ECS를 활용한 배포-CAS/ASG(2)(2022.04.14~2022.04.14)

Service Autoscaling? Instance Autoscaling

ECS와 관련된 Autoscaling에서 가장 헷갈렸던 부분이다. 지금까지 흔히 내가 생각한 autoscaling이란 필요한 만큼의 EC2인스턴스를 스케일링 하는 것이었다.

하지만 ECS에서는 컨테이너 인스턴스 내부에 태스크가 실행되고 상황에 따라서 태스크를 추가로 스케일링 할 필요가 있다. 따라서 스케일링의 개념을 두가지로 나눌 필요가 있다.

서비스를 생성할 때, auto scaling이라는 항목에서 조정할 수 있는 내역으로, 특정 조건에 의해서 인스턴스 내부에서 실행되고 있는 서비스(태스크)를 확장할 수 있도록 하는 옵션이다.

Untitled

즉, 이 옵션을 인스턴스의 스케일링 옵션으로 착각해서는 안된다. 스케일링을 진행하는 옵션은 CPU혹은 메모리 사용량과 같이 한계치를 지정하여 특정 상황을 넘겼을 때, 자동을 태스크가 증식되도록 하여 분산 처리를 하게되는 것이다.

ECS에서 볼 수 있는 지표

서비스 오토스케일링이란 컨테이너 인스턴스에 남아있는 자원을 존재할 때, 특정 조건을 충족하는 상황에서 서비스를 추가로 늘리는 작업을 의미한다.

인스턴스 자체의 사용용량이 많아지는 상황에서는 인스턴스 내부에 더이상 태스크를 증식할 공간이 없거나 여유분을 유지해야하는 경우 ECS는 CAS 내부에서 Capcity Provider를 이용해서 ASG을 관리하게 된다.

기존의 ASG의 경우는 로드밸런서와 연결하여 특정 조건에 따라서 스케일링을 하도록 조정을 할 수 있지만 ECS를 사용하는 상황에서는 ECS가 조건에 따라 ASG를 관리하게 된다. 자세한 사항은 이전 포스트를 참고하자

<aside> <img src="https://img.icons8.com/ios/250/FFFFFF/info.png" alt="https://img.icons8.com/ios/250/FFFFFF/info.png" width="40px" /> CAS와 ASG 참고자료(Capcity Provider가 작동하는 방식)

</aside>

배포를 하는 상황에서는 BLUE/GREEN을 위해서 같은 태스크를 띄우고 트래픽을 조절하여 교체를 하게된다. 언뜻 보기에는 이 방법도 ECS의 스케일링을 이용해서 해결할 수 있어보이지만 배포를 하는 상황과 스케일링을 하는 상황은 엄밀히 말하면 분리되어 있다.

스케일링 상황: 서비스를 새로 생성하여 태스크를 추가하는 경우. 새로운 태스크가 추가되로 PROVISIONING상태로 들어가게 된다.
배포: 서비스를 업데이트하는 상황으로 기존의 존재하던 서비스의 태스크를 교체하기 위해서 컨테이너 인스턴스의 자원을 판단하고 상태 비율에 따라서 태스크를 싱행한다.

CodeDeploy를 이용하는 것도 마찬가지로 진행이되며 Capacity Provider를 기본적으로는 사용하지 않기 때문에 새롭게 생성될 태스크(대체본)를 PROVISIONING 상태로 올리지 않고 STOPPED이 된다.

가장 핵심은 CodeDeploy를 이용할 때, ECS의 capacity provider를 하용하도록 하는 것이다. 기본적인 옵션은 appspec.yaml에서 추가할 수 있다.

CapacityProviderStrategy:
	- CapacityProvider: "<MyCapacityProviderNameFromECSCluster>"
	  Base: 0
	  Weight: 1