ECS Scaling

Service CPU Usage Example

아래의 예시에서는 service A가 두 개의 Task를 운영하고 있다.
이 때, 유저가 접속하면 CPU Usage는 매우 부족한 상황이라 가정하자.

• Auto scaling을 설치하면 많은 유저가 service에 접속할 경우 특정 CPU 이상 사용하게 될 경우
  CloudWatch Metric이 CloudWatch Alarm을 트리거 할 것이며 이에 의해 Auto scaling이 ECS service를 자동으로 조정해 새로운 task를 launch할 것이다.
  - 이는 Fargate와 EC2 launch type 모두에 적용 가능하다.

• 이 경우, 가끔 EC2 instance에 새로운 task를 시작할 공간이 부족할 수 있기 때문에 instance 자체에 조정이 필요할 수도 있다.
  - 따라서, 우리는 EC2 instance의 ECS cluster를 ECS Capacity Providers를 통해 최대 규모로 조정할 수 있다(이는 선택사항이다!). 이를 통해 더 많은 EC2 instance를 추가할 수 있다.

SQS Queue Example

만약 우리가 SQS Queue로부터 메시지를 읽어올 수 있는 service를 가지고 있다면 이를 통해 메시지를 가져오게 될 것이다(poll for messages).

• 이 때, 아래와 같이 ECS service에 auto-scaling을 설치한 뒤 CloudWatch Metric을 이용해 Queue Length를 확인하고 length가 특정 threshold를 넘기면(너무 많은 메시지가 있으면) alarm을 trigger 하도록 구성한다.
  - 이후 alarm은 auto scaling group이 ECS service를 위해 새로운 task를 생성하도록 만들어 준다.
• 위에서와 마찬가지로 ECS capacity provider를 이용해 EC2 instance의 용량이 부족할 경우 instance를 추가하도록 만들 수도 있다.

ECS Rolling Updates

v1에서 v2로 업데이트를 할 때 몇 개의 tasks를 어떤 순서로 실행 시키고 중단 시킬 지를 결정할 수 있다.

ECS service update screen에서 Minimum healthy percent와 Maximum percent를 지정할 수 있다.

• minimum healthy percent
  - 만약 최소 백분율이 100이하가 되면 최소 백분율을 초과하는 충분한 task를 가진 경우 초과한 task들은 종료하도록 할 수 있다.
• maximum percent
  - 최대 백분율은 v1에서 v2로 업데이트 할 때 얼마나 많은 새로운 task를 생성할 수 있는 지를 나타낸다.
  - 기본적으로 서비스를 roll update 한다.
  

예를 들어,

Min 50%, Max 100%이며 시작 tasks의 숫자가 4개라고 가정해 보자.

1. 그러면 tasks는 2개로만 가동 할 수 있기 때문에 2개는 종료한다(50%).
2. 이후 업데이트 하면 v2 두 개가 추가 되고(100%) v1 두 개는 종료 된다(50%).
3. 그 다음 v2 두 개가 추가로 업데이트 되어 100%가 된다.