Informazioni sulla scalabilità automatica delle istanze nei servizi Cloud Run

Questa pagina descrive il comportamento di scalabilità automatica predefinito di Cloud Run. Per un'opzione di scalabilità alternativa in cui puoi configurare un conteggio specifico di istanze, vedi Scalabilità manuale.

Per impostazione predefinita, ogni revisione di Cloud Run viene scalata automaticamente al numero di istanze necessarie per gestire le richieste in entrata, gli eventi o l'utilizzo della CPU. Puoi anche perfezionare questo comportamento di scalabilità configurando target personalizzati per CPU e utilizzo.

Quando una revisione non riceve traffico, per impostazione predefinita viene scalata a zero istanze. Puoi modificare questo valore predefinito per specificare un'istanza da mantenere inattiva o "in uso" utilizzando l'impostazione istanze minime. Se il tuo servizio utilizza la CPU anche quando non elabora richieste, devi impostare il numero minimo di istanze su 1.

Il gestore della scalabilità automatica di Cloud Run valuta periodicamente le seguenti metriche per determinare il numero di istanze necessarie per gestire il traffico:

  • Utilizzo di CPU e concorrenza: Cloud Run regola il numero di istanze per mantenere la CPU e la concorrenza medie entro le soglie target.

  • Limiti di istanza: Cloud Run limita il numero di istanze tra i limiti massimo e minimo che configuri.

Comportamento della scalabilità automatica orizzontale del servizio

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

Scalabilità basata sulle metriche

La scalabilità basata sulle metriche regola automaticamente il numero di istanze in base all'utilizzo medio della CPU e ai driver di scalabilità della concorrenza media delle richieste per fornire una capacità di gestione stabile per il 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 della CPU: calcola il numero di istanze facendo la media dell'utilizzo della CPU al secondo in un periodo di 1 minuto e dividendo questo valore per il numero di CPU per istanza. Questo risultato viene ulteriormente diviso per il target di CPU. La seguente equazione definisce questo calcolo:

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

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

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

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

Cloud Run non supporta lo scaling in base all'utilizzo della memoria.

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

Quando Cloud Run esegue lo scaling in base all'utilizzo della CPU, prende in considerazione l'utilizzo medio della CPU in tutte le CPU allocate a un'istanza. Se la tua applicazione è single-thread ma viene eseguita il deployment su un'istanza multi-CPU, ciò può comportare una lettura dell'utilizzo medio basso, il che potrebbe influire sul modo in cui vengono prese le decisioni di scalabilità basate sulla CPU. Per ulteriori dettagli sull'ottimizzazione della configurazione della CPU per l'architettura dell'applicazione, vedi Configurare i limiti della CPU e Impostare il numero massimo di richieste simultanee per istanza.

Scale up

Cloud Run aumenta il numero di istanze in base al driver di scalabilità che richiede più istanze.

Anche se Cloud Run ha come target un utilizzo del 60% per le revisioni, con un numero inferiore di istanze, il gestore della scalabilità automatica potrebbe attendere più a lungo prima di scalare.

Puoi attivare i controlli di scalabilità (anteprima) per passare a un modello di scalabilità automatica di maggiore precisione, in cui la scalabilità automatica basata su metriche di Cloud Run risponde in modo preciso ai target che configuri, anche per i servizi con un numero ridotto di istanze. Se il tuo servizio differisce dalle configurazioni target personalizzate di oltre la soglia di tolleranza del 10%, Cloud Run consiglia il numero di istanze richiesto per portare il driver di scalabilità che attiva lo scaling al di sotto del target.

Scalabilità verso il basso

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 sulle metriche modifica continuamente il numero di istanze consigliate in base all'utilizzo.

Quando l'utilizzo medio della CPU o le richieste attive medie diminuiscono, l'algoritmo di scalabilità riduce il numero consigliato di istanze. Il bilanciatore del carico delle richieste di Cloud Run prende in considerazione questi consigli indirizzando preferibilmente le richieste in entrata prima alle istanze consigliate. In questo modo le istanze consigliate sono più occupate e le altre istanze rimangono inattive. Cloud Run riduce il conteggio di queste istanze non consigliate declassandole 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 intervallo 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 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 le istanze minime su almeno 1 per garantire che la CPU rimanga allocata per l'elaborazione in background.

Scalabilità on demand

Cloud Run utilizza lo scaling on demand quando non riesce a trovare un'istanza disponibile per gestire la richiesta in entrata. Lo scaling on demand risponde in tempo reale alle variazioni del traffico in entrata su una revisione di Cloud Run o alle variazioni della latenza della revisione. Questo scalabilità tenta di garantire che ogni richiesta in entrata venga indirizzata a un'istanza in breve tempo. La scalabilità on demand è l'unico driver per la scalabilità da zero. Tuttavia, quando la scalabilità avviene da N istanze, la scalabilità basata sulle metriche o su richiesta gestisce il traffico, a seconda di quale si attiva per prima.

Poiché lo scaling on demand risponde in tempo reale ai cambiamenti improvvisi 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 in cui una richiesta attende l'apertura di uno slot su un'istanza esistente). Per ogni richiesta, il sistema determina se la messa in coda per un'istanza imminente o un'istanza esistente è più veloce (in questo 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 il tempo di avvio a freddo previsto (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 la regolazione adattiva della concorrenza (ACT) per impedire 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 massimo di richieste simultanee dell'istanza per mantenere l'utilizzo della CPU al di sotto del 90%. ACT regola la concorrenza 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 simultanee dell'istanza.

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

  • Se le metriche di scalabilità mostrano che la concorrenza non raggiunge mai il massimo configurato, potrebbe essere perché ACT ha ridotto dinamicamente il 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 concorrenza 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à. Le metriche ACT non sono osservabili.

Fatturazione e scalabilità automatica basate sulle istanze

Se configuri la fatturazione basata sulle istanze per il tuo servizio Cloud Run, devi tenere presente lo scaling a e da zero.

Scalabilità da zero. Lo scale da zero può essere attivato solo da una richiesta, quindi un servizio che non elabora richieste non può scalare da zero. Per questi carichi di lavoro, puoi impostare un numero minimo di istanze > 0 oppure includere una "richiesta di riattivazione" nella progettazione per riavviare l'elaborazione dopo lo scaling a zero.

Scalabilità fino a zero. Dato che nessuna istanza è mai allo 0% di CPU, l'analisi di tutto l'utilizzo della CPU non comporterebbe mai lo scale down a zero. Ciò significa che la decisione di scalare da 1 a 0 può essere presa solo verificando 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 simultanee.

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 descritto in Impostare un numero massimo di istanze.

Superamento del numero massimo di istanze

In circostanze normali, la tua revisione viene scalata creando nuove istanze per gestire il carico di traffico in entrata. Tuttavia, quando imposti un limite massimo di istanze, in alcuni scenari non ci saranno istanze sufficienti per soddisfare il carico di traffico. In questo caso, le richieste in entrata vengono messe in coda (in attesa) nel seguente modo:

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

Durante questo periodo di tempo, se un'istanza termina l'elaborazione delle richieste, diventa disponibile per elaborare le richieste in attesa in coda. Se non diventa disponibile alcuna istanza 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 significa che il numero di istanze per questa revisione non deve superare il 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 potrà fare lo scale out fino al numero di istanze specificato in un determinato momento. In circostanze eccezionali, Cloud Run può limitare lo scaling per garantire un buon servizio 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 di quelle specificate nell'impostazione del numero massimo di istanze. Le nuove istanze possono essere avviate oltre l'impostazione del numero massimo di istanze per sostituire le istanze esistenti e fornire un periodo di tolleranza per consentire alle richieste in corso di completare l'elaborazione.

Il limite massimo di istanze può essere superato durante il normale funzionamento alcune volte alla settimana. Il periodo di tolleranza di solito dura fino a 15 minuti o fino al valore specificato nell'impostazione Timeout richiesta. Queste istanze aggiuntive vengono eliminate entro 15 minuti dall'inattività.

Se sono necessarie molte sostituzioni, gli aggiornamenti vengono in genere distribuiti su più 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 dell'istanza sono normalmente inferiori al doppio del limite massimo di istanze configurato, ma possono essere molto più grandi in caso di picchi di traffico improvvisi e di grandi dimensioni.

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 pubblicati i picchi di traffico per preservare la capacità dei carichi di lavoro esistenti che hanno mantenuto pattern di carico.

Se il 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 massimo di istanze è un limite per ogni revisione, se il servizio divide il traffico tra più revisioni, il numero totale di istanze per il servizio può superare il numero massimo di istanze per revisione. Ciò può essere osservato nelle metriche Conteggio istanze.

Deployment

Quando esegui il deployment di una nuova revisione per pubblicare il 100% del traffico, Cloud Run avvia un numero sufficiente di istanze della nuova revisione prima di indirizzare il traffico. In questo modo si riduce l'impatto dei deployment di nuove revisioni sulle latenze delle richieste, in particolare quando si gestiscono livelli elevati di traffico. Poiché il limite 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. Ciò 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 che hanno terminato la gestione delle richieste (fino a 15 minuti o 10 minuti per le GPU).

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

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

Scalabilità automatica e richieste in attesa

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

Impatto della scalabilità automatica sui servizi di backend

Man mano che il numero di istanze aumenta automaticamente, il tuo servizio Cloud Run potrebbe riscontrare limiti con i suoi servizi di backend. Ad esempio, Cloud SQL ha un limite di quota API. Assicurati che questi servizi di backend abbiano 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 backend.

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 push vengono ricevuti come richieste HTTP dal contenitore, 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 allochi la CPU quando imposti i limiti della CPU a livello di container. Se utilizzi più container per istanza, l'allocazione effettiva della CPU per quell'istanza è la somma dei limiti della CPU che hai impostato su ogni container.

Passaggi successivi