Mise à l’échelle automatique du cluster ECS | AU NOUVEAU Blog

Introduction

Amazon ECS (Elastic Container Service) est un service d’orchestration de conteneurs hautement évolutif et entièrement géré qui nous permet d’exécuter, de gérer et de faire évoluer facilement des applications conteneurisées sur AWS.

Avec ECS, il n’est pas nécessaire d’installer ou d’utiliser manuellement un logiciel d’orchestration de conteneurs, ni même de planifier des conteneurs sur un ensemble de machines informatiques.

En outre, il existe un concept de fournisseurs de capacité ECS qui est configuré pour fournir les ressources/l’infrastructure qui seront utilisées par les charges de travail exécutées au sein du cluster. Dans un cluster, il est possible d’avoir plusieurs fournisseurs de capacité et une stratégie facultative de fournisseur de capacité par défaut.

La stratégie de fournisseur de capacité détermine comment les charges de travail sont réparties entre les fournisseurs de capacité du cluster. Nous pouvons opter pour la stratégie en fonction de nos besoins lorsque nous exécutons une tâche. Il existe également différents types de fournisseurs de capacité, selon que nos charges de travail sont hébergées sur EC2 ou Fargate.

Énoncé du problème

Exécuter des conteneurs sans utiliser de service d’orchestration de conteneurs nous amènerait à gérer de nombreuses tâches supplémentaires telles que :

1. La configuration d’Auto Scaling des conteneurs doit être gérée en externe.
2. Il est fort possible que nous soyons privés de certains très bons services fournis par les fournisseurs de cloud gérés, tels que la possibilité d’utiliser des services sans serveur (comme Fargate par AWS ECS).
3. De plus, nous devrons mettre en place des alternatives liées à l’intégration avec les systèmes de configuration des journaux et les systèmes de fichiers tels que NFS/EFS.

Approche de solution

Dans notre cas, étant donné que la plupart de l’infrastructure du client fonctionnait déjà sur AWS, nous avons donc opté pour ECS comme orchestrateur de conteneurs, une technologie propriétaire fournie par AWS.
L’une des principales raisons de choisir ECS est ses intégrations étroites avec une variété d’autres services AWS tels que le mappage dynamique des ports, CloudWatch, EFS, etc.

Dans ECS, nous disposons de 2 options de type de lancement différentes d’AWS, qui se présentent comme suit :

1. Fargate: Un moteur de calcul sans serveur, nous n’avons pas besoin de gérer les serveurs.
2. EC2: Infrastructure autogérée utilisant des instances Amazon EC2.

Avec Auto-Scaling, le principal avantage est qu’il nous évite d’avoir à surveiller et à répondre en permanence aux pics de trafic en temps réel, et plutôt, cette charge de travail est effectuée automatiquement à l’aide du service CloudWatch, ce qui conduit à la création de nouvelles ressources.

Les 3 valeurs dont nous avons besoin pour fournir la valeur dans ASG sont le nombre minimum, souhaité et maximum de tâches, puis il est nécessaire de créer une stratégie de mise à l’échelle. (Il définit l’action à entreprendre lorsque l’alarme CloudWatch associée est à l’état ALARME, ou en référence aux métriques surveillées)

La mise à l’échelle automatique est une fonctionnalité facultative fournie avec le service ECS et peut être activée même lors de la modification du service déjà existant.

Procédure étape par étape :

Sous Politiques de mise à l’échelle automatique des tâches, lorsque nous cliquons sur « Ajouter une politique de mise à l’échelle », nous obtenons 2 types comme mentionné ci-dessous :

1. Suivi de cible
2. Mise à l’échelle des étapes

Suivi de cible :

Avec la mise à l’échelle du suivi de la cible, nous sélectionnons une métrique de mise à l’échelle et définissons une valeur cible. Les alarmes CloudWatch associées aux politiques de mise à l’échelle du suivi de la cible sont gérées par AWS et supprimées automatiquement lorsqu’elles ne sont plus nécessaires. Par conséquent, nous ne gérons pas les alarmes, dans ce cas.

Nous avons la possibilité de surveiller parmi 3 métriques de service lors de sa configuration, qui se déroule comme suit :

1. ECSServiceAverageCPUUtilizationECSServiceAverageCPUUtilization
2. ECSServiceAverageMemoryUtilizationECSServiceAverageMemoryUtilization
3. ALBRequestCountPerTarget

En vertu de cela, nous serions tenus de fournir la valeur cible de la métrique lorsque l’action de mise à l’échelle serait déclenchée.

De plus, nous obtenons 2 types de périodes de recharge à configurer ici :

1. Période de refroidissement de la montée en charge (le nombre de secondes dans les activités de montée en puissance n/b 2)
2. Période de refroidissement de la montée en puissance (le nombre de secondes dans les activités de montée en puissance n/b 2)

Cependant, il est également possible de désactiver l’action « Désactiver la mise à l’échelle », avec laquelle cette politique ne serait jamais utilisée pour la mise à l’échelle au sein de l’ASG.

Mise à l’échelle des étapes :

La mise à l’échelle par étapes est l’une des options de mise à l’échelle dynamique que nous pouvons utiliser et nous oblige à créer des alarmes CloudWatch pour la politique, cependant, nous pouvons également utiliser les alarmes existantes, le cas échéant.

Sur la console ECS, nous pouvons obtenir une nouvelle alarme créée en choisissant l’option de métrique de service ECS sur « CPUUtilization » ou « MemoryUtilization ».

Pour faire évoluer le service ECS avec d’autres métriques, nous pouvons créer nos propres alarmes via la console CloudWatch.

Et enfin, le seuil d’alarme peut être défini, en fonction de la charge de trafic applicatif pouvant être gérée par un seul conteneur/tâche, pour laquelle un test de charge via l’outil Apache Jmeter est recommandé.

Débogage :

Au départ, il y avait quelques cas où les alarmes CloudWatch n’étaient pas configurées correctement en raison de conteneurs qui n’étaient pas mis à l’échelle de la manière souhaitée.

En dehors de cela, selon notre architecture, il était nécessaire de savoir quand le montage du système de fichiers allait réellement avoir lieu dans le conteneur parmi les multiples étapes impliquées, donc c’était sûrement quelque chose que nous devions examiner.

Conclusion:

Par conséquent, la puissante simplicité d’Amazon ECS nous permet de passer d’un conteneur Docker unique à la gestion d’un portefeuille d’applications d’entreprise complet. Il est recommandé de tirer parti de l’option Auto Scaling fournie sous ECS, qui rend l’infrastructure de l’application hautement automatisée.

TROUVÉ CELA UTILE ? PARTAGEZ-LE