Mode de gestion des instances

Les instances constituent la base d'App Engine. Elles fournissent toutes les ressources nécessaires à l'hébergement d'une application, À tout moment, votre application peut être exécutée sur une ou plusieurs instances, avec des requêtes réparties sur chacune d'entre elles. Toutes les instances comportent une couche de sécurité. Ainsi, une instance ne peut pas en perturber accidentellement une autre.

App Engine peut créer et arrêter automatiquement des instances lorsque le trafic fluctue, ou vous pouvez spécifier un nombre d'instances à exécuter quelle que soit la quantité de trafic. Pour déterminer comment et quand les instances sont créées, vous devez spécifier un type de scaling pour votre application. Les paramètres de scaling sont appliqués au niveau de la version d'App Engine dans le fichier app.yaml.

Types de scaling

App Engine est compatible avec les types de scaling suivants, qui déterminent comment et quand les instances sont créées :

• Automatique (par défaut)
• De base
• Manuel

Spécifiez le type de scaling dans le fichier app.yaml de votre application. Par défaut, votre application utilise le scaling automatique, ce qui signifie qu'App Engine gère le nombre d'instances inactives.

Scaling automatique

Le scaling automatique crée des instances sur la base du taux de demandes, des latences de réponse et d'autres métriques d'application. Vous pouvez spécifier des seuils pour chacune de ces métriques, ainsi qu'un nombre minimal d'instances à conserver en fonctionnement en permanence en configurant l'élément automatic_scaling.

Scaling de base

Le scaling de base crée des instances lorsque votre application reçoit des requêtes. Chaque instance est arrêtée lorsque l'application devient inactive. Le scaling de base est idéal pour les tâches intermittentes ou liées à l'activité des utilisateurs.

Scaling manuel

Le scaling manuel spécifie le nombre d'instances qui s'exécutent en continu quel que soit le niveau de charge. Cela permet d'effectuer des tâches telles que des initialisations complexes, et de concevoir des applications qui dépendent de l'état de la mémoire au fil du temps.

Scaling des instances dynamiques

Les applications App Engine qui utilisent le scaling de base ou automatique reposent sur un certain nombre d'instances dynamiques à un instant donné, en fonction du volume de requêtes entrantes. À mesure que les requêtes de votre application augmentent, le nombre d'instances dynamiques peut également augmenter.

Applications avec scaling de base

Si vous utilisez le scaling de base, App Engine tente de maintenir un coût faible, même si cela peut entraîner une latence plus élevée à mesure que le volume de requêtes entrantes augmente.

Lorsqu'aucune instance existante n'est disponible pour répondre à une requête entrante, App Engine démarre une nouvelle instance. Même après le démarrage d'une nouvelle instance, certaines requêtes peuvent être mises en file d'attente jusqu'à la fin du processus de démarrage de la nouvelle instance. Si vous avez besoin de la latence la plus faible possible, envisagez d'utiliser le scaling automatique, qui crée de nouvelles instances de manière préemptive afin de minimiser la latence.

Applications avec scaling automatique

Si vous utilisez le scaling automatique, chaque instance de votre application possède sa propre file d'attente pour les requêtes entrantes. Avant que les files d'attente ne deviennent suffisamment longues pour que la latence de votre application soit sensiblement affectée, App Engine crée automatiquement une ou plusieurs instances pour gérer la charge croissante.

Vous pouvez configurer les paramètres du scaling automatique pour obtenir un compromis entre les performances souhaitées et le coût potentiel. Le tableau suivant décrit ces paramètres.

Regardez la vidéo sur les paramètres du programmeur App Engine pour découvrir leurs effets.

Réduire la capacité

Lorsque les volumes de requêtes diminuent, App Engine réduit le nombre d'instances. Ce scaling à la baisse permet de garantir que toutes les instances actuelles de votre application sont bien utilisées pour une efficacité et une rentabilité optimales.

Lorsqu'une application n'est pas utilisée du tout, le service App Engine désactive les instances dynamiques associées. Il les recharge immédiatement dès que cela s'avère nécessaire. Le rechargement des instances peut engendrer des requêtes de chargement et une latence supplémentaire pour les utilisateurs.

Vous pouvez spécifier un nombre minimal d'instances inactives. La définition d'un nombre approprié d'instances inactives pour votre application en fonction du volume des requêtes permet à cette dernière de diffuser chaque requête avec une latence faible, à moins que vous ne soyez confronté à un volume de requêtes anormalement élevé.

Réduire la capacité à l'aide du scaling automatique

Si votre application utilise le scaling automatique, les instances inactives commencent à s'arrêter au bout d'environ 15 minutes. Pour maintenir une ou plusieurs instances inactives en cours d'exécution, définissez la valeur de min_idle_instances sur 1 ou une valeur supérieure.

Scaling et lots de requêtes

Si vous envoyez des lots de requêtes à vos services, par exemple vers une file d'attente de tâches à traiter, de nombreuses instances sont créées rapidement. Nous vous recommandons de contrôler ce phénomène en limitant dans la mesure du possible le débit, c'est-à-dire le nombre de requêtes envoyées par seconde. Par exemple, si vous utilisez Google Tasks, vous pouvez contrôler la vitesse à laquelle les tâches sont transmises.

Cycle de vie des instances

États des instances

Une instance d'un service avec autoscaling s'exécute en permanence. En revanche, une instance d'un service avec scaling manuel ou de base peut être en cours d'exécution ou arrêtée. Toutes les instances du même service et de la même version partagent le même état. Vous modifiez l'état de vos instances en gérant vos versions. Vous pouvez :

• utiliser la page Versions dans la console Google Cloud ;
• utiliser les commandes gcloud app versions start et gcloud app versions stop.

Démarrage

Chaque instance de service est créée en réponse à une requête de démarrage, qui correspond à une requête HTTP GET vide adressée à /_ah/start. App Engine envoie cette requête pour créer une instance. Les utilisateurs ne peuvent pas envoyer de requête à /_ah/start. Les instances avec scaling manuel et de base doivent répondre à la requête de démarrage avant de pouvoir traiter toute autre requête. La requête de démarrage peut être utilisée pour les raisons suivantes :

• Pour démarrer un programme qui fonctionne indéfiniment, sans accepter d'autres requêtes
• Pour initialiser une instance avant que le trafic n'augmente

Les instances avec scaling manuel, de base et automatique ne démarrent pas de la même façon. Lorsque vous démarrez une instance avec scaling manuel, App Engine envoie immédiatement une requête /_ah/start à chaque instance. Lorsque vous démarrez une instance d'un service avec scaling de base, App Engine l'autorise à accepter le trafic. Toutefois, la requête /_ah/start n'est envoyée à aucune instance tant qu'App Engine n'a pas reçu sa première requête d'utilisateur. Plusieurs instances avec scaling de base ne sont démarrées que si cela s'avère nécessaire pour gérer l'augmentation du trafic. Les instances avec scaling automatique ne reçoivent pas de requête /_ah/start.

Lorsqu'une instance répond à la requête /_ah/start avec un code d'état HTTP 200–299 ou 404, elle est considérée comme ayant démarré correctement et peut gérer des requêtes supplémentaires. Sinon, App Engine arrête l'instance. Les instances avec scaling manuel redémarrent immédiatement, tandis que les instances avec scaling de base ne redémarrent que pour diffuser le trafic.

Arrêt

Le processus d'arrêt peut être déclenché par différents événements planifiés et non planifiés, tels que les suivants :

• Il y a trop d'instances et pas assez de requêtes d'application (trafic).
• Vous arrêtez manuellement une instance.
• Vous déployez une version mise à jour sur le service.
• L'instance dépasse la quantité de mémoire maximale pour la classe instance_class configurée.
• Votre application dépasse son quota d'heures d'utilisation de l'instance.
• Votre instance est transférée sur un autre ordinateur, soit parce que l'ordinateur qui exécute actuellement l'instance redémarre, soit parce qu'App Engine a déplacé votre instance pour améliorer la répartition de la charge.

L'un des avantages de la plate-forme "Appairer uniquement ce dont vous avez besoin" de l'environnement standard App Engine, comme décrit précédemment dans la section Effectuer un scaling à la baisse, est que le système effectue un autoscaling à la baisse du nombre d'instances lorsqu'il n'y a aucun trafic. App Engine est ainsi une solution rentable pour les petites applications qui ne reçoivent pas de requêtes continues. Lorsqu'une instance doit être arrêtée, les nouvelles requêtes entrantes sont acheminées vers d'autres instances (le cas échéant) et les requêtes en cours de traitement ont le temps de se terminer.

Normalement, App Engine envoie un signal STOP (SIGTERM) au conteneur de l'application. Votre application n'a pas besoin de répondre à cet événement, mais elle peut l'utiliser pour effectuer toutes les actions de nettoyage nécessaires avant l'arrêt du conteneur. Dans des conditions normales, le système attend jusqu'à 3 secondes que l'application s'arrête, puis envoie un signal KILL (SIGKILL). Si votre application ne détecte pas le signal SIGTERM, l'instance est immédiatement arrêtée.

Voici quelques messages d'arrêt d'instance possibles :

[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit

Ces messages de journal n'indiquent aucune condition d'erreur, mais indiquent le processus d'arrêt normal de l'instance. Notez que [start] et Start dans les journaux font référence à un processus de plate-forme nommé start et n'ont rien à voir avec le démarrage d'une instance ou d'une application.

Requêtes de chargement

Lorsque le service App Engine crée une instance pour votre application, l'instance doit d'abord charger les bibliothèques et les ressources requises pour gérer la requête. Cette opération est exécutée lors de la première requête adressée à l'instance, appelée requête de chargement. Dans ce type de requête, votre application fait l'objet d'une initialisation. C'est pour cette raison que la requête prend plus de temps.

Suivez ces bonnes pratiques pour réduire la durée des requêtes de chargement :

• Chargez seulement le code nécessaire au démarrage.
• Accédez le moins possible au disque.
• Dans certains cas, le chargement du code est plus rapide s'il s'effectue à partir d'un fichier zip ou jar, plutôt que depuis de nombreux fichiers distincts.

Requêtes de préchauffage

Les requêtes de préchauffage constituent un type particulier de requête de chargement. Elles chargent préalablement le code de l'application dans une instance, avant l'émission de requêtes en temps réel. Les instances avec scaling manuel ou de base ne reçoivent pas de requête /_ah/warmup.

Consultez la page spécifique à la configuration des requêtes de préchauffage pour en savoir plus sur l'utilisation de ce type de requête.

Disponibilité des instances

App Engine tente d'exécuter indéfiniment les instances avec scaling manuel et scaling de base. Toutefois, pour le moment, la disponibilité de ce type d'instance n'est pas garantie.

NTP avec l'environnement standard App Engine

L'environnement standard App Engine inclut des services NTP (Network Time Protocol) qui utilisent les serveurs NTP de Google. Toutefois, le service NTP n'est pas modifiable.

Gérer les services

En fonction du type de scaling de votre instance, vous pouvez gérer les services et les versions dans la console Google Cloud ou Google Cloud CLI.

Arrêter une version

Chaque version d'App Engine s'exécute dans une ou plusieurs instances, en fonction de la quantité de trafic qu'elles peuvent gérer selon les paramètres configurés.

Cliquez sur l'onglet pour obtenir des instructions concernant l'utilisation de l'outil de votre choix.

  gcloud app versions stop --service=SERVICE VERSION

Supprimer un service

Chaque service peut être configuré afin d'utiliser différents environnements d'exécution et de fonctionner avec des paramètres de performance différents. Vous ne pouvez pas supprimer le service par défaut. La suppression d'un service entraîne également la suppression de toutes les versions associées dans votre projet.

Cliquez sur l'onglet pour obtenir des instructions concernant l'utilisation de l'outil de votre choix.

  gcloud app services delete SERVICE