Anycast не отменяет магию сети: мифы, которые ломают ожидания от архитектуры

Anycast не отменяет магию сети: мифы, которые ломают ожидания от архитектуры

Anycast — это не «один IP и всё само поедет». Это набор независимых точек входа, где BGP выбирает ближайшую с точки зрения политики и топологии площадку. Давайте разберем флоу запроса: клиент попадает не в «лучшую» ноду, а в ту, до которой маршрут сейчас короче и стабильнее.

Типовые мифы:
— Anycast всегда снижает RTT. Нет: иногда маршрут короче, иногда — с сюрпризом в виде асимметрии и транзита через лишний AS.
— Отказ одной площадки незаметен. Нет: при flap’ах и долгом сходе маршрутов часть клиентов упрется в кэш и таймауты.
— Состояние можно игнорировать. Нет: если сервис неидемпотентен или зависит от sticky-сессий, Anycast начинает спорить с прикладной логикой.

Реальность проще и жестче: нужна одинаковая конфигурация на всех узлах, предсказуемая фильтрация анонсов, health-checks, быстрый withdrawal и контроль за тем, как резолверы переживают смену маршрута. Проверим влияние на RTT и консистентность зон: плохой фейловер в DNS часто выглядит как проблема приложения, хотя корень — в маршрутизации.

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