[AWS] ECS 서비스 설정하고 실행하기

클러스터 상세 페이지로 들어가게 되면 서비스 내에 생성이라는 버튼이 있습니다. 생성을 클릭해서 서비스를 구성하여도 되고, 태스크 정의에서도 가능합니다. 

 

 

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

저는 태스크에서부터 서비스를 생성하는 방법을 설명해보겠습니다. (사실 클러스터에서 하는 것도 같습니다.) 태스크의 개정 생성 옆에 '배포'라는 드롭다운이 있습니다. 

 

서비스 생성 : 서비스를 생성하고 그 서비스가 계속 유지될 수 있도록 합니다. 운영중인 웹 프로젝트는 서비스로 선택하여야 합니다.

서비스 생성 기본 인터페이스

 

태스크 실행 : 한 건의 태스크만 실행되고 중지되는 태스크를 실행합니다. 스케줄로 작동하는 배치형 프로그램에 적합합니다.

태스크 실행 기본 인터페이스

 

여기서는 서비스 생성을 선택해준 후 상단부터 하나씩 확인해보겠습니다. 

 

1. 환경 

여기서는 클러스터를 선택하고 용량 공급자를 선택하는 옵션을 정해줍니다. 실행될 클러스터를 선택해줍니다. 

Fargate ARM 기반의 아키텍쳐는 용량 공급자는 현재 선택할 수 없습니다. 

 

2. 배포 구성 

해당 영역에서는 실행될 서비스의 이름과 태스크 개수를 지정할 수 있습니다. 기본적으로 1개가 세팅되어 있고, 태스크를 동시에 여러개 돌릴 필요가 없다면 1을 추천합니다. 

 

a. 배포 옵션

배포 옵션에서는 서비스가 작동을 시작하여 프로비저닝(배포 트리거가 눌렸을 때 Docker Image 내 프로젝트가 실행되기까지)의 단계에서 사용되는 태스크의 양을 설정할 수 있습니다. 퍼센트 단위로 설정할 수 있으며, 배포를 하면서 유동적으로 2배(200%)까지 유연성있게 확장이 되는 것입니다. 

 

b. 배포 실패 감지

태스크에 환경 변수가 잘못 세팅되거나 특정 상황때문에 배포가 실패하였다면 실패되었다라는 것을 CloudWatch 및 다른 서비스에 경보로 출력할 수 있습니다. 아래는 배포 실패가 되었을 때 AWS에서 이야기하는 주석입니다. 

Deployment failure detection(배포 실패 감지) 워크플로에서 Amazon ECS가 배포 실패를 감지하는 방법과 실패 시 취해야 할 조치를 지정할 수 있습니다.

롤링 업데이트의 경우 서비스 스케줄러가 원하는 개수에 도달할 때까지 새 작업을 시작합니다.

롤링 업데이트를 사용하는 서비스를 배포하는 경우 다음과 같은 실패 감지 방법을 사용할 수 있습니다.

• Use the Amazon ECS deployment circuit breaker(Amazon ECS 배포 회로 차단기 사용) - 작업이 정상 상태에 도달하지 않을 경우 회로 차단기가 배포를 실패로 설정합니다.
• Use CloudWatch alarms(CloudWatch 경보 사용) - Amazon ECS는 지정된 CloudWatch 경보가 ALARM 상태로 전환된 것을 감지하면 배포를 실패로 설정합니다.

Rollback on failures(실패 시 롤백) 옵션은 배포가 실패로 설정되었을 때 Amazon ECS가 마지막으로 완료된 배포로 롤백하는 것을 의미합니다.

이러한 방법을 개별적으로 사용하거나 함께 사용할 수 있습니다. 두 방법을 모두 사용하는 경우 두 방법 중 하나의 기준이 충족되면 배포가 실패한 것으로 간주됩니다.

CloudWatch alarm name(CloudWatch 경보 이름)의 경우 이미 생성한 CloudWatch 경보를 선택하거나 Create new alarm(새 경보 생성)을 선택하여 CloudWatch 콘솔에서 CloudWatch 경보를 생성합니다.

다음과 같은 경보 지표를 사용하는 것이 좋습니다.

• Application Load Balancer를 사용하는 경우 HTTPCode_ELB_5XX_Count 및 HTTPCode_ELB_4XX_Count 지표를 사용합니다. 이러한 지표는 HTTP 스파이크를 확인합니다.
• 기존 애플리케이션이 있는 경우 CPUUtilization  및 MemoryUtilization 지표를 사용합니다. 이러한 지표는 클러스터 또는 서비스가 사용하는 CPU 및 메모리의 백분율을 확인합니다.

 

c. 서비스 연결 

AWS에서 의미하는 서비스 연결은 다른 리전간 구성된 ECS간 상호 연결을 하기 위한 전략으로 보입니다. 다른 리전간 통신을 하기 위해 AWS 내부에서 통신 규약을 지정하는데, 여기서 사용하는 네임스페이스가 바로 AWS ECS 에서 관리하는 클러스터를 의미합니다.

클러스터 설정을 할 떄 us-east-1 (미국 동부 버지니아 북부 리전)에서 dev-cluster-us-east를 네임스페이스로 하였고, ap-northeast-2 (아시아 태평양 서울 리전) 에서 dev-cluster-seoul을 네임스페이스로 하였다면, 이 두 개의 클러스터를 연결시키기 위한 방법이라고 이해하면 될 것 같습니다. 즉, 리전을 1개만 사용한다면 불필요한 옵션입니다. 자세한 정보는 AWS 공식 문서에 나와 있습니다. 

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-connect.html?icmpid=docs_ecs_hp_deploy_serviceconnect 

Service Connect - Amazon Elastic Container Service

 

d. 네트워킹

여기에서는 아마존 내부의 VPC(가상 사설 클라우드)를 선택하고 서브넷을 설정할 수 있습니다. 그리고 EC2 설정에서 적용하였던 보안 그룹을 적용하여 화이트리스트 또는 블랙리스트에 대한 컨트롤을 지원합니다. 

 

e. 로드 밸런싱

사실 서비스 관리에서 가장 큰 부분을 차지하는 영역입니다. 서버를 단일 서버로 운용하고자하여 오토 스케일링 또는 로드 밸런싱이 필요없는 경우는 이 설정을 패스하셔도 됩니다. 

하지만 트래픽이나 CPU사용량에 따라 서버의 대수가 변경되고 무중단 배포를 희망한다면 이 부분을 잘 확인해보는 것이 좋습니다. 대부분의 문제는 여기서 발생하기 떄문입니다. 

 

로드 밸런서란? 클라이언트는 1개의 IP를 가지고 2대의 서버 경유를 할 수 없습니다. 서버가 2대 이상일 때는 일정양 만큼 고르게 요청을 보내거나 가중치를 두어 요청의 수를 서버 스펙에 맞게 다르게 지정할 수 있습니다. 로드 밸런서는 이 중재자 역할을 하면서 트래픽을 자유롭게 조절하는데 도움을 줍니다. 서버가 배포중이거나 잠시 사용이 불가능한 상태가 될 때 우회를 시켜주는 역할도 병행하면서 동시에 서버가 잘 살아있는지 헬스 체크를 병행하기도 합니다. 

 

AWS 에서의 로드 밸런서

아마존 웹서비스에서 제공하는 로드 밸런서는 크게 3가지의 유형이 있습니다. 

• Application Load Balancer: 일반적으로 웹 소켓 통신에서 사용되는 로드 밸런서입니다. 기본적인 웹페이지나 API 서버등은 모두 클라이언트의 요청을 받아 원하는 페이지 혹은 데이터를 제공해줍니다.  
• Network Load Balancer: 가상 사설 클라우드(VPC) 내에서 TCP, UDP, TLS와 관련된 네트워크 통신을 할 때 사용하는 로드 밸런서입니다. 주로 내부망에서 사용이 되고, 외부의 접근이 제한됩니다. 
• Gateway Load Balancer: 써드 파티 앱 또는 보안, 정책 컨트롤과 관련된 로드 밸런싱을 위해 존재하는 로드밸런서입니다. 

 

아마존에서 이야기해주는 로드 밸런서 유형은 아래에 기재하였습니다. 

사용하는 Load balancer type(로드 밸런서 유형)은 애플리케이션의 특정 요구 사항에 따라 달라집니다.
Application Load Balancer는 애플리케이션 계층에서 라우팅 결정을 내리고 HTTP 및 HTTPS 네트워크 트래픽을 라우팅합니다. 연결 요청을 처리하고 대상 그룹을 통해 대상으로 라우팅하기 위해 Application Load Balancer에 하나 이상의 리스너를 구성해야 합니다.

 

이제 다시 ECS의 로드 밸런싱 설정을 진행해보겠습니다. 

로드 밸런서 유형 : 위 3가지의 유형중에 선택하면 됩니다. 웹 애플리케이션의 경우 Application Load Balancer를 선택하면 됩니다.

로드 밸런서가 존재하는 경우 '기존 로드 밸런서 적용' 을 눌러 선택하시면 되고, 없는 경우 로드 밸런서를 자동으로 생성해주는 '새 로드 밸런서 생성'을 누릅니다.

로드 밸런서 이름 : 구분이 되는 로드 밸런서의 이름을 작성해주시면 됩니다.

리스너 : 로드 밸런서는 리스너가 존재합니다. 기본적으로 로드 밸런서가 떠있는 포트 번호는 HTTP의 경우 80, HTTPS의 경우 443의 값을 가지고 있고, 요청이 오게 되면 기본적으로 적용되는 포트 번호를 가진 리스너가 필요합니다. 

* HTTPS 설정을 진행하고자 하는 경우 아래 글을 참고해주시기 바랍니다. 

https://abbo.tistory.com/435

[AWS] ECS HTTPS 적용하기

 

대상 그룹 이름 : 로드 밸런서는 대상 그룹(Target Group)이라고 하여 태스크로 요청을 라우팅하는데 사용됩니다. ECS 서비스가 시작되거나 중지될 때 대상 그룹이 지속적으로 업데이트 되며, 헬스 체크를 위한 신호를 주기적으로 보내 서버의 상태 체크를 지속합니다. 여기에 입력하는 이름으로 '대상 그룹'이 자동 생성되고 자동으로 로드밸런서에 붙습니다. 

상태 확인 경로 : 태스크의 헬스 체크를 하기 위한 경로입니다. Java 프로젝트에 actuator라고 하는 의존성이 있는 경우 "/actuator/health" 라는 경로를 자동으로 생성해주기 때문에 기본값을 다음과 같이 붙였지만, 기본적으로 루트 패스("/")를 가지고 있어도 무방합니다.

상태 검사 유예 기간 : 상태 확인 주기를 의미합니다. 저같은 경우 60초마다 주기적으로 서버의 상태를 체크합니다. 

 

f. 서비스 자동 크기 조정 (오토 스케일링 설정)

서비스가 트래픽을 많이 받거나 이상이 생겨 자원 소모량이 갑자기 늘어나게 되면, 관리하고 있는 운영체제가 서비스를 강제 종료시키거나 서버가 다운되는 경우가 종종 있습니다. 그렇기 때문에 그 부하량을 설정하여 특정 임계점에 도달하게 되면 태스크를 여분으로 작동시키는 기능입니다. 이를 오토스케일링이라고 합니다. 

최소 태스크 개수 : 문제가 없더라도 상시적으로 운용되는 태스크 개수를 지정합니다.

최대 태스크 개수 : 문제가 발생하였거나 리소스 소모량이 늘었을 때 임계치에 도달하면 켜지는 태스크 개수입니다. 최대로 도달하면 2개로 설정하였기 때문에 2개가 다 문제가 발생하더라도 추가적으로 태스크가 켜지지 않습니다.

정책 이름 : 오토 스케일링의 이름을 정해줍니다. 

ECS 서비스 지표 : 이 기준을 가지고 CPU 사용량 또는 메모리 사용량, 요청횟수를 감지하여 특정 시점 이후에 태스크 개수를 늘릴지 정합니다. 

대상 값 : 위의 지표값에 맞는 임계치를 설정할 수 있습니다. 

확장 휴지 기간 : 태스크를 확장해서 유지하고 지속하는 시간을 입력합니다. 단위는 초입니다.

축소 휴지 기간 : 태스크를 확장한 이후에 다시 정상으로 돌아왔을 때 최소 단위로 돌아가는 시간을 의미합니다. 단위는 초입니다.

 

g. 작업 배치 및 태그 

태스크를 인스턴스에 배치하는 방식을 정할 수 있는 구간입니다. 정보 탭을 열어보면 아래처럼 나와있습니다. 

Task placement(작업 배치) 옵션은 Amazon ECS가 클러스터의 인스턴스에 작업을 배치하는 데 사용하는 알고리즘을 결정합니다.

다음과 같은 템플릿을 사용할 수 있습니다.

• AZ Balanced Spread - 작업을 가용 영역과 가용 영역의 컨테이너 인스턴스에 분산합니다. - 이 값이 기본값입니다.
• AZ Balanced BinPack - 작업을 가용 영역과 가용 메모리가 최소인 컨테이너 인스턴스에 분산합니다.
• BinPack - 사용 가능한 CPU 또는 메모리 최소량에 따라 작업을 분산합니다.
• One Task Per Host - 각 컨테이너 인스턴스에 서비스의 작업을 최대 1개 배치합니다.
• Custom - 자체 작업 배치 전략을 정의합니다.

Custom(사용자 지정) 템플릿을 선택하면 최대 5개의 전략과 10개의 제약 조건을 정의할 수 있습니다.

Strategy(전략)는 Type(유형)(알고리즘)과 Field(필드)(알고리즘이 적용되는 개체)로 구성됩니다.

Constraint(제약 조건)는 Amazon ECS가 작업을 배치할 때 고려하는 필터입니다. 제약 조건은 Type(유형)(규칙 정의)과 Expression(표현식)(둘러싼 큰따옴표(" ") 없이 사용자 지정 또는 기본 속성 정의)으로 구성됩니다.

 

 

이후 설정이 완료되었다면 '생성'을 눌러 서비스를 생성합니다. 서비스가 생성되면 몇 초 뒤에 자동으로 서비스가 시작됩니다.