veilletech.frCe qui se passe
Quand un client modifie un enregistrement DNS ou un réglage de zone, le Zone Builder de Cloudflare transforme le changement en clés pour les serveurs DNS faisant autorité, puis les écrit dans Quicksilver, le magasin clé-valeur distribué de Cloudflare. Il reçoit aujourd'hui environ 700 changements d'enregistrements par seconde (250 en 2022), plus 100 événements divers, et certaines zones dépassent 20 millions d'enregistrements.
Le problème n'est pas le nombre d'événements, mais leur coût : un simple réglage de zone, comme l'activation d'Universal SSL (qui peut toucher les enregistrements CAA à l'apex), déclenchait une reconstruction de la zone entière, tenue en mémoire.
Le mécanisme
Un planificateur de builds ciblés choisit, parmi cinq types, le plus petit build dont la sûreté est prouvée :
| Type | Quand |
|---|---|
| Enregistrements seuls | A, AAAA, TXT, CNAME ordinaires |
| Enregistrements et métadonnées | changements de serveurs de noms ou de jokers |
| Apex et métadonnées | réglages comme Universal SSL |
| Suppression | zone qui ne doit plus être publiée |
| Zone complète | tout ce qui ne peut pas être prouvé plus petit |
La règle : chaque clé écrite par un build ciblé doit être identique, octet pour octet, à celle d'un build complet. Sinon, build complet. Un événement sans détail, ou une mise à jour d'horodatage seule, reste donc un build complet : le planificateur ne transforme jamais l'incertitude en travail en moins.
Un ordonnanceur unique remplace les deux anciens : il fusionne les événements d'une même zone en attente (on ne fait que ajouter du travail), garde le décompte des messages Kafka à acquitter, et n'avance la position validée dans Kafka qu'une fois tous les messages précédents terminés. Avant l'exécution, le planificateur relit un état frais depuis des réplicas, qui peut transformer un build ciblé en complet ou en suppression.
Les résultats
Sur 24 h : 86,81 % des builds en « enregistrements seuls », 2,54 % en « enregistrements et métadonnées », 2,30 % en « apex et métadonnées », 1,30 % de suppressions ; 92,95 % évitent la zone complète, 7,04 % restent complets. Les builds complets passent d'environ 11,88 % à 7,04 %.
- Mémoire : moyenne de 49 à 7 GiB (−86 %), pointe de 79 à 12 GiB (−85 %).
- Latence : plus gros pic au p99 de 14,6 à 1,21 min (divisé par 12) ; délai médian de 7,7 à 3,3 s, une fois raccourcis l'intervalle de reconstruction par zone et l'attente de l'agrégateur Kafka.
- Kafka : la consommation suit désormais la production, au lieu d'osciller de 300 à 1 550 messages par seconde.
Limites et déploiement
Les builds complets ne disparaissent pas : première publication d'une zone, événement sans détail. Pour les plus grandes zones, au-delà d'un seuil d'enregistrements, le Zone Builder ne se replie jamais sur un build complet, qui ne finirait pas ; il reconstruit l'apex, les métadonnées et les noms signalés.
La mise en production a suivi une méthode que n'importe quelle équipe peut copier : des tests d'équivalence build complet / build ciblé, puis un Zone Builder miroir qui consomme le flux Kafka de production, écrit dans un Quicksilver séparé, et dont un comparateur contrôle 20 % des zones (taux de différence de 0,31 % sur 234 313 zones appariées, écarts surtout dus au décalage). Déploiement progressif par hachage du nom de zone, zones gratuites d'abord.
Source : blog Cloudflare. Source en anglais.