Seite 5: Beispiel eines Chaos-Experiments

Inhaltsverzeichnis

Die Applikation besteht aus mehreren Microservices, die über eine REST-API und eine Service Discovery verbunden sind. Zur Absicherung hält der "Product-Service" einen lokalen Cache des Warenbestands aus dem "Warehouse-Service" vor. Daten aus dem Cache sollen immer dann geliefert werden, wenn der Warehouse-Service nicht innerhalb von 500 Millisekunden antwortet. Erreichen können Entwickler das Verhalten im Umfeld von Java zum Beispiel mit Hystrix oder resilience4j. Dank der Bibliotheken können Anwender einfach und effektiv Fallbacks und weitere Resilience-Pattern implementieren.

Nachfolgend fasst eine Tabellen die wichtigen Infos zusammen, die für ein erfolgreiches Experiment notwendig sind. Jedes Chaos-Experiment erfordert eine detaillierte Planung, beteiligte Personen und notwendige Ressourcen müssen bereitstehen.

Target	Warehouse-Service
Experiment	Latency
Hypothese	Durch die erhöhte Latenz beim Aufruf des Warehouse-Service werden 30 Prozent der Requests aus dem lokalen Cache des Product-Service geliefert.
Blast-Radius	Product- und Warehouse-Service
Vorheriger Status	OK
Status danach	ERROR
Erkenntnisse	Product-Service Fallback schlug fehl und führte zu Exceptions, da der Cache nicht alle Requests beantworten konnte.
(Tabelle: Übersicht über ein Chaos-Experiment)

Wie am Ergebnis des Experiments zu erkennen, hat man zwar das eine oder andere Resilience-Pattern eingesetzt, dennoch kam es zu Fehlern. Diese gilt es nun zu beseitigen und mit der erneuten Durchführung des Experiments zu testen.

Automatisierte Experimente

Es genügt nicht, ein Experiment zu starten und danach nie wieder. Chaos Engineering muss kontinuierlich stattfinden. Systeme ändern sich ständig, neue Versionen gehen in Produktion, Hardware wird ausgetauscht, jemand hat die Firewall-Regeln angepasst oder mal eben den Server neu gestartet.

Die hohe Kunst ist es, die Kultur des Chaos Engineering im Unternehmen und den Köpfen der Mitarbeiter zu platzieren. Netflix hat das gezielt herbeigeführt, in dem sie eine Reihe an Tools – die sogenannte Simian Army – auf die Erzeugnisse ihrer Entwickler losgelassen hat, und das auch noch in Produktion.

Die notwendige Umgebung

Für die ersten Experimente sollte man eine Umgebung wählen, die identisch mit der in Produktion betriebenen ist. Ansonsten erlangt man keine aussagekräftigen Erkenntnisse. Sobald die ersten Schritte getan sind und es zu Verbesserungen kam, kann der Weg weiter in Richtung Produktion gehen, um auch dort die Experimente durchzuführen.

Ziel des Chaos Engineering ist es, dass es in Produktion betrieben wird. Lasttestumgebungen haben eine definierte und kontrollierte Last, die leider nicht der der Produktion entspricht. Kunden benutzen Services nicht nur so, wie Entwickler es sich vorstellen. Sie interagieren oftmals anders mit den Services als erwartet. Diese Last und die dadurch entstehenden Requests sind notwendig, um zu erkennen, ob es Fehler im Design oder im Betrieb der Software gibt.

In deutschen Unternehmen ist die Akzeptanz noch sehr gering, Chaos Engineering auch in Produktion durchzuführen. Der Weg in die Produktion ist trotz automatisierter Deployments aufwendig und langwierig. Solange ein kontinuierliches Deployment in Produktion nicht gegeben ist, muss eine Umgebung gewählt und vorbereitet werden, die der der Produktion am nächsten ist. Wichtig ist, dass dort eine identische Infrastruktur und Deployment-Prozesse vorhanden sind. Chaos Engineering nur in einer Testumgebung ohne eine kontinuierliche Grundlast führt nicht zu den Erkenntnissen und Verbesserungen, die man für die Produktion benötigt. Sollten die Experimente nur in einer Entwicklungs-Stage stattfinden, ist sie im Anschluss viel eher für den Einsatz als Produktion geeignet, als es die dafür vorgesehene Produktionsumgebung ist.