Video poziv je glavni način komunikacije između nastavnika i studenta na platformi Vimbox. Oduvijek smo se odrekli Skypea, isprobali smo nekoliko rješenja trećih strana i na kraju se odlučili za kombinaciju WebRTC - Janus-gateway. Neko vrijeme smo bili zadovoljni, ali su se ipak pojavljivali neki negativni aspekti. Na kraju je stvorena posebna jedinica za video.
Zamolio sam Kirila Rogovog, voditelja nove jedinice, da govori o evoluciji video poziva u Skyengu, otkrivenim problemima, rješenjima i improvizacijama koje smo na kraju primijenili. Nadamo se da će članak biti koristan za kompanije koje također ostvaruju video putem web aplikacije.
Malo povijesti
Ljeta 2017. godine, vođa razvoja Skyenga, Sergey Safonov, nastupio je na Backend Conf govoreći o tome kako smo "odrecimo se Skypea i implementirali WebRTC". Oni koji žele, mogu pogledati snimku njegovog nastupa na (~45 min), a ovdje ću ukratko iznijeti suštinu.
Za školu Skyeng video poziv je oduvijek bio prioritetni način komunikacije između nastavnika i učenika. U početku smo koristili "Skype", ali to je bilo potpuno neprihvatljivo iz više razloga, prvenstveno zbog nedostatka zapisnika i nemogućnosti neposredne integracije u web aplikaciju. Stoga smo provodili razne eksperimente.
Zapravo, naši zahtjevi za video poziv bili su otprilike ovakvi:
— stabilnost;
— niska cijena po satu;
— snimanje sati;
— praćenje koliko tko govori (važno nam je da učenici govore više od nastavnika tijekom sati);
— linearno skaliranje;
— mogućnost korištenja i UDP i TCP.
Prvi put smo 2013. godine probali implementirati Tokbox. Sve je bilo dobro, ali je cijena bila vrlo visoka - 113 rubalja po satu - i smanjila je profit.
Zatim smo 2015. godine integrirali Voximplant. Ovdje je bila potrebna funkcija praćenja koliko tko govori, a rješenje je bilo znatno jeftinije: uz uvjet snimanja samo zvuka, trošilo se 20 rubalja po satu. Međutim, radilo je samo putem UDP-a, a nije umjelo prebaciti se na TCP. Ipak, na kraju je oko 40% učenika koristilo.
Nakon godine dana počeli su nam se javljati korporativni klijenti s vlastitim specifičnim zahtjevima. Na primjer, sve mora raditi putem preglednika, u tvrtki su otvoreni samo http i https; tj. nema „Skajpova“ i UDP-a. Korporativni klijenti = novac, pa smo se vratili na Tokbox, ali problem cijene nije nestao.
Rješenje — WebRTC i Janus
Donijeli smo odluku da koristimo . Ona je odgovorna za uspostavljanje veze, kodiranje i dekodiranje tokova, sinkronizaciju staza i kontrolu kvalitete uz obradu mrežnih problema. S naše strane moramo osigurati očitavanje tokova s kamere i mikrofona, crtanje videa, upravljanje vezom, uspostavljanje WebRTC veze i prijenos tokova prema njoj, kao i prijenos signalnih poruka između klijenata za uspostavu veze (sam WebRTC opisuje samo format podataka, ali ne i mehanizme njihove prijenosa). U slučaju da se klijenti nalaze iza NAT-a, WebRTC povezuje STUN poslužitelje, a ako to ne pomogne, TURN poslužitelje.
Obično p2p povezivanje nam nije dovoljno, jer želimo snimati lekcije za daljnju analizu u slučaju pritužbi. Stoga šaljemo WebRTC tokove putem prebacivača . Kao rezultat, klijenti ne znaju adrese jedni drugih, vide samo adresu Janus poslužitelja; on također obavlja funkciju signalnog poslužitelja. Janus ima mnoge potrebne značajke: automatski prelazi na TCP ako je kod klijenta blokiran UDP; može snimati tokove i UDP-a i TCP-a; skalira se; čak ima ugrađeni plugin za echo testove. U slučaju potrebe automatski se povezuju STUN i TURN poslužitelji od Twilio.
Ljeto 2017. godine imali smo dva Janus poslužitelja plus dodatni poslužitelj za obradu snimljenih sirovih audio i video datoteka, kako ne bismo opterećivali procesore glavnih. Pri povezivanju, Janus poslužitelji su birani prema principu par-nepar (broj veze). U tom trenutku to je bilo dovoljno, prema našim osjećajima davalo je otprilike četverostruki oslonac, stopa implementacije bila je oko 80. U isto vrijeme cijena je snižena na ~2 rubalja po lekciji, plus razvoj i podrška.
Povratak na temu videoveze
Stalno pratimo povratne informacije učenika i nastavnika kako bismo pravovremeno prepoznali i uklonili probleme. Do ljeta 2018. godine kvalitet veze je postao najčešća žalba. S jedne strane, to je značilo da smo uspešno rešili druge nedostatke. S druge strane, trebalo je hitno nešto uraditi: prekid časa može nas koštati, ponekad zajedno s troškom kupovine sledećeg paketa, a prekid uvodnog časa može nas potpuno odvojiti od potencijalnog klijenta.
U to vreme, videoveza je i dalje bila u MVP fazi. Drugim rečima, pokrenuli smo, to je radilo, jednom smo skalirali, shvatili kako to raditi – a to je to. Ako funkcioniše, ne popravljaj to. Niko nije aktivno radio na pitanju kvaliteta veze. Do avgusta je postalo jasno da tako ne može da ide dalje, i pokrenuli smo poseban odjeljak kako bismo shvatili šta nije u redu s WebRTC-om i Janusom.
Na ulazu je ovaj odjeljak imao: MVP rešenje, nema metrika, nema ciljeva, nema procesa poboljšanja, pri čemu se 7% učitelja žali na kvalitet veze (podataka o učenicima takođe nije bilo).
Novi odjeljak kreće s radom
Tim izgleda otprilike ovako:
- Vođa odjeljka, koji je ujedno i glavni programer.
- QA pomaže u testiranju promena, traži nove načine stvaranja nestabilnih uslova za vezu, izveštava o problemima s terena.
- Analitičar neprekidno traži razne korelacije u tehničkim podacima, poboljšava analizu povratnih informacija korisnika, proverava rezultate eksperimenta.
- Produkt menadžer pomaže sa opštim smerom i raspodelom resursa za eksperimente.
- Drugi programer često pomaže sa samim programiranjem i srodnim zadacima.
Na početku smo postavili relativno pouzdanu metriku koja je pratila promene u oceni kvaliteta veze (prosečna ocena po danima, nedeljama, mesecima). U to vreme su to bile ocene od učitelja, a kasnije su im dodate i ocene od studenata. Zatim smo počeli da postavljamo hipoteze o tome šta ne funkcioniše, ispravljali i posmatrali promene u dinamici. Išli smo za lakim plodovima: na primer, zamenili smo vp8 kodek s vp9, a pokazatelji su se poboljšali. Pokušali smo da se igramo s podešavanjima Janusa, sproveli razne eksperimente – koji su većinom doveli do ničega.
U drugoj fazi pojavila se hipoteza: WebRTC je rešenje peer-to-peer, a mi koristimo posrednički server. Možda se problem krije ovde? Počeli smo istraživati i ovde pronašli za sada najznačajnije poboljšanje.
U tom trenutku server iz grupe birao se prilično glupim algoritmom: svaki je imao svoj 'težinu', zavisnu od veze i snage, i nastojali smo poslati korisnika na onaj s većom 'težinom', ne obazirući se na to gde se geografski nalazi korisnik. Kao rezultat, učitelj iz Peterburga mogao je da komunicira sa učenikom iz Sibira preko Moskve, a ne preko našeg Janus servera u Sankt Peterburgu.
Algoritam smo prepravili: sada, kada korisnik otvori našu platformu, putem Ajax-a prikupljamo pingove od njega do svih servera. Kada uspostavljamo vezu, biramo par pingova (učitelj-server i učenik-server) s najmanjom sumom. Manji ping – manja mrežna udaljenost do servera; manja udaljenost — manja verovatnost gubitka paketa; gubitak paketa — najveći negativni faktor u video vezi. Udeo negativnog iskustva tokom tri meseca pao je na polovinu (za pravednost, u to vreme su se sprovodili i drugi eksperimenti, ali ovaj je gotovo sigurno imao najveći uticaj).
Nedavno smo otkrili još jednu ne očiglednu, ali očigledno važnu stvar: umjesto jednog moćnog Janus servera na širokom kanalu, bolje je imati dva jednostavnija s manjom propusnošću. Ovo je otkriveno nakon što smo kupili moćne mašine u nadi da ćemo u njih smjestiti što više soba (seansa veze) odjednom. Serveri imaju limit propusnosti, koji možemo točno pretvoriti u broj soba - znamo koliko se može otvoriti, na primjer, na 300 mbit/s. Čim na serveru bude otvoreno previše soba - prestajemo ga birati za nove sesije dok se opterećenje ne smanji. Ideja je bila da, kupnjom moćne mašine, maksimalno opteretimo kanal kako bismo na kraju došli do ograničenja procesora i memorije, a ne do propusnosti. No, ispostavilo se da nakon određenog broja otvorenih soba (420), unatoč tome što je opterećenje procesora, memorije i diska još uvijek daleko od limita, počinju dolaziti negativne povratne informacije u tehničku podršku. Očigledno, nešto postaje lošije unutar Janusa, možda postoje neka ograničenja. Počeli smo eksperimentirati, smanjili smo limit propusnosti s 300 na 200 mbit/s, problemi su nestali. Sada smo kupili tri nova servera s niskim limitima i karakteristikama, mislimo da će to dovesti do stabilnog poboljšanja kvalitete veze. Naravno, nismo se trudili otkriti o čemu se radi, improvizacija je naš zaštitni znak. U svoju obranu možemo reći da je tada bilo potrebno što brže riješiti hitan problem, a ne to učiniti lijepo; osim toga, Janus za nas je crna kutija napisana na C, kopanje po njemu je jako skupo.
Pa, usput smo:
- ažurirali sve ovisnosti koje je bilo moguće ažurirati, kako na serveru, tako i na klijentu (to su također bili eksperimenti, pratili smo rezultate);
- popravili sve uočene greške koje su se ticale konkretnog slučaja, na primjer, kada je veza padala i nije se automatski obnavljala;
- proveli brojne sastanke s tvrtkama koje rade u području video veze i upoznate su s našim problemima: streamanje igara, organizacija webinara; isprobali smo sve što nam se činilo korisnim;
- proveli tehnički pregled hardvera i kvalitete veze učitelja od kojih je dolazilo najviše pritužbi.
Eksperimenti koje smo proveli i naknadne promjene omogućile su smanjenje nezadovoljstva korisničkom vezom među predavačima s 7,1% u siječnju 2018. na 2,5% u siječnju 2019.
Što dalje
Stabilizacija naše platforme Vimbox jedan je od glavnih projekata tvrtke za 2019. godinu. Imamo velika očekivanja da ćemo zadržati dinamiku i više ne vidjeti videovezu na vrhu pritužbi. Razumijemo da značajan dio tih pritužbi proizlazi iz kašnjenja na računalima i internetu korisnika, ali moramo odrediti taj dio i riješiti sve ostalo. Sve ostalo predstavlja tehnički problem s kojim se, čini se, moramo znati nositi.
Glavna poteškoća je što ne znamo do koje razine je stvarno moguće poboljšati kvalitetu. Utvrđivanje tog plafona je glavni zadatak. Zbog toga su planirana dva eksperimenta:
- usporediti video putem Janusa s običnim p2p u stvarnim uvjetima. Ovaj eksperiment je već proveden, a nije pronađena nijedna statistički značajna razlika između našeg rješenja i p2p;
- instalirati (skupe) servise od kompanija koje zarađuju isključivo na rješenjima u području videoveze i usporediti količinu negativnih komentara koju generiraju s postojećim;
Ova dva eksperimenta omogućit će nam da odredimo dostižni cilj i fokusiramo se na njega.
Osim toga, postoji niz zadataka koji se rješavaju u radnom procesu:
- stvaramo tehničku metričku kvalifikaciju veze umjesto subjektivnih povratnih informacija;
- izradit ćemo detaljnije zapise o sesijama kako bismo točnije analizirali incidentne kvarove, razumjeli kada i gdje su se točno dogodili, te koje naizgled nepovezane situacije su se odvijale u tom trenutku;
- pripremamo automatski test kvalitete veze prije lekcije, kao i omogućiti klijentu ručno testiranje veze kako bismo smanjili broj negativnih komentara uzrokovanih njegovim hardverom i vezom;
- razvijat ćemo i provoditi više opterećenja testova videoveze u lošim uvjetima, s promjenjivim gubitkom paketa itd.;
- promijenit ćemo ponašanje poslužitelja u slučaju problema kako bismo povećali otpornost sustava;
- obavijestit ćemo korisnika ako ima problema s vezom, kao što to radi Skype, kako bi shvatio da je problem na njegovoj strani.
Od travnja, područje video poziva postaje samostalni projekt unutar Skyenga, koji se bavi vlastitim proizvodom, a ne samo dijelom Vimboxa. To znači da počinjemo tražiti ljude za . Kao i uvijek, .
I, naravno, nastavljamo aktivno komunicirati s ljudima i tvrtkama koje se bave video pozivima. Ako želite podijeliti s nama iskustvo — bit ćemo sretni! Komentirajte, kontaktirajte — odgovoriti ćemo svima.
Izvor: habr.com
