Cloudflare réduit son empreinte mémoire en compressant le cache avec Zstandard dans Pingora

Un arbitrage entre processeur et capacité de stockage

Face à la hausse marquée des prix de la mémoire RAM et des disques durs, les ingénieurs de Cloudflare ont cherché à optimiser l'efficacité de leurs serveurs CDN (réseaux de diffusion de contenu distants). L'expérimentation, nommée Cache Transcoding, introduit la compression des données directement au sein de Pingora (le proxy inverse développé en Rust qui gère le trafic de Cloudflare). Lorsqu'une réponse HTTP éligible entre dans le cache, elle est immédiatement encodée avec Zstandard (ou zstd, un algorithme de compression sans perte conçu par Facebook) avant d'être inscrite sur le disque.

L'intérêt technique repose sur l'asymétrie entre l'encodage et le décodage. L'opération d'encodage nécessite environ 4,31 ns par octet (soit 232 Mo/s), un coût payé une seule fois à l'entrée en cache. Le décodage, exécuté à chaque requête cliente, est plus rapide avec 1,56 ns par octet (environ 641 Mo/s). Cet arbitrage permet de concéder une légère augmentation d'usage processeur sur le proxy frontal pour débloquer plusieurs pétaoctets de capacité de stockage effective sur l'ensemble du réseau.

Sélection stricte des contenus compressibles

L'équipe d'ingénierie a fait le choix de ne pas tout compresser. Les fichiers médias (images, vidéos, polices), bien que représentant 63,3 % des octets du trafic observé, sont déjà compressés à la source. Cloudflare s'est donc concentré sur le contenu textuel (HTML, JSON, CSS, JavaScript), qui constitue 67,3 % des requêtes et 22,3 % des octets, avec environ 71 % de ce flux arrivant sans en-tête de compression Content-Encoding depuis les serveurs d'origine.

Pour préserver les ressources CPU, le prototype applique des règles d'éligibilité strictes :

• La réponse HTTP doit être un code 200 OK sans en-tête Content-Encoding déjà présent.
• Le type MIME (Content-Type, qui définit le format de la réponse) doit correspondre à du texte compressible.
• La taille de l'objet (Content-Length) doit atteindre au minimum 4 KiB (kibioctets).

Ce seuil de 4 KiB élimine un volume important de micro-requêtes tout en capturant l'essentiel des données utiles (seul 1 % des octets éligibles est écarté par cette limite). Le prototype utilise le niveau de compression zstd niveau 3, offrant un bon équilibre entre gain d'espace et rapidité.

Transferts optimisés entre centres de données

Lors d'un manque en cache (cache miss), la réponse est encodée en zstd par le proxy Pingora et sauvegardée avec la métadonnée de sa taille originale. Sur le réseau Tiered Cache (l'architecture de caches intermédiaires en couches reliant les centres de données de Cloudflare), l'objet circule et reste stocké sous sa forme compressée entre les différents échelons. Il n'est décodé qu'au moment d'être distribué au client final.

{
  "eligibility_criteria": {
    "status_code": 200,
    "content_encoding": null,
    "min_content_length_bytes": 4096,
    "algorithm": "zstd",
    "compression_level": 3
  }
}

Une campagne de tests menée sur 10 serveurs de cache et plus d'un million de requêtes a confirmé que les fichiers de test (de 195 KiB et 272 KiB) ont vu leur taille sur disque réduite d'un facteur 2,834 (soit environ un tiers de leur taille d'origine). Cette densité accrue limite les évictions prématurées d'objets du cache et réduit la bande passante consommée entre les centres de données de l'opérateur.