Anycast не лечит все: где архитектура помогает, а где только маскирует проблему

Anycast не лечит все: где архитектура помогает, а где только маскирует проблему

Anycast часто продают как универсальный ответ на DDoS, отказ узла и низкую задержку. На практике это всего лишь способ анонсировать один и тот же IP из нескольких точек. Дальше начинается инженерия: BGP-политики, фильтрация префиксов, контроль состояния нод и дисциплина в операциях.

Мифы обычно одинаковые:
— «Запрос всегда попадет в ближайший узел». Нет: маршрут выбирает сеть, а не география.
— «Отказ одного POP незаметен». Нет: при флапе вы получите сдвиг трафика, а иногда и каскадный эффект.
— «Anycast сам балансирует нагрузку». Нет: без health-check и корректного withdrawal один узел может быть перегрет, а другой — простаивать.

Реальность проще и жестче. Anycast хорош там, где важны отказоустойчивость и сокращение RTT при stateless-сервисах, включая DNS. Но он плохо переносит сессии, требует одинакового конфигурационного состояния на всех нодах и аккуратной работы с TTL, очередями запросов и лимитами по UDP/TC. Иначе вы получите не распределенную систему, а географически размазанный инцидент. 🔧

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