Mode de gestion des instances

Les instances sont les unités de calcul dont se sert App Engine pour procéder au scaling automatique d'une application. À tout moment, votre application peut être exécutée sur une ou plusieurs instances, les demandes étant réparties sur toutes les instances.

Vos instances avec scaling manuel devraient s'exécuter indéfiniment, mais il n'y a aucune garantie de disponibilité, car les instances peuvent être arrêtées en raison de défaillances ou de redémarrage des mises à jour. Les pannes matérielles ou logicielles qui entraînent une résiliation anticipée ou des redémarrages fréquents peuvent survenir sans avertissement et prendre un temps considérable à résoudre.

Toutes les instances flexibles peuvent être redémarrées chaque semaine si des mises à jour sont disponibles. Cette planification n'est pas garantie. Lors des redémarrages, les mises à jour critiques, à compatibilité ascendante, sont automatiquement déployées sur le système d'exploitation sous-jacent. L'image de votre application restera la même après les redémarrages.

Vérification de l'état

App Engine envoie des requêtes de vérification d'état périodiques pour confirmer qu'une instance est en cours d'exécution et pour vérifier qu'une instance est entièrement démarrée et prête à accepter les requêtes entrantes. Par défaut, ces vérifications d'état sont activées et appelées vérifications d'état fractionnées. Une instance qui reçoit une vérification d'état doit y répondre dans un intervalle de temps spécifié.

Si vous devez étendre le comportement par défaut des vérifications d'état fractionnées à votre application, vous pouvez personnaliser le fichier app.yaml pour configurer deux types de vérifications d'état :

Les vérifications d'activité détectent qu'une instance de VM et son conteneur sont en cours d'exécution. Lorsqu'une instance de VM échoue à la vérification d'activité, elle est automatiquement redémarrée. Les vérifications d'activité peuvent échouer en raison des seuils et des intervalles de temps configurés, ou en raison du plantage du conteneur.
Les vérifications d'aptitude détectent qu'une instance de VM est prête à accepter les requêtes entrantes. Si une instance de VM échoue à la vérification d'aptitude, cela signifie que l'instance de VM n'a pas terminé son démarrage et qu'elle n'est pas prête à recevoir des requêtes. Une fois que l'instance de VM a réussi la vérification d'aptitude et qu'elle a terminé son démarrage, elle est ajoutée au pool d'instances disponibles.

Pour en savoir plus sur les comportements des vérifications d'état fractionnées, consultez le guide Migrer vers des vérifications d'état fractionnées.

Au fil des vérifications d'état, les journaux App Engine peuvent indiquer que l'instance se trouve dans l'un des états suivants :

Opérationnel L'instance a reçu les requêtes de vérification d'état et les traite. Un état opérationnel indique que l'instance dispose de plus de 820 Mo d'espace disque disponible et doit répondre à une vérification d'état avec le code d'état HTTP 200.
Non opérationnel L'instance a refusé les requêtes de vérification d'état et n'a pas répondu à un nombre spécifié de requêtes de vérification d'état consécutives. App Engine continue d'envoyer des requêtes de vérification d'état et redémarre l'instance si une instance non opérationnelle continue de ne pas répondre à un nombre prédéterminé de vérifications d'état consécutives.
Lameduck. L'instance est programmée pour s'arrêter ou redémarrer. Lors des arrêts, l'instance termine les requêtes en cours et refuse les nouvelles requêtes. L'application renvoie un code 503 pour indiquer que l'instance n'est pas en mesure de gérer les requêtes. Avant l'arrêt ou le redémarrage d'une instance, le script d'arrêt dispose d'un temps d'exécution limité et ne peut pas être configuré pour être plus court ou plus long.
App Lameduck. L'instance se prépare à diffuser le trafic. L'application renvoie un code 503 pour indiquer que l'instance n'est pas en mesure de gérer les requêtes. Lorsqu'une instance de VM a terminé le démarrage et qu'elle est prête à diffuser le trafic, l'instance devient opérationnelle et traite les requêtes. Si une instance de VM ne démarre pas dans le temps, elle passe à l'état "non opérationnel" et est supprimée.

Les comportements "Lameduck" et "App Lameduck" font partie d'un processus normal par lequel passe l'instance de VM.

Contrôle de l'utilisation des ressources

La page "Instances" de la console Google Cloud offre de la visibilité sur les performances de vos instances. Vous pouvez vérifier l'utilisation de la mémoire et du processeur de chaque instance, la disponibilité, le nombre de requêtes et d'autres statistiques. Vous pouvez également lancer manuellement le processus d'arrêt pour n'importe quelle instance.

NTP avec l'environnement flexible App Engine

L'environnement flexible App Engine inclut des services NTP (Network Time Protocol) qui utilisent des serveurs NTP de Google. Toutefois, les services NTP de l'environnement flexible ne sont pas modifiables.

Emplacement des instances

Les instances sont automatiquement localisées par région géographique en fonction des paramètres du projet.

Scaling d'instance

Lorsqu'une application est en cours d'exécution, les requêtes entrantes sont routées vers une instance existante ou nouvelle du service/de la version appropriée. Chaque version active doit avoir au moins une instance en cours d'exécution ; le type de scaling d'un service ou d'une version contrôle la manière dont les instances supplémentaires sont créées. 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 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.