Videohovory sú hlavným spôsobom komunikácie učiteľa a študenta na platforme Vimbox. Už dávno sme sa vzdali Skypu, vyskúšali sme niekoľko externých riešení a nakoniec sme sa rozhodli pre kombináciu WebRTC – Janus-gateway. Po určitý čas sme boli so všetkým spokojní, ale aj napriek tomu sa stále objavovali niektoré negatívne momenty. Nakoniec sme vytvorili samostatný smer pre video.
Požiadal som Kirilla Rogovogo, vedúceho nového smeru, aby nám prerozprával evolúciu videohovoru v Skyeng, objavené problémy, riešenia a obmedzenia, ktoré sme nakoniec použili. Dúfame, že článok bude užitočný aj pre firmy, ktoré takisto implementujú video cez webovú aplikáciu.
Trochu histórie
V lete 2017 predstavil vedúci vývoja Skyeng Sergej Safonov na Backend Conf tému, ako sme „s Skypom skončili a implementovali WebRTC“. Záujemcovia si môžu pozrieť záznam jeho vystúpenia na (~45 min), a tu zhrniem jeho základné myšlienky.
Pre školu Skyeng boli videohovory vždy prioritným spôsobom komunikácie učiteľ-žiak. Na začiatku sme používali „Skype“, ale ten nás z viacerých dôvodov absolútne neuspokojoval, predovšetkým kvôli nedostatku logov a nemožnosti integrácie priamo do webovej aplikácie. Preto sme realizovali rôzne experimenty.
Požiadavky na videohovor boli približne takéto:
— stabilita;
— nízka cena za hodinu;
— nahrávanie hodín;
— sledovanie, kto koľko hovorí (je pre nás dôležité, aby žiaci hovorili na hodinách viac ako učitelia);
— lineárne škálovanie;
— možnosť používať ako UDP, tak aj TCP.
Prvým, ktorý sme v roku 2013 vyskúšali implementovať, bol Tokbox. Všetko bolo v poriadku, ale bolo to veľmi drahé – 113 rubľov za hodinu – a konzumovalo to zisk.
Potom sme v roku 2015 integrovali Voximplant. Tu bola potrebná funkcia sledovania, kto koľko hovorí, a zároveň bolo toto riešenie výrazne lacnejšie: za podmienky nahrávania iba zvuku to vyšlo na 20 rubľov za hodinu. Avšak fungovalo to iba cez UDP, prepnúť sa na TCP to nevedelo. Napriek tomu to nakoniec používalo asi 40% žiakov.
Po roku sme začali získavať firemných klientov s ich špecifickými požiadavkami. Napríklad, všetko musí fungovať cez prehliadač, v spoločnosti sú povolené iba http a https; teda žiadne „Skypy“ a UDP. Firemní klienti = peniaze, preto sme sa vrátili k Tokboxu, ale problém s cenou nezmizol.
Riešenie — WebRTC a Janus
Rozhodli sme sa použiť . Zabezpečuje nadväzovanie spojenia, kódovanie a dekódovanie prúdov, synchronizáciu stôp a kontrolu kvality s riadením sieťových problémov. Z našej strany musíme zabezpečiť čítanie prúdov z kamery a mikrofónu, vykreslovanie videa, správu spojenia, nastavenie WebRTC pripojenia a prenos prúdov naň, ako aj prenos signálnych správ medzi klientmi na nadviazanie spojenia (sám WebRTC opisuje iba formát dát, ale nie mechanizmus ich prenosu). V prípade, že sú klienti za NAT, WebRTC sa pripojuje k STUN serverom, ak to nepomáha, TURN serverom.
Zvyčajného p2p spojenia nám nestačí, pretože chceme nahrávať lekcie pre ďalšiu analýzu v prípade reklamácií. Preto prenášame prúdy WebRTC cez retranslátor . V dôsledku toho klienti nepoznajú adresy jeden druhého a vidia iba adresu servera Janus; ten tiež plní funkciu signálneho servera. Janus má množstvo potrebných funkcií: automaticky prechádza na TCP, ak má klient zablokované UDP; dokáže nahrávať prúdy cez UDP aj TCP; škáluje; a má dokonca zabudovaný plugin na echo testy. V prípade potreby sa automaticky pripájajú STUN a TURN servery od Twilio.
V lete 2017 sme mali v prevádzke dva servery Janus plus ďalší server na spracovanie nahratých surových súborov zvuku a videa, aby sme nezaberali procesory hlavných. Pri pripojení sa servery Janus vyberali podľa princípu pár-nepár (číslo spojenia). V tom čase to stačilo, podľa našich pocitov to dávalo približne štvornásobný rezervačný faktor, miera zavedenia bola približne 80. Pri tom cena klesla na ~2 ruble za lekciu, plus vývoj a podpora.
Návrat k téme videohovorov
Stále sledujeme spätnú väzbu od žiakov a učiteľov, aby sme včas odhalili a zastavili problémy. Do léta 2018 sa na prvom mieste medzi sťažnosťami pevne usadila kvalita spojenia. Na jednej strane to znamenalo, že sme úspešne zvládli iné nedostatky. Na druhej strane bolo nutné rýchlo niečo urobiť: pri prerušených lekciách riskujeme stratu ich hodnoty, niekedy spolu s hodnotou nákupu ďalšieho balíka, a pri prerušeniach úvodnej hodiny dokonca riskujeme stratu potenciálneho klienta.
V tom čase bola naša videokomunikácia stále v režime MVP. Jednoducho povedané, spustili sme to, fungovalo to, raz sme to škálovali, pochopili sme, ako na to – a to bola paráda. If it works, don’t fix it. Nikto sa cielene nezaoberal otázkou kvality spojenia. Do augusta sa ukázalo, že takto to nemôže pokračovať, a spustili sme samostatný smer, aby sme sa vysporiadali s problémom s WebRTC a Janus.
Na vstupe tento smer dostal: riešenie MVP, žiadne metriky, žiadne ciele, žiadne procesy na zlepšovanie, pričom 7% učiteľov si sťažovalo na kvalitu spojenia (údaje o žiakoch tiež neexistovali).
Nový smer sa pustil do práce
Príkaz vyzerá asi takto:
- Vedúci smeru, ktorý je tiež hlavným vývojárom.
- QA pomáha testovať zmeny, hľadá nové spôsoby, ako vytvárať nestabilné podmienky spojenia, hlási problémy z frontu.
- Analytik neustále hľadá rôzne korelácie v technických dátach, zlepšuje analýzu spätnej väzby používateľov, kontroluje výsledky experimentov.
- Produktový manažér pomáha s celkovým smerovaním a prideľovaním zdrojov na experimenty.
- S programovaním a súvisiacimi úlohami často pomáha druhý vývojár.
Na začiatku sme nastavili relatívne spoľahlivú metriku, ktorá sledovala zmeny hodnotenia kvality spojenia (priemer za dni, týždne, mesiace). V tom čase to boli hodnotenia od učiteľov, neskôr sme k nim pridali hodnotenia od študentov. Následne sme začali formulovať hypotézy o tom, čo nefunguje, opravovali sme to a sledovali zmeny v dynamike. Išli sme po nízko visiacich plodoch: napríklad sme vymenili kodek vp8 za vp9 a ukazovatele sa zlepšili. Skúšali sme hrať sa s nastaveniami Janus, vykonávať ďalšie experimenty – vo väčšine prípadov bez výsledku.
V druhej fáze sa objavila hypotéza: WebRTC je riešenie peer-to-peer, zatiaľ čo my používame server uprostred. Možno je problém práve tu? Začali sme kopnúť a našli sme tu zatiaľ najvýznamnejšie zlepšenie.
V tom čase sa server z poolu vyberal podľa pomerne základného algoritmu: každý mal svoj "váhu", ktorá závisela od kanála a výkonu, a snažili sme sa poslať používateľa na ten, kde bola "váha" vyššia, bez ohľadu na to, kde sa používateľ geograficky nachádza. Výsledkom bolo, že učiteľ z Petrohradu mohol komunikovať so žiakom zo Sibíri cez Moskvu, a nie cez náš Janus server v SPb.
Algoritmus sme prepracovali: teraz, keď používateľ otvorí našu platformu, pomocou Ajaxu zbierame pingi od neho k všetkým serverom. Pri nadviazaní spojenia vyberáme pár pingov (učiteľ-server a žiak-server) s najnižším súčtom. Nižší ping znamená menšiu sieťovú vzdialenosť k serveru; menšia vzdialenosť — nižšia pravdepodobnosť straty paketov; strata paketov je najväčším negatívnym faktorom vo videohovoroch. Podiel negatívnych skúseností za tri mesiace klesol na polovicu (pre spravodlivosť, počas tohto obdobia prebiehali aj ďalšie experimenty, ale tento takmer určite mal najväčší vplyv).
Nedávno sme objavili ešte jednu nevydarenú, ale zjavne dôležitú vec: namiesto jedného výkonného servera Janus na silnom kanáli je lepšie mať dva jednoduchšie s nižšou priepustnosťou. Toto sme zistili po tom, čo sme zakúpili práve výkonné stroje v nádeji, že do nich narveme čo najviac miestností (komunikačných relácií) naraz. Servery majú limit priepustnosti, ktorý môžeme presne prevádzať na počet miestností — vieme, koľko ich možno otvoriť napríklad na 300 Mbit/s. Hneď ako je na serveri otvorených príliš veľa miestností — prestávame ho vyberať na nové aktivity, kým sa záťaž nezníži. Nápad bol v tom, že ak kúpime výkonný stroj, maximálne vyťažíme kanál, aby sme sa nakoniec dostali k procesoru a pamäti, a nie k priepustnosti. Ale ukázalo sa, že po určitom počte otvorených miestností (420), aj keď využitie procesora, pamäte a disku je ešte veľmi ďaleko od limitov, začína prichádzať negatívna spätná väzba z technickej podpory. Zjavne sa niečo zhoršuje vo vnútri Janus, možno tam tiež existujú nejaké obmedzenia. Začali sme experimentovať, znížili sme limit priepustnosti z 300 na 200 Mbit/s, problémy sa stratili. Teraz sme zakúpili hneď tri nové servery s nízkymi limitmi a charakteristikami, veríme, že to povedie k stabilnému zlepšeniu kvality spojenia. Skúmať, čo tam bolo na príčine, sme samozrejme nezačali, pretendujúci sme všetko. Na svoju obhajobu povieme, že v tej chvíli bolo potrebné čo najrýchlejšie vyriešiť aktuálny problém, nie to urobiť krásne; navyše Janus pre nás — čierna skrinka napísaná v C, s ktorou je veľmi nákladné sa zaoberať.
No a v procese sme:
- aktualizovali všetky závislosti, ktoré sa dali aktualizovať, ako na serveri, tak aj na kliente (to boli tiež experimenty, sledovali sme výsledok);
- opravil všetky zistené chyby týkajúce sa konkrétnych prípadov, napríklad keď spojenie klesalo a neobnovovalo sa automaticky;
- usporiadali mnoho stretnutí s firmami, ktoré pracujú v oblasti videokomunikácie a sú oboznámené s našimi problémami: streamovať hry, organizovať webináre; vyskúšali sme všetko, čo sa nám zdalo užitočné;
- uskutočnili technické preskúmanie hardvéru a kvality spojenia u učiteľov, od ktorých prichádzalo najviac sťažností.
Experimenty a následné zmeny nám umožnili znížiť nespokojnosť učiteľov s videonahovom z 7,1% v januári 2018 na 2,5% v januári 2019.
Čo ďalej
Stabilizácia našej platformy Vimbox je jeden z hlavných projektov spoločnosti na rok 2019. Máme veľké očakávania, že sa nám podarí udržať dynamiku a už viac nevidieť videonahov na vrchole sťažností. Chápeme, že značná časť týchto sťažností súvisí so zdržaním počítačov a internetu používateľov, ale musíme identifikovať túto časť a vyriešiť všetko ostatné. Všetko ostatné je technický problém, s ktorým by sme si mali vedieť poradiť.
Hlavnou ťažkosťou je, že nevieme, do akej úrovne je vôbec reálne zvýšiť kvalitu. Zistenie tejto stropnej hodnoty je hlavnou úlohou. Preto boli naplánované dva experimenty:
- porovnať video cez Janus s obyčajným p2p v bojových podmienkach. Tento experiment sa už uskutočnil, žiadny štatisticky významný rozdiel medzi naším riešením a p2p nebol zistený;
- nasadíme (drahé) služby od spoločností, ktoré zarábajú výlučne na riešeniach v oblasti videonahov a porovnáme množstvo negativity od nich s existujúcim.
Tieto dva experimenty nám umožnia určiť dosiahnuteľný cieľ a sústrediť sa naň.
Okrem toho existuje rad úloh, ktoré sa riešia v rámci pracovného procesu:
- vytvárame technickú metriku kvality spojenia namiesto subjektívnych hodnotení;
- robíme podrobnejšie logy relácií, aby sme presnejšie analyzovali vyskytujúce sa zlyhania, pochopili, kedy a kde presne sa stali, aké na prvý pohľad nesúvisiace udalosti sa v tom čase vyskytli;
- pripravíme automatický test kvality spojenia pred hodinou a tiež poskytneme klientovi možnosť manuálne otestovať spojenie, aby sme znížili množstvo negativity spôsobenej jeho hardvérom a kanálom;
- vyvinúť a vykonávať viac záťažových testov videonahov v zlých podmienkach, so stratou paketov a pod.;
- meníme správanie serverov v prípade problémov na zvýšenie odolnosti;
- budeme varovať používateľa, ak má niečo úplne zle so spojom, ako to robí aj Skype, aby vedel, že problém je na jeho strane.
Od apríla sa smerovanie videokonferencií stáva plnohodnotným samostatným projektom v rámci Skyeng, ktorý sa zaoberá vlastným produktom a nie je iba súčasťou Vimboxu. To znamená, že začíname hľadať ľudí na . No a ako vždy .
. A samozrejme pokračujeme v aktívnom rozhovore s ľuďmi a spoločnosťami, ktoré pracujú s videokonferenciami. Ak sa chcete s nami podeliť o skúsenosti, budeme radi! Komentujte, kontaktujte nás — odpovieme všetkým.
Zdroj: habr.com
