Google ACE: Gestion des coûts, performance et optimisation de la capacité — 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

La gestion des coûts et l’optimisation des performances/de la capacité sur Google Cloud exigent une visibilité continue, des décisions de dimensionnement adéquat (right-sizing) et une gouvernance qui aligne l’utilisation des ressources sur les objectifs métier. Une pratique efficace combine des contrôles financiers (budgets, allocation), des leviers techniques (autoscaling, réservations, politiques de cycle de vie), des choix architecturaux (localité des données, réplication) et des retours opérationnels (télémétrie, tests de charge). Cette section détaille les outils clés, les compromis et les modes de défaillance pour le calcul, le stockage, le traitement des données, le réseau, les bases de données, les quotas et l’ingénierie des performances.

Visibilité des coûts, budgets et allocation

• Rapports de facturation et exportations :

  • Utilisez les Cloud Billing Reports pour des analyses rapides des tendances et des répartitions par SKU ; activez l’exportation des données Cloud Billing vers BigQuery pour obtenir des données de coût et d’utilisation détaillées et interrogeables. Cela permet les prévisions quotidiennes/mensuelles, la détection d’anomalies et les agrégations multi-projets avec du SQL standard.
  • L’exportation de la table des prix (Pricing table) aide à rapprocher les prix catalogue des coûts et des crédits par SKU.
  • Modes de défaillance : L’utilisation exclusive des vues de la console limite la granularité ; ne pas exporter vers BigQuery empêche la modélisation historique et un showback/chargeback précis.

• Budgets et alertes :

  • Créez des budgets ciblés sur des comptes de facturation, des projets, des dossiers, des services ou des filtres par étiquette/tag ; configurez des alertes de seuil (par ex., 50/90/100 %) sur les coûts réels et prévisionnels. Envisagez des canaux de notification via Pub/Sub pour déclencher des actions automatisées (par ex., mettre en pause la non-prod).
  • Compromis : Des arrêts automatisés agressifs réduisent les dépenses mais peuvent nuire à la fiabilité s’ils sont appliqués aux chemins de production.

• Étiquettes et tags pour l’allocation :

  • Appliquez les étiquettes de ressources et les tags Resource Manager de manière cohérente (env, app, owner, cost-center). Les tags prennent en charge les politiques d’organisation et apparaissent dans les filtres de facturation pour une allocation robuste.
  • Gouvernance : Appliquez les politiques d’étiquettes/tags à l’aide d’Organization Policy, de modèles de déploiement et de vérifications CI/CD.
  • Modes de défaillance : Des clés incohérentes ou des étiquettes manquantes cassent les modèles d’allocation ; les tags hérités ne sont pas appliqués à tous les types de ressources si l’outillage est incohérent.

• Modèles d’allocation des coûts :

  • Le showback/chargeback utilise généralement une hiérarchie : projet → service/SKU → étiquette/tag. Les coûts de plateforme partagés (par ex., load balancers, sortie VPC) peuvent être répartis selon des inducteurs tels que le nombre de requêtes, les Go transférés ou les heures-CPU mesurées via les journaux/métriques.
  • Compromis : Les modèles simples (répartition égale) sont faciles à exécuter mais peuvent mal tarifer les gros utilisateurs ; les modèles granulaires nécessitent une télémétrie fiable et plus de frais généraux.

Petit exemple (simulation BigQuery pour l’estimation des coûts) :

undefined

Efficacité du calcul et optimisation du cycle de vie

• Dimensionnement adéquat (rightsizing) et types de machines personnalisés :

  • Utilisez l’API/console Recommender pour dimensionner adéquatement les VM en fonction des percentiles d’utilisation du CPU/de la mémoire. Préférez les types de machines personnalisés pour les besoins stables et intermédiaires (par ex., 2 vCPU/10 Go de RAM) afin d’éviter de payer pour de la capacité inutilisée.
  • Modes de défaillance : Le sous-dimensionnement de services sensibles à la latence ou sujets à des pics d’activité (bursty) peut provoquer une limitation (throttling). Validez avec des tests de charge et prévoyez une marge de sécurité.

• Engagements d’utilisation (CUDs) :

  • Achetez des CUDs basés sur les ressources (vCPU, mémoire, GPU) à l’échelle régionale pour des durées de 1 ou 3 ans via la console ou la CLI. Idéal pour une capacité de base stable ; superposez l’autoscaling pour les pics.
  • Compromis : Les engagements réduisent le prix unitaire mais sont inflexibles. Un sur-engagement verrouille les dépenses ; un sous-engagement fait perdre les remises.

• Spot VMs :

  • Utilisez les Spot VMs pour les charges de travail tolérantes aux pannes et interruptibles (batch, CI, niveaux sans état). Implémentez le checkpointing et la gestion de la préemption (préavis de 30 secondes via les métadonnées/Pub/Sub).
  • Modes de défaillance : La capacité peut disparaître à tout moment ; ne placez jamais de services avec état (stateful) ou critiques pour le quorum uniquement sur des Spot VMs.

• Autoscaling, planification et cycle de vie :

  • Les groupes d’instances gérés (MIGs) avec autoscaling (basé sur le CPU, le load balancer ou des métriques Cloud Monitoring personnalisées) gèrent la charge variable. Ajustez les contrôles de temporisation (cool-down) et de réduction (scale-in) pour éviter l’oscillation ; alignez le délai initial de la vérification de l’état (health check) sur la disponibilité de l’application.
  • Planification : Arrêtez ou suspendez les VM de dev/test en dehors des heures de bureau ; utilisez les Instance Schedules ou l’automatisation avec Cloud Scheduler et Cloud Functions pour minimiser les coûts d’inactivité.
  • Cycle de vie et maintenance : Activez le redémarrage automatique et la migration lors de la maintenance de l’hôte (host maintenance migrate) pour la haute disponibilité ; sachez que la migration à chaud (live migration) peut ne pas s’appliquer avec des GPU ou des SSD locaux.
  • Nettoyage des ressources inactives : Récupérez les disques persistants non attachés, les snapshots obsolètes et les adresses IP statiques inutilisées à l’aide de Recommender.
  • Modes de défaillance : Des délais de health check trop courts ou des signaux de disponibilité (readiness) manquants provoquent un sur-provisionnement ; un scale-in trop agressif interrompt les connexions ; la désactivation de l’autoréparation (autohealing) masque les nœuds défaillants.

Petits exemples :

undefined

undefined

Aspects économiques du stockage et du traitement des données

• Classes de stockage et cycle de vie de Cloud Storage :

  • Choisissez les classes en fonction du profil d’accès : Standard (données chaudes), Nearline (min. 30 jours), Coldline (min. 90 jours), Archive (min. 365 jours). Appliquez des règles de cycle de vie pour basculer vers des classes inférieures et supprimer les données selon un calendrier.
  • Compromis sur la récupération : Les classes moins chères imposent des frais de récupération par Go et des frais de durée de stockage minimale ; des lectures fréquentes sur Coldline/Archive annulent les économies. Planifiez les workflows de restauration en tenant compte des pics de coûts de lecture.
  • Gouvernance : Utilisez des règles de conservation et des blocages d’objet pour la conformité ; activez le mode “requester-pays” (paiement par le demandeur) pour les ensembles de données partagés afin d’éviter les surprises de facturation entre équipes.

• Exemple de règle de cycle de vie (basculement puis suppression) :

  • Définissez des actions SetStorageClass et Delete basées sur l’âge pour automatiser les transitions et le nettoyage des données obsolètes.

• Contrôles des coûts de BigQuery :

  • Les requêtes à la demande sont facturées par octets traités ; minimisez-les avec l’élagage de partitions (partition pruning) et le clustering. Partitionnez par date d’ingestion ou par colonne de date ; clusterisez jusqu’à quatre colonnes à haute cardinalité/sélectivité.
  • Utilisez des exécutions à blanc (dry runs) pour estimer le coût, des vues matérialisées pour les agrégations fréquentes et des décorateurs de table pour réduire les fenêtres temporelles.
  • Les réservations (slots) offrent des performances et des dépenses prévisibles ; utilisez des attributions par projet/dossier et envisagez des engagements flexibles (flex commitments) pour les pics de courte durée.
  • Modes de défaillance : Des analyses de tables non partitionnées, des SELECT * sur des tables larges ou un clustering mal ordonné génèrent des quantités massives d’octets analysés ; les tables intermédiaires éphémères peuvent faire exploser le stockage si elles n’expirent pas.

Exemple court (extrait JSON de cycle de vie Cloud Storage) :

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Réseau, bases de données et mise à l’échelle en tenant compte des quotas

• Impact de la sortie réseau (egress) et de l’architecture :

  • La sortie vers Internet, entre régions et via des adresses IP externes entraîne des frais ; le trafic au sein d’une même région via une IP interne est généralement gratuit. Choisissez le niveau réseau Premium pour la performance ou Standard pour les charges de travail sensibles au coût avec des exigences de latence/gigue moins strictes.
  • Load balancers : Les L7 HTTP(S) et L4 TCP/UDP ont des frais de traitement de données et de règles de transfert ; les LB inter-régionaux peuvent ajouter des frais de sortie inter-régionale. La consolidation des LB réduit les coûts fixes mais peut augmenter le rayon d’impact en cas de défaillance (blast radius).
  • Optimisation : Maintenez le trafic intra-régional ; utilisez des buckets et des services régionaux ; évitez le “hairpinning” (trafic en épingle à cheveux) via des IP externes. Mettez en cache les ressources statiques en périphérie (edge) pour réduire la sortie depuis l’origine.
  • Modes de défaillance : L’utilisation accidentelle d’IP externes entre des services dans le même VPC génère une sortie réseau inutile ; la réplication multi-régionale double la sortie pour les chemins d’écriture.

• Dimensionnement des bases de données, réplicas et disponibilité :

  • Cloud SQL : Dimensionnez les vCPU/RAM pour la charge au 95e centile ; activez le redimensionnement automatique du stockage ; utilisez des réplicas en lecture (read replicas) pour la mise à l’échelle horizontale des lectures ; la haute disponibilité (HA) double le coût de calcul mais réduit le RTO de basculement. Le regroupement de connexions (connection pooling) évite une surcharge excessive de connexions.
  • Spanner : La capacité est provisionnée en nœuds ou en unités de traitement ; les configurations multi-régionales améliorent la disponibilité et la latence en lecture mais augmentent le coût et la latence en écriture ; planifiez soigneusement les divisions (splits) et les points chauds (hotspots).
  • Bigtable : Le nombre de nœuds détermine le débit ; l’autoscaler aide à suivre le trafic ; la réplication multi-cluster ajoute de la disponibilité et des coûts ; concevez un schéma pour une distribution de clés uniforme.
  • Compromis : Les réplicas améliorent le débit en lecture et la disponibilité mais augmentent l’amplification d’écriture et la sortie réseau ; la cohérence forte (strong consistency) et les écritures multi-régionales ajoutent de la latence.

• Quotas, limites de débit et contre-pression (backpressure) :

  • Comprenez les quotas par API et la simultanéité par service. Implémentez un backoff exponentiel avec gigue (jitter) pour les erreurs 429/5xx. Appliquez un lissage de charge basé sur une file d’attente avec des jobs Pub/Sub et Dataflow ou Cloud Run.
  • Paramètres de simultanéité : Dans Cloud Run, une simultanéité plus élevée réduit les coûts mais risque d’augmenter la latence de queue (tail latency) ; ajustez l’allocation de CPU sur demande pour un débit stable.
  • Contre-pression (Backpressure) : Utilisez le contrôle de flux dans les abonnés Pub/Sub, les disjoncteurs (circuit breakers) et le contrôle d’admission pour prévenir les défaillances en cascade.
  • Modes de défaillance : Ignorer les quotas mène à une limitation soudaine (throttling) ; l’autoscaling peut amplifier la charge sur les services en aval sans contre-pression, provoquant des nouvelles tentatives et aggravant les coûts.

Mesure de la performance et gouvernance de l’optimisation

• Mesure et tests de charge :

  • Établir des SLI/SLO pour la latence, le taux d’erreur et la saturation. Utiliser les tableaux de bord Cloud Monitoring, les vérifications de disponibilité (uptime checks) et les alertes. Instrumenter le traçage (Cloud Trace) et le profilage (Cloud Profiler) pour localiser les chemins critiques et la contention de verrous.
  • Effectuer des tests de charge avec des modèles de trafic, une cardinalité des données et des temps de réflexion réalistes. Valider les paramètres de l’autoscaler, le préchauffage et les portes de préparation (readiness gates). Inclure des scénarios de basculement et de chaos pour observer la marge de capacité et le temps de récupération.
  • Diagnostic des goulots d’étranglement : Utiliser la méthode USE (Utilisation, Saturation, Erreurs) pour le CPU, la mémoire, le disque, le réseau et les dépendances en aval ; corréler avec les journaux et les traces.

• Gouvernance équilibrant coût, sécurité et fiabilité :

  • Garde-fous FinOps : Libellés/tags obligatoires ; budgets avec alertes prévisionnelles ; exportations de facturation centralisées et cadences de revue des coûts. Intégrer les recommandations de Recommender (IP/disques inactifs, redimensionnement) dans le backlog avec des SLA par propriétaire.
  • Sécurité : Préférer la connectivité privée (pas d’adresses IP externes), VPC Service Controls pour les risques d’exfiltration de données — reconnaître que les chemins privés peuvent modifier les modèles de sortie (egress) et les coûts. Chiffrer les données au repos et en transit ; prendre en compte l’utilisation de KMS dans les modèles de coûts.
  • Fiabilité : Réserver la capacité de base via des CUD ou des réservations BigQuery ; conserver une marge pour les pics de charge afin de respecter les SLO ; effectuer des exercices pratiques (game days) réguliers. Documenter les cas où les VM Spot ou un autoscaling agressif sont inacceptables pour les chemins critiques.
  • Gestion du changement : Traiter les paramètres affectant les coûts (seuils de l’autoscaler, réservations BigQuery, topologie du LB) en tant que code (IaC) avec des plans de revue et de restauration (rollback).

Scénario de problème pratique

Contoso Media exploite une plateforme d’analyse vidéo multi-régions qui subit une augmentation des coûts et des violations occasionnelles du SLO de latence lors des pics de trafic. La direction souhaite une réduction des coûts de 20 % sans compromettre un SLO de latence p95 de 300 ms pour l’API et un SLA de 2 heures pour l’achèvement des traitements par lots nocturnes.

1. Établir des bases de référence pour les coûts et la performance

• Action : Activer l’exportation de Cloud Billing vers BigQuery et créer des tableaux de bord corrélant les coûts des SKU avec les SLI de Cloud Monitoring (latence, CPU, octets en sortie). Exécuter des bq dry runs sur les 20 principales requêtes pour estimer les octets analysés.
• Justification : Les bases de référence identifient les services à fort impact et relient les dépenses aux facteurs de performance, permettant une optimisation ciblée.

2. Imposer l’attribution de tags et les budgets

• Action : Exiger des libellés/tags (env, service, owner, cost-center) via les modèles de déploiement ; définir des budgets par environnement avec des alertes prévisionnelles vers un sujet Pub/Sub FinOps.
• Justification : Des données d’attribution complètes et des alertes proactives permettent une identification rapide des responsables et une action corrective avant les dépassements.

3. Redimensionner et engager la capacité de calcul de base

• Action : Appliquer le redimensionnement de VM de Recommender aux services stables ; convertir la capacité en régime de croisière en CUD régionaux d’un an ; conserver un tampon de 20 à 30 % sur le maximum de l’autoscaler pour les pics.
• Justification : Le redimensionnement et les engagements réduisent le coût unitaire des charges prévisibles tout en préservant une marge pour les SLO.

4. Optimiser l’autoscaling et la préparation (readiness)

• Action : Pour les MIG, basculer les signaux d’autoscaling vers des métriques basées sur les requêtes ou des métriques personnalisées de QPS/latence, définir la période de stabilisation (cooldown) à 120-180 secondes, et aligner le délai initial de la vérification de santé avec le préchauffage de l’application. Activer les contrôles de réduction d’échelle (scale-in) pour empêcher une diminution rapide.
• Justification : Des signaux tenant compte de la charge de travail et une stabilisation évitent l’instabilité et le surprovisionnement qui augmentent les coûts et nuisent à la latence.

5. Réduire la sortie réseau (egress) et la surcharge du load balancer

• Action : Supprimer la communication par IP externe entre les services ; s’assurer que tout le trafic est-ouest utilise l’équilibrage de charge interne ; colocaliser les services bavards au sein des régions ; mettre en cache les ressources statiques en périphérie (edge).
• Justification : Les chemins internes éliminent la sortie (egress) inutile et réduisent le traitement L7, améliorant la latence et les coûts.

6. Cycle de vie et archivage du stockage

• Action : Appliquer les règles de cycle de vie de Cloud Storage pour déplacer les artefacts froids vers Coldline à 90 jours et les supprimer à 365 jours ; configurer le mode requester-pays sur les buckets partagés ; examiner les implications de la durée minimale de stockage pour les données à accès rare.
• Justification : La hiérarchisation et la rétention réduisent les coûts de stockage et de récupération tout en maintenant la conformité.

7. Optimisation des requêtes et de la capacité BigQuery

• Action : Partitionner les grandes tables de faits par date, les organiser en clusters par colonnes à haute sélectivité ; remplacer SELECT * par des projections de colonnes ; introduire des vues matérialisées pour les principales agrégations ; acheter une petite réservation pour les fenêtres ETL de pointe et utiliser des flex slots pendant les pics de traitement par lots.
• Justification : Le partitionnement/clustering réduit les octets analysés ; les réservations de capacité stabilisent la performance et le coût pour les charges de travail critiques.

8. Mise à l’échelle et réplicas de la base de données

• Action : Pour les services Cloud SQL à forte lecture, ajouter des réplicas en lecture ; optimiser la mutualisation des connexions (connection pooling) ; configurer le redimensionnement automatique du stockage ; tester le basculement pour valider les RTO/RPO. Pour Bigtable, activer l’autoscaler et traiter les clés de point chaud (hotspot).
• Justification : Les réplicas déchargent les lectures et protègent les chemins d’écriture ; l’autoscaling maintient le débit aligné sur la demande sans surprovisionnement manuel.

9. Quotas, simultanéité et contre-pression (backpressure)

• Action : Implémenter un backoff exponentiel avec gigue (jitter) ; configurer le contrôle de flux de l’abonné Pub/Sub ; définir la simultanéité de Cloud Run pour équilibrer le débit et la latence ; ajouter des disjoncteurs (circuit breakers) aux frontières en aval.
• Justification : Une contre-pression (backpressure) adéquate prévient les défaillances en cascade et les tentatives de relance incontrôlées qui dégradent les SLO et augmentent les coûts.

10. Validation et gouvernance continues

• Action : Effectuer des tests de charge mensuels et des exercices de chaos ; suivre les budgets d’erreurs/SLO ; intégrer les anomalies de coût et les recommandations de Recommender dans la planification de sprint avec des propriétaires et des dates d’échéance.
• Justification : La validation itérative garantit que les économies persistent et que les SLO restent respectés à mesure que les charges de travail évoluent.

← Fiabilité · Tous les domaines

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

Parcourir Google →