Visual Studio 2010で、Azure のロードテスト（サイジング検証）
Windows Azure をはじめとするクラウドコンピューティングのメリットの１つは、利用状況に応じて動的にサーバパフォーマンス（とそれに必要なコスト）を変更できることです。
当然、Windows Azure では、インスタンス数とホストしているVMのコアを動的に変更できるようになっています。特に、インスタンス数は、Azureの管理画面から簡単に変更できるようになっています。
が、
実際に、インスタンス数やVMの種類によってどれくらいパフォーマンスが変わるのか？というのは、調査が必要なところですし、おそらくその調査内容も、実装される（Web）アプリケーションのアーキテクチャに依存するところが多いでしょうから、実運用に近い形で、開発およびテスト環境およびワークフローを構築することが重要になります。
ということで、開発環境およびロードテスト環境を構築して、実際に、インスタンス変更によるパフォーマンスの差異を簡単に検証してみました。
まず、開発環境。
開発環境は、VisualStudioです。それだけ。
次に、テスト環境。
Webのパフォーマンスチェックツールはいくつかあります。昔懐かしいMS Web Application Stress もいいかなと思いWebを見てみると、「提供は終了しました」とのこと、さらに、Web Capacity Analysis Tool（WCAT）もございます。とのことなので、とりあえず使い方を見てみると、なにやらめんどくさそうなので、Visual Studio 2010 Ultimit （たぶんVS 2010 Test ProfessionalというのでもOKだと思います）についているTest機能を使うことにしました（細かなステップは今日は書きません。すみません）。
VSを使うと操作も結果もグラフィカルです・・・。さすが有償。
テストシナリオの設定。テストミックスで、Topページへの単純なアクセスを設定。ブラウザミックスでは、とりあえずIE8.0で100％行うことにしていますが、ここにFirefox20%とか設定できます。また、ネットワークも、LANとかダイアルアップとか、設定できます（テストの記録で、X64環境だと、テスト内容が記録されない不具合に見舞われましたが、先人の知恵で解決しました）。
テスト対象としては、とりあえず、先日Azure上に展開したWordPressを利用することにします。とはいえ、今回は、単にTOPページにアクセスするだけということにします。
これです。Windows Azureに載せてます。バックエンドDBはSQL Azureです。
VS上でテストを定義し、実行準備を整えました。
で、まず、インスタンス1個の状態からテスト。
うーん。早いんだから遅いんだかわかりませんが、まあいいとしましょう。
次にインスタンスを10個にしてみました。
Azureの設定画面。この1になってるところを変更します。今日は10です。私のVMはSコースなので、20個まで増やせるはずですが・・・ま、いいでしょう。
インスタンス数を10に変更して、「Save」。
今回のプロセスの中で、一番「あれ？」と思ったのがこのフェーズです。Saveしたまま、しばらくAzureの設定画面が「RoleがUpdating」とかになったままになりフリーズしたのかと思ってしまいました。どうやら、インスタンス数の変更は結構な時間を要するようです。結局20分くらいかかりました。まあ、よくよく考えてみると、複数のサーバにまたがるであろう処理設定を行うわけですから、20分くらいは許せる範囲かもしれません。ちなみにインスタンス数を1にもどすのは、10秒くらいでした。
なお、Updatingの間、数度サイトにアクセスしてみましたがダウンはしていませんでした（瞬断はあるのかもしれません）。
で、なんとかインスタンス10になったので、テストを実行してみました。
処理できるページ数で5倍弱というところでしょうか。
「えー、インスタンス10倍にしたのに？？？」と思うかもしれせんが、これは、並列処理の限界もさることながら、Wordpressの構造が影響しているものと思われます。WordPressはいわゆる動的に都度コンテンツを生成（都度DBにアクセス）しているので、処理能力向上のためにはWebRoleのインスタンス数のUPもさることながら、SQL AzueのパフォーマンスUPが影響するのだと思います。SQL Azure はマルチインスタンスには対応していないのでVM環境のスケールアップで処理能力UPをすればいいと思います。
が、今日は、ちょっと時間がないので、その報告はまた別の機会に。
というか、課金が心配。