JBossクラスタの概要と性能比較

連載 :

2014年12月24日(水)

第1回では商用版のJBoss Enterprise Application Platform（以下、EAP）とコミュニティ版のJBoss Application Server（以下、AS）と、Tomcatとの単体での性能（スループット、レスポンスタイム）の比較を行いました。今回はJBossクラスタについての説明と、クラスタ環境での性能比較について紹介します。

JBossクラスタの概要

図1：クラスタ構成の概要

JBossでクラスタを構成する場合、一般的には図1のようにクライアントからのアクセスをWebサーバ（Apache）で受け、Apacheに導入したコネクタモジュールからJBossクラスタの各ノードにリクエストを振り分ける構成になります。まずはJBoss側の構成について見てみましょう。

JBossクラスタ

APサーバ同士のクラスタを構成するためには、クラスタのノード間通信を行う機能と、各ノードが保持しているセッション情報をレプリケーションする機能の2つが必要になります。JBossの場合、ノード間通信はJGroupsサブシステム、セッションレプリケーションはInfinispanサブシステムを利用することで、クラスタ化を実現しています。

JGroups

JGroupsは、クラスタノード間の通信機能を提供します。haプロファイルもしくはfull-haプロファイルでは、デフォルトでUDPマルチキャスト通信による自動検出を行うよう設定されており、サーバを起動すると自動的にクラスタが構成されます。また通信にはTCPも利用できますので、マルチキャスト通信が許可されていないネットワークでもクラスタ構成を採れます。

Infinispan

Infinispanは、キャッシュ機能を提供するサブシステムです。JBossに含まれるInfinispanは、クラスタの内部利用を目的として組み込まれており、セッションレプリケーションはInfinispanを利用して実現しています。こちらもhaもしくはfull-haプロファイルには定義済みです。

キャッシュの同期方式と同期対象は、それぞれ表1、2の方式から選択可能です。

表1：キャッシュモード

モード	特徴
Replicationモード（デフォルト）	クラスタグループ内の全てのサーバノードに対して、キャッシュを複製する
Distributionモード	キャッシュのレプリケート先を、対象のクラスタグループ内の一部のみとする

表2：同期モード

モード	特徴
ASYNC（非同期）モード（デフォルト）	セッションレプリケーションの応答受信を非同期処理で行い、応答受信を待たずにクライアントにレスポンスを返す
SYNC（同期）モード	セッションレプリケーションの応答受信が全て完了してから、クライアントにレスポンスを返す

キャッシュモードをReplicationからDistributionに変更すると、クラスタ内でキャッシュを保持している台数が減るため信頼性は低下しますが、ノード間の通信量は減るので高速になります。また同期モードをASYNCからSYNCにすると、セッション情報の複製確認まで行うようになるため信頼性は高まりますが、同期待ちの増加により性能が低下することになります。

コネクタ

クライアントとJBossクラスタの間にWebサーバ（Apache）を設置してロードバランシングする場合、コネクタとしては以下の3つの選択肢があります。

Tomcat Connectors（mod_jk）
Apache Tomcatプロジェクトによって開発されているコネクタです。開発の歴史も古く情報も豊富なため、利用される方も多いようです。

Apache Proxyモジュール（mod_proxy）
Apache HTTPに標準で含まれているプロキシ用モジュールです。mod_proxyはいくつかのモジュールに分割されていて、APサーバとの通信を行う場合はmod_proxy_ajp、mod_proxy_httpといったモジュールを利用して通信します。

JBoss HTTP Connector（mod_cluster）
JBossコミュニティが開発しているコネクタモジュールです。mod_clusterは、JBossパッケージに含まれて配布されていますので、簡単に利用できます。

mod_jkやmod_proxyは、Webサーバ側に導入するコネクタです。一方mod_clusterは他の2つとは異なり、Webサーバ、APサーバそれぞれにモジュールを導入します（図2）。

図2：コネクタ構成の違い

コネクタが利用するプロトコルとロードバランシング方式を簡単にまとめると、表3のようになります。

表3：コネクタ比較

Connector	Protocol			Load Balancing
	AJP	HTTP	HTTPS	Sticky Session	Method
mod_jk	○	×	×	○	表4参照
mod_proxy	○	○	○	○
mod_cluster	○	○	○	○

利用できるプロトコルはmod_jkがAJPのみで、mod_proxyやmod_clusterはAJPに加えてHTTP、HTTPSも利用できます。したがってWebサーバとAP間の通信で暗号化（https）が必要といったような要件がある場合は、mod_jkは利用できないことになります。

ロードバランシングの方式について比較すると表4のようになります。

表4：ロードバランシング方式比較

ロードバランシング方式	mod_proxy	mod_jk	mod_cluster
処理リクエスト数（ラウンドロビン）	○	○	○
転送量	○	○	○
待機リクエスト数（リーストコネクション）	○	○	○
セッション数		○	○
APサーバ情報			○

ロードバランサとして一般的に選択されるラウンドロビン（処理リクエスト数）やリーストコネクション（待機リクエスト数）といった方式であれば、どのコネクタでも利用できます。
mod_jkやmod_proxyは、Webサーバ上で取得できる情報に基づいてリクエストの振り分け先を決定しますが、mod_clusterはこれに加えて、APサーバ側のCPU負荷やメモリ使用量といった情報も利用して振り分け先を決定できます。

コネクタの種類による性能の違いを見るために、Apacheに付属しているApache Benchを利用して簡単な試験を実施しました。各コネクタのロードバランシング方式は、処理リクエスト数による振り分けとし、単位時間あたりの処理リクエスト数を比較してみます（図3）。