# Amazon ECS 오토 스케일링 및 용량 관리 모범 사례
Amazon ECS에서 모든 크기의 컨테이너화된 애플리케이션 워크로드를 실행할 수 있습니다. 여기에는 최소한의 테스트 환경과 글로벌 규모로 운영되는 대규모 프로덕션 환경이 포함됩니다.
다른 모든 AWS 서비스와 같이 Amazon ECS에서는 사용한 만큼만 비용을 지불합니다. 애플리케이션을 적절하게 설계하면 필요할 때 필요한 리소스만 소모하여 비용을 절감할 수 있습니다.
다음 권장 사항은 Amazon ECS 워크로드를 실행하여 서비스 수준 목표를 충족하는 동시에 비용 효율적으로 운영하는 방법을 보여줍니다.
**Topics**
+ [Amazon ECS에 대한 태스크 크기 결정](capacity-tasksize-best-practice.md)
+ [Amazon ECS 서비스 오토 스케일링 최적화](capacity-autoscaling-best-practice.md)
+ [Amazon ECS 용량 및 가용성](capacity-availability-best-practice.md)
+ [Amazon ECS 클러스터 용량](capacity-cluster-best-practice.md)
+ [Amazon ECS에 대한 Fargate 태스크 크기 선택](fargate-task-size-best-practice.md)
+ [Amazon EC2의 용량 공급자를 사용하여 Amazon ECS 클러스터 용량 프로비저닝 속도 향상](capacity-cluster-speed-up-ec2-best-practice.md)
# Amazon ECS에 대한 태스크 크기 결정
Amazon ECS에서 컨테이너를 배포할 때 가장 중요한 선택 사항 중 하나는 컨테이너와 태스크 크기입니다. 컨테이너와 태스크 크기 모두 규모 조정 및 용량 계획에 필수적입니다.
Amazon ECS는 CPU 및 메모리와 같이 용량에 대해 두 가지 리소스 지표를 사용합니다. Amazon ECS는 CPU를 전체 vCPU의 1/1,024 단위로 측정합니다(여기서 1,024 단위는 전체 vCPU 1개와 같음). Amazon ECS는 메모리를 메가바이트 단위로 측정합니다.
작업 정의에서 리소스 예약 및 제한을 선언할 수 있습니다.
예약을 선언하는 경우 태스크에 필요한 최소 리소스 크기를 선언합니다. 태스크는 적어도 요청한 리소스 크기를 수신합니다. 애플리케이션은 선언한 예약보다 더 많은 CPU 또는 메모리를 사용할 수 있습니다. 하지만 이 경우 함께 선언한 제한이 적용됩니다.
예약 크기를 초과하여 사용하는 것을 버스팅이라고 합니다. 버스팅은 애플리케이션이 예약한 것보다 더 많은 리소스를 사용하지만 선언된 제한 내에서 유지됨을 의미합니다. Amazon ECS는 예약을 보장합니다. 예를 들어 Amazon EC2 인스턴스를 사용하여 용량을 제공하는 경우 Amazon ECS는 예약을 충족할 수 없는 인스턴스에 태스크를 배치하지 않습니다.
제한은 컨테이너 또는 작업에서 사용할 수 있는 CPU 단위 또는 메모리의 최대 크기입니다. 컨테이너에서 이 제한보다 많은 CPU를 사용하려고 하면 Amazon ECS가 이를 스로틀링합니다. 컨테이너에서 이 제한보다 많은 메모리를 사용하려고 하면 Amazon ECS가 컨테이너를 중지합니다.
이 값을 선택하는 것은 어려울 수 있습니다. 애플리케이션에 가장 적합한 값은 애플리케이션의 리소스 요구 사항에 따라 크게 달라집니다.
성공적인 리소스 요구 사항 계획을 수립하려면 애플리케이션 부하 테스트가 매우 중요합니다. 부하 테스트는 애플리케이션의 요구 사항을 더 잘 이해하는 데 도움이 됩니다.
## 상태 비저장 애플리케이션
로드 밸런서를 사용하는 애플리케이션과 같이 수평적으로 규모를 조정하는 상태 비저장 애플리케이션의 경우 먼저 애플리케이션이 요청을 지원할 때 소비하는 메모리 크기를 결정하는 것이 좋습니다.
이를 위해 `ps` 또는 `top`과 같은 기존 도구를 사용할 수 있습니다. CloudWatch Container Insights와 같은 모니터링 솔루션을 사용할 수도 있습니다.
CPU 예약을 결정할 때 비즈니스 요구 사항에 맞게 애플리케이션 규모를 조정하는 방법을 고려하세요.
256개의 CPU 단위(또는 1/4 vCPU)와 같은 더 작은 CPU 예약을 사용하여 비용을 최소화하는 세분화된 방식으로 스케일 아웃할 수 있습니다. 하지만 급증하는 수요를 감당할 만큼 빠르게 규모가 조정되지 않을 수도 있습니다.
더 큰 CPU 예약을 사용하면 보다 빠르게 스케일 인 및 스케일 아웃할 수 있습니다. 그러면 수요 급증에 더 빠르게 대응할 수 있습니다. 하지만 CPU 예약이 커지면 비용이 증가합니다.
## 기타 애플리케이션
싱글톤 작업자 또는 데이터베이스 서버와 같이 수평적으로 규모가 조정되지 않는 애플리케이션의 경우 사용 가능한 용량과 비용이 가장 중요한 고려 사항입니다.
서비스 수준 목표를 달성하기 위해 트래픽을 처리하려면 부하 테스트에서 표시하는 필요한 수준에 따라 메모리와 CPU 크기를 선택합니다. Amazon ECS는 적절한 용량을 갖춘 호스트에 애플리케이션을 배치하도록 보장합니다.
# Amazon ECS 서비스 오토 스케일링 최적화
Amazon ECS 서비스는 관리형 작업 모음입니다. 각 서비스에는 관련 작업 정의, 원하는 작업 수 및 선택적 배치 전략이 있습니다.
Amazon ECS 서비스 오토 스케일링은 Application Auto Scaling 서비스를 통해 구현됩니다. Application Auto Scaling은 CloudWatch 지표를 지표 조정 소스로 사용합니다. 또한 CloudWatch 경보를 사용하여 서비스를 스케일 인 또는 스케일 아웃할 시기에 대한 임계값을 설정합니다.
규모 조정에 대한 임계치를 제공합니다. *대상 추적 규모 조정*이라고 하는 지표 대상을 설정할 수 있습니다. *단계 규모 조정*이라고 하는 임계치를 지정할 수도 있습니다.
Application Auto Scaling을 구성한 후에는 서비스에 적절한 원하는 태스크 수를 지속적으로 계산합니다. 또한 스케일 인 또는 스케일 아웃하여 원하는 작업 수가 변경될 경우 이를 Amazon ECS에 알립니다.
서비스 Auto Scaling을 효과적으로 사용하려면 적절한 조정 지표를 선택해야 합니다. 다음 섹션에서 지표를 선택하는 방법을 설명합니다.
## 애플리케이션 특성 지정
애플리케이션 규모를 적절하게 조정하려면 애플리케이션을 스케일 인해야 하는 조건과 스케일 아웃해야 하는 시기를 알아야 합니다.
기본적으로 수요가 용량을 초과할 것으로 예상되는 경우 애플리케이션을 스케일 아웃해야 합니다. 반대로, 리소스가 수요를 초과할 경우 비용을 절약하기 위해 애플리케이션을 스케일 인할 수 있습니다.
### 사용률 지표 식별
효과적으로 규모를 조정하려면 사용률 또는 포화도를 나타내는 지표를 식별해야 합니다. 이 지표는 조정에 유용하도록 다음 속성을 보여주어야 합니다.
+ 지표는 수요와 상관되어야 합니다. 리소스가 일정하게 유지되지만 수요가 변경되면 지표 값도 변경되어야 합니다. 수요가 증가하거나 감소하면 지표가 증가하거나 감소해야 합니다.
+ 지표 값은 용량에 비례하여 스케일 인되어야 합니다. 수요가 일정할 때 리소스를 더 추가하면 지표 값이 비례적으로 변해야 합니다. 따라서 작업 수를 두 배로 늘리면 지표가 50% 감소해야 합니다.
사용률 지표를 식별하는 가장 좋은 방법은 스테이징 환경과 같은 사전 프로덕션 환경에서 부하 테스트를 수행하는 것입니다. 상용 및 오픈 소스 부하 테스트 솔루션이 널리 사용됩니다. 이러한 솔루션은 일반적으로 합성 부하를 생성하거나 실제 사용자 트래픽을 시뮬레이션할 수 있습니다.
부하 테스트 프로세스를 시작하려면 먼저 애플리케이션의 사용률 지표에 대한 대시보드를 빌드해야 합니다. 이러한 지표로, CPU 사용률, 메모리 사용률, I/O 작업, I/O 대기열 길이, 네트워크 처리량이 포함됩니다. CloudWatch Container Insights와 같은 서비스를 통해 이러한 지표를 수집할 수 있습니다. Amazon Managed Service for Prometheus를 Amazon Managed Grafana와 함께 사용하여 수집할 수도 있습니다. 이 프로세스 중에 애플리케이션의 응답 시간이나 작업 완료율에 대한 지표를 수집하고 도표를 작성해야 합니다.
부하 테스트를 수행할 때 작은 요청이나 느린 작업 삽입 속도로 시작합니다. 애플리케이션이 워밍업될 수 있도록 몇 분 동안 이 속도를 일정하게 유지합니다. 그런 다음, 속도를 천천히 올리고 몇 분 동안 일정하게 유지합니다. 이 주기를 반복하고 애플리케이션의 응답 또는 완료 시간이 너무 느려 서비스 수준 목표(SLO)를 충족하지 못하면 매번 비율을 높입니다.
부하 테스트를 수행하는 동안 각 사용률 지표를 살펴봅니다. 부하와 함께 증가하는 지표는 가장 적합한 사용률 지표로 사용할 수 있는 가장 좋은 후보입니다.
다음으로, 포화 상태에 도달한 리소스를 식별합니다. 동시에 사용률 지표를 살펴보고 어떤 지표가 높은 수준에서 먼저 평준화되는지 확인합니다. 또는 피크에 도달한 후 애플리케이션과 먼저 충돌하는 지표를 살펴봅니다. 예를 들어 부하를 추가할 때 CPU 사용률이 0%에서 70%\$180%로 증가하는 경우 부하를 더 추가한 후에도 이 수준을 유지한다면 CPU는 포화 상태일 수 있습니다. CPU 아키텍처에 따라 100%에 도달하지 못할 수도 있습니다. 예를 들어 부하를 추가할 때 메모리 사용률이 증가하다가 애플리케이션이 작업 또는 Amazon EC2 인스턴스 메모리 제한에 도달했을 때 갑자기 애플리케이션 충돌이 발생한다고 가정합니다. 이 상황에서는 메모리가 완전히 소모되었을 가능성이 큽니다. 애플리케이션에서 여러 리소스를 사용할 수 있습니다. 따라서 가장 먼저 고갈되는 리소스를 나타내는 지표를 선택합니다.
마지막으로 태스크 또는 Amazon EC2 인스턴스 수를 두 배로 늘린 후 부하 테스트를 다시 시도합니다. 주요 지표가 이전보다 절반 정도 증가하거나 감소한다고 가정합니다. 이 경우 지표는 용량에 비례합니다. 이는 Auto Scaling에 적합한 사용률 지표입니다.
이제 이 가상 시나리오를 고려합니다. 애플리케이션의 부하 테스트를 수행한 결과, 초당 요청 100개에서 CPU 사용률이 결국 80%에 도달한다고 가정합니다. 부하를 더 추가해도 CPU 사용률은 더 이상 증가하지 않습니다. 하지만 이렇게 하면 애플리케이션 응답 속도가 느려집니다. 그런 다음, 부하 테스트를 다시 실행하여 작업 수를 두 배로 늘리되 속도를 이전 피크 값으로 유지합니다. 평균 CPU 사용률이 약 40%로 떨어지면 평균 CPU 사용률은 조정 지표로 사용하기에 적합합니다. 반면, 작업 수를 늘린 후에도 CPU 사용률이 80%로 유지되면 평균 CPU 사용률은 적절한 조정 지표가 아닙니다. 이 경우 적절한 지표를 찾으려면 더 많은 연구가 필요합니다.
### 공통 애플리케이션 모델 및 조정 속성
모든 종류의 소프트웨어를 AWS에서 실행할 수 있습니다. 자체 개발되는 워크로드도 많지만, 널리 사용되는 오픈 소스 소프트웨어에 기반하는 워크로드도 있습니다. 어디에서 생성되었든 서비스의 몇 가지 일반적인 디자인 패턴을 확인할 수 있습니다. 효과적인 규모 조정 방법은 대부분 패턴에 따라 달라집니다.
#### 효율적인 CPU 의존 서버
효율적인 CPU 의존 서버는 CPU 및 네트워크 처리량 이외의 리소스를 거의 사용하지 않습니다. 각 요청은 애플리케이션에서만 처리할 수 있습니다. 요청은 데이터베이스와 같은 다른 서비스에 의존하지 않습니다. 애플리케이션은 수십만 개의 동시 요청을 처리할 수 있으며, 이를 위해 여러 CPU를 효율적으로 활용할 수 있습니다. 각 요청은 메모리 오버헤드가 적은 전용 스레드에서 처리되거나 각 CPU에서 요청을 지원하는 비동기 이벤트 루프가 실행되기도 합니다. 애플리케이션의 각 복제본은 요청을 균등하게 처리할 수 있습니다. CPU 이전에 고갈될 수 있는 유일한 리소스는 네트워크 대역폭입니다. CPU 의존 서비스에서는 피크 처리량에서도 메모리 사용률이 사용 가능한 리소스의 일부에 불과합니다.
이 유형의 애플리케이션에 대해 CPU 기반 오토 스케일링을 사용할 수 있습니다. 애플리케이션은 조정 측면에서 최대한의 유연성을 제공합니다. 여기에 더 큰 Amazon EC2 인스턴스 또는 Fargate vCPU를 제공하여 수직적으로 규모를 조정할 수 있습니다. 또한 복제본을 더 추가하여 수평적으로 규모를 조정할 수도 있습니다. 복제본을 더 추가하거나 인스턴스 크기를 두 배로 늘리면 용량 대비 평균 CPU 사용률이 절반으로 줄어듭니다.
이 애플리케이션에 Amazon EC2 용량을 사용하는 경우 `c5` 또는 `c6g` 패밀리와 같은 컴퓨팅 최적화 인스턴스에 배치하는 방법을 고려합니다.
#### 효율적인 메모리 의존 서버
효율적인 메모리 의존 서버는 요청당 상당한 양의 메모리를 할당합니다. 최대 동시성에서(처리량이 반드시 필요하지 않음) CPU 리소스가 고갈되기 전에 메모리가 고갈됩니다. 요청이 종료되면 요청에 연결된 메모리를 비웁니다. 사용 가능한 메모리가 있는 한, 추가 요청을 수락할 수 있습니다.
이 유형의 애플리케이션에 대해 메모리 기반 오토 스케일링을 사용할 수 있습니다. 애플리케이션은 조정 측면에서 최대한의 유연성을 제공합니다. 여기에 더 큰 Amazon EC2 또는 Fargate 메모리를 제공하여 모두 수직적으로 규모를 조정할 수 있습니다. 또한 복제본을 더 추가하여 수평적으로 규모를 조정할 수도 있습니다. 복제본을 더 추가하거나 인스턴스 크기를 두 배로 늘리면 용량 대비 평균 메모리 사용률이 절반으로 줄어들 수 있습니다.
이 애플리케이션에 Amazon EC2 용량을 사용하는 경우 `r5` 또는 `r6g` 패밀리와 같은 메모리 최적화 인스턴스에 배치하는 방법을 고려합니다.
일부 메모리 의존 애플리케이션은 요청이 종료될 때 요청에 연결된 메모리를 비우지 않으므로 동시성이 줄어도 사용되는 메모리가 줄지 않습니다. 이 경우 메모리 기반 규모 조정을 사용하지 않는 것이 좋습니다.
#### 작업자 기반 서버
작업자 기반 서버는 각 개별 작업자 스레드에 대해 하나의 요청을 차례로 처리합니다. 작업자 스레드는 POSIX 스레드와 같은 경량 스레드일 수 있습니다. UNIX 프로세스처럼 가중치가 더 큰 스레드일 수도 있습니다. 스레드가 무엇이든 애플리케이션이 지원할 수 있는 최대 동시성은 항상 존재합니다. 일반적으로 동시성 제한은 사용 가능한 메모리 리소스에 비례하여 설정됩니다. 동시성 제한에 도달하면 애플리케이션은 추가 요청을 백로그 대기열에 배치합니다. 백로그 대기열에서 오버플로가 발생하면 애플리케이션은 추가 수신 요청을 즉시 거부합니다. 이 패턴에 맞는 일반적인 애플리케이션으로, Apache 웹 서버와 Gunicorn이 있습니다.
일반적으로 요청 동시성은 이 애플리케이션 규모를 조정하는 데 가장 적합한 지표입니다. 각 복제본에는 동시성 제한이 있으므로 평균 제한에 도달하기 전에 스케일 아웃하는 것이 중요합니다.
요청 동시성 지표를 확보하는 가장 좋은 방법은 애플리케이션에서 해당 지표를 CloudWatch에 보고하도록 하는 것입니다. 애플리케이션의 각 복제본은 동시 요청 수를 사용자 지정 지표로 매우 자주 게시할 수 있습니다. 빈도는 최소 1분에 한 번으로 설정하는 것이 좋습니다. 여러 보고서가 수집된 후 평균 동시성을 조정 지표로 사용할 수 있습니다. 이 지표는 전체 동시성을 가져와 이 값을 복제본 수로 나누어 계산합니다. 예를 들어, 총 동시성이 1,000이고 복제본 수가 10개인 경우 평균 동시 실행성은 100입니다.
애플리케이션이 Application Load Balancer를 사용하는 경우 로드 밸런서의 `ActiveConnectionCount` 지표를 조정 지표 요소로 사용할 수도 있습니다. 평균값을 구하려면 `ActiveConnectionCount` 지표를 복제본 수로 나누어야 합니다. 원시 개수 값과는 반대로, 규모 조정에 평균값을 사용해야 합니다.
이 설계가 가장 잘 작동하려면 낮은 요청 빈도에서 응답 지연 시간의 표준 편차가 작아야 합니다. 수요가 적은 기간에는 대부분의 요청에 짧은 시간으로 응답하고 평균 응답 시간보다 훨씬 오래 걸리는 요청은 많지 않은 것이 좋습니다. 평균 응답 시간은 95 백분위수 응답 시간에 가까워야 합니다. 그렇지 않으면 결과적으로 대기열 오버플로가 발생할 수 있습니다. 이로 인해 오류가 발생합니다. 오버플로 위험을 줄이려면 필요한 경우 추가 복제본을 제공하는 것이 좋습니다.
#### 대기 중인 서버
대기 중인 서버는 각 요청에 대해 일부 처리를 수행하지만 작동을 위해 하나 이상의 다운스트림 서비스에 크게 의존합니다. 컨테이너 애플리케이션은 종종 데이터베이스 및 기타 API 서비스와 같은 다운스트림 서비스를 많이 사용합니다. 특히 용량이 크거나 동시성이 높은 시나리오에서는 이러한 서비스가 응답하는 데 다소 시간이 걸릴 수 있습니다. 이러한 애플리케이션은 CPU 리소스를 거의 사용하지 않고 가용 메모리 측면에서 최대 동시성을 활용하는 경향이 있기 때문입니다.
대기 중인 서비스는 애플리케이션의 설계 방식에 따라 메모리 의존 서버 패턴 또는 작업자 의존 서버 패턴 중 하나에 적합합니다. 애플리케이션의 동시성이 메모리로만 제한되는 경우 평균 메모리 사용률을 조정 지표로 사용해야 합니다. 애플리케이션의 동시성이 작업자 제한을 기반으로 하는 경우 평균 동시성을 조정 지표로 사용해야 합니다.
#### Java 기반 서버
Java 기반 서버가 CPU에 의존하고 CPU 리소스에 비례하여 조정되는 경우 효율적인 CPU 의존 서버 패턴에 적합할 수 있습니다. 이 경우 평균 CPU 사용률이 조정 지표로 적절할 수 있습니다. 하지만 많은 Java 애플리케이션은 CPU에 의존하지 않으므로 조정하기 어렵습니다.
최고의 성능을 위해 Java Virtual Machine(JVM) 힙에 메모리를 최대한 많이 할당하는 것이 좋습니다. Java 8 업데이트 191 이상을 포함한 최신 버전의 JVM에서는 컨테이너에 맞도록 힙 크기를 최대한 크게 자동으로 설정합니다. 즉, Java에서 메모리 사용률이 애플리케이션 사용률에 비례하는 경우는 거의 없습니다. 요청 빈도와 동시성이 증가해도 메모리 사용률은 일정하게 유지됩니다. 따라서 메모리 사용률에 따라 Java 기반 서버를 확장하지 않는 것이 좋습니다. 대신 일반적으로 CPU 사용률을 기준으로 조정하는 것이 좋습니다.
Java 기반 서버에서 CPU를 모두 소모하기 전에 힙이 고갈되는 경우도 있습니다. 애플리케이션이 동시성이 높아 힙이 고갈되기 쉬운 경우 평균 연결이 가장 좋은 조정 지표입니다. 애플리케이션이 높은 처리량에서 힙이 고갈되기 쉬운 경우 평균 요청 속도가 가장 좋은 조정 지표입니다.
#### 기타 가비지 수집 런타임을 사용하는 서버
많은 서버 애플리케이션은 .NET 및 Ruby와 같은 가비지 수집을 수행하는 런타임을 기반으로 합니다. 이러한 서버 애플리케이션은 앞서 설명한 패턴 중 하나에 적합할 수 있습니다. 그러나 Java와 마찬가지로 메모리를 기반으로 이러한 애플리케이션은 조정하지 않는 것이 좋습니다. 관찰된 평균 메모리 사용률이 처리량이나 동시성과 관련되지 않은 경우가 많기 때문입니다.
이러한 애플리케이션의 경우 애플리케이션이 CPU에 의존하는 경우 CPU 사용률을 높이는 것이 좋습니다. 그렇지 않으면 부하 테스트 결과에 따라 평균 처리량이나 평균 동시성을 기준으로 조정하는 것이 좋습니다.
#### 작업 프로세서
많은 워크로드에는 비동기 작업 처리가 포함됩니다. 여기에는 요청을 실시간으로 수신하지 않고 대신 작업 대기열을 구독하여 작업을 수신하는 애플리케이션이 포함됩니다. 이러한 유형의 애플리케이션에서 적절한 조정 지표는 거의 항상 대기열 깊이입니다. 대기열 증가는 보류 중인 작업이 처리 용량을 초과한다는 의미이고, 빈 대기열은 수행할 작업보다 용량이 더 많다는 의미입니다.
Amazon SQS 및 Amazon Kinesis Data Streams와 같은 AWS 메시징 서비스에서는 조정에 사용할 수 있는 CloudWatch 지표를 제공합니다. Amazon SQS의 경우 `ApproximateNumberOfMessagesVisible`이 가장 좋은 지표입니다. Kinesis Data Streams의 경우 Kinesis Client Library(KCL)에서 게시한 `MillisBehindLatest` 지표를 사용하는 방법을 고려합니다. 이 지표를 조정에 사용하기 전에 모든 소비자를 대상으로 이 지표의 평균을 구해야 합니다.
# Amazon ECS 용량 및 가용성
애플리케이션 가용성은 오류 없는 환경을 제공하고 애플리케이션 지연 시간을 최소화하는 데 매우 중요합니다. 가용성은 액세스할 수 있고 수요를 충족할 수 있는 충분한 용량의 리소스를 확보하는 데 달려 있습니다. AWS는 가용성을 관리하기 위한 몇 가지 메커니즘을 제공합니다. Amazon ECS에 호스팅하는 애플리케이션의 경우 여기에 오토 스케일링 및 가용 영역(AZ)이 포함됩니다. Auto Scaling은 정의한 지표를 기반으로 태스크 또는 인스턴스 수를 관리하는 반면, 가용 영역을 사용하면 격리되어 있지만 지리적으로 가까운 위치에서 애플리케이션을 호스팅할 수 있습니다.
태스크 크기와 마찬가지로 용량과 가용성에는 반드시 고려해야 할 몇 가지 단점이 있습니다. 이상적으로는 용량이 수요에 완벽하게 일치하는 것이 좋습니다. 낮은 지연 시간과 오류율 등 서비스 수준 목표(SLO)를 충족하기 위해 요청을 처리하고 작업을 처리할 수 있는 충분한 용량을 언제나 확보할 수 있습니다. 용량이 너무 높아서 과도한 비용이 발생하거나, 너무 낮아서 지연 시간과 오류율이 높아져서는 안 됩니다.
Auto Scaling은 잠재적인 프로세스입니다. 먼저 CloudWatch는 실시간 지표를 수신해야 합니다. 그런 다음 CloudWatch는 분석을 위해 지표를 집계해야 하며 지표의 세분성에 따라 최대 몇 분이 걸릴 수 있습니다. CloudWatch는 지표를 경보 임계값과 비교하여 리소스 부족 또는 초과를 식별합니다. 불안정성을 방지하려면 설정된 임계치를 넘고 몇 분 후에 경보가 울리도록 구성해야 합니다. 또한 새 태스크를 프로비저닝하고 더 이상 필요하지 않은 태스크를 종료하는 데에도 시간이 걸립니다.
시스템의 이러한 잠재적인 지연 때문에 오버프로비저닝을 통해 여유 공간을 유지해야 합니다. 오버프로비저닝은 단기 수요 버스트를 수용하는 데 도움이 될 수 있습니다. 또한 애플리케이션이 포화 상태에 도달하지 않고 추가 요청을 처리하는 데 도움이 됩니다. 일반적으로 규모 조정 목표치를 사용률의 60\$180% 사이로 설정하는 것을 권장합니다. 이렇게 하면 여전히 추가 용량을 프로비저닝하는 동안 애플리케이션이 급증하는 추가 수요를 더 잘 처리할 수 있습니다.
오버프로비저닝을 권장하는 또 다른 이유는 가용 영역 장애에 신속하게 대응하기 위해서입니다. AWS에서는 프로덕션 워크로드를 여러 가용 영역에서 제공할 것을 권장합니다. 이는 가용 영역 장애가 발생하더라도 나머지 가용 영역에서 실행 중인 태스크가 계속해서 수요를 충족할 수 있기 때문입니다. 애플리케이션이 두 개의 가용 영역에서 실행되는 경우 일반 태스크 수를 두 배로 늘려야 합니다. 이는 잠재적인 장애 발생 시 즉시 용량을 제공할 수 있도록 하기 위한 것입니다. 애플리케이션이 3개의 가용 영역에서 실행되는 경우 일반 태스크 수의 1.5배를 실행하는 것이 좋습니다. 즉, 일반적인 제공에 필요한 태스크 2개당 3개의 태스크를 실행합니다.
## 규모 조정 속도 극대화
Auto Scaling은 적용되는 데 시간이 걸리는 반응형 프로세스입니다. 그러나 스케일 아웃하는 데 필요한 시간을 최소화하는 데 도움이 되는 몇 가지 방법이 있습니다.
**이미지 크기를 최소화하세요.** 이미지가 클수록 이미지 저장소에서 다운로드하고 압축을 푸는 데 시간이 오래 걸립니다. 따라서 이미지 크기를 더 작게 유지하면 컨테이너를 시작하는 데 필요한 시간이 줄어듭니다. 이미지 크기를 줄이려면 다음 구체적인 권장 사항을 따르세요.
+ 정적 바이너리를 빌드하거나 Golang을 사용할 수 있는 경우 이미지 `FROM` 스크래치를 빌드하고 결과 이미지에 바이너리 애플리케이션만 포함하세요.
+ Amazon Linux 또는 Ubuntu와 같은 업스트림 배포판 공급업체의 최소화된 기본 이미지를 사용하세요.
+ 최종 이미지에 빌드 아티팩트를 포함하지 마세요. 다단계 빌드를 사용하는 것이 도움이 될 수 있습니다.
+ 가능하다면 `RUN` 단계를 간소화합니다. 각 `RUN` 단계는 새 이미지 레이어를 생성하므로 레이어를 다운로드하는 데 추가 왕복 시간이 소요됩니다. 여러 명령이 `&&`로 결합된 단일 `RUN` 단계는 여러 `RUN` 단계가 있는 경우보다 레이어 수가 적습니다.
+ ML 추론 데이터와 같은 데이터를 최종 이미지에 포함하려면 시작하고 트래픽 제공을 시작하는 데 필요한 데이터만 포함하세요. 서비스에 영향을 주지 않고 Amazon S3 또는 기타 스토리지에서 온디맨드 방식으로 데이터를 가져오는 경우 해당 위치에 데이터를 저장하세요.
**이미지를 가까이 두세요.** 네트워크 지연 시간이 길수록 이미지를 다운로드하는 데 시간이 더 오래 걸립니다. 워크로드가 있는 것과 동일한 AWS 리전의 리포지토리에 이미지를 호스팅하세요. Amazon ECR은 Amazon ECS를 사용할 수 있는 모든 리전에서 사용할 수 있는 고성능 이미지 리포지토리입니다. 컨테이너 이미지를 다운로드하기 위해 인터넷이나 VPN 링크를 거치지 마세요. 동일한 리전에서 이미지를 호스팅하면 전반적인 신뢰성이 향상됩니다. 다른 리전의 네트워크 연결 문제 및 가용성 문제의 위험을 완화합니다. 또는 Amazon ECR 리전 간 복제를 구현하여 이를 지원할 수도 있습니다.
**로드 밸런서 상태 확인 임계값을 줄입니다.** 로드 밸런서는 애플리케이션에 트래픽을 보내기 전에 상태 확인을 수행합니다. 대상 그룹에 대한 기본 상태 확인 구성은 90초 이상 걸릴 수 있습니다. 이 과정에서 로드 밸런서는 상태를 확인하고 요청을 수신합니다. 상태 확인 간격과 임계값 수를 낮추면 애플리케이션이 트래픽을 더 빠르게 수용하고 다른 태스크에 대한 로드를 줄일 수 있습니다.
**콜드 스타트 성능을 고려하세요.** Java와 같은 일부 애플리케이션은 JIT(Just-In-Time) 컴파일을 수행하는 런타임을 사용합니다. 컴파일 프로세스가 시작될 때 애플리케이션 성능을 확인할 수 있습니다. 해결 방법은 워크로드에서 지연 시간이 중요한 부분을 콜드 스타트 성능 저하를 부과하지 않는 언어로 다시 작성하는 것입니다.
**타겟 추적 규모 조정 정책이 아닌 단계 규모 조정 정책을 사용하세요.** Amazon ECS 작업을 위한 여러 Application Auto Scaling 옵션이 있습니다. 대상 추적이 가장 사용하기 쉬운 모드입니다. 이 옵션을 사용하는 경우 CPU 평균 사용률과 같은 지표의 목표 값을 설정하기만 하면 됩니다. 그러면 자동 스케일러가 해당 값을 달성하는 데 필요한 작업 수를 자동으로 관리합니다. 단계 조정을 사용하면 조정 지표의 특정 임계값과 임계값을 초과했을 때 추가 또는 제거할 작업 수를 정의하므로 수요 변화에 더 빠르게 대응할 수 있습니다. 더욱이 임계값 경보를 위반하는 시간을 최소화하여 수요 변화에 매우 빠르게 대응할 수 있습니다. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [서비스 Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)을 참조하세요.
클러스터 용량을 제공하기 위해 Amazon EC2 인스턴스를 사용하는 경우 다음 권장 사항을 고려하세요.
**더 큰 Amazon EC2 인스턴스와 더 빠른 Amazon EBS 볼륨을 사용하세요.** 더 큰 Amazon EC2 인스턴스와 더 빠른 Amazon EBS 볼륨을 사용하면 이미지 다운로드 및 준비 속도를 향상할 수 있습니다. 주어진 Amazon EC2 인스턴스 패밀리 내에서 네트워크 및 Amazon EBS 최대 처리량은 인스턴스 크기가 증가함에 따라 증가합니다(예: `m5.xlarge`에서 `m5.2xlarge`로). 또한 Amazon EBS 볼륨을 사용자 지정하여 처리량과 IOPS를 늘릴 수도 있습니다. 예를 들어 `gp2` 볼륨을 사용하는 경우 기준 처리량을 더 많이 제공하는 더 큰 볼륨을 사용하세요. `gp3` 볼륨을 사용하는 경우 볼륨을 생성할 때 처리량과 IOPS를 지정하세요.
**Amazon EC2 인스턴스에서 실행되는 태스크에는 브리지 네트워크 모드를 사용하세요.** Amazon EC2에서 `bridge` 네트워크 모드를 사용하는 태스크는 `awsvpc` 네트워크 모드를 사용하는 태스크보다 빠르게 시작됩니다. `awsvpc` 네트워크 모드를 사용하는 경우 Amazon ECS는 작업을 시작하기 전에 탄력적 네트워크 인터페이스(ENI)를 인스턴스에 연결합니다. 이로 인해 지연 시간이 추가됩니다. 그러나 브리지 네트워킹을 사용하는 데에는 몇 가지 상충 관계가 있습니다. 이러한 태스크에는 자체 보안 그룹이 없으며 로드 밸런싱에 몇 가지 영향이 있습니다. 자세한 내용은 *Elastic Load Balancing 사용 설명서*의 [로드 밸런서 대상 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html)을 참조하세요.
## 수요 충격 처리
일부 애플리케이션은 갑자기 큰 수요 충격을 받기도 합니다. 이는 뉴스 이벤트, 대규모 세일, 미디어 이벤트, 입소문을 타고 매우 짧은 시간 내에 트래픽이 빠르고 크게 증가하는 기타 이벤트 등 다양한 이유로 발생합니다. 계획하지 않으면 수요가 가용 리소스를 빠르게 초과할 수 있습니다.
수요 충격을 처리하는 가장 좋은 방법은 수요 충격을 예상하고 그에 따라 계획을 세우는 것입니다. Auto Scaling에는 시간이 걸릴 수 있으므로 수요 충격이 시작되기 전에 애플리케이션을 스케일 아웃하는 것이 좋습니다. 최상의 결과를 얻으려면 공유 캘린더를 사용하는 팀 간의 긴밀한 협업을 포함하는 비즈니스 계획을 세우는 것이 좋습니다. 이벤트를 기획하는 팀은 사전에 애플리케이션 담당 팀과 긴밀하게 협력해야 합니다. 이를 통해 해당 팀은 명확한 일정 계획을 세울 수 있는 충분한 시간을 확보할 수 있습니다. 이벤트 전에 용량을 스케일 아웃하고 이벤트 후에 용량을 스케일 인하도록 예약할 수 있습니다. 자세한 내용은 [Application Auto Scaling 사용 설명서](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)의 *예약된 크기 조정*을 참조하세요.
Enterprise Support 플랜을 사용하는 경우에는 기술 계정 관리자(TAM)와도 협력하세요. TAM은 서비스 할당량을 확인하고 이벤트가 시작되기 전에 필요한 할당량을 늘리도록 할 수 있습니다. 이렇게 하면 실수로 서비스 할당량을 초과하지 않습니다. 또한 로드 밸런서와 같은 서비스를 미리 준비하여 이벤트가 원활하게 진행될 수 있도록 지원할 수 있습니다.
예상하지 못한 수요 충격을 처리하는 것은 더 어려운 문제입니다. 예상하지 못한 충격의 진폭이 충분히 크면 수요가 빠르게 용량을 초과할 수 있습니다. 또한 Auto Scaling이 반응하는 기능을 능가할 수도 있습니다. 예상하지 못한 충격에 대비하는 가장 좋은 방법은 리소스를 오버프로비저닝하는 것입니다. 언제든지 예상되는 최대 트래픽 수요를 처리할 수 있는 충분한 리소스를 확보해야 합니다.
예상하지 못한 수요 충격에 대비해 최대 용량을 유지하는 것은 비용이 많이 들 수 있습니다. 비용 영향을 완화하려면 대규모 수요 충격이 임박했음을 예측할 수 있는 선행 지표나 이벤트를 찾아보세요. 지표 또는 이벤트가 중요한 사전 알림을 안정적으로 제공하는 경우 이벤트가 발생하거나 지표가 설정한 특정 임계값을 초과하는 즉시 스케일 아웃 프로세스를 시작합니다.
애플리케이션이 예상하지 못한 갑작스러운 수요 충격을 받기 쉬운 경우에는 중요하지 않은 기능을 희생하면서도 고객을 위해 중요한 기능은 유지하는 고성능 모드를 애플리케이션에 추가하는 것을 고려하세요. 예를 들어 애플리케이션이 비용이 많이 드는 사용자 지정 응답 생성에서 정적 응답 페이지 제공으로 전환할 수 있다고 가정합니다. 이 시나리오에서는 애플리케이션의 규모를 전혀 조정하지 않고도 처리량을 크게 늘릴 수 있습니다.
마지막으로 수요 충격에 더 잘 대처하기 위해 모놀리식 서비스를 분리하는 것을 고려할 수 있습니다. 애플리케이션이 실행 비용이 많이 들고 규모 조정 속도가 느린 모놀리식 서비스인 경우 성능에 중요한 부분을 추출하거나 재작성하여 별도의 서비스로 실행할 수 있습니다. 그러면 이러한 새로운 서비스는 덜 중요한 구성 요소와 독립적으로 규모를 조정할 수 있습니다. 애플리케이션의 다른 부분과 별도로 성능에 중요한 기능을 유연하게 스케일 아웃할 수 있으면 용량을 추가하는 데 걸리는 시간을 줄이고 비용을 절약할 수 있습니다.
# Amazon ECS 클러스터 용량
여러 방법으로 Amazon ECS 클러스터에 용량을 제공할 수 있습니다. 예를 들어 Amazon EC2 인스턴스를 시작하고 Amazon ECS 컨테이너 에이전트를 사용하여 시작 시 클러스터에 등록할 수 있습니다. 그러나 조정을 직접 관리해야 하므로 이 방법은 어려울 수 있습니다. 따라서 Amazon ECS 용량 공급자를 사용하는 것이 좋습니다. 용량 공급자는 사용자를 대신해 리소스 조정을 관리합니다. Amazon EC2, Fargate, Fargate 스팟과 같이 세 가지 유형의 용량 공급자가 있습니다. Fargate 용량 공급자에 대한 자세한 내용은 [Fargate 워크로드에 대한 Amazon ECS 클러스터 워크로드](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html)를 참조하고 EC2 워크로드의 경우 [EC2 워크로드에 대한 Amazon ECS 클러스터 워크로드](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html)를 참조하세요.
Fargate 및 Fargate 스팟 용량 공급자는 사용자를 대신해 Fargate 태스크의 수명 주기를 처리합니다. Fargate는 온디맨드 용량을 제공하고 Fargate 스팟은 스팟 용량을 제공합니다. 태스크를 시작하면 Amazon ECS가 사용자를 대신해 Fargate 리소스를 프로비저닝합니다. 이 Fargate 리소스는 태스크 정의에서 선언한 태스크 수준 제한에 직접 해당하는 메모리 및 CPU 단위와 함께 제공됩니다. 각 태스크는 자체 Fargate 리소스를 수신하여 태스크와 컴퓨팅 리소스 간에 1:1 관계를 형성합니다.
Fargate 스팟에서 실행되는 태스크는 중단될 수 있습니다. 중단은 2분 경고 후에 발생합니다. 수요가 많은 기간에 발생합니다. Fargate 스팟은 배치 작업, 개발 또는 스테이징 환경과 같은 중단 방지 워크로드에 가장 적합합니다. 또한 고가용성과 짧은 지연 시간이 필요하지 않은 다른 시나리오에도 적합합니다.
Fargate 온디맨드 태스크와 함께 Fargate 스팟 태스크를 실행할 수 있습니다. 이를 함께 사용하면 저렴한 비용으로 프로비저닝 '버스트' 용량을 받을 수 있습니다.
Amazon ECS는 태스크에 대한 Amazon EC2 인스턴스 용량도 관리할 수 있습니다. 각 Amazon EC2 용량 공급자는 사용자가 지정한 Amazon EC2 Auto Scaling 그룹과 연결됩니다. Amazon EC2 용량 공급자를 사용하는 경우 클러스터 오토 스케일링은 예약된 모든 태스크를 배치할 수 있도록 Amazon EC2 Auto Scaling 그룹의 크기를 유지 관리합니다.
# Amazon ECS에 대한 Fargate 태스크 크기 선택
AWS Fargate 태스크 정의의 경우 태스크 수준에서 CPU와 메모리를 지정해야 하며 오버헤드를 고려하지 않아도 됩니다. Fargate 태스크에 대해 컨테이너 레벨에서 CPU와 메모리를 지정할 수도 있습니다. 하지만 필수는 아닙니다. 리소스 제한은 사용자가 선언한 예약 수준 이상이어야 합니다. 대부분의 경우 태스크 정의에 선언된 각 컨테이너의 예약 합계로 설정할 수 있습니다. 그런 다음 숫자를 가장 가까운 Fargate 크기로 반올림합니다. 사용 가능한 크기에 대한 자세한 내용은 [태스크 CPU 및 메모리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size)를 참조하세요.
# Amazon EC2의 용량 공급자를 사용하여 Amazon ECS 클러스터 용량 프로비저닝 속도 향상
Amazon EC2에서 Amazon ECS를 실행하는 고객은 [Amazon ECS 클러스터 오토 스케일링(CAS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html)을 활용하여 Amazon EC2 Auto Scaling(ASG) 그룹의 규모 조정을 관리할 수 있습니다. CAS를 사용하면 ASG 규모를 자동으로 조정하도록 Amazon ECS를 구성하고 태스크 실행에만 집중할 수 있습니다. ECS는 추가 개입 없이 필요에 따라 ASG를 스케일 인 및 스케일 아웃하도록 보장합니다. Amazon ECS 용량 공급자는 애플리케이션의 요구 사항을 충족하기에 충분한 컨테이너 인스턴스가 있는지 확인하여 클러스터의 인프라를 관리하는 데 사용됩니다. Amazon ECS CAS의 작동 방식을 알아보려면 [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)을 참조하세요.
CAS는 클러스터 용량 조정을 위해 ASG와의 CloudWatch 기반 통합에 의존하므로 CloudWatch 지표 게시와 관련된 고유한 지연 시간, 지표 `CapacityProviderReservation`이 CloudWatch 경보(높음 및 낮음 모두)를 위반하는 데 걸리는 시간, 새로 시작한 Amazon EC2 인스턴스가 워밍업하는 데 걸리는 시간이 존재합니다. 더 빠른 배포를 위해 CAS의 응답성을 높이려면 다음 작업을 수행할 수 있습니다.
## 용량 제공자 단계 규모 조정 크기
Amazon ECS 용량 공급자는 결국 애플리케이션의 요구 사항을 충족하기 위해 컨테이너 인스턴스를 늘리거나 줄일 것입니다. Amazon ECS가 시작할 최소 인스턴스 수는 기본적으로 1로 설정됩니다. 보류 중인 작업을 배치하는 데 여러 인스턴스가 필요한 경우 배포 시간이 추가될 수 있습니다. Amazon ECS API를 사용해 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html)를 늘려 Amazon ECS가 한 번에 스케일 인하거나 스케일 아웃하는 최소 인스턴스 수를 늘릴 수 있습니다. [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html)가 너무 낮으면 한 번에 스케일 인 또는 스케일 아웃하는 컨테이너 인스턴스 수를 제한하여 배포 속도가 느려질 수 있습니다.
**참고**
이 구성은 현재 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 또는 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API를 통해서만 사용할 수 있습니다.
## 인스턴스 워밍업 기간
인스턴스 워밍업 기간은 새로 시작된 Amazon EC2 인스턴스가 Auto Scaling 그룹의 CloudWatch 지표에 기여할 수 있는 기간입니다. 지정된 워밍업 기간이 만료되면 인스턴스는 ASG의 집계된 지표로 계산되고 CAS는 다음 계산 반복을 진행하여 필요한 인스턴스 수를 추정합니다.
[https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)의 기본값은 300초이며 보다 반응성이 뛰어난 조정을 위해 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) 또는 [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) API를 사용하여 더 낮은 값으로 구성할 수 있습니다.
## 예비 용량
용량 공급자가 작업 배치에 사용할 수 있는 컨테이너 인스턴스가 없는 경우 Amazon EC2 인스턴스를 즉시 시작하여 클러스터 용량을 늘리고(스케일 아웃) 컨테이너를 시작하기 전에 해당 인스턴스가 부팅될 때까지 기다려야 합니다. 이로 인해 작업 시작 속도가 크게 느려질 수 있습니다. 여기에서는 두 가지 옵션이 있습니다.
이 경우 예비 Amazon EC2 용량이 이미 시작되어 태스크를 실행할 준비가 되어 있으면 효과적인 작업 시작 속도가 빨라집니다. `Target Capacity` 구성을 사용하여 클러스터의 예비 용량을 유지하도록 지정할 수 있습니다. 예를 들어 `Target Capacity`를 80%로 설정하면 클러스터에 항상 20%의 예비 용량이 필요함을 나타냅니다. 이 여유 용량을 통해 모든 독립 실행형 태스크를 즉시 시작할 수 있으므로 태스크 시작이 제한되지 않습니다. 이 접근 방식의 단점은 예비 클러스터 용량을 유지하는 데 드는 비용이 증가할 수 있다는 것입니다.
고려할 수 있는 또 다른 접근 방식은 용량 공급자가 아닌 서비스에 헤드룸을 추가하는 것입니다. 즉, 예비 용량을 시작하기 위한 `Target Capacity` 구성을 줄이는 대신 대상 추적 조정 지표 또는 서비스 Auto Scaling의 단계 규모 조정 임계값을 수정하여 서비스의 복제본 수를 늘릴 수 있습니다. 이 접근 방식은 워크로드가 급증하는 경우에만 유용하며 새 서비스를 배포하거나 처음으로 0개에서 N개의 태스크로 전환하는 경우에는 효과가 없다는 점에 유의하세요. 관련 조정 정책에 대한 자세한 내용은 [대상 추적 조정 정책](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) 또는 [단계 조정 정책](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)을 참조하세요.