AWS ECS vs EKS 차이점 알기 ( 그리고 Fargate vs EC2)

오늘은 제가 AwsStudentCommunityDay 에서 발표했던 내용을 정리해보고자 합니다.

https://aws-cloud-clubs.github.io/student-community-day/2024/

ACC Student Community Day 2024

 

목차

1. 컨테이너 개념 간단하게 짚기

2. EKS 와 ECS 에 대해 알아보기

2.1 EC2 vs Fargate

2.2 Fargate 구축 맛보기

3. EKS 와 ECS 다른그림 찾기

---

1. 컨테이너 개념 간단하게 짚고 넘어가기 

첫번째로, ECS 와 EKS 는 컨테이너 기반 기술입니다. 때문에, 이를 소개하기 전에 컨테이너에 대해 가볍게 몸풀기로 짚고

넘어가 보겠습니다.

 

먼저, 컨테이너란 무엇일까요?

컨테이너를 이해하는 가장 쉬운 방법은 '배에 실리는 컨테이너' 에 비유하는 것입니다. 배에 실리는 컨테이너는 다양한 화물을 담아 목적지까지 안전하게 운송하는 역할을 합니다. 딱 맞는 규격에 여러 화물을 실어 쉽게 운송할 수 있는데요!

 

마찬가지로, 소프트웨어에서의 컨테이너는 우리가 구동하려는 애플리케이션을 실행하는 데 필요한 모든 것( 코드, 라이브러리, 설정 파일 등)을 담아 규격화 시켜 프로그램의 배포 및 관리를 단순화 하여 다양한 컴퓨팅 환경에서도 문제 없이 작동할 수 있게 해줍니다.

 

 

 

 

"패키징"과 "격리된 실행" 이라는 특징 때문에, 서버별 환경에 영향 받지 않고, 사람의 개입 없이 자동으로 배포할 수 있습니다.

이러한 기술을 기반으로, 컨테이너를 쉽게 생성, 배포, 실행할 수 있게 해주는 도구로 많은 분들이 알고 계신 도커가 있습니다. 도커는 앞서 말씀드린 컨테이너 기술을 기반으로 한 가상화 플랫폼입니다.

 

 

 

 

 

 

정확히는 도커 엔진 위에서 도커 이미지들이 실행되기 때문에, 실행환경에 상관없이 모든 환경에서 동일하게 작동합니다. 

 

이는 마치 기존의 VM 과 비슷해보이지만, 둘은 다음과 같은 차이점이 존재합니다.

도커와 같은 컨테이너 기술은 여러 컨테이너들이 똑같은 하나의 머신 위에서, OS 커널을 공유하는 형태로 동작합니다.

하지만, 가상머신은 하나의 머신이나 하드웨어를 여러개의 OS 로 나누어 점유하게 되기 때문에, 사실상 다른 머신인것처럼 각자의 OS, 앱, 라이브러리를 가지고 있기에 부팅하는데 오랜 시간이 걸립니다.

 

컨테이너와 도커에 대한 설명은 간단하게 이정도로만 다뤄보고, 다음으로

---

컨테이너 오케스트레이션

컨테이너 오케스트레이션입니다. 컨테이너의 개수가 수백 또는 수천개의 컨테이너가 될 수록, 이를 관리하기가 어려워지기 때문에,

출처 : codestates

컨테이너의 배포, 관리, 확장, 네트워킹을 도와주는 관리 도구인 컨테이너 오케스트레이션의 필요성이 대두되었습니다.

그러한 도구로 Docker swarm 과 같은 여러가지가 있지만, 가장 대표적인 것으로 " 쿠버네티스 " 가 있습니다.

 

쿠버네티스는 원래 구글(Google) 엔지니어들이 개발하고 설계한 플랫폼입니다. 

 

실제 프로덕션 환경에서의 애플리케이션들은 여러 컨테이너에 걸쳐 있으며 이러한 컨테이너는 여러 서버 호스트에 배포되어야 합니다.  이 때문에 컨테이너를 위한 보안은 멀티 레이어 구조로 되어 있고 복잡할 수 있습니다. 바로 여기에 쿠버네티스가 사용됩니다. 쿠버네티스는 이러한 워크로드를 위해 규모에 맞는 컨테이너를 배포하는 데 필요한 오케스트레이션 및 관리 기능을 제공합니다. 쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리할 수 있습니다. 또한 IT 보안을 한층 강화할 수 있습니다.

 

 

---

이렇듯 많은 기업들이 컨테이너화된 애플리케이션의 확장성과 유연성을 지속적으로 수용함에 따라서, 컨테이너를 효율적으로 관리하고 오케스트레이션 하는 것이 무엇보다 중요해졌습니다. aws 역시도 완전관리형 컨테이너 서비스를 제공하는데요. 

이것이 바로 ECS 와 EKS 입니다. 

ECS 란 무엇인가

먼저 ECS 에 대해 알아봅시다.

ECS 는 AWS 에서 제공하는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 간소화 하는 완전 관리형 컨테이너 오케스레이션 서비스 플랫폼입니다.

말 그대로 컨테이너를 '관리' 해주는 서비스이지, 그 동작 환경을 제공하지는 않습니다. 

 

그렇다면, ECS 가 관리하는 컨테이너는 어떤 환경에서 어떻게 동작할까요? 

한번 살펴보시죠!

 

먼저 ECS 는 ECS Cluster 를 생성해야 합니다.

ECS Cluster 는 Control Plane 과 같으며, 소속되어있는 모든 컨테이너들의 라이프 사이클을 관리하는 녀석입니다.

 

이러한 컨테이너들은

VM 위에서 동작하며, 즉, EC2 인스턴스를 통해 동작하거나 서버리스 환경인 Fargate 위에서 동작할 수 있습니다.

 

그렇다면 이 두가지 환경에서의 ECS 는 어떤 장단점을 가지고 있는지 한번 알아보겠습니다.

 

ECS on EC2 vs ECS on Fargate

 

EC2환경에서 ECS 를 실행하게 되면, 필요에 따라 cpu 코어 수, 메모리 용량 등과 같은 인스턴스 사양과 같은 세부적인 설정이 가능하다는 점에서 유연한 설계가 가능하기 때문에, 장점이라고 볼 수 있습니다.

다만, 오히려 단점이 될 수 있습니다. 하나하나 사소한 것까지 세부적인 세팅을 해줘야하기 때문에 운영복잡도가 증가할 수 있습니다.

 

ECS on EC2 vs ECS on Fargate

이에 반대로, Fargate 같은 경우 서버리스이기 때문에 aws 가 인프라를 관리해줍니다.

fargate는 컨테이너를 분석해 얼마만큼의 리소스가 필요한지, 자동으로 해당 컨테이너를 위해 리소스를 프로비저닝 해, 프로비저닝 된 리소스 위해 배포 및 실행되어 편리하지만,

세부 관리와 같이 사용자가 조작하기 어렵기 때문에 유연성이 제한될 수 있습니다. 

 

 

---

EKS 란 무엇인가

그렇다면, 이어서 EKS 는 무엇일까요?

AWS managed Kubernetes 서비스입니다.

AWS 가 쿠버네티스를 클러스터를 생성하고, 수정, 삭제를 전부 담당하므로 "Managed" 라는 키워드가 있습니다.

이쯤에서 첨부하는 쿠버네티스의 구조

EKS 는 어떻게 동작할까요?

짧게 설명하자면, EKS 구조는 

 

 

컨트롤플레인과, 데이터 플레인으로 나뉩니다. 

 

먼저, 컨트롤 플레인 내부는 다음과 같이 구성되어있다.

1. 중간에서 교통 정리를 해주는 API Server

2. 여유 공간을 확인하고 서버를 어떻게 배포할 지 정해주는 스케쥴러

3. 컨테이너의 상태를 체크하는 컨트롤러

4. 모든 상태를 저장 및 조회할 수 있는 DB 와 같은 etcd

등으로 이루어져 있는데, 이는 aws 에서 관리해줍니다.

 

다음으로, 데이터 플레인을 살펴보면,

컨트롤 플레인의 마스터 노드와 통신해서 컨테이너를 유지 관리하는 역할을 하는 워커노드,

컨테이너를 묶는 단위인 파드,

api server 와 통신하는 일꾼인 Kubelet,

파드의 통신을 담당하는 kube-proxy 등 많은 것들이 포함되어있습니다.

전체 동작은, 유저가 쿠버네티스 관련 설정 파일을 작성해서 올리게 되면, k8s api endpoint 를 통해 api 요청을 받아 컨트롤플레인이 처리하여 데이터 플레인에 파드가 적재적소에 띄워질 수 있게 하는 것입니다.

 

EKS 마스터 노드 즉, 컨트롤 플레인은 aws 측에서 생성 및 관리하고 

워커노드는 ECS 와 마찬가지로 EC2 인스턴스 또는 Fargate 로 사용자가 생성할 수 있습니다. 

 

EKS on EC2 vs EKS on Fargate 

입문자가 EKS 를 사용한다면, 기본적으로 EC2 를 이용해 관리형 노드그룹을 만들 수 있습니다. 

만드는 방법은, eksctl 명령어를 사용하거나 콘솔을 이용해 손쉽게 만들 수 있습니다.

노드그룹을 ec2 로 다음과 같이 사양을 선택해서 만들게 되면

aws측에서 노드의 프로비저닝과 스케일링 등의 관리를 해줍니다.

EC2 환경에서 EKS 노드그룹을 만들게 되면, 

역시나 EC2이기 때문에, 직접 관리할 수 있어 유연성이 있지만, 직접 관리해야 한기에 운영복잡도가 다소 높다는 단점이 있습니다.

 

EKS on EC2 vs EKS on Fargate 

다음은 Fargate 입니다.

Fargate 는 워커 노드를 구축하게 되면, 완전관리형 서버리스 서비스이기 때문에 EC2 인스턴스를 추상화하여 우리가 관리할 필요가 없고, 운영체제 패치 등의 작업도 불필요하며 EC2 를 이용했을 때와 달리, worker node 조차도 aws 에서 관리를 해줍니다.

때문에 ec2 를 따로 관리할 필요가 없고, 우리는 컨테이너의 묶음 단위인 파드만 관리하면 됩니다.

즉 pod 하나가 node 하나가 되는 셈입니다.

서버리스이기 때문에, pod 의 실행시간으로 계산이 됩니다.

 

 

EKS on Fargate 구축 방법 : Fargate Profiles

ec2 사양 및 다양한 옵션을 선택해줬던 앞선 노드그룹 방식과 달리,

fargate는 pod 를 띄울때 yaml 파일에 profile 을 설정해줘야 합니다.

조건 (namespace , label) 을 만족하면, 

Fargate 컨트롤러가 해당 파드를 인식하고 자동으로 Fargate 에 배치됩니다.

 

다음 과 같이 조건을 명시해줘야하고, 

조건이 둘중 하나라도 만족하지 않으면 pod는 기존 ec2 기반 워커노드그룹에 배치되게됩니다. 

 

다음은 실제 구축화면입니다.

저같은 경우는 ec2 와 fargate 를 혼용해서 구축했는데요, 

 

기존 노드그룹 외에 fargate로 구축하게 될 경우 상단에 fargate 노드그룹이 생기며,

하단과 같이 fargate 프로파일을 확인할 수 있습니다. 

EKS on Fargate 제약 사항 

다음은 제가 fargate를 구축하면서 직면했던 제약사항입니다.

- fargate 는 노드를 추상화 했기 때문에, Demonset 은 지원되지 않습니다.

- Secret Manager 사용 불가

- GPU 인스턴스 타입 사용 불가

- public subnet 에 생성 불가

• 제약사항이 다소 많다
  이 외에도 다양한 제약사항이 있었고, 하나하나 할때마다 제약이 걸려버렸기 때문에, EKS를 오로지 fargate만으로는 구축할 수 없겠다는 사실을 깨달을 수 있었습니다.

EKS 와 ECS 다른 그림 찾아보기 

일단 가장 큰 차이점은, ECS 는 Docker 기반의 컨테이너를 지원하고, EKS 는 쿠버네티스 기반의 컨테이너화된 앱을 지원합니다. 용도부터가 다른게 느껴지시져? 

 

그래서 어떤 차이가 있는걸까요 ?

 

먼저 ECS 의 장점은,

간편한 설정이 가능하고, 비용 효율적이며, aws 서비스에 최적화되어있어 통합이 용이한 반면에

쿠버네티스에 비해 유연성이 제한되어있을 수 있습니다. 

 

EKS 같은 경우, 쿠버네티스 표준을 따르므로, 다양한 환경에서의 이식성이 뛰어납니다.

더불어 확장성이 좋습니다.

 

반면, ecs 에 비해 초기설정과 관리가 복잡하거나 비용이 높을 수 있습니다. 

 

자 간단하게 차이점을 비교해보겠습니다.

 

1. ECS 는 EKS 에 비해 비교적 진입장벽이 낮습니다. 컨테이너에 대한 기본 지식만 알면 할 수 있기에
   쿠버네티스기반인 EKS 보다는 쉽습니다.
2. 컨트롤플레인 비용이 있는 EKS 와 달리 ECS 는 그에 대한 비용이 없기에 저렴합니다.
3. ECS 는 컨테이너만 관리하기에 유지관리가 덜필요합니다. 반면 EKS 는 정기적인 컨트롤플레인 업그
   레이드와 같은 추가 유지관리가 필요합니다.
4. EKS 는 helm, kustomize 와 같은 다양한 오픈소스 프로젝트를 활용할 수 있습니다. 반면 ECS 는 제한적인거나 사용가능한게 거의 없습니다. 
5. ECS 는 AWS 독점 상품이기에 특정 벤더에 종속되지만, EKS 는 쿠버네티스기반으로 구축되어있기에 타 벤더사로
   쉽게 마이그레이션이 가능합니다. 

EC2 와 Fargate 도 앞선 장단점을 총 정리하여 차이점을 비교하면 다음과 같습니다.

 

관리는, 사용자가 인스턴스를 관리하는 ec2 에 비해 aws 가 관리하는 점이라는 것,

ec2 는 사용한 만큼 지불하지만, fargate 는 컨테이너 사양에 따라 비용이 결정된다는 점

더불어 수동으로 확장 및 축소가 가능하지만, fargate는 자동으로 확장 과 축소가 가능하다는 것

또한 ec2 는 설정의 복잡도가 높으며, fargate는 낮은것

ec2 는 이로서 커스텀 설정이 필요한 경우에 사용이 가능하고,

fargate는 서버 관리없이 가볍게 컨테이너 실행을 원할 때 사용이 가능합니다. 

그럼 대체 뭘 써야해요?

• 비용
• 확장성
• 신뢰성
• 엔지니어링 관점
  즉, 본인의 상황과 선택에 따라 선택하시면 됩니다.

 

이상으로, 저의 발표 정리글을 마치겠습니다.

도움이 되셨으면 좋겠네요! 하핫 저도 아직 배워야할게 한참입니다..