Webサイトの負荷テストと容量計画をどのように行いますか？
これは、Webサイトの容量計画についての 標準的な質問 です。
関連：
WebサイトとWebアプリケーションのキャパシティプランニングの推奨ツールと方法は何ですか？
さまざまなWebサーバー、フレームワークなどのさまざまなツールや手法、およびWebサーバー全般に適用されるベストプラクティスを自由に説明してください。
簡単に言えば、あなた以外の誰もこの質問に答えることはできません。
長い答えは、特定のワークロードのベンチマークは、「文字列の断片はどれくらいの長さですか？」と尋ねるようなものなので、自分で行う必要があることです。
シンプルな1ページの静的WebサイトをPentium Pro 150でホストしても、毎日数千のインプレッションを配信できます。
この質問に答えるために必要な基本的なアプローチは、試してみて何が起こるかを確認することです。システムを人工的に圧力をかけて、どこに座屈しているかを確認するために使用できるツールはたくさんあります。
これの概要は次のとおりです。
- シナリオを配置する
- 監視を追加する
- トラフィックを追加
- 結果を評価する
- 結果に基づいて修正
- すすぎ、適度に幸せになるまで繰り返します
シナリオを配置する
基本的に、負荷をテストするためには、テストするものが必要です。テストする環境をセットアップします。これは、可能な場合は実動ハードウェアにかなり近い推測である必要があります。そうしないと、データを推定することになります。
サーバー、アカウント、ウェブサイト、帯域幅などを設定します。VMでこれを行ったとしても、結果をスケーリングする準備ができていれば問題ありません。
そこで、中出力の仮想マシン（2コア、512 MB RAM、4 GB HDD）をセットアップし、お気に入りのロードバランサーをインストールします haproxy 内部- Red Hat Linux VM上。
また、ロードバランサーのストレステストに使用する2台のWebサーバーをロードバランサーの背後に配置します。これら2つのWebサーバーは、実際のシステムと同じように設定されています。
監視を追加
監視するいくつかのメトリックが必要になるため、Webサーバーに到達するリクエストの数と、ユーザーが2秒を超える応答時間を取得する前に1秒間に絞り込めるリクエストの数を測定します。
ロードバランサーが接続を処理できることを確認するために、haproxyインスタンスのRAM、CPU、およびディスクの使用状況も監視します。
これを行う方法は、プラットフォームに大きく依存し、この回答の範囲外です。 Webサーバーのログファイルを確認したり、パフォーマンスカウンターを開始したり、ストレステストツールのレポート機能を利用したりする必要があるかもしれません。
常に監視したいいくつかの事項：
- CPU使用率
- RAM使用量
- ディスクの使用状況
- ディスクの待ち時間
- ネットワーク利用
また、具体的にテストしている内容に応じて、SQLデッドロック、シーク時間などを確認することもできます。
トラフィックを追加
ここが楽しいところです。次に、テスト負荷をシミュレートする必要があります。設定可能なオプションでこれを行うことができる たくさんのツール があります：
- JMeter （Web、LDAP）
- Apacheベンチマーク （ウェブ）
- グラインダー （ウェブ）
- httperf （ウェブ）
- [〜＃〜] wcat [〜＃〜] （ウェブ）
- Visual Studioロードテスト（Web）
- [〜＃〜] sqlio [〜＃〜] （SQLサーバー）
数、任意の数を選択します。システムが1分あたり10,000ヒットでどのように応答するかを確認するとします。このステップを何度も繰り返し、その数を上下に調整してシステムの応答を確認するため、選択する数は関係ありません。
理想的には、1つのクライアントがリクエストのボトルネックにならないように、これらの10,000リクエストを複数の負荷テストクライアント/ノードに分散する必要があります。たとえば、JMeterの Remote Testing は、制御するJmeterマシンから複数のクライアントを起動するための中央インターフェイスを提供します。
マジックGoボタンを押して、Webサーバーが溶けてクラッシュするのを確認します。
結果を評価する
したがって、ステップ2で収集したメトリックに戻る必要があります。10,000の同時接続では、haproxyボックスはほとんど問題なく動作しますが、2つのWebサーバーの応答時間はわずかです。 5秒以上。これはクールではありません。覚えておいてください、応答時間は2秒を目指しています。したがって、いくつかの変更を行う必要があります。
修復する
今、あなたは2倍以上であなたのウェブサイトをスピードアップする必要があります。したがって、スケールアップまたはスケールアウトする必要があることがわかります。
スケールアップするには、より大きなWebサーバー、より多くのRAM、より高速なディスクを入手してください。
スケールアウトするには、より多くのサーバーを取得します。
この決定を行うには、ステップ2のテストとテストを使用します。たとえば、テスト中にディスクのレイテンシが大きいことがわかった場合、スケールアップしてより高速なハードドライブを入手する必要があることがわかります。
テスト中にプロセッサが100％に留まっていることがわかった場合は、既存のサーバーへの負荷を減らすために、Webサーバーを追加するためにスケールアウトする必要があるかもしれません。
一般的な正しい答えや間違った答えはありません。あなたにとって正しいものだけがあります。スケールアップしてみて、それが機能しない場合は、代わりにスケールアウトしてください。かどうか、それはあなた次第です。
スケールアウトするとします。それで、2つのWebサーバー（それらはVMです）のクローンを作成することにし、4つのWebサーバーができました。
すすぎ、繰り返し
手順3からもう一度開始します。予想どおりに動作しない場合（たとえば、Webサーバーが2倍になったが、応答時間がまだ2秒を超えている場合）は、他のボトルネックを調べます。たとえば、Webサーバーを2倍にしましたが、まだデータベースサーバーが不安定です。または、より多くのVMのクローンを作成しましたが、それらは同じ物理ホスト上にあるため、サーバーリソースの競合が高くなっただけです。
その後、この手順を使用して、システムの他の部分をテストできます。ロードバランサーをヒットする代わりに、Webサーバーを直接ヒットしてみてください またはSQLベンチマークツールを使用したSQLサーバー 。
キャパシティプランニングは、測定、この場合は応答時間と負荷の比較から始まります。線形関数ではない負荷でプログラムの速度が低下する程度がわかったら、応答時間の目標を選択し、所定の負荷量でその目標を達成するために必要なリソースを見つけることができます。
パフォーマンス測定は常にtime単位で行われます。
- それらはユーザーが気にすることです
- それらは拡大縮小できます
％CPUやIOPSのようなものはシステム固有であるため、システムを計画し、本番稼働前に測定した場合にのみ、気になるものの「代理」として機能します。
容量計画は厄介な獣です。それは芸術と同じくらい科学です（間違いなく暗いものなら）。
あなたの最良のケースは、十分な情報に基づいた決定およびを行うことです。あなたの能力が仮定と現実が一致する必要がある場合、あなたは神秘的なヨギのように見えます。残念ながら、あなたの仮定が現実を超えている場合、あなたは行き過ぎて行き過ぎたように見えるでしょう。さらに残念なことに、想定が最終的な現実を下回っている（またはその他の点で正しくない）場合、必要な容量が不足し、うめきインフラストラクチャの障害を軽減するためにスクランブルをかけなければならず、能力が不足しているように見えます。
プレッシャーはない...
残念ながら、キャパシティプランニングのダークアートは、単一のサーバーフォールトの回答に合理的に抽出できる以上のものです。本当に、それは本に値するトピックです。
幸いにも、そのような本があります： " The Art of Capacity Planning "
Mark Hendersonの投稿をさらに詳しく説明するために、これをApacheに特化して書いています。彼の言ったことを繰り返すと、「簡単な答えは、あなた以外の誰もこの質問に答えることはできない」ということです。この回答のテキストは、 Drupal Webサイトのパフォーマンス に関する同様の質問への私の回答から大きく借用されています。
Mod_Preforkを使用したApacheの構成
Apache は、間違いなく（利用できない場合でも）最も人気のあるWebサーバーの1つです。オープンソースであり、現在も積極的に維持されています。 LinuxとWindowsの両方のオペレーティングシステムで実行できますが、Linux/Unixの世界ではより一般的です。
すぐに使えるApache構成を決して使用しないでください。常にApacheをサイトに合わせて調整する必要があります。 CentOSのメインの Apache設定 ファイルは/etc/httpd/conf/httpd.confにあり、UbuntuシステムのメインのApache設定ファイルは通常/etc/Apache2/Apache2.confにあります。追加の設定ファイルは Virtual Hosts のようなものに使用されます。
多くのソフトウェアと同様に、Apacheは特定のWebサイトのニーズに応じて柔軟にカスタマイズできるように構築されています。 さまざまなマルチプロセッシングモジュールがあります Apacheを構成して、ネットワークポートにバインドし、リクエストを受け入れて処理することができます。
CentOSおよびUbuntuサーバーに付属するデフォルトのApacheインストールでは、ほとんどの場合、MPM " mod_prefork "が使用されます。 mod_preforkを使用していると仮定します（わからない場合は、その可能性が高くなりますが、それを判別できるのはあなただけです）設定方法の基本は次のとおりです。
- Apacheが使用できるようにするメモリの最大量を把握します。
- Webサイトを徹底的にテストし、各Apacheプロセスが使用するメモリ量を決定します（topを使用）。
- 最も多くのメモリを使用するApacheプロセスを上に置き、適切な方法で少し追加してから、最初の数（Apacheが使用するメモリの最大量）をこの新しい数で割ります。
- 取得する数値は、
MaxClients＆ServerLimit変数でなければなりません。
これは確かに最終的な答えではありません。 Apacheサーバーのチューニング は時間がかかり、適切に実行するには経験が必要です。
また、ボトルネック、単一障害点、およびライセンスの制限を特定するためにアプリケーションを設計/構築したアーキテクトおよびエンジニアに話をすることをお勧めします。