Équilibrage de charge et health checks
Choisir le bon load balancer par la décision de routage qu'il peut prendre, diagnostiquer une cible bloquée en unhealthy, et faire correspondre la couche du contrôle de santé à la couche de la panne.
Une instance peut être joignable, répondre sur son port et renvoyer une erreur à chaque appel. Aucune supervision d'infrastructure ne la signalera, parce que rien n'est tombé. Un health check, lui, la sort de la rotation en moins d'une minute. Ce sujet traite de la mécanique qui décide où va chaque requête et comment un système apprend qu'une de ses parties ne mérite plus de trafic.
Ce que couvre ce sujet
- Le modèle en nœuds d'Elastic Load Balancing, la résolution DNS avec son TTL de 60 secondes, et les schémas internal et internet-facing
- Les 3 load balancers de génération actuelle rangés par couche OSI, et la décision de routage que chaque couche rend possible
- Le trajet d'une requête à travers un listener, une règle de listener, un target group et une cible, avec les types de cible instance, ip et lambda
- Le cross-zone load balancing calculé chiffres en main, ses valeurs par défaut par type de load balancer et ses frais de transfert
- Les attributs de target group qui changent le comportement en production : deregistration delay, algorithme de routage, slow start et stickiness
- Les réglages de health check, les états de santé et les reason codes, avec la liste ordonnée des causes derrière une cible unhealthy
- Le comportement fail-open, les seuils de santé de target group, et la séparation entre codes d'erreur ELB et codes d'erreur de la cible
- Les health checks Route 53 d'endpoint, calculés et sur alarme CloudWatch, la règle des 18 %, l'inversion contre la désactivation
- Le failover actif-passif et actif-actif, Evaluate Target Health sur les enregistrements alias, et le zonal shift avec Application Recovery Controller
Pourquoi c'est important
La compétence 2.2.1 du SOA-C03 nomme explicitement la configuration et le diagnostic des health checks ELB et Route 53, donc ce sujet est directement testé. Les questions décrivent rarement une panne franche. Elles décrivent un symptôme ambigu : une charge déséquilibrée entre instances, un endpoint de santé qui répond 200 dans un navigateur mais échoue depuis le load balancer, du trafic qui continue de circuler vers des cibles cassées. Chacun de ces cas a une cause unique et plusieurs explications plausibles.
Le même raisonnement sert en astreinte. Savoir qu'une cible en unused n'échoue à rien, qu'un target group entièrement en échec fait fail-open, et qu'un load balancer mort ne peut pas se signaler lui-même vous évite de chercher une panne à la mauvaise couche pendant que l'incident dure.