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.

Multi-Region-Grundlagen 2: Die Daten verstehen

Die Verwaltung von Daten ist bei Architekturen mit mehreren Regionen kein triviales Problem. Die geografische Entfernung zwischen Regionen führt zu einer unvermeidlichen Latenz, die sich in der Zeit äußert, die für die Replikation von Daten zwischen Regionen benötigt wird. Kompromisse zwischen Verfügbarkeit, Datenkonsistenz und der Einführung höherer Latenzzeiten bei einem Workload, der eine Architektur mit mehreren Regionen verwendet, werden notwendig sein. Unabhängig davon, ob Sie asynchrone oder synchrone Replikation verwenden, müssen Sie Ihre Anwendung an die Verhaltensänderungen anpassen, die die Replikationstechnologie mit sich bringt. Aufgrund von Problemen im Zusammenhang mit Datenkonsistenz und Latenz ist es sehr schwierig, eine bestehende Anwendung, die für eine einzelne Region konzipiert wurde, in mehrere Regionen umzuwandeln. Es ist wichtig, die Anforderungen an die Datenkonsistenz und die Datenzugriffsmuster für bestimmte Workloads zu verstehen, um die Kompromisse abzuwägen.

2a: Die Anforderungen an die Datenkonsistenz verstehen

Das CAP-Theorem bietet eine Referenz für Überlegungen zu den Kompromissen zwischen Datenkonsistenz, Verfügbarkeit und Netzwerkpartitionen, von denen für eine Arbeitslast nur zwei gleichzeitig erfüllt werden können. Multiregion umfasst definitionsgemäß Netzwerkpartitionen zwischen Regionen, sodass Sie zwischen Verfügbarkeit und Konsistenz wählen müssen.

Wenn Sie sich für die regionsübergreifende Verfügbarkeit der Daten entscheiden, treten bei transaktionalen Schreibvorgängen keine nennenswerten Latenzen auf, da auf die asynchrone Replikation festgeschriebener Daten zwischen Regionen angewiesen ist, was zu einer verringerten Konsistenz zwischen den Regionen führt, bis die Replikation abgeschlossen ist. Wenn bei der asynchronen Replikation ein Fehler in der primären Region auftritt, besteht eine hohe Wahrscheinlichkeit, dass Schreibvorgänge aus der primären Region noch nicht repliziert werden. Dies führt zu einem Szenario, in dem die neuesten Daten erst verfügbar sind, wenn die Replikation wieder aufgenommen wird, und ein Abgleichprozess erforderlich ist, um laufende Transaktionen zu verarbeiten, die nicht aus der Region repliziert wurden, in der der Ausfall aufgetreten ist.

Für Workloads, bei denen asynchrone Replikation bevorzugt wird, können Sie Services wie Amazon Aurora und Amazon DynamoDB verwenden, die eine asynchrone regionsübergreifende Replikation ermöglichen. Sowohl die globalen Tabellen von Amazon Aurora Global Database als auch Amazon DynamoDB verfügen über standardmäßige CloudWatchAmazon-Metriken, um die Überwachung von Replikationsverzögerungen zu unterstützen.

Der Workload so zu gestalten, dass er die Vorteile ereignisgesteuerter Architekturen nutzt, ist für eine Strategie mit mehreren Regionen von Vorteil, da der Workload dadurch die asynchrone Replikation von Daten umfassen kann und der Status durch die Wiedergabe von Ereignissen wiederhergestellt werden kann. Da Streaming- und Messaging-Dienste Nachrichtennutzdaten in einer einzigen Region zwischenspeichern, muss ein regionaler Failover-/Failback-Prozess einen Mechanismus zur Umleitung von Client-Eingabedatenströmen sowie zum Abgleich von laufenden und/oder nicht zugestellten Payloads, die in der Region gespeichert sind, in der der Ausfall aufgetreten ist, beinhalten.

Wenn Konsistenz ausgewählt ist, kommt es zu einer erheblichen Latenz, da Daten während transaktionaler Schreibvorgänge synchron repliziert werden. Wenn Sie synchron in mehrere Regionen schreiben und der Schreibvorgang nicht in allen Regionen erfolgreich ist, wird die Verfügbarkeit möglicherweise beeinträchtigt, da die Transaktion nicht festgeschrieben wird und erneut versucht werden muss. Wiederholte Versuche, die Daten synchron in alle Regionen zu schreiben, gehen bei jedem Versuch auf Kosten der Latenz. Irgendwann, wenn die Wiederholungsversuche ausgeschöpft sind, muss entschieden werden, ob die Transaktion entweder komplett fehlschlagen soll, wodurch die Verfügbarkeit reduziert wird, oder ob die Transaktion nur auf verfügbare Regionen übertragen werden soll, was zu Inkonsistenzen führt. Es gibt Technologien zur Quorumbildung wie Paxos, mit denen Daten synchron repliziert und übertragen werden können, für die jedoch erhebliche Investitionen von Entwicklern erforderlich sind.

Wenn Schreibvorgänge synchrone Replikationen über mehrere Regionen hinweg beinhalten, um hohe Konsistenzanforderungen zu erfüllen, erhöht sich die Schreiblatenz um eine Größenordnung. Eine höhere Schreiblatenz kann normalerweise nicht ohne wesentliche Änderungen in eine Anwendung nachgerüstet werden. Im Idealfall muss dies bei der ersten Entwicklung der Anwendung berücksichtigt werden. Bei Workloads mit mehreren Regionen, bei denen synchrone Replikation Priorität hat, können AWSPartnerlösungen helfen.

2b: Verständnis der Datenzugriffsmuster

Datenzugriffsmuster für Workloads lassen sich in einen der folgenden Typen einteilen: leseintensiv oder schreibintensiv. Wenn Sie dieses Merkmal für einen bestimmten Workload verstehen, können Sie sich bei der Auswahl einer geeigneten Architektur für mehrere Regionen entscheiden.

Für leseintensive Workloads wie statische Inhalte, die vollständig schreibgeschützt sind, kann eine aktive/aktive Multiregions-Architektur ohne nennenswerte Komplexität erreicht werden. Die Bereitstellung statischer Inhalte am Netzwerkrand mithilfe eines Content Distribution Network (CDN) gewährleistet die Verfügbarkeit, indem Inhalte zwischengespeichert werden, die dem Endbenutzer am nächsten sind. Die Verwendung von Funktionen wie Origin-Failover innerhalb von Amazon CloudFront kann dazu beitragen, dies zu erreichen. Eine weitere Option ist die Bereitstellung von statusfreiem Computing in mehreren Regionen und die Verwendung von DNS, um Benutzer zur nächstgelegenen Region weiterzuleiten, wo sie die Inhalte lesen können. Um dies zu erreichen, kann Route 53 mit Geolocation-Routing-Richtlinie verwendet werden.

Für leseintensive Workloads mit einem höheren Prozentsatz an Lese- als Schreibvorgängen kann eine lokale Lesestrategie und eine globale Schreibstrategie verwendet werden. Das bedeutet, dass alle Schreibvorgänge in eine Datenbank in einer bestimmten Region gehen und die Daten asynchron in alle anderen Regionen repliziert werden. Lesevorgänge können zu diesem Zweck in jeder Region durchgeführt werden. Bei diesem Ansatz ist ein Workload erforderlich, der letztendlich für Konsistenz sorgen muss, da lokale Lesevorgänge aufgrund der erhöhten Latenz bei der regionsübergreifenden Replikation von Schreibvorgängen veraltet sein können.

Aurora Global Database kann bei der Bereitstellung von Read Replicas in einer Standby-Region helfen, die ausschließlich den gesamten Lesetraffic lokal verarbeiten kann, und einem einzigen primären Datenspeicher in einer bestimmten Region für Schreibvorgänge. Daten werden asynchron von der Primär- in die Standby-Datenbank (Read Replicas) repliziert, und die Standby-Datenbanken können zur Primärdatenbank heraufgestuft werden, wenn Sie Failover-Operationen auf die Standby-Region umstellen müssen. Wenn ein Workload besser für nicht-relationale Datenmodelle geeignet ist, kann DynamoDB auch in diesem Ansatz verwendet werden. Auch hier muss der Workload letztendlich konsistent sein, weshalb er möglicherweise neu geschrieben werden muss, wenn er nicht von Anfang an darauf ausgelegt war.

Bei schreibintensiven Workloads sollte eine primäre Region ausgewählt werden, und die Fähigkeit zum Failover auf eine Standby-Region sollte in den Workload integriert werden. Im Vergleich zu einem aktiven/aktiven Ansatz ist ein primärer/Standby-Ansatz weniger kompliziert. Dies liegt daran, dass bei einer aktiven/aktiven Architektur der Workload neu geschrieben werden muss, um intelligentes Routing zu Regionen zu ermöglichen, Sitzungsaffinität herzustellen, idempotente Transaktionen sicherzustellen und potenzielle Konflikte zu bewältigen.

Für die meisten Workloads, die aus Gründen der Resilienz auf mehrere Regionen abzielen, ist kein aktiver/aktiver Ansatz erforderlich. Eine Sharding-Strategie kann eingesetzt werden, um die Widerstandsfähigkeit zu erhöhen, indem der Explosionsradius einer Beeinträchtigung innerhalb des Kundenstamms begrenzt wird. Wenn Sie einen Kundenstamm effektiv teilen können, können Sie für jeden Shard verschiedene Hauptregionen auswählen. Wenn Sie beispielsweise Kunden so teilen können, dass die Hälfte der Kunden auf Region Eins und die andere Hälfte auf Region Zwei ausgerichtet ist und Regionen als Zellen behandelt werden, kann ein zellenübergreifender Ansatz geschaffen werden, der den Wirkungsradius Ihrer Arbeitslast reduziert.

Der Sharding-Ansatz kann mit einem Primär-/Standby-Ansatz kombiniert werden, um Failover-Funktionen für die Shards bereitzustellen. Ein getesteter Failover-Prozess muss in die Arbeitslast integriert werden, und es muss auch ein Prozess für den Datenabgleich entwickelt werden, um die Transaktionskonsistenz der Datenspeicher nach dem Failover sicherzustellen. Diese werden später in diesem paper ausführlicher behandelt.

Wichtige Leitlinien