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

本番前の負荷テストのお手伝いというお仕事が年に数回まわってきます。始めて負荷テストに取り組まれている方や単体での負荷テストしか経験のない方とお供すると勘違いや楽観的過ぎる計画になっていて修正をお願いさせていただくことがよくあります。
そこで、初心者向けに小生の経験から負荷テストのポイントをいくらかアドバイスしたいと思います。なお、小生は負荷テストの専門家ではないので、Qiitaに投稿されている専門家の方々の立派な記事もあわせて参考にしていただければと思います。

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

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

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

この記事で書くこと

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

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

1. なぜ負荷テストを行うのか

負荷テストを行う理由は色々あります。もちろん一番は運用に入ってから性能問題が表面化すると利用者に多大な迷惑や損害、信用への影響が出ることがあるからです。例えば次のような場合です。

• 金融：売買、取引の中断
• 民間：営業活用への支障や機会損失
• 医療：診療や看護への支障
• 大学：履修中断

そして本番後に発生した性能問題への対応は次のような事情があり非常に大変だからです。

• エラーとして表示されないしメッセージログにも記録されるものではないので原因究明が難しい。
• パフォーマンスデータを取っていても、その分析に大変な時間と労力を必要とする。
• 複数の処理が複雑に絡み合って発生することが多く原因特定に時間がかかる。
• 再現テストが簡単にできない。
• 現実はスケールアップもスケールアウトもプログラム修正も簡単にはできない。

性能問題は改善までに時間がかかることが多く、大変な損失につながる場合もあるので事前にできるだけ取り除いておく必要があります。その為には できるだけ現実に則した状況を想定した負荷テストを実施することが重要になります。

2. 負荷テストの概要と全体的なスケジュール

初心者の中には負荷テストはツールでボタンをぽちぽちすれば自動的に負荷がかかって、あっというまにレポート完成..というイメージを持たれている方がおられるのですが、残念ながらそんなに簡単ではありません。負荷テストは次のようなステップを実施します。

ステップ	作業名	内容	主な成果物	工数(人/日)
1	計画立案	性能リスクが懸念されるシナリオの洗い出し、目標やテストの種類の決定、必要リソースの洗い出し、計画書のレビュー	負荷テスト計画書	5
2	準備	関連部門への通知や支援要請、リソース確保、テストの開発環境の構築、勉強会	開発環境利用手順、テストツールの操作手順書	7
3	シナリオ作成	シナリオ詳細設計、作業指示書作成、リスク対策	負荷テストの詳細設計、作業指示書	9
4	シナリオプログラム作成	シナリオスクリプト作成	シナリオプログラム	9
5	テストデータ作成	サイト側テストデータ作成、クライアント側テストデータ作成	テストデータ	6
6	シミュレーション	予備テスト実施、分析シミュレーション、シナリオの妥当性確認	各成果物の修正版	6
7	負荷テストの実施	リハーサル、負荷テスト実施、テスト後作業	一時報告書(速報)	３
8	分析	計測結果分析、報告書作成、報告会実施、今後の方向性の決定	最終報告書	７

もちろんシステムの規模や特性、テスト目的や方法により工数の増減はありますが、5人前後のチームで活動して凡そ3～4週間のプロジェクトとなります。そして、負荷テストを進めるには次の要素が必要になります。

要素	具体的な対象
綿密な計画と設計	様々なドキュメント
各関係者への根回し	ステークフォルダ、 利用者、 システム管理者、 開発チーム、 関係会社
様々なリソース	人員、 時間、 機材、 費用
高い技術力	プログラミング力、 分析力、 プロジェクトマネジメント力、 対象システムの理解力、 対象業務の理解力

また、負荷テストの実施時期は早い段階で行えば行うほど良いです。リリースぎりぎりで行うと問題が発覚した場合に改修が間に合わなかったりリリース自体が遅れることになりかねないためです。

3. 計画立案のポイント

負荷テストの計画作成は次のようなステップを実施します。

1. リスクシナリオの洗い出し
2. 目標の設定
3. テスト方法の決定
4. 計画書の作成

3.1 リスクシナリオの洗い出し

シナリオとはある業務の操作や処理の一連の流れのシーンです。例えば本の注文のシナリオの場合、「会員ページにログイン」->「本の検索」->「本の選択」->「配送先の入力」->「決済情報の入力」->「確認画面」->「確定画面」->「ログアウト」 といった一連の操作がシナリオとなります。

システムには様々なシナリオがあり、このうち性能障害が発生すると業務に大きな支障が出たり損失につながるものをピックアップします。

次にピックアップしたシナリオに優先度を付け上位3～5位程度を選定します。理由は一度の負荷テストで確認できるシナリオは多くても5つ程度であることと、だいたい上位5位までがフィックスできればリスクの7～8割程度は回避できるからです。優先順位を付けるポイントは性能障害が発生しそうな処理を優先するのではないということです。先に紹介したように業務に大きな支障がでたり損失につながるものを優先します。初心者の方は機能面から選定してしまうことがありますが、利用者目線でリスクは選定します。

3.2 目標の設定

シナリオが選定できたら、そのシナリオで懸念されるリスクはどういったものかを検討し、それにあわせて目標や目的を設定します。ここでのポイントは目標や目的を明確にすることです。あいまいだと計測結果を正しく分析できなくなり意味のないレポートを作ってしまうリスクを負うことになります。また、プロジェクトのゴールがわからなくなります。

リスクには次のような例があります。

リスク	確認しておきたい内容
始めてシステムを導入する不安	普通に予定通りの性能が出るか
24H365Dの無停止運用を開始する	長期間運用に耐えうるか
締め切り間近にアクセスが集中する	限界要件に耐えうるか
多数の利用者が同時に同じ操作をする	スパイクアクセスに耐えうるか
運用投資計画を明確にしたい	システム限界点の見極め

これらに対して次のように分類されたテストの目的を当てはめていきます。

No	テスト目的
1	通常時に十分なパフォーマンスが得られるか確認する
2	ピーク時に十分なパフォーマンスが得られるか確認する
3	長期間運用しても十分なパフォーマンスが得られ、必要以上のリソースの消費がないことを確認する
4	指定した限界要件に耐えられるか確認する
5	システム限界点を見極める
6	限界を超えた場合にどのような現象が発生するか調べる
7	スパイクテストを行い短時間に処理が集中した場合に発生する現象を確認する

この目的に合わせて次の要素の目標値を設定します。これが分析時の判定の基準となります。

• レスポンスタイム(平均, 最大)
• スループット(平均, 最大)
• CPUやメモリ等のコンピューティングリソースの使用率(平均, 最大)
• ディスク容量等のコンピューティングリソースの消費量
• エラーの発生頻度
• その他 (ガベージコレクションの発生頻度等)

目標値の設定例です。

3.3 テスト方法の決定

目的や目標値が決まったら、それを調査するためのテスト方法を決定します。テスト方法には次のようなものがあります。

No	テスト方法	内容
1	予備テスト	調査対象の処理を1～数台のクライアントから行い、正しく動作し、小規模の段階でのパフォーマンスが十分であるかどうかを確認する。他の負荷テストを行う前の準備として実施する。
2	パフォーマンステスト	通常の予定同時接続数においてユーザが満足するパフォーマンスが出るかどうか確認する。チューニングを支援する。
3	ロードテスト	ピーク時において十分なスループットおよびパフォーマンスが発揮できるか確認する。チューニングの他、ノードやリソースの増強、ロードバランスのセッティングをも支援する。SLAやSLOで定義されたパフォーマンス要求の達成を目的とする耐久テスト（長期間連続運用しても十分なスループットとパフォーマンスが維持できるか）はこのテストに含まれる。
4	キャパシティテスト（限界値テスト）	予定以上の負荷をかけてパフォーマンスの要件を満たせるシステム限界値を検証する。将来のリソース拡張をプランニングするための指標となる。
5	ストレステスト（過負荷テスト）	過負荷な状態にして障害を発生させると、どういった症状が発生するかを検証する。（同期不良、競合、メモリーリークなど）を確認する。スパイクテスト（短時間に多数のクライアントから同時にリクエストを発生させる）はこのテストに含まれる。

各リスクシナリオに対してどういったテストを行うかが決まったら、どれくらいの負荷をかけるのか、その負荷をかけるために必要なリソースは何でどれくらい必要かを検討します。

3.4 計画書の作成

これまで検討してきた事を整理し計画書に落とし込みます。計画書には次の事項を盛り込みます。

• リスクシナリオ一覧
• テストの目的一覧
• テストの方法と負荷のかけ方一覧
• 判断の指標となる目標値一覧
• プロジェクトメンバーと役割分担
• 作業スケジュール
• テスト及び準備に必要なコンピューティングリソース一式
• 予定成果物
• 費用
• 情報の共有方法（報連相含む)

計画書が出来上がったら、負荷テストプロジェクトのメンバーでレビューを行います。計画の合意が得られればそのままキックオフとし次のステップに進めます。

4. 準備のポイント

準備の段階では次の作業を行ないます。

1. 関連部門への通知や支援要請
2. リソース確保
3. テストの開発環境の構築
4. 勉強会

4.1 関連部門への通知や支援要請

負荷テストをリリースを控えた本番環境を使って行う場合は開発プロジェクト本体やプレ作業を行なっている関係者に対して計画の通知を行う必要があります。場合によっては関係者全員を集めて説明会を開く必要があります。また負荷テストプロジェクトメンバーだけでテストを遂行できない場合は各署に次のような支援を要請します。

対象各署	通知・支援要請内容
開発プロジェクト本体	負荷テスト作業全般の全体への通知、テスト結果の評価、テスト実施日のオペレータが必要な場合は要員の要請
アプリケーション開発者	シナリオプログラム及びテストデータ作成支援
データベース管理者	バックアップを含むテストデータへの入れ替え作業支援、計測データ採取、計測データ分析支援
Webシステム管理者	計測データ採取、計測データ分析支援
ネットワーク管理者	ネットワーク環境の隔離などテスト環境の構築支援、計測データ採取、計測データ分析支援
ハードウェア管理者	テスト環境構築支援、計測データ採取、計測データ分析支援 (オンプレ時)
外部機関	高度な技術を必要とする場合の支援、一部作業のアウトソーシング
プレ利用者やユーザ	負荷テスト実施予定通知、 一部テスト結果の評価

4.2 リソースの確保

ここでは物理的なリソースの手配を行います。テスト計画作成段階でリストアップしたリソースの手配を行います。主に次のような作業を行います。

作業	ポイント
機材のレンタル	できるだけ予備機も確保しておくこと
負荷テストツールの手配	有償ツールの場合はライセンスが利用期間になっている場合があるので注意。また手配に時間を要する場合があるので注意。 始めて利用するツールの場合はベンダーに操作指導の依頼を行うのもよい。
会場の確保	オペレータ操作で負荷をかける場合や計測する場合は、安定したネットワーク性能が保てる会場を確保しておく。
備品の準備	必要に応じてストップウォッチ、クリップボード、メモリスティック、ケーブル類、ネットワーク機材、工具、等々を用意すること

4.3 テストの開発環境の構築

本番環境のミニマム構成の環境を構築します。この開発環境上で負荷テストツールの習得、シナリオプログラムの作成、テストデータの作成を行い、各シナリオプログラムの単体テストまでを実施します。また、分析手順の確認もこの環境のテストデータを使って行っておきます。なお、ミニマム環境であっても接続元のアクセス制限などセキュリティには十分配慮してください。

開発環境が準備できたら次の資料を作成し関係者に提供します。

• 開発環境システム構成図
• 開発環境利用手順書
• 負荷テストツール操作マニュアル

4.4 勉強会

負荷テストプロジェクトを円滑に進めるため、状況によっては次のような勉強会を開催します。

勉強会名	ポイント
負荷テスト入門	はじめて負荷テストに関わるプロジェクトメンバーへ経験者がポイントをレクチャー
業務やシステムの理解	負荷テストプロジェクトメンバーが対象システムや業務の理解度が十分でない場合に実施。開発プロジェクト本体に講師を依頼する。
負荷テストツールの理解	始めて利用する負荷テストツールの場合は負荷テストプロジェクトメンバーの代表者がルーツベンダーの研修を受講し、プロジェクトメンバーにフィードバックのハンズオン勉強会を行う。ベンダーより講師を招いてもよい。
操作オペレーション	オペレータの操作で負荷をかける場合は負荷テストツールやアプリケーションの使い方、データの計測方法をオペレーターにあらかじめレクチャーしておく。

5. シナリオ作成のポイント

ここではシナリオの詳細設計を行います。シナリオの詳細設計とは現実的な利用シーンを想定して操作の流れ図を作成したり負荷のかけ方を作成します。さらに、負荷をかけるオペレーション方法や負荷テスト中に想定されるリスクへの対策も検討します。

1. シナリオパターン一覧の作成
2. 作業計画書の作成
3. リスク対策の準備

5.1 シナリオパターン一覧の作成

シナリオパターンとは、リスク対象のシナリオを負荷テストができるようにシステマチックに置き換えたものでテストするシーン分作成します。例えば次のような遷移図です。これまでのように操作したページを並べるだけでなく、データの受信と送信、次のページに移るまでの思考遅延などを意識した内容となります。思考遅延とは実際に人が行うオペレーションを想定したら次の操作を行うまでに考える時間があるよねというところに設定する”待ち時間”です。これを入れることでより現実を意識したシナリオパターンになり正確な負荷テストができるようになります。

これに加えて負荷テストツールの実行のさせ方の要素を検討します。シナリオの繰り返し回数や仮想ユーザを段階的に増やすのか一気に増やすのかといった点です。

シナリオの詳細設計で必要な要素

要素	主な検討事項
シナリオパターンの詳細設計	ページの遷移数、ページ遷移のタイミングや思考遅延、 仮想ユーザの増減方法、負荷をかける回数や時間、シナリオパターン毎のテスト実施回数、 エラーへの考慮
データ設計	バックエンド側に配置するテストデータ（蓄積データ）の内容・分量・偏り、 クライアント側（エージェント側）に配置するテストデータ（入力データ）の内容・分量・偏り、 適度なエラーデータの盛り込み
実施に関する設計	どのクライアントから負荷をかけるか(ランダムにかけられるか)、 各計測ポイントでどんなデータを採取するか、どんなフォーマットで保存するか どのタイミングで計測データを採取するか
分析に関する設計	計測データの分析方法と資料化方法の確定、 計測データの保管先の確保

5.2 作業計画書の作成

ここでは負荷テスト本番当日の行動計画を作成します。特に本番環境を使ってテストする場合はシステムを借りれる時間が限られてきますので、綿密な計画をたてておかないとテストを完了することができなかったり他の開発作業に影響を及ぼすことになります。
次の表は簡単な例になります。

No	作業	開始予定日時	終了予定日時	担当者
1	ブリーフィング	4/30 22:00	4/30 23:00	全員
2	テスト用機材設置	4/30 23:00	5/1 0:00	B,Cさん
3	システムの利用停止	5/1 0:00	5/1 0:15	Aさん
4	既存データのバックアップ	5/1 0:15	5/1 1:15	Dさん
5	ネットワークから隔離	5/1 1:15	5/1 1:30	Nさん
6	テストデータへの入れ替え	5/1 1:30	5/1 2:30	Aさん
7	予備テスト	5/1 2:30	5/1 3:15	全員
8	データクリア	5/1 3:15	5/1 3:30	T,Dさん
9	本番テスト1回目	5/1 3:30	5/1 4:15	全員
10	データクリア	5/1 4:15	5/1 4:30	T,Dさん
11	本番テスト2回目	5/1 4:30	5/1 5:15	全員
n	...以後必要回数繰り返し	5/1 5:30	5/1 10:00	全員
12	計測データの保存状態確認	5/1 10:00	5/1 10:15	Tさん
13	既存データのリストア・リカバリ	5/1 10:15	5/1 11:15	Dさん
14	テスト用機材撤収	5/1 10:15	5/1 11:15	B,Cさん
15	システムの基本動作確認	5/1 11:15	5/1 11:45	B,Cさん
16	ネットワークへの復帰	5/1 11:45	5/1 12:00	Nさん
17	不要なバックアップや一時ファイルの削除	5/1 11:45	5/1 12:00	T,Dさん
18	システム再開案内	5/1 12:00	5/1 12:15	Aさん
19	計測データの簡易分析	5/1 12:00	5/1 15:00	Tさん
20	速報報告・ブリーフィング	5/1 15:00	5/1 15:30	全員

5.3 リスク対策の準備

これまでの経験から、実際に作業を進めていくと全て順調に滞りなくテストが完了することは稀で何がしか問題が発生します。事前に問題を想定しておき対策案を用意しておくことで作業の混乱を回避することができます。
以下はリスクと対策案の例です。

リスク	対策案
プログラムバグの発覚	影響あるシナリオのテスト中止。軽度の場合は1日延期。重度の場合は再スケジューリング。
データバグの発覚	影響のあるシナリオのテスト中止。軽度の場合は1日延期。重度の場合は再スケジューリング。
機材の破損	速やかに予備機に置き換える
ネットワークダウン	テスト中止。軽度の場合は1日延期。重度の場合は再スケジューリング。
負荷テストツールの不具合発生	テスト中止。軽度の場合は1日延期。重度の場合は再スケジューリング。
時間切れ	延長可能時間を事前に確認しておく。基本的には翌日実施
計測データが採取できなかった場合	テストを続行する。採取できない回については分析しない。ただし、2回データ採取に失敗した場合はテストを中止し原因調査、1日延期とする
予想を大きく上回る高結果	関係者で妥当性検証を行う。妥当でない結果であった場合はデータを放棄し、原因調査、対策実施し、翌日以降に再テストとする。
その他予想外の障害	PMに連絡の上指示を仰ぐ。PMは責任者及び各リーダに状況を連絡、対応協議の上、指示を連絡する。

今回はここまで

ずいぶん長くなってしまいましたので今回はここまでとします。
次回はシナリオプログラム作成のポイント から 結果を踏まえて対策のポイントまでを一気に紹介します。 お楽しみに。