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.
Optimisation de l’autoscaling de cluster Amazon ECS
Les clients qui exécutent Amazon ECS sur Amazon EC2 peuvent tirer parti de l’autoscaling de cluster pour gérer la mise à l’échelle des groupes Amazon EC2 Auto Scaling. Grâce à l’autoscaling de cluster, vous pouvez configurer Amazon ECS pour qu’il mette automatiquement à l’échelle votre groupe Auto Scaling, et vous concentrer uniquement sur l’exécution de vos tâches. Amazon ECS veille à ce que le groupe Auto Scaling évolue horizontalement en fonction des besoins, sans qu’aucune autre intervention ne soit requise. Les fournisseurs de capacité Amazon ECS vous permettent de gérer l’infrastructure de votre cluster en s’assurant qu’il y a suffisamment d’instances de conteneur pour répondre aux demandes de votre application. Pour savoir comment fonctionne l’autoscaling de cluster, consultez le billet de blog Deep Dive on Amazon ECS Cluster Auto Scaling
La mise à l'échelle automatique du cluster repose sur une intégration CloudWatch basée sur le groupe Auto Scaling pour ajuster la capacité du cluster. Par conséquent, il a une latence inhérente associée :
-
Publier les CloudWatch statistiques,
-
Le temps nécessaire à la métrique
CapacityProviderReservationpour violer les CloudWatch alarmes (haute et faible) -
au temps nécessaire à la préinitialisation d’une instance Amazon EC2 récemment lancée. Vous pouvez prendre les mesures suivantes pour améliorer la réactivité de l’autoscaling de cluster et accélérer les déploiements :
Mise à l’échelle par étapes du fournisseur de capacités
Les fournisseurs de capacité Amazon ECS grow/shrink fourniront les instances de conteneur répondant aux exigences de votre application. Le nombre minimum d’instances qu’Amazon ECS lancera est fixé à une par défaut. Cela peut allonger la durée de vos déploiements si plusieurs instances sont nécessaires pour placer vos tâches en attente. Vous pouvez augmenter la minimumScalingStepSize via l’API Amazon ECS afin d’accroître le nombre minimum d’instances qu’Amazon ECS peut faire évoluer horizontalement à la fois. Une maximumScalingStepSize trop faible peut limiter le nombre d’instances de conteneur pouvant être mises à l’échelle horizontale, ce qui peut ralentir vos déploiements.
Note
Cette configuration n'est actuellement disponible que via le CreateCapacityProviderou UpdateCapacityProvider APIs.
Durée de préinitialisation de l’instance
La période de préchauffage de l'instance est la période au bout de laquelle une instance Amazon EC2 récemment lancée peut contribuer CloudWatch aux métriques du groupe Auto Scaling. Une fois la période de préinitialisation spécifiée expirée, l’instance est prise en compte dans les mesures agrégées du groupe Auto Scaling, et l’autoscaling de cluster poursuit sa prochaine itération de calculs pour estimer le nombre d’instances requises.
La valeur par défaut instanceWarmupPeriodest de 300 secondes, que vous pouvez configurer à une valeur inférieure via CreateCapacityProviderou UpdateCapacityProvider APIs pour une mise à l'échelle plus réactive. Nous vous recommandons de définir la valeur sur une valeur supérieure à 60 secondes afin d’éviter la surallocation.
Capacité de réserve
Si votre fournisseur de capacité ne dispose d’aucune instance de conteneur pour placer des tâches, il doit accroître (augmenter horizontalement) la capacité du cluster en lançant des instances Amazon EC2 à la volée, puis attendre leur démarrage avant de pouvoir y lancer des conteneurs. Cela peut réduire considérablement la vitesse de lancement des tâches. Vous avez deux options.
Dans ce cas, le fait de disposer d’une capacité Amazon EC2 disponible déjà lancée et prête à exécuter des tâches augmentera la vitesse de lancement effective des tâches. Vous pouvez utiliser la configuration de Target
Capacity pour indiquer que vous souhaitez conserver de la capacité de réserve dans vos clusters. Par exemple, en définissant Target Capacity sur 80 %, vous indiquez que votre cluster a besoin de 20 % de capacité de réserve à tout moment. Cette capacité de réserve peut permettre le lancement immédiat de toutes les tâches autonomes, garantissant ainsi que les lancements de tâches ne sont pas ralentis. L’inconvénient de cette approche est l’augmentation potentielle des coûts liés au maintien de la capacité de réserve des clusters.
Une autre approche que vous pouvez envisager consiste à augmenter la marge de manœuvre de votre service, et non celle du fournisseur de capacité. Cela signifie qu’au lieu de réduire la configuration de Target
Capacity pour lancer de la capacité de réserve, vous pouvez augmenter le nombre de réplicas dans votre service en modifiant la métrique de mise à l’échelle du suivi de cible ou les seuils de mise à l’échelle par étapes de l’autoscaling du service. Notez que cette approche ne sera utile que pour les charges de travail complexes, mais n’aura aucun effet lorsque vous déployez de nouveaux services et que vous passez de 0 à N tâches pour la première fois. Pour plus d’informations sur les politiques de mise à l’échelle associées, consultez les sections Politiques de mise à l’échelle du suivi de cible ou Politiques de mise à l’échelle par étapes dans le Guide du développeur Amazon Elastic Container Service.