| Oracle® Fusion Middleware Oracle WebLogic Serverメッセージング・ブリッジの構成と管理 12cリリース1 (12.1.1) B65894-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverメッセージング・ブリッジの構成と管理 12cリリース1 (12.1.1) B65894-01 |
|
前 |
次 |
この章では、メッセージング・ブリッジを設計、構成およびチューニングする方法について説明します。
この章の内容は以下のとおりです。
以下の節では、メッセージング・ブリッジを使用すべき状況について説明します。
メッセージング・ブリッジの使用により、リモートの宛先に対する高可用性が実現します。ストア・アンド・フォワード・メッセージング機能を使用すると、ローカル・クライアントでローカルの宛先を作成し、その宛先のメッセージをリモートの宛先が利用できるときに自動的にリモートの宛先に転送できます。そのため、リモートの宛先が利用できないときにもローカル・クライアントでメッセージの生成を続けられます。「メッセージングの永続性」を参照してください。
WebLogicメッセージング・ブリッジを使用して、以下の製品間のストア・アンド・フォワード・メッセージングに対する管理ソリューションを実現できます。
WebLogic JMSの2つの実装(WebLogic Serverのリリースが異なる場合を含む)。
別々のWebLogicドメインにあるWebLogic JMSの複数の実装。
WebLogic JMSとサード・パーティのJMS製品(MQSeriesなど)。
メッセージング・ブリッジは、WebLogic Serverリリースで利用できる分散トピック機能のように、トピックをレプリケートできます。その結果、スケーラビリティが向上し、高可用性が実現する場合があります。(分散トピックの使用方法は、『Oracle WebLogic Server JMSのプログラミング』の「分散宛先の使用」を参照)トピックのレプリケーションは、ブリッジで1つのトピックをサブスクライブしてそのトピックのメッセージを別のトピックに転送する、つまり実質的には同じメッセージ・ストリームを持つ2つのトピックを作成することによって実現されます。Oracle WebLogic Server管理コンソール・ヘルプのメッセージング・ブリッジ・インスタンスの作成に関する項を参照してください。
以下に説明する状況では、メッセージング・ブリッジを使用しないようにします。
リモートの宛先からメッセージを受信する場合 - メッセージドリブンEJBを使用するか、クライアント・コンシューマを直接実装してください。
ローカルの宛先にメッセージを送信する場合 - ローカルの宛先に直接送信してください。
メッセージのレイテンシに対する許容度が低い環境。メッセージング・ブリッジによってレイテンシが増大し、スループットが低下することもあります。メッセージング・ブリッジは、メッセージ・パスに特別な宛先を挿入するため、メッセージのレイテンシを増大させます。また、シングル・スレッドでメッセージを転送するため、スループットを低下させる可能性があります。
WebLogic 9.0以降のドメイン間でメッセージを転送する場合 - WebLogicストア・アンド・フォワード機能を使用してください。
表3-1にWebLogicメッセージング・ブリッジを使用すべき状況と他の転送技術を使用すべき状況についてまとめます。
WebLogicメッセージング・ブリッジでは、3種類のQOSレベルがサポートされます。
「必ず1回」 - もっとも高レベルのQOS。メッセージがリモートのエンド・ポイントに1回だけ送信されます。「必ず1回」を指定すると、サーバーのクラッシュ時やネットワークのダウン時にもメッセージは存続し、各メッセージがエンドポイントに1つだけ存在する状態にできます。
「1回以上」 - メッセージはリモートのエンド・ポイントに送信されますが、重複する可能性があります。「1回以上」を指定すると、メッセージの転送中に発生したネットワーク障害やサーバーのクラッシュにより、そのメッセージの複数のコピーがリモートのエンドポイントに現れることがあります。
「最大1回」 - もっとも低レベルのQOS。各メッセージがリモートのエンド・ポイントに(送信できた場合には) 1回だけ送信されます。このレベルでは、必ずメッセージがエンドポイントに送信されるとはかぎりません。「最大1回」を指定していると、ネットワーク障害やサーバーのクラッシュによってメッセージが失われることがあります。メッセージが重複してエンドポイントに届くことはありません。
場合によって、ブリッジに構成したサービス品質をターゲット宛先では提供できないことがあります。そのような場合、QOSDegradationAllowedフラグを指定して、サービス品質が低下できるようにブリッジ・インスタンスを構成します。Oracle WebLogic Server管理コンソール・ヘルプのメッセージング・ブリッジ・インスタンスの作成に関する項を参照してください。
ストア・アンド・フォワード・メッセージング機能を利用すると、ローカルJMSクライアントでローカルの宛先へのメッセージを作成し、それらのメッセージをリモートの宛先が利用できるときに自動的にリモートの宛先に転送できます。こうしたメッセージは、そのターゲット宛先が再起動されたときにブリッジによって転送されます。メッセージング・ブリッジでは次の場合に、ターゲット宛先へのメッセージが格納されてから転送(ストア・アンド・フォワード)されます。
ソース宛先がキューです。
ソース宛先がトピックであり、「恒久性の有効化」属性が設定されています。この場合、恒久サブスクリプションが作成されます。恒久トピック・サブスクライバの構成の詳細は、『Oracle WebLogic Server JMSのプログラミング』の恒久サブスクリプションの設定に関する項を参照してください。
アプリケーションのメッセージがトランザクション内にある場合、「必ず1回」のセマンティクスを保持するために、永続ストアへのメッセージの保存は必ずそのユーザー・トランザクションの一環として行われます。また特に、メッセージの永続ストアからの削除は、アプリケーションでトランザクションのロールバックが決定された場合にトランザクション・ロールバックの一環として行われます。一方、転送はアプリケーション・トランザクションの一環としては行われません。トランザクションがコミットされるまで、トランザクション・メッセージは送信エージェントによって転送されません。トランザクション内では、メッセージの順序はメッセージが送信された時間に基づいて保持されます。
メッセージの順序を確実に指定するには、メッセージ順序単位を構成します。『Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。
weblogic-ra.xml記述子ファイルのmax-capacity属性を調整して、各リソース・アダプタに関連付けられた接続ファクトリの容量を変更することを検討してください。通常、max-capacity属性の値は、少なくともブリッジ・インスタンス数の2倍にする必要があります。たとえば、割り当てられているメッセージング・ブリッジ・インスタンスが10個までの環境においては、max-capacity属性は20に設定されているのは適切な設定です。ブリッジ・インスタンスを15個に増やす場合には、max-capacity属性の値を30まで増やします。
|
注意: メッセージ・ブリッジ・アダプタのinitial-capacity値を変更しないでください。ブリッジ・インスタンスがResourceAllocationエラーで機能しなくなることがあるため、initial-capacity値をゼロ(デフォルト)に設定することをお薦めします。 |
次の手順で、weblogic-ra.xml記述子ファイルを変更します。
任意のエディタを使用して、属性値を目的の値に更新します。例3-1を参照してください。
更新したアダプタをデプロイします。
更新後の値を必要とするすべてのブリッジ・インスタンスを停止してから再起動します。
例3-1 weblogic-ra.xml記述子ファイルのサンプル
<weblogic-connection-factory-dd>
<connection-factory-name>WLSJMSConnectionFactoryLocal</connection-factory-name>
<jndi-name>eis/jms/WLSConnectionFactoryJNDILocal</jndi-name>
<pool-params>
<initial-capacity>0</initial-capacity>
<max-capacity>20</max-capacity>
</pool-params>
</weblogic-connection-factory-dd>
PreserveMsgPropertyを設定すると、ブリッジ・インスタンスによってメッセージが転送されるときに、メッセージ・ヘッダー内にメッセージのプロパティを保持できます。旧リリースでは、ターゲット宛先へのメッセージの転送時に使用される接続ファクトリのデフォルト配信モード属性から、メッセージのプロパティが継承されます。デフォルト配信モードが「永続」に設定されていると、非永続メッセージが永続メッセージとして転送されて、パフォーマンスが大幅に低下します。
PreserveMsgPropertyを有効にすると、ブリッジによって、受信された非永続メッセージは非永続メッセージとして、永続メッセージは永続メッセージとしてターゲット宛先に転送されます。Oracle WebLogic Server管理コンソール・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。
メッセージング・ブリッジ・インスタンスの動作は以下のガイドラインによって決まります。
PreserveMsgPropertyが有効になっていません。この設定では、前のリリースと同じ転送動作が行われます。
メッセージング・ブリッジ・インスタンスの構成時には、PreserveMsgPropertyはデフォルトで無効になっています。
PreserveMsgPropertyが有効になっています。メッセージのプロパティは、表3-2のように保持されます。
メッセージング・ブリッジでは、メッセージのJMSXUserIDがメッセージング・ブリッジの境界を越えて開示されることはありません。JMSXUserIDとは、メッセージの送信者であるユーザーを識別するシステム生成プロパティです。オラクル社が発行しているJMS仕様(http://www.oracle.com/technetwork/java/jms/index.html)を参照してください。
メッセージング・ブリッジを使用して、「分散宛先」との間で送受信できます。以下の構成をお薦めします。
ソース宛先が分散宛先の場合、ブリッジは宛先に接続したときにいずれかの宛先メンバーに固定されます。接続を中断するイベントが発生するまで、ブリッジはそのメンバーに接続されています。再接続される際は、利用可能な次のメンバーが使用されます。一度接続されると、ブリッジでは分散宛先の他のメンバーからのメッセージが受信されません。そのため、メンバーのJNDI名を使用して、分散宛先の各メンバーに対し1つずつブリッジを構成することがベスト・プラクティスです。
ターゲットが分散宛先の場合、ベスト・プラクティスは、分散宛先のJNDI名を使用して分散宛先に対して送信し、サーバー・アフィニティを無効にしておくことです。こうすると、分散宛先で受信するメッセージをロード・バランシングできます。『Oracle WebLogic Serverクラスタの使用』のJMSのロード・バランシングに関する項を参照してください。
メッセージング・ブリッジのチューニングの主な目的は、メッセージングの全体的なパフォーマンスの向上です。処理速度を高速に保つことも重要ですが、これは数あるパフォーマンス関連の要素の1つにすぎません。パフォーマンスには他にも、信頼性、スケーラビリティ、管理容易性、モニター、ユーザー・トランザクション、メッセージドリブンBeanのサポート、アプリケーション・サーバーとの統合などの要素が影響します。『Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogicメッセージング・ブリッジのチューニングに関する項を参照してください。
