- O gigantesco Big Pineapple
- Rust ajudou, mas o segredo estava nas estruturas de dados
- Três listas viraram um único bloco de memória
- Por que guardar algo que pode ser reconstruído?
- Um IPv4 de quatro bytes ocupava espaço para 144 bytes
- Menos RAM e mais velocidade
- De 9,3 GB para 5,3 GB por instância
- O equivalente a 130 servidores
- Cloudflare não pretende deixar esses 100 TB vazios
- O melhor upgrade pode ser não comprar hardware
Cinco otimizações no código Rust reduziram o tamanho típico de cada entrada do cache DNS de 953 bytes para apenas 420 bytes, cortando o consumo de memória pela metade e ainda melhorando o desempenho.
A Cloudflare conseguiu um daqueles feitos de engenharia que parecem quase absurdos quando colocados em números: a empresa recuperou aproximadamente 100 terabytes de memória RAM espalhados por sua infraestrutura global sem instalar novos servidores, remover módulos de memória ou realizar qualquer atualização de hardware.
O ganho veio exclusivamente de software.
Engenheiros da companhia revisaram a forma como o sistema responsável pelo cache DNS do famoso 1.1.1.1 armazena informações na memória. Depois de cinco grandes otimizações no código escrito em Rust, o espaço necessário para armazenar uma entrada típica caiu de 953 bytes para 420 bytes.
Isso representa uma redução de aproximadamente 56% no tamanho líquido de cada entrada.
O gigantesco Big Pineapple
No centro da história está o Big Pineapple, plataforma de cache DNS desenvolvida pela Cloudflare e utilizada por serviços como 1.1.1.1, Gateway DNS, DNS Firewall e AS112.
O tamanho dessa infraestrutura ajuda a explicar por que pequenas otimizações produzem resultados tão gigantescos.
Segundo a própria Cloudflare, o Big Pineapple mantém mais de 250 bilhões de entradas DNS em cache simultaneamente. Nesse volume, desperdiçar apenas um único byte por entrada representa mais de 250 GB de memória consumidos pela frota de servidores.
Multiplique isso por dezenas ou centenas de bytes desnecessários e o problema rapidamente passa da escala dos gigabytes para dezenas de terabytes.
Em números:
- Mais de 250 bilhões de entradas DNS armazenadas simultaneamente;
- 953 bytes por entrada antes das otimizações;
- 420 bytes depois das mudanças;
- 56% menos memória por entrada;
- Aproximadamente 100 TB de RAM recuperados em toda a infraestrutura.
Rust ajudou, mas o segredo estava nas estruturas de dados
Uma das principais mudanças envolveu estruturas bastante comuns na linguagem Rust: Vec<T> e String.
Essas estruturas foram projetadas para permitir crescimento dinâmico. Para isso, além dos próprios dados, precisam armazenar informações como capacidade disponível para futuras expansões.
Isso faz sentido para uma coleção que continuará recebendo novos elementos.
Mas não para uma resposta DNS armazenada em cache.
Depois que uma resposta entra no cache do Big Pineapple, seu conteúdo não precisa mais crescer. Mesmo assim, milhares de milhões dessas estruturas continuavam carregando metadados destinados justamente a permitir expansão.
A solução foi substituir vários desses objetos por estruturas de tamanho fixo, como Box<[T]> e Box<str>.
Com isso, o sistema eliminou informações de capacidade que simplesmente não tinham utilidade depois que os dados entravam no cache.
Somente essa alteração economizou mais de 15 TB de RAM em toda a infraestrutura da Cloudflare.
Três listas viraram um único bloco de memória
Outra otimização atacou a própria organização das respostas DNS.
Anteriormente, o Big Pineapple mantinha separadamente três conjuntos de registros correspondentes às tradicionais seções de uma resposta DNS: respostas, autoridade e informações adicionais.
O novo modelo coloca esses registros dentro de um único buffer contínuo.
Pequenos offsets de dois bytes são então utilizados para indicar onde cada seção começa e termina.
Além de reduzir o número de estruturas e alocações necessárias, a abordagem melhora a chamada localidade de memória. Na prática, informações relacionadas tendem a permanecer próximas umas das outras na RAM, aumentando a possibilidade de o processador encontrá-las diretamente em seus caches internos.
Por que guardar algo que pode ser reconstruído?
Os engenheiros também identificaram informações redundantes dentro dos registros DNS.
Um exemplo envolve o nome do proprietário de determinado registro. Em muitos casos, esse nome é exatamente o mesmo domínio utilizado na consulta original.
Em vez de armazenar novamente essa informação em cada registro, o Big Pineapple agora simplesmente reconstrói o nome quando a resposta precisa ser enviada.
A estratégia troca uma quantidade minúscula de processamento por enormes economias de armazenamento quando multiplicada por centenas de bilhões de entradas.
Um IPv4 de quatro bytes ocupava espaço para 144 bytes
Outra fonte importante de desperdício estava na representação interna dos tipos de registros DNS.
Um endereço IPv4 armazenado em um registro A precisa de apenas quatro bytes. Um endereço IPv6 em um registro AAAA precisa de 16 bytes.
Esses dois tipos representam mais de 80% do tráfego DNS observado pela Cloudflare.
Mesmo assim, no modelo anterior alguns desses registros acabavam ocupando internamente o mesmo espaço reservado para estruturas DNS muito maiores.
Um simples endereço IPv4 de quatro bytes poderia acabar dentro de uma estrutura dimensionada para aproximadamente 144 bytes, tamanho necessário para acomodar tipos muito maiores e bem menos comuns, como registros NAPTR.
Em sistemas normais, desperdiçar algumas dezenas de bytes dificilmente seria motivo de preocupação.
Em um sistema com centenas de bilhões de objetos, é outra história.
A Cloudflare passou então a armazenar os dados dos registros em seu formato binário DNS original, utilizando campos de tamanho variável precedidos pelo comprimento dos dados.
Assim, um endereço IPv4 passa a ocupar algo muito mais próximo do espaço que realmente precisa.
Menos RAM e mais velocidade
A consequência mais interessante das otimizações é que economizar memória não tornou o sistema mais lento.
Aconteceu justamente o contrário.
Nos testes publicados pela Cloudflare, a capacidade de inserir entradas no cache aumentou de aproximadamente 625 mil para 893 mil entradas por segundo.
Isso representa uma melhoria de cerca de 43%.
Ao mesmo tempo, a latência das consultas caiu de aproximadamente 828 nanossegundos para 670 nanossegundos, uma redução de aproximadamente 19%.
| Métrica | Antes | Depois | Resultado |
|---|---|---|---|
| Memória líquida por entrada | 953 bytes | 420 bytes | -56% |
| Alocações por entrada | 1,1 KB | 461 bytes | -58% |
| Inserções no cache | 625.000/s | 893.000/s | +43% |
| Latência de consulta | 828 ns | 670 ns | -19% |
A explicação está novamente ligada à arquitetura de memória.
Menos alocações significam menos trabalho para o gerenciador de memória, enquanto estruturas menores aumentam a probabilidade de dados utilizados juntos permanecerem próximos dentro dos caches do processador.
De 9,3 GB para 5,3 GB por instância
As otimizações foram implantadas gradualmente entre 18 de maio e 6 de julho de 2026.
Durante o processo, a Cloudflare acompanhou o consumo real de memória dos servidores em produção.
No percentil 99, o consumo de memória das instâncias caiu de aproximadamente 9,3 GB para 5,3 GB.
No percentil 90, caiu de 6,5 GB para 3,8 GB.
Ao final do rollout e depois que os caches voltaram ao seu estado normal de operação, a redução total no conjunto da infraestrutura foi estimada em aproximadamente 100 TB de memória ativa.
O equivalente a 130 servidores
A Cloudflare colocou o número em perspectiva comparando a memória recuperada com sua geração atual de servidores.
Cada servidor Gen 13 utilizado pela empresa possui aproximadamente 768 GB de DDR5-6400.
Os 100 TB recuperados apenas com otimizações de software equivalem aproximadamente à quantidade de memória instalada em 130 desses servidores.
E isso sem precisar comprar nenhum deles.
A empresa chegou a considerar configurações com 1.152 GB de RAM para essa geração de hardware, mas decidiu não adotá-las depois de analisar o custo dos módulos de maior capacidade.
Cloudflare não pretende deixar esses 100 TB vazios
A memória recuperada não ficará simplesmente sem utilização.
A Cloudflare pretende utilizar parte desse espaço para aumentar a quantidade de informações mantidas nos caches DNS.
Um cache maior significa maior probabilidade de uma consulta DNS já possuir a resposta disponível localmente.
Isso pode reduzir ainda mais a latência percebida pelos usuários e diminuir a quantidade de consultas que a infraestrutura precisa encaminhar aos servidores DNS autoritativos espalhados pela Internet.
Ou seja: a Cloudflare não apenas reduziu seus custos de memória. Ela transformou o espaço recuperado em capacidade adicional para acelerar o próprio DNS.
O melhor upgrade pode ser não comprar hardware
O caso do Big Pineapple é também um ótimo exemplo de algo que às vezes fica esquecido em uma indústria obcecada por processadores maiores, mais RAM e novos aceleradores: software eficiente continua sendo uma das formas mais poderosas de aumentar capacidade computacional.
Trocar um servidor por outro com o dobro da memória resolve um problema rapidamente.
Descobrir por que centenas de bilhões de objetos estão desperdiçando dezenas ou centenas de bytes exige muito mais engenharia.
Mas quando o sistema opera na escala da Cloudflare, o resultado pode ser equivalente a adicionar dezenas ou até centenas de servidores sem colocar uma única máquina nova no rack.
E, neste caso, ainda deixando o sistema mais rápido.
100 TB recuperados simplesmente reorganizando bits na memória. Para qualquer geek que já passou uma madrugada tentando economizar alguns megabytes em um servidor, é difícil não apreciar a escala da coisa.
