CDN и Anycast: как edge-сеть снижает latency

⚙️ Теория

🌍 CDN как распределенный edge-слой

CDN размещает контент и compute-близко к пользователю (edge/PoP), чтобы:

сократить RTT и время первого байта;
снизить нагрузку на origin;
повысить устойчивость к локальным сбоям.

Типовой путь запроса:

Клиент обращается к домену.
DNS/маршрутизация направляет его в edge PoP.
При cache hit ответ формируется на edge.
При cache miss запрос идет к origin (или к вышестоящему cache-tier).

📡 Что такое Anycast в терминах RFC

RFC 4786 определяет anycast как модель, где один и тот же IP-префикс анонсируется из нескольких локаций, а трафик идет по BGP к "наиболее близкой" в маршрутизационном смысле точке.

Важно:

"близкий" в anycast не означает географически ближайший;
выбор пути зависит от BGP-политик и состояния межсетевой связности.

🧱 Почему CDN часто строится на Anycast

Anycast дает естественные свойства для edge-сети:

быстрый вход в ближайший PoP;
распределение трафика по множеству площадок;
быстрая реакция при деградации площадки (через изменение анонсов/маршрутов).

В CDN это сочетается с кэшированием и tiered-архитектурой, поэтому уменьшается и latency, и pressure на origin.

⚖️ Ограничения, о которых часто забывают

По RFC 4786 и практикам эксплуатации:

anycast не гарантирует равномерный load balancing по площадкам;
long-lived stateful-сессии чувствительны к route change (поток может попасть в другой PoP);
инциденты нужно анализировать с учетом региональной маршрутизации, а не только глобальных метрик.

❓ Что нужно уметь объяснить

Почему Anycast не равно "магический глобальный балансировщик"?

Потому что распределение задается BGP-путями и политиками провайдеров, а не централизованным алгоритмом layer 7.
Можно получить перекос нагрузки, если маршрутизационная топология несимметрична.

Почему CDN улучшает отказоустойчивость origin?

Кэш на edge гасит значительную долю чтений, а трафик распределен по PoP.
В результате кратковременные деградации origin реже превращаются в глобальный инцидент.

Где основные риски при внедрении?

неправильная cache-policy (перекэширование динамики или отсутствие кэша там, где он нужен);
отсутствие защиты origin (rate limiting/WAF на edge и ограничение прямого доступа к origin);
слабая observability по регионам и ASN.

🧪 Практика

1. Проверьте DNS-поведение и TTL

dig +nocmd example.com A +noall +answer
dig +nocmd example.com AAAA +noall +answer

Смотрите:

TTL;
используемые edge IP;
согласованность ответов между резолверами.

2. Проверьте путь до anycast IP из разных точек

mtr -rwzbc 50 <edge-ip>
traceroute <edge-ip>

Сравнивайте:

задержку;
AS-path/узлы;
стабильность маршрута по регионам.

3. Проверьте cache hit/miss на edge

curl -I https://example.com/static/app.js
curl -I https://example.com/static/app.js

Проверьте заголовки CDN-платформы (cache-status/age и эквиваленты), чтобы убедиться, что объект реально кэшируется.

4. Протестируйте деградационный сценарий origin

Минимальный сценарий:

ограничить доступность части origin-инстансов в test/stage;
проверить, что edge продолжает обслуживать горячий контент из кэша;
зафиксировать поведение latency/error-rate по регионам.

🧾 Вывод

CDN + Anycast дают выигрыш по latency и resiliency, но это не "самонастраивающаяся магия".
Нужны:

корректная cache-стратегия,
явная защита origin,
региональная сетево-прикладная observability,
регулярная проверка деградационных сценариев.