PR

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:コネクタ比較

ConnectorProtocolLoad Balancing
AJPHTTPHTTPSSticky SessionMethod
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_proxymod_jkmod_cluster
処理リクエスト数(ラウンドロビン)
転送量
待機リクエスト数(リーストコネクション)
セッション数
APサーバ情報

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

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

コネクタ性能検証環境

図3:コネクタ性能検証環境

表5:コネクタ性能比較

mod_proxymod_jkmod_cluster
Requests per second545351574284

表5の結果から、mod_clusterは他の2つのコネクタと比べると処理性能が低いことがわかります。APサーバ側の負荷情報で振り分ける機能は魅力的ですが、利用する場合は実効性能に注意する必要がありそうです。

TIS株式会社 コーポレート本部 戦略技術センター 主任

学生の頃にLinuxで構築された研究室のシステムに影響を受けOSS関連の業務に進む。システムインテグレーションやOSサポートを経験し、2012年からは戦略技術センターにてOSSを利用した新規技術の開発や検証などを行っている。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています