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