Cloudflare reduz 100 TB de RAM no Pingora Backend Router com hashing consistente em Rust

A Cloudflare recuperou mais de 100 TB de RAM globalmente ao corrigir o consumo excessivo do Pingora Backend Router (PBR), o serviço interno de balanceamento de carga baseado em Pingora. A origem foi um ticket aberto por Ivan sobre “Excessive memory usage from pingora-ketama in Pingora Backend Router”, conforme a nota publicada no Cloudflare Blog. O ganho não veio de hardware novo, mas de pequenas mudanças no algoritmo de hashing consistente.

O diagnóstico de excesso de memória no Pingora Backend Router

A Cloudflare descreve uma infraestrutura com milhares de servidores espalhados pelo mundo, petabytes de RAM e milhões de núcleos de CPU, tudo operando perto da capacidade máxima. Nesse cenário, melhorias de 1% são amplificadas e justificam esforço. O ticket do Ivan apontou que o PBR usava significativamente mais memória do que o esperado, especialmente nas estruturas associadas ao pingora-ketama, a biblioteca de código aberto da Cloudflare para hashing consistente.

O PBR é um serviço interno que roteia requisições cacheáveis por URL usando hashing consistente. A memória excedente estava nessas estruturas, o que motivou a equipe de Performance a investigar o algoritmo e buscar a redução. O relato detalha o raciocínio por trás do ajuste, com foco em matemática e implementação em Rust.

Consistent hashing como intervalo em uma reta numérica

Hashing consistente é usado para distribuir tarefas entre vários servidores sem exigir grandes mudanças quando nós são adicionados ou removidos. No caso da Cloudflare, ele roteia requisições cacheáveis por URL, permitindo manter apenas uma cópia de cada arquivo por data center e ainda oferecer um caminho estável para localizar cada objeto.

O conceito central é que, embora uma função de hash aceite qualquer tipo de entrada, sua saída é limitada a um único inteiro sem sinal — de 32, 64 ou 128 bits, dependendo da implementação. Isso permite relacionar tarefas e servidores de forma consistente. Em vez da metáfora circular mais comum, a Cloudflare representa a saída de 32 bits como uma reta numérica, para simplificar a atribuição.

Imagine servidores A, B e C e tarefas de t a z mapeadas por seus hashes. Atribuir uma tarefa consiste em encontrar o primeiro servidor à esquerda do hash da tarefa. A região coberta pelo servidor C pode “embrulhar” o final da reta e continuar no início, daí a ideia de anel. Essa simplicidade tem consequências práticas importantes.

O custo estatístico de um único hash por servidor

O problema de um único hash por servidor é o desbalanceamento: o intervalo coberto por um servidor é proporcional à fração de requisições que ele recebe, e os hashes se comportam como valores aleatórios. Um servidor pode ficar com um intervalo muito maior que os demais.

Para quantificar essa incerteza, a Cloudflare recorre a dois conceitos: valor esperado e desvio padrão. O valor esperado indica o centro da distribuição dos intervalos; o desvio padrão mostra quão próximos desse centro a maioria dos valores tende a estar. No exemplo com 100 servidores, o intervalo de cada servidor tende a se concentrar em torno de 0,99% do total, e a maioria dos comprimentos fica dentro de 1% do valor esperado. Isso é razoável, mas o número precisa ser interpretado relativamente. A medida relevante é o coeficiente de variação, que escala o desvio padrão pelo valor esperado para mostrar o erro como fração do tamanho alvo. O resultado é que a simplicidade do hashing consistente tem um preço estatístico.

Mais hashes por servidor e o parâmetro 160

A solução para reduzir esse desbalanceamento é adicionar vários hashes por servidor, em vez de um único ponto na reta. Segmentos individuais ainda têm desvio padrão alto, mas combinados tendem a se compensar. É o mesmo princípio da lei dos grandes números: a média de várias amostras tende a se estabilizar, desde que haja quantidade suficiente.

A Cloudflare observa que, no NGINX, o número base de hashes por servidor é fixado em 160, e o Pingora adota o mesmo valor como padrão. No exemplo de 100 servidores, o texto poupa a matemática, mas a lógica é clara: mais pontos por servidor reduzem a variação do tamanho dos intervalos. O outro lado é que cada hash adicional tende a consumir mais memória e tempo de consulta. Esse trade-off é o centro da otimização discutida.

Rust, pingora-ketama e a otimização que liberou 100 TB

A implementação que estava gastando memória faz parte do pingora-ketama, biblioteca aberta da Cloudflare para hashing consistente. A nota não publica um diff isolado do ganho, mas deixa claro que o trabalho combinou a análise matemática acima com mudanças no algoritmo em Rust — o próprio texto adianta que a discussão passa por Rust, além da matemática.

O resultado relatado é a recuperação de mais de 100 TB de RAM globalmente, somados aos 100 TB que a equipe de DNS havia eliminado no mês anterior. A postagem não descreve trocas de coleções ou flags específicas de compilação, então o ganho deve ser atribuído ao conjunto de melhorias algorítmicas. Para times que operam instâncias próprias de Pingora ou usam hashing consistente, o aprendizado imediato é revisar como os pontos de hash são armazenados e checar se o default 160 faz sentido para o tamanho do cluster, como detalhado na nota do Cloudflare Blog.

O que muda na prática para operação em larga escala

Para a Cloudflare, uma redução de memória em um serviço distribuído globalmente se traduz em capacidade liberada sem comprar hardware. O texto reforça que todos os recursos são finitos e que cada serviço precisa rodar em cada nó, então espaço desperdiçado não fica invisível.

A relevância para tech leads brasileiros é mais direta em ambientes com muitos nós e muitas arenas de cache. Se o balanceamento por hashing consistente estiver gerando intervalos desiguais, a correção pode ser mais barata do que escalar a infraestrutura. Mas o ganho de 100 TB é específico da escala da Cloudflare; em clusters pequenos, o mesmo tipo de ajuste tende a economizar megabytes, não petabytes.

Ressalvas e quando essa estratégia não é a prioridade

Nem todo serviço precisa de hashing consistente com dezenas ou centenas de pontos por servidor. Aumentar o número de hashes reduz a variância dos intervalos, mas também aumenta o custo de manutenção do anel e o tempo de lookup. O default de 160 pode ser excessivo para quem tem poucos servidores ou tráfego baixo, e insuficiente para cargas muito desbalanceadas.

Além disso, a análise estatística assume hashes suficientemente uniformes; se a função de hash ou a representação tiver viés, a distribuição continua ruim. O ganho da Cloudflare não elimina todo desbalanceamento — apenas reduz a memória gasta pelas estruturas do PBR e devolve capacidade ao sistema. A publicação foca no diagnóstico e na matemática, sem fornecer um patch pronto para reaproveitar em qualquer base de código.

Faz sentido investigar esse tipo de otimização quando o serviço roda em muitos nós, a memória é o gargalo e o roteamento por hash consistente é um componente central. Não faz quando o cluster é pequeno, o consumo está sob controle ou a complexidade operacional de ajustar o algoritmo supera a economia obtida. No caso da Cloudflare, a conta fechou em favor da mudança — e os 100 TB recuperados são a medida disso.