Netflix: Resilience konsequent zu Ende gedacht

Keine Angst vor Chaos

Stefan Toth
Keine Angst vor Chaos

© iStock / mbortolino

Netflix gilt als Vorreiter, wenn es darum geht, Fehler nicht nur zu vermeiden, sondern sie als normalen Teil des (System)lebens zu akzeptieren und effektiv zu überstehen. Mit einem Konzert von Tools und Bibliotheken rund um Hystrix, Asgard, Eureka und die Cloud-Infrastruktur von Amazon isoliert Netflix seine Nutzer von Fehlern und bleibt als System stabil. Dabei sind sich die Herren und Damen so sicher, dass sie selbst Hand anlegen und eine Vielzahl unterschiedlicher Fehler im Produktivsystem verursachen – täglich –, um es zu beweisen und im Ernstfall zu können. Dazu gehört Courage und Selbstbewusstsein. Haben sie die?

Fehler sind unvermeidbar. Sie testen Ihre Software auf unterschiedlichen Ebenen, unterziehen sie Reviews, Sie lassen Bug Finder und Metriken auf Ihre Applikationen los und trotzdem: Völlige Bugfreiheit ist illusorisch. Manche Firmen entwickeln mit unterschiedlichen Teams zwei Mal das gleiche System, um dieses Problem zu umgehen, setzen auf unterschiedliche Frameworks und Bibliotheken. Selbst dann bleibt noch die Hardwareseite der Medaille, um die sie sich kümmern müssen. Festplatten, Platinen, Sensoren etc. – alles Fehlerquellen. Müssen Sie Fremdsysteme anbinden oder haben Sie Verteilungsgrenzen in Ihrem System? Glückwunsch! Das Netzwerk hatten wir bisher noch gar nicht auf der Rechnung. Es ist jedoch nicht alleine die schiere Menge an Fehlerquellen, die problematisch ist, sondern auch deren zufällige und nicht vorhersagbare Verteilung.

Es gibt mehrere Strategien, wie Sie trotzdem zuverlässige und verfügbare Systeme bauen können. Eine davon ist besonders effektiv und bietet sozusagen ein zweites Fangnetz: Resilient Design. Wenn Fehler nicht vermieden werden können (oder deren Vermeidung sehr teuer wäre), sollte das System gut damit umgehen können und nicht als Ganzes gefährdet sein. Resilience ist also eine Eigenschaft, die es Systemen erlaubt, Defekte und Fehler zu überstehen, sie zu isolieren, ihre Auswirkungen gering zu halten und sie idealerweise zu korrigieren. Für manche Systeme ist Resilience der einzige Weg zur Ausfallssicherheit, für andere einfach die billigere Alternative zu teuren Simulationen, Analysen und Testumgebungen. Netflix ist ein Pionier des Resilient Designs und setzt neue Maßstäbe, was die Entwicklung für Fehlertoleranz angeht. Sehen wir, warum das so ist, was Netflix genau macht und wie Sie davon profitieren können.

Warum Netflix?

Netflix ist der größte Online-Streaming-Anbieter der Welt. Über zwei Milliarden Stunden Filme und Serien sind für Mitglieder verfügbar (nicht in jedem Land, aber dennoch). Warum wurde Netflix so innovativ, was die Verfügbarkeit angeht? Man bekommt eine erste Idee, wenn man einen Blick auf die Webseite von Netflix wirft: „Netflix-Mitglieder können Serien und Filme schauen – so viele sie wollen, jederzeit, überall, auf fast jedem internetverbundenen Bildschirm“. Eine zentrale Ansage, ein Versprechen und eine Architekturherausforderung zugleich.

Um zu verstehen, wie groß die Herausforderung eigentlich ist, zeigt Abbildung 1 eine topologische Sicht auf Netflix. Die grünen Bereiche zeigen Services von Netflix. Insgesamt sind es über sechshundert verschiedene Services, die jeweils drei bis mehrere hundert Mal installiert sind. Der Übersicht halber zeigt Abbildung 1 diese Redundanz nicht. Die blauen Linien zeigen Abhängigkeiten bzw. Aufrufwege. Greift man auf die Webseite zu, trifft man etwa zwanzig bis dreißig Prozesse im Front Tier, dahinter wird es komplizierter. Insgesamt arbeiten etwa fünfzig bis sechzig Teams an diesem System.

Abb. 1: Netflix: Topologiesicht; Screenshot aus AppDynamics [1]

Abb. 1: Netflix: Topologiesicht; Screenshot aus AppDynamics [1]

Es ist eine gewisse Hürde, ein solches System in einer realistischen Testumgebung nachzubauen, Daten(-verteilungen) und Benutzerverhalten realistisch zu simulieren und dieses System analytisch zu betrachten. Netflix verzichtet trotz allem nicht gänzlich darauf, betrachtet diese Techniken jedoch als Ergänzung. Resilience ist aufgrund der Komplexität ein Erfordernis und in vielen Fällen billiger als Fehlervermeidungsstrategien vor der Auslieferung. Hinzu kommt noch der Zeitaspekt: Netflix möchte innovativ bleiben, neue Features schnell ausliefern und damit den Vorsprung gegenüber der Konkurrenz zumindest halten. Manager sagen dazu gerne Time to Market – bei Netflix heißt es, der schnellste Weg, Code auszuliefern, sei es, gelegentlich Bugs auszuliefern.

Die zentralen Herausforderungen

Verteilte Systeme wie Netflix sind von Fehlerquellen durchsetzt. Festplattenfehler, Stromausfälle, Backup-Generatorausfälle, Netzwerkfehler, Softwarebugs, menschliches Versagen und einiges mehr machen hohe Verfügbarkeit schwierig.

Recht gut verstanden und einfach zu reparieren sind „saubere“ Ausfälle von Instanzen. Gehen etwa durch einen Stromausfall oder einen anderen Fehler einzelne Instanzen verloren, ist der lokale Status zwar ebenfalls verloren, der Fehler ist allerdings schnell entdeckt, und das System kann entsprechend reagieren, etwa, indem der Traffic umgeleitet und eine Ersatzinstanz bereitgestellt wird. Sind Services zustandslos oder wird der Zustand über Caches oder eine Datenbank „geshared“, wird das Problem noch kleiner.

Problematischer sind andere Ausfälle. Wird etwa fehlerhafter Code ausgeliefert, ist ein Service mit all seinen Instanzen betroffen. Die fehlerhafte Funktionalität muss schnell aus dem Verkehr gezogen werden, steht dann dem Benutzer aber nicht zur Verfügung. Schnelle Erkennung von solchen Fehlern und noch schnelleres Rollback sind wichtig, aber schwierig.

Netzwerkfehler isolieren Instanzen vom Rest des Systems, sie sind aber oft weiterhin ansprechbar – zumindest bei partitionstoleranten Systemen, wie es hochskalierbare Webanwendungen meist sind. Dadurch kann der Status inkonsistent werden, und man erhält komplexere Symptome, die eine Wiederherstellung erschweren.

Sich fortpflanzende Fehler stellen ein weiteres, größeres Problem dar. AWS-(Amazon-Web-Services-)Fehler können beispielsweise dazu führen, dass keine neuen Instanzen mehr gestartet werden können. Die Threadpools können nicht mehr aus dem Vollen schöpfen, das Load Balancing wird beeinflusst und reagiert vielleicht fehlerhaft. Kommt dann noch etwas menschliches Versagen ins Spiel, kann auch eine ganze Zone oder gar Region Schaden nehmen. Sich fortpflanzende Fehler zeigen oft verwirrende Symptome und so genannte „byzantinische“ Seiteneffekte.

Bleiben noch Latenzprobleme, die ebenfalls zur herausfordernden Kategorie gehören. Nachdem Services bei diesen Problemen noch antworten, ist die Erkennung und Behandlung schwieriger. Dabei kann eine einzelne latent antwortende Funktionalität das gesamte System gefährden. Bei Netflix ist etwa das API stark bedroht. Es spricht alle anderen (Mid-Tier-)Services an. Dauert eine Operation normalerweise 20 Millisekunden und hat plötzliche Spikes im Sekundenbereich, wird diese Funktionalität schnell alle Ressourcen, Queues und Threads in der API-Schicht binden. Bei mehr als 50 Requests pro Sekunde können alle Request-Threads innerhalb weniger Sekunden blockieren, und das System kollabiert.

Strategien und Techniken

Diesen Problemen setzt Netflix ein ganzes Set an Strategien und Techniken entgegen. Die wichtigsten davon sind die folgenden, die ich im weiteren Verlauf dieses Artikels noch genauer besprechen werde:

  1. Redundanz: Netflix’ Regel: „Everything is built for three“.
  2. Logging und Monitoring: Die Erkennung und Analyse von aufgetretenen oder bevorstehenden Fehlern.
  3. Schnelles Fallback/Rollback/Failover: Erkannte Fehler müssen schnell zu Reaktionen führen.
  4. Fehlerisolierung: Einzelne Fehler oder Latenzen sollen nicht „durchschlagen“.
  5. Empirische Überprüfung der Resilience: Zielgerichtete Einsteuerung von Fehlern in die Produktivumgebung als Test und Übung.

Netflix hat neben den Infrastrukturelementen der Amazon-Cloud, die bereits einige dieser Punkte behandeln, einige Werkzeuge und Frameworks erarbeitet, die mittlerweile zum Großteil Open Source zur Verfügung gestellt wurden. Die berühmtesten Projekte für die genannten Strategien sind Hystrix, Asgard und die Simian Army.

Redundanz

Netflix verteilt alle Applikationen und Infrastrukturkomponenten über mehrere „Zonen“, um bei Ausfällen „Redundanz für alles“ zu haben. Netflix unterteilt seine Datencenter in drei große AWS-Regionen: EU, US-East und US-West. Theoretisch kann der Ausfall einer ganzen Region verkraftet werden, wenn die anderen beiden Regionen entsprechend elastisch hochskaliert werden. Innerhalb der Regionen sind so genannte „Availability Zones“ die nächstkleinere Einheit. Dabei handelt es sich um Datencenter, in denen unabhängige Application-Cluster wohnen („Auto Scaling Groups“, kurz ASGs). Die ASGs sind wiederum aus bis zu 100 Instanzen pro Zone aufgebaut, die über eine Service Registry und Software-Load-Balancing miteinander kommunizieren. Jeder Request eines Nutzers hat eine Präferenz für eine Zone (innerhalb einer Region), der nächste Request ist aber völlig ungebunden und kann die Zone theoretisch wechseln.

Die einzelnen Instanzen sind weitestgehend zustandslos, der eventuell vorhandene Zustand wird jedoch in einer Netflix-Erweiterung von Memcached (EVCache) gehalten und über mehrere Zonen verteilt, natürlich über mindestens drei. Auch die Daten, die Netflix hauptsächlich in Cassandra-Clustern ablegt, sind redundant über mindestens drei Zonen gestreut – für global relevante Daten auch über Zonen unterschiedlicher Regionen. Über Cassandra-Mechanismen wie Local Write Quorums und Hinted Handoffs ist die sichere Ablage von Daten gelöst. Nächtliche Vergleichs- und Reparaturarbeiten sorgen für Konsistenz.

Der Ausfall einer einzelnen Instanz wird nun bereits durch die ASGs, also die automatisch skalierenden Application-Cluster, abgefangen und ausgeglichen. Als fehlerhaft erkannte Instanzen werden von der Service Discovery ausgeschlossen. Bis dahin überspringen Software-Load-Balancer die fehlerhafte Instanz. Auto Scaling sorgt nach dem Trafficstop für neue Instanzen, um das System stabil zu halten.

Der Ausfall ganzer Zonen ist ähnlich verkraftbar, weil alle Daten und Funktionen über mindestens drei Zonen gestreut sind. Komplizierter wird es trotzdem. Kurzfristig ist eine Zone immer mit etwa ein Drittel Overhead ausgelegt, kann also einen Zonenausfall gemeinsam mit einer anderen Zone abfangen. Muss mehr Traffic abgefangen werden, setzt ein Throttling-Mechanismus ein, der den Zugriff auf die Zone begrenzt und sie so schützt. Nach dem Auto Scale der enthaltenen Application-Cluster wird wieder der gesamte Traffic angenommen. Dieses Vorgehen verhindert einen Totalausfall und sorgt dafür, dass einzelne Services lediglich sehr kurz für einige wenige Benutzer nicht verfügbar sind. Daneben muss das Routing sauber sein, um nicht zu viel Traffic zwischen den Zonen zu verursachen und in die fehlerhafte Zone tatsächlich keinen Traffic mehr zu leiten. Netflix beobachtet solche Ausfälle in Regionen und reagiert proaktiv. Sind Zonenausfälle in US-East zu beklagen, wird vorsichtshalber in US-West hochskaliert, um im Ernstfall schnell reagieren zu können.

Logging und Monitoring

Für die eben besprochene proaktive Reaktion müssen Fehler erst einmal bekannt sein. Für die spätere Analyse des Fehlergrunds und die daraus abgeleiteten Maßnahmen zur Verbesserung müssen die Zustände und Aktionen nachvollziehbar und analysierbar sein. Auch Resilience-Werkzeuge wie die weiter unten besprochene Simian Army müssen über den Systemzustand Bescheid wissen. Absichtlich ins System eingeschleuste Fehler sollten nicht sowieso schon kränkelnde Systemteile destabilisieren. Im Resilient Design sind Logging und Monitoring also zentral – Netflix bezeichnet sich manchmal als Logging-Service, der zufällig auch Filme abspielen kann.

Die drei wichtigsten Tools, die Netflix hierfür einsetzt, sind Atlas, Chronos und Hystrix. Altlas ist ein Cloud-weites Monitoringframework mit Millionen von Metriken rund um Performance, Fehler- und Time-out-Raten. Es operiert unterhalb der Hystrix-Ebene auf Services, Instanzen, der JVM und Tomcat. Aus Atlas bedienen sich weitere Monitoringtools wie Mogul und Vector.

Chronos ist ein Netflix-Projekt, das noch nicht Open Source bereitgestellt wurde. Es zeichnet alle Änderungen an der Systemumgebung oder -konfiguration auf und soll formale Change-Prozesse so weit wie möglich obsolet machen. Chronos nimmt über eine REST-Schnittstelle Events an und erlaubt es, Menschen und Maschinen nach den Aktivitäten der letzten Stunde, nach speziellen Deployments oder sonstigen (Zustands-)Änderungen zu fragen. Über die Integration zu anderen Netflix-Werkzeugen werden die meisten Änderungen an der Umgebung automatisch an Chronos reportet. Prinzipiell soll jedes Event, das den Zustand des Systems ändert, aufgezeichnet werden. Dazu zählen z. B. Deployments, Änderungen in der Runtime Configuration, AB-Tests, Securityevents und andere automatisierte Aktionen.

Hystrix ist eine Bibliothek für Latenz- und Fehlertoleranz. Der „Fault Tolerance Layer“ von Netflix besteht hauptsächlich aus Hystrix – es ist das Tool für Resilience. Hystrix isoliert Servicezugriffe voneinander, stoppt sich fortpflanzende Fehler, sorgt auch bei Latenz für schnelle Fehler und koordiniert Fallbacks (mehr dazu in den folgenden beiden Abschnitten 3 und 4). Hierfür wrappt Hystrix die Aufrufe fremder Services und verfügt über alle wichtigen Informationen für ein feingranulares Monitoring. Die Daten werden wie beim grundlegenderen Atlas auf einem Dashboard gesammelt und mit geringer Latenz live aktualisiert. Abbildung 2 zeigt ein annotiertes Beispiel-Dashboard für eine ASG.

Abb. 2: Beispiel eines Hystrix Dashboards [2]

Abb. 2: Beispiel eines Hystrix Dashboards [2]

Mit Turbine, einem weiteren Netflix-Projekt, lassen sich die Daten mehrerer ASGs aggregieren. So können mehrere hundert Server live getrackt werden. Die Anzeigelatenz steigt dabei von Sekundenbruchteilen für einzelne Server auf etwa 1–2 Sekunden. Netflix weiß also recht schnell, wenn es brennt und wo es brennt.

Schnelles Fallback/Rollback/Failover

Ebenso wichtig wie die Erkennung von Fehlern und ungewolltem Verhalten ist die Reaktion darauf. Bei Ausfällen muss ein automatischer Failover erfolgen, Zonen und Regionen müssen sich gegenseitig auffangen können. Hier hilft die Redundanz und die Infrastruktur von Amazon (siehe Punkt 1 – Redundanz). Bei Ausfällen ist der Failover schnell, bei Problemen mit der Latenz hilft wiederum Hystrix: Netzwerkzugriffe werden mit aggressiven Time-outs versehen, und das Circuit Breaker Pattern [3] sorgt dafür, dass langsam oder fehlerhaft reagierende Services beim nächsten Mal gar nicht erst aufgerufen werden, sondern über den „Short Circuit“ sofort in einen Fallback münden. Das spart Zeit.

Um auch nach einem Failover sofort wieder schnelle Antwortzeiten zu garantieren, ist ein aufgewärmter Ersatzcache nötig. Den hält Netflix mit EVCache vor – einer Erweiterung von memcached und spymemcached, die mit dem Netflix-Ökosystem und speziell mit der Service-Registry von Netflix (Eureka) zusammenarbeitet. EVCache steht für Ephemeral Volatile Cache, beschreibt also einen kurzlebigen Cache, dessen Daten jederzeit verschwinden können. Es handelt sich um einen verteilten Key-Value-Store, der über mehrere AWS-Availability-Zonen operieren kann. Beim Start-up registrieren sich EVCache-Instanzen bei Eureka. Clients verbinden sich dann per Namen mit den registrierten Cacheinstanzen. Im Falle eines Multi-Zone-Deployments erfolgen Lesezugriffe immer in einer Zone, Schreib- oder Löschzugriffe immer in allen Zonen. Kommt es zum Failover, findet der Client in einer „fremden“ Zone einen warmen Cache vor. Auch wenn der zonenübergreifende Zugriff etwas Latenz verursacht, ist das meist um Größenordnungen schneller als ein Zugriff auf Cassandra, S3 oder SimpleDB selbst. EVCache unterstützt also tatkräftig beim schnellen Failover bzw. der Verschleierung des Fehlers gegenüber dem Benutzer.

Das Wegbrechen einzelner Instanzen oder Zonen ist mit den genannten Techniken schnell auszugleichen. Problematisch wird es jedoch, wenn neue oder veränderte Funktionalität in Produktion gebracht wird und dort für Ausfälle oder fehlerhafte Antworten sorgt. Die Funktionalität muss schnell von allen Instanzen verschwinden und durch eine nicht schadhafte Version ersetzt werden, am schnellsten natürlich in einem Rollback zur Vorversion. Die Deployment-Kette um Tools wie Asgard hilft Netflix hier (Abb. 3) und orientiert sich am Ansatz der Blue-Green Deployments.

Abb. 3: Build und Deployment bei Netflix

Abb. 3: Build und Deployment bei Netflix

Der Build- und Deploymentprozess von Netflix wird in der Mitte gezeigt, seine Beschreibung rechts. Neben Standardwerkzeugen wie Jenkins setzt Netflix auf eine eigene Image-Bakery (Aminator). Dort werden die Applikationen auf Maschinen-Images für die Amazon-Cloud installiert, bevor sie deployt werden. Das Deployment selbst wird durch Asgard gesteuert und kann so in einem einzelnen Schritt erfolgen. Auf der linken Seite von Abbildung 3 sehen Sie die Lebenslinie der alten Version der Funktionalität. Sie lebt nicht nur bis zum Deployment der neuen Version, sondern ist auch danach noch aktiv. In einer Cloud-Umgebung können Sie unbegrenzt Maschinen erzeugen. Netflix instanziiert die neue Serviceversion also zusätzlich und leitet lediglich den Traffic teilweise um. Oft werden nur einzelne Knoten mit der neuen Version live geschaltet – so genannte „Canaries“. Mit Werkzeugen wie Hystrix oder Servo überwacht Netflix nun beide produktive Versionen und protokolliert unterschiedliches Verhalten oder Fehler. Bei Fehlern oder stark verschlechterten Performanz- und Stabilitätseigenschaften wird der neue Service automatisch aus dem Verkehr gezogen – und zwar genau so wie bei einem Failover. Der Traffic wird einfach zu den alten Instanzen zurück geleitet, die Instanz(en) der neuen Serviceversion aus der Service-Discovery ausgeschlossen. Dieses Vorgehen ist zwar ressourcenintensiver, aber sehr effizient im Sinne der Resilience. Nutzer sind sehr schnell von fehlerhaften Services abgeschnitten und können das System wie gewohnt benutzen.

Fehlerisolierung

Abhängigkeiten zwischen Services machen Systeme kompliziert. Wie man in Abbildung 1 sehen kann, ist das bei Netflix auch nicht anders. Im Sinne der Resilience sollten Fehler in einem Service nicht zu anderen Services durchschlagen bzw. sollten sich Abhängigkeiten zu unterschiedlichen Services nicht gegenseitig beeinflussen. Es ist deshalb wichtig, Aufrufe unterschiedlicher Services in unterschiedliche Threads auszulagern. Aufgrund der schwer durchschaubaren Komplexität beim Schachteln von Threads und Responses hat Netflix RxJava entwickelt: eine Java-Portierung von ReactiveX aus dem Microsoft-Umfeld. Grob gesprochen handelt es sich dabei um ein asynchrones Kommunikationsmodell, in dem über Events kommuniziert wird. Beobachtete Event- und Datenströme können dabei explizit geschlossen werden, Eventempfänger wissen also, wann sich weiteres Warten auf Events nicht mehr lohnt. RxJava erlaubt Netflix eine sehr lose, aber effiziente Kopplung von Services.

Die bevorzugt über RxJava abgebildeten Serviceabhängigkeiten werden durch Hystrix gewrappt. Hystrix zeichnet nicht nur Informationen für das Monitoring auf und sorgt für (schnelle) Fallbacks im Fehlerfall, es sorgt vor allem auch für die Isolierung von Abhängigkeiten. Aufrufe werden in Threads oder tryable Semaphores ausgelagert, und es werden so genannte „Bulkheads“ eingezogen. Um zu verhindern, dass fehlerhaft oder langsam antwortende Services binnen Sekunden alle Request-Threads auf Clientseite binden, werden Requests einem eigenen Threadpool je Serviceabhängigkeit zugeordnet. Ist dieser gesättigt, wird eine Exception geworfen und ein Fallback ausgelöst, andere Threadpools (bzw. Serviceaufrufe) sind davon nicht betroffen. Die genaue Funktionsweise inkl. Flow-Chart finden Sie hier.

Empirische Überprüfung der Resilience

Die bisher besprochenen Techniken helfen beim Resilient Design. Wie wissen Sie aber, dass Sie mit Ihren Bemühungen erfolgreich sind? Wie im Abschnitt „Warum Netflix?“ beschrieben, ist Testen für Netflix impraktikabel, was ROI und Time to Market neuer Features betrifft. Stattdessen hat man sich entschieden, Resilience am echten System zu beweisen – dort, wo es darauf ankommt. Dazu gehört eine ordentliche Portion Selbstbewusstsein, die sich Netflix Stück für Stück erarbeitet hat. Mittlerweile gibt es eine ganze Abteilung, die sich mit dem „Chaos-Engineering“ beschäftigt, also dem kontrollierten Einschleusen von Fehlern und Latenzen. Zyniker würden Netflix vielleicht raten, einfach auf eine unzuverlässigere Infrastruktur umzuziehen, um sich diese Chaosabteilung zu sparen. Das, was Netflix salopp als „Chaos“ bezeichnet, hat jedoch durchaus Ordnung und Methode.

Die fehlerverursachenden Applikationen sind allesamt „Monkeys“ und gehören der Simian Army an – dem wohl berühmtesten Ausschnitt des Netflix-Ökosystems. Tabelle 1 zeigt einen Überblick über einige bei Netflix eingesetzten Monkeys.

Tabelle 1: Die wichtigsten Affen der Simian Army

Tabelle 1: Die wichtigsten Affen der Simian Army

Die unteren drei Monkeys aus Tabelle 1 informieren die Serviceeigentümer per Mail über ihre Erkenntnisse. Teams werden so für nicht konforme oder überlastete Services sowie unsauberes Ressourcenmanagement in die Verantwortung gezogen und können aus diesen Problemen lernen. Chaos Monkey, Gorilla, Kong und Latency Monkey intervenieren unabhängig von Serviceeigenschaften. Sie sind das unberechenbare Element, um für den Ernstfall zu üben.

Chaos Monkey war der erste Vertreter seiner Gattung und simuliert den wohl häufigsten Fehler in der typischen Cloud-Umgebung: den Ausfall einer virtuellen Instanz. Über Asgard und Edda findet Chaos Monkey die momentan laufenden Serviceinstanzen. Jede Stunde wählt er einige davon zufällig aus und terminiert sie über AWS-APIs. In der Chaos-Monkey-Konfiguration können Teams die Wahrscheinlichkeiten einstellen, mit der ein bestimmter Service getroffen wird – auch auf 0 Prozent, falls nötig (Opt-out).

Chaos Gorilla funktioniert ähnlich. Um Zonenfehler zu simulieren, werden zwei Modes angeboten. Neben dem totalen Zonenausfall können auch Netzwerkpartitionen entstehen, die ein Grüppchen von Instanzen weiterhin funktionsfähig, aber vom Restsystem isoliert belassen. Der Einsatz von Chaos Gorilla ist eine ungleich höhere Herausforderung und sorgt für massive Probleme bei der Lastverteilung und Recovery. Die Ausführung ist deshalb nicht automatisiert, sondern erfolgt manuell.

Chaos Kong kümmert sich um den Ausfall einer ganzen AWS-Region. Ein entsprechender Ausfall ist allein schon eine Herausforderung in der Simulation, und selbst Netflix lässt dieses Biest nicht allzu oft aus dem Käfig. Alle paar Monate ist es aber so weit. Generell werden die „Ausfalls“-Monkeys in der Reihenfolge ausgeführt, wie sie auch hier beschrieben sind. Zur Einführung dieser Monkeys konnten sich Teams zu Beginn freiwillig für das Chaos melden (Opt-in). Später wurde dann ein Blacklisting erstellt, wie beim Chaos Monkey beschrieben.

Der Latency Monkey stellt schlussendlich sicher, dass Netflix Services mit Problemen umgehen können, die keinen klaren Ausfall darstellen. Dafür wird REST-Calls eine zufällige Latenz zugeschlagen, oder es werden Fehler zurückgegeben (Status 500 beispielsweise). Werden sehr lange Latenzzeiten zugeschlagen, kann auch der Ausfall eines Service simuliert werden, ohne die entsprechenden Instanzen tatsächlich terminieren zu müssen. Der Service kann so auch nur für bestimmte Clients nicht verfügbar gemacht werden, während er für andere Clients weiterhin normal ansprechbar bleibt – schön vor allem beim Test der Robustheit von neu deployten Services. Durch den Einsatz dieses Monkeys hat Netflix vor allem in den Bereichen Start-up Resilience, Bootstraping, Cache-Warm-up und der Koordinierung von Abhängigkeiten gelernt.

Insgesamt hilft die Simian Army Netflix dabei, die Probleme rund um Resilience zu verstehen und Teams schrittweise zu einem entsprechenden Design zu führen. Die Monkeys werden prinzipiell zwischen 9:00 und 15:00 Uhr (Serviceeignerzeit) ausgeführt und rigorosem Monitoring unterzogen. So werden Fehler zu Zeiten provoziert, in denen viele Entwickler reagieren und gegensteuern können, die Lernerfahrung wird ins System zurückgetragen, und man ist auf echte Ausfälle zu eventuell ungünstigeren Zeiten besser vorbereitet. Dass diese Ausfälle tatsächlich passieren, zeigt die Geschichte. Netflix musste am 21. April 2011 mit großen Ausfällen in der AWS-Region US-East umgehen, zu Weihnachten 2012 fiel das Elastic Load Balancing von Amazon aus, und letztes Jahr (2014) mussten wegen Wartungsarbeiten 218 Cassandra-Knoten heruntergefahren werden.

Sie wollen das auch?

Netflix baut mit der eigenen Software auf der Cloud-Infrastruktur von Amazon auf. Viele der entwickelten Frameworkkomponenten entlässt Netflix als Open-Source-Software (OSS) in die Freiheit. So können Projekte auf viele Errungenschaften zurückgreifen (Abb. 4).

Abb. 4: Netflix OSS als PaaS

Abb. 4: Netflix OSS als PaaS

Die in diesem Artikel erwähnten Projekte Chaos Monkey, Janitor Monkey, Conformity Monkey, Hystrix, Turbine, Asgard, EVCache, Edda, Eureka, Aminator und RxJava sind alle bereits verfügbar, weitere Bibliotheken und Werkzeuge sollen folgen.

Selbst wenn Sie nicht auf Basis von AWS arbeiten, bleiben einige Möglichkeiten. Spring Cloud Netflix ermöglicht die Netflix-OSS-Integration über Spring Boot. Einige Firmen lassen Netflix OSS in Docker laufen. Mittlerweile gibt es mit ZeroToDocker auch eine offizielle Netflix-Variante, um Teile des OSS-Stacks in Docker laufen zu lassen und so zumindest auszuprobieren. Momentan findet man leider nur Asgard, Edda und Eureka von den hier erwähnten Tools, es sollen jedoch weitere Projekte folgen.

Sie können also einiges vom Klassenbesten abschreiben und die Ideen in Ihre eigene Lösung einfließen lassen. Denken Sie nur daran, dass technologische Lösungen alleine wenig helfen. Teamverantwortung bis ins Deployment und eine Kultur, in der Lernen wichtiger als Schuldzuweisung ist, sind wichtige Säulen von Resilience, die in diesem Artikel nicht beleuchtet werden konnten.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Verwandte Themen:

Geschrieben von
Stefan Toth
Stefan Toth
Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs "Vorgehensmuster für Softwarearchitektur". Kontakt: st@embarc.de
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Keine Angst vor Chaos"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
trackback

[…] Neben diesen Beiträgen habe ich auch einen ausführlichen JavaMagazin-Artikel zu Verfügbarkeit und Resilience bei Netflix geschrieben der mittlerweile online verfügbar ist: Keine Angst vor Chaos […]