Es ist drei Uhr morgens. Dein Dienst zeigt erhöhte Fehlerraten, du wirst per Pager geweckt. Liegt es an meinem Service? Hängt ein Problem bei einem anderen Dienst damit zusammen? Welche Teams muss ich alarmieren? Diese Situation beschreiben die Entwickler von Netflix in einem aktuellen Blogbeitrag. Sie nennen es das „3-Uhr-morgens-Problem“. Ihre Lösung: eine Echtzeit-Service-Topologie-Karte, die alle Abhängigkeiten zwischen den tausenden Microservices visualisiert.
Das Puzzle mit tausend Teilen
Netflix betreibt eine massive, verteilte Architektur mit tausenden Microservices. Jeder Dienst erfüllt eine bestimmte Aufgabe – von der Authentifizierung über die Personalisierung bis zur Streaming-Optimierung. Wenn ein Nutzer auf „Play“ drückt, löst das eine Kaskade von Service-to-Service-Aufrufen aus. Diese Abhängigkeiten sind oft nur den Entwicklern im Kopf bekannt oder in veralteten Architekturdiagrammen festgehalten. In einer Umgebung, in der mehrmals täglich neue Versionen ausgerollt werden, ändern sich diese Abhängigkeiten ständig.
Die Ingenieure bei Netflix stellten fest, dass ein zentrales Werkzeug fehlt, um diese Verbindungen in Echtzeit zu verstehen. Herkömmliche Observability-Tools liefern Metriken, Logs und Traces – jedes zeigt nur einen Ausschnitt. Eine Metrik sagt dir, dass ein Dienst langsam ist, aber nicht, welche anderen Dienste er aufruft. Ein Trace zeigt den Pfad einer einzelnen Anfrage, aber nicht das gesamte Abhängigkeitsnetzwerk. Entwickler mussten bisher aus mehreren Quellen mühsam ein Gesamtbild zusammensetzen – in einer Stresssituation um drei Uhr morgens ist das fehleranfällig und zeitraubend.
Die Autoren des Blogbeitrags – Parth Jain, Rakesh Sukumar, Yingwu Zhao, Renzo Sanchez und Nathan Fisher – analysierten über vier Jahre Supportanfragen von Ingenieuren. Immer wieder tauchten dieselben drei Fragen auf: „Welche Dienste hängen von mir ab?“, „Was ist der Blast Radius, wenn ich meinen Dienst runterfahre?“, „Kommt der Fehler von einem vorgelagerten Dienst oder von mir selbst?“. Diese Fragen sind fundamental für das Troubleshooting in verteilten Systemen. Netflix wollte Antworten geben – schnell, genau und in Echtzeit.
Die Anforderungen an eine lebende Karte
Bevor sie mit dem Bau begannen, definierten die Entwickler klare Anforderungen. Erstens: Die Karte muss in Echtzeit aktualisiert werden. Ein Topologie-Plan, der einige Stunden alt ist, nützt nichts, wenn Services mehrmals täglich deployen. Zweitens: Die Abfragen müssen extrem schnell sein – unter einer Sekunde. Wenn ein Ingenieur um drei Uhr morgens nach Abhängigkeiten sucht, darf die Antwort keine Minute dauern. Drittens: Die Karte muss mehrere Perspektiven abdecken. Netzwerkverbindungen allein sagen nicht, welche APIs genau aufgerufen werden. Es braucht die Netzwerkebene, die Anwendungsebene und die Ebene der tatsächlichen Anfragepfade.
Viertens: Die Daten müssen angereichert sein. Es reicht nicht zu wissen, dass Service A mit Service B spricht. Man muss auch den Health-Status, die Verfügbarkeitsstufe, die Geschäftsdomäne und das verantwortliche Team sehen. Fünftens: Die Karte muss visuell und programmatisch zugänglich sein. Entwickler brauchen eine grafische Oberfläche zur Erkundung, aber auch Automatisierungssysteme wie Blast-Radius-Rechner oder Incident-Response-Tools müssen per API darauf zugreifen können.
Aus früheren Experimenten hatten die Entwickler gelernt: Keine einzige Datenquelle liefert ein vollständiges Bild. Netzwerkdaten zeigen alle Verbindungen, aber ohne Anwendungskontext. Anwendungsmetriken geben Details zu Endpunkten, aber nur für instrumentierte Dienste. Traces zeigen reale Anfragepfade, aber unterliegen Sampling. Die Lösung: drei unabhängige Quellen kombinieren.
Drei Datenquellen, drei Graphen, einheitliche Sicht
Die Netflix-Ingenieure entschieden sich für einen Multi-Layer-Ansatz. Sie bauten drei separate Graphen – einen für jede Perspektive – die physikalisch getrennt gespeichert werden. Jeder Graph lebt in einem eigenen Datenspeicher: der Netzwerk-Graph in einer Graphdatenbank-Partition, der IPC-Graph in einer weiteren Partition und der Tracing-Graph in einem columnar Storage für analytische Abfragen. Wenn ein Entwickler eine einheitliche Sicht anfordert, führt das System gleichzeitige Abfragen in allen drei Partitionen durch und merged die Ergebnisse. Das geht in unter einer Sekunde.
1. eBPF-Netzwerkflüsse (Netzwerkebene)
Mit eBPF, einer Technologie zur dynamischen Instrumentierung des Linux-Kernels, erfassen die Entwickler Netzwerk-Flow-Records. Diese zeigen, welche Services sich über IP-Adressen und Ports verbinden. Der Vorteil: Jeder Dienst wird erfasst, unabhängig davon, ob er instrumentiert ist. So entsteht eine vollständige Karte aller Netzwerkverbindungen – auf Cluster- und Applikationsebene. Die Einschränkung: Man sieht nur, dass Service A mit Service B spricht, aber nicht, welche API-Endpunkte (z. B. /api/v1/users vs. /api/v1/orders) aufgerufen werden.
2. IPC-Metriken (Anwendungsebene)
Netflix sammelt Metriken zu Inter-Process Communication (IPC) aus den instrumentierten Diensten. Diese Metriken werden von den Anwendungen selbst ausgestoßen, wenn sie über gRPC, GraphQL oder REST andere Dienste aufrufen. Sie enthalten reichhaltige Informationen: konkrete Endpunkte, Fehlerraten, Latenzverteilungen, Protokolldetails. Diese Ebene liefert detaillierte Applikationstopologie – aber nur für Dienste, die solche Metriken emittieren. Nicht alle Services tun das.
3. End-to-End-Tracing (Anfrageebene)
Die dritte Quelle ist das verteilte Tracing. Netflix verfolgt einzelne Anfragen durch das gesamte System – allerdings nur einen Teil der Anfragen, um die Performance nicht zu beeinträchtigen (Sampling). Aus den aggregierten Traces bauen sie einen Topologie-Graphen, der zeigt, wie Anfragen tatsächlich fließen. Das ist besonders wertvoll, weil es konditionale Logik und Feature-Flags abbildet: Nicht immer ruft Service A Service B auf – nur unter bestimmten Bedingungen. Entwickler können die aggregierte Ansicht oder einzelne Traces auf der Karte anzeigen lassen, um konkrete Anfragepfade nachzuvollziehen.
Wie die drei Schichten zusammenwirken
Die Stärke des Systems liegt in der Kombination. Der Netzwerk-Graph sorgt für Vollständigkeit: Jede Verbindung wird erfasst, auch von nicht instrumentierten Diensten. Der IPC-Graph liefert den Anwendungskontext: Welche Endpunkte, welche Protokolle, welche Fehlerquote? Der Tracing-Graph zeigt das reale Laufzeitverhalten: Welche Pfade werden tatsächlich durchlaufen? Keine der drei Ebenen allein wäre ausreichend. Zusammen ergeben sie eine aktuelle Karte der Infrastruktur.
Entwickler können jede Ebene einzeln betrachten oder die vereinigte Ansicht nutzen. Die vereinigte Ansicht vereint Knoten und Kanten aus allen drei Partitionen und bewahrt die jeweiligen Eigenschaften. Ein Knoten kann Netzwerk-, IPC- und Tracing-Attribute tragen. Im Incident-Fall sieht der Ingenieur sofort, welche Dienste in welcher Art verbunden sind, welchen Health-Status sie haben und welche Teams verantwortlich sind. Per Klick kann er in die detaillierten Metriken, Logs oder Traces abtauchen – ohne zwischen verschiedenen Tools hin- und herspringen zu müssen.
Die Autoren betonen, dass die Skalierbarkeit eine der größten Herausforderungen war. Lösungen, die bei tausend Knoten funktionieren, versagen bei der Größenordnung von Netflix. Auch die Datenqualität war kritisch: Unvollständige oder falsche Abhängigkeitsinformationen können während eines Incidents zu Fehlentscheidungen führen. Deshalb setzen sie auf multiple Quellen, die sich gegenseitig validieren. Und auf Echtzeit: Da sich die Topologie ständig ändert, wird der Graph kontinuierlich aktualisiert – nicht einmal pro Stunde, sondern quasi in Echtzeit.
Was das konkret bedeutet
Mit Service Topology haben die Entwickler bei Netflix ein Werkzeug geschaffen, das genau die drei Fragen beantwortet, die sie immer wieder hörten: Wer hängt von wem ab? Was ist der Blast Radius? Wo liegt die Ursache? Die Karte ist keine statische Architekturzeichnung, sondern ein aktuelles Abbild der Systemstruktur. Für die Ingenieure bedeutet das weniger Stress in Incidents, schnellere Root-Cause-Analysen und eine bessere Grundlage für Entscheidungen über Wartungsarbeiten oder neue Deployments.
Die Architektur ist nicht auf Netflix beschränkt. Jedes Unternehmen mit einer Vielzahl von Microservices steht vor ähnlichen Herausforderungen. Der Ansatz, mehrere Datenquellen zu kombinieren und physisch getrennte Graphen parallel abzufragen, ist übertragbar – auch wenn die konkrete Implementierung auf die Netflix-eigene Observability-Plattform zugeschnitten ist. Das Prinzip bleibt: Eine Echtzeit-Topologiekarte ist keine Spielerei, sondern eine Notwendigkeit für zuverlässige verteilte Systeme.
Als Entwickler oder Architekt solltest du überlegen, ob dein Unternehmen ebenfalls eine solche Karte braucht. Vielleicht beginnst du nicht mit drei Quellen, sondern mit einer – etwa mit Tracing-Daten. Der wichtigste Punkt: Verlass dich nicht auf ein einziges Signal. Kombiniere Netzwerk-, Anwendungs- und Anfragedaten, um ein vollständiges Bild zu erhalten. In der Welt der Microservices ist die Abhängigkeitstopologie die Landkarte deines Systems – und ohne aktuelle Karte tappst du im Dunkeln.
Quelle: netflixtechblog.com
