Google PCD: Coûts, gouvernance et opérations applicatives durables — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — 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

Les coûts, la gouvernance et les opérations durables sont indissociables dans le développement d’applications modernes sur Google Cloud. L’objectif est d’exposer et de contrôler les dépenses, de concevoir des services qui s’adaptent de manière économique et d’appliquer des garde-fous qui maintiennent les environnements sécurisés, conformes et propres, tout en équilibrant la performance et la fiabilité. Cette section détaille les mécanismes pratiques (facturation et libellés, paramètres d’autoscaling, quotas et règles), l’économie spécifique aux charges de travail (Cloud Run, GKE, plateformes de données) et les choix conscients de la durabilité qui réduisent le gaspillage des ressources inutilisées et l’impact carbone sans nuire à l’expérience utilisateur.

Contrôle et visibilité des coûts

• Comptes de facturation, libellés, répartition des coûts, budgets, alertes et visibilité
  • Utilisez un compte de facturation dédié par unité commerciale ou source de financement pour isoler la propriété et permettre des autorisations granulaires. Exportez les données de facturation vers BigQuery pour une analyse détaillée, des prévisions et une refacturation interne (chargeback).
  • Les libellés (labels) sont des paires clé-valeur sur les ressources pour l’attribution des coûts. Standardisez les clés de libellés (team, app, env, cost-center) et imposez-les via une règle d’organisation et des vérifications CI. Note : les libellés ne sont pas rétroactifs ; les ressources non libellées faussent les rapports.
  • Utilisez des budgets et des alertes au niveau du compte de facturation et du projet. Combinez des seuils (par ex., 50, 90, 100 pour cent) et des déclencheurs basés sur les prévisions. Acheminez les notifications de budget vers Pub/Sub et transférez-les vers des outils de Chat/Ops. Les budgets alertent ; ils n’imposent pas de limite stricte.
  • Pour les plateformes partagées (par ex., GKE, BigQuery), utilisez des libellés par espace de noms (namespace) ou par tâche (job) et attachez-les aux journaux et à l’utilisation pour permettre la répartition des coûts (showback/chargeback).

Exemple : ajouter des libellés

undefined

• Quotas, limites, prévision de la consommation et gouvernance de la capacité
  • Les quotas protègent les services et limitent les coûts excessifs. Examinez régulièrement les quotas de service, dimensionnez-les correctement par projet et demandez des augmentations avant les lancements. Mettez en œuvre des vérifications de pré-déploiement qui comparent l’utilisation de pointe attendue par rapport aux quotas.
  • Prévoyez les dépenses en utilisant l’exportation de la facturation (Billing export) ainsi que la télémétrie d’utilisation des produits (métriques Cloud Monitoring, métriques basées sur les journaux). Modélisez des scénarios (QPS attendu, données analysées) et validez-les en pré-production.
  • Modes de défaillance : atteindre un quota au milieu d’un incident ou d’un lancement de produit entraîne une limitation (throttling) (429/403), des pannes partielles ou une dégradation silencieuse. Des quotas sur-provisionnés augmentent le rayon d’impact (blast radius) des tâches défectueuses.

Exemple : lister les quotas de Compute Engine

undefined

Gouvernance des coûts des données, de l’analytique et du réseau

• Classes de stockage, contrôles du cycle de vie, mise à l’échelle des bases de données et conception de la sortie réseau
  • Choisissez les classes de Cloud Storage en fonction du modèle d’accès : Standard pour les données chaudes ; Nearline, Coldline ou Archive pour les données plus froides. Soyez attentif aux minimums de récupération et de suppression anticipée pour les niveaux plus froids.
  • Les règles de cycle de vie automatisent les transitions et les suppressions. Utilisez le mode bi-régional pour la résilience lorsque la latence multi-régionale est acceptable ; colocalisez le calcul et les données pour réduire la sortie réseau et la latence.
  • Mise à l’échelle des bases de données :
    • Cloud SQL : mettez à l’échelle verticalement avec prudence ; utilisez des réplicas en lecture pour les lectures ; activez la mise à l’échelle automatique du stockage ; utilisez les plans de requête et le regroupement de connexions (connection pooling). Un débit d’écriture élevé peut nécessiter un sharding ou une migration vers Spanner/Bigtable.
    • Spanner : mise à l’échelle horizontale en ajoutant des nœuds ; configurations multi-régionales pour la disponibilité et les lectures globales ; concevez des schémas et des clés pour une charge équilibrée.
    • Bigtable : concevez les clés de ligne pour éviter les points chauds (hotspots) ; mettez à l’échelle les nœuds du cluster et le stockage séparément.
  • Sortie réseau : évitez le trafic inter-régional ; placez les clients et les données dans la même région lorsque c’est possible. Utilisez Cloud CDN pour le contenu à l’échelle d’Internet, Cloud Interconnect/Peering pour l’hybride, et Private Google Access ou Private Service Connect pour accéder aux API Google de manière privée. Le trafic inter-zone/régional inutile augmente les coûts et la latence.

Exemple : Cycle de vie de Cloud Storage cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

• Contrôles des requêtes BigQuery, rétention des données et coût d’utilisation de l’analytique
  • Contrôlez les octets analysés : filtrez toujours par clés de partition/cluster ; évitez SELECT * ; utilisez des vues matérialisées et la mise en cache des résultats pour les requêtes répétées ; utilisez des agrégations approximatives lorsque c’est possible.
  • Plafonnez le coût d’analyse avec maximum bytes billed et définissez la priorité des tâches sur batch pour les travaux non urgents afin de réduire les interférences et les coûts.
  • Choisissez le modèle de tarification : à la demande (on-demand) pour les charges de travail sporadiques ; réservations (slots) avec engagements pour les charges de travail stables à volume élevé. Utilisez des réservations et des attributions distinctes pour isoler les équipes.
  • Rétention des données : définissez l’expiration des ensembles de données/tables et des partitions pour la gouvernance ; mettez en œuvre un stockage à plusieurs niveaux ou une exportation pour l’archivage.
  • Modes de défaillance : les grandes tables non partitionnées font exploser les coûts ; les requêtes sans filtres de partition analysent les tables complètes ; des expirations trop agressives suppriment des données nécessaires ; une contention excessive des slots dégrade le SLA.

Exemple : plafonner le coût d’une requête bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

Gouvernance organisationnelle et hygiène de l’environnement

• Politiques d’organisation, nommage des ressources, étiquetage et séparation des projets

  • Utilisez les politiques d’organisation pour appliquer des garde-fous : restreindre les emplacements des ressources, interdire les adresses IP externes, exiger les CMEK, limiter les services autorisés, contrôler le VPC peering et imposer OS Login si nécessaire. Appliquez au niveau de l’organisation ou du dossier avec des exceptions modélisées via la hiérarchie.
  • Standardisez le nommage des ressources pour encoder l’environnement, le projet, l’application et la région (par ex., app-env-region-suffixe). Appliquez via des vérifications CI ou du policy-as-code.
  • Distinguez :
    • Labels : attribution pour la facturation/les opérations.
    • Tags (de première classe) : à attacher aux ressources et à utiliser dans les conditions IAM et le ciblage des politiques d’organisation.
    • Tags réseau : pour les règles de pare-feu sur Compute Engine.
  • Séparation des projets : isolez les environnements (prod, staging, dev) et les charges de travail sensibles. Utilisez le VPC partagé (Shared VPC) pour une mise en réseau centralisée et des projets de service appliquant le moindre privilège. Cela réduit le rayon d’impact et simplifie IAM.

• Cycle de vie de l’environnement, environnements de test éphémères et automatisation du nettoyage

  • Provisionnez les environnements via l’IaC (Terraform) et activez des environnements éphémères par PR (Pull Request). Définissez des labels de durée de vie (TTL) et un démantèlement automatique après fusion ou inactivité.
  • Utilisez Cloud Scheduler avec des jobs Cloud Run ou des Functions pour rechercher les ressources obsolètes par label/âge et les supprimer. Exportez l’inventaire via Cloud Asset Inventory pour piloter les audits.
  • Modes de défaillance : les bacs à sable (sandboxes) abandonnés entraînent des coûts ; des labels ou des TTL manquants empêchent le nettoyage ; un nettoyage trop agressif peut supprimer des ressources actives — ajoutez des listes d’autorisation (allowlists) et des périodes de grâce.

• Architecture soucieuse de la durabilité et équilibre entre coût, performance et fiabilité

  • Préférez les services gérés et serverless pour réduire l’inactivité et améliorer l’utilisation des ressources.
  • Choisissez des régions à plus faible intensité carbone lorsque cela est conforme ; planifiez les charges de travail par lots pendant les périodes où l’énergie décarbonée est plus abondante, si possible.
  • Optimisez la gravité des données et la mise en cache pour réduire l’énergie consommée par le réseau. Ajustez l’autoscaling et la simultanéité pour diminuer la sous-utilisation. Utilisez le profilage pour supprimer les chemins de code gaspilleurs qui déclenchent un excès de calcul ou d’E/S.
  • Équilibre : n’ajoutez des instances ou des réplicas minimums que lorsque les SLO l’exigent ; évaluez la latence de queue par rapport à la simultanéité et la redondance par rapport à l’utilisation de Spot. Validez avec des tests de charge basés sur les SLO et une modélisation coût/performance.

Scénario de problème pratique

NimbusMarket, une entreprise de e-commerce, connaît des pics de trafic pendant les ventes flash et une augmentation des dépenses analytiques. Ils exécutent les API client sur Cloud Run, des workers d’arrière-plan sur GKE, et l’analyse des produits dans BigQuery. La direction demande une réduction des coûts de 25 % sans compromettre le SLO de 99,9 % pour l’API.

Approche :

1. Établir une visibilité des coûts et des garde-fous

   • Créez des budgets avec des alertes prévisionnelles à 60, 90 et 100 % pour le compte de facturation, avec des notifications Pub/Sub acheminées vers l’équipe d’astreinte.
   • Standardisez les labels (team, app, env, cost-center) et imposez-les via la CI sur les plans Terraform ; ajoutez une politique d’organisation qui restreint les emplacements des ressources aux régions approuvées. Justification : Les budgets donnent une alerte précoce ; les labels permettent des rapports par équipe ; les politiques empêchent l’utilisation accidentelle de régions à fort egress et améliorent la conformité.

2. Ajuster Cloud Run pour une mise à l’échelle économique

   • Réglez containerConcurrency à 40 pour l’API stateless après que le profilage a confirmé un temps CPU moyen de 30 ms et des E/S non bloquantes. Configurez minScale=2 pour éviter les démarrages à froid pendant les heures normales ; définissez une politique planifiée pour ramener minScale à 0 pendant la nuit. Justification : Une simultanéité plus élevée améliore l’utilisation et réduit le nombre d’instances ; un nombre minimal d’instances stables préserve les SLO avec un coût de base limité qui est supprimé en dehors des heures de pointe.

3. Dimensionner correctement les charges de travail GKE et activer un autoscaling efficace

   • Appliquez des requests de 500m CPU/512Mi et des limits de 1 CPU/768Mi aux pods worker en vous basant sur le profilage. Activez le HPA sur la profondeur de la file d’attente et la latence de traitement, et le VPA en mode recommandation pour affiner les requests de manière itérative. Vérifiez que les PodDisruptionBudgets autorisent la réduction d’échelle (scale-down). Activez le Cluster Autoscaler sur le pool avec plusieurs nœuds plus petits. Justification : Des requests précises permettent une planification et un autoscaling efficaces ; le HPA aligne la capacité sur le backlog ; le VPA évite la dérive ; plusieurs petits nœuds réduisent la capacité inutilisée et accélèrent les événements de mise à l’échelle.

4. Adopter la capacité Spot pour les traitements par lots tolérants aux pannes

   • Déplacez la génération de vignettes d’images vers un pool de nœuds basé sur Spot avec création de points de contrôle (checkpointing). Implémentez des hooks preStop pour vider le travail en cours et un contrôleur pour replanifier les tâches interrompues. Justification : La génération de vignettes est idempotente et flexible dans le temps, ce qui la rend idéale pour réaliser des économies avec Spot avec un impact minimal sur l’expérience utilisateur.

5. Réduire les coûts d’analyse (scan) et isoler les charges de travail

   • Partitionnez et clusterisez la table des événements par event_date et customer_id. Ajoutez une expiration de table pour les événements bruts après 180 jours. Assignez les analystes marketing à une réservation BigQuery distincte avec un plafond de slots ; imposez maximum_bytes_billed dans leurs requêtes planifiées. Convertissez les rapports nocturnes en priorité batch. Justification : Le partitionnement et la clusterisation limitent les octets par requête ; l’expiration applique la gouvernance ; les réservations isolent les « voisins bruyants » ; le mode batch réduit la contention et le coût pour les tâches non urgentes.

6. Optimiser le cycle de vie du stockage et l’egress

   • Stockez les images de produits en mode bi-régional (dual-region) à proximité des clients ; déplacez les images non consultées pendant 30 jours vers Coldline via des règles de cycle de vie ; servez-les via Cloud CDN. Colocalisez les services Cloud Run avec Cloud SQL dans la même région et activez Private Service Connect vers les API Google. Justification : Le CDN réduit l’egress et la latence ; le cycle de vie déplace le contenu froid vers un stockage moins cher ; la colocalisation minimise l’egress et améliore la performance.

7. Mettre en œuvre l’automatisation du nettoyage et les vérifications de durabilité

   • Étiquetez les environnements éphémères avec ttl-hours et exécutez une tâche Cloud Run nocturne qui supprime les ressources expirées. Utilisez les rapports Carbon Footprint pour envisager de déplacer les tâches par lots vers une région à plus faible empreinte carbone et de les planifier pendant les heures creuses en termes d’émission de carbone. Justification : Le nettoyage automatisé prévient les fuites de coûts ; la planification soucieuse du carbone réduit l’impact environnemental sans affecter les SLO.

8. Valider avec des tests de charge tenant compte des SLO et des modèles de coûts

   • Exécutez des tests de charge qui rejouent les schémas des ventes flash ; vérifiez la latence p95 et les budgets d’erreur. Comparez les coûts avant/après à l’aide des tableaux de bord d’exportation de la facturation. Justification : Confirme que les ajustements atteignent les objectifs de fiabilité tout en générant des économies mesurables alignées sur les objectifs.

En exécutant ces étapes, NimbusMarket aligne les dépenses sur la demande, prévient le gaspillage dû à l’inactivité et applique la gouvernance, réalisant ainsi les économies ciblées tout en maintenant le SLO de 99,9 % pour l’API et en améliorant sa posture en matière de durabilité.

← Tests · Tous les domaines

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

Parcourir Google →