Concevoir la migration et la réplication de bases de données à l'aide de Striim

Ce document décrit l'utilisation de Striim pour la migration et la réplication de bases de données. Ce document se concentre sur les concepts d'architecture associés à la migration et à la réplication continue de bases de données. Il est destiné aux architectes et ingénieurs de bases de données, ainsi qu'aux propriétaires des données qui souhaitent migrer ou répliquer des sources de données sur Google Cloud.

Présentation de la migration et de la réplication de bases de données

De nombreuses entreprises adoptent une stratégie axée sur le cloud en créant des applications métier à l'aide de services et de technologies basés sur le cloud. Les entreprises rivalisent entre elles en raccourcissant le temps de production de leurs services, en répondant rapidement à l'évolution des demandes des clients et des conditions du marché. Les applications métier qui exploitent pleinement le cloud computing de bout en bout constituent des facteurs essentiels pour la croissance durable de l'entreprise.

Les anciennes applications critiques posent plusieurs problèmes dans la migration vers le cloud : la migration du niveau d'application, la migration de la base de données sous-jacente et le maintien d'un accès des utilisateurs ininterrompu aux applications lors de la migration.

De nombreux produits et services de migration peuvent vous aider à migrer le niveau de l'application métier, mais la migration des bases de données sous-jacentes qui diffusent l'application métier est souvent le défi le plus difficile.

En pratique, une migration de base de données vers le cloud peut prendre plusieurs formes. Le schéma suivant illustre le cas d'utilisation le plus élémentaire : une base de données sur site est migrée vers une base de données basée dans le cloud, dans ce cas, Cloud Spanner.

Architecture de la migration de base d'une base de données source vers Cloud Spanner.

Le schéma suivant illustre un cas d'utilisation plus complexe : le déplacement de plusieurs bases de données avec une modernisation de l'application.

Architecture d'une migration complexe impliquant plusieurs bases de données sources et cibles à l'aide d'un système de migration de base de données.

Dans cette configuration, deux bases de données sources sont migrées vers deux bases de données cibles. Une application accède à une des bases de données source, puis à la base de données cible correspondante de manière modernisée (mise en œuvre sur Google Kubernetes Engine). La deuxième base de données source contient également des clients (non illustrés sur le schéma).

Bien que le système de migration de bases de données soit installé sur Google Cloud, vous pouvez l'installer sur un autre emplacement Par exemple, pour des raisons de sécurité, le système de migration peut être requis pour s'exécuter au même emplacement que la base de données source.

Migrations Lift and Shift et de base de données en ligne

De manière générale, les deux approches de la migration de base de données sont la migration Lift and Shift et la migration en ligne.

Dans le cadre d'une migration Lift and Shift, vous exportez ou sauvegardez généralement une base de données source, déplacez le fichier exporté ou de sauvegarde vers le cloud, puis importez et restaurez le fichier sur une instance de base de données cible exécutée dans le cloud. Lorsque la nouvelle base de données cible est prête, les applications métier s'exécutent dans le cloud et accèdent aux données.

L'inconvénient de l'approche Lift and Shift est qu'elle nécessite des temps d'arrêt pour l'application métier et la base de données. Cette approche nécessite une planification minutieuse de la migration en période de faible activité. Cette approche suppose également que vous pouvez arrêter l'application métier pendant la migration et la redémarrer une fois la base de données restaurée dans le cloud. Les tests exécutés sur l'application après la restauration de la base de données s'ajoutent au temps d'arrêt. De plus, l'approche Lift and Shift crée une copie intermédiaire de la base de données qui doit être sécurisée, déplacée, stockée et finalement supprimée. Cet aspect ajoute une complexité au niveau des coûts et de la gestion. Bien que l'approche Lift and Shift puisse fonctionner pour certaines applications, les exigences de la plupart des applications stratégiques ne justifient pas ces coûts. Pour toutes ces raisons, la migration des bases de données en ligne est bien plus efficace.

L'approche de migration en ligne vise à avoir un impact minimal sur les performances de la base de données et les utilisateurs des applications métier. L'approche en ligne vous permet de migrer vos bases de données vers le cloud en continu, en maintenant les bases de données source et cible entièrement synchronisées pendant des mois, voire des années, pendant que vous optimisez et testez l'application métier pour la nouvelle base de données dans le cloud.

Migration de base de données et réplication de base de données

Dans une migration de base de données vers le cloud, la base de données source est supprimée une fois la migration terminée, car la base de données cloud devient alors l'instance de production.

Dans certains cas d'utilisation, l'instance de base de données d'origine peut continuer à s'exécuter pendant le traitement en aval sur Google Cloud. Dans ce cas, la base de données source est répliquée dans Google Cloud. Par exemple, vous pouvez avoir une application qui accède à une base de données qui dépend d'une technologie ne pouvant pas être transférée vers Google Cloud. Dans le même temps, la technologie Google Cloud est utilisée pour des fonctionnalités telles que l'analyse (réplication vers BigQuery, par exemple). Autre exemple : une base de données contenant des informations personnelles doit résider dans un environnement sur site, tandis que le traitement en aval utilisant des informations personnelles cachées se produit dans Google Cloud.

Dans ces cas d'utilisation, la base de données d'origine doit être répliquée en continu sur la cible opérationnelle ou analytique, telle que Spanner ou BigQuery. La base de données source n'est pas arrêtée, comme pour une migration de bases de données.

La migration de bases de données en ligne et les réplications de bases de données hétérogènes sont généralement complexes, car elles impliquent des mois, voire des années, de codage manuel et d'intégration de divers services. Une approche plus moderne et efficace de la migration de base de données en ligne consiste à utiliser un système de migration et d'intégration de base de données tel que Striim.

Le schéma suivant illustre une architecture de déploiement de base de la plate-forme de veille et d'intégration des données Striim avec une base de données source et une base de données cible.

Architecture de la migration de base avec Striim.

Migration et réplication de base de données avec Striim

Stiim, un partenaire technologique de Google fournissant une technologie de migration de base de données, simplifie la migration en ligne en utilisant une interface par glisser-déposer afin de configurer un déplacement continu des données entre des bases de données hétérogènes. Pour ces migrations vers Google Cloud, Striim offre une plate-forme d'extraction, de transformation et de chargement (ETL) qui n'est pas perturbatrice, et qui est plus rapide à déployer et plus facile à itérer que les autres solutions.

Grâce à la capture de données de modification non intrusive (CDC), Striim extrait des données en temps réel sans ralentir les bases de données transactionnelles source, ce qui autorise des migrations de base de données cloud sans temps d'arrêt et avec un risque minimal. Pendant le transfert des données, Striim peut filtrer, transformer, agréger et enrichir les données via des requêtes SQL à l'aide d'un moteur d'analyse de streaming complet.

En répliquant en continu les données entre les bases de données sur site et Google Cloud, Striim prend en charge la réplication en ligne lorsque les applications critiques continuent de s'exécuter sans temps d'arrêt. Grâce à la validation de la livraison continue, à la haute disponibilité et au basculement, Striim minimise également le risque de perte de données.

Cas d'utilisation pour la migration et la réplication de base de données

Les migrations de bases de données en ligne et la réplication continue peuvent être appliquées à une combinaison de problèmes propres à des secteurs spécifiques et de problèmes technologiques. Par exemple, une utilisation propre à un secteur peut être un service financier qui exploite les services de données cloud et les données en temps réel. Une migration de bases de données de rapports ou une migration en plusieurs phases de bases de données opérationnelles constituent des cas d'utilisation plus axés sur la technologie. Striim active ces cas d'utilisation en fournissant des pipelines de données continues qui diffusent les données au bon format et au bon moment.

Cette section traite de l'utilisation de Striim pour migrer des bases de données pour un cas d'utilisation propre à un secteur et deux cas d'utilisation technologiques.

Technologie financière

Les entreprises spécialisées dans les technologies financières ont besoin de données rapides et précises. Par exemple, les clients des banques souhaitent consulter immédiatement les transactions et les nouveaux soldes publiés sur leurs comptes. Les emprunteurs et les prêteurs veulent gagner du temps lors d'octrois de prêts. Les entreprises financières peuvent utiliser Striim pour répondre à de nombreuses exigences commerciales telles que celles-ci.

Considérez l'exemple d'un service automatisé de vérification des emplois et des revenus qui accélère les octrois de prêts. Dans ce cas d'utilisation, Striim intègre des données en temps réel provenant de diverses sources sur site à Google Cloud. Cette automatisation réduit les retards dans le processus de vérification des emplois. Le schéma suivant illustre l'architecture de ce cas d'utilisation.

Cas d'utilisation fintech pour le transfert de données vers Google Cloud à l'aide de Striim.

Cette architecture tire parti de l'intégration de données de streaming en temps réel de Striim. Striim collecte en continu des données provenant de diverses sources externes et internes (par exemple, la charge de processeurs tels qu'ADP, ainsi que les données d'employés et démographiques d'autres fournisseurs). Striim transmet ensuite les données à divers services Google Cloud. Stiim ingère en continu les données de bases de données relationnelles en utilisant le CDC basé sur les journaux, en accédant aux fichiers de parcours Oracle® GoldenGate, le cas échéant, et même à partir de fichiers plats. Striim fournit en continu des données agrégées et transformées à Cloud Storage pour alimenter les applications métier et les services conçus pour le cloud.

Déchargement des rapports

Dans certains cas d'utilisation axés sur la technologie, une distinction est effectuée entre les charges de travail transactionnelles et les charges de travail analytiques. En raison de l'augmentation des performances sur votre base de données transactionnelle source et de la latence accrue dans le traitement des requêtes analytiques, il est inutile d'exécuter des requêtes analytiques sur des bases de données transactionnelles.

Pour répondre à cette distinction, vous pouvez continuer à fournir en continu un sous-ensemble de données transactionnelles à Google Cloud afin de procéder à une analyse et des rapports plus complets dans BigQuery. Le schéma suivant illustre un exemple d'architecture.

Architecture qui répartit les charges de travail entre les bases de données transactionnelles et les bases de données analytiques.

Avec la possibilité de transformer et de normaliser les données dans des pipelines de données de streaming, Striim peut intégrer un sous-ensemble sélectionné des données transactionnelles source aux plates-formes d'analyse, tandis que les données restantes sont déplacées en permanence vers une ou plusieurs données Google Cloud cible.

Migration en plusieurs phases

Les grandes entreprises disposent de bases de données sur site extrêmement volumineuses qui contiennent des données d'une valeur inestimable s'étendant sur plusieurs années. La migration de ces bases de données vers le cloud est une opération complexe qui peut prendre plusieurs années. Le maintien des anciennes bases de données n'est pas sans conséquences, par exemple, la perte d'opportunités des nouvelles technologies de base de données cloud telles que BigQuery, Cloud Spanner et Pub/Sub.

Pour trouver le juste équilibre entre la maintenance des anciens systèmes et l'exploitation des dernières technologies de base de données cloud, vous pouvez migrer, en plusieurs phases, des sous-ensembles de données vers les bases de données Google Cloud à l'aide de Striim tout en continuant à exécuter des bases de données de production sources. Le fait de commencer par un petit sous-ensemble permet également à vos développeurs de tester le niveau d'application dans la nouvelle base de données cloud sans affecter la base de données de production sur site.

Après vous être assuré que le niveau d'application est compatible, vous pouvez augmenter progressivement les sous-ensembles que vous migrez jusqu'à la migration de toute la base de données. Cette migration rythmée vous permet de gérer les risques et de migrer vos systèmes de production avec un temps d'arrêt minimal.

Architecture de déploiement

Les architectures de déploiement de cette section présentent les divers services cloud, bases de données et applications utilisés dans différents cas d'utilisation pour la migration et la réplication de base de données.

Architecture de déploiement de base

Le schéma suivant illustre une architecture de déploiement simple : le système de base de données source est migré vers le système de base de données cloud, Cloud Spanner. Cette architecture est utilisée tout au long de ce document, et fonctionne pour la réplication continue et les migrations complètes ou effectuées en plusieurs phases.

Architecture de la migration de base avec Striim.

Dans cette architecture, le système de base de données source est migré vers le système de base de données cloud, ici Cloud Spanner. Le système de migration de bases de données, Striim, est connecté aux deux systèmes et transfère les données du système de base de données source vers le système de base de données cible.

Architecture de déploiement de complexité moyenne

Le schéma suivant illustre une architecture impliquant deux systèmes de base de données source. Cette architecture est plus complexe que l'architecture précédente, et fonctionne pour la migration de bases de données et la réplication de bases de données.

Migration de bases de données source sur site et cloud vers les bases de données cible transactionnelles et analytiques.

Le schéma illustre l'architecture initiale avec deux systèmes de base de données sources. L'une des bases de données sources est un système de base de données (S1) exécuté dans un cloud public et qui doit être migré. La deuxième base de données source est un système de base de données (S2) exécuté dans un centre de données sur site pendant que ses données et modifications ultérieures sont répliquées sur BigQuery pour analyse. Deux systèmes de base de données cibles sont déployés : Cloud Spanner pour recevoir les données du système S1 (migration) et BigQuery pour recevoir des flux de données continus du système S2.

Le schéma suivant représente l'architecture de déploiement une fois la migration de la base de données terminée. S1 est arrêté et la cible Cloud Spanner correspondante n'est plus connectée à Striim.

Architecture après la fin de la migration où la base de données transactionnelles est déconnectée de Striim.

Ce scénario montre que l'architecture de déploiement n'est pas nécessairement statique. Certains cas d'utilisation, tels qu'une migration de base de données ponctuelle, exigent que le système de migration soit connecté aux systèmes ou aux services tant que la migration n'est pas terminée. D'autres cas d'utilisation sont plus statiques, comme dans le cas de la réplication de base de données. Cette configuration montre comment une architecture peut répondre à plusieurs cas d'utilisation.

Architecture de déploiement complexe

Cette section décrit une migration conçue pour servir de solution de remplacement. Un remplacement peut être requis lorsque des erreurs survenant après la migration nécessitent un retour à la source pour traitement. La configuration de remplacement garantit que lorsqu'une migration est inversée, les modifications de la cible sont transmises à la source.

Cette architecture de déploiement, qui implique la réplication et la migration, est la plus complexe des trois architectures abordées dans ce document.

Cette architecture illustre également comment Striim peut fonctionner dans un environnement en cluster pour répondre à l'augmentation du débit. Le cluster de l'architecture suivante se compose de trois instances Compute Engine afin de fournir une capacité suffisante. Chaque instance Compute Engine est placée dans une zone différente qui fournit une haute disponibilité en matière de protection contre les défaillances zonales et d'instance.

Dans ce cas, deux bases de données sources situées dans un centre de données sur site sont répliquées dans le cloud. Une base de données est répliquée dans Cloud Spanner et une autre dans BigQuery. En outre, la migration déplace les données d'une base de données d'un cloud public vers une instance Cloud SQL.

Le schéma suivant illustre l'architecture de déploiement avant la fin de la migration.

Architecture de plusieurs bases de données source et cible utilisant le système de migration Striim

Trois bases de données source sont connectées à Striim. Striim migre et réplique les données vers trois bases de données cible. Les deux bases de données source du centre de données sur site sont répliquées vers BigQuery et Cloud Spanner, et la base de données source dans le cloud est migrée vers Cloud SQL.

Une fois la migration terminée, le flux est inversé de Cloud SQL vers la base de données dans le cloud pour anticiper un remplacement éventuel. Afin de garantir que toutes les modifications apportées à la cible sont également disponibles sur la source, la migration inverse doit être configurée après la migration d'origine.

Le schéma suivant illustre la modification de configuration pour anticiper un remplacement éventuel.

Architecture de remplacement de la base de données source utilisant le système de migration Striim.

La direction du flux de données est inversée entre la base de données cloud source d'origine et Cloud SQL. Une fois la migration terminée et le besoin de remplacement écarté, les systèmes associés dans la migration sont déconnectés, y compris Cloud SQL et la base de données source dans le centre de données sur site.

Le schéma suivant montre comment cette architecture de déploiement accepte le cas d'utilisation de réplication continue.

Architecture de la réplication continue de deux bases de données source sur site à plusieurs bases de données cible à l'aide de Striim.

Les deux bases de données source du centre de données sur site sont répliquées en continu vers BigQuery et Cloud Spanner.

Comme le montre cet article, cette architecture de déploiement peut gérer divers cas d'utilisation, quelle que soit la complexité. La configuration peut également être modifiée de manière dynamique, par exemple lorsque la direction du déplacement de données est inversée.

Cette architecture peut également évoluer pour répondre aux charges accrues ou aux pics.

Complexité de l'architecture de déploiement par rapport à la spécification de migration

Dans les architectures précédentes, les deux dimensions de la complexité sont les suivantes :

  • Nombre de systèmes de base de données connectés à Striim
  • Modification de l'architecture de déploiement à mesure que des cas d'utilisation sont terminés

La complexité peut également être prise en compte dans le contexte des spécifications de migration elles-mêmes, indépendamment de l'architecture de déploiement.

Par exemple, si une base de données MySQL sur site est migrée vers une base de données MySQL dans le cloud, et si le schéma et les données sont identiques, la spécification de la migration est simple, car il s'agit d'une copie. Cependant, si la migration est effectuée d'une base de données Oracle vers une base de données Cloud Spanner, la complexité de la migration augmente considérablement, car les schémas source et cible sont différents, et les données doivent être transformées lors de la migration.

Le tableau suivant fournit une approche générale permettant de déterminer la complexité d'une spécification de migration. Les fonctionnalités sont répertoriées avec une indication de la complexité de la migration ou de la réplication. Vous pouvez utiliser la colonne intitulée Votre cas d'utilisation pour évaluer vos besoins.

Fonctionnalité Semblable Différent Votre cas d'utilisation
Système de base de données source et cible Faible complexité Complexité élevée
Schéma de base de données source et cible Faible complexité Complexité élevée
Données provenant de la base de données source et cible Faible complexité Complexité élevée
Partitionnement des données (le cas échéant) Faible complexité Complexité élevée
Séparation ou consolidation des données Complexité élevée Complexité élevée

La complexité de la migration correspond à un spectre basé sur le cas d'utilisation mis en œuvre. Vous pouvez déterminer la complexité globale en fonction du taux de faible complexité et de complexité élevée pour les caractéristiques de votre cas d'utilisation.

D'autres considérations peuvent jouer un rôle dans la définition de la complexité, en particulier dans les cas d'utilisation avancée. Exemple :

  • Plusieurs de vos bases de données source seront-elles regroupées en une seule base de données cible ?
  • Les données de plusieurs bases de données source seront-elles redistribuées dans un ensemble de bases de données cible, par exemple pour une re-segmentation ou un repartitionnement ?
  • Les données seront-elles enrichies ou réduites lors de la migration afin de fournir un ensemble de données bien organisé dans le système cible ?

Chaque fonctionnalité que vous ajoutez à votre cas d'utilisation augmente la complexité, et un système tel que Striim est conçu pour prendre cette situation en charge.

Étape suivante