Confronta App Engine e Cloud Run

Questa guida fornisce un'introduzione a Cloud Run per gli utenti che hanno familiarità con App Engine. Vengono illustrate le principali somiglianze e differenze tra le piattaforme serverless per prepararsi alla migrazione dall'ambiente standard di App Engine o dall'ambiente flessibile di App Engine.

Panoramica

Cloud Run è l'ultima evoluzione di Google Cloud Serverless, basata sull'esperienza di esecuzione di App Engine per oltre un decennio. Cloud Run viene eseguito sulla stessa infrastruttura dell'ambiente standard di App Engine, quindi esistono molte somiglianze tra queste due piattaforme.

Cloud Run è progettato per migliorare l'esperienza di App Engine, incorporando molte delle migliori funzionalità sia dell'ambiente standard di App Engine sia dell'ambiente flessibile di App Engine. I servizi Cloud Run possono gestire gli stessi carichi di lavoro dei servizi App Engine, ma Cloud Run offre ai clienti molta più flessibilità nell'implementazione di questi servizi. Questa flessibilità, insieme a una migliore integrazione con Google Cloud e servizi di terze parti, consente inoltre a Cloud Run di gestire carichi di lavoro che non possono essere eseguiti su App Engine.

Riepilogo del confronto

Sebbene esistano molte somiglianze e differenze tra App Engine e Cloud Run, questa panoramica si concentra sulle aree più pertinenti per i clienti App Engine che iniziano a utilizzare Cloud Run.

Modello di risorsa

Il modello di risorse Cloud Run è molto simile ad App Engine, ma ci sono alcune differenze fondamentali:

• Cloud Run non dispone di una risorsa Applicazione di primo livello o del servizio default corrispondente.
• I servizi Cloud Run nello stesso progetto possono essere sottoposti a deployment in regioni diverse. In App Engine, tutti i servizi del progetto si trovano nella stessa regione.
• Cloud Run utilizza il termine Revisione, anziché Versione, per allinearsi al modello di risorse Knative.
• I nomi delle revisioni di Cloud Run utilizzano il formato SERVICE_NAME-REVISION_SUFFIX, dove REVISION_SUFFIX viene generato automaticamente o impostato utilizzando il flag di deployment --revision-suffix=REVISION_SUFFIX.
• Le revisioni di Cloud Run sono immutabili, il che significa che non puoi riutilizzare i nomi come puoi fare con le versioni di App Engine (utilizzando il flag di deployment --version=VERSION_ID).
• Gli URL dei servizi Cloud Run si basano su un identificatore di servizio generato automaticamente al primo deployment del servizio. Gli identificatori di servizio utilizzano il formato: SERVICE_NAME-<auto-generated identifier>. L'identificatore di servizio è univoco e non cambia durante la durata del servizio.
• In Cloud Run, per impostazione predefinita vengono esposti solo gli URL del servizio (SERVICE_IDENTIFIER.run.app e https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app). Per indirizzare una revisione specifica, devi configurare un tag di traffico. In App Engine, sia gli URL di servizio che quelli di versione vengono esposti automaticamente.

Deployment e configurazione

In App Engine, la maggior parte della configurazione viene eseguita nel file app.yaml incluso in ogni deployment. Questa semplicità ha un costo, in quanto, sebbene alcune impostazioni possano essere aggiornate utilizzando l'API Admin, la maggior parte delle modifiche richiede il redeployment del servizio.

Sebbene Cloud Run disponga del file di configurazione service.yaml, non viene utilizzato nello stesso modo di app.yaml. service.yaml di Cloud Run non può essere utilizzato durante il deployment dall'origine, in quanto uno degli elementi richiesti è il percorso dell'immagine container finale. Inoltre, service.yaml è conforme alla specifica Knative e può essere difficile da leggere per chi non ha familiarità con i file di configurazione in stile Kubernetes. Per ulteriori informazioni sull'utilizzo di service.yaml per gestire la configurazione, consulta la documentazione di Cloud Run.

Per i clienti App Engine che iniziano a utilizzare Cloud Run, l'utilizzo dei flag di deployment di gcloud CLI è molto più in linea con la gestione della configurazione di App Engine al momento del deployment.

Per impostare la configurazione durante il deployment di nuovo codice in Cloud Run, utilizza i flag gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Sebbene non sia necessario utilizzare i flag di configurazione con ogni deployment (vedi Gestione delle configurazioni), puoi farlo per semplificare la gestione della configurazione.

In Cloud Run, puoi anche aggiornare la configurazione senza eseguire nuovamente il deployment del codice sorgente utilizzando gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Poiché le revisioni di Cloud Run sono immutabili, questo comando creerà una nuova revisione con la configurazione aggiornata, ma utilizzerà la stessa immagine container della revisione esistente.

Gestione delle configurazioni

Per i deployment di App Engine, tutte le impostazioni devono essere fornite per ogni deployment e a tutte le impostazioni non fornite vengono assegnati valori predefiniti. Ad esempio, prendi App Engine service-a, con versioni che utilizzano i file app.yaml nella tabella seguente:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 è configurato con instance_class: F4, mentre version2, che non ha fornito alcun valore per instance_class, è configurato con il valore predefinito instance_class: F1.

Per Cloud Run, vengono applicate tutte le impostazioni di configurazione fornite, ma quelle non fornite mantengono i valori esistenti. Devi fornire valori solo per le impostazioni che vuoi modificare. Ad esempio:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

In App Engine, il deployment senza impostazioni di configurazione crea una versione che utilizza tutte le impostazioni predefinite. In Cloud Run, il deployment senza impostazioni di configurazione crea una revisione utilizzando le stesse impostazioni di configurazione della revisione precedente. Per la prima revisione di un servizio Cloud Run, il deployment senza impostazioni di configurazione crea una revisione utilizzando tutte le impostazioni predefinite.

Valori predefiniti di configurazione

Entry point

Quando esegui il deployment dall'origine, App Engine legge il comando di punto di ingresso dall'attributo entrypoint in app.yaml. Se non viene fornito alcun punto di ingresso, viene utilizzato un valore predefinito specifico del runtime. Cloud Run utilizza i buildpack di Google Cloud durante il deployment dal codice sorgente e alcune lingue non hanno un punto di ingresso predefinito, il che significa che devi fornirne uno o la build non andrà a buon fine. Ad esempio, i buildpack Python richiedono un Procfile o la specifica della variabile di ambiente di build GOOGLE_ENTRYPOINT.

Consulta la documentazione dei buildpack per i requisiti di configurazione specifici per la lingua.

Controlli di integrità

In App Engine, i controlli di integrità sono in gran parte automatici e gestiti dalla piattaforma. App Engine esegue controlli di attività e idoneità per determinare se un'istanza è operativa e pronta a gestire il traffico. Se un'istanza non supera costantemente i controlli automatici, App Engine la termina e la sostituisce con una nuova istanza per garantire la continuità del servizio.

Cloud Run offre un controllo più granulare con probe di avvio e attività configurabili. Questi probe ti consentono di definire un'istanza integra, il che è fondamentale per i microservizi complessi.

In Cloud Run, puoi configurare i seguenti probe:

• Probe di avvio per definire quando un container è stato avviato ed è pronto a gestire il traffico. Quando configuri un probe di avvio, disattiva i controlli di attività finché l'avvio non va a buon fine, assicurandosi che i probe di attività non interferiscano con l'avvio dell'applicazione.

• Probe di attività per determinare quando riavviare un container. Ad esempio, i probe di attività potrebbero rilevare un deadlock quando un'applicazione è in esecuzione, ma non riesce a progredire. Il riavvio di un container in questo stato garantisce che l'applicazione sia disponibile nonostante i bug.

Per saperne di più, consulta Configurare i controlli di integrità dei container per i servizi.

Scalabilità

Sebbene Cloud Run e l'ambiente standard di App Engine condividano un'infrastruttura di scalabilità simile, Cloud Run è ottimizzato per una scalabilità più rapida e funzionalità di scalabilità a zero. Di conseguenza, ci sono meno impostazioni configurabili. Questa semplificazione limita le impostazioni configurabili a:

• Contemporaneità massima
• Istanze massime e minime

Per le istanze Cloud Run, l'utilizzo della CPU target non è configurabile; è fissato al 60%. Per maggiori dettagli, consulta Informazioni sulla scalabilità automatica delle istanze nei servizi Cloud Run.

L'ambiente flessibile di App Engine utilizza il gestore della scalabilità automatica di Compute Engine e pertanto ha caratteristiche di scalabilità molto diverse rispetto all'ambiente standard di App Engine e a Cloud Run.

Eseguire la migrazione dei controlli di scalabilità da App Engine a Cloud Run

Questa sezione descrive come mappare la configurazione di scalabilità di App Engine esistente a Cloud Run.

Numero minimo di istanze (preparazione)

Mantieni un numero minimo di istanze in uso per gestire il traffico di base ed evitare gli avvii a freddo.

Strategia di migrazione: imposta il numero minimo di istanze per il warm-up a livello di servizio. Se indirizzi il traffico a una revisione specifica, l'impostazione a livello di revisione override l'impostazione predefinita a livello di servizio. Utilizza questa impostazione per testare una nuova revisione con un conteggio minimo di istanze diverso prima di promuoverla in produzione.

Numero massimo di istanze

Imposta un limite rigido al numero totale di istanze per controllare i costi e proteggere le dipendenze downstream.

Strategia di migrazione: imposta un limite globale a livello di servizio. Cloud Run applica l'impostazione di livello di servizio e di revisione inferiore. Per saperne di più, vedi Impostare il numero massimo di istanze per i servizi.

Contemporaneità

Definisci la capacità di richiesta di una singola istanza.

Strategia di migrazione: segui una delle due strategie di migrazione:

• Inizia con la capacità predefinita dell'istanza Cloud Run di 80 e esegui test di carico per trovare il limite di concorrenza stabile per la tua applicazione su Cloud Run. L'ottimizzazione di questo valore è un modo efficace per ottimizzare prestazioni e costi su Cloud Run. Modifica il valore diminuendolo da 80 in base ai risultati del test. Per saperne di più, consulta Impostare il numero massimo di richieste in parallelo per istanza.

• Utilizza il valore di configurazione esistente nell'ambiente standard di App Engine, ovvero 10 richieste simultanee per istanza per impostazione predefinita. Si tratta di un'opzione sicura, perché è una configurazione nota e funzionante per la tua applicazione. Tuttavia, questo potrebbe comportare un sottoutilizzo significativo delle istanze Cloud Run e costi potenzialmente più elevati, poiché il gestore della scalabilità automatica crea più istanze del necessario per gestire il carico.

Utilizzo CPU

Scalare quando il carico della CPU supera una determinata soglia.

Strategia di migrazione: non puoi configurare questo valore. Il gestore della scalabilità automatica di Cloud Run mantiene un utilizzo della CPU di circa il 60% sulle istanze attive. A differenza di App Engine, Cloud Run alloca la CPU solo durante l'elaborazione delle richieste e la limita a zero in caso contrario. Nell'ambiente standard di App Engine, indipendentemente dal tipo di scalabilità configurato, App Engine assicura che la CPU sia disponibile continuamente per l'istanza.

Se la tua applicazione esegue operazioni in background tra le richieste, ad esempio utilizzando thread in background nello scaling di base o manuale, configura la fatturazione basata sulle istanze in Cloud Run per evitare la sospensione delle attività di elaborazione in background.

Velocità effettiva richiesta

Scalare in base alla velocità effettiva delle richieste quando l'applicazione raggiunge il limite di concorrenza.

Strategia di migrazione: il gestore della scalabilità automatica di Cloud Run tenta di mantenere il numero di richieste simultanee per istanza al 60% del valore di maxInstanceRequestConcurrency. Quando imposti questo valore, definisci implicitamente il throughput target che attiva un evento di scalabilità verticale.

Latenza

Definisci una finestra di tempo di attesa dell'utente che attiva lo scaling. App Engine è in parte reattivo alla creazione di code di richieste.

Strategia di migrazione: Cloud Run esegue lo scale automatico prima che le richieste inizino a essere accodate e si verifichino picchi di latenza. Se si verificano picchi di latenza, valuta la possibilità di ottimizzare il valore di template.maxInstanceRequestConcurrency per garantire uno scale out più rapido.

Istanze inattive

Scopo:in App Engine, le impostazioni delle istanze inattive controllano un pool di istanze inattive pre-riscaldate che assorbono i picchi di traffico e controllano i costi.

Strategia di migrazione: non puoi configurare un numero minimo o massimo separato di istanze inattive in Cloud Run. Per mantenere le istanze in uso e pronte per il traffico immediato e ridurre gli avvii a freddo in Cloud Run, utilizza l'impostazione scaling.min_instance_count, che garantisce che un numero minimo specificato di container sia sempre in esecuzione. Per saperne di più, consulta Informazioni sulla scalabilità automatica delle istanze nei servizi Cloud Run.

Timeout istanza inattiva

In App Engine, le istanze inattive rimangono attive per circa 15 minuti dopo l'ultima richiesta. Cloud Run controlla questo comportamento utilizzando l'impostazione di fatturazione.

Per ottenere un comportamento di fatturazione simile a quello di App Engine, in cui la CPU viene allocata al di fuori dell'elaborazione delle richieste, utilizza la fatturazione basata sulle istanze in Cloud Run.

In alternativa, utilizza la fatturazione basata sulle richieste per allocare la CPU solo durante l'elaborazione delle richieste. Con questa impostazione, l'istanza rimarrà attiva per un massimo di 15 minuti dopo l'ultima richiesta, ma la CPU verrà limitata durante questo periodo di inattività.

Scalabilità di base

Quando configuri l'impostazione basic_scaling nell'ambiente standard di App Engine, vengono create istanze quando riceve richieste e viene scalata a zero dopo un periodo di inattività. Puoi replicare questo comportamento in Cloud Run utilizzando scalabilità automatica impostando min-instances su 0.

Scalabilità manuale

Esegui un numero fisso di istanze e disattiva la scalabilità automatica.

Strategia di migrazione: in Cloud Run esiste un mapping diretto per lo scaling manuale. Imposta la modalità di scalabilità su MANUAL a livello di servizio in Cloud Run e specifica il numero esatto di istanze da eseguire utilizzando manualInstanceCount. Questo ha lo stesso effetto della disattivazione completa dello scale automatico. Per maggiori informazioni, consulta Scalabilità manuale in Cloud Run.

Periodo di attesa

Configura un periodo di raffreddamento dopo un evento di scalabilità verso l'alto prima che si verifichi un altro evento.

Strategia di migrazione: non richiesta. Cloud Run esegue lo scaling automatico in base alla domanda e all'utilizzo ed è progettato per reagire in modo efficiente senza una configurazione manuale del periodo di raffreddamento.

Richieste di warmup

Cloud Run esegue automaticamente il warm-up delle istanze utilizzando il comando di punto di ingresso del container, quindi non è necessario abilitare manualmente le richieste di warm-up o configurare un gestore /_ah/warmup. Se hai del codice che vuoi eseguire all'avvio dell'istanza prima che vengano elaborate le richieste, puoi:

• Configurare l'app per l'ascolto delle richieste
• Configurare un probe di avvio personalizzato

Contenuti statici

Nell'ambiente standard di App Engine, puoi pubblicare contenuti statici senza utilizzare risorse di calcolo pubblicandoli da Cloud Storage o configurando i gestori.Cloud Run non ha l'opzione dei gestori per la pubblicazione di contenuti statici, quindi puoi pubblicare i contenuti dal servizio Cloud Run (come i contenuti dinamici) o da Cloud Storage.

Ruolo Cloud Run Invoker

Cloud Run offre anche la possibilità di controllare l'accesso a un servizio con Identity and Access Management (IAM). Le associazioni di policy IAM per un servizio possono essere impostate utilizzando gcloud CLI, la console o Terraform.

Per replicare il comportamento di App Engine, puoi rendere pubblico il servizio consentendo le richieste non autenticate. Può essere impostato al momento del deployment o aggiornando le associazioni di criteri IAM su un servizio esistente.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

In alternativa, puoi scegliere di controllare chi ha accesso al servizio concedendo il ruolo IAM Invoker di Cloud Run, configurabile per servizio.

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

Variabili di ambiente e metadati

Sia App Engine che Cloud Run hanno determinate variabili di ambiente che vengono impostate automaticamente. La tabella seguente mostra le variabili di ambiente di App Engine, insieme ai relativi equivalenti di Cloud Run. Cloud Run implementa solo alcune variabili di ambiente, rispetto ad App Engine, ma i dati disponibili dal server dei metadati sono per lo più equivalenti.

Variabili di ambiente predefinite

Percorsi comuni del server di metadati

Passaggi successivi

• Guida rapida: esegui il deployment di un servizio web con Cloud Run
• La mia app è adatta a Cloud Run?
• Eseguire la migrazione del mio dominio personalizzato App Engine a Cloud Load Balancing
• Altre risorse:
  • Migrazione da App Engine a Cloud Run con Docker (Python: codelab, video, Java: codelab)
  • Esegui la migrazione da App Engine a Cloud Run con i buildpack (Python: codelab, video; Java: codelab)