# COST 9. 수요와 리소스 공급은 어떻게 관리하나요?
비용과 성능을 적절하게 절충한 워크로드에서는 비용을 결제한 모든 리소스가 사용되는지 확인하고, 사용률이 매우 낮은 인스턴스가 없도록 해야 합니다. 사용률 지표가 매우 높거나 낮으면 조직의 운영 비용(사용률이 너무 높아 성능이 저하됨)이 늘어나거나 과도한 프로비저닝으로 AWS 지출 금액이 낭비되는 등 조직에 악영향을 미칩니다.
**Topics**
+ [
# COST09-BP01 워크로드 수요 분석 수행
](cost_manage_demand_resources_cost_analysis.md)
+ [
# COST09-BP02 수요 관리를 위한 버퍼 또는 제한 구현
](cost_manage_demand_resources_buffer_throttle.md)
+ [
# COST09-BP03 동적으로 리소스 공급
](cost_manage_demand_resources_dynamic.md)
# COST09-BP01 워크로드 수요 분석 수행
시간별 워크로드 수요를 분석합니다. 분석에서 시기별 추세를 파악하고 전체 워크로드 수명 주기 동안의 작동 상태를 정확하게 반영하는지 확인합니다. 분석 작업은 소요되는 시간 대비 워크로드 비용 등의 제공될 수 있는 이점을 반영해야 합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
클라우드 컴퓨팅에 대한 워크로드 수요를 분석하려면 클라우드 환경에서 시작되는 컴퓨팅 작업의 패턴과 특성을 이해해야 합니다. 이 분석을 통해 사용자는 리소스 할당을 최적화하고 비용을 관리하며 성능이 요구 수준을 충족하는지 확인할 수 있습니다.
워크로드의 요구 사항을 파악합니다. 조직의 요구 사항에는 요청에 대한 워크로드 응답 시간이 표시되어야 합니다. 응답 시간을 사용하면 수요가 관리되는지 여부 또는 리소스 공급이 수요에 따라 변경되어야 하는지 여부를 확인할 수 있습니다.
분석에는 수요의 예측 가능성 및 반복 가능성, 수요 변경의 속도 및 수요 변경의 규모가 포함되어야 합니다. 월말 처리 또는 휴가철 피크와 같은 계절적 변동을 포함하기에 충분히 긴 기간에 걸쳐 분석을 수행합니다.
분석 작업에는 규모 조정 구현의 잠재적 이점이 반영되어야 합니다. 구성 요소의 예상 총 비용을 찾아보고 워크로드 수명에 걸쳐 사용량 및 비용이 증가하거나 감소하는지 살펴봅니다.
다음은 클라우드 컴퓨팅에 대한 워크로드 수요 분석을 수행할 때 고려해야 할 몇 가지 주요 측면입니다.
1. **리소스 사용률 및 성과 지표:** 시간이 지남에 따라 AWS 리소스가 어떻게 사용되고 있는지 분석합니다. 사용량이 최대일 때와 사용량이 적을 때의 패턴을 확인하여 리소스 할당 및 규모 조정 전략을 최적화합니다. 응답 시간, 지연 시간, 처리량, 오류율과 같은 성과 지표를 모니터링합니다. 이러한 지표는 클라우드 인프라의 전반적인 상태와 효율성을 평가하는 데 도움이 됩니다.
1. **사용자 및 애플리케이션 규모 조정 동작:** 사용자 행동과 이것이 워크로드 수요에 미치는 영향을 파악합니다. 사용자 트래픽 패턴을 조사하면 콘텐츠 전송 및 애플리케이션 응답성을 향상시키는 데 도움이 됩니다. 증가하는 수요에 맞추어 워크로드 규모가 어떻게 조정되는지 분석합니다. 로드 변동을 처리할 수 있도록 Auto Scaling 파라미터가 정확하고 효과적으로 구성되었는지 확인합니다.
1. **워크로드 유형**: 일괄 처리, 실시간 데이터 처리, 웹 애플리케이션, 데이터베이스 또는 기계 학습과 같이 클라우드에서 실행되는 다양한 유형의 워크로드를 파악합니다. 워크로드 유형마다 리소스 요구 사항 및 성능 프로필이 다를 수 있습니다.
1. **서비스 수준에 관한 계약(SLA)**: 실제 성능을 SLA와 비교하여 규정 준수를 보장하고 개선이 필요한 영역을 파악합니다.
[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)를 사용하여 지표를 수집 및 추적하고, 로그 파일을 수집 및 모니터링하며, 경보를 설정하고, AWS 리소스 변경에 자동으로 대응할 수 있습니다. 또한 Amazon CloudWatch를 사용하여 시스템 전반의 리소스 사용률, 애플리케이션 성능, 운영 상태를 파악할 수 있습니다.
[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)를 사용하면 모범 사례에 따라 리소스를 프로비저닝하여 시스템 성능 및 신뢰성을 개선하고, 보안을 강화하며, 비용을 절감할 기회를 모색할 수 있습니다. 비프로덕션 인스턴스를 끄고 수요 증가 또는 감소에 맞춰 Amazon CloudWatch 및 Auto Scaling을 사용할 수도 있습니다.
마지막으로, [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 또는 [Quick](https://aws.amazon.com/quicksight/)을 AWS Cost and Usage Report(CUR) 파일 또는 애플리케이션 로그와 함께 사용하여 워크로드 수요에 대한 고급 분석을 수행할 수 있습니다.
전반적으로, 포괄적인 워크로드 수요 분석을 통해 조직은 리소스 프로비저닝, 규모 조정 및 최적화에 대해 합리적인 결정을 내려서 성능, 비용 효율성 및 사용자 만족도를 높일 수 있습니다.
### 구현 단계
+ **기존 워크로드 데이터 분석:** 기존 워크로드, 이전 버전의 워크로드 또는 예측된 사용 패턴의 데이터를 분석합니다. Amazon CloudWatch, 로그 파일 및 모니터링 데이터를 사용하여 워크로드가 어떻게 사용되었는지에 대한 인사이트를 얻을 수 있습니다. 워크로드의 전체 주기를 분석하여 월말 또는 연말 이벤트와 같은 주기적 변경 사항에 대한 데이터를 수집합니다. 분석에 반영되는 작업량은 워크로드 특성을 반영해야 합니다. 수요 변화가 가장 많은 고가치 워크로드에 가장 많은 작업량을 배치해야 합니다. 수요 변화가 가장 적은 저가치 워크로드에 가장 적은 작업량을 배치해야 합니다.
+ **외부 영향 예측:** 워크로드의 수요에 영향을 주거나 변화를 줄 수 있는 조직 전체의 팀원과 만납니다. 일반적인 팀은 영업, 마케팅 또는 비즈니스 개발입니다. 이들 팀과 협력하여 작업 주기를 확인하고 워크로드 수요를 바꾸는 이벤트가 있는지 확인합니다. 이 데이터로 워크로드 수요를 예측합니다.
## 리소스
**관련 문서:**
+ [ Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Quick](https://aws.amazon.com/quicksight/)
**관련 예제:**
+ [Monitor, Track and Analyze for cost optimization](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/monitor-track-and-analyze/)
+ [Searching and analyzing logs in CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-search-analysis.html)
# COST09-BP02 수요 관리를 위한 버퍼 또는 제한 구현
버퍼링 및 제한은 워크로드의 수요를 수정하여 평준화합니다. 클라이언트가 재시도를 수행할 때 제한을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다. 클라이언트가 필요한 시간에 응답을 수신하도록 제한 및 버퍼가 설계되었는지 확인합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
클라우드 컴퓨팅에서 수요를 관리하고 워크로드에 필요한 프로비저닝 용량을 줄이려면 버퍼 또는 제한을 구현하는 것이 중요합니다. 최적의 성능을 위해서는 피크, 요청 변경 속도, 필요한 응답 시간을 포함한 총 수요를 측정하는 것이 핵심입니다. 클라이언트가 요청을 재전송할 수 있게 되면 제한을 적용하는 것이 실용적입니다. 반대로 재시도 기능이 없는 클라이언트의 경우 이상적인 접근 방식은 버퍼 솔루션을 구현하는 것입니다. 이러한 버퍼는 요청 유입을 간소화하고 다양한 작업 속도로 애플리케이션 간의 상호 작용을 최적화합니다.
![\[높은 프로비저닝 용량을 필요로 하는 두 개의 피크가 있는 수요 곡선\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/provisioned-capacity-1.png)
위 그림에 표시된 수요 곡선을 바탕으로 워크로드를 가정합니다. 이 워크로드에는 2개의 피크가 있으며, 이러한 피크를 처리하기 위해 주황색 선으로 표시된 리소스 용량이 프로비저닝됩니다. 이 워크로드에 사용되는 리소스와 에너지는 수요 곡선 아래의 영역이 아니라 프로비저닝된 용량 선 아래의 영역으로 표시됩니다. 이 2개의 피크를 처리하려면 프로비저닝된 용량이 필요하기 때문입니다. 워크로드 수요 곡선을 완화하면 워크로드에 프로비저닝된 용량을 줄이고 환경에 미치는 영향도 줄일 수 있습니다. 피크 속도를 낮추려면 제한 또는 버퍼링 솔루션을 구현하는 것이 좋습니다.
이해를 돕기 위해 제한과 버퍼링에 대해 살펴보겠습니다.
**제한:** 수요의 소스에 재시도 기능이 있는 경우 제한을 구현할 수 있습니다. 제한은 현재 요청을 처리할 수 없는 경우 나중에 다시 시도해야 함을 소스에 알려줍니다. 소스는 일정 기간 기다린 다음 요청을 재시도합니다. 제한을 구현하면 워크로드의 최대 리소스 양과 비용을 제한할 수 있는 장점이 있습니다. AWS에서는 [Amazon API Gateway](https://aws.amazon.com/api-gateway/)를 사용하여 제한을 구현할 수 있습니다.
**버퍼 기반:** 버퍼 기반 접근 방식은 *생산자*(대기열에 메시지를 보내는 구성 요소), *소비자*(대기열에서 메시지를 받는 구성 요소) 및 *대기열*(메시지를 보관함)을 사용하여 메시지를 저장합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다. 버퍼 중심 방법을 사용하면 생산자의 메시지가 대기열이나 스트림에 보관되어 소비자가 작업 요구 사항에 맞는 속도로 액세스할 수 있습니다.
AWS에서는 여러 서비스 중에서 버퍼링 방식을 구현하는 데 적합한 서비스를 선택할 수 있습니다. [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/)는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공하는 관리형 서비스입니다. [Amazon Kinesis](https://aws.amazon.com/kinesis/)에서는 여러 소비자가 같은 메시지를 읽을 수 있는 스트림을 제공합니다.
버퍼링 및 제한을 통해 워크로드에 대한 수요를 수정하여 피크를 원활하게 처리할 수 있습니다. 클라이언트가 작업을 재시도할 때는 제한을 사용하고 요청을 보류했다가 나중에 처리하려면 버퍼링을 사용합니다. 버퍼 기반 접근 방식을 사용할 때는 필요한 시간에 요청을 처리하도록 워크로드를 설계해야 하며 작업에 대한 중복 요청을 처리할 수 있는지 확인해야 합니다. 전체 수요, 변경률 및 필수 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 적절하게 조정합니다.
### 구현 단계
+ ** 클라이언트 요구 사항 분석:** 클라이언트 요청을 분석하여 재시도를 수행할 수 있는지 확인합니다. 재시도를 수행할 수 없는 클라이언트의 경우 버퍼를 구현해야 합니다. 전체 수요, 변경률 및 필요한 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 결정합니다.
+ ** 버퍼 또는 제한 구현:** 워크로드에 버퍼 또는 제한을 구현합니다. Amazon Simple Queue Service(Amazon SQS)와 같은 대기열은 워크로드 구성 요소에 버퍼를 제공할 수 있습니다. Amazon API Gateway는 워크로드 구성 요소에 대한 제한을 제공할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [ SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화 ](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a7.html)
+ [ REL05-BP02 요청 제한 ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [Amazon Simple Queue Service](https://aws.amazon.com/sqs/)()
+ [Getting started with Amazon SQS](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
**관련 비디오:**
+ [ Choosing the Right Messaging Service for Your Distributed App ](https://www.youtube.com/watch?v=4-JmX6MIDDI)
**관련 예제:**
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ Throttling a tiered, multi-tenant REST API at scale using API Gateway ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ Enabling Tiering and Throttling in a Multi-Tenant Amazon EKS SaaS Solution Using Amazon API Gateway ](https://aws.amazon.com/blogs/apn/enabling-tiering-and-throttling-in-a-multi-tenant-amazon-eks-saas-solution-using-amazon-api-gateway/)
+ [ Application integration Using Queues and Messages ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
# COST09-BP03 동적으로 리소스 공급
리소스가 계획된 방식으로 프로비저닝됩니다. 자동 크기 조정과 같은 수요 기반이거나, 수요를 예측할 수 있고 리소스가 시간을 기준으로 제공되는 시간 기반일 수 있습니다. 이러한 방법을 사용하면 과다 프로비저닝 또는 과소 프로비저닝을 최소화할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
AWS 고객이 애플리케이션에 사용할 수 있는 리소스를 늘리고 수요를 충족하는 리소스를 공급할 수 있는 몇 가지 방법이 있습니다. 이러한 옵션 중 하나는 Amazon Elastic Compute Cloud(Amazon EC2) 및 Amazon Relational Database Service(RDS) 인스턴스의 시작 및 중지를 자동화하는 AWS Instance Scheduler를 사용하는 것입니다. 다른 옵션은 AWS Auto Scaling을 사용하는 것입니다. 이 옵션을 사용하면 애플리케이션 또는 서비스의 요구에 따라 컴퓨팅 리소스를 자동으로 조정할 수 있습니다. 수요에 따라 리소스를 공급하면 사용한 리소스에 대해서만 비용을 지불하고 필요할 때 리소스를 해제하여 비용을 절감하며 필요하지 않을 때는 리소스를 종료할 수 있습니다.
[AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)를 사용하면 정의된 시간에 Amazon EC2 및 Amazon RDS 인스턴스의 중지와 시작을 구성할 수 있습니다. 그러면 예를 들어 저녁 6시 이후에는 필요 없는 Amazon EC2 인스턴스에 매일 오전 8시에 액세스하는 등의 일정한 시간 패턴을 통해 동일한 리소스의 수요를 충족할 수 있습니다. 이 솔루션은 사용하지 않는 리소스는 중지하고 필요할 때 시작하여 운영 비용을 줄여줍니다.
![\[AWS Instance Scheduler를 사용한 비용 최적화를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/instance-scheduler-diagram.png)
또한 AWS Systems Manager 빠른 설정을 사용하여 간단한 사용자 인터페이스(UI)로 계정 및 리전 전체에서 Amazon EC2 인스턴스의 일정을 쉽게 구성할 수 있습니다. AWS Instance Scheduler로 Amazon EC2 또는 Amazon RDS 인스턴스를 예약하고 기존 인스턴스를 중지 및 시작할 수 있습니다. 그러나 Auto Scaling 그룹(ASG)의 일부이거나 Amazon Redshift 또는 Amazon OpenSearch Service 등과 같은 서비스를 관리하는 인스턴스는 중지 및 시작할 수 없습니다. Auto Scaling 그룹에는 그룹 내 인스턴스에 대한 고유한 일정이 있으며 이러한 인스턴스가 생성됩니다.
[AWS Auto Scaling](https://aws.amazon.com/autoscaling/)은 용량을 조정하여 최대한 저렴한 비용으로 변화하는 수요를 충족하기 위한 안정적이고 예측 가능한 성능을 유지하는 데 도움이 됩니다. Amazon EC2 인스턴스 및 스팟 플릿, Amazon ECS, Amazon DynamoDB 및 Amazon Aurora와 통합되어 애플리케이션 용량을 조정하는 완전관리형의 무료 서비스입니다. Auto Scaling이 제공하는 자동 리소스 검색 기능을 사용하면 워크로드에서 구성 가능한 리소스를 쉽게 찾을 수 있습니다. 또한 기본적으로 포함되어 있는 확장 전략을 통해 성능, 비용 또는 둘 사이의 균형을 최적화할 수 있으며 예측 조정 기능을 통해 주기적으로 발생하는 스파이크를 지원할 수 있습니다.
Auto Scaling 그룹을 조정하는 데 사용할 수 있는 다양한 규모 조정 옵션이 있습니다.
+ 항상 현재 인스턴스 수준 유지 관리
+ 수동 조정
+ 일정에 근거하여 조정
+ 온디맨드 기반 조정
+ 예측 조정 사용
Auto Scaling 정책은 서로 다르며 동적 및 예약 규모 조정 정책으로 분류될 수 있습니다. 동적 정책은 수동 또는 동적 규모 조정으로, 예약 또는 예측 규모 조정입니다. 동적, 예약 및 예측 규모 조정에 규모 조정 정책을 사용할 수 있습니다. 또한 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)의 지표와 경보를 사용하여 워크로드에 대한 규모 조정 이벤트를 트리거할 수 있습니다. 최신 기능과 개선 사항에 액세스하려면 [시작 템플릿](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)을 사용하는 것이 좋습니다. 시작 구성을 사용할 때 일부 Auto Scaling 기능을 사용할 수 없습니다. 예를 들어, 스팟 및 온디맨드 인스턴스를 모두 시작하거나 여러 인스턴스 유형을 지정하는 Auto Scaling 그룹은 생성할 수 없습니다. 이러한 기능을 구성하려면 시작 템플릿을 사용해야 합니다. 시작 템플릿을 사용할 때는 각 템플릿의 버전을 지정하는 것이 좋습니다. 시작 템플릿 버전 관리를 사용하면 전체 파라미터 세트의 하위 세트를 생성할 수 있습니다. 그런 다음, 해당 세트를 재사용하여 동일한 시작 템플릿의 다른 버전을 만들 수 있습니다.
AWS Auto Scaling을 사용하거나 [AWS API 또는 SDK](https://aws.amazon.com/developer/tools/)를 사용하여 코드에서 규모 조정을 통합할 수 있습니다. 이렇게 하면 환경을 수동으로 변경하는 데 따른 운영 비용이 제거되므로 전반적인 워크로드 비용이 절감되며 변경을 훨씬 더 빠르게 수행할 수 있습니다. 이는 또한 언제든지 수요에 맞춰 워크로드 리소스를 조정합니다. 이 모범 사례를 따르고 조직에 리소스를 동적으로 공급하려면 AWS 클라우드의 수평적 스케일링 및 수직적 스케일링과 Amazon EC2 인스턴스에서 실행 중인 애플리케이션의 특성을 이해해야 합니다. 이 모범 사례를 따르기 위해 클라우드 재무 관리 팀이 기술 팀과 협력하는 것이 좋습니다.
[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)은 여러 리소스에 걸쳐 수요를 분산하여 규모를 조정하는 데 도움이 됩니다. ASG 및 Elastic Load Balancing을 사용하면 Auto Scaling 그룹 내에서 어떤 인스턴스에도 부하가 걸리지 않도록 트래픽을 최적으로 라우팅하여 들어오는 요청을 관리할 수 있습니다. 요청은 용량 또는 사용률을 고려하지 않고 대상 그룹의 모든 대상에 라운드 로빈 방식으로 분산됩니다.
일반적인 지표로는 CPU 사용률, 네트워크 처리량 및 Elastic Load Balancing에서 관찰된 요청 및 응답 지연 시간과 같은 표준 Amazon EC2 지표가 있습니다. 가능한 경우 고객 경험을 나타내는 지표를 사용해야 합니다. 일반적으로는 워크로드 내 애플리케이션 코드에서 생성될 수 있는 사용자 지정 지표입니다. 이 문서에서는 수요를 동적으로 충족하는 방법을 자세히 설명하기 위해 Auto Scaling을 수요 기반 공급 모델과 시간 기반 공급 모델의 두 범주로 분류하고 각 모델을 심층적으로 살펴보겠습니다.
**수요 기반 공급:** 클라우드의 탄력성을 활용하여 거의 실시간에 가까운 수요 상태를 기반으로 변화하는 수요를 충족할 리소스를 공급합니다. 수요 기반 공급에서는 API 또는 서비스 기능을 사용하여 프로그래밍 방식을 통해 아키텍처의 클라우드 리소스 양을 변경합니다. 이렇게 하면 아키텍처 구성 요소의 규모를 조정할 수 있으며, 수요 급증 기간에는 리소스 수를 늘려 성능을 유지하고 수요 감소 기간에는 용량을 줄여 비용을 절감할 수 있습니다.
![\[단순/단계별 규모 조정 및 목표 추적과 같은 수요 기반 규모 조정 정책을 설명하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/demand-based-supply.png)
+ **단순/단계별 규모 조정:** 고객이 수동으로 정의한 단계에 따라 지표를 모니터링하고 인스턴스를 추가 또는 제거합니다.
+ **목표 추적:** 지표를 사용자가 정의한 목표로 유지하기 위해 인스턴스를 자동으로 추가 또는 제거하는 온도 조절기와 유사한 제어 메커니즘입니다.
수요 기반 방식을 사용하여 설계할 때는 두 가지 주요 사항을 고려해야 합니다. 먼저 새 리소스를 프로비저닝해야 하는 속도를 파악해야 합니다. 그리고 수요와 공급 간의 차이 규모는 변화한다는 점을 이해해야 합니다. 따라서 수요 변화 속도에 맞게 공급 속도를 변경할 수 있도록 준비하는 동시에 리소스 장애에도 대비해야 합니다.
**시간 기반 공급:** 시간 기반 방식에서는 시간별로 예측 가능하거나 적절하게 정의되는 수요에 맞게 리소스 용량을 조정합니다. 이 방식에서는 일반적으로 리소스 용량이 리소스 사용률 수준에 따라 달라지지 않습니다. 시간 기반 방식을 사용하면 필요한 특정 시간에 리소스를 사용할 수 있으며, 시작 절차 및 시스템 또는 일관성 검사로 인한 지연 없이 리소스를 제공할 수 있습니다. 또한 사용량이 많은 기간에 추가 리소스를 제공하거나 용량을 늘릴 수 있습니다.
![\[예약 및 예측 규모 조정과 같은 시간 기반 규모 조정 정책을 설명하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/time-based-supply.png)
예약 또는 예측 Auto Scaling을 사용하여 시간 기반 접근 방식을 구현할 수 있습니다. 사용자 도달 또는 수요 증가 시 리소스를 사용할 수 있도록 정의된 시간(예: 업무 시간 시작 시)에 워크로드 스케일 아웃 또는 스케일 인을 예약할 수 있습니다. 예측 규모 조정은 패턴을 사용하여 스케일 아웃하는 반면에 예약된 규모 조정은 미리 정의된 시간을 사용하여 스케일 아웃합니다. 또한 Auto Scaling 그룹의 [속성 기반 인스턴스 유형 선택(ABS) 전략](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)을 사용하여 vCPU, 메모리 및 스토리지와 같은 일련의 속성으로서 인스턴스 요구 사항을 표현할 수 있습니다. 또한 신세대 인스턴스 유형이 릴리스되면 이를 자동으로 사용하고 Amazon EC2 스팟 인스턴스를 통해 더 광범위한 용량에 액세스할 수 있습니다. Amazon EC2 플릿과 Amazon EC2 Auto Scaling은 지정된 속성에 맞는 인스턴스를 선택하고 시작하여 인스턴스 유형을 수동으로 선택할 필요성이 사라집니다.
또한 [AWS API 및 SDK](https://aws.amazon.com/developer/tools/)와 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)을 활용하여 필요한 경우 전체 환경을 자동으로 프로비저닝하고 폐기할 수 있습니다. 이 방식은 정의된 업무 시간이나 일정 기간에만 실행되는 개발 또는 테스트 환경에 적합합니다. API를 사용해 환경 내에서 리소스 규모를 조정할 수 있습니다(수직적 스케일링). 예를 들어 인스턴스 크기나 클래스를 변경하여 프로덕션 워크로드의 규모를 스케일 업할 수 있습니다. 이렇게 하려면 인스턴스를 중지했다가 시작한 후 다른 인스턴스 크기나 클래스를 선택합니다. 크기를 늘리거나, 성능(IOPS)을 조정하거나, 사용 중에 볼륨 유형을 변경하기 위해 수정할 수 있는 Amazon EBS 탄력적 볼륨 등의 다른 리소스에도 이 기술을 적용할 수 있습니다.
시간 기반 방식을 사용하여 설계할 때는 두 가지 주요 사항을 고려해야 합니다. 먼저 사용 패턴의 일관성 정도를 파악해야 합니다. 그리고 패턴 변경 시의 영향을 고려해야 합니다. 워크로드를 모니터링하고 비즈니스 인텔리전스를 사용하면 예측 정확도를 높일 수 있습니다. 사용 패턴이 크게 변경되는 경우에는 패턴이 변경된 기간이 포함되도록 시간을 조정할 수 있습니다.
## 구현 단계
+ ** 예약 규모 조정 구성:** 예측 가능한 수요 변화를 위해 시간 기반 조정은 적시에 올바른 개수의 리소스를 제공할 수 있습니다. 리소스 생성 및 구성이 수요 변화에 대응할 만큼 충분히 빠르지 않은 경우에도 유용합니다. 워크로드 분석으로 AWS Auto Scaling을 사용하여 예약된 규모 조정을 구성합니다. 시간 기반 일정을 구성하기 위해 예약된 규모 조정의 예측 규모 조정을 사용하여 예상되는 또는 예측 가능한 로드 변화에 따라 Auto Scaling 그룹 내 Amazon EC2 인스턴스 수를 미리 늘릴 수 있습니다.
+ **예측 규모 조정 구성:** 예측 규모 조정을 사용하여 트래픽 흐름의 일일 및 주간 패턴에 앞서 Auto Scaling 그룹의 Amazon EC2 인스턴스 수를 늘릴 수 있습니다. 시작하는 데 오래 걸리는 애플리케이션이 있고 정기적으로 트래픽이 급증하는 경우 예측 규모 조정 사용을 고려해야 합니다. 예측 규모 조정은 예측한 로드가 발생 전에 용량을 초기화함으로써 반응적인 속성의 동적 규모 조정을 단독으로 사용하는 것과 비교하여 더 빠르게 규모를 조정할 수 있도록 합니다. 예를 들어, 사용자가 업무 시간 시작과 함께 워크로드를 사용하기 시작하고 업무 시간이 지나면 사용하지 않는 경우, 예측 규모 조정은 업무 시간 전에 용량을 추가할 수 있습니다. 그러면 변화하는 트래픽에 대응하기 위한 동적 규모 조정의 지연이 사라집니다.
+ ** 동적 자동 규모 조정 구성:** 활성 워크로드 지표를 기반으로 조정을 구성하려면 Auto Scaling을 사용합니다. 분석을 사용하여 올바른 리소스 수준에서 시작하도록 Auto Scaling을 구성하고 워크로드가 필요한 시간 내에 조정되도록 합니다. 단일 Auto Scaling 그룹 내에서 온디맨드 인스턴스 및 스팟 인스턴스 플릿를 자동으로 확장할 수 있습니다. 스팟 인스턴스 사용에 대한 할인을 받을 수 있을 뿐만 아니라 예약 인스턴스 또는 Savings Plans를 사용하여 일반 온디맨드 인스턴스 요금의 할인된 요금을 받을 수 있습니다. 이러한 모든 요소를 결합하면 Amazon EC2 인스턴스의 비용 절감을 최적화할 수 있으며 애플리케이션에서 원하는 규모 및 성능을 얻을 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ Auto Scaling 그룹의 크기 조정
+ [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Scheduled Scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [ Predictive scaling for Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)
**관련 비디오:**
+ [ Target Tracking Scaling Policies for Auto Scaling ](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS Instance Scheduler ](https://www.youtube.com/watch?v=nTLEyo2NzUs)
**관련 예제:**
+ [ Attribute based Instance Type Selection for Auto Scaling for Amazon EC2 Fleet ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [ Optimizing Amazon Elastic Container Service for cost using scheduled scaling ](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [ Predictive Scaling with Amazon EC2 Auto Scaling ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [CloudFormation과 함께 Instance Scheduler를 사용하여 EC2 인스턴스를 예약하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)