Questa pagina descrive il comportamento di scalabilità automatica predefinito di Cloud Run. Se hai bisogno di un maggiore controllo sul comportamento di scalabilità, scopri l'opzione di scalabilità alternativa, la scalabilità manuale.
Per impostazione predefinita, ogni revisione di Cloud Run viene scalata automaticamente al numero di istanze necessarie per gestire tutte le richieste, gli eventi o l'utilizzo della CPU in entrata.
Quando una revisione non riceve traffico, per impostazione predefinita viene scalata a zero istanze. Tuttavia, se necessario, puoi modificare questa impostazione predefinita per specificare un'istanza da mantenere inattiva o "in uso" utilizzando l'impostazione istanze minime. Se utilizzi la CPU al di fuori delle richieste, devi impostare il numero minimo di istanze pari a 1
.
Oltre alla frequenza delle richieste, degli eventi o dell'utilizzo della CPU in entrata, il numero di istanze pianificate è influenzato da:
- L'utilizzo medio della CPU delle istanze esistenti in un intervallo di un minuto, con l'obiettivo di mantenere le istanze pianificate a un utilizzo della CPU del 60%.
- La concorrenza delle richieste attuale, con l'obiettivo di mantenere la concorrenza delle istanze al 60% della concorrenza massima in una finestra di un minuto.
- L'impostazione del numero massimo di istanze
- L'impostazione del numero minimo di istanze
Il gestore della scalabilità automatica di Cloud Run li valuta periodicamente.
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 up da zero può essere attivato solo da una richiesta, quindi un servizio che non elabora richieste non può essere scalato da zero. Per questi carichi di lavoro, puoi impostare istanze minime > 0 o includere una "richiesta di riattivazione" nella progettazione per riavviare l'elaborazione dopo lo scale down 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
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 in grado di gestire solo un determinato numero di connessioni aperte simultanee.
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 revisione viene scalata orizzontalmente 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 accodate (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 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 massimo.
In circostanze normali, Cloud Run è in grado di scalare 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à essere scalata al numero specificato di istanze 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 in caso di 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. È possibile avviare nuove istanze oltre l'impostazione del numero massimo di istanze per sostituire quelle 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 dura in genere 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 in genere 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 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 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 gestire il 100% del traffico, Cloud Run avvia un numero sufficiente di istanze della nuova revisione prima di indirizzare il traffico. Ciò riduce l'impatto dei nuovi deployment di revisione 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
Cloud Run non arresta immediatamente le istanze una volta gestite tutte le richieste. Per ridurre al minimo l'impatto degli avvii a freddo, Cloud Run potrebbe mantenere alcune istanze inattive per un massimo di 15 minuti. Le risorse Cloud Run con GPU abilitate possono mantenere alcune istanze inattive per un massimo di 10 minuti. Queste istanze sono pronte a gestire le richieste in caso di picco improvviso di traffico.
Ad esempio, quando un'istanza ha terminato di gestire le richieste, potrebbe rimanere inattiva per un periodo di tempo nel caso in cui debba essere gestita un'altra richiesta. Un'istanza inattiva può conservare risorse, ad esempio connessioni di database aperte. Tieni presente che l'impostazione di fatturazione predefinita è basata su richieste, a meno che tu non configuri esplicitamente il servizio in modo che utilizzi 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 prende in considerazione 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
- Per scoprire altre opzioni di scalabilità, consulta la scalabilità manuale.
- Per gestire il numero massimo di istanze dei tuoi servizi Cloud Run, consulta Impostazione di un numero massimo di istanze.
- Per gestire il numero massimo di richieste simultanee gestite da ogni istanza, consulta Impostazione della concorrenza.
- Per ottimizzare l'impostazione della contemporaneità, consulta i suggerimenti per lo sviluppo per la regolazione della contemporaneità.
- Per specificare un'istanza inattiva da mantenere in esecuzione per ridurre al minimo la latenza o gli avvii a freddo
nelle prime richieste, consulta
Utilizzo di
min-instance
per attivare le istanze inattive.