Faire 30% d’économies en migrant dans le cloud !

Notre Client entité d’un groupe de grande distribution dédiée à la vente de billetterie de spectacles propose un catalogue permanent de plus de 15.000 références de manifestations à réserver en ligne pour des spectacles, places de concerts, parcs de loisirs, expositions ou événements sportifs.

Son site e-commerce est son principal vecteur de vente et doit être hébergé sur une infrastructure à haute disponibilité capable d’absorber de forts pics de fréquentation lors de ventes événementielles (vente d’un gros stock de billets d’une manifestation à une heure donnée).

Objectif de la migration Cloud

Dans le cadre de l’harmonisation de ses coûts, nous avons été mandaté par notre client pour une mission d’audit et d’accompagnement dans la modernisation et la migration dans le Cloud de son application legacy et de son infrastructure de Production on-premise afin d’être en mesure de :

• Réduire ses coûts par un dimensionnement sur mesure de l’infrastructure de Production calée sur son utilisation ponctuelle et non à son utilisation maximum.
• Augmenter la robustesse du site e-commerce initialement développé sur une architecture monolithique non redondée.
• Disposer d’une architecture scalable capable d’absorber son trafic présent et futur sans nouveau chantier technique.
• Absorber des pics de charges ponctuels (quelques heures) en rendant cette scalabilité rapide voire automatique.

Après une phase d’étude partagée avec la DSI du client, un plan de migration vers une architecture Cloud Ready a été proposée par STEAMULO dont voici les grandes lignes :

Solution Proposée

→ Découpage de l’application monolithique en différentes parties indépendantes :

• Ceci permettra le dimensionnement de chaque élément suivant ses propres besoins.

→ Migration sur un environnement virtualisé d’un Cloud provider ayant des data centers en France :

• Automatisation des tâches de provisioning, installation, configuration, déploiement de l’application via nos outils DevOps (Ansible / SteamEngine) et l’API du Cloud Provider.
• Passage d’un coût forfaitaire lié à l’infrastructure figée vers un mode “pay as you go” (facturation à la consommation réelle).

→ Consolidation de l’architecture en dupliquant des traitements sensibles

• Répartition des traitements sur plusieurs datacenters éloignés géographiquement.
• Robustesse et résilience aux pannes en cas de problèmes techniques sur un des centres.

Découpage de l’application en sous-ensembles (services) indépendants

Cette opération de décomposition de l’application initiale en sous-ensembles autonomes selon les règles SOA (Système Orienté Services) est primordiale pour bénéficier pleinement des avantages du passage sur une infrastructure Cloud.

En effet, pour une optimisation des ressources, l’architecture d’hébergement Cloud sera calquée sur l’architecture logique du système. Si un des services a besoin de plus de puissance, on adaptera en conséquence uniquement les ressources correspondantes et non l’infrastructure entière comme dans un système monolithique.

Chaque sous-élément doit pouvoir être clairement défini avec les caractéristiques suivantes:

• traitement effectué
• périmètre des données traitées
• interfaces d’échange avec le reste du système (API, webservices, bus de msg, fichiers, BDD)

Le travail de découpage applicatif est fortement dépendant de la qualité de l’architecture initiale et de la finesse du découpage attendu.

Voici quelques questions qui permettent de qualifier le travail à effectuer :

• Les services existants sont-ils stateless ?
• Les différentes briques du système sont-elles faiblement ou fortement couplées ?
• Les interfaces entre les différents sous-modules sont-ils clairement définies et documentées ?
• L’application utilise t elle la base de données comme “bus d’échange” entre blocs applicatifs ?
• Nombre et taille des services ?

Nous reviendrons sur ce sujet intéressant du découpage des applications en sous-services dans un article ultérieur.

Les sous-parties identifiées pour la 1er phase de migration de notre projet sont:

• Frontal Web
• Back-office d’administration
• Base de données clients, commandes, paiements
• Moteur de recherche des manifestations
• Contenu multimédia statique du catalogue

Les étapes de la migration

1. Provisionnement et Installation des nouvelles infrastructures/machines

• Provisionning et configuration via TERRAFORM des machines virtuelles dans l’environnement Cloud cible, homologation et documentation.
• Ecriture du code ANSIBLE d’installation de l’infrastructure: provisionning de VM, configuration , installation des applications.

2. Transfert des données de l’ancienne vers la nouvelle infra

• Ecriture et test des scripts de migration et reprise de données (BDD, fichiers statiques,..).
• Réalisation d’un 1er transfert de donnée “one shot” puis mise à jour par delta jusqu’à la bascule d’environnement pour limiter le down-time.

3. Ouverture des flux de données entrant et sortant

• Ouverture de l’infrastructure pour les flux entrants des partenaires
• Communication des IPs sortantes pour autorisation auprès des partenaires
• Test et validation de l’ouverture des flux

4. Installation des applications

• Mise en place du système de déploiement continu (CI/CD) automatisé sur les environnements d’Intégration, Pré-production et Production.

5. Recette du nouvel environnement

• Suivi lors de la Recette fonctionnelle par le Client des 3 environnements.
• Suivi lors des tests de Sécurité effectués par la DSI du Client sur la Production.
• Réalisation de tests de charge GATLING garantissant le trafic max absorbable par la plateforme de Production.

6. Bascule du trafic de l’ancien vers le nouvel hébergement

• Arrêt de l’ancienne application + message de maintenance
• Synchronisation des données vers la nouvelle infras
• Test du fonctionnement global
• Bascule DNS

7. Haute surveillance de la nouvelle infrastructure

• Surveillance et analyse journalière des metrics de la plateforme pendant 2 semaines.

Optimisation du coût de fonctionnement au passage à une infrastructure Cloud “à la demande”

Les coûts de fonctionnement de la nouvelles infrastructure ont significativement baissé suite à la migration. Le passage à un mode de “paiement à la consommation” a induit des nouvelles pratiques et des changements d’habitudes sur la gestion de l’hébergement (c’est ce que l’on regroupe sous le terme FinOps).

Mesurer et surveiller

• Mettre en place des outils de mesure de l’usage de chaque ressources (VM, réseau, etc..)
• Mettre en place un reporting automatique régulier de la consommation.

Anticiper

• Anticiper les pics de charges pour instancier des VM à l’avance
• ex: La saisonnalité est par définition anticipable, l’allocation des ressources est du coup planifiable.

Optimiser

• Une réflexion sur “ressources long termes” versus “ressources à la demande” est primordiale en début de projet.

Bilan du Projet

• Le planning de migration à été respecté et le passage à un hébergement Cloud est un succès !
• Le provisionning, l’installation et la configuration des nouveaux environnements sont maintenant automatisés, gérés en version et testés comme un projet de développement classique (Infrastructure as Code).
• Les scripts d’installation, configuration de l’infrastructure et de déploiement (continu) du projet sont sans lock-in technique et permettent donc de changer de Cloud provider dans le futur si besoin.
• La baisse du coût d’hébergement obtenue est de l’ordre de 30%
• La mise en place de cette nouvelle architecture est la 1ère brique qui ouvre la voie vers de nouveaux chantiers d’optimisations :

→ Mise en place de l’auto-scaling ( augmentation / réduction automatique ) de ressources (VM) en fonction de leur utilisation.

→ Utilisation des modules de prédiction du trafic de la stack ELK utilisée pour le monitoring de l’application.

Détail de la Stack des outils utilisés

• CI/CD: Gitlab, Jenkins, SonarQube, Ansible AWX
• Provisioning: Terraform
• Configuration, déploiement: Ansible, SteamEngine, Molecule
• Monitoring: Beats/Graylog/Elastic/Grafana