Concetti di scalabilità automatica semplificati per i workload AI/ML in GKE

Questo documento fornisce una panoramica dei concetti di scalabilità automatica per i carichi di lavoro di AI/ML in Google Kubernetes Engine (GKE).

Questo documento è destinato ai machine learning engineer che non hanno mai utilizzato GKE. Ti consigliamo di leggere i seguenti documenti della serie per iniziare a utilizzare GKE per i carichi di lavoro AI/ML:

  1. Perché utilizzare GKE per l'inferenza AI/ML
  2. Informazioni sull'inferenza del modello AI/ML su GKE
  3. Concetti di scalabilità automatica semplificati per i workload AI/ML in GKE (questo documento)

Prima di iniziare

Dovresti avere una familiarità di base con i seguenti concetti:

La sfida: soddisfare la domanda di picco

Cymbal Shops, un rivenditore online fittizio, si sta preparando per l'evento di vendita annuale. Il motore di suggerimenti basato sull'AI del negozio deve fornire suggerimenti personalizzati in tempo reale a un afflusso massiccio di acquirenti online.

Se il motore di raccomandazioni rallenta, l'esperienza utente ne risente e le vendite vanno perse. Tuttavia, il provisioning di una capacità del server eccessiva non è conveniente durante i periodi di traffico normale. L'obiettivo è scalare automaticamente le risorse in risposta alla domanda, garantendo una buona esperienza utente e mantenendo i costi sotto controllo.

La soluzione: scalabilità automatica on demand

La scalabilità automatica di GKE funziona come un responsabile del negozio che si prepara per un aumento delle vendite. Anziché mantenere un edificio enorme con personale e alimentazione sempre attivi, il gestore regola dinamicamente l'intera capacità del negozio (personale, spazio e attrezzature) in base alle esigenze degli acquirenti in un determinato momento.

GKE applica lo stesso principio: scala automaticamente le risorse allocate alla tua applicazione (sia carico di lavoro che infrastruttura) in base alla domanda in tempo reale.

Vantaggi aziendali della scalabilità automatica di GKE

Combinando le strategie di scalabilità orizzontale e verticale, GKE offre un approccio solido che offre tre vantaggi principali:

  • Ottimizzazione dei costi: paghi solo le risorse di calcolo che utilizzi ed eviti la spesa del provisioning eccessivo. La scalabilità automatica di GKE evita gli sprechi ridimensionando automaticamente le applicazioni in base ai requisiti effettivi di CPU e memoria. Può anche eseguire il provisioning di hardware costoso e specializzato (come le GPU) solo per i momenti in cui sono necessari e rimuoverli al termine del job.
  • Affidabilità e prestazioni migliorate: la tua applicazione può scalare automaticamente (aggiungere altre copie) per gestire picchi di traffico improvvisi, garantendo stabilità per i tuoi utenti. Allo stesso tempo, lo scaling automatico di GKE aiuta a prevenire gli errori comuni "Out of Memory " (OOM) che possono causare l'arresto anomalo delle applicazioni. Per i lavori di AI/ML impegnativi, contribuisce a garantire che l'hardware ad alte prestazioni necessario sia disponibile per eseguire in modo efficiente e completare i lavori in tempo.
  • Overhead operativo ridotto: la strategia di scalabilità automatica multidimensionale di GKE semplifica notevolmente la gestione delle risorse. GKE automatizza le attività complesse di ottimizzazione delle richieste di risorse e gestione di pool di nodi specializzati per hardware diversi. Questa automazione consente ai team di ingegneri di concentrarsi sullo sviluppo delle applicazioni anziché sull'ottimizzazione dell'infrastruttura.

Scalabilità automatica del workload

La scalabilità automatica del workload regola automaticamente la potenza della tua applicazione in base alla domanda. GKE utilizza un sistema di scalabilità automatica a due livelli per gestire in modo efficiente le risorse della tua applicazione.

Horizontal Pod Autoscaler (HPA): aggiunta di altre risorse

Horizontal Pod Autoscaler (HPA) monitora l'utilizzo delle risorse dei pod della tua applicazione. Nella nostra analogia, i Pod sono gli "addetti alle vendite" e l'HPA è il "team leader" che osserva il livello di attività degli addetti alle vendite.

Quando la domanda sui pod aumenta, HPA esegue automaticamente il provisioning di altri pod per distribuire il carico. Quando la domanda diminuisce, HPA termina i pod inattivi per risparmiare risorse.

Per saperne di più, consulta Scalabilità automatica orizzontale dei pod.

Vertical Pod Autoscaler (VPA): rendere le risorse più potenti

Mentre la scalabilità orizzontale si concentra sull'aumento della quantità di risorse, la scalabilità verticale è una strategia complementare che si concentra sull'aumento della potenza delle risorse esistenti. Nel contesto della nostra analogia con il negozio fisico, non si tratta di assumere più personale, ma di migliorare le capacità del team attuale per aumentare la sua efficienza individuale.

Questo approccio di scalabilità verticale a livello di pod è gestito da Vertical Pod Autoscaler (VPA). VPA analizza il consumo di risorse della tua applicazione e regola le richieste di CPU e memoria del pod in base al suo utilizzo effettivo.

VPA può regolare le richieste e i limiti di risorse di un pod, ad esempio eseguendo il riprovisioning del pod per scalare da 1 CPU e 16 GB a 4 CPU e 64 GB. Questo processo prevede il riavvio del pod con la sua nuova configurazione più potente per gestire meglio il workload.

Per maggiori informazioni, consulta le seguenti risorse:

HPA e VPA sono complementari. HPA regola il numero di pod in risposta alle variazioni del traffico, mentre VPA contribuisce a garantire che ogni pod abbia le dimensioni corrette per la sua attività. Queste strategie di scalabilità evitano lo spreco di risorse, costi inutili e contribuiscono a garantire che la tua app rimanga reattiva e disponibile durante le fluttuazioni del traffico. Tuttavia, sconsigliamo di utilizzare HPA e VPA sulle stesse metriche (CPU e memoria) perché possono entrare in conflitto. Per saperne di più, consulta Limitazioni della scalabilità automatica orizzontale dei pod.

Scalabilità automatica dell'infrastruttura

La scalabilità automatica dell'infrastruttura aggiunge o rimuove automaticamente l'hardware per soddisfare le esigenze dei carichi di lavoro.

Gestore della scalabilità automatica del cluster: il gestore dell'edificio

Il gestore della scalabilità automatica del cluster contribuisce a garantire che l'infrastruttura sottostante (VM o nodi nel contesto di GKE) sia sufficiente per ospitare i pod. I nodi possono essere paragonati ai "piani" di un negozio, dove il gestore della scalabilità automatica del cluster è il "gestore dell'edificio".

Se HPA deve aggiungere altri pod, ma i nodi esistenti non hanno capacità disponibile, il gestore della scalabilità automatica del cluster esegue il provisioning di un nuovo nodo. Al contrario, se un nodo diventa sottoutilizzato, il gestore della scalabilità automatica del cluster sposta i pod del nodo su altri nodi e termina il nodo ora vuoto.

Per saperne di più, consulta Cluster Autoscaler.

Creazione automatica del node pool: lo specialista dell'automazione

Mentre il gestore della scalabilità automatica dei cluster aggiunge nodi ai pool di nodi esistenti, la creazione automatica dei pool di nodi estende la funzionalità del gestore della scalabilità automatica dei cluster consentendogli di creare automaticamente nuovi pool di nodi che corrispondono alle esigenze specifiche dei tuoi pod.

Alcuni workload di AI/ML richiedono hardware specializzato ad alte prestazioni, come GPU o TPU, che non sono disponibili nei node pool per uso generico. La creazione automatica dei node pool automatizza completamente il provisioning di questo hardware specializzato quando i tuoi carichi di lavoro lo richiedono. In questo modo, anche le attività più intensive dal punto di vista computazionale ricevono l'hardware di cui hanno bisogno, quando ne hanno bisogno.

Per saperne di più, consulta Informazioni sulla creazione automatica di pool di nodi.

Per gli acceleratori disponibili in GKE, vedi quanto segue:

ComputeClasses: il trigger per la creazione automatica del pool di nodi

Sebbene la creazione automatica del pool di nodi possa essere attivata dalla richiesta di un pod di un tipo di hardware specifico (come nvidia-l4-vws), l'utilizzo di una ComputeClass è il metodo più resiliente e moderno. Una ComputeClass è una risorsa GKE che definisci e che agisce su un insieme di regole per controllare e personalizzare la scalabilità automatica dell'hardware. Sebbene non sia un gestore della scalabilità automatica, funziona con il gestore della scalabilità automatica dei cluster.

Per estendere l'analogia, pensa a ComputeClasses come a un "modulo di richiesta intelligente" per l'attrezzatura del tuo negozio.

Invece di un addetto alle vendite (il tuo Pod) che richiede un hardware specifico e rigido (ad esempio "Ho bisogno del registratore di cassa Brand X Model 500"), richiede una funzionalità utilizzando il modulo di richiesta (ad esempio "Ho bisogno di una postazione di pagamento ad alta velocità"). Il modulo, ovvero ComputeClass, contiene un insieme di regole per il team acquisti (GKE) su come evadere l'ordine.

ComputeClasses separa la richiesta di hardware del pod dall'azione di provisioning di GKE. Anziché richiedere una macchina specifica (ad esempio a3-highgpu-8g), il pod può richiedere una ComputeClass. ComputeClass definisce la logica "smart", un elenco prioritario di regole che indicano a GKE come soddisfare la richiesta.

Per saperne di più, consulta Informazioni su GKE ComputeClasses.

Per un approfondimento su ComputeClass con esempi reali e configurazioni YAML, consulta la guida tecnica: Ottimizzazione dei carichi di lavoro GKE con ComputeClass personalizzate.

Metriche e trigger chiave per la scalabilità automatica

Per prendere decisioni di scalabilità informate, i componenti di scalabilità automatica monitorano diversi indicatori. La tabella seguente mostra il confronto dei trigger di scalabilità automatica basati sulle metriche.

Componente Reagisce a Origine segnale Ragionamento Azione di GKE
HPA Carico corrente Consumo in tempo reale, ad esempio la CPU è al 90% in questo momento. "I Pod attuali sono sovraccarichi. Dobbiamo distribuire questo traffico immediatamente". Aumenta o diminuisce il numero di repliche del pod per soddisfare la domanda.
VPA Efficienza del dimensionamento Consumo storico, ad esempio l'utilizzo medio della RAM nelle ultime 24 ore. "Le esigenze di risorse di questo pod sono cambiate o le nostre stime iniziali non erano corrette. Dobbiamo modificare l'allocazione delle risorse in base all'utilizzo effettivo". Aumenta o diminuisce le dimensioni: modifica le dimensioni (limiti di CPU o RAM) del pod per dimensionarlo correttamente.
Creazione automatica del node pool Disponibilità dell'hardware Richieste non soddisfatte, ad esempio il pod è nello stato "In attesa" perché non esistono nodi GPU. "Impossibile avviare questo pod perché l'hardware fisico richiesto non è presente." Esegue il provisioning dell'infrastruttura: crea nuovi node pool con l'hardware specifico.

Trigger di Horizontal Pod Autoscaler (HPA): reazione al carico

HPA scala il numero di pod (aumenta o diminuisce) monitorando le metriche sul rendimento in tempo reale. Ad esempio, l'utilizzo di CPU e memoria, le metriche fondamentali che indicano il carico di elaborazione sui tuoi pod, sono disponibili immediatamente per HPA.

Tuttavia, alcune metriche richiedono configurazioni esplicite, ad esempio:

  • Metriche del bilanciatore del carico (richieste al secondo (RPS)): una misurazione diretta del traffico dell'applicazione, che consente risposte di scalabilità più rapide. Per utilizzare questa metrica, consulta Abilitare il bilanciamento del carico basato sull'utilizzo e il profilo HPA per il rendimento.
  • Metriche personalizzate: configura la scalabilità automatica in base a metriche aziendali personalizzate, ad esempio "numero di utenti attivi", per gestire in modo proattivo le risorse in base alla domanda prevista. Per utilizzare le metriche personalizzate, devi configurare una pipeline delle metriche per esporle all'HPA. Per saperne di più, consulta Google Cloud Managed Service per Prometheus.

Trigger di Vertical Pod Autoscaler (VPA): reagire alle esigenze di risorse

VPA ridimensiona il pod (aumenta o riduce le dimensioni) monitorando il consumo storico delle risorse:

  • Utilizzo di CPU e memoria: la scalabilità automatica pod verticale analizza l'utilizzo passato di un pod per determinare se la richiesta di risorse è corretta. L'obiettivo principale di VPA è prevenire la contesa delle risorse aumentando o diminuendo le richieste di memoria e CPU di un pod in base alle sue esigenze reali.

Trigger di creazione automatica del node pool: risposta alle richieste hardware

La creazione automatica del node pool esegue il provisioning di nuovi node pool con hardware specializzato. Non viene attivato da metriche sul rendimento come il carico della CPU. Viene invece attivato da una richiesta di risorse del pod:

  • Richiesta di risorsa non pianificabile: un trigger chiave. Quando viene creato un pod, questo richiede hardware specifico. Se il cluster non può soddisfare questa richiesta perché nessun nodo esistente dispone di questo hardware, viene attivata la creazione automatica pool di nodi.
  • Richiesta ComputeClass: un pod richiede una ComputeClass, ad esempio cloud.google.com/compute-class: premium-gpu. Se nessun nodo del cluster può fornire le funzionalità "premium-gpu", la creazione automatica pool di nodi crea automaticamente un nuovo pool di nodi in grado di fornire queste funzionalità.

Per scoprire come utilizzare le metriche personalizzate, Prometheus ed esterne per ottenere la scalabilità automatica, consulta Informazioni sulla scalabilità automatica dei carichi di lavoro in base alle metriche.

Conclusione

Applicando queste strategie di scalabilità automatica, puoi gestire in modo efficace i workload AI/ML fluttuanti. Proprio come il responsabile del negozio Cymbal Shops ha gestito il suo evento di picco delle vendite gestendo in modo flessibile le risorse, puoi utilizzare la scalabilità automatica di GKE per espandere e ridurre automaticamente le risorse dell'infrastruttura e del carico di lavoro. In questo modo, i tuoi modelli rimangono performanti durante i picchi di traffico ed efficienti in termini di costi durante i periodi di inattività, mantenendo le dimensioni corrette dell'ambiente.

Passaggi successivi