2019/04 追記 : Cloud-based Load Testing は、2020 年 03 月に終了 (retire) 予定です。(代替のソリューションについては “Azure Update : Cloud-based load testing features will be retired on March 31, 2020” を参照してください)

環境 : Visual Studio 2013, Visual Studio Team Services

こんにちは。

これまで Install Maniax として開催されてきたコンテストが、「Tuning Maniax」という新たな形で生まれ変わり、本日より (さきほど) エントリー受付が開始されました !

Tuning Maniax では専用の負荷テスト (Load Test) ツールを使って審査をおこない、Tuning のテクを競います。審査で どんなツールを使うかは内緒ですが、今回は、そんな参加者の方のために、Visual Studio の Load Test を軽く紹介したいと思います。(怪しいツールの売り込みみたいですみません。。。とにかく便利ですので)
私も入社以来、セミナー (パフォーマンス系のデモなど) で使いまくっていますが、軽く Tuning の効果を確認する程度なら、ほとんど準備は不要です。

ご注意いただきたい点として、Visual Studio Ultimate 2013 が必要ですが、Visual Studio Ultimate の試用版もあるので、これから試したい方も気軽にお試しください。

まずは、普通に Load Test してみる

まずは、知らない方のために、Visual Studio Load Test そのものについて簡単に紹介します。

概念は単純で、まず、1 回だけの Web Performance Test (HTTP テスト) を作成して、この作成した Web Test の Load Test を作成し、実行するという手順です。

ということで、まず、Web Performance Test を作成します。

Visual Studio でプロジェクトを新規作成します。[テスト] (Test) – [Web パフォーマンスとロード テストのプロジェクト] (Web Performance and Load Test Project) を選択するとテスト用のプロジェクトが作成できます。
作成されたプロジェクトを右クリックして、[追加] (Add) – [Web パフォーマンス テスト] (Web Performance Test) を選択すると、Web テストが追加され、以下の「Web テスト レコーダー」と呼ばれるペインの表示された Internet Explorer が起動します。
このブラウザーで、今回テストしたい Web サイトにアクセスすると、下図の通り、HTTP の情報がトレースされて左ペインに表示されます。

注意 : Internet Explorer 上にペイン (Test Helper) が表示されない場合
ペイン (Test Helper) が表示されない場合は、Internet Explorer のアドオンの管理画面で、下図の Microsoft Web Test Recorder や Web Test Recorder のアドオンが有効になっていることを確認してください。IE が使っていないアドオンを無効にしてくれたりするので、要注意です。

一連の HTTP 要求が終わったら、上図の [停止] ボタンを押してテスト (HTTP トレース) を終了します。これだけで、HTTP の Request / Response がトレースされて、Web Performance Test の作成が完了します。

ここで、普通なら Web Performance Test を実行して試したいところですが、今回は Load Test をするために作っただけなので省略します。

捕捉 : 例えば、http://testdomain.net/?q=… などの各種パラメーターがある場合もちゃんと抽出され、このパラメーターにデータベースなどから取得したデータを設定してテストなどが可能です。Web Performance Test も、いろいろ応用的なことができるので、是非試してみてください。

つぎに、作成した Web Performance Test を元に目的の Load Test を作成します。
同様に、プロジェクトを右クリックして、[追加] (Add) – [ロード テスト] (Load Test) を選択すると、テスト作成のためのウィザードが表示されます。ウィザードの設定が面倒なら、後述の Test Mix の設定を除き、すべて既定値のまま [OK] ボタンを押して進めて構いません。Load Test が完成してテスト可能になるので、あとから細かな設定を変更して Test 内容を変えれば良いでしょう。

念のため、以下に、このウィザードについて、いくつか重要な設定だけピックアップして解説しましょう。(すみません、簡単に説明して終わるつもりでしたが、だんだん説明が長くなってきました。やはり、ここはちゃんと説明せねば。。。)

まずは、Load Pattern の設定です。例えば、「常時 100 ユーザーのアクセス状態」、「20 秒間の間に 250 ユーザーのアクセスの繰り返し」など、いわゆる Load のかけ方を設定できます。

つぎに Test Mix の設定です。この設定は必ずおこなってください。
今回は、上述の通り、Web パフォーマンス テストを 1 つしか作成していませんが、本来は、異なるテストを複数作成して、それらを一定の割合で Mix できます。例えば、Web テスト 1 を 30 %、Web テスト 2 を 70 % といった具合に設定すると、設定した割合で負荷をかけてくれます。

つぎに Browser Mix の設定です。
例えば、Responsive な処理を埋め込んだサイトの場合、下図の Browser Mix を指定して、iPhone 版の Safari が 50 %、PC 上の Internet Explorer 9 が 50 % など、User Agent の割合を決めて負荷をかけることができます。

さいごに、このテストを実行する時間を指定します。(既定では 10 分間です。)
途中で止めることもできるので、充分な時間を設定しておくと良いでしょう。

ウィザードを完了して Load Test を作成したら、下図左上の [ロードテストの実行] アイコン (下図) をクリックして Load Test を開始できます。

Load Test が始まると実行状況がグラフで表示されるので、いろいろとインジケーターを確認して遊んでみてください。
ちなみに、超基本的な情報として、処理された Request (Page) の数や、発生している「エラー」の数は、いつも見ておくと良いでしょう。(下図の赤の囲みです。) エラーページの内容なども、もちろん確認できます。

テストの目的に応じて、特定のインジケーターに絞って Watch することもできます。
例えば、下図は、ページの平均応答時間 (sec / page) を表示しています。下図では、現在の応答時間が 10.0 sec / page で、ここまでの最小値が 10.0 sec / page、最大値が 10.3 sec / page であることを意味しています。つまり、このページは、相当安定したページであることがわかります。グラフも 10 秒ごとに規則的に応答しているのが確認できますね。

例えば、「ASP.NET MVC で非同期 (Async) がなぜ重要なのか」で解説したように、下記のような Non-Blocking Code (良いコード) と Blocking Code (悪いコード) のサンプルを作って試してみてください。(下記は C# のサンプルです。) きっと、あまりの結果の違いに驚くことでしょう。
このように、インスタンス サイズやインスタンス数などの いわゆる「お金をかけて速くする」だけが Tuning ではありません。(Microsoft としては、Azure のリソースをどんどん使ってもらえるのは嬉しいですが。。。)
スマートな Tuning ポイントもきっと沢山あると思いますので、是非、そうしたポイントを探して賢く賞品を Get してください !

// Good codepublic async Task<ActionResult> Test1(){  await Task.Delay(10000);  return View();}// Bad codepublic ActionResult Test2(){  Thread.Sleep(10000);  return View();}

なお、上記では、ブラウザーのヘルパー (プラグイン) を使って HTTP をキャプチャーすることで Web Performance Test を作成しましたが、Unit Test (単体テスト) を作成して、その Load Test をおこなうこともできるので、SOAP の WCF サービスなどブラウザーでトレースが難しい Request も負荷テスト可能です。

そして、Cloud-Based Load Test (Cloud-based Load Testing Service)

と、ここまでは、もう 10 年ひと昔前からある普通の Load Test ですが、つい先日の BUILD で正式リリースした Visual Studio Team Services を使うと、今風な、すばらしいオプションが使えるので紹介します。(これも、もうセミナーなどで何度か見せてますが、実は 発表されてから随分たっています …)

まず、上記で紹介した Visual Studio Load Test ですが、その内部では、ローカルマシン上の Test Agent が使用されており、この Agent を Test Controller が制御することでテストの実行や収集をおこなっています。
そうした構成を前提に、現実に負荷テストを使っていただくとわかりますが、実は、いざ負荷テストをやろうとすると、環境上の配慮しなければならない さまざまな問題が出てきます。

例えば、初心者が陥りやすい点として、サーバー側のスペックの問題があります。
通常、皆さんは Windows Client を使用されていると思いますが (わざわざ Windows Server 上で仕事をしている人は一部の物好きな方だけだと思いますが)、例えば、Windows Client 上に作ったアプリケーションを配置して Load Test をおこなうと、Windows Client の接続数の制限 (同時 10 クライアントまで) から、負荷を増やしても接続を拒否されてしまいます。つまり、on-premise 環境 (自社設置型環境) をお使いの方は、開発途中でも、本番さながらに、ちゃんと Windows Server を準備する必要があるわけです。(もちろん、前述のようなアーキテクチャなので Linux 上のサーバーでもテストできます。)

では、クラウドが超簡単に使えるようになった現在、ホスト先としてクラウド環境を使って検証すれば問題解決です。Azure Web Sites を使えば、10 秒もあれば配置できてしまいますね。
しかし、今度は また別の問題にぶちあたることでしょう。Azure Web Sites の無料版のように Limit (Quota) が設定されているような初歩的なミスも考えられますが、この他にも環境上の頭の痛い問題が幾つかあるのです。

例えば、皆さんが会社から Load Test をおこなう時を想像してみてください。通常、企業内から外にアクセスをおこなう際は、何らかの Proxy を経由します。この構成で負荷テストをおこなうと、きっと、会社の Proxy がボトルネックとなって高負荷なテストは難しいでしょう。(場合によっては、スパム扱いされて切断されるかもしれません。) 自分 Wi-Fi などでつないでいる方も同じです。その接続ポイントがボトルネックとなってテストになりません。(私もセミナー巡業していた頃には、よく会場の環境の問題でデモを断念したことがあります。。。)

こうした問題を避けるために、ある程度の規模以上の場合にはテスト環境もクラウド上に構成しなければなりませんが、想像していただけるとおわかりの通り、そう簡単な話ではありません。Visual Studio はローカルにあるわけですから、Load Agent と Load Controller と Visual Studio の 3 種類のノードの構成を検討する必要が出てきます。
大規模システムなど、現実のシナリオを想定した本格的なテストでは、on-premise の場合であっても、あえて現実的な Load を生成するために、Test Agent を異なる環境にセットアップしてテストする場合もあります。

さて、前置きが超長くなりましたが (私の経験談は不要でしたね。。。)、最新の Visual Studio では、こうした Pain を克服する新しいオプションとして、Visual Studio Team Services を使用した Cloud-Based Load Test なるものが提供されています !
この Cloud-based Load Test は上述の Visual Studio Load Test のアーキテクチャとは異なり、あらかじめクラウド上 (Azure 上) に用意された多数の Virtual Machine とその上の Test Agent が使用されます。Test Controller の配置と接続など、面倒なセットアップも不要です。(すべては、あらかじめ用意されています。)
まさに、Load Test as a Service (LTaaS) ですね ! (注意 : こんな用語はありません)

どれくらい簡単かみてみましょう。

まず、Visual Studio Team Services にサインアップをおこない、上記の Load Test をおこなった Visual Studio で Visual Studio Team Services に接続します。(Visual Studio の [チーム] – [Team Foundation Server への接続] メニューで接続できます。)

注意 : お使いの Visual Studio で、既に以前の Team Foundation Services の頃に接続済みの場合には、いったん切断してから接続しなおしてください。そのまま使用するとテストに失敗します。

つぎに、ソリューション エクスプローラーから、上記の Load Test プロジェクトに入っている Load.testsettings をダブルクリックして設定画面を開きます。
そして、下図の通り、[Run test using Visual Studio Online] を選択します。これだけです !

あとは、先ほどと同じアイコンをクリックしてテストを実行 (開始) します。
実行中は、下図のように簡単な状況のレポートが表示されます。(アーキテクチャを想像していただくとわかりますが、テスト実行中はローカル マシンのときのようにすべての診断結果がリアルタイムで見えるわけではないので、あくまでも簡易的なレポートになります。)

テストが終わったら、下図の [レポートのダウンロード] (Download report) を選択して表示することで、上述の on-premise のときと同じ細かなインジケーターを確認できます。

下図の通り、前述の Load Test のときと同じ UI が表示され、細かくトレース情報を確認できます。

詳細説明は省略しますが、いくつかの細かな設定も可能です。
例えば、下図のように実行設定のプロパティを使って Visual Studio Team Services の Agent Core の数も指定できます。(0 の場合は「auto selection」になります。)

この他に、Azure Virtual Machine では、Visual Studio Team Services の「Application Insight」と呼ばれるものを使用して Application の実行状態も監視できます。最新の Application Insights ではリアルタイム モニタリングも可能であり、つい先日出たばかりの Visual Studio 2013 Update 2 RC (← リリース候補版です) を使うと、前述の Cloud-based Load Test と Application Insights を組み合わせたモニタリングもできます。(手順詳細は省略します。「Channel9 Getting Started with cloud based load testing and Application Insights」が参考になります。)

ということで、なかなか、こういう良い教材もめったにないと思いますので、この機会に、こうした監視と性能評価を使って勉強してみては如何でしょうか。(本番環境で勉強するというわけにはいかないので。)

あれやこれやと関連技術を紹介していたら、すっかり長い紹介になってしまいました。。。(すみません)

※ 変更履歴

2016/07  Visual Studio Online から Visual Studio Team Services に名称変更