Groupes cibles et vérifications de l’état

Un groupe cible est un ensemble logique de cibles vers lesquelles l’équilibreur de charge route les demandes. Chaque groupe cible possède un type de cible, un protocole/port et une configuration de vérification d’état. L’équilibreur de charge distribue les demandes aux cibles enregistrées du groupe cible qui réussissent les vérifications d’état.

Les groupes cibles sont associés aux écouteurs de l’équilibreur de charge par l’intermédiaire de règles d’écouteur. Un écouteur peut router vers plusieurs groupes cibles selon les attributs de la demande. C’est le mécanisme central du routage fondé sur le chemin et sur l’hôte dans ALB.

Les groupes cibles prennent en charge trois types de cibles :

• instance : route vers des instances EC2 par ID d’instance ; l’équilibreur de charge envoie le trafic vers l’interface réseau principale de l’instance sur le port indiqué
• ip : route vers des adresses IP privées — utile pour les cibles dans des conteneurs (ECS/EKS), les serveurs sur site accessibles via VPN/Direct Connect ou les IP secondaires d’instances EC2
• lambda : route vers une seule fonction Lambda (ALB uniquement) ; ALB convertit la demande HTTP en événement JSON et appelle la fonction de manière synchrone

Le type de cible IP est requis pour les tâches ECS utilisant le mode réseau awsvpc (chaque tâche obtient sa propre IP), pour les pods EKS et pour les architectures hybrides avec des cibles sur site.

Vous enregistrez les cibles dans un groupe cible manuellement (dans la console ou via la CLI) ou automatiquement (en associant un Auto Scaling Group ou en configurant un service ECS). Les cibles enregistrées manuellement restent dans le groupe jusqu'à ce que vous les désenregistriez explicitement.

Pour les ASG, vous associez l'ASG à un groupe cible, puis l'ASG enregistre automatiquement les instances nouvellement lancées et désenregistre celles qui sont arrêtées. Cette intégration étroite avec l'ASG est le modèle standard pour les niveaux de calcul élastiques : les nouvelles instances deviennent disponibles et commencent à recevoir du trafic dès qu'elles réussissent la vérification de l'état.

Chaque groupe cible possède une vérification de l'état associée, que l'équilibreur de charge utilise pour déterminer si une cible est saine et peut recevoir du trafic. La vérification de l'état envoie régulièrement des requêtes à chaque cible et évalue la réponse :

• Protocol : HTTP, HTTPS ou TCP (pour NLB)
• Chemin : chemin URL à demander (par exemple, /health ou /ping)
• Port : port à vérifier (par défaut, le port du groupe cible)
• Seuil de bon état : nombre de réussites consécutives avant de déclarer la cible saine
• Seuil de mauvais état : nombre d'échecs consécutifs avant de déclarer la cible défaillante
• Intervalle : nombre de secondes entre les vérifications de l'état (5–300)
• Délai d'expiration : nombre de secondes à attendre une réponse

Pour les vérifications de l'état HTTP/HTTPS, vous indiquez quels codes de réponse HTTP signalent qu'une cible est saine. La valeur par défaut est 200, mais vous pouvez configurer des plages telles que 200-299 ou des valeurs séparées par des virgules telles que 200,301,302.

Bonne pratique : créez dans votre application un point de terminaison /health dédié qui renvoie 200 uniquement lorsque toutes les dépendances critiques sont disponibles (connectivité à la base de données, cache, service en aval). N'utilisez pas l'URL racine (/) comme chemin de vérification de l'état si elle effectue des opérations coûteuses ou nécessite une authentification.

Après son enregistrement, une cible passe par les états suivants :

• initial : ELB effectue les premières vérifications de l'état
• healthy : la cible a réussi le nombre requis de vérifications consécutives ; elle reçoit du trafic
• unhealthy : la cible a échoué au nombre requis de vérifications consécutives ; elle est retirée de la rotation
• draining : le désenregistrement est en cours ; les connexions existantes peuvent se terminer, mais aucune nouvelle connexion n'est envoyée
• unused : la cible est enregistrée dans le groupe, mais aucune règle d'écoute ne redirige actuellement le trafic vers ce groupe

Surveillez les métriques CloudWatch UnHealthyHostCount et HealthyHostCount pour détecter les problèmes dans votre parc de cibles.

Le délai de désenregistrement (anciennement appelé drainage des connexions) correspond au temps pendant lequel ELB attend la fin des connexions existantes avant de désenregistrer définitivement une cible. La valeur par défaut est de 300 secondes (5 minutes). Pendant cette période, aucune nouvelle requête n'est envoyée à la cible en cours de désenregistrement, mais les requêtes en cours sont autorisées à se terminer.

Pour les déploiements rapides et les arrêts liés à la mise à l'échelle automatique, vous pouvez réduire cette durée à 30–60 secondes si votre application traite rapidement les requêtes. Pour les opérations longues (envoi de fichiers, traitement vidéo), conservez une durée suffisante pour qu'elles puissent se terminer sans interruption.

Les groupes cibles prennent en charge différents algorithmes d'équilibrage de charge :

• Tourniquet (valeur par défaut d'ALB) : les requêtes sont distribuées équitablement à tour de rôle — idéal lorsque toutes les cibles sont équivalentes
• Nombre minimal de requêtes en cours (ALB) : chaque nouvelle requête est envoyée à la cible qui comporte le moins de requêtes en cours — mieux adapté aux charges de travail de durée variable, lorsque certaines requêtes prennent plus de temps que d'autres
• Hachage du flux (NLB) : la distribution repose sur le protocole, les adresses IP source et destination, les ports source et destination et le numéro de séquence TCP — cela garantit que tous les paquets d'un flux TCP/UDP sont envoyés à la même cible

Pour les applications utilisant des sessions, lorsque toutes les requêtes d'un utilisateur doivent atteindre la même cible, activez les sessions persistantes au lieu de compter sur une distribution en tourniquet.

Une seule règle d'écoute ALB peut distribuer le trafic entre plusieurs groupes cibles avec des groupes cibles pondérés. Par exemple, vous pouvez diriger 90 % du trafic vers un groupe cible stable et 10 % vers un groupe cible canari pour des déploiements bleu-vert, sans utiliser le routage pondéré de Route 53.

Les groupes cibles pondérés sont configurés au niveau de la règle d'écoute. Les pondérations sont relatives : une répartition 90/10 envoie 90 % au premier groupe et 10 % au second. Cela diffère du routage pondéré entre plusieurs ALB : ici, la répartition s'effectue au sein d'une seule règle d'écoute ALB.

Lors du déploiement de services ECS derrière un ALB, chaque tâche ECS est enregistrée auprès du groupe cible de l'ALB à l'aide du type de cible IP (pour le mode réseau awsvpc). Le service ECS gère automatiquement l'enregistrement et le désenregistrement : les nouvelles tâches sont enregistrées après avoir réussi les vérifications de l'état, et l'arrêt des tâches déclenche le délai de désenregistrement avant leur terminaison.

Chaque service ECS peut être enregistré avec une surcharge de port spécifique, ce qui permet à plusieurs services ECS de partager un seul ALB via différentes règles d'écoute (basées sur le chemin ou sur l'hôte) avec différents groupes cibles — un modèle courant pour les microservices.

Le comportement des vérifications de l'état diffère entre NLB et ALB :

• NLB prend en charge les protocoles de vérification de l'état TCP, HTTP et HTTPS, quel que soit le protocole d'écoute
• Les vérifications de l'état NLB sont envoyées depuis les adresses IP du NLB dans chaque AZ — assurez-vous que les groupes de sécurité autorisent le trafic provenant des adresses IP de sous-réseau du NLB, ou utilisez le groupe de sécurité du NLB lui-même
• Pour les vérifications de l'état TCP, NLB considère une cible comme saine si elle accepte une connexion TCP sur le port indiqué
• Les cibles NLB qui échouent aux vérifications de l'état sont retirées dans chaque AZ — si toutes les cibles d'une AZ sont défaillantes, NLB peut équilibrer le trafic entre zones vers des cibles saines situées dans d'autres AZ (si l'équilibrage de charge entre zones est activé)

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les groupes cibles contiennent des cibles enregistrées et saines de type instance, IP ou Lambda, que les vérifications de l'état sondent régulièrement les cibles afin de retirer les cibles défaillantes de la rotation, et que le délai de désenregistrement assure un drainage progressif des requêtes en cours avant le retrait d'une cible. Nous allons maintenant étudier les règles d'écoute et le routage basé sur le chemin avec ALB.