Видеосвязь — основной способ общения преподавателя и ученика на платформе Vimbox. Мы давно отказались от Skype, попробовали несколько сторонних решений и в итоге остановились на связке WebRTC — Janus-шлюз.
Какое-то время нас все устраивало, но все же некоторые негативные моменты продолжали проявляться.
В результате было создано отдельное видеонаправление.
Я попросил Кирилла Рогового, руководителя нового направления, рассказать об эволюции видеосвязи в Skyeng, обнаруженных проблемах, решениях и костылях, которые мы в итоге использовали.
Надеемся, статья будет полезна компаниям, которые также самостоятельно создают видео через веб-приложение.
Немного истории
Летом 2017 года руководитель разработки Skyeng Сергей Сафонов выступил на Backend Conf с рассказом о том, как мы «отказались от Skype и внедрили WebRTC».Желающие могут посмотреть запись выступления на сайте связь (~45 мин), и здесь я кратко изложу ее суть.
Для школы Skyeng видеосвязь всегда была приоритетным способом общения учителя и ученика.
Сначала использовался Skype, но он категорически не устраивал по ряду причин, в первую очередь из-за отсутствия логов и невозможности интеграции непосредственно в веб-приложение.
Поэтому мы проводили всевозможные эксперименты.
Собственно, наши требования к видеосвязи были примерно такими: — стабильность; — низкая цена за занятие; — запись уроков; — отслеживание, кто сколько говорит (нам важно, чтобы на уроках ученики говорили больше, чем преподаватель); — линейное масштабирование; - возможность использовать как UDP, так и TCP. Первым попробовал внедрить Токбокс в 2013 году.
Все было хорошо, но это оказалось очень дорого — 113 рублей за урок — и съело прибыль.
Затем, в 2015 году, была интегрирована Voximplant. Здесь нам нужна была функция, чтобы отслеживать, кто сколько говорил, и при этом решение было значительно дешевле: если записывалась только аудиозапись, то это стоило 20 рублей за урок.
Однако он работал только через UDP и не мог переключиться на TCP. Однако около 40% студентов в конечном итоге воспользовались им.
Год спустя у нас появились корпоративные клиенты со своими специфическими требованиями.
Например, всё должно работать через браузер; компания открывает только http и https; то есть нет Skype или UDP. Корпоративные клиенты = деньги, поэтому вернулись в Токбокс, но проблема цены не ушла.
Решение — WebRTC и Янус
Решил использовать браузерная платформа для одноранговой видеосвязи WebRTC .Он отвечает за установление соединения, кодирование и декодирование потоков, синхронизацию треков и контроль качества с устранением сетевых сбоев.
Мы со своей стороны должны обеспечить чтение потоков с камеры и микрофона, отрисовку видео, управление соединением, установление WebRTC-соединения и передачу на него потоков, а также передачу сигнальных сообщений между клиентами для установления соединения (сам WebRTC описывает только формат данных, а не механизм его передачи).
Если клиенты находятся за NAT, WebRTC подключает STUN-серверы; если это не поможет, ВЕРНИТЕ сервера.
Обычного p2p-соединения нам недостаточно, поскольку мы хотим записывать уроки для дальнейшего анализа в случае претензий.
Поэтому мы отправляем потоки WebRTC через ретранслятор.
В результате клиенты не знают адреса друг друга, видя только адрес сервера Янус; он также выполняет функции сервера сигналов.
Janus имеет множество необходимых нам функций: автоматически переключается на TCP, если у клиента заблокирован UDP; может записывать потоки UDP и TCP; масштабируемый; Есть даже встроенный плагин для эхо-тестов.
При необходимости автоматически подключаются STUN и TURN-серверы от Twilio. Летом 2017 года у нас работало два сервера Janus плюс дополнительный сервер для обработки записанных сырых аудио и видео файлов, чтобы не занимать процессоры основных.
При подключении серверы Янус выбирались по четному-нечетному принципу (номер подключения).
На тот момент этого было достаточно, по нашим ощущениям, это давало примерно четырехкратный запас прочности, процент внедрения был около 80. При этом цена была снижена до ~2 рублей за урок плюс разработка и поддержка.
Возвращаясь к теме видеосвязи
Мы постоянно отслеживаем обратную связь от студентов и преподавателей, чтобы своевременно выявлять и исправлять проблемы.К лету 2018 года качество связи прочно заняло первое место среди жалоб.
С одной стороны, это означало, что мы успешно преодолели и другие недостатки.
С другой стороны, нужно было срочно что-то делать: если урок будет сорван, мы рискуем потерять его ценность, иногда вместе со стоимостью приобретения следующего пакета, а если вводное занятие будет сорвано, мы рискуем потерять потенциального клиента.
вообще.
На тот момент наша видеосвязь еще находилась в режиме MVP. Проще говоря, запустили, заработало, один раз масштабировали, поняли, как это делать — ну и отлично.
Если это работает, не исправляйте это.
Никто сознательно не занимался вопросом качества связи.
К августу стало ясно, что так продолжаться не может, и мы запустили отдельное направление, чтобы разобраться, что не так с WebRTC и Янусом.
На вход это направление получило: MVP-решение, никаких метрик, никаких целей, никаких процессов для улучшения, при этом 7% преподавателей жалуются на качество коммуникации (данных по ученикам тоже не было).
Развивается новое направление
Команда выглядит примерно так:- Руководитель отдела, он же главный разработчик.
- QA помогает тестировать изменения, ищет новые способы создания нестабильных условий связи и сообщает о проблемах с линии фронта.
- Аналитик постоянно ищет различные корреляции в технических данных, совершенствует анализ отзывов пользователей и проверяет результаты экспериментов.
- Менеджер по продукту помогает с общим направлением и распределением ресурсов для экспериментов.
- Второй разработчик часто помогает с программированием и связанными с ним задачами.
В то время это были оценки учителей; позже к ним добавились оценки учеников.
Потом начали строить гипотезы о том, что работает неправильно, исправлять и смотреть на изменения в динамике.
Мы пошли за простым фруктом: например, заменили кодек vp8 на vp9, производительность улучшилась.
Мы пробовали играться с настройками Януса и проводить другие эксперименты — в большинстве случаев они ни к чему не привели.
На втором этапе возникла гипотеза: WebRTC — это одноранговое решение, и мы используем сервер посередине.
Возможно, проблема кроется здесь? Мы начали копать и обнаружили самое значительное улучшение на данный момент. В этот момент сервер из пула выбирался по довольно дурацкому алгоритму: каждый имел свой «вес» в зависимости от канала и мощности, и мы пытались отправить пользователя на тот, у которого «вес» будет наибольшим, без обращая внимание на то, где географически находится пользователь.
В результате преподаватель из Питера мог общаться со студентом из Сибири через Москву, а не через наш сервер Янус в Питере.
Алгоритм был переделан: теперь, когда пользователь открывает нашу платформу, мы собираем от него пинги ко всем серверам, использующим Ajax. При установлении соединения выбираем пару пингов (учитель-сервер и ученик-сервер) с наименьшей суммой.
Меньший пинг означает меньшее сетевое расстояние до сервера; меньшее расстояние означает меньшую вероятность потери пакетов; Потеря пакетов является самым большим негативным фактором в видеосвязи.
Доля негатива за три месяца упала вдвое (справедливости ради, в это время проводились и другие эксперименты, но этот почти наверняка оказал наибольшее влияние).
Недавно мы обнаружили еще одну неочевидную, но, видимо, важную вещь: вместо одного мощного сервера Janus на толстом канале лучше иметь два более простых с меньшей пропускной способностью.
Это стало понятно после того, как мы купили мощные машины в надежде втиснуть в них как можно больше комнат (сеансов связи) одновременно.
У серверов есть лимит пропускной способности, который мы можем точно перевести в количество комнат — мы знаем, сколько их можно открыть, например, на скорости 300 Мбит/с.
Как только на сервере открывается слишком много комнат, мы перестаем выбирать его для новых активностей до тех пор, пока нагрузка не снизится.
Идея была в том, что, купив мощную машину, мы бы нагрузили к ней канал по максимуму, чтобы в итоге он был ограничен процессором и памятью, а не пропускной способностью.
Но оказалось, что после определенного количества открытых номеров (420), несмотря на то, что нагрузка на процессор, память и диск еще очень далека от пределов, в техподдержку начинает поступать негатив.
Судя по всему, внутри Януса что-то становится хуже, возможно, там тоже есть какие-то ограничения.
Мы начали экспериментировать, снизили лимит пропускной способности с 300 до 200 Мбит/с, и проблемы ушли.
Сейчас мы купили сразу три новых сервера с низкими лимитами и характеристиками, думаем, что это приведет к стабильному улучшению качества связи.
Мы, конечно, не пытались разобраться, что там происходит; наши костыли — это все.
В свое оправдание скажем, что в тот момент нужно было как можно быстрее решить насущную проблему, а не сделать это красиво; к тому же Янус для нас — это черный ящик, написанный на C, возиться с ним очень дорого.
Итак, в процессе мы:
- обновили все зависимости, которые можно было обновить, как на сервере, так и на клиенте (это тоже были эксперименты, мы следили за результатами);
- исправлены все выявленные ошибки, относящиеся к конкретным случаям, например, когда соединение разрывалось и не восстанавливалось автоматически;
- Мы провели множество встреч с компаниями, работающими в сфере видеокоммуникаций и знакомыми с нашими проблемами: стриминг игр, организация вебинаров; мы попробовали все, что нам показалось полезным;
- Проведена техническая проверка качества оборудования и связи преподавателей, от которых поступило больше всего жалоб.
Что дальше
Стабилизация нашей платформы Vimbox — один из главных проектов компании на 2019 год. Мы возлагаем большие надежды, что нам удастся сохранить динамику и больше не видеть видеосвязь в топе жалоб.Мы понимаем, что значительная часть этих жалоб связана с лагами компьютеров и Интернета пользователей, но мы должны определить эту часть и решить остальные.
Все остальное — техническая проблема, кажется, мы с ней сможем справиться.
Основная сложность в том, что мы не знаем, до какого уровня реально можно улучшить качество.
Выяснить этот потолок – основная задача.
Поэтому было запланировано два эксперимента:
- сравните видео через Янус с обычным p2p в боевых условиях.
Этот эксперимент уже проводился, статистически значимой разницы между нашим решением и p2p обнаружено не было;
- Давайте поставим (дорогие) услуги от компаний, которые зарабатывают исключительно на решениях видеосвязи, и сравним количество негатива от них с имеющимся.
Кроме того, есть ряд задач, которые можно решить в плановом порядке:
- Создаем техническую метрику качества общения вместо субъективных отзывов;
- Делаем более подробные журналы сессий, чтобы точнее проанализировать возникающие сбои, понять, когда и где именно они произошли, и какие, казалось бы, несвязанные между собой события произошли в этот момент;
- Перед занятием мы готовим автоматический тест качества соединения, а также даем клиенту возможность вручную протестировать соединение, чтобы уменьшить количество негатива, вызываемого его оборудованием и каналом;
- разработаем и проведем дополнительные нагрузочные тесты видеосвязи в плохих условиях, с переменной потерей пакетов и т. д.;
- меняем поведение серверов при возникновении проблем для повышения отказоустойчивости;
- Мы предупредим пользователя, если с его подключением вообще что-то не так, как это делает Skype, чтобы он понял, что проблема на его стороне.
Ну как всегда Мы ищем много хороших людей .
И, конечно, мы продолжаем активно общаться с людьми и компаниями, работающими в сфере видеосвязи.
Если вы хотите обменяться с нами опытом, мы будем рады! Комментируйте, обращайтесь - всем ответим.
Теги: #Работа с видео #Оптимизация сервера #облачные сервисы #Управление продуктом #Тестирование веб-сервисов #webrtc #веб-приложения #Janus Gateway #p2p видео
-
Компьютеры На Рынке
19 Oct, 24 -
Как Я Сломал Telegram
19 Oct, 24 -
Выпуск Livestreet 0.5.1 И Переход На Github
19 Oct, 24 -
Как Большие Компании Приходят В Упадок
19 Oct, 24 -
3D-Здания Из Openstreetmap
19 Oct, 24 -
Если Flash Выйдет Из Строя.
19 Oct, 24
