Aujourd’hui, on va parler d’équilibrage de charge (aka. load-balancing) et plus particulièrement des solutions proposées par Microsoft sur son cloud Azure.

Avant de rentrer dans le vif du sujet, prenons un peu de temps pour définir ce qu’est l’équilibrage de charge et à quoi ça sert.

L’équilibrage de charge désigne le fait de distribuer des charges de travail sur plusieurs ressources. Il vise plusieurs objectifs :

• optimisation de l’utilisation des ressources
• optimisation du débit
• réduction du temps de réponse
• éviter la surcharge d’une seule ressource
• amélioration de la disponibilité / redondance

Source : https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview

Grâce à cette définition, on comprend aisément que l’équilibrage de charge est d’une grande importance dans les environnements informatiques modernes. Il aide à résoudre les problématiques de haute disponibilité (tolérance aux pannes) et de scalabilité (mise à l’échelle horizontale) tout en offrant des possibilités de gestion fine du trafic (par exemple, la distribution géographique).

Dans son cloud Azure, Microsoft propose 4 services permettant de faire de l’équilibrage de charge :

• Traffic Manager
• Load Balancer
• Application Gateway
• Front Door

Avant de passer à la présentation de chaque service, il me semble important de faire le point sur 2 options qui vont orienter votre choix.

Table des matières

Global vs Régional

La première option va permettre de choisir le périmètre de distribution du trafic.

Dans le cas de l’équilibrage de charge global, le service va distribuer le trafic entre des ressources situées dans des régions géographiquement distinctes. Il est capable de rediriger l’utilisateur vers un serveur proche, ce qui contribue à l’amélioration des performances et de la latence. De plus, ce type d’équilibrage est robuste vis-à-vis des pannes géographiques.

A l’inverse, l’équilibrage de charge régional va répartir le trafic entre des ressources situées dans une seule région. C’est pratique lorsque vous avez besoin d’optimiser les performances ou la disponibilité d’une application au sein d’une même région (entre plusieurs VM ou conteneurs par exemple).

Comme nous le verrons un peu plus loin, ces choix ne sont pas exclusifs et il est possible de combiner les 2 approches en fonction de vos besoins et contraintes.

HTTP(s) vs non-HTTP(s)

La seconde option permet de choisir le type de protocole supporté par l’équilibrage de charge.

Dans le cas du protocole HTTP(s) (couche 7 du modèle OSI), il est possible de configurer des règles basées sur l’URI ou les headers HTTP. Il y a aussi des fonctionnalités comme le déchargement SSL, un WAF (Web Application Firewall) ou l’affinité de session. Le cas d’usage principal est la répartition de trafic entre des serveurs web.

Dans le cas des protocoles non-HTTP(s), comme TCP ou UDP, les règles seront plutôt basées sur les IPs ou les ports. Cette fois, on est sûr des cas d’usage de répartition de trafic entre des services non-web, comme des bases de données ou des serveurs de messagerie.

Pour résumer, voici un tableau récapitulatif de ces 2 options par rapport aux 4 services Azure :

Service	Global / régional	Trafic recommandé	Technologie
Azure Front Door	Global	HTTP(s)	7 - Application
Traffic Manager	Global	non-HTTP(s)	DNS
Application Gateway	Régional	HTTP(s)	7 - Application
Azure Load Balancer	Zones géographiques	non-HTTP(s)	4 - Transport

En prime, Microsoft propose un arbre de décision permettant d’aider au choix :

Et aussi un outil sous la forme d’un questionnaire. En fonction de vos réponses, il est capable de vous proposer des combinaisons de service si c’est nécessaire.

Maintenant que l’on a fait le tour des bases, on va pouvoir explorer plus en détails chaque service et découvrir leurs spécificités et cas d’utilisation.

Traffic Manager

Ce service a été publié en avril 2011. Il s’agit d’un service de gestion du trafic basé sur DNS (aka. Domain Name System), c’est-à-dire au niveau de la couche Application (couche 7 du modèle OSI).

Le principe est simple : assurer la meilleure réponse DNS pour le client tout en contrôlant l’intégrité des points de terminaison. Potentiellement, chaque client peut donc recevoir un enregistrement DNS différent.

Pour déterminer la meilleure réponse, il existe plusieurs méthodes :

• latence faible (ou performance) :
  • il s’agit d’une assignation automatique des ressources (aka. routage intelligent)
  • le point de terminaison ayant la latence la plus faible pour le client sera proposé (c’est souvent celui le plus proche géographiquement)
  • pour cela, Azure se base sur une table de latence, mesurant le temps entre les plages d’IP et chaque centre de données Azure (qui est recalculée fréquemment)
• priorité :
  • il s’agit d’une assignation manuelle des ressources, il n’y a pas d’intelligence particulière avec ce mode de routage.
  • si le endpoint P1 est disponible (aka. online) alors le client recevra systématiquement les informations de connexion vers ce endpoint. S’il est indisponible (aka. offline ou désactivé), alors ce sera P2.
  • cela permet de mettre en place un système de failover/backup
• géographie :
  • se base sur la localisation géographique du client pour l’envoyer vers un endpoint proche
  • pour cela, Azure utilise une base de données de géolocalisation, qui permet d’associer un emplacement géographique à partir d’une adresse IP
  • chaque endpoint doit se voir affecter une région et il y existe différent niveau de granularité : monde, regroupement régional, pays et province (uniquement pour l’Australie, le Canada et les Etats-Unis) => https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-geographic-regions
• poids :
  • permet de répartir le trafic simultanément entre plusieurs endpoints, de manière uniforme ou non
  • se base sur des poids, sous forme d’entier de 1 à 1000, et plus l’entier est élevé, plus il est prioritaire
  • pour chaque requête, Traffic Manager va choisir “au hasard” un endpoint, et la probabilité de choisir un endpoint dépend du poids qui lui est associé
  • pratique pour rediriger une faible partie des utilisateurs vers la nouvelle version d’un site web par exemple
  • si vous avez déjà utilisé Azure Web App, il existe déjà une option permettant de réaliser cela, mais elle est limitée à une seule région Azure.
• valeurs multiples : permet de retourner plusieurs points de terminaison sains au client, pour lui permettre de faire de nouvelles tentatives plus efficacement.
• subnet : permet de retourner un point de terminaison spécifique en fonction de l’IP du client. Par exemple, vous pouvez afficher un contenu différent si vos utilisateurs se connectent à un site web à partir de votre siège social.

Pour bien comprendre le fonctionnement de chaque méthode de routage, un schéma est parfois plus clair ! Je vous invite à consulter la documentation de Microsoft à ce sujet, leurs schémas sont parfait ;)

Concernant les points de terminaison (aka. endpoints), Traffic Manager prend en charge 3 types :

• Les services hébergés dans Azure (service PaaS, Web Apps, adresse IP publique avec un nom DNS…)
• Les endpoints externes
• Les endpoints imbriqués

Pour ce dernier type, il faut savoir qu’un profil Traffic Manager ne peut avoir qu’une seule méthode de routage (par contre, il peut avoir plusieurs types de endpoint). Ce type de endpoint permet donc d’imbriquer des profils Traffic Manager pour combiner différentes méthodes de routage.

Imaginons un scénario d’un site web avec 4 WebApps, réparties dans différentes régions (West Europe, North Europe, East US, West US). On pourrait prévoir 2 profils Traffic Manager imbriqués :

• un premier profil de type géographie pour répartir les utilisateurs vers le endpoint le plus proche (Europe ou US)
• puis un second profil imbriqué de type priorité, avec plusieurs endpoints, pour gérer les éventuelles pannes au sein de la zone géographique

Traffic Manager propose des outils pour suivre le trafic, notamment Traffic View. Ce dernier permet de surveiller les requêtes reçues et d’en extraire la localisation géographique pour les regrouper par régions. Cela permet à Azure de construire une carte permettant de visualiser le volume de trafic par région, pour le corréler avec la latence dans le but d’ouvrir de nouvelles régions Azure (pour apporter de meilleures performances à vos utilisateurs).

Traffic Manager est particulièrement adapté pour rendre une application robuste à la défaillance d’une région, en permettant d’acheminer le trafic de manière transparente vers la région la plus proche, et ce, sans aucune intervention manuelle et tout en conservant un haut niveau de performance (aka. latence).

Azure Load Balancer

Ce service a été publié en avril 2012. Il permet de répartir du trafic réseau entrant au sein d’un groupe de ressources ou de serveurs back-end (des Azure Virtual Machine). Il opère au niveau de la couche Transport (couche 4 du modèle OSI).

Il s’agit de la solution d’équilibrage de charge la plus performante d’Azure. Azure Load Balancer est capable de gérer plusieurs millions de requêtes par seconde avec une faible latence.

Azure Load Balancer va exposer un point d’entrée unique pour les clients, et c’est lui qui va se charger de les répartir. Etant donné qu’il opère sur la couche 4 du modèle OSI, soit la couche Transport, on va donc pouvoir définir des règles basées sur les ports ou les IPs sources.

Ce service peut avoir 2 modes de fonctionnement :

• public : permet l’équilibrage de charge du trafic en provenance d’internet ; traduction d’adresses IP privées en adresses IP publiques
• privé (aka. interne) : dans le cas où l’on souhaite équilibrer le trafic interne avec uniquement des adresses IP privées

Un concept important dans Azure Load Balancer est la sonde d’intégrité. Elle permet de connaitre l’état des points de terminaison (aka. les VMs) et donc de savoir si ceux-ci sont prêts à recevoir du trafic ou non. En cas d’échec d’une sonde d’intégrité, l’équilibreur de charge n’envoie plus de données (la connectivité sortante n’est pas affectée). Il est possible d’en détourner l’usage en renvoyant de manière intentionnelle un code HTTP autre que 200. C’est très pratique pour, par exemple, mettre une application en mode maintenance.

Autre concept fondamental, les règles d’équilibrage. Une règle permet de distribuer le trafic entrant envoyé à une combinaison adresse IP + port vers un pool de backend. Bien sûr, avec l’aide des sondes, le trafic est redirigé uniquement aux instances saines.

A noter, la présence d’un paramètre Session persistence. Il permet de contrôler le mode de distribution des requêtes. Il existe 3 modes :

• par défaut, c’est basé sur un hachage à 5 tuples (IP source, port source, IP destination, port destination et type de protocole). Dans ce mode, il n’y a aucune affinité de session. Des requêtes successives d’un même client pourront donc être gérées par n’importe quelle machine du pool.
• persistance par adresse IP : dans ce cas, la distribution est basée sur un hachage à 2 tuples (IP source et IP destination).
• persistance par adresse IP et protocole : dans ce cas, la distribution est basée sur un hachage à 3 tuples (IP source, IP destination et type de protocole).

Dans les 2 derniers modes (aka. avec affinité de session), les flux en provenance du même client vont donc à la même instance backend d’un pool.

Pour terminer, je souhaite faire le focus sur 2 fonctionnalités permettant d’améliorer la disponibilité de votre load balancer.

• Les zones de disponibilité : dans les régions concernées, cela permet au load balancer d’être résistant à la panne d’une ou plusieurs zones de disponibilité, et ce, avec une adresse IP unique pour votre frontend (mode redondant interzone). Vous pouvez aussi choisir de ne garantir un frontend que dans une seule (mode zonal) ou encore n’offrir aucune garantie (mode non zonal).
• L’équilibreur de charge inter-région : il s’agit d’une nouveauté de juillet 2023. Cela permet d’équilibrer le trafic global vers le load balancer régional optimal (en général, le plus proche).

Front Door

Ce service a été publié en septembre 2019. Issu d’un développement interne, FrontDoor est utilisé par Microsoft pour distribuer certains de ses services phares, comme Office 365 ou la recherche Bing. Il est plutôt destiné à des grosses applications recevant un fort trafic entrant et ayant besoin d’une présence mondiale.

En termes de fonctionnalités, il est très proche d’Azure Application Gateway. La principale différence est que Front Door est un service global, s’appuyant sur le Microsoft Global Network, et utilisant le protocole Anycast. Cela permet aux requêtes des utilisateurs d’atteindre l’emplacement de périphérie le plus proche (aka. avec le moins de tronçons réseau).

Dans Azure Front Door, un concept important est l’origine. Il s’agit du point de terminaison de votre backend, autrement dit ce que doit appeler Front Door lorsque la mise en cache est désactivée ou que la donnée n’est pas disponible dans le cache. Pour être tout à fait clair, il s’agit de vos VMs ou App Service ;) Vous allez pouvoir regrouper vos origines dans des groupes d’origines pour les instances de vos applications répondant aux mêmes critères de distribution du trafic. Pour optimiser le fonctionnement de l’ensemble, n’oubliez pas, au niveau de vos origines, de bloquer le trafic qui ne transite pas par Front Door.

Lors du routage (aka. comment le trafic est distribué entre les différentes origines), Front Door va suivre plusieurs étapes pour déterminer l’origine cible :

1. Détermination des origines disponibles (marquées saines par les sondes d’intégrité et non désactivées)
2. Tri par priorité
3. Tri par latence
4. Répartition du trafic via l’algorithme Round Robin entre les groupes d’origines sélectionnés et dans les proportions définies (utile pour faire du déploiement progressif)

Grâce au WAF (aka. Web Application Firewall) intégré, il est possible de configurer des règles pour personnaliser la gestion des requêtes et réponses. Par exemple, on va pouvoir ajouter/modifier les headers HTTP, router les requêtes en provenance de périphériques mobiles vers le backend adapté ou encore faire de la réécriture d’URL.

Front Door va aussi disposer d’une brique permettant de se protéger contre les attaques DDoS (aka. déni de service distribué).

Une solution souvent utilisée est la combinaison d’Azure Front Door en tête de file, pour router le trafic vers la région appropriée. Ensuite, c’est Azure Application Gateway qui prend le relais pour distribuer le trafic vers le bon service (un App Service par exemple).

Front Door est aussi très pratique via un usage de type CDN (aka. Content Delivery Network), pour délivrer du contenu statique (images, fichiers CSS/JS, documents…) mais aussi pour gérer un système de cache en périphérie. Je vous invite à lire la page de documentation de Microsoft à ce sujet.

Azure Front Door permet d’améliorer la disponibilité de vos applications avec un déploiement dans plusieurs régions. Il est particulièrement adapté dans le cas où les applications sont déployées dans différents types d’environnement (cloud Azure, autre cloud provider, on-premise…).

Application Gateway

Ce service a été publié en février 2016. Techniquement, on est très proche d’Azure Front Door. On travaille donc aussi sur la couche Application (couche 7 du modèle OSI). La principale différence vient du fait qu’Application Gateway est un équilibreur de charge régional alors que Front Door est global/mondial. De ce fait, il offre un contrôle plus précis sur la façon dont le trafic va être réparti au sein d’une même région.

Ces 2 outils sont d’ailleurs souvent utilisés en combinaison :

• Front Door en tant que point d’entrée global et unique pour l’ensemble de votre trafic
• Application Gateway dans chaque région

Lors de la configuration d’Application Gateway, on va retrouver 4 types d’objet :

• L’écouteur (aka. listener) : c’est le point d’entrée de l’Application Gateway. Il vérifie les requêtes de connexion entrantes, en se basant sur le protocole, le port, le hostname et l’ip. En fonction, il est équipé d’une ip publique ou privée.
• Le backend : il s’agit des services cibles. Ils peuvent être de différents types : adresses IP publiques ou privées, nom de domaine, carte réseau, VM ou pool de VMs, App Service… A noter, comme pour Front Door, on peut donc cibler des services en dehors d’Azure.
• Le pool de backend : cela permet de regrouper plusieurs backends répondant aux mêmes règles de routage.
• La règle : elle permet de lier l’écouteur et le pool de backend pour définir le mode de routage. C’est ici que l’on va pouvoir configurer le protocole et le port, l’affinité des cookies et de la session ainsi que les éléments spécifiques au hostname.

A noter, Microsoft a récemment sorti en preview la brique Application Gateway for Containers. C’est une évolution de Application Gateway Ingress Container (aka. AGIC).

Conclusion

Nous avons fait le tour des différents services d’équilibrage de trafic d’Azure. Comme je l’ai déjà évoqué dans l’article, chaque service à ses propres spécificités et contraintes, et il est important avant de choisir une solution, de bien identifier vos besoins. Il est bien sûr possible de combiner les services entre eux pour bénéficier des avantages de chacun. Dans Azure Architecture Center, Microsoft détaille plusieurs architectures de référence mettant en oeuvre un ou plusieurs équilibreurs de charge.

En tout cas, j’espère vous avoir donné envie d’explorer ces services et de mettre en place des applications hautement disponibles et performantes ;)