Architektura AWS w przypadku wielu regionów

Question

Niedawno zostałem wprowadzony do AWS i bardzo mi się podobało. Jednak zadaję sobie kilka pytań (które mogą być głupie) o architekturę dla wielu regionów.

Załóżmy, że aplikacja jest używana przez Europejczyków i Azjatów. Moim pierwszym pomysłem było dodanie instancji EC2 w Europie, a także zasobnika S3 do przechowywania danych statycznych i kolejki SQS oraz ElastiCache w Europie. Dla Europejczyków będzie to niezwykle szybkie, ale wolniejsze dla Azjatów.

Aby rozwiązać ten problem, dodałabym CloudFront do statycznych danych, dzięki czemu obrazy będą szybko dostarczane również dla Azjatów. Jednak żądania do serwera (żądania Ajaxa) nadal będą miały pewne opóźnienia, więc rozwiązaniem będzie dodanie instancji EC2 również w regionie Singapur/Tokio.

Pojawia się jednak nowy problem: jeśli żądanie jest wysyłane do instancji Tokyo EC2, to jeśli potrzebuje odebrać wiadomość od SQS przechowywanego w Europie lub uzyskać dostęp do danych ElastiCache => opóźnienie + koszty transferu międzyregionalnego . Więc musimy dodać SQS i ElastiCache również w Azji?

Może brakuje mi czegoś, a międzyregionalne żądania AWS są superszybkie, ale z tego, co zrozumiałem, jeśli chcemy szybkiego doświadczenia dla wielu regionów, w zasadzie musimy powielić wszystkie usługi w każdym regionie (z wyjątkiem S3 może, ponieważ możemy użyć CloudFront do tego i przypuszczam, że możemy żyć z opóźnieniem, jeśli zadanie SQS w Azji potrzebuje dostępu do zasobu S3 w Europie).

W każdym razie, czy zrozumiałem to poprawnie? Czy masz jakieś zasoby na temat tworzenia aplikacji dla wielu regionów?

Dzięki :)

Answer 1

To nie są głupie pytania w ogóle! Ta część jest absolutnie poprawne:

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 

wnioski Cross-region będzie ograniczona przez prędkość światła i topologii sieci między regionami. Spodziewałbym się, że prośby z Azji dotrą do europejskiej aplikacji w około 1/4 sekundy w obie strony. Większość zgłoszeń będzie szybsza, ale nie możesz zagwarantować, że wszystkie będą szybsze, więc musisz odpowiednio zaprojektować. Jeśli to nie wystarczy, tak, musisz wdrożyć w bliższym regionie i skierować użytkowników do odpowiedniego regionu. Liczba żądań podróży w obie strony zależy od architektury aplikacji. Jeśli masz wiele próśb do Elasticache lub SQS, te 1/4 sekundy będą sumować się bardzo szybko. Jeśli możesz grupować żądania, może to być tolerowane.

Aby skierować użytkowników do odpowiedniego regionu, należy spojrzeć na numer Route 53, który jest inną częścią rodziny AWS. This announcement o trasie 53 opisuje routing oparty na opóźnieniach między regionami, których potrzebujesz. Gdy użytkownicy zostaną przekierowani do odpowiednich instancji EC2, każdy region, który wdrożyłeś, powinien być izolowany. Konfigurowałbyś swoje europejskie wdrożenie za pomocą EC2, SQS, Elasticache i wszelkich innych ofert AWS obsługiwanych z regionu europejskiego (eu-west-1). W przypadku wdrożenia w Azji możesz go hostować w regionie ap-southeast-1. Kiedy trasa 53 łączy użytkownika azjatyckiego z instancją EC2 w obrębie ap-południowy-wschód-1, żądania do SQS, Elasticache itd. Będą znajdować się w tym samym regionie, a zatem bardzo szybko.

Answer 2

Model usług udostępnianych przez Amazon Web Services pomaga wdrożyć tę samą usługę w wielu regionach. Te same komendy CLI/konsola internetowa/skrypty CloudFormation działają we wszystkich regionach w ten sam sposób. Dlatego uruchomienie podobnej usługi w Singapurze i Europie nie powinno być dla ciebie skomplikowane. Co więcej, możesz również zarządzać wszystkimi z tej samej lokalizacji - mocą chmury.

Nie będzie również droższe, ponieważ płacisz za to, czego używasz, a jeśli rozdzielisz obciążenie między regiony, będziesz mieć mniej więcej taki sam koszt. Na przykład, jeśli potrzebujesz 10 serwerów do obsługi swoich użytkowników, możesz mieć 5 serwerów w Europie i 5 serwerów w Singapurze. Więcej niż; możesz mieć różną liczbę serwerów w różnych regionach w oparciu o godzinę obciążenia przy użyciu auto-scaling. na przykład 8 serwerów w Europie, gdy Europa się obudzi, a tylko 2 w Singapurze, gdy jest noc, i na odwrót.

Dzięki połączeniu powyższych usług wieloregionowych (EC2, S3, ElasticCache, RDS ...) z Amazon CloudFront (CDN) i Route 53 (DNS) można stworzyć bardzo skalowalną i niedrogą usługę, z doskonałą opóźnienia na całym świecie (Europa, Azja, Ameryka Północna i Południowa ...).