.jpg)
← 自主トレシリーズ トップへ
.jpg) | 比較的最終工程で実施される Web 負荷テスト |
一般的にテストの重要性はソフトウェア開発に携わる技術者にとっては常識と言ってよいと思いますが、特に負荷試験に関しては失敗しているプロジェクトほ ど、遅い時期に実施してそこでパフォーマンス面の課題が発覚し、顔が青くなる事態に遭遇したという話を多く聞きます。この章ではマイクロソフトが現在提供 している負荷試験ツールについて解説するとともにその特徴と考慮すべき観点について整理していきます。
.jpg) | マイクロソフトと負荷試験ツール |
マイクロソフトは今までいくつかの機能は異なるものの、ツールを提供してきています。ここでは特に Web アプリケーションに絞って記載しますが、WAST (Web Application Stress Tool、技術情報 313559、通称 "Homer!") あるいは ACT (Application Center Test、Visual Studio 2003 付属、技術情報 307492) が代表例でしょう。WAST の後継が最初に解説する WCAT と言えますし、ACT が発展してより本格的な負荷試験が可能になったのが Visual Studio Team System 2008 に付属の単体テストや負荷テストの機能と言えると思います。
.jpg) | WCAT (Web Capacity Analysis Tool) |
WCAT は無償で利用できるコマンドライン ツールと Windows Scripting の組合せで利用できる大変便利なツールです。このツールは IIS の開発のためにも利用されていますが、そもそも Windows 開発チームの全般的な Web ワークロードのパフォーマンス評価を行うためにパフォーマンスを担当しているチームが開発、改良していっているものです。
WCAT は現在大きく二つのバージョンが提供されています。一つは IIS 6.0 Resource Kit Tools に含まれているもので、ダウンロードセンターのこのページ (英語) から入手できます。こちらに含まれているのはバージョン 5.2 になります。もう一方は IIS.NET から直接入手できるバージョン 6.3 のものでこちらは x86 (32 ビット) 環境用 (英語) と x64 (64 ビット) 環境用 (英語) の 2 つがあります。
この章では v6.3 の方を使った説明をします。v5.2 に比べるとシナリオ ファイルの記述方法が異なる、あるいは 結果出力の XML レポートが出ないなどの差があります。可能であれば v6.3 の方を使いましょう。
実行が成功すると下記の図のように完了します。サンプルのバッチ (構築手順参照) では Pause を入れているので「何かキーを押してください」と出ています。
WCAT の利用シナリオは構造が簡単なだけに組合せによって下図のように柔軟に負荷を生成することが可能です。
「一台で全部」のシナリオでは負荷をかけるコントローラもクライアントも負荷をかける対象のマシン上で実行しているので「負荷をかける負荷」がその マシン上で発生してしまうために、相対的には役に立つデータがとれますが、絶対値としては「負荷をかける負荷」をどのように加算するかを試算しないといけ なくなります。一方で、WCAT n 台で高負荷を発生させるシナリオを使えば、かなり本当の負荷に近い状況を作り出すことが可能です。
負荷が終了すると、バージョン 6.3 では XML ファイル形式でテスト結果レポートを作成してくれますので、環境や負荷の相違によって、この XML ファイルを比較する方法論がよいでしょう。
さて、ではどういう点が不足しているのでマイクロソフトは Visual Studio に負荷テスト機能を作ったのでしょうか?負荷試験の肝は如何に本物に近いトランザクションを Web サーバーにぶつけることができるかというのが大きな要素になっています。WCAT では負荷の掛け方はあくまでも XML 形式のテキスト ファイルで記述され、そのファイルを作成する機能はついていません。従って、全部手で記述する必要があり、どのページをアクセスするかさえもそれぞれ URL を XML のセクションで書いていかないといけません。実は Log Parser というツールを使用して IIS ログから UBR ファイルを作成する方法が無いわけではありません。これに挑戦する人はぜひやってみましょう。Microsoft.com チームはやっているようです。一番下にリンクを添付しておきます。
WCAT は "Capacity Analysis" という名前の CA の部分からもわかるように、キャパシティを判断する際にお使いいただくのが便利だと言えます。つまり、テスト環境のメーカー A、スペック 乙のマシン 2 台が本番環境で想定しているメーカー B、スペック 甲の 4 台のマシンが処理できる性能で言うと何分の一なのかを概算する際に大いに役に立ちます。逆に言うと、「将来、例えば次の 2 年間くらいの利用者増加の想定している割合を加味したマシン スペックと台数は?」というものすごい難問に対して大きなベースになる資料を提供してくれるわけです。
基本的に WCAT でできることは次に説明する Visual Studio でできると考えてください。ただコマンドで簡易にできる点や無償である点は WCAT が優位なので、どういうシチュエーションで使うといいかという観点でじっくり吟味しましょう。
.jpg) | Visual Studio 2008 ロード テスト |
Visual Studio 2008 のロード テスト (負荷テスト) の機能は、Visual Studio Team System 2008 の Test Edition と Team Suite で使用できます。
Visual Studio 2008 ロード テストは、以下の特徴をもっています。
- 負荷 (ロード) をかける元となるトランザクションをテストとして作成し、このトランザクションに対して負荷をかけます。
今回は、Web のアプリケーションですので、「Web テスト」という単一のトランザクションを作成しますが、例えば、作成した単体テストに対して負荷テストをかける、といったことなども容易に可能となります。 - 負荷をかける際のさまざまなシナリオ (例: 想定するユーザ数、想定するネットワークの帯域、などさまざま) を設定していきます。設定した内容は、無論、あとから変更をおこなうことも可能です。
- 取得するカウンタ (例: 1 秒あたりのリクエスト数、 1 秒あたりのエラー数、など) を指定しますが、ここで、リモートのマシン上のカウンタを収集することも可能です。
WCAT と比較した最大の特徴は、これらの多くの作業がウィザード形式などのユーザ インタフェースによりビジュアルに設定できることです。このため、設定のための複雑なツールの知識や、Windows のパフォーマンス カウンタに関する細かな知識などを有していなくても、簡単にテストをおこなうことができます。
このことは、単に負荷テストの作業工数が短縮 できるということ以上に、Team Suite を使用すれば開発・プログラミングの初期段階から、特別な準備を実施することなくまめにロード テストを実施しておくことができるという「開発業務」を進める上での大きなインパクトをもたらします。
例えばデータベース処理におけるデッ ドロックなど、ロード テストの段階においても、複数の要因が複雑に絡み合って 1 つの現象を発生させ、開発の工程が進むにつれて問題が複雑化していく傾向があります。Visual Studio Team System 2008 のロード テストを使用すると、こうした要因のうちの基本的なものは開発の前工程であらかじめ排除をしておき、開発の後工程では、統合的なパフォーマンスの最終テス トなど、そのフェーズに相応しい問題に絞りこんで検証やテストをおこなっていくことができます。
.jpg) | Webcast |
.jpg) | 縮小版 Podcast (ダウンロード版) |
← 自主トレシリーズ トップへ