タイトルはホッテントリメーカーで作りました。特に意味はありません、多分。
ここ数ヶ月は Windows Azure Web サイトを使って開発していたので、その時に気が付いた点・ハマった点をまとめておきます。それ以外にも Web サイトに関係することを総まとめな記事にしておきます。
ちなみに今回のアプリケーションの開発、動作環境は以下のような感じです。
- Windows Azure Web サイト
- 標準 S インスタンス、独自ドメイン SSL 付き
- SQL Database
- Web Edition
- ASP.NET MVC 4
- LINQ to SQL
今回は開発の都合で LINQ to SQL を使いましたが、SQL Server 相手では良い感じに使えました。
アプリの起動に時間がかかる
アプリをデプロイしたタイミング、インスタンスサイズを切り替えたタイミング、Web サイト自体のアップデートのタイミングで応答に数秒から 10 数秒かかる時があります。起動した後は高速に動作してくれますが。
デプロイしたタイミングでは MVC アプリの場合は、ビューのコンパイルとかで時間がかかるので仕方ない感じです。アプリケーションプールも再起動しますし。
しかし、インスタンスサイズの切り替えやアップデートのタイミングでは、下手したら 10 秒以上時間がかかる時があります。事実、S インスタンスから M インスタンスに切り替えたタイミングで 10 秒たっても応答が返ってこなかったので、やばいと思って戻したことがあります。
インスタンスの移動を考慮する
Web サイトはクラウドサービスとは異なり、インスタンスが別のマシンへ色々と移動したりします。移動することは標準インスタンスの場合はあまり無いみたい*1ですが、今までに 2 回ほどインスタンスの移動を経験したので考えておく必要がありますね。
監視には New Relic を使っているのですが、インスタンスが移動した場合には以下のようにわかりやすく表示されます。
マシンが 2 台あるのが一目で分かりますね。
移動のタイミングで何が起こるかですが、正直よくわかりません。自分は 10 秒ほどのダウンタイムの経験と、マルチスレッドに関係するバグが発覚して Web サイトの再起動を行ったことがあります。
セッションアフィニティ
Web サイトは IIS ARR でのルーティングを容易にするために、1 度 Web サイトへアクセスしたユーザーに対してクッキーを発行して、次からは出来るだけ同じインスタンスへアクセスするようになっています。
ということは、InProc なセッションを使っていても問題ないんじゃないかと思ったんですが、田口さん曰く物理的なマシンの故障などでインスタンスが移動した場合には、セッションのデータが吹っ飛ぶので Universal Provider などを今まで通り使った方が良いとのことです。
静的ファイルのレイテンシが悪い時がある？
通常では 60-70ms ぐらいで 304 を返してくれるのが、急に 500ms ぐらいになったりして細かいファイルが多い時に、レンダリングに時間がかかる時がありました。
なので、基本的に静的ファイルは Blob ストレージにアップロードして使うようにしています。
ちなみに Web サイトではクラウドサービスのように CDN を簡単に使えるようにはなっていないので、Blob にアップロードしておいた方が便利に使えると思います。まだ CDN が新ポータルで使えるようになっていない環境があるみたいですけどね。
独自ドメインを設定する
共有、標準インスタンスの場合は独自ドメインを設定することが出来ます。詳しくは以下の記事で。
SSL を設定する
標準インスタンスでは独自ドメインに対して SSL を設定することが出来ます。使い方は非常に簡単で、pfx にした証明書をポータルからアップロードして有効にするだけです。クラウドサービスとは比べ物にならないぐらい簡単ですね。
SNI SSL と IP SSL と 2 つ選べるようになってますが、IP SSL の場合は IIS ARR にグローバル IP アドレス 1 つを固定する？ことになるみたいなので、料金が結構お高いです。
モダンブラウザだけをターゲットにする場合には SNI SSL で十分のようです。
停止と再起動
Web サイトはポータルから停止と再起動というコマンドがあります。停止を選ぶと完全にサイトにアクセスできなくなって、以下のようなページへリダイレクトされます。IIS の停止ということになりそうです。
この時点ではワーカープロセスも止まっているようなので、New Relic のプロファイラのようにワーカーの動作中はロックされているファイルに対しても更新できるようになります。
そして再起動ですが、これは IIS の再起動に相当するコマンドのようです。ASP.NET のランタイムキャッシュは再起動したときに消えた気がします。
IIS ログの最大サイズは 35MB でした
あまりにも残念な仕様なのがこれですね。標準インスタンスを使っていても、IIS ログは 35MB までしか保存されません。*2
ちょっと前までは 35MB の壁に達したときに、ログが保存されないという致命的な問題がありましたが、今は 35MB でローテーションするようになっています。
しかし、今のサービスでは IIS ログの 35MB なんて 2 日で使いきってしまうので、1 日ごとに Blob ストレージにアップロードする機能が欲しいですね。今は FTP で繋いで Blob にアップロードするようなバッチを作る必要があります。
重要な追記
今朝に Web サイトのアップデートがあったようで、管理ポータルから Blob ストレージに IIS ログを保存する設定が追加されていました。
設定の前に保存先となる（プライベート）コンテナを作っておかないとエラーになります。
そして、今までのようにファイルストレージにログを保存する場合にもクオータサイズや保有期間を指定できるようになりました。
これは素晴らしいアップデートですね！
まとめ
とまあ、いろいろと便利だったり悩まされたりした Web サイトですが、クラウドサービスと比べると非常に簡単に扱えるので、非常に便利に使えています。
しかし、まだまだ残念な部分もあると感じたので、これからも開発が進むのを期待しています。Web サイトについて詳しく知りたい人は、河野さんの資料を見ると良いと思います！
