見せてもらおうか、占有インスタンスの性能というものを！！ ～ クラウドアプリもロードテスト♪

本 Blog は “Visual Studio Advent Calendar 2012” の８日目の記事として、知られているような気もするけど、使われていない気もしている Visual Studio のロードテスト機能を紹介する記事です。

 

ということで、さっそくはじめましょう（意外と長くなっちゃた）。

 

■■■ お品書き ■■■

(1) Web を最速で立ち上げる “Windows Azure Web サイト”

(2) Visual Studio におけるロードテストの手順概要

(3) Web パフォーマンステストの作成とカスタマイズ

(4) 複数シナリオの用意

(5) ロードテストの実施

(6) Windows Azure Web サイトのスケールの調整

(7) ロードテスト機能の利用権に関して

 

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(1) Web を最速で立ち上げる “Windows Azure Web サイト”

 

さて、タイトルに ”占有インスタンス” と書いていますが、これが何かと問われたら♪、 Windows Azure の新機能 “Web サイト” におけるコンピューティング パワーの使用 “サイズ” のことです。

 

Windows Azure の “Web サイト” においては、利用形態として①無料、②共有（有償）、③占有（有償）、の３パターンがありますが、②の共有での利用が、１時間あたりおよそ ¥1.75 円、ということで、コンピューティング サービスにおけるサイズでいうところの eXtra Small (XS) にあたり、③の占有では Small(S)、Medium(M)、Large(L) の３種類が用意されています。。

今回は、この占有インスタンスでの処理がどの程度の負荷に耐えられるかを Visual Studio のロードテスト（負荷テスト）機能を使って確認したいと思います。

 

 

 

ということで、まずは、Windows Azure の管理ポータルへアクセスし、新規作成で、Web サイトの作成を行いましょう！（※）

 

「最速」 立ち上げをめざし、今回はギャラリーから Web サイトの作成を行います。

 

 

 

今回は、ASP.NET で作成された CMS (コンテンツ管理システム）の Orchard を利用してみます。

 

ウィザードではURL の一部となる Web サイトの名前を設定します。今回は “Advent” という名前を設定しています。これで https://advent.azurewebsites.net/ に Web サイトが作成されることになります。

 

 

入力が終わると、あっというまに、作成と Windows Azure データセンターへのデプロイが開始されます。

 

 

ちなみに “Web サイト” は新規作成時には、”無料” のモードで作成が行われます。

 

 

作成が終われば、先ほど指定したURL(https://advent.azurewebsites.net/ など）にアクセスしてみてください。

Orchard の初期設定画面が表示されるので、さっくっと入力します（今回は Recipe で “Blog” を選択しています）。

 

 

 

設定が終わると、以下のように新しい Blog が立ち上がります。

 

 

 

ということで、あっ、というまに Blog サイトが立ち上がりました（しかもここまでの設定内容であれば無料！）。

 

 

さて、このあとのテストのことを考えて、２つほど作業を行いましょう。サイト下部にある “Dashboard” をクリックして、管理者モードでサイトの設定を行います。

 

まず一つ目。コメントを許可制から、許可なしでコメントできるようにしましょう。

 

 

二つ目はユーザーの追加。

admin の影分身を４体用意しておきます。

 

ということで、以上で Windows Azure 側の準備を一旦終了して、帽子を切り替えて、Visual Studio モードへ！

 

※ もし Windows Azure のアカウントをお持ちでないのであれば、https://aka.ms/Free-Azure を参考に無料の評価版、もしくは MSDN Subscription の契約をお持ちであればその特典でアカウントを作成してみてください！

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(2) Visual Studio におけるロードテストの手順概要

 

さて、さっそうと Visual Studio 2012 を立ち上げ、新規プロジェクト作成を行います。

今回は “Web パフォーマンステストとロードテスト” のプロジェクトテンプレートを利用します。

 

 

 

Visual Studio では、Web に対する単体テスト的な機能として、”Web パフォーマンス テスト” を用意しています。

「単体テスト的な」と書いたのは、”Web パフォーマンス テスト” は単体テスト、としても利用できますし、シナリオテスト、あるいはパフォーマンステストとしても利用できるためです。

 

 

まず、Web パフォーマンステストでは、最初にブラウザーを利用して Web に対する操作の記録を行い、テストを作成することが可能です。

 

地味なボタンですが、ウィンドウの上部に記録用のボタンがあるので、押してみます。

 

おもむろに、IE が立ち上がってきます。初期状態では、特にどの URL にもアクセスしていませんので、Web パフォーマンステストを実施したい URL をアドレスバーに入力し、リターンを押してみます。

 

すると、先ほど作成した Orchard のサイトが表示されます。と、同時に左側に２つの URL が表示されました。

これが、今回指定した URL へのアクセスに伴って、実際に HTTP Request が送られた内容の記録になります。

 

 

 

 

今回はここまでで、記録を「停止」します。

すると、Visual Studio に先ほどの操作履歴をもとにした情報が出てきました。

 

 

 

この作成された Web パフォーマンステストを、単体テストとして利用するには、「検証規則」の機能を利用します。

例えば、「この URL へアクセスした後に表示される Web サイトにおいて表示されるべき文字列」を指定しておきます。

具体的には以下のような感じです。

 

 

では、テストを実施してみます！

 

 

あれ？失敗ですね。

 

そんな時には、「詳細」タブを確認してみてください。

 

なんと、表示されるべきテキストを間違って「こんにちは、Visual Studio 2010」としていました。

最新の Visual Studio は 2012 です！

とんだうっかりですね！（てへぺろ(・ω<)）

 

 

さっくりと検証規則を書き換えます。

 

 

 

テストを実行すると、今度はグリーンになりました！

 

このテスト結果の表示において、実際にサーバーから要求がどのくらいの時間で帰ってきたかの概要が示されます。これを用いると、Web サイトに対する単一アクセスに対する「パフォーマンス」を計測することができます（なので、このテスト機能は 「Web パフォーマンス テスト」 と呼ばれています）。この応答時間を使って、サーバーからの応答時間を閾値にしたテストを行いたい場合は、検証規則として時間のルールを設定することでテストを作成できます。

 

 

また、あるシナリオに基づいた一連の Web サイトの操作を記録し、検証規則を交えつつ正しくページが表示、遷移するかを検証するようにルールを設定することで、シナリオテストとして利用することもできます。

 

 

なお、テストの実行後に「応答」タブをクリックすると、そのテストでサーバーから戻された Response の内容を確認することが可能です（同じく「要求」タブで Request の内容も確認できます）

 

このあたりの情報を利用することで、細かな検証規則を効率的に作成できるようになります。

 

 

さて、このセクションの目的は、ロードテストの手順の概要を示すことです。

いよいよ、ロードテストの作成を行いましょう。

 

 

 

まずは、初回ということで、基本的にはデフォルトの設定値を使ってみたいと思います。

ただ、「ロードパターン」としては、緩やかなユーザーアクセス設定にしておきたいと思います。

 

 

上記の設定で、テスト開始時に仮想ユーザー１人のアクセスから始まり、２０秒ごとに仮想ユーザーが１人追加されていく（なので、６５秒経過した段階で仮想ユーザーは４人になっている）、という設定になります。

また、最大ユーザー数は５人にしています。

 

そして、もう一か所指定が必要な個所として、テストシナリオの追加があります。

ここで先ほど作成した Web パフォーマンステストを指定しましょう。

 

 

準備が終わって、ロードテストが作成されたら、おもむろに「ロードテストの実行」を行います！

 

 

すると、先ほど作成したロードテストの設定にもとづき、Web パフォーマンステストが実施されます。

開始直後の「ページ応答速度」が若干悪い感じですが、そのあとは順調にリクエストをさばいているようです！

 

 

 

と、思っていたら、、、、

４分前後と、７分を過ぎたあたりで大量のエラーが！！！

 

 

ログを確認すると、Orchard の応答ではなく、Azure のほうから、”This site is currently not available” の応答が帰ってきていたようです。

 

 

 

 

とはいえ、サマリーとしては、”Web サイト” 作成後のデフォルトのインスタンス設定（無料の１インスタンス）で、１０分間のうちに 4675 のリクエストを受け、うち 3075 の応答には成功しました。まずまず、でしょうか。

 

 

 

さて、今回はロードテストの概要を示すため、あまり多くのカスタマイズを入れませんでしたが、通常は Web パフォーマンテストにおける各リクエストの間隔や、ロードテストにおける同様の間隔設定を行っていくので、もう少し違った結果になります。

 

より具体的には、今回５人の仮想ユーザーが、１０分間の負荷テストを行っているわけですが、そこでさばいているリクエスト量として 4675 あった、ということは、平均１人１０００リクエストを行っていることになり、すなわちユーザーそれぞれが１分で１００リクエストぐらい Web への操作を実施している数字になるので、これ、ちょっとテスト自体の品質が高くない、といえますよね。

このあたりは次のセクション以降で改善していきたいと思います。

 

 

ということで、ひとまずこのセクションでは、ロードテストの手順の概要を示しました！

 

 

P.S.

ちなみに、Azure の側から見た、このロードテストに伴うリソースの消費量は以下のような感じでした。

 

 

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(3) Web パフォーマンステストの作成とカスタマイズ

さて、実際の Web サイトへのアクセスを考えたときに、

・ 複数ページへのアクセス

・ データの操作(POST リクエスト)

・ 複数ユーザーによる操作

 

といった内容も入れたいところです。

Visual Studio の Web パフォーマンステストによって、この辺りをうまく入れ込んだテストを作ってみましょう。

 

 

Web パフォーマンステストを新規に作成し、先ほどのサイトへのアクセスを開始します。

今回は、

① トップページへのアクセス

② 管理者としてログイン

③ ダッシュボードで新規 Blog エントリを作成し、Publish。

④ 通常のサイト閲覧に戻り、先ほど作成した Blog エントリの詳細情報へアクセス

⑤ コメントとして「いいね！」を残し、ログアウト

 

といったシナリオで操作を行いたいと思います。

 

 

 

操作の記録が終わると、以下のようにテストが作成されました。

 

よく見ると、Blog のエントリを書いていた際にタグ入力でアドバイスが出ていましたが、その部分のリクエストなども残っているようです。

 

 

これによってどのようなテストが可能か、まずは実行してみましょう。。。。。。。

エラーが出ましたね。

 

 

確認すると、Blog のエントリを行う際に、URL の指定がかぶっていたようです。

むむむむ、、、、、

 

 

とはいえ、「複数ページへのアクセス」、「データの操作」には一歩近づいた感じですね！少しづつカスタマイズを行ってテストを良いものにしていきましょう！

 

まず最初は、ログオンの際に用いられる ID 情報を変更してみます。

デフォルトでは、 Web 操作の記録で入力されたデータが入っています。

 

 

今回は、事前に４人の影分身を作っていたので、その分身データも利用したいと思います。

ログインの際に POST リクエストとともに投げられているパラメーターのプロパティを確認し、「値」の部分で、データソースの追加、を指定します。

 

 

立ち上がってきたウィンドウで、適切なデータソースを指定します。

私はあらかじめ Excel で用意しておいた CSV なデータを利用して、データソースの追加を行っています。

 

 

データソースが追加されたら、再びパラメーターのプロパティを確認し、そこで先ほど追加したデータソースの項目へのバインドを行います。

 

 

 

今回は、ユーザー名とパスワードをバインドしました。

 

 

次に、コードを使ってテストのカスタマイズを行うため、「コードの生成」を行います。

 

 

作成されたコードでは、各リクエストが順番に yeild return で返されるコード！、になっています（これ、きれいな書き方なので好きです）。

 

さて、この９番目のリクエストに、Blog エントリにポストするデータがあり、その中でタイトルとURL の指定を行っている箇所がありますので、DateTime.Now な文字列をくっつけて、作成ごとにユニークなタイトル、URL になるようにしておきましょう。

 

 

また、Blog エントリ投稿後にアクセスする Web ページのURLと、コメントを投稿した後に戻ってくる Web ページの URL を同様に変更しましょう。

 

 

 

 

 

 

では、準備が整った気がするので、いよいよ実行、、、、、、、、、、、

なのですが、Web パフォーマンステストでは、残念ながら「テストエクスプローラー」（下図の左側の囲み）でテストを拾ってくれません orz

 

リズムが狂いますが、Web パフォーマンス テストの実行の際は、該当するテストを開いている状態で、メニューを出して、「コード化された Web パフォーマンステストの実行」を指定してください。

 

 

 

こちらもご参考に。

How to: Run a Coded Web Performance Test( https://msdn.microsoft.com/ja-jp/library/hh534291.aspx)

 

 

さて、実際に実行すると失敗した点があるようです。

どうやら、Blog エントリを新規に追加しようとした際の後の戻り URL が異なる、と。

 

 

この部分は、新規作成ごとに異なるURLが割り当てられている感じなので、検証を入れるのが難しいですね。

今回は、ざっくりこの ResponseURL の確認自体を削除してしまいます。

 

 

 

 

上記変更を加えた後、再実行すると、無事に成功しました！

 

 

ところで、データを確認すると、先ほどデータバインドを行ったはずなのに、データが１件しか登録されていません。

この設定は、テストの設定で変更を行いましょう（ソリューションエクスプローラーで Local.testsetting をダブルクリックすると出てきます）。

 

以下のように、「データソース行ごとに１つ実行」を選択します。

 

 

 

この後再び Web パフォーマンステストを実行すると、５つのエントリが追加されています。データバインドした CSV のデータ通りですね。

 

またうち一つを確認すると、タイトルと URL に日付情報が付与されており、コメントを行ったユーザーの名前が（最初に捜査記録した時に使っていた admin でなく、CSV で指定していた）admin5 となっていることを確認できました。

 

また、今回作成された５件のエントリのタイトル末尾を見ると、09121738 から 09131038 という数字になっていましたので、9時12分17秒から開始し、9時13分10秒の間に作成された（およそ１分のうちに、５本が作成された）、ということがわかりました。

 

 

このセクションでは、”Web パフォーマンス テスト” の作成方法を説明しました。

つぎは、この Web パフォーマンステストをシナリオごとに複数用意する準備をします。

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(4) 複数シナリオの用意

 

さて、通常の Web サイトにおいては、管理者による Blog のポストの他に、一般ユーザーによる情報の閲覧が行われます。また、これまで作成したロードテストでは、(2)の時が一分当たり約 500 Request が、(3)の場合には１分に５人の管理者がそれぞれ１エントリを書く、というスピードで実行されています。

 

実際の負荷を考えると、ちょっと負荷がかかりすぎですね。

そこで、Visual Studio では、ロードテストを作成する際に、Web パフォーマンステストで記録されている待ち時間をもとに、より実際のシナリオにあった負荷を設定することができます。

 

 

 

また、テストとテストの間に、クールダウン的な待ち時間を設定しておくことも可能です。

 

さて、(3)で作成した Web パフォーマンステストをもとに、仮想ユーザー数一人で、ロードテストを作成し、実際に実行した結果が以下の通りです。

 

 

 

 

(2) で実施したテストに比べると、ずいぶんおとなしいグラフになっています。

実は開始直後から、５分ごろまでの間隔は、テスト作成時に実際にコンテンツ作成にかかった時間をもとにして（サーバーから見ると）アイドルになっている時間になります。

コードで見ると以下のように、操作の記録の際には 340秒くらいかかっていたことがわかります。

 

 

 

結局、このシナリオを仮想ユーザー１人で実施した場合には、１０分の実行の間に１エントリが書き込まれただけのテストになりました。しかしながら、実際のブログの場合にも、書き込みに関してはその程度のアクセスでよいはずですので、テストシナリオとしては、OKとしましょう。

 

 

では、次に一般ユーザーによる情報の閲覧の操作を記録しましょう。

ここまでの試行で、すでに Blog エントリが複数できていますので、トップページに来てざっとタイトル等をよみ、いくつかのエントリを読む、といったシナリオを想定し、新規に Web パフォーマンステストを作成します(下図は実際に作成したテストの内容です）。

 

 

つぎに、これらを合わせて、ロードテストの作成を行いましょう。

今回は30秒に５ユーザーずつ仮想ユーザーを増加させたいと思います。最大値は100ユーザーに設定しました。

 

 

あわせてテストミックスとしては、管理者シナリオが20%、一般ユーザーシナリオが 80% の割合で実行されるようにしました。従って、テスト開始当初は、管理者が一人、一般ユーザーが４人、Web サイトにアクセスしているようなイメージになります。これがテストの最終段階では、管理者が２０人、一般ユーザーが８０人、アクセスしている形になります。

 

 

それでは、いよいよロードテストの実行に移りましょう！

 

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(5) ロードテストの実施

 

Visual Studio から、ロードテストを開始します！

すると、３分ごろ（＝仮想ユーザーは約３０人）のあたりで、エラー（紫のグラフ）の数が上がりました。

 

 

 

確認すると、先ほど同様、Site Unavailable のエラーです。

しかし、しばらくすると落ち着いてきましたので、引き続きテストを見守りましょう。

下記が１０分通して行ったテストの結果です。

 

 

開始６分ぐらいに再びエラーが増加してしまいますが、これは８分ぐらいにまた落ち着き始めています。

テスト終了後、サイトにアクセスすると、この時間帯に書き込みのアクセスが13件集中していました。おそらくこの辺りにも原因があったのではないかと思います。その後のエラーの解消は、これらの書き込みアクセスが落ち着いたために、サーバー全体のレスポンスが回復したものではないかと予想されます。

 

なお、今回の Azure 側のリソース消費は以下のような感じでした。

 

 

 

しかし、このポータルの内容を見る限り、Windows Azure の “Web サイト” としては、エラーがゼロ（上部グラフの青色のグラフ）なんですよねー。。。。。

 

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(6) Windows Azure Web サイトのスケールの調整

今回は非常に簡単な Blog の Web サイトとなっており、これまでのロードテスト結果からも、「意外と使える “Web サイト”」感を持っていただけたのではないでしょうか。

 

ただこれ、まだ無償枠での利用なんですよね。しかも１インスタンス。

 

 

ということで、次は、XS 相当の性能である「共有」モードを確認したいと思います。

Azure の管理ポータルにおいて「スケール」メニューから、Web サイトのモードを「共有」に切り替えましょう！

 

 

 

 

設定を保存すると、即座にインスタンスが再起動し、はれて XS 相当のパフォーマンスを持つ Web サイトに生まれ変わります！

では、さっそくロードテストを開始！

 

 

 

 

うう、、、、、、期待していたほどの数値になっていないですね、印象としては無料枠と変わらない。。。。

 

 

しかし、先ほど管理ポータルのほうで、Web サイトとしてのエラーが特に報告されていなかったので、今回もしや、とおもいエラーが出始めた際に、管理ポータルのダッシュボードを確認したのが以下の画面。

 

 

 

なんと、５分当たりの CPU 使用率の上限に引っかかっていたようです。

今回のテストシナリオでは、その他の項目はほぼ問題ないのですが、CPU の制約が厳しいようです。

 

 

ということで、いよいよ上限値のない本命、「占有」モードに切り替えましょう！

 

 

前述したように CPU の上限値以外は問題がなさそうなので、今回は Small インスタンスを１つ利用します。

 

 

なお、実際には、今回先ほどと同条件（「共有」）にてロードテストを開始後、そのテストの最中に占有インスタンスへの切り替えを行いました(下図の緑の矢印あたりで「共有」から「占有」へのアップグレードを実施しています）。

 

体感で約１０秒程度でインスタンスが切り替わり、CPU 上限という枠がなくなった “Web サイト” はさくさくとリクエストをさばき始めたようです（紫色のグラフがエラーの数を示しますが、占有へ切り替え後は見事にゼロになりました）。

 

 

ただ、テストの応答時間（Ave. Page Time。青色のグラフ）は占有への切り替え後も、仮想ユーザー数の増加に伴い数値が増加しており、全体的にはそれなりの負荷がかかっていることがわかります。

 

 

あとは、実際に作成したシナリオのリアリティと、求める非機能要件（レスポンスタイムの制約）などによって、テストの精度を高め、また Azure のインスタンスサイズなどの利用量を調整することになるかと思います。

 

 

■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

(7) ロードテスト機能の利用権に関して

最後に、今回紹介した Visual Studio の Web パフォーマンステスト、あるいはロードテスト機能ですが、Visual Studio 2012 においては最上位の Ultimate にて提供される機能です。

 

一方、この機能自体は Visual Studio 2005 において Team System が登場した際から提供されており、Visual Studio 2005 および 2008 であれば、Team Edition for Software Tester または Team Test にて提供されています。

 

 

また、Visual Studio 2008 から Visual Studio 2010 へバージョンが切り替わる際に、Visual Studio 2008 において いずれかの Team Edition を MSDN Subscription 付きで購入されており、また MSDN Subscription が有効期間中だった方は自動的に Visual Studio 2010 の Ultimate with MSDN にアップグレードされている（手続きや追加費用なしに）ので、意外とロードテスト機能の利用権をお持ちでいながら、気づいていない開発者の方もいらっしゃるかもしれません。

 

今回紹介したように、この機能を利用すると Web アプリケーションのテストが驚くほど簡単にでききるようになりますので、MSDN Subscription をお持ちの方は、この機能を使う権利（＝Ultimate の利用権）を持っていないか確認してみてください（※）。

 

また、これから購入を検討してみたい、という方は、 https://aka.ms/Try-VS2012 で Ultimate の試用版をダウンロードし、この機能を試してみてください！

 

 

それでは、Enjoy！

 

 

※なお、Visual Studio 2008 から 2010 への移行の際に Ultimate へのアップグレードが行われていても、その後の MSDN Subscription 更新で、Ultimate ではなく Premium での更新を選択された場合は、Ultimate の利用権利がなくなっていますのでご注意ください。