Google PCD: Performance, scalabilité et ingénierie de la résilience — 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’ingénierie de la performance, de la scalabilité et de la résilience sur Google Cloud vise à maintenir un service à faible latence et rentable sous une charge variable, tout en tolérant les pannes sans enfreindre les SLO. La conception doit aligner les signaux d’autoscaling sur les caractéristiques de la charge de travail, placer les données et les ressources de calcul pour minimiser la latence de queue, et mettre en œuvre des contrôles de surcharge, des tentatives (retries) et des mécanismes de basculement (failover) pour éviter les défaillances en cascade. Cette section détaille les modèles, les contrôles et les compromis importants pour les développeurs d’applications au niveau des couches de calcul (compute), de réseau et de données.

Scalabilité et répartition de la charge

Scalabilité horizontale ou verticale

• La scalabilité horizontale ajoute des instances ou des pods pour augmenter la capacité et la résilience. À privilégier pour les services sans état (stateless) et lorsque vous avez besoin d’une élasticité rapide. Utilisez les groupes d’instances gérés (Managed Instance Groups - MIGs), les révisions Cloud Run ou les déploiements GKE.
• La scalabilité verticale augmente la taille de la machine. Utile pour les charges de travail monothread ou limitées par la mémoire, ou pour réduire la coordination entre les nœuds, mais elle offre une marge de manœuvre limitée et des temps de redémarrage plus longs.
• Simultanéité (Concurrency) : Ajustez la simultanéité des requêtes pour correspondre aux profils limités par le CPU (CPU-bound) ou par les E/S (I/O-bound). Cloud Run prend en charge la simultanéité par révision ; les pods GKE peuvent servir plusieurs requêtes si votre environnement d’exécution est non bloquant ; pour une isolation stricte, réglez la simultanéité sur 1.

Signaux d’autoscaling et capacité préchauffée (warm capacity)

• L’autoscaling des MIG prend en charge l’utilisation du CPU, l’utilisation de l’équilibrage de charge et des métriques personnalisées via Cloud Monitoring. Pour un trafic en rafales (bursty), basez la scalabilité sur les métriques de requêtes (rps, profondeur de la file d’attente) plutôt que sur le CPU.
• Le Horizontal Pod Autoscaler (HPA) de GKE peut effectuer une scalabilité basée sur le CPU, la mémoire ou des métriques personnalisées/externes (par ex., la longueur de la file d’attente Pub/Sub). Utilisez le Vertical Pod Autoscaler (VPA) pour le bon dimensionnement (right-sizing), mais évitez les mises à jour en direct du VPA sur les frontends à scalabilité rapide pour prévenir l’instabilité (churn).
• Cloud Run effectue une mise à l’échelle en fonction de la charge de requêtes simultanées et, en option, de métriques personnalisées. Évitez les démarrages à froid (cold starts) en maintenant une capacité préchauffée (warm capacity) : configurez des instances minimales, maintenez une faible simultanéité inactive et préchauffez via des pings de santé synthétiques si nécessaire.
• L’autoscaling prédictif dans les MIG et la configuration de min replicas sur un déploiement/une révision aident à masquer la latence de provisionnement pendant les pics diurnes.

Équilibrage de charge, distribution globale du trafic, vérifications de santé et basculement (failover)

• Utilisez l’Application Load Balancer externe global pour un VIP anycast mondial, HTTP/2 et HTTP/3, et une terminaison en périphérie (edge) avec Cloud CDN. Les backends peuvent être des groupes d’instances, des NEG zonaux/régionaux, des NEG sans serveur (serverless NEGs pour Cloud Run/Functions) ou des Ingress GKE.
• Les vérifications de santé (health checks) détournent le trafic des backends défaillants. Assurez-vous que vos points de terminaison de santé valident les dépendances de manière ciblée (par ex., le processus et les ressources locales critiques) pour éviter les défaillances circulaires lors de pannes en aval.
• Les listes d’autorisation (allowlists) du pare-feu doivent autoriser les vérificateurs de santé. Si les vérifications sur le port 80 échouent, autorisez les plages d’adresses de Google :

undefined

• Basculement (Failover) : Configurez des services backend principaux/de secours ou des politiques de trafic qui dirigent vers des régions alternatives en cas d’échec de la vérification de santé. Pour un basculement au niveau DNS, utilisez les politiques Cloud DNS avec des vérifications de santé pour les points de terminaison non-HTTP.

Latence et Efficacité

Budgets de latence

• Allouez un budget de latence de bout en bout par niveau (client, périphérie, application, données). Surveillez les p95/p99, pas les moyennes. Utilisez Cloud Trace pour trouver les contributeurs inter-services et le blocage en tête de file (head-of-line blocking). Appliquez des délais (deadlines) aux RPC afin que l’annulation en amont libère de la capacité.

Utilisation du cache et du CDN

• Superposez les caches : cache client/navigateur, cache en périphérie du CDN (Cloud CDN) et caches régionaux/en mémoire (Memorystore ou en processus). Choisissez soigneusement les clés de cache et les en-têtes vary. Définissez les TTL en fonction de la fraîcheur des données et du risque de péremption ; envisagez la mise en cache négative pour les 404 lorsque cela est sûr.
• Servez les ressources statiques depuis Cloud Storage derrière Cloud CDN pour réduire la charge sur l’origine et la latence de queue. Utilisez des URL/en-têtes signés pour un accès contrôlé.

Réutilisation des connexions

• Privilégiez HTTP/2 ou gRPC pour le multiplexage et la compression des en-têtes. Activez les keep-alives et le regroupement de connexions (connection pooling) pour réduire la surcharge liée à l’établissement de la connexion (handshake). Surveillez l’épuisement des ports NAT ; ajustez les pools de connexions client et les délais d’inactivité (idle timeouts), et dimensionnez les ports Cloud NAT par VM le cas échéant.

Efficacité de la charge utile (payload)

• Utilisez des encodages binaires (par ex., protobuf) et compressez les charges utiles textuelles (gzip/brotli) au-delà d’un certain seuil de taille. Concevez soigneusement les champs des requêtes/réponses ; paginez, filtrez côté serveur et évitez de récupérer trop de données (over-fetching). Utilisez les ETags et les requêtes conditionnelles (If-None-Match) pour éviter les transferts redondants. Pour Cloud Storage, utilisez les préconditions de génération et les lectures partielles (Range reads) pour le contenu partiel.

Patrons de surcharge et de résilience

Limitation de débit, contre-pression, mise en file d’attente et traitement par lots

• Appliquez la limitation de débit en périphérie (Cloud Armor pour la limitation de débit basée sur l’IP/la géolocalisation/le service) et au niveau de la couche API (quotas Apigee, jetons par client d’API). Implémentez des algorithmes de seau à jetons (token-bucket) ou de seau percé (leaky-bucket) côté serveur pour un partage équitable.
• Contre-pression : Ne dépassez pas la capacité des services en aval. Utilisez des files d’attente (Pub/Sub pour la transmission d’événements “au moins une fois” ; Cloud Tasks pour des limitations par file d’attente et par cible avec planification et nouvelles tentatives). Propagez les erreurs 429 Too Many Requests ou 503 avec un en-tête Retry-After pour repousser les clients.
• Le traitement par lots peut augmenter le débit et réduire la surcharge par appel (par ex., mutations par lots dans les bases de données ou acquittements par lots sur Pub/Sub), échangeant une latence accrue contre une meilleure efficacité. Ajustez la taille des lots et le temps d’attente maximal.

Protection contre la surcharge

• Appliquez des délais d’attente (timeouts) et des échéances (deadlines) à chaque RPC. Utilisez des disjoncteurs (circuit breakers) pour cesser d’envoyer du travail aux dépendances défaillantes et permettre des solutions de repli rapides. Mettez en œuvre le délestage de charge (load shedding) en fonction de la profondeur de la file d’attente, de l’utilisation du CPU ou du non-respect du SLO de latence pour protéger les fonctionnalités essentielles.

Nouvelles tentatives résilientes, backoff exponentiel, gigue, idempotence et gestion des doublons

• N’effectuez de nouvelles tentatives que lorsque c’est sûr : délais d’attente réseau, erreurs 5xx ou codes documentés comme pouvant faire l’objet d’une nouvelle tentative (par ex., Cloud Storage 429/5xx). Ne réessayez jamais sur des erreurs 4xx comme 400/401/403, sauf indication contraire.
• Utilisez un backoff exponentiel tronqué avec de la gigue (jitter) pour éviter les nouvelles tentatives synchronisées. Préférez la gigue complète (full jitter). Exemple :

undefined

• Assurez l’idempotence. Utilisez des clés d’idempotence (par ex., un ID d’opération unique) et des opérations d’upsert/écritures conditionnelles pour tolérer les doublons. Pour Pub/Sub, dédupliquez en utilisant le messageId ou des clés applicatives ; concevez les gestionnaires pour qu’ils soient sûrs pour une livraison “au moins une fois”. Pour les écritures sur Cloud Storage, utilisez les préconditions generation-match pour éviter les écrasements.

Montée en charge des ressources dormantes

• Certains services appliquent des limites adaptatives. Pour Cloud Storage, augmentez progressivement les taux de requêtes sur les buckets précédemment inactifs pour réduire les erreurs 429/5xx transitoires lors de pics soudains. Limitez les producteurs et “chauffez” les buckets avec un trafic contrôlé avant la pleine charge.

Haute disponibilité, données, reprise après sinistre et tests

Multizone, régional, multirégional ; actif-actif vs actif-passif

• Déployer sur plusieurs domaines de défaillance. Utiliser des MIG régionaux ou des clusters GKE régionaux pour la tolérance aux pannes de zone. Pour les services mondiaux, utiliser plusieurs régions avec le global load balancer.
• L’actif-actif réduit le RTO et la latence, mais exige des données sans conflit et une gestion rigoureuse de la cohérence. L’actif-passif simplifie la sémantique d’écriture, mais entraîne un RTO plus élevé et une potentielle capacité à froid.

RTO, RPO, sauvegarde, restauration et tests de reprise après sinistre

• Définir le RTO (temps de reprise du service) et le RPO (perte de données tolérable) pour chaque charge de travail. Les faire correspondre aux capacités de la plateforme :
  • Cloud Spanner : multirégional avec une disponibilité de cinq 9 et une réplication synchrone pour un RPO quasi nul.
  • Cloud SQL : Haute Disponibilité au sein d’une région ; utiliser des instances dupliquées interrégionales pour la reprise après sinistre, activer la restauration à un moment précis (PITR) et valider les procédures de basculement/rétablissement.
  • Firestore et Bigtable offrent des options régionales et multirégionales ; choisir en fonction des exigences de RTO/RPO.
  • Les buckets Cloud Storage bi-régionaux ou multirégionaux fournissent une géo-redondance ; vérifier les procédures de restauration et la réémission des URL signées.
• Tester la reprise après sinistre : Effectuer régulièrement des exercices de basculement. Valider les sauvegardes en les restaurant dans un environnement isolé, répéter le basculement du DNS/trafic et mesurer les RTO/RPO réels.

Performance des bases de données et du stockage, conception des index, clés surchargées (hot keys) et contention

• Cloud Spanner : Éviter les clés primaires à croissance monotone qui créent des points chauds (hotspotting). Utiliser des tables entrelacées pour la localité, des index secondaires pour les schémas de lecture et des transactions délimitées pour réduire les conflits de verrouillage. Dimensionner les nœuds pour les QPS et le stockage ; conserver au moins trois nœuds pour le quorum de production et la marge de manœuvre.
• Cloud SQL : Analyser les requêtes, ajouter des index couvrants, éviter les transactions longues et utiliser des pools de connexions. Ajuster judicieusement les paramètres d’InnoDB ou de Postgres ; mettre à l’échelle les instances dupliquées avec accès en lecture pour les charges de travail à forte lecture.
• Bigtable : Concevoir les clés de ligne pour distribuer uniformément la charge (salage ou inversion de champ). Utiliser le routage multi-cluster pour la haute disponibilité entre les régions si disponible.
• Firestore : Utiliser des index composites pour les requêtes sur plusieurs champs ; être conscient du hotspotting lorsque de nombreuses écritures ciblent le même chemin de document.
• Cloud Storage : Cohérence forte en lecture après écriture pour les nouveaux objets ; utiliser les téléversements parallèles et la segmentation (chunking) pour le débit. Augmenter progressivement le trafic sur les buckets inactifs ; préférer la périphérie du CDN pour les lectures fréquentes. Pour de nombreuses VM nécessitant le même grand jeu de données en lecture seule, attacher un disque persistant en mode lecture seule à plusieurs instances pour un accès local rapide à faible coût.

Tests de charge, expériences de chaos, injection de pannes et planification de la capacité

• Tests de charge : Simuler des formes de trafic et des distributions de données réalistes. Préchauffer les caches et les autoscalers ; tester la latence p95/p99 sous charge et pendant les événements de mise à l’échelle. Répliquer une petite fraction du trafic en direct vers des piles fantômes (shadow stacks) pour valider le comportement avec la complexité de la production.
• Chaos et injection de pannes : Arrêter des pods/VM, isoler une zone, injecter de la latence/des erreurs au niveau du maillage de services (par ex., Envoy/Istio) pour observer le rayon d’impact et la résilience. Vérifier que les disjoncteurs (circuit breakers) et les tentatives se comportent comme prévu.
• Planification de la capacité : Prévoir en utilisant la demande historique et les événements planifiés. Maintenir une marge de manœuvre pour les pannes N+1 et le rééquilibrage. Aligner les délais de récupération (cooldowns) et les taux maximums de l’autoscaler avec les pics attendus ; pré-provisionner pendant les pics prévisibles.

Compromis de disponibilité entre les services gérés et les architectures personnalisées

• Calcul : Cloud Run offre une mise à l’échelle rapide jusqu’à zéro et une faible charge opérationnelle, mais présente des démarrages à froid et des contraintes de simultanéité des requêtes. GKE fournit un contrôle fin et une portabilité au prix d’un coût opérationnel plus élevé. Les VM Compute Engine offrent un contrôle maximal avec la charge opérationnelle la plus lourde.
• Données : Cloud Spanner fournit une cohérence globale et une haute disponibilité à un coût plus élevé et avec une plus grande rigueur de schéma. Cloud SQL convient aux SGBDR traditionnels avec des opérations plus simples mais une HA/scalabilité limitée. Bigtable excelle pour les données clé-valeur/séries temporelles à faible latence et à très grande échelle. Firestore fournit des schémas flexibles avec une forte cohérence et des options globales.
• Réseau : Les global load balancers et Cloud CDN sont hautement disponibles et opèrent à la périphérie de Google ; les proxys personnalisés (DIY) offrent une personnalisation mais créent un risque opérationnel et de défaillance.
• Préférer les services gérés pour une disponibilité de base plus élevée et une résistance aux attaques DDoS, mais tenir compte des quotas, des démarrages à froid et de la sémantique spécifique au service dans votre conception.

Scénario de problème pratique

NimbusMart, une entreprise mondiale de commerce électronique, a besoin d’une API de catalogue de produits à faible latence avec une disponibilité de cinq 9 et une latence de lecture minimisée pour les utilisateurs en Amérique du Nord, en Europe et en Asie-Pacifique. Les écritures doivent être globalement cohérentes. Le trafic est en dents de scie pendant les ventes flash, et les incidents passés incluent des tentatives en cascade et une surcharge de l’origine.

Approche :

1. Provisionner une instance Cloud Spanner multirégionale en utilisant nam-asia-eur1 avec au moins trois nœuds.

• Justification : Fournit des lectures/écritures globalement cohérentes avec une disponibilité de cinq 9 et place les réplicas à proximité des utilisateurs pour réduire la latence de lecture. Un minimum de trois nœuds assure la robustesse du quorum et une marge de manœuvre pour le rééquilibrage.

2. Implémenter une couche API sans état (stateless) dans plusieurs régions derrière le global external Application Load Balancer.

• Justification : Le VIP Anycast et le routage mondial réduisent l’établissement de la connexion et dirigent les utilisateurs vers la région saine la plus proche. Les services sans état facilitent la mise à l’échelle horizontale et le basculement.

3. Configurer les vérifications de l’état (health checks) et les règles de pare-feu pour l’accessibilité du load balancer.

• Justification : Les vérifications de l’état empêchent le routage vers des backends défaillants. Autoriser les plages d’adresses IP de vérification de l’état de Google pour que les vérifications réussissent : gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS

4. Mettre en œuvre la mise à l’échelle automatique basée sur les métriques de requêtes avec une capacité préchauffée.

• Justification : Mettre à l’échelle les MIG ou le HPA de GKE sur les QPS/latence plutôt que sur le CPU pour réagir au trafic des ventes flash. Maintenir un nombre minimum de réplicas par région pour éviter les démarrages à froid et permettre la mise à l’échelle prédictive avant les événements connus.

5. Ajouter Cloud CDN pour les médias de produits statiques stockés dans Cloud Storage.

• Justification : La mise en cache en périphérie décharge l’origine, réduit la latence de queue et atténue l’amplification des rafales sur les couches applicatives et de stockage. Utiliser des URL signées et des clés de cache/TTL appropriés.

6. Appliquer une protection contre la surcharge et une limitation de débit en périphérie et au niveau du service.

• Justification : Configurer les limites de débit de Cloud Armor pour absorber les pics abusifs. Dans le service, utiliser des limites de type seau à jetons (token bucket) par client et délester les requêtes de faible priorité lorsque les SLO de latence sont menacés. Appliquer des délais (deadlines) à chaque appel en aval.

7. Utiliser des tentatives résilientes avec un intervalle exponentiel tronqué et une gigue complète (full jitter) ; assurer l’idempotence avec des ID d’opération.

• Justification : Prévenir les effets de troupeau (thundering herds) et les écritures en double lors de pannes partielles. Les clés d’idempotence garantissent des rejeux sûrs ; pour les opérations de stockage, utiliser des préconditions conditionnelles.

8. Introduire une file d’attente d’écriture pour le lissage des rafales et l’asynchronisme là où c’est acceptable.

• Justification : Pub/Sub absorbe les pics soudains d’écritures non critiques (par ex., les événements d’analyse), découplant les producteurs de Spanner et protégeant les chemins d’écriture primaires de la surcharge.

9. Définir des SLO et des budgets de latence ; instrumenter le traçage et les tableaux de bord.

• Justification : Les budgets par niveau guident l’optimisation. Les SLO de Cloud Monitoring avec des budgets d’erreur et Cloud Trace révèlent les contributeurs interrégionaux et de la couche de données à la latence p99.

10. Établir des procédures de reprise après sinistre et tester le basculement.

• Justification : Avec Spanner multirégional et un calcul multirégional, pratiquer des exercices d’évacuation de région. Vérifier le RTO avec des chronologies de drainage et de montée en charge du trafic, et valider que les autoscalers et le CDN se comportent correctement pendant le basculement.

Cette conception satisfait les objectifs de disponibilité mondiale et de faible latence en alignant la topologie du calcul et des données, en appliquant des contrôles de surcharge et en utilisant des services gérés qui offrent une scalabilité et une résilience éprouvées.

← Observabilité · Tous les domaines · Tests →

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

Parcourir Google →