Contexte et objectifs
Le réseau d'edge de Cloudflare exploite plusieurs dizaines de milliers de serveurs, chacun disposant de plusieurs centaines de gigaoctets de mémoire vive. La pression sur la RAM provient principalement de la mise en cache de métadonnées et de la gestion de flux HTTP/2 et HTTP/3. Afin de limiter les coûts d'infrastructure et d'améliorer la densité de charge, l'équipe d'optimisation a cherché à réduire la consommation globale de mémoire sans sacrifier les performances.
Approche mathématique et implémentation Rust
Les ingénieurs ont d'abord analysé les structures de données utilisées dans le moteur de mise en cache. En appliquant des techniques de compactage d'entiers (varint) et de bit‑packing, ils ont pu représenter les mêmes informations avec jusqu'à 70 % d'espace en moins. Ces transformations reposent sur des modèles mathématiques de distribution des valeurs, permettant de choisir la largeur de champ optimale pour chaque champ de donnée.
Pour garantir la sécurité mémoire et la performance, le code critique a été réécrit en Rust. Le langage offre un contrôle précis de l'allocation grâce à son système de possession et à son borrow checker, éliminant les fuites et les dépassements de tampon qui pouvaient apparaître dans les implémentations C++ antérieures. L'utilisation d'un arena allocator spécialisé a également réduit le nombre d'appels au système d'allocation, limitant la fragmentation.
Résultats mesurés et impact
Les mesures internes montrent une économie cumulative de 100 TB de RAM sur l'ensemble du réseau. Cette réduction correspond à la capacité de 400 serveurs équipés de 256 GB de RAM, soit une part non négligeable du pool de mémoire disponible. Le gain a été observé sans impact négatif sur la latence des requêtes : les temps de réponse moyens sont restés stables, voire légèrement améliorés grâce à une meilleure localisation des données en cache.
En termes de coût, la diminution de la consommation de RAM se traduit par une réduction de la facture d'énergie et de refroidissement, ainsi que par la possibilité d'augmenter la densité de charge sur chaque nœud sans ajouter de matériel supplémentaire.
Limites et perspectives
La méthode repose sur des hypothèses de distribution des valeurs qui, si elles changent, peuvent réduire l'efficacité du compactage. De plus, la réécriture en Rust a nécessité une phase de validation extensive pour s'assurer que les comportements existants restent inchangés. Les équipes envisagent d'étendre ces techniques à d'autres composants du stack, notamment le moteur de routage DNS, où des gains similaires pourraient être obtenus.
