PERF04-BP04 Utilisation de l'équilibrage de charge pour répartir le trafic entre plusieurs ressources - AWS Well-Architected Framework

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 votre application dans une seule zone de disponibilité 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 d'exposition au risque si cette bonne pratique n'est pas respectée : É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. L'Application Load Balancer est davantage adapté à l'équilibrage de charge du trafic HTTP et HTTPS et fournit un routage avancé des requêtes, axé sur la diffusion d'architectures d'application modernes, notamment de microservices et de conteneurs.

Le Network Load Balancer est tout indiqué 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 (l'ALB en tant que cible du NLB) si vous souhaitez tirer parti des fonctionnalités des deux produits. Par exemple, vous pouvez le faire si vous voulez utiliser les IP statiques du NLB avec le routage basé sur l'en-tête HTTP de l'ALB, ou si vous voulez exposer votre charge de travail HTTP à un AWS PrivateLink.

    • Pour une comparaison complète des équilibreurs de charge, voir 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, l'ALB fournit deux options pour les algorithmes de routage :

    • Demandes les moins en attente : permet d'obtenir une meilleure répartition de la charge sur vos cibles backend dans les cas où les requêtes de votre application varient en complexité ou vos cibles varient en capacité de traitement.

    • Tourniquet : utilisez cette méthode lorsque les requêtes et les cibles sont similaires, ou si vous devez distribuer les requêtes 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 procédure à suivre pour Apache et Nginx, voir 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 l'Application Load Balancer et le Network Load Balancer.

    • Les principaux champs à prendre en compte pour l'ALB sont les suivants : request_processing_timerequest_processing_timeet response_processing_time. »

    • Les principaux champs à prendre en compte pour le NLB sont les suivants : connection_time et tls_handshake_time. »

    • Soyez prêt à interroger les journaux lorsque vous en aurez besoin. Vous pouvez utiliser Amazon Athena pour interroger à la fois 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 :