Відеозв'язок – основний спосіб спілкування викладача та студента на платформі 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, але проблема ціни нікуди не поділася.
Рішення - WebRTC і Janus
Вирішили використовувати . Вона відповідає за встановлення з'єднання, кодування та декодування потоків, синхронізацію доріжок та контроль якості з обробкою мережевих глюків. Зі свого боку ми повинні забезпечити зчитування потоків з камери та мікрофона, відтворення відео, керування з'єднанням, встановлення WebRTC-підключення та передачу йому потоків, а також передачу сигнальних повідомлень між клієнтами для встановлення з'єднання (сам WebRTC описує лише формат даних, але не механізм їх передачі). Якщо клієнти знаходяться за NAT, WebRTC підключає STUN-сервери, якщо це не допомагає, TURN-сервери.
Звичайного p2p з'єднання нам недостатньо, адже хочемо записувати уроки для подальшого аналізу у разі скарг. Тому ми надсилаємо потоки WebRTC через ретранслятор. . В результаті клієнти не знають адрес один одного, бачачи тільки адресу сервера Janus; він виконує і функції сигнального сервера. Janus має безліч потрібних нам фіч: автоматично переходить в TCP, якщо у клієнта заблоковано UDP; вміє записувати потоки і UDP, і TCP; масштабується; є навіть вбудований плагін для ехо-тестів. У разі потреби автоматично підключаються STUN та TURN сервери від Twilio.
Влітку 2017 року у нас працювало два сервери Janus плюс додатковий сервер для обробки записаних сирих файлів аудіо та відео, щоб не займати процесори основних. При підключенні сервери Janus вибиралися за принципом чет-непар (номер з'єднання). На той момент цього вистачало, за нашими відчуттями давало приблизно чотириразовий запас міцності, відсоток впровадження становив близько 80. При цьому ціна скоротилася до 2 рублів за урок, плюс розробка та підтримка.
Повернення до теми відеозв'язку
Ми постійно моніторимо фідбек від учнів та викладачів, щоб вчасно виявляти та усунути проблеми. До літа 2018 року на першому місці серед скарг впевнено закріпилася якість зв'язку. З одного боку, це означало, що ми успішно впоралися з іншими недоліками. З іншого, потрібно було терміново щось робити: при зриві уроку ми ризикуємо втратити його вартість, іноді разом із вартістю покупки наступного пакета, а при зриві вступного заняття – взагалі втратити потенційного клієнта.
На той момент відеозв'язок у нас, як і раніше, знаходився в режимі MVP. Простіше кажучи, запустили, воно запрацювало, один раз масштабували, зрозуміли, як це робити – та й славно. Якщо це робота, don't fix it. Ніхто цілеспрямовано питання якості зв'язку не займався. До серпня стало ясно, що далі так продовжуватися не може, і ми запустили окремий напрямок, щоб розібратися, що ж у нас не так з WebRTC і Janus.
На вході цей напрямок отримав: рішення MVP, метрик немає, цілей немає, процесів щодо поліпшення немає, при цьому 7% вчителів скаржаться на якість зв'язку (даних учням теж не було).
Новий напрямок береться за роботу
Команда виглядає приблизно так:
- Керівник напряму, він же головний розробник.
- QA допомагають тестувати зміни, шукають нові способи створення нестабільних умов зв'язку, повідомляють про проблеми з лінії фронту.
- Аналітик постійно шукає різні кореляції у технічних даних, покращує аналіз фідбеку користувачів, перевіряє результати експериментів.
- Продакт-менеджер допомагає із загальним напрямом та виділенням ресурсів для експериментів.
- З самим програмуванням та суміжними завданнями часто допомагає другий розробник.
Для початку налаштували відносно надійну метрику, яка відстежувала зміни оцінки якості зв'язку (середнє по днях, тижнях, місяцях). На той час це були оцінки від вчителів, надалі до них додали оцінки від студентів. Далі почали будувати гіпотези, що працює не так, виправляти та дивитися на зміни в динаміці. Пішли низьковисокими фруктами: наприклад, замінили кодек 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 рік. У нас великі надії на те, що вдасться зберегти динаміку і більше не бачити відеозв'язок у топі скарг. Ми розуміємо, що значна частина цих скарг пов'язана з лагами комп'ютерів та інтернету користувачів, але ми повинні визначити цю частину та вирішити все інше. Решта — технічна проблема, здається, ми повинні вміти з нею справлятися.
Основна складність у тому, що ми не знаємо, до якого рівня взагалі реально підвищити якість. З'ясування цієї стелі – головне завдання. Тому було заплановано два експерименти:
- порівняти відео через Janus зі звичайним p2p у бойових умовах. Цей експеримент вже проведено, жодної статистично значущої різниці між нашим рішенням та p2p не виявлено;
- поставимо (дорогі) сервіси від компаній, що заробляють виключно на рішеннях в галузі відеозв'язку, і порівняємо кількість негативу від них із наявним.
Ці два експерименти дозволять нам визначити досяжну мету та сконцентруватися на ній.
Крім того, є ряд завдань, які вирішуються в робочому порядку:
- створюємо технічну метрику якості зв'язку замість суб'єктивних відгуків;
- робимо докладніші логи сесій, щоб точніше аналізувати трапляються збої, розуміти, коли і де саме вони сталися, які на перший погляд не пов'язані події мали місце в цей момент;
- готуємо автоматичний тест якості зв'язку перед уроком, а також дамо можливість клієнту протестувати зв'язок вручну, щоб зменшити кількість негативу, викликаного його залізом і каналом;
- розробимо і проводитимемо більше навантажувальних тестів відеозв'язку в поганих умовах, зі змінною втратою пакетів тощо;
- змінюємо поведінку серверів у разі проблем для підвищення стійкості до відмови;
- будемо попереджати користувача, якщо в нього щось не так взагалі зі зв'язком, як це робить той самий "Скайп", щоб він розумів, що проблема на його боці.
З квітня напрямок відеозв'язку стає повноцінним окремим проектом усередині Skyeng, що займається власним продуктом, не просто частиною Vimbox. А це означає, що ми починаємо шукати людей на . Ну і як завжди .
Ну і, звичайно, продовжуємо активно спілкуватися з людьми та компаніями, які працюють із відеозв'язком. Якщо ви хочете обмінятися з нами досвідом, ми будемо раді! Коментуйте, зв'язуйтесь – відповімо всім.
Джерело: habr.com