[AWS] ECS vs EKS, 비교/분석

현재 재직중인 회사에서는 모든 서비스가 EKS 환경으로 구성되어 있다.

처음에는 EKS에서 서비스를 제공하는것이 당연하다고 생각했는데, 꼭 그렇지만은 아닌것 같다.

어떤 회사는 EC2를 기본 환경으로 하는곳도 있고, ECS를 기본으로 하는곳도 있다.

 

그리고 최근의 Devops 공고를 보면 ECS to EKS 마이그레이션 경험을 많이 요구하는것 같다.

그래서 이번 기회에 ECS와 EKS의 공통점과 각 장점과 단점에 대해서 정리해보려고 한다.

EKS는 현재 직접 사용하고 있고, 운영중이기 때문에 어느정도? 정보의 정확성은 있다고 생각하나,

ECS는 사용해본적이 없다. AWS Docs/구글링의 글을 바탕으로 내가 이해한 내용을 정리하였기에 일부 틀린 내용이 있을 수 있다.

 

틀린 내용이 있다면 자유롭게 댓글을 달아주세요~ 확인해보고 수정하도록 하겠습니다.

---

EKS와 ECS 중에서 어떤 것이 더 좋다고 말하기는 어려울것 같다. 처음 사용하기에는 ECS를 사용하는 것이 편하다는 의견이 많다.

하지만 어느정도? 프로젝트가 커지고 나면, ECS에서는 유연성이 떨어지고/다양한 Plugin이 없어서 EKS로 전환하는 케이스가 많다.

• 실제로 2023.4Q 기준으로 원티드에서 공고를 보면 ECS to EKS에 대한 경험에 대한 우대사항이 많다.

개인적으로도 만약 작은 프로젝트라면 운영 비용이 있는 EKS보다는 ECS가 더 효율적일것 같은 생각이다.

하지만 이것도 회사 내에 K8s를 잘 다룰 수 있는 인원이 있다면 EKS가 더 효율적인 오케스트레이션이 될 수 있고, 케바케이다.

필자는 EKS만 사용해봤기 때문에 만약 새로운 프로젝트를 하라고 한다면 ECS보다는 EKS를 선택할 것 같다.

EKS vs ECS 장/단점이 뭘까?

EKS 요약정리

Elastic Kubernetes Service의 약자로 완전 관리형 Kubernetes 서비스이다.

Kubernetes 기반 애플리케이션을 AWS의 컨테이너 오케스트레이션 툴이다.

구성

EKS 구성도

 AWS에서 관리하는 Controle Plane와 사용자가 관리하는 Data Plane으로 구성되어 있다.

• Api server, kubelet, etcd 등은 AWS에서 관리한다.

EKS on EC2, Fargate 2가지 형태를 제공한다. 일반적으로는 EKS on EC2로 서비스를 제공한다.

최근에는 EC2에서도 비용절약을 위해 Karpenter + Spot 노드를 많이 사용하는 추세이다.

• Karpenter를 사용하면 Cluster AutoScaler에서는 힘들었던 Spot 사용이 쉽다.
  • EC2 Type 선택, EBS 할당/AZ 할당 등등..

그리고 기본적으로 Deployment, Pod, Service, Ingress, ServiceAccount의 요소가 있다.

• Deployment : Pod을 세밀하게 관리해주는 컨트롤러이다.
• Pod : 컨테이너를 배포할 오브젝트, 가장 작은 단위이다.
• Service : Pod으로 트래픽을 전달하기 위한 Proxy의 역할을 한다.
• Ingress : EKS 내/외부 노출을 위한 엔드포인트를 생성한다.
• Hpa : Deployment 기준으로 부하/분산 등을 판단하여 일정 개수의 Pod을 유지하는 스케줄러이다.
• ServiceAccount : Pod에 부여하는 권한의 계정이다.

장점

• 기존 K8s의 경험을 그대로 사용할 수 있다.
• 커뮤니티가 매우 활성화 되어 있다. 그만큼 다양한 오픈소스가 있다.
• 확장성이 좋다. 노드를 간단하게 늘리거나/줄일 수 있다.
• AWS 서비스와 K8s 오픈소스 생태계가 잘 결합되어 있다.

단점

• 학슴 비용이 있다. 다양한 기능을 제공해주는만큼 알아야하는 지식이 많다.
• 다른 서비스(EC2, ECS)에 비해서 인프라 비용이 다소 높다.

ECS 요약정리

Elastic Container Server의 약자로 완전 관리형 컨테이너 관리 서비스 이다.

EKS의 대항마?이며, AWS에서 제작한 자체 엔진의 컨테이너 오케스트레이션 툴이다.

구성

ECS 구성도

EKS와 동일하게 ECS on EC2, Fargate 2가지 형태를 제공한다.

프로젝트 규모에 따라서 작은 규모라면 Fargate를 많이 선택하는 추세인것 같다.

Task, Task Definition, Service, Cluster 이름의 5가지 구성요소로 서비스를 제공한다.

• Task : 컨테이너가 동작하는 가장 작은 단위이다. K8s에서의 Pod의 역할이다.
• Task Definition : Task를 정의하는 Json 형식의 파일이다. 배포할 이미지/자원, IAM 역할 등을 정의한다.
  • K8s에서의 Deployment와 유사한 역할을 한다. 차이점이 있다면 ECS에서는 Definition만 있어서는 동작하지 않는다.
  • Task Definition + Service 합쳐야 Task가 배포된다.
• Service : Task를 일정 수준만큼 정의하기 위한 스케줄러의 역할을 한다.
  • Task Definition + Service를 합치면 K8s Deployment + HPA의 역할을 한다.
• Cluster : Service와 Task를 구분하는 논리적인 그룹이다.

장점

• AWS에서 만든 서비스이기에 AWS의 다른 서비스와 결합이 잘 되어 있다. 그만큼 배포/운영이 쉽다.
• EKS에 비해 구조가 어렵지 않다. AWS Console을 통해서 간단하게 배포가 가능하다.

단점

• K8s의 다양한 오픈소스와 오퍼레이터 사용에 제약사항이 많다. 그만큼 커뮤니티 생태계가 작다.
• Vender Lock-in이 있다. ECS는 AWS에서 제작하고 개발한 서비스이기에 다른곳에서는 사용할 수 없다.

EKS vs ECS 요소별 차이점은 뭘까?

나름대로 정리해본 요소별 차이점은 아래와 같이 정리할 수 있을것 같다.

요소	EKS	ECS
오케스트레이션 엔진	오픈소스 K8s 기반 서비스	AWS 자체 제작
오케스트레이션 도구	Kubelet	AWS CLI + SDK
운영 난이도	높음	낮음
컨테이너 로깅	K8s Plugin, Logging solution	CloudWatch
인프라 유연성	상대적으로 높음	상대적으로 낮음
컨테이너 보안 관리	K8s RBAC 사용	AWS IAM 사용
커뮤니티 생태계	높음(=활성)	낮음
ALB 적용 유무	Ingress별로 개별 ALB 사용 가능	단일 ALB로 다수의 Task를 관리
관리 범위	사용자 운영/관리 필요	AWS에서 다수 관리
Network IP 할당	노드 기준으로 ENI 할당	Task별로 ENI 사용

그래서 나는 뭘 선택하지?

하지만 장인은 도구를 탓하지 않는다ㅋㅋㅋㅋ EKS/ECS는 다 같은 오케스트레이션툴이다.

간혹 Devops 팀원으로 일을 하다보면, 어떤 오픈소스를 사용하기 위해서 업무를 진행하는 경우가 종종 있다.

회사 상황과 규모보다는 좋은 오픈소스 솔루션/다른 사람들이 많이 사용하는 오픈소스를 사용하고 싶은 업무 욕심이다.

 

물론 좋은 솔루션이라고 하면, 사용하는게 좋겠지만 솔루션을 사용하기 위한 업무는 하지 않도록 경계해야 한다.

(여러가지 썰이 있지만.. 필자도 Argo Workflow + Rollout이 좋아보여서 무리하게 진행했던 경험이 있다..)

 

ECS와 EKS도 어떤것을 사용하던지, 회사의 상황을 판단하고, 팀의 규모를 판단해서 선택하면 된다.

무조건적으로 좋은 솔루션은 없다. 다 좋은 솔루션이다. 얼마나 효율적으로 사용할지의 차이이다.

 

끝!!