JPWO2013171879A1 - ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法 - Google Patents

Abstract

コンピュータリソースを用いて演算ジョブを実行するために承認が必要となる場合において、承認処理の負担を軽減する。本発明に係るジョブ実行システムは、複数の演算ジョブをグループ化してグループ単位で承認を依頼し、グループに対する承認を得た場合はそのグループに含まれる全演算ジョブが承認されたものとして取り扱う（図７参照）。

Description

本発明は、コンピュータリソースを用いて演算ジョブを実行する技術に関する。

データ量の増加に伴い、グリッド・コンピューティングのような分散処理が注目を集めている。分散処理の１つの適用例として総売上高の算出がある。ここでは、取引データとして登録された各取引の金額をすべて加算して総売上高を求めるものとする。取引数が少ない場合は１台のコンピュータでも短時間で処理を終えることができるが、取引数が多い場合は総売上高の算出に長時間かかってしまうため、複数台のコンピュータに取引のデータを分割して配布し、各コンピュータ上で計算を分散実行することにより、短時間で計算結果を得ることができる。

下記特許文献１には、分散コンピューティング技術に関する技術が記載されている。同文献では、『分散コンピュータネットワークにおいてリソースに対するセキュリティを確保したアクセスを提供する。』ことを課題として、『ジョブチケット（６１）を格納することができ、該ジョブチケットがジョブに対する参照を提供し、該ジョブが１つまたは複数のリソースを含み、プロセッサ（８０）が該ジョブを実行するために前記ジョブチケットにアクセスするものである、ジョブチケットサービス（６０）と、該ジョブチケットへのアクセスを試みているプロセッサの識別を検証することができる認証機構（９４）と、該認証機構から前記識別を受取ることができ前記プロセッサに対し前記ジョブチケットにアクセスする権限を提供することができ、前記プロセッサが、前記ジョブチケットにアクセスする時に前記１つまたは複数のリソースにアクセスする、権限付与機構（９２）とを具備する。』という技術が開示されている（要約参照）。

下記特許文献２では、ネットワーク上に配置されたデータファイルに対するアクセスを制御する技術が記載されている。同文献では、『ネットワークに接続された端末におけるファイル操作を検出した際に、その操作の承認の可否を決定することにより、操作を制御する技術を提供する。』ことを課題として、『サーバＳの操作情報取得部２１は、端末Ｃから操作情報を取得する。承認依頼部２２は、取得した操作情報に基づき、承認者を特定し、承認者情報を取得すると共に、特定した承認者に承認依頼を送信する。承認結果受信部２３は、各承認者からの承認結果を受信し、集計部２４に渡す。集計部２４は、承認者情報および承認結果を取得し、所定条件を満たすと集計結果を生成する。承認可否判定部２５は、集計部２４から集計結果を取得し、操作情報と集計結果に基づき、承認の可否を判定する。制御部２６は、承認可否判定部２５による判定結果に基づき、所定の制御を実行する。』という技術が開示されている（要約参照）。

特開２００３−１２２５４０号公報 特開２００９−２３０２５７号公報

アクセスするために承認を要するコンピュータリソースを用いて演算ジョブを実行する場合には、演算ジョブを開始する前にそのコンピュータリソースを使用することについて承認を得なければならない。分散コンピューティング環境においては、コンピュータリソースと演算ジョブがともに分散しているため、個々のコンピュータリソースと演算ジョブについて個別に承認を実施する必要があると考えられる。これは特に、承認者が手作業によって承認を実施する場合において、承認者にとって過剰な負担になる。

上記特許文献１に記載されている技術では、ジョブチケットにアクセスするプロセッサを認証し、認証されたプロセッサへアクセス権限を付与する。この技術では、各プロセッサを個別に認証する必要があると考えられる。また同文献では、認証処理を通過したプロセッサについてはジョブチケットへアクセスする権限を自動的に付与しているので、承認者が個々のジョブチケットについて承認作業を個別に実施することは想定されていないと考えられる。

上記特許文献２に記載されている技術では、ファイルに対するアクセスを承認者が承認しているが、分散コンピューティング環境については考慮されていない。また、同文献に記載されている技術をそのまま分散コンピューティング環境に導入すると、個々の演算ジョブやコンピュータリソースについて個別に承認を実施しなければならないので、承認者にとっての負担が大きくなると考えられる。

本発明は、上記のような課題に鑑みてなされたものであり、コンピュータリソースを用いて演算ジョブを実行するために承認が必要となる場合において、承認処理の負担を軽減することを目的とする。

本発明に係るジョブ実行システムは、複数の演算ジョブをグループ化してグループ単位で承認を依頼し、グループに対する承認を得た場合はそのグループに含まれる全演算ジョブが承認されたものとして取り扱う。

本発明に係るジョブ実行システムによれば、個々の演算ジョブについて個別に承認を実施する必要がなくなるので、承認処理の負担を軽減することができる。

上記した以外の課題、構成、および効果は、以下の実施形態の説明により明らかになるであろう。

実施形態１に係るジョブ実行システム１０００の構成図である。 承認依頼ＤＢ２４０の構成とデータ例を示す図である。 承認結果ＤＢ２５０の構成とデータ例を示す図である。 リソース情報ＤＢ４１０の構成とデータ例を示す図である。 分割情報ＤＢ４２０の構成とデータ例を示す図である。 承認者端末３００が表示する承認依頼一覧画面３１０の画面イメージである。 グループ管理部１４０が作成するジョブグループとジョブグループ全体に対する承認について説明する図である。 演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを同じグループに所属させる例を示す図である。 演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを異なるグループに所属させる例を示す図である。 分割前後に係る演算ジョブを同じグループに所属させる例を示す図である。 アプリケーションジョブとこれから生成した演算ジョブを同じグループに所属させる例を示す図である。 グループ管理部１４０が図８〜図１０に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。 グループ管理部１４０が図１１に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。 ステップＳ１２０５の詳細を示す図である。 承認者が承認者端末３００を用いて承認依頼に対する回答を入力する処理を説明する図である。 ステップＳ１２１６の詳細を示す図である。

＜実施の形態１：システム構成＞
図１は、本発明の実施形態１に係るジョブ実行システム１０００の構成図である。ジョブ実行システム１０００は、コンピュータリソースを用いて演算ジョブを実行するシステムであり、計算機ノード１００、承認サーバ２００、承認者端末３００、リソース情報データベース（ＤＢ）４１０、分割情報データベース（ＤＢ）４２０を備える。これらはネットワークを介して互いに接続されている。

計算機ノード１００は、演算ジョブを実行するコンピュータであり、複数台設けられている。ユーザは、上位アプリケーションのジョブ（例えば経理アプリケーションの売上集計ジョブ）を計算機ノード１００に投入する。アプリケーションジョブが投入された計算機ノード１００は、そのアプリケーションジョブを複数の演算ジョブ（例えば店舗毎の集計ジョブ）に分割し、他の計算機ノード１００へ配布する。各計算機ノード１００は、受け取った演算ジョブを実行する。これにより、複数の計算機ノード１００がアプリケーションジョブを分担して実行することになる。

計算機ノード１００は、ジョブ受付部１１０、リソース操作検知部１２０、承認制御部１３０、グループ管理部１４０、ジョブ制御部１５０、リソース分割部１６０を備える。

ジョブ受付部１１０は、ユーザが投入したアプリケーションジョブ、または他の計算機ノード１００が配布した演算ジョブを受け取り、そのジョブがいずれのグループに属するかを判定する。ジョブが属するグループについては後述する。ジョブ受付部１１０が受け取ったジョブは、ジョブ制御部１５０によって実行される。

リソース操作検知部１２０は、ジョブ制御部１５０が実行するジョブがコンピュータリソースにアクセスする必要がある場合、その旨を検知する。ここでいうコンピュータリソースは、例えば演算ジョブを実行する際に用いるデータファイルまたはデータベースのテーブル、他の計算機ノード１００、などが考えられる。以下では説明の便宜上、コンピュータリソースとして、演算ジョブを実行する際に用いるデータファイルを例に動作を説明する。例えば経理アプリケーションの例においては、演算ジョブがアクセスするデータファイルとして、全店舗の売上実績を記録したデータファイルが考えられる。

承認制御部１３０は、リソース操作検知部１２０がコンピュータリソースへのアクセスを検知した場合、そのコンピュータリソースにアクセスするために承認を要するか否かを判定する。判定手法については後述する。承認を要する場合、承認制御部１３０は承認依頼を承認サーバ２００へ発行する。承認者がその承認依頼に対して回答（承認結果）を入力した後、承認制御部１３０はその承認結果を承認サーバ２００から受け取ってジョブ制御部１５０に通知する。承認依頼が生じてから承認者が回答を入力するまではタイムラグがあるので、承認制御部１３０は承認依頼に対する回答を即時に得られるとは限らない。ただし後述するように、同じグループに属する演算ジョブに対して既に承認者が回答を入力していた場合は、即座に回答を得ることができる。

グループ管理部１４０は、複数の演算ジョブをグループ化し、同一のグループＩＤを付与する。同じグループに属する演算ジョブを複数の計算機ノード１００に配布する場合、各計算機ノード１００が受け取る演算ジョブは、そのグループのグループＩＤを、配布前の演算ジョブから引き継ぐ。グループＩＤを複数の演算ジョブ間で共有する手法については後述する。

ジョブ制御部１５０は、ジョブ受付部１１０が受け取ったアプリケーションジョブに基づき個々の演算ジョブを生成して実行し、または他の計算機ノード１００へ演算ジョブを配布して実行させその結果を受け取る。ジョブ制御部１５０は、他の計算機ノード１００から演算ジョブを受け取る場合もある。この場合はその演算ジョブを実行する。ジョブ制御部１５０が個々の演算ジョブを生成する手法については後述する。

ジョブ制御部１５０はさらに、ジョブ複製部１５１を備える。ジョブ複製部１５１は、演算ジョブを複製することにより分割する機能部である。複製された演算ジョブは複製元の演算ジョブと同じ処理を実行するが、処理対象となるデータファイルなどが異なる。

リソース分割部１６０は、ジョブ制御部１５０が他の計算機ノード１００へ演算ジョブを配布する場合において、他の計算機ノード１００が演算ジョブを実行するためアクセスするコンピュータリソースを他の計算機ノード１００へ配布する。例えば演算ジョブを実行するためデータファイルにアクセスする必要がある場合、リソース分割部１６０はそのデータファイルのうち他の計算機ノード１００がアクセスする必要がある部分を分割して他の計算機ノード１００へ配布する。

承認サーバ２００は、計算機ノード１００が備える承認制御部１３０より承認依頼を受け取って承認結果を回答するコンピュータである。承認サーバ２００は、コンピュータリソースに対するアクセスを、グループ管理部１４０が作成したグループ単位で承認する。承認サーバ２００は、依頼受付部２１０、承認部２２０、優先度判定部２３０、承認依頼データベース（ＤＢ）２４０、承認結果データベース（ＤＢ）２５０を備える。

依頼受付部２１０は、承認制御部１３０が発行した承認依頼を受け取り、その承認依頼に対する回答（承認結果）が入力されているか否か、承認結果ＤＢ２５０から検索する。承認結果が見つからない場合、依頼受付部２１０はその承認依頼を承認依頼ＤＢ２４０へ登録する。承認結果が見つかった場合、依頼受付部２１０はその承認結果を承認制御部１３０へ返信する。

承認部２２０は、承認者端末３００からのリクエストに応じて承認依頼ＤＢ２４０に登録されている承認依頼のリストを承認者端末３００へ送信する。また、承認者端末３００から承認依頼に対する承認結果を受け取り、承認依頼ＤＢ２４０へ登録する。承認部２２０は、承認依頼ＤＢ２４０に登録されている回答を集計し、グループに対する最終的な承認結果を決定して承認結果ＤＢ２５０に格納する。最終的な承認結果については後述の図２で改めて説明する。承認されたグループに属する全ての演算ジョブは、ジョブの過程で使用するコンピュータリソースにアクセスすることを許可される。

優先度判定部２３０は、承認依頼ＤＢ２４０に登録されている承認依頼の優先度を判定する。この優先度は、どの順序で承認依頼を処理すべきかを定めるための指標となる。承認者はこの優先度を参考にして、承認処理を実施することができる。優先度の高低は、例えば複数の承認者から承認を得なければならない場合において、承認を要する承認者の人数が多い承認依頼ほど優先度を高くする、などの手法が考えられる。

承認依頼ＤＢ２４０、承認結果ＤＢ２５０、リソース情報ＤＢ４１０、分割情報ＤＢ４２０については、後述の図２〜図５で説明する。

承認者端末３００は、承認者が承認依頼に対する回答を入力するための端末である。承認者端末３００は、未回答の承認依頼があるか否かを承認サーバ２００へ問い合わせる。承認者端末３００は、後述の図６で説明する画面上に未回答の承認依頼のリストを表示する。承認者はその画面上で回答を入力する。承認サーバ２００はその回答を受け取って承認依頼ＤＢ２４０に格納する。

図１に示す各コンピュータが備える各機能部は、これらの機能を実現する回路デバイスなどのハードウェアとして構成することもできるし、同様の機能を実装したプログラムとこれを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置を用いて構成することもできる。

図２は、承認依頼ＤＢ２４０の構成とデータ例を示す図である。承認依頼ＤＢ２４０は未回答の承認依頼を保持するデータベースであり、データを保持するデータファイルをＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶装置に格納することによって構成することができる。図２ではテーブル形式の構成を例示したが、その他の形式でもよい。データベースを構成する手法およびデータ形式については他のデータベースについても同様であるため、以降に説明するデータベースについてはその記載を省略する。

承認依頼ＤＢ２４０は、グループＩＤフィールド２４１、代表ジョブＩＤフィールド２４２、リソースＩＤフィールド２４３、依頼元フィールド２４４、承認者ＩＤフィールド２４５、回答フィールド２４６、分割前リソースＩＤフィールド２４７、作業者ＩＤフィールド２４８、アプリケーションジョブＩＤフィールド２４９を有する。承認依頼ＤＢ２４０の各レコードが１つの承認依頼に相当する。承認者端末３００は承認依頼ＤＢ２４０に格納されているレコードを取得し、後述の図６で説明する画面上に取得したレコードを表示する。

グループＩＤフィールド２４１は、グループ管理部１４０が作成したグループのＩＤを保持する。代表ジョブＩＤフィールド２４２は、グループＩＤフィールド２４１が指定するグループを代表する演算ジョブのＩＤを保持する。リソースＩＤフィールド２４３は、グループＩＤフィールド２４１が指定するグループに含まれる演算ジョブを実行するためにアクセスする必要があるコンピュータリソースのうちアクセスする際に承認を要するもののＩＤを保持する。依頼元フィールド２４４は、承認依頼を発行した計算機ノード１００を識別する情報を保持する。ここではＩＰアドレスとポート番号を例示した。承認者ＩＤフィールド２４５は、承認依頼に対して回答すべき承認者のＩＤを保持する。

回答フィールド２４６は、承認者が承認者端末３００上で入力した回答を保持する。承認結果ＤＢ２５０とは別に本フィールドを設けているのは、承認者が複数いる場合を想定しているためである。

そこで本実施形態１では、承認者端末３００から入力された承認結果をいったん承認依頼ＤＢ２４０上に格納し、グループに属する演算ジョブに対する承認結果がある程度（必ずしも全部でなくともよい）集まった段階で、承認部２２０がそのグループに対する最終的な承認結果を判定することとした。例えば、同じグループに属する演算ジョブに対する承認結果の多数決によって、そのグループに対する最終的な承認結果を判定することができる。その他適当な手法を用いて判定してもよい。承認部２２０は、グループに対する最終的な承認結果を承認結果ＤＢ２５０に格納する。

分割前リソースＩＤフィールド２４７は、リソースＩＤフィールド２４３が指定するコンピュータリソースがリソース分割部１６０によって作成されたものである場合、その分割前のリソースのＩＤを保持する。本フィールドは後述する分割情報ＤＢ４２０から取得することもできるので、必ずしも承認依頼ＤＢ２４０内に設けなくともよい。

作業者ＩＤフィールド２４８は、各グループに含まれる演算ジョブを生成する元になったアプリケーションジョブを投入したユーザのＩＤである。アプリケーションジョブＩＤフィールド２４９は、そのアプリケーションジョブのＩＤである。

承認部２２０は、承認者端末３００から承認依頼のリストを送付するよう要求するリクエストを受け取ると、その承認者のＩＤをキーにして承認依頼ＤＢ２４０を検索してその承認者が回答を入力すべき承認依頼のリストを取得する。承認部２２０は、以下の処理により承認者端末３００へ返信すべき承認依頼リストを作成する。これにより、同じ内容の承認依頼に対して何度も回答を要求することを避けることができる。

（承認依頼リスト作成処理その１）
既に回答フィールド２４６へ回答が入力されている承認依頼については改めて承認者端末３００上で提示する必要はない。そこで承認部２２０は、承認者端末３００へ返信する承認依頼リストから回答済のものを除外する。

（承認依頼リスト作成処理その２）
既に回答フィールド２４６へ回答が入力されている承認依頼と同じグループに属し、かつ承認対象リソース（分割されていなければリソースＩＤフィールド２４３、分割されていれば分割前リソースＩＤ２４７）も同じである承認依頼については、承認者が同じ承認結果を入力するはずである。そこで承認部２２０は、承認者端末３００へ返信する承認依頼リストから上記に該当するものを除外する。

（承認依頼リスト作成処理その３）
未回答の承認依頼のうち、同じグループに属し、かつリソースＩＤフィールド２４３も同じである承認依頼が複数存在する場合は、そのなかのいずれか１つを残してその他の承認依頼は承認依頼ＤＢ２４０から削除する。承認者はこれらの承認依頼に対して同じ回答を入力するであろうし、後述するようにグループ全体に対して承認結果が得られればそのグループに属する全ての演算ジョブに対して同じ承認結果が適用されるので同じグループに属するいずれかの承認依頼に対して回答が得られれば十分だからである。

図３は、承認結果ＤＢ２５０の構成とデータ例を示す図である。承認結果ＤＢ２５０は演算ジョブのグループに対する最終的な承認結果を保持するデータベースであり、グループＩＤフィールド２５１、リソースＩＤフィールド２５２、承認結果２５３を有する。

グループＩＤフィールド２５１は、承認部２２０が最終的に承認結果を決定したグループのＩＤを保持する。本フィールドはグループＩＤフィールド２４１に対応する。リソースＩＤフィールド２５２は、グループＩＤフィールド２５１が指定するグループに含まれる演算ジョブがアクセスするコンピュータリソースのＩＤを保持する。本フィールドは分割されていなければリソースＩＤフィールド２４３、分割されていれば分割前リソースＩＤ２４７に対応する。承認結果２５３は、グループＩＤフィールド２５１が指定するグループに対する最終的な承認結果を保持する。

図４は、リソース情報ＤＢ４１０の構成とデータ例を示す図である。リソース情報ＤＢ４１０は、アクセスする際に承認を要するコンピュータリソースを列挙するとともに、その承認者を特定するためのデータベースである。リソース情報ＤＢ４１０は、リソースＩＤフィールド４１１、承認者ＩＤフィールド４１２を有する。

リソースＩＤフィールド４１１は、アクセスする際に承認を要するコンピュータリソースのＩＤを保持する。承認者ＩＤフィールド４１２は、リソースＩＤフィールド４１１が指定するコンピュータリソースに対するアクセスを承認する承認者のＩＤを保持する。

計算機ノード１００の承認制御部１３０は、承認サーバ２００に対して承認依頼を発行する。承認部２２０は、その承認依頼に対して回答すべき承認者を指定する。

図５は、分割情報ＤＢ４２０の構成とデータ例を示す図である。分割情報ＤＢ４２０は、リソース分割部１６０がコンピュータリソースを分割した場合、その分割前後の対応関係を管理するためのデータベースである。分割情報ＤＢ４２０は、グループＩＤフィールド４２１、分割後リソースＩＤフィールド４２２、分割前リソースＩＤフィールド４２３を有する。

グループＩＤフィールド４２１は、コンピュータリソースを使用する演算ジョブが属するグループのＩＤである。分割後リソースＩＤフィールド４２２は、グループＩＤフィールドが指定するグループに属する演算ジョブが使用するコンピュータリソースのうち、リソース分割部１６０が生成したもののＩＤである。分割前リソースＩＤフィールド４２３は、分割後リソースＩＤ４２２が指定するコンピュータリソースをリソース分割部１６０が生成する元になったコンピュータリソースのＩＤである。

リソース分割部１６０は、コンピュータリソースを分割して他の計算機ノード１００へ配布するとき、分割前後の対応関係を分割情報ＤＢ４２０へ登録する。承認依頼ＤＢ２４０の分割前リソースＩＤフィールド２４７は、分割情報ＤＢ４２０に登録されている情報から導き出すことができる。

演算ジョブが分割後のコンピュータリソースを使用する場合においては、承認者は分割後のコンピュータリソースに対するアクセス可否を判断する必要がある。しかし、分割後のコンピュータリソースＩＤは必ずしも分割前のコンピュータリソースＩＤと同様であるとは限らず、コンピュータリソースＩＤのみではアクセス可否を判断することができない場合がある。このような場合には、分割情報ＤＢ４２０から分割前後それぞれのコンピュータリソースＩＤの対応関係を読み出し、分割前のコンピュータリソースＩＤに置き換えて承認者へ提示すればよい。分割前後のコンピュータリソースそれぞれに求められるセキュリティレベルは同程度であると考えられるので、分割前のコンピュータリソースに対するアクセス可否を判断することができれば、承認作業を実施するのに十分だからである。

図６は、承認者端末３００が表示する承認依頼一覧画面３１０の画面イメージである。承認依頼一覧画面３１０は、承認依頼ＤＢ２４０内に登録されている承認依頼のリストを表示する画面であり、承認依頼テーブル３１１、更新ボタン３１２、承認ボタン３１３、却下ボタン３１４を有する。

承認者は、承認作業を実施するとき、承認者端末３００のディスプレイ上に承認依頼一覧画面３１０を表示させる。このとき、当該承認者のＩＤを指定しておく。例えば当該承認者のログインＩＤなどを用いればよい。承認者端末３００は、その承認者ＩＤをキーにして承認サーバ２００へ未回答の承認依頼を問い合わせる。

承認部２２０は、承認依頼リスト作成処理その１〜３で説明した手法により承認依頼ＤＢ２４０から当該承認者に関連する承認依頼リストを作成し、承認者端末３００へ送信する。承認者端末３００は、承認依頼テーブル３１１上にその承認依頼リストを画面表示する。必ずしも承認依頼ＤＢ２４０が備える全フィールドを画面表示する必要はなく、承認者が承認作業を実施するために必要な情報のみを表示すればよい。優先度については、優先度判定部２３０が上述の方法によって判定した値を承認者端末３００へ通知し、これを表示すればよい。

承認者は、承認ボタン３１３または却下ボタン３１４を押下することにより、承認依頼に対する回答を入力する。承認依頼リストを承認サーバ２００から再取得する場合は、更新ボタン３１２を押下する。承認サーバ２００は、承認者が入力した回答を承認者端末３００から受け取って承認依頼ＤＢ２４０の回答フィールド２４６に登録する。以後の処理は先に説明した通りである。

＜実施の形態１：ジョブグループについて＞
図７は、グループ管理部１４０が作成するジョブグループとジョブグループ全体に対する承認について説明する図である。ここではユーザがアプリケーションジョブを投入してから各計算機ノードが承認依頼を発行するに至る処理の流れを示した。以下、図７に示す各ステップについて説明する。

（図７：ステップ１：売上集計ジョブ）
ユーザは、上位アプリケーションを介してアプリケーションジョブを計算機ノード１００へ投入する。ここでは経理アプリケーションの全店舗売上集計ジョブを投入したものと仮定する。

（図７：ステップ２：加算ジョブ生成）
ジョブ制御部１５０は、ユーザが投入した売上集計ジョブを、コンピュータが実行する演算ジョブとして置き換える。売上集計ジョブの例に即して述べると、各店舗の売上を加算する演算ジョブなどを生成することになると考えられる。以下では便宜上、同例を用いて説明する。

（図７：ステップ３：リソース分割承認依頼）
演算ジョブの処理負荷が大きい場合、ジョブ制御部１５０はステップ２で生成した演算ジョブを分割して他の計算機ノード１００に割り当てる。グループ管理部１４０は、分割前後の演算ジョブをグループ化して同一のグループＩＤを割り当て、各演算ジョブにパラメータとして引き渡しておく。あるいは、各演算ジョブがいずれのグループに属しているかについて、適当なデータベース上で管理してもよい。このとき、分割後の演算ジョブが使用するコンピュータリソースを併せて配布する必要がある。ここでは売上実績を記録したデータファイルを店舗毎に分割し、その店舗の集計を担当する計算機ノード１００へ配布することとする。データファイルを分割する際に、データファイルに対するアクセスが発生するので、リソース操作検知部１２０はその旨を検知する。承認制御部１３０は、そのアクセスに対する承認依頼を承認サーバ２００へ発行する。承認者は承認者端末３００を用いてその承認依頼に対し回答する。承認部２２０は、当該グループに対する最終的な承認結果を承認結果ＤＢ２５０に登録する。

（図７：ステップ４：分割ジョブを配布）
ジョブ制御部１５０は、分割後の演算ジョブを各計算機ノード１００へ配布する。

（図７：ステップ４：分割リソースを配布）
リソース分割部１６０は、分割後のコンピュータリソースを、対応する計算機ノード１００へ配布する。このとき、対応する演算ジョブが属するグループＩＤと、分割前後のコンピュータリソースＩＤとの間の対応関係を、分割情報ＤＢ４２０へ登録しておく。

（図７：ステップ５：承認依頼）
各計算機ノード１００のジョブ制御部１５０は、受け取った演算ジョブを実行する。この過程において、分割後のコンピュータリソースにアクセスする場合、リソース操作検知部１２０がその旨を検知し、承認制御部１３０はそのコンピュータリソースに対するアクセス可否について承認サーバ２００へ承認依頼を発行する。このとき、分割後の演算ジョブが属するグループＩＤを併せて承認サーバ２００へ通知する。

（図７：ステップ６：承認）
承認部２２０は、承認依頼に係るグループＩＤをキーにして、承認結果ＤＢ２５０を検索する。図７に示す処理フローでは、ステップ３において既に当該グループに対して承認結果が登録されているので、承認部２２０はこれを用いて承認依頼に対し回答する。これにより、承認者が分割後ジョブから発生した承認依頼に対して逐一回答を入力する必要がなくなるので、承認者の負担を軽減することができる。各計算機ノード１００のジョブ制御部１５０は、グループに対してコンピュータリソースへのアクセスを許可する旨の承認結果を得た場合は各演算ジョブを実行し、アクセスを許可しない旨の承認結果を得た場合はジョブの実行を中止する。

＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るジョブ実行システム１０００は、演算ジョブを分割して各計算機ノード１００へ配布する際に、各演算ジョブをグループ化して同じグループＩＤを割り当てておく。各計算機ノード１００は、分割後の演算ジョブを実行する際に承認サーバ２００へ承認依頼を発行する。承認サーバ２００はグループに対する承認結果を回答し、各計算機ノード１００はこれにしたがって演算ジョブを制御する。この構成によれば、承認者はグループに対する承認結果をいったん回答すれば、以後の分割後ジョブから生じる承認依頼に対して逐一回答する必要がなくなるので、承認者の負担を軽減することができる。

＜実施の形態２＞
実施形態１では、グループ管理部１４０が複数の演算ジョブをグループ化することについて説明した。このとき、どの範囲で演算ジョブをグループ化するかにより、承認依頼の発生頻度や承認対象が異なる。本発明の実施形態２では、グループ化する演算ジョブの範囲について種々の構成例を説明する。また、ジョブ実行システム１０００の詳細動作について併せて説明する。その他の構成は実施形態１と同様である。

図８は、演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを同じグループに所属させる例を示す図である。ジョブ複製部１５１はアプリケーションジョブから生成された代表演算ジョブを複製することにより、分割演算ジョブを生成する。さらに分割演算ジョブのなかで、部分的な処理を担当する派生的なジョブが発生する場合もある。

図８に示す例では、代表演算ジョブと分割演算ジョブは異なるグループに属することになるので、代表演算ジョブに対する承認結果は分割演算ジョブに対して適用されない。これは代表演算ジョブに対する承認結果を分割後の演算ジョブに引き継がせたくない場合に有効である。

図８に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブが無所属であれば新たに作成したグループとなり、複製元ジョブがグループに所属していればそのグループとなる。複製以外の方法によって生成したジョブが所属するグループは、生成元のジョブと同じである。

図９は、演算ジョブを複製することにより生成した分割ジョブと、分割ジョブから派生した演算ジョブとを異なるグループに所属させる例を示す図である。分割演算ジョブから派生する派生ジョブの内容を承認者が知らない場合には、分割演算ジョブから生じた承認依頼を承認する場合においても、派生ジョブから生じる承認依頼を必ずしも承認するとは限らない。このような場合には、分割演算ジョブと派生演算ジョブを異なるグループに属させることが望ましい。

図９に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブが作成したグループとなる。複製以外の方法によって生成したジョブは、無所属となる。

図１０は、分割前後に係る演算ジョブを同じグループに所属させる例を示す図である。これは実施形態１で説明したグループ構造に対応する。分割前後の演算ジョブを一括して承認したい場合には、図１０に示すグループ構造が有効である。また、分割前の演算ジョブに対する承認結果を分割後の演算ジョブにも継承させたい場合にも同様に有効である。

図１０に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブと同じである。複製以外の方法によって生成したジョブが所属するグループも、生成元のジョブと同じである。

図１１は、アプリケーションジョブとこれから生成した演算ジョブを同じグループに所属させる例を示す図である。承認者がアプリケーションジョブの段階から承認を実施したい場合には、図１１に示すグループ構造が有効である。

図１１に示す例においては、複製によって生成したジョブが所属するグループは、複製元ジョブと同じである。複製以外の方法によって生成したジョブが所属するグループも、生成元のジョブと同じである。

図１２は、グループ管理部１４０が図８〜図１０に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。ここでは２つの計算機ノード１００の間で分割した演算ジョブを配布する例を示した。以下、図１２の各ステップについて説明する。

（図１２：ステップＳ１２０１）
ユーザがアプリケーションジョブを計算機ノード１００へ投入するか、または他の計算機ノード１００が演算ジョブを配布すると、ジョブ受付部１１０はそのジョブを受け付ける。ジョブ受付部１１０は、受け取ったジョブがいずれのグループに属するかを、例えば引き渡されるパラメータに基づき判定する。

（図１２：ステップＳ１２０２〜Ｓ１２０３）
ジョブが終了段階に達している場合はそのジョブを終了し、実行すべきステップが残っている場合はステップＳ１２０３へ進む（Ｓ１２０２）。ジョブ制御部１５０は、実行すべき演算ジョブの次のステップを取得する（Ｓ１２０３）。

（図１２：ステップＳ１２０４）
リソース操作検知部１２０は、次に実行すべきステップが、アクセスする際に承認を要するコンピュータリソースを使用するか否かを判定する。使用する場合はステップＳ１２０５において後述の図１４で説明する処理フローを実行し、使用しない場合はステップＳ１２０７へスキップする。

（図１２：ステップＳ１２０６）
承認制御部１３０は、承認サーバ２００よりコンピュータリソースを使用してよいか否かについての承認結果を受け取る。使用を許可する旨の承認結果を受け取った場合はステップＳ１２０７へ進み、使用を許可しない旨の承認結果を受け取った場合はジョブ制御部１５０が現在実行している演算ジョブをエラー終了する。

（図１２：ステップＳ１２０７）
ジョブ制御部１５０は、演算ジョブを他の計算機ノード１００とともに分担して実行するため子ジョブ（分割ジョブ）を生成するか否かを判定する。この判定は、例えば想定される演算ジョブの負荷に応じて実施してもよいし、ユーザが手動で指定してもよい。子ジョブを生成する場合はステップＳ１２０８へ進み、生成しない場合はステップＳ１２０３で取得した処理を実行してステップＳ１２０２へ戻る。

（図１２：ステップＳ１２０８〜Ｓ１２１０）
ジョブ制御部１５０は、分割ジョブを実行するよう依頼する計算機ノード１００を決定する（Ｓ１２０８）。リソース分割部１６０は、ステップＳ１２０５で承認依頼を発行したコンピュータリソースを分割し、分割ジョブを依頼する計算機ノード１００へ配布する（Ｓ１２０９）。リソース分割部１６０は、分割前後のコンピュータリソースの対応関係を、分割情報ＤＢ４２０へ登録する（Ｓ１２１０）。

（図１２：ステップＳ１２１１〜Ｓ１２１３）
グループ管理部１４０は、分割ジョブを所属させるグループを作成し、グループＩＤを付与する（Ｓ１２１１）。ジョブ制御部１５０は、例えば演算ジョブを複製するなどして分割ジョブを生成し、その分割ジョブとグループＩＤを対応付ける（Ｓ１２１２）。分割ジョブは以後そのグループＩＤを引き継ぐ。ジョブ制御部１５０は、分割ジョブを他の計算機ノード１００へ配布し、実行させる（Ｓ１２１３）。

（図１２：ステップＳ１２１１〜Ｓ１２１３：補足その１）
分割ジョブが属するグループＩＤの値が攻撃者に知られると、そのグループＩＤを用いてコンピュータリソースへ不正にアクセスされる可能性がある。これを防ぐためには、例えばステップＳ１２１１において乱数を用いてグループＩＤを生成する、グループＩＤを他の計算機ノード１００へ送信する際に暗号化する、などの手法が考えられる。

（図１２：ステップＳ１２１１〜Ｓ１２１３：補足その２）
分割ジョブを配布された計算機ノード１００は、ステップＳ１２０１〜Ｓ１２１７と同様の処理を実行する。すなわち、分割ジョブをさらに分割する場合にはステップＳ１２０７以降と同様の処理を実行し、さらに分割しない場合にはステップＳ１２０７において子ジョブを生成せず単独で処理を実行する。

（図１２：ステップＳ１２１４〜Ｓ１２１７）
ジョブ制御部１５０は、各計算機ノード１００が実行した分割ジョブの結果を集約して集計する（Ｓ１２１４）。ステップＳ１２１１において新たなグループを作成した場合はステップＳ１２１６において後述の図１６で説明する処理フローを実行し、作成しなかった場合はステップＳ１２１７へスキップする（Ｓ１２１５）。リソース分割部１６０は、ステップＳ１２１０で分割情報ＤＢ４２０へ登録した情報を削除する（Ｓ１２１７）。

図１３は、グループ管理部１４０が図１１に示すグループ構造を採用する場合における、ジョブ実行システム１０００の動作フローを示す図である。以下、図１３の各ステップについて説明する。図１２と同様のステップについては同じ符号を付しているが、ステップの順序が図１２とは異なる。以下、図１２と異なる点および新たに追加されたステップを中心に説明する。

（図１３：ステップＳ１３０１）
ジョブ受付部１１０がジョブを受け取った後、グループ管理部１４０は、そのジョブが属するグループがパラメータ等によって指定されているか否かを判定する。ユーザが最初にアプリケーションジョブを投入した場合は未だそのアプリケーションジョブを所属させるグループが作成されていないため、ステップＳ１２１１で新たにグループを作成する。アプリケーションジョブから生成した演算ジョブ以降のジョブを受け取った場合は、既に派生元であるアプリケーションジョブが所属するグループが作成されているので、ステップＳ１２０２へスキップする。

（図１３：ステップＳ１２０２）
本ステップは図１２と同様であるが、本ステップの次にステップＳ１２１５〜Ｓ１２１６を実行する点が図１２とは異なる。図１２においては図８〜図１０のグループ構造を採用しているため演算ジョブが全て終了した時点でグループを削除すればよいのに対し、図１３においては演算ジョブが終了してもアプリケーションジョブが残っている場合があるので、ジョブを終了する直前にグループを削除することとした。

（図１３：ステップＳ１２０６）
本ステップは図１２と同様であるが、本ステップの次にステップＳ１３０２〜Ｓ１３０３を実行する点が図１２とは異なる。これらのステップはステップＳ１２１５〜Ｓ１２１６と同様である。ステップＳ１２０２と同様の理由により、ジョブをエラー終了する直前でグループを削除することとしたものである。

（図１３：ステップＳ１２１０）
図１３においては、ジョブを受け付けた直後にグループを作成しているので、本ステップの次はステップＳ１２１２へ進む。以後のステップは図１２と同様である。ただしグループ削除については上述の通りステップＳ１２０２の直後とステップＳ１２０６の直後に実行することとした。

図１４は、ステップＳ１２０５の詳細を示す図である。以下、図１４の各ステップについて説明する。

（図１４：ステップＳ１４０１）
計算機ノード１００の承認制御部１３０は、承認依頼に係るコンピュータリソースを生成する元になった分割前リソースが存在するか否かを確認するため、そのコンピュータリソースのＩＤをキーにして分割情報ＤＢ４２０を検索する。

（図１４：ステップＳ１４０２）
承認制御部１３０は、ステップＳ１４０１において分割前リソースが見つかった場合は、その分割前リソースをキーにしてリソース情報ＤＢ４１０を検索する。ステップＳ１４０１において分割前リソースが見つからなかった場合は、承認依頼に係るコンピュータリソースをキーにしてリソース情報ＤＢ４１０を検索する。

（図１４：ステップＳ１４０３〜Ｓ１４０４）
承認制御部１３０は、ステップＳ１４０２においてリソース情報ＤＢ４１０上に該当するレコードが見つかった場合は、そのコンピュータリソースにアクセスする際に承認を要すると判断し、ステップＳ１４０４において承認サーバ２００へ承認依頼を発行する。リソース情報ＤＢ４１０上に該当するレコードが見つからなかった場合は、そのコンピュータリソースにアクセスする際に承認は必要ないので、本処理を終了する。

（図１４：ステップＳ１４０５〜Ｓ１４０７）
承認サーバ２００の依頼受付部２１０は、承認依頼を受け付ける（Ｓ１４０５）。承認部２２０は、ステップＳ１４０１〜Ｓ１４０２と同様の処理を実行する。分割前リソースが見つかった場合はその分割前リソースに係るグループを承認対象とする。分割前リソースが見つからなかった場合は承認依頼に係るグループを承認対象とする（Ｓ１４０６〜Ｓ１４０７）。

（図１４：ステップＳ１４０８〜Ｓ１４０９）
承認部２２０は、承認依頼に係る演算ジョブが属するグループと、ステップＳ１４０７において承認対象として設定したコンピュータリソースとをキーにして、承認結果ＤＢ２５０を検索する（Ｓ１４０８）。該当する承認結果が見つかった場合はステップＳ１４１２へスキップし、見つからなかった場合はステップＳ１４１０へ進む（Ｓ１４０９）。

（図１４：ステップＳ１４１０〜Ｓ１４１１）
承認部２２０は、ステップＳ１４０８において承認結果ＤＢ２５０上に該当するレコードが見つからなかった場合は、当該承認依頼は未回答であると判断し、リソース情報ＤＢ４１０からその承認依頼に対して回答すべき承認者を検索する（Ｓ１４１０）。承認部２２０は、ステップＳ１４１０で特定した承認者と併せて、承認依頼を承認依頼ＤＢ２４０に登録する（Ｓ１４１１）。該当する承認者が複数存在する場合は、個々の承認者についてそれぞれレコードを登録する。

（図１４：ステップＳ１４１２）
本ステップは、後述する図１５のポイントＡの続きである。承認部２２０は、先に説明した手法により承認依頼に対する最終的な承認結果を決定し、承認結果ＤＢ２５０にその承認結果を登録する。

（図１４：ステップＳ１４１３〜Ｓ１４１４）
承認部２２０は、承認結果ＤＢ２５０に登録されている最終承認結果を計算機ノード１００へ返信する（Ｓ１４１３）。計算機ノード１００の承認制御部１３０は、その承認結果を受信する（Ｓ１４１４）。

（図１４：ステップＳ１４１５）
承認部２２０は、承認結果ＤＢ２５０に登録されている最終承認結果のグループＩＤ２５１とリソースＩＤ２５２をキーにして、承認依頼ＤＢ２４０を検索する。承認部２２０は、該当する承認依頼ＤＢ２４０のレコードを削除する。具体的には、承認結果が出たリソースをキーとして、リソースＩＤ２４３だけでなく、分割前リソースＩＤ２４７も検索してヒットしたレコードを削除する。

図１５は、承認者が承認者端末３００を用いて承認依頼に対する回答を入力する処理を説明する図である。以下、図１５の各ステップについて説明する。

（図１５：ステップＳ１５０１〜Ｓ１５０２）
承認者端末３００は、承認者サーバ２００に対し、未回答の承認依頼のリストを送信するよう要求する（Ｓ１５０１）。承認部２２０は、その承認者のＩＤをキーにして承認依頼ＤＢ２４０を検索し、該当する承認依頼のリストを取得する（Ｓ１５０２）。

（図１５：ステップＳ１５０３）
承認部２２０は、ステップＳ１５０２で取得した承認依頼のリストのなかから、回答済のものを削除する。具体的には、回答フィールド２４６が既に入力されている承認依頼をまず削除する。次に、グループＩＤフィールド２４１とリソースＩＤフィールド２４３が回答済の承認依頼と同じである承認依頼をさらに削除する。

（図１５：ステップＳ１５０３：補足）
承認依頼のリスト作成時は、分割前リソースが同じ分割後リソースに対する承認依頼があった場合、その中の１つでも回答済みなら、同じ分割前リソースを持つ他の分割後リソースも回答済みと判断する。すなわち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３のペアだけでなく、グループＩＤフィールド２４１と分割前リソースＩＤフィールド２４７のペアでもグループ化し、その中のいずれかが回答済みであれば、回答済みと判断する。

（図１５：ステップＳ１５０４）
承認部２２０は、ステップＳ１５０３で残った承認依頼のうち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３が同じものについては、そのなかのいずれか任意の１つのみを残し、その他は削除する。

（図１５：ステップＳ１５０４：補足）
承認依頼のリスト作成時は、分割前リソースが同じものを１つにまとめる。すなわち、グループＩＤフィールド２４１とリソースＩＤフィールド２４３のペアでグループ化したレコード群の中から任意の１つを選んだ後、グループＩＤフィールド２４１と分割前リソースＩＤフィールド２４７のペアでもグループ化し、その中から任意の１つを選び、レコード数を削減する。つまり、グループIDフィールド241とリソースIDフィールド243のペアでグループ化したレコード群の中から任意の1つを選んだ後、グループIDフィールド241と分割前リソースIDフィールド247のペアでもグループ化し、その中から任意の1つを選び、レコード数を削減する。

（図１５：ステップＳ１５０５〜Ｓ１５０６）
優先度判定部２３０は、ステップＳ１５０４で残った承認依頼について、承認者が回答すべき優先度を判定し、各承認依頼にその優先度を付与する（Ｓ１５０５）。承認部２２０は、優先度を付与した承認依頼のリストを承認者端末３００へ送信する（Ｓ１５０６）。

（図１５：ステップＳ１５０７〜Ｓ１５０８）
承認者は、図６で説明した承認依頼一覧画面３１０上で、承認依頼に対する回答を入力する（Ｓ１５０７）。承認部２２０は、その回答を受け取り、承認依頼ＤＢ２４０の回答フィールド２４６へその回答を記録する（Ｓ１５０８）。

（図１５：ステップＳ１５０９〜Ｓ１５１０）
承認部２２０は、各承認者が入力した回答フィールド２４６を集計し、上述の手法により最終的な承認結果を判定する（Ｓ１５０９）。最終的な承認結果を確定することができる段階に至っている場合は図１４のポイントＡへ進み、それ以外であれば本処理フローを終了する（Ｓ１５１０）。

図１６は、ステップＳ１２１６の詳細を示す図である。以下、図１６の各ステップについて説明する。

（図１６：ステップＳ１６０１）
計算機ノード１００のグループ管理部１４０は、所属する全てのジョブが終了したグループのＩＤをキーにして分割情報ＤＢ４２０を検索し、該当するレコードを削除する。本ステップと同様の処理はステップＳ１６０５において承認サーバ２００も実行するので、省略してもよい。

（図１６：ステップＳ１６０２〜Ｓ１６０５）
グループ管理部１４０は、ステップＳ１６０１で検索したレコードに対応するグループを削除するよう、承認サーバ２００へ要求する（Ｓ１６０２）。承認サーバ２００の承認部２２０は、依頼されたグループＩＤをキーにして、該当するレコードを承認結果ＤＢ２５０、承認依頼ＤＢ２４０、分割情報ＤＢ４２０からそれぞれ削除する（Ｓ１６０３〜Ｓ１６０５）。グループに属する全てのジョブが終了した後は、これらのレコードは必要ないからである。これにより、例えば承認結果を不正に取得してコンピュータリソースへ不正アクセスするような攻撃を防ぐことができる。

＜実施の形態２：まとめ＞
以上のように、本実施形態２に係るジョブ実行システム１０００は、図８〜図１１で説明したグループ構造のうちいずれかを採用することができる。これにより、図８〜図１１でそれぞれ説明したようなジョブの特性や承認者の権限などに応じて、適切な承認作業を実施することができる。

＜実施の形態３＞
実施形態１〜２では、優先度判定部２３０が承認依頼の優先度を判定する手法として、多数決に係る承認者数が多いものを優先することを説明した。本発明の実施形態３では、優先度を判定するその他の手法について説明する。これらの手法は実施形態１〜２で説明したものに代えて用いることもできるし、ジョブの性質等に応じて判定手法を入れ替えるなどによって併用してもよい。

（優先度の判定手法その１）
同じコンピュータリソースに対して複数のグループから承認依頼が届いている場合、そのコンピュータリソースについては承認結果を早く決定して依頼元へ通知することが望ましいと考えられる。そこで、このようなコンピュータリソースに係る承認依頼は、関連するグループの数が多いほど優先度を高くすることが考えられる。コンピュータリソースに係る承認依頼の件数は、承認依頼ＤＢ２４０のリソースＩＤフィールド２４３をキーにしてレコードをグループ化する（例えばＳＱＬのｇｒｏｕｐ ｂｙ句を用いる）ことによりカウントできる。

（優先度の判定手法その２）
同じグループに属する複数の演算ジョブから承認依頼が届いている場合、グループが多数のノードで実行されている（多くの計算資源を占有している）と想定される。そこで、承認依頼に係る演算ジョブのうち同じグループに属するものが多いほど、そのグループからの承認依頼の優先度を高くすることが考えられる。グループ毎の承認依頼の件数は、承認依頼ＤＢ２４０のグループＩＤフィールド２４１をキーにしてレコードをグループ化することによりカウントできる。グループ化した承認依頼のうち、依頼元が同じものを１つにまとめたとき、レコード数が多いものほど優先度を高く設定する。

（優先度の判定手法その３）
同じグループに係る承認済のコンピュータリソース数が多い場合、そのグループに属するジョブがアクセスする必要があるコンピュータリソース数が多いと考えられる。この場合、そのグループが確保しているコンピュータリソースの数が多いと想定される。そこで、承認依頼に係るコンピュータリソースのうち同じグループに属するものが多いほど、そのグループからの承認依頼の優先度を高くすることが考えられる。グループ毎のコンピュータリソースの件数は、承認依頼ＤＢ２４０のグループＩＤフィールド２４１とリソースＩＤフィールド２４３をキーにしてレコードをグループ化することによりカウントできる。

＜実施の形態４＞
以上の実施形態１〜３において、承認サーバ２００がコンピュータリソースへのアクセスを許可する旨の承認結果を計算機ノード１００へ送信するまでは、計算機ノード１００はそのコンピュータリソースを用いたジョブを実行することができないようにしておくことが、セキュリティ対策の上で必要である。これを実現する具体的な手法として、以下のようなものが考えられる。

（承認に関するアクセス制御手法その１）
ジョブが使用するコンピュータリソースがデータファイルである場合、セキュリティを確保するため、そのデータファイルをあらかじめ暗号化しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、その復号キーを併せて計算機ノード１００へ送信する。これにより、適正な承認結果を得るまではそのデータファイルを読み取ることができないので、仮にそのデータファイルへアクセスしてもジョブを実行することはできない。

（承認に関するアクセス制御手法その２）
手法その１と同様の手法として、データファイルに対するアクセス権限を付与することが考えられる。例えばファイルシステム上のアクセス権限設定により、データファイルに対するアクセスをあらかじめ禁止しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、アクセス権限を付与する情報を併せて計算機ノード１００へ送信する。

（承認に関するアクセス制御手法その３）
上記手法その１〜その２は、データベースに対するアクセスにおいても有用である。すなわち、データベース上のデータをあらかじめ暗号化しておくか、またはデータベースに対するアクセス権限を付与することにより、同様の効果を発揮することができる。

（承認に関するアクセス制御手法その４）
ジョブが使用するコンピュータリソースが計算機ノード１００の演算リソース（例えばＣＰＵやメモリ）である場合、ファイアウォールの設定などにより、その計算機ノード１００に対する通信をあらかじめ遮断しておく。承認サーバ２００は、コンピュータリソースに対するアクセスを許可する旨の承認結果を送信する際に、ファイアウォールの設定を変更し、アクセス元の計算機ノード１００とアクセス先の計算機ノード１００との間の通信を許可する。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。

例えば、各コンピュータが備える機能部を入れ替えることもできるし、あるコンピュータ上に集約することもできる。具体的には、いずれかの計算機ノード１００上に承認サーバ２００の機能部を実装することが考えられる。あるいは、分割ジョブのみを実行し、さらなる分割ジョブや派生ジョブを生成しない計算機ノード１００については、ジョブ複製部１５１とリソース分割部１６０は必要ないであろう。すなわち、ジョブ実行システム１０００全体として、以上の実施形態で説明した各機能部が、分散システムの趣旨を損なわない態様で設けられていればよい。

上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

１００：計算機ノード、１１０：ジョブ受付部、１２０：リソース操作検知部、１３０：承認制御部、１４０：グループ管理部、１５０：ジョブ制御部、１６０：リソース分割部、２００：承認サーバ、２１０：依頼受付部、２２０：承認部、２３０：優先度判定部、２４０：承認依頼ＤＢ、２５０：承認結果ＤＢ、３００：承認者端末、４１０：リソース情報ＤＢ、４２０：分割情報ＤＢ、１０００：ジョブ実行システム。

Claims (20)

1. コンピュータリソースを用いて演算ジョブを実行するジョブ制御部と、
   前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御部と、
   複数の前記演算ジョブをグループ化したグループを作成するグループ管理部と、
   を備え、
   前記承認制御部は、
   前記グループ管理部が作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼し、前記承認結果として前記グループに対する承認結果を受け取り、
   前記ジョブ制御部は、
   前記グループに対して実行を許可する旨の前記承認結果を前記承認制御部が受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行し、
   前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御部が受け取った場合は、そのグループに含まれる各前記演算ジョブを実行しない
   ことを特徴とするジョブ実行システム。
2. 前記ジョブ実行システムは、
   前記演算ジョブを複製することによって生成した子ジョブを他の計算機ノードに対して配布して実行させるジョブ複製部を備え、
   前記グループ管理部は、
   前記ジョブ複製部が生成した前記子ジョブをグループ化し、
   前記承認制御部は、
   前記子ジョブを含む前記グループに対する前記承認を依頼する
   ことを特徴とする請求項１記載のジョブ実行システム。
3. 前記ジョブ実行システムは、
   前記コンピュータリソースを分割して前記他の計算機ノードへ配布するリソース分割部を備え、
   前記ジョブ複製部は、
   前記リソース分割部が前記他の計算機ノードへ配布した前記コンピュータリソースを用いて前記子ジョブを実行するよう前記他の計算機ノードへ指示し、
   前記承認制御部は、
   前記グループ管理部が作成した前記グループに含まれる前記演算ジョブのうち前記リソース分割部が分割する前の前記コンピュータリソースを使用する演算ジョブである分割前演算ジョブに対する前記承認を依頼し、
   前記ジョブ制御部は、
   前記分割前演算ジョブの実行を許可する旨の前記承認結果を前記承認制御部が受け取った場合は、前記グループ管理部が作成した前記グループに含まれる前記演算ジョブのうち前記リソース分割部が分割する前後双方に係る前記コンピュータリソースを使用する演算ジョブをいずれも実行する
   ことを特徴とする請求項２記載のジョブ実行システム。
4. 前記コンピュータリソースは、暗号化されたデータファイルであり、
   前記承認制御部は、
   前記グループに対して実行を許可する旨の前記承認結果とともに、前記コンピュータリソースを復号するための復号鍵を併せて受け取り、
   前記ジョブ制御部は、
   前記復号鍵を用いて復号した前記コンピュータリソースを用いて前記演算ジョブを実行する
   ことを特徴とする請求項１から３のいずれか１項記載のジョブ実行システム。
5. 前記ジョブ実行システムは、
   前記演算ジョブが使用する際に承認を要する前記コンピュータリソースのＩＤを記憶するリソース情報記憶部を備え、
   前記承認制御部は、
   前記演算ジョブが使用する前記コンピュータリソースのＩＤが前記リソース情報記憶部に格納されている場合は、そのコンピュータリソースを用いて前記演算ジョブを実行する可否について前記承認を依頼し、
   前記ジョブ実行部は、
   前記演算ジョブが使用する前記コンピュータリソースのＩＤが前記リソース情報記憶部に格納されていない場合は、前記承認制御部が前記承認を依頼していなくとも、そのコンピュータリソースを用いて前記演算ジョブを実行する
   ことを特徴とする請求項１から４のいずれか１項記載のジョブ実行システム。
6. 前記ジョブ複製部は、前記子ジョブを生成する際に、
   前記演算ジョブが属する前記グループのＩＤを複製元の前記演算ジョブから複製後の前記子ジョブへ引き継ぎ、または、前記演算ジョブもしくは前記子ジョブが使用する前記コンピュータリソースのＩＤを前記グループのＩＤとともに記憶装置へ格納しておき、
   前記承認制御部は、
   前記子ジョブが複製元の前記演算ジョブから引き継いだ前記ＩＤを取得し、または、演算ジョブもしくは前記子ジョブが使用する前記コンピュータリソースに対応する前記グループのＩＤを前記記憶装置から読み出すことにより、前記演算ジョブまたは前記子ジョブがいずれの前記グループに属するかを特定する
   ことを特徴とする請求項２または３記載のジョブ実行システム。
7. 前記グループ管理部は、
   同じ前記演算ジョブを複製することによって生成された前記子ジョブおよびその子ジョブから派生した演算ジョブを、同じ前記グループとしてグループ化する
   ことを特徴とする請求項６記載のジョブ実行システム。
8. 前記グループ管理部は、
   同じ前記演算ジョブを複製することによって生成された前記子ジョブを同じ前記グループとしてグループ化し、前記子ジョブから派生した演算ジョブはそのグループには含めない
   ことを特徴とする請求項６項記載のジョブ実行システム。
9. 前記グループ管理部は、
   同じ前記演算ジョブを複製することによって生成された前記子ジョブ、その子ジョブから派生した演算ジョブ、および前記子ジョブの複製元となった前記演算ジョブを、同じ前記グループとしてグループ化する
   ことを特徴とする請求項６記載のジョブ実行システム。
10. 前記ジョブ複製部は、
    上位アプリケーションから投入されたアプリケーションジョブから派生するジョブを前記演算ジョブとして処理し、
    前記グループ管理部は、
    同じ前記演算ジョブを複製することによって生成された前記子ジョブ、その子ジョブから派生した演算ジョブ、前記子ジョブの複製元となった前記演算ジョブ、および前記子ジョブの複製元となった前記演算ジョブの派生元である前記アプリケーションジョブを、同じ前記グループとしてグループ化する
    ことを特徴とする請求項６記載のジョブ実行システム。
11. 前記ジョブ実行システムは、
    前記承認制御部が発行した前記承認の依頼を承認するか否かを判定しその承認結果を前記承認制御部へ通知する承認部を備える
    ことを特徴とする請求項１から１０のいずれか１項記載のジョブ実行システム。
12. 前記承認部は、
    前記承認制御部が発行した前記承認の依頼を承認する場合であって、かつ前記コンピュータリソースが暗号化されたデータファイルである場合は、前記コンピュータリソースを復号するための復号鍵を、前記承認の依頼に対する承認結果とともに前記承認制御部へ送信する
    ことを特徴とする請求項１１記載のジョブ実行システム。
13. 前記ジョブ実行システムは、
    前記承認部が承認した前記依頼に係る前記グループのＩＤを格納する承認結果記憶部を備え、
    前記承認部は、
    承認した前記依頼に係る前記グループに含まれている全ての前記演算ジョブが終了するまで、前記承認結果記憶部が格納している前記グループのＩＤを前記承認結果記憶部上に保持しておき、
    前記承認結果記憶部上にＩＤを保持している前記グループと同じ前記グループについて前記依頼を受け取ると、その依頼を承認するか否かを判定することなく、承認した旨の承認結果を前記承認制御部へ通知する
    ことを特徴とする請求項１１または１２記載のジョブ実行システム。
14. 前記グループ管理部は、
    前記グループに含まれる全ての前記演算ジョブが終了するとそのグループを削除し、
    前記承認部は、
    前記グループが削除された後、前記承認結果記憶部が保持している前記承認結果のうち削除された前記グループに係るものを削除する
    ことを特徴とする請求項１３記載のジョブ実行システム。
15. 前記ジョブ実行システムは、
    前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    前記優先度判定部は、
    前記依頼の数が多い前記グループに係る前記承認ほど前記承認優先度を高くする
    ことを特徴とする請求項１１から１４のいずれか１項記載のジョブ実行システム。
16. 前記ジョブ実行システムは、
    前記承認部が前記承認を実施する順序を規定する承認優先度を判定する優先度判定部を備え、
    前記承認部は、
    複数の承認者から受け取った前記依頼に対する承認結果に基づき前記承認の依頼を承認するか否かを判定し、
    前記優先度判定部は、
    前記承認部が前記承認の依頼を承認するか否かを判定するために必要になる前記承認者の人数が多い前記承認ほど前記承認優先度を高くする
    ことを特徴とする請求項１１から１５のいずれか１項記載のジョブ実行システム。
17. 前記ジョブ実行システムは、
    前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    前記優先度判定部は、
    前記承認依頼に係る前記演算ジョブが多く含まれている前記グループに係る前記承認ほど前記承認優先度を高くする
    ことを特徴とする請求項１１から１６のいずれか１項記載のジョブ実行システム。
18. 前記ジョブ実行システムは、
    前記承認部が前記承認を実施すべき順序を規定する承認優先度を判定する優先度判定部を備え、
    前記優先度判定部は、
    前記グループに含まれる前記演算ジョブが使用する前記コンピュータリソースのうち前記承認が済んでいるものが多い前記グループに係る前記承認ほど前記承認優先度を高くする
    ことを特徴とする請求項１１から１７のいずれか１項記載のジョブ実行システム。
19. コンピュータリソースを用いて演算ジョブを実行するジョブ制御ステップと、
    前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御ステップと、
    複数の前記演算ジョブをグループ化したグループを作成するグループ管理ステップと、
    をコンピュータに実行させ、
    前記承認制御ステップでは、前記コンピュータに、
    前記グループ管理ステップで作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼させ、前記承認結果として前記グループに対する承認結果を受け取らせ、
    前記ジョブ制御ステップでは、前記コンピュータに、
    前記グループに対して実行を許可する旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行させ、
    前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブを実行させない
    ことを特徴とするジョブ実行プログラム。
20. コンピュータリソースを用いて演算ジョブを実行するジョブ制御ステップと、
    前記コンピュータリソースを用いて前記演算ジョブを実行する可否について承認を依頼しその承認結果を受け取る承認制御ステップと、
    複数の前記演算ジョブをグループ化したグループを作成するグループ管理ステップと、
    を有し、
    前記承認制御ステップでは、
    前記グループ管理ステップで作成した前記グループに含まれる前記演算ジョブに対する前記承認を依頼し、前記承認結果として前記グループに対する承認結果を受け取り、
    前記ジョブ制御ステップでは、
    前記グループに対して実行を許可する旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブをそれぞれ実行し、
    前記グループに対して実行を許可しない旨の前記承認結果を前記承認制御ステップで受け取った場合は、そのグループに含まれる各前記演算ジョブを実行しない
    ことを特徴とするジョブ実行方法。

Images