Les équilibreurs de charge d’application assurent intelligemment l’évolutivité, les performances et la disponibilité. Ils garantissent également que vos serveurs ne sont pas surchargés et qu’ils sont prêts à gérer les pics de trafic.
L’infrastructure de sécurité de toute équipe informatique s’articule autour des équilibreurs de charge. Ces derniers veillent à ce que votre application puisse gérer le trafic entrant. Dans cet article, nous examinerons plus en détail l’équilibreur de charge d’application sur AWS.
Qu’est-ce qu’un équilibreur de charge d’application ?
L’Application Load Balancer, ou ALB, est un Elastic Load Balancer ou ELB sur AWS. Il opère au niveau de la couche application (la septième couche) du modèle OSI (Open Systems Interconnection).
Les ALB ont trois composants : les auditeurs, l’équilibreur de charge et le groupe cible. Après avoir reçu une demande, l’équilibreur de charge évalue les règles de l’auditeur par ordre de priorité (pour choisir la règle à exécuter). Il sélectionne ensuite une cible dans le groupe de cibles pour l’action de la règle.
Vous pouvez configurer des règles d’écoute pour envoyer des requêtes à différents groupes cibles en fonction du contenu du trafic de l’application. L’algorithme de routage par défaut pour les ALB est Round-robin ; toutefois, vous pouvez choisir la technique de routage des demandes les moins en suspens.
Au fur et à mesure que vos besoins évoluent, vous pouvez supprimer et ajouter des cibles à votre équilibreur de charge sans interrompre le flux général de requêtes de votre application.
L’Elastic Load Bal ancing (ELB) vous permet d’adapter votre équilibreur de charge en fonction de l’évolution du trafic de votre application. Tous les équilibreurs de charge élastiques peuvent s’adapter automatiquement à la grande majorité des charges de travail.
Vous pouvez également mettre en place des contrôles de santé pour surveiller l’état de votre application sur les cibles enregistrées afin que l’équilibreur de charge n’envoie des requêtes qu’aux cibles saines.
Caractéristiques des équilibreurs de charge d’application
Équilibrage de charge de couche 7
En fonction des attributs de la demande, vous pouvez équilibrer la charge du trafic HTTP/HTTPS et gRPC vers des instances Amazon EC2, des conteneurs ECS, AWS Lambda, des serveurs tiers ou sur site.
Fonctionnalités de sécurité
ALB prend en charge les sauvegardes de désynchronisation basées sur la bibliothèque HTTP desync-guardian. Cette fonctionnalité protège les applications des clients contre les vulnérabilités HTTP causées par Desync sans sacrifier la disponibilité ou la latence. Les clients peuvent également définir leur niveau de tolérance pour les requêtes douteuses en fonction de l’architecture de leurs applications.
Support Outposts
AWS Outposts est une solution entièrement gérée qui étend l’infrastructure, les services et les outils AWS à presque tous les centres de données, espaces de colocation ou installations sur site pour une expérience hybride vraiment cohérente. Vous pouvez utiliser des équilibreurs de charge d’application avec AWS Outposts. Les clients peuvent déployer des ALB sur les types d’instance pris en charge, et l’ALB s’adaptera automatiquement à la capacité du rack pour répondre aux différents niveaux de charge de travail des applications sans nécessiter d’intervention manuelle.
Vous pouvez également configurer l’ALB pour qu’il reçoive des rappels/alertes afin de l’aider à gérer ses besoins en capacité d’équilibrage de charge. Les clients peuvent utiliser la même console AWS, le même CLI et les mêmes API pour provisionner et gérer les ALB sur les avant-postes que pour provisionner et gérer les ALB dans les régions AWS.
Terminaison HTTPS
Un Application Load Balancer (ALB) prend en charge la terminaison HTTPS entre les clients et l’équilibreur de charge. Cela signifie que la connexion entre votre client et l’ALB est HTTPS, mais que la connexion entre l’ALB et les serveurs d’application (EC2, ECS, etc.) est HTTP.
Comme la connexion entre l’ALB et les serveurs d’application se trouve à l’intérieur de votre VPC, elle est protégée par défaut par des entités externes. Les ALB peuvent gérer des certificats SSL en utilisant AWS Certificate Manager pour des politiques de sécurité prédéfinies et AWS Identity and Access Management (IAM).
Prise en charge de HTTP/2 et gRPC
HTTP/2 est une nouvelle forme de protocole de transfert d’hypertexte (HTTP) qui permet de transmettre de nombreuses requêtes sur la même connexion en utilisant une seule connexion multiplexée. Il fournit également des connexions SSL aux clients et compresse les données d’en-tête avant de les envoyer au format binaire.
le trafic gRPC peut être acheminé et équilibré entre les microservices ou entre les clients et les services compatibles gRPC à l’aide de l’équilibreur de charge d’application. Cela permet d’intégrer en douceur la gestion du trafic gRPC dans les architectures sans qu’il soit nécessaire de modifier l’infrastructure sous-jacente du côté des clients ou des services.
gRPC est le protocole de choix pour les communications inter-services dans les architectures microservices, et il utilise HTTP/2 pour la transmission. Il présente des caractéristiques telles qu’une sérialisation binaire efficace, la prise en charge d’un grand nombre de langues, ainsi que les avantages inhérents à HTTP/2, tels que la réduction de l’empreinte réseau, la compression et le flux bidirectionnel, ce qui le rend supérieur aux protocoles hérités tels que REST.
Sessions collantes
Les sessions collantes permettent aux demandes d’un même client d’être acheminées vers la même cible à l’aide de cookies. Nous pouvons facilement mettre en place des sessions collantes en activant simplement les sessions collantes et les cookies dans les attributs de l’ALB. L’Application Load Balancer (ALB) supporte à la fois les cookies basés sur la durée et les cookies basés sur l’application.
Déterminer la durée pendant laquelle votre équilibreur de charge doit constamment envoyer la requête de l’utilisateur à la même cible est la clé de la gestion des sessions collantes. Les sessions collantes sont activées au niveau du groupe cible. Vous pouvez déployer une combinaison de sessions collantes basées sur la durée, de sessions collantes basées sur l’application et d’absence de sessions collantes dans différents groupes cibles.
Prise en charge de l’IPv6 natif
Le protocole Internet natif version 6 (IPv6) est pris en charge par les équilibreurs de charge d’application dans un VPC. Cela permet aux clients de se connecter à l’Application Load Balancer en utilisant IPv4 ou IPv6.
Traçage des requêtes
Pour toutes les requêtes entrant dans l’équilibreur de charge, l’Application Load Balancer injecte un nouvel identifiant personnalisé “X-Amzn-Trace-Id” dans l’en-tête HTTP. Le traçage des requêtes vous permet de suivre la progression d’une requête au fur et à mesure qu’elle est envoyée à de nombreux services AWS en utilisant son identifiant unique. Vous pouvez utiliser le traçage des requêtes pour trouver des problèmes de performance ou de goulot d’étranglement dans votre pile d’applications.
Redirections
L’Application Load Balancer (ALB) peut rediriger une requête entrante d’une URL vers une autre. Par exemple, vous pouvez rediriger des requêtes HTTP vers des requêtes HTTPS, ce qui vous permet d’atteindre votre objectif de conformité en matière de navigation sécurisée tout en améliorant le classement de votre site dans les moteurs de recherche et le score SSL/TLS. Les redirections peuvent également diriger les utilisateurs vers un site web différent, par exemple une ancienne version d’une application vers une version plus récente.
Réponse fixe
L’Application Load Balancer peut gérer les demandes des clients que vos applications servent. Sans transmettre la requête à l’application, vous pouvez répondre aux requêtes entrantes avec des codes de réponse d’erreur HTTP et des messages d’erreur personnalisés directement à partir de l’équilibreur de charge.
Prise en charge des WebSockets
Les équilibreurs de charge d’applications prennent en charge les WebSockets. Les WebSockets permettent à un serveur d’envoyer des messages en temps réel aux utilisateurs finaux sans qu’ils aient à demander (ou à interroger) une mise à jour du serveur. Sur une connexion TCP de longue durée, le protocole WebSockets permet des canaux de communication bidirectionnels entre un client et un serveur.
Indication du nom du serveur (SNI)
SNI (Server Name Indication) est une extension du protocole TLS dans laquelle un client spécifie le nom d’hôte auquel se connecter dans la poignée de main TLS. L’équilibreur de charge peut présenter de nombreux certificats via un seul auditeur sécurisé, ce qui lui permet de prendre en charge plusieurs sites web sécurisés avec un seul auditeur sécurisé.
Avec SNI, les répartiteurs de charge d’application utilisent un processus intelligent de sélection des certificats pour faire correspondre le nom d’hôte de la demande au certificat SSL correspondant. Si le nom d’hôte d’un client correspond à plusieurs certificats, l’équilibreur de charge choisit le certificat optimal en fonction de plusieurs paramètres, dont les capacités du client.
Adresses IP comme cibles
En utilisant les adresses IP des backends des applications comme cibles, vous pouvez utiliser les ALB pour équilibrer la charge de n’importe quelle application hébergée sur AWS, sur site ou même chez d’autres fournisseurs de cloud. Cela permet d’équilibrer la charge vers n’importe quelle adresse IP et interface d’un backend d’application.
Lesadresses IP peuvent également être utilisées comme cibles pour l’équilibrage de charge des applications hébergées sur site (via Direct Connect ou VPN), des VPC en peering et EC2-Classic (à l’aide de ClassicLink). Vous pouvez migrer vers le cloud, faire du burst vers le cloud ou basculer vers le cloud avec la possibilité d’équilibrer la charge entre les ressources sur site et AWS.
Fonctions Lambda en tant que cibles
Les utilisateurs peuvent accéder aux apps sans serveur depuis n’importe quel client HTTP, y compris les navigateurs web, grâce à la prise en charge par les équilibreurs de charge d’applications de l’exécution des fonctions Lambda pour délivrer des requêtes HTTP(S). Vous pouvez utiliser la prise en charge des règles de routage basées sur le contenu pour diriger les demandes vers des fonctions Lambda distinctes en enregistrant les fonctions Lambda en tant que cibles de l’équilibreur de charge.
Un équilibreur de charge d’application peut être utilisé comme point de terminaison HTTP standard pour les apps qui exploitent les serveurs et l’informatique sans serveur. Pour développer des applications, vous pouvez utiliser des fonctions Lambda pour créer un site web entier ou les combiner avec des instances EC2, des conteneurs et des serveurs sur site.
Routage basé sur le contenu
Supposons que votre application soit composée de nombreux services indépendants. Dans ce cas, un équilibreur de charge applicatif peut acheminer une requête vers un service en fonction du contenu de la requête, comme le champ Host, l’URL du chemin, l’en-tête HTTP, la méthode HTTP, la chaîne de requête ou l’adresse IP source.
Routage basé sur l’hôte : En utilisant le champ Host de l’en-tête HTTP, l’ALB peut acheminer une requête client vers plusieurs domaines à partir du même équilibreur de charge.
Routage basé sur le chemin : Le chemin URL de l’en-tête HTTP peut être utilisé pour acheminer une requête client.
Routage basé sur l’en-tête HTTP : Toute valeur d’en-tête HTTP standard ou personnalisée peut être utilisée pour acheminer une requête client.
Routage basé sur la méthode HTTP : Toute méthode HTTP standard ou personnalisée peut être utilisée pour rediriger une requête client.
Routage basé sur les paramètres de la chaîne de requête : Une demande de client peut être acheminée en fonction de la chaîne de requête ou des paramètres.
Routage basé sur l’adresse IP source CIDR : Une demande de client peut être acheminée en fonction de l’adresse IP source CIDR d’où elle provient.
Prise en charge des applications conteneurisées
Application Load Balancer améliore la prise en charge des conteneurs en répartissant la charge sur plusieurs ports d’une même instance Amazon EC2(mappage dynamique des ports). Dans la définition de la tâche ECS, vous pouvez spécifier un port dynamique, ce qui donne au conteneur un port inutilisé lorsqu’il est planifié sur l’instance EC2. Ce port est utilisé par le planificateur ECS pour ajouter la tâche à l’équilibreur de charge.
ALB avec Web Application Firewall
Grâce à AWS WAF, vous pouvez désormais protéger vos applications web sur vos équilibreurs de charge. AWS WAF protège vos applications web contre les exploits typiques du web qui peuvent causer des temps d’arrêt de l’application, compromettre la sécurité ou consommer des ressources excessives.
Mode de démarrage lent avec algorithme d’équilibrage de charge
L’Application Load Balancer (ALB) prend en charge un algorithme d’équilibrage de charge round-robin. En outre, le mécanisme round-robin de l’Application Load Balancer comprend un mode de démarrage différé qui vous permet d’ajouter de nouvelles cibles sans les surcharger de demandes. L’option de démarrage lent permet aux cibles de s’échauffer avant de recevoir leur juste part de requêtes pendant une période de montée en puissance spécifiée. Le démarrage lent est utile pour les applications qui reposent sur le cache et qui ont besoin d’une période d’échauffement avant de pouvoir réagir au mieux aux requêtes.
Authentification des utilisateurs
Vous pouvez utiliser l’Application Load Balancer pour décharger le mécanisme d’authentification de vos applications. Lorsque les utilisateurs accèdent aux applications en nuage, l’Application Load Balancer les authentifie. Les utilisateurs finaux peuvent s’authentifier via des fournisseurs d’identité sociale comme Google, Facebook et Amazon, ainsi que des fournisseurs d’identité d’entreprise comme Microsoft Active Directory via SAML ou tout fournisseur d’identité compatible avec OpenID Connect, grâce à l’intégration transparente d’Application Load Balancer avec Amazon Cognito.
Application Load Balancer peut également vérifier les utilisateurs de l’entreprise en se connectant directement à votre fournisseur d’identité si vous disposez déjà d’une solution IdP sur mesure 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 ont été le premier type d’équilibreurs de charge d’AWS. Bien que puissants, avec l’introduction des ALB et des NLB, les Load Balancers classiques deviennent peu à peu obsolètes. De nombreuses fonctionnalités désormais prises en charge par les versions plus récentes des équilibreurs de charge ne sont pas présentes dans l’équilibreur de charge classique.
- Prise en charge des conditions de chemin d’accès : Vous pouvez configurer votre auditeur avec des règles qui transfèrent les demandes en fonction de l’URL dans la demande. Cela vous permet de décomposer votre application en petits services (microservices) et d’acheminer les demandes vers le service approprié en fonction du contenu de l’URL.
- Prise en charge des conditions d’hébergement : Vous pouvez configurer votre listener avec des règles qui transfèrent les requêtes en fonction du champ host dans l’en-tête HTTP. Cela vous permet d’acheminer des demandes vers de nombreux domaines à l’aide d’un seul équilibreur de charge.
- Le routage est pris en charge sur la base d’informations de requête telles que les conditions et méthodes de l’en-tête HTTP, les paramètres de la requête et les adresses IP source.
- Vous pouvez envoyer des demandes de routage à de nombreuses applications sur un seul serveur EC2.
- Une instance ou une adresse IP peut être enregistrée auprès de plusieurs 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 des cibles pour l’équilibreur de charge par adresse IP, y compris les cibles en dehors du VPC.
- Les fonctions Lambda peuvent être enregistrées en tant que cibles.
- Avant de router les requêtes, l’équilibreur de charge peut authentifier les utilisateurs de vos applications à l’aide de leur identité d’entreprise ou sociale.
- Les applications conteneurisées sont prises en charge. Lors de la planification d’une tâche, Amazon Elastic Container Service (Amazon ECS) peut choisir un port inutilisé et l’utiliser pour enregistrer la tâche auprès d’un groupe cible. Cela vous permet de tirer le meilleur parti de vos clusters.
- Comme les contrôles de santé sont définis au niveau du groupe cible et que les mesures CloudWatch sont publiées au niveau du groupe cible, il est possible de surveiller la santé de chaque service individuellement. Lorsque vous ajoutez un groupe cible à un groupe de mise à l’échelle automatique, 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.
Quelques mots pour conclure
Les équilibreurs de charge applicatifs sont des équilibreurs de charge de nouvelle génération, élastiques, évolutifs et dotés de nombreuses fonctionnalités, en particulier pour les besoins des applications web. Vous devrez peut-être utiliser des équilibreurs de charge classiques si vous avez des applications anciennes hébergées sur le réseau EC2 classique, mais pour toutes les charges de travail de nouvelle génération, les ALB seront un choix évident.