Amazon ECS 태스크 크기 모범 사례

Amazon ECS 태스크 크기 모범 사례

컨테이너 크기와 태스크 크기는 모두 확장과 용량 계획에 필수적입니다. 이 글에서는 CPU와 메모리 리저베이션(reservation)과 리밋(limit)을 설정하는 방법과 모범 사례를 알아봅니다.

출처: 문서

본문

컨테이너 크기와 태스크 크기는 모두 확장과 용량 계획에 필수적입니다. Amazon ECS에서 CPU와 메모리는 용량에 사용되는 두 가지 리소스 지표입니다. CPU는 전체 vCPU의 1/1024 단위로 측정됩니다(1024 단위는 전체 vCPU 1개와 같음). 메모리는 메비바이트(mebibytes)로 측정됩니다.

태스크 정의에서 리소스 리저베이션(reservation)과 리밋(limit)을 구성할 수 있어요. 리저베이션을 구성하면 태스크가 요구하는 최소 리소스 양을 설정하는 것입니다. 태스크는 요청된 리소스 양 이상을 받습니다. 애플리케이션은 선언한 리저베이션보다 더 많은 CPU나 메모리를 사용할 수 있을 수도 있습니다. 그러나 이는 또한 선언한 리밋의 적용을 받습니다. 리저베이션 양보다 많이 사용하는 것을 버스팅(bursting)이라고 합니다.

Amazon ECS에서 리저베이션은 보장됩니다. 예를 들어 Amazon EC2 인스턴스로 용량을 제공한다면, Amazon ECS는 리저베이션을 충족할 수 없는 인스턴스에는 태스크를 배치하지 않아요.

리밋(limit)은 컨테이너 또는 태스크가 사용할 수 있는 최대 CPU 유닛 또는 메모리 양입니다. 이 리밋보다 더 많은 CPU를 사용하려는 시도는 스로틀링(throttling)이 발생합니다. 더 많은 메모리를 사용하려는 시도는 컨테이너가 중지됩니다.

이 값을 선택하는 것은 어려울 수 있어요. 애플리케이션에 가장 적합한 값은 애플리케이션의 리소스 요구 사항에 크게 의존하기 때문입니다. 애플리케이션을 부하 테스트(load testing)하는 것이 성공적인 리소스 요구 계획과 애플리케이션 요구 사항을 더 잘 이해하는 열쇠입니다.

무상태 애플리케이션 (Stateless applications)

로드 밸런서 뒤의 애플리케이션처럼 수평으로 확장되는 무상태 애플리케이션의 경우, 먼저 애플리케이션이 요청을 서비스할 때 소비하는 메모리 양을 결정할 것을 권장합니다. 이를 위해 ps나 top 같은 전통적인 도구나 CloudWatch Container Insights 같은 모니터링 솔루션을 사용할 수 있어요.

CPU 리저베이션을 결정할 때는 비즈니스 요구 사항을 충족하기 위해 애플리케이션을 어떻게 확장할지 고려하세요. 256 CPU 유닛(또는 1/4 vCPU) 같은 더 작은 CPU 리저베이션을 사용하면 비용을 최소화하는 세분화된 방식으로 스케일 아웃할 수 있어요. 하지만 상당한 수요 급증을 충족할 만큼 빠르게 확장되지 않을 수도 있습니다. 더 큰 CPU 리저베이션을 사용하면 더 빠르게 스케일 인·아웃하여 수요 급증을 더 빨리 맞출 수 있어요. 하지만 더 큰 CPU 리저베이션은 비용이 더 많이 듭니다.

기타 애플리케이션 (Other applications)

싱글턴 워커(singleton worker)나 데이터베이스 서버처럼 수평으로 확장되지 않는 애플리케이션의 경우 사용 가능한 용량과 비용이 가장 중요한 고려 사항입니다. 서비스 수준 목표를 충족하기 위해 트래픽을 서비스하는 데 필요한 양을 부하 테스트가 알려주는 바에 따라 메모리와 CPU 양을 선택해야 합니다. Amazon ECS는 애플리케이션이 적절한 용량을 가진 호스트에 배치되도록 보장합니다.

더 알아보기 (Learn more)

  • 태스크 정의에서 리소스 예약과 리밋을 구성하는 방법에 대한 자세한 내용은 AWS 개발자 가이드의 관련 문서를 참고하세요.