Video komunikácia je hlavným spôsobom komunikácie medzi učiteľom a študentom na platforme Vimbox. Skype sme už dávno vzdali, vyskúšali niekoľko riešení tretích strán a nakoniec sme sa rozhodli pre kombináciu WebRTC – Janus – brána. Nejaký čas sme boli so všetkým spokojní, no stále sa objavovali nejaké negatívne stránky. V dôsledku toho vznikla samostatná video réžia.
Požiadal som Kirilla Rogovoya, šéfa nového smerovania, aby hovoril o vývoji videokomunikácie v Skyeng, objavených problémoch, riešeniach a barličkách, ktoré sme nakoniec použili. Dúfame, že článok bude užitočný pre spoločnosti, ktoré si video vytvárajú aj svojpomocne prostredníctvom webovej aplikácie.
Trocha histórie
V lete 2017 vedúci vývoja Skyeng, Sergey Safonov, hovoril na Backend Conf s príbehom o tom, ako sme „opustili Skype a implementovali WebRTC“. Záujemcovia si záznam prejavu môžu pozrieť na (~45 min), a tu stručne načrtnem jej podstatu.
Pre Skyeng School bola video komunikácia vždy prioritným spôsobom komunikácie medzi učiteľom a študentom. Najprv sa používal Skype, ktorý však kategoricky nevyhovoval z viacerých dôvodov, predovšetkým kvôli nedostatku protokolov a nemožnosti integrácie priamo do webovej aplikácie. Preto sme robili všelijaké experimenty.
V skutočnosti boli naše požiadavky na videokomunikáciu približne nasledovné:
— stabilita;
— nízka cena za lekciu;
— nahrávanie hodín;
— sledovanie toho, kto koľko hovorí (pre nás je dôležité, aby žiaci počas vyučovania hovorili viac ako učiteľ);
— lineárne škálovanie;
- schopnosť používať UDP aj TCP.
Prvým pokusom bolo implementovať Tokbox v roku 2013. Všetko bolo dobré, ale ukázalo sa, že je to veľmi drahé - 113 rubľov za lekciu - a zjedol zisk.
Potom v roku 2015 bol integrovaný Voximplant. Tu bola funkcia, ktorú sme potrebovali na sledovanie toho, kto koľko hovoril, a zároveň bolo riešenie oveľa lacnejšie: ak sa nahrával iba zvuk, stálo to 20 rubľov za lekciu. Fungoval však len cez UDP a nevedel sa prepnúť na TCP. Asi 40 % študentov ho však nakoniec využilo.
O rok neskôr sme začali mať firemných klientov s vlastnými špecifickými požiadavkami. Napríklad všetko by malo fungovať cez prehliadač, spoločnosť otvára iba http a https; tj žiadny Skype alebo UDP. Firemná klientela = peniaze, tak sa vrátili k Tokboxu, no problém s cenou nezmizol.
Riešenie - WebRTC a Janus
Rozhodol sa použiť . Je zodpovedný za nadviazanie spojenia, kódovanie a dekódovanie tokov, synchronizáciu stôp a kontrolu kvality s riešením sieťových závad. Z našej strany musíme zabezpečiť čítanie streamov z kamery a mikrofónu, kreslenie videa, správu spojenia, nadviazanie spojenia WebRTC a prenos streamov naň, ako aj prenos signalizačných správ medzi klientmi na vytvorenie spojenia (samotný WebRTC popisuje iba dátový formát, ale nie jeho mechanizmus prenosu). Ak sú klienti za NAT, WebRTC pripojí servery STUN; ak to nepomôže, servery TURN.
Bežné p2p pripojenie nám nestačí, pretože chceme nahrávať lekcie pre ďalšiu analýzu v prípade reklamácií. Preto posielame streamy WebRTC cez relé . Výsledkom je, že klienti navzájom nepoznajú svoje adresy, vidia iba adresu servera Janus; tiež vykonáva funkcie signálneho servera. Janus má veľa funkcií, ktoré potrebujeme: automaticky sa prepne na TCP, ak má klient zablokované UDP; môže zaznamenávať prúdy UDP aj TCP; škálovateľný; K dispozícii je dokonca aj vstavaný doplnok pre testy ozveny. V prípade potreby sa automaticky pripoja servery STUN a TURN od Twilio.
V lete 2017 sme mali spustené dva servery Janus plus ďalší server na spracovanie nahratých nespracovaných audio a video súborov, aby sme nezaberali procesory tých hlavných. Pri pripájaní boli servery Janus vybrané na základe párneho a nepárneho (číslo pripojenia). Vtedy to stačilo, podľa našich pocitov to dávalo približne štvornásobnú bezpečnostnú rezervu, percento implementácie bolo asi 80. Zároveň sa cena znížila na ~2 ruble za lekciu plus rozvoj a podpora.
Vráťme sa k téme videokomunikácie
Neustále sledujeme spätnú väzbu od študentov a učiteľov, aby sme včas identifikovali a opravili problémy. Do leta 2018 bola kvalita hovorov pevne na prvom mieste medzi sťažnosťami. Na jednej strane to znamenalo, že ďalšie nedostatky sme úspešne prekonali. Na druhej strane bolo potrebné niečo urgentne urobiť: ak sa lekcia naruší, riskujeme stratu jej hodnoty, niekedy aj s nákladmi na nákup ďalšieho balíčka, a ak sa naruší úvodná lekcia, riskujeme stratu potenciálneho klienta celkom.
V tom čase bola naša videokomunikácia ešte v režime MVP. Jednoducho povedané, spustili to, fungovalo to, raz to škálovali, pochopili, ako to urobiť - no, skvelé. Ak to funguje, neopravujte to. Nikto sa zámerne nezaoberal otázkou kvality komunikácie. V auguste sa ukázalo, že to nemôže pokračovať, a vydali sme samostatný smer, aby sme zistili, čo je zlé s WebRTC a Janusom.
Na vstupe tento smer dostal: riešenie MVP, žiadne metriky, žiadne ciele, žiadne procesy na zlepšovanie, pričom 7 % učiteľov sa sťažuje na kvalitu komunikácie (neboli ani údaje o študentoch).
Nastupuje nový smer
Príkaz vyzerá asi takto:
- Vedúci oddelenia, ktorý je zároveň hlavným developerom.
- QA pomáha testovať zmeny, hľadá nové spôsoby vytvárania nestabilných komunikačných podmienok a hlási problémy z prvej línie.
- Analytik neustále hľadá rôzne korelácie v technických údajoch, zlepšuje analýzu spätnej väzby používateľov a kontroluje výsledky experimentov.
- Produktový manažér pomáha s celkovým smerovaním a prideľovaním zdrojov pre experimenty.
- Druhý vývojár často pomáha s programovaním a súvisiacimi úlohami.
Na začiatok sme nastavili relatívne spoľahlivú metriku, ktorá sledovala zmeny v hodnotení kvality komunikácie (priemer za dni, týždne, mesiace). Vtedy to boli známky od učiteľov, neskôr sa k nim pridali známky od žiakov. Potom začali vytvárať hypotézy o tom, čo fungovalo nesprávne, opravovali to a sledovali zmeny v dynamike. Išli sme do nízko visiaceho ovocia: napríklad sme nahradili kodek vp8 za vp9, výkon sa zlepšil. Snažili sme sa pohrať s Janusovým nastavením a vykonať ďalšie experimenty – vo väčšine prípadov k ničomu neviedli.
V druhej fáze sa objavila hypotéza: WebRTC je riešenie typu peer-to-peer a v strede používame server. Možno je problém tu? Začali sme kopať a našli sme zatiaľ najvýraznejšie zlepšenie.
V tom momente bol server z fondu vybraný pomocou dosť hlúpeho algoritmu: každý mal svoju vlastnú „váhu“ v závislosti od kanála a výkonu a pokúsili sme sa používateľa poslať na server s najväčšou „váhou“ bez venujte pozornosť tomu, kde sa používateľ geograficky nachádzal. Výsledkom bolo, že učiteľ z Petrohradu mohol komunikovať so študentom zo Sibíri cez Moskvu, a nie cez náš server Janus v Petrohrade.
Algoritmus bol prepracovaný: teraz, keď používateľ otvorí našu platformu, zhromažďujeme od neho pingy na všetky servery používajúce Ajax. Pri nadväzovaní spojenia vyberieme pár pingov (učiteľ-server a študent-server) s najmenším množstvom. Menej ping znamená menšiu vzdialenosť siete od servera; kratšia vzdialenosť znamená nižšiu pravdepodobnosť straty paketov; Strata paketov je najväčším negatívnym faktorom vo videokomunikácii. Podiel negativity klesol o polovicu za tri mesiace (aby sme boli spravodliví, v tomto čase sa robili aj iné experimenty, ale tento mal takmer určite najväčší vplyv).
Nedávno sme objavili ďalšiu nezrejmú, ale zjavne dôležitú vec: namiesto jedného výkonného servera Janus na hrubom kanáli je lepšie mať dva jednoduchšie s tenšou šírkou pásma. To sa ukázalo po tom, čo sme kúpili výkonné stroje v nádeji, že do nich naraz natlačíme čo najviac miestností (komunikačných relácií). Servery majú limit šírky pásma, ktorý vieme presne premietnuť do počtu miestností – vieme, koľko je možné otvoriť napríklad rýchlosťou 300 Mbit/s. Akonáhle je na serveri otvorených príliš veľa miestností, prestaneme ho vyberať pre nové aktivity, kým sa zaťaženie nezníži. Myšlienkou bolo, že po zakúpení výkonného stroja naň načítame kanál na maximum, takže v konečnom dôsledku bude obmedzený procesorom a pamäťou, a nie šírkou pásma. Ukázalo sa však, že po určitom počte otvorených miestností (420), napriek tomu, že zaťaženie procesora, pamäte a disku je stále veľmi ďaleko od limitov, na technickú podporu začína dochádzať negatíva. Vnútri Janusa sa zrejme niečo zhoršuje, možno sú tam aj nejaké obmedzenia. Začali sme experimentovať, znížili sme limit šírky pásma z 300 na 200 Mbit/s a problémy zmizli. Teraz sme kúpili tri nové servery naraz s nízkymi limitmi a vlastnosťami, myslíme si, že to povedie k stabilnému zvyšovaniu kvality komunikácie. Samozrejme, nesnažili sme sa zistiť, čo sa tam deje; naše barle sú všetko. Na našu obranu povedzme, že v tej chvíli bolo potrebné vyriešiť naliehavý problém čo najrýchlejšie, a nie to urobiť krásne; okrem toho Janus je pre nas cierna skrinka napisana v C, hrat sa s tym je velmi drahe.
No, v tomto procese:
- aktualizovali všetky závislosti, ktoré sa dali aktualizovať, na serveri aj na klientovi (tiež to boli experimenty, výsledky sme sledovali);
- opravené všetky zistené chyby súvisiace s konkrétnymi prípadmi, napríklad keď sa spojenie prerušilo a nebolo automaticky obnovené;
- Uskutočnili sme množstvo stretnutí so spoločnosťami pracujúcimi v oblasti videokomunikácií a oboznámenými s našimi problémami: streamovanie hier, organizovanie webinárov; vyskúšali sme všetko, čo sa nám zdalo užitočné;
- Uskutočnil technickú kontrolu kvality hardvéru a komunikácie učiteľov, od ktorých prišlo najviac sťažností.
Experimenty a následné zmeny umožnili znížiť nespokojnosť s komunikáciou medzi učiteľmi zo 7,1 % v januári 2018 na 2,5 % v januári 2019.
čo ďalej
Stabilizácia našej platformy Vimbox je jedným z hlavných projektov spoločnosti na rok 2019. Pevne dúfame, že sa nám podarí udržať tempo a už nebudeme vidieť videokomunikáciu v najvyšších sťažnostiach. Chápeme, že značná časť týchto sťažností súvisí s oneskorením v počítačoch používateľov a na internete, ale túto časť musíme určiť a zvyšok vyriešiť. Všetko ostatné je technický problém, zdá sa, že by sme si s ním mali vedieť poradiť.
Hlavným problémom je, že nevieme, na akú úroveň je skutočne možné zlepšiť kvalitu. Zistenie tohto stropu je hlavnou úlohou. Preto boli naplánované dva experimenty:
- porovnajte video cez Janus s bežným p2p v bojových podmienkach. Tento experiment už bol uskutočnený, nezistil sa žiadny štatisticky významný rozdiel medzi naším roztokom a p2p;
- Dodajme (drahé) služby od firiem, ktoré zarábajú výhradne na videokomunikačných riešeniach a porovnajme množstvo negativity z nich s existujúcou.
Tieto dva experimenty nám umožnia identifikovať dosiahnuteľný cieľ a zamerať sa naň.
Okrem toho existuje množstvo úloh, ktoré možno rutinne vyriešiť:
- Namiesto subjektívnych recenzií vytvárame technickú metriku kvality komunikácie;
- Vytvárame podrobnejšie protokoly relácií, aby sme presnejšie analyzovali zlyhania, ktoré sa vyskytli, aby sme pochopili, kedy a kde presne k nim došlo a aké zdanlivo nesúvisiace udalosti sa v danom momente odohrali;
- Pred lekciou pripravujeme automatický test kvality pripojenia a dávame klientovi aj možnosť manuálne otestovať pripojenie, aby sa znížilo množstvo negativity spôsobenej jeho hardvérom a kanálom;
- vyvinieme a vykonáme viac testov záťaže videokomunikácie v zlých podmienkach, s premenlivou stratou paketov atď.;
- meníme správanie serverov v prípade problémov, aby sme zvýšili odolnosť voči chybám;
- Používateľa upozorníme, ak s jeho pripojením vôbec nie je niečo v poriadku, ako to robí Skype, aby pochopil, že problém je na jeho strane.
Smer videokomunikácie sa od apríla stal v rámci Skyengu plnohodnotným samostatným projektom, zaoberajúcim sa vlastným produktom, nielen súčasťou Vimboxu. To znamená, že začíname hľadať ľudí na . No ako vždy .
A, samozrejme, naďalej aktívne komunikujeme s ľuďmi a spoločnosťami pracujúcimi s videokomunikáciou. Ak si s nami chcete vymeniť skúsenosti, budeme radi! Komentujte, kontaktujte - každému odpovieme.
Zdroj: hab.com