Google ACE: Archiviazione, database e servizi dati — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Panoramica

Questa sezione fornisce un riferimento pratico e incentrato sulle operazioni per i servizi di storage, database e analisi dei dati di Google Cloud. Pone l’accento sui pattern di configurazione, il controllo degli accessi, i meccanismi di durabilità, le caratteristiche di performance e di costo e le pratiche di ripristino sicure. L’obiettivo è aiutarti a decidere quale servizio utilizzare per un determinato carico di lavoro, a comprendere i compromessi operativi e ad anticipare le modalità di guasto più comuni.

Progettazione, accesso, ciclo di vita e protezione di Cloud Storage

Cloud Storage è uno storage a oggetti durevole e ad alta disponibilità per dati non strutturati e backup.

Bucket e oggetti: I bucket sono namespace globali in una location (regione o doppia/multi-regione) che contengono versioni immutabili degli oggetti. Scegli la location del bucket per minimizzare l’egress e soddisfare i requisiti di residenza dei dati.
Classi di archiviazione: Utilizza Standard (dati ad accesso frequente), Nearline (min. ~30 giorni), Coldline (min. ~90 giorni) e Archive (min. ~365 giorni) in base alla frequenza di accesso. Per i backup di DR, Coldline è una scelta predefinita comune. È possibile combinare classi per singolo oggetto all’interno di un bucket.
Regole del ciclo di vita: Automatizza le transizioni e le eliminazioni tramite le condizioni Age, CreatedBefore, MatchesStorageClass e NoncurrentVersion. Esempio per la transizione a 90 giorni e l’eliminazione a 365 giorni:
1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
2. Applica: gsutil lifecycle set lifecycle.json gs://my-bucket
Conservazione e blocchi per motivi legali: Le policy di conservazione impediscono l’eliminazione o la modifica degli oggetti prima che il periodo scada; il blocco della policy è irreversibile. I blocchi per motivi legali sono per singolo oggetto e devono essere rimossi prima dell’eliminazione.

Controllo degli accessi e condivisione:

Uniforme vs granulare: Preferisci l’accesso uniforme a livello di bucket (UBLA) per gestire le autorizzazioni solo con IAM. L’accesso granulare (ACL a livello di oggetto) è un sistema legacy e complica la verificabilità e la propagazione. L’abilitazione di UBLA disabilita le ACL e può avere un impatto immediato sulle integrazioni esistenti che si basavano su di esse.
URL firmati: Per un accesso di breve durata senza un’identità Google, utilizza gli URL firmati. Evita i file delle chiavi degli account di servizio firmando con IAM: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com Assicurati che l’account di servizio abbia il ruolo “Creatore token account di servizio” (Service Account Token Creator) su se stesso o tramite un ruolo di firmatario.
Crittografia: Crittografia lato server per impostazione predefinita; abilita le CMEK (Customer-Managed Encryption Keys) a livello di bucket o di singolo oggetto quando hai bisogno di controllo sulle chiavi e sugli audit trail. Monitora la disponibilità e la rotazione delle chiavi KMS; l’indisponibilità delle CMEK bloccherà gli upload e le decrittazioni.
Versioning: Abilita il versioning degli oggetti per conservare le versioni non correnti dopo sovrascritture/eliminazioni. Combinalo con le regole del ciclo di vita per far scadere le versioni non correnti e controllare la crescita dello storage. Presta attenzione alla logica di listing lato client quando esistono molte versioni.

Modalità di guasto e mitigazione:

Eliminazione o sovrascrittura accidentale: Utilizza il versioning e le policy di conservazione. Per una conformità rigorosa, blocca la policy di conservazione.
Accesso pubblico configurato in modo errato: Applica la prevenzione dell’accesso pubblico (Public Access Prevention) e UBLA. Esegui audit periodici con Cloud Asset Inventory e l’analizzatore di policy.
Costi eccessivi: Le regole del ciclo di vita, le classi a livello di oggetto e l’opzione “requester pays” riducono le sorprese. Monitora con le metriche di Cloud Monitoring e i budget.

Comandi utili:

Creare un bucket con UBLA e conservazione: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

Storage a blocchi e file per carichi di lavoro di calcolo

Scegli lo storage in base al pattern di accesso, alle esigenze di performance e ai requisiti di durabilità per Compute Engine e GKE.

Persistent Disk (PD): Storage a blocchi durevole, a livello di zona o di regione. Tipi: Standard (HDD) per throughput sequenziale; Bilanciato (pd-balanced) e SSD (pd-ssd) per bassa latenza e IOPS elevati. Il PD a livello di regione esegue una replica sincrona tra le zone, consentendo un ripristino più rapido. I PD possono essere sottoposti a snapshot, ridimensionati online e collegati in modalità di sola lettura a più VM (scrittore singolo per la modalità di lettura-scrittura).
- Compromessi: Costi IOPS più elevati su SSD; l’HDD è conveniente ma ha una latenza elevata per l’I/O casuale. Il PD a livello di regione costa di più ma riduce l’RTO.
Local SSD: Storage effimero collegato tramite NVMe o SCSI con IOPS molto elevati e bassa latenza. I dati vengono persi all’arresto della VM o durante la manutenzione dell’host; utilizzalo solo per cache effimere o dati replicati. Esegui il backup o la replica altrove per evitare la perdita di dati.
Filestore: Servizio NFS gestito per semantiche di file condivisi POSIX. I tier di base sono a livello di zona; i tier Enterprise e superiori offrono HA (High Availability) a livello di regione con replica sincrona e IOPS più elevati. Ideale per GCVE, scratch HPC, rendering multimediale e applicazioni che necessitano di blocco di file condiviso.
- Compromessi: NFS introduce caching lato client e semantiche di blocco; il throughput e la latenza differiscono in base al tier; non è adatto per I/O casuale di piccole dimensioni con latenze nell’ordine di microsecondi a una cifra come il Local SSD.

Considerazioni sui guasti:

Manutenzione dell’host: Perdita dei dati su Local SSD; proteggere con la replica a livello di applicazione.
Interruzioni a livello di zona: Interruzioni per PD a livello di zona e Filestore di livello Basic; utilizzare PD a livello di regione o Filestore Enterprise per l’HA.
Consistenza degli snapshot: Per snapshot di PD consistenti con l’applicazione, coordinare con il freeze del filesystem o il quiesce nativo del database per evitare finestre di ripristino da crash.

Database gestiti e servizi dati

Cloud SQL (MySQL, PostgreSQL, SQL Server gestiti):

Configurazione: Scegliere la forma della macchina, il tipo di storage, le connessioni (preferibilmente IP privato), le reti autorizzate se si utilizza un IP pubblico, le finestre di manutenzione e gli insights per la diagnostica delle prestazioni. Utilizzare il connection pooling (es. Cloud SQL Auth Proxy, PGbouncer) per rimanere entro i limiti di connessione e CPU.
Alta disponibilità: Le istanze HA regionali implementano uno standby in un’altra zona con replica sincrona dello storage; il failover è automatico. Aspettarsi una breve finestra di indisponibilità in scrittura durante il failover.
Repliche: Repliche di lettura per la scalabilità in lettura e per scaricare il carico di lavoro di BI; replica esterna per le migrazioni. Monitorare il ritardo della replica (replica lag) e progettare lettori idempotenti.
Backup e PITR: Abilitare i backup automatici e il logging binario/WAL per il ripristino point-in-time (point-in-time recovery). Testare regolarmente i ripristini.

undefined

Modalità di guasto: Transazioni a lunga esecuzione bloccano il vacuum/checkpointing; picchi di connessioni causano thrashing; la crescita automatica dello storage (autogrow) può bloccarsi se la quota è insufficiente. Impostare alert per CPU, memoria, connessioni, ritardo della replica e utilizzo del disco.

Cloud Spanner:

Scalabilità e regionalità: Istanze regionali o multi-regionali con replica sincrona e coerenza forte a livello globale (strong global consistency). Scalare i nodi per throughput e storage; il posizionamento della regione leader influenza la latenza di scrittura.
Schema e chiavi: Progettare le chiavi primarie per evitare hotspot; utilizzare chiavi composite con un prefisso hashato o randomizzato per le serie temporali per distribuire le scritture. Utilizzare indici secondari per i pattern di query e considerare di archiviare insieme le colonne filtrate di frequente. Mantenere le transazioni piccole e limitate per minimizzare la contesa sui lock.
Transazioni: Transazioni distribuite fortemente consistenti con coerenza esterna tramite TrueTime. Latenza di scrittura limitata dal quorum; i conflitti portano all’interruzione delle transazioni (aborted transactions)—riprovare con backoff.

Firestore e Bigtable:

Firestore (modalità nativa): Document store con collezioni, listener in tempo reale, transazioni che possono includere fino a 500 documenti per transazione e coerenza forte (strong consistency) per le letture di documenti e la maggior parte delle query. Ideale per dati di app mobili/web, JSON gerarchici e app event-driven.
Bigtable: Database a colonne larghe (wide-column) per scalabilità a livello di petabyte e latenza inferiore a 10 ms. Solo transazioni su singola riga; progettare le chiavi di riga (row key) per evitare l’hotspotting. Ideale per serie temporali, IoT, personalizzazione e contatori su larga scala. Non adatto per join ad-hoc o aggregazioni complesse.

Memorystore:

Redis e Memcached: Cache in-memory per una latenza di microsecondi-millisecondi. Il livello Basic non ha HA; il livello Standard fornisce HA regionale con failover automatico per Redis. Trattare come effimero; non utilizzare come sistema di riferimento (system of record).

BigQuery:

Dataset e tabelle: Organizzare per dataset; controllare l’accesso a livello di progetto, dataset, tabella, colonna e riga. Utilizzare tabelle partizionate e clusterizzate per controllare i byte scansionati e i costi.
Job di caricamento e query: Caricare da Cloud Storage, esportazioni di Cloud SQL o inserimenti in streaming. Utilizzare le esecuzioni di prova (dry run) per stimare i costi:

undefined

Controllo degli accessi: Concedere il ruolo BigQuery Data Viewer a livello di dataset per i consumer di sola lettura; utilizzare viste autorizzate o la sicurezza a livello di riga/colonna per il principio del privilegio minimo (least privilege).

Compromessi operativi, di convalida, migrazione e spostamento dei dati

Migrazione e trasferimento:

Database Migration Service (DMS): per migrazioni omogenee verso Cloud SQL con tempi di inattività minimi tramite la replica. Convalidare il cutover con metriche di lag e confronti di checksum.
Trasferimenti su Cloud Storage: Storage Transfer Service per trasferimenti ripetitivi o basati su eventi; gsutil -m rsync per copie sincronizzate una tantum con checksum; Transfer Appliance per grandi spostamenti offline.
Import/export: Cloud SQL esporta su Cloud Storage; il re-import supporta il bootstrap del PITR e la verifica dei dati. BigQuery supporta caricamenti batch da Cloud Storage ed esportazioni in Avro/Parquet per l’utilizzo a valle (downstream).
Convalida: utilizzare checksum degli oggetti (CRC32C), conteggi delle righe, query di campionamento e invarianti a livello di applicazione. Per BigQuery, confrontare i conteggi o gli hash di GROUP BY tra origine e destinazione.

Compromessi tra prestazioni, disponibilità, capacità e costi:

Cloud Storage: ottimizzare l’egress collocando il compute nella stessa location; scegliere le classi in base alla frequenza di accesso; utilizzare dual/multi-region per la resilienza tra zone e una maggiore disponibilità a un costo di storage più elevato.
PD/Filestore: SSD per I/O a bassa latenza; HDD per il throughput; replica a livello di region per l’HA; dimensionare correttamente gli IOPS per evitare il throttling.
Cloud SQL: il dimensionamento verticale è semplice ma limitato; le repliche di lettura scaricano il traffico di lettura; l’HA aggiunge disponibilità ma non capacità di lettura; la classe di storage influisce su latenza e costi.
Spanner: scala orizzontalmente con strong consistency; il costo premium è compensato da RPO/RTO globali e da uno sharding semplificato. Le scritture sono sensibili al design delle chiavi e alla latenza della region leader.
Firestore/Bigtable/Memorystore: scegliere in base a latenza, modello dei dati e consistenza. Le cache in-memory riducono il carico sul database ma aggiungono complessità nell’invalidazione della cache.
BigQuery: il costo on-demand è proporzionale ai byte scansionati; il partizionamento/clustering e il predicate pushdown riducono la spesa. Le prenotazioni flat-rate scambiano la prevedibilità con un impegno di spesa (commitment).

Risoluzione dei problemi e ripristino sicuro:

Cloud Storage: utilizzare il versioning e la retention degli oggetti per il ripristino; esaminare i data access log di Cloud Logging per l’audit degli eventi di lettura/scrittura; assicurarsi che le chiavi CMEK siano abilitate durante il ripristino.
PD/Filestore: ripristinare da snapshot o backup; eseguire fsck e le modalità di ripristino del database; garantire la coerenza con il quiesce a livello di applicazione prima di creare lo snapshot.
Cloud SQL: ripristinare su una nuova istanza per il PITR per evitare la perdita di dati sulla primaria; verificare con test di sola lettura; mantenere firewall e DNS privato per pattern di cutover sicuri.
Spanner/Bigtable: investigare l’hotspotting tramite lo sbilanciamento (skew) nell’accesso alle chiavi; usare Monitoring per tracciare latenza e throttling; implementare backoff e tentativi (retry) per transazioni interrotte o operazioni soggette a rate-limiting.
BigQuery: diagnosticare query lente tramite i dettagli di esecuzione; aggiungere partizioni e clustering; limitare SELECT *; materializzare i risultati intermedi quando appropriato. Recuperare tabelle eliminate (dropped) entro la finestra di time travel ripristinando uno snapshot o copiando da un punto temporale dello snapshot.

Scenario pratico

Contoso Retail sta consolidando i dati di backup e di analytics, rafforzando al contempo i controlli di accesso e abilitando il point-in-time recovery (PITR) per i suoi sistemi transazionali. Le loro necessità sono: archiviare i backup delle applicazioni con tiering automatizzato, fornire condivisione di file a breve termine a terze parti, abilitare il PITR per un piccolo workload relazionale e stimare i costi delle query di analytics prima della loro esecuzione.

Approccio:

Creare un bucket Cloud Storage regionale con UBLA, retention e lifecycle.
- Comando: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
- Motivazione: UBLA centralizza l’autorizzazione in IAM e migliora l’auditabilità. Una retention di un anno previene cancellazioni accidentali. Il lifecycle sposta i backup su Coldline dopo 90 giorni e li elimina alla scadenza per controllare i costi.
Concedere accesso in sola scrittura per i job di backup tramite un service account dedicato.
- Comando: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
- Motivazione: il ruolo storage.objectCreator impedisce la manomissione dei metadati e la rilettura di backup sensibili, aderendo al principio del privilegio minimo (least privilege).
Condividere un backup sensibile con un fornitore per quattro ore utilizzando una signed URL senza distribuire chiavi.
- Comando: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
- Motivazione: l’accesso a tempo limitato e senza identità evita la creazione di identità esterne o segreti di lunga durata. L’impersonation utilizza una firma centralizzata basata su KMS ed elimina i rischi di fuga di chiavi.
Abilitare i backup di Cloud SQL e il PITR per il database degli ordini.
- Comando: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
- Motivazione: i backup automatici più il logging binario/WAL forniscono punti di ripristino a qualsiasi secondo entro la finestra di retention, proteggendo da corruzione logica ed errori dell’operatore.
Testare il ripristino ripristinando su una nuova istanza e convalidando i dati prima del cutover.
- Comando: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
- Motivazione: il ripristino su un’istanza separata evita di impattare la produzione e consente la convalida tramite checksum e query di esempio prima di qualsiasi modifica a livello di DNS o applicazione.
Stimare il costo di una query BigQuery con una dry run e ottimizzare con il partizionamento.
- Comando: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
- Motivazione: le dry run mostrano i byte che verranno scansionati; assicurarsi che sale_date sia una colonna di partizione con un predicato limitato riduce i byte scansionati e controlla i costi on-demand.
Monitorare e verificare gli accessi.
- Passaggi:
  - Abilitare i log di accesso ai dati (Data Access logs) per Cloud Storage e BigQuery.
  - Configurare alert di Cloud Monitoring sulle connessioni di Cloud SQL, sull’utilizzo del disco e sui fallimenti dei backup.
- Motivazione: i Data Access logs forniscono visibilità a livello di oggetto sulle letture/scritture per la conformità. Gli alert proattivi riducono l’MTTR e garantiscono che i backup e il PITR rimangano efficaci.
Documentare le modalità di guasto e i runbook.
- Passaggi:
  - Registrare le procedure per il ripristino delle versioni degli oggetti, la revoca delle signed URL, il PITR di Cloud SQL e il recupero di tabelle BigQuery tramite time travel.
- Motivazione: runbook chiari e testati riducono il rischio operativo durante gli incidenti e standardizzano le pratiche di ripristino sicuro tra i team.