DynamoDB Streams und globale Tabellen

DynamoDB Streams erfassen eine zeitlich geordnete Folge von Änderungen auf Elementebene in einer DynamoDB-Tabelle. Jedes Mal, wenn ein Element erstellt, aktualisiert oder gelöscht wird, schreibt DynamoDB einen Stream-Datensatz, der die Änderung beschreibt. Stream-Datensätze sind nach dem Schreiben 24 Stunden lang verfügbar.

Streams bilden die Grundlage ereignisgesteuerter Architekturen mit DynamoDB. Zu den typischen Anwendungsfällen gehören das Auslösen von Lambda-Funktionen zur Echtzeitverarbeitung, das Führen eines Auditprotokolls, die Replikation von Daten in einen anderen Speicher oder die Invalidierung eines Caches bei Datenänderungen.

Beim Aktivieren eines Streams wählen Sie einen StreamViewType, der festlegt, welche Daten jeder Stream-Datensatz enthält:

• KEYS_ONLY: nur die Primärschlüsselattribute des geänderten Elements
• NEW_IMAGE: das gesamte Element nach der Änderung
• OLD_IMAGE: das gesamte Element vor der Änderung
• NEW_AND_OLD_IMAGES: sowohl der Zustand des Elements vor als auch nach der Änderung

Wählen Sie NEW_AND_OLD_IMAGES für Audits (um zu sehen, was sich geändert hat), NEW_IMAGE für Replikation oder Cache-Aktualisierungen und KEYS_ONLY, wenn Sie nur wissen müssen, welches Element geändert wurde, und den aktuellen Zustand separat abrufen.

Die häufigste Methode, einen DynamoDB Stream zu konsumieren, ist AWS Lambda. Lambda fragt den Stream ab und ruft Ihre Funktion mit einem Stapel von Stream-Datensätzen auf. Lambda übernimmt automatisch das Abrufen, das Setzen von Checkpoints und Wiederholungsversuche.

Wichtige Konfigurationsparameter: batch size (Anzahl der Datensätze pro Aufruf, bis zu 10.000), bisect on error (Aufteilen eines fehlgeschlagenen Stapels, um den fehlerhaften Datensatz zu isolieren) und destination on failure (SQS oder SNS für nicht verarbeitbare Datensätze). Lambda liest parallel aus jedem Shard. Die Parallelität entspricht daher der Anzahl der Shards im Stream.

Praktische Anwendungsfälle für DynamoDB Streams in der SAA-C03-Prüfung:

• Regionsübergreifende Replikation: Lambda liest den Stream und schreibt Änderungen in eine Tabelle in einer anderen Region (bevor es Global Tables gab, war dies das Standardmuster)
• ElastiCache-Invalidierung: Wenn sich ein DynamoDB-Element ändert, invalidiert oder aktualisiert Lambda den entsprechenden Cache-Schlüssel
• Synchronisierung eines Suchindex: Übertragen Sie Elementänderungen an OpenSearch Service, um die Volltextsuche in DynamoDB-Daten zu ermöglichen
• Auditprotokollierung: Schreiben Sie jede Änderung zu regulatorischen Zwecken in S3 oder einen Compliance-Speicher
• Ereignisgesteuerte Microservices: Lösen Sie nachgelagerte Services aus, wenn sich bestimmte Elemente ändern

DynamoDB Global Tables bieten eine vollständig verwaltete, multiregionale Replikation mit aktivem Betrieb in mehreren Regionen. Jede Region erhält eine vollständige Kopie der Tabelle, und alle Kopien können gleichzeitig beschrieben werden. Schreibvorgänge in einer Region werden innerhalb von etwa 1 Sekunde asynchron in alle anderen Regionen repliziert.

Global Tables ermöglichen zwei wichtige Szenarien: Lese- und Schreibvorgänge mit niedriger Latenz für global verteilte Benutzer (jeder Benutzer schreibt in die nächstgelegene Region und liest daraus) sowie eine multiregionale Active-Active-Notfallwiederherstellung (die Anwendung läuft in jeder noch verfügbaren Region ohne Datenverlust seit der letzten Replikation weiter).

Zum Erstellen einer Global Table erstellen Sie zunächst eine Tabelle mit aktiviertem DynamoDB Stream (NEW_AND_OLD_IMAGES ist intern für Global Tables erforderlich). Anschließend fügen Sie Replikatregionen hinzu. AWS erstellt in jeder hinzugefügten Region eine Replikattabelle und beginnt mit der bidirektionalen Synchronisierung der Daten.

Global Tables (Version 2019.11.21) sind der aktuelle Standard und unterstützen On-Demand- oder bereitgestellte Kapazität mit Auto Scaling. Jedes Replikat in einer Region muss denselben Tabellennamen haben. Sie können jederzeit Regionen zu einer Global Table hinzufügen oder daraus entfernen.

Da Global Tables gleichzeitige Schreibvorgänge in mehreren Regionen ermöglichen, können Schreibkonflikte auftreten, wenn zwei Regionen nahezu gleichzeitig dasselbe Element aktualisieren. DynamoDB löst Konflikte nach dem Prinzip last-writer-wins anhand von Zeitstempeln, die in den Stream-Datensätzen gespeichert sind.

In der Praxis bedeutet dies, dass bei zwei nahezu gleichzeitigen widersprüchlichen Aktualisierungen eine gewinnt und die andere überschrieben wird. Anwendungen sollten so entworfen werden, dass gleichzeitige Schreibvorgänge aus verschiedenen Regionen für dasselbe Element vermieden werden. Wenn Konflikte häufig auftreten, sollten Sie in Betracht ziehen, alle Schreibvorgänge für einen bestimmten Benutzer oder eine bestimmte Entität an eine einzige Heimatregion zu leiten.

Bei Global Tables werden Schreibvorgänge in einer Region automatisch in alle anderen Regionen repliziert. Jeder replizierte Schreibvorgang verbraucht WCUs in den Zielregionen – bei 3 Regionen kostet ein einzelner Schreibvorgang über alle Regionen hinweg ungefähr das Dreifache der WCUs. Planen Sie die Kapazität entsprechend.

Lesevorgänge in jeder Region verbrauchen die RCUs des lokalen Replikats. Eventual-consistent-Lesevorgänge (die Standardeinstellung) verwenden lokale Daten, während stark konsistente Lesevorgänge über Regionen hinweg nicht unterstützt werden. Für die meisten globalen Anwendungen ist eine eventual-consistent-Synchronisierung innerhalb von etwa 1 Sekunde zwischen den Regionen akzeptabel.

Ein wichtiger Unterschied für die SAA-C03-Prüfung: DynamoDB Global Tables sind multi-active (alle Regionen akzeptieren Lese- UND Schreibvorgänge), während regionsübergreifende Read Replicas von RDS read-only sind (Sie können ein Replikat nur hochstufen, um es beschreibbar zu machen, und unterbrechen dadurch die Replikation).

Verwenden Sie DynamoDB Global Tables, wenn Sie Folgendes benötigen: multiregionale Active-Active-Schreibvorgänge, weltweit einen Zugriff mit weniger als 100 ms oder eine multiregionale NoSQL-Notfallwiederherstellung mit einem RPO von null. Verwenden Sie regionsübergreifende RDS-Replikate, wenn Sie Folgendes benötigen: globale Leseskalierbarkeit für eine relationale Datenbank oder ein betriebsbereites Notfallwiederherstellungs-Standby, das Sie im Failover-Fall hochstufen können.

Häufige Architekturmuster, die Streams und Lambda kombinieren:

• Fan-out: Lambda liest den Stream und veröffentlicht die Daten in SNS. SNS verteilt sie auf mehrere SQS-Warteschlangen für unabhängige Konsumenten
• Aggregation: Lambda sammelt Änderungen und aktualisiert aggregierte Summen in einer separaten DynamoDB-Tabelle (z. B. die tägliche Anzahl von Bestellungen)
• Write-behind-Cache: Bei jedem Stream-Ereignis aktualisiert Lambda ElastiCache, sodass Lesevorgänge aus dem Cache bedient werden können
• Benachrichtigung: Der Stream löst Lambda aus. Lambda sendet eine SES-E-Mail oder Push-Benachrichtigung über SNS, wenn sich eine bestimmte Bedingung ändert

Als Alternative zu DynamoDB Streams können Sie Änderungen auf Elementebene an einen Amazon Kinesis Data Stream weiterleiten. Das ist nützlich, wenn Sie eine längere Aufbewahrungsdauer (bis zu 1 Jahr statt 24 Stunden bei nativen DynamoDB Streams), mehr Consumer oder eine Integration mit Services benötigen, die Daten aus Kinesis lesen.

Die Integration mit Kinesis Data Streams wird pro Tabelle aktiviert und ersetzt DynamoDB Streams nicht – Sie können beide gleichzeitig aktivieren. Diese neuere Funktion (seit 2021) erweitert die Pipeline für Änderungsereignisse von DynamoDB, ohne dass Sie eine eigene Replikationslogik implementieren müssen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: DynamoDB Streams erfassen Änderungen auf Elementebene 24 Stunden lang und lassen sich für ereignisgesteuerte Verarbeitung in Lambda integrieren, Global Tables ermöglichen eine Multi-Active-Replikation über mehrere Regionen mit einer Konfliktauflösung nach dem Prinzip „Last Writer Wins“, und die Integration mit Kinesis Data Streams verlängert die Aufbewahrungsdauer über das 24-Stunden-Zeitfenster von Streams hinaus. Als Nächstes sehen wir uns in Route 53 gehostete Zonen und DNS-Eintragstypen an.