WebSphere Virtual Enterprise によるサービス・レベルの差別化

WebSphere® Virtual Enterprise では、受信したリクエストのサービス・レベルを差別化することができます。しかし適切な結果を得るためには構成を熟慮する必要があります。この記事では、サービス・レベルの差別化に関する WebSphere Virtual Enterprise の挙動について、また適切な構成を行うための方法について説明します。

Benjamin Parees, Software Engineer, IBM

Ben PareesBen Parees は現在、IBM のアドバイザリー・ソフトウェア・エンジニアです。彼は過去 6 年間、ソフトウェア・エンジニアとして IBM で働いています。ここ 2 年間は、ディメンショナル・モデリング手法を活用する WebSphere Business Monitor 製品のデータベース・アーキテクチャーに携わっています。



2009年 11月 04日

WebSphere Virtual Enterprise におけるサービス・レベルの差別化

サービス・レベルの差別化とは、特定のリクエストを他のリクエストよりも優先することで、より重要なアプリケーションの可用性を保証する、あるいは重要なユーザー・リクエストへの応答時間を短縮する概念です。WebSphere Virtual Enterprise では、そこに含まれるいくつかのコンポーネントが連携して動作し、管理者はアプリケーション環境でサービス・レベルの差別化を図ることが可能となっています。これは、管理者が指定する優先順位と、システムの動的な状態に基づいて、利用可能なサーバー・キャパシティーを管理することにより行われます。この記事ではオートノミック要求フロー・マネージャー (ARFM) について説明します。ARFM はリソースが限られている場合に、優先度の低いトラフィックを制限します。


オートノミック要求フロー・マネージャー (ARFM) の紹介

オートノミック要求フロー・マネージャー (ARFM) は WebSphere Virtual Enterprise のコア・コンポーネントであり、どの着信リクエストをいつサービスするかの優先順位を決定することでサービス・レベルの差別化を実現します。優先順位の決定は、着信トラフィックの動的分析、利用可能なサーバー・キャパシティー、およびユーザーによって定義されたサービス目標に基づいて行われます。

サーバー・キャパシティーについて、ARFM は、リクエストを処理できる一連のアプリケーション・サーバー (つまりクラスター) 全体を対象として考慮します。1 台のサーバーだけが対象となるわけではないことに注意してください (ただし対象のアプリケーションに対するリクエストを処理できるサーバーが 1 台しかない場合は別です)。

図 1 はリクエストの処理方法を要約したものです。リクエストが オンデマンド・ルーター に到達すると、ARFM はそれらのリクエストをキューに入れ、それらをいつバックエンドのアプリケーション・サーバーにディスパッチするかを決定します。すべてのリクエストを同時に処理するだけの十分なリソースがない場合、このキュー・プロセスによって、優先度の高いトラフィック (優先度は管理者が指定します) が最初に処理され、その後で優先度の低いトラフィックが処理されます。トラフィックをキューに入れると応答時間が増加します。これは、そのトラフィックが少しの時間キューに保持された後で処理されるためです。

ARFM は、リクエストに関連付けられたサービス・ポリシーに基づいてリクエストをキューに入れます。サービス・ポリシーというのは、リクエストのパターンと、そのパターンと一致するリクエストが満たすべき応答時間目標とを組み合わせたものです。またサービス・ポリシーには重要度の値も含まれます。この値によって、そのサービス・ポリシーに関連付けられるリクエストに対し、その優先度を直接指定します。

ARFM は、利用可能なバックエンド・リソースと、キューの中で処理を待っているリクエストとを比較します。

ARFM は利用可能なリソースに基づき、(リクエストがある場合には) どのリクエストをディスパッチするかを選択します。また、サーバー・キャパシティーを増やすことで、発生しているキューイングを軽減できると判断すると、ARFM は追加のサーバーをオンラインにするよう要求します。この詳細については次のセクションで説明します。

これらの動作の詳細については下記の「参考文献」を参照してください。今後の記事では アプリケーション配置コントローラー・コンポーネントについても説明します。アプリケーション配置コントローラー・コンポーネントは ARFM による負荷要件レポートに基づいてサーバーの起動停止を行います。

図 1. オンデマンド・ルーターのリクエスト・フロー
オンデマンド・ルーターのリクエスト・フロー

ARFM はどのようにしてキャパシティーを管理するか

ARFM は制御サイクル (デフォルトは 1 分間) ごとに、利用可能なサーバー・キャパシティー、現在のトラフィック要求、そのトラフィックに関するキャパシティー要件、そのトラフィックで想定される応答時間を調べ、システムの現状を分析します。この情報に基づき、ARFM は各サービス・ポリシーに対する「割り振り」を算出します。割り振りは、(十分なサーバー・キャパシティーがあるという前提で) サービス目標が必ず達成されるように設計されています。

これらの割り振りは、一連のアプリケーション・サーバーに対して各サービス・ポリシーのリクエストを同時にいくつ受け付けられるか、という形を取ります。特定のサービス・ポリシーに対し、そのクラスの同時割り振りで処理可能な数を超えるリクエストを受信した場合には、それまでに受信したリクエストの処理が完了して同時処理の制限内に収まるようになるまで、処理能力を超えた分のリクエストはキューに入れられます。通常のようにキューから即座にディスパッチされるわけではありません。

特定のサービス・ポリシーに対する割り振りを決定するにあたり、ARFM はまず、アプリケーション・サーバー上で利用可能なキャパシティーと、多様なサービス・ポリシーから予想される CPU 要求を判断します (予想されるリクエスト頻度と、特定のサービス・ポリシーに分類されるリクエストの処理に必要な CPU 要求を、履歴データを基に判断します)。

ARFM は次に、各サービス・ポリシーに対する割り振りを最適化しようとします。そのために、(過去の監視を基に) 予想されるトラフィック要求と、そのクラスのトラフィックの処理に必要な時間に基づいて、そのサービス・ポリシーに対して発生し得るキューイングの量を予測します。予想サービス時間 (通常の負荷条件で、リクエストの処理に通常どれだけ時間を要するか) と、そのクラスのトラフィックに対して定義されたサービス目標との差が、サービス目標に違反せず ARFM がキューにリクエストを保持できる時間、ということになります。つまり、(キャパシティーが十分あるならば、) キューに保持される時間とアプリケーション・サーバーでの実際のリクエスト処理時間とを加えた値が、構成されたサービス目標よりも小さくなければなりません。各サービス・ポリシーに対する同時処理の割り振りは、システム全体の即応性に対するキューの影響を最小限にとどめるように、またサービス目標に違反しないように行われます (十分なキャパシティーがない場合、ARFM は、トレードオフとして違反を許すサービス目標とその度合いを決定します)。

ARFM は、『アプリケーションで処理可能な最善の予想サービス時間は、バックエンド・サーバーが過負荷ではない場合に記録されたサービス時間である』という前提のもとでトラフィックのプロファイリングを行います。その際、リクエスト間の競合は (同じサービスへのリクエストかそれぞれ異なるサービスへのリクエストかに関わらず) 考慮されず、またデータベースなどのバックエンド・リソースに対する競合も考慮されません。

ここで、ゴールド・トラフィックとブロンズ・トラフィックという 2 種類のクラスのトラフィックがあるシナリオを考えてみましょう。このシナリオでは、ゴールド・トラフィックはブロンズ・トラフィックよりも重要であり、どちらのタイプのリクエストでも共通のバックエンド・データベースに対する負荷が発生します。ここで、バックエンド・データベースが過負荷となり、一方でアプリケーション・サーバーのキャパシティーにはまだ余裕がある場合、どうなるでしょうか。過負荷のためゴールド・トラフィックの応答時間は増加し、ブロンズ・トラフィックを制限することでゴールド・トラフィックの応答時間を改善できるかもしれません。しかしデータベースに対する競合を緩和するためにブロンズ・トラフィックがキューに入れられることはなく、そのためゴールド・トラフィックの応答時間は増加します。これは、ARFM に管理されるリソース階層であるアプリケーション・サーバーが、過負荷になっていないからです。ARFM はゴールド・トラフィックのプロファイリングを続行し、ゴールド・トラフィックについて測定されるサービス時間の増加に合わせて、その予想サービス時間も増やします。ARFM からは、アプリケーション・サーバーが過負荷であるとは見なされず、そのため、ゴールド・トラフィックのサービス時間増加は、ゴールド・トラフィックの処理に必要な時間が基本的に変化したことによるものと判断されます。これはユーザーがよく混乱する点です。ユーザーは、この場合はブロンズ・トラフィックがキューイングされるはず、と思いがちですが、ARFM はブロンズ・トラフィックの増加とゴールド・トラフィックのサービス時間の増加との相関を判断することができません。ARFM はキャパシティーの最初の層のみを管理します。この状況を改善するためには、さらに深くの層までリソースの利用状況を調べる必要があります。限られた CPU サイクルに対し、ゴールド・リクエストとブロンズ・リクエストがアプリケーション層で競合している場合には、ARFM は想定どおりブロンズ・トラフィックをキューに入れます。

実際、サービス目標に違反しないように ARFM が実行するアクションは 2 つしかありません。1 つは、該当するサービス・ポリシーのトラフィックについて、ARFM がリクエストをキューに保持する時間を短縮することです (それによって全体としての応答時間を短縮します)。ただし ARFM がこのアクションを実行できるのは、そうしたサービス・ポリシーのトラフィックをキューイングしていた場合のみであり、先ほどの例はこれに該当しません。もう 1 つのアクションとして、ARFM はアプリケーション配置コントローラーに対し、動的クラスター内でサーバーを追加起動してキャパシティーを増やす必要があると通知することができます。しかしこれもまた、ARFM が実際にリクエストをキューイングしていて、キャパシティーの追加によりそれを回避できると判断した場合に限られます。このアクションでは、(リクエストがキューに保持されていた時間だけ) そのトラフィックの応答時間を短縮でき、サービス目標を違反せずに済むことが期待できます。

ARFM がトラフィックをキューイングしておらず、またアプリケーション・サーバーの CPU キャパシティーに余裕がある場合、ARFM は、リクエストが既に可能な限り迅速に処理されていると見なし、サービス目標を達成するためのアクションを実行しません。つまり、リクエストの応答時間増加はキューイングやアプリケーション・サーバーのキャパシティー不足の結果ではありません (上記の例の場合、応答時間の増加はデータベースのキャパシティー不足が原因です)。そのため、他のトラフィックをキューイングあるいはブロックしても、またキャパシティーを追加しても、状況を改善することはできません。既存のキャパシティーが完全に使用されているわけではないからです。

ARFM に関する最後のポイントは、ARFM がしきい値をどう判断するかに注意する必要があるということです。ARFM が、すべてのリクエストをサービスするためのキャパシティーが十分ではなく、一部のリクエストをキューイングする必要があると判断するしきい値は、CPU Overload Protection (過負荷保護) の値です (図 2)。デフォルトで、この値は 90% に設定されています。つまり ARFM は、アプリケーション・サーバーの CPU 使用率が 90% を超えるという段階になるまで、トラフィックのキューイングはいっさい行いません。この値を小さくすると、ARFM によってバックエンドに許可されるトラフィック量が減少します。その結果として ARFM は、より多くのトラフィックをキューイングするようになります。そのトラフィックに対して利用可能なバックエンドのキャパシティーが実質的に少なくなるからです。これは例えば、アプリケーション・サーバーの使用率が 50% に達するとデータベース・リソースが過負荷になることがわかっているような場合に便利です。その場合には CPU Overload Protection の値を 50% に設定することで、実質的にデータベースの過負荷を保護することができます。こうすることで、より深い層にあるリソースを ARFM を使って間接的に管理することができます。この CPU 使用率は、ARFM が通過を許可したリクエストの特性予測を基に ARFM によって概略計算された値であることに注意してください。そうした予測が正しくない場合には、実際のバックエンドの使用率によって、過負荷保護の目標に少し違反する場合や、あるいはまったく目標に達しない場合もあります。また、先ほど説明したように、ARFM は一連の同等のアプリケーション・サーバーを 1 つのリソースとして管理し、これらのサーバー間で負荷が均等に分散されるものと見なします。これはつまり、個々のサーバーの負荷レベルは高くなることも低くなることもあるということです。この動作については、今後の記事で DWLM (Dynamic Work Load Manager) コンポーネントの概要を取り上げる際に詳しく説明します。

図 2. ARFM の CPU Overload Protection (過負荷保護) のしきい値を構成する
ARFM の CPU Overload Protection (過負荷保護) のしきい値を構成する

サービス・ポリシーを定義する

WebSphere Virtual Enterprise では、ARFM によるトラフィック・フローの分析や最適化は、サービス・ポリシー定義を基に行われます。ARFM は各サービス・ポリシーのトラフィックを監視した結果に基づいて予測と計算を行います。ある 1 つのサービス・ポリシーの中では、すべてのリクエストは等価とみなされます。これはつまり、2 つのリクエストが同じサービス・ポリシーに分類される場合、ARFM はその 2 つのリクエストの応答時間や CPU に関する要件は同じであると見なします。

そのような前提で、次に述べる ARFM の動作を十分理解し、また落とし穴に注意する必要があります。ARFM はシステムを流れるトラフィック・フローをモデリングし、受信した一連のリクエストに対する応答時間を予測します。このモデリングのベースとなるのは、同じサービス・ポリシーに対する以前のリクエストで観測されたサービス時間の実績です。これはつまり、ARFM は、アプリケーション・サーバーはあるタイプのリクエストを毎秒ある数だけ処理できるものと見なす、ということです。ARFM はこの想定を基に、同時にいくつのリクエストを許可するのかを決定します。例えば、リクエストが処理待ちにならず、システムを過負荷にすることもなく、(ある特定クラスのトラフィックの) リクエストを毎秒 2 つ連続的に受信できると ARFM が予測した場合、受信したリクエストの 1 つの処理に予想を大幅に上回る時間がかかると、予想外のキューイングが発生します。するとしばらくの間、同時に処理できるリクエストの数は実質 1 つに減ります (同時処理用のもう 1 つのスロットは、予測に反して時間のかかっているリクエストによって占有されます)。その結果、処理時間の長いリクエストが返されて同時処理スロットが解放されるまで、さらに他のリクエストがキューイングされることになります。

この問題を避けるためには、サービス・ポリシーを定義する場合、そのサービス・ポリシーに分類されるトラフィックの典型的な応答時間がすべて同程度となるようにする必要があります。つまり、場合によっては複数の「ゴールド」サービス・ポリシーを定義することになり、これは同じアプリケーションによってサービスされる (ただし典型的な応答時間は異なる) リクエストについても同様です。

サービス・ポリシーの構成は 2 つのステップで行います。まず、関連付けられたリクエスト URI をトランザクション・クラスにグループ分けします (図 3)。これは管理コンソールで行い、Enterprise Applications (エンタープライズ・アプリケーション) ->< アプリケーション名 >-> Service Policies (サービス・ポリシー) の順に選択します。次に、Operational Policies (動作ポリシー) -> Service Policies (サービス・ポリシー) -> New (新規) の順に選択してサービス・ポリシーを作成します。新しいサービス・ポリシーを作成したら、そのポリシーを編集し (同じ Operational Policies->Service Policies パネルを使います)、そのサービス・ポリシーの定義とトランザクション・クラスを関連付けます (図 4)。またサービス・ポリシーの定義には、そのサービス・ポリシーに関連付けられたトランザクション・クラス (つまり URI) に適用される目標と重要度も含まれています (図 5)。サービス・ポリシーの定義は管理コンソールで Operational Policies->Service Policies の順に選択して行います。サービス・ポリシーを作成するための詳細に関しては、この記事の最後にある「参考文献」を参照してください。

図 3. リクエスト URI をトランザクション・クラスにグループ分けする
リクエスト URI をトランザクション・クラスにグループ分けする
図 4. トランザクション・クラスをサービス・ポリシーにグループ分けする
トランザクション・クラスをサービス・ポリシーにグループ分けする

初めてポリシーを構成する際は、1 つのアプリケーションに対しそのアプリケーションの重要度を基に直感的に 1 つのサービス・ポリシーを定義してしまいがちです。しかし 2 つのサービスの応答時間が大きく異なる場合には、その 2 つのサービスに対して別々のサービス・ポリシーを定義する必要があります。例えば検索サービスとタイムスタンプ・サービスの両方を提供するアプリケーションであれば、2 つのサービス・ポリシーを定義する必要があります。単なるタイムスタンプのレスポンスよりも検索リクエストの方が長い時間を要すると思われるからです。2 つのサービス・ポリシーを持つことによって、ARFM は各タイプのトラフィック (タイムスタンプ・リクエストと検索リクエスト) を個別にプロファイリングすることができます。こうすることで、ARFM は各リクエストに対する予想サービス時間の予測精度を向上することができ、それが結果的にトラフィックの状態に関するARFM の判断を改善することになります。

同様に、ARFM は、ある 1 つのサービス・ポリシーに属するリクエストであれば、どのリクエストもアプリケーション・サーバーに対する CPU 要求は同程度、と見なします。そのため、その想定とトラフィック・パターンとが一致しない場合には適切なフロー制御が行われなくなる可能性があります。例えば、バックエンド・サーバーで同時に 10 件のリクエストを処理でき、その結果 CPU 使用率が 90% (1 リクエスト当たり 9%) になると ARFM が計算したとします。その予想に反し、リクエストの 1 つが 27% の CPU 時間を使用したとすると、バックエンド・サーバーの使用率は 108% という過負荷になります。このシナリオは、もし ARFM が CPU リソースを 2 つのサービス・ポリシーの間で分割し、各ポリシーで 45% の CPU を消費するものと想定すると、さらに悪化します。この場合、過度に CPU を要求して過負荷の元となる片方のサービス・ポリシーのリクエストによって、もう一方のポリシーまたは両方のポリシーのサービス目標に違反する可能性があります。

この場合にも、検索リクエストとタイムスタンプ・リクエストの例が当てはまります。検索リクエストの方がタイムスタンプ・リクエストよりも CPU リソースを多く使用する可能性が高いからです。この 2 種類のリクエストを同じサービス・クラスに分類してしまうと、ARFM は CPU 要件を正確に予測することができず、ある時点でシステムが受信する検索リクエストとタイムスタンプ・リクエストの割合によって、アプリケーション・サーバーは過負荷または過小負荷になります。

以上の例は、わかりやすくするために誇張してあります。実際には、ARFM はリクエスト間に一貫性がなくても一定レベルまでは変動を想定し、許容します。しかし特定のタイプのリクエストの間に大きな違いがある場合には、それらのリクエストを個別のサービス・ポリシーに分割し、ARFM が各ポリシーを効果的に管理できるようにする必要があります。

トラフィックの分類とサービス・クラスの目標の他に、サービス・ポリシーには重要度が関連付けられています。重要度は実質的には乗数であり、実際の応答時間が、どの程度サービス目標を上回っているか、あるいは下回っているかを判断するために使われます。つまり ARFM は、特定の割り当てに対する目標達成または未達成の程度と、その目標の重要度の重みを乗算します。ARFM は、その乗算の結果の合計値が出来るだけ小さくなるように、さまざまなサービス・ポリシーに対する割り当てを最適化します。(この計算では、期待される応答時間がサービス目標よりも短い場合は負の値と見なされます。) サービス・ポリシーの目標タイプが「discretionary (任意)」というレベルの場合は、一連の割り当ての相対的な目標達成度には寄与しません。つまり ARFM は、そのサービス・クラスのトラフィックについてはキューイングを回避するための策はまったく講じず、そのトラフィックをキューイングすることで他のサービス・ポリシーの全体的な応答時間 (キューイング時間とサービス時間の合計) を改善できる場合には、制限なくそれを実行します。

例えば、ゴールド、シルバー、ブロンズという 3 つのサービス・ポリシーが定義されたシステムがあるとします。ゴールドは非常に高い重要度を持つと定義され、シルバーは中程度の重要度を持ち、ブロンズは discretionary と定義されています。(サーバーのキャパシティー不足のため) 即座には処理できない一連のリクエストを受信した場合、ARFM はブロンズ・ポリシーに関連付けられたリクエストを最初にキューイングします。なぜなら、ブロンズ・ポリシーの重要度は discretionary であり、ブロンズ・ポリシーのリクエストに対するサービス時間が増加しても、システムの目標達成度の計算には影響しないからです。シルバー・リクエストとゴールド・リクエストの場合には、ARFM は必要なキューイングをそれぞれのリクエストの重要度に応じて分割します。これはつまり、どちらのタイプのリクエストもある程度の時間キューに保持されますが、割合としてはゴールド・リクエストの方がキューに保持される時間は短いということです。高い重要度として 100 という数値を割り当て、中程度の重要度として 50 という数値を割り当てるとすると、ARFM は 100*(ゴールドのキューイング時間)==50*(シルバーのキューイング時間) となるようにキューを操作します。つまり、即座にリクエストを処理するだけの十分なリソースがない場合には、シルバー・リクエストは (平均として) ゴールド・リクエストの 2 倍の時間キューに保持されます。

図 5. サービス・ポリシーの目標を構成する
サービス・ポリシーの目標を構成する

最後に、先ほど説明したように、ARFM の基本的なキャパシティー管理メカニズムは、受信したリクエストをキューイングして遅延させてもサービス目標を達成できるように動作します。これはつまり ARFM にとって、特定クラスのトラフィックにおける通常のサービス時間とサービス目標との間には多少の余裕が必要だと言うことです。ARFM は、割り当てを減らせる (従ってキューイングされる可能性が高くなる) リクエストと、減らせないリクエストを把握する必要があります。アプリケーションによる通常の処理時間に非常に近い値にサービス目標が設定されてしまうと、いずれのトラフィックをキューイングしてもサービス目標に違反してしまうため、ARFM はどのトラフィックをキューに入れればよいか、適切な判断を下すことが困難になります。意味のある形でサービス・レベルの差別化を作成するためには、サービス・ポリシーをある程度緩やかに設定し、バックエンドのサービス時間を考慮しても ARFM がサービス目標に違反せずにリクエストをキューイングできるようにします。その際に複数のサービス・ポリシーを作成しておくと、アプリケーションに対するすべてのリクエストの目標を 1 つだけ設定するのではなく、潜在的なリクエスト・タイプごとに適切な目標を設定できます。


どういう場合に ARFM を使うべきか

ここまで読むと明確に理解できたと思いますが、ARFM は上記のようにトラフィック・パターンの評価およびキャパシティーの管理を行うため、実装を成功させるためには、トラフィックを適切にカテゴリー分けし、またサービス・ポリシーとサービス目標を適切に定義することが重要となります。サービス・ポリシーを適切に定義しないと、ARFM は処理対象のトラフィックの性質や、そうしたトラフィックによってアプリケーション・サーバーにかかる負荷について不正確な予測をたててしまい、アプリケーション・サーバーは過負荷あるいは過小負荷になってしまいます。

妥当なサービス・ポリシー定義でシステムが適切に構成されるまで、ARFM のトラフィック・キューイング機能を無効にすることを検討する必要があります。そのためには disableARFM.py という wsadmin スクリプト (<WAS_HOME>/bin ディレクトリーにあります) を使用して、セル・レベルのカスタム・プロパティー arfmManageCpufalse に設定します。またその逆の enableARFM.py スクリプトもあります。disableARFM.py を実行すると、ARFM はどのような状況でもトラフィックをキューイングしなくなるため、CPU 過負荷検出が暗黙的に無効になることに注意してください。ただしその場合も、アプリケーション配置コントローラーは利用可能なサーバーがあれば必要に応じて追加のキャパシティーをオンラインにします。


まとめ

オートノミック要求フロー・マネージャー (ARFM) はサービス・レベルの差別化を調整するための非常に強力なツールです。ただし、ARFM によって下される判断は必ずしもシステム管理者が直感的に予期する結果とは一致しません。また、意図した結果を得るためには、ARFM の構成を十分注意して適切に行う必要があります。サービス・レベルの差別化を実装するために ARFM を構成する際、念頭に置くべき重要ポイントは以下のとおりです。

ARFM の機能に関して:

  • アプリケーション・サーバーのリソースに対してポリシー間で競合が発生しても、CPU 以外のリソースの競合 (例えばアプリケーション・サーバーのファイル・システムに対する競合など) については管理しません。
  • バックエンド・リソース (データベースなど) に対してポリシー間で競合が発生しても管理しません。

ARFM の構成に関して:

  • 1 つのポリシーの中で、リクエストによってサービス時間が大幅に異なることがないようにする必要があります。
  • 1 つのサービス・ポリシーの中で、リクエストによって CPU 使用率が大きく異なることがないようにする必要があります。

これらの項目を念頭に置き、またリソースに関する判断を下す際に ARFM が用いるアルゴリズムを理解しておくと、優先度の判断が予想と異なって驚かされることなく、適切に WebSphere Virtual Enterprise 環境を構成して、サービス・レベルの差別化を実現することができます。


用語

サービス時間 (Service Time) – アプリケーション・サーバー上でリクエストを処理するために必要な時間です。これはアプリケーション・サーバーにリクエストが到着した時からレスポンスが生成された時までの時間です。この時間には、オンデマンド・ルーターでのキューイング時間は含まれません。

応答時間 (Response Time) – オンデマンド・ルーターにリクエストが送信された時からレスポンスが戻った時までの合計時間です。この時間には オンデマンド・ルーターキューイングされた時間が含まれます。この値はサービス・ポリシーの目標に対して測定される値です。

作業クラス(Work Class) – 各アプリケーションに関連付けられた構成であり、こうした構成によって各リクエストを URI に基づいて特定のトランザクション・クラスに分類します。

トランザクション・クラス (Transaction Class) – 一連の作業クラスをグループとして集め、1 つのサービス・ポリシーに関連付けるためのオブジェクトです。

サービス・ポリシー (Service Policy) – ある 1 つのサービス目標に関連付けられた一連のトランザクション・クラスです。1 つのサービス・ポリシーの中のすべてのトランザクション・クラスは、応答時間と CPU 使用率のパターンが同程度でなければなりません。

サービス目標 (Service Goal) – 特定のサービス・ポリシーに関連付けられた一連のトランザクション・クラスについて、ARFM が目標とする応答時間です。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=500195
ArticleTitle=WebSphere Virtual Enterprise によるサービス・レベルの差別化
publish-date=11042009