Прямой эфир на 10 000 зрителей: где заканчивается один сервер

MAATRIX

Разовый прямой эфир — презентация, конференция, финал турнира, распродажа с ведущим в кадре — устроен иначе, чем обычный растущий трафик сайта. Аудитория не нарастает неделями, она приходит вся сразу, в одну и ту же минуту, и держит одинаково высокую нагрузку весь эфир, а не пиковые секунды. Один сервер, который прекрасно тянет постоянный поток из пары сотен зрителей, на разовом всплеске в 10 000 может лечь не из-за слабого процессора, а из-за архитектуры, которая для такой задачи в принципе не годится. Разберём, где именно проходит эта граница и что стоит между «ещё выдержит» и «нужен специализированный сервис».

Чем разовый эфир отличается от обычного трафика

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

Отсюда два следствия, которые редко закладывают заранее:

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

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

Два разных предела: канал и соединения

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

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

Второй предел — число одновременных соединений и файловых дескрипторов, и о нём вспоминают куда реже. Каждое TCP-соединение на сервере — это файловый дескриптор, запись в таблице сетевого стека ядра, буфер на чтение и запись. Операционная система и веб-сервер по умолчанию настроены на разумные, но далеко не безграничные величины. Стандартный лимит ulimit -n во многих дистрибутивах — несколько тысяч, worker_connections в дефолтном конфиге nginx — тоже не рассчитан на десятки тысяч одновременных долгоживущих соединений без явной настройки. Если этот потолок не поднять заранее, сервер начнёт отклонять новые подключения или захлёбываться задолго до того, как исчерпается канал — и внешне это будет выглядеть как «сервер тормозит», хотя дело в лимите ОС, а не в мощности железа.

Проверить и поднять лимиты до эфира можно так:

# Текущий лимит открытых файлов для процесса
ulimit -n

# Постоянное увеличение лимита (в /etc/security/limits.conf)
www-data soft nofile 65535
www-data hard nofile 65535

# В конфиге nginx — число соединений на воркер
worker_processes auto;
events {
    worker_connections 8192;
}

# Проверка текущего числа установленных соединений
ss -s

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

Почему раздача видео — это не масштабирование веб-сервера

Интуитивно кажется, что раздача видео 10 000 зрителям — это то же самое, что раздача страницы 10 000 посетителям, просто в большем объёме. На практике это разные задачи по физике процесса.

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

Второй момент — доставка одного и того же контента множеству получателей одновременно физически ограничена одной сетевой картой одного сервера. У обычного веб-трафика запросы к разным страницам легко распределяются между несколькими бэкендами через балансировщик — задача параллелится естественно. У живого эфира все 10 000 зрителей смотрят один и тот же поток в одну и ту же секунду, и если раздача идёт с одной точки, она физически упирается в один сетевой интерфейс, сколько бы CPU и RAM на сервере ни было свободно. Единственный способ обойти этот предел — размножить точки раздачи (несколько серверов раздачи, edge-узлы CDN), а не наращивать мощность одной точки бесконечно.

Путь от камеры до 10 000 экранов: где на самом деле узкое место

Полезно разложить трансляцию на этапы — узкое место почти никогда там, где его интуитивно ищут:

1. Захват и кодирование. Камера или программа-кодировщик (OBS и аналоги) сжимает картинку в видеопоток и отправляет его на сервер по протоколу вроде RTMP. Это один поток, битрейт скромный (единицы-десятки мегабит), и на этом этапе проблем с масштабом почти никогда нет — узкое место не здесь.
2. Приём и упаковка (origin-сервер). Сервер принимает входящий поток и упаковывает его в формат для раздачи зрителям — обычно HLS или подобный протокол, где видео режется на короткие сегменты по несколько секунд, доступные по обычным HTTP-запросам. Если сервер ещё и транскодирует поток в несколько качеств (adaptive bitrate) — это отдельная, ощутимая нагрузка на CPU или GPU, независимая от раздачи.
3. Раздача сегментов зрителям. Вот здесь и находится настоящее узкое место при большой аудитории: 10 000 плееров каждые несколько секунд запрашивают у origin-сервера очередной сегмент. Если все 10 000 запросов идут напрямую на один сервер — это именно та нагрузка, которая упирается в оба предела из предыдущего раздела: канал и число соединений.

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

Что даёт CDN или стриминговая платформа для живого видео

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

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

Нюанс именно для *живого* видео, в отличие от статики: сегменты live-потока живут секунды, а не дни или месяцы, как картинка или скрипт на сайте. Кэш на edge-узле должен обновляться почти в реальном времени — это накладывает более жёсткие требования на настройку TTL и инвалидации кэша, чем для обычного статического контента, и не любой CDN одинаково хорошо справляется именно с live-сценарием. При выборе стоит явно уточнять поддержку low-latency HLS или аналогичных протоколов, а не полагаться на то, что «CDN для сайта» автоматически хорошо тянет и живое видео.

Общую методику, когда переход на CDN оправдан экономически, а когда раздача со своего сервера всё ещё дешевле и достаточно надёжна, разбирает статья CDN против раздачи со своего сервера: с какого объёма он окупается. Для разового пикового эфира логика немного смещена по сравнению с постоянным трафиком сайта: даже если в обычные дни своей раздачи хватает с запасом, разовый всплеск в 10 000 одновременных зрителей может оправдать подключение CDN или готовой платформы именно на день эфира, а не насовсем.

Три сценария: где чей потолок

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

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

Если аудитория эфира постоянна и предсказуема (не разовое событие, а регулярная стриминговая площадка), выбор инфраструктуры устроен иначе — там уже есть смысл держать выделенный сервер под постоянную нагрузку, а не платить за managed-платформу на каждый эфир. Обзор конфигураций под такой сценарий — в статье выделенный сервер для стриминговой платформы: конфигурация и цена.

Чек-лист подготовки к разовому пиковому эфиру

Разовое событие нельзя протестировать «по факту» — все проверки нужно закрыть заранее:

1. Посчитайте канал под ожидаемый пик, а не под среднюю аудиторию — по формуле «зрители на качество × битрейт качества» с запасом 30-50%, как описано в статье про расчёт полосы на зрителя, упомянутой выше.
2. Поднимите лимиты соединений на сервере заранее — ulimit, worker_connections, системные лимиты сетевого стека — и проверьте их реальным нагрузочным тестом, а не только на бумаге.
3. Проведите нагрузочный тест с эмуляцией реального числа зрителей до эфира — инструментами вроде синтетических HLS-клиентов, которые действительно открывают ожидаемое число параллельных соединений и запрашивают сегменты в реальном темпе, а не просто нагружают канал синтетическим трафиком.
4. Решите заранее, где проходит раздача зрителям — напрямую с вашего сервера, через CDN поверх вашего origin, или полностью через managed-платформу — и настройте это решение до дня эфира, а не в процессе.
5. Заложите план Б на случай превышения ожидаемой аудитории: автоматическое переключение части зрителей на более низкое качество, очередь на подключение, либо заранее подключённый резервный канал раздачи.
6. Мониторьте в реальном времени во время самого эфира: утилизацию канала, число активных соединений, задержку и буферизацию у зрителей (если платформа это отдаёт), а не только «сервер жив / сервер не жив». Проблема на разовом эфире, замеченная через десять минут после начала, обычно означает, что часть аудитории эти десять минут провела с фризами картинки.

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

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