La compatibilité de Python 2 n'est plus assurée par la communauté. Nous vous recommandons de migrer les applications Python 2 vers Python 3.

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.

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
  • De base
  • Manuel

Vous spécifiez le type de scaling dans le fichier app.yaml de votre application.

Autoscaling
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 permanence.
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.
Vous trouverez un comparatif des caractéristiques de performances des trois types de scaling dans le tableau ci-dessous :

Fonctionnalité Autoscaling Scaling de base Scaling manuel
Délai avant expiration de la requête 10 minutes pour les requêtes HTTP et les tâches de file d'attente de tâches. Si votre application ne renvoie pas de requête dans ce délai, App Engine interrompt le gestionnaire de requêtes et émet une erreur que votre code doit gérer.

Pour les anciens environnements d'exécution (Java 8, PHP 5 et Python 2) :

  • Le délai avant expiration des tâches de file d'attente et des requêtes des tâches Cron est de 10 minutes.
  • Le délai avant expiration des autres requêtes HTTP est de 1 minute.
24 heures pour les requêtes HTTP et les tâches en file d'attente. Si votre application ne renvoie pas de requête dans ce délai, App Engine interrompt le gestionnaire de requêtes et émet une erreur que votre code doit gérer.

Une instance de base peut choisir de gérer /_ah/start et d'exécuter un programme ou un script pendant plusieurs heures sans renvoyer de code de réponse HTTP.

Identique au scaling de base.
Threads en arrière-plan Non autorisés. Autorisés. Autorisés.
Résidence Les instances sont arrêtées en fonction des schémas d'utilisation. Les instances sont arrêtées en fonction du paramètre idle_timeout. Si une instance a été inactive (ce qui signifie, par exemple, qu'elle n'a pas reçu de requête) pendant une durée supérieure à celle de idle_timeout, elle est arrêtée. Les instances restent en mémoire de sorte que l'état est préservé entre les requêtes. Lorsque des instances sont redémarrées, une requête /_ah/stop s'affiche dans les journaux. Si un hook d'arrêt est enregistré, il dispose de 30 secondes pour s'exécuter avant que l'arrêt ne se produise.
Démarrage et arrêt Les instances sont créées à la demande pour la gestion des requêtes et désactivées automatiquement en cas d'inactivité. Les instances sont créées à la demande pour la gestion des requêtes et désactivées automatiquement en cas d'inactivité, en fonction du paramètre de configuration idle_timeout. Une instance qui est arrêtée manuellement dispose de 30 secondes pour terminer le traitement des requêtes avant d'être arrêtée de manière forcée. App Engine envoie automatiquement une requête de démarrage aux instances sous la forme d'une requête GET vide adressée à /_ah/start. Comme avec le scaling de base, une instance qui est arrêtée manuellement dispose de 30 secondes pour terminer le traitement des requêtes avant d'être arrêtée de manière forcée.
Adressage des instances Les instances sont anonymes. L'instance "i" de la version "v" du service "s" peut être adressée à l'URL : https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com. Si vous avez configuré un mappage générique de sous-domaines pour un domaine personnalisé, vous pouvez également adresser un service ou l'une de ses instances via une URL au format https://s.domain.com ou https://i.s.domain.com. Vous pouvez stocker l'état en cache de manière fiable dans chaque instance et le récupérer dans les requêtes ultérieures. Identique au scaling de base.
Scaling App Engine adapte automatiquement le nombre d'instances en réponse au volume à traiter. Ce scaling tient compte des paramètres automatic_scaling fournis pour chaque version dans le fichier de configuration. Un service avec scaling de base est configuré en définissant le nombre maximal d'instances dans le paramètre max_instances du paramètre basic_scaling. Le nombre d'instances actives évolue avec le volume à traiter. Vous pouvez configurer le nombre d'instances de chaque version dans le fichier de configuration du service. Le nombre d'instances correspond généralement à la taille d'un ensemble de données en mémoire ou au débit souhaité pour un travail hors connexion. Vous pouvez ajuster très rapidement le nombre d'instances d'une version avec scaling manuel, sans arrêter les instances en cours d'exécution, à l'aide de la fonction set_num_instances de l'API Modules.

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.

Paramètres de scaling automatique Description
Utilisation du processeur cible Définit le seuil d'utilisation du processeur à partir duquel d'autres instances démarrent pour gérer le trafic.
Utilisation du débit cible Définit le seuil de débit pour le nombre de requêtes simultanées au-delà duquel d'autres instances démarrent pour gérer le trafic.
Nombre maximal de requêtes simultanées Définit le nombre de requêtes simultanées qu'une instance peut accepter avant que le programmeur ne génère une nouvelle instance.

Regardez la vidéo sur les nouveaux 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é.

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

Start-up

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 :

  • Vous arrêtez manuellement une instance.
  • Vous déployez une version mise à jour sur le service.
  • La taille de mémoire maximale de l'instance est dépassée pour la classe instance_class.
  • 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.

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 le cadre de 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. Des pannes matérielles et logicielles à l'origine d'arrêts anticipés ou de redémarrages fréquents risquent de se produire sans avertissement. Par ailleurs, leur résolution peut prendre beaucoup de temps. Vous devez donc configurer votre application de sorte qu'elle tolère ces pannes.

Voici quelques stratégies efficaces pour éviter les temps d'arrêt dus aux redémarrages des instances :

  • Réduisez le temps nécessaire au redémarrage des instances existantes ou au démarrage des nouvelles instances.
  • Pour les calculs de longue durée, créez régulièrement des points de contrôle afin de pouvoir reprendre l'activité à partir de ces derniers.
  • Votre application doit être "sans état" pour que rien ne soit stocké sur l'instance.
  • Servez-vous de files d'attente pour exécuter des tâches asynchrones.
  • Si vous configurez vos instances pour le scaling manuel , procédez comme suit :
    • Utilisez l'équilibrage de charge sur plusieurs instances.
    • Configurez plus d'instances que nécessaire pour gérer le trafic normal.
    • Mettez en place une logique de secours qui utilise les résultats mis en cache lorsqu'une instance avec scaling manuel n'est pas disponible.