Docker 컨테이너를 확장하려면 AWS Elastic Beanstalk 또는 Amazon EC2 Container Service (ECS)를 사용해야합니까?


81

여러 마이크로 서비스로 구성된 Docker 기반 애플리케이션을 개발했습니다. Amazon SQS 메시지를 소비하고 처리해야합니다. 처음에는 AWS Elastic Beanstalk를 사용하고 싶었지만 EC2 컨테이너 서비스에 넘어갔습니다. 이제 어떤 것을 선택해야할지 모르겠습니다.

현재 Elastic Beanstalk는 Multi-Container-Environments를 지원합니다. 모든 마이크로 서비스에는 도커 컨테이너 내부에 자체 애플리케이션 서버가 있기 때문에 훌륭합니다. 다음 문제는 확장입니다.

스케일링 메커니즘이 어떻게 작동하는지 모르겠습니다. 예 : Elastic Beanstalk 환경에 5 개의 도커 컨테이너가 있습니다. 이제 다섯 번째 도커 컨테이너 만 처리 할 SQS 메시지가 엄청나게 많기 때문에 부하가 높고 나머지 4 개는 CPU가 많이 필요하지 않거나 SQS 메시지가 많지 않기 때문에 거의 유휴 상태입니다. 다섯 번째 컨테이너가 JBoss 애플리케이션 서버를 실행한다고 가정 해 보겠습니다. 내가 아는 한, 서버는 사용 가능한 CPU / 메모리가 충분하더라도 제한된 양의 병렬 요청 만 사용할 수 있습니다.

JBoss Docker 컨테이너가 요청 량을 처리 할 수 ​​없지만 사용 가능한 CPU / 메모리가 충분한 경우, 물론 동일한 인스턴스에서 두 번째 Docker / JBoss 컨테이너를 자동으로 시작하고 싶습니다. 하지만 CPU / 메모리가 충분하지 않으면 어떻게됩니까? 물론 EB의 자동 확장 그룹을 통해 구성 할 수있는 두 번째 인스턴스에서 회전하고 싶습니다. 이제 두 번째 인스턴스가 회전하지만 5 번째 인스턴스를 제외한 모든 컨테이너는 거의 유휴 상태입니다. 물론 두 번째 인스턴스에서도 불필요한 4 개를 생성하는 것을 원하지 않습니다. 이는 리소스 낭비입니다. 5 번째 만 스폰되고 나머지는 CPU / 메모리 / SQS와 같은 구성 가능한 매개 변수를 기반으로 5 번째 스케일처럼 확장되어야합니다.

Amazon ECS가 그렇게하고 있는지 또는 가능한지 정확히 알 수는 없지만, 일반적으로 인스턴스 / 컨테이너를 기반으로 확장하는이 주제에 대해 인터넷에서 소스를 찾을 수 없습니다.


문제가 해결되었다고 생각하십니까? 나는 그것을 별도의 인스턴스의 모든 5 개 컨테이너를 시작 의심, EB에 관한 매우 비슷한 문제를 가지고
카메론 그을음

3
나도 혼란스러워. 선택한 답변은 두 서비스에서 확장이 작동하는 방식을 실제로 설명하지 않습니다. 또한 ECS / EB는 실제로 다른 다섯 번째 컨테이너를 킥한 다음 충분한 리소스가있는 경우 동일한 인스턴스에서 두 가지를 동시에 실행합니까?
codepushr 2019 년

답변:


69

EB 대 ECS는 실제로 제어 할 수 있습니다. 확장 및 용량을 제어하고 싶습니까, 아니면 더 추상화하고 대신 주로 앱에 집중하고 싶습니까? ECS는 클러스터에서 노드의 크기와 수를 지정해야하고 자동 확장을 사용해야하는지 여부를 지정해야하므로 제어 기능을 제공합니다. EB를 사용하면 Dockerfile을 제공하기 만하면 EB가 노드 수와 크기의 프로비저닝을 조정합니다. 기본적으로 EB 경로를 사용하는 인프라는 잊어 버릴 수 있습니다.

Docker에 대한 EB 설명서는 다음과 같습니다. 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 Auto Scaling 그룹 프리미티브를 사용하여 수행됩니다. 확장 또는 축소를위한 트리거 요소는 컨테이너가 아니라 인스턴스 노드입니다. 즉, 네트워크 인터페이스 트래픽, CPU로드 또는 디스크로드가 특정 임계 값에 도달하면 클러스터가 확장 또는 축소 될 수 있습니다. 따라서 예에서 5 번째 컨테이너의 노드가 CPU 부하가 높으면 자동 확장 그룹 트리거 기반을 설정할 수 있습니다. 그것에.
alanwill 2015-04-13


또한 AWS Fargate 를 사용하여보다 제어 된 컨테이너 지향 ECS 접근 방식을 유지하고 클러스터 제어 책임을 연기 할 수 있습니다 .
dmulter

가격은 어떻습니까? 다른가요?
Daniel Vilela

12

죽은 질문을 부활시키는 것이 아니라 누군가에게 도움이되기를 바랍니다.

받아 들여지는 대답은 충분히 명확하지 않습니다. OP는 설명 된 OP에 따라 MCEB (Multi-Container Elastic Beanstalk)가 아닌 ECS를 원합니다. 내가 말할 수있는 한 MCEB는 컨테이너를 인스턴스로 효율적으로 포장하려고하지 않습니다. OP는 "하나만로드 중이면이 항목 만 확장하거나 항상 인스턴스를 확장하고 모든 컨테이너를 시작합니까? 그리고 대답은 "후자"입니다. MCEB는 인스턴스를 확장하고 부하에 관계없이 모든 컨테이너를 시작합니다.

편집하다

당신이 상상하는 아키텍처를 사용하지 마십시오.

마이크로 서비스는 얼마나 마이크로입니까? 그들에게 각각 t2.nano를주는 것이 우스꽝 스럽습니까? 그런 다음 각각을 단일 컨테이너 Docker EB 앱으로 만듭니다. EB 작업자 애플리케이션은 SQS 메시지로 구동 될 수 있습니다. 또는 apex.run을 사용 하십시오 .

1/31/18 수정 :

AWS Fargate는 꽤 멋져 보입니다.

6/5/19 수정 :

가려움증을 해결하기 위해 컨테이너를 조정해야하는 경우 EKS를 사용합니다. 그러나 정말로 이것을 피하십시오. 분산 시스템은 어렵습니다.


1
정확히 이것을합니다. 일반적으로 함께 확장해도 괜찮은 스택 방식으로 앱을 구성하기 때문에 이는 큰 문제가 아닙니다. 앱이 독립적으로 확장되어야한다면 EB의 또 다른 앱이어야합니다. 나는 이것이 필요한 좋은 시나리오를 생각하기 위해 정말 열심히 노력하고 있습니다. 나는이 욕망을 말하는 사람들의 많은 사례를 읽어 왔고 그것이 단지 학문적 인 것인지, 디자인적인 문제인지 아니면 정말로 유효한 사례인지 결정할 수 없습니다.
Jacob Thomason
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.