Esta primavera nos encontramos en condiciones muy alegres. Debido a la pandemia, quedó claro que nuestras conferencias de verano debían realizarse en línea. Y para poder realizarlos en línea de manera eficiente, las soluciones de software ya preparadas no eran adecuadas para nosotros; tuvimos que crear las nuestras propias. Y teníamos tres meses para hacer esto.
Está claro que han sido tres meses apasionantes. Pero desde fuera no está del todo claro: ¿qué es una plataforma de conferencias online? ¿De qué partes se compone? Por eso, en la última de las conferencias de verano sobre DevOops, pregunté a los responsables de esta tarea:
- Nikolay Molchanov, director técnico del Grupo JUG Ru;
- Vladimir Krasilshchik es un programador Java pragmático que trabaja en el backend (también puede ver sus informes en nuestras conferencias sobre Java);
- Artyom Nikonov es responsable de toda nuestra transmisión de vídeo.
Por cierto, en las conferencias de otoño-invierno utilizaremos una versión mejorada de la misma plataforma, por lo que muchos lectores de habra seguirán siendo sus usuarios.
Imagen general
— ¿Cuál era la composición del equipo?
Nikolay Molchanov: Contamos con un analista, un diseñador, un probador, tres front-end y un back-end. Y, por supuesto, ¡un especialista en forma de T!
— ¿Cómo fue el proceso en general?
Nikolay: Hasta mediados de marzo, no teníamos nada listo para publicar en línea. Y el 15 de marzo, todo el carrusel online empezó a girar. Instalamos varios repositorios, planificamos, discutimos la arquitectura básica e hicimos todo en tres meses.
Esto, por supuesto, pasó por las etapas clásicas de planificación, arquitectura, selección de características, votación de esas características, política para esas características, su diseño, desarrollo y pruebas. Como resultado, el 6 de junio lanzamos todo a producción. . Hubo 90 días para todo.
— ¿Logramos cumplir lo que nos comprometimos?
Nikolay: Dado que ahora participamos en la conferencia DevOops en línea, significa que funcionó. Personalmente me comprometí con lo principal: brindar a los clientes una herramienta con la que puedan realizar una conferencia en línea.
El desafío era este: darnos una herramienta con la que podamos transmitir nuestras conferencias a los poseedores de entradas.
Toda la planificación se dividió en varias etapas y todas las funciones (alrededor de 30 globales) se dividieron en 4 categorías:
- que definitivamente haremos (no podemos vivir sin ellos),
- que haremos en segundo lugar,
- que nunca haremos,
- y que nunca jamás haremos.
Hicimos todas las funciones de las dos primeras categorías.
— Sé que se crearon un total de 600 ediciones de JIRA. En tres meses, creó 13 microservicios y sospecho que no fueron escritos solo en Java. Utilizó diferentes tecnologías, tiene dos clústeres de Kubernetes en tres zonas de disponibilidad y 5 transmisiones RTMP en Amazon.
Veamos ahora cada componente del sistema por separado.
Transmisión
— Empecemos cuando ya tenemos una imagen de vídeo y se transmite a algunos servicios. Artyom, cuéntanos cómo ocurre esta transmisión.
Artem Nikonov: Nuestro esquema general se ve así: imagen de la cámara -> nuestra sala de control -> servidor RTMP local -> Amazon -> reproductor de video. Más detalles en Habré en junio.
En general, existen dos formas globales de hacer esto: ya sea mediante hardware o basándose en soluciones de software. Elegimos la ruta del software porque es más fácil en el caso de altavoces remotos. No siempre es posible llevar el hardware a un orador en otro país, pero entregar software al orador parece más fácil y confiable.
Desde el punto de vista del hardware, tenemos una cierta cantidad de cámaras (en nuestros estudios y en altavoces remotos), una cierta cantidad de controles remotos en el estudio, que a veces deben repararse justo debajo de la mesa durante la transmisión.
Las señales de estos dispositivos ingresan a las computadoras con tarjetas de captura, tarjetas de entrada/salida y tarjetas de sonido. Allí las señales se mezclan y ensamblan en diseños:
Ejemplo de diseño para 4 altavoces.
Ejemplo de diseño para 4 altavoces.
Además, la transmisión continua se realiza con la ayuda de tres computadoras: hay una máquina principal y un par de computadoras que funcionan a su vez. La primera computadora recopila el primer informe, la segunda, la pausa, la primera, el siguiente informe, la segunda, la siguiente pausa, y así sucesivamente. Y la máquina principal mezcla el primero con el segundo.
Esto crea una especie de triángulo y, si alguno de estos nodos falla, podemos continuar entregando contenido a los clientes rápidamente y sin pérdida de calidad. Tuvimos tal situación. Durante la primera semana de conferencias, arreglamos una máquina, la encendimos y apagamos. La gente parece estar contenta con nuestra resiliencia.
A continuación, las transmisiones de las computadoras van a un servidor local, que tiene dos tareas: enrutar transmisiones RTMP y registrar copias de seguridad. Entonces tenemos múltiples puntos de grabación. Luego, las transmisiones de video se envían a la parte de nuestro sistema construida sobre los servicios SaaS de Amazon. Usamos ,S3,CloudFront.
Nikolay: ¿Qué sucede allí antes de que el vídeo llegue a la audiencia? Hay que cortarlo de alguna manera, ¿no?
Artem: Comprimimos el vídeo por nuestra parte y lo enviamos a MediaLive. Lanzamos transcodificadores allí. Transcodifican vídeos en tiempo real en varias resoluciones para que la gente pueda verlos en sus teléfonos, a través de la mala Internet del país, etc. Luego estas corrientes se cortan en Así funciona el protocolo. . Enviamos una lista de reproducción a la interfaz que contiene punteros a estos fragmentos.
— ¿Estamos usando una resolución de 1080p?
Artem: El ancho de nuestro video es el mismo que 1080p - 1920 píxeles, y la altura es un poco menor, la imagen es más alargada; hay razones para esto.
Jugador
— Artyom describió cómo el vídeo llega a las transmisiones, cómo se distribuye en diferentes listas de reproducción para diferentes resoluciones de pantalla, cómo se corta en trozos y cómo llega al reproductor. Kolya, ahora dime qué tipo de reproductor es este, cómo consume la transmisión, ¿por qué HLS?
Nikolay: Tenemos un reproductor que todos los espectadores de la conferencia pueden ver.
Esencialmente, esto es un envoltorio alrededor de la biblioteca. , en el que están escritos muchos otros jugadores. Pero necesitábamos una funcionalidad muy específica: rebobinar y marcar el lugar donde se encuentra la persona, qué informe está viendo en ese momento. También necesitábamos nuestros propios diseños, todo tipo de logotipos y todo lo que teníamos integrado. Por lo tanto, decidimos escribir nuestra propia biblioteca (un contenedor sobre HLS) e incrustarla en el sitio.
Esta es la funcionalidad raíz, por lo que se implementó casi primero. Y luego todo creció a su alrededor.
De hecho, a través de la autorización, el reproductor recibe del backend una lista de reproducción con enlaces a fragmentos correlacionados con el tiempo y la calidad, descarga los necesarios y se los muestra al usuario, realizando algo de “magia” en el camino.
Ejemplo de línea de tiempo
— Hay un botón integrado en el reproductor para mostrar una línea de tiempo de todos los informes...
Nikolay: Sí, solucionamos inmediatamente el problema de la navegación del usuario. A mediados de abril decidimos que no transmitiríamos cada una de nuestras conferencias en un sitio web separado, sino que combinaríamos todo en uno. Para que los usuarios de entradas Full Pass puedan alternar libremente entre diferentes conferencias: tanto retransmisiones en directo como grabaciones de pasadas.
Y para que a los usuarios les resulte más fácil navegar por la transmisión actual y cambiar entre pistas, decidimos crear un botón de "Transmisión completa" y boletines de calificaciones horizontales para cambiar entre pistas e informes. Hay control de teclado.
— ¿Hubo alguna dificultad técnica con esto?
Nikolay: Tenían una barra de desplazamiento en la que se marcaban los puntos de inicio de diferentes informes.
— Al final, ¿implementaste estas marcas en la barra de desplazamiento antes de que YouTube hiciera algo similar?
Artem: Lo tenían en versión beta entonces. Parece que esta es una característica bastante compleja porque la han estado probando parcialmente con usuarios durante el año pasado. Y ahora ha llegado a la venta.
Nikolay: Pero en realidad lo pusimos a la venta más rápido. Honestamente, detrás de esta característica simple hay una gran cantidad de backend, frontend, cálculos y matemáticas dentro del reproductor.
Interfaz
— Averigüemos cómo llega este contenido que mostramos (tarjeta de discurso, oradores, sitio web, programación) al front-end.
Vladimir Krasilshchik: Disponemos de varios sistemas informáticos internos. Existe un sistema en el que se ingresan todos los informes y todos los oradores. Existe un proceso mediante el cual un orador participa en una conferencia. El hablante envía una solicitud, el sistema la captura y luego hay un canal determinado según el cual se crea el informe.
Así ve el hablante el oleoducto
Este sistema es nuestro desarrollo interno.
A continuación, debe crear un cronograma a partir de informes individuales. Como sabes, este es un problema NP-difícil, pero de alguna manera lo solucionamos. Para hacer esto, lanzamos otro componente que genera un cronograma y lo carga en el servicio en la nube de terceros Contentful. Allí todo parece una tabla en la que están los días de la conferencia, en los días hay franjas horarias, y en las franjas horarias hay informes, descansos o actividades de patrocinio. Entonces el contenido que vemos se encuentra en un servicio de terceros. Y la tarea es transmitirlo al sitio.
Parecería que el sitio es solo una página con un reproductor, y aquí no hay nada complicado. Excepto que no lo es. El backend detrás de esta página va a Contentful, obtiene la programación desde allí, genera algunos objetos y los envía al frontend. Utilizando una conexión websocket, que realiza cada cliente de nuestra plataforma, le enviamos una actualización del cronograma desde el backend al frontend.
Caso real: el ponente cambió de trabajo justo durante la conferencia. Necesitamos cambiar la insignia de su empresa empleadora. ¿Cómo sucede esto desde el backend? Se envía una actualización a todos los clientes a través del websocket y luego la interfaz vuelve a dibujar la línea de tiempo. Todo esto sucede sin problemas. La combinación del servicio en la nube y varios de nuestros componentes nos da la oportunidad de generar todo este contenido y brindarlo al frente.
Nikolay: Es importante aclarar aquí que nuestro sitio no es una aplicación SPA clásica. Este es a la vez un sitio web renderizado basado en diseño y un SPA. Google en realidad ve este sitio como HTML renderizado. Esto es bueno para SEO y para entregar contenido al usuario. No espera a que se carguen 1,5 megabytes de JavaScript antes de ver la página, ve inmediatamente la página ya renderizada y lo siente cada vez que cambia el informe. Todo sucede en medio segundo, ya que el contenido ya está listo y publicado en el lugar correcto.
— Trazamos una línea debajo de todo lo anterior enumerando las tecnologías. Tyoma dijo que tenemos 5 transmisiones de Amazon y entregamos video y sonido allí. Tenemos scripts bash allí, los usamos para iniciar y configurar...
Artem: Esto sucede a través de la API de AWS, hay muchos más servicios técnicos allí. Dividimos nuestras responsabilidades para que pueda entregar a , y los desarrolladores de front-end y back-end lo toman a partir de ahí. Disponemos de varios enlaces propios para simplificar el diseño del contenido, que luego realizamos en 4K, etc. Como los plazos eran muy ajustados, lo hicimos casi en su totalidad en AWS.
— Luego, todo esto ingresa al reproductor mediante el sistema backend. Tenemos TypeScript, React, Next.JS en nuestro reproductor. Y en el backend tenemos varios servicios en C#, Java, Spring Boot y Node.js. Todo esto se implementa utilizando Kubernetes utilizando la infraestructura Yandex.Cloud.
También quiero señalar que cuando necesité familiarizarme con la plataforma, resultó fácil: todos los repositorios están en GitLab, todo está bien nombrado, las pruebas están escritas, hay documentación. Es decir, incluso en modo de emergencia, se encargaron de esas cosas.
Restricciones comerciales y análisis
— Nos dirigimos a 10 000 usuarios según los requisitos comerciales. Es hora de hablar de las restricciones comerciales que teníamos. Teníamos que garantizar una gran carga de trabajo y garantizar el cumplimiento de la ley sobre conservación de datos personales. ¿Y qué más?
Nikolay: Inicialmente, partimos de los requisitos del vídeo. Lo más importante es el almacenamiento de vídeo distribuido en todo el mundo para una entrega rápida al cliente. Otros incluyen resolución de 1080p, así como rebobinado, que muchos otros no implementan en modo en vivo. Más tarde agregamos la capacidad de habilitar 2x velocidad, con su ayuda puede "ponerse al día" con la transmisión en vivo y continuar viendo la conferencia en tiempo real. Y en el camino, apareció la función de marcado de línea de tiempo. Además, teníamos que ser tolerantes a fallos y soportar la carga de 10 conexiones. Desde el punto de vista del backend, esto equivale aproximadamente a 000 10 conexiones multiplicadas por 000 solicitudes por cada actualización de página. Y esto ya es 8 RPS/seg. Bastante.
— ¿Había otros requisitos para una “exposición virtual” con stands en línea de los socios?
Nikolay: Sí, esto tenía que hacerse con bastante rapidez y de forma universal. Teníamos hasta 10 empresas asociadas para cada conferencia y todas debían completarse en una o dos semanas. Sin embargo, su contenido difiere ligeramente en formato. Pero se creó un determinado motor de plantillas que ensambla estas páginas sobre la marcha, prácticamente sin participación adicional en el desarrollo.
— También existían requisitos para el análisis de vistas y estadísticas en tiempo real. Sé que usamos Prometheus para esto, pero cuéntenos con más detalle: ¿qué requisitos cumplimos para el análisis y cómo se implementa?
Nikolay: Inicialmente, tenemos requisitos de marketing para recopilar información para pruebas A/B y recopilar información para comprender cómo entregar adecuadamente el mejor contenido al cliente en el futuro. También existen requisitos para algunos análisis sobre las actividades de los socios y los análisis que ve (contador de visitas). Toda la información se recopila en tiempo real.
Podemos proporcionar esta información de forma agregada incluso a los oradores: cuántas personas te estaban mirando en un momento determinado. Al mismo tiempo, para cumplir con la Ley Federal 152, su cuenta personal y sus datos personales no son rastreados de ninguna manera.
La plataforma ya cuenta con herramientas de marketing y nuestras métricas para medir la actividad de los usuarios en tiempo real (quién vio qué segundo del informe) para poder construir gráficos de asistencia a los informes. A partir de estos datos se están realizando investigaciones que mejorarán las próximas conferencias.
Fraude
— ¿Tenemos mecanismos antifraude?
Nikolay: Debido a los plazos ajustados desde el punto de vista empresarial, inicialmente no se planteó la tarea de bloquear inmediatamente las conexiones innecesarias. Si dos usuarios iniciaron sesión con la misma cuenta, podrían ver el contenido. Pero sabemos cuántas vistas simultáneas hubo desde una cuenta. Y prohibimos a varios infractores particularmente maliciosos.
Vladimir: Hay que reconocer que uno de los usuarios prohibidos entendió por qué sucedió esto. Vino, se disculpó y prometió comprar un billete.
— Para que todo esto suceda, debes rastrear completamente a todos los usuarios desde la entrada hasta la salida, saber siempre lo que están haciendo. ¿Cómo funciona este sistema?
Vladimir: Me gustaría hablar de análisis y estadísticas, que luego analizamos para determinar el éxito del informe o que luego podemos proporcionar a los socios. Todos los clientes están conectados a través de una conexión websocket a un clúster de backend específico. esta ahi . Cada cliente en cada periodo de tiempo envía lo que está haciendo y qué track está viendo. Luego, esta información se agrega mediante trabajos rápidos de Hazelcast y se envía a todos los que miran estas pistas. Vemos en la esquina cuántas personas están ahora con nosotros.
La misma información se almacena en y va a nuestro lago de datos, desde donde tenemos la oportunidad de construir un gráfico más interesante. Surge la pregunta: ¿cuántos usuarios únicos vieron este informe? Vamos a , hay pings de todas las personas que llegaron por el id de este informe. Recopilamos, agregamos algunos únicos y ahora podemos entenderlos.
Nikolay: Pero al mismo tiempo también recibimos datos en tiempo real de Prometheus. Se compara con todos los servicios de Kubernetes, con el propio Kubernetes. Recoge absolutamente todo y con Grafana podemos construir cualquier gráfico en tiempo real.
Vladimir: Por un lado, lo descargamos para su posterior procesamiento OLAP. Y para OLTP, la aplicación descarga todo a Prometheus, Grafana e incluso los gráficos convergen.
- Este es el caso cuando las gráficas convergen.
Cambios dinámicos
— Cuéntanos cómo se implementan los cambios dinámicos: si el informe se canceló 6 minutos antes del inicio, ¿cuál es la cadena de acciones? ¿Qué tubería funciona?
Vladimir: El oleoducto es muy condicional. Hay varias posibilidades. La primera es que el programa de generación de horarios funcionó y cambió el horario. El horario modificado se carga en Contentful. Después de lo cual el backend entiende que hay cambios para esta conferencia en Contentful, los toma y los reconstruye. Todo se recopila y envía a través de websocket.
La segunda posibilidad, cuando todo sucede a un ritmo vertiginoso: el editor cambia manualmente la información en Contentful (enlace a Telegram, presentación del orador, etc.) y funciona la misma lógica que la primera vez.
Nikolay: Todo sucede sin actualizar la página. Todos los cambios se producen de forma absolutamente fluida para el cliente. Lo mismo ocurre con el cambio de informes. Cuando llega el momento, el informe y la interfaz cambian.
Vladimir: Además, existen límites de tiempo para el inicio de los informes en la línea de tiempo. Al principio no hay nada. Y si pasa el mouse sobre la franja roja, en algún momento, gracias al director de transmisión, aparecerán cortes. El director establece el inicio correcto de la transmisión, el backend recoge este cambio, calcula los tiempos de inicio y finalización de las presentaciones de toda la pista de acuerdo con el cronograma de la conferencia, lo envía a nuestros clientes y el reproductor dibuja los cortes. Ahora el usuario puede navegar fácilmente hasta el principio y el final del informe. Era un requisito comercial estricto, muy conveniente y útil. No pierde tiempo buscando la hora de inicio real del informe. Y cuando hagamos una vista previa, será absolutamente maravilloso.
Despliegue
— Me gustaría preguntar sobre el despliegue. Kolya y el equipo dedicaron mucho tiempo al principio a configurar toda la infraestructura en la que se desarrolla todo para nosotros. Dime, ¿de qué está hecho todo esto?
Nikolay: Desde un punto de vista técnico, inicialmente teníamos el requisito de que el producto fuera lo más abstracto posible de cualquier proveedor. Venga a AWS para crear scripts de Terraform específicamente desde AWS, o específicamente desde Yandex, o desde Azure, etc. realmente no encajaba. En algún momento teníamos que mudarnos a algún lugar.
Durante las primeras tres semanas buscamos constantemente una manera de hacerlo mejor. Como resultado, llegamos a la conclusión de que Kubernetes en este caso es nuestro todo, porque nos permite crear servicios que se escalan automáticamente, se implementan automáticamente y obtienen casi todos los servicios listos para usar. Naturalmente, todos los servicios tuvieron que capacitarse para trabajar con Kubernetes, Docker y el equipo también tuvo que aprender.
Tenemos dos grupos. Prueba y producción. Son absolutamente idénticos en términos de hardware y configuración. Implementamos infraestructura como código. Todos los servicios se implementan automáticamente en tres entornos desde ramas de funciones, ramas maestras, ramas de prueba y GitLab mediante una canalización automática. Esto está integrado al máximo en GitLab, integrado al máximo con Elastic, Prometheus.
Tenemos la oportunidad de implementar rápidamente (para el backend en 10 minutos, para el frontend en 5 minutos) implementar cambios en cualquier entorno con todas las pruebas, integraciones, ejecución de pruebas funcionales, pruebas de integración en el entorno y también pruebas con pruebas de carga en un entorno de prueba aproximadamente lo mismo que queremos tener en producción.
Acerca de las pruebas
— Pruebas casi todo, es difícil creer cómo escribiste todo. ¿Puede contarnos sobre las pruebas de backend: cuánto está cubierto todo, qué pruebas?
Vladimir: Se han escrito dos tipos de pruebas. Las primeras son las pruebas de componentes. Pruebas de nivel de elevación de toda la aplicación del resorte y la base en . Esta es una prueba de escenarios empresariales del más alto nivel. No pruebo funciones. Sólo probamos algunas cosas importantes. Por ejemplo, directamente en la prueba, se emula el proceso de inicio de sesión de un usuario, la solicitud del usuario de entradas para ir a dónde puede ir y una solicitud de acceso para ver la transmisión. Escenarios de usuario muy claros.
Aproximadamente lo mismo se implementa en las llamadas pruebas de integración, que en realidad se ejecutan en el entorno. De hecho, cuando se implemente la próxima implementación en producción, también se ejecutarán escenarios básicos reales en producción. Lo mismo iniciar sesión, solicitar tickets, solicitar acceso a CloudFront, comprobar que el stream realmente conecta con mis permisos, comprobar la interfaz del director.
Actualmente tengo alrededor de 70 pruebas de componentes y alrededor de 40 pruebas de integración a bordo. La cobertura es muy cercana al 95%. Esto es para los componentes, menos para los de integración, simplemente no se necesita tanto. Teniendo en cuenta que el proyecto implica todo tipo de generación de código, este es un muy buen indicador. No había otra manera de hacer lo que hicimos en tres meses. Porque si probáramos manualmente, dándole funciones a nuestro evaluador, y ella encontraría errores y nos los devolvería para que los corrigiéramos, entonces este viaje de ida y vuelta para depurar el código sería muy largo y no cumpliríamos ningún plazo.
Nikolay: Convencionalmente, para realizar una regresión en toda la plataforma al cambiar alguna función, es necesario sentarse y hurgar en todas partes durante dos días.
Vladimir: Por lo tanto, es un gran acierto que cuando evalúo una característica, diga que necesito 4 días para dos bolígrafos simples y 1 websocket, Kolya lo permite. Ya está acostumbrado a que estos 4 días incluyan 2 tipos de pruebas, y entonces, lo más probable es que funcione.
Nikolay: También tengo 140 pruebas escritas: componente + funcional, que hacen lo mismo. Los mismos escenarios se prueban en producción, en prueba y en producción. También agregamos recientemente pruebas de interfaz de usuario básicas funcionales. De esta manera cubrimos la funcionalidad más básica que puede fallar.
Vladimir: Por supuesto, vale la pena hablar de pruebas de carga. Fue necesario probar la plataforma bajo una carga cercana a la real para entender cómo es todo, qué está pasando con Rabbit, qué está pasando con las JVM, cuánta memoria se necesita realmente.
— No sé con certeza si estamos probando algo en el lado de la transmisión, pero recuerdo que hubo problemas con los transcodificadores cuando hicimos reuniones. ¿Hemos probado las transmisiones?
Artem: Probado iterativamente. Organización de reuniones. En el proceso de organización de reuniones, se obtuvieron aproximadamente 2300 entradas JIRA. Estas son solo cosas genéricas que la gente hacía para concertar reuniones. Llevamos partes de la plataforma a una página separada para reuniones, dirigida por Kirill Tolkachev ().
Para ser honesto, no hubo grandes problemas. Literalmente, un par de veces detectamos errores de almacenamiento en caché en CloudFront, lo resolvimos con bastante rapidez: simplemente reconfiguramos las políticas. Hubo muchos más errores en las personas, en los sistemas de transmisión del sitio.
Durante las conferencias tuve que escribir a varios exportadores más para cubrir más equipos y servicios. En algunos lugares tuve que fabricar mis propias bicicletas sólo por razones métricas. El mundo del hardware AV (audio y vídeo) no es muy optimista: tienes una especie de "API" de equipo en el que simplemente no puedes influir. Y está lejos de ser un hecho que podrá obtener la información que necesita. Los proveedores de hardware son realmente lentos y es casi imposible obtener de ellos lo que desea. En total hay más de 100 piezas de hardware, no te devuelven lo que necesitas y escribes exportadores extraños y redundantes, gracias a los cuales al menos de alguna manera puedes depurar el sistema.
Equipo
— Recuerdo que antes del inicio de las conferencias compramos parcialmente equipo adicional.
Artem: Compramos computadoras, laptops y paquetes de baterías. Actualmente podemos vivir sin electricidad durante 40 minutos. En junio hubo fuertes tormentas en San Petersburgo, por lo que tuvimos un apagón. Al mismo tiempo, varios proveedores nos llegan con enlaces ópticos desde diferentes puntos. Realmente son 40 minutos de inactividad del edificio, durante los cuales tendremos luces encendidas, sonido, cámaras, etc. funcionando.
— Tenemos una historia similar con Internet. En la oficina donde están ubicados nuestros estudios, arrastramos una red feroz entre los pisos.
Artem: Disponemos de 20 Gbit de fibra entre plantas. Más adelante en los pisos, en algún lugar hay óptica, en algún lugar no hay óptica, pero aún así hay menos canales que gigabit: transmitimos video en ellos entre las pistas de la conferencia. En general, es muy conveniente trabajar en su propia infraestructura, rara vez puede hacerlo en conferencias fuera de línea en sitios.
— Antes de trabajar en JUG Ru Group, vi cómo se instalaban salas de hardware en conferencias fuera de línea de la noche a la mañana, donde había un monitor grande con todas las métricas que se crean en Grafana. Ahora también hay una sala de la sede en la que se sienta el equipo de desarrollo, que durante la conferencia corrige algunos errores y desarrolla funciones. Al mismo tiempo, hay un sistema de seguimiento que se muestra en una pantalla grande. Artyom, Kolya y otros muchachos se sientan y se aseguran de que todo no se caiga y funcione a la perfección.
Curiosidades y problemas
— Hablaste bien sobre el hecho de que tenemos transmisión con Amazon, hay un reproductor con la web, todo está escrito en diferentes lenguajes de programación, se proporciona tolerancia a fallas y otros requisitos comerciales, incluida una cuenta personal compatible con personas jurídicas y individuos, y podemos integrarnos con alguien usando OAuth 2.0, hay antifraude y bloqueo de usuarios. Podemos implementar cambios dinámicamente porque lo hicimos bien y todo está probado.
Me interesa saber qué rarezas estuvieron involucradas en el inicio de algo. ¿Ha habido situaciones extrañas en las que estabas desarrollando un backend, un frontend, resultó algo loco y no sabías qué hacer con ello?
Vladimir: Me parece que esto sólo ha sucedido durante los últimos tres meses. Cada día. Como puedes ver, me han arrancado todo el pelo.
Vladimir Krasilshchik después de 3 meses, cuando apareció una especie de juego y nadie sabía qué hacer con él.
Todos los días había algo así, cuando llegaba un momento en el que lo tomas y te arrancas el pelo, o te das cuenta de que no hay nadie más, y que sólo tú puedes hacerlo. Nuestro primer gran evento fue TechTrain. El 6 de junio a las 2 a.m. aún no habíamos implementado el entorno de producción, Kolya lo estaba implementando. Y la cuenta personal no funcionó como servidor de autorización usando OAuth2.0. Lo convertimos en un proveedor de OAuth2.0 para conectarle la plataforma. Había estado trabajando probablemente durante 18 horas seguidas, miré la computadora y no vi nada, no entendí por qué no funcionaba, y Kolya miró mi código de forma remota, buscó un error en la configuración de Spring. Lo encontré y el LC funcionó, y también en producción.
Nikolay: Y una hora antes de TechTrain se produjo el lanzamiento.
Aquí se alinearon muchas estrellas. Tuvimos mucha suerte porque teníamos un súper equipo y todos se inspiraron con la idea de hacerlo en línea. Durante todos estos tres meses nos impulsó el hecho de que "hicimos YouTube". No me permití arrancarme el pelo, pero les dije a todos que todo saldría bien, porque en realidad todo había sido calculado hace mucho tiempo.
Acerca del rendimiento
— ¿Puedes decirme cuántas personas había en el sitio en una pista? ¿Hubo algún problema de rendimiento?
Nikolay: No hubo problemas de rendimiento, como ya dijimos. El número máximo de personas que asistieron a un informe fue de 1300 personas, esto es en Heisenbug.
— ¿Hubo algún problema con la visualización local? ¿Y es posible tener una descripción técnica con diagramas de cómo funciona todo?
Nikolay: Haremos un artículo sobre esto más adelante.
Incluso puedes depurar transmisiones localmente. Una vez que comenzaron las conferencias, se volvió aún más fácil, porque aparecieron flujos de producción que podemos ver todo el tiempo.
Vladimir: Según tengo entendido, los desarrolladores front-end trabajaron localmente con simulacros y luego, dado que el tiempo para implementarlos en el front-end también es corto (5 minutos), no hay problemas para verificar qué está pasando con los certificados.
— Todo se prueba y depura, incluso localmente. Esto significa que escribiremos un artículo con todas las características técnicas, te mostraremos, te contaremos todo con diagramas, cómo fue.
Vladimir: Puedes tomarlo y repetirlo.
- En 3 meses.
Total
— Todo lo descrito en conjunto suena genial, considerando que lo hizo un pequeño equipo en tres meses.
Nikolay: Un equipo grande no haría esto. Pero un pequeño grupo de personas que se comunican bastante estrecha y bien entre sí y pueden llegar a un acuerdo sí podrían hacerlo. No tienen contradicciones, la arquitectura se inventó en dos días, se finalizó y en realidad no ha cambiado. Existe una facilitación muy estricta de los requisitos comerciales entrantes en términos de acumulación de solicitudes y cambios de funciones.
— ¿Qué había en su lista de tareas futuras cuando ya se habían celebrado las conferencias de verano?
Nikolay: Por ejemplo, créditos. Líneas progresivas en el video, ventanas emergentes en algunos lugares del video dependiendo del contenido que se muestra. Por ejemplo, el orador quiere hacer una pregunta a la audiencia y aparece una votación en la pantalla, que retrocede según los resultados de la votación hasta el propio orador. Algún tipo de actividad social en forma de me gusta, corazones, calificaciones del informe durante la presentación en sí, para que pueda completar los comentarios en el momento adecuado sin distraerse más tarde con los formularios de comentarios. Inicialmente así.
Y además añadiendo a toda la plataforma, excepto streaming y conferencia, también un estado post-conferencia. Se trata de listas de reproducción (incluidas las compiladas por los usuarios), posiblemente contenidos de otras conferencias pasadas, integradas, etiquetadas, accesibles para el usuario y también disponibles para su visualización en nuestro sitio web ().
— Chicos, ¡muchas gracias por sus respuestas!
Si entre los lectores hay quienes asistieron a nuestras conferencias de verano, comparta sus impresiones sobre el jugador y la transmisión. ¿Qué te convenía, qué te irritaba, qué te gustaría ver en el futuro?
Si estás interesado en la plataforma y quieres verla “en batalla”, la usamos nuevamente en nuestro . Hay una gran variedad de ellos, por lo que es casi seguro que haya uno adecuado para usted.
Fuente: habr.com