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.
# Pratiques exemplaires en matière d’autoscaling et de gestion des capacités Amazon ECS
Vous pouvez exécuter des charges de travail d’applications conteneurisées de toutes tailles sur Amazon ECS. Cela inclut des environnements de test minimaux et des environnements de production de grande envergure qui fonctionnent à l’échelle mondiale.
Avec Amazon ECS, comme tous les AWS services, vous ne payez que pour ce que vous utilisez. Lorsque vous élaborez votre application de manière appropriée, vous pouvez réduire les coûts en ne consommant que les ressources dont vous avez besoin au moment où vous en avez besoin.
Les recommandations suivantes vous montrent comment exécuter vos charges de travail Amazon ECS afin d’atteindre vos objectifs de niveau de service tout en fonctionnant de manière rentable.
**Topics**
+ [Détermination de la taille d’une tâche pour Amazon ECS](capacity-tasksize-best-practice.md)
+ [Optimisation de l’autoscaling d’un service Amazon ECS](capacity-autoscaling-best-practice.md)
+ [Capacité et disponibilité d’Amazon ECS](capacity-availability-best-practice.md)
+ [Capacité de cluster Amazon ECS](capacity-cluster-best-practice.md)
+ [Choix de la taille des tâches Fargate pour Amazon ECS](fargate-task-size-best-practice.md)
+ [Accélération de l’allocation des capacités des clusters Amazon ECS avec les fournisseurs de capacité sur Amazon EC2](capacity-cluster-speed-up-ec2-best-practice.md)
# Détermination de la taille d’une tâche pour Amazon ECS
L’un des choix les plus importants lorsque vous déployez des conteneurs sur Amazon ECS concerne la taille de vos conteneurs et de vos tâches. La taille de vos conteneurs et de vos tâches est essentielle pour la mise à l’échelle et la planification des capacités.
Amazon ECS utilise deux métriques de ressources pour la capacité : l’UC et la mémoire. Amazon ECS mesure l’UC en unités de 1/1 024 d’un vCPU complet (1 024 unités équivalant à 1 vCPU entier). Amazon ECS mesure la mémoire en mégaoctets.
Dans la définition de votre tâche, vous pouvez déclarer des réserves et des limites de ressources.
Lorsque vous déclarez une réserve, vous déclarez la quantité minimale de ressources requise par une tâche. Votre tâche reçoit au moins la quantité de ressources que vous demandez. Votre application peut utiliser plus d’UC ou de mémoire que la réserve que vous déclarez. Cependant, cette capacité est soumise aux limites que vous avez également déclarées.
L’utilisation d’une quantité supérieure à la réserve est appelée éclatement (bursting). L’éclatement signifie que votre application utilise plus de ressources que ce que vous avez réservé, mais reste dans les limites que vous avez déclarées. Amazon ECS garantit les réserves. Par exemple, si vous utilisez des instances Amazon EC2 pour fournir de la capacité, Amazon ECS ne place aucune tâche sur une instance dans laquelle il ne peut pas honorer la réserve.
Une limite est la quantité maximale d’unités d’UC ou de mémoire que votre conteneur ou votre tâche peut utiliser. Si votre conteneur essaie d’utiliser plus d’UC que cette limite, Amazon ECS le limite. Si votre conteneur essaie d’utiliser plus de mémoire que cette limite, Amazon ECS l’arrête.
Choisir ces valeurs peut s’avérer difficile. Les valeurs les mieux adaptées à votre application dépendent dans une large mesure des besoins en ressources de votre application.
Le test de charge de votre application est la clé d’une planification réussie des besoins en ressources. Les tests de charge vous aident à mieux comprendre les exigences de votre application.
## Applications sans état
Pour les applications sans état qui sont mises à l’échelle horizontalement, telles qu’une application située derrière un équilibreur de charge, nous vous recommandons de déterminer d’abord la quantité de mémoire consommée par votre application lorsqu’elle traite des requêtes.
Pour ce faire, vous pouvez utiliser des outils traditionnels tels que `ps` ou `top`. Vous pouvez également utiliser des solutions de surveillance telles que CloudWatch Container Insights.
Lorsque vous déterminez une réserve d’UC, réfléchissez à la manière dont vous souhaitez mettre votre application à l’échelle en fonction de vos besoins métier.
Vous pouvez utiliser des réserves d’UC plus petites, telles que 256 unités d’UC (soit 1/4 de vCPU), pour procéder à une augmentation horizontale précise tout en minimisant les coûts. Mais ils risquent de ne pas se mettre à l’échelle assez rapidement pour répondre à des pics de demande importants.
Vous pouvez utiliser des réserves d’UC plus importantes pour procéder à une augmentation ou à une réduction horizontale plus rapidement. Cela vous permet de faire face plus rapidement aux pics de demande. Cependant, les réserves d’UCs plus importantes coûtent plus cher.
## Autres applications
Pour les applications qui ne sont pas mises à l’échelle horizontalement, telles que les travailleurs individuels ou les serveurs de base de données, la capacité disponible et le coût sont vos principaux facteurs à prendre en compte.
Choisissez la quantité de mémoire et d’UC en fonction des tests de charge qui indiquent que vous avez besoin pour gérer le trafic et atteindre votre objectif de niveau de service. Amazon ECS garantit que votre application est placée sur un hôte doté d’une capacité adéquate.
# Optimisation de l’autoscaling d’un service Amazon ECS
Un service Amazon ECS est un ensemble géré de tâches. Chaque service est associé à une définition de tâche, à un nombre de tâches souhaité et à une stratégie de placement facultative.
L’autoscaling d’un service Amazon ECS fonctionne via le service Application Auto Scaling. Application Auto Scaling utilise CloudWatch les métriques comme source pour le dimensionnement des métriques. Il utilise également des CloudWatch alarmes pour définir des seuils indiquant quand il faut étendre ou dédimensionner votre service.
Vous indiquez les seuils de mise à l’échelle. Vous pouvez définir une cible métrique, appelée *mise à l’échelle du suivi de cible*. Vous pouvez également spécifier des seuils, appelés *mise à l’échelle par étapes*.
Une fois que vous avez configuré Application Auto Scaling, celui-ci calcule en permanence le nombre de tâches souhaité pour le service. Il indique également à Amazon ECS lorsque le nombre de tâches souhaité doit changer, soit en l’augmentant, soit en le réduisant horizontalement.
Pour utiliser efficacement l’autoscaling du service, vous devez choisir une métrique de mise à l’échelle appropriée. Dans les sections suivantes, nous expliquons comment choisir une métrique.
## Caractérisation de votre application
Pour dimensionner correctement une application, vous devez connaître les conditions dans lesquelles vous devez soit augmenter, soit réduire horizontalement votre application.
En substance, vous devez augmenter horizontalement votre application si la demande prévue dépasse la capacité disponible. À l’inverse, vous pouvez réduire horizontalement votre application pour réduire les coûts lorsque les ressources dépassent la demande.
### Identification d’une métrique d’utilisation
Pour effectuer une mise à l’échelle efficace, vous devez identifier une métrique indiquant l’utilisation ou la saturation. Cette métrique doit présenter les propriétés suivantes pour être utile à la mise à l’échelle.
+ La métrique doit être corrélée à la demande. Lorsque vous maintenez les ressources stables mais que la demande change, la valeur de la métrique doit également changer. La métrique doit augmenter ou diminuer lorsque la demande augmente ou diminue.
+ La valeur de la métrique doit évoluer proportionnellement à la capacité. Lorsque la demande reste constante, l’ajout de ressources supplémentaires doit entraîner une modification proportionnelle de la valeur de la métrique. Ainsi, le doublement du nombre de tâches devrait entraîner une diminution de 50 % de la métrique.
Le meilleur moyen d’identifier une métrique d’utilisation consiste à effectuer des tests de charge dans un environnement de préproduction tel qu’un environnement intermédiaire. Les solutions de test de charge commerciales et open source sont largement disponibles. Ces solutions peuvent généralement générer une charge synthétique ou simuler le trafic utilisateur réel.
Pour démarrer le processus de test de charge, vous devez d’abord créer des tableaux de bord pour les indicateurs d’utilisation de votre application. Ces indicateurs incluent l'utilisation du processeur, l'utilisation de la mémoire, I/O les opérations, la profondeur des I/O files d'attente et le débit du réseau. Vous pouvez collecter ces statistiques avec un service tel que CloudWatch Container Insights. Vous pouvez également les collecter en utilisant Amazon Managed Service for Prometheus avec Amazon Managed Grafana. Au cours de ce processus, veillez à collecter et à représenter graphiquement les métriques relatives aux temps de réponse ou aux taux d’achèvement des tâches de votre application.
Lorsque vous effectuez un test de charge, commencez par un faible taux de requêtes ou d’insertion de tâches. Maintenez ce débit pendant plusieurs minutes afin de permettre à votre application de prendre la température. Ensuite, augmentez lentement le taux et maintenez-le stable pendant quelques minutes. Répétez ce cycle en augmentant le taux à chaque fois jusqu'à ce que les délais de réponse ou de traitement de votre demande soient trop lents pour atteindre vos objectifs de niveau de service ()SLOs.
Pendant le test de charge, examinez chacune des métriques d’utilisation. Les indicateurs qui augmentent en fonction de la charge sont les meilleurs candidats pour vous servir de meilleurs indicateurs d’utilisation.
Identifiez ensuite la ressource qui atteint la saturation. Dans le même temps, examinez également les métriques d’utilisation afin de déterminer laquelle se stabilise en premier à un niveau élevé. Vous pouvez également examiner laquelle atteint le pic, puis bloque votre application en premier. Par exemple, si l’utilisation de l’UC augmente de 0 % à 70-80 % à mesure que vous ajoutez de la charge, puis qu’elle reste à ce niveau une fois que vous ajoutez encore plus de charge, on peut affirmer sans risque de se tromper que l’UC est saturé. Selon l’architecture de l’UC, il se peut qu’il n’atteigne jamais 100 %. Supposons, par exemple, que l’utilisation de la mémoire augmente à mesure que vous ajoutez de la charge, puis que votre application se bloque soudainement lorsqu’elle atteint la limite de mémoire de la tâche ou de l’instance Amazon EC2. Dans ce cas, il est probable que la mémoire ait été entièrement consommée. Plusieurs ressources peuvent être consommées par votre application. Par conséquent, choisissez la métrique qui représente la ressource qui s’épuise en premier.
Enfin, essayez à nouveau le test de charge après avoir doublé le nombre de tâches ou d’instances Amazon EC2. Supposons que l’indicateur clé augmente ou diminue de moitié par rapport au taux précédent. Si tel est le cas, la métrique est proportionnelle à la capacité. Il s’agit d’un bon indicateur d’utilisation pour l’autoscaling.
Examinons maintenant ce scénario hypothétique. Supposons que vous soumettiez une application à un test de charge et que vous constatiez le résultat suivant : l’utilisation de l’UC atteint finalement 80 % à 100 requêtes par seconde. Lorsque vous ajoutez de la charge, l’utilisation de l’UC n’augmente plus. Cependant, cela ralentit la réponse de votre application. Ensuite, vous exécutez à nouveau le test de charge, en doublant le nombre de tâches tout en maintenant le taux à sa valeur maximale précédente. Si vous constatez que l’utilisation moyenne de l’UC tombe à environ 40 %, l’utilisation moyenne de l’UC est un bon candidat pour une métrique de mise à l’échelle. D’un autre côté, si l’utilisation de l’UC reste à 80 % après l’augmentation du nombre de tâches, l’utilisation moyenne de l’UC n’est pas une bonne métrique de mise à l’échelle. Dans ce cas, vous devrez effectuer des recherches supplémentaires afin de trouver une métrique appropriée.
### Modèles d’application et propriétés de mise à l’échelle courants
Vous pouvez exécuter des logiciels de toutes sortes sur AWS. De nombreuses charges de travail sont développées en interne, tandis que d’autres sont basées sur des logiciels open source populaires. Quelle que soit leur origine, nous avons observé certains modèles de conception courants pour les services. La manière dont vous effectuez une mise à l’échelle efficace dépend en grande partie du modèle.
#### Serveur efficace lié à lUC
Le serveur efficace lié à l’UC n’utilise pratiquement aucune ressource autre que l’UC et le débit réseau. Chaque requête peut être traitée par l’application seule. Les requêtes ne dépendent pas d’autres services tels que les bases de données. L'application peut traiter des centaines de milliers de demandes simultanées et peut en utiliser plusieurs efficacement CPUs pour ce faire. Chaque requête est traitée soit par un thread dédié avec une faible surcharge de mémoire, soit par une boucle d’événements asynchrone qui s’exécute sur chaque UC qui traite les requêtes. Chaque réplica de l’application est également capable de traiter une requête. La seule ressource susceptible d’être épuisée avant l’UC est la bande passante du réseau. Dans les services liés à l’UC, l’utilisation de la mémoire, même au débit maximal, ne représente qu’une fraction des ressources disponibles.
Vous pouvez utiliser l’autoscaling basée sur l’UC pour ce type d’application. L’application bénéficie d’une flexibilité maximale en termes de mise à l’échelle. Vous pouvez le redimensionner verticalement en lui fournissant des instances Amazon EC2 ou Fargate v plus grandes. CPUs Et vous pouvez également la mettre à l’échelle horizontalement en ajoutant d’autres réplicas. L’ajout de réplicas supplémentaires, ou le doublement de la taille de l’instance, réduit de moitié l’utilisation moyenne de l’UC par rapport à la capacité.
Si vous utilisez la capacité Amazon EC2 pour cette application, pensez à la placer sur des instances optimisées pour le calcul, telles que la famille d’instances `c5` ou `c6g`
#### Serveur efficace lié à la mémoire
Le serveur efficace lié à la mémoire alloue une quantité importante de mémoire par requête. En cas de simultanéité maximale, mais pas nécessairement de débit, la mémoire est épuisée avant que les ressources d’UC ne soient épuisées. La mémoire associée à une requête est libérée lorsque celle-ci prend fin. Des requêtes supplémentaires peuvent être acceptées dans la limite de la mémoire disponible.
Vous pouvez utiliser l’autoscaling basé sur la mémoire pour ce type d’application. L’application bénéficie d’une flexibilité maximale en termes de mise à l’échelle. Vous pouvez la mettre à l’échelle verticalement en lui fournissant des ressources de mémoire Amazon EC2 ou Fargate plus importantes. Et vous pouvez également la mettre à l’échelle horizontalement en ajoutant d’autres réplicas. L’ajout de réplicas supplémentaires ou le doublement de la taille de l’instance peut réduire de moitié l’utilisation moyenne de la mémoire par rapport à la capacité.
Si vous utilisez la capacité Amazon EC2 pour cette application, pensez à la placer sur des instances optimisées pour la mémoire, telles que la famille d’instances `r5` ou `r6g`.
Certaines applications limitées en mémoire ne libèrent pas la mémoire associée à une requête lorsqu’elle se termine, de sorte qu’une réduction de la simultanéité n’entraîne pas une réduction de la mémoire utilisée. Pour cela, nous vous déconseillons d’utiliser la mise à l’échelle basée sur la mémoire.
#### Le serveur basé sur les travailleurs
Le serveur basé sur les travailleurs traite une requête pour chaque thread de travail individuel l’une après l’autre. Les threads de travail peuvent être des threads légers, tels que des threads POSIX. Il peut également s’agir de threads plus lourds, tels que des processus UNIX. Quel que soit le type de thread, il existe toujours un nombre maximal de connexions simultanées que l’application peut prendre en charge. Généralement, la limite de simultanéité est définie proportionnellement aux ressources de mémoire disponibles. Si la limite de simultanéité est atteinte, l’application place des requêtes supplémentaires dans une file d’attente du backlog. Si la file d’attente du backlog est débordée, l’application rejette immédiatement les requêtes entrantes supplémentaires. Les applications courantes qui correspondent à ce modèle incluent le serveur Web Apache et Gunicorn.
La simultanéité des requêtes est généralement le meilleur indicateur pour dimensionner cette application. Étant donné qu’il existe une limite de simultanéité pour chaque réplica, il est important de procéder à une augmentation horizontale avant que la limite moyenne ne soit atteinte.
Le meilleur moyen d'obtenir des mesures de simultanéité des demandes est de demander à votre application de les communiquer à CloudWatch. Chaque réplica de votre application peut publier le nombre de requêtes simultanées sous forme de métrique personnalisée à une fréquence élevée. Nous recommandons de régler la fréquence au moins une fois par minute. Une fois que plusieurs rapports ont été collectés, vous pouvez utiliser la simultanéité moyenne comme métrique de mise à l’échelle. Vous calculez cette métrique en divisant la simultanéité totale par le nombre de réplicas. Par exemple, si la simultanéité totale est de 1 000 et que le nombre de réplicas est de 10, la simultanéité moyenne est de 100.
Si votre application se trouve derrière un Application Load Balancer, vous pouvez également utiliser la métrique `ActiveConnectionCount` de l’équilibreur de charge comme facteur dans la métrique de mise à l’échelle. Vous devez diviser la métrique `ActiveConnectionCount` par le nombre de réplicas pour obtenir une valeur moyenne. Vous devez utiliser la valeur moyenne pour la mise à l’échelle, par opposition à la valeur de comptage brute.
Pour que cette conception fonctionne de manière optimale, l’écart type de la latence de réponse doit être faible à des taux de requêtes bas. Nous recommandons que, pendant les périodes de faible demande, la plupart des requêtes soient traitées dans un délai court et qu’il n’y ait pas beaucoup de requêtes dont le traitement prend beaucoup plus de temps que la moyenne. Le temps de réponse moyen devrait être proche du 95e centile du temps de réponse. Dans le cas contraire, des dépassements de files d’attente pourraient en résulter. Cela entraîne des erreurs. Nous vous recommandons de fournir des réplicas supplémentaires si nécessaire pour atténuer le risque de débordement.
#### Serveur en attente
Le serveur en attente effectue un certain traitement pour chaque requête, mais son fonctionnement dépend fortement d’un ou de plusieurs services en aval. Les applications de conteneurs font souvent un usage intensif des services en aval tels que les bases de données et autres services d’API. La réponse de ces services peut prendre un certain temps, en particulier dans les scénarios de haute capacité ou de concurrence élevée. En effet, ces applications ont tendance à utiliser peu de ressources d’UC et à utiliser leur simultanéité maximale en termes de mémoire disponible.
Le service en attente convient soit au modèle de serveur limité à la mémoire, soit au modèle de serveur basé sur le travailleur, selon la conception de l’application. Si la simultanéité de l’application n’est limitée que par la mémoire, l’utilisation moyenne de la mémoire doit être utilisée comme métrique de mise à l’échelle. Si la simultanéité de l’application est basée sur une limite de travail, la simultanéité moyenne doit être utilisée comme métrique de mise à l’échelle.
#### Le serveur basé sur Java
Si votre serveur basé sur Java est lié à l’UC et s’adapte proportionnellement aux ressources d’UC, il convient peut-être au modèle de serveur efficace lié à l’UC. Si tel est le cas, l’utilisation moyenne de l’UC peut être appropriée comme métrique de mise à l’échelle. Cependant, de nombreuses applications Java ne sont pas liées à l’UC, ce qui les rend difficiles à mettre à l’échelle.
Pour de meilleures performances, nous vous recommandons d’allouer autant de mémoire que possible au segment de machine virtuelle Java (JVM). Les versions récentes de la JVM, y compris la mise à jour 191 ou ultérieure de Java 8, définissent automatiquement la taille du tas aussi grande que possible pour tenir dans le conteneur. Cela signifie qu’en Java, l’utilisation de la mémoire est rarement proportionnelle à l’utilisation des applications. À mesure que le taux de requêtes et la simultanéité augmentent, l’utilisation de la mémoire reste constante. Pour cette raison, nous ne recommandons pas de dimensionner les serveurs Java en fonction de l’utilisation de la mémoire. Au lieu de cela, nous recommandons généralement une mise à l’échelle en fonction de l’utilisation de l’UC.
Dans certains cas, les serveurs basés sur Java rencontrent un épuisement de la mémoire avant d’épuiser l’UC. Si votre application risque de s’épuiser en cas de forte simultanéité, le nombre moyen de connexions constitue la meilleure métrique de mise à l’échelle. Si votre application est susceptible de s’épuiser en tas à haut débit, le taux de requêtes moyen est la meilleure métrique de mise à l’échelle.
#### Serveurs qui utilisent d’autres environnements d’exécution avec récupérateur de mémoire
De nombreuses applications serveur sont basées sur des environnements d’exécution qui effectuent le récupérateur de mémoire, tels que .NET et Ruby. Ces applications serveur peuvent correspondre à l’un des modèles décrits précédemment. Cependant, comme pour Java, nous ne recommandons pas de dimensionner ces applications en fonction de la mémoire, car l’utilisation moyenne de la mémoire observée n’est souvent pas corrélée au débit ou à la simultanéité.
Pour ces applications, nous vous recommandons une mise à l’échelle en fonction de l’utilisation de l’UC si l’application est liée à l’UC. Dans le cas contraire, nous vous recommandons d’effectuer une mise à l’échelle en fonction du débit moyen ou de la simultanéité moyenne, en fonction des résultats de vos tests de charge.
#### Processeurs de tâches
De nombreuses charges de travail impliquent un traitement de tâches asynchrone. Il s’agit notamment des applications qui ne reçoivent pas de requêtes en temps réel, mais qui s’abonnent à une file d’attente pour recevoir des tâches. Pour ces types d’applications, la métrique de mise à l’échelle appropriée est presque toujours la profondeur de la file d’attente. La croissance des files d’attente indique que le travail en attente dépasse la capacité de traitement, tandis qu’une file d’attente vide indique qu’il y a plus de capacité que de travail à effectuer.
AWS les services de messagerie, tels qu'Amazon SQS et Amazon Kinesis Data Streams, fournissent des CloudWatch métriques qui peuvent être utilisées pour le dimensionnement. Pour Amazon SQS, `ApproximateNumberOfMessagesVisible` c’est la meilleure métrique. Pour Kinesis Data Streams, pensez à utiliser la métrique `MillisBehindLatest` publiée par la bibliothèque client Kinesis (KCL). Cette métrique doit être moyennée pour tous les consommateurs avant d’être utilisée à des fins de mise à l’échelle.
# Capacité et disponibilité d’Amazon ECS
La disponibilité des applications est essentielle pour garantir une expérience sans erreur et minimiser le temps de latence des applications. La disponibilité dépend du fait de disposer de ressources accessibles et d'une capacité suffisante pour répondre à la demande. AWS fournit plusieurs mécanismes pour gérer la disponibilité. Pour les applications que vous hébergez sur Amazon ECS, il s'agit notamment de l'autoscaling et des zones de disponibilité (AZs). L’autoscaling gère le nombre de tâches ou d’instances en fonction des métriques que vous définissez, tandis que les zones de disponibilité vous permettent d’héberger votre application dans des emplacements isolés, mais géographiquement proches.
Comme pour la taille des tâches, la capacité et la disponibilité présentent certains compromis que vous devez prendre en compte. Idéalement, la capacité devrait être parfaitement adaptée à la demande. Il y aurait toujours juste assez de capacité pour traiter les demandes et traiter les tâches afin d'atteindre les objectifs de niveau de service (SLOs), notamment une faible latence et un faible taux d'erreur. La capacité ne devrait jamais être trop élevée, ce qui entraînerait des coûts excessifs, ni trop faible, ce qui entraînerait des temps de latence et des taux d’erreur élevés.
L’autoscaling est un processus latent. Tout d'abord, vous CloudWatch devez recevoir des métriques en temps réel. Ensuite, il CloudWatch faut les agréger pour les analyser, ce qui peut prendre plusieurs minutes en fonction de la granularité de la métrique. CloudWatch compare les indicateurs aux seuils d'alarme pour identifier une pénurie ou un excès de ressources. Pour éviter toute instabilité, vous devez configurer les alarmes de manière à ce que le seuil défini soit dépassé pendant quelques minutes avant que l’alarme ne se déclenche. Il faut également du temps pour configurer de nouvelles tâches et mettre fin à des tâches qui ne sont plus nécessaires.
En raison de ces retards potentiels dans le système, vous devez conserver une certaine marge de manœuvre en allouant des ressources supplémentaires.. La surallocation peut aider à faire face à des pics de demande à court terme. Cela permet également à votre application de répondre à des requêtes supplémentaires sans atteindre la saturation. À titre de pratique exemplaire, vous pouvez définir votre objectif de mise à l’échelle entre 60 et 80 % d’utilisation. Cela permet à votre application de mieux gérer les pics de demande alors que de la capacité supplémentaire est encore en cours d’allocation.
Une autre raison pour laquelle nous vous recommandons de surprovisionner est de pouvoir réagir rapidement aux défaillances de la zone de disponibilité. AWS recommande que les charges de travail de production soient traitées à partir de plusieurs zones de disponibilité. En effet, en cas de défaillance d’une zone de disponibilité, les tâches exécutées dans les zones de disponibilité restantes peuvent toujours répondre à la demande. Si votre application s’exécute dans deux zones de disponibilité, vous devez doubler le nombre normal de tâches. Cela vous permet de fournir une capacité immédiate en cas de panne potentielle. Si votre application s’exécute dans trois zones de disponibilité, nous vous recommandons d’exécuter 1,5 fois le nombre normal de tâches. C’est-à-dire, exécutez trois tâches pour deux qui sont nécessaires au service ordinaire.
## Maximisation de la vitesse de mise à l’échelle
L’autoscaling est un processus réactif dont l’effet prend du temps. Cependant, il existe des moyens de minimiser le temps nécessaire pour augmenter horizontalement.
**Minimisez la taille de l’image.** Le téléchargement et la décompression des images volumineuses à partir d’un référentiel d’images prennent plus de temps. Par conséquent, réduire la taille des images réduit le temps nécessaire au démarrage d’un conteneur. Pour réduire la taille de l’image, vous pouvez suivre ces recommandations spécifiques :
+ Si vous pouvez créer un binaire statique ou utiliser Golang, créez votre image `FROM` scratch et n’incluez que votre application binaire dans l’image résultante.
+ Utilisez des images de base minimisées provenant de fournisseurs de distribution en amont, tels qu’Amazon Linux ou Ubuntu.
+ N’incluez aucun artefact de construction dans votre image finale. L’utilisation de versions en plusieurs étapes peut y contribuer.
+ Dans la mesure du possible, compactez les étapes `RUN`. Chaque étape `RUN` crée une nouvelle couche d’image, ce qui entraîne un aller-retour supplémentaire pour télécharger la couche. Une étape `RUN` comportant plusieurs commandes jointes par `&&` comporte moins de couches qu’une étape comportant plusieurs étapes `RUN`.
+ Si vous souhaitez inclure des données, telles que des données d’inférence ML, dans votre image finale, incluez uniquement les données nécessaires pour démarrer et commencer à desservir le trafic. Si vous récupérez des données à la demande depuis Amazon S3 ou un autre système de stockage sans affecter le service, stockez plutôt vos données dans ces emplacements.
**Gardez vos images au plus proche.** Plus la latence du réseau est élevée, plus le téléchargement de l’image prend du temps. Hébergez vos images dans un référentiel situé dans la même AWS région que celle dans laquelle se trouve votre charge de travail. Amazon ECR est un référentiel d’images hautes performances disponible dans toutes les régions dans lesquelles Amazon ECS est disponible. Évitez d’utiliser Internet ou un lien VPN pour télécharger des images de conteneurs. L’hébergement de vos images dans la même région améliore la fiabilité globale. Il atténue le risque de problèmes de connectivité réseau et de disponibilité dans une autre région. Vous pouvez également implémenter la réplication entre régions Amazon ECR pour y parvenir.
**Réduisez les seuils de surveillance de l’état de l’équilibreur de charge.** Les équilibreurs de charge effectuent une surveillance de l’état avant d’envoyer du trafic à votre application. La configuration de la surveillance de l’état par défaut pour un groupe cible peut prendre 90 secondes ou plus. Pendant ce temps, l’équilibreur de charge vérifie l’état et reçoit les requêtes. La réduction de l’intervalle entre les surveillances de l’état et du nombre de seuils peut permettre à votre application d’accepter le trafic plus rapidement et de réduire la charge sur les autres tâches.
**Tenez compte des performances de démarrage à froid.** Certaines applications utilisent des environnements d'exécution tels que la compilation Java Perform Just-In-Time (JIT). Le processus de compilation, au moins lorsqu’il démarre, peut montrer les performances de l’application. Une solution consiste à réécrire les parties critiques de votre charge de travail en termes de latence dans des langages qui n’affectent pas les performances de démarrage à froid.
**Utilisez la mise à l’échelle par étapes, et non des politiques de mise à l’échelle du suivi de cible.** Vous disposez de plusieurs options d'Application Auto Scaling pour les tâches Amazon ECS. Le suivi des cibles est le mode le plus simple à utiliser. Il vous suffit de définir une valeur cible pour une métrique, telle que l'utilisation moyenne du processeur. Ensuite, l'autoscaler gère automatiquement le nombre de tâches nécessaires pour atteindre cette valeur. Grâce à la mise à l'échelle par étapes, vous pouvez réagir plus rapidement aux variations de la demande, car vous définissez les seuils spécifiques pour vos métriques de mise à l'échelle et le nombre de tâches à ajouter ou à supprimer lorsque les seuils sont dépassés. Et surtout, vous pouvez réagir très rapidement aux variations de la demande en réduisant la durée pendant laquelle une alarme de seuil est franchie. Pour plus d'informations, consultez [Scalabilité automatique de service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) dans le *Guide du développeur Amazon Elastic Container Service*.
Si vous utilisez des instances Amazon EC2 pour fournir de la capacité de cluster, tenez compte des recommandations suivantes :
**Utilisez des instances Amazon EC2 de plus grande taille et des volumes Amazon EBS plus rapides.** Vous pouvez améliorer les vitesses de téléchargement et de préparation des images en utilisant une instance Amazon EC2 plus grande et un volume Amazon EBS plus rapide. Au sein d’une famille d’instances Amazon EC2 donnée, le débit maximal du réseau et d’Amazon EBS augmente à mesure que la taille de l’instance augmente (par exemple, de `m5.xlarge` à `m5.2xlarge`). En outre, vous pouvez également personnaliser les volumes Amazon EBS pour augmenter leur débit et leurs IOPS. Par exemple, si vous utilisez des volumes `gp2`, utilisez des volumes plus importants offrant un débit de base supérieur. Si vous utilisez des volumes `gp3`, spécifiez le débit et les IOPS lorsque vous créez le volume.
**Utilisez le mode réseau en pont pour les tâches exécutées sur les instances Amazon EC2.** Les tâches qui utilisent le mode réseau `bridge` sur Amazon EC2 démarrent plus rapidement que celles qui utilisent le mode réseau `awsvpc`. Lorsque le mode réseau `awsvpc` est utilisé, Amazon ECS attache une interface réseau Elastic (ENI) à l’instance avant de lancer la tâche. Cela introduit une latence supplémentaire. Il existe cependant plusieurs compromis à faire lors de l’utilisation d’un réseau de ponts. Ces tâches ne disposent pas de leur propre groupe de sécurité, ce qui a des répercussions sur l’équilibrage de charge. Pour plus d’informations, consultez la section [Suppression de votre équilibreur de charge](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html) dans le *Guide de l’utilisateur Elastic Load Balancing*.
## Gestion des pics de demande
Certaines applications subissent des pics soudains et importants en termes de demande. Cela se produit pour diverses raisons : un événement d’actualité, une grosse vente, un événement médiatique ou tout autre événement qui devient viral et entraîne une augmentation rapide et significative du trafic en très peu de temps. Si cela n’est pas planifié, la demande peut rapidement dépasser les ressources disponibles.
La meilleure façon de gérer les pics de demande est de les anticiper et de planifier en conséquence. La mise à l’échelle automatique pouvant prendre du temps, nous vous recommandons de faire évoluer votre application avant que le pic de demande ne commence. Pour de meilleurs résultats, nous recommandons d’élaborer un plan d’affaires impliquant une étroite collaboration entre les équipes utilisant un calendrier partagé. L’équipe chargée de planifier l’événement doit travailler en étroite collaboration avec l’équipe chargée de l’application à l’avance. Cela donne à cette équipe suffisamment de temps d’établir une planification claire. Ils peuvent planifier la capacité nécessaire pour augmenter horizontalement avant l’événement et la réduire horizontalement après l’événement. Pour plus d’informations, voir [Mise à l’échelle planifiée](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) dans le *Guide de l’utilisateur Application Auto Scaling.*.
Si vous disposez d’un plan de support Entreprise, veillez également à collaborer avec votre responsable de compte technique (TAM). Votre TAM peut vérifier vos quotas de service et s’assurer que tous les quotas nécessaires sont augmentés avant le début de l’événement. De cette façon, vous n’atteignez aucun quota de service par accident. Ils peuvent également vous aider en préchauffant des services, tels que les équilibreurs de charge, afin de garantir le bon déroulement de votre événement.
Il est plus difficile de gérer les pics de demande imprévus. Les pics imprévus, s’ils sont d’une amplitude suffisante, peuvent rapidement faire en sorte que la demande dépasse la capacité. Cela peut également dépasser la capacité de réaction de l’autoscaling. La meilleure façon de se préparer à des pics imprévus est de surallouer les ressources. Vous devez disposer de suffisamment de ressources pour répondre à la demande maximale de trafic prévue à tout moment.
Le maintien d’une capacité maximale en prévision de pics de demande imprévus peut s’avérer coûteux. Pour atténuer l’impact sur les coûts, trouvez une métrique avancée ou un événement qui permet de prédire qu’un pic de demande important est imminent. Si la métrique ou l’événement fournit un préavis significatif de manière fiable, lancez le processus d’augmentation horizontale immédiatement lorsque l’événement se produit ou lorsque la métrique dépasse le seuil spécifique que vous avez défini.
Si votre application est sujette à des pics de demande soudains et imprévus, envisagez d’ajouter un mode haute performance à votre application qui sacrifie les fonctionnalités non critiques tout en préservant les fonctionnalités cruciales pour le client. Supposons, par exemple, que votre application puisse passer de la génération de réponses personnalisées coûteuses à la diffusion d’une page de réponse statique. Dans ce scénario, vous pouvez augmenter le débit de manière significative sans devoir dimensionner l’application.
Enfin, vous pouvez envisager de dissocier les services monolithiques afin de mieux faire face aux pics de demande. Si votre application est un service monolithique coûteux à exécuter et lent à adapter, vous pourriez être en mesure d’extraire ou de réécrire des éléments critiques en termes de performances et de les exécuter en tant que services distincts. Ces nouveaux services peuvent ensuite être étendus indépendamment des composants moins critiques. Le fait de disposer de la flexibilité nécessaire pour augmenter horizontalement les fonctionnalités critiques en termes de performances séparément des autres parties de votre application peut à la fois réduire le temps nécessaire pour augmenter la capacité et contribuer à réduire les coûts.
# Capacité de cluster Amazon ECS
Vous pouvez fournir de la capacité à un cluster Amazon ECS de plusieurs manières. Par exemple, vous pouvez lancer des instances Amazon EC2 et les enregistrer auprès du cluster au démarrage à l’aide de l’agent de conteneur Amazon ECS. Cependant, cette méthode peut s’avérer difficile, car vous devez gérer vous-même la mise à l’échelle. Par conséquent, nous vous recommandons d’utiliser les fournisseurs de capacité Amazon ECS. Les fournisseurs de capacités gèrent la mise à l’échelle des ressources pour vous. Il existe trois types de fournisseurs de capacité : Amazon EC2, Fargate et Fargate Spot. Pour plus d’informations sur les fournisseurs de capacité Fargate, consultez la section [Clusters Amazon ECS pour les charges de travail Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html) et, pour les charges de travail EC2, consultez la section [Clusters Amazon ECS pour les charges de travail EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html).
Les fournisseurs de capacité Fargate et Fargate Spot prennent en charge le cycle de vie des tâches Fargate pour vous. Fargate fournit une capacité à la demande et Fargate Spot fournit une capacité Spot. Lorsque vous lancez une tâche, Amazon ECS met à votre disposition une ressource Fargate. Cette ressource Fargate est fournie avec les unités de mémoire et d’UC qui correspondent directement aux limites de niveau de tâche que vous avez déclarées dans votre définition de tâche. Chaque tâche reçoit sa propre ressource Fargate, ce qui crée une relation 1:1 entre la tâche et les ressources de calcul.
Les tâches exécutées sur Fargate Spot sont susceptibles d’être interrompues. Les interruptions surviennent après un avertissement de deux minutes. Elles se produisent pendant les périodes de forte demande. Fargate Spot convient parfaitement aux charges de travail tolérantes aux interruptions, telles que les tâches par lots, les environnements de développement ou de préparation. Ils sont également adaptés à tout autre scénario où une haute disponibilité et une faible latence ne sont pas requises.
Vous pouvez exécuter des tâches Fargate Spot parallèlement à des tâches Fargate à la demande. En les utilisant ensemble, vous bénéficiez d’une capacité « de débordement » pour l’allocation à moindre coût.
Amazon ECS peut également gérer la capacité de l’instance Amazon EC2 pour vos tâches. Chaque fournisseur de capacité Amazon EC2 est associé à un groupe Amazon EC2 Auto Scaling que vous spécifiez. Lorsque vous utilisez le fournisseur de capacité Amazon EC2, l’autoscaling de cluster maintient la taille du groupe Amazon EC2 Auto Scaling afin de garantir que toutes les tâches planifiées peuvent être placées.
# Choix de la taille des tâches Fargate pour Amazon ECS
Pour les définitions de AWS Fargate tâches, vous devez spécifier le processeur et la mémoire au niveau de la tâche, et vous n'avez pas besoin de prendre en compte les frais généraux. Vous pouvez également spécifier l'UC et la mémoire au niveau du conteneur pour les tâches Fargate. Toutefois, cette opération n'est pas obligatoire. Les limites de ressources doivent être supérieures ou égales à toutes les réserves que vous avez déclarées. Dans la plupart des cas, vous pouvez les définir en fonction de la somme des réserves de chacun des conteneurs déclarés dans votre définition de tâche. Ensuite, arrondissez le nombre à la taille Fargate la plus proche. Pour plus d’informations sur les tailles disponibles, consultez la section [UC et mémoire de la tâche.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size).
# Accélération de l’allocation des capacités des clusters Amazon ECS avec les fournisseurs de capacité sur Amazon EC2
Les clients qui exécutent Amazon ECS sur Amazon EC2 peuvent tirer parti de l[’autoscaling de cluster (CAS, Cluster Auto Scaling) Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) pour gérer la mise à l’échelle des groupes Amazon EC2 Auto Scaling (ASG, Auto Scaling groups). Avec le CAS, vous pouvez configurer Amazon ECS pour mettre automatiquement votre ASG à l’échelle 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 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 en savoir plus sur le fonctionnement du CAS Amazon ECS, consultez le billet de blog [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/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 au préchauffage d'une instance Amazon EC2 récemment lancée. Vous pouvez prendre les mesures suivantes pour améliorer la réactivité du CAS et accélérer les déploiements :
## Mise à l’échelle 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é à 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 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) en utilisant l’API Amazon ECS pour augmenter le nombre minimum d’instances qu’Amazon ECS fait évoluer ou non à la fois. Une [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) 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 qu'en utilisant le [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs.
## Durée de préinitialisation de l’instance
La période de préchauffage de l'instance est la période après 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échauffage spécifiée expirée, l’instance est prise en compte dans les métriques agrégées de l’ASG, et le CAS procède à sa prochaine itération de calculs pour estimer le nombre d’instances requises.
La valeur par défaut [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)est de 300 secondes, que vous pouvez configurer à une valeur inférieure en utilisant le [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)ou [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) 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 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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) ou [Politiques de mise à l’échelle par étapes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html).