M6 ha hecho de la Eurocopa 2024 un escaparate para el canal, con la retransmisión de 13 partidos de esta competición, incluida la final (prevista para el 14 de julio). De ahí la necesidad de ofrecer una calidad de servicio impecable en el sitio web de medios, M6+ (antes 6play), que ofrece retransmisiones en directo de los partidos, así como múltiples repeticiones (partidos completos, goles, resúmenes, resúmenes). Tras algunos problemas registrados durante la anterior competición europea de fútbol en 2020, la empresa conjunta de M6 y RTL optó por priorizar la disponibilidad del servicio sobre la optimización de costes. Si bien 6play suele funcionar al 100% en instancias puntuales en la nube de AWS (es decir, capacidad informática no utilizada), el sitio se beneficia de máquinas reservadas e instancias bajo demanda más caras para la competición actual. “A esto hay que sumarle las limitaciones para los equipos, aunque es imposible añadir máquinas indefinidamente, debido al riesgo de saturación de las API en Kubernetes”, subraya Jean-Yves Camier, que dirige un equipo Devops que trabaja en el núcleo de la aplicación M6+.

La nube pública no responde lo suficiente

Pero más allá de los recursos financieros destinados al evento, el principal desafío para Bedrock Streaming, la filial digital del grupo que produce la base técnica y opera los sitios M6 y RTL, es gestionar unas audiencias que, estructuralmente, son muy fluctuantes. Un problema que Jean-Yves Camier conoce bien, ya que, en el fondo, no es tan diferente del que suele experimentar el sitio del canal, con audiencias bastante modestas durante el día y saltos cuando hay un programa disponible o para las transmisiones en vivo por la noche. "Y, con el fútbol, ​​todo el mundo llega a la plataforma a la misma hora y vuelve a la misma hora, después del descanso", subraya el responsable del equipo Devops. "Un problema que ya conocíamos en programas como Top Chef".

"Este perfil de audiencia plantea problemas de escalabilidad, incluso con la nube pública e incluso con Kubernetes", afirma Jean-Yves Camier. "Por lo tanto, es necesario 'precalentar' los entornos". Dado que el tiempo de disponibilidad de un nuevo entorno técnico en AWS, la nube operada por Bedrock, es de entre 3 y 6 minutos, es necesario aprovisionar los recursos necesarios antes de los picos de audiencia. Por supuesto, la empresa conjunta formada por M6 y el grupo RTL ha empezado a utilizar la tecnología Karpenter, que reduce el aprovisionamiento en Kubernetes a alrededor de un minuto, pero el componente Open Source, todavía relativamente joven a ojos de Jean-Yves Camier, actualmente solo se utiliza con entornos de integración continua.

Un componente para automatizar el escalamiento

Para gestionar las variaciones de tráfico en la producción, Bedrock Streaming se basa ahora en una programación que anticipa la carga que manejará el sitio, con un sistema de multiplicación de entornos en función de las franjas horarias. "Utilizamos este mismo principio para los partidos de la Eurocopa, añadiendo una configuración específica para DynamoDB (base de datos NoSQL de AWS, n.º del editor)", explica el especialista. Una parte del proceso ya está equipada, con los administradores de canales que introducen las audiencias previstas en un calendario de Google. La noche del 25 de junio y el día siguiente (durante los partidos de la fase de grupos), Bedrock Streaming había previsto cuadriplicar la infraestructura técnica de su sitio en comparación con el nivel estándar. "El escalado es automático y está respaldado por un pequeño desarrollo en Go, disponible en Nuestro GitHub"En el futuro, nos gustaría integrar esta programación directamente en el back office", afirma Jean-Yves Camier. "Gracias a este principio, M6+ puede reunir a los varios millones de usuarios que acuden a los partidos.

Valentin Chabrier, ingeniero DevOps en Bedrock Streaming, y Jean-Yves Camier, Tech Lead & Manager en la misma entidad, que cuenta con unas 400 personas. (Foto: DR)

Más allá de la escalabilidad de los entornos cloud, este tipo de eventos también pone de relieve los límites intrínsecos de las aplicaciones. Esta es una de las razones por las que Bedrock Streaming se interesó por las pruebas de carga. “Realizamos experimentos iniciales en este ámbito hace dos años, pero la solución en aquel momento era difícil de utilizar”, subraya Jean-Yves Camier. Por ello, la empresa conjunta especializada en streaming migró a principios de año a la herramienta del editor francés Gatling. “En una semana, pudimos identificar un gran número de áreas de mejora”, continúa el experto. “La observabilidad que proporciona la solución de forma nativa es muy importante en un entorno de microservicios”.

Ve a liberarte de las limitaciones de PHP

Además de estas pruebas basadas en escenarios construidos a principios de año y actualizados regularmente para adaptarse cada vez más a las prácticas de los usuarios de Internet, Bedrock Streaming también ha abordado un trabajo en profundidad: reescribir la aplicación M6+ en Go, para superar las limitaciones de PHP (como la necesidad de implementar un proxy inverso, la repetición de handshakes para cada solicitud HTTPS, etc.). "Hoy en día, el trabajo de migración se está priorizando en función de la carga soportada por los diferentes componentes", explica Jean-Yves Camier. Un candidato para esta reescritura prioritaria podría ser la API Gateway, un componente PHP que hace un uso intensivo de la gestión de caché y que está llegando a los límites del servicio dedicado de AWS, Redis.

La solución de pruebas Gatling también debería integrarse en esta estrategia de migración hacia el lenguaje Go. "Hemos rediseñado un mini-framework Go que ofrece los mismos componentes que Symfony. Estamos intentando concienciar a los desarrolladores sobre el rendimiento desde el principio, integrando herramientas de benchmarking de Go. El siguiente paso consistirá en realizar pruebas de carga en cada servicio de la aplicación y monitorear estos rendimientos a lo largo del tiempo", explica Jean-Yves Camier.