Grundlegendes 3 für mehrere Regionen: Verstehen Sie Ihre Workload-Abhängigkeiten

Ein bestimmter Workload kann in einer Region mehrere Abhängigkeiten aufweisen, z. B. AWS-Services verwendete, interne Abhängigkeiten, Abhängigkeiten von Drittanbietern, Netzwerkabhängigkeiten, Zertifikate, Schlüssel, Geheimnisse und Parameter. Um den Betrieb des Workloads in einem Ausfallszenario zu gewährleisten, sollten keine Abhängigkeiten zwischen der primären Region und der Standby-Region bestehen. Jede Region sollte unabhängig voneinander arbeiten können. Um dies zu erreichen, sollten Sie alle Abhängigkeiten im Workload genau prüfen, um sicherzustellen, dass sie in jeder Region verfügbar sind. Dies ist erforderlich, da sich ein Ausfall in der primären Region nicht auf die Standby-Region auswirken sollte. Darüber hinaus müssen Sie wissen, wie der Workload funktioniert, wenn sich eine Abhängigkeit in einem schlechten Zustand befindet oder gar nicht verfügbar ist, damit Sie Lösungen entwickeln können, die diesem Problem angemessen gerecht werden.

3.a: AWS-Services

Wenn Sie eine Architektur mit mehreren Regionen entwerfen, ist es wichtig zu verstehen, welche Funktionen diese Dienste für mehrere Regionen bieten und welche Lösungen Sie entwickeln müssen, um Ziele für mehrere Regionen zu erreichen. AWS-Services Beispielsweise können Amazon Aurora und Amazon DynamoDB Daten asynchron in eine Standby-Region replizieren. Alle AWS-Service Abhängigkeiten müssen in allen Regionen verfügbar sein, in denen ein Workload ausgeführt werden soll. Überprüfen Sie die Liste nach Regionen, um zu überprüfen, ob die AWS-Services von Ihnen verwendeten Dienste in den gewünschten Regionen verfügbar sind.

3.b: Interne Abhängigkeiten und Abhängigkeiten von Drittanbietern

Stellen Sie sicher, dass die internen Abhängigkeiten aller Workloads in den Regionen verfügbar sind, von denen aus sie ausgeführt werden. Wenn der Workload beispielsweise aus vielen Microservices besteht, identifizieren Sie alle Microservices, die eine Geschäftsfähigkeit ausmachen, und stellen Sie sicher, dass all diese Microservices in jeder Region bereitgestellt werden, von der aus der Workload ausgeführt wird. Definieren Sie alternativ eine Strategie für den ordnungsgemäßen Umgang mit Microservices, die nicht mehr verfügbar sind.

Von regionsübergreifenden Aufrufen zwischen Microservices innerhalb eines Workloads wird abgeraten, und die regionale Isolation sollte beibehalten werden. Dies liegt daran, dass die Schaffung regionsübergreifender Abhängigkeiten das Risiko eines korrelierten Ausfalls erhöht, wodurch die Vorteile isolierter regionaler Implementierungen des Workloads zunichte gemacht werden. Lokale Abhängigkeiten können ebenfalls Teil der Arbeitslast sein. Daher ist es wichtig zu verstehen, wie sich die Merkmale dieser Integrationen ändern könnten, wenn sich die primäre Region ändern würde. Wenn sich die Standby-Region beispielsweise weiter von der lokalen Umgebung entfernt befindet, kann sich die erhöhte Latenz negativ auswirken.

Wenn Sie Software-as-a-Service (SaaS) -Lösungen, Software Development Kits (SDKs) und andere Abhängigkeiten von Produkten von Drittanbietern verstehen und Szenarien ausführen können, in denen diese Abhängigkeiten entweder beeinträchtigt oder nicht verfügbar sind, erhalten Sie einen besseren Einblick in die Funktionsweise und das Verhalten der Systemkette unter verschiedenen Ausfallmodi. Diese Abhängigkeiten können in Ihrem Anwendungscode enthalten sein, z. B. die externe Verwaltung von Geheimnissen mithilfe AWS Secrets Manager, oder sie können eine Tresorlösung eines Drittanbieters (z. B. HashiCorp) oder Authentifizierungssysteme betreffen, die auf AWS IAM Identity CenterVerbundanmeldungen angewiesen sind.

Redundanz in Bezug auf Abhängigkeiten kann die Widerstandsfähigkeit erhöhen. Wenn eine SaaS-Lösung oder eine Abhängigkeit von einem Drittanbieter denselben primären AWS-Region Workload verwendet, ermitteln Sie gemeinsam mit dem Anbieter, ob dessen Ausfallsicherheit Ihren Anforderungen an den Workload entspricht.

Achten Sie außerdem darauf, dass der Workload und seine Abhängigkeiten, wie z. B. Anwendungen von Drittanbietern, gemeinsam genutzt werden. Wenn die Abhängigkeiten nach einem Failover in (oder von) einer sekundären Region nicht verfügbar sind, wird der Workload möglicherweise nicht vollständig wiederhergestellt.

3.c: Failover-Mechanismus

DNS wird häufig als Failover-Mechanismus verwendet, um den Verkehr von der primären Region in eine Standby-Region zu verlagern. Prüfen und überprüfen Sie kritisch alle Abhängigkeiten, die der Failover-Mechanismus mit sich bringt. Wenn Ihr Workload beispielsweise Amazon Route 53 verwendet, us-east-1 bedeutet das Wissen, dass die Kontrollebene in dieser bestimmten Region gehostet wird, eine Abhängigkeit von der Kontrollebene in dieser bestimmten Region einzugehen. Dies wird nicht als Teil eines Failover-Mechanismus empfohlen, wenn die primäre Region auch us-east-1 deshalb gilt, weil dadurch ein einziger Fehlerpunkt entsteht. Wenn Sie einen anderen Failover-Mechanismus verwenden, sollten Sie ein tiefes Verständnis von Szenarien haben, in denen ein Failover nicht wie erwartet funktionieren würde, und dann für Notfälle planen oder, falls erforderlich, einen neuen Mechanismus entwickeln. Lesen Sie den Blogbeitrag Creating Disaster Recovery Mechanisms Using Amazon Route 53, um mehr über Methoden zu erfahren, mit denen Sie ein erfolgreiches Failover durchführen können.

Wie im vorherigen Abschnitt beschrieben, müssen alle Microservices, die Teil einer Geschäftsfunktion sind, in jeder Region verfügbar sein, in der der Workload bereitgestellt wird. Im Rahmen der Failover-Strategie sollten alle Microservices, die Teil der Geschäftsfähigkeit sind, gemeinsam ein Failover durchführen, um die Möglichkeit regionsübergreifender Anrufe auszuschließen. Wenn Microservices unabhängig voneinander ein Failover durchführen, besteht alternativ die Möglichkeit, dass unerwünschtes Verhalten auftritt, z. B. wenn Microservices möglicherweise regionsübergreifende Anrufe tätigen. Dies führt zu Latenz und kann dazu führen, dass der Workload während der Client-Timeouts nicht mehr verfügbar ist.

3.d: Abhängigkeiten von der Konfiguration

Zertifikate, Schlüssel, Geheimnisse, Amazon Machine Images (AMIs), Container-Images und Parameter sind Teil der Abhängigkeitsanalyse, die beim Entwurf einer Architektur mit mehreren Regionen erforderlich ist. Wann immer möglich, ist es am besten, diese Komponenten innerhalb der einzelnen Regionen zu lokalisieren, damit sie in Bezug auf diese Abhängigkeiten nicht von mehreren Regionen gemeinsam genutzt werden. Sie sollten beispielsweise die Ablaufdaten von Zertifikaten variieren, um zu verhindern, dass sich ein ablaufendes Zertifikat (bei Alarmen auf „Im Voraus benachrichtigen“) auf mehrere Regionen auswirkt.

Verschlüsselungsschlüssel und -geheimnisse sollten ebenfalls regionsspezifisch sein. Auf diese Weise sind die Auswirkungen auf eine bestimmte Region beschränkt, wenn bei der Rotation eines Schlüssels oder Geheimnisses ein Fehler auftritt.

Schließlich sollten alle Workload-Parameter lokal gespeichert werden, damit der Workload in der jeweiligen Region abgerufen werden kann.

Wichtige Hinweise

• Eine Architektur mit mehreren Regionen profitiert von der physischen und logischen Trennung zwischen Regionen. Durch die Einführung regionsübergreifender Abhängigkeiten auf Anwendungsebene wird dieser Vorteil zunichte gemacht. Vermeiden Sie solche Abhängigkeiten.

• Die Failover-Steuerung sollte ohne Abhängigkeiten von der primären Region funktionieren.

• Der Failover sollte während der gesamten Benutzererfahrung koordiniert werden, um die Möglichkeit einer erhöhten Latenz und Abhängigkeit regionsübergreifender Anrufe zu vermeiden.