Équilibrage de charge, absence d’état et sessions

Ce que fait un équilibreur de charge

Un équilibreur de charge se place entre les clients et un pool d’instances interchangeables et décide, pour chaque connexion ou requête, quelle instance la reçoit. La répartition n’est qu’une partie du travail. Un équilibreur de charge vérifie aussi quelles instances sont en bonne santé et cesse d’envoyer du trafic à celles qui ne le sont pas ; il donne aux clients une adresse stable unique pendant que les instances vont et viennent au gré des déploiements et de l’autoscaling ; il assure souvent la terminaison TLS, de sorte que les certificats sont gérés en un seul endroit ; et en couche 7, il peut router, réessayer, limiter le débit et enregistrer chaque requête. C’est donc le composant qui rend la scalabilité horizontale invisible pour les clients.

L’équilibrage de charge intervient à plusieurs niveaux. Un équilibreur de charge cloud managé ou une paire de proxys comme HAProxy, NGINX ou Envoy se trouve généralement en périphérie. Entre les services, l’équilibrage se fait de plus en plus côté client : une bibliothèque cliente gRPC ou un proxy sidecar de service mesh (section 6.3) détient la liste des instances en bonne santé fournie par la découverte de services et en choisit une lui-même, ce qui supprime un saut réseau et un composant central. Quelle que soit la forme, les mêmes décisions reviennent : ce que l’équilibreur peut voir, quel algorithme il utilise, comment il décide qu’une instance est en bonne santé, et comment les instances partent sans perdre de travail.

Équilibrage de charge de couche 4 et de couche 7

Les numéros de couche viennent du modèle réseau OSI. Un équilibreur de charge de couche 4 travaille au niveau de la couche transport : il voit les adresses IP et les ports TCP ou UDP, choisit un backend à l’ouverture d’une connexion, puis transmet les paquets de cette connexion sans regarder à l’intérieur. Comme il en fait très peu, il est extrêmement rapide et fonctionne avec n’importe quel protocole, y compris les bases de données, les courtiers de messages et le trafic chiffré qu’il ne peut pas lire. Maglev de Google et les équilibreurs de charge réseau des principaux clouds sont des conceptions de couche 4 qui traitent des millions de paquets par seconde.

Un équilibreur de charge de couche 7 est un proxy inverse qui comprend le protocole applicatif, presque toujours HTTP. Il termine la connexion du client (et généralement TLS), lit chaque requête, et ouvre ou réutilise ses propres connexions vers les backends. Cela lui permet de router selon le chemin, l’hôte, un en-tête ou un cookie (/orders/* vers le pool de commandes, /menus/* vers le pool de la carte), d’équilibrer chaque requête plutôt que chaque connexion, de réessayer une requête échouée sur une autre instance, d’appliquer des limites de débit, d’ajouter des en-têtes de traçage et de journaliser chaque requête avec son statut et sa latence. Le prix à payer est davantage de traitement par requête, un composant qui doit détenir les clés TLS, et un endroit de plus où les délais d’expiration et les nouvelles tentatives doivent être configurés de manière cohérente avec le reste du système (section 9.4).

Une différence prend de nombreuses équipes au dépourvu. HTTP/2 et gRPC multiplexent de nombreuses requêtes sur une seule connexion de longue durée. Un équilibreur de couche 4 choisit un backend une fois par connexion, si bien qu’un client qui ouvre une seule connexion envoie toutes ses requêtes à une seule instance, quel que soit le nombre d’instances : les nouvelles instances ajoutées par l’autoscaling ne reçoivent rien tant que les clients ne se reconnectent pas. Équilibrer le trafic gRPC exige donc un proxy de couche 7 ou un équilibrage côté client par requête.

Les algorithmes d’équilibrage de charge

L’algorithme décide quelle instance en bonne santé reçoit la connexion ou la requête suivante. Les plus simples ignorent à quel point les instances sont occupées ; les meilleurs utilisent une mesure de la charge ; ceux fondés sur le hachage envoient délibérément les requêtes liées au même endroit. Le tableau résume les choix courants.

La puissance de deux choix aléatoires

Si « moins de connexions » fonctionne si bien, pourquoi ne pas toujours choisir l’instance la moins chargée globalement ? Parce que, dans un grand système, il n’existe aucune vue unique et actuelle de la charge. Des dizaines d’équilibreurs de charge ou des milliers d’équilibreurs côté client ne voient chacun que leurs propres requêtes, ou un relevé de charge vieux de quelques secondes. S’ils choisissent tous l’instance qui semblait la moins chargée, ils choisissent tous la même, qui est aussitôt submergée, puis ils passent tous à la suivante : un troupeau qui poursuit la charge à travers le pool.

La thèse de doctorat de Michael Mitzenmacher (1996), publiée sous le titre The Power of Two Choices in Randomized Load Balancing (IEEE Transactions on Parallel and Distributed Systems, 2001) et s’appuyant sur des travaux antérieurs d’Azar, Broder, Karlin et Upfal, a analysé une alternative d’une simplicité frappante : choisir deux instances au hasard et envoyer la requête à la moins chargée des deux. Dans le modèle classique des balles et des urnes, placer n requêtes au hasard sur n serveurs donne un serveur le plus chargé avec environ log n ÷ log log n requêtes ; avec deux choix aléatoires, ce nombre tombe à environ log log n ÷ log 2, une amélioration exponentielle, tandis qu’un troisième choix n’apporte que peu de chose de plus. Le hasard empêche l’effet de troupeau, et la comparaison évite les pires instances.

La puissance de deux choix aléatoires est désormais l’option par défaut ou une option standard dans des proxys très répandus : l’équilibreur least-request d’Envoy compare par défaut deux hôtes choisis au hasard, et NGINX propose random two least_conn. C’est un bon choix par défaut pour l’équilibrage côté client dans tout système comportant de nombreux équilibreurs.

Hachage et affinité

Parfois, le but est d’envoyer des requêtes liées à la même instance : à un nœud de cache qui détient déjà la carte d’un restaurant, ou à l’instance qui détient une session WebSocket. Hacher une clé (identifiant du restaurant, identifiant de l’utilisateur, IP source) vers une instance permet d’y parvenir. Un simple hash mod N réaffecte la plupart des clés chaque fois que N change, ce qui vide tous les caches au pire moment, pendant un ajout d’instances. Le hachage cohérent (présenté à la section 7.4) ne déplace qu’environ 1 ÷ N des clés quand une instance arrive ou part. Sa faiblesse, ce sont les clés chaudes : le restaurant le plus populaire à midi tombe sur une seule instance. Des variantes comme le hachage cohérent à charge bornée plafonnent la part de chaque instance et déversent l’excédent sur l’instance suivante de l’anneau.

Contrôles de santé : vivacité et disponibilité

Un équilibreur de charge doit savoir quelles instances peuvent recevoir du trafic. Un contrôle de santé actif sonde chaque instance périodiquement, par exemple GET /healthz toutes les cinq secondes, la marque comme hors service après quelques échecs consécutifs et de nouveau en service après quelques succès. Les contrôles passifs, souvent appelés détection des valeurs aberrantes (outlier detection), observent le trafic réel et éjectent une instance qui renvoie, par exemple, cinq erreurs serveur consécutives. Les deux se complètent : les contrôles actifs trouvent les instances qui ne reçoivent pas de trafic, et les contrôles passifs réagissent aux défaillances qu’une sonde triviale ne met pas à l’épreuve.

Kubernetes a rendu explicite une distinction importante. Une sonde de vivacité (liveness probe) demande si le processus est bloqué sans possibilité de rétablissement (interblocage, mémoire épuisée dans une boucle) ; si elle échoue, l’instance est redémarrée. Une sonde de disponibilité (readiness probe) demande si l’instance doit recevoir du trafic maintenant ; si elle échoue, l’instance est retirée de l’équilibreur de charge mais continue de tourner, par exemple pendant qu’elle chauffe ses caches au démarrage, ou pendant qu’elle déleste de la charge. Une troisième, la sonde de démarrage (startup probe), met les deux autres en attente pendant qu’une application lente démarre.

L’erreur classique consiste à vérifier des dépendances partagées dans ces sondes. Si la sonde de vivacité de chaque instance appelle la base de données, une brève panne de la base fait échouer toutes les sondes, l’orchestrateur redémarre toutes les instances à la fois, et la tempête de redémarrages (caches froids, milliers de nouvelles connexions) prolonge la panne bien après le retour de la base de données. Des contrôles de disponibilité qui incluent une dépendance partagée peuvent de même marquer tout le parc comme non disponible, transformant des erreurs partielles en panne totale. Gardez la sonde de vivacité locale et minimale ; laissez la sonde de disponibilité refléter la capacité propre de l’instance à servir ; et gérez les défaillances des dépendances avec les patrons de la section 9.4. Les équilibreurs de charge se prémunissent contre le cas extrême en échouant en mode ouvert : un Application Load Balancer d’AWS route vers toutes les cibles si toutes échouent à leurs contrôles de santé, et Envoy ignore l’état de santé quand la part d’hôtes en bonne santé tombe sous un seuil de panique (50 % par défaut), au motif qu’envoyer du trafic à des instances douteuses vaut mieux que de ne l’envoyer nulle part.

Drainage des connexions et arrêt en douceur

Les instances quittent le pool en permanence : chaque déploiement les remplace, l’autoscaling les retire, et la plateforme les déplace lors des maintenances. Si une instance est simplement tuée, chaque requête qu’elle traitait échoue, et les clients voient des erreurs pendant ce qui devrait être une mise en production de routine. Le drainage des connexions (appelé deregistration delay chez AWS) retire l’instance de la rotation de l’équilibreur pour qu’elle ne reçoive plus de nouvelles requêtes, attend que les requêtes déjà en cours se terminent, et ne la laisse s’arrêter qu’ensuite.

L’instance doit coopérer. À la réception de son signal d’arrêt, elle doit faire échouer sa sonde de disponibilité, continuer à servir les requêtes en cours, dire aux clients sur des connexions keep-alive d’aller ailleurs (un en-tête Connection: close en HTTP/1.1, une trame GOAWAY en HTTP/2), terminer ou rendre le travail d’arrière-plan, et se terminer avant la fin du délai de grâce. Dans Kubernetes, le retrait d’un pod de l’équilibreur de charge et l’envoi de SIGTERM se produisent en parallèle : une requête peut donc encore arriver juste après le signal ; un court délai pré-arrêt (pre-stop) de quelques secondes couvre cette situation de concurrence. Le délai de grâce par défaut est de 30 secondes, après quoi le processus est tué. Les requêtes de longue durée (gros envois de fichiers, réponses en streaming, WebSockets) exigent soit un délai de grâce plus long, soit un protocole qui permet aux clients de se reconnecter ailleurs sans perdre de travail.

Les sessions persistantes et leurs problèmes

Les applications web plus anciennes conservaient la session de chaque utilisateur (qui est connecté, ce que contient le panier) dans la mémoire du serveur qui l’avait créée. Derrière un équilibreur de charge, cela ne fonctionne que si toutes les requêtes d’un utilisateur reviennent vers ce serveur ; les équilibreurs proposent donc des sessions persistantes (sticky sessions, ou affinité de session), généralement en posant un cookie qui désigne l’instance. La persistance est un moyen rapide de placer une application avec état derrière un équilibreur, et elle a un usage légitime comme indication de performance, par exemple pour garder un utilisateur sur une instance dont le cache local contient déjà ses données.

Comme garantie de bon fonctionnement, en revanche, elle pose des problèmes. La charge devient inégale, car quelques gros utilisateurs ou un grand bureau derrière une seule adresse IP restent attachés à une instance quelle que soit sa charge. Quand une instance tombe en panne, ses utilisateurs perdent leur session : les paniers disparaissent et les gens sont déconnectés. Les retraits d’instances et chaque déploiement ont le même effet, sauf si les sessions sont drainées, ce qui peut prendre autant de temps que la plus longue session. Les nouvelles instances ajoutées par l’autoscaling ne reçoivent que les nouveaux utilisateurs : elles soulagent donc lentement les instances surchargées. Et le système n’est plus sans état au sens de la section 9.1, si bien que chacun de ces problèmes réapparaît lors d’un basculement entre zones ou entre régions.

Externaliser l’état de session

Le remède consiste à sortir l’état de session de l’instance, pour que n’importe quelle instance puisse servir n’importe quelle requête. Il existe trois options principales, souvent combinées. Un jeton côté client transporte l’état avec chaque requête : un cookie signé (et si nécessaire chiffré) ou un jeton comme un JWT contenant l’identité de l’utilisateur et quelques données. Les serveurs n’ont besoin d’aucun stockage, mais les jetons doivent rester petits, ne peuvent pas facilement être révoqués avant leur expiration et doivent être protégés contre la falsification et le vol (section 8.3). Un stockage de sessions partagé, typiquement Redis ou Memcached, conserve les sessions dans un stockage externe rapide, indexé par un identifiant de session placé dans le cookie ; il gère un état plus volumineux et la déconnexion immédiate, au prix d’un appel réseau par requête et d’une dépendance qui doit elle-même être hautement disponible. Une base de données convient à l’état qui doit survivre à tout, comme un panier que l’utilisateur s’attend à retrouver le lendemain, qui relève en réalité des données métier plutôt que des données de session.

Un découpage pratique pour la plateforme de livraison de repas : l’identité dans un jeton signé de courte durée, le panier dans la base de données du service de commandes (les utilisateurs passent du téléphone à l’ordinateur portable), et l’état transitoire de l’interface dans le client. Aucune instance ne conserve quoi que ce soit dont une requête ultérieure a besoin : l’équilibreur de charge peut donc utiliser un équilibrage « moins de requêtes » sans affinité, et les instances peuvent être ajoutées, retirées et remplacées à volonté.

Équilibrage de charge global : DNS et anycast

Dès qu’un système tourne dans plusieurs régions, quelque chose doit envoyer chaque utilisateur vers une région adaptée : la région en bonne santé la plus proche, ou celle qui détient ses données. L’équilibrage de charge global se fait généralement de l’une de deux façons, souvent combinées.

L’équilibrage de charge global des serveurs fondé sur le DNS utilise un serveur de noms faisant autorité qui répond au même nom par des adresses différentes selon l’origine de la requête, la santé de chaque région et des poids configurés : un utilisateur à Lisbonne reçoit l’adresse de la région UE, un utilisateur dans l’Ohio celle de la région US. Il ne nécessite aucun réseau particulier, mais il est grossier et lent à réagir. Les réponses sont mises en cache par les résolveurs au moins pendant la durée de vie de l’enregistrement (souvent 30 à 300 secondes), et parfois plus longtemps : après la défaillance d’une région, certains utilisateurs continuent donc d’y arriver pendant plusieurs minutes. Le serveur de noms voit l’emplacement du résolveur plutôt que celui de l’utilisateur, même si l’extension EDNS Client Subnet (RFC 7871) permet aux résolveurs de transmettre une partie de l’adresse du client.

Avec l’anycast, la même adresse IP est annoncée depuis de nombreux sites par le protocole de routage d’internet (BGP), et les paquets de chaque utilisateur sont livrés au site le plus proche au sens du routage. Le basculement consiste à retirer l’annonce d’un site défaillant, ce qui prend effet rapidement sans attendre les caches DNS. L’anycast est utilisé depuis longtemps pour les serveurs racines du DNS et les services de résolution ; les CDN et les équilibreurs de charge globaux des grands fournisseurs de cloud l’utilisent pour amener les utilisateurs vers un site périphérique proche, où des proxys de couche 7 terminent la connexion et transmettent les requêtes, via le réseau du fournisseur, à une région en bonne santé. La conception multirégion, le placement des données et le basculement sont le sujet de la section 10.6.