Modalità di gestione delle istanze

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

App Engine può creare e arrestare automaticamente le istanze in base al traffico, oppure puoi 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 la tua 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 (impostazione predefinita)
  • Base
  • Manuale

Specifica il tipo di scalabilità nella tua app app.yaml. Per impostazione predefinita, l'applicazione utilizza la scalabilità automatica, il che significa che App Engine gestisce 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 dell'applicazione. Puoi specificare le soglie per ciascuna di queste metriche, nonché un numero minimo di istanze da continuare a essere eseguito 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 il lavoro intermittente o guidato dall'attività utente.
Scalabilità manuale
La scalabilità manuale specifica il numero di istanze eseguite in modo continuo, indipendentemente dal livello di carico. Questo consente attività quali inizializzazioni complesse e applicazioni che si basano sullo stato della memoria nel tempo.
Questa tabella mette a confronto le funzionalità relative alle prestazioni dei tre tipi di scalabilità:

Funzionalità Scalabilità automatica Scalabilità di base Scalabilità manuale
Timeout della richiesta 10 minuti per le richieste HTTP e le attività in coda per le attività. Se l'app non restituisce una richiesta entro questo limite di tempo, App Engine interrompe il gestore delle richieste ed emette un errore per la gestione del codice.

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

  • Il timeout per le attività in coda delle attività e le richieste dai job cron è di 10 minuti.
  • Il timeout per le altre richieste HTTP è di 1 minuto.
 24 ore per le richieste HTTP e le attività in coda per le attività. Se l'app non restituisce una richiesta entro questo limite di tempo, App Engine interrompe il gestore delle richieste ed emette un errore per la gestione del codice.

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, viene arrestata. Le istanze rimangono in memoria e lo stato viene preservato nelle richieste. Quando le istanze vengono arrestate, nei log viene visualizzata una richiesta /_ah/stop. Se è presente un gestore /_ah/stop, il completamento ha 30 secondi prima dell'arresto.
Avvio e arresto Le istanze vengono create on demand per gestire le richieste e disattivate automaticamente quando inattive. Le istanze vengono create on demand per gestire le richieste e arrestate automaticamente quando inattivi, in base al parametro di configurazione idle_timeout. Un'istanza interrotta manualmente ha 30 secondi per terminare la gestione delle richieste prima che venga terminata forzatamente. Le istanze ricevono automaticamente una richiesta di avvio da App Engine sotto forma di una richiesta GET vuota a /_ah/start. Come con la scalabilità di base, un'istanza interrotta manualmente ha 30 secondi per terminare la gestione delle richieste prima che venga terminata forzatamente.
Indirizzabilità dell'istanza Le istanze sono anonime. Istanza "i" della versione "v" di 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 gestire un servizio o una delle sue istanze tramite un URL nel formato https://s.domain.com o https://i.s.domain.com. Puoi memorizzare lo stato nella cache in ogni istanza e recuperarlo 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à nelle impostazioni di automatic_scaling forniti in base alla versione nel file di configurazione. Un servizio con scalabilità di base è 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 conservata in memoria o alla velocità effettiva desiderata per il lavoro offline.

Scalabilità delle istanze dinamiche

Le applicazioni App Engine che utilizzano la scalabilità di base o automatica si basano su un numero qualsiasi di istanze dinamiche in un determinato momento, a seconda del volume di richieste in arrivo. Con l'aumento delle richieste per la tua applicazione, può aumentare 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 determinare una latenza maggiore con l'aumento 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 aver avviato una nuova istanza, potrebbe essere necessario mettere in coda alcune richieste fino al completamento del processo di avvio della nuova istanza. Se hai bisogno della latenza più bassa possibile, valuta la possibilità di utilizzare la scalabilità automatica, creando nuove istanze in modo preventivo per ridurre al minimo la latenza.

App con scalabilità automatica

Se utilizzi la scalabilità automatica, ogni istanza nella tua app ha una 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 in modo da ottenere un compromesso tra il rendimento desiderato e il costo che puoi sostenere. Nella tabella seguente vengono descritte le 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 verso la 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 verrà avviata un'altra istanza della gestione del traffico.
Max richieste simultanee 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 di 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. Questa scalabilità verso il basso contribuisce a garantire che tutte le istanze attuali della tua applicazione vengano utilizzate per un'efficienza e un'efficienza dei costi ottimali.

Quando un'applicazione non viene utilizzata, App Engine disattiva le istanze dinamiche associate, ma la ricarica rapidamente non appena necessario. Il ricaricamento delle istanze può comportare richieste di caricamento e 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 di richieste consente all'applicazione di gestire ogni richiesta con poca latenza, a meno che tu non stia riscontrando un volume di richieste insolitamente alto.

Scale down con scalabilità automatica

Se la tua app utilizza la scalabilità automatica, sono necessari circa 15 minuti di inattività prima che l'arresto delle istanze inattive inizi. Per mantenere in esecuzione una o più istanze di inattività, imposta il valore di min_idle_instances su 1 o 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, viene creato rapidamente un numero elevato di istanze. Ti consigliamo di controllare questo limite limitando il numero di richieste inviate al secondo, se possibile. Ad esempio, se utilizzi Tasks, puoi controllare la frequenza del push delle attività.

Ciclo di vita di un'istanza

Stati dell'istanza

Un'istanza di un servizio a scalabilità automatica è sempre in esecuzione. Tuttavia, un'istanza di un servizio scalato 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 versioni. Puoi:

Avvio

Ogni istanza di servizio viene creata in risposta a una richiesta di avvio, che è una richiesta HTTP GET vuota a /_ah/start. App Engine invia questa richiesta per creare un'istanza; gli utenti non possono inviare una richiesta a /_ah/start. Le istanze di scalabilità manuali e di base devono rispondere alla richiesta di avvio prima di poter gestire un'altra richiesta. La richiesta iniziale può essere utilizzata per due scopi:

  • Avviare un programma in esecuzione a tempo indeterminato, senza accettare ulteriori richieste.
  • Per inizializzare un'istanza prima di ricevere traffico aggiuntivo.

Avvio manuale delle istanze di base, di base e a scalabilità automatica 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à di base vengono avviate solo se necessario per gestire l'aumento del traffico. La scalabilità automatica delle istanze non riceve 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. In caso contrario, App Engine termina l'istanza. Le istanze di scalabilità manuale vengono riavviate immediatamente, mentre le istanze di scalabilità di base vengono riavviate solo quando è necessario per gestire il traffico.

Arresto

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

  • Sono presenti troppe istanze e richieste di app (traffico) insufficienti.
  • Puoi arrestare manualmente un'istanza.
  • Esegui il deployment di una versione aggiornata nel servizio.
  • L'istanza supera la memoria massima per la sua configurazione instance_class.
  • L'applicazione esaurisce la quota di ore di istanza.
  • L'istanza viene spostata su un'altra macchina, perché quella corrente che esegue l'istanza viene riavviata oppure perché 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 serve" 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. In questo modo, App Engine è una soluzione conveniente per piccole applicazioni 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 tempo da completare.

App Engine normalmente invia un segnale STOP (SIGTERM) al container dell'app. L'app non deve rispondere a questo evento, ma può utilizzarla per eseguire le azioni di pulizia necessarie prima dell'arresto del container. In condizioni normali, il sistema attende fino a 3 secondi l'arresto dell'app, quindi invia un segnale KILL (SIGKILL). Se la tua app non riesce a rilevare il segnale SIGTERM, l'istanza viene arrestata immediatamente.

Ecco alcuni messaggi di log della chiusura delle istanze:

[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 dell'istanza. Tieni presente che [start] e Start nei log fanno riferimento a un processo della piattaforma denominato start e non hanno nulla a che fare con l'avvio di un'istanza o un'app.

Caricamento delle richieste in corso...

Quando App Engine crea una nuova istanza per la tua applicazione, deve prima caricare le librerie e le risorse necessarie per gestire la richiesta. Questo si verifica durante la prima richiesta all'istanza, denominata richiesta di caricamento. Durante una richiesta di caricamento, l'applicazione viene sottoposta a un'inizializzazione, che richiede più tempo.

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

  • Carica solo il codice necessario per l'avvio.
  • Accedi al disco nel modo più breve possibile.
  • In alcuni casi, il caricamento del codice da un file ZIP o jar è più rapido rispetto al caricamento da molti file separati.

Richieste di riscaldamento

Le richieste di riscaldamento sono un tipo specifico di richiesta di caricamento che carica il codice dell'applicazione in anticipo su un'istanza prima che vengano effettuate richieste in tempo reale. Le istanze di scalabilità manuali o di base non ricevono una richiesta /_ah/warmup.

Per scoprire di più su come utilizzare le richieste di riscaldamento, consulta la sezione Configurare le richieste di riscaldamento.

Tempo di attività istanza

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

NTP con ambiente standard di App Engine

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