이번에 소개할 컨테이너 오케스트레이션 툴인 ECS는 소규모, 대규모 고객 모두 사용하기 편리하고, 인프라 관리에 대한 부담이 적어서 Container만 사용하고 싶은 고객에게 권장되는 서비스입니다.
ECR (Elastic Container Registry)
ECR은 컨테이너를 위한 프라이빗 도커 레포지토리이며, ECR를 사용하면 AWS 컨테이너 서비스와 호환성 측면에서 이점이 있다. 클러스터를 ECR과 쉽게 연결할 수 있으며, 새로운 버전의 이미지가 올라오면 자동으로 클러스터에 넘어가게끔 설정할 수도 있는 등 다양한 기능을 누릴 수 있다.
ECR 서비스는 꽤나 단순하고 직관적이다. 프라이빗 레포지토리를 생성하고, 애플리케이션 이미지, 다양한 이미지 및 버전을 레포지토리에 등록할 수 있고, 레포지토리 엔드포인트로 클러스터에서 이미지를 다운로드할 수 있다.
ECS (Elastic Container Servie) 란
AWS의 컨테이너 오케스트레이션 서비스 ECS는 내부적으로 Cluster, Task, Sevice 이렇게 세 가지 메인으로 구성되어 있는데, 간단히 설명하자면 다음과 같다.
- Cluster : 여러 컨테이너의 하드웨어 리소스를 논리적으로 그룹화한 녀석이며, 컨테이너 라이프사이클을 관리한다.
- Service : Auto-Scaling, LB 등 컨테이너를 어떻게 배포, 실행, 관리할지 Task보다 advanced 한 설정 내용을 품고 있는 녀석
- Task : VM에 어떻게 컨테이너를 배포할지 내용을 품고 있는 템플릿 메타데이터 (mem, cpu, env etc… 어떻게 배포할지)
* 스케줄링 : k8s 방식으로 설명하자면, 새로 생성된 파드 중 노드가 할당되지 않은 녀석을 스케줄러가 탐지해, 해당 파드를 가동할 최적의 노드를 찾는다. 최적의 노드는 파드 배치가 가능한 노드에 일련의 Function을 돌려 스케줄러가 점수를 매기고, 가장 높은 점수의 노드를 채택한다.
용어 설명
클러스터 (Cluster) 클러스터는 작업 또는 서비스의 논리적 그룹이며, 뒤에서 생성할 작업 및 서비스는 클러스터에 등록된 인프라에서 실행됩니다
네트워킹 전용 / EC2 Linux + 네트워킹 / EC2 Windows + 네트워킹 3가지 템플릿을 제공합니다. 일반적으로 프로젝트 또는 컨테이너 종류에 따라 클러스터를 구분하여 사용합니다.
작업 정의 (Task definitions)
작업의 일부가 될 컨테이너의 개수, 컨테이너가 사용할 리소스, 컨테이너 간 연결 방식, 컨테이너가 사용할 호스트 포트와 같은 애플리케이션 관련 컨테이너 정보를 지정합니다.
서비스 (Service)
어떤 이유로 작업(Task)이 실패 또는 중지되는 경우 서비스 스케줄러가 다른 인스턴스를 시작하며, 문제가 발생한 작업을 대체하여 원하는 작업(Task) 수를 유지합니다.
작업(Task)를 지속적으로 관리하는 단위이며, 라이프 사이클을 관리한다고 보시면 됩니다. 추가적으로 배포 옵션, 작업 배치 및 Auto scaling, Load Balancing와 같이 작업(Task)과 관련된 설정을 관리합니다.
작업 (Task)
작업 정의(Task definitions)에 설정한대로 생성한 Container의 그룹을 작업(Task) 이라고 합니다. 작업(Task)에는 1개 이상의 Container가 포함됩니다.
번역의 한계로 페이지 마다 작업 or 태스크 or Task로 다르게 표기되므로 혼동되지 않게 유의합니다.
EC2 방식과 Fargate 방식의 비용 차이
비용적인 측면에서 보았을 때, Fargate 방식은 컨테이너 구동을 위해 요구되는 필요한 리소스만 확인과 얼마나 오래 돌릴 것인지 확인만 하면 된다. 둘을 간단하게 정리하자면 다음과 같다.
– EC2 방식: 컨테이너를 적게 돌리건 말건 호스팅에 쓰인 EC2에 대한 비용이 청구
– Fargate 방식: 컨테이너를 가동을 위해 얼마만큼의 리소스가 요구되었는지, 얼마만큼의 기간 동안 가동할 것이지
이렇게만 들으면 Fargate가 무조건 좋아 보이지만, 만약 기본 인프라에 대한 액세스, 컨테이너를 가동하는 실제 인프라에 접근이 필요하다면 EC2 방식이 접근 측면에서 더 높은 유연성을 보여준다.