エンティティBean

JBossとWebLogic ServerのエンティティBeanは、クラスタ間にまたがって整合性を維持する仕組みを有していません。複数のクライアントがそれぞれ別のクラスタノードに同時アクセスを行い、同一レコードをあらわすエンティティBeanにアクセスした場合には、どちらか一方の更新が反映されていない可能性があります。

読み込み専用のエンティティBeanの場合は更新されることがないので、この点を心配する必要はありません。しかし、読み書きをするエンティティBeanの場合は以下の設定をしなければなりません。

データベースレベルで行ロックをかける
データベースのトランザクション独立性レベルをSERIALIZABLEにする

表7：読み書きをするエンティティBeanの場合にする設定

この点はJBossとWebLogicに大差はありません。ただし、JBossにはcache invalidationという仕組みがあります。この仕組みを利用することにより、読み書きをするエンティティBeanにおいても値をキャッシュすることができます。ただし、完全なキャッシュではありません。詳しくは、「第4回：JBossのクラスタ設定」を参照してください。

その他のクラスタ機能

ここでは、サーブレットとEJB以外のクラスタ機能を解説します。

JMS

まずはJBossとWebLogic ServerのJMSのクラスタ機能を比較します。JBossのHA-JMSは、フェイルオーバーのみ実現しており、ロードバランシングは含まれていません。WebLogic Serverの場合は、分散キューという仕組みを利用することにより、フェイルオーバーとロードバランシングの両方を実現しています。

また、JBossのHA-JMSはクラスタノードにおいてストア先のデータベースは1つしか用意されていません。そのため、このデータベースも冗長化しておかなければ、可用性に問題が残ります。WebLogic ServerのJMSは、ストア先が分かれているので、複数のデータベースを利用することでこの問題を回避できます。

ただし、そのデータストアを利用しているWebLogic Serverが停止したときに処理されずにプールされていたメッセージは、停止したWebLogic Serverが復旧するまでは滞留することになります。もしすぐに処理を再開する場合には、マイグレーションを実施しなければなりません。

WebLogic Serverのクラスタ機能は比較的シンプルですが、JMSのクラスタに関しては、JBossよりも複雑に思えます。しかし、エンタープライズレベルで利用する場合には、大量のメッセージが処理される可能性があるので、ロードバランスの実現は必須ではないでしょうか。一方JBossのJMSのクラスタは、それほどパフォーマンス要求の厳しくないシステムであれば、シンプルな運用を実現できます。

ファーミング

次にTomcat・JBoss・WebLogic Serverのファーミングの違いを解説します。Tomcatはファーミングの処理を開始したときにクラスタに参加しているサーバにのみ、デプロイ処理を行います。

ファーミング後にクラスタに参加したサーバには、デプロイの反映が行われません。クラスタに参加するまでにファーミングされたモジュールを別途デプロイする必要があります。

JBossとWebLogic Serverは、クラスタに参加したときにデプロイされているモジュールを同期する仕組みがあります。よって、クラスタに参加しているすべてのサーバには、同じモジュールがデプロイされるようになっています。運用・管理を考慮するのであれば、Tomcatにもこの機能は求められるでしょう。

おわりに

本連載ではTomcat・JBoss・WebLogicという3つのアプリケーションサーバを取り上げてクラスタリング機能の比較を行ってきました。それぞれの製品のクラスタリング機能の性格を簡単にあらわすと「Tomcat=必要最低限の機能をシンプルに実装」「JBoss=多様な機能を備え、設定項目も多いが活用にはノウハウが必要」「WebLogic=設定項目は少なめだがデフォルトで高性能」といったところでしょうか。

Tomcatのクラスタ機能、およびJBossのJBossCacheはまだ採用されて日が浅いことから、機能の充実（Tomcat）、性能の向上（JBoss）は今後に期待といえるでしょう。採用にあたってはシステムの機能／性能要件に応じて製品を適材適所で選択することになります。本連載が皆さんの製品選定やクラスタ運用の一助となれば幸いです。