# 수요에 맞춘 조정
**Topics**
+ [SUS 2 클라우드 리소스를 비즈니스 요구에 어떻게 맞추시겠습니까?](sus-02.md)
# SUS 2 클라우드 리소스를 비즈니스 요구에 어떻게 맞추시겠습니까?
사용자 및 애플리케이션이 워크로드 및 기타 리소스를 사용하는 방식을 통해 지속 가능성 목표를 달성하기 위한 개선 사항을 식별할 수 있습니다. 인프라를 지속적으로 확장하여 수요를 충족하고 사용자를 지원하는 데 필요한 최소 리소스만 활용하는지 확인합니다. 고객 요구 사항에 맞게 서비스 수준을 조정합니다. 사용자 및 애플리케이션이 리소스를 소비하는 데 필요한 네트워크를 제한하도록 리소스를 배치합니다. 사용되지 않는 자산을 제거합니다. 팀원에게 지속 가능성에 미치는 영향을 최소화하면서 요구 사항을 지원하는 디바이스를 제공합니다.
**Topics**
+ [SUS02-BP01 워크로드 인프라를 동적으로 확장](sus_sus_user_a2.md)
+ [SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정](sus_sus_user_a3.md)
+ [SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지](sus_sus_user_a4.md)
+ [SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화](sus_sus_user_a5.md)
+ [SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화](sus_sus_user_a6.md)
+ [SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화](sus_sus_user_a7.md)
# SUS02-BP01 워크로드 인프라를 동적으로 확장
클라우드의 탄력성을 활용하고 인프라를 동적으로 확장하여, 클라우드 리소스 공급을 수요에 맞게 조정하고 워크로드의 용량 초과 프로비저닝을 방지할 수 있습니다.
**일반적인 안티 패턴:**
+ 사용자 로드에 따라 인프라를 확장하지 않습니다.
+ 항상 인프라를 수동으로 확장합니다.
+ 조정 이벤트 후에 다시 축소하는 대신 증가된 용량을 그대로 둡니다.
**이 모범 사례 실천의 이점:** 워크로드 탄력성을 구성하고 테스트하면 클라우드 리소스 공급을 수요에 효율적으로 일치시키고 용량 초과 프로비저닝을 방지할 수 있습니다. 클라우드의 탄력성을 활용하여 수요가 급증하는 도중과 그 이후에 용량을 자동으로 확장하여 비즈니스 요구 사항을 충족하는 데 필요한 리소스만큼만 사용할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출 위험도:** 중간
## 구현 가이드
클라우드는 수요 변화에 맞춰 다양한 메커니즘을 통해 리소스를 동적으로 확장 또는 축소할 수 있는 유연성을 제공합니다. 공급과 수요를 최적으로 일치시키면 워크로드 환경에 미치는 영향이 최소화됩니다.
수요는 고정되거나 가변적일 수 있으므로 관리에 부담이 되지 않도록 측정 기준과 자동화가 필요합니다. 애플리케이션은 인스턴스 크기를 수정하여 수직(위로 또는 아래로)으로 확장하거나 인스턴스 수를 수정하여 수평(안 또는 밖으로)으로 확장하거나 둘을 모두 조합하여 확장할 수 있습니다.
다양한 접근 방식을 사용하여 리소스 공급과 수요를 일치시킬 수 있습니다.
+ **타겟 추적 접근법:** 스케일링 지표를 모니터링하고 필요에 따라 용량을 자동으로 늘리거나 줄입니다.
+ **예측 확장:** 일일 및 주간 추세를 예상하여 확장할 수 있습니다.
+ **일정 기반 접근법:** 예측 가능한 부하 변화에 따라 직접 스케일링 일정을 설정합니다.
+ **서비스 스케일링:** 기본적으로 설계별로 확장되는 서버리스와 같은 서비스를 선택하거나 자동 스케일링 기능을 제공합니다.
활용률이 낮거나 없는 기간을 식별하고 리소스의 크기를 조정하여 초과 용량을 제거하고 효율성을 개선합니다.
## 구현 단계
+ 탄력성은 보유한 리소스의 공급을 해당 리소스의 수요에 맞춥니다. 인스턴스, 컨테이너 및 함수는 자동 스케일링과 함께, 또는 서비스의 기능을 사용하여 탄력성을 지원하는 메커니즘을 제공합니다. AWS는 사용자 로드가 적은 기간에 워크로드를 빠르고 쉽게 축소할 수 있도록 다양한 자동 스케일링 메커니즘을 제공합니다. 자동 스케일링 메커니즘의 예시는 다음과 같습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/sus_sus_user_a2.html)
+ 확장은 대개 Amazon EC2 인스턴스나 AWS Lambda 함수 등의 컴퓨팅 서비스와 관련하여 설명하는 경우가 많습니다. [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 읽기/쓰기 용량 단위나 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 샤드와 같은 컴퓨팅 외의 서비스를 구성할 때는 수요에 일치시키는 것이 좋습니다.
+ 스케일 업 또는 스케일 다운 대한 지표가 배포 중인 워크로드 유형에 대해 검증되었는지 확인합니다. 동영상 트랜스코딩 애플리케이션을 배포하는 경우 100%의 CPU 활용률이 예상되므로, 기본 지표로 사용해서는 안 됩니다. 필요한 경우 [맞춤형 지표](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/)(예: 메모리 사용률)을 스케일링 정책에 사용할 수 있습니다. 올바른 지표를 선택하려면 Amazon EC2에 대한 다음 지침을 고려하세요.
+ 지표는 유효한 사용률 지표여야 하며 인스턴스가 얼마나 많이 사용되는지를 설명해야 합니다.
+ 지표 값은 Auto Scaling 그룹 내 인스턴스 수에 비례하여 늘거나 줄어야 합니다.
+ Auto Scaling 그룹에는 [수동 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) 대신 [동적 스케일링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)을 사용합니다. 또한, 동적 스케일링에는 [타겟 추적 스케일링 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)을 사용할 것을 권합니다.
+ 워크로드 배포에서 확장 및 축소 이벤트를 모두 처리할 수 있는지 확인합니다. 축소 이벤트에 대한 테스트 시나리오를 생성하여 워크로드가 예상대로 작동하고 사용자 환경에 영향(예: 스티키 세션 손실)을 미치지 않는지 확인합니다. [활동 기록](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)을 사용하여 Auto Scaling 그룹의 스케일링 활동을 확인할 수 있습니다.
+ 워크로드의 예측 가능한 패턴을 평가하고 예측 및 계획된 수요 변화에 따라 사전 예방적으로 확장합니다. 예측 스케일링에서는 용량을 과도하게 프로비저닝할 필요가 없습니다. 자세한 내용은 [Amazon EC2 Auto Scaling을 사용한 예측 스케일링](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)을 참조하세요.
## 리소스
**관련 문서:**
+ [Amazon EC2 Auto Scaling 시작하기](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and Kibana(Amazon OpenSearch Service, Amazon Kinesis Data Firehose 및 Kibana를 사용하여 사용자 행동 분석)](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [What is Amazon CloudWatch?(CloudWatch란 무엇인가요?)](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Monitoring DB load with Performance Insights on Amazon RDS(Amazon RDS의 성능 개선 도우미로 DB 로드 모니터링)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling(Amazon EC2 Auto Scaling을 사용한 예측 확장에 대한 기본 지원 소개)](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler(Karpenter - 고성능 오픈 소스 Kubernetes Cluster Autoscaler 소개)](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Deep Dive on Amazon ECS Cluster Auto Scaling(Elastic Container Service 클러스터 자동 스케일링 심층 분석)](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**관련 동영상:**
+ [Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2(더 정확하고, 더 빠르고, 더 저렴한 컴퓨팅: Amazon EC2 비용 최적화)(CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw)
**관련 예시:**
+ [실습: Amazon EC2 Auto Scaling 그룹 예시](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [실습: Karpenter를 사용하여 오토스케일링 구현](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 SLA를 지속 가능성 목표에 맞게 조정
지속 가능성 목표를 기준으로 서비스 수준에 관한 계약(SLA)을 검토 및 최적화하여 계속해서 비즈니스 필요를 충족하면서 워크로드를 지원하는 데 필요한 리소스를 최소화합니다.
**일반적인 안티 패턴:**
+ 워크로드 SLA가 알려져 있지 않거나 모호합니다.
+ 가용성 및 성능에 대해서만 SLA를 정의합니다.
+ 모든 워크로드에 대해 동일한 설계 패턴(예: 다중 AZ 아키텍처)을 사용합니다.
**이 모범 사례 확립의 이점:** 지속 가능성 목표에 맞춰 SLA를 조정하면 비즈니스 요구 사항을 충족하면서 리소스 사용을 최적화할 수 있습니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
SLA는 클라우드 워크로드에서 예상되는 서비스 수준(예: 응답 시간, 가용성, 데이터 보존 등)을 정의합니다. SLA는 클라우드 워크로드의 아키텍처, 리소스 사용 및 환경 영향에 영향을 미칩니다. 주기적으로 SLA를 검토하여 허용 가능한 수준으로 서비스를 줄여 리소스 사용을 크게 줄이는 절충안을 제시합니다.
**구현 단계**
+ 비즈니스 요구 사항을 충족하되 초과하지는 않으면서 지속 가능성 목표를 지원하는 SLA를 정의 또는 재설계합니다.
+ 허용 가능한 수준으로 서비스를 줄여 지속 가능성에 미치는 영향을 크게 줄이는 절충안을 제시합니다.
+ **지속 가능성 및 신뢰성:** 가용성이 뛰어난 워크로드는 리소스를 더 많이 사용하는 경향이 있습니다.
+ **지속 가능성 및 성능:** 성능을 높이기 위해 리소스를 더 많이 사용하면 환경에 미치는 영향이 커질 수 있습니다.
+ **지속 가능성 및 보안:** 지나치게 안전한 워크로드는 환경에 미치는 영향이 커질 수 있습니다.
+ 비즈니스에 중요한 기능에 우선순위를 두고 중요하지 않은 기능에 대해 더 낮은 서비스 수준(예: 응답 시간 또는 복구 시간 목표)을 허용하는 설계 패턴(예: [AWS의 마이크로서비스](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html))을 사용합니다.
## 리소스
**관련 문서:**
+ [AWS 서비스 수준에 관한 계약(SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)
+ [SaaS 공급자의 서비스 수준 계약 중요성](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**관련 동영상:**
+ [Delivering sustainable, high-performing architectures(지속 가능한 고성능 아키텍처 제공)](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [Build a cost-, energy-, and resource-efficient compute environment(비용, 에너지, 리소스 효율적인 컴퓨팅 환경 구축)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 미사용 자산의 생성 및 유지 관리 중지
워크로드에서 사용되지 않는 자산을 폐기하여 수요를 지원하는 데 필요한 클라우드 리소스 수를 줄이고 낭비를 최소화합니다.
**일반적인 안티 패턴:**
+ 중복되거나 더 이상 필요하지 않은 자산에 대해 애플리케이션을 분석하지 않습니다.
+ 중복되거나 더 이상 필요하지 않은 자산을 제거하지 않습니다.
**이 모범 사례 확립의 이점:** 사용되지 않는 자산을 제거하면 리소스가 확보되고 워크로드의 전체 효율성이 향상됩니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
사용되지 않는 자산은 스토리지 공간 및 컴퓨팅 전력과 같은 클라우드 리소스를 소비합니다. 이러한 자산을 식별하고 제거함으로써 리소스를 확보하여 클라우드 아키텍처의 효율성을 높일 수 있습니다. 애플리케이션 자산(예: 사전 컴파일된 보고서, 데이터 세트, 정적 이미지 등)과 자산 액세스 패턴을 정기적으로 분석하여 중복된 자산, 활용률이 낮은 자산 및 잠재적 폐기 대상을 식별합니다. 이러한 중복 자산을 제거하여 워크로드의 리소스 낭비를 줄이세요.
**구현 단계**
+ 모니터링 도구를 사용하여 더 이상 필요하지 않은 정적 자산을 식별합니다.
+ 자산을 제거하기 전에 제거로 인해 아키텍처가 받는 영향을 평가합니다.
+ 플랜을 세우고 더 이상 필요하지 않은 자산을 제거합니다.
+ 중복 생성 자산을 통합하여 중복 처리를 제거합니다.
+ 애플리케이션을 업데이트하여 더 이상 필요 없는 자산을 생성하고 저장하지 않습니다.
+ 더 이상 필요하지 않은 관리 자산의 생산 및 저장을 중단하도록 제3자에게 지시합니다.
+ 생성된 중복 자산을 통합하도록 제3자에게 지시합니다.
+ 워크로드를 정기적으로 검토하여 사용되지 않는 자산을 식별하고 제거합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)(지속 가능성을 위한 AWS 인프라 최적화, 파트 II: 스토리지)
+ [AWS 계정에서 더 이상 필요하지 않은 활성 리소스를 종료하려면 어떻게 해야 하나요? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**관련 동영상:**
+ [ How do I check for and then remove active resources that I no longer need on my AWS 계정?](https://www.youtube.com/watch?v=pqg9AqESRlg)(AWS 계정에서 더 이상 필요하지 않은 활성 리소스를 확인하고 제거하려면 어떻게 해야 하나요?)
# SUS02-BP04 네트워킹 요구 사항에 따라 워크로드의 지리적 배치 최적화
네트워크 트래픽이 이동해야 하는 거리를 단축하고 워크로드를 지원하는 데 필요한 총 네트워크 리소스를 줄일 수 있는 워크로드의 클라우드 위치 및 서비스를 선택합니다.
** 일반적인 안티 패턴: **
+ 자신의 고유한 위치를 기준으로 워크로드의 리전을 선택합니다.
+ 모든 워크로드 리소스를 하나의 지리적 위치로 통합합니다.
+ 모든 트래픽이 기존 데이터 센터를 통과합니다.
**이 모범 사례 확립의 이점:** 사용자에게 가깝게 워크로드를 배치하면 지연 시간을 최대한 단축할 수 있고 동시에 네트워크 간 데이터 이동을 줄이고 환경에 미치는 영향을 줄일 수 있습니다.
**이 모범 사례가 확립되지 않았을 경우의 위험 수준:** 보통
## 구현 가이드
AWS 클라우드 인프라는 리전, 가용 영역, 배치 그룹, 엣지 로케이션(예: [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 및 [AWS 로컬 영역)과](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)같은 위치 옵션을 중심으로 구축됩니다. 이러한 위치 옵션은 애플리케이션 구성 요소, 클라우드 서비스, 엣지 네트워크, 온프레미스 데이터 센터 간의 연결을 유지합니다.
워크로드의 네트워크 액세스 패턴을 분석하여 이러한 클라우드 위치 옵션을 사용하는 방법을 식별하고 네트워크 트래픽이 이동해야 하는 거리를 줄이십시오.
## 구현 단계
+ 워크로드의 네트워크 액세스 패턴을 분석하여 사용자가 애플리케이션을 사용하는 방법을 식별합니다.
+ 예를 들어 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 및 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)같은 모니터링 도구를 사용하여 네트워크 활동에 대한 데이터를 수집합니다.
+ 데이터를 분석하여 네트워크 액세스 패턴을 식별합니다.
+ 다음과 같은 주요 요소를 토대로 하여 워크로드 배포용 리전을 선택합니다.
+ **지속 가능성 목표:** 리전 선택 [에 설명되어 있습니다](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html).
+ **데이터 위치:** 데이터를 많이 사용하는 애플리케이션의 경우(예: 빅 데이터 및 기계 학습) 애플리케이션 코드는 최대한 데이터와 가까운 위치에서 실행되어야 합니다.
+ **사용자의 위치:** 사용자가 직접 사용하는 애플리케이션의 경우 워크로드의 사용자와 가까운 리전(또는 리전들)을 선택합니다.
+ **기타 제약 조건:** AWS 아키텍처 블로그 [워크로드의 리전을 선택할 때 고려해야 할 사항](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)에서 설명한 것처럼 비용 및 규정 준수 등의 제약을 고려해야 합니다.
+ 자주 사용되는 자산에 로컬 캐싱 또는 [AWS 캐싱 솔루션을](https://aws.amazon.com/caching/aws-caching/) 사용하여 성능을 개선하고 데이터 이동을 줄이며 환경에 미치는 영향을 줄입니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+ 워크로드 사용자에게 더 가까운 위치에서 코드를 실행할 수 있는 서비스를 사용합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+ 연결 풀을 사용하여 연결을 재사용하고 필요한 리소스를 줄입니다.
+ 지속적 연결 및 동기식 업데이트에 의존하지 않는 분산 데이터 스토어를 사용하여 리전별 사용자 집단을 일관되게 지원합니다.
+ 사전 프로비저닝된 정적 네트워크 용량을 공유 동적 용량으로 교체하고 네트워크 용량의 지속 가능성에 미치는 영향을 다른 구독자와 공유합니다.
## 리소스
**관련 문서:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking(지속 가능성을 위한 AWS 인프라 최적화, 파트 III: 네트워킹)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache 설명서](https://docs.aws.amazon.com/elasticache/index.html)
+ [Amazon CloudFront란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront 주요 기능](https://aws.amazon.com/cloudfront/features/)
**관련 동영상:**
+ [Demystifying data transfer on AWS(AWS에서의 데이터 전송 알아보기)](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ 차세대 Amazon EC2 인스턴스의 네트워크 성능 확장 ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
**관련 예시:**
+ [AWS 네트워킹 워크숍](https://catalog.workshops.aws/networking/en-US)
+ [ 지속 가능성을 위한 설계 - 네트워크 간 데이터 이동 최소화 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 수행된 활동에 대한 팀원 리소스 최적화
팀원에게 제공되는 리소스를 최적화하여 팀원에게 필요한 지원을 충분히 제공하면서도 환경 지속 가능성에 미치는 영향을 최소화합니다.
**일반적인 안티 패턴:**
+ 팀원이 사용하는 디바이스가 클라우드 애플리케이션의 전반적인 효율성에 미치는 영향을 무시합니다.
+ 팀원이 사용하는 리소스를 수동으로 관리하고 업데이트합니다.
**이 모범 사례 확립의 이점:** 팀원 리소스를 최적화하면 클라우드 지원 애플리케이션의 전반적인 효율성이 향상됩니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
팀원이 서비스를 사용하는 데 활용하는 리소스, 예상 수명 주기, 재무 및 지속 가능성에 미치는 영향을 이해합니다. 이러한 리소스를 최적화하기 위한 전략을 구현합니다. 예를 들어, 활용률이 낮은 고성능 단일 사용자 시스템 대신 활용률이 높은 확장 가능한 인프라에서 렌더링 및 컴파일과 같은 복잡한 작업을 수행합니다.
**구현 단계**
+ 사용 방식에 맞게 워크스테이션 및 기타 디바이스를 프로비저닝합니다.
+ 가상 데스크톱 및 애플리케이션 스트리밍을 사용하여 업그레이드 및 디바이스 요구 사항을 제한합니다.
+ 프로세서 또는 메모리 집약적인 태스크를 클라우드로 옮겨 탄력성을 활용합니다.
+ 디바이스 수명 주기에 대한 프로세스 및 시스템의 영향을 평가하고 비즈니스 요구 사항을 충족하면서 디바이스 교체 요구 사항을 최소화하는 솔루션을 선택합니다.
+ 디바이스에 대한 원격 관리를 구현하여 필요한 출장을 줄입니다.
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html)는 AWS 또는 온프레미스에서 실행 중인 노드를 원격으로 관리하는 데 도움이 되는 통합 사용자 인터페이스(UI) 환경입니다.
## 리소스
**관련 문서:**
+ [Amazon WorkSpaces란 무엇인가요?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [ Amazon WorkSpaces용 Cost Optimizer](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [Amazon AppStream 2.0 설명서](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**관련 동영상:**
+ [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE)(AWS에서 Amazon Workspaces의 비용 관리)
# SUS02-BP06 버퍼링 또는 제한 개선으로 수요 곡선 완화
버퍼링 및 제한은 수요 곡선을 완화하고 워크로드에 필요한 프로비저닝 용량을 줄입니다.
**일반적인 안티 패턴:**
+ 클라이언트 요청은 필요하지 않아도 즉시 처리합니다.
+ 클라이언트 요청에 대한 요구 사항을 분석하지 않습니다.
**이 모범 사례 확립의 이점:** 수요 곡선을 완화하면 워크로드에 필요한 프로비저닝 용량이 줄어듭니다. 프로비저닝 용량을 줄이면 에너지 소비와 환경에 미치는 영향도 줄어듭니다.
**이 모범 사례를 따르지 않을 경우 노출되는 위험 수준:** 낮음
워크로드 수요 곡선을 완화하면 워크로드에 프로비저닝된 용량을 줄이고 환경에 미치는 영향도 줄일 수 있습니다. 아래 그림에 표시된 수요 곡선을 바탕으로 워크로드를 가정합니다. 이 워크로드에는 2개의 정점이 있으며, 이러한 정점을 처리하기 위해 주황색 선으로 표시된 리소스 용량이 프로비저닝됩니다. 이 워크로드에 사용되는 리소스와 에너지는 수요 곡선 아래의 영역이 아니라 프로비저닝된 용량 선 아래의 영역으로 표시됩니다. 이 2가지 정점을 처리하려면 프로비저닝된 용량이 필요하기 때문입니다.
![\[높은 프로비저닝 용량을 필요로 하는 2개의 고유한 정점이 있는 프로비저닝된 용량 파형입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/images/provisioned-capacity-1.png)
버퍼링 또는 제한을 사용하여 수요 곡선을 수정하고 정점을 완화할 수 있습니다. 이렇게 되면 프로비저닝된 용량과 소비되는 에너지가 줄어듭니다. 클라이언트가 재시도를 수행할 때 제한을 구현합니다. 요청을 저장하고 나중에 처리하도록 버퍼링을 구현합니다.
![\[버퍼링 또는 제한을 사용하여 만든 정점이 완화된 워크로드를 표시하는 파형 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2023-04-10/framework/images/provisioned-capacity-2.png)
**구현 단계**
+ 클라이언트 요청을 분석하여 응답 방법을 결정합니다. 고려해야 할 질문은 다음과 같습니다.
+ 이 요청을 비동기식으로 처리할 수 있는가?
+ 클라이언트에 재시도 기능이 있는가?
+ 클라이언트에 재시도 기능이 있는 경우 현재 요청을 처리할 수 없으면 나중에 다시 시도해야 함을 소스에 알려주는 제한 기능을 구현할 수 있습니다.
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)를 사용하여 제한을 구현할 수 있습니다.
+ 재시도를 수행할 수 없는 클라이언트의 경우 수요 곡선을 완화하려면 버퍼를 구현해야 합니다. 버퍼는 서로 다른 속도로 실행되는 애플리케이션이 효과적으로 통신할 수 있도록 요청 처리를 연기합니다. 버퍼 기반 접근 방식은 대기열 또는 스트림을 사용하여 생산자의 메시지를 수락합니다. 메시지는 소비자가 읽은 후 처리되므로 소비자의 비즈니스 요구 사항을 충족하는 속도로 메시지를 실행할 수 있습니다.
+ [Amazon Simple Queue Service(Amazon SQS)](https://aws.amazon.com/sqs/)는 단일 소비자가 개별 메시지를 읽을 수 있는 대기열을 제공하는 관리형 서비스입니다.
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)에서는 여러 소비자가 같은 메시지를 읽을 수 있는 스트림을 제공합니다.
+ 전체 수요, 변경률 및 필수 응답 시간을 분석하여 필요한 제한 또는 버퍼의 크기를 적절하게 조정합니다.
## 리소스
**관련 문서:**
+ [Amazon SQS 시작하기](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Application integration Using Queues and Messages](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)(대기열 및 메시지를 사용한 애플리케이션 통합)
**관련 동영상:**
+ [ Choosing the Right Messaging Service for Your Distributed App](https://www.youtube.com/watch?v=4-JmX6MIDDI)(분산형 앱에 적합한 메시징 서비스 선택)