Google ACE: Stockage, bases de données et services de données — 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.

Vue d’ensemble

Cette section fournit une référence pratique et axée sur les opérations pour les services de stockage, de bases de données et d’analyse de données de Google Cloud. Elle met l’accent sur les modèles de configuration, le contrôle d’accès, les mécanismes de durabilité, les caractéristiques de performance et de coût, ainsi que les pratiques de récupération sécurisées. L’objectif est de vous aider à décider quel service utiliser pour une charge de travail donnée, à comprendre les compromis opérationnels et à anticiper les modes de défaillance courants.

Conception, accès, cycle de vie et protection de Cloud Storage

Cloud Storage est un service de stockage d’objets durable et hautement disponible pour les données non structurées et les sauvegardes.

Buckets et objets : Les buckets sont des espaces de noms globaux dans un emplacement (région ou bi/multi-région) qui contiennent des versions d’objets immuables. Choisissez l’emplacement du bucket pour minimiser la sortie de données et respecter la résidence des données.
Classes de stockage : Utilisez Standard (accès fréquent), Nearline (min. ~30 jours), Coldline (min. ~90 jours) et Archive (min. ~365 jours) en fonction de la fréquence d’accès. Pour les sauvegardes de reprise après sinistre (DR), Coldline est une option par défaut courante. Vous pouvez mélanger les classes par objet au sein d’un même bucket.
Règles de cycle de vie : Automatisez les transitions et les suppressions avec les conditions Age, CreatedBefore, MatchesStorageClass et NoncurrentVersion. Exemple pour faire passer un objet en Coldline à 90 jours et le supprimer à 365 jours :
1. lifecycle.json :

undefined

Appliquer :

undefined

Rétention et conservation à des fins juridiques : Les règles de rétention empêchent la suppression ou la modification d’objets avant la fin de la période ; le verrouillage de la règle est irréversible. Les conservations à des fins juridiques s’appliquent par objet et doivent être levées avant toute suppression.

Contrôle d’accès et partage :

Accès uniforme ou détaillé : Préférez l’accès uniforme au niveau du bucket (UBLA) pour gérer les autorisations uniquement avec IAM. L’accès détaillé (ACL d’objet) est hérité et complique l’auditabilité et la propagation. L’activation de l’UBLA désactive les ACL et peut affecter immédiatement les intégrations existantes qui en dépendaient.
URL signées : Pour un accès de courte durée sans identité Google, utilisez des URL signées. Évitez les fichiers de clé de compte de service en signant avec IAM :

undefined

Assurez-vous que le compte de service dispose du rôle Créateur de jetons du compte de service (service account token creator) sur lui-même ou via un rôle de signataire.

Chiffrement : Chiffrement côté serveur par défaut ; activez les CMEK au niveau du bucket ou par objet lorsque vous avez besoin de contrôler les clés et les journaux d’audit. Surveillez la disponibilité et la rotation des clés KMS ; l’indisponibilité des CMEK bloquera les téléversements et les déchiffrements.
Gestion des versions : Activez la gestion des versions d’objets pour conserver les versions non actuelles après des écrasements/suppressions. Combinez avec des règles de cycle de vie pour faire expirer les versions non actuelles et contrôler la croissance du stockage. Soyez conscient de la logique de listing côté client lorsque de nombreuses versions existent.

Modes de défaillance et atténuation :

Suppression ou écrasement accidentel : Utilisez la gestion des versions et les règles de rétention. Pour une conformité stricte, verrouillez la rétention.
Accès public mal configuré : Appliquez la prévention de l’accès public et l’UBLA. Auditez périodiquement avec Cloud Asset Inventory et l’analyseur de règles (policy analyzer).
Coûts excessifs : Les règles de cycle de vie, les classes au niveau de l’objet et les paiements par le demandeur (requester pays) réduisent les surprises. Surveillez avec les métriques et les budgets de Cloud Monitoring.

Commandes utiles :

Créer un bucket avec UBLA et rétention :

undefined

Stockage en mode bloc et fichier pour les charges de travail de calcul

Choisissez le stockage en fonction du modèle d’accès, des besoins en performance et des exigences de durabilité pour Compute Engine et GKE.

Persistent Disk (PD) : Stockage en mode bloc durable, zonal ou régional. Types : Standard (HDD) pour le débit séquentiel ; Équilibré (pd-balanced) et SSD (pd-ssd) pour une faible latence et des IOPS élevés. Le PD régional se réplique de manière synchrone entre les zones, permettant une récupération plus rapide. Le PD peut être sauvegardé par snapshot, redimensionné en ligne et attaché en lecture seule à plusieurs VM (un seul rédacteur pour la lecture-écriture).
- Compromis : Les IOPS plus élevés coûtent plus cher sur SSD ; le HDD est rentable mais présente une latence élevée pour les E/S aléatoires. Le PD régional coûte plus cher mais réduit le RTO.
SSD local : Stockage éphémère attaché en NVMe ou SCSI avec des IOPS très élevés et une faible latence. Les données sont perdues lors de l’arrêt de la VM ou de la maintenance de l’hôte ; utilisez-le uniquement pour des caches éphémères ou des données répliquées. Sauvegardez ou répliquez ailleurs pour éviter la perte de données.
Filestore : NFS géré pour une sémantique de fichiers partagés POSIX. Les niveaux de base sont zonaux ; les niveaux Enterprise et supérieurs offrent une haute disponibilité (HA) régionale avec une réplication synchrone et des IOPS plus élevés. Idéal pour GCVE, le stockage temporaire (scratch) pour le HPC, le rendu multimédia et les applications nécessitant un verrouillage de fichiers partagés.
- Compromis : NFS introduit une mise en cache côté client et une sémantique de verrouillage ; le débit et la latence diffèrent selon le niveau ; ne convient pas aux petites E/S aléatoires avec des latences de l’ordre de quelques microsecondes comme le SSD local.

Considérations sur les défaillances :

Maintenance de l’hôte : Perte de données du SSD local ; protégez avec la réplication applicative.
Pannes de zone : Interruptions du PD zonal et du Filestore de base ; utilisez le PD régional ou Filestore Enterprise pour la haute disponibilité (HA).
Cohérence des snapshots : Pour des snapshots de PD cohérents avec l’application, coordonnez avec un gel du système de fichiers (filesystem freeze) ou une mise en attente native de la base de données pour éviter les fenêtres de récupération après incident.

Bases de données et services de données gérés

Cloud SQL (MySQL, PostgreSQL, SQL Server gérés) :

Configuration : Choisissez la forme de la machine, le type de stockage, les connexions (IP privée préférée), les réseaux autorisés si vous utilisez une IP publique, les fenêtres de maintenance et les insights pour le diagnostic des performances. Utilisez le regroupement de connexions (par ex., Cloud SQL Auth Proxy, PGbouncer) pour respecter les limites de connexion et de CPU.
Haute disponibilité : Les instances HA régionales déploient une instance de secours (standby) dans une autre zone avec une réplication de stockage synchrone ; le basculement (failover) est automatique. Attendez-vous à une courte fenêtre d’indisponibilité en écriture pendant le basculement.
Réplicas : Réplicas en lecture (read replicas) pour la mise à l’échelle en lecture et le délestage de la BI ; réplication externe pour les migrations. Surveillez le décalage des réplicas (replica lag) et concevez des lecteurs idempotents.
Sauvegardes et PITR : Activez les sauvegardes automatisées et la journalisation binaire/WAL pour la restauration à un instant T (point-in-time recovery). Testez les restaurations régulièrement.

undefined

Modes de défaillance : Les transactions de longue durée bloquent le vacuum/checkpointing ; les pics de connexions provoquent du thrashing ; l’auto-agrandissement du stockage peut se bloquer si le quota est insuffisant. Définissez des alertes pour le CPU, la mémoire, les connexions, le décalage des réplicas et l’utilisation du disque.

Cloud Spanner :

Mise à l’échelle et régionalité : Instances régionales ou multirégionales avec réplication synchrone et cohérence forte (strong consistency) globale. Mettez à l’échelle les nœuds pour le débit et le stockage ; le placement de la région leader influence la latence en écriture.
Schéma et clés : Concevez des clés primaires pour éviter les points chauds (hotspots) ; utilisez des clés composites avec un préfixe haché ou aléatoire pour les séries temporelles afin de distribuer les écritures. Utilisez des index secondaires pour les modèles de requêtes et envisagez de stocker ensemble les colonnes fréquemment filtrées. Gardez les transactions petites et limitées pour minimiser la contention de verrous.
Transactions : Transactions distribuées fortement cohérentes avec une cohérence externe via TrueTime. Latence en écriture limitée par le quorum ; les conflits entraînent des transactions abandonnées — réessayez avec un backoff (attente exponentielle).

Firestore et Bigtable :

Firestore (Mode natif) : Base de données de documents avec des collections, des écouteurs en temps réel (real-time listeners), des transactions portant sur jusqu’à 500 documents par transaction, et une cohérence forte pour les lectures de documents et la plupart des requêtes. Idéal pour les données d’applications mobiles/web, le JSON hiérarchique et les applications événementielles.
Bigtable : Base de données à colonnes larges (wide-column) pour une échelle de pétaoctets et une latence inférieure à 10 ms. Transactions sur une seule ligne uniquement ; concevez les clés de ligne (row keys) pour éviter le hotspotting. Idéal pour les séries temporelles, l’IoT, la personnalisation et les compteurs à grande échelle. Ne convient pas aux jointures ad-hoc ou aux agrégations complexes.

Memorystore :

Redis et Memcached : Caches en mémoire pour une latence de l’ordre de la microseconde à la milliseconde. Le niveau de base (Basic) n’a pas de HA ; le niveau standard (Standard) fournit une HA régionale avec basculement automatique pour Redis. Traitez-le comme éphémère ; ne pas utiliser comme système de référence (system of record).

BigQuery :

Ensembles de données et tables : Organisez par ensemble de données (dataset) ; contrôlez l’accès aux niveaux du projet, de l’ensemble de données, de la table, de la colonne et de la ligne. Utilisez des tables partitionnées et clusterisées pour contrôler les octets analysés et le coût.
Tâches de chargement et de requête : Chargez depuis Cloud Storage, des exports Cloud SQL ou des insertions en streaming. Utilisez des exécutions à blanc (dry runs) pour estimer le coût :

undefined

Contrôle d’accès : Accordez le rôle BigQuery Data Viewer au niveau de l’ensemble de données pour les consommateurs en lecture seule ; utilisez des vues autorisées ou la sécurité au niveau de la ligne/colonne pour le moindre privilège.

← Réseautage VPC · Tous les domaines · Déploiement →

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