[AWS] AWS ECS Fargate?

01. ECS

현재 고객사 서비스의 API는 ECS Fargate로 구성이 되어있다.
ECS에 대해 간략히 정리하고 복기하고자 하는 마음으로 글을 작성한다.

https://tech.cloud.nongshim.co.kr/2021/08/30/%EC%86%8C%EA%B0%9C-amazon-ecs%EB%9E%80/

• ECS(Elastic Container Service)는 클러스터에서 컨테이너를 쉽게 실행, 중지 및 관리할 수 있게 해주는 컨테이너 관리 서비스
• 간단한 API 호출을 사용하여 컨테이너 기반 Application을 시작 및 중지할 수 있다

01-1. ECS Fargate

• AWS Fargate란 서버를 관리하지 않고도 컨테이너를 배포하고 관리할 수 있는 서버리스 컴퓨팅 엔진이다
• Task에 산정된 리소스만큼 사용한 만큼만 비용이 발생한다
• 같은 애플리케이션의 Fargate끼리는 localhost 안에서 서로 통신할 수 있다

01-2. ECS Cluster

• 하나의 ECS Cluster 안에 포함되는 개념은 Service -> Task -> Container 순이다
• ECS에서 Service는 여러 Task의 집합이라 할 수 있다
• ECS에서 Task는 여러 Container의 집합이라 할 수 있다
• 하나의 docker-compose를 하나의 Task라 생각하면 편할 것 같다
• ECS는 Cluster의 Container 인스턴스들을 관리하면서 Task를 실행을 해준다

01-3. Task definition

• ECS의 Task를 만들기 위한 하나의 클래스 혹은 설계도라 할 수 있음
• Task 실행을 위한 청사진으로 봐도 좋을 듯 하다
• 자바에서 청사진이라 하면 클래스가 있지 않은가? 이렇듯이 Task defefinition도 마찬가지다
• Task definition(작업 정의)는 ecs의 최소 실행 단위

01-4. Task

• Task란 작업 정의(Task Definition)에서 정의된 설정으로 인스턴스화 된 것을 의미한다
• Task의 경우 Cluster에 속한 컨테이너 인스턴스(EC2 인스턴스) 혹은 Fargate에 배포하게 된다

02. Fargate

• Fargate를 사용하면 EC2 인스턴스를 관리하지 않아도 된다는 장점이 있음
• Task만 정의하면 해당 Task를 어딘가에서 실행 해준다 (Serverless)

02-1. Fargate의 장점

• 인프라 영역(ECS Fargate)을 따로 정의하지 않아도 됨
• Task만 정의 하여도 구동이 가능
• Task에 정의한 리소스(CPU, Mem) 만큼만 비용이 청구된다

02-2. Fargate의 단점

• 일부 기능 지원 X
• Fargate에서는 Swap Memory를 사용할 수 없음
• 비용이 13% 정도 더 비쌈

03. ECS vs Fargate

• 대체로 Fargate가 추천이 된다
• 워크로드(Workload)가 예상 가능하지 않거나(변칙적)
• 비용 최적화가 정말 중요한 조직이 아니라면

03-1. EC2 vs Faraget, 뭘 써야 하는가?

• EC2를 사용해야 하는 경우
  • 지원되지 않는 기능이 필요하거나
  • 워크로드가 어느정도 예측이 되거나
  • 비용 최적화에 자신이 있다면
• Fargate를 사용해야 하는 경우
  • 지원되지 않는 기능이 있어도 상관 없는 경우, Fargate는 특정 기능을 지원하지 않는 경우가 있음
  • Volume Mount
  • Fargate의 경우 EFS나 FireLens(Fluentd)를 통해 로그를 전달하는 아키텍처가 주로 사용되는 것으로 보인다

Hard vs Soft

• Hard
  • 명시한 값만큼 리소스 제약이 생김
  • 클러스터 인스턴스에서 docker stats 명령어를 조회하면 LIMIT 값이 Hard로 명시한 값으로 표시
• Soft
  • 명시한 값이 클러스터 인스턴스에 예약 된다
  • Soft limit이므로 컨테이너 메모리 사용량이 명시한 값의 제한을 넘겨 사용이 가능함
  • 클러스터 인스턴스에서 docker stats 명령어롤 조회하면 LIMIT 값이 클러스터 인스턴스의 총 자원으로 표시

⁉️ 왜 Hard Limit을 사용하여 Container의 리소스를 제약하는거지?

1. 여러 컨테이너가 동일한 인스턴스에서 실행될 때, 하나의 컨테이너가 너무 많은 리소스를 사용하면 다른 컨테이너의 성능에 영향을 줄 수 있기 때문에, 각 컨테이너가 사용할 수 있는 리소스를 제한한다.
2. 리소스 제약을 통해 애플리케이션의 예상치 못한 리소스 사용을 제한하여, 다른 애플리케이션에 영향을 주는 것을 방지할 수 있다.

ECS Scailing

ECS의 스케일링(Scailing) 방식은 2가지가 존재한다

• Service에 의하여 Task가 Scailing 되는 Horizontal AutoScailing
• CapacityProvider에 의하여 컨테이너 인스턴스가 Scailing 되는 Cluster Autoscaling

Service auto scaling

서비스 스케일링은 또 다시 Target tracking과 Step scaling으로 나뉜다

• Target tracking : CPU/Memory 사용률 및 ALB 요청 횟수를 기반한 정책
• Step 방식 : Alarm을 활용한 Custom 정책

ECS Service Configuration

Deployment Configuration

ECS 서비스에서 배포와 관련된 설정을 보면, maximumPercent, minimumHealthyPercent가 존재한다.

 

🧑🏻‍💻는 ECS maximumPercent가 200%, minimumHealthyPercent가 100%로 설정되어 있으며, Rolling update 방식을 사용하고 있다. 현재 ver01을 운영하는 🧑🏻‍💻는 실수로 오류를 포함한 ver02를 배포했다. 기존 Task 4개일 때, 어떤 상황이 벌어지는가?

 

minimumHealthyPercent가 100%이기 때문에 ver02에 프로비저닝되고 정상 상태로 확인될 때까지 ver01은 중단되지 않습니다. ver02는 running 상태로 진입하지 못해 provisioning-pending-stopped 단계를 반복합니다. 이때 maximumPercent가 200%임에 따라 ver02 Task는 4개와 ver01 Task 4개(합, 최대 8개)의 Task가 동시에 올라올 수 있다.

Task Placement

ECS Task Rebalancing을 이용한 EC2 비용 최적화

ECS의 서비스가 컨테이너 인스턴스에 Task를 배치하는 전략은 아래 3가지로 분류됨

전략은 단독 혹은 복수로 지정이 가능함

• binpack : CPU 또는 메모리를 최소화 하기 위해 유휴 자원을 고려한 배치
• random : 무작위 배치
• spread : ami-id, availability-zone, instance-type, os-type 등을 고려한 배치

04. ECS AutoScaling 관련

• Cooldown period
• Scale-out cooldown period
  • 한 번의 스케일링 아웃이 끝나고 다음 번 스케일링 아웃이 시작될 때까지 대기해야 하는 시간(초)이다
• Scale-in cooldown period
  • 한 번의 스케일링 인이 끝나고 다음 번 스케일링 인이 시작될 때까지 대기해야 하는 시간(초)이다

• Minimum adjustment magnitude
  • 최소 몇개의 Task를 줄일 것인지 명시
  • ex) 만약 줄여야 한다면 최소 1개의 Task를 줄여라

04-1. Step Scaling Polices

ScaleOut Policy

ScaleIn Policy

1. Cloudwatch Alarm을 기반으로 스케일링을 하는 전략
2. 이러한 알람(CA)이 발생했을 때 태스크(Task)를 얼마나 늘리고 줄일 것인지 직접 설정이 가능
3. 예를 들어 CPU 사용량이 75% ~ 85%인 경우 하나의 태스크(Task)를 추가하고, 85% 이상인 경우 두 개의 태스크(Task)를 추가하는 식으로 사용이 가능하다
4. 태스크 개수 단위가 아닌 % 형식으로도 늘릴 수 가 있는데, 현재 desired count의 몇 % 단위로 설정이 가능하고 몇 % 단위일 때 한번에 증감시킬 태스크 수 또한 지정이 가능하다

04-1. 주의할 점

CoolTime이 300s인 경우에 반대로는 작용이 된다
IN → IN은 안됨 OUT → OUT도 안됨

1. 참고로 ECS는 메트릭 정보를 1분 간격으로 CloudWatch에 보내고, CloudWatch alarm은 존재하는 메트릭에 대해서만 변경 가능하다
2. ECS 서비스 스케쥴러는 항상 desired count대로 테스크를 유지 하지만 Scaling policy 관련 알람이 발생하는 경우 Service Auto Scaling이 사용자가 수동으로 설정해둔 desired count를 수정할 수 있다.
3. ECS ScaleIn Cooltime이 300s 로 잡혀 있다고 가정을 했을 때 해당 시간이 지나기 전에 ScaleIn이 발생하는 경우에는 이벤트가 발생하지 않는다, 하지만 300s 내 범주 과정에서 ScaleOut 이벤트가 발생하게 되면 실제 ScaleOut이 실행 되게 된다

05. ECS 작업 배치 전략

• 작업 배치 전략
  • 작업 배치를 위한 인스턴스나 종료할 작업을 선택하는 알고리즘
  • 예) 작업이 인스턴스 그룹 전체에 고르게 분산되도록 선택하거나 무작위로 선택
  • Amazon ECS 서비스의 일부로 실행되는 작업의 기본 전략은 attribute:ecs.availability-zone에 대한 spread를 사용합니다
• Fargate 시작 유형
  • 작업 배치 전략 및 제약 조건이 지원되지 않음
  • Fargate 작업은 가용 영역 전체에 분산된다

99. 참고자료

[소개] Amazon ECS란?

Docker overview

Amazon Elastic Container Service란 무엇입니까? - Amazon Elastic Container Service

ECS on EC2 Walkthrough

 

[AWS] ECS란? – 교보DTS 기술 블로그