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.

Optimisez la ECS capacité et la disponibilité d'Amazon

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 de la disponibilité de ressources ayant une capacité suffisante pour répondre à la demande. AWS fournit plusieurs mécanismes pour gérer la disponibilité. Pour les applications hébergées sur AmazonECS, 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 serait jamais trop élevée, ce qui entraînerait des coûts excessifs ; elle ne serait pas non plus trop faible, ce qui entraînerait une latence et des taux d'erreur élevés.

La mise à l'échelle automatique est un processus latent. Tout d'abord, les métriques en temps réel doivent être transmises à CloudWatch. Ils doivent ensuite être agrégés pour être analysés, 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é, configurez 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 décrit, il est important de conserver une certaine marge de manœuvre en surprovisionnant. Cela peut aider à faire face à des pics de demande à court terme. Cela permet également à votre application de répondre à des demandes supplémentaires sans atteindre la saturation. Comme bonne pratique, 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 de provisionnement.

Une autre raison pour laquelle nous vous recommandons de surprovisionner est de pouvoir réagir rapidement aux défaillances de la zone de disponibilité. Nous recommandons de traiter les charges de travail de production à 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.

Maximiser la vitesse de mise à l'échelle

La mise à l'échelle automatique est un processus réactif dont l'effet prend du temps. Cependant, il existe des moyens de minimiser le temps nécessaire à la mise à l'échelle.

Minimisez la taille de l'image. Les images plus grandes sont plus longues à télécharger à partir d'un référentiel d'images et à les décompresser. 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 :

Gardez vos images à portée de main. Plus la latence du réseau est élevée, plus le téléchargement de l'image est long. Hébergez vos images dans un référentiel situé dans la même région que celle dans laquelle se trouve votre charge de travail. Amazon ECR est un référentiel d'images performant disponible dans toutes les régions où Amazon ECS est disponible. Évitez de parcourir Internet ou d'utiliser un VPN lien 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 ECR la réplication entre régions Amazon pour y parvenir.

Réduisez les seuils de vérification de l'état de l'équilibreur de charge. Les équilibreurs de charge vérifient l'état de santé avant d'envoyer du trafic à votre application. La configuration du contrôle de santé par défaut pour un groupe cible peut prendre 90 secondes ou plus. Pendant ce temps, l'équilibreur de charge vérifie l'état de santé et reçoit les demandes. La réduction de l'intervalle entre les vérifications de santé 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 Java pour effectuer la compilation 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 le dimensionnement par étapes, et non des politiques de dimensionnement pour le suivi des cibles. Il existe plusieurs options d'Application Auto Scaling pour les tâches. 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 CPU moyenne. 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 Service Auto Scaling.

Si vous utilisez des EC2 instances Amazon pour fournir de la capacité de cluster, tenez compte des recommandations suivantes :

Utilisez des EC2 instances Amazon plus grandes et des EBS volumes Amazon plus rapides. Vous pouvez améliorer les vitesses de téléchargement et de préparation des images en utilisant une EC2 instance Amazon plus grande et un EBS volume Amazon plus rapide. Au sein d'une famille d'instances donnée, le débit EBS maximal du réseau et d'Amazon augmente à mesure que la taille de l'instance augmente (par exemple, de m5.xlarge àm5.2xlarge). En outre, vous pouvez également personnaliser les EBS volumes Amazon pour augmenter leur débit etIOPS. Par exemple, si vous utilisez des gp2 volumes, utilisez des volumes plus importants qui offrent un débit de base supérieur. Si vous utilisez gp3 des volumes, spécifiez le débit et la IOPS date de création du volume.

Utilisez le mode réseau en pont pour les tâches exécutées sur les EC2 instances Amazon. Les tâches qui utilisent le mode bridge réseau sur Amazon EC2 démarrent plus rapidement que celles qui utilisent le mode awsvpc réseau. Lorsque le mode awsvpc réseau est utilisé, Amazon ECS attache une interface réseau élastique (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 Groupes cibles des équilibreurs de charge dans le guide de l'utilisateur d'Elastic Load Balancing.

Gérer les chocs liés à la demande

Certaines applications subissent des chocs 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 chocs 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 choc de la demande ne commence. Pour de meilleurs résultats, nous recommandons d'élaborer un plan d'affaires qui implique 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 pour établir un plan de planification clair. Ils peuvent planifier la capacité pour augmenter la capacité avant l'événement et pour l'augmenter après l'événement. Pour plus d'informations, voir Mise à l'échelle planifiée dans le Guide de l'utilisateur Application Auto Scaling..

Si vous avez un plan de Support aux entreprises, assurez-vous également de travailler avec votre responsable de compte technique (TAM). TAMVous pouvez vérifier vos quotas de service et vous assurer que 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 proposant des services de préchauffage tels que des équilibreurs de charge pour garantir le bon déroulement de votre événement.

Il est plus difficile de gérer les chocs imprévus liés à la demande. Les chocs 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 chocs imprévus est de surapprovisionner 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 chocs imprévus liés à la demande peut s'avérer coûteux. Pour atténuer l'impact sur les coûts, trouvez un indicateur avancé, un indicateur ou un événement qui prédit l'imminence d'un choc de demande important. Si la métrique ou l'événement fournit un préavis significatif de manière fiable, lancez le processus de scale-out 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 chocs 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 avoir à redimensionner l'application.

Vous pouvez envisager de dissocier les services monolithiques afin de mieux faire face aux chocs liés à la 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 étendre 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.