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à. # Utilizzo delle tabelle globali DynamoDB Le tabelle globali sono progettate in base all’impatto globale di Amazon DynamoDB per offrire un database completamente gestito, multi-Regione e multi-attivo in grado di garantire prestazioni di lettura e scrittura rapide e locali per applicazioni globali dimensionate su larga scala. Le tabelle globali replicano automaticamente le tabelle DynamoDB tra quelle di tua scelta. Regioni AWS Non sono necessarie modifiche all'applicazione perché le tabelle globali utilizzano DynamoDB APIs esistente. Non sono previsti costi anticipati o impegni per l'utilizzo delle tabelle globali; vengono infatti addebitati solo i costi per le risorse utilizzate. In questa guida viene illustrato come utilizzare efficacemente le tabelle globali di DynamoDB. Vengono fornite informazioni chiave sulle tabelle globali, spiegati i casi d’uso principali della funzionalità, descritte le due modalità di coerenza, introdotta una tassonomia di tre diversi modelli di scrittura da prendere in considerazione, vengono illustrate le quattro principali scelte di instradamento delle richieste che è possibile implementare, illustrati i modi per evacuare una Regione attiva o una Regione offline, viene spiegato come pensare alla pianificazione della capacità di throughput e viene fornito un elenco di aspetti da considerare per l’implementazione delle tabelle globali. [Questa guida si inserisce in un contesto più ampio di implementazioni in più AWS regioni, come illustrato nel white paper [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) e nei modelli di progettazione della resilienza dei dati con video. AWS](https://www.youtube.com/watch?v=7IA48SOX20c) **Topics** + [Aspetti chiave sulla progettazione di tabelle DynamoDB globali](#bp-global-table-design.prescriptive-guidance.facts) + [Aspetti chiave della MREC](#bp-global-table-design-MREC-facts) + [Aspetti chiave della MRSC](#bp-global-table-design-MRSC-facts) + [Casi d’uso delle tabelle globali MREC DynamoDB](#bp-global-table-design.prescriptive-guidance.usecases) + [Modalità di scrittura con le tabelle globali DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md) + [Strategie di instradamento in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) + [Processi di evacuazione](bp-global-table-design.prescriptive-guidance.evacuation.md) + [Pianificazione della capacità di throughput per le tabelle globali DynamoDB](bp-global-table-design.prescriptive-guidance.throughput.md) + [Elenco di controllo di preparazione per tabelle globali DynamoDB](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md) + [Conclusioni e risorse](#bp-global-table-design.prescriptive-guidance-resources-conclusion) ## Aspetti chiave sulla progettazione di tabelle DynamoDB globali + Esistono due versioni delle tabelle globali: la versione corrente [Tabelle globali versione 2019.11.21 (Corrente)](GlobalTables.md) (a volte detta “V2”) e [Tabelle globali versione 2017.11.29 (Legacy)](globaltables.V1.md) (a volte detta “V1”). Questa guida fa riferimento esclusivamente alla versione corrente. + DynamoDB (senza tabelle globali) è un servizio Regionale, il che significa che è altamente disponibile e intrinsecamente resiliente ai guasti dell’infrastruttura, inclusi i guasti in un’intera zona di disponibilità. Una tabella DynamoDB a Regione singola è progettata per garantire una disponibilità del 99,99%. Per ulteriori informazioni, consulta l’[Accordo sul livello di servizio](https://aws.amazon.com/dynamodb/sla/) (SLA). + Una tabella globale DynamoDB replica i propri dati tra due o più Regioni. Una tabella DynamoDB multi-Regione è progettata per garantire una disponibilità del 99,999%. Con una pianificazione adeguata, le tabelle globali possono contribuire a creare un’architettura resiliente ai guasti a livello Regionale. + DynamoDB non ha un endpoint globale. Tutte le richieste vengono effettuate a un endpoint Regionale, che accede all’istanza della tabella globale locale per tale Regione. + Le chiamate a DynamoDB non devono passare tra Regioni. La best practice prevede che un’applicazione che risiede in una Regione acceda direttamente solo all’endpoint DynamoDB locale per tale Regione. Se vengono rilevati problemi all’interno di una Regione, nel livello DynamoDB o nello stack circostante, il traffico degli utenti finali deve essere instradato a un endpoint dell’applicazione diverso ospitato in una Regione diversa. Le tabelle globali assicurano che l’applicazione ospitata in ogni Regione abbia accesso agli stessi dati. ### Modalità di coerenza Quando viene creata una tabella globale, viene configurata la modalità di coerenza. Le tabelle globali supportano due modalità di coerenza: coerenza finale multi-Regione (MREC, Multi-Region Eventual Consistency) ed elevata consistenza multi-Regione (MRSC, Multi-Region Strong Consistency), introdotta nel giugno 2025. Se non si specifica una modalità di coerenza durante la creazione di una tabella globale, la tabella globale per impostazione predefinita è MREC. Una tabella globale non può contenere repliche configurate con modalità di coerenza diverse. Non è possibile modificare la modalità di coerenza di una tabella globale dopo la sua creazione. ## Aspetti chiave della MREC + Anche le tabelle globali che utilizzano la MRSC impiegano 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à 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 venire replicati congiuntamente. + Ogni partizione di tabella nella Regione di origine replica le proprie operazioni di scrittura in parallelo con ogni altra partizione. La sequenza delle operazioni di scrittura all’interno della Regione remota potrebbe non corrispondere alla sequenza delle operazioni di scrittura 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](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/). + 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ò essere utile a 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 della finestra `ReplicationLatency`) in due Regioni diverse e la seconda operazione di scrittura avviene prima della replica della prima operazione di scrittura, è possibile che si verifichino conflitti di scrittura. Le tabelle globali che utilizzano la MREC risolvono tali conflitti utilizzando un meccanismo basato sulla priorità dell’ultima istanza di scrittura, ovvero sul timestamp delle operazione di scrittura. La prima operazione “perde” rispetto alla seconda operazione. 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 viene implementato utilizzando un’operazione di scrittura condizionale che richiede che il timestamp dell’elemento in arrivo sia maggiore (cronologicamente successivo) del timestamp dell’elemento esistente. + Una tabella globale replica tutti gli elementi in tutte le Regioni partecipanti. Per avere ambiti di replica diversi, è possibile creare più tabelle globali e assegnare a ciascuna di esse diverse Regioni partecipanti. + La Regione locale accetta operazioni di scrittura 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 per tutte le repliche in uscita e in entrata in sospeso verranno effettuate ripetizioni di tentativi. 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 MREC DynamoDB in qualsiasi momento. DynamoDB gestisce la sincronizzazione iniziale e la replica continua. È possibile anche rimuovere una Regione (anche la Regione originale), e questo eliminerà la tabella locale in quella Regione. ## Aspetti chiave della MRSC + Anche le tabelle globali che utilizzano la MRSC impiegano un modello di replica attivo-attivo. Dal punto di vista di DynamoDB, la tabella in ogni regione può accettare richieste di lettura e scrittura. Le modifiche agli elementi in una replica di tabella globale MRSC vengono replicate in **modo sincrono** in almeno un’altra Regione prima che l’operazione di scrittura restituisca una risposta con esito positivo. + Le operazioni a elevata consistenza di lettura su qualsiasi replica MRSC restituiscono sempre la versione più recente di un elemento. Le operazioni di scrittura condizionale valutano sempre l’espressione della condizione rispetto alla versione più recente di un elemento. Gli aggiornamenti funzionano sempre sulla base della versione più recente di un elemento. + Le operazioni di lettura a coerenza finale su una replica MRSC potrebbero non includere le modifiche apportate di recente in un’altra Regione e potrebbero non includere nemmeno le modifiche avvenute di recente nella stessa Regione. + Un’operazione di scrittura ha esito negativo con un’eccezione `ReplicatedWriteConflictException` quando tenta di modificare un elemento che è già stato modificato in un’altra Regione. Per le operazioni di scrittura che hanno esito negativo con l’eccezione `ReplicatedWriteConflictException` è possibile effettuare ripetizioni di tentativi. Queste avranno esito positivo se l’elemento non viene più modificato in un’altra Regione. + Con MRSC, le latenze sono più elevate per le operazioni di scrittura e per le operazioni a elevata consistenza di lettura. Queste operazioni richiedono una comunicazione multi-Regione. Questa comunicazione può aggiungere una latenza che aumenta in base alla latenza del round trip tra la Regione a cui si accede e la Regione più vicina che partecipa alla tabella globale. Per ulteriori informazioni, consulta la presentazione di AWS re:Invent 2024, [Forte coerenza multiregionale con](https://www.youtube.com/watch?v=R-nTs8ZD8mA) le tabelle globali DynamoDB. Le operazioni di lettura a coerenza finale non comportano alcuna latenza aggiuntiva. Esiste uno [strumento di test](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester) open source che consente di calcolare sperimentalmente queste latenze con le proprie Regioni. + Gli elementi vengono replicati singolarmente. Le tabelle globali che utilizzano MRSC non supportano la transazione. APIs + Una tabella globale MRSC deve essere implementata esattamente in tre Regioni. È possibile configurare una tabella globale MRSC con tre repliche o con due repliche e un testimone. Un testimone è un componente di una tabella globale MRSC che contiene dati recenti scritti su repliche di tabelle globali. Un testimone fornisce un’alternativa opzionale a una replica completa, supportando al contempo l’architettura di disponibilità di MRSC. Non è possibile eseguire operazioni di lettura o scrittura su un testimone. Un testimone non sostiene costi di archiviazione o scrittura. Un testimone si trova in una Regione diversa dalle due repliche. + Per creare una tabella globale MRSC, si aggiungono una replica e un testimone oppure si aggiungono due repliche a una tabella DynamoDB esistente che non contiene dati. Non è possibile aggiungere repliche aggiuntive a una tabella globale MRSC esistente. Non è possibile eliminare una singola replica o un testimone da una tabella globale MRSC. È possibile eliminare due repliche o eliminare una replica e un testimone da una tabella globale MRSC. Il secondo scenario converte la replica rimanente in una tabella DynamoDB a Regione singola. + È possibile determinare se una tabella globale MRSC ha un testimone configurato e in quale regione è configurato, dall'output dell' DescribeTable API. Il testimone è di proprietà e gestito da DynamoDB e non appare nella regione in cui è Account AWS configurato. + Le tabelle globali MRSC sono disponibili nei seguenti set di 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) + Le tabelle globali MRSC non possono estendersi su set di Regioni. Ad esempio, una tabella globale MRSC non può contenere repliche di set di Regioni degli Stati Uniti e dell’UE. + Il valore Time to Live (TTL) non è supportato per le tabelle globali MRSC. + Gli indici secondari locali (LSIs) non sono supportati per le tabelle globali MRSC. + CloudWatch Le informazioni di Contributor Insights vengono riportate solo per la regione in cui si è verificata un'operazione. + La Regione locale accetta tutte le operazioni di lettura e scrittura purché esista una seconda Regione che ospita una replica o un testimone per stabilire il quorum. Se una seconda Regione non è disponibile, la Regione locale può fornire solo letture a coerenza finale. + Nel caso improbabile che una Regione vada completamente offline, quando tornerà online si aggiornerà automaticamente. Fino a quando non verranno recuperate, le operazioni di scrittura e le operazioni di lettura fortemente coerenti *solo* nella regione che sta recuperando restituiranno errori, mentre le richieste verso le altre regioni continueranno a funzionare normalmente. Alla fine, operazioni di lettura coerenti nella regione di recupero restituiranno i dati che finora sono stati propagati nella regione, con il consueto comportamento di coerenza locale tra il nodo leader e le repliche locali. Non è richiesta alcuna azione speciale per ripristinare la sincronizzazione delle tabelle. ## Casi d’uso delle tabelle globali MREC DynamoDB Le tabelle globali MREC sono caratterizzate dai seguenti vantaggi comuni: + **Operazioni di lettura a bassa latenza.** Posiziona una copia dei dati più vicino all’utente finale per ridurre la latenza di rete durante le operazioni di lettura. L’aggiornamento dei dati è in linea con l’aggiornamento del valore `ReplicationLatency`. + **Operazioni di scrittura a bassa latenza.** È 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 [Strategie di instradamento in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md). + **Migrazione regionale senza interruzioni.** È possibile aggiungere una nuova Regione ed eliminare quella vecchia per eseguire la migrazione di un’implementazione da una Regione all’altra senza tempi di inattività a livello di dati. Le tabelle globali MREC e MRSC offrono entrambe questo vantaggio: + **Resilienza e ripristino di emergenza migliorati.** Se una Regione presenta prestazioni ridotte o un’interruzione totale, è possibile evacuarla. Evacuare significa spostare alcune o tutte le richieste destinate a quella Regione. L’utilizzo delle tabelle globali aumenta la disponibilità dello [SLA di DynamoDB](https://aws.amazon.com/dynamodb/sla/) per il tempo di attività mensile dal 99,99% al 99,999%. L’utilizzo della MREC supporta un Obiettivo del punto di ripristino (RPO) e un Obiettivo del tempo di ripristino (RTO) misurati in secondi. L’utilizzo della MRSC supporta un RPO pari a zero. Ad esempio, Fidelity Investments ha presentato a re:Invent 2022 la modalità di utilizzo delle tabelle globali DynamoDB per il proprio sistema di gestione degli ordini. L’obiettivo era ottenere un’elaborazione affidabile a bassa latenza su una scala che non sarebbe possibile raggiungere con l’elaborazione on-premises, mantenendo al contempo la resilienza ai guasti nelle zone di disponibilità e nelle aree di disponibilità. Se l’obiettivo è la resilienza e il disaster recovery, le tabelle MRSC hanno latenze di scrittura superiori e latenze per le operazioni a elevata consistenza di lettura più elevate, ma supportano un RPO pari a zero. Le tabelle globali MREC supportano un RPO pari al ritardo di replica tra le repliche, in genere di pochi secondi a seconda delle Regioni di replica. # Modalità di scrittura con le tabelle globali DynamoDB Le tabelle globali utilizzano sempre un modello di replica attivo-attivo a livello di tabella. Tuttavia, in particolare per le tabelle MREC, è possibile considerarle basate su un modello attivo-passivo mediante il controllo della modalità di instradamento delle richieste di scrittura. Ad esempio, è possibile decidere di instradare le richieste di scrittura a un’unica Regione per evitare potenziali conflitti di scrittura che possono verificarsi con le tabelle MREC. Esistono tre modelli principali di scrittura gestita, come spiegato nelle tre sezioni successive. È consigliabile valutare il modello di scrittura più adatto a uno specifico caso d'uso. Questa scelta influisce sulle modalità di instradamento delle richieste, evacuazione di una regione e gestione del ripristino di emergenza. Le indicazioni nelle sezioni successive dipendono dalla modalità di scrittura dell’applicazione. ## Modalità di scrittura in qualsiasi regione (non primaria) La modalità di *scrittura in qualsiasi Regione*, illustrata nel diagramma seguente, si basa su un modello di replica attivo-attivo e non impone restrizioni su dove può avvenire la scrittura. Qualsiasi regione può accettare un'operazione di scrittura in qualsiasi momento. Questa è la modalità più semplice, ma può essere utilizzata solo con alcuni tipi di applicazioni. Questa modalità è adatta a tutte le tabelle MRSC. È adatta anche per le tabelle MREC quando tutte le istanze di scrittura sono idempotenti e quindi ripetibili in modo sicuro in modo che le operazioni di scrittura simultanee o ripetute tra Regioni non siano in conflitto. Ad esempio, quando un utente aggiorna i propri dati di contatto. Questa modalità è adatta anche per un caso speciale di idempotenza, ovvero un set di dati di tipo "solo accodamento", in cui tutte le scritture sono inserimenti univoci sotto una chiave primaria deterministica. Infine, questa modalità è adatta per la MREC nei casi in cui il rischio di scritture in conflitto sia accettabile. ![\[Diagramma delle modalità di scrittura da parte del client in qualsiasi regione.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png) La modalità *scrittura in qualsiasi regione* rappresenta l'architettura più semplice da implementare. L'instradamento è più semplice perché qualsiasi regione può essere la destinazione delle operazioni di scrittura in qualsiasi momento. Il failover è più semplice, perché con le tabelle MRSC gli elementi sono sempre sincronizzati e con le tabelle MRSC, qualsiasi scrittura recente può essere riprodotta un numero qualsiasi di volte in qualsiasi Regione secondaria. Laddove possibile, è consigliabile usare questa modalità di scrittura nella fase di progettazione. Ad esempio, vari servizi di streaming video utilizzano tabelle globali per tenere traccia di segnalibri, recensioni, flag relativi allo stato di visualizzazione e così via. Queste implementazioni utilizzano tabelle MREC perché necessitano di repliche di tipo sparse in tutto il mondo, con ogni replica che fornisce operazioni di lettura e scrittura a bassa latenza. Queste implementazioni possono utilizzare la modalità di *scrittura in qualsiasi Regione* purché assicurino che ogni operazione di scrittura sia idempotente. Questo si verifica se ogni aggiornamento, ad esempio l’impostazione di un nuovo timecode più aggiornato, l’assegnazione di una nuova recensione o l’impostazione di un nuovo stato di visualizzazione, assegna direttamente il nuovo stato dell’utente e il successivo valore corretto per un elemento non dipende dal valore corrente. Se, per caso, le richieste di scrittura dell’utente vengono instradate a Regioni diverse, l’ultima operazione di scrittura risulterà persistente e lo stato globale verrà adeguato in base all’ultima assegnazione. Le operazioni di lettura in questa modalità risulteranno a coerenza finale, con un ritardo in base al valore `ReplicationLatency` più recente. In un altro esempio, una società di servizi finanziari utilizza tabelle globali come parte di un sistema per il conteggio continuo degli acquisti con carta di debito per ogni cliente, per calcolare il valore del cashback per il cliente specifico. L’intenzione è conservare un elemento `RunningBalance` per cliente. Questa modalità di scrittura non è per natura idempotente perché, man mano che le transazioni arrivano, modificano il saldo attraverso un’espressione `ADD` in cui il nuovo valore corretto dipende dal valore corrente. Utilizzando le tabelle MRSC è comunque possibile *scrivere in qualsiasi Regione*, poiché ogni chiamata `ADD` opera sempre in base al valore più recente dell’elemento. Un terzo esempio riguarda un’azienda che fornisce servizi di inserimento di annunci online. Questa azienda ha deciso che è accettabile un basso rischio di perdita di dati per ottenere le semplificazioni di progettazione derivanti dalla modalità di *scrittura in qualsiasi Regione*. Alla pubblicazione degli annunci, sono disponibili solo pochi millisecondi per recuperare metadati sufficienti per determinare l’annuncio da mostrare e quindi registrare l’impression di tale annuncio in modo da non ripeterlo nel giro di poco tempo. L’azienda impiega le tabelle globali per ottenere sia operazioni di lettura a bassa latenza per gli utenti finali di tutto il mondo che operazioni di scrittura a bassa latenza. L’azienda registra tutte le impression degli annunci di un utente all’interno di un singolo elemento, che è rappresentato come un elenco crescente. Utilizza un solo elemento anziché aggiungerlo a una raccolta di elementi, così che le impression meno recenti possano essere rimosse come parte di ogni operazione di scrittura senza dover pagare tale operazione. Questa operazione di scrittura NON è idempotente; se lo stesso utente finale vede annunci pubblicati in più Regioni all’incirca nello stesso momento, è possibile che l’operazione di scrittura di un’impression possa sovrascrivere l’altra. Il rischio è che un utente veda un annuncio ripetuto di tanto in tanto, ma l’azienda ha deciso che l’opzione è accettabile. ## Scrittura in una Regione (unica primaria) La modalità di *scrittura in una Regione*, illustrata nel diagramma seguente, si basa su un modello di replica attivo-passivo e instrada tutte le scritture a livello di tabelle in un’unica Regione attiva. Si noti che DynamoDB non ha "percezione" del concetto di regione attiva; l'instradamento delle applicazioni esternamente a DynamoDB gestisce questo scenario. La modalità di *scrittura in una Regione* è molto utile per tabelle MREC che devono evitare i conflitti di scrittura assicurando che le operazioni di scrittura vengano instradate verso solo una Regione alla volta. Questa modalità di scrittura è utile quando si desidera utilizzare espressioni condizionali e non è possibile utilizzare la MRSC per qualche motivo, o quando è necessario eseguire transazioni. Queste espressioni non sono possibili a meno di non essere consapevoli di stare agendo sulla base dei dati più recenti, quindi richiedono l’invio di tutte le richieste di scrittura a un’unica Regione con i dati più recenti. Quando si utilizza una tabella MRSC, è possibile scegliere di scrivere in genere in un’unica Regione per comodità. Ad esempio, questo può aiutare a ridurre al minimo lo sviluppo dell’infrastruttura oltre a DynamoDB. La modalità di scrittura sarebbe comunque quella di scrivere su qualsiasi Regione, perché con la MRSC è possibile scrivere in tutta sicurezza in qualsiasi Regione in qualsiasi momento senza preoccuparsi della risoluzione dei conflitti che farebbe sì che le tabelle MREC decidano di *scrivere in una Regione*. Le letture a consistenza finale possono essere eseguite in qualsiasi regione di replica per ottenere latenze più basse. Le operazioni a elevata consistenza di lettura devono essere instradate all’unica Regione primaria. ![\[Diagramma del funzionamento della modalità di scrittura in una regione.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png) A volte è necessario modificare la Regione attiva in risposta a un guasto a livello Regionale. Alcuni utenti modificano la regione attualmente attiva secondo una pianificazione regolare, ad esempio implementando una distribuzione. follow-the-sun In questo modo la Regione attiva si colloca vicino all’area geografica con la maggiore attività (di solito dove è giorno, da qui il nome), il che si traduce nelle operazioni di lettura e scrittura con la latenza più bassa. L’approccio ha anche il vantaggio di chiamare quotidianamente il codice di modifica della Regione, assicurandosi che sia ben testato prima di eventuali disaster recovery. Le Regioni passive possono mantenere un set sottodimensionato dell’infrastruttura DynamoDB, che potrà essere potenziato solo quando la Regione dovesse diventare attiva. Questa guida non copre i modelli pilot light e warm standby. Per ulteriori informazioni, vedere [Disaster Recovery (DR) Architecture on AWS, Parte III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). L’utilizzo della modalità di *scrittura in una Regione* funziona bene quando si utilizzano tabelle globali per operazioni di lettura distribuite a livello globale a bassa latenza. Un esempio è rappresentato da una grande società di social media che deve disporre degli stessi dati di riferimento in tutte le Regioni del mondo. Non aggiorna spesso i dati, ma quando lo fa, scrive in una sola Regione per evitare potenziali conflitti di scrittura. Le operazioni di lettura sono sempre consentite da qualsiasi Regione. Come altro esempio, si consideri l’azienda di servizi finanziari discussa in precedenza che ha implementato un calcolo del cashback giornaliero. Usa la modalità di *scrittura in qualsiasi Regione* per calcolare il saldo, ma *scrive in una Regione* per tenere traccia dei pagamenti. Questo lavoro richiede transazioni che non sono supportate nelle tabelle MRSC, pertanto funziona meglio con una tabella MREC separata e la modalità di *scrittura in una Regione*. ## Scrittura nella propria Regione (primaria mista) La modalità *di scrittura nella propria Regione*, illustrata nel diagramma seguente, funziona con le tabelle MREC. Assegna diversi sottoinsiemi di dati a diverse Regioni di origine e consente operazioni di scrittura su un elemento solo tramite la relativa Regione di origine. Questa modalità è attiva-passiva ma assegna la Regione attiva in base all’elemento. Ogni Regione è primaria per il proprio set di dati non sovrapposto e le operazioni di scrittura devono essere protette per garantire la corretta localizzazione. Questa modalità è simile alla modalità di *scrittura in una Regione*, tranne per il fatto che consente operazioni di scrittura a latenza inferiore, poiché i dati associati a ciascun utente possono essere collocati in prossimità della rete più vicina a quell’utente. Inoltre, distribuisce l’infrastruttura circostante in modo più uniforme tra le Regioni e richiede meno lavoro per ricostruire l’infrastruttura durante uno scenario di failover, poiché tutte le Regioni hanno una parte della propria infrastruttura già attiva. ![\[Diagramma del funzionamento delle scritture client in ogni elemento in una singola regione.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png) È possibile determinare la Regione di origine degli elementi in diversi modi: + **Modalità intrinseca:** alcuni aspetti dei dati, ad esempio un attributo speciale o un valore incorporato nella relativa chiave di partizione, rendono chiara la Regione di origine. Questa tecnica è descritta nel post del blog relativo all’[uso del pinning della Regione per impostare una Regione di origine per gli elementi in una tabella globale di Amazon DynamoDB](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/). + **Modalità negoziata:** l’area di origine di ogni set di dati viene negoziata esternamente, ad esempio con un servizio globale distinto che gestisce le assegnazioni. L'assegnazione può avere una durata limitata, trascorsa la quale è soggetta a rinegoziazione. + **Modalità orientata alla tabella:** anziché creare una singola tabella globale di replica, si crea lo stesso numero di tabelle globali quante sono le Regioni di replica. Il nome di ogni tabella fa riferimento alla regione di origine. Nelle operazioni standard, tutti i dati vengono scritti nella regione di origine, mentre le altre regioni ne conservano una copia di sola lettura. Durante un failover, un’altra Regione adotta temporaneamente le funzioni di scrittura per tale tabella. Ad esempio, si supponga di lavorare per una società di videogiochi. Deve essere disponibile una bassa latenza per le operazioni di lettura e scrittura per tutti i giocatori di tutto il mondo. A ciascun giocatore viene assegnata la Regione più vicina. Quella regione esegue tutte le operazioni di lettura e scrittura, garantendo una forte read-after-write coerenza. Tuttavia, quando il giocatore viaggia o la sua Regione di origine subisce un’interruzione dei servizi, una copia completa dei suoi dati sarà disponibile in altre Regioni e per il giocatore si verificherà l’assegnazione di una Regione diversa. Per fare un altro esempio, si supponga di lavorare in un’azienda di servizi di videoconferenza. I metadati di ogni chiamata di conferenza vengono assegnati a una Regione specifica. I partecipanti (chiamanti) possono utilizzare la Regione più vicina a loro in modo da avere la latenza più bassa. In caso di interruzione dei servizi in tale Regione, l’utilizzo delle tabelle globali consente un ripristino rapido poiché il sistema può spostare l’elaborazione della chiamata in un’altra Regione in cui è già presente una copia replicata dei dati. **Riepilogo** + La modalità di scrittura in qualsiasi Regione è adatta per le tabelle MRSC e le chiamate idempotenti alle tabelle MREC. + La modalità di scrittura in una Regione è adatta per le chiamate non idempotenti alle tabelle MREC. + La modalità di scrittura nella propria Regione è adatta per chiamate non idempotenti alle tabelle MREC, in cui è importante che i client scrivano in una Regione vicina a loro. # Strategie di instradamento in DynamoDB Forse la parte più complessa di una implementazione di tabelle globali è la gestione dell'instradamento delle richieste. Le richieste devono prima essere inviate da un utente finale a una regione scelta e destinataria dell'instradamento. La richiesta incontra alcuni stack di servizi in quella regione, tra cui un livello di calcolo che forse consiste in un sistema di bilanciamento del carico supportato da una AWS Lambda funzione, un contenitore o un nodo Amazon Elastic Compute Cloud (Amazon EC2) e possibilmente altri servizi tra cui un altro database. Questo livello di calcolo comunica con DynamoDB mediante l'endpoint locale per tale regione. I dati nella tabella globale vengono replicati in tutte le altre regioni partecipanti e ogni regione ha uno stack di servizi simile attorno alla propria tabella DynamoDB. A ogni stack nelle varie regioni la tabella globale fornisce una copia locale degli stessi dati. È possibile considerare l'ipotesi di progettare un unico stack in un'unica regione e prevedere di effettuare chiamate remote all'endpoint DynamoDB di una regione secondaria in caso di problemi con la tabella DynamoDB locale. Questa non è una best practice. Se c’è un problema in una Regione causato da DynamoDB (o, più probabilmente, causato da qualcos’altro nello stack o da un altro servizio che dipende da DynamoDB), è meglio indirizzare l’utente finale verso un’altra Regione per l’elaborazione e utilizzare il livello di calcolo dell’altra Regione, che comunicherà con l’endpoint DynamoDB locale. Questo approccio riguarda interamente la Regione problematica. Per garantire la resilienza, è necessario eseguire la replica su più Regioni, con la replica dei livelli di calcolo e dati. Esistono numerose tecniche alternative per instradare una richiesta dell'utente finale a una regione per l'elaborazione. La scelta ottimale dipende dalla modalità di scrittura e dalle considerazioni relative al failover. Questa sezione illustra quattro opzioni di instradamento: basato sul client, livello di calcolo, Route 53 e Global Accelerator. ## Instradamento delle richieste basato sul client Con il routing delle richieste basato sul client, illustrato nel diagramma seguente, il client dell'utente finale (un'applicazione, una pagina Web con o un altro client) tiene traccia degli endpoint applicativi validi (ad esempio JavaScript, un endpoint Amazon API Gateway anziché un endpoint DynamoDB letterale) e utilizza la propria logica incorporata per scegliere la regione con cui comunicare. Potrebbe scegliere in base alla selezione casuale, alle latenze più basse rilevate, alle misurazioni della larghezza di banda più elevata rilevate o ai controlli di integrità eseguiti localmente. ![\[Diagramma di come funziona la scrittura in una destinazione designata di un client.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png) Il vantaggio dell’instradamento delle richieste basato sul client è che può adattarsi relativamente a fattori come le condizioni reali del traffico Internet pubblico e che pertanto può cambiare Regione in caso di peggioramento delle prestazioni. Il client deve conoscere tutti i potenziali endpoint, ma il lancio di un nuovo endpoint regionale non è un evento frequente. Con la modalità di *scrittura in qualsiasi Regione*, un client può selezionare unilateralmente il suo endpoint preferito. Se il suo accesso a una regione viene compromesso, il client può reindirizzare le richieste a un altro endpoint. Con la modalità *scrittura in una regione*, il client avrà bisogno di un meccanismo per instradare le sue operazioni di scrittura alla regione attualmente attiva. Questa operazione potrebbe essere semplice, come verificare empiricamente quale Regione accetta le scritture rilevando eventuali errori di scrittura e ricorrendo eventualmente a un’alternativa, oppure complessa, come chiamare un coordinatore globale per richiedere lo stato corrente dell’applicazione (basato sul controllo di instradamento del Sistema di controllo Amazon per il ripristino delle applicazioni (ARC) che fornisce un sistema basato su quorum a 5 Regioni per mantenere lo stato globale per esigenze di questo tipo). Il client può decidere se le letture possono essere instradate a una regione qualsiasi per ottenere un'eventuale coerenza o se devono essere indirizzate alla regione attiva per una maggiore coerenza. Per ulteriori informazioni, consulta l'argomento relativo al [funzionamento di Route 53](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html). Con la modalità di *scrittura nella propria regione*, il client deve determinare la regione di origine del set di dati che sta usando. Ad esempio, se il client corrisponde a un account utente e ogni account utente si trova in una regione specifica, il client può richiedere l'endpoint appropriato da un sistema di accesso globale. Ad esempio, una società di servizi finanziari che aiuta gli utenti a gestire le proprie finanze aziendali tramite il Web potrebbe utilizzare tabelle globali con la modalità di *scrittura nella propria regione*. Ogni utente deve accedere a un servizio centrale. Tale servizio restituisce le credenziali e l'endpoint per la regione in cui tali credenziali funzioneranno. Le credenziali sono valide per un breve periodo. Successivamente, la pagina web negozia automaticamente un nuovo accesso, che offre l'opportunità di reindirizzare potenzialmente l'attività dell'utente verso una nuova regione. ## Instradamento delle richieste al livello di calcolo Con l’instradamento delle richieste al livello di calcolo, illustrato nel seguente diagramma, il codice in esecuzione nel livello di calcolo stabilisce se elaborare la richiesta localmente o passarla a una copia di se stesso in esecuzione in un’altra Regione. Quando si utilizza la modalità di *scrittura in una Regione*, il livello di calcolo può rilevare che la Regione non è la Regione attiva e consentire operazioni di lettura locali mentre inoltra tutte le operazioni di scrittura a un’altra Regione. Questo codice al livello di calcolo deve conoscere la topologia dei dati e le regole di instradamento e applicarle in modo affidabile in base alle impostazioni più recenti che specificano le Regioni attive e i dati da utilizzare. Lo stack software esterno all’interno della Regione non deve conoscere il modo in cui il microservizio instrada le richieste di lettura e scrittura. In una progettazione affidabile, la regione ricevente verifica se è la regione primaria corrente per l'operazione di scrittura. In caso contrario, genera un errore che indica che lo stato globale deve essere corretto. La regione ricevente potrebbe anche memorizzare l'operazione di scrittura nel buffer per un breve intervallo, se la regione primaria è in fase di modifica. In ogni caso, lo stack di calcolo in una regione effettua la scrittura solo sul proprio endpoint DynamoDB locale, ma gli stack di calcolo potrebbero comunicare tra loro. ![\[Diagramma dell'instradamento delle richieste al livello di calcolo.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png) Il Vanguard Group utilizza un sistema chiamato Global Orchestration and Status Tool (GOaST) e una libreria chiamata Global Multi-Region library (GMRlib) per questo processo di routing, presentato a [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s). follow-the-sunUsano un unico modello primario. GOaST mantiene lo stato globale, in modo simile al controllo di routing ARC discusso nella sezione precedente. Viene utilizzata una tabella globale per monitorare la Regione primaria e controllare quando è programmato il passaggio alla Regione primaria successiva. Tutte le operazioni di lettura e scrittura vengono eseguite GMRlib, il che si coordina con GOa ST. GMRlib consente di eseguire le operazioni di lettura localmente, a bassa latenza. Per le operazioni di scrittura, GMRlib verifica se la regione locale è la regione principale corrente. In caso affermativo, l’operazione di scrittura viene completata direttamente. In caso contrario, GMRlib inoltra l'attività di scrittura GMRlib alla regione principale. La libreria ricevente conferma di essere la regione primaria e genera un errore in caso contrario, il che genera un ritardo di propagazione con lo stato globale. Questo approccio offre un vantaggio in termini di convalida in quanto non viene effettuata una scrittura diretta su un endpoint DynamoDB remoto. ## Instradamento delle richieste Route 53 Il sistema ARC è una tecnologia DNS (Domain Name Service). Con Route 53, il client richiede il proprio endpoint mediante la ricerca di un nome di dominio DNS noto; Route 53 restituisce l'indirizzo IP corrispondente agli endpoint regionali ritenuti più appropriati. Il diagramma seguente ne è l'illustrazione. Route 53 dispone di un lungo elenco di policy di instradamento che utilizza per determinare la Regione appropriata. Può anche eseguire il routing di failover per deviare il traffico dalle Regioni in cui non vengono superati i controlli dell’integrità. ![\[Diagramma dell'instradamento delle richieste al livello di calcolo.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png) Con la modalità di *scrittura in qualsiasi regione* o combinato con l'instradamento delle richieste al livello di calcolo sul backend, Route 53 può avere l'accesso completo per restituire la regione in base a regole interne complesse come la regione più vicina alla rete o la prossimità geografica più vicina o qualsiasi altra scelta. Con la modalità di *scrittura in una Regione*, Route 53 può essere configurato in modo da restituire la Regione attualmente attiva (utilizzando il sistema ARC Route 53). Se il client desidera connettersi a una Regione passiva (ad esempio, per operazioni di lettura), potrebbe cercare un nome DNS diverso. **Nota** I client memorizzano nella cache gli indirizzi IP nella risposta di Route 53 per il periodo di tempo specificato nell'impostazione dell'opzione Time to Live (TTL) sul nome di dominio. Un TTL più lungo estende l'obiettivo del tempo di ripristino (RTO) affinché tutti i client riconoscano il nuovo endpoint. Un valore di 60 secondi è tipico per l'utilizzo del failover. Non tutti i software rispettano perfettamente la scadenza del TTL del DNS e potrebbero esserci più livelli di caching DNS, ad esempio a livello di sistema operativo, macchina virtuale e applicazione. Con la modalità di *scrittura nella propria regione*, è consigliabile evitare l'uso di Route 53 a meno che non si utilizzi anche l'instradamento delle richieste al livello di calcolo. ## Instradamento delle richieste Global Accelerator Con [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/), illustrato nel diagramma seguente, un client cerca il nome di dominio noto in Route 53. Tuttavia, invece di recuperare un indirizzo IP corrispondente a un endpoint regionale, il client riceve un indirizzo IP statico anycast che indirizza verso la edge location più vicina AWS . A partire da tale posizione edge, tutto il traffico viene instradato sulla rete privata  AWS  e verso alcuni endpoint (come un sistema di bilanciamento del carico o un Gateway API) in una regione scelta in base alle regole di instradamento gestite in Global Accelerator. Rispetto all'instradamento basato sulle regole Route 53, l'instradamento delle richieste Global Accelerator presenta latenze inferiori perché riduce la quantità di traffico sulla rete Internet pubblica. Inoltre, poiché Global Accelerator non dipende dalla scadenza del TTL del DNS per modificare le regole di instradamento, può modificare l’instradamento più rapidamente. ![\[Diagramma di come funziona la scrittura client con Global Accelerator.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png) Con la modalità di *scrittura in qualsiasi regione* o combinato con l'instradamento delle richieste al livello di calcolo sul backend, Global Accelerator funziona senza problemi. Il client si connette alla posizione edge più vicina e non deve preoccuparsi di quale regione riceve la richiesta. Con la modalità di *scrittura in una regione*, le regole di instradamento di Global Accelerator devono inviare le richieste alla regione attualmente attiva. È possibile utilizzare i controlli dell'integrità per segnalare artificialmente un guasto in qualsiasi regione non considerata dal sistema globale come regione attiva. Come con il DNS, è possibile utilizzare un nome di dominio DNS alternativo per instradare le richieste di lettura se le richieste possono provenire da qualsiasi regione. Con la modalità di *scrittura nella propria regione*, è consigliabile evitare l'uso di Global Accelerator a meno che non si utilizzi anche l'instradamento delle richieste al livello di calcolo. # Processi di evacuazione L’evacuazione di una Regione è il processo di migrazione delle attività, solitamente delle attività di lettura e scrittura, o delle attività di lettura, dalla Regione. ## Evacuazione di una regione in tempo reale Potresti decidere di evacuare una regione attiva per diversi motivi: come parte della normale attività aziendale (ad esempio, se utilizzi una modalità di scrittura in una regione) follow-the-sun, a causa della decisione aziendale di modificare la regione attualmente attiva, in risposta a guasti nello stack software esterno a DynamoDB o perché stai riscontrando problemi generali come latenze più elevate del solito all'interno della regione. Con la modalità di *scrittura in qualsiasi regione*, l'evacuazione di una regione in tempo reale è semplice. È possibile instradare il traffico verso le Regioni alternative tramite qualsiasi sistema di instradamento e lasciare che le operazioni di scrittura della Regione evacuata si replichino come al solito. Le modalità di scrittura in una Regione e quella di scrittura nella propria Regione vengono generalmente utilizzate con le tabelle MREC. Pertanto, è necessario assicurarsi che tutte le operazioni di scrittura nella nuova Regione attiva siano state completamente registrate, elaborate in streaming e propagate globalmente prima di iniziare le operazioni di scrittura nella nuova Regione attiva, per garantire che le future operazioni di scrittura vengano elaborate sulla versione più recente dei dati. Si supponga che la regione A sia attiva e la regione B sia passiva (per la tabella completa o per gli elementi che si trovano nella regione A). Il meccanismo tipico per eseguire un'evacuazione consiste nel sospendere le operazioni di scrittura nella Regione A, attendere il tempo necessario affinché tali operazioni si siano propagate completamente nella Regione B, aggiornare lo stack dell'architettura per riconoscere la Regione B come attiva e quindi riprendere le operazioni di scrittura nella Regione B. Non esiste una metrica che indichi con assoluta certezza che la Regione A ha replicato completamente i propri dati nella Regione B. Se la Regione A è integra, la sospensione delle operazioni di scrittura nella regione A e l'attesa di 10 volte il valore massimo recente della metrica `ReplicationLatency` sarebbero in genere sufficienti per determinare che la replica è completa. Se la Regione A non è integra e mostra altre aree con latenze aumentate, per definire il tempo di attesa scegliere un valore multiplo più grande. ## Evacuazione di una regione offline Esiste un caso speciale da considerare: cosa succede se la Regione A risulta inaspettatamente offline? Ciò è estremamente improbabile, ma va comunque considerato. Evacuazione di una tabella MRSC offline Se ciò accade con una tabella MRSC, non è necessario fare nulla di particolare. Le tabelle MRSC supportano un obiettivo del punto di ripristino (RPO) pari a zero. Tutte le operazioni di scrittura eseguite correttamente sulla tabella MRSC nella Regione offline saranno disponibili in tutte le altre tabelle delle Regioni, quindi non vi è alcuna potenziale lacuna nei dati anche se la Regione passa completamente offline senza preavviso. Le aziende possono continuare a utilizzare le repliche situate nelle altre Regioni. Evacuazione di una tabella MREC offline In questo caso, tutte le operazioni di scrittura nella Regione A non ancora propagate vengono conservate e propagate dopo che la Regione A torna online. Le operazioni di scrittura non vengono perse, ma la loro propagazione viene ritardata a tempo indeterminato. Come procedere in questo caso dipende dall'applicazione. Per la continuità aziendale, potrebbe essere necessario procedere alle operazioni di scrittura nella nuova Regione B. Tuttavia, se un elemento nella Regione B riceve un aggiornamento mentre è in corso la propagazione di un'operazione di scrittura per tale elemento dalla Regione A, la propagazione viene soppressa in base al modello basato sulla *priorità dell'ultima istanza di scrittura*. Qualsiasi aggiornamento nella Regione B potrebbe eliminare una richiesta di scrittura in arrivo. Con la modalità di *scrittura in qualsiasi Regione*, le operazioni di lettura e scrittura possono continuare nella Regione B, con la certezza che gli elementi nella Regione A alla fine si propagheranno alla Regione B e con la possibilità di elementi mancanti fino a quando la Regione A non tornerà online. Quando possibile, come con le operazioni di scrittura idempotenti, è consigliabile valutare la possibilità di rieseguire il traffico di scrittura recente (ad esempio, utilizzando una fonte a monte di eventi) per colmare la lacuna di eventuali operazioni di scrittura potenzialmente mancanti e lasciare che la risoluzione dei conflitti relativi alla priorità dell’ultima istanza di scrittura annulli la propagazione finale dell’operazione di scrittura in entrata. Con le altre modalità di scrittura, è necessario considerare il grado in cui il lavoro può continuare con una out-of-date visione leggermente del mondo. Alcune operazioni di scrittura di breve durata, tracciate da `ReplicationLatency`, risulteranno mancanti fino a quando la Regione A non tornerà online. L'attività aziendale può andare avanti? In alcuni casi d'uso ciò è possibile, ma in altri casi potrebbe non essere possibile senza meccanismi di mitigazione aggiuntivi. Ad esempio, si supponga di dover mantenere disponibile il saldo del credito senza interruzioni anche dopo un’interruzione totale nella Regione. È possibile dividere il saldo in due elementi diversi, uno situato nella Regione A e uno nella Regione B, ciascuno riferito a metà del saldo disponibile. In questo caso si utilizzerebbe la modalità di *scrittura nella propria regione*. Gli aggiornamenti transazionali elaborati in ciascuna regione verrebbero contabilizzati sulla copia locale del saldo. Se la Regione A passa alla modalità offline, l'elaborazione delle transazioni nella Regione B potrebbe continuare e le operazioni di scrittura sarebbero limitate alla parte del saldo conservata nella Regione B. Suddividere il saldo in questo modo comporta difficoltà quando il saldo si esaurisce o il credito deve essere ribilanciato, ma fornisce un esempio di ripristino aziendale sicuro anche con operazioni di scrittura in sospeso incerte. Per fare un altro esempio, si supponga di acquisire i dati dei moduli web. È possibile utilizzare la funzionalità di [controllo della simultaneità ottimistica](DynamoDBMapper.OptimisticLocking.md) (OCC, Optimistic Concurrency Control) per assegnare versioni agli elementi di dati e incorporare la versione più recente nel modulo web come campo nascosto. Ad ogni invio, l'operazione di scrittura ha esito positivo solo se la versione nel database corrisponde alla versione con cui è stato creato il modulo. Se le versioni non corrispondono, il modulo web può essere aggiornato (o unito) in base alla versione corrente nel database e l'utente può procedere. Il modello OCC di solito protegge dalla sovrascrittura e dalla produzione di una nuova versione dei dati da parte di un altro client, ma può anche essere utile durante il failover, situazione in cui un client potrebbe riscontrare versioni precedenti dei dati. Si supponga di utilizzare il timestamp come versione. Si immagini inoltre che il modulo sia stato creato per la prima volta nella Regione A alle 12:00 ma (dopo il failover) tenti di eseguire un’operazione di scrittura nella Regione B e si accorga che l’ultima versione nel database risale alle 11:59. In questo scenario, il client può attendere che la versione delle 12:00 si propaghi nella Regione B e quindi sovrascrivere su quella versione oppure eseguire una compilazione alle 11:59 e creare una nuova versione alle 12:01 (che, dopo la scrittura, eliminerebbe la versione in arrivo dopo il ripristino della Regione A). Come terzo esempio, una società di servizi finanziari conserva i dati sugli account dei clienti e sulle relative transazioni finanziarie in un database DynamoDB. In caso di interruzione completa dei servizi nella Regione A, la società vuole essere sicura che qualsiasi attività di scrittura relativa ai propri account sia disponibile nella Regione B oppure che i propri account vengano messi in quarantena come account parzialmente noti fino a quando la Regione A non torna online. Invece di sospendere tutte le attività, la società decide di sospendere l'attività solo per la piccola parte di account con transazioni ritenute non propagate. A tal fine, la società utilizza una terza regione, definita Regione C. Prima di elaborare qualsiasi operazione di scrittura nella Regione A, nella Regione C la società inserisce un breve riepilogo delle operazioni in sospeso (ad esempio, un nuovo numero di transazioni per un conto). Questo riepilogo è sufficiente per consentire alla Regione B di determinare se la visualizzazione è completamente aggiornata. Questa azione effettivamente blocca l'account dal momento della scrittura nella Regione C fino a quando la Regione A accetta le operazioni di scrittura e la Regione B le riceve. I dati nella Regione C non vengono utilizzati se non come parte di un processo di failover, dopodiché la Regione B controlla i dati con quelli della Regione C per verificare se alcuni dei suoi account non sono aggiornati. Tali account vengono contrassegnati come messi in quarantena fino a quando il ripristino della Regione A non propaga i dati parziali alla Regione C, potrebbe invece essere utilizzata una nuova Regione D. I dati nella regione C erano molto transitori e dopo pochi minuti la regione D avrebbe avuto una up-to-date registrazione sufficiente delle operazioni di scrittura in volo per essere pienamente utili. Se si verifica un guasto nella Regione B, la Regione A potrebbe continuare ad accettare richieste di scrittura in collaborazione con la Regione C. La società è disposta ad accettare scritture a latenza più elevata (verso due regioni, ovvero C e poi A) ed è fortunata a disporre di un modello di dati in cui lo stato di un account può essere riassunto in modo sintetico. # Pianificazione della capacità di throughput per le tabelle globali DynamoDB In relazione alla capacità, la migrazione del traffico da una regione all'altra richiede un'attenta valutazione delle impostazioni delle tabelle DynamoDB. Alcune considerazioni sulla gestione della capacità di scrittura: + Una tabella globale deve essere in modalità on demand o per essa deve essere effettuato il provisioning con il dimensionamento automatico abilitato. + Se viene effettuato il provisioning del dimensionamento automatico, le impostazioni di scrittura (utilizzo minimo, massimo e obiettivo) vengono replicate tra le regioni. Anche se le impostazioni del dimensionamento automatico sono sincronizzate, la capacità di scrittura effettiva allocata potrebbe variare in modo indipendente tra le Regioni. + Uno dei motivi per cui potrebbe essere possibile riscontrare una diversa capacità di scrittura allocata è dovuto alla funzionalità TTL. Quando si abilita il TTL in DynamoDB, è possibile specificare un nome di attributo il cui valore indica l'ora di scadenza dell'elemento, espresso in secondi, nel formato epoch Unix. Alla fine di tale periodo, DynamoDB può eliminare l'elemento senza incorrere in costi di scrittura. Con le tabelle globali è possibile configurare il TTL in una regione. Tale impostazione viene replicata automaticamente nelle altre regioni associate alla tabella globale. Quando un elemento è idoneo per l'eliminazione tramite una regola TTL, questa operazione può essere eseguita in qualsiasi regione. L'operazione di eliminazione viene eseguita senza consumare unità di scrittura sulla tabella di origine, ma le tabelle di replica riceveranno una scrittura replicata di tale operazione di eliminazione e comporteranno costi unitari di scrittura replicati. Il TTL non è supportato nelle tabelle MRSC. + Se si utilizza il dimensionamento automatico, assicurarsi che l'impostazione della capacità di scrittura massima con provisioning sia sufficientemente alta per gestire tutte le operazioni di scrittura e tutte le potenziali operazioni di eliminazione TTL. Il dimensionamento automatico adatta ogni regione in base al consumo delle operazioni di scrittura. Le tabelle on demand non hanno un'impostazione di capacità di scrittura massima con provisioning, ma il *limite massimo di velocità di trasmissione effettiva di scrittura a livello di tabella* specifica la capacità massima di scrittura sostenuta consentita dalla tabella on demand. Il limite predefinito è 40.000, ma questo valore è modificabile. È consigliabile impostarlo su un valore sufficientemente alto da gestire tutte le operazioni di scrittura (incluse le operazioni di scrittura TTL) che la tabella on demand potrebbe richiedere. Questo valore deve essere lo stesso in tutte le regioni partecipanti quando vengono configurate le tabelle globali. Alcune considerazioni sulla gestione della capacità di lettura: + Le impostazioni relative alla gestione della capacità di lettura possono differire tra regioni perché si presume che regioni diverse possano avere modelli di lettura indipendenti. Quando si aggiunge una replica globale a una tabella, la capacità della regione di origine viene propagata. Dopo la creazione, è possibile adattare la capacità di lettura di una replica; questa nuova impostazione non viene trasferita all'altra regione. + Quando si usa il dimensionamento automatico di DynamoDB, assicurarsi che le impostazioni relative alla capacità massima di lettura con provisioning siano sufficientemente elevate da gestire tutte le operazioni di lettura in tutte le regioni. Durante le operazioni standard, è possibile che la capacità di lettura venga distribuita tra le regioni, ma durante il failover la tabella dovrebbe essere in grado di adattarsi automaticamente all'aumento del carico di lavoro di lettura. Le tabelle on demand non hanno un'impostazione di capacità di lettura massima con provisioning, ma il *limite massimo di velocità di trasmissione effettiva di lettura a livello di tabella* specifica la capacità massima di lettura sostenuta consentita dalla tabella on demand. Il limite predefinito è 40.000, ma questo valore è modificabile. È consigliabile impostarlo su un livello sufficientemente alto da gestire tutte le operazioni di lettura necessarie alla tabella se tutte le operazioni di lettura dovessero essere instradate a questa regione. + Se una tabella in una Regione in genere non riceve traffico di lettura ma potrebbe dover assorbire una grande quantità di traffico di lettura dopo un failover, è possibile pre-riscaldare la capacità di lettura per accettare un livello più elevato di traffico di lettura. Il sistema ARC dispone di [controlli di idoneità](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html) che possono essere utili per controllare se le Regioni DynamoDB hanno impostazioni di tabella e quote di account simili, indipendentemente dal fatto che si utilizzi Route 53 per instradare le richieste. Questi controlli di idoneità possono anche aiutare ad adattare le quote a livello di account per assicurarsi che corrispondano. # Elenco di controllo di preparazione per tabelle globali DynamoDB Utilizza il seguente elenco di controllo per decisioni e attività relative all’implementazione delle tabelle globali. + 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](bp-global-table-design.prescriptive-guidance.writemodes.md). + Pianifica la strategia [Strategie di instradamento in DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md) in base alla modalità di scrittura scelta. + Definisci i [ Processi di evacuazione Evacuazione di una regione con le tabelle globali L’evacuazione di una Regione è il processo di migrazione delle attività, solitamente delle attività di lettura e scrittura, o delle attività di lettura, dalla Regione. Evacuazione di una regione in tempo realeRegioni in tempo reale Evacuazione di una regione in tempo reale Potresti decidere di evacuare una regione attiva per diversi motivi: come parte della normale attività aziendale (ad esempio, se utilizzi una modalità di scrittura in una regione) follow-the-sun, a causa della decisione aziendale di modificare la regione attualmente attiva, in risposta a guasti nello stack software esterno a DynamoDB o perché stai riscontrando problemi generali come latenze più elevate del solito all'interno della regione. Con la modalità di *scrittura in qualsiasi regione*, l'evacuazione di una regione in tempo reale è semplice. È possibile instradare il traffico verso le Regioni alternative tramite qualsiasi sistema di instradamento e lasciare che le operazioni di scrittura della Regione evacuata si replichino come al solito. Le modalità di scrittura in una Regione e quella di scrittura nella propria Regione vengono generalmente utilizzate con le tabelle MREC. Pertanto, è necessario assicurarsi che tutte le operazioni di scrittura nella nuova Regione attiva siano state completamente registrate, elaborate in streaming e propagate globalmente prima di iniziare le operazioni di scrittura nella nuova Regione attiva, per garantire che le future operazioni di scrittura vengano elaborate sulla versione più recente dei dati. Si supponga che la regione A sia attiva e la regione B sia passiva (per la tabella completa o per gli elementi che si trovano nella regione A). Il meccanismo tipico per eseguire un'evacuazione consiste nel sospendere le operazioni di scrittura nella Regione A, attendere il tempo necessario affinché tali operazioni si siano propagate completamente nella Regione B, aggiornare lo stack dell'architettura per riconoscere la Regione B come attiva e quindi riprendere le operazioni di scrittura nella Regione B. Non esiste una metrica che indichi con assoluta certezza che la Regione A ha replicato completamente i propri dati nella Regione B. Se la Regione A è integra, la sospensione delle operazioni di scrittura nella regione A e l'attesa di 10 volte il valore massimo recente della metrica `ReplicationLatency` sarebbero in genere sufficienti per determinare che la replica è completa. Se la Regione A non è integra e mostra altre aree con latenze aumentate, per definire il tempo di attesa scegliere un valore multiplo più grande. Evacuazione di una regione offlineRegioni offline Evacuazione di una regione offline Esiste un caso speciale da considerare: cosa succede se la Regione A risulta inaspettatamente offline? Ciò è estremamente improbabile, ma va comunque considerato. Evacuazione di una tabella MRSC offline Se ciò accade con una tabella MRSC, non è necessario fare nulla di particolare. Le tabelle MRSC supportano un obiettivo del punto di ripristino (RPO) pari a zero. Tutte le operazioni di scrittura eseguite correttamente sulla tabella MRSC nella Regione offline saranno disponibili in tutte le altre tabelle delle Regioni, quindi non vi è alcuna potenziale lacuna nei dati anche se la Regione passa completamente offline senza preavviso. Le aziende possono continuare a utilizzare le repliche situate nelle altre Regioni. Evacuazione di una tabella MREC offline In questo caso, tutte le operazioni di scrittura nella Regione A non ancora propagate vengono conservate e propagate dopo che la Regione A torna online. Le operazioni di scrittura non vengono perse, ma la loro propagazione viene ritardata a tempo indeterminato. Come procedere in questo caso dipende dall'applicazione. Per la continuità aziendale, potrebbe essere necessario procedere alle operazioni di scrittura nella nuova Regione B. Tuttavia, se un elemento nella Regione B riceve un aggiornamento mentre è in corso la propagazione di un'operazione di scrittura per tale elemento dalla Regione A, la propagazione viene soppressa in base al modello basato sulla *priorità dell'ultima istanza di scrittura*. Qualsiasi aggiornamento nella Regione B potrebbe eliminare una richiesta di scrittura in arrivo. Con la modalità di *scrittura in qualsiasi Regione*, le operazioni di lettura e scrittura possono continuare nella Regione B, con la certezza che gli elementi nella Regione A alla fine si propagheranno alla Regione B e con la possibilità di elementi mancanti fino a quando la Regione A non tornerà online. Quando possibile, come con le operazioni di scrittura idempotenti, è consigliabile valutare la possibilità di rieseguire il traffico di scrittura recente (ad esempio, utilizzando una fonte a monte di eventi) per colmare la lacuna di eventuali operazioni di scrittura potenzialmente mancanti e lasciare che la risoluzione dei conflitti relativi alla priorità dell’ultima istanza di scrittura annulli la propagazione finale dell’operazione di scrittura in entrata. Con le altre modalità di scrittura, è necessario considerare il grado in cui il lavoro può continuare con una out-of-date visione leggermente del mondo. Alcune operazioni di scrittura di breve durata, tracciate da `ReplicationLatency`, risulteranno mancanti fino a quando la Regione A non tornerà online. L'attività aziendale può andare avanti? In alcuni casi d'uso ciò è possibile, ma in altri casi potrebbe non essere possibile senza meccanismi di mitigazione aggiuntivi. Ad esempio, si supponga di dover mantenere disponibile il saldo del credito senza interruzioni anche dopo un’interruzione totale nella Regione. È possibile dividere il saldo in due elementi diversi, uno situato nella Regione A e uno nella Regione B, ciascuno riferito a metà del saldo disponibile. In questo caso si utilizzerebbe la modalità di *scrittura nella propria regione*. Gli aggiornamenti transazionali elaborati in ciascuna regione verrebbero contabilizzati sulla copia locale del saldo. Se la Regione A passa alla modalità offline, l'elaborazione delle transazioni nella Regione B potrebbe continuare e le operazioni di scrittura sarebbero limitate alla parte del saldo conservata nella Regione B. Suddividere il saldo in questo modo comporta difficoltà quando il saldo si esaurisce o il credito deve essere ribilanciato, ma fornisce un esempio di ripristino aziendale sicuro anche con operazioni di scrittura in sospeso incerte. Per fare un altro esempio, si supponga di acquisire i dati dei moduli web. È possibile utilizzare la funzionalità di [controllo della simultaneità ottimistica](DynamoDBMapper.OptimisticLocking.md) (OCC, Optimistic Concurrency Control) per assegnare versioni agli elementi di dati e incorporare la versione più recente nel modulo web come campo nascosto. Ad ogni invio, l'operazione di scrittura ha esito positivo solo se la versione nel database corrisponde alla versione con cui è stato creato il modulo. Se le versioni non corrispondono, il modulo web può essere aggiornato (o unito) in base alla versione corrente nel database e l'utente può procedere. Il modello OCC di solito protegge dalla sovrascrittura e dalla produzione di una nuova versione dei dati da parte di un altro client, ma può anche essere utile durante il failover, situazione in cui un client potrebbe riscontrare versioni precedenti dei dati. Si supponga di utilizzare il timestamp come versione. Si immagini inoltre che il modulo sia stato creato per la prima volta nella Regione A alle 12:00 ma (dopo il failover) tenti di eseguire un’operazione di scrittura nella Regione B e si accorga che l’ultima versione nel database risale alle 11:59. In questo scenario, il client può attendere che la versione delle 12:00 si propaghi nella Regione B e quindi sovrascrivere su quella versione oppure eseguire una compilazione alle 11:59 e creare una nuova versione alle 12:01 (che, dopo la scrittura, eliminerebbe la versione in arrivo dopo il ripristino della Regione A). Come terzo esempio, una società di servizi finanziari conserva i dati sugli account dei clienti e sulle relative transazioni finanziarie in un database DynamoDB. In caso di interruzione completa dei servizi nella Regione A, la società vuole essere sicura che qualsiasi attività di scrittura relativa ai propri account sia disponibile nella Regione B oppure che i propri account vengano messi in quarantena come account parzialmente noti fino a quando la Regione A non torna online. Invece di sospendere tutte le attività, la società decide di sospendere l'attività solo per la piccola parte di account con transazioni ritenute non propagate. A tal fine, la società utilizza una terza regione, definita Regione C. Prima di elaborare qualsiasi operazione di scrittura nella Regione A, nella Regione C la società inserisce un breve riepilogo delle operazioni in sospeso (ad esempio, un nuovo numero di transazioni per un conto). Questo riepilogo è sufficiente per consentire alla Regione B di determinare se la visualizzazione è completamente aggiornata. Questa azione effettivamente blocca l'account dal momento della scrittura nella Regione C fino a quando la Regione A accetta le operazioni di scrittura e la Regione B le riceve. I dati nella Regione C non vengono utilizzati se non come parte di un processo di failover, dopodiché la Regione B controlla i dati con quelli della Regione C per verificare se alcuni dei suoi account non sono aggiornati. Tali account vengono contrassegnati come messi in quarantena fino a quando il ripristino della Regione A non propaga i dati parziali alla Regione C, potrebbe invece essere utilizzata una nuova Regione D. I dati nella regione C erano molto transitori e dopo pochi minuti la regione D avrebbe avuto una up-to-date registrazione sufficiente delle operazioni di scrittura in volo per essere pienamente utili. Se si verifica un guasto nella Regione B, la Regione A potrebbe continuare ad accettare richieste di scrittura in collaborazione con la Regione C. La società è disposta ad accettare scritture a latenza più elevata (verso due regioni, ovvero C e poi A) ed è fortunata a disporre di un modello di dati in cui lo stato di un account può essere riassunto in modo sintetico. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title) [Processi di evacuazione](bp-global-table-design.prescriptive-guidance.evacuation.md) 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](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) un elenco di metriche da osservare. È inoltre consigliabile utilizzare [canary sintetici](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (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](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) è 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. **Nota** Con le procedure di failover, è 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 degradarsi 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](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/): 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](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 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. ## Domande frequenti relative alla distribuzione delle tabelle globali **Quali sono i prezzi delle tabelle globali?** + 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. **Quali sono regioni supportate dalle tabelle globali?** [La versione 2019.11.21 (corrente) di Global Tables](GlobalTables.md) supporta tutte le tabelle MREC e i seguenti set di regioni Regioni AWS per le tabelle MRSC: + 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) **Come vengono gestite le tabelle globali? GSIs ** Nelle [Tabelle globali versione 2019.11.21 (Corrente)](GlobalTables.md), quando viene creato un GSI in una Regione, tale indice viene automaticamente creato e compilato nelle altre Regioni partecipanti. **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. + 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. **In che modo i flussi DynamoDB interagiscono con le tabelle globali?** + 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. **In che modo le tabelle globali gestiscono le transazioni?** + 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. **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](PointInTimeRecovery_Howitworks.md) (PITR) in una regione. **Come posso distribuire tabelle globali utilizzando? 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 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 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 [Per ulteriori informazioni, consulta il AWS GitHub repository.](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk) + La replica su più account non è al momento supportata. ## Conclusioni e risorse Le tabelle globali DynamoDB hanno pochissimi controlli ma richiedono comunque un’attenta considerazione. È 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 è avere un set di dati distribuito a livello globale con operazioni di lettura e scrittura a bassa latenza progettato per una disponibilità del 99,999%. Per ulteriori informazioni sulle tabelle globali DynamoDB, consulta le seguenti risorse: + [Documentazione di DynamoDB](https://docs.aws.amazon.com/dynamodb/) + [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) + [Controllo di idoneità in ARC (documentazione](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html))AWS + [Route 53 routing policies](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [AWS Acceleratore globale](https://aws.amazon.com/global-accelerator/) + [Accordo sul livello di servizio di DynamoDB](https://aws.amazon.com/dynamodb/sla/) + [AWS Nozioni di base su più regioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) (white paper)AWS + Modelli di [progettazione della resilienza dei dati](https://www.youtube.com/watch?v=7IA48SOX20c) con (presentazione re:Invent 2022) AWSAWS + [Come Fidelity Investments e Reltio si sono modernizzati con Amazon DynamoDB (presentazione re:Invent](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s) 2022)AWS + Modelli di progettazione e [best practice multiregionali](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) (presentazione re:Invent 2022)AWS + [Architettura di disaster recovery (DR) attiva AWS, parte III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (post sul blog)AWS + [Usa Region Pinning per impostare una regione di origine per gli elementi in una tabella globale AWS di Amazon DynamoDB (post](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/) del blog) + [Monitoraggio di Amazon DynamoDB per la consapevolezza AWS operativa](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) (post sul blog) + [Scalabilità di DynamoDB: in che modo le partizioni, i tasti di scelta rapida e la suddivisione per il riscaldamento influiscono](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/) sulle prestazioni (post sul blog)AWS + [Forte coerenza multiregionale con le tabelle AWS globali di DynamoDB (presentazione re:Invent](https://www.youtube.com/watch?v=R-nTs8ZD8mA) 2024)