Migration d'une infrastructure complète dans le cloud AWS

Migration d'une infrastructure complète dans le cloud AWS

Nous partageons dans cet article notre expérience sur le cloud AWS au sein du centre de service Omnilog à la FFF.

Nous y présenterons le projet et l'infrastructure cloud mise en place dans sa globalité.

 

 

 

Introduction sur le projet FFF de migration de leurs sites dans le cloud

Notre client a saisi l'opportunité de la refonte d’un nombre important de ses sites Internet (110 sites) pour réaliser une infrastructure dans le cloud AWS.

La fréquentation de ces sites varie entre les jours de semaine et le week-end. Les sites sont moins visités du lundi au vendredi. Le nombre des visites augmente de manière significative pendant le week-end, samedi et dimanche. Cette variabilité dans la fréquentation des sites est l’une des raisons du passage dans le cloud. Le besoin est d’y trouver une infrastructure élastique, qui peut grandir ou diminuer suivant la charge à tenir.

 

Présentation de la console AWS

La console AWS est l’interface web qui permet de gérer les services AWS.

Identification

Avant d’avoir accès aux service AWS il faut s'identifier en créant un compte ou en se connectant à cette adresse : https://aws.amazon.com/fr/

Figure 1Tous les services AWS sont visibles dans cette page de la console

 

Schéma fonctionnel de l'architecture AWS mise en place. Nous avons pu expérimenter et utiliser différents services AWS.

 

Liste des composants de l'architecture

Dans cette section, nous listons quelques services installés en décrivant leurs rôles dans l’application. Pour chaque service, vous trouverez une petite présentation, quelques notes ainsi que quelques écrans de la console AWS.

Route 53

Amazon Route 53 est le service de gestion de DNS dans le cloud AWS. Il permet de traduire des noms de domaines en IP internes à AWS et d'acheminer les requêtes arrivant sur ces noms de domaines vers les applications voulues.

Route 53 peut être configuré pour acheminer le trafic vers des serveurs EC2, des Load Balancers internes à AWS, des compartiments S3 ou bien des distribution Cloud Front.

Comment ?

1.Allez sur la console

2.Créer une hosted zone pour stocker des enregistrements DNS pour notre domaine. Exemple *.fff.fr

3.Ajouter un RecordSet et configurer son point de terminaison.

Figure 2 Un recordset dans la hosted zone *.fff.fr

Notre retour d’expérience

Nous utilisons ce composant pour déléguer la gestion de sous domaines en *.fff.fr par exemple (demo.fff.fr) à Amazon. Le nom de domaine de base fff.fr étant géré par une autre autorité. Nous avons renseigné dans le DNS de cette autorité tous les sous domaines que nous voulons être gérés par Amazon Route 53. Ainsi quand un utilisateur veut aller sur demo.fff.fr il est dirigé vers l’application hébergée sur le AWS.

Lien : https://aws.amazon.com/fr/route53/

 

Cloud Front

Amazon Cloud Front est le réseau de diffusion de contenu (CDN) de AWS.

Nous utilisons Cloud Front pour disposer d’un cache entre l’utilisateur final et les serveurs web de l’application. Dans le jargon Cloud Front on dit que le serveur web est “origin” d’une distribution Cloud Front. Cloud Front peut avoir pour “origin” un serveur web (EC2), un Load Balancer ou un compartiment S3.

Cloud Front nous permet de gérer un cache pour toutes nos ressources web avec la possibilité de configurer plusieurs comportements de cache en fonction des modèles de chemin d'URL.

Nous mettons en cache les ressources statiques : JS, CSS, images, Fonts, PDF … et les contenus dynamiques : les page PHP rendues en HTML. Les règles de comportement du cache nous permettent de mettre des durés de vies différentes pour chaque type de ressources.

Exemple très simplifié

www.demo.fff.fr/css/* -> 30 jours max

www.demo.fff.fr/*        -> 7 jours max

Comment ?

1.Aller dans la console

2.Créer une distribution

3.Configurer la distribution

Figure 3 Configuration de comportements Cloud Front suivant l'url de la ressource

 

Notre retour d’expérience

Nous utilisons Cloud Front pour forcer HTTPS en redirigeant toutes les requêtes HTTP vers HTTPS.

Pour un site à forte fréquentation, Cloud Front est un composant cher. Le coût de ce composant inclut :

  • Les données sortantes de Cloud Front vers l’utilisateur final,
  • Le nombre de requêtes http entrante,
  • Le nombre de requêtes https entrante.

Une bonne nouvelle cependant : le trafic entre AWS et Cloud Front est gratuit.

Quelques configurations du comportement du cache Cloud Front dépendent de l’application. Nous avons eu des comportements non voulus parce que nous avions oublié de déclarer un cookie de notre application dans une configuration.

Lien : https://aws.amazon.com/fr/cloudfront/

 

ELB

Elastic Load Balancing distribue automatiquement le trafic entrant sur plusieurs serveurs EC2. L’ELB détecte automatiquement la disponibilité et l'état de santé d’une EC2. Quand une EC2 n’est plus disponible l’ELB arrête d’y acheminer le trafic.

L’ELB permet d'associer durablement des sessions utilisateur à des serveurs EC2 spécifiques à l'aide de cookies. Le trafic est alors toujours acheminé vers les mêmes instances tant que l'utilisateur continue d'utiliser l’application.

 

Comment ?

1.Aller dans la console

2.Créer un ELB

3.Configurer Cloud Front (ou Route 53) pour avoir l’ELB crée comme Origin

4.Configurer l’ELB

 

Lien : https://aws.amazon.com/fr/elasticloadbalancing/

 

Auto Scaling

Auto Scaling permet de maintenir la disponibilité de l’application et d'augmenter ou diminuer dynamiquement et automatiquement le nombre de serveurs EC2 selon les conditions que nous avons défini dans sa configuration.

Les conditions d’ajout ou d'arrêt d’instances EC2 peuvent être dynamiques, sur des métriques comme le CPU moyen de toute les instances (Ajouter une machine si le CPU moyen dépasse 20 % pendant 5 minutes par exemple) ou bien être prévisible en suivant un calendrier (par exemple lancer 5 machines tous les dimanches à 18h00)

 

Comment ?

1.Aller dans la console

2.Créer un ASG

3.Configurer l’ASG

a.Renseigner un ELB dans la configuration de l'auto Scaling pour recevoir le trafic.

b.Renseigner le nombre minimum et le nombre maximum de machines

c.Ajouter des règles pour augmenter et diminuer le nombre de machines

d.Configurer un Launch Configuration : C’est dans ce dernier que nous indiquons quelle image nous voulons lancer dans l’auto Scaling et quelques autres options concernant le lancement des machines.

Figure 4 Configuration d'alarmes pour l'ASG

Notre retour d’expérience

Les machines de t2 ne sont pas adaptées à l’autoscaling. Le comportement du CPU (capacité variable) de ce type de machine rend le réglage de l’Auto Scaling difficile.

Réglage difficile en environnement d'intégration ou de pré production où le trafic ne correspond pas au trafic réel dans l’environnement de production. Nous avons dû mettre à jour les configurations de ce service après la mise en production et les retours sur la fréquentation réelle.

Lien : https://aws.amazon.com/fr/autoscaling/

 

RDS

Amazon Relational Database Service (RDS) est le service AWS qui permet de configurer et de gérer une base de données relationnelle.

RDS offre le choix entre 6 moteurs de bases de données : Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server. Amazon Aurora est la base de données relationnelle compatible avec MySQL créée par Amazon pour le cloud.

RDS offre une capacité ajustable (on peut changer l’instance type pour augmenter la RAM ou le CPU à la volée et en quelques minutes).

RDS permet d’automatiser des tâches de maintenance de SGBD : mises à jour et application des correctifs, sauvegardes, monitoring … etc.

 

Comment ?

1.Aller dans la console

2.Créer une instance RDS

3.Configurer l’instance RDS

 

Lien : https://aws.amazon.com/fr/rds/

 

Notre retour d’expérience

La possibilité de changer directement la capacité de la base de données a prouvé son utilité un dimanche soir de forte charge a rendu les sites inaccessibles. Un changement de la capacité de la BDD ce soir-là a permis de rétablir le service. Ce changement est très simple est peut se faire directement sur la console AWS.

RDS est l’un des composants les plus chers de l’infra de notre application (après Cloud Front).

Composant à risque dans une architecture « autoscallée », c’est le composant central qui peut faire goulot d'étranglement. Pour minimiser la charge sur RDS on peut utiliser des réplicas en lecture seul ou bien mettre un cache Memcached comme dans notre architecture.

 

ElastiCache

Amazon ElastiCache est le composant AWS qui offre un service de cache de données en mémoire. Il prend en charge deux moteurs : Redis et Memcached.

 

Comment ?

  1. Aller dans la console
  2. Créer et configurer un cluster Memcached ou un cluster Redis

 

Lien : https://aws.amazon.com/fr/elasticache/

 

Notre retour d’expérience

Simple et efficace : l’un des composants les plus simples à utiliser.

Robuste, aucune maintenance ni réglage supplémentaire depuis le lancement des sites.

 

DMS

Amazon Database Migration Service est le service qui permet de migrer les données entre des bases de données ayant le même moteur de stockage ou entre SGBD différents.

Il est simple à utiliser. AWS met à disposition un outil pour configurer correctement DMS : AWS Schéma Conversion Tool.

DMS exploite les logs binaires de la BDD source et ne bloque donc pas cette dernière pendant la migration.

On peut migrer les données en une fois comme on peut le faire en continu. DMS utilise les logs binaires pour répliquer en continue et en temps réel tous les changements de la BDD source.

Nous l'utilisons dans notre architecture pour répliquer en temps réel quelques tables d’une base de données Oracle dans le réseau interne de notre client sur un base de données MySQL dans le cloud.

Comment ?

1.Aller dans la console

2.Commencer un projet de migration

3.Configurer la source

4.Configurer la destination

5.Configurer l’instance de réplication

6.Configurer une tâche de réplication

7.Lancer la tache de réplication

 

Figure 5 DMS, configuration d'une tâche de réplication

 

Lien : https://aws.amazon.com/fr/dms/

 

Notre retour d’expérience

A nécessité du temps pour sa prise en main.

Robuste, très peu de maintenance depuis le lancement des sites.

  

EFS

Amazon Elastic File System fournit un stockage de fichier à utiliser avec les instances Amazon EC2 dans le cloud AWS. Nous l'utilisons dans notre architecture pour rendre quelques ressources (images, PDF, … etc.) immédiatement disponibles sur toutes les EC2 (serveurs web) de l’autoscaling. Si une image est uploadée sur un serveur, elle est mise dans l’EFS et elle est immédiatement accessible de toutes les EC2 qui ont monté l’EFS.

Quand l'autoscaling ajoute une nouvelle machine, l’EFS est montée sur cette machine et les fichiers partagés sont accessible depuis la nouvelle EC2 lancée.

Nous utilisons deux instance EFS : Un EFS de production et un EFS de backup. Les sauvegardes sont faites quotidiennement avec Amazon Data Pipeline, nous en parlerons plus bas.

 

Comment ?

1.Aller à la console

2.Crée un EFS

3.Monter l’EFS sur les EC2

4.Automatiser le montage de l’EFS à la création des EC2 en ajoutant une commande dans le fichier UserDate du Launch Configuration de l’Auto Scaling.

Lien : https://aws.amazon.com/fr/efs/

 

Notre retour d’expérience

Pas cher, on paye au GO stocké

Lent en lecture et en écriture quand beaucoup d’EC2 (faire attention à la gestion de la bande passante sur ce service).

 

Data Pipeline

AWS Data Pipeline est le composant qui permet de traiter et de transférer des données entre différents services AWS. Il nous permet de créer des tâches exécutées à intervalle régulier pour transfert des données entre composant AWS ou bien entre une source de données dans le réseau du client ver un composant AWS.

Nous utilisons ce composant pour effectuer une sauvegarde quotidienne de l’EFS de production avec une rétention de quelques jours.

Lien : https://aws.amazon.com/fr/datapipeline/

 

Notre retour d’expérience

Fiable, pas de modification de la configuration depuis le lancement des sites.

A nécessité un temps de prise ne main pour comprendre et tester.

 

Conclusion

Vous venez de survoler les quelques services que nous avons pu utiliser pour notre application. Quelques-uns de ces services sont très simples à utiliser. D’autre sont plus complexes et nécessitent un article entier pour entrer dans les détails de leur configuration.

Nous espérons par cet article avoir donnée une vision opérationnelle des composants AWS.

N'hésitez pas à nous demander des précisions sur l’application ou la configuration d’un service en particulier si vous en ressentez le besoin.

 

Hakim.

 

Ajouter un commentaire