[AWS] ECS Task 구성하기

이번 글에서는 ECS의 핵심 아이템인 Task를 구성하고 관리하는 방법에 대해 살펴보고자 합니다. Task는 업무의 단위라는 뜻을 가지고 있기도 한 만큼 클러스터 구성에서도 큰 비중을 차지하고 있습니다. 실제 껍데기는 클러스터이고 안을 채우고 있는 것은 태스크라고 봐도 무방합니다. 

 

1) 태스크 생성 방법

아래 링크로 이동하여 태스크 리스트를 확인한 후 '새 태스크 정의 생성'이라는 버튼을 눌러 '새 태스크 정의 생성' 을 해줍니다. 

https://ap-northeast-2.console.aws.amazon.com/ecs/v2/task-definitions?region=ap-northeast-2 

https://ap-northeast-2.console.aws.amazon.com/ecs/v2/task-definitions?region=ap-northeast-2

JSON 파일로도 새 태스크 정의 생성을 하는 것이 가능하지만 처음이므로 콘솔로 태스크를 생성해보겠습니다.

 

2) 태스크 구성하기 1단계 - 태스크 정의 및 컨테이너 구성

해당 페이지에서는 태스크의 기초 개념인 태스크 정의 패밀리 이름과 ECR 리포지토리에 존재하는 Docker Image URI를 넣어주는 역할을 합니다. 

a. 태스크 정의 패밀리

태스크의 이름과도 같습니다. 태스크를 하나만 사용할 것이면 괜찮지만, 여러 대를 운용해야할 필요가 있으면 (예를 들어, 다른 도커 이미지나 다른 서버를 운용) 규칙을 정하는 것도 방법입니다. 저 같은 경우 태스크 명은 {서비스명}-{프론트/백엔드}-{운영환경}-task 정도로 지정하는 편입니다.

 

b. 컨테이너 구성

다음으로 정의할 것은 우리가 개발해놓은 Docker Image Repository 의 이름과 이미지 URI를 넣어주는 과정입니다. 리포지토리의 URI를 넣으면서 마지막에 ":latest"는 필수로 넣어주어야 최신 버전의 이미지를 기반으로 빌드가 가능합니다. 그 외에 이전 버전으로 롤백하는 경우 파라미터로 처리를 해야할 수도 있습니다. 

ECR 링크 : https://ap-northeast-2.console.aws.amazon.com/ecr/repositories?region=ap-northeast-2 

https://ap-northeast-2.console.aws.amazon.com/ecr/repositories?region=ap-northeast-2

* 컨테이너는 1개는 필수 사항이고, 2개부터는 선택적으로 추가가 가능합니다. 

 

1. 포트번호 지정

이제 도커 이미지가 어떤 포트에서 뜨는지 설정하는 부분입니다. 기본적으로 Spring Framework를 쓴다면 8080번 포트를 쓴다는 가정하에 아래와 같이 설정해보겠습니다. 

 

2. 컨테이너에 환경 변수 또는 S3 파일 추가

이제 서버가 어떤 환경으로 작업을 진행할 지 Active Profiles 등의 환경 변수를 넣어주는 부분입니다. 넣어주는 방법은 기존에 사용했던 방법과 같이 Key-Value Pair 로 넣어주면 됩니다. 

S3 파일의 경우 링크를 넣는 것이 아닌 ARN(Amazon Resource Name) 값을 넣어줍니다. 

S3 파일로 들어가보면 이렇게 ARN 고유값이 존재합니다.

 

3. 상태 확인 및 도커 구성

그 외에 shell command, docker-compose 구성등을 할 수 있는 옵션이 제공됩니다. 

태스크 정의와 컨테이너 구성이 제대로 입력되었다면 '다음'을 클릭하여 두번째 스텝으로 넘어갑니다.

 

3) 태스크 구성하기 2단계 - 환경, 스토리지, 모니터링 및 태그 구성

a. 환경

이제 두번째로 확인할 곳입니다. 앱 환경의 경우 AWS Fargate, EC2 중에 선택이 가능합니다. 이번 태스크 생성은 Fargate로 진행하고자 하여 Fargate를 선택하겠습니다. 

 

1. 운영 체제/아키텍처

특별한 일이 없는 한 ARM64를 선택합니다.

 

2. 태스크 크기

여기서는 선택한 CPU에 따라 메모리를(또는 그 반대로 선택한 메모리에 따라 CPU 선택) 선택할 수 있습니다. 

사용 가능한 스펙은 0.5vCPU 일때 RAM 4GB까지 사용가능합니다.

 

3. 컨테이너 크기 

컨테이너 크기는 Docker Image를 관리하는 Docker Container의 크기를 의미합니다. 여기서는 설정을 따로 하지 않아도 태스크 크기에 맞춰 자동으로 지정해줍니다.

 

4. 태스크 역할, 네트워크 모드 

태스트 역할은 컨테이너가 AWS 서비스에 API 요청을 할 수 있게 허용하는 역할을 합니다. 보통 AWS 외부에서 API를 호출하는데 정책이 들어가지 않은 상태로 서버를 띄우게 되면 접근 자체가 불가능한 API가 있습니다. 그렇기 때문에 역할(IAM 관련)을 할당해주고 어느 선까지 API 요청이 가능하고, 실행이 가능한지 설정할 수 있습니다. 통상적으로 태스크 역할, 실행 역할은 같게 적용해도 무방합니다. 

네트워크 모드는 Fargate를 선택한 이상 자동으로 VPC가 설정됩니다. 여기서 주석은 아래와 같이 나와 있습니다. 

네트워크 모드(network mode)는 태스크에서 컨테이너가 사용하는 네트워킹 유형을 지정합니다. 새로운 Amazon ECS 콘솔 환경은 현재 다음과 같은 네트워크 모드를 지원합니다.

• 작업에 탄력적 네트워크 인터페이스(ENI)를 제공하는 awsvpc 네트워크 모드. 이 네트워크 모드로 서비스를 생성하거나 태스크를 실행할 때 하나 이상의 서브넷, 보안 그룹 및 태스크에 퍼블릭 IP 주소를 할당할지 여부 등의 네트워크 구성을 지정해야 합니다.
• 브리지 네트워크 모드는 작업을 호스팅하는 각 Amazon EC2 인스턴스 내에서 실행되는 도커의 기본 가상 네트워크를 사용합니다. 브리지는 동일한 브리지 네트워크에 연결된 각 컨테이너가 서로 통신할 수 있도록 하는 내부 네트워크 네임스페이스입니다. 이는 동일한 브리지 네트워크에 연결되지 않은 컨테이너와의 격리 경계를 제공합니다. 정적 또는 동적 포트 매핑을 사용하여 컨테이너의 포트를 Amazon EC2 호스트의 포트와 매핑합니다.
• 네트워크 모드로 브리지를 선택한 경우 이전을 선택한 다음 포트 매핑에서 호스트 포트에 컨테이너용으로 예약할 컨테이너 인스턴스의 포트 번호를 지정합니다.
• 기본 모드는 작업을 호스팅하는 각 Amazon EC2 인스턴스 내에서 실행되는 Windows용 도커의 기본 가상 네트워크 모드를 사용합니다. 작업 정의에 네트워크 모드가 지정되지 않은 경우 이것이 Windows의 기본 네트워크 모드입니다.

 

b. 스토리지

태스크가 할당할 스토리지의 SSD 볼륨입니다. 기본값으로 지정하여도 프로그램이 작동되는데 큰 문제는 없습니다. 

 

c. 모니터링 및 로깅 

모니터링은 주로 로그를 집계하면서 동시에 이루어집니다. CloudWatch 라는 서비스가 바로 그 기능을 담당하는 서비스이고, 로그를 확인하고자 할 때에도 CloudWatch에서 확인이 가능합니다. 지금 이 글에서는 태스크를 설정하는 것만 먼저 체크해보고, 로그 보는 방법은 다른 글에서 올려보도록 하겠습니다. 

 

d. 태그

선택 사항이긴 하지만, 태그를 설정하면 비용 어떻게 청구되는지 확인하기 편합니다. 

완료되었으면 '다음'을 누른 후 검토가 완료되면 '생성'을 누릅니다. 

 

4. 태스크를 관리하는 것과 개정에 대하여

이제 만들어진 태스크를 확인해보면 새 개정 생성이라는 것이 있습니다. 

 

개정

개발중인 프로젝트에서는 기능이 더 추가되거나 유지 보수를 하는 와중에 버전을 관리하곤 합니다. 버전은 ECR 이미지에서도 알 수 있지만 최신 버전은 latest, 그리고 기존에 버전 히스토리가 차곡차곡 쌓입니다.

태스크의 기준에서는 프로젝트의 버전과 같이 형상 관리가 되는 기준을 '개정'이라고 합니다. 개정은 태스크가 변경되거나 스펙, 네트워크나 볼륨등이 변경되면 1씩 오릅니다. 그래서 기존에 사용했던 개정판으로 롤백을 시켜서 서비스를 운용할 수도 있습니다. 새롭게 태스크를 재구성하거나 문제가 생겨 급하게 롤백을 해야 하는 경우에 주로 사용합니다. 

 

여기서 "JSON을 사용하여 개정 생성"을 눌러보면 다음과 같이 나오게 됩니다. 

JSON을 가지고도 태스크 설정을 변경할 수 있고, 규칙만 잘 알고 있다면 다른 클러스터와 연결하는것도 매우 쉽습니다. 그리고 해당 json 파일은 추후에 젠킨스와 같이 외부에 존재하는 서비스에서 파이프라인을 연결할 때도 상당히 유용합니다. 

'생성' 버튼을 누르게 되면 기존에 사용하던 개정 1에서 개정 2로 업그레이드 됩니다. 

기존에 web-dev-cluster:1 에서 2로 변경된 것을 확인할 수 있습니다.

 

이제 이 개정 버전에 맞춰 클러스터에 태스크를 올리고 배포를 진행하는 과정까지 다른 글에서 작성해보겠습니다.