Amazon ECS

컨테이너 이미지는 만들었는데 어느 서버에 몇 개를 띄울지, 죽은 컨테이너를 누가 다시 올릴지까지 직접 챙기면 배포 규칙이 금방 복잡해집니다. 서비스가 늘수록 애플리케이션 실행보다 컨테이너 운영 자체가 일이 됩니다.

컨테이너를 직접 운영하던 초기 방식은 서버마다 수동 배포 스크립트와 실행 규칙이 달라질수록 장애 복구와 확장이 어려워졌습니다. 그래서 컨테이너 정의, 원하는 개수 유지, 롤링 업데이트를 서비스 차원에서 관리하는 ECS 같은 계층이 필요해졌습니다.

ECS는 Cluster, Service, Task 세 계층으로 구성됩니다. Cluster는 컨테이너를 실행할 컴퓨팅 자원 풀입니다. EC2 인스턴스를 직접 묶거나 Fargate를 선택해 서버리스로 구성할 수 있습니다. Service는 태스크 정의를 바탕으로 원하는 태스크 수를 유지하는 역할을 합니다. 컨테이너가 비정상 종료되면 Service가 감지하고 새 태스크를 자동으로 시작합니다. Task는 실제 컨테이너가 실행되는 단위로, 어느 이미지를 얼마만큼의 CPU와 메모리로 실행할지를 태스크 정의에서 읽어옵니다. 이미지는 ECR(컨테이너 이미지 저장소)에서 가져오고, Service 앞단에 ALB를 붙이면 트래픽이 여러 태스크로 분산됩니다. 이 계층 구조 덕분에 배포 중에도 최소 실행 수가 유지되고 롤링 업데이트가 가능해집니다.

ECS와 EC2는 둘 다 앱을 실행하지만 관리 단위가 다릅니다. EC2는 서버가 중심이고, ECS는 컨테이너 태스크와 서비스가 중심입니다. 컨테이너 배포 표준화와 롤링 업데이트가 중요하면 ECS가 맞고, OS까지 세밀하게 만져야 하면 EC2가 더 직접적입니다.

마이크로서비스, 배치 워커, 컨테이너 기반 API처럼 같은 패턴으로 여러 서비스를 운영할 때 적합합니다. 컨테이너 없이 서버를 직접 다루거나 요청 단위 함수 실행만 필요한 경우에는 맞지 않습니다.