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 ein nicht triviales Problem, wenn Sie Architekturen mit mehreren Regionen einsetzen. 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 einer höheren Latenz 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. Probleme im Zusammenhang mit Datenkonsistenz und Latenz machen 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.
2.a: Die Anforderungen an die Datenkonsistenz verstehen
Das CAP-Theorem bietet eine Referenz für Überlegungen zu den Kompromissen zwischen Datenkonsistenz, Verfügbarkeit und Netzwerkpartitionen. Für einen Workload können nur zwei dieser Anforderungen gleichzeitig erfüllt werden. Per Definition umfasst eine Architektur mit mehreren Regionen Netzwerkpartitionen zwischen Regionen, sodass Sie sich zwischen Verfügbarkeit und Konsistenz entscheiden müssen.
Wenn Sie sich für die regionsübergreifende Verfügbarkeit von Daten entscheiden, treten bei transaktionalen Schreibvorgängen keine nennenswerten Latenzen auf, da die Abhängigkeit von der asynchronen Replikation festgeschriebener Daten zwischen Regionen zu einer verringerten Konsistenz zwischen den Regionen führt, bis die Replikation abgeschlossen ist. Bei der asynchronen Replikation besteht bei einem Ausfall in der primären Region eine hohe Wahrscheinlichkeit, dass Schreibvorgänge noch auf die Replikation aus der primären Region warten. 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 die Unterbrechung aufgetreten ist. Für dieses Szenario müssen Sie Ihre Geschäftslogik verstehen und einen speziellen Prozess erstellen, um die Transaktion erneut abzuspielen oder Datenspeicher zwischen Regionen zu vergleichen.
Für Workloads, bei denen asynchrone Replikation bevorzugt wird, können Sie Services wie Amazon Aurora und Amazon
Bei einer Strategie mit mehreren Regionen ist es von Vorteil, den Workload so zu gestalten, dass er die Vorteile ereignisgesteuerter Architekturen nutzt, da der Workload 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- oder Failback-Prozess einen Mechanismus zur Umleitung von Client-Eingabedatenströmen beinhalten. Der Prozess muss auch Payloads abgleichen, die während der Übertragung übertragen wurden oder nicht zugestellt wurden, die in der Region gespeichert sind, in der die Störung aufgetreten ist.
Wenn Sie sich für die GAP-Konsistenzanforderung entscheiden und eine synchron replizierte Datenbank in allen Regionen verwenden, um Ihre Anwendungen zu unterstützen, die gleichzeitig in mehreren Regionen ausgeführt werden, vermeiden Sie das Risiko eines Datenverlusts und sorgen dafür, dass die Daten zwischen den Regionen synchron bleiben. Dies führt jedoch zu höheren Latenzeigenschaften, da Schreibvorgänge auf mehr als eine Region übertragen werden müssen und die Regionen Hunderte oder Tausende von Meilen voneinander entfernt sein können. Sie müssen dieses Latenzmerkmal in Ihrem Anwendungsdesign berücksichtigen. Darüber hinaus kann die synchrone Replikation das Risiko korrelierter Fehler mit sich bringen, da Schreibvorgänge in mehr als einer Region gespeichert werden müssen, um erfolgreich zu sein. Wenn es innerhalb einer Region zu einer Beeinträchtigung kommt, müssen Sie ein Quorum bilden, damit Schreibvorgänge erfolgreich sind. Dies beinhaltet in der Regel die Einrichtung Ihrer Datenbank in drei Regionen und die Einrichtung eines Quorums für zwei von drei Regionen. Technologien wie Paxos
Wenn Schreibvorgänge eine synchrone Replikation über mehrere Regionen hinweg beinhalten, um hohe Konsistenzanforderungen zu erfüllen, erhöht sich die Schreiblatenz um eine Größenordnung. Eine höhere Schreiblatenz ist normalerweise nicht etwas, das Sie in einer Anwendung nachrüsten können, ohne wesentliche Änderungen, wie z. B. die Timeout- und Wiederholungsstrategie für Ihre Anwendung, zu ändern. Im Idealfall muss dies bei der ersten Entwicklung der Anwendung berücksichtigt werden. Für Workloads mit mehreren Regionen, bei denen die synchrone Replikation Priorität hat, können AWS Partner Lösungen
2.b: Datenzugriffsmuster verstehen
Arbeitslast-Datenzugriffsmuster sind entweder leseintensiv oder schreibintensiv. Wenn Sie dieses Merkmal für einen bestimmten Workload verstehen, können Sie eine geeignete Architektur für mehrere Regionen auswählen.
Für leseintensive Workloads wie statische Inhalte, die vollständig schreibgeschützt sind, können Sie eine aktiv-aktive
Für leseintensive Workloads, die einen höheren Prozentsatz an Lesetraffic als an Schreibverkehr haben, können Sie eine lokale Lesestrategie und eine globale Schreibstrategie
Die globalen Aurora-Datenbanken
Für schreibintensive Workloads sollte eine primäre Region ausgewählt werden, und die Fähigkeit, auf eine Standby-Region umzuschalten, sollte in den Workload integriert werden. Im Vergleich zu einem Active-Active-Ansatz hat ein primärer
Für die meisten Workloads, die aus Gründen der Resilienz einen Ansatz mit mehreren Regionen verwenden, ist kein aktiv-aktiver Ansatz erforderlich. Sie können eine Sharding-Strategie
Sie können den Sharding-Ansatz mit einem Primary-Standby-Ansatz kombinieren, um Failover-Funktionen für die Shards bereitzustellen. Sie müssen einen getesteten Failover-Prozess für die Arbeitslast und auch einen Prozess für den Datenabgleich einrichten, um die Transaktionskonsistenz der Datenspeicher nach dem Failover sicherzustellen. Diese werden später in diesem Handbuch ausführlicher behandelt.
Wichtige Hinweise
-
Es besteht eine hohe Wahrscheinlichkeit, dass Schreibvorgänge, die zur Replikation noch ausstehen, nicht in die Standby-Region übernommen werden, wenn ein Fehler auftritt. Daten sind erst verfügbar, wenn die Replikation wieder aufgenommen wird (unter der Annahme einer asynchronen Replikation).
-
Im Rahmen des Failovers ist ein Datenabgleich erforderlich, um sicherzustellen, dass bei Datenspeichern, die asynchrone Replikation verwenden, ein transaktionskonsistenter Zustand aufrechterhalten wird. Dies erfordert eine spezielle Geschäftslogik und wird nicht vom Datenspeicher selbst verwaltet.
-
Wenn eine hohe Konsistenz erforderlich ist, müssen die Workloads so angepasst werden, dass sie die erforderliche Latenz eines Datenspeichers, der synchron repliziert, tolerieren.
