Choisir le bon équilibreur de charge sur Amazon : Équilibreur de charge d’application AWS contre. NGINX Plus
En août 2016, Amazon Web Services (AWS) a introduit Application Load Balancer pour l'équilibrage de charge de couche 7 du trafic HTTP et HTTPS. Le nouveau produit a ajouté plusieurs fonctionnalités manquantes à l'équilibreur de charge de couche 4 et de couche 7 existant d'AWS, Elastic Load Balancer, qui a été officiellement renommé Classic Load Balancer.
Un an plus tard, AWS a lancé Network Load Balancer pour améliorer l'équilibrage de la charge de couche 4. Ainsi, l'ensemble des choix pour les utilisateurs exécutant des applications hautement disponibles et évolutives sur AWS comprend :
- 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 examinons les fonctionnalités d’ALB et comparons ses prix et ses fonctionnalités à ceux de NGINX Open Source et 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 de NGINX Plus et Classic Load Balancer (anciennement Elastic Load Balancer ou ELB), ainsi que des informations sur leur utilisation ensemble, consultez notre article de blog précédent .
- Pour plus d’informations sur l’utilisation de NLB pour un déploiement NGINX Plus à haute disponibilité, consultez notre article de blog précédent .
Fonctionnalités d'Application Load Balancer
ALB, 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 ne fournisse pas toute l'étendue des fonctionnalités, des réglages et du contrôle direct qu'un proxy inverse et un équilibreur de charge de couche 7 autonomes peuvent offrir.
ALB fournit les fonctionnalités suivantes qui manquent à Classic Load Balancer :
- Routage basé sur le contenu. ALB prend en charge le routage basé sur le contenu en fonction de l’URL de la demande, de l’en-tête
de l’hôteet des champs de la demande qui incluent les en-têtes et méthodes HTTP standard et personnalisés, les paramètres de requête et l’adresse IP source. (Voir « Avantages de la migration à partir d’un équilibreur de charge classique » dans la documentation 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 le service de conteneurs EC2 (ECS) d'Amazon.
- Plus de mesures. 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 HTTP/2. ALB prend en charge HTTP/2, une alternative supérieure lors de la diffusion de contenu sécurisé par SSL/TLS.
(Pour une comparaison complète des fonctionnalités d'ALB et de Classic Load Balancer, consultez « Comparaisons de produits » dans la documentation AWS .)
ALB était une mise à jour importante pour les utilisateurs d’AWS qui avaient du mal avec l’ensemble limité de fonctionnalités de Classic Load Balancer, et elle a contribué à répondre dans une certaine mesure aux exigences des utilisateurs sophistiqués qui doivent pouvoir sécuriser, optimiser et contrôler le trafic vers leurs applications Web. Cependant, il ne fournit 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
Plutôt que d'utiliser Amazon ALB, les utilisateurs peuvent déployer NGINX Open Source ou NGINX Plus sur AWS pour contrôler et équilibrer la charge du trafic. Ils peuvent également déployer Classic Load Balancer ou Network Load Balancer en tant qu'interface pour obtenir une haute disponibilité sur plusieurs zones de disponibilité. Le tableau compare les fonctionnalités prises en charge par ALB, NGINX et NGINX Plus.
Note: Les informations contenues 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 | |
|---|---|---|---|
| Équilibrage de charge méthodes et fonctionnalités |
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 lent |
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 | Identique à NGINX Open Source, avec en plus la méthode Least Time, davantage de méthodes de persistance de session et un démarrage lent |
| Mise en cache | ❌ La mise en cache dans l'équilibreur de charge n'est pas prise en charge | ✅ Mise en cache statique des fichiers et mise en cache dynamique (application) | ✅ Mise en cache statique et dynamique ainsi que fonctionnalités avancées |
| Contrôles de santé | Actif (identifie les serveurs défaillants en vérifiant le code d'état renvoyé pour les contrôles asynchrones) | Passif (identifie les serveurs défaillants en vérifiant les réponses aux demandes des clients) | À la fois actifs et passifs – les contrôles actifs sont plus riches et plus configurables que ceux d’ALB |
| Haute disponibilité | Vous pouvez déployer des instances ALB dans plusieurs zones de disponibilité pour HA, mais pas dans plusieurs régions | HA actif-actif avec NLB et HA actif-passif avec adresses IP élastiques | Identique à NGINX Open Source, avec en plus un partage d'état de cluster intégré pour une haute disponibilité transparente sur 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 contrôles de santé passifs | ✅ Également TCP et UDP, avec contrôles de santé actifs et passifs |
| Plusieurs applications par instance d'équilibreur de charge | ✅ | ✅ | |
| Routage basé sur le contenu | ✅ Basé sur l'URL de la demande, l'en-tête de l'hôte et les champs de demande, y compris 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 que ALB, plus des cookies et des calculs dynamiques utilisant le module JavaScript NGINX comme moteur JavaScript en ligne | ✅ Basé sur les mêmes facteurs que NGINX Open Source, plus les revendications et valeurs JWT dans le magasin clé-valeur |
| Applications conteneurisées | Peut équilibrer la charge sur les identifiants Amazon, les instances de conteneur ECS, les groupes Auto Scaling et les fonctions AWS Lambda | Nécessite une configuration manuelle ou des modèles de configuration | Configuration automatisée à l'aide de DNS, y compris les enregistrements SRV ; fonctionne avec les principaux services de registre |
| Portabilité | ❌ Tous les environnements (développement, test et production) doivent être sur AWS | ✅ N'importe quel environnement peut être sur n'importe quelle plateforme de déploiement | |
| SSL/TLS | ✅ Plusieurs certificats SSL/TLS avec prise en charge SNI ❌ Validation des flux SSL/TLS en amont non prise en charge |
✅ Plusieurs certificats SSL/TLS avec prise en charge SNI ✅ Choix complet de chiffrements SSL/TLS ✅ Validation complète des flux SSL/TLS en amont |
|
| HTTP/2 et WebSocket | ✅ | ✅ | |
| Capacités d'authentification | – Options d’authentification OIDC, SAML, LDAP, AD IdP – Intégré à AWS Cognito et CloudFront |
Plusieurs options d'authentification | |
| Capacités avancées | ❌ API de base | ✅ Diffusion d'origine, priorisation, limitation de débit et plus encore | ✅ Identique à NGINX Open Source, plus API RESTful, magasin clé-valeur |
| Journalisation et débogage | ✅ Format du journal binaire Amazon | ✅ Fichiers journaux personnalisables et interfaces de débogage multiples | ✅ Fichiers journaux entièrement personnalisables et interfaces de débogage multiples, entièrement pris en charge par NGINX |
| Outils de surveillance | ✅ Intégré à Amazon CloudWatch | ✅ Contrôleur NGINX* et autres outils tiers | ✅ Contrôleur NGINX et autres outils tiers ; ensemble étendu de statistiques rapportées |
| Support technique officiel | ✅ Avec un coût supplémentaire | ❌ Support communautaire uniquement | ✅ Inclus dans le prix et directement depuis NGINX |
| Niveau gratuit | ✅ Les 750 premières heures | ✅ Toujours gratuit | ✅ Abonnement d'essai de 30 jours |
* NGINX Controller est désormais F5 NGINX Management Suite .
Bien entendu, vous devez évaluer votre choix d’équilibrage de charge non pas en fonction d’une liste de fonctionnalités, mais en évaluant les capacités dont vous avez besoin pour fournir vos applications de manière irréprochable, avec une sécurité élevée, une disponibilité maximale et un contrôle total.
Gérer les pics de trafic
L’équilibreur de charge classique d’Amazon (anciennement ELB) souffrait d’une mauvaise réponse aux pics de trafic. Les instances d'équilibrage de charge étaient automatiquement dimensionnées en fonction du niveau de trafic actuel, et il pouvait falloir plusieurs minutes à ELB pour répondre et déployer une capacité supplémentaire en cas de pics. Les utilisateurs devaient recourir à un processus manuel basé sur des formulaires pour demander des ressources supplémentaires avant les pics de trafic (appelé « préchauffage »). Étant donné qu’ALB est basé sur NGINX, les instances ALB peuvent gérer beaucoup plus de trafic, mais vous pouvez toujours observer des événements de mise à l’échelle en réponse aux pics de trafic. De plus, un pic de trafic entraîne automatiquement une plus grande consommation d'unités de capacité d'équilibrage de charge (LCU) et, par conséquent, un coût plus élevé.
Vous pouvez obtenir un contrôle total sur la capacité et les coûts si vous déployez et faites évoluer vous-même vos proxys d’équilibrage de charge. NGINX et NGINX Plus sont déployés dans des instances Amazon standard, et notre guide de dimensionnement donne une indication des performances de pointe potentielles des types d'instances avec différentes capacités. La tarification de NGINX Plus est la même pour toutes les tailles d'instance. Il est donc rentable de déployer une capacité excédentaire pour gérer les pics, et il est rapide de déployer davantage d'instances (aucun formulaire à remplir) lorsqu'une capacité supplémentaire est nécessaire.
Détection des serveurs défaillants à l'aide de contrôles de santé
Nos tests d’Amazon ALB indiquent qu’il n’implémente pas de contrôles de santé « passifs ». Un serveur n'est détecté comme ayant échoué qu'une fois qu'un test asynchrone vérifie qu'il ne renvoie pas le code d'état attendu.
Nous avons découvert cela en créant une instance ALB pour équilibrer la charge d’un cluster d’instances. Nous avons configuré un contrôle de santé avec une fréquence minimale de 5 secondes et un seuil minimum de 2 contrôles échoués, et avons envoyé un flux constant de requêtes à l'ALB. Lorsque nous avons arrêté l'une des instances, pour certaines requêtes, ALB a renvoyé une 502 Mauvais Porte erreur pendant plusieurs secondes jusqu'à ce que le contrôle de santé détecte que l'instance était en panne. Les contrôles de santé passifs (pris en charge par NGINX et NGINX Plus) empêchent ces types d’erreurs d’être détectés par les utilisateurs finaux.
Les contrôles de santé d'ALB ne peuvent déterminer la santé d'une instance qu'en inspectant le code d'état HTTP (tel que 200OK ou 404( Non trouvé ). De tels contrôles de santé 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 ne sont signalées que dans le corps d’une page Web.
NGINX Plus prend en charge les contrôles de santé passifs et actifs , et ces derniers sont plus puissants que ceux d'ALB, capables de correspondre au corps d'une réponse ainsi qu'au code d'état.
Tarifs
Enfin, la plus grande question à laquelle vous êtes confronté si vous déployez ALB est le 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 prix . À moins que vous ne sachiez précisément combien de nouvelles connexions, combien de connexions simultanées et quelle quantité de données vous gérerez chaque mois – ce qui est très difficile à prévoir – et que vous puissiez exécuter le calcul LCU de la même manière qu'Amazon, vous redouterez votre facture Amazon chaque mois.
NGINX Plus sur AWS vous offre une prévisibilité totale. Pour un coût horaire fixe plus les frais d’hébergement AWS, vous obtenez une solution d’équilibrage de charge nettement plus puissante avec un support complet.
Conclusion
NGINX Plus est une solution éprouvée pour l'équilibrage de charge de couche 7, avec également des fonctionnalités d'équilibrage de charge de couche 4. Il fonctionne bien en tandem avec le Classic Load Balancer ou NLB d’Amazon.
Nous encourageons l’utilisation continue et croissante de NGINX et NGINX Plus dans l’environnement AWS, une solution déjà très populaire. Si vous n'êtes pas encore utilisateur de NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."