Cloudflare réduit de moitié le délai de construction DNS grâce à une planification ciblée

Cloudflare a considérablement optimisé son pipeline de propagation DNS, réduisant de moitié le temps nécessaire pour appliquer les modifications sur son réseau mondial. L'équipe d'ingénierie y est parvenue en remplaçant les reconstructions complètes des zones, larges et gourmandes en ressources, par un nouveau planificateur de construction ciblée qui identifie la plus petite unité de travail sûre pour chaque modification. Ce changement architectural a également permis de réduire la consommation maximale de mémoire de 85 %, permettant au système de gérer plus efficacement les zones contenant des dizaines de millions d'enregistrements.

Ce qui s'est passé

Le défi principal découlait de la croissance de l'échelle des zones DNS sur le réseau de Cloudflare. Alors que le volume d'événements est passé de 250 à environ 700 par seconde depuis 2022, le goulot d'étranglement principal n'était pas le débit, mais le coût computationnel du traitement des grandes zones. Certaines zones contiennent désormais plus de 20 millions d'enregistrements, un chiffre qui devrait atteindre des centaines de millions. Auparavant, toute modification d'un paramètre de zone ou d'un enregistrement déclenchait souvent une reconstruction complète, qui lit chaque enregistrement dans la base de données, le convertit au format edge et le compare à l'état existant. Pour les zones massives, ce processus est prohibitif en termes de coûts et il est souvent impossible de le faire tenir dans la mémoire.

Pour résoudre ce problème, les ingénieurs de Cloudflare ont développé un planificateur de construction ciblée et un ordonnanceur unifié. Le planificateur analyse les événements entrants pour déterminer exactement quelles parties d'une zone ont changé, comme des noms DNS spécifiques ou des métadonnées partagées, plutôt que de reconstruire toute la zone. L'ordonnanceur combine ensuite plusieurs événements en attente pour la même zone dans une seule fenêtre d'exécution. Cette approche garantit que les modifications des paramètres de zone ne déclenchent plus de reconstructions complètes pour les zones contenant des dizaines de millions d'enregistrements. Le résultat est une réduction de 50 % du temps entre une modification DNS et l'écriture de ses données dans Quicksilver, le magasin clé-valeur distribué de Cloudflare, ainsi qu'une baisse de 85 % de l'utilisation maximale de la mémoire.

Comment cela fonctionne

L'optimisation repose sur la distinction entre différents types de modifications DNS et leur association à des portées de construction spécifiques. Le système classe les constructions en cinq catégories : ressources uniquement (pour les modifications standard d'enregistrements comme A ou CNAME), ressources et métadonnées (pour les modifications de serveurs de noms ou de caractères génériques), apex et métadonnées (pour les paramètres comme Universal SSL), purge (pour les zones non publiées) et zone complète (lorsque la sécurité ne peut être prouvée). Le planificateur garantit que toute construction ciblée produit une sortie identique octet par octet à celle générée par une construction complète. Si le système ne peut pas prouver qu'une construction plus petite est sûre, il revient à une construction complète, bien que pour les zones extrêmement grandes, il évite totalement les constructions complètes afin de prévenir l'épuisement de la mémoire.

Un composant critique de ce système est la gestion des métadonnées partagées. Dans l'architecture de Cloudflare, plusieurs objets de zone internes peuvent exister pour le même nom de domaine public lors d'événements du cycle de vie tels que l'intégration initiale. Une clé de métadonnées partagées dans Quicksilver agit comme un répertoire, indiquant aux serveurs autoritatifs quels ID de zones internes sont actifs. Lorsqu'une modification affecte ces métadonnées, comme une mise à jour des serveurs de noms, le constructeur doit rafraîchir toute la clé partagée. Pour assurer la cohérence, le système effectue une lecture fraîche depuis les répliques de la base de données immédiatement avant l'exécution. Cette approche « planifier deux fois » tient compte de tout changement dans la base de données survenu entre l'événement initial et la construction réelle, empêchant la propagation de données obsolètes ou incorrectes vers l'edge.

Détails clés

• L'utilisation maximale de la mémoire a chuté de 85 % grâce à l'élimination des lectures inutiles de zones complètes pour les grands jeux de données.
• La latence de propagation DNS a été réduite de moitié, diminuant de 50 % le temps entre la modification et l'écriture dans Quicksilver.
• Le système gère des zones contenant plus de 20 millions d'enregistrements, avec des prévisions de croissance vers des centaines de millions.
• Cinq types de construction sont utilisés : ressources uniquement, ressources et métadonnées, apex et métadonnées, purge et zone complète.
• Un ordonnanceur unifié combine plusieurs événements pour la même zone en une seule construction pour améliorer l'efficacité.
• Des lectures fraîches de la base de données sont effectuées immédiatement avant l'exécution pour garantir que la construction reflète l'état actuel.

Pourquoi c'est important

Pour les ingénieurs d'infrastructure et les équipes de plateforme, cette étude de cas souligne l'importance du traitement incrémental dans les systèmes à grande échelle. À mesure que les jeux de données augmentent, les opérations linéaires comme les reconstructions complètes deviennent intenable. Le passage d'un modèle « tout reconstruire » à un modèle « ne reconstruire que ce qui a changé » démontre comment un suivi précis des dépendances peut libérer des gains de performance significatifs. Cela est particulièrement pertinent pour les équipes gérant des magasins de configuration à grande échelle ou des services avec état où la cohérence et la vitesse sont toutes deux critiques. La capacité à prouver la sécurité tout en minimisant le travail permet aux systèmes de passer à l'échelle sans augmentation proportionnelle des ressources de calcul.

Cette approche offre également des leçons sur la gestion de la cohérence éventuelle et des conditions de concurrence. En lisant l'état frais depuis les répliques juste avant l'exécution, Cloudflare atténue le risque d'agir sur des informations obsolètes sans bloquer le pipeline d'ingestion. Ce modèle de planification prudente suivie d'une vérification de dernière minute est une stratégie robuste pour les systèmes distribués où l'ordre des événements et le retard de réplication de la base de données sont des défis inhérents. Il montre que la résilience n'exige pas toujours d'ajouter des temps d'attente ; parfois, elle nécessite une validation plus intelligente au moment de l'action.

Ce que vous pouvez faire

• Auditez vos pipelines de données pour identifier les processus qui effectuent des reconstructions complètes lorsque seules des mises à jour partielles sont nécessaires.
• Implémentez un système de classification des modifications pour déterminer la portée minimale du travail requis pour chaque type d'événement.
• Utilisez un ordonnanceur unifié pour regrouper les événements liés, réduisant la surcharge due aux changements de contexte et configurations répétitifs.
• Vérifiez l'état final contre une source de vérité fraîche immédiatement avant l'exécution pour gérer le retard de réplication en toute sécurité.
• Définissez des limites strictes sur les opérations gourmandes en mémoire et établissez des stratégies de repli, telles que des reconstructions partielles, pour les cas extrêmes.
• Assurez-vous que toute mise à jour ciblée produit une sortie identique à une reconstruction complète pour maintenir les garanties d'intégrité des données.