🐳 컨테이너 오케스트레이션

왜 컨테이너 오케스트레이션을 배워야 할까?

여러분이 작은 온라인 쇼핑몰을 운영한다고 상상해보세요. 처음에는 EC2 인스턴스 1대에 Node.js 서버를 직접 설치하여 서비스했습니다. 고객이 늘어나자 서버를 2대로 늘렸습니다. 그런데 문제가 생깁니다.

서버마다 Node.js 버전이 다릅니다. 서버 1에는 18.17이, 서버 2에는 18.19가 설치되어 있습니다. OS 패치도 따로 관리해야 합니다. 새 개발자가 입사하면 로컬 환경 세팅에 하루가 걸립니다. "내 컴퓨터에서는 되는데"가 매주 반복됩니다.

Docker 컨테이너는 이 문제를 해결합니다. 애플리케이션과 실행 환경(OS, 라이브러리, 의존성)을 하나의 이미지로 패키징합니다. 이 이미지는 어떤 서버에서든 동일하게 실행됩니다. 개발 노트북, 테스트 서버, 프로덕션 서버 — 모든 곳에서 같은 동작을 보장합니다.

하지만 Docker만으로는 부족합니다. 컨테이너가 10개, 100개로 늘어나면 누가 관리할까요? 컨테이너가 죽으면 누가 다시 살릴까요? 트래픽이 몰리면 누가 컨테이너를 추가로 띄울까요?

이것이 오케스트레이션입니다. 오케스트라에서 지휘자가 수십 명의 연주자를 조율하듯, ECS(Elastic Container Service)가 수십 개의 컨테이너를 관리합니다.

이 실습에서는 다음을 직접 구축합니다:

• Docker 이미지를 빌드하고 ECR(Elastic Container Registry)에 푸시
• ECS Fargate 클러스터에 컨테이너를 배포하여 서버 관리 없이 실행
• ALB를 연동하여 여러 컨테이너에 트래픽을 자동 분산
• 오토 스케일링으로 트래픽 증가에 자동 대응
• CloudWatch Logs로 컨테이너 로그를 중앙 집중 모니터링

아키텍처 개요

컨테이너 배포 흐름

비용 예측

Step 1: Dockerfile 작성

Dockerfile은 컨테이너 이미지의 "레시피"입니다. 어떤 기반 이미지를 사용하고, 어떤 파일을 복사하고, 어떤 명령을 실행할지를 순서대로 정의합니다. 좋은 Dockerfile을 작성하면 이미지 크기가 줄어들고, 빌드 속도가 빨라지고, 보안이 향상됩니다.

node:18-alpine을 기반 이미지로 사용하는 이유는 일반 node:18 이미지(약 900MB)에 비해 Alpine 기반 이미지(약 120MB)가 훨씬 작기 때문입니다. 이미지가 작을수록 ECR에서 Pull하는 시간이 줄어들고, 컨테이너 시작 속도가 빨라집니다.

COPY package*.json ./을 COPY . .보다 먼저 실행하는 것은 Docker의 레이어 캐싱을 활용하기 위해서입니다. 소스 코드가 변경되어도 package.json이 변경되지 않았다면 npm ci 단계를 캐시에서 재사용할 수 있습니다.

# Dockerfile 생성
cat <<'DOCKERFILE' > Dockerfile
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
DOCKERFILE
 
docker build -t lab-app .
docker run -p 3000:3000 lab-app

Step 2: ECR 리포지토리 생성 및 이미지 푸시

ECR(Elastic Container Registry)은 Docker Hub와 유사한 AWS의 컨테이너 이미지 저장소입니다. 프라이빗 저장소이므로 IAM 인증이 필요하고, 이미지가 AWS 네트워크 내에 저장되므로 ECS에서 Pull하는 속도가 매우 빠릅니다.

ECR에 Push하기 전에 aws ecr get-login-password로 인증 토큰을 받아야 합니다. 이 토큰은 12시간 동안 유효합니다. CI/CD 파이프라인에서는 매 빌드마다 새로 인증하도록 설정하세요.

aws ecr create-repository --repository-name lab-app --region ap-northeast-2
 
aws ecr get-login-password --region ap-northeast-2 | \
  docker login --username AWS --password-stdin <ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com
 
docker tag lab-app:latest <ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/lab-app:latest
docker push <ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/lab-app:latest

ECS vs EKS 비교

컨테이너 오케스트레이션 서비스를 선택할 때 가장 많이 받는 질문은 "ECS를 쓸까, EKS를 쓸까?"입니다. 두 서비스의 핵심 차이를 이해하면 올바른 선택을 할 수 있습니다.

• ECS (Elastic Container Service): AWS 네이티브 오케스트레이터. AWS 콘솔에서 직접 관리. Fargate와의 통합이 매끄럽고, 학습 곡선이 낮습니다. 소규모~중규모 워크로드에 적합합니다.
• EKS (Elastic Kubernetes Service): Kubernetes 기반 오케스트레이터. 표준 Kubernetes API를 사용하므로 멀티 클라우드 이식성이 높습니다. 학습 곡선이 가파르지만, 복잡한 마이크로서비스 아키텍처에 적합합니다.

이 실습에서는 ECS Fargate를 사용합니다. AWS 환경에서 컨테이너를 시작하는 가장 빠르고 간단한 경로이며, Kubernetes 지식 없이도 컨테이너 오케스트레이션의 핵심 개념(서비스 디스커버리, 오토 스케일링, 헬스 체크)을 학습할 수 있습니다.

Step 3: ECS 클러스터 생성

ECS 클러스터는 컨테이너를 실행하는 논리적 그룹입니다. Fargate를 선택하면 EC2 인스턴스를 직접 관리할 필요가 없습니다. AWS가 컨테이너를 실행할 서버를 자동으로 할당하고, 사용한 만큼만 비용을 청구합니다.

Fargate의 가장 큰 장점은 서버 관리의 완전한 제거입니다. OS 패치, 보안 업데이트, 용량 계획 모두 AWS가 담당합니다. 개발자는 "어떤 서버에서 실행할지"가 아니라 "얼마나 많은 CPU/메모리가 필요한지"만 결정하면 됩니다.

EC2 시작 유형과 Fargate 시작 유형의 비용 분기점도 알아두면 좋습니다. 24시간 상시 실행되는 워크로드에서는 EC2 + Reserved Instance가 Fargate보다 저렴할 수 있습니다. 하지만 트래픽이 불규칙하거나 운영 인력이 부족한 환경에서는 Fargate의 서버리스 특성이 총 비용(TCO) 관점에서 더 유리합니다.

Step 4: Task Definition 작성

Task Definition은 컨테이너를 어떻게 실행할지 정의하는 "설계도"입니다. Docker 이미지 위치, CPU/메모리 할당량, 포트 매핑, 환경 변수, 로그 설정 등을 포함합니다.

CPU와 메모리 조합에는 제한이 있습니다. 예를 들어 0.25 vCPU를 선택하면 메모리는 0.5GB, 1GB, 2GB 중에서만 선택 가능합니다. 실습에서는 최소 사양인 0.25 vCPU / 0.5 GB로 시작하여 비용을 절약합니다.

awslogs 로그 드라이버를 설정하면 컨테이너의 stdout/stderr가 자동으로 CloudWatch Logs에 전송됩니다. SSH 접속 없이도 로그를 확인할 수 있으므로, Fargate 환경에서는 반드시 설정해야 합니다.

Step 5: 서비스 생성 (ALB 연동)

ECS 서비스는 "항상 N개의 태스크가 실행되고 있도록 보장"하는 역할을 합니다. 태스크가 비정상 종료되면 자동으로 새 태스크를 시작합니다. ALB와 연동하면 여러 태스크에 트래픽을 자동으로 분산하고, 비정상 태스크로의 라우팅을 차단합니다.

원하는 태스크 수를 2 이상으로 설정하는 것이 중요합니다. 태스크가 1개뿐이면 해당 태스크가 종료되는 순간(업데이트, 장애 등) 서비스가 중단됩니다. 2개 이상이면 항상 최소 1개는 트래픽을 처리할 수 있습니다.

Step 6: 오토 스케일링 설정

오토 스케일링은 트래픽 변화에 따라 태스크 수를 자동으로 조절합니다. 쇼핑몰 세일 기간에 트래픽이 5배로 늘어나면 태스크도 자동으로 늘어나고, 세일이 끝나면 줄어듭니다. 수동으로 서버를 늘리고 줄이는 것에 비해 비용 효율과 대응 속도가 크게 향상됩니다.

대상 추적 정책(Target Tracking Policy)은 가장 직관적인 스케일링 방식입니다. "CPU 사용률을 70%로 유지하라"고 설정하면, 사용률이 70%를 넘으면 태스크를 추가하고, 70% 미만이면 태스크를 줄입니다. 쿨다운(60초)은 스케일링 후 다음 스케일링까지 대기하는 시간으로, 불필요한 진동을 방지합니다.

Step 7: CloudWatch 로그 확인

Fargate 환경에서는 컨테이너에 직접 SSH로 접속할 수 없습니다. 따라서 CloudWatch Logs가 유일한 로그 확인 경로입니다. 로그 인사이트(Log Insights) 기능을 사용하면 SQL과 유사한 쿼리로 대량의 로그를 빠르게 분석할 수 있습니다.

트러블슈팅 가이드

핵심 개념 확인

완성 후 테스트 가이드

실무에서 자주 묻는 질문

Q: Fargate 태스크의 CPU/메모리를 어떻게 결정하나요?

처음에는 최소 사양(0.25 vCPU / 0.5 GB)으로 시작하고, CloudWatch 메트릭에서 CPU/메모리 사용률을 모니터링합니다. 사용률이 지속적으로 80%를 넘으면 한 단계 올리고, 20% 미만이면 한 단계 내립니다. Fargate는 정해진 조합만 지원하므로 AWS 문서에서 유효한 조합을 확인하세요.

Q: 컨테이너 이미지를 업데이트할 때 다운타임이 발생하나요?

ECS 서비스의 롤링 업데이트 설정에 따라 다릅니다. 기본 설정에서는 새 태스크가 먼저 시작되고 헬스 체크를 통과한 후, 이전 태스크가 종료됩니다. minimumHealthyPercent=100으로 설정하면 항상 기존 태스크가 유지된 상태에서 새 태스크가 추가되므로 다운타임이 발생하지 않습니다.

Q: 프라이빗 서브넷에서 ECR 이미지를 Pull하려면 어떻게 하나요?

두 가지 방법이 있습니다. (1) NAT Gateway: 프라이빗 서브넷에서 NAT Gateway를 통해 인터넷에 접근. 간단하지만 NAT Gateway 비용(월 $32+)이 발생합니다. (2) VPC 엔드포인트: ECR, S3, CloudWatch Logs에 대한 VPC 엔드포인트를 생성. 인터넷 접근 없이 AWS 네트워크 내에서 통신하므로 보안성이 높고, 데이터 전송 비용이 절감됩니다.

확장 아이디어

1. 멀티 컨테이너 태스크: 하나의 Task Definition에 웹 서버(nginx)와 앱 서버(node)를 함께 배치하는 사이드카 패턴을 구현합니다.
2. 서비스 디스커버리: AWS Cloud Map을 연동하여 마이크로서비스 간 DNS 기반 통신을 구현합니다.
3. ECS + CI/CD 연동: CodePipeline에서 ECR 이미지를 빌드하고, ECS 서비스를 자동 업데이트하는 파이프라인을 구축합니다.
4. EKS 비교 실습: 동일한 애플리케이션을 EKS(Kubernetes)에 배포하고, ECS Fargate와 관리 복잡성/비용을 비교합니다.
5. Fargate Spot 활용: 내결함성이 있는 배치 처리 태스크에 Fargate Spot을 사용하여 비용을 최대 70% 절감합니다.

Fargate CPU/메모리 조합 참고

Fargate는 아래의 유효한 CPU/메모리 조합만 지원합니다. 잘못된 조합으로 Task Definition을 생성하면 오류가 발생합니다.

학습 정리

리소스 정리