# 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 워크로드 수요 분석 수행:
시간별 워크로드 수요를 분석합니다. 분석에서 시기별 추세를 파악하고 전체 워크로드 수명 주기 동안의 작동 상태를 정확하게 반영하는지 확인합니다. 분석 작업은 소요되는 시간 대비 워크로드 비용 등의 제공될 수 있는 이점을 반영해야 합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
워크로드의 요구 사항을 파악합니다. 조직의 요구 사항에는 요청에 대한 워크로드 응답 시간이 나타나야 합니다. 응답 시간을 사용하면 수요가 관리되는지 여부 또는 리소스 공급이 수요에 따라 변경되는지 여부를 확인할 수 있습니다.
분석에는 수요의 예측 가능성 및 반복 가능성, 수요 변경의 속도 및 수요 변경의 규모가 포함되어야 합니다. 분석은 월말 처리 또는 휴가철 피크와 같은 계절적 변동을 포함하기에 충분히 긴 기간에 걸쳐 수행되어야 합니다.
분석 작업에 확장 구현의 잠재적 이점이 반영되는지 확인하십시오. 구성 요소의 예상 총 비용을 찾아보고 워크로드 수명에 걸쳐 사용량 및 비용이 증가하거나 감소하는지 살펴봅니다.
여러분은 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 또는 [Amazon Quick](https://aws.amazon.com/quicksight/) 에서 AWS Cost and Usage Report(CUR) 또는 애플리케이션 로그를 사용하여 워크로드 수요를 시각적으로 분석할 수 있습니다.
**구현 단계**
+ ** 기존 워크로드 데이터 분석: **기존 워크로드, 이전 버전의 워크로드 또는 예측된 사용 패턴의 데이터를 분석합니다. 로그 파일과 모니터링 데이터를 사용하여 고객이 워크로드를 어떻게 사용하는지에 대한 인사이트를 얻을 수 있습니다. 일반적인 지표는 실제 수요(초당 요청 수), 수요 비율이 바뀌는 시간 또는 서로 다른 수준에 있는 시간, 수요 변경률 등이 있습니다. 워크로드의 전체 주기를 분석하여 월말 또는 연말 이벤트와 같은 주기적 변경 사항에 대한 데이터를 수집해야 합니다. 분석에 반영되는 작업량은 워크로드 특성을 반영해야 합니다. 수요 변화가 가장 많은 고가치 워크로드에 가장 많은 작업량을 배치해야 합니다. 수요 변화가 가장 적은 저가치 워크로드에 가장 적은 작업량을 배치해야 합니다. 일반적인 가치 지표는 위험, 브랜드 인식, 수익 또는 워크로드 비용입니다.
+ ** 외부 영향 예측: **워크로드의 수요에 영향을 주거나 변화를 줄 수 있는 조직 전체의 팀원과 만나십시오. 일반적인 팀은 영업, 마케팅 또는 비즈니스 개발입니다. 이들 팀과 협력하여 작업 주기를 확인하고 워크로드 수요를 바꾸는 이벤트가 있는지 확인합니다. 이 데이터로 워크로드 수요를 예측합니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 인스턴스 스케줄러](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [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/)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)
# COST09-BP02 수요 관리를 위한 버퍼 또는 제한 구현
버퍼링 및 조절은 워크로드의 수요를 수정하여 평준화합니다. 클라이언트가 재시도를 수행할 때 조절을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다. 클라이언트가 필요한 시간에 응답을 수신하도록 제한 및 버퍼가 설계되었는지 확인합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
**제한** 수요의 소스에 재시도 기능이 있는 경우 조절을 구현할 수 있습니다. 조절은 소스에 현재 요청을 처리할 수 없는 경우 나중에 다시 시도해야 함을 알려줍니다. 소스는 일정 시간 동안 기다린 후 요청을 다시 시도합니다. 조절을 구현하면 워크로드의 최대 리소스 양과 비용을 제한할 수 있는 장점이 있습니다. AWS에서는 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 를 사용하여 조절을 구현할 수 있습니다. 접근 관리 구현에 대한 자세한 내용은 [Well-Architected 안정성 원칙 백서](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) 를 참조하십시오.
**버퍼 기반: **조절과 비슷하게, 버퍼는 서로 다른 속도로 실행되는 애플리케이션이 효과적으로 통신할 수 있도록 요청 처리를 연기합니다. 버퍼링 기반 접근 방식에서는 대기열을 사용해 생산자의 메시지(작업 단위)를 수락합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다. 생산자는 데이터 내구성 및 백 프레셔(소비자 실행 속도가 느려서 생산자의 속도도 느려지는 현상)와 같은 조절 관련 문제를 처리할 필요가 없습니다.
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는 워크로드 구성 요소에 제한 기능을 제공할 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 인스턴스 스케줄러](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/)
+ [Amazon SQS 시작하기](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
# COST09-BP03 동적으로 리소스 공급
리소스가 계획된 방식으로 프로비저닝됩니다. 자동 크기 조정과 같은 수요 기반이거나, 수요를 예측할 수 있고 리소스가 시간을 기준으로 제공되는 시간 기반일 수 있습니다. 이러한 방법을 사용하면 너무 많거나 적게 프로비저닝되는 리소스의 양을 최소화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
여러분은 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)을 사용하거나 코드에 크기 조정을 포함할 수 있습니다. 코드에 포함하려는 경우에는 다음을 사용하면 됩니다. [AWS API 또는 SDK](https://aws.amazon.com/developer/tools/). 이렇게 하면 환경을 수동으로 변경하는 데 따른 운영 비용이 제거되므로 전반적인 워크로드 비용이 절감되며 변경을 훨씬 더 빠르게 수행할 수 있습니다. 또한 항상 수요와 가장 일치하는 양의 워크로드 리소스를 공급할 수 있습니다.
**수요 기반 공급:** 클라우드의 탄력성을 활용하여 수요 변경에 맞춰 리소스를 공급합니다. API 또는 서비스 기능을 활용하면 프로그래밍 방식을 통해 아키텍처의 클라우드 리소스 양을 동적으로 변경할 수 있습니다. 이렇게 하면 아키텍처의 구성 요소를 확장할 수 있으며, 수요 급증 기간 동안에는 리소스 수를 자동으로 늘려 성능을 유지하고 수요 감소 기간에는 용량을 줄여 비용을 절감할 수 있습니다.
[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 은 용량을 조정하여 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지하는 데 도움이 됩니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 스팟 플릿, Amazon Elastic Container Service(Amazon ECS), Amazon DynamoDB 및 Amazon Aurora와 통합되는 완전관리형의 무료 서비스입니다.
Auto Scaling이 제공하는 자동 리소스 검색 기능을 사용하면 워크로드에서 구성 가능한 리소스를 쉽게 찾을 수 있습니다. 또한 기본적으로 포함되어 있는 확장 전략을 통해 성능, 비용 또는 둘 사이의 균형을 최적화할 수 있으며 예측 조정 기능을 통해 주기적으로 발생하는 스파이크를 지원할 수 있습니다.
Auto Scaling으로 수동, 일정, 수요 기반 크기 조정을 구현할 수 있습니다. 또한 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 의 지표 및 경보를 사용하여 워크로드에 대한 조정 이벤트를 트리거할 수도 있습니다. 일반적인 지표로는 표준 Amazon EC2 지표가 있는데, CPU 사용률, 네트워크 처리량 및 [Elastic Load Balancing(ELB)에서 ](https://aws.amazon.com/elasticloadbalancing/)관찰된 요청/응답 지연 시간 등입니다. 가능한 경우 고객 경험을 나타내는 지표를 사용해야 합니다. 일반적으로 이 지표는 워크로드 내 애플리케이션 코드에서 생성될 수 있는 사용자 지정 지표입니다.
수요 기반 방식을 사용하여 설계할 때는 두 가지 주요 사항을 고려해야 합니다. 먼저 새 리소스를 프로비저닝해야 하는 속도를 파악해야 합니다. 그리고 수요와 공급 간의 차이 규모는 변화한다는 점을 이해해야 합니다. 따라서 수요 변화 속도에 맞게 공급 속도를 변경할 수 있도록 준비하는 동시에 리소스 장애에도 대비해야 합니다.
[ELB](https://aws.amazon.com/elasticloadbalancing/) 는 여러 리소스에 걸쳐 수요를 분산하여 확장하는 데 도움이 됩니다. 더 많은 리소스를 구현하면 로드 밸런서에 추가하여 수요에 대응하도록 합니다. Elastic Load Balancing은 Amazon EC2 인스턴스, 컨테이너, IP 주소, AWS Lambda 함수에 대한 지원을 제공합니다.
**시간 기반 공급:** 시간 기반 방식에서는 시간별로 예측 가능하거나 적절하게 정의되는 수요에 맞게 리소스 용량을 조정합니다. 이 방식에서는 일반적으로 리소스 용량이 리소스 사용률 수준에 따라 달라지지 않습니다. 시간 기반 방식을 사용하면 필요한 특정 시간에 리소스를 사용할 수 있으며, 시작 절차 및 시스템 또는 일관성 검사로 인한 지연 없이 리소스를 제공할 수 있습니다. 또한 사용량이 많은 기간 동안 추가 리소스를 제공하거나 용량을 늘릴 수 있습니다.
예약된 Auto Scaling을 사용하면 시간 기반 접근 방식을 구현할 수 있습니다. 사용자 또는 수요 도달 시 리소스를 사용할 수 있도록 정의된 시간(예: 업무 시간 시작 시)에 워크로드 규모 확장/감축을 예약할 수 있습니다.
또한 [AWS API, SDK](https://aws.amazon.com/developer/tools/) 및 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 을 활용하면 전체 환경을 필요할 때 자동으로 프로비저닝하고 폐기할 수 있습니다. 이 방식은 정의된 업무 시간이나 일정 기간 동안에만 실행되는 개발 또는 테스트 환경에 적합합니다.
API를 사용해 환경 내에서 리소스 규모를 조정할 수 있습니다(수직 확장). 예를 들어 인스턴스 크기나 클래스를 변경하여 프로덕션 워크로드의 규모를 확장할 수 있습니다. 이렇게 하려면 인스턴스를 중지했다가 시작한 후 다른 인스턴스 크기나 클래스를 선택합니다. 크기를 늘리거나, 성능(IOPS)을 조정하거나, 사용 중에 볼륨 유형을 변경하기 위해 수정할 수 있는 Amazon Elastic Block Store(Amazon EBS) 탄력적 볼륨 등의 다른 리소스에도 이 기술을 적용할 수 있습니다.
시간 기반 방식을 사용하여 설계할 때는 두 가지 주요 사항을 고려해야 합니다. 먼저 사용 패턴의 일관성 정도를 파악해야 합니다. 그리고 패턴 변경 시의 영향을 고려해야 합니다. 워크로드를 모니터링하고 비즈니스 인텔리전스를 사용하면 예측 정확도를 높일 수 있습니다. 사용 패턴이 크게 변경되는 경우에는 패턴이 변경된 기간이 포함되도록 시간을 조정할 수 있습니다.
**구현 단계**
+ ** 시간 기반 일정 구성: **예측 가능한 수요 변화를 위해 시간 기반 조정은 적시에 올바른 개수의 리소스를 제공할 수 있습니다. 리소스 생성 및 구성이 수요 변화에 대응할 만큼 충분히 빠르지 않은 경우에도 유용합니다. 워크로드 분석으로 AWS Auto Scaling을 사용하여 예약된 크기 조정을 구성합니다.
+ ** Auto Scaling 구성: **활성 워크로드 지표를 기반으로 조정을 구성하려면 Amazon Auto Scaling을 사용합니다. 분석을 사용하여 올바른 리소스 수준에서 트리거되도록 Auto Scaling을 구성하고 워크로드가 필요한 시간 내에 조정되도록 합니다.
## 리소스
**관련 문서:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/)
+ [Amazon EC2 Auto Scaling 시작하기](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon SQS 시작하기](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [Amazon EC2 Auto Scaling에 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)