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

環境 :
Windows Azure Caching Preview – June 2012
Windows Azure SDK for .NET – June 2012

関連ナンバー

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

こんにちは。しばらくブログをさぼっており、すみません。

先週は うちの 0 歳の息子の初めての誕生日だったのですが、月曜から 1 週間近く熱を出し、夫婦で看病の毎日でした。さらに、週末にお祝いをしてあげたかったのですが、今度は、私が病をもらって寝込んでしまいました。
残念です。。。近いうちに、是非、盛大に祝ってあげたいと思います。

さて、これまで、Caching の新機能をずっと紹介してきた経緯から、今回の Windows Azure Caching Preview (June 2012) についても紹介しないといけませんね。どこかどう変わったのか、気になる方も多いことでしょう。
そこで、今回は、この新しい Caching のどんな点が改善されたか、実際のコードを使って紹介したいと思います。(1 週間以上動かしておらず忘れてしまいそうなので、備忘のためにも、頑張って記載しておきます。。。)

Windows Azure Role-based Caching – 新しいアーキテクチャと その利用手順

まず、新しい Windows Azure Caching (Preview) は Windows Azure Role-based Caching と呼ばれるもので、従来の Windows Azure Caching のように専用のサービスとしてホストされるのではなく、開発者が作成する Windows Azure の Role (Web Role, Worker Role) の中で実行されます。
このため、新しい Caching では、分割するインスタンスの数や、ノードに割り当てるメモリ容量など、より細かなカスタマイズが可能で、かつ、後述するように、柔軟な管理が可能となっています。(今までの Windows Azure Caching では、多くは、black box でした。)

この Role-based Caching は、さらに、下記の 2 つに分類されます。

• Co-located Role caching
  Web Role などアプリケーションを実行している各インスタンスと同居して動作するキャッシュ (クラスター) です。Role 内に、キャッシュ用のメモリ領域を確保し、キャッシュ クラスターは、そのロールの各インスタンスに分散されます。
• Dedicated Role caching
  キャッシュ専用の Role として実行します。このため、必然的に、Worker Role になります。(作成方法は、Role の追加の際に、[Cache Worker Role] を選択します。) この方法では、上記と異なり、Cache だけ独立して Scale out させることが可能です。

Dedicated Role の Cache を構成して、他の Service から接続する構成も考えられますが、現時点では、Azure の Virtual Machine (Persistent VM) などからは接続できないようなので注意してください。(おそらく、Security 上の理由からでしょう。)

また、先日、日本で開催された GoAzure のイベントで エバンジェリスト 野村が説明していたように、パフォーマンスは、従来の Windows Azure Caching の約 4 倍速いそうです。(Tech Ed US のセッションでも、そのように紹介されていました。すみません、私自身、まだ検証してませんが。) このため、後述する機能面での改善や、パフォーマンス改善など多くの理由により、これから Windows Azure Caching を使用する方は、できるだけ、この新しい Cache を使用したほうが良いでしょう。
なお、従来の Windows Azure Caching v1.0 (専用のキャッシュ サービスとして実装されていた Caching) は、Windows Azure Shared Caching という名称で今後も継続してサポートされますので安心してください。(プログラミング上の概念も変わっていないので、移行も容易だと思います。)

では、実際に、構成手順を見ながら、これまでとどう違っているのか確認してみたいと思います。(プログラミング方法などは これまでの Cache の利用方法 と同じですが、構成方法が異なるので、以下に、その点を強調して記載します。)

まず、Cache Cluster (複数 Node の Cache Server 群) を構成するには、以降の通り設定します。今回は、Web Role を複数インスタンス起動し、Co-located Role として構成してみます。

June 2012 の Windows Azure SDK を使って Windows Azure のプロジェクトを作成し、追加した Web Role のプロパティ画面を開くと、[Caching] という名前のタブが表示されるので、このタブを選択し、下図の通り、[Enable Caching] を選択します。
さらに、この画面で、[Co-located role] を選択します。Role の中で、Cache に割り当てるメモリ量 (Percentage) なども、下図の通り、設定できます。

また、Windows Azure に配置する前に、Storage Account を作成して、上図の通り、この Account と Key を設定しておいてください。
以前も記載しましたが (「Windows Server AppFabric Cache の入門」を参照)、こうした Storage やデータベースには、キャッシュ データが入るのではなく、Cluster の構成情報 (Cache Cluster Configuration) が保持され、各ノード (インスタンス) から参照されます。

あと、上図を見ていただくとわかりますが、この画面を使って、名前付き Cache (Named Cache) の作成も可能です。(Windows Server 版の AppFabric Cache だと、new-cache コマンド に相当します。なお、作成しない場合は default cache のみとなります。)

また、念のため、Instance の Size も Medium 以上に設定しておきましょう。

つぎに、Cache を使用するクライアントに、必要な dll を参照追加します。今回は、上記の Web Role のプロジェクトそのものがクライアントなので、以降は、Web Role のプロジェクトに対して設定をおこないます。
Web Role のプロジェクトで、NuGet を使って、下図の Microsoft.WindowsAzure.Caching (Windows Azure Caching Preview) をインストールすることで、必要な dll (Microsoft.ApplicationServer.Caching.Core.dll、Microsoft.ApplicationServer.Caching.Client.dll、Microsoft.ApplicationServer.Caching.AzureCommon.dll、Microsoft.ApplicationServer.Caching.AzureClientHelper.dll、Microsoft.Web.DistributedCache.dll、Microsoft.WindowsFabric.Common.dll、Microsoft.WindowsFabric.Data.Common.dll) の参照追加と、構成 (Web.config) の変更がおこなわれます。

なお、Windows Azure SDK for .NET June 2012 をインストールした環境では、これらの dll は、%programfiles%\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\ref\CachingPreview に入っています。(ただし、最新バージョンとは限らないので、上記の手順でインストールしたほうが無難でしょう。)
Web Role プロジェクトの Web.config を開くと、下記の通り設定がおこなわれます。

. . .<configSections>  . . .  <section name="dataCacheClients"type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection,  Microsoft.ApplicationServer.Caching.Core"allowLocation="true"allowDefinition="Everywhere" /></configSections>. . .<dataCacheClients>  <tracing sinkType="DiagnosticSink" traceLevel="Error" />  <dataCacheClient name="default"><autoDiscover isEnabled="true" identifier="MvcWebRole1" />  </dataCacheClient></dataCacheClients>. . .

上記の Web.config を見ていただくとわかりますが、Windows Server AppFabric Cache (オンプレミスの Cache) と異なり、<autoDiscover /> が設定されている点に注意してください。Windows Azure の Role-based Caching では、サーバーの物理的な名称や Cache のポートなどを指定せず、この <autoDiscover /> によって、cache が実行されている Role instance の cluster に接続をおこないます。
なお、identifier 属性には、Cache が実行されている Role の名前、すなわち、今回の場合は Web Role 自身の名前を設定してください。(今回は「MvcWebRole1」と仮定します。)
もちろん、Local cache なども構成できます。

上記で Cache cluster の構成と、必要なクライアントの設定が完了しました。つぎに、クライアント側のプログラミングをおこない、この Cache を使用します。

Cache の利用方法は、これまでとまったく変わりません。(「Windows Server AppFabric cache 入門」を参照。)
下記は、ASP.NET MVC で、Cache データの更新 (追加、変更) と取得を実装したサンプル コードです。(もちろん、文字列だけでなく、.NET のオブジェクトなどもキャッシュ可能です。) なお、以前も記載したように、DataCacheFactory や DataCache の再作成 (new) はオーバーヘッドとなるので、下記のように、static 変数 (インメモリー) などに設定しておくと良いでしょう。(また、Factory を、毎回、再作成すると、Local Cache も扱えなくなります。)

. . .using Microsoft.ApplicationServer.Caching;. . .public class TestController : Controller{  private static DataCache _mycache = null;  internal DataCache MyCache  {get{  if(_mycache == null)  {var factory = new DataCacheFactory();_mycache = factory.GetDefaultCache();  }  return _mycache;}  }  public ActionResult Add(string key, string value)  {MyCache.Add(key, value);return View();  }  public ActionResult Update(string key, string value)  {MyCache.Put(key, value);return View();  }  public ActionResult Get(string key)  {string result = (string)MyCache.Get(key);ViewBag.Result = result;return View();  }}

なお、今回から、Factory を使用せず、下記の通り記述することもできます。(この場合も、実は内部で DataCacheFactory が使用されていますが、この Factory は毎回生成されず、内部の static な領域に保持されています。)

// no need for Factory_mycache = new DataCache("default");

また、Default Cache の場合には、下記のように、引数を省略して記述することもできます。

_mycache = new DataCache();

Windows Azure Role-based caching では、前述の通り、開発者自らが作成する Role でクラスターが実行されるため、管理もやりやすくなっています。
例えば、Windows Azure に配置をおこなって、Remote Desktop でインスタンスに接続すると、オンプレミスの Cache (Windows Server AppFabric Cache) と同様、Cache 専用の Windows サービスが動作しているのがわかります。(下図)
このため、ノードを停止して動きを確認するなど、Fault の検証などもすぐ行えます。

また、Emulator によるローカルのデバッグ環境もサポートされています。(Asure SDK の %programfiles%\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\bin\plugins に、サーバー側のバイナリーが含まれています。)

機能制限の大幅な改善

新しい Windows Azure caching (Role-based caching) の利点は、構成面の改善だけではありません。

これまでの Windows Azure Caching の Pain point を 2 つあげるとすれば、Server AppFabric cache と比べて 機能が大きく制限されている点と、管理がしづらい (Windows PowerShell が使えない) という点でしょう。特に前者は、Tag が使用できないため、実システムで利用を検討されていて、この理由で採用を見送ったところも多かったことでしょう。(「検索」に相当する機能がほとんど使えないからです。)
今回の Role-based caching から、Region と Tag は勿論、通知 (Notification)、HA (High Availavility) など、これまで Windows Azure Cache で不可能であった機能のほとんどがサポートされるようになりました。

なお、これらの使い方 (サンプル コードなど) については、以前、「AppFabric Caching A to Z」に記載していますので、参考にしてください。(Caching 自体がバージョン アップしているため、いくつかコードの変更が必要かもしれませんが。)

Notification (通知)、HA などを構成する場合、Windows Server AppFabric Caching では、Windows PowerShell などを使用しましたが、Windows Azure Caching (Role-based caching) では、プロジェクトの Role のプロパティ画面を使って、下図の通り設定できます。(下図の「Backup Copies」に、HA で使用する Secondary のコピー数を設定します。これらの設定の多くは、.cscfg ファイルに設定されます。)

なお、Local Cache、Session State、Output Cache などは、今回も使用可能です。

Memcache protocol のサポート

さらに、新しい Caching では、memcache protocol に対応しています。以降で、簡単に確認してみましょう。

Windows Azure Caching (Role-based Caching) は、既定では、memache protocol を listen していません。
まず、下図の通り、Role に、memcache_<cache name> という名前の Internal Endpoint を構成します。この名前の Endpoint を作成すると、インスタンスで memcache protocol の listen をおこなうようになります。

Endpoint の構成をおこなって Windows Azure に配置したら、試しに、Remote Desktop でインスタンスに接続し、telnet などで下記の通り確認してみてください。(下記で、白文字が入力で、緑の文字が出力です。Windows Azure インスタンスには、Telnet クライアントがインストールされています。)
ちゃんと、memcache protocol の仕様に沿って対話可能であることが確認できますね。なお、binary と text の双方の memcache protocol に対応しています。

telnet localhost 11211set test1 0 300 9testvalueSTOREDget test1VALUE test1 0 9testvalueEND

このため、memcache protocol のクライアントを使って、Windows Azure Caching の処理を呼び出すことができます。例えば、著名な EnyimMemcached を使用してみましょう。

まず、NuGet を使って、smarx が作成した Windows Azure 用の EnyimMemcached client (WazMemcachedClient) をプロジェクトにインストールします。(このライブラリーでは、Role 名から RoleEnvironment クラスを用いてインスタンスの一覧を取得し、取得した各インスタンスから Endpoint 名を使用して IPEndPoint を取得して、必要なホストとポートに接続しています。ご自身でこうしたコードが書ける方は、NuGet から EnyimMemcached client だけインストールして、皆さん自身でコードを書いても構いません。)

上記で作成した TestController の処理を、今度は、下記の通り、EnyimMemcached を使って記述しなおしてみましょう。
この場合も、さきほどと同様に動作することが確認できます。

. . .using Enyim.Caching;. . .private static MemcachedClient _enyimCl = null;internal MemcachedClient EnyimCl{  get  {_enyimCl = _enyimCl ??  WindowsAzureMemcachedHelpers.CreateDefaultClient("MvcWebRole1", "memcache_default");return _enyimCl;  }}public ActionResult Add(string key, string value){  EnyimCl.Store(Enyim.Caching.Memcached.StoreMode.Add, key, value);  return View();}public ActionResult Get(string key){  string result = (string) EnyimCl.Get(key);  ViewBag.Result = result;  return View();}. . .

補足 : ちなみに、詳しく調べてませんが、Enyim cache client API で入れたデータを Windows Azure caching API (Client Api) で取得すると、例外が発生します。(その逆も同様です。)
おそらく、最終的に登録されるデータの型などが異なっているためと思われます。(時間があったら、ちゃんと調べてみます。)

なお、今回、サーバー側で、memcache protocol の listen をおこなうよう構成しましたが、クライアント側で要求を変換する方法も使えます。これをおこなうには、NuGet の Microsoft.WindowsAzure.Caching.MemcacheShim のパッケージを使用します。(Microsoft.ApplicationServer.Caching.MemcacheShim.dll は、Windows Azure SDK がインストールされたマシンの %programfiles%\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\ref\CachingPreview にも入っています。)

memcache protocol support は非常に強力な武器となります。例えば、既存の memcached を使用したプロジェクトの移行に使えますし、あるいは、敢えて 上記のような作り方をしておき、チューニングとパフォーマンス結果に応じてベースのインフラ (Memcached, or Windows Azure caching) を変更するなど、さまざまなシナリオで活用できます。

管理と Monitoring (監視)

上述の通り、今回 (Windows Azure Role-based caching) から black box ではなくなり、より管理しやすくなっていますが、これまで同様、Diagnostics でのトレースやパフォーマンス カウンターの収集が必要であるという点は同じです。(現 Preview 段階でも、Windows PowerShell による管理や統計結果の表示などは提供されていません。)

しかし、Cache サーバーが Role インスタンス上で動作しているためサーバーの監視も容易で、かつ、Windows Azure ポータル (Windows Azure Preview Management Portal) が新しくなり、Windows 標準の Performance Counter 同様の Monitoring も可能です。

例えば、クラスター上の各ホスト (ロールのインスタンス) に登録されているアイテムの数を Monitoring する場合、Role プロジェクトの OnStart に下記の通り追加します。(下記では、Diagnostic の構成を変更しています。この構成情報は、Azure Blob Storage 上に <deployment guid>/<role name>/<instance name> の名前で保存されます。)
なお、今回は、Realtime Monitoring の場合ですが、Log Monitoring の場合は、トレースの設定なども影響してくると思いますので、注意してください。

. . .using Microsoft.ApplicationServer.Caching.AzureCommon;. . .public override bool OnStart(){  DiagnosticMonitorConfiguration conf =DiagnosticMonitor.GetDefaultInitialConfiguration();  conf.PerformanceCounters.ScheduledTransferPeriod =TimeSpan.FromMinutes(1D);  conf.PerformanceCounters.BufferQuotaInMB = 512;  conf.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration(){  CounterSpecifier = @"AppFabric Caching:HostTotal Object Count",  SampleRate = TimeSpan.FromSeconds(30D)});  DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", conf);  return base.OnStart();}

このプロジェクトを Windows Azure に配置後、新しい Windows Azure Portal (Windows Azure Preview Portal) で [Configure] をクリックし、Level を Verbose に変更します。

Windows Azure Portal で [Monitor] をクリックし、[Add Metrix] をクリックすると、下図の通り、上記のコードで追加した Performance Counter を選択できます。

あとは、新しい Windows Azure Portal を使って、下図の通り、現在の状況を Monitoring できます。(インスタンスごとの状態だけでなく、全体の傾向なども確認できます。)

補足 : Agent への反映の時間や、定期的に収集をおこなっている関係から、タイムラグはあります。なお、収集した Raw データは、Azure Table Storage の WADPerformanceCountersTable という名前のテーブルに格納されています。(Azure Storage Explorer などで確認してみてください。)

Performance counter として、Total Requests (Total Read Requests、Total Write Operations)、Total Data Size Bytes などの基本的な Counter はもちろん、Total Cache Misses、Total GetAndLock Requests、Total Successful GetAndLock Requests など、細かな Counter も使用できます。このため、キャッシュ ヒット率の統計データの作成など、柔軟な管理と監視が可能です。

なお、使用できる Metric の一覧は下記に記載されていますので、参考にしてください。

[MSDN] Monitoring Windows Azure Caching (Preview)
http://msdn.microsoft.com/en-us/library/windowsazure/jj136940

機能比較

ということで、この Preview 段階での Windows Azure Caching (Role-based caching の場合) と Windows Server AppFabric Cache の比較を表にまとめると、下記の通りになります。(セキュリティについては、Server caching と Azure caching で考え方が異なるため、単純比較はやめました。)
もう、Windows Azure caching は、見劣りしなくなってきましたね。