Panoramica delle tabelle globali

Aspetti chiave

• Esistono due versioni delle tabelle globali: la versione 2017.11.29 (precedente) (a volte chiamata v1) e la versione 2019.11.21 (attuale) (a volte chiamata v2). Questa guida si concentra esclusivamente sulla versione attuale.

• DynamoDB (senza tabelle globali) è un servizio regionale, il che significa che è altamente disponibile e intrinsecamente resiliente ai guasti dell'infrastruttura, incluso il guasto di un'intera zona di disponibilità. Una tabella DynamoDB a regione singola è progettata per una disponibilità del 99,99%. Per ulteriori informazioni, consulta il contratto sul livello di servizio (SLA) di DynamoDB.

• Una tabella globale DynamoDB replica i dati tra due o più regioni. Una tabella DynamoDB multiregione è progettata per una disponibilità del 99,999%. Con una pianificazione adeguata, le tabelle globali possono contribuire a creare un'architettura resiliente ai fallimenti regionali.

• 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 replica l'operazione di scrittura in altre regioni remote partecipanti in background.

• Gli elementi vengono replicati singolarmente. Gli elementi aggiornati all'interno di una singola transazione potrebbero non essere replicati insieme.

• Ogni partizione di tabella nella regione di origine replica le sue operazioni di scrittura in parallel con ogni altra partizione. La sequenza delle operazioni di scrittura all'interno di una regione remota potrebbe non corrispondere alla sequenza delle operazioni di scrittura avvenute 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 calcolato esaminando gli articoli in arrivo, confrontando l'ora di arrivo con il tempo di scrittura iniziale e calcolando una media. I tempi sono memorizzati all'interno della CloudWatch regione di origine. La visualizzazione dei tempi medi e massimi può essere utile per determinare il ritardo di replica medio e peggiore. Non esiste alcun Accordo sul livello di servizio (SLA) per questa latenza.

• Se un singolo elemento viene aggiornato all'incirca nello stesso momento (all'interno di questa ReplicationLatency finestra) in due regioni diverse e la seconda operazione di scrittura viene eseguita prima della replica della prima operazione di scrittura, è possibile che si verifichino conflitti di scrittura. Le tabelle globali risolvono tali conflitti utilizzando il meccanismo Last Writer Wins, basato sul timestamp delle operazioni di scrittura. La prima operazione «perde» rispetto alla seconda operazione. Questi conflitti non vengono registrati in CloudWatch oAWS CloudTrail.

• Il timestamp dell'ultima scrittura viene conservato come proprietà di sistema privata di ciascun elemento. L'approccio Last Writer Wins viene implementato utilizzando un'operazione di scrittura condizionale che richiede che il timestamp dell'elemento in arrivo sia maggiore del timestamp dell'elemento esistente.

• Una tabella globale replica tutti gli articoli in tutte le regioni partecipanti. Se desideri avere ambiti di replica diversi, puoi creare più tabelle globali e assegnare a ciascuna tabella diverse regioni partecipanti.

• La regione locale accetta operazioni di scrittura anche se la regione di replica è offline o ReplicationLatency cresce. 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 caso in cui una regione diventi completamente offline, quando tornerà online in un secondo momento, 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 dell'ultimo scrittore vince garantisce che i dati alla fine diventino coerenti.

• È possibile aggiungere una nuova regione a una tabella DynamoDB in qualsiasi momento. DynamoDB gestisce la sincronizzazione iniziale e la replica continua. Puoi anche rimuovere una regione (anche la regione originale) e questo eliminerà la tabella locale in quella regione.

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

• Le chiamate a DynamoDB non devono passare da una regione all'altra. La procedura migliore prevede che un'applicazione ospitata in una regione acceda direttamente solo all'endpoint DynamoDB locale per la regione. Se vengono rilevati problemi all'interno di una regione (nel livello DynamoDB o nello stack circostante), il traffico degli utenti finali deve essere indirizzato a un endpoint dell'applicazione diverso ospitato in una regione diversa. Le tabelle globali assicurano che l'applicazione presente in ogni regione abbia accesso agli stessi dati.

Casi d'uso

Le tabelle globali offrono i seguenti vantaggi comuni:

• Operazioni di lettura a latenza inferiore. È possibile posizionare una copia dei dati più vicino all'utente finale per ridurre la latenza di rete durante le operazioni di lettura. I dati vengono mantenuti aggiornati tanto quanto il ReplicationLatency valore.

• Operazioni di scrittura a latenza inferiore. Un utente finale può scrivere in una regione vicina per ridurre la latenza di rete e il tempo necessario per completare l'operazione di scrittura. Il traffico di scrittura deve essere indirizzato con attenzione per garantire che non vi siano conflitti. Le tecniche per il routing sono discusse in una sezione successiva.

• Resilienza e ripristino di emergenza migliorati. Se una regione presenta un calo delle prestazioni o un'interruzione completa, è possibile evacuarla (allontanando alcune o tutte le richieste rivolte a quella regione) e raggiungere un obiettivo del punto di ripristino (RPO) e un obiettivo del tempo di ripristino (RTO) misurati in secondi. L'utilizzo di tabelle globali aumenta anche lo SLA di DynamoDB per la percentuale di uptime mensile dal 99,99% al 99,999%.

• Migrazione regionale senza interruzioni. Puoi aggiungere una nuova regione e quindi eliminare la vecchia regione per migrare una distribuzione da una regione all'altra, senza tempi di inattività a livello di dati.

Ad esempio, Fidelity Investments ha presentato a re:Invent 2022 come utilizzano le tabelle globali DynamoDB per il loro sistema di gestione degli ordini. Il loro obiettivo era ottenere un'elaborazione affidabile a bassa latenza su una scala che non poteva raggiungere con l'elaborazione in locale, mantenendo al contempo la resilienza agli errori della zona di disponibilità e delle aree regionali.