最新の Redis Cache については「Azure Redis Cache の使用 (.NET, PHP, Node.js)」に記載しました。(これは、古い記事です。)。

環境 :
Visual Studio 2010
Windows Azure SDK V1.4
Windows Azure AppFabric SDK V1.0 (07/2011 Update)
(Windows Azure の利用方法は下記補足)

関連ナンバー

• Windows Server AppFabric Cache v1.0
• Cache 機能一覧
• Azure Shared Cache
• Windows Server AppFabric Cache v1.1 (新機能紹介)
• Azure Role-based Cache
• New Azure Cache (留意点)

こんにちは。

以前投稿した「AppFabric caching A to Z」でも記載しましたが、Windows Azure caching では、Windows Server AppFabric caching の基盤を使用していますが、細かく見ていくと、その機能や概念にいくつかの差異があります。今回は、もうリリースされて随分と時間が経ちますが、この Windows Azure caching の相違点を整理しておきたいと思います。(その前に、まずは、簡単に、Windows Azure caching の使い方もおさらいしておきましょう。)

なお、あらかじめ、Visual Studio 2010 のインストールされた開発環境に、Windows Azure AppFabric SDK (07/2011) をインストールしておきますが、Windows Server AppFabric がインストールされている環境に、この SDK はインストールしないように注意してください。(将来的には統合されると思いますが、現在のところ、こうした点を見据えて、同じ厳密名のアセンブリが使用されており、競合して うまく動作しないためです。)

キャッシュの作成

まずは、簡単に、Windows Azure caching の使い方を確認しておきましょう。(この説明の中でも、一部、Windows Server AppFabric caching との相違点について触れます。)

まず、キャッシュを使用するため、Windows Azure 管理ポータル にサインイン (Sign In) します。ポータル上で、[サービス バス、アクセス制御、キャッシュ] をクリックして、[キャッシュ] を選択し、上部の [サービス名前空間] の [新規作成] (New Namespace) コマンドをクリックします。

表示される画面 (下図) で、名前空間の名前を設定して、[名前空間の作成] ボタンを押します。この名前空間を作成すると、[状態] 欄に、しばらく、「アクティブ化しています…」と表示されますので、この状態が「アクティブ」に変更されるのを待ちます。(これにより、「サービス名前空間」と呼ばれるものが作成されます。)

補足 : この際、上図の [キャッシュ – キャッシュ サイズ クォータ] (Cache Size Quota) 欄でキャッシュ サイズを指定できます。このキャッシュ サイズは、Windows AppFabric FAQ に書かれている通り、金額によって使えるサイズが異なっています。(なお、このサイズは、シリアライズ後のサイズを基準としていますので注意してください。)
また、こちら に書かれている通り、使用するサイズによって、「Transactions Per Hour」、「Bandwidth MB Per Hour」、「Concurrent Connections」のクォータ (上限値) も変わってきますので、こうした点も加味して、チューニング結果に応じた適切なサイズを使用 (契約) するようにしてください。

上記で新規作成した「サービス名前空間」(Service Namespace) というものですが、Windows Server AppFabric のホスト (キャッシュ サービス) にも似ていますが、少し異なっています。これについては、後ほど設定 (構成) の際に違いを説明したいと思いますので、まずは、先に進めましょう。

さて、上記の作成後、状態が「アクティブ」に変更されたら、作成されたサービス名前空間をマウスで選択して、上部の [クライアントの表示構成] (View Client Configuration) をクリックしてみてください。すると、下図の通り、このキャッシュ利用時に、構成ファイル (Web.config など) に記述すべき設定内容が表示されるので、この文字列を (クリップボードに) コピーしておきましょう。

コピーした構成には、下記の通り記述されているはずです。(下記で、「XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」の箇所には、認証のための Token 文字列が記述されています。なお、この文字列は、作成した名前空間ごとに異なるので注意してください。)
このように、Windows Azure cache では、Windows Server AppFabric cache と異なり、トークン (Token) によるアクセス制御をおこなっているという点もおぼえておいてください。(Windows Server AppFabric cache と異なり、この認証を None にすることはできません。)

. . .<dataCacheClients>  <dataCacheClient name="default"><hosts>  <host name="tsmatsuz-demo1.cache.windows.net" cachePort="22233″ /></hosts><securityProperties mode="Message">  <messageSecurity authorizationInfo="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">  </messageSecurity></securityProperties>  </dataCacheClient>  <dataCacheClient name="SslEndpoint"><hosts>  <host name="tsmatsuz-demo1.cache.windows.net" cachePort="22243″ /></hosts><securityProperties mode="Message" sslEnabled="true">  <messageSecurity authorizationInfo="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">  </messageSecurity></securityProperties>  </dataCacheClient></dataCacheClients>. . .

アプリケーションの開発

では、Windows Server AppFabric cache の際 と同じようなプログラムを、上記で作成した Windows Azure cache を使って構築してみましょう。

Visual Studio 2010 を起動し、[Windows Azure Project] のプロジェクトを新規作成します。
表示されるロール追加のウィザードで、下図の通り、[ASP.NET Web Role] を追加し、[OK] ボタンを押して、プロジェクトを新規作成します。

作成された Web アプリケーションで、[参照を追加] を選択して、下記の dll を参照追加します。(いきなりすべては必要ありませんが、この後のさまざまな応用に備えて、ここでは、すべての dll を参照追加しておきます。)

%programfiles%\Windows Azure\AppFabric SDK\V1.0\Assemblies\NET4.0\Cache\
Microsoft.ApplicationServer.Caching.Client.dll
Microsoft.ApplicationServer.Caching.Core.dll
Microsoft.Web.DistributedCache.dll
Microsoft.WindowsFabric.Common.dll
Microsoft.WindowsFabric.Data.Common.dll

Web アプリケーションのプロジェクトの Web.config を開き、上記でクリップボードにコピーした文字列の下記の configSections 要素と dataCacheClients 要素を、Web.config に張り付けます。(前述の通り、下記の XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX には、ACS のトークン文字列が設定されます。)
この設定により、この Web アプリケーション (Cache クライアント) から、上記で作成したキャッシュのサービス名前空間 (Cache サーバー) に接続が可能になります。

<configuration>  <configSections><section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere"/>  </configSections>  <dataCacheClients><dataCacheClient name="default">  <hosts><host name="tsmatsuz-demo1.cache.windows.net" cachePort="22233″ />  </hosts>  <securityProperties mode="Message"><messageSecurity  authorizationInfo="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"></messageSecurity>  </securityProperties></dataCacheClient>  </dataCacheClients>  . . .

補足 : 上述の通り、キャッシュへの接続は、メッセージ レベルの ACS Token によって認証されますが、さらに、キャッシュ サーバーとのやりとり (データ) を TCP レベルで暗号化したい場合は、sslEnabled プロパティが true に設定されたもう一方の dataCacheClient (「default」ではなく、「SslEndpoint」という名前の指定された構成) を使用してください。

さて、上記で、ホスト (<host />) を複数指定できるようになっているため、一見すると、Windows Server AppFabric のホストと同じように多数のホストを設定してスケール アウトをおこなえるように想像されるかもしれません。
しかし、実際には、割り当てられる Authorization token (authorizationInfo) の文字列は、上記で作成したサービス名前空間 (Service Namespace) ごとに異なっており、使用するキャッシュごとに単一のサービス名前空間のみを指定することになります。つまり、Windows Azure caching では、この「サービス名前空間」の中の具体的な実装 (スケール アウトされるか、スケール アップされるか、など) はブラックボックスとなっていて、開発者は、このサービス名前空間に必要なキャパシティ (サイズ) を設定 (変更) すれば、あとは、すべてを Azure プラットフォームが構成してくれるようになっています。

では、Web アプリケーションの開発を進めましょう。

Default.aspx に、ラベル (名前を Label1 とします) とボタン (名前を Button1 とします) を張り付け、ボタンのクリック イベントとして、以下を実装します。
このコードでは、Foo のキーを持つアイテムを取得し、もしアイテムがなければ、「test」という値を持ったアイテムがキャッシュ (キー Foo) に設定されます。そして、2 回目以降からは、このアイテムが取得されて、ラベル (Label1) には「test」と表示されます。(つまり、最初は「test (new!)」と表示され、2 回目以降から「test」と表示されます。)

. . .using Microsoft.ApplicationServer.Caching;. . .protected void Button1_Click(object sender, EventArgs e){var factory = new DataCacheFactory();var cache = factory.GetDefaultCache();var test = cache.Get("Foo");if (test == null){cache.Add("Foo", "test");test = "test (new !)";}Label1.Text = (string)test;}

補足 : 実際の開発では、上記のように、ボタンが押されるたびにファクトリー (DataCacheFactory) の作成を毎回おこなうことは避けたほうが良いでしょう。(オーバーヘッドの原因となります。static 変数などを使用して、保持しておくと良いでしょう。) 上記は、処理を理解してもらうためのサンプル コードとして記載しています。

あとは、いつもの通り、このクラウド アプリケーションを配置します。(今回も、いきなり Production Deplyment をおこなってしまいましょう…)
Visual Studio のソリューション エクスプローラーで、Windows Azure プロジェクトを右クリックして [発行] を選択し、表示されるダイアログ ボックスで、[Create Service Package Only] (下図) を選択します。

サービス構成ファイル (.cscfg) とサービス パッケージ ファイル (.cspkg) が作成されるので、これらのファイルを、Windows Azure 管理ポータルを使って、ホステッド サービス (Hosted Service) にアップロード (配置) します。

動作結果は、説明の必要はないでしょう。ラベルには、最初にボタンを押したときだけ「test (new !)」と表示され、以降では「test」と表示されます。

この内容はキャッシュ サービスに保持されているため、この Azure プロジェクトのインスタンスを止めても、Azure プロジェクトを削除 (再配置) しても、キャッシュのデータはしばらく残っていることが確認できます。

Windows Server AppFabric cache との相違点 (機能差)

以前 も記載しましたが、Windows Azure caching では、現在 (2011年07月) のところ、Region、Tag、HA オプションなどは使用できません。また、これに伴って、いくつかの API も制限されているので注意してください。(API としては含まれていますが、使用できないようになっています。)
制限されている API については、以下が参考になります。

[MSDN] API Reference (Windows Azure Caching) :
http://msdn.microsoft.com/en-us/library/gg278350.aspx

また、上記で見たように、ホストの概念や、認証の概念なども Windows Server AppFabric cache とは異なっているので注意してください。

また、Windows Azure cache における もう 1 つのペイン ポイントとして、管理系のコマンドの多くが使えないという点です。そもそも、Windows Server AppFabric caching のように Windows PowerShell を使った管理ができません。このため、キャッシュの停止・開始などの操作や、キャッシュ内の状況確認のコマンド (Get-CacheStatistics コマンドなど) を実行することもできません。
代わりに、Windows Azure cache では、Windows Azure 管理ポータルを使って、サービス名前空間で使用されているサイズ (下図) や、過去のピーク サイズなどを確認できます。

以下に、Windows Server AppFabric cache と Windows Azure cache の機能比較を一覧にしておきます。

補足 : 各機能の詳細については、以前投稿した「AppFabric cache : A to Z」を参照してください。

補足 : 逆に、リリースが後だったこともあり、Windows Azure cache のほうが充実している面も多少あります。例えば、Velocity を使った ASP.NET の出力キャッシュ (Output cache) については、Windows Server AppFabric cache ではサンプル コードが提供されていただけでしたが、Windows Azure cache では専用のクラスが既定で提供されています。(ASP.NET Session については、双方共に、専用のクラスが提供されています。)

現時点では、Windows Server AppFabric cache も Windows Azure cache もバージョン 1 であり、今後も cache は進化を続けます。今後の進化に取り残されないよう、まずは、現時点の機能をおさえておきましょう。