Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzare il seguente elenco di controllo per decisioni e attività relative all'implementazione delle tabelle globali.
Determinare quante e quali regioni devono essere incluse nella tabella globale.
Determinare la modalità di scrittura dell'applicazione. Per ulteriori informazioni, consulta Modalità di scrittura con tabelle globali DynamoDB.
Pianificare la strategia Routing delle richieste con tabelle globali DynamoDB in base alla modalità di scrittura scelta.
Definite il vostro piano di evacuazione, in base alla modalità di scrittura e alla strategia di routing.
Acquisire le 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. Impostare allarmi per qualsiasi incremento 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. Potresti anche fare attenzione a non ReplicationLatencyscendere a 0, che indica che la replica è in stallo.Assegnare 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.
Nota
È consigliabile fare affidamento solo sulle operazioni del piano dati e non sulle operazioni del piano di controllo (control-plane) perché alcune operazioni del piano di controllo (control-plane) potrebbero essere degradate durante i guasti a livello di regione.
Per ulteriori informazioni, consulta il post AWS sul blog Crea applicazioni resilienti con le tabelle globali di Amazon DynamoDB
: parte 4. Testare periodicamente tutti gli aspetti del runbook, comprese le evacuazioni della regione. Un runbook non testato è un runbook inaffidabile.
Considerare la possibilità di utilizzare 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.
Prendi in considerazione l'utilizzo dei controlli di fattibilità ARC per valutare la configurazione corrente della tua applicazione e tenere traccia di eventuali scostamenti dalle best practice.
Quando si scrive un controllo dell'integrità da utilizzare con Route 53 o Global Accelerator, non è sufficiente inviare un ping per indicare che l'endpoint DynamoDB sia attivo. Questa procedura non copre le numerose modalità di errore come gli errori di configurazione IAM, i problemi di implementazione del codice, gli errori nello stack esterno a DynamoDB, le latenze di lettura o scrittura superiori alla media e così via. È preferibile eseguire una serie di chiamate che generino un flusso completo del database.
Domande frequenti relative alla distribuzione delle tabelle globali
Quali sono alcuni principi utili per l'utilizzo generale delle tabelle globali DynamoDB?
Le tabelle globali DynamoDB sono caratterizzate da un numero esiguo di punti di controllo, ma richiedono comunque una serie di considerazioni. È necessario determinare la modalità di scrittura, il modello di instradamento e i processi di evacuazione. È necessario dotare l'applicazione della strumentazione necessaria in ogni regione ed essere pronti a modificare l'instradamento o eseguire un'evacuazione per salvaguardare l'integrità globale. Il vantaggio che ne deriva è la disponibilità di un set di dati distribuiti a livello globale con letture e scritture a bassa latenza e un accordo sul livello di servizio (SLA) con disponibilità del 99,999%.
Quali sono i prezzi delle tabelle globali?
Il prezzo di una scrittura su una tabella DynamoDB tradizionale è espresso in Write Capacity Units WCUs (per le tabelle con provisioning) o Write Request Units WRUs (per le tabelle on-demand). In caso di scrittura di un elemento da 5 KB, viene addebitato un costo pari a 5 unità. Il prezzo di una scrittura su una tabella globale è espresso in Replicated Write Capacity Units (rWCUs, per le tabelle fornite) o Replicated Write Request Units (r, per le tabelle on-demand). WRUs
I valori r WCUs e r WRUs includono il costo dell'infrastruttura di streaming necessaria per gestire la replica.
I costi delle unità di scrittura replicate vengono applicati in tutte le regioni in cui l'elemento viene scritto direttamente o replicato.
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 rWCUs . L'acquisto di capacità riservata può comunque essere utile per le tabelle che GSIs consumano unità di scrittura.
Il bootstrap iniziale quando si aggiunge una nuova regione a una tabella globale viene addebitato come un ripristino per GB di dati ripristinati, oltre alle tariffe per il trasferimento dei dati tra regioni.
Quali sono regioni supportate dalle tabelle globali?
La versione 2019.11.21 (attuale) di Global Tables è disponibile nella maggior parte delle regioni. È possibile visualizzare l'elenco più recente nell'elenco a discesa delle regioni nella console DynamoDB quando viene aggiunta una replica.
Come vengono GSIs gestite le tabelle globali?
Nella versione 2019.11.21 (attuale) di Global Tables, quando si crea un GSI in una regione, questo viene creato automaticamente nelle altre regioni partecipanti e riempito automaticamente.
Come posso interrompere la replica di una tabella globale?
È 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.
In che modo i flussi DynamoDB interagiscono con le tabelle globali?
Ogni tabella globale produce un flusso indipendente basato su tutte le relative scritture, 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.
In che modo le tabelle globali gestiscono le transazioni?
Le operazioni transazionali forniscono garanzie di atomicità, consistenza, isolamento e durabilità (Atomicity, Consistency, Isolation and Durability, 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 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.
In che modo le tabelle globali interagiscono con la cache DynamoDB Accelerator (DAX)?
Le tabelle globali ignorano DAX aggiornando direttamente DynamoDB, quindi DAX non è consapevole della presenza di dati obsoleti. La cache DAX verrà aggiornata solo alla scadenza del TTL della cache.
I tag presenti nelle tabelle vengono propagati?
No, i tag non vengono propagati automaticamente.
Devo eseguire il backup delle tabelle in tutte le regioni o solo in una?
La risposta dipende dallo scopo del backup. 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.
Come posso distribuire tabelle globali utilizzando? AWS CloudFormation
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 iniziare, è quindi possibile mantenerle come tabelle autonome e aggiungere successivamente le regioni, 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 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. CloudFormation
La replica su più account non è al momento supportata.
