BigQuery Autoscaling in Public Preview: la guida firmata DoiT

Ecco una rapida panoramica dei termini utilizzati nell'articolo. Se conosce già BigQuery, la maggior parte le sarà familiare; in caso contrario, questa sezione le tornerà utile prima di proseguire.

• Job Un job è un'azione eseguita su BigQuery per svolgere un'attività: esecuzione di query, caricamento o copia di dati e così via. Il tipo di job più comune è la query, e i due termini vengono spesso usati come sinonimi.
• Slot L'unità di calcolo di base che BigQuery impiega per eseguire un job. La si può immaginare come una "mini macchina virtuale" che, insieme a molte altre, svolge il lavoro effettivo per un job.
• Reservation Un costrutto che riserva un insieme di slot da utilizzare per zero o più progetti associati alla reservation stessa.
• Commitment Un numero fisso di slot riservati per una durata stabilita, in genere un mese o un anno, in cambio di un prezzo più vantaggioso.
• Admin Project Un progetto designato come "manager" delle reservations e dei commitments di BigQuery. In genere un'organizzazione ne ha uno solo (o pochi selezionati) per garantire un "single pane-of-glass" nella gestione delle risorse BigQuery. Per i progetti flat-rate e autoscaling, le SKU di fatturazione delle reservations dell'intera organizzazione vengono associate a questo progetto.
• Flex Slots Slot che possono essere aggiunti a una reservation per gestire picchi di breve durata nel numero di slot. Vengono fatturati al secondo, con un periodo minimo di fatturazione di 60 secondi.
• Idle Slot Uno slot che al momento non è impiegato in alcun job.
• Workloads Un workload è un insieme di job eseguiti all'interno di un singolo progetto.
• Slot/Ora La metrica di fatturazione di base per i progetti BigQuery Autoscaling. Corrisponde all'utilizzo di un singolo slot in un job per un'ora.
• Autoscaling Slots Nuovo costrutto che scala il numero di slot da un valore baseline fino a un valore massimo, in base alle esigenze del workload in esecuzione.
• Baseline Slots Il numero minimo di slot mantenuti "caldi" e attivi in un progetto BigQuery Autoscaling. Sono i primi a essere utilizzati prima che si attivi l'autoscaling e vengono fatturati per tutta la durata della reservation.

Google ha appena rilasciato in public preview una funzionalità attesa da tempo: l'autoscaling degli slot di BigQuery, pensato per i casi in cui i workloads richiedono più slot di quelli previsti dalla capacità acquistata.

In sintesi, consente a BigQuery di scalare automaticamente, verso l'alto e verso il basso, gli slot necessari ai workloads, senza alcun intervento manuale, come una Cloud Function che modifica una reservation di Flex Slots al raggiungimento di determinate soglie di utilizzo.

Dato che il modello di fatturazione di BigQuery ha ormai più di 10 anni e si basa essenzialmente sui paradigmi "pay-for-data-scanned" e "pay-for-capacity", non si sposa bene con l'autoscaling della capacità di calcolo. Per ovviare a questo limite, Google ha introdotto un modello di fatturazione più moderno, basato sull'approccio "pay-for-what-you-use", a supporto della nuova funzionalità.

Questa funzionalità è esattamente ciò che il nome suggerisce: autoscaling degli slot. In altre parole, quando un workload necessita di slot aggiuntivi, BigQuery scala automaticamente, verso l'alto o verso il basso, il numero di slot all'interno della reservation in base alle esigenze dei job in esecuzione.

Ad accompagnarla, come anticipato, c'è un nuovo modello di fatturazione basato su un costrutto chiamato "slot/ora", ovvero il prezzo per l'utilizzo di un singolo slot per un'ora, fatturato al secondo.

* Si noti che la modifica riguarda solo il lato compute/analisi di BigQuery, non i costi di storage. Lo storage non è in alcun modo interessato da questi cambiamenti. Lo tenga presente proseguendo nella lettura.

Si tratta di una novità estremamente potente per chi utilizza la fatturazione flat-rate e ha bisogno di più slot di quelli riservati. I Flex Slots offrivano già un modo per ottenere slot aggiuntivi, ma non in modo automatico: richiedevano strumenti aggiuntivi, di solito una Cloud Function eseguita a intervalli regolari, che monitorava la metrica degli slot in uso e aggiungeva o rimuoveva Flex Slots da una reservation in base alle necessità. Un buon esempio è disponibile qui (non affiliato con DoiT). Purtroppo, in caso di necessità immediata di più slot, non c'era modo di farlo, se non costruendo e pagando un'infrastruttura aggiuntiva.

Prima di entrare nel dettaglio, si tenga presente che questo nuovo modello di fatturazione può essere applicato a una singola reservation contenente zero o più progetti. Ciò significa che è possibile combinare on-demand, flat-rate e autoscaling come si preferisce tra reservations e progetti, per ottimizzare utilizzo o costi.

In pratica, quando un progetto ha un valore baseline impostato, tutti i job iniziano utilizzando il numero di slot baseline e cominciano a scalare una volta esauriti. Si tratta di un pool di slot condiviso tra tutti i job in esecuzione nei progetti all'interno di una reservation, esattamente come in una reservation flat-rate. Quando non vengono più utilizzati, gli slot vengono ridotti automaticamente, evitando addebiti inutili: è qui che la differenza con i Flex Slots diventa evidente, visto che questi ultimi vengono fatturati fino alla loro rimozione.

Detto ciò, esiste una finestra di 60 secondi durante la quale BigQuery decide come scalare. Questo evita che query di breve durata facciano salire il numero di slot fino al massimo, generando addebiti eccessivi per slot che non sarebbero serviti.

Come accade fin troppo spesso nel mondo del cloud, la risposta è: dipende. Una risposta poco soddisfacente, quindi entriamo nel merito e vediamo alcuni scenari in cui questo nuovo modello di autoscaling risulta ideale.

Supponiamo di avere un workload eseguito solo poche volte al giorno per un breve periodo, ma che impiega un numero enorme di slot (qualche migliaio). I Flex Slots possono essere usati in questo scenario, ma spesso il job termina in meno di un minuto, quindi si finisce per pagare in eccesso il periodo minimo di fatturazione di 60 secondi dei Flex Slots, anche quando non vengono utilizzati per tutto quel tempo.

Se invece i workloads utilizzano grandi quantità di slot (oltre 2k, ovvero il numero di slot on-demand) e sono molto read-heavy, rendendo poco sensata la fatturazione on-demand, allora si tratta di candidati perfetti per l'Autoscaling. In più, spesso questi workloads vengono avviati da un'azione del cliente, quindi non c'è il tempo necessario per creare una reservation di Flex Slots in cui eseguirli.

Infine, se i suoi workloads sono molto irregolari, può confrontarne l'utilizzo di slot nel nostro calcolatore degli Autoscaling Slots di BigQuery con la sua configurazione attuale e verificare se la nuova soluzione è più adatta.

Le reservations in questo nuovo modello di autoscaling sono in gran parte simili alle precedenti reservations flat-rate, ma introducono qualche concetto nuovo e qualche differenza.

Vengono ancora create all'interno di un management project, e all'interno di ciascuna reservation ci sono zero o più progetti a cui sono allocati gli slot da utilizzare.

Poiché viene introdotto il concetto di scaling, ora esistono un valore minimo di scaling, chiamato "Baseline Slots", e un valore massimo, chiamato "maximum reservation size" o "max slots".

Il valore max slots è dato dalla somma del valore Baseline Slots e del numero di slot in autoscaling impostati per l'intera reservation.

Per impostazione predefinita, se un job, o un insieme di job, supera il limite massimo di autoscaling della propria reservation, può prendere in prestito slot da altre reservations dello stesso management project. Una checkbox chiamata "Ignore idle slots" permette di disattivare questa funzionalità nella schermata "Create Reservation":

I prezzi sono completamente diversi rispetto ai modelli tariffari tradizionali adottati finora da BigQuery. Il nuovo modello si basa su un concetto chiamato slot/ora, ovvero un addebito per slot per un'ora di utilizzo, fatturato al secondo.

L'Autoscaling fattura l'utilizzo in base al tempo di impiego di uno slot. La fatturazione avviene al secondo, ma l'ora viene utilizzata come comodo punto di arrotondamento. Quindi, se utilizza un singolo slot per 900 secondi (un quarto d'ora in secondi), le verranno addebitati 0,25 slot/ora. Per 3.600 secondi (1 ora in secondi) le verrà addebitato 1,0 slot/ora. Verosimilmente userà più di un singolo slot per un job, quindi moltiplicando per il numero di slot utilizzati otterrà il totale degli slot/ora fatturati.

Il tassello mancante per determinare il prezzo è il costo per slot/ora che, per la public preview, è fissato a $0,06 USD per slot/ora. Questo valore potrebbe variare, trattandosi di una funzionalità in preview.

La formula complessiva per determinare il costo di un job è dunque:

Prezzo = 0,06 * (<Slot utilizzati> * (<Secondi utilizzati>/3600))

Non è la formula più immediata da leggere, ma in sostanza si moltiplicano gli slot utilizzati per le ore di utilizzo (secondi utilizzati / 3.600 secondi). Sembra più complicato di quanto sia.

Per questo abbiamo creato un calcolatore che le permette di determinare e confrontare i prezzi più facilmente. Si noti che è in sola lettura: per usarlo al meglio, ne crei prima una copia nel suo ambiente Workspace.

Trattandosi di una nuova funzionalità Google, sono state introdotte alcune nuove SKU di prezzo, così da poter monitorare la spesa nella DoiT Console (precedentemente Cloud Management Platform o CMP).

I costi slot/ora sono coperti da una SKU con un nome simile a questo:

BigQuery Autoscale Preview for US (multi-region)

L'ID di questa SKU è: B8BE-01DC-0ECF

Gli annual commits (descritti più avanti) sono coperti da una SKU con un nome simile a questo:

BigQuery Autoscale Preview 1 Year for US (multi-region)

L'ID è: C0F6–38AB-6629

La region, o multi-region, varia nei nomi delle SKU, ma il formato resta invariato per tutte le region.

Come per la fatturazione flat-rate, anche l'Autoscaling prevede una funzione di commitment con cui ci si può impegnare a utilizzare un numero fisso di slot, in blocchi da 100, per una durata specificata, in cambio di un prezzo più vantaggioso. Funzionano allo stesso modo dei commitments flat-rate, con la differenza che nell'Autoscaling sono ammessi solo commitments annuali. Sono su base per region o per multi-region, esattamente come nei commitments flat-rate: per ottenere il risparmio è quindi necessario utilizzarli nella specifica region o multi-region in cui sono stati acquistati.

*Si noti che, al momento della sottoscrizione di un commitment, viene addebitato l'intero valore impegnato, esattamente come per un commitment flat-rate. Sono trattati come commitments flat-rate dal punto di vista della fatturazione.

Il prezzo di un commitment annuale è di $0,05 USD per slot/ora, acquistabile in blocchi da 100. Si traduce in circa $3.504 USD al mese per 100 slot, contro circa $4.380 USD al mese per 100 slot eseguiti per un mese intero (assumendo 730 ore al mese) senza commitment.

Il modo più semplice per passare dalla fatturazione flat-rate all'Autoscaling è modificare la reservation da flat-rate ad Autoscaling. Google ha reso il cambio molto immediato e non richiede di eliminare e ricreare le reservations.

Passare da on-demand ad Autoscaling (o flat-rate) è un processo un po' più articolato. Consiglio vivamente di leggere la documentazione di Google sul tema qui prima di procedere, e di seguire poi le procedure per creare una reservation, selezionando però Autoscaling al posto di flat-rate nel menu.

Probabilmente questa è una delle domande più frequenti, perché molti utenti BigQuery non lo sanno. Niente paura, ci pensiamo noi.

In una precedente serie di articoli sull'ottimizzazione dei costi di BigQuery ho pubblicato una raccolta di query BigQuery in un repository GitHub, contenente diverse query utili a questo scopo. Prima di eseguire qualsiasi cosa nel repository, presti attenzione alla quantità di dati scansionati, perché possono elaborare facilmente enormi volumi di dati (>2 TB su alcuni dei nostri dataset interni).

Pur essendo un argomento estremamente vasto e ben oltre lo scopo di questo articolo, le suggerisco di eseguire le seguenti query:

• Slots by Minute Genera una serie temporale sull'intervallo specificato e mostra il numero di slot utilizzati in ciascun minuto.
• Top Complex Queries Restituisce le query più complesse (in questo caso, quelle che hanno utilizzato il maggior numero di slot) nell'intervallo specificato.
• Job Information Restituisce alcune statistiche relative a un Job ID, incluse le informazioni sugli slot. Molto utile quando si rileva che un job presenta problemi di performance e si vuole capire se necessita di slot aggiuntivi per essere eseguito più velocemente.