La pasada Copa Mundial de la FIFA 2018 en Rusia trajo cargas pesadas no solo a los centros de transporte del país, sino también a la infraestructura de TI de la emisora rusa más grande, que hizo que los partidos estuvieran disponibles en formato de transmisión en línea. Asumimos con interés un nuevo desafío que llegó a los servidores que se estaban atendiendo junto con la fiebre del fútbol.
Prólogo: ¿cargas elevadas?
Las conversaciones sobre alta carga a menudo comienzan con reflexiones sobre el tema, ¿qué cargas pueden considerarse correctamente "altas": miles de solicitudes de dinámica por segundo? ¿O incluso un pequeño número de solicitudes en relación con los recursos disponibles? Millones de visitantes por día? ¿Cientos de nodos de carga de trabajo en un clúster? ..
Para tener una idea de la "escala del desastre", el hecho de que estamos hablando de usuarios
que ven
simultáneamente la transmisión, cuyo número alcanzó la marca de
2 millones , debería ser suficiente. ¿Qué pasó si miras las transmisiones de partidos "desde adentro", y cómo lograste hacer frente a un tráfico sin precedentes?
Tres ballenas
1. Arquitectura del sitio y sistemas de traducción
El esquema general de interacción entre el usuario final y el sistema de traducción se reduce al siguiente esquema:
- El usuario llega al sitio donde se inicia el reproductor para ver el video. El reproductor en sí está escrito en JavaScript y al cargarlo se generan muchas solicitudes de estadísticas, así como varias API relacionadas con las traducciones.
- Entre otras cosas, hay un atractivo para el equilibrador para una lista de reproducción para la reproducción.
- Una lista de reproducción es un conjunto constantemente actualizado de fragmentos cortos de video que se almacenan en caché en servidores CDN.
- Mientras mira el video de un usuario en tiempo real, se recopilan una variedad de estadísticas, que, en particular, se tienen en cuenta para el equilibrio de carga de CDN (junto con el ancho de banda real disponible).
La arquitectura para la distribución directa del video fue diseñada e implementada por las fuerzas internas de los ingenieros del cliente incluso antes del inicio de nuestra cooperación. Más tarde, además del servicio en sí, nos dedicamos al diseño y la puesta en marcha de la infraestructura de algunos de sus componentes, así como del sitio en sí, que desempeña un papel importante en el esquema general.
El sitio, lanzado en producción hace varios años, se centra en la escalabilidad horizontal, incluidos muchos centros de datos:
El esquema presentado aquí está simplificado y está destinado a demostrar la naturaleza de la escalabilidad del sitio, cuyos componentes se distribuyen en diferentes centros de datos.
2. CDN
Volviendo a ver el video, es obvio que la carga principal recae en los servidores CDN. En las cifras de la pasada Copa del Mundo, estamos hablando del tráfico constante, que se mide en
terabits por segundo . Y en muchos aspectos, el éxito del trabajo de las traducciones con cargas máximas se debe al almacenamiento en caché en el CDN de todo lo que se les puede transferir y a minimizar los costos de recursos (red, CPU, RAM, ...) de otras operaciones.
Además, un punto importante al trabajar con CDN es la interacción con su API para obtener información relevante sobre el ancho de banda total y disponible. En el sistema de difusión, estos datos se utilizan para distribuir nuevos espectadores y redistribuir los actuales.
Entonces, si los servidores CDN pueden proporcionar suficiente ancho de banda para millones de usuarios de Internet, ¿cuándo pueden ocurrir problemas? Durante el campeonato, observamos dos escenarios principales:
- Por alguna razón, hay un retraso en la transmisión.
Por ejemplo, la configuración del sistema "jugó" en uno de los partidos de campeonato que el servicio de protección DDoS, que no esperaba una carga repentina, comenzó a considerar lo que estaba sucediendo como un ataque, bloqueando la disponibilidad de servidores CDN uno tras otro ... hasta que se notificó que la situación era en un sentido extremo, pero aún a tiempo completo (se hicieron las conclusiones necesarias; en las próximas transmisiones la situación no se repitió).
En esos momentos, todos los usuarios que se ven superados por un problema masivo comienzan a actualizar la página con el reproductor. - Un gol anotado (especialmente el primero), como regla, provoca una gran afluencia de espectadores en un período de tiempo limitado.
Si hablamos de números más específicos, esa afluencia ascendió a cientos de miles de usuarios en 1-1.5 minutos.
Ambos casos generaron picos agudos en las solicitudes de contenido dinámico del sitio que debían ser manejados por los recursos disponibles. ¿Cómo se rastrearon y resolvieron tales problemas?
3. Seguimiento y estadísticas en tiempo real.
Es posible bromear con un grado significativo de verdad que durante la duración de todo el campeonato tuvimos un puesto especial, cuyas tareas incluían mirar atentamente el fútbol en el lugar de trabajo. Por supuesto, no se trataba tanto del fútbol como tal, sino de la reacción inmediata ante cualquier incidente provocado por partidos u otras circunstancias ...
¿Cuáles son las "otras circunstancias"? En tales eventos públicos, incluso la influencia del clima es notable. Aquí hay dos ejemplos del campeonato que encontramos:
- Cuando comenzó una tormenta eléctrica durante uno de los partidos, los proveedores de televisión por satélite tenían problemas con el equipo (no podían enviar una señal). Esto condujo a un aumento notable en el tráfico (alrededor del 10%) en poco tiempo, porque en busca de una solución alternativa urgente, los espectadores comenzaron a conectarse en línea y continuar navegando allí.
- Cuando comenzó a llover durante el partido final, se notó un pequeño salto (aproximadamente el 3%) en la desconexión y reconexión de los usuarios (después de aproximadamente 5 minutos). En este caso, no se observaron problemas en la transmisión en sí, es decir, las razones del salto no tenían una base técnica. La suposición es que los espectadores que vieron fútbol en la calle (como yo mismo lo hice) se mudaron a la habitación debido a la lluvia, y durante este breve tiempo se desconectaron de la transmisión.
Volviendo al tema del monitoreo en sí mismo, durante la duración de todo el campeonato, la
práctica de reuniones regulares (después de cada transmisión pico) se tomó como norma con los desarrolladores, quienes analizaron todas las situaciones críticas (o cercanas a esas) y sus consecuencias, para minimizar los posibles problemas en la proxima vez ¿Qué servidores / servicios estaban en el límite? ¿Qué consultas fueron especialmente exigentes? ¿Qué solicitudes se pueden eliminar (transferir a CDN a la memoria caché durante unos segundos)? ¿Qué solicitudes se pueden almacenar en caché por más tiempo (cada 3 minutos, no por minuto)? ¿Qué pasará con el aumento proyectado en el número de espectadores, porque Rusia jugará? ..
Hablando de Rusia. Como puede suponer, en promedio varias veces más personas asistieron a los partidos con el equipo nacional ruso que otros. Y cuanto más avanzó nuestro equipo en el grupo de torneos, más difícil fue combinar nuestra alegría en este asunto con el desempeño de tareas inmediatas, porque todo se complicó por el crecimiento incansable de la audiencia. A pesar de que el sistema fue diseñado para soportar cargas enormes, en el horario normal de trabajo no ocurren con tanta frecuencia (menos de 10 veces al año) ... y en el caso de la Copa del Mundo, observamos picos de carga casi diarios durante un mes. La ventaja de este modo, sin embargo, fue la gran posibilidad de detectar cuellos de botella reales que solo se detectan en los momentos de tales cargas.Entonces, si parte de los problemas puramente técnicos se eliminó mediante gráficos estándar de los sistemas de monitoreo, en la solución de problemas más complejos y / o orientados a la lógica de negocios, los logros del proyecto bajo el nombre interno de "Estadísticas en tiempo real" jugaron un papel importante.
Estadísticas en tiempo real
Este importante componente de la infraestructura de transmisión por Internet fue diseñado e implementado por nuestros esfuerzos para proporcionar una herramienta de inteligencia empresarial para los datos técnicos recopilados de los jugadores en los que los usuarios ven videos. En esencia, es un sistema de registro que:
- recopila todo tipo de datos disponibles sobre los usuarios (navegador, IP, etc.), por simplicidad, podemos decir que estas son las características que solíamos ver en las estadísticas sobre la audiencia del sitio);
- los complementa con datos técnicos sobre transmisión (tasa de bits, etc.) y eventos / problemas que han ocurrido (cambio de CDN, fallas de visualización ...);
- proporciona al equilibrador datos para un equilibrio de carga óptimo en servidores CDN (de acuerdo con las características de cada usuario);
- envía las alertas necesarias a los ingenieros de servicio y crea gráficos comerciales útiles.
El último punto es el más interesante, porque:
- Las alertas de este sistema de estadísticas son un componente clave de la supervisión que le permite "mantenerse al día" de los indicadores prácticos durante las transmisiones. Analizándolos (en un lugar donde la automatización no es suficiente), el asistente toma las decisiones apropiadas para mejorar la calidad del servicio en tiempo real. Por ejemplo:
- ¿Muchos usuarios se cambiaron del mismo servidor CDN? Debe deshabilitarse temporalmente de la rotación (o contactar al proveedor para una respuesta rápida).
- ¿Han comenzado los usuarios a experimentar problemas masivos viendo videos? Tiempo para un análisis urgente de las causas.
- Los gráficos son estadísticas comerciales en tiempo real que le permiten responder preguntas clave, como:
- ¿Cuántos usuarios vieron la transmisión de último minuto?
- ¿Qué porcentaje de usuarios tuvo problemas en el último minuto y cuál era su naturaleza?
Dado que eventos similares tienen el mismo perfil de gráfico, el gráfico en sí mismo le permite predecir el crecimiento en el número de usuarios en los próximos minutos y tomar medidas proactivas si es necesario.
Dado que estas estadísticas funcionan en tiempo real y son críticas para la calidad de todo el servicio, incluso la visualización de videos de naturaleza simple por millones de usuarios no se reduce a la distribución de contenido a través de CDN. ClickHouse DBMS ayuda a lograr una grabación rápida de nuevos datos de numerosos jugadores (estamos hablando de decenas de miles de solicitudes por segundo para grabar en cada servidor), y el Grafana habitual se usa para gráficos.
Ilustración de la proporción de espectadores de video en línea antes, durante y después del partidoPor cierto : una solución interesante durante las cargas máximas fue deshabilitar HTTPS (a favor de HTTP) para las solicitudes del sistema de estadísticas, lo que condujo a una reducción doble en la carga de la CPU en algunos de los servidores.Resumen
El éxito de las transmisiones en línea de un evento a gran escala
(¡incluso YouTube TV no siempre hizo frente a las cargas!) Fue proporcionado por tres factores clave:
- arquitectura competente (para el sistema de transmisión y el sitio), que incluso sin el uso de sistemas modernos como Kubernetes se orientó inicialmente a altas cargas, escalabilidad y preparación para explosiones significativas;
- Servidores CDN con suficiente ancho de banda;
- monitoreo especializado, que permitió: a) rastrear problemas en tiempo real, b) proporcionar la información necesaria para evitarlos en el futuro.
Aunque en realidad hubo más factores ... y uno de ellos, tal vez, es capaz de superar todos los técnicos: humanos. El papel más importante lo desempeñaron especialistas que no solo pudieron hacer y vincular todo lo necesario técnicamente, sino que también lograron resultados incansablemente, lo que quiero señalar especialmente los méritos de la gestión del cliente.
PD: sobre los Kubernetes mencionados ... una historia que muchos lectores de nuestro blog pueden haber esperado ver. El proceso de migración del sistema de transmisión a él ya ha comenzado, pero durante la Copa Mundial, estos desarrollos aún no estuvieron involucrados.PPS
Lea también en nuestro blog: