G ワーク・マネージャとスレッド

この付録では、Oracle Service Busによって使用される内部スレッド・モデルと、パフォーマンスおよびサーバーの安定性に関するその影響について説明します。HTTPトランスポートに焦点を当てます。

この付録の内容は次のとおりです。

G.1 スレッドの主要な概念

ワーク・マネージャをサービスに割り当てる場合、次の概念を考慮することが重要です。

リクエストおよびレスポンスのパイプラインは常に個別のスレッドで実行されます。リクエスト・スレッドはプロキシ・サービス・トランスポートを起点とし、レスポンス・スレッドはビジネス・サービス・トランスポートを起点とします。
外部サービスの起動時、スレッドは、パイプライン・アクション、サービス品質(QoS)の構成、および使用中のトランスポートに応じて、ブロッキングまたは非ブロッキングのいずれかになります。
ブロッキング呼出しを使用する場合は、サーバーのデッドロックを回避するために、最小スレッド制約を持つワーク・マネージャをレスポンスに関連付ける必要があります。

Service Busはプロキシ・サービス間の呼出しを最適化します。あるHTTPプロキシ・サービスが次のHTTPプロキシ・サービスを呼び出すと、トランスポート・レイヤーがバイパスされます。リクエスト・メッセージがネットワーク・ソケットを使用して送信されないため、トランスポートのオーバーヘッドが削減されます。かわりに、最初のプロキシ・サービスを処理するスレッドが、呼び出されたサービスのリクエスト・パイプラインの処理を継続します。同様に、ビジネス・サービスを起動すると、プロキシ・サービス・スレッドがリクエストの送信にも使用されます。HTTPトランスポートはWebLogic Serverの非同期機能を使用するため、ビジネス・サービスのレスポンスは別のスレッドで処理されます。

スレッドの説明において、Service BusがWebLogic Server上で実行されることを記憶しておくことは重要です。 Service Busは、様々なタイプのリクエストの実行をWeb Logic Server HTTP、JMSおよびコア・エンジンに依存する場合があります。時には、Service BusからWebLogic Serverに処理の一部が渡されます。 WebLogic Serverは、WebLogic Server自己チューニング・スレッド・プールで利用可能なスレッドを使用して、それを実行します。Service Busのドキュメントでは、Service Busの処理がWebLogic Serverおよびその自己チューニング・スレッドに依存するシナリオについては記載していません。

例として、サービス・コール・アウトの場合、Service Busレイヤー内の同期コールであっても、バックエンドからのレスポンスはWebLogic Socket Muxerスレッドが読み込む必要があります。これらのMuxerスレッドは、バックエンド・システムからレスポンスを取得した後、ブロックされ、レスポンスを待っているService Busスレッドに通知します。

すべてのService Busプロキシおよびビジネス・サービスは、それぞれワーク・マネージャからのスレッドを使用して実行するように構成することを強くお薦めします。ワーク・マネージャの制約の最小値および最大値は最大ロードに基づいて設定してください。これにより、プロキシ・サービスおよびビジネス・サービスが、実行に関してWebLogic Server実行スレッド・プールに依存しなくなり、WebLogic Serverは、スレッドがスタックする問題を引き起こすことなく、Service Busからの非定型リクエストを処理するのに十分な空きスレッドまたはアイドル・スレッドを持ちます。

G.2 パイプライン・アクション

この項では、スレッドに特に影響するパイプライン・アクションについて説明します。

パイプライン・アクションは、ルート・アクション、パブリッシュ・アクションおよびサービス・コールアウト・アクションです。

G.2.1 ルート・アクション

デフォルトでは、HTTPトランスポートはWebLogic Serverの非同期機能を使用して、ビジネス・サービスのレスポンスを待機しながらスレッドのブロックを回避します。ルート・アクションの実行では、リクエストの送信を完了したスレッドはプールに戻され、そこで別の作業の処理に使用されます。外部サービスからレスポンスが返されると、それを処理するために2番目のスレッドがスケジュールされます。この動作は、ルート・オプション・アクションを使用し、「QoS」を「必ず1回」に設定することで変更できます。

G.2.2 パブリッシュ・アクション

パブリッシュ・アクションは一方向の送信です。これは、レスポンスを受信せずに外部サービスを起動する手段を提供します。多くの場合、ロギングや監査などのイベントの通知に使用されます。デフォルトでは、呼出しの成否はパイプライン・スレッドに返されません。前述の2つのアクションでは、「QoS」を「必ず1回」に設定すると、レスポンスを受信するまでリクエスト・スレッドが強制的にブロックされます。これにより、リクエスト・スレッドは、コールバックなしで呼出し元にただちにエラーを通知できます。この動作はまた、プロキシ・サービスを同時に処理するスレッド数を調整する場合に役立ちます。

G.2.3 サービス・コールアウト・アクション

サービス・コールアウトは、同期ブロッキング呼出しとして実装されます。これは、ターゲット・サービスにリクエストをルーティングする前に、外部サービスを起動して、リクエスト・メッセージに情報を追加する機能を提供するために設計されたものです。コールアウトがレスポンスを待機している間、リクエスト・パイプライン・スレッドは、レスポンスの準備が完了して処理が続行できることをレスポンス・スレッドが通知するまでブロックされます。

G.3 ワーク・マネージャ

ワーク・マネージャは、WebLogic Server管理コンソールを使用して作成および構成されます。この項では、Service Busの最適化の鍵となるワーク・マネージャの概念について説明します。

WebLogic Serverは、自己チューニング・スレッド・プールを使用してアプリケーション関連のすべての作業を実行します。プール・サイズは増分マネージャによって管理され、プールのスレッドが必要に応じて追加または削除されます。アクティブ・スレッド数は400を超えることはありません。リクエストがサーバーに届くと、スケジューラがリクエストの実行順序を管理します。リクエスト数が使用可能なスレッド数を超えると、リクエストはキューに格納され、スレッドがプールに戻って使用可能になった時点で実行されます。ワーク・マネージャはスケジューラに対して、作業のタイプとリクエストの優先度を示します。

ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

G.3.1 ワーク・マネージャの構成

ワーク・マネージャの構成に重要なプロパティは、最大スレッド制約と最小スレッド制約です。最大スレッド制約は、スケジューラに対して、構成された数を超える同時実行を制限することにより、あるリクエスト・タイプを実行する同時スレッド数を制限します。ただし、スレッド・プールはすべてのワーク・マネージャで共有されるため、常に最大数のスレッドで処理を実行できるわけではありません。

最小スレッド制約は、最小数のスレッドの処理を保証します。最小数のプロセスに至るまでの十分なスレッドがスレッド・プールで使用可能でない場合、スケジューラは最小数のスレッドの処理に対応するためにスタンバイ・スレッドを使用します。スタンバイ・スレッドは、プール内の最大数である400スレッドとしてはカウントされません。最小スレッド制約を含むワーク・マネージャに関連付けられたリクエストをスレッドで実行する場合、ワーク・マネージャはまず、同じ制約が関連付けられた別のリクエストについてキューをチェックし、それを実行します(空きプールには戻りません)。このような理由から、最小スレッド制約は慎重に使用してください。使いすぎるとデフォルトのワーク・マネージャのリソースが不足して、予期できない結果が生じることがあります。

G.3.2 ワーク・マネージャの優先度

デフォルトでは、ワーク・マネージャはスケジューラと同じ優先度を持ち、共有値は50に設定されています。待機中のリクエストを実行する際、スケジューラは、各ワーク・マネージャに関連付けられたリクエストに同数のスレッド・リソースが渡されていることを確認します(待機中のリクエストが同数である場合)。

ワーク・マネージャは、ディスパッチ・ポリシーを指定することでService Bus内からサービスに関連付けられます。ビジネス・サービスにルーティングする簡単なプロキシ・サービスが存在する場合は、各サービスに様々なディスパッチ・ポリシーを割り当てることができます。これにより、スケジューラは、新しいリクエストが受信レスポンスとは異なる作業であることを認識します。その後、作業リクエスト(プロキシ・サービスに対する新しい受信リクエスト・メッセージまたはビジネス・サービスに対するレスポンス・メッセージのいずれか)がキューに追加されると、各ワーク・マネージャは均等にスケジュールされます。これは、ビジネス・サービスがブロッキング呼出しにより起動される場合(サービス・コールアウトの場合)に不可欠になります。

スレッドが特定のワーク・マネージャを指定して処理されると、プールに戻るまでそれが継続されます。したがって、パイプライン内部からビジネス・サービスまたはプロキシ・サービスを起動した場合、実行中のスレッドは引き続き、最初のプロキシ・サービスのワーク・マネージャの下で処理されます。この場合、呼び出されるサービスに指定されたワーク・マネージャは無視されます。

G.4 ワーク・マネージャの指定

ビジネス・サービスのワーク・マネージャ(ディスパッチ・ポリシー)構成は、ビジネス・サービスの起動方法に応じて行う必要があります。

サービス・コールアウト、パブリッシュ・アクション、または必ず1回行われるQoS (「パイプライン・アクション」を参照してください)によるルーティングを使用してプロキシ・サービスおよびビジネス・サービスを起動する場合は、プロキシ・サービスおよびビジネス・サービスの両方で同じワーク・マネージャを使用するのでなく、異なるワーク・マネージャを使用することを検討してください。ビジネス・サービス・ワーク・マネージャでは、使用可能なスレッドを確保するために、「最小スレッド数制約」プロパティの数を少なく構成します(1-3)。