ストア・アンド・フォワード・サービスの理解

2 ストア・アンド・フォワード・サービスの理解

Oracle WebLogic ServerでWebLogicストア・アンド・フォワード(SAF)サービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上のエンドポイントにメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートのエンドポイントが使用可能になった時点でそのエンドポイントに転送されます。

WebLogic SAF環境

WebLogic SAF環境には、SAFサービスとSAFエージェントが含まれ、さらにJMS SAF、Webサービスの信頼性のあるメッセージングおよびクロスドメイン・セキュリティも含まれる場合があります。

SAFサービス

SAFサービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上のエンドポイントにメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートのエンドポイントが使用可能になった時点で転送されます。

WebLogic JMSでは、SAFサービスを利用して、ローカルのJMSメッセージ・プロデューサが、リモートのJMSキューまたはトピックにメッセージを確実に送信できるようにします。「WebLogic JMSでのSAFの使用」を参照してください。

WebLogic Webサービスでは、SAFサービスを利用して、Web Services Reliable Messaging (WSRM)の信頼性を確保します。「Web Services Reliable Messaging (WSRM)でのSAFの使用」を参照してください。

SAFサービス・エージェント

メッセージの格納と転送のプロセスには、ローカルの送信側とリモートの受信エンドポイントという2つの側面があります。SAFエージェントは、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージの格納と転送を行います。SAFエージェントは、送信機能または受信機能のみを持つように構成することも、両方の機能を持つように構成することもできます。

JMS SAFでは、JMSメッセージの送信側に送信エージェントのみが必要になります。一方、WSRM SAFでは、送信エージェントと受信エージェントの両方が必要になります。

送信エージェント - JMSメッセージおよびWSRMで使用されます。送信エージェントは、メッセージの永続性が必要になる場合に、永続ストレージへのメッセージの格納、受信側へのメッセージの転送、確認応答が時間内に戻らなかった場合のメッセージの再送信を行います。
受信エージェント - WSRMのみで使用されます。受信エージェントは、送信エージェントが送信したメッセージのうち重複するものの検出および消去と、最終的な宛先へのメッセージの配信を行います。

ノート:

JMSメッセージの場合は、受信側のエクスポート済みリモートJMS宛先に関連付けられたJMSサーバーが重複排除を管理します。

SAFエージェントの構成パラメータ

SAFエージェントは構成可能なオブジェクトであり、メッセージの永続性、ページング・パラメータ、およびしきい値と割当てを管理するという点でJMSサーバーに似ています。SAFサービスの動作は、SAFエージェントの以下の構成可能なパラメータによって制御されます。

以下のような、全般的な構成パラメータ。
- 永続ストレージの選択
- メッセージ・ページングのデフォルトの設定
- 配信再試行設定の指定
- ウィンドウ・サイズの指定
- メッセージ確認応答の間隔の指定(WSRMのみ)
配信再試行の設定、ロギング、およびページングのデフォルトの詳細は、「SAFエージェントの設計」を参照してください。

SAFエージェントに対するすべての一般構成パラメータの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェント: 構成: 全般を参照してください。
SAFエージェントのメッセージ・スループットを制御するための、しきい値および割当てに関するパラメータ。

「SAFエージェントの設計」を参照してください。
SAFエージェント、リモート・エンドポイント、および会話のモニター機能。SAFエージェントでの着信、転送、および受信メッセージ処理、およびリモート・エンドポイントに対する着信および転送メッセージ処理を管理するための機能もあります。

「SAFエージェントのモニターと管理」を参照してください。
SAFインポート済み宛先のJMSメッセージ・ロギング機能。JMSメッセージが、SAFエージェントによって格納されてから、最終的にリモートのJMS宛先に転送されるまでに発生するイベントを外側から見る形になります。

SAF宛先のJMSメッセージ・ロギングのオプションについては、「JMSメッセージのSAFメッセージ・ライフ・サイクルのロギング」を参照してください。

SAFエージェントをクラスタに割り当てる場合の永続ストアのルール

SAFエージェントをスタンドアロン・サーバーに割り当てる場合には、サーバーのデフォルトの永続ストアを使用することも、明示的に構成されたストアを選択することもできます。しかし、SAFエージェントをクラスタに割り当てる場合には、以下の永続ストアの選択ルールが適用されます。

移行可能ターゲットを使用しない場合には、クラスタ内の各サーバー・インスタンスはデフォルト永続ストアを使用しなければならず、SAFエージェントもデフォルト・ストアを使用しなければなりません。
JMSメッセージの場合には、SAF送信エージェントとインポート済み宛先が同じサーバー・インスタンス上に存在しなければなりません。SAFエージェントがクラスタに割り当てられると、クラスタ内の各サーバー・インスタンス上にエージェントが自動的に構成されます。
移行可能ターゲットに割り当てる場合には、SAFエージェントがカスタム永続ストアを使用し、かつそのカスタム・ストアで使用されるものと同じ移行可能ターゲットに割り当てられていることが必要です。SAFエージェント、JMSサーバー、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。Oracle WebLogic Serverクラスタの管理のクラスタ内の移行可能ターゲットの理解を参照してください。

ノート:

SAFメッセージの一貫性を保持するために、WebLogic Serverでは既存のSAFエージェントを移行可能ターゲットに再割当てすることはできません。かわりに、既存のSAFを削除し、同じ値で構成した新しいSAFを移行可能ターゲットに割り当てる必要があります。

WebLogic JMSでのSAFの使用

JMSストア・アンド・フォワードでは、1つの送信エージェントを使用して、高可用性を備えたJMSメッセージ生産を行います。たとえば、ローカルのサーバー・インスタンスに接続されたJMSメッセージ・プロデューサは、メッセージ送信時にリモートのJMS宛先が一時的に使用できない場合でも、そのリモート宛先に確実にメッセージを転送できます。JMS SAFはJMSアプリケーションからは透過的なので、JMSクライアント・コードは既存のJMS APIを使用して、リモート宛先にアクセスできます。「JMSメッセージに対するSAFの構成」を参照してください。

インポート済みJMS宛先に対するSAF送信エージェントによってクラスタ内の依存するJMSアプリケーションに対してシングル・ポイント障害が発生しないように、SAFエージェントをクラスタ内の正常なサーバー・インスタンスに移行するようWebLogic Serverを構成できます。「可用性の高いメッセージングのための移行可能なSAFエージェント」を参照してください。

Webサービスの信頼性のあるメッセージングでのSAFの使用

JAX-RPCの信頼性のあるメッセージングでは、ローカル・サーバー・インスタンスで構成されたSAF送信エージェント、およびリモート・サーバー・インスタンスで構成されたSAF受信エージェントのペアが使用されます。これにより、別々のサーバー・インスタンス上で動作する2つのWebサービスは、ソフトウェア・コンポーネント、システム、またはネットワークに障害がある場合でも確実に通信できるようになります。具体的には、ソース・エンドポイントから宛先エンドポイントに送信されたメッセージは1つまたは複数の配信保証に基づいて確実に配信され、配信されない場合には必ずエラーが送出されます。

ノート:

WebLogic SAFエージェントのJAX-RPCの信頼性のあるメッセージングに対するサポートは、すべてのJAX-RPC APIとともに非推奨になりました。このため、今後のリリースでは、SAFエージェント・サービス・タイプ属性は無視され、すべてのSAFエージェントは「送信専用」のサービス・タイプとして扱われます。このテクノロジのかわりに、JAX-WSの信頼性のあるメッセージングを使用することをお薦めします。

次の場所にある『Oracle WebLogic Server JAX-RPC Webサービスの開発』バージョン12.2.1.0のWebサービスの信頼性のあるメッセージングの使用に関する項を参照してください。

http://docs.oracle.com/middleware/1221/wls/WSRPC/jax-rpc-rm.htm#WSRPC319

SAFとクロス・ドメイン・セキュリティ

SAFサービスでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、1つのドメインにクロス・ドメイン・セキュリティが構成されていて、共通分散宛先のメンバーシップがSAFの変更を介してインポートされる場合には、プロセスの通信対象となるすべてのドメインに対して、クロス・ドメイン・セキュリティを構成する必要があります。ベスト・プラクティスは、プロセスで使用されるすべてのドメインに関してクロス・ドメイン・セキュリティの構成を統一することです。つまり、すべてのドメインがクロス・ドメイン・セキュリティを使用する(または、適切な例外リストに含まれる)か、どのドメインについてもクロス・ドメイン・セキュリティを有効にしないかのいずれかにします。『Oracle WebLogic Serverセキュリティの管理』のクロス・ドメイン・セキュリティの構成に関する項を参照してください。

SAFサービスを使用する場合

SAFサービスは、WebLogic Server 9.x以降のドメイン間でJMSメッセージまたはWSRMメッセージを転送する場合に使用します。

SAFサービスによるメッセージの配信対象間の関係は、以下のとおりです。

2つのスタンドアロンのサーバー・インスタンス間
クラスタ内のサーバー・インスタンス間
ドメイン内の2つのクラスタ間
異なるドメイン間

SAFサービスを使用しない場合は、以下のとおりです。

バージョン9.0以前のWebLogic Serverのインスタンスにメッセージを転送する場合。
サード・パーティのJMS製品(MQSeriesなど)と相互運用する場合

これらのタスクでは、WebLogicメッセージング・ブリッジを使用します。Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。
リクエストにレスポンスを返すためにJMSReplyToで一時的な宛先を使用する場合

なお、JMS SAFを使用する場合、アプリケーションは使用可能なリモート・サーバーから直接メッセージを受信することしかできません。

基本的なSAFサービスの構成

基本的なSAFサービスを実装するための主なタスクには、SAF送信エージェントおよび受信エージェントの作成と構成が含まれます。WSRM、WebLogic JMSおよび永続ストアに関するその他のタスクも必要になる場合があります。

ドメインにSAFサービスを実装するには、次のタスクを完了します。

送信側クラスタまたはサーバー・インスタンスで、SAFエージェントを構成します。SAFエージェントは、以下のいずれかの方法で作成できます。
- WebLogic Server管理コンソールを使用します。これにより、使用している環境のSAFエージェントを構成、変更、ターゲット指定、モニター、および削除できます。SAFエージェントの構成タスクのステップは、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェントの作成を参照してください。
- WebLogic Java Management Extensions (JMX)を使用します。これにより、SAFエージェントを作成および管理するためのSAFAgentMBeanおよびSAFAgentRuntimeMBeanの各MBeanにアクセスできます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。
- WebLogic Scripting Tool (WLST)を使用します。これにより、JMSサーバーとJMSシステム・リソースを作成および管理できます。『Oracle WebLogic Server JMSリソースの管理』のWLSTを使用したJMSサーバーとJMSシステム・リソースの管理に関する項を参照してください。
WSRMを使用する場合は、送信側で送信機能と受信機能の両方の機能を持つSAFエージェントを構成した場合でも、受信側のクラスタまたはサーバー・インスタンスで受信機能を持つSAFエージェントを構成する必要があります。
SAFエージェントの構成時には、サーバーのデフォルト・ストアをそのまま使用することもできますし、SAFメッセージ専用のストアを構成する場合はストアを構成することもできます。SAFエージェントをクラスタに割り当てる場合には、サーバーのデフォルト・ストアをそのまま使用しなければなりません。また、SAFエージェントを移行可能ターゲットに割り当てて高可用性を高めることもできます。「SAFエージェントをクラスタに割り当てる場合の永続ストアのルール」を参照してください。

『WebLogic永続ストアの管理』のWebLogic永続ストアの使用方法に関する項を参照してください。
WebLogic JMSの場合は、JMSモジュールでSAFインポート済宛先、SAFコンテキスト処理、およびSAFエラー処理(オプション)の各オブジェクトを構成します。「JMSメッセージに対するSAFの構成」を参照してください。
(オプション)送信側がクラスタで、JMSプロデューサがメッセージ順序単位に関連付けられている場合は、JMSメッセージのパス・サービスを構成します。メッセージ順序単位を使用することで、JMSメッセージ・プロデューサは順序付けされたメッセージを1つの単位にグループ化できます。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

パス・サービスは、メッセージのグループとメッセージング・リソース(SAFエージェントなど)との間のマッピングを格納できる永続マップです。『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項を参照してください。

SAFエージェントの設計

メッセージ転送のためのSAFエージェントを設計および構成する際には、SAFエージェントが信頼性の高い方法でメッセージを配信するために要する時間、失敗したメッセージ配信のロギング、配信再試行の設定など、運用環境の要件を考慮する必要があります。

メッセージの存続時間とメッセージ配信の失敗ポリシーの設定

SAFの信頼性は、時間に基づいています。存続時間のパラメータを使用して、メッセージがSAFエージェントによって確実に配信されなければならない期間を構成できます。構成された存続時間が経過すると、送信エージェントはメッセージをストレージから削除し、受信側に対するメッセージの再送信の試行を中止します。存続時間が経過したときに、配信できなかったメッセージをどのように処理するかは、アプリケーション側の設定で決まります。

失敗したメッセージ配信のJMSにおける処理方法については、「SAFエラー処理」を参照してください。

メッセージ配信の失敗で考えられる理由は、以下のとおりです。

ネットワークの停止があった
エンドポイントが存在しない(構成されていない)
エンドポイントが停止している
エンドポイントの割当てエラーが発生した
セキュリティによって拒否された
必要なQOSがサポートされていない
WSRM会話がタイムアウトになった(会話があまりに長い間アイドル状態にある)

失敗したメッセージ配信のロギング

ロギングのパラメータが有効になっている場合、失敗したメッセージごとに、送信エージェントによってメッセージがサーバー・ログに記録されます。これは、アプリケーションで独自の失敗処理が定義されていない場合や、アプリケーションで失敗処理を完了できない場合のかわりの方法として使用できます。『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のWebLogicロギング・サービスの理解に関する項を参照してください。

配信再試行の設定

メッセージを転送するために、送信エージェントは受信側に接続する必要がありますが、接続が使用不能になっている場合もあります。メッセージ送信の試行が失敗した場合には、送信エージェントは成功するまで再試行しなければなりません。同様に、必要なQOSが「必ず1回」または「1回以上」である場合には、そのメッセージの確認応答を受信するまで、送信エージェントはメッセージを送信し続ける必要があります。

試行の頻度、および連続する2回の試行の間隔を制御するには、再試行遅延の基数、再試行遅延の乗数、および最大再試行遅延の各パラメータのデフォルト値を構成します。再試行遅延の乗数パラメータの値は1以上に設定する必要があり、最大再試行遅延パラメータの値は再試行遅延の基数パラメータの値以上に設定する必要があります。デフォルトでは、再試行遅延の乗数パラメータの値は1に設定されています。この場合は、再試行遅延の基数パラメータの値で定義された一定間隔が、連続する2回の試行の間隔に使用され、最大再試行遅延パラメータの値は無視されます。再試行遅延の乗数パラメータに1より大きい値が設定されている場合、再試行間隔の調整に指数関数的なバックオフ・アルゴリズムが使用されます。

遅延は、再試行遅延の基数パラメータの値から始まり、指数関数的に長くなります。つまり、試行のたびに再試行遅延の乗数パラメータの値で乗算されていきます。最大再試行遅延パラメータの値に達すると、遅延時間はそれ以上長くなりません。試行が成功すると、再試行遅延の乗数パラメータの対象は、再試行遅延の基数パラメータの値にリセットされます。

SAFエージェントの配信再試行パラメータの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェント: 構成: 全般を参照してください。

メッセージの割り当て、しきい値、およびページングの使用

永続メッセージは、受信側に正常に転送され、確認応答されるまで送信側の永続ストアに保存されます。一方、配信が保留になっている非永続メッセージは送信側のメモリー内に存在し、すべての履歴記録は受信側のメモリー内に存在します。リモート側が長時間使用不能になっている場合には、保留中の非永続メッセージによって送信側サーバーのメモリーがすべて使用されてしまい、サーバーが停止してしまうこともあります。各SAFエージェントの割当てを構成することで、メモリー不足からサーバーを保護できます。割当てを超過しそうになると、SAFエージェントは新しいリクエストを拒否します。

割当てに達する前に、メッセージまたは履歴記録をページング・ディレクトリにページングするように、SAFエージェントを構成することもできます。ページングは、SAFエージェントの構成でしきい値として指定された一定の条件が満たされるとトリガーされます。メッセージまたは履歴記録用の永続ストアもページングに使用されます。

SAFエージェントのしきい値および割当てに関するパラメータとその関係は、JMS宛先やJMSサーバーのしきい値および割当てに関するパラメータと同じです。

SAFエージェントのしきい値および割当てパラメータの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェント: 構成: しきい値と割当てを参照してください。

起動時のリカバリ

WebLogic Serverインスタンスが再起動すると、そのサーバー・インスタンスが停止する前に送信されなかったメッセージが、サーバーの永続ストアから回復されます。送信エージェントは、リモート側がまだ期限切れになっていなければ、それらのメッセージをリモート側に送信しようとします。同様に、受信側でも再起動時に履歴記録が回復されます。

可用性の高いメッセージングのための移行可能なSAFエージェント

インポート済みJMS宛先に対するSAF送信エージェントによってクラスタ内の依存するJMSアプリケーションに対してシングル・ポイント障害が発生しないように、SAFエージェントをクラスタ内の正常なサーバー・インスタンスに自動または手動で移行するようWebLogic Serverを構成できます。

クラスタ指定SAFエージェントを使用し、自動的にエージェントおよびそれらのカスタム・ストアを使用するWebLogicクラスタ内の正常なサーバーに移行できます。『Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

また、サービスの移行では、JMSサーバー、SAFエージェント、永続ストアなどのJMS関連の固定サービスをグループ化した移行可能ターゲットを使用することができ、このような移行可能ターゲットはクラスタ内のいずれか1つの物理サーバーでホストされます。ホストされているサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行可能ターゲットによってホストされるJMSサービスは、サーバー障害への対処として、また定期的なメンテナンスの一環として手動で移行できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべての固定サービスも移行されます。

Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。