Google PCD: Architecture d'applications Cloud-Native et sélection de services — 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.

Aperçu

L’architecture d’applications cloud-natives sur Google Cloud se concentre sur la création de services sans état et résilients qui se mettent à l’échelle horizontalement, minimisent la charge opérationnelle et adoptent les services gérés lorsque cela est approprié. Une sélection efficace des services nécessite de comprendre les compromis entre le contrôle, la portabilité, la performance, le coût et la responsabilité opérationnelle. Cette section présente des principes et des modèles qui vous aident à concevoir, moderniser et exploiter des applications pour des utilisateurs mondiaux avec une fiabilité prévisible.

Principes du cloud-natif et choix d’architecture

Conception “Twelve-Factor” et sans état
- Base de code, dépendances et build-release-run : Épinglez les dépendances exactes, créez des artefacts immuables et séparez la phase de build de celle de release. Les images de conteneur et les pipelines Cloud Build garantissent des déploiements reproductibles.
- Configuration dans l’environnement : Externalisez la configuration à l’aide de variables d’environnement, de Secret Manager, de Kubernetes Secrets ou des métadonnées d’instance pour Compute Engine. N’intégrez pas d’identifiants ou de paramètres spécifiques au déploiement dans les images. Pour les groupes d’instances gérés Compute Engine, utilisez les métadonnées du modèle d’instance pour les valeurs spécifiques au déploiement.
- Services de support : Traitez les bases de données, les files d’attente et les caches comme des ressources attachées. Préférez les services gérés (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub) pour réduire la charge opérationnelle.
- Processus sans état : Mettez à l’échelle en ajoutant des instances ; stockez l’état de session de manière externe (Memorystore for Redis, Firestore ou Spanner). Écrivez les journaux sur stdout/stderr ou dans des fichiers de logs collectés par l’agent Cloud Logging.
- Caractère éphémère : Un démarrage/arrêt rapide permet une mise à l’échelle rapide et des mises à jour progressives. Gérez SIGTERM pour un arrêt en douceur.
- Journaux en tant que flux d’événements : Émettez des journaux structurés ; utilisez Cloud Logging pour l’ingestion et Cloud Monitoring pour les alertes.
Compromis d’architecture
- Monolithe
  - Avantages : Développement/test simplifié, moins de frontières réseau, unité de déploiement unique.
  - Inconvénients : Livraison indépendante plus lente, contraintes de mise à l’échelle, couplage fort entre les domaines.
  - Modes de défaillance : Un chemin critique peut consommer des ressources partagées ; les régressions impactent toutes les fonctionnalités.
- Monolithe modulaire
  - Avantages : Frontières claires entre les modules internes, chemin de refactorisation vers des services, un seul déployable.
  - Inconvénients : Toujours contraint par le déploiement et la base de données monolithiques.
  - À utiliser pour les équipes qui affinent les frontières de leurs domaines avant d’extraire des services.
- Microservices
  - Avantages : Déployabilité indépendante, mise à l’échelle ciblée, autonomie des équipes, isolation des défaillances avec des cloisons (bulkheads) appropriées.
  - Inconvénients : Complexité des systèmes distribués, cohérence, observabilité et surcharge opérationnelle.
  - Modes de défaillance : Défaillances en cascade via des appels synchrones ; dérive de schéma ; réseaux bavards.
- Orienté événements
  - Avantages : Couplage lâche, résilience asynchrone, mise en tampon naturelle, auditabilité via les journaux/flux.
  - Inconvénients : Complexité du débogage, cohérence à terme (eventual consistency), l’ordonnancement et la sémantique de traitement unique (exactly-once) sont difficiles.
  - Pub/Sub fournit une livraison “au moins une fois” (at-least-once) ; concevez des consommateurs idempotents.
- Serverless (Cloud Run, Cloud Functions, App Engine)
  - Avantages : Opérations minimales, mise à l’échelle jusqu’à zéro, autoscaling par requête, sécurité et télémétrie intégrées.
  - Inconvénients : Limites de temps d’exécution et de simultanéité, démarrages à froid, contraintes spécifiques à la plateforme.
  - À utiliser pour les charges de travail en rafale, les backends mobiles/web et le traitement d’événements.

Modèles de communication et sélection de services

Appels synchrones vs asynchrones
- Synchrone
  - À utiliser pour les API de type requête/réponse nécessitant des résultats immédiats.
  - Protocoles : gRPC (HTTP/2, streaming, Protobuf compact ; excellent pour la bande passante mobile et les contrats forts), HTTP/JSON (large compatibilité ; débogage plus simple).
  - Risques : Couplage fort et amplification de la latence ; utilisez des délais d’attente (timeouts), des nouvelles tentatives avec gigue (jitter) et des disjoncteurs (circuit breakers).
- Asynchrone
  - Utilisez Pub/Sub ou Cloud Tasks lorsque le travail peut être différé ou traité par lots.
  - Avantages : Lisse les pics de charge, isole les défaillances, améliore la latence perçue par l’utilisateur grâce à un achèvement ultérieur.
  - Risques : Nécessite l’idempotence et des actions de compensation ; la visibilité sur le travail en cours doit être mise en place.
Critères de sélection de services sur Google Cloud
- Contrôle et portabilité
  - Compute Engine : Contrôle total des VM et images personnalisées ; charge opérationnelle plus élevée.
  - GKE : Conteneurs portables et options de maillage de services ; autoscaling robuste ; responsabilité partagée.
  - Cloud Run : Haute portabilité pour les conteneurs avec un minimum d’opérations ; mise à l’échelle jusqu’à zéro ; orienté requête.
  - App Engine : PaaS “opinionated” (à fortes conventions) avec routage et mise à l’échelle intégrés ; chemin le plus rapide pour certains langages.
- Mise à l’échelle et latence
  - Global HTTP(S) Load Balancing avec Cloud CDN pour l’accélération en périphérie (edge).
  - Banques de données :
    - Cloud Spanner : Cohérence globale, mise à l’échelle horizontale, disponibilité multirégionale de 99,999 %.
    - Cloud SQL : Base de données relationnelle gérée, régionale, réplicas en lecture y compris interrégionaux.
    - Firestore : Base de données de documents avec disponibilité mondiale en multirégion, forte cohérence pour les documents uniques.
    - Cloud Bigtable : Faible latence, mise à l’échelle massive pour les cas d’usage à colonnes larges.
    - Memorystore : Cache à faible latence pour les chemins critiques et les sessions.
- Responsabilité opérationnelle
  - Préférez les services gérés pour les préoccupations essentielles (disponibilité, application de correctifs, sauvegardes, mises à niveau).
  - L’autogestion offre de la flexibilité mais ajoute de la charge opérationnelle et une surface de défaillance (par ex., Kafka auto-hébergé vs Pub/Sub).
- Mouvement et intégration des données
  - Utilisez la connectivité native au VPC, Private Service Connect et l’internal HTTP(S) Load Balancing pour un accès privé à faible latence.
  - Découverte de services : Noms de Service Kubernetes au sein d’un cluster ; DNS interne de Compute Engine pour les VM.

Exemple de Service Kubernetes (découverte de nom au sein du cluster) :

undefined

Frontières, compatibilité et modèles de fiabilité

Frontières de domaine et propriété (ownership)
- Utiliser la conception pilotée par le domaine (domain-driven design) pour définir des contextes délimités (bounded contexts). Chaque service possède ses propres données et publie des API/événements en tant que contrats.
- Éviter les bases de données partagées entre les services ; utiliser des interfaces bien définies et la propagation d’événements.
- La propriété implique l’astreinte, les SLO, la cadence de livraison et la responsabilité budgétaire pour chaque service.
Contrats d’API et rétrocompatibilité
- Versionner les API de manière explicite (par ex., v1 dans le chemin ou l’en-tête). Préférer les changements additifs ; éviter de casser des champs ou des comportements.
- Utiliser des tests de contrat pilotés par le consommateur (consumer-driven contract tests) et des déploiements canary. Déprécier avec des échéanciers et de la télémétrie sur l’utilisation.
- Pour les clients mobiles, s’attendre à des versions à longue traîne ; maintenir plusieurs versions d’API simultanément.
Isolation des pannes et résilience
- Bulkheads (cloisons) : Isoler les ressources par service ou par classe de priorité (pools de nœuds, groupes d’instances, quotas distincts). Empêcher qu’une fonctionnalité en mode « best-effort » n’épuise les ressources des chemins critiques.
- Disjoncteurs (Circuit breakers) : Se déclenchent après des échecs consécutifs vers une dépendance ; délestent la charge et permettent une fenêtre de récupération. À implémenter via un maillage de services (par ex., Envoy), des politiques de passerelle ou des bibliothèques.
- Délais d’attente (timeouts) et nouvelles tentatives (retries) : Utiliser un backoff exponentiel tronqué avec gigue (jitter) ; s’assurer que les gestionnaires sont idempotents.
- Dégradation gracieuse : Omettre les composants d’interface utilisateur non critiques en cas de timeout ; servir des données mises en cache ou approximatives plutôt que des erreurs.
- Vérifications de santé (health checks) et sondes de disponibilité (readiness probes) : N’acheminer le trafic que vers les instances prêtes ; utiliser les sondes de vivacité (liveness) pour l’auto-réparation.

Exemple de backoff exponentiel tronqué (HTTP 429) :

undefined

Considérations globales et opérationnelles

Modèles multirégionaux pour les utilisateurs mondiaux
- Frontend global : Utiliser un Global External HTTP(S) Load Balancing avec une adresse IP anycast et Cloud CDN pour le contenu statique. Configurer la mise en cache négative et la validation pour réduire la charge sur l’origine.
- Plan de données :
  - Pour une disponibilité de base de données à cinq 9 (99,999 %) et une latence de lecture mondiale minimisée, utiliser une instance Cloud Spanner multirégionale (par ex., nam-asia-eur1) et provisionner suffisamment de nœuds pour le calcul et le quorum (minimum trois nœuds pour la production).
  - Pour les modèles à forte charge de lecture sans cohérence globale stricte, envisager une région primaire avec des réplicas en lecture interrégionaux ; accepter une latence d’écriture plus élevée entre les continents.
- Plan applicatif :
  - Déployer des services sans état (stateless) dans plusieurs régions avec autoscaling (GKE ou Cloud Run). Utiliser des services de backend et des groupes de points de terminaison réseau (NEG) par région.
  - Router par latence tout en respectant les contraintes de résidence des données et de conformité.
- Caches : Placer des caches Memorystore ou en périphérie (edge) près des utilisateurs pour absorber le trafic de lecture et protéger les origines.
Géré ou autogéré
- Utiliser Cloud Monitoring pour les métriques, Cloud Logging pour les journaux, Cloud Trace/Profiler pour la latence et les points chauds (hotspots) CPU/mémoire. Créer des règles d’alerte pour les taux d’épuisement des SLO (burn rates) et des vérifications de disponibilité (uptime checks) pour la disponibilité externe.
- Si une plateforme d’observabilité existante doit rester le système de référence (system of record), ingérer d’abord avec Cloud Logging pour des alertes à faible latence, puis exporter via des récepteurs (sinks) vers la plateforme externe.
Modernisation et migration incrémentielle
- Modèle de l’étrangleur (Strangler pattern) : Placer une passerelle (gateway) devant le monolithe ; router des points de terminaison spécifiques vers de nouveaux services. Remplacer progressivement les fonctionnalités.
- Branche par abstraction (Branch by abstraction) : Introduire une interface autour d’une dépendance et interchanger l’implémentation derrière elle (par ex., base de données ou stockage).
- Couche anti-corruption (Anti-corruption layer) : Traduire entre les modèles de données hérités (legacy) et les nouveaux contextes délimités (bounded contexts).
- Migration de données : Utiliser les écritures doubles (dual writes) avec vérification ou l’approvisionnement par événements (event sourcing) pour le remplissage a posteriori (backfill) ; planifier les basculements (cutovers) avec des contrôles de contre-pression (backpressure).
- Livraison par phases : Remplacer les fonctionnalités par étapes pour minimiser le risque métier ; mesurer continuellement les SLO.
Revues de conception et évaluation des compromis
- Sécurité : Modèle de menace, principe de moindre privilège IAM, comptes de service au lieu de clés intégrées (utiliser Application Default Credentials sur GCE/GKE/Cloud Run), CMEK si nécessaire, connectivité privée, WAF et limites de débit (rate limits), analyse des vulnérabilités et de la sécurité web.
- Fiabilité : Définir les SLO et les budgets d’erreur, plans de basculement (failover) multirégionaux, marge de capacité (headroom), exercices de chaos (chaos drills), cartographie des dépendances.
- Performance : Analyse de la latence de queue (tail latency), tests de charge en périphérie (edge) et à l’origine, réutilisation des connexions (HTTP/2, gRPC), compression, stratégie de mise en cache.
- Coût : Dimensionner correctement les ressources (right-sizing), politiques d’autoscaling, remises pour usage engagé (committed use discounts), mise à l’échelle à zéro (scale-to-zero) pour les charges de travail en rafales, sortie de données (egress) et délestage sur le CDN.
- Opérations : Guides opérationnels (runbooks), restaurations (rollbacks), livraison progressive (canary, blue/green), politique sous forme de code (policy as code), sauvegardes et tests de reprise après sinistre (DR), intégration de la réponse aux incidents.

Scénario de problème pratique

Nimbus Retail lance une plateforme e-commerce mondiale avec des images personnalisées, des objectifs de latence stricts inférieurs à 200 ms au p95 dans le monde entier, et une exigence de disponibilité de 99,999 % pour la base de données des commandes. Ils doivent également conserver leur SIEM existant tout en améliorant la vitesse d’alerte.

Établir une base de données mondiale et hautement disponible avec Cloud Spanner

Action : Créer une instance Spanner multirégionale dans nam-asia-eur1 avec au moins trois nœuds et diviser les tables en schémas entrelacés (interleaved) appropriés pour la localité.
Justification : Spanner multirégional offre une disponibilité à cinq 9 et une faible latence de lecture grâce à des réplicas sur trois continents ; trois nœuds ou plus garantissent une capacité de calcul et de quorum de réplicas suffisante.

Exemple :

undefined

Déploiement mondial du frontend et de l’API

Action : Utiliser un Global External HTTP(S) Load Balancing avec Cloud CDN pour les ressources statiques et le routage dynamique vers les backends régionaux (services GKE dans us-central1, europe-west1, asia-east1).
Justification : L’IP virtuelle (VIP) anycast minimise le RTT ; le CDN met en cache les images près des utilisateurs ; les services de backend distribuent les requêtes à la région saine la plus proche.

Services sans état (stateless) sur GKE avec découverte intra-cluster

Action : Déployer les services de redimensionnement d’images et d’API sur GKE avec l’autoscaling horizontal des pods et des services ClusterIP pour un accès intra-cluster basé sur le nom ; exposer les points de terminaison publics via un Ingress.
Justification : Les pods sans état permettent une mise à l’échelle élastique ; le service Kubernetes abstrait les adresses IP des pods et fournit un DNS stable, réduisant le couplage client.

Traitement d’images événementiel

Action : Publier les tâches de traitement d’images sur Pub/Sub ; exécuter des services Cloud Run abonnés via push pour traiter les objets stockés dans Cloud Storage. Implémenter un backoff exponentiel tronqué avec gigue (jitter) sur les erreurs GCS 429/5xx.
Justification : Pub/Sub absorbe les pics de charge et isole les défaillances ; Cloud Run se met à l’échelle par message ; le backoff réduit l’amplification des erreurs et aide les buckets à monter en charge progressivement.

Observabilité et alertes rapides

Action : Utiliser Cloud Logging et Cloud Monitoring pour ingérer les journaux et les métriques, définir des vérifications de disponibilité (uptime checks) pour les API, et créer des règles d’alerte sur les taux d’erreur et la latence. Configurer un récepteur de journaux (log sink) pour exporter vers le SIEM existant.
Justification : La télémétrie native fournit des alertes à faible latence et des vérifications de disponibilité gérées ; l’exportation préserve le SIEM centralisé sans sacrifier la vitesse d’alerte.

Configuration et secrets externalisés

Action : Stocker la configuration non secrète dans des ConfigMaps ; les secrets et les clés d’API dans Secret Manager avec Workload Identity pour GKE. Pour les tâches basées sur Compute Engine, utiliser les métadonnées d’instance pour les valeurs spécifiques au déploiement.
Justification : La configuration externalisée permet des images immuables et des paramètres spécifiques à l’environnement ; évite d’intégrer des secrets ; les métadonnées prennent en charge la variance des VM sans modification du code.

Isolation des défaillances et dégradation gracieuse

Action : Appliquer des cloisons (bulkheads) avec des pools de nœuds distincts pour les charges de travail de personnalisation en mode “best-effort” ; appliquer des budgets de requêtes et des disjoncteurs (circuit breakers) pour les services de personnalisation. Dans l’interface utilisateur, omettre les widgets non critiques en cas de timeout des dépendances.
Justification : Isoler la capacité empêche les fonctionnalités “best-effort” d’épuiser les ressources du processus de paiement ; les disjoncteurs limitent le rayon de l’impact (blast radius) ; la dégradation gracieuse préserve les parcours utilisateurs principaux.

Contrats d’API et compatibilité

Action : Définir des contrats gRPC pour les clients mobiles (v1) avec transcodage HTTP/JSON pour le web ; adopter des changements additifs et maintenir au moins deux versions pendant le déploiement mobile.
Justification : gRPC réduit la bande passante et fournit un typage fort ; le transcodage facilite l’intégration avec les navigateurs et les partenaires ; le versionnage préserve la compatibilité ascendante.

Sécurité et identité

Action : Utiliser des comptes de service Google par service avec le principe de moindre privilège IAM ; s’appuyer sur Application Default Credentials. Activer Cloud Armor pour les protections en périphérie et imposer TLS partout.
Justification : Workload Identity supprime les risques liés à la gestion des clés ; le WAF et les limites de débit atténuent les abus ; le chiffrement en transit est la norme et est obligatoire.

Livraison continue et sécurité des mises en production

Action : Mettre en œuvre des déploiements canary avec une répartition du trafic basée sur un pourcentage au niveau de l’équilibreur de charge et une restauration automatique (rollback) en cas d’alertes d’épuisement du SLO. Conserver des environnements blue/green par région.
Justification : La livraison progressive limite les risques ; le blue/green régional accélère la restauration et permet des migrations de schéma sécurisées, alignées sur les API versionnées.

Tous les domaines · Calcul →

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