Fondamentaux d'Elastic Load Balancing

Une API de paiement tourne sur 6 instances EC2 réparties sur 2 zones de disponibilité. Un déploiement sort, une instance démarre avec une configuration cassée, et pendant les 40 minutes qui suivent environ un sixième des requêtes renvoie une erreur. Personne n'a été alerté, parce que rien n'était tombé. L'instance était joignable, elle répondait sur le port 8080, et elle renvoyait un HTTP 500 à chaque appel.

Un load balancer aurait sorti cette instance de la rotation en moins d'une minute. C'est le vrai travail d'Elastic Load Balancing : non seulement répartir les requêtes, mais demander en continu à chaque cible si elle est en état de les recevoir, et contourner celles qui ne le sont pas. Cette leçon construit le modèle de cette répartition. La suivante traite du cas où c'est le health check lui-même qui est cassé.

Un load balancer est un ensemble de nœuds, pas un boîtier

La première image à désapprendre est celle d'un appareil unique posé devant votre flotte. Quand vous activez une zone de disponibilité pour un load balancer, Elastic Load Balancing crée un nœud de load balancer dans cette zone. Activez 3 zones et vous obtenez 3 nœuds, chacun avec sa propre adresse IP, chacun capable de recevoir du trafic client.

Les clients trouvent ces nœuds par le DNS. Votre load balancer reçoit un nom comme my-lb-1234567890abcdef.elb.us-east-2.amazonaws.com, et le DNS d'Amazon répond à une requête sur ce nom avec les adresses IP des nœuds. L'enregistrement porte un TTL de 60 secondes, court volontairement : AWS peut ajouter des nœuds quand le trafic monte, et retirer le nœud d'une zone en difficulté, sans attendre les caches clients.

dig +short my-lb-1234567890abcdef.elb.us-east-2.amazonaws.com
3.13.20.147
18.222.9.88

Deux conséquences suivent immédiatement, et les 2 reviennent à l'examen.

D'abord, un load balancer a besoin de sous-réseaux dans les zones qu'il doit servir. Un Application Load Balancer exige au moins 2 zones de disponibilité ; un Network Load Balancer fonctionne avec une seule, même si une zone unique vous prive de redondance zonale. Si vous enregistrez des cibles dans une zone que vous n'avez jamais activée, ces cibles ne reçoivent aucun trafic.

Ensuite, c'est le client qui choisit l'adresse de nœud qu'il utilise. AWS n'oriente pas ce choix. La forme de votre trafic dépend donc du nombre de nœuds existants et des cibles que chaque nœud a le droit d'atteindre, ce qui est exactement la question du cross-zone plus loin dans cette leçon.

Une dernière distinction avant les types. Un load balancer internet-facing a des nœuds avec des adresses IP publiques et exige des sous-réseaux publics routés vers une internet gateway. Un load balancer internal n'a que des adresses privées. Les 2 joignent leurs cibles par adresse IP privée, donc vos instances n'ont jamais besoin d'IP publique pour se placer derrière l'un ou l'autre.

Trois load balancers, trois profondeurs d'inspection

AWS propose 3 load balancers de génération actuelle. La tentation est d'apprendre par cœur un tableau de fonctionnalités. Le modèle qui va plus vite consiste à demander jusqu'à quelle profondeur chacun a le droit de regarder dans le paquet, parce que ce seul fait détermine tout ce qu'il peut décider.

Un Application Load Balancer travaille au niveau 7. Il analyse la requête HTTP, donc il peut router sur le nom d'hôte, le chemin, un en-tête, la méthode, un paramètre de la query string ou l'adresse IP source. Il sait aussi terminer TLS, authentifier des utilisateurs auprès d'un fournisseur d'identité, renvoyer une réponse fixe et émettre une redirection sans jamais toucher une cible.

Un Network Load Balancer travaille au niveau 4. Il n'analyse jamais le HTTP. Il choisit une cible avec un hachage de flux portant sur le protocole, l'IP et le port source, l'IP et le port de destination, et le numéro de séquence TCP, puis il épingle toute cette connexion TCP sur la cible choisie pour sa durée de vie. Comme il fait moins de travail par paquet, il encaisse des taux de connexion très élevés avec une latence ajoutée faible, et comme il n'a rien à réécrire, il peut livrer à votre cible la vraie IP source du client.

Un Gateway Load Balancer travaille au niveau 3. Il écoute tous les paquets IP sur tous les ports et les transmet à des appliances virtuelles, pare-feu, systèmes de détection d'intrusion, outils d'inspection profonde de paquets, avec le protocole GENEVE sur le port 6081. Le trafic l'atteint par un Gateway Load Balancer endpoint que vous placez comme prochain saut dans une table de routage, donc la flotte d'appliances devient un point de passage invisible sur le trajet.

Le Classic Load Balancer existe toujours et apparaît encore dans d'anciens supports, mais AWS recommande de le quitter, et les scénarios du SOA-C03 sont construits autour de la génération actuelle.

Comment un Application Load Balancer choisit la destination d'une requête

Quatre objets se placent entre un client et une instance, et chaque question de diagnostic sur un ALB dépend de savoir lequel détient quelle décision.

Un listener surveille les connexions sur un protocole et un port, HTTP ou HTTPS, port 1 à 65535. Une règle de listener a une priorité, une ou plusieurs conditions, et une ou plusieurs actions. Un target group rassemble des cibles qui partagent un protocole, un port et un seul jeu de réglages de health check. Une cible est l'instance, l'adresse IP ou la fonction Lambda qui répond finalement.

Suivez une requête à travers tout ça. Un client envoie GET https://shop.example.com/api/orders/1042. Le listener HTTPS sur le port 443 termine TLS avec le certificat ACM qui lui est attaché. Il évalue ensuite ses règles par ordre de priorité, du plus petit numéro au plus grand :

priorité 10   SI path-pattern = /api/*          ALORS forward vers tg-api
priorité 20   SI host-header  = img.example.com ALORS forward vers tg-images
défaut        (non supprimable)                 forward vers tg-web

La règle 10 correspond, donc la requête part vers tg-api. Les règles fonctionnent en première correspondance gagnante, et la règle par défaut est toujours évaluée en dernier et ne peut pas être supprimée, donc elle sert d'attrape-tout. Si votre nouvelle règle de chemin siège en priorité 60000 derrière une règle large /* en priorité 5, elle ne se déclenchera jamais, et cette erreur d'ordonnancement est un énoncé d'examen fréquent.

tg-api choisit alors une cible avec son algorithme de routage et transmet la requête sur une connexion backend, en HTTP/1.1 par défaut. Le load balancer ajoute X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Port pour que l'application voie encore qui était le client, puisqu'au niveau 7 le paquet reçu par la cible vient du load balancer et non du client.

Deux réglages de ce trajet méritent d'être mémorisés. Le connection idle timeout vaut 60 secondes par défaut et se règle de 1 à 4 000. Et le load balancer s'accorde 10 secondes pour établir une connexion TCP vers une cible avant d'abandonner. Ces 2 nombres deviennent des codes d'erreur dans la leçon suivante.

Les types de cible : ce que vous enregistrez décide de ce que vous pouvez atteindre

Un target group a un seul type de cible, choisi à la création et jamais modifiable ensuite.

• instance enregistre par ID d'instance. Le trafic part vers l'IP privée principale de l'interface réseau principale. Simple, et c'est ce à quoi un Auto Scaling group s'attache automatiquement. Ce type ne peut pas atteindre des instances dans un VPC appairé.
• ip enregistre par adresse IP. Les plages autorisées sont les sous-réseaux du VPC du target group plus 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12 et 192.168.0.0/16. Les adresses routables publiquement sont refusées. C'est ainsi que vous atteignez un VPC appairé, une base de données ou un serveur on-premises via Direct Connect ou Site-to-Site VPN, et cela laisse aussi plusieurs conteneurs d'une même instance utiliser le même port.
• lambda enregistre une seule fonction, que le load balancer invoque au lieu de s'y connecter. Les corps de requête et de réponse sont plafonnés à 1 Mo.

L'erreur tentante consiste à supposer qu'instance est toujours le choix sûr. C'est le seul type de cible qui ne franchit pas une frontière de peering VPC, donc tout scénario hybride ou multi-VPC désigne ip.

Comment décide un Network Load Balancer, et pourquoi l'IP client compte

Il n'y a pas de règles à évaluer au niveau 4. Le nœud hache le flux, choisit une cible, et y maintient la connexion. Tout ce qui est intéressant tient dans la gestion des connexions.

La préservation de l'IP client est le réglage qui surprend. Quand elle est active, votre cible voit la vraie adresse source du client, ce qui veut dire que vos security groups doivent autoriser la plage cliente, pas le load balancer. Quand elle est inactive, la cible voit l'IP privée du nœud de load balancer. Les valeurs par défaut ne sont pas uniformes :

Si la préservation est inactive et que vous avez quand même besoin de l'adresse de l'appelant, activez proxy protocol v2, qui préfixe un en-tête binaire portant les détails de la connexion. Vérifiez d'abord que l'application sait l'analyser : une cible qui s'étrangle sur cet en-tête se met à échouer ses health checks, parce que l'en-tête est aussi ajouté aux connexions de health check.

Les idle timeouts sont des repères fixes à connaître. Les flux TCP sont par défaut à 350 secondes et se règlent de 60 à 6 000. Les listeners TLS sont fixés à 350 secondes. Les flux UDP sont fixés à 120 secondes, après quoi le paquet suivant est traité comme un nouveau flux et peut atterrir sur une autre cible.

Le cross-zone load balancing, avec le calcul

C'est le comportement le plus testable du sujet, et les nombres le fixent mieux que la définition.

Prenez un load balancer avec 2 zones activées. La zone de disponibilité A contient 2 cibles, la zone B en contient 8. Le DNS distribue les 2 adresses de nœud à peu près également, donc chaque nœud reçoit 50 % du trafic client.

Cross-zone désactivé. Chaque nœud ne peut atteindre que les cibles de sa propre zone. Le nœud de la zone A partage ses 50 % entre 2 cibles, donc chacune reçoit 25 %. Le nœud de la zone B répartit ses 50 % sur 8 cibles, donc chacune reçoit 6,25 %. Deux cibles font 4 fois le travail des 8 autres.

Cross-zone activé. Chaque nœud atteint les 10 cibles, donc chaque cible reçoit 10 %.

Les valeurs par défaut diffèrent selon le type, et la raison est architecturale plutôt qu'arbitraire. Un Application Load Balancer est toujours cross-zone au niveau du load balancer et ne peut pas y être désactivé, même si un target group individuel peut fixer load_balancing.cross_zone.enabled à false et redevenir zonal. Les Network Load Balancers et les Gateway Load Balancers sont par défaut à off, ce qui garde chaque zone comme domaine de panne autonome et évite les frais de transfert inter-zones.

Ces frais sont le piège pratique. Activer le cross-zone sur un Network Load Balancer fait franchir au trafic les frontières de zone de disponibilité, et les frais de transfert de données EC2 s'appliquent. Le laisser désactivé vous oblige à prévoir assez de capacité dans chaque zone, parce qu'une zone avec trop peu de cibles les saturera pendant qu'une autre reste au repos.

La configuration désactivée cache un piège. Quand le cross-zone est off, une zone vide ou entièrement en échec est une vraie panne pour les clients qui y ont résolu. Sur un Application Load Balancer, cela produit un HTTP 503 pour chaque requête entrant dans cette zone, et c'est pour cette raison qu'AWS déconseille de créer des sous-réseaux vides.

Les attributs de target group qui changent le comportement en production

Les réglages de health check ont leur propre leçon. Ces 4 attributs décident comment le trafic atteint une cible saine, et chacun existe pour résoudre une panne précise.

Deregistration delay (deregistration_delay.timeout_seconds, défaut 300 secondes, plage 0 à 3 600). Quand une cible est retirée, elle passe à l'état draining et cesse de recevoir de nouvelles requêtes pendant que celles en vol se terminent. Si le délai expire alors qu'une requête tourne encore, le client reçoit un 502. Si la cible n'a ni requête en vol ni connexion active, le retrait se termine immédiatement, même si la console continue d'afficher draining jusqu'à la fin du minuteur.

Algorithme de routage (load_balancing.algorithm.type, défaut round_robin). Round robin suppose des requêtes semblables sur des cibles semblables. Least outstanding requests envoie chaque requête à la cible qui a le moins de requêtes en cours, ce qui est la bonne réponse quand le coût des requêtes ou la capacité des cibles varie. Weighted random répartit au hasard et c'est le seul algorithme compatible avec l'atténuation d'anomalie d'Automatic Target Weights. Ni l'un ni l'autre ne se combine avec le slow start.

Slow start (slow_start.duration_seconds, défaut 0, soit désactivé, plage 30 à 900). Une cible fraîchement saine reçoit normalement sa part complète de trafic dès qu'elle passe un health check. Pour une application qui doit chauffer un cache ou un compilateur JIT, cette part complète arrive comme un mur de latence. Le slow start monte plutôt la cible en charge de façon linéaire sur la fenêtre configurée.

Stickiness (stickiness.enabled, défaut false). La stickiness par durée fait émettre au load balancer un cookie chiffré AWSALB qui épingle un client sur une cible ; la stickiness applicative suit un cookie posé par votre application. Les 2 se configurent par target group, avec une durée de 1 seconde à 7 jours. Deux contraintes piègent souvent : la stickiness exige que le cross-zone load balancing soit actif, et elle ne fonctionne pas avec l'algorithme weighted random.

Il est tentant de traiter la stickiness comme le correctif d'un problème de session. C'est un contournement, et il vous coûte la régularité de la répartition, parce qu'un événement de scale-out laisse les anciens clients épinglés sur les anciennes cibles. Le vrai correctif consiste à sortir l'état de session de l'instance, vers ElastiCache ou DynamoDB, et un sujet plus loin dans ce domaine reprendra ce fil.

Conseils pour l'examen

• « Router selon le chemin d'URL ou le nom d'hôte » désigne toujours un Application Load Balancer. « Adresse IP statique », « Elastic IP », « des millions de requêtes par seconde » ou un protocole autre que HTTP désignent un Network Load Balancer. « Appliance de pare-feu », « détection d'intrusion » ou « inspection tierce » désignent un Gateway Load Balancer.
• « Les cibles doivent terminer TLS elles-mêmes » exclut un listener HTTPS sur un ALB. La réponse est un Network Load Balancer avec un listener TCP sur le port 443.
• Une charge déséquilibrée entre instances avec le cross-zone dans l'énoncé, c'est le calcul 25 % contre 6,25 %. Comptez les cibles par zone avant même de lire les options.
• Si une question invoque le coût comme raison de ne pas toucher à un réglage de Network Load Balancer, elle parle des frais de transfert inter-zones.
• Des requêtes perdues pendant un déploiement désignent le deregistration delay. De nouvelles instances lentes pendant leur première minute désignent le slow start. Les 2 sont opposés et leurs noms ne le disent pas.
• Un target group enregistré par ID d'instance ne peut pas atteindre un VPC appairé. Si l'énoncé parle de peering, d'hybride ou de cibles on-premises, le type de cible est ip.
• « L'application a besoin de la vraie IP du client », c'est X-Forwarded-For sur un Application Load Balancer, et la préservation de l'IP client ou proxy protocol v2 sur un Network Load Balancer. Rappelez-vous que la valeur par défaut est désactivée pour les target groups ip en TCP et TLS.

L'idée à emporter est qu'un load balancer ne route que vers les cibles qu'il croit saines, et que cette croyance est entièrement construite à partir de réglages de health check que vous avez choisis. Tous les comportements de répartition de cette leçon supposent que ces contrôles disent la vérité. Quand ce n'est pas le cas, des cibles disparaissent de la rotation pour des raisons qui n'ont rien à voir avec l'application, et c'est là que commence la leçon suivante.