Topics
Enterprise Architecture
WebLogic Server 9.0におけるワークロード（作業負荷）管理
概要
ワークロード（作業負荷）管理は、クライアントで生成された作業を、アプリケーションサーバが受理して処理する方法を説明するために使われる用語で す。BEA WebLogic Server 9.0では、以前のリリースにはなかった、作業負荷管理のための新しい概念がいくつか導入されました。これらの概念は、以前のリリースで定義されていた実 行キューに取って代わるもので、作業の優先順位付け、スレッドプール管理、過負荷保護の考え方を含んでいます。この解説記事では、作業負荷管理が WebLogic Server 9.0ではどのように処理されるか、また、それが以前のリリースとどのように異なるかについて説明します。
はじめに
WebLogic Server 9.0より前のリリースでは、スレッド数が固定、かつ作業キューの長さが未定の状態で実行キューを設定しなければなりませんでした。しかし、スレッド数の ような低レベルのカーネル属性を直接扱うことには問題がありました。管理者は次のような困難に直面していました。
- アプリケーションが与えられたときに、必要なスレッド数を正確に決定するのは困難です。適度なパフォーマンスを実現できるスレッド数を決定するためには、数多くの試行錯誤が必要です。
- 作業の優先順位付けを実現するには、独立の実行キューを作成しなければなりません。たとえば、同じサーバインスタンス上に2つのアプリケーション がデプロイされているシナリオを考えます。管理者は、要求の到着率に関係なく、任意の時点で、両方のアプリケーションがスレッドリソースのフェアシェアを 取得できることを保証する必要があります。これを保証する唯一の方法は、アプリケーションごとに専用のスレッドを持つ独立した実行キューを2つ用意するこ とです。
- 同じアプリケーション内で複数の要求を処理できるように、実行キューを設定する必要がある場合もあります。実行キューが、処理の遅いバックエンド とやり取りをする場合、処理の遅い要求の到着率の方が遥かに高いため、処理の速い要求の実行が妨げられる可能性があるからです。これは、コンボイ現象と呼 ばれることもあります。WebLogic Server 9.0より前のリリースでは、専用のスレッドプールを作成することが、このような問題に対する唯一の解決策でした。
- 専用の実行キューは、順序付けを保証し、特定のクラスの要求に対する作業をピックアップするスレッドが少なくとも1つ存在するように設定されていなければなりません。
- 各実行キューは、固有のスレッドプールを作成します。サーバ内のスレッド数は、サーバ内のすべての実行キューのスレッド数の合計になります。実行 キューは、容量とパフォーマンスが最大になるように設定されます。これは、利用率が低いにもかかわらず、監視しなければならないスレッドが、サーバ内に大 量に存在する可能性があることを意味します。100スレッドを超えるスレッドダンプを想像してください。問題を診断するのは困難です。
WebLogic Server 9.0を使用すると、管理者は専用の実行キューを設定する必要がなくなり、実行キューが理解できる言語でアプリケーションの要件を記述することができるようになります。主な機能を以下に示します。
- アプリケーションは、フェアシェアパラメータを使用して、スレッドリソースのフェアシェアを要求できます。これによって、 WebLogicServerカーネルは、到着パターンに関係なく、2つのアプリケーションに平均にスレッドを割り当てます。実際には、これは、何も設定 しなくてもデフォルトで実行されます。
- 管理者は、もはやスレッド数を設定する必要はありません。最適なスレッド数は、全体的なスループット測定に基づいて、サーバが自動的に決定します。
- 専用のスレッドプールを作成せずに、制約を設定することによって、同時実行の最大値と最小値を強制できます。
- 実行キューとは違い、すべてのワークマネージャが1つの共通スレッドプールと、1つの優先度キューを共有します。スレッドプールのサイズは、カー ネルによって自動的に決定されます。また、必要に応じてサイズ変更されます。ワークマネージャ（次ページで説明）は非常に軽量になります。また、ユーザ が、スレッドプールのサイズを気にせずに、ワークマネージャを作成することもできます。スレッドダンプは、スレッド数が少ないのでかなりすっきり見えま す。
- 新しいモデルでは、同じサーブレット呼び出しに対して、その呼び出しに関連したユーザに応じて、フェアシェアや応答時間などの異なるサービスレベ ルアグリーメント（SLA）を指定することができます。たとえば、同じサーブレットまたはEJB呼び出しに対して、「上級」ユーザには、「評価」ユーザよ りも高いフェアシェアを与えることができます。
以降のセクションでは、これらの機能についてさらに詳しく説明していきます。
スレッドプールの新しい実装
WebLogic Server 9.0には、すべてのアプリケーションからの要求用に単一のスレッドプールがあります。同様に、保留中の作業はすべて、共通の優先度キューに入れられま す。スレッド数は、全体のスループットが最大になるように自動的に調整されます。要求の優先度は、予め決められている目標を満たすように、動的に内部で計 算されます。管理者は、フェアシェア目標や応答時間目標のようなアプリケーションレベルのパラメータを使用して、目標を設定するだけです。
以前のリリースでは、サーブレットやRMI要求は、それぞれ実行キューにマッピングされたディスパッチポリシーに関連付けられていました。明確な ディスパッチポリシーを持たない要求は、サーバ全体のデフォルトの実行キューを使用します。WebLogic Server 9.0でも、要求は依然としてディスパッチポリシーに関連付けられています。ただし、ディスパッチポリシーは、実行キューではなく、 ワークマネージャにマッピングされています。 ここで説明するワークマネージャの概念は、5ページで説明する「タイマーおよびワークマネージャ仕様」とは全く異なります。
明確なディスパッチポリシーを持たない要求は、そのアプリケーションのデフォルトのワークマネージャを使用します。つまり、各アプリケーションは、 それぞれ固有のデフォルトワークマネージャを持っています。このデフォルトのワークマネージャは他のアプリケーションと共有されません。この区別が重要な 点です。実行キューは常にグローバルであるのに対して、ワークマネージャは常にアプリケーションスコープを持っています。コンソールでグローバルに定義さ れたワークマネージャでさえも、実行時にはアプリケーションスコープを持ちます。つまり、各アプリケーションは、他とは異なる独自の実行時インスタンスを 持ちます。ただし、これらのすべてのインスタンスは、フェアシェア目標のような同じ性質を共有します。これによって、アプリケーションレイヤで作業を追跡 できると同時に、個々のアプリケーションの優れたサスペンションのような機能を提供できます。
先に述べたように、サーブレットやRMI要求は、それぞれ1つのワークマネージャに関連付けられます。デフォルトでは、すべての要求が、そのアプリ ケーションのデフォルトのワークマネージャに関連付けられます。要求を特定のワークマネージャに関連付けるために、ディスパッチポリシー要素が使われま す。ワークマネージャは、アプリケーションスコープ内で定義されているか、または、サーバレベルでグローバルに定義されています。ディスパッチポリシーの 使い方については、後のセクションで例を示します。
スレッド数の自動チューニング
実行キューと、新しいスレッドスケジューリングモデルの主な違いの1つは、スレッド数を設定する必要がないところです。以前のリリースでは、ユーザ が、新たにスレッドプールを定義して、デッドロックを回避して差別化されたサービスを提供できるように、そのサイズを設定していました。しかし、最適なス ループットを達成し、デッドロックを回避できるように、実運用環境で必要なスレッド数を正確に決定することは極めて困難です。WebLogic Server 9.0では、デッドロックを回避し、同時実行制約に基づいて最適なスループットを達成できるように、スレッド数が動的に自動調整されます。これによって、 差別化されたサービスのための目標も達成できます。これらの目標は、フェアシェア目標または応答時間目標と呼ばれます。これについては、次のセクションで 説明します。
自動チューニングされたスレッドプールは、2秒ごとに全体のスループットを監視し、収集したデータを使用して、スレッド数を変更する必要があるかど うかを判断します。スレッド数を増やす、または減らす必要があるかどうかを判断するアルゴリズムでは、現在のスレッド数、測定されたスループット、および 過去の履歴が考慮されます。そして、必要に応じて、自動的に、新しいスレッドがプールに追加されたり、スレッドがプールから削除されます。
Printer View