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)
- Basic
- 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.
| Fonctionnalité | Scaling automatique | Scaling de base | Scaling manuel |
|---|---|---|---|
| Délai avant expiration de la requête |
10 minutes 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.
Pour les anciens environnements d'exécution (Java 8, PHP 5 et Python 2) :
|
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 |
Identique au scaling de base. |
| 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 gestionnaire /_ah/stop est défini, il dispose de 30 secondes pour mettre fin à son exécution 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. |
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 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 startetgcloud app versions stop. - utiliser le service Modules.
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_classconfiguré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.
Lorsqu'une instance doit être arrêtée, App Engine envoie un signalKILL (SIGKILL) qui met fin à l'instance.
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.
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.
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.