Google PCD: Prestazioni, scalabilità e ingegneria della resilienza — Guida allo studio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Panoramica

L’ingegneria delle prestazioni, della scalabilità e della resilienza su Google Cloud si concentra sul mantenimento di un servizio a bassa latenza e conveniente in termini di costi sotto un carico variabile, tollerando al contempo i guasti senza violare gli SLO. La progettazione deve allineare i segnali di autoscaling con le caratteristiche del carico di lavoro, posizionare dati e risorse di calcolo per minimizzare la latenza di coda (tail latency) e implementare controlli per il sovraccarico, tentativi (retry) e failover per evitare guasti a cascata. Questa sezione dettaglia i pattern, i controlli e i compromessi (trade-off) importanti per gli sviluppatori di applicazioni a livello di calcolo, rete e dati.

Scalabilità e Distribuzione del Carico

Scalabilità orizzontale e verticale

La scalabilità orizzontale aggiunge istanze o pod per aumentare la capacità e la resilienza. Da preferire per servizi stateless e quando è necessaria un’elasticità rapida. Utilizzare Managed Instance Groups (MIGs), revisioni di Cloud Run o Deployment di GKE.
La scalabilità verticale aumenta le dimensioni della macchina. Utile per carichi di lavoro single-threaded o con limiti di memoria (memory-bound), o per ridurre il coordinamento tra nodi, ma offre un margine di crescita limitato e tempi di riavvio più lunghi.
Concorrenza: Ottimizzare la concorrenza delle richieste per allinearla ai profili CPU-bound o I/O-bound. Cloud Run supporta la concorrenza per revisione; i pod GKE possono servire più richieste se il runtime non è bloccante; per un isolamento rigoroso, impostare la concorrenza a 1.

Segnali di autoscaling e capacità a caldo (warm capacity)

L’autoscaling dei MIG supporta l’utilizzo della CPU, l’utilizzo del bilanciamento del carico e metriche personalizzate tramite Cloud Monitoring. Per traffico con picchi improvvisi (bursty), basare la scalabilità su metriche di richiesta (rps, profondità della coda) piuttosto che sulla CPU.
L’Horizontal Pod Autoscaler (HPA) di GKE può scalare in base a CPU, memoria o metriche personalizzate/esterne (es. lunghezza della coda di Pub/Sub). Utilizzare il Vertical Pod Autoscaler (VPA) per il right-sizing, ma evitare gli aggiornamenti live del VPA su frontend che scalano rapidamente per prevenire il churn (avvicendamento dei pod).
Cloud Run scala in base al carico di richieste concorrenti e, opzionalmente, a metriche personalizzate. Evitare i cold start mantenendo una capacità a caldo (warm capacity): configurare istanze minime, mantenere bassa la concorrenza inattiva (idle) e pre-riscaldare tramite ping di health check sintetici, se necessario.
L’autoscaling predittivo nei MIG e l’impostazione di repliche minime su Deployment/Revision aiutano a mascherare la latenza di provisioning durante i picchi diurni.

Bilanciamento del carico, distribuzione globale del traffico, health check e failover

Utilizzare l’Application Load Balancer esterno globale per VIP anycast a livello mondiale, HTTP/2 e HTTP/3, e terminazione all’edge con Cloud CDN. I backend possono essere gruppi di istanze, NEG di zona/regionali, NEG serverless (Cloud Run/Functions) o GKE Ingress.
Gli health check allontanano il traffico dai backend non integri (unhealthy). Assicurarsi che gli endpoint di health check convalidino le dipendenze in modo ristretto (es. processo e risorse locali critiche) per evitare guasti circolari in caso di interruzioni a valle (downstream).
Le allowlist del firewall devono consentire gli health checker. Se i controlli sulla porta 80 falliscono, consentire gli intervalli di Google:

undefined

Failover: Configurare servizi di backend primari/di backup o policy di traffico che indirizzano verso regioni alternative in caso di fallimento dell’health check. Per il failover a livello DNS, utilizzare le policy di Cloud DNS con health check per endpoint non HTTP.

Latenza ed Efficienza

Budget di latenza

Allocare il budget di latenza end-to-end per ogni livello (client, edge, applicazione, dati). Monitorare p95/p99, non le medie. Utilizzare Cloud Trace per trovare i fattori che contribuiscono alla latenza tra i servizi e il blocco head-of-line. Applicare delle scadenze (deadline) alle chiamate RPC in modo che la cancellazione a monte (upstream) liberi capacità.

Utilizzo di cache e CDN

Cache a più livelli: cache del client/browser, edge della CDN (Cloud CDN) e cache regionali/in memoria (Memorystore o in-process). Scegliere attentamente le chiavi di cache e gli header Vary. Impostare i TTL in base all’aggiornamento dei dati e al rischio di obsolescenza (staleness); considerare la cache negativa per i 404 quando è sicuro.
Servire gli asset statici da Cloud Storage tramite Cloud CDN per ridurre il carico sull’origine e la latenza di coda. Utilizzare URL/header firmati per un accesso controllato.

Riutilizzo delle connessioni

Preferire HTTP/2 o gRPC per il multiplexing e la compressione degli header. Abilitare i keep-alive e il connection pooling per ridurre l’overhead dell’handshake. Monitorare l’esaurimento delle porte NAT; ottimizzare i pool di connessioni del client e i timeout di inattività (idle), e dimensionare le porte di Cloud NAT per VM, se applicabile.

Efficienza del payload

Utilizzare codifiche binarie (es. protobuf) e comprimere i payload di testo (gzip/brotli) al di sopra di una soglia di dimensione. Progettare attentamente i campi di richiesta/risposta; impaginare, filtrare lato server ed evitare il recupero di dati in eccesso (over-fetching). Utilizzare ETags e richieste condizionali (If-None-Match) per evitare trasferimenti ridondanti. Per Cloud Storage, utilizzare le precondizioni di generazione e le letture Range per contenuti parziali.

Pattern di sovraccarico e resilienza

Limitazione della frequenza, contropressione, accodamento e batching

Applicare limiti di frequenza (rate limit) a livello di edge (Cloud Armor per la limitazione della frequenza basata su IP/geolocalizzazione/servizio) e a livello di API (quote di Apigee, token per client API). Implementare algoritmi token-bucket o leaky-bucket lato server per una condivisione equa.
Contropressione: Non superare la capacità dei sistemi a valle. Utilizzare code (Pub/Sub per eventi at-least-once; Cloud Tasks per limiti per coda e per target con pianificazione e tentativi di ripetizione). Propagare errori 429 Too Many Requests o 503 con Retry-After per respingere i client.
Il batching può aumentare il throughput e ridurre l’overhead per chiamata (ad es. mutazioni batch su database o conferme batch in Pub/Sub), scambiando una maggiore latenza con una maggiore efficienza. Ottimizzare la dimensione del batch e il tempo massimo di attesa.

Protezione dal sovraccarico

Applicare timeout e deadline a ogni RPC. Usare i circuit breaker per interrompere l’invio di lavoro a dipendenze malfunzionanti e abilitare fallback rapidi. Implementare il load shedding basato sulla profondità della coda, sulla CPU o sulla violazione degli SLO di latenza per proteggere le funzionalità principali.

Tentativi resilienti, backoff esponenziale, jitter, idempotenza e gestione dei duplicati

Ripetere il tentativo solo quando è sicuro: timeout di rete, errori 5xx o codici di errore documentati come ritentabili (es. Cloud Storage 429/5xx). Non ripetere mai il tentativo per errori 4xx come 400/401/403, a meno che non sia specificato.
Utilizzare il backoff esponenziale troncato con jitter per evitare tentativi di ripetizione sincronizzati. Preferire il full jitter. Esempio:

undefined

Garantire l’idempotenza. Utilizzare chiavi di idempotenza (ad es. un ID operazione univoco) e operazioni di upsert/scritture condizionali per tollerare i duplicati. Per Pub/Sub, deduplicare usando il messageId o chiavi applicative; progettare i gestori (handler) in modo che siano sicuri per una consegna at-least-once. Per le scritture su Cloud Storage, usare precondizioni generation-match per evitare sovrascritture.

Ramp-up di risorse inattive

Alcuni servizi applicano limiti adattivi. Per Cloud Storage, aumentare gradualmente la frequenza delle richieste su bucket precedentemente inattivi per ridurre errori 429/5xx transitori durante picchi improvvisi. Limitare i producer e “riscaldare” i bucket con traffico controllato prima del carico completo.

Alta Disponibilità, Dati, DR e Test

Multi-zona, regionale, multi-regionale; attivo-attivo vs attivo-passivo

Eseguire il deploy su più domini di errore. Utilizzare MIG regionali o cluster GKE regionali per la tolleranza ai guasti di zona. Per i servizi globali, usare più region con il load balancer globale.
L’approccio attivo-attivo riduce RTO e latenza, ma richiede dati senza conflitti e un’attenta gestione della coerenza. L’approccio attivo-passivo semplifica la semantica di scrittura ma comporta un RTO più elevato e una potenziale capacità a freddo.

RTO, RPO, backup, ripristino e test di disaster recovery

Definire l’RTO (tempo per ripristinare il servizio) e l’RPO (perdita di dati tollerabile) per ogni workload. Mapparli alle capacità della piattaforma:
- Cloud Spanner: multi-regionale con disponibilità al 99,999% (cinque 9) e replica sincrona per un RPO quasi nullo.
- Cloud SQL: Alta Disponibilità all’interno della region; usare repliche cross-region per il DR, abilitare il PITR e convalidare i runbook di failover/failback.
- Firestore e Bigtable offrono opzioni regionali e multi-regionali; scegliere in base ai requisiti di RTO/RPO.
- I bucket Cloud Storage dual-region o multi-region forniscono geo-ridondanza; verificare le procedure di ripristino e la riemissione di URL firmati.
Testare il DR: Eseguire regolarmente esercitazioni di failover. Convalidare i backup ripristinandoli in un ambiente isolato, provare il failover del DNS/traffico e misurare l’RTO/RPO effettivi.

Prestazioni di database e storage, progettazione degli indici, hot key e contesa

Cloud Spanner: Evitare chiavi primarie a incremento monotono che creano hotspot. Usare tabelle interleaved per la località, indici secondari per i pattern di lettura e transazioni limitate per ridurre i conflitti di lock. Dimensionare i nodi per QPS e storage; mantenere almeno tre nodi per il quorum di produzione e per avere margine.
Cloud SQL: Analizzare le query, aggiungere indici di copertura, evitare transazioni lunghe e usare pool di connessioni. Ottimizzare con giudizio le impostazioni di InnoDB o Postgres; scalare le repliche di lettura per workload con carichi di lettura elevati.
Bigtable: Progettare le chiavi di riga (row key) per distribuire uniformemente il carico (tramite salting o inversione dei campi). Usare il routing multi-cluster per l’alta disponibilità tra le region, se disponibile.
Firestore: Usare indici composti per query su più campi; essere consapevoli dell

← Osservabilità · Tutti i domini · Test →

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