Questa guida fornisce un'introduzione all'ambiente flessibile per coloro che conoscono l'ambiente standard. Illustra le analogie e le principali differenze tra gli ambienti e fornisce inoltre consigli generali sull'architettura per le applicazioni che utilizzano entrambi gli ambienti.
Per una mappatura dei servizi disponibili nell'ambiente standard ai relativi analoghi nell'ambiente flessibile, vedi Migrazione dei servizi dall'ambiente standard all'ambiente flessibile.
Analogie e differenze chiave
Entrambi gli ambienti ti forniscono il deployment, la gestione e la scalabilità di App Engine. Le differenze principali sono il modo in cui l'ambiente esegue l'applicazione, come l'applicazione accede ai servizi esterni, come viene eseguita localmente l'applicazione e come viene scalata l'applicazione. Per un riepilogo generale di queste differenze, puoi anche consultare la sezione sulla scelta di un ambiente.
Esecuzione dell'applicazione
Nell'ambiente standard, l'applicazione viene eseguita in un'istanza leggera all'interno di una sandbox. Questa sandbox limita le operazioni consentite dall'applicazione. Ad esempio, la sandbox consente all'applicazione 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 l'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 la tua applicazione nei container Docker sulle macchine virtuali (VM) di Google Compute Engine, che hanno meno restrizioni. Ad esempio, puoi utilizzare qualsiasi linguaggio di programmazione a tua scelta, scrivere su disco, utilizzare la libreria che preferisci ed eseguire anche più processi. L'ambiente flessibile consente inoltre di scegliere qualsiasi tipo di macchina di Compute Engine per le istanze, in modo che l'applicazione abbia accesso a più memoria e CPU.
Accesso a servizi esterni
Nell'ambiente standard, l'applicazione accede in genere 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, pertanto la tua applicazione è più portabile. Se necessario, le applicazioni eseguite nell'ambiente flessibile di solito possono essere eseguite su Google Kubernetes Engine o Compute Engine senza modifiche significative.
Sviluppo locale
Nell'ambiente standard, in genere si esegue l'applicazione in locale utilizzando l'SDK di App Engine. L'SDK gestisce l'esecuzione dell'applicazione e emula i servizi App Engine. Nell'ambiente flessibile, l'SDK non viene più utilizzato per eseguire la tua applicazione. Invece, le applicazioni scritte per l'ambiente flessibile
devono essere scritte come applicazioni web standard che possono essere eseguite ovunque. Come
indicato, l'ambiente flessibile esegue la tua applicazione solo in un container
Docker. Ciò significa che per testare l'applicazione in locale è sufficiente eseguirla
direttamente. Ad esempio, per eseguire un'applicazione Python con Django, dovresti semplicemente eseguire python manage.py runserver.
Un'altra differenza fondamentale è che le applicazioni dell'ambiente flessibile in esecuzione localmente utilizzano i servizi Cloud Platform effettivi, come Datastore. Utilizza un progetto separato per i test localmente e, quando disponibili, utilizza gli emulatori.
Caratteristiche di scalabilità
Sebbene entrambi gli ambienti utilizzino l'infrastruttura di scalabilità automatica di App Engine, il modo in cui si ridimensionano è diverso. L'ambiente standard è in grado di scalare da zero istanze fino a migliaia di istanze molto rapidamente. Per contro, l'ambiente flessibile deve avere almeno un'istanza in esecuzione per ogni versione attiva e può richiedere più tempo per scalare in risposta al traffico.
L'ambiente standard utilizza un algoritmo di scalabilità automatica progettato su misura. L'ambiente flessibile utilizza il scalatore automatico di Compute Engine. Tieni presente che l'ambiente flessibile non supporta tutte le opzioni di scalabilità automatica disponibili per Compute Engine. Gli sviluppatori devono testare il loro comportamento di applicazione in una serie di condizioni. Ad esempio, devi verificare come la scalabilità automatica risponde quando un'applicazione basata su CPU diventa I/O vincolata 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 del controllo di integrità che saranno utilizzati dal bilanciatore del carico per determinare se inviare o meno il traffico a un'istanza e se deve essere corretto 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 guasto temporaneo in tale servizio può causare lo stato non integro di tutte le istanze, causando potenzialmente un errore di cascata.
Abbandono di richieste in caso di sovraccarico
Le applicazioni possono far perdere le richieste in caso di sovraccarico durante una strategia per evitare errori a cascata. Questa funzionalità è integrata nel livello di routing del traffico nell'ambiente standard. Consigliamo agli sviluppatori di applicazioni QPS molto elevate nell'ambiente flessibile di creare questa funzionalità per ridurre il carico di traffico nelle proprie applicazioni limitando il numero di richieste in parallelo.
Per verificare che la tua applicazione per l'ambiente flessibile non sia suscettibile a questo tipo di errore, puoi creare una versione con un limite massimo per il numero di istanze. Quindi, aumenta costantemente il traffico fino a quando le richieste non vengono eliminate. Devi assicurarti che l'applicazione non superi i controlli di integrità durante il sovraccarico.
Dimensioni istanza
Le istanze dell'ambiente flessibile possono avere limiti di memoria e CPU più elevati rispetto alle istanze dell'ambiente standard. Ciò consente alle istanze flessibili di eseguire applicazioni che richiedono più memoria e CPU. Tuttavia, è possibile aumentare la probabilità di bug di contemporaneità a causa dell'aumento dei thread all'interno di una singola istanza.
Gli sviluppatori possono utilizzare SSH per un'istanza di ambiente flessibile e ottenere un dump del thread per risolvere questo tipo di problema.
Timeout massimo della richiesta
Mentre il timeout dell'ambiente standard varia a seconda del tipo di scalabilità selezionato, l'ambiente flessibile impone sempre un timeout di 60 minuti. Per evitare di lasciare aperte le richieste per tutti i 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 impiegano molto tempo in modo inaccettabile, come 60 secondi. Assicurati che la tua app possa tornare a uno stato coerente dopo che il filtro interrompe una richiesta.
Migrazione del traffico
L'ambiente standard fornisce una funzionalità di migrazione del traffico che trasferisce gradualmente il traffico a una nuova versione per ridurre al minimo i picchi di latenza. Consulta i documenti sulla migrazione del traffico per assicurarti di evitare un picco di latenza quando passi al traffico a una nuova versione.
Errori di zona singola
Le applicazioni dell'ambiente standard sono ospitate a un'unica casa, ovvero tutte le istanze dell'applicazione si trovano in una singola zona di disponibilità. In caso di errore nella zona, l'applicazione avvia nuove istanze in una zona diversa nella stessa area geografica e il bilanciatore del carico instrada il traffico alle nuove istanze. Vedrai un picco di latenza dovuto alle richieste di caricamento e anche uno svuotamento di memcache.
Le applicazioni per l'ambiente flessibile utilizzano gruppi di istanze gestite a livello di area geografica, il che significa che le istanze sono distribuite tra più zone di disponibilità all'interno di un'area geografica. In caso di errore di una singola zona, il bilanciatore del carico interrompe il routing del traffico a tale zona. Se hai impostato la scalabilità automatica per eseguire le istanze il più rapidamente possibile, vedrai un breve periodo di sovraccarico prima che la scalabilità automatica crei altre istanze.
Confronti di costi
Sono molti i fattori coinvolti nel confronto dei costi tra i carichi di lavoro in esecuzione in ambienti standard e flessibili. Queste includono:
- Prezzo pagato per MCycle.
- Capacità della piattaforma CPU, che influisce sul lavoro che può essere svolto per MCycle
- Velocità di esecuzione delle istanze su ogni piattaforma.
- Il 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 di runtime.
Dovrai eseguire esperimenti per determinare il costo del carico di lavoro su ciascuna piattaforma. In un ambiente flessibile, puoi utilizzare QPS per core come proxy per l'efficienza dei costi della tua applicazione quando esegui esperimenti per determinare se una modifica ha un impatto sui costi. L'ambiente standard non offre un meccanismo per ottenere metriche in tempo reale sull'efficienza dei costi dell'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 dispone di tale funzionalità. L'approccio consigliato per un'autenticazione sicura tra le applicazioni è l'utilizzo di OAuth.
Deployment
I deployment nell'ambiente standard sono generalmente più veloci rispetto ai deployment in un ambiente flessibile. È più veloce fare lo scale up di una versione esistente in un ambiente Flessibile rispetto al deployment di una nuova versione, perché la programmazione di rete per una nuova versione è di solito il polo lungo in un deployment di ambienti flessibili. Una strategia per eseguire rapidi rollback in un ambiente flessibile consiste nel mantenere una versione valida nota scalata verso una singola istanza. Potrai quindi scalare tale versione e quindi instradare tutto il traffico verso di essa utilizzando la suddivisione del traffico.
Quando utilizzare l'ambiente flessibile
L'ambiente flessibile è pensato per essere complementare con l'ambiente standard. Se hai un'applicazione esistente in esecuzione nell'ambiente standard, in genere non è necessaria la migrazione dell'intera applicazione nell'ambiente flessibile. Identifica invece le parti dell'applicazione che richiedono più CPU, RAM e una libreria o un programma di terze parti specializzato oppure 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 tali 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 viene eseguito nell'ambiente flessibile che gestisce solo la conversione in PDF. Questo microservizio può essere un programma semplice contenente solo 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 potrebbe richiedere tempo, può utilizzare Cloud Tasks o Cloud Pub/Sub per mettere in coda le richieste.
Passaggi successivi
Mappa i servizi che la tua app utilizza nell'ambiente standard ai analoghi dell'ambiente flessibile.