2020, quelques évos techniques chez Nofrag

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.

La genèse de Nofrag V2 – Présentation de l’Architecture Applicative

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Continuer la lecture de « La genèse de Nofrag V2 – Présentation de l’Architecture Applicative »

La genèse de Nofrag V2 – Introduction et Architecture Technique

Il y a quelques semaines, DrLoser  m’a suggéré de rédiger un papier sur le développement de la V2 de Nofrag, qui s’est étalé de début septembre 2017 avec un gros chantier sur le forum, suivi par le nouveau site de news, jusqu’à l’ouverture des nouveaux blogs courant janvier 2018.

L’idée est de rédiger une série d’articles présentant l’architecture technique et applicative, ainsi que des tutoriaux détaillant chaque composant.

A la fin de cette série d’articles, vous aurez à votre disposition un socle logiciel permettant de faire de la publication d’articles sur un site de news, l’hébergement d’un forum, de blogs pour les besoins d’une communauté.

On va commencer par une description de l’infrastructure, résumée par ce schéma.

Nous avons créé une machine virtuelle fonctionnant sur Ubuntu et dont l’image est positionnée dans une AMI. Cette AMI est un cliché de la machine à un instant T, qui a besoin d’être associée à une instance EC2 pour prendre vie. L’EC2, c’est le terme choisi par Amazon pour parler d’une machine virtuelle. La configuration de l’EC2 est de type t2.medium : 2CPU et 4Go de RAM. Cette EC2 est positionnée dans une Auto Scaling Group, qui est un composant permettant de paramétrer le nombre d’instance EC2 simultanées et du même coup protège notre infrastructure des plantages : si une EC2 plante, l’Auto Scaling Group se charge de redémarrer une instance avec son contenu d’origine dans l’AMI et une configuration lui permettant de récupérer le contenu qui a évolué depuis la création de l’AMI.

Car oui, si nous nous arrêtions là, à chaque redémarrage d’une instance, tout le contenu de la machine qui aura évolué entre temps est perdu. Il est donc nécessaire de gérer le stockage du contenu qui évolue et qu’on doit conserver.

Ainsi, pour le contenu des différents sites (Nofrag, Forums, Wiki, Blogs) , nous utilisons le produit S3 de Amazon, qui permet le stockage de données sur le cloud. Nous synchronisons régulièrement le contenu des sites sur S3, et lors d’un redémarrage de l’EC2, ce contenu est redescendu sur l’instance afin d’avoir les fichiers les plus récents.

L’adresse IP de nofrag.com est affiliée à l’Auto Scaling Group pour avoir accès en permanence à l’instance EC2 en cours depuis l’IP associée au nom de domaine.

Concernant la base de données, RDS (managée sous AWS), et sous MariaDB, elle n’est pas hébergée sur l’EC2 mais sur une machine dédiée, elle n’est pas dans l’Auto Scaling Group car elle se gère toute seule, notamment en terme de maintenance. Ce choix s’est fait pour des raisons de performances et de sécurité. Il s’agit d’une  t2.small : 1CPU et 2Go de RAM. De par l’utilisation de plusieurs caches, son taux d’utilisation est relativement faible.

Tout ce petit monde est défini dans une Availability Zone, qui permet de choisir le datacenter sur lequel sera stocké nos composants. On trouve également la notion de region, qui est la zone géographique où l’on héberge nos composants. Ces deux parties ne sont pas neutres car elles ont de l’influence sur la manière dont sont traitées les données légalement, et sur le montant de la facture. En effet, il est important de définir des zones et datacenters communs.

Rassurez-vous, nos données sont en Europe.

Bilan

Me concernant, j’ai trouvé hyper enrichissant l’utilisation du cloud Amazon, d’un point de vue personnel mais aussi professionnel. C’est très performant, quoique pas toujours clair.

Nous n’utilisons qu’une infime partie des fonctionnalités proposées, comme vous pouvez le voir dans cette petite liste. Si un jour on veut se lancer dans les learning machine, on a ce qu’il faut !

Voilà pour l’infrastructure technique, prochain article sur l’architecture applicative.