Разработка ПО для видеоконференций: руководство по масштабируемым решениям

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

Мы более 10 лет проектируем, разрабатываем и масштабируем платформы видеоконференций, реализуя комплексные решения для разработки ПО для видеоконференций. Среди продуктов, которые запустили наши инженерные команды:

• BrainCert (100 000+ одновременных пользователей, 500 млн+ записанных минут, 10 дата-центров, 4 награды Brandon Hall)
• ProVideoMeeting (WebRTC + SIP-мост + электронная подпись)
• CirrusMED (телемедицина с соответствием HIPAA, 1 500+ активных пациентов, шифрованная запись)

Это руководство вобрало в себя более 500 архитектурных решений, провалов масштабирования, багов согласования кодеков и регуляторных аудитов и превратило их в работающие паттерны. Выбираете между Agora и собственным SFU или ловите джиттер на 50 000 одновременных пользователей — это та самая шпаргалка, которая вам нужна.

Что делает видеоконференцию масштабируемой

Современная разработка ПО для видеоконференций требует понимания того, что масштабируемость измеряется по трём независимым осям:

1. Количество одновременных участников в одном звонке

Небольшие сценарии (до 1 000 пользователей) обслуживаются P2P или Mesh-топологиями. Средний масштаб (до 100 000 пользователей) требует Selective Forwarding Unit (SFU). Корпоративный масштаб (1 млн+) — это гео-распределённые кластеры SFU с RTT менее 150 мс во всех регионах и автомасштабированием.

2. Количество одновременных звонков во всей системе

Если на платформе одновременно идёт 10 000 звонков по 8 участников, активных медиапотоков уже 80 000. Это совсем другая задача, чем один общий созвон на 100 000 человек. Нужно планировать пулы соединений, память на каждый поток и нагрузку CPU на инстанс SFU.

3. Географическое распределение

Пользователь из Мумбаи, который подключается к SFU в Вирджинии, увидит RTT 300+ мс. Добавьте задержку кодека, джиттер-буфер и сетевые потери — и двухсекундный фриз почти гарантирован. Деплойте региональные кластеры SFU в US-East, US-West, EU, APAC и LATAM. Используйте anycast-DNS или геолокационный API, чтобы каждый пользователь попадал в ближайший SFU.

Основа WebRTC: строительные блоки

Медиапайплайн

Сигналинг

STUN, TURN и ICE

Согласование кодеков

Варианты архитектуры: P2P, Mesh, SFU, MCU

P2P (Peer-to-Peer)

Mesh

SFU (Selective Forwarding Unit) — основа современной разработки ПО для видеоконференций

MCU (Multipoint Control Unit)

Краткое сравнение архитектур

Архитектура	Максимум участников	Полоса на участника	Стоимость серверов	Задержка	Где применять
P2P	4	5–10 Мбит/с	0 ₽	<50 мс	Один на один, парное программирование
Mesh	8	2–5 Мбит/с	0 ₽	<100 мс	Небольшая команда, надёжные сети
SFU	100+	0,5–3 Мбит/с	0,37–1,5 ₽/мин	50–150 мс	Вебинары, обучение, общие собрания
MCU	50	0,3–1 Мбит/с	3,7–7,5 ₽/мин	100–200 мс	HIPAA и регулируемые отрасли, легаси-интеграции

CPaaS vs. кастомный WebRTC: как выбрать

CPaaS (Communications Platform as a Service)

Цены: Agora (0,74–1,49 ₽/мин), Daily.co (0,62–1,49 ₽/мин), 100ms (0,22–0,75 ₽/мин), Dyte (0,24–0,74 ₽/мин), Twilio (0,63 ₽/мин). Плюсы: не нужно своё железо, глобальные кластеры SFU включены, готовые шаблоны под комплаенс (HIPAA, GDPR), поддержка 24/7. Минусы: вендор-лок, ограниченная кастомизация, непредсказуемые счета на больших объёмах.

Кастомный WebRTC (SFU)

Стоимость: 0,37–0,75 ₽/мин на больших объёмах (self-hosted) или 0,75–3,7 ₽/мин с управляемым SFU (LiveKit Cloud, managed Mediasoup). Плюсы: полный контроль, кастомные UI/UX, тесная интеграция с бэкендом, комплаенс на ваших условиях. Минусы: 18–24 месяца инженерной работы, операционная поддержка 24/7, аудиты безопасности, своя инфраструктура TURN.

Гибрид: CPaaS для звонков, своё — для записей

Возьмите Agora или Daily для звонков в реальном времени (CDN + SFU). Записи держите у себя и обрабатывайте сами — транскрибация, диаризация, детекция объектов. Хороший вариант для e-learning, телемедицины, юридических компаний — там, где нужен контроль над комплаенсом и долгосрочным хранением.

Сигнальные серверы: оркестрация звонков

Сигнальный сервер — это мозг системы. Он отвечает за:

• Создание комнат и звонков: выдать ID комнаты, назначить регион SFU, выставить лимит участников, хранить метаданные.
• Обмен offer/answer: прокидывает SDP (Session Description Protocol) между участниками. Для задержки менее 200 мс используйте WebSocket.
• ICE-кандидаты: собирает STUN/TURN-кандидаты от каждого клиента и пересылает их другим, чтобы они нашли лучший сетевой маршрут.
• Переходы между состояниями звонка: отслеживает, кто подключился и вышел, контролирует лимиты полосы, запускает запись, фиксирует длительность звонка для биллинга.
• Аутентификация: JWT или OAuth2 для проверки, что пользователь имеет право зайти в комнату. Защищайтесь от перехвата сессии.

Что выбрать в стеке: Node.js (Socket.io, Express), Go (gRPC, Gin), Rust (Actix, Tokio). Закладывайте 50–100 мс на обмен offer/answer. Кэшируйте адреса SFU в Redis — не делайте DNS-запрос на каждый звонок.

Варианты SFU: LiveKit, Mediasoup, Janus, ion-sfu, Pion

LiveKit

Mediasoup

Janus

ion-sfu

Pion

TURN и STUN: преодоление NAT

Большинство корпоративных файрволов блокируют прямой P2P. Сигнальный сервер должен сообщать клиентам адреса STUN/TURN, чтобы те узнали свой публичный IP (STUN) и при провале прямого соединения ретранслировали медиа (TURN).

Бюджет на регион:

• 3–5 TURN-серверов (t2.medium, 2 vCPU, 4 ГБ RAM) — 6 000–11 000 ₽/мес за сервер.
• Исходящий трафик: 22–37 ₽ за ГБ (AWS, GCP, Azure). Каждый TURN-сервер тянет 50–100 тыс. одновременных потоков.
• Берите coturn (open-source) или коммерческие решения (Twilio, Xirsys, Netmanaged).
• Что мониторить: CPU, число соединений, полосу. Если средний RTT превышает 50 мс или потери пакетов выше 2%, добавляйте серверы или расширяйте ёмкость.

Отладка ICE: если клиент завис в состоянии «checking», значит он не смог пройти ни одну пару кандидатов. Типичные причины: TURN лежит, файрвол блокирует UDP 3478/5349, сигнальный сервер не отдаёт креды. Логируйте каждую неудачную пару кандидатов и настраивайте алерты.

Запись и транскрибация в масштабе

Запись — это отдельный пайплайн. Не смешивайте её с логикой SFU реального времени.

• Архитектура: SFU отправляет сырой RTP в демон записи (FFmpeg, JVB-рекордер от Jitsi или ваш собственный бинарь на Go). Пишите на локальный диск, заливайте в S3/GCS асинхронно.
• Битрейт: 1–5 Мбит/с на звонок в зависимости от разрешения и кодека. 100 одновременных звонков — 100–500 Мбит/с, 10–50 ТБ в сутки.
• Стоимость хранения: около 1,7 ₽ за ГБ в месяц (S3 Standard). 10 ТБ в сутки — порядка 525 000 ₽/мес.
• Транскрибация: Google Speech-to-Text (108 ₽/час), Azure Cognitive (75 ₽/час) или open-source Whisper (расходы на GPU). Задержка: либо в реальном времени (Google API), либо батчем (Whisper).
• Диаризация: определение, кто из участников говорит. Whisper v2 умеет это сам; для старых API подключайте pyannote или диаризацию AWS Transcribe.

Безопасность и регуляторные требования

1. Шифрование медиа: DTLS-SRTP (стандарт). Обмен ключами через DTLS-хэндшейк. Ключи ротируются на каждый звонок. Проверяйте отпечаток DTLS через сигналинг, чтобы предотвратить MITM.
2. Соответствие HIPAA: журналы аудита (кто, когда, длительность, объём данных), шифрованные записи, логи согласий, хранение данных только в США, ежегодный пентест, BAA с подрядчиками.
3. Соответствие GDPR: право на забвение (удаление записей в течение 30 дней), хранение данных только в ЕС или в выбранном облачном регионе, управление согласиями, оценка влияния на приватность, DPA с обработчиками.
4. SOC 2 Type II: ежегодный аудит, контроль изменений, реагирование на инциденты, журналы доступа, требования к шифрованию, оценка поставщиков.
5. Безопасность сигналинга: TLS 1.3 для всего трафика, JWT со сроком жизни менее 5 минут, rate-limit (100 запросов в секунду на IP), CSRF-токены для веб-приложений, CSP-заголовки против XSS.

Паттерны масштабирования до 1 млн+ пользователей

Как это работает на практике:

• Zoom: 19 дата-центров, 50 000+ инстансов SFU, географический балансировщик (anycast), автомасштабирование по регионам.
• Discord: 20 кластеров (на Pion/Go), каждый держит 1 млн+ одновременных соединений, событийная архитектура (Redis pubsub), голосовой кодек с низкой задержкой (Opus, кадры по 20 мс).
• Google Meet: gRPC + собственный кодек Velodyne, Spanner (глобально распределённая база), региональные SFU, маршрутизация через Andromeda SDN.

Чек-лист для деплоя:

• Мульти-региональный SFU: us-east-1, us-west-2, eu-west-1, ap-southeast-1, sa-east-1. Каждый регион работает независимо.
• Геолокационный API, чтобы направлять пользователей в ближайший SFU (целевой RTT <100 мс).
• Автомасштабирование: при 80% CPU или памяти → поднимаем новый инстанс SFU. Снимаем нагрузку, если простаивает 15 минут.
• Health-чеки: пинг SFU раз в 10 секунд, два неуспешных подряд — убираем из пула.
• Пайплайн записи — отдельный слой, масштабируется самостоятельно.
• Мониторинг: Prometheus (задержка, джиттер, потери), дашборды в Grafana, PagerDuty при ошибках выше 5%.

Разработка видеоплатформ с помощью AI

Большие языковые модели (Claude, GPT-4, Gemini) заметно ускоряют разработку видеоплатформ:

• Генерация кода: LLM пишет 70% бойлерплейта (сигнальный сервер, сервис креденшелов TURN, пайплайны записи). Инженеры просматривают и дорабатывают.
• Проектирование архитектуры: загружаете в LLM свои ограничения (1 млн пользователей, RTT 150 мс, стоимость 0,75 ₽/мин). На выходе — 10-страничный документ с диаграммами потоков, планированием ёмкости и сценариями отказа.
• Отладка: вставляете в чат алгоритм джиттер-буфера, LLM ловит крайние случаи (ошибки округления, переполнение буфера, обнуление таймстампа на 32 битах).
• Документация: автоматически генерирует API-документацию, описание архитектуры и ранбуки из комментариев и аннотаций типов.

Шаблон промпта для проектирования: «Я строю платформу видеоконференций. Масштаб: 100 000 одновременных пользователей, 50 звонков в секунду. Целевая задержка: менее 150 мс. Кодек: H.264 + Opus. Комплаенс: HIPAA. Бюджет: 375 000 ₽/мес на SFU. Предложи архитектуру (сигналинг, SFU, запись, TURN, базы данных). Включи планирование ёмкости.»

Кейс: путь BrainCert к 500 млн+ минут

BrainCert — это образовательная платформа, которой пользуются 100 000+ одновременных учеников и преподавателей. За 10 лет Фора Софт построила и масштабировала её видеоинфраструктуру:

• Годы 1–3: P2P WebRTC для маленьких групп (менее 8 человек). Низкая задержка, но непредсказуемое качество.
• Годы 4–5: миграция на self-hosted Janus SFU в трёх регионах (США, ЕС, APAC). Запись на локальный диск.
• Годы 6–7: рост до 10 дата-центров, автомасштабируемые кластеры Mediasoup, запись в S3 с lifecycle-политиками (автоудаление через 30 дней под комплаенс).
• Годы 8–10: 500 млн+ записанных минут, пройден аудит HIPAA, AI-транскрибация (Whisper) на 50 млн+ минут. Мульти-региональный отказоустойчивый SFU.

Ключевые метрики: 4 награды Brandon Hall (за e-learning), SLA 99,99% доступности, p99 задержки менее 120 мс, доля дропнутых звонков менее 1%. Стоимость: 0,6 ₽/мин на SFU + 0,15 ₽/мин на запись.

Пять вопросов, которые помогут принять решение

1. Сколько одновременных пользователей? До 100 → CPaaS (Agora, Daily). 100–10 000 → управляемый SFU (LiveKit Cloud). 10 000+ → собственный self-hosted.
2. Критична ли задержка? Да (геймдев, совместная работа в реальном времени) → P2P или SFU. Нет (вебинары, обучение) → CPaaS или MCU.
3. Регулируемая отрасль? Да (HIPAA, GDPR, финансы) → собственный SFU с журналами аудита. Нет → любой вариант.
4. Какой бюджет на инженерию? Меньше 7,5 млн ₽/год → CPaaS. 7,5–150 млн ₽/год → управляемый SFU. Больше 150 млн ₽/год → кастом.
5. Нужны кастомные интеграции? Да (CRM, аналитика, кастомные сценарии записи) → собственный SFU. Нет → CPaaS быстрее выведет на рынок.

12 типичных ошибок и как их избежать

1. P2P для звонка на 10 человек: P2P разваливается уже на 6. Если планируете расти за пределы 4, ставьте SFU сразу.
2. Недооценка TURN-инфраструктуры: TURN — не опция. Он нужен 30% корпоративных пользователей. Минимум 37 500 ₽/мес на регион.
3. Несовпадение кодеков: клиент предлагает H.264 + VP8, SFU поддерживает только VP8. Согласование молча проваливается. Прогоняйте все пары кодеков до продакшена.
4. Узкое место в записи: SFU пишет RTP напрямую на диск — на масштабе упирается в I/O. Используйте FFmpeg или выделенный демон записи.
5. Игнорирование мобильных сетей: мобильный: джиттер 20–50 мс, средний битрейт 500 кбит/с. Десктоп: джиттер менее 5 мс, 2 Мбит/с. Настраивайте кодеки под тип устройства.
6. Сигналинг без резерва: упал сигнальный сервер — упали все звонки. Запускайте 3+ инстанса в разных AZ с автопереключением.
7. Нет мониторинга: «задержка выросла на 50 мс» — а почему, непонятно. Снимайте: время сборки ICE, кодек и разрешение, потери пакетов, глубину джиттер-буфера.
8. Слишком высокий битрейт: 2 Мбит/с в H.264 работают на Wi-Fi 10 Мбит/с, но падают на 4G. Используйте 500–1500 кбит/с с адаптивным битрейтом, чтобы клиент сам подстраивался под сеть.
9. Нет обработки разрывов: сеть пропала на 5 секунд — клиент висит на чёрном экране. Реализуйте переподключение с экспоненциальной задержкой (1с, 2с, 4с, 8с — стоп).
10. Таймаут DTLS: DTLS-хэндшейк занимает 200–500 мс. Если UI не показывает спиннер, пользователю кажется, что приложение зависло. Ставьте таймаут на 5 секунд + повтор.
11. Слишком маленький джиттер-буфер: пакеты приходят не по порядку, буфер опустошается, звук рвётся. Берите 50–100 мс на десктопе, 100–200 мс на мобильных.
12. Нет rate-limit на сигналинге: атакующий шлёт 10 000 SDP-офферов в секунду, CPU сигнального сервера в полке, все звонки падают. Лимитируйте по IP (100 запросов в секунду) и по пользователю (10 запросов в секунду).

KPI: как измерять качество видео

Уровень 1: пользовательский опыт

• Mean Opinion Score (MOS): шкала 1–5 (5 — отлично). Цель: не ниже 4,2. Замеряется опросами или алгоритмическими приближениями (ITU-T P.863 PESQ).
• Время установления звонка: от отправки оффера до начала медиа. Цель: менее 2 секунд.
• Доля сорванных звонков. Цель: менее 0,1%.

Уровень 2: сетевые метрики

• RTT: цель — менее 150 мс (воспринимается как «живое» общение). Больше 300 мс — заметная задержка.
• Потери пакетов: цель — менее 2%. Больше 5% — заметное падение качества.
• Джиттер: цель — менее 20 мс. Больше 50 мс — рваный звук.

Уровень 3: инфраструктура

• Нагрузка SFU на поток: 50–200 мс CPU (зависит от кодека). 100 000 потоков — 5–20 физических ядер.
• Память: 100–500 МБ на 100 потоков. 100 000 потоков — 100–500 ГБ RAM.
• Полоса: 0,5–3 Мбит/с на участника в зависимости от разрешения и кодека.

Когда НЕ стоит строить свою видеоплатформу

Если что-то из этого про вас — берите CPaaS:

• У вас менее 6 месяцев до запуска и меньше 10 инженеров.
• Бюджет на эксплуатацию и инфраструктуру — менее 7,5 млн ₽/год.
• Масштаб непредсказуем — может быть 1 000 пользователей, а может миллион за полгода.
• Нет круглосуточного дежурства DevOps.
• Нужно работать в нескольких странах (GDPR, требования к хранению данных), а глобальной операционки у вас нет.

Часто задаваемые вопросы

Можно ли использовать WebRTC без сигнального сервера?

Нет. WebRTC отвечает только за медиа; для обмена SDP и ICE-кандидатами нужен внешний сигналинг. Даже P2P-звонкам требуется лёгкий сервер, который прокинет начальный SDP.

Как дешевле всего раздать видео на 1 миллион пользователей?

Это не видеозвонок — это вещание один-ко-многим. Используйте CDN + HLS/DASH. Стоимость: 0,3–0,7 ₽ за ГБ (Cloudflare, Akamai). Поток 1 Гбит/с — 3,7–7,5 ₽/с, то есть 300–600 тыс. ₽/час. Видеозвонок на миллион участников нереалистичен; большинство платформ упираются в 100 000.

Как делать звонки, если оба пользователя за NAT?

ICE сначала пробует прямое соединение (STUN), потом ретрансляцию (TURN). Если оба клиента за симметричным NAT, STUN не сработает, нужен TURN. Закладывайте 100–200 мс лишней задержки на TURN. Большинство звонков (70%) проходят через STUN; рассчитывайте на TURN как fallback для оставшихся 30%.

Что лучше — H.264 или VP8?

У H.264 есть аппаратное ускорение (быстрее, меньше CPU); VP8 — royalty-free. Для веба предлагайте оба. SFU договаривается о кодеке с каждым клиентом отдельно. Если участник A шлёт H.264, а участник B — VP8, SFU транскодирует (дорого). Выберите один и стандартизируйтесь.

Можно ли поднять видеоинфраструктуру в AWS или GCP?

Да. SFU на EC2/GCE, TURN на Compute Engine, запись в S3/GCS, сигналинг на Lambda/Cloud Functions. Суммарная стоимость выше, чем на своём железе (облачный налог), зато проще в управлении. До 100 000 пользователей облако окупается. На 500 000+ свои дата-центры обычно дешевле.

Как масштабировать запись со 100 до 10 000 одновременных звонков?

Не пишите на SFU. Используйте отдельный демон записи. SFU отправляет RTP в демон по UDP или пишет в общую очередь сообщений (Kafka). Демон складывает на локальный NVMe SSD и заливает в S3 асинхронно. Масштабирование: добавляйте инстансы записи и автомасштабируйтесь по глубине очереди.

Чем CPaaS отличается от CDN?

CPaaS (Agora, Daily) — это медиа и сигналинг в реальном времени для групповых звонков. CDN (Akamai, Cloudflare) раздаёт записанный или транслируемый контент. CPaaS — для встреч, CDN — для вещания.

Какие инструменты помогают отлаживать качество видео в продакшене?

WebRTC Statistics API (getStats) отдаёт джиттер, потери, RTT, параметры кодеков. Webrtc-internals в Chrome, RTC Inspector в Firefox и сторонние сервисы (Agora Inspect, LiveKit Insights) визуализируют эти метрики. Сливайте результаты getStats раз в 1–2 секунды в бэкенд — для исторического анализа и алертов.

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

Итоги

Видеоконференции — уже не новинка. Пользователи ждут задержки менее 150 мс, потери пакетов меньше 1% и кристально чистого звука на 4G. Конкурировать фичами (фильтры, фоны, запись) — это базовый уровень. Побеждают те, кто масштабируется на миллионы, держит ops в тонусе и предсказуемо контролирует расходы.

Выбор между CPaaS и кастомным SFU сводится к трём переменным: масштаб (одновременные пользователи), сроки (месяцы до запуска) и кастомизация (насколько уникален ваш продукт). Не уверены — стартуйте с CPaaS. Дошли до 50 000+ одновременных пользователей — пересчитывайте экономику. Собственный SFU окупается на больших объёмах; CPaaS выигрывает там, где нужна скорость вывода на рынок.

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