Google PCD: Calcul, conteneurs et plateformes d'exécution Serverless — 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

Google Cloud propose plusieurs plateformes d’exécution couvrant le serverless, les conteneurs et les machines virtuelles. Le choix de la bonne plateforme dépend des caractéristiques de la charge de travail, telles que les schémas de requêtes, la gestion de l’état, la discipline de build et de déploiement, le modèle opérationnel et les contraintes réseau. Cette section aborde les principes de conception, les modes de défaillance et les compromis pour Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) et Compute Engine, ainsi que les services de support pour les images, l’identité, le réseau, la configuration et les opérations.

Runtimes Serverless : Cloud Run, App Engine, Cloud Functions

Cloud Run

• Modèle : Conteneurs entièrement gérés avec traitement des requêtes HTTP ou Jobs conteneurisés qui s’exécutent jusqu’à leur terme.
• Révisions et trafic : Chaque déploiement crée une révision immuable. La répartition du trafic en pourcentage entre les révisions permet des déploiements de type canary et bleu-vert avec une restauration instantanée. Exemple :

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Simultanéité et mise à l’échelle : La simultanéité par défaut est de 80 ; réglez-la sur 1 pour le code limité par le CPU ou non thread-safe. Une simultanéité plus élevée réduit l’amplification des démarrages à froid et le coût, mais peut augmenter la latence de queue si le CPU/la mémoire par requête est insuffisant. Cloud Run effectue une mise à l’échelle à zéro et vers le haut en fonction du taux de requêtes entrantes ; contrôlez avec des instances min/max pour réduire les démarrages à froid et limiter les coûts.
• Allocation du CPU : Choisissez « CPU toujours alloué » pour les tâches en arrière-plan entre les requêtes, au prix d’une facturation supplémentaire ; sinon, le CPU n’est alloué que pendant le traitement des requêtes.
• Jobs : Les Jobs Cloud Run exécutent N tâches parallèles jusqu’à leur terme avec un nombre maximal de tentatives par tâche et des délais d’attente globaux ; adaptés aux traitements ETL, par lots et en fan-out. Les modes de défaillance incluent le hot-spotting des backends lorsque de nombreuses tâches ciblent la même dépendance ; ajoutez une limitation de débit et des tentatives avec un backoff.
• Réseau : Public, authentifié via IAM, ou privé derrière un VPC via Serverless VPC Access et Private Service Connect.

App Engine

• Environnements :
  • Standard : Sandboxé, mise à l’échelle rapide, runtimes fixes par langage ; faible latence de démarrage à froid avec mise à l’échelle automatique ; système de fichiers restreint, délais d’attente des requêtes et limites de taille des requêtes entrantes. Utilisez les URL signées de Cloud Storage pour les téléversements volumineux.
  • Flexible : Basé sur Docker, capacités similaires à une VM, runtimes personnalisés, montée en charge plus lente que le Standard, prend en charge les threads d’arrière-plan et l’écriture sur le disque local.
• Services et versions : Un service (microservice) peut héberger plusieurs versions ; acheminez le trafic par pourcentage entre les versions, de manière similaire à Cloud Run. Utilisez dispatch.yaml pour acheminer des chemins ou des hôtes spécifiques vers des services pour un routage simple et centralisé sans load balancer externe.
• Mise à l’échelle : Manuelle, de base ou automatique en Standard ; mise à l’échelle basée sur le nombre de VM en Flexible. Compromis : un autoscaling agressif améliore la réactivité mais peut augmenter les coûts et la contention sur les backends.
• Pièges courants : Une mise à l’échelle d’instances non limitée et sans quotas peut submerger les systèmes en aval ; appliquez des quotas et des disjoncteurs (circuit breakers).

Cloud Functions

• Gestionnaires événementiels : Déclenchés par des événements HTTP, Pub/Sub, Cloud Storage ou Eventarc. Utilisez la 2e génération pour tirer parti du modèle d’exécution de Cloud Run, du contrôle de sortie VPC et de la simultanéité ; la 1re génération traite une seule requête à la fois.
• Tentatives et idempotence : Les fonctions d’arrière-plan peuvent être réessayées en cas d’échec ; concevez des gestionnaires idempotents et utilisez des clés de déduplication pour éviter le double traitement. Les déclencheurs HTTP ne sont pas réessayés par la plateforme ; implémentez des tentatives côté client avec un backoff exponentiel.
• Configuration d’exécution : Variables d’environnement, intégration avec Secret Manager, et configuration de la simultanéité/du nombre maximal d’instances par fonction. Définissez des délais d’attente pour maîtriser les coûts excessifs. Méfiez-vous des longs démarrages à froid avec de grandes dépendances ; gardez des paquets légers.

Conteneurs sur Google Kubernetes Engine

Charges de travail

• Deployments : Pods stateless avec mises à jour progressives (rolling updates). Assurez des déploiements sûrs avec des limites de surge/unavailable :

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSets : ID réseau stables et ordonnés, et volumes persistants pour les services stateful.
• DaemonSets, Jobs, CronJobs : Agents au niveau des nœuds et charges de travail par lots.

Services et Ingress

• Types de Service :
  • ClusterIP pour un usage interne uniquement.
  • NodePort pour un accès externe simple (limité sur le plan opérationnel).
  • LoadBalancer pour l’équilibrage de charge externe/interne régional.
• Ingress : Routage HTTP(S) et terminaison TLS ; préférez l’API Gateway ou Ingress avec des contrôleurs gérés pour les politiques de niveau 7 (L7). Mode de défaillance : échec des vérifications de santé (health checks) à cause du pare-feu ; autorisez les plages d’adresses IP du load balancer vers les nœuds backend.

Autoscaling et pools de nœuds

• Horizontal Pod Autoscaler (HPA) : Met à l’échelle les pods en fonction du CPU, de la mémoire ou de métriques personnalisées ; combinez avec des Pod Disruption Budgets pour protéger la disponibilité.
• Vertical Pod Autoscaler (VPA) : Dimensionne correctement les requêtes/limites des pods ; évitez d’utiliser simultanément HPA et VPA sur la même dimension pour prévenir les boucles de rétroaction.
• Cluster Autoscaler : Ajoute/supprime des nœuds pour répondre aux demandes de ressources des pods en attente.
• Pools de nœuds : Séparez les pools par classe de charge de travail. Utilisez les taints/tolerations et les labels pour le scheduling. Mélangez des instances spot/préemptives pour les charges de travail sensibles aux coûts avec une tolérance aux interruptions. Choisissez des types de machines avec une bande passante mémoire/CPU suffisante pour les limites par pod afin d’éviter le throttling.

Santé et déploiements

• Les sondes de liveness, readiness et startup empêchent l’envoi de trafic vers des pods non prêts et redémarrent les conteneurs bloqués. Des sondes de liveness trop strictes peuvent provoquer des redémarrages en cascade ; ajustez les délais initiaux et les seuils d’échec.
• Restauration avec kubectl rollout undo. Pour un déploiement canary, utilisez plusieurs Deployments et une répartition du trafic au niveau du Service via Ingress/Gateway.

Compute Engine pour les charges de travail applicatives

Conception de VM

• Les modèles d’instance définissent le type de machine, l’image, les disques, les champs d’application du compte de service, les scripts de démarrage et les métadonnées. Gardez les images minimales ; utilisez des scripts de démarrage ou des images créées avec Packer pour un démarrage déterministe.
• Disques : Utilisez des disques persistants équilibrés ou SSD pour les applications sensibles à la latence. Partagez de grands ensembles de données en lecture seule au sein d’un groupe d’instances géré via un disque persistant en lecture seule attaché à plusieurs instances pour une faible latence et un démarrage rapide.
• Réseau : Créez des règles de pare-feu pour les vérifications d’état (health checkers) lors de l’utilisation d’équilibreurs de charge. Exemple :

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Groupes d’instances gérés (MIG)

• Autoscaling par CPU, requêtes par seconde de l’équilibreur de charge, métriques personnalisées ou planifications. Définissez des délais de récupération (cool-downs) pour éviter l’instabilité (thrashing).
• La réparation automatique (Autohealing) avec des vérifications d’état redémarre les VM défaillantes ; assurez-vous que le chemin de la vérification d’état teste la disponibilité de l’application, et pas seulement l’accessibilité du port, pour éviter de servir des erreurs 500.
• Mises à jour progressives et bleu-vert : Créez un nouveau modèle d’instance et lancez une mise à jour canary sur un sous-ensemble d’instances. Si le nombre d’erreurs augmente, effectuez un rollback vers le modèle précédent. Les vérifications de disponibilité (Uptime checks) et les alertes basées sur les SLO détectent rapidement les dégradations.

Journalisation et surveillance

• Installez des agents pour collecter les journaux d’application sans modifier le code ; envoyez-les à Cloud Logging et alertez via Cloud Monitoring. Utilisez Debug Logpoints pour des diagnostics en direct avec une perturbation minimale.

Build, Identité, Réseau, Secrets et Opérations

Artifact Registry et images

• Utilisez Artifact Registry pour les images de conteneurs et les artefacts de langage. Activez l’analyse des vulnérabilités et la génération de provenance. Gardez les images de petite taille :
  • Builds multi-étapes pour séparer la construction (build) et l’exécution (runtime).
  • Évitez les outils de développement dans l’image finale ; épinglez les versions de l’OS et des paquets. Exemple :

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Promotion : Taguez les images de manière immuable (par ex., app:1.3.7, app:prod-20240901) et promouvez-les en les retaguant dans Artifact Registry ; évitez le tag mutable latest en production. Contrôlez les promotions avec les résultats des tests d’intégration et canary.

Identité d’exécution et moindre privilège

• Assignez un compte de service dédié par charge de travail (workload) avec les rôles IAM minimaux requis. Évitez les rôles larges tels que Éditeur (Editor). Dans GKE, mappez les ServiceAccounts Kubernetes aux comptes de service Google via Workload Identity. Pour le serverless, définissez explicitement le compte de service d’exécution et supprimez les portées (scopes) du jeton par défaut.

Connecteurs VPC et réseau de services

• Les connecteurs Serverless VPC Access acheminent le trafic de sortie (egress) de Cloud Run, Cloud Functions et App Engine vers un VPC. Choisissez le mode de sortie :
  • Plages privées uniquement (Private ranges only) pour atteindre les services RFC1918 et connectés au VPC, tandis que le trafic de sortie public passe directement.
  • Tout le trafic via le connecteur plus Cloud NAT pour des adresses IP de sortie déterministes et des politiques de sortie restreintes.
• Dépendances privées : Préférez l’IP privée pour Cloud SQL et Private Service Connect pour les API Google ou les services partenaires. Assurez-vous que les connecteurs correspondent à la région et sont dimensionnés pour le débit ; surveillez le CPU du connecteur pour éviter la limitation (throttling).

Configuration, secrets et vérifications de santé (health checks)

• Utilisez des variables d’environnement pour la configuration non secrète. Stockez les secrets dans Secret Manager et montez-les ou injectez-les à l’exécution ; effectuez une rotation régulière des clés. Dans GKE, utilisez les Secrets et le pilote CSI pour Secret Manager. Dans App Engine et Cloud Run, accordez au compte de service l’accès à des secrets spécifiques.
• Vérifications de santé (Health checks) :
  • Cloud Run : l’instance redémarre en cas de crash ; utilisez des vérifications au niveau de la requête et des SLI de latence.
  • App Engine : vérifications de santé intégrées ; personnalisez les sondes de liveness/readiness pour l’environnement Flexible.
  • GKE : configurez les sondes de liveness/readiness/startup.
  • Compute Engine derrière des LBs : utilisez des vérifications de santé HTTP(S) avec des points de terminaison (endpoints) spécifiques à l’application.

Dépannage, restauration (rollback) et modèles de déploiement

• Déploiements blue-green et canary avec répartition du trafic (traffic splitting) sur Cloud Run et App Engine ; dans GKE, utilisez des déploiements (Deployments) parallèles ou des contrôleurs de livraison progressive ; dans les MIGs, utilisez des sous-ensembles canary d’instances. Définissez toujours des critères d’abandon basés sur le budget d’erreur SLO et la latence.
• Modes de défaillance courants :
  • Effets de troupeau (Thundering herds) après une mise à l’échelle à zéro (scale-to-zero) ou de grands déploiements ; atténuez avec des instances minimales, des préchauffages (warmups) et une limitation de débit (rate limiting).
  • Dépassement des quotas de backend ou des limites de connexion ; appliquez un backoff exponentiel et des disjoncteurs (circuit breakers).
  • Démarrages à froid (Cold starts) dus à de grandes images ou dépendances ; affinez les images et pré-initialisez les clients.

Scénario de Problème Pratique

Acme Retail prévoit de migrer une API de redimensionnement d’images depuis des VM autogérées vers une plateforme évolutive et rentable offrant des réponses à faible latence, un accès privé à un bucket Cloud Storage régional et des déploiements canary sécurisés.

Approche

1. Empaquetez le service dans une petite image de conteneur et publiez-la sur Artifact Registry.

• Justification : Un build Docker multi-étapes et affiné minimise les démarrages à froid et le transfert réseau. Artifact Registry centralise les analyses et les flux de travail de promotion.

2. Déployez l’API sur Cloud Run avec un minimum de 2 instances (min instances), une simultanéité (concurrency) de 40, et l’option CPU toujours alloué (CPU always allocated) désactivée.

• Justification : Cloud Run fournit une mise à l’échelle horizontale instantanée et du HTTPS géré. Un petit pool d’instances minimales réduit la latence de démarrage à froid pendant les pics diurnes. Une simultanéité de 40 équilibre le coût et la latence de queue pour les transformations d’images liées aux I/O. La désactivation du CPU toujours alloué évite de payer pour le calcul inactif entre les requêtes.

3. Créez un connecteur Serverless VPC Access et réglez la sortie (egress) sur “plages privées uniquement” ; activez l’accès privé à Google (Private Google Access) dans le sous-réseau et configurez un point de terminaison VPC-SC ou Private Service Connect pour Cloud Storage si nécessaire.

• Justification : L’API doit récupérer et écrire des images en privé sans sortie publique. Le mode “plages privées” garantit que seul le trafic VPC passe par le connecteur, gardant les appels publics directs et efficaces. L’accès privé à Google ou Private Service Connect fournit un accès privé aux API Google depuis le VPC.

4. Accordez à un compte de service d’exécution dédié un accès de moindre privilège au bucket Cloud Storage cible et aux secrets requis.

• Justification : Le principe du moindre privilège limite le rayon de l’impact (blast radius). L’identité d’exécution reçoit les rôles storage.objectViewer et storage.objectAdmin sur le bucket spécifique, et le rôle d’accesseur (accessor) sur les secrets Secret Manager nécessaires.

5. Stockez les clés d’API et la configuration par environnement dans Secret Manager et les variables d’environnement ; injectez les secrets à l’exécution.

• Justification : Rotation centralisée des secrets et accès auditable. La configuration non secrète via les variables d’environnement soutient les pratiques 12-factor.

6. Implémentez un backoff exponentiel et des écritures idempotentes pour gérer les erreurs 429/5xx de Cloud Storage.

• Justification : Lors de pics de trafic ou d’événements régionaux, des erreurs transitoires peuvent se produire. Le backoff avec gigue (jitter) protège à la fois l’API et Cloud Storage des tempêtes de nouvelles tentatives (retry storms).

7. Configurez une révision canary et répartissez 10 % du trafic vers elle ; surveillez le taux d’erreur, la latence P95 et la saturation.

• Justification : La répartition du trafic sur Cloud Run permet un déploiement progressif sécurisé. Les moniteurs basés sur les SLO fournissent des déclencheurs de restauration automatique si les budgets d’erreur sont consommés trop rapidement.

8. Ajoutez un point de terminaison de santé HTTP qui sollicite les dépendances en aval ; définissez des alertes sur les vérifications de disponibilité (uptime checks) de Cloud Monitoring et les métriques basées sur les journaux.

• Justification : La santé de bout en bout détecte tôt les défaillances des dépendances. Les vérifications de disponibilité fournissent une perspective externe ; les métriques basées sur les journaux capturent les modèles de défaillance spécifiques à l’application.

9. Établissez des limites d’autoscaling et des budgets ; définissez un nombre maximal d’instances (max instances) pour plafonner les dépenses, et définissez la gestion des erreurs 429 en cas de surcharge.

• Justification : Limiter la mise à l’échelle prévient les coûts excessifs et l’épuisement du backend. Un comportement de surcharge maîtrisé maintient la stabilité du service.

10. Documentez la restauration (rollback) : rebasculez 100 % du trafic vers la révision Cloud Run précédente avec une seule commande.

• Justification : Les révisions immuables rendent la restauration sûre et rapide, minimisant le temps moyen de rétablissement (MTTR).

← Architecture d’applications Cloud-Native et sélection de services · Tous les domaines · Conception d’API →

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

Parcourir Google →