22.3. Infinispan
22.3.1. Infinispan
Infinispan は Java データグリッドプラットフォームで、キャッシュされたデータの管理に Jakarta Persistence 2.2 準拠のキャッシュインターフェイスを提供します。
Infinispan の機能や設定オプションの詳細は Infinispan のドキュメント を参照してください。
infinispan
サブシステムは JBoss EAP のキャッシュサポートを提供します。名前付きのキャッシュコンテナーやキャッシュのランタイムメトリックスを設定および表示できます。
高可用性の機能を提供する設定を使用する場合 (マネージドドメインでは ha や full-ha プロファイル、スタンドアロンサーバーは standalone-ha.xml
や standalone-full-ha.xml
設定ファイル)、infinispan
サブシステムはキャッシング、状態のレプリケーション、および状態分散サポートを提供します。高可用性でない設定では、infinispan
サブシステムはローカルのキャッシュサポートを提供します。
Infinispan は、JBoss EAP 8.0 のパブリックモジュールです。アプリケーション用の infinispan
サブシステムを使用して、新しいキャッシュコンテナーまたはキャッシュを作成および使用できます。また、Infinispan API の使用は、アプリケーションによってサポートされています。
22.3.2. キャッシュコンテナー
キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。各キャッシュコンテナーは、使用されるデフォルトのキャッシュを定義します。
JBoss EAP 8.0 では、次のデフォルトの Infinispan キャッシュコンテナーが定義されています。
-
server
(シングルトンキャッシング) -
web
(Web セッションクラスタリング) -
ejb
(ステートフルセッション Bean クラスタリング) -
hibernate
(エンティティーキャッシング)
例: Infinispan のデフォルト設定
<subsystem xmlns="{InfinispanSubsystemNamespace}"> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> <transport lock-timeout="60000"/> <replicated-cache name="default"> <transaction mode="BATCH"/> </replicated-cache> </cache-container> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/> </local-cache> <invalidation-cache name="entity"> <transaction mode="NON_XA"/> <object-memory size="1000"/> <expiration max-idle="100000"/> </invalidation-cache> <replicated-cache name="timestamps" mode="ASYNC"/> </cache-container> </subsystem>
各キャッシュコンテナーで定義されたデフォルトのキャッシュに注目してください。この例では、web
キャッシュコンテナーは dist
分散キャッシュをデフォルトとして定義します。そのため、Web セッションのクラスタリングでは dist
キャッシュが使用されます。
デフォルトキャッシュの変更やキャッシュの追加に関する詳細は、キャッシュコンテナーの設定 を参照してください。
22.3.2.1. キャッシュコンテナーの設定
キャッシュコンテナーやキャッシュ属性は、管理コンソールまたは管理 CLI を使用して設定できます。
設定の他のコンポーネントが参照する可能性があるため、キャッシュまたはキャッシュコンテナーの名前を変更しないでください。
22.3.2.1.1. 管理コンソールを使用したキャッシュの設定
管理コンソールの Configuration タブで Infinispan サブシステムを選択するとキャッシュやキャッシュコンテナーを設定できます。マネージドドメインでは設定するプロファイルを選択してください。
キャッシュコンテナーを追加します。
Cache Container の横にある追加 (+) ボタンをクリックし、Cache Container を追加 を選択して新しいキャッシュコンテナーの設定を入力します。
キャッシュコンテナー設定を更新します。
該当するキャッシュコンテナーを選択し、表示 を選択します。必要に応じてキャッシュコンテナーの設定を行います。
キャッシュコンテナートランスポート設定を更新します。
該当するキャッシュコンテナーを選択し、表示 を選択します。Transport タブで、必要に応じてキャッシュコンテナートランスポートを設定します。
キャッシュを設定します。
該当するキャッシュコンテナーを選択し、表示 を選択します。キャッシュタブ (Replicated Cache など) でキャッシュを追加、更新、および削除できます。
22.3.2.1.2. 管理 CLI を使用したキャッシュの設定
管理 CLI を使用してキャッシュおよびキャッシュコンテナーを設定できます。マネージドドメインではコマンドの前に /profile=PROFILE_NAME
を追加して更新するプロファイルを指定する必要があります。
キャッシュコンテナーを追加します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:add
レプリケートされたキャッシュを追加します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE:add(mode=MODE)
キャッシュコンテナーのデフォルトキャッシュを設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=default-cache,value=CACHE)
レプリケートされたキャッシュのバッチ処理を設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE/component=transaction:write-attribute(name=mode,value=BATCH)
これにより、サーバーが以下のように設定されます。
<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan"> ... <distributed-cache name="concurrent"> <file-store/> </distributed-cache> </cache-container>
22.3.2.1.3. デフォルト Jakarta Enterprise Beans キャッシュコンテナーの変更
以下のようにキャッシュコンテナーを ejb3
サブシステムで使用できます。
-
Jakarta Enterprise Beans セッション bean のパッシベーションをサポートするには、
infinispan
サブシステムに定義されたejb
キャッシュコンテナーを使用してセッションを保存できます。 - サーバー上でクラスター化されたデプロイメントに接続するリモート Jakarta Enterprise Beans クライアントの場合、クラスタートポロジーの情報をこれらのクライアントに提供して、これらのクライアントが対話するノードに障害が発生したときにクラスターの別のノードにフェイルオーバーできるようにする必要があります。
22.3.2.1.4. Infinispan サブシステムから Jakarta EE アプリケーションにリソースを注入する
@Resource
アノテーションを使用して、キャッシュなどの Infinispan リソースを Infinispan サブシステムからアプリケーションに注入できます。次の例は、@Resource
アノテーションを使用して Jakarta EE アプリケーションにキャッシュを注入する方法を示しています。
@Resource(lookup = "java:jboss/infinispan/cache/foo/bar") private org.infinispan.Cache<Integer, Object> cache;
上記の例では、foo
はキャッシュコンテナーの名前であり、bar
は注入するキャッシュの名前です。
EAP は注入されたリソースのライフサイクルを管理するため、アプリケーションはキャッシュやキャッシュマネージャーなどのリソースを管理する必要がありません。
リソースを手動で作成すると、EAP ではなくアプリケーションがそれらのリソースを管理します。
次の例は、Infinispan サブシステムから、さまざまなリソースをアプリケーションに注入する方法を示しています。
デフォルトのキャッシュを注入する例
キャッシュコンテナーのデフォルトキャッシュを Infinispan サブシステムからアプリケーションに注入するには、次のコマンドを使用します。
@Resource(lookup = "java:jboss/infinispan/cache/foo/default")
埋め込みキャッシュマネージャーの注入例
埋め込みキャッシュマネージャーを注入して、アプリケーションが新しいキャッシュ設定とキャッシュを作成できるようにするには、次のコマンドを使用します。
@Resource(lookup = "java:jboss/infinispan/container/foo") private org.infinispan.manager.EmbeddedCacheManager manager;
キャッシュ設定の注入例
Infinispan サブシステム内で定義されたキャッシュ設定は、アプリケーションがそれらのキャッシュ設定に明示的に依存しない限り、常にインストールされていたり使用できたりするわけではありません。Infinispan サブシステムからアプリケーションにキャッシュ設定を注入するには、@Resource
アノテーションを使用します。
次の例では、
@Resource
アノテーションを使用してfoo
コンテナーのキャッシュ設定を注入します。@Resource(lookup = "java:jboss/infinispan/configuration/foo/bar") private org.infinispan.config.Configuration config;
次の例では、
@Resource
アノテーションを使用して、foo
コンテナーのデフォルトのキャッシュ設定を注入します。@Resource(lookup = "java:jboss/infinispan/configuration/foo/default") private org.infinispan.config.Configuration config;
22.3.2.1.5. Hibernate キャッシュコンテナーのエビクション機能
hibernate
キャッシュコンテナーのエビクション機能は、メモリーからキャッシュエントリーを削除します。この機能は、サブシステムのメモリー負荷を軽減するのに役立ちます。
size
属性は、キャッシュエントリーのエビクションの開始前に保存されるキャッシュエントリーの最大数を設定します。
例: エビクション機能
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/>
エビクションはメモリー内でのみ実行されることに注意してください。キャッシュストアは、情報の永続的な損失を防ぐためにエビクトされたキャッシュエントリーを保持します。エビクション機能の詳細は、Infinispan ユーザーガイドの エビクションおよびデータコンテナー セクションを参照してください。
22.3.2.1.6. Hibernate キャッシュコンテナーの有効期限機能
hibernate
キャッシュコンテナーの有効期限機能は、クラスター化された操作です。したがって、クラスター化されたキャッシュを使用すると、期限切れのキャッシュエントリーがすべてのクラスターメンバーから削除されます。詳細は、Infinispan ユーザーガイドの 有効期限 セクションを参照してください。
22.3.3. クラスタリングモード
JBoss EAP で Infinispan を使用すると、2 つの方法でクラスタリングを設定できます。ご使用のアプリケーションに最も適した方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、およびスケーラビリティーのトレードオフが発生します。クラスタリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取る必要があります。
キャッシュモード
- レプリケーション
- Replication (レプリケーション) モードはクラスターの新しいインスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常 Replication モードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。
- Distribution (分散)
Distribution (分散) モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数 (または所有者数) は設定可能です。保持するコピー数、データの永続性、およびパフォーマンスにはトレードオフが生じます。保持するコピー数が多いほどパフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータを損失する可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。
クラスターサイズが 6-8 ノードを超える場合は Distribution モードをキャッシュストラテジーとして使用することを考慮してください。Distribution モードでは、データはクラスター内のすべてのノードではなくノードのサブセットのみに分散されます。
22.3.3.1. キャッシュモードの設定
管理 CLI を使用してデフォルトキャッシュを変更できます。
ここでは、デフォルトが Distribution モードである Web セッションキャッシュの設定に固有する手順を説明します。手順と管理 CLI コマンドは、他のキャッシュコンテナー向けに簡単に調整できます。
レプリケーションキャッシュモードへの変更
Web セッションキャッシュのデフォルトの JBoss EAP 8.0 設定には、repl
レプリケーションキャッシュが含まれていません。最初にこのキャッシュを追加する必要があります。
以下はスタンドアロンサーバーの管理 CLI コマンドになります。マネージドドメインで実行している場合は、/subsystem=infinispan
コマンドの前に /profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。
レプリケーションキャッシュ
repl
を追加し、デフォルトのキャッシュとして設定します。batch /subsystem=infinispan/cache-container=web/replicated-cache=repl:add() /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/replicated-cache=repl/store=file:add /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=repl) run-batch
サーバーをリロードします。
reload
分散キャッシュモードへの変更
Web セッションキャッシュのデフォルトの JBoss EAP 8.0 設定には、すでに dist
ディストリビューションキャッシュが含まれています。
以下はスタンドアロンサーバーの管理 CLI コマンドになります。マネージドドメインで実行している場合は、/subsystem=infinispan
コマンドの前に /profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。
デフォルトのキャッシュを
dist
分散キャッシュに変更します。/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
分散キャッシュの所有者数を設定します。以下のコマンドは所有者の数を
5
に設定します。デフォルトは2
です。/subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
サーバーをリロードします。
reload
22.3.3.2. キャッシュストラテジーのパフォーマンス
SYNC
キャッシュストラテジーを使用すると、レプリケーションが完了するまでリクエストが完了しないため、レプリケーションのコストを簡単に評価でき、直接応答時間に影響します。
ASYNC
キャッシュストラテジーの応答時間は SYNC
キャッシュストラテジーよりも短いと思われがちですが、一定の状況下でのみ短くなります。ASYNC
キャッシュストラテジーの評価はより困難ですが、リクエスト間の時間がキャッシュ操作を完了できるほど長い場合はパフォーマンスが SYNC
よりも良くなります。これは、レプリケーションのコストが応答時間に即影響しないためです。
同じセッションのリクエストの作成が早すぎると、先行リクエストからのレプリケーションが完了するまで待機しなければならないため、先行リクエストのレプリケーションコストが後続リクエストの前に移動します。応答の受信直後に後続リクエストが送信され、リクエストが急速に発生する場合、ASYNC
キャッシュストラテジーのパフォーマンスは SYNC
よりも劣化します。そのため、同じセッションのリクエストの間には、SYNC
キャッシュストラテジーのパフォーマンスが ASYNC
キャッシュストラテジーよりも良くなる期間のしきい値があります。実際の使用状態では、通常同じセッションのリクエストが立て続けに受信されることはありませんが、一般的にリクエストの間に数秒程度の時間が存在します。その代わりに、通常、要求間に数秒以上の時間が経過します。この場合、ASYNC
キャッシュストラテジーが適切なデフォルトで、応答時間が早くなります。
22.3.4. 状態遷移
状態遷移は、基本的なデータグリッドとクラスター化されたキャッシュ機能の両方です。状態遷移がない状態では、ノードがクラスターに追加されたり、クラスターから削除されるとデータが失われます。
状態遷移は、キャッシュメンバーシップの変更に応じて、キャッシュの内部状態を調整します。この変更は、ノードがクラスターに参加または退出するとき、2 つ以上のクラスターパーティションがマージするとき、またはこれらのイベントの組み合わせが発生した後に自動的に行われます。新しいキャッシュは、以下のキャッシュのモードを基にして、最大量の状態を受け取る必要があるため、新たに開始されたキャッシュの最初の状態遷移は最も多くのリソースが必要となります。
timeout
属性を使用すると、新たに開始されたキャッシュが状態を受け取る待ち時間を制御することができます。timeout
属性が正の値である場合、キャッシュはすべての初期状態を受け取るまで待機した後、リクエストに対応できるようになります。状態遷移が指定時間内 (デフォルトは 240000
ミリ秒) に完了しなかった場合、キャッシュによってエラーが発生し、開始がキャンセルされます。timeout
を 0
に設定するとキャッシュは即座に利用可能になり、バックグラウンド操作中に最初の状態を受け取ります。最初の状態遷移が完了するまで、キャッシュが受け取っていないキャッシュエントリーのリクエストは、リモートノードから取得する必要があります。
timeout
属性を 0
に設定するには、以下のコマンドを実行します。
/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)
状態遷移の挙動はキャッシュのモードによって決まります。
- レプリケーションモードでは、キャッシュに参加する新規ノードは既存ノードからキャッシュの状態をすべて受け取ります。ノードがクラスターから退出すると、状態遷移はありません。
-
Distribution モードでは、新しいノードは既存のノードから状態の一部のみを受け取り、既存のノードは一貫したハッシュの決定どおりに、各キーの
owners
コピーを維持するために状態の一部を削除します。ノードがクラスターから退出する場合、分散キャッシュはそのノードに保存されたキーの追加コピーを作成し、各キーの所有者が存続するようにする必要デフォルトがあります。 - インバリデーションモードでは、最初の状態推移はレプリケーションモードと似ていますが、ノードが同じ状態でいられる保証がないことが唯一の違いです。ノードがクラスターから退出すると、状態遷移はありません。
デフォルトでは、状態遷移はインメモリーおよび永続状態の両方を遷移しますが、設定で無効にすることもできます。状態遷移が無効になっている場合、ClusterLoader
を設定しないと、データをキャッシュにロードせずにノードがキーの所有者またはバックアップ所有者になります。さらに、Distribution モードで状態遷移が無効になっていると、キャッシュでキーのコピーが owners
コピーよりも少なくなることがあります。
22.3.5. Infinispan スレッドプールの設定
infinispan
サブシステムには async-operations
、expiration
、listener
、persistence
、remote-command
、state-transfer
、および transport
スレッドプールが含まれます。これらのプールはすべての Infinispan キャッシュコンテナーに設定できます。
以下の表は、infinispan
サブシステムの各スレッドプールに設定できる属性とデフォルト値を表しています。
スレッドプール名 | keepalive-time | max-threads | min-threads | queue-length |
---|---|---|---|---|
async-operations | 60000L | 25 | 25 | 1000 |
expiration | 60000L | 1 | 該当なし | 該当なし |
listener | 60000L | 1 | 1 | 100000 |
persistence | 60000L | 4 | 1 | 0 |
remote-command | 60000L | 200 | 1 | 0 |
state-transfer | 60000L | 60 | 1 | 0 |
transport | 60000L | 25 | 25 | 100000 |
以下の構文を使用して、管理 CLI で Infinispan スレッドプールを設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER_NAME/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)
以下は、server
キャッシュコンテナーの persistence
スレッドプールで max-threads
の値を 10
に設定する管理 CLI コマンドの例になります。
/subsystem=infinispan/cache-container=server/thread-pool=persistence:write-attribute(name="max-threads", value="10")
22.3.6. Infinispan の統計
監視目的で、Infinispan キャッシュやキャッシュコンテナーに関する実行時統計を有効にできます。パフォーマンス上の理由で、統計の収集はデフォルトでは無効になっています。
統計収集は、各キャッシュコンテナー、キャッシュ、または両方に対して有効にできます。各キャッシュの統計オプションはキャッシュコンテナーのオプションをオーバーライドします。キャッシュコンテナーの統計収集を無効または有効にすると、独自の設定が明示的に指定されている場合以外はそのコンテナーのすべてのキャッシュが設定を継承します。
22.3.6.1. Infinispan 統計の有効化
Infinispan の統計を有効にすると、infinispan
サブシステムのパフォーマンスに影響する可能性があります。統計は必要な場合のみ有効にしてください。
管理コンソールまたは管理 CLI を使用すると Infinispan の統計収集を有効または無効にできます。管理コンソールでは、Configuration タブで Infinispan サブシステム選択してキャッシュまたはキャッシュコンテナーを選択し、Statistics Enabled 属性を編集します。管理 CLI を使用する場合は以下のコマンドを実行して統計を有効にします。
キャッシュコンテナーの統計収集を有効にします。サーバーをリロードする必要があります。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)
キャッシュの統計収集を有効にします。サーバーをリロードする必要があります。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
以下のコマンドを使用すると、キャッシュの statistics-enabled
属性の定義が解除され、キャッシュコンテナーの statistics-enabled
属性の設定を継承します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)
22.3.7. Infinispan パーティションの処理
Infinispan クラスターは、データが保存される複数のノードで構築されます。複数のノードに障害が発生した場合のデータの損失を防ぐため、Infinispan は複数のノードで同じデータをコピーします。このレベルのデータ冗長性は owners
属性を使用して設定されます。設定されたノードの数未満のノードが同時にクラッシュしても、Infinispan はデータのコピーを利用できます。
しかし、クラスターから大量のノードが消滅すると最悪の事態を招く可能性があります。
- スプリットブレイン
スプリットブレインはクラスターを独立して動作する 2 つ以上のパーティションまたはサブクラスターに分割します。このような場合、異なるパーティションから読み書きする複数のクライアントが同じキャッシュエントリーの異なるバージョンを見ることになり、多くのアプリケーションにとって問題となります。
注記スプリットブレインの発生を軽減する方法には、冗長化ネットワークや IP ボンディング などがあります。 しかし、これらの方法は問題発生のリードタイムを削減するだけです。
- 複数ノードの連続クラッシュ
- 複数のノード (所有者の数) が連続してクラッシュし、Infinispan がクラッシュ間の状態を適切に調整する時間がない場合、結果として部分的なデータの損失が発生します。
スプリットブレインや複数ノードの連続クラッシュが原因で、不適切なデータがユーザーに返されないようにすることが大切です。
22.3.7.1. スプリットブレイン
スプリットブレインが発生した場合、各ネットワークパーティションが独自の JGroups ビューをインストールし、他のパーティションからノードを削除します。パーティションはお互いを認識しないため、クラスターが 2 つ以上のパーティションに分割されたかどうかを直接判断することはできません。そのため、明示的な脱退メッセージを送信せずに、1 つ以上のノードが JGroups クラスターから消滅した場合にクラスターが分割されたと判断します。
パーティション処理が無効の場合、各パーティションは継続して独立したクラスターとして機能します。各パーティションはデータの一部のみを認識できる可能性があり、競合する更新をキャッシュに書き込む可能性があります。
パーティション処理が有効の場合、スプリットを検出したときに各パーティションは即座にリバランスを行わず、degrade モードにするかどうかを最初にチェックします。
- 1 つ以上のセグメントがすべての所有者を失った場合 (最後に行ったリバランスが完了した後に指定した所有者の数以上が脱退した場合)、パーティションは degrade モードになります。
- 最新の安定したトポロジーでパーティションに単純多数のノード (floor(numNodes/2) + 1) が含まれない場合も、パーティションは degrade モードになります。
- その他の場合は、パーティションは通常通り動作し、リバランスを開始します。
安定したトポロジーは、リバランス操作が終了するたびに更新され、コーディネーターによって他のリバランスが必要ないと判断された場合に毎回更新されます。これらのルールは、1 つのパーティションが available モードを維持し、他のパーティションが degraded モードになるようにします。
パーティションが degraded モードの場合、完全に所有されたキーへのアクセスのみを許可します。
- このパーティション内のノード上のコピーをすべて持つエントリーのリクエスト (読み取りおよび書き込み) は許可されます。
-
消滅したノードによって完全所有または一部所有されたエントリーのリクエストは
AvailabilityException
によって拒否されます。
これにより、パーティションが同じキーに異なる値を書き込めないようにし (キャッシュの一貫性を保つ)、さらにパーティションが他のパーティションで更新されたキーを読み取れないようにします (陳腐データをなくす)。
2 つのパーティションは分離して開始できます。これらのパーティションはマージされなければ不整合なデータを読み書きできます。 将来的に、この状況に対処できるカスタムの可用性ストラテジーが許可される可能性があります (例: 特定のノードがクラスターの一部であるかを確認、外部のマシンにアクセスできるかどうかを確認など)。
22.3.7.2. パーティション処理の設定
パーティション処理はデフォルトで無効になっています。パーティション処理を有効にすると、設定可能な属性が 2 つあります。
属性 | 値 |
---|---|
| "DENY_READ_WRITES", "ALLOW_READS", "ALLOW_READ_WRITES" |
| "NONE", "PREFERRED_ALWAYS", "PREFERRED_NON_NULL", "REMOVE_ALL" |
ネットワークパーティションの検出時に、キャッシュの読み取りおよび書き込み動作を決定するために、when-split
を設定します。
merge-policy
を設定して、複数のネットワークパーティションをマージする際に競合解決ポリシーストラテジーを決定します。
CLI コマンドの例
/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=when-split, value=DENY_READ_WRITES)
22.3.7.3. リモートキャッシュコンテナーの設定
マネージドドメインのすべてのサーバーグループにリモートキャッシュを設定する必要があります。statistics-enabled
属性により、指定の remote-cache-container
および関連するランタイムキャッシュについてのメトリックのコレクションを有効にできます。
22.3.7.3.1. リモートキャッシュコンテナーの作成
マネージドドメインの各サーバーグループには、一意のリモートキャッシュが必要です。このキャッシュは、同じデータグリッドに所属することができます。そのため、ユーザーは、サーバーグループのソケットバインディングを定義し、ソケットバインディングをリモートキャッシュコンテナーに関連付けることにより、すべてのサーバーグループのリモートキャッシュを設定する必要があります。
手順
socket-binding
を定義します。 クラスターの各リモート Red Hat Data Grid インスタンスの必要に応じて、コマンドを繰り返し実行します。/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
新規作成されたソケットバインディングを参照する
remote-cache-container
を定義します。batch /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER:add(default-remote-cluster=data-grid-cluster) /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/remote-cluster=data-grid-cluster:add(socket-bindings=[SOCKET_BINDING,SOCKET_BINDING_2,...]) run-batch
22.3.7.3.2. リモートキャッシュコンテナーの統計の有効化
statistics-enabled
属性により、指定の remote-cache-container
および関連するランタイムキャッシュに関するメトリックのコレクションが有効になります。
-
"foo" という
remote-cache-container
場合は、次の操作を使用して統計を有効にします。
/subsystem=infinispan/remote-cache-container=foo:write-attribute(name=statistics-enabled, value=true)
-
"foo" という
remote-cache-container
は、以下のメトリックがランタイム時に表示されます。
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=active-connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=idle-connections)
-
これらのメトリックの説明は、
remote-cache-container
に read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo:read-resource-description
- 以下のメトリックは、選択したデプロイメントによって使用されるリモートキャッシュに固有のものです。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource(include-runtime=true, recursive=true) { "average-read-time" : 1, "average-remove-time" : 0, "average-write-time" : 2, "hits" : 9, "misses" : 0, "near-cache-hits" : 7, "near-cache-invalidations" : 8, "near-cache-misses" : 9, "near-cache-size" : 1, "removes" : 0, "time-since-reset" : 82344, "writes" : 8 }
- これらのメトリックの説明は、リモートキャッシュに対して read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource-description
- これらのメトリックの一部は計算値 (例: average- *) であり、ヒットやミスなどのその他は集計値です。この集計メトリックは、以下の操作でリセットできます。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:reset-statistics()
22.3.8. HTTP セッションの Red Hat Data Grid への外部化
この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。
Red Hat Data Grid は、HTTP セッションなどの JBoss EAP のアプリケーション固有データの外部キャッシュコンテナーとして使用できます。これにより、アプリケーションとは独立したデータレイヤーのスケーリングが可能になり、さまざまなドメインに存在する可能性がある異なる JBoss EAP クラスターが同じ Red Hat Data Grid クラスターからデータにアクセスできるようになります。また、他のアプリケーションは Red Hat Data Grid によって提供されたキャッシュと対話できます。
以下の例は、HTTP セッションを外部化する方法を説明しています。これは、JBoss EAP のスタンドアロンインスタンスとマネージドドメインの両方に適用されます。
-
remote-cache-container
を作成します。詳細は、リモートキャッシュコンテナーの設定 を参照してください。 HotRod ストアを設定します。HotRod ストアは、JBoss EAP サーバーによって作成された各キャッシュに対して専用のリモートキャッシュを 1 つ使用します。通常、以下の CLI スクリプトのように、JBoss EAP サーバーで 1 つのインバリデーションキャッシュが使用されます。
注記Red Hat Data Grid サーバーでリモートキャッシュを手作業で設定する必要があります。これらのキャッシュに推奨される設定は、楽観的ロックを持つトランザクション分散モードです。キャッシュ名はデプロイメントファイル名に対応する必要があります (例:
test.war
)。リモートキャッシュコンテナーが設定されたら、
hotrod
ストアを設定して既存のストアを置き換えることができます。以下の CLI スクリプトは、インバリデーションキャッシュとともにセッションをオフロードする典型的なユースケースを示しています。batch /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME:add() /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/store=hotrod:add(remote-cache-container=CACHE_CONTAINER,fetch-state=false,purge=false,passivation=false,shared=true) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=CACHE_NAME) run-batch
このスクリプトは新しいインバリデーションキャッシュを設定します。作成後、セッションデータはパフォーマンスの目的でキャッシュに維持され、復元の目的でストアに書き込まれます。
@Resource
アノテーションを使用すると、HotRod クライアントを直接 Jakarta EE アプリケーションにインジェクトすることができます。@Resource
アノテーションはhotrod-client.properties
ファイルで、クラスパスの設定プロパティーを検索します。@Resource(lookup = "java:jboss/infinispan/remote-container/web-sessions") private org.infinispan.client.hotrod.RemoteCacheContainer client;
例:
hotrod-client.properties
ファイルinfinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory infinispan.client.hotrod.server_list = 127.0.0.1:11222 infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory infinispan.client.hotrod.default_executor_factory.pool_size = 1 infinispan.client.hotrod.default_executor_factory.queue_size = 10000 infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1 infinispan.client.hotrod.tcp_no_delay = true infinispan.client.hotrod.ping_on_startup = true infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy infinispan.client.hotrod.key_size_estimate = 64 infinispan.client.hotrod.value_size_estimate = 512 infinispan.client.hotrod.force_return_values = false ## below is connection pooling config maxActive=-1 maxTotal = -1 maxIdle = -1 whenExhaustedAction = 1 timeBetweenEvictionRunsMillis=120000 minEvictableIdleTimeMillis=300000 testWhileIdle = true minIdle = 1
リモートキャッシュコンテナーの保護
SSL を使用してリモート Red Hat Data Grid インスタンスへの通信をセキュアにすることが可能です。これを行うには、JBoss EAP インスタンスで remote-cache-container
を設定し、Red Hat Data Grid インスタンスで hotrod コネクターを調整してアクティブなセキュリティーレルムを使用するようにします。
JBoss EAP で
client-ssl-context
を作成します。他の elytron コンポーネントの生成など、client-ssl-context
作成のその他の詳細は、JBoss EAP の How to Configure Server Security の Using a client-ssl-context を参照してください。/subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
クライアント SSL コンテキストを使用するよう、リモートキャッシュコンテナーを設定します。
/subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
リモート Red Hat Data Grid インスタンスをセキュアにします。各インスタンスの必要に応じて手順を繰り返します。
-
client-ssl-context
で使用されるキーストアをリモート Red Hat Data Grid インスタンスにコピーします。 ApplicationRealm
を設定して、このキーストアを使用するようにします。/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:add(keystore-path="KEYSTORE_NAME",keystore-relative-to="jboss.server.config.dir",keystore-password="KEYSTORE_PASSWORD")
hotrod connector を調整して、このセキュリティーレルムを示すようにします。
/subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
リモート Red Hat Data Grid インスタンスをリロードします。
reload
-
22.3.9. リモートストアを使用した HTTP セッションの Red Hat Data Grid への外部化
この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。
この手順は、セッションを外部化する旧式の方法になります。JBoss EAP 7.2 には、elytron
サブシステムと統合する HotRod プロトコルをベースとするカスタムの最適化されたキャッシュストアが導入されました。HTTP セッションの Red Hat Data Grid への外部化 の説明に従って、新しい hotrod
ストアを使用することが推奨されます。
分散可能なアプリケーションごとに完全に新しいキャッシュを作成する必要があります。新しいキャッシュは web
などの既存のキャッシュコンテナーに作成できます。
HTTP セッションを外部化するには、以下を行います。
ネットワーク情報を
socket-binding-group
に追加することにより、リモート Red Hat Data Grid サーバーの場所を定義します。例: リモートソケットバインディングの追加
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server1:add(host=RHDGHostName1, port=11222) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server2:add(host=RHDGHostName2, port=11222)
結果の XML
<socket-binding-group name="standard-sockets" ... > ... <outbound-socket-binding name="remote-rhdg-server1"> <remote-destination host="RHDGHostName1" port="11222"/> </outbound-socket-binding> <outbound-socket-binding name="remote-rhdg-server2"> <remote-destination host="RHDGHostName2" port="11222"/> </outbound-socket-binding> </socket-binding-group>
注記各 Red Hat Data Grid サーバーにリモートソケットバインディングを設定する必要があります。
リモートキャッシュコンテナーが JBoss EAP の
infinispan
サブシステムで定義されているようにしてください。 以下の例では、remote-store
要素のcache
属性によって、リモート Red Hat Data Grid サーバーのキャッシュ名が定義されます。マネージドドメインで実行している場合は、コマンドの前に
/profile=PROFILE_NAME
を追加してください。例: リモートキャッシュコンテナーの追加
/subsystem=infinispan/cache-container=web/invalidation-cache=rhdg:add(mode=SYNC) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=locking:write-attribute(name=isolation,value=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=transaction:write-attribute(name=mode,value=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/store=remote:add(remote-servers=["remote-rhdg-server1","remote-rhdg-server2"], cache=default, socket-timeout=60000, passivation=false, purge=false, shared=true)
結果の XML
<subsystem xmlns="{InfinispanSubsystemNamespace}"> ... <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true"> <transport lock-timeout="60000"/> <invalidation-cache name="rhdg" mode="SYNC"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <remote-store cache="default" socket-timeout="60000" remote-servers="remote-rhdg-server1 remote-rhdg-server2" passivation="false" purge="false" shared="true"/> </invalidation-cache> ... </cache-container> </subsystem>