(57)【要約】【課題】限られたシステムリソースを有効活用し、全サービスにおいて可能な限り、サービスレベル内に収めて運用を行なう。【解決手段】Ｗｅｂサーバ１は、データベース（ＤＢ）サーバ２との間で各種情報を授受する。データベースサーバ２は、Ｗｅｂサーバ１が提供する複数のサービスの各々で用いられる各種情報を保持している。サービス品質維持システム５は、クライアント４からＷｅｂサーバ１へのアクセス状況を収集し、所定のサービスレベルとそのときのサービス毎の利用状況とを比較することで、所定のサービスレベルと比べ余裕のあるサービスと既に所定のサービスレベルを超えているサービスとを判断し、その差がなくなるように、システムリソースを最適に割り振る。【選択図】  図１
2004259110.tif 000002
【特許請求の範囲】
【請求項１】
所定のサービスレベルを定めて運用している複数のサービスの品質を維持するサービス品質維持装置において、
所定のサービスレベルと各サービスの運用状態とに基づいて、各サービスに分け与えるリソースの配分値を計算する演算手段と、
前記演算手段により計算された配分値に基づいてリソースをサービス毎に分け与える際に、所定のサービスレベルを超えているサービスを所定のサービスレベル内で運用させる制御手段と
を具備することを特徴とするサービス品質維持装置。
【請求項２】
前記演算手段は、全サービスのレスポンスタイムの平均値を算出し、該レスポンスタイム平均値と所定のサービスレベルとに基づいて、全サービスに分け与えるリソースの配分値を計算することを特徴とする請求項１記載のサービス品質維持装置。
【請求項３】
全サービスのレスポンスタイムの平均値を算出するステップと、
前記レスポンスタイムの平均値と所定のサービスレベルとに基づいて、各サービスに分け与えるリソースの配分値を計算するステップと、
該配分値に基づいてリソースをサービス毎に分け与える際に、サービスレベルを超えているサービスをサービスレベル内で運用させるステップと
をコンピュータに実行させることを特徴とするサービス品質維持プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、それぞれサービスレベルを定めて運用している複数のサービスの品質を維持するサービス品質維持装置およびサービス品質維持プログラムに関する。
【０００２】
【従来の技術】
従来、複数のサービスが運用されており、複数のサービスに対し、それぞれサービスレベルを定めて運用している情報通信端末において、サービス品質維持方法としては、長期的に見て、運用中に定められたサービスレベルを守れなくなると予測されたり、実際に守れなくなったりした際に、一度運用を止め、不足していると推測されたシステムリソースを物理的に増強することで、サービス品質を守ろうとしてきた。また、限られたリソースの中で、サービス品質を可能な限り守るための方法として、複数存在するサービス品質のうち、サービスの種類・利用者の種別・利用時間帯などの指標を用いて、複数のサービスに対し優先度を付けて、優先度の低いものを犠牲にして、優先度の高いサービスの品質を上げるためのＱｏＳの考え方が考案され、採用されている（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開平１０−９７４７６号公報
【０００４】
【発明が解決しようとする課題】
しかしながら、前者の方法では、システムリソース資源を増強していけば問題解決にはなるが、どのシステムリソースが不足しているかを判断することが難しく、また、増強すればするほどコストがかかってしまう。一方、後者の方法では、限られた資源の中でサービスレベルをできるだけ守ろうとする手法であるが、優先度がはじめから決定されてしまい、優先度の高いサービスにばかり資源が使われてしまうといった問題や、優先度の低いサービスを犠牲にする必要があるため、どのサービスも重要であり、優先度を付けられない場合、優先度により切り捨てられるサービスを選べないといった問題があった。
【０００５】
この発明は上述した事情に鑑みてなされたもので、限られたシステムリソースを有効活用することで、全サービスにおいて可能な限り、サービスレベル内に収めて運用を行なうことができるサービス品質維持装置およびサービス品質維持プログラムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した問題点を解決するために、請求項１記載の発明では、所定のサービスレベルを定めて運用している複数のサービスの品質を維持するサービス品質維持装置において、所定のサービスレベルと各サービスの運用状態とに基づいて、各サービスに分け与えるリソースの配分値を計算する演算手段と、前記演算手段により計算された配分値に基づいてリソースをサービス毎に分け与える際に、所定のサービスレベルを超えているサービスを所定のサービスレベル内で運用させる制御手段とを具備することを特徴とする。
【０００７】
また、請求項２記載の発明では、請求項１記載のサービス品質維持装置において、前記演算手段は、全サービスのレスポンスタイムの平均値を算出し、該レスポンスタイム平均値と所定のサービスレベルとに基づいて、全サービスに分け与えるリソースの配分値を計算することを特徴とする。
【０００８】
また、上述した問題点を解決するために、請求項３記載の発明では、全サービスのレスポンスタイムの平均値を算出するステップと、前記レスポンスタイムの平均値と所定のサービスレベルとに基づいて、各サービスに分け与えるリソースの配分値を計算するステップと、該配分値に基づいてリソースをサービス毎に分け与える際に、サービスレベルを超えているサービスをサービスレベル内で運用させるステップとをコンピュータに実行させることを特徴とする。
【０００９】
この発明では、演算手段により、所定のサービスレベルと各サービスの運用状態とに基づいて、各サービスに分け与えるリソースの配分値を計算し、該配分値に基づいてリソースをサービス毎に分け与える際に、制御手段により、所定のサービスレベルを超えているサービスを所定のサービスレベル内で運用させる。したがって、限られたシステムリソースを有効活用することで、全サービスにおいて可能な限り、サービスレベル内に収めて運用を行なうことが可能となる。
【００１０】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
【００１１】
Ａ．実施形態の構成
図１は、本発明の実施形態によるサービス品質維持装置を提供したシステム全体の一構成例を示すブロック図である。図１において、Ｗｅｂサイト３には、複数のサービス、例えば、図５に示すように、５つのサービスＡ〜Ｅを提供するＷｅｂサーバ１と、該Ｗｅｂサーバ１のサービスで用いられる各種情報を保持するデータベース（ＤＢ）サーバ２とが存在する。なお、本実施形態では、サービスの品質を表す指標として、レスポンスタイムを用いることとし、全てのサービスＡ〜Ｅともサービスレベルを８秒とする。各サービスＡ〜Ｅにおいて、１つのリクエストがＷｅｂサイト３で処理されるのに必要な処理時間は、図５に示すように、サービスＡが０．６秒、サービスＢが０．９秒、サービスＣが０．４秒、サービスＤが０．８秒、サービスＥが０．３秒となっている。
【００１２】
クライアント４は、ネットワークを介してＷｅｂサーバ１にアクセスし、該Ｗｅｂサーバ１が提供する各種サービス（この場合、サービスＡ〜Ｅ）を享受する。実際には、クライアント４のリクエストは、サービス品質維持システム５で制御されることになる。
【００１３】
サービス品質維持システム５は、クライアント４からＷｅｂサーバ１へのアクセス状況を収集し、所定のサービスレベルとそのときのサービス毎の利用状況とを比較することで、所定のサービスレベルと比べ余裕のあるサービスと既に所定のサービスレベルを超えているサービスとを判断し、その差を計算する。そして、この差がなくなるように、システムリソースを最適に割り振る。
【００１４】
すなわち、サービス品質維持システム５は、Ｗｅｂサーバ１で利用される全サービスの利用状況から、現在の利用状況を計算し、サービスレベルと計算された現在の利用状況との差を比較し、サービスレベルに比べ現在の利用状況に余裕があるサービスに対してはシステムリソースを制限し、このシステムリソースをサービスレベルよりも現在の値が越えてしまうサービスに対して分け与えることで、サービスレベルを超えてしまうアクセスを減らすようにしている。
【００１５】
また、サービス品質維持システム５は、複数のサービスに対し、各サービスに分け与えるＷｅｂサーバ１のリソースのより有効な配分値を計算し、この配分値を用いてサービスに対して優先度をつけ、この配分値に基づいて制御を行なうことで、限られたリソースを有効活用する。なお、図１に示す点線は、トラフィックの流れる方向を示している。
【００１６】
次に、図２は、本実施形態によるサービス品質維持システム５の構成を示すブロック図である。サービス品質維持システム５には、「通常・維持・改善」の３つのモードが存在する。「通常モード」は、どのサービスもサービスレベルより低いレスポンスタイムを持っている場合の動作モードである（図６参照）。「維持モード」は、１つ以上のサービスがサービスレベルよりもレスポンスタイムが高く、全サービスの全体平均レスポンスタイムは、サービスレベルよりも下回っている場合の動作モードである（図７参照）。「改善モード」は、全サービスの全体平均レスポンスタイムがサービスレベルより高い場合の動作モードである（図８参照）。
【００１７】
サービス品質維持システム５は、利用状況収集システム６、リソース解放時間計算システム７、待機可能時間計算システム８、リクエスト待機システム９およびダミーリクエスト発生システム１０から構成されている。利用状況収集システム６は、定期的にサービス毎のレスポンスタイムおよび全体平均レスポンスタイムを計算する。また、利用状況収集システム６は、Ｗｅｂサイト３のアクセス状況を収集する。
【００１８】
リソース解放時間計算システム７は、各サービスのリソース解放時間ＲＲＴ（Ｘ）を計算する。ページ毎のリソース解放時間ＲＲＴ（Ｘ）は、式「（各サービスのリソース解放時間）＝（全体平均レスポンスタイム）−（各サービスの平均レスポンスタイム）」により求められる。
【００１９】
待機可能時間計算システム８は、利用状況収集システム６で得られた全体平均レスポンスタイムと予め定められたサービスレベルとの差を求め、待機可能時間Ｗを算出する。ここで、待機可能時間Ｗとは、サービス毎のリクエストがリクエスト待機システム９でサービス毎に存在する待ち行列Ｑ（Ｘ）の中に滞在でき得る時間を示し、リクエストの待ち行列Ｑ（Ｘ）での滞在時間Ｗを超えたとき、そのリクエストがサービスレベルを守れなくなったことを意味する。
【００２０】
リクエスト待機システム９は、サービス毎の待ち行列部１１と処理部１２とを備えている。サービス毎の待ち行列部１１は、サービス毎に用意された待ち行列Ｑ（Ｘ）（Ｘはサービス名）を有する。処理部１２は、各サービスのリクエストおよびダミーリクエストを処理するためのエリアを有する。エリアの数Ｎ（Ｘ）（Ｘはサービス名）は、処理部１２で同時に処理できる数（可変）を示す。処理部１２に入ったリクエストおよびダミーリクエストは、Ｗｅｂサイト３で処理が完了するまで、処理部１２に滞在し、Ｗｅｂサイト３での処理完了後、処理部１２から消滅する。
【００２１】
ダミーリクエスト発生システム１０は、サービス品質維持システム５が起動すると、サービス毎に０．１秒単位にＷｅｂサイト３上で負荷を与えないダミーリクエストを生成する。
【００２２】
Ｂ．実施形態の動作
次に、本実施形態の動作について詳細に説明する。
【００２３】
サービス品質維持システム５を起動すると、最初に、ダミーリクエスト発生システム１０からサービス毎に０．１秒単位にＷｅｂサイト３上で負荷を与えないダミーリクエストが生成される。クライアント４からの通常リクエストとダミーリクエストは、サービス毎のリクエスト待機システム９に移動し、サービス毎に用意された待ち行列Ｑ（Ｘ）１１に入る。処理部１２に入ったリクエストおよびダミーリクエストは、Ｗｅｂサイト３で処理が完了するまで、処理部１２に滞在する。同時に、利用状況収集システム６において、定期的にサービス毎のレスポンスタイムおよび全体平均レスポンスタイムを計算する。
【００２４】
「通常モード」では、処理部１２のそれぞれのエリアの数Ｎ（Ｘ）は、Ｗｅｂサイト３に対する同時受け付けリクエスト数に等しい。そのため、発生したリクエストおよびダミーリクエストは待たされることなく、処理部１２に入り、Ｗｅｂサイト３での処理完了後、処理部１２から消滅する。
【００２５】
次に、図７に示すように、Ｗｅｂサイト３の全体平均レスポンスタイムがサービスレベルである８秒よりも低く、あるサービスのレスポンスタイムがサービスレベルより高い値を示した場合、サービス品質維持システム５は、「維持モード」に遷移する。
【００２６】
利用状況収集システム６が「維持モード」であると判断すると、リクエスト待機システム９は、処理部１２に存在しているサービス毎のリクエスト数を求め、サービス毎の処理部１２の数Ｎ（Ｘ）として設定する。処理部１２の数Ｎ（Ｘ）が設定されると、リクエスト待機システム９では、サービス毎にＮ（Ｘ）個までしか同時に処理できなくなる。あるサービスでＮ（Ｘ）個以上のリクエストが同時に発生した場合、Ｎ（Ｘ）個目以降のリクエストは、待ち行列部１１の待ち行列Ｑ（Ｘ）に入り、処理部１２に空きが発生するまで、待ち行列Ｑ（Ｘ）の中で順に待機するようになる。この場合、サービス毎の処理部１２のエリアの数Ｎ（Ｘ）を図７に示す。
【００２７】
次に、待機可能時間計算システム８において、利用状況収集システム６で得られた全体平均レスポンスタイムと予め定められたサービスレベルとの差を求め、待機可能時間Ｗを算出する。図７に示す状況では、待機可能時間Ｗ＝（サービスレベル）−（全体平均レスポンスタイム）＝３秒となる。各サービスの待ち行列Ｑ（Ｘ）での滞在時間Ｗｃ（Ｘ）は、待ち行列Ｑ（Ｘ）に存在するダミーリクエストの数により、式「Ｗｃ（Ｘ）＝ダミーリクエストの数×０．１」で求められる。あるサービスの待ち行列Ｑ（Ｘ）でＷｃ（Ｘ）≦Ｗのときは、「維持モード」を継続し、Ｗｃ（Ｘ）＞Ｗのときは、そのサービスがサービスレベルを守れなくなったことを示し、サービス品質維持システム５は、「維持モード」から「改善モード」に遷移する。
【００２８】
「維持モード」では、待機可能時間Ｗを計算すると同時に、リソース解放時間計算システム７において、リソース解放時間ＲＲＴ（Ｘ）を計算する。ページ毎のリソース解放時間は、式「（各サービスのリソース解放時間）＝（全体平均レスポンスタイム）−（各サービスの平均レスポンスタイム）」により求められる。但し、各サービスのリソース解放時間が０未満である場合には、そのサービスのリソース解放時間は０となる。求められたリソース解放時間を図７に示す。そして、計算されたリソース解放時間の間だけ、リクエストをＷｅｂサイト３の処理部１２で待機させる。
【００２９】
これにより、全体平均レスポンスタイムより低いレスポンスタイムを持つサービスは、リソース解放時間だけ処理部１２で待たされることにより、全体平均レスポンスタイムに近づき、サービスレベルよりも高いレスポンスタイムを持つサービスは、リソース資源をより多く与えられ、Ｗｅｂサイト３での処理時間が減少するため、レスポンスタイムが減少する。
【００３０】
このため、全サービスが全体平均レスポンスタイムに近づき、結果としてサービスレベルよりも高かったサービスのレスポンスタイムは減少する。また、実際の各サービスのレスポンスタイムＲＴは、式「ＲＴ（Ｘ）＝Ｗｃ（Ｘ）＋ＲＲＴ（Ｘ）＋ＥＸＴ（Ｘ）」で表される。但し、ＥＸＴ（Ｘ）は、Ｗｅｂサイト３での処理時間となる。ＥＸＴ（Ｘ）は、処理部１２のエリアの数Ｎ（Ｘ）と図５で示されるＷｅｂサイト３で１つのリクエストを処理するのに必要な時間である。
【００３１】
図７に示す場合に「維持モード」を行なった結果を、図３および図９に示す。但し、ここでは、Ｗｃ＝０として計算している。図３および図９に示すように、サービスレベルを超えていたサービスＢおよびサービスＤのレスポンスタイムは、サービスレベル以下となる。次に、ある時点で、Ｗｃ（Ｘ）＞Ｗとなるとき、もしくは全体平均レスポンスタイムがサービスレベルを超えてしまったとき、「維持モード」は前述した通り、「改善モード」に遷移する。
【００３２】
「改善モード」に遷移すると、利用状況収集システム６で、Ｗｅｂサイト３のアクセス状況を収集する。このときのサービス毎の平均レスポンスタイムと全体平均レスポンスタイムを図８に示す。「改善モード」では、全体平均レスポンスタイムがサービスレベルを超えているため、制限していた各サービスの処理部１２のエリアの数Ｎ（Ｘ）をＷｅｂサイト３への同時受付リクエスト数に戻す。待機時間の計算は行なわず、リソース解放時間計算システム７で、リソース解放時間を再計算する。「改善モード」では、式「ＲＲＴ（Ｘ）＝ＳＬＡ（Ｘ）−ＲＴ（Ｘ）」で各サービスのリソース解放時間ＲＲＴ（Ｘ）を求める。但し、ＳＬＡは、サービスレベル、ＲＴ（Ｘ）は、各サービスのレスポンスタイムを表し、ＲＲＴ（Ｘ）が０未満である場合は、ＲＲＴ（Ｘ）＝０となる。この場合のリソース解放時間を図８に示す。
【００３３】
これにより、サービスレベルより低いレスポンスタイムを持つサービスは、リソース解放時間だけ処理部１２で待たされることになり、サービスレベルよりも高いレスポンスタイムを持つサービスは、リソースをより多く与えられ、Ｗｅｂサイトでの処理時間が減少することとなり、レスポンスタイムが減少する。実際の各サービスのレスポンスタイムＲＴは、式「ＲＴ（Ｘ）＝ＲＲＴ（Ｘ）＋ＥＸＴ（Ｘ）」で表される。各サービスの処理部１２で同時に３つずつ処理されている場合のレスポンスタイムは、図８に示す通りとなる。また、改善後も処理部１２で同時に処理されているリクエストの数が一定であるとすると、図４および図１０に示すように、サービスＡ，ＢおよびＤのように、レスポンスタイムがサービスレベルを超えるサービスのレスポンスタイムは減少し、さらにサービスＡでは、レスポンスタイムがサービスレベル以下となる。
【００３４】
上述した実施形態では、複数のサービスが運用されており、それら複数のサービスに対し、それぞれサービスレベルを定めて運用している情報通信端末において、サービスレベルと各サービスの運用状態とを比較し、各サービスに分け与える情報通信端末のリソースのより有効な配分値を計算し、計算結果の通り、情報通信端末のリソースを各サービスに分け与えることにより、サービスレベルを超えてしまっていたサービスをサービスレベル内で運用させることが可能となる。
【００３５】
なお、上述した実施形態において、サービス品質維持システム５の機能は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。
【００３６】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理をサービス品質維持システム５に既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００３７】
以上、この発明の実施形態を、図面を参照して詳述してきたが、具体的な構成は、上記実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【００３８】
【発明の効果】
以上説明したように、本発明によれば、守るべきサービスレベルを定められた複数のサービスを持つ情報通信端末において、情報通信端末のシステムリソースが限られており、増強ができず、さらに、複数のサービスのうち、サービスの種類・利用者の種別・利用時間帯などの指標で優先度を付けることができないような状況であっても、所定のサービスレベルと各サービスの運用状態とに基づいて、各サービスに分け与えるリソースの配分値を計算し、該配分値に基づいてリソースをサービス毎に分け与える際に、所定のサービスレベルを超えているサービスを所定のサービスレベル内で運用させることで、全サービスにおいて可能な限り、サービスレベル内に収めて運用を行なうことができるという利点が得られる。
【図面の簡単な説明】
【図１】本発明の実施形態によるサービス品質維持装置を提供したシステム全体の一構成例を示すブロック図である。
【図２】本実施形態によるサービス品質維持システム５の構成を示すブロック図である。
【図３】維持動作後のレスポンスタイムの遷移を説明するための概念図である。
【図４】改善動作後のレスポンスタイムの遷移を説明するための概念図である。
【図５】Ｗｅｂサイトにおける各サービスの処理時間を示す概念図である。
【図６】「通常モード」における各サービスのレスポンスタイムを示す概念図である。
【図７】「維持モード」における各サービスのレスポンスタイム、処理部のエリアの数、リソース解放時間を示す概念図である。
【図８】「改善モード」における各サービスのレスポンスタイム、リソース解放時間を示す概念図である。
【図９】維持前および維持後のレスポンスタイムを示す概念図である。
【図１０】改善前および改善後のレスポンスタイムを示す概念図である。
【符号の説明】
１  Ｗｅｂサーバ
２  データベースサーバ
３  Ｗｅｂサイト
４  クライアント
５  サービス品質維持システム（演算手段、制御手段）
６  利用状況収集システム
７  リソース解放時間計算システム
８  待機可能時間計算システム
９  リクエスト待機システム
１０  ダミーリクエスト発生システム
１１  待ち行列部
１２  処理部
【図１】
2004259110.tif 000003
【図２】
2004259110.tif 000004
【図３】
2004259110.tif 000005
【図４】
2004259110.tif 000006
【図５】
2004259110.tif 000007
【図６】
2004259110.tif 000008
【図７】
2004259110.tif 000009
【図８】
2004259110.tif 000010
【図９】
2004259110.tif 000011
【図１０】
2004259110.tif 000012