SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする - AWS Well-Architected Framework
実装のガイダンス実装手順リソース

SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする

クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。

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

  • ユーザーの負荷に合わせてインフラストラクチャをスケールしない。

  • 常に手動でインフラストラクチャをスケールする。

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

このベストプラクティスを確立するメリット: ワークロードの伸縮性を設定およびテストすることで、クラウドリソースの供給を需要に効率的に一致させ、容量の過剰なプロビジョニングを回避できます。クラウドの伸縮性を利用して、需要の急増時や急増後に容量を自動的にスケールすることにより、ビジネス要件を満たすために必要となる適切な数のリソースのみを運用できます。

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

実装のガイダンス

クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。最適な形で需要と供給を一致させることで、ワークロードに対する環境の影響を最小限に抑えることができます。

需要が一定の場合も変動する場合もあり、管理面の負担を回避するには、メトリクスと自動化が必要になります。アプリケーションのスケールは、インスタンスのサイズを変更して垂直方向 (スケールアップ/スケールダウン)、インスタンス数を変更して水平方向 (スケールイン/スケールアウト)、あるいはこれらの組み合わせで調整できます。

リソースの需要と供給は、さまざまなアプローチで一致させることができます。

  • ターゲット追跡アプローチ: スケーリングメトリクスを監視し、必要に応じて容量を自動的に増減します。

  • 予測スケーリング: 日単位および週単位の傾向を見越してスケールします。

  • スケジュールベースのアプローチ: 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。

  • サービススケーリング: 設計によってネイティブにスケールされるか、機能として自動スケーリングを提供するサービス (サーバーレスなど) を選択します。

使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除し効率性を改善します。

実装手順

  • 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。AWS では、ユーザー負荷が低い期間には迅速かつ簡単にワークロードをスケールダウンできるように、幅広い自動スケーリングメカニズムを提供しています。自動スケーリングメカニズムの例を次に示します。

    Auto scaling mechanism Where to use

    Amazon EC2 Auto Scaling

    アプリケーションのユーザー負荷を処理するために、Amazon EC2 インスタンスを適切な数に調整します。

    Application Auto Scaling

    Amazon EC2 だけでなく、個々の AWS サービス (Lambda 関数や Amazon Elastic Container Service (Amazon ECS) サービスなど) のリソースを自動的にスケールします。

    Kubernetes Cluster Autoscaler

    AWS の Kubernetes クラスターを自動的にスケールします。

  • スケーリングに関する議論は、Amazon EC2 インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連していることが一般的です。需要に合わせて、Amazon DynamoDB の読み取り/書き込みキャパシティユニットや Amazon Kinesis Data Streams シャードなどの非コンピューティングサービスに関する設定も検討してみてください。

  • スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。必要に応じて、カスタマイズされたメトリクス (メモリ使用率など) をスケーリングポリシーに使用することもできます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。

    • メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。

    • メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。

  • Auto Scaling グループの手動スケーリングではなく、動的スケーリングを使用します。また、動的スケーリングでターゲット追跡スケーリングポリシーを使用することをお勧めします。

  • スケールアウトとスケールインの両方のイベントに対処できるようにワークロードをデプロイします。スケールインイベントのテストシナリオを作成して、ワークロードが期待どおりに動作し、ユーザーエクスペリエンスに影響しない (スティッキーセッションが失われない) ことを確認します。アクティビティ履歴を使用すると、Auto Scaling グループのスケーリングアクティビティを検証できます。

  • ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、Amazon EC2 Auto Scaling を使用した予測スケーリングに関するブログを参照してください。

リソース

関連するドキュメント:

関連動画:

関連する例: