TOP
＞
設計・移行・活用
＞ クラスタリングの注意点
オープンソースJ2EE APサーバ JBossの可能性
第５回：JBossの固有機能
著者：
ダイテックＣ＆Ｄ 高橋 康弘
2005/5/27
前のページ
1
2
3
4
次のページ
クラスタリングの注意点
JBossのクラスタリングを利用する上での注意点をいくつか指摘しておきます。JBossのクラスタリングはネットワーク越しにステートをレプリケートしますので、オーバヘッドが発生します。オーバヘッドの原因は先の連載で述べた通り「シリアライゼーション」が多発するためです。特にステートフル・セッションBeanの場合はオーバヘッドがより大きくなります。
そしてこのオーバヘッドは、クラスタに参加させるノード（サーバ）の数が増えるに従って増大していきます。ですから、クラスタに参加させるノードの数は2〜4台程度にとどめておくのが無難でしょう。
また、JBossのクラスタリングは「パーティション」といった論理的なグループ単位で行われます。そのため、システム全体でひとつのクラスタリングを構成するのではなく、機能単位でパーティションを定義して、できるだけクラスタリングに参加するノード数を制限した方が良いでしょう。
クラスタリング構成を検討する場合は、次のような事項を考慮した上で導入を決定しましょう。
ハードウェアロードバランサ＋スティッキー・セッションだけでは不十分なのか？
一部ハードウェア障害が発生したときに、ユーザに再ログオンしてもらうことは許容できないか？また、メモリ上のデータ（ショッピングカートなど）が消えてしまうことは許容できないか？
ステートフル・セッションBeanが必要か？ステートレス・セッションBeanで代替できないか？
ファーミング
クラスタリング構成を導入すると、ノード数の増加に伴って管理対象が増えるため、管理が大変になります。こういった管理の手間を軽減するためのしくみとして、JBossには「ファーミング」と呼ばれる機能が搭載されています。ファーミングを利用することにより、クラスタ内のノードすべてに対して一度にアプリケーションの更新をかけることが可能となります。
具体的には、クラスタを構成している1ノードの、決められたディレクトリ（デフォルトでは$JBOSS_HOME\server\farm）にEARなどのファイルを配置することにより、自動的にクラスタ内の全ノードに対してそのコピーが配布され、それぞれのノードにてホットデプロイが実行されます。ファーミングはall設定を利用すれば、自動的に有効となります（注2）。
※注2：
それぞれの設定は下記のファイルで行います。
クラスタリングの設定： $JBOSS_HOME\server\all\deploy\cluster-service.xml
ファーミングの設定： $JBOSS_HOME\server\all\deploy\deploy.last\farm-service.xml
JBossCache
JBossCacheは、その名前の通りオブジェクトやデータのキャッシュを管理して、パフォーマンスを向上させることを目的として最近開発されたものです。JBossCacheが開発される以前でも、EJBの仕様にもある通り、ローカルオブジェクトのキャッシュ自体はJBoss内部で既に実装されていました。しかし、JBossCacheはこの枠を超えて、クラスタ構成の場合であってもキャッシュを利用しようという目的で開発されました。
先のクラスタの説明で触れましたが、クラスタリング構成を採用して可用性を高めると、シリアライゼーションが発生してオーバヘッドが大きくなり、パフォーマンスを落としてしまいます。しかしJBossCacheはこの相反する要求を実現するべく開発され、そして今も改良が続けられています。
クラスタリング構成でパフォーマンスが低下する最大の理由はシリアライゼーションです。このシリアライゼーションを回避するためにキャッシュを利用するというのがJBossCacheの基本的な考え方です。
前のページ
1
2
3
4
次のページ
著者プロフィール
株式会社ダイテックＣ＆Ｄ 高橋 康弘
入社以来Windowsを中心としたアプリケーション開発に従事。2000年頃からJavaを扱うようになり、2年ほど前からオープンソースを利用したシステム開発を開始。最近はJBoss＋オープンソースの組み合わせでWEBアプリケーション開発に携わることが多い。
資格：JBoss認定コンサルタント
INDEX
第5回：JBossの固有機能
クラスタリング／ファーミング
クラスタリングの注意点
シリアライゼーションを低減させる
アスペクト指向プログラミングの例
