Nel percorso di modernizzazione applicativa e migrazione al cloud delle grandi organizzazioni bancarie ed enterprise, i database relazionali transazionali (OLTP) rappresentano da sempre il carico più critico, complesso e vincolante. La transizione da sistemi monolitici on-premise — come cluster Oracle RAC su appliance ingegnerizzate, IBM Db2 o cluster PostgreSQL virtualizzati su hypervisor VMware/KVM attestati su storage SAN enterprise — verso il cloud pubblico impone scelte architetturali che vanno ben oltre il mero dimensionamento di CPU e memoria.

Su Google Cloud, il catalogo per i motori compatibili con PostgreSQL offre due soluzioni pienamente gestite (fully managed): Cloud SQL for PostgreSQL e AlloyDB for PostgreSQL. Spesso valutate superficialmente come opzioni differenziate solo dal livello di prezzo e dalla capacità di calcolo, le due piattaforme poggiano in realtà su paradigmi architetturali antitetici: un'architettura a disco condiviso convenzionale (monolithic storage) contro un'architettura cloud-native a calcolo e storage disaccoppiati (disaggregated compute and storage).

Alla luce dei rigorosi requisiti imposti dal regolamento europeo DORA (Digital Operational Resilience Act) e dalle linee guida EBA sulla continuità operativa — che richiedono Recovery Point Objective (RPO) prossimo allo zero, Recovery Time Objective (RTO) deterministico e capacità di Disaster Recovery multi-regione testabili — comprendere i trade-off profondi tra Cloud SQL e AlloyDB è fondamentale per un Cloud Architect.

Architettura a Confronto: Persistent Disk vs Disaggregated Storage

La differenza sostanziale tra le due piattaforme non risiede nel motore di esecuzione SQL (entrambe garantiscono piena compatibilità PostgreSQL), ma nel modo in cui gestiscono l'I/O, i log transazionali (Write-Ahead Log - WAL) e la persistenza dei blocchi dati.

Ingrandisci

1. Cloud SQL: La Virtualizzazione della Macchina su Persistent Disk

Cloud SQL implementa un pattern classico: esegue PostgreSQL all'interno di una macchina virtuale Compute Engine gestita, collegata a volumi Regional Persistent Disk (Regional PD):

• Doppio Carico di I/O (Write Amplification): Il processo PostgreSQL primario deve scrivere sul disco sia i record WAL sia le pagine di memoria modificate (dirty buffer pool pages) durante le operazioni di checkpoint.
• Failover Zonale: L'Alta Disponibilità (HA) è implementata a livello di blocco di archiviazione. In caso di disservizio della zona primaria, Google Cloud avvia un'istanza standby nella seconda zona, aggancia il Regional PD e avvia il motore PostgreSQL. Questo processo richiede tra i 60 e i 120 secondi per completare l'aggancio del disco, l'inizializzazione del database e il crash recovery dei log non consolidati.
• Repliche di Lettura: Ciascuna read replica è un'istanza autonoma con il proprio Persistent Disk dedicato, che riceve gli aggiornamenti dal primario tramite lo streaming replication convenzionale di PostgreSQL su rete. In presenza di picchi di scrittura massivi, le repliche possono accumulare un sensibile replication lag, compromettendo la coerenza delle letture analitiche.

2. AlloyDB: Il Principio "The Log is the Database"

AlloyDB adotta un'architettura a calcolo e storage disaccoppiati (disaggregated storage), concettualmente analoga ad Amazon Aurora ma ingegnerizzata nativamente sull'infrastruttura Google:

• Separazione Netta di Calcolo e Memoria: Il nodo di calcolo (Compute Instance) non esegue checkpoint di pagine disco verso lo storage. Invia unicamente il flusso compresso dei record WAL a uno Storage Engine distribuito intelligente, costruito direttamente sopra Colossus, il file system distribuito planetario di Google. Colossus assicura replica continua multi-zona, throughput elastico e durabilità enterprise a livello hardware.
• Elaborazione Asincrona dei Log (Log Processing Service): Il layer di storage incorpora microservizi distribuiti (Log Processing Service) che processano i record WAL in background e mantengono aggiornati i blocchi dati su unità NVMe ultra-veloci gestite da Colossus, sollevando la CPU primaria dall'I/O di checkpoint.
• Failover Zonale Sub-Secondo: Tutte le istanze di lettura (Read Pool) condividono direttamente lo stesso storage distribuito. Se l'istanza primaria collassa, una delle repliche del read pool viene promossa a primario in meno di 1 secondo, poiché non deve riprodurre gigabyte di WAL da disco né attendere lo switch di volumi fisici.
• AlloyDB Columnar Engine: Consente di mantenere in memoria cache una rappresentazione colonnare vettoriale dei dati transazionali per query analitiche e reportistiche (HTAP), accelerando le scansioni tabellari fino a 100 volte senza gravare sull'elaborazione OLTP.

Continuità Operativa e Conformità DORA nel Banking

Il regolamento europeo DORA impone requisiti stringenti di resilienza per le istituzioni finanziarie:

1. RPO (Recovery Point Objective): Riduzione quasi a zero della perdita di dati ammissibile in caso di disservizio catastrofico.
2. RTO (Recovery Time Objective): Ripristino rapido e prevedibile del servizio core banking.
3. Disaster Recovery Multi-Regione: Capacità di eseguire failover cross-region senza impattare l'integrità del dato contabile.

Il Confronto Multi-Regione

Nelle architetture multi-regione per la mitigazione del rischio sistemico:

• Cloud SQL Cross-Region Read Replica: La replica su una seconda regione è asincrona. In caso di outage regionale completo della primary region, la replica secondaria deve essere "promossa" a database standalone. Questa operazione è irreversibile: scollega l'istanza dalla topologia di replica, richiede la riconfigurazione manuale o via Terraform delle connessioni applicative e rende estremamente complessa la procedura di failback non appena la regione principale torna operativa.
• AlloyDB Secondary Cluster: AlloyDB introduce il concetto di Secondary Cluster multi-regione. La sincronizzazione tra cluster primario e secondario avviene direttamente a livello di layer di storage Colossus, con un RPO target nell'ordine di pochi secondi (e tipicamente sub-secondo in condizioni standard di carico). La promozione del cluster secondario a primario può essere gestita in modo pulito e, soprattutto, l'architettura supporta il failback controllato: il vecchio cluster primario può essere re-integrato come secondario senza dover rieseguire il restore completo da backup.

Matrice Comparativa: Cloud SQL vs AlloyDB

Implementazione Infrastructure as Code con Terraform

Di seguito è riportato il modulo Terraform per il deployment di un cluster AlloyDB ad alta resilienza enterprise con nodo primario HA, read pool con columnar engine abilitato e secondary cluster multi-regione per disaster recovery conforme a DORA.

terraform {
  required_version = ">= 1.14.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}

# 1. Cluster Primario ad Alta Disponibilità (Regione Primaria: europe-west8 - Milano)
resource "google_alloydb_cluster" "primary" {
  cluster_id = "alloydb-banking-primary"
  location   = var.primary_region # europe-west8 (Milano)
  network_config {
    network = var.vpc_network_id
  }

  initial_user {
    user     = "dba_admin"
    password = var.db_admin_password
  }

  automated_backup_policy {
    enabled = true
    weekly_schedule {
      days_of_week = ["MONDAY", "WEDNESDAY", "FRIDAY", "SUNDAY"]
      start_times {
        hours   = 2
        minutes = 0
      }
    }
    retention_period = "2592000s" # 30 giorni di retention conforme alle policy bancarie
    location         = var.dr_region      # Replica geografica dei backup su europe-west12
  }
}

# Istanza Primaria Write-Read
resource "google_alloydb_instance" "primary_instance" {
  cluster       = google_alloydb_cluster.primary.name
  instance_id   = "primary-instance-01"
  instance_type = "PRIMARY"

  machine_config {
    cpu_count = 16 # 16 vCPU, 128 GB RAM per workload OLTP intensivo
  }

  availability_type = "REGIONAL" # Alta disponibilità zonale garantita

  database_flags = {
    "google_columnar_engine.enabled" = "on"
    "google_columnar_engine.memory_size_in_mb" = "32768"
    "password.enforce_complexity" = "on"
  }
}

# 2. Cluster Secondario di Disaster Recovery (Regione Secondaria: europe-west12 - Torino)
resource "google_alloydb_cluster" "secondary_dr" {
  cluster_id       = "alloydb-banking-secondary-dr"
  location         = var.dr_region # europe-west12 (Torino)
  cluster_type     = "SECONDARY"

  network_config {
    network = var.vpc_network_id
  }

  secondary_config {
    primary_cluster_name = google_alloydb_cluster.primary.name
  }

  depends_on = [google_alloydb_instance.primary_instance]
}

# Istanza di Failover nel Cluster Secondario
resource "google_alloydb_instance" "secondary_instance" {
  cluster       = google_alloydb_cluster.secondary_dr.name
  instance_id   = "secondary-instance-01"
  instance_type = "SECONDARY"

  machine_config {
    cpu_count = 16
  }

  availability_type = "REGIONAL"
}

Guida alla Scelta: Quando Adottare Cloud SQL o AlloyDB

La scelta tra le due tecnologie deve essere guidata dal profilo di rischio e dalle caratteristiche del carico:

Quando scegliere Cloud SQL for PostgreSQL

• Workload dipartimentali o non critici: Ambienti di sviluppo, staging o microservizi satellite con requisiti di RTO permissivi (> 60 secondi).
• Volumetrie e I/O moderati: Database con dataset inferiori a 1 TB e traffico di scrittura non concorrenziale.
• Costi infrastrutturali base contenuti: Esigenza di ridurre i costi fissi tramite istanze entry-level a 1–2 vCPU con dischi ridotti.

Quando scegliere AlloyDB for PostgreSQL

• Sistemi Core Banking e Payment Processing: Piattaforme transazionali e ledger contabili dove anche 60–120 secondi di failover zonale violano gli SLA o incorrono in sanzioni regolamentari.
• Carichi ad alta intensità di scrittura: Applicazioni OLTP con frequenti update concorrenziali che soffrirebbero del collo di bottiglia dei checkpoint disco di PostgreSQL tradizionale.
• Analitica e reportistica real-time (HTAP): Necessità di interrogare i dati di produzione ad alta velocità tramite il Columnar Engine senza sviluppare pipeline ETL intermedie.
• Piani di Disaster Recovery multi-regione verificabili: Architetture di continuità operativa conformi a DORA con RPO target rigorosamente nell'ordine dei secondi e failback non distruttivo.