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

81

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.

orbatschow
fuente
¿Sientes que tu problema ha sido resuelto? Tengo una preocupación muy similar con respecto a EB, sospecho que lanza los 5 contenedores en una instancia separada
Cameron Singe
3
También estoy confundido. La respuesta seleccionada no explica realmente cómo funciona el escalado en ambos servicios. Además, ¿ECS / EB realmente patea otro quinto contenedor y luego ejecuta ambos en paralelo en la misma instancia si hay suficientes recursos?
codepushr

Respuestas:

69

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.

Alanwill
fuente
7
Sí, pero ¿cómo funciona el mecanismo de escalado automático de ambos servicios? ¿Elastic Beanstalk escala los contenedores, por contenedor, de modo que si solo uno está bajo carga, solo escala este, o siempre escala las instancias e inicia todas? contenedores, sin importar la carga que se encuentren?
orbatschow
6
Ahora que ECS es GA, EB aprovecha ECS para proporcionar su infraestructura de contenedores múltiples. El autoescalado se realiza utilizando la primitiva típica de grupo de autoescalado de EC2. Sin embargo, el factor desencadenante para escalar hacia arriba o hacia abajo no es el contenedor, sino el nodo de la instancia. Es decir, si el tráfico de la interfaz de red, la carga de la CPU o la carga del disco alcanzan un cierto umbral, entonces el clúster puede escalar horizontalmente o hacia adentro. Por lo tanto, en su ejemplo, si el nodo del quinto contenedor estaba bajo una gran carga de CPU, podría establecer un activador de grupo de escalado automático basado en ese.
Alanwill
También tenga en cuenta que puede seguir con el enfoque ECS más controlado y orientado a contenedores y aplazar la responsabilidad del control del clúster mediante AWS Fargate .
dmulter
¿Qué hay de los precios? ¿Es diferente?
Daniel Vilela
12

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.

Sam H.
fuente
1
Hace exactamente esto. Para nosotros, eso no es un gran problema porque estructuramos nuestras aplicaciones de forma apilada donde generalmente está bien que se escalen juntas. Si es necesario que una aplicación se amplíe de forma independiente, diría que debería ser otra aplicación en EB. Realmente estoy tratando de pensar en un buen escenario donde esto sea necesario. He estado leyendo muchos casos de personas que manifiestan este deseo y no puedo decidir si es solo académico, un problema de diseño o un caso realmente válido.
Jacob Thomason