Масштабируемый видеостриминг и видеоконференции в 2026: архитектура, расходы и стратегия стабилизации

Почему этот гид написала Фора Софт

Фора Софт уже 21 год создаёт продукты для видео в реальном времени и стриминга. В нашем портфолио — масштабная онлайн-обучалка BrainCert, трансляции бильярда на уровне телевидения на Kozoom, телемедицина, видеозалы суда на базе WebRTC, OTT-платформы и системы видеонаблюдения. Мы построили, проверили и спасли больше таких систем, чем можем точно посчитать.

Этот гид — то, что мы рассказываем клиентам в первую неделю проекта по масштабированию: чем на самом деле отличаются стриминг и видеоконференции, где платформы чаще всего дают сбой, как правильно оценить нагрузку и как выглядит реальное решение. В основе — технологии, которые мы используем в продакшене: bare-metal-серверы Hetzner серии AX для транскодинга, Cloudflare на edge, mediasoup и LiveKit для SFU-кластеров, управляемый Kubernetes там, где он себя окупает, а также сравнение кастомной разработки с managed-решениями уровня Agora.

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

Стриминг и конференции — две разные задачи масштабирования

Решения по масштабированию начинаются с одного вопроса: какой трафик-паттерн у продукта? Broadcast (один публикующий, много зрителей) и конференции (много публикующих, много зрителей) выглядят похоже на питч-слайде, но в продакшене ведут себя совершенно по-разному.

Почему видеоплатформы реально ломаются — и почему «купить ещё серверов» не помогает

Когда видеоплатформа падает на вебинаре, финале по крикету или виртуальном уроке, проблема почти никогда не в общем количестве CPU. Почти всегда это один из пяти структурных сбоев.

1. Один origin раздаёт поток каждому зрителю. CDN отсутствует или его мощности недостаточно. Выходной трафик (egress) достигает предела пропускной способности первой сетевой карты; буферизация растёт от региона к региону.

2. Транскодер на универсальной VM с общими ресурсами. ABR-лестницы требуют много CPU. Запуск 1080p60 H.264 на общей VM класса t — почти гарантированный источник обрывов потока.

3. SFU размером «как было вчера». SFU для конференций ограничены либо исходящей полосой пропускания, либо количеством портов. Один узел легко справляется с 300–1000 одновременных аудио- и видеопотоков; при превышении этого лимита требуется каскадирование или автоматическое масштабирование.

4. Stateful-серверы приложений. Если состояние сессии хранится в процессе приложения, горизонтально масштабировать его без sticky-сессий или общего хранилища невозможно. Состояние нужно выносить в Redis, Postgres или отдельное хранилище сессий.

5. Никакой наблюдаемости. Нет дашборда по доле ребуферизации, нет P95 времени старта, нет алерта на CPU SFU — вы узнаёте о проблеме из Twitter. Мониторинг стоит дёшево. Перестраиваться в огне — не вариант.

Простой стоит дорого. По данным Gartner и Information Technology Intelligence Consulting, средняя стоимость простоя в корпоративных системах — от 420 тыс. ₽ до 675 тыс. ₽ в минуту. В случае с потребительским live-стримом потери включают не только упущенную рекламу и отписки, но и ущерб репутации бренда. Как правило, один точечный аудит обходится дешевле, чем последствия следующего сбоя.

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

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

1. Stateless-вычисления, stateful-хранилище. API-сервисы не хранят состояние пользователей в памяти. Сессии — в Redis, медиа-данные — в SFU или origin, бизнес-данные — в Postgres. Любой сервис может завершиться или масштабироваться без привязки к конкретному узлу.

2. Доставка через CDN. Для вещания: HLS/ DASH пакетируются на origin, кэшируются на CDN (Cloudflare, Fastly, Akamai, AWS CloudFront). 95–99% трафика зрителей не доходит до origin. Для низколатентной передачи — LL-HLS или WebRTC через CDN (Cloudflare, Phenix), чтобы задержка оставалась ниже секунды.

3. Адаптивный битрейт (ABR). Лестница рендиций (например, 240p, 480p, 720p, 1080p при 400 Кбит/с / 1,2 Мбит/с / 3 Мбит/с / 6 Мбит/с) позволяет каждому зрителю выбрать максимально возможное качество, которое выдержит его интернет-соединение. Доля ребуферизации снижается на порядок.

4. Горизонтальный SFU с каскадом. У каждого SFU есть ограничение — например, 500 одновременных медиа-потоков. Когда количество участников в комнате превышает это число, поток перенаправляют на второй SFU. mediasoup, LiveKit, Jitsi и Janus поддерживают такую схему — различия только в деталях реализации.

5. Транскодинг на правильном железе. Для серьёзного вещания мы используем транскодеры на «голом» железе Hetzner серии AX с GPU (NVENC) или выделенным CPU. На пиках нагрузки подключаем эластичный burst в AWS MediaConvert или Cloudflare Stream. Транскодинг на общих виртуальных машинах — ловушка.

6. Мониторинг и плавная деградация. Дашборд по P95 времени старта, доле ребуферизации, error rate по регионам, загрузке CPU SFU и полосе TURN. Алерты при достижении 70% ёмкости. Если что-то идёт не так — сначала отключаем второстепенное: симулькаст-слои, 4K-рендеры, сложные фильтры. Базовый поток должен работать.

Эталонная архитектура масштабируемой видеоплатформы

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

Рисунок 1. Путь broadcast (сверху) и путь конференций (снизу) используют общую авторизацию, биллинг и мониторинг, но различаются на уровне медиа-плоскости.

Путь трансляции (OTT, прямые трансляции)

Ingest (RTMP, SRT или WebRTC-WHIP) → ферма транскодеров, выдающая ABR-лестницу → origin, который пакетирует поток в HLS/ДASH + CMAF LL → edge CDN → плеер. Типичная единица масштабирования — региональная ферма транскодеров под пиковый ingest, плюс автомасштабируемая группа на всплески.

Путь конференций (встречи, комнаты, интерактивный live)

WebRTC-пир → кластер SFU → (опционально) каскадный SFU → WebRTC-пир. TURN-серверы масштабируются отдельно, в зависимости от количества клиентов за симметричным NAT (по правилу большого пальца — 15–20% пользователей нуждаются в TURN). Для интерактивных live-продуктов (например, watch-along, e-learning) этап конференции может переходить в режим трансляции через server-side RTMP-egress.

Общий слой (авторизация, биллинг, аналитика)

Идентификация, биллинг, пользовательские записи и аналитика используются в обоих путях. Эти сервисы stateless, горизонтально масштабируемые, находятся за региональным балансировщиком и подключаются к реплицированному Postgres или Aurora. События аналитики поступают в Kafka или её управляемый аналог, затем попадают в BigQuery или Redshift для формирования отчётов, а также в хранилище временных рядов (например, Prometheus или Grafana Cloud) для операционной аналитики.

Бюджеты задержки, которые определяют архитектуру

До того как выбирать инструменты, определите допустимое время задержки. Всё остальное зависит от этого.

Когда платформа уже горит: план стабилизации

Большинство платформ, которые мы аудируем, не сломаны навсегда. У них два-три узких места, на которые приходится подавляющая часть инцидентов. Точечная работа на 2–6 недель даёт запас в 10 раз. Стандартная последовательность:

Неделя 1 — аудит и базовые метрики. Измеряем P95 старт, долю ребуферизации, загрузку CPU SFU, исходящий трафик с origin-сервера, размер пула соединений с БД. Выявляем три главных узких места. Письменный аудит кода и архитектуры превращается в план действий.

Недели 1–2 — поставить CDN перед origin. Быстрая победа для broadcast. Cloudflare или Fastly на HLS/DASH-эндпоинте сокращают исходящий трафик origin на 95–99% почти мгновенно.

Недели 2–3 — контейнеризация и автомасштабирование. Stateless-сервисы переводятся в контейнеры (Docker + Kubernetes или ECS). Автомасштабирование настраивается по кастомным метрикам — например, по загрузке CPU SFU или глубине очереди транскодера, а не только по общему использованию CPU.

Недели 3–4 — вывести транскодинг из приложения. Транскодеры переносятся на выделенные серверы или в managed-услуги (AWS MediaConvert, Cloudflare Stream, Wowza). Обработка идёт через очередь, а не в рамках самого запроса.

Недели 4–5 — каскадировать SFU. Для конференций. Каждый SFU ограничен известной полосой или количеством участников; комнаты каскадируются по узлам, маршрутизация — по географии.

Недели 5–6 — наблюдаемость и runbooks. Дашборды Grafana по KPI ниже. Алерты при достижении 70% ёмкости. Runbooks для пяти самых частых инцидентов. Blue-green или canary-реплики, чтобы релизы перестали быть авариями.

Модель затрат: куда на самом деле уходят деньги

Два паттерна, которые нужно запомнить:

В broadcast доминирует egress. Когда у вас уже есть CDN, вычислительные ресурсы стоят копейки, а трафик — дорого. На большом масштабе цена — 0,3–3 ₽ за ГБ в зависимости от контракта с CDN и региона. Поток на 2 Мбит/с при просмотре в течение часа — это около 900 МБ, то есть примерно 0,3–2,7 ₽ egress на час просмотра. Транскодинг — это фиксированная стоимость серверов, распределённая между всеми зрителями.

В конференциях доминирует вычислительная мощность. Управляемые сервисы (Agora, Twilio, Daily, LiveKit Cloud) тарифицируют по числу одновременных пользователей или по минутам — типичный управляемый WebRTC обходится в 0,2–0,7 ₽ за минуту участия. Самостоятельный SFU на Hetzner или Equinix может быть в 3–5 раз дешевле при стабильной нагрузке, но требует собственной команды разработчиков.

Точка перехода: self-hosted SFU становится выгоднее managed-решения при нагрузке около 30–50 тысяч минут участников в день — точное значение зависит от географии. Ниже этого порога managed-конференции почти всегда дешевле с учётом общей стоимости владения, включая затраты на инженеров.

Мини-кейс: стабилизация платформы для онлайн-обучения с живым видео

Ситуация. Live-видео-решение для e-learning, построенное на монолитном Node-сервере с одним SFU, не справлялось с нагрузкой в 300–400 одновременных пользователей в вечерний час пик в Азии. Вебинары превращались в аудио, участники отключались, а CSAT в магазине приложений резко упал.

Что мы изменили за шесть недель. Перенесли безсостоятельные сервисы за ALB и настроили автомасштабирование в Kubernetes. Развернули кластер SFU (mediasoup) из четырёх узлов — два в Европе, один на восточном побережье США и один в Сингапуре. Выделили TURN в отдельный пул. Настроили дашборды в Grafana по задержкам запуска (P95), сбоям подключения и нагрузке CPU на SFU, с оповещениями при достижении 70% загрузки.

Результат. Стабильные 8–10 тыс. CCU на том же коде продукта, P95 подключения — меньше 1,5 с, доля ребуферизации снизилась с 4,1% до 0,6%. Месячная стоимость инфраструктуры выросла примерно на 450 тыс. ₽, но удалось избежать переписывания, оценённого в 30 млн ₽, и запустить новый корпоративный тариф. Такая схема работает и в масштабируемых системах видеонаблюдения, и в интерактивных live-инструментах в целом.

Хотите такую же оценку для своей платформы? Позвоните нам по номеру +7 (911) 236-51-91 — обычно после разговора мы оставляем одностраничный список действий, который можно начать выполнять уже в следующем спринте.

Фреймворк решений — масштабируйте видеоплатформу за пять вопросов

В1. Broadcast или интерактив? Один на многих → HLS + CDN. Многие на многих с задержкой до 200 мс → WebRTC SFU. Гибрид (например, живой урок с вопросами и ответами) → комбинируем оба решения, спроектировав их вместе.

В2. Какой реальный бюджет задержки? Запишите его в миллисекундах. Не позволяйте никому потом «передоговориться» о нём без перепроектирования пайплайна.

В3. Какой пик одновременных пользователей? Пиковый CCU — это число, под которое вы настраиваете инфраструктуру. Обычный трафик не показывает проблем. Моделируйте худшую минуту худшего дня, который вам важен.

В4. Managed или self-hosted медиа? До примерно 30 тысяч минут участников в день managed-решение выгоднее по общей стоимости. При нагрузке выше этого порога self-hosted окупается за квартал, если у вас есть собственная команда.

В5. Кто на дежурстве? Видео работает 24/7. Если нет чёткой ротации и инструкций — вы заплатите простоями вместо зарплат.

Пять подводных камней почти на каждом проекте по масштабированию

1. Один origin для broadcast. Без CDN, без кэш-слоя. Первые 500 зрителей перегружают сетевой интерфейс; качество падает по регионам.

2. Stateful-серверы приложений. Состояние пользователя или сессии привязано к процессу. Горизонтальное масштабирование невозможно; sticky-сессии становятся новым узким местом.

3. Один SFU на весь мир. Отлично работает до первого глобального события. Каскад и региональные SFU становятся необходимыми при нагрузке выше ~500 одновременных потоков.

4. Транскодинг на VM приложения. Всплески нагрузки на CPU приводят к падению API. Транскодинг следует вынести на отдельный флот или использовать managed-сервис.

5. Нулевая наблюдаемость. Нет дашборда по ребуферизации, нет гистограммы времени запуска, нет алерта на загрузку CPU SFU. О проблеме узнаёте только из жалобы клиента в Twitter — и то не раньше.

KPI: что отслеживать каждую неделю

KPI качества. P95 времени запуска — менее 3 с (broadcast) или менее 1,5 с (интерактив). Доля ребуферизации — менее 1%. Отказы при запуске видео — менее 0,5%. MOS — не ниже 4,0 (для конференций). P95 glass-to-glass — в пределах бюджета сценария.

Бизнес-метрики. Количество одновременных зрителей, продолжительность сессии, доля досмотров, отток по регионам, стоимость часа просмотра или минуты участия. Эти показатели подтверждают эффективность всей программы.

KPI надёжности. Загрузка CPU origin и SFU (алерт при 70%), использование полосы TURN, ошибка rate по регионам, задержка подключения на уровне P99, доля неудачных деплоев, MTTR — не более 30 минут. Относитесь к видеоплоскости как к платёжной системе: если она не работает — теряется выручка.

Когда не стоит строить кастомное масштабирование

Ранний MVP с непредсказуемым спросом. Используйте managed-сервисы (Mux, Cloudflare Stream, LiveKit Cloud, Agora, Daily), чтобы сэкономить время. Кастомная разработка окупается, когда у вас уже есть стабильный рост.

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

Команда без опыта в WebRTC и стриминге. Самостоятельные SFU и транскодеры не прощают ошибок. Если такого опыта нет — и нанять специалиста не получится — лучше остаться на управляемом решении.

Стандартный сценарий внутри чужой экосистемы. Виджет встреч в EMR-системе обычно работает на Amazon Chime SDK или Zoom SDK — а не на собственном SFU-флоте.

FAQ

Что вообще значит «масштабируемый» для видеоплатформы?

Это значит, что система может вырасти по числу одновременных пользователей или сессий как минимум в десять раз без пропорционального роста стоимости, задержек и сбоев. На практике: P95 старта и доля ребуферизации остаются в допустимых пределах, загрузка CPU SFU и origin держится ниже 70%, а добавление мощности сводится к масштабированию группы, а не к повторному развёртыванию стека.

Строить на WebRTC, на HLS или на обоих?

Broadcast (VOD, спорт, концерты) с допустимой задержкой 5–30 с — HLS/DASH + CDN. Групповые звонки, интерактивные комнаты, залы суда, телемедицина — WebRTC SFU. Интерактивный live (онлайн-классы, фитнес-стримы, аукционы) обычно требует обоих: WebRTC для активных участников и HLS/LL-HLS для пассивной аудитории.

Почему маленькие платформы так легко ломаются при росте?

Ранние версии обычно полагаются на один origin, stateful-процесс на Node и общую виртуальную машину, которая обслуживает и API, и транскодинг. Под реальной нагрузкой все три компонента начинают падать. Проблему нужно решать не масштабированием, а архитектурой — использовать CDN, stateless-сервисы, выделить транскодинг в отдельный сервис и внедрить мониторинг.

Масштабируемость — это просто докупить серверов?

Нет. Железо не решает структурное узкое место — оно лишь делает падение более заметным. Можно поставить десять серверов за одним origin и всё равно направлять 100% зрителей туда же. Сначала инвестируйте в CDN, stateless-архитектуру и мониторинг — и только потом увеличивайте вычислительные мощности.

Можно ли стабилизировать перегруженную систему без полного переписывания?

В большинстве случаев — да. Точечная программа на 2–6 недель — CDN, stateless-сервисы, каскад SFU, выделенный транскодинг и мониторинг — обычно даёт запас по безопасной нагрузке в 10 раз. Полное переписывание иногда необходимо (например, если всё приложение построено вокруг сломанного WebSocket-сигналинга), но это исключение.

Сколько занимает масштабирование видеоплатформы?

Быстрые победы (CDN перед origin, асинхронный транскодинг, базовые дашборды) — несколько дней. Полная программа стабилизации с каскадом SFU, автомасштабированием, blue-green-деплоями и наблюдаемостью — 4–8 недель для большинства платформ. Кастомная разработка с нуля — 4–9 месяцев в зависимости от объёма.

Как понять, что моя платформа действительно масштабируется?

Проведите нагрузочный тест на 2× ожидаемого пика и отслеживайте KPI. P95 старта остаётся < 3 с, ребуферизация < 1%, ни один регион не опускается ниже целевого качества, CPU SFU держится < 70%. Сюда же — chaos-тест (убить регион, уронить узел): если платформа выдержала, всё хорошо. Если хоть что-то покраснело — у вас есть пробел в масштабировании.

Делает ли Фора Софт бесплатный аудит масштабируемости?

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

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

Готовы масштабировать видеоплатформу, не сломав её?

Масштабируемость в видео — это не про «купить ещё серверов». Это набор структурных решений: stateless-вычисления, доставка через CDN, ABR, горизонтальные SFU, выделенные транскодеры, серьёзный мониторинг. У стриминга и видеоконференций — свои подходы; пытаться решить обе задачи одной архитектурой — самая дорогая ошибка в этой области.

Большинство платформ, которые сейчас «горят», можно стабилизировать за шесть недель. Оставшимся 20% нужна серьёзная переработка архитектуры, и обычно её стоит начинать только после того, как стабилизация даст время на нормальное планирование. В любом случае — измеряйте правильные KPI, включайте людей в процесс принятия решений и проектируйте систему с учётом реальной кривой роста, а не той, на которую вы надеетесь.