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

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

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

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

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

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

  • スケーリングイベントの後、スケールダウンして元に戻さずに、容量を増加させたままにする。

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

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

実装のガイダンス

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

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

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

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

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

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

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

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

実装手順

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

    自動スケーリングメカニズム 使用する場所

    Amazon EC2 Auto Scaling

    アプリケーションのユーザー負荷を処理するために使用できる Amazon EC2 インスタンスの数が正しいことを検証するために使用します。

    Application Auto Scaling

    Lambda 関数や Amazon Elastic Container Service (Amazon ECS) サービスなど、Amazon EC2 を超えた個々の AWS のサービスのリソースを自動的にスケールするために使用します。

    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 の予測スケーリング」を参照してください。

リソース

関連ドキュメント:

関連動画:

関連する例: