Google PCA: Coûts, performance et conception de cloud durable — 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.

Coût-performance du stockage, des bases de données et de l’analytique

Choisissez des classes de stockage et des modèles de capacité de base de données qui reflètent les schémas d’accès, la rétention et les SLO de performance.

Classes de stockage et politiques de cycle de vie
- Utilisez Standard pour les données chaudes, Nearline pour un accès mensuel, Coldline pour un accès trimestriel, et Archive pour un accès rare à long terme. Conservez les données et les ressources de calcul dans la même région pour éviter les frais de sortie (egress).
- Appliquez la gestion du cycle de vie pour faire passer les objets à une autre classe ou les supprimer automatiquement. Faites attention aux durées de stockage minimales et aux frais de récupération ; des transitions de classe prématurées peuvent coûter plus cher qu’elles n’économisent.
- Exemple de politique de cycle de vie (supprimer après 90 jours) :
  - { “rule”: [{ “action”: {“type”: “Delete”}, “condition”: {“age”: 90} }]}
  - gsutil lifecycle set lifecycle.json gs://my-backups
Transfert et archivage de données
- L’accès inter-régional entraîne souvent des frais de sortie (egress) ; co-localisez les producteurs et les consommateurs. Utilisez Private Google Access et VPC-SC pour un accès sécurisé et optimisé en termes de coûts aux API Google. Pour les archives à long terme, évitez les récupérations fréquentes depuis la classe Archive pour ne pas subir des frais de récupération élevés.
Dimensionnement et performance des bases de données
- Relationnel : dimensionnez pour le jeu de données de travail résident en mémoire, les IOPS et les réplicas en lecture. Activez l’augmentation automatique du stockage et surveillez le retard de réplication ; effectuez une mise à l’échelle verticale ou un sharding horizontal lorsque le retard menace les RPO/RTO.
- NoSQL/séries temporelles : utilisez Bigtable pour une ingestion à haut débit et faible latence avec une conception appropriée des clés de ligne pour éviter les points chauds (hotspots).
Contrôles des coûts et modèles de capacité de BigQuery
- À la demande (par To analysé) : démarrage rapide, risque de pics de coûts. Réservations basées sur la capacité : dépenses prévisibles, contrôle de la simultanéité et du débit. Les engagements Flex absorbent les pics à court terme.
- Optimisez les requêtes avec le partitionnement et le clustering ; exigez des filtres de partition pour empêcher les analyses complètes de table :
  - bq update –require_partition_filter=true myds.mytable
- Définissez un maximum d’octets facturés par tâche pour plafonner les dépenses :
  - bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
- Utilisez des vues matérialisées, le cache de résultats, des agrégations approximatives, et évitez SELECT * en production. Conservez le stockage et les ressources de calcul dans la même région.

Modes de défaillance et compromis :

Déplacer des objets chauds vers Coldline/Archive déclenche des coûts de récupération et des frais de suppression anticipée.
BigQuery à la demande sans contrôles peut entraîner des coûts exorbitants dus à des analyses non filtrées ; imposez un maximum d’octets facturés et des filtres de partition.
Le sur-sharding des bases de données augmente la complexité opérationnelle ; effectuez des benchmarks avant de diviser.

Réseaux, débit, quotas et conception durable

Le déplacement des données et la conception de la simultanéité influencent fortement le coût et la performance ; les choix en matière de durabilité affinent davantage le placement et la planification.

Trafic de sortie réseau, trafic inter-régional, CDN et mise en cache
- Minimisez les sauts inter-régionaux ; ne répliquez les données que lorsque la proximité de l’utilisateur ou la conformité l’exige. Utilisez Cloud CDN pour décharger le contenu statique et le contenu dynamique pouvant être mis en cache ; ajustez les clés de cache, les TTL et les URL signées pour obtenir des taux de succès élevés.
- Mettez en cache près des clients (CDN), à la périphérie de votre VPC (cache proxy) et au sein des services (caches en mémoire comme Memorystore). Méfiez-vous des données obsolètes et des tempêtes d’invalidation ; définissez des en-têtes Cache-Control explicites.
Mesure de la performance, tests de charge et mise à l’échelle
- Établissez des SLO et mesurez-les avec Cloud Monitoring, les vérifications de disponibilité (Uptime checks), Cloud Trace et Profiler. Suivez la latence p95/p99 et les signaux de saturation.
- Effectuez des tests de charge avec des données réalistes et un temps de réflexion. Échelonnez les tests pour éviter de déclencher les limites de débit globales ; demandez des augmentations de quota temporaires.
- Augmentez le débit en utilisant des réplicas horizontaux, des files d’attente partitionnées (sharded), des sujets partitionnés et des autoscalers basés sur les métriques de backlog. Préférez les pipelines asynchrones lorsque c’est possible.
Quotas, simultanéité, limites de débit et backpressure
- Inventoriez les quotas par service et par région ; imposez un backoff exponentiel avec gigue côté client pour les réponses 429/5xx. Mettez en œuvre un contrôle d’admission et une backpressure basée sur des files d’attente pour protéger les dépendances.
- Ajustez le contrôle de flux de Pub/Sub (nombre/volume maximal de messages en attente), le traitement par lots (batching) et le parallélisme. Dans Cloud Run et GKE, dimensionnez correctement la simultanéité pour correspondre au CPU et à la mémoire, afin d’éviter l’inflation de la latence de queue.
Conception axée sur la durabilité
- Préférez les services serverless et gérés à forte utilisation. Choisissez des régions avec des pourcentages d’énergie décarbonée plus élevés lorsque la latence et la conformité le permettent.
- Planifiez les tâches batch et flexibles pendant les fenêtres à faible émission de carbone ; utilisez les rapports Carbon Footprint pour suivre l’impact.
- Utilisez des types de machines écoénergétiques et envisagez le calcul basé sur ARM lorsque c’est compatible pour améliorer la performance par watt.
Gouvernance qui équilibre fiabilité, sécurité, performance et coût
- Définissez des garde-fous architecturaux : libellés obligatoires, alertes budgétaires, règles d’organisation (par exemple, restreindre les adresses IP externes), SLO/budgets d’erreur et SLO de coût.
- Menez des revues régulières coût-performance avec l’ingénierie, la sécurité et la finance. Intégrez Recommender et des tableaux de bord personnalisés ; construisez des runbooks de remédiation.
- Équilibrez explicitement les compromis : multi-région contre régional (durabilité et latence contre coût et trafic de sortie), couches de chiffrement et d’inspection (sécurité contre CPU et latence), et autoscaling agressif (performance contre quota et risque de dépenses).

Modes de défaillance et compromis typiques :

L’analytique inter-régionale sur un jeu de données mono-régional génère un trafic de sortie soutenu ; répliquez ou déplacez le calcul.
Une mauvaise configuration du CDN entraîne de faibles taux de succès du cache ; surveillez les succès du cache et le trafic de sortie de l’origine pour valider les économies.
L’absence de backpressure lors de pannes partielles amplifie la défaillance ; mettez en œuvre des circuit breakers et effectuez un délestage de charge progressif.

Scénario de problème pratique

Acme Learn, une entreprise d’éducation en ligne, subit des pics imprévisibles en soirée lors d’événements en direct. Les coûts augmentent fortement à cause des requêtes BigQuery inter-régionales, des pics d’autoscaling et du trafic de sortie des ressources statiques. La direction souhaite également réduire l’impact carbone sans dégrader l’expérience utilisateur.

Approche :

Consolider la visibilité de la facturation et appliquer l’allocation des coûts
- Créez une exportation de la facturation vers BigQuery et des tableaux de bord segmentés par produit, environnement et région en utilisant des libellés et des tags standardisés dans les modèles de déploiement.
- Justification : La visibilité en quasi-temps réel lie les dépenses aux équipes responsables, permettant une responsabilisation budgétaire. Les libellés permettent une refacturation granulaire et la détection d’anomalies.
Ré-architecturer l’analytique pour colocaliser le calcul et le stockage
- Déplacez les jeux de données d’analyse d’événements et les requêtes planifiées dans la même région que les processeurs de flux. Pour BigQuery, faites passer les équipes à fort volume du modèle à la demande aux réservations de capacité, dimensionnées pour la simultanéité de pointe avec un petit tampon de flexibilité.
- Justification : La colocalisation élimine le trafic de sortie inter-régional. Le modèle basé sur la capacité de BigQuery stabilise les coûts sous charge tout en préservant la performance.
Optimiser la diffusion de contenu avec la mise en cache en périphérie (edge)
- Placez les ressources de cours statiques et semi-dynamiques derrière Cloud CDN, en définissant des en-têtes Cache-Control explicites et des URL signées pour le contenu premium. Ajustez les TTL en fonction de la mutabilité du contenu.
- Justification : Des taux de succès de cache élevés déplacent le trafic des origines vers la périphérie, réduisant le trafic de sortie et le calcul à l’origine tout en améliorant la latence pendant les pics.
Renforcer l’autoscaling et les réservations pour les événements en direct
- Ajoutez un groupe d’instances géré régional pour la couche API avec des cibles d’autoscaler basées à la fois sur le CPU et le backlog de requêtes. Créez une petite réservation de capacité zonale pour garantir une marge de manœuvre pour les pics pendant les événements. Activez l’autoscaling prédictif avant les sessions planifiées.
- Justification : L’autoscaling à double signal réagit à la fois à l’utilisation et à la demande, tandis que les réservations et le pré-chauffage prédictif évitent la latence de démarrage à froid et les manques de capacité.
Appliquer un mix de calcul : charge de base sur des engagements, pics sur des instances Spot
- Achetez des engagements d’un an pour les charges de travail de base de l’API et du traitement de données. Configurez les tâches de transcodage et d’enrichissement par lots sur des VMs Spot avec du checkpointing et des groupes d’instances multi-zones.
- Justification : Les engagements réduisent le coût de l’état stable ; les VMs Spot fournissent une élasticité à faible coût pour les travaux interruptibles sans risquer le trafic utilisateur.
Instaurer un cycle de vie du stockage et un placement régional
- Conservez les métadonnées “chaudes” des cours et les vignettes dans un stockage Standard régional, à proximité du calcul qui les sert. Transférez les journaux et les flux de clics bruts vers Nearline après 30 jours et supprimez-les après 180 jours. Pour les archives de conformité, utilisez Archive avec des SLA de récupération documentés.
- Justification : Aligne la classe de stockage sur les modèles d’accès, réduisant les coûts courants tout en respectant les politiques de rétention.
Mettre en place des garde-fous sur l’utilisation de BigQuery
- Exigez des filtres de partition sur les grandes tables et définissez des valeurs par défaut au niveau du projet pour le nombre maximal d’octets facturés par tâche. Introduisez des vues matérialisées pour les agrégats courants et les modèles d’ingestion partitionnés.
- Justification : Empêche les scans complets accidentels, stabilise les dépenses et accélère les requêtes fréquentes.
Concevoir pour le débit avec backpressure et quotas
- Intégrez Cloud Tasks pour les workflows à débit limité et configurez les abonnés Pub/Sub avec un contrôle de flux. Mettez en œuvre un backoff exponentiel avec gigue pour les API tierces et définissez des plafonds de simultanéité par service dans Cloud Run.
- Justification : Contrôle la demande pour respecter les quotas, protège les dépendances en cas de pic et évite les défaillances en cascade.
Intégrer la durabilité dans les opérations
- Préférez le serverless lorsque c’est possible, sélectionnez des régions avec une énergie plus décarbonée pour l’analytique, et planifiez les tâches batch non urgentes pendant les fenêtres à faible émission de carbone. Suivez les émissions avec Carbon Footprint et incluez-les dans les revues trimestrielles.
- Justification : Améliore la performance par watt et réduit l’impact carbone avec des compromis minimes pour l’utilisateur.
Gouverner en continu
- Créez des budgets et des alertes par produit, imposez les libellés via des règles, et établissez des revues mensuelles coût-performance-SLO. Automatisez le nettoyage des ressources inactives et des disques non attachés basé sur Recommender.
- Justification : Une gouvernance continue pérennise les gains, prévient les régressions et équilibre la fiabilité, la sécurité, la performance et le coût dans le temps.