Elenco di controllo di preparazione per tabelle globali DynamoDB

Determina se il caso d’uso trae maggiori vantaggi da una modalità di coerenza MRSC o MREC. È necessaria un’elevata consistenza, anche con una latenza più elevata e altri compromessi?

Determina quante e quali Regioni devono essere incluse nella tabella globale. Se intendi utilizzare MRSC, decidi se desideri che la terza Regione sia una replica o un testimone.

Determina la modalità di scrittura dell’applicazione. Questa non è la stessa della modalità di coerenza. Per ulteriori informazioni, consulta Modalità di scrittura con le tabelle globali DynamoDB.

Pianifica la strategia Strategie di instradamento in DynamoDB in base alla modalità di scrittura scelta.

Definisci i Processi di evacuazione in base alla modalità di coerenza, alla modalità di scrittura e alla strategia di instradamento scelti.

Acquisisci metriche su integrità, latenza ed errori in ogni Regione. Per un elenco delle metriche di DynamoDB, consulta il post relativo al monitoraggio di Amazon DynamoDB per la consapevolezza operativa nel blog AWS per un elenco delle metriche da osservare. È inoltre consigliabile utilizzare canary sintetici (richieste artificiali progettate per rilevare i guasti), nonché l'osservazione in tempo reale del traffico dei clienti. Non tutti i problemi verranno visualizzati nelle metriche di DynamoDB.

In caso di utilizzo di MREC, imposta allarmi per qualsiasi aumento prolungato di ReplicationLatency. Un incremento potrebbe indicare una configurazione errata accidentale in cui la tabella globale ha impostazioni di scrittura diverse in varie regioni, il che porta a richieste replicate non riuscite e a un aumento della latenza. Potrebbe anche indicare che si è verificata un'interruzione dei servizi a livello regionale. Un buon esempio è generare un avviso se il valore medio recente supera i 180.000 millisecondi. È anche possibile controllare se ReplicationLatency scende a 0; ciò indica una replica bloccata.

Assegna impostazioni massime di lettura e scrittura sufficienti per ogni tabella globale.

Individuare in anticipo i motivi dell'evacuazione di una regione. Se la decisione implica un giudizio umano, documentare tutte le considerazioni. Questa fase deve essere svolta con attenzione in anticipo, non in situazioni di stress.

Gestire un runbook per ogni operazione da eseguire in caso di evacuazione di una regione. Di solito è richiesto pochissimo lavoro per le tabelle globali, ma il trasferimento del resto dello stack potrebbe essere una procedura complessa.

Per ulteriori informazioni, consulta il post relativo alla creazione di applicazioni resilienti con le tabelle globali di Amazon DynamoDB (parte 4) nel blog AWS.

Testa periodicamente tutti gli aspetti del runbook, comprese le evacuazioni della Regione. Un runbook non testato è un runbook inaffidabile.

Considera la possibilità di utilizzare AWS Resilience Hub per valutare la resilienza dell’intera applicazione (comprese le tabelle globali). Fornisce una visione completa dello stato di resilienza complessivo del portafoglio di applicazioni tramite il relativo pannello di controllo.

Considera la possibilità di utilizzare i controlli di idoneità del sistema ARC per valutare la configurazione corrente dell’applicazione e tenere traccia di eventuali anomalie rispetto alle best practice.

In caso di scrittura di controlli di integrità da utilizzare con Route 53 o Global Accelerator, esegui una serie di chiamate che coprano l’intero flusso del database. In caso di limitazione del controllo alla sola conferma che l’endpoint DynamoDB è attivo, non sarà possibile coprire molte modalità di guasto come errori di configurazione AWS Identity and Access Management (IAM), problemi di implementazione del codice, guasti nello stack esterno a DynamoDB, latenze di lettura o scrittura superiori alla media e così via.

Il prezzo di un’operazione di scrittura su una tabella DynamoDB tradizionale è espresso in unità di capacità di scrittura (WCU, Write Capacity Units) per tabelle con provisioning o unità di richiesta di scrittura (WRU, Write Request Units), per tabelle on demand. In caso di scrittura di un elemento da 5 KB, viene addebitato un costo pari a 5 unità. Il prezzo di un’operazione di scrittura su una tabella globale è espresso in unità di capacità di scrittura replicate (rWCU, replicate Write Capacity Units), per tabelle con provisioning, o unità di richiesta di scrittura replicate (rWRU, replicated Write Request Units), per tabelle on demand. Per le rWCU e le rWRU il prezzo è lo stesso che per le WCU e le WRU.

I costi di rWCU e rWRU vengono applicati in tutte le Regioni in cui l’elemento viene scritto direttamente o tramite una replica. Si applicano tariffe per il trasferimento di dati tra regioni.

La scrittura su un indice secondario globale (GSI) è considerata una scrittura locale e utilizza le normali unità di scrittura.

Al momento non è disponibile alcuna capacità riservata per le rWCU o rWRU. L’acquisto di capacità riservata per le WCU può essere utile per le tabelle in cui i GSI consumano unità di scrittura.

Quando aggiungi una nuova Regione a una tabella globale, DynamoDB avvia automaticamente la nuova Regione e ti addebita come se si trattasse di un ripristino della tabella, in base alla sua dimensione in GB. Addebita inoltre tariffe aggiuntive per il trasferimento di dati tra regioni.

Set della Regione degli Stati Uniti: Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (Oregon)

Set della Regione Europa: Europa (Irlanda), Europa (Londra), Europa (Parigi), Europa (Francoforte)

Set della Regione Asia Pacifico: Asia Pacifico (Tokyo), Asia Pacifico (Seoul) e Asia Pacifico (Osaka)

È possibile eliminare una tabella di replica con la stessa procedura usata per eliminare qualsiasi altra tabella. Ciò interromperà la replica ed eliminerà la copia della tabella conservata in tale regione. Tuttavia, non è possibile interrompere la replica e conservare le copie della tabella come entità indipendenti, né è possibile sospendere la replica.

Una tabella MRSC deve essere distribuita esattamente in tre Regioni. Per eliminare le repliche è necessario eliminare tutte le repliche e il testimone in modo che la tabella MRSC diventi una tabella locale.

Ogni tabella globale produce un flusso indipendente basato su tutte le relative operazioni di scrittura, a prescindere dal punto di partenza. È possibile scegliere di utilizzare il flusso DynamoDB in una regione o in tutte le regioni in modo indipendente. Per elaborare operazioni di scrittura locali non replicate, è possibile aggiungere l’attributo relativo alla regione a ciascun elemento. È quindi possibile utilizzare un filtro di eventi Lambda per richiamare solo la funzione Lambda per le operazioni di scrittura nella regione locale. Questa procedura serve per le operazioni di inserimento e aggiornamento, ma non per le operazioni di eliminazione.

Le tabelle globali configurate per la coerenza finale tra più Regioni (tabelle MREC) replicano le modifiche leggendo tali modifiche da un flusso DynamoDB su una tabella di replica e applicandole a tutte le altre tabelle di replica. Pertanto, DynamoDB è abilitato per impostazione predefinita su tutte le repliche in una tabella globale MREC e non può essere disabilitato su tali repliche. Il processo di replica MREC può combinare più modifiche in un breve periodo di tempo in un’unica operazione di scrittura replicata. Di conseguenza, il flusso di ogni replica potrebbe contenere record leggermente diversi. I record dei flussi DynamoDB sulle repliche MREC vengono sempre ordinati per elemento, ma l’ordinamento tra gli elementi potrebbe differire tra le repliche.

Le tabelle globali configurate per un’elevata consistenza multi-Regione (tabelle MRSC) non utilizzano i flussi DynamoDB per la replica, quindi questa funzionalità non è abilitata per impostazione predefinita sulle repliche MRSC. È possibile abilitare i flussi DynamoDB su una replica MRSC. I record dei flussi DynamoDB sulle repliche MRSC sono identici per ogni replica e vengono sempre ordinati per elemento, ma l’ordinamento tra gli elementi potrebbe differire tra le repliche.

Le operazioni transazionali sulle tabelle MRSC genereranno errori.

Le operazioni transazionali sulle tabelle MREC forniscono garanzie di atomicità, consistenza, isolamento e durabilità (ACID) solo all’interno della Regione in cui si è originariamente verificata l’operazione di scrittura. Le transazioni non sono supportate tra le regioni nelle tabelle globali. Ad esempio, se è presente una tabella globale MREC con repliche nelle Regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) e si esegue un’operazione TransactWriteItems nella Regione Stati Uniti orientali (Ohio), è possibile osservare transazioni parzialmente completate nella Regione Stati Uniti occidentali (Oregon) man mano che le modifiche vengono replicate. Le modifiche vengono replicate in altre Regioni solo dopo essere state confermate nella Regione di origine.

Se è necessario garantire la durabilità dei dati, DynamoDB fornisce già questa protezione. Il servizio garantisce la durabilità dei dati.

Se si desidera conservare uno snapshot dei record storici (ad esempio per soddisfare i requisiti normativi), il backup in una regione dovrebbe essere sufficiente. È possibile copiare il backup in altre regioni utilizzando AWS Backup.

Se si desidera ripristinare dati eliminati o modificati per errore, utilizzare il ripristino point-in-time (PITR) di DynamoDB in una Regione.

CloudFormation rappresenta una tabella DynamoDB e una tabella globale come due risorse distinte, ovvero AWS::DynamoDB::Table e AWS::DynamoDB::GlobalTable. Un approccio consiste nel creare tutte le tabelle che possono essere potenzialmente globali utilizzando il costrutto GlobalTable per mantenerle inizialmente come tabelle autonome e aggiungere Regioni in un secondo momento, se necessario.

In CloudFormation, ogni tabella globale è controllata da un singolo stack, in una singola regione, indipendentemente dal numero di repliche. Quando il modello viene distribuito, CloudFormation crea e aggiorna tutte le repliche come parte di un'operazione a stack singolo. Non è consigliabile implementare la stessa risorsa AWS::DynamoDB::GlobalTable in più Regioni. Questo metodo non è supportato e genererà errori. Se si distribuisce il modello di applicazione in più regioni, è possibile utilizzare le condizioni per creare la risorsa AWS::DynamoDB::GlobalTable solo in una regione. In alternativa, è possibile scegliere di definire le risorse AWS::DynamoDB::GlobalTable in uno stack separato dallo stack dell'applicazione e verificare che sia distribuito solo in un'unica regione.

Se è presente una tabella normale e si desidera convertirla in una tabella globale mantenendola gestita da CloudFormation, imposta la policy di eliminazione su Retain, rimuovi la tabella dallo stack, converti la tabella in una tabella globale nella console e quindi importa la tabella globale come nuova risorsa nello stack. Per ulteriori informazioni, consulta il repository GitHub AWS.

La replica su più account non è al momento supportata.