Windows Server AppFabric キャッシュ処理容量計画ガイド
Jason Roth、Rama Ramani、Jaime Alva Bravo
2011 年 3 月
このホワイト ペーパーでは、Windows Server AppFabric キャッシュの処理容量を計画するためのガイダンスを示します。
はじめに
AppFabric キャッシュのパフォーマンスの評価
処理容量の計画の方法
手順 1: ボトルネックを把握してキャッシュの対象を識別する
手順 2: 現在の作業負荷のパターンを評価する
手順 3: 物理的なインフラストラクチャとハードウェア リソースを理解する
手順 4: すべてのアプリケーションで必要なパフォーマンス SLA を確定する
手順 5: 適切な AppFabric の機能および構成の設定を識別する
処理容量計画ツール
処理容量計画の次の手順
継続的なキャッシュの処理容量の要件の監視
はじめに
Windows Server AppFabric キャッシュ機能は、分散型のインメモリ キャッシュ クラスターを提供します。このホワイト ペーパーでは、Windows Server AppFabric キャッシュの内部設置型の展開において処理容量を計画する際のガイダンスを示します。
Windows Server AppFabric キャッシュのアーキテクチャについては、ドキュメントで詳しく説明されています。詳細については、「Windows Server AppFabric のキャッシュ機能」を参照してください。簡単に言うと、AppFabric キャッシュ クラスターは、1 つまたは複数のキャッシュ サーバー (キャッシュ ホストとも呼ばれる) で構成されています。キャッシュはキャッシュ ホストに分散され、メモリ内に格納されます。
ヒント
クラウド環境でキャッシュを使用するための Windows Azure AppFabric キャッシュも存在しています。このドキュメントで説明されている、メモリ要件の見積もりに関する手順の一部は、クラウドベースのソリューションにも適用されますが、このドキュメントでは内部設置型のキャッシュ クラスターのシナリオに重点を置いて説明しています。Azure AppFabric キャッシュ機能の使用の詳細については、「Windows Azure AppFabric キャッシュ (英語の可能性あり)」を参照してください。
このドキュメントの内容は、マイクロソフトがユーザーと共に進めてきた計画作業に基づいています。AppFabric キャッシュを使用するユーザーから、"自分のシナリオでは何台のサーバーが必要か" という質問がよく寄せられます。このような説明では、多くの場合、最初の典型的な回答は "状況によって異なる" というものです。次に、さまざまな詳細を迅速に検討して、最終的に適切なシステム構成のたたき台ができあがります。このプロセスにおいて、次のような、より具体的な質問が出てきます。
使用するアプリケーションでどれくらいの容量のキャッシュ メモリが必要であるか。
キャッシュ クラスターで何台のコンピューターを使用すればよいか。
各コンピューターにどれくらいの容量のメモリが必要であるか、どのようにメモリを構成すればよいか。
ネットワークの帯域幅がキャッシュ クラスターのパフォーマンスにどのように影響するか。
このホワイト ペーパーの目標は、このようなユーザーとの考察から学んだ教訓をまとめて、処理容量の計画に利用できる方法として提供することです。
このドキュメントを読んでいるユーザーは、次のいずれかの開発フェーズで作業をしていると考えられます。
分散キャッシュについて検討を始めたばかりで、作業負荷の構成、パフォーマンスの要件、またはサーバーの展開トポロジについての詳細データがまだない段階。この時点では、まず AppFabric キャッシュのパフォーマンス データを調べることから始めます。
または、AppFabric キャッシュの機能とパフォーマンスについて既に調査を進めている段階。この場合は、具体的なシナリオと詳細な要件を深く検討するための手助けが必要になります。この段階で、処理容量の計画の具体的な作業に入ります。
また、既に運用段階に入っている場合も考えられます。この段階では、パフォーマンス データを分析して、処理容量が十分であることを確認する必要があります。さらに、AppFabric キャッシュの実行時の動作に基づいて、主な指標とベスト プラクティスを把握し、将来の作業負荷の増大への対応を計画することも必要です。
このホワイト ペーパーは、これらのフェーズを時系列的に説明するように構成されています。AppFabric のパフォーマンスを評価している場合は、マイクロソフト パートナーである Grid Dynamics が作成した総合的なホワイト ペーパーを一読することをお勧めします。ここでは、評価作業を容易にし、処理容量の計画プロセスを説明するために、このホワイト ペーパーのデータをわかりやすくグループ化しています。
処理容量の計画プロセスを実行する準備ができている場合は、ユーザーのシナリオに適用できる手法を形式化するための手順を示します。
キャッシュ クラスターを使用またはテストしている場合は、主なパフォーマンス評価指数を調べて処理容量が適切であることを確認して、処理容量の計画プロセスを検証できます。さらに、ベスト プラクティスについても説明します。
AppFabric キャッシュのパフォーマンスの評価
マイクロソフト パートナーである Grid Dynamics では、最近、AppFabric キャッシュのパフォーマンスに対する一連のテストを完了しました。テストの結果は、ホワイト ペーパー「Windows Server AppFabric キャッシュ: 詳細なパフォーマンスおよびスケーラビリティに関するデータシート (英語の可能性あり)」にまとめられています。
各テストでは、キャッシュのサイズやキャッシュ クラスター内のサーバー数などの特定の変数に重点を置いています。Grid Dynamics の調査結果を使用して、AppFabric のキャッシュ機能のパフォーマンスとスケーラビリティを評価できます。スループットと遅延の数値を、ユーザーのアプリケーション要件を満たす幅広いテスト シナリオおよびトポロジで比較することができます。通常、各テストでは、パラメーターのパフォーマンスへの影響に注目するために、1 つまたは 2 つのパラメーターのみを変化させます。全パラメーターの一覧を以下に示します。
負荷のパターン |
キャッシュの使用パターン、つまり 'Get'、'Put'、'BulkGet'、'GetAndLock'、'PutAndUnlock' の各操作のパーセンテージ |
キャッシュされたデータ サイズ |
テスト中にキャッシュに格納されたデータの量 |
クラスター サイズ |
キャッシュ クラスター内のサーバーの数 |
オブジェクト サイズ |
キャッシュ内に格納されている、シリアル化後のオブジェクトのサイズ |
型の複雑さ |
キャッシュ内に格納される byte、string[] などのさまざまな .NET オブジェクト型 |
セキュリティ |
キャッシュ クラスターのセキュリティ設定 |
AppFabric のキャッシュ機能のパフォーマンスとスケーラビリティを検証することに加えて、Grid Dynamics では、ユーザーが独自のデータと作業付加でテストを繰り返すことができるようにするテスト ハーネスを提供しています。これも、ユーザーの特定のシナリオでキャッシュ機能のパフォーマンスを評価するための選択肢の 1 つです。
この調査全体とその結果に目を通すことを強くお勧めしますが、ここでは、後で説明するベスト プラクティスにつながる調査結果のいくつかの概要を示します。
AppFabric のキャッシュ機能は、キャッシュ クラスターに追加されるコンピューター数に比例して拡張されます。
書き込みの割合が大きい、大容量のキャッシュを除いて、キャッシュ サイズの影響は大きくはありません。さまざまな要因の中で特に、書き込みの作業負荷が大きいことは、マネージ ヒープ サイズが大きい場合に .NET ガベージ コレクションに対する影響が増大します。
型が複雑であることは、シリアル化のためにクライアント側のパフォーマンスにのみ影響します。
一括取得の呼び出しによって、ネットワークの使用効率は向上します。Direct Cache Access はプロキシ (ASP.NET、WCF) よりも高速ですが、これはキャッシュ機能のパフォーマンスではなく、中間層のパフォーマンスによるものです。
ペシミスティック ロックとオプティミスティック ロックのパフォーマンスは同等なので、アプリケーション設計に最適な手法を使用してください。競合が発生する比率が小さいほど、遅延とスループットの値はいずれも向上します。
キャッシュ クラスターのセキュリティによってパフォーマンスが低下することはなく、既定では有効になっています。セキュリティを無効にすると、スループットは最大になり、遅延は最小になりますが、このような設定はデータの機密性やビジネスの要件によって受け入れられない可能性があります。
アプリケーション サーバーとキャッシュ サーバーの間で専用のネットワークを使用することによって、ネットワークのボトルネックは削減されます。
Grid Dynamics のホワイト ペーパーは、AppFabric のキャッシュ機能の評価を開始するための最適なたたき台であると同時に、処理容量の計画プロセスで使用できる生のデータや検出されたパターンも含まれています。
処理容量の計画の方法
アプリケーションで AppFabric のキャッシュ機能のような分散型のインメモリ キャッシュのメリットがあることがわかったら、処理容量の計画段階に入ります。一部の処理容量計画の手順は、AppFabric キャッシュ クラスターに対して直接テストを行うことによって実行できますが、このようなテストを行わずに見積もりを作成するよう求められる場合があります。ここでは、このような状況について説明します。以下の手順では、AppFabric のキャッシュ機能の要件を体系的に検討するための方法を示します。
ボトルネックを把握してキャッシュの対象を識別する
現在の作業負荷のパターンを評価する
物理的なインフラストラクチャとハードウェア リソースを理解する
すべてのアプリケーションで必要なパフォーマンス SLA を確定する
適切な AppFabric の機能および構成の設定を識別する
このドキュメントでは、オンライン ストア アプリケーションのサンプルのニーズを探ることによって、これらの手順の例を示します。ただし、キャッシュ機能はあらゆる種類の .NET アプリケーションで使用できるので、複数のアプリケーションが同じキャッシュ クラスターにアクセスしている場合があります。このようなシナリオでは、各アプリケーションについて以下の手順を実行し、結果を集計することによって、処理容量の正確な見積もりを算出する必要があります。
手順 1: ボトルネックを把握してキャッシュの対象を識別する
最初に、キャッシュに保存するデータを識別します。そのためには、SQL Server プロファイラー、パフォーマンス モニター、Visual Studio テストなどのパフォーマンス分析ツールを使用します。これらのツールによって、頻繁にアクセスされるデータベース オブジェクトや、Web サービスに対する時間のかかる呼び出しを識別することができます。これらのバックエンド ストアから返されるデータ セットは、キャッシュの潜在的な候補となります。このようなデータを一時的にキャッシュに格納することによって、パフォーマンスが向上し、バックエンド データ ストアに対する影響が緩和されます。
潜在的なキャッシュの候補を識別したら、そのオブジェクトをアクティビティ データ、参照データ、リソース データ の 3 つの大きなカテゴリのいずれかに分類しておくと便利です。これらについて例を挙げて詳しく説明します。
アクティビティ データには、個々のユーザーに関連する読み書き可能なデータが含まれます。たとえば、オンライン ストアでは、ユーザーのショッピング カーとがアクティビティ データになります。このデータはユーザーの現在のセッションに適用され、頻繁に変更される可能性があります。ショッピング カートについて高可用性を維持することは重要ですが、ショッピング カートのデータは常にバックエンド データベースに永続的に保存することが必要になるわけではありません。その一時的な特性によって、アクティビティ データはキャッシュ機能の候補として適しています。
参照データは、複数のユーザーまたは複数のアプリケーション インスタンスによって共有される、読み取り専用データです。参照データは、頻繁にアクセスされますが、変更されることはまれです。たとえば、オンライン ストアの例では、商品カタログが参照データになります。カタログは 1 日以上有効ですが、複数のユーザーによって何千回もアクセスされる可能性があります。この種類のデータも、キャッシュ機能の候補として適しています。何らかの種類のキャッシュ機能がなければ、商品カタログを見るユーザーはそれぞれデータベースのデータにアクセスすることが必要になります。キャッシュを使用することによって、ほぼ静的なデータに対して反復される要求がバックエンド データベースに及ぼす影響を緩和できます。その永続的な特性によって、参照データもキャッシュ機能の候補として適しています。
リソース データは、ユーザー間で共有される読み書き可能なデータです。たとえば、サポート フォーラムにはこの種類のデータが含まれています。すべてのユーザーは、フォーラムの投稿に対する返信を読むことができます。
キャッシュされるデータの種類によって使用パターンが異なるので、データをこれらのカテゴリに分類しておくと便利です。たとえば、オブジェクトを参照データとして識別することによって、読み取り専用の作業負荷であることが自動的にわかります。この分類は有効期限ポリシーを決定する場合にも役に立ちます。頻繁に変更されるデータほど有効期限は短くなります。開発では、このような論理的な区分によって、コードでカプセル化できる領域が示されます。
個々のオブジェクトについて見積もりを作成した後、そのデータを集計することをお勧めします。次の表は、この段階で収集された情報の例です。
| キャッシュするオブジェクト | キャッシュのカテゴリ | 永続的な記憶域の場所 |
|---|---|---|
ショッピング カート オブジェクト |
アクティビティ データ |
なし |
ユーザー設定オブジェクト |
アクティビティ データ |
バックエンド データベース |
商品カタログ |
参照データ |
バックエンド データベース |
ユーザー フォーラムのスレッド |
リソース データ |
バックエンド データベース |
キャッシュの候補となるデータを識別するときに、各カテゴリでキャッシュするデータを見つける必要はありません。アプリケーションのショッピング カートをキャッシュするだけで、パフォーマンスおよびスケーラビリティを向上させることができる場合があります。この手順で重要な点は、利用可能な情報を使用してキャッシュに最適な項目を識別することです。
手順 2: 現在の作業負荷のパターンを評価する
キャッシュに適したデータを特定したら、次に、現在のアプリケーションによるデータへのアクセス方法および関連する作業負荷のパターンを理解する必要があります。この手順の最後には、キャッシュ機能のメモリの要件について、生の見積もりを得ることができます。また、データがどのようにアクセスおよび使用されているかについて理解を深めることができます。これは、後の手順で重要になります。
たとえば、商品カタログをキャッシュの候補として考えている場合、アプリケーションがいつ商品カタログを取得しているか、およびこれらの要求が発生する頻度を調べる必要があります。前の手順に基づいて、商品カタログは参照データであることがわかっているので、主に読み取り専用の作業負荷になります。さまざまなオブジェクトについて作業負荷のパターンを十分に理解しておくことが、後で処理容量を決定する際の指針となります。それでは、この手順の内容を詳しく見ていくことにしましょう。
現在のデータ アクセスのパターンをより深く理解するには、いくつかの方法があります。
コード全体を詳しく調べて、どこでデータがアクセスされているか、およびデータ アクセスの頻度を確認します。
メソッド呼び出しの頻度および関連するパフォーマンス データを提供できるコード プロファイラーを使用します。
コード内の特定のデータ アクセス セクションにインストルメンテーションを作成し、データ アクセスの試行および関連するデータ操作のパフォーマンスをログに記録します。
SQL Server プロファイラーなどのデータベース プロファイラーを使用して、データベース操作の回数と継続時間を調べます。
これらの手法の多くは、前の手順でキャッシュ機能の対象となるデータを決定するために使用することができます。ただし、現在の段階では、後の処理容量の計画に使用できる、より詳細な数値を求める必要があります。
この評価の一環として、書き込みに対する読み取りの比率を理解する必要があります。読み書き可能な作業負荷は、後の処理容量に関する決定に影響する場合があります。たとえば、書き込みの割合が大きい作業負荷では、.NET ガベージ コレクションがトリガーされることが多くなります。これについては後の手順で説明します。
もう 1 つの要因は、負荷のピーク時における読み取りと書き込みの頻度です。次の表に、ショッピング カート オブジェクトの例について、この段階で収集されたサンプル データを示します。
分析するオブジェクト |
ショッピング カート |
読み取り % |
50% |
書き込み % |
50% |
読み取り操作数/秒 (最大) |
250 |
書き込み操作数/秒 (最大) |
250 |
ここでも、各種オブジェクトについて同じ分析を実行する必要があります。オブジェクトの種類ごとに、アクセス パターンおよび作業負荷の下での 1 秒あたりの最大読み取り数と書き込み数が決まります。
キャッシュ機能の要件を把握するには、特定の時点におけるキャッシュ内の各種オブジェクトについて、アクティブ オブジェクトの最大数の見積もりが必要です。この見積もりでは、オブジェクト挿入の頻度とオブジェクトの予測保持期間とのバランスをとる必要があります。このことを例を使って説明します。
ASP.NET Web アプリケーションの例で、運用データを見ると、ピーク時に 25,000 人の同時接続ユーザーがいるとします。ユーザーごとにセッションの状態情報が必要であるため、キャッシュされるオブジェクトは 25,000 個になります。ただし、このようなオブジェクトの有効期間を 30 分間に設定することができます。ピーク時の運用データを見ると、1 時間あたりの新規ユーザーは 5,000 人です。つまり、30 分間の有効期間に、2,500 人の新規ユーザーが増加する可能性があります。さらに、一部のユーザーはブラウザーを終了して、新しいセッションを開始する場合があります。この場合、ユーザーは同じですが、異なるセッションを使用しています。このような場合を考慮して見積もりに余裕を持たせる必要があります。最後に、今後 6 ～ 12 か月間の予測成長を計画に含める必要があります。最終的には、キャッシュ内のアクティブ オブジェクトの最大数の計算は次のようになります。
分析するオブジェクト: |
ショッピング カート |
ピーク時の同時接続ユーザー数 |
25000 |
有効期間 (30 分) 内の新規ユーザー数 |
2500 |
新規ブラウザー セッションを開始する既存ユーザー数 |
250 |
将来の成長予測 (25%) |
6940 |
合計アクティブ オブジェクト数 (最大): |
最大アクティブ オブジェクト 35,000 個 |
有効期間などの入力値に変更があった場合、負荷のピーク時にキャッシュ内に存在する、有効期限が切れていないオブジェクトの数も変化します。これは単なる思考プロセスの例です。オブジェクトの種類によって、パターンも、計算に使用される変数も異なります。たとえば、共有される商品カタログが丸 1 日間有効である場合、その日のキャッシュ内の商品カタログ オブジェクトの最大数は 1 にする必要があります。
ただし、キャッシュ内の最大オブジェクト数が役に立つのは、平均オブジェクト サイズもわかっている場合のみです。これは、本質的に難しい問題です。ショッピング カートの例では、あるユーザーがカートに入れるアイテムは 1 つでも、別のユーザーは 10 個または 20 個のアイテムをカートに入れる場合があります。目標は平均値を把握することです。このプロセスの多くの数値と同様に完璧な値はありませんが、最終的な結果は単純な推測ではなく、ユーザーのキャッシュ クラスターについてよく考えられたたたき台になります。
オブジェクトはシリアル化された形式でキャッシュ内に格納されます。このため、平均オブジェクト サイズを求めるには、シリアル化されたオブジェクトの平均サイズを計算する必要があります。AppFabric では、アイテムをキャッシュ内に格納する前に、NetDataContractSerializer クラスを使用してシリアル化を行います。平均オブジェクト サイズを特定するには、オブジェクトをシリアル化し、シリアル化されたオブジェクトのサイズを記録するインストルメンテーション コードをアプリケーションに追加します。
次のコード例では、単一オブジェクトの平均サイズを予測しようとしています。シリアル化されるオブジェクトの名前は obj です。length 変数を使用して長さを記録しています。NetDataContractSerializer によるサイズの取得に問題がある場合は、代わりに BinaryFormatter を使用します。簡単に使用できるように、これをメソッド内にラップすることができます。その場合、obj はパラメーターとして渡され、メソッドから length が返されます。
// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;
MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer =
XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
NetDataContractSerializer serializer = new NetDataContractSerializer();
serializer.WriteObject(writer, obj);
length = stream1.Length;
}
if (length == 0)
{
MemoryStream stream2 = new MemoryStream();
BinaryFormatter bf = new BinaryFormatter();
bf.Serialize(stream2, obj);
length = stream2.Length;
}
ヒント
テスト用のキャッシュ クラスターをセットアップしている場合は、キャッシュにアイテムを追加し、Windows PowerShell の Get-CacheStatistics コマンドを使用して、キャッシュに追加された 1 つまたは複数のオブジェクトのサイズを検出します。または、キャッシュ内の複数のオブジェクトのサイズを、キャッシュ内のオブジェクト数で除算する方法もあります。コードとテストのどちらによって見積もりを収集するかを選択できます。
セッション状態について AppFabric のキャッシュ機能を使用することを計画している場合は、ASP.NET セッション状態用の SQL Server プロバイダーが常に NetDataContractSerializer ではなく、BinaryFormatter を使用することを理解しておく必要があります。場合によって、NetDataContractSerializer クラスによってシリアル化されたオブジェクトは、BinaryFormatter を使用するオブジェクトのシリアル化されたサイズの数倍大きくなる場合があります。SQL Server でセッション状態オブジェクトのサイズに注目している場合、そのサイズを使用することができず、キャッシュ内でも同じサイズであると見なすことができないので、これが重要になります。このサイズを 6 倍することによって、大まかな見積もりを得ることができます。見積もりの精度を向上させるには、セッション状態で格納されたオブジェクトについて、前に示したコードを使用してください。これまでに収集されたデータを使用して、合計メモリの要件の策定を開始できます。この手順には、以下のサブタスクが含まれます。
オブジェクトの種類 (ショッピング カート オブジェクトなど) に注目します。
そのオブジェクトについて、シリアル化されたオブジェクトの平均サイズを算出します。
次に、キャッシュのオーバーヘッドを考慮して、平均サイズに 500 バイトを加えます。
このサイズに、アクティブ オブジェクトの最大数を乗算します。これによって、そのオブジェクトの種類について、合計キャッシュ メモリの要件が求められます。
内部キャッシュ構造の場合は、見積もりのオーバーヘッド (5%) を追加します。
識別された各オブジェクトの種類について、この手順を繰り返します。
合計キャッシュ メモリの要件の結果を集計します。
このプロセスでは、オブジェクトごとに約 0.5 KB のオーバーヘッドがあり、サイズの見積もりに加算する必要があることに注意してください。また、キャッシュ内のメモリを必要するその他の内部データ構造もあります。リージョン、タグ、および通知はすべて、追加のメモリ管理が必要になります。前に示した計算例では、これらの内部構造を考慮するために合計に 5% を加算していますが、これらのキャッシュ機能をどの程度利用するかに応じてパーセンテージを増減することができます。
この時点では、特定の AppFabric キャッシュ機能 (高可用性) の影響を考慮する必要があります。この機能は、セカンダリ サーバーに、キャッシュされたアイテムのコピーを作成します。つまり、1 台のキャッシュ サーバーが停止しても、セカンダリ キャッシュ サーバーが処理を引き継ぐのでデータは失われません。高可用性を使用することを選択した場合は、メモリの見積もりを 2 倍にする必要があります。また、Windows Server 2008 Enterprise Edition 以上を使用することも必要です。高可用性機能は、名前付きキャッシュのレベルで設定する必要があります。つまり、仮に同じクラスターで 2 つの名前付きキャッシュを作成する場合、必ずしも各キャッシュで高可用性を使用する必要はないことを意味します。アプリケーションでは、あるアイテムを高可用性を使用する名前付きキャッシュに格納し、別のアイテムを高可用性を使用しないキャッシュに格納することができます。これによって、メモリ リソースを最大限に活用できます。高可用性を使用するキャッシュではメモリの要件が 2 倍になるので、高可用性に関する決定を理解しておくことが重要です。
例として、同じアプリケーションでアクティビティ データと参照データの要件を評価している表を示します。シナリオによって、この見積もりをオブジェクト レベルで行うか、アプリケーション レベルで行うかを選択できます。この例に列を追加して、適切なラベルを付けることもできます。
分析するオブジェクト: |
アクティビティ データ |
参照データ |
シリアル化されたオブジェクトの平均サイズ: |
250 KB |
60 KB |
オブジェクトごとのキャッシュ クラスターのオーバーヘッド: |
0.5 KB |
0.5 KB |
シリアル化されたオブジェクトの調整された平均サイズ: |
250.5 KB |
60.5 KB |
最大アクティブ オブジェクト数: |
~35000 |
~68000 |
キャッシュのメモリ要件: |
8.4 GB |
3.9 GB |
高可用性が有効であるか? |
16.8 GB |
いいえ |
内部データ構造のオーバーヘッド (5%): |
0.8 GB |
0.2 GB |
合計メモリ要件: |
17.6 GB |
4.1 GB |
これらの見積もりを集計したものが、キャッシュ クラスターの内部メモリの要件になります。この例では、合計は 21.7 GB です。この見積もりを使用することにより、物理的なインフラストラクチャ、SLA 要件、AppFabric のキャッシュ構成の設定など、その他の考慮事項を検討できるようになります。
手順 3: 物理的なインフラストラクチャとハードウェア リソースを理解する
物理的なインフラストラクチャとリソースの可用性を理解することが重要です。ここで、よくある質問を挙げてみます。
物理コンピューターまたは仮想マシンをプロビジョニングすることができますか。
既存のハードウェアがある場合、コンピューターの構成はどのようなっていますか (8 GB RAM、クアッド コアなど)。
キャッシュ クラスターはアプリケーション サーバーと同じデータセンター内に設置されますか。
ネットワーク機能はどのようになっていますか。
キャッシュ クラスターとして仮想マシンを使用することを検討している場合、いくつかの考慮事項があります。たとえば、同一の物理コンピューターで複数の仮想マシンを実行する際の影響を検討する必要があります。複数の仮想マシンで同じネットワーク カードを共有することができますが、ネットワークのボトルネックになる可能性が大きくなります。また、同一の物理コンピューター上で、仮想マシンであるプライマリ キャッシュ ホストとセカンダリ キャッシュ ホストとの間で、高可用性をセットアップすることができます。この物理コンピューターが停止すした場合、データのコピーは残りません。詳細については、「仮想マシンで AppFabric Cache を実行する場合のガイダンス (英語の可能性あり)」を参照してください。
既存のコンピューターの場合、推奨される仕様はありません。ただし、大規模なキャッシュ クラスターの場合、16 GB の RAM、クアッド コアを搭載したコンピューターで問題なく機能するようです。一般的に、適切な物理メモリの容量とネットワークの負荷を計画することは、最も重要な考慮事項です。
物理コンピューターと仮想マシンの両方について、キャッシュを使用するアプリケーション サーバーや Web サーバーに対するキャッシュ クラスターの場所をメモしておいてください。キャッシュ クラスターとアプリケーション サーバーまたは Web サーバーが別のデータセンターにある場合は、データセンター間の遅延がパフォーマンスに悪影響を及ぼさないことを確認します。この段階において、アプリケーション サーバーや Web サーバーをキャッシュ サーバーとして使用したいと考えるかもしれません。可能ではありますが、これはサポートされていません。まず、これらのコンピューター上の IIS などのサービスによって、リソースの使用が急激に増加するとキャッシュ クラスターに影響を及ぼす可能性があります。2 つ目として、キャッシュ サービスは専用のサーバーで運用されていることを前提としており、潜在的に、ユーザーが指定した値よりも多くのメモリを使用する可能性があります。
ネットワーク機能については、予想されるネットワーク負荷を評価し、それをインフラストラクチャと比較します。最初に、各キャッシュ サーバーで処理することが予測されているデータの量と、ネットワーク カードの機能が十分であるかどうかを知る必要があります。十分でなければ、より多くのキャッシュ サーバーが必要になる可能性があります。たとえば、キャッシュされたオブジェクトの平均サイズが 500.5 KB であり、キャッシュ クラスター上で 1 秒間に 240 件の操作が実行されているシナリオを考えてみます。単一のキャッシュ ホストが使用されている場合、結果は次のようになります。
1 秒あたりのオブジェクトの読み書きの回数: |
240 |
キャッシュ クラスター内のコンピューターの数: |
1 |
コンピューター 1 台あたり、1 秒あたりのキャッシュ操作の回数: |
240 |
平均オブジェクト サイズ: |
500.5 KB |
1 秒あたりの転送データのサイズ: |
240 * 500.5 = 117.3 MBps |
各コンピューターに 1Gbps のネットワーク カードが搭載されている場合、最大スループットは約 119 MBps になります。計算された値 117.3 MBps は、1 台のコンピューターでは荷が重過ぎる可能性があります。これにより、ネットワークがボトルネックとなる可能性がさらに増加します。ただし、キャッシュ クラスター内で 3 台のコンピューターが使用されている場合は、キャッシュ要求を均等に分散させることにより、各サーバーの負荷は 1/3 になります。
キャッシュ クラスターにアクセスするアプリケーション サーバーのネットワーク使用率も検討します。アプリケーション サーバーが他のシステムと大量のデータをやり取りしている場合は、アプリケーション サーバーとキャッシュ クラスターとの間に専用のネットワークを作成することを検討してください。そのためには、この目的専用のネットワーク カードを各アプリケーション サーバーに追加する必要があります。
最終的なネットワークの考慮事項は、ネットワークがパス全体にわたって必要な負荷を処理できるかどうかということです。各キャッシュ サーバーに 1Gbps のネットワーク カードを搭載するだけでは十分ではありません。ネットワーク上のスイッチおよびその他のポイントでも、負荷を処理できる必要があります。この要件を満たすように運用を調整します。
手順 4: すべてのアプリケーションで必要なパフォーマンス SLA を確定する
最終的な構成を決定する前に、パフォーマンスや信頼性のサービス レベル アグリーメント (SLA) など、ビジネスの要件についても理解しておく必要があります。実践的な意味では、この手順はキャッシュ クラスターの数および各クラスター内のキャッシュ ホストの数の決定に影響します。
たとえば、キャッシュ クラスターを使用するミッションクリティカル アプリケーションがある場合、そのキャッシュ クラスターを、優先順位が低い他のアプリケーションから分離したいと考える可能性があります。このような優先順位の低いアプリケーションがより多くのメモリ、ネットワーク、または CPU リソースを使用すると、ミッションクリティカル アプリケーションに悪影響を及ぼします。
このような決定に影響する具体的な要因を以下に示します。
セキュリティはキャッシュ クラスター レベルで維持されます。ユーザーがキャッシュ クラスターに対してアクセス権を持つ場合、そのユーザーは潜在的にキャッシュ クラスター上のすべてのデータにアクセスできます (ユーザーがキャッシュ名と要求するキーを知っている場合)。データの種類ごとに異なるセキュリティ設定が必要な場合は、キャッシュ クラスターを分割することも検討してください。詳細については、「セキュリティの管理」を参照してください。
メモリが高基準値に達すると、有効期限が切れていないアイテムが削除されます。1 つのキャッシュに必要なメモリの容量を低く見積もると、クラスターのすべてのキャッシュに影響する場合があります。メモリ不足によって削除が行われるときには、メモリ不足が 1 つのキャッシュのみで発生している場合でも、すべてのキャッシュで削除が実行されます。この問題は、削除できないキャッシュを作成することによって、ある程度緩和することができますが、この作業は注意して行う必要があります。詳細については、「有効期限と削除」を参照してください。
キャッシュ クラスターをある程度分割することによって、管理が容易になる場合があります。100 個の異なるキャッシュ用に個別のクラスターを管理することはしたくないでしょうが、キャッシュ クラスターを 2 つの大きなキャッシュ用に分割すると便利な場合があります。キャッシュ クラスターを個別に管理、拡張、および監視できるからです。
最後に、遅延とスループットの考慮事項を含む要件がいくつかあります。この決定を行うためのガイダンスとテスト結果については、Grid Dynamics のホワイト ペーパーを参照してください。たとえば、キャッシュ クラスターのスループットの要件を、Grid Dynamics のホワイト ペーパーで公開されているテスト結果と比較できます。Grid Dynamics の調査結果によって、スループットの目標に対して、サーバー数が極端に少ないことがわかる可能性があります。この調査結果が、ユーザーのオブジェクトの種類、オブジェクトのサイズ、物理インフラストラクチャおよび論理インフラストラクチャに性格に一致していない可能性もあることを認識しておく必要があります。ただし、その場合でも、情報に基づく意思決定に役立つ、実証済みのテスト結果を得ることができます。
手順 5: 適切な AppFabric の機能および構成の設定を識別する
プロセスのこの部分では、AppFabric キャッシュ機能の具体的な構成設定および AppFabric キャッシュ クラスターのアーキテクチャを検討します。正しい実験データとビジネス データをすべて収集しても、これらの AppFabric のキャッシュ設定を無視すると、適切な計画を行えない場合があります。
次の表に、さまざまな AppFabric のキャッシュ機能および関連する処理容量の考慮事項を示します。
複数のリージョンを作成できますが、各リージョンは 1 つのキャッシュ ホスト上に存在します。分散型キャッシュを活用するには、アプリケーションで複数のリージョンを使用する必要があります。リージョンを指定しないすべての呼び出しでは、自動的に内部の既定のリージョンが使用されます。キャッシュ クラスター内の各キャッシュ ホストは、最大リージョンの最大サイズを処理できる必要があります。 |
|
キャッシュ機能の通知を有効にして、キャッシュ クライアントでこれらの通知を受信できます。これによって、ネットワーク トラフィックとサーバー側でのプロセッサの使用率が増加します。影響は、通知の間隔と送信される通知の数によって異なります。多くの通知が非常に短い間隔で送信されると、パフォーマンスとスケーラビリティに影響を及ぼす場合があります。この影響を予測するための確実なガイドラインはないので、テスト中に確認する必要があります。 |
|
ローカル キャッシュでは、サーバーだけではなく、クライアントでもオブジェクトをキャッシュすることによって、パフォーマンスが向上します。ローカル キャッシュを使用する場合は、クライアント コンピューター上のメモリへの影響を考慮してください。ローカルにキャッシュされるアイテムはサーバー側にも存在するので、この機能はサーバー側でのメモリの処理容量計画とは関係がありません。ただし、ローカル キャッシュの無効化のために通知が使用される場合は、通知の処理によってサーバー側でも影響を受ける可能性があります。 |
|
クライアント側のアプリケーション設計と構成 |
クライアント側のアプリケーション設計は、全体的なパフォーマンスに影響を与える場合があります。たとえば、作成したすべての DataCacheFactory オブジェクトは、呼び出しごとに再作成するのではなく再利用できるように格納しておく必要があります。スレッドごとに 1 つの DataCacheFactory オブジェクトを作成すると便利な場合もあります。または、複数のスレッドで 1 つの DataCacheFactory オブジェクトを共有する場合は、MaxConnectionsToServer の設定を大きくすることも検討してください。これによって、DataCacheFactory ごとのキャッシュ サーバーへの接続数が増加します。 |
前に説明したように、高可用性を使用するキャッシュでは、計算されたメモリ要件の 2 倍の容量が必要になります。また、この機能では最低 3 台のサーバーが必要です。1 台のサーバーが停止した場合、残りの 2 台のサーバーで、障害発生後の各アイテムのプライマリ コピーとセカンダリ コピーをサポートする必要があります。さらに、この機能を使用するには、すべてのサーバーで Windows Server 2008 Enterprise Edition 以上が必要です。 |
|
現時点では、名前付きキャッシュは 128 個まで作成できます。アプリケーションでこの数よりも多くの名前付きキャッシュが必要である場合は、これが処理容量計画の決定要因になります。このような場合、複数のキャッシュ クラスターを使用するか、使用するキャッシュを少なくするようにアプリケーションを設計する必要があります。別の方法として、プログラムによって名前付きキャッシュ内にリージョンを作成する方法もあります。 |
|
キャッシュ クラスターの構成ストアとしてネットワーク上の共有の場所を使用する場合は、クラスター内に最低 3 台のサーバーが存在し、すべてがリード ホストとして指定されていることが必要です。この理由の詳細については、「キャッシュ サーバーの更新」を参照してください。 |
理解しておく必要がある最も重要な設定の 1 つが、各キャッシュ ホスト上のメモリ設定であることは驚くべきことではありません。各キャッシュ ホストの既定のメモリ設定を表示するには、Windows PowerShell コマンド Get-CacheHostConfig を使用します。
ヒント
キャッシュに関連する Windows PowerShell コマンドの使用方法については、「キャッシュ クラスターの一般的な管理タスク」を参照してください。
次のスクリーンショットは、4 GB の RAM を搭載したコンピューターでの Get-CacheHostConfig の出力を示しています。
.gif "Get-CacheHostConfig コマンド")
既定では、サーバーでキャッシュ用に予約されているメモリの容量は RAM の総容量の 50% です。この例では、RAM 容量の半分は 2 GB です。残りのメモリは、オペレーティング システムとサービスで使用できます。さらに多くのメモリが搭載されているコンピューターでも、この既定の設定を変更しないことをお勧めします。前に説明したように、キャッシュ サービスは専用のコンピューターで実行されることを前提としているので、キャッシュに割り当てられている容量よりも多くのメモリが使用される可能性があります。このメモリ使用の一部はキャッシュ サービスの内部設計によるものですが、部分的には .NET のメモリ管理およびガベージ コレクションにも関係しています。.NET アプリケーションでメモリが解放されても、プロセス メモリから解放されるには、ガベージ コレクションが行われるまで待たなければなりません。プロセスでは、ガベージ コレクションの非決定的な性質を考慮して、物理メモリのバッファーが必要になります。
ガベージ コレクションの影響を理解すると、書き込みの割合と頻度が高い作業負荷において、ガベージ コレクションのサイクルを考慮して大量のメモリ バッファーが必要になることがわかります。ほとんどが読み取りのみの作業負荷では、この点を考慮する必要はありません。この場合は、状況によってキャッシュ用に予約するメモリの容量を増やすことを検討します。たとえば、16 GB のメモリを搭載したコンピューターでは、(既定の 8 GB ではなく) 12 GB をキャッシュ サイズの設定として予約し、オペレーティング システムとサービス用に 4 GB のオーバーヘッドを提供することを検討できます。ここでは、コンピューターがキャッシュ サービス専用であることを前提としており、現在サポートされているのはこの構成のみです。この例では、予想される作業負荷を使用して、このメモリ構成をテストする必要があります。メモリの割り当てが過剰である場合、テストで削除やスロットル調整などのメモリ関連の問題が発生することで、不適切な設定が検出されます。詳細については、「サーバーの問題のトラブルシューティング (Windows Server AppFabric キャッシュ)」を参照してください。次の例では、Set-CacheHostConfig コマンドを使用して、Server1 という名前のサーバーのキャッシュ サイズを 12 GB に設定します。
Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288
Get-CacheHostConfig の出力で確認する必要があるもう 1 つの項目が基準値です。LowWatermark 値 (低基準値) は、既定ではキャッシュ サイズの設定の 70% です。キャッシュされたメモリが LowWatermark に達すると、キャッシュ サービスは既に有効期限が切れているオブジェクトの削除を開始します。これらのオブジェクトはいずれにしてもアクセスできないので、この処理に問題はありません。
.gif "キャッシュ ホストの低基準値")
HighWatermark 値 (高基準値) は、既定ではキャッシュ サイズの設定の 90% です。HighWatermark のレベルに達すると、メモリが LowWatermark のレベルに戻るまで、有効期限に関係なくオブジェクトが削除されます。この場合、パフォーマンスを低下させ、ユーザー エクスペリエンスも悪化させる可能性があることは明らかです。
.gif "キャッシュ ホストの高基準値")
HighWatermark に達する可能性を回避するために、キャッシュの使用率は LowWatermark のレベルで計画することをお勧めします。詳細については、「有効期限と削除」を参照してください。
ヒント
完全なガベージ コレクション サイクルによって短時間の遅延が発生する可能性があります。これは通常、再試行エラーとして検出されます。このような理由から、各キャッシュ ホストのメモリは 16 GB 以下にすることをお勧めします。16 GB を超える RAM を搭載したコンピューターでは、完全なガベージ コレクションが行われる際に長い一時停止が発生する可能性があります。ただし、各キャッシュ ホストで使用できるメモリ容量に制限はありません。読み取りが多い作業負荷では、完全なガベージ コレクション サイクルが頻繁には発生しない可能性があります。この点は、負荷テストを通じて見極めることができます。
前の例では、キャッシュ メモリの合計の要件として、21.7 GB という見積もりを算出しました。高可用性が必要であるため、最低 3 台のサーバーが必要です。各サーバーには 16 GB の RAM が搭載されていると仮定しています。この例では、各サーバーの既定のキャッシュ サイズの設定である 8 GB をそのまま使用します。前に説明したように、LowWatermark (70%) を各サーバーで使用可能なメモリの目標にする必要があります。つまり、各キャッシュ サーバーで使用できるメモリの見積もりは 5.6 GB になります。これらの要素を考慮した結果、次の表に示されているように、4 台のサーバーで 22.4 GB のキャッシュ メモリを提供することによって、21.7 GB の要件を満たすことができます。
合計メモリ要件 |
21.7 GB |
初期メモリ (キャッシュ ホスト) |
16 GB |
キャッシュ サイズの設定 (キャッシュ ホスト) |
8 GB |
低基準値 (キャッシュ ホスト) |
70% |
キャッシュ ホストごとの調整されたメモリ容量の目標 |
5.6 GB |
キャッシュ クラスター上の合計メモリ (3 台のコンピューター) |
5.6 GB * 4 台のサーバー = 22.4 |
ここでも、Grid Dynamics のホワイト ペーパーで公開されている結果を使用して、スループットと遅延の目標に関連する見積もりを検証することができます。これらのテスト結果を参考にして、キャッシュ サーバーの数を追加するなど、初期の見積もりを若干修正することになる可能性もあります。ここで重要な点は、このような利用可能なリソースを使用して、情報に基づいた意思決定を行うことです。
処理容量計画ツール
スプレッドシートは、前のセクションの処理容量計画の手順に最適なツールです。サンプルのスプレッドシートをまとめたものを、ここからダウンロードすることができます。アスタリスクの付いているエントリは、ユーザーの計画やリソースに基づいて修正する必要がある項目です。残りの計算はスプレッドシートで自動的に行われます。
スプレッドシートの最初の部分では、各キャッシュ ホストのサーバー構成を指定します。この構成は、計画プロセスの中で変更し、最終的な計算でその相違点を確認できます。次のスクリーンショットは、この最初のセクションを示しています。
.gif "処理容量計画のスプレッドシートの画面")
重要
既定のインストールの値を使用していない場合は、Set-CacheHostConfig コマンドを各キャッシュ ホストに対して使用して、CacheSize と LowWatermark の設定を適用する必要があります。
2 番目のセクションでは、さまざまな種類のオブジェクトの見積もりを入力できます。サンプルのスプレッドシートでは、"Activity Data" および "Reference Data" 用に 2 つのセクションのみ使用されています。その後には、一連の空の列が用意されています。計画で使用する細分性のレベル (オブジェクト、カテゴリ、アプリケーションなど) に応じて、これらの列の名前を変更できます。次のスクリーンショットは、この 2 番目のセクションを示しています。
.gif "処理容量計画のスプレッドシートの画面")
3 番目のセクションでは、ネットワークの要件の見積もりを行います。平均的な読み取り/書き込みのオブジェクト サイズおよび 1 秒あたりの最大読み取り/書き込み操作数を入力します。このセクションでは、そのオブジェクトの種類について、最大ネットワーク帯域幅の要件が計算されます。これを使用して、コンピューターおよびネットワーク カードのグループ化によって負荷を処理できるかどうかを、大まかに把握することができます。前に説明したように、ネットワーク パス全体の帯域幅を確認することも必要です。次のスクリーンショットは、この 3 番目のセクションを示しています。
.gif "処理容量計画のスプレッドシートの画面")
最後のセクションでは、メモリ セクションとネットワーク セクションの要件を集計します。次に、最初のセクションで指定されたコンピューターの構成を使用して、必要なサーバーの台数を計算します。"Additional Servers (追加のサーバー)" フィールドで、必要に応じて、計算された合計値を増やすことができます。たとえば、計算ではサーバーが 2 台だけ必要であると示されている場合、高可用性を適切にサポートするために、最終的な合計にサーバーを 1 台追加することができます。次のスクリーンショットは、この最後のセクションを示しています。
.gif "処理容量計画のスプレッドシートの画面")
ヒント
ここで示したスクリーンショットでは、このホワイト ペーパーの例と同じような数値が使用されていますが、見積もりのサーバー数は 4 台ではなく、3 台になっています。その理由は、カスタム設定を示すために、スプレッドシートで Cache Size Setting(Set-CacheHostConfig) の値を 12 GB に設定しているからです。この値を 8 GB に変更すると、このホワイト ペーパーでこれまでに示した結果と同様の結果になります。
処理容量計画の次の手順
前のセクションでは、キャッシュ クラスターの数、クラスター内のキャッシュ ホストの数、およびキャッシュ ホストの構成について、初期の見積もりを算出する方法を示しました。ただし、これらの見積もりは、テストや継続的な監視に基づいて変更される可能性があることを認識しておく必要があります。
AppFabric のキャッシュ機能を使用する計画を次の段階に進める場合は、概念実証を行って、AppFabric のキャッシュ機能がソリューションでどのように機能するかについて感触をつかんでおくことができます。その後、環境内でテスト用のキャッシュ クラスターをセットアップします。テスト結果に応じて、処理容量、パフォーマンス、およびスケーラビリティの要件を満たすように、構成をさらに変更することができます。次のセクションでは、テスト中および運用中に確認できる特定の継続的な数的指標について説明します。
継続的なキャッシュの処理容量の要件の監視
キャッシュの処理容量の計画は精密科学ではありません。結論に盛り込まれる数値の多くは、それ自体が見積もりです。また、アプリケーションの使用率や使用パターンは時間と供に変化する場合があります。このため、パフォーマンス指標を監視して、キャッシュ クラスターが処理容量の要件を満たしているかどうかを確認することが必要です。適切な処理容量計画は、テスト環境と運用環境の両方で続行される継続的なプロセスです。
パフォーマンス モニター ツールは、処理容量を継続的に監視するのに最適な方法です。各キャッシュ ホストについて、以下のカウンターを監視することをお勧めします。
| 監視のカテゴリ | パフォーマンス モニターのカウンター |
|---|---|
メモリ |
AppFabric キャッシュ: ホスト\合計データ サイズ バイト数 AppFabric キャッシュ: ホスト\解放されたオブジェクトの合計数 AppFabric キャッシュ: ホスト\解放実行の合計数 AppFabric キャッシュ: ホスト\解放されたメモリ合計 AppFabric キャッシュ: ホスト\合計オブジェクト カウント .NET CLR Memory(DistributedCacheService)\# Gen 0 Collections .NET CLR Memory(DistributedCacheService)\# Gen 1 Collections .NET CLR Memory(DistributedCacheService)\# Gen 2 Collections .NET CLR Memory(DistributedCacheService)\# of Pinned Objects .NET CLR Memory(DistributedCacheService)\% Time in GC .NET CLR Memory(DistributedCacheService)\Large Object Heap size .NET CLR Memory(DistributedCacheService)\Gen 0 heap size .NET CLR Memory(DistributedCacheService)\Gen 1 heap size .NET CLR Memory(DistributedCacheService)\Gen 2 heap size Memory\Available MBytes |
ネットワーク |
Network Interface(*)\Bytes Received/sec Network Interface(*)\Bytes Sent/sec Network Interface(*)\Current Bandwidth |
CPU |
Process(DistributedCacheService)\% Processor Time Process(DistributedCacheService)\Thread Count Process(DistributedCacheService)\Working Set Processor(_Total)\% Processor Time |
スループット |
AppFabric キャッシュ: ホスト\合計クライアント要求数 AppFabric キャッシュ: ホスト\合計クライアント要求数/秒 AppFabric キャッシュ: ホスト\合計取得要求数 AppFabric キャッシュ: ホスト\合計取得要求数/秒 AppFabric キャッシュ: ホスト\合計取得要求数 AppFabric キャッシュ: ホスト\合計取得要求数/秒 AppFabric キャッシュ: ホスト\GetAndLock 要求の合計数 AppFabric キャッシュ: ホスト\合計 GetAndLock 要求数/秒 AppFabric キャッシュ: ホスト\合計読み取り要求数 AppFabric キャッシュ: ホスト\合計読み取り要求数/秒 AppFabric キャッシュ: ホスト\合計書き込み操作数 AppFabric キャッシュ: ホスト\合計書き込み操作数/秒 |
その他 |
AppFabric キャッシュ: ホスト\キャッシュできなかった数の割合 AppFabric キャッシュ: ホスト\期限切れオブジェクトの合計数 AppFabric キャッシュ: ホスト\通知配信合計数 |
ここに挙げたカウンターの多くは、処理容量計画プロセスに直接関係します。たとえば、メモリ関連のカウンターがいくつかあります。"Memory\Available Mbytes" は、コンピューターで使用可能な物理メモリがどれくらい残っているかを MB 単位で示します。このカウンターが合計物理メモリ容量の 10% を下回ると、調整が行われる可能性が非常に高くなります。詳細については、「スロットルのトラブルシューティング」を参照してください。また、キャッシュ機能に固有のカウンターもあります。"AppFabric キャッシュ: ホスト\解放実行の合計数" は、メモリの削除が何回実行されたかを示します。メモリ レベルが高基準値を超えると、このカウンターは、メモリが低基準値に戻るまでの削除実行の回数が示されます。同様に、その他のカウンターも、前に説明した処理容量計画の検討プロセスに関連しています。
DistributedCacheService サービスのプロセス カウンターおよびコンピューターの Processor カウンターの値も取得されます。プロセッサの使用率が高いと、キャッシュ クラスターのパフォーマンスに悪影響を及ぼす場合があります。プロセッサの使用率が高い期間が検出された場合は、それがキャッシュ サービス (DistributedCacheService.exe) に関連するものであるか、コンピューター上の別のプロセスに関連するものであるかを見極めることが重要です。
パフォーマンス モニター ツールに加えて、AppFabric と供にインストールされる Windows PowerShell コマンドを使用することもできます。これらのコマンドの多くは、キャッシュ クラスターの正常性と状態を監視するために使用できます。詳細については、「正常性の監視ツール」および「AppFabric キャッシュのログとカウンター (英語の可能性あり)」を参照してください。
関連項目
その他のリソース
Windows Server AppFabric のインストール
MSDN の Windows Server AppFabric のキャッシュ機能に関するドキュメント
AppFabric キャッシュ機能のプログラミング ガイド
ASP.NET セッション状態プロバイダーの構成 (英語の可能性あり)
クラスター構成の保存オプション
Windows Server AppFabric キャッシュ展開および管理ガイド
Windows Server AppFabric および Windows Azure AppFabric に関するリンクとリソース (英語の可能性あり)
2011-12-05