Cloudflare prueba a comprimir la caché con Zstandard para ganar petabytes
El prototipo Cache Transcoding comprime con Zstandard el texto sin comprimir que entra en caché antes de escribirlo a disco. La compañía calcula que le daría petabytes de capacidad efectiva adicional.
Cloudflare ha descrito un prototipo llamado Cache Transcoding que comprime con Zstandard el contenido apto que va a caché —sobre todo texto sin comprimir: HTML, JSON, CSS y JavaScript— antes de guardarlo en disco. La compañía estima que el enfoque podría darle petabytes de capacidad de caché efectiva adicional, aunque reconoce que falta probarlo a fondo.
El coste de CPU se paga una sola vez, cuando el objeto entra en la caché, y la descompresión ocurre al servirlo. La compresión reduce el tamaño del contenido apto unas 2,8 veces, así que los servidores existentes guardan más datos y circula menos tráfico entre centros de datos. Para montarlo, Cloudflare se apoya en Zstandard, el algoritmo de compresión sin pérdida que salió de Facebook para uso en tiempo real, y en Pingora, su proxy escrito en Rust.
"Un pequeño aumento de CPU le da a Cloudflare petabytes de capacidad de caché efectiva y reduce los datos transferidos entre nuestros centros de datos", escribe Aashi Patel en la nota que acompaña al prototipo.
Qué entra y qué no
No todo se comprime. Solo pasan por el proceso las respuestas sin comprimir que contienen texto compresible, que se completan con éxito y que pesan al menos 4 KiB. Quedan fuera las range requests, el contenido binario o ya precomprimido y las respuestas de tamaño desconocido. El umbral de 4 KiB evita procesar objetos pequeños a cambio de sacrificar alrededor del 1% de los datos aptos, y tanto ese límite como el nivel de compresión de Zstandard se pueden ajustar según el equilibrio entre CPU y almacenamiento que quiera cada uno.
Los números de tráfico que maneja la compañía explican el filtro. En su muestra, imágenes, vídeo y fuentes representaron el 21,4% de las peticiones pero el 63,3% de los bytes: ya vienen comprimidos, y volver a comprimirlos quemaría CPU para nada, según Patel. El texto compresible (HTML, JSON, CSS, JavaScript) fue el 67,3% de las peticiones y el 22,3% de los bytes, y de ese contenido alrededor del 71% llegaba sin comprimir y por tanto se podía comprimir de verdad.
El nombre y los range requests
El experimento ha levantado dudas en Hacker News. Hay quien cuestiona que se llame transcoding a un esquema de codificar y descodificar, y quien discute las alternativas de compresión. El usuario MayeulC apunta que, si el objetivo era ahorrar CPU en la descodificación, él habría comprimido el contenido frío en lugar del popular. CodesInChaos pregunta por el efecto en las range requests: sin comprimir, basta con leer la parte correspondiente del fichero completo cacheado, pero no queda claro cómo se resuelven ahora.
Cloudflare ha probado el sistema con y sin Tiered Cache para medir el impacto de la compresión en el cacheo local y en las transferencias entre niveles. El prototipo sigue en desarrollo, con más pruebas previstas en distintos niveles de compresión, tipos de contenido, tamaños de objeto y escenarios de caché. Para quien opera una CDN o una capa de caché propia, el interés está en que los dos parámetros que gobiernan el invento —umbral de tamaño y nivel de compresión— son precisamente los que deciden cuánta CPU se cambia por cuánto disco.
