Skip to content
research

Cloudflares 100-TB-Speicher-Raub

Ingenieure haben gerade genug RAM freigesetzt, um 130 Server zu betreiben, ohne einen einzigen Chip zu kaufen. Aber die eigentliche Überraschung sind nicht die Einsparungen – es ist das, was dabei schneller wurde.

Aki Tanaka
Cloudflares 100-TB-Speicher-Raub

Das 100-Terabyte-Problem

Cloudflare hat kürzlich einen erstaunlichen Memory-Raub durchgeführt und 100 Terabyte an operativer Kapazität in seinem globalen Netzwerk freigesetzt. Diese bemerkenswerte Optimierung entspricht dem Hinzufügen der gesamten RAM-Kapazität von 130 modernen Gen-13-Servern zur Infrastruktur, ohne dass eine einzige neue Hardwarekomponente eingesetzt werden musste. Eine solch massive Rückgewinnung unterstreicht die tiefgreifende Wirkung von Low-Level-Softwareeffizienz.

Die Big Pineapple-Plattform von Cloudflare betreibt kritische Dienste wie 1.1.1.1, Gateway DNS und DNS Firewall und verwaltet einen enormen Umfang. In jedem Moment speichert dieses System über 250 Milliarden DNS-Cache-Einträge, von denen jeder ein entscheidendes Stück Internet-Routing-Information darstellt und täglich Milliarden globaler Anfragen ermöglicht. Dieser immense Umfang verwandelt selbst geringfügige Ineffizienzen in erhebliche betriebliche und finanzielle Herausforderungen.

Die zentrale Herausforderung für Cloudflare lag im kumulativen Effekt scheinbar winziger Overheads. Bei 250 Milliarden DNS-Einträgen multipliziert sich ein einziges verschwendetes Byte pro Eintrag zu Hunderten von Gigabytes an überflüssigem Speicher in der gesamten global fleet. Diese mikroskopische Ineffizienz, skaliert über ein so riesiges System, verbraucht nicht nur wertvolle Ressourcen, sondern kann auch die Leistung beeinträchtigen und die Betriebskosten erhöhen, was eine grundlegende Neubewertung der Datenstrukturen erforderte.

Fünf Schnitte, ein massiver Gewinn

Cloudflare führte fünf präzise Rust-Level-Optimierungen durch, jede ein chirurgischer Schlag gegen Speicherblähungen, was in einem massiven 100-TB-Gewinn gipfelte. Zunächst ersetzten die Ingenieure Vec<T> und String durch Box<[T]> und Box<str> für unveränderliche Cache-Einträge. Dies eliminierte vorab zugewiesene Kapazitäten und unnötigen Heap-Overhead, wodurch sofort 64 Bytes pro Eintrag und über 15 TB im gesamten Netzwerk frei wurden.

Eine zweite kritische Änderung betraf die Speicherung von DNS-Datensätzen als raw wire-format bytes anstelle von vollständig geparsten Rust-Structs. Dies rationalisierte die Verarbeitung, da das System nun redundantes Parsen und Serialisieren vermeidet. Es verbesserte zudem die cache locality erheblich, indem mehr relevante Daten in weniger Cache-Lines gepackt wurden.

Weitere Layout-Einfallsreichtümer verhinderten Speicherverschwendung. Cloudflare kapselte große enum variants, wie NAPTR innerhalb des RecordData-Enums, um zu verhindern, dass kleinere, häufigere Datensatztypen (wie A und AAAA) übermäßigen Platz reservieren. Dies stellte sicher, dass die Speicherzuweisung genauer mit der tatsächlichen Datengröße übereinstimmte.

Die Ingenieure führten zudem drei separate DNS-Antwort-Datensatzlisten (Antwort, Autorität, zusätzlich) zu einer einzigen, vereinheitlichten Liste zusammen. Zwei kompakte 2-Byte-u16-Offsets begrenzen nun die Abschnitte und ersetzen größere Zeiger/Längen-Paare, was 28 Bytes pro Eintrag einspart. Diese Konsolidierung straffte die Datenstruktur erheblich.

Schließlich stellte die bedingte Eigentümerspeicherung den fünften Schnitt dar. Cloudflare speichert den Namen des Eigentümers nun nur noch, wenn er sich von der abgefragten Domain unterscheidet, und leitet ihn ansonsten aus dem Cache-Key ab. In Kombination reduzierten diese granularen Optimierungen den Platzbedarf pro Eintrag um 56 %, von 953 Bytes auf 420 Bytes, und veränderten damit die Speicherlandschaft von Cloudflare grundlegend.

Schneller durch Verkleinerung

Das Verkleinern von Datenstrukturen impliziert oft einen Leistungs-Kompromiss, aber die Optimierungen von Cloudflare lieferten einen seltenen doppelten Gewinn. Der Cache-Insert-Durchsatz stieg um beeindruckende 43 % und kletterte von 625.000 auf 893.000 Einträge pro Sekunde. Gleichzeitig sank die Lookup-Latenz deutlich und verbesserte sich um 19 % von 828 ns auf 670 ns.

Diese Beschleunigung ist keine Magie, sondern eine direkte Folge der Speicherdichte. Durch die Reduzierung des Speicherbedarfs pro DNS-Cache-Eintrag um 56 % (von 953 Byte auf 420 Byte) wurden die Datenstrukturen von Cloudflare kompakter. Kleinere Daten beanspruchen weniger Platz, wodurch mehr Cache-Einträge in die schnelleren L1-, L2- und L3-Caches der CPU passen, was die CPU-Cache-Lokalität verbessert.

Stellen Sie es sich wie das Auffüllen einer Speisekammer vor: Eine kleinere Verpackung bedeutet, dass Sie häufiger benötigte Artikel in den leicht zugänglichen vorderen Regalen unterbringen können. Prozessoren verbringen weniger Zeit damit, Daten aus dem langsameren Hauptspeicher (RAM) abzurufen, und mehr Zeit damit, sie direkt aus diesen Hochgeschwindigkeits-Caches zu verarbeiten, was Wartezustände drastisch reduziert.

Eine solch tiefgreifende Verbesserung sowohl beim Ressourcenverbrauch als auch bei der Betriebsgeschwindigkeit ist eine technische Seltenheit, die den typischen Kompromissen zwischen Speichernutzung und Ausführungszeit trotzt. Cloudflare hat nicht nur 100 Terabyte Speicher freigesetzt, sondern auch seinen DNS-Resolver nachweislich schneller gemacht. Für einen tieferen Einblick in die technischen Details lesen Sie den Bericht von Cloudflare selbst: How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache.

Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.

eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte

Der Welleneffekt der Effizienz

Cloudflare wird diese 100 TB an freigesetztem Speicher nicht ungenutzt lassen. Stattdessen reinvestiert das Unternehmen diese beträchtliche Kapazität direkt in sein globales Netzwerk, insbesondere durch die Erweiterung des DNS-Caches für Dienste wie 1.1.1.1. Diese strategische Zuweisung maximiert die Wirkung der Speicherrückgewinnung und verwandelt einen technischen Triumph in ein sofortiges betriebliches Upgrade.

Ein größerer DNS-Cache führt direkt zu greifbaren Vorteilen für Millionen von Nutzern weltweit. Höhere Cache-Trefferraten bedeuten schnellere DNS-Antworten, da die Server von Cloudflare mehr Abfragen aus dem lokalen Speicher auflösen können, anstatt Upstream-Lookups zu initiieren. Dies verbessert direkt die Reaktionsfähigkeit und Widerstandsfähigkeit des Interneterlebnisses.

Die Leistung von Cloudflare bietet eine wichtige Lektion für die Branche: Tiefgreifende Systemoptimierung bleibt ein mächtiger Hebel für Effizienz. Da die Nachfrage durch AI-Workloads die Server-Speicherkosten in die Höhe treibt, ist die Optimierung der bestehenden Infrastruktur zur Rückgewinnung von 100 Terabyte Speicher ohne Hardwareänderungen nicht nur eine technische Meisterleistung, sondern eine strategische Notwendigkeit. Diese akribische Arbeit auf Rust-Ebene unterstreicht den bleibenden Wert von Präzision in der Systemprogrammierung.

Häufig gestellte Fragen

Wie viel Speicher hat Cloudflare tatsächlich eingespart?

Cloudflare hat durch die Optimierung seines 1.1.1.1 DNS-Caches etwa 100 Terabyte (TB) RAM in seiner gesamten globalen Serverflotte eingespart, was dem Speicher von 130 seiner Server entspricht.

Welche Programmiersprache wurde für die Optimierung verwendet?

Die Optimierungen wurden in Rust implementiert, das aufgrund seiner Speichereffizienz, Leistung und Low-Level-Kontrolle über Datenstrukturen ausgewählt wurde.

Hat die Speichereinsparung den DNS-Resolver verlangsamt?

Nein, kontraintuitiv haben die Optimierungen auch die Leistung verbessert. Der Cache-Einfügedurchsatz stieg um 43 % und die Lookup-Latenz sank um 19 %.

Wie wurde der Speicher eingespart?

Die Einsparungen resultierten aus fünf wesentlichen Änderungen an der Speicherung von DNS-Daten, darunter die Eliminierung ungenutzter Speicherkapazität in Vektoren, die Zusammenführung von Datenlisten und die effizientere Speicherung von Datensätzen als Roh-Bytes.

Was wird Cloudflare mit den eingesparten 100 TB Speicher tun?

Der freigewordene Speicher wird reinvestiert, um die Größe des DNS-Caches zu erhöhen. Dies soll die Cache-Trefferraten verbessern, Upstream-Abfragen reduzieren und den 1.1.1.1-Dienst für Nutzer noch schneller machen.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$500 · AI tools & software only

Für Builder

Diese Seite arbeitet gerade für das Tool von jemand anderem.

KI-Agenten lesen sie. Käufer landen darauf. Sie antwortet in acht Sprachen und über MCP. Dein Tool kann so eine haben — in 24 Stunden live.