Sommario

I requisiti di continuità operativa per i sistemi di pagamento e il core banking impongono una tolleranza ai guasti che va oltre la singola Availability Zone. Con l'applicazione del regolamento europeo DORA (Digital Operational Resilience Act), gli istituti finanziari devono dimostrare la capacità tecnica di superare l'indisponibilità di un'intera regione cloud senza perdite di dati transazionali (RPO = 0) e con tempi di ripristino sub-minuto (RTO < 60s). Questo articolo esplora i trade-off architetturali tra modelli Active-Passive ottimizzati e architetture Active-Active distribuite, analizzando la propagazione dello stato dei dati, il global traffic routing e le strategie di Chaos Engineering necessarie per validare la resilienza in produzione.

La sfida del fallimento d'area e il vincolo di coerenza nei dati bancari

Nel cloud computing, la disponibilità ad alto livello all'interno di una singola regione (multi-AZ) protegge contro guasti a singoli datacenter o hardware fisici. Tuttavia, eventi sistemici complessi — come interruzioni prolungate della connettività dorsale, corruzione del control plane DNS o incidenti energetici su vasta scala — possono rendere un'intera regione geografica indisponibile.

Nel settore bancario, la progettazione di un'architettura multi-regione deve affrontare il celebre Teorema CAP applicato alla latenza fisica della luce su fibra ottica:

• La distanza fisica tra le regioni: Tra Milano (eu-south-1) e Francoforte (eu-central-1) la latenza di rete round-trip (RTT) si attesta tra i 12ms e i 18ms.
• Transazioni sincrone vs asincrone: La replica sincrona a due fasi (2PC / synchronous commit) garantisce RPO = 0 (nessuna perdita di dati), ma introduce una penalizzazione sulla latenza di scrittura inaccettabile per transazioni di autorizzazione carta o trading ad alta frequenza.
• Rischio di Split-Brain: Durante una partizione di rete tra regioni, se entrambi i nodi credono di essere master attivi, si generano scritture concorrenti divergenti e insanabili sui saldi contabili dei clienti.

La scelta architetturale deve quindi bilanciare la consistenza forte del dato finanziario con la continuità del servizio erogato all'utente finale.

Modelli architetturali a confronto: Active-Passive Warm vs Active-Active Globale

Per gestire la resilienza su carichi mission-critical bancari si utilizzano due macro-pattern principali:

flowchart TD
    subgraph ClientLayer["Edge & Global Anycast Layer"]
        Users["Client / Mobile Banking / ATM"] --> Anycast["Global Load Balancer / Cloudflare Anycast"]
        Anycast --> HealthProbe{"Global Health Routing"}
    end

    subgraph PrimaryRegion["Primary Region: Milan (eu-south-1)"]
        HealthProbe -->|Active 100% Traffic| GatewayA["API Gateway / Ingress Envoy"]
        GatewayA --> AppA["Microservices Core (EKS / GKE)"]
        AppA --> MasterDB[("Primary Database (Read/Write)")]
    end

    subgraph SecondaryRegion["Secondary Region: Frankfurt (eu-central-1)"]
        HealthProbe -.->|Failover Traffic on Incident| GatewayB["API Gateway / Ingress Envoy"]
        GatewayB --> AppB["Standby Microservices (Warm Replica)"]
        AppB --> ReplicaDB[("Read Replica / Secondary Sync")]
    end

    MasterDB -->|Replication Stream (WAL / Change Streams)| ReplicaDB
    QuorumWitness["Independent Quorum Witness (Region 3 / On-Prem)"] -.-> MasterDB
    QuorumWitness -.-> ReplicaDB

1. Active-Passive "Warm Standby" con Failover Automatizzato

Questo modello rappresenta la soluzione più comune ed economicamente efficiente per la maggior parte dei servizi bancari:

• Regione Primaria: Elabora il 100% del traffico in lettura e scrittura.
• Regione Secondaria: Mantiene l'infrastruttura di calcolo (Kubernetes cluster, container) pre-istanziata a capacità minima (warm), mentre il database riceve lo streaming continuo dei Write-Ahead Log (WAL) con replica asincrona o semi-sincrona a basso ritardo (< 500ms).
• Riconciliazione automatica del DNS: Un quorum esterno (posizionato su una terza regione cloud o on-premise) monitora continuamente gli health check sintetici. Se la regione primaria smette di rispondere per più di 30 secondi, il quorum promuove il database secondario a master e aggiorna i record DNS Anycast.

2. Active-Active con Database Distribuiti a Consenso Quorum

Per i circuiti di pagamento interbancari dove anche pochi secondi di indisponibilità comportano sanzioni regolamentari, si adotta un'architettura Active-Active distribuita basata su motori dati multi-regione nativi (come Google Cloud Spanner, AWS Aurora Global Database con write forwarding, o CockroachDB/YugabyteDB basati su algoritmo Raft):

• I dati sono partizionati logicamente su base geografica o per range di account.
• Le scritture richiedono il consenso della maggioranza dei nodi del quorum (2 su 3 zone/regioni).
• Entrambe le regioni elaborano traffico utente contemporaneamente. Se una regione scompare, il cluster mantiene il quorum grazie alla terza regione "witness" e continua a processare scritture senza alcun intervento manuale né riconfigurazione DNS.

Esempio di configurazione Health Routing e Failover con Terraform

Il codice seguente definisce una regola di routing globale con health check continuo e fallback automatico in caso di indisponibilità della regione primaria:

# Health Check sulla regione primaria (Milano)
resource "aws_route53_health_check" "milan_primary_health" {
  fqdn              = "api-eu-south.bank.corp"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz/deep-readiness"
  failure_threshold = 3
  request_interval  = 10

  tags = {
    Environment = "production"
    Tier        = "core-payments"
  }
}

# Record DNS di Failover per il servizio pagamenti
resource "aws_route53_record" "payments_primary" {
  zone_id = data.aws_route53_zone.corporate.zone_id
  name    = "payments.bank.corp"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "milan-primary"
  health_check_id = aws_route53_health_check.milan_primary_health.id

  alias {
    name                   = data.aws_lb.milan_alb.dns_name
    zone_id                = data.aws_lb.milan_alb.zone_id
    evaluate_target_health = true
  }
}

resource "aws_route53_record" "payments_secondary" {
  zone_id = data.aws_route53_zone.corporate.zone_id
  name    = "payments.bank.corp"
  type    = "A"

  failover_routing_policy {
    type = "SECONDARY"
  }

  set_identifier = "frankfurt-standby"

  alias {
    name                   = data.aws_lb.frankfurt_alb.dns_name
    zone_id                = data.aws_lb.frankfurt_alb.zone_id
    evaluate_target_health = true
  }
}

Chaos Engineering e Validazione Periodica della Resilienza per DORA

Un piano di disaster recovery non testato in condizioni reali non offre alcuna garanzia durante un incident effettivo. L'articolo 24 del regolamento DORA impone l'esecuzione di test periodici di resilienza digitale (Threat-Led Penetration Testing e scenari di interruzione controllata).

Nel cloud enterprise, questa validazione viene eseguita tramite framework di Chaos Engineering automatizzati (es. Chaos Mesh, AWS Fault Injection Simulator o LitmusChaos):

1. Iniezione del Guasto: Vengono simulate interruzioni delle route del Transit Gateway tra la regione primaria e il database centrale, oppure viene forzato il blocco delle chiamate API su un intero pool di nodi.
2. Verifica dei Metadati di Failover: Si misurano in tempo reale i valori effettivi di:
3. RTO reale: Tempo impiegato dal sistema per reindirizzare il 99.9% delle chiamate HTTP 200 OK verso la regione secondaria.
4. RPO reale: Verifica crittografica dell'ultimo transaction_id registrato nella regione primaria rispetto all'ultimo importato nella regione di fallback.
5. Reportistica di Compliance: I risultati del test (inclusi grafici di latenza, log di riconciliazione e log di audit immutabili) vengono generati automaticamente e archiviati per le ispezioni dell'EBA e della Banca d'Italia.

Conclusione

La resilienza cloud nel settore finanziario non è un attributo statico che si acquista dal cloud provider, ma una disciplina architetturale rigorosa che integra progettazione software, replica deterministica dello stato dei dati e validazione empirica continua.

Per un Cloud Architect enterprise, governare architetture multi-regione significa superare i dogmi teorici e dimensionare i pattern di failover sui vincoli reali del business: garantire RPO nullo sui libri contabili, contenere i costi infrastrutturali ed eliminare qualsiasi singolo punto di fallimento per assicurare la fiducia dei clienti e la piena conformità normativa.