Считаем, во сколько обходится собственный видеохостинг

MAATRIX

Идея звучит соблазнительно: зачем платить видеохостингу или CDN за каждый гигабайт, если можно поднять свой сервер и раздавать видео напрямую? На бумаге расчёт простой — цена VPS известна заранее, никаких сюрпризов в счёте. На практике видео — это единственный тип контента, где именно исходящий трафик, а не диск и не CPU, обычно решает, выгодна ли затея. Разберём по шагам, из чего складывается реальная стоимость, и как понять, при каком объёме просмотров свой сервер становится дешевле стороннего сервиса.

Из чего вообще складывается стоимость своего видеохостинга

Когда считают «сколько стоит держать видео у себя», почти всегда вспоминают только диск — и ошибаются, потому что диск обычно самая дешёвая часть уравнения. Реальных статей расхода четыре, и их важно считать отдельно, потому что они по-разному растут:

• Хранение (диск). Растёт линейно от объёма библиотеки видео — сколько часов контента вы храните и в каком качестве. Не зависит от того, смотрит ли кто-то это видео сегодня.
• Исходящий трафик (раздача). Растёт от числа просмотров и качества, в котором смотрят. Это переменная часть, и именно она обычно недооценена на старте — часовой ролик в HD может «весить» в трафике как сотни обычных веб-страниц.
• Транскодирование. Разовая или регулярная нагрузка на CPU/GPU при загрузке нового видео — конвертация в несколько разрешений и битрейтов под разные устройства и скорости соединения. Это не раздача, это отдельная вычислительная задача.
• Инфраструктура вокруг. Веб-сервер отдачи (nginx с поддержкой byte-range и HLS/DASH), плеер, возможно очередь транскодирования, бэкапы исходников, мониторинг диска и канала.

Если у вас пара роликов и десяток просмотров в день — вообще не о чем считать, хватит любого недорого VPS. Разговор начинается там, где счёт идёт на сотни часов видео и тысячи просмотров в месяц — и тут уже важно не гадать, а прогнать цифры через простую модель ниже.

Место на диске: как перевести битрейт и разрешение в гигабайты

Формула здесь одна и та же для хранения и для трафика, разница только в том, что умножаем: длительность × битрейт = объём. Битрейт задаёт кодек и настройки кодирования, и он сильно отличается по разрешению.

Ориентировочные битрейты для H.264 при типичных настройках стриминга (это диапазоны, а не точные цифры — конкретное значение зависит от кодека, содержания кадра и настроек кодировщика):

Формула для проверки: битрейт (Мбит/с) × длительность (сек) / 8 = объём в мегабайтах. Например, 5 Мбит/с × 3600 сек / 8 = 2250 МБ ≈ 2.2 ГБ за час 1080p-видео.

Если вы отдаёте видео адаптивным потоком (несколько разрешений одновременно — обычная практика HLS/DASH), место на диске нужно на все варианты сразу, а не только на исходник. Условная библиотека в 500 часов оригинального 1080p-контента, транскодированная в 480p/720p/1080p, займёт на диске сумму всех трёх колонок — грубо говоря, умножьте объём одного разрешения на число вариантов, которые вы храните, а не только раздаёте.

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

Исходящий трафик: самая недооценённая статья расходов

Вот здесь начинается настоящая математика, и её часто просто не делают на старте. Формула:

Трафик в месяц = битрейт × длительность просмотра × число просмотров

Ключевое слово — «длительность просмотра», а не длительность ролика. Если у видео средняя глубина досмотра 40% (это нормально для многих типов контента), считать нужно именно эти 40%, а не полную длину — иначе объём завышен в 2.5 раза и решение будет приниматься на неверных цифрах.

Пример на пальцах. 10-минутный ролик в 1080p (битрейт ~5 Мбит/с), средняя глубина просмотра 60% (то есть смотрят 6 минут = 360 сек):

Объём одного просмотра = 5 Мбит/с × 360 сек / 8 = 225 МБ ≈ 0.22 ГБ

Дальше — просто умножение на аудиторию:

Для сравнения: обычная веб-страница с картинками весит десятки-сотни КБ. То есть один просмотр видео в 1080p может весить как сотни, а то и тысячи загрузок обычной страницы. Это и есть причина, по которой видеотрафик — статья расходов совершенно другого порядка, чем трафик текстового или новостного сайта. Если у вас уже был опыт, когда счёт за трафик неожиданно вырастал на обычном сайте, — механика описана в статье цена одного гигабайта трафика у разных провайдеров; с видео та же логика, но объёмы на порядки выше.

Дальше нужно посчитать деньги. У большинства VPS и выделенных серверов трафик либо включён безлимитно (но с оговоркой про «разумное использование» или ограничение по каналу — 1 Гбит/с, например), либо оплачивается за перерасход сверх включённого пакета. Возьмите свой тариф и посчитайте: если включено, скажем, N ТБ в месяц, а по формуле выше вам нужно X ТБ — либо вы укладываетесь, либо переплачиваете за превышение по тарифу провайдера (эти ставки у всех разные, уточняйте у своего хостера точную стоимость перерасхода — готовых универсальных цифр здесь нет). Отдельно проверьте физический потолок канала: даже безлимитный по объёму тариф на канале 1 Гбит/с физически не отдаст больше ~324 ТБ в месяц при полной непрерывной загрузке — на практике меньше, так как трафик пиковый, а не равномерный. Разница между шириной канала «на бумаге» и тем, что реально прокачивается, разобрана в статье сетевой канал 1G против 10G.

Транскодирование: отдельная нагрузка, которую часто забывают посчитать

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

Что происходит при транскодировании:

• Исходник (например, снятый в 4K) перекодируется в 2-4 более лёгких варианта — 1080p, 720p, 480p — чтобы плеер мог переключаться между ними в зависимости от скорости соединения зрителя (адаптивный битрейт, ABR).
• Для широкой совместимости часто нужен ещё и пересчёт в разные контейнеры/кодеки (H.264 для совместимости со старыми устройствами, H.265/AV1 для экономии трафика на новых).
• Если видео нарезается под HLS/DASH — дополнительно генерируются сегменты и манифесты для каждого варианта.

Это тяжёлая CPU-задача (программный кодировщик вроде ffmpeg с libx264) либо она ускоряется через GPU (NVENC у NVIDIA, QuickSync у Intel) — на GPU транскодирование в разы быстрее и не так сильно нагружает CPU, но нужна видеокарта с соответствующим кодировщиком в самом сервере или в отдельном сервере транскодирования. Пример команды для базового перегона одного разрешения:

ffmpeg -i source.mp4 -vf scale=-2:720 -c:v libx264 -b:v 3000k \
  -c:a aac -b:a 128k -f hls -hls_time 6 -hls_playlist_type vod \
  output_720p/index.m3u8

Прогнать один часовой ролик в 3-4 разрешения программным кодировщиком на обычном CPU-ядре может занимать заметно дольше реального времени ролика — точная скорость сильно зависит от процессора, разрешения источника и настроек, готовых цифр тут давать не будем, лучше замерить на своём железе на тестовом файле. Практический вывод для расчёта бюджета: если вы регулярно загружаете новый контент (а не редко публикуете уже готовые ролики), транскодирование стоит либо выносить на отдельный сервер с GPU, либо закладывать в расчёт запас CPU на основном сервере, который не будет мешать одновременной раздаче зрителям. Про выбор сервера под тяжёлую видеонагрузку — в статье выделенный сервер для видеомонтажа и рендер-фермы: логика подбора GPU/CPU для рендера и для транскодирования во многом пересекается.

Сравнение с оплатой стороннего видеохостинга или CDN

У сторонних видеосервисов и CDN для видео обычно две модели тарификации: за объём отданных гигабайт или за число/минуты просмотров (иногда — комбинация с включённым бесплатным лимитом). Точные тарифы у разных провайдеров сильно различаются и часто меняются, поэтому вместо конкретных цифр — сравнение по структуре затрат:

Ключевая разница: свой сервер — это фиксированная стоимость независимо от того, 100 у вас просмотров или 100 000 (пока не упёрлись в потолок канала или диска). Сторонний сервис — это переменная стоимость, растущая вместе с аудиторией. Отсюда и логика следующего раздела — где именно проходит граница выгодности.

Точка безубыточности: при каком объёме просмотров свой хостинг выгоднее

Смысл расчёта простой: у своего сервера есть фиксированная стоимость в месяц (аренда VPS/выделенного сервера, вне зависимости от нагрузки), у стороннего сервиса — переменная стоимость, растущая с трафиком. Точка безубыточности — это объём просмотров, при котором переменные затраты стороннего сервиса сравниваются с фиксированной ценой вашего сервера.

Методика расчёта:

1. Возьмите месячную стоимость вашего сервера (аренда +, если нужно, CDN перед ним) — это C_own.
2. Возьмите тариф стороннего сервиса за ГБ или за просмотр (уточните у конкретного провайдера — эти цифры у всех разные) — это P_gb или P_view.
3. Посчитайте объём трафика на один просмотр по формуле из раздела про трафик выше (битрейт × длительность просмотра) — это V.
4. Точка безубыточности по просмотрам: N = C_own / (V × P_gb) (если тариф за ГБ) или N = C_own / P_view (если тариф за просмотр).

Пример подстановки (числа условные, чтобы показать саму механику расчёта — подставьте свои реальные тарифы): сервер обходится в условную сумму X ₽/месяц, один просмотр весит 0.22 ГБ (как в примере выше), тариф стороннего сервиса — Y ₽/ГБ. Тогда безубыточный объём — N = X / (0.22 × Y) просмотров в месяц. Ниже этого объёма выгоднее сторонний сервис (вы платите только за то, что реально посмотрели), выше — выгоднее свой сервер (фиксированная цена уже отбилась, а дополнительные просмотры почти бесплатны, пока не упёрлись в потолок канала).

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

От чего сильно зависит расчёт: популярность контента и география

Две вещи ломают простую формулу выше и их обязательно нужно учитывать отдельно.

Популярность и распределение просмотров во времени. Формула трафика предполагает равномерную нагрузку, но у видео почти никогда так не бывает — вирусный ролик может дать 90% месячного трафика за один день. Ваш сервер должен выдержать не среднюю, а пиковую нагрузку на канал, иначе в момент всплеска просто не хватит пропускной способности и зрители получат тормозящее видео или обрывы — а это прямой удар по репутации контента в момент, когда он больше всего нужен. Если вы не уверены, что текущий тариф выдержит всплеск, — сторонний CDN/видеохостинг с эластичным масштабированием на такой случай объективно надёжнее, чем один фиксированный сервер.

География аудитории. Скорость доставки видео зрителю сильно зависит от того, насколько далеко он физически находится от вашего сервера — задержка и потери пакетов растут с расстоянием, а видео к задержкам куда чувствительнее обычной страницы (буферизация, прерывания потока). Если ваша аудитория сосредоточена в одном регионе рядом с сервером — всё в порядке, раздавайте напрямую. Если аудитория географически разнесена (например, часть в России, часть в Европе, часть в США) — есть по сути два варианта: либо смириться с просадкой скорости для дальних зрителей, либо поставить CDN перед своим сервером, чтобы кэшировать контент ближе к зрителю. Как это устроено технически и что при этом происходит с исходным сервером — в статьях что такое CDN изнутри: где на самом деле лежит ваша картинка и настройка CDN перед сервером: те же принципы кэширования, что для картинок сайта, применимы и к видеосегментам, только объёмы кэша нужны на порядки больше.

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

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