Webサイト構築・運用のキホン！ Web負荷テストの押さえるべきポイントとは

　Webがアプリケーション開発の基盤として利用されるようになって以来、われわれは社内システムあるいはインターネット上のサービスとしてそれらを利用している。

　しかし、サーバやネットワーク機器のパフォーマンスが年々向上しているにもかかわらず、エンドユーザーが感じるパフォーマンスが、さほど向上していないように感じている人は多いのではないだろうか。それどころかパフォーマンスの問題から、エラーメッセージが出ていないにもかかわらず空白ページが現れたり、コンテンツが途中までしか表示されないといったトラブルを経験することは、むしろ増えてきている。

　米調査会社Business Internet Group of SanFranciscoの調査（2002年1月〜4月調査、調査対象315サイト）によると、驚くべきことに10サイトに6サイトの割合で、空白ページの発生やコンテンツエラー、File not Found、Internal server errorをエンドユーザーに返す問題を抱えているという。おそらくインターネットユーザーの多くが、この現象が決して少なくないことに気付いているはずだ。Webサイトを運用する企業にとって、これは決して他人事ではない。

　現代のWebアプリケーションは、さまざまな役割が数多くのサーバに割り振られ、ロードバランサやSSLアクセラレータなどのネットワークアプライアンスからバックエンドまで、複数のレイヤに分かれる複雑な構造になってきている。

　もちろん、開発者は十分にパフォーマンスに留意し、担当する個々のモジュールを高性能に作ろうとする。しかしシステム全体が組み上がったとき、どれだけのパフォーマンスが出るかを把握している担当者はいるのだろうか？ ネットワークを通じ、複雑に結びついた分散処理のシステムにおいて、だれがパフォーマンスを保証できるというのだろう？ 仮にパフォーマンス保証をしているとして、その保証のための負荷テストを行っているのか？ また、きちんと負荷テストを行っていても、ボトルネックを見つけられていない場合も少なくない。では、なぜパフォーマンスの問題が起こるのだろうか？

　このようなさまざまなWebシステムへの問いに対して、負荷テストツールベンダであるエンピレックスの山岡英明副社長に伺ってみたところ「現状、Webのシステムは複雑すぎる。複雑なのだから問題が起きて当然。そのテストには複雑な分だけの時間を掛けなければ、顧客が求めるレスポンスは実現できない」と話す。

　山岡氏が指摘する問題のうち、根本的な対策が必要な点は2つある。1つは“負荷テストが行われていない”現状。もう1つは“負荷テストの行い方が適切ではない”ことが多い点だ。また同氏は、「多くの場合、テストはシステムが完成してから行う。機能テストはシステムがそろわなければ、その動作をチェックできないためだ。しかし負荷テストは違う。機能モジュールごとに、ボトルネックとなり得るクリティカルなパスを開発者自身がテストできる。その点が誤解されていることが多い」と負荷テスト実施のタイミングに関する問題点を指摘する。

「現状、Webのシステムは複雑であるため問題が起きて当然。そのテストには複雑な分だけの時間を掛けなければ、顧客が求めるレスポンスは実現できない」と語るエンピレックス 山岡英明副社長

　ところが実際には、テスト工数は開発の最終段階にしか計上されていないことが多いのが実情。システムが組み上がってからパフォーマンス的に問題が明らかになると、問題の発生個所を探すのは困難だ。ネットワーク上にボトルネックがあるのか、特定のアプリケーションサーバに問題があるのか、それともプログラムロジックそのものに問題があるのか。複雑に絡み合ったシステムの中で、ボトルネックを把握するのは難しい。対処療法的に数カ所を修正しても、問題の本質が別なところにあることも珍しくない。

　しかし、あらかじめ機能モジュールごとに負荷テストを行い、クリティカルパスを潰しておけば、システムが完全に組み上がってからパフォーマンスチューニングを行うよりも、はるかに低コストで問題に対応できる。機能モジュールごとのチューニングが終わっているため、各モジュールの連携にかかわる部分だけにフォーカスを絞って調整できるからだ。開発とテストの期間をオーバーラップさせることも可能なため、トータルの開発期間も短縮可能だ。

　さらには「十分、パフォーマンスに留意した設計と機器構成にしている」という運用サイドからの自信により、負荷テストを行う十分な時間が取られておらず、事実上“負荷テストなし”、あるいはパフォーマンス問題発生の可能性があるにもかかわらず、そのまま本番運用がスタートしてしまうケースも少なくないと山岡氏は現状を語る。

失敗組	成功組
図1 負荷テストの必要性（出典：米Newport Group、1999年2月〜3月調査、回答数117）

　米調査会社Newport Groupの報告によれば、パフォーマンス上の問題が発生したサイト、発生しなかったサイトを比較した場合、負荷テスト計画の違いによって、成功組と失敗組がきれいに分かれている（図1）。負荷テストを行わなかったサイトのほとんどが、システムの立ち上げに失敗しているのに対し、仕様決定段階あるいは開発の初期段階から負荷テストを計画的に行ったサイトのほとんどが立ち上げに失敗していない。

　問題をさらに複雑にしているのは、開発終盤で負荷テストを行っているにもかかわらず、立ち上げに失敗しているケースが目立つことである。これは問題を予測しながらも、納期問題から無理に本番運用をスタートさせたサイトがある、という理由だけでは説明できない。

　実はここには、もう1つの問題が潜んでいる。それは、負荷テストが正しく行われていない可能性だ。テストツールを用い、予想されるトラフィックよりも多い負荷を掛けながら、本番ではその何分の一かの負荷で簡単にシステムダウン、あるいは空白ページの送出といったトラブルを起こすのである。それはなぜなのか？

　設計上の最大値を超えるテストを行いながら、それでもなおパフォーマンス不足が露呈してしまう理由の多くは、実際のアプリケーション運用を無視した型どおりのテストしか行われていないケースが多いためだ。

　Webアプリケーションの負荷テストといっても、実際には5〜10人程度のテストチームで、一斉に端末から負荷を掛けるテストを行い、その際のシステムの負荷状況をログに取って分析するだけというケースが最も多い。これだけでは、負荷テストにはなり得ないのは明白だが、信じられないことに、その程度のテストがまかり通っているのが現実である。

　もう1つは、オープンソースコミュニティで公開されているフリーのWebアプリケーション負荷テストツールを使う場合だ。この場合は、設定によってある程度細かな負荷シミュレーションのシナリオを作成し、負荷テストらしいことを実行できる。しかし、ボトルネックがあるのか？ といった問題検出の機能がなく、何階層にも分かれた複雑なシステム構成には対応できないといった問題がある。このため、本来行わなければならないテストをすべてこなすことができない。

　最後に独自に自社でテストツールを開発するケースもある。この場合は、開発の手間さえいとわなければ、複雑なテストも実行できるが、経験不足から思わぬ落とし穴にはまる事例が多い。新規で開発されたテストツールは、本当に目的の負荷を生成できているかどうか、あるいは問題を発見できているかどうか、ツール自身がテストされていないからである。これはフリーのテストツールにも共通する問題だ。

　結局、開発期間を短縮し、かつ正しいテストを行うためには、専門のツールを導入することが最も近道となる。世界中で商用のテストツールとして利用されているだけに、ツール自身の信頼性を疑う必要がない。

　では、ここからは前出のエンピレックスが開発したWeb負荷テストツール「e-Load」を例に挙げながら、専門ツールのアドバンテージについて話を進めることにしたい。なお、e-Loadは同社のWebページから機能無制限・期間限定の評価版を入手できる。実際にe-Loadを試用しながら、その違いについて検討してみることを薦める（「e-Load評価版ダウンロード」ページへ）。

●正しい負荷が生成できているか？

　一部の市販ツールを含め、ほとんどの負荷テストツールは、負荷を掛ける仮想ユーザーごとに1セッションの負荷しか掛けない。しかし、ご存じのように実際のWebブラウザは同時に4セッションをリクエストする（Internet Explorerデフォルト設定の場合）。HTTPセッションのリクエストだけをシミュレートし、クッキー処理など実際のWebブラウザが生成するはずのセッションが無視されていることがほとんどだ。

　このため、ツールで200ユーザー同時アクセスの負荷テストを行っているにもかかわらず、e-Loadで60ユーザー程度の負荷を掛けただけで問題を発生させるシステムも多いという。本当の負荷テストを行うためには、本物のWebブラウザと同じ振る舞いをシミュレートできるツールが不可欠なのだ。

●ユーザーサイドの視点でテストできているか？

　サーブレットで動的にWebページの内容を生成している場合、負荷が高くなるとサーブレットの生成するHTMLが不完全なままでクライアント側に送出されることがある（空白ページになる直前の現象）。ところが、ユーザー側の視点でテスト結果を評価できない負荷テストツールを使っていると、この問題を発見できない。なぜなら、このケースではHTTPセッションが正常終了したように振る舞うからだ。

　つまりHTTPセッションが予定どおりのレスポンスで完了したか否かではなく、生成されたページが完全なものかどうかを評価しなければならない。

　e-Loadの場合、コンテンツを自動チェックする機能があり、こうした問題を検出できる。コンテンツ内のキーワードを指定して、ページの完全性をチェックする機能は多くのツールに存在するが、ユーザーがエラー時のシナリオを想定していない場合でも問題を発見できる点が大きな違いだ。ユーザー側の不注意でエラー検出の設定を忘れていた場合でも、正しいテストを行える。

画面1 負荷テスト用のスクリプトをe-Testerで簡単に作成できる（拡大）

　e-Loadではテストシナリオを、実際のWebアプリケーションにユーザーがアクセスすることでスクリプト化するが、そこで入力・操作するフィールドやボタンがページ中に存在しないとエラーを検出する。これが前述の問題に対処できる理由だ。

●テストスクリプトの共用は行えるか？

　アプリケーション開発では、ボタン類や入力フィールドの振る舞い、処理の流れなどを試験する機能テストが重視される傾向が強い。このため、開発初期の段階からシステム設計担当者によって細かなテスト仕様が作られることが多い。機能テストは、そのシナリオに従って行えば、多くの場合、あらゆる操作パスをチェックできる。

　しかし負荷テストツールの多くは、現実のWebブラウザを完全にシミュレートせず、また処理の流れを意識したテストも行わない。現実に即したテストが行われない理由の1つである。

　e-Loadは前述したように、実際のWebアプリケーションをユーザーが操作した過程をスクリプト化し、そのスクリプトに沿って仮想ユーザーからの同時アクセスをシミュレートする。このため、機能テスト仕様で示されているテストパスを用いて負荷テストも実行できるのだ。また、エンピレックスはe-Testerという機能テストツールも提供しており、スクリプトをe-Loadと共用することができる。

　前出のエンピレックス山岡氏は「負荷テストは軽視されがちだが、システムが完成してからの変更は非常にコスト高になるうえ、納期延期の原因にもなる。システム立ち上げの1カ月前に評価するといったギリギリのスケジュールでテストを行うことも少なくないが、その段階では予定どおりに立ち上げられないか、あるいは予定どおりのパフォーマンスを達成できないのを我慢するか。2つに1つの選択になってしまう」と話す。

　エンピレックスの調べでは、パフォーマンスの問題発生個所のうち40％がアプリケーションサーバで、30％がデータベースサーバ。機器交換で対処できるネットワーク機器の問題（ロードバランサやSSLアクセラレータなど）は20％、スケールアウトさせることで対処可能なWebサーバの問題は10％にしか過ぎない。つまり一度問題が発見されれば、70％の確率で、再度、開発、テスト、リリースのプロセスをやり直さなければならない。そうなってからでは遅すぎる、というわけだ。

図2 パフォーマンスの問題個所（出典：米エンピレックス、2002年1月〜4月調査）

　「e-Loadはエンジニアであれば、1〜2日ほど触ってみるだけでだれでも使える。多くのツールは複雑で、習得に時間が掛かり、人事異動でテスト担当者がいなくなると使える人間がいなくなることも多いが、e-Loadはそのようなことがない。まずは評価版をダウンロードし、そして開発中のアプリケーション上で試されることをお薦めしたい」と山岡氏はその手軽さと効果が実感できることの自信を語る。

　実際のe-Loadに触れてみると、開発者だけでなく、エンドユーザーにとっても使えるシンプルな操作性であることがすぐに分かる。エンピレックスではSIerとパートナーシップを結び、企業に対して負荷テストと監視をサービスとして提供するビジネスも展開しているという。開発者もユーザーも、その立場を問わず、無料の評価版を試してみる価値は大きい。まずはダウンロード。そこから始めてみよう。

◇　◇　◇

【負荷テストツール「e-Load」評価版が手に入る！】 ダウンロードはエンピレックスのサイトからどうぞ 評価版ダウンロード