Cloudflare halbiert die DNS-Build-Verzögerung durch gezielte Planung

Cloudflare hat seine Pipeline zur DNS-Propagierung erheblich optimiert und die Zeit, die benötigt wird, um Änderungen an das globale Netzwerk zu übertragen, halbiert. Das Engineering-Team erreichte dies, indem es breite, ressourcenintensive vollständige Zone-Rebuilds durch einen neuen gezielten Build-Planer ersetzte, der die kleinste sichere Arbeitseinheit für jede Änderung identifiziert. Dieser architektonische Wandel reduzierte auch den Spitzen-Speicherverbrauch um 85 %, sodass das System Zonen mit Dutzenden von Millionen Datensätzen effizienter verarbeiten kann.

Was passiert ist

Die zentrale Herausforderung ergab sich aus dem wachsenden Umfang der DNS-Zonen im Cloudflare-Netzwerk. Während das Volumen der Ereignisse seit 2022 von 250 auf etwa 700 pro Sekunde gestiegen ist, war der primäre Engpass nicht der Durchsatz, sondern die Rechenkosten für die Verarbeitung großer Zonen. Einige Zonen enthalten nun über 20 Millionen Datensätze, eine Zahl, die voraussichtlich Hunderte von Millionen erreichen wird. Früher löste jede Änderung an einer Zoneneinstellung oder einem Datensatz oft einen vollständigen Build aus, der jeden Datensatz in der Datenbank liest, ihn in das Edge-Format konvertiert und ihn mit dem bestehenden Zustand vergleicht. Für massive Zonen ist dieser Prozess prohibitiv teuer und passt oft nicht in den Speicher.

Um dieses Problem zu lösen, entwickelten Cloudflare-Ingenieure einen gezielten Build-Planer und einen einheitlichen Scheduler. Der Planer analysiert eingehende Ereignisse, um genau zu bestimmen, welche Teile einer Zone geändert wurden, wie z. B. bestimmte DNS-Namen oder gemeinsame Metadaten, anstatt die gesamte Zone neu aufzubauen. Der Scheduler kombiniert dann mehrere ausstehende Ereignisse für dieselbe Zone in einem einzigen Ausführungsfenster. Dieser Ansatz stellt sicher, dass Änderungen an Zoneneinstellungen keine vollständigen Rebuilds mehr für Zonen mit Dutzenden von Millionen Datensätzen auslösen. Das Ergebnis ist eine Reduzierung der Zeit von einer DNS-Änderung bis zum Schreiben ihrer Daten in Quicksilver, den verteilten Key-Value-Speicher von Cloudflare, um 50 % und ein Rückgang des Spitzen-Speicherverbrauchs um 85 %.

Wie es funktioniert

Die Optimierung basiert darauf, zwischen verschiedenen Arten von DNS-Änderungen zu unterscheiden und sie bestimmten Build-Umfängen zuzuordnen. Das System klassifiziert Builds in fünf Kategorien: nur Ressourcen (für Standard-Datensatzänderungen wie A oder CNAME), Ressourcen und Metadaten (für Nameserver- oder Wildcard-Änderungen), Apex und Metadaten (für Einstellungen wie Universal SSL), Purge (für unveröffentlichte Zonen) und vollständige Zone (wenn die Sicherheit nicht nachgewiesen werden kann). Der Planer stellt sicher, dass jeder gezielte Build eine Ausgabe erzeugt, die bytegenau identisch mit der eines vollständigen Builds ist. Wenn das System nicht nachweisen kann, dass ein kleinerer Build sicher ist, greift es standardmäßig auf einen vollständigen Build zurück, vermeidet jedoch bei extrem großen Zonen vollständigere Builds, um eine Speichererschöpfung zu verhindern.

Ein kritischer Bestandteil dieses Systems ist die Handhabung gemeinsamer Metadaten. In der Architektur von Cloudflare können während Lifecycle-Ereignissen wie dem Onboarding mehrere interne Zonenobjekte für denselben öffentlichen Domainnamen existieren. Ein Schlüssel für gemeinsame Metadaten in Quicksilver fungiert als Verzeichnis, das den autoritativen Servern mitteilt, welche internen Zonen-IDs aktiv sind. Wenn eine Änderung diese Metadaten betrifft, wie z. B. ein Nameserver-Update, muss der Builder den gesamten gemeinsamen Schlüssel aktualisieren. Um Konsistenz zu gewährleisten, führt das System unmittelbar vor der Ausführung einen frischen Lesevorgang von Datenbank-Replikas durch. Dieser „doppelt geplante“ Ansatz berücksichtigt alle Datenbankänderungen, die zwischen dem ursprünglichen Ereignis und dem tatsächlichen Build aufgetreten sind, und verhindert so, dass veraltete oder falsche Daten an das Edge propagiert werden.

Wichtige Details

• Der Spitzen-Speicherverbrauch sank um 85 % dank der Eliminierung unnötiger vollständiger Zonen-Lesevorgänge für große Datensätze.
• Die Latenz bei der DNS-Propagierung wurde halbiert, was die Zeit von der Änderung bis zum Quicksilver-Schreibvorgang um 50 % verkürzt.
• Das System verarbeitet Zonen mit über 20 Millionen Datensätzen, wobei ein Wachstum in Richtung Hunderte von Millionen erwartet wird.
• Es werden fünf Build-Typen verwendet: nur Ressourcen, Ressourcen und Metadaten, Apex und Metadaten, Purge und vollständige Zone.
• Ein einheitlicher Scheduler kombiniert mehrere Ereignisse für dieselbe Zone in einem einzelnen Build, um die Effizienz zu verbessern.
• Frische Datenbank-Lesevorgänge erfolgen unmittelbar vor der Ausführung, um sicherzustellen, dass der Build den aktuellen Zustand widerspiegelt.

Warum es wichtig ist

Für Infrastruktur-Ingenieure und Plattform-Teams unterstreicht diese Fallstudie die Bedeutung der inkrementellen Verarbeitung in hochskalierenden Systemen. Wenn Datensätze wachsen, werden lineare Operationen wie vollständige Rebuilds nicht mehr tragfähig. Der Wechsel vom Modell „alles neu aufbauen“ zum Modell „nur das Geänderte neu aufbauen“ demonstriert, wie präzise Abhängigkeitsverfolgung erhebliche Leistungssteigerungen freisetzen kann. Dies ist besonders relevant für Teams, die große Konfigurationsspeicher oder zustandsbehaftete Dienste verwalten, bei denen sowohl Konsistenz als auch Geschwindigkeit kritisch sind. Die Fähigkeit, Sicherheit nachzuweisen, während der Arbeitsaufwand minimiert wird, ermöglicht es Systemen, ohne proportional steigende Rechenressourcen zu skalieren.

Der Ansatz bietet auch Lehren im Umgang mit eventual consistency und Race Conditions. Indem Cloudflare unmittelbar vor der Ausführung einen frischen Zustand von Replikas liest, mildert es das Risiko, auf veralteten Informationen zu handeln, ohne die Aufnahme-Pipeline zu blockieren. Dieses Muster aus konservativer Planung gefolgt von einer Last-Minute-Überprüfung ist eine robuste Strategie für verteilte Systeme, bei denen Ereignisreihenfolge und Replikationsverzögerungen inhärente Herausforderungen darstellen. Es zeigt, dass Resilienz nicht immer zusätzliche Wartezeiten erfordert; manchmal erfordert sie intelligentere Validierung am Punkt der Aktion.

Was Sie tun können

• Prüfen Sie Ihre Datenpipelines, um Prozesse zu identifizieren, die vollständige Rebuilds durchführen, wenn nur partielle Updates erforderlich sind.
• Implementieren Sie ein Klassifikationssystem für Änderungen, um den minimalen Arbeitsumfang für jeden Ereignistyp zu bestimmen.
• Nutzen Sie einen einheitlichen Scheduler, um verwandte Ereignisse zu bündeln, wodurch der Overhead durch wiederholtes Kontextwechseln und Setup reduziert wird.
• Überprüfen Sie den endgültigen Zustand gegen eine frische Quelle der Wahrheit unmittelbar vor der Ausführung, um Replikationsverzögerungen sicher zu handhaben.
• Legen Sie harte Grenzen für speicherintensive Operationen fest und definieren Sie Fallback-Strategien, wie z. B. partielle Rebuilds, für extreme Fälle.
• Stellen Sie sicher, dass jedes gezielte Update eine Ausgabe erzeugt, die identisch mit einem vollständigen Rebuild ist, um die Garantien für die Datenintegrität aufrechtzuerhalten.