Каков оптимальный способ запуска Node API в Docker на Amazon ECS?


С появлением docker и служб планирования и оркестровки, таких как ECS Amazon, я пытаюсь определить оптимальный способ развертывания моего Node API. Помимо Docker и ECS, я хотел воспользоваться преимуществами библиотеки Node cluster для изящной обработки сбоя приложения node в случае асинхронной ошибки, как это предлагается в документации , путем создания главного процесса и нескольких рабочих процессоров.

Одно из преимуществ кластерного подхода, помимо изящная обработка ошибок-это создание рабочего процессора для каждого доступного процессора. Но имеет ли это смысл в мире докеров? Имеет ли смысл иметь несколько узловых процессов, работающих в одном контейнере docker, который будет масштабироваться в кластер экземпляров EC2 на ECS?

Без кластерного подхода к узлам я бы потерял способность изящно обрабатывать ошибки, и поэтому я думаю, что, как минимум, я должен запустить мастер-и один рабочий процессы на контейнер docker. Я все еще здесь. непонятно, сколько процессоров нужно определить в определении задачи для ECS. Документация ECS говорит что-то о каждом экземпляре контейнера, имеющем 1024 единицы на процессор; но это не то же самое, что вычислительные единицы EC2, не так ли? И с учетом сказанного, мне нужно будет выбрать типы инстансов EC2 с соответствующим количеством vcpu для достижения этого права?

Я понимаю, что достижение наиболее оптимальной конфигурации может потребовать некоторого уровня бенчмаркинга моего конкретного приложения Node API, но было бы здорово иметь лучшее представление о том, с чего начать. Может быть, есть какие-то исследования/исследования, которые мне нужно сделать? Любые указатели, чтобы направить меня на путь или рекомендации будут наиболее ценны!

Edit: чтобы резюмировать мои конкретные вопросы:

  1. Имеет ли смысл запускать главный / рабочий кластер, как описано здесь внутри контейнера docker для достижения изящного сбоя?

  2. Имеет ли смысл использовать почти идентичный код, как описано в Кластерные документы, чтобы "масштабироваться" до доступных процессоров через require('os').cpus().length?

  3. Что означает Amazon в документации по определению задач ECS, где говорится для параметра cpus, что A container instance has 1024 units per CPU? И что было бы хорошей отправной точкой для этой установки?

  4. Что было бы хорошей отправной точкой для типа экземпляра, чтобы использовать для кластера ECS, направленного на обслуживание API узла, основанного на вышеуказанном? И как доступные vcpu влияют на предыдущие вопросы?

3 19

3 ответа:

Все эти технологии являются новыми, и лучшие практики все еще устанавливаются, поэтому считайте, что это советы только из моего опыта.

Один процесс на контейнер-это скорее предложение, чем жесткое и быстрое правило. Это нормально, чтобы запустить несколько процессов в контейнере, когда у вас есть использование для него, особенно в этом случае, когда главный процесс разветвляет рабочих. Просто используйте один контейнер и позвольте ему разветвлять один процесс на ядро, как вы предлагали в вопросе.

На EC2, типы экземпляров имеют ряд vcpu, которые будут отображаться как ядро ОС. Для кластера ECS используйте экземпляр типа EC2, например c3.xlarge с четырьмя vcpu. В ECS это означает 4096 процессорных единиц. Если вы хотите, чтобы приложение использовало все 4 vcpu, создайте определение задачи, требующее 4096 процессорных блоков.

Но если вы делаете все это только для того, чтобы остановить приложение от сбоя, вы также можете просто использовать политику перезапуска, чтобы перезапустить контейнер, если он аварийно завершает работу. Похоже, что политики перезапуска однако они еще не поддерживаются ECS.

Похоже, это действительно хорошая модель. Это похоже на то, что делается с Erlang/OTP, и я не думаю, что кто-то будет спорить, что это одна из самых надежных систем на планете. Теперь вопрос в том, как это осуществить.

Я бы использовал паттерны Heroku или других подобных систем PaaS, которые имеют немного большую зрелость. Я не говорю, что amazon-неподходящее место для этого, но просто много работы было сделано с этим в других областях, которые вы можете перевести. Для например, в этой статье есть рецепт в нем: https://devcenter.heroku.com/articles/node-cluster

Что касается отношений между vCPU и вычислительными единицами, похоже, что это просто прямое отношение 1/1024. Это движение в сторону микрозарядов, основанных на использовании процессора. Они идут еще дальше с работой лямбды. Они заряжают вас на основе долей секунды, которые вы используете.

В мире docker вы бы запускали 1 nodejs на контейнер docker, но вы бы запускали много таких контейнеров на каждом из ваших экземпляров ec2. Если вы используете что-то вроде fig, вы можете использовать fig scale <n> для запуска многих избыточных контейнеров в экземпляре. Таким образом, вам не нужно заранее определять количество nodejs, и каждый из ваших процессов nodejs изолирован от других.