Migrer vers Google Cloud: bonnes pratiques pour valider un plan de migration

Last reviewed 2025-05-05 UTC

Ce document décrit les bonnes pratiques pour valider le plan de migration de vos charges de travail vers Google Cloud. Ce document ne répertorie pas toutes les bonnes pratiques possibles pour valider un plan de migration, et ne constitue pas une garantie de résultat. Sa fonction est de vous aider à susciter le débat sur les modifications et améliorations potentielles de votre plan de migration.

Ce document est utile si vous planifiez une migration vers Google Clouddepuis un environnement sur site, un environnement d'hébergement privé ou un autre fournisseur cloud. Ce document est également utile si vous souhaitez évaluer une opportunité de migration, et découvrir à quoi elle pourrait ressembler.

Ce document fait partie d'une série d'articles sur la migration versGoogle Cloud :

Évaluation

L'évaluation complète de vos charges de travail et environnements vous aide à acquérir une connaissance approfondie de vos charges de travail et de vos environnements. L'acquisition de ces connaissances va vous aider à réduire les risques de problèmes pendant et après votre migration vers Google Cloud.

Effectuer une évaluation complète

Avant de passer aux étapes qui suivent la phase d'évaluation, effectuez l'évaluation de vos charges de travail et environnements. Pour effectuer une évaluation complète, tenez compte des éléments suivants, qui sont souvent négligés :

  • Inventaire : assurez-vous que l'inventaire des charges de travail à migrer est à jour et que vous en avez effectué l'évaluation. Tenez compte par exemple du degré d'actualisation et de la fiabilité des données sources pour votre évaluation, ainsi qu'aux lacunes qui pourraient exister dans ces données.

  • Temps d'arrêt : identifiez les charges de travail pouvant supporter des temps d'arrêt. Déterminez quand ces temps d'arrêt peuvent se produire et combien de temps ils peuvent durer pour minimiser les perturbations (par exemple, en fin de soirée ou le week-end). Il est plus difficile de migrer des charges de travail avec des temps d'arrêt nuls ou quasi-nuls que des charges de travail qui peuvent se permettre de subir des temps d'arrêt. Pour effectuer une migration sans temps d'arrêt, vous devez concevoir et mettre en œuvre une redondance pour chaque charge de travail à migrer. Vous devez également coordonner ces instances redondantes.

    Lorsque vous évaluez les temps d'arrêt pouvant être supportés par une charge de travail, déterminez si les avantages commerciaux d'une migration sans temps d'arrêt sont supérieurs à la complexité accrue de la migration. Dans la mesure du possible, évitez de définir une exigence de temps d'arrêt nuls pour une charge de travail.

  • Clustering et redondance : évaluez les charges de travail compatibles avec le clustering et la redondance. Si une charge de travail est compatible avec le clustering et la redondance, vous pouvez déployer plusieurs instances de cette charge, même dans différents environnements, tels que l'environnement source et l'environnement cible. Les déploiements en cluster et redondants peuvent simplifier la migration, car ces charges de travail se coordonnent entre elles avec une intervention limitée.

  • Mises à jour de la configuration : évaluez la manière dont vous mettez à jour la configuration de vos charges de travail. Par exemple, réfléchissez à la manière de diffuser les mises à jour de la configuration de chaque charge de travail que vous souhaitez migrer. Ce point est essentiel au succès de votre migration, car vous devrez peut-être mettre à jour la configuration de vos charges de travail pendant leur migration vers l'environnement cible.

  • Générer plusieurs rapports d'évaluation : pendant la phase d'évaluation, il peut être utile de générer plusieurs rapports d'évaluation pour tenir compte de différents scénarios. Par exemple, vous pouvez générer des rapports pour prendre en compte différents profils de charge pour vos charges de travail (horaires de pics d'activité et de faible activité, par exemple).

Évaluer les modes de défaillance acceptés par vos charges de travail

Connaître le comportement de vos charges de travail dans des circonstances exceptionnelles vous permet de vous assurer de ne pas les exposer à des conditions empêchant toute faculté de récupération. Pour l'évaluation, rassemblez des informations sur les modes de défaillance et leurs effets, qui sont acceptés par vos charges de travail et compatibles avec une récupération automatique, et sur les modes de défaillance nécessitant votre intervention. Par exemple, vous pouvez commencer par vous poser des questions sur les modes de défaillance possibles, telles que celles-ci :

  • Que se passe-t-il si une charge de travail perd la connectivité au réseau ?
  • Une charge de travail peut-elle reprendre là où elle s'était arrêtée après son arrêt ?
  • Que se passe-t-il si les performances d'une charge de travail ou de ses dépendances sont inappropriées ?
  • Que se passe-t-il si l'architecture mêle deux charges de travail ayant le même identifiant ?
  • Que se passe-t-il si une tâche planifiée n'est pas exécutée ?
  • Que se passe-t-il si deux charges de travail traitent le même message ?

Le plan de migration lui-même constitue une autre source de modes de défaillance non acceptés. Déterminez si votre plan de migration inclut des étapes qui dépendent de la validation d'une condition particulière, et s'il inclut une planification de contingence en cas de condition non validée. Un plan qui inclut ces types de conditions peut indiquer que le plan lui-même peut échouer ou que des composants individuels peuvent échouer lors de la migration.

Après avoir évalué ces modes de défaillance et leurs effets, validez vos résultats dans un environnement non critique en simulant des défaillances et en injectant des pannes qui émulent ces modes de défaillance. Par exemple, si une charge de travail est conçue pour assurer une récupération automatique après une perte de connectivité réseau, validez la récupération automatique en procédant à une interruption forcée de la connectivité et en la restaurant par la suite.

Évaluer vos pipelines de traitement de données

Votre évaluation de la charge de travail doit pouvoir apporter des réponses aux questions suivantes :

  • Les ressources sont-elles correctement dimensionnées pour la migration ?
  • Combien de temps faut-il pour migrer les données nécessaires à vos charges de travail ?
  • L'environnement cible peut-il gérer l'intégralité du volume de données ?
  • Comment vos charges de travail se comportent-elles lorsqu'elles doivent gérer les pics de demande ou les pics de quantité de données qu'elles produisent sur une période spécifique ?
  • En cas de pics de demande ou de pics dans la quantité de données produites par vos charges de travail, ceux-ci produisent-ils des effets négatifs, tels qu'une latence accrue ou des retards dans les réponses ?
  • Une fois vos charges de travail démarrées, ont-elles besoin d'un certain délai pour atteindre les niveaux de performances attendus ?

Les résultats de cette évaluation constituent souvent des modèles de la demande satisfaite par vos charges de travail, ainsi que des données produites par celles-ci sur une période donnée. Lorsque vous collectez des points de données pour produire de tels modèles, pensez qu'ils peuvent varier considérablement entre les périodes de pic et les périodes creuses. Pour en savoir plus sur les méthodes de surveillance et les éléments à surveiller, consultez la page Objectifs de niveau de service dans le manuel sur l'ingénierie de la fiabilité des sites.

Vous assurer de pouvoir mettre à jour et déployer chaque charge de travail à migrer

Pendant la migration, vous devrez peut-être mettre à jour certaines des charges de travail que vous migrez. Par exemple, vous devrez peut-être déployer un correctif pour un problème ou effectuer un rollback sur une modification récente qui pose problème. Pour chaque charge de travail que vous migrez, assurez-vous de pouvoir appliquer et déployer des modifications. Par exemple, si vous migrez une charge de travail pour laquelle vous disposez du code source, assurez-vous d'avoir accès à ce code source, et de pouvoir compiler, empaqueter et déployer le code source si nécessaire.

Votre migration peut inclure des charges de travail auxquelles vous ne pouvez pas appliquer ni déployer de modifications, telles que des logiciels préexistants et prêts à l'emploi. Dans ce scénario, refactorisez votre plan de migration afin d'y intégrer les démarches supplémentaires à mener afin d'atténuer les problèmes qui pourraient survenir après la migration de ces charges de travail.

Évaluer votre infrastructure réseau

Une infrastructure réseau fonctionnelle est essentielle à une migration réussie. Vous pouvez utiliser l'infrastructure réseau comme l'un de vos outils de migration. Par exemple, vous pouvez utiliser des équilibreurs de charge et des serveurs DNS pour diriger le trafic en fonction de votre plan de migration.

Pour éviter les problèmes lors de la migration, il est important d'évaluer votre infrastructure réseau et d'évaluer dans quelle mesure elle peut accepter votre migration. Par exemple, vous pouvez commencer par vous poser ces questions sur votre infrastructure d'équilibrage de charge :

  • Que se passe-t-il lorsque vous reconfigurez vos équilibreurs de charge ?
  • Combien de temps faut-il pour que la configuration mise à jour soit prise en compte ?
  • Lors d'une migration sans temps d'arrêt, que se passe-t-il si vous obtenez un pic de trafic avant que la configuration mise à jour ne soit effective ?

Une fois que vous avez abordé les questions concernant votre infrastructure d'équilibrage de charge, posez-vous ensuite les questions suivantes sur votre infrastructure DNS :

  • Quels enregistrements DNS devez-vous mettre à jour pour qu'ils pointent vers l'environnement cible, et quand les mettre à jour ?
  • Quels sont les clients utilisant ces enregistrements DNS ?
  • Comment la valeur TTL (Time To Live) est-elle configurée pour les enregistrements DNS que vous prévoyez de mettre à jour ?
  • Pouvez-vous définir la valeur TTL des enregistrements DNS sur sa valeur minimale en secondes avant d'effectuer la migration ?
  • Vos clients DNS et intermédiaires respectent-ils la valeur TTL des enregistrements DNS que vous prévoyez de mettre à jour ? Par exemple, vos applications disposent-elles d'une mise en cache DNS côté client qui ignore la valeur TTL que vous avez configurée pour la migration ? N'oubliez pas que la résolution DNS implique plusieurs couches de mise en cache. Envisagez d'utiliser le DNS public de Google pour éviter les problèmes de DNS liés à votre FAI.
  • Vos clients DNS respectent-ils la valeur TTL des enregistrements DNS à mettre à jour ? Par exemple, vos applications disposent-elles d'une mise en cache DNS côté client qui ignore la valeur TTL que vous avez configurée pour la migration ?
  • Détectez-vous du trafic dirigé vers votre environnement source même après avoir terminé la migration ?

Envisagez de créer une démonstration de faisabilité

Une démonstration de faisabilité est une petite implémentation préliminaire d'un projet de migration planifié. Il valide la faisabilité, la fonctionnalité et les avantages potentiels de ce projet avant que vous ne vous engagiez à le mettre en œuvre entièrement. Une démonstration de faisabilité vous aide à déterminer si les charges de travail de migration fonctionnent correctement dans l'environnement cible.

Commencez par définir le champ d'application et les critères de réussite spécifiques du POC. Vos critères de réussite peuvent inclure des métriques telles que la compatibilité complète de la charge de travail cible, un temps d'arrêt minimal pour la migration et des exigences de performances spécifiques.

Une fois que vous avez identifié vos critères de réussite, testez et validez votre POC. Dans la documentation de votre plan de migration, consignez vos conclusions, les difficultés que vous avez rencontrées et les solutions potentielles à ces difficultés.

Envisagez de créer un POC lorsque vous souhaitez étudier les domaines d'intérêt suivants :

  • Validez la faisabilité de la migration : vérifiez que vos applications, charges de travail et données fonctionnent comme prévu dans Google Cloud.
  • Estimez le temps d'arrêt et planifiez le rollback : mesurez le temps d'arrêt nécessaire pour migrer vos charges de travail et transférer les données. Validez vos scénarios de rollback.
  • Affinez le plan de migration : tenez compte des points suivants pour affiner votre plan avant de vous engager dans une migration à grande échelle :
    • Identifier la meilleure approche de migration
    • Identifiez vos besoins en matière de modernisation ou de refactoring de charge de travail.
    • Identifiez les risques ou problèmes potentiels liés à votre migration.
    • Testez la migration.
  • Validez la sécurité et la conformité : assurez-vous que les règles de sécurité, les rôles IAM (Identity and Access Management) et les exigences de conformité pour votre migration correspondent aux besoins de votre organisation.
  • Renforcer la confiance et l'adhésion des parties prenantes : contribuez à la satisfaction des parties prenantes. Un POC réussi renforce la confiance des parties prenantes dans le plan de migration en démontrant des avantages concrets à vos équipes de direction et techniques.
  • Estimez les coûts et les possibilités d'optimisation : estimez les coûts associés à la migration. Explorez les possibilités d'optimisation, par exemple en testant différentes tailles d'environnement cible et différents outils de migration.

Itérer plusieurs preuves de concept. Ajustez les charges de travail cibles et le plan de migration jusqu'à ce que vous créiez un POC qui réponde à vos critères de réussite.

Planification des migrations

Une planification minutieuse de votre migration vous permet d'éviter les problèmes pendant et après celle-ci. La planification vous aide également à tenir compte des tâches imprévues.

Développer une stratégie de rollback pour chaque étape du plan de migration

Au cours de la migration, chacune des étapes du plan de migration que vous exécutez peut entraîner des problèmes imprévus. Pour vous assurer de pouvoir résoudre ces problèmes, préparez une stratégie de rollback pour chaque étape du plan de migration. Pour éviter de perdre du temps lors d'une panne, procédez comme suit :

  • Assurez-vous que vos stratégies de rollback fonctionnent, en examinant et en testant régulièrement chacune d'elles.
  • Définissez une durée d'exécution maximale autorisée pour chaque étape de la migration. Une fois ce délai d'exécution autorisé écoulé, vos équipes vont procéder au rollback de l'étape de migration.

Même si des stratégies de rollback sont prêtes pour chaque étape du plan de migration, certaines de ces étapes peuvent être potentiellement perturbatrices. Une étape potentiellement perturbatrice peut engendrer une perte, de quelque nature que ce soit, même en cas de rollback, par exemple une perte de données. Identifiez les étapes du plan de migration qui sont potentiellement perturbatrices.

Si vous avez automatisé une étape du plan de migration, assurez-vous de disposer d'une procédure planifiée pour chaque étape automatisée, en cas d'échec de l'automatisation. Comme pour les stratégies de rollback, examinez et testez régulièrement chaque procédure planifiée.

Si vous configurez des canaux de communication pour la migration, afin de vous assurer de ne pas être tenu à distance de votre environnement, provisionnez des canaux de secours que vous pouvez utiliser pour effectuer une récupération après une défaillance. Par exemple, si vous configurez une interconnexion partenaire lors de la migration, vous pouvez également configurer un accès de secours via l'Internet public en cas de problème lors du provisionnement et de la configuration.

Planifier la modernisation et l'adaptation de vos charges de travail

Lorsque vous planifiez votre migration vers Google Cloud, n'oubliez pas que la migration et l'intégration de vos charges de travail prennent du temps et peuvent présenter des difficultés. Envisagez de créer un document de présentation qui décrit l'architecture générale de vos charges de travail, y compris des informations sur les sujets suivants :

  • Dépendances vis-à-vis de systèmes externes et de middleware tiers, tels que le stockage, la messagerie et l'hébergement.
  • Mécanismes permettant d'authentifier et d'autoriser les charges de travail.
  • Procédures d'intégration à IAM.
  • Exigences concernant l'environnement d'exécution.
  • Interactions avec les options de couche de stockage, comme Cloud Storage et les bases de donnéesGoogle Cloud .
  • Exigences concernant le volume de transfert de données et la bande passante.
  • Modifications que vous pourriez apporter au code de votre application lors de la migration.
  • Options d'intégration à Google Cloud Observability.

Il peut être nécessaire de moderniser vos charges de travail, par exemple en intégrant des bibliothèquesGoogle Cloud pour l'authentification, l'autorisation, le stockage et l'observabilité. La modernisation des anciennes bibliothèques peut demander des efforts. Prévoyez suffisamment de temps pour tester minutieusement vos charges de travail.

Planifier des déploiements progressifs

Pour réduire l'ampleur des problèmes pouvant survenir lors de la migration, évitez les changements à grande échelle et concevez votre plan de migration dans une optique de déploiement progressif des modifications. Par exemple, planifiez des déploiements et des modifications de configuration progressifs.

Si vous envisagez d'effectuer des déploiements progressifs, réduisez le nombre et la taille de ces modifications afin de réduire le risque de problèmes imprévus résultant de l'application des modifications. Après avoir identifié et résolu les problèmes dans votre premier déploiement de faible envergure, vous pouvez effectuer les déploiements suivants pour des modifications similaires, mais à plus grande échelle.

Alerter les équipes DevOps

Pour réduire l'impact des problèmes pouvant survenir lors d'une migration, avertissez les équipes responsables de la migration des charges de travail. Alertez également les équipes responsables de l'infrastructure des environnements source et cible.

Si vos équipes travaillent dans des fuseaux horaires différents et que vous pratiquez le modèle opérationnel follow-the-sun, assurez-vous des points suivants :

  • Vos équipes couvrent correctement ces fuseaux horaires et couvrent plusieurs périodes de travail consécutives, car elles peuvent ne pas être en mesure de résoudre les problèmes au cours d'une seule période de travail posté.
  • Vos équipes sont prêtes à collecter des informations détaillées sur les problèmes auxquels elles pourraient être confrontées. Cette collecte va fournir aux ingénieurs en poste lors de la prochaine période de travail une vision complète des actions et motivations de l'équipe qui les a précédés.
  • Des membres spécifiques de vos équipes ont été désignés pour assumer la responsabilité d'une période de travail donnée.

Supprimer les ressources de démonstration de faisabilité de l'environnement de production cible

Pour l'évaluation, vous avez peut-être utilisé l'environnement cible pour héberger des tests et des démonstrations de faisabilité. Avant la migration, supprimez les ressources que vous avez créées lors de ces tests et démonstrations de faisabilité dans la zone de production de l'environnement cible.

Vous pouvez conserver les ressources dans une zone hors production de l'environnement cible tandis que la migration est en cours, car elles peuvent vous aider à collecter des informations sur tout problème pouvant survenir pendant la migration. Par exemple, pour diagnostiquer les problèmes qui affectent vos charges de travail de production après la migration, vous pouvez comparer les journaux de configuration et de données de la charge de travail de production aux journaux de configuration et de données des démonstrations de faisabilité et des tests.

Une fois la migration terminée, et après avoir vérifié que l'environnement cible fonctionne comme prévu, vous pouvez supprimer les ressources dans la zone hors production de l'environnement cible.

Définir des critères pour supprimer l'environnement source en toute sécurité

Pour éviter de devoir payer indéfiniment pour l'exécution infinie de deux environnements, définissez les conditions qui doivent être remplies pour supprimer l'environnement source en toute sécurité, par exemple :

  • Toutes les charges de travail, y compris leurs sauvegardes et leurs mécanismes de haute disponibilité et de reprise après sinistre, ont été correctement migrés vers l'environnement cible.
  • Les données migrées vers l'environnement cible sont cohérentes, accessibles et exploitables.
  • La précision et l'exhaustivité des données migrées respectent la norme définie.
  • Les ressources restantes dans l'environnement source ne sont pas des dépendances associées à des charges de travail qui ne relèvent pas du champ d'application de la migration.
  • Les performances de vos charges de travail dans l'environnement cible respectent vos cibles de contrat de niveau de service.
  • Vos systèmes de surveillance indiquent qu'il n'y a aucun trafic réseau vers l'environnement source qui doive être redirigé vers l'environnement cible.
  • Après avoir vérifié que les charges de travail s'exécutent sans problème dans l'environnement cible pendant une période que vous aurez définie, vous êtes certain de ne plus avoir besoin de revenir à l'environnement source.

Prévoyez de mettre à jour tous les documents et tableaux de bord.

Une fois la migration terminée, prévoyez de mettre à jour de manière exhaustive vos runbooks d'opérations de production, vos documents d'assistance et vos tableaux de bord de surveillance. Voici quelques exemples de modifications que vous devrez peut-être apporter à votre documentation :

  • Diagrammes d'architecture : mettez à jour vos diagrammes d'architecture pour refléter l'architecture Google Cloud , en particulier si vous modernisez et refactorisez vos charges de travail.
  • Connexion et authentification : mettez à jour votre documentation sur les méthodes d'authentification, telles qu'IAM, et les configurations réseau pour refléter l'architecture Google Cloud .
  • Sécurité : mettez à jour votre documentation sur les fonctionnalités de sécurité deGoogle Cloud , y compris le chiffrement au repos et en transit, ainsi que les contrôles des accès basés sur IAM.
  • Maintenance et scaling : mettez à jour vos manuels d'exécution des opérations de production sur les périodes de maintenance des services gérés, les procédures de scaling vertical et horizontal, et les bonnes pratiques pour optimiser les performances.
  • Haute disponibilité et basculement : mettez à jour votre documentation pour les configurations à haute disponibilité, les considérations de synchronisation régionale et zonale, et les mécanismes de basculement.
  • Sauvegarde et récupération : mettez à jour vos processus de sauvegarde et de récupération pour les aligner sur ceux compatibles avec Google Cloud et le service Backup and DR. Ces processus incluent les sauvegardes automatiques, les possibilités de récupération à un moment précis, ainsi que les procédures d'exportation et d'importation.
  • Reprise après sinistre : mettez à jour votre plan et vos procédures de reprise après sinistre pour les aligner sur les capacités de reprise après sinistre de Google Cloud , puis testez les procédures mises à jour.
  • Surveillance et journalisation : intégrez Google Cloud Observability à vos tableaux de bord de surveillance et à vos systèmes d'alerte. Mettez à jour votre documentation sur les quotas Cloud et précisez comment interpréter les journaux, les métriques et les alertes.

Opérations

Pour gérer efficacement l'environnement source et cible pendant la migration, vous devez également concevoir vos processus opérationnels.

Surveiller vos environnements

Pour observer le comportement de vos environnements source et cible et vous aider à diagnostiquer les problèmes au fur et à mesure qu'ils surviennent, configurez les éléments suivants :

  • Un système de surveillance permettant de collecter des métriques utiles pour votre scénario.
  • Un système de journalisation permettant d'observer le flux des opérations effectuées par vos charges de travail et les autres composants de vos environnements.
  • Un système d'alerte qui vous avertit avant qu'un événement problématique ne se produise.

Google Cloud Observability accepte l'intégration de fonctionnalités de surveillance, de journalisation et d'alerte pour votre environnementGoogle Cloud .

Étant donné qu'une charge de travail et ses dépendances couvrent plusieurs environnements, vous devrez peut-être envisager d'utiliser plusieurs outils de surveillance et d'alerte pour différents environnements. Tenez compte du moment auquel vous migrez les règles de surveillance et d'alerte sous-jacentes à vos charges de travail. Par exemple, si votre environnement source est configuré pour vous avertir lorsqu'un serveur spécifique est indisponible, l'alerte va se déclencher lorsque vous désactivez intentionnellement ce serveur. Le déclenchement de l'alerte est un comportement certes attendu, mais inutile dans ce contexte. Pour la migration, vous devez ajuster en permanence les alertes pour l'environnement source et les reconfigurer pour l'environnement cible.

Gérer la migration

Pour gérer la migration, vous examinez ses performances afin de collecter des informations que vous pourrez utiliser à titre rétrospectif, une fois la migration terminée. Une fois les informations collectées, vous pouvez vous en servir pour analyser les performances de la migration et préparer les points de données concernant les améliorations potentielles à apporter à vos environnements.

Par exemple, pour commencer à planifier la gestion de la migration, posez-vous les questions suivantes :

  • Combien de temps a pris chaque étape du plan de migration ?
  • Certaines étapes du plan de migration ont-elles pris plus de temps que prévu ?
  • Y a-t-il eu certaines étapes ou vérifications qui n'ont pas été menées, et qui auraient dû l'être ?
  • Des événements défavorables se sont-ils produits lors de la migration ?

Étapes suivantes

Contributeurs

Auteur : Marco Ferrari | Architecte de solutions cloud

Autre contributeur : Alex Cârciu | Architecte de solutions