Google PCNE: Bilanciamento del carico, Cloud CDN e gestione del traffico globale — Guida allo studio

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

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Questa sezione spiega come Google Cloud Load Balancing, Cloud CDN e la gestione del traffico globale lavorano insieme per fornire servizi resilienti, performanti e sicuri. Tratta le famiglie di load balancer e la loro selezione, il comportamento proxy rispetto a quello passthrough, i componenti di backend e di routing, il failover e la gestione della capacità, il caching di Cloud CDN e le protezioni dell’origine, i design anycast e cross-region, l’instradamento DNS e gli health check, l’osservabilità e i pattern di progettazione per punti di ingresso globali e robusti.

Famiglie di load balancer, selezione e comportamento del data plane

Google Cloud fornisce load balancer esterni e interni con caratteristiche distinte di scope, protocollo e data plane. La scelta di quello giusto allinea le esigenze di protocollo, la geografia e i controlli operativi.

Proxy esterno L7 (globale): External Application Load Balancer per HTTP(S) e gRPC. Termina la connessione TLS, applica policy L7, supporta mappe URL, Cloud CDN, Cloud Armor, funzionalità di richiesta/risposta e anycast IPv4/IPv6. Ideale per API/siti web esposti su Internet che richiedono routing avanzato, sicurezza e caching.
Proxy esterno L4.5: External TCP Proxy Load Balancer (globale) e External UDP Proxy Load Balancer (regionale) terminano le connessioni dei client e le inoltrano ai backend tramite proxy. Da utilizzare quando si necessita di un VIP globale e di funzionalità L4 (policy TLS, conservazione dell’IP del client tramite header per TCP) senza routing L7.
Passthrough esterno L3/L4 (regionale): External Network Load Balancer inoltra i pacchetti senza terminare la connessione. Latenza più bassa e massima semplicità; supporta TCP/UDP/ESP/ICMP. Appropriato per il lift-and-shift, backend eterogenei o protocolli che non tollerano la terminazione tramite proxy. Il NLB classico utilizza i target pool; il più recente NLB passthrough regionale utilizza i backend service.
Proxy interno (regionale): Internal HTTP(S) Load Balancer (L7) e Internal TCP Proxy Load Balancer (L4.5) terminano e inoltrano tramite proxy all’interno di un VPC per l’uso north-south tra microservizi e service-to-service. Supportano il routing basato su host/path (HTTP), mTLS verso i client tramite l’applicazione e policy di sicurezza per-service.
Passthrough interno (regionale): Internal TCP/UDP Load Balancer distribuisce le connessioni ai backend su indirizzi privati RFC1918, conservando l’IP del client e utilizzando l’hashing MAGLEV. Ideale per servizi east-west (database, protocolli personalizzati) che richiedono una distribuzione consapevole della zona (zone-aware) e un basso overhead.

Compromessi tra layer e terminazione:

Il proxy L7/4.5 offre routing avanzato, offload TLS, osservabilità, Cloud Armor/CDN e failover cross-regionale al costo di hop aggiuntivi e possibili modifiche di header/NAT. È adatto per punti di ingresso pubblici e service mesh.
Il passthrough L3/L4 preserva l’IP del client end-to-end e minimizza la latenza, ma non offre funzionalità L7 e ha meno hook di osservabilità. Il comportamento della sessione è basato su hash; gli health check sono più semplici.

Scope e famiglie di IP:

I VIP anycast globali sono disponibili per l’External Application LB e l’External TCP Proxy LB, fornendo un singolo indirizzo IPv4/IPv6 raggiungibile da qualsiasi luogo. I LB regionali utilizzano VIP unicast regionali. L’esposizione IPv6 per i servizi pubblici si ottiene configurando un load balancer globale esterno con un indirizzo IPv6.

Punti salienti dei criteri di selezione:

Necessità di routing host/path, reindirizzamenti, Cloud CDN, Cloud Armor o gRPC: External Application LB.
Necessità di TCP globale senza L7: External TCP Proxy LB.
Protocolli che non gradiscono i proxy (es. alcuni UDP/TFTP legacy): Passthrough esterno o interno.
Service-to-service privato con routing HTTP: Internal HTTP(S) LB.
Minimizzare costi/hop per il traffico intra-VPC: Passthrough interno.

Servizi di backend, oggetti di routing, integrità e aderenza del traffico

Oggetti principali del data plane:

Servizi di backend: Definiscono i backend (gruppi di istanze, NEG di zona, NEG ibridi, NEG serverless), i controlli di integrità, la modalità di bilanciamento, la capacità, l’affinità di sessione, il timeout e la policy di failover. Necessari per i proxy LB e i più recenti passthrough LB.
Pool di destinazione: Costrutto legacy per il classico external NLB. Adatto per semplici distribuzioni TCP/UDP e VM eterogenee durante il lift-and-shift.
Porte denominate: Chiavi sui gruppi di istanze che mappano nomi logici (es. http) a numeri di porta, referenziate dai servizi di backend e dalle mappe URL. Assicurare la coerenza tra i membri del gruppo.

Controlli di integrità e failover:

Tipi: HTTP(S), HTTP/2, gRPC, TCP, SSL. Scegliere un controllo che convalidi l’effettiva prontezza del servizio, non solo la raggiungibilità del sistema operativo.
Ambito: I controlli di integrità sono regionali; ogni backend dovrebbe avere un controllo di integrità con ambito nella sua regione di servizio.
Policy di failover: Il servizio di backend può designare backend primari e di failover. Il traffico passa al failover quando il primario non è integro o ha esaurito la capacità (se il failover-on-capacity è abilitato e la soglia è raggiunta). Considerare il drenaggio e la prenotazione della capacità per evitare l’effetto “thundering herd”.

Mappe URL e routing:

La mappa URL si collega all’HTTP(S) LB esterno o interno e definisce le regole host e i path matcher.
Servizio predefinito: Backend catch-all per le richieste che non corrispondono a nessuna regola; se non impostato, viene restituito un 404.
Reindirizzamenti e riscritture: Usare le azioni della mappa URL per eseguire reindirizzamenti HTTPS, reindirizzamenti a host canonici o riscritture di percorsi prima del routing.

Esempio: mappa URL minima con reindirizzamento HTTPS e backend predefinito

Creare una regola host per example.com, reindirizzare HTTP a HTTPS, instradare /static a un backend bucket abilitato per CDN e usare come predefinito un servizio di backend regionale.

Affinità di sessione e drenaggio:

Le opzioni di affinità dipendono dal tipo di LB. Le opzioni comuni sono:
- Nessuna: Ideale per servizi stateless; massimizza la distribuzione del carico.
- IP client: Adesione (stickiness) per IP di origine su L4/L7; da usare quando più protocolli (es. HTTP e TFTP) devono avere aderenza allo stesso backend.
- Cookie generato (solo L7): L’LB imposta un cookie per mantenere la persistenza su un backend; distribuzione migliore rispetto all’IP client per i client dietro NAT.
Compromessi: L’affinità può causare hotspotting e complicare l’autoscaling. Preferire l’approccio stateless dove possibile.
Drenaggio delle connessioni: In caso di scale-in o rimozione di un backend, l’LB rispetta il timeout di drenaggio per consentire alle connessioni esistenti di chiudersi gradualmente. Regolare il tempo di drenaggio sulla richiesta più lunga prevista per evitare reset.

Capacità e autoscaling:

Modalità di bilanciamento: Basate sull’utilizzo (es. CPU), RPS o connessioni. Ogni backend dichiara la propria capacità; l’LB devia il carico o esegue il failover quando si verifica la saturazione.
Autoscaling: I gruppi di istanze gestite si scalano in base a segnali (CPU, metriche personalizzate). Il ritardo nello scale-out può causare errori 503 se l’LB esaurisce la capacità; effettuare un pre-warm con un numero minimo di repliche o con l’autoscaling predittivo per il traffico diurno.
Failover e overflow: Abilitare il failover-on-capacity con una soglia appropriata consente un overflow fluido tra regioni.

Sicurezza sui backend:

Limitare l’accesso al backend usando regole firewall che puntano a tag di istanza o service account. Consentire solo il traffico proveniente dai load balancer di Google e dagli intervalli di origine dei controlli di integrità, oltre agli intervalli dei client approvati se è richiesto l’accesso diretto per i client interni.

Esempio: limitare client e controlli di integrità a un gruppo con tag di backend

Assegnare un tag alle istanze con application.
Creare una regola di autorizzazione in ingresso per tcp:80 dagli intervalli CIDR dei client e dagli intervalli dei controlli di integrità di Google, con destinazione il tag application.
Si raccomanda una policy deny-by-default per far emergere il traffico scartato nei log.

Cloud CDN, policy di cache e protezione dell’origine

Cloud CDN si integra con l’Application Load Balancer esterno per memorizzare nella cache le risposte presso i POP edge, riducendo la latenza e alleggerendo la capacità dell’origine.

Modalità di cache e TTL:

Usa header di origine: Rispetta gli header Cache-Control ed Expires della tua origine. È la modalità preferita per garantire la correttezza.
Forza cache: Memorizza nella cache tutte le risposte con un TTL predefinito configurato, sovrascrivendo o ignorando opzionalmente gli header di origine per i contenuti statici. Da usare con cautela per evitare di memorizzare nella cache dati dinamici.
Bypass della cache: Utile per i percorsi che non devono mai essere memorizzati nella cache.

Chiavi di cache:

I campi della chiave includono protocollo, host, percorso, parametri di query, header e cookie. Configura la policy per le query string (includi tutto, includi una selezione o ignora), l’inclusione selettiva di header e cookie e la segmentazione per dispositivo secondo necessità.
Mantieni le chiavi minimali per massimizzare l’hit ratio; variale solo in base ai campi che modificano la rappresentazione del contenuto.

Richieste firmate:

URL firmati: Allega una firma HMAC o RSA con una scadenza e un ambito di percorso per concedere un accesso limitato nel tempo a risorse specifiche. Ideale per l’uso della CDN come acceleratore con autorizzazione per singolo oggetto.
Cookie firmati: Autorizza un insieme di percorsi con un cookie; utile per contenuti ad accesso limitato su un intero sito.
Ruota le chiavi e imponi scadenze brevi per ridurre il rischio di attacchi di tipo “replay”.

Compressione e correttezza:

Le origini devono comprimere i dati anche quando le richieste includono un header Via. Se la CDN serve oggetti non compressi mentre l’origine “supporta la compressione”, verifica che l’origine sia configurata per comprimere quando l’header Via è presente.

Sicurezza dell’origine:

Usa HTTPS dai proxy edge verso le origini con policy TLS moderne.
Limita la raggiungibilità dell’origine: imposta regole firewall del backend che consentano solo il traffico proveniente dagli intervalli di origine del load balancer e degli health check di Google e da producer privati noti. Le istanze di backend non dovrebbero accettare traffico in ingresso pubblico arbitrario.
Abbina a Cloud Armor per DDoS/WAF di livello 7, rate limiting e rilevamento delle minacce. Usa la modalità di anteprima per le nuove regole per mitigare i falsi positivi.
Invalida intenzionalmente i contenuti usando le API di invalidamento della cache quando devi eliminarli prima della scadenza del TTL. Per i contenuti dinamici, preferisci TTL brevi e la rivalidazione (ETag/If-None-Match).

Modalità di fallimento e compromessi:

Chiavi di cache troppo generiche sprecano spazio nella cache e abbassano l’hit ratio; chiavi troppo specifiche rischiano di servire varianti di contenuto errate.
Forzare la memorizzazione nella cache di dati dinamici può causare la fuga di contenuti personalizzati.
URL/cookie firmati proteggono l’accesso a livello di edge, ma il bypass dell’origine deve comunque essere negato tramite una policy di rete.

Gestione del traffico globale, indirizzamento DNS, osservabilità e punti di ingresso resilienti

Punti di ingresso anycast e failover cross-region:

L’Application LB esterno e il TCP Proxy LB esterno utilizzano VIP anycast globali per attirare i client verso l’edge di Google più vicino. Il traffico viene quindi inoltrato tramite proxy al backend più integro, più vicino e con capacità disponibile. Configurare più region di backend con health check e impostazioni di capacità coerenti per un failover e un overflow senza interruzioni.
Pre-allocare la capacità nelle region secondarie per evitare penalità di avvio a freddo; coordinare i valori min/max dell’autoscaler con le soglie di capacità del LB.

Gestione del traffico interno regionale:

L’HTTP(S) LB interno e il passthrough LB interno sono regionali; progettare per la diversità di zona all’interno di una region e, se necessario, per il multi-region utilizzando LB separati con Private Service Connect o client consapevoli del servizio per selezionare gli endpoint regionali.
Mantenere bassa la latenza est-ovest posizionando i servizi che comunicano tra loro nella stessa region e nello stesso VPC. Utilizzare l’indirizzamento RFC1918 con un singolo VPC o VPC in peering per costi minimi e semplicità operativa.

Policy di routing e health check di Cloud DNS:

Policy: Round robin ponderato (suddivisione del traffico), geolocalizzazione (inviare gli utenti al VIP regionale più vicino) e failover (primario/backup). Combinare le policy per soddisfare le regole di business.
Health check: Associare gli health check DNS (HTTP/HTTPS/TCP) ai record A/AAAA utilizzati nell’indirizzamento in modo che gli endpoint non integri vengano rimossi. Tenere conto del caching del resolver (TTL) che ritarda la reazione; mantenere bassi i TTL sui record indirizzati per migliorare la reattività del failover, al costo di un maggior numero di lookup DNS.
Indirizzamento del traffico: Utilizzare policy ponderate per effettuare migrazioni graduali o spostare il carico tra le region. Evitare di indirizzare il traffico da Internet verso indirizzi privati, a meno che non si utilizzi un DNS split-horizon.

Osservabilità e diagnostica:

Logging del bilanciatore di carico: Abilitare il logging per tutti i LB. I log HTTP(S) includono metodo/URI della richiesta, latenza, hit/miss della cache, servizio di backend, regola della mappa URL, dettagli TLS e codici di risposta. I log TCP/UDP forniscono metadati sulla connessione e lo stato delle probe di health check.
Metriche: Monitorare l’integrità del backend, l’utilizzo, RPS, connessioni, latenza, rapporto di hit della cache, tassi di errori 4xx/5xx e saturazione della capacità. Impostare alert su cambiamenti improvvisi e sul superamento prolungato delle soglie.
Pattern di errore HTTP(S) comuni:
- 404: Nessuna corrispondenza nella mappa URL; verificare le regole di host/path e il servizio predefinito.
- 301/302: Reindirizzamenti intenzionali; verificare la presenza di loop di reindirizzamento.
- 502: Problema di connessione con il backend o discrepanza di protocollo (es. HTTP/1.1 vs gRPC); controllare l’integrità e la configurazione del protocollo del backend.
- 503: Nessun backend integro o senza capacità; verificare gli health check, le quote e il comportamento dell’autoscaler.
Tracciamento delle richieste: Utilizzare X-Forwarded-For, X-Forwarded-Proto e gli ID di traccia propagati dalla propria applicazione. Correlare i log del LB con i log del backend utilizzando gli ID delle richieste.
Analisi del firewall: Abilitare il logging del firewall VPC sulle regole di allow e deny. Per registrare esplicitamente i drop, aggiungere una regola deny-all a bassa priorità con il logging abilitato.

Progettazione di un punto di ingresso globale resiliente:

Utilizzare un singolo VIP anycast globale su un Application LB esterno che funge da front-end per più backend regionali. Posizionare i backend serverless/VM/container in almeno due region. Abilitare il failover e l’overflow cross-region, configurare health check conservativi e ottimizzare il drenaggio e i timeout per i propri carichi di lavoro.
Proteggere il punto di ingresso con Cloud Armor e policy di limitazione delle quote. Utilizzare Cloud CDN per contenuti statici e dinamici memorizzabili nella cache per assorbire i picchi di traffico sull’edge.
Esporre il dual-stack IPv4/IPv6 sul LB globale per servire tutte le reti. Per un accesso client restrittivo, applicare regole firewall di backend con intervalli di origine precisi e tag di istanza o service account.

Esempio: regola firewall che limita gli intervalli di client e health check a backend con tag specifici

Assegnare alle istanze il tag application.
Creare una regola di ingress allow per tcp:443 con source-ranges=203.0.113.0/24, 198.51.100.0/24 e gli intervalli degli health check di Google, che abbia come target application.
Assicurarsi che esista una regola deny-all a priorità più bassa con logging per catturare le origini impreviste.

Scenario pratico

Acme Retail lancia una piattaforma e-commerce globale che richiede bassa latenza, sicurezza elevata e failover trasparente tra us-east1 ed europe-west1, servendo al contempo i media statici in modo efficiente. Solo gli uffici aziendali e una rete di staging CDN partner dovrebbero poter raggiungere l’interfaccia di amministrazione privata.

Punto di ingresso e backend

Creare un Application Load Balancer esterno con un VIP anycast dual-stack e certificati TLS per l’hostname della vetrina pubblica.
Definire due servizi di backend, ciascuno che punta a un gruppo di istanze gestite regionale in us-east1 ed europe-west1. Abilitare gli health check (HTTPS) e impostare la modalità di bilanciamento su utilization con una soglia di capacità dell'80%. Motivazione: L’uso di anycast e backend multi-region garantisce che gli utenti raggiungano l’edge più vicino e che il failover avvenga senza interruzioni se una region non è integra o è satura.

Mappa URL, routing e reindirizzamenti

Configurare una mappa URL con regole di host per gli hostname della vetrina pubblica e dell’amministratore privato. Indirizzare /static a un bucket di backend con Cloud CDN abilitato; indirizzare /api e / ai backend VM. Aggiungere un reindirizzamento da HTTP a HTTPS. Motivazione: Il routing basato su host/path separa il traffico statico da quello dinamico e impone un accesso sicuro.

Policy di Cloud CDN

Per il bucket di backend /static, impostare la modalità cache per utilizzare gli header di origine e definire una chiave di cache che ignori i parametri di query non funzionali e includa solo l’header Accept-Encoding. Abilitare il negative caching per gli errori 404 comuni con un TTL breve. Motivazione: Rispetta la semantica del contenuto, massimizza il rapporto di hit e evita di memorizzare nella cache varianti errate.

Affinità di sessione e drenaggio

Impostare l’affinità basata su cookie generato per la vetrina pubblica e nessuna affinità per gli asset statici; impostare il drenaggio delle connessioni a 60 secondi. Motivazione: I cookie mantengono stabili le sessioni del carrello pur consentendo un’ampia distribuzione; il drenaggio previene errori visibili all’utente durante lo scale-in o il failover.

Failover cross-region e autoscaling

Abilitare il failover in base alla capacità con una soglia di overflow del 90% per spostare il carico in eccesso sull’altra region. Configurare l’autoscaling del MIG con un minimo di 4 repliche per region e target di CPU corrispondenti all’utilizzo del LB. Motivazione: Evita i capacity cliff (crolli di capacità) e coordina le decisioni del LB e dell’autoscaler per uno scaling fluido.

Restrizione dell’interfaccia di amministrazione

Creare un HTTP(S) Load Balancer interno per l’hostname dell’amministratore privato, accessibile solo all’interno del VPC. Pubblicare un DNS Cloud split-horizon in modo che i client interni risolvano il VIP dell’ILB e i client esterni ricevano NXDOMAIN. Motivazione: Mantiene il traffico di amministrazione privato e controllato senza esporre endpoint pubblici.

Firewall di backend e sicurezza dell’origine

Assegnare il tag application ai backend di amministrazione e web e aggiungere una regola di allow per tcp:443 dai CIDR aziendali e di staging, più gli intervalli di origine del bilanciatore di carico e degli health check di Google; aggiungere una regola deny-all con logging a priorità più bassa. Motivazione: Garantisce che solo i client previsti e l’infrastruttura di Google possano raggiungere i backend e fornisce visibilità sui drop.

Cloud Armor

Applicare una policy di sicurezza con regole WAF gestite e un limite di frequenza in modalità anteprima per i picchi su /api. Motivazione: La protezione a livello L7 e l’applicazione graduale riducono il rischio durante la fase di ottimizzazione.

Indirizzamento DNS e health check di Cloud DNS

Pubblicare i record A e AAAA per l’hostname della vetrina pubblica verso il VIP anycast dell’ALB. Per un canary blue/green, creare una policy ponderata su un hostname canary designato, suddividendo il 5% del traffico verso l’ALB esclusivo di europe-west1 e il 95% verso l’implementazione globale. Associare health check HTTPS per ritirare il canary se non è integro e impostare il TTL a 20 secondi. Motivazione: Il canary basato su DNS consente un’esposizione graduale con rimozione basata sull’integrità e una rapida convergenza.

Osservabilità

Abilitare i log di LB e CDN; esportarli in BigQuery per l’analisi. Impostare alert sul tasso di errori 5xx, sulla capacità del backend, sui fallimenti degli health check e sul rapporto di hit della CDN. Utilizzare i test della mappa URL e i log delle richieste per diagnosticare errori di routing; ispezionare i picchi di errori 502/503 per individuare saturazione del backend o discrepanze di protocollo. Motivazione: Il monitoraggio proattivo e

← Connettività ibrida · Tutti i domini · Cloud DNS →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →