Knoten, Kanten, Richtungen
Eine Anfrage als Weg in einem Graphen
Jedes Komponente, die eine Anfrage berührt, ist ein Knoten: Client, DNS-Resolver, CDN-Edge, Reverse Proxy, Backend-Replik, Datenbank, Cache.
Jede Verbindung zwischen zwei Knoten ist eine gerichtete Kante: Anfragen fließen vorwärts, Antworten fließen zurück. Die Vorwärtskante stellt eine offene TCP-Verbindung plus das darüberliegende Protokoll dar.
Eine einzelne Anfrage ist ein Pfad durch diesen Graphen. Die gesamte Arbeit, die das System leistet, um die Anfrage zu beantworten, entspricht der Summe der Arbeit an jedem Knoten plus der Latenz jeder Kante.
Warum ist das wichtig? Sobald man den Graphen zeichnet, werden Eigenschaften sichtbar, die im Code unsichtbar sind:
- Hop-Anzahl: die Anzahl der Kanten im Pfad. Jeder Hop fügt Latenz hinzu (Netzwerk-Roundtrip + Knotenverarbeitung). Weniger Hops = niedrigerer Latenz-Untergrenzwert.
- Einlaufgrad: wie viele Kanten auf einen Knoten zeigen. Ein hoher Einlaufgrad bedeutet, dass der Knoten Anfragen von vielen Quellen erhält und sich skalieren oder schützen muss.
- Auslaufgrad: wie viele Kanten von einem Knoten ausgehen. Ein hoher Auslaufgrad bedeutet, dass der Knoten von vielen nachgelagerten Diensten abhängt und viele Ausfallmöglichkeiten hat.
- Scheitelknoten (Cut Vertex): ein einzelner Knoten, dessen Entfernung den Graphen trennt. Ein Reverse Proxy ohne Peer ist ein Scheitelknoten; seine Entfernung entfernt den gesamten Zugriff auf seine Ursprünge.
Wo sich Verkehr konzentriert
Fan-In = Konzentration
Der Eingrad eines Knotens = Anzahl der Kanten, die auf ihn zeigen. In einem Anfragegraph = Anzahl der upstream-Quellen, die Anfragen senden.
Fan-in-Muster: viele Clients -> ein CDN; viele CDN-Edges -> wenige Origin-Proxy; viele Proxy -> weniger Backend-Replikate; viele Backends -> eine Datenbank.
Konzentration ist entscheidend, da der Knoten mit dem höchsten Eingangsgrad die höchste aggregierte Last sieht. Die Datenbank am Ende der Kette kann Abfragen von jedem aktiven Request im gesamten System sehen, selbst wenn kein einzelner Nutzer viel erzeugt.
Fan-Out = Abhängigkeit
Ausgangsgrad eines Knotens = Anzahl der Kanten, die von ihm ausgehen. Ein hoher Ausgangsgrad bedeutet viele downstream-Abhängigkeiten.
Ein Backend, das eine Datenbank, zwei Caches, drei externe APIs & eine Warteschlange aufruft, hat den Ausgangsgrad 7. Seine Erfolgswahrscheinlichkeit ist ungefähr das Produkt der Erfolgswahrscheinlichkeiten jeder Downstream-Komponente (wenn alle für eine erfolgreiche Antwort erforderlich sind).
0,999 ^ 7 ≈ 0,993: Ein Backend mit 7 Downstreams, die jeweils eine Zuverlässigkeit von 99,9 % haben, kann selbst nur eine Zuverlässigkeit von ca. 99,3 % erreichen, selbst wenn es keine eigenen Fehler hat.
Ausgangsgrad reduzieren durch: Caching von Downstream-Ergebnissen, das Nicht-Kritische Downstreams optional machen (graceful degradation), Parallelisierung dessen, was parallelisiert werden kann.
Die Asymmetrie
Fan-in konzentriert die Last; Fan-out multipliziert das Risiko. Ein gut gestalteter Graph minimiert beides an den Knoten mit der größten Auswirkung.
Die Datenbank (höchster Fan-in): Aggressiv cachen, um die Last zu reduzieren. Lese-Replikate, um den Fan-in auf mehrere Knoten zu verteilen.
Der Orchestrierungsdienst (höchster Fan-out): Circuit Breaker pro Abhängigkeit, graceful degradation, Bulkheads.
Ein eingefügter Knoten schafft Flexibilität
Indirektion = Einfügen eines Zwischenknotens
Ohne Proxy lautet der Graph: client -> backend. Der Client muss die Adresse des Backends kennen. Eine Verlagerung des Backends erfordert die Aktualisierung des Clients (über DNS oder Konfiguration). Dies ist eine starre Kopplung.
Mit einem Proxy wird der Graph: client -> proxy -> backend. Der Client kennt nur den Proxy. Eine Verlagerung des Backends erfordert die Aktualisierung der Upstream-Konfiguration des Proxys, nicht die des Clients.
Die Graphenoperation: Einfügen eines Knotens entlang einer vorhandenen Kante. Die neue Kante client -> proxy ist stabil; die neue Kante proxy -> backend liegt nun in der Verantwortung des Teams.
Geometrische Interpretation: Indirektion fügt eine Schicht hinzu, die Änderungen upstream von Änderungen downstream entkoppelt. Die Kanten jeder Schicht können unabhängig voneinander neu verdrahtet werden.
Kosten der Indirektion
Jede Ebene fügt hinzu:
- Einen Latenz-Hop (die Kante vom Client zum Proxy)
- Einen weiteren Schnittknoten auf dem Pfad (den Proxy selbst)
- Einen weiteren Ort, an dem Fehlkonfigurationen auftreten können
Die Vorteile (Neuverdrahtung, Skalierung, Abschirmung, TLS-Terminierung, Lastverteilung) überwiegen in der Regel die Kosten für jedes nicht-triviale System. Aber es gibt eine Grenze: Jede Indirektionsebene fügt einen weiteren Hop und einen weiteren potenziellen SPOF-Kandidaten hinzu.
Die Volkswissensregel: Jedes Problem kann durch das Hinzufügen einer Indirektionsebene gelöst werden (außer dem Problem zu vieler Indirektionsebenen).
Eine Architektur als Graph lesen
Synthese
Du kannst nun eine Systemarchitektur als Graph lesen: Hops zählen, Schnittknoten identifizieren, die Konzentration der Fan-in messen, Verfügbarkeitsgrenzen aus der Fan-out berechnen & Indirektions-Trade-offs bewerten.
Wende alle vier an.
Ein neuer Dienst hat diese Architektur: clients -> CDN -> reverse proxy (2 Replikate) -> backend tier (8 Replikate) -> { DB primary, cache cluster (3 Knoten), external API }.
Begleitende Notizen
Begleitende Notizen
Diese Lektion zur Geometrie interpretiert die Hauptlektion Proxies & Origins als Analyse eines gerichteten Graphen.
Die nächste Begleitlektion in diesem Kurs, geometry_of_stateless_horizontal_scaling, nimmt die Replikationsmathematik aus der Hauptlektion zum Skalieren und leitet daraus geometrisch die Warteschlangenkurve, das Little'sche Gesetz und das 80-%-Auslastungs-Knie ab.
Gut gemacht.