Transloadit escala a 1500 máquinas para un encoding más rápido

El encoding es un trabajo duro para los servidores. Cuando empezamos este negocio, supimos desde el principio que a los clientes les resultaría mucho más fácil enviarnos Jobs de lo que a nosotros nos resultaría procesarlos. Dados los picos muy variables en los Encoding Jobs y un presupuesto finito, las colas son inherentes a este negocio.

Quien te diga lo contrario, o no está operando a escala, o está perdiendo dinero.

Picos y colas

Algunas personas integran las capacidades de subida de Transloadit para que sus usuarios finales puedan subir avatares a sus sitios web. Obviamente, no es aceptable que esas personas tengan que esperar cuatro horas a que se redimensione su avatar, solo porque estamos optimizando la biblioteca de 500 videos de otra persona para su visualización en iPad.

Por esa razón, hay que minimizar las colas y su impacto en los distintos casos de uso:

Para abordar el impacto, escribimos algoritmos capaces de distinguir los Jobs que deben percibirse en tiempo real, como la subida y el redimensionado de avatares, de los Jobs a los que se les permite tardar un poco más, como la conversión de grandes lotes de archivos multimedia existentes.

Esperar cuatro horas más es desastroso para el caso de uso de tres segundos, mientras que esperar tres segundos más está bien para el caso de uso de cuatro horas. Las prioridades importan.

Por supuesto, sería aún mejor si las 4 horas pudieran reducirse a diez minutos.

Para abordar las colas en sí, sabíamos que necesitábamos escalar. Como mencionamos, el tráfico de encoding puede ser muy irregular. Para vaciar rápidamente las colas largas, necesitaríamos una capacidad base muy grande.

Por desgracia, necesitaríamos esa capacidad solo para gestionar los picos. El 90 % del tiempo restante estaría pudriéndose en centros de datos, evaporando su valor. Sería extremadamente difícil convertir ese modelo en un negocio rentable.

Y entonces llegó Amazon.

La nube de Amazon

Amazon tenía un problema similar con picos de tráfico enormes durante las ventas navideñas. Obviamente, no podían rechazar a nadie y tenían que invertir en tantos servidores como fuera necesario para gestionar esos picos.

Pero durante el resto del año, ese equipamiento caro no les generaba dinero alguno.

Por esa época, el departamento de TI de Amazon estaba explorando maneras de aprovechar la virtualización para hacer su plataforma más mantenible. Solo poder reinstalar la mayoría de los servidores sin tener que ir al centro de datos ya era una gran victoria. Jeff Bezos había emitido un memorando tiempo antes: cualquier servicio construido dentro de Amazon debía diseñarse de tal manera que a otras empresas también les resultara fácil usarlo.

Después abrieron al mundo sus herramientas de administración de virtualización y pudieron alquilar su sobrecapacidad, lo que les permitió ganar algo de dinero con esos servidores inactivos fuera de la temporada navideña.

Y así nació la nube 🐣. O al menos, esta es mi versión simplificada 😄. Si lees esto y piensas que digo tonterías, dímelo en twitter⁠ y refinaré este glorioso relato.

Transloadit ❤️ Amazon

Como mencionamos, no podríamos permitirnos el tipo de capacidad necesaria para gestionar los picos. Quizá habríamos podido convencer a un inversor de que la financiara, pero, como decíamos, es extremadamente difícil obtener beneficios cuando las máquinas no hacen nada la mayor parte del tiempo.

Sin embargo, cuando se nos ocurrió la idea de Transloadit, Amazon acababa de quitar la etiqueta beta de su oferta en la nube: AWS⁠, y pudimos alquilar capacidad de servidor por hora. Y gracias a su API, pudimos escribir software para hacerlo automáticamente, a medida que el tráfico crecía.

Como ves, les debemos nuestra existencia.

Techos de cristal

Con la promesa de la nube de Amazon, pensamos que el cielo era el límite. «¡Capacidad ilimitada!» «¡Solo cuando realmente la necesitemos!». Y recuerdo lo felices que estábamos al funcionar en nuestra primera máquina potente:

Pero había algunos techos de cristal. Cuando intentamos lanzar seis máquinas, nos encontramos con errores. Resultó que:

Cuando creas tu cuenta de AWS, AWS establece límites de instancias por región.

Nuestro límite estaba fijado en cinco máquinas, y una cola que teníamos en ese momento tardó una eternidad en vaciarse.

Siempre hemos tenido buenos encuentros con Amazon; incluso nos ayudaron a ganar algo de visibilidad⁠ en los primeros días. Nos pusimos en contacto rápidamente, y ellos nos concedieron rápidamente un nuevo «techo de instancias» con un máximo de 20 máquinas.

Estábamos encantados 😄 porque validaba lo que intentábamos hacer, y acabábamos de romper un techo de cristal.

Desde entonces, hemos tenido que contactar con Amazon algunas veces más para aumentar nuestro techo de instancias. La última vez fue el 5 de noviembre de 2013, cuando Amazon nos concedió un límite de 500 máquinas en nuestro centro de datos principal.

Patrones de escalado

Últimamente hemos visto que el tráfico repunta de nuevo siguiendo este patrón:

El gráfico muestra que las máquinas se escalan a medida que se lanzan Encoding Jobs a la cola, pero cuando escalamos hasta 500 máquinas, la línea se aplana y la cola de 5 TB se procesa más lentamente de lo que nos gustaría.

Normalmente, le enviaríamos un email rápido a Amazon, pero resulta que:

Para un aumento de límite de este tamaño, necesitaré colaborar con nuestro equipo de servicio para obtener la aprobación. Esto es para asegurar que podamos satisfacer tus necesidades manteniendo segura la infraestructura existente.

Sé que se estima que Amazon tiene alrededor de 450.000 servidores (de hardware)⁠, así que a su escala seguimos siendo peces pequeños. Aun así, que tuvieran que hacer algo de planificación adicional de recursos para esta solicitud resultó emocionante.

Entenderás que hoy esté aún más emocionado por el email que acabamos de recibir y que dice:

Me complace informarte de que hemos aprobado y procesado tu solicitud de aumento de límite de instancias EC2 para las regiones EU (Ireland) y US East (Northern Virginia). A veces puede tardar hasta 15 minutos en propagarse y quedar disponible para su uso.

Gracias a este nuevo techo de instancias, ahora podemos escalar una flota de 1000 máquinas en EE. UU. y 500 en la UE, lo que significa que habremos más que duplicado nuestra capacidad:

Esto no quiere decir que ya estemos funcionando con 1500 máquinas, pero contar desde hoy con ese margen es un gran avance para nosotros, y poder aprovecharlo será de gran ayuda para vaciar rápidamente las colas de encoding de varios terabytes que hemos visto con más frecuencia últimamente.

¡Para ti como cliente, esto significa tiempos de encoding más rápidos y que podemos manejar importaciones masivas de video HD como si fueran un pequeño avatar! 😉