Réduisez la latence pour les applications dont le temps de démarrage est long à l'aide de pools chauds - Amazon EC2 Auto Scaling
Concepts de basePrérequisMise à jour les instances d’un groupe chaudRessources connexesLimites

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Réduisez la latence pour les applications dont le temps de démarrage est long à l'aide de pools chauds

Un groupe d'instances pré-initialisées vous permet de réduire la latence de vos applications dont les temps de démarrage sont exceptionnellement longs, du fait par exemple que les instances doivent écrire des quantités massives de données sur disque. Avec les groupes d'instances pré-initialisées, il n'est plus nécessaire de surprovisionner vos groupes Auto Scaling pour réduire la latence et améliorer ainsi les performances des applications. Pour plus d'informations, consultez l'article de blog Scaling your applications faster with EC2 Auto Scaling Warm Pools.

Important

La création d'un groupe d'instances pré-initialisées quand elle n'est pas nécessaire risque d'entraîner des coûts inutiles. Si le temps de démarrage initial n'entraîne pas de problèmes de latence notables pour votre application, vous n'avez probablement pas besoin d'utiliser ce type de groupe.

Rubriques

Concepts de base

Avant de commencer, familiarisez-vous avec les concepts de base ci-dessous :

Pools d'instances pré-initialisées

Ce type de groupe d'instances EC2 pré-initialisées réside à côté d'un groupe Auto Scaling. Chaque fois que votre application doit monter en puissance, le groupe Auto Scaling peut s'appuyer sur le groupe d'instances pré-initialisées pour atteindre la nouvelle capacité souhaitée. Cela vous permet de vous assurer que les instances sont rapidement disponibles pour gérer le trafic des applications, ce qui accélère la réponse à un événement de montée en puissance. Lorsque des instances sont retirées du groupe d'instances pré-initialisées, elles sont comptabilisées dans la capacité souhaitée du groupe. Il s'agit d'une opération de type démarrage à chaud.

Lorsque les instances sont dans le groupe chaud, vos politiques de mise à l’échelle ne montent en puissance que si la valeur métrique des instances qui sont dans l’état InService est supérieure au seuil d’alarme supérieur de la politique de mise à l’échelle (qui est le même que l’utilisation cible d’une politique de suivi des objectifs et d’échelonnement).

Taille d'un groupe d'instances pré-initialisées

Par défaut, la taille d'un groupe d'instances pré-initialisées correspond à la différence entre la capacité maximale du groupe Auto Scaling et sa capacité souhaitée. Par exemple, si la capacité souhaitée de votre groupe Auto Scaling est de 6 et que la capacité maximale correspond à 10, la taille de votre groupe d'instances pré-initialisées est donc de 4 lorsque vous configurez le groupe pour la première fois et qu'il est initialisé.

Pour spécifier séparément la capacité maximale du pool de chaleur, utilisez l'option custom specification (MaxGroupPreparedCapacity) et définissez une valeur personnalisée supérieure à la capacité actuelle du groupe. Si vous fournissez une valeur personnalisée, la taille du pool de chaleur est calculée comme la différence entre la valeur personnalisée et la capacité actuelle souhaitée du groupe. Par exemple, si la capacité souhaitée de votre groupe Auto Scaling est de 6, si la capacité maximale est de 20 et si la valeur personnalisée est de 8, la taille de votre pool de chaleur sera de 2 lorsque vous le configurez pour la première fois et que le pool sera initialisé.

Il se peut que vous n'ayez besoin d'utiliser l'option custom specification (MaxGroupPreparedCapacity) que lorsque vous travaillez avec de grands groupes Auto Scaling afin de gérer les avantages financiers liés à un pool de chaleur. Par exemple, un groupe Auto Scaling avec 1 000 instances, une capacité maximale de 1 500 (pour fournir une capacité supplémentaire en cas de pics de trafic d'urgence) et un groupe d'instances pré-initialisées de 100 instances peut vous aider à atteindre vos objectifs mieux que de garder 500 instances réservées pour une utilisation future dans le groupe d'instances pré-initialisées.

Taille minimale du groupe d'instances pré-initialisées.

Envisagez d'utiliser le paramètre de taille minimale pour définir de manière statique le nombre minimal d'instances à conserver dans le groupe. Aucune taille minimale n'est définie par défaut.

État des instances de groupe d'instances pré-initialisées

Vous pouvez conserver des instances dans le groupe d'instances pré-initialisées dans l'un des trois états suivants : Stopped, Running ou Hibernated. Conserver les instances dans l'état Stopped est un moyen efficace de limiter les coûts. Lorsque les instances sont interrompues, vous ne payez que pour les volumes utilisés et les adresses IP élastiques attachées aux instances.

Vous pouvez également conserver les instances dans un état Hibernated pour arrêter les instances sans supprimer leur contenu de mémoire (RAM). Lorsqu'une instance est mise en veille prolongée, cela signale au système d'exploitation qu'il doit enregistrer le contenu de votre RAM sur votre volume racine Amazon EBS. Lorsque l'instance est redémarrée, le volume racine est restauré à son état précédent et le contenu de la RAM est rechargé. Pendant que les instances sont en veille prolongée, vous ne payez que pour les volumes EBS, y compris le stockage du contenu RAM, et les adresses IP Elastic attachées aux instances.

Garder des instances dans un état Running à l'intérieur du groupe d'instances pré-initialisées est également possible, mais est fortement déconseillé pour éviter d'encourir des frais inutiles. Lorsque les instances sont arrêtées ou mises en veille prolongée, vous économisez le coût des instances elles-mêmes. Vous payez les instances uniquement lorsqu'elles sont en cours d'exécution.

Hooks de cycle de vie

Les hooks de cycle de vie vous permettent de mettre des instances dans un état d’attente afin que vous puissiez effectuer des actions personnalisées sur les instances. Les actions personnalisées sont exécutées au lancement des instances ou avant qu'elles ne se terminent.

Dans une configuration de groupe chaud, les hooks de cycle de vie retardent l’arrêt ou la mise en veille prolongée des instances et leur mise en service pendant un événement de montée en puissance jusqu’à ce que leur initialisation soit terminée. Si vous ajoutez un groupe d'instances pré-initialisées à votre groupe Auto Scaling sans hook de cycle de vie, les instances dont l'initialisation prend beaucoup de temps peuvent être arrêtées ou mises en veille prolongée, puis mises en service pendant un événement de montée en puissance avant qu'elles ne soient prêtes.

Politique de réutilisation d'instance

Par défaut, Amazon EC2 Auto Scaling résilie vos instances lors de la mise à l'échelle horizontale de votre groupe Auto Scaling. Ensuite, il lance de nouvelles instances dans le groupe d'instances pré-initialisées pour remplacer celles qui ont été résiliées.

Si vous souhaitez plutôt renvoyer des instances vers le groupe d'instances pré-initialisées, vous pouvez spécifier une politique de réutilisation d'instance. Cela vous permet de réutiliser des instances déjà configurées pour servir le trafic des applications. Pour s'assurer que votre groupe d'instances pré-initialisées n'est pas surapprovisionné, Amazon EC2 Auto Scaling peut résilier des instances dans le groupe d'instances pré-initialisées pour réduire sa taille lorsque celle-ci est plus grande que nécessaire en fonction de ses paramètres. Lors de la résiliation d'instances dans le groupe d'instances pré-initialisées, il utilise la politique de résiliation par défaut pour choisir les instances à résilier en premier.

Important

Si vous souhaitez mettre en veille prolongée des instances mises à l'échelle horizontale et que le groupe Auto Scaling contient déjà des instances, celles-ci doivent répondre aux exigences de la mise en veille prolongée des instances. Si ce n'est pas le cas, lorsque les instances retourneront dans le groupe d'instances pré-initialisées, elles seront arrêtées au lieu d'être mises en veille prolongée.

Note

Actuellement, vous ne pouvez spécifier une politique de réutilisation d'instance qu'à l'aide de la AWS CLI ou d'un kit SDK. Cette fonction n'est pas disponible depuis la console.

Prérequis

Avant de créer un groupe chaud pour votre groupe Auto Scaling, déterminez comment vous allez utiliser les hooks de cycle de vie pour initialiser de nouvelles instances avec un état initial approprié.

Pour effectuer des actions personnalisées sur des instances alors qu’elles sont en état d’attente à cause d’un hook de cycle de vie, deux options s’offrent à vous :

  • Pour les scénarios simples où vous souhaitez exécuter des commandes sur vos instances au lancement, vous pouvez inclure un script de données utilisateur lorsque vous créez un modèle de lancement ou une configuration de lancement pour votre groupe Auto Scaling. Les scripts de données utilisateur ne sont que des scripts shell standards ou des directives cloud-init exécutées par cloud-init au démarrage de vos instances. Le script peut également contrôler le moment où vos instances passent à l'état suivant en utilisant l'ID de l'instance sur laquelle il s'exécute. Si ce n'est pas le cas, mettez à jour le script pour récupérer l'ID de l'instance à partir de ses métadonnées. Pour plus d'informations, consultez la section Récupérer les métadonnées d'une instance dans le guide de l'utilisateur Amazon EC2.

    Astuce

    Pour exécuter des scripts de données utilisateur lors du redémarrage d'une instance, les données utilisateur doivent être au format MIME en plusieurs parties et spécifier les éléments suivants dans la section #cloud-config des données utilisateur :

    #cloud-config
cloud_final_modules:
 - [scripts-user, always]

  • Pour les scénarios avancés dans lesquels vous avez besoin d'un service, par exemple AWS Lambda pour agir lorsque des instances entrent ou sortent du pool de chaleur, vous pouvez créer un lien de cycle de vie pour votre groupe Auto Scaling et configurer le service cible pour effectuer des actions personnalisées en fonction des notifications relatives au cycle de vie. Pour plus d’informations, consultez Cibles de notification prises en charge.

Préparer les instances à la mise en veille prolongée

Pour préparer les instances Auto Scaling à utiliser l'état du Hibernated pool, créez un nouveau modèle de lancement ou une nouvelle configuration de lancement correctement configuré pour prendre en charge l'hibernation des instances, comme décrit dans la rubrique Conditions préalables à l'hibernation du guide de l'utilisateur Amazon EC2. Ensuite, associez le nouveau modèle de lancement ou la nouvelle configuration de lancement au groupe Auto Scaling et lancez une actualisation d'instance pour remplacer les instances associées à un précédent modèle de lancement ou configuration de lancement. Pour plus d’informations, consultez Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling.

Mise à jour les instances d’un groupe chaud

Pour mettre à jour les instances d’un groupe chaud, vous devez créer un nouveau modèle de lancement ou une nouvelle configuration de lancement et l’associer au groupe Auto Scaling. Toutes les nouvelles instances sont lancées à l'aide de la nouvelle AMI et d'autres mises à jour spécifiées dans le modèle de lancement ou la configuration de lancement, mais les instances existantes ne sont pas affectées.

Pour forcer le lancement d’instances de groupe chaud de remplacement qui utilisent le nouveau modèle de lancement ou la nouvelle configuration de lancement, vous pouvez lancer une actualisation de l’instance pour effectuer une mise à jour progressive de votre groupe. Une actualisation d'instance remplace d'abord les instances InService. Elle remplace ensuite les instances du groupe d'instances pré-initialisées. Pour plus d’informations, consultez Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling.

Vous pouvez consulter notre GitHubréférentiel pour obtenir des exemples de crochets de cycle de vie pour les piscines chaudes.

Limites

  • Vous ne pouvez pas ajouter un pool de chaleur à un groupe Auto Scaling doté d'une politique d'instances mixtes. Vous ne pouvez pas non plus ajouter un warm pool à un groupe Auto Scaling doté d'un modèle de lancement ou d'une configuration de lancement qui demande des instances Spot.

  • Amazon EC2 Auto Scaling peut placer une instance dans l'état Stopped ou Hibernated que si elle est dotée d'un volume Amazon EBS comme périphérique racine. Les instances qui utilisent des stockages d'instance pour le périphérique racine ne peuvent pas être arrêtées ou mises en veille prolongée.

  • Amazon EC2 Auto Scaling ne peut mettre une instance dans un Hibernated état que si elle répond à toutes les exigences répertoriées dans la rubrique relative aux conditions préalables à l'hibernation du guide de l'utilisateur Amazon EC2.

  • Si votre groupe d'instances pré-initialisées est épuisé lors d'un événement de montée en puissance, les instances sont lancées directement dans le groupe Auto Scaling (démarrage à froid). Le démarrage à froid se produit également en cas d'épuisement de la capacité d'une zone de disponibilité.

  • Si une instance du warm pool rencontre un problème pendant le processus de lancement, l'empêchant d'atteindre InService cet état, l'instance sera considérée comme un échec de lancement et sera interrompue. Cela s'applique quelle que soit la cause sous-jacente, telle qu'une erreur de capacité insuffisante ou tout autre facteur.

  • Si vous essayez d'utiliser un pool d'instances pré-initialisées avec Amazon Elastic Kubernetes Service (Amazon EKS), les instances qui sont toujours en cours d'initialisation peuvent s'enregistrer auprès de votre cluster Amazon EKS. Par conséquent, le cluster peut planifier des tâches sur une instance alors qu'il se prépare à être arrêté ou mis en veille prolongée.

  • De même, si vous essayez d'utiliser un groupe d'instances pré-initialisées avec un cluster Amazon ECS, les instances peuvent s'enregistrer auprès du cluster avant la fin de leur initialisation. Pour résoudre ce problème, vous devez configurer un modèle de lancement ou une configuration de lancement qui inclut une variable de configuration d'agent spéciale dans les données utilisateur. Pour plus d'informations, consultez Utilisation d'un groupe d'instances pré-initialisées pour votre groupe Auto Scaling dans le Guide du développeur Amazon Elastic Container Service.

  • La prise en charge de l'hibernation pour les pools chauds est disponible dans toutes les zones commerciales Régions AWS où Amazon EC2 Auto Scaling et Hibernation sont disponibles, à l'exception des suivantes :

    • Asie-Pacifique (Hyderabad)

    • Asie-Pacifique (Melbourne)

    • Canada Ouest (Calgary)

    • Région Chine (Beijing)

    • Région Chine (Ningxia)

    • Europe (Espagne)

    • Israël (Tel Aviv)