Streaming-Daten mit DynamoDB

Anwendungen auf AWS entwickeln

Ricardo Sueiras

Principal Technologist

DynamoDB Streams: Grundlagen

 

• Reagiere fast in Echtzeit auf Datenbankänderungen.
• Basiert auf ereignisgetriebenen Mustern.
• Jeder Insert, jedes Update oder Delete erzeugt einen Stream-Datensatz.
• Baue reaktive Apps ohne Table-Polling.
• Standardmäßig aus: aktiviere mit StreamSpecification.
• Jeder Stream hat eine eigene ARN, getrennt von der Tabellen-ARN.

Aufbewahrungszeitraum

 

• Stream-Datensätze werden 24 Stunden aufbewahrt.
  • Die Aufbewahrung ist fest und nicht konfigurierbar.
• Ändern des View-Typs erfordert das Neuerstellen des Streams.
  • Ein neuer Stream erzeugt eine neue Stream-ARN.

Streams und DynamoDB Read Capacity Units

 

• Stream-Reads verbrauchen KEINE Read Capacity Units (RCUs).
• Streams aktivieren beeinflusst den bereitgestellten Durchsatz nicht.

Stream-Datensätze

• Jeder Stream-Datensatz enthält Metadaten zur Änderung.
• Streams erfassen drei Ereignistypen:
  • INSERT
  • MODIFY
  • REMOVE

 

• View-Typen steuern, welche Daten im Datensatz landen.
  • KEYS_ONLY: nur Partition- und Sortierschlüssel.
  • NEW_IMAGE: komplettes Item nach der Änderung.
  • OLD_IMAGE: komplettes Item vor der Änderung.
  • NEW_AND_OLD_IMAGES: Item davor und danach.
• NEW_AND_OLD_IMAGES ist Standard fürs Auditing.
• Erforderlich für DynamoDB Global Tables.

• Streams bewahren die Reihenfolge pro Partitionsschlüssel.
• Lambda verarbeitet Datensätze in Batches.
  • Checkpoints nach jedem erfolgreichen Batch.
  • Fehlgeschlagene Batches werden erneut versucht.
  • Wiederholungen laufen bis Erfolg oder Ablauf.

 

 

• Lambda ist der häufigste Stream-Consumer.
• Nutzt ein Polling-basiertes Event-Source-Mapping.
• Liest Datensätze aus dem Stream.
• Ruft deine Funktion mit Batches von Datensätzen auf.

Architekturmuster

 

• Ein gängiges End-to-End-Muster:
  • Ein Item-Update landet in DynamoDB.
  • Die Änderung erzeugt einen Stream-Datensatz.
  • Der Datensatz triggert Lambda zur Verarbeitung.

Skalierung

 

• Streams sind intern in Shards aufgeteilt.
  • Ähnlich wie Kinesis Data Streams.
• Pro Shard sind bis zu zwei gleichzeitige Consumer erlaubt.
  • Überschreitungen führen oft zu Read-Throttling.

• Lambda-Concurrency skaliert mit der Shard-Anzahl.
• Feintuning der Verarbeitung mit:
  • BatchSize: max. Datensätze pro Aufruf.
  • MaximumBatchingWindow: Wartezeit vor Teilbatch.
  • MaximumRetryAttempts: Wiederholungen bis Failure Destination.
  • MaximumRecordAgeInSeconds: verwerfe zu alte Datensätze.
  • ParallelizationFactor: parallele Verarbeitung pro Shard (max. 10).

Filtering und Tumbling Windows

• Lambda unterstützt Filterkriterien.
  • Verwirf Datensätze vor dem Funktionsaufruf.
  • Reduziert unnötige Aufrufe und Kosten.
• Lambda unterstützt Tumbling Windows.
  • Aggregiere Zustand über Batches in einem Shard.

 

Doppelte Datensätze verwalten

• Streams erfassen jede Änderung genau einmal.
• Lambda verarbeitet Datensätze mit At-least-once-Semantik.
  • Retries können denselben Datensatz erneut verarbeiten.
• Designe Consumer idempotent.
• Gängiges Muster: verarbeitetes eventID oder SequenceNumber speichern.
  • Überspringe bereits bearbeitete Datensätze.
  • Beide bleiben über Retries stabil.
  • Zuverlässige Idempotency-Keys.

 

Fehler behandeln

 

• ReportBatchItemFailures wiederholt nur fehlgeschlagene Datensätze.
• Behandle Lambda-Fehler mit:
  • BisectBatchOnFunctionError für Batch-Halbierung.
  • Retry-Steuerung.
  • Failure Destinations für Poison Batches nach erschöpften Retries.

Integration: DynamoDB zu Kinesis

 

• Tabellen können Änderungen direkt an Kinesis Data Streams senden.
  • Über das Feature „Kinesis Data Streams for DynamoDB".
  • Eine separate, parallele Fähigkeit, keine Verkettung.
  • Events fließen NICHT durch DynamoDB Streams.
• Beides kann gleichzeitig auf derselben Tabelle laufen.
  • Arbeiten unabhängig voneinander.
  • Versorgt breitere Streaming- und Analytics-Architekturen.

Monitoring: häufige Probleme

 

• Häufige Betriebsprobleme:
  • Heiße Partitionen.
  • Fehlgeschlagene Retries.
  • Doppelte Verarbeitung.
  • Throttling und Consumer-Lag.

Monitoring: CloudWatch-Metriken

• Wichtige CloudWatch-Metriken:
  • Lambda Errors: zeigt Code- oder Downstream-Probleme.
  • IteratorAge: hohe Werte = langsame Consumer.
  • Throttling-Metriken: überschrittene Read-Limits.
  • Batch-Verarbeitungsfehler: Datensätze in einer DLQ.

 

Sicherheit

• Zugriff auf Streams wird über IAM-Berechtigungen gesteuert.
• Streams erben die Verschlüsselungseinstellungen der Tabelle.
  • Einschließlich serverseitiger Verschlüsselung at rest mit KMS.
• Wende Least-Privilege-Policies auf Consumer und Downstream-Prozessoren an.

 

Lass uns üben!

Anwendungen auf AWS entwickeln