ECS는 도커 컨테이너를 쉽고 빠르게 실행, 중단 및 관리할 수 있게 해주는 관리형 서비스이다.

1. ECS의 핵심 구성 요소

ECS를 이해하려면 아래 세 가지 계층 구조를 반드시 알아야 한다.

1.1. 작업 정의 (Task Definition): 설계도

• 컨테이너 하나 이상의 설정을 담은 JSON 형식의 설계도이다
• 포함 내용: 사용할 도커 이미지 주소(ECR), CPU/메모리 할당량, 환경 변수(DB주소 등), 로그 설정(CloudWatch), 사용할 포트 등
• 백엔드 개발자가 가장 많이 설정하는 부분이다.

1.2. 작업 (Task): 실행 중인 컨테이너

• 작업 정의 설계도를 바탕으로 실제로 실행된 컨테이너 묶음이다.
• 클래스(작업 정의)를 인스턴스화한 객체(작업)라고 생각하면 이해하기 쉽다.

1.3. 서비스 (Service): 관리자

• 작업을 몇 개나 띄우맂 유지하고 관리한다.
• 핵심 기능
  • 상태 유지: 컨테이너가 죽으면 자동으로 새 컨테이너를 띄운다.
  • 로드 밸런서 연결: 새로 뜬 컨테이너들을 ALB에 자동으로 등록한다.
  • 배포 전략: 롤링 업데이트(새 버전으로 하나씩 교체) 등을 제어한다.

---

2. ECS 클러스터와 실행 모델 (Launch Type)

ECS 작업을 어디 위에서 실행할 것인지 결정해야 한다.

1. ECS + EC2 모델
   • 사용자가 직접 관리하는 EC2 서버들 위에 컨테이너를 올린다.
   • 서버 사양을 세세하게 제어할 수 있지만 EC2 OS 관리와 확장을 직접 해야 한다.
2. ECS + Fargate 모델
   • 서버 관리가 필요 없는 서버리스 방식이다
   • 백엔드 개발자는 서버 사양 대신 컨테이너 사양에만 집중하면 되므로 가장 많이 선호된다.

---

3. 백엔드 배포 아키텍처 흐름

실제 현업에서는 다음 흐름으로 ECS가 동작한다.

1. 이미지 빌드: 개발자가 코드를 짜고 Docker 이미지를 만든다
2. 이미지 저장: Amazon ECR(도커 허브의 AWS 버전)에 이미지를 푸쉬한다.
3. 작업 정의 업데이트: 새로운 이미지 태그(v2)로 ‘작업 정의’를 업데이트한다.
4. 서비스 업데이트: ECS 서비스가 새 ‘작업 정의’를 잠기하고 배포를 시작한다.
   • 새로운 컨테이너(Task)를 띄운다.
   • 새 컨테이너가 정상(Healthy)인지 확인한다.
   • 로드 밸런서가 트래픽을 새 컨테이너로 보낸다.
   • 이전 버전 컨테이너를 안전하게 종료한다.

---

4. 백엔드 개발자가 ECS를 쓰면 좋은 점

• 무중단 배포(Zero Downtime): 새로운 코드를 배로할 대 사용자는 끊김을 느끼지 못한다.
• 자동 배포(Self-healing): 애플리케이션에 런타임 에러가 발생해 컨테이너가 종료되면 ECS 서비스가 증시 새 컨테이너를 살려낸다.
• 로그 통합: awslogs드라이버를 통해 별도 설정 없이 애플리케이션 로그가 CloudWatch로 모인다.
• 보안 격리: 각 task마다 별도의 IAM 역할을 부여할 수 있어서 특정 API 서버만 특정 S3 버킷에 접근하게 하는 등의 세밀한 보안 제어가 가능하다.

---

5. 꼭 확인해야 할 것

• 상태 저장(Stateless)인가?: ECS 작업은 언제든지 삭제되고 다시 뜰 수 있다. 로컬 서버에 파일을 저장하거나 세션을 메모리에 저장하면 배포 시 사라진다.
• 헬스 체크(Health Check): ALB가 어떤 경로(/health 상태를 확인할지 엔드포인트를 만들어야 한다.
• 리소스 할당: 앱이 돌아가는 데 필요한 최소 CPU와 메모리를 테스트를 통해 적절히 설정해야 비용과 성능 모두를 잡을 수 있다.