JBoss Fuseを使い倒す 〜その1：環境構築編〜

はじめに

今回は、JBoss Fuseを本格的に導入することを想定し、3つのシステム構成パターンによる、高可用性、負荷分散、集中管理の対応方法を説明します。

最初に、中小規模の導入によく見られる「ホットスタンバイ構成」と「負荷分散とホットスタンバイ構成」を紹介し、その後「大規模な負荷分散とホットスタンバイ構成」による大規模構成を紹介します。

ホットスタンバイ構成

この構成は高可用性を実現するため、Fuse全体を対象にしたホットスタンバイのシステム構成になります。まずは、サーバー1台でのホットスタンバイ構成例を以下に示します。

図1：ホットスタンバイ（サーバー1台）の構成例

同一の連携サービスを設定したFuseサーバーインスタンスを2個（Master系/Slave系）用意しておき、最初に起動されるサーバーインスタンスが「ロック」を取得し、Master系として稼働します。Master系のサーバーインスタンスが使用不可となった場合、Slave系のサーバーインスタンスがロックを取得し、自動的にMaster系に切り替わって連携サービスの提供を継続させる構成です。

FuseのMaster/Slaveの切り替えに利用される「ロック」は、Fileロック、JDBCロックから選択できます。一般的に、同一物理サーバー上にMaster/Slaveを構成する場合はFileロックを利用し、異なるサーバー上の場合はJDBCロックを採用することになります。

下記の図2は、JDBCロックを採用したサーバー2台での構成例です。

図2：ホットスタンバイ（サーバー2台）の構成例

ホットスタンバイの利点

Slave系のOS及びFuseのコアコンポーネントが起動して待機するため、コールドスタンバイ構成よりもサービスの停止時間が短くて済みます。

ホットスタンバイの欠点

メッセージキューが共有されていないため、障害発生時にキューに滞留したメッセージをSlave系に引き継ぐことができません。またSlave系が待機状態のため、サーバーリソースの無駄が発生します。

負荷分散とホットスタンバイ構成

この構成は、Fuseのサーバーインスタンスを連携サービス（CXF、Camel）とメッセージングシステム（JBoss A-MQ、以下A-MQ）の役割で分割し、負荷分散とホットスタンバイを併用したシステム構成になります（図3）。

図3：負荷分散とホットスタンバイの構成例

同一の連携サービスを配置したFuseサーバーインスタンスを、複数同時起動します。また、共有のデータストアを利用するA-MQサーバーを複数用意し、最初に起動されるA-MQサーバーインスタンスが「ロック」を取得し、A-MQのMaster系として稼働します。Master系のサーバーインスタンスが使用不可になった場合、Slave系のサーバーインスタンスがロックを取得し、自動的にMaster系に昇格し、メッセージキューの滞留メッセージを継続処理させる構成です。

A-MQのMaster/Slave切り替え時には、メッセージキューの引き継ぎが必要となるため、データストアを共有しなければなりません。A-MQでは、データストアの共有方式は、共有ファイルシステムと共有データベースの2種類が提供されています。一般的に、構築の容易さと性能上の考慮から、共有ファイルシステムが採用されるケースが多いです。

「負荷分散とホットスタンバイ」の利点

Slave系A-MQが起動して待機するため、前述の「ホットスタンバイ構成」より、サービスの停止時間が短縮されます。また障害発生時にメッセージキューの滞留メッセージが継続処理され、処理順序も保証されます。

「負荷分散とホットスタンバイ」の欠点

スケールアウトの際のサーバーインスタンスの増設に伴い、環境構築、設定変更が初期導入時と同じ作業量が必要になるため、急な処理増加に対応できません。また可用性は「ホットスタンバイ構成」に比べて向上しますが、大規模な連携基盤として採用する場合、サーバーインスタンスの数が増えるほど、運用の複雑さから、保守コストが増えてしまいます。