Cómo ayudamos a CDN MegaFon.TV a no llegar a la Copa Mundial 2018

En 2016, hablamos sobre cómo MegaFon.TV hizo frente a todos los que querían ver la nueva temporada de Game of Thrones. El desarrollo del servicio no se detuvo allí, y a mediados de 2017 tuvimos que lidiar con cargas varias veces más. En esta publicación, diremos cómo un crecimiento tan rápido nos inspiró a cambiar radicalmente el enfoque para organizar CDN y cómo este nuevo enfoque fue probado por la Copa del Mundo.

Brevemente sobre MegaFon.TV

MegaFon.TV es un servicio OTT para ver diversos contenidos de video: películas, programas de televisión, canales de televisión y programas grabados. A través de MegaFon.TV, se puede obtener acceso al contenido en prácticamente cualquier dispositivo: en teléfonos y tabletas con iOS y Android, en televisores inteligentes LG, Samsung, Philips, Panasonic de diferentes años de lanzamiento, con todo un zoológico de SO (Apple TV, Android TV), en navegadores de escritorio en Windows, MacOS, Linux, en navegadores móviles en iOS y Android, e incluso en dispositivos tan exóticos como STB y proyectores de Android para niños. Prácticamente no hay restricciones en los dispositivos: solo es importante la disponibilidad de Internet con un ancho de banda de 700 Kbps. Sobre cómo organizamos el soporte para tantos dispositivos, habrá un artículo separado en el futuro.
La mayoría de los usuarios del servicio son suscriptores de MegaFon, lo que se explica por las ofertas rentables (y casi siempre incluso gratuitas) incluidas en el plan de tarifas del suscriptor. Aunque también notamos un aumento significativo en los usuarios de otros operadores. De acuerdo con esta distribución, el 80% del tráfico de MegaFon.TV se consume dentro de la red MegaFon.

Arquitectónicamente, desde el lanzamiento del servicio, el contenido se ha distribuido a través de CDN. Tenemos una publicación separada dedicada al trabajo de este CDN. En él, hablamos sobre cómo nos permitió manejar el tráfico pico que entró al servicio a fines de 2016, durante el lanzamiento de la nueva temporada de Game of Thrones. En esta publicación, hablaremos sobre el mayor desarrollo de MegaFon.TV y sobre nuevas aventuras que han caído en el servicio junto con la Copa Mundial 2018.

Servicio de crecimiento. Y problemas

En comparación con los eventos de la última publicación, a finales de 2017 el número de usuarios de Megafon.TV ha aumentado varias veces, las películas y series también se han vuelto un orden de magnitud más grande. Se lanzó una nueva funcionalidad, aparecieron nuevos paquetes, disponibles "por suscripción". Los picos de tráfico desde el "Juego de Tronos" que vemos ahora todos los días, la proporción de películas y programas de televisión en la corriente total ha aumentado constantemente.

Junto con esto, los problemas comenzaron con la redistribución del tráfico. Nuestro monitoreo, configurado para descargar fragmentos para diferentes tipos de tráfico en diferentes formatos, comenzó a producir cada vez más errores al descargar fragmentos de video por tiempo de espera. En el servicio MegaFon.TV, la longitud del fragmento es de 8 segundos. Si el fragmento no tiene tiempo para cargar en 8 segundos, pueden producirse errores.

Se esperaba que el pico de errores ocurriera en las horas más ocupadas. ¿Cómo debería afectar esto a los usuarios? Como mínimo, pudieron observar un deterioro en la calidad del video. No siempre se nota a simple vista, debido a un número suficientemente grande de perfiles de velocidad de bits múltiple. En el peor de los casos, el video se congela.

La búsqueda del problema comenzó. Casi de inmediato, quedó claro que se produce un error de retroceso en los servidores EDGE de CDN. Aquí tenemos que hacer una pequeña digresión y decir cómo funcionan los servidores con tráfico en vivo y VOD. El esquema es un poco diferente. Un usuario que acude al servidor EDGE en busca de contenido (una lista de reproducción o fragmento), si hay contenido en el caché, lo obtiene desde allí. De lo contrario, el servidor EDGE busca contenido en Origin y carga el canal principal. Junto con una lista de reproducción o un fragmento, se proporciona el encabezado Cache-Control: max-age , que le indica al servidor EDGE cuánto almacenar en caché esta o aquella unidad de contenido. La diferencia entre LIVE y VOD radica en el tiempo que lleva almacenar en caché los fragmentos. Para fragmentos en vivo, se establece un tiempo de almacenamiento en caché corto, generalmente de 30 segundos a varios minutos, esto se debe al poco tiempo de relevancia del contenido en vivo. Este caché se almacena en la RAM, ya que debe proporcionar constantemente fragmentos y reescribir el caché. Para los fragmentos de VOD, se establece más tiempo, desde varias horas hasta semanas e incluso meses, dependiendo del tamaño de la biblioteca de contenido y la distribución de sus vistas entre los usuarios. En cuanto a las listas de reproducción, generalmente se almacenan en caché en no más de dos segundos, o no se almacenan en caché en absoluto. Vale la pena aclarar que solo estamos hablando del llamado modo PULL de CDN, en el que funcionaban nuestros servidores. Usar el modo PUSH en nuestro caso no estaría completamente justificado.

Pero volvamos a encontrar el problema. Como ya hemos notado, todos los servidores trabajaron simultáneamente en la devolución de ambos tipos de contenido. Al mismo tiempo, los propios servidores tenían una configuración diferente. Como resultado, algunas máquinas se sobrecargaron con IOPS. Los fragmentos no tuvieron tiempo de escribir / leer debido al pequeño rendimiento, cantidad, volumen de discos, gran biblioteca de contenido. Por otro lado, las máquinas más potentes que recibieron más tráfico comenzaron a fallar en el uso de la CPU. Los recursos de la CPU se gastaron en atender el tráfico SSL y los fragmentos entregados a través de https, mientras que los IOPS en los discos apenas alcanzaron el 35%.

Lo que se necesitaba era un esquema que, a un costo mínimo, hiciera posible utilizar las capacidades disponibles de manera óptima. Además, seis meses más tarde comenzaría la Copa del Mundo y, según cálculos preliminares, los picos en el tráfico en vivo deberían haber aumentado seis veces ...

Nuevo enfoque para CDN

Después de analizar el problema, decidimos separar el VOD y el tráfico en vivo de acuerdo con diferentes PAD compuestos por servidores con diferentes configuraciones. Y también cree una función de distribución de tráfico y su equilibrio entre diferentes grupos de servidores. Había tres de esos grupos en total:

• Servidores con una gran cantidad de discos de alto rendimiento que son los más adecuados para almacenar en caché el contenido de VOD. De hecho, los discos SSD RI de la capacidad máxima serían los más adecuados, pero no había ninguno, y se necesitaría demasiado presupuesto para comprar la cantidad correcta. Al final, se decidió usar lo mejor que estaba disponible. Cada servidor contenía ocho discos SAS de 1TB y 10k en RAID5. De estos servidores se compiló VOD_PAD.
  
• Servidores con una gran cantidad de RAM para almacenar en caché todos los formatos posibles para la entrega de fragmentos en vivo, con procesadores capaces de manejar tráfico SSL e interfaces de red "gruesas". Utilizamos la siguiente configuración: 2 procesadores de 8 núcleos / 192 GB de RAM / 4 interfaces de 10 GB. De estos servidores se compiló EDGE_PAD.
  
• El grupo de servidores restante no puede manejar el tráfico VOD, pero es adecuado para pequeños volúmenes de contenido en vivo. Se pueden usar como reserva. De los servidores RESERVE_PAD fue compilado.
  

La distribución fue la siguiente:

Un módulo lógico especial se encargaba de elegir el PAD del que se suponía que el usuario recibiría el contenido. Aquí están sus tareas:

• Analice la URL, aplique el esquema anterior para cada solicitud de transmisión y emita el PAD requerido
  
• Descargue las interfaces EDGE_PAD cada 5 minutos ( y este fue nuestro error ), y cuando se alcanza el límite, cambie el exceso de tráfico a RESERVE_PAD. Para aliviar la carga, se escribió un pequeño script perl que devolvió los siguientes datos:
  - marca de tiempo : fecha y hora de actualización de los datos de carga (en formato RFC 3339);
  - total_bandwidth - carga actual de la interfaz (total), Kbps;
  - rx_bandwidth - carga actual de la interfaz (tráfico entrante), Kbps;
  - tx_badwidth : carga actual de la interfaz (tráfico saliente), Kbps.
  
• Dirija el tráfico en modo manual a cualquier PAD u servidor de Origin en caso de situaciones imprevistas, o si es necesario, trabaje en uno de los PAD. La configuración estaba en el servidor en formato yaml y permitía llevar todo el tráfico al PAD deseado, o el tráfico de acuerdo con uno de los parámetros:
  - Tipo de contenido
  - cifrado de tráfico
  - Tráfico pagado
  - tipo de dispositivo
  - Tipo de lista de reproducción
  - Región
  

Los servidores de origen han sido SSD con poco personal. Desafortunadamente, al cambiar el tráfico a Origin, HIT_RATE en fragmentos VOD dejó mucho que desear (alrededor del 30%), pero realizaron su tarea, por lo que no observamos ningún problema con los empaquetadores en CNN.

Como había pocos servidores para la configuración EDGE_PAD, se decidió asignarlos en las regiones con la mayor proporción de tráfico: Moscú y la región del Volga. Con la ayuda de GeoDNS, el tráfico se envió a la región del Volga desde las regiones de los distritos federales de Volga y Ural. El centro de Moscú sirvió al resto. Realmente no nos gustó la idea de entregar tráfico a Siberia y el Lejano Oriente desde Moscú, pero en total estas regiones representan aproximadamente 1/20 de todo el tráfico, y los canales de MegaFon resultaron ser lo suficientemente amplios para tales volúmenes.
Después del desarrollo del plan, se realizó el siguiente trabajo:

• En dos semanas, desarrolló la funcionalidad de cambiar CDN
  
• Se tardó un mes en instalar y configurar los servidores EDGE_PAD, así como expandir los canales para ellos.
  
• Tomó dos semanas dividir el grupo de servidores actual en dos partes, más otras dos semanas para aplicar la configuración a todos los servidores en la red y el equipo del servidor
  
• Y, finalmente, la semana se dedicó a las pruebas (desafortunadamente, no bajo carga, lo que luego afectó)
  

Resultó paralelizar parte del trabajo, y al final todo tomó seis semanas.

Primeros resultados y planes futuros

Después de la optimización, el rendimiento general del sistema fue de 250 Gb / s. La solución con la transferencia del tráfico VOD a servidores separados mostró inmediatamente su eficacia después de su lanzamiento a producción. Desde el comienzo de la Copa del Mundo, no ha habido problemas con el tráfico de VOD. Varias veces, por varias razones, tuve que cambiar el tráfico de VOD a Origin, pero en principio, también se las arreglaron. Quizás este esquema no sea muy efectivo debido al uso muy pequeño de la memoria caché, ya que obligamos a los SSD a sobrescribir constantemente el contenido. Pero el circuito funciona.

En cuanto al tráfico en vivo, los volúmenes correspondientes para probar nuestra decisión aparecieron con el inicio de la Copa del Mundo. Los problemas comenzaron cuando la segunda vez que enfrentamos el cambio de tráfico cuando llegamos al límite durante el partido Rusia-Egipto. Cuando el cambio de tráfico funcionó, todo se vertió en el PAD de respaldo. En estos cinco minutos, el número de solicitudes (curva de crecimiento) fue tan grande que la CDN de respaldo se obstruyó por completo y comenzó a generar errores. Al mismo tiempo, el PAD principal se lanzó durante este tiempo y comenzó a permanecer inactivo un poco:



De esto se extrajeron 3 conclusiones:

1. Cinco minutos todavía es demasiado. Se decidió reducir el período de descarga a 30 segundos. Como resultado, el tráfico en el PAD en espera dejó de crecer espasmódicamente:
   
   
2. Como mínimo, es necesario transferir usuarios entre PAD cada vez que se activa el interruptor. Esto debería proporcionar suavidad adicional de conmutación. Decidimos asignar una cookie a cada usuario (o más bien al dispositivo), según el cual el módulo responsable de la distribución comprende si el usuario debe dejarse en el PAD actual o si se debe realizar el cambio. Aquí la tecnología puede quedar a discreción de quien la implemente. Como resultado, no soltamos el tráfico en el PAD principal.
   
3. El umbral para la conmutación se estableció demasiado bajo, como resultado, el tráfico en el PAD de respaldo creció como una avalancha. En nuestro caso, fue un reaseguro: no estábamos completamente seguros de haber hecho el ajuste correcto del servidor (la idea, por cierto, fue tomada de Habr). El umbral se ha incrementado para el rendimiento físico de las interfaces de red.
   

Las mejoras tomaron tres días, y ya en el partido Rusia-Croacia, verificamos si nuestra optimización funcionó. En general, el resultado nos agradó. En su apogeo, el sistema procesó 215 Gbit / s de tráfico mixto. Este no era un límite teórico en el rendimiento del sistema: todavía teníamos un margen sustancial. Si es necesario, ahora podemos conectar cualquier CDN externo, si es necesario, y "tirar" el exceso de tráfico allí. Tal modelo es bueno cuando no desea pagar dinero sólido cada mes por usar el CDN de otra persona.

Nuestros planes incluyen un mayor desarrollo de CDN. Para empezar, me gustaría extender el esquema EDGE_PAD a todos los distritos federales; esto conducirá a un menor uso de canales. También se están realizando pruebas de circuito de redundancia VOD_PAD, y algunos de los resultados ahora parecen bastante impresionantes.

En general, todo lo hecho durante el año pasado me lleva a pensar que la CDN del servicio que distribuye contenido de video es imprescindible. Y ni siquiera porque le permite ahorrar mucho dinero, sino porque el CDN se convierte en parte del servicio en sí, afecta directamente la calidad y la funcionalidad. En tales circunstancias, entregarlo en las manos equivocadas es al menos irrazonable.