(57)【要約】  個々のバッチジョブの要求処理時間を遵守する。  バッチアプリケーションの配置に必要なリソースの計算を行なうリソース補正制御サーバ（１）であって、所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群を中間処理単位とする中間処理単位データ取得処理部（１０２）と、前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部（１０３）と、前記判定の結果、前記必要な進捗率に達していない場合、遅延回復対象進捗率と、リソースの情報と、を基に、遅延回復に必要なリソースを算出する割当てリソース算出処理部（１０４）と、を有することを特徴とする。
2011142031.tif 000002
【特許請求の範囲】
【請求項１】
バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置におけるリソース管理方法であって、
前記リソース管理装置は、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめ、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定し、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出する
ことを特徴とするリソース管理方法。
【請求項２】
前記所定の時刻は、実行されているアプリケーションの処理開始時刻および処理終了時刻である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項３】
前記再検査の契機は、定期的な時刻である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項４】
前記処理進捗率は、現在までに行なっている処理件数を、全処理対象件数で除算したものである
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項５】
前記必要処理件数は、現在までの処理時間を、前記要求処理時間で除算したものである
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項６】
前記リソースとは、ＣＰＵのコア数、メモリ割当て数またはディスク割当て数である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項７】
前記リソース管理装置は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項８】
前記リソース管理装置は、
前記リソース量を算出する際に、前記バッチアプリケーションの割当てに必要な時間を考慮する
ことを特徴とする請求の範囲第７項に記載のリソース管理方法。
【請求項９】
前記リソース管理装置は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
【請求項１０】
前記リソース管理装置は、
前記リソース量を算出する際に、前記バッチアプリケーションの割当てに必要な時間と、前記バッチアプリケーションを切り離すために必要な時間と、を考慮する
ことを特徴とする請求の範囲第９項に記載のリソース管理方法。
【請求項１１】
バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置であって、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめる中間処理単位データ取得処理部と、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部と、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するため必要なリソースを算出する割当てリソース算出処理部と、
を有することを特徴とするリソース管理装置。
【請求項１２】
前記割当てリソース算出処理部は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１１項に記載のリソース管理装置。
【請求項１３】
前記割当てリソース算出処理部は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１１項に記載のリソース管理装置。
【請求項１４】
バッチアプリケーションの配置に必要なリソースの計算を行なうためにコンピュータを、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめる中間処理単位データ取得処理部、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するため必要なリソースを算出する割当てリソース算出処理部
として機能させることを特徴とするプログラム。
【請求項１５】
前記割当てリソース算出処理部は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１４項に記載のプログラム。
【請求項１６】
前記割当てリソース算出処理部は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１４項に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース管理方法、リソース管理装置およびプログラムの技術に関する。
【背景技術】
【０００２】
近年、インターネット技術や仮想化技術の進展に伴い、企業や個人などのユーザに対して、インターネット経由でコンピュータリソースやアプリケーションサービスを提供し、使用したリソース量やサービスに応じて課金を行なうクラウドコンピューティングの利用が広まりつつある。従来のコンピュータ利用は、ユーザがコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは、設備に対する投資や調達にかかる時間を削減することが可能になるため、企業の間での利用事例も出始めつつある。【０００３】
企業内の利用ケースの一つとして、企業における売上データや受注データの集計処理など、一定期間ごとに大量のデータを集めて一括処理するバッチ処理がある。バッチ処理には、要求処理時間（ＳＬＡ：Service Level Agreement）が存在するのが一般的である。バッチ処理は、処理するデータや処理内容によって、一定期間の間に集中的にコンピュータリソースを使用するという特徴があるため、使用したリソース量に応じて課金するクラウドコンピューティングの利用形態に対する適合性が高いと考えられている。そのため、データに対するセキュリティ確保などの懸案は残るものの、今後、ユーザによる利用は広がっていくものと予想されている。【０００４】
一方で、クラウドコンピューティングのサービスを提供する事業者側は、複数のユーザ企業からのサービス要求に対して、有限のコンピュータリソースで応えていく必要がある。複数のユーザ企業からのバッチ処理を受け持つクラウドサービスを考えた場合、有限のコンピュータリソースをいかに有効活用して、ユーザ企業毎の個別の要求処理時間を遵守するかということが重要なポイントになる。【０００５】
このような状況下において、バッチ処理の要求処理時間の遵守を実現するための技術として、予め割当てたコンピュータリソース上で部分的なバッチ処理を所定時間行ない、その結果から進捗率を計算して、要求処理時間を遵守できないと推定した場合、コンピュータリソースを追加することで要求処理時間を遵守するジョブ実行方法、ジョブ実行システムおよびジョブ実行プログラムが開示されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−１２３２０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に記載の技術を用いることにより、予め割当てたコンピュータリソースでは、要求処理時間を遵守できないと推定した場合、要求処理時間を遵守できるまでコンピュータリソースを追加することで、要求処理時間を遵守することができるようになる。しかしながら、有限のコンピュータリソースの有効活用という観点では、必ずしも十分とは言えない場合がある。例えば、特許文献１に記載の技術では、該当バッチアプリケーションにコンピュータリソースを追加した後、リソース割当ては固定になる。このため、複数のバッチアプリケーションが共存して稼働することを想定した場合、該当するバッチアプリケーションの実行中に、別のバッチアプリケーションの開始や終了などによるリソース使用状況の変化、あるいは、別のバッチアプリケーションの処理遅延などを含めた、動的なコンピュータリソースの割当てを行なうことは困難である。【０００８】
また、バッチ処理の進捗率を計算して、コンピュータリソースの追加の再計算を行なうこと自体の処理にコストがかかるため、頻繁に行なうと、バッチ処理のスループットに影響を及ぼす可能性がある。【０００９】
従って、コンピュータリソースの有効活用と個別のバッチアプリケーションの要求終了時間遵守の両立を目的としたバッチアプリケーションシステムにおいては、複数のバッチアプリケーションが共存して稼働する環境下において、該当バッチアプリケーションの実行中に、コンピュータリソースの使用状況の変動や別のバッチアプリケーションの処理遅延が発生した場合であっても、コンピュータリソースを有効活用しつつ、個々のバッチアプリケーションの要求処理時間を遵守できるようにする必要がある。要求処理時間を遵守するためには、実行中のバッチアプリケーションの中間処理履歴を利用して算出した進捗率からバッチアプリケーションに割り当てたリソースを見直すことが考えられるが、リソース割当ての見直しを頻繁に行なうことによってスループット低下を招く可能性がある。従って、スループット低下を防ぎながら、個々のバッチジョブの要求処理時間を遵守するためには、必要最小限の再検査の契機の取得と、その契機を境にした中間処理履歴を取得するためのデータ分割の実現が課題となる。【００１０】
このような背景に鑑みて本発明がなされたのであり、本発明は、個々のバッチジョブの要求処理時間を遵守するリソース管理方法、リソース管理装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するため、本発明は、バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置におけるリソース管理方法であって、前記リソース管理装置は、所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめ、前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定し、前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出することを特徴とする。
その他の解決手段については、実施形態中において記載する。
【発明の効果】
【００１２】
本発明によれば、個々のバッチジョブの要求処理時間を遵守するリソース管理方法、リソース管理装置およびプログラムを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に係る計算機システムの構成例を示す図である。
【図２】本実施形態に係る実行仮想サーバの構成例を示す機能ブロック図である。
【図３】本実施形態に係るクライアント端末の構成例を示す機能ブロック図である。
【図４】本実施形態に係るリソース管理サーバの構成例を示す機能ブロック図である。
【図５】本実施形態に係る配備制御サーバの構成例を示す機能ブロック図である。
【図６】本実施形態に係るリソース補正制御サーバの構成例を示す機能ブロック図である。
【図７】本実施形態に係るバッチアプリケーション実行方法に関する全体処理の手順を示すフローチャートである。
【図８】図７のステップＳ１０２の処理のうち、リソース情報取得およびリソース割当てに関する部分の詳細な手順を示すフローチャートである。
【図９】本実施形態に係るリソース情報管理テーブルの例を示す図である。
【図１０】図８のステップＳ２０３の処理の詳細な手順を示すフローチャートである。
【図１１】本実施形態に係るＳＬＡ情報管理テーブルの例を示す図である。
【図１２】本実施形態に係る処理対象データ管理テーブルの例を示す図である。
【図１３】図７のステップＳ１０２の処理のうち、バッチアプリケーション情報収集に関する部分の詳細な手順を示すフローチャートである。
【図１４】本実施形態に係る配備アプリケーション管理テーブルの例を示す図である。
【図１５】図７のステップＳ１０３の処理の詳細な手順を示すフローチャートである。
【図１６】本実施形態に係るバッチアプリケーション毎ロット単位処理履歴管理テーブルの例を示す図である（バッチＡＰ１）。
【図１７】本実施形態に係るバッチアプリケーション毎ロット単位処理履歴管理テーブルの例を示す図である（バッチＡＰ２）。
【図１８】本実施形態に係るロット単位処理履歴管理テーブルの例を示す図である。
【図１９】本実施形態に係るバッチ単位処理履歴管理テーブルの例を示す図である。
【図２０】本実施形態に係るリソース補正のための再検査の契機に関する概念図である。
【図２１】ステップＳ１０４の処理の詳細な手順のうち、再検査の契機取得に関する部分を示すフローチャートである。
【図２２】再検査に必要な中間処理単位データ取得の概念図である（その１）。
【図２３】再検査に必要な中間処理単位データ取得の概念図である（その２）。
【図２４】図７のステップＳ１０４の処理の詳細な手順のうち、中間処理単位データ取得に関する部分を示すフローチャートである。
【図２５】本実施形態に係る中間処理単位データ管理テーブルの例を示す図である。
【図２６】ステップＳ１０４の処理のうち、リソース補正判定に関する部分の手順を示すフローチャートである。
【図２７】本実施形態に係る中間進捗率管理テーブルの例を示す図である。
【図２８】図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。
【図２９】本実施形態に係る中間処理リソース割当て管理テーブルの例を示す図である。
【図３０】契機毎のリソース割当ての例を示すものである。
【図３１】契機毎のリソース割当てに伴う中間処理進捗率管理テーブルおよび中間処理リソース割当て管理テーブルの推移の例を示すものである。
【図３２】処理遅延が発生している場合における契機毎のリソース割当ての例を示すものである（その１）。
【図３３】処理遅延が発生している場合における契機毎のリソース割当てに伴う中間処理進捗率管理テーブルおよび中間処理リソース割当て管理テーブルの推移の例を示すものである（その１）。
【図３４】本実施形態に係るリソース割当て所要時間管理テーブルの例を示す図である。
【図３５】図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。
【図３６】処理遅延が発生している場合における契機毎のリソース割当ての例を示すものである（その２）。
【図３７】処理遅延が発生している場合における契機毎のリソース割当てに伴う中間処理進捗率管理テーブルおよび中間処理リソース割当て管理テーブルの推移の例を示すものである（その２）。
【発明を実施するための形態】
【００１４】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【００１５】
［第１実施形態］
まず、図１〜図３４を参照して、本発明の第１実施形態に係る説明を行なう。なお、図１〜図６までがシステムおよび装置の構成を説明するための図であり、図７〜図１９までがリソース補正のための各情報を収集する処理を説明するための図であり、図２０から図３４までがリソース補正に係る処理を説明するための図である。
《システム構成》
図１は、本実施形態に係る計算機システムの構成例を示す図である。
計算機システム１０は、複数の実行物理サーバ４、クライアント装置６、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ（リソース管理装置）１がネットワーク７を介して互いに接続されている。なお、ネットワーク７は、ＬＡＮ（Local Area Network）や、ＷＡＮ（Wide Area Network）や、インターネットなどのグローバルネットワークである。また、ネットワーク７は、複数のネットワーク７に分けられてもよい。
ここで、実行物理サーバ４は、バッチアプリケーションを実行する複数の実行仮想サーバ５から構成されている。
【００１６】
次に、図１を参照しつつ、図２〜図６に沿って、計算機システム１０を構成する各装置１〜４の説明を行なう。
《実行仮想サーバ》
図２は、本実施形態に係る実行仮想サーバの構成例を示す機能ブロック図である。
実行仮想サーバ５は、二次記憶装置５１０、ＣＰＵ（Central Processing Unit）５２０、主記憶装置５００およびネットワークインタフェース５３０がバスによって互いに接続されてなる。
なお、実行仮想サーバ５が備える各種機器５００，５１０，５２０，５３０は、実行物理サーバ４が備える各種機器の一部を仮想的に割り当てたものである。
【００１７】
ネットワークインタフェース５３０は、実行仮想サーバ５がネットワーク７に接続するためのインタフェースである。ＣＰＵ５２０は、二次記憶装置５１０から主記憶装置５００にロードされたプログラムを実行する演算処理装置である。主記憶装置５００は、ＣＰＵ５２０によって実行されるプログラムおよびプログラムの実行に必要なデータを二次記憶装置５１０からロードするＲＡＭ（Random Access Memory）などの記憶装置である。プログラムとは、例えば、バッチ処理のロジックが記述され、ＣＰＵ５２０によって実行されることによりバッチアプリケーションとなるバッチＡＰ（Application）プログラム５０１などがあるが、不図示のＯＳ（Operating System）なども含まれる。二次記憶装置５１０は、バッチＡＰプログラム５０１が使用するバッチＡＰデータ５１１（以下、適宜データと記載）を格納するハードディスク装置などの磁気記憶媒体である。なお、二次記憶装置５１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。バッチＡＰデータ５１１の格納形態は限定されるものではないが、ファイル形式やＲＤＢ（Relational Database）などの形態で格納されるのが一般的である。なお、バッチＡＰデータ５１１は、主記憶装置５００上に格納されていても構わない。
【００１８】
《クライアント端末》
図３は、本実施形態に係るクライアント端末の構成例を示す機能ブロック図である。
クライアント装置６は、二次記憶装置６１０、ＣＰＵ６２０、主記憶装置６００およびネットワークインタフェース６３０がバスによって互いに接続されてなる。
ネットワークインタフェース６３０は、クライアント装置６がネットワーク７に接続するためのインタフェースである。ＣＰＵ６２０は、主記憶装置６００に記憶されているプログラムを実行することによってクライアント装置６の所定の機能を実現する演算処理装置である。主記憶装置６００は、ＣＰＵ６２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
【００１９】
ここで、プログラムとは、例えば、クライアント端末６が、不図示のＯＳ、ユーザからの実行要求の送信などクライアント装置６の所定の機能を実現するためのクライアント処理プログラム６０１などである。二次記憶装置６１０は、クライアント処理プログラム６０１が使用するクライアント処理データ６１１を格納するハードディスク装置などの磁気記憶媒体である。なお、二次記憶装置６１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
【００２０】
《リソース管理サーバ》
図４は、本実施形態に係るリソース管理サーバの構成例を示す機能ブロック図である。
リソース管理サーバ３は、実行物理サーバ４のリソースを管理するためのサーバであり、二次記憶装置３１０、ＣＰＵ３２０、主記憶装置３００およびネットワークインタフェース３３０がバスによって互いに接続されてなる。
二次記憶装置３１０は、リソース管理サーバ３がネットワーク７に接続するためのインタフェースである。ＣＰＵ３２０は、主記憶装置３００に記憶されているプログラムを実行することによってリソース管理サーバ３の所定の機能を実現する演算処理装置である。主記憶装置３００は、ＣＰＵ３２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
【００２１】
ここで、プログラムとは、例えば、リソース管理サーバ３が、不図示のＯＳ、リソース情報管理部３０１、アプリケーション構成情報管理部３０２およびリソース割当て処理部３０３の機能を実現するためのプログラムである。二次記憶装置３１０は、リソース管理サーバ３が各部３０１〜３０３の機能を実現するために必要なプログラムおよびリソース情報管理テーブル３１１、仮想マシンイメージである仮想マシンイメージ管理領域３１２を格納するハードディスク装置などの磁気記憶媒体である。リソース情報管理テーブル３１１は後記して説明する。なお、二次記憶装置３１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
なお、各部３０１〜３０３の機能については、処理の説明において後記する。
【００２２】
《配備制御サーバ》
図５は、本実施形態に係る配備制御サーバの構成例を示す機能ブロック図である。
配備制御サーバ２は、実行物理サーバ５に実行仮想サーバ４を配備するためのサーバであり、二次記憶装置２１０、ＣＰＵ２２０、主記憶装置２００およびネットワークインタフェース２３０がバスによって互いに接続されてなる。
ネットワークインタフェース２３０は、配備制御サーバ２がネットワーク７に接続するためのインタフェースである。ＣＰＵ２２０は、主記憶装置２００に記憶されているプログラムを実行することによってアプリケーション配備制御サーバ２の所定の機能を実現する演算処理装置である。主記憶装置２００は、ＣＰＵ２２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
【００２３】
ここで、プログラムとは、例えば、配備制御サーバ２が、不図示のＯＳ、ＳＬＡ（要求処理時間）情報管理部２０１、配備アプリケーション情報管理部２０２およびアプリケーション・データ配備処理部２０３の機能を実現するためのプログラムなどである。二次記憶装置２１０は、配備制御サーバ２が各部２０１〜２０３の機能を実現するために必要なプログラム、ＳＬＡ情報管理テーブル２１１、処理対象データ管理テーブル２１２、配備アプリケーション管理テーブル２１３、バッチ単位処理履歴管理テーブル２１４およびロット単位処理履歴管理テーブル２１５などの各データを格納するハードディスク装置などの磁気記憶媒体である。配備アプリケーション管理テーブル２１３、バッチ単位処理履歴管理テーブル２１４およびロット単位処理履歴管理テーブル２１５は後記して説明する。なお、二次記憶装置２１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。なお、ロット単位処理履歴管理テーブル２１５には、図１６および図１７で後記するバッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂも含まれている。
なお、各部２０１〜２０３の機能については、処理の説明において後記する。
【００２４】
《リソース補正制御サーバ》
図６は本実施形態に係るリソース補正制御サーバの構成例を示す機能ブロック図である。
リソース補正制御サーバ１は、後記して説明する再検査の契機で、リソースの割当て補正を行なう装置であり、二次記憶装置１１０、ＣＰＵ１２０、主記憶装置１００およびネットワークインタフェース１３０がバスによって互いに接続されてなる。
ネットワークインタフェース１３０は、リソース補正制御サーバ１がネットワーク７に接続するためのインタフェースである。ＣＰＵ１２０は、主記憶装置１００に記憶されているプログラムを実行することによってリソース補正制御サーバ１の所定の機能を実現する演算処理装置である。主記憶装置１００は、ＣＰＵ１２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
【００２５】
ここで、プログラムとは、例えば、リソース補正制御サーバ１が、不図示のＯＳ、再検査契機取得処理部１０１、中間処理単位データ取得処理部１０２、リソース補正判定処理部１０３および割当てリソース算出処理部１０４の機能を実現するためのプログラムなどである。二次記憶装置１１０は、リソース補正制御サーバ１が各部１０１〜１０４の機能を実現するために必要なプログラム、中間処理単位データ管理テーブル１１１、中間処理進捗率管理テーブル１１２、中間処理リソース割当て管理テーブル１１３およびリソース割当て所要時間管理テーブル１１４の各データを格納するハードディスク装置などの磁気記憶媒体である。中間処理単位データ管理テーブル１１１、中間処理進捗率管理テーブル１１２、中間処理リソース割当て管理テーブル１１３およびリソース割当て所要時間管理テーブル１１４は後記して説明する。なお、二次記憶装置１１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
なお、各部１０１〜１０４の機能については、処理の説明において後記する。
【００２６】
以上、各装置のハードウェア構成およびソフトウェア構成について説明してきたが、実行物理サーバ４、実行仮想サーバ５、クライアント装置６、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ１の構成は、図１に示す構成に限定されるものではない。例えば、図１では、実行物理サーバ４上で複数の実行仮想サーバ５が稼働している構成を示したが、実行仮想サーバ５を介さず、実行物理サーバ４上でバッチアプリケーションが稼働する構成でも構わない。さらに、実行物理サーバ４上で稼働するバッチアプリケーションと、実行仮想サーバ５上で稼働するバッチアプリケーションが混在する構成でも構わない。また、図１では、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ１は、異なる計算機上で実行される構成を示したが、これらの全部、または一部が同一のサーバ上で実行しても構わない。
【００２７】
次に、図１〜図６を参照しつつ、図７〜図３４に沿って本実施形態に係る処理の説明を行なう。
《全体処理》
図７は、本実施形態に係るバッチアプリケーション実行方法に関する全体処理の手順を示すフローチャートである。
まず、クライアント装置６から配備制御サーバ２へバッチサービスの受付要求として、バッチＡＰプログラム名、処理対象となるデータ（バッチＡＰデータ５１１）、配備対象となる実行物理サーバ名である配備対象サーバ名、見積りリソース量および要求処理時間が送信される（Ｓ１０１）。ここで、見積もりリソース量とは、ユーザがクライアント端末６に入力するバッチサービスに必要なリソース量である。
【００２８】
なお、本実施形態では、クライアント装置６から実行対象のバッチＡＰプログラム５０１、処理対象データ、要求処理時間と共に、見積りリソース量も受信するものとしたが、見積りリソース量が与えられなかった場合は、図３０に示すバッチ単位処理履歴管理テーブル２１４を参照して、過去に実行したバッチアプリケーション名、データ処理件数、平均バッチ終了時間、使用したリソース量などから、見積もったリソース量を使用しても構わない。
【００２９】
なお、要求処理時間の代わりに、要求処理開始時刻と要求処理終了時刻を指定しても構わない。あるいは、要求処理時間と、処理開始時刻と処理終了時刻の両者であっても構わない。
【００３０】
続いて、配備制御サーバ２からリソース管理サーバ３に、リソース情報の取得要求が送信され、リソース管理サーバ３は、稼働リソース情報を確認した上で、指定されたリソースをバッチアプリケーションに割当てる（Ｓ１０２）。ステップＳ１０２の詳細は後記して説明する。
【００３１】
次に、クライアント装置６は、配備制御サーバ２に対して、バッチアプリケーションの実行要求を送信し、配備制御サーバ２は実行仮想サーバ４でバッチアプリケーションを開始し、さらに、配備制御サーバ２は処理対象データに対して、ロット単位の処理の成功、失敗などの処理履歴を管理する（Ｓ１０３）。ステップＳ１０３の処理は後記して説明する。
そして、リソース補正制御サーバ１の再検査契機取得処理部１０１が、後記して説明する再検査の契機で、ロット単位の処理履歴をグルーピングして中間処理単位とし、処理進捗率と必要進捗率を算出する（Ｓ１０４）。ステップＳ１０４の処理は後記して説明する。
【００３２】
続いて、リソース補正制御サーバ１のリソース補正判定処理部１０３は、ステップＳ１０４で算出した処理進捗率と必要進捗率の比較を行ない、処理進捗率が必要進捗率未満となるバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ１０５）。なお、処理進捗率と必要進捗率については後記して説明するが、処理進捗率は該当時点における実際の進捗率であり、必要進捗率は要求処理時間内にバッチ処理が終了するために該当時点でどれだけ進捗していなければならないかを示すものである。
ステップＳ１０５の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがある場合（Ｓ１０５→Ｙｅｓ）、リソース補正判定処理部１０３は、バッチ処理に遅延が発生しているものと判定し、リソース補正制御サーバ１の割当てリソース算出処理部１０４が、所定の規則で、ロット単位でのバッチのデータ（ロット単位データ）をグルーピングした中間処理履歴を基に、処理遅延の回復に必要なリソース量を算出する（Ｓ１０６）。
【００３３】
なお、割当てリソース算出処理部１０４は、リソースが確保できない場合などは、割当て可能な最大リソースを割当てるものとする。
【００３４】
リソース管理サーバ３のリソース割当て処理部３０３がステップＳ１０６で算出した割当てリソースの割当てを実施する（Ｓ１０７）。
なお、ステップＳ１０５〜ステップＳ１０７の詳細は後記して説明する。
【００３５】
ステップＳ１０５の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがない場合（Ｓ１０５→Ｎｏ）、割当てリソース補正判定処理部１０３は、予定通りバッチ処理が進行しているものと判定し、次のロットについてバッチ処理を続行する（ステップＳ１０８）。
ステップＳ１０７およびステップＳ１０８の後、配備制御サーバ２の配備アプリケーション情報管理部２０２が、すべてのロットに対して、バッチ処理を終了したか否かを判定する（Ｓ１０９）。
【００３６】
ステップＳ１０９の結果、すべてのロットに対しバッチ処理が終了していない場合（Ｓ１０９→Ｎｏ）、計算機システム１０はステップＳ１０４へ処理を戻す。
ステップＳ１０９の結果、すべてのロットに対しバッチ処理が終了している場合（Ｓ１０９→Ｙｅｓ）、計算機システム１０は処理を終了する。
【００３７】
《ステップＳ１０２の詳細（リソース情報取得およびリソース割当て）》
図８は、図７のステップＳ１０２の処理のうち、リソース情報取得およびリソース割当てに関する部分の詳細な手順を示すフローチャートである。なお、図８の処理は、リソース管理サーバ３上のリソース情報管理部３０１、アプリケーション構成情報管理部３０２およびリソース割当て処理部３０３が行なう処理である。
まず、リソース管理サーバ３は、クライアント装置６、配備制御サーバ２またはリソース補正制御サーバ１から、バッチアプリケーションのリソース情報取得の実行要求、またはリソース割当ての実行要求をクライアント端末から受信する（Ｓ２０１）。
続いて、リソース情報管理部３０１は、処理対象となっている実行要求がリソース情報取得の実行要求であるか否かを判定する（Ｓ２０２）。
ステップＳ２０２の結果、リソース情報取得の実行要求でない場合（Ｓ２０２→Ｎｏ）、すなわち、処理対象となっている実行要求がリソース割当ての実行要求である場合、リソース管理サーバ３は、リソース割当て処理部３０３を起動し、起動されたリソース割当て処理部３０３が、図１０で後記するリソースの割当てを実行物理サーバ４に行なった後、実行物理サーバ５上に実行仮想サーバ４を作成し、リソース情報管理テーブル３１１（図９）に割当てたリソース情報を反映させ（Ｓ２０３）、ステップＳ２０６へ処理を進める。ここで、リソース情報とは、図９のリソース情報管理テーブル３１１に格納されてる各情報である。
【００３８】
ステップＳ２０２の結果、リソース情報取得の実行要求である場合（Ｓ２０２→Ｙｅｓ）、リソース管理サーバ３は、リソース情報管理部３０１を起動し、起動されたリソース情報管理部３０１が、実行物理サーバ４上で稼働している実行仮想サーバ５から、当該実行仮想サーバ５のリソース種別、ＣＰＵ種別、メモリ種別、ディスク種別、および各々の実行物理サーバに割当てられたリソース量を取得し、これらの情報を登録することでリソース情報管理テーブル３１１（図９）を更新する(Ｓ２０４）。
次に、リソース管理サーバ３はアプリケーション構成情報管理部３０２を起動し、起動されたアプリケーション構成情報管理部３０２は、実行仮想サーバ４上で稼働しているバッチアプリケーションのバッチＡＰプログラム名と稼働状態を取得し、取得したバッチＡＰプログラム名と稼働状態を登録することで、リソース情報管理テーブル３１１（図９）を更新する（Ｓ２０５）。
【００３９】
なお、本実施形態において、リソース管理サーバ３はリソース情報取得の実行要求を受信することで、ステップＳ２０４およびステップＳ２０５を実行したが、これに限らず、定期的な監視によってステップＳ２０４およびステップＳ２０５を行なっても構わない。
【００４０】
そして、リソース管理サーバ３は未実行の実行要求（リソース情報取得またはリソース割当て）があるか否かを判定する（Ｓ２０６）。
ステップＳ２０６の結果、未実行の実行要求がある場合（Ｓ２０６→Ｙｅｓ）、リソース管理サーバ３はステップＳ２０２へ処理を戻す。
ステップＳ２０６の結果、未実行の実行要求がない場合（Ｓ２０６→Ｎｏ）、リソース管理サーバ３は、図７の処理へリターンする。
【００４１】
《リソース情報管理テーブル》
図９は、本実施形態に係るリソース情報管理テーブルの例を示す図である。
リソース情報管理テーブル３１１は、リソース情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、バッチアプリケーションの実行や完了などの状態を示す稼働状態の各欄を有する。さらに、リソース情報管理テーブル３１１は、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てた実行物理サーバ４のＣＰＵのコア数を示すＣＰＵ割当て（コア割当て数）、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て（メモリ割当て数）の各情報を有する。
【００４２】
図９に示すリソース情報管理テーブル３１１の例では、リソースの具体例として、ＣＰＵとメモリを挙げたが、この他に、ハードディスクなどをリソースの対象に含めても構わない。例えば、ハードディスクを対象リソースに含めた場合、リソース情報管理テーブル３１１は、ハードディスクのスペック名称を示すハードディスク種別、割当てたハードディスクの容量を示すディスク割当てを有することになる。なお、ハードディスク割当てには、割当てたハードディスクの容量を示すものとしたが、データ転送量などの情報を示すものとしても構わない。
【００４３】
《ステップＳ２０３の詳細（リソース割当て）》
図１０は、図８のステップＳ２０３の処理の詳細な手順を示すフローチャートである。なお、図１０の処理は、配備制御サーバ２上のＳＬＡ（要求処理時間）情報管理部２０１、配備アプリケーション情報管理部２０２およびアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２がクライアント装置６からバッチサービスの受付要求を受信する（Ｓ３０１）。
続いて、配備制御サーバ２がＳＬＡ情報管理部２０１を起動し、起動されたＳＬＡ情報管理部２０１が、クライアント装置６から実行対象のバッチＡＰプログラム５０１、処理対象データ、配備対象サーバ名、見積りリソース量、要求処理時間を受信する（Ｓ３０２）。ここで、ステップＳ３０２は、図７のステップＳ１０１に対応する。なお、要求処理時間の代わりに、処理開始時刻と処理終了時刻を指定しても構わない。あるいは、要求処理時間と、要求処理開始時刻と要求処理終了時刻の両者であっても構わない。また、処理対象データは、ロットと呼ばれる業務要件によって定められた分類や一定のデータ件数で分けられた単位に分割されているものとする。
【００４４】
次にＳＬＡ情報管理部２０１が、リソース管理サーバ３にリソース情報取得の実行要求を送信し、リソース管理サーバ３上に格納されるリソース情報管理テーブル３１１（図９）を参照することによってリソース割当て状況を確認し、未割当てのＣＰＵのコアが存在するか否かで実行物理サーバ４へのバッチアプリケーションの割当てが可能か否かを判定する（Ｓ３０３）。なお、ここで、送信されたリソース情報取得の実行要求が、ステップＳ２０１で受信される実行要求である。
ステップＳ３０３の結果、バッチアプリケーションの割当てが可能でない場合（Ｓ３０３→Ｎｏ）、ＳＬＡ情報管理部２０１がクライアント装置６にリソースが確保できないというメッセージを表示させ（Ｓ３０４）、ステップＳ３０３へ処理を戻して、リソースが空くのを待つ。ただし、ある一定時間の経過によって図１０の処理を終了させたり、クライアント装置６からの処理終了の要求で、図１０の処理を終了させても構わない。
【００４５】
ステップＳ３０３の結果、バッチアプリケーションの割当てが可能である場合（Ｓ３０３→Ｙｅｓ）、ＳＬＡ情報管理部２０１がリソース管理サーバ３に、リソース割当ての実行要求を送信し、割当ての対象となるバッチＡＰプログラム名、処理対象データ名、配備対象サーバ名、および要求処理時間を図１１に示すＳＬＡ情報管理テーブル２１１に登録する（Ｓ３０５）。ここで、送信されたリソース割当ての実行要求が、ステップＳ２０１で受信される実行要求である。なお、リソース割当ての実行要求には、処理対象データ名、配備対象サーバ名、および要求処理時間が格納されている。
そして、ＳＬＡ情報管理部２０１は、ステップＳ３０２で受信したバッチ処理の対象データ（処理対象データ）から処理対象データ名、データ件数、ロット単位件数、ロット単位データ名を取得すると、図１２に示す処理対象データ管理テーブル２１２に登録し（Ｓ３０６）、図１３の処理へ進む。
【００４６】
《ＳＬＡ情報管理テーブル》
図１１は、本実施形態に係るＳＬＡ（要求処理時間）情報管理テーブルの例を示す図である。
ＳＬＡ情報管理テーブル２１１は、図１０のステップＳ３０２でクライアント装置６から受信したバッチサービスに関する情報を管理するための属性情報として、バッチアプリケーションプログラム名、処理対象データ名、配備対象サーバ名、要求処理時間、要求処理開始時刻および要求処理終了時刻の各情報を有する。要求処理開始時刻、あるいは、要求処理終了時刻が指定されない場合は、ＮＵＬＬ値が格納される。
【００４７】
《処理対象データ管理テーブル》
図１２は、本実施形態に係る処理対象データ管理テーブルの例を示す図である。
処理対象データ管理テーブル２１２は、図１０のステップＳ３０２で受信した処理対象データに関する情報を管理するための属性情報として、処理対象データ名、データ件数、業務要件により定められた分類や一定のデータ件数で分けられたロット単位件数、ロット単位に分けられたデータを識別するためのロット単位データ名の各情報を有する。
【００４８】
《ステップＳ１０２の詳細（バッチアプリケーション情報収集）》
図１３は、図７のステップＳ１０２の処理のうち、バッチアプリケーション情報収集に関する部分の詳細な手順を示すフローチャートである。なお、図１３の処理は、配備制御サーバ２上の配備アプリケーション情報管理部２０２が行なう処理である。
まず、配備制御サーバ２は、リソース管理サーバ３から、図８のステップＳ２０５におけるリソース情報管理テーブル３１１（図９）の更新をメッセージとして受信する（Ｓ４０１）。
そして、配備制御サーバ２は配備アプリケーション情報管理部２０２を起動し、起動された配備アプリケーション情報管理部２０２が、リソース管理サーバ３のリソース情報管理テーブル３１１（図９）から全レコードにおける実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）を取得する（Ｓ４０２）。
【００４９】
続いて、配備アプリケーション情報管理部２０２は、ＳＬＡ情報管理テーブル２１１（図１１）から処理対象となっているバッチアプリケーションの処理対象データ名を取得し、処理対象データ管理テーブル２１２（図１２）にアクセスして、割出した処理対象データに該当するロット単位データ名を取得し、ステップＳ４０２で取得した実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名と共に、配備アプリケーション管理テーブル２１３（図１４）に登録することで配備アプリケーション管理テーブル２１３を更新し（Ｓ４０３）、図７の処理へリターンする。なお、初回の場合、配備アプリケーション情報管理部２０２が配備アプリケーション管理テーブル２１３を新規作成するものとする。
【００５０】
《配備アプリケーション管理テーブル》
図１４は、本実施形態に係る配備アプリケーション管理テーブルの例を示す図である。
配備アプリケーション管理テーブル２１３は、配備対象となるアプリケーション、実行サーバ、処理対象データとの対応に関する情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、処理対象データ名およびロット単位データ名の各情報を有する。
【００５１】
《ステップＳ１０３の詳細》
図１５は、図７のステップＳ１０３の処理の詳細な手順を示すフローチャートである。なお、図１５の処理は、主に配備制御サーバ２上のアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２は、クライアント装置６からバッチアプリケーションの実行要求を受信する（Ｓ５０１）。
そして、配備制御サーバ２はアプリケーション・データ配備処理部２０３を起動し、起動されたアプリケーション・データ配備処理部２０３は配備アプリケーション管理テーブル２１３（図１４）を参照して、実行対象であるバッチアプリケーション名をキーとして、実行仮想サーバ名を取得する（Ｓ５０２）。
続いて、アプリケーション・データ配備処理部２０３は、リソース管理サーバ３上の仮想マシンイメージ管理領域３１２に格納された該当の仮想マシンイメージを、該当の実行物理サーバ４に配備し、起動させる（Ｓ５０３）ことによって、実行仮想サーバ５を起動する。
【００５２】
次に、アプリケーション・データ配備処理部２０３は、配備アプリケーション管理テーブル２１３（図１４）を参照して、起動した実行仮想サーバ５にロット単位データを配備する（Ｓ５０４）。
そして、アプリケーション・データ配備処理部２０３は、ステップＳ５０４の処理をすべてのロットに対して処理したか否かを判定する（Ｓ５０５）。なお、ステップＳ５０４の処理は、所定のロット単位データ毎に行なってもよいし、すべてのロット単位データでまとめて行なってもよい。
ステップＳ５０５の結果、すべてのロットに対して処理していない場合（Ｓ５０５→Ｎｏ）、アプリケーション・データ配備処理部２０３はステップＳ５０５へ処理を戻す。
ステップＳ５０５の結果、すべてのロットに対して処理している場合（Ｓ５０５→Ｙｅｓ）、各実行仮想サーバ５は該当するバッチアプリケーションを実行する（Ｓ５０６）。このとき、アプリケーション・データ配備処理部２０３は、リソース補正制御サーバ１のリソース割当て所要時間管理テーブル１１４（図３４）の各欄に情報を登録し、割当て所要時間の欄にバッチアプリケーションの割当てにかかった時間を登録する。
【００５３】
アプリケーション・データ配備処理部２０３は、配備した各々のバッチアプリケーションに対して、ロット単位毎に処理状況を監視する（Ｓ５０７）。
そして、アプリケーション・データ配備処理部２０３は、すべてのロットのバッチ処理を終了したか否かを判定する（Ｓ５０８）。
ステップＳ５０８の結果、すべてのロットのバッチ処理を終了している場合（Ｓ５０８→Ｙｅｓ）、アプリケーション・データ配備処理部２０３は、バッチアプリケーションの処理時間や使用したリソース情報などの処理履歴をバッチ単位処理履歴管理テーブル２１４（図１９）およびアプリケーションゲーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）に登録し（Ｓ５０９）、図７の処理へリターンする。ここで、リソース情報とは、ステップＳ４０２で取得したＣＰＵ種別、合計ＣＰＵ割当て、メモリ種別および合計メモリ割当てなどである。
【００５４】
ステップＳ５０８の結果、すべてのロットのバッチ処理を終了していない場合（Ｓ５０８→Ｎｏ）、アプリケーション・データ配備処理部２０３は、ロット単位のバッチ処理の終了の監視を行ない、ロット単位のバッチ処理が終了したか否かを判定する（Ｓ５１０）。
ステップＳ５１０の結果、ロット単位のバッチ処理が終了していない場合（Ｓ５１０→Ｎｏ）、アプリケーション・データ配備処理部２０３は、ステップＳ５１０へ処理を戻し、監視を続ける。
【００５５】
ステップＳ５１０の結果、ロット単位の処理が終了している場合（Ｓ５１０→Ｙｅｓ）、アプリケーション・データ配備処理部２０３は、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）における処理単位の欄を「終了」に更新し、所要時間の欄に所要時間を登録する（Ｓ５１１）。このとき、アプリケーション・データ配備処理部２０３は、現在時刻を処理状態最終更新時刻の欄に登録する。
そして、アプリケーション・データ配備処理部２０３は、各ロット単位を処理するのに要した平均所要時間を算出し、ロット単位処理履歴管理テーブル２１５（図１８）に算出した平均値および使用したリソース情報（実行物理サーバ４のＣＰＵ種別、ＣＰＵ割当て、メモリ種別、メモリ割当て）を登録し（Ｓ５１２）ステップＳ５０８へ処理を戻す。リソース情報は、図１３のステップＳ４０２で取得した情報である。
【００５６】
なお、バッチアプリケーションの切離し（終了）も、同様の手順で行なわれるが、このとき、アプリケーション・データ配備処理部２０３は、リソース補正制御サーバ１のリソース割当て所要時間管理テーブル１１４（図２４）の各欄に情報を登録し、切離し所要時間の欄にバッチアプリケーションの切離し（終了）にかかった時間を登録する。
【００５７】
《バッチアプリケーション毎ロット単位処理履歴管理テーブル》
図１６および図１７は、本実施形態に係るバッチアプリケーション毎ロット単位処理履歴管理テーブルの例を示す図である。なお、図１６が「バッチＡＰ１」について、図１７はバッチＡＰ２について示している。
図１６を参照して説明すると、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ（２１５）は、バッチアプリケーションにおけるロット単位での処理履歴を管理する属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、ロット単位での処理の終了や実行中などの状態を示す処理状態、ロット単位の処理の終了に係る時間を示す所要時間を有している。また、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当てを有している。さらに、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、該当するロット単位データの処理が終了した時刻である処理状態最終更新時刻の各情報を有する。
処理状態の欄には、「実行前」、「実行中」、「終了」などの情報が格納される。
なお、図１７のバッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ｂ（２１５）は、対象となるバッチアプリケーションが「バッチＡＰ２」となった以外は、図１６と同様であるため説明を省略する。
【００５８】
《ロット単位処理履歴管理テーブル》
図１８は、本実施形態に係るロット単位処理履歴管理テーブルの例を示す図である。
ロット単位処理履歴管理テーブル２１５は、各々のバッチアプリケーションにおけるロット単位での処理履歴を管理するための属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、各々のロットの平均処理時間を示す平均ロット処理時間、ロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
【００５９】
図１８は、「バッチＡＰ１」がロット単位データ「データ１−２」まで処理が完了しており、「バッチＡＰ２」がロット単位データ「データ２−３」まで処理が完了していることを示している。
【００６０】
《バッチ単位処理履歴管理テーブル》
図１９は、本実施形態に係るバッチ単位処理履歴管理テーブルの例を示す図である。
バッチ単位処理履歴管理テーブル２１４は、各々のバッチアプリケーションにおける処理履歴を管理するための属性情報として、処理実行日、バッチアプリケーション名（バッチＡＰ名）、データ処理件数、バッチ処理が終了するまでにかかる時間を示すバッチ処理時間、今回のバッチ処理時間を含む、これまでのバッチ処理のバッチ処理時間の平均処理時間を示す平均バッチ平均処理時間の各情報を有する。また、バッチ単位処理履歴管理テーブル２１４は、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵの合計コア数を示す合計ＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、割当てたメモリの合計容量を示す合計メモリ割当ての各情報を有する。
【００６１】
図１９の例は、「２０１０年１月２１日」には、「バッチＡＰ１」が４０００件のデータをバッチ処理し、「バッチＡＰ２」が２０００件のデータをバッチ処理したことを示している。同様に、「２０１０年１月２２日」には、「バッチＡＰ１」が３０００件のデータをバッチ処理し、「バッチＡＰ２」が３０００件のデータをバッチ処理したことを示している。
【００６２】
ここで、バッチ平均処理時間は、バッチ処理時間の平均値であり、例えば「２０１０−０１−２２」の「バッチＡＰ１」におけるバッチ平均処理時間「４．８０時間」は、「２０１０−０１−２１」のバッチ処理時間「４．７５時間」と、「２０１０−０１−２２」のバッチ処理時間「４．８５時間」との平均値である。
【００６３】
次に、図２０〜図３４を参照して、本実施形態に係るリソース補正処理について説明する。
《再検査の契機の概念図》
図２０は、本実施形態に係るリソース補正のための再検査の契機に関する概念図である。
ここで、リソース量の再検査（以下、再検査と称する）を行なう目的は、バッチアプリケーションの要求処理時間（ＳＬＡ）遵守の確度を高めることである。つまり、リソース補正制御サーバ１は、再検査を行なうことで、要求処理時間内で処理を終了させるペースで処理の進捗が得られているか確認することができ、処理を終了させるペースの進捗が得られていない場合は、リソースの割当ての見直しを行なう。これにより、リソース補正制御サーバ１は、バッチ処理の遅延を回復することが可能になる。ただし、頻繁にリソースの割当てを見直すことは、バッチ処理のスループットを低下させる原因にもなるので、効果的な見直しを行なう必要がある。本実施形態では、効果的な見直しを行なうために、共存するバッチアプリケーションを横断的に統合監視し、バッチアプリケーションの開始や終了のタイミングに着目して、再検査を行なうものとする。
【００６４】
図２０は、３つのバッチアプリケーション「バッチＡＰ１」、「バッチＡＰ２」および「バッチＡＰ３」が共存する環境下における再検査の契機を概念的に示したものである。図２０では、まず、「Ｔ０」の時刻で「バッチＡＰ１」の処理が開始していることを示し、「バッチＡＰ２」の処理が開始する「Ｔ１」の時刻を、１度目の再検査の契機としている。続いて、「バッチＡＰ３」の処理が開始する「Ｔ２」の時刻を、２度目の再検査の契機としている。同様に、「バッチＡＰ２」の処理が終了する「Ｔ３」の時刻を、３度目の再検査の契機とし、「バッチＡＰ３」の処理が終了する「Ｔ４」の時刻を、４度目の再検査の契機としている。さらに、「バッチＡＰ１」が終了する「Ｔ５」の時刻を５度目の再検査の契機としている。また、図２０では、「バッチＡＰ１」の処理時間に関しては、処理開始時刻「Ｔ０」から処理終了時刻「Ｔ５」までであって、要求処理時間が処理終了時刻「Ｔ５」の先にあることから、「バッチＡＰ１」は要求処理時間内に処理が終了できたことを示している。同様にして、「バッチＡＰ２」、「バッチＡＰ３」についても要求処理時間内に処理が終了している。
【００６５】
《ステップＳ１０４の詳細（再検査の契機取得）》
図２１は、ステップＳ１０４の処理の詳細な手順のうち、再検査の契機取得に関する部分を示すフローチャートである。なお、図２１の処理は、リソース補正制御サーバ１の再検査契機取得処理部１０１が行なう処理である。
リソース管理サーバ３は、図８のステップＳ２０５でリソース情報管理テーブル３１１（図９）の稼働状態ステータスが「準備中」→「実行中」となると「開始」を検知し、「実行中」→「準備中」となると「終了」を検知し、これらの情報をリソース補正制御サーバ１へ送信する。
【００６６】
まず、リソース補正制御サーバ１が、リソース管理サーバ３からバッチアプリケーションの稼働状態に変化があったことをメッセージとして受信し、再検査契機取得処理部１０１を起動する（Ｓ６０１）。
そして、起動された再検査契機取得処理部１０１は、稼動状態に変化が起きた時刻（ステップＳ６０１でメッセージを受信した時刻）を再検査の契機とする（Ｓ６０２）。
【００６７】
なお、本実施形態では、再検査の契機を共存するアプリケーションの稼働状態の変化から取得するものとしたが、定期的な時刻や時間を再検査の契機としても構わない。また、ロット単位のバッチ処理の終了メッセージや、リソース使用率の閾値監視のアラートを契機にしても構わない。
【００６８】
《中間処理単位データ取得の概念図》
図２２および図２３は、再検査に必要な中間処理単位データ取得の概念図である。
ここで、図２２は、各バッチアプリケーションで使用するロット単位データのデータ数が同じである場合を示し、図２３は、各バッチアプリケーションで使用するロット単位データのデータ数が異なる場合を示している。
なお、図２２および図２３における「１−１」、「１−２」などは配備アプリケーション管理テーブル２１３（図１４）のロット単位データの「データ１−１」、「データ１−２」などに対応する。
中間処理単位を決める目的は、バッチ処理の進捗率の算出に必要になる処理済みデータを特定するためである。図２２に示すように、中間処理単位は、契機を境にして処理済みのロット単位のデータをグルーピングすることによって決める。例えば、「バッチＡＰ１」の場合、時刻「Ｔ１」の契機では、ロット単位データ「１−１」、「１−２」がグルーピングされ、１つの中間処理単位となり、リソース補正判定処理部１０３は、このグルーピングを基に後記する進捗率を求める。同様にして、時刻「Ｔ２」の契機では、中間処理単位データ取得処理部１０２は、ロット単位データ「１−３」を中間処理単位とし、時刻「Ｔ３」の契機では、ロット単位データ「１−４」、「１−５」、「１−６」を中間処理単位とする。そして、時刻「Ｔ４」の契機では、ロット単位データ「１−７」を中間処理単位とし、時刻「Ｔ５」の契機では、ロット単位データ「１−８」、「１−９」を中間処理単位とする。中間処理単位データ取得処理部１０２は、「バッチＡＰ２」、「バッチＡＰ３」も同様にして中間処理単位を求める。
【００６９】
図２２では、共存する全てのバッチアプリケーションのロット単位が１００件と均一な例を示したが、実際には、業務要件により、バッチアプリケーションによって異なるロット単位が混在するケースが予想される。図２３は、その場合における中間処理単位を決めるためのデータ分割を概念的に示したものである。
取得した再検査の契機が、ロット単位や１件当たりの処理の負荷によるばらつきにより、処理途中であったロットは、その直近のロットの処理終了を中間処理単位とする。
【００７０】
《ステップＳ１０４の詳細（中間処理単位データ取得）》
図２４は、図７のステップＳ１０４の処理の詳細な手順のうち、中間処理単位データ取得に関する部分を示すフローチャートである。なお、図２４の処理は、リソース補正制御サーバ１の中間処理単位データ取得処理部１０２が主に行なう処理である。
まず、リソース補正制御サーバ１は、図２１のステップＳ６０２での再検査契機取得処理部１０１から再検査の契機取得完了を検知する（Ｓ７０１）。
そして、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２を起動し、起動された中間処理単位データ取得処理部１０２は、再検査契機取得処理部１０１が図２１のステップＳ６０２で取得した再検査の契機の時刻を取得する（Ｓ７０２）。
続いて、中間処理単位データ取得処理部１０２は、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）を参照し、取得した再検査の契機の時刻（処理状態最終更新時刻）における処理状態のステータスを取得する（Ｓ７０３）。
【００７１】
そして、中間処理単位データ取得処理部１０２は、取得した処理状態のステータスが「実行中」のバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ７０４）。
ステップＳ７０４の結果、「実行中」のバッチアプリケーションがある場合（Ｓ７０４→Ｙｅｓ）、中間処理単位データ取得処理部１０２は、そのバッチアプリケーションに関し、前回の契機から、すでに終了しているロット単位データまでを中間処理単位データとして、中間処理単位データ管理テーブル１１１（図２５）に登録し（Ｓ７０５）、図２６の処理へ進む。ここでは、「実行中」のバッチアプリケーションがある場合において、その時点で終了しているロットを中間処理単位データに含めるようにしたが、実行中のロットが終了するまで待ち、終了した時点で該当のロットを含めて中間処理単位データとしてもよい。
【００７２】
ステップＳ７０４の結果、「実行中」のバッチアプリケーションがない場合（Ｓ７０４→Ｎｏ）、前回の契機から今回の契機までの間に処理が終了しているロットを中間処理単位データとして、中間処理単位データ管理テーブル１１１（図２５）に登録し（Ｓ７０６）、図２６の処理へ進む。
【００７３】
《中間処理単位データ管理テーブル》
図２５は、本実施形態に係る中間処理単位データ管理テーブルの例を示す図である。
中間処理単位データ管理テーブル１１１では、各バッチアプリケーションの中間処理単位データを管理するための属性情報として、再検査の契機時刻を示す契機、共存するバッチアプリケーションの中間処理単位となるデータを示すバッチＡＰ１中間処理単位データ、バッチＡＰ２中間処理単位データ、バッチＡＰ３中間処理単位データの各情報を有する。なお、図２５では、共存するバッチアプリケーションが３つの例を示しているが、１つ以上であれば、共存するバッチアプリケーションはいくつであってもよい。
【００７４】
《ステップＳ１０４の詳細（リソース補正判定）》
図２６は、ステップＳ１０４の処理のうち、リソース補正判定に関する部分の手順を示すフローチャートである。なお、図２６の処理は、主にリソース補正制御サーバ１のリソース補正判定処理部１０３が行なう処理である。
まず、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２から中間処理単位データの取得完了を検知する（Ｓ８０１）。
そして、リソース補正制御サーバ１は、リソース補正判定処理部１０３を起動し、起動されたリソース補正判定処理部１０３は、中間処理単位データ管理テーブル１１１を参照し、各バッチアプリケーションにおいて、処理対象となっている契機の中間処理単位データ名を取得する（Ｓ８０２）。
【００７５】
次に、リソース補正判定処理部１０３は、配備制御サーバ２の処理対象データ管理テーブル２１２（図１２）を参照して、ステップＳ８０２で取得した処理対象となっている中間処理単位データに該当するロット単位件数を取得し、取得した各々のロット単位件数毎のデータ件数を加算し、累積処理件数とすることによって、累積処理件数を算出する（Ｓ８０３）。
【００７６】
続いて、リソース補正判定処理部１０３は、配備制御サーバ２の処理対象データ管理テーブル２１２（図１２）を参照して、処理対象となっている中間処理単位データに該当するデータ件数を取得することによって、全処理対象件数を取得し、ステップＳ８０３で算出した累積処理件数と、全処理対象件数とを基に、式（１）を計算することにより全処理対象件数に対する累積処理件数の占める割合である処理進捗率を算出する（Ｓ８０４）。
ここで、処理進捗率は、前記したように現時点での実際の処理進捗率である。
【００７７】
処理進捗率＝累積処理件数/全処理対象件数  ・・・  （１）
【００７８】
次に、リソース補正判定処理部１０３は、配備制御サーバ２のバッチアプリケーション毎ロット単位データ処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）を参照して、処理対象の中間処理データに該当するロット単位データの所要時間を加算することで、中間処理データに含まれるロットの処理にかかった時間を取得し、この時間を累積処理時間とする（Ｓ８０５）。
【００７９】
そして、リソース補正判定処理部１０３は、配備制御サーバ２上のＳＬＡ情報管理テーブル２１１を参照して、各バッチアプリケーションの要求処理時間を取得すると、要求処理時間、累積処理時間から必要進捗率を算出し、該当するバッチアプリケーション名、ステップＳ７０３で取得した処理状態と共に、処理進捗率と必要進捗率とを中間処理進捗率管理テーブル１１２（図２７）に登録する（Ｓ８０６）。ここで、必要進捗率の算出方法は、リソース補正判定処理部１０３が、要求処理時間に対する累積処理時間と全処理件数の比率を求めることで行なわれる。すなわち、必要進捗率は、全処理件数に対する現段階までに処理が行なわれているべき処理件数の割合であり、以下の式（２）で算出されるものである。
【００８０】
必要進捗率＝累積処理時間/要求処理時間  ・・・  （２）
【００８１】
なお、式（２）のバリエーションとして、要求処理時間遵守の確度を高めるために、累積処理時間の代わりに、累積処理時間に安全係数を加味した時間を加えた合計時間を用いてもよい。また、式（１）および式（２）の処理進捗率、必要進捗率のそれぞれに、全処理件数をかけたものを処理進捗率、必要進捗率としてもよい。
【００８２】
次に、リソース補正判定処理部１０３は、算出した処理進捗率と必要進捗率の値を比較し、処理進捗率が必要進捗率未満となるバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ８０７）。ここで、ステップＳ８０７の処理は、図７のステップＳ１０５に対応する処理である。
ステップＳ８０７の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがない場合（Ｓ８０７→Ｎｏ）、リソース補正判定処理部１０３は。、リソース補正を行なう必要はないと判定し、以降のバッチ処理を続行し（Ｓ８０８）、図７の処理へリターンする。なお、ステップＳ８０８の処理は、図７のステップＳ１０８に対応する処理である。
【００８３】
ステップＳ８０７の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがある場合（Ｓ８０７→Ｙｅｓ）、リソース補正判定処理部１０３は、リソース補正を行なう必要があると判定し、割当てリソース算出処理部１０４を呼び出す（Ｓ８０９）。ステップＳ８０９で呼び出された割当てリソース算出処理部１０４の処理は図２８で後記する。
【００８４】
《中間処理進捗率管理テーブル》
図２７は、本実施形態に係る中間進捗率管理テーブルの例を示す図である。
中間処理進捗率管理テーブル１１２は、各バッチＡＰの中間処理の進捗率を管理するための属性情報として、契機、バッチアプリケーション名（バッチＡＰ名）、各々のバッチアプリケーションにおける稼働状態を示す稼働状態、各々のバッチアプリケーションの必要進捗率を示す必要進捗率、各々のバッチアプリケーションの処理進捗率を示す処理進捗率の各情報を有する。
【００８５】
《ステップＳ１０６，Ｓ１０７の詳細》
図２８は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図２８の処理は、主に割当てリソース算出処理部１０４が行なう処理である。
まず、リソース補正制御サーバ１は、図２６のステップＳ８０９のリソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４を起動し、起動された割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２(図２７）の必要進捗率と処理進捗率を基に、各バッチアプリケーションにおけるバッチ処理の遅延分の進捗率（以下、遅延回復対象進捗率と称する）を算出する（Ｓ９０１）。なお、割当てリソース算出処理部１０４は、以下の式（３）によって遅延回復対象進捗率を算出する。
【００８６】
遅延回復対象進捗率＝必要進捗率−処理進捗率  ・・・  （３）
【００８７】
そして、割当てリソース算出処理部１０４は、配備制御サーバ２のロット単位処理履歴管理テーブル２１５（図１８）を参照し、処理進捗率を得るために使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、ＣＰＵに割当てたリソース量を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、メモリに割当てたリソース量を示すＣＰＵ割当てを取得すると共に、中間処理単位データ管理テーブル１１１（図２５）の契機、バッチアプリケーション名（バッチＡＰ名）、稼働状態を取得し、さらに、リソース情報管理テーブル３１１からバッチアプリケーションの稼働状態を取得し、中間処理リソース割当て管理テーブル１１３（図２９）に登録することによって、中間処理リソース割当て管理テーブル１１３を作成する（Ｓ９０２）。
【００８８】
割当てリソース算出処理部１０４は、図２６のステップＳ８０７で検出された必要進捗率に達していないバッチアプリケーションに対し、ステップＳ９０１で算出した遅延回復対象進捗率と、今回の契機までの処理進捗率を得るために使用した各種リソース情報を基に、補充するリソースの種別、割当て量を算出する（Ｓ９０３）。ステップＳ９０３の詳細は、図３０〜図３３を参照して後記する。
【００８９】
次に、割当てリソース算出処理部１０４は、図３４に示すリソース割当て所要時間管理テーブル１１４を参照し、処理対象となっているバッチアプリケーションのリソース割当て所要時間を取得する（Ｓ９０４）。リソース割当て所要時間管理テーブル１１４については、図３４を参照して後記するが、図１０や、図２８におけるリソースの割り当てが実際に行なわれるたびに、リソース管理サーバ３のリソース割当て処理部３０３によって割当てリソース算出処理部１０４で登録されるテーブルである。
続いて、割当てリソース算出処理部１０４は、リソース割当て所要時間を考慮したリソース量を計算する（Ｓ９０５）。ステップＳ９０５の詳細も、図３０〜図３３を参照して後記する。なお、ステップＳ９０５の処理は図７のステップＳ１０６に含まれる処理である。また、ステップＳ９０５の結果、割当てが不可能であれば、割当てリソース算出処理部１０４は、クライアント端末６に対しエラー出力を行なう。
【００９０】
そして、割当てリソース算出処理部１０４は、リソース管理サーバ３に緊急運用リソース（予備）からリソースを補充するよう指示し、リソース管理サーバ３のリソース割当て処理部３０３がリソース情報管理テーブル３１１を参照し、緊急運用リソースからリソースを補充して（Ｓ９０６）、図２６の処理へリターンする。なお、ステップＳ９０６の処理は、図７のステップＳ１０７に対応する処理である。
【００９１】
《中間処理リソース割当て管理テーブル》
図２９は、本実施形態に係る中間処理リソース割当て管理テーブルの例を示す図である。
中間処理リソース割当て管理テーブル１１３は、ロット単位で使用してリソース情報を中間処理単位で使用してリソース情報に置き換えて管理するためのテーブルであり、管理する属性情報として、契機、バッチアプリケーション名（図２９では、バッチＡＰ名と表記）、稼働状態、中間処理単位で使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
なお、図２９の中間処理リソース割当て管理テーブル１１３では、ディスク種別やディスク割当ての属性情報が示されていないが、図９のリソース情報管理テーブル３１１の説明で補足した通り、ディスク種別やディスク割当ての情報が含まれていても構わない。
【００９２】
《リソース割当ての概念図》
次に、図３０〜図３３を参照して、第１実施形態に係るリソース割当ての概念を説明する。
図３０および図３１は、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）が稼働している状態における、契機毎のリソース割当ての例を示すものである。
ここで、図３０は、実行仮想サーバ５におけるバッチアプリケーションの推移を示す図であり、図３１は、中間処理リソース割当て管理テーブル１１３および中間処理進捗率管理テーブル１１２の推移を示す図である。
図３０では、横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
なお、図３０および図３１は、すべての時間で処理進捗率が必要進捗率と一致している場合である。
【００９３】
尚、図３１、図３３および後記する図３７では、煩雑になるのを防ぐため中間処理リソース割当て管理テーブル１１３の契機、ＣＰＵ種別、メモリ種別およびメモリ割当ての欄を省略し、バッチＡＰ名の欄は「ＡＰ」と記載し、稼働状態の欄は「状態」と省略している。同様に煩雑になるのを避けるため、中間処理進捗率管理テーブル１１２の契機の欄を省略し、バッチＡＰ名の欄「ＡＰ」と記載し、稼働状態の欄を「状態」と省略している。
また、バッチアプリケーション名も「ＡＰ１」、「ＡＰ２」、「ＡＰ３」と省略する。
【００９４】
図３１において「Ｔ０」の段階における中間処理リソース割当て管理テーブル１１３ａより、「バッチＡＰ２」および「バッチＡＰ３」の稼働状態が「準備中」であるため、すべてのリソースを「バッチＡＰ１」が占有できることを示している。
そして、リソース補正判定処理部１０３は、次の契機の「Ｔ０」の時点で算出された中間処理進捗率（必要進捗率および処理進捗率）を中間処理進捗割当て管理テーブル１１２ａとして登録する。同様にして、配備制御サーバ２は、「Ｔ１」以降の契機（「Ｔ１」〜「Ｔ４」）についても、中間処理リソース割当て管理テーブル１１３ｂ〜１１３ｅを参照して、稼働状態（「状態」）が実行中であるか否かを基に、バッチアプリケーションに対してリソースを割当て、リソース補正判定処理部１０３は処理結果に従って中間処理進捗率管理テーブル１１２ｂ〜１１２ｅの値を随時更新しながら、それぞれの実行仮想サーバ５はバッチ処理を継続する（図３０の「Ｔ２」〜Ｔ４」））。前記したように、図３０および図３１に示す例では、すべての契機（「Ｔ１」〜「Ｔ４」）で必要進捗率に処理進捗率が達しているので、予定通り処理が進行しており、新たなリソースの補充の必要がないことを示している。
なお、契機「Ｔ５」については、契機「Ｔ４」と同様のリソース状態となるため、図示することを省略する。
【００９５】
次に、図３２および図３３を参照して、処理に遅延が生じている場合のリソース補正について説明する。なお、図３２および図３３について、図３０および図３１と同様の要素については、同一の符号を付して説明を省略する。
図３２および図３３は、図３０および図３１と同様の図であるが、図３３の「Ｔ２」の段階で、「バッチＡＰ３」は、必要処理進捗率が５０％であるのに対し、処理進捗率が４０％までしか達しておらず、１０％分の処理遅延（遅延回復対象進捗率）が発生していることを示している（中間処理進捗率管理テーブル１１２ｆの符号３３０１）。「Ｔ２」時点の中間処理リソース割当て管理テーブル１１３ｃから、「バッチＡＰ３」に割当てられたＣＰＵは、１コアであったことが分かり、この状態で「Ｔ２」で４０％の処理進捗率を得ている。従って、割当てリソース算出処理部１０４は、もう１コア追加することで１０％分の処理遅延を埋めることができると判定する。さらに、割当てリソース算出処理部１０４はリソース割当てに必要な時間であるリソース割当て所要時間を考慮してリソース量を計算する（図２８のステップＳ９０５）。
【００９６】
この処理は、例えば、以下のように行なわれる。
次の契機「Ｔ３」は、未来の時間であり、何時間後にＴ３となるのかをリソース補正制御サーバ１は知ることができないので、「Ｔ２」後、「Ｔ２」−「Ｔ１」時間後に次の契機「Ｔ３」となると仮定してリソース補正制御サーバ１は計算する。
つまり、「Ｔ１」→「Ｔ２」が仮に１時間であったとすると、「Ｔ２」から１時間後に「Ｔ３」となると仮定することになる。
【００９７】
中間処理進捗率管理テーブル１１２ｂ，１１２ｆから、バッチアプリケーション「ＡＰ３」は、１時間で４０％の処理進捗率であるので、１つの実行仮想サーバ４は、次の契機「Ｔ３」の１時間で４０％の処理進捗率を得ることができることになる。
図３２の「Ｔ２」に示すように「バッチＡＰ３（ＡＰ３）」を実行する実行仮想サーバ３２０１を増やすことで、２つの実行仮想サーバ４で「バッチＡＰ３」を実行することになる（中間処理リソース割当て管理テーブル１１３ｆの符号３３０２）。すると、次の１時間では８０％と２倍の処理進捗率を得ることとなる。従って、「バッチＡＰ３」が完了する時間は、「Ｔ２」後、（６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間が、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。処理進捗率１００％を達成することができないと判定された場合、緊急運用リソース(予備）に余裕があれば、割当てリソース算出処理部１０４は、さらに実行仮想サーバ４を増やして、再度計算してもよいし、緊急運用リソース(予備）に余裕がなければ、クライアント端末６に対してエラー出力を行なう。
【００９８】
次の契機の「Ｔ３」までに処理進捗率１００％を達成することができれば、割当てリソース算出処理部１０４は、リソース管理サーバ３へリソース割当てを指示し、リソース管理サーバ３のリソース割当て処理部３０３は、緊急運用リソース(予備）から１コア分のリソースを確保して、新たに「バッチＡＰ３」を実行する実行仮想サーバ３２０１を起動する(図２８のステップＳ９０６）。この結果、図３３より「Ｔ３」の段階では、処理進捗率が必要進捗率に追いついて１００％に達し、要求処理時間内にバッチ処理を終了させることに成功している。さらに、「バッチＡＰ１」は、「Ｔ３」において処理進捗率、必要進捗率共に８０％であるため、「バッチＡＰ１」については新たなリソースが必要なわけではないため、実行仮想サーバ３２０１は、「バッチＡＰ３」の終了後、割当てリソース算出処理部１０４によって解放され緊急運用リソース上にプールされる。
【００９９】
ここでは、契機「Ｔ３」直後に要求処理時間がくることを想定しているが、例えば、要求処理時間が「Ｔ２」後、２時間後であれば、割当てリソース算出処理部１０４は、前記したように「Ｔ３」が「Ｔ２」後、１時間後であると仮定して、その時点の必要進捗率および処理進捗率を計算した上で、「Ｔ３」での進捗率が必要進捗率に達するか否かを判定してもよい。
また、実行仮想サーバ５に性能差がある場合は、各実行仮想サーバ５の性能を考慮してもよい。
【０１００】
なお、また、図３０〜図３３では、ＣＰＵ割当てを基に、リソース割当ての要・不要を判定しているが、同様にして、メモリやディスクなどのリソースを基にリソース割当ての要・不要を判定してよい。さらに、図３３では、割当てるＣＰＵのコア数を例に説明したが、割当てるリソース量の他に、ＣＰＵ種別やメモリ種別などのスペック名称を考慮に入れた割当てを行なうものとしても構わない。
【０１０１】
《リソース割当て所要時間履歴管理テーブル》
図３４は、本実施形態に係るリソース割当て所要時間管理テーブルの例を示す図である。
リソース割当て所要時間管理テーブル１１４は、リソースの割当てや切離しにかかる時間の履歴を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、該当する実行仮想サーバ５が実行されている実行物理サーバ５のＣＰＵのスペック名称を示すＣＰＵ種別、割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別の各情報を有している。リソース割当て所要時間管理テーブル１１４は、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、リソース割当てにかかる時間を示す割当て所要時間、リソース切離しかかる時間を示す切離し所要時間の各情報をさらに有する。なお、リソース割当て所要時間管理テーブル１１４では、ディスク種別やディスク割当ての属性情報が示されていないが、含まれていても構わない。さらに、各仮想サーバに配備するバッチアプリケーションの配備時間も併せて管理して、算出の際に考慮するものとしても構わない。
【０１０２】
［第２実施形態］
次に、図３５〜図３７を参照して、本発明の第２実施形態について説明する。
第１実施形態では、リソース補正制御サーバ１上で稼働する割当てリソース算出処理部１０４は、必要進捗率に達していない（処理遅延が生じている）バッチアプリケーションに対し、緊急運用リソースから新たに補充するリソースと割当て量を算出し、割当てを行なうものであったが、第２実施形態においては、通常運用リソース上で稼働するバッチアプリケーションから処理進捗率に余裕があるバッチアプリケーションを割り出し、必要進捗率に達していないバッチアプリケーションと置換するものである。
【０１０３】
《ステップＳ１０６，Ｓ１０７の詳細》
図３５は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図３５の処理は、主に割当てリソース算出処理部１０４が行なう処理であり、第１実施形態の図２８の処理に対応する処理である。
リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２の終了メッセージを検知し、割当てリソース算出処理部１０４を起動し、起動した割当てリソース算出処理部１０４が算出した必要進捗率と処理進捗率の差分(式（３））を算出する（Ｓ１００１）ことにより、遅延回復対象進捗率を算出する。図２８のステップＳ９０１では、リソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４が起動しているが、第２実施形態では、図２６のステップＳ８０９において、中間処理単位データ取得処理部１０２が発した終了メッセージを基に、割当てリソース算出処理部１０４が起動している。
【０１０４】
次に、割当てリソース算出処理部１０４は、図２８のステップＳ９０２と同様に、アプリケーション配備制御サーバ２上の図１８に示すロット単位処理履歴管理テーブル２１５を参照し、処理進捗率の算出対象となっている（すなわち、バッチアプリケーションの置換対象となっている）実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、ＣＰＵに割当てたリソース量を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、メモリに割当てたリソース量を示すＣＰＵ割当てを取得すると共に、中間処理単位データ管理テーブル１１１（図２５）の契機、バッチアプリケーション名（バッチＡＰ名）、稼働状態を取得し、さらに、リソース情報管理テーブル３１１からバッチアプリケーションの稼働状態を取得し、（図２９）に登録することによって、中間処理リソース割当て管理テーブル１１３を作成する（Ｓ１００２）。
【０１０５】
続いて、割当てリソース算出処理部１０４は、図２６のステップＳ８０７で検出された必要進捗率に達していないバッチアプリケーションに対し、ステップＳ１００１で算出した必要進捗率と処理進捗率の差分の値（遅延回復対象進捗率）と、今回の処理進捗率を得るために使用した各種リソースの種別、割当て量を基に、切離し可能な余剰リソースと補充リソースの量を算出する（Ｓ１００３）。ステップＳ１００３の詳細は、図３６および図３７を参照して後記する。
そして、割当てリソース算出処理部１０４は、図３４に示すリソース割当て所要時間履歴管理テーブル２４００を参照し、処理対象となっているバッチアプリケーションのリソース割当てにかかる時間（割当て所要時間）と切離しにかかる時間(切離し所要時間）を取得する（Ｓ１００４）。
【０１０６】
続いて、割当てリソース算出処理部１０４は、割当て所要時間と切離し所要時間を考慮したリソース量を計算する（Ｓ１００５）。ステップＳ１００５の詳細も、図３６〜図３７を参照して後記する。なお、ステップＳ１００５の処理は図７のステップＳ１０６に対応する処理である。
そして、割当てリソース算出処理部１０４は、通常運用リソース上で稼働する余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、遅延回復が必要なバッチアプリケーション（バッチＡＰ）にリソースを補充するよう指示し、リソース管理サーバ３のリソース割当て処理部３０３がリソース情報管理テーブル３１１を参照し、余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、緊急運用リソースからリソースを補充して（Ｓ１００６）、図２６の処理へリターンする。なお、ステップＳ１００７の処理は、図７のステップＳ１０８に対応する処理である。
【０１０７】
《リソース割当ての概念図》
次に、図３６および図３７を参照して、第２実施形態に係るリソース割当ての概念を説明する。
図３６および図３７は、通常運用リソース上から余剰リソースを捻出して、遅延が発生しているバッチアプリケーションにリソース割当てを行なう流れを示す概念図である。なお、図３６および図３７において、図３０〜図３３と同様の要素については、同一の符号を付して説明を省略する。
図３６および図３７では、、図３０〜図３３と同様に、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）を稼働している状態における、契機毎のリソース割当てを示すものである。
また、図３６では、図３０と同様に横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
【０１０８】
ここで、図３３で示した例と同様にして、「Ｔ２」の段階で、「バッチＡＰ３（ＡＰ３）」は、必要処理進捗率が５０％であるのに対し、処理進捗率が４０％までしか達しておらず、１０％分の処理遅延（遅延回復対象進捗率）が発生しているものとする（中間処理進捗率管理テーブル１１２ｇの符号３７０１）。「Ｔ２」で処理進捗率４０％を得るために使用したリソースは、「Ｔ２」時点の中間処理リソース割当て管理テーブル１１３より、１コア分のＣＰＵ割当てであったことが分かり、１０％分の遅延回復に必要な補充リソース量は、１コア分のＣＰＵ割当てである。
【０１０９】
一方で、切離し可能な余剰リソースの算出については、「Ｔ２」の段階で、「バッチＡＰ１（ＡＰ１）」は、必要処理進捗率が５０％であるのに対し、処理進捗率が６６％まで達しており、１６％分の余裕があることが分かる（中間処理進捗率管理テーブル１１２ｈの符号３７０２）。さらに、「バッチＡＰ１」は、「Ｔ１」の中間処理進捗率管理テーブル１１２ｂと「Ｔ２」の中間処理リソース割当て管理テーブル１１３ｃから、２コアのＣＰＵ割当てで、３０％から６６％の進捗率を得ており、１コアのＣＰＵ割当てで（６６−３０）／２＝１８％の進捗を得られていることが分かる（中間処理進捗率管理テーブル１１２ｇの符号３７０２）。従って、「Ｔ２」の段階で、「バッチＡＰ１」は、１８％分上回っている進捗率に該当するリソース、つまり切離し可能な余剰リソースは、１コア分のＣＰＵ割当てである。
【０１１０】
従って、「Ｔ３」の段階で、「バッチＡＰ３」の処理遅延の回復に必要なリソースを、「バッチＡＰ１」から１コア分のＣＰＵ（図３６の実行仮想サーバ３６０１）を切り離して、「バッチＡＰ３」に割当てることで、通常運用リソース上でリソース融通することが可能になる（図３６）。つまり、実行仮想サーバ３６０１で実行されているバッチアプリケーションを「バッチＡＰ１」から「バッチＡＰ３」に置換する。
なお、融通可能なリソースがない場合は、第１実施形態と同様の処理を行なうことで緊急リソースから融通することとなる。
【０１１１】
以下、図３７を参照して、具体的なリソース割当てを説明する。
まず、割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２ｇから「バッチＡＰ３（ＡＰ３）」の処理遅延が１０％であり、「バッチＡＰ１（ＡＰ１）」の処理進捗率に１６％の余裕があるので、「バッチＡＰ１」→「バッチＡＰ３」の置換を試みる。
【０１１２】
そして、割当てリソース算出処理部１０４は以下の手順で、「バッチＡＰ１」→「バッチＡＰ３」の置換を行なっても、「バッチＡＰ１」、「バッチＡＰ３」共に要求処理時間を満たすことができるか否かを判定する。なお、第１実施形態と同様に「Ｔ１」から「Ｔ２」の間は１時間であるとする。
【０１１３】
また、「バッチＡＰ１（ＡＰ１）」は、ＣＰＵ２コアを使用して「Ｔ１」から「Ｔ２」にかけて６６−３０＝３６％の処理進捗率を得ているので、１コアで１８％の進捗率を得ていると、割当てリソース算出処理部１０４は判定する。
そして、割当てリソース算出処理部１０４は、「バッチＡＰ１」を１コアに減じても、要求処理時間を満たすことができるか否かを判定する。
第１実施形態で前記したように、リソース補正制御サーバ１は未来の契機である「Ｔ３」がいつになるのかを知ることができないため、割当てリソース算出処理部１０４は、「Ｔ２」後、「Ｔ２」−「Ｔ１」で「Ｔ３」となると仮定する。
【０１１４】
「バッチＡＰ１」は、「Ｔ１」→「Ｔ２」で１コアあたり１８％の処理進捗率を得ているので、「Ｔ３」の時点では６６＋１８＝８４％の処理進捗率を得られると、割当てリソース算出処理部１０４は算出する。また、必要進捗率は、「Ｔ１」の時点で３０％であり、「Ｔ２」の時点で５０％であるので、同じ割合で必要進捗率が進むと仮定し、「Ｔ３」では、７０％の必要進捗率となると割当てリソース算出処理部１０４は算出する。
従って、「バッチＡＰ１」は、ＣＰＵを１コアに減じても、「Ｔ３」の時点で、なお８４％−７０％＝１４％の余裕があるため、「バッチＡＰ１」に関しては、ＣＰＵを１コアに減じても要求処理時間を満たすことができると、割当てリソース算出処理部１０４は判定する。
【０１１５】
なお、「Ｔ２」→「Ｔ３」で「バッチＡＰ１」を「バッチＡＰ３」に置換される実行仮想サーバ５は、既に起動されているものであるので、割当て所要時間や、切離し所要時間を考慮することはない。また、置換される実行仮想サーバ５は、「バッチＡＰ１」を実行している実行仮想サーバ５であれば、どれでもよいが、リソース管理サーバ３のリソース割当て処理部３０３は、付されている番号の若い順に選択したり、実行仮想サーバ５間に性能差が存在する場合は、一番性能の低い実行仮想サーバ５を選択したりする。
【０１１６】
一方、「バッチＡＰ３」は、第１実施形態と同様に、「Ｔ１」→「Ｔ２」の間で４０％の処理進捗率を得ているため、「Ｔ２」→「Ｔ３」ではＣＰＵが２コアになることにより、４０×２＝８０％の処理進捗率を得ることができると、割当てリソース算出処理部１０４は判定する。
つまり、「Ｔ３」の時点の処理進捗率は、４０％（「Ｔ２」の時点の処理進捗率）＋８０％＝１２０％となり、２０％の余裕が発生する。
実際に、ＣＰＵのコア数を２倍にしたとき、すなわち、「バッチＡＰ３」を実行する実行仮想サーバ５の数を２倍にしたとき、処理進捗率が１００％となるのは、「Ｔ２」後、何分であるかを計算すると、６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間と、リソース切離し所要時間を加算したものが、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。
【０１１７】
《まとめ》
本実施形態によれば、複数のバッチアプリケーションが共存する環境下において、実行中のバッチ処理に処理遅延が発生した場合であっても、中間処理履歴より、処理遅延の回復に必要なリソースを同定し、拡充することで、次の分割単位から拡充したリソース上でバッチ処理を実行することができるため、個々のバッチ処理の要求処理時間（ＳＬＡ）を遵守する確度を高めることができる。また、要求処理時間遵守のために必要な実行中のバッチ処理の進捗率の検査や、割当てリソースの見直しを必要最小限に抑えることでバッチ処理のスループット低下を防止することも併せて実現することができる。さらに、中間処理履歴から算出した処理進捗率を基に、処理に余裕のあるバッチ処理のリソースを、遅延が発生しているバッチ処理に融通することができ、システム全体のリソースを有効活用することもできるようになる。
【符号の説明】
【０１１８】
１      リソース補正制御サーバ（リソース管理装置）
２      配備制御サーバ
３      リソース管理サーバ
４      実行物理サーバ
５      実行仮想サーバ
６      クライアント装置
１０    計算機システム
１０１  再検査契機取得処理部
１０２  中間処理単位データ取得処理部
１０３  リソース補正判定処理部
１０４  割当てリソース算出処理部
１１１  中間処理単位データ管理テーブル
１１２  中間処理進捗率管理テーブル
１１３  中間処理リソース割当て管理テーブル
１１４  リソース割当て所要時間管理テーブル
２０１  ＳＬＡ情報管理部
２０２  配備アプリケーション情報管理部
２０３  アプリケーション・データ配備処理部
２１１  ＳＬＡ情報管理テーブル
２１２  処理対象データ管理テーブル
２１３  配備アプリケーション管理テーブル
２１４  バッチ単位処理履歴管理テーブル
２１５  ロット単位処理履歴管理テーブル
２１５ａ，２１６ａ  バッチアプリケーション毎ロット単位処理履歴管理テーブル
３０１  リソース情報管理部
３０２  アプリケーション構成情報管理部
３０３  リソース割当て処理部
３１１  リソース情報管理テーブル
３１２  仮想マシンイメージ管理領域
５０１  バッチアプリケーションプログラム
【図１】
2011142031.tif 000003
【図２】
2011142031.tif 000004
【図３】
2011142031.tif 000005
【図４】
2011142031.tif 000006
【図５】
2011142031.tif 000007
【図６】
2011142031.tif 000008
【図７】
2011142031.tif 000009
【図８】
2011142031.tif 000010
【図９】
2011142031.tif 000011
【図１０】
2011142031.tif 000012
【図１１】
2011142031.tif 000013
【図１２】
2011142031.tif 000014
【図１３】
2011142031.tif 000015
【図１４】
2011142031.tif 000016
【図１５】
2011142031.tif 000017
【図１６】
2011142031.tif 000018
【図１７】
2011142031.tif 000019
【図１８】
2011142031.tif 000020
【図１９】
2011142031.tif 000021
【図２０】
2011142031.tif 000022
【図２１】
2011142031.tif 000023
【図２２】
2011142031.tif 000024
【図２３】
2011142031.tif 000025
【図２４】
2011142031.tif 000026
【図２５】
2011142031.tif 000027
【図２６】
2011142031.tif 000028
【図２７】
2011142031.tif 000029
【図２８】
2011142031.tif 000030
【図２９】
2011142031.tif 000031
【図３０】
2011142031.tif 000032
【図３１】
2011142031.tif 000033
【図３２】
2011142031.tif 000034
【図３３】
2011142031.tif 000035
【図３４】
2011142031.tif 000036
【図３５】
2011142031.tif 000037
【図３６】
2011142031.tif 000038
【図３７】
2011142031.tif 000039
【国際調査報告】
2011142031.tif 000040
2011142031.tif 000041