翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ベストプラクティス: アプリケーションサーバー数の最適化
重要
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、 AWS re:Post
一般的に、本稼働用スタックには、複数のアベイラビリティーゾーン全体に分散されるアプリケーションサーバーが複数含まれます。ただし、入って来るリクエストの数は、時間または曜日によって大幅に異なる場合があります。予測される最大負荷を処理するのに最小限必要なサーバーを実行しようとしても、結局、必要とする容量より多くのサーバー容量に料金を支払うはめになることが少なくありません。サイトを効率的に実行するために推奨される方法は、サーバー数を現在求められているボリュームと一致させることです。
AWS OpsWorks スタックには、サーバーインスタンスの数を管理する 3 つの方法があります。
-
24/7 インスタンス はユーザーが手動で起動し、ユーザーが手動で停止するまで実行されます。
-
時間ベースのインスタンスは、ユーザーが指定したスケジュールで AWS OpsWorks スタックによって自動的に開始および停止します。
-
負荷ベースのインスタンスは、CPU やメモリの使用率など、ユーザーが指定した負荷メトリクスのしきい値を超えると、 AWS OpsWorks スタックによって自動的に開始および停止します。
注記
スタックの時間ベースおよび負荷ベースのインスタンスを作成して設定すると、指定した設定に基づいて AWS OpsWorks スタックによって自動的に起動および停止されます。インスタンスの設定または数を変更することを決定しない限り、特別な操作をする必要はありません。
推奨事項: アプリケーションサーバーインスタンスが数個以上あるスタックを管理する場合は、これらの 3 つのインスタンスタイプを組み合わせて使用することをお勧めします。次の例では、スタックのサーバー容量を管理して、さまざまな特徴を持つ変動する日単位のリクエスト量を処理する方法を示します。
-
リクエストの平均量は、1 日を通じて正弦的に変化します。
-
リクエストの平均最小量では、5 個のアプリケーションサーバーインスタンスが必要です。
-
リクエストの平均最大量では、16 個のアプリケーションサーバーインスタンスが必要です。
-
リクエストボリュームの急激な増大には、通常 1～2 個のアプリケーションサーバーインスタンスで対処できます。
これは、説明の目的で便宜上用意されていますが、リクエストのボリュームあらゆる変化に簡単に応用でき、また週単位の変化に対応するように拡張することもできます。次の図に、3 つのインスタンスタイプを使用して、このリクエストの量を管理する方法を示します。
この例には次の特徴があります。
-
スタックに、常に稼働し、基本負荷を処理する 3 つの 24/7 インスタンスがあります。
-
スタックに 12 個の時間ベースのインスタンスがあります。これらは、平均の日単位変動を処理するよう設定されています。
1 つは午後 10 時から午前 2 時まで、別の 2 つは午後 8 時から午後 10 時までと午前 2 時から午前 4 時までのように実行されます。わかりやすいように、この図では 2 時間ごとの時間ベースのインスタンスの数に変更していますが、より詳細に管理するために 1 時間当たりの数に変更することもできます。
-
スタックには、24/7 および時間ベースのインスタンスで処理できる量を超えたトラフィックの急増を処理するのに十分な負荷ベースのインスタンスがあります。
AWS OpsWorks スタックは、現在実行中のすべてのサーバー全体の負荷が指定されたメトリクスを超えた場合にのみ、ロードベースのインスタンスを起動します。実行されていないインスタンスにかかるコストは最小限 (Amazon EBS でバックアップされたインスタンス) またはゼロ (instance store-backed インスタンス) であるため、推奨される方法としては、予測される最大リクエストボリュームを無理なく処理できるだけのインスタンスを作成します。この例では、スタックに少なくとも 3 個の負荷ベースのインスタンスが必要です。
注記
サービス中断の影響を軽減するために、3 つすべてのインスタンスタイプを複数のアベイラビリティーゾーン全体に分散してください。
