Відэасувязь - асноўны спосаб зносін выкладчыка і студэнта на платформе 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. Прасцей кажучы, запусцілі, яно зарабіла, адзін раз маштабавалі, зразумелі, як гэта рабіць - ну і хвалебна. If it works, 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