# COST09-BP03 リソースを動的に供給する
<a name="cost_manage_demand_resources_dynamic"></a>

リソースを計画的にプロビジョニングします。これは、自動スケーリングなどの需要ベース、または需要が予測可能でリソースが時間に基づいて提供される時間ベースで行います。これらの手法を使用すると、過剰プロビジョニングやプロビジョニング不足を最小限に抑えることができます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 AWS のお客様がアプリケーションに利用できるリソースを増やし、需要に合わせてリソースを供給する方法はいくつかあります。その 1 つが AWS Instance Scheduler を使用した方法です。これにより、Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Relational Database Service (Amazon RDS) インスタンスの起動および停止を自動化します。もう 1 つの方法は AWS Auto Scaling を使用することです。この方法では、アプリケーションやサービスの需要に基づいてコンピューティングリソースを自動的にスケールできます。需要に応じてリソースを供給することで、使用したリソースに対してのみ支払いを行い、必要なときにリソースを起動してコストを削減し、必要でないときにリソースを終了することができます。

 [AWS Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) を使用すると、Amazon EC2 インスタンスや Amazon RDS インスタンスを決まった時間に停止および開始するように設定できます。これにより、例えばユーザーが毎朝 8 時に Amazon EC2 インスタンスにアクセスし、夜 6 時以降は必要としないなど、一貫した時間パターンがある同一リソースの需要に応えることができます。この解決方法では、リソースを使用しないときは停止し、必要なときに開始することで、運用コストを削減できます。

![\[AWS Instance Scheduler を使用したコスト最適化を示す図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/instance-scheduler-diagram.png)


 

また、AWS Systems Manager Quick Setup を使用してシンプルなユーザーインターフェイス (UI) を使用して、アカウントやリージョン全体で Amazon EC2 インスタンスのスケジュールを簡単に設定できます。AWS Instance Scheduler を使用して Amazon EC2 または Amazon RDS インスタンスをスケジュールでき、既存のインスタンスを停止および起動できます。ただし、Auto Scaling グループ (ASG) の一部であるインスタンス、または Amazon Redshift や Amazon OpenSearch Service などのサービスを管理するインスタンスを停止/開始することはできません。Auto Scaling グループには、グループ内のインスタンスに対して独自のスケジューリングがあり、このスケジュールに基づいてインスタンスが作成されます。

[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) により、変化する需要に対応するためにキャパシティを調整して、最低限のコストで安定かつ予測可能なパフォーマンスを維持できます。これは、Amazon EC2 インスタンスおよびスポットフリート、Amazon ECS、Amazon DynamoDB、Amazon Aurora と統合するアプリケーションの容量をスケールするためのフルマネージドで無料のサービスです。自動スケーリングでは、リソースの自動検出によってワークロード内の設定可能なリソースを検出できます。また、パフォーマンス、コスト、または両者のバランスを最適化するためのスケーリング戦略が組み込まれており、予測スケーリングによって定期的に発生する急増に対応することができます。

 Auto Scaling グループをスケーリングするには、複数のスケーリングオプションを使用できます。
+  現在のインスタンスレベルの常時維持 
+  手動でスケールする 
+  スケジュールに基づくスケーリング 
+  需要に基づくスケーリング 
+  予測スケーリングの使用 

 自動スケーリングポリシーは異なり、動的スケーリングポリシーとスケジュールスケーリングポリシーに分類できます。動的ポリシーには、手動または動的スケーリング、スケジュールスケーリングまたは予測スケーリングがあります。スケーリングポリシーは、動的スケーリング、スケジュールスケーリング、予測スケーリングに使用できます。[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) のメトリクスとアラームを使用して、ワークロードのスケーリングイベントをトリガーすることもできます。最新の機能や改善点にアクセスできるように、[起動テンプレート](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)を使用することをお勧めします。起動設定を使用する場合、すべての自動スケーリング機能を使用できるわけではありません。たとえば、スポットインスタンスとオンデマンドインスタンスの両方を起動する Auto Scaling グループや、複数のインスタンスタイプを指定する Auto Scaling グループを作成することはできません。これらの機能を設定するには、起動テンプレートを使用する必要があります。起動テンプレートを使用するときは、それぞれバージョンを作成することをお勧めします。起動テンプレートのバージョン管理では、パラメータのフルセットのサブセットを作成できます。その後、再使用して、同じ起動テンプレートの他のバージョンを作成できます。

 AWS Auto Scaling を使用するか、[AWS API または SDK](https://aws.amazon.com/developer/tools/) でコードにスケーリングを実装できます。これにより、環境を手動変更していた運用コストがなくなり、その結果、全体的なワークロードコストが削減され、変更をより迅速に実行できるようになります。またこれにより、いつでもワークロードのリソースを需要に合わせて調達できます。ベストプラクティスに従って組織に動的にリソースを供給するには、AWS クラウドの水平スケーリングおよび垂直スケーリングと、Amazon EC2 インスタンスで実行されるアプリケーションの特性を理解する必要があります。このベストプラクティスに従うには、クラウド財務管理チームとテクニカルチームが協働することをお勧めします。

 [Elastic Load Balancing (Elastic Load Balancing)](https://aws.amazon.com/elasticloadbalancing/) は、複数のリソースに需要を分散させることでスケーリングに役立ちます。ASG と Elastic Load Balancing を使用して、トラフィックを最適にルーティングして受信リクエストを管理し、Auto Scaling グループ内の 1 つのインスタンスに負荷がかかりすぎないようにすることができます。リクエストは、キャパシティや使用率を考慮せずに、ラウンドロビン方式でターゲットグループのすべてのターゲットに分散されます。

 一般的な Amazon EC2 メトリクスは、CPU 使用率、ネットワークスループット、Elastic Load Balancing で確認されたリクエストとレスポンスのレイテンシーなどの標準メトリクスです。可能な場合は、カスタマーエクスペリエンスの指標となるメトリクスを使用する必要があります。このメトリクスは一般には、ワークロード内のアプリケーションコードから生成されるカスタムメトリクスです。このドキュメントでは、需要を動的に満たす方法を詳しく説明するために、自動スケーリングを需要ベースの供給モデルと時間ベースの供給モデルの 2 つのカテゴリに分類し、それぞれについて詳しく説明します。

**需要ベースの供給:** クラウドの伸縮性を活用して、ほぼリアルタイムの需要状況に応じて、変化する需要に対応するリソースを供給できます。需要ベースの供給の場合、API やサービス機能を活用すると、アーキテクチャ内のクラウドリソースの量をプログラムで変更できます。これにより、アーキテクチャ内のコンポーネントをスケールしたり、需要が急増したときにリソースの数を増加させてパフォーマンスを維持したり、需要が後退したときにキャパシティを減少させてコストを節減したりできます。

![\[シンプル/ステップスケーリングやターゲットトラッキングなどの需要ベースのスケーリングポリシーを説明する図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/demand-based-supply.png)


 
+  **シンプル/ステップスケーリング:** メトリクスをモニタリングし、ユーザーが手動で定義したステップに従ってインスタンスを追加/削除します。
+  **ターゲット追跡:** サーモスタットのような制御メカニズムで、インスタンスを自動的に追加または削除して、メトリクスをユーザー定義の目標に維持します。

需要ベースのアプローチで設計する場合、主に 2 つの点を考慮する必要があります。第 1 に、新しいリソースをどれだけ早くプロビジョニングする必要があるかを理解することです。第 2 に、需要と供給の差異が変動することを理解することです。需要の変動ペースに対処できるようにしておくだけでなく、リソースの不具合にも備えておく必要があります。

**時間ベースの供給:** 時間ベースのアプローチでは、リソースのキャパシティを予測可能な需要、または時間ごとに明確に定義された需要に合わせます。このアプローチは、通常、リソースの使用率に依存せず、リソースが必要な特定の時間にそのリソースを確保します。また、起動手順、およびシステムや一貫性のチェックにより、遅延なくリソースを提供できます。時間ベースのアプローチでは、繁忙期に追加のリソースを投入したり、キャパシティを拡大したりできます。

![\[スケジュールスケーリングや予測スケーリングなど、時間ベースのスケーリングポリシーを説明する図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/time-based-supply.png)


 

スケジュールされた自動スケーリングまたは予測自動スケーリングを使用して、時間ベースのアプローチを実装できます。営業開始時など、特定の時間にワークロードをスケールアウトまたはスケールインするようにスケジュールできるため、ユーザーがアクセスしたときや需要が増加したときにリソースを利用可能にしておくことができます。予測スケーリングでは、パターンを使用してスケールアウトします。一方スケジュールに基づくスケーリングでは、事前に定義された時間を使用してスケールアウトします。また、Auto Scaling グループで[属性ベースのインスタンスタイプ選択 (ABS) 戦略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)を使用すると、vCPU、メモリ、ストレージなどの属性セットとしてインスタンスの要件を表現できます。これにより、新しい世代のインスタンスタイプがリリースされると自動的に使用し、さらに Amazon EC2 スポットインスタンスでより広い範囲のキャパシティにアクセスできます。Amazon EC2 Fleet と Amazon EC2 Auto Scaling が指定した属性に適合するインスタンスを選択して起動するため、手動でインスタンスタイプを選択する必要がなくなります。

[AWS API と SDK](https://aws.amazon.com/developer/tools/) と [AWS CloudFormation](https://aws.amazon.com/cloudformation/) を活用して、必要に応じて環境全体を自動でプロビジョニングおよび廃止することもできます。このアプローチは、所定の営業時間や一定期間にのみ実行される開発環境またはテスト環境に適しています。API を使用した環境内のリソースサイズのスケーリング (垂直スケーリング) にも対応しています。例えば、インスタンスのサイズやクラスを変更して、本番稼働ワークロードをスケールアップできます。これを行うには、インスタンスを停止・起動して、別のインスタンスのサイズやクラスを選択します。この手法は、使用中にサイズの拡大、パフォーマンス (IOPS) の調整、ボリュームタイプの変更が可能な Amazon EBS Elastic Volumes などのリソースにも適用できます。

時間ベースのアプローチを設計する際は、主に 2 つの点を考慮する必要があります。第 1 に、使用パターンの一貫性について、第 2 に、パターンを変更した場合の影響です。予測精度は、ワークロードをモニタリングし、ビジネスインテリジェンスを使用することで高めることができます。使用パターンに大幅な変更がある場合は、時間を調整して予測対象範囲に収まるようにします。

## 実装手順
<a name="implementation-steps"></a>
+ **スケジュール済みのスケーリングを設定する:** 需要の変化を予測できるため、時間ベースのスケーリングは適切な数のリソースを適時に提供できます。また、リソースの作成と設定が、需要の変化に対応するのに十分ではない場合にも役立ちます。ワークロード分析を活用して、AWS Auto Scaling を使用してスケジュールに基づくスケーリングを設定します。時間ベースのスケジューリングを設定するには、予測スケーリングまたはスケジュールに基づくスケーリングを使用し、予想される、または予測可能な負荷の変化に合わせて、事前に Auto Scaling グループの Amazon EC2 インスタンス数を増やすことができます。
+  **予測スケーリングの設定:** 予測スケーリングを使用して、トラフィックフローの日次および週次のパターンに先立って Auto Scaling グループ内の Amazon EC2 インスタンスの数を増やします。定期的にトラフィックのスパイクがあり、アプリケーションの起動に時間がかかる場合は、予測スケーリングの使用を考慮すべきです。予測スケーリングを使用すると、見積もられた負荷の前にキャパシティを初期化できるため、性質上後手に回る動的スケーリング単体と比較して、より迅速にスケールできます。例えば、ユーザーが始業時間とともにワークロードの仕様を開始し、終業時間後は使用しない場合、予測スケーリングを使用すれば、始業時間前にキャパシティを追加できるため、トラフィックの変化に反応する動的スケーリングで生じる遅延を排除できます。
+ ** 動的自動スケーリングの設定:** アクティブなワークロードメトリクスに基づいてスケーリングを設定するには、自動スケーリングを使用します。分析を使用して、正しいリソースレベルで起動するように自動スケーリングを設定し、ワークロードが要求された時間内にスケールすることを検証します。1 つの Auto Scaling グループ内で、オンデマンドインスタンスとスポットインスタンスのフリートを起動してオートスケールできます。スポットインスタンスの使用で割引を受けるだけでなく、リザーブドインスタンスまたは Savings Plan を使用して、通常のオンデマンドインスタンス コストの割引料金を受け取ることができます。これらのすべての要素を組み合わせることで、Amazon EC2 インスタンスのコスト削減を最適化しつつ、アプリケーションに必要なスケールとパフォーマンスを得ることができます。

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 
+  [AWS での Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) 
+  Auto Scaling グループのサイズをスケールする 
+  [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) 
+ [Amazon EC2 Auto Scaling の予測スケーリング ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html)

 **関連動画:** 
+ [自動スケーリングのターゲットトラッキングスケーリングポリシー](https://www.youtube.com/watch?v=-RumeaoPB2M)
+ [AWS での Instance Scheduler](https://www.youtube.com/watch?v=nTLEyo2NzUs)

 **関連する例:** 
+ [Amazon EC2 Fleet 用自動スケーリングでの属性ベースのインスタンスタイプ選択](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [スケジュールされたスケーリングを使用して Amazon Elastic Container Service を最適化しコストを削減する](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Amazon EC2 Auto Scaling での予測スケーリング](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [CloudFormation で Instance Scheduler を使用して Amazon EC2 インスタンスをスケジュールするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-instance-scheduler/)