Google PCA: Migration, modernisation et stratégie de cloud hybride — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Une stratégie de migration, de modernisation et de cloud hybride réussie aligne les choix de plateforme sur les résultats métier tout en gérant les risques liés à la disponibilité, à l’intégrité des données, à la latence, à la sécurité et aux coûts. La trajectoire équilibre un rehost rapide pour réduire les risques liés au datacenter avec un refactoring ciblé pour tirer parti des avantages du cloud. Le modèle opérationnel doit évoluer parallèlement à la technologie pour pérenniser les améliorations. Cette section fournit un plan pragmatique pour l’évaluation et la planification par vagues, les cadres de décision, les mécanismes de migration, l’intégration hybride, les modèles de modernisation, les considérations relatives aux politiques et au multi-cloud, et l’optimisation post-migration, en mettant l’accent sur les modes de défaillance et les compromis.

Évaluation, Préparation et Planification par Vagues

• Découverte et analyse des dépendances

  • Inventoriez les charges de travail, les versions, les noyaux de système d’exploitation, le stockage, IAM et les classifications de données. Cartographiez les dépendances à travers les flux web→API→BD, les services partagés (LDAP/AD, DNS, NTP), les pipelines de traitement par lots et les API externes.
  • Utilisez le profilage d’application et le traçage distribué dans les environnements de pré-migration pour révéler les dépendances cachées et la latence de longue traîne. Activez les VPC Flow Logs et l’instrumentation au niveau applicatif (Cloud Logging, Cloud Monitoring, Cloud Trace).
  • Identifiez les frontières d’état et la gravité des données : taille, modèles d’accès (mix R/W), attentes en matière de cohérence et topologie de réplication.

• Préparation et compétences

  • Évaluez les compétences sur les fondamentaux du cloud, l’IaC, le CI/CD, le SRE, la sécurité, le réseau et les bases de données. Définissez une feuille de route pour la formation et la certification basée sur les rôles, et prévoyez du temps pour la montée en compétences et les astreintes en observation.
  • Établissez une landing zone (projets, dossiers, Shared VPC, politiques d’organisation, récepteurs d’audit, stratégie CMEK) avant la première vague.

• Planification des vagues de migration

  • Regroupez les applications en vagues par affinité et rayon d’impact : données partagées, dépendances synchrones et fenêtres de changement. Rassemblez les dépendances à haut risque dans la même vague ou simulez-les avec des contrats d’API bien définis.
  • Définissez par vague les SLO, RTO/RPO, les critères de restauration, et les portes de validation (vérifications de schéma, parcours utilisateur synthétiques, seuils de performance).
  • Préparez les runbooks et la gestion du changement : étapes de basculement, points de contrôle, restauration et collecte de preuves pour validation.

• Compatibilité, licences et évaluation des performances de référence

  • Validez la prise en charge des systèmes d’exploitation et des middlewares dans Compute Engine et les services managés. Vérifiez les conditions de licence commerciale, les contraintes BYOL, les exigences de modules de noyau et les affinités matérielles.
  • Capturez les métriques de référence pour le CPU, la mémoire, les IOPS, le débit et la latence, avec les valeurs de pic et du 95e centile, pour dimensionner les ressources cibles et valider les bénéfices.

• Gouvernance des données

  • Classifier les données PII/PCI. Planifiez la dé-identification ou la tokenisation à l’ingestion à l’aide de Cloud DLP. Définissez les politiques d’audit, de rétention et d’exportation avant que le premier log de production ne soit stocké.

Modes de défaillance courants : dépendances synchrones inconnues provoquant des timeouts en cascade après le basculement ; plages d’adresses IP qui se chevauchent et bloquent la connectivité ; lacunes dans la conformité des licences ; absence de parité de restauration où les mutations de données ne peuvent être annulées.

Modèles de migration, déplacement des données et basculement

• Cadre de décision (les 6 R)

  • Rehost (Réhéberger) : déplacer tel quel vers Compute Engine. Délai de mise en service cloud le plus rapide, changement minimal. Risque : reporte la dette technique et le dimensionnement inefficace.
  • Replatform (Réarchitecturer) : changements mineurs pour adopter des services gérés (par ex., Cloud SQL, Cloud Load Balancing). Bénéfices opérationnels plus rapides avec peu de modifications de code.
  • Refactor (Refactoriser) : décomposer ou conteneuriser pour GKE/Cloud Run ; adopter des modèles événementiels. Bénéfice à long terme le plus élevé avec un risque de livraison.
  • Retire (Retirer) : supprimer les systèmes inutilisés après avoir prouvé l’absence d’utilisation et de dépendances.
  • Retain (Conserver) : garder sur site pour des raisons réglementaires ou de latence ; intégrer via une solution hybride.
  • Relocate (Déplacer) : déplacer les charges de travail vSphere vers Google Cloud VMware Engine ; préserve l’outillage et minimise les changements.

• Outils de migration de calcul et de base de données

  • Migrate to Virtual Machines accélère le réhébergement vers Compute Engine tout en préservant les disques et la configuration réseau. Valider la prise en charge de l’OS invité et les pilotes du noyau.
  • Database Migration Service fournit une réplication en ligne homogène (par ex., MySQL, PostgreSQL) vers Cloud SQL avec un temps d’arrêt faible. S’assurer que les paramètres de binlog/réplication sont corrects et que la latence permet un rattrapage quasi temps réel.
  • Choisir les bases de données en fonction de la charge de travail :
    • Cloud SQL pour les besoins relationnels gérés ; activer l’augmentation automatique du stockage et surveiller le CPU proche de 75 % par cœur ; suivre le retard de réplication et partitionner (shard) ou monter en charge si les seuils sont approchés.
    • Bigtable pour l’ingestion de séries temporelles à faible latence et haut débit (par ex., données de capteurs).
    • Spanner pour une mise à l’échelle mondiale et une cohérence forte ; comprendre le compromis entre l’enfermement propriétaire (lock-in) et la portabilité.
  • Déplacement des données
    • Storage Transfer Service pour les transferts continus ou planifiés ; parallélise et gère les nouvelles tentatives.
    • Transfer Appliance pour les chargements en masse uniques (des dizaines aux centaines de To) pour réduire le temps et le risque réseau.
    • gsutil et les téléversements composites parallèles pour les ensembles de données de petite à moyenne taille.

• Migration en ligne ou hors ligne

  • En ligne : réplication continue avec un basculement court. Avantages : temps d’arrêt minimal ; Inconvénients : nécessite une latence et une bande passante stables ; éviter soigneusement la double écriture.
  • Hors ligne : instantané (snapshot) et importation en masse. Avantages : simple et prévisible ; Inconvénients : le temps d’arrêt est égal à la durée de la copie.

• Planification du basculement, retour arrière et contrôle du temps d’arrêt

  • Réduire les TTL DNS plusieurs jours avant le basculement, geler les changements non essentiels et planifier une fenêtre de maintenance.
  • Exécuter les portes de validation : parité des schémas, sommes de contrôle (checksums) ou comptages de lignes, tests de fumée (smoke tests) applicatifs, trafic canary et sondes de performance.
  • Retour arrière : assurer des changements de schéma rétrocompatibles, des feature flags et la préservation des données de la source de vérité. Éviter les écritures irréversibles jusqu’à ce que la stabilité soit prouvée.
  • Exemple d’extension de disque de VM avec un temps d’arrêt minimal :
    • Redimensionner le disque dans la Console ou la CLI :

undefined

- Sur Linux ext4 :

undefined

• Mises à jour d’application progressives (rolling updates) avec un impact minimal sur GKE :

undefined

Modes d’échec courants : perte de paquets sur Cloud VPN perturbant la réplication de la base de données (utiliser Dedicated Interconnect ou Partner Interconnect), divergence de double écriture pendant le basculement, vérifications de santé (health checks) manquantes interrompant les mises à jour progressives.

Identité hybride, connectivité et intégration sur site

• Identité

  • Conserver Active Directory comme source de vérité. Utiliser Google Cloud Directory Sync pour la synchronisation des comptes et des groupes, et configurer le SSO SAML pour l’accès des utilisateurs à Google Cloud.
  • Accorder le moindre privilège IAM via des rôles, utiliser des comptes de service pour les charges de travail et préférer Workload Identity Federation aux clés à longue durée de vie.

• Connectivité et routage hybrides

  • Utiliser Cloud VPN pour les besoins initiaux à faible débit et les tests ; passer à Dedicated Interconnect pour une bande passante soutenue, une latence plus faible et des performances de réplication prévisibles. Déployer des rattachements VLAN redondants et un VPN HA ou des interconnexions doubles pour la résilience.
  • S’assurer que les plages d’adresses IP de Google Cloud ne se chevauchent pas avec les CIDR sur site pour préserver la joignabilité de bout en bout.

  • Appliquer un accès à plusieurs niveaux avec des règles de pare-feu et des tags. Exemple pour autoriser uniquement web→API :

undefined

• Utiliser Private Service Connect et l’accès privé à Google pour la communication de service à service sans sortie publique ; segmenter avec VPC Service Controls le cas échéant.

• DNS hybride : utiliser Cloud DNS avec des politiques de transfert entrant/sortant pour résoudre les noms sur site et dans le cloud.

• Intégration sur site et latence

  • Garder l’état proche du calcul ou vice versa ; si la base de données sur site doit rester la source faisant autorité, envisager App Engine flexible ou Compute Engine avec Cloud VPN/Interconnect pour un accès privé.
  • Introduire des caches et des files d’attente pour découpler les chemins synchrones et absorber la gigue de latence ; mesurer la latence p95/p99, pas seulement les moyennes.

Modes d’échec courants : chevauchement de CIDR bloquant les routes, redondance insuffisante des sessions BGP, fuites de DNS public ou de sortie exposant des services privés, et protocoles bavards imprévus souffrant sur des liaisons à haute latence.

Modernisation, Modèle Opérationnel et Optimisation

• Modèles de modernisation des systèmes hérités (legacy)

  • Figuier étrangleur (Strangler Fig) : placer une façade d’API devant le monolithe et router progressivement les domaines vers de nouveaux services.
  • Conteneurisation : standardiser les images de base (préférer les images légères comme Alpine si compatibles), ordonner les couches du Dockerfile pour mettre en cache l’installation des dépendances avant de copier le code source afin de réduire le temps de compilation, et adopter un pipeline CI/CD avec des tests automatisés en pré-production (staging).
  • Données gérées : déplacer les bases de données opérationnelles vers des bases de données gérées ; choisir par domaine : Cloud SQL pour le transactionnel, Bigtable pour les séries temporelles, Spanner pour les charges de travail globalement cohérentes.

• Validation de la compatibilité, de la cohérence et des performances des applications

  • Confirmer le support de l’OS et du middleware, les limites de threads et de connexions, et la sémantique du système de fichiers. Valider la portabilité des licences et la mesure de l’utilisation.
  • Définir les exigences de cohérence des données (lecture de ses propres écritures, lectures monotones, cohérence éventuelle vs forte). Les aligner avec les bases de données cibles et les modèles d’accès.
  • Valider les performances avec des tests de charge et des parcours utilisateur synthétiques ; s’assurer que les budgets de SLO sont réalisables après la migration.

• Observabilité et conformité

  • Instrumenter les applications avec Cloud Logging, Monitoring et Trace pour localiser la latence à travers les microservices.
  • Exporter les journaux d’audit et les changements de politique IAM vers BigQuery et les partager avec les auditeurs via des vues et des autorisations IAM sur les datasets. Exporter les métriques à long terme vers Cloud Storage pour répondre aux exigences de rétention de plusieurs années.

• Modèle opérationnel et propriété (ownership)

  • Adopter les pratiques SRE : SLO, budgets d’erreur, réponse aux incidents et post-mortems sans blâme. Définir la propriété des services, les guides opérationnels (runbooks) et les rotations d’astreinte.
  • Utiliser l’IaC (par ex., Terraform) pour provisionner l’infrastructure de manière cohérente. Garder à l’esprit que Deployment Manager est spécifique à Google, peut limiter l’automatisation des ressources multi-cloud et est peu familier pour de nombreux ingénieurs.
  • Automatiser la cohérence des politiques avec Organization Policy, IAM Conditions, Config Sync et Policy Controller (OPA Gatekeeper) à travers les projets et les environnements.

• Stratégie multi-cloud et compromis liés au verrouillage fournisseur (lock-in)

  • Augmenter la portabilité avec Kubernetes, les pratiques de l’application à 12 facteurs, les contrats définis par OpenAPI et les abstractions pour la sortie des données (data egress). Équilibrer la portabilité avec la charge opérationnelle et les performances ; les services gérés réduisent la charge de travail manuelle (toil) mais peuvent augmenter le coût de changement.

• Optimisation des coûts et des performances ; démantèlement

  • Mettre à l’échelle les services Compute Engine sans état (stateless) avec des groupes d’instances gérés et l’autoscaling ; choisir le serverless (Cloud Functions ou Cloud Run) pour les charges de travail en rafale ou les MVP qui bénéficient d’une mise à l’échelle jusqu’à zéro.
  • Ajuster la taille des VM (rightsizing), activer l’autoscaling sur GKE, appliquer les remises sur engagement d’utilisation et démanteler les artefacts non utilisés. Suivre la réalisation des bénéfices via des KPI (disponibilité, latence, coût de service).
  • Démanteler les systèmes sur site après une période de stabilisation et la confirmation des dépendances. Archiver ou supprimer les données conformément à la politique de rétention et mettre à jour la CMDB.

Scénario de Problème Pratique

Acme Weather Networks doit migrer sa plateforme de capteurs en temps réel et une interface utilisateur d’administration J2EE héritée d’un centre de données sur site vers Google Cloud. Le système ingère les données de 50 000 capteurs envoyant 10 lectures par seconde et stocke cinq ans de données historiques (75 To). Il doit maintenir un accès privé à l’ERP et à l’Active Directory sur site pendant la transition, minimiser le temps d’arrêt pour une base de données MySQL sur site et éliminer les échecs de réplication intermittents observés sur le VPN.

1. Établir une zone d’atterrissage (landing zone) sécurisée

   • Créer une organisation, des dossiers et des projets de production/non-production. Mettre en place un VPC partagé (Shared VPC) avec des plages d’adresses IP qui ne se chevauchent pas pour assurer la joignabilité sur site via une connectivité hybride. Appliquer des politiques d’organisation et des exportations centralisées des journaux d’audit vers BigQuery avec un accès basé sur le moindre privilège.
   • Justification : Prévenir les conflits de routage et appliquer une gouvernance de base avant l’arrivée des charges de travail.

2. Mettre en œuvre une identité hybride

   • Configurer Google Cloud Directory Sync pour synchroniser les identités et les groupes AD et mettre en place le SSO SAML. Utiliser des comptes de service et des rôles personnalisés IAM pour la plateforme et les charges de travail.
   • Justification : Conserve l’identité d’entreprise comme source de vérité et permet un contrôle d’accès basé sur le moindre privilège.

3. Provisionner la connectivité et planifier les performances

   • Commencer avec HA Cloud VPN pour le développement/test. Pour la réplication de la base de données de production et l’ingestion stable des capteurs, provisionner Dedicated Interconnect avec deux attachements VLAN et des sessions BGP.
   • Justification : Interconnect offre une latence plus faible et moins de pertes de paquets que le VPN, stabilisant la réplication MySQL et l’ingestion en streaming.

4. Déplacer efficacement les données historiques

   • Commander des Transfer Appliances, charger l’ensemble de données de 75 To sur site, les expédier et les réhydrater dans Cloud Storage. Utiliser Storage Transfer Service pour les mises à jour incrémentielles continues si nécessaire. Exécuter Cloud DLP sur les journaux de support pour anonymiser les PII avant le stockage dans Bigtable ou BigQuery.
   • Justification : Le transfert de masse hors ligne réduit le risque lié à la fenêtre de basculement et évite de saturer les circuits.

5. Réhéberger l’interface utilisateur d’administration J2EE

   • Utiliser Migrate to Virtual Machines pour effectuer un lift-and-shift de la VM J2EE vers Compute Engine. Placer les instances dans un groupe d’instances géré derrière un équilibreur de charge HTTP(S). Appliquer des règles de pare-feu par tags pour forcer uniquement les flux web→API→BD. Exemple :

undefined

• Justification : Réduction rapide des risques avec un environnement d’exécution familier tout en appliquant des chemins réseau basés sur le moindre privilège.

6. Migrer MySQL vers Cloud SQL avec un temps d’arrêt minimal

   • Établir une base de référence des performances et activer la journalisation binaire (binary logging) sur la source. Utiliser Database Migration Service pour mettre en place une réplication continue vers Cloud SQL. Activer l’augmentation automatique du stockage et créer des alertes pour un CPU proche de 75 % et un retard de réplication inférieur à 60 secondes.
   • Justification : La migration en ligne permet un faible temps d’arrêt ; le SQL géré réduit la charge opérationnelle et garantit le respect des SLO opérationnels.

7. Exécuter un basculement contrôlé

   • Abaisser les TTL DNS 48 heures à l’avance, geler les modifications de schéma et planifier une fenêtre de maintenance. Arrêter les écritures sur site, s’assurer que le retard de DMS est nul, exécuter des sommes de contrôle (checksums) et des tests de fumée (smoke tests) applicatifs, puis pointer les clients vers Cloud SQL. Maintenir un plan de retour en arrière (rollback) où les écritures peuvent être redirigées vers le système sur site si la validation échoue.
   • Justification : Des étapes déterministes limitent le RTO et maintiennent la cohérence des données.

8. Construire l’ingestion pour la télémétrie en temps réel

   • Ingestion via Pub/Sub, traitement avec Dataflow et stockage des séries temporelles dans Bigtable pour des écritures et des lectures à faible latence. Maintenir l’intégration ERP privée via Interconnect.
   • Justification : Bigtable correspond au profil de séries temporelles à haut débit, et Pub/Sub découple les producteurs en rafale des consommateurs.

9. Conteneuriser les services et introduire le CI/CD

   • Conteneuriser les services sans état (stateless) pour GKE. Optimiser les Dockerfiles en utilisant des images de base légères et en ordonnant les couches pour que l’installation des dépendances précède la copie du code source. Mettre en œuvre un pipeline CI/CD avec des tests automatisés en pré-production et des déploiements canary. Mettre à jour avec un temps d’arrêt minimal :

undefined

• Justification : Améliore la vitesse de déploiement, la fiabilité et la scalabilité sans une réécriture de type big-bang.

10. Améliorer l’observabilité et l’audit

    • Instrumenter Cloud Logging, Monitoring et Trace pour identifier précisément la latence à travers les microservices. Exporter les journaux d’audit vers BigQuery et partager des vues avec une portée limitée pour les auditeurs. Exporter les métriques à long terme vers Cloud Storage pour respecter la rétention de cinq ans.
    • Justification : Une télémétrie complète soutient les SLO et la conformité.

11. Optimiser et démanteler

    • Activer l’autoscaling sur les MIG et GKE, ajuster la taille des instances, appliquer les remises sur engagement d’utilisation et planifier les charges de travail non-24x7 sur du serverless (par ex., Cloud Functions pour les tâches auxiliaires) pour une mise à l’échelle jusqu’à zéro. Après une période de stabilisation, démanteler les systèmes sur site, mettre à jour la CMDB et publier les bénéfices réalisés.
    • Justification : Capturer les efficacités de coût et opérationnelles tout en éliminant les dépenses liées au fonctionnement en parallèle.

12. Opérationnaliser et former

    • Finaliser les guides opérationnels (runbooks), la matrice RACI, les rotations d’astreinte et les budgets de SLO/erreur. Proposer des formations ciblées et des plans de certification pour combler les lacunes en matière de compétences. Préférer Terraform pour l’IaC ; noter que Deployment Manager est spécifique à Google et peut ne pas gérer les ressources non-Google.
    • Justification : Un modèle opérationnel mature maintient la fiabilité et la vélocité au-delà de l’événement de migration.

← Fiabilité · Tous les domaines · Opérations →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →