Блог

Вопрос может быть не таким фундаментальным, как вы думали. Прежде всего, спасибо, что прочитали. Я изучаю информатику. Я только начинаю узнавать об AWS, особенно о маршруте 53, поэтому, пожалуйста, простите меня, если что-то режет вам глаза 🙂

Все мы знаем, что Amazon Route 53 предоставляет клиентам возможность направлять пользователей к инстансам EC2, сегментам S3 и эластичным балансировщикам нагрузки в нескольких зонах и регионах доступности, а также существуют различные формы балансировки нагрузки DNS, в том числе:

• Маршрутизация на основе LBR / Latency для маршрутизации в регион с наименьшей задержкой
• WRR / Взвешенный циклический перебор, для присвоения весов различным целям

Кроме того, возможны пользовательские конфигурации, которые объединяют оба варианта (LBR WRR).

Гибкость маршрута 53 позволяет пользователям экономить затраты, однако ручная настройка может стать все более сложной для конечных пользователей. Поиск наилучшей не вероятностной политики (такой как веса WRR) является NP-полным.

В каких возможных случаях нам нужно присвоить IP-адресам сервера разный вес? учитывая, что могут существовать серверы EC2, которые в нескольких зонах доступности и экземплярах могут содержать как интерфейс, так и серверную часть или содержать только уровни приложений или базы данных? Есть ли какие-либо идеи по поиску возможного лучшего использования Route 53 в сочетании с другими сервисами AWS, чтобы повысить производительность интерактивных многоуровневых облачных приложений?

Извините за длинный вопрос. Я ищу мысли и идеи о наилучшем способе / отправной точке для экспериментов по улучшению использования Route 53 и в сочетании с другими сервисами AWS для многоуровневого облачного приложения. Не обязательно 100% правильный ответ. Любые идеи или предложения приветствуются. Заранее большое спасибо!

Обновить:

Вероятно, мне следует перефразировать вопрос: какова цель установки взвешенной записи в маршруте 53, т. е. в службе DNS? Очевидно, что WRR в DNS может управлять зельями трафика, но если мы просто будем полагаться на этот баланс нагрузки DNS (или распределение нагрузки), мы создадим большую нагрузку на многие другие DNS-серверы. Один случай, который я мог бы обдумать, заключается в том, что веб-сайты, такие как Google или Facebook, потенциально могут получать тонны запросов на доменные имена, балансировка нагрузки WRR DNS может быть полезной, и должна быть какая-то липкость сеанса, поскольку совместное использование сеанса между серверами кажется плохой идеей.

Есть ли какой-либо другой способ / цель использования взвешенной записи в маршруте 53.

Большое вам спасибо за рассмотрение моего вопроса!

Другой вариант использования, который следует рассмотреть, — это A / B тестирование интерфейсных или серверных служб. Позвольте мне проиллюстрировать: допустим, мы только что протестировали CI-версию 1.0.1 нашего веб-приложения (которое работает в контейнере Docker), и мы развернули контейнер, но мы еще не направляем к нему трафик. Мы не хотим переключать переключатель и немедленно сбрасывать наш миллион ежедневных активных пользователей (woohoo!) на версию v1.0.1, пока мы не сможем провести небольшое тестирование в реальном мире. Поэтому мы решили использовать взвешенную циклическую балансировку нагрузки, доступную в Route 53, чтобы отправить 0,25% наших пользователей в контейнеры версии v1.0.1, что позволит нам протестировать новую версию с реальными пользователями, прежде чем переключать переключатель. Мы можем сделать то же самое практически с любой службой, которая использует поиск по имени хоста для поиска ресурсов.

Одним из вариантов использования может быть использование его для балансировки нагрузки внутренних служб, которые не могут быть сбалансированы с помощью эластичного балансировщика нагрузки, например, реплик чтения rds или эластичного кэша, поэтому вместо создания экземпляра ec2 с помощью haproxy, например, для балансировки нагрузки ваших служб, вы можете создать балансировщик уровня Route 53на основе весов или задержек.

Я предполагаю, что внутренне они используют пользовательский балансировщик нагрузки на DNS-сервере, который балансирует запросы на основе псевдонимов домена и выбранной политики балансировки.