Comparer App Engine et Cloud Run

Ce guide présente Cloud Run pour les utilisateurs qui connaissent déjà App Engine. Il couvre les principales similitudes et différences entre les plates-formes sans serveur pour vous aider à préparer la migration depuis l'environnement standard ou flexible App Engine.

Présentation

Cloud Run est la dernière évolution de Google Cloud Serverless, développé depuis plus de 10 ans sur l'expérience d'exécution d'App Engine. Cloud Run s'exécute en grande partie sur la même infrastructure que l'environnement standard App Engine. Il existe donc de nombreuses similitudes entre ces deux plates-formes.

Cloud Run est conçu pour améliorer l'expérience App Engine, en intégrant bon nombre des meilleures fonctionnalités de l'environnement standard et de l'environnement flexible App Engine. Les services Cloud Run peuvent gérer les mêmes charges de travail que les services App Engine, mais Cloud Run offre beaucoup plus de flexibilité aux clients dans la mise en œuvre de ces services. Cette flexibilité, ainsi que l'amélioration des intégrations à Google Cloud et à des services tiers, permet également à Cloud Run de gérer les charges de travail qui ne peuvent pas s'exécuter sur App Engine.

Résumé comparatif

Bien qu'il existe de nombreuses similitudes et différences entre App Engine et Cloud Run, cette présentation se concentre sur les domaines les plus pertinents pour les clients App Engine qui font leurs premiers pas avec Cloud Run.

Modèle de ressource

Le modèle de ressource Cloud Run est très semblable à App Engine, mais il existe quelques différences clés :

• Cloud Run ne dispose pas de ressource Application de premier niveau ni du service default correspondant.
• Les services Cloud Run du même projet peuvent être déployés dans différentes régions. Dans App Engine, tous les services du projet se trouvent dans la même région.
• Cloud Run utilise le terme Révision au lieu de Version pour s'aligner sur le modèle de ressource Knative.
• Les noms des révisions Cloud Run utilisent le format SERVICE_NAME-REVISION_SUFFIX, où REVISION_SUFFIX est généré automatiquement ou défini à l'aide de l'option de déploiement --revision-suffix=REVISION_SUFFIX.
• Les révisions Cloud Run sont immuables, ce qui signifie que vous ne pouvez pas réutiliser les noms comme vous le feriez avec les versions d'App Engine (à l'aide de l'option de déploiement --version=VERSION_ID).
• Les URL de service Cloud Run sont basées sur un identifiant de service généré automatiquement lors du premier déploiement du service. Les identifiants de service utilisent le format suivant : SERVICE_NAME-<auto-generated identifier>. L'identifiant de service est unique et ne change pas pendant la durée de vie du service.
• Dans Cloud Run, seules les URL de service (SERVICE_IDENTIFIER.run.app et https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) sont exposées par défaut. Pour traiter une révision spécifique, vous devez configurer un tag de trafic. Dans App Engine, les URL de service et de version sont exposées automatiquement.

Déploiement et configuration

Dans App Engine, la plupart des configurations sont effectuées dans le fichier app.yaml inclus dans chaque déploiement. Cette simplicité a un coût : si certains paramètres peuvent être mis à jour à l'aide de l'API Admin, la plupart des modifications nécessitent de redéployer le service.

Bien que Cloud Run dispose du fichier de configuration service.yaml, il n'est pas utilisé de la même manière que le fichier app.yaml. Le fichier service.yaml de Cloud Run ne peut pas être utilisé lors du déploiement à partir de la source, car l'un des éléments requis est le chemin d'accès à l'image de conteneur finale. En outre, service.yaml est conforme à la spécification Knative et peut être difficile à lire pour les utilisateurs qui ne connaissent pas les fichiers de configuration de type Kubernetes. Pour en savoir plus sur l'utilisation de service.yaml pour gérer la configuration, consultez la documentation Cloud Run.

Pour les clients App Engine qui font leurs premiers pas avec Cloud Run, l'utilisation des options de déploiement de gcloud CLI s'aligne beaucoup plus sur la gestion de la configuration lors du déploiement d'App Engine.

Pour définir la configuration lors du déploiement d'un nouveau code dans Cloud Run, utilisez les options gcloud run deploy :

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

Bien qu'il ne soit pas nécessaire d'utiliser les options de configuration avec chaque déploiement (voir Gérer les configurations), vous pouvez le faire pour simplifier la gestion de la configuration.

Dans Cloud Run, vous pouvez également mettre à jour la configuration sans redéployer le code source à l'aide de gcloud run services update :

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

Comme les révisions Cloud Run sont immuables, cette commande crée une nouvelle révision avec la configuration mise à jour, mais utilise la même image de conteneur que la révision existante.

Gérer les configurations

Pour les déploiements App Engine, tous les paramètres doivent être fournis pour chaque déploiement. Si des paramètres ne sont pas fournis, des valeurs par défaut leur sont attribuées. Prenons l'exemple d'App Engine service-a, avec des versions utilisant les fichiers app.yaml du tableau suivant :

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 est configuré avec instance_class: F4, tandis que version2, qui n'a fourni aucune valeur pour instance_class, est configuré avec la valeur par défaut instance_class: F1.

Pour Cloud Run, tous les paramètres de configuration fournis sont appliqués, mais ceux qui ne sont pas fournis conservent leurs valeurs existantes. Il vous suffit de fournir les valeurs des paramètres que vous souhaitez modifier. Exemple :

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:
..
..

Dans App Engine, le déploiement sans paramètres de configuration crée une version utilisant tous les paramètres par défaut. Dans Cloud Run, le déploiement sans paramètre de configuration crée une révision utilisant les mêmes paramètres de configuration que la révision précédente. Pour la première révision d'un service Cloud Run sans déploiement de configuration, une révision est créée à l'aide de tous les paramètres par défaut.

Configuration par défaut

Point d'entrée

Lors du déploiement à partir de la source, App Engine lit la commande entrypoint à partir de l'attribut entrypoint dans le fichier app.yaml. Si aucun point d'entrée n'est fourni, une valeur par défaut spécifique à l'environnement d'exécution est appliquée. Cloud Run utilise les buildpacks de Google Cloud lors du déploiement à partir de la source. Certains langages ne disposent pas de point d'entrée par défaut, ce qui signifie que vous devez en fournir un, sinon la compilation échouera. Par exemple, les buildpacks Python nécessitent un fichier Procfile ou la spécification de la variable d'environnement de build GOOGLE_ENTRYPOINT.

Consultez la documentation sur les buildpacks pour connaître les exigences de configuration spécifiques au langage.

Vérifications d'état

Dans App Engine, les vérifications de l'état sont en grande partie automatiques et gérées par la plate-forme. App Engine effectue des vérifications d'activité et d'aptitude pour déterminer si une instance est opérationnelle et prête à diffuser du trafic. Si une instance échoue systématiquement aux vérifications automatiques, App Engine la résilie et la remplace par une nouvelle instance pour assurer la continuité du service.

Cloud Run offre un contrôle plus précis grâce à des vérifications de démarrage et d'activité configurables. Ces tests vous permettent de définir une instance opérationnelle, ce qui est essentiel pour les microservices complexes.

Dans Cloud Run, vous pouvez configurer les vérifications suivantes :

• Vérification de démarrage pour définir le moment où un conteneur a démarré et est prêt à diffuser du trafic. Lorsque vous configurez une vérification de démarrage, elle désactive les vérifications d'activité jusqu'à ce que le démarrage réussisse, en s'assurant que les vérifications d'activité n'interfèrent pas avec le démarrage de votre application.

• Vérification d'activité pour déterminer quand redémarrer un conteneur. Par exemple, les vérifications d'activité peuvent détecter un interblocage lorsqu'une application est en cours d'exécution, mais ne peut pas progresser. Le redémarrage d'un conteneur dans un tel état permet de s'assurer que votre application est disponible malgré les bugs.

Pour en savoir plus, consultez Configurer les vérifications de l'état des conteneurs pour les services.

Scaling

Bien que Cloud Run et l'environnement standard App Engine partagent une infrastructure de scaling similaire, Cloud Run est simplifié pour accélérer le scaling et offrir des capacités de scaling à zéro. Cela se traduit par un nombre moins important de paramètres configurables. Cette simplification limite les paramètres configurables aux éléments suivants :

• Simultanéité maximale
• Nombre maximal et nombre minimal d'instances

Pour les instances Cloud Run, l'objectif d'utilisation du processeur n'est pas configurable. Il est fixe à 60 %. Pour en savoir plus, consultez À propos de l'autoscaling des instances dans les services Cloud Run.

L'environnement flexible App Engine utilise l'autoscaler Compute Engine. Il présente donc des caractéristiques de scaling très différentes de celles de l'environnement standard et de Cloud Run.

Migrer les contrôles de scaling d'App Engine vers Cloud Run

Cette section explique comment mapper votre configuration de scaling App Engine existante à Cloud Run.

Nombre minimal d'instances (préparation)

Maintenez un nombre minimal d'instances en attente pour gérer le trafic de base et éviter les démarrages à froid.

Stratégie de migration : définissez le nombre minimal d'instances pour le préchauffage au niveau du service. Si vous dirigez le trafic vers une révision spécifique, le paramètre au niveau de la révision remplace la valeur par défaut au niveau du service. Utilisez ce paramètre pour tester une nouvelle révision avec un nombre minimal d'instances différent avant de la promouvoir en production.

Nombre maximal d'instances

Définissez une limite stricte sur le nombre total d'instances pour contrôler les coûts et protéger les dépendances en aval.

Stratégie de migration : définissez une limite globale au niveau du service. Cloud Run applique le paramètre le plus faible entre le niveau du service et celui de la révision. Pour en savoir plus, consultez Définir le nombre maximal d'instances pour les services.

Simultanéité

Définissez la capacité de requête d'une seule instance.

Stratégie de migration : suivez l'une des deux stratégies de migration :

• Commencez par la capacité d'instance Cloud Run par défaut de 80 et effectuez des tests de charge pour trouver la limite de concurrence stable de votre application sur Cloud Run. Ajuster cette valeur est un moyen efficace d'optimiser les performances et les coûts sur Cloud Run. Ajustez la valeur à la baisse par rapport à 80 en fonction des résultats de vos tests. Pour en savoir plus, consultez Définir le nombre maximal de requêtes simultanées par instance.

• Utilisez votre valeur de configuration existante dans l'environnement standard App Engine, qui est de 10 requêtes simultanées par instance par défaut. Il s'agit d'une option sûre, car il s'agit d'une configuration connue et fonctionnelle pour votre application. Toutefois, cela peut entraîner une sous-utilisation importante de vos instances Cloud Run et potentiellement des coûts plus élevés, car l'autoscaler crée plus d'instances que nécessaire pour gérer la charge.

Utilisation du processeur

Effectuez un scaling lorsque la charge du processeur dépasse un certain seuil.

Stratégie de migration : vous ne pouvez pas configurer cette valeur. L'autoscaler de Cloud Run maintient une utilisation du processeur d'environ 60 % sur les instances actives. Contrairement à App Engine, Cloud Run n'alloue de processeur que pendant le traitement des requêtes et le limite à zéro dans le cas contraire. Dans l'environnement standard App Engine, quel que soit le type de scaling que vous configurez, App Engine s'assure que le processeur est disponible en permanence pour votre instance.

Si votre application effectue des tâches en arrière-plan entre les requêtes, par exemple en utilisant des threads en arrière-plan dans le scaling de base ou manuel, configurez la facturation basée sur les instances dans Cloud Run pour éviter la suspension de vos tâches de traitement en arrière-plan.

Débit des requêtes

Effectuez un scaling en fonction du débit de requêtes lorsque votre application atteint la limite de simultanéité.

Stratégie de migration : l'autoscaler Cloud Run tente de maintenir le nombre de requêtes simultanées par instance à 60 % de la valeur maxInstanceRequestConcurrency. Lorsque vous définissez cette valeur, vous définissez implicitement le débit cible qui déclenche un événement de scaling-up.

Latence

Définissez une période d'attente des utilisateurs qui déclenche le scaling. App Engine est en partie réactif à la mise en file d'attente des requêtes.

Stratégie de migration : Cloud Run effectue l'autoscaling avant que les requêtes ne commencent à être mises en file d'attente et que la latence n'augmente. Si des pics de latence se produisent, envisagez d'ajuster la valeur template.maxInstanceRequestConcurrency pour garantir un scale-out plus rapide.

Instances inactives

Intention : dans App Engine, les paramètres d'instances inactives contrôlent un pool d'instances inactives préchauffées qui absorbent les pics de trafic et contrôlent les coûts.

Stratégie de migration : vous ne pouvez pas configurer un nombre minimal ou maximal d'instances inactives distinct dans Cloud Run. Pour maintenir les instances en attente et prêtes à gérer le trafic immédiat, et pour atténuer les démarrages à froid dans Cloud Run, utilisez le paramètre scaling.min_instance_count. Il permet de s'assurer qu'un nombre minimal spécifié de conteneurs est toujours en cours d'exécution. Pour en savoir plus, consultez À propos de l'autoscaling des instances dans les services Cloud Run.

Délai d'inactivité de l'instance

Dans App Engine, les instances inactives restent actives pendant environ 15 minutes après la dernière requête. Cloud Run contrôle ce comportement à l'aide de son paramètre de facturation.

Pour obtenir un comportement de facturation similaire à celui d'App Engine, où le processeur est alloué en dehors du traitement des requêtes, utilisez la facturation basée sur les instances dans Cloud Run.

Vous pouvez également utiliser la facturation basée sur les requêtes pour que le processeur ne soit alloué que lors du traitement des requêtes. Avec ce paramètre, l'instance reste active pendant 15 minutes après la dernière requête, mais le processeur est limité pendant cette période d'inactivité.

Scaling de base

Lorsque vous configurez le paramètre basic_scaling dans l'environnement standard App Engine, des instances sont créées lorsque des requêtes sont reçues, et la mise à l'échelle est définie sur zéro après une période d'inactivité. Vous pouvez reproduire ce comportement dans Cloud Run à l'aide du scaling automatique en définissant min-instances sur 0.

Scaling manuel

Exécutez un nombre fixe d'instances et désactivez l'autoscaling.

Stratégie de migration : il existe un mappage direct dans Cloud Run pour le scaling manuel. Définissez le mode de scaling sur MANUAL au niveau du service dans Cloud Run, puis spécifiez le nombre exact d'instances à exécuter à l'aide de manualInstanceCount. Cela a le même effet que de désactiver complètement l'autoscaling. Pour en savoir plus, consultez Scaling manuel dans Cloud Run.

Période de stabilisation

Configurez une période de refroidissement après un événement de scale-up avant qu'un autre événement ne se produise.

Stratégie de migration : non requise. Cloud Run effectue l'autoscaling en fonction de la demande et de l'utilisation. Il est conçu pour réagir efficacement sans configuration manuelle de période de refroidissement.

Requêtes de préchauffage

Cloud Run préchauffe automatiquement les instances à l'aide de la commande entrypoint du conteneur. Vous n'avez donc pas besoin d'activer manuellement les requêtes de préchauffage ni de configurer un gestionnaire /_ah/warmup. Si vous souhaitez exécuter du code au démarrage d'une instance, avant que des requêtes soient traitées, vous pouvez soit :

• Configurer votre application pour écouter les requêtes
• Configurer une vérification de démarrage personnalisée

Contenu statique

Dans l'environnement standard App Engine, vous pouvez diffuser du contenu statique sans utiliser de ressources de calcul en diffusant depuis Cloud Storage ou en configurant des gestionnaires. Cloud Run ne propose pas d'option de gestionnaires pour la diffusion de contenu statique. Vous pouvez donc diffuser le contenu à partir du service Cloud Run (identique au contenu dynamique) ou depuis Cloud Storage.

Rôle de demandeur Cloud Run

Cloud Run offre également la possibilité de contrôler l'accès au service avec IAM (Identity and Access Management). Les liaisons de stratégie IAM pour un service peuvent être définies à l'aide de gcloud CLI, de la console ou de Terraform.

Pour répliquer le comportement d'App Engine, vous pouvez rendre le service public en autorisant les requêtes non authentifiées. Vous pouvez définir cela au déploiement ou en mettant à jour les liaisons de stratégie IAM sur un service existant.

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

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

Vous pouvez également choisir de contrôler qui a accès au service en attribuant le rôle IAM Demandeur Cloud Run qui est configurable par service.

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"

Variables d'environnement et métadonnées

App Engine et Cloud Run disposent de certaines variables d'environnement qui sont définies automatiquement. Le tableau suivant présente les variables d'environnement App Engine, ainsi que leurs équivalents dans Cloud Run. Par rapport à App Engine, Cloud Run n'implémente que quelques variables d'environnement, mais les données disponibles à partir du serveur de métadonnées sont pour la plupart équivalentes.

Variables d'environnement par défaut

Chemins d'accès de serveur de métadonnées courants

Étapes suivantes

• Guide de démarrage rapide : déployer un service Web avec Cloud Run
• Mon application est-elle adaptée à Cloud Run ?
• Migrer mon domaine personnalisé App Engine vers Cloud Load Balancing
• Autres ressources :
  • Migrer depuis App Engine vers Cloud Run avec Docker (Python : atelier de programmation, vidéo, Java : atelier de programmation)
  • Migrer depuis App Engine vers Cloud Run avec les buildpacks (Python : atelier de programmation, vidéo, Java : atelier de programmation)