

# REL 7  수요 변경에 따라 조정되도록 워크로드를 설계하려면 어떻게 해야 합니까?
<a name="w2aac19b9b9b7"></a>

확장 가능한 워크로드는 리소스를 자동으로 추가하거나 제거하여 특정 시기의 수요에 리소스 공급을 맞출 수 있는 탄력성을 제공합니다.

**Topics**
+ [REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 워크로드 장애 감지 시 리소스 확보](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 워크로드 로드 테스트](rel_adapt_to_changes_load_tested_adapt.md)

# REL07-BP01 리소스를 확보하거나 조정할 때 자동화 사용
<a name="rel_adapt_to_changes_autoscale_adapt"></a>

 손상된 리소스를 교체하거나 워크로드 크기를 조정할 때 Amazon S3 및 AWS Auto Scaling과 같은 관리형 AWS 서비스를 사용하여 프로세스를 자동화합니다. 서드 파티 도구 및 AWS SDK를 사용하여 크기를 자동 조정할 수도 있습니다. 

 관리형 AWS 서비스에는 Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate, Amazon Route 53가 있습니다. 

 AWS Auto Scaling을 사용하면 손상된 인스턴스를 감지하고 교체할 수 있습니다. 또한 [Amazon EC2](https://aws.amazon.com/ec2/) 인스턴스 및 스팟 플릿, [Amazon ECS](https://aws.amazon.com/ecs/) 태스크, [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 테이블 및 인덱스와 [Amazon Aurora](https://aws.amazon.com/aurora/) 복제본에 대한 조정 계획을 수립할 수도 있습니다. 

 EC2 인스턴스의 크기를 조정할 때는 여러 가용 영역(3개 이상 권장)을 사용하고 용량을 추가하거나 제거하여 이러한 가용 영역 간의 균형을 유지해야 합니다. ECS 태스크 또는 Kubernetes 포드(Amazon Elastic Kubernetes Service를 사용하는 경우) 역시 여러 개의 가용 영역에 분산되어야 합니다. 

 AWS Lambda를 사용하는 경우에는 인스턴스가 자동으로 조정됩니다. 함수에 대한 이벤트 알림이 수신될 때마다 AWS Lambda가 컴퓨팅 플릿 내에서 여유 용량을 신속하게 찾고 할당된 동시성까지 코드를 실행합니다. 사용자는 필요한 동시성이 특정 Lambda와 Service Quotas에 구성되어 있는지 확인해야 합니다. 

 Amazon S3는 높은 요청 속도를 처리하도록 자동으로 확장됩니다. 예를 들어 애플리케이션은 버킷에서 접두사마다 초당 3,500개 이상의 PUT/COPY/POST/DELETE 및 5,500개의 GET/HEAD 요청을 전송할 수 있습니다. 버킷의 접두사 수에는 제한이 없습니다. 읽기를 병렬화하여 읽기 또는 쓰기 성능을 높일 수 있습니다. 예를 들어 Amazon S3 버킷에서 10개의 접두사를 생성하여 읽기를 병렬화하는 경우 읽기 성능을 초당 55,000개의 읽기 요청으로 확장할 수 있습니다. 

 Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. CDN은 더 빠른 최종 사용자 응답 시간을 제공할 수 있으며 콘텐츠 요청을 캐시에서 처리하므로 워크로드의 크기를 확대할 필요가 줄어듭니다. 

 **일반적인 안티 패턴:** 
+  자동 복구를 위해 Auto Scaling 그룹을 구현하지만 탄력성은 구현하지 않음 
+  Auto Scaling을 사용하여 트래픽의 대규모 증가에 대응 
+  고도의 상태 저장 애플리케이션을 배포하여 탄력성 옵션을 없앰 

 **이 모범 사례 수립의 이점:** 자동화는 리소스를 배포하고 폐기할 때 수작업으로 인한 오류가 발생할 가능성을 없앱니다. 자동화는 배포 또는 폐기 요구 사항에 대한 느린 대응으로 인해 비용이 초과하거나 서비스가 거부될 위험성을 없앱니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  AWS Auto Scaling을 구성하고 사용합니다. 애플리케이션을 모니터링하고 용량을 자동으로 조정하여 최저 비용으로 안정적이고 예측 가능한 성능을 유지할 수 있습니다. AWS Auto Scaling을 사용하면 여러 서비스에 걸쳐 여러 리소스에 대한 애플리케이션 크기 조정을 설정할 수 있습니다. 
  +  [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
    +  Amazon EC2 인스턴스, 스팟 플릿, Amazon ECS 태스크, Amazon DynamoDB 테이블 및 인덱스, Amazon Aurora 복제본, AWS Marketplace 어플라이언스에 적절하게 Auto Scaling을 구성합니다. 
      +  [DynamoDB Auto Scaling을 통한 처리량 용량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
        +  서비스 API 작업을 사용하여 경보, 확장 정책, 가동 준비 시간 및 중단 시간을 지정합니다. 
+  Elastic Load Balancing을 사용합니다. 로드 밸런서는 경로별 또는 네트워크 연결별로 로드를 분산할 수 있습니다. 
  +  [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
    +  Application Load Balancers는 경로별로 로드를 배포할 수 있습니다. 
      +  [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
        +  도메인 이름의 하위 경로를 기준으로 다른 워크로드에 트래픽을 분산하도록 Application Load Balancer를 구성합니다. 
        +  Application Load Balancers를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다. 
          +  [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
    +  Network Load Balancer는 연결별로 로드를 분산합니다. 
      +  [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
        +  TCP를 사용하여 다른 워크로드로 트래픽을 분산하도록 Network Load Balancer를 구성하거나 워크로드가 일정한 IP 주소 집합을 갖도록 합니다. 
        +  Network Load Balancer를 사용해 AWS Auto Scaling과 통합하는 방식으로 수요를 관리해 로드를 분산할 수 있습니다. 
+  가용성 높은 DNS 공급자를 사용합니다. DNS 이름을 사용하면 사용자가 IP 주소 대신 이름을 입력하여 워크로드에 액세스하고 이 정보를 정의된 범위, 즉 일반적으로 워크로드 사용자의 경우 전역적으로 배포할 수 있습니다. 
  +  Amazon Route 53 또는 신뢰할 수 있는 DNS 제공업체를 사용합니다. 
    +  [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  Route 53를 사용하여 CloudFront 배포 및 로드 밸런서를 관리합니다. 
    +  관리할 도메인 및 하위 도메인을 결정하십시오. 
    +  ALIAS 또는 CNAME 레코드를 사용하여 적절한 레코드 세트를 생성합니다. 
      +  [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 
+  AWS 글로벌 네트워크를 사용하여 사용자로부터 애플리케이션으로의 경로를 최적화합니다. AWS Global Accelerator는 30초 이내에 애플리케이션 엔드포인트의 상태를 지속적으로 모니터링하고 트래픽을 정상 엔드포인트로 리디렉션합니다. 
  +  AWSGlobal Accelerator는 로컬 또는 글로벌 사용자에 대해 애플리케이션의 가용성과 성능을 개선하는 서비스입니다. Application Load Balancers, Network Load Balancer 또는 Amazon EC2 인스턴스 등, 하나 또는 여러 AWS 리전에서 애플리케이션 엔드포인트에 고정된 진입점 역할을 하는 고정 IP 주소를 제공합니다. 
    +  [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  Amazon CloudFront 또는 신뢰할 수 있는 콘텐츠 전송 네트워크(CDN)를 구성하고 사용합니다. 콘텐츠 전송 네트워크를 사용하면 최종 사용자 입장에서는 응답 시간을 단축할 수 있으며 워크로드를 불필요하게 확장할 수 있는 콘텐츠 요청을 처리할 수 있습니다. 
  +  [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
    +  워크로드에 Amazon CloudFront 배포를 구성하거나 서드 파티 CDN을 사용합니다. 
      +  CloudFront의 IP 범위를 엔드포인트 보안 그룹 또는 액세스 정책에 사용함으로써 워크로드에 대한 액세스를 제한하여 CloudFront에서만 액세스할 수 있도록 할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [오토 스케일링 그룹과 함께 로드 밸런서 사용](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) 
+  [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
+  [AWS Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html) 
+  [Amazon CloudFront란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected) 
+  [Amazon Route 53란 무엇입니까?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Elastic Load Balancing이란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [Network Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 
+  [Application Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 
+  [레코드 작업](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) 

# REL07-BP02 워크로드 장애 감지 시 리소스 확보
<a name="rel_adapt_to_changes_reactive_adapt_auto"></a>

 가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다. 

 먼저 상태 확인과 이러한 확인에 대한 기준을 구성하여 리소스 부족으로 인해 가용성이 영향을 받는 시기를 나타내야 합니다. 그런 다음 적절한 담당자에게 수동으로 리소스를 조정하도록 알리거나 자동화를 트리거하여 자동으로 리소스를 조정합니다. 

 워크로드에 맞게 적절하게 수동으로 규모를 조정할 수 있습니다. 예를 들어 AWS Management Console 또는 AWS CLI를 통해 Auto Scaling 그룹의 EC2 인스턴스 수를 변경하거나 DynamoDB 테이블의 처리량을 수정할 수 있습니다. 하지만 가능한 경우에는 항상 자동화를 사용해야 합니다( **리소스를 확보하거나 조정할 때 자동화 사용**)는 SAP NetWeaver Guide Finder 및 SAP NetWeaver Security Guide를 참조하세요. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  워크로드 장애 감지 시 리소스를 확보합니다. 가용성이 영향을 받는 경우 필요에 따라 리소스를 사후에 확장하여 워크로드 가용성을 복원합니다. 
  +  AWS Auto Scaling의 핵심 구성 요소인 크기 조정 계획을 사용하여 리소스 크기 조정을 위한 지침 집합을 구성합니다. AWS CloudFormation을 사용하거나 AWS 리소스에 태그를 추가하는 경우 애플리케이션마다 서로 다른 리소스 집합에 대해 크기 조정 계획을 설정할 수 있습니다. AWS Auto Scaling은 각 리소스에 맞춤화된 크기 조정 전략에 대한 권장 사항을 제공합니다. 크기 조정 계획을 생성하면 AWS Auto Scaling이 동적 조정과 예측 조정 방식을 결합하여 조정 전략을 지원합니다. 
    +  [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
  +  Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리하는 데 사용할 수 있는 적절한 수의 Amazon EC2 인스턴스를 확보할 수 있습니다. Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 사용하면 그룹의 크기가 이 값 아래로 내려가지 않게 합니다. 각 오토 스케일링 그룹의 최대 인스턴스 수를 지정할 수 있으며, Amazon EC2 Auto Scaling은 그룹의 크기가 이 값을 초과하지 않게 합니다. 
    +  [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 
  +  Amazon DynamoDB Auto Scaling은 AWS Application Auto Scaling 서비스를 사용하여 사용자를 대신해 실제 트래픽 패턴에 따라 프로비저닝된 처리량 용량을 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스를 통해 프로비저닝된 읽기 및 쓰기 용량을 늘려 조절 없이 급증하는 트래픽을 처리할 수 있습니다. 
    +  [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [APN 파트너: 자동화된 컴퓨팅 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27) 
+  [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html) 
+  [Amazon EC2 Auto Scaling이란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP03 워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스 확보
<a name="rel_adapt_to_changes_proactive_adapt_auto"></a>

 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다. 

 많은 AWS 서비스가 수요에 맞춰 자동으로 확장됩니다. Amazon EC2 인스턴스 또는 Amazon ECS 클러스터를 사용하는 경우 워크로드 수요에 해당하는 사용량 지표에 따라 이러한 자동 조정이 수행되도록 구성할 수 있습니다. Amazon EC2의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 또는 네트워크 대역폭을 사용하여 EC2 인스턴스를 스케일아웃(또는 스케일인)할 수 있습니다. Amazon ECS의 경우 평균 CPU 사용률, 로드 밸런서 요청 수 및 메모리 사용률을 사용하여 ECS 작업을 스케일 아웃(또는 스케일 인)할 수 있습니다. AWS에서 Target Auto Scaling을 사용하면 Autoscaler가 가정용 온도 조절기처럼 작동하여 리소스를 추가하거나 제거함으로써 지정한 목표 값(예: 70%의 CPU 사용률)을 유지합니다. 

 또한 AWS Auto Scaling은 기계 학습을 사용하여 각 리소스의 기간별 워크로드를 분석하고 향후 2일간의 로드를 주기적으로 예측하는 [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)을 수행할 수도 있습니다. 

 리틀의 법칙은 필요한 컴퓨팅 인스턴스(EC2 인스턴스, 동시 Lambda 함수 등) 수를 계산하는 데 도움이 됩니다. 

 *L* = *λW* 

 L = 인스턴스 수(또는 시스템의 평균 동시성) 

 λ = 요청이 도착하는 평균 속도(요청/초) 

 W = 시스템이 각 요청에 소비하는 평균 시간(초) 

 예를 들어 100rps에서 각 요청을 처리하는 데 0.5초가 걸리는 경우 수요를 따라가려면 50개의 인스턴스가 필요합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  워크로드에 더 많은 리소스가 필요한 것으로 감지되면 리소스를 확보합니다. 수요를 충족하고 가용성에 영향을 미치지 않도록 리소스를 사전에 확장합니다. 
  +  지정된 요청 속도를 처리하는 데 필요한 컴퓨팅 리소스(컴퓨팅 동시성)를 계산합니다. 
    +  [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
  +  사용량에 대한 과거 패턴이 있는 경우 Amazon EC2 Auto Scaling에 대한 예약된 조정을 설정합니다. 
    +  [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
  +  AWS 예측 크기 조정을 사용합니다. 
    +  [Predictive Scaling for EC2, Powered by Machine Learning(기계 학습 기반 EC2용 예측 확장)](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Auto Scaling: 조정 계획 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html) 
+  [AWS Marketplace: 오토 스케일링과 함께 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling) 
+  [DynamoDB Auto Scaling을 통한 처리량 자동 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.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/) 
+  [Amazon EC2 Auto Scaling의 예약된 조정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) 
+  [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html) 
+  [Amazon EC2 Auto Scaling란 무엇입니까?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 

# REL07-BP04 워크로드 로드 테스트
<a name="rel_adapt_to_changes_load_tested_adapt"></a>

 확장 작업이 워크로드의 필요 사항을 충족하는지 측정하기 위한 로드 테스트 방식을 채택하십시오. 

 지속적인 로드 테스트를 수행하는 것이 중요합니다. 로드 테스트를 통해 한계점을 찾고 워크로드의 성능을 테스트할 수 있습니다. AWS를 사용하면 프로덕션 워크로드의 규모를 모델링하는 임시 테스트 환경을 쉽게 설정할 수 있습니다. 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇 분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다. 

 또한 프로덕션에서의 로드 테스트는 프로덕션 시스템에 스트레스가 가해지는 실전 연습의 일부로 간주되어야 하며 고객 사용량이 적은 시간에는 모든 직원이 결과를 해석하고 발생하는 문제를 해결해야 합니다. 

 **일반적인 안티 패턴:** 
+  구성이 프로덕션 환경과 동일하지 않은 배포에 대해 로드 테스트 수행 
+  전체 워크로드가 아니라 워크로드의 개별 부분에 대해서만 로드 테스트 수행 
+  대표적인 실제 요청 세트가 아니라 요청의 하위 집합을 사용하여 로드 테스트 수행 
+  예상 부하보다 작은 안전 계수로 부하 테스트 수행 

 **이 모범 사례 수립의 이점:** 로드 시 장애가 발생하는 아키텍처의 구성 요소를 알고 있으며, 해당 로드에 곧 도달할 것임을 나타내는 지표를 식별하고 조사하여 문제를 해결할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  로드 테스트를 수행하여 워크로드의 어느 측면에 용량을 추가 또는 제거해야 하는지 파악합니다. 로드 테스트에는 프로덕션 환경에서 수신하는 것과 유사한 대표 트래픽이 있어야 합니다. 계측한 지표를 모니터링하면서 로드를 늘려 리소스를 추가 또는 제거해야 하는 시점을 나타내는 지표를 결정합니다. 
  +  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 
    +  요청의 조합을 식별합니다. 다양한 요청 조합이 있을 수 있으므로 트래픽 조합을 식별할 때 다양한 시간 프레임을 살펴봐야 합니다. 
    +  로드 드라이버를 구현합니다. 사용자 지정 코드, 오픈 소스 또는 상용 소프트웨어를 사용하여 로드 드라이버를 구현할 수 있습니다. 
    +  처음에는 작은 용량을 사용하여 로드 테스트를 수행합니다. 인스턴스 또는 컨테이너 하나 정도의 작은 용량으로 로드를 유도하면 즉각적인 효과가 나타납니다. 
    +  더 큰 용량에 대해 로드 테스트를 수행합니다. 분산된 부하에서는 효과가 다르게 나타나므로 가능한 한 제품 환경에 가깝게 테스트해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/) 