Questa guida fornisce un'introduzione all'ambiente flessibile per chi ha familiarità con l'ambiente standard. Spiega le somiglianze e le principali differenze tra gli ambienti e fornisce anche suggerimenti generali sull'architettura per le applicazioni che utilizzano entrambi gli ambienti.
Per una mappatura dei servizi disponibili nell'ambiente standard ai loro analoghi nell'ambiente flessibile, consulta Migrazione dei servizi dall'ambiente standard all'ambiente flessibile.
Somiglianze e differenze principali
Entrambi gli ambienti forniscono l'infrastruttura di deployment, gestione e scalabilità di App Engine. Le differenze principali sono il modo in cui l'ambiente esegue l'applicazione, il modo in cui l'applicazione accede ai servizi esterni, il modo in cui l'applicazione viene eseguita localmente e la scalabilità dell'applicazione. 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 attività dell'applicazione. Ad esempio, consente alla tua app di utilizzare solo un insieme limitato di librerie binarie e l'app non può scrivere su disco. L'ambiente standard limita anche le opzioni di CPU e memoria disponibili per la tua applicazione. A causa di queste restrizioni, la maggior parte delle applicazioni standard di App Engine tendono 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 restrizioni. Ad esempio, puoi usare qualsiasi linguaggio di programmazione, scrivere su disco, utilizzare qualsiasi libreria e persino eseguire più processi. L'ambiente flessibile consente inoltre di scegliere qualsiasi tipo di macchina Compute Engine per le tue istanze, in modo che l'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, 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 in genere essere eseguite su Google Kubernetes Engine o Compute Engine senza modifiche pesanti.
Sviluppo locale
Nell'ambiente standard, in genere l'applicazione viene eseguita localmente utilizzando l'SDK di 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. Invece, le applicazioni scritte per l'ambiente flessibile
devono essere scritte come applicazioni web standard, eseguibili ovunque. Come detto, l'ambiente flessibile esegue semplicemente l'applicazione in un container Docker. Ciò significa che per testare l'applicazione in locale, è sufficiente eseguirla direttamente. Ad esempio, per eseguire un'applicazione Python utilizzando Django, è sufficiente eseguire python manage.py runserver.
Un'altra differenza fondamentale è che le applicazioni in ambiente flessibile eseguite in locale usano i servizi effettivi della piattaforma Cloud, come Datastore. Utilizza un progetto separato per i test in locale e, se disponibile, utilizza gli emulatori.
Caratteristiche di scalabilità
Sebbene entrambi gli ambienti utilizzino l'infrastruttura di scalabilità automatica di App Engine, il modo in cui vengono scalati è diverso. L'ambiente standard consente di scalare da zero fino a migliaia di istanze in tempi rapidissimi. Al contrario, l'ambiente flessibile deve avere almeno un'istanza in esecuzione per ogni versione attiva e può richiedere più tempo per lo scale out in risposta al traffico.
L'ambiente standard utilizza un algoritmo di scalabilità automatica personalizzato. L'ambiente flessibile utilizza il scaler automatico di Compute Engine. Tieni presente che l'ambiente flessibile non supporta tutte le opzioni di scalabilità automatica disponibili per Compute Engine. Gli sviluppatori dovrebbero testare il comportamento dell'applicazione in base a una serie di condizioni. Ad esempio, devi verificare la risposta della scalabilità automatica quando un'applicazione collegata alla CPU passa a I/O durante i periodi in cui le chiamate ai servizi remoti presentano 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 per il 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 fare attenzione quando aggiungono logica ai controlli di integrità. Ad esempio, se il controllo di integrità effettua una chiamata a un servizio esterno, un errore temporaneo in quel servizio può causare lo stato non integro di tutte le istanze, causando un errore a cascata.
Eliminazione delle richieste in caso di sovraccarico
Le applicazioni possono ignorare le richieste se sovraccaricate come parte 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 valore di QPS molto elevato nell'ambiente flessibile di creare questa funzionalità per ridurre il traffico di sovraccarico nelle applicazioni limitando il numero di richieste in parallelo.
Per verificare che la tua applicazione nell'ambiente flessibile non sia suscettibile a questo tipo di errore, crea una versione con un limite al numero massimo di istanze. Poi aumenta costantemente il traffico finché le richieste non vengono ignorate. Devi assicurarti che la tua applicazione non superi i controlli di integrità durante il sovraccarico.
Per Java, le app Java che utilizzano il runtimeJetty possono configurare il filtro Quality of Service per implementare il sovraccarico di abbandono. Puoi impostare il numero massimo di richieste in parallelo gestite dalle app e il periodo di tempo per cui le richieste verranno messe in coda utilizzando questa funzionalità.
Dimensioni istanza
Le istanze dell'ambiente flessibile possono avere limiti di CPU e memoria più elevati rispetto alle istanze dell'ambiente standard. Ciò consente alle istanze flessibili di eseguire applicazioni che utilizzano molta memoria e CPU. Tuttavia, potrebbe aumentare la probabilità di bug di contemporaneità dovuti all'aumento dei thread all'interno di una singola istanza.
Gli sviluppatori possono eseguire l'SSH su un'istanza di ambiente flessibile e ottenere un thread dump 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
Mentre il timeout della richiesta per l'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 tutti i 60 minuti e di esaurire potenzialmente tutti i thread sul server web:
Quando effettui chiamate a servizi esterni, specifica un timeout.
Implementa un filtro servlet per arrestare le richieste che richiedono un tempo inaccettabilmente lungo, ad esempio 60 secondi. Assicurati che la tua app possa tornare a uno stato coerente dopo che il filtro interrompe 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 portano un'applicazione dal runtime dell'ambiente standard Java di prima generazione all'ambiente flessibile devono passare alle librerie 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 di thread.
Migrazione del traffico
L'ambiente standard offre una funzionalità di migrazione del traffico che sposta gradualmente il traffico a 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 si passa a una nuova versione.
Errori a zona singola
Le applicazioni dell'ambiente standard sono su una casa singola, il che significa che tutte le istanze dell'applicazione risiedono in un'unica zona di disponibilità. In caso di errore in quella zona, l'applicazione avvia nuove istanze in una zona diversa nella stessa regione e il bilanciatore del carico instrada il traffico alle nuove istanze. Vedrai un picco di latenza dovuto alle richieste di caricamento e anche lo svuotamento di Memcache.
Le applicazioni in ambiente flessibile utilizzano gruppi di istanze gestite a livello di regione, ovvero le istanze sono distribuite tra più zone di disponibilità all'interno di una regione. In caso di errore di una singola zona, il bilanciatore del carico interrompe il routing del traffico a quella zona. Se hai impostato la scalabilità automatica per eseguire le istanze al massimo livello possibile, noterai un breve periodo di sovraccarico prima che la scalabilità automatica crei altre istanze.
Confronti di costi
In un confronto dei costi tra i carichi di lavoro in esecuzione in ambienti standard e flessibili sono coinvolti molti fattori. Queste includono:
- Prezzo pagato per ciclo di fatturazione.
- Capacità della piattaforma CPU, con un impatto sul lavoro eseguibile per ciclo
- Livello di temperatura per l'esecuzione delle istanze su ogni piattaforma.
- Costo dei deployment, che può variare da una piattaforma all'altra e può essere significativo se utilizzi il deployment continuo per la tua applicazione.
- Overhead del runtime.
Dovrai eseguire esperimenti per determinare il costo del carico di lavoro su ogni piattaforma. Nell'ambiente flessibile, puoi utilizzare QPS per core come proxy per l'efficienza in termini di costi dell'applicazione durante l'esecuzione di esperimenti per determinare se una modifica ha un impatto sui costi. L'ambiente standard non fornisce un meccanismo di questo tipo per ottenere metriche in tempo reale sull'efficienza dei 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 utilizzando l'intestazione della richiesta X-Appengine-Inbound-Appid. L'ambiente flessibile non offre una funzionalità di questo tipo. L'approccio consigliato per l'autenticazione sicura tra le applicazioni è utilizzare OAuth.
Deployment
I deployment nell'ambiente standard sono generalmente più veloci dei deployment nell'ambiente flessibile. È più veloce fare lo scale up di una versione esistente in un ambiente flessibile piuttosto che il deployment di una nuova versione, perché la programmazione di rete per una nuova versione è di solito il polo lungo in un deployment in un ambiente flessibile. Una strategia per eseguire rollback rapidi nell'ambiente flessibile è mantenere una versione valida nota scalata verso il basso su una singola istanza. Puoi fare lo scale up di quella versione e instradarvi 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, di solito 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 che non sono possibili nell'ambiente standard. Una volta identificate queste parti dell'applicazione, crea piccoli servizi App Engine che utilizzino l'ambiente flessibile per gestire solo quelle parti. Il tuo 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 viene eseguito nell'ambiente flessibile che gestisce solo la conversione in PDF. Questo microservizio può essere un semplice programma costituito da uno o due gestori di 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 richiederà molto tempo, l'applicazione può utilizzare Cloud Tasks o Pub/Sub per mettere in coda le richieste.