Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Anforderungsweiterleitung mit globalen DynamoDB-Tabellen
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 Anfrage trifft auf einen Stapel von Diensten in dieser Region, einschließlich einer Rechenschicht, die möglicherweise aus einem Load Balancer besteht, der von einer AWS Lambda Funktion, einem Container oder einem Amazon Elastic Compute Cloud (AmazonEC2) -Knoten unterstützt wird, und möglicherweise auf andere Dienste, einschließlich einer anderen Datenbank. 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. Die Latenzen bei einem regionsübergreifenden Zugriff können 100-mal höher sein als beim lokalen Zugriff. Eine back-and-forth Reihe von 5 Anfragen kann Millisekunden dauern, wenn sie lokal ausgeführt werden, aber Sekunden, wenn sie den Globus überqueren. Es ist besser, den Endbenutzer zur Verarbeitung an eine andere Region weiterzuleiten. 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 clientgesteuerten Weiterleitung von Anfragen verfolgt ein Endbenutzer-Client, z. B. eine Anwendung, eine Webseite mit einem JavaScript anderen Client, die gültigen Anwendungsendpunkte. In diesem Fall handelt es sich eher um Anwendungsendpunkte wie ein Amazon API Gateway als um wörtliche DynamoDB-Endpunkte. Der Endbenutzer-Client verwendet seine eigene eingebettete Logik, um auszuwählen, mit welcher Region 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.
Der Vorteil der Client-gesteuerten Weiterleitung von Anforderungen besteht darin, dass beispielsweise eine Anpassung an die realen Bedingungen des öffentlichen Internetverkehrs möglich ist und die Region gewechselt werden 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. Dies könnte so einfach sein wie das empirische Testen, welche Region derzeit Schreibvorgänge akzeptiert (wobei alle Schreibabweisungen notiert und auf eine Alternative zurückgegriffen wird) oder so komplex wie das Aufrufen eines globalen Koordinators zur Abfrage des aktuellen Anwendungsstatus (möglicherweise auf der Route 53 Application Recovery Controller (ARC) -Routingsteuerung aufgebaut, die ein quorumgesteuertes System mit 5 Regionen bereitstellt, um den globalen Status für solche Anforderungen aufrechtzuerhalten). 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 strikte 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 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 Leseoperationen, 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.
Nehmen wir in diesem Szenario an, ein Finanzdienstleistungsunternehmen verwendet ein follow-the-sun Single-Primärmodell. Das Unternehmen verwendet ein System und eine Bibliothek für diesen Weiterleitungsprozess. Ihr Gesamtsystem behält den globalen Status bei, ähnlich wie bei AWS der ARC Routingsteuerung. 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 Bibliothek, die mit dem System koordiniert wird. Die Bibliothek ermöglicht die lokale Ausführung von Leseoperationen mit geringer Latenz. Bei Schreiboperationen prüft die Anwendung, ob die lokale Region die aktuelle Primärregion ist. Falls ja, wird der Schreibvorgang direkt abgeschlossen. Wenn nicht, leitet die Bibliothek die Schreibaufgabe an die Bibliothek weiter, die sich in der aktuellen Primärregion befindet. 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 zurück, die den regionalen Endpunkten entspricht, die er für am geeignetsten hält. Route 53 verfügt über eine Liste von Weiterleitungsrichtlinien, anhand derer die entsprechende 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 „In eine Region schreiben“ kann Route 53 so konfiguriert werden, dass sie die aktuell aktive Region zurückgibt (mithilfe von Route 53ARC).
Anmerkung
Clients speichern die IP-Adressen in der Antwort von Route 53 für einen Zeitraum im Cache, der durch die Einstellung time to live (TTL) für den Domänennamen angegeben ist. Eine längere Einstellung TTL verlängert die Zielvorgabe für die Wiederherstellung (RTO), sodass alle Clients den neuen Endpunkt erkennen können. Ein Wert von 60 Sekunden ist typisch für den Failover-Einsatz. Nicht jede Software hält sich perfekt an das DNS TTL Ablaufdatum.
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
Ein Client verwendet AWS Global Accelerator
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 ist es möglichDNS, einen alternativen DNS Domainnamen für die Weiterleitung von Leseanfragen zu verwenden, wenn die Anfragen 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.
