DynamoDB Global Tables: la replica multi-regione spiegata

Una global table è un'unica tabella DynamoDB replicata su più regioni AWS, dove ogni replica è scrivibile. DynamoDB le tiene sincronizzate automaticamente — ottieni letture e scritture locali a bassa latenza in ogni regione più disaster recovery cross-regione, senza gestire la tua replica.

Nello scenario dell'audit-log, un cliente UE richiede che i propri dati risiedano in eu-west-1, mentre il resto gira in us-east-1. E trattandosi di un log critico per la compliance, deve sopravvivere a un'interruzione completa di una regione. Una global table risponde a entrambi con una sola funzionalità.

Come funzionano le DynamoDB Global Tables?

Le DynamoDB Global Tables sono un'unica tabella replicata su più regioni AWS, dove ogni replica è leggibile e scrivibile. DynamoDB le sincronizza automaticamente tramite replica asincrona eventualmente coerente, risolvendo i conflitti last-writer-wins. Ottieni letture e scritture locali a bassa latenza per regione più disaster recovery cross-regione, a supporto dello SLA di disponibilità del 99,999% di DynamoDB.

• Multi-regione, attiva-attiva. Ogni replica è pienamente leggibile e scrivibile; le scritture in qualsiasi regione si propagano alle altre.
• Nella modalità predefinita, la replica è asincrona ed eventualmente coerente tra le regioni — tipicamente entro un secondo, ma non istantanea. (Esiste anche una modalità a coerenza forte — vedi sotto.)
• I conflitti si risolvono last-writer-wins. Scritture concorrenti sullo stesso item in due regioni si riconciliano su quella più recente.
• Supporta lo SLA di disponibilità del 99,999% — una global table multi-regione è la configurazione a più alta disponibilità di DynamoDB.

Il problema: una regione non basta

Una tabella a regione singola ha due limiti che l'audit log non può accettare. Primo, la residenza dei dati: gli eventi di un cliente UE devono essere memorizzati nell'UE, ma la tua app gira negli USA. Secondo, il disaster recovery: se us-east-1 ha un'interruzione, un audit log a regione singola è illeggibile e non scrivibile per tutta la durata — esattamente quando hai più bisogno del registro di ciò che è successo.

Costruire l'uno o l'altro da solo — replica cross-regione, failover, gestione dei conflitti — è un progetto grande e soggetto a errori. Le global table lo rendono una scelta di configurazione.

Meccanica della replica

Aggiungi una regione replica alla tabella; DynamoDB ne crea una copia lì e tiene tutte le repliche sincronizzate.

Due regole di coerenza definiscono il comportamento predefinito (MREC):

• La replica cross-regione è asincrona. Una scrittura in us-east-1 è riconosciuta localmente, poi propagata a eu-west-1 — di solito entro un secondo, ma una lettura nell'altra regione subito dopo una scrittura potrebbe non vederla ancora. (Nella modalità MREC predefinita, le letture fortemente coerenti funzionano ancora, ma solo all'interno di una singola regione.)
• I conflitti sono last-writer-wins. Se lo stesso item viene scritto in due regioni quasi contemporaneamente, DynamoDB mantiene la scrittura con il timestamp più recente e scarta l'altra.

Un esempio pratico: una replica UE che è anche DR

Aggiungi eu-west-1 come replica della tabella audit-log. Ora:

L'app del cliente UE scrive su e legge dalla replica locale eu-west-1 — bassa latenza e dati residenti in-regione. La stessa replica che soddisfa la residenza fa anche da disaster recovery: se us-east-1 va giù, la replica eu-west-1 tiene ancora il log completo e serve traffico; fai failover su di essa.

Poiché l'audit log è append-only e partizionato per tenant, il last-writer- wins è essenzialmente un non-problema qui — gli eventi di un dato tenant sono scritti da una regione e le chiavi evento sono uniche, quindi due regioni raramente corrono sullo stesso item. Non è fortuna; è il motivo per cui un log append-only è uno dei casi più puliti per le global table. Un contatore mutabile, al contrario, richiederebbe attenzione sotto scritture cross-regione concorrenti.

Fallo in DynoTable

Dopo aver aggiunto una replica vuoi confermare che i dati siano effettivamente atterrati nella nuova regione e corrispondano alla fonte — che la replica UE contenga davvero gli eventi di acme, con gli attributi giusti, e non sia in ritardo.

DynoTable si connette a qualsiasi regione con le proprie credenziali, così che tu possa puntare una finestra su us-east-1 e un'altra su eu-west-1 e confrontare gli item dello stesso tenant fianco a fianco per verificare la replica.

Puoi prototipare le query per-regione che eseguirai contro ogni replica nel DynamoDB Expression Builder.

Insidie e passaggi successivi

• Non leggere la tua stessa scrittura tra regioni. Il ritardo di replica significa che una scrittura in una regione potrebbe non comparire in un'altra per ~un secondo. Non scrivere negli USA e poi leggere subito dall'UE aspettandoti di trovarla. Nella modalità MREC predefinita, le letture fortemente coerenti funzionano solo all'interno di una singola regione; MRSC estende le letture forti tra regioni.
• Il last-writer-wins scarta dati silenziosamente. Per item mutabili scritti in modo concorrente in due regioni, il perdente viene scartato senza errore. I design append-only o a singolo writer per item (come questo audit log) evitano il problema; lo stato mutabile condiviso ha bisogno di un design conscio dei conflitti.
• Ogni replica costa. Ogni regione memorizza una copia completa e fattura la propria capacità e storage — una replica raddoppia grosso modo il costo. Aggiungi regioni per una reale esigenza di residenza o DR, non per default.
• I backup sono per-replica. Una global table ripristinata diventa una tabella indipendente — pianifica il recupero per regione. Vedi backup e ripristino temporizzato.

Le global table proteggono dalla perdita di una regione. L'ultima preoccupazione operativa è proteggersi dalla perdita di dati — un deploy sbagliato o una cancellazione accidentale — con backup e ripristino temporizzato.

Scarica DynoTable per connetterti a più regioni e verificare che le tue repliche di global table contengano gli stessi dati.