Dati in streaming con DynamoDB

Sviluppare applicazioni su AWS

Ricardo Sueiras

Principal Technologist

Fondamentali di DynamoDB Streams

 

• Reagisci alle modifiche del database quasi in tempo reale.
• Basato su pattern event-driven.
• Ogni insert, modify o delete genera un record di stream.
• Crea app reattive senza fare polling della tabella.
• Disattivato per impostazione predefinita: abilita con StreamSpecification.
• Ogni stream ha un proprio ARN, distinto dall'ARN della tabella.

Periodo di conservazione

 

• I record di stream sono conservati per 24 ore.
  • La retention è fissa e non configurabile.
• Cambiare il tipo di vista richiede di ricreare lo stream.
  • Un nuovo stream genera un nuovo ARN di stream.

Stream e read capacity units di DynamoDB

 

• Le letture dallo stream NON consumano i tuoi read capacity units (RCU).
• Abilitare gli stream non impatta sul throughput preconfigurato.

Record di stream

• Ogni record di stream include metadati che descrivono la modifica.
• Gli stream catturano tre tipi di evento:
  • INSERT
  • MODIFY
  • REMOVE

 

• I tipi di vista controllano quali dati finiscono in ogni record.
  • KEYS_ONLY: solo chiave di partizione e di ordinamento.
  • NEW_IMAGE: l'elemento completo dopo la modifica.
  • OLD_IMAGE: l'elemento completo prima della modifica.
  • NEW_AND_OLD_IMAGES: l'elemento prima e dopo.
• NEW_AND_OLD_IMAGES è lo standard per l'auditing.
• Richiesto per le DynamoDB Global Tables.

• Gli stream preservano l'ordine per chiave di partizione.
• Lambda elabora i record in batch.
  • Effettua il checkpoint dopo ogni batch riuscito.
  • I batch non riusciti vengono ritentati.
  • I retry continuano finché riescono o i record scadono.

 

 

• Lambda è il consumer di stream più comune.
• Usa un event source mapping basato su polling.
• Legge i record dallo stream.
• Invoca la tua funzione con batch di record.

Pattern architetturale

 

• Un pattern end-to-end comune:
  • Un aggiornamento di un elemento arriva in DynamoDB.
  • La modifica genera un record di stream.
  • Il record attiva Lambda per l'elaborazione.

Scalabilità

 

• Gli stream sono suddivisi internamente in shard.
  • Molto simile a Kinesis Data Streams.
• Ogni shard consente fino a due consumer simultanei.
  • Superare questo limite causa spesso throttling in lettura.

• La concurrency di Lambda scala con il numero di shard.
• Ottimizza l'elaborazione con:
  • BatchSize: max record per invocazione.
  • MaximumBatchingWindow: attesa prima di un batch parziale.
  • MaximumRetryAttempts: retry prima della failure destination.
  • MaximumRecordAgeInSeconds: scarta record oltre questa età.
  • ParallelizationFactor: elaborazione concorrente per shard (max 10).

Filtraggio e tumbling windows

• Lambda supporta criteri di filtro.
  • Scarta i record prima che la funzione sia invocata.
  • Riduce invocazioni inutili e costi.
• Lambda supporta le tumbling windows.
  • Aggrega stato tra batch in uno shard.

 

Gestire i record duplicati

• Gli stream catturano ogni modifica esattamente una volta.
• Lambda elabora i record con semantica at-least-once.
  • I retry possono rielaborare lo stesso record.
• Progetta i consumer per essere idempotenti.
• Pattern comune: memorizza eventID o SequenceNumber già elaborati.
  • Salta i record già gestiti.
  • Entrambi restano stabili tra i retry.
  • Chiavi di idempotenza affidabili.

 

Gestione degli errori

 

• ReportBatchItemFailures ritenta solo i record falliti.
• Gestisci gli errori di Lambda con:
  • BisectBatchOnFunctionError per dividere il batch.
  • Controlli di retry.
  • Failure destination per batch «velenosi» che esauriscono i retry.

Integrazione da DynamoDB a Kinesis

 

• Le tabelle possono inviare le modifiche direttamente a Kinesis Data Streams.
  • Tramite la funzionalità Kinesis Data Streams for DynamoDB.
  • Capacità separata e parallela, non in cascata.
  • Gli eventi NON passano da DynamoDB Streams.
• Entrambe possono operare sulla stessa tabella contemporaneamente.
  • Operano in modo indipendente.
  • Alimentano architetture di streaming e analytics più ampie.

Monitoraggio: problemi comuni

 

• Problemi operativi comuni da monitorare:
  • Partizioni calde.
  • Retry falliti.
  • Elaborazioni duplicate.
  • Throttling e lag dei consumer.

Monitoraggio: metriche CloudWatch

• Metriche CloudWatch chiave da monitorare:
  • Lambda Errors: evidenziano problemi di codice o a valle.
  • IteratorAge: valori alti indicano consumer lenti.
  • Metriche di throttling: superamento dei limiti di lettura.
  • Errori di elaborazione batch: record inviati a una DLQ.

 

Sicurezza

• L'accesso agli stream è controllato con permessi IAM.
• Gli stream ereditano le impostazioni di crittografia della tabella.
  • Inclusa la crittografia lato server a riposo con KMS.
• Applica policy di minimo privilegio a consumer e processori a valle.

 

Esercitiamoci!

Sviluppare applicazioni su AWS