しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Windows Azure Web サイトのオートスケールを検証してみた

少し前のアップデートで Windows Azure Web サイトでもオートスケールが使えるようになったのですが、そこまで Web サイトがガッツリ使われていないからなのか、あまり検証を行った記事は無いみたいです。

今の仕事では Web サイトを結構本気で使っているので、何時かは必要になるであろうオートスケールの検証を行っておくことにしました。

オートスケールの設定

Web サイトでオートスケールの設定をするためには、サイズを標準インスタンスにアップグレードする必要があります。共有インスタンスでもインスタンスの数は増やすことが出来ますが、オートスケール設定は出来ないので注意が必要ですね。

とりあえず、今回はオートスケールの検証用に標準インスタンスの Web サイトを 1 つ用意しました。

f:id:shiba-yan:20130914233658p:plain

そしてオートスケールの設定ですが、クラウドサービスの場合はキューのメッセージの数でも設定できるのですが、Web サイトの場合は CPU 使用率とスケジュールの指定だけが出来ます。

f:id:shiba-yan:20130914234118p:plain

スケジュールの設定は分かりにくいですが、定義した時間ごとにスケールの設定を保存できるようです。とりあえずメトリックだけ指定して保存しておきます。

ターゲット CPU は 60-80 のままですが、これは CPU 使用率が 60% を下回った時に縮退、80% を上回った時にスケールアウトを行うという意味のはずです。実際に本番環境で使う場合には、もうちょっと調整は必要になるかと思います。

インスタンス数の増減を確認する

後は適当なアプリケーションをデプロイして loader.io を使って負荷をかけることにします。loader.io については以前ブログに書いたので、こっちを参照してください。

loader.io を使って Web サイトの負荷テストを実行してみた - しばやん雑記

実際に loader.io を使って負荷をかけたところ、暫くして Web サイトのインスタンスが増え始めました。

クラウドサービスとは違い、インスタンス数の増減グラフは用意されていないので分かりにくいですが、現在のインスタンス数を手っ取り早く確認するには、メトリックの設定を「なし」にします。そして表示されたインスタンス数が、現在稼働しているインスタンス数になるようです。

f:id:shiba-yan:20130915002551p:plain

後は、管理サービスの操作ログからオートスケールの処理が何時に実行されたか確認出来ます。

f:id:shiba-yan:20130915003747p:plain

そしてインスタンスが増えた後に負荷をかけるのをやめてみたところ、約 2 時間後ぐらいから増やされたインスタンスが減り始めました。

f:id:shiba-yan:20130915030039p:plain

稼働中インスタンスの数は相変わらず分かりにくいですが、管理ポータルを見るとコスト削減率が表示されるので、これでもインスタンスが減ったことは確認できますね。

ちなみに 33% 削減と言うのは、オートスケール設定の最大インスタンス数に対する率になっています。なので、この場合では 3 台中 1 台が止まっているので 33% 削減ということになります。

f:id:shiba-yan:20130915124202p:plain

そして 1 インスタンス減ってから 2 時間後にもう 1 インスタンス減って、通常の状態に戻りました。下の 2 つが縮退操作のログになります。

IIS ログについて

この間追加された Web サイトの IIS ログを Blob ストレージに保存する機能を使っている場合は、マシン別にちゃんとストレージに保存されます。

f:id:shiba-yan:20130915003541p:plain

しかし、実際にインスタンスが増えてからストレージにログが転送されるまでには少し時間がかかるみたいなので、ログが保存されていないからと言って焦る必要は無さそうです。

オートスケール時の挙動について

管理サービスから確認できる、オートスケール処理が実行された時間を見る限りでは、Web サイトの場合は 10 分毎に CPU 使用率を確認してオートスケールを実行しているように見えますね。

そして IIS ログに残っている時間を確認すると、オートスケール処理が行われてから最大でも 3 分以内にインスタンスは起動し、リクエストを受付可能な状態になっているようです。しかし、Web サイトのロードバランサーの仕様なのか分かりませんが 3 インスタンスで稼働している状態であっても、メインの 1 インスタンスにしかリクエストが割り振られないという、不思議な挙動を示していました。

f:id:shiba-yan:20130915010023p:plain

上の画像は 1 秒に 1 回リクエストを投げ続けた時の IIS ログですが、RD00155D380DF6 のログだけが増え続けて他のマシンのログは全く更新がされていませんでした。

これだとインスタンス増やし損な感じなので、何らかの問題があったのかもしれません。

まとめ

今回の検証で分かったことをまとめておきます。

  • Web サイトは 10 分程の間隔で CPU 使用率をチェックしてインスタンスを増やす
  • インスタンスが増えてからは、最大でも 3 分以内にリクエスト処理可能な状態になる
    • インスタンスの起動、ユーザーコンテンツ VHD のマウント、IIS ワーカープロセスの起動を含む
  • 複数インスタンスで動作していても 1 つのインスタンスにリクエストが偏る?
    • 何か怪しいけど、そういったログになった
  • 過去 2 時間程の CPU 使用率が設定値を下回った時にインスタンスを減らす
    • インスタンスを複数増やしていた場合は 2 時間に 1 つずつ減らす

思ったよりインスタンスを増やすのは早いみたいなので、急激なリクエストの増加にもある程度は対応できる気がします。逆にインスタンスを減らすのには時間がかかるようなので、少し注意が必要かもしれません。

予めピークタイムが予測できるような場合には、予めオートスケールのスケジュールを設定しておくのが良さそうですね。