JP6248560B2 - 管理プログラム、管理方法、および管理装置 - Google Patents

Description

本発明は、負荷に応じてリソースを割り当てる管理プログラム、管理方法、および管理装置に関する。

情報処理システムでは、複数の情報処理装置を配置し、負荷分散装置によって、各情報処理装置に負荷を分散させる場合がある。負荷を分散させることで、各情報処理装置に効率的に処理を実行させることができ、システム全体の処理性能が向上する。

複数の情報処理装置での分散処理を行う場合、情報処理装置数が多すぎると、コンピュータ資源が無駄に占有され、資源（リソース）の利用効率が低くなる。他方、情報処理装置数が少なすぎると、情報処理装置１台当たりの負荷が過大となり、処理要求に対する応答時間が長期化する。そこで、処理量に応じて、情報処理装置数を自動的に増減させる技術が考えられている。このような技術は、オートスケールと呼ばれる。ここで、情報処理装置数を増加させることをスケールアウト、情報処理装置数を減少させることをスケールダウンと呼ぶ。オートスケールを実施することで、コンピュータ資源を節約しながら、システム全体として十分な性能を維持することができる。

オートスケールの契機は、例えば、ＣＰＵ（Central Processing Unit）使用率や応答時間の閾値超過により判断される。また各ネットワークサービスに到着する要求量の変動の様子を監視し、要求量の一定時間経過後の値を予測し、その要求量予測値の大きさに応じて当該ネットワークサービスに対する情報処理装置の割当量を制御する技術も考えられている。

国際公開第２００４／０９２９７１号

応答時間に基づいてスケールアウトを行う場合、例えば、応答時間が閾値を超過するような処理が発生したときに、スケールアウトが行われる。スケールアウトによって処理を実行する情報処理装置数を増加させることで、１台当たりの処理負荷を軽減し、応答時間が短縮するものと期待できる。

しかし、現実には、スケールアウトを行っても、応答時間の短縮効果が得られない場合が存在する。例えば、システム内の障害や、多階層システムにおける情報処理装置間での通信の輻輳などが原因で応答時間が長期化した場合、情報処理装置のスケールアウトを行っても、応答時間の短縮効果は得られない。しかも、従来技術では、応答時間が閾値を超過した場合において、スケールアウトが有効かどうかを適切に判断できない。その結果、応答時間が閾値を超過したときに、応答時間が閾値を超えるような処理の発生を抑止できない場合でもスケールアウトが実施され、資源が無駄に消費されている。

１つの側面では、本件は、情報処理装置のリソースの適切な割り当てを実現することを目的とする。

１つの案では、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの量を管理する処理を管理装置に実行させる管理プログラムが提供される。この管理プログラムを実行することで管理装置は、受信した処理要求に応じた処理が情報処理装置で実行されると、実行開始の際に前記情報処理装置が実行している処理の数を示す同時処理数と、該受信した処理要求に応じた処理の実行開始から完了までの処理時間とを関連付けて、記憶手段に蓄積する。次に管理装置は、同時処理数それぞれについて、該同時処理数に関連付けられた処理時間の集合のうち、該同時処理数よりも少ない同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出する。そして管理装置は、新たに蓄積された処理時間と、該処理時間が関連付けられた同時処理数について算出された代表値とに基づいて、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの追加の要否を決定する。

１態様によれば、情報処理装置のリソースの適切な割り当てを実現することができる。

第１の実施の形態のシステム構成の一例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 負荷分散装置のハードウェアの一構成例を示す図である。 仮想サーバによる負荷分散処理の一例を示す図である。 同時リクエスト数と応答時間との関係を示す図である。 スケールアウトの要否の誤判断の例を示す図である。 集計データの作成に使用する応答時間の一例を示す図である。 集計対象とする応答時間の違いによる平均値の傾向を示す図である。 スケールアウトの要否判定例を示す図である。 同時リクエスト数の増加に伴う集計データの上昇が抑制される例を示す図である。 オートスケールの委譲例を示す図である。 負荷分散装置の機能構成の一例を示すブロック図である。 管理情報記憶部に記憶される情報の一例を示す図である。 応答時間管理テーブルのデータ構造の一例を示す図である。 応答時間集計情報のデータ構造の一例を示す図である。 通信時間管理テーブルのデータ構造の一例を示す図である。 通信時間集計情報のデータ構造の一例を示す図である。 委譲先管理テーブルのデータ構造の一例を示す図である。 委譲元管理テーブルのデータ構造の一例を示す図である。 スケールアウト要否判断を伴うリクエスト振り分け処理の手順の一例を示すフローチャートである。 集計データ算出処理の手順の一例を示すフローチャートである。 過負荷判定処理の手順の一例を示すフローチャートである。 過負荷箇所判定処理の手順の一例を示すフローチャートである。 被委譲スケールアウト処理の手順の一例を示すフローチャートである。 スケールダウンの制御手順の一例を示すフローチャートである。 被委譲スケールダウン制御の手順の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、第１の実施の形態について説明する。第１の実施の形態は、処理要求に応じた処理実行の処理時間が閾値を超えたとしても、リソースの追加割り当てを行っても、処理時間が閾値を超えることを抑止できない場合には、リソースの追加割り当てを行わないようにした情報処理システムである。

図１は、第１の実施の形態のシステム構成の一例を示す図である。管理装置１０は、複数の端末装置１ａ，１ｂ，・・・と複数の情報処理装置２ａ，２ｂ，２ｃとに接続されている。端末装置１ａ，１ｂ，・・・は、情報処理装置２ａ，２ｂ，２ｃに対する処理要求を出力する。その処理要求は、管理装置１０を介して情報処理装置２ａ，２ｂ，２ｃに振り分けられる。情報処理装置２ａ，２ｂ，２ｃは、受信した処理要求に応じて処理を実行する。

情報処理装置２ａ，２ｂ，２ｃは、管理装置１０からの指示に従って、処理要求に応じた処理の実行に、リソースを割り当てる。図１の例では、情報処理装置２ａ，２ｂは運用中であり、情報処理装置２ｃは運用していない（プールされている状態）。この場合、情報処理装置２ａ，２ｂのリソースは、処理要求に応じた処理の実行に割り当てられているが、情報処理装置２ｃのリソースは、処理要求に応じた処理の実行に割り当てられていない。

管理装置１０は、振り分け手段１１、蓄積手段１２、記憶手段１３、算出手段１４、決定手段１５、および制御手段１６を有する。
振り分け手段１１は、端末装置１ａ，１ｂ，・・・から出力された処理要求を、運用中の情報処理装置２ａ，２ｂに振り分ける。例えば振り分け手段１１は、情報処理装置２ａ，２ｂの負荷が均等になるように、振り分けを行う。

蓄積手段１２は、受信した処理要求に応じた処理が情報処理装置２ａ，２ｂ，２ｃで実行されると、実行された処理に関する情報を記憶手段１３に蓄積する。例えば、実行開始の際に情報処理装置が実行している処理の数を示す同時処理数と、その受信した処理要求に応じた処理の実行開始から完了までの処理時間とが関連付けて蓄積される。このとき蓄積手段１２は、情報処理装置２ａ，２ｂ，２ｃに処理要求を送信してから応答を受信するまでの時間を、処理時間とすることができる。この場合、管理装置１０と情報処理装置２ａ，２ｂ，２ｃとの間の通信に要した時間も処理時間に含まれてしまう。そこで情報処理装置２ａ，２ｂ，２ｃにおいて、処理要求に応じて実行した処理に要した処理時間を計測し、蓄積手段１２は、情報処理装置２ａ，２ｂ，２ｃから処理時間を取得するようにしてもよい。なお、同時処理数は、処理の多重度とも呼ばれる。

記憶手段１３は、同時処理数と処理時間とを関連付けて記憶する。図１の例では、処理を実行した情報処理装置の識別子（ＩＤ）に対応付けて、同時処理数と処理時間とが記憶手段１３に記憶されている。

算出手段１４は、同時処理数それぞれについて、その同時処理数に関連付けられた処理時間の集合のうち、該同時処理数よりも少ない同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出する。算出手段１４は、代表値の算出を、情報処理装置ごとに個別に実行してもよい。代表値は、処理時間の特徴や傾向を示す数値である。代表値としては、例えば部分集合に含まれる処理時間の平均値を用いることができる。また代表値として、部分集合に含まれる処理時間の中央値を用いてもよい。

算出手段１４は、代表値の算出の際に、例えば、代表値を算出する同時処理数よりも少ない同時処理数のうち、代表値が算出されている最も大きな同時処理数を特定する。そして算出手段１４は、代表値を算出する同時処理数に関連付けられた処理時間のうち、特定した同時処理数の関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出する。

決定手段１５は、新たに蓄積された処理時間と、その処理時間が関連付けられた同時処理数について算出された代表値とに基づいて、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの追加の要否を決定する。例えば決定手段１５は、新たに蓄積された処理時間が、所定の閾値を超え、かつその処理時間が関連付けられた同時処理数について算出された代表値に所定値を乗算した値未満であるという条件が満たされたかどうかを判断する。ここで乗算する所定値は、１より大きな実数である。そして「同時処理数について算出された代表値に所定値を乗算した値」とは、その同時処理数で実行された負荷の高い処理の、過去の処理履歴から予測できる、過負荷時の処理時間の上限を表している。すなわち、その上限よりも新たな処理の処理時間が長い場合は、障害などの過負荷以外の原因があるものと判断できる。そこで決定手段１５は、上記条件が満たされたときに、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定する。

制御手段１６は、決定手段１５による決定内容に従って、処理要求に応じた処理に割り当てる、情報処理装置２ａ，２ｂ，２ｃのリソースの量を制御する。例えば制御手段１６は、決定手段１５において、リソースを追加する旨が決定された場合、プール状態の情報処理装置２ｃに指示を出し、処理要求に応じた処理の実行を開始させる。

このような管理装置１０によれば、端末装置１ａ，１ｂ，・・・からの処理要求が、振り分け手段１１によって、運用中の情報処理装置２ａ，２ｂに振り分けられる。すると情報処理装置２ａ，２ｂにおいて、処理要求に応じた処理が実行される。情報処理装置２ａ，２ｂは、処理が完了すると、処理要求に対する応答を管理装置１０に送信する。振り分け手段１１は、情報処理装置２ａ，２ｂからの応答を受信し、処理要求の送信元の端末装置に受信した応答を転送する。

振り分け手段１１による処理要求の振り分けと、その処理要求に対する応答の転送とは、蓄積手段１２により監視されている。蓄積手段１２は、例えば振り分けられた処理要求のうち、未応答の処理要求の数を管理し、その数を、情報処理装置２ａ，２ｂでの同時処理数とする。また蓄積手段１２は、例えば、処理要求の振り分けから応答を受信するまでの時間を、その処理要求に応じた処理の処理時間とする。そして処理要求が振り分けられ、応答が返されると、蓄積手段１２により、その処理要求の実行開始時点での同時処理数と処理時間とを関連付けて、記憶手段１３に格納される。

その後、記憶手段１３に記憶された情報に基づいて、算出手段１４により、同時処理数ごとの代表値が算出される。ある同時処理数の代表値の算出では、例えば、その同時処理数に関連付けられた処理時間のうち、その同時処理数よりも少ない同時処理数のうち、代表値が得られている最大の同時処理数の代表値よりも、大きい値の処理時間のみが集計対象とされる。そして、集計対象の処理時間を集計することで、代表値が算出される。代表値は、例えば集計対象の処理時間の平均値である。なお代表値を計算しようとする同時処理数よりも、少ない値の同時処理数のなかに、代表値が得られている同時処理数がない場合、例えば、代表値を計算しようとする同時処理数に関連付けられたすべての処理時間が集計対象とされる。

図１の例では、同時処理数「５」、「８」、「１０」に関連付けられた処理時間が、記憶手段１３に記憶されているものとする。この場合、処理時間が関連付けられた同時処理数のうちの最小の同時処理数「５」の代表値の算出の際には、同時処理数「５」に関連付けられたすべての処理時間の代表値が算出される。次に少ない同時処理数「８」の代表値の算出の際には、同時処理数「８」に関連付けられた処理時間のうち、同時処理数「５」の代表値よりも長い処理時間の代表値が算出される。同様に、同時処理数「１０」の代表値の算出の際には、同時処理数「１０」に関連付けられた処理時間のうち、同時処理数「８」の代表値よりも長い処理時間の代表値が算出される。このようにして算出された同時処理数それぞれの代表値は、決定手段１５に通知される。

その後、新たな処理時間が記憶手段１３に蓄積されると、決定手段１５により、その処理時間が、予め設定された閾値を超えているかどうかが判断される。閾値を超えている場合、決定手段１５により、新たに蓄積された処理時間に関連付けられた同時処理数の代表値と、記憶された処理時間とが比較され、その比較結果に基づいて、処理要求に応じた処理を実行する情報処理装置のリソースの追加の要否が決定される。

例えば、新たに蓄積された処理時間が、比較した代表値の所定倍（例えば２倍）以上の場合、リソースの追加を行わないものと決定される。すなわち、処理時間が閾値を超えたとしても、代表値よりも過度に長い処理時間を要した処理は、障害などの過負荷以外の原因で処理時間が長期化した可能性が高い。このような場合に、処理要求の実行に割り当てるリソースを追加しても、リソースが無駄に消費されるだけで、処理時間の短縮効果を得ることができない。そのため、リソースの追加を行わないのが適切である。図１の例では、同時処理数「５」、「８」に関連付けられた処理時間が閾値を超えていても、代表値の所定倍以上であるため、リソースは追加しないと決定される。

また新たに蓄積された処理時間が、比較した代表値の所定倍未満の場合、リソースの追加を行うものと決定される。すなわち、閾値を超えており、かつ代表値からそれほど離れていない処理時間を要した処理は、過負荷が原因で処理時間が長期化した可能性が高い。このような場合に、処理要求の実行に割り当てるリソースを追加することで、処理時間の短縮効果を期待できる。そのため、リソースを追加するのが適切である。図１の例では、同時処理数「１０」に関連付けられた処理時間が閾値を超えており、代表値の所定倍未満であるため、リソースを追加すると決定される。

リソースを追加すると決定された場合、制御手段１６によって、処理要求に応じた処理の実行へ割り当てる情報処理装置２ａ，２ｂ，２ｃのリソースが追加される。例えば新たに、情報処理装置２ｃの運用を開始することで、情報処理装置２ａ，２ｂ，２ｃのリソースが、処理要求に応じた処理の実行に割り当てられる。

このようにして、処理要求に応じた処理の実行への、情報処理装置２ａ，２ｂ，２ｃのリソースの割り当てが適切に実行される。すなわち、第１の実施の形態では、各同時処理数の代表値を算出する際に、ある程度以下の処理時間が、集計対象から除外される。これは、同時処理数が増加しても処理時間が長期化しないような処理（例えば、極めて短時間で実行できる処理）の処理時間を、集計対象から除外するものである。その結果、同時処理数の増加に伴って運用中の情報処理装置２ａ，２ｂの負荷が増加し、処理時間が長期化するような処理の処理時間のみに基づいて、代表値を算出できる。このようにして得られた同時処理数ごとの代表値は、同時処理数の増加に伴う処理時間の長期化の傾向を正しく表している。同時処理数の増加に伴う処理時間の長期化によって、多くの処理時間が閾値に近づいている状況において、処理時間が閾値を超過すれば、その原因は運用中の情報処理装置２ａ，２ｂの過負荷であると考えられる。この場合には、プールされている情報処理装置２ｃで運用を開始すれば、以後の処理要求に応じた処理の処理時間を短縮できる。

他方、処理時間が閾値を超えたとしても、処理時間の長期化の原因が過負荷以外の原因であると考えられる場合には、リソースの追加が抑止される。これにより、過度なリソースの消費が抑止され、リソースの効率的な利用が可能となる。またリソースが過度に使用されないことで、システムの消費電力を削減することもできる。さらにリソースの使用量に応じてユーザに課金する場合であれば、障害が原因で処理が遅延したにも拘わらず、ユーザの料金負担が増加してしまう事態の発生を抑止できる。

なお、決定手段１５は、新たに蓄積された処理時間が関連付けられた同時処理数について代表値が算出されていない場合、該同時処理数の代表値を、他の同時処理数について算出された代表値に基づいて推定することもできる。例えば決定手段１５は、代表値が算出されており、かつ該同時処理数に近い方から２つの同時処理数について算出された代表値に基づいて、同時処理数の増加に伴う代表値の増加度合いを表す式を求める。そして決定手段１５は、求めた式に基づいて、新たに蓄積された処理時間が関連付けられた同時処理数の代表値を推定する。これにより、代表値が計算されていない同時処理数に関連付けられた処理時間が新たに蓄積され、その処理時間が閾値を超えていた場合であっても、適切な判断を行うことができる。

また決定手段１５は、直近の所定期間内に蓄積されたすべての処理時間が、過負荷判定に用いる閾値未満の所定値（例えば閾値の１／２）以下のときに、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを削減するものと決定する。これにより、過度なリソースの消費が抑止される。

また、コンピュータのシステムでは、多階層に構成された複数の情報処理装置が連携して処理要求に応じた処理を実行している場合がある。この場合、階層ごとに、図１に示した管理装置１０を設けることができる。そのとき、各管理装置１０の蓄積手段１２は、例えば、複数の情報処理装置うちの特定の情報処理装置が受信した処理要求に応じて実行した処理についての、同時処理数、処理時間、および下位の階層の情報処理装置との通信時間を関連付けて蓄積する。決定手段１５は、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定する条件として、新たに蓄積された処理時間に対する、その処理時間に関連付けられた通信時間の割合が所定値未満であるという条件を追加する。これにより、各管理装置１０において、下位の階層の過負荷にもかかわらず、自己の管理する情報処理装置のリソースを追加してしまうことが抑止される。

なお決定手段１５は、新たに蓄積された処理時間に対する、その処理時間に関連付けられた通信時間の割合が所定値以上の場合、特定の情報処理装置よりも下位の階層の情報処理装置のリソースを追加するものと決定することができる。この決定をした場合、決定手段１５は、下位の階層の情報処理装置のリソースの、処理要求に応じた処理の実行への割り当て量を管理する他の管理装置に、リソース追加要求を送信する。これにより、他の管理装置と連携して、適切なリソース追加の要否判断が可能となる。

多階層システムの管理装置１０では、上位の階層の情報処理装置のリソースの処理の実行への割当量を管理する他の管理装置から、リソース追加要求を受信した場合、以下の処理が行われる。例えば、上位の階層の情報処理装置において実行された、処理時間が閾値を超えた処理について、その処理の実行過程で行われた通信の開始から終了までの通信時間が求められる。そして求めた通信時間と、その通信経由で依頼された処理要求に応じて特定の情報処理装置が実行した処理の処理時間とが比較される。通信時間に対する、下位の階層である特定の情報処理装置での処理時間の割合が所定値以上の場合、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定される。これにより、情報処理装置の過負荷ではなく、通信過負荷の場合に、情報処理装置のリソースの追加が行われてしまうことを抑止できる。

さらに多階層システムに適用される管理装置１０の決定手段１５は、一定の場合に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを削減するものと決定することができる。一定の場合とは、例えば、新たに蓄積された処理時間が、閾値未満の所定値以下であり、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものとの決定後に、他の管理装置へのリソース追加要求を送信していない場合である。これにより、リソースの追加を行った範囲内で、リソースの削減をすることができる。その結果、過度なリソースの削減を抑止できる。

また多階層システムに適用される管理装置１０の決定手段１５は、一定の場合に、他の管理装置へ、リソース削減要求を送信することができる。一定の場合とは、例えば、新たに蓄積された処理時間が、閾値未満の所定値以下であり、他の管理装置へのリソース追加要求の送信後に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定を行っていない場合である。これにより、処理時間が短くなると、多階層システムのうちの適切な階層の情報処理装置のリソースを削減し、リソースの効率的な利用を促進することができる。

また、多階層システムに適用される管理装置１０は、特定の情報処理装置よりも上位の階層の情報処理装置のリソースの、処理要求に応じた処理の実行への割当量を管理する他の管理装置から、リソース削減要求を受信する場合がある。この場合、管理装置１０の決定手段１５は、他の管理装置からのリソース追加要求に応じて追加したリソースの範囲内で、処理要求に応じた処理の実行へ割り当てる前記特定の情報処理装置のリソースを削減するものと決定することができる。これにより過度なリソースの削減を抑止できる。

なお、振り分け手段１１、蓄積手段１２、算出手段１４、決定手段１５、および制御手段１６は、例えば管理装置１０が有するプロセッサにより実現することができる。また、記憶手段１３は、例えば管理装置１０が有するメモリにより実現することができる。

また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、多階層システムにおけるオートスケールを適切に行うものである。

情報処理システムでは、１台のサーバ内で処理が完結するとは限らず、複数のサーバが連携して応答を返す場合が多い。そのため、連携する他のサーバの応答時間が悪化することにより、上位の階層のサーバの応答時間が超過する場合がある。この場合、オートスケールによりサーバを追加しても性能が改善されない可能性がある。

そこで第２の実施の形態では、上位の階層のサーバにおけるリクエストに対する応答時間に占める、他サーバとの通信時間を計測することで、応答遅延の原因が上位の階層のサーバにあるのか、下位の階層のサーバにあるのかの判別を可能とする。応答時間の長期化の原因が、上位の階層のサーバではなく下位の階層のサーバの処理時間の悪化であることが分かった場合、例えば通信先の下位のサーバのオートスケールを促すことができる。

なお多階層システムのサーバは、例えば仮想サーバによって実現できる。仮想サーバは、物理サーバ内に仮想的に設けられたコンピュータ（仮想マシン）である。例えば物理サーバは、ハイパーバイザによって物理サーバ内に多数の仮想サーバを立ち上げることができる。仮想サーバを用いることで、オートスケールにおけるサーバのスケールアウト（仮想サーバの追加）や、サーバのスケールダウン（仮想サーバの削減）が容易となる。そこで第２の実施の形態では、仮想サーバを用いてオートスケールを実現するものとする。

図２は、第２の実施の形態のシステム構成例を示す図である。図２に示す多階層システムは、複数の負荷分散装置１００，２００，３００，４００と、複数の物理サーバ４１〜４４とを有する。複数の負荷分散装置１００，２００，３００，４００と、複数の物理サーバ４１〜４４とは、それぞれ管理ネットワーク４６を介して仮想化装置４５に接続されている。仮想化装置４５は、物理サーバ４１〜４４に対して、仮想サーバの立ち上げや、運用開始などを指示する。物理サーバ４１〜４４は、仮想化装置４５からの指示に従って、複数の仮想サーバを立ち上げることができる。

なお仮想サーバとは、コンピュータの動作をエミューレートすることで実現された、アプリケーションなどのソフトウェアの実行機能である。仮想サーバは、物理サーバが、ハードウェア資源またはソフトウェア資源の一部を割り当てることによって実現される。

負荷分散装置１００は、ネットワーク２０を介して複数の端末装置３１，３２，・・・に接続されている。また負荷分散装置１００は、物理サーバ４１に接続されている。負荷分散装置１００は、複数の端末装置３１，３２，・・・から、処理の実行を依頼するリクエストを受信すると、そのリクエストを物理サーバ４１内に立ち上げられた仮想サーバのいずれかに転送する。その際、負荷分散装置１００は、物理サーバ４１内の仮想サーバ間での負荷が均等化されるように、リクエストの送信先を決定する。

負荷分散装置２００は、物理サーバ４１と物理サーバ４２との間に接続されている。負荷分散装置２００は、物理サーバ４１からリクエストを受信すると、そのリクエストを物理サーバ４２内に立ち上げられた仮想サーバのいずれかに、転送する。その際、負荷分散装置２００は、物理サーバ４２内の仮想サーバ間での負荷が均等化されるように、リクエストの送信先を決定する。

負荷分散装置３００は、物理サーバ４１と物理サーバ４３との間に接続されている。負荷分散装置３００は、物理サーバ４１からリクエストを受信すると、そのリクエストを物理サーバ４３内に立ち上げられた仮想サーバのいずれかに、転送する。その際、負荷分散装置３００は、物理サーバ４３内の仮想サーバ間での負荷が均等化されるように、リクエストの送信先を決定する。

負荷分散装置４００は、物理サーバ４２と物理サーバ４４との間に接続されている。負荷分散装置４００は、物理サーバ４２からリクエストを受信すると、そのリクエストを物理サーバ４４内に立ち上げられた仮想サーバのいずれかに、転送する。その際、負荷分散装置４００は、物理サーバ４４内の仮想サーバ間での負荷が均等化されるように、リクエストの送信先を決定する。

各負荷分散装置１００，２００，３００，４００は、例えばプロセッサやメモリを有するコンピュータを用いて実現できる。
図３は、負荷分散装置のハードウェアの一構成例を示す図である。負荷分散装置１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１の機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、負荷分散装置１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８ａ，１０８ｂ，１０８ｃがある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、負荷分散装置１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、負荷分散装置１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８ａは、ネットワーク２０に接続されている。ネットワークインタフェース１０８ａは、ネットワーク２０を介して、端末装置３１，３２，・・・との間でデータの送受信を行う。ネットワークインタフェース１０８ｂは、物理サーバ４１に接続されている。ネットワークインタフェース１０８ｂは、物理サーバ４１との間でデータの送受信を行う。ネットワークインタフェース１０８ｃは、仮想化装置４５に接続されている。ネットワークインタフェース１０８ｃは、仮想化装置４５との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。他の負荷分散装置２００，３００，４００、仮想化装置４５、端末装置３１，３２，・・・，物理サーバ４１〜４４についても、負荷分散装置１００と同様のハードウェアにより実現できる。また、第１の実施の形態に示した管理装置１０も、図３に示した負荷分散装置１００と同様のハードウェアにより実現することができる。

負荷分散装置１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。負荷分散装置１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、負荷分散装置１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また負荷分散装置１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

次に、仮想サーバによる負荷分散処理について説明する。
図４は、仮想サーバによる負荷分散処理の一例を示す図である。負荷分散装置１００は、物理サーバ４１内の複数の仮想サーバ４１ａ，４１ｂの負荷が均等化されるように、端末装置３１，３２，・・・からのリクエストを物理サーバ４１内のいずれかの仮想サーバ４１ａ，４１ｂに転送する。仮想サーバ４１ａ，４１ｂは、リクエストに応じた処理を実行する。そして仮想サーバ４１ａ，４１ｂは、処理の実行過程で、他の仮想サーバに依頼する処理が発生すると、その処理のリクエストを生成し、負荷分散装置２００，３００のいずれかに送信する。例えば物理サーバ４２内の仮想サーバ４２ａ，４２ｂに依頼する処理のリクエストであれば、負荷分散装置２００に送信される。また物理サーバ４３内の仮想サーバ４３ａ，４３ｂに依頼する処理のリクエストであれば、負荷分散装置３００に送信される。

なお上位の階層の仮想サーバが下位の階層の仮想サーバへのリクエストの振り分けを行う負荷分散装置へリクエストを送信する場合、送信するリクエストに、仮想サーバ自身が処理の依頼を受けたときのリクエストの識別子を含める。リクエストを受け取った下位の階層の負荷分散装置は、受信したリクエストに付与されている識別子を用いて、リクエストを管理する。これにより、上位の階層の仮想サーバで実行したリクエストと、そのリクエストの実行過程で発生した、下位の階層の仮想サーバ宛のリクエストとを、一意に対応付けることができる。

負荷分散装置２００は、物理サーバ４２内の複数の仮想サーバ４２ａ，４２ｂの負荷が均等化されるように、仮想サーバ４１ａ，４１ｂからのリクエストを物理サーバ４２内のいずれかの仮想サーバ４２ａ，４２ｂに転送する。負荷分散装置３００は、物理サーバ４３内の複数の仮想サーバ４３ａ，４３ｂの負荷が均等化されるように、仮想サーバ４１ａ，４１ｂからのリクエストを物理サーバ４３内のいずれかの仮想サーバ４３ａ，４３ｂに転送する。各仮想サーバ４２ａ，４２ｂ，４３ａ，４３ｂは、受信したリクエストに応じた処理を実行する。仮想サーバ４２ａ，４２ｂは、処理の実行過程で、他の仮想サーバに依頼する処理が発生すると、その処理のリクエストを生成し、負荷分散装置４００に送信する。負荷分散装置４００は、物理サーバ４４内の複数の仮想サーバ４４ａ，４４ｂの負荷が均等化されるように、仮想サーバ４２ａ，４２ｂからのリクエストを物理サーバ４４内のいずれかの仮想サーバ４４ａ，４４ｂに転送する。

このようにして、多階層システムの各階層の処理を、仮想サーバで負荷分散することができる。仮想サーバ４１ａ，４１ｂ，４２ａ，４２ｂ，４３ａ，４３ｂ，４４ａ，４４ｂは、例えばウェブサーバ、アプリケーションサーバ、データベースサーバであり、階層ごとに割り当てられた処理を実行する。なお図４の例では、各物理サーバ４１〜４４に２台ずつの仮想サーバ４１ａ，４１ｂ，４２ａ，４２ｂ，４３ａ，４３ｂ，４４ａ，４４ｂが設けられているが、各物理サーバ４１〜４４内の仮想サーバの数は、仮想化装置４５からの指示に応じて変更される。

負荷分散装置１００，２００，３００，４００は、負荷分散処理以外に、オートスケールにおけるスケールアウトまたはスケールダウンの要否判断を行う。例えば負荷分散装置１００，２００，３００，４００は、リクエストの送信先の仮想サーバの負荷状況を監視しており、負荷が過大であれば、仮想化装置４５に対してスケールアウトを要求する。

仮想サーバの負荷が過大かどうかを判断は、リクエストに対する応答時間に基づいて行われる。すなわち、第２の実施の形態では、第１の実施の形態における処理時間として、リクエストに対する応答時間を用いる。例えば応答時間が閾値を超えたリクエストが検出されたときに、仮想サーバが過負荷の可能性があると判断される。応答時間が閾値以上に長期化していても、長期化の原因が過負荷以外であれば、スケールアウトの要求を行わない。応答時間の長期化の原因は、リクエストごとの応答時間と、そのリクエストの送信先の仮想サーバにおける同時リクエスト数とに基づいて判断される。同時リクエスト数は、リクエストの送信先の仮想サーバにおける、リクエストに応じた処理の実行開始時における、同時処理数である。

また負荷分散装置１００，２００は、応答時間の長期化の原因が過負荷であった場合、その負荷分散装置１００，２００の送信先の仮想サーバの過負荷なのか、さらに下位層の仮想サーバの過負荷なのかを判断する。そして負荷分散装置１００，２００は、下位層の仮想サーバの過負荷であれば、その下位層の仮想サーバへのリクエストの負荷分散を行う他の負荷分散装置へ、オートスケールの要否判断を委譲する。

負荷分散装置１００，２００，３００，４００では、無駄なスケールアウトを実施しないように、適切な判断を行う。換言すると、リクエストに対する応答時間が閾値を超えた場合であっても、スケールアウトによって応答時間が閾値を超える処理を抑止できないことがある。このような場合にスケールアウトを行うと、リソースの利用効率が低下する。

ここで、リクエストに対する応答時間が閾値を超えたにも拘わらず、スケールアウトによって応答時間が閾値を超える処理を抑止できない場合について詳細に説明する。
例えば、オートスケールによりサーバを自動的に追加する時の判断方法として、リクエストに対する応答時間が閾値（例えば１秒）を超えた場合にスケールアウトする方法がある。しかし、応答時間の長期化の原因は様々であり、サーバに対するリクエスト過多以外の要因で応答時間が長期化することがある。例えば、アプリケーション障害による無限ループの発生によりＣＰＵ使用率が上昇し、その結果として応答時間が長期化する場合がある。また、システムがハングアップする障害によりリクエストに対する応答時間が長期化する場合もある。このような場合、スケールアウトによりサーバを追加し、サーバ１台当たりの処理リクエスト数を低下させても、システム全体の性能が改善されない可能性がある。

障害によって応答時間が長期化した場合、通常よりも大幅に応答時間が長くなるものと考えられる。他方、サーバの過負荷により応答時間が長期化した場合、各リクエストの応答時間は、リクエストに応じた処理開始時点で同時に実行されているリクエストの処理数（同時リクエスト数）に基づいて予測される応答時間から所定の範囲内に収まるものと考えられる。そこで、リクエストへの応答時間が閾値を超えた場合であっても、そのリクエストに対して予測される応答時間に対し、実際のリクエスト応答時間が大幅に超過していることが確認できれば、スケールアウトを行わないことが考えられる。

このように予測される応答時間と比較してスケールアウトを行うかどうかを判断する場合、応答時間を適切に予測することが重要となる。同時リクエスト数からリクエスト応答時間を予測するには、例えば情報処理システムにおいて、リクエスト応答時間と同時リクエスト数とを常時採取し、同時リクエスト数が共通のリクエスト同士での応答時間の平均値を求める。さらに情報処理システムは、同時リクエスト数ごとに得られた平均値を、同時リクエスト数に応じた応答時間の予測値とする。そして情報処理システムは、応答時間の閾値を超過したリクエストにおける応答時間の実測値と、そのリクエストの処理開始時における同時リクエスト数に応じた予測値とを比較する。情報処理システムは、実測値が予測値を大幅に超えている場合には、スケールアウトは行わず、実測値が予測値から所定の範囲内であれば、スケールアウトを行う。

図５は、同時リクエスト数と応答時間との関係を示す図である。図５では、横軸に同時リクエスト数、縦軸に応答時間を取っている。実行されたリクエストごとに採取された、同時リクエスト数と応答時間の実測値とを、黒い矩形で表している。

図５に示すように、同時リクエスト数が多くなるほど、応答時間の長いリクエストが多くなる。そして応答時間が閾値を超えるようなリクエストが発生しても、そのリクエストの応答時間が、負荷の増減を加味して予測できる応答時間の範囲を大幅に上回っている場合、過負荷以外の原因で応答時間が長期化したものと判断できる。

このようにして、スケールアウトを行うかどうかを判断することが可能である。ただし、この方法には以下の２つの課題がある。
第１の課題は、平均値を導き出すための採取データが少ない場合、負荷の増減に応じたリクエストの応答時間を正しく予測するのが難しいことである。例えば、図５において同時リクエスト数が「５」の場合のように、リクエストの応答時間の採取データが１つしかない場合や、同時リクエスト数が「９」の場合のように急激なリクエスト数の増加などでリクエストの応答時間の採取データが無い場合が考えられる。このように採取データがないか、あったとしてもごく少数の場合に、適切な応答時間の予測が困難となる。

第２の課題は、負荷が大きな処理のリクエストのみの平均値を計測するのが難しいことである。情報処理システムが扱うリクエストには、単なるデータの表示を行うような応答時間が短いリクエストや、大量データの集計を行うような応答時間が長いリクエストが混在している。応答時間が短いリクエストの数が増えたとしても、サーバに与える負荷は少ない。他方、応答時間が長いリクエストの増加は、サーバに大きな負荷を与え、そのリクエストの応答時間も長期化する。そのため負荷分散では、応答時間が長いリクエストを複数サーバに分散させることで、性能の維持を図っている。そうすると、応答時間が閾値を超えたリクエストについて、応答時間の長期化の原因が過負荷なのか、その他の障害なのかを判断するに当たり、応答時間が長いリクエストに関する情報に基づいて予測値を計算するのが妥当である。それにも拘わらず応答時間が短いリクエストも含めて採取データの平均値を求め、予測値とすると、応答時間が長いリクエストの応答時間の平均値よりも低い予測値となる。低い予測値と実測値とを比較してスケールアウトの要否を判断すると、過負荷により応答時間が長期化した場合であっても、異常が発生したと誤判断してスケールアウトが行われない可能性がある。

図６は、スケールアウトの要否の誤判断の例を示す図である。図６では、横軸に同時リクエスト数、縦軸に応答時間を取っている。実行されたリクエストごとに採取された、同時リクエスト数と応答時間の実測値とを、黒い矩形で表している。また新たに実行されたリクエストの同時リクエスト数と応答時間とを、白抜きの矩形で表している。

図６の例では、同時リクエスト数「３」の新たなリクエストの応答時間が閾値を超えた場合と、同時リクエスト数「９」の新たなリクエストの応答時間が閾値を超えた場合とを想定している。

同時リクエスト数が「３」の過去のリクエストの応答時間の平均値は、応答時間の閾値の半分以下である。そのため、同時リクエスト数「３」の新たなリクエストの応答時間が閾値を超えた場合、障害が原因であると判断され、スケールアウトは行われない。これは正しい判断である。

同時リクエスト数が「９」の過去のリクエストの応答時間の平均値は、応答時間の閾値の半分以下である。そのため、同時リクエスト数「９」の新たなリクエストの応答時間が閾値を超えた場合、障害が原因であると判断され、スケールアウトは行われない。しかし、同時リクエスト数が「９」の過去のリクエストの中には、応答時間が閾値近くになっているものが多数有り、今回のリクエストの応答時間が閾値を超えた原因は、過負荷であると判断し、スケールアウトを行うのが妥当である。すなわち、同時リクエスト数が共通のすべてのリクエストの応答時間の平均値を予測値としてしまうと、スケールアウトの要否判断を誤ってしまう。

なお、リクエストの処理内容は、処理を実行する業務アプリケーションにより様々であり、アプリケーションも頻繁に変更される。そのため、リクエストの処理内容を解析して各リクエストの負荷が大きいか小さいかを判断するのは現実的ではない。

オートスケールが有用となるのは、サーバの追加により１台のサーバで処理する同時リクエスト数を削減することで、リクエスト応答時間が短くなる場合である。換言すると、同時リクエスト数が多くなり負荷が高くなるにつれてリクエストへの応答時間が長くなるような場合である。このような場合の同時リクエスト数とリクエストへの応答時間の関係をグラフ化した場合には、以下のような性質があることが分かる。

＜性質＞横軸を同時リクエスト数、縦軸をリクエスト応答時間としてグラフ化した場合、同時リクエスト数の増加に合わせてリクエスト応答時間が増加する右肩上がりのグラフとなる。

この右肩上がりのグラフの傾きを導き出せれば、障害などにより応答時間が長期化したリクエストと、過負荷によって応答時間が長期化したリクエストとを区別できるようになる。その結果、過負荷以外の原因で応答時間が長期化した場合、スケールアウトの実行を抑止し、リソースの過剰消費を抑止することができる。

また、リクエストの応答時間に占める他サーバとの通信時間を合わせて計測することにより、リクエスト応答時間の悪化の原因が、上位の階層の仮想サーバではなく、下位の階層の仮想サーバの処理時間の悪化であると判断することが可能となる。この場合、通信先である下位の階層の仮想サーバのスケールアウトを促すことで、適切な仮想サーバのスケールアウトが可能となる。

第２の実施の形態では、オートスケールの適切な要否判断を実現するため、集計データ作成処理、スケールアウトの要否判定処理、オートスケール委譲処理、およびスケールダウン判定処理を行う。以下、これらの処理について順に説明する。

＜集計データ作成処理＞
集計データ作成処理では、まず負荷分散装置１００，２００，３００，４００が負荷分散先のすべての仮想サーバについて、仮想サーバごとに以下の情報を蓄積する。
・リクエストへの応答時間
・そのリクエスト受付時の同時リクエスト数
・上位の階層のサーバが下位の階層のサーバと通信した場合における、通信先のサーバ名と通信が完了するまでの時間
次に負荷分散装置１００，２００，３００，４００は、蓄積した情報から、同時リクエスト数ごとの応答時間を集計し、集計データを算出する。集計データの算出において、各同時リクエスト数に関連付けて蓄積された応答時間のうち、ある程度以下の応答時間については、集計対象から除外される。

図７は、集計データの作成に使用する応答時間の一例を示す図である。図７のグラフは、横軸に同時リクエスト数、縦軸に応答時間を採っている。グラフ中の矩形が、同時リクエスト数に関連付けて蓄積された応答時間を表している。

負荷分散装置１００，２００，３００，４００は、各同時リクエスト数に関連付けられた応答時間の集計データを算出する際に、他の同時リクエスト数についての集計データに基づいて、応答時間を集計対象とするか否かを判断する。

例えば集計データを計算しようとする同時リクエスト数よりも少ない同時リクエスト数（グラフ上において左側）の中で、平均値が求められた同時リクエスト数が存在しない場合がある。その場合、負荷分散装置１００，２００，３００，４００は、集計データを計算しようとする同時リクエスト数のすべての応答時間の平均値を計算する。

また集計データを計算しようとする同時リクエスト数よりも少ない同時リクエスト数（グラフ上において左側）の中で、平均値が求められた同時リクエスト数が存在する場合がある。この場合、負荷分散装置１００，２００，３００，４００は、平均値が求められた同時リクエスト数のうち最大の同時リクエスト数の平均値を取得する。これは、グラフ上で左側に隣接する同時リクエスト数の平均値である。そして負荷分散装置１００，２００，３００，４００は、集計データを計算しようとする同時リクエスト数の応答時間のうち、取得した他の同時リクエスト数の平均値より大きい応答時間だけを集計対象とし、集計対象の応答時間の平均値を求める。

このような処理が、例えば同時リクエスト数の小さい方から順に実行される。そして同時リクエスト数ごとに計算された平均値が、集計データとなる。
ここで、グラフ上で左側に隣接する同時リクエスト数の平均値より大きい値だけの平均値を求める理由は以下の通りである。

業務システムでは、単なる情報の参照を行うような負荷の小さい処理と、ファイルの更新・データベースの更新・複雑なデータの計算を行うような負荷の大きい処理が混在してサーバ上で処理される。負荷の小さい参照系の処理は同時リクエスト数の増加にともなう応答時間の増加が少ない。これに対し、負荷の大きい更新系の処理は同時リクエスト数の増加にともなって応答時間の増加が顕著に表れる。この更新系の処理がシステム全体のレスポンス悪化に影響する。

そこで負荷分散装置１００，２００，３００，４００は、グラフ上で左側に隣接する同時リクエスト数の平均値と、集計データを計算しようとする同時リクエスト数の応答時間とを比較する。そして負荷分散装置１００，２００，３００，４００は、隣接する同時リクエスト数の平均値より大きい応答時間となった処理を、負荷の大きい処理であると想定することで、負荷の大きい処理の応答時間の傾向を調べる。これにより、負荷の大きい処理の応答時間のみを集計対象とした平均値の算出が可能となる。

負荷の大きい処理の応答時間のみを集計対象として平均値を算出した場合と、すべての応答時間の平均値を算出した場合とでは、平均値の傾向が異なる。
図８は、集計対象とする応答時間の違いによる平均値の傾向を示す図である。図８の左には、すべての応答時間を集計対象として平均値を求めた場合の、同時リクエスト数の増加に伴う平均値５１の増加傾向を示している。図８の右には、負荷の大きい処理の応答時間のみを集計対象として平均値を求めた場合の、同時リクエスト数の増加に伴う平均値５２の増加傾向を示している。図８に示すように、負荷の大きい処理の応答時間のみを集計対象として平均値を求めた場合の方が、同時リクエスト数の増加に応じた応答時間の増加傾向が強くなる。すなわち平均値を示す線の傾きが大きくなる。

データベースの更新系・参照系の処理を例にした場合、一般的には参照系の処理のリクエスト数の方が圧倒的に多い。例えばＳＮＳ（Social Networking Service）サイトの個人情報を想定すると、個人情報を更新するのに比べて、個人情報を照会する方が圧倒的に多い。この負荷の小さい参照系の処理を平均値に含めてしまうと、本当にスケールアウトが必要な負荷の高い処理の傾向を見誤り、オートスケールの必要性を誤判断してしまう。

＜スケールアウトの要否判定処理＞
リクエストへの応答時間が閾値を超過した場合、事前に求められた集計データから、応答時間の長期化の原因が、仮想サーバの過負荷なのかどうかが判断され、その判断結果により、スケールアウトの要否が決定される。すなわち、負荷増加以外の原因で応答時間が長期化したものと判断した場合には、スケールアウトは行わないものと決定される。応答時間の長期化の原因が、仮想サーバの過負荷なのかどうかは、閾値を超えた応答時間と、その応答時間に対応する同時リクエスト数の集計データとを比較して判断される。なお、リクエストへの応答時間が閾値を超過した後も、集計データの算出は繰り返し行われる。これにより、集計データの信頼性が向上する。

図９は、スケールアウトの要否判定例を示す図である。例えば、新たに蓄積された応答時間に対応する同時リクエスト数について、集計データが存在する場合、集計データと比較して応答時間が２倍以上の場合には、スケールアウトは行わないものと判定される。図９の例では、新たに蓄積されたのが、応答時間６１，６３のいずれかであれば、スケールアウトは行わないものと判定される。他方、新たに蓄積されたのが応答時間６５であれば、スケールアウトを行うものと判定される。

また、新たに蓄積された応答時間に対応する同時リクエスト数について、集計データが存在しない場合、他の複数の同時リクエスト数に対して集計データが存在するかどうかが判定される。他の複数の同時リクエスト数に対して集計データが存在する場合、集計データが存在する同時リクエスト数のうち、新たに蓄積された応答時間に対応する同時リクエスト数に近い方から２つの同時リクエスト数が特定される。さらに、特定された同時リクエスト数の集計データ（平均値）を通る一次式から、新たに蓄積された応答時間に対応する同時リクエスト数に対する集計データの推測値が算出される。そして、新たに蓄積された応答時間が、推測値の２倍以上の場合には、スケールアウトは行わないものと判定される。図９の例では、新たに蓄積されたのが応答時間６２，６４の場合、応答時間６２，６４に対応する同時リクエスト数に対し、グラフ上で両側に隣接する同時リクエスト数の集計データから、応答時間６２，６４に対応する同時リクエスト数の集計データが推測される。また新たに蓄積されたのが応答時間６６の場合、応答時間６６に対応する同時リクエスト数に対して、グラフ上で左側の直近の２つの同時リクエスト数の集計データから、応答時間６６に対応する同時リクエスト数の集計データが推測される。新たに蓄積されたのが応答時間６２の場合、スケールアウトは行わないものと判定される。他方、新たに蓄積されたのが応答時間６４，６６の場合、スケールアウトを行うものと判定される。

ところで、グラフ上で左に隣り合う同時リクエスト数の平均値より大きな値の応答時間のみの平均値を取るという方法を採用することで、同時リクエスト数の増加に応じた集計データの上昇傾向が多くなりすぎる場合も考えられる。このような場合、同時リクエスト数が増加したときに、集計対象となる応答時間が存在しない同時リクエスト数が発生する。その結果、同時リクエスト数の増加に応じた集計データの上昇傾向が、適切な範囲に抑止される。

図１０は、同時リクエスト数の増加に伴う集計データの上昇が抑制される例を示す図である。図１０に示すように、同時リクエスト数「２」から同時リクエスト数「３」にかけて、集計データが大きく上昇している。この場合、同時リクエスト数「４」において、集計対象とする応答時間が存在せず、応答時間の平均値が計算できない。このため同時リクエスト数「５」の集計データの計算では、同時リクエスト数「３」の集計データより大きな値の応答時間を集計対象として、集計データが計算される。

同時リクエスト数「４」の集計データは、同時リクエスト数「３」の集計データと同時リクエスト数「５」の集計データとから推定される。すなわち、同時リクエスト数「３」の集計データと同時リクエスト数「５」の集計データとを結ぶ直線（一次式）において、同時リクエスト数を「４」としたときの応答時間が、同時リクエスト数を「４」の集計データと推定される。このとき、同時リクエスト数「３」から同時リクエスト数「５」へは、同時リクエスト数が２増加しているため、その分、得られた一次式の傾きは抑制されている。

このように、いずれかの同時リクエスト数で、データ数が少ないために、集計データが大きくなりすぎたとしても、グラフ上で右に隣り合う同時リクエスト数の集計対象の応答時間が少なくなり、平均値の傾きが抑制される。そのため、異常値を除外するには十分な傾向を調べることができる。

＜オートスケールの委譲処理＞
負荷増加により応答時間が閾値を超過したと判断された場合、リクエスト応答時間と合わせて集計した他の仮想サーバとの通信時間が比較される。他の仮想サーバとの通信時間が全体の５０％以上を占めている場合には、負荷分散装置は、閾値を超過した応答時間の処理を実行した仮想サーバが通信した相手の仮想サーバにリクエストを振り分けている負荷分散装置に、オートスケールが委譲される。それ以外は、閾値を超過した応答時間の処理を実行した仮想サーバのスケールアウトが行われる。

オートスケールを委譲された負荷分散装置では、同時リクエスト数・応答時間・他の仮想サーバとの通信時間が解析され、さらにスケールアウトの要否が判断される。
例えば、オートスケールを委譲された負荷分散装置は、委譲元で応答時間が閾値を超えた処理を実行した、上位の階層の仮想サーバにおける、処理実行中の通信時間をＸ（Ｘは正の実数）とする。またオートスケールを委譲された負荷分散装置は、その上位の階層の仮想サーバとの通信によりリクエストを送信した下位の階層の仮想サーバの、そのリクエストに対する応答時間をＹ（Ｙは正の実数）とする。そしてオートスケールを委譲された負荷分散装置は、ＹがＸの８０％以上であるかを判断する。ＹがＸの８０％以上でなければ、スケールアウトを行わないものと決定される。

このような判断を行う理由は、仮想サーバ間は通信されるためネットワーク通信がボトルネックとなっている可能性があるためである。ネットワーク通信に時間がかかっているとサーバを増やしても性能は改善されないため、ＹがＸの８０％以上でなければ、スケールアウトを行わないと決定される。

ＹがＸの８０％以上の場合には、委譲先の負荷分散装置において、応答時間Ｙと、下位の階層の仮想サーバにおいて、応答時間Ｙとなった処理の実行過程における、他のサーバとの通信時間とを比較する。他サーバとの通信時間が、応答時間Ｙの５０％以上を占めている場合には、委譲先の負荷分散装置は、通信先の仮想サーバへのリクエストを振り分ける負荷分散装置に、オートスケールを委譲する。該当しない場合には、スケールアウトのオートスケールを実行するものと決定される。

下位の階層の仮想サーバとの通信が発生している限り、オートスケールを行うのか、委譲するのかの判断が、各階層にリクエストを振り分ける負荷分散装置で繰り返し行われる。

図１１は、オートスケールの委譲例を示す図である。図１１の例では、最上位の階層の仮想サーバ４１ａ，４１ｂにリクエストを振り分ける負荷分散装置１００から、次の階層の仮想サーバ４２ａ，４２ｂにリクエストを振り分ける負荷分散装置２００に、オートスケール委譲要求が送信されている。さらに、負荷分散装置２００から、次の階層の仮想サーバ４４ａ，４４ｂにリクエストを振り分ける負荷分散装置４００に、オートスケール委譲要求が送信されている。

このように、上位の階層から下位の階層へ、順番にオートスケールを行うのか、委譲するのかの判断を行うことで、応答時間のボトルネックとなっている仮想サーバと特定し、その仮想サーバのスケールアウトを行うことができる。なお、オートスケールを委譲された負荷分散装置では、自身が蓄積した応答時間の閾値を超えていなくても、オートスケールを委譲されたことで、自分自身より下位の階層のどこかが、上位の階層の仮想サーバの応答時間を悪化させていることを認識できる。その結果、システム全体として、応答時間が長期化する状態を、迅速に解消することができる。

＜スケールダウン判定処理＞
各負荷分散装置１００，２００，３００，４００は、応答時間が十分短い状況が長時間継続した場合に、スケールダウンすることを決定する。例えば、応答時間が十分短い状況が３０分継続したら、長時間継続したと判断することができる。また応答時間の閾値の１／２を、十分に短い応答時間とすることができる。なお、どの程度の時間を長時間とするのか、またはどの程度の時間を十分に短い応答時間とするのかは、システム管理者が適宜変更可能である。

なお、仮想サーバ自体のリクエスト応答時間が十分短いと判断されても、オートスケールを委譲されたことがある場合、スケールダウンしてしまうと上位の階層の仮想サーバにおける応答時間の長期化を招く場合がある。このため、スケールダウンの要否を、以下のように判定する。

・スケールアウトのオートスケール委譲元の場合
各負荷分散装置１００，２００，３００，４００は、スケールアウトのオートスケールを委譲する時に、委譲先の負荷分散装置のホスト名と、委譲した順番に記憶する。また、自分自身がオートスケールした場合、委譲した順番と合わせていつ自分自身がスケールアウトしたかを記憶する。例えば、「負荷分散装置１に委譲」、「負荷分散装置２に委譲」、「自分自身がスケールアウト」、「負荷分散装置１に委譲」、「負荷分散装置３に委譲」というような情報を記憶する。

各負荷分散装置１００，２００，３００，４００は、リクエスト応答時間が十分短い状況が長時間続いていると判断した場合、スケールアウトのオートスケールを委譲した順番とは逆の順に、スケールダウンのオートスケールを指示する。例えば上記の例の場合、スケールダウンを指示する順番は、「負荷分散装置３」、「負荷分散装置１」、「自分自身」、「負荷分散装置２」、「負荷分散装置１」となる。

・スケールアウトのオートスケール委譲先の場合
各負荷分散装置１００，２００，３００，４００は、オートスケールの委譲によりスケールアウトした時に、追加仮想サーバ数をカウントアップし、委譲元からの指示でスケールダウンを実施した場合には、追加仮想サーバ数をカウントダウンする。各負荷分散装置１００，２００，３００，４００は、応答時間が十分短い状況と判断しても、追加仮想サーバ数が１以上の場合にはスケールダウンを行わないものと決定し、追加仮想サーバ数が０の時はスケールダウンを行うものと決定する。また、スケールダウンのオートスケールが委譲された場合、委譲元からのスケールアウトのオートスケール委譲要求に応じたスケールアウトが過去に行われていれば、スケールダウンを行うものと決定する。このようにして、多階層システム内の複数の負荷分散装置それぞれが、過度にスケールダウンを行い、システム全体としての応答時間を長期化させてしまうことを抑止できる。

以下、第２の実施の形態における負荷分散装置の機能について詳細に説明する。
図１２は、負荷分散装置の機能構成の一例を示すブロック図である。負荷分散装置１００，２００は、リクエスト受付部１１０，２１０、負荷分散制御部１２０，２２０、オートスケール要否判定部１３０，２３０、管理情報記憶部１４０，２４０、オートスケール要求部１５０，２５０、オートスケール委譲要求部１６０，２６０、およびオートスケール委譲受付部１７０，２７０を有する。

リクエスト受付部１１０，２１０は、外部からの処理のリクエストを受け付ける。例えば負荷分散装置１００のリクエスト受付部１１０は、端末装置３１，３２，・・・が送信したリクエストを受け付ける。また負荷分散装置２００のリクエスト受付部２１０は、物理サーバ４１内の仮想サーバ４１ａ，４１ｂが送信したリクエストを受け付ける。リクエスト受付部１１０，２１０は、受け付けたリクエストを負荷分散制御部１２０，２２０に送信する。またリクエスト受付部１１０，２１０は、負荷分散制御部１２０，２２０からリクエストに対する応答を受信すると、受信した応答を、リクエストの送信元に返信する。

負荷分散制御部１２０，２２０は、リクエストを受信すると、そのリクエストを仮想サーバに転送する。その際、負荷分散制御部１２０，２２０は、転送先の仮想サーバが複数あれば、その複数の仮想サーバ間で負荷が均等化されるように、リクエストの転送先を決定する。また負荷分散制御部１２０，２２０は、リクエストに対する応答を仮想サーバから受信すると、受信した応答を、リクエスト受付部１１０，２１０に転送する。

さらに負荷分散制御部１２０，２２０は、リクエストに対する応答を仮想サーバから受信した場合、そのリクエストの応答時間と同時リクエスト数とを求める。リクエストの応答時間は、リクエストを送信してから応答を受信するまでの経過時間である。例えば負荷分散制御部１２０，２２０は、リクエストを仮想サーバに送信する際に、リクエストの識別子に対応付けて送信時刻を記憶する。そして負荷分散制御部１２０，２２０は、応答を受信すると、応答内容に付与されたリクエストの識別子に基づいて、対応するリクエストの送信時刻を判断し、その送信時刻から応答を受信した時刻までの経過時間を計測し、応答時間とする。

同時リクエスト数は、リクエストの送信先の仮想サーバにおける、そのリクエストの受け付け時点で処理途中のリクエストの数である。換言すると、負荷分散制御部１２０，２２０から仮想サーバに送信したリクエストのうち、その仮想サーバからの応答を受信していないリクエストの数である。例えば、負荷分散制御部１２０，２２０は、仮想サーバごとに、その仮想サーバに送信し、応答を未受信のリクエストの数（同時リクエスト数）をカウントする。そして負荷分散制御部１２０，２２０は、新たなリクエストを仮想サーバに送信するとき、リクエスト送信前の時点での仮想サーバの同時リクエスト数に１を加算した値を、そのリクエストの実行開始時における同時リクエスト数とする。

負荷分散制御部１２０，２２０は、例えば、送信したリクエストの実行開始時における同時リクエスト数を、そのリクエストの識別子に対応付けてメモリに保持する。そして負荷分散制御部１２０，２２０は、リクエストに対する応答を受信すると、そのリクエストの識別子に対応付けられた同時リクエスト数と応答時間との組を、オートスケール要否判定部１３０，２３０に送信する。

また負荷分散制御部１２０，２２０は、リクエストを送信した仮想サーバが、そのリクエストに応じた処理の過程で、さらに下位の仮想サーバへリクエストを送信した場合、下位の仮想サーバとの間の通信時間を取得する。例えば負荷分散制御部１２０，２２０は、リクエストに対する応答を仮想サーバから受信すると、その仮想サーバから、そのリクエストに応じた処理の実行中に下位層の仮想サーバに処理のリクエストを送信してから応答を受信するまでの時間を取得する。そして負荷分散制御部１２０，２２０は、取得した時間を通信時間として、負荷分散制御部１２０，２２０が送信したリクエストの識別子に対応付けて、オートスケール要否判定部１３０，２３０に送信する。

オートスケール要否判定部１３０，２３０は、オートスケールを実行するかどうかを判定する。例えばオートスケール要否判定部１３０，２３０は、負荷分散制御部１２０，２２０から受信した、リクエストごとの同時リクエスト数と応答時間との組を、管理情報記憶部１４０，２４０を用いて管理する。そしてオートスケール要否判定部１３０，２３０は、例えばリクエストに対する応答を負荷分散制御部１２０，２２０が受信するごとに、管理情報記憶部２４０内に格納した情報に基づいて、オートスケールの要否判断を行う。またオートスケール要否判定部１３０，２３０は、オートスケール委譲受付部１７０，２７０を介して、他の負荷分散装置からのオートスケール委譲要求を取得した場合にも、オートスケールの要否判断を行う。

各負荷分散装置１００，２００でのオートスケールの要否判断では、その負荷分散装置１００，２００からのリクエストの振り分け先となる仮想サーバ群について、オートスケールを実行するか否かを判断する。例えばオートスケール要否判定部１３０は、負荷分散制御部１２０がリクエストの振り分け先としている仮想サーバ４１ａ，４１ｂの数を増加させるか、減少させるかの判断を行う。同様にオートスケール要否判定部２３０は、負荷分散制御部２２０がリクエストの振り分け先としている仮想サーバ４２ａ，４２ｂの数を増加させるか、減少させるかの判断を行う。オートスケール要否判定部１３０，２３０は、オートスケールを実施すると判断した場合、オートスケール要求部１５０，２５０に、オートスケール要求の送信を依頼する。

またオートスケール要否判定部１３０，２３０は、その負荷分散装置１００，２００からのリクエストの振り分け先となる仮想サーバ群よりも下位の階層のサーバ群のオートスケールの実行の要否も判断する。オートスケール要否判定部１３０，２３０は、下位の階層のサーバ群のオートスケールを実行すると判断した場合、オートスケール委譲要求部１６０，２６０にオートスケール委譲要求の送信を依頼する。

管理情報記憶部１４０，２４０は、オートスケールの要否判定に用いる情報を記憶する。例えば管理情報記憶部１４０，２４０は、リクエストごとの同時リクエスト数、リクエスト応答時間、またはそれらの集計データなどを記憶する。また管理情報記憶部１４０，２４０は、例えばリクエストごとの通信時間や、通信時間の集計データを記憶する。例えば負荷分散装置１００，２００のメモリまたはＨＤＤの記憶領域の一部が、管理情報記憶部１４０，２４０として使用される。なお管理情報記憶部１４０，２４０に記憶される情報の詳細は後述する（図１３〜図１９参照）。

オートスケール要求部１５０，２５０は、オートスケール要否判定部１３０，２３０からのオートスケール要求の送信依頼に応じて、仮想化装置４５に対して、オートスケール要求を送信する。オートスケール要求には、例えば、どの物理サーバで実行されている仮想サーバに対するオートスケールなのか、スケールアウトとスケールダウンとの何れを行うのか、といったことに関する情報が含まれる。

オートスケール委譲要求部１６０，２６０は、オートスケール要否判定部１３０，２３０からのオートスケール委譲要求の送信依頼に応じて、下位の階層の仮想化装置に対するリクエストを分配する負荷分散装置に対して、オートスケール委譲要求を送信する。

オートスケール委譲受付部１７０，２７０は、他の負荷分散装置からのオートスケール委譲要求を受け付ける。そしてオートスケール委譲受付部１７０，２７０は、受け付けたオートスケール委譲要求を、オートスケール要否判定部１３０，２３０に送信する。

このような構成の負荷分散装置１００，２００とすることで、多階層システム全体での適切なオートスケールが可能となる。なお、図１２に示していない他の負荷分散装置３００，４００も、負荷分散装置１００，２００と同様の機能を有している。また、図１２に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。さらに、図１２に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

図１に示した第１の実施の形態の管理装置１０の機能と、図１２に示した第２の実施の形態の負荷分散装置１００，２００の機能との関係は以下の通りである。
管理装置１０の振り分け手段１１の機能は、負荷分散装置１００，２００のリクエスト受付部１１０，２１０と負荷分散制御部１２０，２２０とによって実現されている。管理装置１０の蓄積手段１２，算出手段１４、および決定手段１５の機能は、負荷分散装置１００，２００のオートスケール要否判定部１３０，２３０によって実現されている。管理装置１０の記憶手段１３は、負荷分散装置１００，２００の管理情報記憶部１４０，２４０によって実現されている。

次に、管理情報記憶部１４０，２４０に記憶される情報について詳細に説明する。
図１３は、管理情報記憶部に記憶される情報の一例を示す図である。図１３の例では、管理情報記憶部１４０，２４０には、応答時間管理テーブル１４１，２４１、応答時間集計情報１４２，２４２、通信時間管理テーブル１４３，２４３、通信時間集計情報１４４，２４４、委譲先管理テーブル１４５，２４５、および委譲元管理テーブル１４６，２４６が格納されている。

応答時間管理テーブル１４１，２４１は、リクエストの同時リクエスト数と応答時間とを管理するデータテーブルである。応答時間集計情報１４２，２４２は、リクエストの応答時間を同時リクエスト数ごとに集計した、集計結果である。通信時間管理テーブル１４３，２４３は、リクエスト送信先の仮想サーバにおける、リクエストに応じた処理実行時の、下位層の仮想サーバとの間の通信時間を管理するデータテーブルである。通信時間集計情報１４４，２４４は、通信時間を同時リクエスト数ごとに集計した、集計結果である。委譲先管理テーブル１４５，２４５は、オートスケールを委譲した場合の委譲先を管理するデータテーブルである。委譲元管理テーブル１４６，２４６は、オートスケールを委譲された場合の委譲元を管理するデータテーブルである。

以下、管理情報記憶部１４０内の各情報のデータ構造について、具体例を用いて説明する。
図１４は、応答時間管理テーブルのデータ構造の一例を示す図である。応答時間管理テーブル１４１には、ＩＤ、リクエスト送信先仮想サーバ名、同時リクエスト数、およびリクエスト応答時間の欄が設けられている。応答時間管理テーブル１４１には、仮想サーバに送信したリクエストごとのレコードが登録される。

ＩＤの欄には、仮想サーバに送信したリクエストの識別子が設定される。リクエスト送信先仮想サーバ名の欄には、リクエストの送信先となった仮想サーバの名称が設定される。同時リクエスト数の欄には、リクエスト送信時の送信先の仮想サーバにおける同時リクエスト数が設定される。リクエスト応答時間の欄には、リクエストに対する応答時間が、例えばミリ秒単位で設定される。

図１５は、応答時間集計情報のデータ構造の一例を示す図である。応答時間集計情報１４２には、リクエストの送信先となる仮想サーバごとの集計情報１４２ａ，１４２ｂが含まれている。仮想サーバごとの集計情報１４２ａ，１４２ｂには、同時リクエスト数に対応付けて、その同時リクエスト数のときに実行が開始されたリクエストの応答時間に関する集計データが設定される。

応答時間集計情報１４２における集計データは、集計データ計算対象の同時リクエスト数の列に対して、左に隣り合う列の集計データ以上の応答時間を有するリクエストの、応答時間の平均値である。例えば集計情報１４２ａは、名称「host1」の仮想サーバに関する集計結果が登録されている。図１４の例では、名称「host1」の仮想サーバに対して送信されたリクエストのうち、同時リクエスト数「３」のリクエストが３つある（ＩＤ「３」、「５」、「７」のリクエスト）。これらのリクエストの応答時間の実測値は、それぞれ「４０００」、「１４０００」、「１２０００」である。このうち、「４０００」については、同時リクエスト数「３」の列の左側の列（同時リクエスト数「１」）の集計データ「１１０００」より小さい。そのため、「４０００」を除外した、「１４０００」と「１２０００」との平均値「１３０００」が、同時リクエスト数「３」の集計データとなる。

図１６は、通信時間管理テーブルのデータ構造の一例を示す図である。通信時間管理テーブル１４３には、ＩＤ、リクエスト送信先仮想サーバ名、同時リクエスト数、通信先仮想サーバ名、および通信時間の欄が設けられている。通信時間管理テーブル１４３には、仮想サーバに送信したリクエストごとのレコードが登録される。

ＩＤの欄には、仮想サーバに送信したリクエストの識別子が設定される。リクエスト送信先仮想サーバ名の欄には、リクエストの送信先となった仮想サーバの名称が設定される。同時リクエスト数の欄には、リクエスト送信時の送信先の仮想サーバにおける同時リクエスト数が設定される。通信先仮想サーバ名の欄には、リクエスト送信先の仮想サーバがリクエストに応じた処理中に下位層の仮想サーバと通信した場合における、通信相手の仮想サーバの名称が設定される。通信時間の欄には、リクエスト送信先の仮想サーバがリクエストに応じた処理中に下位層の仮想サーバと通信した場合における、通信相手の仮想サーバとの通信時間が設定される。

図１７は、通信時間集計情報のデータ構造の一例を示す図である。通信時間集計情報１４４には、リクエストの送信先となる仮想サーバと、その仮想サーバとの通信相手となる仮想サーバとの組み合わせごとの集計情報１４４ａ，１４４ｂ，１４４ｃ，１４４ｄが含まれている。各集計情報１４４ａ，１４４ｂ，１４４ｃ，１４４ｄには、同時リクエスト数に対応付けて、リクエストの送信先の仮想サーバと通信相手の仮想サーバとの間の通信時間に関する通信時間集計データが設定される。

通信時間集計データは、リクエストの送信先の仮想サーバと通信相手の仮想サーバとの組み合わせに対応する、同時リクエスト数が同一のリクエストに関する通信時間の平均値である。なお、応答時間の集計データと同様に、同時リクエスト数が少ないときの通信時間集計データ以上の値を用いて、同時リクエスト数が多いときの通信時間集計データを算出してもよい。例えばオートスケール要否判定部１３０は、集計データ計算対象の同時リクエスト数の列に対して、左に隣り合う列の通信時間集計データの値以上の通信時間を有するリクエストのみの通信時間を通信時間管理テーブル１４３から抽出する。そしてオートスケール要否判定部１３０は、抽出した通信時間の平均値を、集計データ計算対象の同時リクエスト数に対応する通信時間集計データとする。

図１８は、委譲先管理テーブルのデータ構造の一例を示す図である。委譲先管理テーブル１４５には、オートスケールを委譲した順番を示す番号（委譲順）に対応付けて、委譲先の負荷分散装置の名称が設定されている。委譲先管理テーブル１４５には、スケールアウトのオートスケール委譲要求が送信されるごとに、新たなレコードが、委譲順の最後尾に追加される。またスケールダウンのオートスケール委譲要求が送信されるごとに、委譲先管理テーブル１４５の委譲順の最後尾のレコードが削除される。

図１９は、委譲元管理テーブルのデータ構造の一例を示す図である。委譲元管理テーブル１４６には、委譲元の負荷分散装置名に対応付けて、その負荷分散装置から受け取ったオートスケール委譲要求によるスケールアウトで追加された仮想サーバ数が設定されている。

図１４〜図１９には負荷分散装置１００が有する情報のデータ構造の例を示したが、他の負荷分散装置２００，３００，４００も、負荷分散装置１００と同様の情報を有している。

図１４〜図１９に示したような情報を利用して、スケールアウト要否判断が行われる。以下に、スケールアウト要否判断は、例えばリクエスト受信時に実行される。
図２０は、スケールアウト要否判断を伴うリクエスト振り分け処理の手順の一例を示すフローチャートである。図２０に示す処理は、各負荷分散装置１００，２００，３００，４００がリクエスト受信時に実行するものであるが、以下の説明では、負荷分散装置１００が実行する場合を例に採って説明する。

［ステップＳ１０１］リクエスト受付部１１０が、端末装置３１，３２，・・・からの処理のリクエストを受け付ける。リクエスト受付部１１０は、受け付けたリクエストを負荷分散制御部１２０に転送する。

［ステップＳ１０２］負荷分散制御部１２０は、振り分け先の仮想サーバを決定し、リクエストを振り分ける。例えば負荷分散制御部１２０は、振り分け可能な仮想サーバ間の負荷が均等になるようなアルゴリズムで、振り分け先の仮想サーバを決定する。そして負荷分散制御部１２０は、振り分け先に決定した仮想サーバにリクエストを送信する。

［ステップＳ１０３］負荷分散制御部１２０は、リクエストを送信した仮想サーバからの応答を待つ。そして負荷分散制御部１２０は、リクエストに対する応答を受信すると、そのリクエスト実行開始時における仮想サーバでの同時リクエスト数と、応答時間とをオートスケール要否判定部１３０に通知する。また負荷分散制御部１２０は、リクエスト送信先の仮想サーバから、リクエストに応じた処理の実行過程で通信した仮想サーバの名称と、通信時間とを取得する。

［ステップＳ１０４］オートスケール要否判定部１３０は、同時リクエスト数、応答時間、および通信時間を、管理情報記憶部１４０に格納する。例えばオートスケール要否判定部１３０は、同時リクエスト数と応答時間との組と、リクエストの送信先である仮想サーバの名称とを対応付けて、管理情報記憶部１４０内の応答時間管理テーブル１４１に登録する。またオートスケール要否判定部１３０は、リクエスト送信先の仮想サーバの名称、同時リクエスト数、リクエスト送信先の仮想サーバが通信したときの通信先仮想サーバ名、および通信時間を対応付けて、通信時間管理テーブル１４３に登録する。

［ステップＳ１０５］オートスケール要否判定部１３０は、ステップＳ１０２で振り分けたリクエストに対する応答時間が、予め設定された閾値を超過したか否かを判断する。閾値を超過した場合、処理がステップＳ１０７に進められる。閾値を超過していなければ、処理がステップＳ１０６に進められる。

［ステップＳ１０６］応答時間が閾値を超過していない場合、オートスケール要否判定部１３０は、集計データを算出する。なお集計データ算出処理の詳細は後述する（図２１参照）。集計データの算出が完了すると、処理が終了する。

［ステップＳ１０７］応答時間が閾値を超過している場合、オートスケール要否判定部１３０は、応答時間長期化の原因が、システム内のどこかの処理での過負荷なのかどうかを判定する。なお、過負荷かどうかの判定処理の詳細は、後述する（図２２参照）。

［ステップＳ１０８］オートスケール要否判定部１３０は、応答時間長期化の原因が過負荷であると判定した場合、処理をステップＳ１０９に進める。またオートスケール要否判定部１３０は、応答時間長期化の原因は過負荷ではないと判定した場合、処理を終了する。

［ステップＳ１０９］オートスケール要否判定部１３０は、応答時間長期化の原因が過負荷と判定された場合、過負荷箇所判定処理を行う。過負荷箇所判定処理では、過負荷となっているのが、負荷分散装置１００がリクエストの振り分け先としている階層の仮想サーバなのかどうかが判定される。そして振り分け先としている階層の仮想サーバの過負荷ではないと判定された場合には、下位の階層の仮想サーバへのリクエストの振り分けを行う他の負荷分散装置に、オートスケールが委譲される。過負荷箇所判定処理の詳細は、後述する（図２３参照）。

［ステップＳ１１０］オートスケール要否判定部１３０は、ステップＳ１０９においてオートスケールを委譲した場合、処理を終了する。オートスケール要否判定部１３０は、ステップＳ１０９においてオートスケールを委譲していない場合、処理をステップＳ１１１に進める。なおオートスケールを委譲していない場合とは、負荷分散装置１００がリクエストの振り分け先としている階層の仮想サーバが過負荷となっていると判定された場合である。

［ステップＳ１１１］オートスケール要否判定部１３０は、負荷分散装置１００がリクエストを振り分ける仮想サーバ群のスケールアウトを行うことを決定する。そしてオートスケール要否判定部１３０は、オートスケール要求部１５０に、スケールアウトのオートスケール要求の送信を依頼する。するとオートスケール要求部１５０が、仮想化装置４５に、スケールアウトのオートスケール要求を送信する。オートスケール要求を受信した仮想化装置４５は、物理サーバ４１に対して、新たな仮想サーバの起動と、その仮想サーバによるサービスの運用開始を指示する。この際、オートスケール要否判定部１３０は、委譲先管理テーブル１４５に、自分自身を示す情報（例えば負荷分散装置１００の識別子）を登録する。

このようにして、リクエスト受信時におけるリクエストの振り分けや、オートスケール要否判定などが行われる。
次に、集計データ算出処理について詳細に説明する。

図２１は、集計データ算出処理の手順の一例を示すフローチャートである。
［ステップＳ１２１］オートスケール要否判定部１３０は、応答時間集計情報１４２内の、今回実行されたリクエストの送信先の仮想サーバ（以下、図２１の説明において「集計対象の仮想サーバ」とする）の集計情報を参照する。そしてオートスケール要否判定部１３０は、今回実行されたリクエストの同時リクエスト数（以下、図２１の説明において「集計対象の同時リクエスト数」とする）よりも少ない同時リクエスト数の集計データが存在するか否かを判断する。該当する集計データが存在すれば、処理がステップＳ１２３に進められる。該当する集計データが存在しなければ、処理がステップＳ１２２に進められる。

［ステップＳ１２２］ステップＳ１２１において該当する集計データがないと判定された場合、オートスケール要否判定部１３０は、集計対象の同時リクエスト数の各リクエストの応答時間の平均を算出する。例えばオートスケール要否判定部１３０は、応答時間管理テーブル１４１から、集計対象の仮想サーバと集計対象の同時リクエスト数との組み合わせを有するレコードを抽出する。そしてオートスケール要否判定部１３０は、抽出したレコードの応答時間の算術平均を計算する。その後、処理がステップＳ１２５に進められる。

［ステップＳ１２３］オートスケール要否判定部１３０は、応答時間集計情報１４２内の、集計対象の仮想サーバの集計情報を参照する。そしてオートスケール要否判定部１３０は、集計対象の同時リクエスト数よりも少ない同時リクエスト数の中で、集計対象の同時リクエスト数に最も近い同時リクエスト数の集計データを、参照した集計情報から取得する。

［ステップＳ１２４］オートスケール要否判定部１３０は、集計対象の同時リクエスト数の各リクエストのうち、ステップＳ１２３で取得した集計データよりも応答時間が大きいリクエストの、応答時間の平均を算出する。例えばオートスケール要否判定部１３０は、応答時間管理テーブル１４１から、集計対象の仮想サーバと集計対象の同時リクエスト数との組み合わせを有するレコードを抽出する。そしてオートスケール要否判定部１３０は、抽出したレコードのうち、ステップＳ１２３で取得した集計データよりも応答時間が大きなレコードの、応答時間の算術平均を計算する。

［ステップＳ１２５］オートスケール要否判定部１３０は、算出した平均値を集計データとして登録する。例えばオートスケール要否判定部１３０は、集計対象の仮想サーバの集計情報に対し、その集計情報における集計対象の同時リクエスト数の集計データとして、算出した平均値を登録する。

［ステップＳ１２６］オートスケール要否判定部１３０は、登録した集計データの同時リクエスト数よりも大きな同時リクエスト数の集計データを更新する。例えばオートスケール要否判定部１３０は、集計対象の仮想サーバの集計情報のうち、ステップＳ１２５で更新した集計データの同時リクエスト数よりも大きな同時リクエスト数を、値の小さい方から順に選択する。そしてオートスケール要否判定部１３０は、選択した同時リクエスト数を順次、集計対象の同時リクエスト数として、ステップＳ１２３〜Ｓ１２５における今の処理を実行し、その同時リクエスト数の集計データを更新する。

このようにして、集計データが算出される。次に、過負荷判定処理について詳細に説明する。
図２２は、過負荷判定処理の手順の一例を示すフローチャートである。

［ステップＳ１３１］オートスケール要否判定部１３０は、応答時間が閾値を超えたリクエストの同時リクエスト数（以下、図２２の説明において「判定対象の同時リクエスト数」とする）の集計データを取得する。例えばオートスケール要否判定部１３０は、応答時間集計情報１４２内の、応答時間が閾値を超えたリクエストの処理を実行した仮想サーバ（以下、図２２の説明において「応答遅延仮想サーバ」とする）に対応する集計情報を参照する。そしてオートスケール要否判定部１３０は、参照した集計情報における、判定対象の同時リクエスト数に対応付けられた集計データを取得する。

［ステップＳ１３２］オートスケール要否判定部１３０は、ステップＳ１３１の処理において、判定対象の同時リクエスト数の集計データが取得できたか否かを判断する。例えば応答遅延仮想サーバの集計情報に、判定対象の同時リクエスト数に対応付けられた集計データが登録されていれば、その集計データを取得できる。他方、応答遅延仮想サーバの集計情報に、判定対象の同時リクエスト数に対応付けられた集計データが登録されていなければ、集計データを取得できない。集計データを取得できた場合、処理がステップＳ１３５に進められる。集計データが取得できなかった場合、処理がステップＳ１３３に進められる。

［ステップＳ１３３］ステップＳ１３１で集計データが取得できなかった場合、オートスケール要否判定部１３０は、応答時間集計情報１４２内の応答遅延仮想サーバの集計情報に、複数の同時リクエスト数に対して集計データが存在するか否かを判断する。集計データが設定された同時リクエスト数が２以上あれば、処理がステップＳ１３４に進められる。集計データが設定された同時リクエスト数が１以下であれば、処理がステップＳ１３６に進められる。

［ステップＳ１３４］集計データが設定された同時リクエスト数が２以上あれば、オートスケール要否判定部１３０は、すでに設定されている集計データに基づいて、判定対象の同時リクエスト数の集計データを推定する。例えばオートスケール要否判定部１３０は、応答時間集計情報１４２内の応答遅延仮想サーバに対応する集計情報において、集計データが設定された同時リクエスト数を抽出する。そしてオートスケール要否判定部１３０は、抽出した同時リクエスト数のうち、判定対象の同時リクエスト数に最も近い同時リクエスト数と、２番目に近い同時リクエスト数とを特定する。次にオートスケール要否判定部１３０は、特定した２つの同時リクエスト数に対応付けられた集計データに基づいて、同時リクエスト数と集計データとの関係を示す一次関数を求める。横軸に同時リクエスト数、縦軸に集計データを採ったグラフで、求められた一次関数を表すと、特定した２つの同時リクエスト数と集計データとを示す２つの点を通る直線となる。オートスケール要否判定部１３０は、求めた一時関数に基づいて、判定対象の同時リクエスト数における集計データを推定する。すなわちオートスケール要否判定部１３０は、求めた一次関数に、判定対象の同時リクエスト数を代入することで得られる集計データの値を、判定対象の同時リクエスト数の集計データと推定する。

［ステップＳ１３５］オートスケール要否判定部１３０は、応答時間が閾値を超えたリクエストの応答時間（実測値）が、判定対象の同時リクエスト数の集計データの２倍以上か否かを判断する。応答時間が集計データの２倍以上であれば、処理がステップＳ１３６に進められる。応答時間が集計データの２倍未満であれば、処理がステップＳ１３７に進められる。

［ステップＳ１３６］判定対象の同時リクエスト数の集計データが存在せず、推定もできない場合、および応答時間が閾値を超えたリクエストの応答時間が集計データの２倍以上の場合、オートスケール要否判定部１３０は、応答時間の長期化要因が過負荷以外であると判定する。その後、過負荷判定処理が終了する。

［ステップＳ１３７］応答時間が閾値を超えたリクエストの応答時間が集計データの２倍未満の場合、オートスケール要否判定部１３０は、応答時間の長期化要因が、過負荷であると判定する。その後、過負荷判定処理が終了する。

このようにして、応答時間が長期化した原因が、過負荷なのか、別の原因なのかが判定される。過負荷が原因であると判定された場合、過負荷箇所判定処理が行われる。
図２３は、過負荷箇所判定処理の手順の一例を示すフローチャートである。

［ステップＳ１４１］オートスケール要否判定部１３０は、今回のリクエストの応答時間と、そのリクエストの同時リクエスト数に対応する通信時間とを比較する。例えばオートスケール要否判定部１３０は、通信時間集計情報１４４内の、今回のリクエストの送信先の仮想サーバに対応する集計情報から、そのリクエストの同時リクエスト数に対応付けられた通信時間集計データを取得する。そしてオートスケール要否判定部１３０は、取得した通信時間を、リクエストの応答時間で除算する。

なお比較対象の通信時間としては、今回のリクエストに応じた処理を実行した仮想サーバが、その実行過程で他の仮想サーバと通信した時間（実時間）を用いることもできる。

［ステップＳ１４２］オートスケール要否判定部１３０は、リクエストに応じた処理の実行過程での通信時間が、処理全体の５０％以上を占めているか否かを判断する。例えば通信時間を応答時間で除算したとき、除算結果が０．５以上であれば、通信時間が処理全体の５０％以上を占めている。通信時間が処理全体の５０％以上を占めている場合、過負荷となっているのが、負荷分散装置１００がリクエストを振り分けている仮想サーバ以外であると判定され、処理がステップＳ１４３に進められる。通信時間が処理全体の５０％未満の場合、過負荷となっているのが、負荷分散装置１００がリクエストを振り分けている仮想サーバであると判定され、過負荷箇所判定処理が終了する。

［ステップＳ１４３］オートスケール要否判定部１３０は、通信時間が処理全体の５０％以上を占めている場合、今回のリクエストの処理を実行した仮想サーバが、その処理の実行過程で通信した相手の負荷分散装置を特定する。そしてオートスケール要否判定部１３０は、特定した負荷分散装置の名称を、委譲先管理テーブル１４５の最後尾に追加登録する。

［ステップＳ１４４］オートスケール要否判定部１３０は、オートスケール委譲要求部１６０に対し、ステップＳ１４３で特定した負荷分散装置へのオートスケール委譲要求の送信を依頼する。するとオートスケール委譲要求部１６０が、特定された負荷分散装置へ、スケールアウトのオートスケール委譲要求を送信する。なおオートスケール委譲要求には、応答時間が閾値を超えたリクエストの識別子、そのリクエスト実行時の仮想サーバによる他の仮想サーバとの通信時間、負荷分散装置１００自身の名称が含められる。

次に、スケールアウトのオートスケール委譲要求を受信した負荷分散装置における処理（被委譲スケールアウト処理）について説明する。
図２４は、被委譲スケールアウト処理の手順の一例を示すフローチャートである。以下、図２４に示す処理を負荷分散装置２００が実行するものとして説明する。

［ステップＳ１５１］オートスケール委譲受付部２７０は、負荷分散装置１００から、スケールアウトのオートスケール委譲要求を取得する。そしてオートスケール委譲受付部２７０は、取得したオートスケール委譲要求を、オートスケール要否判定部２３０に転送する。

［ステップＳ１５２］オートスケール要否判定部２３０は、上位の階層の仮想サーバにおいて応答時間が閾値を超えたリクエストの実行過程で、下位の階層の仮想サーバに出力されたリクエストの応答時間を求める。例えばオートスケール要否判定部２３０は、応答時間管理テーブル２４１から、オートスケール委譲要求に示されるリクエストの識別子に対応する応答時間を取得する。取得した応答時間が、下位の階層の仮想サーバに出力されたリクエストの応答時間である。

［ステップＳ１５３］オートスケール要否判定部２３０は、応答時間が通信時間の８０％以上か否かを判断する。例えばオートスケール要否判定部２３０は、ステップＳ１５２で求めた応答時間を、オートスケール委譲要求に示される通信時間で除算する。除算結果が「０．８」以上であれば、応答時間が通信時間の８０％以上である。応答時間が通信時間の８０％以上の場合、処理がステップＳ１５４に進められる。応答時間が通信時間の８０％未満であれば、応答時間の長期化の原因が、仮想サーバの過負荷ではなく、通信の過負荷であると考えられるため、スケールアウトを行わずに処理が終了する。

［ステップＳ１５４］オートスケール要否判定部２３０は、応答時間が通信時間の８０％以上の場合、過負荷箇所判定処理を行う。過負荷箇所判定処理の詳細は、図２３に示した通りである。

［ステップＳ１５５］オートスケール要否判定部２３０は、ステップＳ１５４においてオートスケールを委譲した場合、処理を終了する。オートスケール要否判定部２３０は、ステップＳ１５４においてオートスケールを委譲していない場合、処理をステップＳ１５６に進める。

［ステップＳ１５６］オートスケール要否判定部２３０は、委譲元の負荷分散装置１００に対応する追加仮想サーバ数を更新する。例えばオートスケール要否判定部２３０は、管理情報記憶部２４０内の委譲元管理テーブル２４６における、負荷分散装置１００の名称に対応する追加仮想サーバ数の値を、１だけカウントアップする。

［ステップＳ１５７］オートスケール要否判定部２３０は、負荷分散装置２００がリクエストを振り分ける仮想サーバ群のスケールアウトを行うことを決定する。そしてオートスケール要否判定部２３０は、オートスケール要求部２５０に、スケールアウトのオートスケール要求の送信を依頼する。するとオートスケール要求部２５０が、仮想化装置４５に、スケールアウトのオートスケール要求を送信する。オートスケール要求を受信した仮想化装置４５は、物理サーバ４２に対して、新たな仮想サーバの起動と、その仮想サーバによるサービスの運用開始を指示する。この際、オートスケール要否判定部２３０は、委譲先管理テーブル２４５に、自分自身を示す情報（例えば負荷分散装置２００の識別子）を登録する。

このようにして、端末装置３１，３２，・・・からのリクエストに応じた処理を実行した際に、そのリクエストに対する応答時間が仮想サーバの過負荷により長期化すると、自動的にスケールアウトが行われる。なお第２の実施の形態に係るシステムでは、システムの負荷が減少した場合には、自動でスケールダウンをすることができる。以下、スケールダウンの制御方法について説明する。

図２５は、スケールダウンの制御手順の一例を示すフローチャートである。図２５に示す処理は、各負荷分散装置１００，２００，３００，４００それぞれが同様に実行するものであるが、以下の説明では、負荷分散装置１００が実行する場合を例に採って説明する。

［ステップＳ２０１］オートスケール要否判定部１３０は、振り分けたリクエストの応答時間を、所定時間（例えば３０分）分だけ取得する。
［ステップＳ２０２］オートスケール要否判定部１３０は、取得した応答時間が、すべて十分に小さい（例えばスケールアウトの際の閾値の１／２以下）かどうかを判断する。すべての応答時間が十分に小さい場合、処理がステップＳ２０３に進められる。少なくとも１つの応答時間が、十分に小さいとは言えない場合、処理が終了する。

［ステップＳ２０３］オートスケール要否判定部１３０は、オートスケール委譲要求に基づくスケールアウトによる追加した仮想サーバ数が「０」かどうかを判断する。例えば、オートスケール要否判定部１３０は、委譲元管理テーブル１４６における追加仮想サーバ数の欄のすべての値が０であれば、追加した仮想サーバ数は「０」であると判断する。追加した仮想サーバ数は「０」であれば、処理がステップＳ２０４に進められる。追加した仮想サーバ数は「０」でなければ、スケールダウンを行わずに処理が終了する。

なお負荷分散装置１００は、多階層システムの最上位の仮想サーバ４１ａ，４１ｂへのリクエストの振り分けを行っているため、オートスケール委譲要求に基づくスケールアウトを行うことはない。そのため、ステップＳ２０３では常に「ＹＥＳ」と判定される。そのため、ステップＳ２０３の処理は、図２５に示したスケールダウン制御を、他の負荷分散装置２００，３００，４００が実行した場合に有効となる処理である。

［ステップＳ２０４］オートスケール要否判定部１３０は、委譲先管理テーブル１４５から、委譲順が最後の委譲先の負荷分散装置名を取得する。
［ステップＳ２０５］オートスケール要否判定部１３０は、ステップＳ２０４で取得した負荷分散装置名に基づいて、最後に過負荷と判定したときに、自分自身でスケールアウトのオートスケール要求を送信したか否かを判断する。例えばオートスケール要否判定部１３０は、ステップＳ２０４で取得したのが負荷分散装置１００自身の名称であれば、最後に過負荷と判定したときに、自分自身でスケールアウトのオートスケール要求を出力したと判断する。ステップＳ２０４で取得したのが他の負荷分散装置の名称であれば、オートスケール要否判定部１３０は、最後に過負荷と判定したときに、取得した名称で示される負荷分散装置にオートスケール委譲要求を送信したと判断する。

最後に過負荷と判定したときに、自分自身でスケールアウトのオートスケール要求を出力したのであれば、処理がステップＳ２０６に進められる。最後に過負荷と判定したときに、他の負荷分散装置にオートスケール委譲要求を送信したのであれば、処理がステップＳ２０７に進められる。

［ステップＳ２０６］最後に過負荷と判定したときに、自分自身でスケールアウトのオートスケール要求を出力した場合、オートスケール要否判定部１３０は、スケールダウンのオートスケール要求の送信を、オートスケール要求部１５０に依頼する。するとオートスケール要求部１５０が仮想化装置４５に、物理サーバ４１で起動する仮想サーバについての、スケールダウンのオートスケール要求を送信する。オートスケール要求を受信した仮想化装置４５は、物理サーバ４１に対して、１台の仮想サーバの停止を指示する。そして物理サーバ４１において、１台の仮想サーバが停止される。その後、処理がステップＳ２０８に進められる。

［ステップＳ２０７］最後に過負荷と判定したときに、他の負荷分散装置にオートスケール委譲要求を送信した場合、オートスケール要否判定部１３０は、最後の委譲先にスケールダウンのオートスケールを委譲する。例えばオートスケール要否判定部１３０は、オートスケール委譲要求部１６０に、スケールダウンのオートスケール委譲要求の送信を依頼する。するとオートスケール委譲要求部１６０は、最後にスケールアウトのオートスケールを委譲した負荷分散装置へ、スケールダウンのオートスケール委譲要求を送信する。このオートスケール委譲要求を受信した負荷分散装置では、オートスケール委譲要求に基づくスケールダウン制御（被委譲スケールダウン制御）が実行される。

［ステップＳ２０８］オートスケール要否判定部１３０は、委譲先管理テーブル１４５を更新する。例えばオートスケール要否判定部１３０は、ステップＳ２０６においてスケールダウンのオートスケール要求を送信した場合、仮想化装置４５からのオートスケール完了通知に応じて、委譲先管理テーブル１４５内の委譲順が最後のレコードを削除する。またオートスケール要否判定部１３０は、ステップＳ２０７においてオートスケール委譲要求を送信した場合、送信先の負荷分散装置からのオートスケール完了通知に応じて、委譲先管理テーブル１４５内の委譲順が最後のレコードを削除する。

次に、スケールダウンのオートスケール委譲要求を受信した負荷分散装置における、被委譲スケールダウン制御について説明する。
図２６は、被委譲スケールダウン制御の所定の一例を示すフローチャートである。以下、図２６に示す処理を負荷分散装置２００が実行するものとして説明する。なおステップＳ２１３〜Ｓ２１７の各処理は、図２５に示す処理のステップＳ２０４〜Ｓ２０８と同様である。そこで図２５と異なるステップＳ２１１，Ｓ２１２，Ｓ２１８について説明する。

［ステップＳ２１１］オートスケール委譲受付部２７０は、負荷分散装置１００からの、スケールダウンのオートスケール委譲要求を受け取る。オートスケール委譲受付部２７０は、受け取ったオートスケール委譲要求を、オートスケール要否判定部２３０に転送する。

［ステップＳ２１２］オートスケール要否判定部２３０は、オートスケールの委譲元からの委譲により追加した仮想サーバ数が１以上か否かを判断する。例えばオートスケール要否判定部２３０は、委譲元管理テーブル２４６を参照し、オートスケール委譲要求の送信元の負荷分散装置の名称に対応付けられた追加仮想サーバ数が１以上であるかどうかを判断する。追加仮想サーバ数が１以上であれば、処理がステップＳ２１３に進められる。追加仮想サーバ数が０であれば、スケールダウンを実施しないと判定され、処理がステップＳ２１８に進められる。

［ステップＳ２１８］オートスケール委譲受付部２７０は、オートスケール完了通知を、オートスケール委譲要求の送信元である負荷分散装置に送信する。
このようにして、オートスケールによる適切なスケールダウンが行われる。すなわち、応答期間が所定値以下となると、応答期間が長期化したときにスケールアウトを行った階層の仮想サーバのスケールダウンが実行される。その結果、システム全体としての端末装置３１，３２，・・・へのレスポンス性能を適切に保持できると同時に、負荷集中以外の性能劣化をオートスケール対象から除外することにより、無駄なサーバリソースの利用を抑止することができる。

さらに第２の実施の形態では、リクエストの応答時間を、そのリクエストの実行開始時における同時リクエスト数ごとに分類して解析している。これにより、過負荷の原因となる処理に関するリクエストの応答時間から、過負荷の原因が判定される。そのため、仮想サーバの負荷に与える影響が少ない処理のリクエストによって、過負荷の原因判定の精度が劣化することが抑止され、正しい判定結果を得ることができる。

すなわち、ＣＰＵ使用率または応答時間という一次元のデータが閾値を超えるかどうかをオートスケールの条件とすると、アプリケーション異常による性能劣化までもオートスケールの対象としてしまう。第２の実施の形態に示すように、リクエストの応答時間と同時リクエスト数を組み合わせた二次元のデータにより判断することで、応答時間の長期化の原因が、アプリケーション異常などであることを適切に検出できる。その結果、無駄なスケールアウトが抑止される。

なおリクエストの応答時間と同時リクエスト数を単に組み合わせただけでは、応答時間が短いものが集計データに含まれてしまい、負荷分散の対象とすべき応答時間が長いような負荷の高い処理の傾向を調べるための適切なグラフを作成できない。第２の実施の形態では、新たに取得した応答時間の同時リクエスト数に対してグラフ上で左に隣り合う同時リクエスト数の平均値と、新たに取得した応答時間とを比較し、平均値より小さい値を集計対象から除外している。これにより、負荷が高い処理の傾向を正しく調べることができる。

しかも仮想サーバ間で連携するシステムの場合、どの仮想サーバをスケールアウトすると性能が改善するのかを判断するのが難しい。第２の実施の形態では、リクエストの応答時間と同時リクエスト数を組み合せた情報を各仮想サーバにリクエストを振り分ける負荷分散装置が集計し、応答時間の閾値を超えたことを検出した負荷分散装置から下位に向かって、順番にオートスケールが委譲される。これにより、ボトルネックとなっている仮想サーバを自動的に追跡して適切な仮想サーバをオートスケールすることができる。

なお第２の実施の形態に係るシステムは、利用したい時に利用したいだけサーバを利用できるようなクラウド環境（外部ベンダのパブリッククラウドを利用する場合など）に適用することもできる。このようなクラウド環境では、利用した仮想サーバの稼働時間により課金されるのが一般的である。そのため第２の実施の形態を適用すれば、無駄なスケールアウトを抑止し、無駄なサーバの稼働による課金の発生が抑止できる。

なお、第２の実施の形態では、負荷分散装置がオートスケール要否判定を行っているが、リクエストの応答時間を他の装置で観測して、他の装置でオートスケール要否判定を行うこともできる。例えば仮想化装置４５が、ネットワーク上の通信をキャプチャすることでリクエストごとの応答時間を計測し、オートスケールの要否判定を行ってもよい。また物理サーバ４１〜４４それぞれが、自身が受信したリクエストの応答時間を計測し、オートスケールの要否判定を行うこともできる。

なお第２の実施の形態における集計データの算出において、応答時間の平均値に代えて、中央値などの他の代表値を用いることもできる。ただし、負荷に応じた応答時間の変動が大きい処理のリクエストに比べ、負荷に応じた応答時間の変動が少ない処理のリクエストが大量にある場合、中央値では、負荷に応じた応答時間の変動が少ない処理の応答時間となってしまう。すると、より大きな同時リクエスト数の集計データを計算する際に、計算に用いる要素から、負荷に応じた応答時間の変動が少ない処理の応答時間を適切に排除できない可能性がある。そのため、負荷に応じた応答時間の変動が大きい処理のリクエストに比べ、負荷に応じた応答時間の変動が少ない処理のリクエストが大量にある場合においては、集計データとして、中央値よりも平均値を用いることが好ましい。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ａ，１ｂ，・・・ 端末装置
２ａ，２ｂ，２ｃ，・・・ 情報処理装置
１０ 管理装置
１１ 振り分け手段
１２ 蓄積手段
１３ 記憶手段
１４ 算出手段
１５ 決定手段
１６ 制御手段

Claims (16)

1. 処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの量を管理する管理装置に、
   受信した処理要求に応じた処理が情報処理装置で実行されると、実行開始の際に前記情報処理装置が実行している処理の数を示す同時処理数と、該受信した処理要求に応じた処理の実行開始から完了までの処理時間とを関連付けて、記憶手段に蓄積し、
   同時処理数それぞれについて、該同時処理数に関連付けられた処理時間の集合のうち、該同時処理数よりも少ない同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出し、
   新たに蓄積された処理時間と、該処理時間が関連付けられた同時処理数について算出された代表値とに基づいて、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの追加の要否を決定する、
   処理を実行させる管理プログラム。
2. 代表値の算出では、代表値を算出する同時処理数よりも少ない同時処理数のうち、代表値が算出されている最も大きな同時処理数を特定し、代表値を算出する同時処理数に関連付けられた処理時間のうち、該特定した同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出する、
   ことを特徴とする請求項１記載の管理プログラム。
3. リソースの追加の要否の決定では、新たに蓄積された処理時間が関連付けられた同時処理数について代表値が算出されていない場合、該同時処理数の代表値を、他の同時処理数について算出された代表値に基づいて推定する、
   ことを特徴とする請求項１または２に記載の管理プログラム。
4. リソースの追加の要否の決定では、新たに蓄積された処理時間が関連付けられた同時処理数について代表値が算出されていない場合、代表値が算出されており、且つ該同時処理数に近い方から２つの同時処理数について算出された代表値に基づいて、同時処理数の増加に伴う代表値の増加度合いを表す式を求め、該式に基づいて新たに蓄積された処理時間が関連付けられた同時処理数の代表値を推定する、
   ことを特徴とする請求項３記載の管理プログラム。
5. リソースの追加の要否の決定では、新たに蓄積された処理時間が、所定の閾値を超え、かつ該処理時間が関連付けられた同時処理数について算出された代表値に所定値を乗算した値未満のときに、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定する、
   ことを特徴とする請求項１乃至４のいずれかに記載の管理プログラム。
6. リソースの追加の要否の決定では、直近の所定期間内に蓄積されたすべての処理時間が、前記閾値未満の所定値以下のときに、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを削減するものと決定する、
   ことを特徴とする請求項５記載の管理プログラム。
7. 多階層に構成された複数の情報処理装置が連携して処理要求に応じた処理を実行している場合、
   同時処理数と処理時間との蓄積では、複数の情報処理装置のうちの特定の情報処理装置が受信した処理要求に応じて実行した処理についての、同時処理数、処理時間、および下位の階層の情報処理装置との通信時間を関連付けて蓄積し、
   リソースの追加の要否の決定では、新たに蓄積された処理時間が、所定の閾値を超え、かつ該処理時間が関連付けられた同時処理数について算出された代表値に所定値を乗算した値未満であるとともに、新たに蓄積された処理時間に対する、その処理時間に関連付けられた通信時間の割合が所定値未満の場合に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定する、
   ことを特徴とする請求項１乃至６のいずれかに記載の管理プログラム。
8. リソースの追加の要否の決定では、新たに蓄積された処理時間が、所定の閾値を超え、かつ該処理時間が関連付けられた同時処理数について算出された代表値に所定値を乗算した値未満であるとともに、新たに蓄積された処理時間に対する、その処理時間に関連付けられた通信時間の割合が所定値以上の場合、前記特定の情報処理装置よりも下位の階層の情報処理装置のリソースを追加するものと決定し、下位の階層の情報処理装置のリソースの、処理要求に応じた処理の実行への割り当て量を管理する他の管理装置に、リソース追加要求を送信する、
   ことを特徴とする請求項７記載の管理プログラム。
9. 前記管理装置に、さらに、
   前記特定の情報処理装置よりも上位の階層の情報処理装置のリソースの割当量を管理する他の管理装置からリソース追加要求を受信した場合、上位の階層の情報処理装置において、処理時間が閾値を超えた処理の実行過程で行われた通信の開始から終了までの通信時間に対する、該通信を介して依頼された処理要求に応じて前記特定の情報処理装置が実行した処理の処理時間の割合が所定値以上の場合に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定する、
   処理を実行させることを特徴とする請求項８記載の管理プログラム。
10. リソースの追加の要否の決定では、新たに蓄積された処理時間が、前記閾値未満の所定値以下であり、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものとの決定後に、他の管理装置へのリソース追加要求を送信していない場合に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを削減するものと決定する、
    ことを特徴とする請求項８または９記載の管理プログラム。
11. リソースの追加の要否の決定では、新たに蓄積された処理時間が、前記閾値未満の所定値以下であり、他の管理装置へのリソース追加要求の送信後に、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースを追加するものと決定を行っていない場合、該他の管理装置へ、リソース削減要求を送信する、
    ことを特徴とする請求項１０記載の管理プログラム。
12. 前記管理装置に、さらに、
    前記特定の情報処理装置よりも上位の階層の情報処理装置のリソースの、処理要求に応じた処理の実行への割当量を管理する他の管理装置から、リソース削減要求を受信した場合、該他の管理装置からのリソース追加要求に応じて追加したリソースの範囲内で、処理要求に応じた処理の実行へ割り当てる前記特定の情報処理装置のリソースを削減するものと決定する、
    処理を実行させることを特徴とする請求項１１記載の管理プログラム。
13. 前記代表値は、部分集合に含まれる処理時間の平均値であることを特徴とする請求項１１乃至１２のいずれかに記載の管理プログラム。
14. 前記代表値は、部分集合に含まれる処理時間の中央値であることを特徴とする請求項１１乃至１２のいずれかに記載の管理プログラム。
15. 処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの量を管理する管理装置が、
    受信した処理要求に応じた処理が情報処理装置で実行されると、実行開始の際に前記情報処理装置が実行している処理の数を示す同時処理数と、該受信した処理要求に応じた処理の実行開始から完了までの処理時間とを関連付けて、記憶手段に蓄積し、
    同時処理数それぞれについて、該同時処理数に関連付けられた処理時間の集合のうち、該同時処理数よりも少ない同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出し、
    新たに蓄積された処理時間と、該処理時間が関連付けられた同時処理数について算出された代表値とに基づいて、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの追加の要否を決定する、
    ことを特徴とする管理方法。
16. 処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの量を管理する管理装置において、
    受信した処理要求に応じた処理が情報処理装置で実行されると、実行開始の際に前記情報処理装置が実行している処理の数を示す同時処理数と、該受信した処理要求に応じた処理の実行開始から完了までの処理時間とを関連付けて、記憶手段に蓄積する蓄積手段と、
    同時処理数それぞれについて、該同時処理数に関連付けられた処理時間の集合のうち、該同時処理数よりも少ない同時処理数に関連付けられた処理時間の部分集合の代表値よりも長い処理時間を集めた部分集合の代表値を算出する算出手段と、
    新たに蓄積された処理時間と、該処理時間が関連付けられた同時処理数について算出された代表値とに基づいて、処理要求に応じた処理の実行へ割り当てる情報処理装置のリソースの追加の要否を決定する決定手段と、
    を有する管理装置。

Images