(57)【要約】【課題】仮想計算機のリソースの確保に応じて、バッチ処理を実行する技術を提供する。【解決手段】第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する監視部と、最大リソース使用量と最大処理時間との傾向から、第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する予測部と、予測されたリソース使用量と予測された処理時間とに応じて、第２バッチ処理の実行を制御する制御部と、を備えるバッチ制御システムにより、上記課題の解決を図る。【選択図】図３
2017129988.tif 000002
【特許請求の範囲】
【請求項１】
第１仮想計算機による第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得する監視部と、
前記最大リソース使用量と前記最大処理時間の傾向から、前記第１仮想計算機による第２バッチ処理の実行の際のリソース使用量と処理時間とを予測する予測部と、
予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する制御部と、
を備えることを特徴とするバッチ制御システム。
【請求項２】
前記監視部は、さらに前記第１バッチ処理以外の前記第１仮想計算機による非バッチ処理でのリソース使用量を監視し、
前記予測部は、前記非バッチ処理でのリソース使用量の傾向から、前記第２バッチ処理時における前記非バッチ処理でのリソース使用量を予測し、
前記制御部は、前記第２バッチ処理の起動時刻が到来した際に、前記予測された処理時間において前記第１仮想計算機にて実行される、該第２バッチ処理と、該第２バッチ処理以外の他のバッチ処理と、前記非バッチ処理とのそれぞれで用いるリソース使用量の合計が閾値より小さい場合、該第２バッチ処理を起動させる
ことを特徴とする請求項１に記載のバッチ制御システム。
【請求項３】
前記バッチ制御システムは、さらに、
前記リソース使用量の合計が閾値以上である場合、前記第１仮想計算機を含む第１物理計算機内からリソースに余裕のある第２仮想計算機を検索し、該第２仮想計算機が存在する場合、前記第２バッチ処理を起動させる仮想計算機を該第１仮想計算機から該第２仮想計算機に切り替える切替部
を備えることを特徴とする請求項２に記載のバッチ制御システム。
【請求項４】
前記バッチ制御システムは、さらに、
前記第２仮想計算機が存在しない場合、前記第１物理計算機内から空きリソースを検索し、該第１物理計算機に空きリソースが存在する場合、前記第２バッチ処理を起動させる前記第１仮想計算機に該空きリソースを融通するスケールアップ調整部と、
を備えることを特徴とする請求項３に記載のバッチ制御システム。
【請求項５】
前記バッチ制御システムは、さらに、
前記第１物理計算機に空きリソースが存在しない場合、他の物理計算機内から空きリソースを検索し、該他の物理計算機のいずれかである第２物理計算機に該空きリソースが存在する場合、該第２物理計算機上に前記第２バッチ処理を起動させる第３仮想計算機を追加し、前記第２バッチ処理を起動させる仮想サーバを前記第１仮想計算機から該第３仮想計算機に切り替えるスケールアウト調整部と、
を備えることを特徴とする請求項４に記載のバッチ制御システム。
【請求項６】
前記スケールアウト調整部は、前記他の物理計算機のいずれにも空きリソースが存在しない場合、または、前記第２バッチ処理を起動させる仮想サーバを前記第１仮想計算機から該第３仮想計算機に切り替えた後に該第２バッチが起動しない場合、異常である旨を通知する
ことを特徴とする請求項５に記載のバッチ制御システム。
【請求項７】
コンピュータに、
第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得し、
前記最大リソース使用量と前記最大処理時間の傾向から、第２バッチ処理の実行の際のリソース使用量と処理時間とを予測し、
予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する
処理を実行させるバッチ制御プログラム。
【請求項８】
コンピュータに、
第１バッチ処理の実行の際のリソース使用量と処理時間を監視して、最大リソース使用量と最大処理時間を取得し、
前記最大リソース使用量と前記最大処理時間の傾向から、第２バッチ処理の実行の際のリソース使用量と処理時間とを予測し、
予測された前記リソース使用量と予測された前記処理時間とに応じて、前記第２バッチ処理の実行を制御する
処理を実行させるバッチ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、バッチ制御システム、バッチ制御プログラム、及びバッチ制御方法に関する。
【背景技術】
【０００２】
近年、仮想化技術を活用したシステム構築の普及に伴い、オンデマンドで仮想サーバを追加し、システムの処理能力を増強することができる。
【０００３】
システム処理はオンライン処理とバッチ処理に大別される。オンライン処理は即座に処理を稼動・完了して結果を送り返す方式を指す。それに対して、バッチ処理は蓄積された複数件のデータを、定期的に一括処理する方式であり、オンライン処理とは異なり、ユーザとの対話なく処理が進められる。
【０００４】
バッチ処理はスケジュールに基づき、同一サーバ上で複数のバッチ処理を順次稼動する方法が主流である。しかしシステムを運用していくうちに、以下のような状況が発生することが予想される。
【０００５】
（状況１）バッチ処理量が日々増加すると、予定時間内にバッチ処理が完了せず、終了時間が延長される。この状態のまま次のバッチ処理開始時刻が到来すると、複数のバッチ処理を並行して稼動する状況が発生し、「リソース使用量」がサーバの許容量を超過する。
【０００６】
（状況２）また、オンライン処理等のバッチ処理以外のサーバ処理が日々増加すると、もともと並行稼動が予定されていたバッチ処理が稼動する度に、「リソース使用量」がサーバの許容量を超過する。
【０００７】
上記のような「リソース使用量」がサーバの許容量を超過する状態では、バッチ処理稼働中に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%として記録する。サーバ監視部２１ｈは、以降も同様に測定と記録を続ける。
【０１５８】
図２６は、本実施形態におけるサーバ予測部２１ｉの動作を説明するための図である。本説明では「リソース使用量」を「ＣＰＵ使用率」を例にして説明する。「ＣＰＵ使用率」は１コア換算で記録する。サーバ予測部２１ｉでは「リソース使用量」として、「ＣＰＵ使用率」のほかに、同様の手法で「メモリ使用量」と「ディスク使用帯域」も扱えるものとする。
【０１５９】
図２６（Ａ）のサーバ集計データ４５のテーブルには、バッチ処理以外のサーバ処理が記録した「ＣＰＵ使用率」が格納されている。図２６（Ｂ）のサーバ予測データ４４のテーブルには、バッチ処理以外のサーバ処理が予測して算出した「予測ＣＰＵ使用率」が格納されている。
【０１６０】
図２７は、本実施形態におけるサーバ予測部２１ｉの起動条件及び処理フローを示す。図２７（Ａ）に示すように、サーバ予測部２１ｉは、仮想サーバ１号機が起動すると同時に起動する。
【０１６１】
図２７（Ｂ）に示すように、サーバ予測部２１ｉは、過去の各「リソース使用量」（サーバ集計データ４５）から、各「「リソース使用量」の傾向」を算出する（１０１）。ここでは、サーバ予測部２１ｉは、近似曲線を適用し、傾向を算出する。
【０１６２】
サーバ予測部２１ｉは、傾向から次回の「予測リソース使用量」を算出し、サーバ予測データ４４に記録する（Ｓ１０２）。
【０１６３】
本例では、サーバ予測部２１ｉは、過去のバッチ処理以外のサーバ処理で記録した「ＣＰＵ使用率」から、近似曲線を適用し、「ＣＰＵ使用率」の傾向を算出する。サーバ予測部２１ｉは、傾向から次回の「予測ＣＰＵ使用率」を算出し、「サーバ稼働状況予測データ」に記録し続ける。記録した後、サーバ予測部２１ｉは処理を完了する。
【０１６４】
図２８は、上述の状況１について、本実施形態の適用後のリソースグラフを示す。図１（Ｂ）と比べて、本実施形態の適用後では、バッチＡにおける日々の増加傾向を考慮し、バッチＢ起動前にスケールアウトによってリソースを増強後、バッチＢを起動した場合を示している。以下、動作概要と効果を説明する。本説明では仮想サーバの「リソース閾値」を１００％と事前に定義したものとする。
【０１６５】
以下の処理を上述したようにＳ１から順に実施する。
Ｓ１において、バッチ起動判定部２１ｄは、バッチＢの「起動時刻」が到来した際、バッチＢの「予測処理時間」において、バッチＢと、バッチＡと、バッチ処理以外のサーバ処理の「予測リソース使用量」の合計が「リソース閾値」内で収まるか否かを判定する。「予測リソース使用量」の合計が「リソース閾値」内で収まらないと判断されると、Ｓ２の処理が実施される。
【０１６６】
Ｓ２において、仮想基盤連携部３３にて、同じ物理サーバ内からリソースに余裕のある仮想サーバを検索したが、存在しなかったため、Ｓ３の処理が実施される。
【０１６７】
Ｓ３において、仮想基盤連携部３３にて、同じ物理サーバ内から空きリソースが検索されたが、存在しなかったため、Ｓ４の処理が実施される。
【０１６８】
Ｓ４において、他の物理サーバ内から空きリソースを検索し、空きリソースが存在したので、連携管理部２１ｇは、全仮想化基盤管理１２と連携して仮想サーバｍ号機１６−ｍをスケールアウトによって他の物理サーバ上に新設する。そして、バッチＢを起動させる仮想サーバを仮想サーバ１号機から仮想サーバｍ号機に切り替え、バッチ起動判定部２１ｄは、Ｓ１の処理を実施し、バッチＢを起動させる。
【０１６９】
同一仮想サーバ上でバッチＢ稼働中にバッチＡも稼動する状況が発生しないので、「リソース使用量」が仮想サーバの許容量である１００％を超過して仮想サーバの全体のパフォーマンスが低下することを回避できる。上記の結果、予定終了時刻にバッチ処理が終了しないといった課題を解決できる。
【０１７０】
図２９は、上述の状況２について、本実施形態の適用後のリソースグラフを示す。図２（Ｂ）と比べて、本実施形態の適用後では、バッチ処理以外のサーバ処理における日々の増加傾向を考慮し、バッチＡ、バッチＢ、バッチＣの起動前にスケールアップによってリソースを増強後、バッチＡ、バッチＢ、バッチＣを稼動した場合を示している。以下、動作概要と効果を説明する。本説明では仮想サーバの「リソース閾値」を１００％と事前に定義したものとする。
【０１７１】
以下の処理をＳ１から順に実施する。
Ｓ１において、バッチ起動判定部２１ｄは、バッチＡの「起動時刻」が到来した際、バッチＡの「予測処理時間」において、バッチＡと、バッチ処理以外のサーバ処理の「予測リソース使用量」の合計が「リソース閾値」内で収まるか否かを判定する。「予測リソース使用量」の合計が「リソース閾値」 内で収まらないと判断されると、Ｓ２の処理が実施される。
【０１７２】
Ｓ２において、仮想基盤連携部３３にて、同じ物理サーバ内からリソースに余裕のある仮想サーバが検索されたが、存在しなかったため、Ｓ３の処理が実施される。
【０１７３】
Ｓ３において、同じ物理サーバ内から空きリソースを検索し、空きリソースが存在したため、連携管理部２１ｆは、次の処理を行う。すなわち、連携管理部２１ｆは、全仮想化基盤管理１２と連携し、バッチＡを起動させる仮想サーバをスケールアップによってリソース増強したのち、Ｓ１の処理を実施しバッチＡを起動させる。
【０１７４】
なお、必要に応じてバッチＢとバッチＣでも同じ処理を行う。
バッチ処理以外のサーバ処理の増加量に対応できる、十分なリソースをスケールアップによって確保したので、バッチＡ、バッチＢ、バッチＣが稼働するたびに「リソース使用量」が仮想サーバの許容量である１００％を超過してサーバの全体のパフォーマンスが低下することを回避できる。上記の結果、予定終了時刻にバッチ処理が終了しないといった課題を解決できる。
【０１７５】
なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【符号の説明】
【０１７６】
１      バッチ制御システム
２      監視部
３      予測部
４      制御部
５      切替部
６      スケールアップ調整部
７      スケールアウト調整部
１１    サーバシステム
１２    全仮想化基盤管理
１３    ネットワーク
１４    物理サーバ
１５    仮想化基盤管理（ハイパーバイザ）
１６    仮想サーバ
１７    空きリソース
２１    主記憶装置
２２    二次記憶装置
２３    ネットワークインタフェース
２４    ＣＰＵ
３１    バッチ管理部
３２    サーバリソース管理部
３３    仮想基盤連携部
２１ａ  バッチ実行制御部
２１ｂ  バッチ監視部
２１ｃ  バッチ予測部
２１ｄ  バッチ起動判定部
２１ｅ  連携管理部
２１ｆ  連携管理部（スケールアップ）
２１ｇ  連携管理部（スケールアウト）
２１ｈ  サーバ監視部
２１ｉ  サーバ予測部
【図１】
2017129988.tif 000003
【図２】
2017129988.tif 000004
【図３】
2017129988.tif 000005
【図４】
2017129988.tif 000006
【図５】
2017129988.tif 000007
【図６】
2017129988.tif 000008
【図７】
2017129988.tif 000009
【図８】
2017129988.tif 000010
【図９】
2017129988.tif 000011
【図１０】
2017129988.tif 000012
【図１１】
2017129988.tif 000013
【図１２】
2017129988.tif 000014
【図１３】
2017129988.tif 000015
【図１４】
2017129988.tif 000016
【図１５】
2017129988.tif 000017
【図１６】
2017129988.tif 000018
【図１７】
2017129988.tif 000019
【図１８】
2017129988.tif 000020
【図１９】
2017129988.tif 000021
【図２０】
2017129988.tif 000022
【図２１】
2017129988.tif 000023
【図２２】
2017129988.tif 000024
【図２３】
2017129988.tif 000025
【図２４】
2017129988.tif 000026
【図２５】
2017129988.tif 000027
【図２６】
2017129988.tif 000028
【図２７】
2017129988.tif 000029
【図２８】
2017129988.tif 000030
【図２９】
2017129988.tif 000031