[技術ブログvol.21] インフラ視点で、負荷テストについて考えてみる

負荷テストは、インフラ環境をサイジングするうえでの具体的なデータを与えてくれます。この記事では、インフラ事業者視点で負荷テストについての目的、種類、実施方法について考えてみます。

※面倒な準備は無しで、簡単に負荷テストを実施したい人向けに、WEBインタフェースから負荷テストがおこなえるシステムを作成中です。

インフラ事業者から見た、負荷テストの目的

サイジングの妥当性を証明できる

インフラ事業者から見た場合、負荷テストの最大のメリットはサイジングの妥当性を証明できることです。

当社も提案の際に、サイジングに必要な情報を確認していきます。月間の（想定）アクセス数、ピーク時の（想定）アクセス数、平均ページサイズ、リプレイスであれば各サーバのCPUやメモリ、ディスクなどのリソース情報などです。しかしながら、具体的な情報がでてくることは多くありません。そのため、想定しているアクセス数やシステムの内容やプロモーションの仕方等をヒアリングして、過去の実績などを総合的に判断してサイジングを行っています。

サイジングの結果を大きく外すことは少ないですが、想定以上にアプリケーションの処理負荷が大きく応答速度が低下したことや、ページサイズが大きすぎて問題になったことがありました。これらは、そのシステム固有の内容になるため、過去の実績からでは判断できず、実際のシステムをもとに確認するしかありません。

負荷特性を知ることで、アクセス集中時の対策を立てられる

実際のシステムの負荷特性を知ることで、アクセス集中時の対策を立てることができます。

クラウドの登場で簡単にサーバのスペックアップや台数追加ができるようになりました。負荷特性を知ることで、アクセス集中が発生した場合の精度の高い対策を立案することが可能になります。

毎月の費用を変動させることが難しい場合は、予算取りのための根拠として使うことも可能です。

負荷テストの種類

負荷テストは大別すると5つくらいに分類できます。今回は、「基礎テスト」と「ストレステスト」について説明していきます。

1. 基礎テスト・・・システムの負荷特性を調べるための、基本的なテストです
2. ストレステスト・・・システムの限界値を探るためのテストです
3. ピークロードテスト・・・高負荷時を想定したテストです
4. スパイクテスト・・・メディア露出など、瞬間的なアクセス発生と発生後を想定したテストです
5. 耐久テスト・・・長時間の稼働を想定したテストです

基礎テスト

基礎テストの目的は、低い負荷をかけることで、システムの限界性能に対して、どの程度の負荷になっているかの確認をするために行います。

実施方法

低い負荷を少しづつ増やしていきます。

まず、スレッド数1で負荷を掛け、応答時間とスループットを取得します。スレッド数とは、同時アクセス数と読み替えても構いません。

• 応答時間
  この時の応答時間は、システムが応答する最速の時間となります。
• スループット
  スループットとは、秒間あたりのリクエスト処理数です。スレッド数1の時のスループットは、システムの性能劣化がないと仮定すると、スレッド数に比例して増加します。これを理想スループットと言います。

理想スループット＝スレッド数1のスループット　×　スレッド数

以降のテストでは、この応答時間と理想スループットを基準に性能を評価していくことになります。（※性能の評価方法は、ストレステストにて後述します）

次にスレッド数2、スレッド数4と増やすし、応答速度に変化がないこと、スループットが理想スループットと大きな差異がないことを確認します。ここで大きな差異が発生している場合は、どこかに問題があることが考えられます。負荷テストツールの設定や、テスト環境の設定等を見直してみましょう。

ストレステスト

ストレステストは、システムの限界性能を探るために行います。また、限界性能を超えた場合のシステムの挙動を確認します。

実施方法

基礎テストと同様の要領で、スレッド数を、1,2,4,8,16と徐々に増やしていきます。システムの限界性能は、スループットの値から判断します。性能限界に近づくと、スループットが理想スループットからかい離してくるため、下図のようなグラフとなります。

このときの限界性能が、要求性能よりも低い場合は、性能要件を満たしていません。性能要件をクリアするために、ボトルネックとなっている箇所を調査、チューニングし、再評価する必要があります。

また、限界性能を超えた場合に、システムがどのような振る舞いをするのかを調べ、対策を検討することで、運用中に問題が発生した際に素早く対応することが可能になります。

JMeterで負荷テストをする方法

JMeterで負荷テストを行い、グラフ化するためには、次のような流れで作業を行います。
一つずつみていきましょう。

[1]該当スレッド数のシナリオ作成～[3]結果をシンプルデータライタで取得

JMeterのインストール方法、シナリオ作成、実行方法までは、下記ブログを参照ください。

参考：JMeterのインストール方法

上記ブログと異なる点は、シナリオ作成のときに、リスナーの「シンプルデータライタ」を追加することです。シンプルデータライタを追加すると、実行結果がCSV形式で出力されます。

[4]結果を統計レポートで加工

シンプルデータライタは、１アクセス1行の結果として出力されます。グラフとして加工するためには、扱いにくいので、JMeterの「統計レポート」を利用します。

Linuxサーバ上で取得したシンプルデータライタのCSVファイルをクライアントPC上へダウンロードしておきます。クライアントPCでは、JMeterを立ち上げ、「リスナー」→「統計レポート」を追加します。「全てのデータをファイルに出力」のファイル名へ、ダウンロードしたCSVファイルを入力すると、ラベルごとにデータを加工することができます。

このとき、CSVファイルの文字コードがUTF-8ではない場合、日本語が文字化けを起こすので注意しましょう。

[5]EXCELへ転記

統計レポートで出力した結果をEXCELへ転記します。EXCELでは、数式を使い、「理想スループット」を算出できるようにしておきます。

理想スループットは、「スレッド数１のスループット×該当スレッド数」です。

[6]EXCELでグラフ化

必要なスレッド数分の情報が取得できたら、グラフ化を行います。

[5]でリストアップした一覧を使いピボットテーブルを作成します。行ラベルに「Label」「スレッド数」をとり、Σ値に「合計/average」「合計/理想スループット」「合計/throughput」を表示させます。

ピボットテーブルで加工した情報をもとにグラフ化を行います。下のグラフでは、横軸をスレッド数にとっており、縦軸をスループットと応答速度の2軸で表現しています。スループットの縦軸は、青の直線で理想スループット、青の▲印の線でスループットを表しています。応答速度は赤の線で表現しています。

JMeterの準備が面倒な人向けのWEBツール

負荷テストを行うことで、過去の実績をもとにしたサイジングから、具体的根拠にもとづいたサイジングをすることができるようになります。また、クラウドをスケーラブルにうまく利用するためにも活用することが可能です。

自分で負荷テスト環境を作るのは大変！という人向けに、WEBから簡単に「基礎テスト」および「ストレステスト」の実施が可能なシステムを作成中です。公開できる状況になったら別途お知らせしますので、楽しみにお待ちください！

次回の更新予定は、1月中旬頃です。