Cloudflare teste une méthode visant à augmenter la capacité effective de son réseau de cache sans ajouter de nouveau matériel, en compressant certaines ressources textuelles avec l’algorithme Zstandard au sein de l’infrastructure fondée sur Pingora. Le prototype, que l’entreprise a baptisé Cache Transcoding, vise à réduire l’espace occupé par les données sur les disques ainsi que le volume de données transférées entre les couches de cache et les centres de données.
Lorsqu’une réponse éligible entre dans le cache, ses données sont converties en une représentation compressée à l’aide de zstd avant d’être écrites sur le disque. Les ressources restent sous cette forme pendant leur présence dans le cache et lors de leur transfert via le Tiered Cache, puis sont décompressées avant d’être envoyées au client. Le contenu du fichier lui-même ne change donc pas : Zstandard est un algorithme de compression sans perte qui restitue chaque octet dans son état d’origine après décompression.
Un résultat important pour un coût de traitement limité
Lors des premiers essais, la taille des ressources éligibles sur le disque a été réduite en moyenne à environ un tiers de leur taille d’origine. Le taux de compression du groupe de test contrôlé a atteint 2,834 fois. Le coût de l’encodage s’élevait à 4,31 nanosecondes par octet, soit environ 232 mégaoctets par seconde, et n’était payé qu’une seule fois lors du remplissage du cache. En revanche, le coût de la décompression atteignait 1,56 nanoseconde par octet, soit environ 641 mégaoctets par seconde, et était payé à chaque opération de diffusion.
L’expérience utilise le niveau 3 de Zstandard, considéré comme un compromis entre la vitesse d’exécution et la taille du résultat. Selon le modèle de Cloudflare, l’augmentation de la consommation du processeur est restée de l’ordre de quelques pour cent dans les hypothèses de trafic et de réutilisation testées par l’entreprise. La réduction du volume des données permet également à chaque serveur de conserver davantage d’éléments et diminue le risque d’expulser du contenu utile du cache parce qu’il occupe plus d’espace que nécessaire.
Pourquoi Cloudflare ne compresse-t-elle pas tout ?
Le mécanisme ne cible pas tous les types de contenu. Les images, les vidéos et les polices sont généralement déjà compressées ; elles représentaient 21,4 % des requêtes dans l’échantillon de trafic, mais 63,3 % du total des octets. Recompresser ces données pourrait solliciter le processeur sans apporter d’économie significative.
En revanche, HTML, JSON, CSS et JavaScript représentaient environ 67,3 % des requêtes et 22,3 % des octets. Environ 71 % de ces réponses textuelles arrivaient de l’origine sans Content-Encoding, ce qui en faisait des candidates à la compression. Le prototype se limite aux réponses 200 OK qui ne définissent pas Content-Encoding, possèdent un type de contenu textuel compressible et ont une longueur connue d’au moins 4 KiB.
Les requêtes de plages partielles, les réponses déjà compressées par l’origine, les requêtes de plage, les corps de longueur inconnue et le contenu binaire sont laissés inchangés. Cloudflare a constaté que la limite de 4 KiB excluait un grand nombre de petites requêtes, mais ne supprimait qu’environ 1 % des octets qui auraient autrement été éligibles.
Comment le mécanisme fonctionne-t-il entre les couches de stockage ?
Lorsqu’un échec complet du cache survient, le niveau supérieur récupère les données non compressées depuis l’origine, puis les compresse une seule fois et les stocke au format zstd. Ce format compressé est transmis au niveau inférieur, qui le conserve et ne le décompresse que sur le chemin de la requête destinée au client. Si l’élément n’est présent que dans le niveau supérieur, il peut être transféré au niveau inférieur sans retourner à l’origine.
Lorsque l’élément est présent dans le niveau inférieur, aucun transfert réseau ni nouvel encodage n’est nécessaire : les données zstd sont lues sur le disque, décompressées, puis transmises au chemin de réponse. Le système enregistre dans ses métadonnées que l’élément est stocké au format compressé, afin d’empêcher sa compression répétée lors de son déplacement entre les couches de stockage.
Lecture de certi.news : que prouve réellement l’expérience ?
L’expérience montre que la réduction du volume des données au sein même de la couche de stockage peut avoir un effet cumulatif plus important que la seule optimisation du remplissage du cache. Le coût de la compression est payé à l’entrée de l’élément, tandis que les économies de stockage et de bande passante se répètent chaque fois qu’il est réutilisé. Cela revêt une importance particulière pour les opérateurs de réseaux de distribution à grande échelle, où la capacité locale dépend du volume de contenu pouvant être conservé et où le transfert de données entre les couches est lié à la consommation du réseau interne.
Les résultats ne signifient toutefois pas que le facteur de 2,8 représente l’ensemble du contenu Internet ou toute l’infrastructure de Cloudflare. Le test de performance s’est appuyé sur plus d’un million de requêtes réparties entre dix serveurs de cache, mais il a utilisé un élément expérimental composé de deux ressources d’environ 195 et 272 KiB, qui étaient clairement compressibles. L’entreprise reconnaît qu’un éventail plus large de types et de tailles de contenu est nécessaire avant de considérer ce taux comme représentatif de l’ensemble du parc.
Cloudflare prévoit de tester des niveaux de zstd supérieurs, d’élargir la portée des contenus et des tailles, d’ajuster les conditions d’éligibilité et d’étudier les requêtes de plage ainsi que les réponses déjà compressées. Cache Transcoding reste donc, dans le présent article, un prototype réussi dans des conditions précises, et non une annonce de généralisation définitive à l’ensemble du trafic de Cloudflare.