Comment Accor a basculé son système de réservation sur AWS
Publié par Alain Clapaud le | Mis à jour le
La plateforme de réservation du groupe Accor, TARS, est exploitée sur AWS.depuis fin 2023. Une migration à haut risque menée avec succès sans rupture de service grâce à une approche de type Blue/Green. Retour d'expérience.
Filiale à 100% d'Accor, D-Edge assure l'exploitation de TARS (The AccorHotels Reservation System), la plateforme de réservation du groupe hôtelier.
Cette plateforme traite toutes les réservations des 5 600 hôtels du groupe et sur l'ensemble des canaux de distribution.
Un composant logiciel de cette plateforme est particulièrement critique, c'est le moteur d'inventaire qui gère la disponibilité et les tarifs de l'ensemble des chambres des hôtels du groupe. Cela nécessite de partager énormément d'informations et s'appuyer sur un moteur de disponibilité qui répond à chaque demande.
Thierry Lefort, VP Engineering de D-Edge résume l'enjeu colossal lié à la migration de ce logiciel dans le Cloud : « Le but était de quitter une infrastructure on-premise et d'aller sur AWS sur un service dont la disponibilité est critique. Il s'agit d'une application déployée sur 220 serveurs, mobilisant 3 To de RAM et capable de répondre en moins de 100 ms à l'ensemble des requêtes. »
De nombreuses équipes ont été mobilisées chez Accor et D-Edge pour mener à bien ce projet, avec l'assistance d'Ippon technologies, un partenaire AWS et certifié sur les processus de migration vers AWS.
Outre les aspects Business et techniques, une contrainte forte pèse sur tous : le projet doit être bouclé avant le 31 décembre, les licences logicielles on-premise devant être renouvelées au 1er janvier...
Une migration de type Blue/Green est privilégiée
Damien Rollet, CTO de l'agence parisienne d'Ippon technologies et architecte Cloud participe au projet. Outre le Move to Cloud de l'application, le projet était aussi une occasion de la moderniser : « Il fallait aussi gérer un contexte organisationnel avec des périmètres de responsabilité différents. et s'inscrire dans le cadre du programme de migration Cloud Accor beaucoup plus large. »
Le projet est mené en appliquant le programme de migration MAP (Migration Acceleration Program) d'AWS, composé de plusieurs phases : l'Assessment, le Mobilize et enfin la phase Migrate/Modernize.
« Cette méthodologie de migration donne un cadre et nous apporte des avantages, notamment le support des équipes AWS pour la migration » explique Damien Rollet. Et d'ajouter : « Sur le planning initial du projet, tout a changé... sauf la date de fin que nous sommes parvenus à tenir, ce qui est un énorme succès pour Accor. Cela a nécessité un gros engagement des équipes Ippon, D-Edge et Accor. »
Lors de la phase d'Assessment, l'équipe projet va réfléchir à l'architecture cible et aux services managés AWS qui seront mis en oeuvre en remplacement des logiciels on-premise. Mais aussi à une manière de migrer qui allait exclure tout risque de rupture de service et problèmes de production une fois l'application migrée.
L'équipe veut disposer de la capacité de fonctionner en double flux et pouvoir mener une migration progressive hôtel par hôtel et opérer un roll-back totalement transparent pour les hôtels.
« Un élément clé de succès était d'élaborer un Business Case qui puisse convaincre la direction générale de lancer cette migration » explique Thierry Lefort, « Si le service tombe, Accor ne peut plus prendre de réservations du tout, ce qui représente 250 000 réservations et 50 millions de chiffre d'affaires par jour ! » Autant dire qu'une migration en mode Big Bang n'est pas envisageable.
Le mode de migration choisi est de type Blue/Green, avec deux environnements en parallèle : l'environnement on-premise d'un côté (Blue) et l'environnement cible sur AWS de l'autre (Green).
L'équipe garde la capacité de basculer son application de l'un à l'autre en fonction des tests à mener, jusqu'au moment où l'environnement Blue est arrêté. Ainsi, le moteur de disponibilité de TARS va fonctionner en « double Run » pendant près de 4 mois, le temps de préparer sereinement la migration.
« Nous avons fait des allers/retours de l'une à l'autre pour assurer le fine tuning de la plateforme » explique Thierry Lefort. « C'est une approche que nous avons pu défendre auprès de notre direction et expliquer que c'est en procédant comme cela que nous aurions une migration sans arrêt de service. » précise-t-il.
La priorité : automatiser les opérations
La procédure de roll-back transparente a permis aux équipes qui arrivaient le matin à 9h de basculer 100 hôtels sur AWS, réaliser un fine tuning sur cet échantillon , puis opérer un roll-back à 17h pour basculer sur le on-premise pendant la nuit etc.
« Nous avons travaillé dans ce mode pendant pratiquement 2 mois. Si nous n'avions pas adopté cette démarche et tenté une telle migration en Big Bang, nous nous serions retrouvés en incident de production dès le jour 1 ! » insiste le VP Engineering de D-Edge.
En termes de modernisation, l'application qui mettait en oeuvre un cluster Cassandra à basculé sur le service managé Amazon Keyspaces.
« Nous avons pu bénéficier du support d'AWS sur le tuning et valider que cela allait bien fonctionner. Nous avons aussi travaillé sur l'optimisation des tables de données. Un monitoring a été mis en place dès le début. » détaille Damien Rollet.
C'est bien évidemment le passage des VM aux conteneurs sous AWS Fargate qui a représenté la plus grosse évolution et a obligé à réfléchir sur l'organisation à mettre en place pour opérer la plateforme.
« On ne travaille pas de la même manière dans un contexte Cloud. Le rôle des équipes évolue. Il faut donc réfléchir à l'aspect organisationnel pour construire une trajectoire d'un état initial au démarrage du projet à l'état cible une fois que l'application est migrée. » argumente Thierry Lefort.
Une migration Blue/Green implique un haut niveau d'automatisation et implique un meilleur partage des responsabilités entre la partie infrastructure et développement que par le passé.
« La partie Dev est maintenant totalement autonome pour réaliser ses déploiements sous le contrôle de l'infra. Chacun a ses scripts Terraform. Avant, une mise en production pouvait prendre de 3 heures à 3 jours. Aujourd'hui, cela se fait en un clic. Nous avons énormément gagné en tranquillité et en autonomie. » précise Thierry Lefort.
La maîtrise des coûts du Cloud
Alors que l'infrastructure on-premise présentait des coûts d'infrastructures fixes et un Capacity Planning établi à l'avance, l'équipe D-Edge doit désormais gérer les coûts variables d'AWS.
« L'avantage de fonctionner en Blue/Green est de pouvoir tester les optimisations et d'avoir droit à l'erreur. Nous avons ainsi pu passer d'un usage de 3,4 To de mémoire à 2,6 To car en migrant vers AWS. »assure-t-il.
Son équipe a gagné en agilité et mené des optimisations qu'il n'était pas possible de mener sur une infrastructure on-premise. « Le monitoring permet de traquer finement le fonctionnement de l'application, mieux comprendre ce qui se passe en production et optimiser la plateforme. Cela permet de se projeter et d'évaluer l'impact d'une modification en termes de coût. »
Cette agilité et cette capacité d'optimisation a permis à l'équipe de tenir le budget pendant que les coûts du on-premise s'envolaient du fait de l'inflation...
En optant pour une migration de type Blue/Green, D-Edge a opté pour la solution la plus sûre, ce qui n'a pas empêché les équipes de tenir la deadline initiale.
L'ensemble des flux ont été basculés sur la nouvelle infrastructure fin novembre 2023 et jamais l'équipe n'a pu opérer de retour en arrière. L'infrastructure on-premise devait être maintenue en l'état jusqu'à fin décembre 2024, en cas de problème. Elle a finalement pu être décommissionnée en début d'année et les licences on-premise n'ont pas été renouvelées.
Photo : © DR