Cloudflare économise 100 To de mémoire en réécrivant le cache DNS de 1.1.1.1

Cloudflare affirme avoir libéré environ 100 téraoctets de mémoire sur son infrastructure DNS en modifiant la représentation des entrées du cache de 1.1.1.1. Le résultat ne vient pas d’un nouvel algorithme spectaculaire, mais de cinq changements successifs dans du code Rust : moins d’allocations, des types mieux dimensionnés et une disposition mémoire plus compacte.

La réponse rapide

Cloudflare mesure ainsi une baisse de 56 % de l’empreinte, 43 % d’insertions supplémentaires par seconde et une lecture 19 % plus rapide. Ces chiffres concernent son environnement et ne constituent pas une promesse pour toutes les applications Rust.

À 250 milliards d’entrées, un octet devient une capacité

La plateforme Big Pineapple alimente notamment 1.1.1.1, Gateway DNS et DNS Firewall. Elle conserve plus de 250 milliards d’entrées en cache. À cette échelle, un octet inutile par entrée représente déjà plus de 250 Go dans l’ensemble du parc.

Le premier enseignement est méthodologique : la structure logique d’un objet ne révèle pas son coût réel. Un tableau dynamique, un pointeur, une longueur ou un alignement ajoutent des octets invisibles dans le modèle métier. Multipliés par des milliards, ces détails dominent le budget matériel.

Cinq petites décisions plutôt qu’une réécriture totale

Cloudflare a regroupé plusieurs sections DNS dans une allocation commune et remplacé certains pointeurs de 64 bits par des décalages sur 16 bits, suffisants pour compter les enregistrements contenus dans une réponse. L’équipe a également réduit les métadonnées du cache et évité des allocations séparées.

La meilleure structure n’est pas nécessairement la plus abstraite. Lorsque les bornes du domaine sont connues, un u16 peut être plus juste qu’un usize. Cette optimisation reste sûre seulement si la limite est contrôlée lors du décodage et couverte par des tests.

Pourquoi la vitesse progresse aussi

Réduire la mémoire ne sert pas uniquement à diminuer le nombre de serveurs. Des objets plus petits occupent moins de lignes de cache CPU, nécessitent moins d’allocations et produisent moins de travail pour l’allocateur. Les lectures deviennent plus locales et les insertions rencontrent moins de contention.

Cloudflare prévoit de réinvestir la mémoire libérée dans une capacité de cache supérieure. Un meilleur taux de hit réduit alors les requêtes envoyées aux serveurs DNS en amont. L’économie peut donc améliorer à la fois le coût, la latence et la résilience.

Ce qu’une équipe peut reprendre

Avant de compacter toutes les structures, mesurez la mémoire résidente en production et construisez un benchmark représentatif. Comparez la taille théorique, les allocations et le comportement du cache CPU. Déployez ensuite chaque changement séparément pour attribuer correctement le gain et détecter une régression.

Les formats compacts ont aussi un coût : code plus spécialisé, conversions supplémentaires et risque d’overflow. Documentez les bornes, testez les entrées extrêmes et conservez des métriques après le déploiement.

L’histoire des 100 To montre que l’optimisation à grande échelle commence souvent par la représentation des données. Le langage protège contre de nombreuses erreurs mémoire, mais il ne choisit pas automatiquement la structure la plus économique pour votre charge.