Capacité et disponibilité

La disponibilité des applications est essentielle pour garantir une expérience sans erreur et réduire la latence des applications. La disponibilité dépend de la disponibilité des ressources qui sont accessibles et qui ont une capacité suffisante pour répondre à la demande.AWSfournit plusieurs mécanismes pour gérer la disponibilité. Pour les applications hébergées sur Amazon ECS, il s'agit de la mise à l'échelle automatique et des zones de disponibilité (AZS). La mise à l'échelle automatique gère le nombre de tâches ou d'instances en fonction des mesures 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 considérer. Idéalement, la capacité serait parfaitement alignée sur la demande. Il y aurait toujours assez de capacité pour répondre aux demandes et traiter les tâches afin d'atteindre les objectifs de niveau de service (LOS), y compris un faible taux de latence et de taux d'erreur. La capacité ne serait jamais trop élevée, entraînant des coûts excessifs ; elle ne serait jamais trop faible, entraînant des taux de latence et d'erreur élevés.

La mise à l'échelle automatique est un processus latent. Tout d'abord, les mesures en temps réel doivent être livrées à CloudWatch. Ensuite, ils doivent être agrégés pour l'analyse, ce qui peut prendre jusqu'à plusieurs minutes en fonction de la granularité de la métrique. CloudWatch compare les mesures aux seuils d'alarme pour identifier une pénurie ou un excès de ressources. Pour éviter l'instabilité, configurez les alarmes de manière à ce que le seuil défini soit franchi pendant quelques minutes avant que l'alarme ne s'éteigne. Il faut également du temps pour provisionner de nouvelles tâches et pour 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 rafales de demande à court terme. Cela permet également à votre application de traiter des demandes supplémentaires sans atteindre la saturation. Comme bonne pratique, vous pouvez définir votre cible de mise à l'échelle entre 60 et 80 % de l'utilisation. Cela permet à votre application de mieux gérer les rafales de demande supplémentaire alors que la capacité supplémentaire est encore en cours d'approvisionnement.

Une autre raison pour laquelle nous vous recommandons de surprovisionner est de pouvoir répondre rapidement aux défaillances de la zone de disponibilité.AWSrecommande que les charges de travail de production soient servies à partir de plusieurs zones de disponibilité. En effet, si une défaillance de la zone de disponibilité se produit, vos tâches qui s'exécutent 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 votre nombre de tâches normal. 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 de tâches normal. Autrement dit, exécutez trois tâches pour deux qui sont nécessaires pour servir ordinaire.

Optimisation de la vitesse de dimensionnement

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

Réduire la taille de l'image Les images plus volumineuses prennent plus de temps à télécharger depuis un référentiel d'images et à décompresser Par conséquent, garder des tailles d'image plus petites réduit le temps nécessaire au démarrage d'un conteneur. Pour réduire la taille de l'image, vous pouvez suivre les recommandations suivantes :

• Si vous pouvez construire un binaire statique ou utiliser Golang, construisez votre imageFROMgratter et inclure uniquement 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 builds en plusieurs étapes peut aider avec cela.

• CompactRUNchaque fois que cela est possible. EACHRUNcrée un nouveau calque d'image, ce qui entraîne un aller-retour supplémentaire pour télécharger le calque. Un seulRUNqui a plusieurs commandes jointes par&&a moins de couches qu'une avec plusieursRUNStades.

• Si vous souhaitez inclure des données, telles que des données d'inférence ML, dans votre image finale, n'incluez que les données nécessaires au démarrage et au démarrage du trafic. Si vous récupérez des données à la demande à partir d'Amazon S3 ou d'un autre stockage sans affecter le service, stockez vos données à ces endroits à la place.

Gardez vos images à proximité. Plus la latence du réseau est élevée, plus le téléchargement de l'image prend de temps. Hébergez vos images dans un référentiel dans le mêmeAWSRégion 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 où Amazon ECS est disponible. Évitez de parcourir Internet ou un lien VPN pour télécharger des images de conteneur. 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 vous aider dans ce domaine.

Réduire les seuils de vérification de l'état de l'équilibreur Les équilibreurs de charge effectuent des vérifications de l'état avant d'envoyer du trafic à votre application. La configuration par défaut du contrôle d'intégrité d'un groupe cible peut prendre 90 secondes ou plus. Pendant ce temps, il vérifie l'état de santé et la réception des demandes. L'abaissement de l'intervalle de vérification de l'état et du nombre de seuils permet à votre application d'accepter le trafic plus rapidement et de réduire la charge sur d'autres tâches.

Considérez les performances de démarrage à froid. Certaines applications utilisent des runtimes tels que Java effectuer la compilation JIT (Just-In-Time). Le processus de compilation au moins au démarrage peut montrer les performances de l'application. Une solution consiste à réécrire les parties critiques en matière de latence de votre charge de travail dans des langues qui n'imposent pas de pénalité de performances de démarrage à froid.

Utilisez les stratégies de dimensionnement par étapes et non pas les stratégies de dimensionnement avec suivi de la cible. Vous disposez de plusieurs options Application Auto Scaling pour les tâches Amazon ECS. Le suivi des cibles est le mode le plus simple à utiliser. Avec elle, tout ce que vous devez faire est de définir une valeur cible pour une mesure, telle que l'utilisation moyenne du processeur. Ensuite, le scaler automatique gère automatiquement le nombre de tâches nécessaires pour atteindre cette valeur. Cependant, nous vous recommandons d'utiliser la mise à l'échelle des étapes à la place afin que vous puissiez réagir plus rapidement aux changements de la demande. Avec la mise à l'échelle des étapes, vous définissez les seuils spécifiques pour vos mesures de mise à l'échelle et le nombre de tâches à ajouter ou à supprimer lorsque les seuils sont franchis. Et, plus important encore, vous pouvez réagir très rapidement aux changements de la demande en minimisant le temps qu'une alarme seuil est en violation. Pour de plus amples informations, veuillez consulterAuto Scaling du servicedans leGuide du développeur Amazon Elastic Container Service.

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

Utilisez des instances Amazon EC2 plus volumineuses 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. Dans une famille d'instances Amazon EC2 donnée, le débit maximal du réseau et Amazon EBS augmente à mesure que la taille de l'instance augmente (par exemple, dem5.xlargesurm5.2xlarge). En outre, vous pouvez également personnaliser les volumes Amazon EBS pour augmenter leur débit et leurs E/S par seconde. Par exemple, si vous utilisezgp2, utilisez des volumes plus importants qui offrent un débit de référence plus élevé. Si vous utilisezgp3, spécifiez le débit et les opérations d'E/S par seconde lorsque vous créez le volume.

Utilisez le mode réseau de pont pour les tâches exécutées sur les instances Amazon EC2. Tâches utilisantbridgesur Amazon EC2 démarre plus rapidement que les tâches qui utilisent leawsvpcMode réseau. QuandawsvpcMode réseau est utilisé, Amazon ECS attache une elastic network interface (ENI) à l'instance avant de lancer la tâche. Cela introduit une latence supplémentaire. Il y a cependant plusieurs compromis pour l'utilisation de la mise en réseau de ponts. Ces tâches n'ont pas leur propre groupe de sécurité, et il y a des implications pour l'équilibrage de charge. Pour de plus amples informations, veuillez consulterGroupes cibles de l'équilibreur de chargedans leGuide de l'utilisateur Elastic Load Balancing.

Traitement des chocs de la demande

Certaines applications subissent des chocs importants soudains en demande. Cela se produit pour diverses raisons : un événement d'actualité, une grande vente, un événement médiatique ou tout autre événement qui devient viral et provoque une augmentation rapide et significative du trafic en très peu de temps. Si elle n'est pas planifiée, la demande peut dépasser rapidement les ressources disponibles.

La meilleure façon de gérer les chocs de la demande est de les anticiper et de les planifier en conséquence. Étant donné que la mise à l'échelle automatique peut prendre du temps, nous vous recommandons de mettre à l'échelle votre application avant que le choc de la demande ne commence. Pour obtenir les meilleurs résultats, nous vous recommandons d'avoir un plan d'affaires qui implique une collaboration étroite entre les équipes qui utilisent un calendrier partagé. L'équipe qui planifie l'événement doit travailler en étroite collaboration avec l'équipe responsable de l'application à l'avance. Cela donne à cette équipe assez de temps pour avoir un plan de planification clair. Ils peuvent programmer la capacité afin qu'elle évolue avant l'événement et qu'elle soit mise à l'échelle après l'événement. Pour de plus amples informations, veuillez consulterMise à l'échelle planifiéedans leGuide de l'utilisateur Application Auto Scaling.

Si vous disposez d'un plan d'Support entreprises, veillez également à travailler 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 levés avant le début de l'événement. De cette façon, vous ne touchez pas accidentellement les quotas de service. Ils peuvent également vous aider en préchauffant des services tels que des équilibreurs de charge pour vous assurer que votre événement se déroule sans heurt.

Le traitement des chocs de demande imprévus est un problème plus difficile. Les chocs imprévus, s'ils sont d'une amplitude suffisante, peuvent rapidement faire en sorte que la demande dépasse la capacité. Il peut également dépasser la capacité d'auto-scaling à réagir. La meilleure façon de se préparer aux chocs imprévus est de surapprovisionner les ressources. Vous devez disposer de suffisamment de ressources pour gérer la demande de trafic maximale prévue à tout moment.

Le maintien d'une capacité maximale en prévision des chocs imprévus de la demande peut s'avérer coûteux. Pour atténuer l'impact sur les coûts, trouvez une mesure ou un événement d'indicateur avancé qui prédit un choc important de la demande est imminent. Si la mesure ou l'événement fournit un préavis significatif de manière fiable, commencez le processus de mise à l'échelle immédiatement lorsque l'événement se produit ou lorsque la mesure franchit le seuil spécifique que vous avez défini.

Si votre application est sujette à des chocs soudains imprévus de la demande, envisagez d'ajouter à votre application un mode hautes performances qui sacrifie les fonctionnalités non critiques tout en conservant des fonctionnalités cruciales pour un client. Par exemple, supposons que votre application peut 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 aucune mise à l'échelle de l'application.

Enfin, vous pouvez envisager de briser les services monolithiques pour mieux faire face aux chocs de la demande. Si votre application est un service monolithique coûteux à exécuter et lent à évoluer, vous pourriez être en mesure d'extraire ou de réécrire des éléments critiques pour les performances et de les exécuter en tant que services distincts. Ces nouveaux services peuvent alors être mis à l'échelle indépendamment des composants moins critiques. Le fait de disposer de la flexibilité nécessaire pour mettre à l'échelle les fonctionnalités critiques en matière de performances séparément des autres parties de votre application peut réduire le temps nécessaire à l'ajout de capacité et contribuer à économiser les coûts.