- Ingenieure für verteilte Systeme lernen in vielen Fällen durch die Narben, die durch Fehler im realen Betrieb entstehen
- Dieser Artikel wurde geschrieben, damit neue Ingenieure solche Narben nicht selbst durchmachen müssen
Verteilte Systeme fallen häufig aus
- Anders als in vielen anderen Bereichen des Software Engineerings ist die Ausfallwahrscheinlichkeit bei verteilten Systemen hoch. Insbesondere ist die Wahrscheinlichkeit partieller Ausfälle hoch.
- Systemingenieure ohne Erfahrung mit verteiltem Rechnen kommen oft mit Ideen wie „Schreib einfach auf zwei Systeme“ oder „Wiederhole den Schreibvorgang einfach, bis er erfolgreich ist“
- Netzwerksysteme fallen häufiger aus als eine einzelne Maschine, und diese Ausfälle sind oft partiell
- Einer der Schreibvorgänge kann erfolgreich sein und der andere fehlschlagen. Wie erhält man nun eine konsistente Sicht auf die Daten? Über solche partiellen Ausfälle nachzudenken ist deutlich schwieriger
- Probleme können auftreten, wenn ein Switch ausfällt, ein Leader wegen Garbage Collection „verschwindet“ oder ein Socket-Schreibvorgang erfolgreich aussieht, in Wirklichkeit aber fehlschlägt. Das Lesen aus lokalem Speicher ist viel zuverlässiger als das Lesen über mehrere Switches hinweg
- Man muss „für Ausfälle designen“
Das Schreiben robuster verteilter Systeme ist teurer
- Der Aufbau einer robusten verteilten Lösung kostet mehr als eine Lösung auf einer einzelnen Maschine.
- Virtuelle Maschinen und Cloud-Technologien machen das Engineering verteilter Systeme günstiger, aber es bleibt trotzdem teuer.
- Simulationen sind nützlich, können aber nicht alle Probleme lösen, die in realen verteilten Umgebungen auftreten.
Robuste Open-Source-Systeme für verteilte Umgebungen sind selten
- Die Kosten, viele Maschinen über lange Zeit zu betreiben, belasten die Open-Source-Community.
- Menschen, die Open-Source-Code als Hobby schreiben, verfügen oft nicht über die finanziellen Ressourcen, um viele Probleme verteilter Systeme zu untersuchen oder zu lösen.
- Einige Probleme werden von Ingenieuren in Unternehmen gelöst, aber deren Prioritäten stimmen nicht immer überein.
Koordination ist sehr schwierig. Man sollte sie möglichst vermeiden
- Der Kern horizontaler Skalierbarkeit ist Unabhängigkeit. Kommunikation und Konsens zwischen Maschinen sollten minimiert werden.
- Jedes Mal, wenn zwei Maschinen sich auf etwas einigen müssen, wird die Implementierung des Dienstes schwieriger.
- Der Paxos-Algorithmus ist extrem schwer zu implementieren.
Wenn ein Problem in den Speicher passt, ist es vermutlich trivial
- Für Ingenieure verteilter Systeme gelten Probleme, die auf eine einzelne Maschine beschränkt sind, als einfach.
- Wenn sich die Daten ein paar Switches entfernt befinden, ist es schwieriger, sie schnell zu verarbeiten.
„Langsamkeit“ ist das schwierigste Problem
- „Langsamkeit“ kann bedeuten, dass eines oder mehrere der Systeme, die eine Benutzeranfrage ausführen, langsam sind.
- Partielle Ausfälle tauchen in Graphen nicht auf, und bis sie offensichtlich werden, ist es oft schwer, die für die Problemlösung nötigen Ressourcen zu bekommen.
Man muss systemweit Backpressure implementieren
- Backpressure bedeutet, dass das bereitstellende System dem anfragenden System Fehler signalisiert und das anfragende System einen Weg hat, mit diesen Fehlern umzugehen.
- Ohne einen Backpressure-Mechanismus kommt es mit hoher Wahrscheinlichkeit zu Kettenausfällen oder unbeabsichtigtem Nachrichtenverlust.
Man muss Wege finden, partiell verfügbar zu sein
- Gemeint ist die Fähigkeit, selbst dann noch einige Ergebnisse zurückzugeben, wenn Teile des Systems ausfallen.
- Ein Suchsystem kann zum Beispiel die bis dahin gesammelten Ergebnisse zurückgeben, wenn es nicht schafft, innerhalb einer bestimmten Zeit alle Dokumente zu durchsuchen.
Metriken sind der einzige Weg, die Arbeit zu erledigen
- Das Bereitstellen von Metriken ist der einzige Weg, um zu verstehen, wie ein System tatsächlich funktioniert.
- Logdateien sind nützlich, lügen aber oft. Erfolgslogs werden in den meisten Fällen nicht geschrieben, weil sie redundant sind.
Man sollte Perzentile statt Durchschnittswerte verwenden
- Perzentile sind genauer und nützlicher als Durchschnittswerte. Durchschnittswerte führen oft zu falschen Entscheidungen.
Man sollte lernen, Kapazitäten abzuschätzen
- Es ist wichtig zu wissen, wie viele Maschinen für eine Aufgabe benötigt werden.
- Häufig macht man Überschlagsrechnungen auf dem leeren Blatt, etwa um auszurechnen, wie viele Tweet-IDs im Speicher gehalten werden können.
Feature Flags sind ein Weg, Infrastruktur auszurollen
- Feature Flags sind eine gängige Methode, um neue Funktionen in ein System auszurollen.
- Mit Feature Flags gewinnt man Vertrauen in ein Projekt und senkt die Kosten eines Fehlschlags.
Man sollte den ID-Raum klug wählen
- Der ID-Raum eines Systems prägt die Struktur des Systems.
- Die Tweet-IDs der Twitter API sind zum Beispiel einfache 64-Bit-Zahlen, die nicht mit anderen Daten verknüpft sind.
Man sollte Datenlokalität ausnutzen
- Es ist effizienter, Verarbeitung und Caching von Daten nahe am persistenten Speicher zu halten.
- Das Netzwerk ist anfälliger für Ausfälle und Latenzen als eine Pointer-Dereferenzierung oder
fread(3).
Es ist schlecht, gecachte Daten zurück in persistenten Speicher zu schreiben
- Dieses Problem tritt in vielen Systemen auf. Besonders häufig sieht man es in Systemen, die von Menschen mit wenig Erfahrung in verteilten Systemen entworfen wurden.
Computer können mehr leisten, als man denkt
- Gerade von weniger erfahrenen Praktikern kursieren viele falsche Vorstellungen über die Leistungsfähigkeit von Computern.
- Moderne Webserver können Tausende von Anfragen in wenigen hundert Millisekunden verarbeiten.
Man sollte das CAP-Theorem nutzen, um Systeme zu kritisieren
- Das CAP-Theorem ist nichts, womit man ein System baut. Es ist jedoch nützlich, um das Design verteilter Systeme kritisch zu beurteilen.
Man sollte Services herauslösen
- Services bezeichnen verteilte Systeme, die Logik auf höherer Ebene enthalten als Speichersysteme.
- Das Herauslösen von Services lässt sich schneller und einfacher deployen als das Erstellen von Bibliotheken.
Zusammenfassung von GN⁺
- Engineering für verteilte Systeme unterscheidet sich von anderen Bereichen des Software Engineerings durch die hohe Ausfallwahrscheinlichkeit und partielle Ausfälle.
- Das Schreiben robuster verteilter Systeme ist teurer und in der Open-Source-Community selten.
- Es ist wichtig, Konzepte wie Koordination, Datenlokalität, Backpressure und partielle Verfügbarkeit zu verstehen und umzusetzen.
- Durch den Einsatz von Metriken und Perzentilen, Feature Flags und einer klugen Wahl des ID-Raums lassen sich Effizienz und Stabilität von Systemen verbessern.
- Es ist sinnvoll, das CAP-Theorem zur Kritik von Systemen zu nutzen und bei Bedarf Services herauszulösen.
1 Kommentare
Hacker-News-Kommentar
Das CALM-Prinzip (Consistency as Logical Monotonicity) ist leichter zu verstehen als CAP und ein grundlegenderes Ergebnis
Exactly-once-Zustellung ist unmöglich; man muss sich entweder für At-most-once- oder At-least-once-Zustellung entscheiden
Guter Artikel. Er ist zwar 8 Jahre alt, aber vieles darin ist noch immer gültig
Links zu früheren Diskussionen:
Die praktische und realistische Erklärung gefällt mir. Es gibt keine Buzzwords wie „Microservices“
Als ich bei Lookout arbeitete, stellte Jeff Hodges diesen Essay vor
Ich habe mit dem Autor dieses Textes zusammengearbeitet
Seit 2013 hat sich vieles verändert