DynamoDB Streams e Global Tables

DynamoDB Streams acquisisce una sequenza ordinata temporalmente delle modifiche a livello di elemento in una tabella DynamoDB. Ogni volta che un elemento viene creato, aggiornato o eliminato, DynamoDB scrive un record nello stream che descrive la modifica. I record dello stream sono disponibili per 24 ore dalla loro scrittura.

Gli stream sono alla base delle architetture basate sugli eventi con DynamoDB. Tra gli usi comuni vi sono l'attivazione di funzioni Lambda per l'elaborazione in tempo reale, la gestione di un audit log, la replica dei dati in un altro archivio o l'invalidazione di una cache quando i dati cambiano.

Quando abilita uno stream, sceglie un StreamViewType che determina quali dati contiene ogni record dello stream:

• KEYS_ONLY: solo gli attributi della chiave primaria dell'elemento modificato
• NEW_IMAGE: l'intero elemento come appare dopo la modifica
• OLD_IMAGE: l'intero elemento come appariva prima della modifica
• NEW_AND_OLD_IMAGES: sia lo stato dell'elemento prima della modifica sia quello successivo

Scelga NEW_AND_OLD_IMAGES per l'audit (per vedere cosa è cambiato), NEW_IMAGE per la replica o gli aggiornamenti della cache e KEYS_ONLY quando deve solo sapere quale elemento è cambiato e recupererà separatamente lo stato corrente.

Il modo più comune per utilizzare un DynamoDB Stream consiste nell'impiegare AWS Lambda. Lambda esegue il polling dello stream e invoca la funzione con un batch di record dello stream. Lambda gestisce automaticamente il polling, il checkpoint e i nuovi tentativi.

Parametri di configurazione principali: dimensione del batch (numero di record per invocazione, fino a 10.000), bisect on error (suddivide un batch non riuscito per isolare il record problematico) e destinazione in caso di errore (SQS o SNS per i record non elaborabili). Lambda legge da ogni shard in parallelo, quindi il parallelismo è pari al numero di shard nello stream.

Casi d'uso pratici di DynamoDB Streams per l'esame SAA-C03:

• Replica tra regioni: Lambda legge lo stream e scrive le modifiche in una tabella di un'altra Regione (prima dell'introduzione di Global Tables, questo era il modello standard)
• Invalidazione di ElastiCache: quando un elemento DynamoDB cambia, Lambda invalida o aggiorna la chiave della cache corrispondente
• Sincronizzazione dell'indice di ricerca: invia le modifiche degli elementi a OpenSearch Service per abilitare la ricerca full-text sui dati DynamoDB
• Registrazione degli audit: scrive ogni modifica in S3 o in un archivio per la conformità normativa
• Microservizi basati sugli eventi: attiva i servizi downstream quando cambiano determinati elementi

DynamoDB Global Tables forniscono una replica multi-Regione e multi-attiva completamente gestita. Ogni Regione riceve una copia completa della tabella e tutte le copie sono scrivibili contemporaneamente. Le scritture effettuate in una Regione vengono replicate in modo asincrono in tutte le altre Regioni entro circa 1 secondo.

Global Tables consentono due scenari fondamentali: letture e scritture a bassa latenza per utenti distribuiti a livello globale (ogni utente scrive e legge dalla Regione più vicina) e disaster recovery multi-Regione active-active (l'applicazione continua a funzionare in qualsiasi Regione sopravvissuta, senza perdita di dati successivi all'ultima replica).

Per creare una Global Table, crei prima una tabella con DynamoDB Streams abilitato (NEW_AND_OLD_IMAGES è richiesto internamente da Global Tables). Quindi aggiunga le Regioni replica. AWS crea una tabella replica in ogni Regione aggiunta e avvia la sincronizzazione bidirezionale dei dati.

Global Tables (Version 2019.11.21) sono lo standard attuale e supportano la capacità On-Demand o Provisioned con Auto Scaling. Ogni replica regionale deve avere lo stesso nome della tabella. Può aggiungere o rimuovere Regioni da una Global Table in qualsiasi momento.

Poiché Global Tables consentono scritture simultanee in più Regioni, possono verificarsi conflitti di scrittura se due Regioni aggiornano lo stesso elemento quasi nello stesso momento. DynamoDB risolve i conflitti utilizzando un approccio last-writer-wins basato sui timestamp memorizzati nei record dello stream.

In pratica, due aggiornamenti in conflitto quasi simultanei producono un aggiornamento vincente e uno sovrascritto. Le applicazioni dovrebbero essere progettate per evitare scritture simultanee sullo stesso elemento da Regioni diverse. Per i casi d'uso in cui i conflitti sono frequenti, valuti di indirizzare tutte le scritture relative a uno specifico utente o entità verso un'unica Regione principale.

Con Global Tables, le scritture in una Regione vengono replicate automaticamente in tutte le altre Regioni. Ogni scrittura replicata consuma WCU nelle Regioni di destinazione: se dispone di 3 Regioni, una singola scrittura costa all'incirca 3× le WCU complessive. Pianifichi la capacità di conseguenza.

Le letture in ogni Regione consumano le RCU della replica locale. Le letture eventualmente coerenti (impostazione predefinita) utilizzano i dati locali, mentre le letture fortemente coerenti non sono supportate tra Regioni. Per la maggior parte delle applicazioni globali, una coerenza eventuale entro circa 1 secondo tra le Regioni è accettabile.

Una distinzione importante per l'esame SAA-C03: le Global Tables di DynamoDB sono multi-attive (tutte le Regioni accettano letture E scritture), mentre le Read Replica tra regioni di RDS sono di sola lettura (può promuovere una replica per renderla scrivibile, interrompendo la replica).

Utilizzi DynamoDB Global Tables quando ha bisogno di: scritture active-active multi-Regione, accesso globale inferiore a 100 ms o disaster recovery multi-Regione con RPO pari a zero per dati NoSQL. Utilizzi le repliche RDS tra regioni quando ha bisogno di: scalabilità globale delle letture per un database relazionale o di un ambiente standby di disaster recovery pronto da promuovere in caso di failover.

Modelli architetturali comuni che combinano Streams e Lambda:

• Fan-out: Lambda legge lo stream e pubblica su SNS, che distribuisce i messaggi a più code SQS per consumer indipendenti
• Aggregazione: Lambda accumula le modifiche e aggiorna i totali aggregati in una tabella DynamoDB separata (ad esempio, il numero giornaliero di ordini)
• Write-behind cache: a ogni evento dello stream, Lambda aggiorna ElastiCache, consentendo di servire le letture dalla cache
• Notifica: lo stream attiva Lambda, che invia un'e-mail SES o una notifica push SNS quando cambia una condizione specifica

In alternativa a DynamoDB Streams, è possibile inviare le modifiche a livello di elemento a un Amazon Kinesis Data Stream. Questa soluzione è utile quando sono necessari periodi di conservazione più lunghi (fino a 1 anno rispetto alle 24 ore di DynamoDB Streams nativo), un numero maggiore di consumer o l'integrazione con servizi che leggono da Kinesis.

L'integrazione con Kinesis Data Streams viene abilitata per singola tabella e non sostituisce DynamoDB Streams: è possibile mantenere entrambe le funzionalità abilitate contemporaneamente. Si tratta di una funzionalità più recente (del 2021) che estende la pipeline degli eventi di modifica di DynamoDB senza richiedere una logica di replica personalizzata.

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: DynamoDB Streams acquisisce le modifiche a livello di elemento per 24 ore e si integra con Lambda per l'elaborazione basata sugli eventi, le Global Tables forniscono la replica multi-attiva e multi-regione con risoluzione dei conflitti basata sull'ultima scrittura, mentre l'integrazione con Kinesis Data Streams estende la conservazione oltre la finestra di 24 ore dello stream. Nella prossima lezione esamineremo le hosted zone di Route 53 e i tipi di record DNS.