Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
REL12-BP05 Testen Sie die Resilienz mithilfe von Chaos Engineering
Führen Sie regelmäßig Chaos-Experimente in oder nahe an Produktionsumgebungen aus, um zu verstehen, wie Ihr System auf ungünstige Bedingungen reagiert.
Gewünschtes Ergebnis:
Die Ausfallsicherheit der Workload wird regelmäßig durch die Anwendung von Chaos-Engineering in Form von Fehlerinjektionsexperimenten oder einer Injektion unerwarteter Last überprüft. Dazu kommen Tests der Ausfallsicherheit, um das bekannte erwartete Verhalten der Workload während eines Ereignisses zu validieren. Kombinieren Sie Chaos-Engineering mit Tests der Ausfallsicherheit, um sicher zu sein, dass Ihre Workload Komponentenausfällen standhalten und sich von unerwarteten Unterbrechungen erholen kann – mit minimalen oder gar keinen Auswirkungen.
Typische Anti-Muster:
-
Auslegung der Systeme auf Ausfallsicherheit, aber keine Überprüfung, wie die Workload als Ganzes funktioniert, wenn Fehler auftreten.
-
Keine Experimente unter echten Bedingungen und der erwarteten Last.
-
Keine Behandlung der Experimente als Code und fehlendes Aufrechterhalten während des Entwicklungszyklus.
-
Keine Durchführung von Chaos-Experimenten als Teil Ihrer CI/CD-Pipeline und außerhalb von Bereitstellungen.
-
Keine Nutzung früherer Analysen nach Vorfällen bei der Entscheidung über die Fehler, mit denen experimentiert werden soll.
Vorteile der Nutzung dieser bewährten Methode: Durch die Injektion von Fehlern zur Überprüfung der Resilienz Ihrer Workload gewinnen Sie die nötige Zuversicht, dass die Wiederherstellungsverfahren Ihres resilienten Entwurfs im Fall eines realen Fehlers funktionieren.
Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: Mittel
Implementierungsleitfaden
Das Chaos-Engineering bietet Ihren Teams die nötigen Chancen, um auf kontrollierte Weise kontinuierlich reale Störungen (Simulationen) auf Serviceanbieter-, Infrastruktur-, Workload- und Komponentenebene zu injizieren – mit nur minimalen oder gar keinen Auswirkungen auf Ihre Kunden. Ihre Teams können so aus Fehlern lernen und die Resilienz Ihrer Workloads beobachten, messen und verbessern. Darüber hinaus können sie überprüfen, ob Warnungen ausgelöst werden und die Teams über Ereignisse benachrichtigt werden.
Bei kontinuierlicher Ausführung kann das Chaos-Engineering Mängel in Ihren Workloads aufzeigen, die sich negativ auf Verfügbarkeit und Ausführung auswirken könnten, wenn sie nicht behoben werden.
Anmerkung
Beim Chaos-Engineering geht es um das Experimentieren mit einem System, um sich davon zu überzeugen, dass das System in der Produktion auch außergewöhnlichen Bedingungen standhalten kann. – Grundlagen des Chaos-Engineering
Wenn ein System diesen Disruptionen standhalten kann, sollte das Chaos-Experiment weiter als automatisierter Regressionstest ausgeführt werden. Auf diese Weise sollten Chaos-Experimente als Teil Ihres Systementwicklungszyklus (SDLC) und als Teil Ihrer CI/CD-Pipeline durchgeführt werden.
Um sicherzustellen, dass Ihre Workload resilient gegenüber dem Ausfall von Komponenten ist, sollten Sie im Rahmen Ihrer Experimente Ereignisse aus der Praxis injizieren. Experimentieren Sie beispielsweise mit dem Verlust von EC2 Amazon-Instances oder dem Failover der primären RDS Amazon-Datenbank-Instance und stellen Sie sicher, dass Ihre Arbeitslast nicht (oder nur minimal) beeinträchtigt wird. Mit einer Kombination von Komponentenfehlern könnten Sie Ereignisse simulieren, die von einer Disruption in einer Availability Zone verursacht werden könnten.
Bei Fehlern auf Anwendungsebene (wie Abstürzen) können Sie mit Stressfaktoren wie Arbeitsspeicher und Erschöpfung beginnen. CPU
Zur Validierung von Fallback- oder Failover-Mechanismen
Andere Degradierungsmodi führen möglicherweise zu einer reduzierten Funktionalität und zu verzögerten Reaktionen, was eine Disruption Ihrer Services verursachen kann. Bekannte Quellen für diese Degradierung sind eine erhöhte Latenz bei kritischen Services und eine unzuverlässige Netzwerkkommunikation (Verlust von Paketen). Experimente mit diesen Fehlern, einschließlich Netzwerkeffekten wie Latenz, verworfenen Nachrichten und DNS Ausfällen, könnten die Unfähigkeit beinhalten, einen Namen aufzulösen, den DNS Dienst zu erreichen oder Verbindungen zu abhängigen Diensten herzustellen.
Chaos-Engineering-Tools:
AWS Fault Injection Service (AWS FIS) ist ein vollständig verwalteter Dienst zur Durchführung von Fault-Injection-Experimenten, der als Teil Ihrer CD-Pipeline oder außerhalb der Pipeline verwendet werden kann. AWS FIS ist eine gute Wahl für Spieltage mit Chaos Engineering. Es unterstützt die gleichzeitige Einführung von Fehlern bei verschiedenen Ressourcentypen, darunter AmazonEC2, Amazon Elastic Container Service (AmazonECS), Amazon Elastic Kubernetes Service (AmazonEKS) und Amazon. RDS Zu diesen Fehlern gehören die Terminierung von Ressourcen, das Erzwingen von Failovers, Überlastung CPU oder Speicherauslastung, Drosselung, Latenz und Paketverlust. Da es in Amazon CloudWatch Alarms integriert ist, können Sie Stoppbedingungen als Leitplanken einrichten, um ein Experiment rückgängig zu machen, wenn es unerwartete Auswirkungen hat.
AWS Fault Injection Service lässt sich in AWS Ressourcen integrieren, sodass Sie Fault-Injection-Experimente für Ihre Workloads durchführen können.
Es gibt auch verschiedene Drittanbieteroptionen für Fehlerinjektionsexperimente. Dazu gehören Open-Source-Tools wie Chaos Toolkit
Implementierungsschritte
-
Ermitteln Sie die Fehler, mit denen experimentiert werden soll.
Bewerten Sie das Design Ihrer Workload in Bezug auf die Resilienz. Solche Designs (die unter Verwendung der bewährten Methoden des Well-Architected Framework erstellt wurden) berücksichtigen Risiken, die auf kritischen Abhängigkeiten, vergangenen Ereignissen, bekannten Problemen und Compliance-Anforderungen basieren. Listen Sie die einzelnen Elemente des Designs auf, die Resilienz zeigen sollen, und die Fehler, denen es standhalten soll. Weitere Informationen zur Erstellung solcher Listen finden Sie im Whitepaper zur Überprüfung der betrieblichen Bereitschaft, in dem Sie auch erfahren, wie Sie einen Prozess erstellen können, um das Wiederauftreten früherer Vorfälle zu verhindern. Der Prozess zur Analyse der Fehlermodi und -auswirkungen (FMEA) bietet Ihnen ein Framework für die Durchführung einer Analyse von Ausfällen auf Komponentenebene und deren Auswirkungen auf Ihre Arbeitslast. FMEAwird von Adrian Cockcroft in Failure
Modes and Continuous Resilience ausführlicher beschrieben. -
Weisen Sie jedem Fehler eine Priorität zu.
Beginnen Sie mit einer groben Kategorisierung wie „Hoch“, „Mittel“ oder „Niedrig“. Berücksichtigen Sie bei der Festlegung der Priorität die Häufigkeit des Fehlers und die Auswirkungen des Fehlers auf die Workload insgesamt.
Analysieren Sie hinsichtlich der Häufigkeit eines bestimmten Fehlers frühere Daten für die betreffende Workload, wenn verfügbar. Wenn keine Daten verfügbar sind, verwenden Sie Daten zu anderen Workloads, die in einer ähnlichen Umgebung ausgeführt werden.
Bei der Betrachtung der Auswirkungen eines bestimmten Fehlers gilt, dass die Auswirkungen im Allgemeinen umso größer sind, je größer der vom Fehler betroffene Bereich ist. Sie sollten auch das Design und den Zweck der Workload berücksichtigen. Beispielsweise ist für eine Workload, die Daten transformiert und analysiert, der Zugriff auf die Quelldatenspeicher von kritischer Bedeutung. In diesem Fall würden Sie Experimente im Zusammenhang mit Zugriffsfehlern, Zugriffsdrosselungen und Latenzen priorisieren.
Nach Vorfällen durchgeführte Analysen stellen eine gute Datenquelle dar, um Häufigkeit und Auswirkungen von Fehlerarten besser zu verstehen.
Legen Sie anhand der zugewiesenen Priorität die Fehler fest, mit denen zuerst experimentiert werden soll, und die Reihenfolge, in der neue Fehlerinjektionsexperimente entwickelt werden sollen.
-
Für jedes von Ihnen ausgeführte Experiment sollten Sie sich am Schwungrad für Chaos-Engineering und kontinuierliche Resilienz in der folgenden Abbildung orientieren.
Schwungrad für Chaos-Engineering und kontinuierliche Resilienz unter Verwendung der wissenschaftlichen Methode von Adrian Hornsby.
-
Definieren Sie den Steady-State als die messbare Ausgabe einer Workload, die ein normales Verhalten zeigt.
Ihre Workload befindet sich im Steady-State, wenn sie zuverlässig und wie erwartet ausgeführt wird. Daher sollten Sie die Integrität Ihrer Workload überprüfen, bevor Sie den Steady-State definieren. Steady-State bedeutet nicht notwendigerweise, dass sich ein Fehler nicht auf die Workload auswirkt, da ein bestimmter Prozentsatz an Fehlern innerhalb akzeptabler Grenzen liegen könnte. Der Steady-State ist die Basislinie, die Sie während des Experiments beobachten. Diese wird Anomalien aufweisen, wenn Ihre Hypothese, die Sie im nächsten Schritt definieren, nicht die erwarteten Ergebnisse zeigt.
Ein stabiler Zustand eines Zahlungssystems kann beispielsweise als die Verarbeitung von 300 Transaktionen TPS mit einer Erfolgsquote von 99% und einer Umlaufzeit von 500 ms definiert werden.
-
Formulieren Sie eine Hypothese dazu, wie die Workload auf den Fehler reagieren wird.
Eine gute Hypothese basiert darauf, wie die Workload den Fehler voraussichtlich bewältigt, um den Steady-State zu wahren. Die Hypothese besagt, dass bei einem Fehler eines spezifischen Typs das System oder die Workload weiter im Steady-State bleibt, da die Workload mit bestimmten Resilienzmerkmalen entworfen wurde. Der spezifische Fehlertyp und die Fehlerbewältigung sollten in der Hypothese angegeben werden.
Sie können für die Hypothese die folgende Vorlage verwenden (andere Formulierungen sind jedoch auch akzeptabel):
Anmerkung
Wenn
specific faulttritt auf, derworkload nameArbeitslast wirddescribe mitigating controlszu pflegenbusiness or technical metric impact.Beispielsweise:
-
Wenn 20% der Knoten in der EKS Amazon-Knotengruppe abgeschaltet werden, bedient Transaction Create API weiterhin das 99. Perzentil der Anfragen in weniger als 100 ms (Steady State). Die EKS Amazon-Knoten werden innerhalb von fünf Minuten wiederhergestellt, und die Pods werden innerhalb von acht Minuten nach Beginn des Experiments geplant und verarbeiten den Datenverkehr. Warnungen werden innerhalb von drei Minuten ausgelöst.
-
Wenn eine einzelne EC2 Amazon-Instance ausfällt, veranlasst die Elastic Load Balancing-Zustandsprüfung des Bestellsystems, dass Elastic Load Balancing nur Anfragen an die verbleibenden fehlerfreien Instances sendet, während Amazon EC2 Auto Scaling die ausgefallene Instance ersetzt, wodurch ein Anstieg der serverseitigen (5xx) Fehler (Steady State) um weniger als 0,01% aufrechterhalten wird.
-
Wenn die primäre RDS Amazon-Datenbank-Instance ausfällt, führt der Supply-Chain-Datenerfassungs-Workload einen Failover durch und stellt eine Verbindung zur RDS Standby-Amazon-Datenbank-Instance her, um weniger als 1 Minute an Lese- oder Schreibfehlern der Datenbank aufrechtzuerhalten (Steady State).
-
-
Führen Sie das Experiment aus, indem Sie den Fehler injizieren.
Ein Experiment sollte grundsätzlich nicht zu einem Ausfall führen und von der Workload toleriert werden. Wenn Sie wissen, dass die Workload ausfallen wird, sollten Sie das Experiment nicht durchführen. Das Chaos-Engineering sollte verwendet werden, um bekannt-unbekannte oder unbekannt-unbekannte Ereignisse zu untersuchen. Bekannt-unbekannte Ereignisse sind Dinge, derer Sie sich bewusst sind, die Sie aber nicht vollständig verstehen, und unbekannt-unbekannte Ereignisse sind Dinge, derer Sie sich nicht bewusst sind und die Sie auch nicht vollständig verstehen. Wenn Sie Experimente für eine Workload ausführen, von der Sie wissen, dass sie fehlerhaft ist, werden Sie keine neuen Erkenntnisse gewinnen. Ihr Experiment sollte sorgfältig geplant sein, einen klaren Wirkungsumfang besitzen und einen Rollback-Mechanismus besitzen, der bei unerwarteten Störungen angewendet werden kann. Wenn eine sorgfältige Überprüfung zeigt, dass Ihre Workload das Experiment überstehen sollte, können Sie das Experiment starten. Für die Injektion von Fehlern gibt es verschiedene Optionen. Für Workloads in AWS bietet AWS FIS viele vordefinierte Fehlersimulationen, die als Aktionen bezeichnet werden. Sie können auch benutzerdefinierte Aktionen definieren, die AWS FIS unter Verwendung von AWS Systems Manager Dokumenten ausgeführt werden.
Wir raten davon ab, angepasste Skripts für Chaos-Experimente zu verwenden, es sei denn, die Skripts können den aktuellen Zustand der Workload erkennen, können Protokolle ausgeben und stellen Rollback-Mechanismen und Stoppbedingungen bereit, soweit möglich.
Ein effektives Framework oder Toolset, das Chaos-Engineering unterstützt, sollte den aktuellen Status des Experiments nachverfolgen, Protokolle ausgeben und Rollback-Mechanismen bereitstellen, um eine kontrollierte Durchführung des Experiments zu unterstützen. Beginnen Sie mit einem etablierten Service wie AWS FIS diesem, der es Ihnen ermöglicht, Experimente mit einem klar definierten Umfang und Sicherheitsmechanismen durchzuführen, die das Experiment rückgängig machen, wenn das Experiment zu unerwarteten Turbulenzen führt. Weitere Informationen zu einer Vielzahl von Experimenten mit AWS FIS Chaos Engineering finden Sie auch im Lab Resilient and Well-Architected Apps with Chaos Engineering
. Außerdem analysiert AWS Resilience Hub Ihre Workload und erstellt Experimente, die Sie in AWS FIS implementieren und ausführen können. Anmerkung
Sie sollten den Umfang und die Auswirkungen jedes Experiments genau verstehen. Wir empfehlen, Fehler zunächst in einer Nichtproduktionsumgebung zu simulieren, bevor sie in der Produktion ausgeführt werden.
Experimente sollten in der Produktion unter realer Last ausgeführt werden, wobei Canary-Bereitstellungen
verwendet werden sollten, die sowohl eine Steuerung als auch eine experimentelle Systembereitstellung ermöglichen, sofern dies möglich ist. Die Ausführung von Experimenten außerhalb von Spitzenzeiten stellt ein empfehlenswertes Verfahren dar, um potenzielle Auswirkungen zu reduzieren, wenn ein Experiment zum ersten Mal in der Produktion durchgeführt wird. Wenn die Verwendung von tatsächlichem Kunden-Traffic ein zu großes Risiko darstellt, können Sie unter Verwendung der Kontroll- und Experimentbereitstellungen Experimente mit synthetischem Datenverkehr in der Produktionsinfrastruktur durchführen. Wenn ein Experiment nicht in der Produktion ausgeführt werden kann, führen Sie es in einer Präproduktionsumgebung aus, die der Produktionsumgebung so nahe wie möglich ist. Sie müssen einen Integritätsschutz einrichten und überwachen, um sicherzustellen, dass sich das Experiment nicht jenseits akzeptabler Grenzen auf den Datenverkehr in der Produktionsumgebung oder andere Systeme auswirkt. Richten Sie Stoppbedingungen ein, um ein Experiment anhalten zu können, wenn es in einer Integritätsschutz-Metrik einen von Ihnen definierten Schwellenwert erreicht. Diese Metriken sollten die Metrik für den Steady-State der Workload und die Metrik für die Komponenten einschließen, in die Sie den Fehler injizieren. Die synthetische Überwachung (auch als Benutzer-Canary bezeichnet) gehört zu den Metriken, die Sie in der Regel als Benutzer-Proxy einschließen sollten. Stoppbedingungen für AWS FIS werden als Teil der Experimentvorlage unterstützt. Es sind bis zu fünf Stoppbedingungen pro Vorlage möglich.
Zu den Grundsätzen des Chaos-Engineering gehört die Minimierung von Umfang und Auswirkungen des Experiments:
Auch wenn einige kurzfristige negative Auswirkungen zulässig sein sollten, ist der Chaos-Engineer dafür verantwortlich, die Auswirkungen der Experimente zu minimieren und einzudämmen.
Eine Methode für die Überprüfung des Umfangs und der möglichen Auswirkungen besteht darin, das Experiment statt in der Produktionsumgebung zunächst in einer Nichtproduktionsumgebung durchzuführen. Dabei wird überprüft, ob die Schwellenwerte für Stoppbedingungen während des Experiments wie vorgesehen aktiviert werden und ob das Experiment beobachtet werden kann, um Ausnahmen abzufangen.
Wenn Sie Fehlerinjektionsexperimente durchführen, müssen alle verantwortlichen Beteiligten gut informiert sein. Teilen Sie den betroffenen Teams mit, wann die Experimente durchgeführt werden und was zu erwarten ist. Dies können Operations-Teams, die für die Servicezuverlässigkeit verantwortlichen Teams und der Kundensupport sein. Stellen Sie diesen Teams Kommunikationstools bereit, damit sie das Team, das das Experiment durchführt, über nachteilige Auswirkungen informieren können.
Sie müssen nach dem Experiment die Workload und die zugrunde liegenden Systeme wieder in den ursprünglichen, gut funktionierenden Zustand zurückversetzen. Häufig führt das resiliente Design der betreffenden Workload eine Selbstreparatur durch. Einige Fehlerdesigns oder fehlgeschlagenen Experimente können Ihre Workload jedoch in einem nicht erwarteten Fehlerzustand zurücklassen. Nach dem Ende des Experiments müssen Sie dies erkennen und die Workload und die Systeme wiederherstellen können. Mit können AWS FIS Sie innerhalb der Aktionsparameter eine Rollback-Konfiguration (auch Post-Aktion genannt) festlegen. Eine Post-Aktion führt das Ziel in den Zustand zurück, in dem es sich vor Ausführung der Aktion befunden hat. Diese Post-Aktionen sollten unabhängig davon, ob sie automatisiert (z. B. mithilfe AWS FIS) oder manuell ausgeführt werden, Teil eines Playbooks sein, in dem beschrieben wird, wie Fehler erkannt und behandelt werden können.
-
Prüfen Sie die Hypothese.
Unter Grundlagen des Chaos-Engineering
wird die folgende Anleitung für die Verifizierung des Steady-State Ihrer Workload bereitgestellt: Konzentrieren Sie sich auf die messbare Ausgabe des Systems und nicht auf seine internen Attribute. Messungen dieser Ausgabe über einen kurzen Zeitraum stellen einen Proxy für den Steady-State des Systems dar. Der Gesamtdurchsatz, die Fehlerraten und die Latenz-Perzentile des Systems könnten Metriken sein, die das Steady-State-Verhalten beschreiben. Durch die Konzentration auf die Verhaltensmuster des Systems während Experimenten überprüft das Chaos-Engineering, ob das System funktioniert, statt zu versuchen, die Art der Funktion zu validieren.
In unseren beiden Beispielen oben verwenden wir die Steady-State-Metrik einer Erhöhung von weniger als 0,01 % bei serverseitigen Fehlern (5xx) und von weniger als einer Minute, in der Datenbankschreib- und Lesefehler auftreten.
Die 5xx-Fehler stellen eine gute Metrik dar, da sie die Folge des Fehlermodus sind, dem ein Client der Workload direkt unterliegen wird. Die Messung der Datenbankfehler ist als direkte Folge des Fehlers gut als Metrik geeignet, sollte jedoch durch eine Messung der Client-Auswirkungen ergänzt werden, beispielsweise in Form von fehlgeschlagenen Kundenanfragen oder Fehlern im Client. Fügen Sie außerdem einen synthetischen Monitor (auch als User Canary bezeichnet) auf einem beliebigen Workload APIs oder einem Client, auf den der Client URIs direkt zugreift, ein.
-
Verbessern Sie das Workload-Design hinsichtlich der Resilienz.
Wenn der Steady-State nicht bewahrt wurde, untersuchen Sie, wie das Workload-Design verbessert werden könnte, um den Fehler zu bewältigen. Wenden Sie dabei die bewährten Methoden der AWS Well-Architected-Säule „Zuverlässigkeit“ an. Zusätzliche Anleitungen und Ressourcen finden Sie in der AWS Builder's Library
. Dort finden Sie unter anderem Artikel darüber, wie Sie Ihre Zustandsprüfungen verbessern oder Wiederholungen mit Backoff in Ihrem Anwendungscode verwenden können. Führen Sie das Experiment nach der Implementierung dieser Änderungen erneut durch (angezeigt durch die gepunktete Linie im Flywheel für das Chaos-Engineering), um ihre Effektivität zu ermitteln. Wenn der Verifizierungsschritt zeigt, dass die Hypothese zutrifft, befindet sich die Workload im Steady-State und der Zyklus wird fortgesetzt.
-
-
Führen Sie regelmäßig Experimente durch.
Ein Chaos-Experiment ist ein Zyklus. Daher sollten Experimente regelmäßig als Teil des Chaos-Engineering durchgeführt werden. Wenn die Hypothese eines Experiments auf eine Workload zutrifft, sollte das Experiment automatisiert werden, um innerhalb Ihrer CI/CD-Pipeline kontinuierlich als Regression ausgeführt zu werden. Wie das geht, erfahren Sie in diesem Blog zur Durchführung von AWS FIS Experimenten mit AWS CodePipeline
. In diesem Lab zu wiederkehrenden AWS FIS -Experimenten in einer CI/CD-Pipeline können Sie praktische Erfahrungen sammeln. Fehlerinjektionsexperimente sind auch Bestandteil von Gamedays (siehe REL12-BP06 Regelmäßig Spieltage durchführen). Bei Gamedays wird ein Fehler oder Ereignis simuliert, um Systeme, Prozesse und die Reaktionen von Teams zu testen. Dabei sollen die auszuführenden Aktionen vom Team wie im Fall eines außergewöhnlichen Ereignisses tatsächlich ausgeführt werden.
-
Erfassen und speichern Sie die Ergebnisse der Experimente.
Die Ergebnisse von Fehlerinjektionsexperimenten müssen erfasst und gespeichert werden. Erfassen Sie dabei alle notwendigen Daten (z. B. Zeit, Workload und Bedingungen), um die Ergebnisse und Trends von Experimenten später analysieren zu können. Beispiele für Ergebnisse können Screenshots von Dashboards, CSV Dumps aus der Datenbank Ihrer Metrik oder eine handgeschriebene Aufzeichnung von Ereignissen und Beobachtungen aus dem Experiment sein. Die Protokollierung von Experimenten mit AWS FIS kann Teil dieser Datenerfassung sein.
Ressourcen
Zugehörige bewährte Methoden:
Zugehörige Dokumente:
Zugehörige Videos:
Zugehörige Beispiele:
Zugehörige Tools:
