Облачные вычисления
DNS и Route 53
В 2019 году крупнейший DNS-провайдер Cloudflare допустил глобальный сбой из-за ошибки в regex-правиле WAF - 30 минут весь их трафик шёл в никуда. Route 53 с SLA 100% и встроенным failover спроектирован так, чтобы DNS никогда не был single point of failure. Понимание его routing policies и health checks - разница между 99.9% и 99.99% uptime.
- **Amazon.com** использует Route 53 Latency-based routing для автоматического направления пользователей к ближайшему региону - без этого каждый запрос из Токио шёл бы в us-east-1, добавляя 150 мс задержки
- **Shopify** применяет Geolocation routing для соответствия региональным законодательствам: европейские магазины обслуживаются из EU-регионов, что упрощает соответствие GDPR
- **Netflix** настраивает Weighted routing для постепенного переноса трафика при деплое новых версий: начиная с 1% нового региона и увеличивая до 100% без даунтайма
Hosted Zones и DNS-записи
DNS - это телефонная книга интернета, и Route 53 - самая надёжная реализация этой книги: SLA 100% availability, что является единственным таким обещанием у AWS. **Hosted Zone** в Route 53 - это контейнер DNS-записей для домена. Публичная hosted zone отвечает на запросы из интернета, приватная - только внутри указанных VPC. Ключевое отличие Route 53 от обычных DNS: **Alias-записи** позволяют указать на ресурс AWS (ALB, CloudFront, S3) без IP-адреса, и AWS обновляет их автоматически при смене IP ресурса.
Alias vs CNAME: CNAME не работает на apex-домене (example.com), Alias - работает. Alias-запросы бесплатны (в отличие от обычных A/CNAME запросов). Поддерживаемые записи: A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, TXT, CAA, DS, NAPTR. TTL влияет на скорость распространения изменений - чем меньше TTL, тем быстрее failover.
Почему Alias-запись предпочтительнее CNAME для указания на ALB в apex-домене (example.com)?
Routing Policies
Route 53 умеет не просто хранить IP-адреса, а принимать решения. Шесть политик маршрутизации превращают DNS в интеллектуальный контроллер трафика. **Weighted routing** распределяет запросы пропорционально: вес 80 и 20 означают 80% и 20% трафика - идеально для canary-деплоя без изменения приложения. **Geolocation routing** направляет европейских пользователей к EU-серверам, американских - к US. GDPR требует, чтобы данные европейцев хранились в Европе - Route 53 Geolocation это обеспечивает на уровне DNS.
Политики маршрутизации: Simple (один ресурс), Weighted (процентное распределение), Latency-based (наименьшая задержка к региону), Failover (active/passive), Geolocation (по стране/континенту), Geoproximity (по расстоянию с bias-коррекцией), Multivalue Answer (до 8 IP с health checks). Latency-based и Geoproximity требуют Traffic Flow (дополнительная стоимость от USD 50/месяц).
Приложение должно соответствовать GDPR: пользователи из ЕС должны попадать на серверы в eu-west-1. Какая routing policy Route 53 подходит?
Health Checks
DNS без health checks - это как навигатор, который ведёт на закрытую дорогу. Route 53 health checks - это распределённая система мониторинга: более 15 проверяющих узлов AWS по всему миру отправляют HTTP/HTTPS/TCP-запросы к ресурсу каждые 10-30 секунд. Ресурс считается недоступным, когда более 18% проверяющих узлов фиксируют сбой. Это предотвращает ложные срабатывания из-за локальных сетевых проблем одного узла.
Три типа health checks: Endpoint (HTTP/HTTPS/TCP к IP или домену), Calculated (комбинация нескольких health checks через AND/OR/NOT), CloudWatch Alarm (состояние метрики). Endpoint health checks могут проверять строку в теле ответа (до 5120 байт). Стоимость: USD 0.50/месяц за endpoint в AWS-регионах, USD 1.00/месяц для не-AWS ресурсов.
Сервис считается недоступным в Route 53, когда проверяющие узлы фиксируют сбой. При каком пороге это происходит?
DNS Failover
Route 53 Failover routing - это автоматический переключатель, который срабатывает без участия человека. Схема active/passive: основной (primary) ресурс обслуживает трафик, резервный (secondary) молчит до сбоя. Когда health check primary фиксирует проблему, Route 53 начинает возвращать IP secondary - но TTL замедляет переключение. Правило: TTL активной записи должен быть минимальным (60 секунд или меньше) в продакшене с критичными SLA.
Active/active failover достигается через Weighted или Multivalue routing с health checks: все узлы активны, нездоровые автоматически исключаются из ответов. Это не то же самое, что Failover routing (active/passive). Время переключения = время обнаружения health check (30-90 сек) + TTL. При TTL=60 сек минимальный downtime около 2 минут.
DNS Failover обеспечивает мгновенное переключение трафика при сбое
Переключение занимает минимум 30-90 секунд (health check) плюс TTL, в течение которого клиенты держат старый IP в кеше
DNS кешируется на уровне клиентов, резолверов ISP и OS. Даже после изменения записи в Route 53 клиенты продолжают использовать старый IP до истечения TTL. Решение - минимальный TTL в продакшене.
Какой параметр DNS-записи наиболее критичен для минимизации времени переключения при Failover routing?
Ключевые идеи
- **Alias-записи** - расширение Route 53, работающее на apex-домене и бесплатное для ресурсов AWS; всегда предпочтительнее CNAME для AWS-ресурсов
- **Routing Policies** превращают DNS в контроллер трафика: Weighted для canary, Geolocation для GDPR, Latency-based для производительности, Failover для катастрофоустойчивости
- **TTL - критический параметр**: маленький TTL (60 сек) ускоряет failover и canary, большой (86400 сек) снижает нагрузку на DNS-серверы, но замедляет реакцию на изменения
Связанные темы
Route 53 является входной точкой для всей инфраструктуры AWS:
- Load Balancing и CDN — ALB и CloudFront - основные цели Alias-записей Route 53; Failover routing переключает между ними при сбоях
- VPC и сетевая изоляция — Приватные hosted zones работают только внутри VPC, обеспечивая DNS-резолюцию для внутренних сервисов
Вопросы для размышления
- Приложение развёртывается в двух регионах AWS. Как настроить Route 53 для автоматического переключения трафика при отказе основного региона, и какой минимальный TTL стоит установить?
- Weighted routing используется для canary-деплоя. Как постепенно увеличивать вес новой версии и как откатиться за 60 секунд при обнаружении проблемы?
- Geolocation и Latency-based routing иногда дают разные результаты для одного и того же пользователя. Какая политика приоритетнее для глобального SaaS-продукта и почему?