Accélérer le provisionnement des capacités des clusters Amazon ECS auprès des fournisseurs de capacité sur Amazon EC2 - Amazon Elastic Container Service

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.

Accélérer le provisionnement des capacités des clusters Amazon ECS auprès des fournisseurs de capacité sur Amazon EC2

Les clients qui exécutent Amazon ECS sur Amazon EC2 peuvent tirer parti d'Amazon ECS Cluster Auto Scaling (CAS) pour gérer le dimensionnement des groupes Amazon EC2 Auto Scaling (ASG). Avec CAS, vous pouvez configurer Amazon ECS pour adapter automatiquement votre ASG et vous concentrer uniquement sur l'exécution de vos tâches. Amazon ECS veillera à ce que l'ASG évolue en fonction des besoins, sans qu'aucune autre intervention ne soit requise. Les fournisseurs de capacité Amazon ECS sont utilisés pour gérer l'infrastructure de votre cluster en veillant à ce qu'il y ait suffisamment d'instances de conteneur pour répondre aux demandes de votre application. Pour en savoir plus sur le fonctionnement d'Amazon ECS CAS, consultez Deep Dive on Amazon ECS Cluster Auto Scaling.

Comme le CAS repose sur une intégration CloudWatch basée sur l'intégration avec ASG pour ajuster la capacité du cluster, il présente une latence inhérente associée à la publication des CloudWatch métriques, CapacityProviderReservation au temps nécessaire pour que la métrique franchisse les CloudWatch alarmes (haute et faible) et au temps nécessaire à une EC2 instance Amazon récemment lancée pour se réchauffer. Vous pouvez prendre les mesures suivantes pour rendre le CAS plus réactif et accélérer les déploiements :

Dimensionnement par étapes du fournisseur de capacités

Les fournisseurs de capacité Amazon ECS finiront par fournir grow/shrink les instances de conteneur répondant aux exigences de votre application. Le nombre minimum d'instances qu'Amazon ECS lancera est fixé à 1 par défaut. Cela peut prolonger la durée de vos déploiements, si plusieurs instances sont nécessaires pour placer vos tâches en attente. Vous pouvez augmenter le minimumScalingStepSizeen utilisant l'API Amazon ECS pour augmenter le nombre minimum d'instances qu'Amazon ECS fait évoluer ou non à la fois. Une maximumScalingStepSizevaleur trop faible peut limiter le nombre d'instances de conteneur augmentées ou dédimensionnées à la fois, ce qui peut ralentir vos déploiements.

Note

Cette configuration n'est actuellement disponible qu'en utilisant le CreateCapacityProviderou UpdateCapacityProvider APIs.

Période de préchauffage de l'instance

La période de préchauffage de l'instance est la période après laquelle une EC2 instance Amazon récemment lancée peut contribuer aux CloudWatch statistiques du groupe Auto Scaling. Une fois la période de préchauffage spécifiée expirée, l'instance est prise en compte dans les métriques agrégées de l'ASG, et CAS procède à 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 en utilisant le CreateCapacityProviderou UpdateCapacityProvider APIs pour une mise à l'échelle plus réactive.

Capacité de réserve

Si votre fournisseur de capacité ne dispose d'aucune instance de conteneur pour placer des tâches, il doit augmenter (augmenter) la capacité du cluster en lançant des EC2 instances Amazon à la volée et en attendant qu'elles démarrent avant de pouvoir y lancer des conteneurs. Cela peut réduire considérablement le taux de lancement des tâches. Deux options s'offrent à vous.

Dans ce cas, le fait de disposer d'une EC2 capacité Amazon disponible déjà lancée et prête à exécuter des tâches augmentera le taux de lancement effectif des tâches. Vous pouvez utiliser la Target Capacity configuration pour indiquer que vous souhaitez conserver de la capacité inutilisée dans vos clusters. Par exemple, en définissant Target Capacity 80 %, vous indiquez que votre cluster a besoin de 20 % de capacité de réserve à tout moment. Cette capacité inutilisée 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é inutilisée 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 Target Capacity configuration pour libérer de la capacité inutilisée, vous pouvez augmenter le nombre de répliques dans votre service en modifiant la métrique de dimensionnement du suivi des cibles ou les seuils de dimensionnement par étapes du dimensionnement automatique 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 dimensionnement associées, consultez les sections Politiques de dimensionnement de Target Tracking ou Politiques de dimensionnement par étapes