Cloudflare recupera mais 100TB de RAM otimizando hashing consistente em Rust

struct PointV2 {
 hash: u32,
 index: u16,
}

As regras de alinhamento de memória do Rust exigem que o tamanho de um struct seja múltiplo do tamanho do seu maior campo. Como o hash de 32 bits é o maior campo, o compilador ainda reserva 8 bytes, mesmo com o índice menor. A saída não foi usar #[repr(packed)] (que a equipe evita por razões conhecidas de segurança e portabilidade), e sim guardar os bytes crus num array e acessá-los por getters:

struct Point([u8; 6]);

impl Point {
 fn hash(&self) -> u32 {
 u32::from_ne_bytes(self.0[0..4].try_into().unwrap())
 }
 fn index(&self) -> u16 {
 u16::from_ne_bytes(self.0[4..6].try_into().unwrap())
 }
}

A mudança, sozinha, reduziu em 25% a memória usada para hashing consistente. Mas o ganho maior ainda estava por vir, e dependia de matemática, não de código.

Por que 90% dos hashes eram desperdício

A fórmula de coeficiente de variação citada acima vale só para um hash por servidor. Para k hashes por servidor, a maioria das fontes só oferece aproximações. A equipe da Cloudflare derivou a fórmula exata (a derivação completa está num post complementar linkado no artigo original) e chegou a uma conclusão prática: cada redução de erro exige, aproximadamente, um aumento de uma ordem de grandeza no número de hashes. Com o peso médio de 625 usado internamente, o PBR estava gerando 160 × 625 = 100 mil hashes por servidor, e os últimos 90 mil desses hashes reduziam o erro em apenas 0,7%.

Pior: como os hashes de 32 bits têm um espaço finito, colisões passam a acontecer com mais frequência conforme o número de hashes cresce (o clássico paradoxo do aniversário). Simulações mostraram que, para data centers com 2048 servidores, o erro real chega a aumentar entre 10 mil e 100 mil hashes por servidor, justamente a faixa em que o PBR estava operando. Com os dados na mão, a equipe cortou o número de hashes gerados por servidor em 90%, sem perda perceptível de precisão no balanceamento.

Como migrar sem derrubar a origem

Trocar o anel de hashing muda para onde cada chave de cache aponta. Uma virada global de uma vez invalidaria quase todo o cache simultaneamente e jogaria uma avalanche de tráfego direto para os servidores de origem dos clientes. A solução foi manter as duas versões do anel (a antiga e a nova, compacta) em memória ao mesmo tempo durante a transição, com o framework de migração interno decidindo, por hash da requisição, qual anel usar. Isso deu duas vantagens: a decisão era estável por requisição e havia um caminho de rollback limpo, sem precisar reimplantar o PBR.

O rollout foi feito por camadas: primeiro locais de validação pequenos, depois grupos progressivamente maiores de data centers, controlando separadamente duas variáveis: quanto tráfego usava o novo anel e em quais data centers isso acontecia. Um rollout por porcentagem global teria espalhado o churn de cache por toda a rede de uma vez; o escopo por data center manteve o raio de impacto pequeno. A equipe monitorou traces de seleção de backend, contadores de versão de anel, erros de conexão do PBR, memória de processo, tempo de startup, comportamento de cache e tráfego de origem durante todo o processo. Ao chegar a 100%, o caminho antigo foi removido, resultando na queda de 100TB de memória usada globalmente, soma que se junta a outros 100TB que o time de DNS da Cloudflare já havia liberado no mês anterior.

O que muda para quem programa

As mudanças estão disponíveis agora na crate pingora-ketama, atrás de uma feature de cargo ainda não anunciada oficialmente: o anel v2 traz o formato de armazenamento compactado, um método de ordenação mais rápido e a possibilidade de escalar o número base de hashes por nó. Como a Pingora é open source, qualquer time que já use o framework para balanceamento de carga (ou que esteja avaliando construir um proxy próprio em Rust) pode testar o ganho direto no próprio projeto, sem esperar a Cloudflare anunciar nada em bombo.

Mas o ponto que vale além do código é o método: as regras de alinhamento de memória do Rust não são detalhe de compilador, são a diferença entre um struct de 6 bytes reais e um de 8 bytes desperdiçados, e isso importa em qualquer sistema que guarde milhões dessas estruturas em memória, seja um proxy de borda ou um jogo. E a estratégia de migração (duas versões coexistindo, decisão determinística por requisição, rollout com raio de impacto controlado por localidade) é um padrão reaproveitável para qualquer troca de algoritmo de roteamento ou particionamento em produção, dentro ou fora do contexto de CDN.

Fonte: Hacker News