Multi-Region ElastiCache

Wenn die Kunden aus der ganzen Welt kommen sollte man sich über ein Multi-Region Deployment Gedanken machen. Die Idee ist dabei die Daten so nahe an den Kunden zu bringen wie möglich. Dadurch wird die Latenz für den Kunden minimiert. Die meisten Services in AWS sind von Haus aus an eine Region gebunden.

Wie kann man nun also mehrere Regions verbinden? Die Antwort lautet Synchronisation / Replikation. Dabei ergeben sich neue Schwierigkeiten. Zwei unabhängige MySQL Datenbanken in Region eu-west-1 (Irland) und us-east-1 (USA) lassen sich nur schwer synchronisieren wenn in beide geschrieben werden darf. Die Latenz zwischen der Ostküste der USA und Irland ist schlicht zu hoch um Transaktionen darüber laufen zu lassen. Also wenn in den USA geschrieben wird so lange zu warten bis der Schreibvorgang auch in Irland bestätigt wurde. Es muss eine asynchrone Synchronisation verwendet werden. Diese bringt allerdings Probleme von Konflikten mit sich wenn ein Datensatz gleichzeitig in beiden Regions geändert wird.

Konzept

Multi-Region Konzept

Um das Problem der konkurrierenden Schreibzugriffe zu umgehen verwenden wir nur eine DynamoDB Datenbank in eu-west-1. In diese Haupt-Datenbank wird hauptsächlich geschrieben. Bei jedem Schreibvorgang (Insert, Update, Delete) wird eine Nachricht auf ein SNS Update Topic publiziert.

In jeder Region läuft ein ElastiCache Cluster das den Datenbestand aus der Haupt-Datenbank spiegelt. Über die von SNS angebotenen Subscriber wird das SNS Update Topic mit je einer SQS Update Queue pro Region verbunden. In jeder Region laufen EC2 Instanzen die neben ihrer eigentlichen Arbeit noch auf die Update Queue hören und Änderungen zum ElastiCache Cluster schicken. Will eine EC2 Instanz Daten lesen so werden die Daten aus dem ElastiCache Cluster gelesen.

Vorteile

Jede Änderung wird nur einmal zwischen den Regionen transportiert. Es werden nur Managed Services eingesetzt, dadurch ist der Betriebsaufwand sehr gering.

Nachteile

Es muss ein Protokoll eingesetzt werden, welches sicherstellt, dass Updates in der richtigen Reihenfolge eingespielt werden. Ein einfaches Protokoll kann für jeden Datensatz eine Versionsnummer verwenden und das Update nur dann einspielen, wenn di Version größer als die aktuelle Version im Cache ist. Andere Updates werden einfach verworfen.

Alternativen

  • DynamoDB Streams sind noch in der Preview Phase, daher noch nicht für produktive Einsätze gedacht

Ähnliche Tags

DynamoDB EC2 ElastiCache Multi-Region SNS SQS aws

Teilen

           

RSS

  RSS

Newsletter


Michael Wittig

Michael Wittig

Ich bin Autor von Author of Amazon Web Services in Action. Ich arbeite als Software Engineer und unabhängiger Berater mit dem Fokus auf AWS und DevOps. Engagiere mich!

Fehlt etwas in meinem Artikel? Ich freue mich auf dein Feedback! @hellomichibye oder michael@widdix.de.


Veröffentlicht am