Questa pagina è stata tradotta dall'API Cloud Translation.

Modalità di gestione delle istanze

Le istanze sono i componenti di base di App Engine, fornendo tutte le e le risorse necessarie per ospitare l'applicazione. In qualsiasi momento, i tuoi l'applicazione può essere in esecuzione su una o più istanze e le richieste vengono in tutti. Ogni istanza include un livello di sicurezza per garantire che le istanze non possano influire inavvertitamente l'una sull'altra.

App Engine può creare e arrestare automaticamente le istanze come traffico fluttua oppure puoi specificare il numero di istanze da eseguire a prescindere una certa quantità di traffico. Per determinare come e quando vengono create nuove istanze, e specificare un tipo di scalabilità per la tua app. Le impostazioni di scalabilità vengono applicate Livello di versione di App Engine come parte di 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)
Di base
Manuale

Puoi specificare il tipo di scalabilità nel app.yaml Per impostazione predefinita, la tua app utilizza la scalabilità automatica, il che significa che App Engine e gestire 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 mantenere in esecuzione in ogni momento, configurando l'elemento automatic_scaling.

Scalabilità di base: La scalabilità di base crea istanze quando l'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à utente.

Scalabilità manuale: La scalabilità manuale specifica il numero di istanze che vengono eseguite continuamente a prescindere dal livello di carico. Ciò consente attività come inizializzazioni complesse e applicazioni che si basano sullo stato della memoria nel tempo.

Questa tabella mette a confronto le caratteristiche prestazionali dei tre tipi di scalabilità:

Funzionalità	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 restituiscono una richiesta entro questo limite di tempo, App Engine interrompe il gestore delle richieste emessi un errore da gestire. Per i runtime legacy (Java 8, PHP 5 e Python 2): Il timeout per le attività in coda di attività e le richieste dai cron job è 10 minuti. Il timeout per le altre richieste HTTP è di 1 minuto.	24 ore per richieste HTTP e attività in coda di attività. Se la tua app non che restituisce una richiesta entro questo limite di tempo, App Engine interrompe gestore delle richieste emessi un errore 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.	Come la scalabilità di base.
Thread in background (solo Java)	Non consentito	Consentito	Consentito
Residenza	Le istanze vengono arrestate in base ai pattern di utilizzo.	Le istanze vengono arrestate in base al `idle_timeout` . Se un'istanza è inattiva, ad esempio non ha ricevuto una richiesta per più di `idle_timeout`, viene chiusa.	Le istanze rimangono in memoria e lo stato viene mantenuto tra le richieste. Quando vengono arrestate, compare una richiesta `/_ah/stop` nei log. Se è presente un gestore `/_ah/stop` o un hook di arresto registrato (Java, Python), ha 30 secondi di tempo per completare l'operazione prima dell'arresto.
Avvio e arresto	Le istanze vengono create on demand per gestire le richieste e, quando il dispositivo è inattivo.	Le istanze vengono create on demand per gestire le richieste e, si arresta in caso di inattività, in base a `idle_timeout` di configurazione del deployment. Un'istanza interrotto manualmente ha 30 secondi di tempo per completare la gestione delle richieste prima che venga forzata terminato.	App Engine invia automaticamente alle istanze una richiesta di avvio sotto forma di richiesta GET vuota a `/_ah/start`. Come con la scalabilità di base, un'istanza interrotto manualmente ha 30 secondi di tempo per completare la gestione delle richieste prima che venga forzata terminato.
Indirizzabilità delle istanze	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 del tipo `https://s.domain.com` o `https://i.s.domain.com`. Puoi memorizzare nella cache in modo affidabile lo stato di ogni istanza e recuperarlo richieste successive.	Uguale alla scalabilità di base.
Scalabilità	App Engine scala il numero di istanze automaticamente in risposta di elaborazione. Questo fattore di scala tiene conto delle impostazioni `automatic_scaling` fornite su base di 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`. È scalabile il numero di istanze attive con il volume di elaborazione.	Configuri il numero di istanze di ogni versione di configurazione del servizio. In genere, il numero di istanze corrisponde alle dimensioni di un set di dati memorizzato in memoria o alla velocità effettiva desiderata per il lavoro offline.

Scalabilità delle istanze dinamiche

Le applicazioni App Engine che usano la scalabilità di base o automatica si basano da un numero qualsiasi di istanze dinamiche in un determinato momento, a seconda del volume richieste in arrivo. Con l'aumento delle richieste, il numero di possono aumentare anche le istanze dinamiche.

App con scalabilità di base

Se utilizzi la scalabilità di base, App Engine tenta di mantenere basso il costo, 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 aver avviato una nuova istanza, alcune richieste potrebbero dover essere messe in coda fino a quando la nuova istanza non completa l'avvio . Se hai bisogno della latenza più bassa possibile, valuta l'utilizzo della scalabilità automatica, il che crea preventivamente nuove istanze per ridurre al minimo la latenza.

App con scalabilità automatica

Se utilizzi la scalabilità automatica, ogni istanza della tua app ha la propria coda per le richieste in arrivo. Prima che le code diventino abbastanza lunghe da avere un effetto significativo sulla latenza della tua app, App Engine crea automaticamente una o più nuove istanze per gestire il carico crescente.

Puoi configurare le impostazioni della scalabilità automatica in modo da ottenere un compromesso tra le prestazioni desiderate e il costo che puoi sostenere. La tabella seguente 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 a cui verranno avviate altre istanze per gestire il traffico.
Utilizzo 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 di Scheduler di App Engine per vedere gli effetti di queste impostazioni.

Scale down

Quando i volumi di richieste diminuiscono, App Engine riduce il numero di istanze. La scalabilità verso il basso aiuta a garantire che tutte le applicazioni vengono 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 immediatamente non appena vengono necessaria. 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'adeguata di istanze inattive per la tua applicazione in base al volume di richieste consente alla tua applicazione di gestire ogni richiesta con poca latenza, a meno che tu quando un volume di richieste è insolitamente elevato.

Scale down nella scalabilità automatica

Se la tua app utilizza la scalabilità automatica, sono necessari circa 15 minuti di inattività, per iniziare l'arresto delle istanze inattive. Per mantenere uno o più istanze inattive in esecuzione, imposta il valore di min_idle_instances a 1 o successiva.

Scalabilità e batch di richieste

Se invii batch di richieste ai tuoi servizi, ad esempio per un'attività di elaborazione, verrà creato rapidamente un numero elevato di istanze. Ti consigliamo di controllarlo limitando il numero di richieste inviate al secondo, se possibile. Ad esempio, se utilizzi Google Tasks, puoi controllare la frequenza con cui le attività vengono inviato tramite push.

Ciclo di vita di un'istanza

Stati istanza

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

Utilizzare la pagina Versioni nella console Google Cloud
Usa gcloud app versions start e gcloud app versions stop

Avvio

Ogni istanza di servizio viene creata in risposta a una richiesta di avvio, ovvero richiesta GET HTTP vuota in /_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à manuale e di base devono rispondere alla richiesta di inizio prima di poter gestire un'altra richiesta. La richiesta di avvio può essere utilizzata per due scopi:

Per avviare un programma che viene eseguito 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 inizi un'istanza con il ridimensionamento manuale, App Engine invia immediatamente una richiesta /_ah/start a ogni istanza. Quando si avvia un'istanza di un modello di scalabilità automatica, App Engine consente di accettare il traffico, La richiesta /_ah/start non viene inviata a un'istanza finché non riceve il primo utente richiesta. Vengono avviate più istanze di scalabilità di base solo se necessario per gestire l'aumento del traffico. La scalabilità automatica delle istanze ricevere qualsiasi richiesta di /_ah/start.

Quando un'istanza risponde alla richiesta /_ah/start con un codice di stato HTTP di 200–299 o 404, viene considerato avviato correttamente e può per gestire richieste aggiuntive. In caso contrario, App Engine termina l'istanza. Le istanze con scalabilità manuale vengono riavviate immediatamente, mentre Le istanze di scalabilità vengono riavviate solo quando necessario per gestire il traffico.

Arresto

Il processo di chiusura può essere attivato da una serie di eventi eventi quali:

Esistono troppe istanze e non sono presenti richieste di app sufficienti (traffico).
Arresti manualmente un'istanza.
Esegui il deployment di una versione aggiornata nel servizio.
L'istanza supera la memoria massima per la sua configurazione instance_class
La quota di ore di istanze dell'applicazione è esaurita.
L'istanza viene spostata su un'altra macchina perché la macchina corrente su cui è in esecuzione l'istanza è stata riavviata o perché App Engine ha spostato l'istanza per migliorare la distribuzione del carico.

Uno dei vantaggi dell'ambiente standard di App Engine "paghi solo per quello che utilizzi" come piattaforma descritto in precedenza in Scalabilità orizzontale, il sistema esegue la scalabilità automatica. il numero di istanze fino a zero in assenza di traffico. Ciò consente di rendere App Engine è una soluzione conveniente per le piccole applicazioni che non ricevono e richieste continue. Quando un'istanza deve essere arrestata, le nuove istanze vengono instradate ad altre istanze (se presenti) e le richieste attualmente in fase di elaborazione hanno il tempo di essere completati.

Di solito App Engine invia un segnale STOP (SIGTERM) al contenitore di app. L'app non deve rispondere a questo evento, ma può utilizzarlo per eseguire eventuali azioni di pulizia necessarie prima dell'arresto del contenitore. In condizioni normali, il sistema attende fino a 3 secondi che l'app si arresti e poi invia un segnale KILL (SIGKILL). Se l'app non rileva il segnale SIGTERM, l'istanza viene arrestata immediatamente.

Ecco alcuni messaggi di log di arresto dell'istanza che potresti visualizzare:

[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 di il 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 di un'app.

Caricamento delle richieste in corso...

Quando App Engine crea una nuova istanza per l'applicazione, l'istanza deve prima caricare le librerie e le risorse necessarie richiesta. Questo accade durante la prima richiesta all'istanza, chiamata Richiesta di caricamento. Durante una richiesta di caricamento, l'applicazione viene sottoposta una inizializzazione che fa sì che la richiesta richieda più tempo.

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 al caricamento da molti file separati.

Richieste di riscaldamento

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

Per scoprire di più su come utilizzare le richieste di warmup, consulta Configurazione delle richieste di warmup.

Tempo di attività istanza

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

NTP con l'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.

Gestisci servizi

A seconda del tipo di scalabilità dell'istanza, puoi gestire i servizi e le versioni nella console Google Cloud o in Google Cloud CLI.

Interrompere una versione

Ogni versione in App Engine viene eseguita all'interno di una o più istanze, a seconda per gestire il volume di traffico che l'hai configurato.

Fai clic sulla scheda per istruzioni sull'utilizzo dello strumento che preferisci:

Console

Per arrestare o disabilitare una versione per il tuo servizio:

Vai alla pagina Versioni di App Engine nella console Google Cloud:

Vai a Versioni
Seleziona una versione dalla tabella e fai clic su Arresta.

gcloud

Esegui questo comando:

  gcloud app versions stop --service=SERVICE VERSION

Sostituisci:

SERVICE con il nome del tuo servizio.
VERSION con il nome della versione del servizio.

Elimina un servizio

Ogni servizio può essere configurato per utilizzare runtime diversi e operare con impostazioni di prestazioni diverse. Non puoi eliminare il servizio predefinito. L'eliminazione di un servizio comporta anche l'eliminazione di tutte le relative versioni nel progetto.