動的キャッシュのキャパシティー・プランニング

WebSphere® Application Server にデプロイされた Java EE アプリケーションでは、動的キャッシュ API を使用できます。 動的キャッシュを使用して、ビジネス・データや生成された HTML をキャッシュに入れたり、データ複製サービス (DRS)を使用してセル内のキャッシュ・データを同期化したりすることができます。

概要

WebSphere eXtreme Scale 動的キャッシュ・プロバイダー で作成されたすべての動的キャッシュ・インスタンスは、デフォルトで、高い可用性を持ちます。高可用性のレベルおよびメモリー・コスト は、使用されるトポロジーによって変わります。

組み込みトポロジーを 使用している場合、キャッシュ・サイズは、1 つのサーバー・プロセス内の空きメモリー の量に制限され、各サーバー・プロセスはキャッシュの完全コピーを 保管します。1 つのサーバー・プロセスが実行し続けている限り、 キャッシュは存続します。キャッシュ・データが失われるのは、 キャッシュにアクセスするすべてのサーバーがシャットダウンされた場合のみです。

組み込み 区画化トポロジーを使用するキャッシングの場合、キャッシュ・サイズの上限は、すべてのサーバー・プロセス内 にある空きスペースの総計です。デフォルトでは、eXtreme Scale 動的キャッシュ・プロバイダー は各プライマリー断片ごとに 1 つのレプリカを使用します。したがって、各キャッシュ・データは 2 回ずつ 保管されます。

組み込み区画化キャッシュの容量を判定する には、以下の式 A を使用してください。

式 A

F * C / (1 + R) = M

各部の意味は、次のとおりです。
  • F = コンテナー・プロセス当たりの空きメモリー
  • C = コンテナーの数
  • R = レプリカの数
  • M = キャッシュの合計サイズ

各プロセスに 256 MB の使用可能なスペースがあり、サーバー・プロセスが合計 4 つある WebSphere Application Server Network Deployment データ・グリッド の場合、それらの全サーバーにまたがるキャッシュ・インスタンスは 512 メガバイトまでのデータを 保管できます。このモードでは、キャッシュ は、1 つのサーバーが破損しても、データを失うことなく存続できます。また、最大 2 つのサーバーが 順次シャットダウンしても、データを失うことは ありません。この例では、上の式は次のようになります。

256mb * 4 コンテナー/ (1 プライマリー + 1 レプリカ) = 512mb

リモート・トポロジーを使用するキャッシュのサイジング特性は、組み込み区画化トポロジーを 使用するキャッシュと似ていますが、 すべての eXtreme Scale コンテナー・プロセス内の使用可能なスペースの総量に制限されます。

リモート・トポロジー では、レプリカの数を増やすことによって、メモリーのオーバーヘッドが余分にかかる代わりにアベイラビリティーのレベルを上げることが 可能です。これは大部分の動的キャッシュ・アプリケーションでは不必要ですが、 dynacache-remote-deployment.xml ファイルを編集してレプリカの数を 増やすことができます。

以下の式 B と C を使用して、 キャッシュの高可用性のためにレプリカを追加することの影響を 判定できます。

式 B

N = Minimum(T -1, R)

各部の意味は、次のとおりです。
  • N = 同時に破損してもかまわないプロセスの数
  • T = コンテナーの総数
  • R = レプリカの総数

式 C

Ceiling(T/ (1+N)) = m

各部の意味は、次のとおりです。
  • T = コンテナーの総数
  • N = レプリカの総数
  • m = キャッシュ・データをサポートするのに必要な最小コンテナー数

動的キャッシュ・プロバイダーでのパフォーマンス・チューニングに ついては、動的キャッシュ・プロバイダーのチューニングを参照してください。

キャッシュのサイズ見積もり

WebSphere eXtreme Scale 動的キャッシュ・プロバイダー を使用するアプリケーションをデプロイする前に、前のセクションに記述されている一般的な規則に、 実動システムの環境データを組み合わせて検討する 必要があります。まず最初に確定する必要がある数値は、コンテナー・プロセスの総数と、 キャッシュ・データを保持するための各プロセス内の使用可能メモリーの量 です。組み込みトポロジーを使用している場合、 キャッシュ・コンテナーは WebSphere Application Server プロセスの内部の同一場所に配置 され、キャッシュを共有する各サーバーごとにコンテナーが 1 つずつある状態になります。 キャッシングを使用可能にしていないアプリケーションと WebSphere Application Server の メモリー・オーバーヘッドを判定することが、プロセス内で使用可能なスペース量を 計算する最良の方法です。これは、詳細ガーベッジ・コレクション・データを分析することで 行えます。リモート・トポロジーを使用している場合、この情報は、 新しく開始され、キャッシュ・データがまだ設定されたことのないスタンドアロン・コンテナーの、詳細ガーベッジ・コレクション出力 を見れば分かります。 キャッシュ・データ用に使用可能な、プロセス当たりのスペース量を計算する 際には、ガーベッジ・コレクション用にいくらかのヒープ・スペースを確保 しておくことにも注意が必要です。コンテナー (WebSphere Application Server または スタンドアロン) のオーバーヘッドに、キャッシュ用に予約されたサイズを加えた結果は、 合計ヒープの 70 % 以下になっているべきです。

この情報を収集できたら、 前述の式 A に値を挿入して、区画化されたキャッシュの 最大サイズを判定してください。最大サイズが判明したら、 次のステップは、サポートできるキャッシュ・エントリー総数を 判定することです。これには、キャッシュ・エントリー当たりの平均サイズを 決定することが必要です。これを行う簡単な方法は、カスタマー・オブジェクトのサイズに 10% 追加 することです。動的キャッシュを使用している場合のキャッシュ・エントリーのサイズ見積もりについて詳しくは、動的キャッシュおよびデータ・レプリカ生成サービスのチューニング・ガイドを参照してください。

圧縮が有効に されている場合、圧縮はカスタマー・オブジェクトのサイズには影響しますが、キャッシング・システムのオーバーヘッドには影響しません。 圧縮を使用している場合のキャッシュ・オブジェクトのサイズを 判定するには、以下の式を使用します。

S = O * C + O * 0.10

各部の意味は、次のとおりです。
  • S = キャッシュ・オブジェクトの平均サイズ
  • O = 圧縮されていないカスタマー・オブジェクトの平均サイズ
  • C = 分数で表した圧縮率
つまり、2 を 1 にする場合の圧縮率は 1/2 = 0.50 です。これは小さいほど 良い値です。保管されるオブジェクトが通常の POJO で、 大部分がプリミティブ型の場合、圧縮率を 0.60 から 0.70 に 想定してください。キャッシュされるオブジェクトが、サーブレット、JSP、または WebServices オブジェクトの場合、圧縮率を判定する最適の方法は、代表的なサンプルを ZIP 圧縮ユーティリティーで圧縮することです。これが不可能な 場合、このタイプのデータの一般的な圧縮率は 0.2 から 0.35 です。

次に、この情報を 使用して、サポートできるキャッシュ・エントリーの総数を判定します。以下の式 D を 使用してください。

式 D

T = S / A

各部の意味は、次のとおりです。
  • T = キャッシュ・エントリーの総数
  • S = 式 A を使用して算出され、キャッシュ・データ用に使用可能な合計サイズ
  • A = 各キャッシュ・エントリーの平均サイズ
最後に、動的キャッシュ・インスタンスにキャッシュ・サイズを 設定して、この制限を強制する必要があります。WebSphere eXtreme Scale 動的 キャッシュ・プロバイダーは、この点で、デフォルトの動的キャッシュ・プロバイダー と異なります。以下の式を使用して、動的キャッシュ・インスタンスのキャッシュ・サイズ に設定する値を判定してください。以下の式 E を 使用してください。

式 E

Cs = Ts / Np

各部の意味は、次のとおりです。
  • Ts = キャッシュの合計目標サイズ
  • Cs = 動的キャッシュ・インスタンスに設定するキャッシュ・サイズ設定値
  • Np = 区画の数。デフォルトは 47 です。
キャッシュ・インスタンスを共有する各サーバーで、動的キャッシュ・インスタンスのサイズを、式 E で計算した値 に設定してください。