De una flota elástica a serverless: migrando la infraestructura de webinars a AWS Fargate

Contexto

A estas alturas, la plataforma de webinars del cliente ya funcionaba sobre una flota elástica de instancias EC2 grandes, orquestada por contenedores para crecer y encogerse según la demanda. Mirar de cerca los patrones de uso reales contaba una historia más clara: los webinars se concentraban abrumadoramente en horario laboral, de 9 a 12 y de 14 a 20 en la hora local del cliente, y casi nunca de madrugada, de 1 a 5. Incluso el mínimo que el sistema mantenía siempre listo (su propio servicio de control más una instancia EC2 caliente) suponía un coste real y constante; con instancias tan grandes, ese suelo de inactividad se traducía en dinero real, todos los días.

El proyecto

1. AWS Fargate acababa de lanzarse, permitiendo ejecutar contenedores sin gestionar en absoluto la flota de EC2 por debajo. Como la plataforma ya funcionaba sobre Docker, este era un paso natural, no una reescritura.
2. Pensarlo como "contenedores serverless" hizo obvia también la siguiente decisión: sustituir el propio servicio de control alojado en EC2 por AWS Lambda, una capa event-driven y serverless a la altura.
3. Diseñamos un pool de tareas de Fargate con un ciclo de vida real de estados propios (solicitada, arrancando, en ejecución, drenando, detenida), gestionado por funciones Lambda que reaccionan a eventos reales de los webinars en lugar de un proceso siempre activo preguntando si hay trabajo.
4. Los límites reales de AWS se interponían si esto se hacía de forma ingenua. Lanzar una tarea de Fargate es mucho más rápido que arrancar una instancia EC2 nueva, pero la propia API de AWS limita cuántos lanzamientos de tareas pueden ocurrir a la vez (del orden de 10 cada 10 segundos), así que una ráfaga real de demanda simultánea todavía podía acumularse y notarse lenta para los usuarios. La solución, acordada junto con el cliente: dejar que los webinars programados se registraran con antelación, de forma que su capacidad pudiera reservarse y precalentarse en lugar de solicitarse en frío en el último momento.

Nuestro papel

• Diseñar el pool de tareas de Fargate y sus estados de ciclo de vida.
• Sustituir el servicio de control alojado en EC2 por una orquestación event-driven basada en Lambda.
• Trabajar con el cliente en el diseño del mecanismo de reserva para los webinars programados, para respetar los límites reales de AWS sin que los usuarios lo notaran.
• Migrar la plataforma de principio a fin, desde la anterior flota de EC2 y contenedores hasta la nueva arquitectura serverless, sin interrumpir un producto en vivo y todavía en crecimiento.

Tecnologías

• AWS Fargate, para ejecutar contenedores sin gestionar la flota de EC2 subyacente.
• AWS Lambda, para una orquestación event-driven que sustituye al antiguo servicio de control siempre activo.
• Contenedores Docker, sin cambios respecto a la arquitectura ya existente de la plataforma.

Conclusión y lecciones aprendidas

Pasar de una infrastructura elástica a una genuinamente serverless no solo redujo el coste: eliminó toda una categoría de trabajo operativo (la gestión del ciclo de vida de EC2) que la arquitectura anterior llevaba integrada como un coste fijo del negocio. La lección real fue que "elastic" y "serverless" no son lo mismo: la primera te sigue pidiendo gestionar máquinas, aunque de forma más eficiente; la segunda plantea una pregunta genuinamente distinta: qué infraestructura es realmente necesaria en cada momento.