Concevoir la migration et la réplication de base de données à l'aide de Sritim

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

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

De nombreuses entreprises adoptent une stratégie axée sur le cloud en créant des applications d'entreprise à l'aide de services et de technologies basés sur le cloud. Les entreprises gagnent en réduisant les temps de production pour leurs services et en répondant rapidement aux changements dans les demandes des clients et les conditions du marché. Les applications métier qui tirent pleinement parti du calcul dans le cloud de bout en bout sont essentielles à la croissance des activités sur le long terme.

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 source et cible à l'aide d'un système de migration de base de données.

Dans cette configuration, deux bases de données source sont migrées vers deux bases de données cible. L'une des bases de données source est accédée par une application qui accède à la base de données cible correspondante sous une forme modernisée (mise en œuvre sur Google Kubernetes Engine). La deuxième base de données source comporte également des clients (non illustrés dans le diagramme).

Bien que le système de migration de base de données soit installé sur Google Cloud, il peut être installé ailleurs. Par exemple, pour des raisons de sécurité, le système de migration peut 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.

Lors 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 vers une instance de base de données cible s'exécutant 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'un des inconvénients de l'approche Lift and Shift réside dans le fait 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 pendant les périodes 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. Tout test de l'application après la restauration de la base de données augmente les temps d'arrêt. En outre, 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 accroît les coûts et la complexité de la gestion. Bien que l'approche Lift and Shift puisse fonctionner pour certaines applications, les exigences de la plupart des applications critiques ne tolèrent pas ces coûts. Pour ces raisons, une migration de base de données en ligne constitue une approche bien meilleure.

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 permanence sur la base de données cible opérationnelle ou analytique, telle que Spanner ou BigQuery. La base de données source n'est pas arrêtée, car elle utilise une migration de base 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 d'intégration et d'intelligence de 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 bases de données avec Sritim

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 série de problèmes spécifiques à un secteur et technologiques (neutres en termes de secteur). Par exemple, une utilisation spécifique à un secteur peut être un service financier qui exploite des services de données cloud et des données en temps réel. Un cas d'utilisation plus axé sur la technologie peut consister en des migrations de bases de données de rapports ou à des migrations par étapes de bases de données opérationnelles. Striim permet ces cas d'utilisation en fournissant des pipelines de données en continu qui diffusent des données au bon format au bon moment.

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

Technologie financière

Les entreprises spécialisées dans les technologies financières (fintech) ont besoin de données rapides et précises. Par exemple, les clients du secteur bancaire souhaitent consulter immédiatement les transactions et les nouveaux soldes sur leur compte. Les emprunteurs et les prêteurs souhaitent gagner du temps avec les origines de prêt. Les entreprises fintech peuvent utiliser Striim pour répondre à de nombreuses exigences commerciales telles que celles-ci.

Considérons un service automatisé de vérification des revenus et des employés qui accélère les origines. Dans ce cas d'utilisation, Striim intègre des données en temps réel de différentes 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.

Rapports sur le déchargement

Pour certains cas d'utilisation technologiques, une distinction est établie entre les charges de travail transactionnelles et les charges de travail analytiques. En raison de l'accroissement des appels de performances sur votre base de données transactionnelles source et de la latence accrue dans le renvoi des requêtes d'analyse, il n'est pas cohérent d'exécuter des requêtes analytiques sur des bases de données transactionnelles.

Pour résoudre ce problème, vous pouvez diffuser en continu un sous-ensemble de vos données transactionnelles à Google Cloud pour effectuer des analyses et des rapports supplémentaires 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 par étapes

Les grandes entreprises possèdent d'énormes bases de données sur site qui intègrent des années de données précieuses. La migration de ces bases de données vers le cloud est une opération de grande envergure qui peut prendre des années. La conservation des anciennes bases de données a également un coût (par exemple, la perte d'opportunités offertes par les nouvelles technologies de base de données cloud telles que BigQuery, Cloud Spanner et Pub/Sub).

Pour trouver un équilibre entre la maintenance des anciens systèmes et l'utilisation des dernières technologies de base de données cloud, vous pouvez migrer des sous-ensembles de vos données vers des bases de données Google Cloud en utilisant Striim dans une approche par étapes tout en continuant à exécuter les bases de données de production source. Le démarrage avec un petit sous-ensemble permet également à vos développeurs de tester le niveau application sur 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 basé sur le cloud, Cloud Spanner. Cette architecture est utilisée tout au long de ce document et fonctionne à la fois pour la réplication continue et les migrations complètes ou par étapes.

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 basé sur le cloud, qui est ici Cloud Spanner. Striim, le système de migration de base de données, est connecté aux deux systèmes et migre 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 et la réplication de base 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 source. L'une des 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 source est un système de base de données (S2) exécuté dans un centre de données sur site qui reste sur site, tandis que ses données et les modifications ultérieures sont répliquées dans BigQuery pour l'analyse. Deux systèmes de base de données cible sont déployés : Cloud Spanner pour la réception de données de S1 (migration) et BigQuery pour la réception de flux de données continus de 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 ponctuelle de base de données, nécessitent que le système de migration soit connecté aux systèmes ou aux services jusqu'à la fin de la migration. D'autres cas d'utilisation sont plus statiques, comme dans le cas de la réplication de base de données. Cette architecture montre comment une architecture peut répondre à plusieurs cas d'utilisation.

Architecture de déploiement complexe

Cette section décrit une migration conçue en remplacement. Un remplacement peut être nécessaire lorsque les erreurs qui se produisent après la migration nécessitent que vous reveniez au traitement sur la source. La configuration de remplacement garantit que lorsqu'une migration est inversée, les modifications apportées à la cible sont recommuniquées à la source.

Cette architecture de déploiement implique la réplication et la migration. Elle est la plus complexe des trois architectures décrites dans ce document.

Cette architecture montre également comment Striim peut fonctionner dans un environnement en cluster afin de prendre en charge un débit plus élevé. Le cluster de l'architecture suivante comprend trois instances Compute Engine pour fournir une capacité suffisante. Chaque instance Compute Engine est placée dans une zone différente, ce qui offre une haute disponibilité pour la protection contre les défaillances de zones et d'instances.

Dans ce cas, deux bases de données sources situées dans un centre de données sur site sont répliquées vers le cloud. Une base de données est répliquée vers Cloud Spanner, et l'autre vers BigQuery. En outre, la migration déplace les données d'une base de données dans 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 préparer un remplacement possible. Pour que les modifications apportées à la cible soient également disponibles sur la source, la migration inversée doit être configurée après la migration d'origine.

Le diagramme suivant montre la modification de la configuration d'une solution de remplacement potentielle.

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

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

Le schéma suivant montre comment cette architecture de déploiement prend en charge le cas d'utilisation de la 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 cette discussion, cette architecture de déploiement peut prendre en charge divers cas d'utilisation, quelle que soit leur complexité. La configuration peut également être modifiée de manière dynamique, par exemple lorsque le sens du déplacement des données est inversé.

Cette architecture peut également évoluer pour permettre une augmentation de la charge ou des 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 au fil du temps, à mesure que les 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 que le schéma et les données sont identiques, la spécification de migration est simple, car elle est une copie. Toutefois, si la migration s'effectue 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 pendant la migration.

Le tableau suivant fournit une approche générale pour déterminer la complexité d'une spécification de migration. Les fonctionnalités sont répertoriées ainsi que 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 la base de données source et cible Faible complexité Complexité élevée
Données de 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 regroupement des données Complexité élevée Complexité élevée

La complexité de la migration est un spectre basé sur le cas d'utilisation mis en œuvre. Pour votre cas d'utilisation, vous pouvez déterminer la complexité globale en fonction du ratio entre faible capacité et complexité élevée avec les fonctionnalités 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