特集 Windows Azure開発入門（後編） Windows Azureクラウド・サービスの配置／運用 デジタルアドバンテージ　一色 政彦 2009/02/17
Page1 Page2 Page3 Page4

■Visual Studio 2008からWindows Azureへの配置方法

　それでは、（VS 2008で開発した）既存のWebクラウド・サービスのプロジェクト（以降、VSクラウド・プロジェクト）を、先ほど作成したWAクラウド・プロジェクト（＝Windows Azure上のクラウド・サービスのプロジェクト）に配置してみよう。

●クラウド・サービスの構成（Web.configファイルと.cscfgファイル）

　最初に、そのWebクラウド・サービスがWindows Azure上でどのように動作するかという構成を設定する。

　ASP.NET Webアプリケーションの構成は一般的にWeb.configファイルで行うが、これは（Web／Workerロールの）クラウド・サービスでも基本的に同じだ。しかしクラウド・サービスは、ZIP形式で圧縮された単一のファイル（.cspkgファイル）として配置することになるため、少しだけ構成内容を変えてクラウド・サービスの挙動をカスタマイズしたい場合でも、.cspkgファイル、つまりプロジェクト全体をアップロードし直さなければならない。これでは不便である。

　そこでWindows Azureでは、.cscfgファイル（クラウド・サービス構成ファイル）が新たに用意されている。この.cscfgファイルをAzureポータル上で編集したり、ローカルで編集して再アップロードしたりすることで、Windows Azureへの配置後でもクラウド・サービスの構成を変更できるようになっている。要するに.cscfgファイルによって、配置後の運用環境で随時さまざまな微調整が行えるというわけだ。この方法について詳しくは、後述の「【コラム】Azureポータルでの.cscfgファイルの編集」で説明している。

　また、（クラウド・サービスの構成だけでなく）実行環境であるWindows Azureの構成も、この.cscfgファイル（クラウド・サービス構成ファイル）と、そのペアとなる.csdefファイル（クラウド・サービス定義ファイル）で行うようになっている。Windows Azureの運用を始めるに当たっては、この2種類の構成ファイルの書き方をマスターしておく必要がある（といっても、シンプルで難しくない）。

　以下では、この2種類の構成ファイルの内容と編集方法を一通り説明しておこう。

●クラウド・サービス構成ファイル（.cscfgファイル）の編集

　まず、.cscfgファイルをVS 2008上で編集する。VSクラウド・プロジェクトを開き、［ソリューション エクスプローラ］で「Cloud Service」（クラウド・サービス）のプロジェクト（＝「WebRole」や「WorkerRole」ではない方のプロジェクト）に含まれる「ServiceConfiguration.cscfg」ファイルを開く。すると、最初からひな型コードが生成されているはずだ。次のコードはそのひな型コードを少しだけ修正したものである。

<?xml version="1.0"?> <ServiceConfiguration serviceName="CloudService1" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">   <Role name="WebRole">     <Instances count="1"/>     <ConfigurationSettings>       <!-- 構成設定の値をセットする（後述） -->       <Setting name="SettingName" value="SettingValue"/>     </ConfigurationSettings>   </Role> </ServiceConfiguration>

クラウド・サービス構成ファイルの内容（ServiceConfiguration.cscfgファイル）

先頭に「<?xml version="1.0"?>」と書かれていることから分かるようにXMLで記述する。

　.cscfgファイルでは、<ServiceConfiguration>要素内にクラウド・サービスの構成設定を記述していく。詳しくは後述するが、<ServiceConfiguration>要素のserviceName属性の値は、.csdefファイル（クラウド・サービス定義ファイル）における<ServiceDefinition>要素のname属性の値と一致させる必要がある。xmlns属性（XML名前空間）は、（現CTP版では）常に「http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration」である。

　<Role>要素内で、Web／Workerロールの構成を行う。上記の記述例では、<Role>要素のname属性が「WebRole」となっているが、これはつまりWebロールの構成を設定している。なお現在の仕様では、1つのクラウド・サービスには、Webロールは1つまで、Workerロールも1つまで、含められる（Webロール1つとWorkerロール1つという組み合わせは可能だが、2つのWebロールを含めることはできない）。ちなみに、ここでWorkerロールも含めたい場合は、「<Role name="WorkerRole">」という定義を新たに付け加えればよい。

　<Role>要素内を詳しく見ていくと、「<Instances count="1"/>」という記述があるが、この<Instances>要素のcount属性の値は、仮想マシン（VM）のインスタンス数を示す。Windows Azureの内部はハイパーバイザ（Hypervisor）による仮想化がなされており、Web／Workerロールはそれぞれ専用の仮想的なサーバ・マシン上で実行される。つまりここでは、定義中のロールに対して、その仮想サーバを何台用意するかを設定している。ここで台数（＝インスタンス数）を増やしたり減らしたりスケールすることで、パフォーマンスを調整できる。

　<ConfigurationSettings>要素は、独自の構成設定の値を記述するためのもの。詳しくは、後述の「独自の構成情報を設定するには？」を参照してほしい。

　以上の.cscfgファイルにはWindows Azureの実行時に使われる構成設定の値（＝動的に変えられる値）が記述されているわけだが、実行前に定義しておくべき構成設定の値や定義（＝動的に変えられない値）は、もう一方の.csdefファイルの方に記述されている。次に、その「ServiceDefinition.csdef」ファイルを編集する。

●クラウド・サービス定義ファイル（.csdefファイル）の編集

　.csdefファイルの内容は次のようなものになる。

<?xml version="1.0" encoding="utf-8"?> <ServiceDefinition name="CloudService1" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">   <WebRole name="WebRole">     <InputEndpoints>       <InputEndpoint name="HttpIn" protocol="http" port="80"/>     </InputEndpoints>     <LocalStorage name="MyCache" sizeInMB="1"/>     <ConfigurationSettings>       <!-- ここに構成設定を定義する（詳細後述） -->       <Setting name="SettingName"/>     </ConfigurationSettings>   </WebRole> </ServiceDefinition>

クラウド・サービス定義ファイルの内容（ServiceDefinition.csdefファイル）

<ServiceDefinition>要素のxmlns属性（XML名前空間）も、（現CTP版では）常に「http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration」である。

　.cscfgファイルとペアになる.csdefファイルでは、<ServiceDefinition>要素内にクラウド・サービスの構成設定の定義を記述していく。name属性の値は、前述した<ServiceConfiguration>要素のserviceName属性と一致させる必要がある。

<ServiceDefinition>要素のname属性値と<ServiceConfiguration>要素のserviceName属性値の一致

　<ServiceDefinition>要素の子要素として、Webロールを定義するための<WebRole>要素と、Workerロールを定義するための<WorkerRole>要素が用意されている。いずれもname属性にユニークなロール名（＝役割名）を記述する。<WebRole>／<WorkerRole>要素の配下には<InputEndpoints>／<LocalStorage>／<ConfigurationSettings>といった子要素を記述できる。

　<InputEndpoints>要素内には、1つ以上の<InputEndpoint>要素を記述する。<InputEndpoint>要素は、HTTP／HTTPSリクエストを受け付ける転送プロトコルとポート番号で構成されたサービス・エンドポイントの定義である。現在のWindows Azure（CTP版）では、HTTPとHTTPSの2種類しかサポートされていないので、次の2種類の<InputEndpoint>要素のいずれか、もしくは両方を書くことになる。

<InputEndpoint name="HttpIn" protocol="http" port="80"/> <InputEndpoint name="HttpsIn" protocol="https port="443"/>

HTTP／HTTPSのサービス・エンドポイントを定義した<InputEndpoint>要素

　<InputEndpoint>要素の各属性を説明しておくと、name属性にはサービス・エンドポイントの名前を、protocol属性にはサービス・エンドポイントのトランスポート・プロトコル（「http」もしくは「https」）を、port属性にはサービス・エンドポイントのポート番号（HTTPなら80番ポート、HTTPSなら443番ポート固定）をそれぞれ指定する（※ちなみにHTTPSを指定したい場合は、クラウド・サービスのプロジェクト・プロパティの［SSL］タブも設定しなければならない）。

　<LocalStorage>要素は、Windows Azure仮想マシンのローカル・ストア（＝ローカル・ファイル・システム上の一時的なキャッシュ領域）を指定するためのものである（※通常のASP.NETサイトで使われるキャッシュ領域のApp_Dataフォルダでは、CAS（コード・アクセス・セキュリティ）の制限によりファイルの書き込みが行えない。その代替として、このキャッシュ領域が用意されている）。name属性でキャッシュ領域の名前を、sizeInMB属性（※MSDNでは「Mb」となっているが「MB」が正しい）で割り当てたいキャッシュ領域の容量をMbytes単位で指定する。なお、このキャッシュ領域の内容は、ロールを一時停止（Suspend）したり、再起動（Run）したりする際に削除されてしまうので注意してほしい。

　実行時にキャッシュ領域の場所を取得するには、RoleManagerクラスの静的（static／Shared）メソッドのGetLocalResourceを使う。GetLocalResourceメソッドはパラメータにキャッシュ領域の名前を取り、戻り値でILocalResourceインターフェイスのオブジェクトを返す。ILocalResourceオブジェクトのRootPathプロパティでキャッシュ領域のディレクトリ・パスが取得できるので、そのディレクトリ内の任意のファイルを作成して読み書きすればよい。

ILocalResource ires = RoleManager.GetLocalResource("MyCache"); string dirPath = ires.RootPath;

「MyCache」という名前のキャッシュ領域のディレクトリ・パスを取得するコード（C#）

　キャッシュ領域を使うメリットは、ローカルの仮想マシン内でデータ・ファイルに直接アクセスできるのでパフォーマンスがよいことである。従って、変更することのない大容量のデータや一時的なデータの場合には、このキャッシュ領域を使うとよいだろう。

　逆に頻繁に変更するデータや永続的なデータの場合は、Windows Azureストレージ・サービス（もしくはSQL Data Services）を使うのが好ましい。Windows Azureファブリック・コントローラは、状況に応じてロールを停止してほかの仮想マシンに切り替える可能性があり、そうなると、キャッシュ領域に格納したファイルに常にアクセス可能かを保証できなくなるからだ。

　<ConfigurationSettings>要素は、独自の構成設定の定義を記述するためのもの。詳しくは、下記の「独自の構成情報を設定するには？」を参照してほしい。

●独自の構成情報を設定するには？

　一般的に、独自の構成設定は、実行中のプログラム・コード内から読み出して、それを基にクラウド・サービスの動作を動的に切り替えるために利用する。

　例えば、「SettingName」という独自の構成設定をプログラム・コードで読み出すには、RoleManagerクラスの静的メソッドGetConfigurationSettingを呼び出す。下記のコード例を見ると分かるだろうが、パラメータに構成設定の名前を受け取り、戻り値で構成設定の値を返す。

string settingValue = RoleManager.GetConfigurationSetting("SettingName");

「SettingName」という名前の構成設定の値を取得するコード（C#）

　「SettingName」という構成設定は、まず.csdefファイル（サービス定義ファイル）に定義しておく必要がある。<ConfigurationSettings>要素内には複数の<Setting>要素を記述でき、1つの<Setting>要素は1つの構成設定の定義を表す。その<Setting>要素のname属性に構成設定の名前を指定する。

　次のコードでは、上記のコードで読み出している「SettingName」という名前の構成設定を定義している。

……前略…… <ConfigurationSettings>   <Setting name="SettingName"/> </ConfigurationSettings> ……後略……

独自の構成設定の「定義」の記述（ServiceConfiguration.csdefファイル）

　定義した構成設定の「値」は、実行時に動的に変えられる.cscfgファイル（サービス構成ファイル）の方に記述する。<ConfigurationSettings>要素と<Setting>要素という同じ組み合わせだが、その<Setting>要素にはvalue属性により構成設定の値を指定する。

……前略…… <ConfigurationSettings>   <Setting name="SettingName" value="SettingValue"/> </ConfigurationSettings> ……後略……

独自の構成設定の「値」の記述（ServiceConfiguration.cscfgファイル）

　ちなみに、Windows Azureストレージを利用する際には「StorageClientライブラリ」が便利だが、そのWindows Azureストレージ・サービスのエンドポイントの指定には、上記のような独自の構成設定が使われている。これについては、「Webアプリケーションをクラウドの中に移行した例」という記事の「Windows Azureに展開するうえでの注意点」の項で紹介しているので参考にしてほしい。

　それでは実際にクラウド・サービスを配置してみよう。

INDEX
	[特集] Windows Azure開発入門（前編）
	無償開発環境で試すWindows Azureクラウド開発
	1．Windows Azure開発環境の構築
	2．WebロールのWindows Azureクラウド・サービスの作成
	[特集] Windows Azure開発入門（後編）
	Windows Azureクラウド・サービスの配置／運用
	1．Azure Services Developer Portalでのプロジェクト作成
	2．クラウド・サービスの構成
	3．クラウド・サービスの配置
	4．Windows Azure／Azure Services Platformの利用申請

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）