Балансировка DNS с помощью Amazon Route 53

Быстрые ссылки

• Как работает DNS‑балансировка нагрузки?
• Настройка Route 53

Балансировка нагрузки — это разделение запросов приложения или сети между двумя и более серверами для повышения производительности и времени доступности. Платные балансировщики AWS (ALB/NLB) упрощают задачу, но эквивалентное поведение можно реализовать бесплатно на уровне DNS с помощью Route 53.

Как работает DNS‑балансировка нагрузки

Традиционный балансировщик (например, Application Load Balancer) принимает весь входящий трафик и распределяет его между инстансами. По сути, балансировщик — это экземпляр с запущенным сетевым прокси (HAProxy/NGINX и т. п.), который обрабатывает большое количество соединений.

DNS‑балансировка использует тот факт, что перед установлением соединения клиент выполняет DNS‑запрос для разрешения имени хоста в IP. Route 53 возвращает разные IP‑адреса (или ресурсы) в ответе DNS в соответствии с выбранной политикой маршрутизации. Например, при взвешенной политике одному пользователю будет возвращён IP сервера 1, другому — сервера 2, при учёте весов и статуса проверок работоспособности.

Важно: DNS‑балансировка распределяет имена/адреса на уровне разрешения имен. Если клиент кэширует ответ или использует длительное соединение, поведение будет зависеть от времени жизни записи (TTL) и поведения приложения.

Когда стоит выбирать DNS‑балансировку

• Нужно простое, бюджетное распределение нагрузки между несколькими независимыми серверами.
• Приложение статично и не требует сложного соединительно‑ориентированного проксирования (persistence, WebSocket, TCP‑уровень с сохранением сессии).
• Требуется геораспределённая маршрутизация или отказоустойчивость между регионами.

Важно: DNS‑балансировка не заменяет балансировщик на уровне L4/L7, если вам нужны: сессии с привязкой, SSL‑терминация с управлением сертификатами, интеллектуальная маршрутизация на основе URL/заголовков или быстрый failover без DNS‑TTL задержек.

Ограничения и случаи, когда это не сработает

• Клиенты строго кэшируют DNS и игнорируют низкий TTL — распределение будет неравномерным.
• Для real‑time приложений (WebSocket, gRPC) и высоких требований к сохранению сессии лучше использовать ALB/NLB.
• DNS‑ответы могут кэшироваться посредниками (ISP, CDN), что замедляет реакцию на переключение на запасной сервер.
• Для TCP/SSL‑сценариев с глубоким инспектированием трафика DNS не даёт контролируемой маршрутизации.

Настройка Route 53 — пошаговая инструкция

1. Войдите в консоль Route 53.
2. В боковой панели выберите Health Checks и создайте новую проверку работоспособности.
   • Health Check — это URL или IP, который Route 53 будет проверять.
   • Для проверки отдельного сервера используйте Elastic IP (если он привязан).
   • Примечание: Health Checks в Route 53 платные (в исходном примере — $0.50 в месяц за проверку); они опциональны, но рекомендуются для автоматического исключения непригодных инстансов.

3. Повторите создание Health Check для каждого сервера, который будет участвовать в балансировке.

4. В боковой панели выберите Hosted Zones и откройте Hosted Zone для вашего домена.

5. Создайте или отредактируйте запись типа A (или Alias на AWS‑ресурс) и укажите IP одного из серверов.

   • При использовании Alias вы можете динамически сопоставлять запись с ресурсами AWS (например, с IP-адресом ELB).

6. Выберите политику маршрутизации:

   • Weighted (Взвешенная) — назначьте вес записям; веса определяют вероятность выбора. Установите одинаковые веса (например, 1) для равномерного распределения.
   • Failover (Отказоустойчивость) — помечайте записи как Primary и Secondary; Route 53 будет переключать трафик при падении Primary и успешной проверке Secondary.

7. Ассоциируйте запись с соответствующей Health Check: выберите “Yes” для Associate With Health Check и укажите ранее созданную проверку. Если Health Check возвращает недоступность, запись исключается из выбора.

8. Сохраните запись и повторите для всех серверов.

9. Для Failover: при создании записи укажите маршрут Failover и пометьте её как Primary или Secondary, а также укажите соответствующую Health Check.

После сохранения Route 53 начнёт отвечать DNS‑запросами в соответствии с выбранной политикой.

Практические рекомендации по параметрам

• TTL: для более гибкого переключения используйте небольшой TTL (например, 60–300 сек). Низкий TTL снижает эффект кэширования, но увеличивает нагрузку на DNS‑сервер.
• Взвешивание: используйте веса для постепенного вывода/ввода инстансов (canary deployments) или для распределения нагрузки между нодами разной мощности.
• Health Checks: проверяйте не только 200 OK, но и критические пути (запросы к базе данных, ответы приложения), чтобы избежать «здоровых» но нефункциональных инстансов.

Контрольные списки и роли

Проверочный список для инженера инфраструктуры:

• Создать Health Check для каждого инстанса.
• Настроить записи A/alias в Hosted Zone.
• Назначить политику маршрутизации и задать Set ID/вес.
• Ассоциировать записи с соответствующими Health Checks.
• Установить TTL, соответствующий SLA.
• Проверить поведение при падении сервера (тестовый сценарий).

Чеклист для SRE/операций:

• Настроить мониторинг и алёрты по Health Checks.
• Документировать порядок переключения и rollback
• Тестировать переключение в период низкой нагрузки

Мини‑методология для миграции на Route 53

1. Создайте Health Checks и DNS‑записи в тестовом поддомене (test.example.com).
2. Проведите нагрузочное тестирование с разными TTL и проверками.
3. Постепенно перенаправляйте трафик (canary) с помощью взвешенных записей.
4. После успешного теста переключите основной домен и наблюдайте метрики.

Как проверить и какие тесты сделать

• Acceptance тесты:

  • При симуляции падения Primary Health Check удаляет запись из ответов DNS.
  • Клиенты получают IP‑адрес серверов в соответствии с весами при множестве запросов.
  • TTL влияет на время видимой смены адреса у реальных клиентов.

• Тесты приёмки:

  • Генерируйте DNS‑запросы с разных сетей и проверяйте распределение.
  • Задержите Health Check (искусственно снизьте доступность) и проверьте переключение.

Как выбрать между Route 53 и классическим балансировщиком

flowchart LR
  A[Требуется балансировка] --> B{Нужны ли L7-фичи?}
  B -- Да --> C[Использовать ALB/NLB]
  B -- Нет --> D{Требуется мгновенный failover без DNS кеширования?}
  D -- Да --> C
  D -- Нет --> E[Использовать Route 53 'Weighted/Failover']

Альтернативные подходы

• Application Load Balancer (ALB): для HTTP/HTTPS с L7‑правилами, SSL‑терминацией, sticky sessions.
• Network Load Balancer (NLB): для высокопроизводительных TCP/UDP нагрузок с минимальной задержкой.
• CDN + Origin failover: если основная цель — доставка статического контента и геораспределённость.

Безопасность и приватность

• Health Checks выполняются из сетей Route 53 — убедитесь, что firewall/ACL разрешают запросы от IP‑диапазонов проверок (документация AWS содержит список).
• Не публикуйте внутренние IP в публичных DNS, если это противоречит политике безопасности; используйте приватные Hosted Zones для внутренних доменов.

Критерии приёмки

• Для взвешенной конфигурации: при 10 000 DNS‑запросах распределение близко к установленным весам.
• Для failover: при отказе Primary трафик перенаправляется на Secondary в разумный срок, учитывая TTL и кэширование.

Важно: проверяйте поведение клиентов и ISP — у разных резолверов поведение кэширования отличается.

Резюме

Route 53 предоставляет простой и экономичный способ распределять трафик между серверами с помощью DNS‑политик. Это хорошее решение для базовой балансировки и отказоустойчивости, но не заменит полнофункциональные балансировщики при требовании сложной логики L4/L7. Перед выбором подхода протестируйте поведение TTL и Health Checks в вашей сети.

Примечание: при настройке учитывайте стоимость Health Checks и характер кэширования DNS у клиентов.