Das 100-Terabyte-Problem, das direkt vor unseren Augen lag
Die globale DNS-Infrastruktur von Cloudflare, die auf der treffend benannten Big Pineapple-Plattform basiert, arbeitet in einem erstaunlichen Maßstab. Sie verwaltet ständig über 250 Milliarden DNS-Cache-Einträge und bildet das Rückgrat für wichtige Dienste wie 1.1.1.1, Gateway DNS und DNS Firewall für unzählige Nutzer weltweit.
Trotz dieser immensen operativen Präsenz entdeckten die Ingenieure von Cloudflare eine weit verbreitete, versteckte Ineffizienz. Ein typischer DNS-Cache-Eintrag, der mit 953 Bytes bemessen wurde, enthielt einen erheblichen Anteil an Memory Overhead, der nicht den DNS-Daten selbst, sondern der internen Buchhaltung der Datenstrukturen gewidmet war. Die Standardtypen Vec und String von Rust speichern beispielsweise einen Zeiger, eine Länge und ein Kapazitätsfeld.
Für statische zwischengespeicherte DNS-Datensätze, die nicht wachsen, wurde dieses Kapazitätsfeld zu einer unnötigen Belastung, die wertvollen Speicher verbrauchte. Diese scheinbar geringfügige Ineffizienz summierte sich im riesigen Netzwerk dramatisch. Selbst ein einziges verschwendetes Byte pro Eintrag bei 250 Milliarden Datensätzen entspricht über 250 Gigabyte an überflüssigem RAM.
Diese massive Speicherverschwendung entsprach den Betriebskosten ganzer Server und verdeutlichte, wie kleine, übersehene Details im Design von Datenstrukturen zu massiven Infrastrukturkosten anwachsen können. Die Erkenntnis von Cloudflare unterstrich die entscheidende Bedeutung eines feingranularen Speichermanagements, selbst in High-Level-Sprachen wie Rust.
Kapazität eliminieren: Rusts zweischneidiges Schwert
Die Datenstrukturen von Rust priorisieren oft Flexibilität. Standardtypen wie Vec und String verwalten dynamische Daten effizient, indem sie mehr Speicher zuweisen als unmittelbar benötigt, um zusätzliche Kapazität für zukünftiges Wachstum zu reservieren. Jede Instanz speichert implizit drei Informationen: einen Zeiger auf ihre Daten, ihre aktuelle Länge und diese vorab zugewiesene Kapazität.
Diese Strategie ist für veränderbare Daten äußerst effektiv, stellt jedoch für unveränderliche Datensätze reine Verschwendung dar. Die 250 Milliarden DNS-Cache-Einträge von Cloudflare sind nach der Speicherung fixiert; sie erweitern oder verkleinern sich nie. Das zusätzliche Kapazitätsfeld erfüllte daher innerhalb von "Big Pineapple" keinen funktionalen Zweck, verbrauchte jedoch wertvolle Systemressourcen.
Da sie diese Ineffizienz erkannten, ersetzten die Ingenieure Vec und String durch boxed slices (Box<[T]>) und boxed strings (Box<str>). Diese spezialisierten Rust-Typen weisen genau den Speicher zu, der für die Daten erforderlich ist, und eliminieren das Kapazitätsfeld vollständig. Diese scheinbar kleine Änderung sparte 64 Bytes pro einzelnem Cache-Eintrag.
In der gesamten globalen Flotte von Cloudflare hat diese Optimierung sofort über 15 TB RAM zurückgewonnen. Sie zeigt, wie ein tiefes Verständnis der Semantik von Datenstrukturen, kombiniert mit den spezifischen Anforderungen der Anwendung, enorme Effizienzgewinne freisetzen und ruhenden Speicher in aktive, nutzbare Ressourcen verwandeln kann.
Jenseits von Boxen: Die Kunst des Data Packing
Cloudflare ging über individuelle Zeiger für DNS-Abschnitte wie Answer, Authority und Additional hinaus und setzte auf eine Strategie von tightly packed Daten. Sie konsolidierten diese Abschnitte in einem einzigen zusammenhängenden Speicherblock und verwendeten dann winzige Zwei-Byte-Offsets, um präzise zu jedem Teil zu navigieren. Dies eliminierte den Zeiger-Overhead und trug maßgeblich zur 56-prozentigen Reduzierung der Cache-Eintragsgröße bei, die von 953 Bytes auf nur 420 Bytes pro Eintrag sank.
Weitere Optimierungen zielten auf Redundanz und strukturelle Ineffizienzen innerhalb des Caches ab. Cloudflare speichert den Namen des Eigentümers nicht mehr, wenn dieser die Abfrage dupliziert, sondern rekonstruiert ihn nur bei Bedarf aus dem Cache-Key. Um die Größe von Rust-Enums zu adressieren, die standardmäßig die Größe der größten Variante annehmen, wurde Boxing für große, seltene Datensatztypen wie NAPTR implementiert. Dadurch konnten kleinere, häufigere Datensätze wie A und AAAA deutlich weniger Speicherplatz belegen.
Die letzte große Änderung bestand darin, Datensatzdaten als rohe, längenpräfixierte wire-format bytes zu speichern, anstatt als vollständig geparste Rust-Structs. Dies umgeht den Speicher-Overhead des komplexen Typsystems von Rust für Daten, die nicht ständig geparst werden müssen, und verringert den In-Memory-Footprint über die 250 Milliarden Cache-Einträge von Big Pineapple weiter. Für einen tieferen Einblick in diese genialen Techniken zur Speichereinsparung können Leser How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache | Cloudflare Blog konsultieren.
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
Das Ergebnis: Schneller und kleiner
Die sorgfältige Daten-Neugestaltung führte zu einem beeindruckenden Ergebnis: Cloudflare reduzierte die typische Größe eines DNS-Cache-Eintrags von 953 Bytes auf nur 420 Bytes. Dies entspricht einer erheblichen Reduzierung des Speicherbedarfs um 56% pro Eintrag. Über die gesamte globale Flotte von Cloudflare, die mehr als 250 Milliarden Cache-Einträge verwaltet, konnte durch diese Optimierung eine erstaunliche Menge von 100 Terabyte an Gesamtspeicher zurückgewonnen werden, ohne einen einzigen neuen Server hinzuzufügen.
Entscheidend ist, dass diese Speichereinsparungen nicht zu Lasten der Leistung gingen; stattdessen beschleunigten sich die Vorgänge erheblich. Cache-Einfügungen wurden um 43% schneller und stiegen von 625.000 auf beeindruckende 893.000 Einträge pro Sekunde. Ebenso verzeichneten Suchanfragen eine Geschwindigkeitsverbesserung von 19%, wobei die Latenz von 828 Nanosekunden auf schnelle 670 Nanosekunden sank. Dieses seltene Win-Win-Szenario lieferte sowohl eine signifikante Ressourceneffizienz als auch eine verbesserte Betriebsgeschwindigkeit und widersprach damit den üblichen Kompromissen.
Cloudflare wird die frei gewordenen 100 Terabyte Speicher strategisch einsetzen, um die Kapazität seines DNS-Caches zu erweitern. Ein größerer, robusterer Cache ermöglicht es der "Big Pineapple"-Plattform, einen noch größeren Anteil der Abfragen lokal aufzulösen. Dies reduziert direkt die Notwendigkeit, Daten von Upstream-Servern abzurufen, was zu einer schnelleren DNS-Auflösung für Benutzer weltweit führt und die allgemeine Internetgeschwindigkeit für alle spürbar verbessert.
Häufig gestellte Fragen
Wie viel Speicher hat Cloudflare durch diese Optimierung eingespart?
Cloudflare hat in seiner globalen Flotte etwa 100 Terabyte (TB) RAM zurückgewonnen, was dem Speicher von etwa 130 Servern entspricht, ohne neue Hardware hinzuzufügen.
Hat die Speicheroptimierung das DNS von Cloudflare verlangsamt?
Nein, die Optimierungen hatten den gegenteiligen Effekt. Cache-Einfügungen wurden um 43% schneller und Suchanfragen um 19% schneller, was den häufigen Kompromiss zwischen Speichernutzung und Geschwindigkeit widerlegt.
Welche Programmiersprache hat Cloudflare verwendet, um dies zu erreichen?
Cloudflare verwendete die Programmiersprache Rust und nutzte deren Funktionen für eine fein abgestimmte Speicherkontrolle, um die Strukturierung von DNS-Cache-Einträgen neu zu schreiben.
Was war die wichtigste Änderung, die Cloudflare vorgenommen hat, um Speicher zu sparen?
Eine wesentliche Änderung war das Ersetzen von Standard-Rust-Datentypen wie Vec und String durch Box<[T]> und Box<str>. Dies eliminierte ein unnötiges 'capacity'-Feld für zwischengespeicherte Daten, die ihre Größe nie ändern, was 64 Bytes pro Eintrag einsparte.
Wie hat Cloudflare die Größe des DNS-Cache-Eintrags um 56% reduziert?
Sie implementierten fünf wichtige Änderungen auf Rust-Ebene: Eliminierung von Kapazitätsfeldern, Zusammenfassung von Datenabschnitten in einem einzigen Block mit Offsets, Entfernung redundanter Informationen, Boxing großer Enum-Varianten und Speicherung der Daten im rohen Wire-Format.