(57)【要約】【課題】複数のサーバからなる計算機システムにおいて後処理が発生する場合でも、サーバ負荷を適切に判定すること。【解決手段】複数のサーバの負荷を管理するサーバ負荷管理システムは、各サーバの性能指標の時系列変化を示す性能指標変化テーブルが格納される記憶装置と、性能指標変化テーブルを参照してサーバ負荷を算出する処理装置と、を備える。性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含む。処理装置は、傾向判定部と負荷算出部とを有する。傾向判定部は、リクエストインデックスの時系列変化に基づいて、複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行う。負荷算出部は、ＣＰＵ使用率を上記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出する。判定結果が増加傾向の場合、ＣＰＵ使用率は上方修正され、一方、判定結果が減少傾向の場合、ＣＰＵ使用率は下方修正される。【選択図】図４
2009252050.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバの負荷を管理するサーバ負荷管理システムであって、
前記複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルが格納される記憶装置と、
前記性能指標変化テーブルを参照してサーバ負荷を算出する処理装置と
を備え、
前記性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含み、
前記処理装置は、
前記リクエストインデックスの時系列変化に基づいて、前記複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行う傾向判定部と、
前記ＣＰＵ使用率を前記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出する負荷算出部と
を有し、
前記判定結果が増加傾向の場合、前記負荷算出部は前記ＣＰＵ使用率を上方修正し、
前記判定結果が減少傾向の場合、前記負荷算出部は前記ＣＰＵ使用率を下方修正する
サーバ負荷管理システム。
【請求項２】
請求項１に記載のサーバ負荷管理システムであって、
前記負荷算出部は、所定の比率だけ前記ＣＰＵ使用率を上方修正あるいは下方修正する
サーバ負荷管理システム。
【請求項３】
請求項２に記載のサーバ負荷管理システムであって、
リクエストを受け取ってからレスポンスを返すまでのリクエスト処理に使われるＣＰＵ時間がｓ１であり、前記レスポンスを返した後の後処理に使われるＣＰＵ時間がｓ２であるとき、前記所定の比率はｓ１と（ｓ１＋ｓ２）との間の比率である
サーバ負荷管理システム。
【請求項４】
請求項１乃至３のいずれか一項に記載のサーバ負荷管理システムであって、
前記傾向判定部は、前記リクエストインデックスの時系列変化に基づいて、前記複数のサーバの各々に関して処理中のリクエスト数の変化率を算出し、
前記変化率が所定の正の閾値以上である場合、前記傾向判定部は、処理中のリクエスト数が増加傾向にあると判定し、
前記変化率が所定の負の閾値以下である場合、前記傾向判定部は、処理中のリクエスト数が減少傾向にあると判定する
サーバ負荷管理システム。
【請求項５】
請求項１乃至４のいずれか一項に記載のサーバ負荷管理システムであって、
前記リクエストインデックスは、処理中のリクエスト数、単位時間あたりのリクエスト到着数、リクエストが格納されるキューの長さ、リクエストを処理するためのプロセス数のうちいずれかである
サーバ負荷管理システム。
【請求項６】
請求項１乃至５のいずれか一項に記載のサーバ負荷管理システムであって、
前記負荷算出部は、前記複数のサーバからいくつかのサーバを抽出し、前記抽出されたサーバの各々に関して前記修正後ＣＰＵ使用率を算出する
サーバ負荷管理システム。
【請求項７】
請求項６に記載のサーバ負荷管理システムであって、
前記負荷算出部は、前記ＣＰＵ使用率と前記判定結果に基づいて、前記いくつかのサーバを抽出し、
前記いくつかのサーバは、
前記判定結果が増加傾向であるサーバのうち、前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの少なくとも一方と、
前記判定結果が減少傾向であるサーバのうち、前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの少なくとも一方と
を含む
サーバ負荷管理システム。
【請求項８】
請求項６又は７に記載のサーバ負荷管理システムであって、
前記処理装置は、前記抽出されたサーバから前記修正後ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの少なくとも１つを選択するサーバ選択部を更に有する
サーバ負荷管理システム。
【請求項９】
請求項６に記載のサーバ負荷管理システムであって、
前記処理装置は、
サーバ選択部と、
リクエスト割当部と
を更に有し、
前記負荷算出部は、前記ＣＰＵ使用率と前記判定結果に基づいて、前記いくつかのサーバを抽出し、
前記いくつかのサーバは、
前記判定結果が増加傾向であるサーバのうち前記ＣＰＵ使用率が最小であるサーバと、
前記判定結果が減少傾向であるサーバのうち前記ＣＰＵ使用率が最小であるサーバと
を含み、
前記サーバ選択部は、前記抽出されたサーバから前記修正後ＣＰＵ使用率が最小であるサーバを選択し、
前記リクエスト割当部は、新規リクエストを前記選択されたサーバに送信する
サーバ負荷管理システム。
【請求項１０】
請求項６に記載のサーバ負荷管理システムであって、
前記処理装置は、
サーバ選択部と、
処理移行部と
を更に有し、
前記負荷算出部は、前記ＣＰＵ使用率と前記判定結果に基づいて、前記いくつかのサーバを抽出し、
前記いくつかのサーバは、
前記判定結果が増加傾向であるサーバのうち、前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの両方と、
前記判定結果が減少傾向であるサーバのうち、前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの両方と
を含み、
前記サーバ選択部は、前記抽出されたサーバから前記修正後ＣＰＵ使用率が最大である第１サーバと最小である第２サーバを選択し、
前記処理移行部は、前記第１サーバで実行中の処理のいくつかを前記第２サーバに移行する
サーバ負荷管理システム。
【請求項１１】
複数のサーバの負荷を管理するサーバ負荷管理方法であって、
（Ａ）前記複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルを、記憶装置から読み出すステップと、
ここで、前記性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含み、
（Ｂ）前記リクエストインデックスの時系列変化に基づいて、前記複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行うステップと、
（Ｃ）前記ＣＰＵ使用率を前記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出するステップと
を含み、
前記判定結果が増加傾向の場合、前記ＣＰＵ使用率は上方修正され、
前記判定結果が減少傾向の場合、前記ＣＰＵ使用率は下方修正される
サーバ負荷管理方法。
【請求項１２】
請求項１１に記載のサーバ負荷管理方法であって、
前記（Ｃ）ステップは、
（Ｃ１）前記複数のサーバからいくつかのサーバを抽出するステップと、
（Ｃ２）前記抽出されたサーバの各々に関して前記修正後ＣＰＵ使用率を算出するステップと
を含む
サーバ負荷管理方法。
【請求項１３】
請求項１２に記載のサーバ負荷管理方法であって、
更に、（Ｄ）前記抽出されたサーバから前記修正後ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの少なくとも１つを選択するステップを含む
サーバ負荷管理方法。
【請求項１４】
請求項１３に記載のサーバ負荷管理方法であって、
前記（Ｃ１）ステップにおいて、前記判定結果が増加傾向であるサーバのうち前記ＣＰＵ使用率が最小であるサーバと、前記判定結果が減少傾向であるサーバのうち前記ＣＰＵ使用率が最小であるサーバとが抽出され、
前記（Ｄ）ステップにおいて、前記抽出されたサーバから前記修正後ＣＰＵ使用率が最小であるサーバが選択され、
前記サーバ負荷管理方法は、更に、（Ｅ）リクエストを前記選択されたサーバに送信するステップを含む
サーバ負荷管理方法。
【請求項１５】
請求項１３に記載のサーバ負荷管理方法であって、
前記（Ｃ１）ステップにおいて、前記判定結果が増加傾向であるサーバのうち前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの両方と、前記判定結果が減少傾向であるサーバのうち前記ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの両方が抽出され、
前記（Ｄ）ステップにおいて、前記抽出されたサーバから前記修正後ＣＰＵ使用率が最大である第１サーバと最小である第２サーバが選択され、
前記サーバ負荷管理方法は、更に、（Ｆ）前記第１サーバに割り当てられた処理のいくつかを前記第２サーバに移行するステップを含む
サーバ負荷管理方法。
【請求項１６】
複数のサーバの負荷の管理処理をコンピュータに実行させるサーバ負荷管理プログラムであって、
前記管理処理は、
（ａ）前記複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルを、記憶装置から読み出すステップと、
ここで、前記性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含み、
（ｂ）前記リクエストインデックスの時系列変化に基づいて、前記複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行うステップと、
（ｃ）前記ＣＰＵ使用率を前記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出するステップと
を含み、
前記判定結果が増加傾向の場合、前記ＣＰＵ使用率は上方修正され、
前記判定結果が減少傾向の場合、前記ＣＰＵ使用率は下方修正される
サーバ負荷管理プログラム。
【請求項１７】
請求項１６に記載のサーバ負荷管理プログラムであって、
前記（ｃ）ステップは、
（ｃ１）前記複数のサーバからいくつかのサーバを抽出するステップと、
（ｃ２）前記抽出されたサーバの各々に関して前記修正後ＣＰＵ使用率を算出するステップと
を含む
サーバ負荷管理プログラム。
【請求項１８】
請求項１７に記載のサーバ負荷管理プログラムであって、
前記管理処理は、更に、（ｄ）前記抽出されたサーバから前記修正後ＣＰＵ使用率が最大であるサーバ及び最小であるサーバの少なくとも１つを選択するステップを含む
サーバ負荷管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバの負荷を管理するための技術に関する。特に、本発明は、後処理を考慮して複数のサーバの負荷を管理するための技術に関する。
【背景技術】
【０００２】
複数のサーバから構成されるコンピュータシステムにおいて、各サーバの負荷を把握することは、サーバ管理、サーバへのリクエストの割り当て、サーバ負荷の分散などの観点から重要である。計算機システムにおける負荷分散に関連する技術として、次のものが知られている。
【０００３】
特許文献１（特開２００１−１０９６３８号公報）には、推定伸長率に基づくトランザクション負荷分散方法が記載されている。この方法によれば、一定時間ごとに、各計算機の処理中トランザクション数、およびＣＰＵ系に滞在するプロセス数またはＣＰＵ使用率が測定される。次に、これらの測定値を元に、各計算機における処理時間の伸長率が推定される。次に、この推定伸長率に基づいて、各計算機の負荷指標の値が求められる。そして、求められた負荷指標に基づいて、負荷の低い計算機へトランザクションの配分が行われる。
【０００４】
特許文献２（特開２０００−１１２９０９号公報）には、負荷分散管理システムが記載されている。処理履歴保存部は、各処理要求に対する処理履歴からなる処理履歴情報を記憶装置に保存する。処理先決定部は、処理要求元クライアントコンピュータからの処理要求が発生した場合に、当該処理要求に対する処理先サーバコンピュータを、処理履歴情報に基づいて決定する。処理要求管理部は、処理要求を処理先サーバコンピュータに転送し、当該処理先サーバコンピュータによる処理結果を当該処理要求元クライアントコンピュータに転送し、当該処理結果を反映した処理履歴を処理履歴保存部に転送する。
【０００５】
特許文献３（特開２００１−７５９３４号公報）には、負荷分散処理システムが記載されている。負荷レポート送信手段は、処理実行本体の負荷が高くなると負荷通知の発信間隔を長くし、負荷が低くなると発信間隔を短くする。負荷レポート受付手段は、負荷通知の受信間隔の長さから負荷率を算出し記録する。処理要求制御手段は、処理要求を受け付けて、選択された処理実行本体へ送信する。負荷調整手段は、負荷率を処理割り当て時の時刻で補正し、補正後の負荷率が最小な処理実行本体を選択する。
【０００６】
特許文献４（特開２００５−２８４６９５号公報）には、情報要求装置からネットワークを介してなされる情報要求に応じて生じる情報提供装置の負荷を分散する負荷分散装置が記載されている。資源情報収集手段は、情報提供装置の１または２以上の資源の使用情報を収集する。情報要求頻度操作手段は、情報要求装置から情報提供装置への情報要求頻度を操作する。反応係数算出手段は、操作による情報要求頻度の変化分と、操作した情報要求頻度に応じて動作した情報提供装置における使用情報の変化分とから、反応係数を算出する。
【０００７】
特許文献５（特開２００６−２５９８１２号公報）には、複数の計算機のキューに処理要求を振り分けて負荷分散を動的に行う動的キュー負荷分散方法が記載されている。その方法は、（１）計算機の負荷のレベルを示す負荷レベルを取得するステップと、（２）キュー管理テーブルのキューの長さを負荷レベルに対応するキューの長さへ変更するステップと、（３）キュー管理テーブル中のキューの長さ及び要求停滞数からキューの使用率を算出するステップと、（４）算出したキューの使用率の情報を通信装置により各計算機間で交換するステップと、（５）交換したキューの使用率に応じて処理要求を振り分けるステップと、を有する。
【０００８】
特許文献６（特開平１１−１１０３６０号公報）には、プロキシサーバ装置によるトランザクション分配方法が記載されている。プロキシサーバ装置は、過去のトランザクションサービスと応答時間の履歴から、トランザクション応答時間の分布を導出する。その導出された分布から、複数のサーバ装置の最大応答待ち時間がそれぞれ動的に決定される。プロキシサーバ装置は、決定された最大応答待ち時間に応じて、クライアント装置からのトランザクションリクエストをいずれかのサーバ装置に分配する。
【０００９】
【特許文献１】特開２００１−１０９６３８号公報
【特許文献２】特開２０００−１１２９０９号公報
【特許文献３】特開２００１−７５９３４号公報
【特許文献４】特開２００５−２８４６９５号公報
【特許文献５】特開２００６−２５９８１２号公報
【特許文献６】特開平１１−１１０３６０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
最近、コンピュータシステム上で動作するアプリケーションの中には「後処理」を行うものが多い。後処理とは、サーバがリクエストを処理し、ユーザあるいは前段階のサーバにレスポンスを返した後に、その処理に関連して行う処理のことである。
【００１１】
Ｗｅｂサーバ、アプリケーションサーバ及びデータベースサーバの３層構成を有するコンピュータシステムを例に挙げて、後処理を説明する。このコンピュータシステムでは、Ｗｅｂサーバがユーザからのリクエスト（処理要求）を受け取り、受け取ったリクエストをアプリケーションサーバに送る。アプリケーションサーバは、要求された処理を実行する。このとき、アプリケーションサーバは、処理実行に必要なデータをデータベースサーバに要求する。データベースサーバは、要求されたデータを求めて登録データベースを検索し、読み出したデータをアプリケーションサーバに提供する。アプリケーションサーバは、当該処理の結果をＷｅｂサーバに送る。ユーザはＷｅｂブラウザを利用し、Ｗｅｂサーバからその処理結果を取得する。これらＷｅｂサーバ、アプリケーションサーバ及びデータベースサーバのそれぞれにおいて、後処理が発生することがある。
【００１２】
Ｗｅｂサーバでは、ユーザにレスポンスを返した後に実行することが許容される処理がある。例えば、ユーザのアクセス終了時間の記録などである。このように、ユーザへのレスポンス送信後に行なわれる処理が、Ｗｅｂサーバにおける「後処理」である。
【００１３】
アプリケーションサーバは、Ｗｅｂサーバから受け取ったリクエストに応答するために必要な処理を行い、Ｗｅｂサーバにレスポンスを返す。Ｗｅｂサーバへのレスポンス送信後に実行が許容される処理が、アプリケーションサーバにおける「後処理」である。アプリケーションサーバで行われる後処理の例は、皆本房幸著、「ＪＢｏｓｓ入門」、技術評論社、ｐ．２０２に記載されている。この文献に記載されているように、アプリケーションサーバの実現の一形態であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎ）では、メッセージ駆動型Ｂｅａｎという機能を用いて「後処理」が行われる。
【００１４】
データベースサーバは、アプリケーションサーバから受け取ったリクエストに応答するために必要な処理を行い、アプリケーションサーバにレスポンスを返す。アプリケーションサーバへのレスポンス送信後に実行が許容される処理が、データベースサーバにおける「後処理」である。データベースサーバで行われる後処理の例は、次の論文に記載されている：A. Tanaka et al., “Capacity Planning for Client Server Database Systems: A Case Study”, Proceedings of the 1995 International Workshop on Computer Performance Measurement and Analysis, pp. 110-117。この論文は、データベースサーバＯｒａｃｌｅ（米国オラクル社の登録商標）の内部動作が、ユーザにレスポンスを返すＳｈａｄｏｗとＬＧＷプロセスと、それらとは非同期に実行されるＤＢｗｒｉｔｅｒｓとから構成されていることを開示している。
【００１５】
このような後処理が発生する場合、サーバ負荷の判定において次のような問題が生じる。例えば、あるサーバがリクエスト処理後にユーザあるいは前段階のサーバにレスポンスを返し、処理中リクエスト数が減少する場合を考える。その後に発生する後処理は、リクエストを処理したプロセスとは異なるプロセスが担当する。当該サーバがレスポンスを返した時点で、処理中リクエスト数が減少するため、サーバ負荷が減少していると判断される。しかしながら、実際には、後処理に伴う負荷に関しては、その後処理を担当するプロセス内で該当処理が終了するまで減少することにはならない。上述の関連技術では、この後処理に伴う負荷が考慮されていない。従って、サーバ負荷が適切に判断されているとは言えない。その結果、計算機システムを管理する上で、サーバ負荷を均等にすることができないという問題も生じる。
【００１６】
本発明の１つの目的は、後処理が発生する場合においてサーバ負荷を適切に判定することができる技術を提供することにある。
【課題を解決するための手段】
【００１７】
本発明の第１の観点において、複数のサーバの負荷を管理するサーバ負荷管理システムが提供される。そのサーバ負荷管理システムは、複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルが格納される記憶装置と、性能指標変化テーブルを参照してサーバ負荷を算出する処理装置と、を備える。性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含む。処理装置は、傾向判定部と負荷算出部とを有する。傾向判定部は、リクエストインデックスの時系列変化に基づいて、複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行う。負荷算出部は、ＣＰＵ使用率を判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出する。具体的には、判定結果が増加傾向の場合、負荷算出部はＣＰＵ使用率を上方修正する。一方、判定結果が減少傾向の場合、負荷算出部はＣＰＵ使用率を下方修正する。
【００１８】
本発明の第２の観点において、複数のサーバの負荷を管理するサーバ負荷管理方法が提供される。そのサーバ負荷管理方法は、（Ａ）複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルを、記憶装置から読み出すステップと、ここで、性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含み、（Ｂ）リクエストインデックスの時系列変化に基づいて、複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行うステップと、（Ｃ）ＣＰＵ使用率を上記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出するステップと、を含む。判定結果が増加傾向の場合、ＣＰＵ使用率は上方修正される。一方、判定結果が減少傾向の場合、ＣＰＵ使用率は下方修正される。
【００１９】
本発明の第３の観点において、複数のサーバの負荷の管理処理をコンピュータに実行させるサーバ負荷管理プログラムが提供される。その管理処理は、（ａ）複数のサーバの各々の性能指標の時系列変化を示す性能指標変化テーブルを、記憶装置から読み出すステップと、ここで、性能指標は、ＣＰＵ使用率と、処理中のリクエスト数の指標を与えるリクエストインデックスとを含み、（ｂ）リクエストインデックスの時系列変化に基づいて、複数のサーバの各々に関して処理中のリクエスト数が増加傾向か減少傾向かの判定を行うステップと、（ｃ）ＣＰＵ使用率を上記判定の結果に基づいて修正し、修正後ＣＰＵ使用率をサーバ負荷として算出するステップと、を含む。判定結果が増加傾向の場合、ＣＰＵ使用率は上方修正される。一方、判定結果が減少傾向の場合、ＣＰＵ使用率は下方修正される。
【発明の効果】
【００２０】
本発明によれば、計算機システムにおいて後処理が発生する場合でも、サーバ負荷を適切に判定することが可能となる。その結果、計算機システムにおいて適切な負荷分散が可能となる。
【発明を実施するための最良の形態】
【００２１】
添付図面を参照して、本発明の実施の形態に係るサーバ負荷管理システム、方法及びプログラムを説明する。
【００２２】
１．概要
本発明の実施の形態では、複数のサーバから構成される計算機システムに関して各サーバの負荷を管理するための技術が提供される。この計算機システムにおいて、各サーバは、ユーザあるいは前段のサーバからリクエスト（処理要求）を受け取り、要求された処理を実行する。リクエスト処理後、各サーバは、ユーザあるいは前段階のサーバにレスポンスを返す。このレスポンスの返信後に実行が許容される処理が「後処理」である。尚、後処理は、リクエストを処理したプロセスとは異なるプロセスによって実行される。
【００２３】
あるサーバがレスポンスを返した時点で、当該サーバにおける処理中リクエスト数は減少する。しかしながら、後処理が発生する場合、その後処理に伴う負荷に関しては、その後処理を担当するプロセス内で該当処理が終了するまで減少することにはならない。従って、当該サーバの負荷を適切に判定するためには、処理中リクエスト数だけでなく、後処理に伴う負荷をも考慮することが望ましい。本実施の形態の１つの目的は、後処理を考慮することによって、サーバ負荷をより正確に算出する（見積もる）ことである。
【００２４】
サーバ負荷は、例えば「ＣＰＵ使用率」で表される。ＣＰＵ使用率とは、ＣＰＵが単位時間あたりに処理を行う割合である。例えば、ＣＰＵが単位時間のうち３０％の時間だけ処理を行い、残りの７０％の時間はアイドル状態であったとき、ＣＰＵ使用率は０．３（３０％）である。
【００２５】
図１Ａは、あるサーバに関するＣＰＵ使用率と処理中リクエスト数との関係を概念的に示している。縦軸がＣＰＵ使用率Ｕを表し、横軸が処理中リクエスト数Ｃを表している。図１Ａ中の破曲線は、後処理が発生しない場合のＣＰＵ使用率Ｕと処理中リクエスト数Ｃとの関係を示している。例えばＭ／Ｍ／１型待ち行列モデルに従うと、その関係はＵ＝１−１／（Ｃ＋１）で表される。一般には、処理中リクエスト数Ｃが増加するにつれて、ＣＰＵ使用率Ｕも増加する。逆に、処理中リクエスト数Ｃが減少するにつれて、ＣＰＵ使用率Ｕも減少する。
【００２６】
図１Ａ中の矢印は、後処理が発生する場合のＣＰＵ使用率Ｕと処理中リクエスト数Ｃとの関係を概念的に示している。特に、右向きの矢印は、処理中リクエスト数Ｃが「増加傾向」にある場合を示し、左向きの矢印は、処理中リクエスト数Ｃが「減少傾向」にある場合を示している。図１Ａに示されるように、概して、減少傾向の場合のＣＰＵ使用率Ｕは、増加傾向の場合のＣＰＵ使用率Ｕよりも高い。これは、次のような理由によると考えられる。処理中リクエスト数Ｃが増加傾向にある場合、それまでに処理したリクエスト数は比較的少なく、後処理に伴う負荷も比較的小さい。従って、ＣＰＵ使用率Ｕが比較的低くなる。一方、処理中リクエスト数Ｃが減少傾向にある場合、それまでに処理したリクエスト数は比較的多く、後処理に伴う負荷が比較的大きい。従って、ＣＰＵ使用率Ｕが比較的高くなる。
【００２７】
このように、増加傾向の場合と減少傾向の場合とでは、同じＣＰＵ使用率Ｕを与える処理中リクエスト数Ｃが異なっている。言い換えれば、処理中リクエスト数Ｃが同じであったとしても、増加傾向の場合と減少傾向の場合とではＣＰＵ使用率Ｕが異なる。すなわち、後処理が発生する場合は、処理中リクエスト数Ｃから単純にサーバ負荷（ＣＰＵ使用率）を算出することはできないのである。サーバ負荷を適切に算出するためには、処理中リクエスト数Ｃが増加傾向にあるか減少傾向にあるかを認識することが重要である。
【００２８】
そこで、本実施の形態では、各サーバから、ＣＰＵ使用率Ｕと共に処理中リクエスト数Ｃに関する情報が継続的に収集される。そして、処理中リクエスト数Ｃの時系列変化に基づいて、処理中リクエスト数Ｃが増加傾向か減少傾向かの判定が行われる。更に、その判定結果に基づいて、ＣＰＵ使用率Ｕの修正（補正）が行われる。このときの修正方針として、本願発明者は次のものを考え出した。
【００２９】
まず、処理中リクエスト数Ｃが増加傾向にある場合を考える。この場合、上述の通り、それまでに処理したリクエスト数は比較的少なく、後処理に伴う負荷も現在のところは比較的小さい。しかしながら、処理中リクエスト数Ｃが増加傾向にあるということは、後処理に伴う負荷が将来的に増大することを意味する。言い換えれば、後処理の増大によって、将来的にはＣＰＵ使用率Ｕがより高くなる確率が極めて高い。従って、後処理に伴う負荷の増大を見込んで、ＣＰＵ使用率Ｕはより高い方に修正される。すなわち、ＣＰＵ使用率Ｕは「上方修正」される。
【００３０】
次に、処理中リクエスト数Ｃが減少傾向にある場合を考える。この場合、上述の通り、それまでに処理したリクエスト数は比較的多く、後処理に伴う負荷は現在のところは比較的大きい。しかしながら、処理中リクエスト数Ｃが減少傾向にあるということは、後処理に伴う負荷が将来的に減少することを意味する。言い換えれば、後処理の減少によって、将来的にはＣＰＵ使用率Ｕがより低くなる確率が極めて高い。従って、後処理に伴う負荷の減少を見込んで、ＣＰＵ使用率Ｕはより低い方に修正される。すなわち、ＣＰＵ使用率Ｕは「下方修正」される。
【００３１】
このように、本実施の形態によれば、後処理に伴う負荷を考慮することによって、各サーバから通知されるＣＰＵ使用率Ｕの修正（補正）が実施される。修正により得られるＣＰＵ使用率は、以下「修正後ＣＰＵ使用率Ｕ’」と参照される。この修正後ＣＰＵ使用率Ｕ’が、修正前のＣＰＵ使用率Ｕよりも正確なサーバ負荷として扱われる。
【００３２】
尚、処理中リクエスト数Ｃが増加傾向か減少傾向かを判断するにあたり、処理中リクエスト数Ｃそのもの以外のパラメータを用いることも可能である。
【００３３】
例えば、図１Ｂは、あるサーバに関するＣＰＵ使用率と単位時間あたりのリクエスト到着数との関係を概念的に示している。縦軸がＣＰＵ使用率Ｕを表し、横軸が単位時間あたりのリクエスト到着数λを表している。図１Ｂ中の破曲線は、後処理が発生しない場合の関係を示しており、例えばＵ＝λ／μで表される。μは、ＣＰＵの単位時間あたりの最大処理数である。また、図１Ｂ中の矢印は、後処理が発生する場合の関係を概念的に示している。右向きの矢印は、リクエスト到着数λが増加傾向にある場合を示し、左向きの矢印は、リクエスト到着数λが減少傾向にある場合を示している。この図１Ｂで示される特性も、図１Ａで示された特性と同様であることに留意されたい。従って、リクエスト到着数λが増加傾向か減少傾向かを判定することは、処理中リクエスト数Ｃが増加傾向か減少傾向かを判定することと同じ意味を持つ。すなわち、リクエスト到着数λの時系列変化に基づいて、処理中リクエスト数Ｃが増加傾向か減少傾向かの判定が可能である。
【００３４】
その他、到着リクエストが格納されるキュー（待ち行列）の長さや、リクエストを処理するためのプロセス数を同様に用いることも可能である。更に、リクエスト到着数とリクエスト退去数（レスポンスが返されたリクエストの数）の組み合わせが用いられてもよい。ある時点までのリクエスト到着数の総和から、その時点までのリクエスト退去数の総和を引くことによって、処理中リクエスト数Ｃを見積もることができる。
【００３５】
以上に説明されたパラメータは、以下「リクエストインデックスＲＩ」と参照される。リクエストインデックスＲＩは、処理中のリクエスト数Ｃの指標を与えるパラメータである。リクエストインデックスＲＩとしては、上述の処理中リクエスト数Ｃそのもの、サーバへの単位時間あたりのリクエスト到着数λ、到着リクエストが格納されるキュー（待ち行列）の長さ、リクエストを処理するためのプロセス数、リクエスト到着数λとリクエスト退去数の組み合わせなどが挙げられる。このようなリクエストインデックスＲＩの時系列変化に基づいて、処理中リクエストＣが増加傾向か減少傾向かの判定を行うことが可能である。
【００３６】
以上に説明された処理を実現するためのサーバ負荷管理システム及びその動作を、以下詳細に説明する。
【００３７】
２．構成
図２は、本実施の形態に係るサーバ負荷管理システム１の構成例を示すブロック図である。サーバ負荷管理システム１は、ネットワークを介して複数のサーバ１００−１〜１００−ｎと通信可能に接続されたコンピュータであり、複数のサーバ１００−１〜１００−ｎのそれぞれの負荷を管理する。サーバ１００の台数はｎ台である（ｎは１以上の整数）。
【００３８】
例えば、各サーバ１００は、Ｗｅｂサーバ、アプリケーションサーバ、あるいはデータベースサーバである。Ｗｅｂサーバの場合、各サーバ１００は、ユーザからのリクエストを、ユーザから直接あるいは負荷分散装置などを経由して受け取り、必要な処理を実行し、処理結果（レスポンス）をユーザに返す。アプリケーションサーバの場合、各サーバ１００は、前段のＷｅｂサーバからリクエストを受け取り、必要な処理を実行し、処理結果（レスポンス）をＷｅｂサーバに返す。データベースサーバの場合、各サーバ１００は、前段のアプリケーションサーバからリクエスト（データベース処理要求）を受け取り、必要な処理を実行し、処理結果（レスポンス）をアプリケーションサーバに返す。いずれの場合でも、各サーバ１００は、何らかのリクエストを受け取り、そのリクエストに対するレスポンスを返す。そして、レスポンスの返信後に「後処理」が発生する。
【００３９】
各サーバ１００は、自身の「性能指標」を計測するための監視部１１０を有している。性能指標は、各サーバ１００におけるＣＰＵ使用率Ｕと上述のリクエストインデックスＲＩを含んでいる。例えば、性能指標は、ＣＰＵ使用率Ｕと処理中リクエスト数Ｃである。このような性能指標は、ＵＮＩＸ（登録商標）（もしくはＬｉｎｕｘ）オペレーティングシステムで用意されている“ｓｙｓｓｔａｔ”、“ｖｍｓｔａｔ”、“ｔｏｐ”などのコマンドを用いることにより計測することができる。あるいは、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの場合、“パフォーマンスモニタ”を用いることにより性能指標を計測することができる。各サーバ１００は、監視部１１０を用いて性能指標を計測し、得られた性能指標と計測時刻を示す性能指標データＰＩをサーバ負荷管理システム１に逐次送信する。
【００４０】
図２に示されるように、本実施の形態に係るサーバ負荷管理システム１は、処理装置２、記憶装置３、通信装置４、入力装置５及び出力装置６を備えている。処理装置２はＣＰＵを含んでおり、各種データ処理を行う。記憶装置３として、ＨＤＤ（Hard Disk Drive）やＲＡＭ（Random Access Memory）等が例示される。通信装置４は、ネットワークに接続されるネットワークインタフェースである。入力装置５として、キーボード、マウス、メディアドライブ等が例示される。出力装置６として、ディスプレイ等が例示される。
【００４１】
記憶装置３には、性能指標変化テーブルＴＢＬ、サーバグループ管理リストＧＲＰなどが格納される。性能指標変化テーブルＴＢＬは、各サーバ１００の性能指標の時系列変化を示すテーブルであり、その詳細は後述される。サーバグループ管理リストＧＲＰは、各サーバをグループ分けして示すリストであり、その詳細は後述される。
【００４２】
処理装置２は、記憶装置３に格納された性能指標変化テーブルＴＢＬを参照して、サーバ負荷を算出する。より詳細には、処理装置２は、サーバ負荷判定プログラムＰＲＯＧ１を実行することにより、サーバ負荷算出処理を行う。サーバ負荷判定プログラムＰＲＯＧ１は、処理装置２によって実行されるソフトウェアプログラムである。典型的には、サーバ負荷判定プログラムＰＲＯＧ１は、コンピュータ読み取り可能な記録媒体に記録されている。処理装置２は、その記録媒体からサーバ負荷判定プログラムＰＲＯＧ１を読み出し、実行する。
【００４３】
図３は、本実施の形態に係る処理装置２の機能を示すブロック図である。図３に示されるように、処理装置２は、性能指標蓄積部１０、傾向判定部２０、サーバ負荷算出部３０、及びサーバ選択部４０を有している。これら性能指標蓄積部１０、傾向判定部２０、サーバ負荷算出部３０、及びサーバ選択部４０は、処理装置２とサーバ負荷判定プログラムＰＲＯＧ１との協働によって実現され、それぞれ所定の機能を提供する。以下、本実施の形態に係るサーバ負荷管理システム１（処理装置２）による処理を詳細に説明する。
【００４４】
３．処理フロー
図４は、本実施の形態に係るサーバ負荷管理システム１による処理を示すフローチャートである。図２〜図４を適宜参照して、本実施の形態に係る処理フローを詳しく説明する。
【００４５】
ステップＳ１０：
各サーバ１００の監視部１１０は、自身の性能指標を所定の時間間隔で測定する。性能指標は、ＣＰＵ使用率Ｕと上述のリクエストインデックスＲＩを含んでいる。そして、各サーバ１００は、得られた性能指標とその測定時刻を示す性能指標データＰＩを、サーバ負荷管理システム１に逐次送信する。サーバ負荷管理システム１の通信装置４は、各サーバ１００から送られてくる性能指標データＰＩを受け取る。性能指標蓄積部１０は、受け取った性能指標データＰＩを、記憶装置３中の性能指標変化テーブルＴＢＬに登録する。
【００４６】
図５Ａは、本実施の形態に係る性能指標変化テーブルＴＢＬを概念的に示している。図５Ａに示されるように、性能指標変化テーブルＴＢＬは、測定時刻（あるいはサーバ負荷管理システム１の受信時刻）と性能指標（ＣＰＵ使用率Ｕ、リクエストインデックスＲＩ）を示している。つまり、性能指標変化テーブルＴＢＬは、性能指標の時系列変化を示している。このような性能指標変化テーブルＴＢＬは、サーバ１００毎に作成される。
【００４７】
図５Ｂは、リクエストインデックスＲＩが処理中リクエスト数Ｃである場合の、あるサーバ１００に関する性能指標変化テーブルＴＢＬの例を示している。図５Ｂに示されるように、性能指標変化テーブルＴＢＬは、当該サーバ１００のＣＰＵ使用率Ｕ及び処理中リクエスト数Ｃの時系列変化を示している。例えば、時刻Ｔ１において、ＣＰＵ使用率はＵ１であり処理中リクエスト数はＣ１であり、直近の時刻Ｔｓのおいて、ＣＰＵ使用率はＵｓであり処理中リクエスト数はＣｓである。新たに受け取る性能指標データＰＩは、テーブルの次の行に追記される。
【００４８】
ステップＳ１５：
サーバ負荷の算出処理は、所定のタイミング毎に実施される。そのタイミングまでは、ステップＳ１０が繰り返され、性能指標変化テーブルＴＢＬにデータが蓄積される。所定のタイミングになると、次のステップＳ２０が実行される。
【００４９】
ステップＳ２０：
傾向判定部２０は、各サーバ１００に関して、処理中リクエスト数Ｃが増加傾向か減少傾向かの判定を行う。この判定にあたり、傾向判定部２０は、記憶装置３に格納された性能指標変化テーブルＴＢＬで示されるリクエストインデックスＲＩの時系列変化を参照することができる。つまり、傾向判定部２０は、リクエストインデックスＲＩの時系列変化に基づいて、各サーバ１００の処理中リクエスト数Ｃの変化傾向を判定する。そして、傾向判定部２０は、その判定結果に基づいて、サーバ１００−１〜１００−ｎのそれぞれをグループ分けする。上記判定結果、すなわち、処理中リクエスト数Ｃの変化傾向に応じて、次の３種類のサーバグループが考えられる。
【００５０】
（１）サーバグループＺ：処理中リクエスト数Ｃが増加傾向にある
（２）サーバグループＧ：処理中リクエスト数Ｃが減少傾向にある
（３）サーバグループＥ：それ以外
【００５１】
記憶装置３中のサーバグループ管理リストＧＲＰは、このようなサーバのグループ分けを示す。つまり、サーバグループ管理リストＧＲＰは、サーバグループ（Ｚ，Ｇ，Ｅ）のそれぞれに属しているサーバのリストを示す。尚、サーバグループＥは、必ずしも設定されなくてもよく、必要に応じて設定されればよい。
【００５２】
図６は、本ステップＳ２０における処理フローの一例を示している。まず、初期化が行われる（ステップＳ２１）。具体的には、サーバグループ管理リストＧＲＰが初期化され、全てのサーバグループが空に設定される。また、判定対象のサーバ番号ｉが１に初期化される。サーバ番号ｉが取り得る値は、１からｎ（サーバ総数）までである。その後、判定対象のサーバ１００−ｉに関して、次の処理が実施される。
【００５３】
ステップＳ２２：
まず、傾向判定部２０は、記憶装置３に格納された性能指標変化テーブルＴＢＬから、サーバ１００−ｉに関する性能指標を読み出す。ここでは、性能指標は、ＣＰＵ使用率Ｕと処理中リクエスト数Ｃであるとする。サーバ１００−ｉに関して、次の（ｋ＋１）種類の時刻のそれぞれにおける性能指標が読み出される。ｋは１以上の整数である。
【００５４】
時刻Ｔｐ：ＣＰＵ使用率Ｕｐ，処理中リクエスト数Ｃｐ
時刻Ｔｐ−１：ＣＰＵ使用率Ｕｐ−１，処理中リクエスト数Ｃｐ−１
・・・
時刻Ｔｐ−（ｋ−１）：ＣＰＵ使用率Ｕｐ−（ｋ−１），処理中リクエスト数Ｃｐ−（ｋ−１）
時刻Ｔｐ−ｋ：ＣＰＵ使用率Ｕｐ−ｋ，処理中リクエスト数Ｃｐ−ｋ
【００５５】
時刻Ｔｐは現在時刻に最も近い時刻であり、パラメータｋが大きくなるにつれて時刻は過去に遡る。パラメータｋは、ユーザによってあらかじめ指定されている。典型的にはパラメータｋは１に設定され（ｋ＝１）、その場合、直近の時刻Ｔｐとその前の時刻Ｔｐ−１のそれぞれにおける性能指標が読み出される。
【００５６】
ステップＳ２３：
次に、傾向判定部２０は、読み出された処理中リクエスト数Ｃｐ〜Ｃｐ−ｋ（リクエストインデックスＲＩ）の時系列変化に基づいて、サーバ１００−ｉの処理中リクエスト数Ｃの変化率Ｖを算出する。そのために、傾向判定部２０は、時刻Ｔｐ−ｊ〜Ｔｐ−（ｊ−１）間での処理中リクエスト数Ｃの単位変化率Ｖｊをそれぞれ算出する（ｊは、１〜ｋの整数）。単位変化率Ｖｊは、次の式（１）で表される。
【００５７】
【数１】
2009252050.tif 000003
【００５８】
更に、傾向判定部２０は、算出されたそれぞれの単位変化率Ｖｊの平均値を変化率Ｖとして算出する。処理中リクエスト数Ｃの変化率Ｖは、次の式（２）で表される。
【００５９】
【数２】
2009252050.tif 000004
【００６０】
変化率Ｖは、単位変化率Ｖｊの重み付け平均であってもよい。この場合、予め指定された重み付けパラメータβｊを用いることにより、変化率Ｖは次の式（３）で表される。
【００６１】
【数３】
2009252050.tif 000005
【００６２】
パラメータｋが１の場合、あるいは、時間間隔Ｔｐ−（ｊ−１）−Ｔｐ−ｊが一定の場合には、単位変化率Ｖｊは次の式（４）で定義されてもよい。
【００６３】
【数４】
2009252050.tif 000006
【００６４】
ステップＳ２４：
次に、傾向判定部２０は、ステップＳ２３で算出された処理中リクエスト数Ｃの変化率Ｖに基づいて、サーバ１００−ｉのグループ分けを行う。例えば、傾向判定部２０は、変化率Ｖを所定の閾値と比較する。変化率Ｖが所定の正の閾値ε以上である場合、傾向判定部２０は、処理中リクエスト数Ｃが増加傾向にあると判定する。従って、傾向判定部２０は、サーバ１００−ｉを、サーバグループ管理リストＧＲＰ中のサーバグループＺに登録する。一方、変化率Ｖが所定の負の閾値−ε以下である場合、傾向判定部２０は、処理中リクエスト数Ｃが減少傾向にあると判定する。従って、傾向判定部２０は、サーバ１００−ｉを、サーバグループ管理リストＧＲＰ中のサーバグループＧに登録する。それ以外の場合、傾向判定部２０は、サーバ１００−ｉを、サーバグループ管理リストＧＲＰ中のサーバグループＥに登録する。
【００６５】
尚、上記閾値（ε，−ε）は、ユーザによってあらかじめ指定される微少量である。閾値（ε，−ε）は０であってもよく、その場合、サーバグループＥは設定されない。
【００６６】
ステップＳ２５，Ｓ２６：
現在のサーバ番号ｉがサーバ総数ｎと等しくない場合（ステップＳ２５；Ｎｏ）、サーバ番号ｉに１が加算され、次のサーバ１００−ｉが選択される（ステップＳ２６）。その後、ステップＳ２２〜Ｓ２４が同様に行われる。現在のサーバ番号ｉがサーバ総数ｎと等しい場合（ステップＳ２５；Ｙｅｓ）、ステップＳ２０は終了する。このようにして、全てのサーバ１００−１〜１００−ｎのグルーピングが完了し、サーバグループ管理リストＧＲＰが完成する。
【００６７】
図７Ａは、ステップＳ２０で作成されるサーバグループ管理リストＧＲＰの一例を示している。ここでは、サーバ総数ｎは５である。サーバグループＺ（増加傾向）は、サーバ１００−２とサーバ１００−３を含んでいる。サーバグループＧ（減少傾向）は、サーバ１００−１とサーバ１００−５を含んでいる。サーバグループＥ（それ以外）は、サーバ１００−４を含んでいる。
【００６８】
また、図７Ｂに示されるように、サーバグループ管理リストＧＲＰは、サーバ１００−１〜１００−５のそれぞれのＣＰＵ使用率Ｕ（１）〜Ｕ（５）を示していてもよい。ここで示されるＣＰＵ使用率Ｕ（１）〜Ｕ（５）の各々は、直近の時刻ＴｐでのＣＰＵ使用率Ｕｐ、あるいは、所定期間内でのＣＰＵ使用率の平均値である。所定期間内でのＣＰＵ使用率の平均値は、例えば、本ステップＳ２０で性能指標変化テーブルＴＢＬから読み出されたＣＰＵ使用率Ｕｐ〜Ｕｐ−ｋの平均値である。
【００６９】
ステップＳ３０：
サーバ負荷算出部３０は、サーバ負荷を算出（推定）する。より詳細には、サーバ負荷算出部３０は、上記ステップＳ２０での判定結果に応じてＣＰＵ使用率Ｕを修正（補正）し、修正後ＣＰＵ使用率Ｕ’を算出する。その修正後ＣＰＵ使用率Ｕ’が、サーバ負荷の推定値となる。
【００７０】
上記ステップＳ２０での判定結果、すなわち、各サーバ１００のグループ分けは、記憶装置３に格納されたサーバグループ管理リストＧＲＰを参照することにより得られる。修正対象のＣＰＵ使用率Ｕは、直近の時刻ＴｐでのＣＰＵ使用率Ｕｐ、あるいは、所定期間内でのＣＰＵ使用率の平均値である。そのような修正対象のＣＰＵ使用率Ｕは、記憶装置２に格納されている性能指標変化テーブルＴＢＬを参照することにより得ることができる。あるいは、図７Ｂで示されたようなサーバグループ管理リストＧＲＰが作成されている場合、性能指標変化テーブルＴＢＬを参照することなく、修正対象のＣＰＵ使用率Ｕを得ることができる。
【００７１】
まず、サーバグループＺに関するＣＰＵ使用率Ｕの修正を考える。サーバグループＺに含まれるサーバの処理中リクエスト数Ｃは増加傾向にある。処理中リクエスト数Ｃが増加傾向にあるということは、後処理に伴う負荷が将来的に増大することを意味する。言い換えれば、後処理の増大によって、将来的にはＣＰＵ使用率Ｕがより高くなる確率が極めて高い。従って、後処理に伴う負荷の増大を見込んで、サーバ負荷算出部３０は、ＣＰＵ使用率Ｕを「上方修正」する。
【００７２】
例えば、サーバ負荷算出部３０は、所定の比率だけＣＰＵ使用率Ｕを上方修正することができる。その所定の比率は、後処理が含まれない場合の負荷と後処理も含めた場合の負荷との間の比率を反映していることが望ましい。サーバがリクエストを受け取ってからレスポンスを返すまでのリクエスト処理に使われるＣＰＵ時間は“ｓ１”であるとする。また、サーバが当該レスポンスを返した後の後処理に使われるＣＰＵ時間は“ｓ２”であるとする。このとき、係数α＝ｓ１／（ｓ１＋ｓ２）は、後処理が含まれない場合の負荷と後処理も含めた場合の負荷との間の比率を反映していると言える。よって、サーバ負荷算出部３０は、ＣＰＵ使用率Ｕを係数α（＜１）で割ることによって、ＣＰＵ使用率Ｕを上方修正することができる。係数αは、ユーザによって予め指定されるとよい。サーバグループＺに含まれるあるサーバｉのＣＰＵ使用率はＵＺ（ｉ）であるとする。また、上方修正によって得られる修正後ＣＰＵ使用率はＵＺ’（ｉ）であるとする。このとき、修正後ＣＰＵ使用率ＵＺ’（ｉ）は、次の式（５）で与えられる。
【００７３】
【数５】
2009252050.tif 000007
【００７４】
次に、サーバグループＧに関するＣＰＵ使用率Ｕの修正を考える。サーバグループＧに含まれるサーバの処理中リクエスト数Ｃは減少傾向にある。処理中リクエスト数Ｃが減少傾向にあるということは、後処理に伴う負荷が将来的に減少することを意味する。言い換えれば、後処理の減少によって、将来的にはＣＰＵ使用率Ｕがより低くなる確率が極めて高い。従って、後処理に伴う負荷の減少を見込んで、サーバ負荷算出部３０は、ＣＰＵ使用率Ｕを「下方修正」する。
【００７５】
例えば、サーバ負荷算出部３０は、所定の比率だけＣＰＵ使用率Ｕを下方修正することができる。その所定の比率は、後処理が含まれない場合の負荷と後処理も含めた場合の負荷との間の比率を反映していることが望ましい。例えば、上述の係数α＝ｓ１／（ｓ１＋ｓ２）が用いられる。サーバ負荷算出部３０は、ＣＰＵ使用率Ｕに係数α（＜１）を掛けることによって、ＣＰＵ使用率Ｕを下方修正することができる。サーバグループＧに含まれるあるサーバｉのＣＰＵ使用率はＵＧ（ｉ）であるとする。また、下方修正によって得られる修正後ＣＰＵ使用率はＵＧ’（ｉ）であるとする。このとき、修正後ＣＰＵ使用率ＵＧ’（ｉ）は、次の式（６）で与えられる。
【００７６】
【数６】
2009252050.tif 000008
【００７７】
それ以外のサーバグループＥに関して、サーバ負荷算出部３０は特に修正を行わない。サーバグループＥに含まれるあるサーバｉのＣＰＵ使用率はＵＥ（ｉ）であるとする。便宜上、修正後ＣＰＵ使用率ＵＥ’（ｉ）を考えると、その修正後ＣＰＵ使用率ＵＥ’（ｉ）は、次の式（７）で与えられる。
【００７８】
【数７】
2009252050.tif 000009
【００７９】
尚、サーバ負荷算出部３０は、サーバ１００−１〜１００−ｎの全てに関してＣＰＵ使用率Ｕの修正を行ってもよいし、そうでなくてもよい。サーバ負荷算出部３０は、サーバ１００−１〜１００−ｎからいくつかのサーバ１００を抽出し、抽出された各サーバ１００に関してＣＰＵ使用率Ｕの修正を行うことができる。例えば、サーバ負荷算出部３０は、サーバグループ管理リストＧＲＰを参照して、サーバグループ（Ｚ，Ｇ，Ｅ）の各々から少なくとも１つのサーバ１００を抽出することができる。また、負荷分散処理では、サーバ負荷が最大である「最大負荷サーバ」や、サーバ負荷が最小である「最小負荷サーバ」を見つけ出すことがとりわけ重要である。従って、サーバ１００−１〜１００−ｎの全てに関してＣＰＵ使用率Ｕの修正を行う必要は必ずしもない。ＣＰＵ使用率Ｕが最大あるいは最小であるサーバに着目し、そのサーバに関してＣＰＵ使用率Ｕの修正を行えば十分である場合もある。
【００８０】
本実施の形態が負荷分散処理へ適用される場合、例えば次のようなサーバ抽出が好適である。サーバ負荷算出部３０は、ＣＰＵ使用率ＵとステップＳ２０での判定結果（サーバグループ管理リストＧＲＰ）に基づいて、サーバ１００−１〜１００−ｎからいくつかのサーバを抽出する。具体的には、サーバ負荷算出部３０は、サーバグループ管理リストＧＲＰで示されるサーバグループ（Ｚ，Ｇ，Ｅ）の各々から、ＣＰＵ使用率Ｕが最大であるサーバ及びＣＰＵ使用率Ｕが最小であるサーバのうち少なくとも一方を抽出する。ここでのＣＰＵ使用率Ｕは、上述の修正対象のＣＰＵ使用率Ｕと同じであり、性能指標変化テーブルＴＢＬあるいは図７Ｂで示されたサーバグループ管理リストＧＲＰを参照することにより得られる。そして、サーバ負荷算出部３０は、抽出された各サーバに関してＣＰＵ使用率Ｕを修正し、修正後ＣＰＵ使用率Ｕ’をサーバ負荷として算出する。
【００８１】
以上に説明されたステップＳ３０の結果、すなわち、算出された修正後ＣＰＵ使用率Ｕ’は、ディスプレイ（出力装置６）に表示されてもよい。ユーザは、その表示を参照することにより、後処理に伴う負荷が考慮された正確なサーバ負荷を把握することができる。また、ユーザは、入力装置５を用いて、修正後ＣＰＵ使用率Ｕ’（サーバ負荷）の分析を行うこともできる。
【００８２】
ステップＳ４０：
サーバ選択部４０は、ステップＳ３０で抽出されたサーバ（修正後ＣＰＵ使用率Ｕ’が算出されたサーバ）から、所定の条件に合うサーバを選択する。例えば、サーバ選択部４０は、ステップＳ３０で抽出されたサーバから、「最大負荷サーバ」及び「最小負荷サーバ」の少なくとも１つを選択する。ここで、最大負荷サーバは、修正後ＣＰＵ使用率Ｕ’が最大であるサーバであり、最小負荷サーバは、修正後ＣＰＵ使用率Ｕ’が最小であるサーバである。最大負荷サーバが選択される場合、先行するステップＳ３０において、サーバグループ（Ｚ，Ｇ，Ｅ）の各々からＣＰＵ使用率Ｕが最大であるサーバが少なくとも抽出されていることが望ましい。最小負荷サーバが選択される場合、先行するステップＳ３０において、サーバグループ（Ｚ，Ｇ，Ｅ）の各々からＣＰＵ使用率Ｕが最小であるサーバが少なくとも抽出されていることが望ましい。
【００８３】
ステップＳ４０において最大負荷サーバ及び／あるいは最小負荷サーバを選択することは、負荷分散処理に有用である。ステップＳ４０の結果、すなわち、選択されたサーバは、ディスプレイ（出力装置６）に表示されてもよい。ユーザは、その表示を参照することにより、最大負荷サーバや最小負荷サーバを把握することができる。
【００８４】
４．効果
以上に説明されたように、本実施の形態によれば、処理中リクエスト数Ｃが増加傾向か減少傾向かの判定が行われ、その判定結果に基づいてＣＰＵ使用率Ｕの修正が行われる。これにより、後処理に伴う負荷が、サーバ負荷の推定値に適切に組み込まれる。つまり、計算機システムにおいて後処理が発生する場合のサーバ負荷をより正確に算出することが可能となる。後処理を考慮することによってサーバ負荷が適切に算出されるため、最小負荷サーバ及び／あるいは最大負荷サーバを正しく決定することができる。結果として、計算機システムにおいて適切な負荷分散が可能となる。
【００８５】
５．第１の応用例（リクエストの割り当て）
本実施の形態は、サーバへのリクエストの割り当て（振り分け）に応用することができる。図８は、既出のサーバ負荷判定処理に加えてリクエスト割当処理を行うための構成例を示している。既出の図２と同じ構成には同一の符号が付され、重複する説明は適宜省略される。
【００８６】
図８に示されるように、サーバ負荷管理システム１Ａは、新規リクエストＲＥＱを受け取り、その新規リクエストＲＥＱを複数のサーバ１００−１〜１００−ｎのうち適切な１台のサーバ１００に割り当てる。特に、サーバ負荷管理システム１Ａは、複数のサーバ１００−１〜１００−ｎのうち最小負荷サーバを選択し、選択された最小負荷サーバに新規リクエストＲＥＱを割り当てる。
【００８７】
より詳細には、サーバ負荷管理システム１Ａの処理装置２は、サーバ負荷判定プログラムＰＲＯＧ１と共にリクエスト割当プログラムＰＲＯＧ２を実行する。リクエスト割当プログラムＰＲＯＧ２は、処理装置２によって実行されるソフトウェアプログラムである。典型的には、リクエスト割当プログラムＰＲＯＧ２は、コンピュータ読み取り可能な記録媒体に記録されている。処理装置２は、その記録媒体からリクエスト割当プログラムＰＲＯＧ２を読み出し、実行する。
【００８８】
図９は、本例に係る処理装置２の機能を示すブロック図である。図９に示されるように、処理装置２は、既出の性能指標蓄積部１０、傾向判定部２０、サーバ負荷算出部３０及びサーバ選択部４０に加えて、リクエスト割当部５０を有している。リクエスト割当部５０は、処理装置２とリクエスト割当プログラムＰＲＯＧ２との協働によって実現される。
【００８９】
図１０は、本例に係るサーバ負荷管理システム１Ａによる処理を示すフローチャートである。ステップＳ１０〜Ｓ４０は、既出の実施の形態と同様である。但し、ステップＳ３０においてサーバ負荷算出部３０によって抽出されるサーバは、各サーバグループ（Ｚ，Ｇ，Ｅ）のうちＣＰＵ使用率Ｕが最小であるサーバを含んでいる。つまり、サーバ負荷算出部３０は、少なくとも、サーバグループＺからＣＰＵ使用率Ｕが最小であるサーバを抽出し、サーバグループＧからＣＰＵ使用率Ｕが最小であるサーバを抽出し、サーバグループＥからＣＰＵ使用率Ｕが最小であるサーバを抽出する。そして、サーバ負荷算出部３０は、抽出されたサーバの各々に関して修正後ＣＰＵ使用率Ｕ’を算出する。また、ステップＳ４０において、サーバ選択部４０は、上記抽出されたサーバから、修正後ＣＰＵ使用率Ｕ’が最小である最小負荷サーバを選択する。
【００９０】
ステップＳ５０において、リクエスト割当部５０は、新規リクエストＲＥＱを受け取る。そして、リクエスト割当部５０は、その新規リクエストＲＥＱを、ステップＳ４０において選択された最小負荷サーバに割り当てる。そして、リクエスト割当部５０は、新規リクエストＲＥＱをその最小負荷サーバに送信する。図８で示された例では、最小負荷サーバはサーバ１００−２である。ステップＳ４０において選択される最小負荷サーバは、時間経過とともに更新される。それに伴い、新規リクエストＲＥＱが送信される最小負荷サーバも変化する。結果として、複数のサーバ１００−１〜１００−ｎ間での負荷分散が実現される。
【００９１】
本実施の形態によれば、後処理に伴う負荷を考慮して、最小負荷サーバが正しく選択される。これを利用することによって、後処理に伴う負荷をも考慮した適切な負荷分散が可能となる。尚、サーバ負荷判定処理（ステップＳ１０〜Ｓ４０）とリクエスト割当処理（ステップＳ５０）は、別々の装置（コンピュータ）により実行されてもよい。
【００９２】
６．第２の応用例（サーバ間の処理の移行）
本実施の形態は、サーバ間の処理の移行に応用することもできる。図１１は、既出のサーバ負荷判定処理に加えて移行処理を行うための構成例を示している。既出の図２と同じ構成には同一の符号が付され、重複する説明は適宜省略される。
【００９３】
本例において、サーバ負荷管理システム１Ｂの処理装置２は、サーバ負荷判定プログラムＰＲＯＧ１と共に処理移行プログラムＰＲＯＧ３を実行する。処理移行プログラムＰＲＯＧ３は、処理装置２によって実行されるソフトウェアプログラムである。典型的には、処理移行プログラムＰＲＯＧ３は、コンピュータ読み取り可能な記録媒体に記録されている。処理装置２は、その記録媒体から処理移行プログラムＰＲＯＧ３を読み出し、実行する。
【００９４】
図１２は、本例に係る処理装置２の機能を示すブロック図である。図１２に示されるように、処理装置２は、既出の性能指標蓄積部１０、傾向判定部２０、サーバ負荷算出部３０及びサーバ選択部４０に加えて、処理移行部６０を有している。処理移行部６０は、処理装置２と処理移行プログラムＰＲＯＧ３との協働によって実現される。
【００９５】
図１３は、本例に係るサーバ負荷管理システム１Ｂによる処理を示すフローチャートである。ステップＳ１０〜Ｓ４０は、既出の実施の形態と同様である。但し、ステップＳ３０においてサーバ負荷算出部３０によって抽出されるサーバは、各サーバグループ（Ｚ，Ｇ，Ｅ）のうちＣＰＵ使用率Ｕが最大であるサーバと最小であるサーバの両方を含んでいる。つまり、サーバ負荷算出部３０は、少なくとも、サーバグループＺからＣＰＵ使用率Ｕが最大であるサーバと最小であるサーバを抽出し、サーバグループＧからＣＰＵ使用率Ｕが最大であるサーバと最小であるサーバを抽出し、サーバグループＥからＣＰＵ使用率Ｕが最大であるサーバと最小であるサーバを抽出する。そして、サーバ負荷算出部３０は、抽出されたサーバの各々に関して修正後ＣＰＵ使用率Ｕ’を算出する。また、ステップＳ４０において、サーバ選択部４０は、上記抽出されたサーバから、修正後ＣＰＵ使用率Ｕ’が最大である最大負荷サーバ（第１サーバ）と、修正後ＣＰＵ使用率Ｕ’が最小である最小負荷サーバ（第２サーバ）の両方を選択する。
【００９６】
ステップＳ６０において、処理移行部６０は、最大負荷サーバで実行中の処理のいくつかを、最小負荷サーバに移行（移動）する。このような移行処理は、例えば、特開２００４−０７８４６５号公報に記載された「プロセスマイグレーション方法」により実現可能である。図１１で示された例では、最大負荷サーバはサーバ１００−１であり、最小負荷サーバはサーバ１００−２である。よって、処理移行部６０は、サーバ１００−１で実行中の処理のいくつかを、サーバ１００−２に移行する。ステップＳ４０において選択される最大負荷サーバ及び最小負荷サーバは、時間経過とともに更新される。それに伴い、移行が行われる最大負荷サーバ及び最小負荷サーバも変化する。結果として、複数のサーバ１００−１〜１００−ｎ間での負荷分散が実現される。
【００９７】
本実施の形態によれば、後処理に伴う負荷を考慮して、最大負荷サーバ及び最小負荷サーバが正しく選択される。これを利用することによって、後処理に伴う負荷をも考慮した適切な負荷分散が可能となる。尚、サーバ負荷判定処理（ステップＳ１０〜Ｓ４０）と移行処理（ステップＳ６０）は、別々の装置（コンピュータ）により実行されてもよい。
【００９８】
以上、本発明の実施の形態が添付の図面を参照することにより説明された。但し、本発明は、上述の実施の形態に限定されず、要旨を逸脱しない範囲で当業者により適宜変更され得る。
【図面の簡単な説明】
【００９９】
【図１Ａ】図１Ａは、ＣＰＵ使用率と処理中リクエスト数との関係を示すグラフである。
【図１Ｂ】図１Ｂは、ＣＰＵ使用率と単位時間あたりのリクエスト到着数との関係を示すグラフである。
【図２】図２は、本発明の実施の形態に係るサーバ負荷管理システムの構成例を示すブロック図である。
【図３】図３は、本実施の形態に係る処理装置の機能を示すブロック図である。
【図４】図４は、本実施の形態に係るサーバ負荷管理システムによる処理を示すフローチャートである。
【図５Ａ】図５Ａは、本実施の形態に係る性能指標変化テーブルを示す概念図である。
【図５Ｂ】図５Ｂは、本実施の形態に係る性能指標変化テーブルの一例を示している。
【図６】図６は、本実施の形態におけるステップＳ２０の処理の一例を示すフローチャートである。
【図７Ａ】図７Ａは、本実施の形態に係るサーバグループ管理リストの一例を示す概念図である。
【図７Ｂ】図７Ｂは、本実施の形態に係るサーバグループ管理リストの他の例を示す概念図である。
【図８】図８は、本実施の形態の第１の応用例に係るサーバ負荷管理システムの構成例を示すブロック図である。
【図９】図９は、第１の応用例に係る処理装置の機能を示すブロック図である。
【図１０】図１０は、第１の応用例に係るサーバ負荷管理システムによる処理を示すフローチャートである。
【図１１】図１１は、本実施の形態の第２の応用例に係るサーバ負荷管理システムの構成例を示すブロック図である。
【図１２】図１２は、第２の応用例に係る処理装置の機能を示すブロック図である。
【図１３】図１３は、第２の応用例に係るサーバ負荷管理システムによる処理を示すフローチャートである。
【符号の説明】
【０１００】
１，１Ａ，１Ｂ    サーバ負荷管理システム
２    処理装置
３    記憶装置
４    通信装置
５    入力装置
６    出力装置
１０    性能指標蓄積部
２０    傾向判定部
３０    サーバ負荷算出部
４０    サーバ選択部
５０    リクエスト割当部
６０    処理移行部
１００    サーバ
１１０    監視部
ＰＩ    性能指標データ
ＲＩ    リクエストインデックス
ＴＢＬ    性能指標変化テーブル
ＧＲＰ    サーバグループ管理リスト
ＰＲＯＧ１  サーバ負荷判定プログラム
ＰＲＯＧ２  リクエスト割当プログラム
ＰＲＯＧ３  処理移行プログラム
【図１Ａ】
2009252050.tif 000010
【図１Ｂ】
2009252050.tif 000011
【図２】
2009252050.tif 000012
【図３】
2009252050.tif 000013
【図４】
2009252050.tif 000014
【図５Ａ】
2009252050.tif 000015
【図５Ｂ】
2009252050.tif 000016
【図６】
2009252050.tif 000017
【図７Ａ】
2009252050.tif 000018
【図７Ｂ】
2009252050.tif 000019
【図８】
2009252050.tif 000020
【図９】
2009252050.tif 000021
【図１０】
2009252050.tif 000022
【図１１】
2009252050.tif 000023
【図１２】
2009252050.tif 000024
【図１３】
2009252050.tif 000025