Oracle Blogs 日本語のまとめ: [WLS] WebLogic MDB and Distributed Queue Elastic Capabilities

MDBは分散Queueにどのように作用するのか、特に自動サービスマイグレーションのイベントが発生した後の作用について知りたいという問い合わせを受けました。移行やフェールオーバがシームレスに行われるようにするため、WebLogic Serverは優れた技術で構成されています。おそらくこの話題に興味がある方がいらっしゃるのではないでしょうか。
なお、このエントリの読者は、WebLogic Serverの分散QueueやTopicをご存知という前提とします。分散送り先について知りたい方は、こちらを参照してください。

Oracle® Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server
4 Configuring Advanced JMS System Resources
Configuring Distributed Destination Resources
http://download.oracle.com/docs/cd/E21764_01/web.1111/e13738/advance_config.htm#i1079175

"Mr. MDB Container, Meet Ms. JMS Service"
WebLogic ServerのMDBの挙動の鍵は、MDBコンテナとJMSサービスの関係です。両者間には、最終結果を可能にする補完する職務の分離があります。最終結果というのは、それは以下の目的を達成することを意味します。

分散Queueのすべてのメンバを使用可能にするMDB　（孤立したメンバやメッセージを作らない）
メッセージの作成・消費とも負荷分散する
WebLogicのトポロジーの変化に動的に対応する

MDBの挙動の背後にある基本的な前提は、分散Queueでメッセージを待機しているMDBが分散Queueの変化に対応すべき、というものです。それゆえ、クラスタ、分散Queueは、もともと柔軟性を持っています。クラスタメンバを追加したり、あるホストマシンから別のマシンへクラスタメンバを移行したり、JMSサービスはクラスタ内のある管理対象サーバから別のサーバに移行することができます。MDBは何もしなくてもその柔軟性を全て処理できるようにする必要があります。内部的には、いくつかのハンドシェイクやクラスタ内のJMSサービスとMDBコンテナ間で会話をします。分散Queueを待機しているMDBを含むアプリケーションをデプロイすると、MDBコンテナはクラスタ内のJMSサービスに分散Queueのメンバリストを要求します。そしてメンバが変化した場合には、JMSサービスにMDBコンテナに通知するように依頼します。技術的には、分散Queueのメンバ更新の通知サービスを使ってMDBコンテナが登録します。更新情報には分散Queueメンバの死活と各メンバの所在場所を含みます。クラスタ内のサーバの障害やクラスタ内のサーバ移行、管理対象サーバ間でのJMSサービス移行時クラスタの拡大により変化が発生します。MDBコンテナはこれらの変化に対応します。実際の対応は分散QueueがMDBとして同一クラスタ内にホストされている（ローカル）か、別のクラスタにホストされているか（リモート）によって変化します。

Local or Remote
クラスタにアプリケーションをデプロイし、分散Queueへのメッセージ到着を待つMDBがアプリケーションに含まれている場合、分散QueueがローカルにあるかリモートにあるかでMDBコンテナがMDBを管理する方法が異なります。いずれの場合でも、MDBコンテナは上記目的を達成するために正しい動作をします。

Local
分散Queueがローカル（同一クラスタ内）の場合、MDBコンテナは、分散Queueを実行している各ホストの分散Queueのメンバごとに、MDBマネージャもしくはMDBプールを作成します。この考え方は分散Queueのすべてのメンバが動作していることを確認したいと思うでしょう。
そして、アプリケーションが同一クラスタ上にデプロイされているので、アプリケーションのインスタンスがローカルで実行可能です。クラスタ内の管理対象サーバ各々のJMSサーバを一様に構成している場合、分散Queueのメンバの一つがクラスタ内の各管理対象サーバに存在するはずです。MDBコンテナはMDBプールを各管理対象サーバに作成し、各分散Queueを使えるようにします。メッセージが発生した場合、分散Queueをまたがったメッセージの負荷分散はクラスタ間でバランシングされます。

図1：ローカルMDBと分散Queue。MDBコンテナは分散Queueメンバがどこに存在してもMDBマネージャを作成する。

管理対象サーバをJMSサーバを持つクラスタに追加する場合、MDBコンテナが反応してMDBプールを新しいサーバに作成します。このMDBコンテナは新しい分散Queueメンバについて、内部通知サービスから情報を入手します。

図2：ローカルMDBと拡大した分散Queue。WebLogicクラスタが新しい管理サーバやJMSサーバで広がると、分散Queueは新しいサーバに広がり、MDBコンテナは新しいローカルMDBマネージャを作成する。

同様に、MDBコンテナは任意のマイグレーションシナリオを処理します。そのマイグレーションシナリオとは、管理サーバ全体が新たなロケーションへのマイグレーション（サーバーマイグレーション）と、管理サーバのJMSサービスのクラスタ内の別の管理サーバへのマイグレーション（自動サービスマイグレーション）のいずれかです。

Remote
デプロイしているアプリケーションがリモートアクセスする分散Queueがクラスタにホストされている場合、そのアプリケーションは、分散Queueを構成する全てのメンバが生きていて、メッセージコンシューマが反応し分散Queueのトポロジーの変化に対応できることを確認する必要がありますが、その方法はローカルの場合とはちょっと違います。リモートの場合、MDBコンテナは、クラスタの各メンバサーバに存在する分散Queueの各メンバへのMDBプールを作成します。MDBコンテナは分散Queueの構成メンバの状況を内部通知サービスで取得します。これと同じサービスにより、リモートのMDBコンテナは分散Queueの構成メンバに発生した更新情報を入手することができます。

図3：リモートMDBと分散Queue。MDBコンテナは各分散QueueメンバのためのMDBプールを作成する

この設計はアプリケーションが分散Queueの全てのメンバのメッセージを待つことを保証します。分散Queueのトポロジーに変化（クラスタの拡張、サーバの故障、サーバの統合、JMSサービスの統合）がある場合、JMSサービスはMDBコンテナに通知し、MDBコンテナは通知に対応します。

図4：リモートMDBが拡大したクラスタおよび分散Queueに動的に適応する

まとめ
JMSサービス、WebLogic ServerのMDBコンテナとも、WebLogic Serverのメッセージングに対する拡張性と高可用性を担保する役割を果たします。JMSサービスはQueueやTopicをホストし、クラスタ間でメッセージを分散させ、全てのメッセージが適切にルーティングされ処理されることを確認します。そしてメッセージングトポロジーにおける変更を他のシステムに通知します。MDBコンテナは分散送り先のすべてのメンバーが参加していることを確認し、もしトポロジーに変化がある場合には、MDBがその変化に対応します。
もっと詳しいことを知りたい場合には、以下のドキュメントを参照ください。