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 dei parametri di DynamoDB, consulta AWS il post del blog Monitoring Amazon DynamoDB for Operational Awareness per un elenco di 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 AWS sul blog Crea applicazioni resilienti con le tabelle globali di Amazon DynamoDB: parte 4.

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. Se limiti il controllo alla sola conferma che l'endpoint DynamoDB è attivo, non sarai in grado di coprire molte modalità di errore AWS Identity and Access Management come errori di configurazione (IAM), problemi di distribuzione del codice, errori nello stack esterno a DynamoDB, latenze di lettura o scrittura superiori alla media e così via.

Il prezzo di un'operazione di scrittura in una tabella DynamoDB tradizionale è espresso in unità di capacità di scrittura WCUs (per le tabelle fornite) o in unità di richiesta di scrittura () per le WRUs tabelle su richiesta. 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 (rWCUs, per le tabelle fornite) o in unità di richiesta di scrittura replicate (rWRUs, per le tabelle su richiesta). r e r hanno lo stesso prezzo di and. WCUs WRUs WGUs WRUs

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 r o r. WCUs WRUs L'acquisto di capacità riservata per WCUs può essere utile per le tabelle in cui si GSIs 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 desideri recuperare dati cancellati o modificati erroneamente, utilizza DynamoDB point-in-time recovery (PITR) in una regione.

CloudFormation rappresenta una tabella DynamoDB e una tabella globale come due risorse separate: e. AWS::DynamoDB::Table 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 distribuisci il modello, CloudFormation crea e aggiorna tutte le repliche come parte di un'unica operazione di stack. Non è consigliabile distribuire 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 disponi di una tabella normale e desideri convertirla in una tabella globale mantenendola gestita, imposta la politica di eliminazione suRetain, 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. CloudFormation Per ulteriori informazioni, consulta il AWS GitHub repository.

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