Équilibrage de charge des groupes AWS Auto Scaling avec NGINX Plus

L’une des fonctionnalités les plus avantageuses du cloud est la possibilité d’adapter automatiquement le nombre d’instances de calcul. Avec AWS Auto Scaling , vous pouvez modifier le nombre d'instances EC2 dans un groupe Auto Scaling , manuellement ou automatiquement, en fonction du calendrier ou de la demande. La mise à l'échelle automatique permet de réduire les coûts en ajustant le nombre d'instances au nombre approprié à la charge de travail actuelle. De plus, la mise à l’échelle automatique redémarre les instances ayant échoué, ce qui ajoute de la résilience à vos applications.

L'équilibrage de la charge est crucial lors de l'utilisation de la mise à l'échelle automatique. AWS fournit un équilibrage de charge des instances de groupes Auto Scaling en intégrant ses équilibreurs de charge intégrés – Elastic Load Balancer (ELB), désormais officiellement appelé Classic Load Balancer, et Application Load Balancer (ALB) – avec Auto Scaling. NGINX Plus fournit un équilibrage de charge cloud avancé pour tout environnement cloud, y compris AWS, et prend en charge les groupes AWS Auto Scaling.

Il existe trois raisons principales de choisir NGINX Plus comme remplacement ou complément aux équilibreurs de charge cloud AWS intégrés :

1. NGINX Plus fournit plusieurs fonctionnalités avancées qui manquent à ELB et ALB.
2. Le modèle de tarification des équilibreurs de charge AWS (en particulier ALB) est complexe, ce qui rend difficile la prévision des coûts. La tarification de NGINX Plus est simple, que vous achetiez l'abonnement NGINX Plus directement auprès de nous ou que vous exécutiez des instances NGINX Plus prédéfinies à partir d' AWS Marketplace , qui sont facturées à un taux horaire fixe.
3. NGINX Plus ne vous lie pas à des API spécifiques à la plateforme, ce qui vous permet de réutiliser la configuration d’équilibrage de charge sur plusieurs plateformes cloud.

Pour voir comment NGINX Plus se compare aux solutions intégrées AWS (et fonctionne avec elles), lisez nos articles de blog sur ELB et ALB .

Dans cet article de blog, nous présentons deux méthodes de configuration de NGINX Plus pour équilibrer la charge des groupes de mise à l'échelle automatique et expliquons quand il est judicieux d'utiliser chaque méthode :

1. Utilisation de NGINX Plus devant ELB
2. Utilisation de NGINX Plus avec le logiciel d’intégration fourni par NGINX, Inc.

Après avoir lu cet article de blog, vous serez prêt à déployer NGINX Plus sur AWS pour fournir un équilibrage de charge avancé pour les groupes de mise à l'échelle automatique.

Exemple d'environnement AWS Auto Scaling

Nous utilisons un exemple d’environnement d’application pour illustrer les deux méthodes d’utilisation de NGINX Plus pour équilibrer la charge des groupes de mise à l’échelle automatique. Notre application Web backend se compose de deux services – Backend One et Backend Two – chacun exposé sur le port 80. Pour chaque service, il existe un groupe de mise à l’échelle automatique de plusieurs instances d’application. L'équilibreur de charge achemine les demandes des clients vers le backend approprié en fonction de l'URI de la demande :

• Les requêtes pour /backend‑one vont à Backend One.
• Les requêtes pour /backend‑two vont au Backend Two.

Lorsque nous mettons à l’échelle les groupes de mise à l’échelle automatique de l’application (automatiquement ou manuellement), la configuration de l’équilibreur de charge doit être mise à jour pour refléter le nouveau nombre d’instances d’application. Les équilibreurs de charge AWS intégrés le font automatiquement. Pour NGINX Plus, nous devons propager les événements de mise à l’échelle à la configuration avec l’une des méthodes mentionnées ci-dessus (NGINX Plus devant ELB ou NGINX Plus avec le logiciel d’intégration).

Une autre façon de mettre à jour la configuration NGINX Plus en réponse aux événements de mise à l’échelle consiste à utiliser un registre de services externe. NGINX Plus prend en charge l'intégration avec les systèmes de découverte de services qui fournissent une interface DNS , tels que Consul . Dans cet article de blog, nous nous concentrons sur des solutions qui ne dépendent pas de systèmes externes et qui sont faciles à configurer et à utiliser.

Utilisation de NGINX Plus devant ELB

Si vous utilisez déjà des groupes de mise à l'échelle automatique et ELB, le moyen le plus simple d'intégrer certaines des fonctionnalités avancées de NGINX Plus à votre application est de placer NGINX Plus devant les équilibreurs de charge cloud ELB, comme indiqué dans le diagramme :

Dans ce cas, NGINX Plus agit comme un proxy/équilibreur de charge pour un ou plusieurs ELB. Grâce à ses fonctionnalités de routage avancées, NGINX Plus transmet les requêtes à l'ELB approprié en fonction de l'URI de la requête. L'ELB transmet ensuite la requête à l'une des instances du groupe de mise à l'échelle automatique. Dans cette configuration, ELB fournit le support de la mise à l'échelle.

Voici la configuration NGINX Plus.

résolveur 169.254.169.253 valide=10s; backend-un en amont { zone backend-un 64k; serveur DNS-nom-de-ELB-pour-Backend-un résoudre; } backend-deux en amont { zone backend-deux 64k; serveur DNS-nom-de-ELB-pour-Backend-deux résoudre; } serveur { écouter 80; emplacement /backend-un { proxy_set_header Hôte $host; proxy_pass http://backend-un; } emplacement /backend-deux { proxy_set_header Hôte $host; proxy_pass http://backend-deux; } }

• La directive resolver définit le serveur DNS que NGINX Plus utilise pour résoudre les noms DNS des instances ELB internes. Voici l'adresse IP du serveur DNS AWS.

• Nous créons deux blocs en amont , un pour chaque groupe Auto Scaling correspondant à nos services, Backend One et Backend Two. Nous identifions le groupe Auto Scaling par le nom DNS de l'ELB qui équilibre la charge du trafic vers celui-ci.

  À l’aide du paramètre resolve , nous demandons à NGINX Plus de résoudre périodiquement le nom. La fréquence est définie par le paramètre valide de la directive resolver décrite dans la puce précédente. Ici, nous le définissons sur 10 secondes car les adresses IP d'ELB sont sujettes à des changements fréquents.

  La directive zone alloue de la mémoire (ici jusqu'à 64 Ko) pour stocker les adresses IP résolues.

• Nous définissons un serveur virtuel qui écoute sur le port 80. Les blocs d'emplacement indiquent à NGINX Plus de transmettre les demandes pour /backend-one à l'ELB pour le groupe de mise à l'échelle automatique Backend One et les demandes pour /backend-two à l'ELB pour le groupe de mise à l'échelle automatique Backend Two.

Comme vous pouvez le voir, cette méthode est facile à configurer et à utiliser, surtout si vous utilisez déjà ELB. Il existe cependant plusieurs inconvénients :

• Options d’équilibrage de charge limitées. Étant donné que NGINX Plus transmet les requêtes à ELB, et non directement aux instances back-end, c'est l'ELB qui effectue l'équilibrage de charge. Pour cette raison, vous ne pouvez pas profiter des algorithmes d’équilibrage de charge et des options de persistance de session plus sophistiqués de NGINX Plus.
• Redondance. NGINX Plus peut effectuer l’équilibrage de charge, donc ELB est redondant – nous l’utilisons uniquement parce qu’il est nativement intégré à Auto Scaling.
• Prise en charge limitée du protocole. Contrairement à NGINX Plus, ELB ne prend pas en charge WebSocket et UDP.

La méthode suivante ne repose pas sur ELB et ne présente donc pas ces inconvénients.

Utilisation de NGINX Plus avec le logiciel d'intégration

Avec cette méthode, vous installez un logiciel d’intégration supplémentaire avec NGINX Plus. Le logiciel ( nginx-asg-sync ) surveille en permanence les groupes Auto Scaling. Lorsqu'il constate qu'un événement de mise à l'échelle s'est produit, il ajoute ou supprime des instances backend de la configuration NGINX Plus. Comme indiqué, nginx-asg-sync apprend les modifications apportées aux groupes Auto Scaling via l'API AWS Auto Scaling.

Pour utiliser le logiciel d'intégration, procédez comme suit :

1. Configurer l'accès à l'API AWS
2. Installer le logiciel d'intégration
3. Configurer NGINX Plus
4. Configurer le logiciel d'intégration

Les instructions supposent que les groupes de mise à l’échelle automatique pour les backends existent déjà. Ils supposent également que NGINX Plus s’exécute sur une AMI Amazon Linux.

Étape 1 – Configurer l’accès à l’API AWS

La communication avec l'API Auto Scaling est authentifiée, vous devez donc fournir des informations d'identification pour nginx-asg-sync . AWS utilise des rôles IAM pour gérer les informations d'identification. Vous devez donc créer un rôle pour l'instance NGINX Plus avant de la lancer. Pour obtenir des instructions étape par étape, consultez Rôles IAM pour Amazon EC2 dans la documentation AWS.

1. Créez un rôle IAM et attachez-lui la politique AmazonEC2ReadOnlyAccess prédéfinie. Cette politique autorise l’accès en lecture seule aux API EC2.
2. Lorsque vous lancez l’instance NGINX Plus, ajoutez ce rôle IAM à l’instance.

Étape 2 – Installer le logiciel d’intégration

Pour installer le logiciel d'intégration, téléchargez le package correspondant à votre système d'exploitation à partir du référentiel GitHub nginx-asg-sync et installez-le sur l'instance sur laquelle NGINX Plus s'exécute.

• Pour Amazon Linux, CentOS et RHEL :

  $ sudo rpm -i nom-du-paquet .rpm
  

• Pour Ubuntu :

  $ sudo dpkg -i nom-du-paquet .deb
  

Pour des instructions d'installation complètes, consultez la documentation sur GitHub.

Étape 3 – Configurer NGINX Plus

Le logiciel d'intégration met à jour la configuration NGINX Plus à l'aide des API de reconfiguration dynamique et de surveillance des activités en direct . Pour que le logiciel fonctionne correctement, vous devez configurer ces API ainsi que déclarer les groupes en amont nécessaires :

• Configurez les points de terminaison de l’API pour la reconfiguration à la volée et la surveillance des activités en direct. Le logiciel d’intégration utilise ces points de terminaison pour ajouter et supprimer des instances back-end des groupes en amont.
• Créez un bloc en amont pour chaque groupe de mise à l’échelle automatique. Ne définissez aucun serveur dans le bloc, car nginx-asg-sync les ajoute et les supprime automatiquement en réponse aux événements de mise à l'échelle.

L'exemple suivant représente la configuration de notre application Web simple :

backend-one en amont { zone backend-one 64k;
état /var/lib/nginx/state/backend-one.conf;
}

backend-two en amont {
zone backend-two 64k;
état /var/lib/nginx/state/backend-two.conf;
}

serveur {
écoute 80;

zone_état backend;

emplacement /backend-one {
proxy_set_header Hôte $host;
proxy_pass http://backend-one;
}

emplacement /backend-two {
proxy_set_header Hôte $host;
proxy_pass http://backend-two;
}
}

serveur {
écoute 8080;

racine /usr/share/nginx/html;

emplacement = / {
retour 302 /status.html;
}

emplacement = /status.html {}

emplacement /status {
access_log off;
status;
}

emplacement /upstream_conf {
upstream_conf;
}
}

• Comme dans l’exemple ELB, nous déclarons deux groupes en amont – backend-one et backend-two , qui correspondent à nos groupes de mise à l’échelle automatique. Ici, cependant, nous n’ajoutons aucun serveur aux groupes en amont, car les serveurs seront ajoutés par nginx‑aws‑sync . La directive d'état nomme le fichier dans lequel la liste des serveurs configurables dynamiquement est stockée, lui permettant de persister après les redémarrages de NGINX Plus.
• Nous définissons un serveur virtuel qui écoute sur le port 80. Contrairement à l’exemple ELB, NGINX Plus transmet les demandes pour /backend-one directement aux instances du groupe Backend One et les demandes pour /backend-two directement aux instances du groupe Backend Two.

• Nous définissons un deuxième serveur virtuel à l'écoute sur le port 8080 et configurons les API NGINX Plus dessus :

  • L'API à la volée est disponible à l' adresse 127.0.0.1:8080/upstream_conf
  • L'API d'état est disponible à l' adresse 127.0.0.1:8080/status

Étape 4 – Configurer le logiciel d’intégration

Le logiciel d'intégration est configuré dans le fichier aws.yaml dans le dossier /etc/nginx . Pour notre application, nous définissons la configuration suivante :

région : us-west-2point_de_fin_de_conf_en_amont : http://127.0.0.1:8080/upstream_conf
point_de_fin_de_statut : http://127.0.0.1:8080/status
intervalle_de_synchronisation_en_secondes : 5
en amont :
- nom : backend-one
autoscaling_group : backend-one-group
port : 80
type : http
- nom : backend-two
groupe de mise à l'échelle automatique : backend-two-group
port : 80
genre : http

• La clé de région définit la région AWS dans laquelle nous déployons notre application.
• Les clés upstream_conf_endpoint et status_endpoint définissent les points de terminaison de l'API NGINX Plus, que nous avons configurés à l'étape 3 .
• La clé sync_interval_in_seconds définit l'intervalle de synchronisation : nginx-asg-sync vérifie les mises à jour de mise à l'échelle toutes les 5 secondes.

• La clé en amont définit la liste des groupes en amont. Pour chaque groupe en amont nous spécifions :

  • nom – Le nom que nous avons spécifié pour le bloc en amont à l’étape 3.
  • autoscaling_group – Le nom du groupe de mise à l’échelle automatique correspondant.
  • port – Le port sur lequel nos services backend sont exposés.
  • kind – Le protocole du trafic que NGINX Plus équilibre vers l’application backend, ici http . Si l'application utilise TCP/UDP, spécifiez plutôt stream .

Après avoir modifié le fichier aws.yaml , redémarrez le logiciel :

$ sudo restart nginx-asg-sync

Test de l'équilibrage de charge et de la mise à l'échelle

Dans les étapes ci-dessus, nous avons configuré NGINX Plus pour équilibrer la charge des groupes de mise à l’échelle automatique pour notre application. Maintenant, nous pouvons le tester. NGINX Plus distribue les requêtes avec l'URI /backend‑one aux instances du groupe Backend One et les requêtes avec l'URI /backend‑two aux instances du groupe Backend Two.

Nous pouvons voir comment NGINX Plus récupère de nouvelles instances lorsque nous mettons à l’échelle nos groupes de mise à l’échelle automatique. Tout d’abord, nous accédons au tableau de bord de surveillance de l’activité en direct , accessible à /status.html sur le port 8080 de l’instance NGINX Plus. Dans l’onglet En amont, nous voyons les instances dans nos groupes de mise à l’échelle automatique :

Maintenant, nous augmentons la capacité du groupe Backend One de trois à cinq instances en modifiant la capacité du groupe de mise à l’échelle automatique. Une fois les nouvelles instances lancées, nginx-asg-sync les ajoute à la configuration NGINX Plus. Bientôt, les nouvelles instances apparaissent sur le tableau de bord :

Rendre NGINX Plus hautement disponible

Jusqu’à présent, nous n’avons lancé qu’une seule instance de NGINX Plus. Cependant, pour une haute disponibilité, nous vous recommandons de créer un groupe de mise à l'échelle automatique pour NGINX Plus lui-même et d'utiliser ELB devant les instances NGINX Plus. Alternativement à ELB, vous pouvez utiliser Route 53 pour acheminer le trafic vers les instances NGINX Plus. Le diagramme de notre déploiement avec ELB ressemble à ceci :

Choisir la bonne méthode

Alors, quelle méthode de configuration de NGINX Plus pour équilibrer la charge des groupes de mise à l’échelle automatique vous convient le mieux ? Le tableau compare brièvement les deux :

Résumé

AWS Auto Scaling offre l’avantage d’ajuster le nombre d’instances d’application au niveau de la demande. NGINX Plus fournit des fonctionnalités d’équilibrage de charge avancées qui peuvent être utilisées conjointement avec les groupes AWS Auto Scaling.

Essayez NGINX Plus avec vos groupes AWS Auto Scaling – démarrez votre essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d'utilisation .