La videoconferencia es el principal medio de comunicación entre el profesor y el estudiante en la plataforma Vimbox. Abandonamos Skype hace tiempo, probamos varias soluciones de terceros y finalmente nos decidimos por la combinación WebRTC - Janus-gateway. Durante un tiempo, todo funcionó bien, pero algunos aspectos negativos seguían apareciendo. Así que se creó una dirección separada para el video.
Le pedí a Kirill Rogovoy, el líder de esta nueva dirección, que hablara sobre la evolución de la videoconferencia en Skyeng, los problemas encontrados, las soluciones y los parches que usamos al final. Esperamos que el artículo sea útil para las empresas que también implementan video a través de aplicaciones web.
Un poco de historia
En el verano de 2017, el jefe de desarrollo de Skyeng, Sergey Safonov, se presentó en Backend Conf para contar cómo 'abandonamos Skype e implementamos WebRTC'. Los interesados pueden ver la grabación de la ponencia por (~45 min), y aquí resumiré brevemente su contenido.
Para la escuela Skyeng, la videoconferencia siempre ha sido la forma prioritaria de comunicación entre el profesor y el alumno. Al principio utilizamos 'Skype', pero no nos satisfacía en absoluto por varias razones, principalmente debido a la falta de registros y la imposibilidad de integrarlo directamente en la aplicación web. Por eso hicimos varios experimentos.
En realidad, nuestros requisitos para la videoconferencia eran aproximadamente los siguientes:
— estabilidad;
— bajo costo por lección;
— grabación de lecciones;
— seguimiento de cuánto habla cada uno (es importante para nosotros que los estudiantes hablen más que el profesor durante las lecciones);
— escalabilidad lineal;
— posibilidad de usar tanto UDP como TCP.
El primero en probar fue Tokbox en 2013. Todo iba bien, pero resultó ser muy caro: 113 rublos por lección, lo que consumía nuestras ganancias.
Luego, en 2015, integramos Voximplant. Aquí teníamos la función necesaria para rastrear cuánto habla cada uno y, además, era significativamente más barata: con solo grabación de audio, salía 20 rublos por lección. Sin embargo, solo funcionaba a través de UDP, no podía cambiar a TCP. A pesar de eso, alrededor del 40% de los estudiantes lo utilizaron.
Después de un año, comenzamos a tener clientes corporativos con requisitos específicos. Por ejemplo, todo debe funcionar a través del navegador, en la empresa solo están habilitados http y https; es decir, nada de «Skype» y UDP. Clientes corporativos = dinero, por lo que regresamos a Tokbox, pero el problema del precio no desapareció.
La solución es WebRTC y Janus
Decidimos usar . Esta se encarga de establecer la conexión, codificar y decodificar flujos, sincronizar pistas y controlar la calidad al manejar fallos de red. De nuestra parte, debemos asegurarnos de leer los flujos de la cámara y el micrófono, renderizar el video, gestionar la conexión, establecer la conexión WebRTC y transmitirle los flujos, así como enviar mensajes de señalización entre los clientes para establecer la conexión (WebRTC solo describe el formato de datos, pero no el mecanismo para su transmisión). En caso de que los clientes estén detrás de NAT, WebRTC conecta servidores STUN, y si eso no ayuda, servidores TURN.
Una conexión p2p ordinaria no es suficiente, ya que queremos grabar las lecciones para análisis posteriores en caso de quejas. Por lo tanto, enviamos los flujos de WebRTC a través de un retransmisor . Como resultado, los clientes no conocen las direcciones entre sí, solo ven la dirección del servidor Janus; este también funciona como servidor de señalización. Janus tiene muchas características que necesitamos: cambia automáticamente a TCP si el cliente tiene bloqueado UDP; puede grabar flujos tanto en UDP como en TCP; es escalable; incluso tiene un plugin incorporado para pruebas de eco. Si es necesario, se conectan automáticamente los servidores STUN y TURN de Twilio.
En el verano de 2017 teníamos dos servidores Janus más un servidor adicional para procesar los archivos de audio y video crudos grabados, para no utilizar los procesadores de los principales. Al conectarse, los servidores Janus se seleccionaban por el principio par-impar (número de conexión). En ese momento, esto era suficiente, ya que nos daba alrededor de cuatro veces más de capacidad de lo que necesitábamos, con un porcentaje de implementación de aproximadamente 80. A su vez, el costo se redujo a ~2 rublos por lección, más desarrollo y soporte.
Volviendo al tema de las videoconferencias
Estamos constantemente monitorizando los comentarios de los alumnos y profesores para identificar y abordar problemas a tiempo. Para el verano de 2018, la calidad de la conexión se había consolidado como la principal queja. Por un lado, esto significaba que habíamos solucionado con éxito otras deficiencias. Por otro lado, había que actuar rápidamente: al interrumpir una clase, corremos el riesgo de perder su valor, a veces junto con el coste de la siguiente compra de paquete; y al interrumpir la clase introductoria, incluso podríamos perder a un cliente potencial.
En ese momento, nuestra videoconferencia seguía funcionando en modo MVP. En otras palabras, lanzamos, funcionó, escalamos una vez, entendimos cómo hacerlo —y eso fue genial. If it works, don’t fix it. Nadie se ocupaba deliberadamente de la calidad de la conexión. Para agosto, quedó claro que esto no podía continuar así, por lo que lanzamos una dirección especial para investigar qué estaba mal con WebRTC y Janus.
A la entrada, esta dirección llegó con: solución MVP, sin métricas, sin objetivos, sin procesos de mejora, y al mismo tiempo, el 7% de los profesores se quejan de la calidad de la conexión (no había datos sobre los alumnos tampoco).
La nueva dirección se pone a trabajar
El comando se ve aproximadamente así:
- El líder de la dirección, que también es el desarrollador principal.
- El QA ayuda a probar los cambios, busca nuevas formas de crear condiciones inestables para la conexión, informa sobre problemas desde la línea del frente.
- El analista busca constantemente diferentes correlaciones en los datos técnicos, mejora el análisis de los comentarios de los usuarios y verifica los resultados de los experimentos.
- El product manager ayuda con la dirección general y la asignación de recursos para los experimentos.
- A menudo, un segundo desarrollador ayuda con la programación y tareas relacionadas.
Para comenzar, configuramos una métrica relativamente confiable que seguía los cambios en la evaluación de la calidad de la conexión (promedio por días, semanas, meses). En ese momento, estas eran evaluaciones de los profesores, y posteriormente se añadieron las evaluaciones de los estudiantes. Luego comenzamos a formular hipótesis sobre qué no estaba funcionando bien, corregir y observar los cambios en la dinámica. Optamos por los ‘frutos al alcance’: por ejemplo, cambiamos el códec VP8 por VP9, lo cual mejoró los indicadores. También probamos a jugar con la configuración de Janus y realizar otros experimentos, que en la mayoría de los casos no dieron resultados.
En la segunda etapa surgió la hipótesis: WebRTC es una solución peer-to-peer, pero nosotros utilizamos un servidor en el medio. ¿Podría ser que el problema esté aquí? Comenzamos a investigar y encontramos aquí la mejora más significativa hasta el momento.
En ese momento, el servidor era seleccionado de un grupo utilizando un algoritmo bastante rudimentario: cada uno tenía su propio 'peso', dependiente del canal y la potencia, y tratábamos de enviar al usuario a aquel donde 'el peso' era 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 alumno de Siberia a través de Moscú, en lugar de a través de nuestro servidor Janus en San Petersburgo.
Reformulamos el algoritmo: ahora, cuando un usuario abre nuestra plataforma, recopilamos pings desde él a todos los servidores mediante Ajax. Al establecer la conexión, elegimos un par de pings (maestro-servidor y alumno-servidor) con la suma más baja. Menos ping significa menor distancia de red al servidor; menor distancia implica menor probabilidad de pérdida de paquetes; la pérdida de paquetes es el mayor factor negativo en la comunicación por video. La proporción de negatividad se redujo a la mitad en tres meses (por justicia, se realizaron otros experimentos durante este tiempo, pero este sin duda tuvo el mayor impacto).
Recientemente descubrimos otra cosa no obvia, pero aparentemente importante: es mejor tener dos servidores Janus de menor potencia en lugar de uno potente en un canal robusto. Esto se determinó después de que compramos máquinas potentes con la esperanza de alojar tantas salas (sesiones de conexión) como fuera posible al mismo tiempo. Los servidores tienen un límite de ancho de banda, que podemos traducir con precisión en el número de salas: sabemos cuántas se pueden abrir, por ejemplo, con 300 mbps. Tan pronto como se abren demasiadas salas en el servidor, dejamos de elegirlo para nuevas sesiones hasta que la carga disminuya. La idea era que, al comprar una máquina potente, saturaríamos el canal lo máximo posible, para al final limitarnos por el procesador y la memoria, no por el ancho de banda. Pero resultó que después de cierto número de salas abiertas (420), aunque la carga de CPU, memoria y disco aún estaba muy lejos de los límites, empezaron a llegar quejas al soporte técnico. Al parecer, algo empeora dentro de Janus, tal vez también haya alguna limitación. Comenzamos a experimentar, redujimos el límite de ancho de banda de 300 a 200 mbps y los problemas desaparecieron. Ahora hemos comprado tres nuevos servidores con límites y características menores, pensamos que esto llevará a una mejora estable en la calidad de la conexión. No nos pusimos a investigar de qué se trataba, los parches son nuestra solución. A nuestra defensa, diremos que en ese momento era necesario resolver rápidamente un problema urgente, y no hacerlo de forma elegante; además, Janus para nosotros es una caja negra escrita en C, meterse con eso es muy costoso.
Y en el proceso, nosotros:
- actualizamos todas las dependencias que pudimos, tanto en el servidor como en el cliente (también fueron experimentos, monitoreamos el resultado);
- reparamos todos los errores identificados que afectaban a casos específicos, por ejemplo, cuando la conexión caía y no se recuperaba automáticamente;
- realizamos numerosas reuniones con empresas que trabajan en el campo de la videoconferencia y están familiarizadas con nuestros problemas: aquellos que transmiten videojuegos, organizan seminarios web; probamos todo lo que nos pareció útil;
- realizamos una revisión técnica del hardware y la calidad de la conexión con los profesores de los que procedían la mayoría de las quejas.
Los experimentos realizados y los cambios que les siguieron permitieron reducir la insatisfacción de los profesores con la conexión del 7,1% en enero de 2018 al 2,5% en enero de 2019.
¿Qué sigue?
La estabilización de nuestra plataforma Vimbox es uno de los principales proyectos de la empresa para 2019. Tenemos grandes esperanzas de mantener la dinámica y no volver a ver las videoconferencias en la parte superior de las quejas. Entendemos que una parte considerable de estas quejas está relacionada con el retraso de las computadoras e internet de los usuarios, pero debemos identificar esta parte y resolver todo lo demás. Lo demás —es un problema técnico que, parece, debemos saber manejar.
La principal dificultad es que no sabemos hasta qué nivel es realmente posible mejorar la calidad. Determinar este límite es la tarea principal. Por lo tanto, se han planificado dos experimentos:
- comparar el video a través de Janus con un p2p normal en condiciones reales. Este experimento ya se ha realizado, no se ha encontrado ninguna diferencia estadísticamente significativa entre nuestra solución y p2p;
- montaremos (caros) servicios de empresas que ganan exclusivamente con soluciones en el área de videoconferencia y compararemos la cantidad de negatividad que generan con la existente.
Estos dos experimentos nos permitirán definir un objetivo alcanzable y concentrarnos en él.
Además, hay una serie de tareas que se resuelven en el trabajo:
- creamos una métrica técnica de calidad de conexión en lugar de opiniones subjetivas;
- hacemos registros más detallados de las sesiones para analizar con mayor precisión las fallas que ocurren, entender cuándo y dónde exactamente sucedieron, qué eventos aparentemente no relacionados ocurrieron en ese momento;
- preparamos una prueba automática de calidad de conexión antes de la lección, y también daremos la oportunidad al cliente de probar la conexión manualmente para reducir la cantidad de negatividad causada por su hardware y canal;
- desarrollaremos y realizaremos más pruebas de carga de videoconferencia en malas condiciones, con pérdida de paquetes variable, etc.;
- cambiamos el comportamiento de los servidores en caso de problemas para aumentar la resistencia a fallos;
- avisaremos al usuario si algo no está bien con su conexión, como lo hace Skype, para que entienda que el problema está de su lado.
A partir de abril, la dirección de videoconferencia se convierte en un proyecto independiente dentro de Skyeng, dedicado a su propio producto, y no solo una parte de Vimbox. Esto significa que empezamos a buscar personas para . Y como siempre, .
. Y, por supuesto, seguimos en contacto activo con personas y empresas que trabajan con videoconferencia. Si deseas compartir tu experiencia con nosotros, ¡estaremos encantados! Comenta, contáctanos, responderemos a todos.
Fuente: habr.com
