In Cloud Run, ogni revisione viene scalata automaticamente in base 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 vuoi, puoi modificare questa impostazione predefinita in
specificare un'istanza da mantenere inattiva o "calda" utilizzando
numero minimo di istanze. Se utilizzi la CPU al di fuori delle richieste, devi impostare il numero minimo di istanze su 1
.
Oltre alla frequenza delle richieste in arrivo, degli eventi o dell'utilizzo della CPU, il numero di istanze pianificate è influenzato da:
- L'utilizzo medio della CPU delle istanze esistenti in una finestra di un minuto, con targeting per mantenere le istanze pianificate su un utilizzo della CPU del 60%.
- La contemporaneità delle richieste corrente, rispetto alla contemporaneità massima in un intervallo di un minuto.
- L'impostazione relativa al numero massimo di istanze
- L'impostazione relativa al numero minimo di istanze
Il gestore della scalabilità automatica di Cloud Run li valuta ogni 5 secondi.
CPU sempre allocata e scalabilità automatica
Se configuri il servizio Cloud Run per avere CPU sempre allocata, il comportamento della scalabilità verso e da zero.
Scalabilità allocata della CPU sempre da zero. La scalabilità da zero può essere attivata solo da una richiesta, quindi un servizio che non elabora le richieste non può scalare zero. Per questi carichi di lavoro, puoi impostare un numero minimo di istanze > 0 o includere una "richiesta di risveglio" nel design per riavviare l'elaborazione dopo la scalabilità a zero.
La CPU è sempre allocata con scalabilità fino a zero. dato che nessuna istanza è mai allo 0% la CPU, esaminando tutto l'utilizzo della CPU, non otterrebbe mai la scalabilità a zero. Ciò significa la decisione di scalare da uno a zero può essere presa solo controllando se se l'istanza sta elaborando una richiesta.
Informazioni sul numero massimo di istanze
In alcuni casi è consigliabile limitare il numero totale di istanze che possono essere avviati, per motivi di controllo dei costi o per una migliore compatibilità ad altre risorse utilizzate dal tuo servizio. Ad esempio, il tuo Cloud Run potrebbe interagire con un database che può gestire solo un certo numero e connessioni aperte simultanee.
Puoi utilizzare l'impostazione di istanze massime per limitare il numero totale di istanze che possono essere avviate in parallelo, come descritto in Impostazione di un numero massimo di istanze.
Numero massimo di istanze superato
In circostanze normali, la revisione viene eseguita su più istanze per gestire il carico del traffico in entrata. Ma quando imposti un limite massimo di istanze, in alcune In alcuni casi, le istanze non saranno sufficienti per soddisfare quel carico di traffico. In questo caso, le richieste in arrivo vengono messe in coda (in attesa) come segue:
- Se vengono avviate nuove istanze, ad esempio durante uno scale-out, le richieste rimarranno in attesa per almeno il tempo di avvio medio delle istanze di container di questo servizio. Ciò include quando la richiesta avvia uno scale-out, ad esempio quando si esegue lo scale up da zero.
- Se il tempo di avvio è inferiore a 10 secondi, le richieste rimarranno in attesa per un massimo di 10 secondi.
- Se non sono presenti istanze in fase di avvio e la richiesta non avviano uno scale out, le richieste pendono per un massimo di per 10 secondi.
Durante questo intervallo di tempo, se un'istanza termina l'elaborazione delle richieste,
disponibili per elaborare le richieste in attesa in coda.
Se nessuna istanza è disponibile durante la finestra temporale, la richiesta non va a buon fine e
Codice di errore 429
.
Garanzie di scalabilità
Il limite massimo di istanze è un limite massimo 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 fare lo scale out fino al massimo le istanze limitati molto rapidamente per gestire tutte le richieste o gli eventi in entrata. Tuttavia, Impostare un limite alto non significa che sarà possibile fare lo scale out della revisione il numero di istanze specificato in un dato momento. In circostanze eccezionale, Cloud Run può limitare la scalabilità per garantire un buon servizio per 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 delle istanze massime. Le nuove istanze possono essere iniziato superando l'impostazione del numero massimo di istanze per sostituire le istanze esistenti e fornire un periodo di tolleranza per il completamento dell'elaborazione delle richieste in corso.
Il limite massimo di istanze può essere superato in condizioni di funzionamento normale alcune volte 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 dopo che sono diventate inattive.
Se sono necessarie molte sostituzioni, gli aggiornamenti in genere vengono distribuiti nell'arco di molti minuti o ore, ma ogni sostituzione ha un'istanza in eccesso solo per il periodo di tolleranza. Le istanze che superano il valore massimo sono normalmente inferiori al doppio del valore ha configurato il limite massimo di istanze, ma può essere molto maggiore in caso di picchi di traffico elevati e improvvisi.
I test di carico subiscono più istanze che superano l'impostazione del numero massimo di istanze perché il sistema potrebbe cambiare la posizione in cui vengono pubblicati i picchi di traffico, in modo da preservare la capacità per i carichi di lavoro esistenti. con pattern di carico sostenuto.
Se il tuo servizio non tollera questo comportamento temporaneo, ti consigliamo per calcolare un margine di sicurezza e impostare un valore massimo più basso per le istanze.
Suddivisioni del traffico
Poiché il limite di istanze massime è un limite per ogni revisione, se il servizio suddivide il traffico in più revisioni, il numero totale di istanze per il servizio può superare il numero massimo di istanze per revisione. Questo fenomeno 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 e il traffico verso di essi. In questo modo si riduce l'impatto dei nuovi implementazioni delle revisioni sulle latenze delle richieste, in particolare quando vengono pubblicati livelli elevati di traffico. Poiché il limite di istanze massime è 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 fenomeno può essere osservato nelle metriche Conteggio istanze.
Istanze inattive e riduzione al minimo degli avvii a freddo
Cloud Run non arresta immediatamente le istanze dopo che hanno gestito 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. Queste istanze sono pronte a gestire le richieste in caso di un picco improvviso di traffico.
Ad esempio, quando un'istanza ha terminato di gestire le richieste, rimangono inattive per un certo periodo di tempo nel caso in cui sia necessario un'altra richiesta gestire. Un'istanza inattiva potrebbe mantenere le risorse, ad esempio le connessioni a database aperte. Tieni presente che la CPU viene allocata solo durante l'elaborazione delle richieste a meno che non configuri esplicitamente il servizio CPU sempre allocata.
Per mantenere le istanze inattive permanentemente disponibili, utilizza
min-instance
. Tieni presente che l'utilizzo di questa funzionalità comporterà un costo anche quando il servizio non sta pubblicando attivamente le richieste.
Scalabilità automatica e richieste in attesa
- Se vengono avviate nuove istanze, ad esempio durante uno scale out, le richieste almeno il tempo di avvio medio delle istanze di container di questo servizio. Sono inclusi i casi in cui la richiesta avvia uno scale out, ad esempio durante la scalabilità partendo da zero.
- Se il tempo di avvio è inferiore a 10 secondi, le richieste rimarranno in attesa per un massimo di 10 secondi.
- Se non sono presenti istanze in fase di avvio e la richiesta non avviano uno scale out, le richieste pendono per un massimo di per 10 secondi.
Impatto della scalabilità automatica sui servizi di supporto
Con l'aumento automatico del numero di istanze, Il servizio Cloud Run potrebbe riscontrare limiti con i suoi servizi di supporto. Ad esempio, Cloud SQL ha un limite di quota API. Assicurati che questi servizi di supporto abbiano una quota sufficiente e che possano gestire le connessioni da tutte le istanze del 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 iscrizioni push per consumare i messaggi da 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 (file collaterali)
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 la CPU viene allocata quando imposti i limiti della CPU a livello di contenitore. Se utilizzi più container per istanza, l'allocazione effettiva della CPU per quell'istanza è la somma dei limiti di CPU impostati su ciascun container.
Passaggi successivi
- Per gestire il numero massimo di istanze dei 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 contemporaneità.
- Per ottimizzare l'impostazione della contemporaneità, vedi suggerimenti di sviluppo per ottimizzare la contemporaneità.
- Per specificare un'istanza inattiva da mantenere in esecuzione per ridurre al minimo la latenza o gli avvii a freddo alle prime richieste, consulta Utilizzare
min-instance
per attivare le istanze inattive.