Google ACE: Fiabilité, sauvegarde et reprise après sinistre — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — 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.

Aperçu

La fiabilité, la sauvegarde et la reprise d’activité sur Google Cloud nécessitent une conception intentionnelle qui prend en compte les domaines de défaillance, les mécanismes de protection des données, la gestion du trafic et la préparation opérationnelle. Cette section explique comment structurer les services à travers les zones et les régions, comment protéger et restaurer les données avec état (stateful), et comment valider les objectifs de reprise grâce à des guides opératoires (runbooks) rigoureux et des tests de résilience continus. Elle présente également les compromis des stratégies de reprise d’activité (DR) et la planification de la capacité pour garantir que la plateforme puisse se rétablir en respectant les objectifs de temps de reprise (RTO) et de point de reprise (RPO) définis.

Domaines de défaillance et conception régionale

• Zones, régions et services multirégionaux

  • Les zones sont les plus petits domaines de défaillance indépendants. Une seule défaillance de zone ne devrait pas interrompre un service régional.
  • Les régions regroupent des zones indépendantes avec des liaisons à faible latence. Les conceptions régionales survivent aux défaillances de zone, mais pas nécessairement aux événements affectant une région entière.
  • Les services multirégionaux se répliquent entre les régions, protégeant contre la perte d’une région à un coût plus élevé et avec une latence d’écriture potentiellement plus grande.
  • Principe de conception : évitez les points de défaillance uniques (single points of failure) au niveau du plus petit domaine de défaillance qui vous importe. Si vos RTO/RPO exigent de survivre à une défaillance de zone, déployez sur au moins deux zones. Pour la capacité de survie régionale, déployez des composants actifs dans plusieurs régions ou utilisez des services multirégionaux.

• Groupes d’instances gérés (MIG) et autoréparation (self-healing)

  • Préférez les MIG régionaux pour répartir les instances entre les zones d’une même région. Cela atténue les pannes de zone sans nécessiter d’outillage distinct.
  • Les vérifications de l’état (health checks) de l’équilibreur de charge retirent du trafic les VM défaillantes. L’autoréparation (autohealing) du MIG remplace les VM défaillantes ou qui ne répondent pas. Utilisez les deux.
  • Utilisez des vérifications de l’état HTTP(S) au niveau de l’application qui vérifient les points de terminaison de disponibilité (readiness endpoints) et les dépendances. Une vérification TCP ne valide que l’accessibilité du port.
  • Mode de défaillance dû à une mauvaise configuration de l’autoréparation : utiliser uniquement une vérification de l’état de l’équilibreur de charge empêche le trafic d’atteindre une instance défaillante, mais ne la recrée pas. Configurez la propre vérification de l’état du MIG pour le remplacement et un délai initial pour éviter les redémarrages prématurés pendant le démarrage.

Exemple :

• Créez une vérification de l’état de l’application avec des intervalles de 10 secondes et 3 seuils d’échec pour déclencher l’autoréparation après environ 30 secondes : gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Attachez la vérification de l’état à un MIG régional pour l’autoréparation : gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Considérations multirégionales

  • Le service Global external HTTP(S) Load Balancing prend en charge des backends dans plusieurs régions avec un basculement automatique (failover) basé sur les vérifications de l’état.
  • La synchronisation de l’état entre les régions est le compromis essentiel. Le débit en mode actif-actif est élevé, mais la cohérence et la résolution des conflits doivent être conçues. Le mode actif-passif est plus simple mais présente un basculement plus lent et un RPO potentiellement plus grand.

Protection des données : bases de données, stockage et calcul

• Haute disponibilité et réplicas Cloud SQL
  • La configuration haute disponibilité place une instance de secours (standby) dans une zone différente avec une réplication synchrone. Le basculement (failover) automatique se produit en cas de défaillance de l’instance principale. Le RTO est généralement de quelques minutes ; le RPO est ≈ 0 au sein d’une région, mais il faut tenir compte des transactions en cours (in-flight).
  • Les réplicas en lecture (read replicas) déchargent les lectures et peuvent être interrégionaux pour la reprise après sinistre (DR). Ils sont asynchrones ; attendez-vous à un décalage de réplication (replication lag) et à un RPO non nul.
  • Sauvegardes et PITR
    • Activez les sauvegardes automatisées et la restauration à un moment précis (point-in-time recovery). Pour MySQL, activez la journalisation binaire (binary logging) ; pour PostgreSQL, activez la rétention PITR.
    • Flux de restauration : en cas de corruption ou d’erreur utilisateur, restaurez vers une nouvelle instance à un horodatage spécifique, redirigez les applications ou les réplicas vers l’instance restaurée, puis validez les données.
  • Modes de défaillance et compromis
    • La haute disponibilité (HA) ne protège pas contre la corruption logique des données ; les sauvegardes et le PITR le font.
    • Les réplicas interrégionaux protègent contre la perte d’une région mais peuvent avoir un décalage ; testez votre RPO acceptable.

Exemple :

• Activer la journalisation binaire (MySQL) et les sauvegardes automatisées :

undefined

• Snapshots de Persistent disk (PD) et images de machine
  • Les snapshots de PD sont des sauvegardes incrémentielles et cohérentes en cas de crash (crash-consistent) des disques. Leur emplacement de stockage est configurable et ils peuvent être utilisés pour créer de nouveaux disques dans n’importe quelle zone relevant de la portée de l’emplacement du snapshot.
  • Pour obtenir des sauvegardes cohérentes au niveau applicatif (application-consistent), mettez en pause (quiesce) le système de fichiers et l’application, ou coordonnez les snapshots avec des mécanismes de sauvegarde spécifiques à la base de données.
  • Les images de machine capturent les disques et les métadonnées de l’instance (disques de démarrage, disques attachés, propriétés de l’instance). Utilisez les images de machine pour une récupération plus rapide du parc (fleet) ou pour cloner une configuration de serveur de référence (golden server).
  • Les politiques de planification de snapshots (snapshot schedule policies) automatisent les sauvegardes ; appliquez la rétention ; taguez les disques critiques en conséquence.
  • Flux de travail de restauration : créez un disque à partir d’un snapshot, attachez-le à une nouvelle instance, mettez à jour les scripts de démarrage et les comptes de service, puis validez l’intégrité de l’application avant de réintroduire le trafic.

Exemple :

• Créer un snapshot et le restaurer sur un nouveau disque :

undefined

undefined

• Réplication, gestion des versions et rétention de Cloud Storage
  • Choix de classes de stockage : Standard pour les données chaudes ; Nearline pour un accès mensuel peu fréquent ; Coldline pour un accès trimestriel (recommandé pour les sauvegardes et la DR) ; Archive pour les données à long terme rarement consultées.
  • Les buckets Regional, Dual-Region et Multi-Region offrent une durabilité via la réplication. Le mode Dual-Region avec la réplication turbo peut contraindre le RPO de réplication pour les objets nouvellement écrits ; le mode Multi-Region offre une large résilience géographique.
  • La gestion des versions d’objets (Object versioning) protège contre les suppressions et les écrasements accidentels en conservant les versions non actuelles. Combinez-la avec des politiques de rétention (retention policies) et le verrouillage de bucket (bucket lock) pour appliquer une rétention de type WORM.
  • Protection contre la suppression accidentelle : activez la gestion des versions d’objets, utilisez une politique de rétention avec un verrou, mettez en œuvre des conservations à déclenchement événementiel (event-based holds) pour des raisons légales ou de traitement, restreignez les suppressions via IAM et l’accès uniforme au niveau du bucket. Pour un accès externe limité dans le temps, utilisez des URL signées (signed URLs) avec des expirations strictes.

Exemple de cycle de vie pour déplacer vers Coldline après 90 jours et supprimer après 365 jours :

• lifecycle.json

undefined

• Appliquer :

undefined

Résilience du trafic, de la capacité et des dépendances

• Basculement DNS et gestion du trafic

  • Préférez le global external HTTP(S) Load Balancing pour les services exposés sur Internet ; il utilise des adresses IP anycast et effectue un basculement interrégional basé sur les bilans de santé (health checks).
  • Pour les services privés, utilisez des équilibreurs de charge internes HTTP(S) ou TCP/UDP. Concevez pour une indépendance zonale avec plusieurs backends.
  • Compromis sur le TTL DNS : des TTL bas permettent un basculement plus rapide mais augmentent la charge des requêtes et peuvent être ignorés par certains résolveurs en raison du comportement de mise en cache.
  • Le basculement d’un LB basé sur les bilans de santé est plus rapide et plus déterministe qu’un basculement basé uniquement sur le DNS.
  • Les politiques DNS pondérées ou de basculement peuvent servir de plan de contrôle de dernier recours pour l’évacuation d’une région, mais elles dépendent de l’expiration du cache.

• Planification de la capacité et conception des quotas

  • Identifiez la capacité saine minimale par zone et par région. Appliquez des marges de sécurité (headroom buffers) pour le basculement (capacité « N+1 zone »).
  • Utilisez des réservations régionales pour les types de machines (shapes) Compute Engine critiques afin de garantir la capacité lors d’événements de mise à l’échelle ou de basculement.
  • Pré-provisionnez les adresses IP, les règles de transfert (forwarding rules), la capacité Cloud NAT, le suivi des connexions (connection tracking) et les certificats SSL pour éviter les retards du plan de contrôle lors de la récupération.
  • Demandez des augmentations de quota bien avant d’en avoir besoin ; validez les quotas dans les régions secondaires et pour toutes les dépendances (par ex., instances Cloud SQL par région, règles de transfert par VPC, débit Pub/Sub, QPS Cloud KMS).
  • Considérations sur l’autoscaling : configurez les délais de récupération (cooldowns), l’autoscaling prédictif si nécessaire, et définissez des limites min/max pour conserver exactement une instance lorsque la politique l’exige.

• Résilience des dépendances

  • Inventoriez les services en amont (upstream) et en aval (downstream). Pour chacun, définissez le comportement en cas de défaillance et les solutions de repli : configuration mise en cache, modes dégradés, disjoncteurs (circuit breakers), files d’attente avec des rubriques de lettres mortes (dead-letter topics) et la contre-pression (backpressure).
  • Validez la portée (scoping) d’IAM et des comptes de service dans les régions de récupération. Des rôles manquants provoquent souvent des défaillances silencieuses lors des événements de reprise après sinistre (DR).
  • Clés de chiffrement : assurez-vous que les réplicas de clés Cloud KMS ou les clés multirégionales correspondent à l’emplacement des données. Planifiez la localité des trousseaux de clés (key-ring) et l’IAM dans les régions secondaires.

Opérations de résilience et amélioration continue

• RTO, RPO, plans de reprise et runbooks

  • Le RTO définit la rapidité avec laquelle le service doit reprendre ; le RPO définit la perte de données acceptable. Dérivez-les de l’analyse d’impact sur l’activité (BIA).
  • Associez chaque composant du système à des mécanismes spécifiques qui satisfont le RTO/RPO : la haute disponibilité (HA) pour les pannes de zone, la réplication interrégionale pour les pannes de région, les sauvegardes pour la corruption, et la classe de stockage/réplication pour la durabilité.
  • Maintenez des runbooks : étapes précises, commandes, accès aux informations d’identification, vérifications de la validation de l’état de santé et arbres de décision. Stockez-les dans un dépôt versionné à accès contrôlé et répétez-les régulièrement.
  • Validation de la reprise : planifiez des exercices pour mesurer les RTO/RPO réels, valider l’intégrité des données et collecter des actions d’amélioration. Testez à la fois les restaurations de portée limitée (table, disque) et la reprise complète du site.

• Stratégies de reprise après sinistre (DR) et compromis

  • Actif-actif : toutes les régions servent du trafic ; RTO minimal et RPO faible si la synchronisation des données est correctement conçue. Complexité et coût plus élevés ; nécessite une résolution des conflits et un équilibrage de charge global.
  • Actif-passif : la région principale est active ; la secondaire est en attente (warm) et reçoit les données répliquées. Coût modéré ; RTO de quelques minutes à plusieurs dizaines de minutes ; RPO non nul en fonction de la réplication.
  • Veilleuse (Pilot-light) : des services critiques minimaux s’exécutent dans la région secondaire (réplication de base de données, empreinte applicative minimale). RTO en heures ; rentable ; une orchestration minutieuse est nécessaire pour augmenter la capacité de calcul lors du basculement.
  • Secours à froid (Cold-standby) : infrastructure définie en tant que code (IaC) mais non provisionnée. RTO en jours ; coût le plus bas ; risque de surprises dues à la dérive de configuration, aux quotas et à la rareté de la capacité.

• Tests de chaos et simulations de pannes

  • Simulez régulièrement des plantages d’instances, des blocages de processus, des échecs de vérification de l’état de santé, des conditions de disque plein et des pannes de dépendances. Utilisez des outils ou des scripts pour terminer des instances, bloquer le trafic sortant vers les backends ou injecter de la latence au niveau de la couche proxy.
  • Validez l’autoréparation du MIG et le retrait par l’équilibreur de charge (LB) en provoquant intentionnellement l’échec du point de terminaison de santé. Confirmez le comportement de remplacement et les délais de reprise.
  • Exercez-vous à l’évacuation régionale : drainez les backends dans une région, observez le basculement de l’équilibreur de charge global et vérifiez les dépendances avec état (stateful) dans la région secondaire.
  • Amélioration continue : enregistrez les métriques pour le temps moyen de détection (MTTD), le temps de basculement et la perte de données pendant les tests. Priorisez les correctifs qui réduisent le RTO/RPO et suppriment les étapes manuelles.

Scénario de problème pratique

Brightlane Retail exploite une plateforme de e-commerce dans us-central1 avec une disponibilité stricte et un RPO de quatre heures pour les données de commande. La direction exige de pouvoir survivre à une panne de zone sans interruption de service et à une panne régionale avec un impact minimal pour le client.

Approche :

1. Implémenter un MIG régional avec autoréparation HTTP et un équilibreur de charge HTTP(S) global

   • Justification : Un MIG régional répartit les instances sur plusieurs zones, et les vérifications de l’état de santé HTTP au niveau de l’application permettent l’autoréparation après trois échecs de vérification de 10 secondes chacun. L’équilibreur de charge global retire automatiquement les VM défaillantes et bascule le trafic vers les zones saines.
   • Commandes : gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Activer la haute disponibilité (HA) de Cloud SQL avec un replica en lecture interrégional et la restauration à un moment précis (PITR)

   • Justification : La haute disponibilité régionale assure la survie aux pannes de zone avec un basculement automatique. Un replica en lecture dans us-east1 fournit une reprise après sinistre régionale avec un RPO non nul mais limité. L’activation de la PITR (journalisation binaire pour MySQL) traite la corruption logique en permettant la restauration à un moment précis.
   • Commandes : gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Protéger les ressources de type objet avec Cloud Storage en mode bi-régional et des politiques de cycle de vie

   • Justification : Les images de produits et les ressources statiques sont stockées dans un bucket bi-régional pour la résilience régionale. Les transitions de cycle de vie déplacent les artefacts plus anciens vers Coldline pour optimiser les coûts, et la gestion des versions ainsi que les politiques de conservation empêchent la suppression accidentelle des ressources critiques.
   • Étapes : Activer la gestion des versions d’objets (Object Versioning), définir une politique de conservation de 30 jours pour les buckets critiques, et appliquer des règles de cycle de vie pour passer à Coldline après 90 jours et supprimer après un an pour les artefacts de build non critiques.

4. Planifier des instantanés de disques persistants (PD) et créer des images de machine pour les services avec état

   • Justification : Les instantanés incrémentiels des disques de VM offrent des options de restauration rapides et cohérentes après incident. Les images de machine capturent le démarrage et la configuration pour accélérer la réhydratation des serveurs d’application lors d’un basculement de région. Les planifications d’instantanés garantissent des sauvegardes cohérentes et pilotées par des politiques.
   • Commandes : gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. Définir le RTO/RPO et codifier les runbooks de reprise après sinistre (DR) et l’IaC

   • Justification : Définir un RTO au niveau du service de 15 minutes pour le web/API et un RPO de quatre heures pour les commandes. Les runbooks spécifient les procédures de basculement du trafic, la promotion du replica en lecture de Cloud SQL, les plans de secours DNS et les étapes de vérification. L’infrastructure en tant que code (Terraform/Deployment Manager) garantit des reconstructions déterministes et réduit les erreurs manuelles.

6. Provisionner la capacité et les quotas dans la région secondaire

   • Justification : Créer des réservations pour les types de VM critiques, pré-provisionner un backend d’équilibreur de charge en attente, des certificats SSL, de la capacité NAT, et vérifier les quotas pour Compute, SQL, les règles de transfert et KMS dans us-east1. Cela prévient une pénurie de capacité lors du basculement.

7. Valider la reprise par des exercices de chaos et documenter les améliorations

   • Justification : Des exercices trimestriels de panne de zone valident le comportement du MIG et de l’équilibreur de charge (LB) ; une évacuation régionale semestrielle promeut le replica en lecture dans us-east1, dirige l’équilibreur de charge global vers les backends de us-east1, et mesure le RTO/RPO. Les conclusions orientent les améliorations, telles que la réduction des étapes manuelles ou l’augmentation de la capacité du replica.

En suivant ces étapes, Brightlane Retail atteint une haute disponibilité au niveau de la zone avec une autoréparation automatisée et une posture de reprise après sinistre régionale avec des runbooks définis et testés, garantissant que les données de commande respectent un RPO de quatre heures et que les services applicatifs se rétablissent dans les limites des RTO ciblés.

← Sécurité · Tous les domaines · Gestion des coûts →

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

Parcourir Google →