(57)【要約】【課題】サーバによるサービスの提供を停止させることなく、リクエストによるサーバへの負荷を調整し、定常化させる。【解決手段】サーバ２に送信されてくるリクエストを、一時的にキュー４に蓄え、キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は擬似クライアント５により発生するリクエストを、順次所定のタイミングでサーバに転送することにより、リクエストによるサーバへの負荷を調整する。その際、所定のタイミングとして、サーバに転送するリクエストが一定の到着時間間隔分布でサーバに到着するようなタイミングを採用する。また、このようなタイミングを、乱数発生器６により所定の確率分布で発生する乱数に基づいて決定する。【選択図】      図１
2004348491.tif 000002
【特許請求の範囲】
【請求項１】
リクエストによるサーバへの負荷を調整するリクエスト負荷調整装置であって、
前記サーバに送信されてくるリクエストに対し、擬似的なリクエストを加えることにより前記負荷の調整を行う負荷調整手段を具備することを特徴とするリクエスト負荷調整装置。
【請求項２】
前記負荷調整手段は、前記サーバに送信されてくるリクエストに対して擬似的なリクエストを加えながら、各リクエストを一定の到着時間間隔分布で到着するようなタイミングで前記サーバに転送するものであることを特徴とする請求項１に記載のリクエスト負荷調整装置。
【請求項３】
前記負荷調整手段は、リクエストの種類毎に、前記擬似的なリクエストの追加を行い、異なる前記到着時間間隔分布となるタイミングで前記転送を行うものであることを特徴とする請求項２に記載のリクエスト負荷調整装置。
【請求項４】
前記負荷調整手段は、
前記サーバに送信されてくるリクエストを一時的に蓄えるキューと、
擬似的にリクエストを発生するリクエスト発生手段と、
前記キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は前記リクエスト発生手段が発生するリクエストを、順次所定のタイミングで前記サーバに転送する転送手段とを有することを特徴とする請求項１に記載のリクエスト負荷調整装置。
【請求項５】
前記所定のタイミングは、前記サーバに転送するリクエストが一定の到着時間間隔分布で前記サーバに到着するようなタイミングであることを特徴とする請求項４に記載のリクエスト負荷調整装置。
【請求項６】
所定の確率分布に従った乱数を発生する乱数発生手段を備え、前記転送手段は前記所定のタイミングを、前記乱数に基づいて決定するものであることを特徴とする請求項４に記載のリクエスト負荷調整装置。
【請求項７】
前記負荷調整手段は、
前記サーバに送信されてくるリクエストをその種類に応じた分類毎に一時的に蓄える複数のリクエスト・キューと、
前記サーバに送信されてくるリクエストを種類に応じて対応する各リクエスト・キューに配分するディスパッチャと、
要求された種類のリクエストを擬似的に発生するリクエスト発生手段と、
各リクエスト・キューに対応させて設けられた転送手段とを備え、
各転送手段は、独自の所定のタイミングで、対応するリクエスト・キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は前記リクエスト発生手段に要求して発生させる該リクエスト・キューに対応する種類のリクエストを、順次前記サーバに転送するものであることを特徴とする請求項１に記載のリクエスト負荷調整装置。
【請求項８】
前記リクエスト発生手段は、セッション情報を含むことが必要な種類のリクエストについては、予め前記サーバにリクエストを転送することによって取得したセッション情報を含むものとして、そのリクエストを発生するものであることを特徴とする請求項７に記載のリクエスト負荷調整装置。
【請求項９】
前記リクエスト発生手段は、とり得る各状態において対応する種類のリクエストを発生するスレッドを、各状態毎に蓄積する複数のスレッド・キューを備え、各スレッドはリクエストを前記サーバに転送することによって取得したセッション情報を保持し、該セッション情報を含むリクエストを発信することができるものであることを特徴とする請求項７に記載のリクエスト負荷調整装置。
【請求項１０】
コンピュータを、請求項１〜９のいずれかのリクエスト負荷調整装置における各手段として機能させることを特徴とするプログラム。
【請求項１１】
リクエストによるサーバへの負荷をコンピュータにより調整するリクエスト負荷調整方法であって、
前記コンピュータが、前記サーバに送信されてくるリクエストに対し、擬似的なリクエストを加えることにより前記負荷の調整を行う負荷調整手順を具備することを特徴とするリクエスト負荷調整方法。
【請求項１２】
前記負荷調整手順では、前記コンピュータが、前記サーバに送信されてくるリクエストに対して擬似的なリクエストを加えながら、各リクエストを一定の到着時間間隔分布で到着するようなタイミングで前記サーバに転送することを特徴とする請求項１１に記載のリクエスト負荷調整方法。
【請求項１３】
前記負荷調整手順では、前記コンピュータが、リクエストの種類毎に、前記擬似的なリクエストの追加を行い、異なる前記到着時間間隔分布となるタイミングで前記転送を行うことを特徴とする請求項１２に記載のリクエスト負荷調整方法。
【請求項１４】
前記負荷調整手順は、
前記コンピュータが、前記サーバに送信されてくるリクエストを一時的にキューに蓄える手順と、
前記コンピュータが、擬似的にリクエストを発生するリクエスト発生手順と、
前記コンピュータが、前記キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は前記リクエスト発生手順により発生するリクエストを、順次所定のタイミングで前記サーバに転送する転送手順とを有することを特徴とする請求項１２に記載のリクエスト負荷調整方法。
【請求項１５】
前記所定のタイミングは、前記サーバに転送するリクエストが一定の到着時間間隔分布で前記サーバに到着するようなタイミングであることを特徴とする請求項１４に記載のリクエスト負荷調整方法。
【請求項１６】
前記コンピュータが所定の確率分布に従った乱数を発生する乱数発生手順を備え、前記転送手順では前記コンピュータが、前記所定のタイミングを、前記乱数に基づいて決定することを特徴とする請求項１４に記載のリクエスト負荷調整方法。
【請求項１７】
前記負荷調整手順は、
前記コンピュータが、前記サーバに送信されてくるリクエストをその種類に応じた分類毎に一時的に複数のリクエスト・キューに蓄える手順と、
前記コンピュータが、前記サーバに送信されてくるリクエストを種類に応じて各リクエスト・キューに配分する手順と、
前記コンピュータが、要求された種類のリクエストを擬似的に発生するリクエスト発生手順と、
前記コンピュータが、各リクエスト・キュー毎に異なる所定のタイミングで、各リクエスト・キュー毎に、リクエスト・キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は前記リクエスト発生手順により発生させる対応する種類のリクエストを、順次前記サーバに転送する手順とを有することを特徴とする請求項１１に記載のリクエスト負荷調整方法。
【請求項１８】
前記リクエスト発生手順では、前記コンピュータが、セッション情報を含むことが必要な種類のリクエストについては、予め前記サーバにリクエストを転送することによって取得したセッション情報を含むものとして、そのリクエストを発生することを特徴とする請求項１７に記載のリクエスト負荷調整方法。
【請求項１９】
前記リクエスト発生手順は、前記コンピュータが、とり得る各状態において対応する種類のリクエストを発生するスレッドを、複数のスレッド・キューに対し各状態毎に蓄積する手順を備え、前記リクエスト発生手順では、前記コンピュータが、各スレッドにより、リクエストを前記サーバに転送することによって取得したセッション情報を保持し、該セッション情報を含むリクエストを発信することを特徴とする請求項１７に記載のリクエスト負荷調整方法。
【請求項２０】
請求項１〜９のいずれかのリクエスト負荷調整装置又は請求項１１〜１９のリクエスト負荷調整方法により、リクエストによるサーバへの負荷を調整しながら、前記サーバの性能に関するデータを収集することを特徴とする性能データ収集方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、リクエストによるサーバへの負荷を調整するリクエスト負荷調整装置及び方法、プログラム、並びに、リクエスト負荷調整装置又は方法によってサーバに対し一定の負荷を与えながらサーバの性能に関するデータを収集する性能データ収集方法に関する。
【０００２】
【従来の技術】
Ｗｅｂサーバ等が提供するオンライン・サービスの性能を予測的に評価する技術は、人手によらない自己構成、自己最適化等を目指す自律型コンピューティングの実現や、Ｗｅｂサイトのパフォーマンスを向上させるパフォーマンス・サービス等において必要とされる基本技術である。システムモデルに基づく性能評価を行うためには、図６に示すように、対象となるシステムのモデルを作成し（ステップ６１）、システムの性能を測定し（ステップ６２）、測定データに基づいてモデルにおけるパラメータを推定し（ステップ６３）、そして、完成したモデルを待ち行列やシミュレータにより解析する（ステップ６４）、という手順を踏む。
【０００３】
従来、Ｗｅｂサーバについて、上述の手順におけるような最適なパラメータを見出すサービスが実施されているが、実施に際しては、対象となるＷｅｂアプリケーションが実装された実機を用い、サーバ・ソフトウェアの主要なパラメータを変えながら、負荷試験により性能を実測し、その結果に基づいて経験則により最適なパラメータを見つけるようにしている。
【０００４】
Ｗｅｂサーバに対する負荷試験を行う技術としては、たとえば、試験対象のＷｅｂサーバに対し、これをテストするためのテスト用サーバを接続し、テスト用サーバが異なるポート番号による偽装した多数のセッションを発生させてＨＴＴＰリクエスト及びＨＴＴＰレスポンスの送受をＷｅｂサーバとの間で行うようにしたものが知られている（たとえば特許文献１参照）。この技術においては、レスポンス中にリクエストによって指定したオブジェクトが誤りなく含まれていることや、リクエスト／レスポンスに要する応答時間等の性能が実測される。その際、ＣＧＩに与えるための引数等のパラメータを動的に変化させることも可能であるとしている。
【０００５】
一方、待ち行列解析や、シミュレーションによるモデルの解析によって、実機を使わずに最適なシステム構成やサーバのパラメータを決定する手法も実用化されつつある。ただしこの場合でも、Ｗｅｂアプリケーションの中身はＪａｖａ（登録商標）によるプログラムであり、顧客毎に内容も異なるため、パラメータの推定を行い、モデルを完成させるためには、少なくとも一度は実機で測定する必要がある。
【０００６】
【特許文献１】
特開２００２−７２３２号公報（段落００３５〜００３８）
【０００７】
【発明が解決しようとする課題】
上述従来技術によれば、Ｗｅｂアプリケーション開発の最終段階で負荷試験を行い、十分な測定データを収集できる場合や、システムが稼動中であってもステージング・サーバ等の余分な実機があるようなテスト環境下での負荷試験により測定データの収集ができる場合には何ら問題はない。ところが、Ｗｅｂアプリケーションの開発に際しては、開発期間が短く、十分な負荷試験を実施せずにアプリケーションのデバッグのための動作確認だけでカット・オーバしてしまう場合が多い。また、ステージング・サーバやバックアップ用サーバ等を用意しているのはごく限られた顧客だけであり、多くの場合は、実稼動中のサーバを開発機として使用し、そのまま実稼動に移行するため、余分な実機を有していない。したがって、十分な負荷試験を実現させるのは難しいのが現状である。このため、システムにおけるパフォーマンス上の問題が運用中に顕在化したときに初めてサービスの依頼を受けることになる。しかしながら、稼動中のシステムを負荷試験のために長時間停止することは、機会損失につながるので、顧客としてはできるだけ避けたいのは言うまでもない。
【０００８】
考えられる最も理想的な解決方法としては、実稼働しているシステムの応答時間、資源使用率等の性能データを収集し、そのデータに基づき、解析のためのモデルのパラメータを推定することが考えられる。しかし、実稼働しているＷｅｂサーバへのリクエスト量は、一般に、単位時間当りの到着数の分布がかなり複雑で、平均到着数自体が時間的に変動し、かつ種々のリクエストの混合比も時間的に変動するという性質を有する。このような状態にあるシステムの性能データを収集しても、現在の解析技術をもってしてはモデルに関するパラメータの推定にはほとんど役に立たない。
【０００９】
本発明の目的は、かかる従来技術の問題点に鑑み、サーバによるサービスを停止させることなく、リクエストによるサーバへの負荷を調整することができる技術を提供することにある。また、サーバによるサービスを停止させることなく、通常の負荷試験の場合と同等の定常的な負荷をサーバに印可することができる技術を提供することにある。
【００１０】
【課題を解決するための手段】
この目的を達成するため、本発明に係るリクエスト負荷調整装置及び方法は、サーバに送信されてくるリクエストに対し、擬似的なリクエストを加えることによって、リクエストによるサーバへの負荷を調整するようにしたことを特徴とする。また、本発明に係るプログラムは、コンピュータを、本発明に係るリクエスト負荷調整装置として機能させ、あるいはコンピュータに、本発明に係るリクエスト負荷調整方法を実行させることを特徴とする。また、本発明に係る性能データ収集方法は、本発明に係るリクエスト負荷調整装置又はリクエスト負荷調整方法により、リクエストによるサーバへの負荷を調整しながら、サーバの性能に関するデータを収集することを特徴とする。
【００１１】
ここで、サーバとは、各種リクエストに応じ、対応するサービスを提供するシステムやコンピュータを意味する。サーバとしては、たとえばＷｅｂサーバが該当する。リクエストとはサーバに対してサービスを要求するためのコマンドやメッセージを意味する。
【００１２】
本発明によれば、サーバに送信されてくる本来のリクエストに対し、擬似的なリクエストを加えることにより負荷の調整を行うようにしているため、サーバは本来のリクエストについての処理を行い、通常の場合と同様に稼働しながら、擬似的なリクエストにも応じることにより負荷が調整されることになる。その際、加える擬似的なリクエストの量を調整することにより、変動のない一定量の負荷をサーバに対して与えることができる。したがって、通常の稼働を停止させることなく、一定の負荷を与えながら、サーバの性能に関するデータを取得することができる。
【００１３】
本発明の好ましい態様においては、サーバに送信されてくる本来のリクエストに対して擬似的なリクエストを加えながら、各リクエストを一定の到着時間間隔分布で到着するようなタイミングでサーバに転送する。擬似的なリクエストの追加を加減して行えば、本来のリクエストの到着を遅延させることなく、一定の到着時間間隔分布を維持することができる。これによれば、リクエストの到着時間間隔分布が一定であるため、サーバに対して、定常的な負荷を与えることができる。到着時間間隔分布としてはたとえばポアソン分布を用いることができる。
【００１４】
この場合、擬似的なリクエストの追加をリクエストの種類毎に行い、かつリクエストの種類毎に独自の到着時間間隔分布となるタイミングでサーバへの転送を行うようにしてもよい。これによれば、リクエストの種類毎に負荷の調整を行うことができる。
【００１５】
本発明の他の態様においては、サーバに送信されてくるリクエストを一時的にキューに蓄え、キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は擬似的に発生するリクエストを、順次所定のタイミングでサーバに転送することにより、リクエストによるサーバへの負荷を調整するようにしている。これにより、簡単な構成で、サーバに送信されてくる本来のリクエストに対し、擬似リクエストを追加して、サーバの負荷を調整することができる。
【００１６】
この場合、所定のタイミングとして、サーバに転送するリクエストが一定の到着時間間隔分布でサーバに到着するようなタイミングを採用することができる。このようなタイミングは、たとえば所定の確率分布に従って発生される乱数に基づいて決定することができる。
【００１７】
本発明の別の態様においては、サーバに送信されてくるリクエストを種類に応じて配分し、種類に応じた分類毎に一時的に複数のリクエスト・キューに蓄え、各リクエスト・キュー毎に別個のタイミングで、各リクエスト・キュー毎に、リクエスト・キュー内にリクエストが存在する場合はそのリクエストを、存在しない場合は擬似的に発生させる対応する種類のリクエストを、順次サーバに転送することにより、リクエストによるサーバへの負荷を調整するようにしている。
【００１８】
この場合、擬似的にリクエストを発生させるとき、セッション情報を含むことが必要な種類のリクエストについては、予めサーバにリクエストを転送することによって取得したセッション情報を含むものとして、そのリクエストを発生することができる。これにより、セッション情報を必要とするリクエストについても支障なく個別に負荷の調整を行うことができる。
【００１９】
セッション情報を含む擬似的リクエストの発生は、たとえば、とり得る各状態において対応する種類のリクエストを発生するスレッドを、複数のスレッド・キューに対し各状態毎に蓄積するとともに、各スレッドにより、リクエストをサーバに転送することによって取得したセッション情報を保持し、該セッション情報を含むリクエストを発信するようにすることによって、行うことができる。
【００２０】
【発明の実施の形態】
図１は、本発明の一実施形態に係る負荷調整フィルタのモジュール構成を示すブロック図である。同図に示すように、この負荷調整フィルタ１はＷｅｂサーバ２と、インターネット３との間に設けられる。負荷調整フィルタ１はＷｅｂサーバ２の性能に関するデータを収集する際に、インターネット３を介してＷｅｂサーバ２に送信されてくるリクエストに対し、擬似的なリクエストを加えることにより、リクエストによるＷｅｂサーバ２への負荷を調整するものである。
【００２１】
負荷調整フィルタ１は、インターネット３を介してサーバ２に送られてくるリクエストを受信し、一時的に蓄える受信キュー４、擬似的なリクエストを発生させる擬似クライアント５、乱数発生器６、及び、乱数発生器６が発生する乱数に応じたタイミングでキュー４又は擬似クライアント５のリクエストをＷｅｂサーバ２へ送るゲート７を備える。
【００２２】
擬似クライアント５はゲート７からの要求に応じてリクエストを生成するものである。乱数発生器６は与えられた確率分布に従う乱数を、ゲート７からの要求に応じて発生するものである。乱数発生器６として、モンテカルロ・シミュレーション等で使用するサンプリング・アルゴリズムを利用したものを用いれば、ほぼ任意の確率分布に従った乱数を発生させることが可能である。各モジュール４〜７はソフトウェアとハードウェアとが協働したものとして構成することができる。
【００２３】
図２は負荷調整フィルタ１のハードウェア構成を示す。同図に示すように、ハードウェア構成としては、プログラムに基づきデータ処理や各部の制御を行うＣＰＵ２１、プログラムやデータを記憶するためのメモリ２２、操作入力を行うための入力手段２３、ＣＰＵ２１によるデータ処理結果等に基づく表示を行い、ＧＵＩ（グラフィック・ユーザ・インタフェース）として機能する表示装置２４、Ｗｅｂサーバ２との間の通信やインターネット３を介した通信を行うための通信インタフェース２５、これらの各要素間を接続するバス２６等を備える。メモリ２２はＲＯＭ、ＲＡＭ、ハードディスク等で構成され、ＯＳ、及び各種アプリケーション・プログラムを格納する。アプリケーション・プログラムには、かかるハードウェア構成を負荷調整フィルタ１として機能させるものが含まれる。
【００２４】
Ｗｅｂサーバ２におけるシステムモデルについて性能評価を行うためには、図６に示すように、対象となるシステムモデルを作成し（ステップ６１）、システムの性能を測定し（ステップ６２）、測定データに基づいてモデルにおけるパラメータを推定し（ステップ６３）、完成したモデルを待ち行列やシミュレータにより解析する（ステップ６４）という手順を踏むが、負荷調整フィルタ１はこの手順のうちの、システムモデルのパラメータを決定するためのシステム性能測定（ステップ６２）に際し、システムモデルに対し、理想的な負荷を与える機能を果すものである。
【００２５】
システム性能測定時の理想的な負荷とは、定常的な負荷、つまり単位時間当たりのリクエスト到着数の分布が一定の負荷である。負荷が定常的であるためにはリクエストの到着間隔の時間分布が一定であればよい。たとえば、待ち行列解析でしばしば想定されるポアソン到着は、到着時間間隔分布を指数分布とすることによって得ることができる。ポアソン到着は解析が最も簡単であるが、他の分布であっても定常であれば、解析あるいは人工的に再現が可能である場合も多い。このため、本実施形態では、リクエストの到着時間間隔分布が一定であるという条件を満たせば具体的な分布の形状は問わないこととしている。
【００２６】
図３はゲート７による負荷調整処理の手順を示すフローチャートである。乱数発生器６は、以下の処理によってＷｅｂサーバ２に到着するリクエストの到着分布が一定の所望の分布となるようにパラメータが予め設定されている。負荷調整処理を開始すると、ゲート７は、まず、ステップ３１において、乱数発生器６より乱数を取得する。次に、ステップ３２において、取得した乱数に対応する時間待機する。
【００２７】
その後、ステップ３３において、キュー４を調べ、リクエストが存在するか否かを判定する。リクエストが存在すると判定した場合はステップ３４においてそのリクエストをＷｅｂサーバ２へ送信し、ステップ３７へ進む。リクエストが存在しないと判定した場合はステップ３５において擬似クライアント５からリクエストを取得し、ステップ３６において、取得したリクエストをＷｅｂサーバ２へ送信し、ステップ３７へ進む。
【００２８】
ステップ３７では、負荷調整期間やＷｅｂサーバ２についての負荷試験期間が終了したこと等に基づいて負荷調整処理を終了するか否かを判定する。終了しないと判定した場合はステップ３１へ戻り、以上の処理を繰り返す。終了すると判定した場合は、負荷調整処理を終了する。
【００２９】
ゲート７はこのようにして、乱数発生器４に乱数を要求し、乱数に対応する時間が経過した後に、インターネット３を介して送られてくるリクエストがキュー４にあればそれをＷｅｂサーバ２に転送し、なければ擬似クライアント５に要求して得たリクエストをＷｅｂサーバ２へ転送するという処理を繰り返す。
【００３０】
これによれば、インターネット３からのリクエストがない場合には、代わりに擬似クライアント５からのリクエストが供給されるので、ゲート７が開くタイミングで必ずリクエストをＷｅｂサーバ２に送信することができる。したがって、乱数発生器４に与えた確率分布による乱数に対応する到着時間間隔分布に従う負荷をＷｅｂサーバ２に与えることができる。
【００３１】
インターネット３を介して送信されてくるリクエストの到着率は時間的に変動しているので、負荷調整フィルタ１を介することなく直接的に通常稼働中のＷｅｂサーバ２へリクエストを付与する場合の負荷については、定常とみなせるのはごく短時間だけである。これに対し、本実施形態によれば、負荷調整フィルタ１によってＷｅｂサーバ２に到着するリクエストの到着時間間隔分布が一定になるように調整されるため、負荷調整処理を行っている期間中、継続的に、定常的な負荷をＷｅｂサーバ２に付与することができる。
【００３２】
その際、インターネット３からのリクエストは棄却することなくすべて受け入れるので、その平均到着率を下回るような到着率による負荷を付与することはできないが、負荷調整処理を行う期間における最大到着率時の負荷量を上回るものであれば、任意の負荷量を、乱数発生器６のパラメータを調整することによって設定することができる。実際問題として、常に高負荷が印加されるＷｅｂサイトは珍しく、明け方等のような１日のある時間帯にはリクエスト数もかなり減り、平均資源使用率が数％となる場合がほとんどであるから、そのような時間帯に負荷調整処理を実施すれば、設定できる負荷の自由度は大きい。
【００３３】
したがって、本実施形態によれば、インターネット３からのリクエストに対する処理を中断することなく、所望の定常負荷を印加した状態において、Ｗｅｂサーバ２のシステムモデルに関する性能データを収集する負荷試験を行うことができる。
【００３４】
図４は本発明の他の実施形態を示す。リクエストの種類としては一般に複数のものが存在するので、各種類のリクエストによる各ハードウェア資源の使用量を推定するには、各種リクエストの平均到着率やリクエストの混合比を変化させながら複数回の測定を行い、性能データを取得する必要がある。実際に従来の通常の負荷試験により性能データを収集する場合は、各種リクエストによる負荷の混合比を変化させながら、何種類かの性能データを収集するようにしている。そこで本実施形態では、同図に示すように、各種リクエスト毎に負荷調整フィルタ４１ａ〜４１ｄを設け、各種リクエストの到着時間間隔を独立に調整できるようにしている。
【００３５】
すなわち、インターネットからのリクエストは、ネットワーク・ディスパッチャ４２により、各種リクエストにそれぞれ対応する各負荷調整フィルタ４１ａ〜４１ｄに振り分けて、各負荷調整フィルタ４１ａ〜４１ｄ毎のタイミングでＷｅｂサーバ４０に転送するようにしている。各負荷調整フィルタ４１ａ〜４１ｄは各種リクエストの供給を行うことができるように拡張された１つの擬似クライアント４３を共有しており、対応する種類のリクエストを必要に応じて取得することができる。これにより、各種リクエストの混合比が調整可能となっている。
【００３６】
図５は負荷調整フィルタ４１ａ〜４１ｄの構成を示す。各負荷調整フィルタ４１ａ〜４１ｄは、インターネットを介してＷｅｂサーバ４０に送られてくるリクエストのうち、自身に対応する種類のものを、ディスパッチャ４２を介して受信し、一時的に蓄える受信キュー５１、キュー５１が蓄えるリクエストの種類に対応した確率分布による乱数を発生するように設定される乱数発生器５２、及び、乱数発生器５２が発生する乱数に応じたタイミングでキュー５１又は擬似クライアント４３のリクエストをＷｅｂサーバ４０へ送るゲート５３を備える。キュー５１、乱数発生器５２、及びゲート５３は図１の負荷調整フィルタ１におけるキュー４、乱数発生器６及びゲート７と同様の構成を有する。
【００３７】
各負荷調整フィルタ４１ａ〜４１ｄのゲート５３は、各種リクエストの供給を行うことができるように拡張された１つの擬似クライアント４３を共有しているが、このような構成を採用したのは、Ｗｅｂサーバ４０に転送するリクエストに対し、セッション情報を付与することができるようにするためである。すなわちＷｅｂサーバ４０におけるシステムモデルを構成するアプリケーション・プログラムによっては、セッションの状態をＷｅｂサーバ４０側で保持しているものがあり、その場合、リクエストは適切なセッション情報を含んでいる場合にのみ正常に処理される。つまり、不適切なリクエストをやみくもに発信しても意味がない。簡単な例としては、ログアウトのリクエストを、ログイン時に返信されるはずのセッション情報を伴わずに発信しても、そのリクエストについてのＷｅｂサーバ４０での処理はエラーとなってしまい、通常の処理は行われない。そこで、擬似クライアント４３を採用し、各リクエストに対して適切なセッション情報を付与することができるようにしている。
【００３８】
擬似クライアント４３は、Ｗｅｂサーバ４０側での状態遷移に対応する各状態間を遷移する状態遷移グラフに従った状態遷移を定義しており、各状態に対応するキューを備える。各キューにはセッション情報を含むリクエストを発信するスレッドが予め蓄えられる。擬似クライアント４３は、各種類のリクエストが要求されたとき、該種類のリクエストを発信するスレッドをキューから取り出して該スレッドによりリクエストを発信し、該スレッドを状態遷移グラフに従い、次の状態のキューに移動させる。
【００３９】
具体例として、Ｗｅｂサーバ４０におけるシステムモデルが簡単なショッピングサイトのＷｅｂアプリケーションで構成される場合について考える。図４に示すように、擬似クライアント４３は、状態遷移グラフとして、Ｗｅｂサーバ４０側での状態遷移に対応するログイン前の状態４４、ログイン中の状態４５、及びログアウト後の状態４６の各状態間を遷移するものを定義し、各状態４４〜４６に対応するキュー４７〜４９を有する。リクエストの種類は、Ａ．ログイン、Ｂ．カタログの表示、Ｃ．決済、Ｄ．ログアウトの４種類である。ログイン前状態４４で発信できるリクエストはログイン（Ａ）であり、ログイン中状態４５で発信できるリクエストは、カタログ表示（Ｂ）、決済（Ｃ）、又はログアウト（Ｄ）である。ログアウト後の状態４６で発信できるリクエストはない。
【００４０】
遷移状態グラフ中の各矢印は、遷移前の状態から遷移後の状態へ伸びており、各矢印には、それが示す状態遷移に際してスレッドが発信するリクエストの種類を示す記号Ａ〜Ｄが添えられている。すなわちログイン前状態４４にあるスレッドがログイン・リクエストＡを発信した場合、そのスレッドはキュー４８に移動される。ログイン中状態４５にあるスレッドが、カタログ表示リクエストＢ又は決済リクエストＣを発信した場合には、そのスレッドはキュー４８に戻される。また、ログイン中状態４５にあるスレッドが、ログアウト・リクエストＤを発信した場合には、そのスレッドはキュー４９に移動される。
【００４１】
キュー４７及び４８には、予め、負荷調整期間におけるリクエストの要求に対応することができる数のスレッドが用意される。すなわち擬似クライアント４３は、キュー４７に所定数のスレッドを用意し、そのうちの適当な数のスレッドによりログイン・リクエストＡをＷｅｂサーバ４０に送信してＷｅｂサーバ４０からセッション情報を取得し、各スレッドをキュー４８に移動する。これにより、キュー４７にはログイン前状態にある適当な数のスレッドを蓄積し、キュー４８にはログイン中状態にある適当数のセッション情報を有するスレッドを蓄積しておく。
【００４２】
擬似クライアント４３はログイン・リクエストＡが要求された場合には、ログイン前状態のキュー４７からスレッドを取り出し、該スレッドによりログイン・リクエストＡを発信し、該レッドをログイン中状態のキュー４８へ移動する。カタログ表示リクエストＢ又は決済リクエストＣが要求された場合には、ログイン中状態のキュー４８からスレッドを取り出し、該スレッドによりセッション情報を含むカタログ表示リクエストＢ又は決済リクエストＣを発信し、該スレッドをキュー４８に戻す。ログアウト・リクエストＤが要求された場合には、ログイン中状態のキュー４８からスレッドを取り出し、該スレッドによりセッション情報を含むログアウト・リクエストＤを発信し、そして該スレッドをキュー４９に移動する。なお、キュー４９へ移動されたスレッドは、消去してもいいし、ログイン前状態のキュー４７に戻してもよい。
【００４３】
なお、状態遷移グラフとしてより複雑なものを用いる場合には、あるリクエストの要求に対し、そのリクエストを発信することができるスレッドの状態が複数存在することもあり得る。その場合には、該複数状態の中からランダムにそのリクエストを発信させる状態を選択すればよい。
【００４４】
擬似クライアント４３によれば、キュー４７及び４８中に、予め十分な数のスレッドを必要なセッション情報とともに用意しておくことにより、各種類のリクエスト要求に対し、またセッション情報が必要なリクエストに対しても、対応することができる。したがって、セッションの状態を保持しているＷｅｂサーバ４０のシステムに対しても、通常の稼働状態を維持させながら、リクエストの種類毎に異なる定常な負荷を印加することができる。
【００４５】
キュー４７及び４８に予め蓄えておくスレッドの数は、対応するログイン前状態及びログイン中状態のそれぞれにおいて発信し得るリクエストＡ及び各リクエストＢ、Ｃ、Ｄについて、各負荷調整フィルタ４１ａ〜４１ｄにおいて設定した到着時間間隔分布を考慮して決定することができる。その場合、たとえば、負荷調整期間においてキュー４７及び４８中のスレッドが枯渇しない確率が９０％以上となるように、スレッド数を見積もることができる。その場合、希なケースとして、スレッドがキューから無くなってしまった場合には、対応するリクエストの発信は無視してもかまわない。負荷試験により収集する性能データについては、これに基づいてシステムモデルのパラメータを推定する際に統計処理を行うので、希なケースとして、設定したリクエストの到着時間間隔分布から外れた時間間隔で到着するリクエストが発生するとしても大きな問題ではない。
【００４６】
Ｗｅｂサーバ４０におけるシステムモデルについての性能データの収集を行うために負荷調整を行うに際しては、それぞれリクエストＡ〜Ｄについての所望の到着時間間隔分布に対応する乱数を発生するように、予め、各負荷調整フィルタ４１ａ〜４１ｄにおける乱数発生器５２のパラメータが設定される。そして、負荷調整の実施に際しては、各負荷調整フィルタ４１ａ〜４１ｄのゲート５３は図３と同様の処理を行う。すなわち、乱数発生器５２より乱数を取得し、乱数に対応する時間待機した後、キュー５１内にリクエストが存在する場合はそのリクエストをＷｅｂサーバ４０に転送し、存在しない場合は擬似クライアント４３から対応する種類のリクエストＡ〜Ｄのいずれかを取得してＷｅｂサーバ４０に転送するという処理を繰り返す。
【００４７】
これにより、各負荷調整フィルタ４１ａ〜４１ｄのゲート５３は、インターネットからのリクエストＡ〜Ｄに対し、擬似クライアントからのリクエストＡ〜Ｄを加え、これを各乱数発生器５２における確率分布の設定に応じた到着時間間隔分布で、Ｗｅｂサーバ４０に供給することができる。したがって、リクエストの種類毎に負荷量が異なり、かつ定常的な負荷をＷｅｂサーバ４０に印加することができる。
【００４８】
したがって本実施形態によれば、顧客のＷｅｂサーバ４０におけるシステムモデルについてのパフォーマンスを向上させるサービスに際し、稼働中のシステムを長時間停止して取引機会の損失を招くようなことなく、定常的な負荷を与えながら性能データの収集を行い、システムモデルのパラメータの推定を行うことができる。この結果、取引機会の損失を恐れて二の足を踏んでいる顧客へのパフォーマンス・サービスに対する敷居が低くなるので、サービス・ビジネスを発展させるうえで大きく貢献することができる。
【００４９】
また、自律コンピューティングの技術が揃ってきた場合に、本発明に従った負荷調整フィルタは、システムモデルに基づく自律調整機能を稼働中のシステムに導入する際のコストが小さいため、かかる導入を促進することができる。
【００５０】
なお、本発明は上述実施形態に限定されることなく適宜変形して実施することができる。たとえば、上述においては、サーバに送信されてくるリクエストを一旦キューに蓄積し、転送する際に擬似的なリクエストを混合することにより負荷を調整するようにしているが、この代わりに、サーバに送信されてくるリクエストをキューに蓄積することなくモニタし、モニタ結果に応じて、擬似的なリクエストを直接サーバに送信することにより、本来のリクエストに対し、擬似的リクエストを加え、負荷の調整を行うようにしてもよい。
【００５１】
上述の各実施形態に係る負荷調整フィルタについて、特に想定している応用の場面は、出願人が提供するウェブスフェア（ＷｅｂＳｐｈｅｒｅ）製品群から構成されるＷｅｂサーバの性能を解析することにより、Ｗｅｂアプリケーション及び想定されるリクエスト量に対して最適となるサーバ・ソフトウェアのパラメータ（スレッド数、キャッシュサイズ等）を見出すサービスや、サーバ・ソフトウェアのパラメータを動的に調整する自動制御の手法等の場面である。この場合のシステムモデルのパラメータとは、たとえば個々のリクエストに対応するトランザクションが消費するＣＰＵ、ディスクＩ／Ｏ、ネットワークＩ／Ｏ等のハードウェア資源の消費量である。典型的な３階層のＷｅｂサーバでは、ＨＴＴＰサーバ、アプリケーション・サーバ、及びデータベースの各階層におけるトランザクションのハードウェア資源消費量を個別に推定し、モデルを完成させる。
【００５２】
【発明の効果】
以上説明したように本発明によれば、サーバに送信されてくるリクエストに対し、擬似的なリクエストを加えることによってサーバに印加される負荷の調整を行うようにしたため、サーバによるサービスの提供を停止させることなく調整された負荷をサーバに対して印加することができる。
【００５３】
また、サーバに送信されてくるリクエストに対して擬似的なリクエストを加えたものを、所定の到着時間間隔分布で到着するようなタイミングで前記サーバに転送するようにしたため、負荷を定常化させることができる。
【００５４】
また、サーバに送信されてくるリクエストに対し、リクエストの種類毎に、擬似的なリクエスト加えたものを、それぞれ独自の所定の到着時間間隔分布で到着するようなタイミングで転送するようにしたため、リクエストの種類毎に負荷を定常化することができる。
【００５５】
さらに、セッション情報を含むことが必要な種類の擬似的リクエストについては、予めサーバにリクエストを転送することによって取得したセッション情報を含むものとして、そのリクエストを発生するようにしたため、セッションの状態を保持しているサーバについても、支障なく負荷の調整を行うことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る負荷調整フィルタのモジュール構成を示すブロック図である。
【図２】図１の負荷調整フィルタのハードウェア構成を示すブロック図である。
【図３】図１の負荷調整フィルタのゲートによる負荷調整処理手順を示すフローチャートである。
【図４】本発明の他の実施形態を示すブロック図である。
【図５】図４の実施形態における各負荷調整フィルタの構成を示すブロック図である。
【図６】システムモデルに基づく性能評価を行う手順を示す図である。
【符号の説明】
１：負荷調整フィルタ、２：Ｗｅｂサーバ：インターネット、４：受信キュー、５：擬似クライアント、６：乱数発生器、７：ゲート、２１：ＣＰＵ、２２：メモリ、２３：入力手段、２４：ディスプレイ、２５：通信インタフェース、２６：バス、４０：Ｗｅｂサーバ、４１ａ〜４１ｄ：負荷調整フィルタ、４２：ディスパッチャ、４３：擬似クライアント、４４：ログイン前状態、４５：ログイン中状態、４６：ログアウト後状態、４７〜４９：スレッド・キュー、５１：リクエスト・キュー、５２：乱数発生器、５３：ゲート。
【図１】
2004348491.tif 000003
【図２】
2004348491.tif 000004
【図３】
2004348491.tif 000005
【図４】
2004348491.tif 000006
【図５】
2004348491.tif 000007
【図６】
2004348491.tif 000008