Google PCA: Fiabilité, reprise après sinistre et continuité des activités — 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

La fiabilité, la reprise après sinistre (DR) et la continuité des activités garantissent que les services continuent de répondre aux objectifs convenus malgré les défaillances de composants, de zones ou de régions. Sur Google Cloud, la fiabilité est conçue en comprenant les domaines de défaillance (zonal, régional et mondial), en définissant des objectifs de reprise (RTO/RPO), en sélectionnant des architectures de service résilientes (par exemple, actif-actif) et en testant rigoureusement les plans de reprise. Votre conception doit faire correspondre la criticité des services à des cibles de disponibilité explicites, des garanties de durabilité et des chemins de reprise validés, en équilibrant la disponibilité, la cohérence, le coût et la complexité opérationnelle. Les thèmes clés incluent l’isolement des points de défaillance uniques (SPOF), l’utilisation de la réplication gérée lorsque cela est possible, l’automatisation des décisions de basculement et la validation continue que les hypothèses se vérifient dans des conditions similaires à la production.

Domaines de défaillance, emplacements et services multirégionaux

• Zones de disponibilité et régions :
  • Les zones sont des domaines de défaillance indépendants au sein d’une région. Les défaillances de zone sont les événements à grande échelle les plus courants pour lesquels vous concevez.
  • Les régions sont des ensembles de zones avec des liaisons à faible latence. Les défaillances régionales sont plus rares mais doivent être prises en compte pour les systèmes à haute criticité.
  • Modèles de conception :
    • Intra-région : placez les ressources de calcul sans état (stateless) sur au moins deux zones via des groupes d’instances gérés (MIG) régionaux.
    • Inter-régions : répliquez l’état et basculez le trafic pour les services critiques qui ne peuvent tolérer la perte d’une région.
• Services multirégionaux et mondiaux :
  • Plans de contrôle mondiaux : les réseaux VPC, Cloud DNS, l’équilibrage de charge HTTP(S) externe mondial et Cloud IAM sont des services à portée mondiale utilisés pour réduire le couplage régional.
  • L’emplacement du plan de données est important :
    • Cloud Storage : choisissez des buckets régionaux, birégionaux ou multirégionaux en fonction des modèles d’accès et des besoins de DR.
    • BigQuery : les ensembles de données se trouvent dans une région ou une multirégion ; la multirégion améliore la disponibilité de la surface d’analyse, mais tenez compte de la résidence des données et de la sortie (egress) pour les jointures externes.
    • Spanner : la configuration de l’instance (régionale ou multirégionale) définit la topologie des réplicas et le comportement de cohérence.
• Analyse des domaines de défaillance :
  • Associez chaque composant à son rayon d’impact (blast radius). Exemples :
    • Zonal : une seule VM, un pool de nœuds GKE zonal, un disque persistant (PD) SSD zonal.
    • Régional : les instances primaire et de secours (standby) de Cloud SQL HA sont régionales ; certains événements de maintenance peuvent impacter une région.
    • Mondial : une mauvaise configuration d’IAM ou de Cloud DNS affecte toutes les régions.
  • Identifiez les défaillances corrélées telles que les dépendances partagées (par exemple, une seule passerelle NAT, une seule instance Memorystore) ou le risque d’origine humaine (compte de service partagé, un seul état Terraform).
  • Considérez les quotas comme des domaines de défaillance ; un autoscaler qui atteint un plafond de quota régional est fonctionnellement en panne.

Compromis :

• La réplication interzone réduit les temps d’arrêt mais ajoute du trafic et des coûts interzones.
• Les conceptions interrégionales réduisent le RTO mais augmentent la latence, la complexité et les dépenses.
• L’équilibrage de charge anycast mondial simplifie le basculement mais ne masque les backends défaillants que si les vérifications de santé (health checks) sont précises.

Objectifs, cartographie des dépendances et validation de la DR

• RTO et RPO :
  • Recovery Time Objective (RTO) : temps cible pour restaurer le service. Détermine le niveau d’automatisation, la posture de secours (standby) et le détail des runbooks.
  • Recovery Point Objective (RPO) : fenêtre de perte de données acceptable. Détermine le choix de la réplication et la cadence des sauvegardes.
• Criticité des services et hiérarchisation :
  • Définissez des niveaux (par exemple, Niveau 0 : impact sur la sécurité/financier ; Niveau 1 : revenus ; Niveau 2 : outils internes) avec des SLO, RTO/RPO cibles et une fréquence de test.
  • Liez les dépenses et la complexité au niveau ; tous les services n’ont pas besoin d’être interrégionaux.
• Cartographie des dépendances :
  • Inventoriez les dépendances en amont et en aval : identité (Cloud IAM, IdP SAML), secrets (Secret Manager, KMS), réseau (DNS, Cloud Interconnect/VPN), stockage et bases de données, observabilité, CI/CD et API tierces.
  • Documentez la région, la zone et le SLA pour chaque dépendance ; définissez des contrôles compensatoires pour les maillons les plus faibles.
• Plans de reprise :
  • Créez des runbooks et des automatisations pour le basculement/rétablissement (failover/failback), la restauration des données et la promotion de la configuration (DNS, backends d’équilibreurs de charge, pare-feu).
  • Pré-provisionnez les autorisations et les comptes de service ; préparez les définitions d’infrastructure pour éliminer les validations manuelles.
  • Maintenez un accès d’urgence (break-glass) avec une élévation de privilèges auditable.
• Tests de reprise :
  • Planifiez des basculements de routine pour les systèmes avec état (stateful) (par exemple, Cloud SQL HA) afin de valider la promotion et la renégociation des connexions.
  • Organisez des « game days » qui simulent une panne de zone ou de région ; incluez les fournisseurs en amont et les défaillances d’IAM/KMS.
  • Utilisez l’injection de fautes pour valider les disjoncteurs (circuit breakers), les délais d’attente (timeouts) et les nouvelles tentatives (retries) ; vérifiez que l’autoscaling et la contre-pression (backpressure) fonctionnent comme prévu.
  • Mesurez en continu le RTO/RPO pendant les tests ; ajustez l’architecture lorsque les objectifs ne sont pas atteints.

Patrons de résilience pour le calcul, les bases de données et le stockage

• Calcul auto-réparateur avec les MIG régionaux et l’équilibrage de charge :
  • Utilisez des MIG régionaux pour répartir les instances sur plusieurs zones avec l’autoscaling et l’auto-réparation.
  • Exposez en frontal avec un équilibreur de charge HTTP(S) externe mondial et une vérification de l’état (health check) du service backend alignée sur la disponibilité réelle (par ex., /healthz vérifie les dépendances).
  • Autorisez les vérifications de l’état à travers les pare-feu pour éviter le recyclage constant des VM :

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Évitez l'état local ; externalisez les sessions vers Memorystore ou des bases de données ; utilisez le drainage des connexions (connection draining) sur les backends pour préserver les requêtes en cours lors d'un scale-in.
  - Modes de défaillance courants : vérifications de l'état mal alignées (vérifiant trop ou pas assez), règles de pare-feu manquantes, et un bootstrapping qui dépend de services en aval non disponibles.
- Résilience de Cloud SQL :
  - Haute disponibilité : une instance principale et une de secours (standby) dans des zones distinctes avec réplication de disque synchrone et basculement automatique ; sélectionnez une fenêtre de maintenance et testez les basculements.
  - Réplicas en lecture : ajoutez des réplicas en lecture dans la même région ou inter-régions pour décharger les lectures et réduire le RTO en cas d'événements régionaux ; promouvez les réplicas lors d'un plan de reprise d'activité (DR).
  - Sauvegardes et PITR :
    - Activez les sauvegardes quotidiennes automatisées et la restauration à un moment précis (PITR) via les journaux binaires/de transactions avec une rétention suffisante pour la conformité et le RPO.
    - Validez les restaurations en environnement de non-production, et répétez les procédures de promotion et les mises à jour des chaînes de connexion des applications.
  - Réseau : préférez une IP privée pour la production ; assurez-vous que les tests de basculement valident le comportement du DNS et du regroupement de connexions (connection pooling).
  - Conseil opérationnel : exécutez périodiquement un basculement contrôlé pour vérifier que les pools de connexions des applications se reconnectent correctement.

gcloud sql instances failover prod-sql
```

• Configuration et résilience de Spanner :
  • Les instances régionales fournissent des lectures/écritures à faible latence et à forte cohérence au sein d’une région en utilisant Paxos entre les zones.
  • Les instances multirégionales se répliquent entre les régions avec des écritures synchrones par quorum (forte cohérence globale) et des réplicas optionnels en lecture seule ; choisissez une région leader proche des processus d’écriture.
  • Compromis : le multirégional améliore le RTO/RPO et la disponibilité en lecture, mais augmente la latence d’écriture et le coût. Utilisez-le pour les charges de travail distribuées mondialement, intensives en écriture, nécessitant une forte cohérence ; sinon, envisagez Spanner régional ou Cloud SQL avec des réplicas.
• Patrons de durabilité et de récupération pour Cloud Storage :
  • Stratégie d’emplacement : régional pour la localité du calcul, birégional (dual-region) pour un mode actif-actif sur deux régions, multirégional pour une large disponibilité pour les utilisateurs mondiaux.
  • Gestion des versions : activez la gestion des versions d’objets pour récupérer après une suppression ou une corruption ; combinez-la avec des règles de cycle de vie pour gérer les coûts.
  • Rétention : appliquez des politiques de rétention au niveau du bucket et, si nécessaire, des verrous de rétention (retention locks) pour la conformité ; utilisez des conservations événementielles (event-based holds) pour la gestion des archives.
  • Patrons de sauvegarde : des buckets inter-projets avec des administrateurs distincts atténuent les suppressions accidentelles et l’escalade de privilèges. Pour les bases de données, exportez des sauvegardes logiques vers Cloud Storage dans un projet distinct.
  • Exemple de règle de cycle de vie pour supprimer les versions de plus de 90 jours :

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Appliquer avec :

gsutil lifecycle set lifecycle.json gs://prod-backups
```

• Récupération : maintenez des catalogues d’objets critiques et testez les restaurations ; pour les grands ensembles de données, effectuez les restaurations dans des buckets temporaires pour éviter les collisions de noms et valider l’intégrité.

Gestion du trafic, stratégies multi-sites et résilience continue

• Stratégies multi-sites :
  • Actif-actif : dessert le trafic depuis plusieurs régions simultanément ; nécessite une réplication symétrique des données et des écritures sans conflit. Meilleurs RTO/RPO ; coût et complexité les plus élevés.
  • Actif-passif : un site principal actif (hot) et un secondaire prêt ; données répliquées en continu, trafic basculé en cas de panne. Bon équilibre entre coût et RTO.
  • Secours tiède (Warm standby) : un site secondaire à échelle réduite avec des données pré-synchronisées ; nécessite une montée en charge (scale-up) lors du basculement ; RTO et coût modérés.
  • Veilleuse (Pilot light) : réplication minimale des données critiques et définitions d’infrastructure ; la plupart des composants sont provisionnés lors du basculement ; RTO long, faible coût en régime de croisière.
  • Secours à froid (Cold standby) : sauvegardes périodiques uniquement ; réhydratation en cas de panne ; RTO le plus long, coût le plus bas.
• Basculement DNS et gestion du trafic :
  • Préférez le routage basé sur la santé au niveau de la couche 7 avec le global external HTTP(S) load balancer. Il effectue des vérifications de santé par backend et détourne le trafic des zones ou régions défaillantes sans modification DNS.
  • Utilisez des enregistrements DNS à faible TTL uniquement comme un contrôle de basculement grossier ou pour basculer entre des VIP de load balancers disjoints ; comprenez que la mise en cache DNS signifie que le basculement n’est pas instantané.
  • Pour les services privés, utilisez Internal HTTP(S) Load Balancing avec des schémas de basculement régionaux, ainsi qu’un DNS privé que vous pouvez mettre à jour par programmation si nécessaire.
• Schémas de dégradation gracieuse :
  • Implémentez des feature flags pour désactiver les fonctionnalités non critiques en cas de charge élevée.
  • Utilisez des disjoncteurs (circuit breakers), des délais d’attente (timeouts), des nouvelles tentatives avec gigue (jitter) et des cloisons (bulkheads) pour localiser les pannes.
  • Fournissez un mode lecture seule lorsque les chemins d’écriture sont dégradés ; mettez les écritures en file d’attente pour une réconciliation ultérieure.
  • Limitez le débit des clients (rate-limit) et appliquez une contre-pression (backpressure) pour éviter les pannes en cascade.
• Tests de chaos et amélioration continue :
  • L’injection de fautes au niveau du réseau (latence, perte de paquets) et des couches applicatives valide que les contrôles de résilience se déclenchent comme prévu.
  • Les “Game days” rendent la reprise après sinistre opérationnelle entre les équipes ; ils incluent l’astreinte (paging), l’exécution des guides opératoires (runbooks) et des post-mortems avec des actions correctives concrètes.
  • Suivez les budgets d’erreurs et les SLO ; ajustez la capacité, les stratégies de nouvelle tentative et les configurations de réplication en fonction des données.
• Compromis entre disponibilité, cohérence, coût et complexité :
  • Disponibilité vs. cohérence : une cohérence forte et globale (par ex., Spanner multi-régional) peut ajouter de la latence en écriture ; la cohérence à terme (eventual consistency) (par ex., réplicas asynchrones) peut améliorer la latence mais risque des lectures de données obsolètes (stale reads).
  • Coût vs. RTO/RPO : le stockage bi-régional et les bases de données multi-régionales augmentent les dépenses mais minimisent la perte de données et les temps d’arrêt.
  • Complexité vs. fiabilité : chaque mécanisme de basculement, flux de réplication et règle de routage doit être exploité et testé ; gardez les conceptions aussi simples que nécessaire pour atteindre les objectifs.

Scénario de problème pratique

Acme Tickets, une entreprise de billetterie en ligne en forte croissance, doit assurer la continuité de ses opérations lors de pannes régionales pour son API d’achat et son catalogue d’événements, tout en maintenant des RTO/RPO stricts (RTO ≤ 5 minutes, RPO ≤ 1 minute). L’architecture comprend des microservices sans état (stateless), une base de données relationnelle pour les commandes, un pipeline d’analyse et des ressources multimédias statiques.

1. Définir les niveaux de service (tiers), les SLO et les objectifs de reprise

• Justification : Classer l’API d’achat et la base de données des commandes en Tier 0 (RTO 5m, RPO 1m), le catalogue en Tier 1 (RTO 15m, RPO 5m) et l’analytique en Tier 2 (au mieux). Cela aligne le coût et la complexité sur l’impact métier.

2. Choisir l’emplacement régional et la stratégie multi-sites

• Justification : Déployer en actif-actif sur us-central1 et us-east1 pour les services sans état afin de minimiser le RTO ; utiliser l’actif-passif pour la base de données des commandes afin d’équilibrer la latence d’écriture et le coût.

3. Mettre en œuvre des MIG régionaux et un global HTTP(S) load balancing

• Justification : Deux MIG régionaux (un par région) répartis sur au moins deux zones chacun. Une seule VIP anycast globale achemine le trafic via des services backend vérifiés par des health checks, excluant automatiquement les régions défaillantes.

4. Externaliser l’état et configurer l’auto-réparation (self-healing)

• Justification : Stocker les sessions dans Memorystore avec des réplicas en lecture inter-régionaux pour le catalogue, et garder les services sans état (stateless) pour que l’auto-réparation des MIG et les mises à jour progressives (rolling updates) soient sûres. Les health checks pointent vers /healthz qui valide les dépendances critiques en aval.

5. Provisionner Cloud SQL for PostgreSQL avec haute disponibilité (HA) et un réplica en lecture inter-régional

• Justification : Utiliser la haute disponibilité (HA) dans la région principale pour la résilience zonale et activer la restauration à un moment précis (PITR) avec une rétention suffisante. Créer un réplica en lecture inter-régional dans la région secondaire et un guide opératoire (runbook) testé pour le promouvoir en cas de panne régionale, respectant un RPO ≤ 1 minute avec une perte d’écriture minimale.

6. Planifier des tests de basculement de base de données de routine

• Justification : Exécuter des basculements contrôlés mensuels pour valider le comportement de reconnexion de l’application et la promotion du réplica. Cela résout un mode de défaillance courant où les réplicas ne sont jamais promus lors d’incidents réels.

7. Placer les médias statiques dans un bucket Cloud Storage bi-régional avec gestion des versions et rétention

• Justification : Le mode bi-régional assure la disponibilité des objets dans deux régions ; la gestion des versions protège contre les écrasements/suppressions accidentels. Appliquer des règles de cycle de vie pour expirer les anciennes versions et maîtriser les coûts.

8. Protéger les health checks et le trafic sortant (egress) avec un pare-feu et des quotas

• Justification : Créer des règles de pare-feu explicites pour les health checks du load balancer et surveiller les quotas d’instances régionales pour éviter que l’autoscaler ne se bloque pendant un basculement.

9. Mettre en œuvre le DNS comme un contrôle grossier avec un faible TTL

• Justification : Bien que le global load balancer gère le routage basé sur la santé, maintenir un enregistrement A à faible TTL vers une VIP de secours pour un basculement manuel d’urgence, en comprenant les limitations du cache DNS.

10. Automatiser les guides opératoires de reprise après sinistre (DR runbooks) et les valider via des “game days”

• Justification : Utiliser Cloud Scheduler pour déclencher du trafic synthétique et les SLO de Cloud Monitoring pour confirmer le comportement lors de “game days” trimestriels avec injection de fautes (par ex., blocage du trafic inter-régional, terminaison de nœuds). Capturer les métriques RTO/RPO et affiner les procédures.

11. Sécuriser et séparer les sauvegardes

• Justification : Exporter quotidiennement des sauvegardes logiques de la base de données des commandes vers un bucket Cloud Storage dans un projet séparé avec des verrous de rétention ; restaurer périodiquement sur une instance de pré-production (staging) pour valider l’intégrité et la durée.

12. Mettre en œuvre la dégradation gracieuse

• Justification : Si la base de données des commandes est dégradée, basculer le catalogue en lecture seule, mettre les écritures en file d’attente pour une réconciliation ultérieure et abandonner les fonctionnalités non critiques. Cela prévient les pannes en cascade et maintient un service partiel.

Cette architecture fournit un basculement régional automatisé pour les services sans état, un basculement contrôlé et testé pour les composants avec état (stateful), et des processus de reprise vérifiés qui répondent aux objectifs de continuité d’activité d’Acme Tickets.

← Sécurité · Tous les domaines · Migration →

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

Parcourir Google →