Videokonverents on peamine suhtlemisviis õpetaja ja õpilase vahel Vimboxi platvormil. Oleme ammu loobunud Skype'ist, proovinud mitmeid kolmanda osapoole lahendusi ning lõpuks otsustanud kasutada WebRTC – Janus-gateway kombinatsiooni. Mõnda aega sobis see meile hästi, kuid siiski kerkis esile mõned probleemid. Lõpuks loodi videoteemade jaoks eraldi suund.
Palusin Kirill Rogovile, uue suuna juhile, rääkida videokonverentsi arengust Skyengis, avastatud probleemidest, lahendustest ja nendest nippidest, mida lõpuks kasutasime. Loodame, et artikkel on kasulik ka teistele ettevõtetele, kes tõstavad video läbi veebirakenduse.
Veidi ajalugu
Suvel 2017 astus Skyengi arenduse juht Sergei Safonov Backend Confis üles ettekandega, milles rääkis sellest, kuidas me «loobusime Skype'ist ja rakendasime WebRTC». Soovijad saavad tema ettekande salvestust vaadata (~45 min), aga siin ma lühidalt esitan selle sisu.
Skyengi koolis on videokõne alati olnud õpetaja ja õpilase vaheline suhtlemise prioriteet. Alguses kasutasime "Skype'i", kuid see ei sobinud mitmel põhjusel, eelkõige logide puudumise ja otsese integreerimise võimaluse tõttu veebirakendusse. Seetõttu tegime erinevaid katsetusi.
Meie videokõne nõudmised olid umbes järgmised:
— stabiilsus;
— madal hind tunni eest;
— tundide salvestamine;
— jälgimine, kui palju igaüks räägib (meie jaoks on oluline, et õpilased räägiksid tundides rohkem kui õpetaja);
— lineaarselt skaaleeritav;
— võimalus kasutada nii UDP-d kui TCP-d.
Esimese asjana proovisime 2013. aastal rakendada Tokboxi. Kõik oli hästi, kuid see osutus väga kalliks – 113 rubla tunni kohta – ja võttis kasumist ära.
Siis 2015. aastal integreerisime Voximplanti. Siin oli vajalik jälgimisfunktsioon, et teada, kui palju igaüks räägib, ja lahendus oli oluliselt odavam: ainult helisalvestuse korral maksis see 20 rubla tunni eest. Siiski töötas see ainult UDP kaudu, TCP-le switchimist ei osanud. Sellegipoolest kasutas seda lõpuks umbes 40% õpilastest.
Aasta pärast hakkasid meie juurde tulema ettevõtteklientidega, kellel olid oma spetsiifilised nõudmised. Näiteks peab kõik toimima läbi brauseri, ettevõttes on avatud vaid http ja https; st. ei mingit 'Skype'i' ja UDP-d. Ettevõtteklient = raha, seetõttu pöördusime tagasi Tokboxi juurde, kuid hinna probleem püsis.
Lahendus — WebRTC ja Janus
Otsustasime kasutada . See vastutab ühenduse loomise, voogude kodeerimise ja dekodeerimise, rajate sünkroniseerimise ning kvaliteedi kontrollimise ja võrgu tõrgete käsitlemise eest. Omalt poolt peame tagama voogude lugemise kaamerast ja mikrofonist, video joonistamise, ühenduse haldamise, WebRTC ühenduse loomise ja voogude edastamise, samuti signaalisõnumite vahetamise klientide vahel ühenduse loomiseks (WebRTC määratleb vaid andmeformaadi, kuid mitte edastamismehhanismi). Kui kliendid asuvad NAT-i taga, ühendab WebRTC STUN-serverid; kui see ei aita, siis TURN-serverid.
Tavaliselt piisab meile p2p-ühendusest, kuid soovime salvestada õppetunde edasiseks analüüsiks kaebuste korral. Seetõttu edastame WebRTC vooge edasiandja kaudu. . Tulemusena ei tea kliendid üksteise aadresse, nähes ainult Januse serveri aadressi; see täidab ka signaaliserveri funktsioone. Janusel on palju vajalikke funktsioone: see läheb automaatselt TCP-le, kui UDP on kliendi jaoks blokeeritud; oskab salvestada nii UDP kui ka TCP vooge; on skaleeritav; ja seal on isegi sisseehitatud plugin kaja testimiseks. Vajadusel ühendatakse automaatselt Twilio STUN ja TURN serverid.
2017. aasta suvel töötas meil kaks Januse serverit ning lisas server, et töötleda salvestatud toormaterjali helis ja videos, et mitte hõivata peamiste protsessorite ressursse. Ühendamisel valiti Januse serverid paaris-ühe kaupa (ühenduse number). Tol ajal piisab sellest meie arust, andes umbes neli korda suurema varu, rakendamise protsent oli umbes 80%. Samuti langes hind ~2 rubla õppetunni kohta, pluss arendamine ja tugi.
Tagasi videokõnede teema juurde
Me pide, et muretsime pidevalt õpilaste ja õpetajate tagasiside üle, et õigeaegselt tuvastada ja lahendada probleeme. Suveks 2018 oli hirenud probleemide seas esikohal kvaliteet. Ühelt poolt tähendas see, et olime teiste puudustega edukalt toime tulnud. Teiselt poolt tuli kiiresti midagi ette võtta: kui tund katkeb, riskime selle maksumuse kaotamisega, mõnikord koos järgmise paketi ostmise maksumusega, ja kui katkeb sissejuhatav tund – siis kaotame potentsiaalse kliendi.
Tol hetkel oli meie videokõne jätkuvalt MVP-režiimis. Lihtsalt öeldes, käivitasime, see töötas, skaleerisime korra, mõistsime, kuidas seda teha – no ja hästi. If it works, don’t fix it. Keegi ei tegelenud sihipäraselt kvaliteedi küsimusega. Augustiks sai selgeks, et nii edasi minna ei saa, ja alustasime eraldi suunaga, et aru saada, mis meie WebRTC ja Janusega ikkagi valesti on.
Selle suuna alguses oli: MVP lahendus, mõõdikud puuduvad, eesmärgid puuduvad, parendusprotsessid puuduvad, samas 7% õpetajatest kurdavad kvaliteedi üle (andmed õpilaste kohta puudusid samuti).
Uus suund on töös
Käsk näeb välja umbes nii:
- Suuna juhiks on peamine arendaja.
- QA aitab testida muudatusi, otsides uusi viise ebastabiilsete ühendustingimuste loomiseks ning teavitades eesliinil esinevatest probleemidest.
- Analüütik otsib pidevalt erinevaid korrelatsioone tehnilistes andmetes, parandab kasutajate tagasiside analüüsi ning kontrollib katsete tulemusi.
- Tootejuht aitab üldise suuna määramisel ning ressursside eraldamisel katsetamiseks.
- Koodi kirjutamise ja seotud ülesannetega aitab sageli teine arendaja.
Alguses seati üles usaldusväärne mõõdik, mis jälgis side kvaliteedi hindamisi (keskmised päevade, nädalate ja kuude kaupa). Sellel hetkel olid hindajad õpetajad, hiljem lisandusid ka hinnangud tudengitelt. Edasi hakati formuleerima hüpoteese selle kohta, mis ei toimi, parandama ja jälgima dünaamikas toimuvaid muudatusi. Alustati madala rippuvate viljade korjamisega: näiteks vahetati kodek vp8 kodeki vp9 vastu, tulemused paranesid. Katsetati Januse seadistustega, tehti teisi katseid – enamasti tulemusi andmata.
Teises etapis tekkis hüpotees: WebRTC on peer-to-peer lahendus, kuid kasutame serverit keskel. Kas probleem peitub siin? Alustasime uurimist ja leidsime siit praegu kõige olulisema täiustuse.
Sel hetkel valiti server krundi seest üsna primitiivse algoritmi kaudu: igal ühel oli oma 'kaal', mis sõltus kanalist ja jõudlustest, ning me püüdsime suunata kasutajad sinna, kus 'kaal' oli suurem, pööramata tähelepanu sellele, kus geograafiliselt kasutaja asub. Selle tulemusena võis õpetaja Peterburist suhelda õpilasega Siberist läbi Moskva, mitte meie Janus-serveri kaudu Peterburis.
Algritm on ümber tehtud: nüüd, kui kasutaja avab meie platvormi, kogume Ajax'i abil tema pingeid kõikide serveritega. Suhtlemise loomisel valime paari pinget (õpetaja-server ja õpilane-server), mille summa on väikseim. Vähem pinget – väiksem võrgu kaugus serverisse; lühem kaugus – madalam paketikaotuse tõenäosus; paketikaotused – suurim negatiivne tegur videosides. Negatiivsete osakaal kolme kuu jooksul vähenes kaks korda (aususe nimel toimusid sel ajal ka teised eksperimendid, kuid see mõjutas ilmselt kõige rohkem).
Hiljuti avastasime veel ühe, esmapilgul mitteilmse, kuid näiliselt olulise asja: ühe suure Janus-serveri asemel on parem kasutada kahte väiksemat, millel on madalam läbilaskevõime. See selgus pärast seda, kui ostsime just võimsad masinad, lootuses mahutada sinna võimalikult palju ruume (ühend seansse) korraga. Serveritel on läbilaskevõime piirang, mille saame täpselt tõlkida ruumide arvuks — me teame, mitu saame avada näiteks 300 Mbit/s. Kui serveris on avatud liiga palju ruume, lõpetame selle uute tegevuste valimise, kuni koormus väheneb. Idee oli see, et ostes võimsa masina, saame kanali maksimaalselt koormata, et lõpuks jõuda protsessori ja mälu piirini, mitte läbilaskevõime piirini. Kuid selgus, et pärast teatud arvu avatud ruumide (420) ilmuvad tehnilisse tugi negatiivsed tagasisided, kuigi protsessori, mälu ja ketta koormus on veel kaugel piiridest. Näib, et Janus sees on midagi halvem, võib-olla on seal ka mingid piirangud. Alustasime katsetamist, vähendasime läbilaskevõime piiri 300-lt 200 Mbit/s-le, probleemid kadusid. Nüüd ostsime kohe kolm uut serverit, millel on madalad piirangud ja omadused, lootes, et see toob kaasa kvaliteedi stabiilse paranemise. Loomulikult ei hakanud me aru saama, mis seal toimus, tugimehanismid — on meie kõik. Meie õigustuseks võib öelda, et tookord tuli kiiresti lahendada vägisi probleem, mitte teha seda ilusasti; pealegi on Janus meie jaoks must kast, kirjutatud C-s, tema kallale minek on väga kallis.
Protsessi käigus oleme:
- uuendanud kõiki sõltuvusi, mida oli võimalik uuendada nii serveris kui ka kliendis (need olid ka eksperimendid, jälgisime tulemusi);
- parandanud kõik tuvastatud vead, mis puudutasid konkreetseid juhtumeid, näiteks kui ühendus katkeb ja ei taastu automaatselt;
- teinud rohkelt kohtumisi ettevõtetega, kes töötavad videokõnede valdkonnas ja tunnevad meie probleeme: mängude voogedastamisega, veebiseminaride korraldamisega; proovisime kõike, mis tundus kasulik;
- viinud läbi tehnilise ülevaate seadmete ja ühenduse kvaliteedi kohta õpetajate hulgas, kellelt tuli kõige rohkem kaebusi.
Tehtud eksperimendid ja neile järgnenud muudatused vähendasid õpetajate rahulolematust ühenduse üle jaanuaris 2018 7,1%lt jaanuaris 2019 2,5%le.
Mis edasi
Vimboxi platvormi stabiliseerimine on 2019. aasta peamine projekt. Me loodame, et suudame säilitada dünaamika ja et videokõned ei paista enam kaebuste tipus. Mõistame, et märkimisväärne osa neist kaebustest on seotud kasutajate arvutite ja interneti viivitustega, kuid peame kindlaks määrama selle osa ja lahendama kõik ülejäänud. Kõik muu on tehniline probleem, millega peaksime olema võimelised toime tulema.
Peamine raskus seisneb selles, et me ei tea, kui palju kvaliteeti üldse parandada on võimalik. Selle ülemise piiri väljaselgitamine on meie peamine ülesanne. Seepärast on planeeritud kaks eksperimenti:
- kui võrrelda videot Januse kaudu tavalise p2p-ga lahingutingimustes. See eksperiment on juba läbi viidud ja meie lahenduse ning p2p vahel ei leitud statistiliselt olulisi erinevusi;
- oleme (kallid) teenused, mis on välja töötatud ettevõtete poolt, kes teenivad eranditult tulu videokõnede lahendustest, ja võrrelda nende negatiivsust meie olemasolevaga.
Need kaks eksperimenti võimaldavad meil kindlaks teha saavutatava eesmärgi ja keskenduda sellele.
Lisaks on rida ülesandeid, mis lahendatakse töökorras:
- loome tehnilise kvaliteedi mõõdiku asemel subjektiivsete arvamustega;
- teeme põhjalikumaid sessiooniloge, et täpsemalt analüüsida juhuslikke tõrkeid, mõista, millal ja kus need täpselt tekkisid, ning millised esmapilgul omavahel mitte seotud sündmused toimusid sel ajal;
- valmistame ette automaatse ühenduse kvaliteedi testi enne tundi ja anname kliendile võimaluse manuaalselt ühendust testida, et vähendada negatiivsete tagasiside hulka, mis võib tuleneda tema riistvarast ja kanallist;
- arendame ja viime läbi rohkem videoühenduse koormusteste halbadest tingimustest, muutuva pakettide kaotusega jne;
- muudame serverite käitumist probleemide korral usaldusväärsuse tõstmiseks;
- hoiame kasutajat kursis, kui tema ühendusega on midagi valesti, nagu seda teeb ka Skype, et ta mõistaks, et probleem on tema poolel.
Alates aprillist muutub videokõne suund täielikuks eraldi projektiks Skyengis, mis tegeleb oma tootega, mitte lihtsalt osa Vimboxist. See tähendab, et hakkame otsima inimesi . Noh ja nagu alati .
Ja, me jätkame aktiivset suhtlemist inimestega ja ettevõtetega, kes tegutsevad videokõnede valdkonnas. Kui soovite meiega kogemusi jagada, siis oleme rõõmsad! Kommenteerige, võtke ühendust — vastame kõigile.
Allikas: habr.com
