A Cloudflare anunciou os resultados de uma série de otimizações de baixo nível no armazenamento de DNS da plataforma Big Pineapple, a plataforma que executa o 1.1.1.1, o Gateway DNS, o DNS Firewall, o AS112 e vários outros serviços DNS. A plataforma armazena mais de 250 bilhões de entradas DNS a qualquer momento; portanto, eliminar um único byte por entrada economiza mais de 250 gigabytes de memória em toda a frota.
Cinco mudanças consecutivas na estrutura de dados escrita em Rust reduziram o tamanho de cada entrada de 953 bytes para 420 bytes, uma redução de 56%. Depois que as mudanças foram implementadas em toda a frota, a memória do conjunto de trabalho usada pela frota da Cloudflare caiu cerca de 100 terabytes, com melhoria de desempenho em vez de concessões: a velocidade de inserção das entradas aumentou 43%, e o tempo de pesquisa no armazenamento caiu 19%.
Por que o tamanho da entrada DNS era importante?
O Big Pineapple começa com um armazenamento vazio durante a inicialização e depois se preenche à medida que as consultas chegam, até atingir o limite máximo; então, as entradas mais antigas ou menos usadas são removidas. O tamanho do armazenamento varia entre os data centers, e o uso de EDNS Client Subnet também pode levar ao armazenamento de várias respostas para a mesma consulta, pois os servidores autoritativos podem fornecer respostas diferentes dependendo da rede do cliente.
Cada entrada consiste em uma chave que identifica o nome do domínio, o tipo de registro e alguns atributos, além de um valor que contém uma resposta DNS, seções authority e additional e metadados como horário de criação, contador de usos e duração do TTL. Nesse volume, campos extras ou espaço reservado deixam de ser pequenos detalhes internos e se transformam em um enorme custo operacional.
De onde vieram as economias?
A Cloudflare substituiu as estruturas Vec e String expansíveis por estruturas de tamanho fixo, Box<[T]> e Box<str>, depois que a resposta é armazenada, pois os dados não são modificados posteriormente. Essa mudança removeu o campo de capacidade mantido pelas estruturas expansíveis e também limitou o espaço reservado não utilizado. Como cada entrada contém oito campos desse tipo, a economia chegou a 64 bytes por entrada, ou mais de 15 terabytes em todo o armazenamento.
As listas das seções de resposta, autoridade e adicionais também foram reunidas em uma única lista, usando deslocamentos do tipo u16 em vez de ponteiros e comprimentos maiores. Isso permitiu economizar 28 bytes por entrada. A estrutura também se beneficiou da compactação de vários campos booleanos em uma única bitflag, reduzindo o espaço desperdiçado devido ao alinhamento de memória imposto pelo Rust dentro das estruturas.
Na maioria dos registros DNS, o proprietário do registro corresponde ao domínio consultado. Por isso, a Cloudflare deixou de armazenar o nome completo do proprietário nesses casos e passou a recuperá-lo da chave de armazenamento ao construir a resposta. Quando o nome é diferente, como ocorre com registros CNAME, o nome completo é armazenado. Dessa forma, as alocações de memória para a maioria dos nomes de proprietários foram eliminadas, mantendo as situações que realmente precisam do nome.
Reduzindo o custo dos tipos de registros grandes
A estrutura RecordData usava um enum cujo tamanho era igual ao do maior tipo de registro, o NAPTR, com 144 bytes após considerar a tag e o alinhamento. Como resultado, os registros A, que precisam de apenas 4 bytes, e os registros AAAA, que precisam de 16 bytes, ocupavam muito mais espaço do que o necessário, embora A e AAAA representassem mais de 80% do tráfego de teste.
Foi testado o armazenamento dos tipos grandes em um Box separado, o que reduziu o desperdício nos registros A e AAAA, mas acrescentou alocações separadas e problemas de locality de memória. A solução final foi armazenar os próprios dados dos registros como bytes brutos contíguos dentro de um Box<[u8]>, com um prefixo de comprimento de dois bytes para cada registro. Isso eliminou o custo do enum e das múltiplas alocações, além de melhorar o aproveitamento da memória cache pelo processador.
Essa escolha significa que os registros não podem mais ser indexados aleatoriamente; é preciso percorrê-los sequencialmente. A Cloudflare considera o custo limitado porque o número de registros em uma única entrada é pequeno. A maioria dos tipos, incluindo A, AAAA, TXT e registros DNSSEC, também pode ser copiada diretamente para a mensagem DNS de saída, enquanto os tipos que contêm nomes de domínio, como CNAME, NS, MX e SOA, ainda precisam ser analisados para aplicar a compactação de nomes DNS.
O que mudou na prática?
As medições em produção mostraram uma redução da memória residente no percentil 99 de 9,3 para 5,3 gigabytes, ou 43%, e de 6,5 para 3,8 gigabytes no percentil 90, ou 42%. As alocações por entrada caíram de 1,1 quilobyte para 461 bytes, enquanto a velocidade de inserção aumentou de 625 mil entradas por segundo para 893 mil, e o tempo de pesquisa caiu de 828 nanossegundos para 670 nanossegundos.
A implementação das mudanças começou em 18 de maio de 2026 e foi concluída em todos os serviços em 6 de julho de 2026. A Cloudflare explica que a memória residente em produção inclui outros dados além do armazenamento; por isso, a porcentagem de redução efetiva no nível do processo foi menor que o resultado da medição isolada por entrada. A empresa também planeja reinvestir a memória liberada no aumento da capacidade do armazenamento sem elevar o consumo de memória, com o objetivo de melhorar as taxas de acerto do cache e reduzir as consultas enviadas aos servidores upstream.
A importância desse caso está em mostrar que melhorias na estrutura de dados, como remover capacidade desnecessária, reunir alocações e melhorar a locality, podem produzir um impacto maior que a adição direta de recursos de hardware quando o serviço opera com centenas de bilhões de elementos. No entanto, algumas concessões permanecem: o armazenamento bruto aumenta a complexidade do tratamento dos registros, recuperar a chave de armazenamento torna-se necessário para reconstruir os nomes dos proprietários, e os resultados dos testes dependem de uma combinação específica de tráfego que não corresponde totalmente à produção. Por isso, as medições em produção, e não apenas os números teóricos, continuam sendo a referência mais importante ao avaliar esse tipo de otimização.