Checkliste zur Vorbereitung für globale DynamoDB-Tabellen

Ermitteln Sie, ob Ihr Anwendungsfall mehr von einem MRSC- oder einem MREC-Konsistenzmodus profitiert. Benötigen Sie starke Konsistenz, auch wenn die Latenz ist und andere Kompromisse bestehen?

Festlegung, wie viele und welche Regionen an der globalen Tabelle teilnehmen sollen. Wenn Sie MRSC verwenden möchten, entscheiden Sie, ob die dritte Region ein Replikat oder ein Witness sein soll.

Ermittlung des Schreibmodus Ihrer Anwendung. Dies ist nicht dasselbe wie der Konsistenzmodus. Weitere Informationen finden Sie unter Schreibmodi bei Verwendung von globalen DynamoDB-Tabellen.

Planung Ihrer Strategie für Routing-Strategien in DynamoDB auf der Grundlage Ihres Schreibmodus.

Definieren Sie Ihre Evakuierungsprozesse basierend auf Ihrem Konsistenzmodus, Ihrem Schreibmodus und Ihrer Routing-Strategie.

Erfassung von Metriken zum Zustand, zur Latenz und zu Fehlern in jeder Region. Eine Liste der zu beachtenden DynamoDB-Metriken finden Sie im AWS-Blogbeitrag Überwachen von Amazon DynamoDB, um operative Einblicke zu gewinnen. Sie sollten auch synthetische Canarys (künstliche Anforderungen, um Ausfälle zu erkennen, benannt nach dem Kanarienvogel in Kohlebergwerken) verwenden und eine Live-Beobachtung des Kundendatenverkehrs nutzen. Nicht alle Probleme werden in den DynamoDB-Metriken erkennbar sein.

Wenn Sie MREC verwenden, legen Sie die Alarme für jeden anhaltenden Anstieg bei ReplicationLatency ein. Ein Anstieg könnte auf eine versehentliche Fehlkonfiguration hinweisen, bei der die globale Tabelle in verschiedenen Regionen unterschiedliche Schreibeinstellungen aufweist, wodurch es zu fehlgeschlagenen replizierten Anforderungen und höheren Latenzen kommt. Auch auf eine regionale Störung könnte ein solcher Anstieg hindeuten. Ein gutes Beispiel ist die Generierung einer Warnung, wenn der aktuelle Durchschnitt 180 000 Millisekunden überschreitet. Sie können auch darauf achten, ob der Wert für ReplicationLatency auf 0 fällt, was auf eine verzögerte Replikation hindeutet.

Zuweisung ausreichend hoher Einstellungen für die maximale Lese- und Schreibkapazität für jede globale Tabelle.

Ermittlung der Gründe für die Evakuierung einer Region im Voraus. Wenn die Entscheidung menschliches Urteilsvermögen erfordert, sollten alle Überlegungen dokumentiert werden. Diese Arbeit sollte bereits im Voraus sorgfältig und nicht unter Stress durchgeführt werden.

Unterhaltung eines Runbooks für jede Aktion, die bei der Evakuierung einer Region stattfinden muss. Normalerweise ist der Aufwand für die globalen Tabellen sehr gering, doch das Verschieben des restlichen Stacks kann komplex sein.

Weitere Informationen finden Sie im AWS-Blogbeitrag Entwicklung widerstandsfähiger Anwendungen mit globalen Amazon-DynamoDB-Tabellen: Teil 4.

Regelmäßiger Test aller Aspekte des Runbooks, einschließlich Evakuierungen von Regionen. Ein nicht getestetes Runbook ist ein unzuverlässiges Runbook.

Ziehen Sie die Nutzung von AWS Resilience Hub in Betracht, um die Resilienz Ihrer gesamten Anwendung (einschließlich globaler Tabellen) zu bewerten. Das Hub bietet in seinem Dashboard einen umfassenden Überblick über die Widerstandsfähigkeit Ihres gesamten Anwendungsportfolios.

Ziehen Sie die Nutzung von ARC-Bereitschaftsprüfungen in Betracht, um die aktuelle Konfiguration Ihrer Anwendung zu bewerten und Abweichungen von den bewährten Methoden zu verfolgen.

Führen Sie beim Schreiben von Zustandsprüfungen für die Verwendung mit Route 53 oder Global Accelerator eine Reihe von Aufrufen aus, die den vollständigen Datenbankfluss abdecken. Wenn Sie Ihre Überprüfung darauf beschränken, nur zu bestätigen, dass der DynamoDB-Endpunkt aktiv ist, können Sie viele Fehlermodi nicht abdecken, z. B. AWS Identity and Access Management (IAM-) Konfigurationsfehler, Probleme bei der Codebereitstellung, Fehler im Stack außerhalb von DynamoDB, überdurchschnittlich hohe Latenzen bei Lese- oder Schreibvorgängen usw.

Ein Schreibvorgang in einer herkömmlichen DynamoDB-Tabelle wird in Schreibkapazitätseinheiten (WCUs) für bereitgestellte Tabellen oder Schreibanforderungseinheiten (WRUs) für On-Demand-Tabellen abgerechnet. Beim Schreiben eines 5-KB-Elements fällt eine Gebühr von 5 Einheiten an. Ein Schreibvorgang in eine globale Tabelle wird in replizierten Schreibkapazitätseinheiten (rWCUs) für bereitgestellte Tabellen oder in replizierten Schreibanforderungseinheiten (rWRUs) für On-Demand-Tabellen abgerechnet. rWCUs und rWRUs werden genauso abgerechnet wie WGUs und WRUs.

rWCU- und rWRU-Gebühren fallen in jeder Region an, in der das Element direkt oder durch Replikation geschrieben wird. Es fallen Gebühren für regionsübergreifende Datenübertragungen an.

Wenn in einen globalen sekundären Index (GSI) geschrieben wird, gilt dies als lokaler Schreibvorgang und es werden reguläre Schreibeinheiten verwendet.

Derzeit ist keine reservierte Kapazität für rWCUs oder rWRUs verfügbar. Der Kauf von reservierter Kapazität für WCUs kann für Tabellen, bei denen GSIs Schreibeinheiten verbrauchen, von Vorteil sein.

Wenn Sie einer globalen Tabelle eine neue Region hinzufügen, bootstrapt DynamoDB die neue Region automatisch und stellt sie Ihnen in Rechnung, als ob es sich um eine Tabellenwiederherstellung handeln würde, basierend auf der GB-Größe der Tabelle. Es fallen auch Gebühren für regionsübergreifende Datenübertragungen an.

Region-Set USA: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon)

Region-Set Europa: Europa (Frankfurt), Europa (Irland), Europa (London), Europa (Paris)

Region-Set Asien-Pazifik: Asien-Pazifik (Tokio), Asien-Pazifik (Seoul) und Asien-Pazifik (Osaka).

Sie können eine Replikattabelle genauso löschen, wie Sie jede andere Tabelle löschen würden. Wenn Sie die globale Tabelle löschen, wird die Replikation in die betreffende Region beendet und die in dieser Region gespeicherte Tabellenkopie wird gelöscht. Sie können die Replikation jedoch nicht stoppen, solange Sie Kopien der Tabelle als unabhängige Entitäten behalten, und Sie können die Replikation auch nicht unterbrechen.

Eine MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Um die Replikate zu löschen, müssen Sie alle Replikate und den Witness löschen, sodass die MRSC-Tabelle zu einer lokalen Tabelle wird.

Jede globale Tabelle erzeugt einen unabhängigen Stream, der auf allen ihren Schreibvorgängen basiert, unabhängig davon, wo diese gestartet wurden. Sie können wählen, ob Sie den DynamoDB-Stream in einer Region oder in allen Regionen (unabhängig voneinander) nutzen möchten. Wenn Sie lokale Schreibvorgänge, aber keine replizierten Schreibvorgänge verarbeiten möchten, können Sie jedem Element Ihr eigenes Regionsattribut hinzufügen, um die schreibende Region zu identifizieren. Sie können dann einen Lambda-Ereignisfilter verwenden, um die Lambda-Funktion nur für Schreibvorgänge in der lokalen Region aufzurufen. Dies ist bei Einfügungen und Aktualisierungen hilfreich, aber nicht bei Löschvorgängen.

Globale Tabellen, die für Multi-Region Eventual Consistency (MREC-Tabellen) konfiguriert sind, replizieren Änderungen, indem sie diese aus einem DynamoDB-Stream in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. DynamoDB ist daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und kann in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren. Daher kann der Stream jedes Replikats leicht unterschiedliche Datensätze enthalten. DynamoDB-Streams-Datensätze in MREC-Replikaten werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann.

Globale Tabellen, die für Multi-Region Strong Consistency (MRSC-Tabellen) konfiguriert sind, verwenden keine DynamoDB Streams für die Replikation, sodass diese Funktion in MRSC-Replikaten standardmäßig nicht aktiviert ist. DynamoDB Streams können in einem MRSC-Replikat aktiviert werden. DynamoDB-Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch und werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann.

Transaktionale Operationen in MRSC-Tabellen führen zu Fehlern.

Transaktionale Operationen in MREC-Tabellen bieten ACID-Garantien (Atomizität, Konsistenz, Isolierung und Zuverlässigkeit) nur in der Region, in der der Schreibvorgang ursprünglich durchgeführt wurde. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt. Wenn Sie beispielsweise eine globale MREC-Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) nutzen und eine TransactWriteItems-Operation in der Region USA Ost (Ohio) durchführen, sind unter Umständen partiell durchgeführte Transaktionen in der Region USA West (Oregon) zu beobachten, während die Änderungen repliziert werden. Die Änderungen werden erst dann in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.

Wenn Sie die Beständigkeit Ihrer Daten sicherstellen möchten, bietet DynamoDB diesen Schutz bereits. Der Service gewährleistet Datenbeständigkeit.

Wenn Sie einen Snapshot für historische Aufzeichnungen aufbewahren möchten (beispielsweise um regulatorische Anforderungen zu erfüllen), sollte eine Sicherung in einer Region ausreichen. Sie können die Sicherung mithilfe von AWS Backup in weitere Regionen kopieren.

Wenn Sie irrtümlich gelöschte oder geänderte Daten wiederherstellen möchten, verwenden Sie die zeitpunktbezogene Wiederherstellung (PITR) von DynamoDB in einer Region.

CloudFormation stellt eine DynamoDB-Tabelle und eine globale Tabelle als zwei separate Ressourcen dar: AWS::DynamoDB::Table und AWS::DynamoDB::GlobalTable. Ein Ansatz besteht darin, alle Tabellen, die potenziell global sein können, mithilfe des GlobalTable-Konstrukts zu erstellen, um sie zunächst als eigenständige Tabellen beizubehalten und später, falls erforderlich, Regionen hinzuzufügen.

In CloudFormation wird jede globale Tabelle von einem einzelnen Stack in einer einzelnen Region gesteuert, unabhängig von der Anzahl der Replikate. Wenn Sie Ihre Vorlage bereitstellen, erstellt und aktualisiert CloudFormation alle Replikate als Teil eines Single-Stack-Vorgangs. Sie sollten die gleiche AWS::DynamoDB::GlobalTable-Ressource nicht in mehreren Regionen bereitstellen. Dies führt zu Fehlern und wird nicht unterstützt. Wenn Sie Ihre Anwendungsvorlage in mehreren Regionen bereitstellen, können Sie Bedingungen verwenden, um die AWS::DynamoDB::GlobalTable-Ressource in einer einzigen Region zu erstellen. Alternativ können Sie Ihre AWS::DynamoDB::GlobalTable-Ressourcen in einem von Ihrem Anwendungs-Stack getrennten Stack definieren und sicherstellen, dass er in einer einzigen Region bereitgestellt wird.

Wenn Sie eine reguläre Tabelle in eine globale Tabelle konvertieren möchten, während sie weiterhin von CloudFormation verwaltet wird, gehen Sie wie folgt vor: Setzen Sie die Löschrichtlinie auf Retain, entfernen Sie die Tabelle aus dem Stack, konvertieren Sie die Tabelle in der Konsole in eine globale Tabelle und importieren Sie dann die globale Tabelle als neue Ressource in den Stack. Weitere Informationen finden Sie im AWS-GitHub-Repository.

Die kontoübergreifende Replikation wird zu diesem Zeitpunkt nicht unterstützt.