Diseñar una infraestructura elastic basada en contenedores para una plataforma de webinars en crecimiento

Contexto

El producto de webinars del cliente estaba creciendo más rápido que la infraestructura sobre la que corría. Los servidores propios eran caros de mantener y lentos de ampliar; cada ráfaga real de demanda suponía un ciclo de aprovisionamiento genuinamente lento y costoso. Para un producto todavía en pleno crecimiento, eso no era solo una molestia operativa: era un riesgo real para la sostenibilidad del propio modelo de negocio.

El proyecto

1. Diseñar desde cero el alojamiento de la plataforma en AWS EC2, usando instancias grandes capaces de ejecutar varias sesiones de webinar simultáneas cada una.
2. Empaquetar el servicio de webinars en contenedores Docker, y adoptar Docker Swarm, recién anunciado, para agrupar esos contenedores en clúster a lo largo de la flota de EC2.
3. Construir un servicio de control propio (internamente, "el master") sobre ese clúster: para cada webinar, decidir qué máquina debe ejecutar su contenedor; vigilar la demanda real y lanzar una nueva instancia EC2 en cuanto la capacidad real del clúster empieza a escasear.
4. Gestionar el desmontaje con el mismo cuidado. Cuando un webinar termina, su contenedor se retira, y el master comprueba si alguna máquina ha quedado inactiva. Una máquina inactiva no se apaga de inmediato: primero se marca para eliminación, un estado de cuarentena que impide que se coloque en ella ningún webinar nuevo, y solo se termina de verdad una vez que todo lo que ya corría en ella ha terminado, evitando que una máquina se apague a mitad de un webinar.

Nuestro papel

• Diseñar el servicio de control master: la lógica de colocación, escalado hacia arriba y desescalado seguro.
• Integrar Docker Swarm como capa de clustering en toda la flota de EC2, una herramienta genuinamente nueva y todavía en maduración.
• Diseñar y construir la nueva arquitectura de alojamiento del cliente, sustituyendo los servidores propios sin interrumpir un producto ya en producción y en crecimiento.

Tecnologías

• AWS EC2, instancias grandes ejecutando varias sesiones de webinar simultáneas cada una.
• Docker, para empaquetar el propio servicio de webinars.
• Docker Swarm, para agrupar en clúster los contenedores a lo largo de la flota de EC2.
• Un servicio de control propio, para la colocación según demanda y la gestión del ciclo de vida de las máquinas.

Conclusión y lecciones aprendidas

El cambio real aquí no fue simplemente pasarse a la nube; muchos productos lo hacen y siguen corriendo sobre una flota de tamaño fijo, dimensionada para su peor día. Fue tratar la propia capacidad como algo sobre lo que el sistema razonaba de forma continua, guiado por la demanda real en lugar de por un número decidido de antemano, lo que convirtió un problema de escalado lento e intensivo en capital en algo que la infraestructura resolvía por sí sola.