Optimisation de la mise à l'échelle automatique du 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.

Le dimensionnement automatique du 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 échelle de suivi des cibles. Vous pouvez également spécifier des seuils, appelés échelonnement 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 le redimensionnant, soit en le redimensionnant.

Pour utiliser efficacement le dimensionnement automatique des services, vous devez choisir une métrique de mise à l'échelle appropriée. Nous expliquons comment choisir une métrique dans les sections suivantes.

Caractérisation de votre application

Pour dimensionner correctement une application, vous devez connaître les conditions dans lesquelles vous devez effectuer une mise à l'échelle de votre application et à quel moment vous devez la redimensionner.

Essentiellement, vous devez étendre votre application si l'on prévoit que la demande sera supérieure à la capacité. À l'inverse, vous pouvez adapter 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 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 à l'aide d'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, assurez-vous de collecter et de tracer des mesures relatives aux temps de réponse ou aux taux d'achèvement des travaux de votre application.

Lorsque vous chargez un test, commencez par un faible taux de demande ou d'insertion d'emplois. Maintenez ce taux constant pendant plusieurs minutes pour permettre à votre application de s'échauffer. 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 chargement, examinez chacune des mesures 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 indicateurs d'utilisation pour voir lequel s'aplatit en premier à un niveau élevé. Vous pouvez également examiner lequel atteint le pic, puis bloque votre application en premier. Par exemple, si l'utilisation du processeur passe 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 le processeur est saturé. Selon l'architecture du processeur, 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' EC2 instance Amazon. 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, réessayez de tester la charge après avoir doublé le nombre de tâches ou d' EC2instances Amazon. 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 le dimensionnement automatique.

Examinons maintenant ce scénario hypothétique. Supposons que vous testiez le chargement d'une application et que vous constatiez que l'utilisation du processeur atteint finalement 80 % à 100 demandes par seconde. Lorsque vous ajoutez de la charge, l'utilisation du processeur 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 du processeur tombe à environ 40 %, l'utilisation moyenne du processeur est un bon candidat pour une métrique de mise à l'échelle. En revanche, si l'utilisation du processeur reste à 80 % après l'augmentation du nombre de tâches, l'utilisation moyenne du processeur n'est pas un bon indicateur de mise à l'échelle. Dans ce cas, vous devez effectuer des recherches supplémentaires pour 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.

Le serveur efficace lié au processeur

Le serveur efficace lié au processeur n'utilise pratiquement aucune ressource autre que le processeur et le débit du réseau. Chaque demande peut être traitée par l'application seule. Les demandes 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 demande est traitée par un thread dédié avec une faible charge de mémoire ou une boucle d'événements asynchrone s'exécute sur chaque processeur qui traite les demandes. Chaque réplique de l'application est également capable de traiter une demande. La seule ressource susceptible d'être épuisée avant le processeur est la bande passante réseau. Dans les services liés au processeur, l'utilisation de la mémoire, même au débit maximal, ne représente qu'une fraction des ressources disponibles.

Vous pouvez utiliser la mise à l'échelle automatique basée sur le processeur 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 EC2 instances Amazon ou Fargate v CPUs plus grandes. Vous pouvez également le redimensionner horizontalement en ajoutant d'autres répliques. L'ajout de répliques supplémentaires, ou le doublement de la taille de l'instance, réduit de moitié l'utilisation moyenne du processeur par rapport à la capacité.

Si vous utilisez les EC2 capacités d'Amazon pour cette application, pensez à la placer sur des instances optimisées pour le calcul, telles que la famille c5 orc6g.

Le serveur économe en mémoire

Le serveur limité à la mémoire efficace alloue une quantité importante de mémoire par demande. En cas de simultanéité maximale, mais pas nécessairement de débit, la mémoire est épuisée avant que les ressources du processeur ne soient épuisées. La mémoire associée à une demande est libérée lorsque celle-ci prend fin. Des demandes supplémentaires peuvent être acceptées dans la limite de la mémoire disponible.

Vous pouvez utiliser le dimensionnement automatique 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 le dimensionner à la fois verticalement en lui fournissant des ressources de mémoire Amazon EC2 ou Fargate plus importantes. Vous pouvez également le redimensionner horizontalement en ajoutant d'autres répliques. L'ajout de répliques 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 EC2 capacité d'Amazon pour cette application, pensez à la placer sur des instances optimisées pour la mémoire, telles que la famille r5 orr6g.

Certaines applications limitées en mémoire ne libèrent pas la mémoire associée à une demande 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 le dimensionnement basé sur la mémoire.

Le serveur basé sur les travailleurs

Le serveur basé sur les travailleurs traite une demande 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 thread, l'application peut toujours prendre en charge une simultanéité maximale. 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 demandes supplémentaires dans une file d'attente. Si la file d'attente du backlog est débordée, l'application rejette immédiatement les demandes entrantes supplémentaires. Les applications courantes qui correspondent à ce modèle incluent le serveur Web Apache et Gunicorn.

La simultanéité des demandes est généralement le meilleur indicateur pour dimensionner cette application. Comme il existe une limite de simultanéité pour chaque réplique, il est important de procéder à une mise à l'échelle 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éplique de votre application peut publier le nombre de demandes 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 mesure de mise à l'échelle. Vous calculez cette métrique en divisant la simultanéité totale par le nombre de répliques. Par exemple, si la simultanéité totale est de 1 000 et que le nombre de répliques 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 ActiveConnectionCount métrique de l'équilibreur de charge comme facteur dans la métrique de dimensionnement. Vous devez diviser la ActiveConnectionCount métrique par le nombre de répliques 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 au mieux, l'écart type de latence de réponse doit être faible à de faibles taux de requêtes. Nous recommandons que, pendant les périodes de faible demande, la plupart des demandes reçoivent une réponse dans un court laps de temps, et il n'y a pas beaucoup de demandes dont le délai de réponse est nettement supérieur à la moyenne. Le temps de réponse moyen doit être proche du 95e percentile. 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épliques supplémentaires si nécessaire pour atténuer le risque de débordement.

Le serveur d'attente

Le serveur en attente effectue un certain traitement pour chaque demande, 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 du processeur et à utiliser leur simultanéité maximale en termes de mémoire disponible.

Le service d'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 est limitée uniquement par la mémoire, l'utilisation moyenne de la mémoire doit être utilisée comme mesure 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 mesure de mise à l'échelle.

Le serveur basé sur Java

Si votre serveur basé sur Java dépend du processeur et s'adapte proportionnellement aux ressources du processeur, il convient peut-être au modèle de serveur efficace lié au processeur. Si tel est le cas, l'utilisation moyenne du processeur peut être appropriée comme mesure de mise à l'échelle. Cependant, de nombreuses applications Java ne sont pas liées au processeur, ce qui les rend difficiles à adapter.

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 demandes 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. Nous recommandons plutôt une mise à l'échelle en fonction de l'utilisation du processeur.

Dans certains cas, les serveurs basés sur Java sont épuisés avant d'épuiser le processeur. Si votre application risque de s'épuiser en cas de forte simultanéité, le nombre moyen de connexions constitue le meilleur indicateur de mise à l'échelle. Si votre application est susceptible de s'épuiser en tas à haut débit, le taux de requêtes moyen est le meilleur indicateur de mise à l'échelle.

Serveurs utilisant d'autres environnements d'exécution collectés avec des déchets

De nombreuses applications serveur sont basées sur des environnements d'exécution qui collectent les déchets, 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 de dimensionner l'utilisation du processeur si l'application est liée au processeur. 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 demandes en temps réel, mais qui s'abonnent à une file d'attente pour recevoir des offres d'emploi. Pour ces types d'applications, la mesure de dimensionnement 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 le meilleur indicateur. Pour Kinesis Data Streams, pensez à utiliser MillisBehindLatest la métrique publiée par la Kinesis Client Library (KCL). Cette métrique doit être moyennée pour tous les consommateurs avant de l'utiliser à des fins de mise à l'échelle.