ECS 완전 정복: 컨테이너 하나는 쉽다, 수백 개를 관리하는 건 다른 문제다

들어가며: 컨테이너가 100개가 되면 생기는 일

이전 글에서 Docker가 "내 컴퓨터에서는 되는데?" 문제를 해결했다고 설명했다. 컨테이너 하나를 만들고 실행하는 것은 docker run 한 줄이면 된다.

하지만 현실의 프로덕션 환경을 상상해 보자. 당신이 운영하는 서비스가 성장했다. 이제 다음이 필요하다:

• 웹 서버 컨테이너 20개
• API 서버 컨테이너 15개
• 백그라운드 워커 컨테이너 10개
• 스케줄러 컨테이너 3개
• 모니터링 컨테이너 5개

총 53개의 컨테이너가 여러 대의 서버(EC2 인스턴스)에 흩어져 돌아간다. 이제 이런 질문들이 쏟아진다:

1. 컨테이너를 어떤 서버에 배치할까? 메모리가 남는 서버? CPU가 남는 서버?
2. 컨테이너가 죽으면 어떻게 감지하고 자동으로 재시작할까?
3. 트래픽이 갑자기 3배로 늘면 웹 서버 컨테이너를 자동으로 늘릴 수 있을까?
4. 새 버전을 배포할 때 서비스 중단 없이 교체할 수 있을까?
5. 컨테이너 간 네트워크 통신은 어떻게 설정할까?
6. 로그와 메트릭을 중앙에서 모니터링할 수 있을까?

docker run을 53번 치는 것으로는 이 문제를 풀 수 없다. 이것이 바로 컨테이너 오케스트레이션(Container Orchestration) 이 필요한 이유이고, AWS가 이를 위해 만든 서비스가 ECS(Elastic Container Service)다.

1. 오케스트레이션이라는 개념은 어디서 왔는가

Google의 Borg: 모든 것의 시작

컨테이너 오케스트레이션의 역사는 Google 내부 시스템에서 시작한다.

2003~2004년, Google은 폭발적으로 성장하는 검색·메일·지도 서비스를 관리하기 위해 Borg라는 내부 클러스터 관리 시스템을 개발했다. Borg의 역할: 수만 대의 서버에서 수십만 개의 작업(컨테이너)을 자동으로 배치·관리·복구하는 것.

2015년, Google은 Borg의 설계와 10년간의 운영 경험을 "Large-scale cluster management at Google with Borg" (Verma 등, EuroSys 2015) 논문으로 공개했다. 이 논문은 컨테이너 오케스트레이션 분야의 사실상의 교과서가 됐다.

Borg 논문의 핵심 설계 원칙들:

• 선언적 배포: "이 작업을 3개 복제본으로 실행하라"고 선언하면, 어떤 서버에서 실행할지는 시스템이 결정
• 자동 복구: 작업이 실패하면 자동으로 다른 서버에서 재시작
• 리소스 효율성: bin-packing 알고리즘으로 서버 자원을 최대한 활용
• 격리: 서로 다른 작업이 같은 서버에서 실행되어도 간섭하지 않음

오케스트레이션 전쟁 (2014~2017)

Google이 Borg의 아이디어를 2014년 쿠버네티스(Kubernetes) 로 오픈소스화하면서, 컨테이너 오케스트레이션 시장에 전쟁이 시작됐다.

각 진영이 "컨테이너를 대규모로 어떻게 관리할 것인가"라는 같은 문제를 다른 철학으로 풀었다. 오픈소스 진영에서는 쿠버네티스가 승리했지만, AWS 생태계 안에서는 ECS가 독자적인 위치를 확립했다.

2. ECS란 무엇인가

정의

ECS(Elastic Container Service)는 AWS에서 Docker 컨테이너를 실행·관리하는 완전관리형 컨테이너 오케스트레이션 서비스다. 2014년 11월에 출시됐다.

핵심 가치: 컨테이너를 실행하는 인프라(EC2 클러스터)를 직접 관리하면서, 그 위에서 컨테이너의 배치·스케일링·복구를 자동화해 주는 것이다.

쉽게 말하면:

• Docker = 컨테이너를 만들고 실행하는 도구 (피자를 굽는 오븐)
• ECS = 여러 오븐에서 수백 개의 피자를 동시에 만들고, 주문에 맞게 조율하는 주방 관리 시스템

ECS의 핵심 개념 4가지

ECS를 이해하려면 4가지 핵심 개념을 알아야 한다. 처음엔 용어가 낯설지만, 각각의 역할은 명확하다.

하나씩 살펴보자.

1. 태스크 정의 (Task Definition) — 컨테이너의 설계도

태스크 정의는 **"어떤 컨테이너를 어떻게 실행할 것인가"**를 정의하는 JSON 문서다. Docker의 docker run 명령에 들어가는 모든 옵션을 구조화한 것이다.

{
  "family": "my-web-app",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "my-app:1.0",
      "cpu": 512,
      "memory": 1024,
      "portMappings": [
        { "containerPort": 3000, "protocol": "tcp" }
      ],
      "environment": [
        { "name": "NODE_ENV", "value": "production" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-web-app",
          "awslogs-region": "ap-northeast-2"
        }
      }
    }
  ],
  "cpu": "512",
  "memory": "1024",
  "networkMode": "awsvpc"
}

태스크 정의는 버전 관리된다. my-web-app:1, my-web-app:2처럼 리비전이 자동으로 증가한다. 문제가 생기면 이전 리비전으로 즉시 롤백할 수 있다.

2. 태스크 (Task) — 실행 중인 컨테이너

태스크는 태스크 정의를 기반으로 실제 실행 중인 컨테이너 인스턴스다. Docker에서 "이미지 : 컨테이너" 관계가 ECS에서는 "태스크 정의 : 태스크" 관계다.

하나의 태스크에는 여러 컨테이너가 포함될 수 있다. 예를 들어 웹 앱 컨테이너 + 사이드카 로그 수집기 컨테이너를 하나의 태스크로 묶어 항상 같이 실행되게 할 수 있다.

3. 서비스 (Service) — 태스크의 관리자

서비스는 **"태스크를 원하는 개수만큼 항상 유지하라"**는 선언이다.

"웹 서버를 5개 실행하라"고 서비스를 정의하면:

• ECS가 5개의 태스크를 시작한다
• 태스크 하나가 죽으면 자동으로 새 태스크를 시작해 5개를 유지한다
• 로드밸런서와 연결하면 트래픽이 5개 태스크에 균등 분배된다
• 오토스케일링 정책을 붙이면 트래픽에 따라 5개 → 20개로 자동 확장된다

이것이 Borg 논문의 "선언적 배포" 개념이다. "어떻게 실행할지"가 아니라 "무엇을 원하는지"를 선언하면, 시스템이 현재 상태를 원하는 상태로 맞춰간다.

4. 클러스터 (Cluster) — 컨테이너가 실행되는 공간

클러스터는 태스크가 실행되는 논리적 그룹이다. 하나의 클러스터에는 여러 EC2 인스턴스가 속하고, ECS는 클러스터 안의 인스턴스들에 태스크를 자동 배치한다.

3. ECS는 구체적으로 어떤 문제를 해결하는가

문제 1: 배치 — "이 컨테이너를 어디에 놓을까?"

EC2 인스턴스가 10대 있다. 새 컨테이너(CPU 2코어, 메모리 4GB 필요)를 실행해야 한다. 어떤 인스턴스에 놓을까?

수동으로 하면:

• 각 인스턴스의 남은 CPU/메모리를 확인
• 적절한 인스턴스를 선택
• 이미 너무 많은 컨테이너가 있으면 다른 인스턴스 선택
• 장애 분산을 위해 같은 서비스의 컨테이너를 다른 AZ에 배치

ECS의 스케줄러(Scheduler) 가 이 모든 것을 자동으로 한다. bin-packing 전략(남는 공간을 최소화하는 방식으로 배치)이나 spread 전략(가능한 한 분산 배치) 중 선택할 수 있다.

문제 2: 자동 복구 — "컨테이너가 죽었다"

컨테이너는 프로세스다. 프로세스는 죽을 수 있다. 메모리 누수, 예외 처리되지 않은 에러, 의존 서비스 장애 — 원인은 다양하다.

Docker만으로는 컨테이너가 죽었는지 알 수 있지만, 자동으로 재시작하고 원하는 개수를 유지하는 것은 별도의 관리 체계가 필요하다.

ECS 서비스는 desired count(원하는 태스크 수) 를 항상 유지한다. 태스크가 죽으면 수 초 내에 새 태스크를 시작한다. 헬스체크를 통해 애플리케이션 수준의 장애(프로세스는 살아있지만 응답하지 않는 경우)도 감지한다.

문제 3: 배포 — "서비스 중단 없이 새 버전을 올리고 싶다"

가장 흔한 배포 시나리오: 웹 앱 v1.0을 v1.1로 업그레이드해야 한다. 5개의 컨테이너가 돌고 있다. 전부 동시에 교체하면 순간적으로 서비스가 중단된다.

ECS는 롤링 업데이트(Rolling Update) 를 기본 지원한다:

minimumHealthyPercent와 maximumPercent 파라미터로 배포 속도를 제어할 수 있다. 예를 들어 minimumHealthyPercent: 50, maximumPercent: 200이면 기존 태스크의 절반까지 줄이면서 동시에 새 태스크를 추가로 실행할 수 있어 배포가 빨라진다.

문제 4: 스케일링 — "트래픽이 갑자기 3배로 늘었다"

ECS 서비스에 Application Auto Scaling을 붙이면, 지정한 메트릭에 따라 태스크 수를 자동으로 조절한다:

• CPU 사용률 기반: "평균 CPU 70% 넘으면 태스크 추가, 30% 미만이면 축소"
• 메모리 사용률 기반: 메모리 임계값 초과 시 확장
• 요청 수 기반: ALB의 요청 수가 태스크당 1,000건 넘으면 확장
• 스케줄 기반: "월~금 오전 9시에 10개, 주말에는 3개"

문제 5: 네트워크 — "컨테이너끼리 어떻게 통신하지?"

ECS는 awsvpc 네트워크 모드를 사용하면 각 태스크에 독립된 ENI(Elastic Network Interface)와 프라이빗 IP를 부여한다. 각 컨테이너가 VPC 안에서 자체 IP를 갖는 것이다.

서비스 간 통신에는 여러 방법이 있다:

• ALB (Application Load Balancer): 외부 트래픽을 서비스의 태스크들에 분배
• Service Connect: ECS 네이티브 서비스 메시. 서비스 이름으로 직접 통신 (예: http://api-service:8080)
• Cloud Map: DNS 기반 서비스 디스커버리. 서비스 이름을 IP로 자동 해석

4. ECS 아키텍처 — 실전 구성

전형적인 웹 서비스 아키텍처

실제 프로덕션에서 가장 흔한 ECS 아키텍처를 살펴보자:

이 아키텍처에서 ECS가 담당하는 것:

• 웹/API/워커 서비스의 태스크 배치와 유지
• 태스크 장애 시 자동 복구
• ALB와 연동한 트래픽 분배
• 오토스케일링 정책에 따른 자동 확장/축소
• 새 버전 배포 시 롤링 업데이트

ECS가 담당하지 않는 것:

• 데이터베이스, 캐시, 메시지 큐 (이들은 별도의 AWS 관리형 서비스)
• SSL 인증서 관리 (ACM이 담당)
• DNS (Route 53이 담당)

ECR — 컨테이너 이미지 저장소

Docker Hub의 AWS 버전이 ECR(Elastic Container Registry)다. ECS와 함께 거의 항상 사용된다.

CI/CD 파이프라인의 전형적인 흐름:

1. 개발자가 코드를 GitHub에 Push
2. CI(CodePipeline/GitHub Actions)가 Docker 이미지를 빌드
3. 이미지를 ECR에 Push
4. ECS 서비스가 ECR에서 새 이미지를 Pull하여 배포

ECR의 이점:

• AWS IAM과 통합된 접근 제어
• 이미지 취약점 자동 스캔
• 리전 내 전송 비용 없음 (ECS ↔ ECR 같은 리전이면 무료)
• 이미지 라이프사이클 정책 (오래된 이미지 자동 삭제)

5. ECS vs 쿠버네티스: 어떤 것을 선택할 것인가

이것은 ECS 도입을 고려하는 모든 팀이 묻는 질문이다.

어떤 상황에 무엇이 맞는가

ECS를 선택해야 하는 경우:

• AWS 올인 전략인 팀
• 인프라 엔지니어가 적거나 없는 팀 (ECS가 더 간단)
• 빠르게 컨테이너 오케스트레이션을 도입하고 싶은 경우
• 추가 관리 비용을 최소화하고 싶은 경우

EKS(쿠버네티스)를 선택해야 하는 경우:

• 멀티클라우드 또는 하이브리드 전략
• 쿠버네티스 생태계의 특정 도구가 필요한 경우 (Istio, Argo CD 등)
• 팀에 쿠버네티스 경험자가 있는 경우
• 향후 클라우드 이전 가능성을 열어두고 싶은 경우

6. 실제 사례: ECS를 쓰는 기업들

Duolingo — 매일 수백만 학습 세션

언어 학습 앱 Duolingo는 ECS를 핵심 인프라로 사용한다. 매일 수백만 명의 동시 사용자가 실시간으로 학습 세션을 진행하며, 사용자 트래픽은 시간대별로 크게 변동한다.

ECS의 오토스케일링으로 아침 출근 시간과 저녁 시간에 자동 확장, 새벽에는 자동 축소하여 비용을 최적화한다.

Samsung SmartThings — IoT 플랫폼

삼성의 IoT 플랫폼 SmartThings는 수억 대의 기기에서 발생하는 이벤트를 처리한다. 마이크로서비스 아키텍처를 ECS에서 운영하며, 이벤트 폭증 시 자동 스케일링으로 대응한다.

Turner Broadcasting (CNN)

CNN을 운영하는 Turner Broadcasting은 2017년 ECS로 마이그레이션하며 인프라 비용을 50% 절감하고, 배포 시간을 일 단위에서 분 단위로 단축했다.

스타트업에서의 ECS

10~50명 규모의 스타트업에서 ECS가 인기 있는 이유:

별도의 인프라팀 없이 개발자가 직접 컨테이너 오케스트레이션을 운영할 수 있다는 것이 ECS의 가장 큰 매력이다.

7. ECS 실전 구성: 단계별 가이드

실제로 ECS에서 서비스를 시작하는 과정을 단계별로 살펴보자.

단계 1: Docker 이미지 준비

이전 글에서 설명한 대로 Dockerfile을 작성하고 이미지를 빌드한다.

docker build -t my-api:1.0 .

단계 2: ECR에 이미지 Push

# ECR 레포지토리 생성
aws ecr create-repository --repository-name my-api

# 로그인
aws ecr get-login-password | docker login --username AWS \
  --password-stdin 123456789.dkr.ecr.ap-northeast-2.amazonaws.com

# 태그 & 푸시
docker tag my-api:1.0 123456789.dkr.ecr.ap-northeast-2.amazonaws.com/my-api:1.0
docker push 123456789.dkr.ecr.ap-northeast-2.amazonaws.com/my-api:1.0

단계 3: 클러스터 생성

AWS 콘솔 또는 CLI로 ECS 클러스터를 생성한다. EC2 런치 타입을 선택하면 ECS가 EC2 인스턴스를 프로비저닝한다.

단계 4: 태스크 정의 등록

이미지 URI, CPU/메모리 할당, 포트 매핑, 환경변수, 로그 설정을 정의한다.

단계 5: 서비스 생성

태스크 정의를 기반으로 서비스를 생성한다. 원하는 태스크 수, 배포 전략, 로드밸런서를 설정한다.

aws ecs create-service \
  --cluster my-cluster \
  --service-name my-api-service \
  --task-definition my-api:1 \
  --desired-count 3 \
  --launch-type EC2 \
  --load-balancers targetGroupArn=arn:aws:...,containerName=web,containerPort=3000

단계 6: 오토스케일링 설정

# 스케일링 타겟 등록
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-api-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20

# CPU 70% 타겟 트래킹 정책
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-api-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  }'

이 설정이 완료되면, ECS가 CPU 사용률 70%를 유지하도록 태스크 수를 2~20개 범위에서 자동 조절한다.

8. 운영 모범 사례

로깅과 모니터링

ECS 태스크의 로그는 CloudWatch Logs로 자동 전송할 수 있다. 태스크 정의에서 awslogs 로그 드라이버를 설정하면 된다.

핵심 모니터링 메트릭:

비용 최적화

EC2 런치 타입에서의 비용 최적화 전략:

• EC2 스팟 인스턴스 활용: ECS 클러스터에 스팟 인스턴스를 혼합하면 최대 70% 비용 절감. 중단에 대비해 다중 인스턴스 타입·AZ를 설정
• 적절한 태스크 사이즈: CPU/메모리를 과도하게 할당하면 인스턴스에 태스크가 적게 배치됨. 실제 사용량을 측정하고 맞춰 조정
• Cluster Auto Scaling: 태스크가 늘어나면 EC2 인스턴스도 자동으로 늘리고, 줄어들면 인스턴스를 종료

보안 모범 사례

• 태스크별 IAM 역할: 각 서비스에 필요한 최소 권한만 부여. API 서버는 S3 읽기만, 워커는 SQS 읽기만
• 비밀 정보 관리: 환경변수에 비밀번호를 직접 넣지 말고, AWS Secrets Manager나 SSM Parameter Store를 참조
• 프라이빗 서브넷: 태스크를 퍼블릭 서브넷이 아닌 프라이빗 서브넷에 배치. 외부 접근은 ALB를 통해서만
• ECR 이미지 스캔: 배포 전 이미지 취약점 자동 검사 활성화

마치며: 오케스트레이션은 "운영의 자동화"다

컨테이너 오케스트레이션의 본질은 이렇다:

"나는 이 서비스가 항상 N개 실행되고, 장애 시 자동 복구되고, 트래픽에 따라 확장되고, 무중단으로 배포되기를 원한다."

이 선언을 하면, ECS가 현실을 그 선언에 맞춰간다. 컨테이너 하나를 실행하는 것은 Docker로 충분하다. 하지만 수십~수백 개의 컨테이너를 안정적으로 운영하려면 오케스트레이션이 필요하고, AWS 생태계에서 가장 간단한 선택이 ECS다.

정리하면:

• Docker → 컨테이너를 만들고 실행한다
• ECR → 컨테이너 이미지를 저장하고 관리한다
• ECS → 컨테이너의 배치·스케일링·복구·배포를 자동화한다
• ALB → 트래픽을 컨테이너들에 분배한다
• Auto Scaling → 부하에 따라 컨테이너 수를 자동 조절한다

다음 글에서는 EC2 인스턴스 관리마저 필요 없는 서버리스 컨테이너, AWS Fargate를 다뤄보겠다. ECS의 모든 장점을 유지하면서, 서버 관리라는 마지막 부담까지 없애는 방법이다.