Video komunikace je hlavním způsobem komunikace mezi učitelem a studentem na platformě Vimbox. Skype jsme již dávno vzdali, vyzkoušeli několik řešení třetích stran a nakonec jsme se rozhodli pro kombinaci WebRTC - Janus-brána. Nějakou dobu jsme byli se vším spokojeni, ale přesto se stále objevovaly některé negativní aspekty. V důsledku toho vznikla samostatná videorežie.
Požádal jsem Kirilla Rogovoye, šéfa nového směru, aby promluvil o vývoji video komunikace ve Skyengu, objevených problémech, řešeních a berlích, které jsme nakonec použili. Doufáme, že článek bude užitečný pro společnosti, které také sami vytvářejí video prostřednictvím webové aplikace.
Trocha historie
V létě 2017 vystoupil vedoucí vývoje Skyeng, Sergey Safonov, na Backend Conf s příběhem o tom, jak jsme „opustili Skype a implementovali WebRTC“. Zájemci se mohou podívat na záznam projevu na (~45 min), a zde stručně nastíním jeho podstatu.
Pro školu Skyeng byla videokomunikace vždy prioritním způsobem komunikace mezi učitelem a studentem. Zpočátku se používal Skype, který však kategoricky nevyhovoval z řady důvodů, především kvůli chybějícím logům a nemožnosti integrace přímo do webové aplikace. Proto jsme prováděli nejrůznější experimenty.
Ve skutečnosti byly naše požadavky na videokomunikaci přibližně následující:
— stabilita;
— nízká cena za lekci;
— nahrávání lekcí;
— sledování toho, kdo kolik mluví (pro nás je důležité, aby studenti během výuky mluvili více než učitel);
— lineární škálování;
- schopnost používat UDP i TCP.
První, kdo se pokusil implementovat Tokbox v roce 2013. Všechno bylo dobré, ale ukázalo se, že je to velmi drahé - 113 rublů za lekci - a sežralo zisk.
V roce 2015 byl integrován Voximplant. Zde byla funkce, kterou jsme potřebovali ke sledování, kdo kolik mluví, a zároveň bylo řešení mnohem levnější: pokud se nahrával pouze zvuk, stálo to 20 rublů za lekci. Fungovalo to však pouze přes UDP a nešlo přepnout na TCP. Asi 40 % studentů jej však nakonec využilo.
O rok později jsme začali mít firemní klientelu s vlastními specifickými požadavky. Vše by mělo například fungovat přes prohlížeč, firma otevírá pouze http a https; tedy žádný Skype nebo UDP. Firemní klienti = peníze, tak se vrátili k Tokboxu, ale problém s cenou nezmizel.
Řešení - WebRTC a Janus
Rozhodl se použít . Je zodpovědný za navázání spojení, kódování a dekódování toků, synchronizaci stop a kontrolu kvality s řešením síťových závad. Z naší strany musíme zajistit čtení streamů z kamery a mikrofonu, kreslení videa, správu spojení, navázání spojení WebRTC a přenos streamů na něj a také přenos signálních zpráv mezi klienty k navázání spojení (WebRTC sám popisuje pouze datový formát, ale ne jeho mechanismus přenosu). Pokud jsou klienti za NAT, WebRTC připojí servery STUN, pokud to nepomůže, servery TURN.
Běžné p2p připojení nám nestačí, protože chceme lekce nahrávat pro další rozbor v případě reklamací. Proto posíláme streamy WebRTC přes relé . V důsledku toho klienti navzájem neznají své adresy a vidí pouze adresu serveru Janus; plní také funkce signálního serveru. Janus má mnoho funkcí, které potřebujeme: automaticky přepne na TCP, pokud má klient zablokované UDP; umí nahrávat UDP i TCP streamy; škálovatelný; K dispozici je dokonce vestavěný plugin pro testy ozvěny. V případě potřeby se automaticky připojí servery STUN a TURN od Twilio.
V létě 2017 jsme měli spuštěné dva Janus servery plus další server pro zpracování nahraných raw audio a video souborů, abychom nezabírali procesory těch hlavních. Při připojování byly servery Janus vybírány na základě lichých-sudých (číslo připojení). V té době to stačilo, podle našich pocitů to dávalo přibližně čtyřnásobnou bezpečnostní rezervu, procento implementace bylo asi 80. Zároveň byla cena snížena na ~2 rubly za lekci, plus vývoj a podpora.
Vraťme se k tématu videokomunikace
Neustále sledujeme zpětnou vazbu od studentů a učitelů, abychom včas identifikovali a opravili problémy. V létě 2018 byla kvalita hovorů pevně na prvním místě mezi stížnostmi. Na jednu stranu to znamenalo, že jsme úspěšně překonali další nedostatky. Na druhou stranu bylo nutné něco urychleně udělat: pokud bude lekce narušena, riskujeme ztrátu její hodnoty, někdy i náklady na nákup dalšího balíčku, a pokud bude úvodní lekce narušena, riskujeme ztrátu potenciálního klienta celkem.
V té době byla naše videokomunikace ještě v režimu MVP. Jednoduše řečeno, spustili to, fungovalo to, jednou to škálovali, pochopili, jak to udělat - no, skvělé. Pokud to funguje, neopravujte to. Nikdo se záměrně nezabýval otázkou kvality komunikace. V srpnu bylo jasné, že to nemůže pokračovat, a vydali jsme samostatný směr, abychom zjistili, co je s WebRTC a Janusem špatně.
Na vstupu tento směr obdržel: řešení MVP, žádné metriky, žádné cíle, žádné procesy pro zlepšování, přičemž 7 % učitelů si stěžuje na kvalitu komunikace (nebyla ani data o studentech).
Probíhá nový směr
Příkaz vypadá asi takto:
- Vedoucí oddělení, který je zároveň hlavním vývojářem.
- QA pomáhá testovat změny, hledá nové způsoby, jak vytvořit nestabilní komunikační podmínky a hlásí problémy z první linie.
- Analytik neustále hledá různé korelace v technických datech, zlepšuje analýzu zpětné vazby uživatelů a kontroluje výsledky experimentů.
- Produktový manažer pomáhá s celkovým směřováním a alokací zdrojů pro experimenty.
- Druhý vývojář často pomáhá s programováním a souvisejícími úkoly.
Pro začátek jsme nastavili poměrně spolehlivou metriku, která sledovala změny v hodnocení kvality komunikace (průměr za dny, týdny, měsíce). Tehdy to byly známky od učitelů, později se k nim přidaly známky od studentů. Pak začali vytvářet hypotézy o tom, co fungovalo špatně, opravovali to a sledovali změny v dynamice. Šli jsme na nízko visící ovoce: například jsme nahradili kodek vp8 za vp9, výkon se zlepšil. Zkusili jsme si pohrát s nastavením Janus a provést další experimenty – ve většině případů k ničemu nevedly.
Ve druhé fázi se objevila hypotéza: WebRTC je řešení typu peer-to-peer a uprostřed používáme server. Možná je problém tady? Začali jsme kopat a našli jsme zatím nejvýraznější zlepšení.
V tu chvíli byl server z fondu vybrán pomocí poněkud hloupého algoritmu: každý měl svou vlastní „váhu“ v závislosti na kanálu a výkonu a my jsme se pokusili poslat uživatele na ten s největší „váhou“, aniž by věnujte pozornost tomu, kde se uživatel geograficky nacházel. V důsledku toho mohl učitel z Petrohradu komunikovat se studentem ze Sibiře přes Moskvu, a ne přes náš server Janus v Petrohradě.
Algoritmus byl přepracován: nyní, když uživatel otevře naši platformu, shromažďujeme od něj pingy na všechny servery používající Ajax. Při navazování spojení vybereme pár pingů (učitel-server a student-server) s nejmenším množstvím. Méně ping znamená menší vzdálenost sítě od serveru; kratší vzdálenost znamená nižší pravděpodobnost ztráty paketů; Ztráta paketů je největším negativním faktorem video komunikace. Podíl negativity klesl za tři měsíce o polovinu (abychom byli spravedliví, v této době byly provedeny další experimenty, ale tento měl téměř jistě největší dopad).
Nedávno jsme objevili další nezřejmou, ale zjevně důležitou věc: místo jednoho výkonného serveru Janus na tlustém kanálu je lepší mít dva jednodušší s tenčí šířkou pásma. To se ukázalo poté, co jsme koupili výkonné stroje v naději, že do nich nacpeme co nejvíce místností (komunikačních relací) současně. Servery mají limit šířky pásma, který můžeme přesně převést na počet místností – víme, kolik jich lze otevřít například rychlostí 300 Mbit/s. Jakmile je na serveru otevřeno příliš mnoho místností, přestaneme jej vybírat pro nové aktivity, dokud se zátěž nesníží. Myšlenka byla taková, že po zakoupení výkonného stroje na něj načteme kanál na maximum, takže nakonec bude omezen procesorem a pamětí, nikoli šířkou pásma. Ukázalo se ale, že po určitém počtu otevřených místností (420), přestože je zatížení procesoru, paměti a disku stále velmi daleko od limitů, se na technickou podporu začíná dostávat negativita. Uvnitř Januse se zřejmě něco zhoršuje, možná jsou tam i nějaká omezení. Začali jsme experimentovat, snížili jsme limit šířky pásma z 300 na 200 Mbit/s a problémy zmizely. Nyní jsme koupili tři nové servery najednou s nízkými limity a vlastnostmi, myslíme si, že to povede ke stabilnímu zlepšování kvality komunikace. Samozřejmě jsme se nesnažili přijít na to, co se tam děje, naše berličky jsou vším. Na naši obranu řekněme, že v tu chvíli bylo nutné naléhavý problém vyřešit co nejrychleji, a ne to udělat krásně; navíc Janus je pro nás černá skříňka napsaná v C, je velmi drahé se s tím šťourat.
No, v procesu my:
- aktualizovaly všechny závislosti, které bylo možné aktualizovat, jak na serveru, tak na klientovi (to byly také experimenty, výsledky jsme sledovali);
- opraveny všechny zjištěné chyby související s konkrétními případy, například když se spojení přerušilo a nebylo automaticky obnoveno;
- Uspořádali jsme mnoho schůzek se společnostmi působícími v oblasti video komunikace a obeznámenými s našimi problémy: streamování her, pořádání webinářů; vyzkoušeli jsme vše, co se nám zdálo užitečné;
- Provedena technická kontrola kvality hardwaru a komunikace učitelů, od kterých přišlo nejvíce stížností.
Experimenty a následné změny umožnily snížit nespokojenost s komunikací mezi učiteli ze 7,1 % v lednu 2018 na 2,5 % v lednu 2019.
Co je další
Stabilizace naší platformy Vimbox je jedním z hlavních projektů společnosti pro rok 2019. Pevně doufáme, že se nám podaří udržet tempo a již nebudeme vidět videokomunikaci v hlavních stížnostech. Chápeme, že značná část těchto stížností souvisí se zpožděním v počítačích uživatelů a internetu, ale tuto část musíme určit a zbytek vyřešit. Vše ostatní je technický problém, zdá se, že bychom si s ním měli být schopni poradit.
Hlavním problémem je, že nevíme, na jakou úroveň je skutečně možné zlepšit kvalitu. Zjistit tento strop je hlavním úkolem. Proto byly naplánovány dva experimenty:
- porovnejte video přes Janus s běžným p2p v bojových podmínkách. Tento experiment již byl proveden, nebyl zjištěn žádný statisticky významný rozdíl mezi naším řešením a p2p;
- Dodávejme (drahé) služby od firem, které vydělávají výhradně na videokomunikačních řešeních, a porovnejme množství negativity z nich s tou stávající.
Tyto dva experimenty nám umožní identifikovat dosažitelný cíl a zaměřit se na něj.
Kromě toho existuje řada úkolů, které lze běžně řešit:
- Místo subjektivních recenzí vytváříme technickou metriku kvality komunikace;
- Vytváříme podrobnější protokoly relací, abychom mohli přesněji analyzovat selhání, ke kterým dochází, abychom pochopili, kdy a kde přesně k nim došlo, a jaké zdánlivě nesouvisející události se v tu chvíli odehrály;
- Před lekcí připravujeme automatický test kvality připojení a také dáváme klientovi možnost ručně otestovat připojení, aby se snížilo množství negativity způsobené jeho hardwarem a kanálem;
- vyvineme a provedeme více zátěžových testů video komunikace ve špatných podmínkách, s proměnlivou ztrátou paketů atd.;
- měníme chování serverů v případě problémů, abychom zvýšili odolnost proti chybám;
- Upozorníme uživatele, pokud je s jeho připojením vůbec něco v nepořádku, jako to dělá Skype, aby pochopil, že problém je na jeho straně.
Od dubna se z videokomunikačního směru stal v rámci Skyeng plnohodnotný samostatný projekt zabývající se vlastním produktem, nejen součástí Vimboxu. To znamená, že začínáme hledat lidi na . No jako vždy .
A samozřejmě i nadále aktivně komunikujeme s lidmi a společnostmi pracujícími s videokomunikací. Pokud si s námi chcete vyměnit zkušenosti, budeme rádi! Komentujte, ozvěte se - všem odpovíme.
Zdroj: www.habr.com