24.3. Infinispan

24.3.1. Infinispan

Infinispan は Java データグリッドプラットフォームで、キャッシュされたデータの管理に JSR-107 準拠のキャッシュインターフェイスを提供します。キャッシュされたデータの管理と同等の Jakarta は Jakarta Persistence 2.2 です。

Infinispan の機能や設定オプションの詳細は Infinispan のドキュメント を参照してください。

infinispan サブシステムは JBoss EAP のキャッシュサポートを提供します。名前付きのキャッシュコンテナーやキャッシュのランタイムメトリックスを設定および表示できます。

高可用性の機能を提供する設定を使用する場合 (管理対象ドメインでは hafull-ha プロファイル、スタンドアロンサーバーは standalone-ha.xmlstandalone-full-ha.xml 設定ファイル)、infinispan サブシステムはキャッシング、状態のレプリケーション、および状態分散サポートを提供します。高可用性でない設定では、infinispan サブシステムはローカルのキャッシュサポートを提供します。

重要

Infinispan は JBoss EAP のプライベートモジュールとして含まれ、JBoss EAP のキャッシュ機能を提供します。アプリケーションによる Infinispan の直接使用はサポートされません。

24.3.2. キャッシュコンテナー

キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。各キャッシュコンテナーは、使用されるデフォルトのキャッシュを定義します。

JBoss EAP 7 は以下のデフォルト Infinispan キャッシュコンテナーを定義します。

  • server (シングルトンキャッシング)
  • web (Web セッションクラスターリング)
  • ejb (ステートフルセッション Bean クラスターリング)
  • hibernate (エンティティーキャッシング)

例: Infinispan のデフォルト設定

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
  <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 キャッシュが使用されます。

デフォルトキャッシュの変更やキャッシュの追加に関する詳細は、キャッシュコンテナーの設定 を参照してください。

重要

HTTP セッション、ステートフルセッション Bean、シングルトンサービスやデプロイメントなどのキャッシュやキャッシュコンテナーを追加できます。ユーザーアプリケーションによるこれらのキャッシュの直接使用はサポートされません。

24.3.2.1. キャッシュコンテナーの設定

キャッシュコンテナーやキャッシュ属性は、管理コンソールまたは管理 CLI を使用して設定できます。

警告

設定の他のコンポーネントが参照する可能性があるため、キャッシュまたはキャッシュコンテナーの名前を変更しないでください。

管理コンソールを使用したキャッシュの設定

管理コンソールの Configuration タブで Infinispan サブシステムを選択するとキャッシュやキャッシュコンテナーを設定できます。管理対象ドメインでは設定するプロファイルを選択してください。

  • キャッシュコンテナーを追加します。

    Cache Container の横にある追加 (+) ボタンをクリックし、Cache Container を追加 を選択して新しいキャッシュコンテナーの設定を入力します。

  • キャッシュコンテナー設定を更新します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。必要に応じてキャッシュコンテナーの設定を行います。

  • キャッシュコンテナートランスポート設定を更新します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。Transport タブで、必要に応じてキャッシュコンテナートランスポートを設定します。

  • キャッシュを設定します。

    該当するキャッシュコンテナーを選択し、表示 を選択します。キャッシュタブ (Replicated Cache など) でキャッシュを追加、更新、および削除できます。

管理 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)

以下の例は、concurrent 分散キャッシュを web キャッシュコンテナーに追加する方法を表しています。このキャッシュ設定はデフォルトキャッシュのロック制約を緩和し、複数の同時リクエストが同じ web セッションに同時にアクセスできるようにします。これは、ロックのない読み取りを許可し、排他的ロックをより頻繁により短期間で取得することで実現されます。

以下の CLI コマンドを使用して concurrent 分散キャッシュを web キャッシュコンテナーに追加し、デフォルトのキャッシュにします。

batch
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent:add
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=concurrent)
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent/store=file:add
run-batch

これにより、サーバーが以下のように設定されます。

<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan">
  ...
  <distributed-cache name="concurrent">
      <file-store/>
  </distributed-cache>
</cache-container>
デフォルト EJB キャッシュコンテナーの変更

以下のようにキャッシュコンテナーを ejb3 サブシステムで使用できます。

  • EJB セッション bean のパッシベーションをサポートするには、infinispan サブシステムに定義された ejb キャッシュコンテナーを使用してセッションを保存できます。
  • サーバー上でクラスター化されたデプロイメントに接続するリモート EJB クライアントの場合、クラスタートポロジーの情報をこれらのクライアントに提供して、これらのクライアントが対話するノードに障害が発生したときにクラスターの別のノードにフェイルオーバーできるようにする必要があります。

パッシベーションやトポロジー情報の提供をサポートするデフォルトのキャッシュコンテナー ejb を変更する場合や、その名前を変更する場合、以下の例のように cache-container 属性を passivation-stores 要素に追加し、cluster 属性を remote 要素に追加する必要があります。独自に使用するために新しいキャッシュを追加する場合は、このような変更を加える必要はありません。

<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
    <passivation-stores>
        <passivation-store name="infinispan" cache-container="ejb-cltest" max-size="10000"/>
    </passivation-stores>

    <remote cluster="ejb-cltest" connector-ref="http-remoting-connector" thread-pool-name="default"/>
</subsystem>

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
    ...
    <cache-container name="ejb-cltest" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
</subsystem>
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 ユーザーガイドの エビクションおよびデータコンテナー セクションを参照し てください。

24.3.3. クラスターリングモード

JBoss EAP で Infinispan を使用すると、2 つの方法でクラスターリングを設定できます。ご使用のアプリケーションに最も適した方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、およびスケーラビリティーのトレードオフが発生します。クラスターリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取ることが必要となります。

キャッシュモード
Replication (レプリケーション)
Replication (レプリケーション) モードはクラスターの新しいインスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常 Replication モードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。
Distribution (分散)

Distribution (分散) モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数 (または所有者数) は設定可能です。保持するコピー数、データの永続性、およびパフォーマンスにはトレードオフが生じます。保持するコピー数が多いほどパフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータを損失する可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。

クラスターサイズが 6-8 ノードを超える場合は Distribution モードをキャッシュストラテジーとして使用することを考慮してください。Distribution モードでは、データはクラスター内のすべてのノードではなくノードのサブセットのみに分散されます。

Scattered (散在)

Scattered (散在) モードは、一貫したハッシュアルゴリズムを使用して所有者を判断する Distribution モードと似ています。しかし、所有者は 2 名のメンバーに限定され、オリジネーター (指定のセッションのリクエストを受信するノード) は常にロックを調整する所有者やキャッシュエントリーの更新を想定します。2 名の所有者を持つ分散キャッシュが頻繁に 2 つの RPC 呼び出しを使用できる場合、Scattered モードで使用されるキャッシュ書き込みアルゴリズムは、書き込み操作の結果が単一の RPC 呼び出しになることを保証します。これは、ロードバランサーのフェイルオーバーがプライマリー以外の所有者やバックアップノードにトラフィックを向ける可能性があるため、分散 Web セッションに便利です。これにより、競合の可能性を下げ、クラスタートポロジーの変更後にパフォーマンスを向上することが可能になります。

Scattered モードは、トランザクションや L1 キャッシュをサポートしません。しかし、一貫したハッシュによると所有者ではない場合でも、指定エントリーのキャッシュの書き込みを開始するノードは一定の期間は継続してそのエントリーの読み取りを継続する、バイアス読み取り (Biased read) をサポートします。バイアス読み取りと L1 キャッシュの設定属性は異なりますが、L1 キャッシュと同様の効果があります。

同期および非同期のレプリケーション

レプリケーションは同期または非同期モードで実行でき、選択するモードは要件やアプリケーションモードによって異なります。

重要

JBoss EAP 7.1 以降では、常に同期 (SYNC) キャッシュモードを使用する必要があります。sync はデフォルトのキャッシュモードです。非同期 (ASYNC) モードの使用は有効ではないため、ロック競合が発生します。セッションレプリケーションと適切なキャッシュモードの詳細は、How to configure and tune the session replication for EAP を参照してください。

同期のレプリケーション
同期のレプリケーションでは、レプリケーションプロセスはユーザーのリクエストを処理するのと同じスレッドで実行されます。セッションレプリケーションは、完了した応答がクライアントに返送された後に開始され、スレッドはレプリケーションの完了後のみに解放されます。同期レプリケーションはクラスターの各ノードからの応答を必要とするため、ネットワークトラフィックに影響を与えます。ただし、クラスターのすべてのノードへ確実に変更が加えられる利点があります。
非同期のレプリケーション
非同期のレプリケーションでは、Infinispan はスレードプールを使用してバックグラウンドでレプリケーションを実行します。送信元はクラスターの他のノードからの返答を待ちません。しかし、同じセッションを読み取るキャッシュはその前のレプリケーションが完了するまでブロックされるため、陳腐データは読み取られません。レプリケーションは時間ベースまたはキューのサイズによって引き起こされます。失敗したレプリケーションはログに書き込まれ、リアルタイムで通知されません。

24.3.3.1. キャッシュモードの設定

管理 CLI を使用してデフォルトキャッシュを変更できます。

注記

ここでは、デフォルトが Distribution モードである Web セッションキャッシュの設定に固有する手順を説明します。手順と管理 CLI コマンドは、他のキャッシュコンテナー向けに簡単に調整できます。

Replication キャッシュモードへの変更

Web セッションキャッシュのデフォルトの JBoss EAP 7 設定には、レプリケートされたキャッシュ repl が含まれていません。最初にこのキャッシュを追加する必要があります。

注記

以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. レプリケーションキャッシュ repl を追加し、デフォルトのキャッシュとして設定します。

    batch
    /subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode=ASYNC)
    /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
  2. サーバーをリロードします。

    reload
Distribution キャッシュモードへの変更

Web セッションキャッシュのデフォルトの JBoss EAP 7 設定にはすでに dist 分散キャッシュが含まれています。

注記

以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. デフォルトのキャッシュを dist 分散キャッシュに変更します。

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
  2. 分散キャッシュの所有者数を設定します。以下のコマンドは所有者の数を 5 に設定します。デフォルトは 2 です。

    /subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
  3. サーバーをリロードします。

    reload
Scattered キャッシュモードの変更

web セッションキャッシュのデフォルトの JBoss EAP 設定には scattered-cache が含まれていません。以下の例は、scattered キャッシュを追加し、デフォルトのキャッシュとして設定する管理 CLI コマンドを示しています。

注記

以下は、HA プロファイルを使用するスタンドアロンサーバー向けの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan コマンドの前に /profile=PROFILE_NAME を追加し、更新するプロファイルを指定する必要があります。

  1. 読み取りのバイアスライフスパンがデフォルトの web セッションタイムアウト値 (30 分) と同じになるよう、scattered キャッシュを作成します。

    /subsystem=infinispan/cache-container=web/scattered-cache=scattered:add(bias-lifespan=1800000)
  2. scattered をデフォルトキャッシュとして設定します。

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=scattered)

これにより、サーバーが以下のように設定されます。

<cache-container name="web" default-cache="scattered" module="org.wildfly.clustering.web.infinispan">
    ...
    <scattered-cache name="scattered" bias-lifespan="1800000"/>
    ...
</cache-container>

24.3.3.2. キャッシュストラテジーのパフォーマンス

SYNC キャッシュストラテジーを使用すると、レプリケーションが完了するまでリクエストが完了しないため、レプリケーションのコストを簡単に評価でき、直接応答時間に影響します。

ASYNC キャッシュストラテジーの応答時間は SYNC キャッシュストラテジーよりも短いと思われがちですが、一定の状況下でのみ短くなります。ASYNC キャッシュストラテジーの評価はより困難ですが、リクエスト間の時間がキャッシュ操作を完了できるほど長い場合はパフォーマンスが SYNC よりも良くなります。これは、レプリケーションのコストが応答時間に即影響しないためです。

同じセッションのリクエストの作成が早すぎると、先行リクエストからのレプリケーションが完了するまで待機しなければならないため、先行リクエストのレプリケーションコストが後続リクエストの前に移動します。応答の受信直後に後続リクエストが送信され、リクエストが急速に発生する場合、 ASYNC キャッシュストラテジーのパフォーマンスは SYNC よりも劣化します。そのため、同じセッションのリクエストの間には、SYNC キャッシュストラテジーのパフォーマンスが ASYNC キャッシュストラテジーよりも良くなる期間のしきい値があります。実際の使用状態では、通常同じセッションのリクエストが立て続けに受信されることはありませんが、一般的にリクエストの間に数秒程度の時間が存在します。その代わりに、通常、要求間に数秒以上の時間が経過します。この場合、ASYNC キャッシュストラテジーが適切なデフォルトで、応答時間が早くなります。

24.3.4. 状態遷移

状態遷移は、基本的なデータグリッドとクラスター化されたキャッシュ機能の両方です。状態遷移がない状態では、ノードがクラスターに追加されたり、クラスターから削除されるとデータが失われます。

状態遷移は、キャッシュメンバーシップの変更に応じて、キャッシュの内部状態を調整します。この変更は、ノードがクラスターに参加または退出するとき、2 つ以上のクラスターパーティションがマージするとき、またはこれらのイベントの組み合わせが発生した後に自動的に行われます。新しいキャッシュは、以下のキャッシュのモードを基にして、最大量の状態を受け取る必要があるため、新たに開始されたキャッシュの最初の状態遷移は最も多くのリソースが必要となります。

timeout 属性を使用すると、新たに開始されたキャッシュが状態を受け取る待ち時間を制御することができます。timeout 属性が正の値である場合、キャッシュはすべての初期状態を受け取るまで待機した後、リクエストに対応できるようになります。状態遷移が指定時間内 (デフォルトは 240000 ミリ秒) に完了しなかった場合、キャッシュによってエラーが発生し、開始がキャンセルされます。timeout0 に設定するとキャッシュは即座に利用可能になり、バックグラウンド操作中に最初の状態を受け取ります。最初の状態遷移が完了するまで、キャッシュが受け取っていないキャッシュエントリーのリクエストは、リモートノードから取得する必要があります。

timeout 属性を 0 に設定するには、以下のコマンドを実行します。

/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)

状態遷移の挙動はキャッシュのモードによって決まります。

  • Replicated (レプリケート) モードでは、キャッシュに参加する新規ノードは既存ノードからキャッシュの状態をすべて受け取ります。ノードがクラスターから退出すると、状態遷移はありません。
  • Distribution (分散) モードでは、新しいノードは既存のノードから状態の一部のみを受け取り、既存のノードは一貫したハッシュの決定どおりに、各キーの owners コピーを維持するために状態の一部を削除します。ノードがクラスターから退出する場合、分散キャッシュはそのノードに保存されたキーの追加コピーを作成し、各キーの所有者が存続するようにする必要デフォルトがあります。
  • Invalidation (インバリデーション) モードでは、最初の状態推移は Replicated モードと似ていますが、ノードが同じ状態でいられる保証がないことが唯一の違いです。ノードがクラスターから退出すると、状態遷移はありません。

デフォルトでは、状態遷移はインメモリーおよび永続状態の両方を遷移しますが、設定で無効にすることもできます。状態遷移が無効になっている場合、ClusterLoader を設定しないと、データをキャッシュにロードせずにノードがキーの所有者またはバックアップ所有者になります。さらに、Distribution モードで状態遷移が無効になっていると、キャッシュでキーのコピーが owners コピーよりも少なくなることがあります。

24.3.5. Infinispan スレッドプールの設定

infinispan サブシステムには async-operationsexpirationlistenerpersistenceremote-commandstate-transfer、および transport スレッドプールが含まれます。これらのプールはすべての Infinispan キャッシュコンテナーに設定できます。

以下の表は、infinispan サブシステムの各スレッドプールに設定できる属性とデフォルト値を表しています。

スレッドプール名keepalive-timemax-threadsmin-threadsqueue-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")

24.3.6. Infinispan の統計

監視目的で、Infinispan キャッシュやキャッシュコンテナーに関する実行時統計を有効にできます。パフォーマンス上の理由で、統計の収集はデフォルトでは無効になっています。

統計収集は、各キャッシュコンテナー、キャッシュ、または両方に対して有効にできます。各キャッシュの統計オプションはキャッシュコンテナーのオプションをオーバーライドします。キャッシュコンテナーの統計収集を無効または有効にすると、独自の設定が明示的に指定されている場合以外はそのコンテナーのすべてのキャッシュが設定を継承します。

24.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)

24.3.7. Infinispan パーティションの処理

Infinispan クラスターは、データが保存される複数のノードで構築されます。複数のノードに障害が発生した場合のデータの損失を防ぐため、Infinispan は複数のノードで同じデータをコピーします。このレベルのデータ冗長性は owners 属性を使用して設定されます。設定されたノードの数未満のノードが同時にクラッシュしても、Infinispan はデータのコピーを利用できます。

しかし、クラスターから大量のノードが消滅すると最悪の事態を招く可能性があります。

スプリットブレイン

スプリットブレインはクラスターを独立して動作する 2 つ以上のパーティションまたはサブクラスターに分割します。このような場合、異なるパーティションから読み書きする複数のクライアントが同じキャッシュエントリーの異なるバージョンを見ることになり、多くのアプリケーションにとって問題となります。

注記

スプリットブレインの発生を軽減する方法には、冗長化ネットワークや IP ボンディング などがあります。 しかし、これらの方法は問題発生のリードタイムを削減するだけです。

複数ノードの連続クラッシュ
複数のノード (所有者の数) が連続してクラッシュし、Infinispan がクラッシュ間の状態を適切に調整する時間がない場合、結果として部分的なデータの損失が発生します。

スプリットブレインや複数ノードの連続クラッシュが原因で、不適切なデータがユーザーに返されないようにすることが大切です。

24.3.7.1. スプリットブレイン

スプリットブレインが発生した場合、各ネットワークパーティションが独自の JGroups ビューをインストールし、他のパーティションからノードを削除します。パーティションはお互いを認識しないため、クラスターが 2 つ以上のパーティションに分割されたかどうかを直接判断することはできません。そのため、明示的な脱退メッセージを送信せずに、1 つ以上のノードが JGroups クラスターから消滅した場合にクラスターが分割されたと判断します。

パーティション処理が無効の場合、各パーティションは継続して独立したクラスターとして機能します。各パーティションはデータの一部のみを認識できる可能性があり、競合する更新をキャッシュに書き込む可能性があります。

パーティション処理が有効の場合、スプリットを検出したときに各パーティションは即座にリバランスを行わず、degrade モードにするかどうかを最初にチェックします。

  • 1 つ以上のセグメントがすべての所有者を失った場合 (最後に行ったリバランスが完了した後に指定した所有者の数以上が脱退した場合)、パーティションは degrade モードになります。
  • 最新の安定したトポロジーでパーティションに単純多数のノード (floor(numNodes/2) + 1) が含まれない場合も、パーティションは degrade モードになります。
  • その他の場合は、パーティションは通常通り動作し、リバランスを開始します。

安定したトポロジーは、リバランス操作が終了するたびに更新され、コーディネーターによって他のリバランスが必要ないと判断された場合に毎回更新されます。これらのルールは、1 つのパーティションが available モードを維持し、他のパーティションが degraded モードになるようにします。

パーティションが degraded モードの場合、完全に所有されたキーへのアクセスのみを許可します。

  • このパーティション内のノード上のコピーをすべて持つエントリーのリクエスト (読み取りおよび書き込み) は許可されます。
  • 消滅したノードによって完全所有または一部所有されたエントリーのリクエストは AvailabilityException によって拒否されます。

これにより、パーティションが同じキーに異なる値を書き込めないようにし (キャッシュの一貫性を保つ) 、さらにパーティションが他のパーティションで更新されたキーを読み取れないようにします (陳腐データをなくす)。

注記

2 つのパーティションは分離して開始できます。これらのパーティションはマージされなければ不整合なデータを読み書きできます。 将来的に、この状況に対処できるカスタムの可用性ストラテジーが許可される可能性があります (例: 特定のノードがクラスターの一部であるかを確認、外部のマシンにアクセスできるかどうかを確認など)。

24.3.7.2. パーティション処理の設定

現在、パーティションの処理はデフォルトで無効になっています。パーティションの処理を有効にするには、以下の管理 CLI コマンドを使用します。

/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=enabled, value=true)

24.3.8. リモートキャッシュコンテナーの設定

管理対象ドメインのすべてのサーバーグループにリモートキャッシュを設定する必要があります。statistics-enabled 属性により、指定の remote-cache-container および関連するランタイムキャッシュについてのメトリクスのコレクションを有効にできます。

24.3.8.1. リモートキャッシュコンテナーの作成

管理対象ドメインの各サーバーグループには、一意のリモートキャッシュが必要です。このキャッシュは、同じデータグリッドに所属することができます。そのため、ユーザーは、サーバーグループのソケットバインディングを定義し、ソケットバインディングをリモートキャッシュコンテナーに関連付けることにより、すべてのサーバーグループのリモートキャッシュを設定する必要があります。

手順

  1. socket-binding を定義します。 クラスターの各リモート Red Hat Data Grid インスタンスの必要に応じて、コマンドを繰り返し実行します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
  2. 新規作成されたソケットバインディングを参照する 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

24.3.8.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()

24.3.9. 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 のスタンドアロンインスタンスと管理対象ドメインの両方に適用されます。

  1. remote-cache-container を作成します。詳細は、リモートキャッシュコンテナーの設定 を参照してください。
  2. HotRod ストアを設定します。HotRod ストアは、JBoss EAP サーバーによって作成された各キャッシュに対して専用のリモートキャッシュを 1 つ使用します。通常、以下の CLI スクリプトのように、JBoss EAP サーバーで 1 つのインバリデーション キャッシュが使用されます。

    注記

    Red Hat JDG サーバーでリモートキャッシュを手作業で設定する必要があります。これらのキャッシュに推奨される設定は、楽観的ロックを持つトランザクション分散モードです。キャッシュ名はデプロイメントファイル名に対応する必要があります (例: 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 コネクターを調整してアクティブなセキュリティーレルムを使用するようにします。

  1. JBoss EAP で client-ssl-context を作成します。他の elytron コンポーネントの生成など、client-ssl-context 作成のその他の詳細は、JBoss EAPHow to Configure Server SecurityUsing a client-ssl-contextを参照してください。

    /subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
  2. クライアント SSL コンテキストを使用するよう、リモートキャッシュコンテナーを設定します。

    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
  3. リモート Red Hat Data Grid インスタンスをセキュアにします。各インスタンスの必要に応じて手順を繰り返します。

    1. client-ssl-context で使用されるキーストアをリモート Red Hat Data Grid インスタンスにコピーします。
    2. 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")
    3. hotrod コネクターを調整して、このセキュリティーレルムを示すようにします。

      /subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
    4. リモート Red Hat Data Grid インスタンスをリロードします。

      reload

24.3.10. リモートストアを使用した HTTP セッションの Red Hat Data Grid への外部化

注記

この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。

この手順は、セッションを外部化する旧式の方法になります。JBoss EAP 7.2 には、elytron サブシステムと統合する HotRod プロトコルをベースとするカスタムの最適化されたキャッシュストアが導入されました。HTTP セッションの JBoss Data Grid への外部化 の説明にしたがって、新しい hotrod ストアを使用することが推奨されます。

注記

分散可能なアプリケーションごとに完全に新しいキャッシュを作成する必要があります。新しいキャッシュは web などの既存のキャッシュコンテナーに作成できます。

HTTP セッションを外部化するには、以下を行います。

  1. ネットワーク情報を 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 サーバーにリモートソケットバインディングを設定する必要があります。

  2. リモートキャッシュコンテナーが 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="urn:jboss:domain:infinispan:7.0">
      ...
      <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>

  3. キャッシュ情報をアプリケーションの jboss-web.xml ファイルに追加します。以下の例では、web はキャッシュコンテナーの名前で、rhdg はこのコンテナーにある適切なキャッシュの名前になります。

    例: jboss-web.xml ファイル

    <?xml version="1.0" encoding="UTF-8"?>
    <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
               version="10.0">
        <replication-config>
            <replication-granularity>SESSION</replication-granularity>
            <cache-name>web.rhdg</cache-name>
        </replication-config>
    </jboss-web>