Tout ce que tu as besoin de savoir

Les répartiteurs de charge applicatifs sont des outils essentiels qui optimisent l'évolutivité, la performance et la disponibilité de vos applications. Ils jouent un rôle crucial en évitant la surcharge de vos serveurs et en garantissant une gestion efficace des pics de trafic.

La sécurité de l'infrastructure informatique repose en grande partie sur ces répartiteurs. Ils s'assurent que votre application peut traiter le flux de requêtes entrantes. Cet article explore en détail le fonctionnement d'un répartiteur de charge applicatif sur AWS.

Qu'est-ce qu'un répartiteur de charge applicatif ?

Un répartiteur de charge applicatif, souvent abrégé en ALB, est un service d' équilibrage de charge élastique (ELB) proposé par AWS. Il fonctionne au niveau de la couche application, soit la septième couche du modèle OSI.

Un ALB est constitué de trois éléments clés : les écouteurs, le répartiteur de charge lui-même et les groupes cibles. Lorsqu'une requête arrive, le répartiteur évalue les règles des écouteurs par ordre de priorité pour déterminer quelle règle doit être appliquée. Il sélectionne ensuite une cible dans le groupe cible correspondant pour exécuter l'action définie par la règle.

Vous pouvez configurer des règles d'écoute qui dirigent les requêtes vers différents groupes cibles en fonction du contenu du trafic de l'application. L'algorithme de routage par défaut pour un ALB est le Round-robin, mais vous pouvez opter pour une technique de routage vers la cible ayant le moins de requêtes en attente.

Les ALB offrent la flexibilité d'ajouter ou de supprimer des cibles en fonction de l'évolution de vos besoins sans perturber le flux de requêtes de votre application.

Le service Elastic Load Balancing (ELB) permet à votre répartiteur de charge de s'adapter automatiquement aux variations du trafic de votre application. La plupart des charges de travail peuvent ainsi être gérées de manière autonome.

Vous pouvez également mettre en place des contrôles d'état pour surveiller la santé de votre application sur les cibles enregistrées, garantissant que le répartiteur de charge n'envoie des requêtes qu'aux cibles opérationnelles.

Fonctionnalités des répartiteurs de charge applicatifs

Équilibrage de charge de couche 7

Grâce à l'analyse des attributs de la demande, vous pouvez répartir le trafic HTTP/HTTPS et gRPC vers diverses ressources : instances Amazon EC2, conteneurs ECS, fonctions AWS Lambda, serveurs tiers ou même infrastructures sur site.

Fonctions de sécurité

Les ALB intègrent des mécanismes de protection contre la désynchronisation, basés sur la librairie HTTP desync-guardian. Ils protègent vos applications contre les vulnérabilités HTTP liées à la désynchronisation sans compromettre la disponibilité ou la latence. Vous pouvez également personnaliser le niveau de tolérance aux requêtes potentiellement problématiques, en fonction de l'architecture de vos applications.

Support des avant-postes

Les avant-postes AWS constituent une solution entièrement gérée qui étend l'infrastructure, les services et les outils d'AWS à divers environnements : centres de données, espaces de colocation ou installations sur site. Vous pouvez utiliser les répartiteurs de charge applicatifs avec les avant-postes AWS. Les ALB sont déployables sur les types d'instances compatibles et s'adaptent automatiquement aux capacités du rack pour faire face aux variations de charge de travail, sans intervention manuelle.

Il est possible de configurer les ALB pour recevoir des notifications et des alertes, ce qui facilite la gestion des besoins en capacité d'équilibrage de charge. L'utilisation de la console AWS, de l'interface de ligne de commande et des API est identique pour provisionner et gérer les ALB dans les régions AWS et sur les avant-postes.

Terminaison HTTPS

Un répartiteur de charge applicatif (ALB) prend en charge la terminaison HTTPS entre les clients et le répartiteur. Cela implique que la connexion entre votre client et l'ALB est sécurisée par HTTPS, tandis que la communication entre l'ALB et les serveurs d'applications (EC2, ECS, etc.) s'effectue via HTTP.

Comme la communication entre l'ALB et les serveurs d'applications se déroule à l'intérieur de votre VPC, elle est par défaut protégée des accès externes. Les ALB peuvent gérer les certificats SSL via AWS Certificate Manager pour les politiques de sécurité prédéfinies et AWS Identity and Access Management (IAM).

Prise en charge HTTP/2 et gRPC

HTTP/2 est une nouvelle version du protocole HTTP qui permet de transmettre plusieurs requêtes simultanément via une seule connexion multiplexée. Il offre des connexions SSL aux clients et compresse les données d'en-tête avant de les envoyer sous forme binaire.

Le trafic gRPC peut être routé et équilibré entre les microservices, ou entre clients et services compatibles gRPC grâce au répartiteur de charge applicatif. Cela permet une intégration fluide de la gestion du trafic gRPC dans les architectures, sans modification de l'infrastructure sous-jacente côté clients ou services.

gRPC est le protocole de communication privilégié pour les microservices, utilisant HTTP/2 pour la transmission. Il offre des avantages tels que la sérialisation binaire efficace, la prise en charge de nombreux langages, ainsi que les atouts d'HTTP/2 : empreinte réseau réduite, compression, et flux bidirectionnels. Il surpasse ainsi les protocoles plus anciens comme REST.

Sessions persistantes

Les sessions persistantes dirigent les requêtes d'un même client vers la même cible en utilisant des cookies. Vous pouvez facilement configurer les sessions persistantes en activant cette fonctionnalité et en configurant les cookies dans les paramètres de l'ALB. Les répartiteurs de charge applicatifs supportent les cookies basés sur la durée et les cookies basés sur l'application.

La durée pendant laquelle un répartiteur doit envoyer les requêtes d'un utilisateur vers la même cible est un paramètre clé pour la gestion des sessions persistantes. Ces sessions sont activées au niveau du groupe cible. Il est possible de combiner des stratégies d'adhérence basées sur la durée, basées sur l'application ou d'opter pour l'absence d'adhérence, selon les différents groupes cibles.

Prise en charge native d'IPv6

Les répartiteurs de charge applicatifs prennent nativement en charge le protocole IPv6 au sein d'un VPC. Les clients peuvent ainsi se connecter à l'ALB en utilisant IPv4 ou IPv6.

Suivi des requêtes

L'ALB injecte un nouvel en-tête HTTP personnalisé, "X-Amzn-Trace-Id", dans chaque requête entrante. Ce suivi permet de suivre le parcours d'une requête lorsqu'elle est transmise à travers plusieurs services AWS grâce à son identifiant unique. Vous pouvez utiliser le suivi de requêtes pour identifier les problèmes de performance ou les goulots d'étranglement dans votre application.

Redirections

Un ALB peut rediriger une requête d'une URL vers une autre. Vous pouvez par exemple rediriger les requêtes HTTP vers HTTPS, améliorant ainsi la sécurité de votre site et votre classement dans les moteurs de recherche. Les redirections permettent également de diriger les utilisateurs vers une autre version de votre application.

Réponse fixe

Un répartiteur de charge applicatif peut gérer directement les requêtes des clients. Vous pouvez configurer l'ALB pour répondre aux requêtes entrantes avec des codes d'erreur HTTP et des messages personnalisés, sans que la requête ne soit transmise à l'application.

Prise en charge des WebSockets

Les répartiteurs de charge applicatifs supportent le protocole WebSockets, qui permet aux serveurs d'envoyer des messages en temps réel aux utilisateurs sans qu'ils aient à solliciter des mises à jour. Les WebSockets permettent une communication bidirectionnelle sur une connexion TCP de longue durée entre un client et un serveur.

Indication du nom du serveur (SNI)

SNI est une extension du protocole TLS qui permet au client de spécifier le nom d'hôte auquel il souhaite se connecter lors de la négociation TLS. L'ALB peut présenter plusieurs certificats via un seul écouteur sécurisé, ce qui permet de prendre en charge de nombreux sites web sécurisés avec un seul écouteur.

Grâce à SNI, l'ALB utilise un processus de sélection de certificat intelligent pour faire correspondre le nom d'hôte dans la requête avec le certificat SSL approprié. Si le nom d'hôte correspond à plusieurs certificats, le répartiteur de charge sélectionne le certificat optimal en fonction de divers paramètres, notamment les capacités du client.

Adresses IP comme cibles

Vous pouvez utiliser les adresses IP des serveurs d'arrière-plan comme cibles, ce qui permet aux ALB d'équilibrer la charge d'applications hébergées sur AWS, sur site ou chez d'autres fournisseurs cloud. L'équilibrage de charge peut se faire vers n'importe quelle adresse IP ou interface sur les serveurs d'arrière-plan.

Les adresses IP peuvent être utilisées comme cibles pour les applications d'équilibrage de charge hébergées sur site (via Direct Connect ou VPN), les VPC appairés et EC2-Classic (via ClassicLink). Cela permet une migration flexible vers le cloud et l'équilibrage de charge entre ressources sur site et ressources AWS.

Les fonctions Lambda comme cibles

Les utilisateurs peuvent accéder à des applications serverless depuis n'importe quel client HTTP, y compris les navigateurs web, grâce à la prise en charge de l'exécution des fonctions Lambda par les ALB. Vous pouvez utiliser des règles de routage basées sur le contenu pour diriger les requêtes vers différentes fonctions Lambda, celles-ci étant enregistrées comme cibles du répartiteur de charge.

Un répartiteur de charge applicatif peut être utilisé comme point de terminaison HTTP standard pour les applications utilisant des serveurs traditionnels ou une architecture serverless. Vous pouvez utiliser les fonctions Lambda pour créer un site web complet ou les combiner avec des instances EC2, des conteneurs et des serveurs sur site.

Routage basé sur le contenu

Si votre application est composée de plusieurs services indépendants, un ALB peut acheminer une requête vers un service spécifique en fonction de son contenu : champ hôte, URL du chemin, en-tête HTTP, méthode HTTP, chaîne de requête ou adresse IP source.

Routage basé sur l'hôte : l'ALB peut utiliser le champ Hôte de l'en-tête HTTP pour diriger les requêtes vers différents domaines à partir d'un même répartiteur de charge.

Routage basé sur le chemin : le chemin d'URL de l'en-tête HTTP peut servir à acheminer une requête.

Routage basé sur l'en-tête HTTP : l'ALB peut router une requête en fonction de n'importe quelle valeur d'en-tête HTTP, qu'il soit standard ou personnalisé.

Routage basé sur la méthode HTTP : toute méthode HTTP standard ou personnalisée peut être utilisée pour router une requête.

Routage basé sur les paramètres de la chaîne de requête : une requête peut être routée en fonction des paramètres de la chaîne de requête.

Routage basé sur le CIDR de l'adresse IP source : la requête peut être dirigée en fonction de son adresse IP source.

Prise en charge des applications conteneurisées

L'ALB améliore la prise en charge des conteneurs en répartissant la charge sur plusieurs ports d'une même instance Amazon EC2 (mappage de port dynamique). Dans la définition de tâche ECS, vous pouvez spécifier un port dynamique, ce qui permet d'attribuer un port inutilisé au conteneur lors de sa planification sur l'instance EC2. Le planificateur ECS utilise ce port pour ajouter la tâche au répartiteur de charge.

ALB avec pare-feu d'application Web

Avec AWS WAF, vous pouvez protéger vos applications web sur vos répartiteurs de charge applicatifs. AWS WAF protège vos applications contre les exploits courants qui peuvent causer des interruptions de service, compromettre la sécurité ou consommer des ressources excessives.

Mode de démarrage lent avec algorithme d'équilibrage de charge

L'ALB prend en charge l'algorithme d'équilibrage de charge circulaire. En outre, le mécanisme de tourniquet de l'ALB inclut un mode de démarrage lent qui permet d'ajouter de nouvelles cibles sans les surcharger immédiatement avec des requêtes. Le démarrage lent permet aux cibles de "s'échauffer" avant de recevoir leur juste part de requêtes. Il est particulièrement utile pour les applications qui utilisent le cache et qui nécessitent une période de préparation avant de pouvoir répondre de manière optimale aux requêtes.

Authentification de l'utilisateur

Vous pouvez utiliser un répartiteur de charge applicatif pour externaliser le mécanisme d'authentification de vos applications. L'ALB authentifie les utilisateurs lorsqu'ils accèdent à des applications cloud. L'authentification peut se faire via des fournisseurs d'identité tels que Google, Facebook ou Amazon, ou via des fournisseurs d'identité d'entreprise comme Microsoft Active Directory via SAML, ou encore tout fournisseur d'identité compatible OpenID Connect, grâce à l'intégration transparente de l'ALB avec Amazon Cognito.

L'ALB peut également authentifier les utilisateurs d'entreprise en se connectant directement à votre fournisseur d'identité si vous disposez déjà d'une solution IdP personnalisée compatible avec OpenID Connect.

Avantages du passage d'un équilibreur de charge classique (CLB) à un équilibreur de charge applicatif (ALB)

Les équilibreurs de charge classiques (CLB) étaient le premier type d'équilibreurs de charge d'AWS. Bien qu'efficaces, ils sont lentement devenus obsolètes avec l'introduction des ALB et des NLB. De nombreuses fonctionnalités désormais prises en charge par les nouvelles versions ne sont pas présentes dans les CLB.

Prise en charge des conditions de chemin : vous pouvez configurer votre écouteur avec des règles qui transfèrent les demandes en fonction de l'URL de la demande. Cela vous permet de décomposer votre application en microservices et d'acheminer les requêtes vers le service approprié en fonction de l'URL.
Prise en charge des conditions d'hôte : vous pouvez configurer votre écouteur avec des règles qui transfèrent les demandes en fonction du champ d'hôte dans l'en-tête HTTP. Cela vous permet de gérer plusieurs domaines via un seul répartiteur.
Le routage est possible en fonction de divers éléments des requêtes : conditions et méthodes d'en-tête HTTP, paramètres de requête et adresses IP source.
Il est possible de rediriger les requêtes vers de multiples applications sur un seul serveur EC2.
Une instance ou une adresse IP peut être enregistrée auprès de nombreux groupes cibles sur un port distinct.
Vous pouvez rediriger les requêtes d'une URL vers une autre.
Il est possible de renvoyer une réponse HTTP personnalisée.
Prise en charge de l'enregistrement de cibles par adresse IP, y compris celles situées en dehors du VPC.
Les fonctions Lambda peuvent être enregistrées comme cibles.
Le répartiteur peut authentifier les utilisateurs de vos applications en utilisant leur identité d'entreprise ou sociale avant d'acheminer les requêtes.
Les applications conteneurisées sont prises en charge. Lors de la planification d'une tâche, Amazon Elastic Container Service (ECS) peut choisir un port inutilisé et l'utiliser pour enregistrer la tâche auprès d'un groupe cible. Cela permet d'optimiser l'utilisation de vos clusters.
Les contrôles d'état sont définis au niveau du groupe cible, ce qui permet de surveiller la santé de chaque service individuellement. Lorsque vous ajoutez un groupe cible à un groupe Auto Scaling, vous pouvez mettre à l'échelle dynamiquement chaque service en fonction de la demande.
Des informations supplémentaires sont enregistrées au format compressé dans les journaux d'accès.

Derniers mots

Les répartiteurs de charge applicatifs sont des outils de nouvelle génération, élastiques, évolutifs et dotés de nombreuses fonctionnalités, particulièrement adaptées aux applications web. Les équilibreurs de charge classiques sont toujours utiles pour les applications anciennes hébergées sur EC2 Classic, mais pour les charges de travail modernes, les ALB sont le choix le plus judicieux.