View a markdown version of this page

Implementierung von Chaos Engineering auf AWS - AWS Präskriptive Leitlinien

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.

Implementierung von Chaos Engineering auf AWS

Chaos Engineering ist Teil der Evaluierungs- und Testphase des AWS Resilienz-Lebenszyklus, wie in der folgenden Abbildung dargestellt. Verteilte Anwendungen können nicht isoliert von anderen Anwendungen oder Clients betrieben werden. Wir empfehlen Ihnen daher, den gesamten Resilienz-Lebenszyklus zu überprüfen. Verteilte Anwendungen ändern sich ständig, da sich das Netzwerk weiterentwickelt, Upstream- und Downstream-Anwendungen Veränderungen unterliegen und die Client-Nutzung sich im Laufe der Zeit ändert.

Fünf wichtige Phasen im Lebenszyklus der AWS Resilienz.

Um zu verstehen, wie sich diese Änderungen an Ihrer Anwendung auf deren Ausfallsicherheit auswirken können, sollten Sie Chaos Engineering zu einem Teil Ihres day-to-day Betriebs machen. Sie können Chaosexperimente auf unterschiedliche Weise implementieren:

  • Ad hoc — Sie können Chaosexperimente als einmalige Experimente durchführen, um ein bestimmtes Problem oder eine bestimmte Frage zu lösen.

  • Chaos-Spieltage — Dabei handelt es sich um strukturierte und wiederkehrende Ereignisse, mit denen die Zuverlässigkeit und Belastbarkeit einer Anwendung überprüft werden soll. Der Zweck eines Chaos-Spieltages besteht darin, potenzielle Resilienzprobleme oder -mängel bei Personen, Prozessen und Technologien zu identifizieren und die Prozesse und Verfahren zur Identifizierung, Minderung und Reaktion auf Vorfälle zu üben.

  • Chaos-Pipeline — Kontinuierliche Integration und kontinuierliche Lieferung (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDPipeline, die zu zunehmenden Paketverlusten für nachgeschaltete Komponenten führt). Dieses Experiment wird dreimal ausgeführt und es dauert jeweils 5 Minuten, bis es abgeschlossen ist. Der Paketverlust steigt mit jedem Durchlauf von 10 Prozent auf 20 bis 30 Prozent, und das Experiment dauert insgesamt 15 Minuten. Wenn Sie 100 parallel Bereitstellungen haben, müssen Sie 1500 Minuten warten, bis ein einzelnes Experiment abgeschlossen ist. Wenn Sie 10 Experimente durchführen müssen, wären die Auswirkungen für Ihre Entwickler unerträglich. Im großen Maßstab benötigt Chaos Engineering eine eigene Pipeline, die es Ihnen ermöglicht, Experimente parallel zu Ihrem Software Development Lifecycle (SDLC) -Prozess durchzuführen.

  • Bereitstellungen auf den Kanarischen Inseln — Die Kanarischen Inseln bieten eine Testumgebung für Chaos-Experimente. Indem Sie einen kleinen Teil des Datenverkehrs an einen Canary-Dienst weiterleiten oder Methoden wie Verkehrsspiegelung oder -wiedergabe verwenden, können Sie neue Infrastruktur- oder Codeänderungen verifizieren, ohne dass dies Auswirkungen auf Ihr stabiles Produktionssystem hat. Sie können Experimente gegen den Kanarienvogel durchführen und bei Bedarf Fehler einschleusen, da Sie den Umfang der Auswirkungen auf den Endbenutzer einschränken können.

  • Geplante Experimente — Sie können Experimente planen, um vorhersehbare Wiederherstellungsmechanismen für Ihre Anwendung zu überprüfen. Verwenden Sie geplante Experimente, um allgemein bekannte Ereignisse wiederzugeben und zu erfassen, wie sich Ihre Systeme nach Ereignissen wie dem Beenden einer EC2 Instance hinter einer automatischen Skalierungsgruppe, dem Entfernen eines Kubernetes-Pods oder dem Löschen einer Amazon ECS-Aufgabe erholen können.