O problema de 100 Terabytes escondido à vista de todos
A infraestrutura global de DNS da Cloudflare, impulsionada pela plataforma apropriadamente chamada Big Pineapple, opera em uma escala impressionante. Ela gerencia constantemente mais de 250 bilhões de entradas de cache DNS, sustentando serviços críticos como 1.1.1.1, Gateway DNS e DNS Firewall para inúmeros usuários em todo o mundo.
Apesar dessa imensa pegada operacional, os engenheiros da Cloudflare descobriram uma ineficiência oculta e generalizada. Uma entrada de cache DNS típica, com 953 bytes, continha uma proporção significativa de memory overhead dedicada não aos dados DNS em si, mas ao gerenciamento interno da estrutura de dados. Os tipos padrão Vec e String do Rust, por exemplo, armazenam um ponteiro, um comprimento e um campo de capacidade.
Para registros DNS estáticos em cache, que não crescem, esse campo de capacidade tornou-se um fardo desnecessário, consumindo memória preciosa. Essa ineficiência aparentemente pequena se multiplicou drasticamente em toda a vasta rede. Mesmo um único byte desperdiçado por entrada em 250 bilhões de registros se traduz em mais de 250 gigabytes de RAM supérflua.
Esse extenso desperdício de memória equivalia ao custo operacional de servidores inteiros, destacando como detalhes pequenos e negligenciados no design de estruturas de dados podem se transformar em enormes despesas de infraestrutura. A revelação da Cloudflare ressaltou a importância crítica do gerenciamento de memória refinado, mesmo em linguagens de alto nível como Rust.
Eliminando a capacidade: a faca de dois gumes do Rust
As estruturas de dados do Rust frequentemente priorizam a flexibilidade. Tipos padrão como Vec e String gerenciam dados dinâmicos de forma eficiente, alocando mais memória do que o necessário imediatamente, reservando capacity extra para crescimento futuro. Cada instância armazena implicitamente três informações: um ponteiro para seus dados, seu comprimento atual e essa capacidade pré-alocada.
Essa estratégia é altamente eficaz para dados mutáveis, mas representa puro desperdício para registros imutáveis. As 250 bilhões de entradas de cache DNS da Cloudflare são fixas uma vez armazenadas; elas nunca se expandem ou contraem. O campo de capacidade adicional, portanto, não servia a nenhum propósito funcional dentro do "Big Pineapple", mas consumia recursos valiosos do sistema.
Reconhecendo essa ineficiência, os engenheiros substituíram Vec e String por boxed slices (Box<[T]>) e boxed strings (Box<str>). Esses tipos especializados do Rust alocam apenas a memória exata necessária para os dados, eliminando completamente o campo de capacidade. Essa mudança aparentemente pequena economizou 64 bytes por entrada de cache individual.
Em toda a vasta frota global da Cloudflare, essa otimização recuperou instantaneamente mais de 15 TB de RAM. Isso demonstra como um conhecimento profundo da semântica das estruturas de dados, combinado com os requisitos específicos da aplicação, pode desbloquear imensos ganhos de eficiência, transformando memória ociosa em recursos ativos e utilizáveis.
Além das Boxes: A arte do empacotamento de dados
A Cloudflare foi além dos ponteiros individuais para seções de DNS como answer, authority e additional, adotando uma estratégia de dados tightly packed. Eles consolidaram essas seções em um único bloco de memória contíguo e, em seguida, usaram pequenos offsets de dois bytes para navegar precisamente para cada parte. Isso eliminou o overhead de ponteiro, contribuindo significativamente para a redução de 56% no tamanho da entrada de cache, caindo de 953 bytes para meros 420 bytes por entrada.
Otimizações adicionais visaram a redundância e ineficiências estruturais dentro do cache. A Cloudflare parou de armazenar o nome do proprietário se ele duplicasse a consulta, reconstruindo-o a partir da chave de cache apenas quando necessário. Abordando o dimensionamento de enum em Rust, que assume como padrão a maior variante, eles implementaram boxing para tipos de registro grandes e raros, como NAPTR. Isso garantiu que registros menores e mais comuns, como A e AAAA, pudessem ocupar significativamente menos memória.
A mudança principal final envolveu armazenar dados de registro como wire-format bytes brutos, prefixados por comprimento, em vez de structs Rust totalmente analisadas. Isso contorna a sobrecarga de memória do rico sistema de tipos do Rust para dados que não exigem análise constante, reduzindo ainda mais a pegada de memória em todas as 250 bilhões de entradas de cache do Big Pineapple. Para um mergulho mais profundo nessas engenhosas técnicas de economia de memória, os leitores podem consultar How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache | Cloudflare Blog.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
O Resultado: Mais rápido e menor
A reengenharia meticulosa de dados culminou em um resultado impressionante: a Cloudflare reduziu o tamanho típico de sua entrada de cache DNS de 953 bytes para apenas 420 bytes. Isso representa uma redução substancial de 56% na pegada de memória por entrada. Em toda a frota global da Cloudflare, que gerencia mais de 250 bilhões de entradas de cache, essa otimização recuperou impressionantes 100 terabytes de memória total sem adicionar um único servidor novo.
Crucialmente, essas economias de memória não vieram a um custo de desempenho; em vez disso, as operações aceleraram significativamente. As inserções no cache tornaram-se 43% mais rápidas, saltando de 625.000 para impressionantes 893.000 entradas por segundo. Da mesma forma, as consultas tiveram uma melhoria de velocidade de 19%, com a latência caindo de 828 nanossegundos para rápidos 670 nanossegundos. Esse raro cenário ganha-ganha proporcionou eficiência de recursos significativa e maior velocidade operacional, desafiando as compensações convencionais.
A Cloudflare implantará estrategicamente os 100 terabytes de memória liberados para expandir sua capacidade de cache DNS. Um cache maior e mais robusto permite que a plataforma "Big Pineapple" resolva uma proporção ainda maior de consultas localmente. Isso reduz diretamente a necessidade de buscar dados de servidores upstream, traduzindo-se em uma resolução de DNS mais rápida para usuários em todo o mundo e melhorando visivelmente a velocidade da internet geral para todos.
Perguntas Frequentes
Quanta memória a Cloudflare economizou com essa otimização?
A Cloudflare recuperou aproximadamente 100 terabytes (TB) de RAM em toda a sua frota global, equivalente à memória de cerca de 130 servidores, sem adicionar novo hardware.
A otimização para memória tornou o DNS da Cloudflare mais lento?
Não, as otimizações tiveram o efeito oposto. As inserções no cache tornaram-se 43% mais rápidas e as consultas tornaram-se 19% mais rápidas, refutando a compensação comum entre uso de memória e velocidade.
Qual linguagem de programação a Cloudflare usou para alcançar isso?
A Cloudflare usou a linguagem de programação Rust, aproveitando seus recursos para controle de memória refinado para reescrever como as entradas de cache DNS são estruturadas.
Qual foi a principal mudança que a Cloudflare fez para economizar memória?
Uma mudança fundamental foi substituir tipos de dados padrão do Rust, como Vec e String, por Box<[T]> e Box<str>. Isso eliminou um campo de 'capacidade' desnecessário para dados em cache que nunca mudam de tamanho, economizando 64 bytes por entrada.
Como a Cloudflare reduziu o tamanho da entrada de cache DNS em 56%?
Eles implementaram cinco mudanças principais no nível do Rust: eliminação de campos de capacidade, empacotamento de seções de dados em um único bloco com deslocamentos, remoção de informações redundantes, boxing de variantes de enum grandes e armazenamento de dados em seu formato wire bruto.