10 キャッシュの概要

この章では、Coherenceで提供される基本的なキャッシュのタイプの概要を説明し、それぞれのタイプを比較します。この章は次の項で構成されています。

分散キャッシュ
レプリケーション・キャッシュ
オプティミスティック・キャッシュ
ニア・キャッシュ
ローカル・キャッシュ
リモート・キャッシュ
キャッシュ・タイプのまとめ

分散キャッシュ

分散キャッシュ(パーティション・キャッシュ)は、線形スケーラビリティを持つクラスタ化されたフォルト・トレラント・キャッシュです。データはクラスタ内のすべてのマシン間でパーティション化されます。フォルト・トレランスを実現するため、パーティション・キャッシュでは、各データをクラスタ内の1つ以上の個別マシンに保持するように構成できます。分散キャッシュはCoherenceで最もよく使用されるキャッシュです。

Coherenceでは、分散キャッシュは、複数のクラスタ・ノードに分散(パーティション化)されたデータのコレクションとして定義されるため、クラスタ内の1つのノードがキャッシュ内の各データに対応し、その対応がクラスタ・ノード間で分散(ロード･バランシング)されます。

分散キャッシュには、いくつかの重要な留意事項があります。

パーティション化: 分散キャッシュ内のデータは、同じデータが2つのサーバーで保持されることがないようにすべてのサーバーに分配されます。これは、キャッシュのサイズ、およびキャッシュの管理に関連する処理能力が、クラスタのサイズとともに線形に拡大することを意味します。また、キャッシュ内のデータに対する操作を単一ホップ(他のサーバーを多くても1つしか必要としない)で実行できることになります。

ロード・バランシング: データがサーバー間に均等に分配されるため、データを管理する役割はクラスタ全体を通して自動的にロード・バランシングされます。

位置の透過性: データはクラスタ・ノード全体に分配されますが、データのアクセスにはまったく同じAPIが使用され、各APIメソッドからも同じ動作が実行されます。これを位置の透過性と呼びます。ローカルのJCache、レプリケートされたキャッシュ、または分散キャッシュではAPIおよびAPIの動作が同じになるため、開発者はキャッシュのトポロジに基づいてコードを記述する必要がありません。

フェイルオーバー: Coherenceのすべてのサービスは、データ損失のないフェイルオーバーおよびフェイルバックを実行しますが、分散キャッシュ・サービスも例外ではありません。分散キャッシュ・サービスではバックアップの回数を設定できます。バックアップ回数を1以上に設定すれば、いずれかのクラスタ・ノードに障害が発生しても、データを失うことはありません。

分散キャッシュにアクセスするには、一般に、ネットワークを介して別のクラスタ・ノードに接続する必要があります。他の条件がすべて同じであるとして、n個のクラスタ・ノードがある場合は、(n-1)/nの操作がネットワークを経由することになります。

図10-1 パーティション・キャッシュ環境でのget操作

各データは1つのクラスタ・ノードのみで管理されるため、ネットワーク経由のアクセスは単一ホップ操作になります。このタイプのアクセスは、Point-to-Point通信を使用できるためスイッチド・ネットワークを最大限に活用できます。そのため、スケーラビリティに非常に優れています。

同様に、キャッシュの更新操作にも同じ単一ホップのPoint-to-Point方式を使用できます。この方法を使用すると、レプリケーション・キャッシュの2つの制限のうち、すべてのクラスタ・ノードにキャッシュの更新をプッシュする必要があるという制限に対応できます。

図10-2 パーティション・キャッシュ環境でのput操作

上の図では、データはプライマリ・クラスタ・ノードとバックアップ・クラスタ・ノードに送信されています。これはフェイルオーバーを目的としたものであり、この場合のバックアップ回数は1になります(デフォルトのバックアップ回数は1に設定されています)。キャッシュ・データが重要ではない(ディスクから再ロードできる)場合は、バックアップ回数をゼロに設定できますが、クラスタ・ノードに障害が発生したときに分散キャッシュ・データの一部が失われる可能性があります。キャッシュがきわめて重要な場合は、バックアップ回数を2などのより高い値に設定できます。バックアップ回数は、キャッシュ・エントリの追加、変更、削除などによるキャッシュの変更パフォーマンスにのみ影響します。

キャッシュに対する変更は、すべてのバックアップが変更を受信したことを認識するまで完了したとは見なされません。したがって、分散キャッシュのバックアップを使用する場合は、キャッシュの変更パフォーマンスが若干低下します。しかし、クラスタ・ノードに予期しない障害が発生しても、データの整合性が維持されることが保証され、データが損失することはありません。

分散キャッシュのフェイルオーバーでは、バックアップ・データがプライマリ記憶域に昇格されます。あるクラスタ・ノードに障害が発生すると、残りのすべてのクラスタ・ノードは、障害が発生したクラスタ・ノードがプライマリ記憶域で停止時に管理していたデータを各自のバックアップ記憶域から判別します。これらのデータの管理は、それをバックアップ記憶域に保持していたクラスタ・ノードに引き継がれます。

図10-3 パーティション・キャッシュ環境のフェイルオーバー

バックアップに複数のレベルがある場合は、最初のバックアップでデータがバックアップされ、2番目以降のバックアップでは前のバックアップがバックアップされるようになります。レプリケーション・キャッシュ・サービスとまったく同じように、サーバーの障害時にはロック情報も維持されます。ただし、唯一の例外として、障害が発生したクラスタ・ノードのロックは自動的に解除されます。

分散キャッシュ・サービスでは、データを格納するクラスタ・ノードと格納しないクラスタ・ノードを構成できます。この設定はローカル記憶域の有効化と呼ばれています。ローカル記憶域を有効化するオプションで構成されたクラスタ・ノードは、分散キャッシュのキャッシュ記憶域とバックアップ記憶域を提供します。この設定にかかわらず、位置の透過性により、データはすべてのクラスタ・ノードでまったく同じように表示できます。

図10-4 パーティション・キャッシュ環境のローカル記憶域

local storage enabledオプションには、次のような利点があります。

クラスタ・ノードのlocal storage enabledを無効にすると、データが他のクラスタ・ノードにキャッシュされるため、このノードのJavaヒープ・サイズはキャッシュ内のデータ量に影響されません。この機能は、大きなJavaヒープを持つ古いバージョンのJVMでアプリケーション・サーバー・プロセスを実行している場合に特に有用です。これらのプロセスは、ヒープ・サイズとともに急激に増加するガベージ・コレクションの一時停止に妨げられることが多いためです。

Coherenceでは、クラスタ・ノードごとに、サポートされている任意のJVMバージョンを実行できます。したがって、local storage enabledを有効にしたクラスタ・ノードでは、大きなヒープ・サイズ、またはJava NIOの機能を使用するCoherenceのヒープ外記憶域をサポートする、新しいJVMバージョンを実行できます。

local storage enabledオプションを使用すると、一部のクラスタ・ノードをキャッシュ・データの格納目的にのみ使用できます。このようなクラスタ・ノードをCoherenceキャッシュ・サーバーと呼びます。キャッシュ・サーバーは、主にCoherenceの分散問合せ機能の拡張に使用されます。

レプリケーション・キャッシュ

レプリケーション・キャッシュはクラスタ化されたフォルト・トレラントなキャッシュで、そこではデータがクラスタ内のすべてのメンバーに完全にレプリケートされます。このキャッシュは、読取りに対して線形パフォーマンスのスケーラビリティで最速の読取りパフォーマンスを示しますが、書込みのスケーラビリティは優れていません(クラスタ内のすべてのメンバーに書込み処理が必要なため)。データがすべてのマシンにレプリケートされるので、サーバーを追加しても、キャッシュの合計容量は増加しません。

レプリケートされたキャッシュは、クラスタ内のデータのレプリケーション、並行処理制御およびフェイルオーバーを処理する能力に優れており、これらの処理はすべてメモリー内のデータ・アクセス速度で実行されます。クラスタ化されたレプリケーション・キャッシュとは、文字どおり、すべてのクラスタ・ノードに自身のデータをレプリケートするキャッシュです。

信頼性のあるレプリケーション・キャッシュを構築するには、いくつかの課題があります。その1つは、どのような方法で高いスケーラビリティとパフォーマンスを得るかということです。キャッシュに対する更新はすべてのクラスタ・ノードに送信する必要があり、たとえ同じデータへの更新が同時に複数行われても、最終的にはすべてのクラスタ・ノードのデータが一致している必要があります。また、あるクラスタ・ノードがロックをリクエストしても、すべてのクラスタ・ノードがそれに従う必要はありません。そうしないと、スケーラビリティがきわめて低くなります。さらに、クラスタ・ノードに障害が発生した場合は、すべてのデータおよびロック情報が安全に維持される必要があります。Coherenceは、このようなシナリオをすべて透過的に処理し、Javaアプリケーションに対応する最もスケーラブルで可用性の高いレプリケーション・キャッシュの実装を実現します。

レプリケーション・キャッシュの最大の長所は、そのアクセス速度です。データがそれぞれのクラスタ・ノードにレプリケートされるため、待機せずにデータを利用できます。これをゼロ待機時間アクセスといい、アプリケーションに最高速のデータ・アクセスが要求される状況においては、まさに理想的な機能です。各クラスタ・ノード(JVM)は、自身のメモリーからデータにアクセスします。

図10-5 レプリケーション・キャッシュ環境でのget操作

一方で、レプリケートされたキャッシュの更新には、他のすべてのクラスタ・ノードに新しいバージョンのデータをプッシュすることが要求されます。

図10-6 レプリケーション・キャッシュ環境でのput操作

Coherenceにおけるレプリケーション・キャッシュ・サービスの実装は、読取り専用操作をすべてローカルで実行する、並行処理制御操作に使用する他のクラスタ・ノードは最大1つとする、他のすべてのクラスタ・ノードとの通信が要求される操作を更新にのみ制限する、という方法で行われます。これにより、スケーラビリティに優れたパフォーマンスが実現し、すべてのCoherenceサービスと同様に、レプリケーション・キャッシュ・サービスからも透過的で完全なフェイルオーバーおよびフェイルバックが提供されます。

レプリケーション・キャッシュ・サービスの制限事項にも十分な留意が必要です。まず、いかに多くのデータをレプリケーション・キャッシュ・サービスで管理していても、それらのデータはサービスに参加している個々のすべてのクラスタ・ノードに保持されます。つまり、メモリー使用量(Javaヒープ・サイズ)はクラスタ・ノードごとに増加し、パフォーマンスに影響する可能性があります。2つ目は、レプリケートされたキャッシュは、更新頻度が高い場合、クラスタ・サイズの増大に比例して線形には拡張されません。つまり、クラスタ・ノードを増設するに従ってクラスタ内の応答能力が損なわれます。

オプティミスティック・キャッシュ

オプティミスティック・キャッシュは、レプリケーション・キャッシュと同様のクラスタ化されたキャッシュの実装になりますが、並行処理制御は行われません。この実装では、レプリケーション・キャッシュより、書込みのスループットが高くなります。また、MRU/MFUベースのキャッシュなどのキャッシュ・データの格納に、代替の基礎となるストアを使用できます。ただし、2つのクラスタ・メンバーが基礎となるローカル・ストアの削除やパージを個別に実行すると、それぞれに保持しているストア・コンテンツがクラスタ・メンバー間で異なる可能性があります。

ニア・キャッシュ

ニア・キャッシュはハイブリッドなキャッシュであり、一般に分散キャッシュまたはリモート・キャッシュとローカル・キャッシュを組み合せた役割を果たします。ニア・キャッシュでは、構成済の無効化方針を使用してフロント・キャッシュ・エントリを無効にし、優れたパフォーマンスおよび同期化を実現します。パーティション・キャッシュによってバッキングされたニア・キャッシュでは、反復的なデータ・アクセスにおいて0ミリ秒のローカル・アクセスが可能になります。同時実行性が可能になり、整合性およびフェイルオーバーが保証されるだけでなく、レプリケーション・キャッシュとパーティション・キャッシュの長所が効率的に結合されます。

ニア・キャッシュの目的は、最後に使用した(MRU: Most Recently Used)データと最も頻繁に使用する(MFU: Most Frequently Used)データの読取りアクセスの速度を上げて、レプリケーション・キャッシュの長所である最大のパフォーマンスと分散キャッシュの長所である最大のスケーラビリティの両方を最大限に実現することです。この目的を達成するため、ニア・キャッシュの実装にはフロント・キャッシュとバック・キャッシュの2つのキャッシュが含まれています。これらはリードスルー/ライトスルー方式を使用することにより、互いに自動的および透過的に通信します。

フロント・キャッシュは、ローカル・キャッシュ・アクセスを提供します。高速でサイズも限られていることから、低コストといえます。バック・キャッシュは、ローカル・キャッシュが使用不能な場合に必要に応じてロードできる、集中型のキャッシュまたは複数層構成のキャッシュにすることができます。バック・キャッシュは、非常に容量が大きいという点で完璧かつ適切ですが、アクセス速度の点では割高といえます。ニア・キャッシュの使用はCoherence*Extendのみに制限されず、TCMPでも使用できます。

この設計により、ニア・キャッシュでは、最も基本的な有効期間ベースのキャッシュや無効化ベースのキャッシュから、データのバージョニングおよび整合性の保証が可能な高度なキャッシュまでの、キャッシュの整合性を様々に構成できます。その結果、ローカル・メモリー・リソースを維持するという点と、真のローカル・キャッシュのパフォーマンス上の利点を活用するという点のバランスを調整することができます。

一般的なデプロイメントでは、フロント・キャッシュにローカル・キャッシュが使用されます。ローカル・キャッシュは、スレッド・セーフである、並行性が高い、サイズ制限がある、自動的に失効する、データがオブジェクト形式で保存される、などの点から妥当な選択といえます。バック・キャッシュには、リモートのパーティション・キャッシュが使用されます。

次の図は、ニア・キャッシュのデータ・フローを示しています。クライアントがオブジェクトDをグリッドに書き込むと、このオブジェクトは、ローカルJVM内のローカル・キャッシュ、およびそれをバックアップする(バックアップ・コピーを含む)パーティション・キャッシュに配置されます。クライアントがオブジェクトをリクエストすると、オブジェクトはローカル、すなわちフロント・キャッシュからオブジェクト形式で待機することなく取得されます。

図10-7 ニア・キャッシュ環境でのput操作

フロント・キャッシュで失効しているオブジェクトまたは無効化されているオブジェクトがクライアントからリクエストされた場合、Coherenceは自動的にパーティション・キャッシュからそのオブジェクトを取得します。更新されたオブジェクトは、フロント・キャッシュに書き込まれてからクライアントに配信されます。

図10-8 ニア・キャッシュ環境でのget操作

ローカル・キャッシュ

クラスタ・サービスではありませんが、Coherenceローカル・キャッシュ実装は、Coherenceの各種クラスタ・キャッシュ・サービスと組み合せて使用されることがよくあります。Coherenceローカル・キャッシュは、特定のクラスタ・ノードに対してローカルである(つまりノード内に完全に含まれる)キャッシュです。ローカル・キャッシュの特に興味深い属性について、次に示します。

ローカル・キャッシュはクラスタ・キャッシュと同じ標準のコレクション・インタフェースを実装します。つまり、ローカル・キャッシュを使用することとクラスタ・キャッシュを使用することにプログラミング上の違いはありません。クラスタ・キャッシュ同様、ローカル・キャッシュではJCache APIまで追跡しています。このAPI自体は、ローカル・キャッシュがベースとする同じ標準のコレクションAPIをベースとしています。
ローカル・キャッシュのサイズは制限できます。つまり、ローカル・キャッシュでは、キャッシュするエントリ数を制限し、キャッシュがいっぱいになったらエントリを自動的に削除できます。さらに、エントリのサイジングとエビクション・ポリシーの両方のカスタマイズが可能です。たとえば、キャッシュされたエントリで使用されるメモリー量を基準にしてキャッシュのサイズを制限できます。デフォルトのエビクション・ポリシーでは、対数曲線で測定された、最も頻繁に使用する(MFU)情報と最後に使用した(MRU)情報の組合せを使用して削除するキャッシュ項目が決定されます。このアルゴリズムは、短期キャッシュと長期キャッシュの両方に対して十分に機能し、頻度と新しさのバランスをとってキャッシュ・スラッシングを回避するため、最適な汎用エビクション・アルゴリズムであるといえます。また、ピュアLRUアルゴリズムおよびピュアLFUアルゴリズムがサポートされ、カスタム・エビクション・ポリシーのプラグイン機能もサポートされています。
ローカル・キャッシュはキャッシュ・エントリの自動失効をサポートしています。つまり、キャッシュ内の各キャッシュ・エントリにTTLを割り当てることができます。
ローカル・キャッシュはスレッド・セーフで並行性が高いため、数多くのスレッドがローカル・キャッシュの複数のエントリに同時にアクセスしたり、エントリを更新したりできます。
ローカル・キャッシュはキャッシュ通知をサポートしています。キャッシュ通知は、追加(クライアントによって追加されたりキャッシュへ自動的にロードされたエントリ)、変更(クライアントによって追加されたり自動的にリロードされたエントリ)、および削除(クライアントによって削除されたり、自動的に失効、フラッシュ、または削除されたエントリ)を処理するために送信されます。これらは、クラスタ・キャッシュでサポートされているキャッシュ・イベントと同じです。
ローカル・キャッシュには、キャッシュ・ヒットおよびキャッシュ・ミスの統計情報が保持されます。これらの実行時統計を使用すれば、キャッシュの有効性を正確に推定できるため、キャッシュ実行時にサイズ制限や自動失効の設定を適宜調整できます。

Coherenceのニア・キャッシュ・テクノロジの一部として機能したり、モジュールで構成されたバッキング・マップ・アーキテクチャで使用されるなど、ローカル・キャッシュはクラスタ・キャッシュ・サービスにおいて重要な役割を果たします。

リモート・キャッシュ

リモート・キャッシュは、Coherence*Extendクライアントによりアクセスされるアウトオブプロセス・キャッシュを表します。キャッシュ・リクエストはすべてCoherenceプロキシに送られ、そこでCoherenceの他のキャッシュ・タイプ(レプリケーション、オプティミスティック、パーティション)のいずれかに委任されます。リモート・キャッシュ使用の詳細は、『Oracle Coherenceクライアント・ガイド』を参照してください。

キャッシュ・タイプのまとめ

数値に関する用語

JVMs = JVMの数
DataSize = キャッシュ・データの合計サイズ(冗長性を除く)
Redundancy = 保持されているデータのコピー数
LocalCache = ローカル・キャッシュ・サイズ(ニア・キャッシュの場合)

表10-1 キャッシュのタイプと特性のまとめ

	レプリケーション・キャッシュ	オプティミスティック・キャッシュ	パーティション・キャッシュ	ニア・キャッシュ(パーティション・キャッシュによるバッキング)	ローカル・キャッシュ(非クラスタ)
トポロジ	レプリケーション	レプリケーション	パーティション・キャッシュ	ローカル・キャッシュ+パーティション・キャッシュ	ローカル・キャッシュ
読取りパフォーマンス	即時5	即時5	ローカル・キャッシュ: 即時5 リモート: ネットワーク速度 1	ローカル・キャッシュ: 即時5 リモート: ネットワーク速度 1	即時5
フォルト・トレランス性	非常に高い	非常に高い	構成可能 4 (0から非常に高い)	構成可能 4 (0から非常に高い)	0
書込みパフォーマンス	高速 2	高速 2	非常に高速 3	非常に高速 3	即時5
メモリー使用量(JVM別)	DataSize	DataSize	DataSize/JVMs x Redundancy	LocalCache + [DataSize / JVMs]	DataSize
整合性	完全な整合性あり	完全な整合性あり	完全な整合性あり	完全な整合性あり6	N/A
メモリー使用量(合計)	JVMs x DataSize	JVMs x DataSize	Redundancy x DataSize	[Redundancy x DataSize] + [JVMs x LocalCache]	N/A
ロック機能	完全に機能	なし	完全に機能	完全に機能	完全に機能
一般的な用途	メタデータ	N/A(ニア・キャッシュを参照)	読取り/書込みキャッシュ	アクセス・アフィニティのある読取り頻度の高いキャッシュ	ローカル・データ

注意:

概算では、100Mbイーサネットの場合、ネットワークで100KBのオブジェクトを1つ読み取るのに最大20ミリ秒を通常必要とします。ギガビット・イーサネットでは一般に、1KBの複数オブジェクトのネットワークでの読取りが1ミリ秒未満になります。
JVMの数に応じて、UDPマルチキャスト操作、またはいくつかのUDPユニキャスト操作が必要です。
冗長性のレベルに応じて、いくつかのUDPユニキャスト操作が必要です。
パーティション・キャッシュでは、バックアップのレベルを必要な数だけ構成することも、まったく構成しないこともできます。ほとんどのインストールでは、バックアップ・コピーを1つ使用します(合計で2コピー)。
ごくわずかな処理を必要とする(一般にはミリ秒未満のパフォーマンス)、ローカルのCPUまたはメモリーのパフォーマンスによって制限されます。
リスナーベースのニア・キャッシュには整合性が確保されています。失効ベースのニア・キャッシュでは、非トランザクション読取りについては部分的な整合性が確保され、トランザクション・アクセスについては整合性が確保されています。