MS_LoadTestingPoints

負荷テストのポイント

• TOP > テスト
  • 負荷テストのポイント
  • 脆弱性対策のポイント

概要

負荷テストをスムーズに計画・実行できるようにコンテンツを作成してみました。

負荷テストとは？

負荷テストの概要図

単純に、Webアプリケーションだけに対して負荷をかけることもできるが、
以下のようにネットワーク機器など含めた本番稼働構成に対する性能検証も可能。

この場合、単純なリクエスト－レスポンス間の時間測定だけするのではなく、
各サーバーや機器のパフォーマンス カウンタなどのパフォーマンス情報を収集し、
ボトルネックが無いか？などを調査する必要がある。

負荷テストのスクリプト作成

• 負荷テストでは、以下のような実行毎に変わる可変値を
  正規表現などを使用して抜いて引き継ぐ処理が必要になるケースがある。

  以降コレを「可変値の追跡」と呼ぶ。

• また、ユーザ入力やユーザ操作をシミュレートする必要になるケースもある。

可変値の場所

post、url、htmlなどに含まれる値。

• ヘッダ部
  • Cookie
    • Session Cookie（ASP.NET Session: ASPNETSession.md）
    • Cookie認証チケット（認証基盤: AuthenticationInfrastructure.md）
  • QueryStringコレクション
• ボディ部
  • Formコレクション
  • HTML
  • JavaScript

可変値のユースケース

• 実行タイミング次第で可変となる値。
• ランダム値が使用されていて可変となる値。
  • 乱数
    • GUID, UUID
    • Temporary Password
  • DBMSの
    • Timestamp値
    • Identity列やSequence値
• ログイン・ユーザ毎に可変となる値。
  • ログイン・アカウント
  • ユーザ毎の結果セット
  • 結果セットから選択したデータ

スクリプトによる可変値の追跡

アプリケーションの仕組み次第では、データストアを初期化すれば、
取得した電文の再送だけで、負荷テストが可能なケースもあるが、

• 実行タイミング次第で可変となる値がある。
• ランダム値が使用されていて可変となる値がある。
• 多重ログインが不可能な仕組みがある。

のような処理がある場合、

• 可変値の追跡
• ユーザ毎の入力

が必要になる。

このため、負荷テストでは、スクリプト作成が必要になる。

このように「可変値の追跡」が必要になる負荷テストは、HTTPを使用するWebアプリケーションでは容易であるが、
バイナリ電文を使用するリッチクライアント・アプリケーションの場合、型情報を取り込む必要があるので、容易ではない。

（...と言うか、実質的に汎用的な負荷ツールでバイナリ電文の実行で負荷をシミュレートできないことが殆どである）。

負荷テスト・ツールの機能

負荷テスト・ツールは、以下のような機能を持っている。

電文のキャプチャとスクリプトの生成機能

• 電文キャプチャとスクリプト（修正前のテンプレート）を生成する。
• 専用ブラウザを持つツールと、HTTPプロキシのように動作するツールがある。

HTTPプロキシのように動作するツール

• GUIを持たないWebAPIの負荷テストの場合は、コチラを使用する必要がある。

専用ブラウザを持つツール

• レグレッション・テスト（回帰テスト）を実行可能。
  • この場合、ブラウザ上の操作手順やjavascriptなどのイベントをシミュレートできる。
  • ただし、レグレッション・テスト（回帰テスト）用であり、負荷テスト用のスクリプト再生には使用できない。
• また、スクリプトを再実行して
  「スクリプト（操作）の記録時」と「テスト時」の
  値の差異を検出し、追跡が必要な可変値をサジェストする。

スクリプトの編集機能

可変値の追跡

• スクリプト生成時に自動追跡するツールもある。
• 以下のケースでは自動追跡できないので、手動でスクリプトを修正する。
  • ユーザ毎に別々の入力値が必要になる場合
  • JavaScriptにより複雑なパラメータを動的に生成している場合
  • クライアント側で、Cookieを生成している場合

ユーザ毎の入力

準備したユーザ毎の入力値を、実行時に投入する。

デバッグ方法

• 下記の仮想ユーザ毎のスクリプト実行機能を使用してスクリプトをデバッグする。
• エラーが発生した際は、見極めが必要になる場合がある。
  • アプリケーション・エラーか？
  • それ以外のアプリケーション上の問題か？
• デバッグ機能が無い場合は、再生したスクリプトを、FiddlerなどのHTTPデバッグ・プロキシでキャプチャして、
  どこに問題があるかを確認・分析する必要がある。コレを行うには、アプリケーションの内部実装位を理解している必要がある。

仮想ユーザ毎のスクリプト実行機能

• 仮想ユーザ毎にスクリプトを実行する。
• 多重度を上げるため、1 Thread = 1 Userに見立てて負荷をシミュレートする。
• この際、ユーザ入力の思考遅延時間をシミュレートする。

エージェント機能

１つのスクリプトやシナリオを複数のマシンを使用して負荷をかける場合、

各マシンにエージェントをインストールし、
コントローラからエージェント経由で各マシンを制御する。

シナリオの組み立てと実行機能

• シナリオでは、複数のスクリプトを組合せて本番環境に近い負荷をシミュレートする。
• このシナリオを組み立て、シナリオに従い仮想ユーザ毎にスクリプトを実行させる。
• シナリオの作成準備として、まず、指針となる「測定モデル」を作成する必要がある。

測定モデル

「測定モデル」は、下記のマトリックスのことで、

トランザクション種別	機能名	実行ユーザ比率	スクリプト名
参照系	機能A、機能B	例：70％	スクリプトA、スクリプトB
更新系	機能C、機能D	例：20％	スクリプトC、スクリプトD
追加、削除系	機能E	例：10％	スクリプトE

• 「トランザクション種別」毎に「機能」を抽出し、
• 「トランザクション種別毎」の「実行ユーザ比率」を設定し、

作成する。

機能抽出

• 「機能」を抽出する際、負荷テストの対象となる

  • 「代表的なパターンの抽出」という観点だけでなく、
  • 「ボトルネックの発見」という観点も含めると良い。

• 例えば、

  • 重要な機能
  • 複雑な機能
  • その他、性能的に問題がありそうな機能

  に、「ボトルネック」がないかどうかチェックすることは重要である。

シナリオ作成

• 「測定モデル」を参考にして、

  • 「代表的なパターン」や、
  • 「ポイント機能を含むパターン」を、

  シナリオとして作成する。

• シナリオ作成のポイントは、

  • 機能（スクリプト）の
    • 選定
    • 組合せ
  • 仮想ユーザ数の設定

  となる。

• シナリオの編成の例

シナリオ	仮想ユーザ数（参照系）	仮想ユーザ数（更新系）	仮想ユーザ数（追加、削除系）
シナリオ1(10ユーザ)	7	2	1
シナリオ2(30ユーザ)	14	4	2
シナリオ3(70ユーザ)	35	10	5
シナリオ4(100ユーザ)	70	20	10

※「仮想ユーザ数」が「測定モデルの実行ユーザ比率」に必ずしも準拠する必要はない。

移行メモ: シナリオ2・3 は合計が表題のユーザ数（30 / 70）と一致しないが、 上記の但し書きのとおり比率への準拠を要求しない例示であるため、原文のまま記載している。

レポーティング機能

• 経過時間と、仮想ユーザ数/平均レスポンスタイム/スループットのグラフ
• パフォーマンス カウンタなどのパフォーマンス情報を収集

アーキテクチャと負荷テスト

Webアプリケーション

HTTPはHeaderからBodyまで、全てテキスト表現となっているため、以下手順に従い、
負荷テスト・ツールを用いてスクリプトを作成し負荷テスト・シナリオを作成しやすい。

• Webアプリケーションをブラウザから操作しながら、
  HTTP電文をキャプチャしてスクリプトを生成する。
• 作成したスクリプトを実行し、
  アプリケーションが動作する（負荷をシミュレートできる）かを確認する。
• アプリケーションが動作しない（負荷をシミュレートできない）部分を確認し、スクリプトの修正を行う。
  • 動的に変更される可変値の追跡を行う。
  • ユーザ入力をシミュレートする。
    例えば、多重ログインができないシステムであれば、
    仮想ユーザごとに使用するユーザIDを変更するようにする。
• スクリプトを実行して、サーバーに負荷をかける。
• スクリプトを組合せ負荷テスト・シナリオを作成し実行する。

リッチクライアント(3層 C/S)

HTTP電文

HTTP電文になっていれば、サーバー側の負荷テストが可能。

• JMeterでRESTfulなAPIをテストする | ヘッドウォータース Tech Note！
• Apache JMeter でクラウド・ベースのアプリケーションをテストする（IBM developerWorks、公開終了）

バイナリ電文

• バイナリ電文を再送するだけのテストであれば、Apache JMeterなどの負荷テストツールが使える。
• 「可変値の追跡」が必要であれば、シミュレータやスクリプトを作成してサーバー側の負荷テストを実行する。
  • バイナリ電文はC構造体や.NETオブジェクトのバイナリ表現になっている事が多い。
    （e.g. HTTP＋バイナリ、WCF（WCF.md）-TCP/IPなど独自プロトコル＋バイナリ）
  • このため、バイナリ電文を使用するリッチクライアント・アプリケーションの負荷テストは、負荷テストツールでは実行が困難である。
    • 電文再送で負荷がかけられるような単純なサーバー機能でない限り、バイナリ電文は型情報が無いと上手く処理できない。
    • 殆どのビジネス・アプリケーションでは、その仕組み上、単純なバイナリの電文再送では負荷をシミュレートできない事が多い。
  • 結果として、バイナリ電文を使用するリッチクライアント・アプリケーションの負荷テストは、
    クライアントサイドのシミュレータやスクリプトなどを開発して負荷をシミュレートする事が多い。

リッチクライアント(2層 C/S)

以下の様な方法で負荷テストを実行する。

トレース ファイルの再生

クエリを記録して再生できる。

• トレース ファイルの再生 (SQL Server Profiler)

負荷テスト・ツール

負荷テスト・ツールを使用できる。
ただし、ワークロードの記録ができない。

→ 参考：Apache JMeter > 実施 > 2層C/Sの場合

シミュレータやスクリプト

また、P層 / B層(D層)が適切にクラス分割されていれば、
3層C/Sのようなシミュレータやスクリプトを作成しやすい。

回帰テストツール機能

リッチクライアント系の負荷テストでは、
回帰テストツールを利用できないか？と検討するケースは多いが、
製品によっては対応していることがあるが、基本的に難しい。

• 負荷テストツールを回帰テストツールとして利用することは可能。
• ただし、回帰テストツールを負荷テストツールとして利用することは困難。

.NETの場合

Webアプリケーション

ASP.NET Web Forms

（ASPNETWebForms.md）

以下がポイントのもよう。

• HTTPクッキーマネージャを設定（Session利用時）

• VIEWSTATEの引継を設定

• EVENTVALIDATIONの引継を設定

  EVENTVALIDATIONは、EnableEventValidation = true の際に
  生成され、PostBackおよびCallbackイベントを検証するための情報。
  これにより、Response・PostBack間で保存 → 復元される値が、
  改ざんされていないかどうかをチェックするようになるので、
  Response・PostBack間で保存 → 復元される値が、
  動的に変更になるような場合は、可変値を追跡する必要がある。

• CSRF(XSRF)対策用のTokenの引継を設定

  • CSRF(XSRF)対策の実装方針（CSRFCountermeasures.md）

• 参考

  • ASP.NET アプリケーションの過負荷試験を JMeter で行う。 - dunno logs
  • JMeter で ASP.NET の負荷試験検証した - minato128 blog

ASP.NET MVC

（ASPNETMVC.md）

• CSRF(XSRF)対策用のTokenの引継を設定
  • CSRF(XSRF)対策の実装方針（CSRFCountermeasures.md）

リッチクライアント

リッチクライアントの負荷テストは、

• Windows Forms
• WPF
• , etc.

前述の方法を参考にする。

• リッチクライアント(3層 C/S)
• リッチクライアント(2層 C/S)

考慮点

クライアントPC設定の考慮点

• ソケット枯渇を防止するために、負荷テスト・ツールのTCP/IPのTTLを0に設定する。
• すると多数のTCP/IP接続を使用するようになるので、以下の設定を行うと良い（Windows）。

利用可能ポート拡張

netshでdynamicport tcpの利用可能ポートを確認して拡張する（10000-65535）。

netsh int ipv4 show dynamicport tcp
netsh int ipv4 set dynamicport tcp start=10000 num=55536

TIME_WAIT状態の短縮

TcpTimedWaitDelayレジストリ・パラメタを短くする。

負荷分散時の考慮点

NLB（NLB.md）

パーシステンスの考慮

• パーシステンスによっては偏りが生じるので注意。
• IPアドレスだけでの負荷分散の場合は、１台のPCに複数のIPアドレスを割り当てることができる。

ツール比較

要約

Apache JMeter

• OSSなので
  • 無償である。
  • 公開情報が多い。
  • 経験者が多い。
• 玄人向けのツールで、
  • 適切に設定しなければ、正しく負荷をかけることができない。
  • また、必要に応じて「可変値の追跡」などのスクリプト修正が必要になるため、
    HTTPとアプリケーション実装の詳細を理解している必要がある。
• 逆に言えば、上記を熟知していれば、殆どのニーズに応えることが出来る。

製品

• 初心者でも適用可能。
  • 高機能なGUIを持つ。
  • 可変値の追跡が自動化されている（スクリプト修正が不要）。
• ユーザ数・期間に比例して費用が発生する。
• 中規模程度のテストを短期間に実施したい場合に適合。
• 製品によっては、回帰テストツールの用途で利用可能な、
  UI操作の記録・再生機能を持っていることがある。

クローズド

• 以下のような謳い文句のものが多い。

  • 製品より廉価で、
  • 痒い所に手が届くため大規模でも適合する。

• 課題は、

  • 結局、有償である。
  • クローズドであるため、インターネット上に情報が無い。

  という点。

回帰テストツール

回帰テストツールの種類

以下の２つがあり、其々タイプが異なるので注意が必要。

• UI自動化による回帰テストツール
• 負荷テストツール機能の延長上の回帰テストツール

回帰テストツールでの代替

バイナリ電文を使用するリッチクライアント・アプリケーションの負荷テスト用途に、
「UI自動化による回帰テストツール」を活用できないか？という話がよく上がる。

• Silk Test - OpenText（旧マイクロフォーカス）
• OpenText Functional Testing（UFT、旧 HP QuickTest Professional）

しかし「UI自動化による回帰テストツール」は、多重実行など、代替が難しい事がある。

参考

Top 5 Performance/Load Testing Tools

Top 5 Performance/Load Testing Tools In 2017

1. LoadUI Pro
2. Apache JMeter
3. HP Performance Tester (LoadRunner)
4. WebLOAD
5. Silk Performer
6. Rational Performance Tester

移行メモ: 見出しは「Top 5」だが、原文の列挙は6項目。原文のまま記載している。

補足（最新化）: 昨今は k6、Gatling、Locust、Azure Load Testing（JMeter / k6 のマネージド実行） なども選択肢になる。なお Visual Studio のロード テスト機能は 2019 で非推奨化され、廃止済み。

参考

• Apache JMeter
• Azure上でのテスト
• 負荷テストのポイント - Open 棟梁 Wiki

---

Tags: テスト, ツール類