Schreibmodi bei Verwendung von globalen DynamoDB-Tabellen

Globale Tabellen sind auf Tabellenebene immer aktiv-aktiv. Vielleicht möchten Sie sie insbesondere bei MREC-Tabellen jedoch als aktiv-passiv behandeln, indem Sie steuern, wie Schreibanforderungen weitergeleitet werden. Sie könnten sich beispielsweise dafür entscheiden, Schreibanforderungen an eine einzelne Region weiterzuleiten, um mögliche Schreibkonflikte zu vermeiden, die bei MREC-Tabellen vorkommen können.

Es gibt drei Hauptmuster für verwaltete Schreibvorgänge, die in den nächsten drei Abschnitten erläutert werden. Sie sollten überlegen, welches Schreibmuster zu Ihrem Anwendungsfall passt. Diese Wahl wirkt sich auf die Weiterleitung von Anforderungen, die Evakuierung einer Region und die Notfallwiederherstellung aus. Die Anleitung in späteren Abschnitten hängt vom Schreibmodus Ihrer Anwendung ab.

Modus „Schreiben in eine beliebige Region“ (keine Primärregion)

Der Modus Schreiben in eine beliebige Region, der im folgenden Diagramm dargestellt wird, ist vollständig aktiv-aktiv. In diesem Modus bestehen keine Einschränkungen in Bezug darauf, wo ein Schreibvorgang stattfinden kann. Jede Region kann jederzeit Schreibvorgänge akzeptieren. Dies ist der einfachste Modus, der jedoch nur für einige Arten von Anwendungen verwendet werden kann. Dieser Modus ist für alle MRSC-Tabellen geeignet. Er eignet sich auch für MREC-Tabellen, wenn alle Writer idempotent und daher sicher wiederholbar sind, sodass gleichzeitige oder wiederholte Schreibvorgänge in verschiedenen Regionen nicht miteinander in Konflikt geraten. Er kann beispielsweise verwendet werden, wenn ein Benutzer seine Kontaktdaten aktualisiert. Dieser Modus eignet sich auch gut für einen Sonderfall der Idempotenz, einen Append-Only-Datensatz, bei dem alle Schreibvorgänge eindeutige Einfügungen unter einem deterministischen Primärschlüssel sind. Schließlich ist dieser Modus für MREC geeignet, wenn das Risiko von Schreibkonflikten akzeptabel wäre.

Der Modus Schreiben in eine beliebige Region ist die am einfachsten zu implementierende Architektur. Die Weiterleitung ist einfacher, da jede Region jederzeit Schreibziel sein kann. Ein Failover ist einfacher, da bei MRSC-Tabellen die Elemente immer synchronisiert werden. Außerdem können bei MRSC-Tabellen alle kürzlichen Schreibvorgänge beliebig oft in jeder sekundären Region wiederholt werden. Wenn möglich, sollten Sie diesen Schreibmodus vorsehen.

Mehrere Video-Streaming-Services verwenden beispielsweise häufig globale Tabellen, um Lesezeichen, Bewertungen, Ansehstatus-Flags usw. zu verfolgen. Diese Bereitstellungen nutzen MREC-Tabellen, da sie Replikate benötigen, die auf der ganzen Welt verstreut sind, wobei jedes Replikat Lese- und Schreibvorgänge mit niedriger Latenz ermöglicht. Für diese Bereitstellungen kann der Modus Schreiben in eine beliebige Region verwendet werden, solange sichergestellt wird, dass jeder Schreibvorgang idempotent ist. Dies ist der Fall, wenn bei jeder Aktualisierung – beispielsweise beim Festlegen eines neuen aktuellen Zeitcodes, beim Zuweisen einer neuen Überprüfung oder beim Einstellen eines neuen Ansehstatus – der neue Status des Benutzers direkt zugewiesen wird und der nächste korrekte Wert für ein Element nicht von seinem aktuellen Wert abhängt. Wenn die Schreibanforderungen des Benutzers zufälligerweise an verschiedene Regionen weitergeleitet werden, bleibt der letzte Schreibvorgang bestehen und der globale Status wird gemäß der letzten Zuweisung festgelegt. Lesevorgänge in diesem Modus werden letztendlich konsistent, verzögert um den letzten ReplicationLatency-Wert.

In einem anderen Beispiel verwendet ein Finanzdienstleistungsunternehmen globale Tabellen als Teil eines Systems, um eine laufende Aufstellung der Debitkartenkäufe für jeden Kunden zu führen und die Cashback-Prämien des Kunden zu berechnen. Das Unternehmen möchte ein RunningBalance-Element pro Kunde beibehalten. Dieser Schreibmodus ist naturgemäß nicht idempotent, da beim Eingehen von Transaktionen der Saldo mit einem ADD-Ausdruck geändert wird, bei dem der neue korrekte Wert vom aktuellen Wert abhängt. Durch die Verwendung von MRSC-Tabellen kann das Unternehmen in eine beliebige Region schreiben, da jeder ADD-Aufruf immer mit dem allerneuesten Wert des Elements ausgeführt wird.

Ein drittes Beispiel betrifft ein Unternehmen, das Online-Werbeplatzierungsdienste anbietet. Dieses Unternehmen hat entschieden, dass ein geringes Risiko eines Datenverlusts akzeptabel wäre, um die Designvereinfachungen des Modus Schreiben in eine beliebige Region zu erreichen. Wenn Anzeigen geschaltet werden, bleiben nur wenige Millisekunden Zeit, um genügend Metadaten abzurufen, zu bestimmen, welche Anzeige geschaltet werden soll, und dann die Ad Impression aufzuzeichnen, damit dem betreffenden Benutzer nicht mehrmals dieselbe Anzeige präsentiert wird. Mit globalen Tabellen kann das Unternehmen sowohl Lesevorgänge mit niedriger Latenz für Endbenutzer auf der ganzen Welt als auch Schreibvorgänge mit niedriger Latenz erzielen. Alle Ad Impressions für einen Benutzer können in einem einzelnen Element aufgezeichnet werden, das als wachsende Liste dargestellt wird. Das Unternehmen verwendet ein Element, anstatt Elemente an eine Elementauflistung anzuhängen, da auf diese Weise ältere Ad Impressions im Rahmen jedes Schreibvorgangs entfernt werden können, ohne Kosten für einen Löschvorgang zu verursachen. Dieser Schreibvorgang ist nicht idempotent. Wenn derselbe Endbenutzer Anzeigen aus mehreren Regionen ungefähr zur gleichen Zeit sieht, besteht die Möglichkeit, dass ein Schreibvorgang für eine Ad Impression den anderen überschreibt. Das Risiko besteht darin, dass ein Benutzer eine Anzeige gelegentlich wiederholt sieht. Das Unternehmen hat entschieden, dass dies akzeptabel ist.

Schreiben in eine Region (einzelne Primärregion)

Der Modus Schreiben in eine Region, der im folgenden Diagramm dargestellt wird, ist aktiv-passiv. Alle Schreibvorgänge in der Tabelle werden an eine einzelne aktive Region weitergeleitet. Beachten Sie, dass DynamoDB das Konzept einer einzelnen aktiven Region nicht kennt. Die Anwendungsweiterleitung außerhalb von DynamoDB verwaltet dies. Der Modus Schreiben in eine Region ist gut für MREC-Tabellen geeignet, bei denen Schreibkonflikte vermieden werden müssen, indem sichergestellt wird, dass Schreibvorgänge jeweils nur in eine Region gelangen. Dieser Schreibmodus ist hilfreich, wenn Sie bedingte Ausdrücke verwenden möchten und MRSC aus irgendeinem Grund nicht verwenden können, oder wenn Sie Transaktionen ausführen müssen. Diese Ausdrücke sind nur möglich, wenn Sie wissen, dass Sie mit den neuesten Daten arbeiten. Deshalb müssen alle Schreibanforderungen an eine einzelne Region gesendet werden, die über die neuesten Daten verfügt.

Wenn Sie eine MRSC-Tabelle verwenden, sollten Sie der Einfachheit halber vielleicht entscheiden, generell in eine Region schreiben. Das kann beispielsweise dazu beitragen, den Ausbau Ihrer Infrastruktur über DynamoDB hinaus zu minimieren. Der Schreibmodus wäre immer noch das Schreiben in eine beliebige Region, da Sie mit MRSC jederzeit sicher in jede Region schreiben könnten, ohne sich Gedanken über die Konfliktlösung machen zu müssen, die dazu führen würde, dass MREC-Tabellen in eine Region schreiben.

Letztendlich konsistente Lesevorgänge können an alle Replikatregionen geleitet werden, um geringere Latenzen zu erreichen. Strikt konsistente Lesevorgänge müssen an die einzelne Primärregion geleitet werden.

Manchmal ist es infolge eines Regionsausfalls notwendig, die aktive Region zu ändern. Manche Benutzer ändern die gerade aktive Region regelmäßig, z. B. durch Implementierung einer „Follow-the-Sun“-Bereitstellung. Dadurch wird die aktive Region in der Nähe der Region mit der höchsten Aktivität platziert (normalerweise dort, wo es Tag ist, daher der Name), was zu Lese- und Schreibvorgängen mit der niedrigsten Latenz führt. Ein Nebeneffekt dabei ist, dass der Code zum Ändern der Region täglich aufgerufen wird und damit vor einer Notfallwiederherstellung gründlich getestet wurde.

Die passive(n) Region(en) kann/können eine verkleinerte Infrastruktur rund um DynamoDB beibehalten, die nur dann aufgebaut wird, wenn sie zur aktiven Region wird. In diesem Handbuch werden die Designs Pilot Light und Warm Standby nicht behandelt. Weitere Informationen dazu finden Sie unter Architektur für die Notfallwiederherstellung in AWS, Teil III: Pilot Light und Warm Standby.

Der Modus Schreiben in eine Region ist gut geeignet, wenn Sie globale Tabellen für global verteilte Lesevorgänge mit niedriger Latenz verwenden. Ein Beispiel ist ein großes Social-Media-Unternehmen, das in allen Regionen der Welt dieselben Referenzdaten zur Verfügung haben muss. Das Unternehmen aktualisiert die Daten nicht oft, aber wenn eine Aktualisierung durchgeführt wird, werden die Daten nur in eine Region geschrieben, um mögliche Schreibkonflikte zu vermeiden. Lesevorgänge sind immer von jeder Region aus zulässig.

Ein weiteres Beispiel ist das schon erwähnte Finanzdienstleistungsunternehmen, das die tägliche Cashback-Berechnung eingeführt hat. Das Unternehmen nutzte den Modus Schreiben in eine beliebige Region, um den Saldo zu berechnen, aber den Modus Schreiben in eine Region, um Zahlungen zu verfolgen. Diese Arbeit erfordert Transaktionen, die in MRSC-Tabellen nicht unterstützt werden. Daher funktioniert dieser Prozess besser mit einer separaten MREC-Tabelle und dem Modus Schreiben in eine Region.

Schreiben in Ihre Region (gemischte Primärregion)

Der Schreibmodus Schreiben in Ihre Region, der im folgenden Diagramm dargestellt ist, kann mit MREC-Tabellen verwendet werden. Er weist verschiedenen Heimatregionen unterschiedliche Datenteilmengen zu und ermöglicht Schreibvorgänge für ein Element nur über dessen Heimatregion. Dieser Modus ist aktiv-passiv, weist jedoch die aktive Region basierend auf dem Element zu. Jede Region ist Primärregion für ihren eigenen, sich nicht überlappenden Datensatz und Schreibvorgänge müssen überwacht werden, um eine korrekte Lokalisierung sicherzustellen.

Dieser Modus ist ähnlich wie der Modus Schreiben in eine Region, mit der Ausnahme, dass Schreibvorgänge mit geringerer Latenz möglich sind, da die jedem Endbenutzer zugeordneten Daten in größerer Netzwerknähe zu diesem Benutzer platziert werden können. Auch ist die umliegende Infrastruktur gleichmäßiger auf die Regionen verteilt und der Aufbau der Infrastruktur während eines Failover-Szenarios ist weniger aufwendig, da in allen Regionen ein Teil der Infrastruktur bereits aktiv ist.

Sie können die Heimatregion für Elemente auf verschiedene Arten bestimmen:

Stellen Sie sich beispielsweise vor, Sie arbeiten für ein Gaming-Unternehmen. Sie benötigen eine niedrige Latenz bei Lese- und Schreibvorgängen für alle Spieler weltweit. Sie weisen jeden Spieler der ihm am nächsten gelegenen Region zu. Diese Region übernimmt all Lese- und Schreibvorgänge, um eine strikte Lesen-nach-Schreiben-Konsistenz zu gewährleisten. Wenn ein Spieler jedoch verreist oder es in seiner Heimatregion zu einem Ausfall kommt, steht eine vollständige Kopie seiner Daten in anderen Regionen zur Verfügung und der Spieler kann einer anderen Heimatregion zugewiesen werden.

Stellen Sie sich als weiteres Beispiel vor, Sie arbeiten in einem Videokonferenzunternehmen. Die Metadaten jeder Konferenz werden einer bestimmten Region zugewiesen. Anrufer können die ihnen am nächsten gelegene Region verwenden, um eine möglichst niedrige Latenz zu erzielen. Wenn eine Region ausfällt, ermöglicht die Verwendung globaler Tabellen eine schnelle Wiederherstellung, da das System die Verarbeitung des Anrufs an eine andere Region weitergeben kann, in der sich bereits eine replizierte Kopie der Daten befindet.