#KI-Werkstatt

Der Betrieb muss aufrecht erhalten bleiben, auch wenn Teile nicht mehr richtig funktionieren. Wenn beispielsweise der Paymentservice eines Online Shops nicht mehr funktioniert, muss der Kunde dennoch in der Lage sein, sich einzuloggen, Produkte zu suchen, sie in seinen Warenkorb zu legen und nachher zu Bestellen.“  

Jeder CTO/CIO

Resilienz – Eine sichere Fahrt auch im Sturm 

Diese Forderung an Softwaresysteme wird als Resilienz, als Widerstandsfähigkeit und Fehlertoleranz gegen Störungen oder Teilausfälle bezeichnet.  

Beim Betrieb von Softwaresystemen, wie zum Beispiel einem großen Onlineportal, geht man davon aus, dass es keine fehlerfreie Software und keinen störungsfreien Betrieb gibt. Jede Software hat Codepassagen in sich, die in bestimmten Konstellationen unerwünscht reagiert. Zudem kann kein Betrieb von Serversystemen einen absolut unterbrechungsfreien Betrieb aller Komponenten ohne Fluktuationen oder Ausfällen garantieren.  

Um diesen widerstandsfähigen Betrieb sicherzustellen, gibt es eine Reihe von Maßnahmen und Werkzeugen. Es gibt zum Beispiel Softwarehüllen, mit denen man Softwarekomponenten (Microservices) ummantelt, um sie vor Ausfällen anderer Komponenten zu schützen. Es gibt fachliche Kompensationen für nicht funktionierende Softwarekomponenten. Man kann zum Beispiel eine Bestellung auch ohne Bezahlung auslösen und den Bezahlvorgang nachlagern, sobald der Paymentservice wieder verfügbar ist.  

Dennoch weiß man nie, was für Probleme im System noch schlummern nur um auf eine unglückliche Kombination von Zufällen zu wartet, um Chaos zu stiften. Um möglichst viele dieser Situationen geregelt und sicher an die Oberfläche zu befördern gibt es das von Netflix initiierte Vorgehensmodell des Chaos Engineerings.  

Chaos Engineering – Die Ausnahme zur Regel machen 

Das von Netflix entwickelte Vorgehensmodell und die dazugehörigen Tools dienen dazu, in gesicherter Art und Weise ein System derart zu stören, dass ein potentielles Chaos zu Tage tritt, ohne in einer Katastrophe zu enden. Im Kern geht es darum, einzelne Teile des Systems zufällig auszuwählen und hart zu beenden. Je nachdem, was beendet werden soll, gibt es sogenannte Monkeys. Der einfache Chaos Monkey wählt zum Beispiel Softwarekomponenten aus (Instanzen von Microservices) und beendet sie. Chaos Gorillas fahren hingegen ein komplettes Rechenzentrum herunter. Eine komplette Liste aller Monkeys findet man bei Wikipedia. Natürlich wird hierbei der Impact Radius so geregelt, dass der laufende Betrieb weiterhin sichergestellt wird.  

Killer-Bot – der KI Monkey unter den Chaos Monkeys 

Das Problem mit den Chaos Monkeys ist, dass sie ihre Ziele zufällig und isoliert auswählen. Man weiß also immer noch nicht, ob eine geschickt gesetzte Kombination von Ausfällen oder Schwächungen sich nicht zu einer Katastrophe aufschaukeln können. Was geschieht zum Beispiel, wenn der Order Service eines Online Shops mehr CPU und Speicher bekommt, damit er noch schneller arbeiten kann, der Paymentservice aber gleichzeitig ausgebremst wird? Läuft der Order Service voll? Sprengt er Batch – Queues? Solche „Chaos Vektoren“ findet man nicht zufällig. Die muss man suchen. Hier kommt der Killer-Bot ins Spiel. Er wählt seine Ziele nicht zufällig aus, sondern sucht und bohrt sich genau in die Schwachstellen des Systems. Damit er diese Schwachstellen und unguten Konstellationen findet, hat er eine KI in sich, die kontinuierlich dazulernt. Hierbei wird die Theorie rund um die Bellman Gleichung und das Reinforcement Learning genutzt, also die gleiche Mathematik, die AlphaGo nutzt um die weltbesten Go Spieler zu schlagen. 

Für uns stehen die unguten Kombinationen von „Kleinigkeiten“ im Fokus: „Hier ein wenig mehr CPU dort ein bisschen schlechtere Netzwerkverbindung“. Die Aktionen, die der Killer-Bot ausführt, sind also keine Totalausfälle einzelner Komponenten, sondern nur das Schwächen und Stärken von Ressourcen innerhalb normaler Parameter. Dazu halten wir das System unter kontinuierlicher Last, indem wir die üblichen Geschäftsvorfälle (Use Cases) automatisch und kontinuierlich ausführen. Der Killer-Bot verändert einzelne Ressourcen und misst die Reaktionen. Dadurch lernt er die Schwächen des Systems kennen und findet so die möglichen Wege in problematische Situationen. Dabei erzeugt er im Hintergrund ein Storybook, das dazu genutzt werden kann, dass die Schwachstellen später geschlossen werden können. 

Wenn man den Killer-Bot kontinuierlich laufen lässt, findet man schon zur Entwicklungszeit die unbeachteten Schwachstellen und vergrößert die Resilienz der gesamten Applikation.


Abbildung 1: Ein mögliches „Werk“ des Killer-Bot für ein zu klein dimensioniertes Kubernetes Cluster

Jetzt teilen auf:

5 Comments

  1. Olaf 29. Januar 2019 at 21:19 - Reply

    Traue keinem ausgedachtem Zitat, besonders nicht, wenn Wahrenkorb mit ‚h‘ geschrieben wird ;-)

  2. Johannes Höhne 31. Januar 2019 at 9:40 - Reply

    Die Evolution brachte die Menschheit zur Intelligenz. Evolution ist nur eine lange Kette von Schreibfehlern. Ich bin dafür den dass wir ab heute den Wahrenkorb mit H schreiben und beobachten, was passiert. :)

  3. Alex Nek 4. Februar 2019 at 21:15 - Reply

    Interessante Idee, ich bin fasziniert wie viel Wert Sie auf den System Test legen. Wie viel Aufwand ist es das Projekt für ein anderes System anzupassen?

    • Johannes Höhne 5. Februar 2019 at 8:40 - Reply

      Hallo
      Wenn das System in einem Kubernetes Cluster läuft und es gute automatische Integrationstests gibt, ist die Anpassung nicht sehr groß. Wir haben eine API – Komponente gebaut, die als µ Service mit in das Cluster deployed wird und so dem Killer Bot die Möglichkeit gibt mit dem System zu „arbeiten“

  4. Johannes Höhne 16. April 2019 at 12:20 - Reply

Jetzt kommentieren