Google PCD: Piattaforme di runtime Compute, Container e Serverless — 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

Google Cloud offre molteplici piattaforme di runtime che spaziano tra serverless, container e macchine virtuali. La scelta della piattaforma giusta dipende dalle caratteristiche del workload, come i pattern delle richieste, la gestione dello stato, la disciplina di build e rilascio, il modello operativo e i vincoli di rete. Questa sezione tratta i principi di progettazione, le modalità di fallimento e i compromessi per Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) e Compute Engine, insieme ai servizi di supporto per immagini, identità, networking, configurazione e operations.

Runtime serverless: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Modello: Container completamente gestiti con gestione delle richieste HTTP o Job containerizzati che vengono eseguiti fino al completamento.
• Revisioni e traffico: Ogni deploy crea una revisione immutabile. La suddivisione del traffico in percentuale tra le revisioni abilita pattern canary e blue-green con rollback istantaneo. Esempio:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Concorrenza e scalabilità: La concorrenza predefinita è 80; impostarla a 1 per codice CPU-bound o non thread-safe. Una concorrenza più alta riduce l’amplificazione dei cold-start e i costi, ma può aumentare la latenza di coda (tail latency) se la CPU/memoria per richiesta è inadeguata. Cloud Run scala fino a zero e verso l’alto in base al rateo di richieste in arrivo; è possibile controllarlo con istanze minime/massime per ridurre i cold-start e limitare i costi.
• Allocazione della CPU: Scegliere “CPU sempre allocata” per il lavoro in background tra le richieste, al costo di una fatturazione aggiuntiva; altrimenti la CPU viene allocata solo durante la gestione delle richieste.
• Job: I Job di Cloud Run eseguono N task in parallelo fino al completamento, con un numero massimo di tentativi per task e timeout generali; adatti per elaborazioni ETL, batch e fan-out. Le modalità di fallimento includono l’hot-spotting sui backend quando molti task si rivolgono alla stessa dipendenza; aggiungere rate limiting e tentativi con backoff.
• Networking: Pubblico, autenticato tramite IAM, o privato dietro una VPC tramite Serverless VPC Access e Private Service Connect.

App Engine

• Ambienti:
  • Standard: In sandbox, con scalabilità rapida, runtime fissi per linguaggio; bassa latenza di cold-start con scalabilità automatica; file system con restrizioni, timeout delle richieste e limiti sulla dimensione delle richieste in entrata. Utilizzare URL firmati di Cloud Storage per upload di grandi dimensioni.
  • Flessibile: Basato su Docker, con capacità simili a una VM, runtime personalizzati, scale-up più lento rispetto allo Standard, supporta thread in background e scrittura su disco locale.
• Servizi e versioni: Un servizio (microservizio) può ospitare più versioni; è possibile instradare il traffico in base alla percentuale tra le versioni, in modo simile a Cloud Run. Usare dispatch.yaml per instradare percorsi o host specifici ai servizi per un routing semplice e centralizzato senza un load balancer esterno.
• Scalabilità: Manuale, di base o automatica nello Standard; scalabilità basata sul numero di VM nel Flessibile. Compromesso: un autoscaling aggressivo migliora la reattività ma può aumentare i costi e la congestione del backend.
• Errori comuni: Una scalabilità illimitata delle istanze senza quote può sovraccaricare i sistemi a valle; applicare quote e circuit breaker.

Cloud Functions

• Handler event-driven: Attivati da eventi HTTP, Pub/Sub, Cloud Storage o Eventarc. Usare la 2ª generazione per sfruttare il modello di esecuzione di Cloud Run, il controllo dell’egress VPC e la concorrenza; la 1ª generazione elabora una richiesta alla volta.
• Tentativi e idempotenza: Le funzioni in background possono essere ritentate in caso di fallimento; progettare handler idempotenti e usare chiavi di deduplicazione per evitare la doppia elaborazione. I trigger HTTP non vengono ritentati dalla piattaforma; implementare tentativi dal client con backoff esponenziale.
• Configurazione del runtime: Variabili d’ambiente, integrazione con Secret Manager e concorrenza/numero massimo di istanze per funzione. Impostare i timeout per contenere i costi fuori controllo. Attenzione ai cold-start lunghi con dipendenze pesanti; mantenere i pacchetti leggeri.

Container su Google Kubernetes Engine

Workload

• Deployment: Pod stateless con aggiornamenti continui (rolling update). Garantire rollout sicuri con limiti di surge/unavailable:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSet: ID di rete stabili e ordinati e volumi persistenti per servizi stateful.
• DaemonSet, Job, CronJob: Agenti a livello di nodo e workload batch.

Servizi e Ingress

• Tipi di Service:
  • ClusterIP per uso solo interno.
  • NodePort per un accesso esterno semplice (operativamente limitato).
  • LoadBalancer per il bilanciamento del carico esterno/interno a livello regionale.
• Ingress: Routing HTTP(S) e terminazione TLS; preferire la Gateway API o Ingress con controller gestiti per le policy L7. Modalità di fallimento: health check che falliscono a causa del firewall; consentire gli intervalli IP del load balancer verso i nodi di backend.

Autoscaling e Node Pool

• Horizontal Pod Autoscaler (HPA): Scala i pod in base a CPU, memoria o metriche personalizzate; combinare con i Pod Disruption Budget per proteggere la disponibilità.
• Vertical Pod Autoscaler (VPA): Dimensiona correttamente le richieste/limiti dei pod; evitare l’uso simultaneo di HPA e VPA sulla stessa dimensione per prevenire cicli di feedback.
• Cluster Autoscaler: Aggiunge/rimuove nodi per soddisfare le richieste di risorse dei pod in attesa.
• Node pool: Separare i pool per classe di workload. Usare taint/toleration ed etichette per lo scheduling. Mischiare istanze spot/preemptible per workload sensibili ai costi con tolleranza alle interruzioni. Scegliere tipi di macchina con sufficiente larghezza di banda di memoria/CPU per i limiti per-pod per evitare il throttling.

Health check e rollout

• Probe di liveness, readiness e startup: impediscono l’invio di traffico a pod non pronti e riavviano i container in deadlock. Probe di liveness troppo restrittivi possono causare riavvii a cascata; ottimizzare i ritardi iniziali e le soglie di fallimento.
• Rollback con kubectl rollout undo. Per il canary, usare più Deployment e la suddivisione del traffico a livello di Service tramite Ingress/Gateway.

Compute Engine per carichi di lavoro applicativi

Progettazione delle VM

• I modelli di istanza definiscono tipo di macchina, immagine, dischi, ambiti dell’account di servizio, script di avvio e metadati. Mantieni le immagini minimali; usa script di avvio o immagini preparate con Packer per un avvio deterministico.
• Dischi: Usa dischi permanenti bilanciati o SSD per le app sensibili alla latenza. Condividi grandi set di dati di sola lettura su un gruppo di istanze gestite tramite un disco permanente di sola lettura collegato a più istanze per ottenere bassa latenza e avvio rapido.
• Networking: Crea regole firewall per gli health checker quando si utilizzano i load balancer. Esempio:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Gruppi di Istanze Gestite (MIG)

• Autoscaling basato su CPU, richieste al secondo del load balancer, metriche personalizzate o pianificazioni. Imposta periodi di cool-down per prevenire il thrashing.
• L’autohealing con controlli di integrità riavvia le VM non integre; assicurati che il percorso del controllo di integrità verifichi la prontezza dell’applicazione, non solo la raggiungibilità della porta, per evitare di servire errori 500.
• Aggiornamenti continui e blue-green: Crea un nuovo modello di istanza e avvia un aggiornamento canary su un sottoinsieme di istanze. Se gli errori aumentano, esegui il rollback al modello precedente. I controlli di uptime e l’alerting basato su SLO rilevano rapidamente i degradi delle prestazioni.

Logging e monitoraggio

• Installa gli agent per raccogliere i log dell’applicazione senza modifiche al codice; inviali a Cloud Logging e imposta alert tramite Cloud Monitoring. Usa i Debug Logpoint per la diagnostica in tempo reale con un’interruzione minima.

Build, Identità, Networking, Segreti e Operazioni

Artifact Registry e immagini

• Utilizzare Artifact Registry per le immagini dei container e gli artefatti dei linguaggi. Abilitare la scansione delle vulnerabilità e la generazione della provenienza. Mantenere le immagini di piccole dimensioni:
  • Build multi-stage per separare l’ambiente di build da quello di runtime.
  • Evitare strumenti di sviluppo nell’immagine finale; fissare le versioni del sistema operativo e dei pacchetti. Esempio:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Promozione: Taggare le immagini in modo immutabile (es. app:1.3.7, app:prod-20240901) e promuoverle ri-taggandole in Artifact Registry; evitare il tag mutabile latest in produzione. Controllare le promozioni con i risultati dei test di integrazione e canary.

Identità di runtime e principio del privilegio minimo

• Assegnare un service account dedicato per ogni workload con i ruoli IAM minimi necessari. Evitare ruoli ampi come Editor. In GKE, mappare i ServiceAccount di Kubernetes ai service account di Google tramite Workload Identity. Per il serverless, impostare esplicitamente il service account di runtime e rimuovere gli scope del token di default.

Connettori VPC e networking dei servizi

• I connettori Serverless VPC Access instradano il traffico in uscita (egress) da Cloud Run, Cloud Functions e App Engine verso una VPC. Scegliere la modalità di egress:
  • Solo intervalli privati (Private ranges only) per raggiungere servizi RFC1918 e connessi alla VPC, mentre il traffico pubblico in uscita va direttamente.
  • Tutto il traffico tramite connettore più Cloud NAT per avere IP di egress deterministici e policy restrittive in uscita.
• Dipendenze private: Preferire l’IP privato per Cloud SQL e Private Service Connect per le API di Google o i servizi dei partner. Assicurarsi che i connettori siano nella stessa regione e dimensionati per il throughput richiesto; monitorare la CPU del connettore per evitare il throttling.

Configurazione, segreti e health check

• Utilizzare le variabili d’ambiente per la configurazione non segreta. Archiviare i segreti in Secret Manager e montarli o iniettarli a runtime; ruotare le chiavi regolarmente. In GKE, usare i Secret e il driver CSI per Secret Manager. In App Engine e Cloud Run, concedere al service account l’accesso a segreti specifici.
• Health check:
  • Cloud Run: le istanze si riavviano in caso di crash; utilizzare controlli a livello di richiesta e SLI di latenza.
  • App Engine: health check integrati; personalizzare i controlli di liveness/readiness per l’ambiente Flexible.
  • GKE: configurare i probe di liveness/readiness/startup.
  • Compute Engine dietro a Load Balancer: utilizzare health check HTTP(S) con endpoint specifici dell’applicazione.

Troubleshooting, rollback e strategie di rilascio

• Blue-green e canary con suddivisione del traffico (traffic splitting) su Cloud Run e App Engine; in GKE, utilizzare Deployment paralleli o controller di progressive delivery; nei MIG, usare sottoinsiemi canary di istanze. Definire sempre criteri di interruzione basati sull’error budget degli SLO e sulla latenza.
• Modalità di fallimento comuni:
  • Effetto “thundering herd” dopo uno scale-to-zero o rollout di grandi dimensioni; mitigare con un numero minimo di istanze (min instances), warmup e rate limiting.
  • Superamento delle quote di backend o dei limiti di connessione; applicare exponential backoff e circuit breaker.
  • Cold start dovuti a immagini o dipendenze di grandi dimensioni; snellire le immagini e pre-inizializzare i client.

Scenario Pratico

Acme Retail pianifica di migrare un’API di ridimensionamento immagini da VM autogestite a una piattaforma scalabile ed economicamente vantaggiosa, con risposte a bassa latenza, accesso privato a un bucket Cloud Storage regionale e rilasci canary sicuri.

Approccio

1. Impacchettare il servizio come un’immagine container di piccole dimensioni e pubblicarla su Artifact Registry.

• Motivazione: Un build Docker snello e multi-stage minimizza i cold start e il trasferimento di rete. Artifact Registry centralizza le scansioni e i flussi di lavoro di promozione.

2. Eseguire il deploy dell’API su Cloud Run con un minimo di 2 istanze (min instances), concorrenza (concurrency) di 40 e l’opzione CPU sempre allocata (CPU always allocated) disabilitata.

• Motivazione: Cloud Run offre scalabilità orizzontale istantanea e HTTPS gestito. Un piccolo pool di istanze minime riduce la latenza dei cold start durante i picchi diurni. Una concorrenza di 40 bilancia i costi e la latenza di coda (tail latency) per le trasformazioni di immagini I/O-bound. Disabilitare la CPU sempre attiva evita di pagare per il calcolo inattivo tra le richieste.

3. Creare un connettore Serverless VPC Access e impostare l’egress su private ranges only; abilitare il Private Google Access nella subnet e configurare un endpoint VPC-SC o Private Service Connect per Cloud Storage se necessario.

• Motivazione: L’API deve recuperare e scrivere immagini privatamente senza egress pubblico. La modalità private ranges assicura che solo il traffico VPC passi attraverso il connettore, mantenendo le chiamate pubbliche dirette ed efficienti. Private Google Access o Private Service Connect forniscono accesso privato alle API di Google dalla VPC.

4. Concedere a un service account di runtime dedicato l’accesso con privilegio minimo al bucket Cloud Storage di destinazione e ai segreti richiesti.

• Motivazione: Il principio del privilegio minimo limita il raggio d’impatto (blast radius). L’identità di runtime riceve i ruoli storage.objectViewer e storage.objectAdmin sullo specifico bucket, e il ruolo di accessor sui segreti necessari di Secret Manager.

5. Archiviare le chiavi API e la configurazione per ambiente in Secret Manager e nelle variabili d’ambiente; iniettare i segreti a runtime.

• Motivazione: Rotazione centralizzata dei segreti e accesso verificabile. La configurazione non segreta tramite variabili d’ambiente supporta le pratiche 12-factor.

6. Implementare exponential backoff e scritture idempotenti per gestire gli errori 429/5xx da Cloud Storage.

• Motivazione: Durante picchi di traffico o eventi regionali, possono verificarsi errori transitori. Il backoff con jitter protegge sia l’API che Cloud Storage da tempeste di tentativi (retry storm).

7. Configurare una revisione canary e deviare il 10% del traffico verso di essa; monitorare il tasso di errore, la latenza P95 e la saturazione.

• Motivazione: La suddivisione del traffico (traffic splitting) su Cloud Run consente un rollout progressivo sicuro. I monitor basati su SLO forniscono trigger di rollback automatici se gli error budget si esauriscono troppo rapidamente.

8. Aggiungere un endpoint di health HTTP che eserciti le dipendenze a valle; impostare alert sugli uptime check di Cloud Monitoring e su metriche basate su log.

• Motivazione: Un health check end-to-end rileva precocemente i fallimenti delle dipendenze. Gli uptime check forniscono una prospettiva esterna; le metriche basate su log catturano pattern di fallimento specifici dell’applicazione.

9. Stabilire limiti di autoscaling e budget; impostare un numero massimo di istanze (max instances) per limitare la spesa e definire la gestione degli errori 429 per il sovraccarico.

• Motivazione: Limitare la scalabilità previene costi fuori controllo e l’esaurimento del backend. Un comportamento di sovraccarico gestito con garbo (graceful overload) mantiene la stabilità del servizio.

10. Documentare il rollback: riportare il 100% del traffico alla revisione precedente di Cloud Run con un singolo comando.

• Motivazione: Le revisioni immutabili rendono il rollback sicuro e veloce, minimizzando il tempo medio di ripristino (mean time to recovery).

← Architettura di applicazioni Cloud-Native e selezione dei servizi · Tutti i domini · Progettazione di API →

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

Sfoglia Google →