Équilibrage de la charge avec AWS ELB

Bonjour à tous ! Aujourd'hui commence le cours «AWS pour les développeurs», c'est pourquoi nous avons organisé un webinaire thématique dédié à la présentation de l'ELB. Nous avons examiné les types de répartiteurs de charge et créé plusieurs instances EC2 avec le répartiteur de charge. Nous avons également étudié d'autres exemples d'utilisation.

Après avoir écouté le webinaire, vous serez :

• capable de comprendre ce qu'est l'AWS Load Balancing ;
• de connaître les types d'Elastic Load Balancer et ses composants ;
• d'utiliser AWS ELB dans votre pratique.

Pourquoi est-il important de maîtriser cela :

• c'est utile si vous prévoyez de passer les examens de certification AWS ;
• c'est une méthode simple de répartition de la charge entre les serveurs ;
• c'est un moyen facile d'ajouter Lambda à votre service (ALB).

La leçon ouverte a été présentée par Rishat Teregulov, ingénieur système dans une entreprise marketing spécialisée dans le développement et le maintien de sites web.

Introduction

Vous pouvez voir ce qu'est un Elastic Load Balancer sur le diagramme ci-dessous, qui présente un exemple simple :

Le répartiteur de charge reçoit les requêtes et les redistribue aux instances. Nous avons une instance distincte, des fonctions Lambda et un groupe d'AutoScaling (groupe de serveurs).

Types d'AWS ELB

1. Examinons les principaux types:

Classic Load Balancer. Le tout premier répartiteur de charge d'AWS, fonctionne au niveau 4 et 7 de l'OSI, prend en charge HTTP, HTTPS, TCP et SSL. Il fournit une répartition de charge de base entre plusieurs instances Amazon EC2 et fonctionne à la fois au niveau des requêtes et au niveau des connexions. Ouvrons-le (en gris) :

Ce répartiteur est considéré comme obsolète, il est donc recommandé de l'utiliser uniquement dans des cas particuliers. Par exemple, pour des applications construites sur le réseau EC2-Classic. En principe, rien ne nous empêche de le créer :

2. Network Load Balancer. Convient pour une forte charge, fonctionne au niveau 4 de l'OSI (peut être utilisé dans EKS et ECS), prend en charge TCP, UDP et TLS.

Le Network Load Balancer dirige le trafic vers des cibles dans Amazon VPC et est capable de traiter des millions de requêtes par seconde avec des latences extrêmement basses. De plus, il est optimisé pour gérer des modèles de trafic avec des charges soudaines et changeantes.

3. Application Load Balancer. Fonctionne au niveau 7, prend en charge Lambda, prend en charge les règles au niveau des en-têtes et des chemins, prend en charge HTTP et HTTPS.
Fournit un routage avancé des requêtes, axé sur la livraison d'applications construites sur des architectures modernes, y compris les microservices et les conteneurs. Oriente le trafic vers des cibles dans Amazon VPC en fonction du contenu de la requête.

Pour de nombreux utilisateurs, l'Application Load Balancer a d'abord remplacé le Classic Load Balancer, car le TCP est moins couramment utilisé que le HTTP.

Créons-en un aussi, ce qui nous donnera déjà deux équilibreurs de charge :

Composants de Load Balance

Composants généraux de Load Balance (communs à tous les équilibreurs de charge) :

• Politique de Journalisation d'Accès

— vos journaux d'accès à l'ELB. Pour effectuer les réglages, vous pouvez aller dans Description et sélectionner le bouton « Modifier les attributs » :

Ensuite, nous spécifions S3Bucket — un stockage d'objets Amazon :

• Scheme

— un équilibreur interne ou externe. L'idée est de savoir si votre LoadBalancer doit recevoir des adresses externes pour être accessible de l'extérieur, ou si c'est votre équilibreur interne ;

• Groupes de Sécurité

— contrôle d'accès à l'équilibreur. En substance, c'est un pare-feu de haut niveau.

• Sous-réseaux

— sous-réseaux au sein de votre VPC (et donc zones de disponibilité). Les sous-réseaux sont spécifiés lors de la création. Si VPC est limité à une région, les sous-réseaux sont limités aux zones de disponibilité. Lorsque vous créez un Load Balancer, il est préférable de le créer dans au moins deux sous-réseaux (cela aide en cas de problèmes dans une zone de disponibilité) ;

• Listeners

— vos protocoles de répartition de charge. Comme mentionné précédemment, pour le Classic Load Balancer, cela peut être HTTP, HTTPS, TCP et SSL, pour le Network Load Balancer — TCP, UDP et TLS, pour l'Application Load Balancer — HTTP et HTTPS.

Exemple pour le Classic Load Balancer :

Et dans l'Application Load Balancer, nous voyons une interface légèrement différente et une logique complètement différente :

Composants de Load Balancer v2 (ALB et NLB)

Examinons plus en détail les équilibreurs de charge de la version 2, l'Application Load Balancer et le Network Load Balancer. Ces équilibreurs de charge ont leurs propres caractéristiques composantes. Par exemple, un nouveau concept est apparu, celui des Groupes de Cibles — instances (et fonctions). Grâce à ce composant, nous avons la possibilité d'indiquer sur quel Groupe de Cibles nous voulons diriger le trafic.

En termes simples, dans les Groupes de Cibles, nous spécifions les instances où le trafic arrivera. Si dans le Classic Load Balancer vous connectez directement les instances à l'équilibreur, dans l'Application Load Balancer, vous devez d'abord :

• créer un Load Balancer ;
• créer un groupe de cibles ;
• diriger via les ports ou règles nécessaires le Load Balancer vers les Groupes de Cibles appropriés ;
• Dans les groupes cibles, vous assignez des instances.

Cette logique de fonctionnement peut sembler plus complexe, mais en réalité, elle est plus pratique.

Le composant suivant est Règles d'écoute (règles pour le routage). Cela concerne uniquement l'Application Load Balancer. Dans le Network Load Balancer, vous créez simplement un Listener, et il envoie le trafic à un groupe cible spécifique, tandis que dans l'Application Load Balancer, tout est plus gai et plus pratique..

Passons maintenant à quelques mots sur le composant suivant — Elastic IP (adresses statiques pour NLB). Si les règles pour le routage des Règles d'écoute ne concernaient que l'Application Load Balancer, l'Elastic IP concerne uniquement le Network Load Balancer.

Créons un Network Load Balancer :

Et c'est précisément lors de la création que nous verrons qu'il nous est donné la possibilité de choisir un Elastic IP :

Elastic IP fournit une adresse IP unique qui peut être associée à différentes instances EC2 dans le temps. Si une instance EC2 a une adresse Elastic IP et que cette instance est arrêtée ou terminée, vous pouvez immédiatement associer une nouvelle instance EC2 à l'adresse Elastic IP. Cela garantit que votre application actuelle ne s'arrête pas, car les applications voient toujours la même adresse IP, même si l'EC2 réel a changé.

Voici un autre cas d'utilisation sur le sujet du besoin d'Elastic IP. Regardez, nous voyons 3 adresses IP, mais elles ne resteront pas ici pour toujours :

Amazon les change avec le temps, peut le faire toutes les 60 secondes (mais en pratique, en général, moins souvent). Cela signifie que les adresses IP peuvent changer. Et dans le cas de Network Load Balancer, vous pouvez effectivement lier l'IP et l'indiquer dans vos règles, politiques, etc.

Faisons des conclusions.

ELB assure une répartition automatique du trafic entrant sur plusieurs cibles (conteneurs, instances Amazon EC2, adresses IP et fonctions Lambda). ELB peut répartir le trafic avec une charge variable à la fois dans une zone de disponibilité et entre plusieurs zones de disponibilité. L'utilisateur peut choisir parmi trois types de load balancers qui assurent à la fois haute disponibilité, auto-scaling et une protection correcte. Tout cela est important pour garantir la résilience de vos applications.

Les principaux avantages :

• haute disponibilité.. L'accord de service implique une disponibilité de 99,99 % pour le répartiteur de charge. Par exemple, plusieurs zones de disponibilité garantissent que le trafic sera traité uniquement par des entités fonctionnelles. En fait, il est possible de répartir la charge sur toute la région, en redirigeant le trafic vers des cibles saines dans différentes zones de disponibilité;
• sécurité. ELB fonctionne avec Amazon VPC, offrant différentes options de sécurité — gestion intégrée des certificats, authentification des utilisateurs et déchiffrement SSL/TLS. Cela garantit une gestion centralisée et flexible des paramètres TLS;
• élasticité. ELB peut gérer les changements soudains du trafic réseau. Une intégration approfondie avec l'Auto Scaling permet à l'application de bénéficier de ressources suffisantes en cas de changement de charge, sans nécessiter d'intervention manuelle;
• flexibilité. Des adresses IP peuvent être utilisées pour router les requêtes vers les cibles de vos applications. Cela assure la flexibilité lors de la virtualisation des applications cibles, permettant ainsi de déployer plusieurs applications sur une seule instance. Les applications peuvent utiliser un même port réseau et posséder des groupes de sécurité distincts, ce qui simplifie les interactions entre les applications, en particulier dans une architecture basée sur les microservices;
• surveillance et audit. Il est possible de surveiller les applications en temps réel en utilisant les fonctionnalités d'Amazon CloudWatch. Cela inclut les métriques, les journaux et le suivi des requêtes. Pour le dire simplement, vous serez en mesure d'identifier les problèmes et de localiser précisément les goulets d'étranglement de performance;
• répartition de charge hybride. La possibilité de répartir la charge entre les ressources locales et AWS en utilisant le même répartiteur simplifie la migration ou l'expansion des applications locales vers le cloud. Le traitement des pannes est également facilitée par l'utilisation du cloud.

Si vous souhaitez plus de détails, voici quelques liens utiles du site officiel d'Amazon :

1. Elastic Load Balancing.
2. Fonctionnalités d'Elastic Load Balancing.

Source : habr.com