이글에서 CAS란 Cluster Auto Scaling의 약자이며 ASG란 Auto Scaling Group의 약자임을 참고하도록 하자. AWS에서 제공하는 ECS의 디자인 목표는 다음과 같다.
CAS는 태스크를 실행할 공간이 없을 때마다 ASG를 확장할 수 있어야 한다.
CAS는 다른 태스크에 영향을 주지 않는 선에서 ASG를 축소할 수 있어야 한다.
이 목표에는 ecs 데몬은 포함하지 않는 것으로 보인다.
소비자(개발자)는 ASG에 대한 전면적인 수정 권한을 가지고 있다.
필요에 따라서 최소, 최대 사이즈를 수정할 수 있다.
우리는 $M$이 얼마만큼의 자원이 필요한지 알 수 없다. 하지만 단순한 논리로 생각하자면 $M >N$일 경우 스케일링이 필요하며, 반대 상황의 경우는 축소가 필요하다는 것을 알 수 있다.
ECS의 라이프 싸이클을 적용해보면 태스크를 실행하기 위한 API를 시행하였을 때, 태스크를 실행하 수 있을 만큼의 자원을 확보하지 못한다면 provisioning 상태로 들어가게 된다. (실패가 아니다)
단, 클러스터가 스케일링을 관리할 수 있는 권한을 가지고 있을 때에만, 프로비전으로 들어가며 그렇지 않은 경우는 실패가 된다.
$M$의 값을 어떻게 계산해야 하는가? 프로비전 상탱에 있는 태스크가 하나 이상이라고 할 때, 당연히 $M>N$을 만족하게 된다. 하지만 얼마나 커야하는가?
가장 이상적인 방법은 모든 태스크를 돌리기에 부족하지도 않으며 넘치지도 않는 인스턴스 수를 띄우는 것이지만 이 방법은 실용적이지도 가능하지도 않다.
→ 각 태스크의 요구사항과 사용하는 자원을 고려할 때, 애초에 정확한 측정이 불가능하기 때문이다.
정확한 값을 계산하는 대신에 CAS는 좋은 예측을 하는 방향으로 생각한다. 따라서 CAS는 ASG를 실행하기 위한 설정을 기반으로 $M$에 근사한 근사치를 계산하게 된다.
ASG에서는 하나의 인스턴스 타입을 사용한다고 가정하자
모든 프로비전 태스크 들은 그룹화 하여 각 그룹에 정확히 같은 자원의 요구사항을 가지도록 한다.
ASG에서 설정한 인스턴스 타입과 설정은 가져온다.
t3.micro를 설정한 경우 해당 인스턴스 타입 정보를 가져온다.