La videocomunicazione è il principale modo di interazione tra insegnante e studente sulla piattaforma Vimbox. Abbandonando a lungo Skype, abbiamo testato diverse soluzioni esterne e alla fine ci siamo orientati su una combinazione di WebRTC e Janus-gateway. Per un certo periodo tutto ha funzionato bene, ma alcuni aspetti negativi continuavano a emergere. Alla fine, è stato creato un settore dedicato al video.
Ho chiesto a Kirill Rogovoy, il responsabile del nuovo settore, di raccontare l'evoluzione della videocomunicazione in Skyeng, i problemi riscontrati, le soluzioni e le soluzioni temporanee che abbiamo quindi applicato. Speriamo che l'articolo sia utile anche per le aziende che stanno implementando video tramite web application.
Un po' di storia
Nell'estate del 2017, il capo dello sviluppo di Skyeng, Sergey Safonov, ha partecipato al Backend Conf parlando di come abbiamo "abbandonato Skype e implementato WebRTC". Chi desidera può vedere la registrazione della presentazione a (~45 min), mentre qui riassumo brevemente il suo contenuto.
Per la scuola Skyeng, la videochiamata è sempre stata il modo prioritario per comunicare tra insegnante e studente. Inizialmente abbiamo utilizzato "Skype", ma questo non soddisfaceva affatto le nostre esigenze per diversi motivi, in particolare per la mancanza di log e l'impossibilità di integrazione diretta nell'applicazione web. Di conseguenza, abbiamo condotto vari esperimenti.
In sostanza, i nostri requisiti per la videochiamata erano più o meno i seguenti:
— stabilità;
— basso costo per lezione;
— registrazione delle lezioni;
— monitoraggio di quanto ciascuno parla (è importante per noi che gli studenti parlino di più durante le lezioni rispetto all'insegnante);
— scalabilità lineare;
— possibilità di utilizzare sia UDP che TCP.
Il primo a essere sperimentato nel 2013 è stato Tokbox. Andava bene, ma risultava molto costoso – 113 rubli per lezione – e riduceva i profitti.
Poi, nel 2015, abbiamo integrato Voximplant. Qui era presente la funzione di monitoraggio richiesta, ed era anche significativamente più economico: con la registrazione solo dell'audio costava 20 rubli per lezione. Tuttavia, funzionava solo tramite UDP e non sapeva passare a TCP. Nonostante ciò, circa il 40% degli studenti lo utilizzava.
Dopo un anno, abbiamo iniziato ad avere clienti aziendali con requisiti specifici. Ad esempio, tutto deve funzionare tramite browser, e in azienda sono aperti solo http e https; quindi niente «Skype» e UDP. Clienti aziendali = denaro, quindi siamo tornati a Tokbox, ma il problema dei costi non è sparito.
La soluzione è WebRTC e Janus
Abbiamo deciso di utilizzare . Essa è responsabile della creazione della connessione, della codifica e decodifica dei flussi, della sincronizzazione delle tracce e del controllo della qualità con gestione delle anomalie di rete. Da parte nostra, dobbiamo garantire la lettura dei flussi da fotocamera e microfono, la visualizzazione video, la gestione della connessione, l'instaurazione della connessione WebRTC e la trasmissione dei flussi, oltre alla trasmissione dei messaggi di segnalazione tra i client per stabilire la connessione (WebRTC descrive solo il formato dei dati, non il meccanismo per la loro trasmissione). Nel caso in cui i client siano dietro NAT, WebRTC connette server STUN; se questo non aiuta, server TURN.
Una connessione p2p normale non è sufficiente, poiché vogliamo registrare le lezioni per un'analisi futura in caso di reclami. Quindi, inoltriamo 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; quest'ultimo funge anche da server di segnalazione. Janus ha molte funzionalità utili: passa automaticamente a TCP se il client ha bloccato UDP; è in grado di registrare flussi sia UDP che TCP; è scalabile; e ha anche un plugin incorporato per test di eco. Se necessario, i server STUN e TURN di Twilio vengono connessi automaticamente.
Nell'estate del 2017 avevamo due server Janus attivi più un server aggiuntivo per elaborare i file audio e video grezzi registrati, in modo da non occupare i processori dei server principali. Durante la connessione, i server Janus venivano selezionati secondo un principio di pari-dispari (numero di connessione). A quel tempo, questo era sufficiente, dando una percezione di circa quattro volte di margine di sicurezza, con una percentuale di implementazione di circa l'80. Inoltre, il costo era ridotto a ~2 rubli per lezione, più lo sviluppo e la manutenzione.
Ritorniamo al tema della videocomunicazione
Monitoriamo costantemente il feedback degli studenti e dei docenti per identificare tempestivamente e affrontare i problemi. Nel 2018, la qualità della connessione si è attestata tra le principali lamentele. Da un lato, ciò significava che eravamo riusciti a risolvere altri difetti. Dall'altro, c'era bisogno di agire rapidamente: se una lezione viene interrotta, rischiamo di perdere il suo valore, a volte insieme al costo dell'acquisto del pacchetto successivo, e se un incontro introduttivo viene interrotto, rischiamo di perdere un cliente potenziale.
All'epoca, il nostro servizio di videoconferenza era ancora in modalità MVP. In parole semplici, lo abbiamo lanciato, ha funzionato, lo abbiamo scalato una volta, abbiamo capito come farlo — ecco fatto. If it works, don’t fix it. Nessuno si è concentrato specificamente sulla qualità della connessione. A agosto, è diventato chiaro che non poteva continuare così, e abbiamo avviato un percorso separato per capire cosa non andava con WebRTC e Janus.
All'inizio, questo percorso ha ricevuto: soluzione MVP, nessuna metrica, nessun obiettivo, nessun processo di miglioramento, mentre il 7% degli insegnanti lamentava problemi di qualità della connessione (non avevamo dati sugli studenti).
Una nuova direzione viene avviata.
Il comando è più o meno così:
- Il responsabile della direzione, che è anche il principale sviluppatore.
- I QA aiutano a testare le modifiche, cercando nuovi modi per creare condizioni instabili per la connessione, segnalano problemi dalla linea del fronte.
- L'analista cerca continuamente 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.
- Per quanto riguarda la programmazione e i compiti correlati, spesso aiuta un secondo sviluppatore.
Inizialmente, abbiamo impostato metriche relativamente affidabili per monitorare i cambiamenti nella qualità della connessione (media giornaliera, settimanale, mensile). All'epoca, si trattava di valutazioni da parte degli insegnanti, in seguito sono state integrate anche quelle degli studenti. Poi abbiamo iniziato a formulare ipotesi su ciò che non funzionava, correggere e osservare i cambiamenti nella dinamica. Abbiamo puntato ai frutti a bassa difficoltà: ad esempio, abbiamo sostituito il codec vp8 con vp9, ottenendo risultati migliori. Abbiamo anche provato a giocare con le impostazioni di Janus e a condurre altri esperimenti, che nella maggior parte dei casi non hanno portato a risultati.
Nella seconda fase è emersa l'ipotesi: WebRTC è una soluzione peer-to-peer, mentre noi utilizziamo un server intermedio. Forse il problema risiede qui? Abbiamo iniziato a scavare e abbiamo trovato qui il miglioramento più significativo fino ad ora.
In quel momento, il server veniva selezionato da un pool tramite un algoritmo piuttosto ingenuo: ognuno aveva un proprio 'peso', che dipendeva dalla larghezza di banda e dalla potenza, e cercavamo di indirizzare l'utente verso quello con 'peso' maggiore, senza prestare attenzione alla posizione geografica dell'utente. Di conseguenza, un insegnante da San Pietroburgo poteva comunicare con uno studente dalla Siberia attraverso Mosca, invece che tramite il nostro server Janus a San Pietroburgo.
L'algoritmo è stato rielaborato: ora, quando l'utente apre la nostra piattaforma, raccogliamo i ping da lui verso tutti i server grazie ad Ajax. Quando si stabilisce una connessione, selezioniamo una coppia di ping (server insegnante e server allievo) con la somma più bassa. Ping più basso significa distanza di rete minore dal server; distanza minore traduce in una minore probabilità di perdita di pacchetti; la perdita di pacchetti è il fattore negativo più grande nelle comunicazioni video. La quota di negatività è scesa della metà in tre mesi (a dire il vero, in questo periodo sono stati condotti anche altri esperimenti, ma questo ha probabilmente avuto il maggiore impatto).
Recentemente abbiamo scoperto un altro aspetto non ovvio ma, a quanto pare, importante: invece di un potente server Janus su una banda larga, è meglio avere due server più semplici con capacità inferiore. Questo è emerso dopo aver acquistato questi potenti macchine nella speranza di gestire il maggior numero possibile di stanze (sessioni) contemporaneamente. I server hanno un limite di capacità che possiamo tradurre esattamente nel numero di stanze - sappiamo quante possono essere aperte, ad esempio, su una connessione di 300 Mbit/s. Non appena su un server vengono aperte troppe stanze, smettiamo di sceglierlo per nuove sessioni fino a quando il carico non diminuisce. L'idea era che, acquistando una macchina potente, avremmo saturato al massimo la banda, in modo da raggiungere un collo di bottiglia nel processore e nella memoria, piuttosto che nella capacità di banda. Ma è emerso 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 iniziava a ricevere segnalazioni negative. A quanto pare, qualcosa peggiora all'interno di Janus, probabilmente ci sono delle limitazioni anche lì. Abbiamo iniziato a fare esperimenti, abbiamo abbassato il limite di capacità da 300 a 200 Mbit/s e i problemi sono scomparsi. Ora abbiamo acquistato tre nuovi server con limiti e caratteristiche non elevate, speriamo che questo porti a un miglioramento stabile della qualità della connessione. Non ci siamo messi a capire cos'era successo, dopotutto, le soluzioni rapide sono il nostro forte. A nostra discolpa possiamo dire che in quel momento era necessario risolvere rapidamente un problema urgente, piuttosto che farlo in modo elegante; inoltre, Janus per noi è una scatola nera scritta in C, rovistare al suo interno è molto costoso.
Inoltre, durante il processo abbiamo:
- aggiornato tutte le dipendenze che potevano essere aggiornate, sia sul server che sul client (anche questi erano esperimenti, monitoravamo i risultati);
- risolto tutti i bug identificati, relativi a situazioni specifiche, ad esempio quando la connessione si interrompeva e non si ripristinava automaticamente;
- tenuto numerosi incontri con aziende che operano nel campo della videoconferenza e che erano a conoscenza dei nostri problemi: streaming di giochi, organizzazione di webinar; abbiamo testato tutto ciò che ci è sembrato utile;
- effettuato una revisione tecnica dell'hardware e della qualità della connessione degli insegnanti da cui provenivano il maggior numero di reclami.
Gli esperimenti condotti e i successivi cambiamenti hanno permesso di ridurre il malcontento riguardo alla connessione tra gli insegnanti dal 7,1% di gennaio 2018 al 2,5% di gennaio 2019.
Cosa succede dopo
La stabilizzazione della nostra piattaforma Vimbox è uno dei principali progetti dell'azienda per il 2019. Abbiamo grandi speranze di mantenere la dinamica e di non vedere più le videochiamate in cima alle lamentele. Comprendiamo che una parte significativa di queste lamentele è legata ai lag dei computer e di internet degli utenti, ma dobbiamo identificare questa parte e risolvere tutto il resto. Tutto il resto è un problema tecnico, e sembra che dovremmo saperlo affrontare.
La principale difficoltà è che non sappiamo fino a che livello sia realmente possibile migliorare la qualità. Determinare questo tetto è la nostra principale sfida. Per questo motivo sono stati programmati due esperimenti:
- confrontare il video tramite Janus con una normale connessione p2p in condizioni reali. Questo esperimento è già stato condotto, e non è stata riscontrata alcuna differenza statisticamente significativa tra la nostra soluzione e il p2p;
- utilizzare servizi (costosi) da aziende che guadagnano esclusivamente con soluzioni nel campo delle videochiamate e confrontare il numero di lamentele ricevute con quelle attuali.
Questi due esperimenti ci permetteranno di identificare un obiettivo raggiungibile e di concentrarci su di esso.
Inoltre, ci sono una serie di compiti da affrontare nell'ambito del lavoro quotidiano:
- creiamo una metrica tecnica della qualità della connessione invece di feedback soggettivi;
- facciamo registrazioni di sessioni più dettagliate per analizzare con precisione i guasti che si verificano, comprendendo quando e dove sono accaduti e quali eventi apparentemente non correlati si sono verificati in quel momento;
- prepariamo un test automatico della qualità della connessione prima della lezione e daremo la possibilità al cliente di testare manualmente la connessione per ridurre il numero di feedback negativi causati dal suo hardware e dalla sua connessione;
- svilupperemo e condurremo più test di carico per videoconferenze in cattive condizioni, con perdita di pacchetti variabile, ecc.;
- modifichiamo il comportamento dei server in caso di problemi per aumentare l'affidabilità;
- avviseremo l'utente se ci sono problemi con la connessione, come fa Skype, in modo che comprenda che il problema è dalla sua parte.
Da aprile, il settore delle videoconferenze diventa un progetto a sé stante all'interno di Skyeng, dedicato a un prodotto proprio, non semplicemente una parte di Vimbox. Ciò significa che iniziamo a cercare persone per . E come sempre .
E, naturalmente, continuiamo a comunicare attivamente con persone e aziende che lavorano con la videocomunicazione. Se vuoi condividere esperienze con noi, saremo felici di farlo! Commenta, contattaci e risponderemo a tutti.
Fonte: habr.com
