Video komunikacija je glavni način komunikacije između nastavnika i učenika na Vimbox platformi. Odustali smo od Skypea davno, isprobali nekoliko rješenja trećih strana i na kraju smo se odlučili na kombinaciju WebRTC - Janus-gateway. Neko vrijeme smo bili zadovoljni svime, ali su se i dalje javljali neki negativni aspekti. Kao rezultat toga, stvorena je posebna video režija.
Zamolio sam Kirila Rogovoja, šefa novog smjera, da govori o evoluciji video komunikacije u Skyengu, otkrivenim problemima, rješenjima i štakama koje smo na kraju koristili. Nadamo se da će članak biti koristan za kompanije koje i same kreiraju video putem web aplikacije.
Malo istorije
U ljeto 2017., šef razvoja Skyeng-a, Sergej Safonov, govorio je na Backend Conf-u s pričom o tome kako smo „napustili Skype i implementirali WebRTC“. Zainteresovani mogu pogledati snimak govora na (~45 min), a ovdje ću ukratko iznijeti njegovu suštinu.
Za Skyeng školu, video komunikacija je uvijek bila prioritetni način komunikacije nastavnika i učenika. U početku se koristio Skype, ali kategorički nije bio zadovoljavajući iz niza razloga, prvenstveno zbog nedostatka logova i nemogućnosti integracije direktno u web aplikaciju. Stoga smo izvodili razne eksperimente.
Zapravo, naši zahtjevi za video komunikacijom bili su otprilike sljedeći:
— stabilnost;
— niska cijena po času;
— snimanje časova;
— praćenje ko koliko govori (nama je važno da učenici govore više od nastavnika tokom nastave);
— linearno skaliranje;
- mogućnost korištenja i UDP i TCP.
Prvi koji je pokušao implementirati Tokbox 2013. godine. Sve je bilo dobro, ali ispostavilo se da je veoma skupo - 113 rubalja po lekciji - i pojelo je profit.
Zatim je 2015. integriran Voximplant. Ovdje je bila funkcija koja nam je bila potrebna da pratimo ko koliko govori, a u isto vrijeme rješenje je bilo mnogo jeftinije: ako se snima samo audio, košta 20 rubalja po lekciji. Međutim, radio je samo preko 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 da imamo korporativne klijente sa svojim specifičnim zahtevima. Na primjer, sve bi trebalo da radi preko pretraživača; kompanija otvara samo http i https; tj. bez Skypea ili UDP-a. Korporativni klijenti = novac, pa su se vratili u Tokbox, ali problem cijene nije nestao.
Rješenje - WebRTC i Janus
Odlučeno koristiti . Odgovoran je za uspostavljanje veze, kodiranje i dekodiranje tokova, sinhronizaciju staza i kontrolu kvaliteta uz rukovanje mrežnim problemima. Sa naše strane, moramo osigurati čitanje tokova sa kamere i mikrofona, crtanje videa, upravljanje vezom, uspostavljanje WebRTC veze i prijenos tokova 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 klijenti stoje iza NAT-a, WebRTC povezuje STUN servere; ako to ne pomogne, TURN servere.
Redovna p2p veza nam nije dovoljna, jer želimo snimiti lekcije za dalju analizu u slučaju pritužbi. Stoga šaljemo WebRTC streamove preko releja . Kao rezultat toga, klijenti ne znaju jedni druge adrese, vide samo adresu Janus servera; također obavlja funkcije signalnog servera. Janus ima mnoge funkcije 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, STUN i TURN serveri iz Twilioa se automatski povezuju.
U ljeto 2017. godine radila su dva Janus servera, plus dodatni server za obradu snimljenih sirovih audio i video fajlova, kako ne bi zauzeli procesore glavnih. Prilikom povezivanja, Janus serveri su odabrani na bazi par-nepar (broj veze). U to vrijeme, to je bilo dovoljno, prema našim osjećajima, dalo je otprilike četverostruku sigurnosnu marginu, postotak implementacije je bio oko 80. Istovremeno, cijena je smanjena na ~2 rublje po lekciji, plus razvoj i podrška.
Da se vratimo na temu video komunikacije
Stalno pratimo povratne informacije od učenika i nastavnika kako bismo na vrijeme identifikovali i otklonili probleme. Do ljeta 2018. kvalitet poziva bio je čvrsto na prvom mjestu među žalbama. S jedne strane, to je značilo da smo uspješno prevazišli druge nedostatke. S druge strane, trebalo je nešto hitno učiniti: ako se lekcija poremeti, rizikujemo da izgubimo njenu vrijednost, ponekad zajedno s troškovima kupovine sljedećeg paketa, a ako se poremeti uvodni čas, rizikujemo da izgubimo potencijalnog klijenta. totalno.
U to vrijeme naša video komunikacija je još uvijek bila u MVP modu. Jednostavno rečeno, pokrenuli su ga, proradilo je, jednom su ga skalirali, shvatili su kako to da urade - pa, odlično. Ako radi, nemojte ga popravljati. Niko se namjerno nije pozabavio pitanjem kvaliteta komunikacije. Do avgusta je postalo jasno da se to ne može nastaviti i pokrenuli smo poseban pravac da otkrijemo šta nije u redu sa WebRTC-om i Janusom.
Na ulazu je ovaj pravac dobio: MVP rješenje, bez metrike, bez ciljeva, bez procesa za poboljšanje, dok se 7% nastavnika žali na kvalitet komunikacije (podataka ni o učenicima nije bilo).
Novi pravac je u toku
Naredba izgleda otprilike ovako:
- Šef odjela, koji je ujedno i glavni programer.
- QA pomaže u testiranju promjena, traži nove načine za stvaranje nestabilnih komunikacijskih uvjeta i izvještava o problemima s prve linije.
- Analitičar stalno traži različite korelacije u tehničkim podacima, poboljšava analizu povratnih informacija korisnika i provjerava rezultate eksperimenata.
- Menadžer 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 prati promjene u procjenama kvaliteta komunikacije (prosjek u danima, sedmicama, mjesecima). U to vrijeme to su bile ocjene nastavnika, kasnije su im se dodavale ocjene učenika. Zatim su počeli da grade hipoteze o tome šta radi pogrešno, ispravljaju to i posmatraju promene u dinamici. Opredelili smo se za voće sa niskim visinom: na primer, zamenili smo vp8 kodek sa vp9, performanse su se poboljšale. Pokušali smo se igrati s Janus postavkama i provoditi 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 do sada.
U tom trenutku je server iz pula odabran prilično glupim algoritmom: svaki je imao svoju „težinu“, u zavisnosti od kanala i snage, a mi smo pokušali da pošaljemo korisnika na onaj sa najvećom „težinom“, bez obraćajući pažnju na to gdje se korisnik geografski nalazi. Kao rezultat toga, nastavnik iz Sankt Peterburga mogao je da komunicira sa učenikom iz Sibira preko Moskve, a ne preko našeg Janus servera u Sankt Peterburgu.
Algoritam je redizajniran: sada, kada korisnik otvori našu platformu, prikupljamo pingove od njega do svih servera koji koriste Ajax. Prilikom uspostavljanja veze biramo par pingova (nastavnik-server i učenik-server) sa najmanjim iznosom. Manji ping znači manju mrežnu udaljenost do servera; kraća udaljenost znači manju vjerovatnoću gubitka paketa; Gubitak paketa je najveći negativni faktor u video komunikaciji. Udio negativnosti prepolovio se u tri mjeseca (da budemo iskreni, u to vrijeme su rađeni i drugi eksperimenti, ali je ovaj gotovo sigurno imao najveći utjecaj).
Nedavno smo otkrili još jednu neočiglednu, ali naizgled važnu stvar: umjesto jednog moćnog Janus servera na debelom kanalu, bolje je imati dva jednostavnija s tanjom propusnošću. To je postalo jasno nakon što smo kupili moćne mašine u nadi da ćemo u njih ugurati što više prostorija (komunikacijskih sesija) u isto vrijeme. Serveri imaju ograničenje propusnosti, koje možemo precizno prevesti u broj soba - znamo koliko ih se može otvoriti, na primjer, pri 300 Mbit/s. Čim se na serveru otvori previše soba, prestajemo ga birati za nove aktivnosti dok se opterećenje ne smanji. Ideja je bila da, kupovinom moćne mašine, maksimalno učitamo kanal do njega, kako bi na kraju bio ograničen procesorom i memorijom, a ne propusnošću. No, pokazalo se da nakon određenog broja otvorenih prostorija (420), unatoč činjenici da je opterećenje procesora, memorije i diska još uvijek jako daleko od granica, 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, smanjili ograničenje propusnosti sa 300 na 200 Mbit/s i problemi su nestali. Sada smo kupili tri nova servera odjednom sa niskim limitima i karakteristikama, mislimo da će to dovesti do stabilnog poboljšanja kvaliteta komunikacije. Naravno, nismo pokušavali da shvatimo šta se tamo dešava; naše štake su sve. U našu odbranu, recimo da je u tom trenutku bilo potrebno što prije riješiti gorući problem, a ne to učiniti lijepo; osim toga, Janus je za nas crna kutija napisana u C-u, jako je skupo petljati se po njoj.
Pa, u procesu mi:
- ažurirane sve zavisnosti koje se mogu ažurirati, kako na serveru tako i na klijentu (i to su bili eksperimenti, pratili smo rezultate);
- popravljene sve identificirane greške vezane za specifične slučajeve, na primjer, kada je veza prekinuta i nije automatski obnovljena;
- Održali smo dosta sastanaka sa kompanijama koje rade u oblasti video komunikacija i upoznati sa našim problemima: streaming igrica, organizacija webinara; probali smo sve što nam se činilo korisnim;
- Obavljen je tehnički pregled hardvera i kvaliteta komunikacije nastavnika, od kojih je stiglo najviše pritužbi.
Eksperimenti i naknadne promjene omogućile su da se smanji nezadovoljstvo komunikacijom među nastavnicima sa 7,1% u januaru 2018. na 2,5% u januaru 2019.
Šta sledi
Stabilizacija naše Vimbox platforme jedan je od glavnih projekata kompanije za 2019. Imamo velike nade da ćemo uspjeti zadrž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 zastoje računara korisnika i interneta, ali ovaj dio moramo utvrditi, a ostatak riješiti. Sve ostalo su tehnički problemi, čini se da bismo se trebali nositi s njim.
Glavna poteškoća je u tome što ne znamo do koje razine je zapravo moguće poboljšati kvalitet. Pronalaženje ovog plafona je glavni zadatak. Stoga su planirana dva eksperimenta:
- uporedi video preko Janusa sa redovnim p2p-om u borbenim uslovima. Ovaj eksperiment je već izveden, nije pronađena statistički značajna razlika između našeg rješenja i p2p;
- Isporučimo (skupe) usluge od kompanija koje zarađuju isključivo na video komunikacijskim rješenjima i uporedimo količinu negativnosti od njih sa postojećom.
Ova dva eksperimenta će nam omogućiti da identificiramo ostvarivi cilj i fokusiramo se na njega.
Osim toga, postoji niz zadataka koji se mogu rutinski rješavati:
- Kreiramo tehničku metriku kvaliteta komunikacije umjesto subjektivnih recenzija;
- Pravimo detaljnije dnevnike sesija kako bismo preciznije analizirali kvarove koji su se desili, razumeli kada i gde su se tačno desili i koji su se naizgled nepovezani događaji odigrali u tom trenutku;
- Pripremamo automatski test kvaliteta veze prije lekcije, a također dajemo mogućnost klijentu da ručno testira vezu kako bi smanjio količinu negativnosti koju uzrokuje njegov hardver i kanal;
- mi ćemo razviti i sprovesti više testova opterećenja video komunikacije u lošim uslovima, sa promenljivim gubitkom paketa, itd.;
- mijenjamo ponašanje servera u slučaju problema radi povećanja tolerancije grešaka;
- Upozorićemo korisnika ako uopšte nešto nije u redu sa njegovom vezom, kao što to radi Skype, kako bi shvatio da je problem na njegovoj strani.
Od aprila, pravac video komunikacije postao je potpuno zaseban projekat u okviru Skyeng-a, koji se bavi sopstvenim proizvodom, a ne samo delom Vimbox-a. To znači da počinjemo da tražimo ljude . Pa, kao i uvek .
I, naravno, nastavljamo aktivno komunicirati sa ljudima i kompanijama koje se bave video komunikacijama. Ukoliko želite da razmenite iskustva sa nama, biće nam drago! Komentirajte, javite se - odgovorićemo svima.
izvor: www.habr.com