Il ruolo chiave di Presto in Meta: ecco cosa abbiamo imparato

Presto è un motore di query SQL open source gratuito. Noi di Meta lo utilizziamo ormai da dieci anni e in questo periodo abbiamo imparato molto. Un'esecuzione su vasta scala, indipendentemente che si tratti di strumenti, processi o servizi, implica spesso sfide impreviste per le quali è necessaria una buona capacità di risoluzione dei problemi. Ecco quattro cose che abbiamo imparato durante l'integrazione di Presto a livello aziendale e alcuni consigli utili per la gestione delle query su larga scala.

Scalabilità vs esigenze crescenti: le sfide superate

Implementazione delle nuove versioni di Presto

Figura 1: Flusso di lavoro del processo di implementazione delle nuove versioni di Presto (schema di Philip S. Bell)

Meta esegue un elevato numero di cluster Presto su data center sparsi in tutto il mondo. Almeno una volta al mese, a volte anche due, viene creata e rilasciata una nuova versione di Presto. Una delle prime sfide che abbiamo dovuto affrontare con la rapida crescita di Presto in Meta è stata la distribuzione del motore di query su un volume elevato di cluster, dovendo al contempo garantire disponibilità e affidabilità costanti. Questo vale ancora oggi soprattutto per i casi d'uso interattivi di Presto, ovvero gli scenari in cui un utente lancia una query ed è attivamente in attesa di un risultato. La mancata riuscita di una query è meno preoccupante per i casi d'uso "batch" automatizzati in cui i ripetuti tentativi automatici assicurano che la query alla fine abbia esito positivo.

La soluzione era piuttosto semplice. Tutti i cluster Presto si basano su un sistema di bilanciamento del carico chiamato Gateway, che è responsabile (insieme ad altri sistemi in Meta) dell'instradamento delle query Presto al cluster corretto. Quando è disponibile un aggiornamento per un cluster Presto, questo viene innanzitutto contrassegnato come svincolato dalla coda del Gateway, in altre parole il Gateway interrompe l'instradamento di qualsiasi nuova query verso il cluster. L'automazione attende quindi un intervallo di tempo predeterminato per consentire il completamento delle query attualmente in esecuzione sul cluster. A questo punto il cluster viene aggiornato e, una volta online, viene reso visibile al Gateway, che può iniziare a indirizzargli nuove query.

L'altro aspetto dell'implementazione delle nuove versioni di Presto è la disponibilità. Dobbiamo assicurarci che gli utenti possano continuare a utilizzare Presto mentre i cluster vengono aggiornati. Anche in questo caso, l'automazione garantisce che ogni data center, qualsiasi sia la sua ubicazione, disponga sempre del numero necessario di cluster Presto disponibili. Naturalmente, è necessario trovare il giusto compromesso per non rischiare di disattivare contemporaneamente troppi cluster (creando un problema di disponibilità) o troppo pochi (allungando i tempi di implementazione).

Integrazione e rimozione automatizzate dei cluster Presto

Figura 2: Flusso di lavoro automatizzato per l'aggiunta di hardware ai cluster (schema di Philip S. Bell)

La distribuzione del data warehouse di Meta nelle diverse aree geografiche è in continua evoluzione. Ciò significa che periodicamente nuovi cluster Presto vengo integrati mentre quelli esistenti vengono rimossi. In precedenza, quando il numero ridotto di cluster Presto era contenuto, questi processi si svolgevano manualmente. Con la rapida crescita di Presto in Meta, riuscire a tenere traccia di tutte le modifiche in modo manuale stava diventando sempre più difficile. Per risolvere questo problema, abbiamo implementato delle soluzioni di automazione per gestire l'integrazione e la rimozione dei cluster.

Come prima cosa abbiamo dovuto standardizzare le nostre configurazioni cluster, questo significa che abbiamo sviluppato delle configurazioni di base per i diversi casi d'uso Presto in Meta. Ogni cluster aveva un numero minimo di specifiche aggiuntive o sovrascritte rispetto alla configurazione di base. In questo modo, tutti i nuovi cluster potevano essere attivati generando configurazioni automatiche a partire dal modello di base. L'attivazione dei cluster ha però richiesto l'impiego di hook per l'automazione che consentissero l'integrazione con i diversi servizi di infrastruttura a livello aziendale, come Tupperware, e i servizi specifici per data warehouse. Una volta che un cluster è online, si procede all'invio di alcune query di test affinché l'automazione ne verifichi la corretta esecuzione. Il cluster viene quindi registrato sul Gateway e inizia a processare query.

La procedura di rimozione di un cluster segue pressoché il processo inverso. La registrazione sul Gateway viene annullata e si attende il completamento di eventuali query in esecuzione. A questo punto, i processi di Presto vengono arrestati e le configurazioni del cluster eliminate.

Questa automazione fa parte del flusso di lavoro di integrazione e rimozione hardware per il data warehouse. Il risultato finale è che l'intero processo è completamente automatizzato: dall'inserimento del nuovo hardware nel data center alla disponibilità online dei cluster Presto e l'avvio dell'elaborazione di query fino alla rimozione al momento della disattivazione dell'hardware. L'implementazione di questa soluzione ha consentito di risparmiare ore di lavoro preziose, tagliare i tempi di inattività dell'hardware e ridurre al minimo l'errore umano.

Debug automatico e correzioni

Figura 3: Rilevamento di host inefficaci (schema di Philip S. Bell)

Data l'ampia distribuzione di Presto in Meta, è fondamentale disporre di strumenti e soluzioni di automazione che semplifichino il lavoro del team di assistenza (il punto di contatto per Presto).

Nel corso degli anni, abbiamo creato diversi "analizzatori" pensati per aiutare il team di assistenza a eseguire il debug e valutare la causa principale dei problemi che emergono in modo efficiente. I sistemi di monitoraggio generano degli avvisi in caso di violazione degli SLA rivolti ai clienti, che attivano gli analizzatori. Questi ottengono informazioni da un'ampia gamma di sistemi di monitoraggio (Operational Data Store o ODS), dagli eventi pubblicati su Scuba e persino dai registri a livello di host. La logica personalizzata nell'analizzatore collega quindi tutte queste informazioni e deduce la probabile causa principale. Questo è estremamente utile per il team di assistenza, che riceve l'analisi della causa principale ed è quindi in grado di passare direttamente alle potenziali opzioni di mitigazione. In alcuni casi, abbiamo completamente automatizzato sia il debug che la correzione, in modo che il team di assistenza non debba nemmeno essere coinvolto. Di seguito riportiamo alcuni esempi:

Rilevamento di host inefficaci

Eseguendo Presto su larga scala su un elevato numero di macchine, abbiamo notato che alcuni host "inefficaci" compromettevano troppo spesso la buona riuscita delle query. Dopo aver indagato, abbiamo identificato alcune delle cause principali dell'inefficacia di quegli host, tra cui:

• Problemi a livello di hardware che non erano ancora stati rilevati dai sistemi di monitoraggio dei cluster a causa della mancanza di copertura
• Bug JVM nascosti che in alcune circostanze causavano una serie prolungata di errori di query

Per contrastare questo problema, ora monitoriamo gli errori di query nei cluster Presto. In particolare, se possibile attribuiamo ciascun errore di query all'host che l'ha provocato. Inoltre, abbiamo previsto l'attivazione di una serie di avvisi in caso di attribuzione di un numero stranamente elevato di errori di query a host specifici. È qui che entra in gioco l'automazione, per svincolare l'host dai cluster Presto e arginare gli errori.

Risoluzione dei problemi di accodamento

Ogni cluster Presto supporta l'accodamento delle query una volta raggiunta la massima concorrenza per l'esecuzione delle query in base al caso d'uso, alla configurazione hardware e alle dimensioni delle query. In Meta, ci avvaliamo di un sofisticato meccanismo di instradamento volto a garantire che ogni query Presto venga inviata al cluster corretto, in grado di eseguire quella query sfruttando al meglio le risorse. Diversi sistemi oltre a Presto sono coinvolti nella decisione di instradamento tenendo conto di molteplici fattori:

• Stato corrente dell'accodamento sui cluster Presto
• Distribuzione hardware su diversi data center
• Ubicazione dei dati delle tabella di cui si avvale la query

Considerato questo livello di complessità, può risultare molto difficile per il team di assistenza individuare la causa principale di eventuali problemi di accodamento riscontrati in produzione. Questo è un altro caso in cui subentrano gli analizzatori, estraendo informazioni da più fonti e presentando conclusioni.

Affidabilità del sistema di bilanciamento del carico

Figura 4: Affidabilità del sistema di bilanciamento del carico (schema di Philip S. Bell)

Come già spiegato, i nostri cluster Presto si basano su sistemi di bilanciamento del carico che indirizzano ogni singola query Presto in Meta. All'inizio, quando il livello di utilizzo interno di Presto non era ancora paragonabile a quello odierno, il funzionamento del Gateway era piuttosto semplice. Tuttavia, poiché l'utilizzo di Presto è aumentato in Meta, in un paio di occasioni ci siamo imbattuti in problemi di scalabilità. Uno di questi era il cedimento del Gateway sotto carico pesante, che in alcuni casi rendeva Presto non disponibile per tutti gli utenti. La causa principale dei problemi di stabilità è risultata essere un servizio che, involontariamente, bombardava il Gateway con milioni di query in un breve lasso di tempo, provocandone l'arresto anomalo dei processi e l'impossibilità di instradare query.

Per prevenire questo scenario, abbiamo deciso di rendere il Gateway più solido e affidabile anche in caso di traffico indesiderato in stile DDoS. A questo scopo abbiamo implementato una funzione di throttling, che rifiuta le query in caso di carico pesante. Il throttling può essere attivato in base al numero di query al secondo su varie dimensioni, ad esempio per utente, per origine, per IP e anche a livello globale per tutte le query. Un altro miglioramento che abbiamo implementato è stato l'autoscalabilità. Appoggiandosi a un servizio Meta che supporta la procedura di aumento e riduzione dei volumi di attività, il numero di istanze del Gateway è ora dinamico. Ciò significa che, in condizioni di carico elevato, il Gateway è ora in grado di garantire la scalabilità per gestire il traffico aggiuntivo senza raggiungere il limite massimo di CPU/memoria, prevenendo così lo scenario di arresto anomalo di cui abbiamo parlato. Questo, in combinazione con la funzione di throttling, assicura che il Gateway sia affidabile e che possa resistere ad andamenti di traffico imprevedibili e di difficile gestione.

Ecco i nostri consigli per un team che vuole aumentare i volumi del proprio data lakehouse con Presto

Figura 5: Scalabilità dell'architettura di Presto (schema di Philip S. Bell)

Di seguito illustriamo alcuni degli aspetti importanti da tenere in mente in relazione alla scalabilità di Presto:

1. Stabilire SLA di facile comprensione e ben definiti rivolti al cliente. Definire gli SLA in base a metriche rilevanti, come il tempo di accodamento e il tasso di errore delle query, in modo da tenere traccia dei punti deboli dei clienti diventa cruciale man mano che il grado di integrazione di Presto aumenta. Quando il numero di utenti è elevato, la mancanza di SLA adeguati può ostacolare notevolmente gli sforzi volti a mitigare i problemi di produzione a causa della confusione nel determinare l'impatto di un incidente.
2. Monitoraggio e debug automatizzato. Con la crescita di Presto e l'aumento del numero di cluster, il monitoraggio e il debug automatizzato diventano fondamentali.
   • Fare affidamento su un sistema di monitoraggio approfondito può aiutare a identificare i problemi di produzione prima che diventino ingestibili. Individuando tempestivamente i problemi sarà possibile ridurre al minimo l'impatto sugli utenti dove possibile.
   • Lo svolgimento manuale delle indagini di fronte a problemi di produzione che incidono sui clienti non è un approccio scalabile. È indispensabile disporre di un sistema di debug automatizzato che consenta di determinare rapidamente la causa principale.
3. Bilanciamo del carico efficace. Man mano che il numero di cluster Presto cresce, è importante poter fare affidamento su una buona soluzione di bilanciamento del carico. Su larga scala, piccole inefficienze nel bilanciamento del carico possono avere un impatto negativo enorme a causa dell'elevatissimo volume del carico di lavoro.
4. Gestione della configurazione. La gestione della configurazione di un numero considerevole di cluster Presto può diventare una seccatura se non è ben pianificata. Quando possibile, le configurazioni devono essere ricaricabili nell'immediato, in modo che le istanze Presto non debbano essere riavviate o aggiornate con conseguenti errori di query e insoddisfazione del cliente.

Questo articolo è stato scritto in collaborazione con Neerad Somanchi, Production Engineer di Meta, e Philip Bell, Developer Advocate di Meta.

Per maggiori informazioni su Presto, visita prestodb.io, guarda la breve presentazione di Presto di Philip Bell su YouTube o segui Presto su Twitter, Facebook e LinkedIn.

Per maggiori informazioni su Meta Open Source, visita il nostro sito open source, iscriviti al nostro canale YouTube o seguici su Twitter, Facebook e LinkedIn.