Постепенное перемещение трафика с помощью политики взвешенной маршрутизации AWS Route 53

🤔 Почему нужно менять трафик постепенно?

В программном обеспечении распространена миграция существующей службы в новую инфраструктуру, например перенос в облако. Бизнес-логика остается прежней, но это все же кардинальное изменение, поскольку новый стек сервисов будет находиться в новой инфраструктуре.

Мы можем использовать обширные интеграционные тесты, нагрузочные тесты и т. д., чтобы убедиться, что новый сервис работает должным образом, однако для критически важных сервисов по-прежнему более безопасным вариантом является постепенное переключение производственного трафика на новый стек сервисов, чтобы сервис владелец может убедиться, что новая служба также надежна и масштабируема безопасным и поэтапным способом, а также дает клиентам время для настройки, если это необходимо.

Вы можете подумать, что уже есть инструменты для этого сценария «постепенного переключения»; например, существует множество инструментов флагов функций, созданных собственными силами или от сторонних поставщиков, которые, вероятно, имеют такие функции, и в некоторых случаях это может быть правильным решением, особенно для экспериментов с новой функцией.

Но для других сценариев вы должны рассмотреть, является ли это правильным решением; увеличится ли задержка, которая может нарушить SLA вашего сервиса? Или могут ли инструменты обрабатывать уровень трафика для всего трафика, поступающего на службу? Или любые работы по очистке, которые вам нужно выполнить с флагом функции после переноса всего трафика.

Чаще всего, если нет плана поддерживать существующий стек сервисов, «перенаправление» трафика с помощью DNS-разрешения является обычным явлением, и именно этому будет посвящена эта статья (я также видел, как люди делали одноразовое переключение с помощью DNS). , но обычно это не рекомендуется из-за риска).

💡Как мы используем DNS для решения этой проблемы?

Прежде чем мы углубимся в детали использования AWS Route53, нам нужно немного больше узнать о DNS и AWS Route 53:

Amazon Route 53 – это высокодоступная и масштабируемая служба облачной системы доменных имен (DNS). Позволяет настраивать политики маршрутизации DNS для уменьшения задержки

Итак, как же работает DNS (система доменных имен)?

Короче говоря, DNS – это телефонная книга для преобразования удобного для человека доменного имени, например example.com, в машиночитаемый IP-адрес, например 192.0. .2.244.

Когда запрос инициирован, поиск DNS происходит в архитектуре разрешения имен иерархии, которая разрешает имя DNS с различными серверами имен.

Например, на приведенной выше диаграмме имя домена www.example.com сначала отвечает корневой DNS-сервер; затем сервер имен для домена верхнего уровня .com, когда он достигает сервера имен Route53, на котором есть запись для www.example.com.

Затем он возвращает машиночитаемый IP-адрес, чтобы клиент мог сделать запрос к хосту, а результат разрешения сильно кэшируется по этому пути.

Теперь, когда мы знаем, как работает DNS, давайте посмотрим, как реализовать его с помощью AWS Route53:

Сценарий A. Попросите клиентов использовать новый API-домен/URL

Если запросить у клиентов новый URL-адрес API несложно, то относительно просто добавить взвешенные записи политики маршрутизации. Вы делегируете новый домен из внутренней инфраструктуры компании или стороннего поставщика услуг; затем создайте новую (общедоступную) зону хостинга в Route53:

Нажмите на строку зоны размещения; вы должны увидеть запись NS (сервер имен) и запись SOA (начало полномочий), созданные автоматически.

В этом сценарии вам не нужно вносить изменения в эти записи; просто оставьте их как есть и знайте, что они являются административным типом информации для разрешения DNS. Мы поговорим об этом подробнее в другом сценарии.

Следующим шагом будет создание записей со взвешенной политикой маршрутизации:

После создания записи, указывающей на новую услугу (с весом 155), мы можем создать еще одну запись, указывающую на существующую услугу с весом 100; то мы должны увидеть эти две записи в размещенной зоне, как показано ниже:

После того, как это настроено, вы можете постепенно изменять конфигурацию веса, чтобы в конечном итоге новый стек служб мог получать весь трафик.

Сценарий Б. От клиентов не требуется никаких изменений для использования взвешенной записи

В действительности рабочие сервисы часто обслуживают широкий круг клиентов, и может быть сложно попросить каждого клиента использовать новый домен/URL API. К счастью, мы все еще можем контролировать, какие конечные точки используются клиентами за кулисами.

Чтобы понять, как работает этот подход, нам нужно понять, какова роль сервера имен:

Запись NS (или запись сервера имен) — это запись DNS, которая содержит имя авторитетного сервера имен в домене или зоне DNS. Когда клиент запрашивает IP-адрес, он может найти IP-адрес предполагаемого места назначения из записи NS с помощью поиска DNS.

Другими словами, сервер имен или DNS-сервер содержит все файлы и записи зоны DNS для домена. Как мы упоминали в сценарии A, при создании размещенной зоны в Route53 по умолчанию будут созданы запись NS и запись SOA. По сути, эти серверы имен знают все записи, которые вы создаете в этой размещенной зоне.

Как сделать так, чтобы клиенты использовали взвешенные записи, которые мы создаем в route53, без каких-либо изменений? Например, клиенты используют конечную точку medium.com.

Этот домен управляется какой-то внутренней инфраструктурой или сторонним инструментом, и вы можете получить соответствующую запись сервера имен с помощью этой команды:

dig medium.com +noall +answer NS

; <<>> DiG 9.10.6 <<>> medium.com +noall +answer NS
;; global options: +cmd
medium.com.  86400 IN NS alina.ns.cloudflare.com.
medium.com.  86400 IN NS kip.ns.cloudflare.com.

В этом случае мы хотим использовать сервер имен в Route53 вместо сервера имен Cloudflare, чтобы разрешение DNS проходило через Route53 вместо Cloudflare; тогда взвешенные записи, которые мы установили в зоне хостинга Route53, будут эффективными.

📝 Извлеченные уроки

• DNS сильно кэшируется; изменения не вступают в силу мгновенно, и после внесения изменений трафик будет задерживаться на некоторое время.

* Более короткий TTL для записей полезен для более легкого отката. После завершения переноса и отсутствия необходимости в откате вы можете изменить TTL обратно на значение по умолчанию или другое значение, которое вы считаете нужным.

* На этапе тестирования, если у вас настроен нагрузочный тест, помните, что хост будет разрешаться в одно из мест назначения записи. Используйте это в течение TTL, поэтому лучше запускать нагрузочные тесты с нескольких хостов и, возможно, дольше, чем TTL разрешения DNS. Вы можете увидеть трафик после весов разрешения DNS.

* Если домены в записи DNS не являются общедоступными, вы не можете использовать обычно используемую проверку работоспособности Route53, поскольку она требует, чтобы домен был общедоступным. Существуют и другие показатели, например показатели DNS-запросов, но если доступ к доменам возможен только внутри страны, лучше найти другие способы измерения работоспособности запроса.

* Чтобы сделать ваше приложение более отказоустойчивым, может помочь Route53 Application Recovery Controller (ARC), а AWS недавно выпустила функцию, называемую зональным сдвигом, которую вы можете использовать для устранения серых сбоев.

* Одна вещь, которую я заметил, это то, что если у вас есть настройка веса, когда 100% трафика идет на A, 0% трафика идет на B, теоретически вы не увидите, что трафик идет на B. Однако, если A не может быть разрешен, Route53 упадет. вернуться к другим записям, таким как B.

* При замене записи сервера имен, как описано в сценарии B, не забудьте заменить запись сервера имен одной операцией (добавить и удалить); в противном случае будет период времени, когда домен не может быть разрешен.

:::подсказка Если вам интересно узнать больше о DNS или сети в целом, этот курс Coursera от Google и этот курс Университета Колорадо дает вам обзор компьютерных сетей. Если вы предпочитаете книги, есть классическая книга по компьютерным сетям Компьютерные сети: нисходящий подход. Надеюсь, это поможет!

:::

:::информация Я составил и курировал список ресурсов для поиска работы для разработчиков программного обеспечения; он охватывает ресурсы для написания резюме, подачи заявлений о приеме на работу и управления ими, эффективных способов подготовки к собеседованиям по программированию и помощи в изучении дизайна системы. Вы можете загрузить бесплатный PDF-файл здесь.

:::