개발 단계의 Docker는 단일 서버 실행이나 Compose 중심으로 충분하다. 그러나 실제 배포에서는 이미지 저장소(ECR), 실행 환경(EC2/ECS), 스토리지(EFS), 트래픽 처리(Load Balancer) 등 연동 구조를 고려해야 한다. 이 글은 최소 구성부터 관리형 배포까지 실무 기준으로 정리한다.
1. 배포 전략 전체 그림
Docker 기반 배포는 크게 두 가지 방식으로 나뉜다.
- EC2 수동 배포
- 가장 단순
- SSH 접속 → 이미지 pull → 컨테이너 실행
- 소규모 프로젝트·개인 서비스에서 적합
- ECS(Fargate/EC2) 관리형 배포
- 컨테이너 오케스트레이션
- 확장성·자동복구·롤링 업데이트 지원
- 트래픽 증가 대응 및 운영 표준화 가능
두 방식 모두 ECR 이미지 저장소를 중심으로 연결된다.
2. ECR: 이미지 저장소 구성
ECR은 AWS의 프라이빗 Docker Registry다.
배포의 모든 시작점은 “이미지를 업로드하는 것”이다.
생성 및 로그인
aws ecr create-repository --repository-name my-app
aws ecr get-login-password | docker login \
--username AWS \
--password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com이미지 태깅 및 push
docker build -t my-app .
docker tag my-app:latest <aws_id>.dkr.ecr.<region>.amazonaws.com/my-app:latest
docker push <aws_id>.dkr.ecr.<region>.amazonaws.com/my-app:latest배포는 이 이미지를 기준으로 이루어진다.
3. EC2 수동 배포: 가장 단순하지만 강력한 방식
1) EC2에 Docker 설치
Amazon Linux 기준:
sudo amazon-linux-extras install docker
sudo service docker start
sudo usermod -aG docker ec2-user2) EC2에서 ECR 로그인
aws ecr get-login-password | docker login --username AWS --password-stdin <repo_url>3) 컨테이너 실행
docker pull <repo_url>:latest
docker run -d -p 80:80 --name app my-app언제 적합한가
- 트래픽이 낮음
- 서버 1~2대 수준
- 배포 파이프라인을 직접 관리하고 싶음
현실적인 장점은 예측 가능성과 디버깅 용이성이다.
4. ECS 기반 배포 흐름
ECS는 컨테이너 실행을 “태스크(Task)” 단위로 관리한다.
핵심 구성 요소는 다음과 같다.
- Task Definition: 컨테이너 선언(Dockerfile 대응)
- Service: 태스크의 원하는 개수 유지
- Cluster: 실행 환경(Fargate 또는 EC2)
- Load Balancer 연동: 트래픽 분배
- Auto-healing: 장애 컨테이너 자동 복구
ECS 배포 기본 단계
- ECR에 이미지 push
- Task Definition 생성
- Service 생성
- ALB(Application Load Balancer) 연결
- 배포 후 자동 롤링 업데이트 진행
이 구조는 서버 수가 늘어날 때 압도적으로 효율적이다.
5. Fargate vs ECS on EC2
Fargate
- 서버 관리 없음
- 자동 확장·복구
- 비용은 더 높을 수 있으나 운영 편의성 최고
ECS on EC2
- 노드(EC2)를 직접 관리
- 비용 절감 가능
- 대규모 또는 커스텀 환경 필요할 때 적합
개인·스타트업 관점에서는 Fargate 선호, 비용이 문제가 되면 EC2로 전환.
6. Load Balancer 구성
React SPA 또는 Node API 배포 시 일반적으로 ALB + target group 구조를 사용한다.
핵심 흐름:
- ALB 80/443 수신
- Target Group에서 ECS 서비스 태스크로 라우팅
- 헬스체크 실패 → ECS 자동 교체
중요 포인트:
- 도커 포트(EXPOSE)와 ALB target port가 일치해야 함
- 태스크가 여러 개면 로드밸런서가 트래픽 균등 분배
7. EFS(Elastic File System) 연동
컨테이너는 Stateless가 원칙이다.
그러나 업로드 파일, 모델 파일, 공유 데이터가 필요할 수도 있다.
EFS 활용 포인트:
- 여러 ECS 태스크가 동일 디렉토리를 공유
- 영구 스토리지 제공
- EC2 기반에서도 동일하게 mount 가능
예:
volumes:
- name: shared
efsVolumeConfiguration:
fileSystemId: fs-xxxx노드 API에서 업로드 파일이 필요한 서비스에서 자주 사용된다.
8. Atlas 연동(MongoDB Cloud 기반)
로컬 MongoDB 컨테이너 대신 Atlas를 운영 DB로 사용하는 구조가 일반적이다.
이점:
- 백업·확장·모니터링 자동화
- VPC Peering 또는 IP Whitelist 기반 접근
- 컨테이너 재시작/교체에 영향 없음
API 컨테이너 환경변수 예:
MONGO_URL="mongodb+srv://user:pwd@cluster.mongodb.net/mydb"운영 환경에서는 로컬 DB 컨테이너를 사용하지 않으므로 안정성이 높다.
9. 운영 이미지 최적화: Multi-stage Build
운영 환경의 이미지는 작고 빠를수록 좋다.
Node.js 기준:
FROM node:18-alpine AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build
FROM node:18-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]장점:
- 이미지 크기 최소화
- 빌드 도구 미포함 → 보안 강화
- 빌드 캐시 활용
ECS·EC2 배포 모두에 적용된다.
10. 배포 파이프라인 관점 핵심 전략
- CI에서 이미지 빌드·테스트·태깅까지 수행
- CD에서 ECS 서비스 업데이트(trigger)
- 수동 배포는 EC2만 대상으로 유지
- 스테이트풀한 자원(EFS/DB)은 컨테이너 외부에 배치
- 모든 실행 환경은 이미지 하나로 정의
Docker 기반 운영의 본질은 환경 불일치 제거 + 자동화 기반 운영 최적화다.
요약 체크리스트
- ECR은 배포의 출발점
- EC2 수동 배포는 단순·예측 가능
- ECS는 확장성과 자동화 중심
- ALB로 트래픽 분배 및 헬스체크 수행
- EFS는 공유 스토리지용
- Atlas는 운영 DB로 안정적
- 운영 이미지는 Multi-stage build로 최적화
