Déplacer des applications, refactorer des services, changer un datalayer vers une autre technologie... Des thématiques assez courantes dans la vie d'une entreprise aujourd'hui. L'équipe de LOUD a récemment eu la chance de travailler à la migration d'une base de données critique sur le Cloud. C'est l'occasion de revenir sur les outils et méthodes à garder en tête pour une migration réussie.
La migration de bases de données est un processus crucial pour de nombreuses entreprises à mesure qu’elles évoluent vers des infrastructures plus flexibles et évolutives. Amazon Web Services (AWS) offre un outil puissant appelé AWS Database Migration Service (DMS) pour faciliter ce processus complexe.
C’est l’outil que nous allons aborder dans cet article pour aborder la migration de bases de données critiques.
Se préparer à migrer une base de données
Avant de penser aux outils, il est important de rappeler un essentiel : il n’y a pas que des aspects techniques qui doivent être pris en compte lors d’un projet de migration.
La préparation est le principal facteur de succès d’une bascule réussie.
Il est donc primordial de se poser certaines questions pour établir le meilleur plan possible. La criticité des applications, les engagements de services, la roadmap produit sont autant de facteurs qui peuvent jouer pour décider d’un modus operandi.
Une fois que le scope est défini, on peut ensuite déterminer une fenêtre temporelle de migration :
-
Pour les applications qui peuvent accepter une fenêtre de maintenance, une solution “dump and restore” peut suffire. Ce type de méthode permet d’atteindre une coupure autour de l’heure ou plus, en fonction de la volumétrie de la base et de la capacité réseau.
-
Pour les fenêtres plus courtes, il faut prévoir une solution plus élaborée, et mettre en place un système de réplication de donnée dans le plan de migration.
Une fois que le type de migration est choisi, il faut formaliser un plan détaillé, que l’on peut appeler procédure ou runbook de migration. C’est une étape obligatoire si l’on veut éviter de nombreux écueils lors de la bascule.
Le choix des outils vient dans un second temps, une fois que les choix déterminants ont été faits et que les contraintes sont établies.
Le Fonctionnement d’AWS DMS
AWS Database Migration Service (AWS DMS) est un service web que vous pouvez utiliser pour migrer les données d’une base de données sources vers une base de données cibles. Ces deux magasins de données sont appelés « Endpoints ».
Vous pouvez effectuer des migrations entre des points de terminaison source et cible qui utilisent le même moteur de base de données, par exemple d’une base de données Oracle vers une base de données Oracle.
Vous pouvez également procéder à une migration entre des points de terminaison source et cible qui utilisent des moteurs de base de données différents, par exemple d’une base de données Oracle vers une base de données PostgreSQL. Pour cela, il faudra prévoir l’utilisation du Schema Convertion Tool (SCT) en amont pour la transformation du modèle de donnée. La seule exigence d’utilisation AWS DMS est que l’un de vos points de terminaison se trouve sur un AWS service.
Vous ne pouvez pas utiliser AWS DMS pour migrer d’une base de données “on-premise"" vers une autre base de données “on-premise”.
Pour réaliser la migration des données, DMS vous permet deux choses complémentaires :
- Migrer la donnée existante, aussi appelé “Full-load”
- Capturer les changements entrants grâce à la réplication “Change Data Capture” (CDC) basée sur le bin-logging
Le service permet désormais de lancer des taches de migration sans serveur (Serverless), mais vous avez toujours la possibilité de provisionner un serveur de réplication dans votre VPC et d’opérer avec. Petit point de vigilance cependant, le lancement des tâches de migration peut être allongé par rapport à la version “serveur” où le temps d’attente est surtout au moment du provisionning du serveur de réplication.
L’avantage de la réplication serverless peut être pour les taches de réplication longues et les volumétries imprévisibles, avec une facturation qui scale en fonction de la capacité de réplication utilisée.
Full Load
La migration Full load est l’équivalent d’un dump and restore version DMS. C’est une méthode fiable et efficace pour migrer des bases de données avec une fenêtre de migration longue et des applications qui acceptent les fenêtre de migration conséquentes, ou encore une suspension des écritures durant la phase de load. Une fois le full-load effectué, la tâche s’arrête et on peut alors réaliser la bascule.
Cette méthode est assez limitée si la base à migrer est modifiée fréquemment (comme la pluspart des applications) et qu’il n’est pas possible pour des raisons diverses de couper assez longtemps l’accès. Le Full load unique conviendra pour les petites bases (quelques Giga tout au plus) et les applications non-critiques.
CDC
Le CDC est une méthode de réplication de données basées sur les bin-logs qui permet de répliquer les changements en direct de la base source à destination. C’est une méthode bien plus efficace, mais elle introduit plus de complexité de configuration. Le CDC est très souvent utilisé en complément d’un Full-load réalisé au préalable. Il est également possible de demander un démarrage du CDC avec un timestamp précis en cas de besoin (reprise d’un CDC à un moment précis). Le CDC continue jusqu’à l’arrêt manuel de la tâche.
Parmi les points de vigilance de cette méthode, nous pouvons citer en premier la latence de réplication : avant de réaliser la bascule, il faut bien entendu s’assurer que le serveur DMS propage bien la totalité des écritures réalisées sur la base source.
La méthode permet de migrer des bases de données très volumineuses sur des plages de temps assez étalée, sans surcharger le système au moment de la bascule. Le CDC permet également des bascules “à chaud” avec de très courtes période de cutover. La contrepartie évoquée plus haut réside dans la plus grande complexité de mise en œuvre.
Démarrer sa première réplication de base de données
Voici un aperçu simplifié d’un script de setup qui crée un serveur de réplication, un endpoint source et target avec la CLI AWS. Certains paramètres sont à customiser, et il faut en ajouter d’autres en fonction du contexte.
Par exemple, vous aurez probablement besoin des extra-connection-attributes pour adapter une timezone source et target hétérogène, ou encore suspendre les validations de clés étrangères pendant le load.
# creation d'une instance de réplication dms
aws dms create-replication-instance \
# mon-serveur-de-replication
--replication-instance-identifier $instance_id \
# dms.r4.2xlarge
--replication-instance-class $instance_class \
# 3.5.1
--engine-version $engine_version \
# 100 (en giga)
--allocated-storage $storage_size \
# Security group pour l'instance
--vpc-security-group-id $vpc_security_group_id \
# subnet group à créer indépendamment
--replication-subnet-group-identifier $subnet_group_id \
# à changer si besoin de haute disponibilité
--no-multi-az
# creation d'un endpoint source
aws dms create-endpoint \
# mon-endpoint-source
--endpoint-identifier $endpoint_id \
--endpoint-type source \
# mysql, oracle, postgresql...
--engine-name $source_engine \
# dbuser
--username $source_username \
# password
--password $source_password \
# 3306
--port $source_port \
# db-hostname
--server-name $endpoint_server_name
# creation d'un endpoint target
aws dms create-endpoint \
--endpoint-identifier $endpoint_aws_id \
--endpoint-type target \
--engine-name $target_aws_engine \
--username $target_aws_username \
--password $target_aws_password \
--port $target_aws_port \
--server-name $endpoint_aws_server_name
Une fois l’instance de réplication prête, vous pouvez alors créer une tâche de réplication selon la configuration souhaitée. Parmi les possibilité de configuration, vous allez retrouver :
- Full-load uniquement, CDC uniquement, ou les deux
- La gestion des “Large Objects” (LOB)
- Le niveau de logging
- Le comportement initial du full load (DROP, TRUNCATE, NOTHING)
- Les bases et schéma concernés par la tache de migration (on peut choisir d’exclure ou d’inclure certaines tables / databases)
- Les transformations que l’on veut potentiellement appliquer à la donnée lors de la migration
Une fois la tâche configurée, on peut alors lancer la migration de la base de données.
Quelques conseils pour la migration avec AWS DMS
Pour réaliser une migration de base de données avec succès dans le Cloud AWS, DMS est l’outil incontournable. Malgré tout, il ne faut pas s’attendre à un outil miracle et garder certains éléments en tête avant de l’utiliser.
Faire les choses dans l’ordre
DMS est un “déménageur” de donnée. Il est très fortement conseillé d’ajouter à sa procédure de migration une création du modèle de donnée en amont. De la même manière, DMS ne s’occupera pas de la création de clés secondaires ou de tout autre index, trigger ou procédure stockée (il en va de même pour les users d’ailleurs). Il est aussi conseillé de créer la structure en plusieurs étapes pour accélérer le full load de la base :
- D’abord créer une structure de base avec uniquement les tables, Primary Key (PK) sans Foreign Key (FK), index secondaire ni trigger
- Une fois le full load fini, lancer la création des FK, index, trigger et des procédures stockées si besoin
Cette façon de faire permettra une migration plus rapide si vous avez des bases volumineuses avec des tables contenant plusieurs millions de lignes.
Anticiper un rollback
Un dernier conseil, également, pourrait être de prévoir l’imprévisible : prévoyez une procédure de rollback pour pouvoir revenir en arrière au moindre problème lors de la bascule.
Pour cela, il est possible de prévoir une réplication bi-directionnelle avec DMS : répliquer avec deux tâches de migration pour pouvoir garantir une perte de donnée minimale en cas de problème.
Un point de configuration important si vous prévoyez une réplication dans les deux sens : Il faut le préciser dans la configuration des tâches pour que DMS puisse empêcher les “boucles infinies” de réplication des changements CDC. Vous pouvez ajouter ces paramètres à chacune des tâches pour cela :
{
. . .
"LoopbackPreventionSettings": {
"EnableLoopbackPrevention": Boolean,
"SourceSchema": String, # exemple : "LOOP-DATA"
"TargetSchema": String # exemple : "loop-data
},
. . .
}
Cette configuration va permettre à DMS de “reconnaître” les changements de la base source et ceux qui proviennent déjà de la réplication DMS. DMS va créer ces deux bases dans les serveurs source et destination pour pouvoir fonctionner.
DMS pour résumer
Dans l’ensemble, AWS DMS est une solution puissante pour la migration de bases de données, offrant efficacité, fiabilité et flexibilité, tout en répondant aux exigences modernes de gestion de données dans le cloud.
Cela permet aux entreprises de tous les secteurs et de toute taille d’adopter une approche plus agile et rentable de la migration des bases de données.
La facilité d’utilisation et la nature hautement configurable d’AWS DMS le rendent adapté à la fois pour les petites entreprises et les grandes entreprises. Les utilisateurs peuvent personnaliser le processus de migration pour répondre à leurs besoins spécifiques, en choisissant parmi une gamme d’options de configuration et de tuning.
Il est cependant à noter que ce n’est pas un outil miracle et qu’il est aisé de faire des erreurs lorsqu’il est mal configuré. Il faut alors accorder une importance particulière à la préparation et aux tests afin de garantir une migration sereine de vos bases de données.
Un autre point regrettable en l’état est l’aspect quelque peu “boite noire” de DMS qui ne facilite pas la compréhension de certains comportements de migration et qui rend la prise en main légèrement ardue lors du “fine tuning” des paramètres pour des cas atypiques (cf. la gestion des Timezones dans le cas de migration non-UTC, à évoquer dans un prochain article).
