Видео для сайта без внешнего плеера: сколько стоит хранить и раздавать его с VPS

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

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

Сначала диск: исходник, варианты и то, что рядом

Размер видеофайла прикидывается просто: битрейт умножить на длительность. Видео в 5 Мбит/с на 60 минут весит примерно 5 × 3600 / 8 = 2250 МБ, то есть около 2,2 ГБ. Аудиодорожка добавит ещё немного, но на фоне видео её часто можно считать погрешностью. Это основа, и от неё считаются все остальные величины.

Теперь о том, что именно хранится. Почти никогда это один файл. Обычно на диске оказываются:

• оригинал, который вы загрузили или получили от оператора — его разумно держать, чтобы при смене схемы кодирования не терять качество повторным пережатием уже пережатого;
• один или несколько вариантов для сайта, например 1080p, 720p и 480p;
• постер и, возможно, субтитры отдельными файлами;
• временные файлы на время перекодирования.

Если подготовить три варианта по 5, 2,5 и 1,2 Мбит/с, суммарный битрейт лесенки составит 8,7 Мбит/с. Для часового видео это около 3,9 ГБ плюс оригинал. Если оригинал снят на 20 Мбит/с, он сам займёт 9 ГБ, и тогда на одно часовое видео уходит почти 13 ГБ. Обратите внимание: подготовленные варианты вместе весят меньше оригинала, а общий объём определяется тем, как вы снимаете, а не тем, как показываете.

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

Запас под перекодирование

Диск нужно считать не по готовому результату, а по пику работы. Пока идёт перекодирование, на диске одновременно лежат оригинал, частично готовые варианты и иногда промежуточные файлы. Разумное правило для планирования: на время обработки одного ролика держать свободным объём, равный как минимум оригиналу плюс всем вариантам. Это наша рабочая прикидка, а не требование какого-либо документа, но она спасает от ситуации, когда обработка падает на 95% из-за нехватки места.

Теперь сопоставим с ресурсами. Если у вас библиотека из 40 часовых лекций по 13 ГБ вместе с оригиналами, это 520 ГБ, и на тарифы с 160 или 240 ГБ NVMe она уже не поместится: у MAATRIX это Heka (160 ГБ) и Maat (240 ГБ), а для такого объёма понадобится либо отказ от хранения оригиналов на сервере, либо больше места. Если оригиналы вынести в холодное хранилище, на сервере останутся лишь варианты: около 4 ГБ на лекцию, то есть 160 ГБ на всю библиотеку, и это уже вопрос грани между двумя тарифами. О том, как выглядит долгосрочная стоимость хранения, есть отдельный разбор: считаем стоимость хранения терабайта на пять лет.

Два учебных профиля, которые ведут себя по-разному

Чтобы не считать абстрактно, возьмём два условных сайта. Оба придуманы для расчёта.

Профиль А: редкое длинное видео. Онлайн-курс, 40 лекций по часу. Каждую в месяц смотрят в среднем 30 человек. Зрители досматривают до конца часто, потому что платили или изучают материал всерьёз, но пусть в среднем просматривается 70% длительности. Вариант качества у большинства один — 720p, 2,5 Мбит/с.

Профиль Б: короткий популярный ролик. Рекламный или обзорный клип на 45 секунд, который встроен на главную страницу. Просмотров много: 100 000 запусков в месяц. Но смотрят его обрывками: в среднем 40% длительности. Битрейт 1080p-варианта — 4 Мбит/с, для мобильных зрителей — 1,2 Мбит/с, и пусть половина зрителей получает каждый вариант.

Посчитаем объём для профиля А. Одна лекция при 2,5 Мбит/с весит 2,5 × 3600 / 8 = 1125 МБ. Просмотренная часть в среднем 70%: 1125 × 0,7 ≈ 790 МБ на просмотр. Всего просмотров 40 × 30 = 1200. Итого около 945 ГБ в месяц. Почти терабайт трафика для сайта, у которого всего 1200 просмотров, и это стоит увидеть глазами: длинное видео делает из малой аудитории тяжёлого потребителя трафика.

Теперь профиль Б. Средний битрейт при половинном распределении: (4 + 1,2) / 2 = 2,6 Мбит/с. Видео на 45 секунд при этом весит около 2,6 × 45 / 8 ≈ 14,6 МБ. Просматривается 40%: примерно 5,9 МБ на запуск. Умножаем на 100 000: около 585 ГБ в месяц. Здесь аудитория в сотню раз больше, а трафик меньше, потому что ролик короткий и его не досматривают.

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

Месячный объём и пик: два разных вопроса

Это самое частое место, где расчёты расходятся с реальностью. Месячный объём отвечает на вопрос, хватит ли вам лимита трафика по тарифу и сколько вы заплатите, если он превышен. Одновременная потребность отвечает на другой вопрос: выдержит ли канал тот момент, когда зрителей много сразу. Можно уложиться в месячный объём и всё равно получить буферизацию в обед, когда ссылку разослали.

Переведём пик в мегабиты. Если в какой-то момент одновременно смотрят 50 человек при среднем битрейте 2,5 Мбит/с, канал должен отдавать около 125 Мбит/с, и это без запаса на заголовки, повторные запросы и другие страницы сайта. На порт в 100 Мбит/с такая нагрузка не ляжет, на гигабитный — ляжет с запасом. Поэтому при выборе VPS полезно знать не только лимит трафика за месяц, но и скорость порта; такие параметры лучше уточнять в условиях выбранного тарифа, а не предполагать.

Отдельно о слове «безлимит». Если тариф описан как unlimited, это говорит о том, что объём передачи не ограничен счётчиком, но не о том, что скорость бесконечна. Порт всё равно имеет конечную пропускную способность, и 50 зрителей при 2,5 Мбит/с упрутся в неё, независимо от того, считает ли провайдер гигабайты. Кроме того, у безлимитных предложений нередко есть правила честного использования, и их надо читать до запуска. Поэтому для видео нужны два числа: сколько гигабайтов вы отдадите за месяц и сколько мегабит в секунду понадобится в самый тяжёлый час.

Как оценить пик по месячному объёму? Грубо: берём месячный трафик и делим на секунды месяца, получаем среднюю полосу, затем умножаем на коэффициент неравномерности. Для профиля А: 945 ГБ ≈ 7560 Гбит; в месяце около 2,6 млн секунд, средняя нагрузка около 2,9 Мбит/с. Звучит ничтожно. Но если зрители приходят в основном вечером и по расписанию курса, пик легко выше средней в 20–50 раз, то есть 60–150 Мбит/с. Коэффициент здесь наше допущение: на практике его определяют по логам, а не по формуле.

Что делает процессор, пока канал раздаёт

Раздача готовых файлов и подготовка вариантов нагружают разные ресурсы, и важно их не путать. В документации Owncast об этом сказано прямо: перекодирование вариантов качества расходует CPU, а доставка зрителям расходует исходящую полосу; кодирование варианта не запускается заново для каждого зрителя, хотя обслуживание зрителей тоже не бесплатно (требования к ресурсам Owncast). Хотя речь там о прямых трансляциях, логика переносится на нашу задачу: если вы заранее подготовили файлы, то 10 или 1000 зрителей не заставляют сервер кодировать заново, зато заставляют отдавать.

Отсюда вывод для планирования. Если вы загружаете видео редко, а смотрят его часто, CPU нужен в моменты подготовки, и его можно получить временно, например запускать кодирование ночью, а в остальное время сервер почти простаивает по процессору. Если же видео загружают пользователи, как на сообществе или курсах с сабмитами, обработка превращается в постоянную очередь, и тогда число vCPU становится реальным ограничением. Для сравнения: на 1 vCPU (тариф Ba) перекодирование часового видео в три варианта растянется надолго и будет конкурировать с сайтом за процессор, а на 4–8 vCPU (Heka, Maat) очередь можно держать под контролем. Это ориентиры для теста, а не обещание: скорость кодирования зависит от кодека, разрешения и настроек, и измерять её нужно на своём материале.

Когда перекодирование включается само

Есть ещё один источник скрытой нагрузки: несовместимость с устройством зрителя. В документации Jellyfin отмечено, что поддержка контейнеров, кодеков, звука и субтитров зависит от клиента, а необходимость встраивания субтитров в изображение может потребовать перекодирования видео (совместимость кодеков в Jellyfin). Для сайта это означает осторожность с экзотическими форматами. Если вы отдаёте файл в редком кодеке или с субтитрами, которые нужно вжигать в картинку, то часть зрителей либо не сможет его воспроизвести, либо создаст нагрузку на CPU, если у вас включено перекодирование на лету. Проще заранее подготовить совместимые варианты и держать субтитры отдельной дорожкой.

Перемотка, повторные запросы и география

Выше мы считали трафик по формуле «просмотренная доля», и это уже учитывает, что люди не досматривают. Но поведение зрителей добавляет ещё три эффекта, которые стоит иметь в виду.

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

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

Переключение качества. Адаптивный плеер выбирает вариант по доступной полосе, а значит, на мобильной сети в метро один зритель может за минуту сходить через два-три варианта. Каждый переход добавляет небольшой перекос в объёме, и средний битрейт в реальных логах почти всегда отличается от среднего по вашей лесенке. Поэтому в расчёте мы брали взвешенное среднее, а не максимальный вариант. Если вы заложите максимальный, получите завышение, но оно безопасно; если заложите минимальный, занизите объём, и это опасно.

География. Здесь расчёт трафика не меняется, зато меняется качество. Физическое расстояние между сервером и зрителем влияет на задержку и на то, как стабильно держится скорость. Один сервер в одной локации одинаково хорошо обслужит аудиторию рядом с ним и хуже — аудиторию на другом континенте, даже если канал свободен. В публичном предложении MAATRIX указаны локации UK, US, RU и FR, поэтому для аудитории, сосредоточенной в одном регионе, можно выбрать ближайшую. Если же зрители распределены по миру, выбор одной локации означает компромисс: часть людей будет получать видео медленнее. Доступность конкретных образов в каждой локации лучше проверять в форме заказа.

Когда одного VPS уже мало

Вопрос не в абстрактном размере проекта, а в конкретных симптомах. Вот признаки, при которых раздачу видео стоит выносить в отдельную систему доставки:

• Пик упирается в порт. Расчётная одновременная полоса приближается к скорости порта, а логи показывают буферизацию в часы пик. Увеличение vCPU и RAM здесь не поможет: проблема в канале.
• Видео мешает сайту. Когда раздача занимает полосу и дисковые операции, страницы, формы и админка начинают отвечать медленнее. Разделить сайт и видео по разным серверам — самый простой первый шаг.
• Аудитория разбросана географически. Если зрители из разных регионов жалуются на загрузку, один сервер в одной локации не исправить мощностью.
• Объём библиотеки перерос диск. Оригиналы и варианты не помещаются даже с запасом на обработку, а докупать диск под архив, который почти никто не смотрит, невыгодно.
• Очередь кодирования стала постоянной. Если обработка не успевает за загрузками и тормозит остальные задачи, нужен отдельный воркер или сервер.

Обратите внимание: ни один из этих признаков не звучит как «у нас слишком много зрителей вообще». Каждый указывает на конкретный ресурс: канал, процессор, диск, расстояние. Это и есть метод диагностики: найти узкое место, а не наращивать всё сразу.

Важный нюанс: отдельная система доставки не обязана быть внешним видеосервисом. Это может быть второй VPS, который отдаёт только статические видеофайлы и сегменты, а первый остаётся для сайта и приложений. Такое разделение понятно и предсказуемо, но нужно помнить, что два сервера не означают автоматическую отказоустойчивость: если видео лежит только на втором, при его недоступности ролики не воспроизведутся. Резервирование — отдельная задача, и она требует собственного решения.

Выбор способа доставки по характеру аудитории

Вернёмся к двум нашим профилям и посмотрим, какой путь подходит каждому.

Для профиля А (курс на 1200 просмотров, около 945 ГБ в месяц, мало зрителей, но тяжёлые сессии) подойдёт один VPS с запасом диска и приличным портом, если аудитория сосредоточена в одном регионе. Тут важнее всего объём: нужно убедиться, что месячный трафик укладывается в условия тарифа, а пик в десятки одновременных зрителей — в порт. Лесенка из трёх вариантов оправдана, потому что студенты смотрят на разных устройствах. Оригиналы стоит выгрузить с сервера после обработки, чтобы не тратить NVMe на архив.

Для профиля Б (клип на 100 000 запусков) главная проблема не объём, а всплески. Короткий ролик на главной получает волну посетителей одновременно, например после рассылки, и тысячи небольших запросов приходят в узком окне. Одного VPS может хватить, если ролик лёгкий и закэширован, но запас по полосе нужен больше, чем у курса. Если же трафик идёт из многих стран, разумнее подумать о распределённой доставке, а на своём сервере оставить источник файлов. Другой вариант — сделать ролик ещё легче: сократить битрейт мобильной версии и убрать автозапуск со звуком, чтобы запуск не равнялся просмотру.

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

Если вы решите начать со своего сервера, под небольшой сайт с несколькими роликами можно взять один из младших тарифов, а под библиотеку с обработкой — конфигурацию с большим числом vCPU и объёмом NVMe. Они доступны с root-доступом на странице аренды VPS MAATRIX, оплата возможна картой РФ и через СБП, а сервер создаётся автоматически через пару минут после оплаты.