Google PCNE: Équilibrage de charge, Cloud CDN et gestion du trafic mondial — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network Engineer — 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

Cette section explique comment Google Cloud Load Balancing, Cloud CDN et la gestion du trafic mondial fonctionnent ensemble pour fournir des services résilients, performants et sécurisés. Elle couvre les familles d’équilibreurs de charge et leur sélection, le comportement des proxys par rapport au mode passthrough, les composants de backend et de routage, le basculement et la gestion de la capacité, la mise en cache avec Cloud CDN et les protections de l’origine, les conceptions anycast et interrégionales, l’aiguillage DNS et les vérifications d’état, l’observabilité et les modèles de conception pour des points d’entrée mondiaux robustes.

Familles d’équilibreurs de charge, sélection et comportement du plan de données

Google Cloud fournit des équilibreurs de charge externes et internes avec des portées, des protocoles et des caractéristiques de plan de données distincts. Choisir le bon permet d’aligner les besoins en matière de protocole, la géographie et les contrôles opérationnels.

Proxy externe L7 (mondial) : External Application Load Balancer pour HTTP(S) et gRPC. Termine la connexion TLS, applique les politiques L7, prend en charge les mappages d’URL, Cloud CDN, Cloud Armor, les fonctionnalités de requête/réponse et l’anycast IPv4/IPv6. Idéal pour les API/sites web exposés sur Internet nécessitant un routage avancé, de la sécurité et de la mise en cache.
Proxy externe L4.5 : External TCP Proxy Load Balancer (mondial) et External UDP Proxy Load Balancer (régional) terminent les connexions client et les transmettent aux backends via un proxy. À utiliser lorsque vous avez besoin d’une VIP mondiale et de fonctionnalités L4 (politique TLS, préservation de l’IP client via les en-têtes pour TCP) sans routage L7.
Passthrough externe L3/L4 (régional) : External Network Load Balancer transfère les paquets sans terminer la connexion. Latence la plus faible et plus simple ; prend en charge TCP/UDP/ESP/ICMP. Approprié pour le lift-and-shift, les backends hétérogènes ou les protocoles qui ne tolèrent pas la terminaison par proxy. Le NLB classique utilise des pools cibles (target pools) ; le nouveau NLB passthrough régional utilise des services de backend (backend services).
Proxy interne (régional) : Internal HTTP(S) Load Balancer (L7) et Internal TCP Proxy Load Balancer (L4.5) terminent et transmettent via un proxy à l’intérieur d’un VPC pour une utilisation nord-sud des microservices et de service à service. Prennent en charge le routage par hôte/chemin (HTTP), le mTLS vers les clients via l’application et les politiques de sécurité par service.
Passthrough interne (régional) : Internal TCP/UDP Load Balancer distribue les connexions aux backends sur des adresses privées RFC1918, en préservant l’IP du client et en utilisant le hachage MAGLEV. Idéal pour les services est-ouest (bases de données, protocoles personnalisés) nécessitant une distribution tenant compte des zones et une faible surcharge.

Compromis sur la couche et la terminaison :

Le proxy L7/4.5 offre un routage avancé, le déchargement TLS, l’observabilité, Cloud Armor/CDN et le basculement interrégional au prix de sauts supplémentaires et de possibles modifications d’en-tête/NAT. Il convient aux points d’entrée publics et aux maillages de services (service meshes).
Le passthrough L3/L4 préserve l’IP du client de bout en bout et minimise la latence, mais n’offre pas de fonctionnalités L7 et moins de points d’observabilité. Le comportement de la session est basé sur le hachage ; les vérifications d’état sont plus simples.

Portée et familles d’adresses IP :

Des VIP anycast mondiales sont disponibles pour l’External Application LB et l’External TCP Proxy LB, fournissant des adresses IPv4/IPv6 uniques joignables de partout. Les équilibreurs de charge régionaux utilisent des VIP unicast régionales. L’exposition IPv6 pour les services publics est réalisée en configurant un équilibreur de charge mondial externe avec une adresse IPv6.

Points clés des critères de sélection :

Besoin de routage par hôte/chemin, de redirections, de Cloud CDN, de Cloud Armor ou de gRPC : External Application LB.
Besoin de TCP mondial sans L7 : External TCP Proxy LB.
Protocoles qui ne fonctionnent pas bien avec les proxys (par ex., certains protocoles UDP/TFTP hérités) : Passthrough externe ou interne.
Service à service privé avec routage HTTP : Internal HTTP(S) LB.
Minimiser le coût/les sauts pour le trafic intra-VPC : Passthrough interne.

Services de backend, objets de routage, santé et persistance du trafic

Objets principaux du plan de données :

Services de backend : Définissent les backends (groupes d’instances, NEG zonaux, NEG hybrides, NEG sans serveur), les vérifications de l’état de santé, le mode d’équilibrage, la capacité, l’affinité de session, le délai d’expiration et la politique de basculement. Requis pour les LB proxy et les LB passthrough plus récents.
Target pools : Construction héritée (legacy) pour le NLB externe classique. Convient aux distributions TCP/UDP simples et aux VM hétérogènes lors d’un lift-and-shift.
Ports nommés : Clés sur les groupes d’instances qui mappent des noms logiques (par ex., http) à des numéros de port, référencées par les services de backend et les mappages d’URL. Assurez la cohérence entre les membres du groupe.

Vérifications de l’état de santé et basculement :

Types : HTTP(S), HTTP/2, gRPC, TCP, SSL. Choisissez une vérification qui valide la disponibilité réelle du service, et non seulement l’accessibilité du système d’exploitation.
Portée : Les vérifications de l’état de santé sont régionales ; chaque backend doit avoir une vérification de l’état de santé dont la portée est limitée à sa région de service.
Politique de basculement : Le service de backend peut désigner des backends principaux et de basculement. Le trafic bascule lorsque le backend principal est défaillant ou n’a plus de capacité (si le basculement sur capacité est activé et que le seuil est atteint). Envisagez le drainage et la réservation de capacité pour éviter l’effet de troupeau (thundering herd).

Mappages d’URL et routage :

Le mappage d’URL (URL map) s’attache au LB HTTP(S) externe ou interne et définit les règles d’hôte et les règles de correspondance de chemin.
Service par défaut : Backend fourre-tout pour les requêtes qui ne correspondent à aucune règle ; s’il n’est pas défini, une erreur 404 est renvoyée.
Redirections et réécritures : Utilisez les actions du mappage d’URL pour effectuer des redirections HTTPS, des redirections d’hôte canoniques ou des réécritures de chemin avant le routage.

Exemple : mappage d’URL minimal avec redirection HTTPS et backend par défaut

Créez une règle d’hôte pour example.com, redirigez le trafic HTTP vers HTTPS, routez /static vers un bucket de backend compatible CDN, et utilisez par défaut un service de backend régional.

Affinité de session et drainage :

Les options d’affinité dépendent du type de LB. Options courantes :
- Aucune : Idéal pour les applications sans état (stateless) ; maximise la répartition de la charge.
- Client IP : Persistance par IP source pour L4/L7 ; à utiliser lorsque plusieurs protocoles (par ex., HTTP et TFTP) doivent être liés de manière persistante au même backend.
- Cookie généré (L7 uniquement) : Le LB définit un cookie pour maintenir la persistance vers un backend ; meilleure répartition que l’IP client pour les clients derrière un NAT.
Compromis : L’affinité peut provoquer une concentration de trafic (hotspotting) et compliquer l’autoscaling. Préférez les architectures sans état (stateless) lorsque c’est possible.
Drainage de connexion : Lors d’un scale-in ou de la suppression d’un backend, le LB respecte le délai de drainage pour permettre aux connexions existantes de se fermer correctement. Ajustez le temps de drainage à la durée de votre requête la plus longue attendue pour éviter les réinitialisations.

Capacité et autoscaling :

Modes d’équilibrage : Basés sur l’utilisation (par ex., CPU), le nombre de RPS (requêtes par seconde) ou les connexions. Chaque backend annonce sa capacité ; le LB décharge le trafic ou bascule lorsque la saturation se produit.
Autoscaling : Les groupes d’instances gérés (Managed instance groups) effectuent un scaling en fonction de signaux (CPU, métriques personnalisées). Un retard de scale-out peut provoquer des erreurs 503 si le LB n’a plus de capacité ; pré-provisionnez avec un nombre minimal de réplicas ou utilisez l’autoscaling prédictif pour le trafic diurne.
Basculement et débordement : L’activation du basculement sur capacité (failover-on-capacity) avec un seuil approprié permet un débordement fluide entre les régions.

Sécurité au niveau des backends :

Restreignez l’accès au backend à l’aide de règles de pare-feu ciblant les tags d’instance ou les comptes de service. N’autorisez que le trafic provenant des plages sources de l’équilibreur de charge et des vérifications de l’état de santé de Google, ainsi que vos plages de clients approuvées si un accès direct est requis pour les clients internes.

Exemple : restreindre les clients et les vérifications de l’état de santé à un groupe tagué comme backend

Taguez les instances avec application.
Créez une règle d’autorisation d’entrée (ingress allow) pour tcp:80 depuis vos CIDR clients et les plages de vérification de l’état de santé de Google, en ciblant le tag application.
Le refus par défaut (deny-by-default) est recommandé pour faire apparaître le trafic rejeté dans les journaux.

Cloud CDN, politique de cache et protection de l’origine

Cloud CDN s’intègre avec l’Application Load Balancer externe pour mettre en cache les réponses au niveau des POPs (points de présence) en périphérie, réduisant ainsi la latence et déchargeant la capacité de l’origine.

Modes de cache et TTL :

Utiliser les en-têtes de l’origine : Respecte les en-têtes Cache-Control et Expires de votre origine. Préféré pour garantir l’exactitude.
Forcer le cache : Met en cache toutes les réponses avec un TTL par défaut configuré, en remplaçant ou en ignorant éventuellement les en-têtes de l’origine pour le contenu statique. À utiliser avec précaution pour éviter de mettre en cache des données dynamiques.
Contourner le cache : Utile pour les chemins qui ne doivent jamais être mis en cache.

Clés de cache :

Les champs de la clé incluent le protocole, l’hôte, le chemin, les paramètres de requête, les en-têtes et les cookies. Configurez la politique de chaîne de requête (tout inclure, inclure une sélection ou ignorer), l’inclusion sélective d’en-têtes et de cookies, et la segmentation par appareil selon les besoins.
Gardez les clés minimales pour maximiser le taux de succès (hit ratio) ; ne les faites varier que sur les champs qui modifient la représentation.

Requêtes signées :

URL signées : Joignez une signature HMAC ou RSA avec une date d’expiration et une portée de chemin pour accorder un accès limité dans le temps à des ressources spécifiques. Idéal pour utiliser le CDN comme accélérateur avec une autorisation par objet.
Cookies signés : Autorisez un ensemble de chemins avec un cookie ; utile pour le contenu à accès restreint sur l’ensemble d’un site.
Effectuez une rotation des clés et imposez des expirations courtes pour réduire le risque d’attaque par rejeu (replay).

Compression et exactitude :

Les origines doivent compresser même lorsque les requêtes incluent un en-tête Via. Si le CDN sert des objets non compressés alors que l’origine « prend en charge la compression », vérifiez que l’origine est configurée pour compresser lorsque l’en-tête Via est présent.

Sécurité de l’origine :

Utilisez HTTPS depuis les proxys de périphérie vers les origines avec des politiques TLS modernes.
Limitez l’accessibilité de l’origine : des règles de pare-feu du backend qui n’autorisent que le trafic provenant des plages de sources du load balancer Google et des vérifications de santé, ainsi que des producteurs privés connus. Les instances de backend ne devraient pas accepter de trafic entrant public arbitraire.
Associez-le à Cloud Armor pour la protection DDoS/WAF de couche 7, la limitation de débit et la détection des menaces. Utilisez le mode aperçu (preview) pour les nouvelles règles afin d’atténuer les faux positifs.
Invalidez intentionnellement le contenu à l’aide des API d’invalidation de cache lorsque vous devez le purger avant l’expiration du TTL. Pour le contenu dynamique, préférez des TTL courts et la revalidation (ETag/If-None-Match).

Modes de défaillance et compromis :

Des clés de cache trop larges gaspillent le cache et diminuent le taux de succès ; des clés trop étroites risquent de servir des variantes incorrectes.
Forcer la mise en cache de données dynamiques peut entraîner la fuite de contenu personnalisé.
Les URL/cookies signés protègent l’accès en périphérie, mais le contournement de l’origine doit toujours être refusé via une politique réseau.

Gestion du trafic mondial, pilotage DNS, observabilité et points d’entrée résilients

Façades anycast et basculement interrégional :

L’Application LB externe et le TCP Proxy LB externe utilisent des VIPs anycast mondiales pour attirer les clients vers le point de présence Google le plus proche. Le trafic est ensuite transmis par proxy au backend le plus sain et le plus proche disposant de capacité. Configurez plusieurs régions de backend avec des vérifications de l’état et des paramètres de capacité cohérents pour un basculement et un débordement transparents.
Pré-provisionnez la capacité dans les régions secondaires pour éviter les pénalités de démarrage à froid ; coordonnez les valeurs min/max de l’autoscaler avec les seuils de capacité de l’équilibreur de charge.

Gestion du trafic interne régional :

L’équilibreur de charge HTTP(S) interne et l’équilibreur de charge passthrough interne sont régionaux ; concevez pour une diversité de zones au sein d’une région et, si nécessaire, pour plusieurs régions en utilisant des équilibreurs de charge distincts avec Private Service Connect ou des clients conscients du service pour sélectionner les points de terminaison régionaux.
Maintenez une faible latence est-ouest en plaçant les services qui communiquent dans la même région et le même VPC. Utilisez l’adressage RFC1918 avec un seul VPC ou des VPC appairés pour un coût minimal et une simplicité opérationnelle.

Politiques de routage et vérifications de l’état de Cloud DNS :

Politiques : Round-robin pondéré (répartition du trafic), géolocalisation (envoyer les utilisateurs vers la VIP régionale la plus proche) et basculement (principal/secours). Combinez les politiques pour répondre aux règles métier.
Vérifications de l’état : Attachez des vérifications de l’état DNS (HTTP/HTTPS/TCP) aux enregistrements A/AAAA utilisés dans le pilotage afin que les points de terminaison défaillants soient retirés. Tenez compte de la mise en cache du résolveur (TTL) qui retarde la réaction ; maintenez des TTL bas sur les enregistrements pilotés pour améliorer la réactivité du basculement, au prix de davantage de recherches DNS.
Pilotage du trafic : Utilisez des politiques pondérées pour phaser les migrations ou répartir la charge entre les régions. Évitez de piloter le trafic vers des adresses privées depuis Internet, sauf si vous utilisez un DNS à horizon partagé.

Observabilité et diagnostics :

Journalisation de l’équilibreur de charge : Activez la journalisation pour tous les équilibreurs de charge. Les journaux HTTP(S) incluent la méthode/URI de la requête, la latence, le succès/échec de cache, le service de backend, la règle de la carte d’URL, les détails TLS et les codes de réponse. Les journaux TCP/UDP fournissent des métadonnées de connexion et l’état de la sonde de santé.
Métriques : Surveillez la santé du backend, l’utilisation, le RPS, les connexions, la latence, le taux de succès du cache, les taux de 4xx/5xx et la saturation de la capacité. Définissez des alertes sur les changements soudains et les seuils prolongés.
Modèles d’erreurs HTTP(S) courants :
- 404 : Aucune correspondance dans la carte d’URL ; confirmez les règles d’hôte/chemin et le service par défaut.
- 301/302 : Redirections intentionnelles ; vérifiez les boucles de redirection.
- 502 : Problème de connexion au backend ou non-concordance de protocole (par ex., HTTP/1.1 vs gRPC) ; vérifiez l’état et la configuration du protocole du backend.
- 503 : Aucun backend sain ou sans capacité ; vérifiez les vérifications de l’état, les quotas et le comportement de l’autoscaler.
Traçage des requêtes : Utilisez X-Forwarded-For, X-Forwarded-Proto et les ID de trace propagés par votre application. Corrélez les journaux de l’équilibreur de charge avec les journaux du backend en utilisant les ID de requête.
Firewall Insights : Activez la journalisation du pare-feu VPC sur les règles allow et deny. Pour journaliser explicitement les rejets, ajoutez une règle deny-all de faible priorité avec la journalisation activée.

Conception de point d’entrée mondial résilient :

Utilisez une seule VIP anycast mondiale sur un Application LB externe en façade de plusieurs backends régionaux. Placez les backends serverless/VM/conteneur dans au moins deux régions. Activez le basculement et le débordement interrégionaux, configurez des vérifications de l’état conservatives, et ajustez le drainage et les délais d’attente pour vos charges de travail.
Protégez le point d’entrée avec Cloud Armor et des politiques de limitation de quota. Utilisez Cloud CDN pour le contenu statique et le contenu dynamique cachable afin d’absorber les pics de trafic en périphérie.
Exposez une double pile IPv4/IPv6 sur l’équilibreur de charge mondial pour servir tous les réseaux. Pour un accès client strict, appliquez des règles de pare-feu de backend avec des plages sources précises et des tags d’instance ou des comptes de service.

Exemple : règle de pare-feu restreignant les plages de clients et de vérification de l’état aux backends tagués

Taguez les instances avec application.
Créez une règle d’entrée allow pour tcp:443 avec source-ranges=203.0.113.0/24,198.51.100.0/24, et les plages de vérification de l’état de Google ciblant application.
Assurez-vous qu’une règle deny-all de priorité inférieure avec journalisation existe pour capturer les sources inattendues.

Scénario de problème pratique

Acme Retail lance une plateforme e-commerce mondiale nécessitant une faible latence, une sécurité renforcée et un basculement transparent entre us-east1 et europe-west1, tout en servant efficacement les médias statiques. Seuls les bureaux de l’entreprise et un réseau de préproduction d’un CDN partenaire doivent pouvoir accéder à l’interface d’administration privée.

Façade et backends

Créez un Application Load Balancer externe avec une VIP anycast double pile et des certificats TLS pour le nom d’hôte de la vitrine publique.
Définissez deux services de backend, chacun pointant vers un groupe d’instances géré régional dans us-east1 et europe-west1. Activez les vérifications de l’état (HTTPS) et définissez le mode d’équilibrage sur l’utilisation avec un seuil de capacité de 80 %. Justification : La combinaison de l’anycast et des backends multi-régions garantit que les utilisateurs atteignent le point de présence le plus proche et basculent de manière transparente si une région est défaillante ou saturée.

Carte d’URL, routage et redirections

Configurez une carte d’URL avec des règles d’hôte pour les noms d’hôte de la vitrine publique et de l’administrateur privé. Routez /static vers un bucket de backend avec Cloud CDN activé ; routez /api et / vers les backends VM. Ajoutez une redirection HTTP vers HTTPS. Justification : Le routage par hôte/chemin sépare le trafic statique du trafic dynamique et impose un accès sécurisé.

Politique Cloud CDN

Pour le bucket de backend /static, définissez le mode de cache pour utiliser les en-têtes d’origine et définissez une clé de cache qui ignore les paramètres de requête non fonctionnels et n’inclut que l’en-tête Accept-Encoding. Activez la mise en cache négative pour les erreurs 404 courantes avec un TTL court. Justification : Respecte la sémantique du contenu, maximise le taux de succès et évite de mettre en cache des variantes incorrectes.

Affinité de session et drainage

Définissez une affinité par cookie généré pour la vitrine publique et aucune pour les ressources statiques ; réglez le drainage de connexion sur 60 secondes. Justification : Les cookies maintiennent la stabilité des sessions de panier tout en permettant une large distribution ; le drainage prévient les erreurs visibles par l’utilisateur lors d’une réduction d’échelle (scale-in) ou d’un basculement.

Basculement interrégional et autoscaling

Activez le basculement sur capacité avec un seuil de débordement de 90 % pour transférer l’excédent vers l’autre région. Configurez l’autoscaling du MIG avec un nombre minimal de 4 réplicas par région et des cibles de CPU correspondant à l’utilisation de l’équilibreur de charge. Justification : Évite les chutes brutales de capacité et coordonne les décisions de l’équilibreur de charge et de l’autoscaler pour une mise à l’échelle fluide.

Restriction de l’interface d’administration

Créez un équilibreur de charge HTTP(S) interne pour le nom d’hôte de l’administrateur privé, accessible uniquement à l’intérieur du VPC. Publiez un DNS Cloud à horizon partagé afin que les clients internes résolvent la VIP de l’ILB et que les clients externes reçoivent une réponse NXDOMAIN. Justification : Maintient le trafic d’administration privé et contrôlé sans exposer de points de terminaison publics.

Pare-feu de backend et sécurité de l’origine

Taguez les backends d’administration et web avec application et ajoutez une règle allow pour tcp:443 depuis les CIDR de l’entreprise et de la préproduction, ainsi que les plages sources de l’équilibreur de charge et des vérifications de l’état de Google ; ajoutez une règle deny-all avec journalisation à une priorité inférieure. Justification : Garantit que seuls les clients prévus et l’infrastructure Google peuvent atteindre les backends et fournit une visibilité sur les paquets rejetés.

Cloud Armor

Appliquez une politique de sécurité avec des règles WAF gérées et une limite de débit en mode prévisualisation pour les pics de trafic sur /api. Justification : La protection de niveau 7 et l’application progressive réduisent le risque pendant la phase d’ajustement.

Pilotage DNS et vérifications de l’état de Cloud DNS

Publiez des enregistrements A et AAAA pour le nom d’hôte de la vitrine publique vers la VIP anycast de l’ALB. Pour un canary bleu/vert, créez une politique pondérée sur un nom d’hôte canary désigné, répartissant 5 % du trafic vers l’ALB exclusif à europe-west1 et 95 % vers le déploiement mondial. Attachez des vérifications de l’état HTTPS pour retirer le canary s’il est défaillant et réglez le TTL à 20 secondes. Justification : Le canary basé sur le DNS permet une exposition progressive avec un retrait basé sur l’état de santé et une convergence rapide.

Observabilité

Activez les journaux de l’équilibreur de charge et du CDN ; exportez-les vers BigQuery pour analyse. Définissez des alertes sur le taux de 5xx, la capacité du backend, les échecs de vérification de l’état et le taux de succès du CDN. Utilisez les tests de carte d’URL et les journaux de requêtes pour diagnostiquer les erreurs de routage ; inspectez les pics de 502/503 pour détecter une saturation du backend ou des non-concordances de protocole. Justification : La surveillance proactive et les diagnostics rapides minimisent le MTTR et préservent l’expérience utilisateur.

← Connectivité hybride · Tous les domaines · Cloud DNS →

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