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

Globale Tabellen bauen auf der globalen Reichweite von Amazon DynamoDB auf, um Ihnen eine vollständig verwaltete, multiregionale und multiaktive Datenbank zur Verfügung zu stellen, die schnelle lokale Lese- und Schreibleistung für massiv skalierte, globale Anwendungen bietet. Mit globalen Tabellen werden Ihre Daten automatisch in den Regionen Ihrer Wahl repliziert. AWS Da globale Tabellen vorhandene DynamoDB-APIs verwenden, sind keine Änderungen an Ihrer Anwendung erforderlich. Für die Verwendung von globalen Tabellen fallen keine Vorabkosten an und Sie müssen keine Verpflichtungen im Voraus eingehen. Sie zahlen nur für die tatsächlich genutzten Ressourcen.

Themen

• Anleitung für das Design von globalen DynamoDB-Tabellen
• Wichtige Fakten zum Design von globalen DynamoDB-Tabellen
• Anwendungsfälle
• Schreibmodi bei Verwendung von globalen Tabellen
• Weiterleitung von Anforderungen mit globalen Tabellen
• Evakuierung einer Region mit globalen Tabellen
• Planung der Durchsatzkapazität für globale Tabellen
• Checkliste zur Vorbereitung für globale Tabellen und häufig gestellte Fragen

Anleitung für das Design von globalen DynamoDB-Tabellen

Für eine effiziente Verwendung von globalen Tabellen müssen verschiedene Faktoren wie Ihr bevorzugter Schreibmodus, das Weiterleitungsmodell und Evakuierungsprozesse genau berücksichtigt werden. Sie müssen Ihre Anwendung in jeder Region instrumentieren und bereit sein, Ihre Weiterleitung anzupassen oder eine Evakuierung durchzuführen, um die globale Integrität zu erhalten. Dies zahlt sich aus, da Sie auf diese Weise einen global verteilten Datensatz mit niedrigen Latenzzeiten beim Lesen und Schreiben und ein Service Level Agreement von 99,999 % erhalten.

Wichtige Fakten zum Design von globalen DynamoDB-Tabellen

• Es gibt zwei Versionen globaler Tabellen: die aktuelle Version von Global Tables Version 2019.11.21 (Current) (manchmal auch „V2“ genannt) und Globale Tabellen Version 2017.11.29 (veraltet) (manchmal auch „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-Einzelregionstabelle gilt ein https://aws.amazon.com/dynamodb/sla/ Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,99 %.

• Durch die Verwendung globaler Tabellen macht es DynamoDB einer Tabelle möglich, ihre Daten zwischen zwei oder mehr Regionen zu replizieren. Für eine multiregionale DynamoDB-Tabelle gilt ein SLA mit einer Verfügbarkeit von 99,999 %. 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. Für diese Latenz gibt es kein SLA.

• 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 AWS CloudTrail aufgezeichnet.

• 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.

Anwendungsfälle

Globale Tabellen bieten folgende allgemeine Vorteile:

• 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 Weiterleitung von Anforderungen mit globalen Tabellen ausführlicher erörtert.

• Verbesserte Resilienz und Notfallwiederherstellung. Sie können eine Region evakuieren (einige oder alle an diese Region gerichtete Anforderungen verschieben), falls die Region Leistungseinbußen aufweist oder vollständig ausfällt, und das mit einem Recovery Point Objective (RPO) und einem Recovery Time Objective (RTO), die in Sekunden gemessen werden. Durch die Verwendung von globalen Tabellen erhöht sich das DynamoDB-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.