Google PCA: Costi, prestazioni e design di cloud sostenibile — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Panoramica

Costo, prestazioni e progettazione sostenibile del cloud sono discipline co-ottimizzate. Costruire architetture efficienti su Google Cloud richiede osservabilità finanziaria, capacità elastica che segue la domanda, rigore nel ciclo di vita dei dati, posizionamento e caching informati per le reti e misurazione continua. Questa sezione spiega i pattern di progettazione e operativi che riducono gli sprechi senza sacrificare l’affidabilità, la sicurezza o le prestazioni, ed evidenzia le modalità di fallimento e i compromessi per evitare sorprese costose.

Architettura dei Costi e Responsabilità Finanziaria

Stabilire controlli finanziari come parte della baseline della piattaforma.

• Analisi e allocazione della fatturazione

  • Esportare i dati di fatturazione in BigQuery per un’analisi della spesa interrogabile e quasi in tempo reale per progetto, servizio, SKU ed etichetta. Partizionare per giorno per query scalabili e impostare controlli di accesso al dataset per gli stakeholder dei reparti finanza e ingegneria.
  • Utilizzare budget con soglie di avviso per prevenire la deriva della spesa. Instradare gli avvisi di budget a Pub/Sub e automatizzare le risposte (ad esempio, mettendo in pausa i workload non critici). Tenere presente che gli avvisi non sono transazionali e possono avere ritardi di segnalazione; non fare affidamento su di essi come unico controllo per i job fuori controllo.

• Etichette, tag e attribuzione dei costi

  • Standardizzare le etichette a livello di organizzazione (cost_center, env, owner, app) e imporle al momento del provisioning con template di deployment o policy-as-code.
  • Preferire tag gerarchici e una struttura di cartelle/progetti che rifletta i modelli di chargeback/showback. Utilizzare sia le etichette (a livello di risorsa) sia i tag (ambito di policy e fatturazione) per ottenere un’allocazione precisa.

• Barriere di budget e rilevamento delle anomalie

  • Configurare budget per progetto e per portafoglio; impostare soglie multiple (ad esempio, 50, 80, 100 percento) e avvisi “previsti” (forecasted) per un’azione proattiva.
  • Utilizzare gli insight di Recommender (VM inattive, dischi non collegati, IP, impegni non utilizzati) per eliminare continuamente gli sprechi.

• Esempi pratici

  • Applicare etichette alla creazione:
    • gcloud compute instances create api-1 –labels=env=prod,cost_center=retail,owner=eng
  • Interrogare l’esportazione della fatturazione per la spesa senza etichette per garantire la conformità tramite controlli CI/CD.

Modalità di fallimento e compromessi comuni:

• Etichette incoerenti compromettono l’allocazione dei costi; imporle con policy dell’organizzazione e validazione nelle pipeline.
• La fatturazione centralizzata senza budget per team ostacola la responsabilità; creare budget a livello di team o di prodotto.
• Un avviso di budget ritardato significa che picchi rapidi possono superare il limite; stratificare limiti (cap) e quote dove possibile.

Efficienza e Prestazioni del Calcolo (Compute)

Associare le risorse ai profili di workload; automatizzare l’elasticità; prenotare o scontare il carico di base costante.

• Rightsizing e tipi di macchine personalizzate

  • Analizzare continuamente l’utilizzo di CPU, memoria, IOPS del disco e rete per effettuare il rightsizing. Utilizzare tipi di macchine personalizzate per adattare vCPU e memoria alle reali esigenze dell’app ed evitare di pagare per la memoria inattiva.
  • Prestare attenzione al margine (headroom): puntare a un utilizzo sostenuto della CPU del 60–75% e garantire un margine di memoria sufficiente per la GC o per i picchi. Un rightsizing troppo aggressivo aumenta il rischio di throttling o OOM (Out of Memory).

• Autoscaling e pianificazione del ciclo di vita

  • Utilizzare l’autoscaling dei gruppi di istanze gestite basandosi su segnali pertinenti (CPU, capacità del load balancer o profondità di una coda personalizzata). Configurare periodi di warmup e controlli di scale-in per prevenire il thrashing.
  • Per ambienti non operativi 24/7, pianificare l’avvio/arresto di VM, node pool di GKE o istanze minime di Cloud Run per evitare la spesa per risorse inattive. Un primo semplice passo è usare Cloud Scheduler per attivare un job di Cloud Run che arresti le istanze di sviluppo durante la notte.

• Strumenti di sconto

  • Sconti per utilizzo commesso (CUD): impegnarsi per 1–3 anni per l’utilizzo stazionario idoneo agli impegni. Bilanciare la dimensione dell’impegno con l’utilizzo storico e le previsioni di business; un impegno eccessivo (overcommitting) spreca denaro.
  • VM Spot: ideali per workload tolleranti ai guasti, batch o distribuiti. Possono essere reclamate in qualsiasi momento; implementare il checkpointing e gruppi multi-istanza con fallback on-demand.
    • Esempio: gcloud compute instances create etl-spot –provisioning-model=SPOT
  • Prenotazioni di capacità: prenotare capacità zonale o regionale per flotte critiche per mitigare i fallimenti di scale-up durante le carenze regionali.
    • Esempio: gcloud compute reservations create web-capacity –zone=us-central1-a –machine-type=n2-standard-4 –vm-count=10

• Metriche di utilizzo e ottimizzazione delle prestazioni

  • Strumentare con Cloud Monitoring, Profiler e Trace. Misurare la latenza p50/p95, il CPU steal, il tempo di GC e gli arretrati delle code. Ottimizzare i percorsi di codice critici (hot path) prima di effettuare lo scale out.
  • Vincolare i workload sensibili alle prestazioni a regioni e zone con piattaforme CPU adeguate e considerare dischi permanenti ad alta velocità (throughput) o Hyperdisk dove necessario.

Modalità di fallimento e compromessi:

• L’autoscaling illimitato può superare le quote e gli obiettivi di costo; aumentare preventivamente le quote, impostare un numero massimo di repliche e utilizzare l’autoscaling predittivo per i picchi noti.
• Le VM Spot possono causare un churn parziale della flotta; diversificare le zone e implementare hook di terminazione controllata (graceful).
• Un impegno eccessivo di CUD o prenotazioni sottoutilizzate creano costi irrecuperabili; rivedere gli impegni trimestralmente.

Costo-Prestazioni di Storage, Database e Analytics

Scegliere classi di storage e modelli di capacità dei database che riflettano i pattern di accesso, la conservazione e gli SLO di performance.

• Classi di storage e policy di lifecycle
  • Utilizzare Standard per i dati hot, Nearline per accessi mensili, Coldline per accessi trimestrali e Archive per accessi a lungo termine e poco frequenti. Mantenere dati e risorse di calcolo nella stessa region per evitare costi di egress.
  • Applicare la gestione del ciclo di vita (lifecycle management) per spostare o eliminare oggetti automaticamente. Prestare attenzione alle durate minime di archiviazione e ai costi di recupero; transizioni premature tra classi possono costare più di quanto facciano risparmiare.

  • Esempio di policy di lifecycle (elimina dopo 90 giorni):

undefined

-

undefined

• Trasferimento e archiviazione dei dati

  • L’accesso tra region diverse comporta spesso costi di egress; collocare produttori e consumatori nella stessa area geografica (co-locate). Utilizzare Private Google Access e VPC-SC per un accesso sicuro e attento ai costi alle API di Google. Per gli archivi a lungo termine, evitare recuperi frequenti dalla classe Archive per prevenire costi di recupero elevati.

• Dimensionamento e performance dei database

  • Relazionali: dimensionare per il working set residente in memoria, IOPS e read replica. Abilitare l’aumento automatico dello storage e monitorare il replication lag; scalare verticalmente o partizionare orizzontalmente (sharding) quando il lag minaccia RPO/RTO.
  • NoSQL/time series: utilizzare Bigtable per un’ingestione a throughput elevato e bassa latenza, con un design appropriato della row key per evitare hotspot.

• Controlli dei costi e modelli di capacità di BigQuery

  • On-demand (per TB scansionato): avvio rapido, rischio di picchi di costo. Prenotazioni basate sulla capacità: spesa prevedibile, controllo su concorrenza e throughput. I Flex commitment assorbono i picchi a breve termine.

  • Ottimizzare le query con partizionamento e clustering; richiedere filtri di partizione per prevenire scansioni complete della tabella (full-table scan):

undefined

• Impostare un massimo di byte fatturati per ogni job per limitare la spesa:

undefined

• Utilizzare viste materializzate, cache dei risultati, aggregazioni approssimate ed evitare SELECT * in produzione. Mantenere storage e risorse di calcolo nella stessa region.

Reti, Throughput, Quote e Progettazione Sostenibile

La progettazione del trasferimento dei dati e della concorrenza influenza fortemente i costi e le prestazioni; le scelte di sostenibilità affinano ulteriormente il posizionamento e la pianificazione.

• Egress di rete, traffico tra region, CDN e caching

  • Minimizzare i salti tra region; replicare i dati solo dove la vicinanza all’utente o la conformità lo richiedono. Utilizzare Cloud CDN per servire contenuti statici e dinamici memorizzabili nella cache; ottimizzare le chiavi di cache, i TTL e le URL firmate per ottenere un’elevata percentuale di hit.
  • Mettere in cache vicino ai client (CDN), ai margini del VPC (proxy cache) e all’interno dei servizi (cache in-memory come Memorystore). Attenzione ai dati obsoleti e alle “tempeste di invalidazione” (invalidation storm); definire header cache-control espliciti.

• Misurazione delle prestazioni, test di carico e scalabilità

  • Stabilire gli SLO e misurarli con Cloud Monitoring, Uptime checks, Cloud Trace e Profiler. Monitorare la latenza p95/p99 e i segnali di saturazione.
  • Eseguire test di carico con dati realistici e “think time”. Scaglionare i test per evitare di attivare i limiti di velocità globali; richiedere aumenti di quota temporanei.
  • Scalare il throughput utilizzando repliche orizzontali, code partizionate (sharded), topic partizionati e autoscaler basati su metriche di backlog. Preferire pipeline asincrone dove possibile.

• Quote, concorrenza, limiti di velocità e backpressure

  • Inventariare le quote per servizio per region; implementare un “exponential backoff” con “jitter” lato client per le risposte 429/5xx. Implementare “admission control” e “backpressure” basato su code per proteggere le dipendenze.
  • Ottimizzare il “flow control” di Pub/Sub (massimo numero di messaggi/byte in sospeso), il batching e il parallelismo. In Cloud Run e GKE, dimensionare correttamente la concorrenza per adeguarla a CPU e memoria, prevenendo l’aumento della “tail latency”.

• Progettazione orientata alla sostenibilità

  • Preferire servizi serverless e gestiti con un’elevata utilizzazione. Scegliere region con percentuali più elevate di energia a zero emissioni di carbonio quando la latenza e la conformità lo consentono.
  • Pianificare i job batch e flessibili durante le finestre a bassa emissione di carbonio; utilizzare i report di Carbon Footprint per monitorare l’impatto.
  • Utilizzare tipi di macchine ad alta efficienza energetica e considerare l’uso di elaborazione basata su ARM, dove compatibile, per migliorare le prestazioni per watt.

• Governance che bilancia affidabilità, sicurezza, prestazioni e costi

  • Definire “guardrail” architetturali: etichette obbligatorie, avvisi di budget, policy organizzative (ad esempio, limitare gli IP esterni), SLO/error budget e SLO di costo.
  • Condurre revisioni periodiche dei costi e delle prestazioni con i team di ingegneria, sicurezza e finanza. Integrare Recommender e dashboard personalizzate; creare “runbook” di remediation.
  • Bilanciare esplicitamente i compromessi: multi-region vs. regional (durabilità e latenza vs. costi ed egress), livelli di crittografia e ispezione (sicurezza vs. CPU e latenza) e autoscaling aggressivo (prestazioni vs. rischio di superamento di quote e spesa).

Modalità di fallimento tipiche e compromessi:

• L’analisi cross-region su un set di dati single-region genera un egress sostenuto; replicare o riposizionare il compute.
• Una configurazione errata della CDN produce basse percentuali di hit; monitorare gli hit della cache e l’egress dall’origine per validare i risparmi.
• La mancanza di backpressure durante interruzioni parziali amplifica il fallimento; implementare “circuit breaker” e ridurre il carico (“shed load”) in modo controllato.

Scenario Pratico

Acme Learn, un’azienda di formazione online, sperimenta picchi serali imprevedibili durante gli eventi dal vivo. I costi aumentano bruscamente a causa di query BigQuery cross-region, picchi di autoscaling ed egress da asset statici. La direzione vuole anche ridurre l’impatto ambientale (carbon impact) senza degradare l’esperienza utente.

Approccio:

1. Consolidare la visibilità della fatturazione e imporre l’allocazione dei costi

   • Creare un’esportazione della fatturazione su BigQuery e dashboard segmentate per prodotto, ambiente e region utilizzando etichette e tag standardizzati nei template di deployment.
   • Razionale: La visibilità quasi in tempo reale collega la spesa ai team responsabili, consentendo la responsabilità di budget. Le etichette permettono un “chargeback” granulare e il rilevamento di anomalie.

2. Riprogettare l’analytics per co-localizzare compute e storage

   • Spostare i set di dati di analytics degli eventi e le query pianificate nella stessa region dei processori di stream. Per BigQuery, far passare i team ad alto volume dal modello on-demand a prenotazioni di capacità (capacity reservation) dimensionate per la concorrenza di picco con un piccolo buffer di flessibilità.
   • Razionale: La co-localizzazione elimina l’egress tra region. Il modello basato sulla capacità di BigQuery stabilizza i costi sotto carico preservando le prestazioni.

3. Ottimizzare la distribuzione dei contenuti con il caching perimetrale (edge)

   • Servire gli asset statici e semi-dinamici delle lezioni tramite Cloud CDN, impostando header cache-control espliciti e URL firmate per i contenuti premium. Ottimizzare i TTL in base alla mutabilità dei contenuti.
   • Razionale: Elevate percentuali di hit della cache spostano il traffico dalle origini al perimetro (edge), riducendo l’egress e il carico di calcolo sull’origine e migliorando la latenza durante i picchi.

4. Rinforzare l’autoscaling e le prenotazioni per gli eventi dal vivo

   • Aggiungere un “managed instance group” regionale per il livello API con target di autoscaler sia sulla CPU che sul backlog delle richieste. Creare una piccola prenotazione di capacità (capacity reservation) zonale per garantire un margine di “burst” durante gli eventi. Abilitare l’autoscaling predittivo prima delle sessioni pianificate.
   • Razionale: L’autoscaling a doppio segnale reagisce sia all’utilizzo che alla domanda, mentre le prenotazioni e il “warm-up” predittivo evitano la latenza da “cold start” e le carenze di capacità.

5. Applicare un mix di compute: carico di base su “commitment”, picchi su “spot”

   • Acquistare “commitment” di 1 anno per i carichi di lavoro di base dell’API e dell’elaborazione dati. Configurare i job batch di transcodifica e arricchimento su Spot VMs con checkpointing e “instance group” multi-zona.
   • Razionale: I “commitment” riducono i costi dello stato stazionario; le Spot VM forniscono elasticità a basso costo per lavori interrompibili senza rischiare il traffico degli utenti.

6. Istituire un ciclo di vita dello storage e un posizionamento regionale

   • Mantenere i metadati e le anteprime dei corsi (“hot data”) in storage di classe Standard regionale, vicino al compute che li serve. Transizionare i log e i clickstream grezzi a Nearline dopo 30 giorni ed eliminarli dopo 180 giorni. Per gli archivi di conformità, utilizzare la classe Archive con SLA di recupero documentati.
   • Razionale: Allinea la classe di storage ai pattern di accesso, riducendo i costi correnti nel rispetto dei requisiti di conservazione.

7. Imporre “guardrail” sull’uso di BigQuery

   • Richiedere filtri di partizione su tabelle di grandi dimensioni e impostare valori predefiniti a livello di progetto per il massimo numero di byte fatturati per job. Introdurre viste materializzate per aggregati comuni e pattern di ingestione partizionati.
   • Razionale: Previene scansioni complete accidentali, stabilizza la spesa e accelera le query frequenti.

8. Progettare per il throughput con backpressure e quote

   • Integrare Cloud Tasks per i flussi di lavoro a velocità limitata e configurare i sottoscrittori di Pub/Sub con il “flow control”. Implementare “exponential backoff” con “jitter” per le API di terze parti e impostare limiti massimi di concorrenza per servizio in Cloud Run.
   • Razionale: Controlla la domanda per rispettare le quote, protegge le dipendenze durante i picchi ed evita fallimenti a cascata.

9. Incorporare la sostenibilità nelle operazioni

   • Preferire il serverless dove possibile, selezionare region con maggiore disponibilità di energia a zero emissioni di carbonio per l’analytics e pianificare i job batch non urgenti durante le finestre a bassa emissione di carbonio. Monitorare le emissioni con Carbon Footprint e includerle nelle revisioni trimestrali.
   • Razionale: Migliora le prestazioni per watt e riduce l’impatto ambientale con compromessi minimi per l’utente finale.

10. Governare con continuità

    • Creare budget e avvisi per prodotto, imporre l’uso di etichette tramite policy e stabilire revisioni mensili di costo-prestazioni-SLO. Automatizzare la pulizia delle risorse inattive e dei dischi non collegati basata su Recommender.
    • Razionale: Una governance continua mantiene i benefici ottenuti, previene le regressioni e bilancia nel tempo affidabilità, sicurezza, prestazioni e costi.

Questo progetto riduce l’egress, stabilizza i costi di analytics, garantisce prestazioni prevedibili durante gli eventi dal vivo e promuove gli obiettivi di sostenibilità senza compromettere l’esperienza utente.

← DevOps · Tutti i domini

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

Sfoglia Google →