Chaos Engineering: Ein Schritt in Richtung Zuverlässigkeit

Eine Reise hin zu Microservices

IT-Organisationen haben einen massiven Wandel in Bezug auf Mitarbeiter, Prozesse und Technologie vollzogen, um den geschäftlichen Anforderungen gerecht zu werden und beispielsweise eine schnellere Markteinführung zu erreichen. Die Mitarbeiter wurden auf Full Stack umgeschult, die Prozesse wurden von der Wasserfallmethode auf iterative und agile Methoden umgestellt, die Teams wurden linear und DevOps-Praktiken wurden auf die Automatisierung der Softwareentwicklung und -bereitstellung angewendet. Obwohl die monolithische Architektur unabhängig von Erweiterungen oder neuen Funktionen eine logische Modularität ermöglicht, wird sie dennoch als eine Einheit eingesetzt, was die kontinuierliche Bereitstellung mühsam und zeitaufwändig macht. Um diese Herausforderung zu lösen, sind Unternehmen von einer monolithischen Architektur zu einer serviceorientierten Architektur und in den meisten Fällen zu Microservices übergegangen. Der Wechsel zu Microservices hat den Teams geholfen, Anwendungen effizienter, schneller und häufiger zu entwickeln, zu testen und bereitzustellen. Darüber hinaus hat die Einführung von Microservices wichtige Leistungsindikatoren (KPIs) wie die Bereitstellungshäufigkeit und die Vorlaufzeit für Änderungen erheblich verbessert, was dazu beiträgt, dass Funktionen in kürzerer Zeit auf den Markt kommen und das Geschäft fördern.

Technologische Herausforderungen der Microservices-Architektur

IT-Unternehmen, die Microservices eingeführt haben, haben enorme Vorteile gesehen. Allerdings bleiben Herausforderungen bei der Bewältigung der betrieblichen und technischen Komplexität bestehen. Eine Zunahme der Anzahl und gegenseitigen Abhängigkeiten von Microservices kann auch die Anzahl der Ausfallpunkte erhöhen, die sich dann auf die folgenden Metriken auswirken:

• Mittlere Zeit bis zur Lösung (Mean Time To Resolution, MTTR): die durchschnittliche Zeit zwischen dem Beginn eines Vorfalls und seiner Lösung
• Mittlere Zeit zwischen Ausfällen (MTBF): Die durchschnittliche Zeit, die zwischen Ausfällen vergeht.

Diese Metriken messen die Verfügbarkeit von Systemen und werden von den Teams für Systemzuverlässigkeit und Entwicklung verwendet, um Verträge mit Service Level Agreements (SLAs) zu unterstützen. Höhere Systemwiederherstellungszeiten/MTTR und häufige Ausfälle im System/MTBF können sich auf die Systemverfügbarkeit und -zuverlässigkeit auswirken und somit die SLA/SLO (Service Level Agreement/Service Level Objective) Verpflichtungen in den Verträgen erheblich beeinträchtigen.

Einsatz von Chaos Engineering zur Verbesserung der Verfügbarkeit

Das Chaos-Engineering umfasst eine Reihe von Praxisexperimenten, die mit den Systemen durchgeführt werden, um ihre Fähigkeit, turbulenten Bedingungen in der Produktion standzuhalten, zu überprüfen und das Vertrauen in sie zu stärken.Laut einem Bericht von Gremlin¹ aus dem Jahr 2021 hatten 23 % der Teams, die häufig Chaos-Engineering-Projekte durchführten, eine MTTR von weniger als einer Stunde; 60 % hatten eine MTTR von weniger als 12 Stunden.Aus diesem Grund ermöglicht die frühe und häufige Durchführung von Chaosexperimenten im Softwareentwicklungs-Lebenszyklus (SDLC) Folgendes:

• Verbesserte MTTR: In der Nicht-Produktionsumgebung bereitet die Behebung von Fehlern die Teams vor und verbessert ihre Geschwindigkeit bei der Lösung von Vorfällen in Produktionsumgebungen.
• Verbesserte MTBF: In der Nicht-Produktionsumgebung können Ausfälle proaktiv identifiziert und behoben werden, wodurch Ausfälle in der Produktion reduziert werden.

Viele Spitzenunternehmen haben heute die Gewissheit, dass sie durch die Implementierung von Chaos-Experimenten als Teil ihres SDLC über eine beispiellose Verfügbarkeit und Zuverlässigkeit verfügen. Daher bedeutet die Verbesserung von MTBF und MTTR eine hohe Systemverfügbarkeit, ohne von den zugesagten SLAs/SLOs abzuweichen.

Chaos-Tests können Systemschwächen aufdecken

Unternehmen können Chaos-Engineering mit Hilfe einer sechsstufigen Strategie einführen, die in der folgenden Grafik dargestellt ist:

Lassen Sie uns näher auf die sechs oben genannten Schritte eingehen. Wir verwenden dazu eine Microservices-basierte Beispielanwendung für Kinobuchungen. Sie wird in einem Kubernetes-Cluster bei einem öffentlichen Cloud-Anbieter eingesetzt, wie in Abbildung 2 unten dargestellt.

Verschiedene Dienste, wie Sendezeiten, Filmbewertungen, Ticketkauf, Zahlung, E-Mail und SMS, werden in einzelnen Behältern bereitgestellt, jeder verpackt in einem separaten Pod. Die Front-End-Benutzeroberfläche und die Datenbank laufen ebenfalls auf den Pods. 

Schritt 1: Entdeckung

Während dieser Phase müssen die Teams zusammenarbeiten, um die erforderlichen Informationen über eine Anwendung und ihre Umgebung zu erhalten, indem sie:

• Alle Dienste/Komponenten, Funktionen, Berührungspunkte und Abhängigkeiten zwischen Diensten analysieren, einschließlich Upstream-Downstream, unabhängige Dienste, Konfigurationen und Datenspeicher 
• Infrastruktur und Implementierungsansatz erforschen
• Fehlerpunkte für jede Komponente/jeden Dienst identifizieren
• Auswirkungen auf das Geschäft für jeden Fehlerpunkt bestimmen 

Schritt 2: „Steady State“ definieren

In dieser Phase sollten die Teams:

• Das Verhalten der Anwendung im Normalzustand messbar definieren 
• Geschäfts- und Betriebsmetriken messen (z. B. Latenz, Durchsatz, Fehlerrate usw.)
• Für die identifizierten Metriken den akzeptablen Wertebereich markieren 

In der Beispielanwendung für Kinobuchungen (Abbildung 2) ist der Service – Film buchen – eine geschäftskritische Komponente, da er mit der Umsatzgenerierung verbunden ist. In der Regel wird diese Komponente in den ersten Tagen nach dem Kinostart massiv gleichzeitig aufgerufen. Daher wird der Durchsatz (die Fähigkeit, diese Anfragen ohne Beeinträchtigung zu bearbeiten) zur wichtigsten Kennzahl, und das Produktmanagementteam definiert den akzeptablen Durchsatz für den Service für Filmbuchungen als einen Wert zwischen 50 und 65 Anfragen pro Sekunde.

Schritt 3: Eine Hypothese aufstellen

Sobald der Steady-State für die Services definiert ist, bestimmen Sie die Experimente, die injiziert werden sollen, und stellen Hypothesen darüber auf, was schief gehen könnte (z. B. was könnte sich auf den Service, das System und die Kunden auswirken?). Setzen Sie außerdem Prioritäten bei den Experimenten auf der Grundlage der Auswirkungen auf die Kunden und der Häufigkeit des Eintretens.

Beenden wir den Pod, der den Buchfilmservice in der Beispielanwendung ausführt. Wir gehen davon aus, dass Kubernetes die Beendigung automatisch erkennen und einen neuen Pod bereitstellen wird.

Schritt 4: Das Experiment durchführen und die Ergebnisse messen und analysieren 

Fangen Sie an, Experimente in einer Nicht-Produktionsumgebung durchzuführen. Es ist jedoch wichtig zu verstehen, wie sich das System verhält, bevor Sie das Experiment durchführen. Messen Sie die erforderlichen Metriken unter normalen Bedingungen und messen Sie dann dieselben Metriken nach der Durchführung von Experimenten. Wenn es nach der Durchführung des Experiments zu schwerwiegenden Auswirkungen kommt, brechen Sie das Experiment ab und führen den Rollback-Plan aus, um zu einem stabilen Zustand zurückzukehren.

Schritte unten, um ein POD-Kill-Experiment für Buchfilme durchzuführen:

• Wir haben Grafana eingerichtet – ein plattformübergreifendes, quelloffenes Analyse-, Visualisierungs- und Überwachungstool. Überwachen Sie den Durchsatz, die Fehlerrate und die Latenzzeit, bevor Sie das Experiment durchführen, wie in den Abbildungen 5 und 6 hervorgehoben.

• Nutzen Sie das Open-Source-Performance-Tool Apache JMeter, um die gleichzeitige Auslastung des Book Movie-Service für eine bestimmte Dauer zu simulieren.
• Führen Sie das Chaos-Experiment – die Beendigung des Film-buchen-Pods – durch, indem Sie ein beliebiges Chaos-Tool verwenden.
• Beobachten Sie nach dem Experiment den Durchsatz, die Fehlerrate und die Latenz nach dem Experimentieren, wie in den Abbildungen 7 und 8 (in Grafana) hervorgehoben.

• Analysieren Sie die Fehlerrate, den Schwellenwert und den Durchsatz (aufgezeichnet vor und nach dem Experiment), um Abweichungen zu verifizieren 

Die Daten zeigen, dass, wenn der Film-buchen-Pod beendet wird, die Fehlerrate und die Latenz über dem normalen Bereich liegen. Der Durchsatz sinkt, bis Kubernetes die Beendigung erkennt und automatisch einen Pod hochfährt, der den Film-buchen-Dienst enthält. Dieser Fehler muss behoben werden.

Schritt 5: Reparieren und erneut testen

In diesem Fall besteht eine der möglichen Korrekturen darin, die Anzahl der Replikate zu skalieren. Dadurch wird sichergestellt, dass eine bestimmte Anzahl von Pods kontinuierlich läuft. Selbst wenn ein Pod ausfällt, werden die anderen Pods die Anfrage bearbeiten. Beachten Sie, dass nach der Korrektur in der Abbildung unten keine Fehler mehr auftreten. Durchsatz und Latenz sind wie erwartet und liegen deutlich innerhalb des Bereichs. 

Mit der Implementierung von Microservice-resilienten Entwurfsmustern können auch Störungen in der Anwendung behoben werden. Entwickler können ausfallsichere Microservices-Anwendungen erstellen, indem sie Resilience-Muster wie Circuit Breaker, Retry und Timeout verwenden.

Schritt 6: Erhöhen Sie den Aktionsradius iterativ

Sobald das Experiment erfolgreich läuft, wird empfohlen, den Radius des Experiments schrittweise zu vergrößern. In dem obigen Beispiel-Experiment beenden wir zum Beispiel einen Dienst und dann nach und nach einen anderen. Daher müssen Sie zunächst in Staging-Umgebungen experimentieren und dann zur Produktion übergehen.

Bewährte Methoden der Chaostechnik 

• Zielen Sie auf Experimente in einer Vorproduktionsumgebung: Starten Sie Experimente in der Entwicklungs- oder Staging-Umgebung.Nachdem Sie Vertrauen in die untere Umgebung gewonnen und die Auswirkungen der Experimente verstanden haben, führen Sie Experimente in der Produktionsumgebung durch.
  
• Automatisierung nutzen: Beginnen Sie mit einem manuellen Test mit Hilfe von Tools, aber nutzen Sie die Vorteile der Automatisierung, um schnelleres Feedback zu erhalten.
• Kontinuierliche Experimente durchführen: Wenn Sie Vertrauen in die Experimente gewinnen, stellen Sie sicher, dass Chaosexperimente kontinuierlich in der CI/CD-Pipeline ablaufen
• Iterativ den Explosionsradius erhöhen: Konzentrieren Sie sich auf bekannte Experimente und beginnen Sie kleine Experimente (z. B. mit einem Container beginnen, die Netzwerklatenz zwischen zwei Diensten messen usw.)
• Wiederherstellungsplan: Stellen Sie einen Wiederherstellungsplan für jedes Experiment sicher.

Abschließende Gedanken

Um die Zufriedenheit und Bindung der Benutzer in der digitalen Welt zu gewährleisten, müssen Unternehmen bestimmte Faktoren berücksichtigen (Markteinführungszeit, Benutzererfahrung, zuverlässiges System und die Fähigkeit zur schnellen Wiederherstellung), um den Betrieb zu gewährleisten und den Endbenutzern einen Mehrwert zu bieten. Die Einbeziehung von Chaos-Engineering in den SDLC bringt sowohl betriebliche als auch technische Vorteile mit sich, wie z.B. die Vermeidung von Umsatzeinbußen, geringere Wartungskosten, ein verbessertes Störungsmanagement, eine geringere Anzahl negativer Störungen, eine Entlastung des Bereitschaftspersonals sowie ein besseres Verständnis der Systemausfallarten und ein verbessertes Systemdesign.

Aufgrund der zahlreichen Vorteile sollten Unternehmen auf Chaos-Engineering setzen, um die Erstellung zuverlässiger Softwaresysteme zu erleichtern.

Referenzen:

1. Horgan, Aileen.„The State of Chaos Engineering in 2021“ (Der Stand der Chaostechnik im Jahr 2021)Veröffentlicht am 26. Januar 2021.The State of Chaos Engineering in 2021“ (Der Stand der Chaostechnik im Jahr 2021) (gremlin.com)