ECS에서 Auto Scaling 관련 옵션을 설정할 때는

• 최소 태스크 수 / 희망 태스크 수 / 최대 태스크 수를 설정할 수 있고

스케일링을 할 때 사용하는 정책은 크게 다음과 같이 둘로 나뉜다.

(1) Target tracking scaling policies(Recommended)
(2) Step scaling policies

1. Target tracking scaling policies

특정 메트릭에 관한 target value(목표값)를 기준으로 스케일링을 진행하는 것이다. 다음과 같은 메트릭 중에 선택할 수 있다.

• ECSServiceAverageCPUUtilization—Average CPU utilization of the service.
• ECSServiceAverageMemoryUtilization—Average memory utilization of the service.
• ALBRequestCountPerTarget—Number of requests completed per target in an Application Load Balancer target group.

즉, 특정 목표값을 설정해두면 해당 목표값을 유지하기 위해서 스케일링이 자동으로 진행되는 것이다. 마치 온도 조절기에 원하는 온도를 설정해두면 어떤 환경(더운 곳이든 추운 곳이든)이든 온도 조절기가 해당 온도를 유지하기 위해 노력하는 과정을 상상하면 된다.

그밖에 주목해야 할 설정으로는 Scale-out cooldown period가 있는데 한 번의 스케일링 아웃이 끝나고 다음 번 스케일링 아웃이 시작될 때까지 대기해야하는 시간(초)이다. 반대로 Scale-in cooldown period는 한 번의 스케일링 인이 끝나고 다음 번 스케일링 인이 시작될 때까지 대기해야 하는 시간(초)이다. 참고로 스케일링 인 후에 Scalin-in cooldown period에 있는데 갑자기 스케일 아웃을 해야하는 알람이 발생하면 스케일링 아웃은 즉시 진행된다.

해당 목표 수치를 유지하기 위해 스케일 아웃이 필요한 경우 스케일 아웃은 최대한 빨리 진행되지만 스케일인의 경우 좀더 점진적으로 수행된다.

그리고 해당 target tracking scaling policy는 복수 개를 설정할 수 있는데 스케일 아웃은 해당 policy들 중 하나라도 만족하면 발생하고, 스케일 인은 해당 policy들 모두가 만족되었을 때 발생한다.

2. Step scaling polices

Cloudwatch alarm을 기반으로 스케일링을 하는 전략이다. 알람을 어떻게 만드는지는 주제와 관련은 없으니 논외로 한다. 이런 알람이 발생했을 때 태스크를 얼마나 늘리고 줄일 것인지 직접 설정할 수 있다. 예를 들어 CPU 사용량이 75~85%인 경우 하나의 태스크를 추가하고, 85% 이상인 경우 두 개의 태스크를 추가하는 식으로 사용할 수 있다. 그리고 이렇게 태스크를 개수 단위가 아니라 현재 desired count의 몇 % 단위로 설정할 수 있고 몇 % 단위일 때 한번에 증감시킬 태스크 수 또한(ex. 한번에 태스크 3개씩 추가 등) 지정할 수 있다.

3. Scheduled Scaling

4. 주의할 점

• 참고로 ECS는 메트릭 정보를 1분 간격으로 CloudWatch에 보내고, CloudWatch alarm은 존재하는 메트릭에 대해서만 발생가능하다.

• ECS 서비스 스케줄러는 항상 desired count대로 태스크를 유지하지만 scaling policy 관련 알람이 발생하는 경우 Service Auto Scaling이 사용자가 수동으로 설정해둔 desired count를 수정할 수 있다.

5. Service throttle logic

ECS 서비스 스케줄러는 특정 태스크가 RUNNING 상태로 넘어가지 않고 자꾸 PENDING -> STOPPED 상태로 가게 된다면, 그 다음 재시도 시작 시간의 간격은 점점 늘어난다.(최대 15분) 이렇게 함으로써 어차피 정상 시작할 수 없을 태스크가 리소스를 낭비하는 것을 방지한다. 이러한 실패가 발생하는 주요 이유들은 다음과 같다.

• 리소스 부족(port, memory, CPU, ...)
• 도커 이미지 로드 실패(잘못된 이미지 이름이나 태그, private registry 인증 정보 없음)
• 컨테이너 인스턴스의 컨테이너 생성을 위해 필요한 디스크 공간 부족

하지만 일단 태스크가 한번 RUNNING 상태로 간 다음에 실패한 경우라면 이러한 throttle logic은 실행되지 않는다. 예를 들어 로드밸런서 health check에 실패하는 태스크더라도 한번 RUNNING 상태로 간 것들은 이런 throttle logic과 연관이 없다.