Modalità di gestione delle istanze

Le istanze sono gli elementi di base di App Engine e forniscono tutte le risorse necessarie per ospitare l'applicazione. In qualsiasi momento, la tua applicazione può essere eseguita su una o più istanze con richieste distribuite su tutte. Ogni istanza include un livello di sicurezza per garantire che le istanze non possano interferire inavvertitamente tra loro.

App Engine può creare e arrestare automaticamente le istanze come fluttuazioni del traffico oppure specificare un numero di istanze da eseguire indipendentemente 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 come parte 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
  • Basic
  • Manuale

Sei tu a specificare il tipo di scalabilità nella tua app app.yaml.

Scalabilità automatica
La scalabilità automatica crea istanze in base a tasso di richieste, latenze di risposta e altre metriche relative alle applicazioni. Puoi specificare le soglie per ciascuna di queste metriche, nonché un numero minimo di istanze che devono rimanere sempre in esecuzione.
Scalabilità di base
La scalabilità di base crea le istanze quando la tua applicazione riceve richieste. Ogni istanza verrà arrestata quando l'applicazione diventa inattiva. La scalabilità di base è ideale per il lavoro intermittente o basato sull'attività degli utenti.
Scalabilità manuale
La scalabilità manuale specifica il numero di istanze che vengono eseguite continuamente, indipendentemente dal livello di carico. Ciò consente attività come inizializzazioni complesse e applicazioni che si basano sullo stato della memoria nel tempo.
In questa tabella vengono messe a confronto le funzionalità di rendimento dei tre tipi di scalabilità:

Caratteristica Scalabilità automatica Scalabilità di base Scalabilità manuale
Timeout richiesta 10 minuti per richieste HTTP e attività in coda delle attività. Se la tua app non restituisce una richiesta entro questo limite di tempo, App Engine interrompe il gestore della richiesta e emette un errore per il tuo codice da gestire.

Per i runtime legacy (Java 8, PHP 5 e Python 2):

  • Il timeout per le attività e le richieste della coda di attività dei cron job è di 10 minuti.
  • Il timeout per altre richieste HTTP è di 1 minuto.
24 ore per richieste HTTP e attività in coda delle attività. Se la tua app non restituisce una richiesta entro questo limite di tempo, App Engine interrompe il gestore delle richieste e emette un errore per il tuo codice da gestire.

Un'istanza con scalabilità di base può scegliere di gestire /_ah/start ed eseguire un programma o uno script per molte ore senza restituire un codice di risposta HTTP.

Uguale alla scalabilità di base.
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 tra le richieste. Quando le istanze vengono arrestate, nei log viene visualizzata una richiesta /_ah/stop. In presenza di un hook di spegnimento registrato, il completamento ha 30 secondi.
Avvio e arresto Le istanze vengono create on demand per gestire le richieste e disattivate automaticamente quando sono inattive. Le istanze vengono create on demand per gestire le richieste e si arrestano automaticamente quando sono inattive in base al parametro di configurazione idle_timeout. Un'istanza interrotta manualmente ha 30 secondi per completare la gestione delle richieste prima che venga interrotta forzatamente. App Engine invia automaticamente una richiesta di avvio a /_ah/start per una richiesta di avvio sotto forma di richiesta GET vuota. Come per la scalabilità di base, un'istanza interrotta manualmente ha 30 secondi per completare la gestione delle richieste prima che venga interrotta forzatamente.
Indirizzabilità delle istanze Le istanze sono anonime. L'istanza "i della versione"v del servizio"è indirizzato 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 qualsiasi delle sue istanze tramite un URL con il formato https://s.domain.com o https://i.s.domain.com. Puoi memorizzare in modo affidabile lo stato di ciascuna istanza in ciascuna istanza e recuperarla nelle richieste successive. Uguale alla scalabilità di base.
Scalabilità App Engine scala automaticamente il numero di istanze in risposta al volume di elaborazione. Questo fattore di scalabilità tiene conto delle impostazioni automatic_scaling fornite in base alla singola 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. Configura 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.

Scalabilità delle istanze dinamiche

Le applicazioni App Engine che utilizzano la scalabilità automatica o di base si basano su un numero qualsiasi di istanze dinamiche in un determinato momento, a seconda del volume delle richieste in entrata. All'aumentare delle richieste per la tua applicazione, può crescere anche il numero di istanze dinamiche.

App con scalabilità di base

Se utilizzi la scalabilità di base, App Engine tenta di mantenere bassi i costi, anche se ciò potrebbe comportare una latenza maggiore con l'aumentare del volume delle richieste in entrata.

Quando 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 messe in coda fino a quando la nuova istanza non completa il suo processo di avvio. Se hai bisogno della latenza più bassa possibile, valuta la possibilità di utilizzare la scalabilità automatica, che crea nuove istanze preventivamente 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 entrata. Prima che le code diventino abbastanza lunghe da avere un effetto evidente sulla latenza della tua app, App Engine crea automaticamente una o più istanze nuove per gestire il carico crescente.

Puoi configurare le impostazioni per la scalabilità automatica in modo da ottenere un compromesso tra le prestazioni che vuoi e il costo che puoi sostenere. La seguente tabella descrive queste impostazioni.

Impostazioni di scalabilità automatica Descrizione
Utilizzo CPU target Imposta la soglia del rapporto di utilizzo della CPU per specificare la soglia di utilizzo della CPU in cui iniziare a gestire il traffico un maggior numero di istanze.
Utilizzo della velocità effettiva target Imposta la soglia di velocità effettiva per il numero di richieste in parallelo, trascorso il quale verranno avviate altre istanze per 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 Impostazioni scheduler di App Engine per vedere gli effetti di queste impostazioni.

Scalabilità verso il basso

Quando il volume delle richieste diminuisce, App Engine riduce il numero di istanze. Questa scalabilità verso il basso garantisce che tutte le istanze attuali delle tue applicazioni vengano utilizzate per un'efficienza e un rapporto costi efficienti.

Quando un'applicazione non viene utilizzata, App Engine disattiva le istanze dinamiche associate, ma le ricarica immediatamente non appena sono necessarie. Il ricaricamento delle istanze può comportare richieste di caricamento e ulteriore latenza 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 soddisfare ogni richiesta con poca latenza, a meno che non si verifichi un volume di richieste eccessivamente elevato.

Scalabilità verso il basso nella scalabilità automatica

Se l'applicazione utilizza la scalabilità automatica, sono necessari circa 15 minuti di inattività affinché le istanze inattive avviino l'arresto. 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 controllarlo limitando la frequenza del numero di richieste inviate al secondo, se possibile. Ad esempio, se utilizzi Tasks, puoi controllare la frequenza di push delle attività.

Ciclo di vita di un'istanza

Stati delle istanze

Un'istanza di un servizio con scalabilità automatica è sempre in esecuzione. Tuttavia, un'istanza di un servizio scalabile manuale può essere in esecuzione o arrestata. Tutte le istanze dello stesso servizio e la stessa versione condividono lo stesso stato. Modifica lo stato delle istanze gestendo le tue versioni. Puoi:

Startup

Ogni istanza di servizio viene creata in risposta a una richiesta di avvio, una richiesta HTTP GET vuota a /_ah/start. App Engine invia questa richiesta per rendere esistente un'istanza; gli utenti non possono inviare una richiesta a /_ah/start. Le istanze di 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 eseguito a tempo indeterminato, senza accettare ulteriori richieste.
  • Per inizializzare un'istanza prima che riceva traffico aggiuntivo.

Avvio manuale delle istanze di base, a scalabilità automatica e in modo diverso. Quando avvii un'istanza di 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à base vengono avviate solo secondo necessità per gestire un maggiore traffico. Le istanze con scalabilità automatica non ricevono richieste /_ah/start.

Quando un'istanza risponde alla richiesta /_ah/start con un codice di stato HTTP 200–299 o 404, si considera che sia stata avviata correttamente e sia in grado di gestire richieste aggiuntive. In caso contrario, App Engine termina l'istanza. Le istanze con scalabilità manuale vengono riavviate immediatamente, mentre le istanze con scalabilità di base vengono riavviate solo quando necessario per l'elaborazione del traffico.

Chiusura

Il processo di arresto potrebbe essere attivato da una serie di eventi pianificati e non pianificati, ad esempio:

  • Ci sono troppe istanze e un numero insufficiente di richieste di app (traffico).
  • Arresta manualmente un'istanza.
  • Esegui il deployment di una versione aggiornata nel servizio.
  • L'istanza supera la memoria massima per il relativo instance_class configurato.
  • L'applicazione ha esaurito la quota di ore di istanza.
  • L'istanza viene spostata in un'altra macchina perché la macchina in esecuzione su cui è in esecuzione l'istanza viene riavviata oppure App Engine ha spostato l'istanza per migliorare la distribuzione del carico.

Uno dei vantaggi dell'ambiente standard di App Engine è pagare solo per quello che ti serve, come descritto in precedenza in Scalabilità verso il basso, poiché il sistema scala automaticamente il numero di istanze fino a zero quando non c'è traffico. Ciò consente di rendere App Engine una soluzione economica per le applicazioni di piccole dimensioni che non ricevono richieste continue. Quando un'istanza deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre istanze (se presenti) e le richieste attualmente in fase di elaborazione hanno il tempo di completamento.

Di solito, App Engine invia un indicatore STOP (SIGTERM) al contenitore dell'app. La tua app non deve rispondere a questo evento, ma può utilizzarla per eseguire le azioni di pulizia necessarie prima che il container venga spento. In condizioni normali, il sistema attende fino a 3 secondi per l'arresto dell'app e poi invia un segnale KILL (SIGKILL). Se la tua app non acquisisce il segnale SIGTERM, l'istanza viene arrestata immediatamente.

Alcuni messaggi di log per la chiusura delle istanze che potresti visualizzare sono:

[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit

Questi messaggi di log non indicano alcuna condizione di errore, ma sono indicazioni del normale processo di arresto delle istanze. Tieni presente che [start] e Start nei log si riferiscono a un processo della piattaforma denominato start e non hanno nulla a che fare con l'avvio di un'istanza o un'app.

Caricamento richieste in corso...

Quando App Engine crea una nuova istanza per l'applicazione, questa deve prima caricare le librerie e le risorse necessarie per gestire la richiesta. Ciò si verifica durante la prima richiesta all'istanza, chiamata Caricamento richiesta. Durante una richiesta di caricamento, l'applicazione viene sottoposta all'inizializzazione, con un conseguente aumento della durata della richiesta.

Le seguenti best practice consentono di ridurre la durata delle richieste di caricamento:

  • Carica solo il codice necessario per l'avvio.
  • Accedi al disco il più presto possibile.
  • In alcuni casi, il caricamento del codice da un file ZIP o jar è più veloce del caricamento di diversi file separati.

Richieste di preparazione

Le richieste di preparazione sono un tipo specifico di richiesta di caricamento che carica in anticipo il codice dell'applicazione in un'istanza, prima di effettuare qualsiasi richiesta in tempo reale. Le istanze di scalabilità manuale o di base non ricevono una richiesta /_ah/warmup.

Per ulteriori informazioni su come utilizzare le richieste di preparazione, consulta la sezione Configurare le richieste di preparazione.

Tempo di attività istanza

App Engine tenta di mantenere in esecuzione le istanze con scalabilità manuale e di base a tempo indeterminato. Tuttavia, al momento non è garantito un tempo di attività garantito per le istanze con scalabilità manuale e di base.

NTP con ambiente standard di App Engine

L'ambiente standard di App Engine prevede servizi NTP (Network Time Protocol) che utilizzano i server NTP di Google. Tuttavia, il servizio NTP non è modificabile.