ベストプラクティス: アプリケーションサーバー数の最適化 - AWS OpsWorks

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ベストプラクティス: アプリケーションサーバー数の最適化

重要

AWS OpsWorks Stacks は新規顧客を受け付けなくなりました。既存のお客様は、2024 年 5 月 26 日までは OpsWorks コンソール、 API、 CLI、および CloudFormation リソースを通常どおり使用できますが、その時点でこれらのリソースは廃止されます。この移行に備えて、できるだけ早くスタックを AWS Systems Manager に移行することをおすすめします。詳細については、AWS OpsWorks Stacks サポート終了に関する FAQ および AWS Systems Manager アプリケーションマネージャへの AWS OpsWorks Stacks アプリケーションの移行 を参照してください。

一般的に、本稼働用スタックには、複数のアベイラビリティーゾーン全体に分散されるアプリケーションサーバーが複数含まれます。ただし、入って来るリクエストの数は、時間または曜日によって大幅に異なる場合があります。予測される最大負荷を処理するのに最小限必要なサーバーを実行しようとしても、結局、必要とする容量より多くのサーバー容量に料金を支払うはめになることが少なくありません。サイトを効率的に実行するために推奨される方法は、サーバー数を現在求められているボリュームと一致させることです。

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 つすべてのインスタンスタイプを複数のアベイラビリティーゾーン全体に分散してください。