# PERF02-BP05 利用可能な伸縮性のあるリソースを使用する
クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。この伸縮性をコンピューティング関連のメトリクスと組み合わせることによって、ワークロードは変更に自動的に対応して、必要なリソースのみを使用することができます。
**一般的なアンチパターン:**
+ 予想されるスパイクに対応するためにオーバープロビジョニングする。
+ アラームに対応するために手動でキャパシティーを増やす。
+ プロビジョニングにかかる時間を考慮に入れずにキャパシティーを増やす。
+ スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。
+ ワークロードの実際の要件を直接反映していないメトリクスをモニタリングする。
**このベストプラクティスを活用するメリット:** 需要は、一定である場合も、変動する場合も、あるパターンに従う場合も、スパイクが発生しやすい場合もあります。需要と供給をマッチングすることで、ワークロードのコストを最低限に抑えることができます。ワークロードの伸縮性をモニタリング、テスト、設定することで、需要の変化に応じてパフォーマンス最適化、コスト低減、信頼性の向上を実現できます。これに対して手動で対応するアプローチも可能であるとはいえ、大規模な場合は非実用的です。自動化したメトリクスベースのアプローチを採用することで、どの時点でもリソースが確実に需要を満たすようにすることができます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
リソースの供給が、ワークロードが求めるリソースの需要とマッチすることを目標に、伸縮性を活用するために、メトリクスベースのオートメーションを使用する必要があります。例えば、[リソースのモニタリングに Amazon CloudWatch メトリクス](https://aws.amazon.com/startups/start-building/how-to-monitor-resources/)を使用したり、Auto Scaling グループには Amazon CloudWatch メトリクスを使用したりすることができます。
コンピューティング関連のメトリクスと組み合わせることによって、ワークロードは自動的に変化に対応し、最適な一連のリソースを利用して目標を達成できるようになります。プロビジョニングにかかる時間と予想されるリソース障害を考慮に入れて計画を策定する必要があります。
インスタンス、コンテナ、関数には、伸縮性のためのメカニズムがあり、サービスの一部として、[Application Auto Scaling](https://aws.amazon.com/autoscaling/) で、または [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) と組み合わせて提供されます。アーキテクチャの伸縮性を活用して、広範囲の規模の使用におけるパフォーマンス要件を満たすために十分なキャパシティーがあることを確認します。
デプロイされているワークロードのタイプに対して、伸縮自在なリソースのスケールアップまたはスケールダウンのメトリクスが検証されていることを確認します。例えば、動画トランスコーディングアプリケーションをデプロイする場合、CPU 使用率は 100% となることが想定されるため、主要なメトリクスにするべきではありません。代替手段として、インスタンスタイプのスケーリングを待機しているトランスコーディングジョブのキューの深さに対して測定することができます。
ワークロードのデプロイは、スケールアップとスケールダウンの両方のイベントに対処できる必要があります。ワークロードコンポーネントを安全にスケールダウンすることは、需要があるときにリソースをスケールアップするのと同じくらい重要です。
スケーリングイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。
**実装手順**
+ 履歴データを活用して、経時的なワークロードのリソース需要を分析します。以下のような具体的な事項を検討します。
+ ワークロードは安定しており、経時的に既知の割合で増加しているか。
+ ワークロードは、季節的な繰り返しのパターンで増減しているか。
+ ワークロードはスパイクが発生しやすいか。 スパイクは予想したり予測したりできるか。
+ モニタリングサービスと履歴データを可能な限り活用します。
+ リソースにタグ付けすると、モニタリングに役立ちます。タグを使用する場合は、「[Tagging Best Practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) (タグ付けのベストプラクティス)」を参照してください。また、[タグを使用すると、リソースの管理、特定、整理に役立ちます](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。
+ AWS では、さまざまなアプローチで需要と供給を一致させることができます。コスト最適化の柱のベストプラクティス ([COST09-BP01～COST09-03](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/manage-demand-and-supply-resources.html)) では、以下のアプローチを採用してコストを低減する方法について説明しています。
+ [COST09-BP01 ワークロードの需要に関する分析を実行する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_cost_analysis.html)
+ [COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_buffer_throttle.html)
+ [COST09-BP03 リソースを動的に供給する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_manage_demand_resources_dynamic.html)
+ スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。
+ 本稼働用以外のほとんどのインスタンスは、使用されていないときに停止するべきです。
+ Amazon Elastic Block Store (Amazon EBS) を使用する場合のストレージのニーズについては、[ボリュームベースの伸縮性](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)を活用します。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) については、[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)の使用を検討してください。これにより、需要のスパイク発生時にコンピューティングインスタンスの数を自動的に増やし、需要の減少時にキャパシティーを減らして、パフォーマンスとコストを最適化できます。
## リソース
**関連するベストプラクティス:**
+ [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md)
+ [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md)
+ [PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する](perf_select_compute_use_metrics.md)
**関連するドキュメント:**
+ [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/)
+ [Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html)
+ [Amazon EKS コンテナ: Amazon EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
**関連動画:**
+ [Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) (Amazon EC2 の基礎 (CMP211-R2))
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1))
+ [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) (AWS Inferentia を使用して高パフォーマンスの機械学習推論を実現する (CMP324-R1))
+ [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) (AWS コンピューティングのパフォーマンスとコストを最適化する)
+ [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) (次世代 EC2 の強化: Nitro System の詳細)
**関連する例:**
+ [Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [Amazon EFS チュートリアル](https://github.com/aws-samples/amazon-efs-tutorial)