Что следует использовать для масштабирования контейнеров Docker - AWS Elastic Beanstalk или Amazon EC2 Container Service (ECS)?


81

Я разработал приложение на основе Docker, состоящее из нескольких микросервисов. Он должен принимать сообщения Amazon SQS и обрабатывать их. Сначала я хотел использовать AWS Elastic Beanstalk, но потом упал на EC2 Container Service. Теперь не знаю, какой выбрать.

На данный момент Elastic Beanstalk поддерживает многоконтейнерные среды. Это здорово, потому что у каждого микросервиса есть собственный сервер приложений внутри контейнера докеров. Следующая проблема - масштабирование:

Я не знаю, как работает механизм масштабирования. Например: у меня есть 5 контейнеров докеров в моей среде Elastic Beanstalk Environment. Теперь только пятый контейнер докеров находится под большой нагрузкой, потому что он имеет огромное количество сообщений SQS для обработки, остальные четыре почти простаивают, потому что им не требуется много ЦП или, возможно, не так много сообщений SQS. Предположим, 5-й контейнер запускает сервер приложений JBoss. Насколько мне известно, сервер может использовать только ограниченное количество параллельных запросов, даже если имеется достаточно ЦП / памяти.

Если контейнер JBoss Docker не может обрабатывать количество запросов, но достаточно ЦП / памяти, конечно, я хочу автоматически запускать второй контейнер Docker / JBoss на том же экземпляре. Но что произойдет, если мне не хватит процессора / памяти? Конечно, я хочу запустить второй экземпляр, который можно настроить с помощью группы автоматического масштабирования в EB. Теперь запускается второй экземпляр, но каждый контейнер, кроме 5-го, почти бездействует, конечно, я не хочу, чтобы они создавали 4 ненужных и во втором экземпляре, что было бы пустой тратой ресурсов. Должен появиться только 5-й, а остальные должны масштабироваться как 5-я шкала на основе настраиваемых параметров, таких как, например: CPU / memory / SQS.

Я точно не знаю, делает ли это Amazon ECS или возможно ли это вообще, но я действительно не могу найти в Интернете какой-либо источник по этой теме, которая в целом называется масштабированием на основе экземпляров / контейнеров.


Считаете ли вы, что ваша проблема решена? У меня очень похожее беспокойство по поводу EB, я подозреваю, что он запускает все 5 контейнеров в отдельном экземпляре
Кэмерон Синг

3
Я тоже в замешательстве. Выбранный ответ на самом деле не объясняет, как масштабирование работает в обоих сервисах. Также действительно ли ECS / EB запускает другой 5-й контейнер, а затем запускает оба параллельно на одном экземпляре, если ресурсов достаточно?
codepushr

Ответы:


69

EB vs ECS действительно сводится к контролю. Вы хотите контролировать свое масштабирование и емкость или хотите, чтобы это было более абстрактно и вместо этого сосредоточилось в основном на своем приложении? ECS предоставит вам контроль, так как вы должны указать размер и количество узлов в кластере, а также следует ли использовать автоматическое масштабирование. С EB вы просто предоставляете Dockerfile, а EB позаботится о масштабировании предоставления количества и размера узлов, вы в основном можете забыть об инфраструктуре с маршрутом EB.

Вот документация EB по Docker: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html

С ECS вам нужно будет сначала построить инфраструктуру, прежде чем вы сможете начать развертывание Dockerfile, поэтому на самом деле все сводится к 1) вашему знакомству с инфраструктурой и 2) уровню усилий, которые вы хотите потратить на инфраструктуру по сравнению с приложением.


7
Да, но как работает механизм автоматического масштабирования обеих служб, масштабирует ли Elastic Beanstalk контейнеры для каждого контейнера, поэтому, если только один из них находится под нагрузкой, он масштабирует только этот или всегда масштабирует экземпляры и запускает все контейнеры, независимо от того, под какой нагрузкой они находятся?
orbatschow

6
Теперь, когда ECS является GA, EB использует ECS для создания своей многоконтейнерной инфраструктуры. Автоматическое масштабирование выполняется с использованием типичного примитива группы автоматического масштабирования EC2. Тем не менее, запускающим фактором для увеличения или уменьшения является не контейнер, а узел экземпляра. То есть, если трафик сетевого интерфейса, загрузка ЦП или нагрузка на диск достигают определенного порога, то кластер может масштабироваться или увеличиваться. Итак, в вашем примере, если узел 5-го контейнера находился под большой загрузкой ЦП, вы могли установить триггер группы автоматического масштабирования на основе на что.
alanwill

Вот несколько ресурсов, которые вам тоже могут помочь: aws.amazon.com/blogs/aws/aws-elastic-beanstalk-for-docker docs.aws.amazon.com/elasticbeanstalk/latest/dg/…
alanwill

Также обратите внимание, что вы можете придерживаться более контролируемого подхода ECS, ориентированного на контейнеры, и отложить ответственность за управление кластером, используя AWS Fargate .
dmulter 05

Как насчет цен? Это другое?
Даниэль Вилела

12

Не воскрешать мертвый вопрос, но, надеюсь, это кому-то поможет.

Принятый ответ недостаточно ясен: исходя из того, что описал OP, OP хочет ECS, а не Multi-Container Elastic Beanstalk (MCEB). Насколько я могу судить, MCEB никогда не пытается эффективно упаковывать контейнеры в экземпляры. OP спрашивает в комментарии: «Если только один находится под нагрузкой, он масштабирует только этот, или он всегда масштабирует экземпляры и запускает все контейнеры, независимо от того, под какой нагрузкой они находятся?» И ответ - «последнее»; MCEB масштабирует экземпляры и запускает все контейнеры, независимо от их нагрузки.

редактировать

Не используйте ту архитектуру, которую вы себе представляете.

Насколько микро ваши микросервисы? Было бы смешно дать каждому по t2.nano? Затем сделайте их каждое приложение Docker EB с одним контейнером - рабочие приложения EB могут управляться сообщениями SQS. Или используйте apex.run .

Изменить 31.01.18:

AWS Fargate кажется довольно крутым.

Изменить 6/5/19:

Используйте EKS, если вам нужно организовать контейнеры, чтобы утолить зуд. Но на самом деле постарайтесь этого избежать. Распределенные системы - это сложно.


1
Он делает именно это. Для нас это не большая проблема, потому что мы структурируем наши приложения в виде стека, где обычно нормально, что они масштабируются вместе. Если это необходимо для независимого масштабирования приложения, я бы сказал, что это должно быть другое приложение на EB. Я очень стараюсь придумать хороший сценарий, где это необходимо. Я читал много случаев, когда люди заявляли об этом желании, и я не могу решить, является ли это чисто академической проблемой, проблемой дизайна или действительно обоснованным случаем.
Джейкоб Томасон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.