JPWO2014192867A1 - 分散処理システム、分散処理装置、分散処理方法および分散処理プログラム - Google Patents

Abstract

【課題】転送するデータ容量を削減し、かつ分散処理を高速に開始することを可能とする分散処理システム等を提供する。【解決手段】複数台のコンピュータ２ａ、２ｂ、…が相互に接続された分散処理システム１で、各コンピュータ２は、各モジュールを読み込んで初期化処理を行うモジュールローダ３と、初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部４と、記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部５と、分散バッチアプリを実行する実行コンテナ６とを備える。そして、ファイル管理部５が、初期化処理の後で当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む。【選択図】図１

Description

本発明は分散処理システム、分散処理装置、分散処理方法および分散処理プログラムに関し、特に通信容量を削減して高速に処理を実行可能な分散処理システム等に関する。

コンピュータが実現せねばならない処理はますます高度かつ大規模になっているが、ハードウェア単体としての性能（演算能力や記憶容量など）の向上は既に限界に達している。そこで、ネットワークを介して相互に接続された複数のコンピュータが連携し、分担して処理を行うという、分散処理（分散データベース、分散キャッシュ、分散共有メモリ、分散バッチなど）の技術が最近とみに発達している。

特に近年は、パーソナルコンピュータの分野においても、４ＧＢクラスの容量を持つＲＡＭ（主記憶装置）、１ＴＢクラスの容量を持つハードディスク（外部記憶装置）、１Ｇｂｐｓクラスの通信速度を持つＮＩＣ（ネットワークカード）などを安価に調達し、それらを備えたコンピュータ装置を高速ネットワークを介して相互に接続することが容易にできるようになったので、それらのようなノード（サーバ装置）を複数台接続し、それら各ノードに分散処理ミドルウェアを導入して分散処理を行わせることが多くなっている。

ミドルウェアとは、一般的にはオペレーティングシステム（ＯＳ）とアプリケーションソフトとの中間に入って、ＯＳの機能の拡張やアプリケーションソフトの汎用的な機能を担うソフトウェアのことをいう。その中でも分散処理ミドルウェアは、分散処理において必要となる機能（複数ノード間のデータ同期、アプリケーションの配布・配備、プロセスの起動・終了、エラー処理など）を提供するものである。特に近年は、多数のノードによって協調して処理を行ういわゆるクラウド・コンピューテングが発達しているので、分散処理ミドルウェアの重要性は特に高まっている。

分散処理ミドルウェアを利用した分散処理システムで実行可能な分散処理方式としては、マップリデュース（MapReduce）、ＢＳＰ、ＭＰＩなどのような複数の方式があるが、その中でマスター・スレーブ型の分散処理方式も一般的である。

マスター・スレーブ型は処理モデルの一種であり、マスターと呼ばれる制御コンポーネントやノードが、スレーブと呼ばれる他のノードやデバイスやプロセスを制御するものである。ノード間、あるいはプロセス間でマスター・スレーブ関係が確立されると、制御は常にマスターからスレーブに対して行われる。

図２０は、既存の分散処理システム９００の構成について示す説明図である。この分散処理システム９００は、複数台のコンピュータ装置がネットワーク９３０を介して相互に接続されることによって構成される。それらのコンピュータ装置のうちの１台がマスターノード９１０であり、他はスレーブノード９２０ａ、９２０ｂ、…（総称してスレーブノード９２０という）である。

マスターノード９１０には、ＯＳ９１１（オペレーティングシステム）上に分散処理ミドルウェア９１２がインストールされている。同様にスレーブノード９２０にも、ＯＳ９２１上に分散処理ミドルウェア９２２がインストールされている。

マスターノード９１０は、スレーブノード９２０に対して分散アプリケーションを配布し、必要な処理を実行させる。ただし、スレーブノードで処理する部分はマスターノードと全く一緒ではなく、処理の一部やデータの一部であることが多い。それぞれのノードで違う処理や違うデータを処理することにより、複数の処理を分散して並列化することができるので、高速に処理を行うことが可能となる。

図２１は、図２０で示した分散処理システム９００によって実行される分散アプリケーション９５０の構成について示す説明図である。分散アプリケーション９５０は、処理モジュール、共通モジュール、設定ファイル、バイナリデータ（画像ファイルなど）などがそれぞれ複数組み合わされて構成されている。

各モジュールは、実行形式ファイルや共通ライブラリファイルなどである。たとえばウィンドウズ（登録商標）の場合はＥＸＥファイルやＤＬＬファイル、Ｌｉｎｕｘ（登録商標）の場合はシェルスクリプト、実行ファイルやライブラリファイル、Ｊａｖａ（登録商標）の場合はＪａｒファイルやＣｌａｓｓファイルなどである。

どの場合も、各モジュールは「メタデータ」および「実行領域」によって構成される。メタデータはモジュール名やシグネチャー（メソッド名と引数の組み）、フィールド、定数などのモジュールに関するデータである。実行領域には実際に動作するメソッドなどの実行コードである。

また、各モジュールには実行時における初期化の処理も含まれる。より具体的には、ウィンドウズのＤＬＬの初期化はＤｌｌＭａｉｎ（）、Ｌｉｎｕｘのライブラリの初期化は＿ｉｎｉｔ（）、Ｊａｖａの初期化は＜ｃｌｉｎｉｔ＞、＜ｉｎｉｔ＞などである。

分散アプリケーション９５０が起動する場合、各ノードでは最初に起動された処理モジュールのメタデータを読み込み、メタデータの解析を行なって実際に処理ができるように定数や実行領域をメモリに配置する。もしその中に他モジュールに対する依存関係が含まれていれば、そのモジュールを読み込んでその依存関係を解決し、モジュール間の呼び出しが可能な状態とする（これをリンクするという）ことを繰り返す。

通常、各モジュールには初期化処理のための部分があり、リンクした後にその初期化処理を行うことにより、当該アプリケーションが実行可能な状態となる。即ち、「必要なファイルを読み出す（Load）→各モジュールの依存関係を解決する（Link）→初期化処理を行う（Initialize）」ことを繰り返すことにより、分散アプリケーション９５０の実行が可能となる。

ただし、各モジュールをどのタイミングで読み込むかは各装置の実装に依存し、必要なモジュールを起動時に全て読み込む場合もあれば、実際の参照が行われるまで読み込まない場合もある。

これに関連する技術文献として、次の各々がある。特許文献１には、設定されたルールに基づいてオブジェクトデータを選択して、これを利用する処理を効率化するという分散処理システムが記載されている。特許文献２には、グラフィックユーザインタフェースを利用して分散処理を管理するという技術について記載されている。特許文献３には、ネットワーク上でのメタデータの配置の技術について記載されている。

特許文献４には、特定の処理に特化したサブプロセッサを備えた処理装置を利用した分散処理システムが記載されている。特許文献５には、ネットワーク上のウェブサービスの配備について記載されている。特許文献６には、分散処理装置で必要な情報が自装置になければ他装置から取得し、全装置間で情報を一致させるという技術が記載されている。

特許文献７には、多層ソフトウェアのメタデータの配置の技術について記載されている。非特許文献１には、代表的な分散処理ミドルウェアであるＨａｄｏｏｐの概要について記載されている。

特開２０１２−０６３８３２号公報 特開２０１１−０３４１３７号公報 特開２００８−１７１２７７号公報 特開２００６−１５５１８７号公報 特表２００４−５３３６８７号公報 特開２００４−３４２０４２号公報 特表２００３−５０５７５０号公報

脇本武士、「Ｈａｄｏｏｐを使って分散処理をやってみよう！」、平成２２年９月２９日、［平成２５年５月１４日検索］、（株）パソナテック、インターネット＜URL：http://www.pasonatech.co.jp/techlab/rdtrend/rep7.jsp＞

本明細書では、前述の非特許文献１に記載されたＨａｄｏｏｐなど、Ｊａｖａ環境で動作する分散処理システム９００を想定しているので、各々の処理モジュールおよび共通モジュールはクラス（.class）ファイルとして記述されているものとする。必ずしも本発明はＪａｖａ環境に限定されるものではない。

図２１で示した分散アプリケーション９５０は、第１〜第３のステップの処理モジュール９５１〜９５３（step01.class〜step03.class）と、各ステップで使用される第１〜第３の共通モジュール９５４〜９５６（shared01.class〜shared03.class）、およびその他の設定ファイルやバイナリデータなどを含む。

かつ、第１および第３のステップはマスターノード９１０単体で実行されるが、第２のステップはマスターノード９１０と各スレーブノード９２０とが協調して分散処理を行うので、分散アプリケーション９５０には第２のステップのスレーブノード側での処理モジュール９５２ａ（step02_slave.class）も含まれている。以上の各ファイルは、「分散バッチアプリケーション１.jar」などのようなファイル名で、１ファイルにまとめられている。

図２２は、図２０で示した既存の分散処理システム９００で、図２１で示した分散アプリケーション９５０を実行する場合の動作について示す説明図である。ユーザから実行指令を受けたマスターノード９１０は、分散アプリケーション９５０のファイル（分散バッチアプリケーション１.jar）を各スレーブノード９２０に配布し、各ノードでは各々に分散処理ミドルウェア９１２（９２２）がプロセスを立ちあげ、この分散アプリケーション９５０のファイルを展開してクラスファイルを読み込み、そして実行する。

ただし図２１で示したように、分散アプリケーション９５０の全てのステップが分散処理を行うものではない。従って、単純に分散アプリケーション９５０のファイル（分散バッチアプリケーション１.jar）を各ノードに配布すると、分散処理に使用されないファイルまで転送してしまうこととなる。これは明らかに無駄な転送である。特に画像、動画、音声など、ファイルサイズの大きいファイルが含まれている場合、これが使用されなければ大きな無駄となる。

また、実行時にファイルを転送すると、スレーブノード９２０の起動処理の遅延という問題も発生する。図２１で示した例でいえば、第２のステップにおいて分散処理が行われるが、第１のステップが終了して第２のステップが開始される段階でマスターノード９１０が各スレーブノード９２０に分散アプリケーション９５０のファイルを配布すると、その配布処理、そして「分散バッチアプリケーション１.jar」ファイルを展開してクラスファイルを読み込むという段階の処理で遅延が発生する。

この遅延を発生させないために、マスターノード９１０が単体で第１のステップを実行している間に分散アプリケーション９５０のファイルを配布し、各スレーブノード９２０側で展開とクラスファイルの読み込みまで済ませておくという方法も考えられる。しかしこれだと別の問題が発生しうる。

分散処理では、スレーブノード９２０の台数が数千台や数万台、あるいはそれ以上の規模になることも多い。かつ、分散処理ミドルウェア９１２（９２２）は通常、実際に分散処理を行う段階になってから、各ノードのリソース（計算機資源）の状況を確認した上で、設定された台数のスレーブノードに処理を割り振るものである。即ち、どのスレーブノードが分散処理を行うかを、その段階になるまで知ることはできない。

従って、各スレーブノード９２０に対して無条件に分散アプリケーション９５０のファイルを事前配布していたら、実際には処理が割り振られないスレーブノード９２０に対してまで事前配布されることになりうる。これもまた無駄な転送である。即ち、スレーブノード９２０の起動処理の遅延をなくすために、分散アプリケーション９５０のファイルを事前配布するということは適切であるとはいえない。

さらに、各ノード（マスターノード９１０と各スレーブノード９２０）とが協調して行う分散処理は、多くの場合は、別々の対象データに対して同一の処理を行うものであるので、各ノードで起動時に行われる起動処理は共通した処理であることが多い。

それにもかかわらず、各スレーブノード９２０の分散処理ミドルウェア９２２は通常、動作ステップごとにプロセスを生成および削除する。従って、各ノードがそれぞれ、各動作ステップごとに毎回同一の起動処理を行っている。これもまた、遅延が発生する原因となる無駄な処理である。

以上の問題を解決して、実行時に各スレーブノードに転送するデータ容量を削減することと分散処理を高速に開始することとを両立しうる技術は、前述の特許文献１〜７や非特許文献１には記載されていない。

本発明の目的は、実行時に各スレーブノードに転送するデータ容量を削減し、かつ分散処理を高速に開始することを可能とする分散処理システム、分散処理装置、分散処理方法および分散処理プログラムを提供することにある。

上記目的を達成するため、本発明に係る分散処理システムは、複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムであって、各コンピュータが、分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、各モジュールのうち初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、分散バッチアプリを実行する実行コンテナとを備えると共に、ファイル管理部が、モジュールローダがメタデータによって初期化処理を行った後で当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む機能を備えたこと、を特徴とする。

上記目的を達成するため、本発明に係る分散処理装置は、複数台が相互に接続されることによって分散バッチアプリを協調して分散実行する分散処理システムを構成する分散処理装置であって、分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、各モジュールのうち初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、分散バッチアプリを実行する実行コンテナとを備えると共に、ファイル管理部が、モジュールローダがメタデータによって初期化処理を行った後で当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む機能を備えたこと、を特徴とする。

上記目的を達成するため、本発明に係る分散処理方法は、複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータをメタデータ管理部が取得し、メタデータによってモジュールローダが初期化処理を行い、初期化処理の後で、当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かをファイル管理部が調べ、実行コードを含む実行領域が記憶手段に存在しない場合、ファイル管理部が他のコンピュータから実行コードを読み込んでこれを実行領域として書き込み、実行コードを含む当該モジュールを実行コンテナが実行すること、を特徴とする。

上記目的を達成するため、本発明に係る分散処理プログラムは、複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、コンピュータに、分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータを取得する手順、メタデータによって初期化処理を行う手順、初期化処理の後で、当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べる手順、実行コードを含む実行領域が記憶手段に存在しない場合、他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む手順、および実行コードを含む当該モジュールを実行する手順を実行させること、を特徴とする。

本発明は、前述の通りメタデータのみによって仮の初期化処理を行い、その後で実行コードがなければ他のコンピュータから読み込むように構成したので、処理を実行しないコンピュータにまで実行コードが送信されることはない。これによって、実行時に各スレーブノードに転送するデータ容量を削減し、かつ分散処理を高速に開始することが可能であるという、優れた特徴を持つ分散処理システム、分散処理装置、分散処理方法および分散処理プログラムを提供することができる。

本発明の基本形態に係る分散処理システムの構成について示す説明図である。 本発明の第１の実施形態に係る分散処理システムの構成について示す説明図である。 図２に示したマスターノードおよびスレーブノードのより詳細な構成について示す説明図である。 図２〜３に示す分散処理システムで実行対象となる分散バッチアプリの構成について示す説明図である。 図２〜３に示す分散処理システムで、図４に示す分散バッチアプリを動作させる場合の処理について示すフローチャートである。 図５の続きである。 図５のステップＳ１０６までの処理が終わった状態でのメタデータ共有部の状態について示す説明図である。 図４に示す分散バッチアプリで、「実行領域ロード指示」が定義されている第１のマスターモジュール（step1.class）について示す説明図である。 図５のステップＳ１１３までの処理が終了して、実行領域が書き換えられた状態の第１のマスターモジュール（step1.class）について示す説明図である。 図４に示す分散バッチアプリで、「実行領域ロード指示」が定義されている第２のマスターモジュール（step2.class）について示す説明図である。 図５のステップＳ１１５の処理で作成されるメタデータのみのスレーブモジュール（step2_slave.class）について示す説明図である。 図５のステップＳ１１３に示した処理が終了して実行領域を配置された状態のスレーブモジュール（step2_slave.class）について示す説明図である。 本発明の第２の実施形態に係る分散処理システムの構成について示す説明図である。 図１３に示したマスターノードおよびスレーブノードのより詳細な構成について示す説明図である。 図１３〜１４に示した分散処理システムで動作する分散バッチアプリの構成について示す説明図である。 図１３〜１４に示す分散処理システムで、図１５に示す分散バッチアプリを動作させる場合の処理について示すフローチャートである。 図１６の続きである。 分散バッチアプリ３２０の動作が完了した状態のメタデータ共有部について示す説明図である。 分散バッチアプリ３２０の動作の後で分散バッチアプリ３３０の動作が完了した状態のメタデータ共有部について示す説明図である。 既存の分散処理システムの構成について示す説明図である。 図２０で示した分散処理システムによって実行される分散アプリケーションの構成について示す説明図である。 図２０で示した既存の分散処理システムで、図２１で示した分散アプリケーションを実行する場合の動作について示す説明図である。

（基本形態）
以下、本発明の基本形態の構成について添付図１に基づいて説明する。
基本形態に係る分散処理システム１は、複数台のコンピュータ２ａ、２ｂ、…が相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムである。各コンピュータ２は、分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダ３と、各モジュールのうち初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部４と、記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部５と、分散バッチアプリを実行する実行コンテナ６とを備える。そして、ファイル管理部５が、モジュールローダがメタデータによって初期化処理を行った後で当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む機能を備える。
これら各部／各手段のより詳細な構成は、次の第１の実施形態として説明する。

（第１の実施形態）
続いて、本発明の第１の実施形態の構成について添付図２〜３に基づいて説明する。
本実施形態に係る分散処理システム１００は、複数台のコンピュータ（マスターノード１０およびスレーブノード２０）が相互に接続され、これらのコンピュータによって分散バッチアプリ１２０を協調して分散実行する分散処理システムである。各コンピュータは、分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダ１１２と、各モジュールのうち初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部１１３と、記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部１１４と、分散バッチアプリを実行する実行コンテナ１１１とを備える。そしてファイル管理部１１４は、モジュールローダがメタデータによって初期化処理を行った後で当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから実行コードを読み込んでこれを実行領域として書き込む機能を備える。

またファイル管理部１１４は、メタデータのみのモジュールをファイルとして作成して、これをメタデータ管理部１１３によって他のコンピュータと共有する機能を備える。

さらに、複数台のコンピュータのうちの１台が分散バッチアプリの分散実行を管理するマスターノード１０であり、マスターノードを除く他のコンピュータがスレーブノード２０である。ここでマスターノード１０のファイル管理部１１４が、メタデータのみのモジュールをファイルとして作成して、これをスレーブノード２０に送信する機能を備える。

以上の構成を備えることにより、この分散処理システムは、実行時に各スレーブノードに転送するデータ容量を削減し、かつ分散処理を高速に開始することが可能なものとなる。
以下、これをより詳細に説明する。

図２は、本発明の第１の実施形態に係る分散処理システム１００の構成について示す説明図である。分散処理システム１００は、複数のコンピュータ装置がネットワーク３０を介して相互に接続されて構成されるものであり、その台数については特に制限はない。図２では、本発明の概念を平易に示すという意味で、マスターノード１０（分散処理装置）、スレーブノード２０ａおよび２０ｂ（分散処理装置）の３台についてのみ図示している。スレーブノード２０ａおよび２０ｂは、総称してスレーブノード２０という。

図３は、図２に示したマスターノード１０およびスレーブノード２０のより詳細な構成について示す説明図である。図３ではマスターノード１０について示しているが、スレーブノード２０についてもハードウェア的には同一の構成を有する。

マスターノード１０は、コンピュータプログラムを実行する主体であるプロセッサ１１、プログラムおよびデータを記憶する記憶手段１２、およびネットワーク３０と接続して他装置とのデータ通信を行う通信手段１３を備えている。マスターノード１０はこれ以外にも多くのハードウェア要素を備えているが、本発明について説明する上で必要のある要素についてのみここでは説明する。また、スレーブノード２０はマスターノード１０と同様のプロセッサ２１、記憶手段２２、および通信手段２３を備えている。

プロセッサ１１では、ＯＳ１０１（オペレーティングシステム）がまず動作し、これを前提として分散処理ミドルウェア１１０が動作する。分散処理ミドルウェア１１０は、実行コンテナ１１１、モジュールローダ１１２、メタデータ管理部１１３、ファイル管理部１１４といった各機能部を備えると共に、記憶手段２２をメタデータ共有部１１５とフォルダ１１６として機能させる。そして、分散処理ミドルウェア１１０の動作を前提として、分散バッチアプリ１２０が動作する。

スレーブノード２０ではマスターノード１０と同一の分散処理ミドルウェア１１０が動作するが、スレーブノード２０側ではメタデータ共有部１１５、フォルダ１１６、および記憶手段２２についてのみ図示することとする。ただし、後述のメタデータ管理部１１３およびファイル管理部１１４による他ノードからのメタデータ取得あるいはファイル読み書きは、スレーブノード２０側からマスターノード１０に対して同一の動作を行うことも可能である。また、スレーブノード２０ａおよび２０ｂの相互間で同一の動作を行うことも可能である。

実行コンテナ１１１は、分散バッチアプリ１２０を実行する。実行コンテナ１１１はまた、モジュールローダ１１２を利用して、分散バッチアプリ１２０のモジュールのロードやファイルの読み書きができる。

モジュールローダ１１２はモジュールや設定ファイルなどを読み込み、メタデータを解析してフォルダ１１６上に実行可能なように配置する。これはＪａｖａ言語でいうクラスローダ（ClassLoader）に相当するが、ここではそのクラスローダを拡張して、メタデータをフォルダ１１６にロードするタイミングや初期化処理の入れ替え、あるいは再初期化を動的に行うことも可能としたものである。

メタデータ管理部１１３はモジュールのメタデータの管理を行う。モジュールのメタデータをメタデータ共有部１１５またはファイル管理部１１４から取得してモジュールローダ１１２に提供する。またメタデータ管理部は他ノードのメタデータ共有部１１５からもメタデータを取得できる。

メタデータ共有部１１５は、ロードされたモジュールのメタデータを保存し、共有する機能を提供する。また保存したメタデータは他ノードからも参照できる機能を提供する。

ファイル管理部１１４は自ノード又は他ノードのフォルダ１１６上のファイルを管理して読み書きを行う。また、実際のモジュールファイルからメタデータのみのファイル作成や、他ノードのファイルの差分だけを読み書きする機能も有する。フォルダ１１６は、ファイル管理部１１４によって管理される記憶領域である。

図４は、図２〜３に示す分散処理システム１００で実行対象となる分散バッチアプリ１２０の構成について示す説明図である。分散バッチアプリ１２０は、複数のモジュール、設定ファイル、バイナリファイルなどによって構成される。各モジュールはメタデータと実行領域とによって構成される。メタデータは、各モジュール間の依存関係、初期化コマンドなどが格納される領域である。実行領域は、実際に実行するコードが格納される領域である。

分散バッチアプリ１２０は、第１〜３のステップ１２１〜１２３という動作ステップによって構成される。図４では、分散バッチアプリ１２０と、第１および第２のステップ１２１および１２２のメタデータと実行領域とを示している。

各ステップのうち、第１および第３のステップ１２１および１２３は、マスターノード１０のみで実行されるが、第２のステップ１２２は各スレーブノード２０との間で協調して分散処理を行う。以下、マスターノード１０の実行コンテナ１１１を「マスターコンテナ」、スレーブノード２０の実行コンテナ１１１を「スレーブコンテナ」という。

また、第１のステップ１２１のマスターノード１０で実行されるモジュールを第１のマスターモジュール１２１ａ（step1.class）、第２のステップ１２２のマスターノード１０で実行されるモジュールを第２のマスターモジュール１２２ａ（step2.class）、第２のステップ１２２のスレーブノード２０で実行されるモジュールをスレーブモジュール１２２ｂ（step2_slave.class）ということにする。

さらに、第２のマスターモジュール１２２ａおよびスレーブモジュール１２２ｂの実行には共有モジュール１２２ｃ（shared2.class）が必要である。

マスターノード１０に配備された分散バッチアプリ１２０を、実行コンテナ１１１（マスターコンテナ）がフォルダ１１６上に展開し、その展開されたフォルダにモジュールファイルや設定ファイルを各々保存する。

そして実行コンテナ１１１（マスターコンテナ）は、分散バッチアプリ１２０を起動するために、モジュールファイルのメタデータ（後述）をロード（Load）し、依存関係を解決して（Link）初期化（Initialize）を行う。ここで読み込まれたメタデータを、モジュールローダ１１２を経由してメタデータ管理部１１３が自らのメタデータ共有部１１５がフォルダ１１６に保存すると同時に、スレーブノード２０のメタデータ共有部１１５にも渡して保存させる。

まず第１のステップ１２１は、マスターノード１０の実行コンテナ１１１（マスターコンテナ）だけで実行される。これに続く第２のステップ１２２では、実行コンテナ１１１（マスターコンテナ）がスレーブノード２０に第２のステップ１２２のスレーブ実行を指示する。スレーブノード２０は実行コンテナ１１１（スレーブコンテナ）を立ち上げて、分散バッチアプリ１２０を起動する準備を行う。

スレーブノード２０は、第２のステップ１２２を実行するために必要なメタデータを、マスターノード１０のメタデータ共有部１１５から取得する。そしてメタデータのみのクラスファイルを作成して、フォルダ１１６に記憶する。スレーブノード２０の実行コンテナ１１１（スレーブコンテナ）は、このスレーブモジュール１２２ｂ（step2_slave.class）の処理を実行するメソッドを呼び出す。ただしここで呼び出されるメソッドには実際の実行コードは無く、ただ実行領域のロードを指示するものであるので、それを実行する。

即ち、スレーブノード２０の実行コンテナ１１１（スレーブコンテナ）は、スレーブモジュール１２２ｂ（step2_slave.class）の実行領域のデータをマスターノード１０のメタデータ共有部１１５から取得し、そこに書かれた内容に応じてフォルダ１１６の記憶領域のデータを再初期化し、そこにスレーブモジュール１２２ｂ（step2_slave.class）を書き込む。即ち、スレーブノード２０では、メタデータと実行領域が揃って、再初期化が行われたので、通常のアプリケーションの動作が可能な状態になる。そこでこのスレーブモジュール１２２ｂ（step2_slave.class）を実行する。スレーブノード２０ａおよび２０ｂで、以上の処理を同時に行う。

スレーブノード２０ａおよび２０ｂでは、マスターノード１０で既に実行されたデータを利用して、メタデータの取得およびロードを行うことが可能である。これにより、起動を高速に行うことが可能となる。また、実際に実行するコードが呼ばれてから、実行に必要なコードやデータを取得するので、実際に転送されるデータの分量が削減される。

図５〜６は、図２〜３に示す分散処理システム１００で、図４に示す分散バッチアプリ１２０を動作させる場合の処理について示すフローチャートである。図５〜６は、紙面の都合で２枚に分けて示している。まず実行コンテナ１１１（マスターコンテナ）が、分散バッチアプリ１．ｊａｒファイルを読み込み、その中の各モジュールおよび設定ファイルなどをフォルダ１１６に保存する（ステップＳ１０１）。

続いて実行コンテナ１１１（マスターコンテナ）が分散バッチアプリ１２０の設定ファイル１２０ａを読み込んで、当該分散バッチアプリ１２０を起動する（ステップＳ１０２）。ここでは、図１に示した通り、第１のステップ１２１から順番に、実行コンテナ１１１（マスターコンテナ）が実行していく。

実行コンテナ１１１（マスターコンテナ）は第１のステップ１２１を実行するために、モジュールローダ１１２に第１のマスターモジュール１２１ａ（step1.class）を読み込んで実行可能な状態とするよう指示し、モジュールローダ１１２はこれに応じて第１のマスターモジュール１２１ａ（step1.class）のメタデータを読み込む（ステップＳ１０３）。

モジュールローダ１１２はその際、メタデータ管理部１１３に第１のマスターモジュール１２１ａ（step1.class）の有無について問い合わせる。メタデータ管理部１１３はこれに応じて、マスターノード１０のメタデータ共有部１１５にメタデータがあるか否かについて調べる。この段階ではメタデータ共有部１１５にメタデータは存在しないので「存在しない」旨の回答をメタデータ管理部１１３がモジュールローダ１１２に返す（ステップＳ１０４）。

これを受けたモジュールローダ１１２は、ファイル管理部１１４に第１のマスターモジュール１２１ａ（step1.class）のメタデータをフォルダ１１６上のファイルから読み込むように指示する。ファイル管理部１１４はフォルダ１１６上から第１のマスターモジュール１２１ａ（step1.class）を探して、そのメタデータを読み込んでモジュールローダ１１２に返す。（ステップＳ１０５）。

続いてモジュールローダ１１２は、第１のマスターモジュール１２１ａ（step1.class）のメタデータをメモリに展開すると同時にメタデータ管理部１１３に通知する。メタデータ管理部１１３はそのメタデータをメタデータ共有部１１５に書き込む（ステップＳ１０６）。図７は、図５のステップＳ１０６までの処理が終わった状態でのメタデータ共有部１１５の状態について示す説明図である。

さらに続いてモジュールローダ１１２は、第１のマスターモジュール１２１ａ（step1.class）のメタデータを読み込み、メタデータの「依存関係」欄に必要な共有モジュールやスレーブモジュールが定義されている場合は、その定義に応じて必要なファイルを読み込むか、もしくは他装置に対して指示する（ステップＳ１０７）。本実施形態の場合、第１のマスターモジュール１２１ａでは依存関係は特に定義されていないので、ここでは特に何もせず「依存関係は解決した」側に進む。

そしてモジュールローダ１１２は仮初期化処理を行う（ステップＳ１０８）。実際には通常の第１のマスターモジュール１２１ａ（step1.class）の初期化処理を行わず、「<clinit>」その他全てのメソッドに「実行領域ロード指示」を呼び出すように、第１のマスターモジュール１２１ａ（step1.class）は予め定義されている。図８は、図４に示す分散バッチアプリ１２０で、「実行領域ロード指示」が定義されている第１のマスターモジュール１２１ａ（step1.class）について示す説明図である。

ここでいう「実行領域ロード指示」とは、モジュールローダ１１２に指定されたクラスの実行領域をロードして再初期化を行い、アプリが実行できる状態とするメソッドである。このようにして仮初期化を行い、通常の初期化処理を終了したことにする。なお、第１のステップ１２１は分散処理を伴わないので、後述のステップＳ１１５はここでは実行されない。

これで実行コンテナ１１１（マスターコンテナ）は第１のマスターモジュール１２１ａ（step1.class）の実行に入る。図８に示した通り、本実施例では実際の実行コードは「実行領域ロード指示」に置き換えられているので、実行コンテナ１１１（マスターコンテナ）はモジュールローダ１１２に実行領域を読み込むよう指示し、モジュールローダ１１２はファイル管理部１１４にクラスの実行領域を読み込むよう指示する（ステップＳ１０９）。

この指示を受けたファイル管理部１１４は、クラスファイルの実行領域が自ノードのフォルダ１１６にある場合は、そこのクラスファイルから実行領域を読み出す（ステップＳ１１０〜１１１）。もし、フォルダ１１６にクラスファイルがない、もしくは実行領域がない（メタデータのみのクラスファイル）であれば、他ノードにあるクラスファイルの実行領域を読み出す（ステップＳ１１０〜１１２）。

本実施例ではマスターノード１０のフォルダ１１６に展開された第１のマスターモジュール１２１ａ（step1.class）が存在するので、ファイル管理部１１４はその実行領域を読み出して、モジュールローダ１１２に通知する。

モジュールローダ１１２は実行領域をメインメモリに配置して、メタデータを書き換えて、再初期化を行い、メソッドを実行できる状態にする（ステップＳ１１３）。図９は、図５のステップＳ１１３までの処理が終了して、実行領域が書き換えられた状態の第１のマスターモジュール１２１ａ（step1.class）について示す説明図である。そして実行コンテナ１１１（マスターコンテナ）は、この状態の第１のマスターモジュール１２１ａ（step1.class）を実行して（ステップＳ１１４）、第１のステップ１２１に係る処理を終了する。

続いて、実行コンテナ１１１（マスターコンテナ）は第２のステップ１２２に係る処理に入る。即ち、第２のマスターモジュール１２１ａ（step2.class）に対して、ステップＳ１０１〜１０６と同様の処理を行う。

これに引き続いて、モジュールローダ１１２は第２のマスターモジュール１２１ａ（step2.class）のメタデータより依存関係を解決する処理を行う（ステップＳ１０７）。この第２のマスターモジュール１２１ａ（step2.class）のメタデータの「依存関係」欄は、スレーブモジュール１２２ｂ（step2_slave.class）と共有モジュール１２２ｃ（shared2.class）とに依存しているとあるので、これらをメタデータ共有部１１５から読み出そうとするが、存在しないのでファイル管理部１１４によって読み出してメタデータ共有部１１５に書き込む。

これで依存関係は解決したので、ステップＳ１０８に進んで第１のステップ１２１と同様に、全てのメソッドを「実行領域ロード指示」に置き換えた状態から仮初期化を行って実行する（ステップＳ１０８〜１１４）。図１０は、図４に示す分散バッチアプリ１２０で、「実行領域ロード指示」が定義されている第２のマスターモジュール１２２ａ（step2.class）について示す説明図である。この場合、スレーブモジュール１２２ｂ（step2_slave.class）と共有モジュール１２２ｃ（shared2.class）については、マスターノード１０側ではそのままである。

この第２のステップ１２２では、マスターノード１０とスレーブノード２０とが協調して分散並列処理を行う。そこでマスターノード１０の実行コンテナ１１１（マスターコンテナ）は、メタデータのみ（実行領域は「実行領域ロード指示」のみ）としたスレーブモジュール１２２ｂ（step2_slave.class）を作成し、スレーブノード２０に送付する（ステップＳ１１５）。図１１は、図５のステップＳ１１５の処理で作成されるメタデータのみのスレーブモジュール１２２ｂ（step2_slave.class）について示す説明図である。なお、マスターノード１０で作成されたこのメタデータのみのスレーブモジュール１２２ｂは、マスターノード１０側の記憶手段１２には保存されてもされなくてもよい。

これを受けたスレーブノード２０の実行コンテナ１１１（スレーブコンテナ）は、このスレーブモジュール１２２ｂ（step2_slave.class）に対して実行を開始し、ステップＳ１０１〜１０３と同様の処理を行う。スレーブモジュール１２２ｂ（step2_slave.class）のメタデータの「依存関係」欄では共有モジュール１２２ｃ（shared2.class）が必要となるので、メタデータ管理部１１３はマスターノード１０のメタデータ共有部１１５にそれらのモジュールがあるか否かについて調べる（ステップＳ１０１〜１０４）。

スレーブノード２０のモジュールローダ１１２は、メタデータ管理部１１３を介してマスターノード１０の第２のマスターモジュール１２１ａ（step2.class）、スレーブモジュール１２２ｂ（step2_slave.class）および共有モジュール１２２ｃ（shared2.class）のメタデータを取得する。本来なら、依存関係を解決する処理を行う必要があるが、それは既にマスターノード１０の処理によって解決されているので、マスターノード１０のメタデータ共有部１１５からこれらのモジュールを取得して（ステップＳ１０７）、これで「依存関係は解決」となる。

マスターノード１０のメタデータ共有部１１５から取得したメタデータを、スレーブノード２０のモジュールローダ１１２がフォルダ１１６上に展開して、マスターノード１０と同様に仮初期化を行う（ステップＳ１０８）。

スレーブノード２０の実行コンテナ１１１（スレーブコンテナ）はスレーブモジュール１２２ｂ（step2_slave.class）を呼び出すが、そのメタデータの中に「実行領域ロード指示」が含まれているので、スレーブノード２０のモジュールローダ１１２にその実行領域をロードするよう指示する（ステップＳ１０９）。

この指示を受けたスレーブノード２０のファイル管理部１１４は、スレーブモジュール１２２ｂ（step2_slave.class）は自らのフォルダ１１６に無いので、マスターノード１０のフォルダ１１６からクラスファイルの実行領域を読み出し、自らのフォルダ１１６に書き込む（ステップＳ１１３，１１６）。

スレーブノード２０のモジュールローダ１１２は実行領域をメインメモリに配置して、メタデータを書き換えて、再初期化を行い、メソッドを実行できる状態にする（ステップＳ１１３）。図１２は、図５のステップＳ１１３に示した処理が終了して実行領域を配置された状態のスレーブモジュール１２２ｂ（step2_slave.class）について示す説明図である。そして実行コンテナ１１１（スレーブコンテナ）は、この状態のスレーブモジュール１２２ｂ（step2_slave.class）を実行して（ステップＳ１１４）、第２のステップ１２２に係る処理を終了する。

第３のステップ１２３に係る処理は、第１のステップ１２１と同じようにマスターノード１０単体で実行される。以上で、分散バッチアプリ１２０の実行に係る処理は完了する。

（第１の実施形態の全体的な動作と効果）
次に、上記の実施形態の全体的な動作について説明する。
本実施形態に係る分散処理方法は、複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにある。分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータをメタデータ管理部が取得し（図５・ステップＳ１０１〜１０７）、メタデータによってモジュールローダが初期化処理を行い（図５・ステップＳ１０８）、初期化処理の後で、当該モジュールの実行コードを含む実行領域が記憶手段に存在するか否かをファイル管理部が調べ（図６・ステップＳ１０９〜１１０）、実行コードを含む実行領域が記憶手段に存在しない場合、ファイル管理部が他のコンピュータから実行コードを読み込んでこれを実行領域として書き込み（図６・ステップＳ１１０〜１１２，１１６）、実行コードを含む当該モジュールを実行コンテナが実行する（図６・ステップＳ１１３〜１１４）。

そして、初期化処理の後で、メタデータのみのモジュールをファイル管理部がファイルとして作成して、これをメタデータ管理部によって他のコンピュータと共有する（図５・ステップＳ１１５）。ここで、複数台のコンピュータのうちの１台が分散バッチアプリの分散実行を管理するマスターノードであり、マスターノードを除く他のコンピュータがスレーブノードであり、この処理は、初期化処理の後でメタデータのみのモジュールをマスターノードのファイル管理部がファイルとして作成して、これをスレーブノードに送信するというものである。

ここで、上記各動作ステップについては、これをコンピュータで実行可能にプログラム化し、これらを前記各ステップを直接実行するマスターノード１０およびスレーブノード２０が各々備えるプロセッサ１１および２１に実行させるようにしてもよい。本プログラムは、非一時的な記録媒体、例えば、ＤＶＤ、ＣＤ、フラッシュメモリ等に記録されてもよい。その場合、本プログラムは、記録媒体からコンピュータによって読み出され、実行される。
この動作により、本実施形態は以下のような効果を奏する。

本実施形態では、マスターノード１０からスレーブノード２０に、まずメタデータのみのモジュールファイルを送信するので、その段階で送信されるデータ量がまず削減される。そして、実際にスレーブノード２０でその実行処理が行われる際に、その実行コードをマスターノード１０から取得するので、実際にその処理を行わないスレーブノードに対して実行コードが送信されることはないので、大幅な送信データ量の削減が可能となる。

さらに、分散処理でスレーブノードが使用するメタデータは原則的に同一で、ただ処理対象データなどが異なるのみである。従って、多数のスレーブノード間で同一のメタデータを流用することができ、同一の初期化処理を毎回行う必要はないので、初期化を高速化することができる。また、分散処理では同一のスレーブノードで異なるデータに対する同一の処理を割り振る場合もありうるが、そのような場合でも同一のメタデータを流用することによって初期化を高速化するという効果を得ることができる。

本実施形態の拡張として、まず図５のステップＳ１０４〜１０５の処理は、メタデータ共有部１１５とファイル管理部１１４に対して同時にメタデータを読み込ませ、先に読み取れた方のメタデータを利用するものとしてもよい。これによって読み取りの高速化の効果を期待することができ、また、いずれか一方が読み取りエラーとなっても他方から読み取りできればよいので耐障害性の効果も期待できる。

これと同様に、メタデータと実行領域を同時に読み取るようにしてもよい。また、メタデータを自ノードから、実行領域を他ノードから、それぞれ読み取るようにしてもよい。

一方、Ｊａｖａ言語では、クラスファイルは固定文字列は必ずメタデータの中に含まれる決まりとなっているが、仮初期化にはこの固定文字列データは使用されない。従って、固定文字列を含まないメタデータをマスターからスレーブにまず配布し、実行領域の実行コード取得と同時に固定文字列データを取得するようにしてもよい。これによって、さらに送信データ量の削減を期待できる。

また、図５のステップＳ１０４〜１０８の処理では、マスターノード１０からメタデータを読み込んで、ローカルフォルダにメタデータのみのファイルを書き出しているが、これと同時にローカルのメタデータ共有部１１５に書き込んでもよい。たとえば、スレーブノード２０で実行エラーが生じて再起動する場合に、同一ノード上のメタデータ共有部１１５から再びメタデータを読み取ることができるので、ロードおよび再初期化の処理を高速に行うことが可能になる。

（第２の実施形態）
本発明の第２の実施形態に係る分散処理システム２００は、第１の実施形態で示した構成に加えて、各コンピュータから共通して参照可能な分散共有メモリ２３０を備えると共に、メタデータ管理部３１３がメタデータによって参照される共通ファイルを分散共有メモリ２３０に記憶させる機能を備えたものとした。

この構成によっても第１の実施形態と同じ効果が得られるのに加えて、異なる処理で同一のメタデータを利用して、処理をさらに高速にすることが可能となる。
以下、これをより詳細に説明する。

図１３は、本発明の第２の実施形態に係る分散処理システム２００の構成について示す説明図である。分散処理システム２００は、前述した第１の実施形態と同様に、複数のコンピュータ装置が相互に接続されて構成されるものである。ただし、複数のマスターノードによって制御される異なる処理が、同一の分散処理システムの中で並行して実行されるという例を、ここでは示すことにする。

従って、図１３ではマスターノード２１０ａおよび２１０ｂ（総称してマスターノード２１０という）、およびスレーブノード２２０の３台についてのみ図示している。さらに、マスターノード２１０およびスレーブノード２２０のいずれからでも共通してアクセスして内容を参照することが可能である分散共有メモリ２３０も、同時に各装置に接続されている。もちろんマスターノード２１０およびスレーブノード２２０の台数について、特に制限はない。また、分散共有メモリ２３０は、実際にはＮＡＳ（Network Attached Storage）などのようなネットワークに接続された外部記憶装置などによって実現可能であるが、具体的な装置の形態については特に制限はない。

図１４は、図１３に示したマスターノード２１０およびスレーブノード２２０のより詳細な構成について示す説明図である。マスターノード２１０およびスレーブノード２２０はいずれも、ハードウェア的には第１の実施形態のマスターノード１０およびスレーブノード２０と同一の構成を有する。従って、同一の要素については同一の呼称および参照番号でいい、詳細な説明は特に割愛することとする。

プロセッサ１１（２１）では、ＯＳ１０１がまず動作し、これを前提として第１の実施形態とは別の分散処理ミドルウェア３１０が動作する。分散処理ミドルウェア３１０は、実行コンテナ３１１、モジュールローダ３１２、メタデータ管理部３１３、ファイル管理部３１４といった各機能部を備える。そして、前述の分散共有メモリ２３０をメタデータ共有部３１５として機能させ、記憶手段１２（２２）をフォルダ３１６として機能させる。

分散処理ミドルウェア３１０の各機能部の動作は、原則として第１の実施形態の分散処理ミドルウェア１１０の各機能部の動作と同一である。ただし、メタデータ共有部３１５は分散共有メモリ２３０上にあるので、異なる分散バッチアプリを動作させている各ノードから共通して内容を参照することが可能である。この分散処理ミドルウェア３１０の動作を前提として、分散バッチアプリ３２０および３３０が動作する。

図１５は、図１３〜１４に示した分散処理システム２００で動作する分散バッチアプリ３２０および３３０の構成について示す説明図である。分散バッチアプリ３２０は、第１の実施形態で説明した分散バッチアプリ１２０と同じく、第１〜３のステップ３２１〜３２３という動作ステップによって構成される。分散バッチアプリ３３０も同様に、第１〜３のステップ３３１〜３３３という動作ステップによって構成される。

ここで、分散バッチアプリ３２０の第１のステップ３２１のマスターノード２１０ａで実行されるモジュールを第１のマスターモジュール３２１ａ（step11.class）、第２のステップ３２２のマスターノード２１０ａで実行されるモジュールを第２のマスターモジュール３２２ａ（step12.class）、第２のステップ３２２のスレーブノード３２０で実行されるモジュールをスレーブモジュール３２２ｂ（step12_slave.class）ということにする。第３のステップ３２３以降については、説明する必要は特にないので記載を省略する。

同様に、分散バッチアプリ３３０の第１のステップ３３１のマスターノード２１０ｂで実行されるモジュールを第１のマスターモジュール３３１ａ（step21.class）、第２のステップ３３２のマスターノード２１０ｂで実行されるモジュールを第２のマスターモジュール３３２ａ（step22.class）ということにする。

そして、第２のステップ３３２のスレーブノード２２０で実行されるスレーブモジュール３３２ｂ（step22_slave.class）は、分散バッチアプリ３２０と同一の共有モジュール３２２ｃ（shared02.class）を利用する。スレーブモジュール３２２ｂ（step12_slave.class）、および第３のステップ３３３以降については、説明する必要は特にないので記載を省略する。

この分散処理システム２００で分散バッチアプリ３２０および３３０を動作させる場合、第１のステップ３２１および３３１までは第１の実施形態と同様の動作となる。即ち、マスターノード２１０ａが分散バッチアプリ３２０を動作させると、メタデータ共有部３１５に共有モジュール３２２ｃ（shared02.class）のメタデータが記憶される。続いて、マスターノード２１０ｂが分散バッチアプリ３３０を動作させると、共有モジュール３２２ｃ（shared02.class）のメタデータは既に記憶されているので、これを共通して利用することができる。

図１６〜１７は、図１３〜１４に示す分散処理システム２００で、図１５に示す分散バッチアプリ３２０および３３０を動作させる場合の処理について示すフローチャートである。図１６〜１７は、紙面の都合で２枚に分けて示している。図１６〜１７のフローチャートで示された各動作は、基本的に図５〜６に示した第１の実施形態と同一であるので、同一の動作については同一の参照番号を付している。唯一の相違点は、メタデータを書き込むメタデータ共有部３１５が分散共有メモリ２３０にあるという点のみである（ステップＳ２０６）。

図１８は、分散バッチアプリ３２０の動作が完了した状態のメタデータ共有部３１５について示す説明図である。図１９は、分散バッチアプリ３２０の動作の後で分散バッチアプリ３３０の動作が完了した状態のメタデータ共有部３１５について示す説明図である。

図１８で示した通り、この段階のメタデータ共有部３１５には分散バッチアプリ３２０を構成する第１のマスターモジュール３２１ａ（step11.class）、第２のマスターモジュール３２２ａ（step12.class）、スレーブモジュール３２２ｂ（step12_slave.class）と共有モジュール３２２ｃ（shared02.class）が記憶されている（第３のステップ以降については記載を省略する。）。

そして、その後で分散バッチアプリ３３０を動作させると、メタデータ共有部３１５には分散バッチアプリ３３０を構成する第１のマスターモジュール３３１ａ（step21.class）、第２のマスターモジュール３３２ａ（step22.class）、スレーブモジュール３３２ｂ（step22_slave.class）が記憶されているが、共有モジュール３２２ｃ（shared02.class）は図１８で示した段階のものが共通して使用可能である。この動作は、他ノードにそのモジュールの有無について照会する必要がないので、高速に行える。

以上で説明した通り、本実施形態によれば、異なるジョブを行う複数の分散バッチアプリの相互間でメタデータの重複を少なくして共有化することが可能となる。従って、アプリケーション配備や初期化をさらに効率的なものとすることができる。さらに、他ノードにメタデータの有無について照会する必要もなくなるので、どのノードにそのメタデータがあるかを検索する必要もなくなり、障害の発生したノードがあったとしても該ノードのためにメタデータの取得が失敗することもなくなる。

本実施形態の拡張として、マスターノードおよびスレーブノードがいずれも、自らのコンテナで読み取ったメタデータをメタデータ共有部１１５に登録するようにしてもよい。たとえばマスターノードで読み取られず、スレーブノードで読み取られたメタデータがあっても、他の分散バッチアプリでマスターノードや他のスレーブノードがこれを利用する可能性があるからである。

これまで本発明について図面に示した特定の実施形態をもって説明してきたが、本発明は図面に示した実施形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができる。

上述した実施形態について、その新規な技術内容の要点をまとめると、以下のようになる。なお、上記実施形態の一部または全部は、新規な技術として以下のようにまとめられるが、本発明は必ずしもこれに限定されるものではない。

（付記１） 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムであって、
前記各コンピュータが、前記分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、前記各モジュールのうち前記初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、前記記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、前記分散バッチアプリを実行する実行コンテナと
を備えると共に、
前記ファイル管理部が、前記モジュールローダが前記メタデータによって前記初期化処理を行った後で当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む機能を備えたこと、を特徴とする分散処理システム。

（付記２） 前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有する機能を備えたこと、を特徴とする付記１に記載の分散処理システム。

（付記３） 前記複数台のコンピュータのうちの１台が前記分散バッチアプリの分散実行を管理するマスターノードであり、前記マスターノードを除く他のコンピュータがスレーブノードであると共に、
前記マスターノードの前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記スレーブノードに送信する機能を備えたこと、を特徴とする付記２に記載の分散処理システム。

（付記４） 前記各コンピュータから共通して参照可能な分散共有メモリを備えると共に、前記メタデータ管理部が前記メタデータによって参照される共通ファイルを前記分散共有メモリに記憶させる機能を備えたこと、を特徴とする付記１に記載の分散処理システム。

（付記５） 複数台が相互に接続されることによって分散バッチアプリを協調して分散実行する分散処理システムを構成する分散処理装置であって、
前記分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、
前記各モジュールのうち前記初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、
前記記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、
前記分散バッチアプリを実行する実行コンテナと
を備えると共に、
前記ファイル管理部が、前記モジュールローダが前記メタデータによって前記初期化処理を行った後で当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む機能を備えたこと、を特徴とする分散処理装置。

（付記６） 前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有する機能を備えたこと、を特徴とする付記５に記載の分散処理装置。

（付記７） 前記メタデータ管理部が前記メタデータによって参照される共通ファイルを前記各コンピュータから共通して参照可能な分散共有メモリに記憶させる機能を備えたこと、を特徴とする付記５に記載の分散処理装置。

（付記８） 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、
前記分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータをメタデータ管理部が取得し、
前記メタデータによってモジュールローダが初期化処理を行い、
前記初期化処理の後で、当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かをファイル管理部が調べ、
前記実行コードを含む実行領域が前記記憶手段に存在しない場合、前記ファイル管理部が他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込み、
前記実行コードを含む当該モジュールを実行コンテナが実行すること、を特徴とする分散処理方法。

（付記９） 前記初期化処理の後で、前記メタデータのみの前記モジュールを前記ファイル管理部がファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有すること、を特徴とする付記８に記載の分散処理方法。

（付記１０） 前記複数台のコンピュータのうちの１台が前記分散バッチアプリの分散実行を管理するマスターノードであり、前記マスターノードを除く他のコンピュータがスレーブノードであると共に、
前記初期化処理の後で、前記メタデータのみの前記モジュールを前記マスターノードのファイル管理部がファイルとして作成して、これを前記スレーブノードに送信すること、を特徴とする付記９に記載の分散処理方法。

（付記１１） 前記各コンピュータから共通して参照可能な分散共有メモリを備えると共に、前記メタデータ管理部が前記メタデータによって参照される共通ファイルを前記分散共有メモリに記憶させること、を特徴とする付記８に記載の分散処理方法。

（付記１２） 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、
前記コンピュータに、
前記分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータを取得する手順、
前記メタデータによって初期化処理を行う手順、
前記初期化処理の後で、当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べる手順、
前記実行コードを含む実行領域が前記記憶手段に存在しない場合、他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む手順、
および前記実行コードを含む当該モジュールを実行する手順
を実行させること、を特徴とする分散処理プログラム。

（付記１３） 前記初期化処理の後で、前記メタデータのみの前記モジュールをファイルとして作成して、これを他のコンピュータと共有する手順をさらに実行させること、を特徴とする付記１２に記載の分散処理プログラム。

この出願は２０１３年５月３１日に出願された日本出願特願２０１３−１１５５２７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、分散処理を行うコンピュータネットワークにおいて幅広く利用可能である。特に、その分散処理が大規模になればなるほど、通信容量の削減と処理の高速化において優れた効果を発揮するものである。

１、１００、２００ 分散処理システム
２、２ａ、２ｂ コンピュータ
３、１１２ モジュールローダ
４、１１３ メタデータ管理部
５、１１４ ファイル管理部
６、１１１ 実行コンテナ
１０、２１０、２１０ａ、２１０ｂ マスターノード
１１、２１ プロセッサ
１２、２２ 記憶手段
１３、２３ 通信手段
２０、２０ａ、２０ｂ、２２０ スレーブノード
３０ ネットワーク
１０１ ＯＳ
１１０、３１０ 分散処理ミドルウェア
１１１、３１１ 実行コンテナ
１１２、３１２ モジュールローダ
１１３、３１３ メタデータ管理部
１１４、３１４ ファイル管理部
１１５、３１５ メタデータ共有部
１１６、３１６ フォルダ
１２０、３２０、３３０ 分散バッチアプリ
１２０ａ 設定ファイル
１２１、３２１ 第１のステップ
１２１ａ、３２１ａ 第１のマスターモジュール
１２２、３２２ 第２のステップ
１２２ａ、３２２ａ 第２のマスターモジュール
１２２ｂ、３２２ｂ スレーブモジュール
１２２ｃ、３２２ｃ 共有モジュール
１２３、３２３ 第３のステップ
１２３ａ、３２３ａ 第３のマスターモジュール
２３０ 分散共有メモリ

Claims (10)

1. 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムであって、
   前記各コンピュータが、前記分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、前記各モジュールのうち前記初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、前記記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、前記分散バッチアプリを実行する実行コンテナと
   を備えると共に、
   前記ファイル管理部が、前記モジュールローダが前記メタデータによって前記初期化処理を行った後で当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む機能を備えたこと、を特徴とする分散処理システム。
2. 前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有する機能を備えたこと、を特徴とする請求項１に記載の分散処理システム。
3. 前記複数台のコンピュータのうちの１台が前記分散バッチアプリの分散実行を管理するマスターノードであり、前記マスターノードを除く他のコンピュータがスレーブノードであると共に、
   前記マスターノードの前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記スレーブノードに送信する機能を備えたこと、を特徴とする請求項２に記載の分散処理システム。
4. 前記各コンピュータから共通して参照可能な分散共有メモリを備えると共に、前記メタデータ管理部が前記メタデータによって参照される共通ファイルを前記分散共有メモリに記憶させる機能を備えたこと、を特徴とする請求項１に記載の分散処理システム。
5. 複数台が相互に接続されることによって分散バッチアプリを協調して分散実行する分散処理システムを構成する分散処理装置であって、
   前記分散バッチアプリを構成する各モジュールを読み込んで初期化処理を行うモジュールローダと、
   前記各モジュールのうち前記初期化処理のコマンドを含むメタデータを予め備えられた記憶手段もしくは他のコンピュータから取得するメタデータ管理部と、
   前記記憶手段もしくは他のコンピュータにあるファイルを読み書きするファイル管理部と、
   前記分散バッチアプリを実行する実行コンテナと
   を備えると共に、
   前記ファイル管理部が、前記モジュールローダが前記メタデータによって前記初期化処理を行った後で当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べ、存在しない場合は他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む機能を備えたこと、を特徴とする分散処理装置。
6. 前記ファイル管理部が、前記メタデータのみの前記モジュールをファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有する機能を備えたこと、を特徴とする請求項５に記載の分散処理装置。
7. 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、
   前記分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータをメタデータ管理部が取得し、
   前記メタデータによってモジュールローダが初期化処理を行い、
   前記初期化処理の後で、当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かをファイル管理部が調べ、
   前記実行コードを含む実行領域が前記記憶手段に存在しない場合、前記ファイル管理部が他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込み、
   前記実行コードを含む当該モジュールを実行コンテナが実行すること、を特徴とする分散処理方法。
8. 前記初期化処理の後で、前記メタデータのみの前記モジュールを前記ファイル管理部がファイルとして作成して、これを前記メタデータ管理部によって他のコンピュータと共有すること、を特徴とする請求項７に記載の分散処理方法。
9. 前記複数台のコンピュータのうちの１台が前記分散バッチアプリの分散実行を管理するマスターノードであり、前記マスターノードを除く他のコンピュータがスレーブノードであると共に、
   前記初期化処理の後で、前記メタデータのみの前記モジュールを前記マスターノードのファイル管理部がファイルとして作成して、これを前記スレーブノードに送信すること、を特徴とする請求項８に記載の分散処理方法。
10. 複数台のコンピュータが相互に接続され、これらのコンピュータによって分散バッチアプリを協調して分散実行する分散処理システムにあって、
    前記コンピュータに、
    前記分散バッチアプリを構成する各モジュールのうち初期化処理のコマンドを含むメタデータを取得する手順、
    前記メタデータによって初期化処理を行う手順、
    前記初期化処理の後で、当該モジュールの実行コードを含む実行領域が前記記憶手段に存在するか否かを調べる手順、
    前記実行コードを含む実行領域が前記記憶手段に存在しない場合、他のコンピュータから前記実行コードを読み込んでこれを前記実行領域として書き込む手順、
    および前記実行コードを含む当該モジュールを実行する手順
    を実行させること、を特徴とする分散処理プログラム。

Images