JP2007249491A - マルチサーバ環境においてバッチジョブを分散させるプログラム、装置、および方法 - Google Patents

Abstract

【課題】バッチジョブを実行させるサーバを複数の実行サーバの中から選ぶときに、バッチジョブの実行にかかる時間の範囲全体の中で最適な実行サーバを選択する。
【解決手段】バッチジョブ特性と入力データの件数からそのバッチジョブの実行にかかる時間を予測し、その時間の範囲全体で各実行サーバの負荷状況を予測し、それにもとづいてバッチジョブを実行させる実行サーバを選択する。また、バッチジョブを実行するたびに、そのバッチジョブの実行により生じた負荷を計測し、その実測値にもとづいてバッチジョブ特性を更新することによって、バッチジョブ特性の確度および実行サーバの選択の精度を高める。
【選択図】図１

Description

本発明は、バッチジョブを実行するサーバが複数存在するマルチサーバ環境において、バッチジョブを実行させるサーバを適切に選択し、効率的に負荷を分散させる技術に関する。

複数のバッチジョブを複数のサーバに分散して実行させることでスループットを向上させる手法がある。静的に分散の仕方を定めておくこともできるが、動的に分散することによって、より効率的な負荷分散が可能になる。

特許文献１に記載されたシステムでは、バッチジョブを実行する複数のサーバの負荷状況を監視している。バッチジョブの実行依頼があると、予め設定されたバッチジョブの資源使用特性にもとづいてそのバッチジョブを型（例えば、メモリやＩ／Ｏ資源に比べてＣＰＵ資源を主に使う「ＣＰＵ資源使用型」など）に分類し、その型のジョブを実行するのに適した負荷状況のサーバを選ぶ。類似のシステムは特許文献２にも開示されている。

ところで、バッチジョブはオンラインジョブと異なり、まとまった量の入力データを一括して処理する。よって、入力データ量を変えて一つのバッチジョブを複数回実行すると、使用するコンピュータ資源の量も実行時間も、入力データ量（処理件数）に依存して異なるという特性がある。

また、大量の入力データを処理するバッチジョブを実行するのには、例えば、１時間から２時間程度の長い時間を要することがしばしばある。したがって、バッチジョブを起動する時に低負荷だったサーバが、バッチジョブを実行しているうちに、そのバッチジョブ以外の要因を含む様々な要因で高負荷になってしまう可能性を無視することができない。バッチジョブを起動する時のサーバ負荷状況だけにもとづいて、そのようなサーバにバッチジョブを実行させてしまうと、最適な分散を実現することができない。

しかし、特許文献１や特許文献２に記載されたシステムでは、バッチジョブの実行にかかる時間という要素を考慮しておらず、バッチジョブを分散させるための判断に用いるサーバの負荷状況は、バッチジョブの実行依頼があった時点の直近の負荷状況のみである。

また、特許文献１や特許文献２などのシステムにおいては、バッチジョブの特性が適切に把握されていることが肝要だが、従来はバッチジョブの特性を把握すること自体が難しく、時間と手間を要するという問題があった。その理由は、第一に、バッチジョブの処理時間の要因である処理データ量、ユーザ資源の競合、システム資源の競合、競合の結果生じる待ち時間などを総合して可視化する標準的な仕組みやツールがないので、バッチジョブの特性を把握するためのアプリケーションプログラムをユーザが独自に開発する必要があるためである。第二の理由は、システム負荷をプロセスごとに集計する標準的な機能はサーバに備わっているが、バッチジョブごとの集計は人手で行うか、ユーザが独自のアプリケーションプログラムを作成する必要があるためである。
特開平１０−３３４０５７号公報 特開平４−３４６４０号公報

本発明の課題は、バッチジョブを実行するサーバが複数存在するマルチサーバ環境において、バッチジョブを実行させるサーバを選択する際に、バッチジョブの実行にかかる時間の範囲全体の中で最適なサーバを選択することである。また、その選択の際に用いるバッチジョブの特性を自動的に記録し、特性を把握する手間を軽減することも本発明の課題である。

図１は本発明の原理を示す図である。本発明によるプログラムは、バッチジョブを実行するサーバが複数存在するマルチサーバ環境において、バッチジョブを実行させるサーバを選択するのに用いられる。本発明によるプログラムは、ステップＳ１において、バッチジョブの特性と入力データ量から、そのバッチジョブを実行するのにかかる実行時間を予測する。そしてステップＳ２において、その実行時間の範囲における各サーバの負荷状況を予測する。最後にステップＳ３において、予測した負荷状況にもとづいて、そのバッチジョブを実行させるサーバを選択する。選択されたサーバでバッチジョブを実行することにより、マルチサーバ環境におけるバッチジョブの適切な分散が実現される。

また、こうして選択されたサーバでバッチジョブが実行されるたびに、その実行に起因する負荷を計測して記録し、記録したデータをもとにバッチジョブの特性を更新する。

本発明によれば、ある一点の時刻におけるサーバの負荷状況ではなく、バッチジョブの実行にかかると予測される時間の範囲でサーバの負荷状況が予測され、その予測にもとづいてバッチジョブを実行するサーバが選択される。よって、たとえ複数のサーバの負荷状況が時間帯によって変化する環境で、処理時間の長いバッチジョブを実行させようとする場合であっても、適切なサーバを選択することができる。そのため、マルチサーバ環境においてバッチジョブを従来よりも効率的に分散することが可能となる。

また、バッチジョブの特性が自動的に作成・更新されるため、システム管理者などの人間がバッチジョブの特性を把握する手間を軽減できる。さらに、バッチジョブの特性を表すデータの収集量が多いほど、記録されたバッチジョブの特性の確度が高まるので、バッチジョブを実行させるサーバを選択するときの判断の精度も高まり、より効率的な運用が実現できる。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
まず、図２と図３を用いて、バッチジョブを実行するサーバを選択する方法の概略を説明する。次に、図４を用いて、本発明によってバッチジョブの実行サーバを選択しバッチジョブを分散実行させるシステムの全体の構成を説明する。その後、図５から図８を用いて、本発明で使われる各種のデータの構成について説明してから、図９から図１２を用いて処理の流れを説明する。

図２は、１つのバッチジョブを実行することによる負荷の一例を示すグラフである。図２のグラフの縦軸は負荷を示し、横軸は時間を示す。図２の例ではＣＰＵ使用量とメモリ使用量の２種類の負荷が示されている。一般的に、バッチジョブは処理対象のデータを一件ずつ順次処理していくことが多いため、図２のように負荷の変動幅が小さいことが多い。よって、負荷が時間とともに変化するのではなく、一定量の負荷が持続すると近似的に見なしても問題がない。

図３は、バッチジョブを実行するサーバの負荷の一例を示すグラフである。図３のグラフの縦軸は負荷を示し、横軸は時間を示す。図３の例ではサーバＡとサーバＢのそれぞれについて、ＣＰＵ使用率とメモリ使用率の２種類の負荷が示されている。サーバは１つのバッチジョブだけを実行するのではないため、図３に示したように、負荷は時間によって大きく変動することがある。

あるバッチジョブを時刻ｔ_１から実行しようとしたとき、図３の例では、時刻ｔ_１における負荷は、サーバＡの方がサーバＢよりも低い。従来の手法では、時刻ｔ_１における負荷にもとづいてバッチジョブを実行させるサーバを選択するため、時刻ｔ_１においてＣＰＵ使用率、メモリ使用率の双方で有利なサーバＡが選択される。しかし、サーバＡの負荷は時間とともに増大する傾向にあるのに対し、サーバＢの負荷は時間とともに減少する傾向にあることを考慮すると、サーバＡを選択することは最適な負荷分散を意味しない。

ここで、説明を簡略化するために、便宜上、サーバＡとサーバＢのハードウェア性能の差が無視できる程度だと仮定すると、あるバッチジョブをサーバＡで実行するのにかかると予測される時間と、そのバッチジョブをサーバＢで実行するのにかかると予測される時間は同一と見なせる（予測の方法は後述する）。この時間をｄとし、時刻ｔ_２はｔ_２＝ｔ_１＋ｄなる時刻とする。時刻ｔ_１から時刻ｔ_２までの範囲は、バッチジョブの実行開始から実行終了と予測されるまでの範囲であり、以下ではこの予測された時間範囲を、バッチジョブの実行範囲と呼ぶ。本発明では、バッチジョブの実行範囲におけるサーバＡとサーバＢのそれぞれの負荷を考慮して、バッチジョブを実行させるサーバが選択される。図３の例では、バッチジョブの実行範囲における負荷の総量は、ＣＰＵ使用率に関しても、メモリ使用率に関しても、サーバＢの方がサーバＡよりも小さいため、サーバＢが選択される。

なお、バッチジョブの実行範囲全体における負荷の総量は、図３のグラフにおいて、ＣＰＵ使用率やメモリ使用率を、それぞれ時刻ｔ_１からｔ_２まで積分した値に相当する。よって、一般に積分値の近似値を求めるときと同様に、ｔ_１からｔ_２の区間を複数の区間に区切って区分求積することにより、バッチジョブの実行範囲全体における負荷の総量が予測できる。

ところで、もしバッチジョブの実行により発生する負荷が実行範囲において大きく変化（増加や減少など）するなら、バッチジョブを実行させるサーバを選ぶときに、その変化の傾向と、実行範囲におけるサーバ負荷の変化の傾向のマッチングを考慮する必要がある。しかし、実際には、１つのバッチジョブの実行により発生する負荷はそれほど大きく変動しない場合が多い（図２）。よって、本発明では、バッチジョブをどのサーバに実行させるかの判断において、変化の傾向のマッチングを考慮しない。つまり、図３のサーバ負荷の変化の傾向（増加するか減少するかなど）を考慮せず、サーバ負荷の総量にもとづいて判断する。また、バッチジョブの実行範囲全体におけるサーバ負荷の総量とサーバ負荷の平均値は比例関係にあるので、サーバ負荷の総量のかわりにサーバ負荷の平均値を利用して、バッチジョブをどのサーバに実行させるかを判断することができる。このことは、図１０のフローチャートに示す処理で利用する。

図４は、本発明によってバッチジョブの実行サーバを選択しバッチジョブを分散実行させるシステムの一実施形態における構成図である。図４に示したバッチシステム１０１は、受付サーバ１０２と、複数の実行サーバ１０３−１、１０３−２、……、１０３−Ｎからなる実行サーバ群１０３と、リポジトリ１０４とを備える。受付サーバ１０２は、バッチジョブの実行要求を受け付けると、バッチジョブの実行にかかる時間を予測し、そのバッチジョブの実行範囲内での各実行サーバ１０３−１、１０３−２、……、１０３−Ｎの負荷状況を予測し、予測した負荷状況にもとづいて実行サーバ群１０３の中から適切な実行サーバを選択して、その実行サーバにバッチジョブを実行させる。受付サーバはこれらの予測と選択を、リポジトリ１０４に格納されたデータにもとづいて行う。図中の番号（１）から（１５）は処理の流れを示すが、詳しくは後述する。

受付サーバ１０２は、バッチジョブをスケジュールする機能（以下「スケジュール機能」という）を有するサーバ・コンピュータである。実行サーバ１０３−１、１０３−２、……、１０３−Ｎは、それぞれがバッチジョブを実行する機能（以下「実行機能」という）を有するサーバ・コンピュータである。以下では、ほぼ同性能のサーバをクラスタ化して運用している場合など、実行サーバ１０３−１、１０３−２、……、１０３−Ｎの性能の差が無視できる程度の場合について主に述べる。リポジトリ１０４はディスク装置（記憶装置）上に配置され、バッチジョブの分散に必要な各種のデータ（図５から図８）が格納されている。受付サーバ１０２および実行サーバ１０３−１、１０３−２、……、１０３−Ｎは、リポジトリ１０４が配置されたディスク装置にアクセス可能であり、リポジトリ内のデータの参照・更新等を行うことができる。

スケジュール機能は、１台の物理的なサーバ（つまり受付サーバ１０２）に存在する。実行機能は、２台以上の物理的なサーバ（つまりに実行サーバ１０３−１、１０３−２、……、１０３−Ｎ）に存在する。受付サーバ１０２は、実行サーバ群１０３のうちの１台のサーバと物理的に同一のサーバであってもよく、実行サーバ群１０３のいずれとも物理的に異なるサーバであってもよい。

リポジトリ１０４を配置したディスク装置のフォーマットは、リポジトリ１０４を利用する各サーバ（受付サーバ１０２および実行サーバ１０３−１、１０３−２、……、１０３−Ｎ）が参照可能なフォーマットでなくてはならない。ただし、汎用的なフォーマットである必要はなく、バッチシステム１０１の独自フォーマットでもよい。

リポジトリ１０４には、システムの運用状態を示すデータ（以下「運用データ」という）、バッチジョブの特性を示すデータ（以下「バッチジョブ特性」という）、サーバの負荷状況を示すデータ（以下「サーバ負荷情報」という）、バッチショブを実行させる実行サーバを選択するための規則（以下「分散条件」という）が格納されている。

これらリポジトリ１０４内の各情報は、一つのファイルに格納してもよいし、複数のファイルに分けて格納してもよい。リポジトリ１０４を配置したディスク装置は、受付サーバ１０２や実行サーバ１０３−１、１０３−２、……、１０３−Ｎのいずれのローカルディスクとも物理的に異なるディスク装置でもよく、これらサーバのいずれかのローカルディスクと物理的に同一の装置であってもよい。また、リポジトリ１０４が物理的に２つ以上のディスク装置に分かれて配置されていてもよい。例えば、バッチジョブ特性と分散条件が受付サーバ１０２のローカルディスクに格納され、運用データとサーバ負荷情報が、いずれのサーバのローカルディスクとも物理的に異なるディスク装置に格納されるようにしてもよい。

運用データは、バッチジョブを実行した際の履歴やサーバ負荷の履歴を管理するためのデータである。運用データの例を図５に示すが、詳しくは後述する。
バッチジョブ特性は、図５に示した運用データからバッチジョブごとにデータが抽出されて作成される。バッチジョブ特性は、各バッチジョブの特性を管理するためのデータである。バッチジョブ特性としてリポジトリ１０４には、例えば、ジョブ識別名、ジョブステップ数、実行時間、ＣＰＵ使用量、メモリ使用量、物理Ｉ／Ｏ発行回数などの項目が格納されてもよい。実施の態様に応じて、これらの項目のうち必要な項目がバッチジョブ特性としてリポジトリ１０４に格納される。バッチジョブ特性の例を図６に示すが、詳しくは後述する。

サーバ負荷情報は、時間帯ごとの各実行サーバ１０３−１、１０３−２、……、１０３−Ｎの負荷を管理するための情報である。サーバ負荷情報としてリポジトリ１０４には、例えば、ＣＰＵ使用量、ＣＰＵ使用率、メモリ使用量、メモリ使用率、物理Ｉ／Ｏの平均待ち時間、ファイルの使用量、記憶装置の空き容量などの項目が格納されてもよい。実施の態様に応じて、これらの項目のうち必要な項目がサーバ負荷情報としてリポジトリ１０４に格納される。サーバの負荷情報の例を図７に示すが、詳しくは後述する。

分散条件は、バッチジョブを実行するサーバを選択するときに参照する規則を保持している。分散条件の一例を図８に示すが、詳しくは後述する。
受付サーバ１０２は、バッチジョブの実行要求を受け付けるジョブ受付サブシステム１０５、ジョブを実行させる実行サーバを選択するジョブ分散サブシステム１０６、運用データを記録するための運用データ採取サブシステム１０７、バッチジョブ特性を更新するためのジョブ情報更新サブシステム１０８、という４つのサブシステムを含む。これら４つのサブシステムは連携している。

実行サーバ１０３−１、１０３−２、……、１０３−Ｎのそれぞれは、バッチジョブを実行するジョブ実行サブシステム１０９、運用データを記録する運用データ採取サブシステム１１０、サーバ負荷情報を収集する性能情報収集サブシステム１１１、収集したサーバ負荷情報にもとづきリポジトリ１０４の内容を更新するサーバ情報採取サブシステム１１２、という４つのサブシステムを含む。これら４つのサブシステムは連携している。

受付サーバ１０２および各実行サーバ１０３−１、１０３−２、……、１０３−Ｎにはそれぞれ４つのサブシステムがあるが、４つのサブシステムを、連携して動作する４つの独立したプログラムにより実現してもよく、４つの機能を含む１つのプログラムにより実現してもよい。あるいは、２つまたは３つの機能を１つのプログラムにまとめたり、１つの機能を複数の連携したプログラムにより実現したりしてもよく、当業者なら様々な態様で実施することが可能である。４つのサブシステムで行う処理内容の詳細は後述する。

図５は運用データの格納例である。運用データはリポジトリ１０４内に格納されるデータで、バッチシステム１０１の運用状態を示す。図５は表形式で表現した例だが、実データは表形式以外の形式で格納されていてもよい。後述するように、運用データは受付サーバ１０２内の運用データ採取サブシステム１０７および各実行サーバ１０３−１、１０３−２、……、１０３−Ｎ内の運用データ採取サブシステム１１０によって記録される。

図５の表には、レコード（行）を格納した日時を示す「格納日時」列、レコードの種別を示す「レコード情報種別」列がある。レコードの種別により、格納すべきデータ項目の数や内容は異なる。そのため、データ項目の各列（「データ項目１」、「データ項目２」、……）は、レコードの種別により、使用されるか否かが異なり、使用される場合も格納されるデータの意味が異なる。

図５の例では種別の異なる４つのレコードが存在する。１番目のレコードの内容は、格納日時が「２００６／０２／０１ １０：００：００．００１」、レコード種別が「１０」（バッチジョブに関する一連の処理を開始したことを示すコード）、データ項目１が「ＪＯＢ１」（このバッチジョブの識別名）である。データ項目２以降の列は使っていない。このレコードは、ＪＯＢ１というバッチジョブの処理を開始したことを２００６／０２／０１ １０：００：００．００１に記録したことを意味する。運用データにおいてレコード種別が「１０」のレコードを以下では「ジョブ開始データ」と呼ぶ。

２番目のレコードの内容は、格納日時が「２００６／０２／０１ １０：００：００．０５０」、レコード種別が「２０」（バッチジョブの実行時間と負荷を予測したことを示すコード）、データ項目１が「ＪＯＢ１」、データ項目２が「１０００」（ＪＯＢ１の入力データの件数）、データ項目３が「３３００秒」（ＪＯＢ１の実行にかかると予測された時間）、データ項目４が「６００．０秒」（ＪＯＢ１の実行にかかると予測されたＣＰＵ使用量、つまりＣＰＵ占有時間）、データ項目５が「９％」（ＪＯＢ１の実行によって増加すると予測されたＣＰＵ使用率）、データ項目６が「４．５ＭＢ」（ＪＯＢ１が使用すると予測されたメモリ使用量）である。このレコードは、ＪＯＢ１の実行にかかる時間および負荷を予測したことを２００６／０２／０１ １０：００：００．０５０に記録したことを意味し、その予測内容がデータ項目２以降に記録されている。データ項目７以降は図示されていないが、実施の態様に応じて必要な項目が予測され、予測結果が格納されている。運用データにおいてレコード種別が「２０」のレコードを以下では「ジョブ実行予測データ」と呼ぶ。

なお、バッチジョブの実行にかかる時間やＣＰＵ使用率は、どの実行サーバに対する予測かによって予測値が異なるが、ここでは実行サーバごとの差は図示されていない。例えば、実行サーバ１０３−１、１０３−２、……、１０３−Ｎのハードウェアの違いが無視できる程度であれば、１つのＣＰＵ使用率が１つのデータ項目に記録されるだけで十分である。一方、各実行サーバ１０３−１、１０３−２、……、１０３−Ｎのハードウェア性能が、無視することができない程度に異なる場合は、例えば、各実行サーバに対するＣＰＵ使用率をそれぞれ予測して別の列にそれぞれ予測値を格納してもよい。あるいは、ある１つのＣＰＵ使用率だけを基準として記録し、各実行サーバ１０３−１、１０３−２、……、１０３−ＮにおけるＣＰＵ使用率はその基準から所定の方法で換算することとしてもよい。

３番目のレコードの内容は、格納日時が「２００６／０２／０１ １０：５５：３０．０１０」、レコード種別が「３０」（バッチジョブの実行が終了したことを示すコード）、データ項目１が「ＪＯＢ１」、データ項目２が「５８２．０秒」（ＪＯＢ１が使用したＣＰＵの量の実測値）、データ項目３が「１０％」（ＪＯＢ１によって増加したＣＰＵ使用率の実測値）、データ項目４が「４．３ＭＢ」（ＪＯＢ１が使用したメモリの量の実測値）、データ項目５が「５％」（ＪＯＢ１が使用したメモリの割合の実測値）、データ項目６が「１６０００」（ＪＯＢ１によって発生した物理Ｉ／Ｏの回数）である。このレコードは、ＪＯＢ１の実行が終了したことを２００６／０２／０１ １０：５５：３０．０１０に記録したことを意味し、その実行にかかった負荷の実測値がデータ項目２以降に記録されている。データ項目７以降は図示されていないが、実施の態様に応じて必要な項目が計測され、その実測値が記録されている。運用データにおいてレコード種別が「３０」のレコードを以下では「ジョブ実測データ」と呼ぶ。

４番目のレコードの内容は、格納日時が「２００６／０２／０１ １０：５５：３０．１００」、レコード種別が「９０」（バッチジョブに関する一連の処理が全て終了したことを示すコード）、データ項目１が「ＪＯＢ１」である。データ項目２以降の列は使っていない。このレコードは、ＪＯＢ１に関する一連の処理が終了したことを２００６／０２／０１ １０：５５：３０．１００に記録したことを意味する。運用データにおいてレコード種別が「９０」のレコードを以下では「ジョブ終了データ」と呼ぶ。

なお、運用データは上記の４つの種別に限定されるものではなく、実施の態様に応じて、任意の種別を追加することができる。例えば、図７に示すサーバ負荷情報に相当するデータを運用データとして記録してもよい。また、レコード種別を数字コード以外の形式で表現するなど、表現形式は実施の態様に応じて任意に選択してよい。また、運用データとして記録するデータ項目は、実施の態様に応じて任意に定めてよい。例えば、入力データ量（入力レコード数）、ＣＰＵの使用量、ＣＰＵの使用率、メモリの使用量、メモリの使用率、物理Ｉ／Ｏの発行回数、ファイルの使用量、ファイルの使用数、ファイルの占有時間、ユーザ資源の競合、システム資源の競合、競合が発生したときの待ち時間、などの中から実施の態様に応じた項目を記録することができる。

図６はバッチジョブ特性の格納例である。バッチジョブ特性はリポジトリ１０４内に格納されるデータで、バッチジョブの特性を示す。後述するように、バッチジョブ特性は自動的に作成・更新される。よって、従来のようにシステム管理者などが手間と時間をかけてバッチジョブ特性を把握する必要がない。また、常に最新のバッチジョブ特性が得られる。図６は表形式で表現した例だが、実データは表形式以外の形式で格納されていてもよい。後述するように、バッチジョブ特性は受付サーバ１０２内のジョブ情報更新サブシステム１０８によって記録される。

図６の表には、バッチジョブの識別名を示す「ジョブ識別名」列、何に関する特性を記録したレコード（行）なのかを示す「データ種別１」列および「データ種別２」列、個々の特性の特性値を記録した「データ値」列がある。

図６の例では、データ種別１とデータ種別２の２つの列の組み合わせにより、階層的にデータ種別を示している。データ種別１とデータ種別２は、図６の例では「１０」（実行時間を示すコード）や「９０」（実測誤差を示すコード）のように、コード化された数字が記録されている。

図６では、データ種別として、「実行数」、「実行時間」、「ＣＰＵ情報」、「メモリ情報」、「物理Ｉ／Ｏ情報」という種別があり、それぞれの種別をさらに細分化した種別に対してデータ値が記録されている。

バッチジョブ特性のデータ種別としては、入力データ量（入力レコード数）、ＣＰＵの使用量、ＣＰＵの使用率、メモリの使用量、メモリの使用率、物理Ｉ／Ｏの発行回数、ファイルの使用量、ファイルの使用数、ファイルの占有時間、ユーザ資源の競合、システム資源の競合、競合が発生したときの待ち時間、などを利用することができる。実施の態様に応じて、必要なデータ種別をバッチジョブ特性として利用すればよい。

なお、図６は「ＪＯＢ１」という識別名のバッチジョブの特性のみを図示しているが、実際には、複数のバッチジョブの特性が格納されている。また、図６の例では多くの行は処理データ１件当たりの値に換算された値がデータ値列に記録されているが、データ種別の性質によっては、１件当たりに換算しないデータ値を記録してもよい。１件当たりの値に換算された値か否かは、データ種別１とデータ種別２の組み合わせで表されるデータ種別に応じて、予め定められている。また、データ種別を数字コード以外の形式で表現したり、１列で表現したりするなど、表現形式は実施の態様に応じて任意に選択してよい。

また、データ種別として図６に示したものが必須というわけではなく、これらのうちの一部のみを用いてもよい。逆に、図６に示していない他のデータ種別について記録してもよい。ただし、バッチジョブ特性は後述の方法により運用データ（図５）から作成されるため、バッチジョブ特性として利用する項目は運用データ作成時にも記録する必要がある。

また、実行サーバ１０３−１、１０３−２、……、１０３−Ｎのハードウェア性能が、無視することができない程度に異なる場合は、一部のデータ種別について、実行サーバごとにバッチジョブ特性を記録した方がよい場合がある。例えば、実行時間やＣＰＵ使用率などは、実行サーバのハードウェア性能によって影響を受けるため、実行サーバごとに記録することが望ましい場合がある。一方、メモリ使用量や物理Ｉ／Ｏの発行回数などは、通常は実行サーバのハードウェア性能の影響をあまり受けないから、実行サーバごとに記録する必要はない。

図７は、サーバ負荷情報の格納例である。サーバ負荷情報はリポジトリ１０４内に格納されるデータで、実行サーバ１０３−１、１０３−２、……、１０３−Ｎそれぞれの負荷状況を示す。図７は表形式で表現した例だが、実データは表形式以外の形式で格納されていてもよい。後述するように、サーバ負荷情報は各実行サーバ１０３−１、１０３−２、……、１０３−Ｎ内の性能情報収集サブシステム１１１により収集され、サーバ情報採取サブシステム１１２により記録される。また、図７のデータをグラフ表示すると、図３に似た折れ線グラフが得られる。

図７の表には、実行サーバの識別名を示す「サーバ識別名」列、実行サーバの負荷状況を測定し、サーバ負荷情報としてレコード（行）に格納した時刻を示す「採取時間帯」列、負荷情報の種別を示す「データ種別１」列および「データ種別２」列、個々の負荷情報の実測値を記録した「データ値」列がある。

まず、図７の例の前提条件について説明する。図７は、実行サーバ１０３−１、１０３−２、……、１０３−Ｎの負荷状況を１０分ごとに測定し、サーバ負荷情報として記録する場合の例である。また、図７は、「バッチジョブのほとんどが日次業務に関するものなので、実行サーバの負荷は１日周期で変動し、同じ時刻の負荷はどの日でもほぼ同じ量となる」という前提にもとづく。

上記の前提のもとで、サーバ負荷情報は、毎日、例えば０時０分から１０分ごとに２３時５０分まで測定されて記録される。また、同じ時刻の負荷はどの日でもほぼ同じ量だという前提があるため、前日の同時刻の記録が上書きされる。さらに、最新の測定時刻におけるデータが特別な「最新状態」データとして別途記録される。つまり、各実行サーバ１０３−１、１０３−２、……、１０３−Ｎに対して、それぞれ（６０÷１０）×２４＋１＝１４５個のデータのブロックが記録されている（以下、データのブロックとは、図７において採取時間帯の値ごとにまとめられた複数行のことを指すものとする）。例えば、０時３０分には、前日の０時３０分に記録された０時３０分のブロックが上書きされるとともに、１０分前の０時２０分に記録された「最新状態」のブロックが上書きされる。すなわち、「最新状態」のブロックのデータ値の内容は、残りの１４４個のブロックのうちのいずれか１つと同じである。

サーバ負荷情報は上記のように特定の時刻に記録されるが、ある時間帯のサーバ負荷状況を代表するものとして特定の時刻のデータを記録しているとも見なせる。例えば、１０分ごとに記録されるサーバ負荷情報は、１０分間の負荷状況の代表であると見なせる。よって、「採取時間帯」などの表現をすることもある。

さて、こうして記録される個々のデータについて、図７の０時１０分のブロックを例に以下で説明する。このブロックには、実行サーバ１０３−１、１０３−２、……、１０３−Ｎのうち、サーバ識別名が「ＳＶＲ１」である実行サーバの負荷状況を０時１０分に実測した結果が記録されている。負荷状況を示す負荷情報は、具体的には、ＣＰＵ使用率が７１％、メモリ使用量が１．１ＧＢ、ハードディスク使用量（図中の「／ｄｅｖ／ｈｄａ」はハードディスクを示す例）が８．５ＧＢ、物理Ｉ／Ｏの平均待ち時間が１６ｍｓ、などである。また、あわせて、ＳＶＲ１に搭載しているメモリ総量が２ＧＢであり、ハードディスク総量が４０ＧＢである、などの情報も記録している。使用率や空き容量は、総量と使用量から算出することができる。

実施の態様によっては、１０分以外の間隔で測定および記録を行ってもよい。また、実際には、週次業務、月次業務など、他の周期で実行されるバッチジョブもあるので、採取時間帯（採取時刻）ではなく、採取日時を記録するようにしてもよい。その場合、上記の例のように直近の１日（つまり２４時間）のサーバ負荷情報だけを蓄積するのではなく、周期の長さに合わせた量のサーバ負荷情報を蓄積することが望ましい。例えば、バッチシステム１０１が、月次業務、週次業務、日次業務のそれぞれの周期の影響を受ける場合、最も長い周期である１ヶ月分のサーバ負荷情報を蓄積し、１ヶ月前の同時刻のブロックを上書きすることが望ましい。なお、実施の態様によって適切な周期の長さは異なるものの、一般に、バッチジョブの多くは定例的に実行されるので、実行サーバの負荷状況にはある程度の周期性が存在する。

また、データ種別として図７に示したものが必須というわけではなく、これらのうちの一部のみを用いてもよい。逆に、図７に示していない他のデータ種別について記録してもよい。例えば、ＣＰＵの使用率、ＣＰＵの使用量、メモリの使用率、メモリの使用量、物理Ｉ／Ｏの平均待ち時間、ファイルの使用量、記憶装置の空き容量、などの中から、実施の態様に応じて必要なデータ種別をサーバ負荷情報として記録することができる。ただし、周期の違いはあるものの、いずれにせよサーバ負荷情報は時刻と関連づけて記録されている必要がある。メモリやハードディスクの総量などのハードウェア資源の量は、ハードウェアの増設などを行わなければ変化しないから、サーバ負荷情報として１０分ごとに記録するのではなく、サーバ負荷情報とは別の静的なデータとしてリポジトリ１０４などに別途記録しておいてもよい。

図８は、分散条件の例である。分散条件は、リポジトリ１０４内に格納されるデータで、バッチジョブを実行するサーバを選択するときに参照する規則である。本発明においては、分散条件が事前に何らかの方法で決定され、リポジトリ１０４内に格納されているものとする。

図８には「条件１」と「条件２」という２つの分散条件があり、条件１が条件２に優先して適用されるべきだという優先順序が指定されている。条件１の意味は、「メモリ使用率が５０％未満のサーバの中でＣＰＵ使用率が一番低いサーバを選択せよ」である。条件２の意味は、「メモリ使用率が５０％未満のサーバが存在しないならば、メモリ使用率が一番低いサーバを選択せよ」である。この例の場合、条件１が条件２に優先するという順序が指定されているので、条件２を、「メモリ使用率が一番低いサーバを選択せよ」を意味する規則「ＭＩＮ（メモリ使用率） ＩＮ ＡＬＬ」に置き換えても同じ結果が得られる。

図８の例は、複数の実行サーバを比較してその中から条件を満たす実行サーバを選択する分散条件の例だが、他の実行サーバとの相対的な比較ではなく、それぞれの実行サーバに対して「メモリ使用率が５０％以上のサーバを選択してはいけない」などの固定的な制約条件を課してもよい。一般に実行サーバ１０３−１、１０３−２、……、１０３−Ｎは、バッチジョブ以外にオンラインジョブも実行する場合が多い。よって、オンラインジョブの実行用に一定のハードウェア資源を確保するため、上記のような固定的な制約条件を分散条件として予め定めておいてもよい。

なお、分散条件は、実施の態様に応じて、図８に示した書式以外の任意の書式で表現することが可能である。
図９は、バッチシステム１０１で実行される処理のフローチャートである。図９の処理は、バッチジョブごとに実行される処理である。

ステップＳ１０１では、受付サーバ１０２のジョブ受付サブシステム１０５がバッチジョブの実行要求を受け付ける。図９のフローチャートにおいて、以後このバッチジョブをカレントバッチジョブと呼ぶことにする。ステップＳ１０１は図４の（１）に相当する。バッチジョブの実行要求は、バッチシステム１０１の外部から与えられる。優先度などに応じてジョブ同士の実行順序を調整する必要がある場合も、バッチシステム１０１の外部で調整が済んでいるものとする。つまり、本発明においては、ジョブ受付サブシステム１０５が実行要求を受け付けた順に一つずつバッチジョブの実行要求を処理していくという前提が成立している。

ステップＳ１０２では、カレントバッチジョブに関して、ジョブ開始データ（図５）をリポジトリ１０４内の運用データに追加するよう、ジョブ受付サブシステム１０５が運用データ採取サブシステム１０７に依頼する。そしてステップＳ１０３に移行する。ステップＳ１０２は図４の（２）に相当する。

ステップＳ１０３では、運用データ採取サブシステム１０７がジョブ開始データを運用データに追加する。つまり、リポジトリ１０４内の運用データにジョブ開始データが記録される。そしてステップＳ１０４に移行する。ステップＳ１０３は図４の（３）に相当する。

ステップＳ１０４では、カレントバッチジョブを実行する実行サーバを実行サーバ群１０３の中から選択して、その実行サーバにカレントバッチジョブを実行させるよう、ジョブ受付サブシステム１０５がジョブ分散サブシステム１０６に依頼する。そしてステップＳ１０５に移行する。ステップＳ１０４は図４の（４）に相当する。

ステップＳ１０５では、ジョブ分散サブシステム１０６がカレントバッチジョブの実行にかかる時間を予測し、予測した時間の範囲の中で最適な実行サーバを決定する。ここで実行サーバ１０３−ｓが選択されたものとする（１≦ｓ≦Ｎ）。ステップＳ１０５のこの処理の詳細は図１０とあわせて後述する。さらにステップＳ１０５では、カレントバッチジョブの実行に必要な資源（時間やメモリ使用量など）をジョブ分散サブシステム１０６が予測し、運用データ採取サブシステム１０７がジョブ実行予測データ（図５）をリポジトリ１０４内の運用データに追加する（つまり記録する）。そしてステップＳ１０６に移行する。ステップＳ１０５は図４の（５）に相当する。

ステップＳ１０６では、実行サーバ１０３−ｓ内のジョブ実行サブシステム１０９に対し、ジョブ分散サブシステム１０６がカレントバッチジョブの実行を依頼する。ここでは受付サーバ１０２と実行サーバ１０３−ｓのサーバ間通信が行われる。そしてステップＳ１０７に移行する。ステップＳ１０６は図４の（６）に相当する。

ステップＳ１０７では、実行サーバ１０３−ｓ内において、ジョブ実行サブシステム１０９が性能情報収集サブシステム１１１に対し、カレントバッチジョブのバッチジョブ特性のデータに対応するデータを記録するよう依頼する。具体的には、カレントバッチジョブの実行に起因するサーバ１０３−ｓの負荷をモニタして、運用データ（図５）のジョブ実測データに含まれる各データ項目（例えばメモリ使用量）のデータ値を計測して記録するよう依頼する。そしてジョブ実行サブシステム１０９がカレントバッチジョブを実行し、性能情報収集サブシステム１１１はそれによって発生した実行サーバ１０３−ｓの負荷をモニタする。カレントバッチジョブを正常に実行し終わるとステップＳ１０８に移行する。ステップＳ１０７は図４の（７）に相当する。

ステップＳ１０８では、性能情報収集サブシステム１１１がモニタした負荷状況をもとにジョブ実測データを記録するよう、性能情報収集サブシステム１１１が運用データ採取サブシステム１１０に依頼し、モニタしたデータを運用データ採取サブシステム１１０に与える。そして、運用データ採取サブシステム１１０は依頼にもとづき、ジョブ実測データをリポジトリ１０４内の運用データに追加する（つまり記録する）。そしてステップＳ１０９に移行する。ステップＳ１０８は図４の（８）に相当する。

ステップＳ１０９では、カレントバッチジョブの実行が終了した旨を、ジョブ実行サブシステム１０９からジョブ受付サブシステム１０５に通知する。ここでもステップＳ１０６と同様に、受付サーバ１０２と実行サーバ１０３−ｓのサーバ間通信が行われる。そしてステップＳ１１０に移行する。ステップＳ１０９は図４の（９）に相当する。

ステップＳ１１０では、通知にもとづき、カレントバッチジョブに関して、ジョブ終了データ（図５）をリポジトリ１０４内の運用データに追加するよう、ジョブ受付サブシステム１０５が運用データ採取サブシステム１０７に依頼する。そして、運用データ採取サブシステム１０７は依頼にもとづき、ジョブ終了データをリポジトリ１０４内の運用データに追加する（つまり記録する）。そしてステップＳ１１１に移行する。ステップＳ１１０は図４の（１０）に相当する。

ステップＳ１１１では、リポジトリ１０４内のバッチジョブ特性を更新するよう、ジョブ受付サブシステム１０５がジョブ情報更新サブシステム１０８に依頼する。そしてステップＳ１１２に移行する。ステップＳ１１１は図４の（１１）に相当する。

ステップＳ１１２では、ジョブ情報更新サブシステム１０８がカレントバッチジョブのバッチジョブ特性を更新する。つまり、リポジトリ１０４の格納内容が更新される。更新は、ステップＳ１０８で記録されたジョブ実測データにもとづいて行われるが、詳細は後述する。ステップＳ１１２の実行後、処理を終了する。ステップＳ１１２は図４の（１２）に相当する。

図１０は、図９のステップＳ１０５で行う、バッチジョブの実行サーバを決定する処理を詳細に示したフローチャートである。図１０の処理は、受付サーバ１０２内のジョブ分散サブシステム１０６により実行される。

まず図１０で用いる変数について説明する。ｔ_１とｔ_２は図３と同様で、バッチジョブの実行範囲を示す時刻である。つまり、ｔ_１はバッチジョブの開始予定時刻で、ｔ_２はバッチジョブの実行が終了すると予測される時刻である。ｊは１つの実行サーバ１０３−ｊを実行サーバ群１０３の中から指定するための添え字である。サーバ負荷情報（図７）のデータ種別の数をＬとする。ｋはサーバ負荷情報のデータ種別を指定するための添え字である。ｊとｋは、後述のＭ_ｊｋ、Ｓ_ｊｋ、Ｄ_ｊｋ、Ｃ_ｊｋ、Ａ_ｊｋ、Ｘ_ｊｋ、Ｙ_ｊｋにおいて添え字として使われる。これらの変数は、受付サーバ１０２のＣＰＵ（Central Processing Unit）内のレジスタやメモリに格納され、参照または更新される。

ステップＳ２０１では、リポジトリ１０４を検索して、カレントバッチジョブに対応するバッチジョブ特性（図６）がリポジトリ１０４に格納されているかどうかを調べる。格納されていればそのバッチジョブ特性を受付サーバ１０２内のメモリなどに記憶する。

ステップＳ２０２では、ステップＳ２０１で調べた結果にもとづき、カレントバッチジョブに対応するバッチジョブ特性が存在するか否か判定する。存在すれば判定がＹｅｓとなってステップＳ２０３に移行し、存在しなければ判定がＮｏとなってステップＳ２１４に移行する。

ステップＳ２０３では、カレントバッチジョブの入力データ量を求める。そして、入力データ量とステップＳ２０１で記憶したバッチジョブ特性とにもとづいてカレントバッチジョブの実行にかかる時間を予測する。入力データ量は、例えば処理件数で表してもよく、処理件数と１件に含まれるデータ項目数など複数の要素を考慮した量で表してもよい。例えば、入力データがテキストファイルで与えられ、１件の入力データが１行に書かれている場合、当該テキストファイルの行数を調べ、入力データ量として使ってもよい。

また、例えば、図６のバッチジョブ特性の例では、ＪＯＢ１の実行時間は処理データ１件あたり３．３秒とある。よって、カレントバッチジョブがＪＯＢ１で、入力データ量として１０００件という処理件数が与えられた場合、本実施形態においては、カレントバッチジョブの実行にかかる時間は、３．３×１０００＝３３００秒という乗算を受付サーバ１０２のＣＰＵで実行することにより予測される。他の実施形態では乗算以外の算出方法を用いてもよい。カレントバッチジョブの実行開始予定時刻ｔ_１は実施の態様に応じて適当な方法で決めればよいので、この予測により、カレントバッチジョブの実行が終了すると予測される時刻ｔ_２が決定される（この例ではｔ_２はｔ_１の３３００秒後である）。ステップＳ２０３の終了後、ステップＳ２０４に移行する。

ステップＳ２０４では実行サーバを指定する添え字ｊに０を代入して初期化する。そしてステップＳ２０５に移行する。
ステップＳ２０５からステップＳ２１１の各ステップにより繰り返しループが形成されている。ステップＳ２０５では、まずｊに１を足し、サーバ負荷を予測する対象として実行サーバ１０３−ｊを選択する。そしてステップＳ２０６に移行する。

ステップＳ２０６では、リポジトリ１０４に格納されたサーバ負荷情報（図７）のうち、実行サーバ１０３−ｊに対応するデータで、「最新状態」のブロックのものと、カレントバッチジョブの実行範囲に対応するブロックのものを読み込み、受付サーバ１０２のメモリなどに記憶する。図７のサーバ負荷情報は、１日周期でほぼ同じ負荷状態が繰り返されるという前提が成立する場合の例である。この例の場合、ステップＳ２０６では、時刻ｔ_１からｔ_２の範囲内の時刻のブロックのサーバ負荷情報を読み込む。読み込んだ各時刻のブロックのサーバ負荷情報自体は過去の実績にもとづく情報だが、ここでは、未来の時刻ｔ_１からｔ_２の範囲におけるサーバ負荷情報の予測値を得るために利用している。本実施例においては、読み込んだ各時刻のブロックのサーバ負荷情報そのものを、対応する未来に時刻におけるサーバ負荷情報の予測値として利用している。

なお、サーバの負荷状況が変動する周期の長さが異なる実施態様においては、その周期に合わせた適切なデータを読み込む。例えば、周期の長さが１ヶ月の場合、サーバ負荷情報は１ヶ月分蓄積されているので、１ヶ月前の日の時刻ｔ_１からｔ_２の範囲内の時刻のブロックのサーバ負荷情報を読み込む。必要なデータを読み込んだら、ステップＳ２０７に移行する。

ステップＳ２０７では、カレントバッチジョブの実行範囲における、実行サーバ１０３−ｊの負荷の平均値を、サーバ負荷情報のデータ種別ごとに算出する。Ｌ個のデータ種別のうちｋ番目のデータ種別について算出した平均値をＭ_ｊｋとして受付サーバ１０２のメモリなどに記憶する。図３に関して説明したとおり、カレントバッチジョブの実行範囲におけるサーバ負荷の総量のかわりに、実行範囲におけるサーバ負荷の平均値を用いても、負荷の総量を考慮したのと同じ判定結果が得られる。よって、ステップＳ２０７では平均値を算出している。なお、ステップＳ２０６で読み込んだデータは過去のサーバ負荷情報であり、算出した平均値Ｍ_ｊｋは、未来（時刻ｔ_１からｔ_２の範囲）における負荷の平均を過去のデータにもとづいて予測したものである。

ステップＳ２０７で算出するサーバ負荷の平均値が、カレントバッチジョブの実行範囲における平均値であるという点は、本発明の特徴である。これにより、バッチジョブの実行サーバを従来よりも適切に選択することができ、分散の効率を改善できる。つまり、従来のようにバッチジョブを実行する直前でのサーバ負荷状況だけを考慮するよりも、カレントバッチジョブの実行範囲全体の負荷状況を考慮することによって、より適切な選択が可能となる。また、平均値Ｍ_ｊｋを算出する範囲が、カレントバッチジョブの実行範囲という特定の時間帯であるため、例えば１ヶ月ごとのサーバの負荷状況の平均など、カレントバッチジョブの実行範囲と無関係な大雑把な範囲の負荷状況の平均と比べると、Ｍ_ｊｋの方がより正確な予測値である。

なお、図７の例ではサーバ負荷情報が１０分ごとに記録されるが、時刻ｔ_１とｔ_２は１０分ごとの切りのよい時刻とは限らない。その場合は、必要に応じて適切な端数処理を行ってもよい。

ステップＳ２０７で１≦ｋ≦Ｌなる全てのｋについて平均値Ｍ_ｊｋを算出したら、ステップＳ２０８に移行する。ステップＳ２０８からステップＳ２１０までは、図１０の処理を実行している時点に近い未来の時刻をｔ_１として指定する場合に、より精度よく最適な実行サーバを決定するために行うステップである。

ステップＳ２０８では、サーバ負荷情報の各データ種別について、平均値Ｍ_ｊｋと、時刻ｔ_１におけるサーバ負荷情報のデータ値Ｓ_ｊｋとの差Ｄ_ｊｋを算出する。つまり、Ｄ_ｊｋ＝Ｍ_ｊｋ−Ｓ_ｊｋである。なお、サーバ負荷情報は一定間隔で記録されるため、時刻ｔ_１と同時刻のデータがあるとは限らない。その場合、Ｓ_ｊｋは、時刻ｔ_１の前後の時刻のサーバ負荷情報から補間により算出してもよく、時刻ｔ_１の直前または直後の時刻のサーバ負荷情報で代用してもよい。１≦ｋ≦Ｌなる全てのｋについて差Ｄ_ｊｋを算出したら、ステップＳ２０９に移行する。

ステップＳ２０９では、１≦ｋ≦Ｌなる全てのｋについて、ステップＳ２０６で読み込んだ最新状態のブロックのサーバ負荷情報のｋ番目のデータ種別のデータ値Ｃ_ｊｋにＤ_ｊｋを加算してＡ_ｊｋを算出する。Ａ_ｊｋは、Ｍ_ｊｋを補正して信頼度を高めた値に相当する。理由は以下のとおりである。

ステップＳ２０６からＳ２０８の動作から明らかなとおり、Ｍ_ｊｋとＳ_ｊｋは、過去のデータにもとづいて算出される値である。本発明では、実行サーバの負荷状況に周期性があり、周期性を利用して過去の負荷情報から未来の負荷状況を予測できるということを前提としているが、予測には誤差が伴う。一方、Ｃ_ｊｋは最新の実測値なので、情報の信頼度が高い。上記のようにｔ_１は図１０の処理を実行している時点に近い時刻なので、Ｃ_ｊｋを記録した時刻にも近い。よって、過去のデータにもとづいて算出した時刻ｔ_１における負荷情報Ｓ_ｊｋを、実測値Ｃ_ｊｋに補正することにより、情報の信頼度が高まると期待できる。一方、実行サーバを選択するために必要なデータは、Ｃ_ｊｋではなく、カレントバッチジョブの実行範囲における実行サーバ１０３−ｊの負荷の平均値である。よって、Ｓ_ｊｋとＣ_ｊｋの関係から、Ｍ_ｊｋを補正してＡ_ｊｋを算出する。上述の説明からＡ_ｊｋは、Ａ_ｊｋ＝Ｃ_ｊｋ＋Ｄ_ｊｋ＝Ｃ_ｊｋ＋Ｍ_ｊｋ−Ｓ_ｊｋ＝Ｍ_ｊｋ＋（Ｃ_ｊｋ−Ｓ_ｊｋ）と表現でき、Ｍ_ｊｋを補正した値に相当することが分かる。つまり、Ａ_ｊｋは、カレントバッチジョブの実行範囲における実行サーバ１０３−ｊの負荷の平均値として予測される値であって、精度を上げるための補正を行った後の値である。

例えば、図７のようにサーバ負荷状況が１日周期で変動し１０分ごとにサーバ負荷情報を記録している場合で、図１０の処理を実行している時点が１０時１２分、ｔ_１が１０時１４分、ｔ_２が１１時３０分の場合、「最新状態」のサーバ負荷情報は１０時１０分に記録されたものである。つまり、Ｃ_ｊｋは１０時１０分の実測値である。一方、Ｍ_ｊｋとＳ_ｊｋは前日のサーバ負荷情報にもとづいた値である。よって、上記のようにＡ_ｊｋを算出することにより、カレントバッチジョブの実行範囲における実行サーバ１０３−ｊの負荷の平均値の予測値の精度向上を図る。

ステップＳ２０９で１≦ｋ≦Ｌなる全てのｋについてＡ_ｊｋを算出したら、ステップＳ２１０に移行する。
ステップＳ２１０では、１≦ｋ≦Ｌなる全てのｋについて、カレントバッチジョブのバッチジョブ特性から、カレントバッチジョブの実行によって発生する負荷Ｘ_ｊｋを予測する。カレントバッチジョブのバッチジョブ特性は、既にステップＳ２０１でメモリなどに記憶されている。そして、カレントバッチジョブを実行した場合の、カレントバッチジョブの実行範囲における実行サーバ１０３−ｊの負荷状況を、１≦ｋ≦Ｌなる全てのｋについて、Ｘ_ｊｋとＡ_ｊｋにもとづいて予測する。この予測値をＹ_ｊｋとして記憶しておく。

例えば、図６のバッチジョブ特性の例において、カレントバッチジョブがＪＯＢ１であり、ｋ番目のデータ種別が物理Ｉ／Ｏの発行回数の場合、Ｘ_ｊｋは少なくとも「１６回」というデータ値にもとづいて予測される。実施の態様によっては、さらにカレントバッチジョブの実行範囲の時間の長さ、処理件数、実測誤差（上記の例では、図６の物理Ｉ／Ｏの発行回数に関する実測誤差「２．１回」に相当する）なども加味してＸ_ｊｋを予測してもよい。例えば、上記の例で処理件数が１０００件のとき、Ｘ_ｊｋ＝（１６＋２．１）×１０００÷（ｔ_２−ｔ_１）、Ｙ_ｊｋ＝Ａ_ｊｋ＋Ｘ_ｊｋと算出し、それをＸ_ｊｋとＹ_ｊｋの予測値としてもよい。もちろん、これ以外の任意の算出方法を用いて予測してもよい。

また、実行サーバ１０３−１、１０３−２、……、１０３−Ｎのハードウェア性能の差が無視できる程度であれば、１≦ｊ≦Ｎなる全てのｊについてＸ_ｊｋの値を等しいと見なすことができる。この場合、ステップＳ２０５からステップＳ２１１の繰り返しループで、ステップＳ２１０を実行するたびにＸ_ｊｋを算出するのではなく、ｊ＝１のときのみＸ_ｊｋ（＝Ｘ_1ｋ）を算出し、ｊ＞１のときは、既に算出され記憶されているＸ_1ｋをＸ_ｊｋとして用いてもよい。

ステップＳ２１０で１≦ｋ≦Ｌなる全てのｋについてＹ_ｊｋを算出したら、ステップＳ２１１に移行する。
ステップＳ２１１では、カレントバッチジョブを実行した場合の、カレントバッチジョブの実行範囲における負荷状況を、全ての実行サーバについて算出したかどうかを判定する。つまり、ｊ＝Ｎか否かを判定する。全ての実行サーバについて算出し終えた場合（ｊ＝Ｎ）、判定はＹｅｓとなってステップＳ２１２に移行し、そうでない場合（ｊ＜Ｎ）、判定はＮｏとなってステップＳ２０５に戻る。なお、ｊ＞Ｎとならないことは、ステップＳ２０４、Ｓ２０５、Ｓ２１１から明らかであろう。

ステップＳ２１２では、ステップＳ２１０で算出したＹ_ｊｋとリポジトリ１０４に格納された分散条件にしたがって、カレントバッチジョブの実行サーバを決定する。分散条件が図８の例の場合、まず「条件１」を使って、メモリ使用率が５０％未満の実行サーバの中でＣＰＵ使用率が一番低い実行サーバを探す。バッチジョブ特性において、メモリ使用率がｍ番目のデータ種別であり、ＣＰＵ使用率がｃ番目のデータ種別であるとすると、１≦ｊ≦Ｎなる全てのＹ_ｊｍのうち、Ｙ_ｊｍ＜５０％となるｊの集合を求める。この集合が空でなければ、その中でＹ_ｊｃが最小となるｊを求める。求めた値をｓとすると、実行サーバ１０３−ｓをカレントバッチジョブの実行サーバとして選択する。Ｙ_ｊｍ＜５０％となるｊが存在しない場合は「条件２」を使う。つまり、メモリ使用率が一番低いサーバを探すため、１≦ｊ≦Ｎなる全てのｊにおいてＹ_ｊｍが最小となるｊを求める。求めた値をｓとすると、実行サーバ１０３−ｓをカレントバッチジョブの実行サーバとして選択する。「条件１」または「条件２」によって実行サーバ１０３−ｓが選択されると、処理はステップＳ２１３に移行する。

ステップＳ２１３では、ジョブ分散サブシステム１０６が運用データ採取サブシステム１０７に、ジョブ実行予測データをリポジトリ１０４内の運用データ（図５）に追加させる。ジョブ実行予測データとして記録する項目は、図５に関して説明したとおりである。それらの項目は、ステップＳ２１０で算出したＸ_ｓｋ（１≦ｋ≦Ｌ）の全部または一部に相当する。ステップＳ２１３の実行後、処理を終了する。

ところで、ステップＳ２０２で判定がＮｏとなった場合はステップＳ２１４に移行する。ステップＳ２１４からステップＳ２１６は例外処理のためのステップである。サーバ負荷情報（図７）に関して述べたとおり、バッチジョブの大部分は定例的に実行される。一方、ステップＳ２０２で判定がＮｏとなるのは、カレントバッチジョブに対応するバッチジョブ特性がリポジトリ１０４に記録されていない場合である。つまり、１回だけ実行されるバッチジョブや初めて実行されるバッチジョブの場合であり、例外的な場合である。あるバッチジョブの実行が２回目以降なら、１回目に実行したときに図９のステップＳ１１２において既にバッチジョブ特性（図６）がリポジトリ１０４に記録されているから、ステップＳ２０２の判定がＹｅｓとなり、ステップＳ２１４は実行されない。また、実施の態様によっては、システム管理者などが手動でバッチジョブ特性を指定するオプションを設けてもよく、その場合は、初めて実行するバッチジョブでも予めバッチジョブ特性が記録されている（つまりステップＳ２０２で判定がＹｅｓとなる）こともある。

ステップＳ２１４では実行サーバを指定する添え字ｊに０を代入して初期化する。そしてステップＳ２１５に移行する。
ステップＳ２１５とステップＳ２１６により繰り返しループが形成されている。ステップＳ２１５では、まずｊに１を足す。そして、リポジトリ１０４に格納されたサーバ負荷情報のうち、実行サーバ１０３−ｊの「最新状態」のブロックのデータを読み込む。そして、実行サーバ１０３−ｊのｋ番目のデータ種別をＹ_ｊｋとして受付サーバ１０２のメモリなどに記憶する。１≦ｋ≦Ｌなる全てのｋに対してＹ_ｊｋを記憶したら、ステップＳ２１６に移行する。

ステップＳ２１６では、「最新状態」のブロックのサーバ負荷情報を、全ての実行サーバについて読み込んだかどうかを判定する。つまり、ｊ＝Ｎか否かを判定する。全ての実行サーバについて読み込み済みの場合（ｊ＝Ｎ）、判定はＹｅｓとなってステップＳ２１２に移行し、そうでない場合（ｊ＜Ｎ）、判定はＮｏとなってステップＳ２１５に戻る。なお、ｊ＞Ｎとならないことは明らかであろう。

ステップＳ２１２では前述のとおり、分散条件にしたがって実行サーバを選択する。つまり、ステップＳ２１６からステップＳ２１２に移行する場合の処理は、バッチジョブの実行依頼があった時点の直近の負荷状況のみにもとづいてバッチジョブの実行サーバを選択する従来の手法と同様である。

なお、図３、図５、図６についての説明から分かるように、実行サーバ１０３−１、１０３−２、……、１０３−Ｎのハードウェア性能の差を無視することができない場合は、ステップＳ２０３での予測を各実行サーバに対して個々に行わなくてはならないこともある。その場合、ステップＳ２０６で読み込むデータのブロックの範囲も影響を受ける。また、ステップＳ２０３で予測した実行時間が長い実行サーバを、カレントバッチジョブを実行させる実行サーバの候補から除外するなどの処理を追加してもよい。例えば、予測した実行時間が所定の閾値より長い実行サーバを除外してもよく、予測した実行時間の長さを実行サーバ群１０３内で比較して、相対的な順位などから除外対象を決めてもよい。また、ステップＳ２１２で使われる分散条件に、実行時間の長さに応じた条件を含めてもよい。

図１１は、図９のステップＳ１１２で行う、運用データ（図５）にもとづいてバッチジョブ特性（図６）を更新する処理を詳細に示したフローチャートである。図１１の処理は、受付サーバ１０２内のジョブ情報更新サブシステム１０８により実行される。

ステップＳ３０１では、リポジトリ１０４に格納された運用データ（図５）のうち、カレントバッチジョブのジョブ開始データ、ジョブ実行予測データ、ジョブ実測データ、ジョブ終了データを読み込み、受付サーバ１０２のメモリ等に記憶する。そしてステップＳ３０２に移行する。

ステップＳ３０２では、ジョブ終了データの格納日時とジョブ開始データの格納日時の差から、カレントバッチジョブの処理時間を算出する。そして、処理件数１件あたりの処理時間Ｔを算出し、ステップＳ３０３に移行する。なお、実施の態様によっては、ジョブ実測データにカレントバッチジョブの処理時間やＴを記録しておき、ステップＳ３０２ではそれを読み込んでもよい。また、ジョブ終了データの格納日時とジョブ開始データの格納日時の差を処理件数で割ってＴを算出してもよく、別の方法でＴを算出してもよい（例えば、入力データの件数に関わらず一定の時間を要する処理を含むバッチジョブの場合など）。

ステップＳ３０３では、ステップＳ３０１で読み込んだジョブ実測データの各データ項目のうち、バッチジョブ特性として記録すべき項目について、処理件数１件あたりのデータ値を算出する。バッチジョブ特性として記録すべきデータ種別の数をＢとすると、１≦i≦Ｂなる全てのｉに対して、ｉ番目のデータ種別に対応するジョブ実測データ中のデータ値と処理件数とにもとづいて、処理件数１件あたりのデータ値Ｃ_ｉを算出する。Ｃ_ｉは、例えば、ｉ番目のデータ種別に対応するジョブ実測データ中のデータ値を処理件数で割って求めてもよい。単純な割り算が適切でないデータ種別の場合は、それ以外の方法で算出してもよい。例えば、メモリ使用量は、プログラムのロードなど処理件数に関わらず使用される部分と、処理件数にほぼ比例して使用される部分を含むので、単純な割り算が適さないことがある。１≦i≦Ｂなる全てのｉに対してＣ_ｉを算出したら、ステップＳ３０４に移行する。

ステップＳ３０４では、１≦i≦Ｂなる全てのｉに対して、ｉ番目のデータ種別に対応する、処理件数１件あたりの予測誤差Ｅ_ｉを算出する。具体的には、ステップＳ３０１で読み込んだジョブ実行予測データとジョブ実測データで、ｉ番目のデータ種別に対応するデータ項目のデータ値をそれぞれ求め、２つのデータ値の差を算出する。その差と処理件数とにもとづいて、処理件数１件あたりの予測誤差Ｅ_ｉを算出する。Ｅ_ｉは、Ｃ_ｉと同様に割り算によって算出してもよく、他の計算方法で算出してもよい。１≦i≦Ｂなる全てのｉに対してＥ_ｉを算出したら、ステップＳ３０５に移行する。

ステップＳ３０５では、リポジトリ１０４にカレントバッチジョブのバッチジョブ特性が存在するか否かを判定する。存在する場合、判定はＹｅｓとなってステップＳ３０７に移行し、存在しない場合、判定はＮｏとなってステップＳ３０６に移行する。この判定は図９のステップＳ２０１、Ｓ２０２と同様で、判定がＮｏとなるのは、１回だけ実行されるバッチジョブや初めて実行されるバッチジョブの場合である。

ステップＳ３０６では、Ｔ、Ｃ_ｉ、Ｅ_ｉからカレントバッチジョブのバッチジョブ特性のデータを作成し、リポジトリ１０４に追加する。バッチジョブ特性のデータ種別に応じて、Ｔ、Ｃ_ｉ、Ｅ_ｉの値をそのままバッチジョブ特性のデータ値として用いてもよく、何らかの加工をしてから用いてもよい。

ステップＳ３０７では、Ｔ、Ｃ_ｉ、Ｅ_ｉにもとづいて、カレントバッチジョブのバッチジョブ特性を更新する。例えば、過去の平均をバッチジョブ特性として記録する実施態様では、現在記録されているバッチジョブ特性の各データ値と、各データ値のデータ種別に対応するＴ、Ｃ_ｉ、Ｅ_ｉのいずれかの値とを加重平均した値に更新する。加重平均に用いる重みは、例えば、バッチジョブ特性のデータとして記録された今までの処理件数の総数と、今回のカレントバッチジョブの実行における処理件数にもとづいて定めることができる。また、別の実施態様では、最新の実行時におけるＴ、Ｃ_ｉ、Ｅ_ｉの値そのものをバッチジョブ特性として記録してもよい。さらに別の実施態様では、カレントバッチジョブの直近のｎ回（ｎは予め決められた定数）の実行におけるＴ、Ｃ_ｉ、Ｅ_ｉの値をバッチジョブ特性として記録してもよく、さらにそれらｎ回のデータの平均値などをあわせて記録してもよい。いずれの実施態様の場合も、ステップＳ３０７では、Ｔ、Ｃ_ｉ、Ｅ_ｉにもとづいた更新が行われることは共通している。

ステップＳ３０６またはステップＳ３０７の処理が終わると、バッチジョブ特性の更新処理が終了する。
本発明によれば、バッチジョブ特性が以上のように自動的に記録され、更新されるため、従来は難しかったバッチジョブ特性の正確な把握が容易になる。また、バッチジョブを実行するたびに更新されるので、バッチジョブ特性がバッチジョブの運用方針の変更などの理由で変化した場合でも、変化に合わせてバッチジョブ特性が自動的に更新される。

図１２は、サーバ負荷情報（図７）をリポジトリ１０４に記録する処理を詳細に示したフローチャートである。図１２の処理は、各実行サーバ１０３−１、１０３−２、……、１０３−Ｎの性能情報収集サブシステム１１１とサーバ情報採取サブシステム１１２により一定の間隔で実行される。一定の間隔とは、バッチシステム１０１のシステム管理者などの人間が手動で設定した間隔や、バッチシステム１０１のデフォルト値として予め定められた間隔である。図７の例ではこの間隔は１０分である。

以下では便宜上、実行サーバ１０３−ａ内で時刻ｔに行われる処理の例を説明する（１≦ａ≦Ｎ）。
ステップＳ４０１では、実行サーバ１０３−ａのサーバ情報採取サブシステム１１２が実行サーバ１０３−ａの性能情報収集サブシステム１１１に実行サーバ１０３−ａの負荷情報の採取を依頼する。そしてステップＳ４０２に移行する。なお、ステップＳ４０１は図４の（１３）に相当する。

ステップＳ４０２では、実行サーバ１０３−ａの現在の負荷情報を性能情報収集サブシステム１１１が採取し、サーバ情報採取サブシステム１１２に結果を返す。ここで採取されるのは、図７のサーバ負荷情報の各データ種別に対応するデータ値である。そしてステップＳ４０３に移行する。なお、ステップＳ４０２は図４の（１４）に相当する。

ステップＳ４０３では、サーバ情報採取サブシステム１１２がステップＳ４０２で受け取ったデータをもとに、リポジトリ１０４のサーバ負荷情報を更新する。図７の例のように１日周期の場合、更新するのは、実行サーバ１０３−ａのサーバ識別名のブロックのうち、「最新状態」のブロックと、時刻ｔのブロックである。まず、「最新状態」のブロックの各データ種別に対応するデータ値を、ステップＳ４０２で受け取ったデータの値に書き換える。次に時刻ｔのブロックを更新するが、その更新方法は実施の態様によって異なる。ある実施態様では、時刻ｔのブロックの各データ種別に対応するデータ値を、ステップＳ４０２で受け取ったデータの値に書き換える。つまり、常に最新の実測値をサーバ負荷情報として記録しておく。別の実施態様では、時刻ｔのブロックに現在記録されているデータと、ステップＳ４０２で受け取ったデータの双方にもとづいて、所定の方法（例えば所定の重み付けによる加重平均）により算出した値を、時刻ｔのブロックの各データ種別に対応するデータ値として記録する。

ステップＳ４０３の処理が終わると、サーバ負荷情報を更新する処理が終わる。
なお、サーバ負荷情報を蓄積する周期によって、ステップＳ４０３において更新すべきブロックが異なることは、図７に関する説明などから明らかであろう。

また、上記と別の実施態様においては、ステップＳ４０２で一旦、サーバ負荷情報を運用データ（図５）としてリポジトリ１０４に記録し、ステップＳ４０３でその運用データからサーバ負荷情報の形式に変換してサーバ負荷情報を更新してもよい。その場合、バッチジョブ特性とサーバ負荷情報がともに運用データにもとづいて作成される。

本発明によるバッチジョブシステム１０１を構成する受付サーバ１０２および実行サーバ１０３−１、１０３−２、……、１０３−Ｎは、それぞれ、図１３に示すような一般的な情報処理装置（コンピュータ）として実現される。また、このような情報処理装置によって、ジョブ分散サブシステム１０６などの機能を実現する本発明のプログラムが実行され、本発明が実施される。

図１３の情報処理装置は、中央処理装置（ＣＰＵ）２００、ＲＯＭ（Read Only Memory）２０１、ＲＡＭ（Random Access Memory）２０２、通信インターフェイス２０３、記憶装置２０４、入出力装置２０５、可搬型記憶媒体の駆動装置２０６を備え、これらの全てがバス２０７によって接続されている。

また、受付サーバ１０２と各実行サーバ１０３−１、１０３−２、……、１０３−Ｎとは、それぞれの通信インターフェイス２０３とネットワーク２０９を介して通信可能である。例えば、図９のステップＳ１０６やステップＳ１０９などは、そのようなサーバ間の通信により実現される。ネットワーク２０９は例えばＬＡＮ（Local Area Network）であり、１つのＬＡＮにバッチシステム１０１を構成する各サーバがそれぞれ通信インターフェイス２０３を介して接続されていてもよい。

記憶装置２０４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができる。
リポジトリ１０４は、受付サーバ１０２または実行サーバ群１０３のうちのいずれかのサーバ内の記憶装置２０４に配置されてもよい。この場合、リポジトリ１０４が配置されているサーバはバス２０７を通じて、それ以外のサーバは通信インターフェイス２０３とネットワーク２０９を通じて、図９から図１２に示したような処理の際にリポジトリ１０４内のデータの参照・更新等を行う。あるいは、リポジトリ１０４はいずれのサーバとも独立の記憶装置（記憶装置２０４と同様の装置）に配置されてもよい。この場合、図９から図１２に示したような処理の際、各サーバは通信インターフェイス２０３とネットワーク２０９を通じてリポジトリ１０４内のデータの参照・更新等を行う。

記憶装置２０４またはＲＯＭ２０１には、本発明によるプログラムなどが格納されている。そのプログラムがＣＰＵ２００によって実行されることにより、本発明によるバッチジョブの分散が実行される。プログラムの実行時には、リポジトリ１０４が配置されている記憶装置から必要に応じてデータが読み出され、ＣＰＵ２００内のレジスタやＲＡＭ２０２に記憶され、ＣＰＵ２００での処理に利用される。また、リポジトリ１０４のデータが適宜更新される。

本発明によるプログラムは、プログラム提供者２０８からネットワーク２０９、および通信インターフェイス２０３を介して、例えば記憶装置２０４に格納され、ＣＰＵ２００によって実行されてもよい。また、市販されて流通している可搬型記憶媒体２１０に本発明によるプログラムが格納され、可搬型記憶媒体２１０が駆動装置２０６にセットされ、格納されたプログラムが例えばＲＡＭ２０２にロードされてＣＰＵ２００によって実行されてもよい。可搬型記憶媒体２１０としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができる。

（付記１）
バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択するバッチジョブ受付コンピュータで使用されるプログラムであって、
前記バッチジョブの特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測する実行時間予測ステップと、
前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を予測する負荷状況予測ステップと、
前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する選択ステップと、
を前記バッチジョブ受付コンピュータに実行させることを特徴とするプログラム。
（付記２）
前記選択ステップにおいて選択されたコンピュータで前記バッチジョブが実行されたとき生じた負荷に関する情報にもとづいて、前記バッチジョブの前記特性を更新するバッチジョブ特性更新ステップをさらに有することを特徴とする付記１に記載のプログラム。
（付記３）
前記バッチジョブの前記特性は、予め記憶されているか前記バッチジョブ特性更新ステップで更新されて記憶されたものであり、
前記実行時間予測ステップにおいて、記憶された前記バッチジョブの前記特性を読み出して使用する
ことを特徴とする付記２に記載のプログラム。
（付記４）
前記負荷状況予測ステップにおいて、前記時間範囲に含まれる所定の間隔の複数の時刻のそれぞれにおける負荷状況を予測し、該予測した複数の時刻における負荷状況にもとづいて前記時間範囲における前記負荷状況を予測することを特徴とする付記１に記載のプログラム。
（付記５）
前記負荷状況予測ステップにおいて、
時刻と対応づけて記憶された、前記複数のコンピュータそれぞれの過去における負荷状況を表す負荷情報の中から、前記複数の時刻のそれぞれに対応する前記負荷情報を読み出し、
読み出した前記負荷情報にもとづいて前記複数の時刻のそれぞれにおける負荷状況を予測する
ことを特徴とする付記４に記載のプログラム。
（付記６）
前記負荷状況予測ステップにおいて、前記負荷状況を表す負荷情報は数値表現であり、前記複数の時刻に対して予測された前記負荷状況に対応する前記負荷情報の平均にもとづいて、前記時間範囲における前記負荷状況を予測することを特徴とする付記４に記載のプログラム。
（付記７）
前記負荷状況予測ステップにおいて、さらに、前記複数のコンピュータの負荷状況の実測値のうち前記負荷状況予測ステップの実行時点の直近の実測値にもとづいて予測することを特徴とする付記１に記載のプログラム。
（付記８）
前記選択ステップにおいて、予め記憶手段に記憶された規則を読み出し、前記複数のコンピュータのそれぞれに対して予測された前記負荷状況を表す負荷情報を前記規則に適用し、前記規則にしたがって前記負荷情報それぞれの値および前記負荷情報同士の相対関係にもとづいて前記複数のコンピュータのうちの一つを選択することを特徴とする付記１に記載のプログラム。
（付記９）
前記負荷情報は、前記複数のコンピュータの、ＣＰＵの使用率、ＣＰＵの使用量、メモリの使用率、メモリの使用量、物理入出力の平均待ち時間、ファイルの使用量、記憶装置の空き容量のうち少なくとも１種類の情報を含み、
前記規則は、予め優先順序が定められた１つ以上の分散条件からなり、
前記分散条件のそれぞれは、前記負荷情報を適用したとき、前記負荷情報に含まれる所定の種類の情報の値にもとづく前記複数のコンピュータの順序にもとづき、該分散条件に該当するコンピュータが存在すれば該コンピュータを指定するよう、設定されており、
前記選択ステップにおいて、前記優先順序にしたがって前記分散条件に前記負荷情報を適用し、最初に指定されたコンピュータを選択する
ことを特徴とする付記８に記載のプログラム。
（付記１０）
前記バッチジョブの前記特性にもとづいて、前記バッチジョブの実行により生じるバッチジョブ負荷を予測するバッチジョブ負荷予測ステップをさらに有し、
前記選択ステップにおいて、さらに前記バッチジョブ負荷にもとづいて選択することを特徴とする付記１に記載のプログラム。
（付記１１）
バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択する装置であって、
前記バッチジョブの特性を記憶するとともに、前記複数のコンピュータそれぞれの過去における負荷状況を表す負荷情報を時刻と対応づけて記憶する記憶手段と、
前記記憶手段から前記バッチジョブの前記特性を読み出し、読み出した前記バッチジョブの前記特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測する実行時間予測手段と、
前記記憶手段から前記負荷情報を読み出し、前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を、読み出した前記負荷情報にもとづいて予測する負荷状況予測手段と、
前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する選択手段と、
を備えることを特徴とする装置。
（付記１２）
バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択するバッチジョブ受付コンピュータで使用される方法であって、
前記バッチジョブの特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測し、
前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を予測し、
前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する
ことを特徴とする方法。
（付記１３）
バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択するバッチジョブ受付コンピュータで使用されるコンピュータ読み取り可能記憶媒体であって、
前記バッチジョブの特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測する実行時間予測ステップと、
前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を予測する負荷状況予測ステップと、
前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する選択ステップと、
を前記バッチジョブ受付コンピュータに実行させるプログラムを格納していることを特徴とするコンピュータ読み取り可能記憶媒体。

本発明の原理を示す図である。 １つのバッチジョブを実行することによる負荷の一例を示すグラフである。 バッチジョブを実行するサーバの負荷の一例を示すグラフである。 本発明によってバッチジョブの実行サーバを選択しバッチジョブを分散実行させるシステムの一実施形態における機能ブロック図である。 運用データの格納例である。 バッチジョブ特性の格納例である。 サーバ負荷情報の格納例である。 分散条件の例である。 バッチシステムで実行される処理のフローチャートである。 バッチジョブの実行サーバを決定する処理のフローチャートである。 バッチジョブ特性を更新する処理のフローチャートである。 サーバ負荷情報を記録する処理のフローチャートである。 本発明のプログラムを実行するコンピュータのブロック図である。

符号の説明

１０１ バッチシステム
１０２ 受付サーバ
１０３ 実行サーバ群
１０３−１、１０３−２、……、１０３−Ｎ 実行サーバ
１０４ リポジトリ
１０５ ジョブ受付サブシステム
１０６ ジョブ分散サブシステム
１０７ 運用データ採取サブシステム
１０８ ジョブ情報更新サブシステム
１０９ ジョブ実行サブシステム
１１０ 運用データ採取サブシステム
１１１ 性能情報収集サブシステム
１１２ サーバ情報採取サブシステム
２００ ＣＰＵ
２０１ ＲＯＭ
２０２ ＲＡＭ
２０３ 通信インターフェイス
２０４ 記憶装置
２０５ 入出力装置
２０６ 駆動装置
２０７ バス
２０８ プログラム提供者
２０９ ネットワーク
２１０ 可搬型記憶媒体

Claims (5)

1. バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択するバッチジョブ受付コンピュータで使用されるプログラムであって、
   前記バッチジョブの特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測する実行時間予測ステップと、
   前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を予測する負荷状況予測ステップと、
   前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する選択ステップと、
   を前記バッチジョブ受付コンピュータに実行させることを特徴とするプログラム。
2. 前記選択ステップにおいて選択されたコンピュータで前記バッチジョブが実行されたとき生じた負荷に関する情報にもとづいて、前記バッチジョブの前記特性を更新するバッチジョブ特性更新ステップをさらに有することを特徴とする請求項１に記載のプログラム。
3. 前記負荷状況予測ステップにおいて、前記時間範囲に含まれる所定の間隔の複数の時刻のそれぞれにおける負荷状況を予測し、該予測した複数の時刻における負荷状況にもとづいて前記時間範囲における前記負荷状況を予測することを特徴とする請求項１に記載のプログラム。
4. 前記バッチジョブの前記特性にもとづいて、前記バッチジョブの実行により生じるバッチジョブ負荷を予測するバッチジョブ負荷予測ステップをさらに有し、
   前記選択ステップにおいて、さらに前記バッチジョブ負荷にもとづいて選択することを特徴とする請求項１に記載のプログラム。
5. バッチジョブを実行させるコンピュータを複数のコンピュータの中から選択する装置であって、
   前記バッチジョブの特性を記憶するとともに、前記複数のコンピュータそれぞれの過去における負荷状況を表す負荷情報を時刻と対応づけて記憶する記憶手段と、
   前記記憶手段から前記バッチジョブの前記特性を読み出し、読み出した前記バッチジョブの前記特性および前記バッチジョブに与える入力データの量にもとづいて、前記バッチジョブの実行にかかる実行時間を予測する実行時間予測手段と、
   前記記憶手段から前記負荷情報を読み出し、前記バッチジョブの実行開始予定時刻を始点とし前記予測した実行時間の長さを有する時間範囲における、前記複数のコンピュータのそれぞれの負荷状況を、読み出した前記負荷情報にもとづいて予測する負荷状況予測手段と、
   前記予測した負荷状況にもとづいて、前記バッチジョブを実行させるコンピュータを前記複数のコンピュータの中から選択する選択手段と、
   を備えることを特徴とする装置。

Images