AWS-Architektur bei Multi-Regionen

Question

Ich wurde kürzlich in AWS eingeführt und ich habe es wirklich geliebt. Allerdings stelle ich mir einige Fragen (die vielleicht dumm sind) über die Architektur für Multi-Regionen.

Angenommen, eine Anwendung wird von Europäern und Asiaten verwendet. Meine erste Idee war, EC2-Instanzen in Europa hinzuzufügen, sowie einen S3-Bucket für statische Daten und eine SQS-Warteschlange und ElastiCache in Europa. Es wird für europäische Menschen blitzschnell sein, aber für Asiaten langsamer.

Um dies zu lösen, würde ich CloudFront für statische Daten hinzufügen, so dass Bilder auch für Asiaten schnell geliefert werden. Anfragen an Server (Ajax-Anfragen ...) haben jedoch immer noch einige Latenzen, so dass die Lösung wäre, auch eine EC2-Instanz in der Region Singapur/Tokio hinzuzufügen.

Es treten jedoch neue Probleme auf: Wenn eine Anfrage an die Tokyo EC2-Instanz gesendet wird, wenn sie eine Nachricht von SQS empfangen muss, die in Europa gespeichert ist oder auf ElastiCache-Daten zugreifen => Latenzzeit + + Kosten für Zwischenregionenübertragung . Also müssen wir SQS und ElastiCache auch in Asien hinzufügen?

Vielleicht vermisse ich etwas, und AWS-Anfragen über Regionen hinweg sind superschnell, aber aus dem, was ich verstanden habe, wenn wir schnelle Erfahrung für Multi-Regionen wollen, müssen wir grundsätzlich alle Services für alle Regionen duplizieren S3 vielleicht, da wir CloudFront dafür verwenden können, und ich nehme an, wir können mit der Latenz leben, wenn ein SQS-Job in Asien auf eine S3-Ressource in Europa zugreifen muss.

Wie auch immer, habe ich das richtig verstanden? Verfügen Sie über Ressourcen für Architekturanwendungen, die auf mehrere Regionen abzielen?

Danke :)

Answer 1

Das sind keine dummen Fragen überhaupt! Dieser Teil ist absolut richtig:

Maybe I miss something, and cross-regions AWS requests are super-fast, but from 
what I've understood, if we want fast experience for multi-regions, we basically 
need to duplicate all services too every regions 

Quer Region Anfragen werden von der Geschwindigkeit des Lichts und die Netzwerktopologie zwischen den Regionen begrenzt werden. Ich würde erwarten, dass Anfragen aus Asien den europäischen Antrag in etwa 1/4 Sekunden Hin- und Rückreise erreichen. Die meisten Anfragen wären schneller, aber Sie können nicht garantieren, dass alle schneller sind, also müssen Sie entsprechend entwerfen. Wenn das nicht schnell genug ist, dann müssen Sie in einer näheren Region bereitstellen und Benutzer zu der entsprechenden Region leiten. Wie oft diese Hin- und Rückreise erforderlich ist, hängt von der Architektur Ihrer Anwendung ab. Wenn Sie viele Anfragen an Elasticache oder SQS haben, summieren sich diese 1/4 Sekunden sehr schnell. Wenn Sie die Anforderungen stapelweise verarbeiten können, ist dies möglicherweise tolerierbar.

Um Benutzer in die entsprechende Region zu leiten, sollten Sie sich die Route 53 ansehen, die ein weiterer Teil der AWS-Familie ist. This announcement über Route 53 beschreibt das latenzbasierte Routing zwischen Regionen, die Sie benötigen. Sobald Benutzer an die entsprechenden EC2-Instanzen weitergeleitet wurden, sollte jede Region, in der Sie sie bereitgestellt haben, isoliert werden. Sie konfigurieren Ihre europäische Bereitstellung mit EC2, SQS, Elasticache und anderen AWS-Angeboten, die alle aus der europäischen Region (eu-west-1) stammen. Für Ihre asiatische Bereitstellung könnten Sie alles in der Region ap-southeast-1 hosten. Sobald Route 53 einen asiatischen Benutzer mit einer EC2-Instanz innerhalb von ap-Südost-1 verbindet, befinden sich die Anforderungen an SQS, Elasticache usw. innerhalb derselben Region und somit sehr schnell.

Answer 2

Das von Amazon Web Services eingeführte Dienstprogramme-Modell unterstützt Sie bei der Bereitstellung desselben Dienstes in mehreren Regionen. Die gleichen CLI-Befehle/Webkonsole/CloudFormation-Skripts funktionieren in allen Regionen auf die gleiche Weise. Daher sollte es nicht kompliziert sein, einen ähnlichen Service in Singapur und in Europa zu starten. Mehr als das, Sie können auch alle von demselben Ort aus verwalten - die Macht der Cloud.

Es wird auch nicht teurer sein, da Sie für das bezahlen, was Sie verwenden, und wenn Sie die Last zwischen den Regionen verteilen, werden Sie mehr oder weniger die gleichen Kosten haben. Wenn Sie beispielsweise 10 Server benötigen, um Ihre Benutzer zu bedienen, können Sie 5 Server in Europa und 5 Server in Singapur haben. Mehr als als; Sie können eine unterschiedliche Anzahl von Servern in verschiedenen Regionen basierend auf der Ladezeit verwenden, indem Sie auto-scaling verwenden. zum Beispiel 8 Server in Europa, wenn Europa wach ist und nur 2 in Singapur, wenn es Nacht ist, und umgekehrt.

Mit der Kombination der oben genannten Multi-Region-Dienste (EC2, S3, ElasticCache, RDS ...) mit Amazon CloudFront (CDN) und Route 53 (DNS) können Sie einen sehr skalierbaren und erschwinglichen Service mit exzellenten erstellen Latenzzeit weltweit (Europa, Asien, Nord- und Südamerika ...).