Videoviestintä on tärkein tapa kommunikoida opettajan ja opiskelijan välillä Vimbox-alustalla. Luovuimme Skypestä kauan sitten, kokeilimme useita kolmannen osapuolen ratkaisuja ja päädyimme lopulta WebRTC - Janus-gateway -yhdistelmään. Jonkin aikaa olimme tyytyväisiä kaikkeen, mutta silti joitain negatiivisia puolia nousi esiin. Tämän seurauksena luotiin erillinen videosuunta.
Pyysin uuden suunnan johtajaa Kirill Rogovoyta puhumaan Skyengin videoviestinnän kehityksestä, löydetyistä ongelmista, ratkaisuista ja kainalosauvoista, joita lopulta käytimme. Toivomme artikkelista olevan hyötyä yrityksille, jotka myös luovat videoita itse verkkosovelluksen kautta.
Vähän historiaa
Kesällä 2017 Skyengin kehitysjohtaja Sergey Safonov puhui Backend Confissa tarinalla siitä, kuinka "hylkäsimme Skypen ja otimme käyttöön WebRTC:n". Kiinnostuneet voivat katsoa puheen tallenteen osoitteessa (~45 min), ja tässä hahmotan lyhyesti sen olemuksen.
Skyeng Schoolille videoviestintä on aina ollut ensisijainen tapa opettajan ja oppilaan välisessä viestinnässä. Aluksi käytettiin Skypeä, mutta se ei ollut kategorisesti tyydyttävä useista syistä, pääasiassa lokien puutteen ja suoraan verkkosovellukseen integroinnin mahdottomuuden vuoksi. Siksi teimme kaikenlaisia kokeita.
Itse asiassa videoviestinnän vaatimukset olivat suunnilleen seuraavat:
— vakaus;
- alhainen hinta per oppitunti;
— oppituntien äänitys;
— seurata, kuka puhuu kuinka paljon (meille on tärkeää, että oppilaat puhuvat enemmän kuin opettaja oppituntien aikana);
— lineaarinen skaalaus;
- kyky käyttää sekä UDP:tä että TCP:tä.
Ensimmäinen kokeilu oli Tokboxin käyttöönotto vuonna 2013. Kaikki oli hyvää, mutta se osoittautui erittäin kalliiksi - 113 ruplaa per oppitunti - ja söi voiton.
Sitten vuonna 2015 Voximplant integroitiin. Tässä oli toiminto, jonka piti seurata kuka puhui kuinka paljon, ja samalla ratkaisu oli paljon halvempi: jos vain ääni nauhoitettiin, se maksoi 20 ruplaa per oppitunti. Se toimi kuitenkin vain UDP:n kautta eikä voinut vaihtaa TCP:hen. Kuitenkin noin 40 % opiskelijoista päätyi käyttämään sitä.
Vuotta myöhemmin meillä alkoi olla yritysasiakkaita, joilla oli omat erityisvaatimukset. Esimerkiksi kaiken pitäisi toimia selaimen kautta, yritys avaa vain http ja https; eli ei Skypeä tai UDP:tä. Yritysasiakkaat = rahaa, joten he palasivat Tokboxiin, mutta hintaongelma ei poistunut.
Ratkaisu - WebRTC ja Janus
Päätti käyttää . Se vastaa yhteyden muodostamisesta, virtojen koodaamisesta ja purkamisesta, raitojen synkronoinnista ja laadunvalvonnasta verkkohäiriöiden käsittelyssä. Meidän on omalta osaltamme varmistettava streamien lukeminen kamerasta ja mikrofonista, videon piirtäminen, yhteyden hallinta, WebRTC-yhteyden muodostaminen ja streamien välittäminen siihen sekä signalointiviestien välittäminen asiakkaiden välillä yhteyden muodostamiseksi (itse WebRTC kuvaa vain tietomuoto, mutta ei sen siirtomekanismi). Jos asiakkaat ovat NAT:n takana, WebRTC yhdistää STUN-palvelimet; jos tämä ei auta, TURN-palvelimet.
Tavallinen p2p-yhteys ei meille riitä, koska haluamme tallentaa oppitunteja jatkoanalyysiä varten valitusten varalta. Siksi lähetämme WebRTC-streameja releen kautta . Tämän seurauksena asiakkaat eivät tiedä toistensa osoitteita, vaan näkevät vain Janus-palvelimen osoitteen; se suorittaa myös signaalipalvelimen toimintoja. Januksella on monia tarvitsemiamme ominaisuuksia: siirtyy automaattisesti TCP:hen, jos asiakas on estänyt UDP:n; voi tallentaa sekä UDP- että TCP-virtoja; skaalautuva; Siellä on jopa sisäänrakennettu laajennus kaikutestejä varten. Tarvittaessa Twilion STUN- ja TURN-palvelimet yhdistetään automaattisesti.
Kesällä 2017 meillä oli käytössä kaksi Janus-palvelinta sekä lisäpalvelin tallennettujen raakaääni- ja videotiedostojen käsittelyyn, jotta pääpalvelinten prosessorit eivät joutuisi varaamaan. Yhteyttä muodostettaessa Janus-palvelimet valittiin parittoman parillisen perusteella (yhteysnumero). Tuolloin tämä riitti, tunteidemme mukaan se antoi noin nelinkertaisen varmuusmarginaalin, toteutusprosentti oli noin 80. Samalla hinta laskettiin ~2 ruplaan per tunti, plus kehitys ja tuki.
Palataan videoviestinnän aiheeseen
Seuraamme jatkuvasti opiskelijoiden ja opettajien palautetta tunnistaaksemme ja korjataksemme ongelmat oikea-aikaisesti. Kesään 2018 mennessä puheluiden laatu oli vahvasti ensimmäisellä sijalla valitusten joukossa. Yhtäältä tämä tarkoitti, että olimme onnistuneet voittamaan muut puutteet. Toisaalta oli pakko tehdä jotain kiireellisesti: jos oppitunti häiriintyy, vaarana on menettää sen arvo, joskus seuraavan paketin ostokustannusten ohella, ja jos johdantotunti häiriintyy, vaarana on menettää mahdollinen asiakas yhteensä.
Tuolloin videoviestintämme oli vielä MVP-tilassa. Yksinkertaisesti sanottuna he lanseerasivat sen, se toimi, he skaalasivat sen kerran, he ymmärsivät, kuinka se tehdään - hienoa. Jos se toimii, älä korjaa sitä. Kukaan ei tietoisesti käsitellyt viestinnän laatua. Elokuussa kävi selväksi, että tämä ei voi jatkua, ja käynnistimme erillisen suunnan selvittääksemme, mikä WebRTC:ssä ja Januksessa oli vialla.
Syötteessä tämä suunta sai: MVP-ratkaisu, ei mittareita, ei tavoitteita, ei parannusprosesseja, kun taas 7 % opettajista valittaa viestinnän laadusta (ei myöskään ollut tietoja opiskelijoista).
Uusi suunta on käynnissä
Komento näyttää suunnilleen tältä:
- Osaston johtaja, joka on myös pääkehittäjä.
- Laadunvarmistus auttaa testaamaan muutoksia, etsii uusia tapoja luoda epävakaita viestintäolosuhteita ja raportoi ongelmista etulinjasta.
- Analyytikko etsii jatkuvasti erilaisia korrelaatioita teknisistä tiedoista, parantaa käyttäjäpalautteen analysointia ja tarkistaa kokeiden tulokset.
- Tuotepäällikkö auttaa kokeiden kokonaissuunnassa ja resurssien allokoinnissa.
- Toinen kehittäjä auttaa usein ohjelmoinnissa ja siihen liittyvissä tehtävissä.
Aluksi määritimme suhteellisen luotettavan mittarin, joka seuraa viestintälaadun arvioinnin muutoksia (päivien, viikkojen ja kuukausien keskiarvo). Tuolloin nämä olivat opettajien arvosanat, joihin lisättiin myöhemmin opiskelijoiden arvosanat. Sitten he alkoivat rakentaa hypoteeseja siitä, mikä toimi väärin, korjata niitä ja tarkastella muutoksia dynamiikassa. Menimme matalaan roikkuviin hedelmiin: esimerkiksi korvasimme vp8-koodekin vp9:llä, suorituskyky parani. Yritimme leikkiä Januksen asetuksilla ja tehdä muita kokeita - useimmissa tapauksissa ne eivät johtaneet mihinkään.
Toisessa vaiheessa nousi esiin hypoteesi: WebRTC on peer-to-peer-ratkaisu, jonka keskellä käytämme palvelinta. Ehkä ongelma on tässä? Aloitimme kaivamisen ja löysimme tähän mennessä merkittävimmän parannuksen.
Tuolloin poolista valittiin palvelin melko typerällä algoritmilla: jokaisella oli oma "painonsa" kanavasta ja tehosta riippuen, ja yritimme lähettää käyttäjän sille, jolla on suurin "paino", ilman kiinnittää huomiota käyttäjän maantieteelliseen sijaintiin . Tämän seurauksena pietarilainen opettaja saattoi kommunikoida Siperiasta tulevan opiskelijan kanssa Moskovan kautta, ei Janus-palvelimemme kautta Pietarissa.
Algoritmi on uusittu: nyt, kun käyttäjä avaa alustamme, keräämme häneltä pingit kaikille Ajaxia käyttäville palvelimille. Kun muodostamme yhteyttä, valitsemme ping-parin (opettaja-palvelin ja opiskelija-palvelin), joiden määrä on pienin. Pienempi ping tarkoittaa pienempää verkon etäisyyttä palvelimeen; lyhyempi etäisyys tarkoittaa pienempää todennäköisyyttä pakettien häviämiselle; Pakettihäviö on suurin negatiivinen tekijä videoviestinnässä. Negatiivisuuden osuus putosi puoleen kolmessa kuukaudessa (rehellisyyden nimissä, muitakin kokeita tehtiin tällä kertaa, mutta tällä oli lähes varmasti suurin vaikutus).
Löysimme äskettäin toisen ei-ilmeisen, mutta ilmeisen tärkeän asian: paksulla kanavalla olevan tehokkaan Janus-palvelimen sijaan on parempi, että sinulla on kaksi yksinkertaisempaa, joiden kaistanleveys on ohuempi. Tämä kävi selväksi, kun ostimme tehokkaita koneita siinä toivossa, että niihin mahtuisi mahdollisimman monta huonetta (viestintäistuntoa) yhtä aikaa. Palvelimilla on kaistanleveysrajoitus, jonka voimme kääntää tarkasti huonemääräksi – tiedämme kuinka monta voidaan avata esimerkiksi nopeudella 300 Mbit/s. Heti kun palvelimella on liian monta huonetta auki, lopetamme sen valitsemisen uusiin aktiviteetteihin, kunnes kuormitus laskee. Ajatuksena oli, että ostaessamme tehokkaan koneen lataamme kanavan siihen maksimaalisesti, jotta loppujen lopuksi sitä rajoittaisi prosessori ja muisti, ei kaistanleveys. Mutta kävi ilmi, että tietyn määrän avoimia huoneita (420) jälkeen huolimatta siitä, että prosessorin, muistin ja levyn kuormitus on edelleen hyvin kaukana rajoista, negatiivisuus alkaa saapua tekniseen tukeen. Ilmeisesti Januksen sisällä jokin pahenee, ehkä sielläkin on joitain rajoituksia. Aloimme kokeilla, pudotimme kaistanleveysrajaa 300:sta 200 Mbit/s:iin ja ongelmat hävisivät. Nyt ostimme kolme uutta palvelinta kerralla matalilla rajoilla ja ominaisuuksilla, uskomme tämän johtavan vakaaseen parantumiseen viestinnän laadussa. Emme tietenkään yrittäneet selvittää, mitä siellä tapahtuu; kainalosauvat ovat kaikki kaikessa. Puolustuksemme sanotaan, että sillä hetkellä oli välttämätöntä ratkaista kiireellinen ongelma mahdollisimman nopeasti, eikä tehdä sitä kauniisti; sitä paitsi meille Janus on musta laatikko, joka on kirjoitettu C-kielellä, sen parissa on erittäin kallista.
No, tässä prosessissa me:
- päivitti kaikki päivitettävät riippuvuudet sekä palvelimella että asiakkaalla (nämäkin olivat kokeiluja, seurasimme tuloksia);
- korjasi kaikki tunnistetut virheet, jotka liittyvät tiettyihin tapauksiin, esimerkiksi kun yhteys katkesi eikä sitä palautettu automaattisesti;
- Pidimme paljon tapaamisia videoviestinnän alalla toimivien ja ongelmamme tuntevien yritysten kanssa: pelien suoratoisto, webinaarien järjestäminen; kokeilimme kaikkea, mikä näytti meille hyödylliseltä;
- Teki teknisen katsauksen opettajien laitteisto- ja viestintälaadusta, joilta tuli eniten valituksia.
Kokeilujen ja myöhempien muutosten ansiosta tyytymättömyyttä opettajien viestintään pystyttiin vähentämään tammikuun 7,1 2018 prosentista 2,5 prosenttiin tammikuussa 2019.
Mitä seuraavaksi
Vimbox-alustamme vakauttaminen on yksi yhtiön vuoden 2019 pääprojekteista. Meillä on suuria toiveita, että pystymme ylläpitämään vauhtia, emmekä enää näe videoviestintää kärkivalituksissa. Ymmärrämme, että merkittävä osa näistä valituksista liittyy käyttäjien tietokoneiden ja Internetin viiveisiin, mutta meidän on määritettävä tämä osa ja ratkaistava loput. Kaikki muu on tekninen ongelma, näyttää siltä, että meidän pitäisi pystyä selviytymään siitä.
Suurin vaikeus on se, että emme tiedä, mille tasolle laatua itse asiassa on mahdollista parantaa. Tämän katon selvittäminen on tärkein tehtävä. Siksi suunniteltiin kaksi koetta:
- vertaa videota Januksen kautta tavalliseen p2p:hen taisteluolosuhteissa. Tämä koe on jo suoritettu, tilastollisesti merkitsevää eroa ei löydetty ratkaisumme ja p2p:n välillä;
- Toimitetaan (kalleita) palveluita yrityksiltä, jotka tienaavat yksinomaan videoviestintäratkaisuilla, ja verrataan niiden negatiivisuuden määrää olemassa olevaan.
Näiden kahden kokeen avulla voimme tunnistaa saavutettavissa olevan tavoitteen ja keskittyä siihen.
Lisäksi on useita tehtäviä, jotka voidaan ratkaista rutiininomaisesti:
- Luomme viestintälaadun teknisen mittarin subjektiivisten arvioiden sijaan;
- Teemme yksityiskohtaisempia istuntolokeja, jotta voimme analysoida tarkemmin esiintyviä vikoja, ymmärtää, milloin ja missä ne tarkalleen tapahtuivat ja mitä näennäisesti toisiinsa liittymättömiä tapahtumia tapahtui sillä hetkellä;
- Valmistelemme automaattisen yhteyden laatutestin ennen oppituntia ja annamme asiakkaalle myös mahdollisuuden testata yhteyttä manuaalisesti vähentääksemme hänen laitteistonsa ja kanavansa aiheuttamaa negatiivisuutta;
- kehitämme ja teemme lisää videoviestinnän kuormitustestejä huonoissa olosuhteissa, vaihtelevalla pakettihäviöllä jne.;
- muutamme palvelinten käyttäytymistä ongelmatilanteissa parantaaksemme vikasietoisuutta;
- Varoitamme käyttäjää, jos hänen yhteydessään on jotain vikaa, kuten Skype tekee, jotta hän ymmärtää ongelman olevan hänen puolellaan.
Huhtikuusta lähtien videoviestintäsuunnasta on tullut Skyengin sisällä täysimittainen erillinen projekti, joka käsittelee omaa tuotettaan, ei vain osa Vimboxia. Tämä tarkoittaa, että alamme etsiä ihmisiä . No, kuten aina .
Ja tietysti jatkamme aktiivista kommunikointia videoviestinnän parissa työskentelevien ihmisten ja yritysten kanssa. Jos haluat vaihtaa kokemuksia kanssamme, olemme iloisia! Kommentoi, ota yhteyttä - vastaamme kaikille.
Lähde: will.com