View a markdown version of this page

Définir la préparation par défaut d'instance d'un groupe Auto Scaling - Amazon EC2 Auto Scaling

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.

Définir la préparation par défaut d'instance d'un groupe Auto Scaling

CloudWatch collecte et regroupe les données d'utilisation, telles que le processeur et le réseau I/O, sur vos instances Auto Scaling. Vous utilisez ces métriques pour créer des politiques de mise à l'échelle qui ajustent le nombre d'instances de votre groupe Auto Scaling lorsque la valeur de la métrique sélectionnée augmente et diminue.

Vous pouvez spécifier combien de temps après qu'une instance a atteint l'InServiceétat qu'elle attend avant de fournir des données d'utilisation aux mesures agrégées. Cette durée spécifiée est appelée le préchauffage de l'instance par défaut. Cela évite que la mise à l'échelle dynamique ne soit affectée par les métriques relatives à des instances individuelles qui ne gèrent pas encore le trafic applicatif et qui pourraient connaître une utilisation temporairement élevée des ressources de calcul.

Pour optimiser les performances de vos politiques de suivi des cibles et de dimensionnement des étapes, nous vous recommandons vivement d'activer et de configurer le préchauffage d'instance par défaut. Il n'est ni activé ni configuré par défaut.

Lorsque vous activez le préchauffage d'instance par défaut, n'oubliez pas que si votre groupe Auto Scaling est configuré pour utiliser une politique de maintenance des instances, ou si vous utilisez une actualisation d'instance pour remplacer des instances, vous pouvez empêcher que les instances ne soient prises en compte dans le calcul du pourcentage sain minimum avant la fin de leur initialisation.

Considérations sur les performances de la mise à l’échelle

Il est utile que la plupart des applications aient un temps de préchauffage d'instance par défaut qui s'applique à toutes les fonctionnalités, plutôt que des temps de préchauffage différents pour différentes fonctionnalités. Par exemple, si vous ne définissez pas de préchauffage d'instance par défaut, la fonction d'actualisation de l'instance utilise la période de grâce du bilan de santé comme durée de préchauffage par défaut. Si vous avez des politiques de suivi des cibles et de dimensionnement par étapes, elles utilisent la valeur définie pour le temps de recharge par défaut comme temps de préchauffage par défaut. Si vous avez des politiques de dimensionnement prédictif, elles n'ont pas de temps de préchauffage par défaut.

Pendant que les instances se réchauffent, vos politiques de dimensionnement dynamique sont redimensionnées uniquement si la valeur métrique des instances qui ne sont pas en train de se réchauffer est supérieure au seuil d'alarme maximal de la politique (ou à l'utilisation cible d'une politique de dimensionnement de suivi des cibles). Si la demande diminue, la mise à l'échelle dynamique devient plus prudente afin de protéger la disponibilité de votre application. Cela bloque l'échelle des activités pour une mise à l'échelle dynamique jusqu'à ce que les nouvelles instances aient fini de se réchauffer.

Lors de la mise à l'échelle, Amazon EC2 Auto Scaling prend en compte les instances en cours d'échauffement dans le cadre de la capacité du groupe lorsqu'il décide du nombre d'instances à ajouter au groupe. Par conséquent, de multiples violations d'alarme nécessitant l'ajout d'une capacité similaire entraînent une seule activité de mise à l'échelle. L'intention est de continuer à évoluer, sans pour autant le faire de manière excessive.

Si le préchauffage d'instance par défaut n'est pas activé, le temps qu'une instance attend avant d'envoyer des métriques CloudWatch et de les comptabiliser dans la capacité actuelle varie d'une instance à l'autre. Il est donc possible que vos politiques de dimensionnement fonctionnent de manière imprévisible par rapport à la charge de travail réelle qui se produit.

Prenons l’exemple d’une application avec un modèle de charge de travail intermittente récurrent. Une politique de mise à l’échelle prédictive est utilisée pour prendre des décisions récurrentes quant à l’augmentation du nombre d’instances. Comme il n'existe pas de temps de préchauffage par défaut pour les politiques de dimensionnement prédictif, les instances commencent immédiatement à contribuer aux métriques agrégées. Si ces instances utilisent davantage de ressources au démarrage, l’ajout d’instances peut entraîner une hausse des métriques agrégées. En fonction du temps nécessaire à la stabilisation de l’utilisation, cela peut avoir un impact sur les politiques de mise à l’échelle dynamique utilisant ces métriques. Si le seuil d’alarme supérieur d’une politique de mise à l’échelle dynamique est dépassé, la taille du groupe augmente à nouveau. Pendant la mise en place des nouvelles instances, l'échelle des activités sera bloquée.

Choisissez le temps de préchauffage par défaut de l'instance

Pour définir la préparation d’instance par défaut, il est essentiel de déterminer le temps dont vos instances ont besoin pour terminer leur initialisation et pour que la consommation de ressources se stabilise une fois qu’elles ont atteint l’état InService. Lorsque vous choisissez le temps de préchauffage de l'instance, essayez de maintenir un équilibre optimal entre la collecte de données d'utilisation pour le trafic légitime et la réduction de la collecte de données associée à des pics d'utilisation temporaires au démarrage.

Supposons qu’un groupe Auto Scaling soit associé à un équilibreur de charge Elastic Load Balancing. Lorsque le lancement des nouvelles instances est terminé, elles sont enregistrées dans l’équilibreur de charge avant d’entrer dans l’état InService. Une fois que les instances passent à l'état InService, la consommation de ressources peut encore connaître des pics temporaires et avoir besoin de temps pour se stabiliser. Par exemple, la consommation de ressources pour un serveur d'applications qui doit télécharger et mettre en cache des ressources volumineuses prend plus de temps à stabiliser qu'un serveur Web léger sans ressources volumineuses à télécharger. La préparation d’instance fournit le délai nécessaire à la stabilisation de la consommation de ressources.

Important

Si vous n'êtes pas sûr du temps de préchauffage dont vous avez besoin, vous pouvez commencer par 300 secondes. Puis diminuez-le ou augmentez-le progressivement jusqu'à obtenir les meilleures performances de mise à l'échelle pour votre application. Vous devrez peut-être le faire plusieurs fois pour bien faire les choses. Sinon, si vous avez des politiques de dimensionnement qui ont leur propre temps de préchauffage (EstimatedInstanceWarmup), vous pouvez utiliser cette valeur pour commencer. Pour de plus amples informations, veuillez consulter Trouvez des politiques de dimensionnement avec un temps de préchauffage d'instance défini au préalable.

Vous pourriez également envisager d’utiliser des hooks de cycle de vie pour les cas d’utilisation dans lesquels vous avez des tâches de configuration ou des scripts à exécuter au démarrage. Les hooks de cycle de vie peuvent retarder la mise en service des instances jusqu’à ce que leur initialisation soit terminée. Ils sont particulièrement utiles si vous disposez de scripts d'amorçage qui nécessitent un certain temps. Si vous ajoutez un hook de cycle de vie, vous pouvez réduire la valeur de la préparation d’instance par défaut. Pour plus d'informations sur l'utilisation des hooks de cycle de vie, consultez Hooks de cycle de vie Amazon EC2 Auto Scaling.