System Design
CDN (Content Delivery Network)
В 2012 году запуск Diablo III вызвал такой трафик, что серверы Blizzard легли на 8 часов - вся нагрузка шла напрямую на origin. Netflix решил эту проблему иначе: компания разместила собственные серверы Open Connect прямо в датацентрах провайдеров, и теперь более 95% трафика Netflix никогда не покидает сеть провайдера. Разница между CDN и его отсутствием - это разница между глобальным стримингом и глобальным сбоем.
- **Netflix Open Connect:** 17 000 собственных CDN-серверов размещены прямо в датацентрах ISP - 95% трафика не покидает сеть провайдера
- **Cloudflare:** более 300 PoP в 100+ странах, edge cache держит 80% запросов без единого round-trip до origin
- **Diablo III launch (2012):** без CDN весь трафик шёл на единственный origin Blizzard - серверы легли на 8 часов, миллионы пользователей не смогли войти
- **GitHub Pages:** статика деплоится в Fastly CDN автоматически - первый byte за 15 мс в любой точке мира без single-server bottleneck
Цели урока
- Понимать, почему CDN критичен для глобальных приложений
- Знать архитектуру CDN: PoP, Edge, Origin, Anycast
- Различать Pull и Push CDN
- Уметь настраивать Cache-Control headers
- Знать стратегии инвалидации: content hash, purge, versioned URLs
Предварительные знания
- Понимание HTTP и кеширования
- Базовое понимание DNS
Зачем нужен CDN
**CDN (Content Delivery Network)** - географически распределённая сеть серверов, которая доставляет контент пользователям из ближайшей точки. Главная цель: уменьшить latency.
Свет в оптоволокне идёт со скоростью 200,000 км/с. Москва → Нью-Йорк = 100ms round-trip. Это физический предел, который CDN обходит.
- Netflix использует Open Connect - собственный CDN с серверами у провайдеров
- Cloudflare обрабатывает ~20% мирового интернет-трафика
- Без CDN сайт из USA открывается в Москве за 2-3 секунды
| Маршрут | Round-trip time | С CDN |
|---|---|---|
| Москва → Москва | ~1 ms | ~1 ms |
| Москва → Амстердам | ~30 ms | ~5 ms (edge) |
| Москва → Нью-Йорк | ~100 ms | ~5 ms (edge) |
| Москва → Сидней | ~300 ms | ~5 ms (edge) |
Загрузка страницы с 50 ресурсами
Как CDN ускоряет загрузку
Без CDN (origin в USA): • 50 ресурсов × 100ms = 5 секунд • Пользователь уходит через 3 секунды С CDN (edge в Москве): • 50 ресурсов × 5ms = 250 ms • Страница загружается мгновенно Улучшение: 20x!
Почему CDN уменьшает latency?
Как работает CDN
CDN состоит из множества **PoP** (Point of Presence) - дата-центров по всему миру. Каждый PoP содержит **edge серверы**, которые кешируют контент.
Ключевые компоненты
| Компонент | Роль | Пример |
|---|---|---|
| PoP | Дата-центр близко к пользователям | Cloudflare: 300+ PoPs |
| Edge Server | Кеширует и отдаёт контент | Nginx/Varnish |
| Origin | Источник правды, ваш сервер | AWS, DigitalOcean |
| Anycast | Один IP → ближайший сервер | Роутинг на уровне BGP |
**Anycast**: Один IP-адрес объявляется из всех PoPs. BGP автоматически направляет пакеты к ближайшему. Это как "любой из этих серверов может ответить".
Что такое PoP в контексте CDN?
Push vs Pull CDN
Как контент попадает на edge серверы? Два подхода: **Pull** (lazy) и **Push** (eager).
Pull CDN (Lazy Loading)
Push CDN (Eager Loading)
| Критерий | Pull | Push |
|---|---|---|
| Первый запрос | Медленный (miss) | Быстрый |
| Сложность | Простой | Сложнее |
| Контроль | Меньше | Полный |
| Use case | Статика сайта | Видео, премьеры |
**Pull CDN** подходит для 95% случаев. Push нужен для критичного контента: премьеры фильмов, live events, где первый запрос должен быть быстрым.
Когда лучше использовать Push CDN?
Cache-Control Headers
CDN слушает HTTP headers от origin. **Cache-Control** - главный инструмент управления кешированием.
| Директива | Значение | Когда |
|---|---|---|
| max-age | TTL в секундах | Основной способ |
| s-maxage | TTL для CDN (shared cache) | CDN TTL ≠ Browser TTL |
| public | Можно кешировать на CDN | Shared content |
| private | Только browser cache | User-specific данные |
| no-store | Не кешировать вообще | Секретные данные |
| immutable | Контент не изменится | Статика с версией |
| stale-while-revalidate | Отдать stale, обновить async | Баланс speed/freshness |
**Set-Cookie** в ответе = CDN не кеширует! Если нужны cookies и кеш - используй отдельные endpoints или Vary header.
Чем отличается max-age от s-maxage?
Инвалидация на CDN
Как обновить контент на 300+ edge серверах по всему миру? Несколько стратегий.
Content Hash (Best Practice)
Cache Purge API
Versioned URLs
**Best Practice для статики**: Content hash (app.abc123.js) + max-age=1year + immutable. Никогда не нужен purge - просто меняется имя файла.
| Метод | Скорость | Сложность | Use case |
|---|---|---|---|
| Content Hash | Мгновенно | Средняя | JS/CSS (build tools) |
| Purge API | Секунды-минуты | Простая | Изображения, редкие update |
| Versioned URL | Мгновенно | Простая | Когда нет build system |
Почему content hash (app.abc123.js) лучше, чем query string (app.js?v=123)?
Ключевые выводы
- **CDN** уменьшает latency за счёт географической близости
- **Pull CDN** - lazy caching, подходит для большинства
- **Cache-Control** - главный инструмент управления кешем
- **s-maxage** позволяет CDN кешировать дольше браузера
- **Content hash** в URL - best practice для статики
- **Purge API** для экстренной инвалидации
Связанные темы
CDN часть инфраструктуры доставки
- Кеширование — CDN = edge cache, один из уровней
- Load Balancer — CDN включает geo-load balancing
- Message Queue — Async обновление контента на CDN
Вопросы для размышления
- CDN кеширует статический контент эффективно, но плохо подходит для персонализированных ответов. Какие архитектурные паттерны позволяют обслуживать миллионы уникальных пользователей с CDN в цепочке?
- При инвалидации CDN по URL возникает проблема: старые клиенты продолжают слать запросы на старые URL. Как решается эта проблема в production - cache-busting, versioned URLs, или Surrogate-Key?
- CDN добавляет промежуточный узел в сеть доставки. В каких сценариях CDN ухудшает latency, а не улучшает её - и как это диагностируется?