Свой кеширующий узел вместо коммерческого CDN: экономика одного региона

MAATRIX

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

Зачем вообще нужен CDN и что из этого действительно работает на скорость

Коммерческий CDN решает три разные задачи одновременно, и их полезно разделять, потому что у каждой своя экономика.

Первая — географическая близость к пользователю. Чем короче путь пакета до сервера и обратно, тем меньше задержка на установление соединения и тем быстрее браузер получает первые байты ответа. Для статики (картинки, CSS, JS, видео) и для API с редко меняющимися данными это даёт заметный эффект, особенно на мобильных сетях, где каждый лишний RTT (round-trip time) ощутим.

Вторая — снятие нагрузки с источника (origin). Кеш на границе сети отдаёт повторяющиеся запросы сам, не долетая до вашего сервера и базы данных. Это защищает от пиковых нагрузок и от части DDoS-паттернов на уровне HTTP.

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

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

Разбор механики того, что вообще происходит "внутри" CDN и куда физически ложится закешированный файл, — в отдельном материале о том, как устроен CDN изнутри: общий принцип тот же, что и для одного узла — кеш живёт на диске или в памяти edge-сервера и отдаётся напрямую, минуя origin.

Когда один регион — это правда один регион

Прежде чем считать экономику, нужно честно оценить, действительно ли аудитория сконцентрирована. Признаки, что это так:

• Основной рынок продукта — одна страна или языковая зона (например, B2B-сервис для российских компаний, локальный маркетплейс, региональное СМИ).
• Аналитика (Google Analytics, Яндекс.Метрика, логи origin-сервера) стабильно показывает 80%+ трафика из одного гео на протяжении нескольких месяцев, а не разового всплеска.
• Международная экспансия не в ближайших планах, либо для новых регионов уже есть отдельная инфраструктура или её сознательно нет.
• Мобильная аудитория преимущественно в одной стране — важно, потому что мобильные сети дают наибольший относительный выигрыш от близкого узла.

Если хотя бы один из пунктов не выполняется — например, продукт растёт в СНГ и Европе одновременно, — экономика меняется, и об этом отдельно ниже.

Стоит также отделить "аудиторию" от "инфраструктуры". Даже у регионального продукта облачные поставщики, платёжные шлюзы или сторонние API могут физически обращаться к серверу из других частей света — это не аудитория, а служебный трафик, и он не должен влиять на решение о географии кеширующего узла.

Что технически представляет собой свой кеширующий узел

Свой кеширующий узел — это сервер, который стоит перед origin (вашим "боевым" бэкендом) и отдаёт закешированные ответы напрямую, не проксируя каждый запрос дальше. Технически это тот же принцип, что и в CDN, только на одной точке.

Схема из двух серверов:

Пользователь → DNS → Кеширующий узел (рядом с аудиторией)
                          │
                          ├─ кеш есть → отдать сразу
                          └─ кеша нет → сходить на origin, сохранить, отдать

Практически это чаще всего связка nginx или Varnish как обратный прокси с кешированием на SSD, TLS-терминацией и (опционально) сжатием на лету. Если origin и кеширующий узел стоят в разных дата-центрах или у разных провайдеров, канал между ними стоит защитить приватной сетью или VPN — иначе кеш-промахи будут ходить через публичный интернет с дополнительной задержкой и в открытом виде.

Пример базовой конфигурации nginx как кеширующего прокси перед origin:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=edge_cache:100m
                  max_size=20g inactive=60m use_temp_path=off;

server {
    listen 443 ssl http2;
    server_name example.com;

    location / {
        proxy_pass http://origin.internal:8080;
        proxy_cache edge_cache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
        proxy_cache_lock on;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

Заголовок X-Cache-Status полезен на этапе отладки — сразу видно, попадает ли запрос в кеш (HIT) или уходит на origin (MISS, EXPIRED). Практические грабли этой настройки — устаревшие ответы после релиза, промахи по авторизованным пользователям, память под зону ключей — разобраны отдельно в статье про частые ошибки настройки кеширования nginx.

Для распределения пользователей на ближайший узел (если узлов больше одного, но всё ещё в пределах одного региона — например, основной и резервный) пригодится GeoDNS: DNS-сервер отдаёт разные A-записи в зависимости от геолокации запроса.

Экономика: фиксированная стоимость сервера против оплаты за трафик

Здесь и заключается основная разница в подходах к оплате.

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

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

Условная модель (без привязки к конкретным цифрам конкретных провайдеров — у каждого своя тарифная сетка, ориентир нужно сверять с текущими прайсами):

Порог, с которого свой узел становится выгоднее, зависит от вашего объёма трафика, тарифа CDN и стоимости аренды сервера с нужным каналом — универсальной цифры тут нет, и её стоит посчитать под свои реальные счета за последние 2-3 месяца, а не ориентироваться на чужие кейсы. Методика простая: возьмите текущий счёт за CDN, разделите на фактически отданные гигабайты, сравните полученную цену за гигабайт со стоимостью аренды сервера с сопоставимым каналом в целевом регионе — и посмотрите, при каком объёме трафика в месяц линии сравняются.

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

Где регионального узла хватает почти полностью

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

• Статику для аудитории одного региона — картинки, CSS, JS, шрифты, если 90%+ запросов реально идёт из целевой географии.
• Кеширование ответов API с TTL от нескольких секунд до часов — карточки товаров, списки, справочники, которые не персонализированы и меняются не мгновенно.
• Снятие нагрузки с origin при пиках трафика внутри региона — репост в соцсетях, рассылка, рекламная кампания, ориентированные на ту же аудиторию.
• Защиту от части паразитной нагрузки — сканеры, боты, повторные запросы одного и того же ресурса гасятся кешем до того, как долетят до бэкенда.

Здесь один узел действительно даёт эффект, близкий к глобальному CDN для этой конкретной аудитории, просто потому что "близко к пользователю" для сфокусированной аудитории — это буквально одна точка на карте, а не сеть точек.

Где один узел не заменит глобальный CDN

Честно про ограничения — здесь экономия оборачивается потерей качества обслуживания:

• Аудитория реально распределена по миру. Пользователь из другого полушария будет ходить к вашему единственному узлу через полмира — задержка окажется не лучше, а иногда хуже, чем прямое обращение к origin из соседнего дата-центра. Один региональный узел физически не может быть "близко" сразу для всех — это не вопрос настройки, а вопрос географии и скорости света: задержка растёт вместе с расстоянием и числом промежуточных сетей на пути пакета.
• Раздача очень больших файлов при большом числе одновременных скачиваний. Один канал сервера имеет физический потолок, и при по-настоящему массовой раздаче (крупные релизы, видео с высокой одновременной аудиторией) распределённая сеть с балансировкой нагрузки между узлами выигрывает — это как раз тот случай, где количество точек присутствия CDN работает на вас, а не просто числится в тарифе.
• Защита от распределённых атак. Крупные CDN поглощают объёмные DDoS-атаки за счёт суммарной ёмкости сети точек присутствия. Один сервер, даже с базовой защитой на уровне провайдера, такой ёмкостью не располагает — при серьёзной атаке это будет заметно слабее.
• Отказоустойчивость без дополнительной работы. У CDN узел из другого региона подхватывает нагрузку прозрачно. У вас единственный узел — это единственная точка отказа, если не построить резервирование самостоятельно (второй сервер, GeoDNS с health check, автоматическое переключение).

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

Как оценить готовность инфраструктуры к переходу

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

1. Посчитайте реальную географию трафика за 2-3 месяца по логам или аналитике, а не по ощущениям — сезонность и разовые кампании могут искажать картину.
2. Оцените текущий счёт за CDN в пересчёте на гигабайт и сравните со стоимостью аренды сервера с сопоставимым каналом в целевом регионе.
3. Проверьте, что можно кешировать — персонализированный контент, ответы с cookie-сессиями, авторизованные API кешировать напрямую нельзя без дополнительной логики разделения ключей кеша.
4. Заложите время на настройку и тестирование — TLS, правила инвалидации кеша, мониторинг попаданий/промахов, поведение при недоступности origin (stale-while-revalidate или отдача устаревшего кеша).
5. Продумайте резервирование, даже минимальное — второй узел или хотя бы алерты, которые разбудят вас раньше, чем пользователей.

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

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