Windows Azure AppFabric Cachingでスケールアウトを実現しよう

Windows Azure新機能チュートリアル（5）

Web.configの修正

　コードの修正が完了したら、Web.configを修正して、AppFabric Cachingが提供するセッションプロバイダーを利用するように構成します。Web.configへ追加する内容は、管理ポータルから取得することができます。

　AppFabric Cachingの管理ポータルを開き、リボンから［View Configuration］ボタンをクリックします。Client Configurationダイアログが表示されます（図9）。表示される内容は、app.configファイルやweb.configファイルに貼り付けるためのXMLスニペットになっています。

図9　構成ファイルの表示

　表示されるXMLスニペットは、configuration要素下に追加するする部分と、system.web要素下に追加する部分の2つに分類されます。ダイアログには一括して表示されるため、2回に分けて取り込みます。

（1）エンドポイントの設定

　XMLスニペットに表示されたconfigSections要素とdataCacheClients要素は、configuration要素下に追加します（リスト3）。

リスト3　configuration要素に追加する内容（Web.config）

<configuration>
<configSections>                                                           *1
  <!-- Append below entry to configSections. Do not overwrite the full section. -->
  <section name="dataCacheClients"
           type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core"
           allowLocation="true" allowDefinition="Everywhere"/>
</configSections>

<!-- Cache exposes two endpoints: one simple and other ssl endpoint. Choose the appropriate endpoint depending on your security needs. -->
  <dataCacheClients>                                                       *2
    <dataCacheClient name="default">
      <hosts>
        <host name="キャッシュサービスのURL" cachePort="22233" />
      </hosts>

      <securityProperties mode="Message">
        <messageSecurity 
          authorizationInfo="認証情報">
        </messageSecurity>
      </securityProperties>
    </dataCacheClient>

    <dataCacheClient name="SslEndpoint">                                   *3

      <hosts>
        <host name="キャッシュサービスのURL" cachePort="22243" />
      </hosts>

      <securityProperties mode="Message" sslEnabled="true">
        <messageSecurity 
          authorizationInfo="認証情報">
        </messageSecurity>
      </securityProperties>
    </dataCacheClient>
  </dataCacheClients>
  ...
  ...
</configuration>

• *1は、dataCacheClientの構成するセクションを定義します。
• *2は、デフォルトのAppFabric Cachingエンドポイントを構成します。
• *3は、暗号化されたAppFabric Cachingエンドポイントを構成します。通信をSSLで暗号化したい場合は、こちらのエンドポイントを使用します。不要な場合は定義しなくても構いません。

　太字部分のURLと認証情報は、XMLスニペットによって埋め込まれるため修正不要です。

（2）セッションプロバイダーの設定

　XMLスニペットに表示されたsessionState要素とcaching要素は、system.web要素下に追加します（リスト4）。

リスト4　system.web要素に追加する構成（Web.config）

<system.web>
  <!-- If session state needs to be saved in AppFabric Caching service, add the following to web.config inside system.web. If ssl is required, then change dataCacheClientName to "SslEndpoint". -->
<sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider">             *1
    <providers>
      <add name="AppFabricCacheSessionStoreProvider"
           type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
           cacheName="default"
           useBlobMode="true"
           dataCacheClientName="default"
           applicationName="AppFabircCachingSample"
          />
    </providers>
  </sessionState>

  <!-- If output cache content needs to be saved in AppFabric Caching service, add the following to web.config inside system.web. -->
  <caching>                                                                                *2
    <outputCache defaultProvider="DistributedCache">
      <providers>
        <add name="DistributedCache"
             type="Microsoft.Web.DistributedCache.DistributedCacheOutputCacheProvider, Microsoft.Web.DistributedCache"
             cacheName="default"
             dataCacheClientName="default" />
      </providers>
    </outputCache>
  </caching>
  ...
  ...
</system.web>

• *1は、AppFabric Cachingをセッションプロバイダーとして利用するための設定です。
• *2は、OutputCacheプロバイダーを利用する設定ですが、利用しなければ特に追加は不要です。

　デフォルトでは、非暗号化のエンドポイントが利用されますが、SSLで暗号化されたエンドポイントを利用したい場合は、dataCacheClientName属性の値を、defaultからSslEndpointに変更することで利用可能です。

　太字のapplicationName属性はXMLスニペットに定義されていませんが、開発環境で複数インスタンスを展開して実行する場合には必要です。この属性が指定されていないと、キャッシュデータを保管するためのキャッシュキーの作成がHttpRuntime.AppDomainappIdを基にして行われます。開発環境ではインスタンスごとにこの値が異なるため、キャッシュの共有ができずエラーが発生する場合があります。

　これで、すべての準備は完了です。

実行確認

　概要で説明したように、複数のインスタンスでも正しくセッション情報が共有できているか確認するために、インスタンス数は2以上に設定して実行してみましょう。

　まずは、開発環境であるCompute Emulatorから実行してみます。ただし、実行にはアウトバウンドポートとして、TCPの22233番ポート（SSLエンドポイント利用時は、22243番ポート）を利用します。ファイアウォールが設定されているネットワークなどからは接続できない場合があるので注意してください。

　ブラウザが開いたら、KeyとValueに任意の値を追加していきます（図10）。ラベルにはこの処理を実行したインスタンス名、GridViewには初回アクセス日時と追加されたセッションデータが表示されます。

　リクエスト送信ごとに異なるインスタンスで実行されているにも関わらず、セッションデータが共用されていることが確認できます。

　また別のタブで開いたり、新規セッションとしてブラウザを開いたりして、セッションデータがどのように共有されるか確認してみてください。

図10　開発環境での実行画面

　続いてWindows Azure環境にデプロイして実行確認をしてみましょう。図11はセッションが維持されている状態で複数のブラウザを開いたところです。開発環境と同じく、異なるインスタンスで実行されているが、セッションデータが共有されていることが確認できます。

図11　Windows Azure環境での実行例

まとめ

　Windows Azure AppFabric Cachingの登場によって、ようやくマイクロソフトが正式に提供するセッション管理方法が登場しました。しかも、既存のコードを変えずにAppFabric Cachingに対応することができます。

　これによって既存アプリケーションのWindows Azureへの移行障壁がますます低くなったといえます。ぜひ、AppFabric Cachingを試してみてください。