Scegliere il load balancer giusto

In Cloud Load Balancing la prima domanda dell’esame è sempre la stessa: interno o esterno, regionale o globale, e a quale livello operi. La combinazione determina il prodotto. Per traffico HTTP(S) con routing content-based scegli l’Application Load Balancer (L7): l’external global ALB usa il Premium network tier con anycast IP e termina TLS all’edge; esiste anche la variante regionale (external o internal) quando serve mantenere il traffico in una regione per data residency o latenza controllata. Per L4 hai due famiglie distinte: il proxy Network Load Balancer (TCP/SSL proxy, termina la connessione e la riapre verso il backend, utile per IP anycast globale su protocolli non-HTTP) e il passthrough Network Load Balancer (L4, non termina nulla: preserva l’IP client e inoltra il pacchetto così com’è). Regola d’oro: se il backend deve vedere l’IP sorgente reale o gestire protocolli arbitrari, è passthrough; se serve offload TLS o routing per URL, è Application LB.

Backend, health check e affinità

Il backend service è il cuore della configurazione. I backend possibili sono managed instance group (MIG) — con autoscaling e autohealing — oppure network endpoint group (NEG): zonal NEG per singoli endpoint GCE, serverless NEG per Cloud Run/App Engine/Functions, internet NEG per origini esterne, e Private Service Connect NEG. Ogni backend service richiede un health check coerente col protocollo servito, altrimenti gli endpoint restano marcati unhealthy e non ricevono traffico. La session affinity (client IP, cookie generato, header) forza uno stesso client sullo stesso backend, ma ricordare il trade-off: rompe la distribuzione uniforme del carico. Il global access su un internal Application/Network LB consente ai client di altre regioni della stessa VPC di raggiungerlo. Su GKE, l’esposizione avviene tramite Gateway API o Ingress, che provisionano dietro le quinte un ALB con NEG.

Traffic management e Cloud CDN

Sull’external Application Load Balancer la URL map abilita il traffic management avanzato: traffic splitting (canary/blue-green pesato tra backend service), traffic mirroring (copia ombra verso un backend per test senza impattare la risposta al client) e URL rewrite/redirect sul path o host. Cloud CDN si attiva sul backend service dell’external Application LB e mette in cache i contenuti ai point of presence Google. Le origini supportate sono MIG, Cloud Storage bucket, Cloud Run e internet NEG. La cache si governa con cache mode e TTL, e i contenuti obsoleti si rimuovono con l’invalidation (operazione lato pattern, non istantanea né sostitutiva di un buon TTL/versioning degli asset). Cloud CDN richiede un external Application LB come frontend: non esiste come servizio standalone.

Cloud DNS

Cloud DNS offre zone public (risoluzione da Internet) e private (visibili solo alle VPC autorizzate). Le routing policy aggiungono logica alla risposta: geolocation (indirizza in base alla regione del client), weighted round robin e failover (record primario/backup con health check). DNSSEC si abilita sulle public zone per firmare le risposte e prevenire spoofing. Il DNS forwarding inoltra query verso resolver on-prem (outbound) o riceve query da on-prem (inbound) tramite forwarding zone e server policy. Lo split-horizon serve la stessa hostname con risposte diverse a client interni vs esterni usando una private e una public zone omonime. Per condividere zone tra progetti usi cross-project binding (una private zone associata a VPC di più progetti) e il DNS peering (una VPC delega la risoluzione di un namespace a un’altra VPC producer).

Trappole tipiche d’esame

  • Il backend deve vedere l’IP client reale → passthrough Network LB: il proxy NLB e l’Application LB sostituiscono l’IP sorgente; solo il passthrough L4 preserva l’IP originale del client.
  • Routing per path/host o offload TLS su L7 → Application Load Balancer, non Network LB: URL map, URL rewrite e traffic splitting esistono solo sull’ALB; il Network LB opera a L4 e non ispeziona l’URL.
  • Cache all’edge richiesta → Cloud CDN dietro external Application LB: Cloud CDN non è attivabile su un Network LB né come servizio isolato; serve sempre l’ALB esterno come frontend.
  • Contenuto aggiornato ma ancora servito vecchio → invalidation + TTL/versioning: l’invalidation ripulisce la cache ma non è immediata; la soluzione robusta abbina cache-control corretti e asset versionati.
  • Stessa hostname, risposte diverse interno/esterno → split-horizon con private + public zone: una sola zona non basta; servono due zone omonime, una privata per la VPC e una pubblica per Internet.
  • Deviare traffico verso un backend per test senza impattare i client → traffic mirroring, non splitting: lo splitting sposta quote reali di traffico (canary), il mirroring invia una copia ombra e scarta la risposta.
  • Failover DNS automatico su endpoint down → routing policy failover con health check: un semplice record A multiplo fa round robin ma non rileva l’endpoint guasto; serve la policy failover.