3,5 Neunen (99,95 %) mit einer Wiederherstellungszeit zwischen 5 und 30 Minuten

Dieses Verfügbarkeitsziel für Anwendungen setzt eine extrem kurze Ausfallzeit und einen sehr geringen Datenverlust zu bestimmten Zeiten voraus. Zu Anwendungen mit diesem Verfügbarkeitsziel gehören Anwendungen in den folgenden Bereichen: Bankwesen, Investments, Notfallservices und Datenerfassung. Diese Anwendungen weisen sehr kurze Wiederherstellungszeiten und Wiederherstellungspunkte auf.

Wir können diese Wiederherstellungszeit weiter verbessern, indem wir einen Warm Standby -Ansatz in zwei AWS-Regionen nutzen. Wir stellen den gesamten Workload in beiden Regionen bereit, wobei unsere passive Website herunterskaliert und alle Daten letztendlich konsistent gehalten werden. Beide Bereitstellungen sind in ihren jeweiligen Regionen statisch stabil. Die Anwendungen sollten unter Verwendung von Ausfallsicherheitsmodellen für verteilte Systeme entwickelt werden. Wir müssen eine einfache Routing -Komponente erstellen, die den Workload-Zustand überwacht und so konfiguriert werden kann, dass der Datenverkehr bei Bedarf an die passive Region weitergeleitet wird.

Überwachung von Ressourcen

Außerdem gibt es einen Alarm bei jedem Austausch eines Webservers sowie bei jedem Datenbank- und Regions-Failover. Wir überwachen außerdem die statischen Inhalte auf Amazon S3 in Bezug auf Verfügbarkeit und geben einen Alarm aus, falls die Inhalte nicht mehr verfügbar sind. Die Protokollierung wird zugunsten einer einfacheren Verwaltung und zur Unterstützung der Ursachenanalyse in jeder Region aggregiert.

Die Routing-Komponente überwacht sowohl den Anwendungsstatus als auch alle regionalen harten Abhängigkeiten, die wir haben.

Anpassungen aufgrund von Bedarfsänderungen durchführen

Identisch mit dem Szenario mit 4 Neunen.

Implementierung von Änderungen

Die Auslieferung neuer Software erfolgt alle zwei bis vier Wochen auf Basis eines festen Zeitplans. Software-Aktualisierungen werden über Canary- oder Blue-/Green-Bereitstellungsmodelle automatisiert.

Es sind Runbooks bei einem Failover in einer Region, bei allgemeinen Kundenproblemen, die im Rahmen dieser Ereignisse auftreten, und für das allgemeine Berichtswesen verfügbar.

Wir verfügen über Playbooks für allgemeine Datenbankprobleme, sicherheitsbezogene Vorfälle, fehlgeschlagene Bereitstellungen, unerwartete Kundenprobleme bei einem Failover in einer Region und der Ermittlung von Problemursachen. Nachdem die Ursache identifiziert wurde, wird die Fehlerbehebung über eine Kombination aus Teams in Betrieb und Entwicklung identifiziert und bereitgestellt, sobald die Fehlerbehebung implementiert wurde.

Für das Infrastructure Event Management nehmen wir außerdem Kontakt zum AWS Support auf.

Daten sichern

Wie im Szenario mit 4 Neunen werden automatische RDS-Sicherungen und die S3-Versionsverwaltung verwendet. Die Daten werden automatisch und asynchron aus dem Aurora RDS-Cluster in der aktiven Region in regionsübergreifende Lesereplikate in der passiven Region repliziert. Die regionsübergreifende S3-Replikation wird verwendet, um Daten automatisch und asynchron aus der aktiven in die passive Region zu verschieben.

Ausfallsichere Architekturen

Wie im Szenario mit 4 Neunen, regionales Failover möglich. Dies wird manuell verwaltet. Während des Failovers leiten wir Anfragen über einen DNS-Failover an eine statische Website weiter, bis die Wiederherstellung in der sekundären Region erfolgreich war.

Ausfallsicherheit testen

Wie im Szenario mit 4 Neunen validieren wir die Architektur im Rahmen von Ernstfallübungen und unter Verwendung von Runbooks. Der Korrektur auf Basis der Ursachenanalyse wird zudem im Vergleich zu Funktionsveröffentlichungen für die unmittelbare Implementierung und Bereitstellung Vorrang eingeräumt.

Planung der Notfallwiederherstellung

Regionales Failover wird manuell verwaltet. Alle Daten werden asynchron repliziert. Die Infrastruktur im Warm Standby wird skaliert. Dies kann mithilfe eines in AWS Step Functions ausgeführten Workflows automatisiert werden. AWS Systems Manager (SSM) kann auch bei dieser Automatisierung helfen, da Sie SSM-Dokumente erstellen können, die Auto Scaling-Gruppen aktualisieren und die Größe von Instances anpassen.

Verfügbarkeitsdesignziel

Wir gehen davon aus, dass zumindest bei einigen Fehlern eine manuelle Entscheidung zur Ausführung einer Wiederherstellung getroffen werden muss. Mit guter Automatisierung in diesem Szenario gehen wir jedoch davon aus, dass diese Entscheidung nur bei zwei Ereignissen pro Jahr getroffen werden muss. Wir benötigen 20 Minuten, um über die Ausführung der Wiederherstellung zu entscheiden, und gehen davon aus, dass die Wiederherstellung innerhalb von 10 Minuten abgeschlossen ist. Dies bedeutet, dass es etwa 30 Minuten dauern wird, das System nach einem Ausfall wiederherzustellen. Ausgehend von zwei Vorfällen pro Jahr liegt die geschätzte zeitliche Auswirkung für das Jahr bei 60 Minuten.

Damit liegen wir am oberen Ende einer Verfügbarkeit von 99,95 %. Die tatsächliche Verfügbarkeit richtet sich auch nach der tatsächlichen Ausfallrate, der Dauer eines Ausfalls und wie schnell jeder Faktor tatsächlich wiederhergestellt werden kann. Bei dieser Architektur gehen wir davon aus, dass die Anwendung auch während der Implementierung von Aktualisierungen online ist. Entsprechend liegt unser Verfügbarkeitsdesignziel bei 99,95 %.

Zusammenfassung

Thema	Implementierung
Ressourcen überwachen	Zustandsprüfungen auf allen Ebenen, einschließlich DNS-Zustand auf AWS-Regionsebene, und für alle KPIs, Ausgabe von Warnmeldungen bei Auslösung konfigurierter Alarme, Warnmeldungen bei allen Fehlern. Im Rahmen betrieblicher Meetings können Trends rigoros aufgedeckt und mit Designzielen in Einklang gebracht werden.
Anpassungen aufgrund von Bedarfsänderungen durchführen	ELB für Web- und Auto Scaling-Anwendungsebene; Auto Scaling-Speicher und Lesereplikate in mehreren Zonen in den aktiven und passiven Regionen für Aurora RDS. Daten und Infrastruktur, die zwischen AWS-Regionen synchronisiert werden, um statische Stabilität zu gewährleisten.
Implementierung von Änderungen	Die automatisierte Bereitstellung über Canary oder Blue/Green und das automatisierte Rollback, wenn KPIs oder Alarme auf nicht erkannte Probleme in einer Anwendung hinweisen. Die Bereitstellungen erfolgen nacheinander in einer Isolationszone einer AWS-Region.
Daten sichern	Automatisierte Sicherungen in jeder AWS-Region über RDS zur Erfüllung des RPO und automatisierte Wiederherstellung, die regelmäßig im Rahmen von Gamedays getestet wird. Aurora RDS- und S3-Daten werden automatisch und asynchron von der aktiven in die passive Region repliziert.
Ausfallsichere Architekturen	Auto Scaling für die Bereitstellung von selbstreparierenden Web- und Anwendungsstufen, RDS ist Multi-AZ, regionaler Failover wird manuell verwaltet, wobei der statische Standort während des Failovers präsentiert wird.
Ausfallsicherheit testen	Das Testen von Fehlern in Komponenten und Isolationszonen ist in der Pipeline enthalten und wird im Rahmen von Gamedays regelmäßig durch Teams im Betrieb ausgeführt, Playbooks sind für die Diagnose unbekannter Probleme vorhanden, und es ist ein Prozess für die Ursachenanalyse vorhanden, mit Kommunikationspfaden zur Problemursache und wie das Problem behoben oder vermieden wurde. Der Korrektur der Ursachenanalyse wird im Vergleich zu Funktionsveröffentlichungen für die unmittelbare Implementierung und Bereitstellung Vorrang eingeräumt.
Planung der Notfallwiederherstellung	Warm Standby wird in einer anderen Region bereitgestellt. Die Infrastruktur wird mithilfe von Workflows skaliert, die mit AWS Step Functions oder AWS Systems Manager-Dokumenten ausgeführt werden. Verschlüsselte Sicherungen über RDS. Regionsübergreifende Lesereplikate zwischen zwei AWS-Regionen. Regionsübergreifende Replikation statischer Komponenten in Amazon S3. Wiederherstellung auf die aktuell aktive AWS-Region, wird im Rahmen von Gamedays geprobt und mit AWS koordiniert.