🚢 컨테이너 오케스트레이션 AWS ECS란?
배포 경험
AWS에서 배포할 때 보통 조합으로 구성해서 배포를 해봤었다.
- EC2: 백엔드 서버 (NestJS, Express 등 실행)
- RDS: 데이터베이스 (MySQL, PostgreSQL)
- S3: 이미지, 파일 저장용
그리고 로컬에서 Docker는 한 번 연습해본 정도였는데,
AWS ECS 라는 걸 찾아보고
왜? 어떻게? 쓰는지?
컨테이너 ?
Docker를 사용하면, 우리가 만든 앱을 컨테이너라는 작은 단위로 포장해서 실행할 수 있게되는데
하지만 컨테이너를 단순히 실행하는 걸 넘어서,
서비스가 커지고 컨테이너가 많아질수록
누가 배포해주고, 죽으면 살리고, 확장도 해주는 자동화된 시스템이 필요하게 됨
이걸 해주는 게 바로 오케스트레이션, 그리고 AWS에서는 ECS이다.
ECS란?
ECS(Amazon Elastic Container Service)는
AWS에서 제공하는 Docker 컨테이너 전용 배포/관리 서비스
Docker로 만든 앱을 AWS에서 자동으로 배포하고, 실행하고, 확장하고, 복구까지 해주는 도구
EC2랑 뭐가 다른점?
| 비교 항목 | EC2 | ECS |
|---|---|---|
| 직접 서버 띄움 | ✅ 직접 띄움 | ❌ 필요 없음 (Fargate 사용 시) |
| 앱 실행 방식 | 코드 직접 실행 (Node, PM2 등) | Docker 이미지로 실행 |
| 확장/배포/복구 | 수동 관리 | 자동 관리 (스케일링, 롤링 업데이트 등) |
| 용도 | 가상 머신 | 컨테이너 오케스트레이션 도구 |
🔍 ECS가 하는 일
ECS는 단순히 컨테이너 실행기 이상
이런 것들을 자동으로 처리해줘요:
- 여러 개의 컨테이너 배포
- 죽은 컨테이너 자동 재시작
- 트래픽이 많아지면 컨테이너 수 늘림 (오토스케일링)
- 다운타임 없이 새로운 버전 배포 (롤링 업데이트)
- 로드 밸런싱 연동도 가능 (ALB)
ECS 실행 방식: EC2 vs Fargate
ECS에는 2가지 실행 방식이 있습니다:
| 방식 | 설명 |
|---|---|
| EC2 방식 | EC2 서버 위에 컨테이너를 올림 (서버 직접 관리 필요) |
| Fargate 방식 | 서버 없이 컨테이너만 실행 (완전 서버리스) ← 요즘 대세 |
구조 (Express 앱 기준)
고급 프로젝트에서 배포했던 Express 앱 기준:
project/
├── app.js
├── package.json
└── Dockerfile이 앱을 Docker 이미지로 만들고 ECS에 배포하면 다음과 같은 구조로 실행
ECS Cluster
└── Service (예: express-service)
└── Task (예: express-task)
└── Container (예: my-express-app:latest)각 구성 요소 설명
- Cluster: ECS 전체를 묶는 단위. 프로젝트별로 하나 생성
- Service: 컨테이너 수 유지, 오토스케일링, 로드밸런서 연결 등을 관리
- Task: 컨테이너가 실행되는 최소 단위 (보통 하나의 컨테이너 포함)
- Container: 실제 Express 앱이 실행되는 Docker 컨테이너
예시 상황
express-service가 3개의 Task를 유지하도록 구성했다고 가정하면:
[express-service]
├─ Task 1 → [my-express-app Container]
├─ Task 2 → [my-express-app Container]
└─ Task 3 → [my-express-app Container]📡 요청 흐름
[브라우저 요청]
↓
[로드 밸런서(ALB)]
↓
[ECS 서비스]
↓
[Express 컨테이너(app.js)]- 사용자가
/api요청을 보내면 - 로드 밸런서가 컨테이너 중 하나로 전달
- 해당 컨테이너 내부에서 Express가 요청을 처리
정리
- Express 앱을 Docker로 감싸고 ECS에 배포하면
- AWS가 컨테이너를 자동 실행, 복구, 확장까지 도와줌
- EC2처럼 직접 서버를 관리할 필요 없이
안정적이고 유연한 서비스를 운영 가능
