Видеосвязь — основной способ общения преподавателя и студента на платформе Vimbox. Мы давно отказались от Skype, перепробовали несколько сторонних решений и в итоге остановились на связке WebRTC — Janus-gateway. Некоторое время нас все устраивало, но все же некоторые негативные моменты продолжали вылезать. В итоге было создано отдельное направление по видео.
Я попросил Кирилла Рогового, руководителя нового направления, рассказать об эволюции видеосвязи в Skyeng, обнаруженных проблемах, решениях и костылях, которые мы в итоге применяли. Надеемся, статья будет полезна для компаний, также поднимающих своими силами видео через веб-приложение.
Летом 2017 года глава разработки Skyeng Сергей Сафонов выступил на Backend Conf с рассказом про то, как мы «отказались от Skype и внедрили WebRTC». Желающие могут посмотреть запись выступления по ссылке (~45 мин), а здесь я кратко изложу его суть.
Для школы Skyeng видеосвязь всегда была приоритетным способом общения учитель-ученик. Поначалу использовался «Скайп», но он категорически не устраивал по целому ряду причин, в первую очередь из-за отсутствия логов и невозможности интеграции непосредственно в веб-приложение. Поэтому мы проводили всякие эксперименты.
Собственно, требования к видеосвязи у нас были примерно такие:
— стабильность;
— низкая цена за урок;
— запись уроков;
— отслеживание, кто сколько говорит (нам важно, чтобы ученики говорили на уроках больше преподавателя);
— линейное масштабирование;
— возможность использовать и UDP, и TCP.
Первым в 2013-м попробовали внедрить Tokbox. Все было хорошо, но получалось очень дорого – 113 рублей за урок – и съедало прибыль.
Затем в 2015-м интегрировали Voximplant. Здесь была необходимая нам функция отслеживания, кто сколько говорит, и при этом решение было значительно дешевле: при условии записи только звука выходило 20 руб за урок. Однако работало оно только через UDP, переключаться на TCP не умело. Тем не менее, в итоге около 40% учеников им пользовались.
Через год у нас начали появляться корпоративные клиенты со своими специфическими требованиями. Например, все должно работать через браузер, в компании открыты только http и https; т. е. никаких «Скайпов» и UDP. Корпоративные клиенты = деньги, поэтому вернулись к Tokbox, но проблема цены никуда не делась.
Приняли решение использовать браузерную платформу для peer-to-peer видеосвязи WebRTC. Она отвечает за установку соединения, кодирование и декодирование потоков, синхронизацию дорожек и контроль качества с обработкой сетевых глюков. Со своей стороны мы должны обеспечить считывание потоков с камеры и микрофона, отрисовку видео, управление соединением, установку WebRTC-подключения и передачу ему потоков, а также передачу сигнальных сообщений между клиентами для установки соединения (сам WebRTC описывает только формат данных, но не механизм их передачи). В случае, если клиенты находятся за NAT, WebRTC подключает STUN-серверы, если это не помогает, TURN-серверы.
Обычного p2p соединения нам недостаточно, ведь мы хотим записывать уроки для дальнейшего анализа в случае жалоб. Поэтому мы отправляем потоки WebRTC через ретранслятор Janus Gateway от Meetecho. В результате клиенты не знают адресов друг друга, видя только адрес сервера Janus; он же выполняет и функции сигнального сервера. Janus обладает множеством нужных нам фич: автоматически переходит в TCP, если у клиента заблокирован UDP; умеет записывать потоки и UDP, и TCP; масштабируется; есть даже встроенный плагин для эхо-тестов. В случае необходимости автоматически подключаются STUN и TURN серверы от Twilio.
Летом 2017-го года у нас работало два сервера Janus плюс дополнительный сервер для обработки записанных сырых файлов аудио и видео, чтобы не занимать процессоры основных. При подключении серверы Janus выбирались по принципу чет-нечет (номер соединения). На тот момент этого хватало, по нашим ощущениям давало примерно четырехкратный запас прочности, процент внедрения составил около 80. При этом цена сократилась до ~2 рублей за урок, плюс разработка и поддержка.
Мы постоянно мониторим фидбек от учеников и преподавателей, чтобы вовремя выявлять и купировать проблемы. К лету 2018-го на первом месте среди жалоб уверенно закрепилось качество связи. С одной стороны, это значило, что мы успешно справились с иными недостатками. С другой, нужно было срочно что-то делать: при срыве урока мы рискуем потерять его стоимость, иногда вместе со стоимостью покупки следующего пакета, а при срыве вводного занятия – и вовсе потерять потенциального клиента.
На тот момент видеосвязь у нас по-прежнему находилась в режиме MVP. Проще говоря, запустили, оно заработало, один раз масштабировали, поняли, как это делать – ну и славно. If it works, don’t fix it. Никто целенаправленно вопросом качества связи не занимался. К августу стало ясно, что дальше так продолжаться не может, и мы запустили отдельное направление, чтобы разобраться, что же все-таки у нас не так с WebRTC и Janus.
На входе это направление получило: решение MVP, метрик нет, целей нет, процессов по улучшению нет, при этом 7% учителей жалуются на качество связи (данных по ученикам тоже не было).
Команда выглядит примерно так:
Для начала настроили относительно надежную метрику, которая отслеживала изменения оценки качества связи (среднее по дням, неделям, месяцам). На тот момент это были оценки от учителей, в дальнейшем к ним добавили оценки от студентов. Дальше стали строить гипотезы, что работает не так, исправлять и смотреть на изменения в динамике. Пошли по низковисящим фруктам: например, заменили кодек vp8 на vp9, показатели улучшились. Пробовали играться с настройками Janus, проводить прочие эксперименты – в большинстве случаев ни к чему не приводившие.
На втором этапе появилась гипотеза: WebRTC – решение peer-to-peer, а мы используем сервер посередине. Быть может, проблема кроется здесь? Начали копать и нашли здесь пока наиболее значительное улучшение.
В тот момент сервер из пула выбирался по довольно тупому алгоритму: у каждого был свой «вес», зависящий от канала и мощности, и мы старались отправить пользователя на тот, где «вес» больше, не обращая внимание на то, где географически находится пользователь. В результате учитель из Питера мог общаться с учеником из Сибири через Москву, а не через наш Janus-сервер в СПб.
Алгоритм переделали: теперь, когда пользователь открывает нашу платформу, мы с помощью Ajax собираем пинги от него до всех серверов. При установке связи мы выбираем пару пингов (учитель-сервер и ученик-сервер) с наименьшей суммой. Меньше пинг – меньше сетевое расстояние до сервера; меньше расстояние — ниже вероятность потерять пакеты; потеря пакетов — самый большой отрицательный фактор в видеосвязи. Доля негатива за три месяца упала в два раза (справедливости ради, в это время проводились и другие эксперименты, но этот почти наверняка повлиял больше всего).
Недавно мы обнаружили еще одну неочевидную, но, судя по всему, важную вещь: вместо одного мощного Janus-сервера на толстом канале лучше два попроще с пропускной способностью пожиже. Выяснилось это после того, как мы купили именно мощные машины в надежде запихнуть туда как можно больше комнат (сеансов связи) одновременно. У серверов есть лимит пропускной способности, который мы можем точно переводить в количество комнат — мы знаем, сколько можно открыть, например, на 300 мбит/с. Как только на сервере открыто слишком много комнат — мы перестаем выбирать его для новых занятий, пока нагрузка не снизится. Идея была в том, что, купив мощную машину, мы загрузим канал до него по максимуму, чтобы в итоге упираться в процессор и память, а не в пропускную способность. Но выяснилось, что после определенного количества открытых комнат (420), несмотря на то что загрузка процессора, памяти и диска еще очень далека от лимитов, в техподдержку начинает прилетать негатив. Судя по всему, что-то становится хуже внутри Janus, возможно, там тоже есть какие-то ограничения. Стали экспериментировать, снизили лимит пропускной способности с 300 до 200 мбит/с, проблемы ушли. Теперь купили сразу три новых сервера с невысокими лимитами и характеристиками, думаем, что это приведет к стабильному улучшению качества связи. Разбираться, в чем там было дело, мы, конечно, не стали, костыли — наше все. В свое оправдание скажем, что в тот момент надо было максимально быстро решить насущную проблему, а не сделать это красиво; к тому же Janus для нас — черный ящик, написанный на C, копаться с ним очень дорого.
Ну и в процессе мы:
Проведенные эксперименты и последовавшие за ними изменения позволили снизить недовольство связью среди преподавателей с 7,1% в январе 2018 до 2,5% в январе 2019.
Стабилизация нашей платформы Vimbox — один из главных проектов компании на 2019 год. У нас большие надежды на то, что удастся сохранить динамику и больше не видеть видеосвязь в топе жалоб. Мы понимаем, что значительная часть этих жалоб связана с лагами компьютеров и интернета пользователей, но мы должны определить эту часть и решить все остальное. Все остальное — техническая проблема, кажется, мы должны уметь с ней справляться.
Основная сложность в том, что мы не знаем, до какого уровня вообще реально повысить качество. Выяснение этого потолка – главная задача. Поэтому были запланированы два эксперимента:
Эти два эксперимента позволят нам определить достижимую цель и сконцентрироваться на ней.
Кроме того, есть ряд задач, решаемых в рабочем порядке:
С апреля направление видеосвязи становится полноценным отдельным проектом внутри Skyeng, занимающимся собственным продуктом, не просто частью Vimbox. А это значит, что мы начинаем искать людей на работу с видео в режиме фултайм. Ну и как всегда ищем много хороших людей.
Ну и, конечно, продолжаем активно общаться с людьми и компаниями, работающими с видеосвязью. Если вы хотите обменяться с нами опытом — мы будем рады! Комментируйте, связывайтесь — ответим всем.
К сожалению, не доступен сервер mySQL