Rund zwei Milliarden Ereignisse pro Sekunde fließen durch die Datenpipeline von Cloudflare, verteilt über Zehntausende Server. Ein interner Dienst namens Logfwdr sammelt sie an der Peripherie ein und übergibt sie an zentrale Empfänger, die sie in ein Puffersystem namens Buftee schreiben. Von dort holen nachgelagerte Konsumenten die Ströme ab und reichen sie an Ziele wie ClickHouse weiter.
So beschreibt das Datenteam des Unternehmens den Aufbau in einem technischen Bericht. Die Pipeline ist kein Randthema: Mehr als zwanzig Prozent des Webverkehrs laufen über Cloudflares Netz, und derselbe Weg versorgt Cloudflare Logs, die SQL-API, Observability sowie interne Analysen. Der Verkehr wächst exponentiell, die Hardware linear. Über fünf Jahre hat das Team nach eigener Darstellung Verbesserungen umgesetzt, die zusammen einer aufgeschobenen Hardware-Erweiterung von etwa zweieinhalb Jahren entsprechen.
Wie eine Datenpipeline zum Nadelöhr wird
Stellt man sich die Architektur als Rohrleitung vor, sieht man schnell, wo der Druck entsteht. Am Anfang steht Logfwdr, das Ereignisse von stark verteilten Quellen wie Workers und FL einsammelt, also dort, wo tatsächlich Arbeit passiert. Diese Ereignisse gehen über ein Weitverkehrsnetz an eine überschaubare Zahl zentraler Empfänger, die das Volumen bündeln. Von dort wandern die Daten über Buftee zu den Konsumenten, die sie in ClickHouse schreiben und für Abfragen bereithalten.
Nur der mittlere Abschnitt dieses Wegs ist wirklich teuer. Bandbreite über Regionen hinweg kostet Geld, Latenz und Ausfallrisiko, während Rechenleistung an den Rändern vergleichsweise billig skalierbar ist. Jede Optimierung, die Bytes aus dem Transit heraushält oder sie später erzeugt, wirkt daher stärker als eine zusätzliche Maschine. Dort setzt die Arbeit der vergangenen Jahre an, nach einem wiederkehrenden Muster: Arbeit nach vorne ziehen, Kopien vermeiden, das Volumen vor dem Versand reduzieren.
Das monolithische Schema aufteilen
Der erste große Eingriff kam 2022 und betraf die Struktur der Nachrichten selbst. Bis dahin gab es einen einzigen Strom, in dem alle Felder aller Produkte steckten. Interne Konsumenten mussten ihn vollständig aufnehmen und anschließend selbst herausfiltern, was sie brauchten, oder den Rest verwerfen. Kaum eine Mannschaft braucht hundert Prozent der Felder.
Die Lösung bestand darin, den einen großen Nachrichtenstrom durch produktspezifische Schemata zu ersetzen. Manche Felder tauchen dadurch in mehreren Nachrichten gleichzeitig auf, es wird also ein wenig dupliziert. Die Bandbreite im Backbone sank nach Angaben des Teams trotzdem um 35 bis 40 Prozent. Umgerechnet entsprach das etwa einem Jahr komprimierten Traffic-Wachstums, das man nicht mehr mit Hardware auffangen musste. Das Problem war nicht die Datenmenge, sondern die Art, wie sie verpackt wurde.
Von LZ4 auf zstd: Komprimierung als Hebel
Bis 2024 wuchs der Verkehr so weit, dass das Team nach eigener Beschreibung täglich mit Netzengpässen zu kämpfen hatte. Der naheliegende Hebel war die Komprimierung, konkret der Wechsel von LZ4 auf zstd. Ein früherer Versuch mit zstd hatte allerdings höhere CPU-Last gezeigt, weshalb die Umstellung zunächst als riskanter Tausch galt: kleinere Pakete gegen mehr Rechenzeit.
Deshalb wurde zuerst eine kleine Gruppe von Servern umgestellt und die CPU-Metriken genau beobachtet. Die befürchtete Mehrbelastung blieb aus. Daraufhin folgte die schrittweise Ausrollung auf die gesamte Flotte, ebenfalls ohne auffällige Wirkung auf die Prozessoren. Am Ende stand eine Reduktion des komprimierten Durchsatzes um knapp 40 Prozent, während die unkomprimierten Bytes unverändert weiterwuchsen. Mit derselben Leitung ließ sich mehr als das Anderthalbfache an Verkehr bewältigen, ein Effekt, der etwa zehn Monaten Wachstum entspricht.
Weniger wichtig als die Wahl des Algorithmus war die Art der Prüfung. Komprimierung verschiebt Last zwischen zwei Ressourcen, und welcher Tausch sich lohnt, hängt vom eigenen Profil ab. Wer dieselbe Änderung blind übernimmt, kann sich die CPU-Last einfangen, die dem Team damals erspart blieb.
Replikation verschieben statt verdoppeln
Der aufwendigste Umbau betraf die Ausfallsicherheit. Um Analysen gegen regionale Störungen zu wappnen, müssen Daten in mehreren zentralen Regionen redundant vorliegen, wobei Daten mit Kunden-Metadaten-Grenzen strikt in ihrer Region bleiben. Historisch geschah das per Doppelschreiben: Logfwdr schickte zwei vollständige Kopien jedes nicht-regionalen Ereignisses los, eine pro Region, und jede Region verarbeitete ihre Kopie unabhängig bis nach ClickHouse. Solange nur wenige Ströme so liefen, war das vertretbar. Als fast alle Analyse-Ströme abgesichert wurden, verdoppelte sich der Logfwdr-Verkehr überall.
Für Logpush hatte das Team dasselbe Problem bereits gelöst. Dort behandelt Logfwdr die zentralen Rechenzentren als einen gemeinsamen Pool: Jede Nachricht geht an genau eine Region und weicht nur dann aus, wenn eine Maschine oder ein Standort nicht erreichbar ist. Der Haken bei Analysen war, dass die ClickHouse-Cluster in beiden Regionen weiterhin eine vollständige Kopie brauchen, damit Abfragen sofort und unabhängig umschwenken können. Die Lösung war, Transit und Datenbank-Redundanz zu entkoppeln.
Konkret bedeutet das drei Dinge: ein gemeinsamer Ingest-Pool, in dem Logfwdr jedes Ereignis genau einmal über das Weitverkehrsnetz verschickt; eine späte Replikation, bei der Kopien erst hinter Buftee durch entfernte Inserter erzeugt werden; und ein Fehlerverhalten, bei dem ein Regionsausfall den Verkehr sofort auf die verbleibende Region umleitet, während entfernte Inserter nach einem Verbindungsabbruch aus dem Puffer nachziehen. Für die migrierten Datensätze verschwanden so rund 43 GB/s komprimierter Transitverkehr, während etwa 7 GB/s Replikation zwischen den Rechenzentren hinzukamen. Unter dem Strich blieben 36 GB/s gespart.
Zwei Gründe erklären, warum die Rechnung so deutlich ausfällt. Erstens liegt die Replikation nun hinter dem Sampling, es werden also nicht mehr zwei Kopien roher, ungesampelter Ereignisse verschickt, sondern eine bereits verdichtete. Zweitens lassen sich zentralisierte Ströme in gleichmäßige Stapel über größere Zeitfenster schneiden, was Kompressionsverfahren bessere Raten erlaubt als die fragmentierten Stapel am Ursprung. Beim ersten Schnitt sank der Verkehr der HTTP-Analyse um etwa 20 GB/s, also um mehr als die Hälfte, und bei Ready-Analytics fiel er von rund 28 auf 16 GB/s.
Sampling nach vorne verlegen
Der zweite große Eingriff in diesem Jahr war das Sampling, also die bewusste Arbeit mit Stichproben statt mit allen Ereignissen. Solche Verfahren liefen bereits in den zentralen Empfängern und entlasteten die nachgelagerten Systeme. Wenn weniger Daten das Haus verlassen müssen, ohne dass die Aussagekraft leidet, ist das der günstigste Weg. Deshalb wanderte das Sampling zusätzlich in Logfwdr selbst, direkt an die Quelle.
Der Algorithmus dahinter ist überschaubar. Jeder Datensatz hat einen Schlüssel, den die produzierenden Teams gewählt haben; für jeden Schlüssel werden die Einträge zunächst gemischt, um Verzerrungen auszuschließen. Aus jeder Gruppe wird dann eine Stichprobe der Größe Quadratwurzel aus der Gesamtzahl gezogen. Aus dieser Stichprobe lassen sich Werte hochrechnen, indem man mit dem Sampling-Faktor skaliert: Wer zehn von hundert Einträgen behält, multipliziert die gezählten Ergebnisse mit zehn. Das Team hat die Schätzung gegen die tatsächlich geschriebenen Zeilen geprüft, und zwar über Schlüssel vom seltensten bis zum häufigsten Fall.
Die Verteilung verschiebt sich dadurch. Viel gesehene Schlüssel bekommen eine niedrigere Sampling-Rate, seltene Schlüssel bleiben vergleichsweise detailliert erhalten. Über Potenzgesetze betrachtet wächst die doppelt gesampelte Menge mit einem Exponenten von etwa 0,319 statt 0,485: Ein Schlüssel mit hundertmal mehr Daten landet dadurch bei rund viermal so vielen gespeicherten Zeilen statt bei zehnmal so vielen. In einem konkreten Beispiel standen 11,6 Millionen Ereignisse am Ende für 18.000 Zeilen in ClickHouse statt für 79.000. Bei den drei größten Datensätzen halbierte sich der komprimierte Verkehr mindestens, zusammen rund 25 GB/s oder mehr als zwei Petabyte pro Tag.
Was die Umbauten für den Betrieb bedeuten
Eine weitere bereits umgesetzte Maßnahme sind frühzeitige Aggregationen. Statt jedes Ereignis bis zum Ende weiterzureichen, fasst Cloudflare passende Teilwerte in Logfwdr, den zentralen Empfängern, den Insertern und schließlich ClickHouse zusammen. Beim HTTP-Rollup-Datensatz sank der komprimierte Verkehr laut Bericht von mehr als 9 auf unter 2 GB/s. Solche Rollups beantworten vorher festgelegte Fragen exakt; Sampling erlaubt dagegen allgemeinere Auswertungen mit Schätzungen. Beim Ready-Analytics-Empfänger nennt das Team außerdem etwa halbierten CPU- und Speicherbedarf, entsprechend rund 750 CPUs und 3,5 TiB Arbeitsspeicher. Diese Ergebnisse gehören zur Nachricht: Es geht um bereits erreichte Einsparungen, nicht nur um einen Ausblick.
Zieht man die Etappen zusammen – Schema-Aufteilung, Komprimierung, späte Replikation, früheres Sampling und bereits eingeführte Aggregationen in Form von Rollups –, ergibt sich ein klares Muster. Das Team senkt die Hardware-Auslastung nicht, indem es weniger misst, sondern indem es dieselbe Aussage mit weniger Bytes transportiert. Filterarbeit wandert nach vorne, Kopien entstehen später, und verdichtet wird dort, wo es billig ist.
Übertragbar ist das nur begrenzt. Sampling funktioniert für Auswertungen, die mit Stichproben umgehen können, nicht für Anwendungen, die jedes einzelne Ereignis exakt brauchen. Komprimierungsraten hängen von der Gleichmäßigkeit der Daten ab, und späte Replikation verschiebt Kosten, sie löscht sie nicht. Jede dieser Änderungen hat außerdem Ingenieurszeit gekostet, die man gegen Hardwarekosten aufrechnen muss.
Trotzdem lohnt der Blick auf die eigene Datenverarbeitung, wenn Traffic-Wachstum gegen ein festes Budget läuft. Wo in der eigenen Pipeline gehen Nachrichten doppelt über eine teure Verbindung? Wo wird gefiltert, nachdem die Daten schon übertragen wurden? Passt das Kompressionsverfahren noch zum heutigen Profil? Diese Fragen kosten nichts und decken meist mehr auf als der nächste Server. Der Rest ist eine Frage der Reihenfolge: erst weniger senden, dann schneller senden, dann mehr Hardware.
Quelle: blog.cloudflare.com
