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

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

Questo documento è destinato agli ingegneri di machine learning (ML) che non conoscono GKE. Ti consigliamo di leggere i seguenti documenti della serie per iniziare a utilizzare GKE per i workload AI/ML:

  1. Perché utilizzare GKE per l'inferenza AI/ML
  2. Informazioni sull'inferenza dei modelli 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 conoscenza di base dei seguenti concetti:

La sfida: soddisfare la domanda di picco

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

Se il motore per suggerimenti rallenta, l'esperienza utente ne risente e le vendite vanno perse. Tuttavia, il provisioning di una capacità server eccessiva non è conveniente durante i periodi di traffico normale. L'obiettivo è che le risorse vengano scalate automaticamente in risposta alla domanda, il che contribuisce a garantire una buona esperienza utente mantenendo i costi sotto controllo.

La soluzione: scalabilità automatica on demand

Le funzioni di scalabilità automatica di GKE sono simili a quelle di un responsabile del negozio che si prepara per un'ondata di vendite. Invece di mantenere un edificio enorme con personale e alimentazione sempre attivi, il responsabile 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 workload 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 per il provisioning eccessivo. La scalabilità automatica di GKE previene 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 è necessario e rimuoverlo al termine del job.
  • Affidabilità e prestazioni migliorate: la tua applicazione può fare lo scale out automaticamente (aggiungendo altre copie) per gestire picchi di traffico improvvisi, garantendo la stabilità per gli utenti. Allo stesso tempo, la scalabilità automatica di GKE aiuta a prevenire gli errori comuni di "Memoria insufficiente" (OOM) che possono causare l'arresto anomalo delle applicazioni. Per i job AI/ML impegnativi, contribuisce a garantire che l'hardware ad alte prestazioni necessario sia disponibile per essere eseguito in modo efficiente e completare i job in tempo.
  • Costo 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 dei node pool specializzati per hardware diversi. Questa automazione consente ai team di ingegneria di concentrarsi sullo sviluppo delle applicazioni anziché sull'ottimizzazione dell'infrastruttura.

Scalabilità automatica dei workload

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

Horizontal Pod Autoscaler (HPA): aggiunta di altre risorse

Horizontal Pod Autoscaler (HPA) monitora l'utilizzo delle risorse dei pod dell'applicazione. Nella nostra analogia, i pod sono gli "addetti alle vendite" e l'HPA è il "responsabile del team" che osserva quanto sono impegnati gli addetti alle vendite.

Quando la domanda sui pod aumenta, l'HPA esegue automaticamente il provisioning di altri pod per distribuire il carico. Quando la domanda diminuisce, l'HPA termina i pod inattivi per conservare le 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 offline, non si tratta di assumere altro personale, ma di migliorare le capacità del team attuale per migliorarne l'efficienza individuale.

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

Il VPA può regolare le richieste e i limiti delle risorse di un pod, ad esempio eseguendo di nuovo il provisioning del pod per scalare da 1 CPU e 16 GB a 4 CPU e 64 GB. Questa procedura prevede il riavvio del pod con la nuova configurazione più potente per gestire meglio il carico di lavoro.

Per maggiori informazioni, consulta le seguenti risorse:

HPA e VPA sono complementari. HPA regola il numero di pod in risposta alle variazioni del traffico e VPA contribuisce a garantire che ogni pod sia dimensionato correttamente per la sua attività. Queste strategie di scalabilità impediscono lo spreco di risorse, evitano costi non necessari e contribuiscono a garantire che l'app rimanga reattiva e disponibile durante le fluttuazioni del traffico. Tuttavia, non è consigliabile 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 in base alle esigenze dei workload.

Gestore della scalabilità automatica dei cluster: il responsabile dell'edificio

Il gestore della scalabilità automatica dei 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 dei cluster è il "responsabile dell'edificio".

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

Per saperne di più, consulta Gestore della scalabilità automatica dei cluster.

Creazione automatica dei node pool: lo specialista dell'automazione

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

Alcuni workload 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 workload 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 dei node pool.

Per gli acceleratori disponibili in GKE, consulta:

ComputeClass: il trigger per la creazione automatica dei pool di nodi

Sebbene la creazione automatica dei pool di nodi possa essere attivata dalla richiesta di un pod per un tipo di hardware specifico (ad esempio 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, considera le ComputeClass come un "modulo di richiesta intelligente" per le attrezzature 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 modello 500"), richiede una funzionalità utilizzando il modulo di richiesta (ad esempio, "Ho bisogno di una postazione di pagamento ad alta velocità"). Il modulo, la ComputeClass, contiene un insieme di regole per il team di acquisto (GKE) su come soddisfare l'ordine.

Le ComputeClass separano la richiesta di hardware del pod dall'azione di provisioning di GKE. Invece di richiedere una macchina specifica (ad esempio a3-highgpu-8g), il pod può richiedere una ComputeClass. La ComputeClass stessa definisce la logica "intelligente", un elenco di regole con priorità che indica a GKE come soddisfare la richiesta.

Per saperne di più, consulta Informazioni sulle ComputeClass di GKE.

Per un approfondimento sulle ComputeClass con esempi reali e configurazioni YAML, consulta la guida tecnica: Ottimizzare i workload GKE con ComputeClass personalizzate.

Metriche e trigger chiave per la scalabilità automatica

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

Componente Reagisce a Origine indicatore 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 immediatamente questo traffico." Esegue lo scale out o lo scale in: modifica il numero di repliche dei 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 regolare l'allocazione delle risorse in base all'utilizzo effettivo" Esegue lo scale up o lo scale down: modifica le dimensioni (limiti di CPU o RAM) del pod per dimensionarlo correttamente.
Creazione automatica dei node pool Disponibilità hardware Richieste non soddisfatte, ad esempio il pod è nello stato "In attesa" perché non esistono nodi GPU. "Impossibile avviare questo pod perché manca l'hardware fisico richiesto." Esegue il provisioning dell'infrastruttura: crea nuovi node pool con l'hardware specifico.

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

L'HPA scala il numero di pod (esegue lo scale in o lo scale out) 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 pod, sono disponibili immediatamente per l'HPA.

Tuttavia, alcune metriche richiedono configurazioni esplicite, ad esempio:

  • Metriche del bilanciatore del carico (richieste al secondo (RPS)): una misura 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 di metriche per esporle all'HPA. Per saperne di più, consulta Google Cloud Managed Service per Prometheus.

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

Il VPA scala le dimensioni del pod (esegue lo scale up o lo scale down) monitorando il consumo storico delle risorse:

  • Utilizzo di CPU e memoria: il VPA analizza l'utilizzo passato di un pod per determinare se la richiesta di risorse è corretta. L'obiettivo principale del 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 dei node pool: reazione alle richieste hardware

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

  • Richiesta di risorse non pianificabile: un trigger chiave. Quando viene creato un pod, richiede hardware specifico. Se il cluster non è in grado di soddisfare questa richiesta perché nessun nodo esistente dispone di questo hardware, la creazione automatica dei pool di nodi interviene.
  • Richiesta di ComputeClass: un pod richiede una ComputeClass, ad esempio cloud.google.com/compute-class: premium-gpu. Se nessun nodo nel cluster può fornire le funzionalità "premium-gpu", la creazione automatica dei 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 workload 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 l'evento di vendita di picco gestendo in modo flessibile le risorse, puoi utilizzare la scalabilità automatica di GKE per espandere e ridurre automaticamente le risorse dell'infrastruttura e dei workload. In questo modo, i modelli rimangono efficienti durante i picchi di traffico e convenienti durante i periodi di inattività, mantenendo l'ambiente dimensionato correttamente.

Passaggi successivi