Google PCA: Compute, piattaforme applicative e architettura dei carichi di lavoro — 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

Questo dominio copre come selezionare e progettare piattaforme di calcolo su Google Cloud, come pacchettizzare e distribuire applicazioni e come gestire i carichi di lavoro per garantire affidabilità, prestazioni, sicurezza ed efficienza dei costi. Comprende macchine virtuali, Kubernetes, runtime serverless, bilanciamento del carico, strategie di rollout, calcolo stateful e specializzato e pattern di modernizzazione che riducono il debito tecnico soddisfacendo al contempo la domanda mutevole.

Compute Engine e architetture basate su VM

Compute Engine fornisce un controllo granulare su sistemi operativi, networking e tipi di macchine. Scegli le famiglie di macchine in base alle caratteristiche del carico di lavoro:

E2: per uso generico ottimizzate per i costi; adatte per sviluppo/test, applicazioni con picchi di carico.
N2/N2D: rapporto prezzo/prestazioni bilanciato per la maggior parte dei carichi di lavoro di produzione; N2D utilizza CPU AMD con un’elevata larghezza di banda della memoria.
C2/C2D/C3: ottimizzate per il calcolo per attività legate alla CPU (CPU-bound) (es. API con elevato numero di QPS, calcolo batch).
M3: ottimizzate per la memoria per grandi set di dati in-memory (cache, analisi in-memory).
A3: ottimizzate per GPU (NVIDIA) per training/inferenza; è anche possibile collegare GPU ad altre famiglie.
Confidential VMs (su CPU supportate) crittografano i dati in uso con modifiche minime al codice.

I gruppi di istanze gestite (MIG) apportano elasticità e resilienza:

Usa gli Instance Template per una configurazione immutabile e i MIG per scalare orizzontalmente tra le zone.
Policy di scalabilità automatica: utilizzo della CPU, utilizzo del bilanciatore di carico, metriche di Cloud Monitoring o profondità della coda tramite metriche personalizzate. Imposta repliche minime/massime e un periodo di cooldown per evitare il thrashing (sovraccarico) in presenza di carichi con picchi.
Gli aggiornamenti continui (rolling update) e i canary riducono il rischio; mantieni conservative le impostazioni di surge (picco) e indisponibilità per servizi stateful o con avvii a freddo (cold-start) pesanti.

Bilanciamento del carico e health check:

Il bilanciatore di carico HTTP(S) esterno globale termina la connessione TLS, supporta la mappatura degli URL ed è il front-end standard per le API web; il bilanciatore di carico HTTP(S) interno è per il traffico est-ovest.
Gli health check devono raggiungere i backend. Un errore comune è il blocco delle probe, che causa riavvii continui delle istanze e una perdita di traffico. Consenti gli intervalli di origine degli health check verso le porte dei backend con regole firewall VPC e tag di destinazione.

Esempio per consentire gli health check HTTP a un MIG:

undefined

Considerazioni sul ciclo di vita delle VM:

Usa script di avvio o metadati dell’immagine per il bootstrap; archivia la configurazione di runtime in Secret Manager, non incorporarla (baked) nelle immagini.
Per le VM prerilasciabili/Spot, aggiungi uno shutdown-script per completare il lavoro in corso (drain) alla notifica di terminazione.
Applica le patch tramite immagini pre-configurate (baked) e sostituzione continua (rolling replacement) per evitare la deriva della configurazione (configuration drift).
Il ridimensionamento dei dischi permanenti è online: aumenta la dimensione del disco, quindi espandi il filesystem (es. resize2fs su ext4) con tempi di inattività minimi.

Esempio di ridimensionamento di un PD:

undefined

Identità sicura e osservabilità:

Associa service account con il principio del privilegio minimo (least-privilege) alle istanze; non incorporare credenziali statiche.
Installa l’Ops Agent per Cloud Logging e Cloud Monitoring. Usa Cloud Trace e Cloud Profiler per ridurre la latenza di coda (tail latency) e gli hot spot.
Esporta i dati di audit e le metriche su BigQuery o Cloud Storage per la conservazione e l’analisi a lungo termine.

Calcolo batch e specializzato:

Usa Cloud Batch o MIG con VM prerilasciabili per l’elaborazione batch tollerante ai guasti per ridurre i costi; implementa il checkpointing.
Collega GPU/TPU dove è necessaria l’accelerazione ML. Usa node pool dedicati o nodi single-tenant per soddisfare i requisiti di conformità/isolamento.
Le Confidential VMs proteggono i dati sensibili in memoria; misura l’overhead rispetto ai requisiti.

Considerazioni sullo stato (state):

Mantenere le istanze dell’applicazione stateless; esternalizzare le sessioni in uno store condiviso (es. Memorystore, Cloud SQL) per evitare anomalie visibili all’utente durante la scalabilità.
Per lo stato legato alla VM, utilizzare dischi permanenti a livello di regione o database replicati; testare i percorsi di failover.

Kubernetes e Piattaforme di Container (GKE)

GKE fornisce un piano di controllo gestito con pool di nodi worker flessibili:

I cluster regionali replicano il piano di controllo e i nodi tra più zone per l’alta disponibilità; i cluster zonali concentrano le risorse per un costo inferiore e per i carichi sensibili alla latenza.
Utilizzare più pool di nodi per segmentare i carichi di lavoro (es. general purpose, GPU, high-memory, spot). Applicare taints/tolerations e affinity/anti-affinity per controllare il posizionamento e ridurre gli effetti “noisy-neighbor”.
Livelli di autoscaling: il cluster autoscaler aggiunge/rimuove nodi; l’Horizontal Pod Autoscaler (HPA) scala le repliche in base a CPU/metriche personalizzate; il Vertical Pod Autoscaler (VPA) dimensiona correttamente le richieste (requests). Combinare l’HPA con il cluster autoscaler per l’elasticità.

Pianificazione dei carichi di lavoro e servizi:

Dimensionare correttamente le richieste (requests) e i limiti (limits) di CPU/memoria per minimizzare il rischio di eviction e massimizzare l’efficienza del binpacking.
Usare i PodDisruptionBudgets per preservare la disponibilità durante gli aggiornamenti.
Tipi di Service: ClusterIP (interno al cluster), NodePort/LoadBalancer (traffico north-south) e Ingress per il routing HTTP(S) con il LB globale. Per i rilasci canary, dirigere il traffico tramite backend di Service/Ingress separati o un service mesh.

Aggiornamenti e resilienza:

Utilizzare gli aggiornamenti surge e maxUnavailable per controllare il “churn”; vincolare i carichi di lavoro critici a più zone e pool.
Impostare finestre/esclusioni di manutenzione per i periodi critici per il business.
Validare con un ambiente di pre-produzione e pool di nodi canary prima di un rollout su larga scala.

Immagini e sicurezza:

Archiviare le immagini dei container in Artifact Registry; abilitare la scansione delle vulnerabilità e configurare la binary authorization o le attestations per la provenienza.
Usare Workload Identity per mappare GSA a KSA per un accesso senza credenziali e con privilegio minimo alle API di Google.
Ottenere la configurazione a runtime da Secret Manager tramite il driver CSI; evitare i Kubernetes Secrets per valori altamente sensibili, a meno che non siano crittografati con CMEK e l’RBAC sia restrittivo.

Rollout e rollback:

Preferire i rolling update dei Deployment con piccoli step e health probe; per sistemi a bassa tolleranza, usare una strategia blue-green tramite due Deployment dietro un unico Service e scambiare le etichette/il selettore.
Definire sempre probe di readiness e liveness; probe mal configurati causano riavvii a cascata o blackhole di traffico durante i rollout.

Piattaforme Serverless ed Event-Driven

Il serverless di Google Cloud astrae l’infrastruttura fornendo al contempo controlli robusti su scalabilità, sicurezza e costi:

Cloud Run: container-native, attivato da richieste HTTP o da Eventarc. Scala fino a zero; concorrenza configurabile; suddivisione del traffico per revisione per canary e rollback. Impostare un numero minimo di istanze (min instances) per ridurre i cold start per endpoint sensibili alla latenza. Si integra con la VPC tramite Serverless VPC Access per l’egress privato.
App Engine: PaaS “opinionated”. L’ambiente Standard offre scalabilità rapida e vincoli di concorrenza per richiesta specifici per linguaggio; l’ambiente Flexible esegue container su VM con maggiore controllo. Evitare lo stato di sessione locale all’istanza; esternalizzarlo su uno storage condiviso per prevenire esperienze utente obsolete o duplicate sotto carico.
Cloud Functions: granularità a livello di funzione per la logica event-driven. Utilizzare trigger da Pub/Sub, Cloud Storage o Eventarc per micro-operazioni leggere; mantenere le funzioni idempotenti e stateless. Per pipeline combinate batch/stream senza codice preesistente, Dataflow fornisce un’elaborazione unificata con autoscaling.

Compromessi nella scelta della piattaforma:

Controllo operativo: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Portabilità: basata su container (GKE/Cloud Run/App Engine Flex) > immagini VM > funzioni e App Engine Standard.
Latenza: Cloud Run con istanze minime (min instances) o GKE per una bassa latenza di coda (tail latency); evitare i cold start per carichi di lavoro interattivi.
Scalabilità: Cloud Functions/Run scalano più velocemente; GKE HPA più cluster autoscaler; i MIG richiedono warm-up e health check.
Costo: serverless pay-per-use per carichi con picchi/basso stato stazionario; GKE/VM con sconti per uso continuativo (committed use discounts) per servizi stabili ad alto throughput; istanze preemptible/Spot per elaborazioni batch.

Identità e configurazione:

Ogni servizio dovrebbe utilizzare un service account dedicato con il privilegio minimo. Per Cloud Run e Functions, impostare esplicitamente il service account di runtime.
Archiviare i segreti in Secret Manager e associare l’accesso tramite IAM; iniettarli tramite variabili d’ambiente o mount di volumi.

Pattern di architettura, delivery e operations

Decomposizione e confini dei servizi:

Monolito: la più semplice implementazione e gestione delle transazioni, ma limita la scalabilità indipendente e il controllo del blast-radius; può mascherare problemi di performance in profondità nelle catene di chiamate.
Monolito modulare: moduli interni chiari, processo condiviso; un buon passo intermedio: impone l’uso di interfacce senza gli svantaggi della distribuzione.
Microservizi: scalabilità e deployment indipendenti; introduce latenza di rete, transazioni distribuite e sfide di consistenza. Definire chiari bounded context e proprietà dei dati; evitare database condivisi per prevenire l’accoppiamento.

Pattern di modernizzazione:

Strangler-fig: instradare in modo incrementale una parte del traffico verso i nuovi componenti, ritirando gradualmente gli endpoint legacy.
Lift and shift: containerizzare o migrare le VM prima per stabilizzare, poi effettuare il refactoring.
Anti-corruption layer/facade: isolare i contratti legacy mentre si costruiscono nuovi servizi.
Dare la priorità ai domini ad alta frequenza di modifica e ad alta frizione per massimizzare il valore di business e ridurre il rischio.

Delivery e rollout:

La CI/CD con test automatizzati e ambienti di staging riduce i rollback. Aggiungere canary analysis, error budget e progressive delivery.
Blue-green minimizza i tempi di inattività e semplifica il rollback al costo di una capacità doppia.
Suddivisione del traffico: Cloud Run/App Engine supportano il routing basato su percentuale tra revisioni/versioni; testare con traffico reale e SLO error budget restrittivi.

Bilanciamento del carico e health check:

Utilizzare un L7 globale per HTTP e un proxy TCP per protocolli non-HTTP; LB interni per servizi privati. Configurare la session affinity solo quando necessario ed esternalizzare lo stato della sessione.
Gli health check dovrebbero riflettere la disponibilità dell’app (es. l’integrità delle dipendenze); un semplice 200 OK che maschera un guasto del datastore può causare un instradamento errato del traffico.

Osservabilità e governance:

Strumentare i trace per l’attribuzione della latenza end-to-end tra i servizi; abilitare il logging dei request ID per correlare log e trace.
Esportare log/metriche/audit trail su BigQuery o Cloud Storage per esigenze di retention e audit; proteggere l’accesso tramite viste e IAM.
Per i log delle VM, installare l’Ops Agent; definire la retention e i sink per controllare costi e conformità.

Catena di fornitura software sicura:

Utilizzare Artifact Registry con la scansione; mantenere le immagini minimali. Ottimizzare i Dockerfile: preferire basi slim, installare prima le dipendenze, poi copiare il codice sorgente per sfruttare la cache di build.

Networking e segmentazione:

Imporre l’accesso a livelli tramite tag e regole del firewall VPC per consentire solo i flussi previsti (es. web → API → DB). Negare l’accesso diretto web → DB.

Capacità, prestazioni e calcolo specializzato

Progettare per una domanda variabile:

GCE: scalabilità automatica dei MIG basata su indicatori anticipatori (lunghezza della coda) per prevenire la saturazione della CPU; aggiungere limitazione della frequenza delle richieste e backpressure per proteggere i sistemi a valle.
GKE: combinare l’HPA basato su richieste al secondo o metriche personalizzate con il cluster autoscaler; predisporre un piccolo buffer per evitare ritardi nella scalabilità.
Serverless: regolare la concorrenza e le istanze minime per bilanciare costi e latenza; utilizzare un deployment regionale per una latenza vicina all’utente.

Resilienza e test:

Eseguire carichi sintetici per convalidare la scalabilità automatica e gli SLO; includere test di chaos (ad es., terminando istanze/pod casuali) per garantire che il sistema mantenga la disponibilità durante guasti e aggiornamenti.
Configurare PodDisruptionBudgets e hook di terminazione graceful per drenare le connessioni prima dell’arresto di pod/VM.

Prestazioni e selezione dello storage:

L’ingestione di serie temporali e clickstream ad alta velocità e bassa latenza si adatta bene a Bigtable; progettare righe ampie e chiavi raggruppate per intervalli di tempo (time-bucketed) per evitare hotspot.
Per Spark/Hadoop con modifiche operative minime, utilizzare Dataproc; dimensionare correttamente i cluster con la scalabilità automatica.
Per l’elaborazione combinata batch oraria e streaming senza codice preesistente, utilizzare Dataflow con scalabilità automatica e windowing per unificare le pipeline.

Spostamento dei dati e connettività:

Per la replica privata, sostenuta e ad alta larghezza di banda (ad es., database multi-terabyte), considerare Dedicated Interconnect; utilizzare VLAN attachment e Cloud Router per il routing dinamico. Per esigenze ad hoc o con throughput inferiore, è sufficiente Cloud VPN.

Workload stateful:

Su GKE, utilizzare StatefulSet con volumi persistenti (PD regionali per l’HA) e identità ordinate e stabili; considerare Filestore per la semantica NFS.
Utilizzare database gestiti (Cloud SQL, AlloyDB, Spanner) per durabilità e scalabilità ove possibile; pianificare repliche di lettura e failover.

Sicurezza e conformità:

Considerare le Confidential VM per proteggere i dati in uso con un impatto limitato sulle prestazioni; valutare in base ai requisiti del workload.
Utilizzare CMEK dove le chiavi devono essere controllate dal cliente; imporre l’isolamento per ambiente e separare i progetti per dev/test/prod.

Controllo dei costi:

Utilizzare sconti per uso impegnato (committed use) e per uso sostenuto (sustained use) per il calcolo a regime; istanze prerilasciabili/Spot per batch fault-tolerant; scalabilità automatica fino a zero su serverless.
Dimensionare correttamente le risorse con i suggerimenti di Monitoring; rimuovere i servizi inattivi e impostare quote per le metriche basate su log per evitare sorprese nei costi.

Risoluzione dei problemi di latenza:

Utilizzare Cloud Trace per identificare il microservizio che aggiunge la maggiore latenza; ottimizzare il percorso del codice, la cache o gli indici del database di quel servizio. Convalidare i miglioramenti con canary A/B.

Scenario pratico

FerroLine Logistics pianifica di modernizzare un monolite J2EE che gestisce il tracciamento delle spedizioni e le notifiche ai clienti. Il carico di lavoro è soggetto a picchi durante gli orari di chiusura regionali, deve raggiungere un obiettivo di disponibilità del 99,9% e il team desidera portabilità con un carico operativo minimo, introducendo al contempo funzionalità basate su eventi.

Stabilizzare e osservare il sistema attuale

Motivazione: prima di apportare modifiche, stabilire una baseline del comportamento e degli errori per ridurre il rischio di rollback. Distribuire l’Ops Agent sulle VM esistenti per Cloud Logging e Monitoring e strumentare il tracciamento distribuito nei percorsi delle richieste ad alta latenza. Esportare log e metriche in BigQuery per l’analisi storica e il reporting degli SLO.

Scegliere una landing zone graduale e un mix di piattaforme

Motivazione: bilanciare controllo e velocità. Migrare il monolite come container su Cloud Run jobs per i componenti batch e su servizi Cloud Run per le API HTTP stateless, impostando istanze minime per gli endpoint critici per la latenza. Mantenere inizialmente il database Oracle stateful su Compute Engine, preceduto da un LB HTTP(S) interno regionale per le API interne, e pianificare una futura migrazione ad AlloyDB.

Esternalizzare lo stato di sessione e di configurazione

Motivazione: evitare problemi di sessione locale all’istanza e abilitare una scalabilità automatica sicura. Archiviare i segreti in Secret Manager con account di servizio dedicati per un accesso con privilegi minimi. Spostare lo stato della sessione su Memorystore e i file condivisi su Cloud Storage. Ciò impedisce agli utenti di visualizzare dati obsoleti durante i picchi di carico.

Stabilire controlli di identità e registro

Motivazione: applicare il principio del privilegio minimo e garantire la provenienza. Archiviare le immagini in Artifact Registry con la scansione delle vulnerabilità abilitata. Assegnare un account di servizio di runtime univoco a ogni servizio Cloud Run e workload GKE (per i componenti scomposti in seguito) e concedere solo i ruoli necessari (ad es., Pub/Sub Publisher).

Implementare CI/CD con strategie di rollout sicure

Motivazione: ridurre i rollback non pianificati. Costruire una pipeline che esegua test di unità/integrazione e distribuisca in staging. Utilizzare la suddivisione del traffico di Cloud Run per inviare in canary il 5-10% del traffico alle nuove revisioni e abilitare un rollback rapido. Per le modifiche al DB basato su VM, utilizzare pattern di migrazione dello schema blue-green per disaccoppiare i deploy dell’applicazione e del database.

Scomporre prima i domini ad alta frequenza di modifica

Motivazione: valore incrementale con minor rischio. Applicare un pattern strangler: estrarre la consegna delle notifiche come microservizio su GKE per sfruttare l’HPA per i picchi e Pub/Sub per il disaccoppiamento. Mantenere il resto del monolite come un monolite modulare su Cloud Run mentre le interfacce si stabilizzano.

Progettare la scalabilità automatica e il load shedding

Motivazione: gestire i picchi di traffico senza guasti a cascata. Configurare la concorrenza e le istanze minime di Cloud Run per endpoint; impostare limiti di frequenza con Cloud Armor sull’LB HTTP(S) globale per proteggersi da picchi di traffico non autenticato. Per i servizi GKE, abilitare l’HPA su metriche personalizzate (richieste al secondo) e predisporre un piccolo buffer di nodi tramite il cluster autoscaler.

Preparare i servizi stateful e i percorsi dei dati

Motivazione: garantire durabilità e prestazioni. Per i tentativi di notifica su GKE, utilizzare una tabella Bigtable con chiave basata su cliente-regione e intervalli di tempo per memorizzare lo stato di consegna transitorio a elevate velocità di scrittura. Per una connettività privata e costante con l’ERP on-premise durante la transizione, utilizzare Dedicated Interconnect con Cloud Router.

Eseguire test di resilienza e prestazioni

Motivazione: convalidare gli SLO prima del passaggio completo. Eseguire flussi utente sintetici e randomizzati per attivare i livelli di scalabilità automatica. Iniettare caos terminando istanze Cloud Run casuali (consentendo al control plane di ricrearle) ed espellendo pod GKE per verificare i PodDisruptionBudgets e i readiness gate. Utilizzare Trace per identificare il maggior contributore alla tail latency e porvi rimedio.

Operare con barriere di controllo per costi e conformità

Motivazione: operare in produzione in modo sostenibile. Impostare budget e avvisi per servizio, abilitare CMEK su storage sensibili ove richiesto e utilizzare sconti per uso impegnato per i node pool di GKE e AlloyDB una volta compreso lo stato a regime. Configurare policy di conservazione dei log e viste BigQuery per condividere in modo sicuro i dati di audit con gli auditor interni.

Questo approccio graduale offre stabilità e osservabilità immediate, introduce pratiche di deployment sicure, scompone progressivamente il monolite lungo confini di servizio naturali e allinea le scelte della piattaforma con gli obiettivi di controllo, latenza, portabilità, scalabilità e costi.

← Design organizzativo · Tutti i domini · Storage dei dati →

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