Azure 上における最新の Redis Cache サービスについては「Azure Redis Cache の使用 (.NET, PHP, Node.js)」に記載しました。(以下の投稿は、古い記事です。)

環境 : Windows Server 2008 R2, Visual Studio 2010 (.NET Framework 4, SQL Server 2008 SP1), Windows Server AppFabric version 1.1 CTP (August 2011)

関連ナンバー

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

こんにちは。

出遅れた報告ですみません。ご存知の方も多いかと思いますが、今月中旬に、Windows Server AppFabric version 1.1 CTP 版がダウンロード センターで公開されました。バージョンは 1.1 とマイナー バージョン アップですが、このバージョンには、Caching 関連で Watch しておくべき機能が実装されています。
以下では、この新しく出た Version 1.1 の Cache の新機能について確認してみたいと思います。

なお、下記は CTP 版をもとに軽く動かしただけです。まだ仕様詳細などは変更される可能性がありますので、ご注意ください。(Release 版が出てきたら、内容を更新しておきます。)

補足 : また、バージョン 1.1 では、Windows Server AppFabric のフォルダーが、%windir%\system32\AppFabric から %programfiles%\Windows Server AppFabric に変更されています。dll の場所なども、すべてこのフォルダーに変更されていますので注意してください。

補足 : 以前、こちら にも記載しましたが、念のため、Windows Azure AppFabric SDK と一緒に使用しないでください。

Read Through / Write Behind

この機能が、今回のアップデートの目玉となる機能です。(以前、こちら でも軽くふれた待望の Cache Through 機能です。)

例えば、Windows Server AppFabric Cache (Velocity) をデータベース アクセスを高速化するための手段として使用する場合など、これまでの AppFabric cache では大きな問題がありました。なぜなら、AppFabric cache が提供するキャッシュ上のデータは、その存在が保証されていないためです。(つまり、常に揮発的です。以前 こちら でも述べたように、LRU のアルゴリズムなどに従って、メモリ上からデータが退避される可能性があります。)
無論、こうしたデータのロスト (Lost) を防ぐために、さらに開発者自身で抽象化をおこない、毎回、アプリケーション側でデータベースに一緒に書き込んでおくことも可能でしょう。しかし、パフォーマンス上の観点から見れば、それならデータベースだけを使っておけば良いという結論にもなってしまうことでしょう。(無論、検索性能は重視されると思いますが。)

こうした実装を容易にする仕組みが、この Read Through / Write Behind の機能です。特に Write については、パフォーマンスを考慮して、キャッシュ クライアントとは非同期に (キャッシュに対する操作とは別に、バックグラウンドで) 処理するようになっていて、こうした点を「Behind」と表現しています。

使い方の大まかな手順は、以下の通りです。

1. DataCacheStoreProvider クラスを継承した専用のプロバイダーを実装します。(SQL Server に保存するプロバイダー、Oracle に保存するプロバイダーなど、用途に応じて dll を構築します。)
2. サーバー上の GAC に dll を登録します。
3. キャッシュ作成 / 変更 (new-cache, set-cacheconfig) のコマンドを使って、上記のプロバイダーをキャッシュに登録します。

まず、プロバイダーを実装してみましょう。

Visual Studio 2010 で、ターゲット フレームワークを .NET Framework 4 として、[クラス ライブラリ] のプロジェクトを新規作成します。なお、このあと GAC に登録するため、プロジェクトに署名を添付しておきましょう。また、Microsoft.ApplicationServer.Caching.Core.dll のアセンブリ参照を追加します。

DataCacheStoreProvider を継承した独自なプロバイダーを実装 (プログラミング) しますが、他の .NET プロバイダーと比べて、フレームワークは非常に簡単 (単純) です。下記の override メソッドが用意されているため、これらを実装すれば OK です。(下記は、CTP 版での実装です。シンタックスなどは Release 版で変更される可能性もあるので注意してください。)

補足 : なお、このプロバイダーのライフサイクルですが、クラスター内のホストが起動するたびに、このプロバイダー インスタンスが初期化されて開始されます。(各ホストごとに実行されます。)

. . .using Microsoft.ApplicationServer.Caching;. . .public class SQLTestProvider : DataCacheStoreProvider{  public override DataCacheItem Read(DataCacheItemKey key){}  public override void Read(ReadOnlyCollection<DataCacheItemKey> keys,    IDictionary<DataCacheItemKey, DataCacheItem> items){}  public override void Write(DataCacheItem item){}  public override void Write(IDictionary<DataCacheItemKey, DataCacheItem> items){}  public override void Delete(DataCacheItemKey key){}  public override void Delete(Collection<DataCacheItemKey> keys){}  protected override void Dispose(bool disposing){}}

Read、Write、Delete があり、それぞれについて、単一のキー (DataCacheItemKey) を処理するメソッドと、キーのコレクション (または Dictionary) を処理するメソッドの 2 種類があります。ここで、開発者の方は、単一アイテムの処理 (Get/Add/Put/Remove) の際は、単一の DataCacheItemKey を引数に持つメソッドが呼ばれると思われるかもしれませんが、どうもそうではないようなので、コレクションを引数に持つメソッドのほうも確実に実装しておいてください。(単一アイテムに対する処理でも、Dictionary を引数に持つほうが呼ばれます。また、Write Behind の場合、複数のアイテムが引数としてまとめて渡される場合もあります。)

では、このカスタム プロバイダーを実装してみましょう。(今回は、SQLTestProvider というクラス名にしておきます。)
まず、コンストラクター (Constructor) を必ず実装しておいてください。コンストラクターによって、使用しているキャッシュの名前や、初期化パラメーターなどを取得して、その後の処理で使用できます。(特に、キャッシュの名前は、キャッシュ アイテムを新規作成する際などに必ず必要になります。)

. . .public class SQLTestProvider : DataCacheStoreProvider{  private string ThisCacheName;  public SQLTestProvider(string cachename, Dictionary<string, string> config)  {    this.ThisCacheName = cachename;  }. . .

つぎに、Read を実装してみましょう。
Read は、キャッシュ クライアント側から　Get (Bulk での Get や、Tag による検索時なども含む) をおこない、かつ、そのアイテムがキャッシュにヒットしなかった場合に、同期的に呼び出されます。つまり、この Read メソッドの処理が完了するまで、クライアント側は待たされます。(このため、Read メソッドの内部で例外が発生すると、呼び出し元のキャッシュ クライアントにも例外が伝播されます。)
Read メソッドの中で、そのキーの値をデータベースなどに問い合わせをおこない、結果を return することで、その return されたキャッシュ アイテムがキャッシュ クラスター (メモリー) に保管され、呼び出し元のキャッシュ クライアントから見ると、まるでキャッシュ アイテムがヒットしたかのように値が返ってきます。

. . .public class SQLTestProvider : DataCacheStoreProvider{  private string ThisCacheName;  . . .  public override DataCacheItem Read(DataCacheItemKey key)  {    object searchedValue = null;    DataCacheItem resItem;    // get data (searchedValue) from database using key.Key    skip code . . .    if (searchedValue == null)  // if not found      resItem = null;    else  // if found      resItem = DataCacheItemFactory.GetCacheItem(        key,        this.ThisCacheName,        searchedValue,        null);    return resItem;  }  public override void Read(ReadOnlyCollection<DataCacheItemKey> keys,    IDictionary<DataCacheItemKey, DataCacheItem> items)  {    foreach (var key in keys)    {      object searchedValue = null;      // get data (searchedValue) from database using key.Key      skip code . . .      if (searchedValue == null)  // if not found        items[key] = null;      else  // if found        items[key] = DataCacheItemFactory.GetCacheItem(          key,          this.ThisCacheName,          searchedValue,          null);      }  }  . . .

補足 : なお、Read メソッドで、該当のデータが存在しなかった場合には、上記の通り、null を返しておくと良いでしょう。こうしておくことで、キャッシュ クライアント側で Get などを呼び出した際に、ちゃんと null が返されるようになります。もし、Read で値を何も設定しないと例外 (値が返されなかったというエラー) が発生します。また、下記の通り null の値を持った DataCacheItem を返すようにすると、キャッシュ上に、null の値が設定されたキャッシュ アイテムが作成されてしまいます。
DataCacheItemFactory.GetCacheItem(. . ., null, null);

つぎに、キャッシュ アイテムが Add された際に呼ばれる Write メソッドを実装してみましょう。
前述の通り、Write は、Read とは異なり、クライアントの呼び出しとは独立して、バックグラウンドで処理されます。このため、Write の処理で例外 (エラー) が発生しても、キャッシュ クライアントにその例外は伝播されません。

. . .public class SQLTestProvider : DataCacheStoreProvider{  private string ThisCacheName;  . . .  public override void Write(DataCacheItem item)  {    // add and update database using item.Key, item.Value    skip code . . .  }  public override void Write(IDictionary<DataCacheItemKey, DataCacheItem> items)  {    foreach (var key in items.Keys)    {      // add and update database using key.Key, items[key].Value      skip code . . .      items.Remove(key);  // Success !    }  }  . . .

Write の処理では、処理成功の際に、上述の通り、Dictionary のアイテムを削除 (Remove) しておくようにしてください。この処理をおこなわないと、そのアイテムは Write に失敗したとみなされ、リトライ (Retry) の対象となってしまいます。

なお、この Write メソッドは、アイテムの Add (追加) の際だけでなく、Put (変更) の際も呼び出されますので、実際には、アイテムの変更時の処理もプログラミングしておきましょう。

以降、ここでは説明を省略しますが、同様に、Delete オーバーライド メソッドは、キャッシュ クライアントが、明示的に、キャッシュ アイテムの Remove を呼んだときに呼び出されます。(Eviction / Expiration によるキャッシュ アイテムの削除では呼び出されません。) この呼び出しも、Write behind と同じインターバルの後で (バックグラウンドで) 呼び出され、後述する Retry も有効です。

また、例外発生時は、DataCacheStoreException を投げるようにプログラミングしておきましょう。

コードの作成が完了したら、キャッシュ サービス (サーバー) の各ホスト上で、Visual Studio コマンド プロンプトを管理者権限で実行して、以下のコマンドを実行します。(無論、インストーラーなどで配って頂いても OK です。)
なお、このプロバイダーは、必ず、キャッシュを使用するすべてのホスト上にインストールしておいてください。(ログなどで確認してもらうとわかりますが、必要なプロバイダーなどが見つけらないと、そもそもホストの起動に失敗します。)

gacutil /i MyTestProviderLib.dll

最後に、Windows PowerShell (こちら を参照) を使って、キャッシュ作成 / 変更 (new-cache, set-cacheconfig) のコマンドを実行する際に、上記のプロバイダーをキャッシュに登録します。
下記を見ていただいておわかりの通り、ProviderType オプションにカスタム プロバイダーの厳密名を設定し、ReadThroughEnabled オプション、WriteBehindEnabled オプションを true にすることで、そのキャッシュで、カスタム プロバイダーを使った Read Through / Write Behind が有効になります。

New-Cache -CacheName HogeHoge  -WriteBehindEnabled true  -WriteBehindInterval 60  -ReadThroughEnabled true  -ProviderType "MyTestProviderLib.SQLTestProvider, MyTestProviderLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=151ae8c35d91e85c"  -WriteBehindRetryInterval 60  -WriteBehindRetryCount 5

上記で WriteBehindInterval オプションは、書き込み (Write) の遅延時間 (秒) を設定します。この値ですが、60 以上の値 (つまり、1 分以上) を設定する必要があるので注意してください。(既定値は 300 秒です。)
WriteBehindRetryCount オプション、WriteBehindRetryInterval オプションは、それぞれ、Write / Delete が Fail した場合のリトライ回数と、リトライの間隔 (秒) を設定します。なお、WriteBehindRetryCount オプションを -1 (既定値) に設定すると、キャッシュ サービスが起動している間、無限にリトライを繰り返します。
また、上記では使用していませんが、ProviderSettings オプションを使用して、プロバイダー (のコンストラクター) に、実行時の初期値 (パラメーター) を渡すこともできます。

以上が、簡単な Read Through / Write Behind の使い方ですが、いくつか注意すべき点があります。

まず、今回のプロバイダーに限ったことではありませんが (他の .NET のプロバイダーでも同様ですが)、品質特性にあわせた実装 (例えば、同時接続の際の制御、ログ、リカバリー実装、など) については、プロバイダーの開発者が責任をもって実装する必要があります。
特に、上述の通り、最速で 60 秒の書き込みの遅延が発生しますので、この呼び出しまでの間でトラブルが発生する可能性は充分に考えられ、トラブルが発生した場合は、処理がロスト (Lost) してしまいます。そして、やっかいなのは、プロバイダー開発者にはこの間の処理を制御する方法はないという点です。(プロバイダーが呼ばれてから先の処理は記述できますが …) 以前 説明した HA オプション などを組み合わせることで、ある程度のコンテンジェンシー シナリオを保証することはできます。しかし、キャッシュ アイテムが更新されてからプロバイダーに到達するまでの処理とリカバリーを確実なものにしたい場合には、別の仕組み (独自なリカバリー設計) が必要となるので注意してください。

また、プロバイダーのデバッグもコツが必要になるので注意してください。(これも同じく、すべてのプロバイダー開発に共通することですが . . .)
上記のカスタム プロバイダーをデバッグする場合は、Visual Studio の [プロセスにアタッチ] を使用して、DistributedCacheService.exe のサービスにアタッチしてデバッグします。(この際、どのホストが呼ばれるか保証できないため、最初は単一ホストのみを動作させて開発とデバッグをおこない、完成したら、クラスター上のすべてのホストに展開して動作確認をおこなうと良いでしょう。)
また、コードを修正して配置した際は、このサービス (DistributedCacheService.exe) の再起動 (restart-cachecluster など) も確実におこなってください。

なお、残念ながら、現時点では、DataCacheStoreProvider クラスから派生された標準のプロバイダーは存在しない模様です。いつもなら SQL Server 用のプロバイダーなどが提供されるところですが、今回の場合は Key-Value なので、マッピング定義もユーザー側で定義する必要があるためでしょう . . . (また、リリース版が出てきたら Watch してみましょう . . .)

ドメイン アカウントを使用したサービスの起動

キャッシュ サービス (Windows のサービスです) をドメイン アカウントで動作させることが可能になりました。
些細な機能追加のように見えますが、ミラーを構成している場合など、運用上のさまざまな構成に対して、統一のユーザーを使用することで、より柔軟に対処できるようになっています。(カスタマー フィードバックを元に実装された機能です。)

設定方法は簡単です。
ドメインに参加しているホスト (マシン) で AppFabric の構成画面を起動した際に、[Caching Service] の構成時に、下図の [変更] (Change) ボタンを押して、ドメイン ユーザーを設定できます。(以前は、ドメインに参加している場合、このボタンを押すことはできず、そのマシンの Network Service のユーザーでしか動作させることができませんでした。)
もちろん、PowerShell を使って構成することも可能です。

補足 : ドメイン ユーザーをサービスとして動かす場合には、グループ ポリシーを使って、そのユーザーにサービスとして動かすための権限を付与してください。ドメイン コントローラーのマシンに管理者としてログインし、mmc を起動して [グループ ポリシー オブジェクト エディター] のスナップインを追加し、ツリーから、[ローカル コンピューター ポリシー] – [コンピューターの構成] – [Windows の設定] – [セキュリティーの設定] – [ローカル ポリシー] – [ユーザー権利の割り当て] を選択して、[サービスとしてログオン] に該当のドメイン ユーザーを追加します。
(なお、ローカル ユーザーの場合は、[管理ツール] – [ローカル セキュリティ ポリシー] を選択し、表示されるローカル セキュリティ ポリシーの画面で、[ローカル ポリシー] – [ユーザー権利の割り当て] の [サービスとしてログオン] に該当のユーザーを追加します。)
また、構成データベース (SQL Server) へ、このユーザーの権限も、忘れず付与しておいてください。(AppFabric cache の構成によって、このセキュリティ設定が変更される場合があるので、特に注意してください。)

補足 : なお、CTP 版で試しに検証してみようと思いましたが、SSPI のエラーが出てきてしまうみたいです。リリース版 (または、つぎのベータ) を待ちたいと思います。

データの圧縮 (Compression)

下記 (太字) の通り、圧縮用のオプションを指定することで、データは、ネットワーク転送前にクライアント側で圧縮され、ネットワーク上に転送されて (圧縮された形で) キャッシュ サーバーのメモリー上に保存されます。

. . .<dataCacheClient isCompressionEnabled="true">  <hosts>  <host name="machine1" cachePort="22233" />  <host name="machine2" cachePort="22233" />  </hosts></dataCacheClient>. . .

特に長い文字列などを設定して、Get-CacheStatistics コマンド (こちら を参照) でサイズを確認すると、非常に効率的に圧縮されていることが確認できます。
このパラメーターを指定することによるパフォーマンスが気になる方も多いかと思いますので、現実の開発では、入念なテストを実施して判断してください。(Get については、あまり大きなパフォーマンス オーバーヘッドはない模様ですが、実際に試してみてください。)

なお、この圧縮オプションは、下記の ASP.NET Session State Provider、ASP.NET Output Cache Provider (アプリケーション レイヤー) でも使用できます。

アプリケーション レイヤーの進化

ご存じの通り、Windows Server AppFabric Caching (v 1.0) のリリース後に Windows Azure Caching がリリースされたという経緯もあり、AppFabric Cache を使った ASP.NET Session State Provider や ASP.NET Output Cache Provider などのアプリケーションは、Windows Server AppFabric と Windows Azure で事情が異なっていました。
このバージョンでは、これらの機能の最新版が統一的に含まれています。(この v1.1 で、Windows Server AppFabric Caching にも、ASP.NET Output Cache Provider が標準実装されています。)

特に、Session State プロバイダーの使い方には注意してください。(内部的な動きを理解して、上手に利用してください。)

以前、Tech Ed では、Microsoft.ApplicationServer.Caching.DataCacheSessionStoreProvider のセッション プロバイダーを使用しましたが、このバージョン (v 1.1) では、Windows Azure Caching に入っていた Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider の最新版が含まれています。(互換性に配慮し、以前のプロバイダーも残っていますが、できるだけ、この新しい DistributedCacheSessionStateStoreProvider クラスを使用してください。)
このため、まず、使用するアセンブリ、クラスも、この新しいものを使用してください。(下記に、web.config への構成例を記載します。)

. . .<configSections>  <section name="dataCacheClient"    type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/></configSections><dataCacheClient>  <hosts>  <host name="machine1" cachePort="22233" />  <host name="machine2" cachePort="22233" />  </hosts></dataCacheClient><system.web>  <compilation debug="true" targetFramework="4.0" />  <sessionState mode="Custom" customProvider="MyVelocity">  <providers>    <add name="MyVelocity"      type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"      cacheName="SessionTest"      useBlobMode="true"/>  </providers>  </sessionState>  . . .

AppFabric Cache から見た場合、同じセッション ID の複数アイテムが、同一のキャッシュ アイテム (1 つのキャッシュ アイテム) に格納されます。
そして、上記の useBlobMode の設定 (true / false) によって、キャッシュ内でのデータの持ち方が変わります。useBlobMode=true の場合、セッション データは、Key の配列、値の配列として、アイテム内に保持されます。一方、useBlobMode=false の場合、System.Collections.Generic.List の Key-Value の一覧をアイテム内に保持します。このため、データ量や、アクセス方法などによってチューニングをおこない、適切なレイアウトのセッションを選択してください。

補足 : useBlobMode の既定値は true です。

なお、Windows Azure Caching では、useBlobMode=false がサポートされていませんでしたが (未実装でしたが)、このバージョンでは可能になっています。これに伴って、下記の通り、useBlobMode が false のときだけ有効な、nonInlinedAdditionalLifetime、inlinedKeys、maxInlinedStringLength の各プロパティも使用可能になっています。

[MSDN] Configuration Settings for the ASP.NET 4 Caching Sessions State Provider (Windows Server AppFabric v1.1)
http://msdn.microsoft.com/en-us/library/hh361700.aspx

また、以前、DataCacheSessionStoreProvider (以前のプロバイダー) を使用したデモで、sharedId というプロパティを使ってセッション情報を共有するデモを紹介しましたが、新しい Session State Provider (DistributedCacheSessionStateStoreProvider) でもこれと同じものが使えます。通常、セッションの情報は、キャッシュ サービス上では、アプリケーション名とセッション ID をキーとして保存されるため、アプリケーションをまたがってセッションの情報を共有できませんが、下記の通り applicationName を明示的に指定することで、サイト内のアプリケーションどうしでセッションの情報を共有できます。

. . .<sessionState mode="Custom" customProvider="MyVelocity">  <providers>  <add name="MyVelocity"    type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"    cacheName="SessionTest"    useBlobMode="true"    applicationName="testshare"/>  </providers></sessionState>. . .

補足 : それでも、セッション ID が使用されるため、サイト (ドメイン) をまたがって共有することはできませんので、注意してください。

また、操作ログをとっていただくと分かりますが、この Session State を使ってデータを取得すると、既定では、内部で GetAndLock (こちら を参照) を使用してキャッシュ データが取得されるので注意してください。(Session では、Activity Data のような種類のデータが扱われることが想定されています。) この動作を Get に変更するには、ReadOnly の Session State を使用します (下記)。これにより、複数の Read、単一の Write の間で、コンカレントなセッション データへのアクセスが可能になります。

<%@ Page . . . EnableSessionState="ReadOnly" %>. . .

複数の dataCacheClient 要素の指定

これ、何げに、イケてる新機能です。
上述の dataCacheClient 要素 (セクション) のサンプルを見てお分かりの通り、従来は、構成ファイル (.config) に dataCacheClient 要素を 1 つだけしか定義できませんでした。(無論、host は、複数指定できます。) 今回から、dataCacheClients という要素が使用可能で、この中に複数の dataCacheClient 要素を指定して、用途に応じて使いわけることができます。
例えば、ローカル キャッシュ (Local Cache) を使用する場合としない場合、圧縮 (isCompressionEnabled) を使用する場合としない場合などを、構成ファイル (.config) の定義によって使い分けることができます。

実際に使用する際は、構成 (.config) の書き方に注意してください。下記の通り、新しい <dataCacheClients /> を使用するため、configSection も以下の通り変更が必要になります。
また、従来、既定の dataCacheClient では name 属性は省略可能でしたが、下記の通り、既定の場合にも「name=”default”」と明示しておいてください。

<?xml version="1.0"?><configuration>  <configSections>    <!--      Attention : dataCacheClient -> dataCacheClients, DataCacheClientSection -> DataCacheClientsSection    -->    <section      name="dataCacheClients"      type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>  </configSections>  <dataCacheClients>    <dataCacheClient name="default">      <hosts>        <host name="machine1" cachePort="22233"/>        <host name="machine2" cachePort="22233"/>      </hosts>    </dataCacheClient>    <dataCacheClient name="CompressedClient" isCompressionEnabled="true">      <hosts>        <host name="machine1" cachePort="22233"/>        <host name="machine2" cachePort="22233"/>      </hosts>    </dataCacheClient>  </dataCacheClients>  <startup>    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>  </startup></configuration>

使用する際は、以下の通り記載します。

. . .// when you use the upper (name="default")var factory = new DataCacheFactory();var cache = factory.GetCache("HogeHoge");. . .// when you use the lower (name="CompressedClient")var config = new DataCacheFactoryConfiguration("CompressedClient");var factory = new DataCacheFactory(config);var cache = factory.GetCache("HogeHoge");. . .

また、SessionState で使用する際は、下記の通り、プロバイダーに dataCacheClientName 属性を指定します。

. . .<sessionState mode="Custom" customProvider="MyVelocity">  <providers>  <add name="MyVelocity"    type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"    dataCacheClientName="CompressedClient"    cacheName="SessionTest"    useBlobMode="true"/>  </providers></sessionState>. . .

Graceful Shutdown

ホストを停止する Stop-CacheHost コマンドに Graceful オプションを使用することで、アイテムをロスト (Lost) せずにホストを停止できる機能です。

例えば、今、machine1、machine2 の 2 台のマシンでキャッシュ クラスターが構成されていると仮定します。下記の通り、machine1 にアイテムが存在しています。

PS C:> Get-CacheStatistics -Hostname machine1 -CachePort 22233Size      : 2048ItemCount     : 1RegionCount   : 1NamedCacheCount : 2RequestCount  : 10MissCount     : 1PS C:> Get-CacheStatistics -Hostname machine2 -CachePort 22233Size      : 0ItemCount     : 0RegionCount   : 0NamedCacheCount : 2RequestCount  : 0MissCount     : 0

ここで、下記の通り、Graceful オプションを付与して、アイテムが存在している machine1 を停止します。

PS C:> Stop-CacheHost -HostName machine1 -CachePort 22233 -GracefulHostName : CachePort    Service Name      Service Status Version Info--------------------    ------------      -------------- ------------machine1.example.jp:22233 AppFabricCachingService SHUTTING DOWN  3 [3,3][3,3]

すると、machine1 にあったアイテムは machine2 に移動し、引き続き、アプリケーションでは、このアイテムを使用できます。

PS C:> Get-CacheStatistics -Hostname machine2 -CachePort 22233Size      : 2048ItemCount     : 1RegionCount   : 1NamedCacheCount : 2RequestCount  : 0MissCount     : 0