[AWS] ECS

1. 컨테이너 오케스트레이션(Container Orchestration)

• 컨테이너
  • 애플리케이션과 그 실행 환경(라이브러리, 의존성 등)을 패키징하여 어디서든 동일하게 실행할 수 있는 기술
  • 실제 운영 환경에서는 수십~수백 개의 컨테이너를 동시에 실행하고 관리
  • → 컨테이너 오케스트레이션 활용
• 하는 일(자동 수행):
  • 컨테이너 배치 (어떤 서버에 컨테이너를 올릴지)
  • 컨테이너 상태 모니터링 (죽으면 자동으로 재시작)
  • 확장/축소 (트래픽에 맞춰 개수를 늘리거나 줄임)
  • 네트워크 연결 및 로드밸런싱
• 예:
  • Kubernetes, Amazon ECS, Docker Swarm 등

2. Amazom ECS

• AWS가 제공하는 완전관리형 컨테이너 오케스트레이션 서비스
• Cluster → Task Definition → Task → Service의 흐름
  • Cluster: 컨테이너를 실행할 수 있는 "운영 단지"
  • Task Definition: 컨테이너를 어떻게 띄울지에 대한 "설계도"
  • Task: 설계도를 바탕으로 실제로 띄워진 "입주 세대(컨테이너 집합)"
  • Service: 세대 수 유지, 교체 공사(배포), 공동시설(ALB) 연결을 담당하는 "관리사무소"

  # 연결 관계 한눈에 보기 (간단 다이어그램)
  [Cluster]
    └─[Service]  ← 확장/축소, 배포, 로드밸런서 연결
        └─[Task] (실행 인스턴스, 1개 이상)
            └─[Containers] (여러 개 가능, web, sidecar, log 등)
  

ECS Cluster

• 컨테이너가 돌아가는 논리적 실행 환경
• 클러스터 안에서 작업(Service/Task) 배치
• 실행 유형:
  • EC2: 사용자가 등록한 EC2 인스턴스(컨테이너 인스턴스) 풀 + 용량 제공자(Capacity Provider)
  • Fargate: 서버리스 서비스, AWS가 컨테이너 실행 인프라 제공
• 네트워크/보안:
  • VPC, 서브넷, 보안그룹은 Task 실행 시점(특히 Fargate/awsvpc)에서 지정
• 운영 포인트:
  • 용량 제공자(Capacity Provider) 전략으로 서비스가 EC2 스팟/온디맨드를 어떤 비율로 쓸지 정할 수 있음
  • 클러스터 CloudWatch 지표(대기 용량, 실패율)를 보고 스케일 전략 조정

Task Definition

• 컨테이너 이미지, CPU/메모리, 포트, 환경 변수, 로그, 볼륨 등 실행 방법을 기술한 템플릿
• 헷갈리기 쉬운 핵심 키
  • taskRoleArn vs executionRoleArn
    • executionRole: 이미지를 끌어오고(Private ECR), 로그를 보내는 등 실행 준비에 필요한 권한
    • taskRole: 애플리케이션 컨테이너가 런타임에 AWS 리소스(S3, SQS 등)에 접근할 권한
  • networkMode
    • Fargate 필수: awsvpc (각 Task가 고유 ENI/프라이빗 IP 보유)
    • EC2: bridge/host/awsvpc 선택 가능
  • portMappings
    • awsvpc에서 보통 containerPort == hostPort로 동일 매핑
    • bridge에서는 hostPort: 0로 동적 할당 후 ALB 대상 등록이 흔함

Task

• Task Definition을 바탕으로 실제 실행 중인 인스턴스
• 하나 이상의 컨테이너를 포함함
• 상태 흐름:
  • PROVISIONING → PENDING → RUNNING → STOPPED
  • STOPPED가 되면 stoppedReason, 컨테이너 exitCode로 원인 파악
• 네트워킹(awsvpc):
  • 각 Task에 개별 ENI/IP가 붙습니다. 보안그룹/서브넷은 서비스나 RunTask 시에 지정
• 로깅/모니터링:
  • CloudWatch Logs에 컨테이너 stdout/stderr 수집, CloudWatch Metrics/Synthetics로 헬스 체크

Service

• ***원하는 개수(desiredCount)***의 Task를 지속적으로 유지하고, 배포/롤링 교체, 로드밸런서 연결, 오토스케일링을 담당
• task들을 관리하고 생성하는 역할
• 배포(Deployment)
  • 롤링 배포(default), maximumPercent/minimumHealthyPercent로 동시 교체 폭을 제어
  • 배포 회로 차단기(Deployment Circuit Breaker) 옵션을 켜면 헬스 실패 시 자동 롤백됨
• 로드밸런서(ALB/NLB) 연동
  • 대상 그룹(Target Group) 헬스 체크 경로(/health, /actuator/health)를 컨테이너 포트와 일치시켜야 함
• 오토스케일링
  • Target Tracking(예: CPU 50% 유지) 또는 Step Scaling 사용. 스케일 인 보호를 켜면 급격한 축소 방지
• 스케줄링 전략
  • REPLICA(기본): 원하는 수만큼 Task를 곳곳에 퍼뜨림
  • DAEMON(EC2 한정): 각 EC2 인스턴스마다 1개씩 Task 실행(로그 수집 데몬 등)

실무 팁

1. taskRole vs executionRole를 반드시 구분합니다. 런타임 AWS 접근 권한은 taskRole에 부여합니다.
2. Fargate는 awsvpc 고정입니다. 보안그룹/서브넷 설정이 *연결 장애의 80%*를 차지합니다.
3. ALB 대상 그룹의 헬스 체크 경로/포트와 컨테이너의 리스닝 포트를 정확히 일치시키세요.
4. 로그는 awslogs 드라이버로 그룹/보존기간을 명시해 운영비/탐지 시간을 줄입니다.
5. 배포 실패 시 서비스 이벤트 → Task stoppedReason → 애플리케이션 로그 순으로 보면 원인 추적이 빨라집니다.
6. 비용/확장 요구가 크면 Capacity Provider + 스팟(EC2) 조합, 운영 단순함이 중요하면 Fargate를 우선 고려합니다.

3. EC2 vs Fargate

• "직접 집을 지어 관리하는 것"(EC2)” vs "원룸을 임대해 바로 입주하는 것"(Fargate)

구분 EC2 Launch Type Fargate Launch Type

인프라 관리	직접 서버 관리 (패치, 모니터링, 스케일링)	AWS 완전 관리
비용	인스턴스 예약/스팟 활용시 저렴	vCPU/메모리 사용량 기준 과금 (상대적 비쌈)
제어권	높음 (OS/AMI/스토리지까지 설정 가능)	낮음 (Task 수준만 제어 가능)
확장성	Auto Scaling 정책 필요	자동 확장 내장
시작 속도	인스턴스 준비 필요 (수분 이상)	수십 초 이내 실행 가능
적합 사례	고정 트래픽, 비용 최적화 필요 서비스, GPU 작업	변동 트래픽, 실험/개발 환경, 관리 최소화

4. 정리

• 컨테이너 오케스트레이션은 많은 컨테이너를 효율적으로 관리하는 기술
• ECS는 AWS의 완전관리형 컨테이너 오케스트레이션 서비스
• 주요 구성 요소: Cluster, Task Definition, Task, Service
• 실행 방식: EC2 기반(세밀 제어, 직접 관리 필요) vs Fargate(서버리스, 관리 편의)
• 실무에서는 서비스 규모, 비용, 관리 역량에 따라 실행 방식 선택