Warum verteilen? Die Fallacies of Distributed Computing

Was ein System zu einem verteilten System macht

Ein verteiltes System ist eine Menge von Programmen auf verschiedenen Computern, die durch das Senden von Nachrichten über ein Netzwerk zusammenarbeiten, um etwas bereitzustellen, das Nutzer als einen einzigen Dienst wahrnehmen. Ihre Essensliefer-App ist eines: Das Smartphone, die Bestell- und Zahlungsservices des Unternehmens, das Tablet des Restaurants, das Smartphone des Kuriers und ein Kartenzahlungsabwickler wirken alle an einer einzigen Bestellung mit. Kapitel 5 hat Stile beschrieben, die als eine Einheit deployt werden (Monolithen); in diesem Kapitel geht es um Stile, deren Teile separat deployt werden und über das Netzwerk kommunizieren.

Leslie Lamport, der mehr als jeder andere dazu beigetragen hat, das Gebiet auf ein mathematisches Fundament zu stellen, fasste seine wesentliche Schwierigkeit in einer internen E-Mail vom Mai 1987 zusammen: Ein verteiltes System ist eines, in dem der Ausfall eines Computers, von dessen Existenz Sie nicht einmal wussten, Ihren eigenen Computer unbrauchbar machen kann. Der Witz funktioniert, weil er wahr ist. Sobald ein System von Rechnern abhängt, die es weder kontrolliert noch sieht, tritt eine ganze Klasse von Ausfällen auf, die innerhalb eines Prozesses schlicht nicht vorkommen können.

Deshalb ist Verteilung eine Entscheidung mit einem Preis, kein Zeichen von Reife. Der Rest dieses Abschnitts legt die Gründe dar, die den Preis rechtfertigen, die falschen Annahmen, die dazu führen, dass man ihn unterschätzt, und einen Weg, einen Teil davon zu berechnen, bevor Sie zahlen.

Warum überhaupt verteilen

Es gibt eine Handvoll berechtigter Gründe, ein System auf Prozesse und Rechner aufzuteilen. Jeder ist ein Qualitätsmerkmal aus Kapitel 2, das eine einzelne Deployment-Einheit ab einer gewissen Größe nur schwer liefern kann. Für jeden gibt es außerdem einen günstigeren Teilersatz innerhalb eines Monolithen, und wer gut architektiert, prüft zuerst diesen Ersatz.

Aus der Tabelle folgen zwei Beobachtungen. Erstens sind die stärksten Gründe oft organisatorischer Natur: Unabhängige Deploybarkeit und Teamautonomie zählen am meisten, wenn viele Teams an einem Produkt arbeiten; deshalb taucht das Gesetz von Conway (Kapitel 3) in diesem Kapitel immer wieder auf. Zweitens ist Verteilung selten eine Frage von alles oder nichts. Viele erfolgreiche Systeme sind ein modularer Monolith plus zwei oder drei separate Services, die jeweils aus einem bestimmten, benannten Grund abgespalten wurden.

Teilausfall: das grundlegende Problem

Innerhalb eines Prozesses kehrt ein Funktionsaufruf entweder zurück, oder der ganze Prozess stirbt mit ihm. Über ein Netzwerk gibt es ein drittes Ergebnis, und es ändert alles: den Teilausfall, bei dem einige Teile des Systems funktionieren, während andere ausgefallen, langsam oder nicht erreichbar sind. Schlimmer noch: Der Aufrufer kann oft nicht erkennen, welcher Fall vorliegt.

Nehmen Sie den Bestellservice, der den Zahlungsservice bittet, £24,50 zu autorisieren. Kommt vor dem Timeout keine Antwort, weiß der Bestellservice nicht, ob die Anfrage unterwegs verloren ging, ob der Zahlungsservice vor oder nach der Belastung der Karte abstürzte oder hängen blieb, oder ob die Karte belastet wurde und nur die Antwort verloren ging. Aus Sicht des Aufrufers sehen alle drei Fälle gleich aus.

Die praktischen Folgen prägen jedes verteilte Design. Eine Wiederholung könnte den Kunden doppelt belasten; deshalb müssen Operationen, die wiederholt werden können, gefahrlos wiederholbar sein. Diese Eigenschaft heißt Idempotenz und wird meist erreicht, indem jede Anfrage einen eindeutigen Schlüssel erhält, den sich der Empfänger merkt. Eine langsame Abhängigkeit ist oft schlimmer als eine tote, weil Aufrufer weiter warten und Threads und Verbindungen blockieren; wird ein Service langsam, gehen seinen Aufrufern die Ressourcen aus, und sie werden ihrerseits langsam: ein kaskadierender Ausfall. Und weil ein Netzwerk so zerfallen kann, dass zwei Gruppen von Rechnern einander nicht erreichen, während beide weiterlaufen, können Daten, die an beiden Orten gehalten werden, auseinanderlaufen: das Thema des CAP-Abschnitts später in diesem Kapitel.

Eine globale Uhr gibt es ebenfalls nicht. Die Uhr jedes Rechners driftet und wird separat korrigiert, sodass sich Zeitstempel zweier Services nicht mit völliger Sicherheit vergleichen lassen und „Was ist zuerst passiert?“ eine schwierige Frage sein kann. Lamports Artikel von 1978 über Zeit und Uhren in verteilten Systemen zeigte, wie man Ereignisse ordnet, ohne sich auf physische Uhren zu verlassen; für Architekturfachleute lautet die Lehre einfach, Korrektheit nicht auf den Vergleich von Uhrzeiten verschiedener Rechner zu bauen.

Die acht Fallacies of Distributed Computing

Die Fallacies of Distributed Computing sind acht Annahmen, die Neulinge bei verteilten Systemen treffen; alle sind falsch, und alle verursachen früher oder später Ärger. Die Liste stammt von Sun Microsystems: L Peter Deutsch stellte 1994 sieben davon zusammen, aufbauend auf vier, die Kollegen wie Bill Joy bereits notiert hatten, und James Gosling, der Schöpfer von Java, fügte um 1997 die achte hinzu. Drei Jahrzehnte später beschreibt jeder Punkt noch immer irgendwo einen echten Ausfall in dieser Woche.

Was Verteilung kostet

Jeder Grund für eine Verteilung wird mit derselben Währung bezahlt. Latenz ist der erste Kostenpunkt. Ein Funktionsaufruf innerhalb eines Prozesses dauert Nanosekunden; ein Netzwerk-Roundtrip zwischen Rechnern im selben Rechenzentrum dauert typischerweise einige hundert Mikrosekunden bis zu einer Millisekunde oder mehr, noch vor jeder Serialisierung oder Arbeit. Zwischen Kontinenten setzt die Physik die Untergrenze: Licht bewegt sich in Glasfaser mit rund 200.000 km pro Sekunde, sodass ein Roundtrip von London nach New York (etwa 5600 km pro Richtung) nicht weniger als etwa 56 ms dauern kann. Die Rechnung zur Tail-Latenz aus Kapitel 2 gilt für jeden Hop.

Observability ist der zweite. In einem Monolithen zeigt ein Stacktrace die ganze Geschichte einer fehlgeschlagenen Anfrage. In einem verteilten System ist die Geschichte über die Logs vieler Services auf vielen Rechnern verstreut. Observability (Beobachtbarkeit), die Fähigkeit, aus den Ausgaben eines Systems zu verstehen, was es tut, muss von vornherein eingeplant werden: Korrelations-IDs, die bei jedem Aufruf weitergegeben werden, zentralisierte Logs, Metriken pro Service und Distributed Tracing (Kapitel 9).

Konsistenz ist der dritte. Eine einzelne Datenbanktransaktion kann eine Bestellung und ihre Zahlung atomar aktualisieren. Liegen Bestellung und Zahlung in verschiedenen Services mit verschiedenen Datenbanken, gibt es keine gemeinsame Transaktion; das System muss eine Zeitspanne hinnehmen, in der beide nicht übereinstimmen, und dafür sorgen, dass sie konvergieren. Spätere Abschnitte behandeln die Werkzeuge: Konsistenzmodelle sowie Sagas und das Outbox-Muster.

Betriebsaufwand ist der vierte und der am häufigsten unterschätzte. Jeder Service braucht eine Build-Pipeline, ein Deployment, Konfiguration, Secrets, Monitoring, Alarme, Kapazitätsplanung, Sicherheitspatches und jemanden in Bereitschaft. Auch das Testen ändert sich: Eine Änderung ist nur dann sicher, wenn jeder Consumer ihrer Schnittstelle weiterhin funktioniert, und das erfordert Contract Tests und abwärtskompatible Änderungen. Diese Kosten sind ungefähr proportional zur Zahl der deploybaren Einheiten; deshalb kommt es auf die Zahl der Services an.

Nachgerechnet: synchrone Ketten

Der günstigste Moment, um festzustellen, dass ein verteiltes Design zu fragil oder zu langsam ist, ist auf dem Papier. Das Werkzeug ist die Reihenregel aus Kapitel 2: Braucht eine Anfrage jede Komponente einer Kette, ist die Verfügbarkeit der Kette das Produkt der Verfügbarkeiten der Komponenten, und ihre Latenz ist ungefähr die Summe ihrer Latenzen.

Das Architekturquantum, noch einmal betrachtet

Kapitel 5 hat das Architekturquantum eingeführt: ein unabhängig deploybarer Teil mit hoher funktionaler Kohäsion, einschließlich seiner Daten, für den ein einziger Satz von Architekturmerkmalen gilt (Architekturstile, Muster und Taktiken). In Software Architecture: The Hard Parts (2021) schärfen Ford, Richards, Sadalage und Dehghani die Idee mit zwei Arten von Kopplung. Statische Kopplung ist das, was vorhanden sein muss, damit ein Teil deployt werden und laufen kann: sein Code, Bibliotheken, Datenbank und Infrastruktur. Dynamische Kopplung beschreibt, wie Teile zur Laufzeit voneinander abhängen: ob sie sich synchron oder asynchron aufrufen und wie sie sich koordinieren und konsistent bleiben.

Das ausgearbeitete Beispiel zeigt, warum die dynamische Seite zählt. Für die Dauer eines synchronen Aufrufs kann der Aufrufer seine Arbeit nur abschließen, wenn der Aufgerufene läuft und schnell ist; die beiden sind betrieblich aneinandergebunden, und ihre Verfügbarkeit und Latenz verbinden sich wie oben berechnet. Fünf separat deployte Services in einer synchronen Kette sind fünf Deployment-Einheiten, doch für die Verfügbarkeit von Bestellen verhalten sie sich wie eine fragile Einheit. Diese Abhängigkeit davon, dass die Gegenseite im selben Moment verfügbar ist, heißt zeitliche Kopplung. Asynchrones Messaging beseitigt einen Großteil davon: Legt der Bestellservice eine Nachricht in eine dauerhafte Queue, kann der Zahlungsservice eine Minute lang ausfallen und danach aufholen, und der Kunde erhält trotzdem eine Bestellnummer. Der Preis ist, dass der Kunde nicht sofort eine endgültige Antwort erhält, was ebenso eine Produktentscheidung wie eine technische ist.

Das ist die tiefste Lehre dieses Abschnitts. Service-Grenzen zu ziehen ist die Hälfte des Designs; zu entscheiden, welche Interaktionen synchron sein müssen, und diese Menge klein zu halten, ist die andere Hälfte.