Google PCA: Calcul, plateformes d'application et architecture des charges de travail — 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.

Aperçu

Ce domaine couvre la sélection et la conception de plateformes de calcul sur Google Cloud, l’empaquetage et le déploiement d’applications, ainsi que l’exploitation des charges de travail pour garantir la fiabilité, la performance, la sécurité et l’efficacité des coûts. Il englobe les machines virtuelles, Kubernetes, les environnements d’exécution serverless, l’équilibrage de charge, les stratégies de déploiement, le calcul avec état et spécialisé, ainsi que les modèles de modernisation qui réduisent la dette technique tout en répondant à une demande changeante.

Compute Engine et architectures basées sur les VM

Compute Engine fournit un contrôle granulaire sur les systèmes d’exploitation, le réseau et les types de machines. Choisissez les familles de machines en fonction des caractéristiques de la charge de travail :

E2 : optimisée pour les coûts, à usage général ; idéale pour le dev/test, les applications en rafale.
N2/N2D : équilibre prix/performance pour la plupart des charges de travail de production ; N2D utilise des CPU AMD avec une bande passante mémoire élevée.
C2/C2D/C3 : optimisée pour le calcul pour les tâches gourmandes en CPU (par ex., API à QPS élevé, calcul par lots).
M3 : optimisée pour la mémoire pour les grands ensembles de données en mémoire (caches, analytique en mémoire).
A3 : optimisée pour les GPU (NVIDIA) pour l’entraînement/l’inférence ; attachez également des GPU à d’autres familles.
Confidential VMs (sur les CPU pris en charge) chiffrent les données en cours d’utilisation avec des modifications de code minimales.

Les groupes d’instances gérés (MIG) apportent élasticité et résilience :

Utilisez les Instance Templates pour une configuration immuable et les MIG pour une mise à l’échelle horizontale entre les zones.
Politiques d’autoscaling : CPU, utilisation de l’équilibreur de charge, métriques Cloud Monitoring, ou profondeur de file d’attente via des métriques personnalisées. Définissez des réplicas min/max et un délai de récupération pour éviter l’instabilité sous des charges en rafale.
Les mises à jour progressives et les déploiements canary réduisent les risques ; maintenez des paramètres de surprovisionnement (surge) et d’indisponibilité (unavailable) conservateurs pour les services avec état ou à démarrage à froid lent.

Équilibrage de charge et vérifications de l’état :

L’équilibreur de charge HTTP(S) externe mondial termine la connexion TLS, prend en charge le mappage d’URL et constitue le frontal standard pour les API web ; l’équilibreur de charge HTTP(S) interne pour le trafic est-ouest.
Les vérifications de l’état doivent atteindre les backends. Une défaillance courante est le blocage des sondes, entraînant des redémarrages perpétuels d’instances et une perte de trafic. Autorisez les plages sources des vérifications de l’état vers les ports du backend avec des règles de pare-feu VPC et des tags cibles.

Exemple pour autoriser les vérifications de l’état HTTP vers un MIG :

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

Considérations sur le cycle de vie des VM :

Utilisez des scripts de démarrage ou des métadonnées d’image pour l’amorçage ; stockez la configuration d’exécution dans Secret Manager, et non intégrée aux images.
Pour les VM préemptives/Spot, ajoutez un script d’arrêt (shutdown-script) pour drainer le travail lors de l’avis de préemption.
Appliquez les correctifs via des images préconfigurées et un remplacement progressif pour éviter la dérive de configuration.
Le redimensionnement des disques persistants se fait en ligne : augmentez la taille du disque, puis agrandissez le système de fichiers (par ex., resize2fs sur ext4) avec un temps d’arrêt minimal.

Exemple de redimensionnement de PD :

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

Identité sécurisée et observabilité :

Attachez des comptes de service avec le moindre privilège aux instances ; n’intégrez pas d’identifiants statiques.
Installez l’Ops Agent pour Cloud Logging et Cloud Monitoring. Utilisez Cloud Trace et Cloud Profiler pour réduire la latence de queue et les points chauds.
Exportez les données d’audit et les métriques vers BigQuery ou Cloud Storage pour la conservation et l’analyse à long terme.

Calcul par lots et calcul spécialisé :

Utilisez Cloud Batch ou des MIG avec des VM préemptives pour le traitement par lots tolérant aux pannes afin de réduire les coûts ; implémentez des points de contrôle (checkpointing).
Attachez des GPU/TPU là où l’accélération ML est nécessaire. Utilisez des pools de nœuds dédiés ou des nœuds à locataire unique pour répondre aux exigences de conformité/d’isolation.
Les Confidential VMs protègent les données sensibles en mémoire ; mesurez la surcharge par rapport aux exigences.

Considérations sur l’état :

Maintenez les instances d’application sans état (stateless) ; externalisez les sessions vers un stockage partagé (par ex., Memorystore, Cloud SQL) pour éviter les anomalies visibles par l’utilisateur lors de la mise à l’échelle.
Pour l’état lié à une VM, utilisez des disques persistants régionaux ou des bases de données répliquées ; testez les chemins de basculement.

Kubernetes et plateformes de conteneurs (GKE)

GKE fournit un plan de contrôle géré avec des pools de nœuds de calcul flexibles :

Les clusters régionaux répliquent le plan de contrôle et les nœuds sur plusieurs zones pour une haute disponibilité ; les clusters zonaux concentrent les ressources pour un coût réduit et pour les charges de travail sensibles à la latence.
Utilisez plusieurs pools de nœuds pour segmenter les charges de travail (par ex., usage général, GPU, haute mémoire, spot). Appliquez des taints/tolérances et des règles d’affinité/anti-affinité pour contrôler le placement et réduire les effets de voisinage bruyant.
Niveaux d’autoscaling : le cluster autoscaler ajoute/supprime des nœuds ; le Horizontal Pod Autoscaler (HPA) met à l’échelle les réplicas en fonction de l’utilisation du CPU/de métriques personnalisées ; le Vertical Pod Autoscaler (VPA) ajuste la taille des requêtes. Combinez le HPA avec le cluster autoscaler pour l’élasticité.

Planification des charges de travail et services :

Dimensionnez correctement les requêtes/limites de CPU/mémoire pour minimiser le risque d’éviction et maximiser l’efficacité du bin packing.
Utilisez des PodDisruptionBudgets pour préserver la disponibilité pendant les mises à niveau.
Types de services : ClusterIP (intra-cluster), NodePort/LoadBalancer (nord-sud), et Ingress pour le routage HTTP(S) avec le LB global. Pour les déploiements canary, dirigez le trafic via des backends de Services/Ingress distincts ou un service mesh.

Mises à niveau et résilience :

Utilisez les mises à niveau par déferlement (surge upgrades) et maxUnavailable pour contrôler le taux de renouvellement (churn) ; épinglez les charges de travail critiques à plusieurs zones et pools.
Définissez des fenêtres/exclusions de maintenance pour les périodes critiques de l’entreprise.
Validez avec un environnement de pré-production et des pools de nœuds canary avant un déploiement à grande échelle.

Images et sécurité :

Stockez les images de conteneurs dans Artifact Registry ; activez l’analyse des vulnérabilités et configurez la Binary Authorization ou des attestations pour la provenance.
Utilisez Workload Identity pour mapper un GSA à un KSA pour un accès sans identifiants et selon le principe de moindre privilège aux API Google.
Récupérez la configuration d’exécution depuis Secret Manager via le pilote CSI ; évitez les Secrets Kubernetes pour les valeurs très sensibles, sauf si elles sont chiffrées avec une CMEK et que le RBAC est strict.

Déploiements et restaurations (rollback) :

Préférez les mises à jour progressives (rolling updates) de Deployments avec de petites étapes et des sondes de santé ; pour les systèmes à faible tolérance, utilisez un déploiement bleu-vert via deux Deployments derrière un seul Service et basculez les labels/sélecteurs.
Définissez toujours des sondes de préparation (readiness) et de vivacité (liveness) ; des sondes mal configurées provoquent des redémarrages en cascade ou des trous noirs de trafic (blackholes) pendant les déploiements.

Plateformes sans serveur (Serverless) et événementielles

Le serverless de Google Cloud abstrait l’infrastructure tout en offrant des contrôles robustes sur la mise à l’échelle, la sécurité et les coûts :

Cloud Run : natif pour les conteneurs, déclenché par des requêtes HTTP ou par Eventarc. Mise à l’échelle jusqu’à zéro ; simultanéité configurable ; répartition du trafic par révision pour les déploiements canary et le rollback. Définissez un nombre minimal d’instances pour réduire les démarrages à froid pour les points de terminaison sensibles à la latence. Intégrez avec un VPC via le Serverless VPC Access pour le trafic de sortie privé.
App Engine : PaaS préconfiguré (opinionated). L’environnement Standard offre une mise à l’échelle rapide et des contraintes de simultanéité par requête selon le langage ; l’environnement Flexible exécute des conteneurs sur des VM avec plus de contrôle. Évitez l’état de session local à l’instance ; externalisez-le vers un stockage partagé pour éviter les expériences utilisateur obsolètes ou dupliquées en charge.
Cloud Functions : granularité au niveau de la fonction pour la logique événementielle. Utilisez des déclencheurs Pub/Sub, Cloud Storage ou Eventarc pour des micro-opérations légères ; gardez les fonctions idempotentes et sans état (stateless). Pour les pipelines combinant traitement par lots (batch) et en flux (stream) sans code existant, Dataflow fournit un traitement unifié avec autoscaling.

Compromis dans le choix de la plateforme :

Contrôle opérationnel : Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabilité : basé sur les conteneurs (GKE/Cloud Run/App Engine Flex) > images de VM > fonctions et App Engine Standard.
Latence : Cloud Run avec des instances minimales ou GKE pour une faible latence de queue (tail latency) ; évitez les démarrages à froid pour les charges de travail interactives.
Mise à l’échelle : Cloud Functions/Run se mettent à l’échelle le plus rapidement ; HPA de GKE plus cluster autoscaler ; les MIG nécessitent une phase de préchauffage (warm-up) et des vérifications de santé.
Coût : paiement à l’usage (pay-per-use) du serverless pour les charges de travail sporadiques/à faible état stable ; GKE/VM avec des remises sur engagement d’utilisation pour les services stables à haut débit ; instances préemptives/Spot pour le traitement par lots (batch).

Identité et configuration :

Chaque service doit utiliser un compte de service dédié avec le principe du moindre privilège. Pour Cloud Run et Functions, définissez explicitement le compte de service d’exécution.
Stockez les secrets dans Secret Manager et liez l’accès via IAM ; injectez-les via des variables d’environnement ou des montages de volume.

Patrons d’architecture, livraison et opérations

Décomposition des services et délimitations :

Monolithe : déploiement et transactions les plus simples, mais limite la mise à l’échelle indépendante et le contrôle du rayon d’impact (blast radius) ; peut masquer des problèmes de performance profonds dans les chaînes d’appels.
Monolithe modulaire : modules internes clairs, processus partagé ; une bonne étape intermédiaire qui impose des interfaces sans les inconvénients de la distribution.
Microservices : déployabilité et mise à l’échelle indépendantes ; introduit une latence réseau, des transactions distribuées et des défis de cohérence. Définir des contextes délimités (bounded contexts) clairs et la propriété des données ; éviter les bases de données partagées pour prévenir le couplage.

Patrons de modernisation :

Étranglement progressif (Strangler-fig) : router de manière incrémentielle une partie du trafic vers de nouveaux composants, retirer progressivement les points de terminaison hérités (legacy).
Lift and shift : conteneuriser ou migrer sur VM d’abord pour stabiliser, puis refactoriser.
Couche anti-corruption/façade : isoler les contrats hérités tout en construisant de nouveaux services.
Prioriser d’abord les domaines à fort changement et à forte friction pour maximiser la valeur métier et réduire les risques.

Livraison et déploiements progressifs :

Le CI/CD avec des tests automatisés et des environnements étagés réduit les restaurations (rollbacks). Ajouter l’analyse canary, les bilans d’erreurs (error budgets) et la livraison progressive.
Bleu-vert (Blue-green) minimise le temps d’arrêt et simplifie la restauration au prix d’une double capacité.
Répartition du trafic (Traffic splitting) : Cloud Run/App Engine prennent en charge le routage basé sur un pourcentage entre les révisions/versions ; tester en conditions de trafic réel avec des bilans d’erreurs SLO stricts.

Équilibrage de charge et santé :

Utiliser un équilibreur de charge global L7 pour HTTP et un proxy TCP pour les protocoles non-HTTP ; des équilibreurs de charge internes pour les services privés. Configurer l’affinité de session uniquement lorsque c’est nécessaire et externaliser l’état de session.
Les vérifications de santé (health checks) doivent refléter la disponibilité de l’application (par ex., la santé des dépendances) ; un simple 200 OK qui masque une défaillance de la base de données peut provoquer une mauvaise orientation du trafic.

Observabilité et gouvernance :

Instrumenter les traces pour l’attribution de la latence de bout en bout entre les services ; activer la journalisation des ID de requête pour corréler les journaux et les traces.
Exporter les journaux/métriques/pistes d’audit vers BigQuery ou Cloud Storage pour les besoins de rétention et d’audit ; sécuriser l’accès via des vues et IAM.
Pour les journaux de VM, installer l’Ops Agent ; définir la rétention et les récepteurs (sinks) pour contrôler les coûts et la conformité.

Sécurisation de la chaîne d’approvisionnement logicielle :

Utiliser Artifact Registry avec l’analyse des vulnérabilités ; garder les images minimales. Optimiser les Dockerfiles : préférer les bases légères (slim), installer les dépendances en premier, puis copier la source pour tirer parti du cache de build.

Réseau et segmentation :

Appliquer un accès à plusieurs niveaux via les tags et les règles de pare-feu VPC pour n’autoriser que les flux attendus (par ex., web → API → BDD). Refuser l’accès direct web → BDD.

Capacité, performance et calcul spécialisé

Concevoir pour une demande variable :

GCE : mettre à l’échelle automatiquement les MIG en fonction d’indicateurs précurseurs (longueur de la file d’attente) pour anticiper la saturation du CPU ; ajouter une limitation du débit des requêtes et une contre-pression pour protéger les services en aval.
GKE : combiner le HPA basé sur les requêtes par seconde ou des métriques personnalisées et l’autoscaler de cluster ; provisionner un petit tampon pour éviter la latence de mise à l’échelle.
Sans serveur (Serverless) : ajuster la simultanéité et le nombre minimal d’instances pour équilibrer le coût et la latence ; utiliser un déploiement régional pour une latence proche de l’utilisateur.

Résilience et tests :

Exécuter une charge synthétique pour valider la mise à l’échelle automatique et les SLO ; inclure des tests de chaos (par ex., arrêter des instances/pods de manière aléatoire) pour s’assurer que le système maintient sa disponibilité pendant les pannes et les mises à niveau.
Configurer des PodDisruptionBudgets et des hooks d’arrêt progressif (graceful termination) pour drainer les connexions avant l’arrêt du pod/de la VM.

Sélection des performances et du stockage :