Videokonference er den primære kommunikationsmetode mellem underviser og studerende på platformen Vimbox. Vi er længe blevet enige om at stoppe med Skype, har prøvet flere tredjeparters løsninger, og endte til sidst med at anvende WebRTC - Janus-gateway. I noget tid var vi tilfredse, men der dukkede stadig nogle negative punkter op. I sidste ende blev der oprettet en separat afdeling for video.
Jeg bad Kirill Rogovoy, lederen af den nye afdeling, om at fortælle om evolutionen af videokonferencer i Skyeng, om de problemer, der blev opdaget, løsningerne og de hacks, som vi endte med at anvende. Vi håber, at artiklen vil være nyttig for virksomheder, der også forsøger at implementere video gennem deres webapp.
Lidt historie
Sommer 2017 præsenterede udviklingschef for Skyeng, Sergey Safonov, på Backend Conf om, hvordan vi "opgav Skype og implementerede WebRTC". De interesserede kan se optagelsen af præsentationen på (~45 min), og her vil jeg kort opsummere essensen.
For Skyeng var videokonference altid den prioriterede kommunikationsmetode mellem lærer og elev. I starten brugte vi "Skype", men det var uacceptabelt af en række årsager, først og fremmest på grund af manglen på logs og umuligheden af integration direkte i webapplikationen. Derfor foretog vi forskellige eksperimenter.
Faktisk havde vi følgende krav til videokonferencer:
— stabilitet;
— lav pris pr. undervisning;
— optagelse af lektioner;
— sporing af hvem der taler hvornår (det er vigtigt for os, at eleverne taler mere end underviseren i lektionerne);
— lineær skalering;
— mulighed for at bruge både UDP og TCP.
I 2013 prøvede vi først at implementere Tokbox. Det fungerede godt, men det blev meget dyrt - 113 rubler pr. lektion - og det tog en del af indtjeningen.
Derefter, i 2015, integrerede vi Voximplant. Her var den funktion, vi havde brug for, til at spore, hvem der taler hvornår, og samtidig var løsningen betydeligt billigere: hvis vi kun optog lyden, var prisen 20 rubler pr. lektion. Det fungerede dog kun via UDP, det kunne ikke skifte til TCP. Ikke desto mindre brugte omkring 40% af eleverne det.
Et år senere begyndte vi at få erhvervskunder med deres specifikke krav. For eksempel skal alt fungere via browseren, og der er kun åbent for http og https i firmaet; dvs. ingen 'Skype' og UDP. Erhvervskunder = penge, så vi vendte tilbage til Tokbox, men prisproblemet forsvandt ikke.
Løsningen er WebRTC og Janus.
Vi har besluttet at bruge Den håndterer oprettelsen af forbindelser, kodning og dekodning af streams, synkronisering af spor og kvalitetskontrol med håndtering af netværksproblemer. På vores side skal vi sikre, at vi kan læse streams fra kameraet og mikrofonen, tegne videoen, styre forbindelsen, oprette WebRTC-forbindelsen og sende streams til den, samt overføre signalbeskeder mellem kunderne for at etablere forbindelsen (selve WebRTC beskriver kun dataformatet, men ikke transmissionsmekanismen). Hvis kunderne befinder sig bag NAT, forbinder WebRTC med STUN-servere, og hvis det ikke hjælper, bruger den TURN-servere.
Et almindeligt p2p-forbindelse er ikke nok for os, da vi ønsker at optage lektioner til senere analyse i tilfælde af klager. Derfor sender vi WebRTC-streams gennem en relæ. Som resultat kender kunderne ikke adressen på hinanden, men ser kun adressen på Janus-serveren; den fungerer også som signalserver. Janus har mange af de funktioner, vi har brug for: den skifter automatisk til TCP, hvis UDP er blokeret for kunden; den kan optage både UDP- og TCP-streams; den kan skaleres; og der er endda en indbygget plugin til ekkotests. Ved behov tilsluttes STUN og TURN-servere fra Twilio automatisk.
I sommeren 2017 havde vi to Janus-servere i drift plus en ekstra server til behandling af de optagede rå audio- og videofiler for at undgå at belaste processorerne på de primære. Ved tilslutning blev Janus-serverne valgt efter princippet om lige-ulige (forbindelsesnummer). På det tidspunkt var det tilstrækkeligt, og vi følte, at det gav cirka fire gange sikkerhedsmargen, mens implementeringen var omkring 80 procent. Samtidig blev prisen reduceret til cirka 2 rubler per lektion, plus udvikling og support.
Tilbage til emnet videokommunikation.
Vi overvåger konstant feedback fra elever og lærere for hurtigt at identificere og afbøde problemer. I sommeren 2018 blev kvaliteten af forbindelsen fast etableret som det primære klagepunkt. På den ene side betød det, at vi havde haft succes med at håndtere de øvrige mangler. På den anden side var det nødvendigt at handle hurtigt: hvis en lektion blev afbrudt, risikerer vi at miste dens værdi, nogle gange sammen med værdien af at købe det næste pakke, og ved afbrydelse af introduktionsbetalingen kan vi i værste fald miste en potentiel kunde.
På det tidspunkt var vores videoforbindelse stadig i MVP-tilstand. Kort sagt, vi startede, det fungerede, skalerede én gang, fandt ud af, hvordan det skulle gøres – og så var det godt. If it works, don’t fix it. Ingen havde specifikt fokus på kvaliteten af forbindelsen. Inden august blev det klart, at det ikke kunne fortsætte sådan, og vi lancerede en separat afdeling for at finde ud af, hvad der egentlig var galt med WebRTC og Janus.
Indgangen til denne afdeling var: MVP-løsning, ingen målinger, ingen mål, ingen processer til forbedring, samtidig klager 7% af lærerne over forbindelseskvaliteten (data om eleverne var heller ikke tilgængelige).
Den nye afdeling tager fat på opgaverne
Kommandoen ser sådan ud:
- Afdelingslederen, som også er hovedudvikleren.
- QA hjælper med at teste ændringer, leder efter nye måder at skabe ustabile forbindelsesforhold på og rapporterer om problemer fra frontlinjen.
- Analytikeren søger konstant efter forskellige korrelationer i tekniske data, forbedrer analysen af brugerfeedback og tjekker resultaterne af eksperimenter.
- Produktchefen hjælper med den overordnede retning og tildeling af ressourcer til eksperimenter.
- Den anden udvikler hjælper ofte med selve programmeringen og relaterede opgaver.
I starten indstillede vi en relativt pålidelig metrik, der overvågede ændringer i vurderingerne af forbindelseskvaliteten (gennemsnit over dage, uger, måneder). På det tidspunkt var det vurderinger fra lærerne, senere blev der tilføjet vurderinger fra studerende. Derefter begyndte vi at formulere hypoteser om, hvad der ikke fungerede, rette op på det og se på ændringerne i dynamikken. Vi gik efter de lavthængende frugter: for eksempel udskiftede vi codec vp8 med vp9, og resultaterne forbedredes. Vi prøvede at lege med Janus' indstillinger, udføre andre eksperimenter – som i de fleste tilfælde ikke gav resultater.
I det andet trin kom hypotesen frem: WebRTC er en peer-to-peer løsning, men vi bruger en server i midten. Måske ligger problemet her? Vi begyndte at undersøge dette og fandt den mest betydelige forbedring indtil videre.
På det tidspunkt blev serveren valgt fra puljen ved hjælp af en ret simpel algoritme: hver server havde sin egen 'vægt', der afhænger af båndbredde og kapacitet, og vi forsøgte at sende brugeren til den med den højeste 'vægt', uden at tage hensyn til, hvor brugeren geografisk befandt sig. Som et resultat kunne en lærer fra Sankt Petersborg kommunikere med en elev fra Sibirien gennem Moskva, og ikke via vores Janus-server i Sankt Petersborg.
Algoritmen blev redesignet: nu, når brugeren åbner vores platform, indsamler vi ved hjælp af Ajax pingdata fra dem til alle servere. Ved oprettelse af forbindelsen vælger vi et sæt pings (lærer-server og elev-server) med den laveste samlede værdi. Mindre ping betyder mindre netværksafstand til serveren; mindre afstand betyder lavere sandsynlighed for packettab; packettab er den største negative faktor i videokommunikation. Andelen af negativ feedback er faldet med det halve på tre måneder (for retfærdighedens skyld blev der også udført andre eksperimenter i denne periode, men dette har næsten helt sikkert haft den største indflydelse).
For nylig opdagede vi en anden mindre åbenbar, men angiveligt vigtig ting: i stedet for én kraftig Janus-server på en bred forbindelse er det bedre med to mindre servere med lavere båndbredde. Dette blev klart, efter at vi købte potente maskiner i håbet om at kunne rumme så mange rum (kommunikationssessioner) som muligt på én gang. Serverne har en begrænsning for båndbredde, som vi kan oversætte til antal rum — vi ved, hvor mange vi kan åbne, f.eks. ved 300 Mbit/s. Så snart der er åbnet for mange rum på serveren, stopper vi med at vælge den til nye sessioner, indtil belastningen falder. Ideen var, at ved at købe en kraftig maskine ville vi maksimere belastningen på forbindelsen, så vi i stedet ramte begrænsningerne for CPU og hukommelse og ikke båndbredden. Men det viste sig, at efter et bestemt antal åbne rum (420), på trods af at belastningen for CPU, hukommelse og disk stadig var langt fra grænserne, begyndte teknisk support at modtage negative tilbagemeldinger. Angiveligt bliver noget værre inde i Janus, måske er der også nogle begrænsninger der. Vi begyndte at eksperimentere, sænkede båndbredden fra 300 til 200 Mbit/s, og problemerne forsvandt. Nu har vi købt tre nye servere med lavere grænser og specifikationer, vi mener, at dette vil føre til en stabil forbedring af kommunikationskvaliteten. Vi gik ikke ind i detaljerne omkring, hvad der egentlig skete, vi accepterer bare, at vi må kompensere. Til vores forsvar må vi sige, at vi på det tidspunkt skulle løse det presserende problem så hurtigt som muligt og ikke nødvendigvis smukt; desuden er Janus for os en sort boks, skrevet i C, så det er meget dyrt at grave i.
Og i processen gjorde vi:
- opdaterede alle afhængigheder, der kunne opdateres, både på serveren og klienten (disse var også eksperimenter, vi holdt øje med resultaterne);
- rettede alle identificerede fejl, der omhandlede specifikke tilfælde, f.eks. når forbindelsen faldt og ikke genoprettede sig automatisk;
- afholdte adskillige møder med virksomheder, der arbejder inden for videokommunikation og kender vores problemer: dem, der streamer spil, holder webinarer; vi afprøvede alt, hvad vi fandt nyttigt;
- foretog en teknisk gennemgang af udstyret og kvaliteten af forbindelsen hos de lærere, der havde modtaget flest klager.
De gennemførte eksperimenter og de efterfølgende ændringer har gjort det muligt at reducere misfornøjelsen med forbindelsen blandt lærerne fra 7,1% i januar 2018 til 2,5% i januar 2019.
vil være udsolgt
Stabilisering af vores platform Vimbox er et af virksomhedens hovedprojekter for 2019. Vi har store forhåbninger om at bevare dynamikken og ikke længere se videoforbindelse på toppen af klagerne. Vi forstår, at en betydelig del af disse klager er relateret til brugernes computer- og internetlag, men vi skal identificere denne del og løse alt andet. Alt andet er et teknisk problem, som vi bør kunne håndtere.
Den største udfordring er, at vi ikke ved, hvor meget vi reelt kan forbedre kvaliteten. At finde denne grænse er den vigtigste opgave. Derfor er to eksperimenter planlagt:
- sammenligne video via Janus med almindelig p2p i realtid. Dette eksperiment er allerede udført, og der blev ikke fundet statistisk signifikante forskelle mellem vores løsning og p2p;
- vi vil installere (dyre) tjenester fra virksomheder, der kun leverer løsninger inden for videoforbindelser, og sammenligne mængden af negativ respons fra dem med den nuværende.
Disse to eksperimenter vil gøre det muligt for os at fastslå et opnåeligt mål og fokusere på det.
Derudover er der en række opgaver, der løses i arbejderækkefølge:
- vi skaber en teknisk måling af forbindelseskvalitet i stedet for subjektive anmeldelser;
- vi laver mere detaljerede session logs for bedre at analysere opståede fejl, forstå hvornår og hvor de præcist opstod, og hvilke tilsyneladende urelaterede hændelser der fandt sted på det tidspunkt;
- vi forbereder en automatisk test af forbindelseskvaliteten før lektionen, og giver også kunden mulighed for manuelt at teste forbindelsen for at reducere mængden af negative anmeldelser forårsaget af hans hardware og kanal;
- vi vil udvikle og gennemføre flere belastningstests af videoforbindelser under dårlige forhold, med variabel pakktab osv.;
- vi ændrer servernes adfærd i tilfælde af problemer for at øge fejltolerance;
- vi vil advare brugeren, hvis der generelt er noget galt med forbindelsen, som det gøres af Skype, så han forstår, at problemet er på hans side.
Fra april bliver videokommunikation et fuldt udskilt projekt inden for Skyeng, der fokuserer på sit eget produkt, ikke blot en del af Vimbox. Det betyder, at vi begynder at lede efter folk til . Som altid .
Og selvfølgelig fortsætter vi med aktivt at kommunikere med folk og virksomheder, der arbejder med videokommunikation. Hvis du ønsker at dele erfaringer med os - vil vi være glade! Kommenter, kontakt os - vi svarer alle.
Kilde: habr.com
