Grundlage 4 für mehrere Regionen: Einsatzbereitschaft

Der Betrieb eines Workloads mit mehreren Regionen ist eine komplexe Aufgabe, die mit betrieblichen Herausforderungen verbunden ist, die für eine Architektur mit mehreren Regionen spezifisch sind. Dazu gehören die AWS-Konto Verwaltung, die Anpassung der Bereitstellungsprozesse, die Entwicklung einer regionsübergreifenden Beobachtungsstrategie, die Erstellung und Erprobung von Wiederherstellungsprozessen und die anschließende Verwaltung der Kosten. Ein Operational Readiness Review (ORR) kann Teams dabei helfen, einen Workload für die Produktion vorzubereiten, unabhängig davon, ob er in einer einzelnen Region oder in mehreren Regionen ausgeführt wird.

4.a: Verwaltung AWS-Konto

Um einen Workload flächenübergreifend bereitzustellen AWS-Regionen, stellen Sie sicher, dass alle AWS-Service Kontingente innerhalb eines Accounts in allen Regionen paritätisch verteilt sind. Identifizieren Sie zunächst alle AWS-Services Komponenten der Architektur, schauen Sie sich die geplante Nutzung in den Standby-Regionen an und vergleichen Sie dann die geplante Nutzung mit der aktuellen Nutzung. In einigen Fällen, wenn die Standby-Region noch nicht genutzt wurde, können Sie sich auf die Standard-Servicekontingente beziehen, um den Ausgangspunkt zu verstehen. Fordern Sie dann für alle Dienste, die verwendet werden, eine Erhöhung des Kontingents an, indem Sie die Konsole für Service Quotas verwenden (Anmeldung erforderlich) oder APIs.

Konfigurieren Sie AWS Identity and Access Management (IAM) -Rollen in jeder Region, um Operatoren, Automatisierungstools und AWS-Services die entsprechenden Berechtigungen für Ressourcen in der Standby-Region zuzuweisen. Um eine regionale Isolierung für Architekturen mit mehreren Regionen zu erreichen, isolieren Sie die Rollen nach Regionen. Stellen Sie sicher, dass die erforderlichen Berechtigungen vorhanden sind, bevor Sie eine Standby-Region live schalten.

4.b: Bereitstellungspraktiken

Funktionen für mehrere Regionen können die Bereitstellung eines Workloads in mehreren Regionen erschweren. Sie müssen sicherstellen, dass Sie die Bereitstellung jeweils in einer Region durchführen. Wenn Sie beispielsweise einen Aktiv-Passiv-Ansatz verwenden, sollten Sie die Bereitstellung zuerst in der primären Region und dann in der Standby-Region durchführen. AWS CloudFormationunterstützt Sie bei der Bereitstellung der Infrastruktur in einer oder mehreren Regionen und kann an Ihre Bedürfnisse angepasst werden. AWS CodePipelinehilft Ihnen beim Aufbau einer integration/continuous delivery (CI/CD (kontinuierlichen) Pipeline mit regionsübergreifenden Aktionen, die den Einsatz in Regionen ermöglichen, die sich von der Region unterscheiden, in der sich die Pipeline befindet. In Kombination mit robusten Bereitstellungsstrategien wie Blau/Grün ermöglicht dies eine Bereitstellung mit minimalen bis gar keinen Ausfallzeiten.

Die Bereitstellung von Stateful-Capabilities kann jedoch komplexer werden, wenn der Status der Anwendung oder der Daten nicht in einen persistenten Speicher ausgelagert wird. Passen Sie in diesen Situationen den Bereitstellungsprozess sorgfältig an Ihre Bedürfnisse an. Entwerfen Sie die Bereitstellungspipeline und den Prozess so, dass die Bereitstellung in jeweils einer Region statt in mehreren Regionen gleichzeitig erfolgt. Dadurch wird die Wahrscheinlichkeit korrelierter Ausfälle zwischen den Regionen verringert. Weitere Informationen zu den Techniken, die Amazon zur Automatisierung von Softwarebereitstellungen verwendet, finden Sie im Artikel Automating safe, hands-off Deployments in der AWS Builders' Library.

4.c: Beobachtbarkeit

Denken Sie bei der Planung für mehrere Regionen darüber nach, wie Sie den Zustand aller Komponenten in jeder Region überwachen möchten, um einen ganzheitlichen Überblick über den regionalen Zustand zu erhalten. Dies könnte die Überwachung von Metriken im Hinblick auf Replikationsverzögerungen beinhalten, was bei Workloads mit nur einer Region nicht berücksichtigt wird.

Wenn Sie eine Architektur mit mehreren Regionen erstellen, sollten Sie die Leistung des Workloads auch von den Standby-Regionen aus beobachten. Dazu gehören auch Integritätsprüfungen und Canaries (synthetische Tests), die von der Standby-Region aus durchgeführt werden, um einen externen Überblick über den Zustand der primären Region zu erhalten. Darüber hinaus können Sie Amazon CloudWatch Internet Monitor verwenden, um den Status des externen Netzwerks und die Leistung Ihrer Workloads aus der Sicht eines Endbenutzers zu verstehen. In der primären Region sollte dieselbe Beobachtbarkeit für die Überwachung der Standby-Region vorhanden sein.

Die Kanaren aus der Standby-Region sollten die Kennzahlen zum Kundenerlebnis überwachen, um den allgemeinen Zustand der Arbeitslast zu ermitteln. Dies ist erforderlich, da bei einem Problem in der primären Region die Beobachtbarkeit in der primären Region beeinträchtigt werden könnte, was sich negativ auf Ihre Fähigkeit auswirken würde, den Zustand der Arbeitslast einzuschätzen.

In diesem Fall kann eine Beobachtung außerhalb dieser Region Aufschluss geben. Diese Kennzahlen sollten in Dashboards zusammengefasst werden, die in jeder Region verfügbar sind, und in Alarmen, die in jeder Region erstellt werden. Da CloudWatches sich um einen regionalen Dienst handelt, ist es erforderlich, Alarme in beiden Regionen zu haben. Diese Überwachungsdaten werden verwendet, um den Anruf zum Failover von einer primären Region in eine Standby-Region zu tätigen.

4.d: Prozesse und Verfahren

Der beste Zeitpunkt, um die Frage „Wann sollte ich einen Failover durchführen?“ zu beantworten ist lange bevor du es musst. Definieren Sie rechtzeitig vor dem Auftreten eines Problems Wiederherstellungspläne, die Personen, Prozesse und Technologien einbeziehen, und testen Sie sie regelmäßig. Entscheiden Sie sich für einen Rahmen für Sanierungsentscheidungen. Wenn es einen gut geübten Wiederherstellungsprozess gibt und die Dauer bis zur Wiederherstellung genau bekannt ist, können Sie den Wiederherstellungsprozess mit einem Failover starten, das das RTO-Ziel erfüllt. Dieser Zeitpunkt kann unmittelbar nach der Identifizierung eines Problems mit der Anwendung in der primären Region liegen, oder es könnte sich um einen weiteren Zeitpunkt handeln, zu dem die Wiederherstellungsoptionen innerhalb der Anwendung in der Region ausgeschöpft sind.

Die Failover-Aktion selbst sollte zu 100 Prozent automatisiert sein, aber die Entscheidung, den Failover zu aktivieren, sollte von Menschen getroffen werden — in der Regel von einer kleinen Anzahl vorher festgelegter Personen in der Organisation. Diese Personen sollten den Verlust von Daten und Informationen über das Ereignis in Betracht ziehen. Außerdem müssen die Kriterien für einen Failover klar definiert und innerhalb der Organisation allgemein bekannt sein. Um diese Prozesse zu definieren und abzuschließen, können Sie AWS Systems Manager Runbooks verwenden, die eine vollständige end-to-end Automatisierung ermöglichen und die Konsistenz der Prozesse sicherstellen, die während der Tests und beim Failover ausgeführt werden.

Diese Runbooks sollten in den Primär- und Standby-Regionen verfügbar sein, um die Failover- oder Failback-Prozesse zu starten. Sobald diese Automatisierung eingeführt ist, definieren Sie einen regelmäßigen Testrhythmus und halten Sie ihn ein. Auf diese Weise wird sichergestellt, dass bei einem tatsächlichen Ereignis die Reaktion auf einen klar definierten, eingeübten Prozess erfolgt, in den das Unternehmen Vertrauen hat. Es ist auch wichtig, die festgelegten Toleranzen für Datenabgleichsprozesse zu berücksichtigen. Vergewissern Sie sich, dass der vorgeschlagene Prozess die festgelegten RPO/RTO-Anforderungen erfüllt.

4.e: Testen

Ein ungetesteter Wiederherstellungsansatz ist gleichbedeutend damit, keinen Wiederherstellungsansatz zu haben. Eine grundlegende Testphase besteht darin, ein Wiederherstellungsverfahren durchzuführen, um die Betriebsregion für Ihre Anwendung zu wechseln. Manchmal wird dies als Ansatz zur Anwendungsrotation bezeichnet. Wir empfehlen Ihnen, die Funktion zum Umschalten von Regionen in Ihre normale Betriebsposition einzubauen. Dieser Test allein reicht jedoch nicht aus.

Resilienztests sind auch wichtig, um den Wiederherstellungsansatz einer Anwendung zu validieren. Dazu gehören die Implementierung bestimmter Ausfallszenarien, das Verständnis dafür, wie Ihre Anwendung und Ihr Wiederherstellungsprozess reagieren, und dann die Implementierung aller erforderlichen Abhilfemaßnahmen, falls der Test nicht wie geplant verlaufen sollte. Wenn Sie Ihr Wiederherstellungsverfahren ohne Fehler testen, erfahren Sie nicht, wie sich Ihre Anwendung insgesamt verhält, wenn Fehler auftreten. Sie müssen einen Plan entwickeln, um Ihre Wiederherstellung anhand erwarteter Ausfallszenarien zu testen. AWS Fault Injection Servicebietet eine ständig wachsende Liste von Szenarien, um Ihnen den Einstieg zu erleichtern.

Dies ist besonders wichtig für Hochverfügbarkeitsanwendungen, bei denen strenge Tests erforderlich sind, um sicherzustellen, dass die Geschäftskontinuitätsziele erreicht werden. Durch proaktives Testen der Wiederherstellungsfunktionen wird das Risiko von Produktionsausfällen reduziert, wodurch das Vertrauen gestärkt wird, dass die Anwendung die gewünschte begrenzte Wiederherstellungszeit erreichen kann. Durch regelmäßige Tests wird auch betriebliches Fachwissen aufgebaut, sodass das Team bei auftretenden Ausfällen schnell und zuverlässig die Wiederherstellung durchführen kann. Die Berücksichtigung der menschlichen Komponente oder des Prozesses Ihres Wiederherstellungsansatzes ist genauso wichtig wie die technischen Aspekte.

4.f: Kosten und Komplexität

Die Auswirkungen einer Architektur mit mehreren Regionen auf die Kosten sind auf eine höhere Infrastrukturnutzung, höhere Betriebskosten und mehr Ressourcenaufwand zurückzuführen. Wie bereits erwähnt, entsprechen die Infrastrukturkosten in einer Standby-Region den Infrastrukturkosten in einer primären Region bei der Vorbereitstellung, sodass sich Ihre Gesamtkosten verdoppeln. Stellen Sie Kapazität so bereit, dass sie für den täglichen Betrieb ausreicht, aber dennoch genügend Pufferkapazität reserviert ist, um Nachfragespitzen zu verkraften. Konfigurieren Sie dann in jeder Region dieselben Grenzwerte.

Wenn Sie eine Active-Active-Architektur verwenden, müssen Sie außerdem möglicherweise Änderungen auf Anwendungsebene vornehmen, um Ihre Anwendung in einer Architektur mit mehreren Regionen erfolgreich auszuführen. Die Entwicklung und der Betrieb dieser Änderungen können zeit- und ressourcenintensiv sein. Unternehmen müssen zumindest Zeit damit verbringen, die technischen und geschäftlichen Abhängigkeiten in den einzelnen Regionen zu verstehen und Failover- und Failback-Prozesse zu entwerfen.

Die Teams sollten außerdem normale Failover- und Failback-Übungen durchführen, um sich mit Runbooks, die während einer Veranstaltung verwendet werden, vertraut zu machen. Diese Übungen sind zwar entscheidend, um das erwartete Ergebnis einer Investition in mehreren Regionen zu erzielen, sie bedeuten jedoch auch Opportunitätskosten und nehmen Zeit und Ressourcen für andere Aktivitäten in Anspruch.

4.g: Organisatorische Failover-Strategie für mehrere Regionen

AWS-Regionen bietet Grenzen zur Fehlerisolierung, um korrelierte Ausfälle zu verhindern und die Auswirkungen von etwaigen AWS-Service Beeinträchtigungen auf eine einzelne Region einzudämmen. Sie können diese Fehlergrenzen verwenden, um regionsübergreifende Anwendungen zu erstellen, die aus unabhängigen, fehlerisolierten Replikaten in jeder Region bestehen, um Szenarien mit gemeinsamem Schicksal zu begrenzen. Auf diese Weise können Sie regionsübergreifende Anwendungen erstellen und eine Reihe von Ansätzen — von Backup und Wiederherstellung über Pilotbetrieb bis hin zu Active-Active — zur Implementierung Ihrer multiregionalen Architektur verwenden. Anwendungen werden jedoch in der Regel nicht isoliert betrieben. Berücksichtigen Sie daher sowohl die Komponenten, die Sie verwenden werden, als auch deren Abhängigkeiten als Teil Ihrer Failover-Strategie. Im Allgemeinen arbeiten mehrere Anwendungen zusammen, um eine User Story zu unterstützen. Dabei handelt es sich um eine spezielle Funktion, die einem Endbenutzer angeboten wird, z. B. das Posten eines Bilds und einer Bildunterschrift in einer Social-Media-App oder das Auschecken auf einer E-Commerce-Website. Aus diesem Grund sollten Sie eine unternehmensweite Failover-Strategie für mehrere Regionen entwickeln, die für die nötige Koordination und Konsistenz sorgt, damit Ihr Ansatz erfolgreich ist.

Es gibt vier übergeordnete Strategien, aus denen Unternehmen als Leitfaden für einen regionenübergreifenden Ansatz wählen können. Diese sind vom detailliertesten bis zum umfassendsten Ansatz aufgeführt:

• Failover auf Komponentenebene

• Failover einzelner Anwendungen

• Failover mit Abhängigkeitsdiagramm

• Failover für das gesamte Anwendungsportfolio

Jede Strategie hat Kompromisse und geht auf unterschiedliche Herausforderungen ein. Dazu gehören Flexibilität bei der Entscheidungsfindung, die Fähigkeit, die Failover-Kombinationen zu testen, modales Verhalten und organisatorische Investitionen in Planung und Implementierung. Weitere Informationen zu den einzelnen Strategien finden Sie im AWS Blogbeitrag Creating an Organizational Multi-Regions Failover-Strategie.

Wichtige Hinweise

• Überprüfen Sie alle AWS-Service Kontingente, um sicherzustellen, dass sie in allen Regionen, in denen die Arbeitslast ausgeführt wird, einheitlich sind.

• Der Bereitstellungsprozess sollte jeweils auf eine Region abzielen, anstatt mehrere Regionen gleichzeitig einzubeziehen.

• Zusätzliche Messwerte wie die Verzögerung bei der Replikation sind spezifisch für Szenarien mit mehreren Regionen und sollten überwacht werden.

• Erweitern Sie die Überwachung der Arbeitslast über die primäre Region hinaus. Überwachen Sie die Kennzahlen zum Kundenerlebnis für jede Region und messen Sie diese Daten außerhalb jeder Region, in der ein Workload ausgeführt wird.

• Testen Sie Failover und Failback regelmäßig. Implementieren Sie ein einziges Runbook für Failover- und Failback-Prozesse und verwenden Sie es sowohl für Tests als auch für Live-Events. Runbooks für Tests und Live-Events sollten sich nicht unterscheiden.

• Machen Sie sich mit den Kompromissen der Failover-Strategien vertraut. Implementieren Sie ein Abhängigkeitsdiagramm oder eine Strategie für das gesamte Anwendungsportfolio.