JPWO2011142031A1 - リソース管理方法、リソース管理装置およびプログラム - Google Patents
リソース管理方法、リソース管理装置およびプログラム Download PDFInfo
- Publication number
- JPWO2011142031A1 JPWO2011142031A1 JP2012514658A JP2012514658A JPWO2011142031A1 JP WO2011142031 A1 JPWO2011142031 A1 JP WO2011142031A1 JP 2012514658 A JP2012514658 A JP 2012514658A JP 2012514658 A JP2012514658 A JP 2012514658A JP WO2011142031 A1 JPWO2011142031 A1 JP WO2011142031A1
- Authority
- JP
- Japan
- Prior art keywords
- processing
- resource
- progress rate
- batch
- processing unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
- G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Debugging And Monitoring (AREA)
Abstract
個々のバッチジョブの要求処理時間を遵守する。バッチアプリケーションの配置に必要なリソースの計算を行なうリソース補正制御サーバ（１）であって、所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群を中間処理単位とする中間処理単位データ取得処理部（１０２）と、前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部（１０３）と、前記判定の結果、前記必要な進捗率に達していない場合、遅延回復対象進捗率と、リソースの情報と、を基に、遅延回復に必要なリソースを算出する割当てリソース算出処理部（１０４）と、を有することを特徴とする。
Description
本発明は、リソース管理方法、リソース管理装置およびプログラムの技術に関する。
近年、インターネット技術や仮想化技術の進展に伴い、企業や個人などのユーザに対して、インターネット経由でコンピュータリソースやアプリケーションサービスを提供し、使用したリソース量やサービスに応じて課金を行なうクラウドコンピューティングの利用が広まりつつある。従来のコンピュータ利用は、ユーザがコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは、設備に対する投資や調達にかかる時間を削減することが可能になるため、企業の間での利用事例も出始めつつある。
企業内の利用ケースの一つとして、企業における売上データや受注データの集計処理など、一定期間ごとに大量のデータを集めて一括処理するバッチ処理がある。バッチ処理には、要求処理時間（ＳＬＡ：Service Level Agreement）が存在するのが一般的である。バッチ処理は、処理するデータや処理内容によって、一定期間の間に集中的にコンピュータリソースを使用するという特徴があるため、使用したリソース量に応じて課金するクラウドコンピューティングの利用形態に対する適合性が高いと考えられている。そのため、データに対するセキュリティ確保などの懸案は残るものの、今後、ユーザによる利用は広がっていくものと予想されている。
一方で、クラウドコンピューティングのサービスを提供する事業者側は、複数のユーザ企業からのサービス要求に対して、有限のコンピュータリソースで応えていく必要がある。複数のユーザ企業からのバッチ処理を受け持つクラウドサービスを考えた場合、有限のコンピュータリソースをいかに有効活用して、ユーザ企業毎の個別の要求処理時間を遵守するかということが重要なポイントになる。
このような状況下において、バッチ処理の要求処理時間の遵守を実現するための技術として、予め割当てたコンピュータリソース上で部分的なバッチ処理を所定時間行ない、その結果から進捗率を計算して、要求処理時間を遵守できないと推定した場合、コンピュータリソースを追加することで要求処理時間を遵守するジョブ実行方法、ジョブ実行システムおよびジョブ実行プログラムが開示されている（例えば、特許文献１参照）。
特許文献１に記載の技術を用いることにより、予め割当てたコンピュータリソースでは、要求処理時間を遵守できないと推定した場合、要求処理時間を遵守できるまでコンピュータリソースを追加することで、要求処理時間を遵守することができるようになる。しかしながら、有限のコンピュータリソースの有効活用という観点では、必ずしも十分とは言えない場合がある。例えば、特許文献１に記載の技術では、該当バッチアプリケーションにコンピュータリソースを追加した後、リソース割当ては固定になる。このため、複数のバッチアプリケーションが共存して稼働することを想定した場合、該当するバッチアプリケーションの実行中に、別のバッチアプリケーションの開始や終了などによるリソース使用状況の変化、あるいは、別のバッチアプリケーションの処理遅延などを含めた、動的なコンピュータリソースの割当てを行なうことは困難である。
また、バッチ処理の進捗率を計算して、コンピュータリソースの追加の再計算を行なうこと自体の処理にコストがかかるため、頻繁に行なうと、バッチ処理のスループットに影響を及ぼす可能性がある。
従って、コンピュータリソースの有効活用と個別のバッチアプリケーションの要求終了時間遵守の両立を目的としたバッチアプリケーションシステムにおいては、複数のバッチアプリケーションが共存して稼働する環境下において、該当バッチアプリケーションの実行中に、コンピュータリソースの使用状況の変動や別のバッチアプリケーションの処理遅延が発生した場合であっても、コンピュータリソースを有効活用しつつ、個々のバッチアプリケーションの要求処理時間を遵守できるようにする必要がある。要求処理時間を遵守するためには、実行中のバッチアプリケーションの中間処理履歴を利用して算出した進捗率からバッチアプリケーションに割り当てたリソースを見直すことが考えられるが、リソース割当ての見直しを頻繁に行なうことによってスループット低下を招く可能性がある。従って、スループット低下を防ぎながら、個々のバッチジョブの要求処理時間を遵守するためには、必要最小限の再検査の契機の取得と、その契機を境にした中間処理履歴を取得するためのデータ分割の実現が課題となる。
このような背景に鑑みて本発明がなされたのであり、本発明は、個々のバッチジョブの要求処理時間を遵守するリソース管理方法、リソース管理装置およびプログラムを提供することを目的とする。
前記課題を解決するため、本発明は、バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置におけるリソース管理方法であって、前記リソース管理装置は、所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめ、前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定し、前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出することを特徴とする。
その他の解決手段については、実施形態中において記載する。
その他の解決手段については、実施形態中において記載する。
本発明によれば、個々のバッチジョブの要求処理時間を遵守するリソース管理方法、リソース管理装置およびプログラムを提供することができる。
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
［第１実施形態］
まず、図１〜図３４を参照して、本発明の第１実施形態に係る説明を行なう。なお、図１〜図６までがシステムおよび装置の構成を説明するための図であり、図７〜図１９までがリソース補正のための各情報を収集する処理を説明するための図であり、図２０から図３４までがリソース補正に係る処理を説明するための図である。
《システム構成》
図１は、本実施形態に係る計算機システムの構成例を示す図である。
計算機システム１０は、複数の実行物理サーバ４、クライアント装置６、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ（リソース管理装置）１がネットワーク７を介して互いに接続されている。なお、ネットワーク７は、ＬＡＮ（Local Area Network）や、ＷＡＮ（Wide Area Network）や、インターネットなどのグローバルネットワークである。また、ネットワーク７は、複数のネットワーク７に分けられてもよい。
ここで、実行物理サーバ４は、バッチアプリケーションを実行する複数の実行仮想サーバ５から構成されている。
まず、図１〜図３４を参照して、本発明の第１実施形態に係る説明を行なう。なお、図１〜図６までがシステムおよび装置の構成を説明するための図であり、図７〜図１９までがリソース補正のための各情報を収集する処理を説明するための図であり、図２０から図３４までがリソース補正に係る処理を説明するための図である。
《システム構成》
図１は、本実施形態に係る計算機システムの構成例を示す図である。
計算機システム１０は、複数の実行物理サーバ４、クライアント装置６、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ（リソース管理装置）１がネットワーク７を介して互いに接続されている。なお、ネットワーク７は、ＬＡＮ（Local Area Network）や、ＷＡＮ（Wide Area Network）や、インターネットなどのグローバルネットワークである。また、ネットワーク７は、複数のネットワーク７に分けられてもよい。
ここで、実行物理サーバ４は、バッチアプリケーションを実行する複数の実行仮想サーバ５から構成されている。
次に、図１を参照しつつ、図２〜図６に沿って、計算機システム１０を構成する各装置１〜４の説明を行なう。
《実行仮想サーバ》
図２は、本実施形態に係る実行仮想サーバの構成例を示す機能ブロック図である。
実行仮想サーバ５は、二次記憶装置５１０、ＣＰＵ（Central Processing Unit）５２０、主記憶装置５００およびネットワークインタフェース５３０がバスによって互いに接続されてなる。
なお、実行仮想サーバ５が備える各種機器５００，５１０，５２０，５３０は、実行物理サーバ４が備える各種機器の一部を仮想的に割り当てたものである。
《実行仮想サーバ》
図２は、本実施形態に係る実行仮想サーバの構成例を示す機能ブロック図である。
実行仮想サーバ５は、二次記憶装置５１０、ＣＰＵ（Central Processing Unit）５２０、主記憶装置５００およびネットワークインタフェース５３０がバスによって互いに接続されてなる。
なお、実行仮想サーバ５が備える各種機器５００，５１０，５２０，５３０は、実行物理サーバ４が備える各種機器の一部を仮想的に割り当てたものである。
ネットワークインタフェース５３０は、実行仮想サーバ５がネットワーク７に接続するためのインタフェースである。ＣＰＵ５２０は、二次記憶装置５１０から主記憶装置５００にロードされたプログラムを実行する演算処理装置である。主記憶装置５００は、ＣＰＵ５２０によって実行されるプログラムおよびプログラムの実行に必要なデータを二次記憶装置５１０からロードするＲＡＭ（Random Access Memory）などの記憶装置である。プログラムとは、例えば、バッチ処理のロジックが記述され、ＣＰＵ５２０によって実行されることによりバッチアプリケーションとなるバッチＡＰ（Application）プログラム５０１などがあるが、不図示のＯＳ（Operating System）なども含まれる。二次記憶装置５１０は、バッチＡＰプログラム５０１が使用するバッチＡＰデータ５１１（以下、適宜データと記載）を格納するハードディスク装置などの磁気記憶媒体である。なお、二次記憶装置５１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。バッチＡＰデータ５１１の格納形態は限定されるものではないが、ファイル形式やＲＤＢ（Relational Database）などの形態で格納されるのが一般的である。なお、バッチＡＰデータ５１１は、主記憶装置５００上に格納されていても構わない。
《クライアント端末》
図３は、本実施形態に係るクライアント端末の構成例を示す機能ブロック図である。
クライアント装置６は、二次記憶装置６１０、ＣＰＵ６２０、主記憶装置６００およびネットワークインタフェース６３０がバスによって互いに接続されてなる。
ネットワークインタフェース６３０は、クライアント装置６がネットワーク７に接続するためのインタフェースである。ＣＰＵ６２０は、主記憶装置６００に記憶されているプログラムを実行することによってクライアント装置６の所定の機能を実現する演算処理装置である。主記憶装置６００は、ＣＰＵ６２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
図３は、本実施形態に係るクライアント端末の構成例を示す機能ブロック図である。
クライアント装置６は、二次記憶装置６１０、ＣＰＵ６２０、主記憶装置６００およびネットワークインタフェース６３０がバスによって互いに接続されてなる。
ネットワークインタフェース６３０は、クライアント装置６がネットワーク７に接続するためのインタフェースである。ＣＰＵ６２０は、主記憶装置６００に記憶されているプログラムを実行することによってクライアント装置６の所定の機能を実現する演算処理装置である。主記憶装置６００は、ＣＰＵ６２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
ここで、プログラムとは、例えば、クライアント端末６が、不図示のＯＳ、ユーザからの実行要求の送信などクライアント装置６の所定の機能を実現するためのクライアント処理プログラム６０１などである。二次記憶装置６１０は、クライアント処理プログラム６０１が使用するクライアント処理データ６１１を格納するハードディスク装置などの磁気記憶媒体である。なお、二次記憶装置６１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
《リソース管理サーバ》
図４は、本実施形態に係るリソース管理サーバの構成例を示す機能ブロック図である。
リソース管理サーバ３は、実行物理サーバ４のリソースを管理するためのサーバであり、二次記憶装置３１０、ＣＰＵ３２０、主記憶装置３００およびネットワークインタフェース３３０がバスによって互いに接続されてなる。
二次記憶装置３１０は、リソース管理サーバ３がネットワーク７に接続するためのインタフェースである。ＣＰＵ３２０は、主記憶装置３００に記憶されているプログラムを実行することによってリソース管理サーバ３の所定の機能を実現する演算処理装置である。主記憶装置３００は、ＣＰＵ３２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
図４は、本実施形態に係るリソース管理サーバの構成例を示す機能ブロック図である。
リソース管理サーバ３は、実行物理サーバ４のリソースを管理するためのサーバであり、二次記憶装置３１０、ＣＰＵ３２０、主記憶装置３００およびネットワークインタフェース３３０がバスによって互いに接続されてなる。
二次記憶装置３１０は、リソース管理サーバ３がネットワーク７に接続するためのインタフェースである。ＣＰＵ３２０は、主記憶装置３００に記憶されているプログラムを実行することによってリソース管理サーバ３の所定の機能を実現する演算処理装置である。主記憶装置３００は、ＣＰＵ３２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
ここで、プログラムとは、例えば、リソース管理サーバ３が、不図示のＯＳ、リソース情報管理部３０１、アプリケーション構成情報管理部３０２およびリソース割当て処理部３０３の機能を実現するためのプログラムである。二次記憶装置３１０は、リソース管理サーバ３が各部３０１〜３０３の機能を実現するために必要なプログラムおよびリソース情報管理テーブル３１１、仮想マシンイメージである仮想マシンイメージ管理領域３１２を格納するハードディスク装置などの磁気記憶媒体である。リソース情報管理テーブル３１１は後記して説明する。なお、二次記憶装置３１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
なお、各部３０１〜３０３の機能については、処理の説明において後記する。
なお、各部３０１〜３０３の機能については、処理の説明において後記する。
《配備制御サーバ》
図５は、本実施形態に係る配備制御サーバの構成例を示す機能ブロック図である。
配備制御サーバ２は、実行物理サーバ５に実行仮想サーバ４を配備するためのサーバであり、二次記憶装置２１０、ＣＰＵ２２０、主記憶装置２００およびネットワークインタフェース２３０がバスによって互いに接続されてなる。
ネットワークインタフェース２３０は、配備制御サーバ２がネットワーク７に接続するためのインタフェースである。ＣＰＵ２２０は、主記憶装置２００に記憶されているプログラムを実行することによってアプリケーション配備制御サーバ２の所定の機能を実現する演算処理装置である。主記憶装置２００は、ＣＰＵ２２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
図５は、本実施形態に係る配備制御サーバの構成例を示す機能ブロック図である。
配備制御サーバ２は、実行物理サーバ５に実行仮想サーバ４を配備するためのサーバであり、二次記憶装置２１０、ＣＰＵ２２０、主記憶装置２００およびネットワークインタフェース２３０がバスによって互いに接続されてなる。
ネットワークインタフェース２３０は、配備制御サーバ２がネットワーク７に接続するためのインタフェースである。ＣＰＵ２２０は、主記憶装置２００に記憶されているプログラムを実行することによってアプリケーション配備制御サーバ２の所定の機能を実現する演算処理装置である。主記憶装置２００は、ＣＰＵ２２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
ここで、プログラムとは、例えば、配備制御サーバ２が、不図示のＯＳ、ＳＬＡ（要求処理時間）情報管理部２０１、配備アプリケーション情報管理部２０２およびアプリケーション・データ配備処理部２０３の機能を実現するためのプログラムなどである。二次記憶装置２１０は、配備制御サーバ２が各部２０１〜２０３の機能を実現するために必要なプログラム、ＳＬＡ情報管理テーブル２１１、処理対象データ管理テーブル２１２、配備アプリケーション管理テーブル２１３、バッチ単位処理履歴管理テーブル２１４およびロット単位処理履歴管理テーブル２１５などの各データを格納するハードディスク装置などの磁気記憶媒体である。配備アプリケーション管理テーブル２１３、バッチ単位処理履歴管理テーブル２１４およびロット単位処理履歴管理テーブル２１５は後記して説明する。なお、二次記憶装置２１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。なお、ロット単位処理履歴管理テーブル２１５には、図１６および図１７で後記するバッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂも含まれている。
なお、各部２０１〜２０３の機能については、処理の説明において後記する。
なお、各部２０１〜２０３の機能については、処理の説明において後記する。
《リソース補正制御サーバ》
図６は本実施形態に係るリソース補正制御サーバの構成例を示す機能ブロック図である。
リソース補正制御サーバ１は、後記して説明する再検査の契機で、リソースの割当て補正を行なう装置であり、二次記憶装置１１０、ＣＰＵ１２０、主記憶装置１００およびネットワークインタフェース１３０がバスによって互いに接続されてなる。
ネットワークインタフェース１３０は、リソース補正制御サーバ１がネットワーク７に接続するためのインタフェースである。ＣＰＵ１２０は、主記憶装置１００に記憶されているプログラムを実行することによってリソース補正制御サーバ１の所定の機能を実現する演算処理装置である。主記憶装置１００は、ＣＰＵ１２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
図６は本実施形態に係るリソース補正制御サーバの構成例を示す機能ブロック図である。
リソース補正制御サーバ１は、後記して説明する再検査の契機で、リソースの割当て補正を行なう装置であり、二次記憶装置１１０、ＣＰＵ１２０、主記憶装置１００およびネットワークインタフェース１３０がバスによって互いに接続されてなる。
ネットワークインタフェース１３０は、リソース補正制御サーバ１がネットワーク７に接続するためのインタフェースである。ＣＰＵ１２０は、主記憶装置１００に記憶されているプログラムを実行することによってリソース補正制御サーバ１の所定の機能を実現する演算処理装置である。主記憶装置１００は、ＣＰＵ１２０によって実行されるプログラムおよびプログラムの実行に必要なデータをロードし、記憶するＲＡＭなどの記憶装置である。
ここで、プログラムとは、例えば、リソース補正制御サーバ１が、不図示のＯＳ、再検査契機取得処理部１０１、中間処理単位データ取得処理部１０２、リソース補正判定処理部１０３および割当てリソース算出処理部１０４の機能を実現するためのプログラムなどである。二次記憶装置１１０は、リソース補正制御サーバ１が各部１０１〜１０４の機能を実現するために必要なプログラム、中間処理単位データ管理テーブル１１１、中間処理進捗率管理テーブル１１２、中間処理リソース割当て管理テーブル１１３およびリソース割当て所要時間管理テーブル１１４の各データを格納するハードディスク装置などの磁気記憶媒体である。中間処理単位データ管理テーブル１１１、中間処理進捗率管理テーブル１１２、中間処理リソース割当て管理テーブル１１３およびリソース割当て所要時間管理テーブル１１４は後記して説明する。なお、二次記憶装置１１０は、フラッシュメモリなどの半導体記憶媒体であってもよい。
なお、各部１０１〜１０４の機能については、処理の説明において後記する。
なお、各部１０１〜１０４の機能については、処理の説明において後記する。
以上、各装置のハードウェア構成およびソフトウェア構成について説明してきたが、実行物理サーバ４、実行仮想サーバ５、クライアント装置６、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ１の構成は、図１に示す構成に限定されるものではない。例えば、図１では、実行物理サーバ４上で複数の実行仮想サーバ５が稼働している構成を示したが、実行仮想サーバ５を介さず、実行物理サーバ４上でバッチアプリケーションが稼働する構成でも構わない。さらに、実行物理サーバ４上で稼働するバッチアプリケーションと、実行仮想サーバ５上で稼働するバッチアプリケーションが混在する構成でも構わない。また、図１では、リソース管理サーバ３、配備制御サーバ２およびリソース補正制御サーバ１は、異なる計算機上で実行される構成を示したが、これらの全部、または一部が同一のサーバ上で実行しても構わない。
次に、図１〜図６を参照しつつ、図７〜図３４に沿って本実施形態に係る処理の説明を行なう。
《全体処理》
図７は、本実施形態に係るバッチアプリケーション実行方法に関する全体処理の手順を示すフローチャートである。
まず、クライアント装置６から配備制御サーバ２へバッチサービスの受付要求として、バッチＡＰプログラム名、処理対象となるデータ（バッチＡＰデータ５１１）、配備対象となる実行物理サーバ名である配備対象サーバ名、見積りリソース量および要求処理時間が送信される（Ｓ１０１）。ここで、見積もりリソース量とは、ユーザがクライアント端末６に入力するバッチサービスに必要なリソース量である。
《全体処理》
図７は、本実施形態に係るバッチアプリケーション実行方法に関する全体処理の手順を示すフローチャートである。
まず、クライアント装置６から配備制御サーバ２へバッチサービスの受付要求として、バッチＡＰプログラム名、処理対象となるデータ（バッチＡＰデータ５１１）、配備対象となる実行物理サーバ名である配備対象サーバ名、見積りリソース量および要求処理時間が送信される（Ｓ１０１）。ここで、見積もりリソース量とは、ユーザがクライアント端末６に入力するバッチサービスに必要なリソース量である。
なお、本実施形態では、クライアント装置６から実行対象のバッチＡＰプログラム５０１、処理対象データ、要求処理時間と共に、見積りリソース量も受信するものとしたが、見積りリソース量が与えられなかった場合は、図３０に示すバッチ単位処理履歴管理テーブル２１４を参照して、過去に実行したバッチアプリケーション名、データ処理件数、平均バッチ終了時間、使用したリソース量などから、見積もったリソース量を使用しても構わない。
なお、要求処理時間の代わりに、要求処理開始時刻と要求処理終了時刻を指定しても構わない。あるいは、要求処理時間と、処理開始時刻と処理終了時刻の両者であっても構わない。
続いて、配備制御サーバ２からリソース管理サーバ３に、リソース情報の取得要求が送信され、リソース管理サーバ３は、稼働リソース情報を確認した上で、指定されたリソースをバッチアプリケーションに割当てる（Ｓ１０２）。ステップＳ１０２の詳細は後記して説明する。
次に、クライアント装置６は、配備制御サーバ２に対して、バッチアプリケーションの実行要求を送信し、配備制御サーバ２は実行仮想サーバ４でバッチアプリケーションを開始し、さらに、配備制御サーバ２は処理対象データに対して、ロット単位の処理の成功、失敗などの処理履歴を管理する（Ｓ１０３）。ステップＳ１０３の処理は後記して説明する。
そして、リソース補正制御サーバ１の再検査契機取得処理部１０１が、後記して説明する再検査の契機で、ロット単位の処理履歴をグルーピングして中間処理単位とし、処理進捗率と必要進捗率を算出する（Ｓ１０４）。ステップＳ１０４の処理は後記して説明する。
そして、リソース補正制御サーバ１の再検査契機取得処理部１０１が、後記して説明する再検査の契機で、ロット単位の処理履歴をグルーピングして中間処理単位とし、処理進捗率と必要進捗率を算出する（Ｓ１０４）。ステップＳ１０４の処理は後記して説明する。
続いて、リソース補正制御サーバ１のリソース補正判定処理部１０３は、ステップＳ１０４で算出した処理進捗率と必要進捗率の比較を行ない、処理進捗率が必要進捗率未満となるバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ１０５）。なお、処理進捗率と必要進捗率については後記して説明するが、処理進捗率は該当時点における実際の進捗率であり、必要進捗率は要求処理時間内にバッチ処理が終了するために該当時点でどれだけ進捗していなければならないかを示すものである。
ステップＳ１０５の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがある場合（Ｓ１０５→Ｙｅｓ）、リソース補正判定処理部１０３は、バッチ処理に遅延が発生しているものと判定し、リソース補正制御サーバ１の割当てリソース算出処理部１０４が、所定の規則で、ロット単位でのバッチのデータ（ロット単位データ）をグルーピングした中間処理履歴を基に、処理遅延の回復に必要なリソース量を算出する（Ｓ１０６）。
ステップＳ１０５の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがある場合（Ｓ１０５→Ｙｅｓ）、リソース補正判定処理部１０３は、バッチ処理に遅延が発生しているものと判定し、リソース補正制御サーバ１の割当てリソース算出処理部１０４が、所定の規則で、ロット単位でのバッチのデータ（ロット単位データ）をグルーピングした中間処理履歴を基に、処理遅延の回復に必要なリソース量を算出する（Ｓ１０６）。
なお、割当てリソース算出処理部１０４は、リソースが確保できない場合などは、割当て可能な最大リソースを割当てるものとする。
リソース管理サーバ３のリソース割当て処理部３０３がステップＳ１０６で算出した割当てリソースの割当てを実施する（Ｓ１０７）。
なお、ステップＳ１０５〜ステップＳ１０７の詳細は後記して説明する。
なお、ステップＳ１０５〜ステップＳ１０７の詳細は後記して説明する。
ステップＳ１０５の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがない場合（Ｓ１０５→Ｎｏ）、割当てリソース補正判定処理部１０３は、予定通りバッチ処理が進行しているものと判定し、次のロットについてバッチ処理を続行する（ステップＳ１０８）。
ステップＳ１０７およびステップＳ１０８の後、配備制御サーバ２の配備アプリケーション情報管理部２０２が、すべてのロットに対して、バッチ処理を終了したか否かを判定する（Ｓ１０９）。
ステップＳ１０７およびステップＳ１０８の後、配備制御サーバ２の配備アプリケーション情報管理部２０２が、すべてのロットに対して、バッチ処理を終了したか否かを判定する（Ｓ１０９）。
ステップＳ１０９の結果、すべてのロットに対しバッチ処理が終了していない場合（Ｓ１０９→Ｎｏ）、計算機システム１０はステップＳ１０４へ処理を戻す。
ステップＳ１０９の結果、すべてのロットに対しバッチ処理が終了している場合（Ｓ１０９→Ｙｅｓ）、計算機システム１０は処理を終了する。
ステップＳ１０９の結果、すべてのロットに対しバッチ処理が終了している場合（Ｓ１０９→Ｙｅｓ）、計算機システム１０は処理を終了する。
《ステップＳ１０２の詳細（リソース情報取得およびリソース割当て）》
図８は、図７のステップＳ１０２の処理のうち、リソース情報取得およびリソース割当てに関する部分の詳細な手順を示すフローチャートである。なお、図８の処理は、リソース管理サーバ３上のリソース情報管理部３０１、アプリケーション構成情報管理部３０２およびリソース割当て処理部３０３が行なう処理である。
まず、リソース管理サーバ３は、クライアント装置６、配備制御サーバ２またはリソース補正制御サーバ１から、バッチアプリケーションのリソース情報取得の実行要求、またはリソース割当ての実行要求をクライアント端末から受信する（Ｓ２０１）。
続いて、リソース情報管理部３０１は、処理対象となっている実行要求がリソース情報取得の実行要求であるか否かを判定する（Ｓ２０２）。
ステップＳ２０２の結果、リソース情報取得の実行要求でない場合（Ｓ２０２→Ｎｏ）、すなわち、処理対象となっている実行要求がリソース割当ての実行要求である場合、リソース管理サーバ３は、リソース割当て処理部３０３を起動し、起動されたリソース割当て処理部３０３が、図１０で後記するリソースの割当てを実行物理サーバ４に行なった後、実行物理サーバ５上に実行仮想サーバ４を作成し、リソース情報管理テーブル３１１（図９）に割当てたリソース情報を反映させ（Ｓ２０３）、ステップＳ２０６へ処理を進める。ここで、リソース情報とは、図９のリソース情報管理テーブル３１１に格納されてる各情報である。
図８は、図７のステップＳ１０２の処理のうち、リソース情報取得およびリソース割当てに関する部分の詳細な手順を示すフローチャートである。なお、図８の処理は、リソース管理サーバ３上のリソース情報管理部３０１、アプリケーション構成情報管理部３０２およびリソース割当て処理部３０３が行なう処理である。
まず、リソース管理サーバ３は、クライアント装置６、配備制御サーバ２またはリソース補正制御サーバ１から、バッチアプリケーションのリソース情報取得の実行要求、またはリソース割当ての実行要求をクライアント端末から受信する（Ｓ２０１）。
続いて、リソース情報管理部３０１は、処理対象となっている実行要求がリソース情報取得の実行要求であるか否かを判定する（Ｓ２０２）。
ステップＳ２０２の結果、リソース情報取得の実行要求でない場合（Ｓ２０２→Ｎｏ）、すなわち、処理対象となっている実行要求がリソース割当ての実行要求である場合、リソース管理サーバ３は、リソース割当て処理部３０３を起動し、起動されたリソース割当て処理部３０３が、図１０で後記するリソースの割当てを実行物理サーバ４に行なった後、実行物理サーバ５上に実行仮想サーバ４を作成し、リソース情報管理テーブル３１１（図９）に割当てたリソース情報を反映させ（Ｓ２０３）、ステップＳ２０６へ処理を進める。ここで、リソース情報とは、図９のリソース情報管理テーブル３１１に格納されてる各情報である。
ステップＳ２０２の結果、リソース情報取得の実行要求である場合（Ｓ２０２→Ｙｅｓ）、リソース管理サーバ３は、リソース情報管理部３０１を起動し、起動されたリソース情報管理部３０１が、実行物理サーバ４上で稼働している実行仮想サーバ５から、当該実行仮想サーバ５のリソース種別、ＣＰＵ種別、メモリ種別、ディスク種別、および各々の実行物理サーバに割当てられたリソース量を取得し、これらの情報を登録することでリソース情報管理テーブル３１１（図９）を更新する(Ｓ２０４）。
次に、リソース管理サーバ３はアプリケーション構成情報管理部３０２を起動し、起動されたアプリケーション構成情報管理部３０２は、実行仮想サーバ４上で稼働しているバッチアプリケーションのバッチＡＰプログラム名と稼働状態を取得し、取得したバッチＡＰプログラム名と稼働状態を登録することで、リソース情報管理テーブル３１１（図９）を更新する（Ｓ２０５）。
次に、リソース管理サーバ３はアプリケーション構成情報管理部３０２を起動し、起動されたアプリケーション構成情報管理部３０２は、実行仮想サーバ４上で稼働しているバッチアプリケーションのバッチＡＰプログラム名と稼働状態を取得し、取得したバッチＡＰプログラム名と稼働状態を登録することで、リソース情報管理テーブル３１１（図９）を更新する（Ｓ２０５）。
なお、本実施形態において、リソース管理サーバ３はリソース情報取得の実行要求を受信することで、ステップＳ２０４およびステップＳ２０５を実行したが、これに限らず、定期的な監視によってステップＳ２０４およびステップＳ２０５を行なっても構わない。
そして、リソース管理サーバ３は未実行の実行要求（リソース情報取得またはリソース割当て）があるか否かを判定する（Ｓ２０６）。
ステップＳ２０６の結果、未実行の実行要求がある場合（Ｓ２０６→Ｙｅｓ）、リソース管理サーバ３はステップＳ２０２へ処理を戻す。
ステップＳ２０６の結果、未実行の実行要求がない場合（Ｓ２０６→Ｎｏ）、リソース管理サーバ３は、図７の処理へリターンする。
ステップＳ２０６の結果、未実行の実行要求がある場合（Ｓ２０６→Ｙｅｓ）、リソース管理サーバ３はステップＳ２０２へ処理を戻す。
ステップＳ２０６の結果、未実行の実行要求がない場合（Ｓ２０６→Ｎｏ）、リソース管理サーバ３は、図７の処理へリターンする。
《リソース情報管理テーブル》
図９は、本実施形態に係るリソース情報管理テーブルの例を示す図である。
リソース情報管理テーブル３１１は、リソース情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、バッチアプリケーションの実行や完了などの状態を示す稼働状態の各欄を有する。さらに、リソース情報管理テーブル３１１は、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てた実行物理サーバ４のＣＰＵのコア数を示すＣＰＵ割当て（コア割当て数）、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て（メモリ割当て数）の各情報を有する。
図９は、本実施形態に係るリソース情報管理テーブルの例を示す図である。
リソース情報管理テーブル３１１は、リソース情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、バッチアプリケーションの実行や完了などの状態を示す稼働状態の各欄を有する。さらに、リソース情報管理テーブル３１１は、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てた実行物理サーバ４のＣＰＵのコア数を示すＣＰＵ割当て（コア割当て数）、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て（メモリ割当て数）の各情報を有する。
図９に示すリソース情報管理テーブル３１１の例では、リソースの具体例として、ＣＰＵとメモリを挙げたが、この他に、ハードディスクなどをリソースの対象に含めても構わない。例えば、ハードディスクを対象リソースに含めた場合、リソース情報管理テーブル３１１は、ハードディスクのスペック名称を示すハードディスク種別、割当てたハードディスクの容量を示すディスク割当てを有することになる。なお、ハードディスク割当てには、割当てたハードディスクの容量を示すものとしたが、データ転送量などの情報を示すものとしても構わない。
《ステップＳ２０３の詳細（リソース割当て）》
図１０は、図８のステップＳ２０３の処理の詳細な手順を示すフローチャートである。なお、図１０の処理は、配備制御サーバ２上のＳＬＡ（要求処理時間）情報管理部２０１、配備アプリケーション情報管理部２０２およびアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２がクライアント装置６からバッチサービスの受付要求を受信する（Ｓ３０１）。
続いて、配備制御サーバ２がＳＬＡ情報管理部２０１を起動し、起動されたＳＬＡ情報管理部２０１が、クライアント装置６から実行対象のバッチＡＰプログラム５０１、処理対象データ、配備対象サーバ名、見積りリソース量、要求処理時間を受信する（Ｓ３０２）。ここで、ステップＳ３０２は、図７のステップＳ１０１に対応する。なお、要求処理時間の代わりに、処理開始時刻と処理終了時刻を指定しても構わない。あるいは、要求処理時間と、要求処理開始時刻と要求処理終了時刻の両者であっても構わない。また、処理対象データは、ロットと呼ばれる業務要件によって定められた分類や一定のデータ件数で分けられた単位に分割されているものとする。
図１０は、図８のステップＳ２０３の処理の詳細な手順を示すフローチャートである。なお、図１０の処理は、配備制御サーバ２上のＳＬＡ（要求処理時間）情報管理部２０１、配備アプリケーション情報管理部２０２およびアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２がクライアント装置６からバッチサービスの受付要求を受信する（Ｓ３０１）。
続いて、配備制御サーバ２がＳＬＡ情報管理部２０１を起動し、起動されたＳＬＡ情報管理部２０１が、クライアント装置６から実行対象のバッチＡＰプログラム５０１、処理対象データ、配備対象サーバ名、見積りリソース量、要求処理時間を受信する（Ｓ３０２）。ここで、ステップＳ３０２は、図７のステップＳ１０１に対応する。なお、要求処理時間の代わりに、処理開始時刻と処理終了時刻を指定しても構わない。あるいは、要求処理時間と、要求処理開始時刻と要求処理終了時刻の両者であっても構わない。また、処理対象データは、ロットと呼ばれる業務要件によって定められた分類や一定のデータ件数で分けられた単位に分割されているものとする。
次にＳＬＡ情報管理部２０１が、リソース管理サーバ３にリソース情報取得の実行要求を送信し、リソース管理サーバ３上に格納されるリソース情報管理テーブル３１１（図９）を参照することによってリソース割当て状況を確認し、未割当てのＣＰＵのコアが存在するか否かで実行物理サーバ４へのバッチアプリケーションの割当てが可能か否かを判定する（Ｓ３０３）。なお、ここで、送信されたリソース情報取得の実行要求が、ステップＳ２０１で受信される実行要求である。
ステップＳ３０３の結果、バッチアプリケーションの割当てが可能でない場合（Ｓ３０３→Ｎｏ）、ＳＬＡ情報管理部２０１がクライアント装置６にリソースが確保できないというメッセージを表示させ（Ｓ３０４）、ステップＳ３０３へ処理を戻して、リソースが空くのを待つ。ただし、ある一定時間の経過によって図１０の処理を終了させたり、クライアント装置６からの処理終了の要求で、図１０の処理を終了させても構わない。
ステップＳ３０３の結果、バッチアプリケーションの割当てが可能でない場合（Ｓ３０３→Ｎｏ）、ＳＬＡ情報管理部２０１がクライアント装置６にリソースが確保できないというメッセージを表示させ（Ｓ３０４）、ステップＳ３０３へ処理を戻して、リソースが空くのを待つ。ただし、ある一定時間の経過によって図１０の処理を終了させたり、クライアント装置６からの処理終了の要求で、図１０の処理を終了させても構わない。
ステップＳ３０３の結果、バッチアプリケーションの割当てが可能である場合（Ｓ３０３→Ｙｅｓ）、ＳＬＡ情報管理部２０１がリソース管理サーバ３に、リソース割当ての実行要求を送信し、割当ての対象となるバッチＡＰプログラム名、処理対象データ名、配備対象サーバ名、および要求処理時間を図１１に示すＳＬＡ情報管理テーブル２１１に登録する（Ｓ３０５）。ここで、送信されたリソース割当ての実行要求が、ステップＳ２０１で受信される実行要求である。なお、リソース割当ての実行要求には、処理対象データ名、配備対象サーバ名、および要求処理時間が格納されている。
そして、ＳＬＡ情報管理部２０１は、ステップＳ３０２で受信したバッチ処理の対象データ（処理対象データ）から処理対象データ名、データ件数、ロット単位件数、ロット単位データ名を取得すると、図１２に示す処理対象データ管理テーブル２１２に登録し（Ｓ３０６）、図１３の処理へ進む。
そして、ＳＬＡ情報管理部２０１は、ステップＳ３０２で受信したバッチ処理の対象データ（処理対象データ）から処理対象データ名、データ件数、ロット単位件数、ロット単位データ名を取得すると、図１２に示す処理対象データ管理テーブル２１２に登録し（Ｓ３０６）、図１３の処理へ進む。
《ＳＬＡ情報管理テーブル》
図１１は、本実施形態に係るＳＬＡ（要求処理時間）情報管理テーブルの例を示す図である。
ＳＬＡ情報管理テーブル２１１は、図１０のステップＳ３０２でクライアント装置６から受信したバッチサービスに関する情報を管理するための属性情報として、バッチアプリケーションプログラム名、処理対象データ名、配備対象サーバ名、要求処理時間、要求処理開始時刻および要求処理終了時刻の各情報を有する。要求処理開始時刻、あるいは、要求処理終了時刻が指定されない場合は、ＮＵＬＬ値が格納される。
図１１は、本実施形態に係るＳＬＡ（要求処理時間）情報管理テーブルの例を示す図である。
ＳＬＡ情報管理テーブル２１１は、図１０のステップＳ３０２でクライアント装置６から受信したバッチサービスに関する情報を管理するための属性情報として、バッチアプリケーションプログラム名、処理対象データ名、配備対象サーバ名、要求処理時間、要求処理開始時刻および要求処理終了時刻の各情報を有する。要求処理開始時刻、あるいは、要求処理終了時刻が指定されない場合は、ＮＵＬＬ値が格納される。
《処理対象データ管理テーブル》
図１２は、本実施形態に係る処理対象データ管理テーブルの例を示す図である。
処理対象データ管理テーブル２１２は、図１０のステップＳ３０２で受信した処理対象データに関する情報を管理するための属性情報として、処理対象データ名、データ件数、業務要件により定められた分類や一定のデータ件数で分けられたロット単位件数、ロット単位に分けられたデータを識別するためのロット単位データ名の各情報を有する。
図１２は、本実施形態に係る処理対象データ管理テーブルの例を示す図である。
処理対象データ管理テーブル２１２は、図１０のステップＳ３０２で受信した処理対象データに関する情報を管理するための属性情報として、処理対象データ名、データ件数、業務要件により定められた分類や一定のデータ件数で分けられたロット単位件数、ロット単位に分けられたデータを識別するためのロット単位データ名の各情報を有する。
《ステップＳ１０２の詳細（バッチアプリケーション情報収集）》
図１３は、図７のステップＳ１０２の処理のうち、バッチアプリケーション情報収集に関する部分の詳細な手順を示すフローチャートである。なお、図１３の処理は、配備制御サーバ２上の配備アプリケーション情報管理部２０２が行なう処理である。
まず、配備制御サーバ２は、リソース管理サーバ３から、図８のステップＳ２０５におけるリソース情報管理テーブル３１１（図９）の更新をメッセージとして受信する（Ｓ４０１）。
そして、配備制御サーバ２は配備アプリケーション情報管理部２０２を起動し、起動された配備アプリケーション情報管理部２０２が、リソース管理サーバ３のリソース情報管理テーブル３１１（図９）から全レコードにおける実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）を取得する（Ｓ４０２）。
図１３は、図７のステップＳ１０２の処理のうち、バッチアプリケーション情報収集に関する部分の詳細な手順を示すフローチャートである。なお、図１３の処理は、配備制御サーバ２上の配備アプリケーション情報管理部２０２が行なう処理である。
まず、配備制御サーバ２は、リソース管理サーバ３から、図８のステップＳ２０５におけるリソース情報管理テーブル３１１（図９）の更新をメッセージとして受信する（Ｓ４０１）。
そして、配備制御サーバ２は配備アプリケーション情報管理部２０２を起動し、起動された配備アプリケーション情報管理部２０２が、リソース管理サーバ３のリソース情報管理テーブル３１１（図９）から全レコードにおける実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）を取得する（Ｓ４０２）。
続いて、配備アプリケーション情報管理部２０２は、ＳＬＡ情報管理テーブル２１１（図１１）から処理対象となっているバッチアプリケーションの処理対象データ名を取得し、処理対象データ管理テーブル２１２（図１２）にアクセスして、割出した処理対象データに該当するロット単位データ名を取得し、ステップＳ４０２で取得した実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名と共に、配備アプリケーション管理テーブル２１３（図１４）に登録することで配備アプリケーション管理テーブル２１３を更新し（Ｓ４０３）、図７の処理へリターンする。なお、初回の場合、配備アプリケーション情報管理部２０２が配備アプリケーション管理テーブル２１３を新規作成するものとする。
《配備アプリケーション管理テーブル》
図１４は、本実施形態に係る配備アプリケーション管理テーブルの例を示す図である。
配備アプリケーション管理テーブル２１３は、配備対象となるアプリケーション、実行サーバ、処理対象データとの対応に関する情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、処理対象データ名およびロット単位データ名の各情報を有する。
図１４は、本実施形態に係る配備アプリケーション管理テーブルの例を示す図である。
配備アプリケーション管理テーブル２１３は、配備対象となるアプリケーション、実行サーバ、処理対象データとの対応に関する情報を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、バッチアプリケーション名（バッチＡＰ名）、処理対象データ名およびロット単位データ名の各情報を有する。
《ステップＳ１０３の詳細》
図１５は、図７のステップＳ１０３の処理の詳細な手順を示すフローチャートである。なお、図１５の処理は、主に配備制御サーバ２上のアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２は、クライアント装置６からバッチアプリケーションの実行要求を受信する（Ｓ５０１）。
そして、配備制御サーバ２はアプリケーション・データ配備処理部２０３を起動し、起動されたアプリケーション・データ配備処理部２０３は配備アプリケーション管理テーブル２１３（図１４）を参照して、実行対象であるバッチアプリケーション名をキーとして、実行仮想サーバ名を取得する（Ｓ５０２）。
続いて、アプリケーション・データ配備処理部２０３は、リソース管理サーバ３上の仮想マシンイメージ管理領域３１２に格納された該当の仮想マシンイメージを、該当の実行物理サーバ４に配備し、起動させる（Ｓ５０３）ことによって、実行仮想サーバ５を起動する。
図１５は、図７のステップＳ１０３の処理の詳細な手順を示すフローチャートである。なお、図１５の処理は、主に配備制御サーバ２上のアプリケーション・データ配備処理部２０３が行なう処理である。
まず、配備制御サーバ２は、クライアント装置６からバッチアプリケーションの実行要求を受信する（Ｓ５０１）。
そして、配備制御サーバ２はアプリケーション・データ配備処理部２０３を起動し、起動されたアプリケーション・データ配備処理部２０３は配備アプリケーション管理テーブル２１３（図１４）を参照して、実行対象であるバッチアプリケーション名をキーとして、実行仮想サーバ名を取得する（Ｓ５０２）。
続いて、アプリケーション・データ配備処理部２０３は、リソース管理サーバ３上の仮想マシンイメージ管理領域３１２に格納された該当の仮想マシンイメージを、該当の実行物理サーバ４に配備し、起動させる（Ｓ５０３）ことによって、実行仮想サーバ５を起動する。
次に、アプリケーション・データ配備処理部２０３は、配備アプリケーション管理テーブル２１３（図１４）を参照して、起動した実行仮想サーバ５にロット単位データを配備する（Ｓ５０４）。
そして、アプリケーション・データ配備処理部２０３は、ステップＳ５０４の処理をすべてのロットに対して処理したか否かを判定する（Ｓ５０５）。なお、ステップＳ５０４の処理は、所定のロット単位データ毎に行なってもよいし、すべてのロット単位データでまとめて行なってもよい。
ステップＳ５０５の結果、すべてのロットに対して処理していない場合（Ｓ５０５→Ｎｏ）、アプリケーション・データ配備処理部２０３はステップＳ５０５へ処理を戻す。
ステップＳ５０５の結果、すべてのロットに対して処理している場合（Ｓ５０５→Ｙｅｓ）、各実行仮想サーバ５は該当するバッチアプリケーションを実行する（Ｓ５０６）。このとき、アプリケーション・データ配備処理部２０３は、リソース補正制御サーバ１のリソース割当て所要時間管理テーブル１１４（図３４）の各欄に情報を登録し、割当て所要時間の欄にバッチアプリケーションの割当てにかかった時間を登録する。
そして、アプリケーション・データ配備処理部２０３は、ステップＳ５０４の処理をすべてのロットに対して処理したか否かを判定する（Ｓ５０５）。なお、ステップＳ５０４の処理は、所定のロット単位データ毎に行なってもよいし、すべてのロット単位データでまとめて行なってもよい。
ステップＳ５０５の結果、すべてのロットに対して処理していない場合（Ｓ５０５→Ｎｏ）、アプリケーション・データ配備処理部２０３はステップＳ５０５へ処理を戻す。
ステップＳ５０５の結果、すべてのロットに対して処理している場合（Ｓ５０５→Ｙｅｓ）、各実行仮想サーバ５は該当するバッチアプリケーションを実行する（Ｓ５０６）。このとき、アプリケーション・データ配備処理部２０３は、リソース補正制御サーバ１のリソース割当て所要時間管理テーブル１１４（図３４）の各欄に情報を登録し、割当て所要時間の欄にバッチアプリケーションの割当てにかかった時間を登録する。
アプリケーション・データ配備処理部２０３は、配備した各々のバッチアプリケーションに対して、ロット単位毎に処理状況を監視する（Ｓ５０７）。
そして、アプリケーション・データ配備処理部２０３は、すべてのロットのバッチ処理を終了したか否かを判定する（Ｓ５０８）。
ステップＳ５０８の結果、すべてのロットのバッチ処理を終了している場合（Ｓ５０８→Ｙｅｓ）、アプリケーション・データ配備処理部２０３は、バッチアプリケーションの処理時間や使用したリソース情報などの処理履歴をバッチ単位処理履歴管理テーブル２１４（図１９）およびアプリケーションゲーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）に登録し（Ｓ５０９）、図７の処理へリターンする。ここで、リソース情報とは、ステップＳ４０２で取得したＣＰＵ種別、合計ＣＰＵ割当て、メモリ種別および合計メモリ割当てなどである。
そして、アプリケーション・データ配備処理部２０３は、すべてのロットのバッチ処理を終了したか否かを判定する（Ｓ５０８）。
ステップＳ５０８の結果、すべてのロットのバッチ処理を終了している場合（Ｓ５０８→Ｙｅｓ）、アプリケーション・データ配備処理部２０３は、バッチアプリケーションの処理時間や使用したリソース情報などの処理履歴をバッチ単位処理履歴管理テーブル２１４（図１９）およびアプリケーションゲーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）に登録し（Ｓ５０９）、図７の処理へリターンする。ここで、リソース情報とは、ステップＳ４０２で取得したＣＰＵ種別、合計ＣＰＵ割当て、メモリ種別および合計メモリ割当てなどである。
ステップＳ５０８の結果、すべてのロットのバッチ処理を終了していない場合（Ｓ５０８→Ｎｏ）、アプリケーション・データ配備処理部２０３は、ロット単位のバッチ処理の終了の監視を行ない、ロット単位のバッチ処理が終了したか否かを判定する（Ｓ５１０）。
ステップＳ５１０の結果、ロット単位のバッチ処理が終了していない場合（Ｓ５１０→Ｎｏ）、アプリケーション・データ配備処理部２０３は、ステップＳ５１０へ処理を戻し、監視を続ける。
ステップＳ５１０の結果、ロット単位のバッチ処理が終了していない場合（Ｓ５１０→Ｎｏ）、アプリケーション・データ配備処理部２０３は、ステップＳ５１０へ処理を戻し、監視を続ける。
ステップＳ５１０の結果、ロット単位の処理が終了している場合（Ｓ５１０→Ｙｅｓ）、アプリケーション・データ配備処理部２０３は、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）における処理単位の欄を「終了」に更新し、所要時間の欄に所要時間を登録する（Ｓ５１１）。このとき、アプリケーション・データ配備処理部２０３は、現在時刻を処理状態最終更新時刻の欄に登録する。
そして、アプリケーション・データ配備処理部２０３は、各ロット単位を処理するのに要した平均所要時間を算出し、ロット単位処理履歴管理テーブル２１５（図１８）に算出した平均値および使用したリソース情報（実行物理サーバ４のＣＰＵ種別、ＣＰＵ割当て、メモリ種別、メモリ割当て）を登録し（Ｓ５１２）ステップＳ５０８へ処理を戻す。リソース情報は、図１３のステップＳ４０２で取得した情報である。
そして、アプリケーション・データ配備処理部２０３は、各ロット単位を処理するのに要した平均所要時間を算出し、ロット単位処理履歴管理テーブル２１５（図１８）に算出した平均値および使用したリソース情報（実行物理サーバ４のＣＰＵ種別、ＣＰＵ割当て、メモリ種別、メモリ割当て）を登録し（Ｓ５１２）ステップＳ５０８へ処理を戻す。リソース情報は、図１３のステップＳ４０２で取得した情報である。
なお、バッチアプリケーションの切離し（終了）も、同様の手順で行なわれるが、このとき、アプリケーション・データ配備処理部２０３は、リソース補正制御サーバ１のリソース割当て所要時間管理テーブル１１４（図２４）の各欄に情報を登録し、切離し所要時間の欄にバッチアプリケーションの切離し（終了）にかかった時間を登録する。
《バッチアプリケーション毎ロット単位処理履歴管理テーブル》
図１６および図１７は、本実施形態に係るバッチアプリケーション毎ロット単位処理履歴管理テーブルの例を示す図である。なお、図１６が「バッチＡＰ１」について、図１７はバッチＡＰ２について示している。
図１６を参照して説明すると、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ（２１５）は、バッチアプリケーションにおけるロット単位での処理履歴を管理する属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、ロット単位での処理の終了や実行中などの状態を示す処理状態、ロット単位の処理の終了に係る時間を示す所要時間を有している。また、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当てを有している。さらに、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、該当するロット単位データの処理が終了した時刻である処理状態最終更新時刻の各情報を有する。
処理状態の欄には、「実行前」、「実行中」、「終了」などの情報が格納される。
なお、図１７のバッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ｂ（２１５）は、対象となるバッチアプリケーションが「バッチＡＰ２」となった以外は、図１６と同様であるため説明を省略する。
図１６および図１７は、本実施形態に係るバッチアプリケーション毎ロット単位処理履歴管理テーブルの例を示す図である。なお、図１６が「バッチＡＰ１」について、図１７はバッチＡＰ２について示している。
図１６を参照して説明すると、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ（２１５）は、バッチアプリケーションにおけるロット単位での処理履歴を管理する属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、ロット単位での処理の終了や実行中などの状態を示す処理状態、ロット単位の処理の終了に係る時間を示す所要時間を有している。また、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当てを有している。さらに、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａは、該当するロット単位データの処理が終了した時刻である処理状態最終更新時刻の各情報を有する。
処理状態の欄には、「実行前」、「実行中」、「終了」などの情報が格納される。
なお、図１７のバッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ｂ（２１５）は、対象となるバッチアプリケーションが「バッチＡＰ２」となった以外は、図１６と同様であるため説明を省略する。
《ロット単位処理履歴管理テーブル》
図１８は、本実施形態に係るロット単位処理履歴管理テーブルの例を示す図である。
ロット単位処理履歴管理テーブル２１５は、各々のバッチアプリケーションにおけるロット単位での処理履歴を管理するための属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、各々のロットの平均処理時間を示す平均ロット処理時間、ロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
図１８は、本実施形態に係るロット単位処理履歴管理テーブルの例を示す図である。
ロット単位処理履歴管理テーブル２１５は、各々のバッチアプリケーションにおけるロット単位での処理履歴を管理するための属性情報として、バッチアプリケーション名（バッチＡＰ名）、ロット単位データ名、各々のロットの平均処理時間を示す平均ロット処理時間、ロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
図１８は、「バッチＡＰ１」がロット単位データ「データ１−２」まで処理が完了しており、「バッチＡＰ２」がロット単位データ「データ２−３」まで処理が完了していることを示している。
《バッチ単位処理履歴管理テーブル》
図１９は、本実施形態に係るバッチ単位処理履歴管理テーブルの例を示す図である。
バッチ単位処理履歴管理テーブル２１４は、各々のバッチアプリケーションにおける処理履歴を管理するための属性情報として、処理実行日、バッチアプリケーション名（バッチＡＰ名）、データ処理件数、バッチ処理が終了するまでにかかる時間を示すバッチ処理時間、今回のバッチ処理時間を含む、これまでのバッチ処理のバッチ処理時間の平均処理時間を示す平均バッチ平均処理時間の各情報を有する。また、バッチ単位処理履歴管理テーブル２１４は、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵの合計コア数を示す合計ＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、割当てたメモリの合計容量を示す合計メモリ割当ての各情報を有する。
図１９は、本実施形態に係るバッチ単位処理履歴管理テーブルの例を示す図である。
バッチ単位処理履歴管理テーブル２１４は、各々のバッチアプリケーションにおける処理履歴を管理するための属性情報として、処理実行日、バッチアプリケーション名（バッチＡＰ名）、データ処理件数、バッチ処理が終了するまでにかかる時間を示すバッチ処理時間、今回のバッチ処理時間を含む、これまでのバッチ処理のバッチ処理時間の平均処理時間を示す平均バッチ平均処理時間の各情報を有する。また、バッチ単位処理履歴管理テーブル２１４は、さらにロット単位の処理に使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵの合計コア数を示す合計ＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、割当てたメモリの合計容量を示す合計メモリ割当ての各情報を有する。
図１９の例は、「２０１０年１月２１日」には、「バッチＡＰ１」が４０００件のデータをバッチ処理し、「バッチＡＰ２」が２０００件のデータをバッチ処理したことを示している。同様に、「２０１０年１月２２日」には、「バッチＡＰ１」が３０００件のデータをバッチ処理し、「バッチＡＰ２」が３０００件のデータをバッチ処理したことを示している。
ここで、バッチ平均処理時間は、バッチ処理時間の平均値であり、例えば「２０１０−０１−２２」の「バッチＡＰ１」におけるバッチ平均処理時間「４．８０時間」は、「２０１０−０１−２１」のバッチ処理時間「４．７５時間」と、「２０１０−０１−２２」のバッチ処理時間「４．８５時間」との平均値である。
次に、図２０〜図３４を参照して、本実施形態に係るリソース補正処理について説明する。
《再検査の契機の概念図》
図２０は、本実施形態に係るリソース補正のための再検査の契機に関する概念図である。
ここで、リソース量の再検査（以下、再検査と称する）を行なう目的は、バッチアプリケーションの要求処理時間（ＳＬＡ）遵守の確度を高めることである。つまり、リソース補正制御サーバ１は、再検査を行なうことで、要求処理時間内で処理を終了させるペースで処理の進捗が得られているか確認することができ、処理を終了させるペースの進捗が得られていない場合は、リソースの割当ての見直しを行なう。これにより、リソース補正制御サーバ１は、バッチ処理の遅延を回復することが可能になる。ただし、頻繁にリソースの割当てを見直すことは、バッチ処理のスループットを低下させる原因にもなるので、効果的な見直しを行なう必要がある。本実施形態では、効果的な見直しを行なうために、共存するバッチアプリケーションを横断的に統合監視し、バッチアプリケーションの開始や終了のタイミングに着目して、再検査を行なうものとする。
《再検査の契機の概念図》
図２０は、本実施形態に係るリソース補正のための再検査の契機に関する概念図である。
ここで、リソース量の再検査（以下、再検査と称する）を行なう目的は、バッチアプリケーションの要求処理時間（ＳＬＡ）遵守の確度を高めることである。つまり、リソース補正制御サーバ１は、再検査を行なうことで、要求処理時間内で処理を終了させるペースで処理の進捗が得られているか確認することができ、処理を終了させるペースの進捗が得られていない場合は、リソースの割当ての見直しを行なう。これにより、リソース補正制御サーバ１は、バッチ処理の遅延を回復することが可能になる。ただし、頻繁にリソースの割当てを見直すことは、バッチ処理のスループットを低下させる原因にもなるので、効果的な見直しを行なう必要がある。本実施形態では、効果的な見直しを行なうために、共存するバッチアプリケーションを横断的に統合監視し、バッチアプリケーションの開始や終了のタイミングに着目して、再検査を行なうものとする。
図２０は、３つのバッチアプリケーション「バッチＡＰ１」、「バッチＡＰ２」および「バッチＡＰ３」が共存する環境下における再検査の契機を概念的に示したものである。図２０では、まず、「Ｔ０」の時刻で「バッチＡＰ１」の処理が開始していることを示し、「バッチＡＰ２」の処理が開始する「Ｔ１」の時刻を、１度目の再検査の契機としている。続いて、「バッチＡＰ３」の処理が開始する「Ｔ２」の時刻を、２度目の再検査の契機としている。同様に、「バッチＡＰ２」の処理が終了する「Ｔ３」の時刻を、３度目の再検査の契機とし、「バッチＡＰ３」の処理が終了する「Ｔ４」の時刻を、４度目の再検査の契機としている。さらに、「バッチＡＰ１」が終了する「Ｔ５」の時刻を５度目の再検査の契機としている。また、図２０では、「バッチＡＰ１」の処理時間に関しては、処理開始時刻「Ｔ０」から処理終了時刻「Ｔ５」までであって、要求処理時間が処理終了時刻「Ｔ５」の先にあることから、「バッチＡＰ１」は要求処理時間内に処理が終了できたことを示している。同様にして、「バッチＡＰ２」、「バッチＡＰ３」についても要求処理時間内に処理が終了している。
《ステップＳ１０４の詳細（再検査の契機取得）》
図２１は、ステップＳ１０４の処理の詳細な手順のうち、再検査の契機取得に関する部分を示すフローチャートである。なお、図２１の処理は、リソース補正制御サーバ１の再検査契機取得処理部１０１が行なう処理である。
リソース管理サーバ３は、図８のステップＳ２０５でリソース情報管理テーブル３１１（図９）の稼働状態ステータスが「準備中」→「実行中」となると「開始」を検知し、「実行中」→「準備中」となると「終了」を検知し、これらの情報をリソース補正制御サーバ１へ送信する。
図２１は、ステップＳ１０４の処理の詳細な手順のうち、再検査の契機取得に関する部分を示すフローチャートである。なお、図２１の処理は、リソース補正制御サーバ１の再検査契機取得処理部１０１が行なう処理である。
リソース管理サーバ３は、図８のステップＳ２０５でリソース情報管理テーブル３１１（図９）の稼働状態ステータスが「準備中」→「実行中」となると「開始」を検知し、「実行中」→「準備中」となると「終了」を検知し、これらの情報をリソース補正制御サーバ１へ送信する。
まず、リソース補正制御サーバ１が、リソース管理サーバ３からバッチアプリケーションの稼働状態に変化があったことをメッセージとして受信し、再検査契機取得処理部１０１を起動する（Ｓ６０１）。
そして、起動された再検査契機取得処理部１０１は、稼動状態に変化が起きた時刻（ステップＳ６０１でメッセージを受信した時刻）を再検査の契機とする（Ｓ６０２）。
そして、起動された再検査契機取得処理部１０１は、稼動状態に変化が起きた時刻（ステップＳ６０１でメッセージを受信した時刻）を再検査の契機とする（Ｓ６０２）。
なお、本実施形態では、再検査の契機を共存するアプリケーションの稼働状態の変化から取得するものとしたが、定期的な時刻や時間を再検査の契機としても構わない。また、ロット単位のバッチ処理の終了メッセージや、リソース使用率の閾値監視のアラートを契機にしても構わない。
《中間処理単位データ取得の概念図》
図２２および図２３は、再検査に必要な中間処理単位データ取得の概念図である。
ここで、図２２は、各バッチアプリケーションで使用するロット単位データのデータ数が同じである場合を示し、図２３は、各バッチアプリケーションで使用するロット単位データのデータ数が異なる場合を示している。
なお、図２２および図２３における「１−１」、「１−２」などは配備アプリケーション管理テーブル２１３（図１４）のロット単位データの「データ１−１」、「データ１−２」などに対応する。
中間処理単位を決める目的は、バッチ処理の進捗率の算出に必要になる処理済みデータを特定するためである。図２２に示すように、中間処理単位は、契機を境にして処理済みのロット単位のデータをグルーピングすることによって決める。例えば、「バッチＡＰ１」の場合、時刻「Ｔ１」の契機では、ロット単位データ「１−１」、「１−２」がグルーピングされ、１つの中間処理単位となり、リソース補正判定処理部１０３は、このグルーピングを基に後記する進捗率を求める。同様にして、時刻「Ｔ２」の契機では、中間処理単位データ取得処理部１０２は、ロット単位データ「１−３」を中間処理単位とし、時刻「Ｔ３」の契機では、ロット単位データ「１−４」、「１−５」、「１−６」を中間処理単位とする。そして、時刻「Ｔ４」の契機では、ロット単位データ「１−７」を中間処理単位とし、時刻「Ｔ５」の契機では、ロット単位データ「１−８」、「１−９」を中間処理単位とする。中間処理単位データ取得処理部１０２は、「バッチＡＰ２」、「バッチＡＰ３」も同様にして中間処理単位を求める。
図２２および図２３は、再検査に必要な中間処理単位データ取得の概念図である。
ここで、図２２は、各バッチアプリケーションで使用するロット単位データのデータ数が同じである場合を示し、図２３は、各バッチアプリケーションで使用するロット単位データのデータ数が異なる場合を示している。
なお、図２２および図２３における「１−１」、「１−２」などは配備アプリケーション管理テーブル２１３（図１４）のロット単位データの「データ１−１」、「データ１−２」などに対応する。
中間処理単位を決める目的は、バッチ処理の進捗率の算出に必要になる処理済みデータを特定するためである。図２２に示すように、中間処理単位は、契機を境にして処理済みのロット単位のデータをグルーピングすることによって決める。例えば、「バッチＡＰ１」の場合、時刻「Ｔ１」の契機では、ロット単位データ「１−１」、「１−２」がグルーピングされ、１つの中間処理単位となり、リソース補正判定処理部１０３は、このグルーピングを基に後記する進捗率を求める。同様にして、時刻「Ｔ２」の契機では、中間処理単位データ取得処理部１０２は、ロット単位データ「１−３」を中間処理単位とし、時刻「Ｔ３」の契機では、ロット単位データ「１−４」、「１−５」、「１−６」を中間処理単位とする。そして、時刻「Ｔ４」の契機では、ロット単位データ「１−７」を中間処理単位とし、時刻「Ｔ５」の契機では、ロット単位データ「１−８」、「１−９」を中間処理単位とする。中間処理単位データ取得処理部１０２は、「バッチＡＰ２」、「バッチＡＰ３」も同様にして中間処理単位を求める。
図２２では、共存する全てのバッチアプリケーションのロット単位が１００件と均一な例を示したが、実際には、業務要件により、バッチアプリケーションによって異なるロット単位が混在するケースが予想される。図２３は、その場合における中間処理単位を決めるためのデータ分割を概念的に示したものである。
取得した再検査の契機が、ロット単位や１件当たりの処理の負荷によるばらつきにより、処理途中であったロットは、その直近のロットの処理終了を中間処理単位とする。
取得した再検査の契機が、ロット単位や１件当たりの処理の負荷によるばらつきにより、処理途中であったロットは、その直近のロットの処理終了を中間処理単位とする。
《ステップＳ１０４の詳細（中間処理単位データ取得）》
図２４は、図７のステップＳ１０４の処理の詳細な手順のうち、中間処理単位データ取得に関する部分を示すフローチャートである。なお、図２４の処理は、リソース補正制御サーバ１の中間処理単位データ取得処理部１０２が主に行なう処理である。
まず、リソース補正制御サーバ１は、図２１のステップＳ６０２での再検査契機取得処理部１０１から再検査の契機取得完了を検知する（Ｓ７０１）。
そして、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２を起動し、起動された中間処理単位データ取得処理部１０２は、再検査契機取得処理部１０１が図２１のステップＳ６０２で取得した再検査の契機の時刻を取得する（Ｓ７０２）。
続いて、中間処理単位データ取得処理部１０２は、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）を参照し、取得した再検査の契機の時刻（処理状態最終更新時刻）における処理状態のステータスを取得する（Ｓ７０３）。
図２４は、図７のステップＳ１０４の処理の詳細な手順のうち、中間処理単位データ取得に関する部分を示すフローチャートである。なお、図２４の処理は、リソース補正制御サーバ１の中間処理単位データ取得処理部１０２が主に行なう処理である。
まず、リソース補正制御サーバ１は、図２１のステップＳ６０２での再検査契機取得処理部１０１から再検査の契機取得完了を検知する（Ｓ７０１）。
そして、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２を起動し、起動された中間処理単位データ取得処理部１０２は、再検査契機取得処理部１０１が図２１のステップＳ６０２で取得した再検査の契機の時刻を取得する（Ｓ７０２）。
続いて、中間処理単位データ取得処理部１０２は、バッチアプリケーション毎ロット単位処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）を参照し、取得した再検査の契機の時刻（処理状態最終更新時刻）における処理状態のステータスを取得する（Ｓ７０３）。
そして、中間処理単位データ取得処理部１０２は、取得した処理状態のステータスが「実行中」のバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ７０４）。
ステップＳ７０４の結果、「実行中」のバッチアプリケーションがある場合（Ｓ７０４→Ｙｅｓ）、中間処理単位データ取得処理部１０２は、そのバッチアプリケーションに関し、前回の契機から、すでに終了しているロット単位データまでを中間処理単位データとして、中間処理単位データ管理テーブル１１１（図２５）に登録し（Ｓ７０５）、図２６の処理へ進む。ここでは、「実行中」のバッチアプリケーションがある場合において、その時点で終了しているロットを中間処理単位データに含めるようにしたが、実行中のロットが終了するまで待ち、終了した時点で該当のロットを含めて中間処理単位データとしてもよい。
ステップＳ７０４の結果、「実行中」のバッチアプリケーションがある場合（Ｓ７０４→Ｙｅｓ）、中間処理単位データ取得処理部１０２は、そのバッチアプリケーションに関し、前回の契機から、すでに終了しているロット単位データまでを中間処理単位データとして、中間処理単位データ管理テーブル１１１（図２５）に登録し（Ｓ７０５）、図２６の処理へ進む。ここでは、「実行中」のバッチアプリケーションがある場合において、その時点で終了しているロットを中間処理単位データに含めるようにしたが、実行中のロットが終了するまで待ち、終了した時点で該当のロットを含めて中間処理単位データとしてもよい。
ステップＳ７０４の結果、「実行中」のバッチアプリケーションがない場合（Ｓ７０４→Ｎｏ）、前回の契機から今回の契機までの間に処理が終了しているロットを中間処理単位データとして、中間処理単位データ管理テーブル１１１（図２５）に登録し（Ｓ７０６）、図２６の処理へ進む。
《中間処理単位データ管理テーブル》
図２５は、本実施形態に係る中間処理単位データ管理テーブルの例を示す図である。
中間処理単位データ管理テーブル１１１では、各バッチアプリケーションの中間処理単位データを管理するための属性情報として、再検査の契機時刻を示す契機、共存するバッチアプリケーションの中間処理単位となるデータを示すバッチＡＰ１中間処理単位データ、バッチＡＰ２中間処理単位データ、バッチＡＰ３中間処理単位データの各情報を有する。なお、図２５では、共存するバッチアプリケーションが３つの例を示しているが、１つ以上であれば、共存するバッチアプリケーションはいくつであってもよい。
図２５は、本実施形態に係る中間処理単位データ管理テーブルの例を示す図である。
中間処理単位データ管理テーブル１１１では、各バッチアプリケーションの中間処理単位データを管理するための属性情報として、再検査の契機時刻を示す契機、共存するバッチアプリケーションの中間処理単位となるデータを示すバッチＡＰ１中間処理単位データ、バッチＡＰ２中間処理単位データ、バッチＡＰ３中間処理単位データの各情報を有する。なお、図２５では、共存するバッチアプリケーションが３つの例を示しているが、１つ以上であれば、共存するバッチアプリケーションはいくつであってもよい。
《ステップＳ１０４の詳細（リソース補正判定）》
図２６は、ステップＳ１０４の処理のうち、リソース補正判定に関する部分の手順を示すフローチャートである。なお、図２６の処理は、主にリソース補正制御サーバ１のリソース補正判定処理部１０３が行なう処理である。
まず、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２から中間処理単位データの取得完了を検知する（Ｓ８０１）。
そして、リソース補正制御サーバ１は、リソース補正判定処理部１０３を起動し、起動されたリソース補正判定処理部１０３は、中間処理単位データ管理テーブル１１１を参照し、各バッチアプリケーションにおいて、処理対象となっている契機の中間処理単位データ名を取得する（Ｓ８０２）。
図２６は、ステップＳ１０４の処理のうち、リソース補正判定に関する部分の手順を示すフローチャートである。なお、図２６の処理は、主にリソース補正制御サーバ１のリソース補正判定処理部１０３が行なう処理である。
まず、リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２から中間処理単位データの取得完了を検知する（Ｓ８０１）。
そして、リソース補正制御サーバ１は、リソース補正判定処理部１０３を起動し、起動されたリソース補正判定処理部１０３は、中間処理単位データ管理テーブル１１１を参照し、各バッチアプリケーションにおいて、処理対象となっている契機の中間処理単位データ名を取得する（Ｓ８０２）。
次に、リソース補正判定処理部１０３は、配備制御サーバ２の処理対象データ管理テーブル２１２（図１２）を参照して、ステップＳ８０２で取得した処理対象となっている中間処理単位データに該当するロット単位件数を取得し、取得した各々のロット単位件数毎のデータ件数を加算し、累積処理件数とすることによって、累積処理件数を算出する（Ｓ８０３）。
続いて、リソース補正判定処理部１０３は、配備制御サーバ２の処理対象データ管理テーブル２１２（図１２）を参照して、処理対象となっている中間処理単位データに該当するデータ件数を取得することによって、全処理対象件数を取得し、ステップＳ８０３で算出した累積処理件数と、全処理対象件数とを基に、式（１）を計算することにより全処理対象件数に対する累積処理件数の占める割合である処理進捗率を算出する（Ｓ８０４）。
ここで、処理進捗率は、前記したように現時点での実際の処理進捗率である。
ここで、処理進捗率は、前記したように現時点での実際の処理進捗率である。
処理進捗率＝累積処理件数/全処理対象件数 ・・・ （１）
次に、リソース補正判定処理部１０３は、配備制御サーバ２のバッチアプリケーション毎ロット単位データ処理履歴管理テーブル２１５ａ，２１５ｂ（図１６、図１７）を参照して、処理対象の中間処理データに該当するロット単位データの所要時間を加算することで、中間処理データに含まれるロットの処理にかかった時間を取得し、この時間を累積処理時間とする（Ｓ８０５）。
そして、リソース補正判定処理部１０３は、配備制御サーバ２上のＳＬＡ情報管理テーブル２１１を参照して、各バッチアプリケーションの要求処理時間を取得すると、要求処理時間、累積処理時間から必要進捗率を算出し、該当するバッチアプリケーション名、ステップＳ７０３で取得した処理状態と共に、処理進捗率と必要進捗率とを中間処理進捗率管理テーブル１１２（図２７）に登録する（Ｓ８０６）。ここで、必要進捗率の算出方法は、リソース補正判定処理部１０３が、要求処理時間に対する累積処理時間と全処理件数の比率を求めることで行なわれる。すなわち、必要進捗率は、全処理件数に対する現段階までに処理が行なわれているべき処理件数の割合であり、以下の式（２）で算出されるものである。
必要進捗率＝累積処理時間/要求処理時間 ・・・ （２）
なお、式（２）のバリエーションとして、要求処理時間遵守の確度を高めるために、累積処理時間の代わりに、累積処理時間に安全係数を加味した時間を加えた合計時間を用いてもよい。また、式（１）および式（２）の処理進捗率、必要進捗率のそれぞれに、全処理件数をかけたものを処理進捗率、必要進捗率としてもよい。
次に、リソース補正判定処理部１０３は、算出した処理進捗率と必要進捗率の値を比較し、処理進捗率が必要進捗率未満となるバッチアプリケーション（バッチＡＰ）があるか否かを判定する（Ｓ８０７）。ここで、ステップＳ８０７の処理は、図７のステップＳ１０５に対応する処理である。
ステップＳ８０７の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがない場合（Ｓ８０７→Ｎｏ）、リソース補正判定処理部１０３は。、リソース補正を行なう必要はないと判定し、以降のバッチ処理を続行し（Ｓ８０８）、図７の処理へリターンする。なお、ステップＳ８０８の処理は、図７のステップＳ１０８に対応する処理である。
ステップＳ８０７の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがない場合（Ｓ８０７→Ｎｏ）、リソース補正判定処理部１０３は。、リソース補正を行なう必要はないと判定し、以降のバッチ処理を続行し（Ｓ８０８）、図７の処理へリターンする。なお、ステップＳ８０８の処理は、図７のステップＳ１０８に対応する処理である。
ステップＳ８０７の結果、処理進捗率が必要進捗率未満となるバッチアプリケーションがある場合（Ｓ８０７→Ｙｅｓ）、リソース補正判定処理部１０３は、リソース補正を行なう必要があると判定し、割当てリソース算出処理部１０４を呼び出す（Ｓ８０９）。ステップＳ８０９で呼び出された割当てリソース算出処理部１０４の処理は図２８で後記する。
《中間処理進捗率管理テーブル》
図２７は、本実施形態に係る中間進捗率管理テーブルの例を示す図である。
中間処理進捗率管理テーブル１１２は、各バッチＡＰの中間処理の進捗率を管理するための属性情報として、契機、バッチアプリケーション名（バッチＡＰ名）、各々のバッチアプリケーションにおける稼働状態を示す稼働状態、各々のバッチアプリケーションの必要進捗率を示す必要進捗率、各々のバッチアプリケーションの処理進捗率を示す処理進捗率の各情報を有する。
図２７は、本実施形態に係る中間進捗率管理テーブルの例を示す図である。
中間処理進捗率管理テーブル１１２は、各バッチＡＰの中間処理の進捗率を管理するための属性情報として、契機、バッチアプリケーション名（バッチＡＰ名）、各々のバッチアプリケーションにおける稼働状態を示す稼働状態、各々のバッチアプリケーションの必要進捗率を示す必要進捗率、各々のバッチアプリケーションの処理進捗率を示す処理進捗率の各情報を有する。
《ステップＳ１０６，Ｓ１０７の詳細》
図２８は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図２８の処理は、主に割当てリソース算出処理部１０４が行なう処理である。
まず、リソース補正制御サーバ１は、図２６のステップＳ８０９のリソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４を起動し、起動された割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２(図２７）の必要進捗率と処理進捗率を基に、各バッチアプリケーションにおけるバッチ処理の遅延分の進捗率（以下、遅延回復対象進捗率と称する）を算出する（Ｓ９０１）。なお、割当てリソース算出処理部１０４は、以下の式（３）によって遅延回復対象進捗率を算出する。
図２８は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図２８の処理は、主に割当てリソース算出処理部１０４が行なう処理である。
まず、リソース補正制御サーバ１は、図２６のステップＳ８０９のリソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４を起動し、起動された割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２(図２７）の必要進捗率と処理進捗率を基に、各バッチアプリケーションにおけるバッチ処理の遅延分の進捗率（以下、遅延回復対象進捗率と称する）を算出する（Ｓ９０１）。なお、割当てリソース算出処理部１０４は、以下の式（３）によって遅延回復対象進捗率を算出する。
遅延回復対象進捗率＝必要進捗率−処理進捗率 ・・・ （３）
そして、割当てリソース算出処理部１０４は、配備制御サーバ２のロット単位処理履歴管理テーブル２１５（図１８）を参照し、処理進捗率を得るために使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、ＣＰＵに割当てたリソース量を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、メモリに割当てたリソース量を示すＣＰＵ割当てを取得すると共に、中間処理単位データ管理テーブル１１１（図２５）の契機、バッチアプリケーション名（バッチＡＰ名）、稼働状態を取得し、さらに、リソース情報管理テーブル３１１からバッチアプリケーションの稼働状態を取得し、中間処理リソース割当て管理テーブル１１３（図２９）に登録することによって、中間処理リソース割当て管理テーブル１１３を作成する（Ｓ９０２）。
割当てリソース算出処理部１０４は、図２６のステップＳ８０７で検出された必要進捗率に達していないバッチアプリケーションに対し、ステップＳ９０１で算出した遅延回復対象進捗率と、今回の契機までの処理進捗率を得るために使用した各種リソース情報を基に、補充するリソースの種別、割当て量を算出する（Ｓ９０３）。ステップＳ９０３の詳細は、図３０〜図３３を参照して後記する。
次に、割当てリソース算出処理部１０４は、図３４に示すリソース割当て所要時間管理テーブル１１４を参照し、処理対象となっているバッチアプリケーションのリソース割当て所要時間を取得する（Ｓ９０４）。リソース割当て所要時間管理テーブル１１４については、図３４を参照して後記するが、図１０や、図２８におけるリソースの割り当てが実際に行なわれるたびに、リソース管理サーバ３のリソース割当て処理部３０３によって割当てリソース算出処理部１０４で登録されるテーブルである。
続いて、割当てリソース算出処理部１０４は、リソース割当て所要時間を考慮したリソース量を計算する（Ｓ９０５）。ステップＳ９０５の詳細も、図３０〜図３３を参照して後記する。なお、ステップＳ９０５の処理は図７のステップＳ１０６に含まれる処理である。また、ステップＳ９０５の結果、割当てが不可能であれば、割当てリソース算出処理部１０４は、クライアント端末６に対しエラー出力を行なう。
続いて、割当てリソース算出処理部１０４は、リソース割当て所要時間を考慮したリソース量を計算する（Ｓ９０５）。ステップＳ９０５の詳細も、図３０〜図３３を参照して後記する。なお、ステップＳ９０５の処理は図７のステップＳ１０６に含まれる処理である。また、ステップＳ９０５の結果、割当てが不可能であれば、割当てリソース算出処理部１０４は、クライアント端末６に対しエラー出力を行なう。
そして、割当てリソース算出処理部１０４は、リソース管理サーバ３に緊急運用リソース（予備）からリソースを補充するよう指示し、リソース管理サーバ３のリソース割当て処理部３０３がリソース情報管理テーブル３１１を参照し、緊急運用リソースからリソースを補充して（Ｓ９０６）、図２６の処理へリターンする。なお、ステップＳ９０６の処理は、図７のステップＳ１０７に対応する処理である。
《中間処理リソース割当て管理テーブル》
図２９は、本実施形態に係る中間処理リソース割当て管理テーブルの例を示す図である。
中間処理リソース割当て管理テーブル１１３は、ロット単位で使用してリソース情報を中間処理単位で使用してリソース情報に置き換えて管理するためのテーブルであり、管理する属性情報として、契機、バッチアプリケーション名（図２９では、バッチＡＰ名と表記）、稼働状態、中間処理単位で使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
なお、図２９の中間処理リソース割当て管理テーブル１１３では、ディスク種別やディスク割当ての属性情報が示されていないが、図９のリソース情報管理テーブル３１１の説明で補足した通り、ディスク種別やディスク割当ての情報が含まれていても構わない。
図２９は、本実施形態に係る中間処理リソース割当て管理テーブルの例を示す図である。
中間処理リソース割当て管理テーブル１１３は、ロット単位で使用してリソース情報を中間処理単位で使用してリソース情報に置き換えて管理するためのテーブルであり、管理する属性情報として、契機、バッチアプリケーション名（図２９では、バッチＡＰ名と表記）、稼働状態、中間処理単位で使用した実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、実行仮想サーバ５を割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当ての各情報を有する。
なお、図２９の中間処理リソース割当て管理テーブル１１３では、ディスク種別やディスク割当ての属性情報が示されていないが、図９のリソース情報管理テーブル３１１の説明で補足した通り、ディスク種別やディスク割当ての情報が含まれていても構わない。
《リソース割当ての概念図》
次に、図３０〜図３３を参照して、第１実施形態に係るリソース割当ての概念を説明する。
図３０および図３１は、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）が稼働している状態における、契機毎のリソース割当ての例を示すものである。
ここで、図３０は、実行仮想サーバ５におけるバッチアプリケーションの推移を示す図であり、図３１は、中間処理リソース割当て管理テーブル１１３および中間処理進捗率管理テーブル１１２の推移を示す図である。
図３０では、横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
なお、図３０および図３１は、すべての時間で処理進捗率が必要進捗率と一致している場合である。
次に、図３０〜図３３を参照して、第１実施形態に係るリソース割当ての概念を説明する。
図３０および図３１は、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）が稼働している状態における、契機毎のリソース割当ての例を示すものである。
ここで、図３０は、実行仮想サーバ５におけるバッチアプリケーションの推移を示す図であり、図３１は、中間処理リソース割当て管理テーブル１１３および中間処理進捗率管理テーブル１１２の推移を示す図である。
図３０では、横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
なお、図３０および図３１は、すべての時間で処理進捗率が必要進捗率と一致している場合である。
尚、図３１、図３３および後記する図３７では、煩雑になるのを防ぐため中間処理リソース割当て管理テーブル１１３の契機、ＣＰＵ種別、メモリ種別およびメモリ割当ての欄を省略し、バッチＡＰ名の欄は「ＡＰ」と記載し、稼働状態の欄は「状態」と省略している。同様に煩雑になるのを避けるため、中間処理進捗率管理テーブル１１２の契機の欄を省略し、バッチＡＰ名の欄「ＡＰ」と記載し、稼働状態の欄を「状態」と省略している。
また、バッチアプリケーション名も「ＡＰ１」、「ＡＰ２」、「ＡＰ３」と省略する。
また、バッチアプリケーション名も「ＡＰ１」、「ＡＰ２」、「ＡＰ３」と省略する。
図３１において「Ｔ０」の段階における中間処理リソース割当て管理テーブル１１３ａより、「バッチＡＰ２」および「バッチＡＰ３」の稼働状態が「準備中」であるため、すべてのリソースを「バッチＡＰ１」が占有できることを示している。
そして、リソース補正判定処理部１０３は、次の契機の「Ｔ０」の時点で算出された中間処理進捗率（必要進捗率および処理進捗率）を中間処理進捗割当て管理テーブル１１２ａとして登録する。同様にして、配備制御サーバ２は、「Ｔ１」以降の契機（「Ｔ１」〜「Ｔ４」）についても、中間処理リソース割当て管理テーブル１１３ｂ〜１１３ｅを参照して、稼働状態（「状態」）が実行中であるか否かを基に、バッチアプリケーションに対してリソースを割当て、リソース補正判定処理部１０３は処理結果に従って中間処理進捗率管理テーブル１１２ｂ〜１１２ｅの値を随時更新しながら、それぞれの実行仮想サーバ５はバッチ処理を継続する（図３０の「Ｔ２」〜Ｔ４」））。前記したように、図３０および図３１に示す例では、すべての契機（「Ｔ１」〜「Ｔ４」）で必要進捗率に処理進捗率が達しているので、予定通り処理が進行しており、新たなリソースの補充の必要がないことを示している。
なお、契機「Ｔ５」については、契機「Ｔ４」と同様のリソース状態となるため、図示することを省略する。
そして、リソース補正判定処理部１０３は、次の契機の「Ｔ０」の時点で算出された中間処理進捗率（必要進捗率および処理進捗率）を中間処理進捗割当て管理テーブル１１２ａとして登録する。同様にして、配備制御サーバ２は、「Ｔ１」以降の契機（「Ｔ１」〜「Ｔ４」）についても、中間処理リソース割当て管理テーブル１１３ｂ〜１１３ｅを参照して、稼働状態（「状態」）が実行中であるか否かを基に、バッチアプリケーションに対してリソースを割当て、リソース補正判定処理部１０３は処理結果に従って中間処理進捗率管理テーブル１１２ｂ〜１１２ｅの値を随時更新しながら、それぞれの実行仮想サーバ５はバッチ処理を継続する（図３０の「Ｔ２」〜Ｔ４」））。前記したように、図３０および図３１に示す例では、すべての契機（「Ｔ１」〜「Ｔ４」）で必要進捗率に処理進捗率が達しているので、予定通り処理が進行しており、新たなリソースの補充の必要がないことを示している。
なお、契機「Ｔ５」については、契機「Ｔ４」と同様のリソース状態となるため、図示することを省略する。
次に、図３２および図３３を参照して、処理に遅延が生じている場合のリソース補正について説明する。なお、図３２および図３３について、図３０および図３１と同様の要素については、同一の符号を付して説明を省略する。
図３２および図３３は、図３０および図３１と同様の図であるが、図３３の「Ｔ２」の段階で、「バッチＡＰ３」は、必要処理進捗率が５０％であるのに対し、処理進捗率が４０％までしか達しておらず、１０％分の処理遅延（遅延回復対象進捗率）が発生していることを示している（中間処理進捗率管理テーブル１１２ｆの符号３３０１）。「Ｔ２」時点の中間処理リソース割当て管理テーブル１１３ｃから、「バッチＡＰ３」に割当てられたＣＰＵは、１コアであったことが分かり、この状態で「Ｔ２」で４０％の処理進捗率を得ている。従って、割当てリソース算出処理部１０４は、もう１コア追加することで１０％分の処理遅延を埋めることができると判定する。さらに、割当てリソース算出処理部１０４はリソース割当てに必要な時間であるリソース割当て所要時間を考慮してリソース量を計算する（図２８のステップＳ９０５）。
図３２および図３３は、図３０および図３１と同様の図であるが、図３３の「Ｔ２」の段階で、「バッチＡＰ３」は、必要処理進捗率が５０％であるのに対し、処理進捗率が４０％までしか達しておらず、１０％分の処理遅延（遅延回復対象進捗率）が発生していることを示している（中間処理進捗率管理テーブル１１２ｆの符号３３０１）。「Ｔ２」時点の中間処理リソース割当て管理テーブル１１３ｃから、「バッチＡＰ３」に割当てられたＣＰＵは、１コアであったことが分かり、この状態で「Ｔ２」で４０％の処理進捗率を得ている。従って、割当てリソース算出処理部１０４は、もう１コア追加することで１０％分の処理遅延を埋めることができると判定する。さらに、割当てリソース算出処理部１０４はリソース割当てに必要な時間であるリソース割当て所要時間を考慮してリソース量を計算する（図２８のステップＳ９０５）。
この処理は、例えば、以下のように行なわれる。
次の契機「Ｔ３」は、未来の時間であり、何時間後にＴ３となるのかをリソース補正制御サーバ１は知ることができないので、「Ｔ２」後、「Ｔ２」−「Ｔ１」時間後に次の契機「Ｔ３」となると仮定してリソース補正制御サーバ１は計算する。
つまり、「Ｔ１」→「Ｔ２」が仮に１時間であったとすると、「Ｔ２」から１時間後に「Ｔ３」となると仮定することになる。
次の契機「Ｔ３」は、未来の時間であり、何時間後にＴ３となるのかをリソース補正制御サーバ１は知ることができないので、「Ｔ２」後、「Ｔ２」−「Ｔ１」時間後に次の契機「Ｔ３」となると仮定してリソース補正制御サーバ１は計算する。
つまり、「Ｔ１」→「Ｔ２」が仮に１時間であったとすると、「Ｔ２」から１時間後に「Ｔ３」となると仮定することになる。
中間処理進捗率管理テーブル１１２ｂ，１１２ｆから、バッチアプリケーション「ＡＰ３」は、１時間で４０％の処理進捗率であるので、１つの実行仮想サーバ４は、次の契機「Ｔ３」の１時間で４０％の処理進捗率を得ることができることになる。
図３２の「Ｔ２」に示すように「バッチＡＰ３（ＡＰ３）」を実行する実行仮想サーバ３２０１を増やすことで、２つの実行仮想サーバ４で「バッチＡＰ３」を実行することになる（中間処理リソース割当て管理テーブル１１３ｆの符号３３０２）。すると、次の１時間では８０％と２倍の処理進捗率を得ることとなる。従って、「バッチＡＰ３」が完了する時間は、「Ｔ２」後、（６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間が、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。処理進捗率１００％を達成することができないと判定された場合、緊急運用リソース(予備）に余裕があれば、割当てリソース算出処理部１０４は、さらに実行仮想サーバ４を増やして、再度計算してもよいし、緊急運用リソース(予備）に余裕がなければ、クライアント端末６に対してエラー出力を行なう。
図３２の「Ｔ２」に示すように「バッチＡＰ３（ＡＰ３）」を実行する実行仮想サーバ３２０１を増やすことで、２つの実行仮想サーバ４で「バッチＡＰ３」を実行することになる（中間処理リソース割当て管理テーブル１１３ｆの符号３３０２）。すると、次の１時間では８０％と２倍の処理進捗率を得ることとなる。従って、「バッチＡＰ３」が完了する時間は、「Ｔ２」後、（６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間が、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。処理進捗率１００％を達成することができないと判定された場合、緊急運用リソース(予備）に余裕があれば、割当てリソース算出処理部１０４は、さらに実行仮想サーバ４を増やして、再度計算してもよいし、緊急運用リソース(予備）に余裕がなければ、クライアント端末６に対してエラー出力を行なう。
次の契機の「Ｔ３」までに処理進捗率１００％を達成することができれば、割当てリソース算出処理部１０４は、リソース管理サーバ３へリソース割当てを指示し、リソース管理サーバ３のリソース割当て処理部３０３は、緊急運用リソース(予備）から１コア分のリソースを確保して、新たに「バッチＡＰ３」を実行する実行仮想サーバ３２０１を起動する(図２８のステップＳ９０６）。この結果、図３３より「Ｔ３」の段階では、処理進捗率が必要進捗率に追いついて１００％に達し、要求処理時間内にバッチ処理を終了させることに成功している。さらに、「バッチＡＰ１」は、「Ｔ３」において処理進捗率、必要進捗率共に８０％であるため、「バッチＡＰ１」については新たなリソースが必要なわけではないため、実行仮想サーバ３２０１は、「バッチＡＰ３」の終了後、割当てリソース算出処理部１０４によって解放され緊急運用リソース上にプールされる。
ここでは、契機「Ｔ３」直後に要求処理時間がくることを想定しているが、例えば、要求処理時間が「Ｔ２」後、２時間後であれば、割当てリソース算出処理部１０４は、前記したように「Ｔ３」が「Ｔ２」後、１時間後であると仮定して、その時点の必要進捗率および処理進捗率を計算した上で、「Ｔ３」での進捗率が必要進捗率に達するか否かを判定してもよい。
また、実行仮想サーバ５に性能差がある場合は、各実行仮想サーバ５の性能を考慮してもよい。
また、実行仮想サーバ５に性能差がある場合は、各実行仮想サーバ５の性能を考慮してもよい。
なお、また、図３０〜図３３では、ＣＰＵ割当てを基に、リソース割当ての要・不要を判定しているが、同様にして、メモリやディスクなどのリソースを基にリソース割当ての要・不要を判定してよい。さらに、図３３では、割当てるＣＰＵのコア数を例に説明したが、割当てるリソース量の他に、ＣＰＵ種別やメモリ種別などのスペック名称を考慮に入れた割当てを行なうものとしても構わない。
《リソース割当て所要時間履歴管理テーブル》
図３４は、本実施形態に係るリソース割当て所要時間管理テーブルの例を示す図である。
リソース割当て所要時間管理テーブル１１４は、リソースの割当てや切離しにかかる時間の履歴を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、該当する実行仮想サーバ５が実行されている実行物理サーバ５のＣＰＵのスペック名称を示すＣＰＵ種別、割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別の各情報を有している。リソース割当て所要時間管理テーブル１１４は、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、リソース割当てにかかる時間を示す割当て所要時間、リソース切離しかかる時間を示す切離し所要時間の各情報をさらに有する。なお、リソース割当て所要時間管理テーブル１１４では、ディスク種別やディスク割当ての属性情報が示されていないが、含まれていても構わない。さらに、各仮想サーバに配備するバッチアプリケーションの配備時間も併せて管理して、算出の際に考慮するものとしても構わない。
図３４は、本実施形態に係るリソース割当て所要時間管理テーブルの例を示す図である。
リソース割当て所要時間管理テーブル１１４は、リソースの割当てや切離しにかかる時間の履歴を管理するための属性情報として、実行物理サーバ名、実行仮想サーバ名、該当する実行仮想サーバ５が実行されている実行物理サーバ５のＣＰＵのスペック名称を示すＣＰＵ種別、割当てたＣＰＵのコア数を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別の各情報を有している。リソース割当て所要時間管理テーブル１１４は、実行仮想サーバ５に割当てたメモリの容量を示すメモリ割当て、通常運用時に使用するリソースであるか、あるいは、緊急運用時に使用するリソースであるかを示すリソース種別、リソース割当てにかかる時間を示す割当て所要時間、リソース切離しかかる時間を示す切離し所要時間の各情報をさらに有する。なお、リソース割当て所要時間管理テーブル１１４では、ディスク種別やディスク割当ての属性情報が示されていないが、含まれていても構わない。さらに、各仮想サーバに配備するバッチアプリケーションの配備時間も併せて管理して、算出の際に考慮するものとしても構わない。
［第２実施形態］
次に、図３５〜図３７を参照して、本発明の第２実施形態について説明する。
第１実施形態では、リソース補正制御サーバ１上で稼働する割当てリソース算出処理部１０４は、必要進捗率に達していない（処理遅延が生じている）バッチアプリケーションに対し、緊急運用リソースから新たに補充するリソースと割当て量を算出し、割当てを行なうものであったが、第２実施形態においては、通常運用リソース上で稼働するバッチアプリケーションから処理進捗率に余裕があるバッチアプリケーションを割り出し、必要進捗率に達していないバッチアプリケーションと置換するものである。
次に、図３５〜図３７を参照して、本発明の第２実施形態について説明する。
第１実施形態では、リソース補正制御サーバ１上で稼働する割当てリソース算出処理部１０４は、必要進捗率に達していない（処理遅延が生じている）バッチアプリケーションに対し、緊急運用リソースから新たに補充するリソースと割当て量を算出し、割当てを行なうものであったが、第２実施形態においては、通常運用リソース上で稼働するバッチアプリケーションから処理進捗率に余裕があるバッチアプリケーションを割り出し、必要進捗率に達していないバッチアプリケーションと置換するものである。
《ステップＳ１０６，Ｓ１０７の詳細》
図３５は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図３５の処理は、主に割当てリソース算出処理部１０４が行なう処理であり、第１実施形態の図２８の処理に対応する処理である。
リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２の終了メッセージを検知し、割当てリソース算出処理部１０４を起動し、起動した割当てリソース算出処理部１０４が算出した必要進捗率と処理進捗率の差分(式（３））を算出する（Ｓ１００１）ことにより、遅延回復対象進捗率を算出する。図２８のステップＳ９０１では、リソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４が起動しているが、第２実施形態では、図２６のステップＳ８０９において、中間処理単位データ取得処理部１０２が発した終了メッセージを基に、割当てリソース算出処理部１０４が起動している。
図３５は、図７のステップＳ１０６，Ｓ１０７の処理の詳細な手順を示すフローチャートである。図３５の処理は、主に割当てリソース算出処理部１０４が行なう処理であり、第１実施形態の図２８の処理に対応する処理である。
リソース補正制御サーバ１は、中間処理単位データ取得処理部１０２の終了メッセージを検知し、割当てリソース算出処理部１０４を起動し、起動した割当てリソース算出処理部１０４が算出した必要進捗率と処理進捗率の差分(式（３））を算出する（Ｓ１００１）ことにより、遅延回復対象進捗率を算出する。図２８のステップＳ９０１では、リソース補正判定処理部１０３による呼出しにより、割当てリソース算出処理部１０４が起動しているが、第２実施形態では、図２６のステップＳ８０９において、中間処理単位データ取得処理部１０２が発した終了メッセージを基に、割当てリソース算出処理部１０４が起動している。
次に、割当てリソース算出処理部１０４は、図２８のステップＳ９０２と同様に、アプリケーション配備制御サーバ２上の図１８に示すロット単位処理履歴管理テーブル２１５を参照し、処理進捗率の算出対象となっている（すなわち、バッチアプリケーションの置換対象となっている）実行物理サーバ４のＣＰＵのスペック名称を示すＣＰＵ種別、ＣＰＵに割当てたリソース量を示すＣＰＵ割当て、メモリのスペック名称を示すメモリ種別、メモリに割当てたリソース量を示すＣＰＵ割当てを取得すると共に、中間処理単位データ管理テーブル１１１（図２５）の契機、バッチアプリケーション名（バッチＡＰ名）、稼働状態を取得し、さらに、リソース情報管理テーブル３１１からバッチアプリケーションの稼働状態を取得し、（図２９）に登録することによって、中間処理リソース割当て管理テーブル１１３を作成する（Ｓ１００２）。
続いて、割当てリソース算出処理部１０４は、図２６のステップＳ８０７で検出された必要進捗率に達していないバッチアプリケーションに対し、ステップＳ１００１で算出した必要進捗率と処理進捗率の差分の値（遅延回復対象進捗率）と、今回の処理進捗率を得るために使用した各種リソースの種別、割当て量を基に、切離し可能な余剰リソースと補充リソースの量を算出する（Ｓ１００３）。ステップＳ１００３の詳細は、図３６および図３７を参照して後記する。
そして、割当てリソース算出処理部１０４は、図３４に示すリソース割当て所要時間履歴管理テーブル２４００を参照し、処理対象となっているバッチアプリケーションのリソース割当てにかかる時間（割当て所要時間）と切離しにかかる時間(切離し所要時間）を取得する（Ｓ１００４）。
そして、割当てリソース算出処理部１０４は、図３４に示すリソース割当て所要時間履歴管理テーブル２４００を参照し、処理対象となっているバッチアプリケーションのリソース割当てにかかる時間（割当て所要時間）と切離しにかかる時間(切離し所要時間）を取得する（Ｓ１００４）。
続いて、割当てリソース算出処理部１０４は、割当て所要時間と切離し所要時間を考慮したリソース量を計算する（Ｓ１００５）。ステップＳ１００５の詳細も、図３６〜図３７を参照して後記する。なお、ステップＳ１００５の処理は図７のステップＳ１０６に対応する処理である。
そして、割当てリソース算出処理部１０４は、通常運用リソース上で稼働する余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、遅延回復が必要なバッチアプリケーション（バッチＡＰ）にリソースを補充するよう指示し、リソース管理サーバ３のリソース割当て処理部３０３がリソース情報管理テーブル３１１を参照し、余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、緊急運用リソースからリソースを補充して（Ｓ１００６）、図２６の処理へリターンする。なお、ステップＳ１００７の処理は、図７のステップＳ１０８に対応する処理である。
そして、割当てリソース算出処理部１０４は、通常運用リソース上で稼働する余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、遅延回復が必要なバッチアプリケーション（バッチＡＰ）にリソースを補充するよう指示し、リソース管理サーバ３のリソース割当て処理部３０３がリソース情報管理テーブル３１１を参照し、余剰リソースを持つバッチアプリケーション（バッチＡＰ）からリソースを切離し、緊急運用リソースからリソースを補充して（Ｓ１００６）、図２６の処理へリターンする。なお、ステップＳ１００７の処理は、図７のステップＳ１０８に対応する処理である。
《リソース割当ての概念図》
次に、図３６および図３７を参照して、第２実施形態に係るリソース割当ての概念を説明する。
図３６および図３７は、通常運用リソース上から余剰リソースを捻出して、遅延が発生しているバッチアプリケーションにリソース割当てを行なう流れを示す概念図である。なお、図３６および図３７において、図３０〜図３３と同様の要素については、同一の符号を付して説明を省略する。
図３６および図３７では、、図３０〜図３３と同様に、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）を稼働している状態における、契機毎のリソース割当てを示すものである。
また、図３６では、図３０と同様に横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
次に、図３６および図３７を参照して、第２実施形態に係るリソース割当ての概念を説明する。
図３６および図３７は、通常運用リソース上から余剰リソースを捻出して、遅延が発生しているバッチアプリケーションにリソース割当てを行なう流れを示す概念図である。なお、図３６および図３７において、図３０〜図３３と同様の要素については、同一の符号を付して説明を省略する。
図３６および図３７では、、図３０〜図３３と同様に、１コアのＣＰＵが割り当てられた実行仮想サーバ５が４台存在する環境下で、３つのバッチアプリケーション（「バッチＡＰ１」〜「バッチＡＰ３」）を稼働している状態における、契機毎のリソース割当てを示すものである。
また、図３６では、図３０と同様に横方向に並んでいる実行仮想サーバ５は同じ実行仮想サーバ５を表しているものとする。
ここで、図３３で示した例と同様にして、「Ｔ２」の段階で、「バッチＡＰ３（ＡＰ３）」は、必要処理進捗率が５０％であるのに対し、処理進捗率が４０％までしか達しておらず、１０％分の処理遅延（遅延回復対象進捗率）が発生しているものとする（中間処理進捗率管理テーブル１１２ｇの符号３７０１）。「Ｔ２」で処理進捗率４０％を得るために使用したリソースは、「Ｔ２」時点の中間処理リソース割当て管理テーブル１１３より、１コア分のＣＰＵ割当てであったことが分かり、１０％分の遅延回復に必要な補充リソース量は、１コア分のＣＰＵ割当てである。
一方で、切離し可能な余剰リソースの算出については、「Ｔ２」の段階で、「バッチＡＰ１（ＡＰ１）」は、必要処理進捗率が５０％であるのに対し、処理進捗率が６６％まで達しており、１６％分の余裕があることが分かる（中間処理進捗率管理テーブル１１２ｈの符号３７０２）。さらに、「バッチＡＰ１」は、「Ｔ１」の中間処理進捗率管理テーブル１１２ｂと「Ｔ２」の中間処理リソース割当て管理テーブル１１３ｃから、２コアのＣＰＵ割当てで、３０％から６６％の進捗率を得ており、１コアのＣＰＵ割当てで（６６−３０）／２＝１８％の進捗を得られていることが分かる（中間処理進捗率管理テーブル１１２ｇの符号３７０２）。従って、「Ｔ２」の段階で、「バッチＡＰ１」は、１８％分上回っている進捗率に該当するリソース、つまり切離し可能な余剰リソースは、１コア分のＣＰＵ割当てである。
従って、「Ｔ３」の段階で、「バッチＡＰ３」の処理遅延の回復に必要なリソースを、「バッチＡＰ１」から１コア分のＣＰＵ（図３６の実行仮想サーバ３６０１）を切り離して、「バッチＡＰ３」に割当てることで、通常運用リソース上でリソース融通することが可能になる（図３６）。つまり、実行仮想サーバ３６０１で実行されているバッチアプリケーションを「バッチＡＰ１」から「バッチＡＰ３」に置換する。
なお、融通可能なリソースがない場合は、第１実施形態と同様の処理を行なうことで緊急リソースから融通することとなる。
なお、融通可能なリソースがない場合は、第１実施形態と同様の処理を行なうことで緊急リソースから融通することとなる。
以下、図３７を参照して、具体的なリソース割当てを説明する。
まず、割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２ｇから「バッチＡＰ３（ＡＰ３）」の処理遅延が１０％であり、「バッチＡＰ１（ＡＰ１）」の処理進捗率に１６％の余裕があるので、「バッチＡＰ１」→「バッチＡＰ３」の置換を試みる。
まず、割当てリソース算出処理部１０４は、中間処理進捗率管理テーブル１１２ｇから「バッチＡＰ３（ＡＰ３）」の処理遅延が１０％であり、「バッチＡＰ１（ＡＰ１）」の処理進捗率に１６％の余裕があるので、「バッチＡＰ１」→「バッチＡＰ３」の置換を試みる。
そして、割当てリソース算出処理部１０４は以下の手順で、「バッチＡＰ１」→「バッチＡＰ３」の置換を行なっても、「バッチＡＰ１」、「バッチＡＰ３」共に要求処理時間を満たすことができるか否かを判定する。なお、第１実施形態と同様に「Ｔ１」から「Ｔ２」の間は１時間であるとする。
また、「バッチＡＰ１（ＡＰ１）」は、ＣＰＵ２コアを使用して「Ｔ１」から「Ｔ２」にかけて６６−３０＝３６％の処理進捗率を得ているので、１コアで１８％の進捗率を得ていると、割当てリソース算出処理部１０４は判定する。
そして、割当てリソース算出処理部１０４は、「バッチＡＰ１」を１コアに減じても、要求処理時間を満たすことができるか否かを判定する。
第１実施形態で前記したように、リソース補正制御サーバ１は未来の契機である「Ｔ３」がいつになるのかを知ることができないため、割当てリソース算出処理部１０４は、「Ｔ２」後、「Ｔ２」−「Ｔ１」で「Ｔ３」となると仮定する。
そして、割当てリソース算出処理部１０４は、「バッチＡＰ１」を１コアに減じても、要求処理時間を満たすことができるか否かを判定する。
第１実施形態で前記したように、リソース補正制御サーバ１は未来の契機である「Ｔ３」がいつになるのかを知ることができないため、割当てリソース算出処理部１０４は、「Ｔ２」後、「Ｔ２」−「Ｔ１」で「Ｔ３」となると仮定する。
「バッチＡＰ１」は、「Ｔ１」→「Ｔ２」で１コアあたり１８％の処理進捗率を得ているので、「Ｔ３」の時点では６６＋１８＝８４％の処理進捗率を得られると、割当てリソース算出処理部１０４は算出する。また、必要進捗率は、「Ｔ１」の時点で３０％であり、「Ｔ２」の時点で５０％であるので、同じ割合で必要進捗率が進むと仮定し、「Ｔ３」では、７０％の必要進捗率となると割当てリソース算出処理部１０４は算出する。
従って、「バッチＡＰ１」は、ＣＰＵを１コアに減じても、「Ｔ３」の時点で、なお８４％−７０％＝１４％の余裕があるため、「バッチＡＰ１」に関しては、ＣＰＵを１コアに減じても要求処理時間を満たすことができると、割当てリソース算出処理部１０４は判定する。
従って、「バッチＡＰ１」は、ＣＰＵを１コアに減じても、「Ｔ３」の時点で、なお８４％−７０％＝１４％の余裕があるため、「バッチＡＰ１」に関しては、ＣＰＵを１コアに減じても要求処理時間を満たすことができると、割当てリソース算出処理部１０４は判定する。
なお、「Ｔ２」→「Ｔ３」で「バッチＡＰ１」を「バッチＡＰ３」に置換される実行仮想サーバ５は、既に起動されているものであるので、割当て所要時間や、切離し所要時間を考慮することはない。また、置換される実行仮想サーバ５は、「バッチＡＰ１」を実行している実行仮想サーバ５であれば、どれでもよいが、リソース管理サーバ３のリソース割当て処理部３０３は、付されている番号の若い順に選択したり、実行仮想サーバ５間に性能差が存在する場合は、一番性能の低い実行仮想サーバ５を選択したりする。
一方、「バッチＡＰ３」は、第１実施形態と同様に、「Ｔ１」→「Ｔ２」の間で４０％の処理進捗率を得ているため、「Ｔ２」→「Ｔ３」ではＣＰＵが２コアになることにより、４０×２＝８０％の処理進捗率を得ることができると、割当てリソース算出処理部１０４は判定する。
つまり、「Ｔ３」の時点の処理進捗率は、４０％（「Ｔ２」の時点の処理進捗率）＋８０％＝１２０％となり、２０％の余裕が発生する。
実際に、ＣＰＵのコア数を２倍にしたとき、すなわち、「バッチＡＰ３」を実行する実行仮想サーバ５の数を２倍にしたとき、処理進捗率が１００％となるのは、「Ｔ２」後、何分であるかを計算すると、６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間と、リソース切離し所要時間を加算したものが、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。
つまり、「Ｔ３」の時点の処理進捗率は、４０％（「Ｔ２」の時点の処理進捗率）＋８０％＝１２０％となり、２０％の余裕が発生する。
実際に、ＣＰＵのコア数を２倍にしたとき、すなわち、「バッチＡＰ３」を実行する実行仮想サーバ５の数を２倍にしたとき、処理進捗率が１００％となるのは、「Ｔ２」後、何分であるかを計算すると、６０％／８０％）×６０分＝４５分となる。
従って、リソース割当て所要時間と、リソース切離し所要時間を加算したものが、１５分より大きければ「Ｔ３」までに処理進捗率１００％を達成することができず、リソース割当て所要時間が、１５分以下であれば「Ｔ３」までに処理進捗率１００％を達成することができる。
《まとめ》
本実施形態によれば、複数のバッチアプリケーションが共存する環境下において、実行中のバッチ処理に処理遅延が発生した場合であっても、中間処理履歴より、処理遅延の回復に必要なリソースを同定し、拡充することで、次の分割単位から拡充したリソース上でバッチ処理を実行することができるため、個々のバッチ処理の要求処理時間（ＳＬＡ）を遵守する確度を高めることができる。また、要求処理時間遵守のために必要な実行中のバッチ処理の進捗率の検査や、割当てリソースの見直しを必要最小限に抑えることでバッチ処理のスループット低下を防止することも併せて実現することができる。さらに、中間処理履歴から算出した処理進捗率を基に、処理に余裕のあるバッチ処理のリソースを、遅延が発生しているバッチ処理に融通することができ、システム全体のリソースを有効活用することもできるようになる。
本実施形態によれば、複数のバッチアプリケーションが共存する環境下において、実行中のバッチ処理に処理遅延が発生した場合であっても、中間処理履歴より、処理遅延の回復に必要なリソースを同定し、拡充することで、次の分割単位から拡充したリソース上でバッチ処理を実行することができるため、個々のバッチ処理の要求処理時間（ＳＬＡ）を遵守する確度を高めることができる。また、要求処理時間遵守のために必要な実行中のバッチ処理の進捗率の検査や、割当てリソースの見直しを必要最小限に抑えることでバッチ処理のスループット低下を防止することも併せて実現することができる。さらに、中間処理履歴から算出した処理進捗率を基に、処理に余裕のあるバッチ処理のリソースを、遅延が発生しているバッチ処理に融通することができ、システム全体のリソースを有効活用することもできるようになる。
１ リソース補正制御サーバ（リソース管理装置）
２ 配備制御サーバ
３ リソース管理サーバ
４ 実行物理サーバ
５ 実行仮想サーバ
６ クライアント装置
１０ 計算機システム
１０１ 再検査契機取得処理部
１０２ 中間処理単位データ取得処理部
１０３ リソース補正判定処理部
１０４ 割当てリソース算出処理部
１１１ 中間処理単位データ管理テーブル
１１２ 中間処理進捗率管理テーブル
１１３ 中間処理リソース割当て管理テーブル
１１４ リソース割当て所要時間管理テーブル
２０１ ＳＬＡ情報管理部
２０２ 配備アプリケーション情報管理部
２０３ アプリケーション・データ配備処理部
２１１ ＳＬＡ情報管理テーブル
２１２ 処理対象データ管理テーブル
２１３ 配備アプリケーション管理テーブル
２１４ バッチ単位処理履歴管理テーブル
２１５ ロット単位処理履歴管理テーブル
２１５ａ，２１６ａ バッチアプリケーション毎ロット単位処理履歴管理テーブル
３０１ リソース情報管理部
３０２ アプリケーション構成情報管理部
３０３ リソース割当て処理部
３１１ リソース情報管理テーブル
３１２ 仮想マシンイメージ管理領域
５０１ バッチアプリケーションプログラム
２ 配備制御サーバ
３ リソース管理サーバ
４ 実行物理サーバ
５ 実行仮想サーバ
６ クライアント装置
１０ 計算機システム
１０１ 再検査契機取得処理部
１０２ 中間処理単位データ取得処理部
１０３ リソース補正判定処理部
１０４ 割当てリソース算出処理部
１１１ 中間処理単位データ管理テーブル
１１２ 中間処理進捗率管理テーブル
１１３ 中間処理リソース割当て管理テーブル
１１４ リソース割当て所要時間管理テーブル
２０１ ＳＬＡ情報管理部
２０２ 配備アプリケーション情報管理部
２０３ アプリケーション・データ配備処理部
２１１ ＳＬＡ情報管理テーブル
２１２ 処理対象データ管理テーブル
２１３ 配備アプリケーション管理テーブル
２１４ バッチ単位処理履歴管理テーブル
２１５ ロット単位処理履歴管理テーブル
２１５ａ，２１６ａ バッチアプリケーション毎ロット単位処理履歴管理テーブル
３０１ リソース情報管理部
３０２ アプリケーション構成情報管理部
３０３ リソース割当て処理部
３１１ リソース情報管理テーブル
３１２ 仮想マシンイメージ管理領域
５０１ バッチアプリケーションプログラム
Claims (16)
- バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置におけるリソース管理方法であって、
前記リソース管理装置は、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめ、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定し、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するために必要なリソースを算出する
ことを特徴とするリソース管理方法。 - 前記所定の時刻は、実行されているアプリケーションの処理開始時刻および処理終了時刻である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記再検査の契機は、定期的な時刻である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記処理進捗率は、現在までに行なっている処理件数を、全処理対象件数で除算したものである
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記必要処理件数は、現在までの処理時間を、前記要求処理時間で除算したものである
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記リソースとは、ＣＰＵのコア数、メモリ割当て数またはディスク割当て数である
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記リソース管理装置は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記リソース管理装置は、
前記リソース量を算出する際に、前記バッチアプリケーションの割当てに必要な時間を考慮する
ことを特徴とする請求の範囲第７項に記載のリソース管理方法。 - 前記リソース管理装置は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１項に記載のリソース管理方法。 - 前記リソース管理装置は、
前記リソース量を算出する際に、前記バッチアプリケーションの割当てに必要な時間と、前記バッチアプリケーションを切り離すために必要な時間と、を考慮する
ことを特徴とする請求の範囲第９項に記載のリソース管理方法。 - バッチアプリケーションの配置に必要なリソースの計算を行なうリソース管理装置であって、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめる中間処理単位データ取得処理部と、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部と、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するため必要なリソースを算出する割当てリソース算出処理部と、
を有することを特徴とするリソース管理装置。 - 前記割当てリソース算出処理部は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１１項に記載のリソース管理装置。 - 前記割当てリソース算出処理部は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１１項に記載のリソース管理装置。 - バッチアプリケーションの配置に必要なリソースの計算を行なうためにコンピュータを、
所定の時刻において、処理が完了しているバッチ処理のデータを１つのデータ群とすることにより中間処理単位としてまとめる中間処理単位データ取得処理部、
前記中間処理単位を用いて、現在時刻における処理の進捗率である処理進捗率と、前記処理進捗率が、要求処理時間内に前記バッチ処理を終了するために必要な進捗率である必要進捗率に達しているか否かを判定するリソース補正判定処理部、
前記判定の結果、前記必要な進捗率に達していない場合、前記必要進捗率および前記処理進捗率の差分である遅延回復対象進捗率と、リソースの情報と、を基に、前記要求処理時間前に前記処理進捗率が前記必要進捗率に達するため必要なリソースを算出する割当てリソース算出処理部
として機能させることを特徴とするプログラム。 - 前記割当てリソース算出処理部は、
前記処理進捗率が、前記必要進捗率に達していない場合、予め設定しておいた予備のリソースに前記バッチアプリケーションを割当てたときのリソース量を算出する
ことを特徴とする請求の範囲第１４項に記載のプログラム。 - 前記割当てリソース算出処理部は、
複数の前記リソースで、前記バッチアプリケーションが実行されている場合において、
あるバッチアプリケーションが前記処理進捗率が、前記必要進捗率に達していない場合、前記処理進捗率が、前記必要進捗率に達しているリソースに対し、当該リソースで実行されているバッチアプリケーションを、前記記処理進捗率が、前記必要進捗率に達していないバッチアプリケーションに置換したときのリソース量を算出する
ことを特徴とする請求の範囲第１４項に記載のプログラム。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2010/058196 WO2011142031A1 (ja) | 2010-05-14 | 2010-05-14 | リソース管理方法、リソース管理装置およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2011142031A1 true JPWO2011142031A1 (ja) | 2013-07-22 |
| JP5815512B2 JP5815512B2 (ja) | 2015-11-17 |
Family
ID=44914099
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012514658A Expired - Fee Related JP5815512B2 (ja) | 2010-05-14 | 2010-05-14 | リソース管理方法、計算機システムおよびプログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US9319281B2 (ja) |
| JP (1) | JP5815512B2 (ja) |
| WO (1) | WO2011142031A1 (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10171392B1 (en) * | 2010-07-09 | 2019-01-01 | Gummarus LLC | Methods, systems, and computer program products for processing a request for a resource in a communication |
| US9998410B1 (en) * | 2010-07-09 | 2018-06-12 | Sitting Man, Llc | Methods, systems, and computer program products for processing a request for a resource in a communication |
| EP2477085B1 (de) * | 2011-01-13 | 2013-07-17 | Siemens Aktiengesellschaft | Verfahren und System zur Analyse eines zeitlichen Ablaufverhaltens eines Steuerungsprogramms einer Industriesteuerung |
| US20130238383A1 (en) * | 2011-12-20 | 2013-09-12 | Callidus Sofrware incorporated | Auto-adjusting worker configuration for grid-based multi-stage, multi-worker computations |
| JP2014215765A (ja) * | 2013-04-24 | 2014-11-17 | 株式会社三菱東京Ｕｆｊ銀行 | 制御装置 |
| US9588795B2 (en) * | 2014-11-24 | 2017-03-07 | Aspen Timber LLC | Monitoring and reporting resource allocation and usage in a virtualized environment |
| JP2016170689A (ja) * | 2015-03-13 | 2016-09-23 | 富士通株式会社 | 配備制御方法、配備制御プログラムおよび配備制御装置 |
| US10951473B1 (en) * | 2015-03-25 | 2021-03-16 | Amazon Technologies, Inc. | Asynchronous fleet configuration service |
| US9886311B2 (en) * | 2015-04-24 | 2018-02-06 | International Business Machines Corporation | Job scheduling management |
| JP6531597B2 (ja) * | 2015-09-28 | 2019-06-19 | 富士通株式会社 | 解析処理プログラム、解析処理方法および解析処理装置 |
| FR3050295B1 (fr) * | 2016-04-13 | 2018-05-25 | Centre National De La Recherche Scientifique | Systeme de traitement de donnees avec transfert d’energie |
| US10296389B2 (en) * | 2016-09-15 | 2019-05-21 | Red Hat, Inc. | Time-bound conditional resource deallocation |
| CN108462658B (zh) * | 2016-12-12 | 2022-01-11 | 阿里巴巴集团控股有限公司 | 对象分配方法及装置 |
| US10990467B2 (en) | 2016-12-15 | 2021-04-27 | Nutanix, Inc. | Accessing computing resource attributes of an external service provider |
| JP6872117B2 (ja) * | 2017-01-26 | 2021-05-19 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及びプログラム |
| JP6957910B2 (ja) * | 2017-03-15 | 2021-11-02 | 日本電気株式会社 | 情報処理装置 |
| US10938673B2 (en) | 2017-08-14 | 2021-03-02 | Tata Consultancy Services Limited | Automated SLA non-compliance detection and prevention system for batch jobs |
| JP7167596B2 (ja) * | 2018-09-26 | 2022-11-09 | 日本電気株式会社 | トランザクション管理装置、トランザクション管理方法及びトランザクション管理プログラム |
| WO2020148933A1 (ja) * | 2019-01-17 | 2020-07-23 | 三菱電機株式会社 | 情報処理システムおよび情報処理装置 |
| CN109857406B (zh) * | 2019-02-15 | 2022-07-12 | 上海微小卫星工程中心 | 卫星嵌入式软件批处理系统和方法 |
| KR20220101789A (ko) * | 2021-01-12 | 2022-07-19 | 삼성전자주식회사 | 전자 장치 및 전자 장치의 동작 방법 |
| US11789779B2 (en) * | 2021-03-01 | 2023-10-17 | Bank Of America Corporation | Electronic system for monitoring and automatically controlling batch processing |
| WO2023105670A1 (ja) * | 2021-12-08 | 2023-06-15 | 日本電信電話株式会社 | リソース管理装置及びプログラム |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040221011A1 (en) * | 2000-04-10 | 2004-11-04 | Steven Smith | High volume electronic mail processing systems and methods having remote transmission capability |
| JP4099973B2 (ja) * | 2001-10-30 | 2008-06-11 | 松下電器産業株式会社 | 映像データ送信方法及び映像データ受信方法、並びに映像監視システム |
| US7379953B2 (en) * | 2005-02-22 | 2008-05-27 | International Business Machines Corporation | Systems and methods for resource-adaptive workload management |
| JP2006305614A (ja) * | 2005-05-02 | 2006-11-09 | Mitsubishi Electric Corp | バーリング加工方法及びバーリング加工装置 |
| JP2007108944A (ja) * | 2005-10-12 | 2007-04-26 | Renesas Technology Corp | 半導体集積回路装置 |
| US20080010642A1 (en) * | 2006-06-30 | 2008-01-10 | Maclellan Scot | Method, system and computer program for scheduling execution of work units with monitoring of progress thereof |
| JP4308241B2 (ja) | 2006-11-10 | 2009-08-05 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ジョブ実行方法、ジョブ実行システム及びジョブ実行プログラム |
| US8495627B2 (en) * | 2007-06-27 | 2013-07-23 | International Business Machines Corporation | Resource allocation based on anticipated resource underutilization in a logically partitioned multi-processor environment |
| JP2009025939A (ja) | 2007-07-18 | 2009-02-05 | Renesas Technology Corp | タスク制御方法及び半導体集積回路 |
| JP2009086733A (ja) * | 2007-09-27 | 2009-04-23 | Toshiba Corp | 情報処理装置、情報処理装置の制御方法および情報処理装置の制御プログラム |
| JP5326387B2 (ja) * | 2008-07-10 | 2013-10-30 | 富士通株式会社 | 経過情報出力方法および経過情報出力プログラム |
-
2010
- 2010-05-14 US US13/696,487 patent/US9319281B2/en not_active Expired - Fee Related
- 2010-05-14 WO PCT/JP2010/058196 patent/WO2011142031A1/ja active Application Filing
- 2010-05-14 JP JP2012514658A patent/JP5815512B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US9319281B2 (en) | 2016-04-19 |
| WO2011142031A1 (ja) | 2011-11-17 |
| US20130103835A1 (en) | 2013-04-25 |
| JP5815512B2 (ja) | 2015-11-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5815512B2 (ja) | リソース管理方法、計算機システムおよびプログラム | |
| US8874811B2 (en) | System and method for providing a flexible buffer management interface in a distributed data grid | |
| JP5664098B2 (ja) | 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム | |
| JP6881575B2 (ja) | 資源割当システム、管理装置、方法およびプログラム | |
| JP6729399B2 (ja) | システム、仮想化制御装置、仮想化制御装置の制御方法及びプログラム | |
| US9792142B2 (en) | Information processing device and resource allocation method | |
| JP2008158628A (ja) | 運用実績評価装置、運用実績評価方法、およびプログラム | |
| JP6233413B2 (ja) | タスク割り当て判定装置、制御方法、及びプログラム | |
| JP6840099B2 (ja) | サービス提供システム、資源割り当て方法、及び資源割り当てプログラム | |
| US10656990B2 (en) | Dynamically adjusting reserve portion and allocation portions of disaster recovery site in a virtual computing system | |
| US9152491B2 (en) | Job continuation management apparatus, job continuation management method and job continuation management program | |
| JP2010231502A (ja) | ジョブ処理方法、ジョブ処理プログラムを格納したコンピュータ読み取り可能な記録媒体、および、ジョブ処理システム | |
| CN113886089A (zh) | 一种任务处理方法、装置、系统、设备及介质 | |
| CN109446062B (zh) | 云计算服务中的软件调试的方法和装置 | |
| JP6924083B2 (ja) | 情報処理システムおよびリソース割り当て方法 | |
| JP2011192049A (ja) | 仮想マシンシステム、自動マイグレーション方法および自動マイグレーションプログラム | |
| JP6047941B2 (ja) | タスク実行順序制御機能を含む監視制御システム | |
| JP5617586B2 (ja) | 情報処理プログラム、中継装置及び中継管理装置 | |
| JP6191361B2 (ja) | 情報処理システム、情報処理システムの制御方法及び制御プログラム | |
| JP6059259B2 (ja) | 計算機システム及び計算機リソースの割当方法 | |
| CN104714924B (zh) | 一种资源控制方法和装置 | |
| JP2018156146A (ja) | 情報処理装置 | |
| US20220357996A1 (en) | Resource management device, resource management method and program | |
| JP6322332B2 (ja) | エネルギー管理システムおよび業務アプリケーションの実行方法 | |
| CN115357342A (zh) | 冷启动资源处理方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130708 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130709 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130827 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140304 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140603 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20140606 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20140626 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20140822 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150924 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5815512 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |