UJP - 技術情報

負荷テスト

　このドキュメントでは，負荷テストについて考えてみる．

開発フェーズの中で，“テスト”と呼ばれる物はいくつかある．
単体テスト，連結テスト，システムテスト，負荷テスト(Load Test：ストレステスト)．
今回はこの負荷テストに焦点をあてて考えてみる．
単体テスト等の他のテストでは，そのシステムが「要求仕様（機能）を満たしているか」という観点でテストを行うが，要求を満たせていても動作が遅いシステムでは，実質利用できない．
Webのシステムの中では「３秒ルール」等というユーザが待つ事が出来る応答時間が示されていたりする．
負荷テストでは「レスポンス」に関する要求仕様を満たせているかを確認する方法であったり，「要求仕様を満たしているが非効率な処理」というバグを発見するなどが目的となる．
まとめると，負荷テストは，次のように定義できる
- どれくらいのユーザアクセスに耐えられるのか．(限界テスト)
- 想定ユーザ数で利用した場合のレスポンスタイムの計測．（サービスレベル保証）

対象をWebシステムとして限定した場合，時として次のような問題が頻発する．
- 不特定多数のユーザを相手にしており，どの程度のアクセス数があるかわからない．
- ある一定以上のアクセスがあった場合にWebサーバを増やせば良いのか指標が不明．
- 問題が起きてもどこがボトルネックがあるかわからない．
「負荷テスト」というキーワードだけだと，「テスト」と付いているので「非効率処理(バグ)の排除」が目的と採られがちだが，そのような負荷過多になった場合の増設要望のベース資料としての利用や，「同時100アクセスまで対応可能」等をサービスレベル保証として行う為の契約問題の対処としても使う事が可能である．

むかし，そんなに昔でもないが60億円かけて400人が使う業務システムの開発を行った事があった．
そこで最終的に行われていた負荷テストでは，休日に部門ユーザの50人ほどに出社してもらって同時に通常業務のシミュレーションをやりながら，それを「負荷テスト」として扱うというやり方である．
大きい会社であれば50人くらいは人間を用意するのは，困難ではあるものの不可能ではない．
しかし，昨今のWebシステムで「同時1000ユーザ」のシステムをテストする際に，人海戦術では破綻してしまう．
負荷テストツールを使うと，人海戦術を使わず，ユーザ数を飛躍的増やす事がででき，数台のPCを使うだけで擬似的に1000ユーザのアクセスを再現するという事も可能である．

とある会社の開発プロセスでは，システムのカットオーバ（サービスイン）前に負荷テストを行う事が必須となっていた．
このようにフェーズに組み込まれると，どちらかというと負荷テストは「障壁」であってそれをOKにするためだけの視点になりがちである．
「障壁」という扱いでは，「レスポンスタイムの実績」を示すだけとなってしまい，肝心な部分のテストをあえて外してしまう傾向が出てこないと言い切れない状態になる．
そもそも，そういう使い方が間違っており，次のような利用方法が有効的であり，目標として取り組むべきである．
- 初期開発時から気軽に利用可能．
- どんな改修のタイミングでもパフォーマンス劣化が即座に判る．
- 開発の最終段階では，それまでに作成したテスト定義をつなぎ合わせる事で連結テストにもなる．
- 本番稼働後は，パフォーマンス管理として定期的に実行し，データ増加などの，いわば経年劣化後の性能を確認する．
貯蓄性と再利用を念頭において利用していく事によって，より効率の良いシステムの実現が可能となる．
このような利用方法を実現するには，ツールの導入が必要である．