Projets

Solocal choisit une base de données cloud managée pour PagesJaunes

---

Deux ans après avoir transféré en IaaS les bases de données MongoDB de PagesJaunes, Solocal les a migrées vers Atlas, la version administrée de MongoDB. A la clé, optimisation de l'infrastructure, forte automatisation des processus, autonomie renforcée pour les équipes internes, avec un SLA de 99,995% et un support 24/7 très réactif.

PublicitéPour optimiser son infrastructure, le site d'annuaire pagesjaunes.fr, navire amiral du groupe Solocal, a migré ses bases de données cloud MongoDB vers la version Atlas de la database, entièrement administrée par MongoDB. Le tout en restant sur le cloud public de Google. Trois objectifs ont guidé ce chantier: réduire les coûts d'infrastructure d'un déploiement IaaS qui reposait sur de nombreux clusters, disposer des mises à jour les plus récentes pour la base de données et renforcer l'axe cloud adopté par Solocal en accédant cette fois à tous les avantages d'un service managé: automatisation, meilleure réactivité, sécurité renforcée. 

La solution NoSQL de MongoDB a été retenue dès 2013 par PagesJaunes, installée au départ sur les propres serveurs de l'entreprise. Au fil des années, les équipes informatiques de Solocal sont montées en compétences sur cette technologie, nous a exposé David de Carvalho, architecte logiciel et chef de projet de la migration vers MongoDB Atlas. Pour couvrir le panel de fonctionnalités, le déploiement on-premise comportait une quarantaine de clusters, un cluster étant constitué de trois machines physiques gérant une base de donnée. Au total, plusieurs dizaines de millions de documents étaient ainsi pris en charge, avec de grosses performances demandées sur les requêtes de lecture, l'une des raisons qui avaient conduit à retenir MongoDB. « En 2017, nous sommes partis sur une mouvance cloud et nous avons commencé à migrer notre stack technique, nos API et nos bases de données sur la Google Cloud Platform », relate David de Carvalho. Pour les databases, cette migration s'est opérée en lift and shift, explique-t-il. C'est-à-dire que les clusters ont été transférés des serveurs physiques vers des machines virtuelles dans le cloud, en IaaS, mais la manière de les gérer n'a pas changé. « Nous avions gardé nos 40 clusters que nous maintenions et faisions évoluer, nos process et nos outils d'intervention », décrit le chef de projet. Pour PagesJaunes, ce transfert vers le IaaS a été l'occasion d'évaluer d'autres technologies, comme CosmosDB ou DocumentDB d'Azure, mais les tests de charge n'ont pas été concluants et les modifications à faire auraient été trop importantes.

Une équipe devops très sollicitée

Une fois dans le cloud, il a été décidé en 2019 d'optimiser l'infrastructure. A chaque base de données, un cluster était mis en place, quelquefois sur-dimensionné. Il fallait travailler à réduire ces coûts d'infrastructure qui comportaient en outre le temps passé par les développeurs et les différents profils techniques à assurer le monitoring de ces bases de données, à les maintenir et surtout, à les faire évoluer. Au total, entre coût d'infrastructure des 40 clusters et coûts des ressources humaines, cela représentait environ 150 K€ sur l'année. « Les versions évoluent très vite et apportent régulièrement de nouvelles fonctionnalités et des gains de performances », souligne David de Carvalho. « Nous passions beaucoup de temps sur ces tâches que nous cherchions à automatiser ». Jusqu'à 5 profils devops s'en sont occupés, la database ne représentant qu'une partie de leurs tâches d'outillage, d'industrialisation, de prise en charge des différentes briques et de mise en pré-production. Il fallait pouvoir alléger la charge de cette équipe devops très sollicitée qui intervient sur des sujets d'une grande variété et constitue un peu le goulet d'étranglement de l'organisation.

Publicité Le deuxième enjeu, pour PagesJaunes, était de pouvoir disposer de bases de données le plus à jour possible sur la dernière version en date. Si les nouveaux services utilisaient la plus récente, d'autres restaient sur d'anciennes versions de MongoDB. Certaines étaient mises à jour assez rarement, avec un coût très élevé lorsqu'il fallait le faire. « Nous avions un stack assez hétérogène, avec 5 versions en parallèle qui tournaient. Nous cherchions aussi à changer cela, pouvoir monter en gamme sans entraîner un coût important sur la mobilisation des équipes ». Le 3ème enjeu visait à aller encore plus loin dans l'adoption du cloud. « Nous y étions passés en lift and shift, il fallait maintenant chercher plutôt un service managé avec tous les avantages que cela apporte sur l'automatisation, une meilleure gestion des clusters, une réactivité plus grande aux problèmes, une sécurité renforcée et la possibilité de gagner énormément en temps humain sur la maintenance et l'évolution des bases de données », détaille David de Carvalho.

Un SLA à 99,995 % sur Atlas

Le projet de passer à une base de données managée est alors mis à l'étude. « Nous utilisions MongoDB depuis 5 ans et avions une maîtrise assez poussée sur les requêtes, l'administration des bases... ». Après une phase d'exploration du marché sans trouver de solutions satisfaisante à ce qui était recherché, Solocal envisage deux choix, passer à la database managée MongoDB Atlas si le budget le permet ou optimiser la stack technique existante. « Nous avons fait une phase d'étude, du chiffrage, des estimations avec un macro-planning, ce qui a vraiment décidé, c'est la phase de prototypage ». Après un 1er prototype concluant sur une petite base de données d'outillage (mise en place des procédures, contrôle en termes de charge, de réseau, de sécurité, etc.), un 2ème prototype est réalisé sur l'une des plus grosses bases. « Techniquement, nous étions en phase, avec de bonnes nouvelles et même, des perspectives très intéressantes que nous n'avions pas forcément envisagées », rapporte David de Carvalho. « Il restait la phase de négociation commerciale ».

La migration est finalement engagée avec l'objectif de l'achever au premier semestre 2021 avec un nombre de clusters divisé à l'arrivée par 2. En termes de ressources humaines, la gestion des bases représentait un tiers du budget, cela pèse maintenant 4 ou 5% du coût, indique le chef de projet. « Enormément de choses sont automatisables et automatisées, c'est le choix que nous avons fait tout de suite ». Deux outils sont utilisés, un portail et un client Terraform avec des scripts qui permettent d'industrialiser de nombreuses tâches. « Nous avons capitalisé sur cela pour tout ce qui tourne autour de la maintenance, de l'évolution de nos bases de données. Nous sommes par exemple passés de la version 3.6, dépréciée en avril, à la 4.2 en une heure, de manière automatique, sans incident, sans coupure de service, ce qui nous prenait peut-être 3 à 4 jours auparavant avec un devops, un développeur et un architecte en cas de problème. Aujourd'hui, avec ce service managé, nous avons des métriques, des alertes, ce qui nous permet de nous assurer que tout se passe bien », pointe M. de Carvalho qui met également en avant le SLA. « Avec Atlas, MongoDB assure une disponibilité de service, un SLA à 99,995 % ». Il cite en exemple la reconfiguration d'un cluster avec l'ajout d'une 4ème machine, fait à plusieurs reprises, sans coupure de service. « C'était une promesse très alléchante au début qui s'est confirmée à l'utilisation ».

Des crédits négociés en avance de phase

Le projet s'est déroulé en 5 grandes étapes, une par trimestre, avec un démarrage au 4ème trimestre 2019. Le chef de projet souligne un point important sur la facturation du service managé MongoDB Atlas : les crédits sont négociés en avance de phase. « Nous les achetons pour l'année et il faut les consommer suivant le planning. Si ce n'est pas le cas à la fin de l'année, nous les perdons. » Le projet doit donc être défini comme un projet prioritaire dans l'entreprise afin que le planning puisse être respecté. « Un des succès, c'est de pouvoir consommer tel que prévu les crédits que l'on a achetés à l'avance ». 

La migration est maintenant pratiquement achevée. « Le passage à MongoDB Atlas nous a donné une grosse force de frappe sur l'automatisation. Cela nous fait gagner énormément de temps ». Sur la gestion des backups, par exemple, il n'est plus nécessaire de recourir aux opérationnels. Cette gestion des sauvegardes et des restaurations se fait avec des politiques assez fines, très bien décrites avec les processus automatiques via le client Terraform. « Autre avantage, dans MongoDB Atlas, l'option autoscaling permet à la plateforme de monter seule en gamme ou de descendre, selon certaines règles ». De même pour les mises à jour de versions. « L'autre point qui était crucial pour nous dès le début, c'était que nous puissions faire des interventions sans coupure de service pour les utilisateurs des sites Internet, que ce soit en migration de base de données ou en run standard. Nous avons profité de ce chantier pour optimiser notre infrastructure, regrouper des bases de données dans un cluster, homogénéiser nos versions... Ce qui ressort des formations que je donne, c'est la facilité que l'on a à gérer nos bases de données sans devoir passer par des devops. Les équipes sont beaucoup plus autonomes ».

Les processus et la sécurité ont été améliorés avec des outils présents nativement, par exemple des systèmes d'alerting assez poussés qui s'enclenchent avec certains seuils. Dernier point, le chef de projet souligne le support fourni par MongoDB, très réactif et disponible 24/7 via sa plateforme. Pour mener un tel projet, David de Carvalho rappelle enfin la nécessité d'un référent technique qui puisse se rendre disponible au moindre problème et insiste sur la phase de prototypage, indispensable. Aujourd'hui, avec les optimisations techniques, les évolutions sur les clusters, le coût global doit avoir augmenté de 10%, mais il est justifié par le service apporté, ainsi que le temps humain important économisé, estime le chef de projet.

Article rédigé par

Maryse Gros, Journaliste, chef de rubrique LMI

Partager cet article