COST09-BP03 リソースを動的に供給する

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

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

実装のガイダンス

専用のインフラストラクチャで AWS Auto ScalingAWS API または SDK を使用して AWS API または SDK.これにより、環境を手動変更していた運用コストがなくなり、その結果、全体的なワークロードコストが削減され、実行速度が向上します。また、ワークロードリソースと需要を常に一致させることができます。

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

AWS Auto Scaling は、キャパシティーを調整し、安定した予測可能なパフォーマンスを可能な限り低いコストで維持するのに役立ちます。これは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、スポットフリート、Amazon Elastic Container Service (Amazon ECS)、Amazon DynamoDB、Amazon Aurora と統合されたフルマネージド型の無料サービスです。

Auto Scaling では、リソースの自動検出によってワークロード内の設定可能なリソースを検出できます。また、パフォーマンス、コスト、または両者のバランスを最適化するためのスケーリング戦略が組み込まれており、予測スケーリングによって定期的に発生する急増に対応することができます。

Auto Scaling では、手動スケーリング、スケジュールに基づくスケーリング、または需要ベースのスケーリングを実装できます。また、 Amazon CloudWatch のメトリクスとアラームを使用して、ワークロードのスケーリングイベントをトリガーできます。一般的なメトリクスは標準Amazon EC2メトリクスです。CPU 使用率、ネットワークスループット、 Elastic Load Balancing(ELB) で確認されたリクエストとレスポンスのレイテンシーなどがあります。可能な場合は、カスタマーエクスペリエンスの指標となるメトリクスを使用する必要があります。このメトリクスは一般には、ワークロード内のアプリケーションコードから生成されるカスタムメトリクスです。

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

ELB は、複数のリソースに需要を分散することで、スケーリングを支援します。運用するリソースが増加したら、ロードバランサーにリソースを追加し需要を分散させます。Elastic Load Balancing では、Amazon EC2 インスタンス、コンテナ、IP アドレス、AWS Lambda 関数がサポートされています。

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

スケジュールされた Auto Scaling を使用して、時間ベースのアプローチを実装できます。営業開始時など、特定の時間にスケールアウトまたはスケールインするようにスケジュールできるため、ユーザーがアクセスしたときや需要が発生したときにリソースを利用可能にしておくことができます。

また、 AWS API や SDK および AWS CloudFormation を使用すると、必要に応じて自動的にプロビジョニングしたり、環境全体を削除したりできます。このアプローチは、所定の営業時間や一定期間にのみ実行される開発環境またはテスト環境に適しています。

API を使用した環境内のリソースサイズのスケーリング (垂直スケーリング) にも対応しています。たとえば、インスタンスのサイズやクラスを変更して、本番稼働ワークロードをスケールアップできます。これを行うには、インスタンスを停止・起動して、別のインスタンスのサイズやクラスを選択します。この手法は、使用中にサイズの拡大、パフォーマンス (IOPS) の調整、ボリュームタイプの変更が可能な Amazon Elastic Block Store (Amazon EBS) Elastic Volumes などのリソースにも適用できます。

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

実装手順

リソース

関連するドキュメント: