Routing-Strategien in DynamoDB

Der vielleicht komplexeste Teil der Bereitstellung einer globalen Tabelle ist die Verwaltung der Weiterleitung von Anforderungen. Anforderungen müssen zunächst von einem Endbenutzer an eine Region gesendet werden, die auf irgendeine Weise ausgewählt und weitergeleitet wird. Die Anforderung trifft auf einen Service-Stack in dieser Region, einschließlich einer Datenverarbeitungsebene, die vielleicht einen Load Balancer, der von einer AWS Lambda-Funktion, einem Container oder einem Amazon Elastic Compute Cloud (Amazon EC2)-Knoten unterstützt wird, und möglicherweise andere Services, einschließlich einer weiteren Datenbank, umfasst. Diese Datenverarbeitungsebene kommuniziert mit DynamoDB. Dazu sollte sie den lokalen Endpunkt für diese Region verwenden. Die Daten in der globalen Tabelle werden in alle anderen teilnehmenden Regionen repliziert und jede Region verfügt über einen ähnlichen Service-Stack rund um ihre DynamoDB-Tabelle.

Die globale Tabelle stellt jedem Stack in den verschiedenen Regionen eine lokale Kopie derselben Daten zur Verfügung. Sie könnten einen einzelnen Stack in einer einzelnen Region vorsehen und im Falle eines Problems mit der lokalen DynamoDB-Tabelle Remote-Aufrufe an den DynamoDB-Endpunkt einer sekundären Region einplanen. Dies stellt keine bewährte Methode dar. Wenn in einer Region ein Problem auftritt, das durch DynamoDB verursacht wird (oder, was wahrscheinlicher ist, durch etwas anderes im Stack oder durch einen anderen Service, der von DynamoDB abhängt), ist es am besten, den Endbenutzer zur Verarbeitung in eine andere Region weiterzuleiten und die Datenverarbeitungsebene dieser anderen Region zu verwenden, die mit ihrem lokalen DynamoDB-Endpunkt kommuniziert. Bei diesem Ansatz wird die problematische Region vollständig umgangen. Um Resilienz zu gewährleisten, benötigen Sie eine Replikation über mehrere Regionen hinweg, wobei sowohl die Datenverarbeitungsebene als auch die Datenebene repliziert werden.

Es gibt zahlreiche alternative Möglichkeiten, die Anforderung eines Endbenutzers zur Verarbeitung an eine Region weiterzuleiten. Die optimale Option ist von Ihrem Schreibmodus und Ihrer Failover-Strategie abhängig. In diesem Abschnitt werden vier Optionen erörtert: Client-gesteuert, Datenverarbeitungsebene, Route 53 und Global Accelerator.

Client-gesteuerte Weiterleitung von Anforderungen

Bei der Client-gesteuerten Weiterleitung von Anforderungen, die im folgenden Diagramm dargestellt ist, verfolgt der Endbenutzer-Client (eine Anwendung, eine Webseite mit JavaScript oder ein anderer Client) die gültigen Anwendungsendpunkte (z. B. ein Endpunkt von Amazon API Gateway statt eines tatsächlichen DynamoDB-Endpunkts) und verwendet seine eigene eingebettete Logik, um die Region auszuwählen, mit der kommuniziert werden soll. Die Entscheidung kann auf der Grundlage einer zufälligen Auswahl, der niedrigsten beobachteten Latenzen, der höchsten beobachteten Bandbreitenmessung oder lokal durchgeführter Zustandsprüfungen getroffen werden.

Ein Vorteil ist, dass sich die Client-gesteuerte Weiterleitung von Anforderungen beispielsweise an die realen Bedingungen des öffentlichen Internetdatenverkehrs anpassen und die Region wechseln kann, falls Leistungseinbußen festgestellt werden. Der Client muss alle potenziellen Endpunkte kennen, doch es kommt nicht oft vor, dass ein neuer regionaler Endpunkt gestartet wird.

Beim Modus Schreiben in eine beliebige Region kann ein Client einseitig seinen bevorzugten Endpunkt auswählen. Wenn der Zugriff auf eine Region beeinträchtigt ist, kann der Client zu einem anderen Endpunkt weiterleiten.

Im Modus Schreiben in eine Region benötigt der Client einen Mechanismus, um seine Schreibvorgänge an die aktuell aktive Region weiterzuleiten. Hierfür könnte es ausreichen, empirisch zu testen, welche Region gerade Schreibvorgänge akzeptiert (wobei jede Ablehnung von Schreibvorgängen vermerkt und auf eine Alternative zurückgegriffen wird), oder es muss ein globaler Koordinator aufgerufen werden, um den aktuellen Anwendungsstatus abzufragen (vielleicht auf der Grundlage der Routing-Steuerung von Amazon Application Recovery Controller (ARC), die ein Quorum-gesteuertes System mit 5 Regionen zur Aufrechterhaltung des globalen Zustands für derartige Anforderungen bereitstellt). Der Client kann entscheiden, ob Lesevorgänge für letztendliche Konsistenz in eine beliebige Region weitergeleitet werden können oder ob sie an die aktive Region weitergeleitet werden müssen, um eine starke Konsistenz zu erzielen. Weitere Informationen finden Sie unter Funktionsweise von Route 53.

Im Modus Schreiben in Ihre Region muss der Client die Heimatregion für den Datensatz ermitteln, mit dem er arbeitet. Wenn der Client beispielsweise einem Benutzerkonto entspricht und jedes Benutzerkonto einer Region zugeordnet ist, kann der Client den entsprechenden Endpunkt von einem globalen Anmeldesystem anfordern.

Ein Finanzdienstleistungsunternehmen beispielsweise, das Benutzer bei der Verwaltung ihrer Geschäftsfinanzen über das Internet unterstützt, könnte globale Tabellen mit dem Modus Schreiben in Ihre Region verwenden. Jeder Benutzer muss sich bei einem zentralen Service anmelden. Dieser Service gibt Anmeldeinformationen sowie den Endpunkt für die Region zurück, für den diese Anmeldeinformationen gelten. Die Anmeldeinformationen sind nur kurze Zeit gültig. Danach handelt die Webseite automatisch eine neue Anmeldung aus, was die Gelegenheit bietet, die Aktivitäten des Benutzers möglicherweise in eine neue Region umzuleiten.

Weiterleitung von Anforderungen auf Datenverarbeitungsebene

Bei der Weiterleitung von Anforderungen auf Datenverarbeitungsebene, die im folgenden Diagramm dargestellt ist, entscheidet der auf Datenverarbeitungsebene ausgeführte Code, ob er die Anforderung lokal verarbeiten oder an eine Kopie des Codes weitergeben möchte, die in einer anderen Region ausgeführt wird. Wenn Sie den Modus Schreiben in eine Region verwenden, erkennt die Datenverarbeitungsebene möglicherweise, dass es sich nicht um die aktive Region handelt, und erlaubt lokale Lesevorgänge, während alle Schreibvorgänge an eine andere Region weitergeleitet werden. Dieser Code auf Datenverarbeitungsebene muss die Datentopologie und die Regeln für die Weiterleitung kennen und unter Berücksichtigung der aktuellen Einstellungen, die angeben, welche Regionen für welche Daten aktiv sind, zuverlässig durchsetzen. Der äußere Software-Stack innerhalb der Region muss nicht wissen, wie Lese- und Schreibanforderungen von dem Microservice weitergeleitet werden. In einem robusten Design überprüft die empfangende Region, ob sie die aktuelle Primärregion für den Schreibvorgang ist. Ist dies nicht der Fall, wird ein Fehler mit dem Hinweis generiert, dass der globale Zustand korrigiert werden muss. Die empfangende Region könnte den Schreibvorgang auch eine Weile zwischenspeichern, wenn sich die Primärregion gerade ändert. In allen Fällen schreibt der Computing-Stack in einer Region nur auf seinen lokalen DynamoDB-Endpunkt, die Computing-Stacks kommunizieren aber möglicherweise miteinander.

Die Vanguard Group verwendet für diesen Routing-Prozess ein System namens Global Orchestration and Status Tool (GOaST) und eine Bibliothek namens Global Multi-Region library (GMRlib), wie auf der re:Invent 2022 vorgestellt. Das Unternehmen nutzt ein einzelnes Follow-the-Sun-Primärmodell. GOaST behält den globalen Zustand bei, ähnlich wie bei der ARC-Routing-Steuerung, die im vorherigen Abschnitt beschrieben wurde. Unter Verwendung einer globalen Tabelle verfolgt das Unternehmen, welche Region die Primärregion ist und wann der nächste Wechsel der Primärregion geplant ist. Alle Lese- und Schreibvorgänge durchlaufen die GMRlib, die mit GOaST koordiniert wird. GMRlib ermöglicht die lokale Ausführung von Leseoperationen mit geringer Latenz. Bei Schreibvorgängen prüft GMRlib, ob die lokale Region die aktuelle Primärregion ist. Falls ja, wird der Schreibvorgang direkt abgeschlossen. Falls nicht, leitet GMRlib die Schreibaufgabe an die GMRlib in der primären Region weiter. Diese empfangende Bibliothek bestätigt, dass sie sich ebenfalls als Primärregion betrachtet, und gibt einen Fehler aus, wenn dies nicht der Fall ist, was auf eine Verzögerung bei der Weitergabe des globalen Zustands hindeutet. Dieses Vorgehen bietet einen Validierungsvorteil, da nicht direkt auf einen DynamoDB-Remote-Endpunkt geschrieben wird.

Route-53-Weiterleitung von Anforderungen

Amazon Application Recovery Controller (ARC) ist eine Domain Name Service (DNS)-Technologie. Bei Route 53 fordert der Client seinen Endpunkt an, indem er nach einem bekannten DNS-Domainnamen sucht, und Route 53 gibt die IP-Adresse des regionalen Endpunkts/der regionalen Endpunkte zurück, den/die es für am geeignetsten hält. Dies wird im folgenden Diagramm veranschaulicht. Route 53 verfügt über eine lange Liste von Weiterleitungsrichtlinien, anhand derer die geeignete Region bestimmt wird. Route 53 kann auch ein Failover-Routing durchführen, um Datenverkehr von Regionen wegzuleiten, die die Zustandsprüfung nicht bestehen.

Mit dem Modus Schreiben in eine beliebige Region oder in Kombination mit der Weiterleitung von Anforderungen auf Datenverarbeitungsebene am Back-End kann Route 53 vollständigen Zugriff erhalten, um die Region auf der Grundlage komplexer interner Regeln zurückzugeben, beispielsweise die Region in nächster Netzwerknähe oder in nächster geografischer Nähe oder eine andere Wahl.

Im Modus Schreiben in eine Region können Sie Route 53 so konfigurieren, dass es die derzeit aktive Region zurückgibt (mithilfe von Route 53 ARC). Wenn der Client eine Verbindung mit einer passiven Region herstellen möchte (z. B. für Lesevorgänge), kann er nach einem anderen DNS-Namen suchen.

Im Modus Schreiben in Ihre Region sollte die Verwendung von Route 53 vermieden werden, es sei denn, Sie verwenden auch die Weiterleitung von Anforderungen auf Datenverarbeitungsebene.

Weiterleitung von Anforderungen mit Global Accelerator

Wie im folgenden Diagramm gezeigt, sucht ein Client mit AWS Global Accelerator nach dem bekannten Domainnamen in Route 53. Anstatt jedoch eine IP-Adresse zurückzuerhalten, die einem regionalen Endpunkt entspricht, erhält der Client eine statische Anycast-IP-Adresse, die an den nächstgelegenen AWS-Edge-Standort weitergeleitet wird. Ausgehend von diesem Edge-Standort wird der gesamte Datenverkehr über das private AWS-Netzwerk zu einem Endpunkt (z. B. einem Load Balancer oder API Gateway) in einer Region geleitet, die anhand von Weiterleitungsregeln ausgewählt wird, die in Global Accelerator verwaltet werden. Im Vergleich zur Weiterleitung auf der Grundlage von Route-53-Regeln weist die Weiterleitung von Anforderungen mit Global Accelerator geringere Latenzen auf, da der Datenverkehr im öffentlichen Internet reduziert wird. Da Global Accelerator bei der Änderung der Weiterleitungsregeln nicht vom DNS-TTL-Ablauf abhängig ist, kann Global Accelerator die Weiterleitung außerdem schneller anpassen.

Im Modus Schreiben in eine beliebige Region oder in Kombination mit der Weiterleitung von Anforderungen auf Datenverarbeitungsebene am Back-End funktioniert Global Accelerator problemlos. Der Client stellt eine Verbindung zum nächstgelegenen Edge-Standort her und muss sich keine Gedanken darüber machen, welche Region die Anforderung erhält.

Beim Schreiben in eine Region müssen die Weiterleitungsregeln von Global Accelerator Anforderungen an die derzeit aktive Region senden. Sie können Zustandsprüfungen verwenden, die künstlich einen Fehler in einer Region melden, die von Ihrem globalen System nicht als aktive Region angesehen wird. Wie bei DNS ist es möglich, einen alternativen DNS-Domainnamen für die Weiterleitung von Leseanforderungen zu verwenden, wenn die Anforderungen aus einer beliebigen Region stammen können.

Im Modus Schreiben in Ihre Region sollte die Verwendung von Global Accelerator vermieden werden, es sei denn, Sie verwenden auch die Weiterleitung von Anforderungen auf Datenverarbeitungsebene.