Nationwide reste « concentré, en forme et rapide » dans la migration des données de SQL vers MongoDB

INTRODUCTION

La plus grande société de construction du monde se lance dans un projet de migration.

Quel que soit l’endroit où vous choisissez d’effectuer vos opérations bancaires, le nom Nationwide Building Society est familier dans tout le Royaume-Uni. C'est non seulement la plus grande société de construction au monde, mais elle existe depuis très longtemps ; fondée en 1884, elle compte aujourd'hui plus de 16 millions de clients et détient près de 10 % de l'épargne des ménages britanniques. Le statut mutualiste de Nationwide – elle appartient à ses membres et est gérée pour eux, et non par ses actionnaires – sous-tend les moteurs stratégiques de la société de construction : des relations enrichissantes, un excellent service client et une amélioration continue. Au sein de son équipe chargée des risques de crédit, l'ingénieure en chef Neha Yadav est au cœur de Nationwide. Elle classe le score de risque de chaque produit de prêt émis par l'intermédiaire de la société de construction, sur la base duquel les prêts sont acceptés, privilégiés ou refusés. « Nous essayons toujours de passer aux dernières technologies et nous nous efforçons toujours de fournir des données de la meilleure qualité possible », explique Neha Yadav. « Nous sommes une équipe en pleine forme, concentrée et rapide, car quoi que nous fassions, cela devrait bénéficier à nos membres. »

LE DÉFI

Atténuer les risques de fin de vie utile

C'est cette détermination à être « en forme, concentrée et rapide » qui a incité Nationwide à abandonner sa précédente plateforme entièrement sur site. « Pour renforcer les protections et garantir un bénéfice mutuel aux clients, l'idée était de se débarrasser de tous les serveurs existants, de tout transférer vers le cloud et de disposer d'une base de données NoSQL », explique Yadav, « offrant ainsi un service optimal à la société et à ses membres. »

L'idée initiale de l'équipe était de tirer parti de certaines fonctionnalités cloud d'AWS et d'utiliser MongoDB dans le cadre d'une banque de données d'audit, uniquement. « C'était l'idée initiale », explique Neha Yadav, qui dirigeait à l'époque l'équipe sur site d'une douzaine de personnes. La base de données des découverts de Nationwide était locale. Ses services étaient consommés par différents secteurs de la société du bâtiment et approchaient de leur fin de vie utile. Dans le but de s'éloigner complètement de la banque de données sur site, l'équipe a décidé que la base de données des découverts serait un bon point de départ.

En avril 2023, en commençant à analyser les changements nécessaires, l'équipe a consulté MongoDB, avec qui elle avait une relation établie, sur la façon dont elle pourrait aider le processus. Les défis liés à l'atténuation du risque de fin de vie MEAN qu'un critère clé pour Nationwide était de déplacer les données avec le moins d'intervention humaine ou d'effort de développement possible. « Nous n'avions donc pas beaucoup de temps pour nous concentrer sur la migration des données », explique Neha Yadav. « C'est alors que MongoDB a proposé la version Preview de Relational Migrator. »

Ce serait la première fois que le produit serait utilisé au Royaume-Uni.

LA SOLUTION

Migration des données rapide, sécurisée et avec validation

À l'aide du MongoDB Relational Migrator, Neha Yadav et son équipe ont entrepris une migration unique de la base de données des découverts de SQL vers MongoDB Atlas, au cours d'une maintenance programmée. « Nous voulions préserver l'intégrité de l'environnement et réduire le risque que quelque chose ne soit oublié ou non vérifié grâce à une migration continue des données », explique-t-elle. « Nous avons donc opté pour une migration instantanée. »

Il faut tout de même dire que le processus a suscité une certaine inquiétude au sein de l'équipe, étant donné la nature complexe des migrations en général et le fait de ne pas savoir comment les données migrées seraient validées ou fonctionneraient en fin de compte. L'équipe a pu effectuer des tests de migration pour valider le processus de production, en créant un environnement de test similaire qui recevrait plusieurs demandes, puis en les interrompant pour voir comment il se comporterait. « De cette façon, nous étions à peu près sûrs que cela fonctionnerait », explique Yadav. « Et pour être en sécurité, nous sommes allés au bureau pour la migration en direct. »

Le projet complet de migration, de l'API sur site vers le cloud, a duré environ six mois. L'équipe a déployé des microservices sur son cluster AWS, donc les nombreux flux ETL sur site ont également dû être déplacés, y compris le temps de développement pour les Lambdas.

« Il ne s’agissait pas seulement de la migration des données », explique Neha Yadav, « mais aussi de la migration du flux, de l’API et des données. »

Elle ajoute : « Cela a nécessité de nombreuses démonstrations de faisabilité et le partage de ressources. Si j'avais supprimé tous les décalages, cela aurait pris trois mois – c'était très rapide. Avec Relational Migrator, je dirais que nous avons économisé 50 % de nos efforts. »

L'une des fonctionnalités les plus appréciées de Relational Migrator est Query Converter, un outil d'intelligence artificielle permettant de migrer les requêtes SQL vers les pipelines d'agrégation de MongoDB. « Cette fonctionnalité a été très utile pour revalider ce que nous avions compris et pour savoir que tout ce que nous avions écrit était correct », explique Neha Yadav.

LES RÉSULTATS

Confiance pour déplacer les données des locaux vers le cloud sans effort de développement

« Relational Migrator nous a donné l'assurance que nous n'avions pas besoin de développer ou de valider les données manuellement pour transférer nos données du site vers le cloud », résume Neha Yadav. Et l’expérience de la migration de la base de données de découvert de SQL vers MongoDB Atlas a été si positive pour l’équipe qu’elle est maintenant en train de déplacer d’autres bases de données vers le cloud. « Relational Migrator est très simple à utiliser », explique Neha Yadav. « Toute personne disposant de connaissances de base peut l’utiliser. C'est vraiment ce qu'il y a de mieux. »

Et cela a été une décision qui en valait la peine. « Avec SQL, il fallait au moins une heure pour générer l'un de nos flux », explique Neha Yadav, « depuis que nous sommes passés à MongoDB, le temps maximum est de deux minutes. » Si l'équipe a réussi à transférer les données vers MongoDB, à optimiser les requêtes et à améliorer les performances globales, la plus grande victoire est de loin d'avoir atténué le risque de fin de service. « Nous avons pris très tardivement la décision de transférer la base de données des découverts dans le cloud, ce qui était notre horizon trois, mais nous l'avons déplacé à l'horizon deux. Donc, mon plus grand succès est de l'avoir réalisé »

Il y a cependant une autre fierté : « Avant cela, Relational Migrator n'était pas utilisé chez Nationwide », explique Neha Yadav. « Ceci comportait un risque important, car si le déploiement n'avait pas été réalisé comme je le souhaitais, l'enjeu était considérable. Je suis fière que l'équipe informatique de Nationwide y soit parvenue, et je suis fier que ce soit une première. »

« La modernisation réussie du backend d'une application en seulement 6 mois est particulièrement impressionnante dans le monde de la finance, où les mises à niveau majeures de l'infrastructure prennent souvent plusieurs années», ajoute-t-elle. « Cette nouvelle agilité aidera Nationwide à maintenir sa position dominante sur le marché dans un environnement bancaire de plus en plus axé sur la technologie. »