Cloudflare comprime cache com Zstandard e pode economizar petabytes

Os preços de memória - RAM e discos rígidos - subiram de forma acentuada no último ano. Operando produtos de armazenamento distribuído em larga escala, como sua CDN, a Cloudflare prototipou o Cache Transcoding, sistema construído durante um estágio no 1.1.1.1 Intern Program. Ele comprime conteúdos elegíveis com Zstandard dentro do Pingora, o proxy da empresa, e pode render petabytes de capacidade efetiva de cache ao custo de um pequeno aumento de CPU e de menos dados transferidos entre data centers. Nos testes iniciais, os conteúdos elegíveis encolheram, em média, para cerca de um terço do tamanho original em disco.

Por que Zstandard

Zstandard, ou zstd, é um algoritmo de compressão sem perdas criado por Yann Collet no Facebook e aberto em 2016: após decodificado, cada byte é idêntico ao original. Em testes anteriores da própria Cloudflare, foi 42% mais rápido que Brotli gerando arquivos de tamanho quase igual e 11,3% menores que gzip em velocidade comparável. O protótipo usa o nível 3 do zstd, que entrega a maior parte do ganho sem transformar o preenchimento do cache em gargalo de CPU.

Nem tudo vale a pena comprimir

Imagens, vídeos e fontes já chegam comprimidos: na amostra de tráfego, essa fatia representou 21,4% das requisições, mas 63,3% dos bytes - recomprimir seria gastar CPU à toa. O texto compressível (HTML, JSON, CSS e JavaScript) somou 67,3% das requisições e 22,3% dos bytes; cerca de 71% dessa fatia chegava sem compressão, com Content-Encoding ausente. No corpus controlado, os conteúdos elegíveis comprimiram cerca de 2,8 vezes. Codificar custa 4,31 ns por byte (aproximadamente 232 MB/s), pago uma vez por preenchimento; decodificar custa 1,56 ns por byte (cerca de 641 MB/s) a cada resposta. Como conteúdos são servidos muito mais vezes do que preenchidos, a economia se repete a cada reuso, e o custo extra de CPU ficou em alguns por cento sob as premissas de tráfego e reuso testadas.

Limitar a transcodificação ao conteúdo popular não ajudou: como a decodificação ocorre a cada serviço, restringir ao conteúdo mais quente reduziu a economia de armazenamento sem cortar CPU na mesma proporção. A política mais simples - transcodificar todo texto compressível elegível a partir de 4 kibibytes (KiB) - capturou quase todo o benefício medido dentro do orçamento de CPU.

Como funciona

Em cache miss, o proxy baseado em Pingora codifica o corpo com zstd antes de gravar em disco; os metadados registram a representação comprimida e preservam o tamanho original, restaurado antes de a resposta sair do proxy. Com Tiered Cache, a representação comprimida é transferida do tier superior ao inferior em forma comprimida e decodificada apenas no salto voltado ao cliente. Um marcador de codificação impede que o objeto seja comprimido mais de uma vez.

São elegíveis apenas respostas 200 OK com Content-Encoding ausente, Content-Type de texto compressível e Content-Length conhecido de pelo menos 4 KiB. Subrequests do Slice, respostas com compressão ativa upstream, range requests, respostas pré-comprimidas, corpos de tamanho desconhecido e conteúdo binário permanecem inalterados. O limite de 4 KiB deixou de fora apenas cerca de 1% dos bytes elegíveis; limiar e nível de compressão são parâmetros, não limites definitivos.

Testes e próximos passos

O protótipo foi exercitado em uma zona de teste controlada, com requisições correlacionadas em logs, métricas Prometheus e traces do Jaeger. Uma campanha de desempenho enviou mais de um milhão de requisições a 10 servidores de cache, metade da campanha com Tiered Cache desativado e a outra metade com ele ativado, para separar o comportamento local das transferências entre tiers. Os dois conteúdos testados, de cerca de 195 KiB e 272 KiB, comprimiram cerca de 2,8 vezes.

O corpus era deliberadamente compressível e não representa todo objeto de texto da Internet; a empresa avalia que um corpus mais amplo é necessário antes de tratar a razão medida como constante para toda a frota. Entre os próximos passos estão avaliar níveis mais altos de zstd, testar mais tipos de conteúdo e tamanhos, ajustar os critérios de elegibilidade e examinar range requests, respostas pré-comprimidas da origem e o repasse direto do objeto comprimido a componentes que já o suportem.