AWS ECS Deep Dive

이 문서는 AWS ECS 딥 다이브에 대한 문서입니다.
이 내용을 통해서 ECS의 구조와 그에 따른 회복력(Resilience) 가용성(Availability)을 알아봅니다.

결론 및 해석

[해석] 파트는 이 문서의 맨 마지막에 작성되었습니다.

정의

Amazon ECS는 EC2, Fargate 등의 컴퓨팅 리소스 위에 컨테이너를 프로비저닝해서 사용하는 서비스입니다.

• 컨테이너 인스턴스는 작업(Task)으로 명명됩니다.

• 작업들은 작업 정의(Task Definition)으로 선언되어 관리됩니다.

• 컨테이너의 생성, 수정, 삭제 등을 관리하기 위한 클러스터(Cluster)가 별도로 존재합니다.

• 모든 고객의 클러스터는 Amazon ECS 컨트롤 플레인(Control Plane)에 소속되어 있으며, 아래 고유키를 통해서 식별하고 있습니다.

  1. AWS_ACCOUNT_ID

  2. CLUSTER_ID

해석

Amazon ECS는 Amazon EKS를 도입하기 전에 시범 운행을 하기 좋아보이는 서비스입니다. 그 이유는 다음과 같은 유사한 부분 때문입니다.

1. Amazon ECS와 EKS의 컨트롤 플레인은 설계 기본 구조가 유사합니다.

2. Amazon ECS와 EKS의 컨테이너에 대한 선언적 특징이 유사합니다.

3. Amazon ECS는 EKS에 비해 자유도가 낮지만 동시에 첫 사용이 편리합니다.

4. Amazon ECS EC2는 EC2에 비해 추가 비용이 존재하지 않습니다.
   클러스터 비용 등이 0$이기 때문

따라서 컨테이너 워크로드를 개발계 → 프로덕션을 거쳐서 운영해보는 것도 좋아보입니다.

즉, 여러 이유로 인프라 고도화가 필요한데 Amazon EKS 만큼의 복잡성을 필요로 하지 않다면 나쁘지 않은 선택일 것이라 생각합니다.

사전 지식

AWS ECS Deep Dive를 제대로 이해하기 위해서 필요한 기초 사전 지식들입니다.

1. 기본 구성요소

2. AWS 리전과 가용 영역

기본 구성요소

ECS는 기본적으로 다음 요소들로 구성됩니다.

1. 클러스터

   컨테이너 인스턴스들을 논리적인 그룹으로 묶는 단위

2. 컨테이너 인스턴스

   컨테이너를 배포하기 위해서 실제로 존재하는 컴퓨터
   일반적으로 EC2 혹은 Fargate가 있으며, Fargate는 서버리스 컴퓨팅 유형임

3. 서비스
   목적 단위의 분류

4. 작업

   ECS 컨테이너 구성을 포함한 작업 정의가 포함되어 있음

5. 작업 선언
   ECS 작업에 대해 선언형 명시

AWS 리전과 가용 영역

작성일(2024-04-22) 기준, AWS는 33개의 Region과 105개의 가용 영역을 가지고 있습니다.

리전은 각 나라별로 구성되어 있는 AWS 서비스 제공 단위입니다.

가용 영역은 여러 물리적인 위치에 걸쳐서 구성된 논리적인 단위입니다.

AWS 가용 영역의 이점

각 AWS 리전은 최소 2~3개 이상의 가용 영역을 포함하도록 설계되어 있습니다.

이런 3개 이상의 가용 영역은 N개의 물리적 데이터 센터 위에 논리적으로 구성된 그룹입니다.

이런 각 가용 영역은 독립적인 전원 공급(Power), 네트워킹(Networking), 냉각(Cooling) 시스템을 가지고 있습니다.

즉, 각 가용 영역은 일반적으로 서로의 장애 상황에서 자유롭다라고 생각할 수 있습니다.

Amazon ECS 소개

작성일 : 2024-04-22
참고자료 : 2번

1. 간단한 Amazon ECS 정의

2. Amazon ECS 지원 범위

3. Amazon ECS와 타 서비스의 통합

간단한 Amazon ECS 정의

• 부제 : Short intro to Amazon ECS

Amazon ECS는 완전관리형 컨테이너 서비스로서 고성능 및 고확작성을 지원해줍니다.

컨테이너가 가동되는 서버의 유형으로는 EC2나 Fargate 뿐만 아니라 Outposts와 같은 광범위한 컴퓨팅 유형과 통합 가능합니다.

Amazon ECS의 지원 범위

AWS Global Infra에 따르면 AWS는 33개의 리전을 제공합니다.

이에 반해 Amazon ECS는 32개의 리전을 지원합니다.

Amazon ECS와 타 서비스의 통합

Amazon ECS는 다양한 AWS 서비스들과의 강력한 통합도 지원됩니다.

1. Amazon Sagemaker
   완전관리형 머신러닝 서비스
   머신러닝 모델을 구축, 학습 및 배포 가능

2. Amazon Lex
   자연어 이해 및 대화형 인터페이스를 구축하는데 사용
   챗봇 및 음성/텍스트 기반의 상호 작용 지원

3. Amazon Polly
   텍스트를 음성으로 변환하는 AI 서비스

4. AWS Batch
   대규모의 배치 작업을 자동화하고 조정하기 위한 서비스

5. Amazon.com Recommendation Engine
   Amazon 제품 추천 시스템
   고객의 이전 구매 기록 및 행동 패턴 기반, 맞춤형 제품 추천 제공

디자인 원칙(Design Principle)

작성일 : 2024-04-22
참고자료 : 2번

Amazon ECS는 실패가 당연히 일어날 수 있는 일로 정의하는 시스템을 구축합니다. 따라서 이에 맞춰서 다양한 구조적인 특징이 반영되었습니다.

We needed to build systems that embrace failure as a natural occurrence
Dr. Werner Vogels / VP and CTO, Amazon.com

또한 Amazon ECS는 다음과 같은 디자인 원칙 및 목표를 정의하고 지향하고 있습니다.

1. 100%에 가까운 고가용성 지향

2. 서비스 고회복력 지향

Amazon ECS의 구조적인 가용성

작성일 : 2024-04-22
참고자료 : 2번

가용 영역를 사용한 고정적인 안정성

Amazon ECS 컨트롤 플레인는 최소 3개 이상의 가용 영역에 배포된다.
각 가용 영역의 수가 3이라고 하였을 때, 가용 영역 별 컨트롤 플레인의 트래픽 수용량은 약 33.3%이 아니라 50%로 배포된다.
즉, 기본적으로 컨트롤 플레인은 오버 프로비저닝된다.

ECS는 전체 과정을 관리할 클러스터를 가지고 있습니다.

이런 클러스터를 포함한 개념을 컨트롤 플레인(Control Plane)이라고 부릅니다. 이런 컨트롤 플레인은 고가용성을 위해서 최소 3개 이상의 가용 영역 위에 배포됩니다.

따라서 각 트래픽은 약 33.3% 씩 3개의 가용 영역에 분산될 것입니다.

하지만 1개의 가용 영역이 마비되면, 시스템 전체의 트래픽 수용량은 66.7%로 줄어들어 연속적인 서비스 장애를 일으킬 수 있습니다.

1. ECS Cluster를 향한 API 콜의 실패

2. ECS Cluster를 향한 API 콜 응답 지연

3. 부하를 견디지 못한 ECS Cluster의 장애

이런 문제를 해결하기 위해서 Amazon ECS는 기본적으로 각 트래픽이 50%씩 들어오는 상황을 가정하고 배포됩니다.

따라서 1개의 가용 영역이 마비되어도, 시스템 전체의 트래픽 수용량은 100%를 유지할 수 있습니다.

즉, 오버 프로비저닝/프리 스케일링을 통해서 이런 문제를 예방하려고 하고 있습니다.

Amazon ECS를 사용한 고정적인 안정성

Amazon ECS는 작업 목록을 선언형으로 작성합니다.
따라서 특정한 작업이 실패하였을 때, 선언된 숫자와 성공한 숫자를 기준으로 성공을 멱등성있게 보장합니다.

• Fargate를 활용한 Amazon ECS

• EC2를 활용한 Amazon ECS

프리스케일 규모 결정

• 용어 설명

  국문명	영문명
  기본 선언 갯수	Base Desired Count
  목표 가용 영역	Target AZs
  목표 선언 갯수	Target Desired Count

Amazon ECS 컨트롤 플레인의 기본 선언 갯수가 6일 때, 이를 기준으로 다음의 공식으로 목표 선언 갯수가 정해집니다.

• 목표 선언 갯수 = 기본 선언 갯수 × (목표 가용 영역 / 목표 가용 영역 - 1)

기본 가용 영역 설정인 3에서는 9개, 720개의 목표 선언 갯수가 계산되지만, 가용 영역 수를 4로 늘리면 12개, 1200개로 늘어납니다.

즉, 가용 영역의 수가 증가하면 프리스케일의 규모는 더 많이 증가합니다.

워크로드의 고립과 샤딩

Amazon ECS 컨트롤 플레인이 많은 수의 소프트웨어 배포를 담당하게 됩니다. 그렇다면 각 소프트웨어 배포를 진행하는 작업 간의 고립은 어떻게 보장될까요?

즉, 개별 컨트롤 플레인 간의 고립은 어떻게 구현이 되어 있을까요?

Amazon ECS 컨트롤 플레인은 매우 얇고 작은 파티셔닝을 이용해서 컨트롤 플레인을 분할하고 고립하여 관리합니다.

그리고 이를 관리하고 접근하기 위한 Amazon ECS Routing Proxy를 사용하고 있습니다. 이 친구의 주된 역할은 다음과 같습니다.

1. 워크로드 고립

2. 장애 억제

3. 스케일 아웃, 스케일 업

4. 테스트 가능성

5. 유지 가능성

Amazon ECS Cluster의 고립

Amazon ECS 컨트롤 플레인의 샤딩을 통해서 각각의 ECS Cluster는 고립(격리)되어 가동됩니다. 각각의 Cluster에 대한 네임스페이스는 ACCOUNT_ID와 CLUSTER_ID로 구성되어 있고 매우 효율적으로 작동합니다.

따라서 AWS에서는 Amacon ECS Cluster를 0$의 비용으로 제공해줄 수 있었습니다.

Amazon ECS의 운영적인 복원력

롤링 배포, 정적인 안정성 그리고 고립

Amazon ECS의 컨테이너 인스턴스가 총 3개의 가용 영역을 선택하였다고 가정합시다.

이런 경우, 코드 변경 사항 Change A가 발생하면, 가용 영역 1부터 3까지 어떤 순서로 배포가 될까요?

일반적으로 많이 쓰이는 롤링 배포의 경우, 가용 영역 1 ~ 3에 각각 Cell 1 ~3이 존재합니다.

그리고 Cell 1의 작업(컨테이너)들이 하나씩 배포가 되며, 그 중 하나가 실패 할 경우 변화가 발생한 부분이 모두 롤백됩니다.

즉, 기존에 트래픽을 감당하던 컨테이너에는 아무 영향이 없기 때문에 정적인 안정성이 보장된다고 할 수 있습니다.

또한 개별 버전에 대한 베이크 타임(Bake Time) 단계에서의 장애가 발생 시, 네트워크 레벨에서도 자동으로 기존 버전(Previous Version)으로 라우팅됩니다.

멀티 리전에서의 롤링 배포

바로 위에서 싱글 리전에서의 롤링 배포에 대해서 논의하였습니다. 그렇다면 멀티 리전에서의 롤링 배포는 어떻게 구성해야 할까요?

그 외

ECS의 지속적인 개선

ECS의 지속적인 개선 및 COE, Anatomy of a COE 등의 내용은 생략하였습니다.

몇 가지 참고 문서

마지막으로 Amazon ECS의 몇 가지 워크로드에 대한 참고 링크가 포함되어 있습니다.

참고자료

1. Jibinary (Blog) | [AWS] [Elastic Container Service] ECS의 구조와 특징 쉽게 이해하기

2. AWS Events (Youtube) | AWS re:Invent 2023 - Deep dive into Amazon ECS resilience and availability (CON401)

3. Amazon Web Services (Youtube) | AWS Summit Tel Aviv 2019 | Deep Dive on Amazon Elastic Container Service (ECS)