Vaizdo komunikacija yra pagrindinis mokytojo ir mokinio bendravimo būdas Vimbox platformoje. Jau seniai atsisakėme Skype, išbandėme keletą trečiųjų šalių sprendimų ir galiausiai apsistojome ties WebRTC – Janus-gateway deriniu. Kurį laiką buvome viskuo patenkinti, bet vis tiek išryškėjo kai kurie neigiami aspektai. Dėl to buvo sukurta atskira vaizdo kryptis.
Paprašiau naujosios krypties vadovo Kirilo Rogovoy papasakoti apie vaizdo komunikacijos raidą Skyeng, atrastas problemas, sprendimus ir ramentus, kuriuos galiausiai panaudojome. Tikimės, kad straipsnis bus naudingas įmonėms, kurios taip pat pačios kuria vaizdo įrašus naudodami žiniatinklio programą.
Truputis istorijos
2017 m. vasarą „Skyeng“ plėtros vadovas Sergejus Safonovas „Backend Conf“ kalbėjo apie tai, kaip „atsisakėme Skype ir įdiegėme WebRTC“. Susidomėję gali pasižiūrėti kalbos įrašą adresu (~45 min.), o čia trumpai išdėstysiu jo esmę.
Skyeng mokyklai vaizdo komunikacija visada buvo prioritetinis mokytojo ir mokinio bendravimo būdas. Iš pradžių buvo naudojama „Skype“, tačiau ji kategoriškai nebuvo patenkinama dėl daugelio priežasčių, visų pirma dėl žurnalų trūkumo ir dėl to, kad neįmanoma tiesiogiai integruoti į žiniatinklio programą. Todėl atlikome visokius eksperimentus.
Tiesą sakant, mūsų reikalavimai vaizdo komunikacijai buvo maždaug tokie:
- stabilumas;
- maža pamokos kaina;
— pamokų įrašymas;
— sekti, kas kiek kalba (mums svarbu, kad mokiniai per pamokas kalbėtų daugiau nei mokytojas);
— tiesinis mastelio keitimas;
- galimybė naudoti tiek UDP, tiek TCP.
Pirmasis pabandė įdiegti Tokbox 2013 m. Viskas buvo gerai, bet pasirodė labai brangu – 113 rublių už pamoką – ir suvalgė pelną.
Tada 2015 m. Voximplant buvo integruotas. Čia buvo funkcija, kurią mums reikėjo sekti, kas kiek kalbėjo, o tuo pačiu sprendimas buvo daug pigesnis: jei buvo įrašomas tik garsas, tai kainavo 20 rublių už pamoką. Tačiau jis veikė tik per UDP ir negalėjo pereiti prie TCP. Tačiau apie 40 % studentų ja pasinaudojo.
Po metų pradėjome turėti verslo klientų su savo specifiniais reikalavimais. Pavyzdžiui, viskas turėtų veikti per naršyklę, įmonė atidaro tik http ir https; ty nėra Skype ar UDP. Įmonės klientai = pinigai, todėl jie grįžo į Tokbox, bet kainos problema neišnyko.
Sprendimas – WebRTC ir Janus
Nuspręsta naudoti . Ji yra atsakinga už ryšio užmezgimą, srautų kodavimą ir dekodavimą, takelių sinchronizavimą ir kokybės kontrolę su tinklo trikdžių tvarkymu. Savo ruožtu turime užtikrinti srautų skaitymą iš kameros ir mikrofono, vaizdo braižymą, ryšio valdymą, WebRTC ryšio užmezgimą ir srautų į jį perdavimą, taip pat signalinių pranešimų perdavimą tarp klientų ryšiui užmegzti (pats WebRTC aprašo tik duomenų formatą, bet ne jo perdavimo mechanizmą). Jei klientai yra už NAT, WebRTC jungia STUN serverius; jei tai nepadeda, TURN serveriai.
Įprasto p2p ryšio mums neužtenka, nes norime įrašyti pamokas tolimesnei analizei esant nusiskundimams. Todėl WebRTC srautus siunčiame per relę . Dėl to klientai nežino vieni kitų adresų, mato tik Janus serverio adresą; ji atlieka ir signalų serverio funkcijas. Janus turi daug mums reikalingų funkcijų: automatiškai persijungia į TCP, jei klientas užblokavo UDP; gali įrašyti tiek UDP, tiek TCP srautus; keičiamas; Yra net įmontuotas aido testų papildinys. Jei reikia, STUN ir TURN serveriai iš Twilio automatiškai prijungiami.
2017 m. vasarą veikė du Janus serveriai ir papildomas serveris įrašytiems neapdorotiems garso ir vaizdo failams apdoroti, kad neužimtume pagrindinių procesorių. Prisijungiant Janus serveriai buvo pasirinkti nelyginiu principu (ryšio numeris). Tuo metu to pakako, pagal mūsų jausmus tai davė maždaug keturis kartus saugumo atsargą, įgyvendinimo procentas buvo apie 80. Tuo pačiu metu kaina buvo sumažinta iki ~ 2 rublių už pamoką, plius plėtra ir palaikymas.
Grįžtant prie vaizdo komunikacijos temos
Nuolat stebime mokinių ir dėstytojų atsiliepimus, siekdami laiku nustatyti ir ištaisyti problemas. 2018 m. vasarą skambučių kokybė buvo tvirtai pirmoje vietoje tarp skundų. Viena vertus, tai reiškė, kad sėkmingai įveikėme kitus trūkumus. Kita vertus, reikėjo kažką daryti skubiai: sutrikus pamokai rizikuojame prarasti jos vertę, kartais kartu su kito paketo įsigijimo išlaidomis, o sutrikus įvadinei pamokai rizikuojame netekti potencialaus kliento. iš viso.
Tuo metu mūsų vaizdo ryšys dar buvo MVP režimu. Paprasčiau tariant, jie jį paleido, jis veikė, vieną kartą padidino, suprato, kaip tai padaryti – na, puiku. Jei tai veikia, netaisykite. Niekas sąmoningai nesprendė komunikacijos kokybės klausimo. Rugpjūčio mėn. tapo aišku, kad tai negali tęstis, ir pradėjome atskirą kryptį, kad išsiaiškintume, kas negerai su WebRTC ir Janus.
Įvedimo metu ši kryptis gavo: MVP sprendimas, nėra metrikų, nėra tikslų, nėra tobulinimo procesų, tuo tarpu 7% mokytojų skundžiasi komunikacijos kokybe (duomenų apie studentus taip pat nebuvo).
Vyksta nauja kryptis
Komanda atrodo maždaug taip:
- Skyriaus vedėjas, kuris yra ir pagrindinis kūrėjas.
- QA padeda išbandyti pakeitimus, ieško naujų būdų, kaip sukurti nestabilias komunikacijos sąlygas, ir praneša apie problemas iš priekinės linijos.
- Analitikas nuolat ieško įvairių techninių duomenų koreliacijų, tobulina vartotojų atsiliepimų analizę, tikrina eksperimentų rezultatus.
- Produkto vadovas padeda bendrai nukreipti ir paskirstyti išteklius eksperimentams.
- Antrasis kūrėjas dažnai padeda programuoti ir atlikti susijusias užduotis.
Pirmiausia sukūrėme gana patikimą metriką, kuri stebėjo komunikacijos kokybės vertinimų pokyčius (dienų, savaičių, mėnesių vidurkį). Tuo metu tai buvo mokytojų pažymiai, vėliau prie jų buvo pridedami mokinių pažymiai. Tada jie pradėjo kelti hipotezes apie tai, kas veikė ne taip, tai taisė ir žvelgė į dinamikos pokyčius. Mes pasirinkome žemai kabančius vaisius: pavyzdžiui, vp8 kodeką pakeitėme vp9, našumas pagerėjo. Bandėme žaisti su Janus nustatymais ir atlikti kitus eksperimentus – daugeliu atvejų jie nieko neleisdavo.
Antrajame etape atsirado hipotezė: WebRTC yra lygiavertis sprendimas, o viduryje naudojame serverį. Galbūt problema slypi čia? Pradėjome kasti ir radome iki šiol reikšmingiausią patobulinimą.
Tuo metu serveris iš baseino buvo pasirinktas naudojant gana kvailą algoritmą: kiekvienas turėjo savo „svorį“, priklausomai nuo kanalo ir galios, o mes bandėme siųsti vartotoją į tą, kurio „svoris“ didžiausias, be atkreipiant dėmesį į vartotojo geografinę vietą . Dėl to dėstytojas iš Sankt Peterburgo su studentu iš Sibiro galėjo bendrauti per Maskvą, o ne per mūsų Janus serverį Sankt Peterburge.
Algoritmas buvo perdarytas: dabar, kai vartotojas atidaro mūsų platformą, mes renkame iš jo ping į visus serverius naudojant Ajax. Užmegzdami ryšį, pasirenkame mažiausią pingų porą (mokytojas-serveris ir mokinys-serveris). Mažiau ping reiškia mažesnį tinklo atstumą iki serverio; trumpesnis atstumas reiškia mažesnę tikimybę prarasti paketus; Paketų praradimas yra didžiausias neigiamas veiksnys vaizdo komunikacijoje. Per tris mėnesius negatyvumo dalis sumažėjo perpus (teisybės dėlei, tuo metu buvo atlikti ir kiti eksperimentai, bet šis beveik neabejotinai turėjo didžiausią įtaką).
Neseniai atradome dar vieną neakivaizdų, bet iš pažiūros svarbų dalyką: vietoj vieno galingo Janus serverio storame kanale geriau turėti du paprastesnius su plonesniu pralaidumu. Tai paaiškėjo po to, kai nusipirkome galingas mašinas, tikėdamiesi vienu metu į jas sugrūsti kuo daugiau patalpų (bendravimo seansų). Serveriai turi pralaidumo limitą, kurį galime tiksliai išversti į kambarių skaičių – žinome, kiek jų galima atidaryti, pavyzdžiui, esant 300 Mbit/s. Kai tik serveryje yra atidaryta per daug kambarių, mes nustojame jį rinktis naujai veiklai, kol apkrova nesumažės. Idėja buvo tokia, kad nusipirkę galingą mašiną maksimaliai įkelsime kanalą į jį, kad galiausiai jį apribotų procesorius ir atmintis, o ne pralaidumas. Tačiau paaiškėjo, kad po tam tikro skaičiaus atvirų patalpų (420), nepaisant to, kad procesoriaus, atminties ir disko apkrova vis dar yra labai toli nuo ribų, neigiamas požiūris į techninį palaikymą. Matyt, Janus viduje kažkas blogėja, galbūt ir ten yra kažkokie apribojimai. Pradėjome eksperimentuoti, sumažinome pralaidumo ribą nuo 300 iki 200 Mbit/s ir problemos išnyko. Dabar įsigijome tris naujus serverius iš karto su žemais limitais ir charakteristikomis, manome, kad tai leis stabiliai pagerinti ryšio kokybę. Žinoma, mes nebandėme suprasti, kas ten vyksta, mūsų ramentai yra viskas. Mūsų gynyboje, tarkime, kad tuo momentu reikėjo kuo greičiau išspręsti aktualią problemą, o ne tai padaryti gražiai; be to, Janus mums yra juoda dėžė, parašyta C, su ja labai brangu krapštytis.
Na, o proceso metu mes:
- atnaujintos visos priklausomybės, kurias buvo galima atnaujinti, tiek serveryje, tiek kliente (tai irgi buvo eksperimentai, stebėjome rezultatus);
- ištaisė visas nustatytas klaidas, susijusias su konkrečiais atvejais, pavyzdžiui, kai ryšys nutrūko ir nebuvo automatiškai atkurtas;
- Surengėme daug susitikimų su įmonėmis, dirbančiomis vaizdo komunikacijų srityje ir susipažinusiomis su mūsų problemomis: žaidimų transliacija, internetinių seminarų organizavimas; išbandėme viską, kas mums atrodė naudinga;
- Atliko dėstytojų, iš kurių buvo daugiausia nusiskundimų, techninės įrangos ir komunikacijos kokybės techninę peržiūrą.
Eksperimentai ir vėlesni pakeitimai leido sumažinti mokytojų nepasitenkinimą bendravimu nuo 7,1 % 2018 m. sausį iki 2,5 % 2019 m. sausį.
Kas toliau?
Mūsų Vimbox platformos stabilizavimas yra vienas pagrindinių bendrovės projektų 2019 m. Labai tikimės, kad pavyks išlaikyti pagreitį ir nebematyti vaizdo komunikacijos didžiausiuose skunduose. Suprantame, kad nemaža dalis šių skundų yra susiję su vartotojų kompiuterių ir interneto vėlavimais, tačiau šią dalį turime nustatyti, o likusią – išspręsti. Visa kita – techninė problema, atrodo, kad turėtume su ja susitvarkyti.
Pagrindinis sunkumas yra tas, kad mes nežinome, iki kokio lygio iš tikrųjų įmanoma pagerinti kokybę. Išsiaiškinti šias lubas yra pagrindinė užduotis. Todėl buvo suplanuoti du eksperimentai:
- palyginkite vaizdo įrašą per Janus su įprastu p2p kovos sąlygomis. Šis eksperimentas jau buvo atliktas, statistiškai reikšmingo skirtumo tarp mūsų sprendimo ir p2p nerasta;
- Teiksime (brangias) paslaugas iš įmonių, kurios uždirba tik vaizdo komunikacijos sprendimus, ir palyginkime jų negatyvo kiekį su esamu.
Šie du eksperimentai leis mums nustatyti pasiekiamą tikslą ir sutelkti dėmesį į jį.
Be to, yra keletas užduočių, kurias galima išspręsti įprastai:
- Kuriame techninę komunikacijos kokybės metriką, o ne subjektyvias apžvalgas;
- Darome detalesnius seansų žurnalus, siekdami tiksliau išanalizuoti įvykusius gedimus, suprasti, kada ir kur tiksliai jos įvyko, kokie iš pažiūros nesusiję įvykiai vyko tuo momentu;
- Prieš pamoką paruošiame automatinį ryšio kokybės testą, taip pat suteikiame galimybę klientui rankiniu būdu patikrinti ryšį, kad sumažintume jo aparatinės įrangos ir kanalo sukeliamą negatyvo kiekį;
- kursime ir atliksime daugiau vaizdo ryšio apkrovos testų prastomis sąlygomis, su kintamu paketų praradimu ir pan.;
- keičiame serverių elgesį iškilus problemoms, kad padidintume atsparumą gedimams;
- Įspėsime vartotoją, jei jo ryšyje išvis kažkas negerai, kaip tai daro „Skype“, kad jis suprastų, jog problema yra jo pusėje.
Nuo balandžio mėnesio vaizdo komunikacijos kryptis tapo visaverčiu atskiru „Skyeng“ projektu, susijusiu su savo produktu, o ne tik „Vimbox“ dalimi. Tai reiškia, kad pradedame ieškoti žmonių . Na kaip visada .
Ir, žinoma, toliau aktyviai bendraujame su žmonėmis ir įmonėmis, dirbančiomis su vaizdo komunikacija. Jei norite pasikeisti patirtimi su mumis, mes džiaugsimės! Komentuokite, susisiekite – visiems atsakysime.
Šaltinis: www.habr.com