#amazon-web-services #load-balancing #amazon-route53
Вопрос:
У меня есть приложение, размещенное на 2 виртуальных машинах в разных регионах (скажем, в США и Австралии). Пользователи будут иметь свои данные в любом из этих регионов из-за ограничений на проживание в данных.
Допустим, пользователь, чьи данные находятся на сервере AU, путешествует в Канаду, и маршрутизация на основе географического местоположения/задержки направит пользователя на ближайший сервер, который находится в США.
Мое приложение может внутренне каким-то образом отреагировать на перенаправление этого пользователя на сервер AU. Как я могу сделать так, чтобы все последующие запросы направлялись непосредственно на сервер AU, не обращаясь к серверу США?
Ответ №1:
Я предполагаю, что вы настроили DNS-имя в Amazon Route 53 для использования геораутинга или маршрутизации на основе задержки для направления пользователей к месту назначения.
Чтобы направить пользователя в другое место, вам может потребоваться отправить его на IP-адрес или DNS-имя, которые не проходят через этот поиск по геопередаче/задержке.
Например:
- Создайте
sydney.example.com, чтобы указать на сервер в Сиднее - Создайте
ohio.example.com, чтобы указать на сервер штата Огайо - Создайте
example.comдля использования гео/латентную маршрутизацию, которая разрешает либоsydney.илиohio. - Если вы хотите перенаправить пользователя в определенное место (например, в Сидней), отправьте его туда
sydney.example.com, чтобы избежать повторного просмотра гео/задержки
Комментарии:
1. Это не то решение, которое я ищу. У меня есть общедоступный API, который будет доступен по общему URL-адресу (api.example.com). Я планирую использовать AWS Global Accelerator для управления архитектурой нескольких регионов. Есть какие-нибудь предложения в этом направлении?
2. Нет возможности указать «переопределение» для Amazon Route 53 или глобального ускорителя. Вот почему вам также понадобится способ отправки пользователей в определенное место назначения.
3. Затем, как работают общедоступные API (скажем api.facebook.com) работает, пока данные пользователей размещаются только в странах, специфичных для пользователей. Но все же они могут предоставлять данные, используя общее доменное имя?
Ответ №2:
Вам необходимо архитектурно отделить требования к месту жительства данных профиля данного пользователя от соображений производительности доставки контента — это поможет вам продвинуться дальше по обоим направлениям.
Например, место жительства пользователя обычно определяется во время создания учетной записи и редко изменяется впоследствии. Например, ваши «данные в состоянии покоя» остаются в Австралии. Данные в состоянии покоя могут быть доступны всем вашим серверам приложений по всему миру (включая те, которые загружены в канадском центре обработки данных) с использованием единого внутреннего API или схем доступа к хосту базы данных.
Вышеуказанная архитектура позволит хранить данные в состоянии покоя в Австралии, но «данные в пути» или данные в кэше в памяти (например, любое хранилище KV) будут доступны с любого «рабочего» сервера приложений в любой точке мира. Убедитесь, что вы используете шифрование во время передачи данных, и проверьте сохранность указанных данных.
Вы можете повысить производительность за счет максимизации HTTP-ответов, которые можно свободно кэшировать с помощью CDN и любых промежуточных кэшей (заголовок Cache-Control HTTP), а также с помощью стратегий гео-маршрутизации, о которых вы уже упоминали.