컨테이너 오케스트레이션이 뭘까
컨테이너 오케스트레이션은 다수의 컨테이너를 자동으로 배포, 관리, 스케일링(확장 및 축소)하는 것을 말한다. 컨테이너 몇 개 정도는 직접 하나씩 띄우고 내릴 수 있지만 컨테이너가 수십, 수백 개로 늘어나면 사람이 일일이 관리하기 어려워지는데 이걸 대신 자동으로 해주는 게 오케스트레이션 도구(컨트롤러)의 역할이다.
개발자 ──명령──▶ 컨트롤러(ECS/EKS) ──자동 배포·관리──▶ 컨테이너 1, 2, 3 ... NAWS ECS가 뭘까
ECS(Amazon Elastic Container Service)는 AWS의 관리형 컨테이너 오케스트레이션 서비스다. 인프라 관리 부담 없이 컨테이너화된 애플리케이션을 배포/관리/확장할 수 있고 IAM/CloudWatch/로드밸런서 같은 AWS 서비스들과 긴밀하게 통합돼 있다.
ECS는 런치 타입을 두 가지로 지원한다.
- EC2 런치 타입: 내가 직접 관리하는 EC2 인스턴스 위에서 컨테이너를 실행한다.
- Fargate 런치 타입: 서버리스 방식으로 AWS가 관리하는 자원 풀에서 컨테이너를 실행한다. 인스턴스를 직접 프로비저닝하거나 관리할 필요가 없다.
구성요소
- 클러스터(Cluster): ECS의 기본 논리적 단위로, 컨테이너를 실행할 수 있는 CPU나 메모리 같은 자원을 모아둔 집합이다.
- 작업 정의(Task Definition): 컨테이너 실행에 필요한 설정(이미지, CPU, 메모리, 포트 매핑, 환경 변수 등)을 담은 명세서다.
- 작업(Task): 작업 정의에 따라 실제로 실행되는 컨테이너 인스턴스다.
- 서비스(Service): 원하는 개수의 작업이 항상 실행되도록 보장하고, 배포/업데이트/자동 복구까지 관리한다.
이 구조를 보면서 EKS의 Pod/Deployment 개념과 자연스레 연관지어 Task Definition은 Pod 스펙, Task는 실제 실행 중인 Pod, Service는 Deployment와 각각 비슷한 역할을 한다고 이해했다. 결국 이름과 세부 구현은 다르지만 실행할 스펙을 정의하고 → 그 스펙대로 실제 컨테이너를 띄우고 → 원하는 개수를 계속 유지시켜주는 3단 구조 자체는 ECS든 EKS든 똑같았다.
IAM Role이 두 종류인 이유
ECS 작업에는 IAM 역할이 두 가지 필요하다.
- 작업 역할(Task Role): 컨테이너 안에서 실행되는 애플리케이션 코드가 다른 AWS 서비스(S3, DynamoDB 등)에 접근할 때 쓰는 권한이다.
- 작업 실행 역할(Task Execution Role): 작업을 실행하는 과정 자체에 필요한 권한이다. 예를 들어 ECR에서 컨테이너 이미지를 가져오거나 S3에서 환경 변수 파일을 읽어오는 데 쓰인다.
'컨테이너를 실행시키는 데 필요한 권한'과 '컨테이너 안의 애플리케이션이 실행 중에 필요한 권한'이 서로 다른 시점, 다른 주체의 권한이라서 분리된 것이라고 이해하기.
네트워크: awsvpc 모드 vs 브릿지 모드
ECS에서 작업을 실행할 때는 네트워크 모드를 선택해야 하는데 크게 두 가지로 나뉜다.
[awsvpc 모드]
Task 1 ──ENI 1(172.31.16.1)──▶ Container (독립된 IP, 독립된 보안 그룹)
Task 2 ──ENI 2(172.31.16.2)──▶ Container (독립된 IP, 독립된 보안 그룹)
[브릿지 모드]
┌─ Container (Port 3000)
EC2 ENI 1 ────┤ (단일 ENI를 여러 컨테이너가 공유, 보안 그룹은 인스턴스 단위)
└─ Container (Port 3000)awsvpc 모드는 각 작업(Task)마다 ENI를 따로 생성해서 독립된 프라이빗 IP를 할당하기 때문에 Task 단위로 보안 그룹을 따로 적용할 수 있고 IP 충돌 걱정도 없다. 반면 브릿지 모드는 하나의 EC2 ENI를 여러 컨테이너가 공유하는 방식이라 컨테이너별로 보안 그룹을 따로 줄 수 없고 호스트 포트를 매핑할 때도 포트 충돌을 신경 써야 한다.
ECS가 각 Task에 별도의 ENI를 붙여주는 awsvpc 모드를 보면서 이 방식은 Task 하나당 ENI 하나가 필요해서 인스턴스당 실행 가능한 Task 수가 ENI 개수 제한에 영향을 받을 수 있겠다는 생각도 들었다.
ECS 애플리케이션 라이프사이클
실제 배포 흐름은 이랬다.
ECR 이미지 준비 → Task Definition 작성(작업 정의) → ECS Task/Service로 배포 → 모니터링
(EC2 or Fargate 자원 위에서 실행)컨테이너 이미지를 ECR에 올려두고 그 이미지를 어떻게 실행할지 Task Definition으로 정의한 다음, 이를 실제 Task나 Service로 배포하고, 이후엔 CloudWatch 같은 서비스로 계속 모니터링하는 흐름이다.
📍 출처: 패스트캠퍼스 강의 - 실전 DevOps의 모든 것
