Migration des bases de données dans le cloud : mode d’emploi

Itamar Ben Hemo, CEO de Rivery partage son expertise sur la migration des bases de données dans le Cloud.

Cette migration peut être réalisée pour différentes raisons, comme l’optimisation des performances, la réduction des coûts ou l’accès à des fonctionnalités avancées. L’idée ici est de voir quelles sont les différentes méthodes qui peuvent être appliquées et d’identifier celle qui semble la plus efficace. Aujourd’hui, il faut au maximum éviter les migrations dites Big Bang, à savoir réalisées d’un seul coup sans possibilité de retour en arrière, ou « au compte-goutte » qui introduisent une couche supplémentaire de complexité. Il faut ainsi aujourd’hui privilégier la migration parallèle directe.

L’objectif de cette stratégie de migration est de faire vivre l’ancienne et la nouvelle base de données en parallèle avec les données de production. C’est la stratégie à privilégier. Dans une migration, il va forcément arriver un moment où soit quelque chose ne va pas, soit il manque des données, soit les données du nouveau système ne correspondent pas à celles de l’ancien. Quelle que soit la façon dont cette migration sera envisagée, il faudra deux choses que seule une migration parallèle en direct peut fournir :

• une validation permanente de la concordance entre les données de l’ancien et du nouveau système
• un moyen facile de tester le nouveau système avec des données et des rapports en temps réel, et de pouvoir revenir en arrière de manière fiable si nécessaire.

Voici donc les étapes à suivre pour réaliser cette migration : 

Migration des données de l’ancien système vers le nouveau

Avant de migrer les données, il faut déterminer comment gérer les différences entre les deux systèmes. Si la plupart des bases de données et des entrepôts de données prennent en charge les mêmes commandes SQL de base, chaque solution basée sur SQL possède sa propre « sauce » et des caractéristiques qui vont au-delà des normes ANSI SQL.

Par exemple, comment les bases de données traitent les données JSON, ou les tableaux de données dans une seule cellule. Ce qu’elles prennent en charge en termes de types de données, d’index, de procédures stockées, de vues, de déclencheurs, de clés étrangères et de fonctions ne sont que quelques-unes des différences communes entre les bases de données.

Si la nouvelle base de données reproduit autant que possible la structure de l’ancienne, il sera plus facile de faire des comparaisons entre les deux bases, mais il faudra peser le pour et le contre des améliorations possibles des performances.

Maintenir la synchronisation des deux systèmes

Attention, il ne faut surtout pas essayer de construire sa propre solution : l’intérêt de passer au cloud computing est de ne pas avoir à gérer l’infrastructure soi-même. Il existe une multitude d’excellents outils et de plates-formes SaaS qui traitent de ce problème. Il ne faut surtout pas réinventer la roue.

Le choix de l’outil le mieux adapté dépasse le cadre de cet article, mais la décision la plus importante à prendre est de savoir s’il faut une synchronisation en continu (en temps réel) ou par lots. La synchronisation par lots signifie que les dernières mises à jour sont copiées par lots, par exemple toutes les 5 minutes, toutes les heures ou peut-être une fois par jour. La synchronisation en continu signifie que chaque mise à jour est diffusée en « temps réel » de la source vers la cible.

Si les mises à jour en continu semblent intéressantes, les mises à jour par lots sont beaucoup plus simples à mettre en œuvre et plus faciles à récupérer en cas de défaillance. Si un délai de 5 minutes est acceptable, mieux vaut opter pour les lots, ce choix sera très bénéfique plus tard.

Un type spécifique de solution à examiner afin de maintenir la synchronisation entre la base de données source et la base de données cible est appelé Change Data Capture, ou CDC en abrégé. La capture des données de changement est une méthodologie de capture des changements de données dans une base de données source afin de transmettre ces mises à jour à une base de données cible ou à un entrepôt de données. Les exemples de changements qui sont suivis sont les insertions, les mises à jour, les suppressions ou les changements de schéma. 

Validation des données dans le nouveau système

Il faut maintenant commencer à comparer les données du système A, la base de données sur site, avec les données du système B, la solution dans le cloud. Mieux vaut d’abord commencer par des données agrégées de haut niveau, généralement sous la forme de rapports, puis d’analyser des données plus petites, voire des postes, selon les besoins.

S’il y a des divergences, l’examen de données plus granulaires et de différentes mesures aidera à trouver la cause du problème. Par exemple, y a-t-il le même nombre de commandes ? Le même nombre de clients, etc. Une fois que tout semble bon au niveau supérieur, on peut toujours valider et comparer les données à un niveau plus granulaire dans tous les cas, car les moyennes et les totaux peuvent cacher des divergences qui s’annulent.

Mise en production du nouveau système

Une fois les données de la nouvelle base de données vérifiées et validées et que les performances et les coûts sont conformes aux attentes, il est temps de « basculer ». La manière de procéder dépend fortement des spécificités du cas d’utilisation individuel, mais les deux points clés restent les suivants : le changement peut être effectué sans temps d’arrêt et il est assez facile de revenir en arrière si nécessaire.

Après le passage au nouveau système, il est très important d’effectuer une nouvelle série de tests de validation et de performance, surtout si plus de personnes utilisent des systèmes connectés à la nouvelle base de données. C’est également le moment de vérifier que l’ancien système est toujours mis à jour et reste synchronisé avec le nouveau système au cas où il faudrait revenir en arrière.

Mise en veilleuse de l’ancien système

Bien que la désactivation de l’ancienne base de données elle-même soit une procédure assez simple, il est temps de s’assurer que l’infrastructure n’y est plus connectée, ce qui peut être fait avec les journaux d’erreurs et les systèmes de surveillance. Une fois l’ancien système arrêté, la migration des données dans le cloud est réussie !