Video komunikacija je glavni način komunikacije između nastavnika i učenika na Vimbox platformi. Davno smo odustali od Skypea, isprobali nekoliko tuđih rješenja i na kraju se odlučili na kombinaciju WebRTC - Janus-gateway. Neko smo vrijeme bili zadovoljni svime, ali ipak su se neki negativni aspekti i dalje pojavljivali. Kao rezultat toga, stvoren je zaseban video smjer.
Zamolio sam Kirilla Rogovoya, voditelja novog smjera, da govori o evoluciji video komunikacije u Skyeng-u, otkrivenim problemima, rješenjima i štakama koje smo u konačnici koristili. Nadamo se da će članak biti koristan tvrtkama koje i same izrađuju video putem web aplikacije.
Malo povijesti
U ljeto 2017., voditelj Skyeng razvoja, Sergey Safonov, govorio je na Backend Confu s pričom o tome kako smo “napustili Skype i implementirali WebRTC”. Zainteresirani mogu pogledati snimku govora na (~45 min), a ovdje ću ukratko iznijeti njegovu bit.
Za školu Skyeng video komunikacija je oduvijek bila prioritetan način komunikacije učitelja i učenika. U početku je korišten Skype, ali kategorički nije zadovoljavao iz niza razloga, prvenstveno zbog nedostatka logova i nemogućnosti integracije izravno u web aplikaciju. Stoga smo proveli razne vrste eksperimenata.
Zapravo, naši zahtjevi za video komunikaciju bili su otprilike sljedeći:
— stabilnost;
— niska cijena po satu;
— snimanje lekcija;
— praćenje tko koliko govori (važno nam je da učenici govore više od nastavnika tijekom nastave);
— linearno skaliranje;
- sposobnost korištenja i UDP i TCP.
Prvi koji je pokušao implementirati Tokbox 2013. godine. Sve je bilo dobro, ali se pokazalo vrlo skupim - 113 rubalja po lekciji - i pojelo je zaradu.
Zatim je 2015. integriran Voximplant. Ovdje je bila funkcija koja nam je trebala da pratimo tko koliko govori, a u isto vrijeme rješenje je bilo mnogo jeftinije: ako se snima samo audio, to košta 20 rubalja po lekciji. Međutim, radio je samo putem UDP-a i nije se mogao prebaciti na TCP. Međutim, oko 40% učenika ga je na kraju koristilo.
Godinu dana kasnije, počeli smo imati korporativne klijente sa svojim specifičnim zahtjevima. Na primjer, sve bi trebalo raditi preko preglednika, tvrtka otvara samo http i https; tj. bez Skypea ili UDP-a. Korporativni klijenti = novac, pa su se vratili na Tokbox, ali problem cijene nije nestao.
Rješenje - WebRTC i Janus
Odlučio koristiti . Odgovoran je za uspostavljanje veze, kodiranje i dekodiranje tokova, sinkronizaciju zapisa i kontrolu kvalitete uz rukovanje mrežnim greškama. S naše strane, moramo osigurati čitanje streamova s kamere i mikrofona, crtanje videa, upravljanje vezom, uspostavljanje WebRTC veze i prijenos streamova na nju, kao i prijenos signalnih poruka između klijenata za uspostavljanje veze (sam WebRTC opisuje samo format podataka, ali ne i njegov mehanizam prijenosa). Ako su klijenti iza NAT-a, WebRTC povezuje STUN poslužitelje; ako to ne pomogne, TURN poslužitelje.
Obična p2p veza nam nije dovoljna, jer želimo snimati lekcije za daljnju analizu u slučaju reklamacija. Stoga šaljemo WebRTC streamove putem releja . Kao rezultat toga, klijenti ne znaju adrese drugih, vide samo adresu Janus poslužitelja; također obavlja funkcije poslužitelja signala. Janus ima mnogo značajki koje su nam potrebne: automatski se prebacuje na TCP ako klijent ima blokiran UDP; može snimati i UDP i TCP tokove; skalabilan; Postoji čak i ugrađeni dodatak za eho testove. Ako je potrebno, automatski se povezuju STUN i TURN poslužitelji iz Twilia.
U ljeto 2017. radila su nam dva Janus servera, plus dodatni server za obradu snimljenih raw audio i video datoteka, kako ne bismo zauzeli procesore glavnih. Prilikom povezivanja Janus poslužitelji su odabrani na par-nepar (broj veze). U to je vrijeme to bilo dovoljno, prema našim osjećajima, davalo je otprilike četverostruku sigurnosnu marginu, postotak implementacije bio je oko 80. U isto vrijeme, cijena je smanjena na ~2 rublje po lekciji, plus razvoj i podrška.
Da se vratimo na temu video komunikacije
Konstantno pratimo povratne informacije učenika i nastavnika kako bismo na vrijeme prepoznali i ispravili probleme. Do ljeta 2018. kvaliteta poziva bila je čvrsto na prvom mjestu među pritužbama. S jedne strane to je značilo da smo se uspješno nosili s ostalim nedostacima. S druge strane, bilo je potrebno hitno nešto poduzeti: ako se lekcija poremeti, riskiramo gubitak vrijednosti, ponekad i trošak kupnje sljedećeg paketa, a ako se poremeti uvodna lekcija, riskiramo gubitak potencijalnog klijenta. ukupno.
Tada je naša video komunikacija još bila u MVP modu. Jednostavno rečeno, pokrenuli su ga, radilo je, skalirali su ga jednom, razumjeli su kako se to radi - pa, super. Ako radi, nemojte ga popravljati. Nitko se nije namjerno pozabavio pitanjem kvalitete komunikacije. U kolovozu je postalo jasno da se to ne može nastaviti, pa smo pokrenuli zaseban smjer kako bismo otkrili što nije u redu s WebRTC-om i Janusom.
Na ulazu je ovaj smjer dobio: MVP rješenje, nema metrike, nema ciljeva, nema procesa poboljšanja, dok se 7% nastavnika žali na kvalitetu komunikacije (nije bilo ni podataka o studentima).
Novi smjer je u tijeku
Naredba izgleda otprilike ovako:
- Voditelj odjela, koji je ujedno i glavni nositelj izrade.
- QA pomaže u testiranju promjena, traži nove načine za stvaranje nestabilnih komunikacijskih uvjeta i prijavljuje probleme s prve crte.
- Analitičar neprestano traži različite korelacije u tehničkim podacima, poboljšava analizu povratnih informacija korisnika i provjerava rezultate eksperimenata.
- Voditelj proizvoda pomaže u cjelokupnom usmjeravanju i raspodjeli resursa za eksperimente.
- Drugi programer često pomaže u programiranju i srodnim zadacima.
Za početak, postavili smo relativno pouzdanu metriku koja je pratila promjene u procjenama kvalitete komunikacije (prosjek po danima, tjednima, mjesecima). Tada su to bile ocjene nastavnika, kasnije su im dodane ocjene učenika. Zatim su počeli graditi hipoteze o tome što nije radilo, ispravljati to i promatrati promjene u dinamici. Odlučili smo se za jeftino: na primjer, zamijenili smo vp8 kodek s vp9, izvedba se poboljšala. Pokušali smo se igrati s Janusovim postavkama i provesti druge eksperimente - u većini slučajeva nisu doveli do ničega.
U drugoj fazi pojavila se hipoteza: WebRTC je peer-to-peer rješenje, a mi koristimo server u sredini. Možda je problem ovdje? Počeli smo kopati i pronašli najznačajnije poboljšanje dosad.
U tom trenutku server iz poola je odabran prilično glupim algoritmom: svaki je imao svoju “težinu”, ovisno o kanalu i snazi, a mi smo pokušali poslati korisnika na onaj s najvećom “težinom”, bez obraćajući pozornost na to gdje se korisnik geografski nalazio. Kao rezultat toga, učitelj iz St. Petersburga mogao je komunicirati s učenikom iz Sibira preko Moskve, a ne preko našeg Janus poslužitelja u St. Petersburgu.
Algoritam je prerađen: sada, kada korisnik otvori našu platformu, prikupljamo pingove od njega do svih poslužitelja koji koriste Ajax. Prilikom uspostavljanja veze odabiremo par pingova (nastavnik-poslužitelj i učenik-poslužitelj) s najmanjim iznosom. Manje pinga znači manju mrežnu udaljenost od poslužitelja; kraća udaljenost znači manju vjerojatnost gubitka paketa; Gubitak paketa je najveći negativni faktor u video komunikaciji. Udio negativnosti se prepolovio u tri mjeseca (pravo rečeno, u to vrijeme su se provodili i drugi eksperimenti, ali ovaj je gotovo sigurno imao najveći utjecaj).
Nedavno smo otkrili još jednu neočitu, ali očito važnu stvar: umjesto jednog moćnog Janus poslužitelja na debelom kanalu, bolje je imati dva jednostavnija s tanjom propusnošću. To je postalo jasno nakon što smo kupili moćne strojeve u nadi da ćemo u njih natrpati što više soba (komunikacijskih sesija) u isto vrijeme. Poslužitelji imaju ograničenje propusnosti, koje možemo točno prevesti u broj soba - znamo koliko ih se može otvoriti, na primjer, pri 300 Mbit/s. Čim na serveru ima previše otvorenih soba, prestajemo ga birati za nove aktivnosti dok se opterećenje ne smanji. Ideja je bila da, kupnjom moćnog stroja, maksimalno opteretimo kanal do njega, tako da na kraju bude ograničen procesorom i memorijom, a ne propusnošću. No, pokazalo se da nakon određenog broja otvorenih soba (420), unatoč činjenici da je opterećenje procesora, memorije i diska još uvijek vrlo daleko od ograničenja, negativnosti počinju stizati u tehničku podršku. Očigledno se nešto pogoršava unutar Janusa, možda i tu postoje neka ograničenja. Počeli smo eksperimentirati, spustili ograničenje propusnosti s 300 na 200 Mbit/s i problemi su nestali. Sada smo kupili tri nova poslužitelja odjednom s niskim ograničenjima i karakteristikama, mislimo da će to dovesti do stabilnog poboljšanja kvalitete komunikacije. Naravno, nismo pokušavali shvatiti što se tamo događa, štake su nam sve. U svoju obranu, recimo da je u tom trenutku bilo potrebno hitan problem riješiti što je brže moguće, a ne učiniti ga lijepo; osim toga, Janus je za nas crna kutija napisana u C, vrlo je skupo petljati s njom.
Pa, u procesu mi:
- ažurirane sve ovisnosti koje se mogu ažurirati, kako na poslužitelju tako i na klijentu (to su također bili eksperimenti, pratili smo rezultate);
- popravljeni su svi identificirani bugovi koji se odnose na određene slučajeve, na primjer, kada je veza prekinuta i nije se automatski obnovila;
- Održali smo puno sastanaka s tvrtkama koje rade na području video komunikacija i upoznate su s našim problemima: streaming igara, organiziranje webinara; isprobali smo sve što nam se činilo korisnim;
- Proveden tehnički pregled hardvera i kvalitete komunikacije nastavnika, od kojih je stiglo najviše pritužbi.
Eksperimenti i naknadne promjene omogućili su smanjenje nezadovoljstva komunikacijom među nastavnicima sa 7,1% u siječnju 2018. na 2,5% u siječnju 2019.
što dalje
Stabilizacija naše Vimbox platforme jedan je od glavnih projekata tvrtke za 2019. godinu. Jako se nadamo da ćemo uspjeti održati zamah i više nećemo vidjeti video komunikaciju među glavnim pritužbama. Razumijemo da se značajan dio ovih pritužbi odnosi na kašnjenja u korisničkim računalima i internetu, ali taj dio moramo utvrditi, a ostatak riješiti. Sve ostalo je tehnički problem, čini se da bismo se s njim trebali nositi.
Glavna poteškoća je u tome što ne znamo do koje je razine zapravo moguće poboljšati kvalitetu. Pronalaženje ovog stropa glavni je zadatak. Stoga su planirana dva eksperimenta:
- usporedite video putem Janusa s običnim p2p u borbenim uvjetima. Ovaj eksperiment je već proveden, nije pronađena statistički značajna razlika između naše otopine i p2p;
- Opskrbimo (skupe) usluge tvrtki koje zarađuju isključivo na videokomunikacijskim rješenjima i usporedimo količinu negativnosti od njih s postojećom.
Ova dva eksperimenta omogućit će nam da identificiramo dostižni cilj i usredotočimo se na njega.
Osim toga, postoji niz zadataka koji se mogu rješavati rutinski:
- Mi stvaramo tehničku metriku kvalitete komunikacije umjesto subjektivnih recenzija;
- Izrađujemo detaljnije zapise sesija kako bismo točnije analizirali kvarove koji se javljaju, razumjeli kada i gdje su se točno dogodili te koji su se naizgled nepovezani događaji dogodili u tom trenutku;
- Pripremamo automatski test kvalitete veze prije predavanja, a klijentu također dajemo mogućnost ručnog testiranja veze kako bismo smanjili količinu negativnosti koju uzrokuje njegov hardver i kanal;
- razvit ćemo i provesti više testova opterećenja videokomunikacije u lošim uvjetima, s promjenjivim gubitkom paketa itd.;
- mijenjamo ponašanje poslužitelja u slučaju problema kako bismo povećali toleranciju na pogreške;
- Upozorit ćemo korisnika ako uopće nešto nije u redu s njegovom vezom, kao što to radi Skype, kako bi shvatio da je problem na njegovoj strani.
Od travnja je smjer videokomunikacija postao punopravni zaseban projekt unutar Skyenga koji se bavi vlastitim proizvodom, a ne samo dijelom Vimboxa. To znači da počinjemo tražiti ljude na . Pa, kao i uvijek .
I, naravno, nastavljamo aktivno komunicirati s ljudima i tvrtkama koje se bave video komunikacijama. Ako želite razmijeniti iskustva s nama, bit će nam drago! Komentirajte, javite se - svima ćemo odgovoriti.
Izvor: www.habr.com