Multi-Region Active-Active und Active-Passive

Multi-AZ schützt vor dem Ausfall einer einzelnen AZ. Eine gesamte AWS-Region kann jedoch bei großflächigen Katastrophen, schwerwiegenden Ausfällen oder aufgrund regulatorischer Anforderungen nicht verfügbar sein. Multi-Region-Architekturen begegnen diesem Problem, indem sie Workloads in zwei oder mehr geografisch getrennten Regionen ausführen. Es gibt zwei grundlegende Muster: Active-Passive (eine Region verarbeitet den Datenverkehr, während eine andere als Standby bereitsteht) und Active-Active (beide Regionen verarbeiten gleichzeitig Datenverkehr).

In einer Active-Passive-Multi-Region-Konfiguration verarbeitet die primäre Region den gesamten Produktionsdatenverkehr. Die sekundäre Region führt eine verkleinerte, aber funktionsfähige Kopie aus, die aktiv und einsatzbereit bleibt. Daten werden kontinuierlich von der primären in die sekundäre Region repliziert. Wenn die primäre Region ausfällt, stufen Sie die sekundäre Region mithilfe des Failover-Routings von Route 53 zur aktiven Region hoch. Dieses Muster ist kostengünstiger als Active-Active, weist jedoch ein höheres RTO auf, da die Standby-Umgebung erst hochgestuft und skaliert werden muss.

In einer Active-Active-Konfiguration verarbeiten beide Regionen gleichzeitig Produktionsdatenverkehr. Route 53 verteilt Benutzer mithilfe von latenzbasiertem Routing oder gewichtungsbasiertem Routing auf die nächstgelegene oder am besten geeignete Region. Wenn eine Region ausfällt, erkennen die Zustandsprüfungen von Route 53 den Ausfall und leiten den gesamten Datenverkehr an die gesunde Region weiter. Active-Active bietet das beste RTO (nahezu null), reduziert die Latenz für global verteilte Benutzer und erhöht den Durchsatz, indem die Last auf mehrere Regionen verteilt wird.

Die größte Herausforderung einer Multi-Region-Architektur besteht darin, Daten über Regionen hinweg konsistent zu halten. Wichtige Werkzeuge sind: S3 Cross-Region Replication (CRR) repliziert S3-Objekte asynchron in einen Bucket in einer anderen Region. DynamoDB Global Tables ermöglichen eine Multi-Master-Replikation über mehrere Regionen mit letztendlicher Konsistenz. Aurora Global Database repliziert aus einer primären Region in bis zu fünf sekundäre Regionen mit einer Verzögerung von weniger als 1 Sekunde. Jeder Replikationsmechanismus bietet unterschiedliche Konsistenzgarantien und weist eigene Eigenschaften hinsichtlich der Verzögerung auf.

DynamoDB Global Tables ermöglichen eine echte Active-Active-Replikation über mehrere Regionen und mit mehreren Mastern. Ihre Anwendung kann in jeder Region in DynamoDB schreiben. Die Änderungen werden normalerweise innerhalb von 1 Sekunde in alle anderen Regionen repliziert. Die Konfliktauflösung erfolgt nach dem Prinzip Last Writer Wins auf Grundlage von Zeitstempeln. Dadurch eignen sich Global Tables ideal für global verteilte Anwendungen wie Gaming-Bestenlisten, Benutzerprofile und Sitzungsspeicher, bei denen lokale Lese- und Schreibvorgänge mit geringer Latenz entscheidend sind.

Aurora Global Database erstreckt sich über mehrere AWS-Regionen. Eine einzelne primäre Region verarbeitet Schreibvorgänge, während bis zu fünf sekundäre Regionen Lesevorgänge mit einer Replikationsverzögerung von weniger als 1 Sekunde verarbeiten. Für Disaster Recovery können Sie eine sekundäre Region innerhalb von weniger als 1 Minute zur primären Region hochstufen, wodurch sich der Service für Active-Passive mit einem anspruchsvollen RTO eignet. Die sekundären Regionen können außerdem Lesezugriffe mit geringer Latenz bedienen. Dadurch entsteht ein hybrides Muster: Active-Active für Lesevorgänge und Active-Passive für Schreibvorgänge.

Das Failover über mehrere Regionen hinweg basiert auf Route-53-Zustandsprüfungen, die Ausfälle von Regionen erkennen. Zustandsprüfungen können einen Endpunkt (HTTP/HTTPS/TCP), einen CloudWatch-Alarm überwachen oder aus anderen Zustandsprüfungen berechnet werden. Route 53 fragt Ihre Endpunkte kontinuierlich von mehreren Standorten weltweit ab. Wenn eine Prüfung fehlschlägt, gibt Route 53 die Datensätze dieser Region automatisch nicht mehr zurück und leitet den Datenverkehr innerhalb des DNS-TTL-Zeitraums an gesunde Regionen weiter.

AWS Global Accelerator stellt zwei statische Anycast-IP-Adressen bereit, die den Datenverkehr über das globale AWS-Netzwerk an den optimalen Endpunkt leiten. Anders als das DNS-Failover von Route 53, das vom TTL abhängt, erkennt Global Accelerator Ausfälle von Endpunkten innerhalb von 1–3 Sekunden und leitet den Datenverkehr sofort um – deutlich schneller als die DNS-Propagation. Verwenden Sie Global Accelerator, wenn Sie ein Failover im Subsekundenbereich, konsistente IP-Adressen für Whitelists oder eine schnellere Alternative zum TTL-basierten DNS-Routing benötigen, um Ihr RTO einzuhalten.

Active-Active-Multi-Region-Architekturen stehen vor einer grundlegenden Herausforderung: Schreibkonflikten. Wenn zwei Regionen gleichzeitig denselben Datensatz aktualisieren, welcher Schreibvorgang setzt sich durch? DynamoDB Global Tables verwendet Last Writer Wins. Strategien zur Konfliktauflösung auf Anwendungsebene umfassen: Event Sourcing (nur anhängende Protokolle mit CRDT-Zusammenführung), Versionierung (Schreibvorgänge mit veralteten Versionsnummern ablehnen) oder partitionierte Schreibvorgänge (jede Region besitzt einen Daten-Shard und schreibt nur in ihren eigenen Shard). Entwerfen Sie Ihr Datenmodell so, dass Schreibkonflikte zwischen Regionen minimiert werden.

Multi-Region-Architekturen erhöhen Kosten und Komplexität erheblich. Sie zahlen für Ressourcen in mehreren Regionen, Kosten für die Datenreplikation (Datenübertragung zwischen Regionen), Kosten für Zustandsprüfungen und benötigen häufig doppelte Werkzeuge für den Betrieb in jeder Region. Active-Passive ist kostengünstiger, da die Standby-Umgebung mit reduzierter Kapazität ausgeführt wird. Active-Active ist am teuersten, bietet jedoch die beste Benutzererfahrung und das beste RTO. Wägen Sie die Kosten stets gegen den geschäftlichen Nutzen der zusätzlichen regionalen Ausfallsicherheit ab.

Wählen Sie Ihr Multi-Region-Muster anhand der geschäftlichen Anforderungen: Wenn das RTO > 1 Stunde beträgt und die Kosten im Vordergrund stehen, verwenden Sie Backup and Restore in einer anderen Region. Wenn das RTO im Minutenbereich liegt, verwenden Sie Active-Passive mit Warm Standby. Wenn das RTO < 1 Minute beträgt und Ihre Benutzer global verteilt sind, verwenden Sie Active-Active. Berücksichtigen Sie regulatorische Anforderungen. In einigen Branchen müssen Daten in bestimmten Regionen verbleiben, was Ihre Replikationsmöglichkeiten einschränken kann. Dokumentieren Sie Ihre Architekturentscheidung und stellen Sie die jeweiligen Kompromisse ausdrücklich dar.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Active-Passive führt eine Standby-Region aus, die bei einem Ausfall aktiviert wird, Active-Active verarbeitet gleichzeitig Datenverkehr aus mehreren Regionen und DynamoDB Global Tables und Aurora Global Database sind wichtige Services für die Datenreplikation über mehrere Regionen hinweg. Zustandsprüfungen von Route 53 und Global Accelerator übernehmen Entscheidungen zur Weiterleitung des Datenverkehrs. Als Nächstes betrachten wir Zustandsprüfungen, Circuit Breaker und die Logik für Wiederholungsversuche.