Distribuzione della configurazione di rete di Databricks a decine di milioni di VM serverless

Riepilogo

• La piattaforma serverless di Databricks avvia decine di milioni di VM ogni giorno e ogni VM necessita di una configurazione di rete, come le destinazioni consentite e gli endpoint privati, prima di poter gestire i carichi di lavoro dei clienti. Poiché ogni nodo recupera la configurazione all'avvio ed esegue il polling per gli aggiornamenti durante il suo ciclo di vita, questo si traduce in miliardi di richieste di configurazione di rete al giorno. La vecchia architettura recuperava queste informazioni da più servizi a monte in modo sincrono, creando colli di bottiglia in termini di latenza e disponibilità.
• Abbiamo riprogettato la distribuzione della configurazione di rete utilizzando pipeline basate su eventi e la pre-computazione degli snapshot, riducendo la latenza RPC del 97,5% (da 5.000 ms a 125 ms) e raggiungendo una disponibilità del servizio del 99,99%.

Definizione del problema

La piattaforma di calcolo serverless di Databricks alimenta praticamente tutti i nostri prodotti di dati e AI, come SQL warehouse, notebook, endpoint di serving ML e altro ancora. La piattaforma avvia decine di milioni di VM ogni giorno su AWS, Azure e GCP.

Prima che qualsiasi carico di lavoro serverless possa essere eseguito, la VM deve conoscere la sua configurazione di rete: a quali destinazioni di archiviazione può accedere? Ci sono endpoint di collegamento privati (private link) attraverso i quali instradare il traffico? Ci sono modifiche recenti in Unity Catalog che consentono l'accesso a nuove destinazioni di archiviazione? Dobbiamo iniziare a utilizzare nuove destinazioni condivise tramite Delta Sharing?

La sfida è che la configurazione di rete non è memorizzata in un unico posto. Deve essere assemblata a partire da molteplici servizi a monte, ognuno dei quali contribuisce a comporre il quadro completo.

La vecchia architettura

Nel design originale, ogni volta che si avviava un cluster serverless, il nostro servizio di configurazione di rete chiamava in modo sincrono tutti i servizi a monte, ne aggregava le risposte, calcolava la configurazione di rete per ciascun workspace e la restituiva al data plane serverless. Questo avveniva nel percorso critico della creazione del cluster.

Sebbene la vecchia architettura fosse semplice e funzionasse bene su scala ridotta, soffriva di problemi fondamentali, che si riflettevano nelle seguenti metriche monitorate sulla nostra dashboard operativa:

1. Latenza: con molteplici servizi a monte sul percorso critico, la latenza RPC per la fornitura della configurazione di rete era di 5.000 ms al p99. Ciò influiva sulla latenza di avvio del cluster serverless.
2. Tasso di successo del server: ogni servizio a monte ha le proprie caratteristiche di disponibilità. Con diversi servizi in serie, la disponibilità complessiva diminuisce rapidamente, traducendosi in una maggiore probabilità di errori di avvio dei cluster serverless all'anno.

Con la rapida crescita dell'utilizzo del serverless, il modello sincrono è diventato sempre più insostenibile. Ogni chiamata sincrona attivava operazioni onerose in tutti i workspace, spesso eseguendo calcoli duplicati. Questo ha aggiunto un carico che cresceva proporzionalmente al numero di tenant e alle loro risorse configurate.

Soluzione: pre-computazione basata su eventi

Abbiamo riprogettato da zero il modo in cui Databricks distribuisce la configurazione di rete. Il nuovo sistema si basa su questi principi fondamentali:

1. Pipeline basata su eventi: invece di effettuare chiamate sincrone a tutti i servizi a monte, il nuovo sistema si iscrive agli eventi di modifica tramite una coda di messaggi. Quando un cliente crea una nuova connessione Unity Catalog o modifica una policy di rete, il servizio a monte emette un evento. Il sistema lo elabora e aggiorna la configurazione pre-computata.
2. Pre-computazione degli snapshot: le configurazioni di rete vengono calcolate in modo asincrono in background e memorizzate in un archivio di snapshot pre-computati. Il percorso di erogazione diventa un singolo e leggero recupero dall'archivio, completamente disaccoppiato dai servizi a monte.
3. Stabilità statica: in caso di interruzione di un servizio a monte, possiamo mantenere una configurazione statica, garantendo stabilità statica ai cluster serverless.

L'architettura separa nettamente due percorsi. Il percorso di gestione viene eseguito in modo asincrono in background: i servizi a monte emettono eventi di modifica in una coda di messaggi, che un elaboratore di eventi consuma per determinare quali workspace sono interessati e propagare le notifiche di aggiornamento per ciascun workspace. Un gestore di eventi locale recupera quindi i dettagli pertinenti a monte, ricalcola la configurazione di rete del workspace e memorizza il risultato in un archivio di snapshot pre-computati. Inoltre, un riconciliatore periodico sincronizza nuovamente tutti i workspace in background, garantendo la consistenza eventuale anche in caso di eventi mancati. Il percorso di erogazione, al contrario, è critico e veloce: quando un cluster serverless si avvia e necessita della configurazione di rete, il servizio di configurazione di rete la fornisce direttamente dall'archivio degli snapshot con una singola lettura, senza richiedere chiamate ai servizi a monte e riducendo significativamente il carico su di essi.

Decisioni chiave di progettazione

• I servizi a monte inviano gli eventi di modifica alla coda di messaggi. Il sistema elabora questi eventi in background. Un riconciliatore a bassa frequenza sincronizza periodicamente tutti i workspace come rete di sicurezza, offrendo l'affidabilità del framework sincrono unita all'efficienza del modello push.
• Le configurazioni di rete vengono calcolate e memorizzate localmente all'interno di ciascuna partizione del servizio, co-locate con i workspace che servono. Ciò distribuisce il calcolo, riduce il raggio d'impatto durante gli incidenti ed elimina le dipendenze tra partizioni diverse sul percorso di erogazione.
• I messaggi degli eventi contengono solo gli identificatori del workspace e delle risorse. Questo mantiene gli eventi leggeri, li rende idempotenti (possono essere riprodotti in qualsiasi ordine) ed evita il trasferimento di dati sensibili dei clienti attraverso la pipeline di messaggistica.

Flusso degli eventi

Quando un cliente crea una nuova connessione Unity Catalog, Unity Catalog emette un evento di modifica nella coda di messaggi. L'elaboratore di eventi riceve quindi l'evento, determina quali workspace sono collegati al metastore interessato e propaga una notifica di aggiornamento per ciascun workspace. Nella partizione di ciascun workspace, il gestore degli eventi riceve questa notifica, recupera i dettagli della connessione aggiornati, ricalcola la configurazione di rete del workspace e la memorizza con un nuovo contrassegno di versione. Da quel momento in poi, quando un cluster serverless richiede la configurazione di rete, questa viene fornita direttamente dall'archivio degli snapshot, senza necessità di chiamate a monte.

Impatto

Dopo l'introduzione della nuova architettura, i risultati sono stati straordinari per tutte le metriche operative:

Oltre alle metriche principali:

1. Il volume delle chiamate a monte è stato ridotto dell'86%. Il sistema chiama i servizi a monte solo quando un evento indica una modifica, non a ogni richiesta.
2. Abbiamo osservato un miglioramento significativo nella freschezza della configurazione di rete.
3. Il framework sincrono legacy è stato completamente deprecato.

Conclusione

Questo progetto ci ha insegnato diverse lezioni sulla gestione dell'infrastruttura di rete su scala cloud:

La pre-computazione disaccoppia i percorsi critici. Spostando l'onerosa aggregazione in background, il percorso di erogazione diventa estremamente semplice e veloce. Questa è stata la singola decisione architetturale di maggiore impatto. Ha trasformato una catena di dipendenze multi-servizio in una singola lettura dall'archivio.

L'architettura basata su eventi scambia la consistenza con la scalabilità, mentre la riconciliazione fornisce una rete di sicurezza. Il modello push basato su eventi gestisce i casi comuni in modo efficiente, mentre un riconciliatore periodico recupera eventuali anomalie sfuggite.

Progettare per l'estensibilità fin dal primo giorno. L'architettura modulare a fasi consente di aggiungere il supporto per una nuova origine dati a monte semplicemente implementando una nuova fase, senza alcuna modifica alla pipeline principale. Con l'espandersi dell'offerta di prodotti Databricks, il sistema di configurazione di rete scala di conseguenza.

Oggi, questo sistema gestisce miliardi di richieste di configurazione di rete al giorno in tutta la flotta serverless globale di Databricks, con una latenza di circa 125 ms e una disponibilità del 99,99%. Con la continua e rapida crescita del calcolo serverless, l'architettura basata su eventi garantisce che la distribuzione della configurazione di rete scali di pari passo.

Siamo sempre alla ricerca di ingegneri che amano affrontare le sfide dei sistemi distribuiti su scala globale. Se questo tipo di problemi ti appassiona, ci piacerebbe molto conoscerti: dai un'occhiata alle posizioni aperte su databricks.com/careers!

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale