PERF02-BP05 利用可能な伸縮性のあるリソースを使用する - AWS Well-Architected Framework

PERF02-BP05 利用可能な伸縮性のあるリソースを使用する

クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。この伸縮性をコンピューティング関連のメトリクスと組み合わせることによって、ワークロードは変更に自動的に対応して、必要なリソースのみを使用することができます。

一般的なアンチパターン:

  • 予想されるスパイクに対応するためにオーバープロビジョニングする。

  • アラームに対応するために手動でキャパシティーを増やす。

  • プロビジョニングにかかる時間を考慮に入れずにキャパシティーを増やす。

  • スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。

  • ワークロードの実際の要件を直接反映していないメトリクスをモニタリングする。

このベストプラクティスを活用するメリット: 需要は、一定である場合も、変動する場合も、あるパターンに従う場合も、スパイクが発生しやすい場合もあります。需要と供給をマッチングすることで、ワークロードのコストを最低限に抑えることができます。ワークロードの伸縮性をモニタリング、テスト、設定することで、需要の変化に応じてパフォーマンス最適化、コスト低減、信頼性の向上を実現できます。これに対して手動で対応するアプローチも可能であるとはいえ、大規模な場合は非実用的です。自動化したメトリクスベースのアプローチを採用することで、どの時点でもリソースが確実に需要を満たすようにすることができます。

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

実装のガイダンス

リソースの供給が、ワークロードが求めるリソースの需要とマッチすることを目標に、伸縮性を活用するために、メトリクスベースのオートメーションを使用する必要があります。例えば、リソースのモニタリングに Amazon CloudWatch メトリクスを使用したり、Auto Scaling グループには Amazon CloudWatch メトリクスを使用したりすることができます。

コンピューティング関連のメトリクスと組み合わせることによって、ワークロードは自動的に変化に対応し、最適な一連のリソースを利用して目標を達成できるようになります。プロビジョニングにかかる時間と予想されるリソース障害を考慮に入れて計画を策定する必要があります。

インスタンス、コンテナ、関数には、伸縮性のためのメカニズムがあり、サービスの一部として、Application Auto Scaling で、または Amazon EC2 Auto Scaling と組み合わせて提供されます。アーキテクチャの伸縮性を活用して、広範囲の規模の使用におけるパフォーマンス要件を満たすために十分なキャパシティーがあることを確認します。

デプロイされているワークロードのタイプに対して、伸縮自在なリソースのスケールアップまたはスケールダウンのメトリクスが検証されていることを確認します。例えば、動画トランスコーディングアプリケーションをデプロイする場合、CPU 使用率は 100% となることが想定されるため、主要なメトリクスにするべきではありません。代替手段として、インスタンスタイプのスケーリングを待機しているトランスコーディングジョブのキューの深さに対して測定することができます。

ワークロードのデプロイは、スケールアップとスケールダウンの両方のイベントに対処できる必要があります。ワークロードコンポーネントを安全にスケールダウンすることは、需要があるときにリソースをスケールアップするのと同じくらい重要です。

スケーリングイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。

実装手順

リソース

関連するベストプラクティス:

関連するドキュメント:

関連動画:

関連する例: