PERF04-BP04 Utilisation de l’équilibrage de charge pour répartir le trafic entre plusieurs ressources - AWS Well-Architected Framework
Directives d’implémentationRessources

PERF04-BP04 Utilisation de l’équilibrage de charge pour répartir le trafic entre plusieurs ressources

Répartissez le trafic sur plusieurs ressources ou services pour permettre à votre charge de travail de tirer parti de l’élasticité fournie par le cloud. Vous pouvez également utiliser l’équilibrage de charge afin de décharger la terminaison du chiffrement en vue d’améliorer les performances, d’assurer la fiabilité et de gérer et acheminer efficacement le trafic.

Anti-modèles courants :

  • Vous ne tenez pas compte des exigences de votre charge de travail lorsque vous choisissez le type d’équilibreur de charge.

  • Vous ne tirez pas parti des fonctions d’équilibrage de charge pour optimiser les performances.

  • La charge de travail est exposée directement à Internet sans équilibreur de charge.

  • Vous acheminez tout le trafic Internet via des équilibreurs de charge existants.

  • Vous utilisez l’équilibrage de charge TCP générique et faites en sorte que chaque nœud de calcul gère le chiffrement SSL.

Avantages liés au respect de cette bonne pratique : un équilibreur de charge gère la charge variable du trafic de vos applications dans une zone de disponibilité unique ou entre plusieurs zones de disponibilité et permet une haute disponibilité, une mise à l’échelle automatique et une meilleure utilisation de votre charge de travail.

Niveau de risque exposé si cette bonne pratique n’est pas établie : élevé

Directives d’implémentation

Les équilibreurs de charge constituent le point d’entrée de votre charge de travail, à partir duquel ils distribuent le trafic vers vos cibles principales, telles que les instances de calcul ou les conteneurs, afin d’améliorer l’utilisation.

Le choix du bon type d’équilibreur de charge est la première étape de l’optimisation de votre architecture. Commencez par énumérer les caractéristiques de votre charge de travail, telles que le protocole (TCP, HTTP, TLS ou WebSockets), le type de cible (instances, conteneurs ou sans serveur), les exigences de l’application (connexions de longue durée, authentification de l’utilisateur ou permanence) et le placement (région, zone locale, Outpost ou isolement de zone).

AWS fournit plusieurs modèles permettant à vos applications d’utiliser l’équilibrage de charge. Application Load Balancer convient parfaitement pour l’équilibrage de charge du trafic HTTP et HTTPS, et fournit un routage avancé des demandes, axé sur la diffusion d’architectures d’application modernes, notamment de microservices et de conteneurs.

Network Load Balancer convient parfaitement pour l’équilibrage de charge du trafic TCP, qui nécessite des performances extrêmes. Il est capable de traiter des millions de requêtes par seconde tout en maintenant de très faibles latences. Il est optimisé pour gérer les tendances soudaines et instables du trafic.

Elastic Load Balancing assure la gestion intégrée des certificats et le déchiffrement SSL/TLS, ce qui vous permet de gérer de façon centralisée les paramètres SSL de l’équilibreur de charge et de décharger les tâches gourmandes en CPU de votre charge de travail.

Après avoir choisi le bon équilibreur de charge, vous pouvez commencer à tirer parti de ses fonctionnalités pour réduire les efforts que votre système backend doit fournir pour servir le trafic.

Par exemple, en utilisant à la fois Application Load Balancer (ALB) et Network Load Balancer (NLB), vous pouvez effectuer un déchargement du chiffrement SSL/TLS. Cela permet d’éviter que la liaison TLS, très gourmande en ressources CPU, ne soit effectuée par vos cibles, et permet également d’améliorer la gestion des certificats.

Lorsque vous configurez le déchargement SSL/TLS dans votre équilibreur de charge, celui-ci se charge du chiffrement du trafic en provenance et à destination des clients, tout en acheminant le trafic non chiffré vers vos systèmes backend. Cela libère vos ressources backend et améliore le temps de réponse pour les clients.

Application Load Balancer peut également servir le trafic HTTP/2 sans avoir besoin de le prendre en charge sur vos cibles. Cette simple décision peut améliorer le temps de réponse de votre application, car HTTP/2 utilise plus efficacement les connexions TCP.

Les exigences de latence de votre charge de travail doivent être prises en compte lors de la définition de l’architecture. Par exemple, si vous avez une application sensible à la latence, vous pouvez décider d’utiliser Network Load Balancer, qui offre des latences extrêmement faibles. Vous pouvez également décider de rapprocher votre charge de travail de vos clients en tirant parti d’Application Load Balancer dans les zones locales AWS ou même AWS Outposts.

L’équilibrage de charge entre zones est un autre élément à prendre en compte pour les charges de travail sensibles à la latence. Avec l’équilibrage de charge inter-zone, chaque nœud d’équilibreur de charge distribue le trafic sur les cibles enregistrées dans toutes les zones de disponibilité activées.

Intégrez Auto Scaling à votre équilibreur de charge. L’un des aspects essentiels d’un système performant est le dimensionnement adéquat de vos ressources backend. Pour ce faire, vous pouvez tirer parti des intégrations d’équilibreurs de charge pour les ressources cibles du système backend. Grâce à l’intégration de l’équilibreur de charge avec les groupes Auto Scaling, les cibles seront ajoutées ou retirées de l’équilibreur de charge selon les besoins en fonction du trafic entrant. Les équilibreurs de charge peuvent également s’intégrer à Amazon ECS et Amazon EKS pour les charges de travail conteneurisées.

Étapes d’implémentation

  • Définissez vos exigences en matière d’équilibrage de charge, notamment en termes de volume de trafic, de disponibilité et de capacité de mise à l’échelle des applications.

  • Choisissez le type d’équilibreur de charge adapté à votre application.

    • Utilisez Application Load Balancer pour les charges de travail HTTP/HTTPS.

    • Utilisez Network Load Balancer pour les charges de travail non HTTP qui fonctionnent sur TCP ou UDP.

    • Utilisez une combinaison des deux (ALB comme cible de NLB) si vous souhaitez tirer parti des fonctionnalités des deux produits. Par exemple, vous pouvez le faire si vous voulez utiliser les adresses IP statiques de NLB avec le routage basé sur l’en-tête HTTP d’ALB, ou si vous voulez exposer votre charge de travail HTTP à AWS PrivateLink.

    • Pour une comparaison complète des équilibreurs de charge, consultez Comparaison des produits ELB.

  • Utilisez le déchargement SSL/TLS si possible.

  • Sélectionnez le bon algorithme de routage (ALB uniquement).

    • L’algorithme de routage peut faire une réelle différence dans la manière d’utiliser vos cibles backend et donc dans leur impact sur les performances. Par exemple, ALB propose deux options pour les algorithmes de routage :

    • Demandes les moins en attente : permet de mieux répartir la charge sur vos cibles backend lorsque les demandes de votre application varient en complexité ou que vos cibles ont des capacités de traitement différentes.

    • Tourniquet : utilisez cette méthode lorsque les demandes et les cibles sont similaires, ou si vous devez distribuer les demandes de manière égale entre les cibles.

  • Envisagez un isolement inter-zone ou par zone.

  • Activez l’option de persistance HTTP pour vos charges de travail HTTP (ALB uniquement). Grâce à cette fonction, l’équilibreur de charge peut réutiliser les connexions backend jusqu’à l’expiration du délai de persistance, ce qui améliore les temps de demande et de réponse HTTP et réduit également l’utilisation des ressources sur vos cibles backend. Pour plus de détails sur la façon de procéder pour Apache et Nginx, consultez Quels sont les paramètres optimaux pour utiliser Apache ou NGINX en tant que serveur principal pour ELB ?

  • Activez la surveillance pour votre équilibreur de charge.

    • Activez les journaux d’accès pour vos Application Load Balancer et Network Load Balancer.

    • Les principaux champs à prendre en compte pour ALB sont request_processing_time, request_processing_time et response_processing_time.

    • Les principaux champs à prendre en compte pour NLB sont connection_time et tls_handshake_time.

    • Soyez prêt à interroger les journaux lorsque vous en aurez besoin. Vous pouvez utiliser Amazon Athena pour interroger les journaux ALB et les journaux NLB.

    • Créez des alarmes pour les métriques liées aux performances, telles que TargetResponseTime pour ALB.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :