Cloudflare a repensé son pipeline de propagation DNS afin de traiter plus efficacement un flux croissant de modifications d’enregistrements et de paramètres de zone. Le Zone Builder reçoit désormais environ 700 modifications d’enregistrements DNS par seconde, auxquelles s’ajoutent environ 100 autres événements, tandis que certaines zones contiennent plus de 20 millions d’enregistrements et devraient continuer à croître.
Le principal problème ne résidait pas dans le nombre d’événements, mais dans la quantité de travail nécessaire pour certaines modifications. Auparavant, un événement concernant les paramètres d’une zone pouvait déclencher une reconstruction complète : la lecture de chaque enregistrement, sa conversion en clés Quicksilver et la comparaison du résultat avec l’état existant. Cette approche devenait de plus en plus coûteuse pour les grandes zones et pouvait nécessiter davantage de mémoire que ce qui était disponible.
Cloudflare a créé un planificateur de constructions ciblées qui sélectionne l’opération la plus limitée dont il peut démontrer la sûreté. Un ordonnanceur unifié regroupe ensuite les tâches en attente pour une même zone. Selon la modification, le système peut reconstruire des noms DNS spécifiques, mettre à jour ces noms ainsi que les métadonnées partagées, reconstruire l’apex de la zone et les métadonnées, purger une zone ou effectuer une construction complète de la zone.
Les modifications ordinaires d’enregistrements, telles que les mises à jour d’enregistrements A, AAAA, TXT et CNAME, n’affectent généralement que les clés correspondant aux noms DNS concernés. Les modifications de serveurs de noms et de caractères génériques peuvent également affecter les métadonnées partagées, tandis que des paramètres tels qu’Universal SSL peuvent nécessiter la reconstruction de l’apex et de ces métadonnées. Lorsque le système ne peut pas établir qu’une opération plus limitée produira exactement le même résultat qu’une construction complète, il conserve le chemin de construction complète.
Le planificateur s’appuie sur des événements plus détaillés provenant des systèmes qui produisent les modifications de zone. Ces événements comprennent les paramètres modifiés et, lorsque ces informations sont disponibles, leurs valeurs précédentes et nouvelles. Les événements ambigus, les informations manquantes et les mises à jour susceptibles d’affecter des enregistrements dans toute la zone continuent de déclencher une construction complète plutôt que de risquer de laisser des données obsolètes en périphérie.
Cloudflare a également dû prendre en compte les domaines qui possèdent temporairement plusieurs objets de zone internes. Les clés d’enregistrements sont stockées séparément pour chaque zone, tandis qu’une clé de métadonnées partagée identifie les zones portant le même nom qui peuvent être publiées. Lorsque ces métadonnées sont concernées, le constructeur lit la liste actuelle des candidats et reconstruit la clé à partir de l’état actualisé, au lieu d’appliquer un correctif à une ancienne version.
La planification a lieu deux fois, car la base de données peut changer après la génération d’un événement. Immédiatement avant l’exécution, le Zone Builder vérifie les paramètres actuels, l’état de publication pour le réseau concerné et la dernière liste des identifiants de zones portant le même nom. Cette vérification peut transformer une opération ciblée en construction complète, la convertir en purge, l’ignorer ou exiger la reconstruction de la clé de métadonnées partagée.
L’ordonnanceur fusionne les modifications en attente pour une zone, en ajoutant les noms concernés et en conservant les exigences relatives aux métadonnées. Une purge est prioritaire sur les opérations de reconstruction. Les accusés de réception Kafka sont suivis séparément du travail DNS, ce qui garantit que les nouvelles tentatives ne perdent pas de messages, même lorsque plusieurs événements ont été regroupés en une seule construction.
Pour préserver le traitement ordonné de Kafka, Cloudflare utilise une validation différée. Une construction terminée peut être enregistrée en mémoire avant la fin des travaux précédents de la même partition, mais l’offset validé par Kafka n’avance qu’une fois tous les messages précédents terminés. Si le constructeur redémarre, ces tâches terminées conservées en mémoire sont rejouées, plutôt que de risquer la perte d’une modification.
Pour les très grandes zones, le système évite de passer à une construction complète au-delà d’un seuil fixe de nombre d’enregistrements, car le fait de conserver en mémoire tous les enregistrements et les clés Quicksilver existantes peut empêcher la construction d’aboutir. Il reconstruit à la place l’apex, les métadonnées et les noms identifiés par les événements en attente. Cette approche réduit le risque qu’une construction impossible à terminer bloque d’autres modifications sur la même partition Kafka.
Cloudflare a testé les constructions ciblées par rapport aux constructions complètes en comparant octet par octet les clés Quicksilver concernées. L’entreprise a également déployé un Zone Builder miroir qui consommait les événements de production et l’état de la base de données tout en écrivant dans un environnement Quicksilver isolé. Un comparateur vérifiait un échantillon de zones afin de détecter les clés manquantes, les clés supplémentaires et les valeurs différentes avant le déploiement progressif du nouvel ordonnanceur.
Ces changements ont réduit de 40 % les constructions complètes, diminué de 85 % l’utilisation maximale de la mémoire et réduit de moitié le délai entre une modification DNS et l’écriture de ses données dans Quicksilver. Au cours d’une période de mesure de 24 heures, 86,81 % des constructions ont été classées comme des opérations portant uniquement sur les ressources, tandis que 2,54 % reconstruisaient les ressources avec les métadonnées.
Sources: Cloudflare Blog.