[AWS] ECS vs EKS
지난 포스팅에 이어 이번 포스팅에서는 AWS에서 제공하는 컨테이너 서비스인 ECS, EKS를 비교해 보려고 한다.
들어가기에 앞서 전체적으로 ECS와 EKS에 대해 전반적으로 살펴보자.
흔히 ECS를 언급할 때 Fargate가 등장한다. 아래 그림과 같이 ECS를 생성할 때 가장 먼저 Compatibilities 옵션으로 등장하고 ECS 관련된 서비스 중에 그래도 가장 최근에 런칭된 서비스이기 때문이다. (최근에 등장했다는 건.. 새롭게 무언거 할 수 있다는게 나왔다는 뜻이니...)
그림 1. Fargate, EC2
기존에는 ECS를 생성 할 때, EC2 인스턴스 위에서 컨테이너를 만들었다면 Fargate는 문서 그대로 설명한다면 클러스터를 더 이상 관리 할 필요 없이 컨테이너를 실행할 수 있게 한다. 즉, 간단하게 말하면 ECS를 Serverless 환경처럼 사용할 수 있게하는 것이다.
그림 2. AWS Container Support Service
그래서 AWS에서 서비스를 설명한 것을 참조한다면 (그림 2), Fargate는 EC2와 같이 단순히 컨테이너 서비스를 위해 컨테이너를 호스팅하는 역할을 할 뿐이다.
(그림에서 확인 할 수 있듯이, AWS의 컨테이너 서비스는 크게 ECS와 EKS로 나뉜다.)
그림 3. Spectrum of Abstraction Level
그렇지만 AWS의 컨테이너 서비스인 ECS와 EKS를 비교할 때, 같은 비교군으로 종종 등장하는 이유는 그림 3에서 볼 수 있듯이 Fargate가 제 3 영역에 있기 때문이다. AWS의 Roadmap상 Fargate를 ECS 뿐만 아니라 EKS에도 지원할 예정이라고 하기 때문에 ECS든 EKS는 Fargate는 단순히 리소스 관련한 Control Plane은 AWS에 위임하는 것이다. 그렇기 때문에 컨테이너 서비스 비교에서는 제외하고 ECS와 EKS를 중심으로 알아보려고 한다.
- Load Balancing
그림 4. Load Balancing
EKS와 ECS의 로드 밸런싱을 보면 그림 4와 같다. 그림 상에는 EKS는 Classic LB만 가능한 것처럼 보이지만 ALB 및 NLB도 지원하다. (ECS도 마찬가지로 모든 타입의 ELB를 지원한다.) ECS와 다르게 EKS는 ELB가 있음에도 불구하고 구조상 내부에 Proxy를 두어 Pods에 로드를 분산*시킨다.
* Randomly 또는 Round Robin으로 적절히 분산시킨다.
언뜻보면 EKS가 Node에 상관없이 로드가 분산되어 좋아보이나 만일 Traffic이 많아진다면 Node간의 네트워크 latency도 점점 늘어나게 된다. (Bottleneck의 원인이 될 수 있다.) 반면에 ECS는 ALB 하나만 사용하기 때문에 더 효율적일 수 있다.
- Networking
그림 5. ENI (Elastic Network Interface)
EKS와 ECS는 내부적으로 VPC를 사용한다. 그런데 VPC를 구성할 때 ENI 할당 방식이 조금 다르다. (그림 5 참조)
EKS에서는 단일 Pod 마다 IP를 할당 받을 수 있고 여러 개의 Pod를 묶어서 IP를 할당 받을 수 있다. 반면에 ECS는 Task 당 ENI를 할당 받을 수 있다.
그런데 보통 AWS에서는 일반적으로 인스턴스 당 15까지 ENI를 사용 할 수 있다. 인스턴스 관점에서 보자면 EKS는 인스턴스당 Pod를 최대 750개까지 만들 수 있는 반면에 ECS는 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가 낫다. 물론 서비스의 규모, 비용, 제어 범위 등등을 더 고려해보고 선택해야 한다.
마지막으로 re:invent 2017에 자료를 보면 아래와 같이 정리되어 있다.
그림 6. Comparison Overview
AWS에서는 컨테이너와 관련된 서비스는 모두 제공하며 각 서비스의 특징에 맞게 사용하면 된다. (물론 이제까지 언급한것처럼 잘 따져봐야 한다.)
참조
- https://www.slideshare.net/AmazonWebServices/deep-dive-ecs-fargate-deep-dive
- http://www.it20.info/2018/06/compute-abstractions-on-aws/
- https://cloudonaut.io/eks-vs-ecs-orchestrating-containers-on-aws/
- https://dev.to/diogoaurelio/container-orchestration-in-aws-comparing-ecs-fargate-and-eks-56d1