Масштабирование OTT: от 1 000 до 1 000 000 зрителей

Кратко

Число, которое определяет, как устроена OTT-платформа (over-the-top – доставка видео по открытому интернету), – это не сколько у вас тайтлов, а сколько людей нажимают «играть» в один и тот же момент; это называется конкурентность, и переход от тысячи одновременных зрителей к миллиону почти ничего не меняет в коде и почти всё – в доставке. Видеопуть (data plane) растёт с сырой полосой: миллион зрителей по 4 Mbps – это около 4 терабит в секунду, уходящих из сети доставки (CDN), поэтому высокий коэффициент cache-offload и более одного CDN – это функции выживания, а не оптимизации. Путь «решать и записывать» (control plane – вход, права, биллинг, аналитика) растёт с числом запросов в секунду и со штормами входа, поэтому он строится под автоскейлинг и под поглощение thundering herd live-премьеры, когда все приходят в одни и те же шестьдесят секунд. Эта статья показывает арифметику конкурентности, рычаги, которые сглаживают кривую затрат, и как планировать ёмкость и под предсказуемый трафик каталога, и под непредсказуемые live-всплески.

Почему это важно

Если вы основатель медиапроекта, продакт-менеджер или CTO стриминга, самая страшная строка в смете – это не разработка, а счёт в ту ночь, когда выходит ваше главное событие. Масштабирование – это место, где OTT-платформы либо зарабатывают маржу, либо тихо её теряют: тот же поток, что стоит пару сотен долларов в месяц для небольшой аудитории, может стоить десятки тысяч долларов в час при миллионе одновременных зрителей, а control plane, который ни разу не нагружали штормом входа, рухнет ровно в тот момент, когда смотрит больше всего людей. Статья даёт вам модель и числа, чтобы спланировать ёмкость до подписания контракта с CDN, говорить с инженерами и не купить неподходящую архитектуру, и отличить платформу, спроектированную под масштаб, от той, что просто работает в демо. Скачиваемый воркшит по планированию ёмкости позволяет просчитать арифметику для вашей аудитории.

Конкурентность – главное число, а не размер каталога

Первый инстинкт новичка в стриминге – оценивать платформу по объёму контента. Это неверная ось. Каталог из десяти тысяч фильмов, лежащий в хранилище, стоит почти ничего; деньги стоят люди, которые смотрят его одновременно. Самое важное число ёмкости в OTT – это конкурентность: количество потоков, доставляемых одновременно в данный момент. Платформа с миллионом зарегистрированных пользователей, но всего пятью тысячами смотрящих сейчас – это платформа на пять тысяч конкурентности, и именно под это число считается каждое решение по доставке.

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

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

Арифметика миллиона зрителей

Числа делают это конкретным, поэтому посчитаем вслух. Базовая величина – битрейт на зрителя: поток 1080p (Full HD) на современном кодеке идёт около 4 мегабит в секунду (Mbps). Чтобы найти общую пропускную способность, которую должна выдержать доставка, умножьте битрейт на зрителя на конкурентность:

1 000 000 зрителей × 4 Mbps = 4 000 000 Mbps = 4 терабита в секунду (Tbps)

Четыре терабита в секунду – это стена воды, которую CDN должен выталкивать непрерывно, пока идёт событие. Это про пропускную способность. Чтобы получить стоимость, переведём в гигабайты, потому что CDN тарифицируют за гигабайт egress – данных, отправленных зрителям. Один зритель-час при 4 Mbps – это:

4 Mbps × 3 600 с = 14 400 мегабит = 1 800 мегабайт ≈ 1,8 ГБ на зритель-час

Значит, миллион зрителей, смотрящих один час, двигают:

1 000 000 × 1,8 ГБ = 1 800 000 ГБ = 1,8 петабайта за один час

При показательной скидочной ставке egress $0,04 за гигабайт (высокий объём; цены egress ступенчатые, зависят от коммита и меняются – см. ниже) этот один час стоит:

1 800 000 ГБ × $0,04 = $72 000 за один час события

Семьдесят две тысячи долларов в час – вот почему масштабирование это вопрос маржи, а не фичи. Та же арифметика при тысяче одновременных зрителей – это $72 в час, погрешность округления. В логике платформы между двумя случаями ничего не изменилось; изменился только множитель. Полная картина затрат – хранилище, кодирование, DRM – в статье модель стоимости OTT; здесь мысль уже: egress доминирует на масштабе, а egress – функция конкурентности.

Замечание о самой ставке egress, потому что это самое неверно цитируемое число в стриминге. Egress CDN – никогда не единая универсальная цифра. Она ступенчатая (ставка за гигабайт падает с ростом месячного объёма), зависит от коммита (годовые обязательства открывают более низкие ставки) и часто полосовая составляющая считается по 95-му перцентилю вашей пропускной способности, а не по среднему – то есть несколько коротких всплесков могут задать ставку на весь месяц. Amazon CloudFront, например, начинается с ~$0,085/ГБ в первой ступени в США и падает ниже $0,040/ГБ на больших объёмах, а коммиты экономят до 30% (цены AWS CloudFront, 2026). Всегда моделируйте свою ступень и фиксируйте дату. Инженерия этого счёта – в инженерии стоимости CDN.

Нажмите, чтобы увеличить

Рычаг, сгибающий кривую: cache offload

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

Мера того, насколько хорошо это работает, – cache-hit ratio (или origin offload): доля байтов, отданных зрителям из кэша, а не из вашего origin. Если 95% байтов отдаются из кэша, origin – авторитетное хранилище, из которого всё строится, – производит лишь 5% трафика, и ваша самая дорогая инфраструктура сжимается в двадцать раз. Практика индустрии целит в cache-hit ratio выше 85%, а здоровые live-платформы – далеко за 90% (рекомендации Fastly и CacheFly по origin-offload, 2024). Арифметика прямая: то же событие на 4 Tbps при 95%-offload кладёт на origin лишь 200 Gbps вместо 4 Tbps.

Поэтому конкурентность, вопреки интуиции, может делать доставку дешевле на зрителя, а не дороже. Live-событие, где все смотрят один поток в один момент, – лучший возможный случай для кэша: одна выборка, отданная всем. Тяжёлый случай – обратный: большой каталог редко смотримых тайтлов, где каждый запрос – за разным, и кэш холодный. Этот «длинный хвост» – причина того, почему video-on-demand (VOD) и live масштабируются по-разному; различие разобрано в Live против VOD: два конвейера.

Origin shielding – защита источника истины

Даже с эдж-кэшами на масштабе появляется проблема. У большого CDN десятки эдж-локаций, и при промахе кэша каждая независимо просит у origin один и тот же сегмент. Origin, который должен выполнять тяжёлую работу вроде упаковки «на лету» (just-in-time packaging), может захлебнуться от десятков одновременных одинаковых запросов – классический thundering herd. Лечение – единый промежуточный кэш, через который ходят все эджи; он называется origin shielding (Amazon CloudFront Origin Shield, Cloudflare Tiered Cache, Fastly Shield POPs). С шилдом десятки промахов эджей схлопываются всего в один запрос к origin на объект. Amazon сообщает, что клиенты, использующие Origin Shield для live-стриминга и multi-CDN, видят снижение нагрузки на origin до 57% (AWS, анонс Origin Shield, 2020). Более глубокая механика – в origin и origin shielding.

Нажмите, чтобы увеличить

Две плоскости масштабируются по разным осям

Вот идея, которая упорядочивает всё планирование ёмкости: OTT-платформа – это две системы, масштабирующиеся по разным мерам, и их путаница – самая частая ошибка масштабирования.

Data plane – путь, по которому идут байты видео: кодирование, упаковка, origin, CDN, плеер. Он растёт с полосой: терабиты в секунду, гигабайты egress. Его стоимость и ёмкость – функция конкурентность × битрейт, а главный рычаг – cache offload, как мы только что видели.

Control plane – всё, что решает и записывает, не пропуская через себя видео: вход и идентичность, права (может ли этот аккаунт смотреть этот тайтл, здесь, сейчас?), биллинг, решение по рекламе, метаданные и аналитика. Он растёт не с полосой, а с запросами в секунду: сколько входов, запросов лицензий, проверок прав и аналитических биконов прилетает каждую секунду. Четырёхмегабитный видеопоток и крошечный килобайтный запрос «можно смотреть?» живут в совершенно разных вселенных стоимости. Control plane двигает почти никаких данных, но при миллионе одновременных зрителей он должен ответить на миллионы мелких вопросов в узком окне.

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

Нажмите, чтобы увеличить

Thundering herd: когда миллион людей приходит разом

Установившаяся конкурентность – лёгкая часть. Тяжёлая – кривая прихода, то, как быстро появляются зрители. Популярный VOD-каталог плавно наращивает и снижает аудиторию в течение дня, и ёмкость может следовать за ней мягко. Live-премьера или спортивный матч делают обратное: аудитория может прыгнуть от почти нуля к пику в первые шестьдесят секунд после старта, когда все жмут «играть» в считаные мгновения друг за другом. Этот синхронный наплыв – thundering herd, и он нагружает control plane куда сильнее, чем data plane.

Подумайте, что происходит в эту минуту. Сотни тысяч приложений одновременно открывают сессию, проверяют права, запрашивают DRM-лицензию и начинают слать аналитику. Видеоэдж это поглощает, потому что все просят один и тот же первый сегмент – лучший случай для кэша. Но control plane получает сотни тысяч разных мелких запросов за секунды: настоящий всплеск трафика того рода, под которым валятся недооснащённые сервисы. Финал ICC T20 World Cup 2026 на JioHotstar, по сообщениям, достиг около 821 миллиона одновременных зрителей (Indian Television, март 2026) – аудитория, приходящая волной, в которую ни одна реактивная система не успеет масштабироваться.

Ответ – снабжать ёмкостью до кривой, а не в ответ на неё. Это делают три приёма. Предиктивный автоскейлинг поднимает ёмкость control plane до события по ожидаемой кривой, а не ждёт, пока появится нагрузка; JioHotstar, по инженерным отчётам, использовал ML-управляемый, лестничный автоскейлинг на Kubernetes, прогревающий ёмкость под известные крикетные паттерны (инженерные публикации, 2026). Прогрев (pre-warming) просит CDN заранее разложить контент и поднять ёмкость на эдже до открытия дверей. А очереди и мягкая деградация – комната ожидания, повтор с backoff, короткая статичная картинка вместо жёсткой ошибки – держат платформу на ногах, когда спрос ненадолго превышает даже щедрый план. Специфика live – в live-доставке и всплеске премьеры.

Частая ошибка: считать под среднее, а не под пик. Платформа, рассчитанная на среднюю конкурентность, будет с комфортом переоснащена 95% времени и катастрофически недооснащена во время единственного события, которое важно. Ёмкость считается под пик кривой прихода плюс запас, а не под дневное среднее. Весь бизнес-кейс live-события можно загубить control plane, рассчитанным как VOD-сервис.

Больше одного CDN: failover и content steering

При тысяче одновременных зрителей один CDN – нормально. На масштабе ставка на единственный CDN – это пари, что у одной компании никогда не будет плохой ночи в вашем крупнейшем рынке, и это пари в конце концов проигрывается. Серьёзные платформы доставляют через больше одного CDN по двум причинам: устойчивость (если один деградирует на всплеске, трафик уходит на другой) и охват (разные CDN сильнее в разных регионах). Рекордные стримы JioHotstar шли через четыре CDN – Akamai, Amazon CloudFront, Cloudflare и собственный Jio CDN – с автоматическим failover между ними менее чем за 250 миллисекунд (инженерные публикации, 2026).

Механизм, делающий multi-CDN практичным без переписывания плееров, – content steering, теперь опубликованный стандарт. Небольшой удалённый сервис выдаёт плееру ранжированный список источников доставки и может менять этот список на старте или в середине потока, переводя зрителей с буксующего CDN на здоровый без прерывания воспроизведения. Он стандартизован так, что один и тот же steering-сервер управляет и HLS-, и DASH-плеерами: HLS объявляет его тегом master-плейлиста EXT-X-CONTENT-STEERING с атрибутом SERVER-URI, указывающим на steering-манифест (Apple HLS Content Steering Specification), а DASH определяет эквивалент в ETSI TS 103 998 v1.1.1 (DASH-IF Content Steering, январь 2024), реализованный в референсном плеере dash.js. Поскольку протокол общий, один управляющий сервис может в реальном времени рулить всей вашей аудиторией между CDN. Сама архитектура – origin, шилды, оркестрация – разобрана в статье о multi-CDN раздела Video Streaming.

Минимальный тег content steering в HLS выглядит так:

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://steer.example.com/manifest.json",PATHWAY-ID="cdn-a"
#EXT-X-STREAM-INF:BANDWIDTH=4000000,PATHWAY-ID="cdn-a"
https://cdn-a.example.com/1080p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4000000,PATHWAY-ID="cdn-b"
https://cdn-b.example.com/1080p.m3u8

Два значения PATHWAY-ID – это два CDN; steering-сервер решает, для каждого зрителя и каждого момента, какому пути отдать предпочтение.

Задержка тоже рычаг масштаба

Есть ещё одно измерение, играющее против вас, – задержка (latency). Low-latency live-стриминг – снижение задержки «от стекла до стекла» с 20–30 секунд стандартного HLS до 3–8 секунд Low-Latency HLS (LL-HLS) и Low-Latency DASH – это то, что делает live-спорт по-настоящему «живым». Но низкая задержка покупается более короткими сегментами и более частыми запросами, а это значит больше запросов в секунду на ваш эдж и ваш control-путь. Выбор агрессивно низкой задержки при миллионе конкурентности умножает мелко-запросную нагрузку, которую надо заложить. Это реальное продуктовое решение с реальной ценой по ёмкости, а не бесплатный тумблер; компромисс детально разобран в статье о low-latency раздела Video Streaming.

Планирование ёмкости на практике

Собирая всё вместе, планирование ёмкости для платформы, которой надо вырасти с тысячи до миллиона зрителей, сводится к короткой дисциплинированной последовательности. Первое – спрогнозировать пиковую конкурентность, а не среднюю: единственное наибольшее число одновременных потоков, которое вы ждёте, отдельно для устойчивого трафика каталога и для любого live-всплеска. Второе – посчитать пропускную способность и egress data plane из этого пика (конкурентность × битрейт, затем × часы просмотра для стоимости) и рассчитать CDN и origin под пик с реалистичным допущением по cache-offload. Третье – рассчитать control plane в запросах в секунду под кривую прихода и выбрать предиктивный автоскейлинг для известных событий. Четвёртое – проектировать под отказ: больше одного CDN с content steering, origin shielding и мягкая деградация, чтобы всплеск, превысивший план, гнулся, а не ломался. Пятое – нагрузить всё это на целевой пик до события, потому что единственный способ узнать, что платформа масштабируется, – довести её туда в репетиции, а не в проде в самую важную ночь. Референсная архитектура, связывающая эти компоненты, – эталонная архитектура OTT.

Где здесь Фора Софт

Фора Софт делает видеостриминг и OTT/Internet TV с 2005 года – 250+ выпущенных проектов для 400+ клиентов. Повторяющаяся задача масштабирования, которую нас нанимают решать, – это разрыв между платформой, работающей в демо, и той, что держится, когда аудитория приходит разом: расчёт data plane под пиковую конкурентность, инженерия cache offload и multi-CDN-доставки, чтобы egress оставался посильным, и построение control plane – права, биллинг, аналитика – так, чтобы он поглощал thundering herd live-премьеры. Мы нейтральны к CDN и DRM-сервисам; мы переводим требование масштаба в архитектуру, а затем нагружаем её на реальный пик до события, а не после.

Главное

• Платформу OTT задаёт конкурентность – одновременные потоки, – а не размер каталога.
• Миллион зрителей по 4 Mbps – это ~4 Tbps и ~$72 000 в час egress.
• Cache offload выше 85–95% – рычаг, сгибающий кривую, а не более дешёвая ставка.
• Data plane растёт с полосой; control plane растёт с числом запросов в секунду.
• Live-премьеры нагружают control plane через thundering herd – снабжайте заранее, не реактивно.
• Multi-CDN со стандартизованным content steering (ETSI TS 103 998) – функция выживания масштаба.

Что почитать дальше

• Модель стоимости OTT: во сколько реально обходится платформа
• Инженерия стоимости CDN: egress, коммиты и 95-й перцентиль
• Эталонная архитектура OTT: полная картина