Contexte et enjeux

En 2022, le pipeline de propagation DNS de Cloudflare traitait environ 250 changements d’enregistrements par seconde. Aujourd’hui, le débit a atteint 700 événements /s, auxquels s’ajoutent ~100 événements de type réglage de zone. Certaines zones contiennent plus de 20 millions d’enregistrements et la tendance est à la hausse, avec des prévisions de plusieurs centaines de millions. Le facteur limitant n’était pas le nombre d’événements, mais la charge générée par chaque construction (build) de zone, qui croît avec la taille de la zone.

Un build consiste à lire l’état actuel de la base, le convertir au format utilisé aux bords du réseau et écrire les différences dans Quicksilver, le magasin clé‑valeur distribué. En 2022, les builds « per‑record » étaient 150 fois plus rapides que les builds complets, et sur une zone de 1 M d’enregistrements, ils étaient 4 250 fois plus rapides. Malgré ces gains, les builds complets restaient impossibles à exécuter pour les zones de plusieurs dizaines de millions d’enregistrements, car ils nécessitaient de charger l’ensemble de la zone en mémoire.

Architecture du pipeline DNS

Le flux se compose de plusieurs étapes : un client modifie un enregistrement via l’API DNS Records ou un autre service Cloudflare, la modification est persistée en base, un événement Kafka est produit, l’agrégateur Kafka regroupe les événements et les transmet au Zone Builder. Ce dernier lit les données nécessaires, génère les clés Quicksilver (réponses DNS) et compare ces clés avec celles déjà stockées. Seules les clés modifiées sont écrites, ce qui minimise le trafic réseau, mais chaque build complet lit, encode et compare chaque enregistrement, ce qui consomme une quantité de mémoire proportionnelle à la taille de la zone.

Planificateur de builds ciblés

Pour réduire la charge, Cloudflare a introduit deux composants : un planificateur de builds ciblés et un ordonnanceur qui regroupe les travaux par zone. Le planificateur analyse chaque événement Kafka enrichi : il indique les champs de zone modifiés, les valeurs précédentes et nouvelles. En fonction du type d’événement, le planificateur sélectionne l’un des cinq modèles de build : Resources only (reconstruction de noms DNS spécifiques), Resources and metadata, Apex and metadata, Purge ou Full zone. La règle de sécurité impose que chaque clé écrite soit identique à celle produite par un build complet; en cas d’incertitude, le système bascule sur un build complet.

Le nouveau scheduler combine les travaux provenant de plusieurs événements pour la même zone, évitant ainsi des reconstructions redondantes. Cette agrégation, couplée au ciblage précis, a permis de réduire l’utilisation maximale de mémoire de 85 % et de diminuer de moitié le délai entre une modification DNS et son écriture dans Quicksilver.

Résultats et limites

Après déploiement, le pipeline gère désormais ~700 événements /s sans saturer la mémoire, même pour des zones de 20 M d’enregistrements. La latence moyenne d’un build ciblé est passée de plusieurs secondes à moins d’une seconde, ce qui améliore la résilience du service en offrant plus de marge pour les pics de trafic. Cependant, le système dépend de la précision des événements : les mises à jour qui ne précisent pas le champ modifié (par ex. un simple timestamp) déclenchent encore des builds complets, conservant une part de charge non optimisée. De plus, la complexité du planificateur augmente la surface de code, ce qui nécessite une surveillance accrue pour éviter des régressions de sécurité ou de cohérence des données.