Cloudflare hat seine DNS-Propagationspipeline neu gestaltet, um einen wachsenden Strom von Änderungen an Einträgen und Zoneneinstellungen effizienter zu verarbeiten. Der Zone Builder erhält inzwischen etwa 700 DNS-Eintragsänderungen pro Sekunde sowie ungefähr 100 weitere Ereignisse, während einige Zonen mehr als 20 Millionen Einträge enthalten und voraussichtlich weiter wachsen.
Das Hauptproblem war nicht die Anzahl der Ereignisse, sondern der Arbeitsaufwand, den bestimmte Änderungen erforderten. Zuvor konnte ein Ereignis zu einer Zoneneinstellung einen vollständigen Neuaufbau auslösen: Jeder Eintrag wurde gelesen, in Quicksilver-Schlüssel umgewandelt und das Ergebnis mit dem bestehenden Zustand verglichen. Dieser Ansatz wurde für große Zonen zunehmend kostspielig und konnte mehr Arbeitsspeicher erfordern, als verfügbar war.
Cloudflare entwickelte einen gezielten Build-Planer, der die kleinste Operation auswählt, deren Sicherheit er nachweisen kann. Ein einheitlicher Scheduler kombiniert anschließend ausstehende Arbeiten für dieselbe Zone. Je nach Änderung kann das System bestimmte DNS-Namen neu aufbauen, diese Namen zusammen mit gemeinsamen Metadaten aktualisieren, den Zonenapex und die Metadaten neu aufbauen, eine Zone leeren oder einen vollständigen Zonen-Build durchführen.
Gewöhnliche Eintragsänderungen, etwa Aktualisierungen von A-, AAAA-, TXT- und CNAME-Einträgen, betreffen im Allgemeinen nur die Schlüssel der relevanten DNS-Namen. Änderungen an Nameservern und Wildcards können ebenfalls gemeinsame Metadaten betreffen, während Einstellungen wie Universal SSL möglicherweise den Neuaufbau des Apex und dieser Metadaten erfordern. Wenn das System nicht feststellen kann, dass eine kleinere Operation exakt dasselbe Ergebnis wie ein vollständiger Build erzeugt, bleibt der Pfad für den vollständigen Build bestehen.
Der Planer stützt sich auf detailliertere Ereignisse aus den Systemen, die Zonenänderungen erzeugen. Diese Ereignisse enthalten geänderte Einstellungen und, sofern verfügbar, deren vorherige und neue Werte. Mehrdeutige Ereignisse, fehlende Informationen und Aktualisierungen, die Einträge in der gesamten Zone beeinflussen könnten, lösen weiterhin einen vollständigen Build aus, anstatt das Risiko veralteter Daten am Edge einzugehen.
Cloudflare musste außerdem Domains berücksichtigen, die vorübergehend mehrere interne Zonenobjekte besitzen. Eintragsschlüssel werden für jede Zone separat gespeichert, während ein gemeinsamer Metadatenschlüssel angibt, welche Zonen mit demselben Namen veröffentlicht werden können. Wenn diese Metadaten betroffen sind, liest der Builder die aktuelle Kandidatenliste und rekonstruiert den Schlüssel aus dem aktuellen Zustand, statt einen Patch auf eine ältere Version anzuwenden.
Die Planung findet zweimal statt, weil sich die Datenbank ändern kann, nachdem ein Ereignis erzeugt wurde. Unmittelbar vor der Ausführung überprüft der Zone Builder die aktuellen Einstellungen, den Veröffentlichungsstatus für das betreffende Netzwerk und die neueste Liste der Zonen-IDs mit demselben Namen. Dadurch kann eine gezielte Operation in einen vollständigen Build umgewandelt, in eine Löschung geändert, übersprungen oder der Neuaufbau des gemeinsamen Metadatenschlüssels erforderlich werden.
Der Scheduler führt ausstehende Änderungen für eine Zone zusammen, fügt betroffene Namen hinzu und bewahrt Anforderungen an Metadaten. Eine Löschung hat Vorrang vor Neuaufbauoperationen. Kafka-Bestätigungen werden getrennt von der DNS-Arbeit verfolgt, sodass Wiederholungen keine Nachrichten verlieren, selbst wenn mehrere Ereignisse zu einem einzigen Build zusammengeführt wurden.
Um die geordnete Kafka-Verarbeitung zu schützen, verwendet Cloudflare ein sogenanntes Soft Committing. Ein abgeschlossener Build kann im Arbeitsspeicher vermerkt werden, bevor frühere Arbeiten in derselben Partition abgeschlossen sind; der von Kafka bestätigte Offset wird jedoch erst weitergeschoben, wenn alle vorhergehenden Nachrichten fertiggestellt wurden. Wenn der Builder neu startet, werden diese im Arbeitsspeicher gespeicherten Abschlüsse erneut abgespielt, anstatt den Verlust einer Änderung zu riskieren.
Bei sehr großen Zonen vermeidet das System oberhalb eines festen Schwellenwerts für die Anzahl der Einträge die Eskalation zu einem vollständigen Build, da das Halten sämtlicher Einträge und vorhandener Quicksilver-Schlüssel im Arbeitsspeicher verhindern kann, dass der Build abgeschlossen wird. Stattdessen baut es den Apex, die Metadaten und die durch in der Warteschlange befindliche Ereignisse identifizierten Namen neu auf. Dieser Ansatz verringert das Risiko, dass ein nicht abschließbarer Build andere Änderungen auf derselben Kafka-Partition blockiert.
Cloudflare testete gezielte Builds gegen vollständige Builds, indem die relevanten Quicksilver-Schlüssel Byte für Byte verglichen wurden. Außerdem stellte das Unternehmen einen spiegelnden Zone Builder bereit, der Produktionsereignisse und den Datenbankzustand verarbeitete und in eine isolierte Quicksilver-Umgebung schrieb. Ein Vergleichssystem überprüfte eine Stichprobe von Zonen auf fehlende Schlüssel, zusätzliche Schlüssel und abweichende Werte, bevor der neue Scheduler schrittweise ausgerollt wurde.
Die daraus resultierenden Änderungen reduzierten vollständige Builds um 40 %, senkten den Spitzenverbrauch an Arbeitsspeicher um 85 % und halbierten die Verzögerung zwischen einer DNS-Änderung und dem Schreiben ihrer Daten in Quicksilver. Während eines Messzeitraums von 24 Stunden wurden 86,81 % der Builds als reine Ressourcenoperationen eingestuft, während bei 2,54 % die Ressourcen zusammen mit den Metadaten neu aufgebaut wurden.
Quellen: Cloudflare Blog.