ECS vs EKS (ing)

 

컨테이너 기술은 Docker 를 이용해 서비스를 구축하려면 여러 고려할 사항이 많다.

필연적으로 컨테이너를 배치/관리를 도와주는 컨테이너 오케스트레이션 도구 중,

AWS의 ECS는 Amazon에서 제공하는 "완전 관리형 컨테이너 오케스트레이션 틀" 으로, Docker 컨테이너를 이용하여 인프라 환경을 편리하게 운영/관리할 수 있는 서비스

- 비슷한 툴로는 Kubernetes, Docker Swarm이 있다.

 

ECS 구성 요소

- ECRAmazon 에서 제공하는 컨테이너 이미지 저장소로, 사용자가 쉽게 컨테이너 이미지 저장/관리/공유/배포하는 완전 관리형 컨테이너 레지스토리(이미지를 S3에 저장)

- ECR 리포지토리에서 이미지 URI를 이용해 빌드한 이미지를 push, pull 가능

- ECR(Elastic Container Registry)

Elastic Container Service(ECS) - 작동 방식

 

ECS 컴포넌트

: Task definition/Task/Service/Container Instance/Cluster

Task / Service 관계

 

1) Task definition

원하는 Docker 컨테이너를 생성할 때, 어떤 설정으로 몇 개 이상 생성할지 정의한 Set

- 컨테이너의 이미지/CPU/메모리 리소스 할당 설정/Port 매핑/volumn 설정 포함 

- 컨테이너가 필요에 의해 자동으로 실행되거나 종료

- 한 개 이상의 컨테이너에 대한 설정을 미리 집합 하나의 단위로 정의( : Task definition) 내부에 정의된 컨테이너 사이는 link 설정으로 연결 가능

 

2) Task

Task definition 에서 정의된 대로 배포된 container set 들을 task

- 즉, Task 안에는 한 개 이상의 컨테이너들이 포함되고, ECS에서 컨테이너를 실행하는 최소 단위는 Task

Task는 Cluster에 속한 Container instance(EC2 instance)에 배포, Task는 여러 EC2에 배포 가능

 

3) Service

Task 들의 Life cycle을 관리하는 부분을 Service

Task를 Cluser 에 몇개 배포할지 결정 후, 실제 Task 는 외부에 서비스(각자)하기 위해 ELB(Elastic Load Balancer)에 연동되는 부분을 관리 함

만약 실행 중인 Task가 어떤 이유로 작동이 중지되면, 자동감지해 새로운 Task를 Cluster에 배포하는 고가용성에 대한 정책 관리

: 오토스케일링 + 로드밸런싱 역할

 

4) Container Instance(EC2 instance)

ECS는 Container 배포(Task 배포)를 EC2 instance 기반에 올리도록 설계됨

Task를 올리기 위해 등록된 EC2 instance를 Container instance라고 하고, ECS 처음 시작 시 생성된 Default Cluster 에는 Container instance를 자동 할당하지만, 새롭게 Cluster를 생성하면 직접 Container instance를 만들어야 함

Container instance 용 AMI(Amazon Machine Image : EC2 안에 가상머신을 생성하기 위해 사용되어 EC2 인스턴스를 이미지로 만들어놓고, 이미지로 여러 개 EC2 인스턴스를 만들어서 오토 스케일링에 사용) 이미지는 AWS 측에서 제공하여 생성

+ fargate : 기존에는 ECS를 생성 할 때, EC2 인스턴스 위에서 컨테이너를 만들었다면 Fargate는 문서 그대로 설명한다면 클러스터를 더 이상 관리 할 필요 없이 컨테이너를 실행할 수 있게 한다. 즉, 간단하게 말하면 ECS를 Serverless 환경처럼 사용할 수 있게 함

 

5) Cluster 

Task가 배포되는 container instance 들은 논리적인 그룹으로 묶이고, 이 단위를 Cluster라고 함, 배포시 등록 필수

 

Docker를 사용하며 컨테이너를 대규모로 운영하려는 시도가 많아지고, 자연스럽게 다수 Docker host를 clustering 형태로 통합 관리하는 필요성이 커진다.

그래서 host에 container를 어떻게 배포할 것인지에 대한

- 스케쥴링 관련 문제

- 다른 host에 배포된 container 사이의 통신 문제

- 동일 port 를 사용하는 컨테이너들을 동시 수용할 때 host 포트 맵핑 이슈 등이 대표적인 문제이다.

다른 kubernetes와 docker swarm에서는 위와 같은 이슈는 overlay network 구조를 추가해 해결

-> host간 네트워크를 논리적으로 묶어 연결해주는 overlay network는 컨테이너 오케스트레이션을 위한 중요 구성 요소로 고려

 

다수의 Docker host를 clustering 형태로 관리하기 위해 overlay network 구조를 추가하는 다른 컨테이너 오케스트레이션 시스템과 달리, ECS의 host clustering 을 위한 network 구조는 ELB를 사용한다.

: ECS는 service 내부에 여러개의 task가 배포될 때, ELB의 밸런싱 그룹에 task들이 자동으로 들어가도록 설계됨

+ 하나의 Host에는 한 개의 Task만 수용 가능

- 컨테이너가 host의 특정 port를 점유해야 하는 궂는, 같은 port로 서비스 하려는 컨테이너가 한 host에 한 개 밖에 올라갈 수 없는 것

예) service안에 컨테이너가 정의된 task 2개 올리고 싶으면, host는 두 대 이상이 필요

 

 

 

ECS vs EKS

- load Balancing

EKS와 ECS의 로드 밸런싱은 위 그림과 같다. EKS는 ELB가 있음에도, 구조상 내부 Proxy를 두어 Pods에 로드를 분산한다.

EKS가 Node에 상관없이 로드가 분산되지만, Traffic이 많아지면 Node간의 네트워크 latency도 늘어난다. (Bottleneck 원인 가능성), 반면 ECS는 ALB 하나만 사용

 

- Networking

EKS와 ECS는 내부 VPC를 사용하지만, ENI 할당 방식이 다르다.

 

EKS에서 단일 Pod마다 IP를 할당받고, 여러 Pod를 묶어 IP 할당 받으 수 있지만, 반면 ECS는 Task당 ENI를 할당받을 수 있다.

보통 AWS에서는 일반적 인스턴스 당 15까지 ENI를 사용하여, 인스턴스 관점에서 EKS는 인스턴스 당 Pod를 최대 750개까지 만들수 있지만, ECSsms 15개까지 Pod를 만들수 있다. 개발 서비스가 컨테이너를 사용하는 갯수가 많으면 EKS가 효율적이다.

(ENI 공유 = 관련 네트워크 속성 공유)

 

- Pricing

EKS와 ECS의 비용을 계산 하는 방법은 다르다. 기본적으로 각 서비스의 필수적인 Cluster는 ECS는 무료이지만 EKS는 시간 당 0.20 USD이다. (한 달이면 144 USD 달러) 그리고 이 외에 나머지 비용은 사용하는 리소스에 따라 부과된다.

 

이번 포스팅에서 비교하는 ECS와 EKS는 컨테이너 Orchestration을 수행하는 서비스로 전반적으로 비슷하다. 하지만 아키텍처가 다르듯이 세부 특징 또한 다르다. 그렇기 때문에 두 가지의 서비스 중 하나를 선택해야 한다면 ECS는 AWS의 내부 리소스와 밀접하게 연결하여 사용하고 싶다면 선택하는게 낫고, 외부 요소들 (Monitoring Tools 및 Hybrid Cloud 등등)과 연결하여 사용하고 싶다면 EKS가 낫다. 물론 서비스의 규모, 비용, 제어 범위 등등을 더 고려해보고 선택해야 한다.

 

---

ECS와 EKS는 모두 AWS의 컨테이너 관리 서비스

그렇다면 장단점

	ECS	EKS
장점	- 단순성 - AWS 통합 - 관리 오버헤드 감소	- 유연/이식성 - 광범위한 도구 생태계 - 넓은 커뮤니티
단점	- 제한된 유연성 - 공급업체에 대한 잠재적 종속성	- 복잡성 증가/높은 학습 곡선 - 비용

 

ECS를 초창기에 사용하다가, 서비스가 커지면 EKS로 마이그레이션을 한다고 한다.

그 이유는 아래와 같다.

ECS는 공급업체 종속성, EKS는 다양한 환경에서 호환성 및 유연성과 맞춤 설정 제공(큐버네티스 기능과 API 지원)

EKS는 Horizontal Pod Autoscaler 및 Cluster Autoscaler.

 

 

 

 

 

 

출처 및 참고

- https://www.qovery.com/blog/migrating-from-ecs-to-eks-a-complete-guide/

- https://www.qovery.com/blog/deploying-containers-on-aws-elastic-beanstalk-vs-ecs-vs-eks/

- https://aws.amazon.com/ko/ecs/

- https://www.smileshark.kr/post/aws-container-service-ecs-eks-fargate-comparison

- https://timewizhan.tistory.com/entry/AWS-ECS-vs-EKS

- https://great-park.tistory.com/15#Cluster%-C%--Container%--Instance%EC%--%--%--Task%-C%--Service%EC%-D%--%--%EA%B-%--%EA%B-%--%EC%-D%--%--%EB%-F%--%EC%-B%-D%ED%--%--