Foto di Rob Wicks su Unsplash
Premessa
Le edizioni di BigQuery hanno introdotto nuovi modelli di pricing e aggiornamenti rilevanti a quelli già esistenti.
Noi di DoiT affianchiamo molti clienti nella progettazione di sistemi well-architected, nell'uso efficiente dei servizi cloud e nell'ottimizzazione dei costi. Dopo le novità di BigQuery, diversi clienti ci hanno contattato per ridurre i costi di calcolo e valutare il passaggio da 'On demand' al nuovo modello di pricing 'Standard Edition'.
Di seguito troverà i passaggi per stabilire se la transizione è davvero conveniente e come eseguirla e monitorarla.
Il codice SQL citato nel post richiede l'accesso a queste INFORMATION_SCHEMA views: JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECT.
Prerequisiti per l'accesso alle tabelle: roles/bigquery.resourceViewer (a livello di progetto)
Il cuore della reservation Standard Edition
La Standard Edition, un'offerta compute-based (Slot hours), si distingue dalle altre opzioni di pricing compute-based perché è basata sul progetto (analogamente alla On-Demand) e non sull'intera organizzazione.
Il vantaggio principale è l'accesso all'autoscaling a basso costo e senza alcun commitment: "BigQuery regola dinamicamente gli slot in funzione dell'aumento o della diminuzione dei workloads." (Introduction to slots autoscaling)
Le differenze principali tra On-Demand e Standard Edition sono:
1. Unità di pricing: On-Demand fattura in base ai dati scansionati, mentre la Standard Edition adotta un modello slot/ora.
2. Disponibilità degli slot: con On-Demand gli slot sono "hot" e immediatamente disponibili; nella Standard Edition, invece, l'AutoScaler individua la capacità di slot necessaria per i job di query prima di assegnarli (con un ritardo di circa 10 secondi), con un impatto sulla latenza delle query.
3. Numero massimo di slot disponibili: 2000 per On-Demand, 1600 per la Standard Edition.
\[1\] Checklist di funzionalità e limitazioni della Standard Edition
Il primo passo è verificare la compatibilità del progetto con la Standard Edition. Esamini con attenzione l'elenco delle funzionalità riportato e si assicuri di averne compreso potenzialità e limiti:
Un confronto completo e dettagliato è disponibile qui: BigQuery editions features.
\[2\] Analizzare l'utilizzo dei workloads
Esaminate funzionalità e limitazioni, il passo successivo consiste nello stimare i costi a seconda che il progetto sia orientato all'I/O o alla CPU (Slot). Nella view INFORMATION_SCHEMA.JOBS questi dati si recuperano da total_bytes_billed (I/O) e total_slot_ms (CPU).
L'obiettivo è confrontare la spesa per i dati scansionati con quella stimata per l'utilizzo degli slot. Calcolare la spesa basata sull'I/O è piuttosto semplice, perché coincide con la somma dei costi di tutte le query. La stima della spesa basata sugli slot, invece, risulta leggermente sottostimata perché non tiene conto del comportamento dell'autoscaler (bucket da 100 slot e downscaling solo dopo un minuto minimo). Per compensare questa discrepanza applicheremo un moltiplicatore di 1,5 alla stima slot-based.
La tabella seguente confronta i costi mensili tramite il rapporto tra costo Slot e On-demand, indicando la variazione di costo stimata nel passaggio da On-demand a Standard Edition.
Un valore inferiore a 100 indica una potenziale riduzione dei costi; un valore superiore a 100 segnala un possibile aumento.
Ad esempio:
Spesa mensile del cliente — On-demand è più costoso
Spesa mensile del cliente — On-demand è più conveniente
Codice per generare la tabella precedente: BigQuery OnDemand vs. SE.sql
Poiché la Standard Edition offre meno funzionalità rispetto all'edizione On-demand, se il rapporto resta in genere sopra il 75% conviene mantenere l'opzione On-demand: il risparmio atteso sarebbe minimo e si rinuncerebbe ad alcune funzionalità.
\[3\] Configurazione del numero massimo di slot
La Standard Edition richiede un'unica configurazione, quella del numero massimo di slot, che funge da limite superiore per l'AutoScaling.
Come si individua la configurazione più adatta?
Purtroppo non esiste una soluzione valida per tutti: il parametro andrà probabilmente affinato dopo la configurazione iniziale, in base al pattern dei suoi workloads e a come desidera bilanciare costi e prestazioni.
Un metodo per calcolare un valore di partenza è la formula seguente:
Identifichi l'ora del 90° percentile, nel periodo selezionato, in cui l'utilizzo degli slot ha superato 100 (configurazione di base) e arrotondi al multiplo di 100 superiore.
Configurazione massima basata sull'ora P90 nel periodo selezionato
Snippet di codice di esempio per determinare la configurazione massima iniziale: BQ SE max configuration.sql
Creazione della reservation
Una guida dettagliata passo passo per creare una reservation è disponibile qui: Get started with reservations.
Selezioni Standard Edition, imposti il valore 'max Slots' e scelga la region o multi-region appropriata: in caso contrario la reservation non funzionerà correttamente.
\[4\] Monitoraggio delle prestazioni e valutazione dei costi
Impatto sulle prestazioni
Per monitorare le prestazioni della sua applicazione, raccolga metriche come i tempi di elaborazione dei job e i tempi di risposta delle query ad-hoc prima della migrazione e li confronti con i risultati post-migrazione. È buona prassi informare gli utenti di BigQuery sui cambiamenti previsti e raccoglierne il feedback.
Può valutare le prestazioni dal punto di vista del sistema facendo riferimento agli Administrative resource charts, di cui parleremo nella prossima sezione.
Vantaggi economici
Per valutare la convenienza economica analizzi le spese tramite il dashboard di fatturazione giornaliera. Selezioni la SKU Analysis e Standard Edition nella sezione di fatturazione.
La tabella seguente somma, in un intervallo di un'ora, l'allocazione totale degli slot e i costi stimati. Da queste informazioni può ricavare un calcolo approssimativo del costo effettivo basato sulle azioni dell'autoscaler.
Snippet di codice di esempio: Standard Edition cost estimation.sql
Distribuzione stimata dei costi per ora
\[5\] Tuning
Il tuning della Standard Edition consiste nel modificare la configurazione del numero massimo di slot per migliorare le prestazioni (aumentando gli slot) o ridurre la spesa (diminuendoli). L'obiettivo è un sistema ben bilanciato, in cui le risorse non siano né sottoutilizzate né sovradimensionate.
Monitorare l'efficienza dei workloads le mostrerà se il sistema è bilanciato, sottoutilizzato o sovradimensionato. Può farlo osservando gli Administrative resource charts oppure interrogando direttamente le INFORMATION_SCHMEA views.
Administrative resource charts:
Gli amministratori di BigQuery monitorano nel tempo l'utilizzo degli Slot della propria organizzazione e le prestazioni dei job BigQuery. Questi grafici si trovano nella sezione 'Monitoring' della sidebar di BigQuery, che offre diverse viste per rispondere a esigenze differenti. Per familiarizzare con queste funzionalità, consulti la guida sugli administrative resource charts.
- Analisi dell'utilizzo degli slot: usi la metrica P90 o P99 per esaminare il rapporto tra utilizzo e allocazione degli slot (che include "baseline + Autoscaled slots") e il tempo necessario per lo scaling up o down.
Utilizzo degli slot
Il grafico precedente utilizza i dati della view RESERVATION_CHANGES_BY_PROJECT, che contiene informazioni sulle modifiche alle reservation.
La tabella seguente mostra l'allocazione degli slot e il tempo che intercorre fino al successivo cambiamento (scaling up o down). La metrica 'allocated_slots' indica la quantità di slot assegnati in un dato momento fino al successivo 'UPDATE', mentre 'Estimated total slots' rappresenta l'allocazione complessiva nell'intero periodo.
Snippet di codice di esempio: Monitor BQ edition autoscaling.sql
Allocazioni effettive degli slot con relativa durata
- Concorrenza dei job: per individuare i colli di bottiglia del sistema, osservi la metrica 'pending jobs'.
Job in attesa
- Prestazioni dei job: tenga sotto controllo i job con latenza elevata utilizzando la misura del 90° percentile (P90).
Latenza dei job
Sintesi e raccomandazioni
In presenza di burst o picchi di utilizzo possono esserci approcci più adatti di questo, che richiedono un'analisi più approfondita. Anche in questi casi, però, gli strumenti descritti offrono indicazioni preziose nel corso dell'analisi.
La transizione dipende soprattutto dal tipo di utilizzo nei singoli progetti: orientato all'I/O (che rende 'On-demand' più costoso) oppure alla CPU (che fa lievitare il costo della 'Standard Edition').
Google consiglia la Standard Edition soprattutto per i progetti di ricerca e sviluppo: "Ad esempio, la Standard Edition è ideale per workloads ad-hoc, di sviluppo e di testing."
Poiché l'espressione 'workload di produzione' può assumere significati diversi a seconda del cliente, alcuni potrebbero valutare l'uso della Standard Edition anche per workloads di produzione ETL/ELT. Una scelta accettabile a patto che si rispettino i limiti dell'edizione (in particolare l'SLA del 99,9%), il carico resti stabile nel tempo e nessun utente finale abbia preoccupazioni sulla latenza delle query.
Ora che conosce il processo, lo metta in pratica e ci faccia sapere com'è andata.