JP2017041191A - リソース管理装置、リソース管理プログラム、及びリソース管理方法 - Google Patents

Abstract

【課題】情報処理システム間にてリソースを提供する場合に、提供する側の情報処理システムのリソースの枯渇の発生を抑制する技術を提供する。【解決手段】リソース管理装置は、複数の仮想計算機により構築される複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、第１の情報処理システムに割り当てられた複数のリソースの使用量を取得し、複数のリソースの使用量に基づいて、第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定し、応答時間の閾値超過がいずれかのリソースの枯渇によるものであると判定された場合、複数のリソースの使用量に基づいて、複数のリソースのうち、枯渇したリソース以外のリソースである余剰リソースを特定し、余剰リソースを複数の情報処理システムのうち第２の情報処理システムへ提供することにより、上記課題の解決を図る。【選択図】図３

Description

本発明は、リソース管理装置、リソース管理プログラム、及びリソース管理方法に関する。

仮想化技術の浸透から、基幹系等の業務システムも仮想環境に載せることが多くなっている。そのため、例えば、一時的な処理要求の増加等が発生しても、業務への影響を発生させないことが重要となる。そのため、有限なコンピュータ資源（リソース）の最適化を図ることが求められる（例えば、特許文献１〜４）。

特開２０１３−２３９０９５号公報 特表２０１３−５４３１７１号公報 国際公開第２００７／１３６０２１号 国際公開第２０１２／０２５９７７号

複数の業務システムにおける処理を複数の仮想マシン（ＶＭ）に実行させる際に、各業務システムの運用スケジュールや、処理の遅延の影響度合いに合わせて、リソースの予約により確実にリソースを確保する場合がある。ここで、予約しているリソースのうちで、余剰リソースの一部または全部は、他のシステムでリソースを予約するときに不足しているリソースとして補充することができる。以下では、このように予約されたリソースを「予約リソース」と表記する場合がある。実際の処理の段階で予約分についてもリソースを融通して確保しているため、安定してシステムを動作させることができる。

リソースを予約してリソースを確保する状況で、各業務システムがどれだけの余剰リソースを持つかを算出するには時間がかかるため、過去の実績等から、現在の余剰リソースを、相関等も考慮して推定することが考えられる。

しかしながら、複数の業務システムそれぞれで算出される余剰リソースの正確度は、過去のボトルネック状態でのリソースについての履歴情報がある業務システムと、過去のボトルネック状態でのリソースについての履歴情報が無い業務システムとでは異なる。ここで、ボトルネック状態とは、業務システム等の情報処理システムが有するリソースのうちいずれかのリソースの枯渇が発生している状態をいう。より具体的には、ボトルネック状態とは、業務システムにおいて使用される複数のリソースのうちのいずれかのリソースの使用量が割り当てられたリソースの上限値に達している場合に、その業務システム全体の処理能力が著しく低下する状態をいう。

このように、過去のボトルネック状態でのリソースについての履歴情報の有無に応じて余剰リソースの正確度が異なる。そのため、推定した余剰リソースが多い業務システムからリソースを融通することが、複数の業務システム全体として、最適なリソース配分とは限らない場合がある。たとえば、融通した業務システムが、却ってボトルネックに達する状況が生じることがありえる。

本発明の一側面として、情報処理システム間にてリソースを提供する場合に、提供する側の情報処理システムのリソースの枯渇の発生を抑制する技術を提供する。

本発明の一側面に係るリソース管理装置は、取得部と、判定部と、特定部と、提供部とを含む。取得部は、複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、第１の情報処理システムに割り当てられた複数のリソースの使用量を取得する。判定部は、複数のリソースの使用量に基づいて、第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定する。特定部は、前記応答時間の閾値超過がいずれかのリソースの枯渇によるものであると判定された場合、複数のリソースの使用量に基づいて、複数のリソースのうち、枯渇したリソース以外のリソースである余剰リソースを特定する。提供部は、余剰リソースを複数の情報処理システムのうち第２の情報処理システムへ融通する。

本発明の一側面によれば、情報処理システム間にてリソースを提供する場合に、提供する側の情報処理システムのリソースの枯渇の発生を抑制することができる。

予測値に基づいて他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第１の例）を示す。 予測値に基づいて他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第２の例）を示す。 本実施形態におけるリソース管理装置の一例を示す。 本実施形態における他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第１の例）を示す。 本実施形態における他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第２の例）を示す。 本実施形態におけるシステム構成図である。 本実施形態における業務システム構成テーブルの一例を示す。 本実施形態における仮想ホストテーブルの一例を示す。 本実施形態における予約スケジュールテーブルの一例を示す。 本実施形態における融通可能リソース管理テーブルの一例を示す。 本実施形態における融通制御装置１３の全体の処理フローを示す。 本実施形態における、遅延防止期間検出処理を説明するための図である。 本実施形態における、リクエスト数と使用リソース量の相関関係を示す図である。 本実施形態における期間検出部により実行される予約スケジュール追加処理のフローの一例を示す。 本実施形態における遅延防止期間算出処理（Ｓ１１）の処理フローの一例を示す。 本実施形態における予約スケジューリング処理（Ｓ１２）の処理フローの一例を示す。 本実施形態における予約量設定部により実行される予約量決定処理のフローの一例を示す。 本実施形態における配置先仮想ホスト及び予約量決定処理（Ｓ２１）のフローの一例を示す。 本実施形態における予約融通処理（Ｓ２１−３）のフローの一例を示す。 本実施形態における予約スケジューラ部により実行される予約終了処理フローの一例を示す。 本実施形態におけるリソース抽出部により実行される融通可能リソース抽出処理フローの一例を示す。 本実施形態における余剰リソース更新処理（Ｓ４１）の処理フローの一例を示す。 本実施形態におけるリソース抽出部により実行される融通可能リソースクリア処理フローの一例を示す。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

以下にて、業務システムのボトルネックの発生における融通の問題について詳述する。
図１は、予測値に基づいて他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第１の例）を示す。図１（Ａ）に示すように、例えば、業務システムＡ，Ｂ，Ｃがある。業務システムＡ，Ｂは、仮想ホスト上で稼動しているとする。例えば、リソースの予約の設定を行う予約スケジューラに業務システムＣの予約を追加しようとするが、仮想ホストの物理リソースに空きがないため、他の業務システムの予約リソースを融通する状況とする。

過去における、リソース使用実績とリクエスト数／sとの相関分析から、業務システムで処理可能な最大リクエスト数／ｓ時のリソース使用量（予測値）が求められ、ボトルネック時の業務システム内ＶＭの空き容量の合計を融通可能なリソース量とする。

例えば、業務システムＡは、ＶＭとして、Ｗｅｂサーバ、アプリケーション（ＡＰ）サーバ、データベース（ＤＢ）サーバを含む。業務システムＡにおいて、割り当てられたリソース量に対してリソースの消費量または使用率が最も高くなる、すなわちボトルネックになるのは、ＡＰサーバであるとする。

また、業務システムＡのＷｅｂサーバ、ＤＢサーバにおいて、相関分析で求めたボトルネック時のリソースの空き量（予測値）はそれぞれ１０、１５であるとする。ボトルネック時のリソースの空き量とは、ある業務システムのボトルネック時において、リソースの消費量または使用率が１００％の状態にあるサーバ以外のサーバのリソースの空き容量または余剰の不使用率を示す。

例えば、ボトルネック時のＷｅｂサーバのリソースの空き量（予測値）が１０であるとは、次のことを示す。すなわち、ＡＰサーバのリソースの消費量または使用率が１００％の状態の場合に、Ｗｅｂサーバのリソースの消費量または使用率が最大９０％であり、１０％分のリソースの余裕があると予測される。

業務システムＢは、ＶＭとして、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバを含む。業務システムＢにおいても同様に、割り当てられたリソース量に対するリソースの消費量または使用率が最も高くなる、すなわちボトルネックになるのは、ＡＰサーバであるとする。また、Ｗｅｂサーバ、ＤＢサーバにおいて、相関分析で求めたボトルネック時のリソースの空き容量（予測値）はそれぞれ１２、１８であるとする。

このような業務システムＡ，Ｂにおいてリソース量の空きの合計はそれぞれ２５、３０となる。ここで、リソースを融通するためにいずれかの業務システムを選択するとする。例えば、リソース量２５のリソースを融通可能な業務システムの選択において、空きが業務システムＡよりも多い業務システムＢを選択するとする。この場合、図１（Ｂ）に示すように、業務システムＢのＷｅｂサーバ、ＤＢサーバの空き容量（予測値）１２、１８から合計２５となるようにそれぞれ１０、１５の予約量が融通される。すなわち、予約量は、空き容量の１２，１８と同じ割合で１０，１５ずつ融通される。すると融通後の業務システムＢの使用可能なリソース量は、Ｗｅｂサーバについて９０、ＤＢサーバについて８５となる。

その後、業務システムＢで突発的なリクエスト急増が発生した場合、予測値よりもリソース量が必要となったとする。この場合、融通した分のリソースが不足してレスポンス遅延が発生する。

例えば、図１（Ｂ）に示すように、業務システムＢのＤＢサーバについて、使用可能なリソース量８５に対して、突発的なリクエスト急増により実際に必要なリソース量が９５であるとする。業務システムＢのＤＢサーバは、予約量１５を融通したことにより、予約量として設定されたリソースを使用できず、リソース不足でボトルネックとなり、レスポンスの遅延が発生する。

図２は、予測値に基づいて他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第２の例）を示す。図２では、図１と同じ構成の業務システムＡにおいて、ボトルネックを考慮しないで、リソースを他の業務システムへ融通した場合の例を示す。

図２（Ａ）に示すように、各ＶＭのリソース毎で、過去のリソースの使用実績と、モニタリングしている現在のリソース使用量との相関分析により今後のリソース使用量の増加分を予測し、空き容量を融通可能なリソース量とする。Ｗｅｂサーバ、ＤＢサーバにおいて、相関分析で求めたボトルネック時のリソースの空き量（予測値）はそれぞれ１０、１５であるとする。また、ボトルネックとなるＡＰサーバのリソースについても空き容量として予測した５が予約量として設定され、他の業務システムへ融通される。

その後、業務システムＡで突発的なリクエスト急増時に、ボトルネックリソースにて融通前よりもリソース使用量が頭打ちとなると想定する。その結果、融通前より早くレスポンス遅延が発生する。

例えば、図２（Ｂ）に示すように、ＡＰサーバでは、融通前は、リソース使用量が１００％になるとリソース使用量が頭打ちとなるが、融通後はリソース使用量が９５％になるとリソース使用量が頭打ちとなる。その結果、図２（Ｃ）に示すように、融通前より早くレスポンス遅延が発生する。

したがって、相関分析などで求めたボトルネック時のリソース使用量の予測値に基づいて、余剰リソース容量を融通する場合には、突発的なリクエスト急増時に対処できない場合がある。

複数のシステムそれぞれにおいて算出される余剰リソースの信頼度については、相関分析などで求めたボトルネック時のリソース使用量の予測値よりも過去にボトルネックが発生したときのリソース使用量の実測値の方が高くなる。このため、上述のように、予測値により求めた余剰リソースが多いシステムからリソースを融通することが、複数のシステム全体として、最適なリソース配分とならない場合がある。

また、各ＶＭの余剰リソースからリソースを融通した場合に融通元の業務システムに与える影響度合いは、ボトルネックが発生したＶＭからリソースを融通した場合、非常に大きくなる。そのため、全ＶＭについて画一的に余剰リソースを評価して万遍なく少しずつリソースを融通することで各ＶＭに与えるインパクトは小さくなるが、システム全体として最適なリソース配分とならない場合がある。

更に、実測値として余剰リソースを求めるには、実際にボトルネック時のリソース使用量の分析が必要となる。しかしながら、全業務システムの全ＶＭの膨大なリソース使用量の実績データを長期間保持しておく必要があり、かつ、融通時に短時間で、膨大なデータから融通可能なＶＭを特定し、そのリソース量を算出することができないため、即座に融通できない。

そこで、本実施形態では、異なる業務システムにリソースを融通する際に、複数の業務システムにおいて、過去にボトルネックが生じた業務システムが存在する場合は、当該業務システムのボトルネック時の余剰リソースを、融通するリソースとして優先する。この場合、融通後、業務に影響が出ないようボトルネックとなるリソース以外のリソースを選択して融通する。

図３は、本実施形態におけるリソース管理装置の一例を示す。リソース管理装置１は、取得部２と、判定部３と、特定部４と、提供部５とを含む。

取得部２は、複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、第１の情報処理システムに割り当てられた複数のリソースの使用量を取得する。取得部２の一例として、後述するリソース抽出部１７が挙げられる。

判定部３は、複数のリソースの使用量に基づいて、第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定する。判定部３の一例として、後述するリソース抽出部１７が挙げられる。

特定部４は、前記応答時間の閾値超過がいずれかのリソースの枯渇によるものであると判定された場合、複数のリソースの使用量に基づいて、複数のリソースのうち、枯渇したリソース以外のリソースである余剰リソースを特定する。特定部４の一例として、予約量設定部１６が挙げられる。

提供部５は、余剰リソースを複数の情報処理システムのうち第２の情報処理システムへ提供する。提供部５の一例として、予約量設定部１６が挙げられる。

このように構成することにより、情報処理システム間にてリソースを提供する場合に、提供する側の情報処理システムのリソースの枯渇の発生を抑制することができる。

特定部４は、第１の情報処理システムにいずれかのリソースの枯渇が発生したことがない場合、処理負荷と処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、複数のリソースから余剰リソースを特定する。

このように構成することにより、過去にボトルネックが発生していない場合には、処理負荷と処理負荷に応じて使用されたリソース量との相関関係に基づいて、ボトルネックルソースを特定することにより、余剰リソースを得ることができる。

特定部４は、いずれかのリソースの枯渇が発生した場合、いずれかのリソースの枯渇の発生時に仮想計算機が使用していたリソースの余剰を余剰リソースとして特定する。

このように構成することにより、業務システムにおいて、複数の仮想計算のうちの、いずれかの仮想計算機が用いるリソースがボトルネックとなっている場合、他の仮想計算機が用いるリソースの余剰分を予約量とすることができる。

取得部２は、第１の情報処理システムにおいて処理の応答時間が閾値を超えた際の第１の情報処理システムが動作する複数の仮想計算機のそれぞれに割り当てられたリソースの使用量を取得する。特定部は、第１の情報処理システムが動作する複数の仮想計算機のうち、使用量が割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する。提供部は、算出されたリソースの余剰量を複数の情報処理システムのうち第２の情報処理システムへ提供する。

このように構成することにより、複数の仮想計算機上で動作する情報処理システム間にてリソースを提供する場合に、提供する側の情報処理システムのリソースの枯渇の発生を抑制することができる。

特定部は、第１の情報処理システムが動作する複数の仮想計算機のうち、使用量が割り当てられたリソースの上限値に達している仮想計算機がこれまでになかった場合、次の処理を行う。特定部は、所定の関係情報に基づいて、第１の情報処理システムが動作する複数の仮想計算機のうち、使用量が割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する。所定の関係情報とは、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報である。

このように構成することにより、業務システムにおいて、複数の仮想計算のうちの、いずれかの仮想計算機が用いるリソースがボトルネックとなっている場合、他の仮想計算機が用いるリソースの余剰分を予約量とすることができる。

本実施形態により、以下のことが実現できる。
図４は、本実施形態における他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第１の例）を示す。図４（Ａ）に示すように、例えば、業務システムＡ（６）及び業務システムＢ（７）が予約スケジューラに登録され、仮想ホストに業務システムＡ（６），Ｂ（７）を実行するためのリソースが割り当てられていると想定する。ここで、さらに、予約スケジューラに業務システムＣの予約を追加しようとするが、仮想ホストの物理リソースに空きがないため、他の業務システムの予約リソースを融通する状況とする。

ここで、業務システムＡ（６）については、過去にボトルネックが発生した実績があり、その実績に基づいて、余剰リソースが予約値として設定されているとする。一方で、業務システムＢ（７）については、ボトルネックが発生した実績がないため、予測値に基づいて余剰リソースが予約値として設定されているとする。

融通する業務システムとして、過去にボトルネックが発生した業務システムが優先して選択される。融通するリソース量は、過去のボトルネック発生時での、ボトルネックが発生したリソース以外のリソースの空き容量とする。ここで説明する例では、図４（Ａ）に示すように、業務システムＢよりも空きリソース量が少ないが、融通リソース量２５を満たし、予測値よりも信頼度が高い、過去にボトルネックが発生した業務システムＡが選択されるとする。

その後、業務システムＡ（６）で突発的なリクエスト急増でボトルネックが発生しても、ボトルネック時に使えるリソース量は予約で確保されているため、融通による影響がない。例えば、図４（Ｂ）に示すように、業務システムＡ（６）で突発的なリクエスト急増でボトルネックが発生した場合、ボトルネックが発生した実績があるＡＰサーバで今回もボトルネックが発生する可能性が高い。ＡＰサーバにてボトルネックが発生した場合、Ｗｅｂサーバ、ＤＢサーバにおけるリソースの使用量はそれぞれ、８７、８８で頭打ちにある（すなわち、Ｗｅｂサーバ、ＤＢサーバの最大使用量はそれぞれ８７、８８である）。そのため、Ｗｅｂサーバ、ＤＢサーバにおいてそれぞれ、予約量１３，１２のリソース量を融通していたとしても、リソースが最大使用量を超えて消費される可能性が少なく、融通した後の予約量を除いた範囲内でリソースの使用量が収まる。もし、レスポンス遅延が発生しても、そのレスポンス遅延は元々のボトルネックによるものであり、融通とは関係がない。

図５は、本実施形態における他の業務システムにリソースの空き容量を融通する場合の融通元の業務システムの選択例（第２の例）を示す。図５では、ボトルネックとなるリソースからの融通を防止することで、業務への影響を抑える例について説明する。

まず、融通するリソースは、過去にボトルネックが発生した業務システムで使用されるリソースであり、かつ、ボトルネックとなったリソース以外の空き容量（実績値）を有するリソースとする。図５（Ａ）の場合、業務システムＡ（６）のＡＰサーバのＣＰＵリソースがボトルネックとなるリソースであるため、ＡＰサーバのＣＰＵリソースからは融通しない。

その後、業務システムＡ（６）で突発的なリクエスト急増時でボトルネックが発生しても、図５（Ｂ）に示すように、ボトルネックリソースであるＡＰサーバは融通前と同じく１００％使用できる。そのため、図５（Ｃ）に示すように、ＡＰサーバは、融通の前後で、単位時間当たりの業務システムＡで処理可能な最大リクエスト数（スループット）に変化はなく、融通による影響がない。

以下では、本実施形態のより具体的な実施例について説明する。
図６は、本実施形態におけるシステム構成図である。システム１０は、管理装置群１１、制御対象装置群３１とを含む。制御対象装置群３１は、制御対象となるサーバ物理装置（仮想ホスト）上で稼働する仮想化装置群である。管理装置群１１は、制御対象装置群３１を制御する管理装置群である。

制御対象装置群３１は、１以上のサーバ物理装置１（３２−１）〜Ｎ（３２−Ｎ）を含む。サーバ物理装置１（３２−１）〜Ｎ（３２−Ｎ）はそれぞれ、仮想ホストサーバ（または仮想ホスト）として機能し、仮想化装置３４−１〜３４−Ｎを含む。

仮想化装置３４−１〜３４−Ｎは、サーバ物理装置１（３２−１）〜Ｎ（３２−Ｎ）において仮想化環境を実現して、複数のＶＭ３３−１〜３３−Ｎを稼動させる制御プログラムで（ハイパーバイザ、仮想マシンモニタ等）ある。

以下では、サーバ物理装置１（３２−１）〜Ｎ（３２−Ｎ）を総称して、サーバ物理装置３２または仮想ホスト３２と称する。また、仮想化装置３４−１〜３４−Ｎを総称して、仮想化装置３４と称する。また、ＶＭ３３−１〜３３−Ｎを総称して、ＶＭ３３と称する。

制御対象装置群３１では、１以上のサーバ物理装置３２上で複数のＶＭが稼動しており、業務システムが仮想化環境で運用される。

管理装置群１１は、バッチジョブ制御装置１２、融通制御装置１３、蓄積装置１９、監視装置２０、統合制御装置２１を含むサーバ群である。

バッチジョブ制御装置１２は、業務システムで用いられるバッチ処理やジョブを制御する。蓄積装置１９は、各業務システムから、その業務システムに対するリクエスト量（実績値）または各ＶＭのリソース（ＣＰＵ、メモリ等）の使用量（実績値）等を収集し、蓄積する。

監視装置２０は、各業務システムのレスポンス時間を監視する。監視の結果、レスポンス時間が閾値を超えた場合には、監視装置２０は、その旨を融通制御装置１３に通知する。

統合制御装置２１は、制御対象装置群に含まれる仮想リソースの統合及び制御を、業務システム単位で行うことを実現する。統合制御装置２１は、本実施形態の例では、後述するように、ある業務システムで用いられる各仮想リソースに対して設定された予約量を、他の業務システムに融通する。

融通制御装置１３は、各業務システムの遅延を防止するために設定された期間（遅延防止期間）で各ＶＭのリソースを予約して運用する。融通制御装置１３は、複数のＶＭの遅延防止期間の重なりにより、物理リソース以上の予約が必要となった場合に、予約融通処理を行う。

予約融通処理では、融通制御装置１３は、事前に登録された各業務システムのボトルネックの有無や余剰リソースの情報に基づいて、過去にボトルネックが発生した信頼度の高い融通可能なリソース量を持つ業務システムを優先して選択する。

それから、融通制御装置１３は、融通による業務への影響を考慮して求めた余剰リソース量を融通可能リソース量として予約する。

融通制御装置１３は、期間検出部１４、予約スケジューラ部１５、予約量設定部１６、リソース抽出部１７、記憶部１８を含む。

期間検出部１４は、統合制御装置２１から、制御対象装置群３１上で構築されている全業務システムについての構成を示す情報である業務システム構成情報を取得する。期間検出部１４は、業務システムで関連付けられているバッチ業務情報に基づいて、バッチジョブ制御装置１２から、予約スケジューラのジョブ開始時刻を取得する。それから、期間検出部１４は、蓄積装置１９から業務システムのリクエスト量と各ＶＭのリソース使用量を取得して、遅延防止期間を決定する。

予約スケジューラ部１５は、期間検出部１４によって決定された遅延防止期間をスケジュールに登録する。予約スケジューラ部１５は、予約量設定部１６に予約開始時刻を通知する。

予約量設定部１６は、リソースの予約開始時刻となった旨の通知を受信すると、統合制御装置２１から、仮想ホスト３２のリソースの予約状況を取得する。予約量設定部１６は、遅延防止期間において、いずれかの仮想ホスト３２上で、リソースの予約ができる場合には、その仮想ホストにて予約量を設定する。遅延防止期間において、いずれかの仮想ホスト３２上で余剰リソースの予約ができない場合には、余剰リソースを有する仮想ホストからリソースを融通するように、統合制御装置２１に依頼する。また、予約量設定部１６は、ＶＭの移動指示を統合制御装置２１に発行する。

リソース抽出部１７は、監視装置２０より業務システムのレスポンスの悪化が通知された場合、蓄積装置からのリソース使用量に基づいて、その通知の対象になった業務システムでのボトルネックの発生に有無を判断する。リソース抽出部１７は、ボトルネックの発生の有無に応じて、リソース使用の実績値または単位時間当たりのリクエスト数とリソース使用量との相関関係を用いて、その業務システムの融通可能なリソース量を求める。リソース抽出部１７は、その求めた融通可能なリソース量を融通可能リソース管理テーブル４４に登録する。リソース抽出部１７は、業務システムのＶＭ構成が変更となった旨のＶＭ構成変更通知を受信した場合、融通可能リソース管理テーブル４４からその業務システムに対応するエントリを削除する。

記憶部１８は、後述するように、業務システム構成テーブル４１、仮想ホストテーブル４２、予約スケジュールテーブル４３、融通可能リソース管理テーブル４４を含む。

図７は、本実施形態における業務システム構成テーブルの一例を示す。業務システム構成テーブル４１は、各業務システムを構成する各ＶＭで用いる仮想リソースを管理するテーブルである。

業務システム構成テーブル４１は、「管理者名」４１−１、「業務システム名」４１−２、「仮想ホスト名」４１−３、「ＶＭ名」４１−４、「ＣＰＵ」４１−５、「メモリ」４１−６、「ＣＰＵ予約量」４１−７、「メモリ予約量」４１−８のデータ項目を含む。

「管理者名」４１−１には、その業務システムの管理者名が格納される。「業務システム名」４１−２には、その業務システムを識別する名称が格納される。「仮想ホスト名」４１−３には、その業務システムで使用される仮想ホストを識別する名称が格納される。

「ＶＭ名」４１−４には、その業務システムで使用されるＶＭを識別する名称が格納される。「ＣＰＵ」４１−５には、そのＶＭに割り当てられているＣＰＵの性能が格納される。「メモリ」４１−６には、そのＶＭに割り当てられているメモリの容量が格納される。

「ＣＰＵ予約量」４１−７には、「ＣＰＵ」４１−５に格納されたＣＰＵの性能のうち、現在予約されているＣＰＵ予約量が格納される。「メモリ予約量」４１−８には、「メモリ」４１−６に格納されたメモリの容量のうち、現在予約されているメモリ予約量が格納される。

図８は、本実施形態における仮想ホストテーブルの一例を示す。仮想ホストテーブル４２は、後述する予約期間における、仮想ホスト３２を構築するサーバ物理装置に含まれる物理リソース及びリソースの予約量を管理するテーブルである。

仮想ホストテーブル４２は、「仮想ホスト名」４２−１、「物理ＣＰＵ」４２−２、「ＣＰＵ予約量合計」４２−３、「物理メモリ」４２−４、「メモリ予約量合計」４２−５のデータ項目を含む。

「仮想ホスト名」４２−１には、仮想ホスト３２を識別する名称が格納される。「物理ＣＰＵ」４２−２には、仮想ホスト３２を構築するサーバ物理装置に含まれる物理ＣＰＵの内容（処理性能（例えば、２ＧＨｚ×１６コア）及び個数）が格納される。「ＣＰＵ予約量合計」４２−３には、業務システム構成テーブル４１において、「仮想ホスト名」４１−３にてグループ化した場合の「ＣＰＵ予約量」４１−７の合計値が格納される。なお、「ＣＰＵ予約量合計」４２−３に格納されるのは、現時点での仮想ホスト内のＣＰＵ予約量の合計である。

「物理メモリ」４２−４には、仮想ホスト３２を構築するサーバ物理装置に含まれる物理メモリの容量が格納される。「メモリ予約量合計」４２−５には、業務システム構成テーブル４１において、「仮想ホスト名」４１−３にてグループ化した場合の「メモリ予約量」４１−８の合計値が格納される。なお、「ＣＰＵ予約量合計」４２−３に格納されるのは、現時点での仮想ホスト内のメモリ予約量の合計である。

図９は、本実施形態における予約スケジュールテーブルの一例を示す。予約スケジュールテーブル４３は、リソースを予約するタイミングを管理するテーブルである。

予約スケジュールテーブル４３は、「業務システム名」４３−１、「ＶＭ名」４３−２、「予約開始」４３−３、「予約終了」４３−４を含む。「業務システム名」４３−１には、その業務システムを識別する名称が格納される。「ＶＭ名」４１−２には、その業務システムで使用されるＶＭを識別する名称が格納される。「予約開始」４３−３及び「予約終了」４３−４にはそれぞれ、業務システム間で融通可能なように予約したリソースを融通する開始時刻及び終了時刻が格納される。

図１０は、本実施形態における融通可能リソース管理テーブルの一例を示す。融通可能リソース管理テーブル４４は、業務システム単位で、融通可能なリソースを管理するテーブルである。融通可能リソース管理テーブル４４は、業務システムのレスポンス悪化の発生時に、業務システム単位で、エントリの内容の記録または更新がされる。これにより、リソースの融通時にて、融通可能リソース管理テーブル４４は、すぐに利用することができる。

融通可能リソース管理テーブル４４は、「業務システム名」４４−１、「レスポンス悪化日時」４４−２、「ボトルネック有無（回数）」４４−３、「ＶＭ名」４４−４、「割り当て」４４−５、「融通可能なリソース量」４４−６のデータ項目を含む。なお、融通可能リソース管理テーブル４４では、１業務システムにつき１エントリとなる。

「業務システム名」４４−１には、その業務システムを識別する名称が格納される。「レスポンス悪化日時」４４−２には、最新のレスポンス悪化が発生した日時が格納される。

「ボトルネック有無（回数）」４４−３には、その業務システムにおけるボトルネックの発生の有無及び発生回数が格納される。「ボトルネック有無（回数）」４４−３に「無」が登録される場合、過去に一度もボトルネックが発生していないことを示す。ボトルネックの有無やボトルネックの発生回数は、リソース融通時の信頼度を示す。図１０の例では、有（３）、有（１）、無の優先順位でリソースが融通される。

「ＶＭ名」４４−４には、その業務システムで使用されるＶＭを識別する名称が格納される。「割り当て」４４−５には、そのＶＭに割り当てられているリソースの容量（ＣＰＵの性能、メモリの容量）が格納される。

「融通可能なリソース量」４４−６には、業務システムで使用されるＶＭで用いられているリソース量のうち、融通可能なリソース量（ＣＰＵの性能、メモリの容量）が格納される。「融通可能なリソース量」４４−６において、“〇”が格納されているリソースは、ボトルネックのリソースであることを示す（“〇”が付与されたリソースの融通可能なリソース量は“０”となる）。また、「融通可能なリソース量」４４−６では、業務システム毎に、融通可能なリソース量の合計も格納される。

ここで、「ボトルネック有無（回数）」４４−３及び「融通可能なリソース量」４４−６について、さらに詳述する。「融通可能なリソース量」４４−６には、ボトルネック発生時の実績値が優先して格納され、「ボトルネック有無（回数）」４４−３には、“有”が格納される。

ボトルネックが複数回発生する場合は、実績値は安全性のため「融通可能なリソース量」４４−６には最小値が格納され、「ボトルネック有無（回数）」４４−３にはボトルネック発生回数が格納される。

ボトルネックが一度も発生しない場合は、「融通可能なリソース量」４４−６には、相関分析による予測値が格納される。このとき、「ボトルネック有無（回数）」４４−３には、“無”が格納される。なお、相関分析による予測値の算出により、あるリソースがボトルネックであると判定された場合にも、そのリソースの「融通可能なリソース量」４４−６に、“〇”が格納される。

図１１は、本実施形態における融通制御装置１３の全体の処理フローを示す。融通制御装置１３は、期間検出部１４として機能し、遅延防止期間検出処理（Ｓ１）を行う。Ｓ１の処理については、図１２を参照しながら説明する。

図１２は、本実施形態における、遅延防止期間検出処理を説明するための図である。期間検出部１４は、バッチ処理と連携した業務システムから、図１２（Ａ）に示すように業務の遅延を防止する期間（遅延防止期間）を検出する。

まず、期間検出部１４は、オンライン業務の追加またはオンライン業務を構成するＶＭの設定の更新のタイミングで、オンライン業務と関係付けられているバッチ業務の集計開始時刻を取得する。

ここで、対象とする業務は、オンライン業務と、一定期間に受け付けたデータを締日以降に集計・分析処理するバッチ業務とを組み合わせたものである。オンライン業務の例として、チケット予約があり、一定期間は、チケットの予約期間（予約開始から予約終了（締日））に相当する。

また、バッチ業務は、予約期間の終了時刻が決定したとき、終了時刻以降を実行開始時刻としてスケジューリングされることを想定する。

期間検出部１４は、オンライン業務で、上記取得した集計開始時刻に対して直前のリクエストの（山）をＷｅｂサーバのログから抽出する。

期間検出部１４は、以下のようにして遅延防止期間を決定する。図１２（Ａ）において、締日時刻は、初回はバッチ業務の開始時刻である。次回以降は、過去のリクエスト数の実績より、集計開始時刻より前で連続したアクセスを含む期間の終了時刻を締日時刻とする。

開始時刻は、初回は集計開始時刻から前日の１日分の期間（設定で変更可）である。次回以降は、連続したアクセス期間の開始時刻を開始時刻とする。

期間検出部１４は、上記で決定された遅延防止期間が予め設定された最大期間（例えば、１０分）を超えている場合は、図１２（Ｂ）に示すように、その最大期間を遅延防止期間とする。締日時刻前に要求されたトランザクション処理時間が締日時刻を超えない最大期間が、事前に設定されている。その最大期間は、例えば、オンライン業務におけるＤＢなどを更新するトランザクション処理時間を超えない最小の期間となるため、最長でも１０分程度でよい。

リクエスト数の山の開始時刻から締日時刻までの期間が最大期間を超えている場合は、締日時刻から最大期間遡った時点の時刻を開始時刻とする。これは、予約期間を可能な限り最短期間なものとし、リソースを必要とするＶＭに優先的に予約期間を割り当てるようにするためである。

期間検出部１４は、上記で求めた遅延防止期間を、図１２（Ｃ）に示すように、予約スケジュールテーブル４３に登録する。これにより、リソースを優先的に割り当てる期間を可能な限り短くかつ動的に算出することにより、リソース競合を最小限にして業務システムの性能劣化も防止できる。

再び図１１の説明に戻る。次に、融通制御装置１３は、予約量設定部１６として機能し、リソース予約設定処理を行う（Ｓ２）。Ｓ２では、予約量設定部１６は、予約スケジュールテーブル４３に登録されている予約開始時刻（遅延防止期間の開始時刻）となったとき、予約開始時刻に対応する対象業務システムの対象ＶＭ３３に対してリソース予約設定処理を開始する。

対象ＶＭ３３でリソースを予約しても、予約したリソース量が、稼働している仮想ホスト３２の物理リソースの上限を超えない場合は、予約量設定部１６は、割り当てられたリソース量に対して１００％のリソース量でリソースの予約を設定して終了する。

ここで、予約量設定部１６は、遅延防止期間では、その開始時刻に対象ＶＭ３３に対してリソースを１００％割り当てることができる設定、すなわち予約をする。予約スケジューラ部１５は、締日時刻になると、その予約を解除する。

予約期間（予約開始時刻〜予約終了時刻）にて予約された対象ＶＭ３３がリソースを必要とする場合には、予約量設定部１６は、予約されていない他のＶＭ３３がリソースを使用していても優先してそのリソースを割り当てることができる。逆に、予約されたＶＭ３３が使わないリソース量分（例えば、ＣＰＵリソース）については、他のＶＭが使用することができる。

予約可能なリソースの上限は、その仮想ホスト３２の物理リソースの上限となる（厳密には、ハイパーバイザが使用する量やＶＭ３３毎のオーバーヘッド分を差し引いた上限となる）。そのため、複数の遅延防止期間を重ねることができる上限は、予約の上限（すなわち、物理リソースの上限）となる。

次に、融通制御装置１３は、リソース抽出部１７として機能し、融通可能なリソース量の抽出処理を行う（Ｓ３）。Ｓ３では、リソース抽出部１７は、以下のようにして、融通時に、未融通の業務システムから融通可能なリソース、及びそのリソース量を決定し、融通リソース管理テーブル４４に記録する。

まず、融通可能なリソース量を求めるタイミングは、業務システム毎でレスポンス悪化が発生しているとき、すなわち、監視装置２０により監視しているレスポンス時間が閾値を越えたときとなる。

リソース抽出部１７は、レスポンス時間の閾値超過がその業務システムでのボトルネックによるものであるか否かを判定する。すなわち、リソース抽出部１７は、レスポンス悪化時（レスポンス時間が閾値を越えたとき）に、蓄積装置１９により収集されたリソース使用量（実績値）またはリクエスト量（実績値）に基づいて、その業務システムでボトルネックが発生しているかを判断する。

ボトルネックは、業務システムで用いられるＶＭ３３のリソース（ＣＰＵ、メモリ）のいずれかについて、割り当てられたリソース量を１００％使い切っているかで判断される。リソース抽出部１７は、割り当てられたリソース量を１００％使い切っているリソースをボトルネックリソースとして融通リソース管理テーブル４４に登録する。

このとき、リソース抽出部１７は、ボトルネックと決定されたリソース以外で、リソース量に空きがあるリソースを余剰リソースとし、融通可能なリソースとする。すなわち、リソース抽出部１７は、ボトルネックのリソース以外のリソースについて、ボトルネックとなったリクエスト数で使用されるリソース量をボトルネック時に使用されるリソース量とし、空き容量を余剰リソースとする。ボトルネックが過去にも発生している場合は、安全性を高めるため余剰リソースの最小値が融通可能なリソース量として採用される。

ボトルネックが発生していない場合は、まだリソースが使用される可能性がある。この場合、リソース抽出部１７は、図１３に示すように、業務システム毎で、リクエスト数と各ＶＭのリソース使用量（ＣＰＵ使用量、メモリ使用量）の相関関係を求める。そして、その求めた相関関係に基づいて、リソース抽出部１７は、リクエスト数の増加で最初に上限に達するリソースをボトルネックリソースとして融通リソース管理テーブル４４に登録する。

なお、ＶＭの構成変更（リソース割り当て変更、ＶＭ個数の追加、削除等）やＶＭ内のアプリケーションの入れ替え、システムパラメタの変更等、ＶＭに対する変更が実施された場合、融通可能なリソース量が変化する。そのため、融通可能なリソース量が再計算され、融通リソース管理テーブル４４に登録される。

次に、融通制御装置１３は、予約量設定部１６として機能し、予約融通処理を行う（Ｓ４）。Ｓ４では、予約量設定部１６は、全ての仮想ホスト３２で物理リソースの上限までリソースが予約されている場合、以下の方法で、融通可能なリソースを有する業務システムから、予約された業務システムの処理を実行するために必要なリソースを融通する。

予約量設定部１６は、融通可能なリソースとして、業務システムのレスポンス悪化時にボトルネックとなったときの余剰リソースを利用する。予約量設定部１６は、まず融通元となる業務システムを選択する場合、過去でレスポンス悪化が発生した時にボトルネックありと判断された業務システムを優先して選択する。これはボトルネックが発生した業務システムであれば、そのときボトルネックリソース以外のリソースの空き容量は、それ以上使用されない量として信頼度が高いためである。更に、ボトルネックが発生している回数が多い業務システムについては、以下の２点の理由から優先順位が上げられる。
・ボトルネックが発生している回数が多い業務システムは、何度もボトルネックによるレスポンス悪化が発生しているにも関わらず、特に対処をしていないため、業務への影響度が低いと考えられること
・ボトルネックが発生している回数が多い業務システムについては、ボトルネックリソース以外のリソースの余剰量が明確であること

次に、予約量設定部１６は、ボトルネックとなっていないＶＭの空きリソース量（＝割り当て量−使用量）を融通可能なリソース量とする。予約量設定部１６は、ボトルネックとなったリソースについては他の業務システムへリソースの融通を行わない。これにより、融通後、融通元の業務システムにおいてリクエスト急増が発生しても当該融通元の業務システムが元々抱えているボトルネックでリソース量が頭打ちとなるため、融通による業務への影響（レスポンス悪化）を抑止することができる。したがって、この場合、業務への影響のリスクはリソース融通する前と後で変わらない。

ボトルネック発生回数が同一、もしくはボトルネック無同士といった同じ条件下において、複数の業務システムから融通元を選択する場合、予約量設定部１６は、融通可能なリソース量の合計値が多いものを優先して選択する。特に信頼度が低い業務システムから融通する場合、融通後に余剰リソースを少しでも残すことで安全性を高めるためである。

１つの業務システムで融通に必要なリソース量が不足している場合は、予約量設定部１６は、複数の業務システムからの融通を実施する。もし、これ以上、融通可能なリソースがない場合は、予約量設定部１６は、運用管理者に融通失敗を通知する。

上述の通り、図１１のフローにより、融通しあった双方の業務システムで突発的なリクエスト急増が発生しても、融通によるリソース不足で発生する業務遅延を防止できる。

以下では、図１１のフローの詳細を説明する。すなわち、期間検出部１４、予約スケジューラ部１５、予約量設定部１６、リソース抽出部１７の各処理を詳述する。

図１４は、本実施形態における期間検出部により実行される予約スケジュール追加処理のフローの一例を示す。新たに業務システムが業務システム構成テーブル４１に追加された場合、またはバッチ業務処理の開始スケジュールが追加もしくが変更された場合、期間検出部１４は、遅延防止期間算出処理を行う（Ｓ１１）。期間検出部１４は、ジョブの開始時刻を取得し、過去のリクエスト量の実績から予約開始時刻及び予約終了時刻を算出する。Ｓ１１の処理については、図１５にて詳述する。

次に、期間検出部１４は、予約スケジューリング処理を行う（Ｓ１２）。期間検出部１４は、算出された予約開始時刻及び予約終了時刻を予約スケジュールテーブル４３に登録する。Ｓ１２の処理については、図１６にて詳述する。

図１５は、本実施形態における遅延防止期間算出処理（Ｓ１１）の処理フローの一例を示す。期間検出部１４は、まず統合制御装置２１から、業務システムの構成を管理する情報である業務システム構成情報を取得し、業務システム構成情報テーブル４１に格納する。期間検出部１４は、業務システム構成情報テーブル４１において「仮想ホスト名」４１−３にてグループ化した場合の予約期間での「ＣＰＵ予約量」４１−７の合計値を、仮想ホスト毎に仮想ホストテーブル４２に格納する。期間検出部１４は、業務システム構成情報テーブル４１において、「仮想ホスト名」４１−３にてグループ化した場合の予約期間での「メモリ予約量」４１−８の合計値を、仮想ホスト毎に仮想ホストテーブル４２に格納する。

期間検出部１４は、業務システム構成テーブル４１から、オンライン業務と関係付けられているバッチ情報として、バッチ業務名（業務システム名）、そのバッチを実行するＶＭ名、仮想ホスト名を抽出する。期間検出部１４は、バッチジョブ制御装置１２から、抽出したバッチ業務名及びＶＭ名に対応するバッチを検索する（Ｓ１１−１）。期間検出部１４は、検索されたバッチのスケジュール情報から、そのバッチの開始時刻を取得する（Ｓ１１−２）。

期間検出部１４は、そのバッチを実行する業務システムに対して過去にリクエスト量に基づいて予約量を設定した実績がある場合（Ｓ１１−３で「ＹＥＳ」）、過去の実績期間に基づいて予約開始時刻と予約終了時刻を決定する。

業務システムに対して過去にリクエスト量に基づいて予約量を設定した実績がない場合または新たに追加された業務システムである場合（Ｓ１１−３で「ＮＯ」）、期間検出部１４は、デフォルト期間を用いて予約開始時刻と予約終了時刻を決定する（Ｓ１１−４）。

図１６は、本実施形態における予約スケジューリング処理（Ｓ１２）の処理フローの一例を示す。期間検出部１４は、Ｓ１１で処理対象となった各業務システムで用いられるＶＭに対して、決定した予約期間（開始時刻〜終了時刻）を、予約スケジュールテーブル４３に登録する（Ｓ１２−１）。

図１７は、本実施形態における予約量設定部により実行される予約量決定処理のフローの一例を示す。

予約量設定部１６は、予約スケジュールテーブル４３を参照して、いずれかの業務システムの予約期間が開始したと判定した場合、配置先仮想ホスト及び予約量決定処理を行う（Ｓ２１）。予約量設定部１６は、複数のＶＭの予約期間（遅延防止期間）の重なりにより、物理リソース以上の予約が必要となった場合に、予約融通処理を行う。すなわち、予約量設定部１６は、予約期間が開始された業務システム（対象業務システム）で使用される各ＶＭを稼動させるために必要なリソースを確保可能な仮想ホスト（配置先仮想ホスト）を選択する。予約量設定部１６は、必要があれば、業務システム間、または仮想ホスト間でＶＭを移動させる。

いずれの仮想ホストも、対象業務システムで使用される全ＶＭを稼動させるために必要なリソースを有さない場合には、予約量設定部１６は、予約融通処理を実施する。予約融通処理では、予約量設定部１６は、リソース融通管理テーブル４４を参照して、ボトルネック“有”の業務システムから、対象業務システムを稼動させる分のリソース量を融通する。ボトルネック“有”のシステムがない場合は、予約量設定部１６は、ボトルネック“無”のシステムから余剰リソースを融通する。Ｓ２１については、図１８で詳述する。

次に、予約量設定部１６は、Ｓ２１で決定した配置先仮想ホストにて動作する各ＶＭに予約量を設定する（Ｓ２２）。後述するようにＳ２１において、予約期間において仮想ホスト内のＶＭで使用されるリソース量が仮想ホスト３２の物理リソースの上限を超えない場合は、予約量設定部１６は、次の処理を行う。すなわち、予約量設定部１６は、業務システム構成テーブル４１に、配置先仮想ホストにて動作する各ＶＭに割り当てられたリソース量に対して１００％のリソース量を設定する。

図１８は、本実施形態における配置先仮想ホスト及び予約量決定処理（Ｓ２１）のフローの一例を示す。

予約量設定部１６は、仮想ホストテーブル４２から、対象業務システムのＶＭが稼働している仮想ホストを選択する。予約量設定部１６は、仮想ホストテーブル４２から、その選択した仮想ホストにおいて、予約期間における仮想ホストの予約量の合計が物理リソース量の上限を超えているかを判定する（Ｓ２１−１）。ここで、予約期間における仮想ホストの予約量の合計とは、仮想ホストテーブル４２の「ＣＰＵ予約量合計」４２−３、「メモリ予約量合計」４２−５に格納されている値を示す。物理量の上限とは、仮想ホストテーブル４２の「物理ＣＰＵ」４２−２、「物理メモリ」４２−４に格納されている値を示す。

その選択した仮想ホストの予約量の合計が物理量の上限を超えていない場合（Ｓ２１−１で「ＮＯ」）、予約量設定部１６は、Ｓ２１−４の処理へ進む。

その選択した仮想ホストの予約量の合計が物理量の上限を超えている場合（Ｓ２１−１で「ＹＥＳ」）、予約量設定部１６は、仮想ホストテーブル４２から、他の仮想ホストを順次選択し、選択した仮想ホストで予約できる空きリソース量があるかを判定する（Ｓ２１−２）。Ｓ２１−２では、他の仮想ホストについて、Ｓ２１−１の処理を行う。

選択した仮想ホストで予約できる空きリソース量がある場合（Ｓ２１−２で「ＹＥＳ」）、予約量設定部１６は、Ｓ２１−４の処理へ進む。

いずれの仮想ホストも予約できる空きリソース量がない場合（Ｓ２１−２で「ＮＯ」）、予約量設定部１６は、必要なリソースを確保するため、予約融通処理を行う（Ｓ２１−３）。Ｓ２１−３については、図１９で詳述する。

Ｓ２１−１で「ＮＯ」またはＳ２１−２で「ＹＥＳ」へ進んだ場合、予約量設定部１６は、選択した仮想ホストを配置先仮想ホストとする。また、予約量設定部１６は、予約融通処理（Ｓ２１−１）がされた場合、融通元の仮想ホストを配置先仮想ホストとする。

図１９は、本実施形態における予約融通処理（Ｓ２１−３）のフローの一例を示す。予約量設定部１６は、「ボトルネック有無（回数）」４４−３に基づいて、リソース融通管理テーブル４４に、ボトルネック“有”の業務システムがあるか否かを判定する（Ｓ２１−３−１）。ボトルネック“有”の業務システムがある場合（Ｓ２１−３−１で「ＹＥＳ」）、予約量設定部１６は、未融通の業務システムのうち、ボトルネック発生回数の最大のものを抽出する（Ｓ２１−３−５）。

予約量設定部１６は、抽出した業務システムの「融通可能なリソース量」４４−６に基づいて、抽出した業務システムの各ＶＭから、そのＶＭに対応する融通可能リソースの予約量を削減する（Ｓ２１−３−６）。ここでは、予約量設定部１６は、抽出した業務システムの「融通可能なリソース量」４４−６から、融通可能なリソース量を取得する。予約量設定部１６は、業務システム構成テーブル４１において、抽出した業務システムに対応する「ＣＰＵ予約量」４１−７と「メモリ予約量」４１−８とから、取得した融通可能なリソース量を削減する。

予約量設定部１６は、抽出した業務システムのリソースから、予約期間においてＶＭが使用するリソース量を削減できたかを判定する（Ｓ２１−３−７）。削減したリソース量が予約期間においてＶＭが使用するリソース量に満たない場合（Ｓ２１−３−７で「ＮＯ」）、処理がＳ２１−３−１へ戻る。

削減したリソース量が予約期間においてＶＭが使用するリソース量以上である場合（Ｓ２１−３−７で「ＹＥＳ」）、予約量設定部１６は、業務システム構成テーブル４１の、対応するリソースの予約量を、上記で削減したリソース量で更新する（Ｓ２１−３−８）。

リソース融通管理テーブル４４に、Ｓ２１−３−５で未抽出の業務システムのうち、ボトルネック“有”の業務システムがない場合（Ｓ２１−３−１で「ＮＯ」）、予約量設定部１６は、次の処理を行う。すなわち、予約量設定部１６は、リソース融通管理テーブル４４を参照して、ボトルネック発生“無”の業務システムのうち、融通可能なリソース量を有する業務システムがあるか否かを判定する（Ｓ２１−３−２）。

ボトルネック発生“無”の業務システムのうち、融通可能なリソース量を有する業務システムがある場合（Ｓ２１−３−２で「ＹＥＳ」）、予約量設定部１６は、次の処理を行う。すなわち、予約量設定部１６は、リソース融通管理テーブル４４に基づいて、ボトルネック発生“無”の業務システムから、最大の融通可能リソースを選択し（Ｓ２１−３−４）、Ｓ２１−３−６の処理を行う。

ボトルネック発生“無”の業務システムのうち、融通可能なリソース量を有する業務システムが全くない場合（Ｓ２１−３−２で「ＮＯ」）、予約量設定部１６は、リソースの確保の失敗を管理者に通知する。すなわち、全ての業務システムで融通するリソースがなくなり、リソースの予約ができなかった場合は、物理リソース不足の状況となるため、予約量設定部１６は、リソースの予約の失敗をシステム管理者に通知する。

図２０は、本実施形態における予約スケジューラ部により実行される予約終了処理フローの一例を示す。

予約スケジューラ部１５は、予約スケジュールテーブル４３を参照して、現在の時刻と予約終了時刻とを比較して、予約期間が終了したと判定した場合、該当のＶＭに対して予約の設定を解除するように、統合制御装置２１に依頼する（Ｓ３１）。その依頼に基づいて、統合制御装置２１は、該当のＶＭに対して予約の設定を解除する。

図２１は、本実施形態におけるリソース抽出部により実行される融通可能リソース抽出処理フローの一例を示す。融通可能リソース抽出処理は、監視装置２０より業務システムのレスポンス悪化が通知された場合に開始される。

リソース抽出部１７は、余剰リソース更新処理を行う（Ｓ４１）。余剰リソース更新処理では、リソース抽出部１７は、ボトルネックの発生の有無によって融通可能なリソース量の抽出処理を切り替え、融通可能リソース管理テーブル４４に値を登録、もしくは更新する。Ｓ４１の処理については、図２２で詳述する。

図２２は、本実施形態における余剰リソース更新処理（Ｓ４１）の処理フローの一例を示す。監視装置２０より業務システムのレスポンス悪化が通知された場合、リソース抽出部１７は、次の処理を行う。すなわち、リソース抽出部１７は、蓄積装置１９により収集されたその業務システムのリソース使用量（実績値）またはリクエスト量（実績値）に基づいて、その業務システムでボトルネックが発生しているかを判断する（Ｓ４１−１）。

Ｓ４１−１では、リソース抽出部１７は、業務システム構成テーブル４１から、レスポンス悪化が通知された業務システムで使用されるＶＭに割り当てられたリソース量（「ＣＰＵ」４１−５、「メモリ」４１−６）を取得する。

それから、リソース抽出部１７は、蓄積装置１９により収集されたその業務システムのリソース使用量が、割り当てられたリソース量に達しているリソースがあるかを判断する。

リソース使用量が、割り当てられたリソース量に達しているリソースがある場合、すなわち、ボトルネックが発生している場合（Ｓ４１−１で「ＹＥＳ」）、リソース抽出部１７は、次の処理を行う。すなわち、リソース抽出部１７は、リソース使用量（実績値）に基づいて、各ＶＭのリソースの空き容量を算出する。リソース抽出部１７は、算出したリソースの空き容量を融通可能なリソース量として融通可能リソース管理テーブル４４に登録する（Ｓ４１−４）。

ここで、各ＶＭの空きリソース量は、割り当てられたリソース量−リソース使用量（実績値）により算出される。ボトルネックが発生しているＶＭ（ボトルネックリソース）の場合は、ＶＭの空きリソース量は０となる。

リソース抽出部１７は、融通可能リソース管理テーブル４４において、ボトルネックリソースについて、ボトルネックであることを示すフラグ”○“を付ける。それから、リソース抽出部１７は、融通可能リソース管理テーブル４４において、発生日付を登録し、ボトルネック発生“有”を登録し、発生回数に１を加算する。

Ｓ４１−１において、リソース使用量が、割り当てられたリソース量に達しているリソースがない場合、すなわち、ボトルネックが発生していない場合（Ｓ４１−１で「ＮＯ」）、リソース抽出部１７は、次の処理を行う。すなわち、リソース抽出部１７は、単位時間あたりのリクエスト数とリソース使用量との相関分析から、最初に頭打ちとなるリソースを算出する（Ｓ４１−２）。リソース抽出部１７は、その最初に頭打ちとなるリソースをボトルネックリソースとして融通可能リソース管理テーブル４４に登録する（Ｓ４１−４）。その他のリソースについては、リソース抽出部１７は、同じ単位時間あたりのリクエスト数からリソース使用量を求め、空きリソースを融通可能リソースとして融通可能リソース管理テーブル４４に登録する。また、リソース抽出部１７は、ボトルネック発生については“無”として融通可能リソース管理テーブル４４に登録する。

図２３は、本実施形態におけるリソース抽出部により実行される融通可能リソースクリア処理フローの一例を示す。

リソース抽出部１７は、ある業務システムにおいてＶＭの構成変更が発生した場合、融通可能リソース管理テーブル４４の登録されているその業務システムで使用される全ＶＭの融通可能なリソース量をクリアする（Ｓ５１）。

図２４は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ５０は、融通制御装置１３として機能する。コンピュータ５０は、ＣＰＵ５２、ＲＯＭ５３、ＲＡＭ５６、通信Ｉ／Ｆ５４、記憶装置５７、出力Ｉ／Ｆ５１、入力Ｉ／Ｆ５５、読み取り装置５８、バス５９、出力装置６１、入力装置６２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス５９には、ＣＰＵ５２、ＲＯＭ５３、ＲＡＭ５６、通信Ｉ／Ｆ５４、記憶装置５７、出力Ｉ／Ｆ５１、入力Ｉ／Ｆ５５、及び読み取り装置５８が接続されている。読み取り装置５８は、可搬型記録媒体を読み出す装置である。出力装置６１は、出力Ｉ／Ｆ５１に接続されている。入力装置６２は、入力Ｉ／Ｆ５５に接続にされている。

記憶装置５７は、記憶部１８に相当し、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置５７またはＲＯＭ５３には、ＣＰＵ５２を取得部２と、判定部３と、特定部４と、提供部５として機能させる本実施形態に係るプログラムが格納されている。より具体的には、記憶装置５７またはＲＯＭ５３には、期間検出部１４、予約スケジューラ部１５、予約量設定部１６、リソース抽出部１７として機能させる本実施形態に係るプログラムが格納されている。また、記憶装置５７には、業務システム構成テーブル４１、仮想ホストテーブル４２、予約スケジュールテーブル４３、融通可能リソース管理テーブル４４が格納されていてもよい。

ＲＡＭ５６には、情報が一時的に記憶される。ＲＡＭ５６は、本実施形態におけるメモリ３０に相当する。

ＣＰＵ５２は、記憶装置５７またはＲＯＭ５３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。

通信Ｉ／Ｆ５４は、ネットワークと接続して他の装置と通信するためのポート等のインターフェースである。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク６０、および通信Ｉ／Ｆ５４を介して、例えば記憶装置５７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置５８にセットされて、ＣＰＵ５２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置５８によって読み取られる。

入力装置６２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネルなどを用いることが可能である。また、出力装置６１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。

ネットワーク６０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

本実施形態によれば、同時期に優先業務を多数稼動させることが可能となり、リソースの融通による融通元の業務システムへの業務影響（処理遅延）も防止できる。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

上記実施形態に関し、さらに、以下の付記を開示する。
（付記１）
複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得する取得部と、
前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定する判定部と、
前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定する特定部と、
前記余剰リソースを前記複数の情報処理システムのうち第２の情報処理システムへ融通する提供部と、
を備えることを特徴とするリソース管理装置。
（付記２）
前記特定部は、前記第１の情報処理システムに前記いずれかのリソースの枯渇が発生したことがない場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記複数のリソースから前記余剰リソースを特定する
ことを特徴とする付記１に記載のリソース管理装置。
（付記３）
前記特定部は、前記いずれかのリソースの枯渇が発生した場合、該いずれかのリソースの枯渇の発生時に前記第１の情報処理システムが動作する前記複数の仮想計算機が使用していたリソースの余剰を前記余剰リソースとして特定する、
ことを特徴とする付記１または２に記載のリソース管理装置。
（付記４）
前記取得部は、前記第１の情報処理システムにおいて処理の応答時間が閾値を超えた際の該第１の情報処理システムが動作する該複数の仮想計算機のそれぞれに割り当てられたリソースの使用量を取得し、
前記特定部は、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出し、
前記提供部は、算出された前記リソースの余剰量を前記複数の情報処理システムのうち第２の情報処理システムへ融通する
ことを特徴とする付記１〜３のうちいずれか一項に記載のリソース管理装置。
（付記５）
前記特定部は、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機がこれまでになかった場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する
ことを特徴とする付記４に記載のリソース管理装置。
（付記６）
コンピュータに、
複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得し、
前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定し、
前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定し、
前記複数の情報処理システムのうち第２の情報処理システムへ前記余剰リソースを融通する、
処理を実行させるリソース管理プログラム。
（付記７）
前記余剰リソースの特定において、前記第１の情報処理システムに前記いずれかのリソースの枯渇が発生したことがない場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記複数のリソースから前記余剰リソースを特定する
ことを特徴とする付記６に記載のリソース管理プログラム。
（付記８）
前記余剰リソースの特定において、前記いずれかのリソースの枯渇が発生した場合、該いずれかのリソースの枯渇の発生時に前記第１の情報処理システムが動作する前記複数の仮想計算機が使用していたリソースの余剰を前記余剰リソースとして特定する、
ことを特徴とする付記６または７に記載のリソース管理プログラム。
（付記９）
前記複数のリソースの使用量の取得において、前記第１の情報処理システムにおいて処理の応答時間が閾値を超えた際の該第１の情報処理システムが動作する該複数の仮想計算機のそれぞれに割り当てられたリソースの使用量を取得し、
前記余剰リソースの特定において、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出し、
前記余剰リソースの融通において、算出された前記リソースの余剰量を前記複数の情報処理システムのうち第２の情報処理システムへ融通する
ことを特徴とする付記６〜８のうちいずれか一項に記載のリソース管理プログラム。
（付記１０）
前記余剰リソースの特定において、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機がこれまでになかった場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する
ことを特徴とする付記９に記載のリソース管理プログラム。
（付記１１）
コンピュータが、
複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得し、
前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定し、
前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定し、
前記複数の情報処理システムのうち第２の情報処理システムへ前記余剰リソースを融通する、
処理を実行させるリソース管理方法。
（付記１２）
前記余剰リソースの特定において、前記第１の情報処理システムに前記いずれかのリソースの枯渇が発生したことがない場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記複数のリソースから前記余剰リソースを特定する
ことを特徴とする付記６に記載のリソース管理方法。
（付記１３）
前記余剰リソースの特定において、前記いずれかのリソースの枯渇が発生した場合、該いずれかのリソースの枯渇の発生時に前記第１の情報処理システムが動作する前記複数の仮想計算機が使用していたリソースの余剰を前記余剰リソースとして特定する、
ことを特徴とする付記６または７に記載のリソース管理方法。
（付記１４）
前記複数のリソースの使用量の取得において、前記第１の情報処理システムにおいて処理の応答時間が閾値を超えた際の該第１の情報処理システムが動作する該複数の仮想計算機のそれぞれに割り当てられたリソースの使用量を取得し、
前記余剰リソースの特定において、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出し、
前記余剰リソースの融通において、算出された前記リソースの余剰量を前記複数の情報処理システムのうち第２の情報処理システムへ融通する
ことを特徴とする付記６〜８のうちいずれか一項に記載のリソース管理方法。
（付記１５）
前記余剰リソースの特定において、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機がこれまでになかった場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する
ことを特徴とする付記９に記載のリソース管理方法。

１ リソース管理装置
２ 取得部
３ 判定部
４ 特定部
５ 提供部
６ 業務システムＡ
７ 業務システムＢ
１０ システム
１１ 管理装置群
１２ バッチジョブ制御装置
１３ 融通制御装置
１４ 期間検出部
１５ 予約スケジューラ部
１６ 予約量設定部
１７ リソース抽出部
１８ 記憶部
１９ 蓄積装置
２０ 監視装置
２１ 統合制御装置
３１ 制御対象装置群
３２（３２−１）〜Ｎ（３２−Ｎ） 仮想ホスト
３３（３３−１〜３３−Ｎ） ＶＭ
３４（３４−１〜３４−Ｎ） 仮想化装置
４１ 業務システム構成テーブル
４２ 仮想ホストテーブル
４３ 予約スケジュールテーブル
４４ 融通可能リソース管理テーブル

Claims (7)

1. 複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得する取得部と、
   前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定する判定部と、
   前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定する特定部と、
   前記余剰リソースを前記複数の情報処理システムのうち第２の情報処理システムへ提供する提供部と、
   を備えることを特徴とするリソース管理装置。
2. 前記特定部は、前記第１の情報処理システムに前記いずれかのリソースの枯渇が発生したことがない場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記複数のリソースから前記余剰リソースを特定する
   ことを特徴とする請求項１に記載のリソース管理装置。
3. 前記特定部は、前記いずれかのリソースの枯渇が発生した場合、該いずれかのリソースの枯渇の発生時に前記第１の情報処理システムが動作する前記複数の仮想計算機が使用していたリソースの余剰を前記余剰リソースとして特定する、
   ことを特徴とする請求項１または２に記載のリソース管理装置。
4. 前記取得部は、前記第１の情報処理システムにおいて処理の応答時間が閾値を超えた際の該第１の情報処理システムが動作する該複数の仮想計算機のそれぞれに割り当てられたリソースの使用量を取得し、
   前記特定部は、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出し、
   前記提供部は、算出された前記リソースの余剰量を前記複数の情報処理システムのうち第２の情報処理システムへ提供する
   ことを特徴とする請求項１〜３のうちいずれか一項に記載のリソース管理装置。
5. 前記特定部は、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機がこれまでになかった場合、処理負荷と該処理負荷に応じて使用されたリソース量との関係に関する情報に基づいて、前記第１の情報処理システムが動作する前記複数の仮想計算機のうち、前記使用量が前記割り当てられたリソースの上限値に達している仮想計算機以外の仮想計算機に割り当てられたリソースの余剰量を算出する
   ことを特徴とする請求項４に記載のリソース管理装置。
6. コンピュータに、
   複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得し、
   前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定し、
   前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定し、
   前記複数の情報処理システムのうち第２の情報処理システムへ前記余剰リソースを提供する、
   処理を実行させるリソース管理プログラム。
7. コンピュータが、
   複数の仮想計算機上で動作する複数の情報処理システムのうち第１の情報処理システムにおいて応答時間が閾値を超えた場合、該第１の情報処理システムに割り当てられた複数のリソースの使用量を取得し、
   前記複数のリソースの使用量に基づいて、前記第１の情報処理システムにおいていずれかのリソースの枯渇が発生したかを判定し、
   前記応答時間の閾値超過が前記いずれかのリソースの枯渇によるものであると判定された場合、前記複数のリソースの使用量に基づいて、前記複数のリソースのうち、枯渇した前記リソース以外のリソースである余剰リソースを特定し、
   前記複数の情報処理システムのうち第２の情報処理システムへ前記余剰リソースを提供する、
   処理を実行させるリソース管理方法。

Images