CDN
Тема дорожной карты · Backend разработчик
CDN (Content Delivery Network — сеть доставки содержимого) — глобально распределённая сеть граничных серверов, кеширующих и доставляющих статические ресурсы — JavaScript-бандлы, CSS, изображения, шрифты, видеосегменты — из мест, физически близких к конечным пользователям, резко снижая задержку и разгружая трафик к серверу-источнику. CDN незаменимы для бэкенд-архитекторов, создающих высоконагруженные приложения: доставляя ресурсы с граничных узлов, CDN поглощает большинство HTTP GET-запросов до того, как они достигают источника, позволяя бэкенд REST API сосредоточиться на динамических, аутентифицированных нагрузках, а не на доставке статических файлов. Современные CDN (Cloudflare, Fastly, AWS CloudFront) также предоставляют граничные возможности: терминирование TLS, поддержку HTTP/2 и HTTP/3, защиту от DDoS и ограничение частоты запросов на сетевом уровне, добавляя слой безопасности перед Kubernetes-кластерами. Инвалидация кеша — главная операционная задача CDN — версионированные имена файлов ресурсов (суффиксы content-hash, генерируемые CI/CD-инструментами сборки) устраняют проблемы с устаревшим кешем, тогда как ответы API, различающиеся по пользователю, должны использовать Cache-Control: private или полностью обходить CDN. Конфигурация CDN управляется как Infrastructure as Code (IaC) через Terraform-провайдеры для Cloudflare или AWS, гарантируя, что граничные правила, настройки источника и политики кеширования версионируются и развёртываются через тот же автоматизированный пайплайн, что и бэкенд-сервисы.
Как это работает
CDN бывает вертикальным (более мощная машина) — до лимитов одной, потом горизонтальным (больше машин за балансировщиком). Stateless-сервисы масштабируются горизонтально тривиально; stateful (БД, очереди) — через primary-replica репликацию, шардинг или оба. Read-реплики поглощают read-нагрузку; write-throughput требует либо больший primary, либо шардинг, либо хитрости (CQRS + eventual-consistency reads). Агрессивно кешируйте на границе (CDN), на app-слое (Redis), внутри процесса.
Когда применять
Сначала вертикально — самое дешёвое и наименее болезненное операционно. Read-реплики — когда primary DB тратит > 50% CPU на чтения. Шардируйте только когда ни один primary не справляется с write rate (эта точка дальше, чем думают — Postgres держит 10k+ writes/sec с тюнингом). CDN — для любого публичного статичного или редко-меняющегося контента; выигрыш в latency обычно 5-10×.
Типичные ошибки
Ловушки CDN: расчёт, что горизонтальное масштабирование решит всё (нет для stateful); преждевременный шардинг (необратимо без огромных миграций); игнор pooling — 1000 app-pod'ов по 10 соединений валят БД; не нагружаете до решений о масштабе (тюните не тот слой). Сначала меряйте, потом масштабируйте, потом документируйте.