Javaアプリケーションサーバのクラスタリング機能比較第3回

注意点

JBossでクラスタリングを行う場合の注意点をあげます。

本当にレプリケーションは必要か

レプリケーションはシステムの可用性を向上するものですが、アプリケーションの作りによってはセッション情報が途中で失われても問題がない場合もあるでしょう。レプリケーションによるパフォーマンス劣化と天秤にかけて、採用を決定すべきです。セッションレプリケーション抜きの単純な「ロードバランス＋スティッキーセッション」であれば、クラスタ台数に応じたリニアなパフォーマンス向上を期待できます。

何をクラスタリングするか

Webアプリケーションにおいて、Web層を入り口にしてステートレスセッションBeanでビジネスロジックを行うアーキテクチャの場合は、 HTTPセッションレプリケーションだけで十分でしょう。EJBのクラスタリングはリモートクライアントがEJBアクセスする際に必要になってきます。

all-to-all

JBossのレプリケーションは第2回で解説したTomcatと同様に"all-to-all"方式です。そのためクラスタのノード数が多くなるとレプリケーションによるオーバーヘッドが増大します。この問題に関してJBossは将来的に"sub-partition"をサポートし、これらのオーバーヘッドを削減することを計画しています。

JBossのバージョン

JBossはメンテナンスバージョン（x.x.xの最下位桁）のバージョンアップでも、しばしば設定のデフォルト値が変わります。例えば"tc5-cluster-service.xml"のCacheModeは、JBoss 4.0.2から「REPL_SYNC → REPL_ASYNC」に変わりました。新しいバージョンを試す場合には、リリースノートも重要ですが各設定ファイルにざっと目を通すことをお勧めします。

最後に

JBossはバージョン3以降、エンタープライズ環境での採用を意識して商用製品レベルの機能をどんどん取り込んでいます。現在JBossはPOJO／アスペクトベースのアプリケーションサーバを目指して新バージョンの開発を進めていますが、クラスタリング機能の設定の容易さや、パフォーマンスの向上なども期待したいところです。

次回は商用J2EEサーバの代表として、WebLogicのクラスタリングを見ていきます。