Le Blog Amazon Web Services

Configurer un ALB sur AWS Outposts

AWS Outposts apporte l’infrastructure et les services AWS à virtuellement n’importe quel datacentre, espace de colocation ou installation on-premises, sous forme d’un rack physiquement connecté au réseau AWS. Les services AWS fonctionnent localement sur l’Outpost, et vous permettent d’accéder à toute l’offre des services AWS disponibles dans votre Région – qui inclu l’équilibreur de charge d’application (Application Load Balancer ALB). Cependant, il existe une légère différence entre la configuration d’un ALB sur Outpost et dans une région du cloud AWS. Cet article fournit une vue d’ensemble la mise en place d’un ALB sur Outpost pour permettre l’équilibrage et le passage à l’échelle des ressources. Nous expliquons également comment visualiser les événements comme la mise à l’échelle de l’ALB lui-même ou les ressources à l’intérieur de son target group (groupe cible).

Cet article suppose que vous êtes familier avec AWS Outposts, y compris les fonctionnalités de la passerelle locale (Local Gateway LGW) et plage d’adresses IP clients (pool CoIP). Si vous voulez en savoir plus sur AWS Outposts de manière générale, le guide d’utilisateur Qu’est-ce qu’AWS Outposts ?, est un bon moyen de débuter.

Les AWS Outposts présentent; entre autre, un intérêt pour nos clients ayant des cas d’usage nécessitant une latence très faible pour lesquels il peut être nécessaire d’amener les fonctionnalités d’équilibrage de charge on-premises.

Un cas d’usage commun est le besoin de communications à faible latence vers les serveurs d’application web pour lesquels AWS Outposts permet la mise en place des services nécessaires on-premises. L’ALB déployé sur AWS Outposts permet alors l’équilibrage de charge à faible latence des flux HTTP et HTTPS émis par un environnement on-premises évolutif et fiable.

Un autre cas d’usage commun est le besoin de communications à faible latence vers un serveur d’application web qui peut être hébergé sur AWS Outposts, dans vos locaux. Ceci peut être crucial dans des industries comme le média ou les jeux video qui génèrent des flux vidéo en direct, ou pour des entreprises dans le domaine du manufacturing dont les communications avec des équipements de lignes de production sont par exemple basées sur l’utilisation d’API web. Fournir de la résilience aux serveurs d’application sans utiliser un ALB sur AWS Outposts nécessite la mise en place d’un équilibreur de charge sur site qui pointe vers l’adresse IP Elastic des serveurs d’applications. Cela implique de dimensionner dès le départ ces équilibreurs de charge pour une utilisation en période de pointe et de créer des scripts complexes pour permettre à ceux-ci d’agir sur la mise à l’échelle de ressources créées dans AWS Outposts. Avec la mise à disposition des équilibreurs de charge ALB sur AWS Outposts, cette fonction peut être déplacée dans l’environnent AWS. L’ALB se met à l’échelle (basé sur la capacité Outpost disponible) et est intégré avec les groupes Auto-Scaling permettant la mise à l échelle des instances cibles. Il s’intègre aussi avec Amazon Route53 pour gérer la résolution DNS des adresses Co-IP de l’ALB.

Bien que l’ALB puisse être utilisé pour équilibrer la charge pour les applications conteneurisées exécutées dans Amazon ECS et Amazon EKS, dans cet article, nous nous concentrerons sur des instances cible Amazon EC2. Nous illustrons le déploiement d’un ALB dans un AWS Outpost qui pointe vers un target group de serveurs web et dont la mise à l’échelle peut se faire via un groupe Auto Scaling. Le trafic est généré depuis un environnement on-premises, pointant sur le nom DNS de l’ALB qui équilibre la charge entre les instances dans le target group. Quand le trafic entrant excède la capacité de l’ALB initialement déployé, l’ALB va se mettre à l’échelle. Nous ne montrons pas le groupe Auto Scaling se mettre à l’échelle, puisque c’est une fonction standard. Vous trouverez plus d’informations sur ce sujet dans la documentation : Elastic Load Balancing et Amazon EC2 Auto Scaling – Amazon EC2 Auto Scaling.

Nous allons également examiner les considérations de dimensionnement d’AWS Outposts et les pré-requis pour l’ALB. Ce sont des éléments auxquels on ne pense pas d’habitude lorsque nous opérons dans une Région AWS. Cependant, dans un Outpost, la capacité est liée aux ressources disponibles dans le rack (ou les racks). Enfin, nous nous intéresserons au coût de la solution.

Différences avec un ALB Régional

Il y a des particularités liées à AWS Outposts qui doivent être considérées lors du déploiement d’un ALB. Elles se divisent en six catégories :

  • Ressources de l’ALB – L’ALB doit consommer des instances EC2 fournies par l’AWS Outposts. Il peut être déployé sur des instances EC2 de type C5, C5d, R5, R5d, M5 ou M5d, et en requiert au minimum deux pour assurer la résilience. Il consomme initialement deux adresses IP depuis le sous réseau Outposts dans le VPC. Vu qu’il équilibre la charge sur site, il a besoin de deux adresses IP Elastic du pool CoIP,
  • Mise à l’échelle de l’ALB – L’ALB requiert deux instances additionnelles de taille supérieure par rapport à la taille courante pour pouvoir se mettre à l’échelle. Ces nouvelles instances doivent être disponibles en plus des instances existantes. L’ALB a aussi besoin de deux autres adresses IP Elastic du pool CoIP. Une fois l’ALB mis à l’échelle et les ressources originales libérées, toutes ces ressources restent utilisées pendant un certain temps.
    Par exemple, si l’ALB se déploie initialement sur des instances c5.large, il doit y avoir des instances c5.xlarge pour qu’il puisse se mettre à l’échelle. Cette mise à l’échelle se poursuit verticalement jusqu’à utiliser des instances c5.4xlarge, au-delà, l’ALB ne peut plus ajouter des instances de taille supérieure pour continuer sa mise à l’échelle. L’ALB va devoir se mettre à l’échelle horizontalement et donc ajouter des instances supplémentaires. Il est important de noter que quel que soit le type d’instance utilisé initialement, la même famille EC2 sera utilisée au fur et à mesure de son évolution. ALB choisit toujours les ressources dans un ordre spécifique. Les instances c5 sont utilisées en premier, puis si aucune instance c5 n’est disponible, d’autres familles d’instances prises en charge sont utilisées. Vous ne pouvez pas influencer l’ALB pour utiliser des instances m5 si vous disposez d’instances c5. Il est important de s’en souvenir lors du dimensionnement de l’Outposts,
  • Défaillance de l’ALB – Si l’ALB tente de se mettre à l’échelle et les ressources nécessaires ne sont pas disponibles dans l’Outpost, la mise à l’échelle échouera. L’ALB notifie son impossibilité à se mettre à l’échelle via l’AWS Personal Health Dashboard et continue d’équilibrer la charge avec ses ressources actuelles,
  • Serveur Web et mise à l’échelle – Lorsque les valeurs seuil spécifiées au niveau du groupe d’Auto scaling sont atteintes, l’Auto scaling se met à l’échelle en ajoutant des instances dans le groupe cible. Cependant, s’il n’y a plus de capacité suffisante dans l’Outpost, le groupe AWS Auto Scaling ne mettra pas à l’échelle les instances de l’application. Si un serveur web tombe en panne, l’instance en panne quitte le groupe AWS Auto Scaling et est remplacée par une nouvelle. Ceci continue jusqu’à ce que la taille du groupe cible atteigne à la valeur seuil du groupe Auto Scaling,
  • Cibles ALB – Un ALB envoie le trafic aux cibles sur l’Outpost où il est déployé (en utilisant les noms d’instances), et aux addresses IP des cibles déployées sur site. Elles sont spécifiées dans un “groupe d’instances cible”. Cependant, il ne peut pas transférer le trafic à des cibles situées dans une Région AWS, même en utilisant leurs adresses IP. L’ALB est conçu pour équilibrer la charge au sein de l’Outpost ainsi que sur les ressources sur site. Si un équilibreur de charge régional est requis, un ALB doit être créé dans la Région AWS plutôt que dans l’Outpost,
  • Résolution DNS – Quand l’ALB est accessible par des ressources sur site, la résolution DNS fournit l’adresse CoIP pour l’ALB plutôt qu’une adresse IPv4 publique. Il est toujours possible de résoudre le nom de l’ALB sur Internet (comme avec un ALB dans une Région AWS) via les points de terminaison Route 53 publics et via les points de terminaison Amazon Route 53 Resolver au sein d’un VPC. Les services sur site qui doivent résoudre cette adresse peuvent le faire de deux manières. La même réponse est donnée dans chaque cas : l’adresse CoIP de l’ALB. Il est important d’utiliser le nom DNS de l’ALB, plutôt que des adresses IP, celles-ci pouvant changer lors d’une mise à l’échelle ou suite à un incident.

Considérations générales pour planifier la capacité d’AWS Outposts

Une des principales différences lors de l’utilisation d’AWS Outposts est la quantité finie de ressources disponibles. Une fois ces ressources consommées toute tentative pour lancer des ressources additionnelles recevront le message “insufficient capacity error”. Lors de la planification des ressources de l’AWS Outposts, il est important de ne pas utiliser 100% des ressources disponibles mais de prévoir une capacité de réserve en cas de panne matérielle. De la même manière que l’on réserve de la capacité additionnelle sur site, il faudra planifier la capacité de votre AWS Outposts en fonction du pic d’utilisation, plutôt que pour la moyenne. Lors de la planification de la taille nécessaires des AWS Outposts, les ressources spécifiques à l’ALB doivent être considérées en plus des autres ressources, afin qu’une capacité suffisante soit disponible pour couvrir les instances du groupe cible et de l’ALB.

De plus, l’ALB doit être pris en compte lors de la définition d’une taille de pool CoIP. Ces pools peuvent utiliser une plage CIDR de /26 à /16 (soit 60 à 65 000 adresses utilisables). Dans le cas d’une utilisation intensive de l’ALB, alors au moins quatre adresses CoIP doivent être disponibles pour chaque ALB déployé. Cela est vrai à la fois pour les activités en régime de croisière ou pour les activités de mise à l’échelle (Le nombre réel peut être plus élevé car l’ALB, au cours de sa mise à l’échelle, passe par deux étapes et donc provisionne des nouvelles instances deux fois avant de pouvoir libérer les plus petites instances dans le pool). Il est donc important d’avoir une capacité de réserve dans le pool CoIP, car la mise à l’échelle de l’équilibreur de charge échoue s’il est incapable d’attribuer une adresse CoIP. L’espace d’adressage doit également être pris en compte pour le choix du sous-réseau VPC, bien qu’il soit généralement plus flexible à attribuer.

Présentation de l’architecture

Dans cet environnement, un ALB est déployé sur une paire d’instances r5.large, au sein d’un sous-réseau AWS Outposts. Ces instances sont déployées lors de la configuration de l’ALB, car aucune instance m5.large ou c5.large n’était disponible. La famille R5 a donc été utilisée. Chaque instance ALB a une CoIP associée et Route 53 les résout pour l’environnement sur site. Les CoIP ont été attribuées au moment de la création en choisissant un ALB avec des adresses IP externes, puis en choisissant le pool CoIP comme ressource qui fournit les adresses. Ces ALB transmettent le trafic à un groupe de deux serveurs Web (dans ce cas, des instances Amazon Linux 2 exécutant Nginx en tant que de serveur Web cible), au sein d’un groupe cible, configuré avec un groupe Auto Scaling. Ce groupe est défini pour se mettre à l’échelle entre deux et huit instances avec une valeur souhaitée de deux et une métrique de mise à l’échelle basée sur RequestCountPerTarget. La capacité de l’ALB évolue au fur et à mesure que le trafic augmente, sur la base d’un algorithme dynamique qui prend en compte le nombre et la taille des requêtes. Le trafic est généré à partir d’un environnement sur site se connectant aux AWS Outpost via une LGW. Les générateurs de trafic dans notre cas utilisent le logiciel wrk2, un générateur de trafic HTTP open source disponible sur GitHub.

Dans le processus de configuration qui suit, nous avons mis en évidence les étapes qui concernent spécifiquement l’ALB sur les AWS Outposts. Nous ne rentrerons pas dans les détails sur la façon de configurer les groupes cibles, le groupe Auto Scaling ou les modèles de lancement. Ceux-ci sont couverts dans la configuration générale d’un ALB, et ils ne diffèrent pas lorsque vous travaillez avec AWS Outposts.

Le schéma suivant résume l’ensemble de ces éléments :

Configuration

Si vous n’êtes pas familier avec la configuration d’un équilibreur de charge ALB avec des groupes Auto Scaling, vous pouvez l’essayer dans une Région AWS pour vous habituer au processus. Une fois familier avec les étapes, vous pouvez procéder à la configuration d’un ALB sur AWS Outposts. Il existe un didacticiel sur la mise à l’échelle automatique dans l’ALB : Configuration d’une application dimensionnée et à charge équilibrée. L’ordre dans lequel vous commencez la configuration est très important. Les composants doivent être configurés dans l’ordre suivant :

  1. Créez un groupe cible. Celui ci est utilisé à la fois par l’ALB et le groupe Auto Scaling,
  2. Créez un ALB et pointez-le sur le groupe cible,
  3. Créez un modèle de lancement. Cela indiquera au groupe Auto Scaling ce qu’il doit faire lorsqu’il provisionne une instance,
  4. Créez un groupe Auto Scaling et associez-le à votre ALB, au groupe cible et au modèle de lancement utilisé.

1. Création du groupe cible

Il s’agit d’un groupe cible standard, mais assurez-vous que le VPC que vous sélectionnez dispose d’un sous-réseau dans votre Outpost.

2. Création de l’ALB

Une fois que le groupe cible existe, configurez un Application Load Balancer. Cela se fait exactement de la même manière que la configuration dans une Région AWS. Pour que l’ALB soit accessible depuis l’infrastructure sur site, son type doit être «accessible sur Internet». À ce stade, vous pouvez sélectionner un pool d’adresses IP. Une fois que vous avez attribué un pool CoIP, vous ne pouvez déployer l’ALB que sur des sous-réseaux au sein des Outposts AWS associés à la passerelle locale (LGW).

Il convient de noter que même si le type d’ALB sélectionné soit « accessible sur Internet », il n’a en fait aucune connexion publique externe. C’est juste un moyen de pouvoir sélectionner le pool d’adresses IP Elastic à utiliser. Dans le cas d’AWS Outposts, il s’agit du pool CoIP, qui est le plus souvent une plage d’adresses IP privées.

Après avoir préalablement créé le groupe cible, vous devriez pouvoir y faire pointer l’ALB et créer la liste des instances dont on va équilibrer la charge. Cependant, à ce stade, il n’y a pas d’instance dans le groupe cible. Cela se produit une fois le groupe Auto Scaling créé.

Une fois l’ALB créé, vous retrouvez alors son nom DNS dans la description. Ce nom DNS est « résolvable » depuis Internet et correspond au nom vers lequel les instances sur site sont pointées.

3 – Création du modèle de lancement

Avant de créer le groupe Auto Scaling, vous devez créer un modèle de lancement pour renseigner les types d’instance et la configuration que le groupe Auto Scaling utilise lorsqu’il provisionne des instances. Cela se fait de la même manière qu’au sein d’une Région AWS.

4- Création du groupe Auto Scaling

Une fois les trois éléments créés, il est alors possible de configurer le groupe Auto Scaling. Le groupe Auto Scaling doit cibler toutes ses instances en tant qu’instances à la demande. N’oubliez pas que lorsque vous choisissez votre type d’instance principale, il doit s’agir d’un type qui existe sur votre AWS Outposts. Vous pouvez également utiliser cette liste pour contrôler les types d’instances que le groupe Auto Scaling peut créer, en limitant la possibilité qu’il entre en conflit avec d’autres besoins en ressources au sein des Outposts. Sélectionnez ensuite le sous-réseau VPC et AWS Outposts uniquement comme cible. L’équilibrage de charge doit être activé et qui pointe vers le groupe cible que vous avez créé à l’étape 1.

Définissez maintenant la taille du groupe requise et créez une stratégie de mise à l’échelle de type « suivi de cible » qui permet au groupe Auto Scaling de calculer la mise à l’échelle en fonction du nombre de requêtes reçu depuis l’ALB. Dans notre cas, nous avons configuré le seuil à 650 000 requêtes par seconde. Enfin, assurez-vous que les instances ont le temps d’être prêtes avant de les ajouter au groupe Auto Scaling.

Vérification de la configuration

Une fois que tout cela est terminé, l’ALB doit être provisionné, puis utiliser le groupe Auto Scaling pour lancer les instances de votre application à partir du modèle de lancement. Ici, parce que nous avons choisi une capacité souhaitée de deux, il devrait y avoir deux serveurs Web principaux lancés au sein d’AWS Outposts.Les captures d’écran qui suivent montrent la configuration du groupe Auto Scaling, les instances lancées par le groupe Auto Scaling et le groupe cible ALB. Si vous vérifiez, les instances lancées par l’ALB doivent avoir le même ID que celles du groupe cible.

Configuration groupe Auto Scaling

Instances dans le groupe Auto Scaling

Instances dans le groupe cible

Vérification de la résolution du nom

À partir d’un serveur Linux sur site, nous pouvons maintenant vérifier les adresses résolues pour l’ALB. Nous envoyons une requête en utilisant le nom DNS de la configuration ALB, et nous obtenons deux résultats. Il s’agit de deux CoIP associées aux instances ALB.

Si nous essayons d’accéder au serveur Web à partir de cette adresse, nous recevons une réponse de l’un des hôtes Nginx qui se trouve dans le groupe Auto Scaling.

Tester la mise à l’échelle de l’ALB

Comme mentionné précédemment, l’ALB peut automatiquement se mettre à l’échelle comme nous l’illustrons par la suite. Nous avons utilisé wrk2 comme générateur de trafic depuis nos infrastructures sur site pointant vers le nom DNS de l’ALB. Nous avons exécuté plusieurs processus en parallèle depuis le générateur de trafic, afin de voir si la charge était équilibrée de manière égale entre les serveurs Web Nginx. Au fur et à mesure que nous augmentons la charge de trafic, l’ALB évolue et nous constatons que les adresses du nom DNS de l’ALB résolu changent. Cela est dû à la mise à l’échelle de l’ALB des instances r5.large vers r5.xlarge. Comme vous pouvez le voir, les adresses résolues en réponse à une requête dig ont changé.


Cependant, la réponse à la requête Web est la même, car ce sont les serveurs Nginx qui répondent, et non l’ALB.

Étant donné que l’ALB appartient à un compte de service AWS, vous ne pouvez pas voir les instances dans la console EC2, mais vous pouvez voir les ENI, tout comme dans une Région AWS. Il y a quatre ENI ici car c’était après un événement de mise à l’échelle, deux sont associées aux instances r5.large et deux aux r5.xlarge.

Cependant, puisqu’il s’agit d’un AWS Outpost, vous pouvez obtenir une vue des instances en examinant l’utilisation du nombre total d’instances au sein de l’Outpost. Dans ce cas, nous pouvons voir qu’avant le début de notre test, aucune instance r5.large n’était utilisée (ligne bleue). Il y avait 25 % des ressources r5.xlarge disponibles déjà utilisées, mais cela provenait d’un autre utilisateur. Cela peut ne pas être pertinent dans un large déploiement d’AWS Outpost. Il peut être suffisant de suivre l’occurrence de l’événement dans CloudWatch. Il convient de souligner que lorsque vous testez initialement l’ALB, vous voyez l’impact de sa mise à l’échelle.

Au début du test, env. 10h50, un ALB a été créé, prenant 25 % de la ressource disponible. Puis, à env. 11h50, un événement de mise à l’échelle a lieu où 25 % supplémentaires des r5.xlarge disponibles ont été utilisés, par la mise à l’échelle de l’ALB. Après environ une heure, l’ALB a décidé qu’il devait garder son échelle sur r5.xlarge. Ensuite, il rend les ressources r5.large dans le pool de capacité disponible.

Pour voir le trafic qui a causé la mise à l’échelle, nous pouvons utiliser CloudWatch pour examiner le nombre de requêtes dans le groupe cible. A env. 11h50, le nombre total de requêtes a dépassé le million, ce qui est probablement à l’origine de la mise à l’échelle. Cet augmentation de trafic se produit par intermittence pendant l’heure suivante. L’ALB décide donc de se maintenir sur les instances r5.xlarge et de libérer la plus petite taille d’instance. Il est également possible de voir que les requêtes par cible représentent la moitié du total des requêtes, correspondant à nos attentes, puisqu’il y a deux instances dans le groupe cible.

L’ALB évolue d’un type d’instance large jusqu’à une instance 4xlarge, au sein d’une famille, tant que cette ressource est disponible. Cependant, étant donné qu’il s’agit d’un AWS Outpost, il a une capacité fixe. Il se peut qu’il n’y ait pas d’instances de la prochaine taille disponible pour la mise à l’échelle.

Si tel est le cas, un événement est enregistré dans le tableau de bord de santé personnel https://phd.thinkwithwp.com/phd/home, afin que vous puissiez voir à quel niveau la mise à l’échelle s’est arrêtée. Il est important de se rappeler que la famille d’instances choisie en premier (M5, C5 ou R5) est la famille dans laquelle l’équilibreur de charge évolue. Cela signifie que s’il se déploie dans une instance m5.large, il va évoluer dans la famille m5, via m5.xlarge, m5.2xlarge et m5.4xlarge. Si l’une de ces types d’instances n’est pas disponible, il arrête la mise à l’échelle et passe à une autre famille d’instances.

Un exemple d’un tel événement peut être vu dans la capture d’écran suivante :

Et l’onglet ressources affiche l’ALB concerné :

Coûts

Les coûts liés à la mise en œuvre de l’ALB sont généralement divisés en deux domaines :

  • Le service ALB lui même
  • Les instances sur lesquelles il fonctionne

Dans une Région AWS, ces frais sont facturés à l’heure pour le service ALB, plus des frais d’unité de capacité d’équilibrage de charge (LCU) qui couvrent effectivement le coût de la ressource sur laquelle ce service ALB s’exécute.

Dans AWS Outposts, étant donné que toutes les instances sont achetées dans le cadre du service AWS Outposts, il n’y a qu’une facturation ALB à l’heure pour le service.

De plus, les serveurs d’application Web (dans ce cas, Nginx) reposent sur des ressources dans les AWS Outposts qui sont déjà achetées dans le cadre du service AWS Outposts. Dans notre cas, parce que nous avons utilisé un logiciel open source pour agir en tant que serveur Web, cela signifie qu’il n’y a aucun coût supplémentaire pour les instances (puisqu’elles sont couvertes par les frais AWS Outposts). Cependant, si vous utilisez AWS Marketplace ou un serveur Web tiers avec un coût de licence associée, vous devrez toujours payer pour cela… seule l’instance EC2 est déjà couverte.

Conclusion

Comme vous avez pu le voir, ALB sur AWS Outposts suit le même modèle et fonctionne comme un ALB dans une Région AWS, au fur et à mesure que de nouvelles fonctionnalités sont ajoutées sur ALB au sein d’AWS Outposts, elles deviennent automatiquement disponibles. Vous pouvez vérifier les fonctionnalités non disponibles dans ce lien . L’objectif principal de l’ALB est de fournir une connexion résiliente, évolutive et à faible latence entre les ressources sur site et AWS Outposts, et d’économiser le provisionnement d’un équilibreur de charge en dehors de l’environnement AWS. Cela signifie qu’il est possible d’intégrer plus étroitement les groupes cibles et de répondre aux exigences de débit et de performance.

La capacité de l’ALB à équilibrer la charge des cibles sur site signifie qu’il peut être utilisé de deux manières. Il peut fournir une évolutivité et une résilience aux charges de travail AWS, et également permettre la résilience pour des charges de travail sur site. Tout cela peut être fait sans avoir besoin de créer des équilibreurs de charge physiques dans vos environnements sur site.

Article original contribué par Luis Felipe Silveira da Silva et localisé par Yécine Allouache, Solutions Architect dans les équipes AWS France.