CDN против раздачи со своего сервера: с какого объёма он окупается

MAATRIX

Рано или поздно у любого растущего проекта возникает один и тот же вопрос: подключать ли CDN или продолжать раздавать статику прямо со своего сервера. Маркетинг CDN-провайдеров говорит «подключайте всегда, это всегда быстрее» — и это неправда. У CDN есть реальная цена, а у собственной раздачи — реальные пределы. Ниже — честная методика, как посчитать, на какой стороне выгода именно для вашего трафика, без религии и без рекламных лозунгов.

Что CDN на самом деле даёт вам за деньги

CDN (Content Delivery Network, сеть доставки контента) — это множество узлов кэширования, географически раскиданных по миру. Когда пользователь из Джакарты запрашивает картинку с вашего сайта, а ваш сервер физически стоит в Лондоне, запрос без CDN идёт через полмира: десятки, а иногда сотни миллисекунд туда и обратно, потери пакетов на дальних магистралях, нестабильность маршрутов через несколько автономных систем. CDN решает это тем, что контент уже лежит закэшированным на узле в Сингапуре или Джакарте — пользователь получает его от ближайшей точки, а не от вашего сервера.

Второе, за что вы платите — это снятие нагрузки с собственного сервера в пиках. Если у вас вирусный пост, распродажа или внезапный наплыв трафика, CDN-узлы принимают основную массу запросов на статику (картинки, JS, CSS, видео), а ваш сервер продолжает спокойно обрабатывать динамику — API, базу данных, бизнес-логику.

Оба эффекта реальны, но оба условны. Географическое преимущество работает только если у вас действительно распределённая по миру аудитория. Если 95% пользователей заходят с одного континента и сервер стоит там же — CDN не даст ощутимого выигрыша в задержке, вы просто платите за инфраструктуру, которая физически ближе к пользователям, которых у вас почти нет. Снятие пиковой нагрузки тоже условно: если ваш сервер и так справляется с пиками без деградации, вы платите за страховку от проблемы, которой не существует.

Из чего складывается счёт за CDN

Коммерческие CDN обычно берут деньги по одной из двух моделей, иногда комбинируя обе:

• Оплата за объём переданного трафика (per-GB). Чем больше гигабайт уходит через сеть CDN, тем больше счёт. У многих провайдеров есть региональные множители: раздача в Северную Америку и Европу дешевле, чем в Южную Америку, Африку или отдельные страны Азии — там инфраструктура CDN-провайдера дороже в обслуживании, и это закладывается в цену.
• Подписка с фиксированным лимитом или тарифной сеткой. Вы платите ежемесячную сумму за пакет трафика и функций (кэширование, защита от DDoS, WAF, оптимизация изображений на лету), а превышение лимита либо тарифицируется отдельно, либо блокируется.

Есть и скрытые статьи расходов, которые часто забывают посчитать заранее:

• плата за инвалидацию кэша (сброс закэшированных версий файлов при частых обновлениях контента);
• плата за дополнительные функции — сжатие на лету, оптимизация изображений, защита от ботов;
• плата за SSL-сертификаты на кастомных доменах у части провайдеров с урезанным бесплатным тарифом;
• разница в цене между «обычным» трафиком и трафиком видео/стриминга — у многих CDN он тарифицируется отдельно и дороже.

Прежде чем сравнивать CDN с собственной раздачей, соберите реальную структуру трафика: сколько гигабайт в месяц, в какие регионы, какая доля — статика, а какая — видео или большие файлы. Без этих цифр сравнение будет гаданием.

Что стоит раздача со своего сервера

Здесь экономика проще: вы уже платите за сервер, и раздача статики поверх этой стоимости почти ничего не добавляет — при условии, что тариф включает достаточный объём исходящего трафика или безлимитный канал на разумной скорости порта. У многих провайдеров выделенных серверов и VPS исходящий трафик либо включён в достаточном объёме, либо тарифицируется по фиксированной скорости порта, а не по гигабайтам — это принципиально отличается от модели облачного egress, где каждый гигабайт исходящего трафика выставляется отдельной строкой в счёте.

Раздать статику своими силами можно через обычный nginx с грамотно настроенным кэшированием на уровне файловой системы и заголовков Cache-Control, ETag, Expires — подробно об установке и частых ошибках такого кэширования мы разбирали в отдельной статье про настройку кэширования nginx на VPS. Такой подход бесплатен сверх стоимости самого сервера: вы не платите за трафик отдельно, не платите за инвалидацию кэша, полностью контролируете логику кэширования.

Минус очевиден и был назван выше: у прямой раздачи нет географического преимущества. Пользователь из другого полушария всегда будет получать контент с задержкой, обусловленной физическим расстоянием и качеством межконтинентальных маршрутов — это не лечится настройками nginx, это лечится только физическим приближением точки раздачи к пользователю.

Где раздача со своего сервера упирается в потолок

Второе ограничение — производительность. У любого сервера есть предел по пропускной способности сетевого интерфейса, по числу одновременных соединений, по скорости чтения с диска при холодном кэше. Если трафик растёт быстрее, чем вы апгрейдите сервер, в какой-то момент раздача статики начинает конкурировать за ресурсы с обработкой динамических запросов — и это уже сказывается на всём сайте, а не только на скорости отдачи картинок.

Практически предел стоит проверять по нескольким метрикам:

• Пропускная способность сетевого интерфейса. Посмотреть заявленную скорость порта можно командой ethtool eth0 | grep Speed, а реальную утилизацию — vnstat -l в реальном времени или iftop для разбивки по соединениям. Если утилизация в пиках регулярно упирается в 70-80% от скорости порта — это тревожный сигнал.
• Число одновременных соединений и файловых дескрипторов. ss -s покажет общее число TCP-соединений, а ss -tan state established | wc -l — активные. Сравните с лимитами nginx (worker_connections) и системными (ulimit -n).
• Нагрузка на диск при холодном кэше. Если статика не помещается целиком в оперативную память и файловый кэш ОС, каждый промах кэша — это операция чтения с диска. iostat -x 1 покажет утилизацию диска (%util) и время ожидания (await).

Если по этим метрикам сервер держит пиковую нагрузку с запасом — раздача своими силами технически безопасна вплоть до довольно больших объёмов. Если запас исчерпывается — вопрос уже не «нужен ли CDN», а «нужно ли масштабировать сервер», и это отдельное решение, которое иногда дешевле, чем подключение CDN, а иногда нет — зависит от того, упираетесь вы в CPU, память или именно в сеть.

Методика: считаем порог окупаемости CDN

Порог, когда CDN оправдан, определяется пересечением двух факторов, а не одного из них по отдельности.

Фактор первый — география и объём трафика. Постройте распределение запросов по регионам за представительный период (минимум месяц, с учётом сезонности, если она есть). Источник данных — логи веб-сервера с геолокацией по IP (GeoIP2 модуль для nginx или разбор логов через goaccess с гео-базой) либо данные веб-аналитики, если она уже настроена. Если 80-90% трафика приходится на один регион, где физически стоит сервер, географическое преимущество CDN проявляется только для оставшихся 10-20% — и выгода от него пропорционально мала. Если аудитория размазана по трём-четырём континентам примерно поровну, преимущество CDN становится системным, а не косметическим.

Фактор второй — достаточность собственной производительности под пики. Если метрики из предыдущего раздела показывают, что сервер комфортно держит текущие и прогнозируемые пиковые нагрузки — довод «CDN снимет нагрузку с сервера» теряет вес, вы платите за резерв, который не используете. Если же пики регулярно приближаются к пределу пропускной способности или диска — CDN действительно снимает реальный риск деградации сайта в момент всплеска трафика.

Дальше — арифметика. Возьмите месячный объём трафика в гигабайтах, разбейте по регионам, посчитайте гипотетическую стоимость через CDN по объявленным тарифам провайдера (это несложно сделать в его калькуляторе, точные цифры у разных провайдеров и по регионам сильно различаются, поэтому здесь не даём условных цифр — считайте по актуальному прайсу интересующего вас CDN). Сравните эту сумму не с «нулём» (раздача со своего сервера не бесплатна абсолютно, но при разумном тарифе с достаточным включённым трафиком предельные затраты на дополнительный гигабайт близки к нулю), а со стоимостью альтернативы: апгрейд сервера, аренда дополнительного сервера в другом регионе, или просто принятие риска более медленной загрузки для доли аудитории.

Порог обычно наступает не при каком-то абсолютном числе гигабайт, а когда одновременно выполняются два условия: заметная доля трафика приходится на удалённые от сервера регионы, и стоимость этого трафика через CDN оказывается меньше, чем стоимость достижения того же результата (низкой задержки и устойчивости к пикам) через масштабирование собственной инфраструктуры.

Практический алгоритм для вашего проекта

Чтобы не гадать, пройдите пять шагов на своих реальных данных:

1. Соберите статистику за 30-90 дней: объём исходящего трафика в гигабайтах помесячно, разбивка по типам контента (изображения, видео, скрипты и стили, документы), разбивка запросов по странам или континентам.
2. Проверьте запас производительности сервера по сети, диску и соединениям в пиковые часы — методами из раздела выше. Зафиксируйте, есть ли запас 30%+ или сервер уже работает на пределе.
3. Оцените реальную выгоду в задержке. Если возможно, замерьте время загрузки статики для пользователей из удалённых регионов текущими средствами (синтетические тесты из разных точек мира, либо реальные данные RUM-мониторинга, если он подключён). Разница в 20-50 мс для локальной аудитории — не повод платить за CDN; разница в разы для удалённой — повод.
4. Посчитайте деньги по обеим сторонам: реальный прайс CDN под ваш объём и географию против стоимости достаточного апгрейда сервера или добавления сервера во втором регионе.
5. Рассмотрите промежуточный вариант. Между «ничего» и «полноценный коммерческий CDN» есть средний путь — собственный кэширующий узел в ключевом для вас регионе, где сосредоточена значимая, но не вся аудитория. Экономику такого варианта на примере одного региона мы разбирали отдельно в статье про собственный кеширующий узел вместо коммерческого CDN, а базовые принципы работы CDN изнутри — в материале о том, что такое CDN и где физически лежит закэшированная картинка.

Если после этих пяти шагов оба фактора — география и нагрузка — говорят в пользу CDN, подключение обычно делается без замены существующей инфраструктуры: сервер остаётся источником истины (origin), а CDN просто становится прослойкой перед ним. Практические шаги такой настройки, включая заголовки кэширования и типичные грабли, мы описывали в статье о настройке CDN перед сервером.

Частые вопросы