IT-Resilienz in der AWS Cloud: Architektur und Muster

von Randy DeFauw, Amine Chigani, and Nigel Harris übersetzt durch David Surey

In Teil I dieses zweiteiligen Blogs haben wir bewährte Verfahren für den Aufbau resilienter Anwendungen in hybriden On-Premises/Cloud-Umgebungen skizziert. Wir haben auch gezeigt, wie Sie Denkweisen und Unternehmenskultur anpassen können. In Teil II werden wir technische Überlegungen zu Architektur und Mustern für Resilienz in der AWS Cloud erläutern.

Überlegungen zu Architektur und Mustern

Das AWS Well-Architected Framework definiert Resilienz als „die Fähigkeit, sich zu erholen, wenn die Workload durch Last (mehr Serviceanfragen), Angriffe (entweder versehentlich durch einen Fehler oder absichtlich) und Ausfälle von Komponenten der Workload belastet wird.“ Resilienz ist ein übergreifendes Anliegen, das eng mit anderen Architekturattributen verbunden ist. Führungskräfte sollten ihre Resilienzstrategien auf Verfügbarkeit, Leistung und Disaster Recovery (DR) ausrichten. Lassen Sie uns Architekturmuster bewerten, die diese Fähigkeit ermöglichen.

1. Kalibrieren Sie Ihre Resilienzarchitektur neu

Die Planung für Resilienz in On-Premises-Umgebungen ist eng mit dem physischen Standort der Rechenressourcen verbunden. On-Premises-Resilienz wird oft mit zwei Rechenzentren erreicht (Abbildung 1).

Lassen Sie uns das Modell in Abbildung 1 basierend auf den Anliegen aufschlüsseln, die Führungskräfte bei der Verbesserung der Resilienz ihrer Umgebung zu lösen versuchen:

• Leistung: Anliegen zur Lösung von Latenz und/oder Leistung unter hoher Last.
• Verfügbarkeit: Anliegen zur Lösung von hoher Verfügbarkeit (HA) und DR.

Lassen Sie uns nun besprechen, wie wir diese Anliegen in der AWS Cloud angehen können. Erstens behandelt das AWS Well-Architected Framework wichtige Architekturprinzipien und zugehörige Services, die Ihnen bei Verfügbarkeit und Leistung helfen. Zweitens können Sie die globale AWS-Infrastruktur nutzen, um Ihre Resilienz durch verschiedene Bereitstellungsmodelle zu verbessern.

AWS-Infrastruktur ermöglicht Resilienz

AWS betreibt weltweit 34 Regionen, die jeweils aus mehreren Availability Zones (AZs) bestehen. Jede AZ verfügt über redundante Ressourcen und nutzt separate physische Einrichtungen, die in sinnvollem Abstand zu anderen AZs liegen. AWS bietet auch Mechanismen, um Ressourcen näher an die Endnutzer zu bringen, einschließlich AWS Local Zones [EN], AWS Wavelength Zones, AWS Outposts und über 600 Points of Presence (PoPs). AWS Direct Connect und verwaltete VPN-Services stellen Verbindungen zwischen dem AWS-Netzwerk und On-Premises-Netzwerken her (Abbildung 2).

Leistung mit AWS-Services

Die am häufigsten verwendeten AWS-Services zur Reduzierung der Latenz sind Amazon CloudFront und Amazon API Gateway. Diese Services cachen statische und dynamische Inhalte sowie API-Antworten in PoPs.

Verfügbarkeit und Disaster Recovery

Verfügbarkeit erfordert die Bewertung Ihrer Ziele und die Durchführung einer Risikobewertung nach Wahrscheinlichkeit, Auswirkung und Minderungskosten (Abbildung 3). Übersetzen Sie ein DR-Ziel nicht automatisch in „Bereitstellung in zwei AWS-Regionen“. Wenn Sie DR beispielsweise als die Fähigkeit definieren, „den Verlust einer physischen Einrichtung zu verkraften“, erfüllt die Bereitstellung in mehreren AZs in einer einzigen AWS-Region dieses Ziel. Multi-AZ-Bereitstellungen zusammen mit regionalen Services wie Amazon Simple Storage Service (Amazon S3) bieten mehr Verfügbarkeit als eine Zwei-Rechenzentren-Infrastruktur.

2. Klassifizieren Sie Workloads nach Verfügbarkeitsstufen

Sobald Sie sich von einer On-Premises-Umgebung entfernen, wenden Sie nicht eine einzige Recovery Time und Recovery Point Objective (RTO/RPO) auf Ihre IT-Landschaft in der Cloud an. Verwenden Sie stattdessen die Vier-Stufen-Klassifizierungsstrategie in Abbildung 4, um Ihre Workloads zu kategorisieren und eine Strategie nach Geschäftskritikalität unter Verwendung von RTO/RPO zu entwickeln.

3. Multi-Region-Disaster-Recovery-Muster

Nachdem Sie Ihre Workloads klassifiziert haben, wählen Sie ein geeignetes DR-Muster, wenn Sie eine Multi-Region-Infrastruktur benötigen. Backup-Lösungen wie Datenbank- und Amazon S3-Replikation können ein RPO von höchstens wenigen Minuten bieten, aber das RTO wird erheblich variieren. Es gibt vier gängige Multi-Region-DR-Muster, wie in den folgenden Abschnitten gezeigt.

Backup und Wiederherstellung (Stufe 4)

Sichern Sie kritische Daten in einer anderen Region. In einem DR-Szenario stellen Sie Daten wieder her und stellen Ihre Anwendung bereit. Diese Option ist am kostengünstigsten, aber eine vollständige Wiederherstellung kann mehrere Stunden dauern. Dieses Muster kann je nach Backup-Zeitplänen zu mehr Datenverlust führen.

Pilot Light (Stufe 2)

Halten Sie wesentliche Komponenten wie Datenbanken repliziert in Amazon S3-Buckets. Herunterskalierte Anwendungsserver werden in einer anderen Region aufrechterhalten und stellen andere Komponenten wie In-Memory-Caches in einem DR-Szenario bereit. Das RTO dauert typischerweise eine Stunde, was Zeit für die Betriebsteams lässt, den Ausfall zu erkennen und darauf zu reagieren, und neue Infrastruktur bereitzustellen.

Warm Standby (Stufe 3)

Führen Sie skalierte Versionen von Anwendungen in einer zweiten Region aus und skalieren Sie für ein DR-Szenario hoch. Während eines Failovers skalieren Sie Ressourcen hoch und erhöhen den Datenverkehr zur Region. Die RTO dauert typischerweise eine Stunde, was den Betriebsteams Zeit gibt, einen Ausfall zu erkennen und darauf zu reagieren. Dieses Muster eignet sich gut für Anwendungen, die schnell reagieren müssen, aber nicht sofort die volle Kapazität benötigen.

Aktiv-aktiv (Tier 1)

Bei diesem Muster bedienen Sie aktiv Datenverkehr aus mehreren Regionen, indem Sie entweder DNS (Amazon Route 53) oder AWS Global Accelerator für das Multi-Region-Routing verwenden. Diese Option bietet die beste RTO, möglicherweise innerhalb von Sekunden, abhängig von der Zeit zur Erkennung des Ausfalls und zur Umleitung des Datenverkehrs durch Aktualisierung des DNS. Sie ist auch kostenintensiver. Neben den Kosten für die Aufrechterhaltung einer minimalen Kapazität wie beim Warm-Standby-Ansatz skalieren Sie jede Region, um zusätzliche Kapazität zu haben.

Die Handhabung von Datenspeichern ist bei diesem Muster komplex, wie wir im nächsten Abschnitt näher erläutern werden.

4. Alles zusammenbringen

Sie haben Ihre geschäftlichen Anforderungen an Leistung und Verfügbarkeit von der Legacy-Infrastruktur entkoppelt. Jetzt können Sie Amazon CloudFront für einen Zugriff mit geringer Latenz für Endbenutzer wählen. Dies kann eine Multi-AZ-Architektur mit einer „Backup und Wiederherstellung“-Strategie für Verfügbarkeit umfassen (Abbildung 5).

Überlegungen zu kritischen Technologiebereichen

AWS gibt Ihnen die Werkzeuge, um die von Ihnen benötigte Ausfallsicherheit zu gestalten. Wenn Ihre Unternehmensarchitekten entscheiden, wie sie diese Werkzeuge anwenden, sollten sie sich auf drei wichtige technische Bereiche konzentrieren. Wir werden jeden davon mit einer Anekdote eines AWS-Kunden aus der Video-Streaming-Branche veranschaulichen.

1. Netzwerk- und Verkehrsmanagement

Nachdem Sie einen DR-Standort in einer zweiten AWS-Region eingerichtet haben, wie leiten Sie den Datenverkehr dorthin um, wenn ein Failover auftritt? Wie vermeiden Sie zusätzliche Latenz, wenn die DR-Region weiter von Ihren Kunden entfernt ist?

AWS bietet Amazon Route 53 und AWS Global Accelerator, Dienste, die als globale Lastverteiler fungieren können, mit festen Eingangspunkten und Verkehrsrouting zwischen Regionen.

Um die Latenz für Endbenutzer zu reduzieren, können Sie AWS Global Accelerator oder Amazon CloudFront verwenden. Dadurch gelangt der Kundenverkehr so schnell wie möglich in das AWS-Edge-Netzwerk und bietet im Vergleich zum offenen Internet eine besser vorhersehbare Latenz.

Unser Video-Streaming-Kunde verwendet Amazon CloudFront für die Inhaltsbereitstellung, um die Leistung beim Video-Streaming zu verbessern. Sie verwenden auch AWS Global Accelerator, um Kundenverkehr zu Microservices zu leiten, die in zwei Regionen bereitgestellt sind.

2. Datenspeicherung

In einer dreischichtigen Webanwendung ist die Datenbankebene am schwierigsten in einem aktiv-aktiven Szenario zu verwalten. Relationale Datenbanken bieten starke Garantien (d. h. ACID-Transaktionen), die mit Kosten verbunden sind: Die meisten relationalen Datenbanken leiten alle Schreibvorgänge durch einen einzelnen Schreibknoten.

Überlegen Sie, ob Sie die Konsistenzanforderungen lockern oder Daten in Ihrer Datenspeicherungsschicht aufteilen können. NoSQL-Datenbanken wie Amazon DynamoDB mit globalen Tabellen ermöglichen es Ihnen, Daten in mehreren Regionen zu schreiben. Die meisten NoSQL-Datenbanken haben jedoch abstimmbare Konsistenzmodelle, die Sie für Verfügbarkeit optimieren können.

Unser Video-Streaming-Kunde hat DynamoDB-globale Tabellen für Multi-Region-Microservices eingeführt, da sie erkannten, dass sie eine eventuelle Lesekonsistenz tolerieren konnten.

3. Überwachung und betriebliche Reaktion

Können Sie erkennen, ob Ihre Kunden ungewöhnliche Fehlerraten und Latenzzeiten beim Zugriff auf Ihre Anwendung erleben? Wissen Sie, warum das passiert und ob Sie ein Failover-Ereignis einleiten müssen?

Überwachungs- und Beobachtbarkeitsdienste wie Amazon CloudWatch und AWS X-Ray helfen Ihnen, die Gesundheitsmetriken und den Fluss von Anfragen für Ihre Anwendung zu sehen. Automatisierungswerkzeuge helfen Ihnen, Reaktions-Runbooks zu automatisieren. Game Days werden Probleme mit Überwachungs- und Reaktionsplänen aufdecken.

Unser Video-Streaming-Kunde verlässt sich auf AWS CloudFormation für die automatisierte Infrastrukturbereitstellung, CloudWatch für die Überwachung und CloudWatch-synthetische Überwachung, um eine Endbenutzersicht auf die Systemleistung zu erhalten.

Fazit

Führungskräfte benötigen Anleitung, wie sie ihre Teams bei der Implementierung und dem Betrieb ausfallsicherer Cloud-Umgebungen führen können. In diesem Blog haben wir Hinweise zur Überprüfung von Architektur- und Musterüberlegungen sowie zu technologischen Bereichen gegeben, auf die man sich konzentrieren sollte.

Weitere Beiträge in dieser Reihe

• IT-Ausfallsicherheit in der AWS Cloud: Denkweise und Kultur

Über die Autoren

	Randy DeFauw ist leitender Principal Solutions Architect bei AWS. Er verfügt über mehr als 20 Jahre Erfahrung im Technologiebereich, beginnend mit seiner Universitätsarbeit an autonomen Fahrzeugen. Er hat mit und für Nutzer von Start-ups bis hin zu Fortune-50-Unternehmen gearbeitet und dabei Big-Data- und Machine-Learning-Anwendungen auf den Markt gebracht. Er besitzt einen MSEE und einen MBA, fungiert als Beirat für K-12 MINT-Bildungsinitiativen und hat auf führenden Konferenzen wie Strata und GlueCon als Redner gewirkt. Er ist Co-Autor des Buches „SageMaker Best Practices“.
	Amine Chigani ist Enterprise Technologist/Strategist bei Amazon Web Services (AWS). In dieser Rolle arbeitet Amine mit Unternehmenskunden zusammen, um Erfahrungen und Strategien zur Cloud-Adoption, agilen Organisationen und Innovation durch KI/ML auszutauschen. Er bringt die AWS-Cloud-Plattform und -Programme ein, um seinen Kunden zu helfen, die Produktqualität zu steigern, technologische Risiken zu reduzieren und den Wert der digitalen Transformation zu realisieren. Vor seiner Tätigkeit bei AWS hatte Amine leitende Technologie-Führungspositionen bei Sentient Science und General Electric inne. Amine hat einen Doktortitel in Informatik von der Virginia Tech.
	Nigel Harris ist Enterprise Solutions Architect bei Amazon Web Services. Er arbeitet mit AWS-Kunden zusammen, um Beratung und technische Unterstützung bei AWS-Architekturen zu bieten.