DynamoDB Global Tables: Multi-Region-Replikation erklärt

Eine Global Table ist eine einzige DynamoDB-Tabelle, die über mehrere AWS- Regionen repliziert wird, wobei jedes Replikat beschreibbar ist. DynamoDB hält sie automatisch synchron — du bekommst latenzarme lokale Lese- und Schreibvorgänge in jeder Region plus regionsübergreifende Notfallwiederherstellung, ohne deine eigene Replikation zu betreiben.

Im Audit-Log-Szenario verlangt ein EU-Kunde, dass seine Daten in eu-west-1 leben, während der Rest in us-east-1 läuft. Und als compliance-kritisches Log muss es einen vollständigen regionalen Ausfall überstehen. Eine Global Table beantwortet beides mit einem Feature.

Wie funktionieren DynamoDB Global Tables?

DynamoDB Global Tables sind eine einzige Tabelle, die über mehrere AWS-Regionen repliziert wird, wobei jedes Replikat les- und schreibbar ist. DynamoDB synchronisiert sie automatisch über letztendlich konsistente asynchrone Replikation und löst Konflikte per Last-Writer-Wins. Du bekommst latenzarme lokale Lese- und Schreibvorgänge pro Region plus regionsübergreifende Notfallwiederherstellung, was DynamoDBs 99,999-%-Verfügbarkeits-SLA untermauert.

• Multi-Region, Active-Active. Jedes Replikat ist vollständig les- und schreibbar; Schreibvorgänge in jeder Region propagieren zu den anderen.
• Im Standardmodus ist die Replikation asynchron und letztendlich konsistent über Regionen hinweg — typischerweise innerhalb einer Sekunde, aber nicht sofort. (Ein Modus mit starker Konsistenz existiert ebenfalls — siehe unten.)
• Konflikte lösen sich per Last-Writer-Wins. Gleichzeitige Schreibvorgänge auf dasselbe Item in zwei Regionen versöhnen sich zum jüngsten.
• Es untermauert das 99,999-%-Verfügbarkeits-SLA — eine Multi-Region-Global-Table ist DynamoDBs Konfiguration mit der höchsten Verfügbarkeit.

Das Problem: eine Region reicht nicht

Eine Single-Region-Tabelle hat zwei Grenzen, die das Audit-Log nicht akzeptieren kann. Erstens Daten- residenz: die Events eines EU-Kunden müssen in der EU gespeichert werden, aber deine App läuft in den USA. Zweitens Notfallwiederherstellung: wenn us-east-1 einen Ausfall hat, ist ein Single-Region- Audit-Log für die Dauer unlesbar und unbeschreibbar — genau dann, wenn du den Datensatz dessen, was passiert ist, am meisten brauchst.

Beides selbst zu bauen — regionsübergreifende Replikation, Failover, Konfliktbehandlung — ist ein großes, fehleranfälliges Projekt. Global Tables machen es zu einer Konfigurationswahl.

Replikationsmechanik

Du fügst der Tabelle eine Replikat-Region hinzu; DynamoDB erstellt dort eine Kopie und hält alle Replikate synchron.

Zwei Konsistenzregeln definieren das Standardverhalten (MREC):

• Regionsübergreifende Replikation ist asynchron. Ein Schreibvorgang in us-east-1 wird lokal bestätigt, dann zu eu-west-1 propagiert — normalerweise innerhalb einer Sekunde, aber ein Lesevorgang in der anderen Region direkt nach einem Schreibvorgang sieht ihn vielleicht noch nicht. (Im Standard-MREC-Modus funktionieren stark konsistente Lesevorgänge weiterhin, aber nur innerhalb einer einzigen Region.)
• Konflikte sind Last-Writer-Wins. Wird dasselbe Item in zwei Regionen zu nahezu derselben Zeit geschrieben, behält DynamoDB den Schreibvorgang mit dem jüngsten Zeitstempel und verwirft den anderen.

Ein durchgearbeitetes Beispiel: ein EU-Replikat, das auch DR ist

Du fügst eu-west-1 als Replikat der Audit-Log-Tabelle hinzu. Nun:

Die App des EU-Kunden schreibt in und liest aus dem lokalen eu-west-1-Replikat — niedrige Latenz und in-Region ansässige Daten. Dieselbe Replikation, die die Residenz erfüllt, dient zugleich als Notfallwiederherstellung: wenn us-east-1 ausfällt, hält das eu-west-1-Replikat weiterhin das vollständige Log und bedient Traffic; du machst ein Failover darauf.

Weil das Audit-Log append-only und pro-Tenant-partitioniert ist, ist Last-Writer- Wins hier im Grunde ein Nicht-Problem — die Events eines gegebenen Tenants werden aus einer Region geschrieben und Event-Keys sind eindeutig, sodass zwei Regionen selten um dasselbe Item rennen. Das ist kein Glück; es ist der Grund, warum ein Append-only-Log einer der saubersten Fits für Global Tables ist. Ein veränderlicher Zähler bräuchte dagegen Vorsicht unter gleichzeitigen regionsübergreifenden Schreibvorgängen.

In DynoTable umsetzen

Nach dem Hinzufügen eines Replikats willst du bestätigen, dass die Daten tatsächlich in der neuen Region gelandet sind und mit der Quelle übereinstimmen — dass das EU-Replikat wirklich acmes Events hält, mit den richtigen Attributen, und nicht hinterherhinkt.

DynoTable verbindet sich mit jeder Region mit ihren eigenen Anmeldedaten, sodass du ein Fenster auf us-east-1 und ein anderes auf eu-west-1 richten und die Items desselben Tenants nebeneinander vergleichen kannst, um die Replikation zu verifizieren.

Du kannst die Abfragen pro Region, die du gegen jedes Replikat ausführen wirst, im DynamoDB Expression Builder prototypisieren.

Fallstricke und nächste Schritte

• Lies nicht regionsübergreifend deinen eigenen Schreibvorgang. Replikationsverzögerung bedeutet, dass ein Schreibvorgang in einer Region für ~eine Sekunde nicht in einer anderen erscheinen kann. Schreibe nicht in die USA und lies dann sofort aus der EU in der Erwartung, ihn zu sehen. Im Standard-MREC-Modus funktionieren stark konsistente Lesevorgänge nur innerhalb einer einzigen Region; MRSC dehnt starke Lesevorgänge regionsübergreifend aus.
• Last-Writer-Wins verwirft Daten stillschweigend. Für veränderliche Items, die gleichzeitig in zwei Regionen geschrieben werden, wird der Verlierer ohne Fehler verworfen. Append-only- oder Single-Writer-pro-Item-Designs (wie dieses Audit-Log) vermeiden das Problem; geteilter veränderlicher Zustand braucht ein konfliktbewusstes Design.
• Jedes Replikat kostet. Jede Region speichert eine vollständige Kopie und berechnet ihre eigene Kapazität und ihren eigenen Speicher — ein Replikat verdoppelt die Kosten grob. Füge Regionen für einen echten Residenz- oder DR-Bedarf hinzu, nicht standardmäßig.
• Backups sind pro Replikat. Eine wiederhergestellte Global Table wird eine unabhängige Tabelle — plane die Wiederherstellung pro Region. Siehe Backup & Point-in-Time Recovery.

Global Tables schützen davor, eine Region zu verlieren. Die letzte operative Sorge ist der Schutz davor, Daten zu verlieren — ein schlechtes Deploy oder ein versehentliches Löschen — mit Backup & Point-in-Time Recovery.

Lade DynoTable herunter, um dich mit mehreren Regionen zu verbinden und zu verifizieren, dass deine Global-Table-Replikate dieselben Daten halten.