Videokommunikation Ă€r det primĂ€ra sĂ€ttet för lĂ€rare och studenter att kommunicera pĂ„ Vimbox-plattformen. Vi har lĂ€nge övergett Skype, testat flera externa lösningar och slutligen landat pĂ„ WebRTC â Janus-gateway. Under en tid var vi nöjda, men vissa negativa aspekter fortsatte att dyka upp. DĂ€rför skapades en separat avdelning för video.
Jag bad Kirill Rogovoy, chefen för den nya avdelningen, att berÀtta om utvecklingen av videokommunikation pÄ Skyeng, de problem som uppstÄtt, lösningarna och de nödlösningar vi i slutÀndan tillÀmpade. Vi hoppas att artikeln kommer att vara anvÀndbar för företag som ocksÄ implementerar video via webbapplikationer.
Lite historia
Sommar 2017 deltog Skyengs chef för utveckling, Sergey Safonov, pÄ Backend Conf och talade om hur vi "övergav Skype och implementerade WebRTC". De som Àr intresserade kan se inspelningen av presentationen pÄ (~45 min), hÀr sammanfattar jag dess innehÄll.
För Skyeng har videokommunikation alltid varit det prioriterade sÀttet för lÀrar-student-interaktion. I början anvÀnde vi "Skype", men det fungerade helt och hÄllet inte av flera skÀl, frÀmst pÄ grund av bristen pÄ loggning och oförmÄgan att integrera den direkt i webbapplikationen. DÀrför genomförde vi olika experiment.
VÄra krav pÄ videokommunikation var ungefÀr sÄ hÀr:
â stabilitet;
â lĂ„g kostnad per lektion;
â inspelning av lektioner;
â spĂ„rning av talartid (vi vill att eleverna ska prata mer Ă€n lĂ€raren under lektioner);
â linjĂ€r skalning;
â möjlighet att anvĂ€nda bĂ„de UDP och TCP.
Först Ă„r 2013 försökte vi implementera Tokbox. Allt var bra, men det kostade mycket â 113 rubel per lektion â och Ă„t upp vinsten.
DÀrefter, 2015, integrerade vi Voximplant. HÀr fanns den funktion vi behövde för att spÄra talartid, och lösningen var betydligt billigare: med endast ljudinspelning kostade det 20 rubel per lektion. Det fungerade dock endast via UDP och kunde inte byta till TCP. Trots detta anvÀnde cirka 40% av eleverna det.
Ett Är senare började vi fÄ företagskunder med specifika krav. Till exempel, allt mÄste fungera via webblÀsaren, och företaget tillÄter endast http och https; det vill sÀga, inga "Skype" och UDP. Företagskunder = pengar, sÄ vi gick tillbaka till Tokbox, men prisproblemet kvarstÄr.
Lösningen â WebRTC och Janus
Vi beslutade att anvĂ€nda . Den ansvarar för att etablera anslutningen, kodning och avkodning av flöden, synkronisering av spĂ„r och kvalitetskontroll med hantering av nĂ€tverksproblem. FrĂ„n vĂ„r sida mĂ„ste vi sĂ€kerstĂ€lla lĂ€sning av flöden frĂ„n kamera och mikrofon, rendering av video, hantering av anslutningen, etablering av WebRTC-anslutningen och överföring av flöden till den, samt överföring av signaleringsmeddelanden mellan kunder för att etablera en anslutning (WebRTC beskriver endast datæ ŒćŒ, men inte mekanismen för deras överföring). Om kunderna befinner sig bakom NAT ansluter WebRTC STUN-servrar, och om det inte hjĂ€lper, TURN-servrar.
Ett vanligt p2p-anslutning rÀcker inte, eftersom vi vill spela in lektioner för vidare analys i hÀndelse av klagomÄl. DÀrför skickar vi WebRTC-flöden via en retranslator . Som ett resultat vet inte kunderna adresserna till varandra, utan ser endast adressen till Janus-servern; den fungerar ocksÄ som signalserver. Janus har mÄnga funktioner vi behöver: den gÄr automatiskt över till TCP om klienten blockerar UDP; kan spela in bÄde UDP- och TCP-flöden; Àr skalbar; det finns till och med en inbyggd modul för eko-tester. Vid behov ansluts automatiskt STUN och TURN-servrar frÄn Twilio.
Under sommaren 2017 hade vi tvÄ Janus-servrar plus en extra server för att bearbeta inspelade rÄa ljud- och videofiler sÄ att vi inte belastar processorerna för huvudservrarna. Vid anslutning valdes Janus-servrarna enligt principen jÀmn-odda (anslutningsnummer). DÄ rÀckte detta, vi kÀnde att det gav cirka fyrdubbel sÀkerhet, och implementeringsgraden var cirka 80. Samtidigt minskade kostnaden till ~2 rubel per lektion, plus utveckling och underhÄll.
à ter till Àmnet videokommunikation
Vi övervakar stÀndigt feedback frÄn elever och lÀrare för att snabbt identifiera och ÄtgÀrda problem. Fram till sommaren 2018 var kvaliteten pÄ internetuppkopplingen den mest frekventa klagan. à ena sidan betydde det att vi hade lyckats ÄtgÀrda andra brister. à andra sidan var det brÄdskande att göra nÄgot: om en lektion stÀlls in riskerar vi att förlora dess vÀrde, ibland Àven vÀrdet av nÀsta paket, och om ett introduktionspass stÀlls in riskerar vi att helt förlora en potentiel kund.
Vid den tidpunkten var vĂ„r videokontakt fortfarande i MVP-lĂ€ge. Enkelt uttryckt, vi startade det, det fungerade, vi skalade upp en gĂ„ng, förstod hur vi skulle göra â och det var bra. If it works, donât fix it. Ingen tog specifikt itu med kvaliteten pĂ„ uppkopplingen. I augusti blev det klart att det inte kunde fortsĂ€tta sĂ„ hĂ€r, och vi startade en separat avdelning för att ta reda pĂ„ vad som egentligen var fel med WebRTC och Janus.
Denna avdelning började med: MVP-lösning, inga mÀtvÀrden, inga mÄl, inga processer för förbÀttring, samtidigt som 7 % av lÀrarna klagade pÄ kvaliteten pÄ uppkopplingen (det fanns inga data om eleverna).
Den nya avdelningen sÀtter igÄng med arbetet
Teamet ser ungefÀr ut sÄ hÀr:
- Avdelningsledaren, som ocksÄ Àr huvudutvecklaren.
- QA-teamet hjÀlper till att testa Àndringar, letar efter nya sÀtt att skapa instabila förhÄllanden för uppkopplingen, rapporterar problem frÄn frontlinjen.
- Analytikern letar stÀndigt efter olika korrelationer i tekniska data, förbÀttrar analysen av anvÀndarfeedback, kontrollerar resultat av experiment.
- Produktchefen hjÀlper till med den övergripande inriktningen och tilldelning av resurser för experiment.
- Den andra utvecklaren hjÀlper ofta till med programmering och relaterade uppgifter.
För att börja stĂ€llde vi in en relativt pĂ„litlig metrisk som övervakade förĂ€ndringar i bedömningen av uppkopplingskvaliteten (genomsnitt per dagar, veckor, mĂ„nader). Vid den tidpunkten var det lĂ€rarens bedömningar, senare la vi till bedömningar frĂ„n studenter. Vi började sedan formulera hypoteser om vad som inte fungerade, korrigerade och sĂ„g pĂ„ förĂ€ndringarna över tid. Vi tog de lĂ„gt hĂ€ngande frukterna: till exempel bytte vi ut codec vp8 mot vp9, och resultaten förbĂ€ttrades. Vi provade olika instĂ€llningar för Janus och genomförde andra experiment â som oftast inte ledde till nĂ„got.
Vid det andra steget uppstod en hypotes: WebRTC Àr en peer-to-peer-lösning, och vi anvÀnder en server i mitten. Kan problemet ligga hÀr? Vi började grÀva och fann hÀr en hittills mest betydande förbÀttring.
Vid den tiden valdes servern frÄn poolen enligt en ganska simpel algoritm: varje server hade sin egen "vikt" som berodde pÄ bandbredd och kapacitet, och vi försökte skicka anvÀndare till den med högre "vikt", utan att ta hÀnsyn till var anvÀndaren geografiskt befann sig. Som ett resultat kunde en lÀrare frÄn Sankt Petersburg kommunicera med en student frÄn Sibirien via Moskva, istÀllet för att gÄ genom vÄr Janus-server i Sankt Petersburg.
Algoritmen har omarbetats: nu, nĂ€r en anvĂ€ndare öppnar vĂ„r plattform, samlar vi in pings via Ajax frĂ„n honom till alla servrar. Vid upprĂ€ttande av anslutningen vĂ€ljer vi ett par pings (lĂ€rare-server och student-server) med den lĂ€gsta summan. LĂ€ngre ping innebĂ€r kortare nĂ€tverksavstĂ„nd till servern; kortare avstĂ„nd â lĂ€gre sannolikhet att förlora paket; paketförlust Ă€r det största negativa faktorn i videosamtal. Negativitetsandelen sjönk med hĂ€lften under tre mĂ„nader (för rĂ€ttvisans skull, under denna tid genomfördes ocksĂ„ andra experiment, men denna pĂ„verkade nĂ€stan sĂ€kert mest).
Nyligen upptĂ€ckte vi ytterligare en icke-uppenbar men tydligen viktig sak: istĂ€llet för en kraftfull Janus-server pĂ„ en bred kanal Ă€r det bĂ€ttre med tvĂ„ enklare med lĂ€gre bandbredd. Detta blev uppenbart efter att vi köpt riktigt kraftfulla maskiner i förhoppningen att kunna rymma sĂ„ mĂ„nga rum (kommunikationssessioner) som möjligt samtidigt. Servrarna har en bandbreddsgrĂ€ns som vi kan översĂ€tta till antalet rum â vi vet hur mĂ„nga rum vi kan öppna, till exempel pĂ„ 300 Mbit/s. SĂ„ snart för mĂ„nga rum öppnas pĂ„ servern slutar vi vĂ€lja den för nya sessioner tills belastningen sjunker. Tanken var att genom att köpa en kraftfull maskin maximalt ladda kanalen sĂ„ att vi i slutĂ€ndan begriper oss pĂ„ processorn och minnet, och inte bandbredden. Men det visade sig att efter ett visst antal öppnade rum (420), trots att processor-, minnes- och diskbelastningen fortfarande Ă€r lĂ„ngt ifrĂ„n grĂ€nserna, börjar negativ feedback komma till supporten. Tydligen blir nĂ„got sĂ€mre inuti Janus, kanske finns det ocksĂ„ nĂ„gra begrĂ€nsningar dĂ€r. Vi började experimentera och sĂ€nkte bandbreddsgrĂ€nsen frĂ„n 300 till 200 Mbit/s, problemet försvann. Nu har vi köpt tre nya servrar med lĂ„ga begrĂ€nsningar och specifikationer och tror att detta kommer att leda till stabila förbĂ€ttringar i kommunikationskvaliteten. Vi granskade inte vad problemet var, naturligtvis, provisoriska lösningar Ă€r allt för oss. Till vĂ„rt försvar sĂ€ger vi att det i det ögonblicket var viktigt att snabbt lösa det akuta problemet och inte göra det fint; dessutom Ă€r Janus en svart lĂ„da för oss, skriven i C, och det Ă€r mycket kostsamt att grĂ€va i.
Och i processen gjorde vi:
- uppdaterade alla beroenden som kunde uppdateras, bÄde pÄ servern och pÄ klienten (detta var ocksÄ experiment, vi följde resultaten);
- fixade alla identifierade buggar som rörde specifika fall, till exempel nÀr anslutningen föll och inte ÄterstÀlldes automatiskt;
- höll mÀngder av möten med företag som arbetar inom videokommunikation och Àr bekanta med vÄra problem: som streamar spel och arrangerar webbinarier; testade allt som verkar anvÀndbart;
- genomförde en teknisk granskning av hÄrdvaran och kommunikationskvaliteten hos lÀrarna som fick flest klagomÄl.
Genomförda experiment och de efterföljande förÀndringarna har gjort det möjligt att minska missnöjet med kommunikationen bland lÀrare frÄn 7,1% i januari 2018 till 2,5% i januari 2019.
Vad hÀnder hÀrnÀst
Stabilisering av vÄr plattform Vimbox Àr ett av företagets huvudprojekt för 2019. Vi har stora förhoppningar om att vi ska kunna behÄlla denna dynamik och slippa se videokommunikation pÄ toppen av klagomÄlen. Vi förstÄr att en betydande del av dessa klagomÄl Àr relaterade till anvÀndarnas datorer och internetlagg, men vi mÄste identifiera denna del och lösa allt annat. Allt annat Àr ett tekniskt problem, och vi borde kunna hantera det.
HuvudsvÄrigheten Àr att vi inte vet hur mycket kvalitén verkligen kan förbÀttras. Att ta reda pÄ denna grÀns Àr vÄr huvuduppgift. DÀrför har vi planerat tvÄ experiment:
- att jÀmföra video genom Janus med vanlig p2p i praktiska förhÄllanden. Detta experiment har redan genomförts, och ingen statistiskt signifikant skillnad mellan vÄr lösning och p2p har upptÀckts;
- att installera (dyra) tjÀnster frÄn företag som enbart tjÀnar pÄ lösningar inom videokommunikation, och jÀmföra deras negativa respons med den vi har.
Dessa tvÄ experiment kommer att hjÀlpa oss att bestÀmma det uppnÄeliga mÄlet och fokusera pÄ det.
Dessutom finns det ett antal uppgifter som löses i det dagliga arbetet:
- vi skapar en teknisk kvalitetsmetrik för kommunikationen istÀllet för subjektiva recensioner;
- vi gör mer detaljerade loggar över sessionerna för att mer noggrant kunna analysera intrÀffande fel, förstÄ nÀr och var de intrÀffade, samt vilka till synes orelaterade hÀndelser som intrÀffade vid det tillfÀllet;
- vi förbereder ett automatiskt test av kommunikationskvaliteten före lektionen, och ger Àven klienten möjlighet att manuellt testa kommunikationen, för att minska antalet negativa upplevelser orsakade av deras hÄrdvara och kanal;
- vi kommer att utveckla och genomföra fler belastningstester av videokommunikation under dÄliga förhÄllanden, med variabel packetförlust osv.;
- vi Àndrar servrarnas beteende vid problem för att öka felresiliensen;
- vi kommer att varna anvÀndaren om det finns nÄgot fel med kommunikationen, precis som Skype gör, sÄ att de förstÄr att problemet ligger pÄ deras sida.
FrÄn och med april blir videokommunikation en helt egen avdelning inom Skyeng, som sysslar med sin egen produkt, och inte bara en del av Vimbox. Det betyder att vi börjar leta efter personer för . Som alltid .
. SjĂ€lvklart fortsĂ€tter vi att aktivt kommunicera med personer och företag som arbetar med videokommunikation. Om du vill dela erfarenheter med oss â vi ser fram emot det! Kommentera, hör av dig â vi svarar alla.
KĂ€lla: habr.com
