Best practice per la progettazione di tabelle DynamoDB globali

Esistono due versioni delle tabelle globali: la versione attuale Global Tables versione 2019.11.21 (Current) (a volte chiamata «V2") e Tabelle globali versione 2017.11.29 (Legacy) (a volte chiamata «V1"). Questa guida fa riferimento esclusivamente alla versione corrente (V2).

Senza l'uso delle tabelle globali, DynamoDB è un servizio regionale. È caratterizzato da disponibilità elevata ed è intrinsecamente resiliente ai guasti dell'infrastruttura in una regione, inclusi i guasti in un'intera zona di disponibilità (AZ). Una tabella DynamoDB a regione singola è associata a un Accordo sul livello di servizio (SLA) https://aws.amazon.com/dynamodb/sla/ con disponibilità del 99,99%.

Con l'uso delle tabelle globali, DynamoDB consente a una tabella di replicare i propri dati tra due o più regioni. Una tabella DynamoDB multi-regione è associata a uno SLA con disponibilità del 99,999%. Con una pianificazione adeguata, le tabelle globali possono contribuire a creare un'architettura resiliente e resistente ai guasti a livello regionale.

Le tabelle globali utilizzano un modello di replica attivo-attivo. Dal punto di vista di DynamoDB, la tabella in ogni regione può accettare richieste di lettura e scrittura. Dopo aver ricevuto una richiesta di scrittura, la tabella di replica locale replicherà la scrittura in altre regioni partecipanti in background.

Gli elementi vengono replicati singolarmente. Gli elementi aggiornati all'interno di una singola transazione potrebbero non venire replicati congiuntamente.

Ogni partizione di tabella nella regione di origine replica le poprie scritture in parallelo con ogni altra partizione. La sequenza delle scritture all'interno della regione remota potrebbe non corrispondere alla sequenza delle scritture eseguite all'interno della regione di origine. Per ulteriori informazioni sulle partizioni delle tabelle, consulta il post del blog relativo al dimensionamento di DynamoDB e all'impatto sulle prestazioni di partizioni, tasti di scelta rapida e isolamento.

Un elemento appena scritto viene in genere propagato a tutte le tabelle di replica entro un secondo. La propagazione nelle regioni vicine è in genere più veloce.

Amazon CloudWatch fornisce una ReplicationLatency metrica per ogni coppia di regioni. Viene calcolata in base all'analisi degli elementi in arrivo e al confronto tra la relativa ora di arrivo e il tempo di scrittura iniziale. Viene infine calcolata una media. Le tempistiche sono memorizzate CloudWatch nella regione di origine. L'analisi dei tempi medi e massimi può aiutare a determinare il ritardo di replica medio e peggiore. Non esiste alcun Accordo sul livello di servizio (SLA) per questa latenza.

Se lo stesso elemento viene aggiornato all'incirca nello stesso momento (all'interno della finestra ReplicationLatency) in due regioni diverse e la seconda scrittura avviene prima della replica della prima scrittura, è possibile che si verifichino conflitti di scrittura. Le tabelle globali risolvono tali conflitti con un meccanismo basato sulla priorità dell'ultima istanza di scrittura, ovvero sul timestamp delle scritture. La prima scrittura "perde" rispetto alla seconda scrittura. Questi conflitti non vengono registrati in CloudWatch o AWS CloudTrail.

Il timestamp dell'ultima scrittura viene conservato come proprietà di sistema privata di ciascun elemento. L'approccio basato sulla priorità dell'ultima istanza di scrittura viene implementato utilizzando una scrittura condizionale che richiede che il timestamp dell'elemento in arrivo sia maggiore (cronologicamente successivo) del timestamp dell'elemento esistente.

Una tabella globale replicherà tutti gli elementi in tutte le regioni partecipanti. Per avere ambiti di replica diversi, è possibile creare tabelle diverse e assegnare a ciascuna di esse diverse regioni partecipanti.

Le scritture verranno accettate nella regione locale anche se la regione di replica è offline o se ReplicationLatency aumenta. La tabella locale continua a tentare di replicare gli elementi nella tabella remota finché la replica di ogni elemento non ha esito positivo.

Nell'improbabile eventualità che una regione risulti offline, quando in seguito torna online tutte le repliche in uscita e in entrata in sospeso verranno ritentate. Non è richiesta alcuna azione speciale per ripristinare la sincronizzazione delle tabelle. Il meccanismo basato sulla priorità dell'ultima istanza di scrittura garantisce la coerenza finale dei dati.

È possibile aggiungere una nuova regione a una tabella DynamoDB in qualsiasi momento. DynamoDB gestirà la sincronizzazione iniziale e la replica continua. Se una regione viene rimossa, anche se si tratta della regione originale, verrà eliminata solo la tabella di tale regione.

DynamoDB non ha un endpoint globale. Tutte le richieste vengono effettuate a un endpoint regionale, che quindi accede all'istanza globale della tabella locale di tale regione.

Le chiamate a DynamoDB non devono passare tra regioni. La best practice prevede che il livello di calcolo in una regione acceda direttamente solo all'endpoint DynamoDB locale per tale regione. Se vengono rilevati problemi all'interno di una regione, indipendentemente dal fatto che tali problemi si trovino nel livello DynamoDB o nello stack circostante, il traffico dell'utente finale deve essere indirizzato a un livello di elaborazione diverso ospitato in una regione diversa. Grazie alla replica delle tabelle globali, le diverse regioni disporranno già di una copia locale degli stessi dati con cui lavorare localmente. In alcune circostanze, il livello di calcolo in una regione può trasmettere la richiesta al livello di calcolo di un'altra regione per l'elaborazione, ma ciò non dovrebbe comportare l'accesso diretto all'endpoint DynamoDB remoto. Per ulteriori informazioni su questo particolare caso d'uso, consulta Instradamento delle richieste al livello di calcolo.

Letture con latenza minore. È possibile posizionare una copia dei dati più vicino all'utente finale per ridurre la latenza di rete durante le letture. L'aggiornamento della cache è in linea con l'aggiornamento del valore ReplicationLatency.

Scritture con latenza minore. È possibile scrivere in una regione vicina per ridurre la latenza di rete e il tempo impiegato per eseguire la scrittura. Il traffico di scrittura deve essere instradato con attenzione per garantire l'assenza di conflitti. Le tecniche di routing sono descritte in dettaglio in Instradamento delle richieste con le tabelle di richiesta.

Resilienza e ripristino di emergenza migliorati. È possibile evacuare una regione (eliminare alcune o tutte le richieste instradate a tale regione) in caso di riduzione delle prestazioni o di un'interruzione completa, con le funzionalità Obiettivo del punto di ripristino (RPO) e Obiettivo del tempo di ripristino (RTO), nel giro di pochi secondi. L'utilizzo delle tabelle globali aumenta anche la disponibilità dello SLA di DynamoDB dal 99,99% al 99,999%.

Migrazione regionale senza interruzioni. È possibile aggiungere una nuova regione e quindi eliminare la vecchia regione per eseguire la migrazione di una implementazione da una regione all'altra, il tutto senza tempi di inattività a livello di dati. Ad esempio, è possibile utilizzare le tabelle globali DynamoDB per un sistema di gestione degli ordini e ottenere un'elaborazione affidabile a bassa latenza su larga scala, conservando contemporaneamente la resilienza ai guasti a livello di zona di disponibilità e regione.