Cloudflare ha recuperato circa 100 TB di memoria RAM dalla propria infrastruttura DNS senza sostituire server o aggiungere memoria. Il risultato è stato ottenuto intervenendo direttamente sul modo in cui la piattaforma Big Pineapple rappresenta e conserva in memoria le entry della cache DNS. L’ottimizzazione ha permesso non solo di ridurre sensibilmente il consumo di memoria, ma anche di migliorare le prestazioni della cache.
Big Pineapple è alla base di diversi servizi DNS di Cloudflare, tra cui il resolver pubblico 1.1.1.1, il Gateway DNS, il DNS Firewall e AS112. La piattaforma mantiene contemporaneamente oltre 250 miliardi di entry DNS. A una scala di questo tipo, anche un singolo byte superfluo per entry comporta oltre 250 GB di memoria aggiuntiva sull’intera infrastruttura.
Le modifiche sono state applicate progressivamente al codice scritto in Rust e hanno riguardato cinque aspetti della rappresentazione dei dati. Il primo intervento ha eliminato parte dell’overhead associato a Vec e String. Queste strutture mantengono infatti, oltre a puntatore e lunghezza, anche la capacità riservata per eventuali successive espansioni. Una caratteristica inutile nel caso delle entry DNS, che dopo essere state inserite nella cache non devono più crescere.
Cloudflare ha quindi utilizzato Boxe Box, strutture a dimensione fissa che non hanno bisogno del campo relativo alla capacità. Considerando gli otto campi interessati presenti in ogni entry, questa modifica ha consentito di risparmiare 64 byte per entry, oltre a eliminare lo spazio inutilizzato dalle allocazioni sovradimensionate. Rapportato all’intera infrastruttura, il solo intervento vale oltre 15 TB di RAM.
Un secondo intervento ha riguardato l’organizzazione delle sezioni delle risposte DNS. In precedenza, le sezioni answer, authority e additional erano conservate in liste separate. Cloudflare le ha riunite in un’unica struttura, usando offset di dimensione ridotta per individuare l’inizio delle diverse sezioni. Poiché il numero di record può essere rappresentato con un u16, gli offset richiedono molto meno spazio rispetto alle strutture separate, con un risparmio di 28 byte per entry. Gli ingegneri hanno inoltre compattato alcuni campi booleani in bitflag, riducendo anche il padding inserito da Rust per rispettare i requisiti di allineamento delle strutture.
La terza ottimizzazione ha eliminato dati ridondanti relativi al nome proprietario dei record DNS. Nella maggior parte dei casi il dominio associato al record coincide con quello richiesto dal client. In queste situazioni non è necessario memorizzarlo nuovamente: durante la costruzione della risposta, il nome può essere ricavato direttamente dalla chiave della cache. Il nome completo continua invece a essere conservato quando è differente, come può accadere nel caso di una risposta che coinvolge un CNAME.
Un’altra fonte di spreco era rappresentata dagli enum utilizzati da Rust per i diversi tipi di record DNS. Un enum occupa lo spazio necessario alla variante più grande. Nel caso di Big Pineapple, il tipo NAPTR richiede fino a 136 byte e porta la dimensione complessiva della struttura a 144 byte considerando tag e padding. Un record A necessita invece di soli 4 byte, mentre un AAAA ne richiede 16. Poiché A e AAAA rappresentano oltre l’80% del traffico considerato nei benchmark, gran parte dello spazio allocato rimaneva inutilizzato.
Cloudflare ha inizialmente spostato le varianti più grandi dell’enum in memoria heap tramite Box, lasciando inline quelle più piccole e frequenti. Questa soluzione riduceva il footprint, ma introduceva nuove allocazioni e peggiorava la località dei dati, costringendo il processore a seguire puntatori verso aree di memoria potenzialmente distanti.
La soluzione finale è stata quindi quella di memorizzare i dati dei record direttamente in un buffer di byte nel formato binario DNS, mantenendo strutturati gli altri metadati della cache. Ogni record viene preceduto dalla propria lunghezza e i dati sono conservati in modo contiguo. In questo modo vengono eliminati sia l’overhead degli enum sia le molteplici allocazioni heap. Per i record A, AAAA, TXT e per quelli DNSSEC i dati possono inoltre essere copiati direttamente nella risposta, evitando di ricostruirli campo per campo. Solo record che contengono nomi di dominio, come CNAME, NS, MX e SOA, richiedono ulteriore elaborazione per applicare la compressione DNS.
La nuova organizzazione ha anche migliorato la località dei dati nella cache della CPU. Secondo i benchmark interni, la sola modifica relativa al buffer dei record ha incrementato del 13% il throughput delle operazioni di inserimento, mentre sul percorso di ricerca ha contribuito a una riduzione della latenza del 5%.
Per valutare l’effetto complessivo, Cloudflare ha utilizzato entry generate artificialmente sulla base della distribuzione osservata in produzione: 56% di record A, 25% AAAA e 19% TXT, con una o quattro registrazioni per entry. I test hanno inoltre misurato sia la memoria utilizzata sia il numero e la dimensione delle allocazioni, oltre a throughput e latenza.
Il risultato complessivo delle cinque ottimizzazioni è una riduzione della memoria necessaria per una singola entry da circa 953 a 420 byte, pari al 56% in meno. Considerando invece tutta la memoria allocata, il valore è passato da circa 1,1 KB a 461 byte per entry, con una riduzione prossima al 58%.
L’effetto è stato confermato anche sulle istanze in produzione. Al 99° percentile, il consumo di memoria residente è sceso da 9,3 a 5,3 GB per istanza, con una riduzione del 43%. Al 90° percentile è passato da 6,5 a 3,8 GB, pari al 42% in meno. Il consumo complessivo del working set dell’intera infrastruttura è diminuito di circa 100 TB dopo il completamento della distribuzione delle modifiche, avviata il 18 maggio 2026 e terminata il 6 luglio.
Anche le prestazioni sono migliorate: il throughput degli inserimenti nella cache è aumentato da circa 625.000 a 893.000 entry al secondo, mentre la latenza delle operazioni di lookup è scesa da circa 828 a 670 nanosecondi. Il risparmio di memoria, quindi, non è stato ottenuto sacrificando la velocità, ma attraverso una rappresentazione più compatta e una riduzione delle allocazioni.
Cloudflare intende ora utilizzare la memoria liberata per aumentare la capacità delle cache senza incrementare il consumo complessivo di RAM. Cache più grandi possono aumentare il tasso di hit e, di conseguenza, ridurre il numero di richieste che devono essere inoltrate verso i server DNS upstream. L’azienda sta inoltre valutando ulteriori interventi di ottimizzazione direttamente sulla cache di Big Pineapple.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
