Cloudflare ha riprogettato la propria pipeline di propagazione DNS per gestire in modo più efficiente un flusso crescente di modifiche ai record e alle impostazioni delle zone. Ora il Zone Builder riceve circa 700 modifiche ai record DNS al secondo, oltre a circa 100 altri eventi, mentre alcune zone contengono più di 20 milioni di record e sono destinate a crescere ulteriormente.
Il problema principale non era il numero di eventi, ma la quantità di lavoro richiesta da alcune modifiche. In precedenza, un evento relativo alle impostazioni di una zona poteva attivare una ricostruzione completa: leggere ogni record, convertirlo in chiavi Quicksilver e confrontare il risultato con lo stato esistente. Questo approccio è diventato sempre più costoso per le zone di grandi dimensioni e poteva richiedere più memoria di quella disponibile.
Cloudflare ha creato un pianificatore mirato che seleziona l’operazione più piccola di cui possa dimostrare la sicurezza. Uno scheduler unificato combina quindi il lavoro in sospeso per la stessa zona. A seconda della modifica, il sistema può ricostruire nomi DNS specifici, aggiornare tali nomi insieme ai metadati condivisi, ricostruire l’apice della zona e i metadati, eliminare una zona oppure eseguire una compilazione completa della zona.
Le normali modifiche ai record, come gli aggiornamenti ai record A, AAAA, TXT e CNAME, generalmente riguardano solo le chiavi relative ai nomi DNS interessati. Le modifiche ai nameserver e ai wildcard possono influire anche sui metadati condivisi, mentre impostazioni come Universal SSL possono richiedere la ricostruzione dell’apice e di tali metadati. Quando il sistema non può stabilire che un’operazione più piccola produrrà esattamente lo stesso risultato di una compilazione completa, mantiene il percorso di compilazione completa.
Il pianificatore si basa su eventi più dettagliati provenienti dai sistemi che producono le modifiche alle zone. Questi eventi includono le impostazioni modificate e, quando disponibili, i relativi valori precedenti e nuovi. Gli eventi ambigui, le informazioni mancanti e gli aggiornamenti che potrebbero influire sui record dell’intera zona continuano ad attivare una compilazione completa, invece di rischiare di lasciare dati obsoleti ai margini della rete.
Cloudflare ha dovuto inoltre tenere conto dei domini che temporaneamente dispongono di più oggetti di zona interni. Le chiavi dei record sono memorizzate separatamente per ogni zona, mentre una chiave di metadati condivisa identifica quali zone con lo stesso nome possono essere pubblicate. Quando sono coinvolti tali metadati, il builder legge l’elenco attuale dei candidati e ricostruisce la chiave a partire dallo stato aggiornato, invece di applicare una patch a una versione precedente.
La pianificazione avviene due volte perché il database potrebbe cambiare dopo la generazione di un evento. Immediatamente prima dell’esecuzione, il Zone Builder verifica le impostazioni attuali, lo stato di pubblicazione per la rete interessata e l’elenco più recente degli ID delle zone con lo stesso nome. Questo può trasformare un’operazione mirata in una compilazione completa, convertirla in un’eliminazione, saltarla oppure richiedere la ricostruzione della chiave dei metadati condivisi.
Lo scheduler unisce le modifiche in sospeso per una zona, aggiungendo i nomi interessati e preservando i requisiti relativi ai metadati. Un’eliminazione ha la precedenza sulle operazioni di ricostruzione. Le conferme di Kafka vengono tracciate separatamente dal lavoro DNS, garantendo che i tentativi successivi non perdano messaggi anche quando diversi eventi sono stati combinati in un’unica compilazione.
Per proteggere l’elaborazione ordinata di Kafka, Cloudflare utilizza il soft committing. Una compilazione completata può essere registrata in memoria prima che termini il lavoro precedente nella stessa partizione, ma l’offset confermato da Kafka avanza solo dopo il completamento di tutti i messaggi precedenti. Se il builder viene riavviato, i completamenti conservati in memoria vengono riprodotti, evitando il rischio di perdere una modifica.
Per le zone molto grandi, il sistema evita di ricorrere a una compilazione completa oltre una soglia fissa di numero di record, perché mantenere in memoria tutti i record e le chiavi Quicksilver esistenti potrebbe impedire il completamento della compilazione. Invece, ricostruisce l’apice, i metadati e i nomi identificati dagli eventi in coda. Questo approccio riduce il rischio che una singola compilazione impossibile da completare blocchi altre modifiche sulla stessa partizione Kafka.
Cloudflare ha testato le compilazioni mirate rispetto alle compilazioni complete usando confronti byte per byte delle chiavi Quicksilver pertinenti. Ha inoltre implementato un Zone Builder mirror che consumava eventi di produzione e lo stato del database, scrivendo in un ambiente Quicksilver isolato. Prima del rilascio progressivo del nuovo scheduler, un sistema di confronto verificava un campione di zone alla ricerca di chiavi mancanti, chiavi aggiuntive e valori differenti.
Le modifiche risultanti hanno ridotto del 40% le compilazioni complete, diminuito dell’85% il consumo massimo di memoria e dimezzato il ritardo tra una modifica DNS e la scrittura dei relativi dati in Quicksilver. Durante un periodo di misurazione di 24 ore, l’86,81% delle compilazioni è stato classificato come operazione limitata alle risorse, mentre il 2,54% ha ricostruito le risorse insieme ai metadati.
Fonti: Cloudflare Blog.