Mise à l’échelle automatique et équilibrage de charge des services ECS

Un desired count fixe pour un service ECS ne peut pas s’adapter aux fluctuations du trafic : vous surdimensionnez vos ressources (et gaspillez de l’argent) ou vous les sous-dimensionnez (ce qui dégrade les performances). La ECS Service Auto Scaling ajuste automatiquement le nombre souhaité de tâches en fonction des métriques CloudWatch. Elle utilise en interne le service Application Auto Scaling, le même cadre que celui utilisé par DynamoDB, Aurora et ElastiCache. La mise à l’échelle automatique des services ECS prend en charge les stratégies de suivi de cible, de mise à l’échelle par étapes et de mise à l’échelle planifiée.

Avant d’ajouter des stratégies de mise à l’échelle, enregistrez le service ECS comme cible pouvant être mise à l’échelle dans Application Auto Scaling. Indiquez le nombre minimal et maximal de tâches, le nom du cluster et le nom du service comme identifiant de ressource. Cela définit les limites dans lesquelles la mise à l’échelle automatique fonctionnera. Le nombre minimal garantit toujours une capacité de base ; le nombre maximal évite qu’une mise à l’échelle incontrôlée n’épuise la capacité Fargate ou les instances EC2.

Target Tracking est la stratégie de mise à l’échelle automatique recommandée pour la plupart des services ECS. La métrique cible la plus courante est ECSServiceAverageCPUUtilization : définissez une cible de 50 à 70 %, et ECS ajoute ou supprime des tâches afin de maintenir ce niveau d’utilisation du CPU. Une autre métrique puissante est ALBRequestCountPerTarget : suivez le nombre de requêtes ALB par tâche et effectuez la mise à l’échelle afin de maintenir un débit cible de requêtes par instance. AWS gère automatiquement la mise à l’échelle vers l’extérieur et vers l’intérieur, avec des périodes de temporisation adaptées.

L’association d’un Application Load Balancer (ALB) à un service ECS distribue le trafic HTTP/HTTPS entre toutes les tâches en cours d’exécution. Le groupe cible de l’ALB enregistre l’adresse IP de chaque tâche (pour Fargate/awsvpc) ou le port du conteneur (en mode bridge). ECS enregistre automatiquement les nouvelles tâches dans le groupe cible lorsqu’elles démarrent et les désenregistre lorsqu’elles s’arrêtent. L’ALB effectue des vérifications d’état sur chaque tâche ; les tâches défaillantes sont vidées (les connexions sont fermées correctement) avant que le service ne les arrête.

Un modèle particulièrement puissant consiste à acheminer différents chemins d’URL vers différents services ECS à l’aide du routage ALB basé sur le chemin. Un seul ALB doté d’un écouteur HTTPS peut acheminer : /api/orders/* vers le service ECS Orders, /api/users/* vers le service ECS Users et /api/products/* vers le service ECS Products ; chacun repose sur son propre service ECS avec une mise à l’échelle indépendante. Cela évite d’avoir besoin d’un équilibreur de charge distinct pour chaque microservice, ce qui réduit les coûts et simplifie la gestion du DNS.

Lorsqu’une tâche ECS est sur le point d’être arrêtée (pendant une réduction d’échelle ou un déploiement), l’ALB la marque comme en cours de vidage et cesse de lui acheminer de nouvelles requêtes, tout en laissant les requêtes en cours s’achever. Le délai de désenregistrement (300 secondes par défaut, configurable de 0 à 3 600 secondes) correspond à la durée pendant laquelle l’ALB attend avant de fermer les connexions de force. Pour ECS, lorsque les requêtes sont courtes, définissez un délai de désenregistrement plus faible (30 à 60 secondes) afin d’accélérer les déploiements et les réductions d’échelle. Pour les connexions longues (WebSocket, téléversements de fichiers), conservez un délai plus élevé.

Au-delà du CPU et de la mémoire, publiez des métriques CloudWatch personnalisées depuis votre application (profondeur de file d’attente, sessions actives, indicateurs clés de performance métier) et utilisez-les pour piloter la mise à l’échelle. Par exemple, si chaque tâche ECS peut traiter simultanément 50 messages d’une file d’attente, publiez la profondeur de la file SQS comme métrique personnalisée et créez une stratégie de suivi de cible visant 50 messages par tâche. Vous obtenez ainsi une mise à l’échelle directement pilotée par la logique métier, plutôt que fondée sur des métriques d’infrastructure qui peuvent ne pas être corrélées à la charge de l’application.

Comme pour la mise à l’échelle automatique d’EC2, ECS prend en charge la protection des tâches contre la réduction d’échelle. Une tâche en cours d’exécution peut définir elle-même son indicateur de protection contre la réduction d’échelle via l’API ECS, afin d’éviter son arrêt pendant une réduction d’échelle alors qu’elle traite un travail critique. Cette fonctionnalité est utile pour les tâches ECS qui jouent le rôle de travailleurs SQS : un travailleur qui vient de retirer un long travail de la file peut se protéger, terminer le travail, puis désactiver la protection. Sans cette protection, une réduction d’échelle pourrait arrêter une tâche en plein traitement et provoquer la duplication du travail ou une perte de données.

Choisissez soigneusement votre métrique de mise à l’échelle. Utilisation du CPU est la valeur par défaut et convient aux charges de travail limitées par le calcul. Utilisation de la mémoire (ECSServiceAverageMemoryUtilization) est utile pour les applications limitées par la mémoire, mais augmenter la mémoire nécessite d’ajouter des tâches ; si votre tâche est limitée par la mémoire disponible par tâche plutôt que par le traitement simultané, il peut être préférable de corriger l’allocation de mémoire dans la définition de tâche. ALBRequestCountPerTarget est directement corrélée à l’expérience utilisateur et constitue la métrique la plus exploitable pour les API web : effectuez la mise à l’échelle en fonction du débit réel de requêtes par tâche.

Le ECS Deployment Circuit Breaker détecte automatiquement les déploiements défaillants et revient à la dernière version stable. Sans lui, un mauvais déploiement (un conteneur qui échoue aux vérifications d’état) obligerait ECS à tenter indéfiniment de lancer de nouvelles tâches. Lorsque le disjoncteur est activé, si un certain pourcentage des tâches nouvellement lancées échoue aux vérifications d’état pendant une fenêtre de détection, ECS marque le déploiement comme FAILED et revient automatiquement à la révision précédente de la définition de tâche. Cela évite qu’un mauvais déploiement ne provoque une dégradation prolongée du service.

Voici une architecture d’API web conteneurisée prête pour la production : Route 53 résout le domaine vers un nom DNS ALB ; l’ALB termine les connexions HTTPS (certificat ACM), applique les règles WAF et achemine les requêtes vers un groupe cible de service ECS ; des tâches Fargate réparties dans des sous-réseaux privés sur 3 AZ traitent les requêtes ; la ECS Service Auto Scaling, avec un suivi de cible sur ALBRequestCountPerTarget, ajuste le nombre de tâches de 2 à 50 ; les tâches se connectent à RDS Aurora et ElastiCache dans des sous-réseaux privés. Tous les journaux sont envoyés vers CloudWatch Logs ; les métriques alimentent les tableaux de bord et les alarmes CloudWatch.

Dans cette leçon, vous avez appris que : ECS Service Auto Scaling utilise Application Auto Scaling avec le suivi de cible (CPU, requêtes ALB ou métriques personnalisées) pour ajuster le nombre de tâches entre les limites minimale et maximale configurées ; le routage ALB basé sur le chemin permet à un seul équilibreur de charge de servir plusieurs microservices ECS en acheminant les chemins d’URL vers différents groupes cibles ; et le Deployment Circuit Breaker revient automatiquement sur les déploiements défaillants avant qu’ils n’entraînent une dégradation prolongée du service. Ce module consacré à ECS et aux conteneurs est terminé ; nous allons maintenant découvrir Amazon EKS pour Kubernetes sur AWS.