Résumé :
Cloudflare a récemment réduit considérablement la mémoire cache utilisée par son résolveur DNS public 1.1.1.1, libérant ainsi environ 100 To de mémoire sur l'ensemble du réseau. Cette optimisation n'implique pas le remplacement du matériel du serveur ou la suppression de modules de mémoire, mais est réalisée en améliorant la méthode de stockage logiciel de mise en cache des données DNS.
Ce travail s'articule principalement autour du Big Pineapple. Big Pineapple est la plate-forme de mise en cache de Cloudflare qui prend en charge le résolveur 1.1.1.1, le pare-feu DNS et de nombreux autres services DNS. L'ingénieur système Cloudflare, Sebastiaan Neuteboom, a présenté dans un blog technique cinq ajustements à la base de code Rust qui ont réduit l'espace occupé par un seul enregistrement de cache DNS typique de 953 octets à 420 octets.
La vitesse de fonctionnement optimisée du système a également été améliorée. Cloudflare a déclaré que le débit d'insertion du cache est passé de 625 000 éléments par seconde à 893 000 éléments par seconde, et que la latence des requêtes est passée de 828 nanosecondes à 670 nanosecondes. Au cours du déploiement, de mi-mai à début juillet, l'utilisation de la mémoire au 99e centile par instance est passée de 9,3 Go à 5,3 Go.
Cloudflare affirme que Big Pineapple met en cache plus de 250 milliards d'enregistrements DNS à tout moment. À une telle échelle, même une infime quantité de mémoire gaspillée par enregistrement représente une quantité importante. La société estime que pour chaque octet inutile occupé dans une entrée de cache, l'ensemble du cluster de serveurs consomme plus de 250 Go de mémoire supplémentaire.
L'un des changements importants concerne les types Vec et String dans Rust. Ces conteneurs sont conçus pour s'étendre de manière dynamique, de sorte qu'en plus des données réelles, des informations supplémentaires telles que la capacité sont enregistrées. Cependant, l'enregistrement DNS n'a pas besoin d'être étendu une fois entré dans le cache. Cloudflare a ensuite remplacé ces structures par des tranches encadrées de taille fixe, supprimant les métadonnées qui n'étaient plus utiles. Selon l'entreprise, cet ajustement à lui seul a permis d'économiser plus de 15 To de mémoire.
Les ingénieurs ont également repensé la façon dont les réponses DNS sont organisées en mémoire. Auparavant, Big Pineapple enregistrait trois ensembles de listes d'enregistrements pour chaque réponse ; la nouvelle conception place tous les enregistrements dans le même tampon, puis utilise un décalage de deux octets pour identifier l'emplacement de chaque enregistrement.
Le cache ne conserve désormais plus les noms de propriétaires lorsqu'ils sont simplement des doublons du nom de domaine interrogé, mais est reconstruit lorsque la réponse est renvoyée. De plus, le système enregistre à la place les données d'enregistrement en utilisant des octets bruts au format de ligne DNS avec un préfixe de longueur, résolvant ainsi le problème d'espace perdu dans les conceptions antérieures. Auparavant, un enregistrement IPv4 A, qui n'occupait que 4 octets, occupait 144 octets, tout comme l'enregistrement NAPTR, relativement rare, le plus grand type d'enregistrement DNS mis en cache par Cloudflare. Le passage à un format de données brutes de longueur variable élimine le besoin d'enregistrements plus courts pour réserver le même espace que les enregistrements les plus longs.
Les 100 To de mémoire récupérés par Cloudflare sur l'ensemble du cluster de serveurs sont à peu près équivalents à la capacité de mémoire de 130 serveurs de 13e génération. Chacun de ces serveurs est équipé de 768 Go de mémoire DDR5-6400. Cloudflare a envisagé une configuration de mémoire de 1 152 Go pour cette génération de serveurs, mais a finalement abandonné après avoir évalué le coût d'une mémoire de plus grande capacité.
Avec cet espace mémoire, Cloudflare prévoit d'étendre la taille du cache DNS. La conservation locale d'un plus grand nombre d'enregistrements devrait améliorer les taux de réussite du cache et réduire le trafic des requêtes vers les serveurs DNS faisant autorité.
Ce n'est pas la première fois que Cloudflare procède à une optimisation à grande échelle de l'efficacité de la mémoire. L'année dernière, la société a également réécrit la couche FL2 responsable du traitement des requêtes en code Rust. Avec la hausse des prix de la mémoire serveur, libérer le potentiel de l’infrastructure existante grâce à l’optimisation logicielle peut s’avérer plus rentable que le simple ajout de matériel.
Commentaires