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.

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.

A volte è necessario modificare la Regione attiva in risposta a un guasto a livello Regionale. Alcuni utenti cambieranno la Regione attualmente attiva in base a una pianificazione regolare, ad esempio mediante un’implementazione basata sull’approccio “follow the sun” (operatività 24 ore su 24). 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, consulta 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.

È possibile determinare la Regione di origine degli elementi in diversi modi:

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. Tale Regione esegue tutte le operazioni di lettura e scrittura, garantendo sempre un’elevata consistenza di lettura dopo la scrittura. 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.