O problema de 100 Terabytes
A Cloudflare executou recentemente um incrível roubo de memória, liberando 100 terabytes de capacidade operacional em sua rede global. Essa otimização notável é equivalente a adicionar toda a capacidade de RAM de 130 servidores Gen 13 modernos à sua infraestrutura, tudo sem implantar uma única peça de hardware novo. Uma recuperação tão massiva ressalta o impacto profundo da eficiência de software de baixo nível.
Alimentando serviços críticos como 1.1.1.1, Gateway DNS e DNS Firewall, a plataforma Big Pineapple da Cloudflare gerencia uma escala enorme. A qualquer momento, este sistema armazena mais de 250 bilhões de entradas de cache DNS, cada uma representando uma peça crucial de informação de roteamento da internet, facilitando bilhões de solicitações globais diariamente. Essa escala imensa transforma até mesmo pequenas ineficiências em desafios operacionais e de custos significativos.
O desafio central para a Cloudflare residia no efeito cumulativo de sobrecargas aparentemente minúsculas. Com 250 bilhões de entradas DNS, um único byte desperdiçado por entrada se multiplica em centenas de gigabytes de memória supérflua em toda a global fleet. Essa ineficiência microscópica, escalada em um sistema tão vasto, não apenas consome recursos valiosos; ela também pode impactar o desempenho e aumentar os custos operacionais, exigindo uma reavaliação fundamental das estruturas de dados.
Cinco cortes, uma recompensa massiva
A Cloudflare executou cinco otimizações precisas em nível de Rust, cada uma um ataque cirúrgico contra o inchaço da memória, culminando em uma recompensa massiva de 100 TB. Primeiramente, os engenheiros substituíram Vec<T> e String por Box<[T]> e Box<str> para entradas de cache imutáveis. Isso eliminou a capacidade pré-alocada e a sobrecarga desnecessária de heap, liberando imediatamente 64 bytes por entrada e mais de 15 TB em toda a frota.
Uma segunda mudança crítica envolveu o armazenamento de registros DNS como raw wire-format bytes, em vez de structs Rust totalmente analisadas. Isso simplificou o processamento, já que o sistema agora evita parsing e serialização redundantes. Também melhorou significativamente a cache locality, compactando mais dados relevantes em menos linhas de cache.
Outra engenhosidade de layout evitou o desperdício de memória. A Cloudflare colocou em 'box' grandes enum variants, como NAPTR dentro do enum RecordData, para impedir que tipos de registro menores e mais comuns (como A e AAAA) reservassem preenchimento excessivo. Isso garantiu que a alocação de memória correspondesse mais precisamente ao tamanho real dos dados.
Os engenheiros também mesclaram três listas de registros de resposta DNS separadas (resposta, autoridade, adicional) em uma única lista unificada. Dois offsets compactos de 2 bytes u16 agora delimitam as seções, substituindo pares maiores de ponteiro/comprimento e economizando 28 bytes por entrada. Essa consolidação tornou a estrutura de dados significativamente mais compacta.
Finalmente, o armazenamento condicional do proprietário representou o quinto corte. A Cloudflare agora armazena o nome do proprietário apenas quando ele difere do domínio consultado, inferindo-o da chave de cache caso contrário. Combinadas, essas otimizações granulares reduziram a pegada por entrada em 56%, de 953 bytes para 420 bytes, transformando o cenário de memória da Cloudflare.
Mais rápido ao ficar menor
Reduzir estruturas de dados geralmente implica um compromisso de desempenho, mas as otimizações da Cloudflare entregaram uma rara vitória dupla. O throughput de inserção no cache aumentou impressionantes 43%, subindo de 625.000 para 893.000 entradas por segundo. Simultaneamente, a latência de consulta caiu significativamente, melhorando em 19%, de 828 ns para 670 ns.
Essa aceleração não é mágica; é uma consequência direta da densidade de memória. Ao reduzir a pegada de memória por entrada de cache DNS em 56% (de 953 bytes para 420 bytes), as estruturas de dados da Cloudflare tornaram-se mais compactas. Dados menores ocupam menos espaço, permitindo que mais entradas de cache caibam nos caches L1, L2 e L3 mais rápidos da CPU, melhorando a CPU cache locality.
Pense nisso como organizar uma despensa: uma embalagem menor significa que você pode colocar mais itens usados com frequência nas prateleiras frontais de fácil acesso. Os processadores gastam menos tempo buscando dados da memória principal (RAM) mais lenta e mais tempo processando-os diretamente desses caches de alta velocidade, reduzindo drasticamente os estados de espera.
Uma melhoria tão profunda tanto no consumo de recursos quanto na velocidade operacional é uma raridade na engenharia, desafiando os compromissos típicos entre uso de memória e tempo de execução. A Cloudflare não apenas liberou 100 terabytes de memória, mas também tornou seu resolvedor DNS comprovadamente mais rápido. Para uma análise detalhada das especificações técnicas, leia o relato da própria Cloudflare: How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache.
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 Efeito Cascata da Eficiência
A Cloudflare não deixará esses 100TB de memória liberados ociosos. Em vez disso, ela reinveste diretamente essa capacidade substancial em sua rede global, expandindo especificamente o cache DNS para serviços como o 1.1.1.1. Essa alocação estratégica maximiza o impacto da recuperação de memória, transformando um triunfo técnico em uma atualização operacional imediata.
Um cache DNS maior traduz-se diretamente em benefícios tangíveis para milhões de usuários em todo o mundo. Taxas de acerto de cache mais altas significam respostas DNS mais rápidas, já que os servidores da Cloudflare podem resolver mais consultas a partir da memória local em vez de iniciar pesquisas upstream. Isso aumenta diretamente a capacidade de resposta e a resiliência da experiência na internet.
A conquista da Cloudflare oferece uma lição crucial para o setor: a otimização profunda de sistemas continua sendo uma alavanca poderosa para a eficiência. À medida que a demanda por AI workloads eleva os custos de memória dos servidores, otimizar a infraestrutura existente para recuperar 100 terabytes de memória sem alterações de hardware não é apenas um feito de engenharia; é um imperativo estratégico. Este trabalho meticuloso em nível de Rust ressalta o valor duradouro da precisão na programação de sistemas.
Perguntas Frequentes
Quanta memória a Cloudflare realmente economizou?
A Cloudflare economizou aproximadamente 100 terabytes (TB) de RAM em toda a sua frota global de servidores ao otimizar seu cache DNS 1.1.1.1, o equivalente à memória de 130 de seus servidores.
Qual linguagem de programação foi usada para a otimização?
As otimizações foram implementadas em Rust, que foi escolhida por sua eficiência de memória, desempenho e controle de baixo nível sobre estruturas de dados.
Economizar memória tornou o resolvedor DNS mais lento?
Não, de forma contraintuitiva, as otimizações também melhoraram o desempenho. O throughput de inserção no cache aumentou 43% e a latência de busca caiu 19%.
Como a memória foi economizada?
A economia veio de cinco mudanças principais na forma como os dados DNS eram armazenados, incluindo a eliminação de capacidade de memória não utilizada em vetores, a fusão de listas de dados e o armazenamento de registros de forma mais eficiente como bytes brutos.
O que a Cloudflare fará com os 100TB de memória economizados?
A memória liberada será reinvestida para aumentar o tamanho do cache DNS. Espera-se que isso melhore as taxas de acerto de cache, reduzindo as consultas upstream e tornando o serviço 1.1.1.1 ainda mais rápido para os usuários.