¿Debo usar AWS Elastic Beanstalk o Amazon EC2 Container Service (ECS) para escalar contenedores Docker?

Desarrollé una aplicación basada en Docker compuesta por múltiples microservicios. Tiene que consumir mensajes de Amazon SQS y procesarlos. Al principio, quería usar AWS Elastic Beanstalk, pero luego me caí del EC2 Container Service. Ahora no sé cuál elegir.

A partir de ahora, Elastic Beanstalk admite entornos de contenedores múltiples. Eso es genial porque cada microservicio tiene su propio servidor de aplicaciones dentro de un contenedor Docker. El siguiente problema es la escala:

No sé cómo funciona el mecanismo de escalado. Por ejemplo: tengo 5 contenedores de Docker en mi Elastic Beanstalk Environment. Ahora solo el quinto contenedor de la ventana acoplable está bajo una gran carga, porque tiene una gran cantidad de mensajes SQS para procesar, los otros cuatro están casi inactivos, porque no necesitan mucha CPU o tal vez no tienen muchos mensajes SQS. Supongamos que el quinto contenedor ejecuta un servidor de aplicaciones JBoss. Hasta donde yo sé, el servidor solo puede consumir una cantidad limitada de solicitudes paralelas incluso si hay suficiente CPU / memoria disponible.

Si el contenedor JBoss Docker no puede manejar la cantidad de solicitudes, pero hay suficiente CPU / memoria disponible, por supuesto, quiero iniciar automáticamente un segundo contenedor Docker / JBoss en la misma instancia. Pero, ¿qué pasa si no tengo suficiente CPU / memoria? Por supuesto, quiero girar en una segunda instancia, que se puede configurar a través de un grupo de escalado automático en EB. Ahora se activa una segunda instancia, pero todos los contenedores excepto el quinto están casi inactivos, por supuesto, no quiero que generen 4 innecesarios en la segunda instancia también, lo que sería un desperdicio de recursos. Solo el quinto debería aparecer y los otros deberían escalar como la quinta escala en función de parámetros configurables como, por ejemplo: CPU / memoria / SQS.

No sé exactamente si Amazon ECS está haciendo eso, o si es posible en absoluto, pero realmente no puedo encontrar ninguna fuente en Internet sobre este tema, que en general se dice, escalado basado en instancias / contenedores.

EB vs ECS realmente se reduce al control. ¿Desea controlar su escalamiento y capacidad o desea tener eso más abstracto y, en cambio, concentrarse principalmente en su aplicación? ECS le dará el control, ya que debe especificar el tamaño y la cantidad de nodos en el clúster y si se debe utilizar o no el escalado automático. Con EB, simplemente proporciona un Dockerfile y EB se encarga de escalar su aprovisionamiento de número y tamaño de nodos, básicamente puede olvidarse de la infraestructura con la ruta EB.

Aquí está la documentación de EB en Docker: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html

Con ECS, primero tendrá que construir la infraestructura antes de poder comenzar a implementar el Dockerfile, por lo que realmente se reduce a 1) su familiaridad con la infraestructura y 2) el nivel de esfuerzo que desea invertir en la infraestructura frente a la aplicación.

No para resucitar una pregunta muerta, pero espero que esto ayude a alguien.

La respuesta aceptada no es lo suficientemente clara: según lo que OP describió, OP quiere ECS, no Multi-Container Elastic Beanstalk (MCEB). Por lo que puedo decir, MCEB nunca intenta empaquetar contenedores de manera eficiente en instancias. OP pregunta en un comentario, "si solo uno está bajo carga, escala solo este, o ¿siempre escala las instancias e inicia todos los contenedores, sin importar la carga que tengan?" Y la respuesta es "lo último"; MCEB escala las instancias e inicia todos los contenedores, sin importar la carga que tengan.

Editar

No uses la arquitectura que estás imaginando.

¿Qué tan micro son sus microservicios? ¿Sería ridículo darles a cada uno un t2.nano? Luego, conviértalos en una aplicación Docker EB de un solo contenedor: las aplicaciones de trabajo EB pueden ser controladas por mensajes SQS. O use apex.run .

Editar 31/01/18:

AWS Fargate parece bastante bueno.

Editar 5/6/19:

Use EKS si necesita orquestar contenedores, para satisfacer una picazón. Pero realmente, trate de evitar esto. Los sistemas distribuidos son difíciles.