Ripensare i Sistemi Distribuiti per Prestazioni e Affidabilità Serverless

La creazione di un'infrastruttura di calcolo veramente serverless per Apache Spark ha richiesto la risoluzione di sfide architettoniche fondamentali esistenti fin dall'inizio di Spark. La complessità va ben oltre la semplice creazione di pool di macchine "caldi" o l'implementazione di un autoscaling di base. Ha richiesto di ripensare le ipotesi fondamentali su come dovrebbero funzionare i sistemi di calcolo distribuiti.

Le distribuzioni tradizionali di Spark espongono l'infrastruttura direttamente agli utenti, creando un forte accoppiamento tra applicazioni e risorse di calcolo. I carichi di lavoro competono per risorse condivise, piccole inefficienze possono degenerare in guasti e gli utenti sono costretti a bilanciare manualmente prestazioni, costi e affidabilità. Al variare della domanda, i sistemi faticano a mantenere sia un'elevata utilizzazione che prestazioni prevedibili.

Il calcolo serverless adotta un approccio diverso gestendo completamente l'infrastruttura in modo che l'utente possa concentrarsi sui dati e sugli insight. La stabilità diventa una proprietà del sistema piuttosto che una responsabilità dell'utente, resa possibile da architetture che isolano i carichi di lavoro, li posizionano in modo intelligente e adattano dinamicamente le risorse.

Il calcolo serverless è progettato per migliorare stabilità, prestazioni e semplicità operativa. Tre sistemi fondamentali lo rendono possibile:

1. Spark Connect, che separa le applicazioni utente dall'infrastruttura di calcolo
2. Il Serverless Gateway, che instrada in modo intelligente i carichi di lavoro tra le risorse di calcolo
3. Un autoscaler adattivo, che ottimizza continuamente le dimensioni del cluster per prestazioni e costi

Insieme, questi sistemi abilitano un modello in cui le prestazioni sono raggiunte garantendo innanzitutto la stabilità dell'intero sistema.

Spark Connect: Stabilità attraverso l'isolamento

Spark Connect rappresenta la trasformazione architettonica più significativa nella storia di Spark, un completo allontanamento dal design monolitico che ha definito il calcolo distribuito per oltre un decennio. Nelle architetture tradizionali, le applicazioni utente vengono eseguite direttamente sulla stessa macchina del driver Spark, creando un forte accoppiamento che introduce limitazioni critiche. Quando più applicazioni competono per le risorse sullo stesso cluster o quando il codice utente consuma memoria o CPU eccessive, il sistema diventa instabile, portando a guasti che possono propagarsi tra i carichi di lavoro.

Spark Connect introduce un'architettura client-server in cui le applicazioni comunicano con il driver Spark tramite gRPC, e il driver esegue le query per conto del client anziché eseguire direttamente i processi utente. Questo sposta l'unità di esecuzione dai processi applicativi alle query e consente una netta separazione tra le applicazioni utente e l'infrastruttura.

Questo disaccoppiamento migliora significativamente l'affidabilità e consente alla piattaforma di gestire i driver indipendentemente dai carichi di lavoro degli utenti. Isolando le applicazioni dal calcolo, Spark Connect crea le basi necessarie per un'esecuzione multi-tenant stabile e consente una gestione delle risorse più avanzata in tutto il sistema.

Questa architettura consente a Databricks di fornire oltre 25 aggiornamenti principali del runtime di Spark all'anno con un tasso di successo del 99,998% su oltre 4,5 miliardi di carichi di lavoro, senza alcuna azione richiesta dall'utente.¹

Il Gateway: Bilanciare efficienza e prevedibilità

I sistemi distribuiti hanno a lungo affrontato una tensione fondamentale tra efficienza e prevedibilità. Massimizzare l'utilizzo spesso porta a contese di risorse, mentre l'isolamento dei carichi di lavoro può comportare una capacità sottoutilizzata. I modelli di cluster tradizionali costringono gli utenti a gestire manualmente questo compromesso, spesso con conseguenti prestazioni imprevedibili o un'esecuzione inaffidabile al variare dei carichi di lavoro.

Consideriamo cosa succede quando decine di query arrivano contemporaneamente: alcune piccole scansioni esplorative eseguite su dati campione, altre grandi processi ETL di produzione che elaborano centinaia di gigabyte. Un router ingenuo le tratta in modo identico, costringendo i lavori di grandi dimensioni ad attendere dietro quelli piccoli o lasciando che i carichi di lavoro competano per lo stesso cluster, portando a un degrado imprevedibile delle prestazioni. Questa dinamica rende difficile fornire sia un'elevata utilizzazione che prestazioni costanti in ambienti condivisi.

Il gateway Databricks instrada ogni carico di lavoro valutando tre segnali in tempo reale: la dimensione stimata della query (derivata dal piano logico), l'utilizzo corrente del pool di cluster e il profilo di latenza: se una sessione è interattiva e sensibile alla latenza o un job batch ottimizzato per il throughput. Una piccola query esplorativa viene instradata a un cluster poco carico che può rispondere in pochi secondi; un job ETL pesante viene diretto a un cluster con capacità disponibile per il suo volume di dati, oppure viene segnalato all'autoscaler di provisionarne uno. Quando le condizioni cambiano (un cluster si riempie, un job a lunga esecuzione termina, un nuovo cluster diventa online), il gateway rivaluta continuamente i posizionamenti e corregge l'instradamento senza intervento dell'utente. Il risultato: i carichi di lavoro sono isolati l'uno dall'altro. Una query fuori controllo su un cluster non ritarda le query su un altro, e il sistema mantiene un'elevata utilizzazione senza sacrificare la prevedibilità.

Autoscaling: Ottimizzare la curva costo-prestazioni

Il dimensionamento dinamico dei cluster è il meccanismo principale per ottimizzare il rapporto prezzo-prestazioni nei sistemi distribuiti, ma determinare la quantità ottimale di risorse di calcolo è intrinsecamente complesso. La configurazione ottimale dipende dalle caratteristiche del carico di lavoro, dalla dimensione dei dati e dall'importanza relativa della latenza rispetto al costo, senza che una singola configurazione funzioni in tutti gli scenari. Databricks serverless offre due modalità per soddisfare diverse esigenze: Standard, che utilizza meno risorse di calcolo per ridurre i costi, e Performance-Optimized, che offre avvio ed esecuzione più rapidi per i carichi di lavoro sensibili al tempo.

L'avvio è una priorità per noi, e i Notebook e i Workflow serverless hanno fatto un'enorme differenza. Il calcolo serverless per i notebook lo rende facile con un solo clic. — Chiranjeevi Katta, Data Engineer presso Airbus

Databricks ci ha aiutato a passare al calcolo serverless, eliminando al contempo i flussi di lavoro ridondanti. Queste efficienze ci hanno permesso di ridurre i costi operativi del 25%. Le pipeline sulla nostra infrastruttura legacy impiegavano ore per essere elaborate. Ora, vengono eseguite da 2 a 5 volte più velocemente. — Evan Cherney, Senior Data Science Manager presso Unilever

Gli approcci tradizionali all'autoscaling si basano su regole statiche e soglie reattive, che spesso non riescono a cogliere queste sfumature. Di conseguenza, i cluster sono frequentemente sottodimensionati o sovradimensionati, portando a inefficienza, instabilità o entrambi.

L'autoscaling serverless adotta un approccio più adattivo. Analizzando continuamente i modelli di carico di lavoro e i segnali a livello di sistema, l'autoscaler posiziona ogni carico di lavoro sulla curva costo-prestazioni ottimale, dove la maggior parte dei cluster configurati manualmente fallisce, offrendo prestazioni peggiori e costi più elevati a causa della difficoltà di dimensionare correttamente i sistemi distribuiti. Regola dinamicamente la capacità di calcolo scalando orizzontalmente e verticalmente secondo necessità, prevenendo errori di memoria insufficiente e mantenendo la stabilità man mano che i carichi di lavoro aumentano. Quando un'attività incontra un errore di memoria insufficiente, l'autoscaler lo rileva automaticamente, riavvia l'attività su una VM più grande e continua il lavoro senza alcun intervento manuale o fallimento del job richiesto.

L'impatto è misurabile. CKDelta ha riportato job completati in 20 minuti che in precedenza duravano 4-5 ore. Unilever ha visto pipeline eseguite 2-5 volte più velocemente con costi operativi ridotti del 25%. HP ha realizzato risparmi sul cloud di oltre il 32% e ridotto il tempo di esecuzione combinato dei job del 36%.

Insieme, Spark Connect, il gateway e l'autoscaler abilitano un modello operativo fondamentalmente diverso per Spark. I carichi di lavoro sono isolati, posizionati in modo intelligente e dotati di risorse dinamiche senza intervento dell'utente. Affrontando la stabilità a livello architettonico, il calcolo serverless può offrire prestazioni elevate mantenendo l'affidabilità, consentendo agli utenti di concentrarsi sulla creazione di carichi di lavoro di dati e AI anziché sulla gestione dell'infrastruttura.

¹ Justin Breese et al., "Blink Twice: Automatic Workload Pinning and Regression Detection for Versionless Apache Spark using Retries," SIGMOD/PODS '25, pp. 103–106. https://doi.org/10.1145/3722212.3725084

Inizia oggi il tuo percorso serverless

• Iscriviti a un account Serverless Databricks
• Compute Serverless per Notebook, Lakeflow Jobs e Pipeline Dichiarative Spark
• Guida Pratica alla Compute Serverless

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