Cloudflare está probando una forma de aumentar la capacidad efectiva de su red de caché sin añadir hardware nuevo, mediante la compresión de algunos activos de texto con el algoritmo Zstandard dentro de una infraestructura basada en Pingora. El prototipo, al que la empresa llamó Cache Transcoding, tiene como objetivo reducir el espacio que ocupan los datos en los discos y el volumen de datos transferidos entre las capas de caché y los centros de datos.
Cuando una respuesta elegible entra en la caché, sus datos se convierten a una representación comprimida mediante zstd antes de escribirse en el disco. Los activos permanecen en este formato mientras están en la caché y durante su transferencia a través de Tiered Cache, y luego se descomprimen antes de enviarse al cliente. De este modo, el contenido del archivo no cambia; Zstandard es un algoritmo de compresión sin pérdidas que, tras la descompresión, devuelve cada byte a su estado original.
Un gran resultado frente a un coste de procesamiento limitado
En las pruebas iniciales, el tamaño de los activos elegibles en el disco se redujo, en promedio, a aproximadamente un tercio de su tamaño original. La proporción de compresión en el conjunto de pruebas controlado fue de 2.834 veces. El coste de codificación fue de 4.31 nanosegundos por byte, o aproximadamente 232 megabytes por segundo, y se paga una sola vez al llenar la caché. En cambio, el coste de descompresión fue de 1.56 nanosegundos por byte, o aproximadamente 641 megabytes por segundo, y se paga en cada operación de entrega.
La prueba utiliza el nivel tres de Zstandard, al considerarlo un punto de equilibrio entre la velocidad de ejecución y el tamaño del resultado. Según el modelo de Cloudflare, el aumento del consumo de CPU se mantuvo en unos pocos puntos porcentuales bajo los supuestos de tráfico y reutilización que probó la empresa. Además, reducir el tamaño de los datos permite que cada servidor conserve un mayor número de elementos y disminuye la probabilidad de expulsar contenido útil de la caché porque ocupa más espacio del necesario.
¿Por qué Cloudflare no comprime todo?
El mecanismo no está dirigido a todos los tipos de contenido. Las imágenes, los vídeos y las fuentes suelen estar comprimidos, y en la muestra de tráfico representaron el 21.4% de las solicitudes, pero el 63.3% del total de bytes. Volver a comprimir estos datos podría consumir CPU sin proporcionar un ahorro significativo.
En cambio, HTML, JSON, CSS y JavaScript representaron aproximadamente el 67.3% de las solicitudes y el 22.3% de los bytes. Cerca del 71% de estas respuestas de texto llegaba desde el origen sin Content-Encoding, lo que las convertía en candidatas para la compresión. El prototipo se limita a respuestas 200 OK que no especifican Content-Encoding, tienen un tipo de contenido textual comprimible y una longitud conocida de al menos 4 KiB.
Las solicitudes de fragmentos parciales, las respuestas comprimidas previamente por el origen, las solicitudes de rango, los cuerpos con longitud desconocida y el contenido binario se dejan sin cambios. Cloudflare descubrió que el límite de 4 KiB excluye un gran número de solicitudes pequeñas, pero elimina solo aproximadamente el 1% de los bytes que, de otro modo, serían elegibles.
¿Cómo funciona el mecanismo a través de las capas de almacenamiento?
Cuando se produce un fallo completo de caché, el nivel superior obtiene los datos sin comprimir del origen, los comprime una sola vez y los almacena en formato zstd. Este formato comprimido pasa al nivel inferior, que lo conserva y solo lo descomprime en la ruta de la solicitud dirigida al cliente. Si el elemento está presente únicamente en el nivel superior, puede trasladarse al nivel inferior sin volver al origen.
Cuando el elemento está presente en el nivel inferior, no se necesita ninguna transferencia de red ni una nueva codificación; los datos zstd se leen del disco, se descomprimen y se pasan a la ruta de respuesta. El sistema registra en sus metadatos que el elemento está almacenado en formato comprimido para impedir que vuelva a comprimirse al trasladarse entre las capas de almacenamiento.
Lectura de certi.news: ¿qué demuestra realmente la prueba?
La prueba muestra que reducir el tamaño de los datos dentro de la propia capa de almacenamiento puede tener un efecto acumulativo mayor que optimizar únicamente el proceso de llenado de la caché. El coste de compresión se paga cuando entra el elemento, mientras que los ahorros de almacenamiento y ancho de banda se repiten cada vez que se reutiliza. Esto resulta especialmente relevante para los operadores de redes de distribución a gran escala, donde la capacidad local está vinculada al volumen de contenido que puede conservarse y la transferencia de datos entre capas está vinculada al consumo de la red interna.
Sin embargo, los resultados no significan que la proporción de 2.8 veces represente todo el contenido de Internet ni toda la infraestructura de Cloudflare. La prueba de rendimiento se basó en más de un millón de solicitudes a través de diez servidores de caché, pero utilizó un origen experimental compuesto por dos elementos de aproximadamente 195 y 272 KiB, que eran claramente comprimibles. La empresa reconoce que se necesita un conjunto más amplio de tipos y tamaños de contenido antes de considerar que la proporción representa a todo el parque.
Cloudflare planea probar niveles superiores de zstd, ampliar el alcance de los contenidos y tamaños, ajustar las condiciones de elegibilidad y estudiar las solicitudes de rango y las respuestas comprimidas previamente. Por ello, Cache Transcoding sigue siendo, en el material actual, un prototipo exitoso bajo condiciones específicas, no un anuncio de despliegue definitivo para todo el tráfico de Cloudflare.