Bewährte Methoden für das Design von globalen DynamoDB-Tabellen

Es gibt zwei Versionen globaler Tabellen: die aktuelle Version Global Tables Version 2019.11.21 (Current) (manchmal auch „V2“ genannt) und Globale Tabellen Version 2017.11.29 (Legacy) (manchmal „V1" genannt). In diesem Leitfaden geht es ausschließlich um die aktuelle Version V2.

Ohne die Verwendung globaler Tabellen ist DynamoDB ein regionaler Service. Der Service ist hochgradig verfügbar und widerstandsfähig gegenüber Infrastrukturausfällen in einer Region, einschließlich des Ausfalls einer gesamten Availability Zone (AZ). Für eine DynamoDB-Tabelle mit einer einzigen Region gilt ein https://aws.amazon.com/dynamodb/sla/ Service Level Agreement () mit einer Verfügbarkeit von 99,99%. SLA

Durch die Verwendung globaler Tabellen macht es DynamoDB einer Tabelle möglich, ihre Daten zwischen zwei oder mehr Regionen zu replizieren. Eine DynamoDB-Tabelle mit mehreren Regionen hat eine Verfügbarkeit von 99,999% SLA Bei richtiger Planung kann mithilfe von globalen Tabellen eine widerstandsfähige Architektur geschaffen werden, die regionalen Ausfällen standhält.

Globale Tabellen verwenden ein Aktiv-Aktiv-Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Nach Erhalt einer Schreibanforderung repliziert die lokale Replikattabelle den Schreibvorgang im Hintergrund in andere teilnehmende Regionen.

Elemente werden einzeln repliziert. Elemente, die im Rahmen einer einzelnen Transaktion aktualisiert wurden, können möglicherweise nicht zusammen repliziert werden.

Jede Tabellenpartition in der Quellregion repliziert ihre Schreibvorgänge parallel zu allen anderen Partitionen. Die Reihenfolge der Schreibvorgänge innerhalb der Remote-Region entspricht möglicherweise nicht der Reihenfolge der Schreibvorgänge in der Quellregion. Weitere Informationen zu Tabellenpartitionen finden Sie im Blogbeitrag Skalierung von DynamoDB: Wie sich Partitionen, Hotkeys und Split for Heat auf die Leistung auswirken.

Ein neu geschriebenes Element wird in der Regel innerhalb einer Sekunde auf alle Replikattabellen verteilt. Die Verteilung in nahegelegene Regionen erfolgt tendenziell schneller.

Amazon CloudWatch stellt für jedes Regionspaar eine ReplicationLatency Metrik bereit. Zur Berechnung dieser Metrik wird die Ankunftszeit eingehender Elemente mit der Zeit, zu der sie ursprünglich geschrieben wurden, verglichen und ein Durchschnitt ermittelt. Die Zeitangaben werden innerhalb CloudWatch der Quellregion gespeichert. Der Vergleich der durchschnittlichen und maximalen Zeiten kann helfen, die durchschnittliche und die stärkste Replikationsverzögerung zu ermitteln. Bei dieser Latenz gibt es keineSLA.

Wenn dasselbe Element ungefähr zu derselben Zeit (innerhalb dieses ReplicationLatency-Fensters) in zwei verschiedenen Regionen aktualisiert wird und der zweite Schreibvorgang vor der Replikation des ersten Schreibvorgangs stattfindet, kann es zu Schreibkonflikten kommen. Globale Tabellen lösen solche Konflikte nach dem Prinzip Wer zuletzt schreibt, gewinnt, basierend auf dem Zeitstempel der Schreibvorgänge. Der erste Schreibvorgang „verliert“ gegenüber dem zweiten Schreibvorgang. Diese Konflikte werden nicht in CloudWatch oder aufgezeichnet AWS CloudTrail.

Jedes Element verfügt über einen Zeitstempel für den letzten Schreibvorgang, der als private Systemeigenschaft gespeichert wird. Zur Umsetzung des Prinzips Wer zuletzt schreibt, gewinnt wird ein bedingter Schreibvorgang verwendet, der voraussetzt, dass der Zeitstempel des eingehenden Elements größer als der Zeitstempel des vorhandenen Elements ist.

In einer globalen Tabelle werden alle Elemente in alle teilnehmenden Regionen repliziert. Wenn Sie unterschiedliche Replikationsbereiche haben möchten, können Sie verschiedene Tabellen erstellen und jeder Tabelle verschiedene teilnehmende Regionen zuweisen.

Schreibvorgänge in die lokale Region werden auch dann akzeptiert, wenn die Replikatregion offline ist oder die ReplicationLatency wächst. Die lokale Tabelle versucht weiterhin, Elemente in die Remote-Tabelle zu replizieren, bis dies für jedes Element erfolgreich ist.

Sollte eine Region vollständig offline gehen, was sehr unwahrscheinlich ist, werden alle ausstehenden ausgehenden und eingehenden Replikationen erneut versucht, wenn sie später wieder online ist. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren. Das Prinzip Wer zuletzt schreibt, gewinnt, stellt sicher, dass die Daten letztendlich konsistent werden.

Sie können einer DynamoDB-Tabelle jederzeit eine neue Region hinzufügen. DynamoDB kümmert sich um die erste Synchronisierung und die fortlaufende Replikation. Wenn eine Region entfernt wird, wird nur die Tabelle für diese Region gelöscht. Dies gilt auch, wenn es sich bei der betreffenden Region um die ursprüngliche Region handelt.

In DynamoDB gibt es keinen globalen Endpunkt. Alle Anforderungen werden an einen regionalen Endpunkt gestellt, der dann auf die für diese Region lokale Instance der globalen Tabelle zugreift.

Aufrufe an DynamoDB sollten nicht regionsübergreifend erfolgen. Am besten ist es, wenn die Datenverarbeitungsebene in einer Region nur auf den lokalen DynamoDB-Endpunkt für diese Region direkt zugreift. Wenn Probleme innerhalb einer Region erkannt werden, unabhängig davon, ob diese Probleme in der DynamoDB-Schicht oder im umgebenden Stack auftreten, sollte der Endbenutzerdatenverkehr an eine andere Rechenschicht weitergeleitet werden, die in einer anderen Region gehostet wird. Dank der Replikation der globalen Tabelle verfügt die andere Region bereits über eine lokale Kopie derselben Daten, mit der sie lokal arbeiten kann. Unter bestimmten Umständen kann die Datenverarbeitungsebene in einer Region die Anforderung zur Verarbeitung an die Datenverarbeitungsebene einer anderen Region weiterleiten, diese sollte jedoch nicht direkt auf den DynamoDB-Remote-Endpunkt zugreifen. Weitere Informationen zu diesem besonderen Anwendungsfall finden Sie unter Weiterleitung von Anforderungen auf Datenverarbeitungsebene.

Lesevorgänge mit geringerer Latenz. Sie können eine Kopie der Daten näher am Endbenutzer platzieren, um die Netzwerklatenz beim Lesen zu reduzieren. Der Cache wird so aktuell gehalten wie der ReplicationLatency-Wert.

Schreibvorgänge mit geringerer Latenz. Sie können in eine nahegelegene Region schreiben, um die Netzwerklatenz und die für den Schreibvorgang benötigte Zeit zu reduzieren. Der Schreibverkehr muss sorgfältig weitergeleitet werden, um Konflikte zu vermeiden. Die Methoden für die Weiterleitung werden unter Anforderungsweiterleitung mit globalen DynamoDB-Tabellen ausführlicher erörtert.

Verbesserte Resilienz und Notfallwiederherstellung. Sie können eine Region evakuieren (einige oder alle Anfragen, die an diese Region gerichtet sind, wegverschieben), falls in der Region Leistungseinbußen oder ein vollständiger Ausfall auftritt. Dabei werden Recovery Point Objective (RPO) und Recovery Time Objective () in Sekunden gemessen. RTO Durch die Verwendung globaler Tabellen steigt auch der DynamoDB-Wert SLA von 99,99% auf 99,999%.

Nahtlose Migration von Regionen. Sie können eine neue Region hinzufügen und dann die alte Region löschen, um eine Bereitstellung von einer Region in eine andere zu migrieren, und das alles ohne Ausfallzeiten auf Datenebene. So können Sie beispielsweise globale DynamoDB-Tabellen für ein Auftragsverwaltungssystem verwenden, um in hohem Maße eine zuverlässige Verarbeitung mit niedriger Latenz zu erreichen und gleichzeitig die Widerstandsfähigkeit gegenüber AZ- und Regionsausfällen aufrechtzuerhalten.