Google PCA: Migrazione, modernizzazione e strategia di cloud ibrido — 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.

Pattern di migrazione, spostamento dei dati e cutover

• Framework decisionale (le 6 “R”)

  • Rehost: spostare così com’è (as-is) su Compute Engine. Il time-to-cloud più rapido, con modifiche minime. Rischio: si porta dietro il debito tecnico e un dimensionamento inefficiente.
  • Replatform: piccole modifiche per adottare servizi gestiti (es. Cloud SQL, Cloud Load Balancing). Benefici operativi più rapidi con poche modifiche al codice.
  • Refactor: decomporre o containerizzare per GKE/Cloud Run; adottare pattern event-driven. Massimo beneficio a lungo termine con rischio in fase di delivery.
  • Retire: rimuovere i sistemi non utilizzati dopo aver verificato l’assenza di utilizzo e dipendenze.
  • Retain: mantenere on-premise per motivi normativi o di latenza; integrare tramite un’architettura ibrida.
  • Relocate: spostare i carichi di lavoro vSphere su Google Cloud VMware Engine; preserva gli strumenti e minimizza le modifiche.

• Strumenti di migrazione per compute e database

  • Migrate to Virtual Machines accelera il rehosting su Compute Engine preservando dischi e configurazione di rete. Verificare il supporto del sistema operativo guest e i driver del kernel.
  • Database Migration Service fornisce una replica online omogenea (es. MySQL, PostgreSQL) verso Cloud SQL con basso downtime. Assicurarsi che le impostazioni di binlog/replica siano corrette e che la latenza supporti un recupero (catch-up) quasi in tempo reale.
  • Scegliere i database in base al carico di lavoro:
    • Cloud SQL per esigenze relazionali gestite; abilitare l’aumento automatico dello storage e monitorare la CPU intorno al 75% per core; tenere traccia del replication lag ed effettuare lo sharding o lo scale-up se ci si avvicina alle soglie.
    • Bigtable per l’ingestion di dati time-series a bassa latenza e alto throughput (es. dati da sensori).
    • Spanner per scalabilità globale e strong consistency; comprendere il trade-off tra lock-in e portabilità.
  • Spostamento dei dati
    • Storage Transfer Service per trasferimenti continui o pianificati; parallelizza ed è in grado di gestire i tentativi (retry-aware).
    • Transfer Appliance per caricamenti massivi una tantum (da decine a centinaia di TB) per ridurre i tempi e i rischi di rete.
    • gsutil e upload compositi paralleli per dataset di piccole e medie dimensioni.

• Migrazione online vs offline

  • Online: replica continua con un breve periodo di cutover. Pro: downtime minimo; Contro: richiede latenza e larghezza di banda stabili; attenta prevenzione del dual-write.
  • Offline: snapshot e importazione massiva. Pro: semplice e prevedibile; Contro: il downtime è pari alla durata della copia.

• Pianificazione del cutover, rollback e controllo del downtime

  • Abbassare i TTL del DNS giorni prima del cutover, congelare le modifiche non essenziali e pianificare una finestra di manutenzione.
  • Eseguire i validation gate: parità dello schema, checksum o conteggio delle righe, smoke test dell’applicazione, traffico canary e sonde di performance.
  • Rollback: assicurare modifiche allo schema retrocompatibili, feature flag e la conservazione dei dati source-of-truth. Evitare scritture irreversibili finché la stabilità non è comprovata.
  • Esempio di espansione del disco di una VM con downtime minimo:
    • Ridimensionare il disco nella Console o tramite CLI:

undefined

- Su Linux ext4:

undefined

• Aggiornamenti continui (rolling update) di un’app con impatto minimo su GKE:

undefined

Modalità di fallimento comuni: perdita di pacchetti su Cloud VPN che interrompe la replica del database (usare Dedicated Interconnect o Partner Interconnect), divergenza del dual-write durante il cutover, health check mancanti che bloccano i rolling update.

Identità ibrida, connettività e integrazione on-premise

• Identità

  • Mantenere Active Directory come source of truth. Usare Google Cloud Directory Sync per la sincronizzazione di account e gruppi, e configurare il SAML SSO per l’accesso degli utenti a Google Cloud.
  • Concedere permessi IAM secondo il principio del least-privilege tramite i ruoli, usare i service account per i carichi di lavoro e preferire Workload Identity Federation rispetto alle chiavi a lunga durata.

• Connettività ibrida e routing

  • Usare Cloud VPN per esigenze iniziali a basso throughput e per i test; passare a Dedicated Interconnect per una larghezza di banda sostenuta, latenza inferiore e prestazioni di replica prevedibili. Implementare VLAN attachment ridondanti e HA VPN o doppi interconnect per la resilienza.
  • Assicurarsi che gli intervalli IP di Google Cloud non si sovrappongano ai CIDR on-premise per preservare la raggiungibilità end-to-end.

  • Applicare un accesso a livelli (tiered access) con regole firewall e tag. Esempio per consentire solo il traffico web→API:

undefined

• Usare Private Service Connect e l’accesso privato Google per la comunicazione service-to-service senza egress pubblico; segmentare con VPC Service Controls dove appropriato.

• DNS ibrido: usare Cloud DNS con policy di forwarding e inbound/outbound per risolvere i nomi sia on-premise che nel cloud.

• Integrazione on-premise e latenza

  • Mantenere lo stato vicino al compute o viceversa; se il DB on-premise deve rimanere autoritativo, considerare App Engine flexible o Compute Engine con Cloud VPN/Interconnect per l’accesso privato.
  • Introdurre cache e code per disaccoppiare i percorsi sincroni e assorbire il jitter della latenza; misurare la latenza p95/p99, non solo le medie.

Modalità di fallimento comuni: sovrapposizione di CIDR che blocca le route, ridondanza insufficiente delle sessioni BGP, leak di DNS pubblico o di egress che espongono servizi privati, e protocolli “chatty” imprevisti che soffrono su collegamenti ad alta latenza.

Modernizzazione, Modello Operativo e Ottimizzazione

• Pattern di modernizzazione del legacy

  • Pattern Strangler Fig: posizionare una facciata API di fronte al monolite e instradare in modo incrementale i domini verso nuovi servizi.
  • Containerizzazione: standardizzare le immagini di base (preferire immagini “slim” come Alpine, se compatibili), ordinare i layer del Dockerfile per memorizzare nella cache l’installazione delle dipendenze prima di copiare il codice sorgente per ridurre i tempi di compilazione, e adottare una pipeline CI/CD con test automatizzati in ambiente di staging.
  • Dati gestiti: spostare gli archivi operativi su database gestiti; scegliere per dominio: Cloud SQL per carichi transazionali, Bigtable per time-series, Spanner per carichi di lavoro con coerenza globale.

• Validazione della compatibilità, coerenza e prestazioni delle applicazioni

  • Confermare il supporto di sistema operativo e middleware, i limiti di thread e connessioni e la semantica del filesystem. Verificare la portabilità delle licenze e la misurazione dell’utilizzo.
  • Definire i requisiti di coerenza dei dati (read-your-write, letture monotoniche, coerenza eventuale vs forte). Allinearli ai database di destinazione e ai pattern di accesso.
  • Validare le prestazioni con test di carico e percorsi utente sintetici; assicurarsi che i budget degli SLO siano raggiungibili dopo la migrazione.

• Osservabilità e conformità

  • Strumentare le applicazioni con Cloud Logging, Monitoring e Trace per localizzare la latenza tra i microservizi.
  • Esportare i log di audit e le modifiche alle policy IAM in BigQuery e condividerli con gli auditor tramite viste e policy IAM sui set di dati. Esportare le metriche a lungo termine su Cloud Storage per soddisfare i requisiti di conservazione pluriennali.

• Modello operativo e proprietà (ownership)

  • Adottare pratiche SRE: SLO, error budget, gestione degli incidenti e postmortem “blameless” (senza colpevolizzazione). Definire la proprietà dei servizi, i runbook e le turnazioni di reperibilità (on-call).
  • Utilizzare IaC (es. Terraform) per provisionare l’infrastruttura in modo coerente. Tenere presente che Deployment Manager è specifico di Google, può limitare l’automazione delle risorse multi-cloud ed è poco conosciuto da molti ingegneri.
  • Automatizzare la coerenza delle policy con Organization Policy, IAM Conditions, Config Sync e Policy Controller (OPA Gatekeeper) tra progetti e ambienti.

• Strategia multi-cloud e compromessi sul lock-in

  • Aumentare la portabilità con Kubernetes, pratiche delle app a 12 fattori, contratti definiti con OpenAPI e astrazioni per l’egresso dei dati. Bilanciare la portabilità con l’onere operativo e le prestazioni; i servizi gestiti riducono il lavoro ripetitivo (“toil”) ma possono aumentare i costi di migrazione (“switching cost”).

• Ottimizzazione dei costi e delle prestazioni; decommissioning

  • Scalare le istanze stateless di Compute Engine con i gruppi di istanze gestite e l’autoscaling; scegliere il serverless (Cloud Functions o Cloud Run) per carichi di lavoro con picchi (“bursty”) o MVP che beneficiano della scalabilità fino a zero.
  • Dimensionare correttamente le VM (“rightsizing”), abilitare l’autoscaling su GKE, applicare sconti per impegno di utilizzo (“committed use discounts”) ed eseguire il decommissioning degli artefatti non utilizzati. Monitorare la realizzazione dei benefici tramite KPI (disponibilità, latenza, costo per servire).
  • Eseguire il decommissioning dei sistemi on-premise dopo un periodo di “raffreddamento” e la conferma delle dipendenze. Archiviare o eliminare i dati secondo la policy di conservazione e aggiornare il CMDB.

Scenario Pratico

Acme Weather Networks deve migrare la sua piattaforma di sensori in tempo reale e una UI di amministrazione legacy J2EE da un data center on-premise a Google Cloud. Il sistema acquisisce dati da 50.000 sensori che inviano 10 letture al secondo e archivia cinque anni di dati storici (75 TB). Deve mantenere l’accesso privato all’ERP e all’Active Directory on-premise durante la transizione, minimizzare il downtime per un database MySQL on-premise ed eliminare i fallimenti di replica intermittenti osservati sulla VPN.

1. Stabilire una landing zone sicura

   • Creare organizzazione, cartelle e progetti di produzione/non produzione. Configurare una Shared VPC con intervalli IP non sovrapposti per garantire la raggiungibilità dall’on-premise tramite connettività ibrida. Applicare policy di organizzazione ed esportazioni centralizzate dei log di audit su BigQuery con accesso basato sul principio del privilegio minimo.
   • Motivazione: Prevenire conflitti di routing e applicare una governance di base prima dell’arrivo dei carichi di lavoro.

2. Implementare un’identità ibrida

   • Configurare Google Cloud Directory Sync per sincronizzare le identità e i gruppi di AD e impostare il SSO SAML. Utilizzare account di servizio e ruoli personalizzati IAM per la piattaforma e i carichi di lavoro.
   • Motivazione: Mantiene l’identità aziendale come fonte di verità e abilita il controllo degli accessi basato sul principio del privilegio minimo.

3. Provisionare la connettività e pianificare le prestazioni

   • Iniziare con una HA Cloud VPN per lo sviluppo/test. Per la replica del database di produzione e l’acquisizione costante dei dati dei sensori, provisionare una Dedicated Interconnect con due collegamenti VLAN (VLAN attachment) e sessioni BGP.
   • Motivazione: L’Interconnect offre una latenza inferiore e meno perdite di pacchetti rispetto alla VPN, stabilizzando la replica di MySQL e l’acquisizione in streaming.

4. Spostare i dati storici in modo efficiente

   • Ordinare le Transfer Appliance, caricare il set di dati da 75 TB on-premise, spedirle e reidratare i dati in Cloud Storage. Utilizzare Storage Transfer Service per eventuali aggiornamenti incrementali continui. Eseguire Cloud DLP sui log di supporto per de-identificare le PII prima dell’archiviazione in Bigtable o BigQuery.
   • Motivazione: Il trasferimento massivo offline riduce il rischio della finestra di cutover ed evita di saturare i circuiti.

5. Eseguire il rehosting della UI di amministrazione J2EE

   • Utilizzare Migrate to Virtual Machines per eseguire il lift-and-shift della VM J2EE su Compute Engine. Posizionare le istanze in un gruppo di istanze gestite dietro un load balancer HTTP(S). Applicare regole firewall basate su tag per forzare solo i flussi web→API→DB. Esempio:

undefined

• Motivazione: Riduzione rapida del rischio con un ambiente di runtime familiare, applicando al contempo percorsi di rete basati sul principio del privilegio minimo.

6. Migrare MySQL su Cloud SQL con downtime minimo

   • Eseguire un benchmark delle prestazioni di base e abilitare il binary logging sulla sorgente. Utilizzare Database Migration Service per configurare la replica continua verso Cloud SQL. Abilitare l’aumento automatico dello storage e creare alert per la CPU vicina al 75% e un ritardo di replica inferiore a 60 secondi.
   • Motivazione: La migrazione online consente di ottenere un basso downtime; un SQL gestito riduce il lavoro ripetitivo (“toil”) e impone SLO operativi.

7. Eseguire un cutover controllato

   • Abbassare i TTL del DNS 48 ore prima, congelare le modifiche allo schema e pianificare una finestra di manutenzione. Interrompere le scritture on-premise, assicurarsi che il ritardo di DMS sia zero, eseguire checksum e smoke test applicativi, quindi puntare i client a Cloud SQL. Mantenere un piano di rollback in cui le scritture possano essere reindirizzate nuovamente all’ambiente on-premise in caso di fallimento della validazione.
   • Motivazione: Passaggi deterministici limitano l’RTO e mantengono la coerenza dei dati.

8. Costruire l’acquisizione per la telemetria in tempo reale

   • Acquisire tramite Pub/Sub, elaborare con Dataflow e archiviare le time-series in Bigtable per scritture e letture a bassa latenza. Mantenere l’integrazione con l’ERP privata tramite l’Interconnect.
   • Motivazione: Bigtable è adatto al profilo time-series ad alto throughput, e Pub/Sub disaccoppia i producer con picchi di attività (“bursty”) dai consumer.

9. Containerizzare i servizi e introdurre la CI/CD

   • Containerizzare i servizi stateless per GKE. Ottimizzare i Dockerfile utilizzando immagini di base “slim” e ordinando i layer in modo che l’installazione delle dipendenze preceda la copia del codice sorgente. Implementare una pipeline CI/CD con test automatizzati in ambiente di staging e rilasci canary. Aggiornare con downtime minimo:

undefined

• Motivazione: Migliora la velocità di deployment, l’affidabilità e la scalabilità senza una riscrittura completa (“big-bang”).

10. Potenziare l’osservabilità e l’audit

    • Strumentare con Cloud Logging, Monitoring e Trace per individuare con precisione la latenza tra i microservizi. Esportare i log di audit su BigQuery e condividere viste con ambito limitato per gli auditor. Esportare le metriche a lungo termine su Cloud Storage per soddisfare i requisiti di conservazione di cinque anni.
    • Motivazione: Una telemetria completa supporta gli SLO e la conformità.

11. Ottimizzare ed eseguire il decommissioning

    • Abilitare l’autoscaling su MIG e GKE, dimensionare correttamente le istanze, applicare sconti per impegno di utilizzo e pianificare i carichi di lavoro non attivi 24x7 su serverless (es. Cloud Functions per attività ausiliarie) per scalare fino a zero. Dopo aver raggiunto la stabilità e trascorso un periodo di “raffreddamento”, eseguire il decommissioning dei sistemi on-premise, aggiornare il CMDB e pubblicare i benefici realizzati.
    • Motivazione: Ottenere efficienze operative e di costo eliminando le spese di gestione di entrambi gli ambienti (dual-run).

12. Rendere operativo e formare il personale

    • Finalizzare i runbook, la matrice RACI, le turnazioni di reperibilità (on-call) e i budget di SLO/errori. Fornire piani di formazione mirata e certificazione per colmare i gap di competenze. Preferire Terraform per l’IaC; notare che Deployment Manager è specifico di Google e potrebbe non gestire risorse non-Google.
    • Motivazione: Un modello operativo maturo sostiene l’affidabilità e la velocità anche dopo l’evento di migrazione.

← Affidabilità · Tutti i domini · Operazioni →

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

Sfoglia Google →