JP2017129988A - バッチ制御システム、バッチ制御プログラム、及びバッチ制御方法 - Google Patents

Abstract

【課題】仮想計算機のリソースの確保に応じて、バッチ処理を実行する技術を提供する。
【解決手段】第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する監視部と、最大リソース使用量と最大処理時間との傾向から、第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する予測部と、予測されたリソース使用量と予測された処理時間とに応じて、第２バッチ処理の実行を制御する制御部と、を備えるバッチ制御システムにより、上記課題の解決を図る。
【選択図】図３

Description

本明細書は、バッチ制御システム、バッチ制御プログラム、及びバッチ制御方法に関する。

近年、仮想化技術を活用したシステム構築の普及に伴い、オンデマンドで仮想サーバを追加し、システムの処理能力を増強することができる。

システム処理はオンライン処理とバッチ処理に大別される。オンライン処理は即座に処理を稼動・完了して結果を送り返す方式を指す。それに対して、バッチ処理は蓄積された複数件のデータを、定期的に一括処理する方式であり、オンライン処理とは異なり、ユーザとの対話なく処理が進められる。

バッチ処理はスケジュールに基づき、同一サーバ上で複数のバッチ処理を順次稼動する方法が主流である。しかしシステムを運用していくうちに、以下のような状況が発生することが予想される。

（状況１）バッチ処理量が日々増加すると、予定時間内にバッチ処理が完了せず、終了時間が延長される。この状態のまま次のバッチ処理開始時刻が到来すると、複数のバッチ処理を並行して稼動する状況が発生し、「リソース使用量」がサーバの許容量を超過する。

（状況２）また、オンライン処理等のバッチ処理以外のサーバ処理が日々増加すると、もともと並行稼動が予定されていたバッチ処理が稼動する度に、「リソース使用量」がサーバの許容量を超過する。

上記のような「リソース使用量」がサーバの許容量を超過する状態では、バッチ処理稼働中にCentral Processing Unit（ＣＰＵ）の取り合いが発生するなどして、サーバ全体のパフォーマンスが低下する。その結果バッチ処理時間が増加し、全てのバッチ処理が予定時間内に終了できないといった課題が発生する。また、一番負荷のかかるバッチ処理に合わせてサーバをサイジングすると、ピーク時以外は空きリソースが多いサーバが存在するという課題がある。

バッチ処理量が増加した場合に発生する課題をリソースグラフで説明する。
図１は、状況１についてのリソースグラフを示す。リソースグラフは横軸が時間、縦軸が「リソース使用量」を示している。以下では、「ＣＰＵ使用率」や「メモリ使用量」、「ディスク使用帯域」を含め、「リソース使用量」として記載するが、ＣＰＵの「リソース使用量」の場合は、「ＣＰＵ使用率」を意味する。

また、グラフ中の実線は各処理の「リソース使用量」、破線が「リソース使用量」の合計を示している。ここでは同一仮想サーバ上でバッチＡ、バッチＢ、バッチＣが順に稼動が予定されており、オンライン処理などのバッチ処理以外のサーバ処理も稼動しているものとする。

図１（Ａ）の通常時では、「リソース使用量」の合計が仮想サーバの許容量である１００％を下回っている。図１（Ｂ）のバッチ処理量が増加した場合では、バッチＡの処理量が日々増加し、予定時間内にバッチＡの処理が完了せず、終了時間が延長している場合を示している。その結果、バッチＢ稼働中にバッチＡも稼動する状況が発生し、「リソース使用量」が仮想サーバの許容量である１００％を超過するため、仮想サーバの全体のパフォーマンスが低下し、予定終了時刻にバッチ処理が終了しないといった課題が発生する。

図２は、状況２についてのリソースグラフを示す。バッチ処理が稼動する状況は図１の場合と同様のものとする。図２の通常時では、「リソース使用量」の合計が仮想サーバの許容量である１００％を下回っている。図２のバッチ処理以外のサーバ処理量が増加した場合では、オンライン処理等のバッチ処理以外のサーバ処理が日々増加し、「リソース使用量」が全体的に増加している場合を示している。その結果、バッチＡ、バッチＢ、バッチＣが稼動するたびに「リソース使用量」が仮想サーバの許容量である１００％を超過するため、仮想サーバの全体のパフォーマンスが低下し、予定終了時刻にバッチ処理が終了しないといった課題が発生する。

上記の課題を解決する為に、例えば第１の技術（例えば、特許文献１）、第２の技術（例えば、特許文献２）が提案されている。

第１の技術では、バッチ処理を起動した後に、現在のバッチ処理の進捗から単位時間当たりの処理件数を算出し、バッチ処理の終了予想時刻を予測する。バッチ処理の終了予想時間が、本来予定されていたバッチ処理の終了予定時刻を超える場合、オンライン実行基盤の処理要求を制限するか他のオンライン実行基盤に移動させることにより、バッチ実行基盤をスケールアップさせる。

第２の技術では、バッチ処理で扱うデータを、全てロット単位でデータをグルーピングし、ロット単位のデータに対して行う。稼動中のバッチ処理の処理進捗率（＝累計処理件数／全処理対象件数）と必要進捗率（＝累計処理時間／要求処理時間）を比較し、遅延が発生していると判断すると、所定の処理によりスケールアウトを実施し、遅延回復に必要なリソースを確保することで処理遅延を回復させる。

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

第１の技術、第２の技術では、バッチ稼動中に現在のバッチ処理の進捗状況から構成変更（スケールアップまたはスケールアウト）を判断・実施している。しかしながら、いずれも日々のバッチ処理の増加傾向を考慮していないことと、バッチ稼動中に構成変更を判断・実施していることから、以下の場合において課題が残るため、上述の課題は解決できていない。
・第１の技術：スケールアップで追加できるリソースは物理的なリソースが上限となり、物理サーバの上限を超えるリソースが必要となった場合には適応できないといった課題がある。
・第２の技術：バッチ稼動中のスケールアウトはレコード（データ）単位に処理が完結するバッチ処理に限定される。しかし、複数テーブルや複数レコードにまたがった更新処理が発生するバッチ処理は単体の仮想サーバで稼動する必要があり、バッチ処理稼動中のスケールアウトはできない。そのため、複数テーブルや複数レコードにまたがった更新処理が発生するバッチ処理を行う場合には適応できないといった課題がある。

また、上述の課題を解決する為に、ＳＱＬなどの特定のバッチ処理に特化した技術も考えられるが、ＳＱＬ以外のバッチ処理には適応できないといった課題がある。

本発明の一側面では、仮想計算機のリソースの確保に応じて、バッチ処理を実行する技術を提供する。

本発明の一側面に係るバッチ制御システムは、監視部と、予測部と、制御部とを含む。監視部は、第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する。予測部は、最大リソース使用量と最大処理時間の傾向から、第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する。制御部は、予測されたリソース使用量と予測された処理時間とに応じて、第２バッチ処理の実行を制御する。

本発明の一側面によれば、仮想計算機のリソースの確保に応じて、バッチ処理を実行することができる。

状況１についてのリソースグラフを示す。 状況２についてのリソースグラフを示す。 本実施形態におけるバッチ制御システムの一例を示す。 本実施形態におけるサーバシステムの全体構成を示す。 本実施形態における仮想サーバのブロック図を示す。 本実施形態における仮想サーバの機能を説明するための図である。 本実施形態で用いるデータの一例を示す。 本実施形態における全体のフローを示す。 本実施形態における想定している動作環境を説明するための図である。 本実施形態におけるバッチ実行制御部の起動条件及び処理フローを示す。 本実施形態におけるバッチ監視部の動作を説明するための図である。 本実施形態におけるバッチ監視部の起動条件及び処理フローを示す。 本実施形態におけるバッチ予測部の動作を説明するための図である。 本実施形態におけるバッチ予測部の起動条件及び処理フローを示す。 本実施形態におけるバッチ起動判定部の動作を説明するための図である。 本実施形態におけるバッチ実行制御部の起動条件及び処理フローを示す。 本実施形態における連携管理部２１ｅの動作を説明するための図である。 本実施形態における連携管理部２１ｅの起動条件及び処理フロー（その１）を示す。 本実施形態における連携管理部２１ｅの起動条件及び処理フロー（その２）を示す。 本実施形態における連携管理部（スケールアップ）２１ｆの動作を説明するための図である。 本実施形態における連携管理部（スケールアップ）２１ｆの起動条件及び処理フローを示す。 本実施形態における連携管理部（スケールアウト）２１ｇの動作を説明するための図である。 本実施形態における連携管理部（スケールアウト）２１ｇの起動条件及び処理フローを示す。 本実施形態におけるサーバ監視部２１ｈの動作を説明するための図である。 本実施形態におけるサーバ監視部２１ｈの起動条件及び処理フローを示す。 本実施形態におけるサーバ予測部２１ｉの動作を説明するための図である。 本実施形態におけるサーバ予測部２１ｉの起動条件及び処理フローを示す。 上述の状況１について、本実施形態の適用後のリソースグラフを示す。 上述の状況２について、本実施形態の適用後のリソースグラフを示す。

本実施形態では、以下のような仮想化環境に適した動的なバッチ制御方式を提案する。本実施形態では、仮想サーバの「リソース閾値」を事前に定義しておき、以下の処理をＳ０から順に実施する。

（Ｓ０）予測「リソース使用量」の算出
バッチ稼働中における「最大リソース使用量」と「最大処理時間」を記録し、記録した「最大リソース使用量」と「最大処理時間」の傾向から次回のバッチ稼動時における「予測リソース使用量」と「予測処理時間」を算出する。同様に、バッチ処理以外のサーバ処理の「リソース使用量」記録し、記録した「リソース使用量」の傾向からバッチ処理以外のサーバ処理の「予測リソース使用量」を算出する。

（Ｓ１）バッチ起動判断
対象バッチ処理の「起動時刻」が到来した際、対象バッチ処理の「予測処理時間」の範囲において、対象バッチ処理と、他のバッチ処理と、バッチ処理以外のサーバ処理の「予測リソース使用量」の合計が「リソース閾値」内で収まるか否かを判定する。「予測リソース使用量」の合計が「リソース閾値」内で収まる場合はバッチ処理を起動させる。「予測リソース使用量」の合計が「リソース閾値」内で収まらない場合は、Ｓ２の処理を実施する。

（Ｓ２）リソースに余裕のある他の仮想サーバに切り替え
仮想基盤連携部にて、同じ物理サーバ内からリソースに余裕のある仮想サーバを検索し、リソースに余裕のある仮想サーバが存在する場合、バッチ処理を、そのリソースに余裕のある仮想サーバに切り替えて、Ｓ１の処理を実施する。リソースに余裕のある仮想サーバが存在しない場合は、Ｓ３の処理を実施する。

（Ｓ３）スケールアップにてリソースを増強
同じ物理サーバ内から空きリソースを検索し、空きリソースが存在する場合、全仮想化基盤管理と連携し、バッチ処理を起動させる仮想サーバをスケールアップによってリソース増強して、Ｓ１の処理を実施する。空きリソースが存在しない場合は、Ｓ４の処理を実施する。

（Ｓ４）スケールアウトにてリソースを増強
他の物理サーバ内から空きリソースを検索し、空きリソースが存在する場合、全仮想化基盤管理と連携してスケールアウトによって他の物理サーバ上にバッチ処理を起動させる仮想サーバを新設する。さらにバッチ処理を起動させる仮想サーバをその新設した仮想サーバに切り替えた後、Ｓ１の処理を実施する。その後、バッチ処理が起動しない場合は管理者に異常を通知する。

また、Ｓ４の処理中において、他の物理サーバ内から空きリソースを検索し、リソースに余裕のある仮想サーバが存在しない場合も管理者に異常を通知する。

本実施形態では、バッチ処理全般に対してバッチ起動前に必要な「リソース使用量」を予測し、バッチ単位ごとに構成変更（スケールアップ、スケールアウト）を判断・実施する。そのため、バッチ処理起動時には単体の物理サーバ上にて、処理完了に必要なリソースが確保された仮想サーバ環境でバッチ処理が稼動される。そのため、仮想サーバの許容量を超えることなくバッチ処理を完了できる。加えて、以下の課題を解決できる。

本実施形態では、バッチ稼動状況予測部（後述するバッチ予測部）において、ＯＳの部を利用して「リソース使用量」の予測を実現しており、ＳＱＬなどの特定ソフトウェアに依存した「リソース使用量」の予測は行っていない。そのため、バッチ処理の種類は問わず、バッチ処理全般に対して「リソース使用量」の予測を行うことができる。上記の結果から、本実施形態はＳＱＬ以外のバッチ処理全般に対して、上記課題を解決できる。

また、本実施形態ではスケールアップによって必要なリソースの確保が実施できなかった場合、スケールアウトを実施するので、物理サーバの上限を超えるリソースが必要となった場合にも適応できる。上記の結果から、バッチ処理稼動中のリソースの取り合いによるパフォーマンス低下を防ぐことができ、バッチ処理が予定時間内に終了できないといった課題を解決することができる。

また、本実施形態では単体の仮想サーバ上にて、処理完了に必要なリソースが確保された仮想サーバ環境でバッチ処理が稼動される。そのため、単体の仮想サーバ上でしか処理が稼動できない、複数テーブルや複数レコードにまたがった更新処理が発生するバッチ処理にも適応できる。上記の結果から、バッチ処理稼動中のリソースの取り合いによるパフォーマンス低下を防ぐことができ、バッチ処理が予定時間内に終了できないといった課題を解決することができる。

さらに、本実施形態を適用することで、特定のバッチ処理ピーク時に合わせた仮想サーバのサイジングが不必要になるとともに、ピーク時以外の空きリソースを他のバッチ処理に活用することが可能となる。その結果、仮想化基盤全体でリソースをより有効活用できる。

図３は、本実施形態におけるバッチ制御システムの一例を示す。バッチ制御システム１は、監視部２と、予測部３と、制御部４とを含む。バッチ制御システム１の一例として、後述するサーバシステム１１が挙げられる。

監視部２は、第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する。監視部２は、一例として、後述するバッチ監視部２１ｂを含む。

予測部３は、最大リソース使用量と最大処理時間の傾向から、第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する。予測部３は、一例として、後述するバッチ予測部２１ｃを含む。

制御部４は、予測されたリソース使用量と予測された処理時間とに応じて、第２バッチ処理の実行を制御する。制御部４の一例として、後述するバッチ起動判定部２１ｄが挙げられる。

このように構成することにより、仮想計算機のリソースの確保に応じて、バッチ処理を実行することができる。

監視部２は、さらに第１バッチ処理以外の第１仮想計算機による第１処理で用いるリソース使用量を監視する。監視部２は、一例として、後述するサーバ監視部２１ｈを含む。

予測部３は、第１処理で用いるリソース使用量の傾向から、第２バッチ処理時における第１処理で用いるリソース使用量を予測する。予測部３は、一例として、後述するサーバ予測部２１ｉを含む。

制御部４は、第２バッチ処理の起動時刻が到来した際に、次の処理を行う。すなわち、制御部４は、予測された処理時間において実行される、第２バッチ処理と、第２バッチ処理以外の他のバッチ処理と、非バッチ処理とのそれぞれで用いるリソース使用量の合計が閾値より小さい場合、第２バッチ処理を起動させる。

このように構成することにより、第１仮想計算機のリソースの許容量を超えない範囲で、第２バッチ処理を実行することができる。

バッチ制御システムは、さらに、切替部５を含む。切替部５は、リソース使用量の合計が閾値以上である場合、第１仮想計算機を含む第１物理計算機内からリソースに余裕のある第２仮想計算機を検索する。切替部５は、第２仮想計算機が存在する場合、第２バッチ処理を起動させる仮想計算機を第１仮想計算機から第２仮想計算機に切り替える。切替部５の一例として、後述する連携管理部２１ｅが挙げられる。

このように構成することにより、第２バッチ処理を起動させる仮想計算機をリソースに余裕のある他の仮想計算機に切り替えることができる。

バッチ制御システムは、さらに、スケールアップ調整部６を含む。スケールアップ調整部６は、第２仮想計算機が存在しない場合、第１物理計算機内から空きリソースを検索する。スケールアップ調整部６は、第１物理計算機に空きリソースが存在する場合、第２バッチ処理を起動させる第１仮想計算機に空きリソースを融通する。スケールアップ調整部６の一例として、後述する連携管理部（スケールアップ）２１ｆが挙げられる。

このように構成することにより、スケールアップにてリソースを増強することができる。

バッチ制御システムは、さらに、スケールアウト調整部７を含む。
スケールアウト調整部７は、第１物理計算機に空きリソースが存在しない場合、他の物理計算機内から空きリソースを検索する。スケールアウト調整部７は、他の物理計算機のいずれかである第２物理計算機に空きリソースが存在する場合、第２物理計算機上に第２バッチ処理を起動させる第３仮想計算機を追加する。スケールアウト調整部７は、第２バッチ処理を起動させる仮想サーバを第１仮想計算機から第３仮想計算機に切り替える。スケールアウト調整部７の一例として、後述するスケールアウト調整部７が挙げられる。

このように構成することにより、スケールアウトにてリソースを増強することができる。

スケールアウト調整部７は、他の物理計算機のいずれにも空きリソースが存在しない場合、または、第２バッチ処理を起動させる仮想サーバを前記第１仮想計算機から第３仮想計算機に切り替えた後に第２バッチが起動しない場合、異常である旨を通知する。
このように構成することにより、運用者にリソース不足を通知することができる。

以下に本実施形態について詳述する。
図４は、本実施形態におけるサーバシステムの全体構成を示す。本実施形態における仮想計算機でのバッチ制御方式は、図４に示すサーバシステム１１により実現される。

サーバシステム１１は、複数台の物理サーバ１４と、全仮想化基盤管理１２とを含む。複数台の物理サーバ１４は、ネットワーク１３に接続される。全仮想化基盤管理１２は、ネットワーク１３上で接続されている全ての物理サーバ１４上の仮想化基盤管理（ハイパーバイザ）１５を管理する。なお、ネットワーク１３は、インターネット、Local Area Network（ＬＡＮ）等の通信ネットワークを含む。

ハイパーバイザ１５は、自身が配備されている物理サーバ１４上に存在する全ての仮想サーバ１６を管理する。ハイパーバイザ１５によりＣＰＵ、メモリなどのリソースが仮想的に提供されるため、物理サーバ１４上には複数台の仮想サーバ１６が存在することができる。また、物理サーバ１４上には空きリソース１７が存在しても良い。

図５は、本実施形態における仮想サーバ１６のブロック図を示す。仮想サーバ１６は、仮想的に、主記憶装置２３、二次記憶装置２２、ネットワークインタフェース２４、およびＣＰＵ２１を含む。主記憶装置２３、二次記憶装置２２、ネットワークインタフェース２４、およびＣＰＵ２１が互いに接続されている。

ネットワークインタフェース２４は、仮想サーバがネットワーク１３に接続するためのインタフェースである。

ＣＰＵ２１は二次記憶装置２２から主記憶装置２３にロードされたプログラムを稼動する演算処理装置である。ＣＰＵ２１が実行するプログラムは、ネットワークを介して取得されてもよいし、可搬型メモリ装置やＣＤ−ＲＯＭ等のコンピュータ読み取り可能な可搬型記録媒体が物理サーバ１５の読出装置に装着されることにより取得されてもよい。

主記憶装置２３は、ＣＰＵ２１によって稼動されるプログラムおよびプログラムの稼動に必要なデータを二次記憶装置２２からロードする記憶装置である。二次記憶装置２２は、仮想サーバ１６に割り当てられたバッチ処理が使用するバッチモジュールや、主記憶装置２３によってＣＰＵ２１で稼動された演算結果などを格納する記憶媒体である。

図６は、本実施形態における仮想サーバの機能を説明するための図である。ＣＰＵ２１は、本実施形態にかかる、主記憶装置２３にロードされたプログラムを読み出すことにより、バッチ管理部３１、サーバリソース管理部３２、仮想基盤連携部３３として機能する。

バッチ管理部３１は、バッチ処理に必要な「リソース使用量」を予測して構成変更を判断する。サーバリソース管理部３２は、バッチ処理以外のサーバ処理に必要な「リソース使用量」を予測する。仮想基盤連携部３３は、スケールアップとスケールアウトを実行する。

バッチ管理部３１は、バッチ監視部２１ｂ、バッチ予測部２１ｃ、バッチ実行制御部２１ａを含む。

バッチ監視部２１ｂは、バッチ処理の稼働状況を監視し、具体的には、バッチ稼働中における各「最大リソース使用量」と「最大処理時間」を記録する。バッチ予測部２１ｃは、バッチ処理の稼働状況を予測し、具体的にはバッチ監視部２１ｂにより記録されたバッチ稼動の傾向から次回のバッチ稼動時における「予測リソース使用量」と「予測処理時間」を予測する。

バッチ実行制御部２１ａは、バッチ処理の実行を制御し、具体的には、バッチ処理の「起動時刻」が到来したことを確認する。バッチ実行制御部２１ａは、バッチ起動判定部２１ｄを含む。バッチ起動判定部２１ｄは、「リソース閾値」と「予測リソース使用量」を比較し、比較結果に基づいてハッチ処理を起動させるかを判定する。

サーバリソース管理部３２は、サーバ監視部２１ｈ、サーバ予測部２１ｉを含む。サーバ監視部２１ｈは、サーバの稼動状況を監視し、具体的にはバッチ処理以外のサーバ処理の「リソース使用量」を記録する。サーバ予測部２１ｉは、サーバの稼働状況を予測し、具体的にはサーバ監視部２１ｈにより記録されたバッチ稼動の傾向から次回の「予測リソース使用量」を予測する。

仮想基盤連携部３３は、連携管理部２１ｅ、連携管理部（スケールアップ）２１ｆ、連携管理部（スケールアウト）２１ｇを含む。

連携管理部２１ｅは、同じ物理サーバ内からリソースに余裕のある他の仮想サーバを検索し、バッチ処理を起動する仮想サーバを切り替える。連携管理部（スケールアップ）２１ｆは、同じ物理サーバ内から空きリソースを検索し、バッチ処理を起動する仮想サーバのパフォーマンスを向上させる（スケールアップする）。連携管理部（スケールアウト）２１ｇは、他の物理サーバ内から空きリソースを検索し、バッチ処理を起動する仮想サーバの数を増やす（スケールアウトする）。

二次記憶装置２２は、バッチ集計データ４１、バッチ予測データ４２、バッチ起動スケジュール４３、サーバ予測データ４４、サーバ集計データ４５、バッチモジュール４６、定義ファイル４７を含む。

バッチ集計データ４１は、バッチ処理の稼働状況の集計データであって、バッチ監視部２１ｂで算出した「最大リソース使用量」と「最大処理時間」を記録する。バッチ予測データ４２は、バッチ処理の稼働状況の予測データであって、バッチ予測部２１ｃで予測した次回の「予測リソース使用量」と「予測処理時間」を記録する。

バッチ起動スケジュール４３は、仮想サーバ１６に割り当てられた全てのバッチ処理のバッチ起動に必要な情報を保持する。

サーバ集計データ４５は、サーバの稼働状況の集計データであって、サーバ監視部２１ｈで記録した「リソース使用量」を記録する。サーバ予測データ４４は、サーバの稼働状況の予測データであって、サーバ予測部２１ｉで予測した次回の「リソース使用量」を記録する。

バッチモジュール４６は、仮想サーバ１６に割り当てられたバッチ処理が使用するプログラムである。定義ファイル４７は、バッチ処理の起動情報についての定義ファイルであって、仮想サーバ１６に割り当てられたバッチ処理ごとのバッチ起動に必要な情報を保持する。

図７は、本実施形態で用いるデータの一例を示す。図７（Ａ）に示すように、バッチ集計データ４１は、バッチ処理の「起動時刻」、本セッションの「最大ＣＰＵ使用率」、本セッションの「処理時間」の項目を含む。

図７（Ｂ）に示すように、バッチ予測データ４２は、「過去最大のＣＰＵ使用率」、「増加傾向の傾き」、「予測ＣＰＵ使用率」の項目を含む。

図７（Ｃ）に示すように、バッチ起動スケジュール４３は、「バッチモジュール名」、「バッチモジュール格納場所」、「起動時刻」、「起動ユーザ」、「処理データ格納場所」の項目を含む。

図７（Ｄ）に示すように、サーバ予測データ４４は、「時間」、「予測ＣＰＵ使用率」の項目を含む。

図７（Ｅ）に示すように、サーバ集計データ４５は、「時間」、「仮想サーバ上の全ての処理の「ＣＰＵ使用率」」、「仮想サーバ上の全てのバッチ処理の「ＣＰＵ使用率」」、「バッチ処理以外のサーバ処理の「ＣＰＵ使用率」」の項目を含む。

図７（Ｆ）に示すように、定義ファイル４７は、「バッチモジュール名」、「バッチモジュール格納場所」、「起動時刻」、「起動ユーザ」、「処理データ格納場所」の項目を含む。

図８は、本実施形態における全体のフローを示す。以下では、仮想化環境に適した動的なバッチ制御方式について説明する。本実施形態では、上述した処理Ｓ０〜Ｓ４の処理がＳ０から順に実施される。なお、仮想サーバの「リソース閾値」は事前に定義されている。

Ｓ０において、予測「リソース使用量」が算出される。ここでは、バッチ監視部２１ｂは、バッチ稼働中における「最大リソース使用量」と「最大処理時間」を記録する。バッチ予測部２１ｃは、バッチ処理の「予測リソース使用量」と 「予測処理時間」を予測する。サーバ監視部２１ｈは、バッチ処理以外のサーバ処理の「リソース使用量」を記録する。サーバ予測部２１ｉは、バッチ処理以外のサーバ処理の「予測リソース使用量」を予測する。

Ｓ１において、バッチ起動が判断される。ここでは、バッチ実行制御部２１ａは、バッチ処理の「起動時刻」が到来したことを確認する。バッチ起動判定部２１ｄは、対象バッチ処理の「予測処理時間」において、「リソース閾値」と「予測リソース使用量」を比較する。比較の結果、予測リソース使用量がリソース閾値を超えていない場合、バッチ起動判定部２１ｄは、バッチ処理を起動させる。予測リソース使用量がリソース閾値を超えている場合、Ｓ２の処理へ移行する。

Ｓ２において、予測リソース使用量がリソース閾値を超えている仮想サーバ１６が、予測リソースリソースに余裕のある他の仮想サーバ１６に切り替えられる。ここでは、連携管理部２１ｅは、自身が配備された同じ物理サーバ内から余裕のある他の仮想サーバ１６を検索する。同じ物理サーバ内に余裕のある他の仮想サーバ１６があれば、仮想サーバを切り替えて、Ｓ１のバッチ起動判定部２１ｄによる処理が再度行われる。同じ物理サーバ内に余裕のある他の仮想サーバ１６がなければ、Ｓ３の処理へ移行する。

Ｓ３において、スケールアップにてリソースが増強される。ここでは、連携管理部（スケールアップ）２１ｆは、自身が配備された同じ物理サーバ内から空きリソースを検索する。空きリソースがあれば、連携管理部（スケールアップ）２１ｆは、スケールアップしてＳ１のバッチ起動判定部２１ｄによる処理が再度行われる。空きリソースがなければ、Ｓ４の処理へ移行する。

Ｓ４において、スケールアウトにてリソースが増強される。ここでは、連携管理部（スケールアウト）２１ｇは、他の物理サーバ内から空きリソースを検索する。空きリソースがなければ、異常通知が発行される。空きリソースがあれば、連携管理部（スケールアウト）２１ｇは、スケールアウトしてＳ１のバッチ起動判定部２１ｄによる処理が再度行われる。なお、スケールアウト後、Ｓ１にてバッチ処理が起動しない場合も異常通知が発行される。

本実施形態における部を説明するに当たり、想定している動作環境を図９のリソースグラフを使用して説明する。

図９は、本実施形態における想定している動作環境を説明するための図である。本実施形態では、「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。また、仮想サーバ１号機１６−１の「ＣＰＵ使用率の閾値（リソース閾値）」を１００％と事前に定義したものとする。

図９のグラフでは、横軸が時間、縦軸が「リソース使用量」を示している。また、グラフ中の実線は各処理の「ＣＰＵ使用率」、破線が各処理の「ＣＰＵ使用率」の合計を示している。ここでは仮想サーバ１号機１６−１上でバッチ処理（バッチＡ）の稼動が予定されており、さらに同一仮想サーバ１号機１６−１にてオンライン処理などのバッチ処理以外のサーバ処理も稼動しているものとする。また、この例では、バッチＡは１日に１セッション実行することを想定しており、バッチＡの「起動時刻」は、例えば「2015/09/05 00:00:00」とする。また、バッチ処理が起動し、バッチ処理が終了するまでを１セッションと定義する。

なお、ここでは、「リソース使用量」として「ＣＰＵ使用率」のほかに、同様の手法で「メモリ使用量」と「ディスク使用帯域」も扱えるものとする。

図１０は、本実施形態におけるバッチ実行制御部の起動条件及び処理フローを示す。図１０（Ａ）に示すように、バッチ実行制御部２１ａは、仮想サーバ１６の起動と同時に起動し、仮想サーバ１６の停止時まで稼動し続ける。

バッチ実行制御部２１ａの動作を、図１０（Ｂ）を用いて説明する。バッチ起動スケジュール４３には、図７（Ｃ）に示すように、仮想サーバ１号機１６−１に割り振られている全てのバッチ処理の「起動時刻」などの各バッチ起動に必要な情報が記載されている。

バッチ実行制御部２１ａは、所属する仮想サーバ起動１号機１６−１と同時に起動し、バッチ起動スケジュール４３を参照してバッチＡの「起動時刻」などの各バッチ起動に必要な情報を参照する（Ｓ１１）。

バッチ実行制御部２１ａは、バッチ起動スケジュール４３とシステム時刻を比較して、バッチ処理の「起動時刻」が到来したか否かを判定する（Ｓ１２）。図７（Ｃ）の例の場合、バッチＡの「起動時刻」である2015/09/05 00:00:00が到来した際、バッチ実行制御部２１ａは、バッチ起動判定部２１ｄにバッチ起動判断を依頼し、バッチ実行制御部２１ａは処理を完了する。

図１１は、本実施形態におけるバッチ監視部の動作を説明するための図である。この例では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。また、この例では、最大ＣＰＵ使用率」は１コア換算で記録するものとする。また、バッチ監視部は、本セッションの「最大リソース使用量」として「最大ＣＰＵ使用率」のほかに、同様の手法で「最大メモリ使用量」と「最大ディスク使用帯域」も記録できるものとする。

図１１（Ａ）に示すように、バッチ稼動状況監視のリソースグラフは、バッチＡ稼働中のリソースグラフで、横軸が時間、縦軸が「ＣＰＵ使用率」を示している。また、グラフ中の点は現時点でのバッチＡの「ＣＰＵ使用率」を示している。

図１１（Ｂ）に示すように、バッチ集計データ４１のテーブルには、バッチＡの「起動時刻」と本セッションの「最大ＣＰＵ使用率」と「処理時間」が格納される。

図１２は、本実施形態におけるバッチ監視部の起動条件及び処理フローを示す。図１２（Ａ）に示すように、バッチ監視部２１ｂは、バッチ起動と同時に起動し、現在割り当てられているバッチ処理ごとに情報を記録する。この例では、バッチ監視部２１ｂは、バッチＡの「起動時刻」である2015/09/05 00:00:00が到来すると起動する。

図１２（Ｂ）に示すように、バッチ監視部２１ｂは、バッチ処理の「リソース使用量」（例えば、「ＣＰＵ使用率」、「メモリ使用量」、「ディスク使用帯域」等）を監視し（Ｓ２１）、バッチ稼働中の各「最大リソース使用量」を更新・保持する（Ｓ２２）。この例では、バッチ監視部２１ｂは、バッチＡの稼働中において、バッチＡの「ＣＰＵ使用率」を監視し、「最大ＣＰＵ使用率」を更新・保持する。

バッチ監視部２１ｂは、バッチ処理完了後、「起動時刻」と「最大リソース使用量」と「処理時間」をバッチ集計データ４１として記録する（Ｓ２３）。この例では、バッチＡの処理完了後、バッチ監視部２１ｂは、バッチＡの「起動時刻」と、保持している「最大ＣＰＵ使用率」と「処理時間」（起動時刻と処理完了時刻の差）をそれぞれ、本セッションの「最大リソース使用量」と「処理時間」としてバッチ集計データ４１に記録する。この例では、バッチ集計データ４１のテーブルに「起動時刻」2015/09/05 00:00:00、本セッションの「最大ＣＰＵ使用率」80%、本セッションの「処理時間」１時間が記録される。

記録した後、バッチ監視部２１ｂはバッチ予測部２１ｃに処理を依頼し、バッチ監視部２１ｂは処理を完了する（Ｓ２４）。

図１３は、本実施形態におけるバッチ予測部の動作を説明するための図である。この例では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。なお、「最大ＣＰＵ使用率」は１コア換算で記録する。本部では「予測リソース使用量」として「予測ＣＰＵ使用率」のほかに、同様の手法で「予測メモリ使用量」と「予測ディスク使用帯域」も扱えるものとする。

図１３（Ａ）のバッチ予測部のリソースグラフは、バッチＡ稼働中のリソースグラフで、横軸が日付、縦軸が「ＣＰＵ使用率」を示している。本例では、バッチ処理は１日に１セッション実行されるため、セッションを区別する為に日付を記載している。

グラフ中の点は（2015/09/03〜2015/09/05における）セッションごとの「最大ＣＰＵ使用率」と本例で更新された「予測ＣＰＵ使用率」を示している。

図１３（Ｂ）の「バッチ集計データ」のテーブルには、バッチＡの「起動時刻」とセッションごとの「最大ＣＰＵ使用率」が格納されている。

図１３（Ｃ）の「バッチ予測データ」のテーブル（更新前）には、本例で更新される前のバッチＡの「最大ＣＰＵ使用率」「増加傾向の傾き」「予測ＣＰＵ使用率」が格納されている。

図１３（Ｃ）の「バッチ予測データ」のテーブル（更新後）には、本例で更新された後のバッチＡの「最大ＣＰＵ使用率」「増加傾向の傾き」「予測ＣＰＵ使用率」が格納されている。

図１４は、本実施形態におけるバッチ予測部の起動条件及び処理フローを示す。図１４（Ａ）に示すように、バッチ予測部２１ｃは、バッチ監視部２１ｂから依頼を受けると起動する。バッチ予測部２１ｃは、割り当てられているバッチ処理ごとに情報を記録する。

図１４（Ｂ）に示すように、バッチ予測部２１ｃは、前回のバッチ稼動で記録したバッチ集計データ４１の「最大リソース使用量」とバッチ予測データ４２の「過去最大のリソース使用量」を比較する（Ｓ３１）。

「最大リソース使用量」が「過去最大のリソース使用量」よりも大きい場合、バッチ予測部２１ｃは、バッチ予測データ４２の「過去最大のリソース使用量」を更新する（Ｓ３２）。図１３の例では、バッチ予測部２１ｃは、「バッチ集計データ」４１のテーブルから2015/09/05の「最大ＣＰＵ使用率」８0%と、「バッチ予測データ」４２のテーブル（更新前）から（2015/09/04の）「過去最大のＣＰＵ使用率」６０％を比較する。比較結果から、バッチ予測部２１ｃは、（「最大ＣＰＵ使用率」のほうが大きいため）「過去最大のＣＰＵ使用率」を８０％に更新する。+
バッチ予測部２１ｃは、「過去最大のリソース使用量」の更新前、更新後の差分から「増加傾向の傾き」を算出する（Ｓ３３）。本例では、「最大ＣＰＵ使用率」の更新前、更新後の差分が２０％、セッション数の差分が２のため、「増加傾向の傾き」として１０％が算出される。

バッチ予測部２１ｃは、「増加傾向の傾き」から次回の「予測リソース使用量」を算出し、記録する（Ｓ３４）。ここで、「予測リソース使用量」は、「増加傾向の傾き」と「過去最大のリソース使用量」との和である。本例では「増加傾向の傾き」が１０％、「過去最大のＣＰＵ使用率」が８０％のため、次回の「予測ＣＰＵ使用率」として９０％が算出される。以上の処理結果から、「最大ＣＰＵ使用率」「増加傾向の傾き」「予測ＣＰＵ使用率」をそれぞれ「バッチ予測データ」４２に記録する。記録した後、バッチ予測部２１ｃは、処理を完了する。

バッチ予測部２１ｃは、「予測リソース使用量」と同様に、「予測処理時間」も算出できるものとする。バッチ予測部２１ｃは、「バッチ集計データ」４１から「リソース使用量」と「処理時間」の最大値を算出することで、増加傾向を各予測値に反映することができる。予測した「リソース使用量」を超過する可能性は低いため、安全にバッチを起動したいケースでは、最大値を使用して「予測リソース使用量」と「予測処理時間」を算出することを推奨する。

しかし、上記の方法では、「リソース使用量」と「処理時間」が減少傾向にあった場合でも、過去に記録した「リソース使用量」と「処理時間」の最大値が常に採用されるため、「予測リソース使用量」と「予測処理時間」は減少することが無い。減少傾向を「予測リソース使用量」と「予測処理時間」に反映したい場合は、バッチ予測部２１ｃは、バッチ集計データ４１から「リソース使用量」と「処理時間」の平均値を算出することで、減少傾向を各予測値に反映することも可能である。本実施形態では増加傾向と減少傾向どちらにも対応できるものとする。

図１５は、本実施形態におけるバッチ起動判定部の動作を説明するための図である。本説明では「リソース使用量」の一例として、「ＣＰＵ使用率」について説明する。ここで、「予測ＣＰＵ使用率」は１コア換算で算出されるため、「リソース閾値」も１コア換算で設定されているものとする。バッチ起動判定部２１ｄでは「予測リソース使用量」として「予測ＣＰＵ使用率」のほかに、同様の手法で「予測メモリ使用量」と「予測ディスク使用帯域」も扱えるものとする。

図１５（Ａ）のバッチ起動判定のリソースグラフは、バッチＡの起動判定を行う際の予測値を含めたリソースグラフで、横軸が時間、縦軸が「ＣＰＵ使用率」（バッチ集計データ４１）を示している。グラフ中の実線は、バッチＡとバッチ処理以外のサーバ処理の「予測ＣＰＵ使用率」（バッチ予測データ４２）をそれぞれ示している。破線は、バッチＡとバッチ処理以外のサーバ処理の「予測ＣＰＵ使用率」の合計を示している。

図１５（Ｂ）の「バッチ予測データ４２のテーブルには、バッチＡの「予測ＣＰＵ使用率」と「予測処理時間」が格納されている。

図１５（Ｃ）の「サーバ予測データ４４のテーブルには、バッチ処理以外のサーバ処理の「予測ＣＰＵ使用率」が格納されている。本例では説明を簡略にするため、サーバの「予測ＣＰＵ使用率」は常に１０％としている。また、「ＣＰＵ使用率の閾値」 は１００％とする。

図１５（Ｄ）のバッチ起動スケジュール４３は、仮想サーバ１号機１６−１に割り振られている全てのバッチ処理の「起動時刻」などの各バッチ起動に必要な情報が記載されている。

図１６は、本実施形態におけるバッチ実行制御部の起動条件及び処理フローを示す。図１６（Ａ）に示すように、バッチ起動判定部２１ｄは、バッチ実行制御部２１ａから依頼を受ける、もしくは連携管理部２１ｅ，２１ｆ，２１ｇから情報を受信すると起動する。本例では、バッチ起動判定部２１ｄは、バッチ実行制御部２１ａから依頼を受けたものとする。

図１６（Ｂ）に示すように、バッチ起動判定部２１ｄは、「リソース閾値」が「予測リソース使用量」の合計より大きいか否かを判定する（Ｓ４１）。「リソース閾値」が「予測リソース使用量」の参照先は、起動条件によって次のように変化する。バッチ実行制御部２１ａから依頼された場合には、バッチ起動判定部２１ｄは、バッチ起動スケジュール４３と、バッチ予測データ４２とサーバ予測データ４４を参照する。連携管理部２１ｅ，２１ｆ，２１ｇから情報を受信した場合には、バッチ起動判定部２１ｄは、受信した情報とサーバ予測データ４４を参照する。

また、バッチ起動判定部２１ｄは、対象バッチ処理の「予測処理時間」の範囲すべてにおいて比較を行う。「予測リソース使用量」の合計は、対象バッチ処理、その他のバッチ処理、及びバッチ処理以外のサーバ処理の「予測リソース使用量」の合計となる。また、「予測ＣＰＵ使用率」は１コア換算で算出されるため、「リソース閾値」も１コア換算で設定されているものとする。

「リソース閾値」が「予測リソース使用量」の合計より大きい場合（Ｓ４１で「ＹＥＳ」）、バッチ起動判定部２１ｄは、バッチを起動する（Ｓ４２）。

「予測リソース使用量」の合計が「リソース閾値」以上の場合（Ｓ４１で「ＮＯ」）、バッチ起動判定部２１ｄは、連携管理部（スケールアウト）２１ｇから情報を受信したかを判定する（Ｓ４３）。連携管理部（スケールアウト）２１ｇから情報を受信した場合（Ｓ４３で「ＹＥＳ」）、バッチ起動判定部２１ｄは処理を完了する。連携管理部（スケールアウト）２１ｇから情報を受信していない場合（Ｓ４３で「ＮＯ」）、バッチ起動判定部２１ｄは、連携管理部２１ｅに処理を依頼する（Ｓ４４）。

本例の場合、バッチ起動判定部２１ｄは、バッチ起動スケジュール４３を参照して、バッチＡの「起動時刻」など起動に必要な情報を確認し、バッチＡの「予測処理時間」の範囲において、「ＣＰＵ使用率の閾値」と「予測ＣＰＵ使用率」の合計を比較する。図１５では、バッチ起動判定部２１ｄは、バッチＡの「起動時刻」2015/09/06 00:00:00と「予測処理時間」１時間から、「予測処理時間」の範囲は2015/09/06の00:00:00から2015/09/06の01:00:00とする。上記の「予測処理時間」の範囲において、バッチＡの 「予測ＣＰＵ使用率」90%と、バッチ処理以外のサーバ処理の「予測ＣＰＵ使用率」10%の和から、「予測ＣＰＵ使用率」の合計として100%が算出される。上記の「予測処理時間」の範囲における比較結果から、バッチ起動判定部２１ｄは、「予測ＣＰＵ使用率」が「ＣＰＵ使用率の閾値」に達する瞬間が存在するため、連携管理部２１ｅに処理を依頼し、バッチ起動判定部２１ｄは処理を完了する。

図１７は、本実施形態における連携管理部２１ｅの動作を説明するための図である。また、本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。連携管理部２１ｅでは「予測リソース使用量」として「予測ＣＰＵ使用率」のほかに、同様の手法で「予測メモリ使用量」と「予測ディスク使用帯域」も扱えるものとする。

図１７（Ａ）のバッチ予測データ４２のテーブルには、バッチＡの「予測ＣＰＵ使用率」と「予測処理時間」が格納されている。

図１７（Ｂ）の定義ファイル４７には、仮想サーバ１号機１６−１に割り振られているバッチＡ単体の「起動時刻」などのバッチＡの起動に必要な情報が記載されている。

図１８及び図１９は、本実施形態における連携管理部２１ｅの起動条件及び処理フローを示す。連携管理部２１ｅは、バッチＡが所属する仮想サーバ１号機１６−１のバッチ起動判定部２１ｄから依頼を受ける（図１８（Ａ））、もしくは他の仮想サーバのバッチ起動判定部２１ｄから情報を受信すると起動する（図１９（Ａ））。本例では、まず図１８（Ａ）のバッチ起動判定部２１ｄから依頼を受けたものとする。

この場合、図１８（Ａ）及び図１８（Ｂ）に示すように、起動条件１の処理フローが実施される。まず、連携管理部２１ｅは、バッチＡが所属する物理サーバ１号機１４−１のハイパーバイザ１５に、本セッション中にバッチＡの依頼を受けていない仮想サーバが存在するか問い合わせる（Ｓ５１）。

問い合わせ結果から、依頼を受けていない仮想サーバ２号機１６−２が存在したため（Ｓ５１で「ＹＥＳ」）、連携管理部２１ｅは、次の処理を行う。
すなわち、連携管理部２１ｅは、仮想サーバ２号機１６−２の連携管理部２１ｅにバッチＡの「予測リソース使用量」90%と「予測処理時間」１時間とバッチ起動に必要な情報を送信し（Ｓ５２）、仮想サーバ１号機１６−１における連携管理部２１ｅは処理を完了する。ここで、バッチ起動に必要な情報として、「バッチモジュール名」バッチＡ、「バッチモジュール格納場所」batch/batchA、「起動時刻」2015/09/06 00:00:00、「起動ユーザ」batch、「処理データ格納場所」/data/batchAが送信される。

問い合わせ結果から、依頼を受けていない仮想サーバ２号機１６−２が存在しない場合（Ｓ５１で「ＮＯ」）、連携管理部２１ｅは、次の処理を行う。すなわち、連携管理部２１ｅは、自分が所属する仮想サーバの連携管理部２１ｆに、バッチの「予測リソース使用量」、バッチの「予測処理時間」、バッチ起動に必要な情報を送信する（Ｓ５３）。バッチ起動に必要な情報とは、バッチモジュール名とバッチモジュール格納場所、起動時刻、起動ユーザ、処理データ格納場所等である。

次に、図１９（Ａ）及び図１９（Ｂ）に示すように、起動条件２の処理フローが実施される。

ここでは、連携管理部２１ｅは、バッチＡが所属する仮想サーバ２号機１６−２のバッチ起動判定部２１ｄにバッチＡの「予測リソース使用量」90%と「予測処理時間」１時間とバッチ起動に必要な情報を送信する（Ｓ６１）。仮想サーバ２号機１６−２における連携管理部２１ｅは処理を完了する。ここで、バッチ起動に必要な情報として、「バッチモジュール名」バッチＡ、「バッチモジュール格納場所」batch/batchA、「起動時刻」2015/09/06 00:00:00、「起動ユーザ」batch、「処理データ格納場所」/data/batchAが送信される。

なお、連携管理部２１ｅでは「予測リソース使用量」と「予測処理時間」とバッチ起動に必要な情報を扱う。これらの情報は、対象バッチ処理が本来所属していた仮想サーバから送信する場合は「バッチ稼働状況予測データ」や「バッチ起動情報定義ファイル」から参照する。本例ではバッチＡが本来所属していた仮想サーバは仮想サーバ１号機１６−１である。

また、同セッション中の、以降の連携管理部２１ｅの処理では、他の仮想サーバの連携管理部２１ｅから受信した情報を参照するものとする。

図２０は、本実施形態における連携管理部（スケールアップ）２１ｆの動作を説明するための図である。本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。連携管理部（スケールアップ）２１ｆでは「予測リソース使用量」として「予測ＣＰＵ使用率」のほかに、同様の手法で「予測メモリ使用量」と「予測ディスク使用帯域」も扱えるものとする。

図２０に示すように、連携管理部２１ｅから受信した情報は、バッチＡの「予測ＣＰＵ使用率」、「予測処理時間」とバッチ起動に必要な情報を含む。バッチ起動に必要な情報は、「バッチモジュール名」、「バッチモジュール格納場所」、「起動時刻」、「起動ユーザ」、「処理データ格納場所」を含む。

図２１は、本実施形態における連携管理部（スケールアップ）２１ｆの起動条件及び処理フローを示す。

図２１（Ａ）に示すように、連携管理部（スケールアップ）２１ｆは、連携管理部２１ｅから情報を受信すると起動する。本例では、物理サーバ１号機１４−１の仮想サーバ２号機１６−２において、連携管理部（スケールアップ）２１ｆは連携管理部２１ｅからバッチＡの情報を受信したものとする。

図２１（Ｂ）に示すように、連携管理部（スケールアップ）２１ｆは、まず、バッチＡが所属する物理サーバ１号機の仮想基盤管理１５に空きリソースが存在するかを、自分が所属する物理サーバの仮想基盤管理１５に問い合わせる（Ｓ７１）。

問い合わせ結果から空きリソースが存在した場合（Ｓ７１で「ＹＥＳ」）、連携管理部（スケールアップ）２１ｆは、バッチＡが所属する物理サーバ１号機の仮想基盤管理１５−１に、スケールアップによるリソース増強を依頼する（Ｓ７２）。

スケールアップ完了後、連携管理部（スケールアップ）２１ｆは、仮想サーバ2号機のバッチ起動判定部２１ｄにバッチＡの「予測ＣＰＵ使用率」90%と「予測処理時間」１時間とバッチ起動に必要な情報を送信する（Ｓ７３）。これにより、仮想サーバ2号機における連携管理部（スケールアップ）２１ｆは処理を完了する。ここで、バッチ起動に必要な情報として、「バッチモジュール名」バッチＡ、「バッチモジュール格納場所」batch/batchA、「起動時刻」2015/09/06 00:00:00、「起動ユーザ」batch、「処理データ格納場所」/data/batchAが送信される。

問い合わせ結果から、空きリソースが存在しない場合（Ｓ７１で「ＮＯ」）、連携管理部（スケールアップ）２１ｆは、次の処理を行う。すなわち、連携管理部（スケールアップ）２１ｆは、仮想サーバ２号機の連携管理部（スケールアウト）２１ｇに、バッチＡの「予測ＣＰＵ使用率」90%と「予測処理時間」１時間とバッチ起動に必要な情報を送信する。これにより、仮想サーバ２号機における連携管理部（スケールアップ）２１ｆは処理を完了する。ここで、バッチ起動に必要な情報として、「バッチモジュール名」バッチＡ、「バッチモジュール格納場所」batch/batchA、「起動時刻」2015/09/06 00:00:00、「起動ユーザ」batch、「処理データ格納場所」/data/batchAが送信される。

図２２は、本実施形態における連携管理部（スケールアウト）２１ｇの動作を説明するための図である。本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。連携管理部（スケールアウト）２１ｇでは「予測リソース使用量」として「予測ＣＰＵ使用率」のほかに、同様の手法で「予測メモリ使用量」と「予測ディスク使用帯域」も扱えるものとする。

図２２において、連携管理部（スケールアップ）２１ｆから受信した情報は、バッチＡの「予測ＣＰＵ使用率」、「予測処理時間」と、バッチ起動に必要な情報を含む。バッチ起動に必要な情報は、「バッチモジュール名」、「バッチモジュール格納場所」 、「起動時刻」、「起動ユーザ」、「処理データ格納場所」を含む。

図２３は、本実施形態における連携管理部（スケールアウト）２１ｇの起動条件及び処理フローを示す。

図２３（Ａ）に示すように、連携管理部（スケールアウト）２１ｇは連携管理部（スケールアップ）２１ｆから情報を受信すると起動する。本例では、物理サーバ１号機１４−１上の仮想サーバ２号機１６−２において、連携管理部（スケールアウト）２１ｇは連携管理部（スケールアップ）２１ｆからバッチAの情報を受信したものとする。

図２３（Ｂ）に示すように、連携管理部（スケールアウト）２１ｇは、全仮想化基盤管理部１２に空きリソースが存在する物理サーバが存在するか問い合わせる（Ｓ８１）。但し、連携管理部（スケールアウト）２１ｇ自身が所属する物理サーバは除かれる。この例では、バッチＡが所属している物理サーバ１号機１６−１は除かれる。

問い合わせ結果から空きリソースが存在する物理サーバ２号機が存在した場合（Ｓ８１で「ＹＥＳ」）、連携管理部（スケールアウト）２１ｇは、全仮想化基盤管理部１２にサーバ追加（スケールアウト）を依頼する（Ｓ８２）。本例では、連携管理部（スケールアウト）２１ｇは、全仮想化基盤管理部１２にスケールアウトを依頼し、物理サーバ２号機１６−２上に仮想サーバｍ号機１６−ｍを新設させる。

スケールアウト完了後、連携管理部（スケールアウト）２１ｇは、スケールアウトしたサーバのバッチ起動判定部２１ｄに、バッチの「予測リソース使用量」、バッチの「予測処理時間」、バッチ起動に必要な情報を送信する。本例では、連携管理部（スケールアウト）２１ｇは、仮想サーバｍ号機のバッチ起動判定部２１ｄに、バッチＡの「予測ＣＰＵ使用率」90%と「予測処理時間」１時間とバッチ起動に必要な情報を送信する。バッチ起動に必要な情報として、「バッチモジュール名」バッチＡ、「バッチモジュール格納場所」batch/batchA、「起動時刻」2015/09/06 00:00:00、「起動ユーザ」batch、「処理データ格納場所」/data/batchAが送信される。

そして、仮想サーバｍ号機のバッチ起動判定部２１ｄにおいて、バッチＡの起動を確認した場合（Ｓ８４で「ＹＥＳ」）、仮想サーバ２号機における連携管理部（スケールアウト）２１ｇは、処理を完了する。

バッチＡの起動が確認できない場合（Ｓ８４で「ＮＯ」）、仮想サーバ２号機における連携管理部（スケールアウト）２１ｇは、運用者にリソース不足を通知して（Ｓ８５）、処理を完了する。

問い合わせ結果から空きリソースが存在する物理サーバが存在しなかった場合（Ｓ８１で「ＮＯ」）、仮想サーバ２号機における連携管理部（スケールアウト）２１ｇは運用者にリソース不足を通知して（Ｓ８５）、処理を完了する。

図２４は、本実施形態におけるサーバ監視部２１ｈの動作を説明するための図である。本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。「ＣＰＵ使用率」は１コア換算で記録する。サーバ監視部２１ｈでは、「リソース使用量」として「ＣＰＵ使用率」のほかに、同様の手法で「メモリ使用量」と「ディスク使用帯域」量も扱えるものとする。

図２４（Ａ）に示すように、サーバ稼働状況監視のリソースグラフは、バッチ処理以外のサーバ処理が稼働中のリソースグラフであり、横軸が時間、縦軸がＣＰＵ使用率を示している。また、当該リソースグラフは現時点での仮想サーバ上の全ての処理の「ＣＰＵ使用率」と、仮想サーバ上の全てのバッチ処理の「ＣＰＵ使用率」を示している。

図２４（Ｂ）の「サーバ集計データ４５のテーブルには、仮想サーバ上の全ての処理の「ＣＰＵ使用率」と、仮想サーバ上の全てのバッチ処理の「ＣＰＵ使用率」と、バッチ処理以外のサーバ処理「ＣＰＵ使用率」が格納される。

図２５は、本実施形態におけるサーバ監視部２１ｈの起動条件及び処理フローを示す。図２５（Ａ）に示すように、サーバ監視部２１ｈは、仮想サーバの起動と同時に起動する。本例では、サーバ監視部２１ｈは、仮想サーバ１号機が起動すると同時に起動する。

図２５（Ｂ）に示すように、サーバ監視部２１ｈは、仮想サーバ上の全ての処理の「リソース使用量」（「ＣＰＵ使用率」,「メモリ使用量」、「ディスク使用帯域」）を監視する（Ｓ９１）。なお、「ＣＰＵ使用率」は１コア換算で記録する。

サーバ監視部２１ｈは、仮想サーバ上の全てのバッチ処理の「リソース使用量」（「ＣＰＵ使用率」、「メモリ使用量」、「ディスク使用帯域」）を監視する（Ｓ９２）。

サーバ監視部２１ｈは、仮想サーバ上の全ての処理の「リソース使用量」から仮想サーバ上の全てのバッチ処理の「リソース使用量」を減算した値をバッチ処理以外のサーバ処理の「リソース使用量」として、サーバ集計データ４５に記録する（Ｓ９３）。

時間2015/09/05 00:00:00を例に説明すると、サーバ監視部２１ｈは、バッチＡの仮想サーバ上の全ての処理の「ＣＰＵ使用率」70%と、仮想サーバ上の全てのバッチ処理の「ＣＰＵ使用率」60%を測定する。

サーバ監視部２１ｈは、仮想サーバ上の全ての処理の「ＣＰＵ使用率」70%から仮想サーバ上の全てのバッチ処理の「ＣＰＵ使用率」60%を減算した値をバッチ処理以外のサーバ処理「ＣＰＵ使用率」10%として記録する。サーバ監視部２１ｈは、以降も同様に測定と記録を続ける。

図２６は、本実施形態におけるサーバ予測部２１ｉの動作を説明するための図である。本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。「ＣＰＵ使用率」は１コア換算で記録する。サーバ予測部２１ｉでは「リソース使用量」として、「ＣＰＵ使用率」のほかに、同様の手法で「メモリ使用量」と「ディスク使用帯域」も扱えるものとする。

図２６（Ａ）のサーバ集計データ４５のテーブルには、バッチ処理以外のサーバ処理が記録した「ＣＰＵ使用率」が格納されている。図２６（Ｂ）のサーバ予測データ４４のテーブルには、バッチ処理以外のサーバ処理が予測して算出した「予測ＣＰＵ使用率」が格納されている。

図２７は、本実施形態におけるサーバ予測部２１ｉの起動条件及び処理フローを示す。図２７（Ａ）に示すように、サーバ予測部２１ｉは、仮想サーバ１号機が起動すると同時に起動する。

図２７（Ｂ）に示すように、サーバ予測部２１ｉは、過去の各「リソース使用量」（サーバ集計データ４５）から、各「「リソース使用量」の傾向」を算出する（１０１）。ここでは、サーバ予測部２１ｉは、近似曲線を適用し、傾向を算出する。

サーバ予測部２１ｉは、傾向から次回の「予測リソース使用量」を算出し、サーバ予測データ４４に記録する（Ｓ１０２）。

本例では、サーバ予測部２１ｉは、過去のバッチ処理以外のサーバ処理で記録した「ＣＰＵ使用率」から、近似曲線を適用し、「ＣＰＵ使用率」の傾向を算出する。サーバ予測部２１ｉは、傾向から次回の「予測ＣＰＵ使用率」を算出し、「サーバ稼働状況予測データ」に記録し続ける。記録した後、サーバ予測部２１ｉは処理を完了する。

図２８は、上述の状況１について、本実施形態の適用後のリソースグラフを示す。図１（Ｂ）と比べて、本実施形態の適用後では、バッチＡにおける日々の増加傾向を考慮し、バッチＢ起動前にスケールアウトによってリソースを増強後、バッチＢを起動した場合を示している。以下、動作概要と効果を説明する。本説明では仮想サーバの「リソース閾値」を１００％と事前に定義したものとする。

以下の処理を上述したようにＳ１から順に実施する。
Ｓ１において、バッチ起動判定部２１ｄは、バッチＢの「起動時刻」が到来した際、バッチＢの「予測処理時間」において、バッチＢと、バッチＡと、バッチ処理以外のサーバ処理の「予測リソース使用量」の合計が「リソース閾値」内で収まるか否かを判定する。「予測リソース使用量」の合計が「リソース閾値」内で収まらないと判断されると、Ｓ２の処理が実施される。

Ｓ２において、仮想基盤連携部３３にて、同じ物理サーバ内からリソースに余裕のある仮想サーバを検索したが、存在しなかったため、Ｓ３の処理が実施される。

Ｓ３において、仮想基盤連携部３３にて、同じ物理サーバ内から空きリソースが検索されたが、存在しなかったため、Ｓ４の処理が実施される。

Ｓ４において、他の物理サーバ内から空きリソースを検索し、空きリソースが存在したので、連携管理部２１ｇは、全仮想化基盤管理１２と連携して仮想サーバｍ号機１６−ｍをスケールアウトによって他の物理サーバ上に新設する。そして、バッチＢを起動させる仮想サーバを仮想サーバ１号機から仮想サーバｍ号機に切り替え、バッチ起動判定部２１ｄは、Ｓ１の処理を実施し、バッチＢを起動させる。

同一仮想サーバ上でバッチＢ稼働中にバッチＡも稼動する状況が発生しないので、「リソース使用量」が仮想サーバの許容量である１００％を超過して仮想サーバの全体のパフォーマンスが低下することを回避できる。上記の結果、予定終了時刻にバッチ処理が終了しないといった課題を解決できる。

図２９は、上述の状況２について、本実施形態の適用後のリソースグラフを示す。図２（Ｂ）と比べて、本実施形態の適用後では、バッチ処理以外のサーバ処理における日々の増加傾向を考慮し、バッチＡ、バッチＢ、バッチＣの起動前にスケールアップによってリソースを増強後、バッチＡ、バッチＢ、バッチＣを稼動した場合を示している。以下、動作概要と効果を説明する。本説明では仮想サーバの「リソース閾値」を１００％と事前に定義したものとする。

以下の処理をＳ１から順に実施する。
Ｓ１において、バッチ起動判定部２１ｄは、バッチＡの「起動時刻」が到来した際、バッチＡの「予測処理時間」において、バッチＡと、バッチ処理以外のサーバ処理の「予測リソース使用量」の合計が「リソース閾値」内で収まるか否かを判定する。「予測リソース使用量」の合計が「リソース閾値」 内で収まらないと判断されると、Ｓ２の処理が実施される。

Ｓ２において、仮想基盤連携部３３にて、同じ物理サーバ内からリソースに余裕のある仮想サーバが検索されたが、存在しなかったため、Ｓ３の処理が実施される。

Ｓ３において、同じ物理サーバ内から空きリソースを検索し、空きリソースが存在したため、連携管理部２１ｆは、次の処理を行う。すなわち、連携管理部２１ｆは、全仮想化基盤管理１２と連携し、バッチＡを起動させる仮想サーバをスケールアップによってリソース増強したのち、Ｓ１の処理を実施しバッチＡを起動させる。

なお、必要に応じてバッチＢとバッチＣでも同じ処理を行う。
バッチ処理以外のサーバ処理の増加量に対応できる、十分なリソースをスケールアップによって確保したので、バッチＡ、バッチＢ、バッチＣが稼働するたびに「リソース使用量」が仮想サーバの許容量である１００％を超過してサーバの全体のパフォーマンスが低下することを回避できる。上記の結果、予定終了時刻にバッチ処理が終了しないといった課題を解決できる。

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

１ バッチ制御システム
２ 監視部
３ 予測部
４ 制御部
５ 切替部
６ スケールアップ調整部
７ スケールアウト調整部
１１ サーバシステム
１２ 全仮想化基盤管理
１３ ネットワーク
１４ 物理サーバ
１５ 仮想化基盤管理（ハイパーバイザ）
１６ 仮想サーバ
１７ 空きリソース
２１ 主記憶装置
２２ 二次記憶装置
２３ ネットワークインタフェース
２４ ＣＰＵ
３１ バッチ管理部
３２ サーバリソース管理部
３３ 仮想基盤連携部
２１ａ バッチ実行制御部
２１ｂ バッチ監視部
２１ｃ バッチ予測部
２１ｄ バッチ起動判定部
２１ｅ 連携管理部
２１ｆ 連携管理部（スケールアップ）
２１ｇ 連携管理部（スケールアウト）
２１ｈ サーバ監視部
２１ｉ サーバ予測部

Claims (8)

1. 第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する監視部と、
   前記最大リソース使用量と前記最大処理時間の傾向から、前記第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する予測部と、
   予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する制御部と、
   を備えることを特徴とするバッチ制御システム。
2. 前記監視部は、さらに前記第１バッチ処理以外の前記第１仮想計算機による非バッチ処理でのリソース使用量を監視し、
   前記予測部は、前記非バッチ処理でのリソース使用量の傾向から、前記第２バッチ処理時における前記非バッチ処理でのリソース使用量を予測し、
   前記制御部は、前記第２バッチ処理の起動時刻が到来した際に、前記予測された処理時間において前記第１仮想計算機にて実行される、該第２バッチ処理と、該第２バッチ処理以外の他のバッチ処理と、前記非バッチ処理とのそれぞれで用いるリソース使用量の合計が閾値より小さい場合、該第２バッチ処理を起動させる
   ことを特徴とする請求項１に記載のバッチ制御システム。
3. 前記バッチ制御システムは、さらに、
   前記リソース使用量の合計が閾値以上である場合、前記第１仮想計算機を含む第１物理計算機内からリソースに余裕のある第２仮想計算機を検索し、該第２仮想計算機が存在する場合、前記第２バッチ処理を起動させる仮想計算機を該第１仮想計算機から該第２仮想計算機に切り替える切替部
   を備えることを特徴とする請求項２に記載のバッチ制御システム。
4. 前記バッチ制御システムは、さらに、
   前記第２仮想計算機が存在しない場合、前記第１物理計算機内から空きリソースを検索し、該第１物理計算機に空きリソースが存在する場合、前記第２バッチ処理を起動させる前記第１仮想計算機に該空きリソースを融通するスケールアップ調整部と、
   を備えることを特徴とする請求項３に記載のバッチ制御システム。
5. 前記バッチ制御システムは、さらに、
   前記第１物理計算機に空きリソースが存在しない場合、他の物理計算機内から空きリソースを検索し、該他の物理計算機のいずれかである第２物理計算機に該空きリソースが存在する場合、該第２物理計算機上に前記第２バッチ処理を起動させる第３仮想計算機を追加し、前記第２バッチ処理を起動させる仮想サーバを前記第１仮想計算機から該第３仮想計算機に切り替えるスケールアウト調整部と、
   を備えることを特徴とする請求項４に記載のバッチ制御システム。
6. 前記スケールアウト調整部は、前記他の物理計算機のいずれにも空きリソースが存在しない場合、または、前記第２バッチ処理を起動させる仮想サーバを前記第１仮想計算機から該第３仮想計算機に切り替えた後に該第２バッチが起動しない場合、異常である旨を通知する
   ことを特徴とする請求項５に記載のバッチ制御システム。
7. コンピュータに、
   第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得し、
   前記最大リソース使用量と前記最大処理時間の傾向から、第２バッチ処理の実行の際のリソース使用量と処理時間とを予測し、
   予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する
   処理を実行させるバッチ制御プログラム。
8. コンピュータに、
   第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得し、
   前記最大リソース使用量と前記最大処理時間の傾向から、第２バッチ処理の実行の際のリソース使用量と処理時間とを予測し、
   予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する
   処理を実行させるバッチ制御方法。