はじめに
本稿では、Windows Azure SDK 1.3によって追加されたFull IIS機能について概要と使用方法について紹介します。Full IIS機能によって、従来のWindows Azureでは利用できなかった複数サイトの構成や、仮想ディレクトリ、仮想アプリケーションの構成が可能になります。
対象読者
- Windows Azureの新機能に興味のある方。
- Windows Azureのサブスクリプションを持っており、Azureを利用したことがある方。
必要な環境
- Windows Azureサブスクリプション
- Visual Studio 2010もしくは、Visual Web Developer 2010 Express
- Windows Azure Tools for Microsoft Visual Studio 2011.3以降 （Windows Azure SDK 1.4含む）
なお、本稿はWindows Azure SDK 1.3で追加された新機能説明ですが、執筆時点での最新版はWindows Azure SDK 1.4更新版です。Windows Azure SDK 1.3で発生していた、いくつかの問題が修正されているため、最新版の利用をお勧めします。また、本稿は、Windows Azure SDK 1.4 更新版で確認を行っています。
Full IISとは
Windows Azure SDK 1.3以降のWebロールでは完全なIISの機能を利用することができるようになりました。Full IISでは、「前回」紹介した権限昇格機能と組み合わせることにより、以下の内容を実現できるようになります。
- 複数サイトの構成
- 仮想ディレクトリ、仮想アプリケーションの構成
- 管理者権限との組み合わせによるIISの構成変更
- Web配置によるアプリケーションの発行（注1）
Windows Azure SDK1.4更新版より利用可能です。
Windows Azure SDK 1.3以降では、Webロールを作成すると既定でFull IISが構成されます。リスト1は、Webロールプロジェクトを作成した直後のサービス定義ファイル（ServiceDefinition.csdef）です。Sites要素が追加されていることが確認できますが、これがFull IISの定義です。このSites要素をコメントアウトすることによって、従来と互換があるモードで動作させることができます。
<WebRole name="WebRole1">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
さて、Full IISは、従来のWebロールとは何が異なるのでしょうか。Windows Azure SDK 1.2以前のWebロールは、Webサーバーの機能にHosted Web Core（HWC）と呼ばれる機構を利用して実装されていました。これはIISを使ってWebサーバー構築するのではなく、独自に用意したプロセスにIISコンポーネントを組み込み、Webサーバーの機能を実装する方法です。したがって、Webロール1つに1つのアプリケーションしかホストすることができないなど制約がありました。
Windows Azure SDK 1.3よりWebロールのWebサーバーはIISそのものとなり、各種制約は取り払われています。Windows Azureでは、これをFull IISと呼んでいます。したがって、Full IISと言っても特別なものではなく、通常のWindowsサーバーで利用していたIISが、Windows Azureでもそのまま利用可能になったということです。
HWCとFull IISの違い
Full IISが公開された当時、いままで正常に動作していたアプリケーションプールが動かなくなったという報告が数多く見られました。これは、HWCとFull IISの違いに起因するものです。ここでは、未然にトラブルを防ぐ意味でも、HWCとFull IISの構造の違いを説明します。
図1は、HWCの概念図です。WaWebHost.exeはWebロールを実行するホストプロセスです。ホストプロセスは、HWCとWebRole1.dll（注2）が組み込まれて動作します。Webアプリケーションのワーカープロセスは、WaWebHost.exe自身となり、ユーザーアセンブリと同一空間で動作します。
このため、ユーザーアセンブリと、Webアプリケーションの間で静的変数の共有を行っても問題なく、また実行権限の違いといったことを意識しなくて済みました。
RoleEntryPointクラスが定義されている、ユーザーが作成したアセンブリ。
図2は、Full IISの概念図です。WaIISHost.exeがWebロールを実行するホストプロセスとなりますが、Webアプリケーションは、IISのワーカープロセスであるw3wp.exeで実行されます。WebRole1.dllは異なる2つのプロセスに読み込まれていることが分かります。RoleEntryPointクラスのOnStart/Run/Stopメソッドが呼ばれるのは、WaIISHost.exe側です。
このようにWebRole.dllは、お互い異なるプロセスに読み込まれます。OnStartで初期化した静的変数を、Webアプリケーション側から参照するようなことは、HWCでは可能でしたが、Full IISでは不可能となります。
これに起因したバグとしては、ストレージ構成パブリッシャの設定があります。CloudStorageAccount.SetConfigurationSettingPublisher (...)をOnStartメソッドで構成し、CloudStorageAccount.FromConfigurationSetting(…)をWebアプリケーション側で実行するようなコードは、例外が発生し正しく実行できません。回避策として、CloudStorageAccount.SetConfigurationSettingPublisherをグローバルアプリケーションクラスのApplication_Startメソッドに移動する方法があります。
他にもFull IISに起因して、いくつかの既知の問題が発生しています。これらは、「Known Issues in Windows Azure」にまとめられています。
Workerロールで、Hosted Web Coreを利用したサンプルが、MSDN Archiveで公開されています。興味がある方は、「Windows Azure Hosted Web Core Worker Role」を参照してください。
