© Excellent backgrounds/Shutterstock.com
Netflix: Resilience konsequent zu Ende gedacht

Keine Angst vor Chaos


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 Resi­lient 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.

toth_1.tif_fmt1.jpgAbb. 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 hoch skalierbare 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 (s. Artikel von Uwe Friedrichsen auf S. 33).

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 b...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang