- Da Ausfälle in Microservices- und Cloud-Umgebungen unvermeidlich sind, sollte die Systemresilienz durch Chaos Engineering im Vorfeld gestärkt werden
- Chaos Toolkit und Chaos Monkey werden jeweils als leistungsstarke Testwerkzeuge für Ausfälle in allgemeinen sowie auf Java (Spring Boot) spezialisierten Umgebungen eingesetzt
- Durch Experimente auf Basis von Kubernetes und Istio lassen sich verschiedene realistische Ausfallszenarien wie Netzwerklatenz, Service-Unterbrechungen oder regionale Ausfälle simulieren
- Durch die Integration in die CI/CD-Pipeline kann Chaos Engineering die Reaktionsfähigkeit auf Störungen bereits vor der Produktion automatisiert verifizieren
- Im Kern geht es nicht um „Zerstörung“, sondern um den „Aufbau von Vertrauen“, wobei eine Strategie empfohlen wird, klein zu beginnen und den Grad des Chaos schrittweise zu erhöhen
Chaos Engineering für Microservices
Was ist Chaos Engineering?
- Chaos Engineering ist eine Methodik, bei der reale Ausfälle simuliert werden, um Schwachstellen eines Systems frühzeitig zu erkennen und zu verbessern
- Beispiele für wichtige Simulationen:
- Ausfall einer Region oder eines Rechenzentrums
- Netzwerklatenz zwischen Services
- CPU-Überlastung und I/O-Ausfälle
- Nichtverfügbarkeit abhängiger Services
- Dateisystemfehler
- Ziel: Wiederherstellungszeit verkürzen, Verfügbarkeit erhöhen und Auswirkungen auf Nutzer minimieren, bevor Störungen auftreten
Lebenszyklus von Chaos-Engineering-Experimenten
- Durch ein strukturiertes Experimentverfahren wird ein zyklischer Prozess aus Planung → Ausführung → Beobachtung → Verbesserung angewendet
- Kontinuierlicher experimentbasierter Betrieb zur systematischen Steigerung der Zuverlässigkeit
Chaos Toolkit vs. Chaos Monkey
-
Einsatzbereich
- Chaos Toolkit : Ein allgemeines Framework für Chaos-Experimente, das auf verschiedenen Plattformen und in unterschiedlichen Umgebungen eingesetzt werden kann
- Chaos Monkey (nur für Spring Boot) : Ein Tool zur Ausfallsimulation, das speziell für Java-Spring-Boot-Anwendungen gedacht ist
-
Konfiguration
- Chaos Toolkit : Experimentdefinition über eine deklarative Konfiguration auf Basis von JSON/YAML
- Chaos Monkey : Konfiguration über die Datei
application.yml und die Integration mit Spring Boot Actuator
-
Unterstützte Sprachen und Umgebungen
- Chaos Toolkit : Unterstützt Multi-Language- und Multi-Plattform-Umgebungen (Node.js, Java, Kubernetes usw.)
- Chaos Monkey : Speziell für Anwendungen auf Basis von Java (Spring Boot)
-
Unterstützte Ausfallarten
- Chaos Toolkit : Unterstützt eine breite Palette an Ausfallexperimenten wie Netzwerkfehler, Pod-Beendigung, CPU-/Speicher-Stress und benutzerdefinierte Fehler
- Chaos Monkey : Latenz (Latency), Ausnahmen (Exceptions), Service-Abbruch (KillApp) und andere Fehlerinjektionen auf Anwendungsebene
-
Integrierbare Systeme
- Chaos Toolkit : Kann mit Kubernetes, Istio, Azure, Prometheus usw. integriert werden
- Chaos Monkey : Direkte Integration mit der Spring Boot Actuator API für interne Spring-Komponenten
Empfohlene Einsatzszenarien
- Chaos Toolkit
- Kubernetes-basierte Deployment-Umgebungen
- Multi-Cloud- oder Multi-Language-Services
- Beim Aufbau komplexer Ausfallszenarien
- Chaos Monkey
- Java-basierte Spring-Boot-Apps
- Ausnahme-/Latenztests auf Methodenebene
- Wenn eine einfache und integrierte Lösung bevorzugt wird
Praxisbeispiele mit Chaos Toolkit (Java/Node.js/Kubernetes)
Experimente in Kubernetes-Umgebungen
- Pod-Beendigungs-Experiment: Resilienzprüfung mit
pod-kill
- Regionale Latenzexperimente: Injektion von Netzwerklatenz in einen virtuellen Istio-Service
- Ressourcenerschöpfung: Erzwingen von CPU-/Speicherauslastung
- Simulation eines DB-Ausfalls: Test der Reaktion auf Störungen abhängiger Services
- Netzwerkpartitionierung: Experimente zur Unterbrechung der Kommunikation zwischen Services
- Zeitbasierte Störungen: Fehlerinjektion während Verkehrsspitzen
Latenzinjektion mit Istio
- Injektion von Netzwerklatenz auf der Service-Mesh-Ebene
- Steuerung von Latenz und Fehlerrate über die Istio-Konfiguration
Berichtserstellung und Analyse
- Zusammenfassung der Experimentergebnisse mit dem Befehl
chaos report
- Interpretation der Ergebnisse:
- Normalzustand bleibt erhalten → Resilienz ist gegeben
- Anomalie erkannt → Analyse von Logs und Monitoring erforderlich
- Kaskadierende Störungen → Einführung eines Circuit Breakers und Refactoring erwägen
Chaos Monkey in Spring Boot
- Überwachte Ziele:
@Controller, @Service, @Repository, @RestController
- Injektierbare Störungen:
- Latency Assault: künstliche Verzögerung
- Exception Assault: Auslösen von Ausnahmen
- KillApp Assault: vollständiger Abbruch der Anwendung
Ausführung
- Aktivierung des Profils
chaos-monkey in application.yml
- Dynamische Steuerung über die Spring Boot Actuator API
Chaos Engineering in Node.js
Einsatz von Chaos Monkey für Node.js
- Installation einer Chaos-Monkey-Bibliothek eines Drittanbieters
- Funktionen:
- Latenzinjektion
- Auslösen von Ausnahmen
- Simulation von Netzwerkstörungen
Beispiel für den Einsatz von Chaos Toolkit
- Experimentkonfiguration im JSON-Format
- Beispiel: Injektion einer Verzögerung von 200 ms in eine bestimmte Node.js-API
Integration von Chaos in die CI/CD-Pipeline
Ziel der Integration
- Automatisierte Resilienzprüfung vor dem Deployment
- Identifikation von Performance-Engpässen
- Verbesserung der MTTR (Mean Time to Recovery)
- Automatisiertes Rollback ohne manuelle Eingriffe
Beispiel für die Integration mit GitHub Actions
- Automatische Ausführung von Experimenten bei Code-Commits
- Durchführung von Experimenten nach Installation des Chaos Toolkit
- Deployment-Abbruch bei fehlgeschlagenem Health Check
Best Practices für Chaos-Engineering-Experimente
- 1. Eine Hypothese für den Normalzustand aufstellen: Klare Definition dessen, was als gesunder Systemzustand gilt
- 2. Mit Experimenten niedriger Intensität beginnen: 100 ms Latenz → schrittweise verstärken
- 3. Monitoring unbedingt integrieren: Echtzeitbeobachtung mit Prometheus, Grafana usw.
- 4. Automatisches Rollback einrichten: Mechanismen für schnelle Wiederherstellung bei Fehlschlägen schaffen
- 5. Umfang schrittweise erweitern: Experimente von Service-Ebene auf Cluster-Ebene ausweiten
Fazit
- Chaos Engineering ist keine Strategie, um Systeme zu zerstören, sondern um Vertrauen aufzubauen
- In Java, Node.js, Kubernetes und Istio kann mit kleinen Experimenten begonnen und schrittweise erweitert werden
- Mit Tools wie Chaos Toolkit und Chaos Monkey lassen sich reale Ausfallsituationen sicher simulieren
- Durch Integration und Automatisierung in CI/CD lässt sich eine stabile Betriebsumgebung frühzeitig absichern
Referenzen
1 Kommentare
Als ich den Begriff Chaos Engineering hörte, dachte ich kurz, es gehe um das Backend unserer Firma, das ich geschrieben habe;