Informazioni sulla scalabilità automatica delle istanze nei servizi Cloud Run

La scalabilità automatica di Cloud Run regola il numero di istanze container per ogni revisione del servizio in modo che corrisponda alle richieste, agli eventi e all'utilizzo della CPU in entrata. La scalabilità delle istanze on demand aiuta il tuo servizio a gestire i picchi di traffico e a scalare fino a zero quando è inattivo per ridurre i costi.

Puoi ottimizzare le soglie di scalabilità automatica configurando target personalizzati di CPU e contemporaneità e impostando limiti di istanze minimi e massimi. Se il tuo servizio utilizza la CPU al di fuori dell'elaborazione delle richieste, imposta il numero minimo di istanze su almeno 1. Per eseguire un numero fisso di istanze, consulta Scalabilità manuale.

Comportamento della scalabilità automatica orizzontale dei servizi

Cloud Run ha due meccanismi di scalabilità automatica, la scalabilità basata su metriche e la scalabilità on demand, per determinare il numero di istanze necessarie per gestire il traffico.

Scalabilità basata su metriche

La scalabilità basata su metriche regola automaticamente il numero di istanze in base ai driver di scalabilità dell'utilizzo medio della CPU e della concorrenza media delle richieste per fornire una capacità di gestione stabile per il tuo servizio Cloud Run.

Il gestore della scalabilità automatica determina un numero consigliato di istanze in base al numero massimo di istanze che calcola per ciascuno dei seguenti driver di scalabilità in modo indipendente:

  • Utilizzo CPU: calcola il numero di istanze facendo la media dell'utilizzo della CPU al secondo in un periodo di 1 minuto e dividendo il risultato per il numero di CPU per istanza. Questo risultato viene ulteriormente diviso per il target della CPU. La seguente equazione definisce questo calcolo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \right\rceil \]

  • Concorrenza delle richieste: calcola il numero di istanze calcolando la media della concorrenza delle richieste al secondo in un periodo di 1 minuto e 10 minuti e dividendo il risultato per la concorrenza massima. Questo risultato viene ulteriormente diviso per il target di richieste in parallelo. La seguente equazione definisce questo calcolo:

\[ \text{Instances} = \left\lceil \dfrac{\left( \frac{\max(\text{average concurrent requests over 1 minute, 10 minutes})}{\text{Maximum concurrency}} \right)}{\text{Concurrency target}} \right\rceil \]

  • Ottimizzazione della concorrenza adattiva: calcola il numero consigliato di istanze per la concorrenza delle richieste media di 1 minuto. Questo metodo utilizza il valore ACT di ogni istanza come capacità di richieste in parallelo dell'istanza anziché il numero massimo di richieste in parallelo configurato. ACT riduce dinamicamente la concorrenza di 1 a intervalli di 1 secondo quando l'utilizzo della CPU supera il 90%. Per saperne di più, consulta Ottimizzazione della concorrenza adattiva (ACT).

Per ogni revisione del servizio, puoi configurare il numero di CPU per istanza e la contemporaneità massima.

Cloud Run non supporta la scalabilità in base all'utilizzo della memoria.

Per impostazione predefinita, la scalabilità basata su metriche imposta una soglia del 60% per i target di utilizzo della CPU e di concorrenza delle richieste. Puoi utilizzare i controlli di scalabilità per specificare target di CPU o contemporaneità personalizzati.

Quando Cloud Run esegue la scalabilità in base all'utilizzo della CPU, considera l'utilizzo medio della CPU in tutte le CPU allocate a un'istanza. Se la tua applicazione è single-thread, ma ne viene eseguito il deployment su un'istanza multi-CPU, ciò può portare a una lettura di utilizzo medio bassa, con un potenziale impatto sul modo in cui vengono prese le decisioni di scalabilità basate sulla CPU. Per maggiori dettagli sull'ottimizzazione della configurazione della CPU per l'architettura della tua applicazione, consulta Configura i limiti della CPU e Imposta il numero massimo di richieste in parallelo per istanza.

Scale up

Cloud Run aumenta il numero di istanze in base al driver di scalabilità che richiede più istanze. Con un numero ridotto di istanze, la scalabilità basata sulle metriche risponde in modo preciso ai target di utilizzo.

La scalabilità basata su metriche mantiene il numero di istanze attuale mentre l'utilizzo rimane entro una tolleranza del 10% rispetto al target. Ad esempio, con il target predefinito del 60%, il numero di istanze non cambia se l'utilizzo rimane compreso tra il 54% e il 66%.

Quando l'utilizzo non rientra in questo intervallo, la scalabilità basata sulle metriche ricalcola il conteggio delle istanze in base all'utilizzo misurato e al target, non al numero di istanze in esecuzione, e arrotonda il risultato all'istanza intera successiva. A causa di questo arrotondamento, il servizio può fare lo scale up anche se l'utilizzo è ancora inferiore al target. Ad esempio, un servizio che richiede 4,1 istanze per raggiungere il target esegue 5 istanze.

Fai lo scale down

La scalabilità automatica di Cloud Run riduce il numero di istanze in esecuzione quando non sono più necessarie per gestire il traffico in entrata. La scalabilità basata su metriche regola continuamente il numero di istanze consigliate in base all'utilizzo. Cloud Run riduce il numero di istanze consigliato solo quando l'utilizzo scende di oltre il 10% al di sotto del target, quindi utilizza lo stesso calcolo arrotondato per eccesso per determinare il nuovo numero.

Quando l'utilizzo medio della CPU o le richieste attive medie diminuiscono, l'algoritmo di scalabilità riduce il numero di istanze consigliate. Il bilanciatore del carico delle richieste di Cloud Run prende in considerazione questi suggerimenti indirizzando preferibilmente le richieste in entrata alle istanze consigliate. In questo modo, le istanze consigliate rimangono più occupate e le altre istanze rimangono inattive. Cloud Run riduce il numero di queste istanze non consigliate riducendone la priorità in modo che ricevano traffico solo se tutte le istanze consigliate sono occupate. Per mantenere la stabilità, Cloud Run arresta le istanze con priorità ridotta nel seguente ordine:

  1. Cloud Run arresta un gruppo di istanze quando il loro utilizzo in un periodo di 1 minuto è inferiore al 10%.
  2. Un secondo gruppo di istanze rimane in esecuzione fino a quando non si verifica un timeout di inattività di 15 minuti, garantendo la disponibilità della capacità in caso di un picco di traffico improvviso.

Se il tuo servizio esegue altre attività anche quando non elabora richieste, ad esempio l'esecuzione di thread in background o l'elaborazione di attività asincrone, devi impostare il numero minimo di istanze su almeno 1 per assicurarti che la CPU rimanga allocata per l'elaborazione in background.

Scalabilità on demand

Cloud Run utilizza la scalabilità on demand quando non riesce a trovare un'istanza disponibile per gestire la richiesta in entrata. La scalabilità on demand risponde in tempo reale alle modifiche del traffico in entrata su una revisione Cloud Run o alle modifiche della latenza della revisione. Questa scalabilità tenta di garantire che ogni richiesta in entrata venga indirizzata a un'istanza in un breve periodo di tempo. La scalabilità on demand è l'unico fattore che determina la scalabilità da zero. Tuttavia, quando si esegue lo scale up da N istanze, la scalabilità basata su metriche o on demand gestisce il traffico, a seconda di quale viene attivata per prima.

Poiché la scalabilità on demand risponde in tempo reale a variazioni improvvise del traffico, Cloud Run gestisce il compromesso tra la latenza di avvio a freddo (il tempo necessario per avviare una nuova istanza) e la latenza della coda in attesa (il tempo di attesa di una richiesta per l'apertura di uno slot su un'istanza esistente). Per ogni richiesta, il sistema determina se l'inserimento in coda per un'istanza imminente o un'istanza esistente è più veloce (in quest'ordine) prima di provare ad avviare una nuova istanza on demand. Una richiesta rimane nella coda in attesa per un massimo di 10 secondi o 3,5 volte l'ora di inizio a freddo prevista (a seconda di quale sia il valore più alto) prima che il sistema attivi una nuova istanza on demand.

Ottimizzazione della concorrenza adattiva (ACT)

Cloud Run utilizza l'ottimizzazione della concorrenza adattiva (ACT) per evitare che la limitazione della CPU causi un'elevata latenza delle richieste. Questo approccio misura l'utilizzo della CPU per ogni istanza in base a un determinato numero di richieste e regola dinamicamente il valore delle richieste in parallelo massime dell'istanza per mantenere l'utilizzo della CPU al di sotto del 90%. ACT ottimizza la contemporaneità in base ai seguenti scenari:

  • Ogni volta che l'utilizzo della CPU nell'ultimo secondo supera il 90%, ACT riduce di 1 il numero massimo di richieste in parallelo dell'istanza.

  • Se l'istanza raggiunge il limite massimo di richieste in parallelo e l'utilizzo della CPU rimane inferiore al 70% per 1 secondo, ACT aumenta di 1 il numero massimo di richieste in parallelo per l'istanza.

  • Se le metriche di scalabilità mostrano che la contemporaneità non raggiunge mai il valore massimo configurato, potrebbe essere perché ACT ha ridotto dinamicamente il valore massimo effettivo per proteggere le prestazioni dell'istanza.

Cloud Run calcola i valori ACT per ogni deployment. Queste metriche non vengono mantenute tra i deployment. Se ACT riduce la contemporaneità al di sotto del livello preferito, aumenta la CPU allocata per richiesta in parallelo massima. Anche le attività in background che causano picchi periodici della CPU possono interferire con questo approccio di scalabilità.

Puoi monitorare quando ACT gestisce attivamente la scalabilità automatica visualizzando il campo scaling_drivernella console Google Cloud . Per informazioni dettagliate su come visualizzare questa metrica, consulta Configura i controlli di scalabilità personalizzati per i servizi.

Fatturazione e scalabilità automatica basate sulle istanze

Se configuri la fatturazione basata sulle istanze per il tuo servizio Cloud Run, devi tenere presente il comportamento di scalabilità a e da zero.

Scalabilità da zero. Lo scale up da zero può essere attivato solo da una richiesta, quindi un servizio che non elabora richieste non può eseguire lo scale up da zero. Per questi workload, puoi impostare un numero di istanze minime > 0 o includere una "richiesta di riattivazione" nel tuo progetto per riavviare l'elaborazione dopo lo scale down a zero.

Scalabilità fino a zero. Dato che nessuna istanza ha mai un utilizzo della CPU pari allo 0%, l'analisi di tutto l'utilizzo della CPU comporterebbe l'impossibilità di scalare a zero. Ciò significa che la decisione di scalare da uno a zero può essere presa solo controllando se l'istanza sta elaborando una richiesta.

Informazioni sul numero massimo di istanze per i servizi

In alcuni casi potresti voler limitare il numero totale di istanze che possono essere avviate, per motivi di controllo dei costi o per una migliore compatibilità con altre risorse utilizzate dal tuo servizio. Ad esempio, il tuo servizio Cloud Run potrebbe interagire con un database che può gestire solo un determinato numero di connessioni aperte contemporaneamente.

A tutti i servizi viene assegnato un limite massimo di istanze per impostazione predefinita, anche se non specifichi un limite personalizzato. Imposta e monitora questo limite per determinare il comportamento di scalabilità e i costi associati al tuo servizio. Per saperne di più, consulta Limiti per il numero massimo di istanze.

Puoi utilizzare l'impostazione del numero massimo di istanze per limitare il numero totale di istanze che possono essere avviate in parallelo, come documentato in Impostazione di un numero massimo di istanze.

Superamento del numero massimo di istanze

In circostanze normali, la tua revisione fa lo scale out creando nuove istanze per gestire il carico di traffico in entrata. Tuttavia, se imposti un limite massimo di istanze, in alcuni scenari non saranno presenti istanze sufficienti per soddisfare il carico di traffico. In questo caso, le richieste in entrata vengono messe in coda (in attesa) come segue:

Le richieste rimarranno in attesa per un massimo di 3, 5 volte il tempo di avvio medio delle istanze di container di questo servizio o per 10 secondi, a seconda di quale sia il valore maggiore.

Durante questa finestra temporale, se un'istanza termina l'elaborazione delle richieste, diventa disponibile per elaborare le richieste in attesa in coda. Se non diventano disponibili istanze durante la finestra, la richiesta non va a buon fine e viene visualizzato un codice di errore 429.

Garanzie di scalabilità

Il limite massimo di istanze è un limite superiore per revisione e indica che il numero di istanze per questa revisione non deve superare il valore massimo.

In circostanze normali, Cloud Run è in grado di fare lo scale out fino al limite massimo di istanze molto rapidamente per gestire tutte le richieste o gli eventi in entrata. Tuttavia, l'impostazione di un limite elevato non significa che la revisione sarà in grado di fare lo scale out fino al numero di istanze specificato in un determinato momento. In circostanze eccezionali, Cloud Run può limitare la scalabilità per garantire un servizio di qualità a tutti i clienti.

Superamento del numero massimo di istanze a causa di picchi di traffico

In alcuni casi, ad esempio picchi di traffico rapidi o manutenzione del sistema, Cloud Run potrebbe, per un breve periodo di tempo, creare più istanze rispetto a quelle specificate nell'impostazione del numero massimo di istanze. È possibile avviare nuove istanze oltre l'impostazione del numero massimo di istanze per sostituire quelle esistenti e fornire un periodo di tolleranza per completare l'elaborazione delle richieste in corso.

Il limite massimo di istanze può essere superato in condizioni di funzionamento normali alcune volte alla settimana. Il periodo di tolleranza di solito dura fino a 15 minuti o fino al valore specificato nell'impostazione Timeout della richiesta. Queste istanze aggiuntive vengono eliminate entro 15 minuti dal momento in cui diventano inattive.

Se sono necessarie molte sostituzioni, gli aggiornamenti vengono in genere distribuiti su molti minuti o ore, ma ogni sostituzione ha un'istanza in eccesso solo per il periodo di tolleranza. Le istanze in eccesso rispetto al valore massimo sono in genere inferiori al doppio del limite massimo di istanze configurato, ma possono essere molto più numerose in caso di picchi di traffico improvvisi.

I test di carico riscontrano più istanze che superano l'impostazione del numero massimo di istanze perché il sistema potrebbe modificare la posizione in cui vengono gestiti i picchi di traffico per preservare la capacità per i workload esistenti che hanno pattern di carico sostenuti.

Se il tuo servizio non può tollerare questo comportamento temporaneo, ti consigliamo di considerare un margine di sicurezza e impostare un valore massimo di istanze inferiore.

Suddivisioni del traffico

Poiché il limite per il numero massimo di istanze è un limite per ogni revisione, se il servizio suddivide il traffico tra più revisioni, il numero totale di istanze per il servizio può superare il numero massimo di istanze per revisione. Questo può essere osservato nelle metriche Conteggio istanze.

Deployment

Quando esegui il deployment di una nuova revisione per gestire il 100% del traffico, Cloud Run avvia un numero sufficiente di istanze della nuova revisione prima di indirizzarvi il traffico. In questo modo si riduce l'impatto dei deployment di nuove revisioni sulle latenze delle richieste, in particolare quando viene gestito un traffico elevato. Poiché il limite per il numero massimo di istanze è un limite per ogni revisione, durante un deployment il numero totale di istanze per il servizio può superare il numero massimo di istanze per revisione. Questo può essere osservato nelle metriche Conteggio istanze.

Istanze inattive e riduzione al minimo degli avvii a freddo

Per ridurre al minimo gli avvii a freddo, Cloud Run potrebbe mantenere le istanze inattive per un periodo di tempo dopo aver terminato la gestione delle richieste (fino a 15 minuti o 10 minuti per le GPU).

Un'istanza inattiva potrebbe mantenere risorse persistenti, come connessioni aperte al database. Tieni presente che l'impostazione di fatturazione predefinita è la fatturazione basata su richieste, a meno che non configuri esplicitamente il servizio per la fatturazione basata su istanze.

Per mantenere le istanze inattive permanentemente disponibili, utilizza l'impostazione min-instance. Tieni presente che l'utilizzo di questa funzionalità comporta dei costi anche quando il servizio non gestisce attivamente le richieste.

Scalabilità automatica e richieste in attesa

Le richieste rimarranno in attesa per un massimo di 3, 5 volte il tempo di avvio medio delle istanze di container di questo servizio o per 10 secondi, a seconda di quale sia il valore maggiore.

Impatto della scalabilità automatica sui servizi di supporto

Man mano che il numero di istanze aumenta automaticamente, il servizio Cloud Run potrebbe incontrare limiti con i servizi di supporto. Ad esempio, Cloud SQL ha un limite di quota dell'API. Assicurati che questi servizi di supporto dispongano di una quota sufficiente e possano gestire le connessioni da tutte le istanze del tuo servizio Cloud Run. Valuta la possibilità di impostare un numero massimo di istanze per evitare di sovraccaricare i servizi di supporto.

Scalabilità automatica e Pub/Sub

Google consiglia di utilizzare le sottoscrizioni push per utilizzare i messaggi di un argomento Pub/Sub su Cloud Run. I messaggi inviati tramite push vengono ricevuti come richieste HTTP dal container, attivando così lo stesso comportamento di scalabilità automatica.

Scalabilità automatica e più container (sidecar)

Cloud Run considera l'utilizzo della CPU delle istanze per la scalabilità automatica, dove l'utilizzo della CPU di un'istanza è la percentuale di CPU allocata in uso.

Tieni presente che l'allocazione della CPU avviene quando imposti i limiti della CPU a livello di container. Se utilizzi più container per istanza, l'allocazione effettiva della CPU per l'istanza è la somma dei limiti della CPU impostati su ciascun container.

Passaggi successivi