ECS vs EKS의 차이점 (그리고 EC2 vs Fargate 차이)

AWS로 아키텍처를 구축하려고 할 때 4가지 아키텍처 중 1가지를 골라야 한다.

AWS ECS와 EKS를 선택할 때 요구사항과 관련지어 잘 선택하는게 중요하다.

아래의 4가지 관점을 참고해서 어떤게 나에게 맞을지 찾아보자.

 

1. 비용
2. 확장성
3. 신뢰성
4. 엔지니어링 관점

 

 

아래 내용은 "AWS 컨테이너 설계와 구축 철저 입문"이라는 책을 읽고 요약한 내용입니다 :)

 

---

 

1. AWS가 제공하는 컨테이너 서비스

제어 플레인이란?

• 컨테이너 기술에서는 Control plane이란 컨테이너를 관리하는 기능을 의미한다.
• AWS에서는 ECS와 EKS로 나뉜다.
• ECS란?
  • AWS에서 제공하는 Elastic Container Service의 줄임말이며, 완전 관리형 컨테이너 오케스트레이터
  • 컨테이너 오케스트레이션 = 컨테이너를 관리한다는 의미이다.
  • 컨테이너를 동작시키는 실행 환경을 제공하는 서비스는 아니다.
  • 태스크(Task)
    • 컨테이너가 동작하는 컴포넌트
    • 태스크는 하나 이상의 컨테이너로 구성된 애플리케이션의 실행 단위
  • 태스크 정의(Task Definition)
    • 태스크를 만드는 템플릿 정의. JSON 형식
    • 배포할 컨테이너 이미지, 태스크와 컨테이너에 할당할 자원, IAM 역할, CloudWatch Logs 출력 장소등을 지정한다.
  • 서비스 (Service)
    • 지정한 수만큼 태스크를 유지하는 스케줄러
    • 실행할 태스크의 수에 맞춰 로드 밸런서와 태스크를 실행할 네트워크를 지정함
    • 태스크가 종료되는 경우 태스크 정의를 바탕으로 새로운 태스크를 만들어 지정된 태스크 수를 유지함.
  • 클러스터(Cluster)
    • 서비스와 태스크를 실행하는 논리 그룹
• EKS
  • Elastic Kubernets Service는 완전 관리형 쿠버네티스 서비스
  • 쿠버네티스 컴포넌트는 쿠버네티스 제어 플레인과 쿠버네티스 노드(Worker 노드)로 구성됨
  • EKS를 통해 쿠버네티즈 제어 플레인 관리를 AWS에 위임하여 건전하게 유지할 수 있음
  • 이점?
    • 쿠버네티스 노드를 동작시키는 실행 환경으로 뒤에 설명할 Fargate(완전 관리형 실행 환경)을 선택할 수 있다.
    • AWS와 연계가 가능함.

데이터 플레인이란?

• 컨테이너가 실제로 동작하는 자원 환경을 지정한다. (EC2와 Fargate가 있다.)
• AWS가 제공하는 데이터 플레인 2가지
  • EC2 (Elastic Compute Cloud)
    • AWS에서 가상 머신을 이용가능한 서비스
    • 제공되는 가상 이미지는 인스턴스라고 하며, 필요에 따라 사양(CPU 코어 수, 메모리 용량, 스토리지)를 변경할 수 있음
    • EC2는 ECS, EKS의 데이터 플레인이 될 수 있음
      • EC2 사용시 호스트 운영비용이 높아짐. 자원 할당, OS 업데이트, 보안패치 적용, 서버 모니터링 같은 책임이 늘어나기 때문(공동 책임 모델)
      • 대신 사용자 요구사항에 따른 설계가 가능해지며 유연한 설계가 가능
  • Fargate
    • ECS와 EKS에서 사용가능한 컨테이너용 서버리스 컴퓨팅 엔진
    • 장점
      • 호스트를 관리하지 않아도 됨. 서버 확장, 패치 적용, 보호, 관리 같은 운영 오버헤드가 없음
      • Fargate 실행환경은 AWS에서 항상 최신으로 유지
    • 단점
      • EC2보다 가격이 비싸다
      • AWS 사용자가 직접 OS를 조작할 수 없음. 커널관련 매개변수를 세세하기 튜닝해야할 경우 맞지 않음.
      • CPU/메모리 할당에 자한, 컨테이너 기동시간이 다소 오래 걸림
    • OS 운영에서 해방되는 아주 좋은 장점이 있어 운영 인력을 확충하지 않아도 됨. → TCO 관점으로 매우 유리

저장소 (Repository)

• 컨테이너 서비스에 대한 저장소, 컨테이너 이미지가 저장되는 서비스 (AWS에는 ECR로 대체된다.)
• ECR
  • Elastic Container Registry, 완전 관리형 컨테이너 저장소
  • ECS와의 연계가 쉬워 ECR에 이미지 저장후 간단히 가져와서 배포할 수 있음. (Docker Hub와 같은 역할)
  • 일반적인 컨테이너 저장소는 도커 허브가 있다.
  • AWS 시스템 구축시 다른 서비스와의 연계 및 보안을 위해 ECR을 추천함

기타 서비스

• AWS Lambda
  • 소스 코드를 업로드 하기만 해도, 애플리케이션을 실행할 수 있는 서비스.
  • AWS에서 제공하는 컴퓨팅 자원을 인프라로 활용해 자동으로 애플리케이션을 구축해주는 완전관리형 서비스
  • Friecraker라는 컨테이너에서 실행되며 경량 마이크로 가상 머신을 실행함. 즉, 컨테이너 관련 기술을 사용
• AWS App Runner
  • 웹 애플리케이션을 빠르게 구축, 배포할 수 있게 해주는 완전 관리형 서비스
  • 깃허브와 연동해 소스코드를 앱 러너에서 배포/빌드
  • Fargate와 다르게 인프라 설계가 필요없음.
  • 인프라 관련 구축을 모두 블랙박스화해서 관리할 수 있게 해줌

2. 아키텍처 구성 예시

4가지의 컨테이너 패턴이 존재한다. 우리는 비용, 확장성, 신뢰성, 엔지니어 관점에서 제일 잘 맞는 아키텍처를 선택하면 된다. 

 

아키텍처를 고르는 4가지 관점

• 비용
  • AWS 서비스 사용료로 지불하는 비용 + 운영 비용 + 인적 비용 + 학습 비용
• 확장성
  • 배포의 신속성, 수평 스케일링, 자원 확장(수직 스케일링)에 중점
• 신뢰성
  • 의도한 기능을 워크로드가 의도대로 수행하는 것을 보증
  • 문제가 발생했을 때 신속한 복구가 가능한지 살펴보기
• 엔지니어링 관점
  • 엔지니어 확보의 용이성 비교

ECS on EC2

• 제어플레인이 ECS, 데이터플레인이 EC2인 아키텍처
• EC2에 여러개의 ECS 태스크를 실행하여 태스크 위에서 컨테이너를 가동시킴
• 비용
  • EC2 인스턴스 및 EBS 볼륨에 대한 서비스 이용 비용이 발생함
  • EC2 인스턴스는 실행되는 만큼 비용이 발생, 인스턴스 크기가 커질수록 시간당 단가도 커짐
  • 너무 작은 인스턴스 선택시 ECS에서 배치하는 태스크를 확장할 수 없음.
  • 운영 비용이 높다. EC2의 유지보수가 발생함. (OS 업데이트 및 보안 패치 적용)
  • 학습 비용이 낮음. 온프레미스 경험과 검색을 통한 정보를 활용할 수 있어 비교적 구축 정보를 많이 얻을 수 있음
• 확장성
  • 배포 신속성 우수. 배포시 이미지 캐시를 EC2 호스트에 저장할 수 있음.
  • 수평 스케일링은 약함. 확보한 용량까지만 수평 스케일링이 가능하기 때문임
  • 자원 확장 우수. EC2 사양은 콘솔에서 클릭 몇번으로 변경 가능
• 신뢰성
  • 장애 조사가 쉬운편. 직접 인스턴스에 접근해서 원인 분석하기 (ssh 또는 system manager 사용)
  • ECS는 AWS 자체 오케스트레이션이므로 내부동작에 대한 지원을 받을 수 있음
• 엔지니어링 관점
  • 엔지니어 수가 절대적으로 많은 편
  • 새로운 기술은 아님

ECS on Fargate

• 제어 플레인이 ECS, 데이터 플레인이 Fargate인 아키텍처
• 1개의 Fargate에 1개의 태스크를 싱행
• 비용
  • vCPU와 메모리 자원에 대한 비용이 발생함. 컨테이너 이미지를 취득한 시점부터 ECS 태스크를 종료될 때까지를 계산하여 초단위로 과금 → 다소 비쌈
  • 운영 비용이 낮다. 인프라 고나리 비용이 들지 않음
  • 학습비용이 낮음
• 확장성
  • 배포 신속성이 낮음.
    • 컨테이너 별로 ENI(Elastic Network Interface)를 연결해야됨. ENI 생성에는 시간이 걸림
    • 이미지 캐시가 불가능함. 컨테이너 구동시 컨테이너 이미지를 가져와야함.
  • 작업에 할당되는 휘발성 스토리즈는 2021 9월 기준 200GB임.
  • 기계 학습에 사용되는 노드 같은 대용량 메모리를 요구할 경우 호스트용으로 적합하지 않음
• 신뢰성
  • SSH를 통해 호스트에 접근할 수 없음.
  • ‘Amazon ECS Exec’를 활용해 컨테이너에 대화형 셸을 이용해 조작하거나 명령을 실행할 수 있음
• 엔지니어링 관점
  • 엔지니어 확보가 쉬운편
  • ECS on EC2보다는 신기술이라 새로운 것에 도전하고픈 엔지니어 모집 가능

EKS on EC2

• 제어플레인이 EKS, 데이터 플레인이 EC2
• 비용
  • 제어플레인인 EKS에 대한 비용도 생김.
  • 운영 비용이 높음. 쿠버네티스는 약 3개월에 한번 마이너 버전이 나옴. EKS의 마이너 버전은 출시 후 약 12개월 지원됨. 즉 컨테이너 플랫폼 버전을 정기적으로 업데이트해야 함
  • 쿠버네티스의 학습비용이 높음.
• 확장성
  • 배포 속도가 우수함.
  • 수평적 스케일을 충분히 고려한 성능 계획의 어려움은 EKS에도 마찬가지로 존재함.
• 신뢰성
  • 쿠버네티스 자체에 문제가 발생한 경우, AWS에서 해결할 수 없는 문제가 된다.
• 엔지니어링 관점
  • 컨테이너 오케스트레이터를 이용하는 77%의 사용자가 쿠버네티스를 이용함
  • 쿠버네티스 커뮤니티가 활성화되어 있으며 열정도 매우 큼.
  • 새로운 체제와 기술을 배우려는 엔지니어 조직이라면 EKS를 채용하는 것은 충분한 가치가 있을 것

EKS on Fargate

• 제어플레인이 ‘EKS’, 데이터 플레인이 ‘Fargate’인 아키텍처
• 데이터 플레인을 모두 Fargate로 하지 않음
• 상주 실행이 필요한 처리를 위해 EC2를 준비하고, 스팟 처리가 필요한 경우에는 Fargate를 이용함.
• Fargate를 이용하는 Pod는 Fargate 프로필에 의 해결정됨
• Pod와 노드의 관계
  • EKS on Fargate에서는 Fargate 노드 위에 1개의 Pod만을 만들 수 있음. → 쿠버네티스의 컴포넌트인 DaemonSet을 이용할 수 없음. DaemonSet은 Pod의 로그를 수집하기 위해 자주 사용됨
• 관리 권한 컨테이너 이용
  • Fargate 노드에서는 관리 권한 컨테이너를 이용할 수 없음. 이것은 쿠버네티스의 제한이 아니라 EKS on Fargate의 제한이다.
• 클러스터 외부로부터의 통신이 가능한 로드밸런서
  • EKS의 엔드포인트를 클러스터 외부에 공개할 때 ELB를 이용함. EKS on EC2에는 다음 Service와 Ingress를 로드 밸런서로 이용할 수 있음
  • Service
    • CLB (Class Load Balancer)
    • NLB (Network Load Balancer)
  • Ingress
    • AWS Load Balacer Controller
    • NLB (Network Load Balancer)
• 비용
  • EKS비용 + Fargate 비용. Fargate 노드 이용시 실행 시간만큼만 부과됨. → 스팟 사용으로 비용을 줄일 수 있음 (비용 절감 가능)
  • 운영비용은 EKS on EC2보다 낮음. (운영에서 해방됨)
  • Fargate의 버전업 작업이 불필요하다.
  • 학습 비용이 가장 높다.
• 확장성
  • Fargate 특성상 느림. 4vCPU, 30GB가 상한이며 GPU를 사용할 수 없음.
• 신뢰성
  • EKS on EC2의 제어플레인과 ECS on Fargate의 데이터플레인과 같다.
• 엔지니어링 관점
  • EKS를 제어플레인으로 사용하므로 쿠버네티스 관련 인재를 채용하게 된다.
  • 관련 인재가 적으며 기술이 성숙되지 않음
  • 스터디 그룹이 많으며 도전 요소가 많은 아키텍처

3. 각 아키텍처를 적용한 사용 예

온프레미스 또는 EC2에 쿠버네티스를 사용할 경우

• 온프레미스 자산을 클라우드로 이전하고 싶은 경우
• 제어 플레인을 직접 운영하는 운영 비용을 줄이기 위해 아키텍처를 변경하는 경우
• 대상 아키텍처
  • 제어 플레인을 ECS로 변경하려는 경우, 쿠버네티스 매니페스트에 정의된 구성을 AWS 서비스에서 동작하도록 변경해야 함 → 비용이 매우 크므로 EKS를 우선 선택하기
  • EKS on Fargate는 제약이 많고 DaemonSet을 사용할 수 없기 때문에 우선은 EKS on EC2를 구현

블록체인을 이용하는 풀 노드(Full node)를 구축하는 경우

• 블록체인은 비트코인같은 가상 화폐의 기반이 되는 기술. 다양한 정보를 블록체인에 저장해 변조를 불가능하게하고 투명성을 확보함.
• 블록체인 플랫폼 이더리움은 풀 노드(Full node)와 검증자(validator), 채굴자(miner)의 역할이 있음
• 풀 노드는 모든 트랜잭션 블록과 트랙잭션을 보유, 관리, 공유하는 서버 역할을 한다.
• 노드에 존재하는 모든 블록을 가지고 있기 때문에 대용량 데이터를 로컬에 저장하고 있어야 한다.
• 대상 아키텍처
  • 고려해야할 것은 대용량 데이터를 로컬에 저장해야 한다는 것
  • 이더리움 풀 노드는 수백기가의 저장 용량이 필요함. (이더리움의 전체 트랜잭션을 다뤄야 하므로) → EC2 선택 (Fargate 스토리지보다 큼)
  • AWS 이외의 클라우드나 온프레미스에서 동작시키는 것을 고려한다면 ‘EKS’, 학습 비용과 운영 비용을 고려한다면 ‘ECS’를 선택

기계학습이 필요한 경우

• 기계학습시 추론 모델 구축과 추론 처리 부분에서 병목이 생김
• 막대한 처리가 병렬로 수행되어야 하므로 CPI보다는 병렬 처리에 특화된 GPU를 이용해 처리 실행
• 대상 아키텍처
  • EC2에는 학습과 추론에 특화된 P3, Inf1, G4같은 인스턴스가 준비됨. GPU 사용과 기계학습에 특화된 칩셋을 사용할 수 있음.
  • 전용 인스턴스를 사용하면 시간이 많이 걸리는 추론 처리와 추론 모델 생성에 걸리는 시간을 줄일 수 있다.
  • Fargate의 경우 제약으로 GPU를 사용할 수 없다. 물론 Faragate 내부에서 컨테이너로 CPU를 활용한 학습 및 추론 처리는 가능하다. → 효율적이지 않음
  • 기계학습 비즈니스는 학습과 추론을 반복해야하기에 짧은 시간에 처리하는 것이 좋음 → EC2 선택
  • 제어플레인의 경우 ECS, EKS 모두 좋음
  • 기계학습 위주의 개발 조직은 데이터 사이언스 지식이 더 높을 것. 프로덕트 개발만을 하는 팀으로 구성된다면 ECS가 유리함.
  • 온프레미스 또는 다른 클라우드에 서비스를 배포할 계획이라면 EKS 선택

높은 자원 집약율을 실현하고자 하는 경우

• EC2에서 높은 자원 집약율이란 인스턴스에 할당된 CPU와 메모리를 낭비하지 않는 것을 말함.
• 특정 인스턴스의 CPU 가동률이 100%에 메모리를 모두 사용하는 상태가 가장 높은 자원 집약율
• 온프레미스의 경우 과부화 상태가 되면 시스템이 다운되거나 커널 패닉이 발생할 수 있음 → 좋지 않음
• 클라우드의 경우 종량 과금제이므로 자원을 모두 활용하는것이 가장 비용 효율이 좋다.
• 컨테이너가 처리해야할 처리량을 고려해 적절한 자원을 할당하기
• 대상 아키텍처
  • 처리량에 따라 적절한 인스턴스 유형을 지정해야한다. 매번 다른 인스턴스 유형을 이용해야하는 것은 매우 힘듬 → Fargate
  • Fargate 사용시 처리량에 따라 CPU와 메모리 요건을 지정해 알아서 컨테이너를 실행함.
  • 자원을 낭비 없이 활용해 높은 자원 집약율을 실현하기 위한 데이터 플레인으로 적합

SI로 서비스를 만드는 경우

• 타사의 의뢰를 받아 서비스를 만드는 경우, 발주자의 이익이 되지 않은 제안은 실행이 힘듬
• 기능과 직접적인 관련이 없어 개선이 어렵다.
• 대상 아키텍처
  • SI로 개발시 다양한 사례를 접할 수 있다는 장점이 있음
  • 역사가 길수록 사례가 많음. → ECS
  • SI도 몇년에 한번 인프라 및 미들웨어 업데이트를 진행함. ECS 선택시 AWS에서 자동으로 업데이트함.
  • 자체 Ops 조직을 구축해 Dev 조직과 연계할 수 있다면 쿠버네티스 고려
  • 운영보다 기능에 집중한다면 운영비용을 줄일 수 있는 Fargate 선택

자사 제품으로 서비스를 개발하는 경우

• SI와 마찬가지로 기능에 직접적으로 관련이 없는 개선이 어려움.
• 자사 개발시 새롭게 시도한 것에 대한 노하우가 회사에 남음. 엔지니어에게 홍보가 가능함.
• 대상 아키텍처
  • 제품 출시 단계에서는 ECS on EC2 또는 ECS on Fargate를 선택
  • 기술적 도전할 여유가 생기면 EKS 도전 (일종의 광고가 됨)
  • 운영 비용을 줄이기 위해 우선 ‘Fargate’ 선택
  • 제어플레인은 홍보 목적의 쿠버네티스나 AWS 지원이 가능한 ECS 중 택 1

4. AWS에서 컨테이너를 이용할 때의 장점

로드맵 정보 제공

• 깃허브 컨테이너 로드맵 저장소에서 확인 가능
• 왜 저장소를 만들었나?
  • 이용자가 계획을 세울때 개발중인 것을 기반으로 결정함. 계획에 필요한 통찰력을 제공하기 위해서
• 로드맵에 모든 것이 있나?
  • ECS, Fargate, ECR, ELS 같은 AWS가 제공하는 OSS 프로젝트에 대한 대부분의 개발 작업이 포함됨.
• 피드백을 제공하려면?
  • 깃허브 Issue 만들기. 오류 보고도 가능함.

지속적인 요금 개정

• AWS는 가볍고 편하게 시작가능. 서비스 이용요금도 합리적임. 요금이 지속적으로 개정되고 있음
• Saving Plans을 활용해 단위 시간당 EC2, Fargate, 람다 이용요금을 합산해 가장 저렴한 요금을 제공

다수의 컨테이너 활용 사례

• 활용 사례가 많고 대규모 컨퍼런스 참고 자료를 이용.

풍부한 학습 매뉴얼

• AWS 공식 문서. 매뉴얼로 참고할 것. 서비스 이용시 옵션, 동작을 전체적으로 배울 수 있음
• AWS Webinar. AWS에서 제공하는 온라인 컨텐츠. 기초지식과 각 서비스 지식을 폭넓게 알기에 좋음.

공식 컨퍼런스

• AWS re:Invent, AWS Summit이 있음. re:Invent에서 발표된 자료 대부분은 이벤트 후 인터넷에 공개됨
• AWS Summit의 발표자료는 AWS 블로그, AWS Stash, Slideshare에서 확인가능

AWSKRUG

• 커뮤니티에 참가하여 서비스를 이용하는 다른 이용자에게 배우기

AWS Certification

• aws 관련 지식 자격증. 학습 콘텐츠는 단순 암기보다는 결과물을 내는 방식.
• 실무 관련 문제가 나오므로 체계적인 학습에 도움됨. 현재의 지식상태를 재확인하는 목적

Qwiklabs

• 클라우드 플랫폼, 인프라 소프트웨어의 체험을 할 수 있는 학습 환경을 제공함
• 유료, 무료 강의가 있음.

AWS Workshops

• AWS에서 공개적으로 진행하는 실습이벤트.
• 레벨 100~400, 워크숍은 무료지만 AWS환경을 실제로 이용해야하므로 과금이 발생할 수 있음

Awesome AWS Workshops

• 분야별 워크숍. 워크숍은 무료, AWS 과금 발생