Google PCD: Conception d'API, intégration et développement piloté par les événements — 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

L’intégration d’applications modernes sur Google Cloud combine des API synchrones bien conçues avec des modèles asynchrones et événementiels résilients. L’objectif est de fournir des contrats clairs, une identité forte, une gestion cohérente des erreurs et des contrôles opérationnels qui maintiennent une faible latence et une haute disponibilité, même en cas de panne, de mise à l’échelle ou de changement. Cette section couvre les choix de protocoles et d’API, les passerelles et l’authentification, la messagerie et le routage d’événements, les tâches d’arrière-plan, l’orchestration, l’identité et la confiance entre les services, les modèles de fiabilité, les webhooks sécurisés et l’évolution sûre des schémas.

Conception et gestion des API

Choisir le bon protocole :

REST : Convivial, mis en cache via HTTP, idéal pour les API publiques et partenaires. Utiliser une conception orientée ressources, des méthodes standard, les ETags et HATEOAS uniquement lorsque cela est pertinent. Compromis : contrats moins précis que Protobuf ; sur-collecte/sous-collecte potentielle de données.
gRPC : Contrats Protobuf, streaming bidirectionnel, transport binaire efficace ; bien adapté aux appels inter-services internes à faible latence. Compromis : le support par les navigateurs nécessite gRPC-Web ; l’observabilité et la compatibilité pour les clients publics peuvent être plus difficiles.
GraphQL : Requêtage flexible qui réduit les allers-retours pour les vues composites. Compromis : résolveurs complexes, risques N+1, défis de mise en cache et nuances du contrôle d’accès.

Versionnement et pagination :

Préférer les changements additifs et rétrocompatibles. Utiliser des versions majeures basées sur l’URI (ex. : /v1) et des révisions mineures via des champs et des feature flags. Déprécier avec des échéanciers clairs.
Paginer avec des curseurs stables ou un nextPageToken pour éviter les pages incohérentes en cas de modifications fréquentes ; éviter l’offset pour les grands jeux de données.

Validation et erreurs :

Utiliser OpenAPI pour les schémas de requête/réponse REST et les règles de validation Protobuf pour gRPC.
Adopter un modèle d’erreur cohérent : mapper sur les codes de statut HTTP canoniques ; pour gRPC, utiliser google.rpc.Status (code, message, détails). Inclure des raisons d’erreur interprétables par une machine et un ID de corrélation. Éviter de divulguer des détails internes.

Choix de gestion d’API :

API Gateway : Passerelle légère et gérée pour les backends OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Prend en charge l’authentification, les clés API, la validation JWT, les quotas. Bon pour les plans de contrôle serverless et simples.
Cloud Endpoints (ESPv2) : Déployé avec votre service ; prend en charge le transcodage OpenAPI ou gRPC, l’authentification, les quotas et les métriques. Bon lorsque la co-localisation du proxy avec la charge de travail est préférable.
Apigee : Gestion complète du cycle de vie des API avec des politiques avancées (prévention des pics de trafic, quotas, médiation, transformation, fournisseurs OAuth, monétisation, portail développeur). Idéal pour les écosystèmes de partenaires complexes et le contrôle nord-sud.

Authentification et quotas :

Pour les utilisateurs finaux : OAuth 2.0 ou Firebase Authentication ; pour les services : jetons d’ID signés par Google (OIDC) ou jetons de compte de service OAuth (à deux acteurs).
Appliquer les quotas et la prévention des pics de trafic près des clients (Apigee) et par consommateur (clés API ou identifiants client) pour protéger les backends.

Exemple minimal d’OpenAPI pour API Gateway avec un backend Cloud Run et OIDC :

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

Messagerie asynchrone et gestion d’événements

Principes fondamentaux de Pub/Sub :

Les sujets (topics) et les abonnements (subscriptions) découplent les publicateurs (publishers) et les consommateurs (consumers). La livraison est de type « au moins une fois » (at-least-once) ; des doublons et des changements d’ordre peuvent survenir.
Utiliser les confirmations de réception (acknowledgments) et prolonger les délais de confirmation (ack deadlines) lorsque le traitement est long ; appliquer un contrôle de flux côté client pour éviter la pression sur la mémoire.
Ordonnancement : activer l’ordonnancement des messages et fournir une clé d’ordonnancement (ordering key) pour garantir une livraison dans l’ordre par clé ; conserver un seul publicateur actif par clé lorsque c’est possible.
Lettres mortes : configurer des sujets de lettres mortes (dead-letter topics) pour contenir les messages empoisonnés (poison messages) et empêcher les tentatives de retraitement infinies ; surveiller et trier.

Créer un sujet, un abonnement et une DLQ :

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

Logique du consommateur : implémenter des gestionnaires idempotents et un dédoublonnage (ex. : par messageId ou clé d’idempotence au niveau applicatif) ; réessayer les erreurs transitoires avec un temps d’attente exponentiel (backoff) ; déplacer les messages non récupérables vers la DLQ et alerter.

Eventarc et CloudEvents :

Eventarc achemine les événements provenant des services Google Cloud, de sources personnalisées et des journaux d’audit (Audit Logs) vers Cloud Run, Cloud Functions ou GKE. Les événements utilisent l’enveloppe CloudEvents (id, source, type, subject, time).
Filtrer par attributs (type, subject, location) au niveau du déclencheur (trigger) pour réduire le bruit et les coûts. Utiliser des comptes de service dédiés pour appliquer le principe de moindre privilège.

Créer un déclencheur Eventarc pour la finalisation d’un objet Cloud Storage :

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

Compromis :

Pub/Sub est optimisé pour le mode pull et résilient pour un haut débit ; Eventarc simplifie le routage depuis des producteurs que vous ne contrôlez pas et utilise le mode push vers votre service avec des métadonnées standardisées.
Pour un ordonnancement strict ou des plafonds de coûts stricts, envisagez le partitionnement et la limitation de débit côté publicateurs ; pour une diffusion en éventail (fan-out) à très faible latence, ajustez soigneusement la concurrence des abonnés.

Orchestration, tâches d’arrière-plan et processus de longue durée

Cloud Tasks :

Files d’attente en mode push pour des appels HTTP d’arrière-plan fiables. Définir le taux d’envoi et la concurrence par file d’attente pour protéger les backends. Configurer les tentatives avec un temps d’attente exponentiel (exponential backoff) et un nombre maximal de tentatives.
Assurer l’idempotence avec un nom de tâche déterministe ou un en-tête Idempotency-Key et dédoublonner côté serveur. Répondre rapidement (2xx) et effectuer le travail lourd de manière asynchrone si nécessaire.

Créer une file d’attente avec des limites de débit et des tentatives :

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows :

Orchestre des processus métier multi-étapes via des connecteurs HTTP et Google Cloud. Modéliser des actions de compensation (modèle saga) pour les pannes partielles ; éviter les transactions distribuées.
Utiliser des délais d’attente et des politiques de relance au niveau des étapes ; persister l’état entre les tentatives pour pouvoir reprendre après des pannes. Interroger (poll) les opérations de longue durée et annuler à l’échéance.

Ébauche de compensation :

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

Recommandations opérationnelles :

Préférer Cloud Tasks pour les tâches d’arrière-plan HTTP de type « fire-and-forget » avec un contrôle précis du débit vers un seul service. Utiliser Pub/Sub pour la diffusion en éventail (fan-out) et les consommateurs multiples. Utiliser Workflows lorsque vous devez coordonner plusieurs appels avec une logique de branchement et de compensation.

Identité, fiabilité et intégrations

Identité de service à service et propagation de jetons :

Les charges de travail (workloads) Cloud Run/Functions/Compute Engine/GKE doivent utiliser des comptes de service avec le principe de moindre privilège. Sur GKE, utilisez Workload Identity pour éviter les identifiants au niveau du nœud.
Pour les appels de Cloud Run à Cloud Run, appelez avec un jeton d’ID (ID token) dont l’audience correspond à l’URL cible. Ne propagez l’identité que lorsque le service en aval doit agir au nom de l’appelant ; sinon, utilisez le compte de service de l’appelé.

Récupérer un jeton d’ID dans Cloud Run :

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

Dépendances synchrones et résilience :

Définissez des délais d’attente (timeouts) client inférieurs aux délais d’attente en amont ; prévoyez un budget par saut (hop). Ne réessayez que les opérations idempotentes avec un backoff exponentiel tronqué et du jitter. Évitez les tempêtes de tentatives (retry storms) en limitant le temps total de nouvelles tentatives.
Utilisez des disjoncteurs (circuit breakers) pour échouer rapidement lorsqu’un service en amont est défaillant ; dans GKE/Apigee/Envoy, vous pouvez configurer le nombre maximal de requêtes en attente, l’éjection en cas d’échec et les sondes de santé (health probes). Fournissez des solutions de repli judicieuses ou dégradez le service progressivement (graceful degradation).
Associez les erreurs transitoires (429, 408, 500–503) à un comportement de nouvelle tentative ; traitez les erreurs 4xx (autres que 408/429) comme non réessayables.

Webhooks et intégrations tierces :

Vérifiez les requêtes entrantes à l’aide d’un en-tête de signature HMAC avec un secret partagé ou un JWT signé ; pour une assurance plus élevée, utilisez mTLS. Stockez les secrets dans Secret Manager et effectuez une rotation régulière.
Acquittez rapidement ; mettez en file d’attente dans Cloud Tasks ou publiez sur Pub/Sub pour découpler les traitements lourds. Limitez le débit (rate-limit) des adresses IP ou des clés entrantes pour protéger les backends.
Webhooks sortants : incluez une Idempotency-Key pour permettre des nouvelles tentatives sûres et vérifiez les certificats TLS et les noms d’hôte distants.

Évolution des schémas et compatibilité :

REST/JSON : les champs additifs sont sûrs ; ne réutilisez jamais ou ne modifiez jamais le type/la signification des champs existants. Marquez les champs comme obsolètes (deprecated) et continuez à les servir pendant une certaine période.
Protobuf/gRPC : ne réutilisez jamais les numéros de champ ; utilisez des balises réservées ; préférez les champs optionnels ; les sémantiques de valeur par défaut et de présence sont importantes pour la compatibilité.
Événements : incluez une dataVersion et maintenez les attributs CloudEvents stables ; réservez de l’espace pour les extensions. Avec Pub/Sub, envisagez d’utiliser Pub/Sub Schema (Avro/Protobuf) pour valider au moment de la publication.
Tests : utilisez des tests de contrat pilotés par le consommateur (consumer-driven contract tests), des émulateurs (Pub/Sub, Datastore/Firestore) ou des projets isolés, et des déploiements canary. Exécutez des tests d’intégration en CI à l’aide d’environnements éphémères et de quotas réalistes pour révéler les défaillances latentes.

Sécurité et quotas à travers la pile (stack) :

Appliquez l’authentification en périphérie (edge) (API Gateway/Apigee/Endpoints) et au niveau du service. Appliquez des quotas par consommateur et une protection contre les pics de trafic (spike arrest). Surveillez les pics de 401/403 et les taux de 429 pour ajuster le backoff client et les quotas.
Journalisez les ID de requête à travers les composants et propagez les en-têtes de traçage (Traceparent ou X-Cloud-Trace-Context) pour une observabilité de bout en bout.

Scénario de problème pratique

AcmeRetail construit un service de click-and-collect sur Google Cloud. Une application web React appelle une API publique pour passer des commandes ; les services backend doivent réserver l’inventaire, effectuer les paiements et notifier les magasins. L’équipe a besoin d’API à faible latence, de traitements en arrière-plan fiables, de mises à jour événementielles et d’une restauration (rollback) sûre en cas d’échecs partiels.

Approche :

Exposer une API REST publique via API Gateway devant un service de commandes sur Cloud Run.

Justification : REST avec JSON est simple pour les navigateurs ; API Gateway valide les JWT de Firebase Auth, applique les clés d’API et les quotas par client, et assure la terminaison en périphérie (edge). Cloud Run s’adapte automatiquement (auto-scales) aux pics de trafic.

Implémenter les appels de service à service avec gRPC pour les chemins critiques internes (commandes vers inventaire, tarification).

Justification : gRPC réduit la surcharge de sérialisation et fournit des contrats stricts. Utiliser Workload Identity (GKE) ou des comptes de service (Cloud Run) et OIDC entre les services. Les délais d’attente (timeouts) sont fixés à 300 ms avec deux nouvelles tentatives et du jitter pour les lectures idempotentes.

Utiliser Workflows pour orchestrer la saga de commande : débiter le paiement, réserver l’inventaire, créer une tâche de retrait ; compenser en cas d’échec.

Justification : L’orchestration centralisée gère les étapes de longue durée et les compensations. Si la réservation échoue, Workflows déclenche un remboursement et renvoie un code 409 au client.

Publier des événements de domaine (domain events) sur les sujets Pub/Sub orders et inventory pour les consommateurs en aval (analytique, notifications aux magasins).

Justification : Distribution en fan-out sans couplage fort. Les abonnés implémentent l’idempotence basée sur orderId. Les abonnements ont des sujets de lettres mortes (dead-letter topics) avec max-delivery-attempts=10, et des alertes se déclenchent sur la croissance de la DLQ.

Déclencher des notifications aux magasins via Eventarc vers un service de notification sur Cloud Run lors de changements pertinents dans Cloud Storage et Firestore.

Justification : Eventarc ne route que les événements nécessaires en utilisant des filtres d’attributs ; CloudEvents assure la cohérence des métadonnées. Le service de notification publie vers des fournisseurs tiers de SMS/Email en utilisant Cloud Tasks pour contrôler le débit et les nouvelles tentatives.

Gérer les webhooks du fournisseur de paiement avec un point de terminaison (endpoint) Cloud Run dédié, précédé par API Gateway, en vérifiant les signatures HMAC et en utilisant Cloud Tasks pour le traitement.

Justification : Un acquittement rapide avec un code 200 réduit les nouvelles tentatives du fournisseur ; Tasks assure les nouvelles tentatives avec backoff. Les secrets sont stockés dans Secret Manager ; les corps de requête sont validés par rapport au schéma OpenAPI.

Appliquer des modèles de fiabilité : disjoncteurs (circuit breakers) au niveau d’Apigee ou d’Envoy pour les appels sortants vers le fournisseur de paiement ; délais d’attente client définis en dessous des SLA du fournisseur ; nouvelles tentatives avec backoff exponentiel tronqué pour les erreurs 429/5xx.

Justification : Prévient les défaillances en cascade et les tempêtes de tentatives, respecte les limites des tiers et transforme une surcharge transitoire en une dégradation progressive (graceful degradation).

Adopter des contrôles d’évolution de schéma : Protobuf pour le gRPC interne avec des champs réservés ; les réponses REST utilisent des changements JSON additifs ; Pub/Sub utilise la validation de schéma Protobuf au moment de la publication.

Justification : Maintient la compatibilité des consommateurs. Les tests de contrat et d’intégration s’exécutent dans Cloud Build à chaque fusion (merge) ; les déploiements canary valident le trafic réel en toute sécurité.

Observer et opérer : propager les en-têtes de traçage entre API Gateway et les services ; exporter les métriques de Cloud Logging pour les taux d’erreur et la taille de la DLQ ; alerter sur l’épuisement du budget d’erreur (SLO burn) et les anomalies 429/5xx.

Justification : Détection rapide des régressions, des problèmes de quota ou des incidents de fournisseur ; les SRE peuvent ajuster rapidement les quotas et les politiques de backoff.

← Calcul · Tous les domaines · Données d’application →

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