Le problème des 100 téraoctets
Cloudflare a récemment réalisé un incroyable casse mémoire, libérant 100 téraoctets de capacité opérationnelle sur l'ensemble de son réseau mondial. Cette optimisation remarquable équivaut à ajouter la capacité RAM totale de 130 serveurs Gen 13 modernes à leur infrastructure, sans déployer un seul nouveau matériel. Une telle récupération massive souligne l'impact profond de l'efficacité logicielle de bas niveau.
Alimentant des services critiques comme 1.1.1.1, Gateway DNS et DNS Firewall, la plateforme Big Pineapple de Cloudflare gère une échelle immense. À tout moment, ce système stocke plus de 250 milliards d'entrées de cache DNS, chacune représentant une information cruciale de routage internet, facilitant des milliards de requêtes mondiales quotidiennement. Cette échelle immense transforme même des inefficacités mineures en défis opérationnels et financiers significatifs.
Le défi principal pour Cloudflare résidait dans l'effet cumulatif de surcoûts apparemment minuscules. Avec 250 milliards d'entrées DNS, un seul octet gaspillé par entrée se multiplie en centaines de gigaoctets de mémoire superflue sur l'ensemble de la global fleet. Cette inefficacité microscopique, mise à l'échelle sur un système aussi vaste, ne consomme pas seulement des ressources précieuses ; elle peut également impacter les performances et augmenter les coûts opérationnels, exigeant une réévaluation fondamentale des structures de données.
Cinq coupes, un gain massif
Cloudflare a exécuté cinq optimisations précises au niveau Rust, chacune étant une frappe chirurgicale contre l'encombrement mémoire, aboutissant à un gain massif de 100 To. Avant tout, les ingénieurs ont remplacé Vec<T> et String par Box<[T]> et Box<str> pour les entrées de cache immuables. Cela a éliminé la capacité pré-allouée et le surcoût inutile du tas, libérant immédiatement 64 octets par entrée et plus de 15 To à l'échelle de la flotte.
Un deuxième changement critique a impliqué le stockage des enregistrements DNS sous forme de raw wire-format bytes, plutôt que sous forme de structures Rust entièrement analysées. Cela a rationalisé le traitement, car le système évite désormais l'analyse et la sérialisation redondantes. Cela a également considérablement amélioré la cache locality, en regroupant davantage de données pertinentes dans moins de lignes de cache.
D'autres astuces de mise en page ont permis d'éviter le gaspillage de mémoire. Cloudflare a mis en boîte (boxed) les grandes enum variants, telles que NAPTR au sein de l'énumération RecordData, pour empêcher les types d'enregistrements plus petits et plus courants (comme A et AAAA) de réserver un remplissage excessif. Cela a permis de s'assurer que l'allocation mémoire correspondait plus étroitement à la taille réelle des données.
Les ingénieurs ont également fusionné trois listes distinctes d'enregistrements de réponse DNS (réponse, autorité, additionnel) en une seule liste unifiée. Deux décalages compacts u16 de 2 octets délimitent désormais les sections, remplaçant les paires pointeur/longueur plus grandes et économisant 28 octets par entrée. Cette consolidation a considérablement resserré la structure des données.
Enfin, le stockage conditionnel du propriétaire a représenté la cinquième coupe. Cloudflare stocke désormais le nom du propriétaire uniquement lorsqu'il diffère du domaine interrogé, en le déduisant de la clé de cache dans le cas contraire. Combinées, ces optimisations granulaires ont réduit l'empreinte par entrée de 56 %, passant de 953 octets à 420 octets, transformant ainsi le paysage mémoire de Cloudflare.
Plus rapide en devenant plus petit
Réduire les structures de données implique souvent un compromis sur les performances, mais les optimisations de Cloudflare ont permis une double victoire rare. Le débit d'insertion dans le cache a bondi de 43 %, passant de 625 000 à 893 000 entrées par seconde. Parallèlement, la latence de recherche a chuté de manière significative, s'améliorant de 19 %, passant de 828 ns à 670 ns.
Cette accélération n'est pas de la magie ; c'est une conséquence directe de la densité de la mémoire. En réduisant l'empreinte mémoire par entrée de cache DNS de 56 % (de 953 octets à 420 octets), les structures de données de Cloudflare sont devenues plus compactes. Des données plus petites occupent moins d'espace, ce qui permet à un plus grand nombre d'entrées de cache de tenir dans les caches L1, L2 et L3 plus rapides du processeur, améliorant ainsi la localité du cache CPU.
Imaginez cela comme le rangement d'un garde-manger : un emballage plus petit signifie que vous pouvez stocker davantage d'articles fréquemment utilisés sur les étagères avant facilement accessibles. Les processeurs passent moins de temps à récupérer des données dans la mémoire principale (RAM) plus lente et plus de temps à les traiter directement à partir de ces caches haute vitesse, ce qui réduit considérablement les temps d'attente.
Une telle amélioration profonde, tant au niveau de la consommation des ressources que de la vitesse opérationnelle, est une rareté en ingénierie, défiant les compromis habituels entre l'utilisation de la mémoire et le temps d'exécution. Cloudflare a non seulement libéré 100 téraoctets de mémoire, mais a également rendu son résolveur DNS manifestement plus rapide. Pour une plongée approfondie dans les détails techniques, lisez le compte-rendu de Cloudflare : Comment nous avons économisé 100 téraoctets de mémoire en optimisant le cache DNS de 1.1.1.1.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
L'effet d'entraînement de l'efficacité
Cloudflare ne laissera pas ces 100 To de mémoire libérée inutilisés. Au lieu de cela, l'entreprise réinvestit directement cette capacité substantielle dans son réseau mondial, en élargissant spécifiquement le cache DNS pour des services comme 1.1.1.1. Cette allocation stratégique maximise l'impact de la récupération de mémoire, transformant un triomphe technique en une mise à niveau opérationnelle immédiate.
Un cache DNS plus grand se traduit directement par des avantages tangibles pour des millions d'utilisateurs dans le monde. L'augmentation des taux de réussite du cache signifie des réponses DNS plus rapides, car les serveurs de Cloudflare peuvent résoudre davantage de requêtes à partir de la mémoire locale plutôt que d'initier des recherches en amont. Cela améliore directement la réactivité et la résilience de l'expérience Internet.
La réussite de Cloudflare offre une leçon cruciale pour l'industrie : l'optimisation approfondie des systèmes reste un puissant levier d'efficacité. Alors que la demande des charges de travail IA fait grimper les coûts de la mémoire des serveurs, optimiser l'infrastructure existante pour récupérer 100 téraoctets de mémoire sans changement matériel n'est pas seulement une prouesse d'ingénierie ; c'est un impératif stratégique. Ce travail méticuleux au niveau de Rust souligne la valeur durable de la précision dans la programmation système.
Foire aux questions
Combien de mémoire Cloudflare a-t-il réellement économisé ?
Cloudflare a économisé environ 100 téraoctets (To) de RAM sur l'ensemble de son parc de serveurs mondial en optimisant son cache DNS 1.1.1.1, ce qui équivaut à la mémoire de 130 de ses serveurs.
Quel langage de programmation a été utilisé pour l'optimisation ?
Les optimisations ont été implémentées en Rust, qui a été choisi pour son efficacité mémoire, ses performances et son contrôle de bas niveau sur les structures de données.
L'économie de mémoire a-t-elle ralenti le résolveur DNS ?
Non, contre toute attente, les optimisations ont également amélioré les performances. Le débit d'insertion dans le cache a augmenté de 43 % et la latence de recherche a chuté de 19 %.
Comment la mémoire a-t-elle été économisée ?
Les économies proviennent de cinq changements principaux dans la manière dont les données DNS étaient stockées, notamment l'élimination de la capacité mémoire inutilisée dans les vecteurs, la fusion des listes de données et le stockage des enregistrements de manière plus efficace sous forme d'octets bruts.
Que fera Cloudflare avec les 100 To de mémoire économisés ?
La mémoire libérée sera réinvestie pour augmenter la taille du cache DNS. Cela devrait améliorer les taux de réussite du cache, réduisant les requêtes en amont et rendant le service 1.1.1.1 encore plus rapide pour les utilisateurs.