2020, quelques évos techniques chez Nofrag

aws NF

Mise en contexte : 08h du matin, un samedi, on reçoit pour la n-ième fois un mail comme quoi le nombre de crédits EC2 de la machine est en baisse et s’approche inexorablement du moment où elle passe en mode dégradé (performances de merde).

Sauf qu’on est déjà sur une machine de type EC2 Large, qui répond à nos besoins 90% du temps.

Schéma de notre infra avant les modifications :

Les sites sont hébergés sur une machine (T2 Large) qui pointe vers la base de données.

Donc l’objectif de cet article, c’est de passer à cette infra.

aws NF

Petite description rapide. 

On passe à plusieurs EC2 de type T2 small (donc à l’unité moins chères que la T2 Large), dont le nombre varie en fonction du trafic, via l’utilisation d’un ASG (Auto Scaling Group). Les données communes aux EC2, à savoir les images du site et des blogs, sont à partager entre elles et stockées sur un espace EFS (Elastic File System), illimité en espace disque.

Pour répartir le trafic sur ces différentes instances EC2, on configure un load balancer, appelé chez AWS Elastic-Load Balancing (ELB).

Bascule des médias sur EFS

Pour cela, on crée un EFS sur AWS. Ca se fait en 3 minutes.

Ensuite, on se connecte à ce partage EFS sur la machine EC2 en cours :

mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,fsc [URL_EFS]:/ /mnt/efs

Puis sur chaque site, on copie les uploads vers un sous répertoire de /mnt/efs, et on remplace le répertoire uploads par un lien symbolique du même nom pointant vers /mn/efs/<sous-répertoire dédié au site>.

On modifie le fichier /etc/fstab pour se connecter au partage EFS dès le démarrage de la machine.

Et c’est tout ! Au passage, on réduit l’espace occupé par l’EC2 de 50 Go à moins de 10 Go. On recrée une image AMI, qui servira de point de référence pour nos petites EC2 auto-managées.

Création de l’Auto Scaling Group

Pour cela, on crée une « configuration de lancement » basée sur l’AMI nouvellement créée. On se contentera d’une typologie de type T2 Small. On pense à cocher la case « Supprimer à la résiliation » dans la partie Stockage, pour supprimer les volumes à chaque destruction d’EC2.

Ensuite, création de l’auto scaling group, avec pour configuration de lancement celle que l’on vient de créer à l’instant. Pour l’instant on la dimensionne à 1 avec une limite à 6, et on définit une stratégie de dimensionnement, qui va nous servir par la suite avec le load-balancer. On est parti sur un taux d’occupation CPU à 30%, ce qui permet de garder une quantité de crédits EC2 stables (ils commencent à descendre à partir de 20%).

Et ? C’est tout. L’auto scaling group se crée et lance une première EC2.

Création du load-balancer

Le load-balancer gère le trafic entre n EC2. Ces EC2 doivent être positionnées dans un ou plusieurs groupes cibles, qui sont ensuite contactés par le load-balancer pour prendre des appels HTTP/HTTPS.

Donc on commence par créer deux groupes cibles, un pour le http et un pour le https. On retourne ensuite dans l’auto scaling group nouvellement créé pour positionner le nom des deux groupes cibles dans la zone idoine de l’auto scaling group, afin que les EC2 soient déclarées immédiatement dans le groupe cible de l’ELB à leur création. Au passage, on active le « type de vérification de l’état » sur ELB : cela permet de se fier à la réponse du serveur nginx comme critère de bonne santé d’une EC2. Si nginx ne répond plus : on tue l’EC2.

Pour ce qui est de la création de l’ELB, c’est simple, on choisit un ELB de type « applicatif » qui va gérer le trafic http et https. Il faut savoir au passage que Amazon propose des certificats HTTPS gratuitement dès lors qu’on utilise un ELB. Donc on en profite, et on choisira de s’en remettre à AWS certificate manager pour la gestion du certificat HTTPS au niveau du load-balancer. On envoie tout le trafic http vers le groupe cible http, idem pour le https. Et c’est tout.

Lors de la création de l’ELB, AWS crée un nom de domaine de type .elb.amazonaws.com. Pour rediriger le trafic entrant vers l’ELB, il suffit d’ajouter une entrée de type CNAME dans le DNS qui va pointer vers ce domaine aws. Au passage on retire toutes les entrées A pour ne plus avoir d’accès IP directe pour le site nofrag.com. Pour notre part, on a fait ces modifications sur CloudFlare.

Et c’est tout.

Bilan

On gagne en robustesse. L’infrastructure s’adapte dynamiquement à la demande. Le graphe ci-dessous montre l’adaptation de l’auto-scaling group à l’occupation CPU sur 3 jours.

Nous avons fait un test de charge, qui s’avère plutôt correct. Pour les plus curieux, ça se passe ici.

Reste à voir l’impact en terme de coût, on verra ça dans quelques semaines.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.