Formation DevOps | Formation AWS Services : 7- Service LoadBalancer

APPLICATION LOAD BALANCER Elastic Load Balancer et Auto Scaling Groups

Application Load Balancer : répartiteur de charge

Ecoute sur un port en entrée
- Point d’entrée DNS(endpoint)
Redistribue vers des instances EC2 de back-end
Utilise un health-check pour écarter les
instances en panne
Distribution du trafic selon un algorithme
Pas de limite de trafic entrant / sortant

Application Load Balancer en région Irlande

Le trafic est distribué sur 3AZs

En cas de perte d’une zone, l’ALB vers les zonesréachemine automatiquement actives. le trafic

ALB : distribution du trafic sur des instancesdisponibles

Lorsque vous activez une zone de disponibilité, vous spécifiez un sous-réseau depuis cette zone :

» ElasticLoadBalancing crée un nœud d’équilibreur de charge dans la zone de disponibilité et une interface réseau pour le sous-réseau

» Chaque nœud d’équilibreur de charge de la zone de disponibilité utilise cette interface réseau pour obtenir une adresseIPv4

» Si accessible depuis internet, vous pouvez associer une adresse IP Elastic à chaque sous-réseau

» Si ELB interne, vous pouvez spécifier une adresse IP privée pour chaquesous-réseau

ALB : Internet facing vsInternal

Charge du trafic en entrée

Pas de limite de connexions en entrée
» L’ALB adapte sa charge dynamiquement
○ Possibilité de voir le nombre de pattes réseaux del’ELB
$ dig a <endpoint_ELB>
» Si on sait à l’avance que le trafic va fortement augmenter (x10)
○ Pre-warming : demander au support AWS d’augmenter la capacité (à faire quelques jours avantl’événement)

Endpoint DNS

Un ALB possède un endpoint DNS persistant
test-1520572891.eu-west-1.elb.amazonaws.com

Possibilité d’associer une URL à l’ALB à l’aide d’un enregistrement DNS

 [http://www.corp1.comin](http://www.corp1.comin) CNAME test-1520572891.eu-west-1.elb.amazonaws.com

L’URL reste accessible même si les IPs de l’CLB changement

CLB vs ALB
➢ CLB : legacy,EC2 classic, 1 application , tous les protocols (HTTP ,HTTPS, TCP ,TLS) , across-zone

➢ ALB : plusieurs applications, niveau 7, HTTP/2 , websockets,jusqu’au 100 règles

Listeners et Target Groups

Listener : socket en écoute sur un port TCP
» HTTP, HTTPS (secure HTTP), TCP, and SSL (secure TCP)
Redistribue vers un Target Group (ALB)
» Groupe d’instances
» Health Check pour tester l’état des instances
» Peut-être associé à un Auto Scaling Group
» Peut-être associé à un service ECS (Docker)
Règle de redirection : URL Path → TargetGroup
Exemple :
http://www.albendpoint.com/backoffice → TG instance admin
http://www.albendpoint.com/monitor → TG instance monitor
http://www.albendpoint.com→TG instancesdefront
Jusqu’à 1000 listeners et 100 règles par ALB
Rupture HTTPS/SSL
»Les paquets clients sont déchiffrés avant d’être distribués aux
groupes d’instances deback-ends
○Certificat SSL chargé dans la configuration de l’ALB, simplifie la gestion des certificats
○Permet de réduire la charge de traitement au niveau des back-ends

Health check

Permet à l’ALB de déterminer si une instance est prête à prendre du
trafic (Healthy, Unhealthy)
Nécessite de paramétrer des seuils (temps maximal d’attente d’une
réponse, nombre d’échec ou de succès consécutifs du check, etc.)

Health check : définition
○ Ping Protocol : comment se connecter à l’instance (HTTP ou HTTPS)
○ Ping Port : TCP (1 à 65535)
○ Ping Path : par défaut « / » (attend le success code)
○ Success code : 200, 301,etc.
○ Timeout (s) : attente maximale pour une réponse
○ Interval : attente entre chaque check (5s à5mn)
○ Unhealthy Threshold : nombre d’échecs consécutifs nécessaires pour qualifier une instance de « Un healthy»
○ Healthy Threshold : nombre de succès consécutifs nécessaires pour qualifier une instance de « Healthy »

Connection draining (activé par défaut)

Traite les connexions actives sur une instance avant qu’elle ne soit désassociée du Target Group
» Parce qu’elle est déclarée unhealthy ouderegistered
Aucune nouvelle connexion n’est autorisée
Les connexions existantes qui ne se termine pas sont coupées à l’issu d’un time-out
»300s par défaut (de 1 à 3600 secondes)

Idle timeout

Nouvelle connexion cliente = 2 nouvelles sockets
» Entre le client et l’ALB, entre l’ALB et leback-end
Aucun trafic pendant une certaine durée = fermeture des sockets (60s par défaut)
Conséquences
»Echec si le back-end répond au-delà de 60 secondes
○Solution avec back-end PHP : max_execution_time < 60
»Echec si le keep-alive du serveur web inférieur à 60
secondes
○Apache : KeepAliveTimout < 60
Bonne pratique
» ALB idle timeout > backend timeout

Sticky sessions

Perte d’un nœud = perte des cookies (sessions)
2 solutions
» Sessions partagées entre tous les nœuds(BDD)
» Sticky session = sessionaffinity
Associe un client à un back-end pendant une
certaine durée
»Utiliser par exemple pour maintenir une sessionWeb

Application gérant des sessions : perte d’un noeud
En cas de perte d’un nœud, connaissant pas le cookie de la l’utilisateur session est redirigé vers un : réinitialisation de la back session-end

Sticky sessions

Solution de contournement : associer un client à un back-end pendant une certaine durée
Utilise un cookie délivré par l’ALB
» Renvoyé au client et permet ultérieurement de conserver le mapping
client /backend
» Durée de vie du cookieparamétrable
» De 1 seconde à 7jours

Sticky session : utilisation du cookieAWSELB
Le cookie mémorise le mapping client <->back-end

** Bonne pratique : gérer les sessions en mode partagé (nosticky)**
En cas de perte d’un nœud, mesure de retrouver l’utilisateur le cookie est redirigé vers un desession back-enden

Access-logs ALB

Logs capturés par l’ALB
» Option àactiver
» Access logs type « Apache»
» Flush des logs toutes les 5 dans un bucket S3
» Log des requêtes faites à l’ALB(TCP)
○Timestamp, latence, IP cliente, request path, code retour,
user_agent, …

ALB : modification des en-têtes HTTP

Problème : les back-ends ne voient que les adresses IP de l’ALB comme adresses sources des paquets
Solution : l’ALB ajoute des informations dans le header HTTP
» X-Forwarded-For : @IP source duclient
» X-Forwarded-Proto: protocole utilisé à l’initialisation de la connexion
(HTTP, HTTPS)
» X-Forwarded-Port : portutilisé

Monitoring CloudWatch

Les plus importantes métriques
» TargetResponseTime(s)
○Temps que met un paquet à êtretraité
» RejectedConnectionCount
○Nombre de connexions rejetées car aucun back-end accessible
» NewConnectionCount
○ Nombre de nouvelles connexions (ALB etinstances)
Les métriques importantes :
» HTTPCode_ELB_5XX_Count
○ Nombre d’erreurs 5xx générées par l’ALB (pas lesbackends)
»HTTPCode_Target_ 2 XX_Count,
HTTPCode_Target_ 3 XX_Count,
HTTPCode_Target_ 4 XX_Count,
HTTPCode_Target_ 5 XX_Count
○ Nombre d’erreurs générées par lesbackends
Ref: https://docs.aws.amazon.com/elasticloadbalancing/latest/ application/load-
balancer-cloudwatch-metrics.html

Troubleshooting

Si l’instance ne passe jamais « healthy », vérifier que l’instance
répond correctement au Health check
» Vérifier que l’application est correctement démarrée sur l’instance et
qu’elle écoute sur son port applicatif:
$ netstat –pant | grep LISTEN
» Contrôle le code HTTP retour de l’application:
$ curl –I http://<adresse_IP_instance>

» Vérifier que l’instance n’est pas filtrée par un firewall (iptables)
» Vérifier que le SG de l’instance accepte les connexions de l’ALB et peut lui répondre (Inbound /Outbound)
» Vérifier que le SG de l’ALB autorise bien les connexions vers l’instance (Outbound)

Network Load Balancer ( NLB )
➢ Un équilibrage de charge TCP etUDP
➢ OSI (couche4)
➢ Hautes performances ( par millions)
➢ Latences ultra faibles < 100ms
➢ Préserve l’adresse IP source duclient NLB par région : 50
➢ Groupes cible par région : 3000*
➢ Écouteurs par NLB : 50
➢ Sous-réseaux par AZ et par NLB : 1
➢ Équilibreurs de charge par groupe cible : 1 Certificatspar NLB : 25

Bonnes pratiques

Monitoring
» Surveiller les métriques “sensibles”
» Créer des alarmes
Auditer avec CloudTrail les modifications de configuration de l’ALB
Security group des back-ends : autoriser les connexions de l’ALB
» Ne pas utiliser les @IPs de l’ALB : elles changent
» Utiliser le SG de l’ALB comme référence pour lasource
○Inbound rule sg-backend : allow HTTP fromsg-Alb
Sticky sessions
» Entravel’élasticité
» Privilégier un partage de session entre lesinstances
» Exemple pour Tomcat http://docs.aws.amazon.com/AWSSdkDocsJava/latest/
DeveloperGuide/java-dg-tomcat-session-manager.html

AUTO SCALING

Elasticité

Le trafic à destination d’une infrastructure varie dans letemps
Nécessité de garantir une performance constante :
infrastructure élastique

« Vertical scaling » : la puissance du serveurvarie
» Upgrade matériel : coupure deservice

Horizontal scaling : le nombre de serveurs varie
» Ajout et suppression de serveurs àchaud
» Possibilité de coller au plus près aubesoin

Mise à l’échelle automatique

S’assurer que le nombre de serveurs en ligne permettant d’encaisser la
charge est optimal
» Collection d’instances EC2identiques
» Leur nombre varieautomatiquement
» S’enregistrent (et se décomissionnent) automatiquement auprès d’un même load
balancer
○ Peuvent opérer sans load balancer
Auto Scaling Group
» Définir un typed’instances
» Définit les règles de mise àl’échelle
» Définit le service qui émet les statuts (ELB ouEC2)
Définir un type l’instance : Launch Configuration
» Modèle d’instance àdémarrer
○AMI, Type, key pair, SG, blockdevice
Définit les règles de mise à l’échelle
» Scale in policy : réduit le nombre deserveurs
○ Par exemple, CPU < 10% depuis 10 minutes
» Scale out policy : augmente le nombre deserveurs
○ Par exemple, CPU > 80% depuis 10 minutes
» Paramètres min, max, desired : encadre lenombre d’instances
3 types de check status
» ELB : HealthCheckELB
○Si échecs répétés, instance déclarée « unhealthy»
» EC2 : Status Checks de l’instance
○Si EC2 System Status = impaired ou EC2 Instance Status autre que « running », alors
instance déclarée « unhealthy»
» Custom
○Requête API à l’ASG pour passer les instancesen
« unhealthy»
Exemple avec (ALB)
» L’ALB distribue le trafic vers les groupes d’instances EC2 de l’Auto ScalingGroup
» Le Target Group détermine si une instance est
« healthy » ou « unhealthy»
» Utilise unhealth-check
○Par ex., GET HTTP « /index.html»
○Attend une réponse 200

Si l’instance est « unhealthy » :
» L’ALB cesse d’envoyer du trafic àl’instance
» Il informe l’Auto ScalingGroup
» L’Auto Scaling Group terminel’instance
» Puis agit en fonction des règles de scaling:
○ Nombre d’instances « min, max, desired »
○ Scale in & outpolicies

Modes de fonctionnement
» Mode Dynamique
» Mode programmé
» Mode manuel

Mode Dynamique : piloté par des alarmes CloudWatch

» Ex. pour une application Web:
○ Si la moyenne d’utilisation CPU de tous les serveurs dépasse 80%,
ajouter des nouvellesinstances
○ Si cette moyenne tombe en dessous de 40%, supprimer des instances
» L’alarme CloudWatch peut être associée àn’importe quelle
métrique
○ Une fileSQS
○ La latence d’un loadbalancer
○ …

Mode programmé : piloté par un calendrier (crontab)
» Ex. pour une application interne à l’entreprise:
○ Tous les lundi matin à 08:00, passer la capacité désirée à 1
○ Tous les vendredi à 20:00, passer la capacité désirée à 0

Mode manuel
» Changer le paramètre « Desired » pour obtenirle nombre d’instances désirées
○ Doit rester entre les bornes « Min » et « Max»
» Nouvelle fonctionnalité : rattacher uneinstance existante manuellement au groupe

Auto Scaling : cooldown

Période de temps pendant laquelle l’ASG suspend ses actions de
launch / terminate
» Donne le temps aux instances de démarrer ou de s’arrêter sans être
perturbée par l’ASG
» Donne le temps à l’ASG d’évaluer la nouvelle situation lorsqu’il démarre et
stoppe une instance

Auto Scaling : terminaison d’instance

Indiquer à l’ASG quelles instances termineren priorité
» Par défaut, l’instance avec la plus ancienne Launch Configuration dans l’AZ la plus peuplée
» Éventuellement au plus proche de la fin de l’heure facturée

Auto Scaling : opération sur les instances

Suspendre des processus spécifiques de l’ASG
» Utile pour diagnostiquer sans risquer de déclencher des actions
Suspension possible pour
» Launch, Terminate, HealthCheck, ReplaceUnhealthy,
AZRebalance, AlarmNotification, SheduledActions,
AddToLoadBalancer

Auto Scaling : opération sur les instances

Une suspension peut-être réalisée par AWS
» Par exemple si l’ASG ne cesse d’échouer à démarrer
des instance depuis24h
○« Administrative suspension»

Monitoring Auto Scaling Group

Notification des événements par SNS
» Démarrage d’instance, changement de capacité,etc.
CloudWatch : métriques consolidées des instances
» Une métrique pour toutes les CPU des instances du groupe

Decouvrez plus d’Offres de la plateform ItGalaxy.io :

Découvrez notre gamme complète de services et formations pour accélérer votre carrière.

1. Nous contactez

Description: Besoin de Formation et des Solutions cloud complètes pour vos applications
Links:
- Nous contactez

2. Infra as a Service

Description: Infrastructure cloud évolutive et sécurisée
Links:
- Demandez un devis

3. Projets Développeurs

Description: Découvrez des opportunités passionnantes pour les développeurs
Links:

4. Développeurs

Description: Rejoignez notre communauté de développeurs
Links:
- DevOps
- Web
- Backend
- SEO
- Design
- Mobile
- Wordpress
- Shopify

5. Formations Complètes

Description: Accédez à des formations professionnelles de haute qualité
Links:

6. Marketplace

Description: Découvrez notre place de marché de services
Links:

7. Blogs

Description: Découvrez nos blogs
Links: