CDN: операции и observability

Вы задеплоили hotfix в 3 часа ночи. Origin обновлён. Но через 20 минут 40% пользователей по-прежнему на старой версии — разные CDN-регионы в разных состояниях кеша, устаревший edge в Азиатско-Тихоокеанском регионе раздаёт вчерашние данные, а мониторинг показывает только агрегированные частоты ошибок, выглядящие нормально. CDN-инциденты невидимы — пока не становятся видимыми.

Cache-tag purge: точечная инвалидация в масштабе

Для сайта с тысячами URL (новостной издатель, e-commerce каталог) purge по URL операционно неуправляем. Cache tags (Cloudflare Enterprise, Fastly) решают это:

1. Origin устанавливает Cache-Tag: article-1001, category-tech на ответы статей.
2. При редактировании статьи CMS вызывает POST /cdn/purge {"tag": "article-1001"}.
3. CDN инвалидирует все закешированные ответы с этим тегом — по всем POP, за секунды.
4. Тег категории позволяет почистить все статьи категории (tag: category-tech) одним API-вызовом.

Без cache tags: каждое редактирование вызывает O(URL) purge-вызовов. С cache tags: каждое редактирование — O(тегов) вызовов, обычно 1–5.

Multi-CDN управление трафиком

Крупные операторы (Netflix, Apple, крупные новостные сайты) одновременно используют два и более CDN для:

• Устойчивость к отказу вендора: отказ одного CDN не роняет сайт.
• Региональная оптимизация: у одного CDN может быть лучший пиринг в Азии, у другого — в Латинской Америке.
• Коммерческие рычаги: конкурирующие CDN-контракты снижают стоимость за ГБ.

Механизм управления: DNS-based steering (NS1 Pulsar, Cedexis Openmix, кастомный). Агрегируют real-user-monitoring (RUM) данные и обновляют DNS-записи каждые несколько секунд, направляя к наиболее производительному CDN по региону. DNS TTL: 30 с для быстрой реакции на управление.

Цена: операционная сложность. Purge, заголовки и код edge-worker должны работать идентично на каждом CDN. Purge, отправленный в CDN A, не очищает CDN B автоматически — каждый требует собственного API-вызова.

BGP-оптимизация: Argo и Global Accelerator

Anycast выбирает POP, ближайший по BGP, а не по задержке. На межконтинентальных путях «ближайший по BGP» и «наименьшая задержка» существенно расходятся.

Cloudflare Argo Smart Routing и AWS Global Accelerator непрерывно измеряют реальную end-to-end задержку со всех POP и направляют трафик через приватный backbone (не публичный интернет) к POP с наименьшей задержкой. Типичная экономия: 30–50% снижение p95-задержки на межконтинентальных путях. Цена: повышенная стоимость за ГБ за backbone-транзит. Оправдано для latency-sensitive API; обычно избыточно для доставки статических ассетов, где BGP уже эффективен.

mTLS edge-to-origin. Даже с Anycast, скрывающим IP origin, атакующие могут обнаружить его через историю DNS, certificate transparency logs или неправильно настроенные пути прямого доступа. mTLS (mutual TLS): origin принимает соединения только если клиент предъявляет сертификат CDN. Без CDN-сертификата прямые запросы к origin отклоняются — раскрытие origin IP больше не имеет значения.

WAF и управление ботами на edge

CDN стоят на пути всего трафика — что делает их самым дешёвым слоем защиты от атак:

• WAF (Web Application Firewall): сопоставляет паттерны запросов с наборами правил OWASP Top 10 (SQL injection, XSS, path traversal, command injection). Блокировка за <1 мс на edge, без участия origin.
• Управление ботами: TLS-фингерпринтинг JA3/JA4 (фингерпринт TLS ClientHello), поведенческий анализ, IP-репутация для различения человеческого и автоматизированного трафика. Блокирует credential stuffing, парсинг и злоупотребление API.
• Rate limiting: по IP, по токену, по маршруту. Конфигурируется на edge; выполняется без round-trip к origin.
• DDoS scrubbing: объёмные атаки (L3/L4) поглощаются на edge до достижения origin. Anycast-сеть Cloudflare охватывает 330+ городов, распределяя атакующий трафик по всем POP.

103 Early Hints

RFC 8297 определяет информационный ответ 103 Early Hints, отправляемый до финального 200 OK. Edge может отправить Link: </style.css>; rel=preload в ответе 103, пока origin генерирует основной HTML. Браузер начинает загружать критические ассеты до прихода HTML, экономя один RTT из критического пути рендеринга. По состоянию на 2026: 93% поддержки браузерами, ~5% реального использования. Vercel лидирует с ~2.8%; Cloudflare и Fastly ниже 1%. Трение при внедрении: edge должен знать, какие ресурсы подсказывать для каждой страницы — без поддержки фреймворка автоматизировать сложно.

Ключевые метрики observability

CDN-инцидент часто начинается как дрейф метрик до появления жалоб пользователей:

Экспортируйте из CDN-дашбордов в Prometheus/OTel для SLO-алертинга. Нативные CDN-дашборды (Cloudflare Analytics, Fastly Real-Time) полезны для углублённого анализа, но не для кросс-CDN корреляции.

$ curl -I https://example.com/article/123
HTTP/2 200
date: Wed, 13 May 2026 14:33:00 GMT
content-type: text/html; charset=utf-8
cache-control: public, max-age=3600
cf-cache-status: MISS
vary: User-Agent, Accept-Encoding, Cookie, Authorization
age: 0
server: cloudflare