La videocomunicazione è il principale modo di comunicare tra insegnante e studente sulla piattaforma Vimbox. Da tempo abbiamo abbandonato Skype, sperimentato diverse soluzioni di terze parti e alla fine ci siamo fermati sulla combinazione WebRTC - Janus-gateway. Per un certo periodo siamo stati soddisfatti, ma alcuni aspetti negativi continuavano a emergere. Alla fine, è stato creato un dipartimento separato per i video.
Ho chiesto a Kirill Rogovoy, il responsabile del nuovo dipartimento, di raccontare l'evoluzione della videocomunicazione in Skyeng, i problemi riscontrati, le soluzioni e i workaround che alla fine abbiamo adottato. Speriamo che l'articolo sia utile per le aziende che stanno affrontando in autonomia la video comunicazione attraverso un'app web.
Un po' di storia
Nell'estate del 2017, il responsabile dello sviluppo di Skyeng, Sergey Safonov, ha partecipato al Backend Conf parlando di come abbiamo "abbandonato Skype e implementato WebRTC". Chi è interessato può vedere la registrazione dell'intervento su (~45 min), qui riassumerò brevemente i punti salienti.
Per la scuola Skyeng, la videocomunicazione è sempre stata un modo prioritario di interazione tra insegnante e studente. Inizialmente utilizzavamo Skype, ma non era affatto soddisfacente per una serie di motivi, principalmente per la mancanza di log e l'impossibilità di integrazione direttamente nell'applicazione web. Pertanto, abbiamo condotto vari esperimenti.
Le nostre esigenze per la videocomunicazione erano più o meno le seguenti:
— stabilità;
— costo ridotto per lezione;
— registrazione delle lezioni;
— monitoraggio di quanto parla ciascuno (è importante per noi che gli studenti parlino di più durante le lezioni rispetto all'insegnante);
— scalabilità lineare;
— possibilità di utilizzare sia UDP che TCP.
Nel 2013 abbiamo provato per primi a implementare Tokbox. Andava tutto bene, ma risultava molto costoso: 113 rubli per lezione – e riduceva i profitti.
Poi, nel 2015, abbiamo integrato Voximplant. Qui c'era la funzione necessaria per monitorare quanto parlava ciascuno, e in più la soluzione era significativamente più economica: con solo la registrazione audio si arrivava a 20 rubli per lezione. Tuttavia, funzionava solo attraverso UDP, non era in grado di passare a TCP. Tuttavia, alla fine circa il 40% degli studenti la utilizzava.
Dopo un anno abbiamo iniziato ad avere clienti aziendali con requisiti specifici. Ad esempio, tutto deve funzionare attraverso il browser, in azienda sono aperti solo http e https; ovvero, niente «Skype» e UDP. Clienti aziendali = denaro, quindi siamo tornati a Tokbox, ma il problema del prezzo era ancora presente.
La soluzione — WebRTC e Janus
Abbiamo deciso di utilizzare . Si occupa dell'instaurazione della connessione, della codifica e decodifica dei flussi, della sincronizzazione delle tracce e del controllo della qualità trattando le problematiche di rete. Da parte nostra, dobbiamo garantire la cattura dei flussi dalla videocamera e dal microfono, il rendering video, la gestione della connessione, l'instaurazione della connessione WebRTC e la trasmissione dei flussi, oltre alla comunicazione dei messaggi di segnalazione tra i client per stabilire la connessione (WebRTC descrive solo il formato dei dati, ma non il meccanismo per la loro trasmissione). Nel caso in cui i client siano dietro un NAT, WebRTC collega i server STUN, se questo non aiuta, i server TURN.
Una normale connessione p2p non è sufficiente, poiché vogliamo registrare le lezioni per ulteriori analisi in caso di reclami. Pertanto, inviamo i flussi WebRTC tramite un relay . Di conseguenza, i client non conoscono gli indirizzi l'uno dell'altro, vedendo solo l'indirizzo del server Janus; questo svolge anche le funzioni di server di segnalazione. Janus ha molte delle funzionalità di cui abbiamo bisogno: passa automaticamente a TCP se il client blocca UDP; può registrare flussi sia UDP che TCP; è scalabile; c'è persino un plugin integrato per test di eco. Se necessario, i server STUN e TURN di Twilio si connettono automaticamente.
Nell'estate del 2017 avevamo in funzione due server Janus più un server aggiuntivo per l'elaborazione dei file audio e video grezzi registrati, in modo da non sovraccaricare i processori principali. Con il collegamento, i server Janus venivano selezionati in base al principio pari-dispari (numero di connessione). A quel tempo, ciò era sufficiente e ci dava un margine di sicurezza di circa quattro volte, con un tasso di implementazione del 80%. Inoltre, il costo è sceso a ~2 rubli per lezione, più lo sviluppo e il supporto.
Ritorno al tema della videocomunicazione
Monitoriamo costantemente il feedback degli studenti e degli insegnanti per identificare e affrontare tempestivamente i problemi. Entro l'estate del 2018, la qualità della connessione si era consolidata al primo posto tra le lamentele. Da un lato, ciò significava che eravamo riusciti a risolvere altre carenze. D'altro canto, era urgente fare qualcosa: in caso di un'interruzione della lezione, rischiamo di perdere il valore di essa, a volte insieme al costo dell'acquisto del pacchetto successivo, e in caso di interruzione della lezione introduttiva, potremmo addirittura perdere un cliente potenziale.
A quel tempo, la videoconferenza era ancora in modalità MVP. In altre parole, l'abbiamo lanciata, ha funzionato, l'abbiamo scalato una volta, abbiamo capito come farlo – e così è andata bene. If it works, don’t fix it. Nessuno si occupava in modo specifico della questione della qualità della connessione. A agosto, era chiaro che non si poteva continuare così e abbiamo avviato un'area separata per capire cosa non andasse con WebRTC e Janus.
In ingresso, questa area ricevette: soluzione MVP, nessuna metrica, nessun obiettivo, nessun processo di miglioramento, mentre il 7% degli insegnanti lamentava problemi con la qualità della connessione (dati sugli studenti non erano disponibili).
La nuova area inizia il lavoro
Il comando appare più o meno così:
- Il responsabile dell'area, anche sviluppatore principale.
- Il QA aiuta a testare le modifiche, cerca nuovi modi per creare condizioni instabili per la connessione e segnala i problemi dalla linea del fronte.
- L'analista cerca costantemente diverse correlazioni nei dati tecnici, migliora l'analisi del feedback degli utenti e verifica i risultati degli esperimenti.
- Il product manager aiuta con la direzione generale e l'allocazione delle risorse per gli esperimenti.
- Il secondo sviluppatore spesso aiuta con la programmazione e compiti correlati.
Per cominciare, abbiamo impostato una metrica abbastanza affidabile per monitorare le variazioni nella valutazione della qualità della connessione (media per giorni, settimane, mesi). In quel momento, si trattava di valutazioni da parte degli insegnanti, successivamente abbiamo aggiunto le valutazioni degli studenti. In seguito, abbiamo iniziato a formulare ipotesi su cosa non funzionasse, a correggere e a osservare le variazioni nel tempo. Abbiamo iniziato con i frutti più a portata di mano: ad esempio, abbiamo sostituito il codec vp8 con vp9 e i risultati sono migliorati. Abbiamo provato a giocarci con le impostazioni di Janus e a condurre altri esperimenti – che in maggioranza non hanno portato a nulla.
Nella seconda fase è emersa l'ipotesi: WebRTC è una soluzione peer-to-peer, ma noi utilizziamo un server intermedio. Forse il problema risiede qui? Abbiamo iniziato a indagare e abbiamo trovato qui il miglioramento più significativo finora.
In quel momento, il server veniva scelto da un pool con un algoritmo piuttosto rudimentale: ognuno aveva un proprio "peso", che dipendeva dal canale e dalla potenza, e cercavamo di indirizzare l'utente a quello con un "peso" maggiore, senza prestare attenzione a dove si trovava geograficamente l'utente. Di conseguenza, un insegnante di San Pietroburgo poteva comunicare con uno studente siberiano passando per Mosca, invece che attraverso il nostro server Janus a San Pietroburgo.
Abbiamo rielaborato l'algoritmo: ora, quando un utente apre la nostra piattaforma, raccogliamo tramite Ajax i ping da lui verso tutti i server. Durante l'instaurazione della connessione, selezioniamo una coppia di ping (insegnante-server e studente-server) con la somma più bassa. Meno ping significa minore distanza di rete dal server; minore distanza implica una minor probabilità di perdere pacchetti; la perdita di pacchetti è il maggior fattore negativo nelle comunicazioni video. La percentuale di negatività è diminuita di due volte in tre mesi (per dire il vero, in quel periodo sono stati condotti anche altri esperimenti, ma questo ha quasi certamente avuto il maggiore impatto).
Recentemente abbiamo scoperto un'altra cosa non ovvia, ma apparentemente importante: invece di un potente server Janus su un canale spesso, è meglio avere due server più semplici con una capacità di banda più bassa. Questo è emerso dopo aver acquistato macchine potenti con la speranza di ospitare quante più stanze (sessioni di comunicazione) possibile contemporaneamente. I server hanno un limite di capacità che possiamo tradurre con precisione in numero di stanze: sappiamo quante possiamo aprire, ad esempio, su 300 Mbps. Non appena sul server vengono aperte troppe stanze, smettiamo di utilizzarlo per nuove sessioni finché il carico non diminuisce. L'idea era che, acquistando una macchina potente, avremmo saturato la banda fino al massimo, per poi arrivare a limitazioni del processore e della memoria, e non della capacità di banda. Ma si è scoperto che dopo un certo numero di stanze aperte (420), nonostante il carico di CPU, memoria e disco fosse ancora lontano dai limiti, il supporto tecnico cominciava a ricevere segnalazioni negative. A quanto pare, qualcosa all'interno di Janus peggiorava; forse ci sono dei limiti anche lì. Abbiamo iniziato a sperimentare, diminuendo il limite di banda da 300 a 200 Mbps, e i problemi sono scomparsi. Ora abbiamo acquistato tre nuovi server con limiti e caratteristiche non elevate, speriamo che questo porti a un miglioramento costante della qualità della comunicazione. Non ci siamo messi a indagare sulle cause del problema; le soluzioni temporanee sono il nostro forte. A nostra difesa, diciamo che in quel momento era necessario risolvere rapidamente un problema urgente, e non farlo in modo elegante; inoltre, Janus per noi è una scatola nera scritta in C, e approfondire ogni aspetto sarebbe molto costoso.
Nel processo abbiamo:
- aggiornato tutte le dipendenze che era possibile aggiornare, sia sul server che sul client (questi sono stati anch'essi esperimenti, seguiti con attenzione);
- risolto tutti i bug identificati riguardanti casi specifici, ad esempio quando la connessione cadeva e non si ripristinava automaticamente;
- tenuto numerosi incontri con aziende operanti nel campo della videocomunicazione e familiari con i nostri problemi: quelle che fanno streaming di giochi, tengono webinar; abbiamo testato tutto ciò che ci è sembrato utile;
- condotto una revisione tecnica dell'hardware e della qualità della comunicazione con gli insegnanti, dai quali provenivano il maggior numero di lamentele.
Gli esperimenti condotti e i cambiamenti successivi hanno permesso di ridurre il malcontento legato alla connessione tra gli insegnanti dal 7,1% di gennaio 2018 al 2,5% di gennaio 2019.
E ora?
La stabilizzazione della nostra piattaforma Vimbox è uno dei principali progetti dell'azienda per il 2019. Abbiamo grandi speranze di riuscire a mantenere questa tendenza e di non vedere più le videochiamate in cima alle lamentele. Comprendiamo che una parte significativa di queste lamentele è legata ai ritardi dei computer e di internet degli utenti, ma dobbiamo identificare questa parte e risolvere tutto il resto. Tutto il resto è un problema tecnico, sembra che dobbiamo essere in grado di gestirlo.
La principale difficoltà è che non sappiamo fino a che livello sia realmente possibile migliorare la qualità. Determinare questo limite è il compito principale. Pertanto, sono stati pianificati due esperimenti:
- confrontare il video tramite Janus con il tradizionale p2p in condizioni reali. Questo esperimento è già stato condotto, non è stata rilevata alcuna differenza statisticamente significativa tra la nostra soluzione e il p2p;
- installeremo (costosi) servizi di aziende che guadagnano esclusivamente con soluzioni nel campo delle videochiamate e confronteremo il loro numero di feedback negativi con quelli attuali.
Questi due esperimenti ci permetteranno di definire un obiettivo raggiungibile e di concentrarci su di esso.
Inoltre, ci sono diverse attività che vengono risolte nel lavoro quotidiano:
- stiamo creando una metrica tecnica di qualità della connessione al posto delle recensioni soggettive;
- stiamo generando log delle sessioni più dettagliati, per analizzare più accuratamente i guasti, capire quando e dove sono avvenuti, quali eventi apparentemente non correlati si sono verificati in quel momento;
- prepariamo un test automatico della qualità della connessione prima della lezione e daremo al cliente la possibilità di testare manualmente la connessione, per ridurre il numero di lamentele causate dal suo hardware e dalla sua connessione;
- svilupperemo e eseguiremo più test di carico per le videochiamate in condizioni difficili, con perdita di pacchetti variabile, ecc.;
- modificheremo il comportamento dei server in caso di problemi per aumentare la resilienza;
- avviseremo l'utente se ci sono problemi con la connessione, proprio come fa Skype, affinché comprenda che il problema è dalla sua parte.
A partire da aprile, la direzione della videocomunicazione diventa un progetto autonomo all'interno di Skyeng, dedicato a un prodotto proprio, non solo una parte di Vimbox. Questo significa che iniziamo a cercare persone per . E come sempre .
E, naturalmente, continuiamo a comunicare attivamente con persone e aziende che operano nel campo della videocomunicazione. Se vuoi condividere la tua esperienza con noi, saremo felici! Commenta, contattaci — risponderemo a tutti.
Fonte: habr.com
