Devenez un architecte de solutions AWS

Eh bien... Presque ! Enfin, il vous reste une dernière chose à faire (et pas des moindres) : assurer la résilience du site une fois qu'il sera lancé. Cela signifie, le rendre résistant aux pannes, pics de visite… Si cela n'est pas fait, vous risquez de perdre le résultat de votre travail.

Revenons encore au diagramme d’architecture de notre projet. Est-ce que vous y voyez des choses qui peuvent mettre le site en danger ?

Ce sont les trois derniers éléments en bas à droite. Nous n’avons qu’une seule instance pour le serveur d’API et une pour la base de données. Cela expose le site à de l’indisponibilité (pannes, pics de visite…). Dans les prochains chapitres, nous allons étudier comment résoudre ce problème.

Explorez le concept de la haute disponibilité

Le serveur d’API est exposé à de potentiels ralentissements en cas de pics de visite (imaginez la vente e-commerce pendant les soldes 😁), voire de l’indisponibilité en cas de panne (on a tous connu ça avec son ordinateur 😅). Pour rendre résilient le site à ces deux cas, il faut mettre en place la scalabilité et la haute disponibilité. Nous en avons déjà parlé dans la partie 2, cela s’appuie sur l’utilisation de plusieurs instances EC2.

Pour y parvenir (voir ci-dessous), il faut exécuter l’application sur plusieurs AZ (au moins 2). Pour rappel, une AZ est un datacenter d’une région AWS. Si une instance ou la AZ elle-même tombe en panne, alors l’application reste toujours disponible.

A - Le serveur d’API est installé dans 2 instances réparties dans 2 AZ. Si une AZ tombe en panne, le site est toujours disponible.

Mettez en place de la haute disponibilité

Avoir plusieurs instances réparties sur plusieurs AZ n’est pas suffisant, il faut être capable de répartir les requêtes HTTP sur les instances de façon transparente pour les utilisateurs. De plus, lorsqu’une instance ou une AZ est indisponible, la charge doit être transférée automatiquement vers les autres instances. C’est là qu’intervient le service régional AWS Elastic Load Balancing (ELB), l’équilibreur de charge géré du cloud AWS qui permet : 

• d’exposer un point d'accès unique (DNS) à une application ;

• de répartir la charge sur les instances ;

• d'assurer la haute disponibilité sur toutes les AZ ;

• d’avoir des connexions HTTPS grâce à des certificats SSL.

Pour s’assurer de la disponibilité des instances et donc de la répartition du trafic, ELB effectue régulièrement des vérifications de l’état (health checks) de chaque instance sur une route et un port dédiés.

A - Le protocole, le port, la route et la période sont définis à la création de ELB.

B - Toutes les 5 secondes (par défaut), une requête HTTP est envoyée pour la vérification d’état sur un port et une route dédiés.

C - Une réponse HTTP avec statut 200 est attendue pour valider l’état.

Dans l’image ci-dessous, pour assurer le trafic réseau, il faudra configurer le groupe de sécurité des instances EC2 pour accepter uniquement le trafic entrant venant de l’ELB. Ce dernier devra également accepter le trafic entrant depuis Internet. Ainsi, ELB est accessible depuis Internet en HTTPS et il redirige le trafic HTTPS vers les instances EC2 en HTTP.

A - Trafic public sur Internet.

B - ELB et les instances EC2 communiquent avec leur IP locale via le réseau privé du VPC.

Voici ce que l’on obtient pour la configuration des groupes de sécurité :

Étudions les quatre types ELB proposés par AWS :

• Classic Load Balancer ;

• Application Load Balancer - ALB (v2) ;

• Network Load Balancer - NLB (v2) ;

• Gateway Load Balancer.

Classic Load Balancer

A - Les protocoles TCP (couche 4) et HTTP/HTTPS (couche 7) sont supportés pour les communications.

TCP et HTTP pour les vérifications d’état.

B - Le format du nom DNS est :  <id>.<region>.https://elb.amazonaws.com

Application Load Balancer - ALB (v2)

A - Les protocoles HTTP/2 (dont HTTP/HTTPS) (couche 7) et WebSocket sont supportés pour les communications. HTTP pour les vérifications d’état.

B - Le format du nom DNS est : <id>.<region>.https://elb.amazonaws.com

Il distribue automatiquement le trafic entrant sur différentes cibles. Chaque cible est une application exécutée sur EC2, ECS, Lambda ou des machines on-premises. ALB dispose d’écouteurs (listeners) correspondant à des règles de routage, pour rediriger le trafic vers la bonne cible, basées sur l’une des conditions suivantes :

• chemin d'accès (path),

• en-tête HTTP (header),

• hôte (hostname),

• chaîne de requête (query string).

A - ALB transmet la requête à la cible avec sa propre adresse IP. Il enrichit l’en-tête avec les informations réseau de l’utilisateur :

• X-Forwarded-For : Adresse IP de l’utilisateur

• X-Forwarded-Port : Port

• X-Forwarded-Proto : Protocole

B - Vous devez utiliser l’adresse IP privée.

Network Load Balancer - NLB (v2)

NLB fonctionne au niveau de la quatrième couche du modèle OSI. Il est dédié à des trafics TCP ou UDP très intenses (par exemple jeux en ligne), car il peut traiter des millions de requêtes par seconde (plus rapide que ALB !). Enfin, dans chaque AZ, l’instance NLB acquiert une adresse IP statique et peut être associée à une adresse IP Elastic.

A - Les protocoles TCP et UDP (couche 4) sont supportés pour les communications.

TCP/HTTP/HTTPS pour les vérifications d’état.

NLP fonctionne également avec des écouteurs et des groupes cibles.

A - Une règle d’un écouteur se base sur le protocole (TCP ou UDP) et le port de la destination. Le trafic est redirigé vers le groupe de cibles dédié.

Gateway Load Balancer

GLB fonctionne au niveau de la couche 3. Il permet de déployer, de mettre à l'échelle et de gérer des appliances virtuelles, telles que des pare-feux, des systèmes d'inspection approfondie des paquets (lien vers Traffic Mirroring). Il combine une passerelle réseau transparente (un point d'entrée et de sortie unique pour tout le trafic) et distribue le trafic tout en adaptant vos appliances virtuelles à la demande. Il utilise le protocole GENEVE sur le port 6081 pour communiquer avec elles.

Par défaut, les requêtes d’un utilisateur ne sont pas assignées à la même instance. Par contre, pour des sites qui utilisent des données de session utilisateurs, cela est nécessaire. Uniquement supporté par CLB et ALB, il faut alors activer la fonction de session permanente (sticky session ou session affinity) pour permettre à l'équilibreur de lier la session d'un utilisateur à une cible spécifique., cCela se base sur l’utilisation d’un cookie basé sur : 

• l’application (généré par l’application cible ou l’équilibreur) ;.

• la durée (généré par l’équilibreur).

A - Le trafic de l’utilisateur #1 est toujours redirigé vers l’instance #1.

B - Le trafic des utilisateurs #2 et #3 est toujours redirigé vers l’instance #2.

Par défaut, la répartition en pourcentage du trafic distribué à chaque cible dépend du nombre de cibles dans toutes les AZ, comme indiqué ci-dessous :

Vous pouvez voir comment mettre en place de la haute disponibilité ici :

En résumé

• La haute disponibilité assure la constante disponibilité du back-end.

• Le service ELB assure la haute disponibilité dont voici un comparatif tiré de la documentation AWS :

 Dans le prochain chapitre, nous verrons comment mettre en place de la scalabilité !