Архитектура AWS, когда несколько регионов

Недавно я познакомился с AWS, и мне очень понравилось. Тем не менее, я задаю себе несколько вопросов (что может быть глупо) об архитектуре для нескольких регионов.

Скажем, приложение используется европейцами и азиатами. Моя первая идея заключалась в том, чтобы добавить экземпляры EC2 в Европе, а также ведро S3 для хранения статических данных и очереди SQS и ElastiCache в Европе. Это будет невероятно быстро для европейских людей, но медленнее для азиатов.

Чтобы решить эту проблему, я бы добавил CloudFront для статических данных, чтобы изображения были быстро отправлены и для азиатов. Однако запросы на сервер (запросы Ajax...) все еще будут иметь некоторые задержки, поэтому решение должно было бы добавить экземпляр EC2 в регионе Сингапур/Токио.

Однако возникает новая проблема: если запрос отправляется в экземпляр Tokyo EC2, то если ему нужно получить сообщение из SQS, которое хранится в Европе, или снова получить доступ к данным ElastiCache = > задержка + затраты на передачу между регионами. Итак, нам нужно добавить SQS и ElastiCache в Азии?

Возможно, я что-то пропустил, и запросы AWS по кросс-регионам очень быстрые, но из того, что я понял, если мы хотим получить быстрый опыт для нескольких регионов, нам в основном нужно дублировать все сервисы тоже в каждом регионе (кроме S3 возможно, поскольку мы можем использовать CloudFront для этого, и я полагаю, что мы можем жить с задержкой, если работа SQS в Азии должна получить доступ к ресурсу S3 в Европе).

В любом случае, правильно ли я это понял? Есть ли у вас какие-либо ресурсы о том, как приложения архитектуры, ориентированные на несколько регионов?

Спасибо:)

Ответ 1

Это не глупые вопросы! Эта часть абсолютно правильная:

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

Запросы в кросс-области будут ограничены скоростью света и топологией сети между регионами. Я ожидал бы, что запросы из Азии достигнут европейской заявки примерно в 1/4 второго тура. Большинство запросов будут быстрее, но вы не можете гарантировать, что все они будут быстрее, поэтому вы должны соответствующим образом разработать. Если это не достаточно быстро, то да, вам нужно будет развернуться в более близком регионе и перенаправить пользователей в соответствующий регион. Количество раз, когда требуется поездка туда и обратно, зависит от вашей архитектуры приложения. Если у вас много запросов к Elasticache или SQS, эти 1/4 секунды будут складываться очень быстро. Если вы можете выполнять пакетные запросы, это может быть приемлемым.

Чтобы перенаправить пользователей в соответствующий регион, вам нужно посмотреть Маршрут 53, который является еще одной частью семейства AWS. Это объявление о маршруте 53 описывает маршрутизацию с задержкой между регионами, которые вам понадобятся. Когда пользователи перенаправляются в соответствующие экземпляры EC2, каждый регион, в который вы развернули, должен быть изолирован. Вы настроили бы свое европейское развертывание с EC2, SQS, Elasticache и любыми другими предложениями AWS, которые обслуживались в Европейском регионе (eu-west-1). Для вашего азиатского развертывания вы можете разместить все это в регионе ap-south-1. Когда Route 53 соединяет азиатского пользователя с экземпляром EC2 в пределах ap-south-1, запросы SQS, Elasticache и т.д. Будут находиться в одной области и, таким образом, очень быстро.

Ответ 2

Модель утилит, предлагаемая Amazon Web Services, помогает вам развертывать одну и ту же услугу в нескольких регионах. Те же команды CLI/web console/CloudFormation работают во всех регионах одинаково. Поэтому для запуска аналогичной услуги в Сингапуре и Европе вам не должно быть сложно. Более того, вы также можете управлять всеми ими из того же места - силой облака.

Это также не будет стоить дороже, поскольку вы платите за то, что используете, и если вы распределяете нагрузку между регионами, у вас будет более или менее одинаковая стоимость. Например, если вам нужно 10 серверов для обслуживания ваших пользователей, вы можете иметь 5 серверов в Европе и 5 серверов в Сингапуре. Более чем; вы можете иметь различное количество серверов в разных регионах в зависимости от часа загрузки, используя автомасштабирование. например, 8 серверов в Европе, когда Европа бодрствует, и только 2 в Сингапуре, когда там ночь, и наоборот.

Благодаря сочетанию вышеупомянутых многорегиональных сервисов (EC2, S3, ElasticCache, RDS...) с Amazon CloudFront (CDN) и маршрутом 53 (DNS) вы можете создать очень масштабируемый и доступный сервис с отличной задержкой глобально (Европа, Азия, Северная и Южная Америка...).