| Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング 11g リリース1 (10.3.6) B61629-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング 11g リリース1 (10.3.6) B61629-05 |
|
前 |
次 |
この章では、可用性の高い(HA)アプリケーションを設計する上で必要となる分散宛先の概念と機能について説明します。
分散宛先は、クライアントから単一の論理的な宛先としてアクセスできる宛先(キューまたはトピック)のセットです。分散宛先は、以下の特性を備えています。
独自のJNDIによって参照されます。
通常、分散宛先のメンバーはクラスタ内の複数のサーバーに分散されており、各宛先メンバーは別々のJMSサーバーに属しています。
分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。一度適切に構成すると、プロデューサとコンシューマがその分散宛先に対してメッセージを送受信できるようになります。WebLogic JMSは、分散宛先のすべてのメンバー間でメッセージングの負荷を分散します。サーバーの障害で宛先メンバーがアクセスできなくなった場合、トラフィックはセット内の他のアクセス可能な宛先メンバーにリダイレクトされます。宛先メンバーのロード・バランシングの詳細は、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。
分散宛先は、システム管理者が管理コンソールを使用して作成します。詳細は、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。
WebLogic Serverでは、以下の2種類の分散宛先がサポートされます。
共通分散宛先(UDD)では、各メンバーには、すべての分散宛先パラメータ(重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ)の一貫した構成が設定されます。
Oracleでは、UDDを使用することを推奨しています。UDDを使用すると、宛先のメンバーを作成したり指定したりする必要がなくなるためです。代わりに、WebLogic Serverによって、UDDのターゲットとなるJMSサーバー上に必要なメンバーが均等に作成されます。この機能により、新しいメンバーを追加したりメンバーを削除したりしたときに、UDDが動的に更新されます。
たとえば、UDDをクラスタにターゲット指定した場合、そのクラスタ内のすべてのJMSサーバーにUDDメンバーが構成されます。新しいJMSサーバーを追加すると、UDDに新しいUDDメンバーが動的に追加されます。同様に、JMSサーバーを削除すると、対応するUDDメンバーがUDDから削除されます。これにより、構成エラーによるボトルネックが解消され、アプリケーションの可用性を高めることができます。詳細は、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。
|
注意: 重み設定された分散宛先は、Weblogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。 |
重み設定された分散宛先では、各メンバーには、すべての分散宛先パラメータ(重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ)の一貫した構成が設定されません。
Oracleでは、重み設定された分散宛先をUDDに変換することを推奨しています。これは、重み設定によって追加のメッセージ負荷や容量をサポートするメンバーを作成すると、管理上の柔軟性が失われることがあるためです。重み設定された宛先は、メンバーの構成に一貫性がないためクラスタに矛盾なくデプロイすることができず、予期しない管理上の問題やアプリケーションの問題につながる可能性があります。
詳細は、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。
分散宛先は、物理的なJMS宛先メンバー(キューまたはトピック)のセットで、単一のJNDI名でアクセスされます。そのため、JNDIを使用することで分散宛先をルックアップできます。分散宛先にはjavax.jms.Destinationインタフェース(http://download.oracle.com/javaee/5/api/javax/jms/Destination.html)が実装されていて、プロデューサ、コンシューマ、およびブラウザの作成に使用できます。
分散宛先の参照の取得については、「宛先のルックアップ方法」を参照してください。
分散キューは、一連の物理的なJMSキューのメンバーです。したがって、分散キューはQueueSender、QueueReceiver、およびQueueBrowserを作成するために使用できます。分散キューが複数の物理的キューを表すという事実は、アプリケーションには全く意識されません。
キューのメンバーはどこにでも配置できますが、単一のサーバー・クラスタ内にあるJMSサーバーからサービスを受ける必要があります。分散キューに送信されるメッセージは、分散キューの一連のメンバー内にある物理的キューの1つだけに送られます。キューのメンバーに届いたメッセージは、そのキューのメンバーのコンシューマのみが受信できるようになります。
この節では、分散キューの使用について説明します。
キューのメンバーがメッセージをキューの他のメンバーに転送できるようにするには、管理コンソールの「転送の遅延」属性を構成します。この属性は、コンシューマではなく、メッセージだけを持つ分散キューのメンバーが、コンシューマを持つキューの他のメンバーにメッセージを転送するときに待機する時間を秒単位で定義します。デフォルトでは、分散キューのメンバー間で転送する場合、配信回数がリセットされます。「ResetDeliveryCountOnForward」を参照してください。
キュー・センダーを作成した後、作成時に提供したキューが分散キューであった場合は、センダーを使用してメッセージが作成されるたびに、どのキューのメンバーがそのメッセージを受信するかの判断が下されます。各メッセージは単一の物理的キューのメンバーに送信されます。
メッセージが複製されることは一切ありません。このため、メッセージは送信元のキューのメンバーのみから受信できます。メッセージの受信前にその物理的キューが使用できなくなった場合は、そのキューのメンバーがオンラインに復帰するまでこのメッセージを受信できなくなります。
メッセージを分散キューに送信して、その分散キューのキュー・レシーバがメッセージを受信することを期待するだけでは十分とは言えません。メッセージは1つの物理的キューのメンバーだけに送信されるため、そのキューのメンバーで受信またはリスニングするキュー・レシーバが存在する必要があります。
|
注意: コンシューマを持たない分散キューに対するロード・バランシングのヒューリスティックについては、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。 |
キュー・レシーバを作成する際は、提供したキューが分散キューの場合、単一の物理的キューのメンバーが作成時にレシーバとして選ばれます。作成されたQueueReceiverは、キュー・レシーバがキュー・メンバーのアクセスを失うまでそのキュー・メンバーに固定されます。この時点で、コンシューマは次のようにJMSExceptionを受信します。
キュー・レシーバが同期レシーバである場合は、例外がユーザーに直接返されます。
キュー・レシーバが非同期レシーバである場合は、例外がConsumerClosedExceptionの内部に配信され、それがコンシューマ・セッションに定義されているExceptionListener (存在する場合)に配信されます。
このような例外を受信した場合、アプリケーションは自分のキュー・レシーバを終了し、再作成できます。分散キュー内で他のキュー・メンバーを使用できる場合は、新しいキュー・レシーバが作成され、これらのキュー・メンバーのいずれかに固定されます。他のキュー・メンバーを使用できない場合、キュー・レシーバの再作成はできないため、後で作成を試みる必要があります。
|
注意: コンシューマを持たない分散キューに対するロード・バランシングのヒューリスティックについては、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。 |
キュー・ブラウザを作成する際は、提供されているキューが分散キューの場合、単一の物理的キューのメンバーが作成時にブラウザとして選ばれます。作成されたキュー・ブラウザは、レシーバがキュー・メンバーのアクセスを失うまでそのキュー・メンバーに固定されます。その時点でキュー・ブラウザを呼び出した場合は、JMSExceptionが発行されます。列挙を呼び出した場合は、NoSuchElementExceptionが返されます。
|
注意: キュー・ブラウザは固定されているキュー・メンバーのみを閲覧できます。分散キューが作成時に指定されている場合でも、キュー・ブラウザが分散宛先内の他のキュー・メンバーのメッセージを表示または閲覧することはできません。 |
分散トピックは、一連の物理的なJMSトピックのメンバーです。このため、分散トピックはTopicPublisherとTopicSubscriberを使用して作成できます。分散トピックが複数の物理的トピックを表すという事実は、アプリケーションには全く意識されません。
|
注意: 恒久サブスクライバ( |
トピック・メンバーはどこにでも配置できますが、単一のWebLogic Server、またはクラスタ内の任意の数のサーバーによってサービスを受ける必要があります。分散トピックに送信されたメッセージは、分散トピック・セット内のトピック・メンバーすべてに送信されます。このため、分散トピックのすべてのサブスクライバは、分散トピック用にパブリッシュされたメッセージを受信できます。
分散宛先のトピック・メンバーに直接パブリッシュされたメッセージ(つまりパブリッシャが宛先を指定しなかったメッセージ)も、その分散トピックのメンバーすべてに転送されます。これには、最初に分散トピックをサブスクライブしたサブスクライバと、その特定のトピック・メンバーにたまたま割り当てられているサブスクライバが含まれます。つまり、特定の分散トピックのメンバーにメッセージをパブリッシュすると、それが分散トピックの他のメンバーすべてに自動的に転送されます。これは、分散トピックにメッセージをパブリッシュすると、その分散トピックのメンバーすべてにメッセージが自動的に転送されることと同じです。特定の分散宛先メンバーのルックアップについては、「分散宛先メンバーへのアクセス」を参照してください。
この項では、分散トピックの使用について説明します。
トピック・パブリッシャを作成する際、提供されている宛先が分散宛先である場合には、その分散宛先に送信されるメッセージは次のように、分散トピックのアクセス可能なトピック・メンバーすべてに送信されます。
1つまたは複数の分散トピック・メンバーにアクセスできず、送信するメッセージが非永続的である場合、メッセージはアクセス可能なトピック・メンバーのみに送信されます。
1つまたは複数の分散トピック・メンバーにアクセスできず、送信するメッセージが永続的である場合、メッセージは格納され、アクセスできなかったメンバーにアクセスできるようになったときに転送されます。ただし、トピック・メンバーにJMSストアが構成されている場合は、メッセージの永続的な保管のみが行われます。
|
注意: 永続ストアを利用している分散メンバーに対しては、最初にメッセージを転送するためにあらゆる努力がなされます。ただし、分散メンバーがいずれもストアを利用していない場合でも、メッセージは『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項で説明されるように、選択されているロード・バランシング・アルゴリズムに従って、いずれかのメンバーに送信されます。 |
分散トピック・メンバーすべてにアクセスできない場合(メッセージが永続的であるか非永続的であるかにかかわらず)は、パブリッシャがメッセージを送信しようとしたときにJMSExceptionが発行されます。
トピック・サブスクライバを作成するとき、提供されているトピックが分散トピックの場合、トピック・サブスクライバはその分散トピックにパブリッシュされたメッセージを受信します。トピック・サブスクライバが分散トピックのトピック・メンバーの1つまたは複数にアクセスできない場合は、メッセージが永続的であるか非永続的であるかに応じて次の事態が発生します。
アクセスできない1つまたは複数の分散トピック・メンバーにパブリッシュされた永続メッセージは、これらのメンバーがアクセス可能になったときに、これらのメンバーのトピック・サブスクライバによって受信されます。ただし、トピック・メンバーにJMSストアが構成されている場合は、メッセージの永続的な保管のみが行われます。
アクセスできない分散トピック・メンバーにパブリッシュされた非永続メッセージは、そのトピック・サブスクライバには送信されません。
|
注意: JMSストアが分散トピック・メンバーをホストするJMSサーバー用に構成されている場合は、そのメンバーの宛先に関連付けられているすべての分散トピック・システム・サブスクライバが恒久サブスクリプションとして処理されます。これは、トピック・メンバーにJMSストアが明示的に構成されていない場合も同様です。したがって、これらの分散トピック・サブスクライバに送信されるすべてのメッセージをメモリーに保存すると、メモリーやディスクが予想以上に消費されるおそれがあります。分散宛先をデプロイする場合のベスト・プラクティスとしてお薦めする設計は、恒久メッセージ用のJMSストアがある場合でも、非恒久メッセージ用のJMSストアがない場合でも、すべてのメンバー宛先を同じように構成することです。たとえば、すべての分散トピック・サブスクライバを非恒久にした上で、一部のメンバー宛先に暗黙的にJMSストアを構成し、それらに関連付けられたJMSサーバーがJMSストアを使用するようにしたい場合は、各メンバー宛先のStoreEnabled属性を明示的にFalseに設定してJMSサーバーの設定をオーバーライドする必要があります。 |
最終的に、トピック・サブスクライバは物理的なトピック・メンバーに固定されます。そのトピック・メンバーにアクセスできなくなった場合は、次のようにトピック・サブスクライバにJMSExceptionが発行されます。
トピック・サブスクライバが同期サブスクライバである場合は、例外がユーザーに直接返されます。
トピック・サブスクライバが非同期サブスクライバである場合は、例外がConsumerClosedExceptionの内部に配信され、それがコンシューマ・セッションに定義されているExceptionListener (存在する場合)に配信されます。
このような例外を受信した場合、アプリケーションはトピック・サブスクライバを終了して再作成できます。分散トピック内のその他のトピック・メンバーにアクセス可能な場合は、新しいトピック・サブスクライバが作成され、これらのトピック・メンバーのいずれかに固定されます。他のトピック・メンバーにアクセスできない場合、トピック・サブスクライバの再作成はできないため、後で作成を再試行する必要があります。
MDBxをトピック上でデプロイする方法の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の分散トピックを使用したMDBの構成およびデプロイに関する項を参照してください。
WebLogic Server 10.3.4.0以降では、パーティション化された分散トピックは、サブスクリプションを共有する機能および複数接続に同一クライアントIDの使用を許可する機能が組み合され、パラレル処理と分散キューに似たHA機能を備えた次のアプリケーション設計パターンを提供しています。
インスタンスごとに1つのコピー: アプリケーションの各インスタンスは、トピックにパブリッシュされる各メッセージのコピーを1つ取得します。
アプリケーションごとに1つのコピー: 各アプリケーションが全体として(つまり、アプリケーションのすべてのインスタンスを合せて)、DTにパブリッシュされる各メッセージのコピーを1つ取得します。つまり、各インスタンスはDTに送信されるメッセージのサブセットのみを取得します。
|
注意: WebLogic ServerのMDBを活用するアプリケーションを設計することをお薦めします。高可用性とスケーラビリティの向上にメッセージドリブンBeanを使用するアプリケーションを設計・実装する方法の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の分散トピックを使用したMDBの構成およびデプロイに関する項を参照してください。 |
パーティション化された分散トピックの使用に関する詳細は、拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項を参照してください。
分散宛先とそのメンバーにアクセスする方法については、「宛先のルックアップ方法」を参照してください。
|
注意: キュー・プロデューサが作成された分散キュー・メンバーに障害が発生したが、プロデューサのJMS接続が存在するWebLogic Serverインスタンスがまだ実行されている場合、プロデューサは閉じられず、WebLogic JMSはロード・バランシング・オプションが有効になっているかどうかに関係なく別の分散キュー・メンバーにフェイルオーバーします。たとえば、WebLogicクラスタにWLSServer1、WLSServer2、およびWLSServer3があり、WLServer2に接続しているとします。サーバーWLSServer 2に障害が発生すると、プロデューサは残りのクラスタ・メンバーの1つにフェイルオーバーします。詳細は、『Oracle WebLogic Server JMSの構成と管理』の分散宛先リソースの構成に関する項を参照してください。 |
障害が発生した分散宛先に接続されているクライアントをフェイルオーバーさせる方法としては、クライアント・コードに再接続ロジックを記述して、onExceptionを捕捉したら分散宛先に接続されるようにする方法が簡単です。
メッセージドリブンBean (MDB)は、JMSメッセージ・リスナー(イベントのかわりにメッセージを受信することを除いてイベント・リスナーと同様)として機能します。MDBの詳細は、以下を参照してください。
『Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のMDBとメッセージング・モデルに関する項
『Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のMDBのデプロイに関する項
以下の節では、分散宛先を使用する場合の一般的な例を示します。
メッセージの生成を最大にするには、分散宛先の各メンバーをプロデューサとコンシューマに関連付けることをお薦めします。次の図は、ロード・バランシングを使用せず、共通分散宛先を使用して効率的に最大のメッセージ生成と高可用性を実現する方法を示しています。
この場合、UDD1は2つの物理的なメンバー、D1およびD2で構成された共通分散宛先です。それぞれの物理的な宛先にはプロデューサとコンシューマのペアがあり、メッセージは実線のとおりに、効率的にプロデューサから宛先メンバーを介してコンシューマに渡されます。順序付けを使用している場合は、予期される順序単位ごとにプロデューサが必要です。「分散宛先で順序単位を使用する」を参照してください。
この節では、メッセージの可用性を最大にする方法について説明します。
プロデューサをコンシューマとペアにするのが理想的ですが、この方法が適切でない場合もあります。メッセージの消費速度は、アプリケーションのメッセージ・スループットを決定する制約要因です。メンバー宛先間でロード・バランシングを使用することにより、コンシューマの可用性を向上できます。この場合、コンシューマはプロデューサとペアになっていませんが、受信メッセージは次の使用可能なコンシューマにロード・バランシング・アルゴリズムに従ってロード・バランシングされます。
|
注意: 順序単位機能の組み合わせによっては、競合する順序単位メッセージ・ストリームが不足することがあります。これには、順序単位名が異なる処理中メッセージの数よりコンシューマの数が多くなったために、リソースが十分に利用されなくなった場合も含まれます。システムのパフォーマンスを最適化し、リソースが十分に利用されない状態を防ぐには、最大の負荷でアプリケーションをテストする必要があります。 |
この場合、プロデューサはUDDの1つのメンバーにメッセージを送信しますが、メッセージを受信できるコンシューマがありません。これは通常、プロデューサが宛先の1つ(D1)にメッセージを送信し、コンシューマが別の宛先(D2)のメッセージをリスニングしている場合に生じます。
UDD1は2つの物理的なメンバー、D1およびD2で構成された共通分散宛先です。D1にはプロデューサがあり、D2にはコンシューマがあります。プロデューサとコンシューマのペアを使用するか、または宛先で転送を構成して、このような構成は回避してください。
