レベル: 初級 小川 哲, WebSphere テクニカル・セールス, IBM
2009年 6月 29日 サーバーリソースに応じたオートノミックな流量制御を行うことで混雑時などのマシンの過負荷状態を防止し、リクエストの優先度に応じたサービスレベル管理を実現する方法を紹介します。
はじめに
Webシステムでは混雑時にあわせたサーバーを用意するのが一般的です。それでも、予想を超える負荷が集中し、その結果、サーバーが過負荷状態に陥るということがあります。こうした過負荷に対しては、前段の負荷分散装置で最大の接続数やリクエスト量といった閾値を設定することで、流量を制限する対策が一般的です。
この方法では予め接続数の閾値を決定する必要があるのですが、最大限にリソースを有効活用するためには、リクエスト量を正確に見積もる必要があり、多くの作業量を要します。逆にサーバーリソースを使い果たす事態を避けたいがために、処理できるリクエスト量を少なく設定した結果、実際にはサーバーリソースが無駄になることもあります。
また、混雑時にはサーバーの負荷増大に対する応答時間が悪化に対しては、負荷分散装置では細かいリクエストの選別をできませんので、ユーザーやアプリケーションの重要度にかかわらず同じように応答時間が悪化し、同じ割合でSorryサーバーに割振られてしまい、重要アプリケーションのサービスレベルを維持することができません。
WebSphere Virtual Enterprise (WVE) V6.1で提供されるオンデマンド･ルーター（ODR）を適用すると、サーバーの負荷状況やレスポンス時間をもとにした流量制御が可能になります。これにより混雑時には優先度に応じてリクエストを割り振ったり、サーバー過負荷状況を防止するためにリクエストをキューイングするといったやり方でサーバーリソースを最大限利用するようになります。また、過負荷時に全てのリクエストを同じように待たせるのでなく、種類わけして流量制御することで、優先度の低いリクエストを待たせて、重要度の高いリクエストの優先的に処理することでサービスレベルを維持します。
WVEを利用することで、混雑時にもユーザーに快適に利用いただけるWebシステムを提供することが出来るのです。本文書では、WVEの流量制御の仕組みや具体的な適用方法を紹介します。
WASシステム運用上の課題点
ここでは、現行のWASシステム環境における過負荷状況時についての課題をあげます。
混雑時のサーバーの過負荷状況
現行のWASシステムでは、混雑時のサーバーリソース使用率が高い状態にもかかわらずそれ以上のリクエストを受け付けることによって、過負荷状況となるケースがあります。場合によっては、サーバー処理不能の状態に陥ることがあります。
Webシステム全体として、過負荷状況を起こさせないための一般的な対応策としては、前段の負荷分散装置で流量を制御するという方法があります。ただし、接続数などは事前に閾値を設定する必要があり、最大限にサーバーリソースを使いつつも、過負荷状況に陥らないよう、最大処理量を正確に見積もる事は大変難しい作業となります。例えば、最大処理量を見積もる場合、リクエストによっても重い処理や軽い処理など様々です。そのため、混雑時の想定をして見積もるときに、考えられる最悪の状況で見積もってしまいまうと、実際にはサーバーリソースが空いているにもかかわらず前段の負荷分散で流量制御してリクエストを拒否するといった状況が起こる可能性があります。逆に、見積もりが甘いと、予想より重いリクエストが多く来た場合、リクエスト量は閾値に達してないにもかかわらず過負荷状況となります。
混雑時のサービスレベルの管理
現状は、割り振りを行う負荷分散装置やWebサーバープラグインが、リクエストの種別にかかわらずリクエストを受信した順番に割り振るため、アプリケーションやユーザーごとに優先度をつけたサービスレベルを管理できていません。そのため混雑時には、どのアプリケーションでも均等に応答が遅延してしまいます。
具体的には、Webショッピングサイトで、商品閲覧ユーザーは問題ないのに購入処理ユーザーがSorryに割り振られるといった問題がおきます。このように、お客様への満足度の低下だけでなく販売機会損失に繋がる可能性があると言うことです。
WVE機能を利用した解決策
WVEは、バックエンドのリソース状況およびリクエストの統計情報を随時収集する事で、予め設定した閾値ではなく、動的にリソースが処理できるリクエスト量を算出することで流量制限します。過負荷状況に対しては、処理可能な量だけサーバーに割り振り、その量をリクエストはキューイングし待たせる事でサーバーの過負荷を防止することができます。サービスレベル管理に関しては、優先的に重要度の高いアプリケーションに対するリクエストをサーバーに割り当てることで、混雑時における重要度の高いアプリケーションへの応答遅延を極小化できます。
WVEによる流量制御
解決策の詳細を説明する前に、WVEによる流量制御について紹介します。
トポロジーに関しては「オンデマンド・ルーター（ODR: On-Demand Router）」をインテリジェントなプロキシー・サーバーとして、アプリケーション・サーバーの前段に配置します。そうすることで、クライアントのリクエストは全てODRを経由し、サーバーの稼動状況に応じてアプリケーション・サーバーに割り振られます。
ODRの機能としては、「オートノミック要求フロー・マネージャー（ARFM: Application Request Flow Manager）」と「動的ワークロード管理（DWLM: Dynamic Workload Manager）」の２つがあり、この文書ではARFMを詳しくとりあげます。
ARFMは、リクエストごとに必要なコストとWebシステム全体としての処理可能量を算出します。処理可能量に対してリクエスト量が多い、つまり過負荷状態の時は、リクエストをODR内部にキューイングすることで処理できる量だけをDWLMに割り振ります。また、ARFMは、アプリケーションの重要度（後述のサービス・ポリシーを参照）ごとにキューを分けるため、重要度の高いポリシーのキューから優先的にリクエストを割り振ることが出来ます。
次に、DWLMでは、サーバーの稼動状況やレスポンスタイムなどの負荷状況をもとにサーバーごとに動的に重みを計算しており、ARFMから受け取ったリクエストをこの重みに基づいて割り振りします。
図1. ARFMとDWLM
次に、サービスレベル管理するために、管理者はWVEに対して「サービス・ポリシー」というものを設定します。サービス・ポリシーの設定は、応答時間の目標値と重要度のみの簡単な設定です。また、サービス・ポリシーはアプリケーション毎に選択できるため、業務単位でサービスレベルを設定することができます。さらに、一つのアプリケーション（業務）でも複数のサービス・ポリシーを定義することも可能です。同一のアプリケーションであっても、ユーザー（CookieやIPなどで識別できる場合）によってサービスレベルに差を付けたい場合などに有効です。
デフォルトでは、全てのアプリケーションは、応答時間の目標値や重要度を持たない「任意」というサービス・ポリシーに設定されます。
図2. サービス・ポリシー
このように、ARFMがWebシステム全体としての過負荷防止および、サービス・ポリシーに応じたサービスレベルを管理するように流量制御し、その後DWLMが各サーバーのリソース状況に応じた負荷分散を実施します。
では、課題に対する解決策を紹介します。
サーバー過負荷状況のWVEの挙動
まず、Webシステム全体が過負荷となる状況に対する対応策を紹介します。
ARFMにより、Webシステム全体としてCPU使用率がある閾値（最大CPU使用率）を超えた場合、キューイングもしくはリクエストの破棄を行うことが可能です。このCPU使用率は各マシンのCPU使用率ではなく、リクエスト毎に使用するコスト（各マシンパワーを加味したCPU使用量）を算出する事で、現在使用しているコストが、ディスパッチ先のWebアプリケーション・サーバーのクラスター全体として何%の使用率であるかを算出した値となります。
デフォルトでは、このCPU使用率の閾値が90%で設定されています。そのため、WVEで構成した場合は設定を変更することなく、クラスター全体でCPU使用率が90%を超えると、ODRがリクエストをキューイングし、ある程度待たせる事で、過負荷を防止することができます。
過負荷状況でのサービスレベル管理
上記の過負荷防止のためリクエストをキューイングする時、重要度別にサービス・ポリシーを作成することで、重要度に応じた流量制御も可能です。ARFMは、サービス・ポリシーごとにキューを持ち、それごとにキューイングさせることで、過負荷状況にはサービス・ポリシーの重要度に応じて各キューのリクエストの処理量を調整します。その結果、混雑時でも重要度の低いリクエストを待たせることで、重要度の高いリクエストを優先的に処理することができます。
挙動詳細
過負荷防止の詳細な挙動
過負荷防止するためには、サーバーリソースの情報収集やリクエストの統計情報収集、次にその情報を元に処理可能なリクエスト量の算出、最後に実際に処理量を超えた時のリクエストをキューイングする仕組みが必要となります。
WVEとしては、ワーク・プロファイラー、ゲートウェイ、コントローラーの3つのコンポーネントで過負荷防止を実現します。ワーク・プロファイラーは、リソースやリクエストの情報収集を行い、同時にリクエスト毎のCPU作業量を算出します。コントローラーは、サービス・ポリシーごとに処理可能なリクエスト量の算出を行います。ゲートウェイは、ODR内で稼動し実際にリクエストをキューイングといった過負荷防止の対処を実施します。
ゲートウェイはその性質上必ずODR内で稼動しますが、コントーラーおよびワーク・プロファイラーはセル内のいずれかのプロセスで稼動します。
これらコンポーネントがどう稼動するか、まずはサービス･ポリシーが一つしかない単純な例で解説します。
- ワーク・プロファイラーが、ODRなどから受け取ったリクエスト統計情報およびサーバーのCPU使用率の情報を収集し、リクエストごとの処理に必要なCPU作業量を計算します。
- ARFMコントローラーが、ワークプ・ロファイラーからリクエストごとのCPU作業量を受け取り、サーバーリソースが処理できるリクエスト量を算出します。過負荷防止として、許容できるCPU使用率をCPU過負荷防止の閾値として設定します。デフォルトでは90%が設定されており、全サーバーリソースの平均CPU使用率が最大90%になるようにリクエスト量を制限します。
- ARFMゲートウェイでは、ODRが受け取ったリクエストの流量を2で算出されたリクエスト量で制限します。ODRは、それ以上のリクエストを受け付けた場合、ゲートウェイのキューで待たせることによって、CPU使用率が90%を超えないように調整します。
図3. キューイングとARFM
次に、サービス・ポリシーが複数ある場合（キューが複数）における、過負荷防止時の挙動を説明します。
- ワーク・プロファイラーが、リクエスト統計情報によりリクエストごとの処理に必要なCPU作業量を計算します。
- サービス・ポリシーが一つの場合と同様、ARFMコントローラーは、リクエスト全体の処理に必要とされるCPU作業量が過負荷防止の閾値を超えないようにリクエスト量を算出します。複数の場合は、現在のリクエスト量やサービス・ポリシーの設定に応じて、サービス・ポリシーごとにリクエスト量の閾値が割り当てられます。
- ARFMゲートウェイでは、ODRで受け取ったリクエストをサービス・ポリシーごとのキューに割り振り、サービス・ポリシーごとに2で算出したリクエスト量の閾値で制限します。閾値を超えたリクエストがきた場合、サービス・ポリシーごとにキューイングします。
サービス・ポリシーの作成指針
最初に、サービス・ポリシーの種類について説明します。
サービス・ポリシーには応答時間目標と任意の2つがあり、このポリシーをベースに流量制御され、ポリシーの種類が割り振り可能なリクエスト量の割り当てに影響します。
- 応答時間目標ポリシーは、応答時間目標と7段階の重要度で設定します。過負荷状況では、応答時間目標を守るようにリクエスト量の閾値が割り当てられます。過負荷状況が悪化し、応答時間目標が守れない場合は、重要度が高いサービス・ポリシーのキューに対してより割振り可能なリクエスト量が割り当てられます。過負荷状況でも全ての応答時間目標が守れる場合は、重要度は関係ありません。
- 任意のポリシーでは、応答時間目標がないため、応答時間目標が無制限のサービス・ポリシー（一番優先度が低いサービス・ポリシー）となります。デフォルトでは、全てのアプリケーションがこの「任意」のポリシーに設定されます。過負荷防止のみを実施したい場合は（アプリケーションごとのサービスレベル管理は必要なし）、デフォルトのままで新たにサービス・ポリシーを作成する必要はありません。
次に、混雑時のサービスレベル管理を実施するための新たなサービス・ポリシーを作成する手順について説明します。サービス・ポリシー作成する前に準備として、「アプリケーションの重要度分け」と応答時間目標設定のための「サービス時間の測定」が必要となります、その後、実際に応答時間目標設定しサービス・ポリシーを作成します。
この作業でポイントとなるのが、重要度の高いアプリケーションのサービスレベル維持のため、その他のアプリケーションをどれだけ切り捨てられるか、つまり、重要度の低いアプリケーションをどれだけ長い時間・どれだけ多くのリクエストを待たせることが出来るかというものです。例えば、重要度の低いアプリケーションが多ければ多くのリクエストを待たせる事で、限りあるサーバーの処理性能を重要度の高いリクエストを優先して利用でき、より効果がでます。
このポイントを踏まえて、手順を説明します。
- アプリケーションの重要度分け
- 重要度が低く、応答時間目標を必要としないアプリケーションについては、「任意」ポリシーを適用します。そのため、2の応答時間検証をする必要はありません。
- 「任意」以外のアプリケーションの重要度分けをします。
- 重要度分けの一つの方法として、最初は重要度の高いアプリケーションを「重要度最高」とし、残りのアプリケーションを「任意」や「重要度最低」といったように重要度に大きく差をつけて設定します。そこを出発点とし、必要に応じて新たに重要度分けします。例えば、最重要ではないが有る程度重要なアプリケーションに対しては、「重要度中」に分類します。
- 後続の節の「サービス・ポリシーの組み合わせの流量制御の挙動」も参考に設定してください。
- アプリケーションのサービス時間測定
- 応答時間目標は、サービス時間（実際のサーバーの処理時間）にODRで許容できる待ち時間を足したものを設定します。
- 注意としては、サーバーの負荷状況にサービス時間は変わりますが、通常時のサービス時間でなく、キューイングが発生している負荷状況下、「CPU過負荷防止の最大CPU使用率」に設定したCPUを使用している時のサービス時間を基準とします。応答時間目標とは、過負荷防止のためODRがキューイングした際、リクエストがODRでどれだけ待たせることが可能かといった指標となりますので、過負荷防止の発生する負荷状況時のサービス時間を基準にして設定していきます。
- 基準となるサービス時間を測定する必要があります。そのためにはIHSのログを用いるなど面倒な作業が発生しますが、WVE機能でサービス時間計測することも出来ますので、活用方法を紹介します。
- アプリケーションごとにサービス・ポリシーを任意で作成し、実際に最大CPU使用率の負荷をかけることで、基準となるサービス・タイムを以下の2つの方法で確認することが出来ます。注意として、明らかに応答時間の異なるURLは1リクエストあたりのCPU作業量も大きく異なるため、別のサービス・ポリシーを作成し計測します
- ランタイム操作⇒レポート画面で、作成したサービス・ポリシーの「平均サービス時間」を表示（図4を参照）
図4. レポートするデータの追加設定
- 可視化データ・サービスのログを使用可能な状態で、「TCModuleStatsCache.log」の「servicetm」（集計時間中の全リクエストの延べサービス時間）から「serviced」（集計時間中のリクエストの処理量）を割ることで、平均のサービス時間を算出することが出来ます。
- サービス・ポリシーの作成
- まず、応答時間目標を設定しなくてもよいような重要度の低いアプリケーションは「任意」のサービス・ポリシーで設定します。
- 1で設定した重要度と応答時間目標の組み合わせでサービス・ポリシーを作成します。応答時間目標は、2で測定した基準のサービス時間に、許容できる待ち時間を足した値を設定します。
例えば、重要度の高いアプリケーションでは、優先的に処理させるため応答時間目標を基準のサービス時間と同じに設定します。そうすることで、待ち時間を短くすることができます。重要度の低いアプリケーションは待ち時間を長くするように応答時間目標を設定します。
この待ち時間をどれだけ長く設定するのかがキーポイントとなります。重要度の低いアプリケーションの待ち時間を長くすることで、より負荷が高い状況でも重要度の高いアプリケーションを優先的に処理しサービスレベルを維持することが可能となります。
 |
サービス・ポリシーの組み合わせの流量制御の挙動
過負荷状況の場合、ポリシーの種類によってどういったキューイングおよび流量制御の挙動になるのかを特に組み合わせたときの挙動を中心に説明します。重要度の設定する上での参考にしてください。
「任意」のみ（デフォルト）
過負荷防止の閾値で設定された値のCPU使用率で処理できるリクエスト量を守るように、キューイングし全てのリクエストが待たせます。
「応答時間目標設定/重要度最高」のみ
「任意」のみのケースと同様の挙動となります。応答時間目標を設定し重要度は最高であっても、全てのリクエストが同じポリシーのため同じようにキューイングし待たせます。
「応答時間目標設定/重要度最高」(SP1)と「任意」(SP2)
SP1の応答時間目標が守れる場合は、全てのリクエストを同等にキューイングし待たせます。より負荷が増大し、SP1の応答時間目標を守れないと予測されると、SP2をよりキューイングして待たせるようにSP2のリクエスト量の割合を少なくし、SP1の応答時間目標を達成するように流量制御します。
「応答時間目標設定/重要度最高」(SP1)と「応答時間目標設定/重要度最低」(SP2)
SP1とSP2の応答時間目標が守れる場合は、全てのリクエストを同等にキューイングし待たせます。どちらか一方のサービス・ポリシーの応答時間目標が守れないと予測すると、他のサービス・ポリシーの応答時間目標を守れる限りキューイングし待たせます。重要度の違いによる影響は、SP1・SP2どちらも応答時間目標を守れなくなってから出てきます。重要度の高いSP1の応答時間目標が守れるように、SP2はより待ち時間を長くするように流量制御します。重要度の低いSP2リクエスト量の割合を少なくし流量制御します。
「応答時間目標設定/重要度最高」(SP1)と「応答時間目標設定/重要度非常に高い」(SP2)
一つ前のサービス・ポリシーの組み合わせ（「最高」＆「最低」）と違うのは、SP2の重要度の違いです。重要度には7段階あり、「最高、非常に高い、高い、中、低い、非常に低い、最低」という順番で設定可能です。重要度の違いによる影響が出るのは、SP1・SP2どちらも応答時間目標を守れなくなってからですので、それ以外の状況では前のサービス・ポリシーの組み合わせと同じ挙動となります。どちらも応答時間目標が守れない場合は、前と同様に重要度の高いSP1の応答時間目標が守れるようにSP2はより待ち時間を長くするように流量制御しますが、SP2に対しては重要度が「最低」のときよりも応答時間目標を守るように流量制御します。結果、前の組み合わせの時よりも、SP1は待ち時間は長くなりSP2の待ち時間が短くなるように、リクエスト量の割合を調整されて、流量制御します。
キューの確認方法
過負荷状況では、ODRがサービス・ポリシーごとにリクエストをキューイングします。適切なポリシー設定のためには、このキュー長やキュー待ち時間の解析が重要となります。
そのキュー長（キューイングされたリクエスト数）やキューの平均の待ち時間の確認方法を紹介します。Webの管理コンソール上でグラフ化したもので確認する方法と可視化データ・サービスのログで集計時間ごとのログで確認する方法、およびdumpOdrState.jaclスクリプトで確認する方法があります。ただし、dumpOdrState.jaclスクリプトは、ODRの詳細な情報も多く出力しますので通常時ではなくデバッグ時に使用するコマンドとなります。
Webの管理コンソール
可視化データ・サービスのログ
平均の待ち時間については、「TCModuleStatsCache.log」の「waittm」（集計時間中の全リクエストの延べ待ち時間）から「serviced」（集計時間中の全リクエストの処理量）を割ることで、平均の待ち時間を算出することが出来ます。キュー長については、「TCModuleStatsCache.log」の「currentLen」の項目で、その時のキューに保持しているリクエスト数を確認することが出来ます。
dumpOdrState.jaclスクリプト
スクリプト実行時のキュー長を確認できます。該当のサービス・ポリシーの「queued=」に続く値で確認することが出来ます（表1ではqueued=23がキュー長となります）。
dumpOdrState.jaclスクリプト出力結果抜粋
SilverSP . Dispatcher state = {state=33, weight=49, fraAlloc=21.25, execLimit=21.25,
concAllocInt=0.0, limitPower=false, workFactor=1.0, maxPowerFactor=1.0,
nomPowerFactor=1.0, svcTime=0.18140364}
For class SilverSP: throttle state = wide open
Dialog admission throttle state = wide open
alloc=319054720, usage=50, heapValue=319054670, queued=23, lengthLimit=1000,
followupLengthLimit=1000 |
まとめ
この章では、WVEの流量制御を利用したWebシステムの過負荷状況の防止方法、および過負荷状況でのサービスレベル管理の方法を紹介してきました。この流量制御によって、過負荷状況を防止することでサーバーのCPUリソースを使い果たすことを防ぎ、なおかつ重要なアプリケーションに対しては応答時間目標を守るようにサービスレベル管理を実施することができます。
既存環境の過負荷状況や新規環境のピーク時の対応として、WVEを利用する事でサーバーを最大限に利用しつつ、サービスレベルを維持し、混雑時にもユーザーが快適に利用できるWebシステムを提供することが可能となります。是非、WebシステムへのWVE利用をご検討ください。
著者について | | | 小川 哲,WebSphere テクニカル・セールス,IBM |
記事の評価
| 
