7. 負荷テストの評価基準には何 を使えばよいのか? に戻る
はじめに
一般的に負 荷テストには、目的に応じて以下の4種類のアプローチがあると言われています。
* 性能テスト - スループット
* 性能テスト - 応答時間
* 限界テスト
* 耐久テスト
負荷試験はシステムに対する客観的評価手法の 一つですが、何をもって判定基準や達成目標にするかという明確な指標を伴わずに、漫然と一定量の負荷をかけて問題が起きなければそ のまま完了とするスタンスには問題があります。
実行時に明確な目標と指標が無い場合には、採取したデータも活用の出来ない 意味の無い客観データになりやすいですし、また、テスト時に可能である潜在的な性能問題の発見/改善のせっかくの機会を見逃すこと になります。
本編では、これらアプローチ毎の目的設定と指標の考え方について整理して解説します。
負荷テストを行うことの目的
負荷テストは、システム開発プロセスにおける結合テストの最終フ ェーズで行われます。
一般的には、負荷テストの実施に際して期待される内容は、「運用時に想定のユーザー数の利用に耐えう るかどうか?」という観点の評価判断となります。
もし、それが単に「想定のユーザー数で耐えられるかどうか?」という視点 であれば、想定した一つのシナリオを求められるユーザー数分、単純に同時実行し、その結果、問題が発生しないことを確認出来れば合 格とみなすことが可能であると考えられます。
しかし、“運用時に”想定のユーザー数で耐えられるかどうか?という実運用を 想定した評価判断が求められる場合には、様々な角度からシステムの性能を判定する必要があるだけでなく、数値的な参考指標を取得し ておき、運用時の安全範囲と危険範囲等の境界値の割り出しや、所定以上のアクセスがあった場合に起きる潜在的な限界点の把握等が求 められます。
ただ、実運用時に生じるシステムの全ての振る舞いを、予め予測してテスト時にカバーすることは、実際のユーザ ーのアクセスパターンを完全に予測出来ない以上、到底不可能で、もしカバー出来たとしても、工数が掛かりROI的に見合わないものにな るでしょう。
その為に、要点を絞って効果的に負荷テストを行うアプローチとして前述の4つのテストパターンが存在するとい うことになります。
性能テスト - スループット
このテストは、システム の処理能力(スループット)に着目した試験です。Webシステムにおいては、一定の時間当たりにどのくらいのユーザーが、ログイン→閲覧 →登録等の定められたユーザー操作を行うことが出来るのか、または、時間当たりのページ処理数やリクエスト処理数、場合によっては 、転送データ量等について数値的指標を割り出すためのテストです。
実行結果として得られる数値的指標は大別して以下の二つ になります。
* 範囲時間内の通算処理量(実行されたユーザートランザクション数)
30分や 1時間等の一定時間内にどのくらいのユーザーの一連の操作が処理されるのか?
主として、一つの処理中で時間をかけて複数の アクションを連続実行するようなリクエスト(例えばユーザーの、ログイン→閲覧→登録→ログアウト等の一連の連続処理)についてのシ ステムの一定時間内の通算処理量を計測したい場合に指標とします。
ただし、この方法は、テスト設計時にどのくらいの量の負 荷を掛ければ良いかという予測をしなければならず、この予測が難しいために、代わりに以下のピーク時の処理量に着目したテストを行 う手法が一般的です。
* ピーク時の処理量
Webピーク時の処理量は、秒間や分間当りのページ処理数、 リクエスト処理数(ヒット数)等でテスト実施結果の中で最も高かった値や平均値を得て、システム処理能力の上限を 把握するための指 標です。
比較的短時間の範囲の値を指標とするため、数十分程度のテスト実施時間があれば、その中で少しずつ負荷の量を漸増させ て行き、処理能力が限界になるポイントまで試すことで、一回の試験で処理能力上限を割り出すことが可能という利点があります。
一方、ユーザートランザクションの一連の処理に数分程度かかるようなケースでは、単純に短いサイクルで負荷の量を増加させ てゆくと、前回に実行した一連の処理が終わり切らず、最も重い処理を実行する前に、次の増加のタイミングに入ってしまい、結果的に その瞬間だけ実際よりも重い負荷が掛かってしまって、正確な計測にならない場合があります。
その為、ピーク時の処理量を漸 増方式で計測する場合には、トランザクションの実行インターバルの長さには予め注意を払っておく必要があります。テスト結果の評価 判断方法としては、要件定義で定められている時間当たりの想定利用者数に対して、何パーセントの処理能力を実際にシステムが持って いるかを報告し、要求数値に足りない場合にはチューニング等の工程に差し戻させる等のアクションを起こすことになります。
性能テスト - 応答時間
このテストは、通常時や高負 荷時のシステムの応答性能(レスポンス応答の所要時間)に着目するテストです。
一般的にWebシステムでは8秒ルール等の利用ユ ーザーがストレス無く使用できるレスポンスの受容範囲が要求仕様上で定義されています。この応答性能が所定範囲内であるかを確認し 、また大量アクセスがあった場合に、どの時点で応答時間が所定範囲を逸脱するかを把握することが目的となります。
実際の運 用時の平均ユーザーアクセス量を想定した負荷を掛けて、その際の各ページやトランザクションの応答時間を把握する平常時応答性能と 、試験時に負荷量を漸増させて応答時間が所定範囲を逸脱するポイントに辿り着くまで計測し、その限界点の負荷量を把握する性能逸脱 限界の把握の2種類のアプローチの両方を実施してシステムの応答性能の実態を把握します。
目標値となる応答性能の定義方法に ついては、利用ユーザーがストレスを感じない速度という、個々人の主観に基づいた基準であるために判断が難しく、そのために実際に システムを高負荷状態にして、ユーザー体感テストを行ってその感想を基に判断するという方法も存在します。
一般的には、表 示系の画面では5~8秒以内、更新処理系は8~10秒以内の範囲で要件として指定することが多いです。
限界テスト
限界テストとは、仮に想定以上の処理限界に近いアクセスが発生した場合に、例え応 答時間遅延や処理能力低下が起きたとしてもシステムが正常に動作出来るのかどうかを確認する目的の試験です。
正常な限界時 の動作としては、例えば「アクセスが込み合っております。暫くお待ちください」といったメッセージが限界時に表示され、ユーザーが 入力中のデータも、正常に保持または破棄されるというように、適切に処理能力を超えるリクエストを誘導出来ることです。
一 方、以下の例は限界時の振る舞いとしては問題があります。
* 画面にException等のシステム内部のエラーメッセ ージが表示される
* 振り分け処理が正常に機能せず一部の機器に処理が偏る
* ユーザーが入力したデータに間違いが生じたり 失われたりする
* 負荷が正常に戻った後も応答速度や処理能力に問題が残る
* システムダウン、アプリケーションクラッシュ の発生
これらの障害はユーザーアクセスをエミュレートした高負荷状態を再現しなければ発見出来ないため、結 合テスト段階では見落としがちであり、限界テストは不可欠です。
耐久テスト
性能テスト、限界テスト等で問題が無かったシステムでも、思わぬ所で高負荷での長期間運用時に問題が発生して しまう場合があります。以下のその問題例を挙げます。
* 微量のメモリリークを起こすプロセスがあり、長期間の 大量処理の結果、リーク量が顕著になりメモリ資源を圧迫しだした。
* セッションタイムアウトの設定値を間違えており、セッ ション情報が大量に残り、メモリやディスク資源を圧迫してしまった。
* セッション情報を管理するデータベーステーブルが肥 大化し、このテーブルの更新処理に異常に時間がかかるようになった。
* ログにローテートや定期削除を設定してあったが、想 定以上の多量のログが蓄積されディスク資源を圧迫しシステムが不安定になった。
* ヒープやトランザクションログ開放が頻繁 に行われることになり、CPUやI/Oに掛かる負担が極端に増えて、アプリケーションの動作に支障をきたすようになった。
これら、通常のテスト時には気付くことが難しい問題は、実際に長期間の高負荷運転を行い、その際にシステムリ ソース監視を行って異常値を検出するような耐久テストを行わない限り、発見することが出来ない性質の問題です。
問題発見→ 修正→再試験 というサイクルを繰り返すことで、かなり時間を必要とすることになりますが、事前のテスト計画の策定時に是非含めてお くようにしましょう。
テスト目的の組み合わせ
上述の各テストアプロー チは、必ずしも完全に別々に実施する必要性は無く、状況に応じて組み合わせて実施することが可能です。
例えば Oracle Load Testing の場合、テスト中やテスト前の負荷量の漸増設定や、テスト実行中の処理性能、応答性能の変化の計測、またサーバーリソース のリアルタイム把握等が可能ですので、性能テスト、限界テストを一度の試験で容易に検証することができます。ただし、同時に実施す る際にも、各アプローチ毎の目的や指標や定義を明確にし、それぞれ整合性が取れるかを確認することは必要です。
9. I/Oボトルネックの計測 に進む