# COST 9 どのように需要を管理し、リソースを供給すればよいですか? 費用とパフォーマンスのバランスが取れたワークロードを作成するには、費用を掛けたすべてのものが活用されるようにし、使用率が著しく低いインスタンスが生じるのを回避します。利用が過剰でも過少でも偏りが生じると、運用コスト (利用過剰によるパフォーマンスの低下) または無駄な AWS 費用 (過剰なプロビジョニング) のいずれかで、組織に悪影響が及びます。 **Topics** + [COST09-BP01 ワークロードの需要に関する分析を実行する](cost_manage_demand_resources_cost_analysis.md) + [COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する](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) またはアプリケーションログとともに使用して、視覚的に分析できます。 **実装手順** + ** 既存のワークロードデータを分析する: **既存のワークロード、以前のバージョンのワークロード、または予測された使用パターンのデータを分析します。ログファイルとモニタリングデータを使用して、顧客がワークロードをどのように使用しているかについての洞察を得ます。一般的なメトリクスは、実際の需要 (1 秒あたりのリクエスト数)、需要率が変化するか異なるレベルとなるタイミング、および需要の変化率です。ワークロードの全サイクルを分析し、月末や年末のイベントなどの季節的な変化のデータを収集します。分析に反映される労力は、ワークロードの特性を反映する必要があります。最大の労力は、需要に最も大きな変化がある価値の高いワークロードに割り当てられる必要があります。需要の変化が最小である低価値のワークロードには、最小の労力を割り当てる必要があります。価値の一般的なメトリクスは、リスク、ブランド認知、収益、ワークロードのコストです。 + ** 外部の影響を予測する: **組織全体において、ワークロードの需要に影響を与え、または変化させる可能性のあるチームメンバーとミーティングを行います。一般的なチームは販売、マーケティング、ビジネス開発です。当該メンバーと協力して、業務のサイクルや、ワークロードの需要を変化させるイベントがあるかどうかを把握します。このデータを使用してワークロードの需要を予測します。 ## リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS での Instance Scheduler](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-BP01 需要を管理するためのバッファまたはスロットルを実装する バッファリングとスロットリングは、ワークロードの需要を修正し、ピークを滑らかにします。クライアントが再試行を実行するときにスロットリングを実行します。バッファリングは、リクエストを保存し、後日まで処理を延期するために実装します。スロットルとバッファが、クライアントが要求された時間内にレスポンスを受け取るように設計されていることを確認します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス **スロットリング:** 需要元のソースに再試行機能がある場合は、スロットリングを実装できます。現在リクエストを処理できない場合は、後で再試行する必要があることがスロットリングによってソースに通知されます。ソースでは一定時間待機してから、リクエストが再試行されます。スロットリングの運用には、リソースの最大量およびワークロードのコストを制限できるという利点があります。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/) は、1 人のコンシューマーが個別のメッセージを読むことができるキューを提供するマネージドサービスです。[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 での 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/) + [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 を使用して [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/)で確認されたリクエストとレスポンスのレイテンシーなどがあります。可能な場合は、カスタマーエクスペリエンスの指標となるメトリクスを使用する必要があります。このメトリクスは一般には、ワークロード内のアプリケーションコードから生成されるカスタムメトリクスです。 需要ベースのアプローチで設計する場合、主に 2 つの点を考慮する必要があります。第 1 に、新しいリソースをどれだけ早くプロビジョニングする必要があるかを理解することです。第 2 に、需要と供給の差異が変動することを理解することです。需要の変動ペースに対処できるようにしておくだけでなく、リソースの不具合にも備えておく必要があります。 [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) Elastic Volumes などのリソースにも適用できます。 時間ベースのアプローチを設計する際は、主に 2 つの点を考慮する必要があります。1 つ目は使用パターンの一貫性についてであり、 第 2 に、パターンを変更した場合の影響です。 予測精度は、ワークロードをモニタリングし、ビジネスインテリジェンスを使用することで高めることができます。使用パターンに大幅な変更がある場合は、時間を調整して予測対象範囲に収まるようにします。 **実装手順** + ** 時間ベースのスケジューリングを設定する: **需要の変化を予測できるため、時間ベースのスケーリングは適切な数のリソースを適時に提供できます。また、リソースの作成と設定が、需要の変化に対応するのに十分ではない場合にも役立ちます。ワークロード分析を活用して、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/) + [Getting Started With 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)