JP2008027442A - サブタスク・プロセッサの分散スケジューリング - Google Patents

Abstract

【課題】複数のプロセッサに計算タスクを分散させる分散コンピューティング方法の提供。
【解決手段】ローカル・ノードにタスクを生成するステップと処理タスクを１以上のサブタスクに分割するステップと、ローカル・ノードからアクセス可能なノード群においてサブタスク群を実行させるのに関連するパラメータの少なくとも一部に基づいて、前記１以上のサブタスクを実行するための最適ノード数ｘを判定するステップと、ｘに基づいて、ローカル・ノードで前記タスクを実行するか、ローカル・ノードからアクセス可能な１以上の分散ノードに前記タスクを分散させるかを判定するステップと、を備える。
【選択図】図２

Description

本実施例は、分散コンピューティングに関連し、より詳細には、複数のプロセッサに計算タスクを分散させるための技術に関する。

複数処理を同時実行可能なシステムの開発により、電子計算技術は大きく進歩した。このようなシステムによる処理は、並列処理とよばれる。計算タスクの多くは、相互に依存する「サブタスク群」と考えることができる。ローカル・プロセッサやリモート・プロセッサの間にタスクを分散させて並列処理できるように、こういったサブタスクを実装してもよい。
Lisa Cingiser et al.,、「Global Scheduling and Binding in a Real-Time Embedded Distributed System」、 Proceedings of the Real-Time & Embedded DOC 、2002.7、［online］、インターネット＜URL：http://rtdoc.cs.uri.edu/downloads/dre_workshop02.pdf＞

本発明の実施例は、このような文脈の中において示されるものである。

本発明の教示するところは、添付図面とあわせて以下の詳細な説明を考慮することにより容易に理解されるでろう。
以下の記述においては、例示のために多くの特定的な詳細を含むけれども、本発明の範囲内において、以下の詳細について多くの変形や変更が可能であることは、当業者には理解されるところである。したがって、下記に示す本発明の実施例は、請求項に記載の発明の一般性を失わせるものでも制約を設けるものでもない。

本発明の実施例は、図１と図２を参照することによって理解されるところである。図１は、本発明の実施例の実装例としてのシステム１００である。図２は、例として、図１のシステム１００により実装される処理過程２００のフローチャートである。システム１００は、通常、ローカル・プロセッサ・ノード１０２を含み、このノードは、以下において「分散ノード（distributed node）」とよばれる１以上の他プロセッサと接続可能である。プロセッサ・ノード１０２は、通常、１以上の個別のプロセッサ・ユニット１０４を含み、メモリ１０６を含んでもよい。制約的な意味ではない例として、プロセッサ・ユニット１０４は、１以上のＣＥＬＬプロセッサ・ユニットを含んでもよい。各ＣＥＬＬプロセッサ・ユニットは、ＰＵ（Power Processing Unit）と１以上のＳＰＵ（Synergistic Processor Unit(s)）を含んでもよい。各ＳＰＵは、対応ローカルメモリを有する。各プロセッサ・ユニット１０４を「ノード」と捉えてもよい。同様にして、プロセッサ・ユニット１０４内の各プロセッサ要素、たとえば、ＰＵやＳＰＵをノードとみなしてもよい。ＰＵとＳＰＵは、バス１０８を介して互いに接続される。

プロセッサ・ユニット１０４は、ローカルな分散ノード、たとえば、ローカル・ノード１０２内の他のプロセッサ・ユニット１０４と、Ｉ／Ｏ（Input/Output）要素１１０や「ブレード（blade）」とも呼ばれるデータバス１１２等を介してデータや命令を送受する。プロセッサユニット１０４は、ＰＣＩ（Peripheral Component Interconnect）データバス、あるいは、ＰＣＩＥ（PCI Express）データバスといったローカル・データバス１１４やＩ／Ｏ要素１１０を介して、他のローカルな分散プロセッサ・ノード１０３と通信してもよい。ローカル・プロセッサ・ノード１０３は、複数のプロセッサ・ユニット１０５、Ｉ／Ｏ要素１０７および内部データバス１０９を含む。ローカル・プロセッサ・ノード１０２のプロセッサ・ユニット１０４は、リモートの分散プロセッサ・ノード１１６と、１以上のネットワーク１２０やＩ／Ｏ要素１１０などと接続されるネットワーク・インタフェース１１８を介して通信してもよい。リモートの各分散プロセッサ・ノード１１６も複数のプロセッサ１１７を含むが、これは上記した通りに構成されてもよい。

ネットワーク１２０には、１以上のローカル・エリア・ネットワークや１以上のワイド・エリア・ネットワークが含まれてもよい。ここでいうローカル・エリア・ネットワーク（ＬＡＮ：Local Area Network）とは、たとえば、単一ビルやビル群といった比較的狭い範囲のコンピュータ・ネットワークを意味する。ＬＡＮにおける各ノード（個々のデバイス）は、通常、プログラムを実行するための１以上のプロセッサを有する。ＬＡＮ内であれば、各ノードはどこのデータやデバイスにもアクセスできるとしてもよい。ＬＡＮは、電話線や電波などを介して、どんなに遠くにある他のＬＡＮとも接続できる。こうして接続されるＬＡＮシステムは、ワイド・エリア・ネットワーク（ＷＡＮ：Wide-Area Network）とよばれる。インターネットもＷＡＮの一種である。ネットワークの実装においては、クライアント／サーバ（Client/Server）・アーキテクチャやピア・ツー・ピア（Ｐ２Ｐ：Peer-to-Peer）・アーキテクチャなど、適切なアーキテクチャを採用すればよい。Ｐ２Ｐ・アーキテクチャでは、各ノードは能力と責任において立場が等しい。これは、いずれかのノードが他のノードにサービスを提供するクライアント／サーバ・アーキテクチャとは異なる。

各プロセッサ・ユニット１０４は、符号命令群１２２の実行によって動作する。符号命令群１２２は、タスクのセットに分割されてもよい。ローカル・プロセッサ・ノード１０２（あるいは、ローカル・プロセッサ・ノード１０２内のプロセッサ・ユニット１０４）によって実行される処理タスクの多くは、更に、相互に依存するサブタスクに分割されてもよい。サブタスクは並列実行されてもよい。符号命令群１２２には、ローカル・プロセッサ・ノード１０２がアクセス可能な複数のプロセッサにサブタスクを分散させる分散スケジューラが含まれる。分散スケジューラは、ハードウェア、ソフトウェア、ファームウェア、あるいはこれら２以上の組み合わせにより実装されればよい。分散スケジューラの鍵となる処理は、利用可能な計算リソースにサブタスクを分散すべきか、また、どのように分散させるかを決定することである。

ノード数ｘは、利用可能なリソースと要求の性質の両方を示すリソース量ベクトルに基づいて決定されてもよい。このベクトルは、たとえば、プロセッサのサイクル（周期）、メモリの大きさ、（ハードディスクなどの）ストレージの大きさ、タスクを処理する上で必要とされるネットワーク帯域幅といったパラメータを含んでもよい。分散ノード群の利用可能性は、ミドルウェアによって推定される。即時利用性、平均的な利用性、予測される利用性等を考慮してもよい。アプリケーションは、タスクが必要とするリソースをラフに見積もってもよい。

図２は、処理タスクを他に分散させる処理過程２００のフローチャートである。ブロック２０２において、リソース量ベクトルに関わるパラメータが収集される。たとえば、符号１２２は、アプリケーションのバックグラウンドで走り、処理タスクの分散要否や分散方法の決定に関わるパラメータについての情報を収集するリソース上書きルーチンを含んでもよい。このようなパラメータは、所与のノードにおけるタスクの実行時間に限らず、サブタスク間で分割されるデータのサイズ、各サブタスクに必要なコードやデータのサイズ、タスクが生成する出力データのサイズ、１以上のノードについての出入力の帯域幅、分散ノードへのラウンド・トリップ・メッセージ（round-trip message）時間（往復遅延時間）、プロセッサの利用可能性やプロセッサの使用方法（usage）等を含んでもよい。

ブロック２０４において、パラメータは、パラメータテーブル２０５に保存されてもよい。パラメータテーブル２０５は、ローカル・ノード１０２によってアクセス可能なメモリに保持されてもよい。たとえば、パラメータテーブル２０５は、ローカル・ノード１０２のメインメモリ１０６に保持されるデータベースＤＢ（Database）の一部であってもよい。新しいタスクを待っているときにも条件変更が発生するので、パラメータテーブル２０５は時々更新されてもよい。ブロック２０６にてローカル・プロセッサ・ノード１０２がタスクを新規生成するときに、タスク処理の分散要否が判定される。つまり、ブロック２０８に示すようにタスクを１以上のサブタスクに分割してもよい。その後、ブロック２１０に示すように、１以上のサブタスクを実行するのに最適なノード数ｘが決定されてもよい。ノード数ｘは、少なくとも、ローカル・ノードがアクセス可能なノードにおけるサブタスク実行に関するパラメータの少なくとも一部、たとえば、パラメータテーブル２０５に保持されるパラメータに基づく。多くのタスクが、入力データやコード等を同じくする同種のサブタスクを複数含む可能性があることは重要である。また、時間経過と共に、リソースやパラメータが変化する可能性があることも重要である。このため、パラメータを再収集するためにブロック２０２に戻ることは意味がある。これにより、ブロック２１０において次の同種サブタスクにとっての最適ノード数ｘを決定する前に、リソースやパラメータが変化していないかチェックできる。

ブロック２１２においては、ｘ値に基づいて、タスクをローカル・ノード１０４において実行するか、ローカル・ノードからアクセス可能な１以上の分散ノードにタスクを分散させるかを判定してもよい。分散させる意味がないとき、たとえば、ｘ＝１で、ローカルな処理の方が高速であり、ローカル処理用のリソースを利用できるときには、ブロック２１４に示すようにタスクはローカルに処理される。

ブロック２１２において、たとえば、ｘ＞１となり、他の基準も満たされ、分散させる意味があると判定されたときには、タスク（あるいは、サブタスク）は、１以上の分散ノードで実行されるように配置されてもよい。分散の本質は、ｘ値と利用可能なノード数に依存する。たとえば、ｘ個のノードが利用可能であれば、ブロック２１６に示すように、タスク（あるいは、サブタスク）はｘ個の分散ノードに送出されて処理される。ｘ個未満のノードしか利用可能でないときには、ブロック２１８に示すように、タスクは利用可能なノードにあわせて分けられてもよい。たとえば、特定のタスクを処理するにはｘ＝２０個のノードが最適であると判定されたが、１０個のノードしか利用可能ではないとする。この場合、タスクは２分割されてもよい。仕事（work）の半分は１０個の利用可能なノードに割り当てられ、残りは他のノードが利用可能となったときにそれらに割り当てられてもよい。

多くの場合、タスクの分散可否や分散方法の決定は、分散ノードへのデータ転送に利用可能な帯域幅に依存する。利用可能な帯域幅は、データ転送経路の性質に依存するかもしれない。たとえば、ローカルノード１０４に接続されるデータバス１０８、１１２、１１４やネットワーク１２０は、お互いに帯域幅が異なるかもしれない。ここでいう「帯域幅」とは、通常、所定時間における情報の伝送率を意味する。デジタルデータの帯域幅は、通常、１秒当たりのビット数やバイト数によって表現される。たとえば、ＣＥＬＬプロセッサでは、ＳＰＵ間におけるデータ転送の帯域幅は、１秒あたり約１００ギガバイト（GByte/s）となるかもしれない。ＳＰＵからメモリ１０６へのデータ転送の帯域幅は、約２０GByte/sとなるかもしれない。「ブレード」を介したＣＥＬＬ間のデータ転送は、約３０GByte/sの帯域幅を持つかもしれない。ＰＣＩＥなどのローカル・バス１１２は、２０GByte/sの帯域幅を有するかもしれない。ＬＡＮの帯域幅は、おおよそ１０（MByte/s）から１０（GByte/s）の範囲となるかもしれない。インターネットのようなＷＡＮの帯域幅は、おおよそ１２８（KByte/s）から１０（MByte/s）の範囲となるかもしれない。

ブロック２１２におけるタスク分散可否、ブロック２１６におけるタスク分散方法の判定は、タスクのタイプにも依存するかもしれない。本実施例における分散コンピューティングにより、多くの異なるタイプのデータ処理タスクやサブタスクが実装されてもよい。各サブタスクは、サブタスクタイプによって特徴づけられるかもしれない。サブタスクタイプは、あるタイプのサブタスクと別のタイプのサブタスクを識別し、最適ノード数ｘや、利用可能ノード群におけるタスクやサブタスクの分配方法を決定するための情報を提供するものである。このようなタスクやサブタスクのタイプは、複合開始終了タスク（Complex start-to-finish tasks）に限らず、Ｎ分割可能タスク（Divisible-by-N tasks）、内部通信永続タスク（Intercommunicative persistent tasks）、ステートレス永続タスクやサービス（Stateless persistent tasks or services）などを含む。

複合開始終了タスクでは、タスクの依存関係や必要なデータ／コードが静的タスクファイルに記述される。最適なプロセッサ数は、静的に、タスクファイルにより決定されてもよい。一つの決定方法は、静的に、最適な分散タスクを決定することである。別の決定方法は、スレッドプールとして割り当てられているプロセッサを使ってタスクを動的に実行させることである。プロセッサはタスクを終了させると、タスクマスタ（task master）に通知して、次のタスクを待機する。バイトサイズや目的ノードの帯域幅が既知であれば、コードやデータリソースをプリフェッチ（先取得）しておいてもよい。各サブタスクの実行時間の推定がされていない場合には、タスク開始時に全サブタスクについてプリフェッチしておいてもよい。

Ｎ分割可能タスクは、利用可能なリソースの数だけ分割できるタスクである。タスクの「１ノード実行時間（one-node-execution-time）」が既知であるならば、タスク実行のために使用すべき最適ノード数Ｎを求めるための方程式が導かれる。方程式においては、帯域幅や分配方法（線形型／サーバと対数型／Ｐ２Ｐ）といった要素を加味してもよい。Ｎ分割可能タスクは、多くの異なるタスクタイプに分かれるかもしれない。あるタスクタイプでは、同一データが全ノードに送信される。こういったタスクタイプの一例として、レイ・トレーシング・タスクを挙げることができる。別のタスクタイプでは、データの一部が各ノードに送信される。こういったタスクタイプの一例として、ＳＥＴＩ（Search for Extra-Terrestrial Intelligence）プロジェクトを挙げることができる。Ｎ分割可能タスクの場合、配置された各タスクは、［０，Ｎ）の範囲の一意のインデックスとＮにより初期化される。Ｎは、実際に配置済となるプロセッサの数である。各タスクに必要なデータは、適切な方式にて分配される。複雑な階層タスク群において並列するサブタスク群は、このカテゴリに適合するかもしれない。

内部通信永続タスク（相互永続タスク（persistent interactive tasks）ともよばれる）においては、タスクと同じ数のプロセッサが割り当てられる。タスクは、自由に実行や通信を開始できる。この環境においては、複雑な階層タスク群は、全サブタスクをあらかじめ割り当てた上で、メッセージを送出することにより実行ステージを進めてもよい。さまざまなノードやプロセッサに並列タスクが割り当てられる限り、（より良いということはないかもしれないが）同じパフォーマンスを実現できる。とりわけ、サーバやゲームオブジェクトは、内部通信永続タスクの数少ない例である。

ステートレス永続タスクやサービスは、入出力を有するが状態（state）を有さないグローバル関数である。これらのタスクは汎用的であるため、ロードバランスのために複数のノードに余分に複製されてもよい。ステートレス永続タスクは、利用可能なノードであればどこで実行されてもよい。このタスクタイプには、なんらかの分散スケジューリングが内包される。たとえば、何個のノードｘにタスクを分散させるかを決定するブロック２１０や、タスクの分散方法を決定するブロック２１６、２１８において、過負荷時にタスクをどのように複製するか知っておくことは有用かもしれない。更に、タスク分配方法をブロック２１６や２１８で決定するためには、使用率や位置（locality）といった要素も有用かもしれない。

上記に一覧した処理タスクを含む処理タスク群は、更に、２つのカテゴリのいずれかに分類されてもよい。一つは、ワンタイムタスクでありもう一つは永続タスクである。ワンタイムタスクは、ある程度の時間、プロセッサの全てまたはほぼ全てのリソースを使用する。この時間は、アプリケーションによって推定されてもよい。対照的に、永続タスクは、不確定時間、平均的には、プロセッサの全リソースよりも少ないリソースを使用する。永続タスクは、メッセージ・トラフィックなどのために、一時的にプロセッサをバースト的に使用する可能性がある。

サブタスクを適切に分散させる上で、インターネットのようなＷＡＮにおける未使用プロセッサ・リソースを使用してもよい。こういった利用可能のリソースの使用は、たとえば、コンピュータゲーム分野において、ゲームの体感を高め、共有空間のオブジェクトを提供し、メディアストリームを符号化し、あるいは、伝統的なクライアント・サーバ・モデルにおいてゲームを提供するために、実装されてもよい。このようなユース・ケースに耐えられるフレームワークの設計は、簡単な仕事ではない。たとえば、こういったフレームワークは、拡張可能で、分散化され、安全で、不正に強く、充分に経済的であることが望ましい。残念なことに、分散コンピューティングフレームワークを確立する上ではいくつかの一般的課題がある。こういったフレームワークは、集権化された核（core）を利用したり、ＳＥＴＩのように「無限のワークパイル（infinite workpile：仕事の無限の積み重ね）」を想定して設計されることが多い。

実行時間の見積り（や他のリソースの使用見積り）は、ブロック２１０においてプロセッサ・ノード数ｘを決定したり、ブロック２１６において特定のタスクをローカルに配置するか、ＬＡＮに割り当てるかか、あるいは、ＷＡＮに割り当てるかを決定するために必要となるかもしれない。正確かつ自動的な見積りは（不可能ではないかもしれないが）実現が難しい。実行時の平均値や静的なコード分析は、通常、定数時間アルゴリズム（constant-time algorithms）（Ｏ（ｃ））の実行時間の決定でしか有効でないかもしれない。更に、並列実行に向いている計算集約的なタスクは、定数時間アルゴリズムから構成されることは多くはなく、むしろ不定長アルゴリズム（variable-length algorithms）から構成されることが多い。このような不定長アルゴリズムの実行時間は、実行時にならなければ利用できない入力パラメータに依存する。所与の関数の実行時間は、入力パラメータに基づいて必要なリソースを算出する第２関数によって予測されてもよい。しかし、このような第２関数は大きなオーバーヘッドとなるかもしれない。なぜならば、実行時において、関数に新しいパラメータがセットされごとに何度も第２関数が実行されなければならなくなるからである。分散処理の効率性は、おおよそ、プロセッサ使用見積りの正確さに依存する。

本実施例において、ブロック２１２から２１６において複数のタスクやサブタスクをいつどのように分散するかを決定するとき、利用可能なプロセッサの能力を計測するための他の手段を検討することも望ましいかもしれない。ワンタイムタスクにとって、均質な計算環境（homogeneous computing environment）において利用可能なプロセッサの能力を判定する上で、実行時間は有用な基準となるかもしれない。均質な環境においては、サイクル数はより有用である。永続タスクにとって、時間経過にともなうＣＰＵの使用率（あるいは、異種環境（heterogeneous environment）における１秒あたりのサイクル数）を知ることはもっと有用であるかもしれない。このため、プロセッサの使用量は、タスクタイプにあわせて解釈されなければならない。

ブロック２１２では、処理タスクの分散要否に関する重要な閾値の問題がある。多くのタスクは、相互に依存する２以上のサブタスクの集合として捉えられるかもしれない。サブタスクは、しばしば並列実行される。特定のタスクを処理するために複数の選択肢が利用可能であるならば、サブタスクを（１）単一のローカル・ノード・プロセッサで実行するか、（２）複数のローカル・ノード・プロセッサに分散させるか、（３）ＬＡＮに分散させるか、（４）ＷＡＮに分散させるか、（５）その他の方法で分散させるか、を決定する分散スケジューラが有効である。分散の規模は、ローカル・ノードからＬＡＮ、さらに、ＷＡＮまで変化する。特定のタスクがこの規模のどのあたりに位置するか判断するためには、多くの要素が考慮されてもよい。

ブロック２１２において分散可否を決定する上で考慮される要素の一つは、並列のサブタスクそれぞれの実行時間である。並列サブタスクの実行時間は、所与のタイプの単一プロセッサにおいて、サブタスクを実行するのに要する時間を示す。通常、実行時間は、サブタスクの性質やサブタスクを実行するプロセッサのタイプに依存する。並列サブタスクの実行時間が長時間に及ぶならば、そのようなサブタスクはＷＡＮにまで分散させる方がよい。反対に、実行時間が短いサブタスクの場合には、ローカル・ノードにて利用可能なプロセッサ群に分散させる方がよい。

考慮すべき別の要素は、実行されるサブタスクの数である。サブタスク数が多いときにはＷＡＮに分散させる方がよい。サブタスク数が少ないときだけ（実行時間が短いときには特に）、ローカル・ノードにて利用可能なプロセッサ群に分散させる方がよい。

考慮すべき更に別の要素は、並列サブタスク間における同期処理（synchronous interaction）の量（数）である。ここでいう同期処理とは、通常、サブタスク間のブロッキング通信である。たとえば、第１のタスクは、第２のタスクにメッセージを送出すると、計算を続行することなく第２のタスクから応答を待つかもしれない。もし、並列サブタスク間における同期処理の量が大きければ、ローカル・ノードにて利用可能なプロセッサ群に並列サブタスクを分散させる方がよいかもしれない。もし、並列サブタスク間における同期処理の量が比較的小さければ（あるいは、まったくなければ）、並列サブタスクをＷＡＮにまで分散させる方がよいかもしれない。同期処理についての所与の量が「大きい」か「比較的小さい」かは、多くの要素から判定されてもよい。たとえば、計算に費やす時間よりも他のサブタスクからの同期応答を待つ時間の方が長ければ、同期処理の量は大きく、サブタスク間の伝送遅延を減少させることで処理効率を向上させることができるかもしれない。伝送遅延は、たとえば、ＷＡＮの代わりにＬＡＮにサブタスクを分散したり、ＬＡＮの代わりにローカル・ノードにサブタスクを分散させることによって減少できるかもしれない。

更に考慮すべき要素は、各サブタスクが必要とするデータ量である。たとえば、サブタスクが使用する入力データやバイナリコードのサイズである。各サブタスクが大量のデータを必要とする場合には、並列サブタスクをローカル・ノードのプロセッサ群に分散させる方がよいかもしれない。各サブタスクが比較的少量のデータしか必要としない場合には、サブタスクをＷＡＮまで分散させる方がよいかもしれない。

ブロック２１０におけるノード数ｎの決定や、ブロック２１６、２１８におけるタスクやサブタスクの分配にとって、分散コンピューティングにより処理効率を確実に高めるためには、タスクの実行時間や要求されるデータを概算しておくことが望ましい。このような概算がなければ、（ローカルにタスクを実行するのに比べて）分散コンピューティングのタスク処理効率を悪化させる可能性がある。

本実施例においては、多くのタイプの並列計算タスクについて、ブロック２１０にて所与のタスクを実行するのに最適なノード数ｘを決定するための方程式が導かれる。このような方程式の導出には、プロセッサノード数（ｘ）に基づく実効実行時間（ＥＥＴ：Effective Execution Time）の判定も含まれる。方程式では、以下の追加変数も考慮に入れてもよい。
ＥＴ：１つのノードにおける全タスクの実行時間を示す。
ＴＳ：サブタスク群で分割されるべきデータの総サイズを示す。
ＣＳ：各サブタスクが必要とする定数サイズのデータ（たとえば、コードのサイズ）を示す。
ＲＳ：タスク群が生成する出力データの総サイズを示す。
ＢＷｏ，ＢＷｉ：それぞれ、全プロセッサ・ノードについての出力および入力の帯域幅を示す。
ＲＴＴ：プロセッサ・ノードに対するラウンドトリップメッセージ時間（往復遅延時間）を示す。
これらの値は、ブロック２０２のパラメータ収集時に取得され、パラメータテーブル２０５に保持されてもよい。

本実施例において、プロセッサノード数ｘに基づく実効実行時間ＥＥＴは、次式によって近似される。

方程式１の右辺第１項は、全プロセッサ・ノードが処理を開始する上で必要なデータを受信するのに要する時間を示す。第２項は、単一のサブタスクを実行するのに必要な時間を示す。第３項は、サブタスクの結果をソース（要求元）へ返信するのに要する時間を示す。

一例として、方程式１の第１項の式f(x,TS,CS)は、全プロセッサ・ノードの実行開始前にシリアル伝送されるデータの量を計算する分散メトリック（分散の基準）であってもよい。データは、ソース・ノードが全プロセッサ・ノードにデータを送信する線形分散（f_１）か、ソース・ノードが２分木分散ツリー（binary distribution tree）のルートとなる対数分散（f_２）のいずれかにより分散されてもよい。線形分散の場合、式f(x,TS,CS)は、以下の形式となってもよい。

一方、対数分散の場合、式f(x,TS,CS)は、以下の形式となってもよい。

本実施例における式f(x,TS,CS)は、方程式２の線形形式のf_１と方程式３の対数形式のf_２との合成関数f_ｈの形式であることが好ましいかもしれない。通常、データＴＳ（このデータは全プロセッサ・ノード群の間で分割される）は、線形に送信する方が効率的である。更に、通常、データＣＳは対数的に送信する方が効率的である。式f_２は、各段階にてＣＳデータ全体を送信する。各段階にて、（ＣＳデータ全体を送信するよりも、）ＣＳデータの無限小部分を（より多くの送信段階にわけて）送信すれば、タスクの実行タイミングが改善されるかもしれない。すると、データ全体を分散させるのに要する時間は、主としてＲＴＴにより制限されることになる。ハイブリッド型の分散関数f_ｈは以下の形式となってもよい。

ＴＳ＜ＣＳのときには、ソース・ノードにＣＳデータを対数分散させ、完了すると、ＴＳデータを分割して全ての同等ノード（peer）に送出するのが特に効率的である。ＴＳ＞ＣＳのときには、データＣＳおよびＴＳを並列して分散させる方が効率的である。上記方程式４の右辺下式のＭＡＸ関数は、ＣＳの対数送信とＴＳの線形送信を並行して実行する旨を示している。ＭＡＸ関数は、ＣＳ＋ＴＳと２ＣＳ＋ＢＷｏ・ＲＴＴ・log_２（x+1）の最大値を返す。ＣＳとＴＳの両方のデータがプロセッサ・ノードに受信されなければ実行開始できない。したがってＭＡＸ関数を使っている。

たとえば、分散型のレイ・トレーシング・タスクを考える。この場合、全ノードは同じシーン・データを必要とする。ＣＳは大きく、ＴＳは事実上ゼロであるため、ＥＥＴの方程式は以下の通りとなる。

タスクを実行する最適ノード数を求める方程式を見つけるために、ＥＥＴが最も小さくなるときのノード数Ｘを計算してもよい。このＸ値を決定するために、ＥＥＴを求める方程式５をｘで微分し、ＥＥＴ’＝０となるときのｘ値を求める。

これにより、以下が導かれる。

現実のタスクにとって、タスク細分化には最大可能数があるかもしれない。ただし、算出された最適実行ノード数が分割可能な最大の数よりも大きいときには、スケジューラは単にその最大の数だけ割り当てればよい。このような結果に基づくと、小さく、長さやサイズが等しいタスクは、分散コンピューティングにもっともふさわしいことになる。スケジューラは、総実行時間と総データサイズに基づいて最適ノード数を決定し、選択したプロセッサ・ノード群に均等に小タスクを分散できるからである。

ブロック２１０の最適ノード数ｘの決定、ブロック２１２における分配可否の決定、ブロック２１６におけるタスクやサブタスクの分散配置決定では、上記パラメータだけではなく追加的基準も考慮に入れてもよい。たとえば、このような追加的基準には、サブタスクの実行コストの決定も含まれる。このコストの決定には、ｘノードでタスクを実行する場合のノード当たりのコストの決定が含まれる。ノード当たりコストには、帯域幅の大きさや各分散ノードで費やされる実行時間といった多くの要素が含まれる。更に、ノード当たりコストは、ノード数ｘ、求められるサービス品質、定数サイズデータの大きさ、伝送コスト、使用コストのうちの１以上に依存する。分散処理のコストを考慮するときには、これら全ての要素を考慮してもよい。

図３は、分散可否の数値的な例を示す。特に、図３の実線プロットは、次に示すパラメータ値において、ｘに対するＥＥＴのグラフである。
ＥＴ＝５秒
ＴＳ＝１KByte
ＣＳ＝１KByte
ＲＳ＝１０KByte
ＢＷｏ＝３０KByte/s
ＢＷｉ＝４００KByte/s
ＲＴＴ＝０．２秒

図３の実線から分かるように、ｘ＝１のプロセッサの処理時間は５秒であり、約１．４秒という最低ＥＥＴとなるのはｘ＝１７のプロセッサによる分散処理を行ったときである。この例では、１７個のプロセッサでは明らかにＥＥＴが短くなっていることから、分散させる意味があるといえる。

図３の点線プロットは、次に示すパラメータ値において、ｘに対するＥＥＴのグラフである。
ＥＴ＝５秒
ＴＳ＝１００KByte
ＣＳ＝０KByte
ＲＳ＝１０KByte
ＢＷｏ＝３０KByte/s
ＢＷｉ＝４００KByte/s
ＲＴＴ＝０．２秒

図３の点線から分かるように、ｘ＝１のプロセッサの処理時間は、１秒という最低ＥＥＴとなっている。１００ノードのときですら、３．５秒の次善ＥＥＴとなる。この例では、１よりも多くのプロセッサを使うと、明らかにＥＥＴが大きくなることから、タスク分散させる意味がないことになる。

分散処理のコストは、だれが処理のためのリソースを提供しているかによって変化する可能性がある。合理的に考えると、リソースの所有者は、リソースを利用可能とすることによる見返りを求めるかもしれない。この見返りの大きさはプロバイダ（提供者）によってさまざまに変化するかもしれない。分散処理リソースのユーザ（使用者）がそのようなリソースの使用コストを判定できれば有用である。図４は、遠隔地に分散されているリソースの使用コストを算定可能なモデル３００を示している。モデル３００においては、ユーザ・ノード３０２とプロバイダ・ノード３０４は、ネットワーク３０６を介して接続されている。プロバイダ・ノード３０４の所有者は、ネットワーク３０６上にてアクセス可能なルックアップテーブル３０８上に、利用可能なリソースとそのコストを示す。一例として、ルックアップテーブル３０８は、ネットワーク３０６に接続されるノードのメモリに保持されてもよい。ユーザ・ノード３０２は、ルックアップテーブル３０８へ問い合わせることにより、どのような処理リソースを利用可能で、どのくらいのコストがかかるかを検出してもよい。

図５に示す別モデル４００では、ユーザ・ノード４０２とプロバイダ・ノード４０４は、ネットワーク４０６を介して、流動資本市場（liquid capital market）４０８により相互作用してもよい。ユーザ・ノード４０２は、流動資本市場４０８にリストアップするためにタスク・リクエスト４１０を送信してもよい。流動資本市場４０８は、たとえば、他のユーザ・ノード４０２やプロバイダ・ノード４０４からアクセス可能なウェブサイトにて、各タスク・リクエスト４１０の一覧表示する。各タスク・リクエスト４１０は、ユーザ・ノード４０２が、利用可能プロバイダ群に分散させたいタスクについての情報が含まれてもよい。この情報には、上記したさまざまなパラメータが含まれる。タスク・リクエスト４１０は、ユーザ・ノードの操作者がプロバイダ・ノードのリソース使用に支払う対価を含んでもよい。この対価とは、たとえば、プロバイダ・ノードのリソース使用の代わりに、ノード操作者が譲渡するリソース、あるいは、通貨といった観点から示されてもよい。プロバイダ・ノード４０４は、流動資本市場４０８にて一覧表示されているタスク・リクエスト４１０に入札（bid）４１２をしてもよい。ユーザ・ノード操作者とプロバイダ・ノード操作者は、オープンかつ競争的な入札処理（せり）により、提供すべきリソースとそれらの対価について合意してもよい。

変形例として、サブ処理タスクについて提案されている分散が１以上のユーザ定義のポリシ（方針）に合致しているかを判定するための追加的基準を考慮に入れてもよい。たとえば、もし、ユーザが、カリフォルニア州でしかサブタスクを実行したくない場合には、このユーザ定義ポリシは、他州から提供されるリソースを選択するためのリソース選択基準に適用されてもよい。

ブロック２１６、２１８における処理タスクの分散方法の決定について更に考慮してもよい。たとえば、分散ノードのキャッシュに、所与のタスクやサブタスクの実行に必要なコードやデータが既に存在するならば、データ転送や処理の時間を大きく削減できるかもしれない。ここでいうキャッシュとは、通常、特定のプロセッサやノードに対応づけられる高速ストレージ領域（たとえば、ＳＲＡＭ（Static Random Access Memory））である。キャッシュは、一般的には、使用頻度の高いデータや命令を保持するために使われる。タスク分散を促進するためには、１以上の分散ノードに関連づけられるタスクの内容を判定し、タスクやサブタスクを処理するために必要なデータがあるかどうかを判定することが望ましい。タスクやサブタスクは、ブロック２１６やブロック２１８において、必要なコードやデータを有するノードに優先的に分散されてもよい。

以上は、本発明の最適な実施例の完全な記述であるが、さまざまな変更、変形、等価物への置き換えが可能である。それゆえ、本発明の範囲は、上記記述に関してではなく、請求項により定義されるべきであり、完全な等価物の範囲も含まれる。記述された特徴は、それが好ましいものであれ、そうでないものであれ、上記したさまざまな特徴と組み合わされてもよい。請求項においては、通常、特に断らない限りは、各要素は１またはそれ以上の数量を想定している。請求項の記載事項は、「〜手段」のような記載によって、明示される場合のほかは、いわゆるミーンズ・プラス・ファンクション特有の限定的意味で解してはならない。

本実施例における分散処理システムのブロック図である。 本実施例における処理過程を示すフローチャートである。 本実施例において、タスクの分散要否を判定するための実行時間とプロセッサ数の関係を示すグラフである。 本実施例において、ルックアップテーブルモデルによる分散処理コストの決定方法を示すブロック図である。 本実施例において、流動資本市場モデルによる分散処理コストの決定方法を示すブロック図である。

Claims (36)

1. ローカル・ノードにタスクを生成するステップと、
   前記タスクを１以上のサブタスクに分割するステップと、
   ローカル・ノードからアクセス可能なノード群においてサブタスク群を実行させるのに関連するパラメータの少なくとも一部に基づいて、前記１以上のサブタスクを実行するための最適ノード数ｘを判定するステップと、
   ｘに基づいて、ローカル・ノードで前記タスクを実行するか、ローカル・ノードからアクセス可能な１以上の分散ノードに前記タスクを分散させるかを判定するステップと、
   を備えることを特徴とするプロセッサにて実行可能なタスクの処理方法。
2. サブタスク群をｘノードに分散させて処理させるステップ、を更に備えることを特徴とする請求項１に記載の処理方法。
3. ｘノードからサブタスクの出力データを取得するステップ、を更に備えることを特徴とする請求項２に記載の処理方法。
4. サブタスク群の実行に関連する前記パラメータを収集するステップ、を更に備えることを特徴とする請求項１に記載の処理方法。
5. ローカル・プロセッサによりアクセス可能なデータ記録媒体に前記パラメータを記録するステップ、を更に備えることを特徴とする請求項４に記載の処理方法。
6. 前記パラメータは、利用可能ノード数、前記ローカル・ノードおよび１以上の分散ノード間におけるデータ伝送率、前記ローカル・ノードおよび１以上の分散ノード間におけるラウンドトリップ時間、サブタスクのプロセッサ・サイクル数、サブタスクが必要とするメモリ領域の大きさ、サブタスクが必要とするストレージ領域の大きさ、および、サブタスクの関連データの転送において利用可能なネットワーク帯域幅、のうちの１以上のを含むことを特徴とする請求項４に記載の処理方法。
7. 前記タスクの実効実行時間（ＥＥＴ：Effective Execution Time）の最低値に基づいて、前記最適ノード数ｘを判定することを特徴とする請求項１に記載の処理方法。
8. 前記実効実効時間は、以下の式によって計算され、
   ここで、ＥＴは、１つのノードにおける全サブタスクの実行時間、
   ＴＳは、サブタスク群で分割されるべきデータの総サイズ、
   ＣＳは、各サブタスクが必要とする定数サイズのデータ、
   ＲＳは、タスク群が生成する出力データの総サイズ、
   ＢＷｏ、ＢＷｉは、それぞれ、全プロセッサ・ノードについての出力および入力の帯域幅、
   ＲＴＴは、前記ローカル・ノードから分散ノードへのラウンドトリップメッセージ時間（往復遅延時間）、をそれぞれを示すことを特徴とする請求項７に記載の処理方法。
9. １ノードにおける全タスクの実行時間（ＥＴ：Execution Time）と前記ローカル・ノードから分散ノードへのラウンドトリップメッセージ時間（ＲＴＴ：Round-trip Message Time）に基づいてｘを決定することを特徴とする請求項１に記載の処理方法。
10. ＥＴとＲＴＴとの比率に基づいてｘを決定することを特徴とする請求項９に記載の処理方法。
11. 追加的基準を含めて、前記最適ノード数ｘを決定することを特徴とする請求項１に記載の処理方法。
12. 前記追加的基準として、サブタスクの実行コストの判定を含むことを特徴とする請求項１１に記載の処理方法。
13. サブタスクの実行コストの判定には、ノード当たりのコストの判定が含まれることを特徴とする請求項１２に記載の処理方法。
14. ノード当たりのコストの判定には、分散ノードの帯域幅、または、実行時間の判定が含まれることを特徴とする請求項１３に記載の処理方法。
15. ノード当たりのコストの決定は、ノード数ｘ、求められるサービス品質、定数サイズデータの大きさ、伝送コスト、使用コスト、のうちの１以上に基づくことを特徴とする請求項１３に記載の処理方法。
16. サブタスクの実行コストの判定には、プロバイダから示されるコストのルックアップテーブルからのコスト取得処理が含まれることを特徴とする請求項１３に記載の処理方法。
17. サブタスクの処理コストの判定には、プロバイダが顧客に入札する流動資本市場の使用を含むことを特徴とする請求項１３に記載の処理方法。
18. 前記追加的基準は、１以上のユーザ定義ポリシを含むことを特徴とする請求項１１に記載の処理方法。
19. サブタスクは、あるタイプのサブタスクと別のタイプのサブタスクを識別し、および／または、最適ノード数ｘを決定するための情報を提供するサブタスクタイプによって特定されることを特徴とする請求項１に記載の処理方法。
20. １以上の分散ノードに関連づけられるキャッシュの内容を判定するステップ、を更に含むことを特徴とする請求項１に記載の処理方法。
21. サブタスクを実行するのに必要なコードやノードを有するノードに対して前記サブタスクを優先的に分散させるステップ、を更に含むことを特徴とする請求項２０に記載の処理方法。
22. 複数の分散ノードと接続されるローカル・ノードと、
    ローカル・ノードによる実行命令群であって、プロセッサにて読み取り可能な記録媒体に保持されるプロセッサ実行可能な命令群と、を備え、
    前記命令群は、
    ローカル・ノードにタスクを生成する１以上の命令と、
    前記タスクを１以上のサブタスクに分割する１以上の命令と、
    ローカル・ノードからアクセス可能なノード群においてサブタスク群を実行させるのに関連するパラメータの少なくとも一部に基づいて、前記１以上のサブタスクを実行するための最適ノード数ｘを判定する１以上の命令と、
    ｘに基づいて、ローカル・ノードで前記タスクを実行するか、１以上の分散ノードに前記タスクを分散させるかを判定する１以上の命令と、
    を含むことを特徴とする複数の分散ノード群に処理を分散させるシステム。
23. 前記ローカル・ノードに接続されるメモリ、を更に備えることを特徴とする請求項２２に記載のシステム。
24. 前記メモリに前記パラメータに関する情報を保持することを特徴とする請求項２３に記載のシステム。
25. 前記パラメータは、利用可能ノード数、前記ローカル・ノードおよび１以上の他ノード間におけるデータ伝送率、前記ローカル・ノードおよび１以上の他ノード間におけるラウンドトリップ時間、サブタスクのプロセッサ・サイクル数、サブタスクが必要とするメモリ領域の大きさ、サブタスクが必要とするストレージ領域の大きさ、および、サブタスクの関連データの転送において利用可能なネットワーク帯域幅、のうちの１以上を含むことを特徴とする請求項２２に記載のシステム。
26. 前記プロセッサにて実行可能な命令群は、更に、分散ノードから前記パラメータを収集する１以上の命令を含むことを特徴とする請求項２２に記載のシステム。
27. 前記ローカル・ノードに接続されるメモリ、を更に備え、
    前記プロセッサにて実行可能な命令群は、前記メモリに前記パラメータを記録するの１以上の命令を含むことを特徴とする請求項２６に記載のシステム。
28. 前記プロセッサにて実行可能な命令群は、前記メモリの前記パラメータを更新する１以上の命令を含むことを特徴とする請求項２７に記載のシステム。
29. 前記プロセッサにて実行可能な命令群は、実効実行時間（ＥＥＴ：Effective Execution Time）の最低値に基づいて、ｘを決定する１以上の命令を含むことを特徴とする請求項２２に記載のシステム。
30. 前記実効実効時間は、以下の式によって計算され、
    ここで、ＥＴは、１つのノードにおける全サブタスクの実行時間、
    ＴＳは、サブタスク群で分割されるべきデータの総サイズ、
    ＣＳは、各サブタスクが必要とする定数サイズのデータ、
    ＲＳは、タスク群が生成する出力データの総サイズ、
    ＢＷｏ、ＢＷｉは、それぞれ、全プロセッサ・ノードについての出力および入力の帯域幅、
    ＲＴＴは、前記ローカル・ノードから、前記ローカル・ノードによりアクセス可能なノードへのラウンドトリップメッセージ時間（往復遅延時間）、をそれぞれを示すことを特徴とする請求項２９に記載のシステム。
31. １ノードにおける全タスクの実行時間（ＥＴ：Execution Time）と前記ローカル・ノードから、前記ローカル・ノードによりアクセス可能なノードへのラウンドトリップメッセージ時間（ＲＴＴ：Round-trip Message Time）に基づいてｘを決定することを特徴とする請求項２２に記載のシステム。
32. ＥＴとＲＴＴとの比率に基づいてｘを決定することを特徴とする請求項３１に記載のシステム。
33. １以上の追加的基準を含めて、ｘを決定することを特徴とする請求項２２に記載のシステム。
34. 前記追加的基準は、サブタスクの実行コスト、および／または、１以上のユーザ定義ポリシを含むことを特徴とする請求項３３に記載のシステム。
35. サブタスクは、あるタイプのサブタスクと別のタイプのサブタスクを識別し、および／または、最適ノード数ｘを決定するための情報を提供するサブタスクタイプによって特定されることを特徴とする請求項２２に記載のシステム。
36. プロセッサ実行可能なタスクの処理方法を実装するための命令群であって、
    ローカル・ノードにタスクを生成する１以上の命令と、
    前記タスクを１以上のサブタスクに分割する１以上の命令と、
    ローカル・ノードにからアクセス可能なノード群においてサブタスク群を処理するのに関連するパラメータの少なくとも一部に基づいて、前記１以上のサブタスクを実行するための最適ノード数ｘを判定する１以上の命令と、
    ｘに基づいて、前記ローカル・ノードで前記タスクを実行するか、前記ローカル・ノードからアクセス可能な１以上の分散ノードに前記タスクを分散させるかを判定する１以上の命令と、
    を含む命令群を保持するプロセッサにて読み取り可能な記録媒体。