| Oracle® Fusion Middleware Oracle Service Bus管理者ガイド 11g リリース1(11.1.1.5.0) B61436-03 |
|
 前 |
 次 |
エンドポイントURIとは、ビジネス・サービスがアクセスする外部サービスのURLです。Oracle Service Busでは、ビジネス・サービスのエンドポイントURIを1つ以上定義する必要があります。ビジネス・サービスに複数のエンドポイントURIを定義する場合、次のロード・バランシング・アルゴリズムのいずれかを定義する必要があります。
ラウンド・ロビン
ランダム
ランダムな重みベース
なし
ロード・バランシング・アルゴリズムは、ビジネス・サービスがエンドポイントURIへのアクセスを試行する方法を制御します。エンドポイントURIの状態は、オンラインまたはオフラインです。詳細については、26.9項「ビジネス・サービスの操作設定の構成」を参照してください。
ここででは次のトピックについて説明します。
ビジネス・サービスの再試行オプションを定義できます。再試行オプションでは、ビジネス・サービスが最初の失敗後にエンドポイントURIへのアクセスを試行できる最大回数を指定します。たとえば、エンドポイントURI eu1、eu2およびeu3を使用した場合のビジネス・サービスBの動作を考えてみます。再試行回数は、それぞれ1、2および4に設定しています。
再試行回数 = 1の場合 - ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、エラーを返します。ビジネス・サービスは、3番目のエンドポイントURI eu3を試行しません。
再試行回数 = 2の場合 - ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。再試行が失敗した場合には、エラーを返します。
再試行回数 = 4の場合 - ビジネス・サービスBは、リクエストを処理できない場合や、エンドポイントURI eu1にアクセスできない場合、eu2を使用してリクエストを処理しようとします(再試行1)。再試行が失敗した場合には、eu3を使用してリクエストを処理しようとします(再試行2)。次に、再試行の反復間隔に構成した間隔(秒)をおいて、eu1を試行します(再試行3)。これに失敗すると、eu2を再試行します(再試行4)。再試行が失敗した場合には、エラーを返します。
再試行回数を0に設定すると、ビジネス・サービスは、失敗後に再試行を実行しません。
|
注意: ビジネス・サービスがエンドポイントを再試行する順序は、ロード・バランシング・アルゴリズムによって制御されます。 |
通信エラーやアプリケーション・エラーが発生すると、ビジネス・サービスはリクエストの処理に失敗します。
通信エラーは、様々なネットワークの問題によって発生します。その場合、別のエンドポイントURIを使用して要求を再試行すると正常に処理できる可能性があります。アプリケーション・エラーは、要求の形式が正しくない場合やエラーが原因で発生します。すべてのエンドポイントは、このエラーを処理できません。その場合、使用した転送に応じて、ビジネス・サービスの「転送コンフィグレーション」ページにある「アプリケーション・エラーの再試行」を「いいえ」に設定することにより、アプリケーション・エラーの再試行動作を無効にできます。
通信エラーは、応答していないURIに対してビジネス・サービスがアクセスを試行するたびに発生します。ビジネス・サービスを構成することにより、応答していないURIをオフラインとしてマークできます。これにより、応答していないURIに対してビジネス・サービスがアクセスを繰返し試行することを防止し、通信エラーを回避します。
これを行うには、ビジネス・サービスの「オフラインのエンドポイントURI」操作設定を有効にする必要があります。以下の項の説明に従うことにより、エンドポイントURIを一時的または永続的にオフラインとしてマークできます。
ビジネス・サービスが短い時間間隔で自動的に同じエンドポイントを再試行するようにするには、エンドポイントURIを一時的にオフラインとしてマークします。ユーザーが手動でリセットするまで、ビジネス・サービスがエンドポイントURIをオフラインとして処理するようにするには、エンドポイントURIを永続的にオフラインとしてマークします。
指定した時間間隔でビジネス・サービスが自動的に同じエンドポイントを再試行するようにするには、エンドポイントURIを一時的にオフラインとしてマークします。
エンドポイントURIを一時的にオフラインとしてマークするには、ビジネス・サービスの「オフラインのエンドポイントURI」操作設定にある「再試行間隔」の値を指定します。通信エラーが発生すると、エンドポイントURIの状態は「オフライン」に変更されます。再試行間隔の期間が経過すると、そのビジネス・サービスは新しいリクエストを処理するために、このエンドポイントURIへのアクセスを試行します。この試行が正常に実行された場合、エンドポイントURIは、再びオンラインとしてマークされます。エンドポイントURIにアクセスできなかった場合、再試行間隔の期間、そのURIは再びオフラインとしてマークされ、このサイクルが繰り返されます。
この構成は、通信エラーが一時的であり、自動的に修復する場合に役立つ可能性があります。たとえば、一時的なオーバーロードの場合、通信エラーは発生しますが、エンドポイントは自動的に正常動作に復帰するため、手動で介入する必要はありません。
ユーザーが手動でリセットするまで、ビジネス・サービスがエンドポイントURIをオフラインとして処理するようにするには、エンドポイントURIを永続的にオフラインとしてマークします。
エンドポイントURIを永続的にオフラインとしてマークするには、ビジネス・サービスの「オフラインのエンドポイントURI」操作設定にある「再試行間隔」の値を、0時間0分0秒に指定します。通信エラーが発生すると、エンドポイントURIの状態は「オフライン」に変更され、エンドポイントURIを再びオンラインとしてマークするまでオフラインに保持されます。
詳細は、26.9項「ビジネス・サービスの操作設定の構成」および第46章「実行時のOracle Service Busのモニター」を参照してください。
この構成は、手動介入によって解決する必要があるエンドポイントURIの問題に起因する通信エラーが発生した場合に役立ちます。
Oracle Service Bus管理コンソールまたはJMXモニタリングAPIを使用してメトリックをモニターできます。Oracle Service Bus管理コンソールの使用の詳細は、46.5.1項「Oracle Service Bus管理コンソールからサービス統計にアクセスする方法」を参照してください。JMXモニタリングAPIの使用方法については、付録D「JMXモニタリングAPI」を参照してください。
Oracle Service Bus管理コンソールでは、サービスの「サービスのモニターの詳細」ページにある「エンドポイントURI」タブでエンドポイントURIのメトリックを使用できます。回数、レスポンス時間、エンドポイントURIの状態などのメトリックがあります。
このビューに表示される統計の詳細は、26.15項「ビジネス・サービスのエンドポイントURIのメトリックの表示」を参照してください。
エンドポイントURIは、URI状態統計とURIレベル統計を使用してモニターできます。以下は、エンドポイントURIをモニターする際に予期される動作の説明です。
統計は、ビジネス・サービスのモニターを有効にしている場合のみ取得できます。
サービスの名前変更や移動を行うと、URIレベル統計がリセットされます。
集約間隔を変更すると、URI状態を除くすべてのURIレベル統計がリセットされます。
サービスの統計をリセット(またはすべての統計をリセット)すると、URI状態を除くすべてのURIレベル統計がリセットされます。
新しいURIを既存のビジネス・サービスに追加すると、その新しいURIのメトリックが自動的に収集されます。
Oracle Service Bus管理コンソールの状態統計は、エンドポイントURIがオンラインであるか、オフラインであるかを示します。JMXモニターリングAPIを使用してエンドポイントURIの状態を取得することもできます。表48-1は、考えられるエンドポイントURIの状態についての説明です。
表48-1 エンドポイントURIの状態
| 状態 | 説明 |
|---|---|
|
オンライン |
特定のサーバーのURIがオンラインであることを示します。クラスタでは、すべてのサーバーのURIがオンラインであることを示します。 |
|
オフライン |
特定のサーバーのURIがオフラインであることを示します。クラスタでは、すべてのサーバーのURIがオフラインであることを示します。 |
|
部分的 |
クラスタ内の1つ以上のサーバーがそのURIについて問題を報告していることを示します。このメトリックは、クラスタだけに使用できます。 |
|
注意: URIが複数のビジネス・サービスに関連付けられている場合、同じエンドポイントURIの状態がビジネス・サービスごとに異なる可能性があります。 |
エンドポイントURIのパフォーマンス・メトリックでは、特定のエンドポイントで処理されたメッセージの数、失敗の数、およびそのレスポンス時間に関する情報が提供されます。次のメトリックは、エンドポイントURIのモニター用に使用できます。
メッセージ数
エラー数
平均レスポンス時間
最小レスポンス時間
最大レスポンス時間
これらの統計の詳細は、26.15項「ビジネス・サービスのエンドポイントURIのメトリックの表示」を参照してください。
以下は、エンドポイントURIの統計の重要な特性です。
統計は、ビジネス・サービスのモニターを有効にしている場合のみ取得できます。
サービスの名前変更や移動、または集約間隔の変更を行うと、URIレベル統計がリセットされます。
新しいURIを既存のビジネス・サービスに追加すると、その新しいURIのメトリックが自動的に収集されます。
Oracle Service Bus管理コンソールを使用するか、パブリックAPIを使用することにより、オフラインのエンドポイントURIをオンラインとしてマークできます。
Oracle Service Bus管理コンソールでは、「サービスのモニターの詳細」ページから、オフラインのエンドポイントURIをオンラインとしてマークできます。「エンドポイントURI」タブの「アクション」列にある「クリックすると、このエンドポイントURIがオンラインとしてマークされます」アイコンをクリックします。詳細については、26.15項「ビジネス・サービスのエンドポイントURIのメトリックの表示」を参照してください。
次の場合には、すべてのエンドポイントURIがオンラインとしてマークされます。
それらをビジネス・サービスに追加する
サーバーを再起動する
無効になっているサービスを有効にする
サービスの名前変更または移動する
構成した再試行間隔の期間が経過すると、ビジネス・サービスはuriに正常にアクセスできます。
APIを使用して、オフラインのエンドポイントURIをオンラインとしてマークすることもできます。この方法は、ビジネス・サービスのモニターを有効にしていないが、そのエンドポイントURIをオンラインとしてマークする必要がある場合に役立ちます。詳細については、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスの、com.bea.wli.monitoring.ServiceDomainMBeanに関する項を参照してください。
クラスタ・ドメインのエンドポイントURIをオンラインとしてマークすると、すべての管理対象サーバーのエンドポイントURIがオンラインとしてマークされます。
エンドポイントURIにアクセスできない場合、アクセスを試行しているビジネス・サービスは通信エラーを受け取ります。
応答していないURIをオフラインとして取得するようにビジネス・サービスを構成する(48.2項「応答していないURIをオフラインとしてマークする方法」を参照)だけでなく、応答していないURIがシステムによって検出された場合にアラートを発生させることができます。これを行うには、エンドポイントURIの状態に基づいたSLAアラート・ルールを構成します。
エンドポイントURIの状態に基づいてビジネス・サービスのアラート・ルールを構成できます。26.23.1項「アラート・ルールの全般的な情報の構成」の説明に従ってタスクを完了します。
次に、図48-1に示すように、「アラート・ルール条件の構成」ページで次のタスクを完了します。
「アラート・ルール条件の構成」ページの「単純な式」セクションで、最初のリストの「ステータス」を選択します。
エンドポイントURIの状態に基づくアラート・ルール条件は、以下の内容で構成されます。
状態移行句 - 状態移行句では、特定のエンドポイントURIまたはすべてのエンドポイントURIの状態がオンラインからオフライン(またはオフラインからオンライン)に変更されたときの通知がサポートされます。通知の作成対象の状態を識別するには、次のオプションのいずれかを選択します。
オフラインのすべてのURI
オンラインのすべてのURI
オフラインの特定のURI
オンラインの特定のURI
たとえば、1つは「オフラインのすべてのURI = True」条件、もう1つは「オフラインの特定のURI = True」条件に基づいた2つのアラート・ルールが構成されているビジネス・サービスを考えてみます。「オフラインのすべてのURI = True」条件に基づいてアラートが生成されている場合、この状態が解決されるまでこのサービスに対するすべてのリクエストが失敗する可能性が高いため、これは重大な問題を示します。
しかし、「オフラインの特定のURI = True」に基づいてアラートが生成されている場合、これは、他のエンドポイントURIが応答するために以降のリクエストが失敗しない可能性があることを示します。
|
注意: すべてのアラート・ルールは、単独で評価されます。同じビジネス・サービスに対して両方(特定またはすべてのURI)の句に基づくアラートを構成すると、最後のエンドポイントURIをオフラインとしてマークするときに両方のアラートが同時に生成される可能性があります。ビジネス・サービスがURIを1つのみ持つ場合、 オフラインからオンラインへの移行に基づくアラート・ルール条件の評価は、再度オンライン状態としてマークされている特定またはすべてのエンドポイントURIを追跡する場合を除き、同じように動作します。 |
サーバー句 - サーバー句では、特定のサーバーまたはすべてのサーバーで状態の移行が発生したときのアラート・トリガーを指定できます。サーバー句は、複数の管理対象サーバーを持つクラスタ・ドメイン内でのみ意味を持ちます。式を作成するには、次のいずれかのオプションを選択します。
すべてのサーバーで評価する
特定のサーバーで評価する
管理対象サーバーをホストしているマシンでは、ネットワークの問題に起因する通信エラーが発生する可能性があります。ビジネス・サービスは、このようなイベントについては、(アクセスしているリモート・エンドポイントが応答していても)エンドポイントURIが応答していないと解釈します。エンドポイントURIが応答していないために、通信エラーが発生する場合もあります。
最初のケースでは、URIは、(ネットワークの問題があるマシン上の)1つのサーバーでのみオフラインとしてマークされ、クラスタ内のその他のサーバーではすべてオンラインとしてマークされます。「特定のサーバーで評価する」句に基づくアラート条件ではアラートが生成されますが、「すべてのサーバーで評価する」句に基づくアラート条件ではアラートは生成されません。
2番目のケースでは、URIは、すべての管理対象サーバーでオフラインとしてマークされます(各サーバーがそのエンドポイントへのアクセスを試行するたびに1つずつマークされます)。各管理対象サーバーがエンドポイントURIをオフラインとしてマークするたびに、「特定のサーバーで評価する」に基づくアラート・ルール条件が満たされ、アラートが生成されます。クラスタ・ドメイン内の最後のサーバーのエンドポイントURIをオフラインとしてマークすると、「すべてのサーバーで評価する」に基づくアラート・ルール条件も満たされ、このアラートも生成されます。
|
注意: すべてのアラート・ルールは、単独で評価されます。同じビジネス・サービスに対して両方(特定またはすべてのサーバー)句に基づくアラートを構成すると、クラスタ内の最後のサーバーのエンドポイントURIをオフラインとしてマークするときに両方のアラートが同時に生成される可能性があります。単一サーバー・ドメインでは、 |
システムのアラート・ルールを設計する際には、要件に従って句の組合せを1つ以上選択する必要があります。
条件のいずれか1つを「True」または「False」に設定する必要があります。これらの条件は、クラスタ内のすべてのサーバーまたは特定のサーバーに対して評価できます。
|
注意: URIの状態が頻繁に変更される場合にトリガーされたアラートを見逃さないように、URIの状態に基づくアラート・ルールの集約間隔を1分に設定することをお薦めします。集約間隔の詳細は、46.2項「集約間隔」を参照してください。 |
