ECS 파헤치기: ECS(Elastic Container Service)에 대해 분석하기

[yachimiya]

📚 정의

Elastic Container Service(이하 ECS)는 컨테이너 애플리케이션을 쉽게 배포하거나 관리, 스케일링할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스입니다. 즉, 저희 프로젝트와 같이 컨테이너화된 애플리케이션을 배포하거나 스케일링하는 데 필요한 인프라를 AWS가 대신 관리해 주게 됩니다.

따라서 개발자가 인프라를 관리하는 데 들이는 노력을 최소화하고 애플리케이션 개발에만 집중할 수 있도록 컨테이너 오케스트레이션, 클러스터 관리, 스케줄링 등을 ECS가 자동으로 처리해 주게 됩니다.

🔄 애플리케이션 라이프 사이클 살펴보기

AWS Elastic Container Registry

도커의 컨테이너는 ‘이미지’라고 부르는 읽기 전용 템플릿으로부터 생성되는데, 이런 이미지는 보통 Dockerfile을 통해 빌드할 수 있습니다. 이 파일은 컨테이너를 어떻게 빌드할 수 있는지를 설명하는 일반 텍스트 파일이라고 할 수 있습니다.

FROM amazoncorretto:21-alpine
ARG JAR_FILE=build/libs/*.jar
WORKDIR /app
COPY ${JAR_FILE} app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/app.jar"]

이렇게 빌드된 이미지는 이미지를 배포하는 장소인 ‘도커 레지스트리’에 푸시하게 되는데, 저희는 기존에 도커 제작사에서 운영하는 공식 도커 레지스트리엔 도커 허브를 통해 이미지를 배포하곤 했었습니다. 그러나 이번에는 빌드된 이미지가 아마존이 관리하는 Amazon Elastic Container Registry(이하 ECR)에 올라가게 됩니다.

ECS의 구성 요소

태스크 정의(Task definition)

이미지를 생성하고 레지스트리에 저장한 뒤에는 ECS 태스크 정의(task definition)를 만들어야 합니다. 이 태스크 정의는 말 그대로 애플리케이션의 설계도라고 할 수 있고, JSON 포맷의 텍스트 파일로 작성할 수 있습니다.

{
    name        = "app",
    image       = "${aws_ecr_repository.app.repository_url}:latest",
    essential   = true,
    portMapping = [{ containerPort = 8080, hostPort = 8080 }]
}

예를 들어서 저희가 레지스트리에 푸시한 이미지, 애플리케이션 개방 포트, 컨테이너와 함께 사용할 데이터 볼륨 등과 같이 애플리케이션을 이루는 하나 이상의 컨테이너와 매개변수를 작성할 수 있습니다. 도커 컨테이너를 어떻게 생성할 수 있는지를 알려주는 역할을 하고, docker-compose.yml와 비슷한 역할을 하는 것 같습니다.

태스크(Task)

여기서 태스크는 위에서 작성한 ‘태스크 정의’를 기반으로 실제로 실행되는 컨테이너를 말합니다. 하나의 태스크는 하나 혹은 여러 개의 컨테이너로 구성될 수 있는데, 예를 들어서 스프링 부트 애플리케이션 컨테이너와 레디스 컨테이너를 하나의 태스크로 구성할 수도 있습니다.

이러한 태스크는 클러스터에 속한 컨테이너 인스턴스에 배포되게 되는데, ECS의 최소 단위라고 말할 수 있습니다.

컨테이너 인스턴스(Container Instance)

방금 말한 컨테이너 인스턴스는 ECS에서 컨테이너를 실제로 실행하는 EC2 인스턴스를 말합니다. 태스크들이 실제로 실행되는 물리적인 서버이고, 여러 태스크들이 하나의 컨테이너 인스턴스에서 실행될 수 있습니다.

참고로 컨테이너 에이전트는 ECS 클러스터 안에 있는 각 컨테이너 인스턴스에서 실행되는데, 이 에이전트는 현재 실행 중인 태스크와 컨테이너의 리소스 사용량 정보를 ECS로 전송하는 역할을 하고 있습니다. ECS로부터 요청을 받으면 태스크를 시작하기도 하고 중지하기도 합니다.

클러스터와 서비스

이렇게 태스크 정의를 작성한 후에는 이것을 실제로 실행해야 하는데, 이는 클러스터(cluster)라는 공간에서 이루어지게 됩니다. 클러스터는 저희의 애플리케이션을 실행할 수 있는 EC2 서버들의 모음이라고 간단하게 생각하셔도 좋을 것 같습니다.

서비스(service)는 태스크의 라이프 사이클을 관리하는 역할을 하는데, 우리가 지정한 수의 태스크를 계속해서 실행 상태로 유지하거나 태스크가 실패하거나 중지되면 자동으로 새로운 태스크를 실행하는 역할을 하게 됩니다. 서비스는 필요하면 ELB(NLB, ALB)와 연결될 수도 있습니다.

🛠️ 실습을 통해 알아보기

이 서비스가 대체 어떤 서비스인지 빠르게 파악하려면 역시 실습은 필수불가결이라고 생각합니다. nginx 이미지를 예시로 AWS에서 ECS를 직접 만들어보도록 하겠습니다.

1. IAM 역할 만들기

클러스터를 만들고 태스크를 정의하기 전에, 먼저 아래와 같은 IAM 역할을 만들도록 하겠습니다. 네트워크 수준(예: 보안 그룹, VPC)에서 통신이 허용되더라도, 이러한 권한들을 부여하지 않으면 다른 AWS 서비스와 통신할 수 없으므로 이러한 역할들을 만들어야 합니다.

1-1. EC2Role 만들기

[IAM > 역할 > 역할 생성]에서 AWS 서비스를 체크하고, 사용 사례에서 Elastic Container Service를 찾은 뒤에 EC2 Role for Elastic Container Service에 체크합니다.

권한 정책을 보면 알겠지만 EC2 인스턴스에서 실행되는 ECS 에이전트가 ECS 서비스와 통신하거나 컨테이너 작업을 위해 필요합니다.

• ecs:CreateCluster: EC2 인스턴스를 ECS 클러스터에 등록
• ecs:DeregisterContainerInstance: 클러스터에서 인스턴스 제거
• ecs:Poll, ecs:Submit:* ECS 에이전트가 태스크 상태를 체크하고 작업 결과를 ECS 서비스에 보고

역할 이름을 지정하고 [역할 생성]을 눌러 생성합니다.

1-2. ECSRole 만들기

이번에도 마찬가지로 [IAM > 역할 > 역할 생성]에서 AWS 서비스를 체크하고, 사용 사례에서 Elastic Container Service를 찾은 뒤에 Elastic Container Service에 체크합니다.

이 역할은 ECS가 우리를 대신해서 AWS 리소스(EC2, ELB)를 만들거나 관리하도록 하기 위해서 필요합니다. 역할 이름을 적절하게 지정하고 [역할 생성]을 눌러 생성합니다.

1-3. ECSTaskExecutionRole 만들기

이번에도 마찬가지로 [IAM > 역할 > 역할 생성]에서 AWS 서비스를 체크하고, 사용 사례에서 Elastic Container Service를 찾은 뒤에 Elastic Container Service Task에 체크합니다.

상당히 많은 권한 정책이 보일텐데, Task를 검색해서 AmazonECSTaskExecutionRolePolicy에 체크합니다. 설명을 보면 ECS 태스크를 실행하는 데 필요한 다른 서비스에 대한 액세스를 제공한다고 나와있습니다.

역할 이름을 적절하게 지정하고 [역할 생성]을 눌러 생성합니다.

1-4. ECSAutoScalingRole

이번에도 마찬가지로 [IAM > 역할 > 역할 생성]에서 AWS 서비스를 체크하고, 사용 사례에서 Elastic Container Service를 찾은 뒤에 Elastic Container Service Autoscale에 체크합니다.

여기서 AmazonEC2ContainerServiceAutoscaleRole 정책에는 ECS 서비스의 오토 스케일링(auto scaling) 기능을 위해서 필요한 권한이 정의되어 있는 것을 확인할 수 있습니다. 즉, 이 권한 정책을 통해 오토 스케일링 서비스가 ECS 서비스의 태스크 수를 동적으로 조절하고, CloudWatch 알람과 연동할 수 있습니다.

역할 이름을 적절하게 지정하고 [역할 생성]을 눌러 생성합니다.

2. 클러스터 만들기

우선 ECS 서비스에서 컨테이너를 실행하려면 클러스터가 있어야 합니다. [ECS > 클러스터 > 클러스터 생성]을 누릅니다.

그리고 Amazon EC2 인스턴스에만 체크하고, 발생하는 요금을 최소화하기 위해서 EC2 인스턴스 유형을 t2.micro로 변경합니다. EC2 인스턴스 역할은 방금 생성한 IAM 역할인 ecsInstanceRole을 선택합니다.

기본적으로 생성된 VPC와 서브넷을 이용하고, 보안 그룹에선 웹 서버에 액세스하기 위해 80 포트를 뚫었습니다. 그리고 생성된 인스턴스에 외부에서 직접적으로 접근할 수 있도록 퍼블릭 IP 자동 지정을 ‘켜기’로 지정했습니다.

설정이 얼추 끝나면 [생성]을 눌러 클러스터를 생성합니다.

3. 새로운 태스크 정의하기

먼저 컨테이너를 올리기 위해서 태스크를 정의해야 하는데, [ECS > 태스크 정의 > 새 태스크 정의 생성]으로 들어가면 아래와 같은 화면을 볼 수 있습니다.

인프라 요구 사항의 시작 유형을 보면 기본적으로 AWS Fargate에 체크가 되어있을텐데, 여기서는 Amazon EC2 인스턴스에만 체크합니다. 운영 체제/아키텍처는 기본적인 Linux/X86_64로 선택하고, 네트워크 모드는 awsvpc를 체크하면 됩니다.

Note

awsvpc를 선택하면 각 태스크가 자체 ENI(Elastic Network Interface, 쉽게 말하면 AWS에서 제공하는 가상의 네트워크 카드)를 가지게 되고, 이를 통해서 태스크별로 고유한 IP 주소를 할당할 수 있게 됩니다. 추가로, 태스크 레벨에서 보안 그룹을 직접 적용할 수도 있습니다.

참고로, awsvpc 네트워크 모드를 사용하면 Fargate 시작 유형을 사용할 때 각 태스크의 ENI에 퍼블릭 IP 주소를 제공할 수 있지만, EC2 시작 유형을 선택하면 그럴 수 없습니다. 따라서 외부에서 EC2 내부에 있는 태스크에 접근하기 위해서는 VPC 내의 로드 밸런서 등으로 태스크의 프라이빗 IP 주소로 라우팅시켜야 합니다.

awsvpc는 AWS ECS에서만 제공하는 특별한 네트워크 모드이고, 그 외의 옵션들(bridge, host, none)은 도커의 네트워크 모드와 동일한 개념입니다.

태스크 크기에서 한 태스크에 단순한 데모 NGINX 앱이 올라가므로 그렇게 많은 CPU와 메모리를 예약할 필요가 없습니다. 여기서는 .25 vCPU와 .5 GB를 사용하겠습니다. 이러면 1 vCPU가 100%라고 했을 때 25%만 사용하게 되고, 512MB의 메모리를 사용하게 됩니다.

컨테이너의 이미지 URI에는 테스트용으로 nginx를 입력하고, 필수 컨테이너에는 ‘예’를 선택합니다.

Note

필수 컨테이너는 태스크의 실행에 반드시 필요한 컨테이너고, 필수 컨테이너가 실패하면 태스크 전체가 중지됩니다. 예를 들어서 한 태스크에 웹 서버 컨테이너와 로그 수집기 컨테이너가 있다고 하면 아래와 같이 생각할 수 있습니다.

• 웹 서버 (필수 O) → 이게 죽으면 애플리케이션이 완전히 작동 불가
• 로그 수집기(필수 X) → 이게 죽어도 웹 서버는 계속 작동 가능

그리고 ECS에서 태스크의 상태를 확인할 때 필수 컨테이너의 상태만 고려하는데, 필수 컨테이너가 하나라도 UNHEALTHY이거나 UNKNOWN이면 태스크의 상태는 해당 상태를 따라가게 됩니다. 다시 말해서, 모든 필수 컨테이너의 상태가 HEALTHY여야 태스크의 상태가 HEALTHY로 판단되는 것입니다.

4. 서비스 만들기

위에서 생성한 클러스터로 들어가서 [클러스터 > 서비스 > 생성]으로 들어갑니다. 배포 구성에서 서비스 없이 독립 실행형 태스크를 만들 수도 있지만, 여기서는 ALB와 연결시키기 위해서 서비스를 만들도록 하겠습니다. 서비스를 선택하고, 패밀리는 우리가 방금 생성한 태스크 정의를 선택하면 됩니다.

로드 밸런싱에서는 ALB를 선택하고 [생성]을 눌러 서비스를 배포합니다.

서비스가 배포된 다음에 로드 밸런서의 DNS 이름을 타서 들어가면 정상적으로 nginx의 기본 페이지가 뜨는 것을 확인하실 수 있습니다.

💸 비용

역시 주목할 부분은 아무래도 비용이라고 생각이 되는데, ECS를 사용하면서 추가 요금은 전혀 발생하지 않습니다.

위에서 사용한 EC2 시작 유형 같은 경우에는 애플리케이션을 실행하거나 저장하기 위해서 중간에 생성된 AWS 리소스(예: EC2 인스턴스, 로드 밸런서, EBS 볼륨, 퍼블릭 IPv4 주소 등)에 대한 비용만 지불하게 됩니다.

만약에 Fargate 시작 유형을 사용하는 경우에는 애플리케이션에서 요청하는 vCPU와 메모리 리소스 양에 대해서만 지불하면 된다고 합니다. 이 경우에는 컨테이너 이미지를 내려받은 시점부터 ECS 태스크가 종료될 때까지 사용한 리소스를 기준으로 계산됩니다. 자세한 내용은 AWS Fargate 요금에서 확인하실 수 있습니다.

참고

• What is Amazon Elastic Container Service?