ECS란?

컨테이너화 된 어플리케이션을 배포, 관리, 확장할 수 있도록 돕는 플랫폼

 

ECS 실행 흐름을 요약한 아래 사진을 간략하게 설명해보겠다.

  1. ECR에 있는 Docker Image를 가져와 컨테이너화하여 Container 실행 단위인 Task에 올린다.
  2. Task 관리 단위인 Service에 Task들을 올린다.
  3. Service와 Task의 가장 상위 관리 단위인 Cluster에 Service가 관리하는 Task들을 EC2 또는 Fargate에 배치하여 컨테이너들을 실행시킨다.

즉, Task는 컨테이너(들)을 의미하고, Service는 컨테이너를 유지/관리하는 역할이고, Cluster는 컨테이너들을 EC2 또는 Fargate에 배치하여 실행시키는 최상단의 관리 단위이다.
Fargate란?(EC2와 비교)

ECS 용어

Cluster(클러스터)

클러스터란?

Task와 Service를 실행하는 컨테이너 그룹을 관리하는 최상위 관리 단위
Task와 Service가 실행되는 환경(EC2, Fargate)을 포함하는 개념

  • 컨테이너 실행을 위한 리소스 풀 제공
  • 작업 정의(Task Definition)에 따라 컨테이너 배치
  • 컨테이너 상태 모니터링 및 관리
  • Auto Scaling을 통한 리소스 확장/축소

Service(서비스)

Service란?

Cluster에서 지정된 수의 Task를 동시에 실행하고 관리할 수 있게 해주는 구성
즉, Task를 유지하고 관리하는 역할을 의미한다.(Task 스케일링(Auto Scaling), 자동 복구, 로드 밸런싱 등)

  • Auto Scaling
    • 최소/최대 Task 수를 설정하여 필요에 따라 자동으로 스케일링

  • 자동 복구
    • Task가 종료되거나 장애가 발생했을 때 자동으로 새로운 Task를 생성하여 원하는 Task의 개수 유지
  • 로드 밸런싱
    • 로드 밸런서(ALB)와 연결하여 외부 요청을 Task로 전달
      • 요청을 처리할 적절한 Task로 전달 - 한 서비스에 서로 다른 역할의 Task를 띄우는 경우
      • 특정 Task에만 요청이 몰리지 않도록 균등 분산 - 한 서비스에 특정 역할의 Task만 띄우는 경우

즉, Service는 Task를 관리하는 개념이다.

Task(작업)

Task란?

1개 이상의 컨테이너를 실행하는 단위(컨테이너 실행 그룹)
(한 Task에 여러 개의 컨테이너를 실행할 수도 있지만 보통은 한 Task에 한 컨테이너만 실행하기 때문에 Task == 컨테이너라고 일단은 생각해도 좋다.)

  • Task는 컨테이너 실행 그룹으로써 그 자체로 유지되지 않고 Service에 의해 관리됨

여러 Service에서 각각 Task를 띄우는 경우 vs 하나의 Service에서 여러 개의 Task를 띄우는 경우

1. 여러 Service에서 각각 Task를 띄우는 경우

서로 다른 역할을 하는 서비스들을 개별적으로 관리 가능

 

아래 예시를 통해 이해해보자

  • FE-service와 BE-service라는 두 Service가 있음
  • FE-service는 두 개의 Task를 실행하고 BE-service는 3개의 Task를 실행중임
  • 서로 다른 역할을 하는 서비스이기 때문에 서로 독립적으로 관리하고 로드 밸런스도 개별적으로 설정할 수 있음
2. 하나의 Service에서 여러 개의 Task를 띄우는 경우

로드 밸런싱과 자동 복구가 쉬움

 

아래 예시를 통해 이해해보자

  • web-service라는 Service가 있음
  • web-service가 3개의 Task를 실행하고 있음
  • ALB를 web-service에 연결하면 3개의 Task에 요청 트래픽을 분산하여 균등하게 부하를 분산시킬 수 있음
  • 만약 Task가 하나 죽어도 Service가 새로운 Task를 띄워서 장애 복구 가능

즉, 전자는 역할별로 개별으로 관리하기 위한 방식이고 후자는 같은 역할의 Task를 로드 밸런싱과 장애 복구를 하기 위한 구조이다.
따라서 우리 프로젝트(Tracky)의 경우 hub와 web, emulator 모두 개별적으로 관리해야 하고 로드 밸런싱은 hub만 필요한 구조이기 때문에 후자를 선택해야 한다.

Task Definition(작업 정의)

Task Definition이란?

컨테이너의 사양(작업)을 JSON 형식으로 정의

  • 유형(EC2, Fargate)
  • 사용할 컨테이너 이미지 지정
  • 개발할 포트, CPU/Memory 리소스 지정, 볼륨 설정

스케줄러

ECS 스케줄러의 역할

클러스터에 Task가 언제, 어디에서 몇 개의 Task를 실행할지 결정하는 역할

  • Service를 생성할 때 원하는 Task 개수를 지정하면, 스케줄러가 자동으로 클러스터 내에 배치하고 유지해줌
    • 즉, Task가 죽으면 새로운 Task를 배치해서 유지하는 것을 스케줄러가 담당한다.

이 외에 EC2를 사용할 경우 스케줄러의 역할이 있는데 이는 넘어가겠다.

ECS 네트워크 모드(awsvpc)

awsvpc란?

ECS에서 각 컨테이너에 고유한 ENI(Elastic Network Interface)를 할당하는 네트워크 모드
즉, 컨테이너가 직접 VPC 내에서 EC2 인스턴스처럼 개별적인 IP 주소를 갖게 되고 VPC 내부에서 직접 통신할 수 있는 ECS 네트워크 모드

  • VPC 네트워크 정책 적용 가능
    • 컨테이너에 Security Group(SG) 및 NACL(Network ACL) 적용 가능
  • Fargate에서 필수적으로 사용해야 함 -> 뒤에 이유 설명
    • EC2를 개발자가 직접 관리하지 않는 서버리스 컨테이너 실행 환경이기 때문에 ENI를 컨테이너에 직접 할당해야만 함
    • 즉, EC2는 ENI를 EC2 인스턴스에 붙이는데 Fargate는 컨테이너 실행 환경이니깐 awsvpc가 필수
  • ALB(Application Load Valancer)와 직접 통합 가능
    • 각 컨테이너가 VPC의 개별 IP를 갖기 때문에 ALB를 컨테이너에 직접 붙일 수 있음
    • 각 컨테이너별로 개별적으로 라우팅 가능
    • EC2는 컨테이너가 아닌 EC2 인스턴스에 ALB를 연결해야 함
컨테이너에 ALB를 통합하는 좋은 점

EC2 인스턴스가 아닌 컨테이너 단위로 ALB를 연결해야 하는 경우 이 방법이 필요

  • EC2에 여러 컨테이너를 띄운 상황
    • 만약 EC2 안에 있는 컨테이너의 개수가 증가하면 EC2 인스턴스를 개발자가 수동으로 스케일링해야 한다.
    • 즉, 컨테이너 개수만 변경하고 싶은데 EC2 인스턴스의 성능이나 용량이 부족하면 EC2 인스턴스를 더 좋은 성능의 인스턴스로 변경(수직 스케일링)하거나 인스턴스의 개수를 개발자가 직접 늘려야(수평 스케일링) 한다.
  • Fargate로 컨테이너를 띄운 상황
    • 각 컨테이너가 ENI를 갖기 때문에 ALB가 각 컨테이너에 직접 트래픽을 보낼 수 있다.
    • 즉, 컨테이너의 개수를 변경하고 싶을 때 서버를 건들 필요 없이 컨테이너 개수만 스케일링 할 수 있다.
  • 내가 진행하고 있는 프로젝트를 예로 들면 다음과 같다.
    • 우린 HUB라는 모듈에만 ALB를 연결해야 하는 상황인데 만약 EC2에 emulator, web, hub 컨테이너를 모두 띄우면 특정 컨테이너(HUB 모듈)에만 ALB를 연결할 수 없다.
    • 따라서 우리 프로젝트에서 Fargate를 사용하는 게 적합하다.
awsvpc를 사용해야 하는 경우
  • 각 컨테이너를 개별적으로 관리하고 싶은 경우
  • 보안 정책을 컨테이너별로 적용하고 싶을 경우
  • ALB or ELB를 연동하고 싶은 경우

ECS 서비스간(컨테이너) 간 통신 방법

Fargate에서 실행되는 각 컨테이너가 VPC의 서브넷에서 개별적인 pravate IP를 할당받아 서로 통신할 수 있고 다음 세 가지 방법으로도 통신 가능

1. Service Discovery(AWS Cloud Map)

Fargate는 컨테이너의 IP가 동적으로 변경될 수 있기 때문에, Cloud Map을 이용하여 서비스 디스커버리를 설정하여 컨테이너 간 통신이 가능하다.

 

즉, 컨테이너에 DNS(my-service.local 등) 이름을 할당하고, 이를 통해 컨테이너 간 통신

2. Application Load Balancer(ALB) - 일반적인 방식

ENI를 갖는 개별 컨테이너에 ALB를 이용하여 특정 task에 트래픽 분산 가능

ENI를 통한 직접 통신이 가능한데 굳이 ALB를 이용하는 이유?

컨테이너(Task)가 동적으로 생성/삭제되면 IP가 계속 바뀌기 때문에 자동 관리를 위해 사용

  • 컨테이너의 Pravate IP가 바뀔 때 ALB를 이용하여 자동 라우팅
    컨테이너(Task)가 스케일링 될 때마다 새로운 ENI가 동적으로 생성된다.
    따라서 Private IP가 계속 바뀌면 컨테이너 간 통신이 불가능하기 때문에 ALB를 사용하여 컨테이너가 스케일링(추가/삭제)될 때마다 자동으로 트래픽을 새로운 컨테이너(Task)로 라우팅하여 컨테이너 간 통신이 용이하도록 할 수 있도록 함
  • 내부 서비스 간 트래픽 균등 분배
    BE가 여러 개 실행중인 경우를 생각해보자.
    FE에서 BE로 요청을 보낼 때 특정 BE 컨테이너에만 트래픽이 몰리지 않도록 ALB를 이용하여 균등 분배할 수 있음

3. App Mesh

패스

ECS 서비스 간 통신 결론

tracky-hub 컨테이너가 오토 스케일링 될 예정이므로 ALB를 이용하여 서비스 간 통신이 가능하도록 해야 함

  1. tracky-hub에 ALB를 달아서 오토 스케일링이 가능하도록 구현
  2. tracky-emulator와 tracky-hub의 라우팅과 트래픽 균등 분배를 위해 ALB 사용

출처

https://countrymouse.tistory.com/entry/awsecs

'DevOps > AWS' 카테고리의 다른 글

VPC와 관련 기술들  (1) 2025.04.05
Fargate vs Lambda vs EC2  (0) 2025.03.23
EC2 인스턴스가 갑자기 터진다면?(Swap memory)  (1) 2024.09.18

티스토리툴바