負荷テストの基本的な考え方と進め方(後編)

昨年早々に続きを書くつもりでしたが世の中そうはうまくいきませんね..。お待たせしてすみませんでした。
さて、前回は「シナリオ作成」のポイントまでを紹介しました。
後半は「シナリオプログラム作成のポイント」から「結果を踏まえて対策のポイント」までを一気に紹介します。
前回同様一応前置きですが、小生は負荷テストの専門家ではないので、Qiitaに投稿されている専門家の方々の立派な記事もあわせて参考にしていただければと思います。

この記事で扱う負荷テストの定義

この記事では次の要件を対象とします。

• システムテスト(総合テスト)の段階で行う負荷テスト。
• 分散ノードが十数台規模、データ量も数百GB程度までの中規模までのシステム。
• 基本はロードバランサで負荷分散するWebシステムでバックエンドにデータベースが控える構造であるが、一部C/Sもあり。

この記事で書くこと

今回は6〜11を記載します。1〜5は前回をご覧ください。

1. なぜ負荷テストを行うのか
2. 負荷テストの概要と全体的なスケジュール
3. 計画立案のポイント
4. 準備のポイント
5. シナリオ作成のポイント
6. シナリオプログラム作成のポイント
7. テストデータ作成のポイント
8. 予備テスト（リハーサル）のポイント
9. テスト実施のポイント
10. 分析のポイント
11. 結果を踏まえて対策のポイント

また、この記事は考え方と進め方の紹介となりますので負荷テストツールの使い方などハンズオン的要素は今回は記載しません。

6. シナリオプログラム作成のポイント

負荷をかけるためのシナリオプログラムを作ります。ここでは次のポイントを押さえます。

1. 負荷テストツールの仕組み
2. 負荷テストツールの種類と言語
3. 注意点
4. 成果物

6.1 負荷テストツールの仕組み

通常Webアプリケーションを利用する場合は、WebブラウザからWebアプリケーションにアクセスし、テキストボックスなどにデータを入力して送信ボタンを押して処理を実行します。

対して負荷テストツールは入力データを直接HTTPリクエストに埋め込んで送信します。これを連続実行しつつ複数のスレッドで並列実行することで負荷をかけています。この時、入力データをどのファイルから読み込むかやどういったタイミングでリクエストを送信するかを定義するのがシナリオプログラムになります。

このプログラムは一般的にはスクリプト言語で記述します。画面遷移を制御構文で定義したり、Sleep文で思考遅延を定義したり、どのデータソースから入力データを呼び出して、どのINPUTタグのフィールドに値をセットするかといったことを記述します。

なお、多くのツールは一連の画面操作をシュミレートすると自動的に一定のシナリオプログラムを生成する機能を有しています。この機能を使って一般的には次のステップで作用を行います。

1. シュミレートしてシナリオプログラムを自動生成する。
   　　　↓
2. 生成したシナリオプログラムに読み込むデータソースや制御構造を追記するカスタマイズを行う。
   　　　↓
3. シナリオパターンに沿ってこれをテンプレートにして複数のシナリオプログラムを作成する。

6.2 負荷テストツールの種類と言語

負荷テストツールはOSSから有償の物まで多数存在します。しかし、マイナー分野のプロダクトのため製品ライフサイクルが早く、WebAPの技術向上とともに新しいツールも出てきますが、更新や開発が終了してしまうツールも相応にあるので、その時々で必要な機能があり安定版があるツールかを見極めることが重要になります。また、それぞれのツールで採用しているスクリプト言語もバラバラですので、学習コストがかかることも織り込む必要があります。よって、初心者が重要なシステムの負荷テストをする場合は、多少費用がかかっても、日本語サポートやテスト開発の支援が受けられる日本法人や代理店のあるプロダクトを選択することも一案かと思います。
次の表は本記事の前提範囲をテストする際に適性と思われるツールリストです。他にもいろいろあり、使い方も多数インターネット上に投稿されていますで検索して研究してみてください。また原点に戻って手作りという方法もあります。

区分	プロダクト	提供元(代理店)	スクリプト言語	備考
OSS	JMater	Apache	パラメータ埋め込み＋BeanShell(Java)	一般的一番に使われていると思われる。WebAPとRDBに負荷をかけられる。
OSS	Locust	Locustコミュニティ	Python	Pythonベースのツール。コミュニティはMicrosoftやAWSからの支援も受けている。
OSS/有償	gatling	Gatling Corp	scala	JMeterと対等できることで近年国内でも話題のツール。有償版もあるが国内代理店は現時点ではなさそう。
有償	LoadRunner	MicroFocus(アシスト等)	独自(TSL) とC言語、JavaScriptに対応。	老舗のツールであるが現在も進化中。最新WebAPからC/Sまで対応可能。
有償	Silk Performer	MicroFocus(同日本法人)	独自(Benchmark Description Language (BDL) )	最新WebAPからC/Sまで対応可能。今は上記と提供元が同じなので提供元に製品特徴や価格を要相談。
その他	手作り	自分	制限なし	開発力があるならアプリケーションに合わせて専用プログラムを手作りすることもあり。最も最適なテストができ、上記のようなツールを使うよりも費用を押さえられることもある。

6.3 注意点

シナリオプログラムの作成やそれを実行するツールによっては次のような注意点があります。ツールのオフィシャルサイトや公開ドキュメント、インターネットの投稿記事なども参考にしましょう。

• 仮想クライアントはスレッドなので接続元のIPアドレスが同じになるツールがあります。接続元のIPアドレスを基準に分散するタイプのロードバランサーを対象とする場合は工夫が必要です。
• 現実にできるだけ近づけるようにリクエスト送信間隔時間はランダムにしましょう。ランダム時間を取得する関数が標準で用意されていない場合はカスタムで作成しておくと便利です。
• 上記と同じように思考遅延間隔もランダム時間を利用するとより現実的なテストが実現できます。
• 自動生成されたシナリオプログラムのINPUTタグのパラメータは固定値がセットされていますので、必ず、テストデータを読み込んで送信データを上書きするようにカスタマイズしてください。
• 各スレッド毎にデータはランダムにセットされて送られるように工夫してください。現実において同じデータが別々のクライアントから送られることは少なく、また、同じデータだとキャッシュがヒットして想定以上に好結果が出てしまう可能性があります。
• ポップアップやショートカットに対応できないツールもあるので注意してください。

6.4 成果物

• シナリオプログラム（スクリプト）
• シナリオプログラム仕様書（必要に応じて）

7. テストデータ作成のポイント

テストデータといっても1つではありません。いろいろなポジションでそれぞれのテストデータが必要になります。ここではそれを踏まえ次のポイントを確認します。

1. 作成するテストデータの種類
2. 注意点
3. 成果物

7.1 作成するデータの種類

作成するデータには次のものがあります。

• Webサーバ側に事前にセットしておくマスタデータ
  アプリケーションを実行するための一般的なマスターデータです。担当者マスタとか商品マスタとかそういった一般的な物です。新規作成中のシステムの場合は作成します。既存システムの場合は次の2つの方法のどちらを採用するかを検討します。

1. 本番環境とは別の場所で負荷テストをする場合
   現行のデータをエクスポートし、個人情報や機密情報をマスキングする加工を施して無害化したデータを用意します。
2. 本番環境上でテストする場合
   テストする直前にシステムを停止して静止点をとり、バックアップを取得します。その後、本番データをそのままテストデータとしてテストを実施します。テスト終了後にバックアップデータをリストアして復元します。

• Webサーバ側に事前にセットしておく蓄積済みトランザクションデータ
  運用開始後どれほどの日数が経ってからの負荷を知りたいのかを考慮して、その時点までのトランザクションデータもテスト前に登録しておく必要があります。データが空の時と大量のデータがある時ではトランザクションにかかる負荷のかかり方が大きく変わるからです。テストデータを作る要領はマスターデータを作成する場合と同じです。　

• 負荷テストツールで読み込む入力データ
  Webアプリに送信するデータです。ツールの機能によってデータソース(CSVファイルやRDBのテーブル)は次の分割単位毎に用意する必要があります。また、各分割単位を組み合わせてデータソースを用意する必要がある場合があります。

分割単位	説明	用意するデータソースの数
シナリオプログラム毎	自動でデータを各スレッドに割り振るコントロール機能を持つツールを使う場合はシナリオ単位でデータを用意します。 コントローラがラウンドロビンで配下のスレッドに適切にデータを配ります。	シナリオ本数分
画面毎	複数回の画面遷移がある場合は入力画面毎にデータソースを用意する必要があります。	画面数 x シナリオ本数分
クライアント毎	複数のPCや仮想OSにエージェントを実装し、そのエージェントが多数のスレッドを展開して負荷をかけるツールの場合でエージェントがローカルファイルシステム内からしかデータソースを参照できない場合はPC/エージェント毎にデータソースを用意します。	クライアント台数 x 画面数 x シナリオ本数分
スレッド毎	コントローラがスレッドにデータを配信する機能を持たない場合にスレッド毎にデータソースを用意する必要があります。	スレッド数 ｘ クライアント台数 x 画面数　x シナリオ本数分

ツールが高機能なほどデータソースを集約できる傾向にあり、ツールが軽快で単純な機能しかない場合ほどテストデータを細分化して多数用意する必要が発生します。

全てのスレッドで1つのデータソースしか参照できない場合もあります。この場合はクラウアントを複数用意し、クライアント毎にコントローラを分け、1スレッド＝1シナリオでそれぞれ別のデータソースをセットすることで回避することができます。ただし、負荷をかけられる分散幅は狭くなります。

7.2 注意点

• テストデータはできるだけ現実世界に近付くように適当にバラバラにしてください。テキスト入力欄等にセットされるデータが不自然に同じだとキャッシュのヒット率が異常に上昇して適切な結果が得られなくなります。

• コード形式のデータ入力欄に対して不自然に連番をセットしないようにしてください。自然な揺れや偏りが発生しなくなりこれまた適切な結果が得られなくなる可能性があります。

• ロードテストなど処理を繰り返し実行する場合は、同じデータが再セットされて重複エラーにならないように十分なデータ量を用意してください。

• 入力ミス等のユーザエラーも考慮する必要がある場合は適度に異常系データも混入してください。　

7.3 成果物

• Webサーバ側テストデータ（マスターデータ、蓄積データ）
• クライアント用テストデータ(入力データ)

8. 予備テスト（リハーサル）のポイント

いよいよ準備の最終段階です。予備テスト（リハーサル）を行います。ここでは次の点を確認します。

1. リハーサルの実施
2. 分析シミュレーション
3. 成果物

8.1 リハーサルの実施

リハーサルは小規模なテスト環境を作るところから始まりになります。作業環境（オフィスやプライベートクラウド）にクライアント１台でスレッド2程度、サーバ側は分散ノード1〜2台程度のミニマムテスト環境を構築します。結果の正常性が確認できる最小容量のデータでテストを実行し不備や不足はないか、見落としていた問題はないかを確認します。この段階では高いスペックは不要です。
なお、リハーサルにあたって前提条件があります。必ず「対象のアプリケーションが完成していること」です。近年はアジャイル開発が盛んなのでどの時点を完成とするかという問題もありますが、少なくともテストシナリオをカバーする機能は仕上がっていることが前提です。稀に開発スケジュールが押してリハーサルをスキップして本番テストに入ることがありますが、経験からすると大体どこかでトラブルか結果データ不適で多かれ少なかれやりなおしが発生することが多いです。
このステップでは次の点を確認します。以外に重要なのが3点目の「1スレッドでの1サイクル」でシングルトランザクションの時点で実は既に問題をかかえていたというパターンが結構あります。

• 環境構築手順書に沿って作業を行い、問題なくテスト環境が構築できたか？
• 環境構築にかかる時間は適切か？
• 最初に行う「1スレッドでの1サイクル」がまず正しく実行できたか？
• 作業計画書に沿ってツールやコマンドの操作が適切に行えたか？
• シナリオプログラムに不具合はないか？
• テストデータは順調にロードされたか？
• 計測データの採取や保管は順調に行えたか？
• 既存環境を使う予定の場合は、データベース等の現状復帰手順に問題はなかったか？

8.2 分析シミュレーション

リハーサルで採取した計測データを分析手順書に沿って表やグラフ化しレポートにしてみます。内部レビューを行い次ような点を確認し問題があるようなら本番テストまでに修正を行います。

• 分析手順書の手順は適切だったか？
• エラーが非常に多いなど極端な結果になっていないか？
• 確認したかった点が網羅されているか？
• 負荷のかかり具合は時間軸に対して適切だったか？
• 計測する必要がなかった余分なデータはなかったか？

8.3 成果物

• リハーサルの結果のレビュー記録
• 問題点リスト

9. テスト実施のポイント

いよいよ本番テスト実施です。オンプレでテストを行う場合や何人もの人手を使う中規模テストになるとテスト当日は非常に慌ただしくなります。準備した段取りを粛々とこなし予定通りテストを完了することを目指しましょう。ここでは次のポイントを押さえます。

1. テスト前の準備
2. 負荷テスト本番
3. テスト後の作業
4. 成果物

9.1 テスト前の準備

テスト開始までには次のような準備作業を行います。時間は限られていますので作業の並行化などで手際良くこなしましょう。

作業	詳細	掛かる時間
既存データのバックアップ	特に既存の環境でテストする場合は、できるだけ二重(または２種類)バックアップを取得し、リストアテストも行い確実に現状復帰できることを担保します。場合によっては前日から作業に入ったりディスク自体を付け替えたりします。	数時間
サーバデータ入れ替え	特に既存の環境でテストする場合、既存データはできるだけファイルのリネームなど簡単な方法で退避します。その後用意したテストデータをインポートして置き換えます。	数時間
機器の搬入と設置	オンプレの場合はクライアントPCの配置やネットワークへの接続を行います。機器の準備ができたら起動して基本的な動作確認と微調整を行います。	1〜2時間
ネットワーク環境をテスト用に切り替え	特に既存の環境でテストを行う場合は一般利用者からテスト環境にアクセスされないようにファイアウォールやスイッチでアクセス制限を行います。物理的に切り離しても良いです。	30分
リハーサル	ここでのリハーサルは動作確認程度の簡単なものです。採取するデータとなるログの記録ができることまでを確認します。また人手を使う場合は採取したデータの集積手順や作業チェックシートの記入具合も確認します。	1時間

9.2 負荷テスト本番

いよいよテスト本番です。ここでは次の点に注意ながら作業をコントロールしてください。このコントロールは非常に重要です。後手に回るとテストが破綻することもあります。

1. 的確に指示を出す
   限られた時間で多くのテストを実施しますので、プロジェクトリーダは的確に指示を出し円滑にテストを進める必要があります。

2. 計画を厳守する
   性能が出ない場合、得てしてチューニングを行いたくなることろです。また、一部データが採取できなかった場合は、余分に再テストを行いたくなります。しかし、計画を逸脱するとその後の作業に影響を及ぼし、計画を回復することが不可能になる可能性があります。
   よって計画通りに作業を行なうことを心がけてください。
   また、作業者が独自判断で計画を逸脱して二次障害を起こすこともありますので、作業者に対してリーダの指示なしに余分な作業を行なわないように指示しておいてください。

3. リスク発生時の対応
   性能が期待を大きく下回りテストの継続が意味を成さない場合やシステムに致命的な障害が見つかりテストの継続が困難になった場合等は、予め取り決めた「リスク対策」に則ってテストを中止してください。他にも発生した障害に対してはリスク対策に則った行動をしてください。リスク対策にない対応や作業を行うとプロジェクトが混乱したり、場合によっては大幅な時間オーバーなどでステークフォルダに迷惑をかけることに繋がる可能性もあります。

4. 計測データを安全に確保
   計測データは絶対に失わないように安全な場所（指定された場所）に保管してください。テストの都度保管状況を確認してください。できれば二重で保管することをお勧めします。誤って撤収時に削除したり、引き上げ忘れたりすることのないよう注意してください。

9.3 負荷テスト後の作業

ここから最後の一踏ん張りです。撤収作業では次のポイントに注意しましょう。

作業	詳細
計測データの保管	集積した計測データを確実に保管してください。メディアに書き出したりクラウド上の安全なストレージに保管してください。
機器の撤去	PCやスイッチなど物理的な機器を取り外します。さらにサーバ環境に残っている一時データやファイル、ログ、プログラムは忘れずに全て削除してください。また環境変数などシステムの設定を変更した場合は元のパラメータに復元してください。
サーバデータの復旧作業	テストデータを消去しバックアップからリストア・リカバリーを行います。データベースとアプリケーション環境が現状復帰したら利用者の代表に動作確認を依頼してください。この時、動作確認するクライアントだけがシステムにアクセスできるようにファイアウォール等のセキュリティシステムを調整してください。動作確認が終わるまではオープンにしない様に注意してください。
ネットワーク環境を本番用に切り替え	一般からのアクセス制限を解除してシステムを再開します。一般から正常利用できることを確認してください。

また速報をステークフォルダーに報告して状況を共有してください。速報のポイントです。

• 基本性能値を分析にかける
  　レスポンスタイムやスループットなど基本的なメトリクスを表やグラフ化します。可能であればサーバ側のCPU、メモリ使用率とディスクIDあたりも時系列に表やグラフ化してください。
• 速報として一時報告し、今後の方向性を検討する
  　大枠において目標を達成できているかを確認します。その結果により詳細分析をどのような方向に進めるかを検討します。

9.4 成果物

• 記入済みチェックシート(計測値記入)
• 記入済みチェックシート(作業エビデンス)
• 計測データ
• 速報レポート

10. 分析のポイント

採取した計測データを分析し最終評価を報告書を作成します。ここでは次の作業ステップを確認します。

1. 分析手順
2. 集計とグラフ化
3. ボトルネック分析と調査のポイント
4. 報告書の作成
5. 報告会の実施

10.1 分析手順

負荷テストのデータはクライアント、DB、Webサーバ、APサーバとそれぞれのポイントで採取したメトリックスを時系列に整理して分析します。少量のデータであればスプレッドシートだけでも整理できますが、通常は短時間でも膨大なデータ量になるため一旦データベースにデータをロードして整理・分析を行います。データベースはRDBでもDWHでも使い慣れた方をご利用ください。手順としては次の図のようになります。

10.2 集計とグラフ化

各分析対象の分析項目（列・軸）と生成するグラフ形式の対応例です。これ以外にも必要に応じて様々な角度から分析材料を作成します。

10.3 ボトルネック分析と調査のポイント

速報によって分析の方向性がある程度できていると思いますので、それに合わせて分析素材を作成し多角的に検討したり組み合わせて原因調査をします。なお分析素材を作成、検討するときは次の点に注意してください。

• 計測値の上限／下限の数%には異常値が含まれる場合があり、平均値を異常に押し上げたり押し下げたるする場合があります。それらの数値は切り捨ててください。（例：他の値より1桁以上多いといった値）
• 複数のグラフを重ねて分析する場合、横軸の基準が違っていて比較しにくい場合があります。例えば横軸が時間軸になっている表と接続数軸になっている表を組み合わせて検討する必要がある場合です。こういった場合は、先におおよそ何時何分にどれだけの接続数があったかを調査してそれを表やグラフ化しておいてから、先の2表に重ねて分析します。第二縦軸を使った分析を使います。
• 負荷が高くなるにつれて性能が向上したり、一定になる場合はテストデータに問題がある可能性があります。同じデータの不自然な繰り返し利用が発生していて異常にヒット率を上昇させている可能性が疑われます。
• 限界点を検討する時は、レスポンスが落ちてくるポイントではなく、エラー数が急増してくるポイントが限界点と判断してください。

下図は正常な結果の例です。時間の経過と共にスループットが下がり、応答時間が上昇し（時間がかかる）、エラー発生数も増えます。点線の少し前からエラー量が急激に上がっているのでこのあたりが限界となります。

10.4 報告書の作成

報告書には次のような項目を盛り込みます。これ以外にもシステムの特製に合わせて必要な情報を追加してください。

順番	項目	詳細
1	前振り	全体の結果のサマリ
2	テスト方法のおさらい	テストの趣旨 実施日時、期間 実施場所、環境 シナリオや負荷のかけ方の概要 各テストの性能指標
3	結果詳細	テストケース(シナリオ)毎の結果概要 結果の根拠になるメトリックスの分析に使った表や図
4	結論	分析と結論のリンク付、 チューニングや改修の効果(または必要性) システムの性能限界についての考察

10.5 報告会の実施

レポートが完成したら報告会を開いてクロージングに向かいます。一般的な報告会と同様に次のような議題で進めてください。

1. 分析結果のフィードバック
2. 質疑, 応答，協議
3. 合否の判定
4. 今後の進め方

なお、必ず関係者全員を集めて実施してください。通常のテストのように正/誤で簡単に合否判断できない要素も多く、専門家や利用者の視点も交えて議論しないと判定できないことがあるためです。

11. 結果を踏まえて対策のポイント

最後にテスト結果を次につなげます。次の点を確認します。

1. 次の行動
2. 成果物の保管管理

11.1 次の行動

報告会の結果により今後の行動を起こします。結果が芳しくなかった場合は再テストですが、良かった場合も良かったのは現時点であり、運用を続けていけばどこかで変化が起こりますので、その時に向けた計画を検討します。

結果	次の行動	詳細
目標をクリアできなかった	再テスト計画立案	対象システムのチューニングや改修計画の立案
データに異常値や偏り,矛盾が散見された	再テスト計画立案	負荷テストシナリオ, シナリオプログラム, テストデータの見直し
目標をクリアできた	リソース拡張計画策定のためのテストの提案	限界テスト実施検討(性能監視を正確に行うため) 定期検査計画検討(システムの進化による特性の変化を把握するため)

11.2 成果物の保管管理

テストが終わっても成果物は大切に保管してください。次のような利用価値があるからです。

• 次の行動でも紹介したように、再テストや定期テストで流用したり再利用したりできる可能性がある。
• 他の負荷テストでテンプレートとして流用できる可能性がある。

なお、成果物を保管する場合、次の点は十分注意してください。

• 個人情報や機密情報が含まれているデータや資料は残さずに完全に削除する。
• シナリオプログラム等にライセンスコードやアクセスキー、認証情報が記載されている場合は必ず削除しておく。
• 成果物は個人で保管せず、組織内で決められた保管場所に保管する。

お疲れさまでした

いかがだったでしょうか？
近年はクラウド化が進み、スケールアウトやスケールアップがしやすくなったので負荷テストを否定される方もいらっしゃいますが、ランニングコストを考えると闇雲に拡張はできないと思いますので、まだまだ負荷テストの需要はあるのではないかと思います。
長文で申し訳なかったですが、これまでの経験をフィードバックすることで一部でもみなさんのお役に立てればと思います。