5.20. アプリケーションクラスタリングの変更

5.20.1. 新しいクラスタリング機能の概要

以下のリストは、アプリケーションを JBoss EAP 6 から JBoss EAP 7 へ移行するときに注意する必要がある新しいクラスタリング機能の一部を示しています。

  • JBoss EAP 7 には、シングルトンサービスのビルドを大幅に簡易化する、新しいパブリック API が導入されました。シングルトンサービスの詳細は JBoss EAP『開発ガイド』の「HA シングルトンサービス」を参照してください。
  • 一度にクラスターで単一のノードのみをデプロイおよび開始するよう、シングルトンデプロイメントを設定できます。詳細は、JBoss EAP『開発ガイド』の「HA シングルトンデプロイメント」を参照してください。
  • クラスター化されたシングルトン MDB を定義できるようになりました。詳細は、JBoss EAP『Developing EJB Applications 』で「Clustered Singleton MDBs」を参照してください。
  • JBoss EAP 7 には、Undertow mod_cluster 実装が含まれています。これは、http web サーバーを必要としない純粋な Java ロードバランシングソリューションを提供します。詳細は、JBoss EAP 『設定ガイド』の「JBoss EAP をフロントエンドロードバランサーとして設定」を参照してください。

本セクションの残りの部分では、クラスタリングの変更がアプリケーションの JBoss EAP 7 への移行に及ぼす可能性のある影響について説明します。

5.20.2. Web セッションクラスタリングの変更

JBoss EAP 7 では、新しい Web セッションクラスタリング実装が導入されました。これは、レガシーの JBoss Web サブシステムソースコードに密に結合された以前の実装に代わる実装です。

新しい Web セッションクラスタリング実装は、JBoss EAP プロプライエタリー Web アプリケーションの XML 記述子ファイルである jboss-web.xml にアプリケーションが設定される方法に影響します。以下は、このファイルのクラスタリング設定要素のみになります。 

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

以下の表は、jboss-web.xml ファイルの廃止された要素と同様の動作を実現する方法を説明しています。

設定要素変更の説明

<max-active-sessions/>

これまでの実装では、アクティブなセッションの数が <max-active-sessions/> によって指定された値を超えるとセッションの作成に失敗しました。

新しい実装では、<max-active-sessions/> を使用してセッションパッシベーションが有効化されます。セッションの作成によって、アクティブなセッションの数が <max-active-sessions/> を超える場合、新しいセッションが作成されるよう、セッションマネージャーが認識する最も古いセッションがパッシベートされます。

<passivation-config/>

この設定要素とサブ要素は JBoss EAP 7 では使用されないようになりました。

<use-session-passivation/>

以前の実装では、この属性を使用してパッシベーションが有効化されました。

新しい実装では、<max-active-sessions/> に負でない値を指定するとパッシベーションが有効化されます。

<passivation-min-idle-time/>

以前の実装では、パッシベーションの候補となる前にセッションは最小時間アクティブである必要がありました。そのため、パッシベーションが有効であってもセッションの作成に失敗することがありました。

新しい実装はこの論理をサポートしないため、サービス拒否 (DoS) 攻撃の発生を防ぎます。

<passivation-max-idle-time/>

以前の実装では、セッションは指定期間アイドル状態であった後にパッシベートされました。

新しい実装はレイジー (Lazy) パッシベーションのみをサポートします。イーガー (Eager) パッシベーションはサポートしません。セッションは、<max-active-sessions/> に準拠する必要があるときのみパッシベートされます。

<replication-config/>

新しい実装では複数のサブ要素が非推奨になりました。

<replication-trigger/>

以前の実装では、この要素を使用してセッションレプリケーションがトリガーされるタイミングを決定しました。新しい実装では、この設定は単一の堅牢なストラテジーに変更されました。詳細は、JBoss EAP『開発ガイド』の「変更不能なセッション属性」を参照してください。

<use-jk/>

以前の実装では、<use-jk/> に指定された値に応じて、指定のリクエストを処理するノードの instance-id が jsessionid の末尾に追加され、mod_jk、mod_proxy_balancer、mod_cluster などのロードバランサーによって使用されました。

新しい実装では、instance-id が定義されている場合は常に jsessionid の末尾に追加されるようになりました。

<max-unreplicated-interval/>

以前の実装では、この設定オプションは変更されたセッション属性がない場合にセッションのタイムスタンプがレプリケートされないようにする最適化を目的としていました。しかし、セッション属性が変更されたかどうかに関係なく、セッションのアクセスにはキャッシュトランザクション RPC が必要であるため、実際は RPC の実行を防ぐことはできません。

新しい実装では、リクエストごとにセッションのタイムスタンプがレプリケートされるようになりました。これにより、フェイルオーバーの後にセッションメタデータが陳腐化されないようにします。

<snapshot-mode/>

これまでは、<snapshot-mode/> を INSTANT または INTERVAL として設定することができました。Infinispan の非同期レプリケーションにより、この設定オプションは廃止になりました。

<snapshot-interval/>

これは <snapshot-mode>INTERVAL</snapshot-mode> にのみ関係しました。<snapshot-mode/> は廃止されたため、このオプションも廃止されました。

<session-notification-policy/>

以前の実装では、この属性によって指定された値はセッションイベントをトリガーするポリシーを定義しました。

新しい実装ではこの動作は仕様に応じて判断されるようになり、設定不可能になりました。

新しいこの実装は、ライトスルーキャッシュストアとパッシベーションのみのキャッシュストアもサポートします。通常、ライトスルーキャッシュストアはインバリデーションキャッシュとともに使用されます。JBoss EAP 6 の web セッションクラスタリング実装は、インバリデーションキャッシュの使用時に適切に動作しませんでした。

5.20.3. ステートフルセッション EJB クラスタリングの変更

JBoss EAP 6 では、以下の方法の 1 つでステートフルセッション Bean (SFSB) のクラスタリング動作を有効化する必要がありました。

  • セッション Bean に org.jboss.ejb3.annotation.Clustered アノテーションを追加。 

    @Stateful
@Clustered
public class MyBean implements MySessionInt {

   public void myMethod() {
      //
   }
}

  • <clustered> 要素を jboss-ejb3.xml ファイルに追加。 

    <c:clustering>
  <ejb-name>DDBasedClusteredSFSB</ejb-name>
  <c:clustered>true</c:clustered>
</c:clustering>

JBoss EAP 7 では、クラスタリング動作を有効にする必要がなくなりました。デフォルトでは、HA プロファイルを使用してサーバーが起動された場合は SFSB の状態が自動的にレプリケートされます。

以下の方法の 1 つを使用すると、このデフォルト動作を無効にできます。

  • EJB 3.2 仕様に新たに導入された @Stateful(passivationCapable=false) を使用して単一のステートフルセッション Bean のデフォルト動作を無効化します。
  • サーバー設定の ejb3 サブシステムの設定で、この動作をグローバルに無効化します。
注記

@Clustered アノテーションがアプリケーションから削除されると、このアノテーションは無視され、アプリケーションのデプロイメントには影響しません。

5.20.4. クラスタリングサービスの変更

JBoss EAP 6 では、クラスタリングサービスの API はプライベートモジュールでサポートされませんでした。

JBoss EAP 7 には、アプリケーションによって使用されるパブリッククラスタリングサービス API が導入されました。新しいサービスは、ライトウェイトで簡単にインジェクトできるよう設計されています。 外部の依存関係は必要ありません。

  • 新しい org.wildfly.clustering.group.Group インターフェースを使用すると、現在のクラスター状態へアクセスでき、クラスターメンバーシップの変更をリッスンできます。
  • 新しい org.wildfly.clustering.dispatcher.CommandDispatcher インターフェースを使用すると、すべてのノードまたはノードの選択されたサブセットのクラスターでコードを実行できます。

これらのサービスは、JBoss EAP 5 の HAPartition、JBoss EAP 6 の GroupCommunicationService、GroupMembershipNotifier、および GroupRpcDispatcher に代わるサービスです。 これらの API は以前のリリースで利用できました。

詳細は、JBoss EAP『開発ガイド』の「クラスタリングサービスのパブリック API」を参照してください。

5.20.5. クラスタリング HA シングルトンの移行

JBoss EAP 6 では、クラスター全体の HA シングルトンサービスに使用できるパブリック API がありませんでした。プライベートの org.jboss.as.clustering.singleton.* クラスを使用した場合、アプリケーションを JBoss EAP 7 に移行するときに新しいパブリックの org.wildfly.clustering.singleton.* パッケージを使用するようコードを変更する必要があります。

HA シングルトンに関する詳細は、JBoss EAP『開発ガイド』の「HA シングルトンサービス」を参照してください。HA シングルトンのデプロイメントに関する詳細は、JBoss EAP『開発ガイド』の「HA シングルトンデプロイメント」を参照してください。