Cloudflare recupera oltre 100 TB di RAM con ottimizzazione del consistent hashing

Cloudflare ha liberato oltre 100 TB di RAM dal servizio interno di bilanciamento del carico ottimizzando l’implementazione in Rust del consistent hashing in pingora-ketama¹.

Pingora Backend Router distribuisce le richieste cacheable tra server. Pesi diversi e combinazioni di funzionalità hanno imposto molti hash ring, con un forte aumento della memoria usata. Il team ha rintracciato l’eccesso nelle strutture dati di pingora-ketama e ha avviato un lavoro mirato di riduzione¹.

Le modifiche hanno compattato le entry dell’hash ring. Un’analisi statistica della distribuzione degli hash e dei tassi di collisione ha poi permesso di tagliare il numero di hash per backend di circa il 90 per cento, mantenendo l’accuratezza del bilanciamento¹.

Passo chiave: applicare la teoria della probabilità al consistent hashing. Il gruppo di lavoro ha determinato il numero minimo di punti di hash necessario per ottenere la distribuzione richiesta. Con questo vincolo ha ridotto in modo netto la dimensione delle strutture, senza perdere la precisione necessaria nella ripartizione del traffico¹.

Risultato, in due numeri: memoria reclamata oltre 100 TB, hash per backend meno 90 per cento. L’accuratezza del bilanciamento resta invariata rispetto a prima dell’intervento¹.

Il contesto operativo spiega l’impatto. Il router di backend affida agli anelli la distribuzione delle richieste che si possono mettere in cache. Ogni combinazione di pesi e funzionalità introduce nuovi anelli, la somma fa crescere la memoria occupata. Ridurre la dimensione e il numero dei punti negli anelli limita questo effetto senza cambiare il comportamento di distribuzione richiesto¹.

Sequenza del lavoro, come da informazioni pubblicate: misurazione del consumo di memoria, tracciamento dell’origine nelle strutture di pingora-ketama, compattazione delle entry, analisi della distribuzione degli hash e delle collisioni. Infine, uso della probabilità per fissare la soglia minima di punti, così da tagliare i dati mantenendo i vincoli di accuratezza¹.

Nel report compare Kevin Guthrie, principal distributed systems engineer di Cloudflare¹. Il focus resta sulle scelte di progettazione delle strutture di hashing, sulla riduzione dei punti per backend e sulla verifica statistica di distribuzione e collisioni¹.

Esito operativo diretto: i ring occupano meno memoria e rispettano gli obiettivi di distribuzione. Il sistema continua a gestire server con pesi diversi e combinazioni di funzionalità, con carico di memoria ridotto grazie alla compattazione e alla selezione del numero minimo di punti di hash ricavata dall’analisi probabilistica¹.

Il caso indica una leva concreta per i servizi che usano consistent hashing: definire con la probabilità la soglia minima di punti per la distribuzione richiesta permette di ridurre memoria e dati senza sacrificare l’accuratezza, anche quando la moltiplicazione degli anelli tende a far crescere le strutture¹.