翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
SUS02-BP01 ワークロードインフラストラクチャを動的にスケーリングする
クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。
一般的なアンチパターン:
ユーザーの負荷に合わせてインフラストラクチャをスケールしない。
常に手動でインフラストラクチャをスケールする。
スケーリングイベントの後、スケールダウンして元に戻さずに、容量を増加させたままにする。
このベストプラクティスを活用するメリット: ワークロードの伸縮性を設定およびテストすることで、需要とクラウドリソースの供給を効率的に一致させ、容量の過剰プロビジョニングを回避できます。クラウドの伸縮性を利用して需要の急増時や急増後に容量を自動的にスケールすることで、ビジネス要件を満たすために必要となる適切な数のリソースのみを運用できます。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を備えます。最適な形で需要と供給を一致させることで、ワークロードに対する環境の影響を最小限に抑えることができます。
需要は、一定の場合も変動する場合もあり、管理面の負担を軽減するには、メトリクスと自動化が必要になります。アプリケーションのスケールは、インスタンスのサイズを垂直方向に変更し (スケールアップ/スケールダウン)、インスタンス数を水平方向に変更して (スケールイン/スケールアウト)、またはこれらの組み合わせで調整します。
リソースの需要と供給は、さまざまなアプローチで一致させることができます。
-
ターゲット追跡アプローチ: スケーリングメトリクスをモニタリングし、必要に応じて容量を自動的に増減します。
-
予測スケーリング: 日次単位および週単位の傾向を見越してスケールします。
-
スケジュールベースのアプローチ: 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。
-
サービススケーリング: ネイティブにスケーリングするサービス (サーバーレスなど) を設計によって選択するか、機能として自動スケーリングを提供します。
使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除することで、効率性を改善します。
実装手順
-
伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、および関数は、自動スケーリングと組み合わせて、または サービスの機能として、弾力性のメカニズムを提供します。 は、さまざまな自動スケーリングメカニズム AWS を提供し、ユーザー負荷が低い期間にワークロードを迅速かつ簡単にスケールダウンできるようにします。自動スケーリングメカニズムの例を以下に示します。
自動スケーリングメカニズム 使用する場所 を使用して、アプリケーションのユーザー負荷を処理するために使用できる Amazon EC2インスタンスの正しい数を確認します。
を使用して、Lambda 関数や Amazon Elastic Container Service (Amazon ECS) AWS サービスなどEC2、Amazon 以外の個々のサービスのリソースを自動的にスケーリングします。
を使用して、 で Kubernetes クラスターを自動的にスケーリングします AWS。
-
スケーリングは、Amazon EC2インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連してよく議論されます。需要に合わせて、Amazon DynamoDB
の読み取り/書き込みキャパシティユニットや Amazon Kinesis Data Streams シャードなどの非コンピューティングサービスの設定を検討してください。 -
スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードの種類に対して検証されていることを確認します。ビデオトランスコーディングアプリケーションをデプロイする場合、100% のCPU使用率が期待され、プライマリメトリクスにはなりません。必要に応じて、スケーリングポリシーにカスタマイズされたメトリクス
(メモリ使用率など) を使用できます。適切なメトリクスを選択するには、Amazon の以下のガイダンスを考慮してくださいEC2。 -
メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。
-
メトリクス値は Auto Scaling グループのインスタンス数に比例して増減する必要があります。
-
-
Auto Scaling グループの手動スケーリングの代わりに、動的スケーリングを使用します。動的スケーリングでターゲット追跡スケーリングポリシーを使用することをお勧めします。
-
スケールアウトとスケールインの両方のイベントに対処できるように、ワークロードをデプロイします。スケールインイベントのテストシナリオを作成して、ワークロードが期待どおりに動作し、ユーザーエクスペリエンスに影響しない (スティッキーセッションが失われない) ことを確認します。アクティビティ履歴を使用して、Auto Scaling グループのスケーリングアクティビティを確認できます。
-
予測可能なパターンについてワークロードを評価し、予測および計画された需要の変化を想定してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、「Amazon EC2 Auto Scaling を使用した予測スケーリング
」を参照してください。
リソース
関連ドキュメント:
関連動画:
関連する例:
