Migrer sur plusieurs régions Google Cloud : préparer les charges de travail de données et par lots pour la migration sur plusieurs régions

Last reviewed 2023-12-08 UTC

Ce document décrit comment concevoir une plate-forme de données sur Google Cloud afin de minimiser l'impact d'une expansion future vers d'autres régions ou d'une migration d'une région à une autre. Ce document fait partie d'une série qui vous aide à comprendre l'impact de l'expansion de votre plate-forme de données vers une autre région. Il vous apprend à effectuer les opérations suivantes :

  • Préparez le transfert des données et des pipelines de données.
  • Mettez en place des contrôles pendant les phases de migration.
  • Créez une stratégie de migration flexible en séparant le stockage des données et le calcul des données.

Les conseils de cette série sont également utiles si vous n'avez pas planifié de migration sur plusieurs régions ou d'expansion vers plusieurs régions. Dans ce cas, vous devrez peut-être déployer des efforts supplémentaires pour préparer votre infrastructure, vos charges de travail et vos données à la migration sur plusieurs régions et à l'expansion vers plusieurs régions.

Ce document fait partie d'une série :

Cette série suppose que vous avez lu et que vous connaissez les documents suivants :

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases

À chaque étape du processus de migration, vous suivez les phases définies dans l'article Migrer vers Google Cloud : premiers pas :

  1. Évaluer et découvrir vos charges de travail.
  2. Planifier et établir les fondations.
  3. Déployer vos charges de travail.
  4. Optimiser votre environnement

La plate-forme de données moderne sur Google Cloud

Cette section décrit les différentes parties d'une plate-forme de données moderne et la manière dont elles sont généralement construites dans Google Cloud. Les plates-formes de données en tant que concept général peuvent être divisées en deux sections :

  • La couche de stockage des données est l'endroit où les données sont enregistrées. Les données que vous enregistrez peuvent prendre la forme de fichiers dans lesquels vous gérez des octets réels sur un système de fichiers tel que le système de fichiers distribué Hadoop (HDFS) ou Cloud Storage. Vous pouvez également utiliser un langage spécifique au domaine (DSL) pour gérer les données dans un système de gestion de base de données.
  • La couche de calcul des données correspond à tout traitement des données que vous pouvez activer sur le système de stockage. Comme pour la couche de stockage, il existe de nombreuses mises en œuvre possibles, et certains outils de stockage de données gèrent également le calcul des données. Le rôle de la couche de calcul de données dans la plate-forme est de charger les données depuis la couche de stockage, de traiter les données, puis d'enregistrer les résultats dans un système cible. Le système cible peut être la couche de stockage source.

Certaines plates-formes de données utilisent plusieurs systèmes de stockage pour leur couche de stockage de données, et plusieurs systèmes de calcul de données pour leur couche de traitement de données. Dans la plupart des cas, la couche de stockage des données et la couche de calcul des données sont séparées. Par exemple, vous avez peut-être mis en œuvre la couche de stockage de données à l'aide des services Google Cloud suivants :

Vous avez peut-être mis en œuvre la couche de calcul de données à l'aide d'autres services Google Cloud comme ceux-ci :

Pour réduire la durée et la latence des communications, le coût du transfert de données sortantes et le nombre d'opérations d'E/S entre la couche de stockage et la couche de calcul, nous vous recommandons de stocker les données dans la même zone que celle dans laquelle vous traitez les données.

Nous vous recommandons également de séparer votre couche de stockage de données de votre couche de calcul. Le fait de séparer ces couches améliore votre flexibilité dans la modification des couches de calcul et la migration des données. Le fait de séparer les couches réduit également votre utilisation des ressources, car la couche de calcul n'a pas besoin d'être opérationnelle en permanence. Par conséquent, nous vous recommandons de déployer le stockage de données et le calcul de données sur des plates-formes distinctes dans la même zone et dans la même région. Par exemple, vous pouvez transférer votre stockage de données depuis HDFS vers Cloud Storage et utiliser un cluster Dataproc pour le calcul.

Évaluer votre environnement

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour la migration des pipelines de données par lot que vous avez déployés :

  1. Dresser un inventaire complet de vos pipelines de données
  2. Cataloguer vos pipelines en fonction de leurs propriétés et de leurs dépendances
  3. Former et préparer vos équipes sur Google Cloud
  4. Élaborer un test et une démonstration de faisabilité sur Google Cloud.
  5. Calculer le coût total de possession (TCO) de l'environnement cible.
  6. Choisir les charges de travail que vous souhaitez migrer en premier

Pour en savoir plus sur la phase d'évaluation et ces tâches, consultez la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail. Les sections suivantes sont basées sur les informations de ce document.

Créer vos inventaires

Pour couvrir votre migration, vous devez comprendre l'environnement de la plate-forme de données dans lequel vos pipelines de données sont déployés :

  1. Dresser un inventaire de votre infrastructure de données, c'est-à-dire les différentes couches de stockage et de calcul que vous utilisez pour le stockage de données et le traitement des données par lot.
  2. Créer un inventaire des pipelines de données dont la migration est planifiée
  3. Créer un inventaire des ensembles de données lus par les pipelines de données et devant être migrés

Pour créer un inventaire de votre plate-forme de données, tenez compte des points suivants pour chaque partie de l'infrastructure de données :

  • Couches de stockage. En plus des plates-formes de stockage standards comme Cloud Storage, envisagez d'autres couches de stockage comme Firebase, BigQuery, Bigtable et Postgres, ou d'autres clusters comme Apache Kafka. Chaque plate-forme de stockage utilise sa propre stratégie et sa propre méthode de migration. Par exemple, Cloud Storage propose des services de migration de données, et une base de données peut disposer d'un outil de migration intégré. Assurez-vous que chaque produit que vous utilisez pour le stockage des données est disponible dans votre environnement cible ou que vous disposez d'un remplacement compatible. Entraînez-vous et vérifiez le processus de transfert de données techniques pour chacune des plates-formes de stockage impliquées.
  • Couches de calcul. Pour chaque plate-forme de calcul, vérifiez le plan de déploiement et les modifications de configuration que vous avez pu apporter aux différentes plates-formes.
  • Latence du réseau. Testez et vérifiez la latence du réseau entre l'environnement source et l'environnement cible. Il est important de connaître le temps nécessaire à la copie des données. Vous devez également tester la latence du réseau des clients et des environnements externes (tels qu'un environnement sur site) vers l'environnement cible par rapport à l'environnement source.

  • Configurations et déploiement. Chaque produit d'infrastructure de données possède ses propres méthodes de configuration. Faites l'inventaire des configurations personnalisées que vous avez créées pour chaque composant et des composants que vous utilisez avec les versions par défaut de chaque plate-forme (par exemple, la version de Dataproc ou Apache Kafka que vous utilisez). Assurez-vous que ces configurations peuvent être déployées au sein de votre processus de déploiement automatisé.

    Vous devez savoir comment chaque composant est configuré, car les moteurs de calcul peuvent se comporter différemment en fonction de leur configuration, en particulier si le framework de la couche de traitement change pendant la migration. Par exemple, si l'environnement cible exécute une version différente d'Apache Spark, certaines configurations du framework Spark peuvent avoir changé entre les versions. Ce type de modification de configuration peut entraîner des modifications de sorties, de sérialisations et de calculs.

    Pendant la migration, nous vous recommandons d'utiliser des déploiements automatisés pour vous assurer que les versions et les configurations restent identiques. Si vous ne pouvez pas conserver les mêmes versions et configurations, assurez-vous de disposer de tests permettant de valider les sorties de données calculées par le framework.

  • Tailles de cluster. Pour les clusters autogérés, tels qu'un cluster Dataproc à longue durée de vie ou un cluster Apache Kafka s'exécutant sur Compute Engine, notez le nombre de nœuds et de processeurs, ainsi que la mémoire pour chaque nœud des clusters. La migration vers une autre région peut entraîner une modification du processeur utilisé par votre déploiement. Par conséquent, nous vous recommandons de profiler et d'optimiser vos charges de travail après avoir déployé l'infrastructure migrée en production. Si un composant est entièrement géré ou sans serveur (par exemple, Dataflow), le dimensionnement fait partie de chaque job et non du cluster.

Les éléments suivants que vous évaluez dans votre inventaire sont axés sur les pipelines de données :

  • Sources et récepteurs de données. Veillez à prendre en compte les sources et les récepteurs utilisés par chaque pipeline de données pour la lecture et l'écriture de données.
  • Contrats de niveau de service (SLA) et objectifs de niveau de service (SLO). Les SLA et les SLO des pipelines de données par lot sont généralement mesurés avant la fin du processus, mais ils peuvent aussi être mesurés d'autres manières, par exemple en fonction de la puissance de calcul utilisée. Ces métadonnées métier sont importantes pour assurer la continuité des activités et la reprise après sinistre (BCDR), tels que le basculement d'un sous-ensemble de vos pipelines les plus critiques vers une autre région en cas de défaillance d'une zone ou d'une région.
  • Dépendances des pipelines de données. Certains pipelines de données reposent sur des données générées par un autre pipeline de données. Lorsque vous divisez des pipelines en sprints de migration, veillez à prendre en compte les dépendances de données.
  • Ensembles de données générés et utilisés. Pour chaque pipeline de données, identifiez les ensembles de données utilisés par le pipeline et les ensembles de données qu'il génère. Cela vous permet d'identifier les dépendances entre les pipelines et entre d'autres systèmes ou composants de votre architecture globale.

Les éléments suivants que vous évaluez dans votre inventaire sont axés sur les ensembles de données à migrer :

  • Ensembles de données. Identifiez les ensembles de données à migrer vers l'environnement cible. Vous pouvez déterminer que certaines données historiques ne sont pas nécessaires à la migration ou qu'elles doivent être migrées à un autre moment, si les données sont archivées et ne sont pas utilisées activement. En définissant le champ d'application du processus de migration et les sprints de migration, vous pouvez réduire les risques liés à la migration.
  • Tailles des données. Si vous prévoyez de compresser des fichiers avant de les transférer, veillez à bien noter la taille des fichiers avant et après compression. La taille de vos données a une incidence sur le temps et les coûts nécessaires pour copier les données depuis la source vers la destination. Ces facteurs vous aideront à choisir entre les différentes stratégies de temps d'arrêt, comme décrit plus loin dans ce document.
  • Structure des données. Classez chaque ensemble de données à migrer et assurez-vous de bien comprendre si les données sont structurées, semi-structurées ou non structurées. Une bonne compréhension de la structure des données peut vous aider à vérifier que les données sont migrées correctement et entièrement.

Terminer l'évaluation

Après avoir créé les inventaires liés à vos charges de travail et clusters Kubernetes, accomplissez les autres étapes de la phase d'évaluation décrites dans la page Migrer vers Google Cloud : évaluer et découvrir vos charges de travail.

Planifier et établir vos fondations

La phase de planification et de création de votre migration vers Google Cloud comprend les tâches suivantes :

  1. Créez une hiérarchie de ressources.
  2. Configurer Identity and Access Management (IAM)
  3. Configurer la facturation
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurer la journalisation, la surveillance et les alertes

Pour en savoir plus sur chacune de ces tâches, consultez la page Migrer vers Google Cloud : établir vos fondations.

Migrer des données et des pipelines de données

Les sections suivantes décrivent certains aspects du plan de migration des données et des pipelines de données par lot. Elles définissent certains concepts liés aux caractéristiques des pipelines de données qu'il est important de comprendre lors de la création du plan de migration. Ils abordent également certains concepts de tests de données qui peuvent vous aider à améliorer la confiance dans la migration des données.

Plan de migration

Dans votre plan de migration, vous devez inclure du temps pour terminer le transfert des données. Votre plan doit tenir compte de la latence du réseau, du temps nécessaire pour tester l'exhaustivité des données et pour obtenir les données qui ont échoué lors de la migration, ainsi que les coûts du réseau. Étant donné que les données seront copiées d'une région à une autre, votre plan de coûts réseau doit inclure les coûts de réseau interrégionaux.

Nous vous recommandons de diviser les différents pipelines et ensembles de données en sprints et de les migrer séparément. Cette approche permet de réduire les risques pour chaque sprint de migration et de les améliorer individuellement. Pour améliorer votre stratégie de migration et détecter les problèmes plus tôt, nous vous recommandons de hiérarchiser les charges de travail plus petites et non critiques avant de migrer des charges de travail plus importantes et plus critiques.

Un autre élément important d'un plan de migration consiste à décrire la stratégie, les dépendances et la nature des différents pipelines de données au sein de la couche de calcul. Si votre couche de stockage de données et votre couche de calcul de données sont basées sur le même système, nous vous recommandons de surveiller les performances du système pendant la copie des données. En règle générale, la copie de grandes quantités de données peut entraîner des frais d'E/S sur le système et dégrader les performances au sein de la couche de calcul. Par exemple, si vous exécutez une charge de travail pour extraire des données d'un cluster Kafka par lots, les opérations d'E/S supplémentaires pour lire de grandes quantités de données peuvent dégrader les performances des pipelines de données actifs qui sont toujours en cours d'exécution dans l'environnement source. Dans ce type de scénario, vous devez surveiller les performances du système à l'aide de métriques intégrées ou personnalisées. Pour éviter de surcharger le système, nous vous recommandons de planifier une mise hors service de certaines charges de travail pendant le processus de copie des données ou de limiter la phase de copie.

Étant donné que la copie de données fait de la migration un processus de longue durée, nous vous recommandons de disposer de plans d'urgence pour résoudre les problèmes qui pourraient survenir lors de la migration. Par exemple, si le transfert de données prend plus de temps que prévu ou si les tests d'intégrité échouent avant la mise en ligne du nouveau système, déterminez si vous souhaitez effectuer un rollback ou essayer de corriger et de relancer les opérations ayant échoué. Bien qu'un rollback puisse être une solution plus propre, il peut être chronophage et coûteux de copier plusieurs ensembles de données volumineux à plusieurs reprises. Nous vous recommandons de disposer d'une compréhension claire et de tests prédéfinis pour déterminer l'action à effectuer dans quelles conditions, le temps nécessaire pour tenter de créer des correctifs et à quel moment effectuer un rollback complet.

Il est important de faire la distinction entre les outils et les scripts que vous utilisez pour la migration, et les données que vous copiez. Effectuer un rollback du transfert de données signifie que vous devez copier à nouveau les données et que vous devez remplacer ou supprimer les données que vous avez déjà copiées. Effectuer un rollback des modifications d'outils et de scripts est potentiellement plus facile et moins coûteux, mais les modifications apportées aux outils peuvent vous obliger à copier à nouveau les données. Par exemple, vous devrez peut-être copier à nouveau les données si vous créez un chemin d'accès cible dans un script qui génère un emplacement Cloud Storage de manière dynamique. Pour éviter de copier des données à nouveau, créez vos scripts de façon à permettre la reprise et l'idempotence.

Caractéristiques du pipeline de données

Pour créer un plan de migration optimal, vous devez comprendre les caractéristiques de différents pipelines de données. Il est important de garder à l'esprit que les pipelines de traitement par lot qui écrivent des données sont différents des pipelines par lot qui lisent des données :

  • Pipelines de données qui écrivent des données : étant donné que cela modifie l'état du système source, il peut être difficile d'écrire des données dans l'environnement source en même temps que les données sont copiées sur l'environnement cible. Considérez les environnements d'exécution des pipelines qui écrivent des données et essayez de hiérarchiser leur migration plus tôt dans le processus global. Vous pourrez ainsi préparer les données dans l'environnement cible avant de migrer les pipelines qui les lisent.
  • Pipelines de données qui lisent des données : les pipelines qui lisent des données peuvent avoir des exigences différentes en ce qui concerne la fraîcheur des données. Si les pipelines qui génèrent des données sont arrêtés sur le système source, les pipelines qui lisent des données peuvent éventuellement s'exécuter pendant la copie des données dans l'environnement cible.

Les données sont avec état, et la copie de données entre régions n'est pas une opération atomique. Par conséquent, vous devez être conscient des changements d'état pendant la copie des données.

Il est également important de différencier les systèmes dans le plan de migration. Vos systèmes peuvent avoir des exigences fonctionnelles et non fonctionnelles différentes (par exemple, un système pour le traitement par lot et un autre pour la diffusion). Par conséquent, votre plan doit inclure différentes stratégies pour migrer chaque système. Veillez à spécifier les dépendances entre les systèmes et la manière dont vous allez réduire les temps d'arrêt de chaque système lors de chaque phase de migration.

Un plan type de sprint de migration doit comprendre les éléments suivants :

  • Stratégie générale. Décrivez la stratégie de gestion de la migration dans ce sprint. Pour connaître les stratégies courantes, consultez la page Déployer vos charges de travail.
  • Liste des outils et des méthodes pour la copie de données et le déploiement de ressources. Spécifiez les outils que vous prévoyez d'utiliser pour copier des données ou déployer des ressources dans l'environnement cible. Cette liste doit inclure des scripts personnalisés qui permettent de copier des éléments Cloud Storage, des outils standards tels que gsutil et des outils Google Cloud tels que les services de migration.
  • Liste des ressources à déployer dans l'environnement cible. Regroupez toutes les ressources à déployer dans l'environnement cible. Cette liste doit inclure tous les composants de l'infrastructure de données, tels que les buckets Cloud Storage, les ensembles de données BigQuery et les clusters Dataproc. Dans certains cas, les sprints de migration anticipés incluent le déploiement d'un cluster dimensionné (tel qu'un cluster Dataproc) dans une capacité plus faible, tandis que les sprints suivants incluent un redimensionnement en fonction des nouvelles charges de travail. Assurez-vous que votre plan inclut un potentiel redimensionnement.
  • Liste des ensembles de données à copier. Pour chaque ensemble de données, veillez à spécifier les informations suivantes :
    • Ordre de copie (le cas échéant) : pour la plupart des stratégies, l'ordre d'opération peut être important. La stratégie de maintenance planifiée décrite plus loin dans ce document constitue une exception.
    • Size (Taille)
    • Statistiques clés : graphique illustrant des statistiques clés, telles que le numéro de ligne, qui peut vous aider à vérifier que l'ensemble de données a bien été copié.
    • Temps estimé à copier : durée du transfert de données, en fonction du plan de migration.
    • Méthode à copier : consultez la liste des outils et des méthodes plus haut dans ce document.
    • Tests de validation : regroupez explicitement les tests que vous prévoyez d'effectuer pour vérifier que les données ont été entièrement copiées.
    • Plan d'urgence : décrivez la procédure à suivre en cas d'échec des tests de validation. Votre plan d'urgence doit spécifier à quel moment réessayer et reprendre la copie ou remplir les données manquantes, et à quel moment effectuer un rollback complet et copier à nouveau l'ensemble de données complet.

Testing

Cette section décrit des exemples typiques de tests que vous pouvez planifier. Les tests peuvent vous aider à assurer l'intégrité et l'exhaustivité des données. Ils peuvent également vous aider à garantir que la couche de calcul fonctionne comme prévu et qu'elle est prête à exécuter vos pipelines de données.

  • Synthèse ou comparaison de hachage : pour valider l'exhaustivité des données après une copie, vous devez comparer l'ensemble de données d'origine à la nouvelle copie dans l'environnement cible. Si les données sont structurées dans des tables BigQuery, vous ne pouvez pas joindre les deux tables dans une requête pour voir si toutes les données existent, car elles se trouvent dans des régions différentes. En raison des coûts et de la latence, BigQuery n'autorise pas les requêtes à joindre des données entre les régions. Au lieu de cela, la méthode de comparaison doit synthétiser chaque ensemble de données et comparer les résultats. Selon la structure de l'ensemble de données, la méthode de synthèse peut être différente. Par exemple, une table BigQuery peut utiliser une requête d'agrégation, mais un ensemble de fichiers sur Cloud Storage peut utiliser un pipeline Spark pour calculer un hachage pour chaque fichier, puis agréger les hachages.

  • Flux Canary : les flux Canary activent les jobs conçus pour valider l'intégrité et l'exhaustivité des données. Avant de poursuivre avec les cas d'utilisation commerciaux comme l'analyse de données, il peut être utile d'exécuter des jobs de flux Canary pour vous assurer que les données d'entrée sont conformes à un ensemble de conditions préalables. Vous pouvez mettre en œuvre des flux Canary en tant que pipelines de données personnalisés ou en tant que flux dans un DAG basé sur Cloud Composer. Les flux Canary peuvent vous aider à effectuer des tâches, comme vérifier qu'il ne manque aucune valeur pour certains champs, ou que le nombre de lignes d'ensembles de données spécifiques correspond au nombre attendu.

    Vous pouvez également utiliser des flux Canary pour créer des condensés ou d'autres agrégations d'une colonne ou d'un sous-ensemble de données. Vous pouvez ensuite utiliser le flux Canary pour comparer les données à un condensé ou à une agrégation similaire provenant de la copie des données.

    Les méthodes de flux Canary sont utiles lorsque vous devez évaluer la précision des données stockées et copiées dans des formats de fichiers, tels que des fichiers Avro sur Cloud Storage. Les flux Canary ne génèrent normalement pas de nouvelles données, mais ils échouent si un ensemble de règles n'est pas respecté dans les données d'entrée.

  • Environnement de test : une fois votre plan de migration terminé, vous devez tester le plan dans un environnement de test. L'environnement de test doit inclure la copie de données échantillonnées ou de données de préproduction dans une autre région, afin d'estimer le temps nécessaire à la copie des données sur le réseau. Ces tests vous aident à identifier les problèmes liés au plan de migration et à vérifier que les données peuvent être migrées correctement. Les tests doivent inclure des tests fonctionnels et non fonctionnels. Les tests fonctionnels vérifient que les données sont correctement migrées. Les tests non fonctionnels vérifient que la migration répond aux exigences de performances, de sécurité et autres exigences non fonctionnelles. Chaque étape de migration de votre plan doit inclure un critère de validation qui détaille à quel moment l'étape peut être considérée comme terminée.

Pour vous aider à valider les données, vous pouvez utiliser l'outil de validation des données. L'outil effectue des fonctions de validation des données à plusieurs niveaux, du niveau des tables au niveau des lignes, et vous aide à comparer les résultats de vos systèmes source et cible.

Vos tests doivent vérifier le déploiement de la couche de calcul et tester les ensembles de données qui ont été copiés. Pour ce faire, vous devez créer un pipeline de test capable de calculer certaines agrégations des ensembles de données copiés et vous assurer que les ensembles de données source et cible correspondent. Une incohérence entre les ensembles de données source et cible est plus courante lorsque les fichiers que vous copiez sur plusieurs régions ne sont pas des représentations exactes de copie d'octets entre les systèmes source et cible (par exemple, lorsque vous modifiez les formats de fichiers ou les compressions de fichiers).

Prenons l'exemple d'un ensemble de données composé de fichiers JSON délimités par un retour à la ligne. Les fichiers sont stockés dans un bucket Cloud Storage et sont installés en tant que table externe dans BigQuery. Pour réduire la quantité de données déplacées sur le réseau, vous pouvez effectuer une compression Avro au sein de la migration avant de copier des fichiers dans l'environnement cible. Cette conversion présente de nombreux avantages mais aussi des risques, car les fichiers écrits dans l'environnement cible ne sont pas une représentation exacte de copie d'octets des fichiers de l'environnement source.

Pour atténuer les risques du scénario de conversion, vous pouvez créer un job Dataflow ou utiliser BigQuery pour calculer des agrégations et des hachages de sommes de contrôle de l'ensemble de données (par exemple, en calculant des sommes, des moyennes ou des quantiles pour chaque colonne numérique). Pour les colonnes de chaîne, vous pouvez calculer des agrégations sur la longueur de la chaîne ou sur le code de hachage de cette chaîne. Pour chaque ligne, vous pouvez calculer un hachage agrégé à partir d'une combinaison de toutes les autres colonnes, ce qui permet de vérifier avec une grande justesse qu'une ligne est identique à son origine. Ces calculs sont effectués à la fois dans les environnements source et cible, puis ils sont comparés. Dans certains cas, par exemple si votre ensemble de données est stocké dans BigQuery, vous ne pouvez pas joindre de tables issues des environnements source et cible, car ils se trouvent dans des régions différentes. Vous devez donc utiliser un client capable de se connecter aux deux environnements.

Vous pouvez mettre en œuvre les méthodes de test précédentes dans BigQuery ou en tant que job par lot (comme dans Dataflow). Vous pouvez ensuite exécuter les jobs d'agrégation et comparer les résultats calculés pour l'environnement source avec ceux calculés pour l'environnement cible. Cette approche peut vous aider à vous assurer que les données sont complètes et exactes.

Un autre aspect important du test de la couche de calcul consiste à exécuter des pipelines comprenant toutes sortes de moteurs de traitement et de méthodes de calcul. Tester le pipeline est moins important pour les moteurs de calcul gérés comme BigQuery ou Dataflow. Toutefois, il est important de tester le pipeline pour les moteurs de calcul non gérés comme Dataproc. Par exemple, si vous disposez d'un cluster Dataproc qui gère plusieurs types de calculs différents, tels qu'Apache Spark, Apache Hive, Apache Flink ou Apache MapReduce, vous devez tester chaque environnement d'exécution pour vous assurer que les différents types de charges de travail sont prêts à être transférés.

Stratégies de migration

Une fois que vous avez vérifié votre plan de migration avec les tests appropriés, vous pouvez migrer les données. Lorsque vous migrez des données, vous pouvez utiliser différentes stratégies pour différentes charges de travail. Vous trouverez ci-dessous des exemples de stratégies de migration que vous pouvez utiliser telles quelles ou personnaliser selon vos besoins :

  • Maintenance planifiée : vous planifiez le moment où votre intervalle de basculement se produit. Cette stratégie est adaptée lorsque les données sont fréquemment modifiées, mais les SLO et les SLA peuvent supporter des temps d'arrêt. Cette stratégie offre une fiabilité élevée des données transférées, car elles sont complètement obsolètes pendant leur copie. Pour en savoir plus, consultez la section Maintenance planifiée de la page "Migration vers Google Cloud : transférer vos ensembles de données volumineux".
  • Basculement en lecture seule : légère variante de la stratégie de maintenance planifiée, dans laquelle la plate-forme de données du système source permet aux pipelines de données en lecture seule de continuer à lire les données pendant leur copie. Cette stratégie est utile, car certains pipelines de données peuvent continuer à fonctionner et fournir des insights aux systèmes finaux. En revanche, avec cette stratégie, les données produites lors de la migration sont obsolètes, car les données sources ne sont pas mises à jour. Par conséquent, vous devrez peut-être utiliser une stratégie de rattrapage après la migration pour tenir compte des données obsolètes dans les systèmes finaux.
  • Entièrement actif : vous copiez les données à un code temporel spécifique, tandis que l'environnement source est toujours actif pour les pipelines de données en lecture et en écriture. Après avoir copié les données et basculé vers le nouveau déploiement, vous effectuez une phase de copie delta pour obtenir les données générées après le code temporel de migration dans l'environnement source. Cette approche nécessite plus de coordination et de considération que les autres stratégies. Par conséquent, votre plan de migration doit inclure la manière dont vous allez gérer les opérations de mise à jour et de suppression sur les données sources.
  • Double écriture : les pipelines de données peuvent s'exécuter dans les environnements source et cible pendant que les données sont copiées. Cette stratégie évite la phase de copie delta requise pour remplir les données si vous utilisez les stratégies entièrement actives ou en lecture seule. Toutefois, pour vous assurer que les pipelines de données produisent des résultats identiques, une stratégie de double écriture nécessite davantage de tests avant la migration. Si vous n'effectuez pas de tests avancés, vous rencontrerez des problèmes en essayant de consolider un scénario de split-brain. La stratégie de double écriture entraîne également des coûts potentiels liés à l'exécution des mêmes charges de travail deux fois dans des régions différentes. Cette stratégie peut migrer votre plate-forme sans aucun temps d'arrêt, mais elle nécessite une plus grande coordination pour l'exécuter correctement.

Tests post-migration

Une fois la migration terminée, vous devez tester l'exhaustivité des données et la validité des pipelines de données. Si vous terminez votre migration en sprints, vous devez effectuer ces tests après chaque sprint. Les tests que vous effectuez à cette étape sont semblables aux tests d'intégration : vous testez la validité d'un pipeline de données qui exécute des cas d'utilisation commerciaux avec des données de niveau production complet en tant qu'entrées, puis vous inspectez le résultat pour évaluer la validité. Vous pouvez comparer le résultat du test d'intégration avec celui de l'environnement source en exécutant le même pipeline de données dans l'environnement source et dans l'environnement cible. Ce type de test ne fonctionne que si le pipeline de données est déterministe et que si vous pouvez vous assurer que les entrées dans les deux environnements sont identiques.

Vous pouvez vérifier que les données sont complètes lorsqu'elles répondent à un ensemble de critères prédéfinis, dans lesquels les données de l'environnement source sont égales (ou suffisamment similaires) aux données de l'environnement cible. Selon la stratégie utilisée dans la section précédente, les données peuvent ne pas présenter une correspondance un à un. Par conséquent, vous devez prédéfinir des critères pour décrire l'exhaustivité des données pour votre cas d'utilisation. Par exemple, pour les données de séries temporelles, vous pouvez considérer que les données sont complètes lorsque l'enregistrement le plus récent ne date pas de plus de cinq minutes par rapport au code temporel actuel.

Basculement

Après avoir vérifié et testé les données et les pipelines de données dans l'environnement cible, vous pouvez démarrer la phase de basculement. Lors de cette phase, les clients peuvent avoir besoin de modifier leur configuration pour faire référence aux nouveaux systèmes. Dans certains cas, la configuration ne peut pas être identique à celle qui pointe vers le système source. Par exemple, si un service doit lire des données à partir d'un bucket Cloud Storage, les clients doivent modifier la configuration pour le bucket à utiliser. Les noms de buckets Cloud Storage étant uniques, le bucket Cloud Storage cible est différent de l'environnement source.

Pendant la phase de basculement, vous devez mettre hors service les charges de travail de l'environnement source et annuler leur planification. Nous vous recommandons de conserver les données de l'environnement source pendant un certain temps, au cas où vous auriez besoin d'effectuer un rollback.

La phase de test de pré-migration n'est pas aussi complète qu'une exécution en production d'un pipeline de données. Par conséquent, une fois le basculement terminé et le système cible opérationnel, vous devez surveiller les métriques, les environnements d'exécution et les sorties sémantiques de vos pipelines de données. Cette surveillance vous aidera à détecter les erreurs que votre phase de test a peut-être manquées et à garantir la réussite de la migration.

Optimiser votre environnement

L'optimisation est la dernière phase de votre migration. Dans cette phase, vous améliorez l'efficacité de votre environnement en exécutant plusieurs itérations d'une boucle reproductible jusqu'à ce que votre environnement réponde à vos exigences d'optimisation :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud, consultez la page Migration vers Google Cloud : optimiser votre environnement.

Préparer vos données et vos ressources de calcul Google Cloud en vue d'une migration sur plusieurs régions

Cette section présente les données et les ressources de calcul sur Google Cloud, ainsi que les principes de conception permettant de préparer une migration sur plusieurs régions.

BigQuery

Étant donné que BigQuery est un entrepôt de données SQL sans serveur, vous n'avez pas besoin de déployer la couche de calcul. Si certains de vos clients BigQuery spécifient des régions pour le traitement, vous devez ajuster ces clients en conséquence. Sinon, BigQuery est identique dans les environnements source et cible. Les données BigQuery sont stockées dans deux types de tables :

  • Tables BigQuery : tables au format BigQuery. BigQuery gère automatiquement les fichiers de données. Pour en savoir plus sur la migration de données au format BigQuery, consultez la page Gérer les ensembles de données.
  • Tables externes BigQuery : tables pour lesquelles les données sont stockées en dehors de BigQuery. Une fois les données transférées, vous devrez recréer les tables externes dans la nouvelle destination. Pour plus d'informations sur la migration de tables externes, consultez la page Présentation des tables externes.

Cloud Storage

Cloud Storage propose un service de transfert de stockage qui peut vous aider à migrer vos données.

Dataflow (lot de données)

Dataflow est un moteur de traitement de données géré par Google. Pour simplifier votre migration Dataflow et vous assurer que vos jobs peuvent être facilement déployés dans n'importe quelle région, vous devez injecter toutes les entrées et sorties en tant que paramètres de votre job. Au lieu d'écrire les emplacements de données d'entrée et de sortie dans votre code source, nous vous recommandons de transmettre les chemins d'accès Cloud Storage et les chaînes de connexion à la base de données en tant qu'arguments ou paramètres.

Dataproc

Dataproc est un environnement Apache Hadoop géré qui peut exécuter n'importe quelle charge de travail compatible avec le framework Apache Hadoop. Il est compatible avec les frameworks comme Apache Spark, Apache Flink et Apache Hive.

Dataproc peut être utilisé des manières suivantes, qui ont un impact sur le processus de migration de votre environnement Dataproc sur plusieurs régions :

  • Clusters éphémères avec des données sur Cloud Storage : les clusters sont conçus pour exécuter des jobs spécifiques et sont détruits une fois les jobs terminés. Cela signifie que la couche HDFS ou tout autre état du cluster est également détruit. Si votre configuration répond aux critères suivants, ce type d'utilisation est plus facile à migrer que les autres types :
    • Les entrées et les sorties de vos jobs ne sont pas codées en dur dans le code source. Au lieu de cela, vos jobs reçoivent des entrées et des sorties en tant qu'arguments.
    • Le provisionnement de l'environnement Dataproc est automatisé, y compris les configurations des frameworks individuels que votre environnement utilise.
  • Clusters de longue durée avec des données externes : vous disposez d'un ou de plusieurs clusters, mais ce sont des clusters de longue durée. Même s'il n'y a aucun job en cours d'exécution sur ce type de cluster, il reste opérationnel. Les données et le calcul sont séparés, car les données sont enregistrées en dehors du cluster dans des solutions Google Cloud comme Cloud Storage ou BigQuery. En règle générale, ce modèle est efficace lorsqu'il y a toujours des jobs en cours d'exécution sur le cluster. Il n'est donc pas logique de supprimer et de configurer les clusters comme dans le modèle éphémère. Comme les données et le calcul sont séparés, la migration est semblable à celle du modèle éphémère.
  • Clusters de longue durée avec des données dans le cluster : le cluster est de longue durée, mais il conserve également l'état, les données ou les deux, le plus souvent en tant que données sur HDFS. Ce type d'utilisation complique la migration, car les données et le calcul ne sont pas séparés. Si vous migrez l'un sans l'autre, le risque de créer des incohérences est élevé. Dans ce scénario, envisagez de déplacer les données et l'état en dehors du cluster avant la migration pour séparer les deux. Si cela est impossible, nous vous recommandons d'utiliser la stratégie de maintenance planifiée afin de réduire le risque d'incohérences dans vos données.

Étant donné qu'il existe de nombreux frameworks potentiels, et de nombreuses versions et configurations de ces frameworks, vous devez réaliser des tests approfondis avant d'exécuter votre plan de migration.

Cloud Composer

Cloud Composer est la version gérée d'Apache Airflow sur Google Cloud, pour l'orchestration et la planification des flux. Les DAG, les configurations et les journaux sont gérés dans un bucket Cloud Storage qui doit être migré avec votre déploiement Cloud Composer. Afin de migrer l'état de votre déploiement Cloud Composer, vous pouvez enregistrer et charger des instantanés d'environnement.

Si vous avez déployé des plug-ins personnalisés sur votre instance Cloud Composer, nous vous recommandons d'appliquer une méthodologie d'infrastructure as Code pour recréer l'environnement de manière entièrement automatisée.

Cloud Composer ne gère pas les données, mais il active d'autres frameworks et plates-formes de traitement des données. Par conséquent, la migration vers Cloud Composer peut être complètement isolée des données. Étant donné que Cloud Composer ne traite pas non plus les données, votre déploiement ne doit pas nécessairement se trouver dans la même région que les données. Par conséquent, vous pouvez créer un déploiement Cloud Composer dans l'environnement cible, mais continuer à exécuter des pipelines dans l'environnement source. Dans certains cas, cela peut être utile pour exploiter différents pipelines dans différentes régions pendant la migration de la plate-forme entière.

Cloud Data Fusion

Cloud Data Fusion est un outil d'intégration visuelle qui vous aide à créer des pipelines de données à l'aide d'un éditeur visuel. Cloud Data Fusion est basé sur le projet Open Source CDAP. Comme Cloud Composer, Cloud Data Fusion ne gère pas les données elles-mêmes, mais il active d'autres frameworks et plates-formes de traitement des données. Vous devez exporter vos pipelines Cloud Data Fusion depuis l'environnement source et les importer dans l'environnement cible de l'une des manières suivantes :

Selon la quantité de flux que vous devez migrer, vous pouvez préférer une méthode à l'autre. L'utilisation de l'API CDAP pour créer un script de migration peut s'avérer difficile et nécessite davantage de compétences en ingénierie logicielle. Toutefois, si vous avez de nombreux flux ou si ceux-ci changent relativement fréquemment, un processus automatisé peut être la meilleure approche.

Étape suivante

Contributeurs

Auteurs :

Autres contributeurs :

Pour consulter les profils LinkedIn non publics, connectez-vous à LinkedIn.