Zonale Automatik-Umschaltung – Automatisches Umleiten des Datenverkehrs von Verfügbarkeitszonen bei potenziellen Problemen

von Sébastien Stormacq, übersetzt von Tobias Nitzsche.

Heute stellen wir eine neue Funktion des Amazon Route 53 Application Recovery Controllers vor: die zonale Automatik-Umschaltung. Diese Funktion leitet den Datenverkehr Ihrer Workloads automatisch und sicher auf eine andere Verfügbarkeitszone [EN] um, sobald AWS ein mögliches Problem in der ursprünglichen Zone erkennt. Sobald das Problem behoben ist, wird der Datenverkehr wieder zurückgeleitet.

Um robuste Anwendungen zu betreiben, verteilen Sie normalerweise Ihre Ressourcen über mehrere Verfügbarkeitszonen innerhalb einer Region. Diese Zonen bestehen aus Gruppen von physischen Datenzentren, die klar voneinander getrennt (meistens einige Kilometer) sind. Das stellt sicher, dass jede Zone über eigene Stromquellen, Verbindungen, Netzwerkgeräte und Schutz vor Überschwemmungen verfügt.

Um Sie vor Problemen wie fehlgeschlagenen Deployments, Konfigurationsfehlern oder Bedienerfehlern zu schützen, haben wir letztes Jahr eine Funktion eingeführt, mit der Sie manuell oder programmgesteuert einen zonalen Wechsel auslösen [EN] können. Diese Funktion erlaubt es Ihnen den Datenverkehr von einer Verfügbarkeitszone umzuleiten, falls Sie dort eine Verschlechterung der Leistung feststellen. Dies wird erreicht, indem Ihr Lastausgleich so eingestellt wird, dass er alle neuen Verbindungen nur an Infrastrukturen in den funktionierenden Verfügbarkeitszonen weiterleitet. Auf diese Weise bleibt Ihre Anwendung für Ihre Kunden verfügbar, während Sie das Problem untersuchen. Sobald das Problem gelöst ist, können Sie die zonale Umschaltung beenden, um den Datenverkehr wieder gleichmäßig über alle Zonen zu verteilen.

Die zonale Umschaltung arbeitet auf der Ebene des Application Load Balancers (ALB) [EN] oder des Network Load Balancers (NLB). Sie funktioniert nur, wenn der Lastenausgleich über verschiedene Zonen ausgeschaltet ist. Bei NLBs ist dies standardmäßig der Fall. Kurz erklärt, Lastausgleicher bieten zwei Stufen: Die erste Stufe erfolgt über DNS. Hier stellen Lastausgleicher für jede Verfügbarkeitszone eine oder mehrere IP-Adressen bereit, was einen Lastenausgleich zwischen den Zonen auf Clientseite ermöglicht. Wenn der Datenverkehr eine Zone erreicht, verteilt der Lastausgleich ihn weiter zu registrierten, funktionierenden Zielen, üblicherweise zu einer Amazon Elastic Compute Cloud (Amazon EC2)-Instanz. Standardmäßig leiten ALBs den Datenverkehr zu Zielen in allen Verfügbarkeitszonen weiter. Für eine korrekte zonale Umschaltung müssen Sie Ihren Lastausgleicher so einrichten, dass der Lastenausgleich über verschiedene Zonen deaktiviert wird.

Wenn die zonale Umschaltung aktiviert wird, lenkt das DNS den Datenverkehr von einer bestimmten Verfügbarkeitszone weg, wie in folgendem Diagramm dargestellt:

Die manuelle zonale Umschaltung hilft dabei, Ihre Workloads vor Problemen zu schützen, die auf Ihrer Seite entstehen könnten. Allerdings ist es manchmal schwierig, ein potenzielles Versagen in einer Verfügbarkeitszone zu erkennen. Es ist oft kompliziert Probleme anhand von Anwendungsmetriken zu erkennen, besonders wenn Sie normalerweise keine Metriken für jede Verfügbarkeitszone separat verfolgen. Zudem können Ihre Dienste Abhängigkeiten über die Grenzen der Verfügbarkeitszonen hinweg haben, was zu Fehlern in allen Zonen führen kann. Bei modernen Mikroservice-Architekturen müssen die Erkennung und Wiederherstellung oft über tausende separate Mikroservices hinweg durchgeführt werden, was die Wiederherstellungszeit auf mehrere Stunden verlängern kann.

Unsere Kunden haben uns gefragt, ob wir ihnen helfen könnten, ein mögliches Versagen in einer Verfügbarkeitszone zu erkennen. Sie argumentierten, dass wir durch unsere internen Überwachungswerkzeuge potenzielle Probleme früher feststellen könnten, als sie es selbst könnten.

Mit dieser neuen Funktion können Sie jetzt die zonale Automatik-Umschaltung einrichten, um Ihre Workloads vor einem möglichen Ausfall in einer Verfügbarkeitszone zu schützen. Wir nutzen dazu unsere eigenen AWS-internen Überwachungswerkzeuge und Metriken, um zu entscheiden, wann eine Umleitung des Datenverkehrs notwendig ist. Diese Umschaltung erfolgt automatisch, ohne dass eine spezielle API aufgerufen werden muss. Sobald wir feststellen, dass eine Zone ein potentielles Problem hat, wie zum Beispiel eine Strom- oder Netzwerkstörung, lösen wir automatisch eine Umschaltung des NLB- oder ALB-Verkehrs Ihrer Infrastruktur aus. Der Datenverkehr wird dann automatisch zurückgeleitet, sobald das Problem behoben ist.

Natürlich ist das Umleiten von Datenverkehr aus einer Verfügbarkeitszone eine sensible und komplexe Aufgabe, die gründliche Vorbereitung erfordert. Wir haben mehrere Sicherheitsmaßnahmen eingeführt, um sicherzustellen, dass wir die Verfügbarkeit Ihrer Anwendung nicht unbeabsichtigt beeinträchtigen.

Erstens haben wir interne Kontrollen implementiert, um sicherzustellen, dass wir zu keiner Zeit den Verkehr aus mehr als einer Verfügbarkeitszone umleiten. Zweitens führen wir wöchentlich für 30 Minuten eine Test-Umschaltung Ihrer Infrastruktur durch. Sie haben die Möglichkeit, Zeiten festzulegen, in denen diese Tests nicht stattfinden sollen, beispielsweise werktags von 08:00 bis 18:00 Uhr. Drittens können Sie zwei Amazon CloudWatch-Alarms einrichten, die während des Testlaufs als Sicherheitsmechanismen (Circuit Breaker) [EN] dienen: einen Alarm, um den Beginn des Tests zu verhindern, und einen weiteren, um die Gesundheit Ihrer Anwendung während des Tests zu überwachen. Wird einer dieser Alarme während des Tests ausgelöst, brechen wir den Test ab und stellen den Verkehr in alle Verfügbarkeitszonen wieder her. Der Zustand des Alarms zur Anwendungsgesundheit am Ende des Tests zeigt an, ob der Test erfolgreich war oder nicht.

Laut dem Modell der geteilten Verantwortung liegen auch bei Ihnen zwei wichtige Aufgaben:

Zuerst müssen Sie sicherstellen, dass in jeder Verfügbarkeitszone genügend Kapazitäten vorhanden sind, um den erhöhten Datenverkehr in den übrigen Zonen nach einer Umleitung zu bewältigen. Wir raten dringend dazu, stets ausreichende Kapazitäten in den verbleibenden Zonen bereitzuhalten. Verlassen Sie sich dabei nicht zu sehr auf Skalierungsmechanismen, da diese die Wiederherstellung Ihrer Anwendung verzögern oder deren Verfügbarkeit beeinträchtigen könnten. Wenn die zonale Automatik-Umschaltung aktiviert wird, könnte es länger dauern als üblich, bis AWS Auto Scaling Ihre Ressourcen angepasst hat. Eine Vorskalierung Ihrer Ressourcen sorgt für eine vorhersehbare Wiederherstellungszeit, auch für Ihre anspruchsvollsten Anwendungen.

Stellen Sie sich vor, Ihre Anwendung benötigt unter normalen Umständen sechs EC2-Instanzen, verteilt auf drei Verfügbarkeitszonen (also jeweils 2 Instanzen pro Zone). Bevor Sie die zonale Automatik-Umschaltung einrichten, sollten Sie sicherstellen, dass in den verbleibenden Verfügbarkeitszonen genügend Kapazitäten vorhanden sind, um den Datenverkehr aufzufangen, falls eine Zone ausfällt. In diesem Beispiel bedeutet das, dass Sie in jeder Verfügbarkeitszone drei Instanzen bereitstellen sollten (also insgesamt 3×3 = 9 Instanzen bei drei Verfügbarkeitszonen). So können Sie sicherstellen, dass genügend Kapazitäten vorhanden sind (2×3 = 6 Instanzen), um den Datenverkehr zu bewältigen, wenn dieser auf zwei Verfügbarkeitszonen umgeleitet wird.

In der Praxis ist es üblich bei Diensten, die hohe Zuverlässigkeit erfordern, etwas redundante Kapazität vorzuhalten, um Eventualitäten wie Lastspitzen, gelegentliche Ausfälle von Hosts und Ähnliches zu bewältigen. Wenn Sie Ihre vorhandene Redundanz auf diese Art erhöhen, sorgt das nicht nur dafür, dass Sie sich schnell von einem Ausfall einer Verfügbarkeitszone erholen können. Es erhöht auch Ihre Widerstandsfähigkeit gegenüber anderen unvorhergesehenen Ereignissen.

Zweitens müssen Sie die zonale Automatik-Umschaltung bewusst für die von Ihnen gewählten Ressourcen aktivieren. AWS wird diese Umschaltung nur auf die Ressourcen anwenden, die Sie ausgewählt haben. Die Nutzung der zonalen Automatik-Umschaltung hat Auswirkungen auf die Gesamtkapazität, die Ihrer Anwendung zur Verfügung steht. Wie ich bereits erläutert habe, muss Ihre Anwendung darauf vorbereitet sein, indem Sie genügend Kapazitäten in den verbleibenden Verfügbarkeitszonen bereithalten.

Natürlich kostet das Bereitstellen zusätzlicher Kapazität in allen Verfügbarkeitszonen Geld. Bei der Frage der Widerstandsfähigkeit geht es immer um eine geschäftliche Abwägung zwischen der Verfügbarkeit Ihrer Anwendung und den damit verbundenen Kosten. Das ist ein weiterer Grund, warum wir die zonale Automatik-Umschaltung nur für die von Ihnen ausgewählten Ressourcen durchführen.

Konfiguration

Ich zeige Ihnen die Konfiguration anhand meiner bekannten TicTacToe-Webanwendung [Extern], die ich mit einem CDK-Skript [Extern] bereitstelle. Zuerst öffne ich die Seite des Route 53 Application Recovery Controllers in der AWS Management Console. Im linken Menü wähle ich Zonale Automatik-Umschaltung (Zonal autoshift). Auf der Willkommensseite klicke ich dann auf die Option Configure zonal autoshift, um die zonale Automatik-Umschaltung für eine Ressource zu konfigurieren.

Ich wähle den Load Balancer meiner Demo-Konfiguration aus. Wichtig ist hierbei, dass momentan nur Load Balancer, die keinen aktiven Lastenausgleich über verschiedene Zonen betreiben, für die zonale Automatik-Umschaltung geeignet sind. Wie mich eine Warnmeldung in der Konsole erinnert, stelle ich außerdem sicher, dass meine Anwendung genügend Kapazitäten besitzt, um auch bei einem Ausfall einer Verfügbarkeitszone weiterhin funktionieren zu können.

Ich scrolle auf der Seite nach unten, um die Zeiten und Tage festzulegen, an denen AWS den 30-minütigen Übungslauf nicht durchführen soll. Anfangs, um mich erst einmal an die Automatik-Umschaltung zu gewöhnen, blockiere ich die Testläufe von 08:00 bis 18:00 Uhr, Montag bis Freitag. Dabei ist zu beachten, dass die Zeiten in UTC angegeben sind und sich nicht automatisch an die Sommerzeit [Extern] anpassen. Hier kann ein UTC-Zeitrechner [Extern] hilfreich sein. Obwohl es sicher erscheint, die Geschäftszeiten anfangs auszuschließen, empfehlen wir, den Übungslauf auch während Ihrer Geschäftszeiten zu planen. So können Sie Probleme entdecken, die möglicherweise nicht auftreten, wenn wenig oder kein Verkehr auf Ihrer Anwendung ist. Die zonale Automatik-Umschaltung ist besonders wichtig, um während Ihrer Hauptverkehrszeiten reibungslos zu funktionieren. Aber wie können Sie sich sicher sein, dass sie funktioniert, wenn Sie sie nie unter diesen Bedingungen getestet haben? Ideal wäre es, keine Zeiten zu blockieren, aber wir verstehen, dass dies nicht immer praktikabel ist.

Weiter unten auf derselben Seite richte ich zwei Schutzschalter-Alarme ein. Der erste Alarm dient dazu, den Start der Übung zu verhindern. Mit diesem Alarm signalisieren Sie uns, dass es gerade kein geeigneter Zeitpunkt für einen Übungslauf ist, beispielsweise wenn es ein Problem mit Ihrer Anwendung gibt oder wenn Sie gerade eine neue Version in der Produktion einführen. Der zweite CloudWatch-Alarm zeigt das Ergebnis des Übungslaufs an. Er hilft dabei zu beurteilen, wie Ihre Anwendung auf den Übungslauf reagiert. Bleibt der Alarm grün, bedeutet das, dass der Übungslauf problemlos verlaufen ist.

Wenn einer dieser beiden Alarme während des Übungslaufs ausgelöst wird, beendet die zonale Automatik-Umschaltung sofort den Test und stellt den Datenverkehr in alle Verfügbarkeitszonen wieder her.

Zum Abschluss bestätige ich, dass der 30-minütige Übungslauf jede Woche stattfindet, wobei ich mir bewusst bin, dass dies kurzfristig die Verfügbarkeit meiner Anwendung beeinträchtigen kann.

Danach klicke ich auf Erstellen (Create).

Und das war’s.

Einige Tage später überprüfe ich die Historie der Übungsläufe im Abschnitt „Zonale Umschaltungshistorie für Ressourcen“ (Zonal shift history for resource) in der Konsole. Ich beobachte die Historie meiner beiden Schutzschalter-Alarme genau, um sicherzustellen, dass alles richtig überwacht und konfiguriert ist.

Es ist nicht möglich, eine Automatik-Umschaltung manuell zu testen, da sie nur automatisch ausgelöst wird, wenn wir ein potentielles Problem in einer Verfügbarkeitszone erkennen. Ich habe sogar das Serviceteam gefragt, ob wir eine Verfügbarkeitszone absichtlich abschalten könnten, um die Schritte, die ich in diesem Beitrag erläutere, zu testen; meine Anfrage wurde freundlich abgelehnt :-).

Um Ihre Konfiguration dennoch zu testen, können Sie stattdessen eine manuelle Umschaltung durchführen, die sich genauso verhält wie eine Automatik-Umschaltung.

Wissenswertes

Die zonale Automatik-Umschaltung ist jetzt in allen AWS-Regionen, mit Ausnahme von China und GovCloud, ohne zusätzliche Kosten verfügbar.

Wir empfehlen, die „Krabbeln, Laufen, Rennen“-Methodik anzuwenden. Beginnen Sie zunächst mit manuellen zonalen Umschaltungen, um Vertrauen in die Funktionsweise Ihrer Anwendung zu gewinnen. Danach aktivieren Sie die zonale Automatik-Umschaltung und führen Übungsläufe außerhalb Ihrer Geschäftszeiten durch. Schließlich passen Sie den Zeitplan so an, dass Übungsumschaltungen auch während Ihrer Geschäftszeiten durchgeführt werden. Das Ziel ist es, zu testen, wie Ihre Anwendung auf ein unerwartetes Ereignis reagiert, insbesondere wenn es am wenigsten erwünscht ist.

Wir raten Ihnen, ganzheitlich zu überlegen, wie sich alle Komponenten Ihrer Anwendung erholen, wenn wir den Verkehr von einer Verfügbarkeitszone weg- und später wieder zurückleiten. Hier ist eine Liste von Überlegungen, die mir in den Sinn kommen (sie ist sicherlich nicht umfassend):

1. Planen Sie zusätzliche Kapazitäten: Wie ich bereits erörtert habe, ist es wichtig, genügend Kapazitäten vorzusehen.
2. Denken Sie über einzelne Ausfallpunkte in jeder Zone nach: Zum Beispiel eine selbstverwaltete Datenbank auf einer einzelnen EC2-Instanz oder ein Mikroservice, der nur in einer Zone verbleibt. Ich empfehle dringend, verwaltete Datenbanken wie Amazon DynamoDB oder Amazon Aurora zu nutzen, die für Anwendungen mit zonalen Umschaltungen integrierte Replikations- und Failover-Mechanismen bieten.
3. Planen Sie den Rückschaltvorgang: Überlegen Sie, wie viel Zeit Sie benötigen, um Ihre Ressourcen zu skalieren, wenn die Verfügbarkeitszone wieder verfügbar ist. Müssen Sie Caches neu auffüllen oder andere Anpassungen vornehmen?

Sie können mehr über resiliente Architekturen und Methodologien in einer ausgezeichneten Artikelserie meines Kollegen Adrian [EN, Extern] lernen.

Zum Abschluss möchte ich nochmals darauf hinweisen, dass derzeit nur Load Balancer, die keinen aktiven Lastenausgleich über verschiedene Zonen ausführen, für die zonale Automatik-Umschaltung geeignet sind. Um den Lastenausgleich über verschiedene Zonen (cross-zone load balancing) in einem CDK-Skript zu deaktivieren, müssen Sie die Eigenschaft stickinessCookieDuration entfernen und load_balancing.cross_zone.enabled=false in der Zielgruppe hinzufügen. Hier ist ein Beispiel dafür, wie es in CDK Typescript aussehen könnte:

// Fügen Sie die Auto-Scaling-Gruppe als Ziel für das Load Balancing
// zum Listener hinzu.
const targetGroup = listener.addTargets('MyApplicationFleet', {
 port: 8080,
// für die zonale Umschaltung müssen Stickiness & Cross-Zones Load Balancing deaktiviert sein
// stickinessCookieDuration: Duration.hours(1),
 targets: [asg]
});

// Cross Zone Load Balancing deaktivieren
targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false");

Nun ist für Sie der richtige Zeitpunkt gekommen, um die Anwendungen auszuwählen, die von der zonalen Automatik-Umschaltung profitieren könnten. Starten Sie, indem Sie Ihre Infrastrukturkapazität in jeder Verfügbarkeitszone überprüfen und anschließend die Schutzschalter-Alarme definieren. Sobald Sie sichergehen, dass Ihr Monitoring korrekt konfiguriert ist, können Sie die zonale Automatik-Umschaltung aktivieren.

— seb [Extern] & Tobi [Extern]

Über die Autoren

Sébastien Stormacq programmiert bereits seit den mittleren 80er Jahren, als er zum ersten Mal Kontakt mit einem Commodore 64 hatte. Er motiviert Entwickler:innen, das Potenzial der AWS-Cloud zu entdecken, indem er Leidenschaft, Begeisterung, Kundenorientierung, Neugier und Kreativität kombiniert. Er interessiert sich besonders für Softwarearchitektur, Entwicklertools und mobile Technologien. Wenn Sie Seb etwas anbieten möchten, sollte es über eine API verfügen. Sie können ihm auf X (Twitter) unter @sebsto folgen.