Netflix betreibt hunderte Microservices, die über Load Balancer, API-Gateways und Proxies kommunizieren. Bei Ausfällen müssen Teams schnell verstehen, welche anderen Dienste betroffen sind. Ältere Systeme sammelten stundenlang Daten und erstellten dann eine Momentaufnahme. Das hilft bei einem Incident um drei Uhr morgens nicht weiter. Die Lösung: ein Streaming-Ansatz, der Daten kontinuierlich aufnimmt und in Minuten aktualisiert.
Millionen Netzwerkflüsse pro Sekunde aus mehreren Regionen über Kafka-Streams zu verarbeiten, erzeugt Probleme: Kafka-Consumer fallen zurück, Instanzen laufen aus dem Speicher, manche Nodes bekommen hundertmal mehr Traffic, Garbage-Collection-Pausen fressen CPU. Netflix entwickelte eine Architektur mit Backpressure. Ein Mechanismus, bei dem stromabwärts gelegene Stufen signalisieren, dass stromaufwärts langsamer gemacht werden soll. Daten warten in Kafka, bis Kapazität da ist. Das System verlangsamt sich, statt zu crashen. Leicht verzögerte Echtzeitdaten sind besser als stundenalte Batches oder unvollständige Daten.
Die Architektur besteht aus drei physisch getrennten Layern: Network Layer (eBPF Flow Logs), IPC Layer (Application Metrics), Tracing Layer (Distributed Traces). Jede Schicht skaliert unabhängig. Abfragen laufen parallel auf den relevanten Speichern und liefern Ergebnisse in subsekundengenauer Antwortzeit.
Der Network Layer nutzt eine dreistufige verteilte Aggregationspipeline. Netzwerk-Flow-Logs zeigen nur einzelne Hops – App A schickt an Load Balancer, Load Balancer an App B. Ingenieure brauchen die logische Abhängigkeit App A → App B. Die Pipeline löst das in drei Schritten:
Stufe 1: Initiale Aggregation – konsumiert Flow Logs aus Multi-Region Kafka, filtert ungültige Records, bündelt sie in 5-Minuten-Fenstern, verteilt per konsistentem Hashing auf Stufe 2.
Stufe 2: Auflösung der Netzwerk-Intermediäre – gruppiert Aggregatoren nach Intermediär (z.B. Load Balancer ID), führt Join durch, erstellt direkte Kanten (Quelle → Ziel), redistribuiert aufgelöste Kanten per konsistentem Hashing an Stufe 3.
Stufe 3: Finale Aggregation und Anreicherung – aggregiert Kanten über Zeitfenster, reichert Knoten mit externen Daten an (Anwendungsstatus, Ownership, Metadaten), schreibt Graph-Entities kontrolliert in die Graphdatenbank mit Throttling.
Ein reiner Zwei-Stufen-Ansatz scheiterte in der Produktion: Datenlokalität – Flows liegen auf unterschiedlichen Kafka-Partitionen, Stufe 2 muss einen Shuffle für den Join durchführen. Eine separate Stufe dafür ist nötig. Die Dreiteilung erlaubt unabhängige Skalierung jeder Stufe.
Produktionserfahrung: Manche Load Balancer hatten hundertfach höheres Traffic-Volumen – heiße Partitionen. Adaptive Partitionszahl und konsistentes Hashing verteilten die Last gleichmäßiger. SSE-Verbindungen zwischen Stufen wurden durch reaktive Streams mit begrenzten Puffern und expliziten Slow-Down-Signalen ersetzt.
Lektionen: Backpressure ist grundlegend für jedes Streaming-System. Physische Trennung nach Datenquelle ermöglicht unabhängige Optimierung. Die Anzahl der Verarbeitungsstufen hängt von der Datenverteilung ab. Leicht verzögerte Echtzeitdaten sind oft besser als perfekte Batches.
Netflix zeigt, wie Millionen Events pro Sekunde verarbeitet werden können: klare Architektur mit Backpressure, durchdachte Aufteilung der Schritte, Akzeptanz, dass Perfektion in Echtzeit unmöglich ist – eine gute Näherung reicht aus, um Incidents schneller zu beheben.
Quelle: netflixtechblog.com
