Part 3. Web サイトサービスアプリケーション開発上の注意点

さて、ここまで Web サイトサービスの概要やその内部動作アーキテクチャについて解説してきたわけですが、引き続き今度は、このサービス上に乗せるアプリケーションを作成する場合の注意点についていくつか解説したいと思います。

• ロードバランサとセッションプロバイダ
• ワーカープロセスの特徴
• 利用できない代表的な機能
• 国際化対応
• アプリケーションの配置方法
• アプリケーションの運用監視方法

［ロードバランサとセッションプロバイダ］

先に述べたように、Web サイトサービスでは、ARR リバースプロキシ層のおかげで、セッションアフィニティ機能つきの負荷分散が行われます。結果として、セッション情報をメモリ上に保有しても、通常は問題なく動作するのですが、Web サーバが何らかの理由でダウンすると、セッション情報が失われてしまいます。このため、Web サーバをクラスタリングする場合には、仮にセッションアフィニティがあったとしても、下図のようにセッション情報をバックエンドストレージに保存することが望ましいです。

具体的には、以下の 3 つの作業を実施します。

• ① セッション情報保存用の SQL データベースを作成する
• ② ASP.NET Universal Provider を入手する
• ③ web.config に構成設定を行う

① セッション情報保存用の SQL データベース（SQL Azure）を作成する

まずは管理ポータルサイトから、新規に SQL データベースを作成します。（Web サイトサービスからリンクリソースとして結びつけておくと管理がラクになりますが、必須ではないので、単独でふつーに SQL データベースを作成していただいて構いません。） 作成する場合には Web サイトサービスで利用しているのと同一のデータセンタ（Region）を指定してください。作成後、Show Connection Strings を押下し、ADO.NET 用の接続文字列を入手しておきます。

② ASP.NET Universal Provider を入手する

.NET Framework 2.0～4.0 に標準で含まれるセッションプロバイダでは、SQL データベースを利用することができません。このため、NuGet パッケージとして配布されている ASP.NET Universal Provider を入手し、これを利用します。具体的な入手手順は以下の通りです。

• Web Platform Installer をインストールする。（VS2012 では不要）
  https://www.microsoft.com/web/downloads/platform.aspx
• NuGet パッケージマネージャをインストールする。（VS2012 では不要）
  https://nuget.codeplex.com/
• Visual Studio を立ち上げ、NuGet コンソールを起動。
  ツール → ライブラリパッケージマネージャ → ソリューションの NuGet バッケージの管理 を選択
• NuGet コンソールから ASP.NET Universal Provider をインストールする。
  ソリューションを開いた状態で、コンソールから以下のコマンドを実行
  Install-Package System.Web.Providers

以上で、ASP.NET Universal Provider が、Web アプリケーションに組み込まれます。

③ web.config に構成設定を行う

最後に、web.config ファイルを修正します。パッケージマネージャで ASP.NET Universal Provider をインストールすると、web.config ファイルにいくつかの設定が追加されていますので、これを修正すれば OK です。具体的には、下図の赤字の部分を修正します。

なお実際には、開発中はファイルアタッチデータベースを利用し、Azure 環境へのアップロード直前に構成設定ファイルを書き換える形になると思いますが、いちいち開発環境と Azure 環境の設定を書き換えるのは面倒です。このような場合には、下図のように web.Debug.config や web.Release.config ファイルを利用し、Azure 環境へ発行するアプリケーションのビルド条件（Debug ビルド or Release ビルド）に併せて web.config を置換するとよいと思います。

なお、事前に セッション情報を格納するためのテーブルを SQL データベース上に作っておく必要はありません。以上の作業を行ってアプリケーションを実行すると、下図のように自動的にセッション格納用のテーブル（Sessions テーブル）が作成され、これが利用されます。

 

セッションプロバイダに関する注意点は以上です。引き続き、Web サイトのワーカープロセスに関する注意点について解説します。

［ワーカープロセスの特徴］

Web サイトサービスのワーカープロセスには、以下のような特徴があります。

• 統合パイプラインモードの w3wp.exe として動作
• 64 ビットプロセスではなく、32 ビットプロセスとして動作
• ユーザごとに異なるローカルアカウントで動作
• .NET Framework は 2.0, 4.0 どちらも利用可能（どちらか片方のみ、管理ページから変更可能）
• カルチャは en-us、タイムゾーンは UTC で動作

このうちちょっと注意すべきなのが、ワーカープロセスの動作ビット数です。通常だとワーカープロセスの既定動作は 64 ビットですが、Web サイトでは 32 ビットプロセスが利用され、これについては変更できません。ASP.NET で Web アプリケーションを作成しているのであれば問題はないと思いますが、念のためご注意ください。

なお、Web サイトの実行環境の詳細を知りたければ、*.aspx 上から各種のデータを拾ってみるとよいと思います。下記に、Web アプリケーション内から拾った、マシン名情報や動作アカウント情報を記載します。（常にこの通りになるとは限りませんが、環境を理解する手助けにはなると思います。）

［利用できない代表的な機能］

前述のように、ワーカープロセスは特殊な制限アカウントで動作していること、また Web サイト環境が共用環境であることから、必然的に様々な制約が発生してきます。特にまず真っ先に気を付けるべきポイントを整理すると、以下のようになります。

• ファイルの自由な読み書きについて
  ほとんどのフォルダについて、自由な読み書きができません。ただし、アプリケーションが展開されているフォルダについては読み書きができます。どうしてもアップロードされたファイルをいったん保存しておきたければ、Server.MapPath(“~”) で取得されるフォルダ下への読み書きができますが、うかつなフォルダに書き込みを行うと、リモートにファイルが公開されてしまいます。基本的には、App_Data フォルダ下に書き込むなどの工夫を行うとよいでしょう。
• イベントログやパフォーマンスカウンタへの書き込みについて
  共用環境ですので、事実上利用できません。書き込みを行おうとすると処理がブロックされ、エラーが出るようになっています。このため、アプリケーションの例外発生時のログをイベントログに記録しておくことができません。通常、global.asax ファイル内で行っているイベントログへの例外ログ書き出し機能については、下に示すように、App_Data フォルダ下へのファイル書き込みという形に変更していただくとよいでしょう。
• COM コンポーネントや 3rd party 製ソフトのインストール
  当たり前のことですが、これらもできませんので注意してください。

なお、注意すべき点として、これらの制約事項は共有型サーバだけでなく、占有型サーバについてもあてはまります。サーバを占有しているのだからこれらが自由にできる、ということにはならないので注意してください。（これらを行いたい場合には、Web サイトサービスではなく、クラウドサービスや IaaS 仮想マシンサービスを利用します。）

［国際化対応について］

Web サイトサービスに限った話ではありませんが、Windows Azure は World Wide でのサービスですので、基本的に言語中立、UTC 標準時刻での動作になっています。このため、国際化対応を意識していないアプリケーションについては、正しく動作しないことがありますので注意してください。よくある実装ミスとしては、以下のようなものがあげられます。

本エントリは国際化対応について解説するためのエントリではないので詳細には立ち入りませんが、特に、時刻の取扱いなどについては DateTimeOffset クラスを使って正しく書くなどの工夫が必要になることに気を付けてください。

……というわけで、Web サイトで利用するアプリケーションの作り方について注意点をいくつか挙げてきたわけですが、クラウドサービス（コンピュートサービス）に比べて簡易な機能であるために、覚えるべき ＆ 注意すべきポイントもさほど多くはありません。単純なアプリであれば、簡単にそのまま載せてしまうことができるでしょうから、まずはぜひ、ご自身の Web アプリケーションを Web サイトサービスに載せて動かしてみていただければと思います。

引き続き、このサービスにアプリを配置する方法と、その運用監視方法について簡単に解説します。

［アプリケーションの配置方法］

Web サイトサービスに対して、開発したアプリケーションを配置する（アップロードする）方法は、大別して 4 通りあります。

• ① Web Deploy
  Visual Studio からアプリケーションの発行機能を利用して展開する（Visual Studio 2010 以降でのみ利用可能）
• ② クラウド版 TFS （Team Foundation Service）
  自動ビルドシステムの中の発行機能を使って展開する
• ③ Git
  オープンソースコードなどの開発で利用されている分散バージョン管理システムの Git から直接発行して展開する
• ④ FTP
  Web サイトサービスに直接つなぎ、ファイルをアップロードする

ASP.NET Web アプリケーションの開発で最も便利なのは、①の方法でしょう。これについて解説します。

Visual Studio から Web サイトサービスにアプリケーションをアップロードするためには、管理ポータルサイトから発行プロファイルと呼ばれる情報を入手する必要があります。具体的には、管理ポータルサイトの ”Download publish profile” というボタンを押下すると、XML 形式で、発行に必要な各種の情報を入手することができます。あとはこれを Visual Studio 2012 に読み込ませるだけです。以上の作業で、Visual Studio の「発行」機能を使うだけで、Azure 環境への直接アップロードができます。

ただし、ダウンロードされる XML ファイルは Visual Studio 2012 用ですので、Visual Studio 2010 の場合には、XML ファイル内の情報を手作業で Visual Studio に設定する必要があります。具体的には、まず発行プロファイル情報をメモ帳で開き、下記のタグを探します。そこに書かれて情報を、Web の発行画面に転記してから発行ボタンを押せば OK です。（ちょっと面倒ですが、一度だけやれば OK です。）

［アプリケーションの運用監視方法］

最後に、Web サイトアプリケーションの運用監視方法について解説します。

クラウドサービス（コンピュートサービス）では、自力で監視エージェントなどを組み込むことにより高度な運用監視が可能でしたが、Web サイトサービスではそのようなことはできません。しかし、簡易なアプリケーションを手軽に運用監視できる機能群が備わっているため、特に事前準備することもなく、すぐさま手軽に運用監視することができます。

具体的な機能としては以下の 2 つがあります。

• ダッシュボードによるモニタリング
• 各種ログの取得機能

これらについて解説します。

ダッシュボードによるモニタリング

これは Web サイトの管理ポータルに行ってみればすぐにわかると思いますが、管理ポータルの画面上に、Web サイトサービスの主要なパラメータがすぐに参照できるようなダッシュボードが提供されています。基本的な稼働状況は、こちらを見ていただければ一目瞭然でしょう。

各種ログの取得機能

またこれに加えて、以下の 3 種類のログを FTP により簡単に取り出すことができるようになっています。

• ① Web サーバのログ（IIS ログ）
• ② アプリケーションエラーのログ
• ③ Failed Request Tracing のログ

既定では、IIS ログのみ有効化されています。他のログについても有効化したい場合には、ポータル管理画面の “diagnostics” からログの取得を設定します。

FTP でアクセスすると、以下のようなフォルダ構造になっていますので、これらを取り出して適宜解析していただけるとよいでしょう。

［Web サイトサービスのまとめ］

というわけで、ここまで Web サイトサービスについて解説してきましたが、いかがでしょうか？ 要点を改めて整理すると、以下の通りです。

• 軽量ホスティングサービスである、Web サイトサービスを利用すると、非常に手軽にクラウドを利用することができる。
  クラウドサービスや IaaS VM サービスなどに比べて圧倒的に簡単に Azure を利用することができる
  制約事項も多いため、エンタープライズ向けのリッチなシステムを作りたい場合には、適宜クラウドサービスや IaaS VM サービスを使う
• 2 種類の配置モデルがある。
  共有型（Shared）、占有型（Prepared）
  共有型の場合には、クォータ制限があることに注意する
• アプリケーション開発時には、いくつか注意が必要。
  ファイル書き込み処理や国際化対応に注意しながら開発を進める

思ったより簡単に使えそうだ、と思っていただけたのであれば嬉しいところ。実際、使ってみると予想以上に簡単かつお手軽にクラウドを使うことができ、この手軽さこそが PaaS のよいところだよね、と思える出来に仕上がっています。クラウドサービス（コンピュートサービス）だとちょっとヘビーだよねぇ、と思っているような場合には非常に効果的な機能ですので、ぜひ使ってみてください。