Le istanze sono i componenti di base di App Engine e forniscono tutte le risorse necessarie per ospitare correttamente l'applicazione. L'applicazione può essere eseguita in qualsiasi momento su una o più istanze e le richieste possono essere distribuite su tutte le istanze. Ogni istanza include un livello di sicurezza per garantire che le istanze non si influenzino a vicenda.
App Engine può creare e arrestare automaticamente le istanze quando il traffico fluttua oppure puoi specificare il numero di istanze da eseguire a prescindere dalla quantità di traffico. Per determinare come e quando vengono create nuove istanze, devi specificare un tipo di scalabilità per l'app. Le impostazioni di scalabilità vengono applicate a livello di versione di App Engine nell'ambito del file app.yaml.
Tipi di scalabilità
App Engine supporta i seguenti tipi di scalabilità, che controllano come e quando vengono create le istanze:
- Automatica (impostazione predefinita)
- Base
- Manuale
Puoi specificare il tipo di scalabilità nella
app.yaml dell'app.
Per impostazione predefinita, la tua app utilizza la scalabilità automatica, il che significa che App Engine gestirà il numero di istanze inattive.
- Scalabilità automatica
- La scalabilità automatica crea istanze in base al tasso di richieste, alle latenze di risposta e ad altre metriche delle applicazioni. Puoi specificare le soglie per ciascuna di queste
metriche, nonché un numero minimo di istanze da mantenere sempre in esecuzione
configurando l'elemento
automatic_scaling.
- Scalabilità di base
- La scalabilità di base crea istanze quando la tua applicazione riceve richieste. Ogni istanza verrà arrestata quando l'applicazione diventa inattiva. La scalabilità di base è ideale per attività intermittenti o guidate dall'attività utente.
- Scalabilità manuale
- La scalabilità manuale specifica il numero di istanze che vengono eseguite in modo continuo indipendentemente dal livello di carico. Ciò permette attività come inizializzazioni complesse e applicazioni che si basano sullo stato della memoria nel tempo.
| Selezione delle | Scalabilità automatica | Scalabilità di base | Scalabilità manuale |
|---|---|---|---|
| Timeout della richiesta |
Dieci minuti per richieste HTTP e attività in coda di attività. Se la tua app non
restituisce una richiesta entro questo limite di tempo, App Engine interrompe
il gestore di richieste e
emette
un errore da far gestire al tuo codice.
Per i runtime legacy (Java 8, PHP 5 e Python 2):
|
24 ore per richieste HTTP e attività in coda di attività. Se la tua app non
restituisce una richiesta entro questo limite di tempo, App Engine interrompe il
gestore di richieste e
emette
un errore da far gestire al tuo codice.
Un'istanza con scalabilità di base può scegliere di gestire |
Come la scalabilità di base. |
| Thread in background | Non consentito | Consentito | Consentito |
| Residenza | Le istanze vengono arrestate in base ai pattern di utilizzo. |
Le istanze vengono arrestate in base al parametro idle_timeout. Se un'istanza è inattiva, ad esempio non ha ricevuto
una richiesta per più di idle_timeout, l'istanza viene arrestata.
|
Le istanze rimangono in memoria e lo stato viene conservato in tutte le richieste. Quando le istanze vengono arrestate, nei log viene visualizzata una richiesta /_ah/stop.
Se è presente un gestore /_ah/stop o un hook di arresto registrato, avranno 30 secondi di tempo per il completamento prima dell'arresto.
|
| Avvio e arresto | Le istanze vengono create on demand per gestire le richieste e vengono disattivate automaticamente quando sono inattive. |
Le istanze vengono create on demand per gestire le richieste e si arrestano automaticamente in caso di inattività, in base al parametro di configurazione idle_timeout. Un'istanza interrotta manualmente ha 30 secondi di tempo per terminare la gestione delle richieste prima di essere terminata in modo forzato.
|
Alle istanze viene inviata automaticamente una richiesta di avvio da App Engine sotto forma di richiesta GET vuota a /_ah/start. Come per la scalabilità di base, un'istanza Arrestata manualmente ha 30 secondi di tempo per terminare la gestione delle richieste prima di essere arrestata forzatamente.
|
| Indirizzabilità dell'istanza | Le istanze sono anonime. |
L'istanza "i" della versione "v" del servizio "s" è indirizzabile all'URL:
https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com.
Se hai configurato una
mappatura dei sottodomini con caratteri jolly per un dominio personalizzato, puoi anche indirizzare un servizio o una delle sue istanze tramite un URL nel formato https://s.domain.com o https://i.s.domain.com.
Puoi memorizzare nella cache in modo affidabile lo stato di ogni istanza e recuperarlo nelle richieste successive.
|
Come la scalabilità di base. |
| Scalabilità |
App Engine scala il numero di istanze automaticamente in risposta al volume di elaborazione. Questa scalabilità tiene conto delle
impostazioni di automatic_scaling fornite in base alla
versione nel file di configurazione.
|
Un servizio con scalabilità di base viene configurato impostando il numero massimo di istanze nel parametro max_instances dell'impostazione basic_scaling. Il numero di istanze attive scala in base al volume di elaborazione.
|
Configuri il numero di istanze di ogni versione nel file di configurazione del servizio. Il numero di istanze di solito corrisponde alla dimensione di un set di dati conservato in memoria o alla velocità effettiva desiderata per il lavoro offline. Puoi regolare molto rapidamente il numero di istanze di una versione con scalabilità manuale, senza arrestare le istanze attualmente in esecuzione, utilizzando la funzione set_num_instances dell'API Modules.
|
Scalabilità delle istanze dinamiche
Le applicazioni App Engine che utilizzano la scalabilità di base o automatica sono basate su un numero qualsiasi di istanze dinamiche contemporaneamente, a seconda del volume di richieste in arrivo. Con l'aumento delle richieste per la tua applicazione, potrebbe aumentare anche il numero di istanze dinamiche.
App con scalabilità di base
Se utilizzi la scalabilità di base, App Engine tenta di mantenere i costi bassi, anche se ciò potrebbe comportare una latenza più elevata con l'aumento del volume delle richieste in entrata.
Se nessuna delle istanze esistenti è disponibile per gestire una richiesta in entrata, App Engine avvia una nuova istanza. Anche dopo l'avvio di una nuova istanza, alcune richieste potrebbero dover essere in coda fino a quando la nuova istanza non completa il suo processo di avvio. Se hai bisogno della latenza più bassa possibile, valuta l'utilizzo della scalabilità automatica, che crea nuove istanze in modo preventivo per ridurre al minimo la latenza.
App con scalabilità automatica
Se utilizzi la scalabilità automatica, ogni istanza dell'app ha la propria coda per le richieste in arrivo. Prima che le code diventino abbastanza lunghe da avere un effetto notevole sulla latenza dell'app, App Engine crea automaticamente una o più nuove istanze per gestire il carico crescente.
Puoi configurare le impostazioni per la scalabilità automatica per trovare un compromesso tra le prestazioni desiderate e il costo che puoi sostenere. La seguente tabella descrive queste impostazioni.
| Impostazioni di scalabilità automatica | Descrizione |
|---|---|
| Utilizzo della CPU target | Imposta la soglia del rapporto di utilizzo della CPU per specificare la soglia di utilizzo della CPU alla quale verranno avviate più istanze per gestire il traffico. |
| Utilizzo della velocità effettiva target | Imposta la soglia di velocità effettiva per il numero di richieste in parallelo dopo le quali più istanze inizieranno a gestire il traffico. |
| Numero massimo di richieste in parallelo | Imposta il numero massimo di richieste in parallelo che un'istanza può accettare prima che lo scheduler generi una nuova istanza. |
Guarda il video sulle impostazioni dello scheduler di App Engine per vedere gli effetti di queste impostazioni.
Scale down
Quando i volumi delle richieste diminuiscono, App Engine riduce il numero di istanze. La scalabilità verso il basso aiuta a garantire che tutte le istanze attuali dell'applicazione vengano utilizzate per ottimizzare l'efficienza e l'efficienza in termini di costi.
Quando un'applicazione non viene utilizzata, App Engine disattiva le istanze dinamiche associate, ma le ricarica facilmente non appena sono necessarie. Il ricaricamento delle istanze può comportare il caricamento delle richieste e una latenza aggiuntiva per gli utenti.
Puoi specificare un numero minimo di istanze inattive. L'impostazione di un numero appropriato di istanze inattive per l'applicazione in base al volume delle richieste consente all'applicazione di gestire ogni richiesta con poca latenza, a meno che tu non stia riscontrando un volume di richieste insolitamente elevato.
Scale down nella scalabilità automatica
Se l'app utilizza la scalabilità automatica, saranno necessari circa 15 minuti di inattività prima che le istanze inattive inizino ad arrestarsi. Per mantenere in esecuzione una o più istanze inattive, imposta il valore di min_idle_instances su 1 o su un valore superiore.
Scalabilità e batch di richieste
Se invii batch di richieste ai tuoi servizi, ad esempio a una coda di attività per l'elaborazione, verrà creato rapidamente un numero elevato di istanze. Consigliamo di controllare questa impostazione limitando la frequenza del numero di richieste inviate al secondo, se possibile. Ad esempio, se utilizzi Google Tasks, puoi controllare la frequenza con cui viene eseguito il push delle attività.
Ciclo di vita di un'istanza
Stati istanza
È sempre in esecuzione un'istanza di un servizio con scalabilità automatica. Tuttavia, un'istanza di un servizio con scalabilità manuale o di base può essere in esecuzione o arrestata. Tutte le istanze dello stesso servizio e della stessa versione condividono lo stesso stato. Puoi modificare lo stato delle istanze gestendo le tue versioni. Puoi:
- Utilizza la pagina Versioni della console Google Cloud
- Usa i comandi
gcloud app versions startegcloud app versions stop - Utilizzare l'API Forms
Avvio
Ogni istanza di servizio viene creata in risposta a una richiesta di avvio, che è una richiesta HTTP GET vuota per /_ah/start. App Engine invia questa richiesta per creare un'istanza. Gli utenti non possono inviare una richiesta a /_ah/start. Le istanze con scalabilità manuale e di base devono rispondere alla richiesta di avvio prima di poter gestire un'altra richiesta. La richiesta di avvio può essere
utilizzata per due scopi:
- Per avviare un programma a tempo indeterminato, senza accettare ulteriori richieste.
- Inizializzare un'istanza prima che riceva traffico aggiuntivo.
Avvio manuale, di base e con scalabilità automatica delle istanze in modo diverso. Quando avvii
un'istanza con scalabilità manuale, App Engine invia immediatamente una
richiesta /_ah/start a ciascuna istanza. Quando avvii un'istanza di un servizio di scalabilità di base, App Engine consente di accettare il traffico, ma la richiesta /_ah/start non viene inviata a un'istanza finché non riceve la prima richiesta dell'utente. Più istanze di scalabilità di base vengono avviate solo se necessario, al fine di gestire l'aumento del traffico. Le istanze con scalabilità automatica non
ricevono alcuna richiesta /_ah/start.
Quando un'istanza risponde alla richiesta /_ah/start con un codice di stato HTTP
200–299 o 404, viene considerata avviata correttamente e può
gestire richieste aggiuntive. Altrimenti, App Engine termina l'istanza. Le istanze con scalabilità manuale vengono riavviate immediatamente, mentre le istanze di scalabilità di base vengono riavviate solo quando necessario per gestire il traffico.
Chiusura
Il processo di chiusura potrebbe essere attivato da una serie di eventi pianificati e non pianificati, ad esempio:
- Ci sono troppe istanze e non abbastanza richieste di app (traffico).
- Arresti manualmente un'istanza.
- Esegui il deployment di una versione aggiornata nel servizio.
- L'istanza supera la memoria massima per l'istanza
instance_classconfigurata. - L'applicazione esaurisce la quota di ore istanza.
- L'istanza viene spostata su un'altra macchina perché è stata riavviata la macchina attuale che esegue l'istanza oppure perché App Engine ha spostato l'istanza per migliorare la distribuzione del carico.
Uno dei vantaggi della piattaforma "paghi solo per quello che utilizzi " dell'ambiente standard di App Engine, come descritto in precedenza in Scalabilità verso il basso, è che il sistema scala automaticamente il numero di istanze fino a zero in assenza di traffico. Ciò contribuisce a rendere App Engine una soluzione conveniente per le piccole applicazioni che non ricevono richieste continue. Quando un'istanza deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre (se presenti) e le richieste attualmente in fase di elaborazione hanno il tempo di essere completate.
Quando è necessario arrestare un'istanza, App Engine invia un indicatoreKILL
(SIGKILL), terminando l'istanza.
Caricamento delle richieste in corso...
Quando App Engine crea una nuova istanza per la tua applicazione, quest'ultima deve prima caricare le librerie e le risorse necessarie per gestire la richiesta. Questo accade durante la prima richiesta all'istanza, chiamata richiesta di caricamento. Durante una richiesta di caricamento, l'applicazione viene iniziata con un processo di inizializzazione che determina la durata della richiesta.
Le seguenti best practice ti consentono di ridurre la durata delle richieste di caricamento:
- Carica solo il codice necessario per l'avvio.
- Accedi al disco il meno possibile.
- In alcuni casi, il caricamento del codice da un file ZIP o jar è più veloce rispetto a quello da molti file separati.
Richieste di riscaldamento
Le richieste di riscaldamento sono un tipo specifico di richiesta di caricamento che carica in anticipo il codice dell'applicazione in un'istanza, prima che vengano effettuate richieste in tempo reale.
Le istanze con scalabilità manuale o di base non ricevono una richiesta /_ah/warmup.
Uptime delle istanze
App Engine tenta di mantenere in esecuzione le istanze di scalabilità manuali e di base per un tempo indefinito. Tuttavia, al momento non è garantito il tempo di attività per le istanze con scalabilità manuale e di base. Gli errori hardware e software che causano terminazione anticipata o frequenti riavvii possono verificarsi senza preavviso e possono richiedere molto tempo per la risoluzione. Pertanto, devi costruire l'applicazione in modo da tollerare questi errori.
Ecco alcune buone strategie per evitare tempi di inattività dovuti al riavvio delle istanze:
- Riduci il tempo necessario per il riavvio delle istanze o per l'avvio di nuove istanze.
- Per calcoli a lunga esecuzione, crea periodicamente punti di controllo in modo da poter riprendere da quello stato.
- La tua app deve essere "stateless" in modo che non venga archiviato nulla nell'istanza.
- Utilizza le code per eseguire l'esecuzione asincrona delle attività.
- Se configuri le istanze sulla scalabilità manuale:
- Utilizza il bilanciamento del carico in più istanze.
- Configura più istanze di quelle necessarie per gestire il traffico normale.
- Scrivi una logica di fallback che utilizza i risultati memorizzati nella cache quando non è disponibile un'istanza con scalabilità manuale.
NTP con l'ambiente standard di App Engine
L'ambiente standard App Engine dispone di servizi NTP (Network Time Protocol) che utilizzano i server NTP di Google. Tuttavia, il servizio NTP non è modificabile.