In questo articolo Indice dei contenuti 3 sezioni
Modificare un record nel pannello di gestione di un dominio richiede pochi secondi, ma far arrivare quella modifica in modo corretto a migliaia di server sparsi nel mondo è un lavoro molto più complesso. Cloudflare ha riprogettato una parte centrale della propria infrastruttura DNS e i risultati sono notevoli. Nei picchi di utilizzo la memoria consumata cala dell’85% e i tempi mediani di elaborazione delle modifiche scendono da 7,7 a circa 3,3 secondi. Dietro questo salto non c’è hardware più potente. C’è una revisione del modo in cui la piattaforma individua, prepara e distribuisce i dati.
La faccenda tocca da vicino chi gestisce domini, applicazioni web e servizi online. Il Domain Name System collega i nomi di dominio alle informazioni necessarie per raggiungere i servizi su Internet. Quando un amministratore cambia un indirizzo IP, aggiunge un sottodominio o mette mano alle impostazioni di una zona, i server autorevoli devono ricevere dati aggiornati. Basta un ritardo nella distribuzione perché le risposte cambino a seconda del server interrogato.
Zone Builder e la logica del lavoro minimo
Cambiare un record e preparare i dati che i server useranno davvero sono due operazioni ben distinte. Per la seconda la società guidata da Matthew Prince si affida allo Zone Builder, un componente che legge le informazioni dai database, applica le regole di pubblicazione e produce una rappresentazione ottimizzata. La novità si chiama targeted build planner e serve a stabilire quali dati vadano rigenerati dopo ogni evento, cercando il lavoro minimo compatibile con un risultato corretto.
Il sistema riconosce cinque tipi di intervento. Il più circoscritto e in genere il meno costoso riguarda le singole risorse. Se cambia un record A, AAAA, TXT o CNAME viene aggiornato solo il nome interessato, quindi una variazione dell’indirizzo IP di www.example.com non obbliga a rielaborare il resto della zona. Alcune modifiche toccano anche le informazioni che i server usano per interpretare la zona, come certi aggiornamenti ai nameserver o ai record wildcard del tipo *.example.com. In quel caso vengono rigenerati le risorse coinvolte e i metadati condivisi, senza rifare tutto.
Esiste poi l’intervento sull’apex, cioè sul dominio principale come example.com anziché sui sottodomini. Attivare o disattivare Universal SSL può richiedere di aggiornare i record CAA, quelli che indicano quali autorità di certificazione possono emettere certificati per il dominio, e basta rigenerare l’apex con i relativi metadati. La rimozione della zona elimina invece le informazioni che la rendono disponibile ai server autorevoli e aggiorna i metadati condivisi, così che nessuno continui a considerarla valida. Resta infine la ricostruzione completa, la più pesante per memoria e calcolo, indispensabile quando una modifica coinvolge molte risorse o quando non si riesce a capire con certezza cosa aggiornare.
La regola scelta dagli ingegneri è severa. Ogni chiave prodotta da una ricostruzione mirata deve coincidere byte per byte con quella ottenuta da una ricostruzione integrale. Se questa equivalenza non può essere garantita si torna al rifacimento completo, tranne per le zone così grandi da renderlo impraticabile.
Notifiche più ricche e nessuna modifica persa
Ridurre le operazioni non basta, bisogna anche sapere con esattezza cosa è cambiato ed evitare che aggiornamenti successivi si sovrappongano o spariscano. Le notifiche ora indicano quali impostazioni o record sono stati modificati e, quando possibile, il valore precedente e quello nuovo. Se mancano dettagli sufficienti scatta la ricostruzione completa. Per le zone enormi vengono aggiornati soltanto il dominio principale, i metadati e i nomi individuati dagli eventi disponibili.
Un caso delicato si presenta quando più zone condividono lo stesso nome, per esempio durante una migrazione. Qui i server devono usare gli identificativi giusti e i record devono essere pronti prima che vengano pubblicati i metadati che li richiamano. A coordinare il tutto c’è uno scheduler unificato che raggruppa più modifiche alla stessa zona in un’unica elaborazione rispettando le dipendenze. Le notifiche passano da Apache Kafka e un messaggio viene confermato solo quando tutte le operazioni precedenti sono concluse. Se un processo si interrompe qualche aggiornamento può ripetersi, ma non deve andare perduto. Prima di procedere lo Zone Builder controlla anche lo stato effettivo della zona e verifica che le repliche del database abbiano già ricevuto le modifiche segnalate, perché Kafka e database non sempre si allineano nello stesso istante e una notifica potrebbe arrivare prima dei dati.
I numeri di Cloudflare in 24 ore
Le misurazioni raccolte in una finestra di 24 ore mostrano che l’86,81% delle elaborazioni riguarda soltanto risorse specifiche. Il 2,54% coinvolge risorse e metadati, il 2,30% apex e metadati, l’1,30% le rimozioni e appena il 7,04% le ricostruzioni complete. In totale il 92,95% delle operazioni evita un rifacimento integrale e i full build calano di circa il 40% rispetto al passato, con vantaggi evidenti soprattutto per le zone più grandi.
Il consumo medio aggregato di memoria dello Zone Builder passa da 49 GB a 7 GB, una riduzione dell’86%, mentre nei picchi si scende da 79 GB a 12 GB, circa l’85% in meno. Migliora anche la gestione dei ritardi più estremi, visto che gli eventi più lenti hanno molte meno probabilità di accumulare attese prolungate.
Fonte: TecnoAndroid