Questa guida fornisce un'introduzione all'ambiente flessibile per chi ha familiarità con l'ambiente standard. Spiega le somiglianze e le differenze principali tra gli ambienti e fornisce anche consigli di architettura generale per le applicazioni che utilizzano entrambi gli ambienti.
Per una mappatura dei servizi disponibili nell'ambiente standard ai relativi analoghi nell'ambiente flessibile, consulta Eseguire la migrazione dei servizi dall'ambiente standard all'ambiente flessibile.
Somiglianze e differenze principali
Entrambi gli ambienti forniscono l'infrastruttura di deployment, pubblicazione e scalabilità di App Engine. Le differenze principali riguardano il modo in cui l'ambiente esegue l'applicazione, il modo in cui l'applicazione accede ai servizi esterni, il modo in cui esegui l'applicazione localmente e il modo in cui l'applicazione viene scalata. Puoi anche consultare la sezione sulla scelta di un ambiente per un riepilogo generale di queste differenze.
Esecuzione dell'applicazione
Nell'ambiente standard, l'applicazione viene eseguita su un'istanza leggera all'interno di una sandbox. Questa sandbox limita le azioni che la tua applicazione può svolgere. Ad esempio, la sandbox consente alla tua app di utilizzare solo un insieme limitato di librerie di codice binario e la tua app non può scrivere su disco. L'ambiente standard limita inoltre le opzioni di CPU e memoria disponibili per l'applicazione. A causa di queste limitazioni, la maggior parte delle applicazioni standard di App Engine tende a essere applicazioni web stateless che rispondono rapidamente alle richieste HTTP.
Al contrario, l'ambiente flessibile esegue l'applicazione in container Docker su macchine virtuali (VM) Google Compute Engine, che hanno meno limitazioni. Ad esempio, puoi utilizzare qualsiasi linguaggio di programmazione, scrivere sul disco, utilizzare qualsiasi libreria e persino eseguire più processi. L'ambiente flessibile ti consente anche di scegliere qualsiasi tipo di macchina Compute Engine per le tue istanze in modo che la tua applicazione abbia accesso a più memoria e CPU.
Accesso a servizi esterni
Nell'ambiente standard, l'applicazione in genere accede a servizi come Datastore tramite le API google.appengine integrate. Tuttavia, in nell'ambiente flessibile, queste API non sono più disponibili. Utilizza invece le librerie client di Google Cloud. Queste librerie client funzionano ovunque, il che significa che la tua applicazione è più portabile. Se necessario, le applicazioni in esecuzione nell'ambiente flessibile possono essere eseguite su Google Kubernetes Engine o Compute Engine senza modifiche sostanziali.
Sviluppo locale
Nell'ambiente standard, in genere esegui l'applicazione localmente utilizzando
l'SDK App Engine. L'SDK gestisce l'esecuzione dell'applicazione ed emula i servizi App Engine. Nell'ambiente flessibile, l'SDK non viene più utilizzato per eseguire l'applicazione. Le applicazioni scritte per l'ambiente flessibile devono invece essere scritte come applicazioni web standard che possono essere eseguite ovunque. Come accennato, l'ambiente flessibile esegue semplicemente l'applicazione in un container Docker. Ciò significa che per testare l'applicazione localmente, devi semplicemente eseguire direttamente l'applicazione. Ad esempio, per eseguire un'applicazione Python utilizzando Django, devi eseguire python manage.py runserver.
Un'altra differenza fondamentale è che le applicazioni per ambiente flessibile in esecuzione localmente utilizzano i servizi effettivi della piattaforma Cloud, come Datastore. Utilizza un progetto distinto per i test locali e, se disponibili, gli emulatori.
Caratteristiche di scalabilità
Sebbene entrambi gli ambienti utilizzino l'infrastruttura di scalabilità automatica di App Engine, il modo in cui eseguono la scalabilità è diverso. L'ambiente standard può scalare da zero a migliaia di istanze molto rapidamente. Al contrario, l'ambiente flessibile deve avere almeno un'istanza in esecuzione per ogni versione attiva e può richiedere più tempo per eseguire lo scale out in risposta al traffico.
L'ambiente standard utilizza un algoritmo di scalabilità automatica progettato su misura. L'ambiente flessibile utilizza Autoscaler di Compute Engine. Tieni presente che l'ambiente flessibile non supporta tutte le opzioni di scalabilità automatica disponibili per Compute Engine. App Engine rispetta le prenotazioni di VM Compute Engine che hai già in una regione e che corrispondono alla tua configurazione. Avere una prenotazione VM aumenta la probabilità di ricevere un'allocazione di risorse durante una carenza temporanea di risorse.
Gli sviluppatori devono testare il comportamento della propria applicazione in una serie di condizioni. Ad esempio, devi verificare come risponde la scalabilità automatica quando un'applicazione vincolata alla CPU diventa vincolata all'I/O durante i periodi in cui le chiamate ai servizi remoti hanno una latenza elevata.
Controlli di integrità
L'ambiente standard non utilizza i controlli di integrità per determinare se inviare o meno il traffico a un'istanza. L'ambiente flessibile consente agli sviluppatori di applicazioni di scrivere i propri gestori controllo di integrità che verranno utilizzati dal bilanciatore del carico per determinare se inviare o meno traffico a un'istanza e se deve essere riparata automaticamente. Gli sviluppatori devono prestare attenzione quando aggiungono logica ai controlli di salute. Ad esempio, se il controllo di integrità effettua una chiamata a un servizio esterno, un errore temporaneo in quel servizio può causare il malfunzionamento di tutte le istanze, con possibile conseguente errore a cascata.
Rifiutare le richieste in caso di sovraccarico
Le applicazioni possono ignorare le richieste in caso di sovraccarico nell'ambito di una strategia per evitare errori a cascata. Questa funzionalità è integrata nel livello di routing del traffico nell'ambiente standard. Consigliamo agli sviluppatori di applicazioni con un QPS molto elevato nell'ambiente flessibile di implementare questa funzionalità per ridurre il traffico in sovraccarico nelle loro applicazioni limitando il numero di richieste simultanee.
Puoi verificare che l'applicazione dell'ambiente flessibile non sia soggetta a questo tipo di errore creando una versione con un limite al numero massimo di istanze. Poi aumenta gradualmente il traffico finché le richieste non vengono ignorate. Devi assicurarti che la tua applicazione non non superi i controlli di integrità durante il sovraccarico.
Per Java, le app Java che utilizzano il runtime Jetty possono configurare il filtro Qualità del servizio per implementare il sovraccarico di drop. Con questa funzionalità puoi impostare il numero massimo di richieste in parallelo gestite dalle app e la durata della coda delle richieste.
Dimensioni delle istanze
Le istanze dell'ambiente flessibile possono avere limiti di CPU e memoria superiori a quelli possibili con le istanze dell'ambiente standard. In questo modo, le istanze flessibili possono eseguire applicazioni che richiedono una maggiore quantità di memoria e CPU. Tuttavia, potrebbe aumentare la probabilità di bug di concorrenza a causa dell'aumento dei thread all'interno di una singola istanza.
Gli sviluppatori possono eseguire SSH su un'istanza di ambiente flessibile e ottenere un dump del thread per risolvere questo tipo di problema.
Ad esempio, se utilizzi il runtime Java, puoi eseguire quanto segue:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Timeout massimo della richiesta
Anche se il timeout delle richieste dell'ambiente standard varia in base al tipo di scalabilità selezionato, l'ambiente flessibile impone sempre un timeout di 60 minuti. Per evitare di lasciare le richieste aperte per l'intera durata di 60 minuti e di utilizzare potenzialmente tutti i thread sul server web:
Quando effettui chiamate a servizi esterni, specifica un timeout.
Implementa un filtro servlet per interrompere le richieste che richiedono un tempo inaccettabilmente lungo, ad esempio 60 secondi. Assicurati che l'app possa tornare a uno stato coerente dopo che il filtro ha interrotto una richiesta.
Gestione dei thread
I runtime Java dell'ambiente standard precedenti a Java 8 potevano utilizzare solo thread creati utilizzando l'SDK dell'ambiente standard di App Engine. Gli sviluppatori che eseguono il porting di un'applicazione da un ambiente di runtime Java standard di prima generazione a un ambiente flessibile devono passare all'utilizzo di librerie di thread native. Le applicazioni che richiedono un numero molto elevato di thread potrebbero essere eseguite in modo più efficiente con i pool di thread rispetto alla creazione esplicita dei thread.
Migrazione del traffico
L'ambiente standard fornisce una funzionalità di migrazione del traffico che sposta gradualmente il traffico in una nuova versione per ridurre al minimo i picchi di latenza. Consulta la documentazione sulla migrazione del traffico per scoprire come evitare un picco di latenza quando trasferisci il traffico a una nuova versione.
Errori relativi a una singola zona
Le applicazioni con ambiente standard sono monohome, il che significa che tutte le istanze dell'applicazione si trovano in un'unica zona di disponibilità. In caso di errore in quella zona, l'applicazione avvia nuove istanze in un'altra zona della stessa regione e il bilanciatore del carico instrada il traffico alle nuove istanze. Verrà visualizzato un picco di latenza a causa delle richieste di caricamento e di un aggiornamento Memcache.
Le applicazioni per ambienti flessibili utilizzano i gruppi di istanze gestite a livello di regione, il che significa che le istanze sono distribuite tra più zone di disponibilità all'interno di una regione. In caso di guasto di una singola zona, il bilanciatore del carico interrompe il routing del traffico verso quella zona. Se hai impostato la scalabilità automatica in modo da eseguire le istanze il più caldo possibile, verrà visualizzato un breve periodo di sovraccarico prima che la scalabilità automatica crei altre istanze.
Confronti dei costi
Un confronto dei costi tra i carichi di lavoro eseguiti in ambienti standard e flessibili coinvolge molti fattori. Queste includono:
- Prezzo pagato per MCycle.
- Funzionalità della piattaforma CPU, che influiscono sul lavoro che può essere svolto per ogni ciclo M
- La quantità di istanze che puoi eseguire su ogni piattaforma.
- Costo dei deployment, che può variare su ogni piattaforma e può essere significativo se utilizzi il deployment continuo per la tua applicazione.
- Overhead del runtime.
Dovrai eseguire esperimenti per determinare il costo del tuo carico di lavoro su ogni piattaforma. In un ambiente flessibile, puoi utilizzare le QPS per core come sostituto dell'efficienza in termini di costi della tua applicazione quando esegui esperimenti per determinare se una modifica ha un impatto sui costi. L'ambiente standard non fornisce un simile meccanismo per ottenere metriche in tempo reale sull'efficienza in termini di costi della tua applicazione. Devi apportare una modifica e attendere il completamento del ciclo di fatturazione giornaliero.
Microservizi
L'ambiente standard consente l'autenticazione sicura tra le applicazioni che utilizzano l'intestazione della richiesta X-Appengine-Inbound-Appid. L'ambiente flessibile non dispone di questa funzionalità. L'approccio consigliato per l'autenticazione sicura tra le applicazioni è l'utilizzo di OAuth.
Deployment
I deployment in ambiente standard sono generalmente più rapidi rispetto a quelli in ambiente flessibile. È più veloce eseguire l'upgrade di una versione esistente in un ambiente flessibile rispetto al deployment di una nuova versione, perché la programmazione di rete per una nuova versione è in genere la parte più lunga del deployment in un ambiente flessibile. Una strategia per eseguire rollback rapidi in un ambiente flessibile è mantenere una versione nota buona scalata a una singola istanza. Puoi quindi eseguire l'upgrade di questa versione e indirizzare tutto il traffico utilizzando la suddivisione del traffico.
Quando utilizzare l'ambiente flessibile
L'ambiente flessibile è pensato per essere complementare all'ambiente standard. Se hai un'applicazione esistente in esecuzione nell'ambiente standard, in genere non è necessario eseguire la migrazione dell'intera applicazione nell'ambiente flessibile. Identifica invece le parti dell'applicazione che richiedono più CPU, più RAM, una libreria o un programma di terze parti specializzati o che devono eseguire azioni non possibili nell'ambiente standard. Una volta identificate queste parti dell'applicazione, crea piccoli servizi App Engine che utilizzano l'ambiente flessibile per gestire solo queste parti. Il servizio esistente in esecuzione nell'ambiente standard può chiamare gli altri servizi utilizzando HTTP, Cloud Tasks o Cloud Pub/Sub.
Ad esempio, se hai un'applicazione web esistente in esecuzione nell'ambiente standard e vuoi aggiungere una nuova funzionalità per convertire i file in PDF, puoi scrivere un microservizio separato che funzioni nell'ambiente flessibile e gestisca solo la conversione in PDF. Questo microservizio può essere un semplice programma costituito da uno o due gestori delle richieste. Questo microservizio può installare e utilizzare qualsiasi programma Linux disponibile per facilitare la conversione, ad esempio unoconv.
L'applicazione principale rimane nell'ambiente standard e può chiamare questo microservizio direttamente tramite HTTP oppure, se prevedi che la conversione impiegherà molto tempo, l'applicazione può utilizzare Cloud Tasks o Pub/Sub per mettere in coda le richieste.