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

Michael Pleshakov

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 d’un calendrier ou de la demande. Auto Scaling permet de réduire les coûts en ajustant le nombre d’instances aux besoins de la charge de travail actuelle. De plus, Auto Scaling redémarre les instances défaillantes, ce qui améliore la résilience de vos applications.

L’équilibrage de charge est essentiel lors de l’utilisation d’Auto Scaling. AWS assure l’équilibrage de charge des instances des 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) – à Auto Scaling. NGINX Plus fournit des fonctionnalités avancées d’équilibrage de charge dans le cloud 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 pour remplacer ou compléter les répartiteurs de charge cloud intégrés d’AWS :

1. NGINX Plus offre de nombreuses fonctionnalités avancées dont ELB et ALB sont dépourvus.
2. Le modèle tarifaire des équilibreurs de charge AWS (en particulier ALB) est complexe, ce qui rend les coûts difficiles à prévoir. La tarification de NGINX Plus est simple, que vous souscriviez un abonnement NGINX Plus directement auprès de nous ou que vous exécutiez des instances NGINX Plus préconfigurées depuis AWS Marketplace, facturées selon un tarif horaire fixe.
3. NGINX Plus ne vous lie pas à des API propres à une plateforme, ce qui vous permet de réutiliser la configuration de l’équilibrage de charge sur plusieurs plateformes cloud.

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

Dans cet article de blog, nous présentons deux méthodes permettant de configurer NGINX Plus pour répartir la charge entre des groupes Auto Scaling, et expliquons dans quels cas il est pertinent d’utiliser chacune d’elles :

1. Utilisation de NGINX Plus en amont d’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 afin de fournir un équilibrage de charge avancé pour les groupes Auto Scaling.

Exemple d’environnement AWS Auto Scaling

Nous utilisons un exemple d’environnement applicatif pour illustrer les deux méthodes permettant d’utiliser NGINX Plus afin de répartir la charge entre des groupes Auto Scaling. Notre application Web backend se compose de deux services, Backend One et Backend Two, chacun étant exposé sur le port 80. Chaque service dispose d’un groupe Auto Scaling comprenant plusieurs instances de l’application. L’équilibreur de charge achemine les requêtes des clients vers le backend approprié en fonction de l’URI de la requête :

• Les requêtes adressées à « /backend‑one » sont acheminées vers Backend One.
• Les requêtes vers « /backend‑two » sont acheminées vers le backend Two.

Lorsque nous redimensionnons les groupes Auto Scaling de l’application (automatiquement ou manuellement), la configuration de l’équilibreur de charge doit être mise à jour pour tenir compte du nouveau nombre d’instances de l’application. Les équilibreurs de charge intégrés d’AWS le font automatiquement. Pour NGINX Plus, nous devons répercuter les événements de redimensionnement dans la configuration à l’aide de l’une des méthodes mentionnées ci-dessus (NGINX Plus placé devant ELB ou NGINX Plus associé au logiciel d’intégration).

Une autre façon de mettre à jour la configuration de 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 des 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 faciles à configurer et à utiliser, qui ne nécessitent pas de systèmes externes.

Utiliser NGINX Plus en amont d’ELB

Si vous utilisez déjà des groupes Auto Scaling et ELB, le moyen le plus simple de faire bénéficier votre application de certaines fonctionnalités avancées de NGINX Plus consiste à placer NGINX Plus devant les équilibreurs de charge cloud ELB, comme illustré dans le schéma :

Dans ce cas, NGINX Plus fait office de proxy et d’équilibreur de charge pour un ou plusieurs ELB. Grâce à ses fonctionnalités avancées de routage, 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 Auto Scaling. Dans cette configuration, l’ELB prend en charge la mise à l’échelle.

Voici la configuration de NGINX Plus.

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

• La directive resolver définit le serveur DNS utilisé par NGINX Plus pour résoudre les noms DNS des instances ELB internes. Ici, il s’agit de l’adresse IP du serveur DNS d’AWS.
• Nous créons deux blocs upstream, 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 répartit le trafic vers celui-ci. Le paramètre resolve indique à NGINX Plus de résoudre à nouveau le nom périodiquement ; la fréquence est définie par le paramètre valid de la directive resolver mentionnée dans le point précédent. Nous la fixons ici à 10 secondes, car les adresses IP de l’ELB sont susceptibles de changer fréquemment. La directive zone alloue de la mémoire (ici jusqu’à 64 Ko) pour stocker les adresses IP résolues.
• Nous définissons un server virtuel qui écoute sur le port 80. Les blocs location indiquent à NGINX Plus de transmettre les requêtes destinées à /backend‑one à l’ELB du groupe Auto Scaling Backend One et celles destinées à /backend‑two à l’ELB du groupe Auto Scaling Backend Two.

Comme vous pouvez le constater, cette méthode est facile à configurer et à utiliser, surtout si vous utilisez déjà ELB. Elle présente toutefois plusieurs inconvénients :

• Options d’équilibrage de charge limitées. Comme NGINX Plus transmet les requêtes à ELB, et non directement aux instances backend, c’est ELB qui assure l’équilibrage de charge. Par conséquent, vous ne pouvez pas tirer parti des algorithmes d’équilibrage de charge plus sophistiqués ni des options de persistance de session de NGINX Plus.
• Redondance. NGINX Plus peut assurer la répartition de charge, ce qui rend ELB superflu : nous l’utilisons uniquement parce qu’il est intégré nativement à Auto Scaling.
• Prise en charge limitée des protocoles. Contrairement à NGINX Plus, ELB ne prend pas en charge WebSocket ni 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 détecte un événement de mise à l’échelle, il ajoute ou supprime des instances backend dans la configuration de NGINX Plus. Comme illustré, nginx-asg-sync est informé des modifications apportées aux groupes Auto Scaling par l’intermédiaire de 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 Auto Scaling pour les backends existent déjà. Elles 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 étant authentifiée, vous devez 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 détaillées, consultez Rôles IAM pour Amazon EC2 dans la documentation AWS.

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

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

Pour installer le logiciel d’intégration, téléchargez le paquet correspondant à votre système d’exploitation depuis le dépôt GitHub nginx-asg-sync GitHub repository, puis installez-le sur l’instance où NGINX Plus est exécuté.

• Pour Amazon Linux, CentOS et RHEL :

$ sudo rpm -i package-name.rpm

• Pour Ubuntu :

$ sudo dpkg -i package-name.deb

Pour obtenir les instructions d’installation complètes, consultez la documentation sur GitHub.

Étape 3 – Configurer NGINX Plus

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

• Configurez les points de terminaison d’API pour la reconfiguration à la volée et la surveillance de l’activité en temps réel. Le logiciel d’intégration utilise ces points de terminaison pour ajouter des instances de serveurs backend aux groupes en amont et en supprimer.
• Créez un bloc upstream pour chaque groupe Auto Scaling. Ne définissez aucun serveur dans ce bloc, car nginx-asg-sync les ajoute et les supprime automatiquement en fonction des événements de mise à l’échelle.

L’exemple suivant présente la configuration de notre application web simple :

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /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 Auto Scaling. Ici, toutefois, nous n’ajoutons aucun serveur aux groupes en amont, car les serveurs seront ajoutés par nginx‑aws‑sync. La directive state indique le fichier dans lequel est stockée la liste de serveurs configurable dynamiquement, ce qui permet de la conserver 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 requêtes destinées à /backend‑one directement aux instances du groupe Backend One, et celles destinées à /backend‑two directement aux instances du groupe Backend Two.
• Nous définissons un deuxième serveur virtuel à l’écoute sur le port 8080 et y configurons les API de NGINX Plus :
  • L’API de configuration à la volée est disponible à l’adresse 127.0.0.1:8080/upstream_conf
  • L’API de statut 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 », situé dans le dossier « /etc/nginx ». Pour notre application, nous définissons la configuration suivante :

region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
 - name: backend-one
   autoscaling_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

• La clé « region » 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é upstreams définit la liste des groupes de serveurs en amont. Pour chaque groupe, nous indiquons :
  • name – Le nom que nous avons spécifié pour le bloc upstream à l’étape 3.
  • autoscaling_group – Le nom du groupe Auto Scaling correspondant.
  • port – Le port sur lequel nos services backend sont exposés.
  • kind – Le protocole du trafic que NGINX Plus répartit vers l’application backend, ici http. Si l’application utilise TCP/UDP, indiquez plutôt stream.

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

$ sudo restart nginx-asg-sync

Tester la répartition de charge et la mise à l’échelle

Dans les étapes précédentes, nous avons configuré NGINX Plus pour répartir la charge entre les groupes Auto Scaling de notre application. Nous pouvons maintenant tester cette configuration. NGINX Plus distribue les requêtes dont l’URI est /backend‑one aux instances du groupe Backend One, et celles dont l’URI est /backend‑two aux instances du groupe Backend Two.

Nous pouvons voir comment NGINX Plus détecte les nouvelles instances lorsque nous augmentons la capacité de nos groupes Auto Scaling. Tout d’abord, nous accédons au tableau de bord de surveillance de l’activité en temps réel, accessible à l’adresse /status.html sur le port 8080 de l’instance NGINX Plus. Dans l’onglet Upstream, nous voyons les instances de nos groupes Auto Scaling :

Nous faisons maintenant passer le groupe Backend One de trois à cinq instances en modifiant la capacité du groupe Auto Scaling. Une fois les nouvelles instances lancées, nginx-asg-sync les ajoute à la configuration de NGINX Plus. Peu après, les nouvelles instances apparaissent dans le tableau de bord :

Rendre NGINX Plus hautement disponible

Jusqu’à présent, nous n’avons lancé qu’une seule instance de NGINX Plus. Toutefois, pour assurer une haute disponibilité, nous vous recommandons de créer un groupe Auto Scaling pour NGINX Plus lui-même et d’utiliser ELB en amont des instances NGINX Plus. À la place d’ELB, vous pouvez utiliser Route 53 pour acheminer le trafic vers les instances NGINX Plus. Le schéma de notre déploiement avec ELB se présente comme suit :

Choisir la bonne méthode

Alors, quelle méthode de configuration de NGINX Plus pour répartir la charge entre les groupes Auto Scaling vous convient le mieux ? Le tableau compare brièvement les deux :

NGINX Plus devant ELB NGINX Plus avec le logiciel d’intégrationAvantages Configuration simple et aucune installation de logiciel supplémentaire. Accès à tous les avantages des fonctionnalités de NGINX Plus, sans les limitations imposées par la méthode ELB.Inconvénients Limite le nombre de fonctionnalités de NGINX Plus utilisables, notamment les protocoles pris en charge. Augmente le coût du déploiement ainsi que la latence. Nécessite l’installation et la configuration du logiciel d’intégration.Résumé Utilisez cette méthode si ses inconvénients sont acceptables. Utilisez cette méthode pour tirer pleinement parti des capacités de NGINX Plus.

Résumé

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

Essayez NGINX Plus avec vos groupes AWS Auto Scaling : commencez votre essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Michael Pleshakov

Autres articles de Michael Pleshakov