Спроектируйте стратегию маршрутизации трафика пользователей из разных географических регионов к ближайшему работоспособному региональному развёртыванию сервиса (глобальный балансировщик, DNS-based failover или anycast). Обсудите компромиссы — единственно верного решения нет.

Короткий ответ

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

Как это работает подробнее

DNS-based маршрутизация направляет клиента на ближайший/здоровый регион через ответ DNS-резолвера, но ограничена кэшированием DNS-записей на стороне клиентов (TTL), из-за чего переключение при сбое не мгновенно для всех пользователей; anycast-балансировщик объявляет один и тот же IP-адрес из нескольких точек присутствия провайдера, и сетевая маршрутизация сама направляет пакет в ближайшую живую точку практически без задержки на переключение.

Пример кода

example.txtКопировать

DNS geo-routing:
  api.example.com -> eu-west-1 LB (для Европы, health check каждые 30с, TTL 60с)
                   -> us-east-1 LB (для Америки)
  При падении eu-west-1 health check помечает запись unhealthy,
  DNS начинает отдавать us-east-1, но полное распространение занимает до нескольких минут
Anycast LB:
  Единый IP объявляется из точек присутствия в нескольких регионах,
  переключение на ближайшую живую точку происходит на уровне сетевой маршрутизации

Что использовать на практике

• Рекомендация. для сервисов, где секунды-минуты задержки обнаружения сбоя приемлемы, DNS-based geo-routing с коротким TTL и health check — практичное и недорогое решение; для сервисов с требованием почти мгновенного переключения anycast-балансировщик провайдера снимает проблему TTL ценой большей зависимости от конкретного провайдера и обычно более высокой стоимости.
• Проверка. учебный тест отказа одного региона должен показать фактическое время, за которое основная доля трафика переключается на здоровый регион, и это время нужно сравнить с согласованным RTO, а не предполагать его.
• Компромисс. DNS-based маршрутизация проще, дешевле и не привязывает к специфичной инфраструктуре провайдера, но даёт менее предсказуемое и более медленное переключение из-за кэширования; anycast/глобальный балансировщик даёт быстрое и предсказуемое переключение, но увеличивает стоимость и зависимость от конкретного провайдера — решение должно явно основываться на требуемом RTO для пользовательского трафика и готовности команды к vendor lock-in, а не приниматься по умолчанию.

Подводные камни

• Риск. ставить длинный TTL на DNS-записи «для экономии на DNS-запросах», что делает failover видимым для части пользователей только спустя долгое время
• Риск. полагаться на DNS-failover, но не тестировать его регулярно
• Риск. не учитывать, что часть клиентов с агрессивным кэшированием резолвера может игнорировать TTL дольше ожидаемого.