Zwar gibt es bereits eine Reihe von ähnlichen Failure-Induction-Frameworks wie etwa Netflix’ Chaos Monkey, allerdings ließen sich diese, so erklärt Arjun Shenoy im LinkedIn-Engineering-Blog, nicht ausreichend an die Bedürfnisse des sozialen Netzwerks anpassen. Stattdessen benötigte man ein System, das es nicht nur erlaubt, mehrere Custom-Ausfallszenarien zu überprüfen, sondern das gleichzeitig genug Flexibilität bietet, um über verschiedene Plattformen hinweg zu funktionieren.

Simoorg überprüft Widerstandskraft von Applikationsinfrastrukturen

Genau hierfür wurde Simoorg entwickelt. Das Ziel des in Python geschriebenen Open-Source-Frameworks soll es sein, zu überprüfen, wie sich Cluster in einem Ausfallszenario verhalten:

The main motivation behind the process is to observe how a healthy cluster will respond to a particular failure, or a set of failures.

Daraus sollen sich anschließend verschiedenste Analysen ablesen lassen, etwa mit wie viel Traffic ein Service umgehen kann, bevor er sich auf die Performance auswirkt, wie sich ein Service in einer Low-Latency-Umgebung gegenüber der Nutzung in einer High-Latency-Umgebung verhält oder welche Änderungen sich während einer vollständigen Garbage Collection ergeben.

Ebenso soll Simoorg die Infrastruktur einer Applikation auf ihre Widerstandsfähigkeit testen. Dafür werden Ausfälle erzeugt, die einen oder mehrere Hosts zum Ausschalten zwingen und so einen Neustart der Applikation auslösen. Außerdem lässt sich ein solches Failure-Induction-Framework auch zum Performance-Benchmarking, der Ressourcen-Optimierung sowie zum Stress- und Skalierbarkeits-Testing genutzt werden.

Failure-Induction mit Simoorg

Üblicherweise besteht der Prozess der Failure-Induction aus drei verschiedenen Schritten: den Ausfall herbeiführen, den Cluster im Ausfallszenario überprüfen und den Cluster zu einem „gesunden“ Status zurückzuführen. Je nach genutztem Framework oder Tool unterscheiden sich die Methoden der Failure-Induction und Failure-Reversion. Simoorg unterscheidet sich davon jedoch in mehreren Key-Features, etwa Custom-Failures, konfigurierbaren Einschränkungen oder einer pluggable Architektur.

Insgesamt besteht Simoorg aus verschiedenen Komponenten (siehe Screenshot):

• dem Root-Observer Moirai: zentraler Single-Thread-Prozess, der alle Aktivitäten des Frameworks überwacht
• Atropos: ein individueller Prozess, der sich auf alle Aktivitäten konzentriert, die zu einem bestimmten Service gehören
• HealthCheck: stellt die Stabilität des Clusters und der einzelnen Nodes sicher, bevor der Ausfall ausgelöst wird
• API-Server: dient als Frontend zum Einholen der Details von den einzelnen Observer-Units

Komponenten in Simoorg, Quelle: LinkedIn

Darüber hinaus besteht eine Atropos-Unit ebenfalls aus einzelnen Komponenten, die verschiedene Aufgaben übernehmen (siehe Screenshot):

• Topology
• Scheduler
• Handler
• Logger
• Journal

Atropos-Unit in Simoorg, Quelle: LinkedIn

Mehr Informationen dazu bietet der oben angesprochene Blogpost von Arjun Shenoy. Simoorg steht auf GitHub zur Verfügung, dort finden sich auch zahlreiche weitere nützliche Tipps zur Nutzung sowie die Dokumentation des Simoorg-APIs.

Aufmacherbild: Stethoscope on an electrocardiogram (ECG) chart von Shutterstock / Urheberrecht: piotr_pabijan