AWS ECS 정리

VM (Virtual Machine) VS Container 구조

Container는 VM 처럼 Guest OS가 필요하지 않으므로 가볍고 빠른데 비해 Host OS에 종속 된다. 이때 Window Host는 지원하지 않고 Linux에서만 생성 가능

 

Docker 구조

Client가 Host(Server)에 접속하여 Docker명령어를 실행하면 Host(Server)와 통신되는 Repository(ECR, Docker Hub 등)을 이용하여 Docker 이미지를 다운로드 받아서 Cotainer를 구동시킨다.

 

container runtime

컨테이너를 실행시키는 엔진으로, OS위에 컨테이너를 실행하기 위한 소프트웨어 구성 요소이다. 리포지토리에 컨테이너 로드, 컨테이너 수명주기, 로컬 리소스 모니터링 및 컨테이너를 위한 리소스 분리 등을 담당한다. 일반적으로 container runtime은 오케스트레이션과 같이 동작한다. 오케스트레이션은 클러스에 있는 모든 노드의 확장, 보안, 네트워크 등을 담당하고, container runtime은 클러스터 안의 노드 위에 가동되는 컨테이너 개개인을 담당한다.

종류: Containerd, CRI-O 등

 

ECR(Elastic Container Registry)

• ECR은 컨테이너를 위한 프라이빗 도커 레포지토리이며, ECR를 사용하면 AWS 컨테이너 서비스와 호환성 측면에서 이점이 있다.
• 클러스터를 ECR과 쉽게 연결할 수 있으며, 새로운 버전의 이미지가 올라오면 자동으로 클러스터에 넘어가게끔 설정할 수도 있는 등 다양한 기능을 누릴 수 있다.
• 구성요소: 레지스틸, 사용자 권한 토큰, 리포지토리, 리포지토리 정책, 이미지
• AWS에서 ECR 접근을 위해선느 보안상 VPC Endpoint(Private 통신)를 생성하여 사용을 권장

 

 

컨테이너 오케스트레이션(Container Orchestration)

• 컨테이너 개수가 늘어나면서 리소스 등 관리 포인트가 늘어나는 데, 이것을 자동화해주는 프로그램
• Ex) 쿠버네티스(k8s), ECS, Docker Compose 등 여러 프로그램 존재

 

ECS(Elastic Container Service)

컨테이너의 라이프사이클을 관리하는 AWS의 컨테이너 오케스트레이션 서비스

컨테이너 라이프사이클엔  'Container Start', 'Re-Schedule', 'Load Balancing' 등이 포

ECS는 내부적으로 Cluster, Task, Sevice 이렇게 세 가지 메인으로 구성

Cluster:

• 여러 컨테이너의 하드웨어 리소스를 논리적으로 그룹화하는 요소로, Controller Plane과 컨테이너 라이프 사이클을 관리한다.
• Cluster (≒Namespace) : Task가 실행되는 논리적 그룹 

 

Task:

• VM(EC2, Fargate)에 어떻게 컨테이너를 배포할지 내용을 품고 있는 템플릿 메타데이터(mem, cpu, env, dockerfile, etc.. 등)
• Task (≒Pod) : 최대 10개 컨테이너 가능, 모두 같은 Host에 배치

Service:

Auto-Scaling, LB등 컨테이너를 어떻게 배포, 실행, 관리할지 Task보다 Advanced한 설정 내용을 품고 있는 요소

Service (≒Deployment or Service) : Task 배치 전략 (bin-packing, spread, random)

 

 

ECS 동작 방식 

1. ECS 서비스를 이용할 시 ECS Cluster 생성된다.
2. 컨테이너는 VM에서 동작하며, 여기서 VM이란 EC2 또는 Fargate 인스턴스가 된다.
3. EC2는 컨테이너를 호스팅 역할을 하며, ECS Cluster와 연결되어 함께 동작한다. EC2에는 Docker Runtime, Container, Runtime가 있어 컨테이너를 시작할 수 있으며, ECS Agent가 설치되어 있어 Control Plane인 ECS Cluster가 VM를 관리할 수 있다.

정리하자면 EC2를 생성해야 하고, 그것을 ECS Cluster에 연결해야 하며, 새로운 컨테이너를 생성한다면 EC2 인스턴스에 충분한 리소스가 남아 있는지를 고려하고, 또한 OS 및 Docke Runtime, ECS Agent도 관리해야 한다. 물론 이 작업을 위해 유저는 그에 맞는 권한이 있는 있어야 한다. 즉, EC2를 사용한 ECS는 ECS Cluster가 컨테이너 서비스를 관리해주지만 VM의 경우 사용자가 직접 신경 써줘야 하는 부분이 있다는 것이다. 하지만 이런 인프라 관리마저도 AWS에 맡기고 싶다면(컨테이너 라이프사이클, 인프라 호스팅)? 이 경우, EC2 인스턴스의 대체품으로 AWS Fargate를 사용해야 된다.

 

Task 배치 전략

Bin Packing과 Spread는 Amazon ECS에서 컨테이너를 인스턴스에 배치할 때 사용하는 두 가지 배치 전략

Bin Packing 전략

• Bin Packing 전략은 리소스 사용률을 최적화하기 위해 최대한 많은 컨테이너를 가능한 한 적은 수의 인스턴스에 배치하는 방법
• 해당 전략의 주요 목표는 인스턴스 수를 최소화하여 비용을 절감하는 것
• 작동 방식
  1. ECS는 인스턴스의 가용 리소스를 기반으로 컨테이너를 배치
  2. 리소스 사용률이 가장 높은 인스턴스부터 시작하여 가능한 한 많은 컨테이너를 배치
  3. 남은 리소스가 적은 인스턴스에 우선적으로 컨테이너를 배치하여 리소스 사용률을 극대화
  4. 새로운 인스턴스를 시작하는 대신 기존 인스턴스에 가능한 많은 컨테이너를 배치
• 장점: 
  • 리소스 사용 최적화: 인스턴스의 리소스를 최대한 활용하여 비용을 절감
  • 인스턴스 수 감소: 더 적은 수의 인스턴스를 사용하여 리소스 비용을 줄일 수 있음
• 단점
  • 단일 인스턴스 장애 시 위험 증가: 많은 컨테이너가 하나의 인스턴스에 집중되므로, 해당 인스턴스가 실패하면 많은 컨테이너가 영향을 받을 수 있음

Spread 전략

• Spread 전략은 컨테이너를 가능한 한 많은 인스턴스에 고르게 분산시키는 방법
• 해당 전략의 주요 목표는 애플리케이션의 가용성과 장애 내성을 향상시키는 것
• 작동 방식:
  • ECS는 가능한 많은 인스턴스에 컨테이너를 균등하게 배치
  • 리소스가 허용하는 한, 새로운 인스턴스에 컨테이너를 배치하여 전체 클러스터에 고르게 분산
  • 특정 인스턴스에 컨테이너가 집중되지 않도록 한다.
• 장점:
  • 장애 내성 증가: 컨테이너가 여러 인스턴스에 분산되어 있으므로, 단일 인스턴스의 장애가 전체 애플리케이션에 미치는 영향을 최소화
  • 높은 가용성: 컨테이너가 여러 인스턴스에 분산되어 있으므로, 애플리케이션의 가용성이 향상
• 단점:
  • 리소스 사용 최적화 미흡: 인스턴스의 리소스를 최대한 활용하지 않으므로, 비용이 증가
  • 인스턴스 수 증가: 더 많은 인스턴스를 사용하게 되어 리소스 비용이 증가할 수 있음

 

 

ECS VS EKS 구조

ECS, EKS는 Container 오케스트레이션으로 K8S 운영 인력이 없는 ECS 사용 권장

• ECS: AWS Only (EKS 보다 저렴, 쉬움)
• EKS: 범용 K8S