Controlli dei costi più intelligenti per il serverless

In Databricks, l'utilizzo del nostro compute serverless è cresciuto di oltre 3 volte nell'ultimo anno e migliaia di clienti ora eseguono notebook, job e pipeline mission critical su di esso. Con l'aumento dell'adozione, la domanda che ogni team di piattaforma pone per prima diventa sempre più insistente: come possiamo ottenere una migliore visibilità sui costi del serverless e mantenerli entro il nostro budget?

I clienti Databricks che utilizzano SQL serverless e Model Serving possono già attribuire i costi, gestire l'accesso e monitorare il consumo senza toccare alcun parametro del cluster. Ora stiamo estendendo questa stessa funzionalità al compute serverless per notebook, job e pipeline. Stiamo facendo in modo che i controlli dei costi serverless funzionino esattamente come i team di piattaforma si aspettano.

Il serverless ha spostato il controllo dei costi a un livello superiore

Nel compute classico, il controllo dei costi risiedeva nell'infrastruttura. Potevi limitare la spesa limitando le macchine: conteggio dei nodi, tipi di istanza, intervalli di autoscaling e criteri del cluster che delimitavano ciò che gli utenti potevano allocare. Questi controlli erano necessari perché dovevi gestire l'infrastruttura da solo.

Il serverless rimuove questi parametri, di proposito. Il provisioning, la scalabilità e il dimensionamento dell'infrastruttura sono ora responsabilità della piattaforma, gestita da Databricks, e questo rappresenta gran parte del valore. Tuttavia, il controllo dei costi deve risiedere da qualche parte, quindi si sposta a un livello superiore. Invece di essere associato alle macchine, si collega alle persone e ai carichi di lavoro. Le domande che contano ora sono: chi può eseguire il serverless, a quale velocità un carico di lavoro può spendere e dove vanno a finire i costi.

I team di piattaforma descrivono le loro esigenze in tre modi:

• Spesa fuori controllo: l'esecuzione di un singolo notebook senza limiti può costare migliaia di dollari in un giorno, poiché non esiste alcuna dimensione del cluster o limite di autoscaling a contenerla.
• Le mani sbagliate: il serverless è disponibile per tutti per impostazione predefinita, compresi gli utenti che non dovrebbero effettuarne il provisioning, senza alcun diritto che regoli chi può eseguirlo.
• Nessuna responsabilità: i team non adotteranno il serverless senza l'applicazione dei tag che avevano sul compute classico.

Il compute classico rispondeva a queste esigenze con tre strumenti: tag per attribuire i costi, diritti per controllare l'accesso e limiti alle dimensioni del cluster per limitare la spesa. Il serverless richiede gli stessi tre elementi. Due di essi esistono già e il terzo sta arrivando.

I tre obiettivi del controllo dei costi serverless

1. Attribuire i costi: sapere a quale team, progetto o utente appartiene un DBU serverless.
2. Controllare l'accesso: decidere chi può eseguire il serverless e su cosa.
3. Limitare la spesa: stabilire un limite a quanto o quanto velocemente un carico di lavoro o un team può spendere, prima che avvenga, anziché dopo.

Esamineremo ciascuno di questi punti in ordine.

Attribuire i costi

L'attribuzione inizia con i tag. Nel compute classico si etichettava il cluster; nel serverless si etichetta il compute, e ogni DBU eseguito da quel compute porta con sé quel tag fino alla fatturazione.

• Tag di compute serverless: etichetta un oggetto di compute serverless una sola volta e i carichi di lavoro che vi vengono eseguiti vengono attribuiti al team, al progetto o al centro di costo corretto, senza dover mantenere alcun oggetto di policy separato.
• Tabelle di sistema: ogni DBU serverless finisce in system.billing.usage, suddiviso per utente, per prodotto e per tag. Una vista "costo per team" pronta per la leadership è una singola query, e i dashboard dei costi della console dell'account la visualizzano senza bisogno di scrivere codice SQL.

La stessa tabella risponde alla domanda di controllo che vorrai porti prima di modificare l'accesso di chiunque: chi sta effettivamente eseguendo il serverless oggi e quanto sta spendendo? Questa è un'ulteriore query, ordinata per consumo, e gli esempi completi sono disponibili nella documentazione delle tabelle di sistema.

Disponibilità: I tag di compute serverless per l'attribuzione sono attualmente disponibili in versione Beta.

L'osservabilità è già disponibile e i clienti possono già monitorare i costi del serverless con le tabelle di sistema su AWS, Azure e Google Cloud.

Tieni d'occhio la spesa mentre si evolve: budget, avvisi e dashboard

Le stesse tabelle di sistema che attribuiscono i costi consentono anche di tracciarli. I budget della console dell'account inviano avvisi via email quando la spesa serverless supera una soglia, e i dashboard di gestione dei costi consentono di monitorare i consumi per prodotto, workspace e tag. Un avviso SQL sulla spesa serverless del giorno precedente chiude il cerchio nel giro di poche ore.

Il monitoraggio è tuttavia reattivo: segnala la giornata costosa la mattina successiva anziché prevenirla. Questa lacuna è il motivo per cui esistono i successivi due obiettivi.

Disponibilità: Il monitoraggio è generalmente disponibile da oggi. Configura i budget e gli avvisi di spesa su AWS, Azure e Google Cloud.

Controllare l'accesso

Il primo controllo proattivo consiste nel decidere chi può eseguire il serverless. Tale autorizzazione è un diritto: definisce quali utenti o gruppi possono accedere al serverless, proprio come i diritti esistenti controllano chi può creare cluster o connettersi a un SQL warehouse. I controlli di accesso al compute serverless sono ora generalmente disponibili e consentono di gestire il serverless con quel modello: autorizzazioni su un oggetto di compute, non policy applicate a ogni carico di lavoro.

Un oggetto di compute serverless rappresenta il confine delle autorizzazioni per il serverless. Ogni workspace ne riceve due per impostazione predefinita:

• Compute interattivo serverless predefinito: notebook e Databricks Connect.
• Compute automatizzato serverless predefinito: job e Spark Declarative Pipelines.

Le autorizzazioni su questi oggetti sono le due che già conosci dai warehouse: Can Use e Can Manage. Se sai valutare chi può connettersi a un SQL warehouse, saprai anche valutare chi può eseguire il serverless.

Il modello è sicuro per impostazione predefinita. Ogni utente inizia con Can Use, quindi l'attivazione della funzione non cambia nulla finché un amministratore non interviene. Quando un amministratore interviene, il flusso è quello che ti aspetti: apri la pagina Compute, vai alla scheda Serverless, apri un oggetto di compute predefinito, rimuovi "All Users" e aggiungi un gruppo specifico. Un utente esterno a quel gruppo vedrà ora Serverless disattivato nel selettore del compute del notebook e nessuna esecuzione in corso verrà interrotta.

Disponibilità: Generalmente disponibile oggi. Consulta la documentazione per AWS, Azure e Google Cloud.

Impostare i limiti di spesa

Il controllo degli accesso decide se un carico di lavoro viene eseguito, non quanto può spendere una volta avviato. Colmare questa lacuna è il terzo compito - Rate Limits – e si applica agli stessi oggetti di compute appena visti.

• Limiti di velocità sui carichi di lavoro automatizzati: limiti per compute, espressi come taglie di magliette (S, M, L, XL) che limitano quanto o quanto velocemente un job o una pipeline possono spendere anziché limitarsi a stabilire se possono essere eseguiti. Gli amministratori creeranno oggetti di compute personalizzati e li condivideranno per team, assegnando a ciascun team il proprio limite. Questo è il classico pattern dei criteri del cluster, portato sul serverless.
• Budget condivisi per l'interattivo (in arrivo): un limite per singola sessione da solo non può proteggere il budget di un team, perché molte sessioni "Medium" si accumulano comunque. La nostra direzione è un limite condiviso per il gruppo, con un massimo per sessione come misura di sicurezza sottostante.

Allo stesso tempo, l'attribuzione migliora. Una nuova serverless_compute_id in system.billing.usage attribuisce la spesa per oggetto di calcolo, rendendo il calcolo del costo per oggetto di calcolo semplice quanto il costo per team.

Una precisazione per chi conosce le taglie t-shirt di DBSQL: per i notebook e i processi, la dimensione rappresenta un limite massimo di scalabilità automatica e non una dimensione fissa del cluster. Se scegli XL per un processo che richiede solo Medium, verrà allocato il livello Medium.

Disponibilità: I limiti di frequenza sono ora disponibili in Beta. Abilita i limiti di frequenza tramite le impostazioni di anteprima di Databricks; consulta la documentazione per AWS, Azure e Google Cloud.

Il quadro completo

Ricomponi i tre processi:

• Attribuisci i costi: tag nativi sul calcolo serverless più serverless_compute_id nelle tabelle di sistema, utilizzabili in budget e dashboard.
• Controlla l'accesso: diritti sugli oggetti di calcolo serverless.
• Limita la spesa: limiti di frequenza, condivisi tra un gruppo e limitati per carico di lavoro.

Inizia oggi

Puoi iniziare a implementare i controlli sui costi serverless fin da subito. Ecco come procedere:

1. Attiva l'applicazione dei tag: applica i tag al calcolo serverless in modo che l'attribuzione sia attiva prima di ogni altra cosa.
2. Configura il monitoraggio: aggiungi le dashboard dei costi su system.billing.usage e un avviso di budget sulla spesa serverless.
3. Verifica chi utilizza il serverless oggi: per conoscere l'impatto potenziale prima di modificare l'accesso.
4. Definisci la tua politica di accesso: chi dovrebbe poter eseguire carichi interattivi serverless e chi quelli automatizzati?
5. Attiva i controlli di accesso al calcolo serverless: abilita un calcolo veloce e completamente gestito per i gruppi che preferisci.

I controlli di accesso al calcolo serverless sono ora generalmente disponibili. Per approfondire l'attribuzione e il monitoraggio, puoi consultare la documentazione sulle tabelle di sistema (AWS | Azure| GCP) e sul tagging serverless (AWS | Azure | GCP).

Scopri di più:

• Gestire il calcolo serverless su AWS | Azure | GCP
• Connetti al calcolo serverless | Databricks su AWS
• Connetti al calcolo serverless - Azure Databricks
• Strumenti di gestione dei costi su Databricks - Azure Databricks
• Calcolo serverless su scala petabyte: ultime novità, roadmap e migrazione
• Meno infrastruttura, maggiore impatto: la trasformazione serverless di Nationwide

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