node.js - servidores - docker amazon tutorial

¿Cuál es la forma óptima de ejecutar una API de nodo en Docker en Amazon ECS?

Question

Con el advenimiento de la ventana acoplable y los servicios de planificación y orquestación como el ECS de Amazon, estoy tratando de determinar la manera óptima de implementar mi API de nodo. Con Docker y ECS a un lado, he querido aprovechar la biblioteca de clústeres de nodos para manejar con gracia el bloqueo de la aplicación del nodo en caso de un error asíncrono como se sugiere en la documentation , al crear un proceso maestro y varios procesadores de trabajo.

Uno de los beneficios del enfoque de clúster, además de manejar los errores con gracia, es crear un procesador de trabajo para cada CPU disponible. Pero, ¿tiene sentido esto en el mundo de los portuarios? ¿Tendría sentido tener múltiples procesos de nodo ejecutándose en un solo contenedor de ventana acoplable que se escalaría en un clúster de instancias de EC2 en ECS?

Sin el enfoque de agrupación de nodos, perdería la capacidad de manejar los errores con gracia y, por lo tanto, creo que, como mínimo, debería ejecutar un maestro y un proceso de trabajo por contenedor de ventana acoplable. Todavía estoy confundido en cuanto a la cantidad de CPU para definir en la Definición de Tarea para ECS. La documentación de ECS dice algo sobre cada instancia de contenedor que tiene 1024 unidades por CPU; pero eso no es lo mismo que las unidades de cómputo EC2, ¿verdad? Y dicho esto, necesitaría elegir los tipos de instancia EC2 con la cantidad adecuada de vCPU para lograr este derecho?

Entiendo que lograr la configuración más óptima puede requerir algún nivel de evaluación comparativa de mi aplicación específica de API de nodo, pero sería increíble tener una mejor idea de dónde comenzar. Tal vez hay algo de estudio / investigación que necesito hacer? ¡Cualquier sugerencia para guiarme en el camino o las recomendaciones serán las más apreciadas!

Edición: Para recapitular mis preguntas específicas:

1. ¿Tiene sentido ejecutar un clúster maestro / trabajador tal como se describe documentation dentro de un contenedor de la ventana acoplable para lograr un bloqueo correcto?

2. ¿Tendría sentido usar un código casi idéntico como se describe en los documentos de Cluster, para ''escalar'' a las CPU disponibles a través de require(''os'').cpus().length ?

3. ¿Qué quiere decir Amazon en la documentación de Definiciones de tareas de ECS, donde se dice para la configuración de la cpus , que una container instance has 1024 units per CPU ? ¿Y cuál sería un buen punto de partida para esta configuración?

4. ¿Cuál sería un buen punto de partida para el tipo de instancia que se usará para un clúster de ECS destinado a servir una API de nodo basada en lo anterior? ¿Y cómo afectan las vCPU disponibles a las preguntas anteriores?

Answer 1

En el mundo de la ventana acoplable, ejecutaría 1 nodejs por contenedor de la ventana acoplable, pero ejecutaría muchos de estos contenedores en cada una de sus instancias de EC2. Si usa algo como fig , puede usar fig scale <n> para ejecutar muchos contenedores redundantes en una instancia. De esta manera, no tiene que definir su cuenta de nodejs con anticipación y cada uno de los procesos de nodejs está aislado de los demás.

Answer 2

Eso parece un patrón realmente bueno. Es similar a lo que se hace con Erlang / OTP, y no creo que nadie diría que es uno de los sistemas más robustos del planeta. Ahora la pregunta es cómo implementar.

Aprovecharía los patrones de Heroku u otros sistemas de PaaS similares que tienen un poco más de madurez. No estoy diciendo que amazon sea el lugar equivocado para hacer esto, sino simplemente que se ha trabajado mucho con esto en otras áreas que puede traducir. Por ejemplo, este artículo tiene una receta en él: https://devcenter.heroku.com/articles/node-cluster

En cuanto a las relaciones entre vCPU y unidades de cómputo, parece que es solo una proporción recta de 1/1024. Es un movimiento hacia los microcharges basados ​​en la utilización de la CPU. Ellos están llevando esto aún más lejos con el trabajo lambda. Te están cobrando en base a las fracciones de segundo que utilizas.

Answer 3

Todas estas tecnologías son nuevas y aún se están estableciendo las mejores prácticas, por lo tanto, considérelas solo como sugerencias basadas en mi experiencia.

Un proceso por contenedor es más una sugerencia que una regla dura y rápida. Está bien ejecutar múltiples procesos en un contenedor cuando tiene un uso para ello, especialmente en este caso donde un proceso maestro bifurca a los trabajadores. Simplemente use un solo contenedor y permita que se bifurque un proceso por núcleo, como sugirió en la pregunta.

En EC2, los tipos de instancia tienen una cantidad de vCPU, que aparecerán como un núcleo para el sistema operativo. Para el clúster ECS, use un tipo de instancia EC2 como c3.xlarge con cuatro vCPU. En ECS esto se traduce en 4096 unidades de CPU. Si desea que la aplicación haga uso de las 4 vCPU, cree una definición de tarea que requiera 4096 unidades de CPU.

Pero si está haciendo todo esto solo para evitar que la aplicación se bloquee, también podría usar una política de reinicio para reiniciar el contenedor si se bloquea. Sin embargo, parece que ECS aún no admite las políticas de reinicio.