En août 2016, Amazon Web Services (AWS) a lancé Application Load Balancer pour l’équilibrage de charge de couche 7 du trafic HTTP et HTTPS. Ce nouveau produit apportait plusieurs fonctionnalités qui faisaient défaut à Elastic Load Balancer, l’équilibreur de charge de couches 4 et 7 existant d’AWS, officiellement rebaptisé Classic Load Balancer.
Un an plus tard, AWS a lancé Network Load Balancer afin d’améliorer la répartition de charge de couche 4. Les utilisateurs qui exécutent des applications hautement disponibles et évolutives sur AWS disposent donc des options suivantes :
- NGINX Open Source et NGINX Plus
- Équilibreur de charge classique
- Équilibreur de charge d’application (ALB)
- Équilibreur de charge réseau (NLB)
Dans cet article, nous passons en revue les fonctionnalités d’ALB et comparons ses tarifs et ses fonctionnalités à ceux de NGINX Open Source et de NGINX Plus.
Remarques –
Les informations sur les fonctionnalités prises en charge sont exactes en date de juillet 2020, mais sont susceptibles d’être modifiées. Pour une comparaison directe entre NGINX Plus et Classic Load Balancer (anciennement Elastic Load Balancer ou ELB), ainsi que des informations sur leur utilisation conjointe, consultez notre précédent article de blog. Pour en savoir plus sur l’utilisation de NLB dans le cadre d’un déploiement NGINX Plus à haute disponibilité, consultez notre précédent article de blog.
Fonctionnalités de l'Application Load Balancer
ALB, tout comme Classic Load Balancer ou NLB, est étroitement intégré à AWS. Amazon le décrit comme un équilibreur de charge de couche 7, bien qu’il n’offre pas toute l’étendue des fonctionnalités, des possibilités de réglage et du contrôle direct que peut proposer un proxy inverse et équilibreur de charge de couche 7 autonome.
ALB fournit les fonctionnalités suivantes, qui ne sont pas disponibles dans Classic Load Balancer :
- Routage basé sur le contenu. L’ALB prend en charge le routage basé sur le contenu en fonction de l’URL de la requête, de l’en-tête
Host, ainsi que des champs de la requête, notamment les en-têtes HTTP standard et personnalisés, les méthodes HTTP, les paramètres de requête et l’adresse IP source. (Consultez la section « Avantages de la migration depuis un Classic Load Balancer » dans la documentation de l’ALB.) - Prise en charge des applications basées sur des conteneurs. ALB améliore la prise en charge existante des conteneurs hébergés sur Amazon EC2 Container Service (ECS).
- Davantage de métriques. Vous pouvez collecter des métriques pour chaque microservice.
- Prise en charge de WebSocket. ALB prend en charge les connexions TCP persistantes entre un client et un serveur.
- Prise en charge de HTTP/2. ALB prend en charge HTTP/2, une solution plus performante pour diffuser du contenu sécurisé par SSL/TLS.
(Pour une comparaison complète des fonctionnalités d’ALB et de Classic Load Balancer, consultez la section « Comparaisons de produits » dans la documentation AWS.)
ALB a constitué une évolution majeure pour les utilisateurs d’AWS confrontés aux fonctionnalités limitées de Classic Load Balancer, et a permis de répondre en partie aux besoins des utilisateurs avancés qui doivent pouvoir sécuriser, optimiser et contrôler le trafic vers leurs applications web. Toutefois, il n’offre toujours pas toutes les fonctionnalités des proxys inverses dédiés (tels que NGINX) et des équilibreurs de charge (tels que NGINX Plus).
Une meilleure approche pour contrôler le trafic sur AWS
Au lieu d’utiliser Amazon ALB, les utilisateurs peuvent déployer NGINX Open Source ou NGINX Plus sur AWS afin de contrôler et de répartir la charge du trafic. Ils peuvent également déployer Classic Load Balancer ou Network Load Balancer en frontal afin d’assurer une haute disponibilité sur plusieurs zones de disponibilité. Le tableau compare les fonctionnalités prises en charge par ALB, NGINX et NGINX Plus.
Remarque : Les informations figurant dans le tableau suivant sont exactes en date de juillet 2020, mais sont susceptibles d’être modifiées.
| Amazon ALB | NGINX Open Source | NGINX Plus | |
|---|---|---|---|
| Méthodes et fonctionnalités d’équilibrage de charge | Méthodes Round_robin et least_outstanding_requests, avec persistance de session basée sur les cookies, groupes cibles pondérés et démarrage progressif | Plusieurs méthodes d’équilibrage de charge (notamment Round Robin, Least Connections, Hash, IP Hash et Random) avec des serveurs en amont pondérés | Fonctionnalités identiques à celles de NGINX Open Source, auxquelles s’ajoutent la méthode Least Time, davantage de méthodes de persistance de session et le démarrage progressif |
| Mise en cache | ❌ Mise en cache non prise en charge dans l’équilibreur de charge | ✅ Mise en cache des fichiers statiques et mise en cache dynamique (des applications) | ✅ Mise en cache statique et dynamique, ainsi que des fonctionnalités avancées |
| Contrôles d’intégrité | Actifs (détectent les serveurs défaillants en vérifiant le code d’état renvoyé lors des contrôles asynchrones) | Passifs (détectent les serveurs défaillants en vérifiant les réponses aux requêtes des clients) | Actifs et passifs – les contrôles actifs sont plus complets et plus configurables que ceux d’ALB |
| Haute disponibilité | Vous pouvez déployer des instances ALB dans plusieurs zones de disponibilité pour assurer la haute disponibilité, mais pas dans plusieurs régions | Haute disponibilité active-active avec NLB et haute disponibilité active-passive avec des adresses IP Elastic | Fonctionnalités identiques à celles de NGINX Open Source, auxquelles s’ajoute le partage intégré de l’état du cluster pour une haute disponibilité transparente entre toutes les instances NGINX Plus |
| Prise en charge de tous les protocoles de la suite IP | ❌ HTTP et HTTPS uniquement | ✅ Également TCP et UDP, avec des contrôles d’intégrité passifs | ✅ Également TCP et UDP, avec des contrôles d’intégrité actifs et passifs |
| Plusieurs applications par instance d’équilibreur de charge | ✅ | ✅ | |
| Routage basé sur le contenu | ✅ Basé sur l’URL de la requête, l’en-tête Host et les champs de la requête, notamment les en-têtes HTTP standard et personnalisés, les méthodes, les paramètres de requête et l’adresse IP source | ✅ Basé sur les mêmes facteurs qu’ALB, ainsi que sur les cookies et les calculs dynamiques effectués à l’aide du module JavaScript de NGINX en tant que moteur JavaScript intégré | ✅ Basé sur les mêmes facteurs que NGINX Open Source, ainsi que sur les revendications JWT et les valeurs du magasin clé-valeur |
| Applications conteneurisées | Peut répartir la charge entre des ID Amazon, des instances de conteneur ECS, des groupes Auto Scaling et des fonctions AWS Lambda | Nécessite une configuration manuelle ou des modèles de configuration | Configuration automatisée à l’aide du DNS, notamment des enregistrements SRV ; fonctionne avec les principaux services de registre |
| Portabilité | ❌ Tous les environnements (développement, test et production) doivent être hébergés sur AWS | ✅ Chaque environnement peut être hébergé sur n’importe quelle plateforme de déploiement | |
| SSL/TLS | ✅ Plusieurs certificats SSL/TLS avec prise en charge de SNI ❌ Validation des serveurs en amont SSL/TLS non prise en charge | ✅ Plusieurs certificats SSL/TLS avec prise en charge de SNI ✅ Choix complet de chiffrements SSL/TLS ✅ Validation complète des serveurs en amont SSL/TLS | |
| HTTP/2 et WebSocket | ✅ | ✅ | |
| Fonctionnalités d’authentification | – Options d’authentification OIDC, SAML, LDAP et fournisseur d’identité AD – Intégration à AWS Cognito et CloudFront | Plusieurs options d’authentification | |
| Fonctionnalités avancées | ❌ API rudimentaire | ✅ Diffusion depuis l’origine, gestion des priorités, limitation du débit, etc. | ✅ Fonctionnalités identiques à celles de NGINX Open Source, auxquelles s’ajoutent une API RESTful et un magasin clé-valeur |
| Journalisation et débogage | ✅ Format de journal binaire Amazon | ✅ Fichiers journaux personnalisables et plusieurs interfaces de débogage | ✅ Fichiers journaux entièrement personnalisables et plusieurs interfaces de débogage, avec une prise en charge complète par NGINX |
| Outils de surveillance | ✅ Intégration à Amazon CloudWatch | ✅ NGINX Controller* et autres outils tiers | ✅ NGINX Controller et autres outils tiers ; ensemble étendu de statistiques communiquées |
| Assistance technique officielle | ✅ Moyennant un coût supplémentaire | ❌ Assistance communautaire uniquement | ✅ Incluse dans le prix et assurée directement par NGINX |
| Offre gratuite | ✅ Les 750 premières heures | ✅ Toujours gratuit | ✅ Abonnement d’essai de 30 jours |
* NGINX Controller s’appelle désormais F5 NGINX Management Suite.
Bien entendu, vous devez évaluer votre choix de solution d’équilibrage de charge non pas à partir d’une liste de fonctionnalités, mais en fonction des capacités dont vous avez besoin pour fournir vos applications sans faille, avec un niveau de sécurité élevé, une disponibilité maximale et un contrôle total.
Gestion des pics de trafic
Le Classic Load Balancer d’Amazon (anciennement ELB) réagissait mal aux pics de trafic. Les instances de l’équilibreur de charge étaient automatiquement dimensionnées en fonction du niveau de trafic actuel, et ELB pouvait mettre plusieurs minutes à réagir et à déployer de la capacité supplémentaire en cas de pic. Les utilisateurs devaient recourir à une procédure manuelle reposant sur des formulaires pour demander des ressources supplémentaires avant les pics de trafic (une opération appelée « préchauffage »). Comme ALB repose sur NGINX, ses instances peuvent gérer un trafic bien plus important, mais des opérations de mise à l’échelle peuvent tout de même se produire en réponse aux pics de trafic. En outre, un pic de trafic entraîne automatiquement une consommation accrue d’unités de capacité de l’équilibreur de charge (LCU) et, par conséquent, une hausse des coûts.
Vous pouvez maîtriser entièrement la capacité et les coûts en déployant et en faisant évoluer vous-même vos proxys d’équilibrage de charge. NGINX et NGINX Plus sont déployés sur des instances Amazon standard, et notre guide de dimensionnement donne une indication des performances maximales potentielles des types d’instances offrant différentes capacités. Le tarif de NGINX Plus étant identique pour toutes les tailles d’instance, il est rentable de déployer une capacité excédentaire pour absorber les pics de trafic. De plus, lorsque davantage de capacité est nécessaire, vous pouvez rapidement déployer des instances supplémentaires, sans aucun formulaire à remplir.
Détection des serveurs défaillants grâce aux contrôles d’intégrité
Nos tests d’Amazon ALB indiquent qu’il ne met pas en œuvre de contrôles d’intégrité « passifs ». Un serveur n’est détecté comme défaillant qu’une fois qu’un test asynchrone a vérifié qu’il ne renvoie pas le code d’état attendu.
Nous l’avons découvert en créant une instance ALB afin de répartir la charge entre un cluster d’instances. Nous avons configuré une vérification de l’état avec la fréquence minimale de 5 secondes et le seuil minimal de 2 échecs, puis envoyé un flux continu de requêtes à l’ALB. Lorsque nous avons arrêté l’une des instances, l’ALB a renvoyé, pour certaines requêtes, une erreur 502 Bad Gateway pendant plusieurs secondes, jusqu’à ce que la vérification de l’état détecte que l’instance était indisponible. Les vérifications passives de l’état (prises en charge par NGINX et NGINX Plus) évitent que les utilisateurs finaux ne voient ce type d’erreur.
Les contrôles d’intégrité d’ALB peuvent uniquement déterminer l’état d’une instance en examinant le code d’état HTTP (tel que 200 OK ou 404 Not Found). Ces contrôles d’intégrité ne sont pas fiables. Par exemple, certaines applications web remplacent les erreurs générées par le serveur par des pages conviviales, et certaines erreurs sont uniquement signalées dans le corps d’une page web.
NGINX Plus prend en charge les contrôles d’intégrité passifs et les contrôles d’intégrité actifs, ces derniers étant plus puissants que ceux d’ALB, car ils peuvent vérifier le corps d’une réponse ainsi que le code d’état.
Tarification
Enfin, la principale question qui se pose si vous déployez un ALB est celle du coût. L’équilibrage de charge peut représenter une part importante de votre facture Amazon.
AWS utilise un algorithme complexe pour déterminer les tarifs. À moins de connaître précisément le nombre de nouvelles connexions, le nombre de connexions simultanées et la quantité de données que vous traiterez chaque mois – ce qui est très difficile à prévoir – et de pouvoir effectuer le calcul des LCU de la même manière qu’Amazon, vous redouterez chaque mois de recevoir votre facture Amazon.
NGINX Plus sur AWS vous offre une prévisibilité totale. Pour un coût horaire fixe auquel s’ajoutent les frais d’hébergement AWS, vous bénéficiez d’une solution d’équilibrage de charge nettement plus puissante, avec une assistance complète.
Conclusion
NGINX Plus est une solution éprouvée pour l’équilibrage de charge de couche 7, qui offre également des fonctionnalités d’équilibrage de charge de couche 4. Elle fonctionne parfaitement en association avec le Classic Load Balancer ou le NLB d’Amazon.
Nous encourageons l’utilisation continue et croissante de NGINX et de NGINX Plus dans l’environnement AWS, où ils constituent déjà une solution très populaire. Si vous n’utilisez pas encore NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.