Speicherbedarf: Cloudflare gibt durch Optimierung 100 Terabyte RAM frei

Ein massiver Effizienzgewinn im Cloudflare-Netzwerk

Das Unternehmen Cloudflare hat einen bedeutenden technischen Erfolg bei der Optimierung seiner Infrastruktur erzielt. Wie der Netzbetreiber am 28. August 2026 bekannt gab, gelang es den Entwicklern, den Speicherbedarf seines DNS-Dienstes 1.1.1.1 drastisch zu senken. Im Zentrum der Bemühungen stand die DNS-Cache-Plattform mit der internen Bezeichnung „Big Pineapple“. Da das System zu jedem beliebigen Zeitpunkt mehr als 250 Milliarden DNS-Cache-Einträge vorhalten muss, führt bereits eine minimale Ineffizienz bei der Speicherung jedes einzelnen Datensatzes zu einer massiven Belastung der gesamten Serverflotte. Die Ingenieure haben durch eine Serie von fünf aufeinanderfolgenden technischen Anpassungen den Speicherbedarf pro Eintrag um mehr als die Hälfte reduziert. Das Ergebnis dieser Bemühungen ist eine dauerhafte Einsparung von rund 100 Terabyte an Arbeitsspeicher über das gesamte globale Netzwerk hinweg. Diese Optimierung ist ein Beispiel dafür, wie bei einer derart hohen Skalierung bereits die Einsparung von nur einem einzigen Byte pro Eintrag eine signifikante Entlastung von über 250 Gigabyte im Gesamtsystem bewirken kann.

Technische Details der Speicheroptimierung

Die von Cloudflare durchgeführten Optimierungen lassen sich in fünf spezifische Schritte unterteilen, die in der Programmiersprache Rust umgesetzt wurden. Zunächst ersetzten die Entwickler dynamische Datenstrukturen wie „Vec“ und „String“ durch unveränderbare Alternativen wie „Box<[T]>“ und „Box<str>“. Da DNS-Antworten nach dem Caching nicht mehr modifiziert werden müssen, war das Feld für die zukünftige Kapazitätserweiterung überflüssig. Allein dieser erste Schritt sparte 64 Byte pro Eintrag und reduzierte den ungenutzten Heap-Speicher, was in der Summe 15 Terabyte einsparte. Im zweiten Schritt wurden die separaten Listen für Antwort-, Autoritäts- und Zusatzsektionen zusammengefasst und über 2-Byte-Offsets adressiert, was weitere 28 Byte pro Eintrag einsparte. Drittens wurde das Feld für den Domainnamen optional gestaltet, da dieser meist mit der angefragten Domain identisch ist. Viertens wurde das Speicherlayout des Rust-Datentyps „Enum“ optimiert. Da bisher das gesamte Enum so groß wie seine größte Variante (NAPTR-Records mit 136 Byte) war, verschwendeten A- und AAAA-Records viel Platz. Durch das Auslagern seltener Varianten schrumpfte die Größe für häufige Typen von 144 auf 24 Byte. Fünftens wurden die Daten im rohen „Wire-Format“ als zusammenhängendes Byte-Array abgelegt. Dies senkte den Netto-Speicherbedarf von 953 auf 420 Byte pro Eintrag.

Der Hintergrund der DNS-Infrastruktur

Die DNS-Plattform „Big Pineapple“ bildet das Rückgrat für den Dienst 1.1.1.1, der als einer der weltweit am stärksten genutzten DNS-Resolver fungiert. Die Notwendigkeit zur Optimierung ergab sich direkt aus der schieren Größe des Datenaufkommens. Da Cloudflare Milliarden von Anfragen pro Sekunde verarbeitet, ist das Caching von DNS-Informationen essenziell, um Latenzzeiten gering zu halten und die Stabilität des Internets zu gewährleisten. Die Herausforderung besteht darin, dass die Speicherkosten bei einer derartigen Skalierung exponentiell steigen. Wenn ein System darauf ausgelegt ist, 250 Milliarden Einträge gleichzeitig im Arbeitsspeicher zu halten, ist jede Speicherverschwendung nicht nur ein theoretisches Problem, sondern ein direkter Kosten- und Effizienzfaktor für die Hardware-Infrastruktur. Die Entscheidung, die Speicherverwaltung grundlegend zu überarbeiten, war daher eine strategische Notwendigkeit, um das Wachstum des Dienstes ohne eine proportionale Steigerung der Hardware-Kosten fortsetzen zu können. Die Umstellung auf effizientere Datenstrukturen in Rust zeigt dabei den hohen Anspruch an die Performance-Optimierung auf Systemebene.

Die beteiligten Akteure und Institutionen

An diesem Prozess waren primär die Entwicklerteams von Cloudflare beteiligt, die für die Wartung und Weiterentwicklung der globalen DNS-Infrastruktur verantwortlich sind. Die Informationen zu den technischen Änderungen wurden durch das Unternehmen selbst in einem offiziellen Blogbeitrag publiziert, der als Primärquelle für die Details der Optimierungen dient. Als technischer Rahmen für die Implementierung diente die Programmiersprache Rust, deren Typsystem und Speicherverwaltungsmöglichkeiten maßgeblich dazu beitrugen, die genannten Einsparungen zu realisieren. Externe Institutionen, Nutzer oder andere Drittanbieter werden in dem Bericht nicht als direkt Beteiligte an diesem spezifischen Optimierungsprozess genannt. Die Verantwortung für die Architektur der Plattform „Big Pineapple“ und die Entscheidung zur Implementierung der fünf Optimierungsschritte lag ausschließlich bei den internen Ingenieuren von Cloudflare, die das Ziel verfolgten, die Effizienz des gesamten Servernetzwerks nachhaltig zu steigern.

Einordnung der technischen Maßnahmen

Einzuordnen ist dieser Erfolg als eine bemerkenswerte Leistung im Bereich des Software-Engineerings für hochskalierbare Systeme. Eine Reduktion des Speicherbedarfs um 56 Prozent bei gleichzeitigem Rückgang der Allokationen um 58 Prozent ist in der Softwareentwicklung ein herausragendes Ergebnis. Den Berichten zufolge zeigt dies, dass selbst bei bereits hochoptimierten Systemen durch eine tiefgreifende Analyse der Datenstrukturen und eine Anpassung an die spezifischen Nutzungsmuster – wie etwa das häufige Vorkommen von A- und AAAA-Records gegenüber seltenen NAPTR-Records – erhebliche Ressourcen freigesetzt werden können. Die Entscheidung, das „Wire-Format“ direkt als Byte-Array zu speichern, deutet darauf hin, dass die Entwickler einen Kompromiss zwischen Speicherplatz und CPU-Last zugunsten des Speichers gewählt haben, da die Daten nun nicht mehr für die Übertragung umgewandelt werden müssen. Diese Maßnahme unterstreicht die Bedeutung von „Zero-Copy“-Ansätzen in der modernen Netzwerkprogrammierung, bei denen Daten so wenig wie möglich transformiert werden, um sowohl Speicher als auch Rechenzeit zu sparen.

Offene Fragen zur weiteren Entwicklung

Der Quelltext lässt einige Fragen offen, die für eine vollständige technische Bewertung relevant wären. Es wird nicht explizit dargelegt, welche Auswirkungen die Optimierungen auf die CPU-Auslastung der Server haben. Während der Speicherbedarf gesunken ist, könnte die Komplexität der Datenzugriffe durch das Auslagern seltener Datensatzvarianten oder das Parsing des Wire-Formats die Prozessorlast beeinflussen. Zudem bleibt offen, wie hoch die Kosten für die Implementierung dieser Änderungen in Bezug auf die Entwicklungszeit waren. Auch wird nicht präzisiert, ob die 100 Terabyte an freigewordenem RAM nun in allen Rechenzentren weltweit gleichermaßen zur Verfügung stehen oder ob dies ein Durchschnittswert über die gesamte Flotte ist. Des Weiteren gibt der Text keine Auskunft darüber, ob die Optimierungen auch die Latenz bei der DNS-Auflösung für den Endnutzer messbar verbessert haben oder ob der Fokus rein auf der Kapazitätserweiterung lag. Auch die langfristige Wartbarkeit des nun komplexeren Speicherlayouts bleibt eine offene Frage.

Wie es in der Cloudflare-Infrastruktur weitergeht

Die unmittelbare Konsequenz der durchgeführten Optimierungen ist bereits definiert: Cloudflare plant, den durch die Maßnahmen freigewordenen Arbeitsspeicher nicht einfach ungenutzt zu lassen oder Hardware zu reduzieren. Stattdessen soll die gewonnene Kapazität direkt dazu verwendet werden, die Cache-Kapazität des DNS-Dienstes 1.1.1.1 weiter zu erhöhen. Dies bedeutet, dass das Unternehmen in der Lage sein wird, eine noch größere Anzahl an DNS-Einträgen im schnellen Arbeitsspeicher vorzuhalten, anstatt auf langsamere Speichermedien oder eine erneute Abfrage der Ursprungsserver angewiesen zu sein. Damit wird die Trefferquote des Caches („Cache Hit Rate“) voraussichtlich steigen, was die Performance des Dienstes für die Nutzer weiter verbessern dürfte. Konkrete Termine für die vollständige Implementierung der Kapazitätserweiterung auf allen Servern wurden nicht genannt, jedoch ist der Prozess als Teil der kontinuierlichen Weiterentwicklung der Plattform „Big Pineapple“ zu verstehen, die auch in Zukunft auf eine maximale Ausnutzung der vorhandenen Hardware-Ressourcen ausgerichtet bleibt.