JP5415183B2 - バッチジョブ処理装置、バッチジョブ処理システム - Google Patents

Description

本発明は、バッチジョブ処理装置、バッチジョブ処理システムに関するものである。

クライアント端末とサーバを有する情報システムにおいて、クライアント端末からサーバに対し、バッチ処理を実行するよう要求する場合がある。一般に、バッチ処理は実行が完了するまで時間がかかる。そのため、クライアント端末からバッチ処理の実行要求を受信した時点で即座にそのバッチ処理を実行し、応答結果をそのクライアント端末に即座に返信する、ということは困難である。

そこで、バッチ処理の実行要求があった時点では、その実行スケジュール等のみをサーバに登録しておき、後に改めてサーバ側でそのバッチ処理を実行する、という手法が採用される場合がある。このように、オンラインのバッチ処理実行要求とオフラインのバッチ実行処理を連携するシステムを、オンラインバッチシステムなどと呼ぶ。

オンラインバッチシステムは、クライアント端末、Ｗｅｂサーバ、データベース、バッチジョブスケジューリングサーバ、バッチ実行サーバなどの機器を用いて構成することができる。上記構成の下では、クライアント端末はバッチ処理の内容と実行スケジュールをＷｅｂサーバに送信し、Ｗｅｂサーバはその情報をデータベースに格納する。バッチジョブスケジューリングサーバは、データベースからバッチ処理の内容と実行スケジュールを取得し、その実行スケジュールにしたがってジョブ実行をスケジューリングする。バッチ実行サーバは、そのスケジュールにしたがってバッチ処理を実行する。

上記のようなオンラインバッチシステムによれば、オンラインのバッチ処理実行要求はデータベースに情報を格納するまでで完了し、バッチ処理そのものはオンライン処理とは非同期で実行される。そのため、オンラインのバッチ処理実行要求に対しては即座に応答を返信しつつ、オフライン処理も実行することができるので、オンライン処理とオフライン処理を連動させることができる。

本発明に関連する公知技術文献として、下記特許文献１、特許文献２、特許文献３があげられる。

特開平０７−０４９８３７号公報 特開平０７−２４４６５３号公報 特開２０００−２０７４８２号公報

一般に、バッチ処理システムの負荷は、バッチジョブの内容やデータ量が推移することにともなって変化する。しかし、バッチ処理を要求する際に、その処理負荷は全く考慮されないか、もしくは経験則程度にしか考慮されない場合がある。

そのため、負荷の高いバッチ処理要求が連続して発生すると、ジョブの処理待ちキューにその高負荷バッチ処理が連続して登録されることになる。一般にジョブの実行が完了するまで他のジョブは実行待ち状態となるため、上記のような状況が発生すると、ジョブ実行モジュールが高負荷バッチ処理によって長時間専有されてしまう。例えばオンライン業務のピーク時間帯に上記のような状況が発生すると、単に業務に支障がでるのみならず、システムダウンを誘発する可能性もある。

本発明は、上記のような課題を解決するためになされたものであり、投入されるバッチ処理の内容によらず、異常な高負荷状態を回避することのできるバッチジョブ処理技術を提供することを目的とする。

本発明に係るバッチジョブ処理装置において、バッチジョブ実行部は、あらかじめ定められた負荷レベルのバッチジョブのみを実行し、そのバッチジョブの実行が終了するまで次のバッチジョブを実行しない。

本発明に係るバッチジョブ処理装置において、バッチジョブ実行部は自己が対象とする負荷レベルのバッチジョブを１つのみしか実行しない。これにより、高負荷のバッチジョブが連続して投入されても、その高負荷バッチジョブが同時に実行される個数を所定限度以内に抑えることができる。したがって、投入されるバッチ処理の内容によらず、異常な高負荷状態を回避することができる。

実施の形態１に係るバッチジョブ処理システム１０００の構成図である。 スケジュールテーブル３４０の構成とデータ例を示す図である。 パラメータテーブル３５０の構成とデータ例を示す図である。 Ｗｅｂサーバ２００の動作を説明するフローである。 バッチジョブ取得部３１０の動作フローである。 実施の形態２に係るバッチジョブ処理システム１０００の構成図である。 ジョブキュー３６０の内部構成を示す模式図である。 実施の形態２におけるバッチジョブ取得部３１０の動作フローである。 実施の形態２におけるバッチジョブ実行部３２０の動作フローである。 実施の形態３に係るバッチジョブ処理システム１０００の構成図である。 実施の形態３におけるバッチジョブ実行部３２０の動作フローのうち、図９のステップＳ９０５に該当する部分の詳細を示す図である。 実施の形態５に係るバッチジョブ処理システム１０００の構成図である。

＜実施の形態１＞
図１は、本発明の実施の形態１に係るバッチジョブ処理システム１０００の構成図である。バッチジョブ処理システム１０００は、バッチジョブの実行要求を受け付けてそのバッチジョブを実行するオンラインバッチシステムであり、クライアント端末１００、Ｗｅｂサーバ２００、バッチジョブ処理装置３００を有する。

クライアント端末１００は、ユーザがバッチジョブ処理装置３００に対するバッチジョブ処理要求を投入するために用いる操作端末である。ユーザは、例えばＷｅｂブラウザを用いてＷｅｂサーバ２００にアクセスし、Ｗｅｂページ上でジョブの内容、負荷レベル、実行スケジュールなどを入力し、これらをＷｅｂサーバ２００に送信する。

Ｗｅｂサーバ２００は、バッチジョブ受付部２１０を備える。バッチジョブ受付部２１０は、クライアント端末１００からバッチジョブ処理要求を受け取り、後述のデータベース３３０に格納する。バッチジョブ受付部２１０は、例えばＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）やＳｅｒｖｌｅｔなどの技術を用いたＷｅｂアプリケーションとして構成することができる。

バッチジョブ処理装置３００は、ユーザがクライアント端末１００を用いて投入したバッチジョブ処理要求を実行する装置であり、バッチジョブ取得部３１０、バッチジョブ実行部３２０、データベース３３０を備える。

バッチジョブ取得部３１０は、データベース３３０が格納している後述のスケジュールテーブル３４０よりバッチジョブの実行スケジュールを取得し、その実行スケジュールに応じて、バッチジョブを実行するようバッチジョブ実行部３２０に指示する。

バッチジョブ実行部３２０は、３個のバッチジョブ実行部３２１、３２２および３２３の総合体である。以下、これらを総称するときは、バッチジョブ実行部３２０と呼ぶ。バッチジョブ実行部３２０は、バッチジョブ取得部３１０よりバッチジョブを実行するように指示を受け、データベース３３０が格納している後述のパラメータテーブル３５０よりバッチジョブの内容を取得し、そのバッチジョブを実行する。

データベース３３０は、後述の図２〜図３で説明するスケジュールテーブル３４０とパラメータテーブル３５０を格納する。

バッチジョブ取得部３１０、バッチジョブ実行部３２０は、これらの機能を実現する回路デバイスのようなハードウェアを用いて構成することもできるし、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。後者の場合は、各部をソフトウェアモジュールなどの形態で実装することができる。

データベース３３０は、各テーブルのデータを記録するデータファイルと、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のような書き込み可能な記憶装置などを用いて構成することができる。

図２は、スケジュールテーブル３４０の構成とデータ例を示す図である。スケジュールテーブル３４０は、クライアント端末１００から受け取ったバッチジョブ処理要求の実行スケジュールを保持するテーブルである。各レコードは、個々のバッチジョブの実行スケジュールを保持する。

スケジュールテーブル３４０は、「Ｎｏ」列３４１、「実行日時」列３４２、「種別」列３４３、「負荷レベル」列３４４、「バッチＩＤ」列３４５、「結果出力先」列３４６、「ステータス」列３４７、「有効」列３４８を有する。

「Ｎｏ」列３４１は、テーブル内の各レコードを識別するための通番である。

「実行日時」列３４２は、バッチジョブの実行予定日時を保持する。

「種別」列３４３は、バッチジョブの種類を表す。本列の値が「通常」である場合、当該バッチジョブはオフラインバッチとして予約実行される。本列の値が「即時」である場合、当該バッチジョブは即時実行される。その他、同じ時刻などで定期的に起動する「定期」などの種別を登録できるようにしてもよい。

「負荷レベル」列３４４は、当該バッチジョブの処理負荷の高低を表す。本列の数値が高いほど、処理負荷が高いことを意味する。本実施の形態１では、「負荷レベル＝３」が最も処理負荷が高く、「負荷レベル＝１」が最も処理負荷が低いものとする。「負荷レベル＝０」の場合は、負荷レベルの値が未定義であることを意味する。

「バッチＩＤ」列３４５は、当該バッチジョブを識別するためのＩＤを保持する。

「結果出力先」列３４６は、当該バッチジョブの実行結果を出力するファイル名を保持する。実行結果を出力する必要がないバッチジョブの場合は、本列は空でもよい。

「ステータス」列３４７は、当該バッチジョブの実行結果を示す。本列は、例えば「成功」「失敗」「未実行」「実行中」「待機」などの値をとり得る。「負荷レベル＝０」となっているレコードは、本列の値を「待機」とする。

「有効」列３４８は、当該バッチジョブが有効であるか否かを表す。本列の値が「有効」である場合は、当該バッチジョブは「実行日時」列３４２の値で指定される日時に実行される。いったん予約したジョブの実行を中止する場合、ユーザは本列の値を「無効」とするように、Ｗｅｂサーバ２００を介して指示する。

図３は、パラメータテーブル３５０の構成とデータ例を示す図である。パラメータテーブル３５０は、バッチジョブの内容を指定する情報を保持するテーブルである。各レコードは、個々のバッチジョブの内容を保持する。図３では、指定した期間における商品の販売状況を集計するバッチジョブの内容を指定するための列構成を例示した。その他の処理内容を実行するバッチジョブについては、別の列構成を有するパラメータテーブル３５０を別途設けることもできる。

図３に例示したパラメータテーブル３５０は、「Ｎｏ」列３５１、「集計開始日」列３５２、「集計終了日」列３５３、「商品ＩＤ」列３５４、「部名」列３５５、「課名」列３５６を備える。

「Ｎｏ」列３５１は、スケジュールテーブル３４０内の「Ｎｏ」列３４１を参照する外部キーである。本列の値が「Ｎｏ」列３４１と一致するレコードは、互いに同じバッチジョブについての情報を保持する。

「集計開始日」列３５２は、販売状況を集計する期間の開始日を保持する。

「集計終了日」列３５３は、販売状況を集計する期間の終了日を保持する。

「商品ＩＤ」列３５４は、販売状況を集計する対象商品を識別するＩＤを保持する。

「部名」列３５５と「課名」列３５６は、対象商品を取り扱う部門名を保持する。

以上、バッチジョブ処理システム１０００の各構成について説明した。次に、バッチジョブ実行部３２０がシステム負荷を抑える手法について説明する。

個々のバッチジョブ実行部３２１〜３２３は、実行するバッチジョブの負荷レベルがあらかじめ規定されている。ここでは、バッチジョブ実行部３２１の担当する負荷レベルは１、バッチジョブ実行部３２２は２、バッチジョブ実行部３２３は３とする。バッチジョブ実行部３２１は負荷レベル１のバッチジョブのみを実行し、バッチジョブ実行部３２２は負荷レベル１〜２のバッチジョブのみを実行し、バッチジョブ実行部３２３は負荷レベル１〜３のバッチジョブ全てを実行するように設定されているものとする。

例えば、同じユーザが負荷レベル３のバッチジョブをバッチジョブ処理システム１０００に短時間に連続して投入した状況を想定する。バッチジョブ実行部３２１〜３２３を上記のように構成した場合、負荷レベル３のバッチジョブはバッチジョブ実行部３２３が同時に１つのみ実行することしかできないため、負荷レベル３のバッチジョブが複数同時に投入されたとしても、これら負荷レベル３のバッチジョブによってバッチジョブ処理システム１０００の演算リソースが専有されてしまう心配はない。

すなわち、バッチジョブ実行部３２３は負荷レベル３のバッチジョブを１つずつ順番に実行し、その他のバッチジョブ実行部３２１と３２２は負荷レベル３のバッチジョブを実行しない。そのため、負荷レベル３のバッチジョブの個数は常に１個以下となり、システム負荷を安定化させることができるのである。

上記のような、同時実行するバッチジョブの個数とその負荷レベルを限定する手法は、オンラインバッチシステムのようにユーザが任意の負荷レベルのバッチジョブをいつでも投入することのできるシステムにおいて特に有効である。オフラインバッチシステムは、あらかじめ計画されているバッチ処理を予定時刻に実行するため、システムの演算リソースを必要十分なだけ準備しておくことができる。これに対し、オンラインバッチシステムでは、どのようなバッチジョブが投入されるか予測することが難しいため、オフラインバッチシステムとは異なる負荷レベル安定化手法が望まれるのである。もっとも、オフラインバッチシステムにおいても、本発明の手法が有用であることはいうまでもない。

以上、バッチジョブ実行部３２０がシステム負荷を抑える手法について説明した。以下では、バッチジョブ処理システム１０００の動作について説明する。

図４は、Ｗｅｂサーバ２００の動作を説明するフローである。以下、図４の各ステップについて説明する。

（図４：ステップＳ４００）
ユーザは、クライアント端末１００を用いて、Ｗｅｂサーバ２００に対し、バッチジョブ処理要求を登録するための画面を送信するよう要求する。クライアント端末１００は、その要求をＷｅｂサーバ２００に送信する。

（図４：ステップＳ４０１）
Ｗｅｂサーバ２００のバッチジョブ受付部２１０は、クライアント端末１００から、バッチジョブ処理要求登録画面を送信すべき旨の要求を受信する。バッチジョブ受付部２１０は、クライアント端末１００に対し、バッチジョブ処理要求登録画面を送信する。

（図４：ステップＳ４０２）
ユーザは、クライアント端末１００が表示するバッチ処理要求登録画面上で、バッチジョブの内容、負荷レベル、実行スケジュールなどのバッチジョブ処理要求を入力する。クライアント端末１００は、その入力内容をＷｅｂサーバ２００に送信する。Ｗｅｂサーバ２００のバッチジョブ受付部２１０は、バッチジョブ処理要求を受信する。

（図４：ステップＳ４０３）
バッチジョブ受付部２１０は、受信したバッチジョブ処理要求に含まれるバッチジョブの負荷レベルと実行スケジュールを、スケジュールテーブル３４０に登録する。また、バッチジョブの内容を、パラメータテーブル３５０に登録する。

図５は、バッチジョブ取得部３１０の動作フローである。以下、図５の各ステップについて説明する。

（図５：ステップＳ５０１）
バッチジョブ取得部３１０は、スケジュールテーブル３４０が保持している全てのレコードを取得する。

（図５：ステップＳ５０２）
バッチジョブ取得部３１０は、以下のステップＳ５０３〜Ｓ５０４を、ステップＳ５０１で取得したレコード数だけ繰り返す。

（図５：ステップＳ５０３）
バッチジョブ取得部３１０は、ステップＳ５０１で取得したレコードのうち１つについて、「有効」列３４８の値が「有効」であり、かつ「ステータス」列３４７の値が「未実行」または「待機」であり、かつ「実行日時」列３４２の値が現在時刻よりも前であるか否かを確認する。当該レコードがこれら３条件を全て満たす場合はステップＳ５０４へ進み、いずれか１条件以上を満たさない場合はループを次のレコードに進める。

（図５：ステップＳ５０４）
バッチジョブ取得部３１０は、バッチジョブ実行部３２０のうち「負荷レベル」列３４４の値に対応するものに、当該バッチジョブを実行するよう指示する。バッチジョブ実行部３２０（３２１、３２２、３２３のうちいずれか）は、受け取ったバッチジョブの負荷レベルを確認し、自己が実行することのできる負荷レベルであれば、そのバッチジョブを実行する。先に実行しているバッチジョブがあれば、そのバッチジョブの実行が終了した後に、受け取ったバッチジョブを実行する。

（図５：ステップＳ５０５）
バッチジョブ取得部３１０は、１５秒スリープ（何もせずに待機）する。

（図５：ステップＳ５０６）
バッチジョブ取得部３１０の処理を終了する場合は本動作フローを終了し、処理を継続する場合はステップＳ５０１に戻って同様の処理を繰り返す。

以上、バッチジョブ処理システム１０００の動作について説明した。なお図５では、ステップＳ５０１で全てのレコードを取得し、ステップＳ５０３で条件チェックを行なっているが、ステップＳ５０１の時点で、条件を満たすレコードのみを取得するようにしてもよい。

以上のように、本実施の形態１によれば、バッチジョブ実行部３２０は、あらかじめ設定されている負荷レベルのバッチジョブを１つのみ実行する。先に実行しているバッチジョブがあれば、そのバッチジョブの実行が終了した後に、受け取ったバッチジョブを実行する。これにより、例えばユーザが負荷レベルの高いバッチジョブを短時間に連続して投入したような場合でも、バッチジョブ処理装置３００がその高負荷レベルのバッチジョブによって専有されることを回避できる。

また、本実施の形態１によれば、ユーザがバッチジョブを投入する時点でその負荷レベルを正確に把握しておらず、または故意に不正確な負荷レベルを指定してバッチジョブを投入したような場合でも、バッチジョブ実行部３２０の作用により、バッチジョブ処理装置３００が同時に実行するバッチジョブの負荷レベルをある範囲内に抑えることができる。これにより、負荷レベルの予測可否および投入されるバッチジョブの負荷レベルの高低を問わず、バッチジョブ処理システム１０００を安定的に稼動させることができる。

また、本実施の形態１において、バッチジョブ処理装置３００は、バッチジョブの実行スケジュールを格納するデータベース３３０を備える。バッチジョブ取得部３１０は、データベース３３０からその実行スケジュールを取得し、バッチジョブ実行部３２０にバッチジョブを引き渡す。これにより、データベース３３０は、オンラインによるバッチジョブ処理要求とオフラインによるバッチジョブ実行との橋渡しを行なうことになるので、オンライン処理とオフライン処理を連携することができる。同様の構成は完全なオフラインバッチシステムでも採用することができるが、オンラインバッチシステムにおいて同構成を採用すると、特に有用である。

＜実施の形態２＞
図６は、本発明の実施の形態２に係るバッチジョブ処理システム１０００の構成図である。本実施の形態２では、バッチジョブ取得部３１０とバッチジョブ実行部３２０の間にジョブキュー３６０を導入した。その他の構成は実施の形態１と概ね同様であるため、以下では差異点を中心に説明する。

ジョブキュー３６０は、バッチジョブ処理装置３００が備えるメモリ装置（図示せず）などの記憶装置内における記憶領域を使用する。ジョブキュー３６０は、バッチジョブ取得部３１０よりバッチジョブを順番に受け取り、受け取った順番に保持する。バッチジョブ実行部３２０からバッチジョブを引き渡すように指示されると、そのバッチジョブを引き渡し、ジョブキュー３６０内から当該バッチジョブを削除する。

ジョブキュー３６０は、その機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵなどの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。後者の場合、例えばメッセージキューイングシステムなどのソフトウェアモジュールを用いてジョブキュー３６０を構成することができる。

図７は、ジョブキュー３６０の内部構成を示す模式図である。ジョブキュー３６０内には、個々のバッチジョブの内容や実行スケジュールなどを記述したメッセージ（図７における３６１〜３６３）が格納される。各メッセージ３６１〜３６３の記述形式として、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの汎用的な記述形式を用いると、処理の都合上便宜である。

図８は、本実施の形態２におけるバッチジョブ取得部３１０の動作フローである。以下図８の各ステップについて説明する。

（図８：ステップＳ８０１〜Ｓ８０３）
これらのステップは、図５のステップＳ５０１〜Ｓ５０３と同様である。

（図８：ステップＳ８０４）
バッチジョブ取得部３１０は、ステップＳ８０３の条件を満たすバッチジョブを、ジョブキュー３６０に投入する。ジョブキュー３６０は、図７で説明したような形式で記述されるメッセージとして、そのバッチジョブの内容を格納する。

（図８：ステップＳ８０５〜Ｓ８０６）
これらのステップは、図５のステップＳ５０５〜Ｓ５０６と同様である。

図９は、本実施の形態２におけるバッチジョブ実行部３２０の動作フローである。以下図９の各ステップについて説明する。なお、図９に示す動作フローは、個々のバッチジョブ実行部３２１〜３２３について共通である。各バッチジョブ実行部は、それぞれ並行して同動作フローを実行する。

（図９：ステップＳ９０１）
バッチジョブ実行部３２０は、ジョブキュー３６０が格納しているバッチジョブ（バッチジョブの内容を記述したメッセージ）を取得する。このとき、他のバッチジョブ実行部３２０が同時にジョブキュー３６０にアクセスしないように、ジョブキュー３６０をロックするなどしてもよい。

（図９：ステップＳ９０２）
バッチジョブ実行部３２０は、ステップＳ９０１で取得したバッチジョブの数だけ、ステップＳ９０３〜Ｓ９０６を繰り返す。

（図９：ステップＳ９０３）
バッチジョブ実行部３２０は、ステップＳ９０１で取得したバッチジョブのうち１つについて、負荷レベルが自己の担当する負荷レベル以下であるか否かを確認する。自己が担当する負荷レベル以下であればステップＳ９０４へ進み、それ以外であればループを次のバッチジョブに進める。

（図９：ステップＳ９０４）
バッチジョブ実行部３２０は、ステップＳ９０３の条件を満たすバッチジョブを、ジョブキュー３６０から１つ取り出す。取り出したバッチジョブは、ジョブキュー３６０から削除する。

（図９：ステップＳ９０５）
バッチジョブ実行部３２０は、ステップＳ９０４でジョブキュー３６０から取り出したバッチジョブを実行する。また、スケジュールテーブル３４０が保持している当該バッチジョブのレコードの「ステータス」列３４７を、「成功」「失敗」などの値に更新する。

（図９：ステップＳ９０６）
バッチジョブ実行部３２０は、１５秒スリープ（何もせずに待機）する。

（図９：ステップＳ９０７）
バッチジョブ実行部３２０の処理を終了する場合は本動作フローを終了し、処理を継続する場合はステップＳ９０１に戻って同様の処理を繰り返す。

以上、本実施の形態２におけるバッチジョブ処理システム１０００の動作について説明した。

以上のように、本実施の形態２によれば、バッチジョブ取得部３１０とバッチジョブ実行部３２０の間にジョブキュー３６０を設け、バッチジョブ実行部３２０はジョブキュー３６０からバッチジョブを取得することとした。これにより、バッチジョブ実行部３２０は先に実行しているバッチジョブが完了してからジョブキュー３６０にアクセスすればよいので、バッチジョブ実行部３２０自身がジョブ実行待ちリストを保持する必要がなくなる。したがって、バッチジョブ実行部３２０はバッチジョブの実行のみに専念することができる。

また、本実施の形態２によれば、バッチジョブ取得部３１０とバッチジョブ実行部３２０をジョブキュー３６０によって緩く結合したので、バッチジョブ取得部３１０またはバッチジョブ実行部３２０を新しいモジュールに入れ替えたりすることが容易になる。

また、本実施の形態２において、ジョブキュー３６０は、バッチジョブの内容などを記述するメッセージを格納するので、ジョブキュー３６０の外部からバッチジョブにアクセスすることが容易になる。例えば、図７で例示したようなＸＭＬ形式でバッチジョブの内容などを記述すれば、コンピュータ等の演算装置にとって取り扱い易い形式でバッチジョブを処理することができるので、処理の都合上便宜である。

また、本実施の形態２において、ジョブキュー３６０は、いったん格納したバッチジョブを、実行のため取り出す以外に削除することができないようにしてもよい。同様に順番の入れ替えなども不可としてもよい。この場合、ジョブキュー３６０にいったんバッチジョブを格納すれば、そのバッチジョブは必ずバッチジョブ実行部３２０に引き渡されることになるので、データベース３３０内に未実効のバッチジョブがいつまでも格納されたままになるような状況ができる限り発生しないよう抑制する効果がある。

＜実施の形態３＞
図１０は、本発明の実施の形態３に係るバッチジョブ処理システム１０００の構成図である。本実施の形態３では、バッチジョブ実行部３２０と連動して動作する負荷レベル予測部３７０を新たに導入した。その他の構成は実施の形態１〜２いずれかと概ね同様であるため、以下では差異点を中心に説明する。なお、図１０では実施の形態２の構成に負荷レベル予測部３７０を追加した構成を例示した。

負荷レベル予測部３７０は、バッチジョブの負荷レベルを、例えば特許文献２に記載されている技術などの適当な手法を用いて予測する。負荷レベル予測部３７０は、その機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵなどの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。

図１１は、本実施の形態３におけるバッチジョブ実行部３２０の動作フローのうち、図９のステップＳ９０５に該当する部分の詳細を示す図である。以下、図１１の各ステップについて説明する。

（図１１：ステップＳ１１０１）
バッチジョブ実行部３２０は、ステップＳ９０４でジョブキュー３６０から取り出したバッチジョブの負荷レベルを確認する。負荷レベルが０（未定義）であればステップＳ１１０４へ進み、それ以外であればステップＳ１１０２へ進む。

（図１１：ステップＳ１１０２）
バッチジョブ実行部３２０は、ステップＳ９０４でジョブキュー３６０から取り出したバッチジョブを実行する。

（図１１：ステップＳ１１０３）
バッチジョブ実行部３２０は、スケジュールテーブル３４０が保持している当該バッチジョブのレコードの「ステータス」列３４７を、「成功」「失敗」などの値に更新する。

（図１１：ステップＳ１１０４）
バッチジョブ実行部３２０は、ステップＳ９０４でジョブキュー３６０から取り出したバッチジョブの負荷レベルを予測するよう、負荷レベル予測部３７０に指示する。負荷レベル予測部３７０は、そのバッチジョブの負荷レベルを予測し、バッチジョブ実行部３２０に予測結果を通知する。

（図１１：ステップＳ１１０５）
バッチジョブ実行部３２０は、スケジュールテーブル３４０が保持している当該バッチジョブのレコードの「負荷レベル」列３４４を、負荷レベル予測部３７０から受け取った予測結果の値に更新する。

以上、本実施の形態３に係るバッチジョブ処理システム１０００の動作について説明した。なお、実施の形態１で説明した構成に加えて負荷レベル予測部３７０を設ける場合、図５のステップＳ５０４の後でバッチジョブ実行部３２０が図１１と同様の処理を実行することになる。

以上のように、本実施の形態３によれば、ユーザがクライアント端末１００を用いてバッチジョブを投入する段階でそのバッチジョブの負荷レベルが不明である場合でも、負荷レベル予測部３７０がユーザに代わって負荷レベルを予測する。そのため、ユーザはバッチジョブ処理要求を送信するときに、そのバッチジョブの負荷レベルを必ずしも指定する必要はない。これにより、負荷レベルが不明なバッチジョブに対してユーザが不正確な負荷レベルを指定し、バッチジョブ処理装置３００における負荷配分が乱れてしまうような状況を低減することができる。

＜実施の形態４＞
以上の実施の形態１〜３において、スケジュールテーブル３４０とパラメータテーブル３５０が保持している各レコードは、所定期間（例えば３０日）が経過した後に削除するようにしてもよい。このとき、「ステータス」列３４７の値が「成功」となっているバッチジョブのみ削除してもよいし、上記所定期間が経過したバッチジョブは無条件に削除するようにしてもよい。

＜実施の形態５＞
図１２は、本発明の実施の形態５に係るバッチジョブ処理システム１０００の構成図である。本実施の形態５では、バッチジョブ処理装置３００とは別にバッチジョブ実行サーバ４００を新たに設け、バッチジョブを実行する処理主体をバッチジョブ実行部３２０から切り出した。その他の構成は実施の形態１〜４いずれかと同様であるため、以下では差異点を中心に説明する。

バッチジョブ実行サーバ４００は、バッチジョブ処理部４１０を備える。バッチジョブ処理部４１０は、バッチジョブ実行部３２０が実行するバッチジョブの処理本体を受け持つ機能部である。本実施の形態５において、バッチジョブ実行部３２０は、実体的にはバッチジョブ処理部４１０を起動する起動部としての役割を果たすことになる。

バッチジョブ処理部４１０は、その機能を実現する回路デバイスなどのハードウェアを用いて構成することもできるし、ＣＰＵなどの演算装置とその動作を規定するソフトウェアを用いて構成することもできる。

なお、負荷レベル予測部３７０など、バッチジョブ処理装置３００が備える機能部の一部をバッチジョブ実行サーバ４００に配置することもできる。

以上のように、本実施の形態５によれば、バッチジョブ処理装置３００が備える機能の一部をバッチジョブ実行サーバ４００に切り出したので、バッチジョブ処理装置３００の処理負担を軽減することができる。

＜実施の形態６＞
以上の実施の形態１〜５において、３つのバッチジョブ実行部３２１〜３２３を備える構成を説明した。また、各バッチジョブ実行部はそれぞれ負荷レベル１、１〜２、１〜３のバッチジョブを実行するものとした。バッチジョブ実行部３２０の構成はこれに限られるものではなく、実行するバッチジョブの性質や数などに応じて構成を適宜変更することができる。

例えば、負荷レベルの高いバッチジョブを多く実行するシステムにおいて本発明の手法を導入する場合は、バッチジョブ実行部３２３の数を多めに設けてもよい。また、バッチジョブ実行部３２０全体の個数も、４個以上でもよいし、２個以下でもよい。

バッチジョブ実行部３２０は、単一の負荷レベルのみ実行対象としてもよい。例えば、各バッチジョブ実行部はそれぞれ負荷レベル１、２、３のバッチジョブを実行する、などである。

バッチジョブ実行部３２０の個数や対象負荷レベルを調整することにより、バッチジョブ処理システム１０００の処理性能や並列度などを、対象業務の仕様などに応じて調整することができる。

１００：クライアント端末、２００：Ｗｅｂサーバ、２１０：バッチジョブ受付部、３００：バッチジョブ処理装置、３１０：バッチジョブ取得部、３２０〜３２３：バッチジョブ実行部、３３０：データベース、３４０：スケジュールテーブル、３５０：パラメータテーブル、３６０：ジョブキュー、３７０：負荷レベル予測部、４００：バッチジョブ実行サーバ、４１０：バッチジョブ処理部、１０００：バッチジョブ処理システム。

Claims (6)

1. バッチジョブとその実行スケジュールを取得するバッチジョブ取得部と、
   前記バッチジョブの負荷レベルを取得しそのバッチジョブを実行するバッチジョブ実行部と、
   前記バッチジョブの実行スケジュールを格納する記憶部と、
   前記バッチジョブ取得部が取得した前記バッチジョブを一時的に保持し出力要求にしたがって出力するジョブキューと、
   を備え、
   前記バッチジョブ取得部は、前記記憶部より前記実行スケジュールを取得し、前記記憶部より取得したバッチジョブを前記ジョブキューに格納し、
   前記バッチジョブ実行部は、
   前記ジョブキューより前記バッチジョブを取得して実行し、
   前記バッチジョブ取得部が取得した前記実行スケジュールにしたがって前記バッチジョブを実行し、
   所定の負荷レベルの前記バッチジョブのみを実行し、そのバッチジョブの実行が終了するまで次のバッチジョブを実行せず、
   前記バッチジョブ実行部は、前記ジョブキューから取得した前記バッチジョブについてその負荷レベルが前記バッチジョブ実行部自身の担当する負荷レベル以下であるか否かを確認し、自身の担当する負荷レベル以下である場合は前記ジョブキューからそのバッチジョブを取り出すとともに前記ジョブキューから削除した上でそのバッチジョブを実行する
   ことを特徴とするバッチジョブ処理装置。
2. 前記ジョブキューに格納された前記バッチジョブは、前記バッチジョブ実行部が実行する場合を除き前記ジョブキューから削除不可とする
   ことを特徴とする請求項１記載のバッチジョブ処理装置。
3. 前記バッチジョブの負荷レベルを予測する負荷レベル予測部を備え、
   前記記憶部は、
   前記負荷レベルが特定されていない前記バッチジョブの実行スケジュールを格納し、
   前記負荷レベル予測部は、
   前記負荷レベルが特定されていない前記バッチジョブを前記バッチジョブ実行部が実行する前にそのバッチジョブの負荷レベルを予測する
   ことを特徴とする請求項１または２記載のバッチジョブ処理装置。
4. 前記バッチジョブの負荷レベルを予測する負荷レベル予測部を備え、
   前記記憶部は、
   前記負荷レベルが特定されていない前記バッチジョブの実行スケジュールを格納し、
   前記バッチジョブ取得部は、
   前記負荷レベルが特定されていない前記バッチジョブを前記ジョブキューに格納し、
   前記負荷レベル予測部は、
   前記ジョブキューが格納している前記バッチジョブのうち前記負荷レベルが特定されていないものについて、前記バッチジョブ実行部が実行する前にそのバッチジョブの負荷レ
   ベルを予測する
   ことを特徴とする請求項１または請求項２記載のバッチジョブ処理装置。
5. 請求項１から請求項４のいずれか１項に記載のバッチジョブ処理装置と、
   前記バッチジョブの内容および実行スケジュールの指示を受信して前記バッチジョブ処理装置に出力する受信サーバと、
   を有することを特徴とするバッチジョブ処理システム。
6. 請求項１から請求項４のいずれか１項に記載のバッチジョブ処理装置と、
   前記バッチジョブの内容および実行スケジュールの指示を受信する受信サーバと、
   を有し、
   前記受信サーバは、
   前記バッチジョブの内容および実行スケジュールを前記記憶部に格納し、
   前記バッチジョブ実行部は、
   前記実行スケジュールにしたがって前記バッチジョブを実行する
   ことを特徴とするバッチジョブ処理システム。

Images