Cloudflare transcode son cache en Zstandard et économise des pétaoctets de stockage

1er septembre 2026. Cloudflare publie un billet d’ingénierie sur un prototype nommé Cache Transcoding, qui encode les réponses éligibles en Zstandard directement dans Pingora. 2016. C’est l’année où Yann Collet ouvre le code de Zstandard chez Facebook. 67,3 %. C’est la part des requêtes portant sur du texte compressible dans l’échantillon de trafic étudié. Pourquoi c’est important : la mémoire et le disque coûtent de plus en plus cher, et comprimer le cache lui-même devient un levier d’économie à l’échelle d’un CDN mondial.

Le problème que Cache Transcoding attaque

Le postulat est posé d’entrée : les coûts mémoire augmentent fortement, et le prix de la RAM comme des disques durs a explosé au cours de l’année écoulée. Cloudflare exploite plusieurs produits de stockage massivement distribués, dont son CDN, qui reposent sur une utilisation efficace de la mémoire déployée pour continuer à servir tous les clients.

La réponse imaginée est de compresser les objets au moment où ils entrent dans le cache, pas seulement au moment où ils sortent vers le navigateur. Quand une réponse éligible est écrite sur disque, Cache Transcoding l’encode en Zstandard avant l’écriture. La forme compressée est conservée pendant toute la durée de vie de l’objet en cache et pendant son transfert entre datacenters via le Tiered Cache, puis décodée juste avant d’être servie au client.

Dans les premiers tests, cet encodage réduit les actifs éligibles à environ un tiers de leur taille sur disque. Le coût CPU supplémentaire estimé sur le proxy orienté origine reste faible. Un léger surcroît de calcul donne à Cloudflare des pétaoctets de capacité de cache effective et réduit les données transférées entre ses datacenters. L’encodage est payé une fois à l’entrée dans le cache, alors que les économies de stockage et de bande passante se répètent à chaque réutilisation de l’objet.

Pourquoi Zstandard plutôt que Brotli ou gzip

Zstandard, ou zstd, est un algorithme de compression sans perte développé par Yann Collet chez Facebook et ouvert en 2016. Sans perte signifie qu’une fois les données décompressées, chaque octet est identique à l’original. On peut changer la représentation d’un actif sur disque sans changer l’actif lui-même.

zstd est conçu pour équilibrer taux de compression et vitesse. Dans les tests de compression navigateur menés plus tôt par Cloudflare, il comprime les données 42 % plus vite que Brotli pour une taille de fichier quasi identique, et produit des fichiers 11,3 % plus petits que gzip à vitesse comparable. Cet équilibre est décisif : Cache Transcoding touche un volume de trafic énorme, donc l’encodage comme le décodage doivent rester rapides.

Le prototype utilise le niveau zstd 3, qui capte l’essentiel du gain de compression sans transformer les remplissages de cache en goulet CPU. Le billet chiffre les coûts : 4,31 ns par octet, soit environ 232 Mo/s, pour l’encodage payé une fois par remplissage, et 1,56 ns par octet, soit environ 641 Mo/s, pour le décodage payé à chaque service. L’encodage coûte plus cher à l’octet, mais un actif est servi bien plus souvent qu’il n’est rempli.

Ce qui est éligible et ce qui ne l’est pas

Transcoder ne veut pas dire tout compresser. Les images, vidéos et polices sont déjà compressées en général. Dans l’échantillon de trafic de Cloudflare, cette part de médias représente 21,4 % des requêtes mais 63,3 % des octets. Les recompresser brûlerait du CPU pour rien.

Le texte compressible est une autre histoire. Le HTML, le JSON, le CSS et le JavaScript représentent 67,3 % des requêtes et 22,3 % des octets. Dans cette tranche, environ 71 % arrivent non compressés, sans Content-Encoding, et se compressent bien. C’est là que Cache Transcoding porte ses fruits, avec un corpus de test contrôlé qui compresse les actifs éligibles d’environ 2,8 fois.

Le prototype n’encode une réponse 200 OK que lorsque le Content-Encoding est absent, que le Content-Type est du texte compressible et que la réponse a un Content-Length connu d’au moins 4 Kio. Les sous-requêtes slice, les réponses utilisant une compression amont active, les requêtes range, les réponses précompressées, les corps de longueur inconnue et le contenu binaire restent inchangés. Ce seuil de 4 Kio écarte un grand nombre de toutes petites requêtes tout en n’abandonnant qu’environ 1 % des octets autrement éligibles.

Le chemin d’un objet à travers les tiers

Le détail de l’architecture mérite d’être compris, car il détermine où le décodage a lieu :

• Sur un miss de cache, le proxy basé sur Pingora encode le corps en zstd avant de l’écrire sur disque. Les métadonnées du cache enregistrent que la représentation stockée est compressée et conservent la longueur de contenu d’origine. Avant de quitter le proxy, le corps est décodé vers sa représentation identité d’origine.
• Sur un hit de cache, l’objet zstd stocké est lu et décodé. Avec le Tiered Cache, la représentation compressée est transférée du tier supérieur vers le tier inférieur sous forme compressée. Le décodage n’a lieu que sur le saut orienté client.
• Sur un miss complet, le tier supérieur récupère les octets identité depuis l’origine, les encode une fois, les stocke en zstd et les transfère au tier inférieur sous forme compressée. Le tier inférieur stocke aussi la représentation zstd, puis la décode pour la requête.

Un marqueur d’encodage de stockage empêche qu’un objet soit encodé plus d’une fois. Un cache qui reçoit un objet d’un autre tier voit qu’il est déjà stocké en zstd et le conserve tel quel.

La politique retenue est aussi une leçon de sobriété : limiter la transcodification aux seuls contenus populaires n’aidait pas, car le décodage a lieu à chaque service. Transcoder tout le texte compressible éligible à partir de 4 Kio capte la quasi-totalité du gain mesuré tout en restant dans le budget CPU.

Comment le prototype a été validé

Le prototype a été exercé contre une zone de test contrôlée, chaque requête étant corrélée entre les journaux de requêtes, les métriques Prometheus et les traces Jaeger. La campagne de correction couvrait les miss et les hits de cache, les remplissages en un saut et les remplissages du Tiered Cache, en variant les clés de cache pour forcer chaque chemin.

Une campagne de performance a envoyé plus d’un million de requêtes à travers 10 serveurs de cache, la moitié avec le Tiered Cache désactivé et l’autre moitié activé, afin de mesurer le comportement local séparément des transferts entre tiers. Les deux actifs de test faisaient environ 195 Kio et 272 Kio et se compressaient tous deux d’environ 2,8 fois. C’était délibérément un corpus compressible, qui valide l’architecture sans représenter chaque objet texte d’Internet : un corpus plus large reste nécessaire avant de traiter ce ratio comme une constante de flotte.

Verdict

Si vous exploitez un cache ou un CDN maison, la leçon est directement transposable : encoder les actifs texte éligibles en zstd à l’entrée du cache, avec un seuil de taille et une liste blanche de types de contenu, transforme du CPU bon marché en capacité de stockage et en bande passante inter-datacenters. Commencez par mesurer la part de votre trafic qui arrive sans Content-Encoding.

Si vous êtes simplement client d’un CDN, vous n’avez rien à configurer : c’est le genre d’optimisation qui se joue à l’intérieur de l’infrastructure du fournisseur, et qui se traduit par une meilleure densité de cache et une éviction moins fréquente de vos contenus. Mais elle rappelle que la compression de niveau 3 sur du texte reste l’un des meilleurs rapports coût/bénéfice de l’ingénierie des caches.

Références

• How we could save petabytes of cache storage with Zstandard and Pingora — Cloudflare Blog, 1er septembre 2026