[AWS] ECS vs Kubernetes

컨테이너 서비스인 AWS ECS와 Kubernetes에 대해 비교해보려고 한다.

먼저 많이 언급되는 컨테이너 서비스의 장점을 먼저 살펴보자.

- Continuous Delivery(CD): 흔히 DevOps에서 언급하는 지속적 배포 과정을 컨테이너만 구성하면 되기 때문에 쉽다.

(혹시나 배포에 실패할 경우 이전 버전의 컨테이너만 다시 roll-back하면 된다.)

- Replication/Isolation: 컨테이너만 복사하면 되기 때문에 replica를 만들기 쉽다. 또한 컨테이너가 여러 개 복사 되어도 여타 환경에 독립적이다.

- Testing: 위에서 언급했듯이 컨테이너는 독립적인 환경을 가지기 때문에 다른 환경에 영향없이 테스트를 할 수 있다.

- Scalability: 컨테이너 단위로 확장이 쉽다. 단순히 인스턴스에서 컨테이너만 추가/삭제하면 된다. 

(Orchestration Tool에 따라 조금 다르다.)

- Performance: VM과 비교했을 때 컨테이너는 가볍고 성능적으로 뛰어나다. 

(VM와 컨테이너의 구성 자체가 다르기 때문이다.)

- Availability : 실행 중인 컨테이너에 문제가 생겼을 때 쉽게 다른 컨테이너에서 작업을 대신 해 줄 수 있다.

(컨테이너 스케줄링 방법에 따라 조금 차이가 있을 수 있다.)

이러한 컨테이너 서비스는 이 전에도 사용되긴 했었지만 MSA(Micro Service Architecture)와 DevOps의 개념이 자리를 잡으면서 거의 필수적인 요소로 언급되었다. 그래서 이번 포스팅에서는 AWS에서 제공하는 컨테이버 서비스인 ECS와 최근 대세가 된 오픈 소스인 Kubernetes에 대해 비교해 보려고 한다.

 

그림 1. Kubernetes(Left), ECS(Right) Architecture

그림 1의 왼쪽을 보면 k8s(kubernetes)의 아키텍처를 확인 할 수 있다. k8s는 구글에서 만든 오픈 소스 프로젝트로 컨테이너화된 어플리케이션을 자동으로 배포, 확장, 관리 등을 위한 Orchestration framework이다. 또한 오른쪽을 보면 ECS의 아키텍처를 확인 할 수 있다. ECS는 네이밍에서도 할 수 있듯이 AWS에서 만든 Orchestration framework로 EC2 인스턴스 위에 컨테이너화된 어플리케이션을 동작시킨다. 

이 두 가지의 세부 특징을 들여다 보기전에 개략적으로 비교해보면 아래와 같다.

	Kubernetes	ECS
배포 환경	Private/Public Cloud 및 On-premise	AWS EC2
오픈 소스	활성화된 오픈 소스	부분적으로 오픈 소스 (크게 활성화는 안됨)

위의 테이블에서 개략적으로 설명은 해 놓았지만 하나 하나 살펴보면 차이가 날 수 밖에 없는 부분이다.

먼저 배포 환경은 k8s는 다양한 환경에서 배포 할 수 있지만 이는 오픈 소스이기 때문에 어찌보면 당연한 것이다. 현재는 메이커 3사 클라우드(AWS, Google, Azure)에서 k8s를 위한 서비스를 제공하기 때문에 ECS와 환경적인 부분은 큰 차이가 없다. 

그림 2. Popularity for K8s Vs ECS 

다음으로 오픈 소스는 애초에 시작 지점부터 다르기 때문에 그림 2에서 인기도가 큰 의미가 있을까 라는 생각이 든다. 하지만 Kubernetes는 오픈 소스로서 활발히 프로젝트가 진행되고 있기 때문에 유지 보수 및 성능 향상이 더 나을 수 있다. (물론 ECS는 AWS의 전문 조직이 있어서 더 유지 보수가 잘 될 수도 있다.)

이렇듯 k8s와 ECS의 전반적인 부분은 오픈 소스에 따라서 지표가 조금은 다르다. 그렇기 때문에 세부 특징별로 비교하는 것이 k8s와 ECS의 차이를 좀 더 확연히 아는데 도움이 될 것이다.

	Kubernetes	ECS
Application Definition	- Pod, Deployment, Service를 사용	- Task를 사용
HA(High Availability)	- Deployment에 의해 Nodes에 Pod를 분산 시킴 - Health check를 통해 작동하지 않는 Pod는 삭제	- ELB에 의해 Traffic이 분산됨 - Control Plane은 AWS에 의해 관리됨
Load Balancing	- Service가 Load balancer 역할을 하며 Pod에 Traffic을 분산 시킴	- ELB에서 CNAME을 제공 (ALB 및 Classic 사용 가능)
Auto-scaling	- Deployment에 의해 수동 및 자동으로 조절됨 - Resource metrics 지원	- Task Definition에 의해 수동으로 조절됨 - CloudWatch가 사용됨 (Resource metrics 확인)
Health Check	- Liveness 및 Readiness 사용	- CloudWatch를 사용
Block Storage	- NFS, EBS, iSCSI 등등 지원	- EBS 지원
Networking	- Flat network (모든 Pod는 서로 간에 통신이 가능)	- AWS VPC 지원
Service Discovery	- 환경 변수 및 DNS 사용	- ELB CNAME 사용
Performance / Scalability	- 최대 5,000개의 Node까지 확장 (1.6 버전에서)	- 최대 1,000 개의 컨테이너까지 확장

위의 테이블에서 특징을 비교한 것을 보면 전반적으로 대부분의 기능을 Kubernetes와 ECS는 지원하고 있다. 때문에 서로 간에 기능 상에 큰 차이는 보여지지 않는다. (물론 언급한 특징들은 개략적인 부분을 나타낸 것이기 때문에 서로 다른 아키텍처 상에서 세밀한 동작 같은 부분은 많이 다를 수 있다.)

때문에 Kubernetes와 ECS는 사용 목적에 따라 선택이 달라 질 수 있다. 예를 들어 AWS 환경에서만 사용하고, AWS 내장 서비스와 연계하여 서비스*를 개발하고 싶다면 Kubernetes 보다는 ECS가 좀 더 낫다. 반면에 Kubernetes는 pluggable 아키텍처이기 때문에 다른 서비스 및 도구와 결합하여 사용 하고 싶다면 ECS 보다는 Kubernetes가 낫다.

* ECS에서 연계하여 사용 서비스의 비용에 대해서도 잘 파악해야 한다. (ELB, CloudWatch, Route 53 등등의 서비스가 사용 될 수 있기 때문에)

지금까지는 단순히 오픈 소스인 Kubernetes에 대해 비교해 보았다. 그렇다면 Vendor에서 지원하는 Kubernetes의 경우는 어떨지 다음 포스팅에서 알아보도록 하겠다.

- https://medium.com/devopslinks/ecs-vs-eks-vs-fargate-the-good-the-bad-the-ugly-9f68bfc3bb73

- https://dzone.com/articles/kubernetes-vs-amazon-ecs

- https://www.stratoscale.com/blog/kubernetes/ec2-container-service-vs-kubernetes/