Почти любой бизнес любит конференц-связь, а особенно видеоконференции. Voximplant помогает бизнесам в том числе и с этим: у нас успешно работают видеоконференции, как обычные так и HD (например, см.статью Video Conferencing). Сейчас наши конфы работают на peer-to-peer архитектуре, однако скоро мы расскажем о клиент-серверном решении с преферансом и куртизанками. А пока предлагаем посмотреть на подходы к созданию серверных конференций с помощью WebRTC: мы подготовили перевод свежей статьи из блога BlogGeek.me. Автор блога – Цахи Левент-Леви, независимый эксперт WebRTC, аналитик и предприниматель; в прошлом Цахи работал над проектами VoIP и 3G как разработчик, маркетолог и технический директор. Одним словом, он знает о чем говорит.
Сколько участников может быть в WebRTC-звонке?
Сколько захотите. Вы можете впихнуть от одного до миллиона участников в любой WebRTC-звонок.
Представим, что вас попросили сделать групповой видеозвонок и очевидно, что выбор технологии пал на WebRTC. Для этой задачи почти нет альтернатив, кроме технологии WebRTC, которая к тому же имеет лучшее соотношение цены и производительности. Однако возникает вопрос: сколько же пользователей может “уместиться” в одном звонке WebRTC?
По крайней мере раз в неделю кто-нибудь говорит, что WebRTC это peer-to-peer технология и вряд ли она подходит для большого количества участников… Что ж, WebRTC отлично подходит для больших групповых звонков.
Сегодня наибольшим структурным блоком WebRTC является SFU (Selective Forwarding Unit – прим. переводчика) – медиароутер, который получает медиапотоки от всех участников в сессии и решает, куда эти потоки направлять.
В этой статье я хочу рассказать про некоторые подходы и решения, которыми вы можете воспользоваться при создании приложений на WebRTC, которые должны поддерживать большие видеосессии.
Проанализируйте сложность
Первый шаг – проанализировать сложность нашего конкретного случая.
В WebRTC (да и в целом, в видеокоммуникациях реального времени) всё сводится к скорости и потокам:
- Скорость – разрешение и битрейт, которые мы ожидаем добиться в нашем сервисе.
- Потоки – количество потоков в сессии
Начнем с примера.
Предположим, что вы хотите запустить сервис групповых звонков для энтерпрайза. Или даже запуститься по всему миру. Люди будут группироваться в рамках сессий. Вы планируете ограничить групповые сессии до 4 человек. Знаю, что вам хочется больше, но пока я стараюсь не усложнять.
Рисунок выше показывает, как должна выглядеть конференция для 4 человек.
Магические квадраты: 720p
Если разметка конференции выглядит как магический квадрат (4 изображения одинакового размера – прим. переводчика), то будет применима следующая логика.
Вы хотите видео высокого качества. Ну, его все хотят. Итак, вы рассчитываете, что все участники посылают видео 720p и используют WQHD мониторы (2560х1440). Допустим, это потребует битрейт 1,5 Мб/с (я здесь скромен; очевидно, что значение может быть выше), таким образом:
- каждый участник сессии отдает 1,5 Мб/с и получает 3 потока по 1,5 Мб/с;
- при 4 участниках медиасервер должен получать 6 Мб/с и отдавать 18 Мб/с.
В виде таблицы это выглядит так:
| Разрешение | 720p |
| Битрейт | 1,5 Мб/с |
| Участник отдает | 1,5 Мб/с (1 поток) |
| Участник принимает | 4,5 Мб/с (3 потока) |
| SFU отдает | 18 Мб/с (12 потоков) |
| SFU принимает | 6 Мб/с (4 потока) |
Магические квадраты: VGA
Если вам нужно разрешение поменьше, вы можете использовать разрешение VGA (640x480 – прим. переводчика) и даже ограничить битрейт до 600 Кб/с:
| Разрешение | VGA |
| Битрейт | 600 Кб/с |
| Участник отдает | 0,6 Мб/с (1 поток) |
| Участник принимает | 1,8 Мб/с (3 потока) |
| SFU отдает | 7,2 Мб/с (12 потоков) |
| SFU принимает | 2.4 Мб/с (4 потока) |
Вероятно, вы захотите избежать масштабирования VGA под дисплеи – может получиться ужасно, особенно на 4K-дисплеях.
Примерные подсчеты показывают, что теоретически вы можете уместить 3 VGA-конференции “по цене” одной 720p-конференции.
В духе Hangouts
Но что если конференция должна выглядеть иначе? Один главный участник и маленькие видео других участников:
Я называю это “в духе Hangouts”, потому как приложение Hangouts хорошо известно такой разметкой и было первым, кто использовал такое представление, не предлагая другие варианты.
В этом случае мы используем simulcast, подразумевая, что все участники отсылают HQ видео и SFU решает, какой поток использовать в качестве главного и устанавливает для него разрешение выше, для остальных потоков – ниже.
Вы решаете использовать 720p, потому что после пары экспериментов вы понимаете, что меньшие разрешения при масштабировании на большие дисплеи выглядят не слишком хорошо. В итоге вы имеете:
- каждый участник сессии отдает 2,2 Мб/с (1,5 Мб/с для потока 720p и дополнительные 800 Кб/с для других разрешений, одновременно с которыми будет трансляция);
- каждый участник сессии получает 1,5 Мб/с от главного участника и 2 дополнительных потока по ~300 Кб/с для маленьких видео;
- при 4 участниках медиасервер должен получать 8,8 Мб/с и отдавать 8,4 Мб/с.
| Разрешение | 720p максимальное (Simulcast) |
| Битрейт | 150 Кб/с – 1,5 Мб/с |
| Участник отдает | 2,2 Мб/с (1 поток) |
| Участник принимает | 1,5 Мб/с (1 поток) 0,3 Мб/с (2 потока) |
| SFU отдает | 8,4 Мб/с (12 потоков) |
| SFU принимает | 8,8 Мб/с (4 потока) |
Что мы узнали:
Различные конфигурации групповых звонков при одинаковом количестве участников оказывают разную нагрузку на медиасервер.
Это не было указано явно, однако Simulcast (то, что мы использовали в Hangouts-примере) работает великолепно и улучшает эффективность и качество групповых звонков.
На примере 3 сценариев видеозвонков с 4-мя потоками (у каждого участника – прим. переводчика) мы получили такую активность SFU:
| Магические квадраты: 720p | Магические квадраты: VGA | В духе Hangouts | |
| SFU отдает | 18 Мб/с | 7,2 Мб/с | 8,4 Мб/с |
| SFU принимает | 6 Мб/с | 2,4 Мб/с | 8,8 Мб/с |
Задание на дом: представьте, что мы хотим сделать сессию с 2 потоками (у каждого участника – прим. переводчика), которая доступна 100 людям через WebRTC. Посчитайте количество потоков и полосы пропускания, которые вам нужны для сервера.
Сколько может быть активных пользователей в WebRTC-звонке?
Трудный вопрос.
Если вы используете MCU (Multipoint Conferencing Unit – прим. переводчика), вы получите столько участников в звонке, сколько способен обработать ваш MCU.
Если же вы используете SFU, это зависит от 3 параметров:
- Сложность и производительность вашего медиасервера
- Доступные вам мощности клиентских устройств
- Как спроектирована ваша инфраструктура и то, как вы осуществили каскадирование (связь между несколькими медиасерверами – прим. переводчика)
Сейчас мы рассмотрим эти параметры.
Один сценарий, разные реализации
Все что касается 8-10 участников в одном звонке, становится сложным. Вот вам пример публично доступного сервиса, которым я хочу поделиться.
Сценарий:
- 9 участников в одной сессии, разметка – “магический квадрат”;
- я использую testRTC, чтобы создать сессию с пользователями, т.е. всё автоматизировано;
- запускаю на 1 минуту. Затем сессия принудительно завершается, т.к. это демо;
- демо учитывает, что на экране 9 человек, поэтому разрешение для всех снижается до VGA, однако в итоге используется 1,3 Мб/с;
- браузеры получают на обработку поток в 10 Мб/с.
В этом случае медиасервер решал как лимитировать и измерять трафик.
А вот другой сервис с онлайн-демо, которое отработало по такому же сценарию:
Теперь средний входящий битрейт у каждого браузера всего лишь 2,7 Мб/с – почти четверть от битрейта в первом сервисе.
Один сценарий. Разные реализации.
Что насчет популярных сервисов?
Что насчет популярных сервисов для видеоконференций с использованием SFU? Какие у них ограничения по количеству участников?
Вот что мне удалось найти:
- Google Hangouts – до 25 участников в сессии. Раньше было 10. Когда я делал первый семинар для моего тренинга по WebRTC, я уперся в это ограничение, что заставило меня использовать другие сервисы;
- Hangouts Meet – максимум 50 человек;
- Houseparty – ограничились 8 участниками;
- Skype – 25 участников;
- appear.in – их PRO аккаунт поддерживает до 12 человек в комнате;
- Amazon Chime – 16 участников в десктопной версии и до 8 участников в iOS-версии (Андроид пока не поддерживается);
- Atlassian Stride и Jitsi Meet – до 50 участников.
Означает ли это, что вы не можете превысить порог в 50 участников?
На мой взгляд, существует зависимость между размером конференции и ее сложностью:
Лимит на размер в CPaaS
CPaaS-платформы, которые поддерживают видео и групповые звонки, часто имеют лимиты на размер конференций. В большинстве случаев там указывается произвольное количество участников, которое было протестировано. Как мы поняли, эти ограничения подходят лишь для определенных сценариев и не факт, что сюда входят ваши сценарии использования.
Для CPaaS-платформ эти лимиты колеблются от 10 до 100 участников для одной сессии. И обычно, если вы превышаете лимит, то дополнительные участники будут только в режиме просмотра.
Ключевые моменты
Вот что следует помнить:
- чем больше конференция, тем сложнее ее реализовать и оптимизировать;
- браузер вынужден запускать множество декодеров, что очень ресурсоемко;
- мобильные устройства (особенно старые) могут не выдержать такую нагрузку. Делайте тесты на максимально старых и слабых устройствах, для которых вы планируете поддержку – и только потом определяйте максимальный поддерживаемый размер конференции;
- вы можете настроить SFU так, чтобы он не отправлял все входящие потоки всем участникам, но выбирал данные для отправки. Например, отправлять аудиопоток только одного участника всем остальным или отправлять только 4 самых громких аудиопотока.
Измерьте ваш медиасервер
Измерения и медиасерверы – это то, что я делал в последнее время с testRTC. Ранее мы немного поигрались с Kurento, а также планируем повозиться с другими медиасерверами. Мне задают один и тот же вопрос в каждом проекте, где я участвую:
Как много сессий / участников / потоков мы можем использовать в одном медиасервере?
Вспоминая вышеуказанные скорость и потоки, то ответ на вопрос очень и очень зависит от того, что именно вы делаете.
Если вы нацелены на групповые звонки, где активен каждый участник, то вы должны рассчитывать на 100-500 участников на одном медиасервере. Точное количество зависит от того, на какой машине работает медиасервер и какой битрейт вам нужен.
Если вы нацелены на вещание одного человека для большой аудитории (броадкаст), сделанного с помощью WebRTC для снижения задержек, то количество участников будет в районе 200-1000 человек. А может и больше.
Большие или маленькие машины?
Еще один важный момент – это машина, на которой будет хостится медиасервер. Будет ли это уберкрутой сервер или вам будет удобно с чем-нибудь поменьше?
Использование больших, серьезных машин позволит вам обслуживать бОльшее количество людей и сессий на одном сервере, так что сложность вашего решения будет ниже. Если что-то выйдет из строя (медиасерверы так делают, да), это коснется большого числа пользователей. И когда вам понадобится обновить медиасервер (а вы точно будете это делать), этот процесс может дорого вам обойтись либо окажется очень трудным.
Чем больше сервер, тем больше у него ядер. Из-за этого медиасервер будет вынужден работать многопоточно, что, в свою очередь, повышает сложность создания медиасервера, его отладки и устранения проблем.
Использование меньших серверов означает, что вы раньше встретите проблемы масштабирования, а для их решения потребуются более продуманные алгоритмы и эвристика. У вас будет больше пограничных случаев во время балансировки загрузки.
Измерять в потоках, полосе пропускания или CPU?
Как вы определяете, что ваш медиасервер работает на полной мощности? Как вы решаете, поместить новую сессию на свободную машину, на новую незанятую или в уже используемую? Если вы выберете уже используемую машину и новые участники начнут добавляться в активную сессию, то хватит ли для всех места?
Это непростые вопросы.
Я видел 3 разные метрики, по которым можно определить, что пора использовать другие серверы. Вот они:
CPU – когда утилизация CPU достигает определенного процента, это означает, что машина “заполнена”. Лучше всего работает при использовании малых серверов, так как в их случае CPU это один из первых “иссякаемых” ресурсов.
Полоса пропускания – SFU проявляет большую сетевую активность. Если вы используете большие машины, то скорее всего вы не достигнете лимита CPU, однако потребуете слишком большой полосы пропускания. Поэтому вы сможете определять остаточную мощность, отслеживая полосу пропускания.
Потоки – трудность, связанная с CPU и полосой пропускания, в том, что количество поддерживаемых сессий и потоков может меняться в зависимости от условий. Ваша стратегия масштабирования может не справиться с этим и вы захотите больше контроля над вычислениями. Это приведет вас к тому, чтобы не измерять загрузку через CPU или полосу пропускания, а создать правила балансировки, основанные на количестве потоков, которые может выдержать сервер.
—
Основной челлендж в том, что какой бы способ вы ни выбрали, измерения вам придется делать самому. Я видел как многие начинали использовать testRTC, когда сталкивались с этой задачей.
Каскадирование одной сессии
Каскадирование – это процесс соединения одного медиасервера с другим. Картинка ниже показывает, что я имею в виду:
У нас есть 4-поточный групповой видеозвонок, который распределен между 3 медиасерверами. Эти серверы маршрутизируют видео и голос между собой так, чтобы медиапотоки были соединены. Почему вам это может понадобиться?
#1 – Географическое распределение
Когда вы запускаете глобальный сервис и используете в нем SFU, то первый же вопрос для каждой новой сессии – какой SFU вы используете? В каком из датацентров? Так как мы хотим, чтобы наши медиасерверы располагались наиболее близко к пользователям, мы либо заранее знаем что-то о новой сессии и понимаем, куда ее определить, либо решаем это разумными средства вроде геолокации – выбираем датацентр, который ближе к пользователю, создавшему конференцию.
Предположим, что в звонке участвуют четверо. Трое из Нью-Йорка, а один из Франции. Что случится, если парень из Франции будет первым в групповом звонке?
Медиасервер расположится во Франции. 3 из 4 участников будут далеко от медиасервера. Не самый лучший подход…
Одно из решений для такой конференции – это распределить ее между серверами, которые близко к каждому из участников:
Серверам потребуется больше ресурсов для обслуживания сессии, однако у нас будет больше контроля над медиамаршрутами, так что мы сможем лучше их оптимизировать. Это улучшит качество медиа в сессии.
#2 – Гибкое резервирование
Предположим, что к одному медиасерверу может подключиться до 100 участников. Кроме того, в каждом групповом звонке может быть до 10 участников. В идеале, мы не хотим размещать больше 10 сессий на одном медиасервере.
Но что если я скажу вам, что в среднем в одном звонке по 2 участника? То есть примерно такое распределение:
Большая часть ресурсов сервера тратится впустую. Как мы можем это исправить?
- Заранее обязывать людей заполнять звонки по максимуму. Это не то, что вы бы хотели делать.
- Рискнем и предположим, что если сервер будет использован на 50%, то оставшаяся мощность позволит текущим конференциям увеличиваться. Вы по-прежнему расходуете ресурсы впустую, но уже меньше. В данном случае возникнут пограничные случаи, когда больше не сможете увеличивать конференции за счет ресурсов сервера.
- Перемещать сессии между медиасерверами в попытке “фрагментировать” серверы. Это ужасно настолько же, насколько оно и звучит (и возможно настолько же плохо для пользователей).
- Каскадировать сессии, то есть позволить им расти на разных машинах.
Как насчет каскадирования? Зарезервируйте ресурсы одного медиасервера под размещение сессий с других медиасерверов.
#3 – Огромные конференции
Если вы задумали создать конференцию больше, чем способен обработать один медиасервер, то каскадирование – ваш единственный выбор.
Если ваш медиасервер рассчитан на 100 участников и вы хотите конференции размером до 5000 участников, то вам нужно каскадирование. Это нелегко, поэтому подобных решений немного, но это определенно возможно.
Имейт в виду, в столь больших конференциях медиапоток не будет двунаправленным. У вас будет меньше участников, отправляющих медиа и больше участников, которые только получают медиа. Для случая чистого броадкаста я уже описывал проблемы масштабирования в блоге Red5 Pro.
Вывод
Мы затронули множество тем в этой статье. Вот список того, что вам необходимо сделать, чтобы определить максимальное количество пользователей в ваших WebRTC-звонках:
- Какой бы размер конференций вы ни задумали, это реализуемо через WebRTC.
- Это будет вопросом затрат и соотношения с бизнес-моделью (которая либо выгорит, либо нет).
- Чем больше конференция, тем сложнее сделать ее правильно и тем больше “переменных в уравнении”.
- Оцените сложность поддержки.
- Посчитайте входящие и исходящие потоки для каждого устройства и медиасервера.
- Определитесь с качеством видео (разрешение и битрейт) для каждого потока.
- Определитесь, какой медиасервер вы будете использовать.
- Выберите, на какой машине будет запускаться медиасервер.
- Измерьте загрузку, достаточную для масштабирования.
- Проверьте, что увеличение загрузки линейно по отношению к ресурсам сервера.
- Решите, какую метрику загрузки вы используете: CPU, полоса пропускания, потоки или что-то еще.
- Как каскадирование впишется в общую картину?
- Улучшенная поддержка геолокации.
- Помощь при фрагментации ресурсов в облачной инфраструктуре.
- Или увеличение конференций за пределы возможностей одного медиасервера.
Итак, каков размер ваших WebRTC-конференций?
Комментариев нет:
Отправить комментарий