Équilibrage de charge : définition et exemples

L'équilibrage de charge (ou Load Balancing en anglais) est une technique d'architecture informatique qui permet, comme son nom l'indique, de répartir la charge (les requêtes) vers plusieurs cibles d'un même groupe. Très souvent utilisé pour les applications Web, l'équilibrage de charge est une pratique incontournable dès que l'on souhaite redimensionner (scaler) une application pour être capable de répondre à chacune des demandes, lorsque ces dernières augmentent considérablement.

Mais comment se fait l'équilibrage de charge en pratique ? Comment peut-on ajouter ou supprimer des serveurs cibles à tout moment ?

Architecture

Construire une architecture Cloud ne consiste pas juste en un assemblage de services, mais nécessite de satisfaire plusieurs conditions.

• Assurer la sécurité des utilisateurs, des applications et des données dans l’infrastructure.
• Préserver l’excellence opérationnelle tout au long de l’évolution de l’infrastructure.
• Garantir une fiabilité des systèmes à l’aide d’une haute disponibilité.
• Conserver le maintien des systèmes avec les tolérances à la panne.
• Assurer l’efficacité en termes de performances avec du redimensionnement automatique.
• Optimiser les dépenses liées à l’infrastructure.

En particulier, la haute disponibilité et la scalabilité sont deux concepts utilisant l'équilibrage de charge, et qui permettent de répondre en partie à ces exigences.

Haute disponibilité

La haute disponibilité (HA pour high availability) est la capacité d’une application ou d’un système à être disponible et accessible avec un niveau de garantie très élevé.

Elle est d’autant plus importante lorsque l’application ou le produit distribué est une plateforme Web qui génère un revenu pour l’entreprise : chaque minute d’interruption peut avoir de grandes conséquences.

Autrement dit, on souhaite minimiser l’interruption de service (downtime) pour les utilisateurs. Il faut donc que le système soit capable d’évoluer avec le moins d’interaction humaine.

Les services en ligne proposent des garanties de disponibilité (SLA pour Service Level Agreement) : un SLA de 99.99% indique que le service pourra être inaccessible au maximum 53m 35s par an.

Élasticité et scalabilité

Les nombreux serveurs à disposition dans les Data Centers offrent une élasticité importante.

L’élasticité est la capacité d’une application ou d’un système informatique à s’adapter en fonction de la charge de travail.

Lorsque l’on doit intégrer l’élasticité pour une application, on doit être capable de provisionner automatiquement à tout moment et en un temps très court des serveurs, tout comme on peut en retirer si certains sont inutilisés.

L'équilibrage de charge est donc une brique supplémentaire pour parvenir à satisfaire toutes ces conditions, bien qu'elle ne constitue pas en soi la seule solution à toutes ces exigences.

Équilibrage de charge

L’équilibrage de charge (répartition de charge) est nécessaire pour mettre à l’échelle horizontalement (ajout de serveurs) une application.

Il s’agit d’un serveur frontal (appelé load balancer) dans une région qui permet de distribuer le trafic entrant vers plusieurs cibles (serveurs, conteneurs, adresses IP) sur une ou plusieurs zones et qui forment un cluster.

Chacune de ces cibles se situe dans un réseau avec lequel le load balancer peut communiquer. Cette représentation sous forme de cluster est très puissante

Redirection du trafic et algorithmes

Le rôle du load balancer est principalement de rediriger et distribuer les requêtes parmi un ensemble de serveurs cibles. Il existe plusieurs techniques qui permettent de répartir le trafic sur les serveurs cibles, dont les plus populaires sont les suivantes.

• Round Robin : il s'agit du plus simple, car les requêtes vont être distribués sous forme de rotation. Si l'on dispose par exemple de trois serveurs cibles, alors une requête sera envoyée au premier serveur, la prochaine au second serveur, puis au troisième serveur, pour enfin revenir au premier serveur et continuer le cycle à l'infini. Dans la plupart des cas, cet algorithme, bien que simple, permet de répondre à la plupart des besoins.
• Weighted Round Robin : très similaire au Round Robin, cet algorithme va utiliser une pondération (weight) affectée à chaque serveur cible pour déterminer la proportion de requêtes à envoyer. Plus un serveur aura une pondération élevée, plus il recevra de requêtes.
• Resource Based : les algorithmes dits « basés sur les ressources » permettent de prendre en considération l'utilisation CPU ou mémoire d'un serveur cible pour rediriger les requêtes. Par exemple, si un serveur est sous-tension, alors on préférera le laisser terminer ses précédentes requêtes avant de lui en envoyer de nouvelles. Bien que ces algorithmes semblent plus précis (car on tient compte de la performance des serveurs), cela nécessite d'avoir un agent installé sur chaque serveur cible qui puisse faire remonter ces informations, ce qui n'est pas toujours facile à faire en pratique.
• Least Connection : certaines requêtes peuvent mettre plus de temps à s'exécuter que d'autres. C'est là que l'algorithme Least Connection permet de prendre en compte le nombre de connexions concurrentes : cet algorithme va à chaque requête choisir le serveur cible qui dispose du plus faible nombre de connexions, évitant ainsi d'avoir trop de requêtes en simultané sur un serveur.
• URL Hash : la redirection du trafic sera effectuée en fonction du chemin de l'URL. Cela peut être utile par exemple si l'on dispose de plusieurs versions d'une application, ou lorsque plusieurs services différents sont exposés derrière une seule et même API.

Il existe également d'autres algorithmes plus spécifiques, qui vont prendre en compte la tension des réseaux par exemple, lorsque la problématique n'est pas directement liée aux ressources des instances/serveurs, mais plutôt à la bande passante.

Vérification des états de santé

Que se passe-t-il si un des serveurs tombe en panne ? Dans ce cas, il ne faudrait pas rediriger les requêtes vers ce serveur, car ces dernières ne pourront pas être prises en charges.

Les équilibreurs de charge ont également des fonctionnalités qui permettent de détecter et vérifier l'état de santé des cibles, c’est-à-dire si ces dernières sont disponibles et atteignables.

Si un des serveurs ne répond plus correctement à une requête spécifique qui retourne l'état de santé de la cible, alors l'équilibreur de charge va automatiquement retirer ce serveur comme cible.

Exécuter un équilibreur de charge

Pour construire et exécuter un équilibreur de charge, il y a plusieurs possibilités.

• Le plus simple consiste à utiliser les services d'équilibrage de charge sur les fournisseurs Cloud (AWS, GCP, Azure). Le principal avantage est que l'intégration avec les autres services se fait naturellement. Par exemple, sur l'Auto Scaling (redimensionnement automatique) s'interface naturellement avec la répartition d'un load balancer sur AWS, sans trop grande complexité.
• Il est possible d'exécuter des services de répartition de charge comme HAProxy sur ses propres serveurs. L'avantage de ce genre d'outil est une granularité plus importante pour la configuration, en comparaison avec ceux des fournisseurs Cloud. En revanche, il faut soi-même tout configurer, jusque dans les moindres détails techniques.

Quand utiliser un équilibreur de charge ?

Il existe de nombreuses situations où l’utilisation d’un équilibreur de charge est nécessaire.

• Dans le cas où l’on souhaite assurer l'élasticité et/ou la scalabilité, l’équilibreur de charge va s’assurer que le trafic est distribué sur tous les serveurs.
• Pour garantir une haute disponibilité, on réplique un serveur dans 1 ou 2 autres zones : l’équilibreur de charge va permettre de gérer les situations où un des serveurs tombe en panne.
• Lorsque les cibles sont de natures différentes (serveur, conteneurs, fonctions serverless), l’équilibrage de charge fait office de point central qui permet à n’importe quel utilisateur de requêter dessus, indépendamment de la cible finale de la requête.
• Les équilibreurs de charges permettent également de router le trafic entrant en fonction de règles spécifiques comme la localisation, le chemin de l’URL ou selon une pondération définie à l’avance.

En parallèle, on configure souvent des métriques et alarmes sur des équilibreurs de charges. Cela permet à la fois de surveiller les requêtes entrantes, mais aussi de prévenir en cas de problème technique.