Las videollamadas son la forma principal en que los profesores y los estudiantes se comunican en la plataforma Vimbox. Abandonamos Skype hace mucho tiempo, probamos varias soluciones de terceros y finalmente nos decidimos por un mont贸n de WebRTC: Janus-gateway. Por un tiempo, todo estuvo bien con nosotros, pero a煤n as铆 algunos puntos negativos continuaron reptando. Como resultado, se cre贸 una direcci贸n de video separada.
Le ped铆 a Kirill Rogovoy, jefe de la nueva direcci贸n, que hablara sobre la evoluci贸n de las comunicaciones de video en Skyeng, los problemas, las soluciones y las muletas que eventualmente aplicamos. Esperamos que este art铆culo sea 煤til para las empresas que tambi茅n hacen videos por su cuenta a trav茅s de una aplicaci贸n web.
Un poco de historia
En el verano de 2017, Sergey Safonov, jefe de desarrollo de Skyeng, habl贸 en Backend Conf sobre c贸mo "abandonamos Skype e implementamos WebRTC". Aquellos que lo deseen pueden ver la grabaci贸n de la actuaci贸n por referencia (~ 45 min), pero aqu铆 resumir茅 brevemente su esencia.
Para Skyeng, la comunicaci贸n por video siempre ha sido un m茅todo de comunicaci贸n maestro-alumno prioritario. Al principio, se us贸 Skype, pero categ贸ricamente no era adecuado por varias razones, principalmente debido a la falta de registros y la incapacidad de integrarse directamente en la aplicaci贸n web. Por lo tanto, realizamos todo tipo de experimentos.
En realidad, los requisitos para la comunicaci贸n por video fueron aproximadamente los siguientes:
- estabilidad;
- bajo precio por clase;
- grabaci贸n de lecciones;
- rastrear qui茅n dice cu谩nto (es importante para nosotros que los estudiantes hablen m谩s en el aula que el profesor);
- escala lineal;
- La capacidad de usar tanto UDP como TCP.
El primero en 2013 intent贸 implementar Tokbox. Todo estaba bien, pero result贸 muy costoso, 113 rublos por lecci贸n, y se comi贸 la ganancia.
Luego, en 2015, se integr贸 Voximplant. Aqu铆 estaba la funci贸n de seguimiento que necesit谩bamos, qui茅n dice cu谩nto y, al mismo tiempo, la soluci贸n era mucho m谩s barata: siempre que solo se grabara el sonido, sal铆an 20 rublos por lecci贸n. Sin embargo, funcionaba solo a trav茅s de UDP; cambiar a TCP no era una habilidad. Sin embargo, al final, alrededor del 40% de los estudiantes lo usaron.
Un a帽o despu茅s, los clientes corporativos comenzaron a aparecer con sus requisitos espec铆ficos. Por ejemplo, todo deber铆a funcionar a trav茅s de un navegador, solo http y https est谩n abiertos en la empresa; es decir, no Skype y UDP. Clientes corporativos = dinero, por lo que regresaron a Tokbox, pero el problema del precio no ha desaparecido.
Soluci贸n - WebRTC y Janus
Decidimos usar la plataforma del navegador para comunicaciones de video punto a punto WebRTC . Es responsable de establecer conexiones, codificar y decodificar secuencias, sincronizar pistas y controlar la calidad con el procesamiento de fallas en la red. Por nuestra parte, debemos asegurarnos de que se lean los flujos de la c谩mara y el micr贸fono, se dibuje el video, se establezca la conexi贸n, se establezca la conexi贸n WebRTC y se transmitan los flujos, as铆 como la transmisi贸n de mensajes de se帽al entre los clientes para establecer la conexi贸n (el propio WebRTC describe solo el formato de datos, pero no su mecanismo transmisi贸n). En caso de que los clientes est茅n detr谩s de NAT, WebRTC conecta los servidores STUN, si esto no ayuda, los servidores TURN.
La conexi贸n p2p habitual no es suficiente para nosotros, porque queremos grabar lecciones para su posterior an谩lisis en caso de quejas. Por lo tanto, enviamos transmisiones WebRTC a trav茅s del repetidor Janus Gateway de Meetecho . Como resultado, los clientes no conocen las direcciones de los dem谩s y solo ven la direcci贸n del servidor Janus; Tambi茅n realiza las funciones de un servidor de se帽ales. Janus tiene muchas caracter铆sticas que necesitamos: cambia autom谩ticamente a TCP si UDP est谩 bloqueado en el cliente; capaz de grabar secuencias de UDP y TCP; escalable Incluso hay un complemento incorporado para las pruebas de eco. Si es necesario, los servidores STUN y TURN de Twilio se conectan autom谩ticamente.
En el verano de 2017, ten铆amos dos servidores Janus, m谩s un servidor adicional para procesar archivos de audio y video en bruto grabados, para no ocupar los procesadores principales. Al conectarse, los servidores Janus se seleccionaron de manera impar (n煤mero de conexi贸n). En ese momento, esto era suficiente, de acuerdo con nuestros sentimientos, daba alrededor de cuatro veces el margen de seguridad, el porcentaje de implementaci贸n era de aproximadamente 80. Al mismo tiempo, el precio baj贸 a ~ 2 rublos por lecci贸n, m谩s desarrollo y soporte.
Regrese al tema de las videollamadas
Monitoreamos constantemente los comentarios de los estudiantes y maestros para identificar y detener los problemas a tiempo. Para el verano de 2018, en primer lugar entre las quejas, la calidad de la comunicaci贸n estaba firmemente arraigada. Por un lado, esto significaba que hab铆amos tratado con 茅xito otras deficiencias. Por otro lado, hab铆a una necesidad urgente de hacer algo: si se rompe la lecci贸n, corremos el riesgo de perder su costo, a veces junto con el costo de comprar el siguiente paquete, y si se pierde la lecci贸n introductoria, perdemos al cliente potencial por completo.
En ese momento, la comunicaci贸n por video todav铆a estaba en modo MVP. En pocas palabras, lo lanzaron, funcion贸, escalaron una vez, descubrieron c贸mo hacerlo, bueno, eso es bueno. Si funciona, no lo arregles. Nadie trat贸 deliberadamente el tema de la calidad de la comunicaci贸n. En agosto, qued贸 claro que esto no pod铆a continuar m谩s, y lanzamos un 谩rea separada para descubrir qu茅 estaba pasando con WebRTC y Janus.
En la entrada, esta direcci贸n recibi贸: soluci贸n MVP, sin m茅tricas, sin objetivos, sin procesos de mejora, mientras que el 7% de los maestros se quejan de la calidad de la comunicaci贸n (tampoco hubo datos sobre los estudiantes).
Se toma una nueva direcci贸n para el trabajo
El comando se ve as铆:
- El jefe de la direcci贸n, 茅l es el desarrollador principal.
- QA ayuda a probar los cambios, busca nuevas formas de crear condiciones inestables para la comunicaci贸n, informa problemas desde la primera l铆nea.
- El analista busca constantemente diferentes correlaciones en los datos t茅cnicos, mejora el an谩lisis de los comentarios de los usuarios, verifica los resultados de los experimentos.
- El gerente de producto ayuda con la direcci贸n general y la asignaci贸n de recursos para experimentos.
- Con la programaci贸n misma y las tareas relacionadas, un segundo desarrollador a menudo ayuda.
Para comenzar, establecimos una m茅trica relativamente confiable que rastre贸 los cambios en la evaluaci贸n de la calidad de la comunicaci贸n (promedio por d铆as, semanas, meses). En ese momento, estas eran calificaciones de los maestros, y se les agregaron calificaciones adicionales de los estudiantes. Luego comenzaron a construir hip贸tesis de lo que no funciona, para corregir y observar los cambios en la din谩mica. Optamos por frutas bajas: por ejemplo, reemplazamos el c贸dec vp8 con vp9, el rendimiento mejor贸. Intentamos jugar con la configuraci贸n de Janus, realizar otros experimentos, en la mayor铆a de los casos, sin resultado.
En la segunda etapa, apareci贸 una hip贸tesis: WebRTC es una soluci贸n punto a punto, y usamos el servidor en el medio. Quiz谩s el problema yace aqu铆? Comenzaron a cavar y encontraron aqu铆 la mejora m谩s significativa hasta ahora.
En ese momento, el servidor del grupo se seleccion贸 de acuerdo con un algoritmo bastante est煤pido: cada uno ten铆a su propio "peso", dependiendo del canal y la potencia, e intentamos enviar al usuario a aquel en el que el "peso" es mayor, sin prestar atenci贸n a la ubicaci贸n geogr谩fica del usuario . Como resultado, un maestro de San Petersburgo podr铆a comunicarse con un estudiante de Siberia a trav茅s de Mosc煤, y no a trav茅s de nuestro servidor Janus en San Petersburgo.
El algoritmo se rehizo: ahora, cuando el usuario abre nuestra plataforma, usamos Ajax para recopilar pings de 茅l en todos los servidores. Al establecer una conexi贸n, seleccionamos un par de pings (maestro-servidor y alumno-servidor) con la menor cantidad. Menos ping: menos distancia de red al servidor; menos distancia: menos posibilidades de perder paquetes; la p茅rdida de paquetes es el mayor factor negativo en las videollamadas. La proporci贸n de negatividad cay贸 dos veces en tres meses (para ser justos, tambi茅n se llevaron a cabo otros experimentos en este momento, pero este casi seguramente afect贸 m谩s).
Recientemente, descubrimos otra cosa no obvia, pero aparentemente importante: en lugar de un poderoso servidor Janus en un canal grueso, dos son m谩s simples con un ancho de banda mejor. Esto result贸 despu茅s de que compramos m谩quinas potentes con la esperanza de llenar tantas salas (sesiones de comunicaci贸n) como fuera posible al mismo tiempo. Los servidores tienen un l铆mite de ancho de banda que podemos traducir con precisi贸n en la cantidad de habitaciones; sabemos cu谩nto puede abrir, por ejemplo, a 300 Mbps. Tan pronto como se abran demasiadas salas en el servidor, dejamos de elegirlo para nuevas actividades hasta que la carga disminuya. La idea era que, despu茅s de haber comprado una m谩quina potente, cargaremos el canal al m谩ximo para que al final descanse en el procesador y la memoria, y no en el ancho de banda. Pero result贸 que despu茅s de un cierto n煤mero de salas abiertas (420), a pesar de que la carga en el procesador, la memoria y el disco a煤n est谩 muy lejos de los l铆mites, la negatividad comienza a volar hacia el soporte t茅cnico. Aparentemente, algo est谩 empeorando dentro de Janus, tal vez tambi茅n hay algunas restricciones. Comenzaron a experimentar, redujeron el l铆mite de ancho de banda de 300 a 200 Mbps, los problemas desaparecieron. Ahora compramos tres nuevos servidores a la vez con bajos l铆mites y caracter铆sticas, creemos que esto conducir谩 a una mejora estable en la calidad de la comunicaci贸n. Por supuesto, no comenzamos a descubrir qu茅 pasaba all铆, las muletas eran nuestras. En nuestra defensa, decimos que en ese momento era necesario resolver el problema urgente lo m谩s r谩pido posible, y no hacerlo bellamente; Adem谩s, Janus es una caja negra para nosotros, escrita en C, es muy costoso profundizar en ella.
Bueno, en el proceso nosotros:
- actualiz贸 todas las dependencias que podr铆an actualizarse, tanto en el servidor como en el cliente (estos tambi茅n fueron experimentos, seguidos del resultado);
- Se corrigieron todos los errores identificados relacionados con casos espec铆ficos, por ejemplo, cuando se cort贸 la conexi贸n y no se restableci贸 autom谩ticamente;
- mantuvimos muchas reuniones con empresas que trabajan en el campo de las comunicaciones de video y est谩n familiarizadas con nuestros problemas: transmisi贸n de juegos, organizaci贸n de seminarios web; prob贸 todo lo que nos pareci贸 煤til;
- llev贸 a cabo una revisi贸n t茅cnica del hierro y la calidad de la comunicaci贸n con los maestros, de donde surgieron la mayor铆a de las quejas.
Los experimentos y los cambios posteriores permitieron reducir la insatisfacci贸n con la comunicaci贸n entre los docentes del 7,1% en enero de 2018 al 2,5% en enero de 2019.
Que sigue
La estabilizaci贸n de nuestra plataforma Vimbox es uno de los principales proyectos de la compa帽铆a para 2019. Tenemos grandes esperanzas de que podremos mantener el impulso y no ver m谩s la comunicaci贸n por video en las principales quejas. Entendemos que una parte importante de estas quejas est谩 relacionada con los retrasos de las computadoras y la Internet de los usuarios, pero debemos determinar esta parte y resolver todo lo dem谩s. Todo lo dem谩s es un problema t茅cnico, parece que deber铆amos ser capaces de solucionarlo.
La principal dificultad es que no sabemos a qu茅 nivel es generalmente realista mejorar la calidad. La aclaraci贸n de este techo es la tarea principal. Por lo tanto, se planearon dos experimentos:
- Compara el video a trav茅s de Janus con p2p regular en combate. Este experimento ya se ha llevado a cabo; no se encontraron diferencias estad铆sticamente significativas entre nuestra soluci贸n y p2p;
- suministraremos servicios (caros) de compa帽铆as que ganen exclusivamente en soluciones de comunicaciones de video, y compararemos la cantidad de negativos de ellos con la existente.
Estos dos experimentos nos permitir谩n determinar un objetivo alcanzable y concentrarnos en 茅l.
Adem谩s, hay varias tareas resueltas en el orden de trabajo:
- creamos una m茅trica t茅cnica de calidad de comunicaci贸n en lugar de revisiones subjetivas;
- hacemos registros de sesiones m谩s detallados para analizar con mayor precisi贸n las fallas que ocurren, para comprender cu谩ndo y d贸nde ocurrieron exactamente, qu茅 eventos aparentemente no relacionados ocurrieron en ese momento;
- estamos preparando una prueba autom谩tica de la calidad de la comunicaci贸n antes de la clase, y tambi茅n permitiremos que el cliente pruebe manualmente la conexi贸n para reducir la cantidad de negativas causadas por su hierro y canal;
- Desarrollaremos y realizaremos m谩s pruebas de estr茅s de comunicaciones de video en malas condiciones, con p茅rdida variable de paquetes, etc.
- Cambiamos el comportamiento de los servidores en caso de problemas para aumentar la tolerancia a fallas;
- advertiremos al usuario si tiene alg煤n problema con la conexi贸n, como lo hace el mismo Skype, para que comprenda que el problema est谩 de su lado.
Desde abril, la direcci贸n de comunicaci贸n por video se ha convertido en un proyecto independiente completo dentro de Skyeng, dedicado a su propio producto, no solo a una parte de Vimbox. Y esto significa que estamos comenzando a buscar personas para trabajar con video en modo de tiempo completo . Bueno, como siempre, estamos buscando mucha gente buena .
Bueno, por supuesto, continuamos comunic谩ndonos activamente con personas y empresas que trabajan con comunicaciones de video. Si desea intercambiar experiencias con nosotros, 隆estaremos encantados! Comentario, contacto: responderemos a todos.