(57)【特許請求の範囲】
【請求項１】
クラスタコンピューティングシステム用のマスタデバイスであって、
少なくとも１つのスレーブデバイスと接続するように構成されている接続インターフェースと、
前記接続インターフェースに電気接続されているプロセッサであって、前記スレーブデバイスからデバイス情報を受信し、前記デバイス情報およびジョブに応じて前記スレーブデバイスに対するリソースフィーチャーモデルを選択し、前記リソースフィーチャーモデルに応じて前記スレーブデバイスのコンテナ構成パラメータを推定し、前記コンテナ構成パラメータを前記スレーブデバイスへ伝送し、前記スレーブデバイスに前記ジョブを割り当てるように構成されている、プロセッサと、を備え、
前記プロセッサはさらに、複数のリソースフィーチャーモデルのサンプルを複数のグループに分類し、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択し、前記スレーブデバイスに対するリソースフィーチャーモデルを前記リソースフィーチャーモデルの代表から選択する、
マスタデバイス。
【請求項２】
前記前記クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、前記マスタデバイスは、前記分散ファイルシステムを前記スレーブデバイスと共有し、前記プロセッサは、前記分散ファイルシステムから前記スレーブデバイスに対するリソースフィーチャーモデルを選択する、請求項１に記載のマスタデバイス。
【請求項３】
前記プロセッサはさらに、ジョブに対応するジョブ情報を前記分散ファイルシステムに記憶する、請求項２に記載のマスタデバイス。
【請求項４】
前記リソースフィーチャーモデルは、中央処理装置（ＣＰＵ）フィーチャーモデルおよびメモリフィーチャーモデルを含み、前記コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、前記コンテナ仕様は、ＣＰＵ仕様およびメモリ仕様を含む、請求項１に記載のマスタデバイス。
【請求項５】
前記プロセッサは、前記デバイス情報および前記ジョブに完全に対応する、対応するリソースフィーチャーモデル、前記デバイス情報および前記ジョブにほぼ対応する、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの１つを、前記リソースフィーチャーモデルとして選択し、前記対応するリソースフィーチャーモデルは、前記同様のリソースフィーチャーモデルに対して優先的に選択され、前記同様のリソースフィーチャーモデルは、前記事前設定されたリソースフィーチャーモデルに対して優先的に選択される、請求項１に記載のマスタデバイス。
【請求項６】
クラスタコンピューティングシステム内にあるマスタデバイスに対するコンピューティング方法であって、前記マスタデバイスは、接続インターフェースおよびプロセッサを備え、前記接続インターフェースは、少なくとも１つのスレーブデバイスと接続するように構成されているコンピューティング方法において、
（Ａ）前記スレーブデバイスのデバイス情報を前記プロセッサで受信するステップと、
（Ｂ）前記スレーブデバイスに対するリソースフィーチャーモデルを、前記デバイス情報およびジョブに応じて前記プロセッサによって選択するステップと、
（Ｃ）前記スレーブデバイスのコンテナ構成パラメータを、前記リソースフィーチャーモデルに応じて前記プロセッサによって推定するステップと、
（Ｄ）前記プロセッサによって前記コンテナ構成パラメータを前記スレーブデバイスに伝送するステップと、
（Ｅ）前記プロセッサによって前記スレーブデバイスに前記ジョブを割り当てるステップとを含み、
前記ステップ（Ｂ）は、複数のリソースフィーチャーモデルのサンプルを前記プロセッサによって複数のグループに分類することと、前記プロセッサによって、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択することと、前記スレーブデバイスに対するリソースフィーチャーモデルを、前記プロセッサによってデバイス情報および前記ジョブに応じて、前記リソースフィーチャーモデルの代表から選択することとを含む、
コンピューティング方法。
【請求項７】
前記クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、前記マスタデバイスは、前記分散ファイルシステムを前記スレーブデバイスと共有し、前記ステップ（Ｂ）は、前記デバイス情報および前記ジョブに応じて、前記スレーブデバイスに対するリソースフィーチャーモデルを前記分散ファイルシステムから前記プロセッサによって選択することを含む、請求項６に記載のコンピューティング方法。
【請求項８】
（Ｆ）前記ジョブに対応するジョブ情報を、前記プロセッサによって前記分散ファイルシステム内に記憶するステップをさらに含む、請求項７に記載のコンピューティング方法。
【請求項９】
前記リソースフィーチャーモデルは、ＣＰＵフィーチャーモデルおよびメモリフィーチャーモデルを含み、前記コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、前記コンテナ仕様は、ＣＰＵ仕様およびメモリ仕様を含む、請求項６に記載のコンピューティング方法。
【請求項１０】
前記ステップ（Ｂ）は、前記デバイス情報および前記ジョブに完全に対応する、対応するリソースフィーチャーモデル、前記デバイス情報および前記ジョブにほぼ対応する、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの１つを、前記プロセッサによってデバイス情報および前記ジョブに応じて、前記スレーブデバイスに対するリソースフィーチャーモデルとして選択することを含み、前記対応するリソースフィーチャーモデルは、前記同様のリソースフィーチャーモデルに対して優先的に選択され、前記同様のリソースフィーチャーモデルは、前記事前設定されたリソースフィーチャーモデルに対して優先的に選択される、請求項６に記載のコンピューティング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マスタデバイス、スレーブデバイスおよびそのコンピューティング方法に関する。さらに詳細には、本発明は、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法に関する。
【背景技術】
【０００２】
ビッグデータの計算には、クラスタコンピューティング技術が効果的な手段である。一般に、クラスタコンピューティングとは、複数のコンピューティングユニットがクラスタ化されてこれらのコンピューティングユニットの協働を通して１つのジョブを達成することを意味する。
動作時には、クラスタコンピューティングシステムは通常、マスタデバイスおよび複数のスレーブデバイスを備えている。マスタデバイスは、スレーブデバイスにジョブを割り当てるように構成されている。各々のスレーブデバイスは、ジョブに対応して割り当てられたタスクを実行するためのコンテナを生成するように構成されている。したがって、無駄を避けるためには、クラスタコンピューティングシステムでリソースを的確に割り当ててビッグデータを計算しなければならない。
【０００３】
一般的には、従来のクラスタコンピューティングシステムは、以下の問題が原因でリソースを効果的に割り当てられないことがある。第一に、従来のスレーブデバイスによって生成されたコンテナはすべて、仕様（中央処理装置（ＣＰＵ）仕様およびメモリ仕様など）が一定であるため、リソースの無駄が様々なジョブの様々な特性によって引き起こされる。例えば、ジョブの計算需要がコンテナの仕様よりも少ない場合、コンテナが完全に使用されていないためにリソースの無駄が起こることがある。
このほか、コンテナ仕様は各々のコンテナに対して一定であるため、従来のスレーブデバイスで生成できるコンテナ数も一定であり、それによってリソースはアイドル状態になる。例えば、１つのジョブに必要なコンテナ数が合計コンテナ数よりも少ない場合、リソースがアイドル状態であることでコンテナ数が過剰になる。また、コンテナ仕様は各々のコンテナに対して一定であるため、複数のスレーブデバイスが異なるデバイス性能を有する場合は、リソースの不適切な割り当てが起こる傾向がある。例えば、２つのスレーブデバイスのコンテナ仕様が同じであってもデバイス性能が異なる場合、２つのスレーブデバイスの処理効率が異なるために、リソースの不適切な割り当てが起こる。
【０００４】
したがって、先行技術による従来のクラスタコンピューティングシステムに対する効果的なリソース割り当て技術を提供することが重要である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、従来のクラスタコンピューティングシステムに対して効果的なリソース割り当て技術を提供することを含む。
【課題を解決するための手段】
【０００６】
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム用のマスタデバイスを備える。マスタデバイスは、接続インターフェースおよびプロセッサを備えている。接続インターフェースは、少なくとも１つのスレーブデバイスと接続するように構成されている。プロセッサは、接続インターフェースに電気接続されていて、スレーブデバイスからデバイス情報を受信し、デバイス情報およびジョブに応じてスレーブデバイスに対するリソースフィーチャーモデルを選択し、リソースフィーチャーモデルに応じてスレーブデバイスのコンテナ構成パラメータを推定し、コンテナ構成パラメータをスレーブデバイスへ伝送し、スレーブデバイスにジョブを割り当てるように構成されている。
プロセッサはさらに、複数のリソースフィーチャーモデルのサンプルを複数のグループに分類し、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択し、前記スレーブデバイスに対するリソースフィーチャーモデルを前記リソースフィーチャーモデルの代表から選択する。
【０００７】
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム用のスレーブデバイスを備える。スレーブデバイスは、接続インターフェースおよびプロセッサを備える。接続インターフェースは、マスタデバイスと接続するように構成されている。プロセッサは、接続インターフェースに電気接続されていて、デバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも１つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成するように構成されている。
【０００８】
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム内にあるマスタデバイスに対するコンピューティング方法を備える。マスタデバイスは、接続インターフェースおよびプロセッサを備えている。接続インターフェースは、少なくとも１つのスレーブデバイスと接続するように構成されている。コンピューティング方法は、
（Ａ）スレーブデバイスのデバイス情報をプロセッサで受信するステップと、
（Ｂ）スレーブデバイスに対するリソースフィーチャーモデルを、デバイス情報およびジョブに応じてプロセッサによって選択するステップと、
（Ｃ）スレーブデバイスのコンテナ構成パラメータを、リソースフィーチャーモデルに応じてプロセッサによって推定するステップと、
（Ｄ）プロセッサによってコンテナ構成パラメータをスレーブデバイスに伝送するステップと、
（Ｅ）プロセッサによってスレーブデバイスにジョブを割り当てるステップと
を含む。
ステップ（Ｂ）は、複数のリソースフィーチャーモデルのサンプルをプロセッサによって複数のグループに分類することと、プロセッサによって、リソースフィーチャーモデルのサンプルを各々のグループからリソースフィーチャーモデルの代表として選択することと、スレーブデバイスに対するリソースフィーチャーモデルを、プロセッサによってデバイス情報および前記ジョブに応じて、リソースフィーチャーモデルの代表から選択することとを含む。
【０００９】
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム内にあるスレーブデバイスに対するコンピューティング方法を備える。スレーブデバイスは、接続インターフェースおよびプロセッサを備える。接続インターフェースは、マスタデバイスと接続するように構成されている。コンピューティング方法は、
（Ａ）プロセッサによってデバイス情報をマスタデバイスに伝送するステップと、
（Ｂ）マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータを、プロセッサによってマスタデバイスから受信するステップと、
（Ｃ）プロセッサによってコンテナ構成パラメータに応じてジョブを計算するために、少なくとも１つのコンテナを生成するステップと、
（Ｄ）ジョブに対応するジョブ情報およびメトリックファイルに応じて、プロセッサによってリソースフィーチャーモデルを作成するステップと
を含む。
【００１０】
上記の説明によれば、本発明は、特定の実施形態では、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法を提供する。マスタデバイスが、各々のスレーブデバイスによって伝送されたデバイス情報を受信し、デバイス情報およびジョブに応じて各々のスレーブデバイスに対するリソースフィーチャーモデルを選択し、各々のリソースフィーチャーモデルに応じて、対応するスレーブデバイスのコンテナ構成パラメータを推定し、各々のコンテナ構成パラメータを対応するスレーブデバイスに伝送し、スレーブデバイスにジョブを割り当てる。スレーブデバイスが、スレーブデバイスのデバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも１つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成する。
【００１１】
したがって、本発明のスレーブデバイスによって生成されたコンテナの仕様は、動的に調整でき、よって様々なジョブの様々な特性が原因であるリソースの無駄がなくなる。さらに、コンテナ仕様は本発明の各々のコンテナに対して一定ではないため、本発明のスレーブデバイスのコンテナ数も動的に調整でき、よってリソースのアイドル状態がなくなる。このほか、本発明のスレーブデバイスによって生成されたコンテナ仕様およびコンテナ数を動的に調整できるため、複数のスレーブデバイスが様々なデバイス性能を有する場合であっても、リソースの不適切な割り当てが起こらない。
【００１２】
特許請求する本発明の特徴を当業者に確実に理解してもらうために、主たる発明に対して実装した詳細な技術および好適な実施形態について、付属の図面を添付して以下の段落に記載する。
【００１３】
図面の簡単な説明を以下に示すが、これは本発明を限定することを意図するものではない。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態によるクラスタコンピューティングシステムの概略構造図である。
【図２】図１に示したクラスタコンピューティングシステム内にあるマスタデバイスおよび単一のスレーブデバイスの動作を示す概略図である。
【図３】図２に示したマスタデバイス内にある最適なリソースモジュールの動作を示す概略図である。
【図４】図２に示したマスタデバイス内にあるモデル管理部の動作を示す概略図である。
【図５】図２に示したスレーブデバイス内にあるモデル生成部の動作を示す概略図である。
【図６】図２に示したスレーブデバイス内にあるジョブステータス収集部の動作を示す概略図である。
【図７】本発明の一実施形態によるクラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイスに対するコンピューティング方法を示す概略図である。
【発明を実施するための形態】
【００１５】
本発明について、本発明の例示的な実施形態を参照して説明していく。しかしながら、以下の例示的な実施形態は、本発明を任意の特定の例、実施形態、環境、用途、構造、プロセスフロー、またはこれらの実施形態に記載のステップに限定することを意図するものではない。換言すれば、以下の例示的な実施形態の説明は、本発明を限定するのではなく本発明を説明することのみを目的とするものである。
【００１６】
図面では、本発明に直接関係のない素子はすべて描写から省略されている。また、個々の素子どうしの寸法上の関係は、理解しやすいように示しているだけであって、実際の規模を限定するものではない。
【００１７】
本発明の一実施形態（簡潔に「第１の実施形態」と呼ぶ）は、クラスタコンピューティングシステムである。図１は、クラスタコンピューティングシステムの概略構造図である。
図１に示したように、クラスタコンピューティングシステム１は、マスタデバイス１１および少なくとも１つのスレーブデバイス１３（すなわち１つまたは複数のスレーブデバイス）を備えていてよい。マスタデバイスは、接続インターフェース１１１およびプロセッサ１１３を備えていてよく、両者は互いに直接または間接的に電気接続されて互いに通信してよい。各々のスレーブデバイス１３は、接続インターフェース１３１およびプロセッサ１３３を備えていてよく、両者は互いに直接または間接的に電気接続されて互いに通信してよい。
マスタデバイス１１の接続インターフェース１１１は、多様な媒体（図示せず）を介して各々のスレーブデバイス１３の接続インターフェース１１１に接続されてこれと通信してよい。マスタデバイス１１の接続インターフェース１１１は、様々な媒体（例えばネットワーク、バスなど）に応じて多様な有線または無線の方式で、各々のスレーブデバイス１３の接続インターフェース１１１に接続してこれと通信してよい。各々のマスタデバイス１１およびスレーブデバイス１３は、スタンドアローンのコンピュータであってもよいし、コンピュータ内にあるスタンドアローンのコンピューティングユニットであってもよい。
【００１８】
クラスタコンピューティングシステム１は、任意選択として、分散ファイルシステム１５を備えていてよい。分散ファイルシステム１５は、複数のスレーブデバイス１３で形成されるファイルシステムであり、それぞれのスレーブデバイスがリソースの一部（例えば記憶スペース）を提供する。
分散ファイルシステム１５は、マスタデバイス１１とスレーブデバイス１３とに共有される。具体的には、マスタデバイス１１の接続インターフェース１１１とスレーブデバイス１３の接続インターフェース１３１との間の接続を通して、マスタデバイス１１および各々のスレーブデバイス１３は、分散ファイルシステム１５内のデータにアクセスできる。換言すれば、マスタデバイス１１および各々のスレーブデバイス１３は、分散ファイルシステム１５の中にデータを記憶できるほか、分散ファイルシステム１５からデータを読み出すこともできる。任意選択として、マスタデバイス１１は、他のインターフェースを介して、または他の方法で、分散ファイルシステム１５内のデータに直接アクセスしてもよい。
【００１９】
図１に示すように、クラスタコンピューティングシステム１がジョブ２１（例えばアルゴリズム）を計算するようになっている場合、マスタデバイス１１はスレーブデバイス１３に、スレーブデバイスのデバイス情報２２をマスタデバイス１１に伝送するよう要求してよい。このようにする代わりにスレーブデバイス１３は、スレーブデバイスのデバイス情報２２をマスタデバイス１１に定期的に伝送してもよい。さらに詳細には、各々のスレーブデバイス１３は、スレーブデバイスのデバイス情報２２をスレーブデバイスの接続インターフェース１３１を介してマスタデバイス１１に伝送できる。
マスタデバイス１１は、各々のスレーブデバイス１３によって伝送されたデバイス情報２２を、マスタデバイスの接続インターフェース１１１を介して受信できる。したがって、クラスタコンピューティングシステム１がジョブ２１を計算するようになっている場合、マスタデバイス１１のプロセッサ１１３は、全スレーブデバイス１３によって事前に伝送されたデバイス情報２２を取得してよい。ジョブ２１は、マスタデバイス１１自体によって生成されてもよいし、マスタデバイスの外部の他のデバイスによって入力されてもよい。スレーブデバイス１３のデバイス情報２２は、ハードウェア、ソフトウェア、およびこれらの計算能力に関する情報を含んでいてよい。
【００２０】
全スレーブデバイス１３によって伝送されたデバイス情報２２を取得した後、マスタデバイス１１のプロセッサ１１３は、デバイス情報２２およびジョブ２１に応じて対応する各々のスレーブデバイス１３に対して、リソースフィーチャーモデル２３を選択してよい。各々のリソースフィーチャーモデル２３は、必要に応じて、中央処理装置（ＣＰＵ）フィーチャーモデル、メモリフィーチャーモデル、ネットワークフィーチャーモデル、ディスク入出力（ディスクＩＯ）フィーチャーモデルなどであってこれに限定されない任意の多様なフィーチャーモデルを備えていてよい。
ＣＰＵフィーチャーモデルは、コンテナを計算するジョブに必要なＣＰＵ仕様を推定するために使用されてよい。メモリフィーチャーモデルは、コンテナを計算するジョブに必要なメモリ仕様を推定するために使用されてよい。ネットワークフィーチャーモデルは、コンテナを計算するジョブに必要なネットワーク仕様を推定するために使用されてよい。ディスクＩＯフィーチャーモデルは、コンテナを計算するジョブにディスクＩＯ仕様を推定するために使用されてよい。
【００２１】
クラスタコンピューティングシステム１が分散ファイルシステム１５を備えている場合、マスタデバイス１１のプロセッサ１１３は、各々のスレーブデバイス１３に対して分散ファイルシステム１５からリソースフィーチャーモデル２３を選択できる。例えば、分散ファイルシステム１５は、事前に複数のリソースフィーチャーモデルのサンプルを記憶してよい。マスタデバイス１１のプロセッサ１１３は、各々のスレーブデバイス１３に対して、対応するデバイス情報２２およびジョブ２１に応じてリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル２３を選択できる。
【００２２】
クラスタコンピューティングシステム１が分散ファイルシステム１５を備えていない場合、マスタデバイス１１のプロセッサ１１３は、各々のスレーブデバイス１３に対して、他のソースによって提供されたリソースフィーチャーモデルのサンプルに応じてリソースフィーチャーモデル２３を選択してもよい。例えば、マスタデバイス１１は、複数のリソースフィーチャーモデルのサンプルを事前に記憶するために記憶デバイス（図示せず）を備えていてもよいし、他のデバイスから事前に複数のリソースフィーチャーモデルのサンプルを取得してもよい。
マスタデバイス１１のプロセッサ１１３は、各々のスレーブデバイス１３に対して、対応するデバイス情報２２およびジョブ２１に応じてリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル２３を選択できる。前述のリソースフィーチャーモデルのサンプルは、リソースフィーチャーモデル２３自体であってもよいし、リソースフィーチャーモデルに関連する情報であってもよい。
【００２３】
取得できるリソースフィーチャーモデルのサンプル数が多すぎると（例えば閾値よりも多いと）、クラスタコンピューティングシステム１が分散ファイルシステム１５を備えていようとなかろうと、マスタデバイス１１のプロセッサ１１３は、任意選択として複数のリソースフィーチャーモデルのサンプルを複数のグループに分類して、各々のグループからリソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として選択してよい。
例えば、マスタデバイス１１のプロセッサ１１３は、Ｋ平均アルゴリズムを用いて複数のリソースフィーチャーモデルのサンプルを複数のグループに分類できる。次に、マスタデバイス１１のプロセッサ１１３は、各々のスレーブデバイス１３に対して、対応するデバイス情報２２およびジョブ２１に応じてリソースフィーチャーモデルの代表からリソースフィーチャーモデル２３を選択できる。前述のリソースフィーチャーモデルのサンプルは、リソースフィーチャーモデル２３自体であってもよいし、リソースフィーチャーモデルに関連する情報であってもよい。
【００２４】
マスタデバイス１１のプロセッサ１１３は、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデル、および事前設定されたリソースフィーチャーモデルのうちの１つを、対応するデバイス情報２２およびジョブ２１に応じて各々のスレーブデバイス１３に対するリソースフィーチャーモデル２３として選択できる。対応するリソースフィーチャーモデルは、同様のリソースフィーチャーモデルに対して優先的に選択され、同様のリソースフィーチャーモデルは、事前設定されたリソースフィーチャーモデルに対して優先的に選択される。具体的には、各々のスレーブデバイス１３に対して、マスタデバイス１１のプロセッサ１１３は、最初に、対応するデバイス情報２２およびジョブ２１に応じて、対応するリソースフィーチャーモデル（すなわちデバイス情報２２およびジョブ２１に完全に対応するリソースフィーチャーモデル）があるかどうかを判断できる。
判断結果が「はい」であれば、マスタデバイス１１のプロセッサ１１３は、対応するリソースフィーチャーモデルをリソースフィーチャーモデル２３として選択する。判断結果が「いいえ」であれば、マスタデバイス１１のプロセッサ１１３は、対応するデバイス情報２２およびジョブ２１に応じて、同様のリソースフィーチャーモデル（すなわちデバイス情報２２およびジョブ２１にほぼ対応するリソースフィーチャーモデル）があるかどうかを判断する。判断結果が「はい」であれば、マスタデバイス１１のプロセッサ１１３は、同様のリソースフィーチャーモデルをリソースフィーチャーモデル２３として選択する。判断結果が「いいえ」であれば、マスタデバイス１１のプロセッサ１１３は、事前設定されたリソースフィーチャーモデル（すなわち事前設定されているリソースフィーチャーモデル）をリソースフィーチャーモデル２３として選択する。
【００２５】
マスタデバイス１１のプロセッサ１１３は、各々のリソースフィーチャーモデル２３に応じて、対応するスレーブデバイス１３のコンテナ構成パラメータ２４を推定できる。各々のコンテナ構成パラメータ２４は、コンテナ数およびコンテナ仕様を含んでいてよい。また、各々のコンテナ仕様は、必要に応じて、ＣＰＵ仕様、メモリ仕様、ネットワーク仕様、ディスク入出力（ディスクＩＯ）仕様などであってこれに限定されない任意の多様な仕様を含んでいてよい。
具体的には、マスタデバイス１１のプロセッサ１１３は、各々のリソースフィーチャーモデル２３に応じて、対応するスレーブデバイス１３に必要な多様な仕様（例えばＣＰＵ仕様、メモリ仕様、ネットワーク仕様、ディスクＩＯ仕様など）を推定してジョブ２１を計算するためのコンテナを開けられる。次に、マスタデバイス１１のプロセッサ１１３は、スレーブデバイス１３のデバイス情報２２および推定した仕様（例えばＣＰＵ仕様、メモリ仕様、ネットワーク仕様、ディスクＩＯ仕様など）に応じて、スレーブデバイス１３によって開けられる必要のあるコンテナ数を推定できる。
【００２６】
例えば、マスタデバイス１１のプロセッサ１１３が、スレーブデバイス１３がコンテナを開けてジョブ２１を計算するために必要なＣＰＵ仕様およびメモリ仕様がそれぞれ１ギガヘルツ（１ＧＨｚ）および１ギガバイト（１ＧＢ）であると推定し、かつデバイス情報２２が、スレーブデバイス１３のＣＰＵ能力およびメモリ能力がそれぞれ４ギガヘルツ（４ＧＨｚ）および４ギガバイト（４ＧＢ）であると指摘すれば、マスタデバイス１１のプロセッサ１１３は、スレーブデバイス１３がジョブ２１を計算するのに必要なコンテナ数が４であると推定する。
【００２７】
マスタデバイス１１のプロセッサ１１３は、各々のコンテナ構成パラメータ２４を接続インターフェース１１１を介して対応するスレーブデバイス１３に伝送し、これらのスレーブデバイスにジョブ２１を割り当ててよい。
クラスタコンピューティングシステム１が同システム内に利用可能なスレーブデバイス１３を１つしか有していなければ、ジョブ２１は、その単一のスレーブデバイス１３のみで計算される。クラスタコンピューティングシステム１が同システム内に利用可能なスレーブデバイス１３を複数有していれば、ジョブ２１は、これらのスレーブデバイス１３全部で計算される。後者の場合、マスタデバイス１１のプロセッサ１１３は、ジョブ２１を複数のタスクに分割した後、これらのタスクをこれらのスレーブデバイス１３に割り当てる。ジョブ２１を複数のタスクに分割し、そのタスクを複数のスレーブデバイス１３に割り当てるという方法は、当業者には公知のものであり、これについては本明細書ではこれ以上説明しない。
【００２８】
各々のスレーブデバイス１３のプロセッサ１３３は、マスタデバイス１１によって割り当てられたジョブ２１（またはマスタデバイスによって割り当てられたジョブ２１に対応するタスク）および対応するコンテナ構成パラメータ２４を、接続インターフェース１３１を介して受信できる。次に、各々のスレーブデバイス１３のプロセッサ１３３は、受信したコンテナ構成パラメータ２４に応じてジョブ２１（またはマスタデバイスによって割り当てられたジョブ２１に対応するタスク）を計算するために少なくとも１つのコンテナを生成できる。
クラスタコンピューティングシステム１では、各々のスレーブデバイス１３は、多様なローカルデータを記憶するためのメトリックファイルを有する。したがって、少なくとも１つのコンテナによってジョブ２１（またはマスタデバイスによって割り当てられたジョブ２１に対応するタスク）を計算するプロセスの過程で、スレーブデバイス１３のプロセッサ１３３は、少なくとも１つのコンテナのジョブステータスを収集して、ジョブステータスのステータス情報をメトリックファイルに記憶できる。
【００２９】
ジョブ２１（またはマスタデバイスによって割り当てられたジョブ２１に対応するタスク）の計算が完了した後、各々のスレーブデバイス１３のプロセッサ１３３は、ジョブ２１に対応するジョブ情報およびそのメトリックファイルに応じてリソースフィーチャーモデル２３を作成できる。例えば、各々のスレーブデバイス１３のプロセッサ１３３は、サポートベクトル回帰（Ｓｕｐｐｏｒｔ  Ｖｅｃｔｏｒ  Ｒｅｇｒｅｓｓｉｏｎ、ＳＶＲ）モジュール生成部を使用して、ジョブ２１に対応するジョブ情報およびそのメトリックファイルに応じてリソースフィーチャーモデルを作成できる。上記のように、リソースフィーチャーモデル２３は、必要に応じて、ＣＰＵフィーチャーモデル、メモリフィーチャーモデル、ネットワークフィーチャーモデル、ディスク入出力（ディスクＩＯ）フィーチャーモデルなどであってこれに限定されない任意の多様なフィーチャーモデルを含んでいてよい。
【００３０】
クラスタコンピューティングシステム１が分散ファイルシステム１５を備えている場合、マスタデバイス１１のプロセッサ１１３は、ジョブ２１に対応するジョブ情報を事前に分散ファイルシステム１５に記憶でき、各々のスレーブデバイス１３のプロセッサ１３３は、分散ファイルシステム１５からジョブ２１に対応するジョブ情報を取得できる。
【００３１】
クラスタコンピューティングシステム１が分散ファイルシステム１５を備えていない場合、各々のスレーブデバイス１３のプロセッサ１３３は、ジョブ２１に対応するジョブ情報を他の方法で取得してもよい。例として、各々のスレーブデバイス１３のプロセッサ１３３は、接続インターフェース１３１および接続インターフェース１１１を介して、マスタデバイス１１からジョブ２１に対応するジョブ情報を取得してよい。もう１つの例として、各々のスレーブデバイス１３は、ジョブ２１に対応するジョブ情報を事前に記憶するための記憶装置（図示せず）を備えていてもよいし、ジョブ２１に対応するジョブ情報を他のデバイスから事前に取得してもよい。
【００３２】
本発明の当業者にとっては、マスタデバイス１１と複数のスレーブデバイス１３との相互作用は、同じく公知のものであってよいため、クラスタコンピューティングシステム１内でのマスタデバイス１１と単一のスレーブデバイス１３との相互作用をさらに説明するために、図２をこの実施形態の例示的な例とみなす。しかしながら、これは本発明を限定するためではなく、説明しやすくするために過ぎない。
図２は、クラスタコンピューティングシステム１にあるマスタデバイス１１および単一のスレーブデバイス１３の動作を示す概略構造図である。図２に示したスレーブデバイス１３は、図１に示した複数のスレーブデバイス１３のいずれであってもよい
【００３３】
図２に示したように、マスタデバイス１１は、任意選択として、前述した接続インターフェース１１１およびプロセッサ１１３の機能を達成するのを補助するために、以下の素子を備えていてよい。リソース管理部１１３１、ジョブ管理部１１３３、最適なリソースモジュール１１３５およびモデル管理部１１３７。
このほか、スレーブデバイス１３は、任意選択として、前述した接続インターフェース１３１およびプロセッサ１３３の機能を達成するのを補助するために、以下の素子を備えていてよい。スレーブ管理部１３３１、少なくとも１つのコンテナ１３３３、モデル生成部１３３５、ジョブステータス収集部１３３７およびメトリックファイル１３３９。
【００３４】
まず、ジョブ２１がマスタデバイス１１によって受信されると、リソース管理部１１３１は、ジョブ管理部１１３３を作動させ、その後ジョブ２１をジョブ管理部１１３３に移して処理する。同時に、リソース管理部１１３１は、スレーブ管理部１３３１からこのスレーブ管理部のデバイス情報２２を取得し、その後、デバイス情報２２をジョブ管理部１１３３に伝送してよい。次に、ジョブ管理部１１３３は、ジョブ２１およびデバイス情報２２を最適なリソースモジュール１１３５に伝送する。
ジョブ２１およびデバイス情報２２を取得した後、最適なリソースモジュール１１３５は、ジョブ２１およびデバイス情報２２に応じてモデル管理部１１３７からリソースフィーチャーモデル２３を取得する。同時に、最適なリソースモジュール１１３５は、ジョブ２１に対応するジョブ情報２５を分散ファイルシステム１５に記憶できる。次に、最適なリソースモジュール１１３５は、スレーブデバイス１３のコンテナ構成パラメータ２４をリソースフィーチャーモデル２３に応じて推定し、その後、コンテナ構成パラメータ２４をジョブ管理部１１３３に伝送する。最後に、ジョブ管理部１１３３は、コンテナ構成パラメータ２４をリソース管理部１１３１に伝送する。
【００３５】
コンテナ構成パラメータ２４を取得した後、リソース管理部１１３１は、コンテナ構成パラメータ２４をスレーブ管理部１３３１に伝送し、ジョブ２１をスレーブ管理部１３３１に割り当てる。スレーブ管理部１３３１は、少なくとも１つのコンテナ１３３３を生成して、コンテナ構成パラメータ２４に応じてジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）を計算する。
スレーブ管理部１３３１は、コンテナ構成パラメータ２４に応じて、コンテナ数１３３３のほか、コンテナ１３３３のＣＰＵ仕様およびメモリ仕様も判断できる。コンテナ１３３３によってジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）を計算するプロセスの過程で、ジョブステータス収集部１３３７は、コンテナ１３３３がジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）を計算しているジョブステータスを収集し、そのジョブステータスに対応するステータス情報２６をメトリックファイル１３３９に記憶する。
ステータス情報２６は、以下のものを含んでいてよいがこれに限定されない。各々のコンテナ１３３３のＣＰＵ消費量およびメモリ消費量。
【００３６】
ジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）がコンテナ１３３３によって計算された後、モデル生成部１３３５は、ジョブ２１に対応するジョブ情報２５（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）およびメトリックファイル１３３９に応じて、リソースフィーチャーモデル２３を作成または更新できる。例えば、モデル生成部１３３５は、サポートベクトル回帰モジュール生成部を使用して、ジョブ情報２５およびメトリックファイル１３３９に応じてリソースフィーチャーモデル２３を作成できる。
モデル生成部１３３５は、分散ファイルシステム１５から、かつ／またはスレーブ管理部１３３１からジョブ情報２５を取得できる。
分散ファイルシステム１５から取得したジョブ情報２５は、以下のものを含んでいてよいがこれに限定されない。データサイズ、Ｍａｐ／Ｒｅｄｕｃｅの見せかけの数など。スレーブ管理部１３３１から取得したジョブ情報２５は、以下のものを含んでいてよいがこれに限定されない。各々のコンテナによるＭａｐ／Ｒｅｄｕｃｅ計算に関する情報など。メトリックファイル１３３９から取得した情報は、以下のものを含んでいてよいがこれに限定されない。ステータス情報２６、計算プロセス中のハードウェア性能に関する情報など。
【００３７】
図３、図４、図５および図６は、最適なリソースモジュール１１３５、モデル管理部１１３７、モデル生成部１３３５およびジョブステータス収集部１３３７のそれぞれの特定の動作を示す概略図である。しかしながら、本発明の他の実施形態では、図２に示した最適なリソースモジュール１１３５、モデル管理部１１３７、モデル生成部１３３５およびジョブステータス収集部１３３７の動作は、図３〜図６に示したものに完全に従っている必要はないが、本発明の精神を逸脱しない限り、適切に調整、変更、かつ／または置換されてよい。
【００３８】
図３に示したように、最適なリソースモジュール１１３５は、ジョブ情報回収部１１３５ａ、利用可能なノード検査部１１３５ｂ、モデル搭載部１１３５ｃ、最適なリソース予測部１１３５ｄ、および最適なコンテナ数予測部１１３５ｅを備えていてよい。ジョブ２１がジョブ管理部１１３３によって取得された後、ジョブ情報回収部１１３５ａは、以下のデータを受信する。ジョブ名（例えばアルゴリズム名）、入力データサイズおよび全Ｍａｐ／Ｒｅｄｕｃｅタスク。
入力データサイズおよび全Ｍａｐ／Ｒｅｄｕｃｅタスクはその後、分散ファイルシステム１５に記憶される。利用可能なノード（すなわち利用可能なスレーブデバイス１３）がクラスタコンピューティングシステム１に現れると、ノード名は、利用可能なノード検査部１１３５ｂによって受信される。次に、モデル搭載部１１３５ｃは、ジョブ名およびノード名に応じて、モデル管理部１１３７内の対応するリソースフィーチャーモデル２３を検索する。
【００３９】
最適なリソース予測部１１３５ｄは、リソースフィーチャーモデル２３に応じて、ノードに対応するコンテナのＣＰＵ仕様およびメモリ仕様を予測でき、最適なコンテナ数予測部１１３５ｅは、ＣＰＵ仕様およびメモリ仕様に応じてノードのコンテナ数を推定できる。
したがって、前述した最適なリソース予測部１１３５ｄおよび最適なコンテナ数予測部１１３５ｅの動作を通して、ノードのコンテナ構成パラメータ２４は、最適なリソースモジュール１１３５によって推定され、その後、ジョブ管理部１１３３に伝送されることが可能である。
【００４０】
図４に示したように、モデル管理部１１３７は、要求処理部１１３７ａ、モデル回収部１１３７ｂ、同質モデルエンジン１１３７ｃおよび同質ノードエンジン１１３７ｄを備えていてよい。最適なリソースモジュール１１３５がリソースフィーチャーモデル２３を検索するための要求を出すと、要求処理部１１３７ａは、最適なリソースモジュール１１３５によって伝送されたジョブ名およびノード名に応じて、分散ファイルシステム１５または他のソースに記憶された複数のリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル２３を選択する。例えば、要求処理部１１３７ａは、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの１つをリソースフィーチャーモデル２３として選択してよい。
【００４１】
同質モデルエンジン１１３７ｃは、モデル情報回収部（図示せず）、モデル統合部（図示せず）およびグループ決定部（図示せず）を備えていてよい。リソースフィーチャーモデルのサンプルの数が多すぎると（例えば閾値よりも多いと）、モデル情報回収部は、各々のリソースフィーチャーモデルのサンプルに関する多様な情報を回収し、その後、モデル統合部は、そのような情報に応じてリソースフィーチャーモデルのサンプルを複数のグループに分類する。
例えば、モデル統合部は、Ｋ平均アルゴリズムを用いてリソースフィーチャーモデルのサンプルを複数のグループに分類してよい。このほか、任意選択として、モデル統合部は、リソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として、各々のグループから選択してよく、要求管理部１１３７ａは、最適なリソースモジュール１１３５によって伝送されたジョブ名およびノード名に応じて、リソースフィーチャーモデルの代表からリソースフィーチャーモデル２３を選択してよい。新たなリソースフィーチャーモデルのサンプルが現れると、グループ決定部は、新たなリソースフィーチャーモデルのサンプルの多様な情報に応じて、その新たなリソースフィーチャーモデルのサンプルを最も適切なグループに追加する。
【００４２】
同質ノードエンジン１１３７ｄは、ノード情報回収部（図示せず）、ノード統合部（図示せず）、グループ決定部（図示せず）およびグループモデル生成部（図示せず）を備えていてよい。ノード数（すなわちスレーブデバイス１３）が多すぎると（例えば閾値よりも多いと）、ノード情報回収部は、各々のノードの多様な情報（例えばハードウェア情報）を回収し、次にノード統合部は、そのような情報に応じてノードを複数のグループに分類する。
例えば、ノード統合部は、Ｋ平均アルゴリズムを用いてノードを複数のグループに分類してよい。新たなノードが現れると、グループ決定部は、その新たなノードの多様な情報に応じて、最も適切なグループに新たなノードを追加する。このほか、グループモデル生成部は、新たなノードが属するグループ内の訓練データを回収し、サポートベクトル回帰モジュール生成部を用いて新たなノードに対してリソースフィーチャーモデル２３を作成し、リソースフィーチャーモデル２３を分散ファイルシステム１５に記憶する。他の実施形態では、同質ノードエンジン１１３７ｄは、同質モデルエンジン１１３７ｃと組み合わされてよい。
【００４３】
図５に示したように、モデル生成部１３３５は、ジョブ終了検知部１３３５ａ、ジョブ情報回収部１３３５ｂおよびサポートベクトル回帰モデル生成部１３３５ｃを備えていてよい。ジョブ終了検知部１３３５ａは、ジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）が終了したかどうかを検知するように構成されている。
ジョブ２１（またはリソース管理部１１３１によって割り当てられたジョブ２１に対応するタスク）が終了した後、ジョブ情報回収部１３３５ｂは、分散ファイルシステム１５からジョブ２１に対応するジョブ情報２５を取得し、メトリックファイル１３３９から多様な情報（ステータス情報２６を含む）を取得する。次に、サポートベクトル回帰モジュール生成部１３３５ｃは、リソースフィーチャーモデル２３を作成し、これをジョブ情報２５およびメトリックファイル１３３９の多様な情報に応じて分散ファイルシステム１５に記憶する。
【００４４】
サポートベクトル回帰モジュール生成部１３３５ｃの入力データは、以下のものを含んでいてよいが、これに限定されない。ジョブ情報回収部１３３５ｂから得た履歴ジョブデータセットのサイズ、ジョブ情報回収部１３３５ｂから得た履歴ジョブのＭａｐタスクの合計数、ジョブ情報回収部１３３５ｂから得た履歴ジョブのＲｅｄｕｃｅタスクの合計数、履歴ジョブ内のノードに割り当てられたＭａｐコンテナ数、履歴ジョブ内のノードに割り当てられたＲｅｄｕｃｅコンテナ数、履歴ジョブ内の単一タスクのＣＰＵ使用率、履歴ジョブ内の単一タスクのメモリ使用率など。
履歴ジョブ内の単一タスクのＣＰＵ使用率は、動作中のＭａｐ数およびＲｅｄｕｃｅ数で割ったＣＰＵ使用率に等しく、履歴ジョブ内の単一タスクのメモリ使用率は、動作中のＭａｐ数およびＲｅｄｕｃｅ数で割ったメモリ使用率に等しい。ジョブ情報２５およびメトリックファイル１３３９の多様な情報は、以下のものを含んでいてよいが、これに限定されない。入力データサイズ、割り当てられたＭａｐタスク、割り当てられたＲｅｄｕｃｅタスク、割り当てられたＭａｐスロット、割り当てられたＲｅｄｕｃｅスロット、１タスク当たりの平均ＣＰＵ使用率、１タスク当たりの平均メモリ使用率など。
【００４５】
図６に示したように、ジョブステータス収集部１３３７は、ハードウェア性能収集部１３３７ａ、ジョブステータス収集部１３３７ｂおよびメトリック集計部１３３７ｃを備えていてよい。ハードウェア性能収集部１３３７ａは、コンテナ１３３３中のＣＰＵ使用率およびメモリ使用率に関する情報を収集するように構成され、ジョブステータス収集部１３３７ｂは、割り当てられたＭａｐスロット、割り当てられたＲｅｄｕｃｅスロット、計算されているＭａｐタスクおよび計算されているＲｅｄｕｃｅタスクに関する情報を収集するように構成されている。
メトリック集計部１３３７ｃは、ハードウェア性能収集部１３３７ａおよびジョブステータス収集部１３３７ｂによってメトリックファイル１３３９内に収集された情報を集計するように構成されている。メトリックファイル１３３９内に集計された情報は、以下のものを含むが、これに限定されない。割り当てられたＭａｐスロット、割り当てられたＲｅｄｕｃｅスロット、１タスク当たりの平均ＣＰＵ使用率、１タスク当たりの平均メモリ使用率など。１タスク当たりの平均ＣＰＵ使用率は、ＣＰＵ使用率を、計算されているＭａｐタスク数と計算されているリデュース処理されたタスク数との和で割ったものに等しく、１タスク当たりの平均メモリ使用率は、メモリ使用率を、計算されているＭａｐタスク数と動作しているリデュース処理されたタスク数との和で割ったものに等しい。
【００４６】
図３〜図６に示した最適なリソースモジュール１１３５、モデル管理部１１３７、モデル生成部１１３５およびジョブステータス収集部１３３７はそれぞれ、この実施形態の例示的な例として提供しているに過ぎず、本発明を限定する意図はない。
【００４７】
本発明のもう１つの実施形態（簡潔に「第２の実施形態」と呼ぶ）は、クラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイス用のコンピューティング方法である。クラスタコンピューティングシステム、マスタデバイスおよびスレーブデバイスはそれぞれ、前述した実施形態のクラスタコンピューティングシステム１、マスタデバイス１１およびスレーブデバイス１３であるとみなしてよい。
図７は、クラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイス用のコンピューティング方法を示す概略図である。
【００４８】
マスタデバイスに対して、この実施形態のコンピューティング方法は、以下のステップを含む。スレーブデバイスのデバイス情報をマスタデバイスのプロセッサで受信するステップＳ２１。デバイス情報およびジョブに応じて、スレーブデバイスに対するリソースフィーチャーモデルをマスタデバイスのプロセッサによって選択するステップＳ２３。リソースフィーチャーモデルに応じて、スレーブデバイスのコンテナ構成パラメータをマスタデバイスのプロセッサによって推定するステップＳ２５。コンテナ構成パラメータをマスタデバイスのプロセッサによってスレーブデバイスに伝送するステップＳ２７。および、ジョブをマスタデバイスのプロセッサによってスレーブデバイスに割り当てるステップＳ２９。
ステップＳ２１〜Ｓ２９を示す順序は、本発明を限定する意図はなく、本発明の精神を逸脱しない限り適切に調整できるものである。
【００４９】
本コンピューティング方法の例示的な一例では、クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、同システムはマスタデバイスとスレーブデバイスとで共有される。ステップＳ２３は、以下のステップを含む。デバイス情報およびジョブに応じて、分散ファイルシステムからスレーブデバイスに対するリソースフィーチャーモデルをマスタデバイスのプロセッサによって選択するステップ。この例では、コンピューティング方法は、任意選択としてさらに以下のステップを含んでいてよい。ジョブに対応するジョブ情報をマスタデバイスのプロセッサによって分散ファイルシステム内に記憶する。
【００５０】
本コンピューティング方法の例示的な一例では、リソースフィーチャーモデルは、ＣＰＵフィーチャーモデルおよびメモリフィーチャーモデルを含み、コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含む。コンテナ仕様は、ＣＰＵ仕様およびメモリ仕様を含む。
【００５１】
本コンピューティング方法の例示的な一例では、ステップＳ２３は、以下のステップを含む。デバイス情報およびジョブに応じて、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの１つを、スレーブデバイスに対するリソースフィーチャーモデルとして、マスタデバイスのプロセッサによって選択するステップ。対応するリソースフィーチャーモデルは、同様のリソースフィーチャーモデルに対して優先的に選択され、同様のリソースフィーチャーモデルは、事前設定されたリソースフィーチャーモデルに対して優先的に選択される。
【００５２】
本コンピューティング方法の例示的な一例では、ステップＳ２３は、以下のステップを含む。複数のリソースフィーチャーモデルのサンプルをマスタデバイスのプロセッサによって複数のグループに分類する。マスタデバイスのプロセッサによって、各々のグループからリソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として選択するステップ。および、マスタデバイスのプロセッサによって、リソースフィーチャーモデルの代表からスレーブデバイスに対するリソースフィーチャーモデルをデバイス情報およびジョブに応じて選択するステップ。
【００５３】
スレーブデバイスに対して、この実施形態のコンピューティング方法は、以下のステップを含む。デバイス情報をスレーブデバイスのプロセッサによってマスタデバイスに伝送するステップＳ３１。マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータを、スレーブデバイスのプロセッサによってマスタデバイスから受信するステップＳ３３。スレーブデバイスのプロセッサによって、コンテナ構成パラメータに応じてジョブを計算するために少なくとも１つのコンテナを生成するステップＳ３５。および、ジョブに対応するジョブ情報およびメトリックファイルに応じて、スレーブデバイスのプロセッサによってリソースフィーチャーモデルを作成するステップＳ３７。ステップＳ３１〜Ｓ３７を示す順序は、本発明を限定する意図はなく、本発明の精神を逸脱しない限り適切に調整できるものである。
【００５４】
本コンピューティング方法の例示的な一例では、クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、同システムはマスタデバイスとスレーブデバイスとで共有される。ステップＳ３７は、以下のステップを含む。スレーブデバイスのプロセッサによって、ジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを分散ファイルシステム内に形成するステップ。この例では、コンピューティング方法は、任意選択としてさらに以下のステップを含んでいてよい。スレーブデバイスのプロセッサによって分散ファイルシステムからジョブ情報を取得するステップ。
【００５５】
本コンピューティング方法の例示的な一例では、コンピューティング方法はさらに、以下のステップを含む。コンテナがジョブを計算するジョブステータスを収集し、そのジョブステータスに対応するステータス情報を、スレーブデバイスのプロセッサによってメトリックファイル内に記憶するステップ。
【００５６】
本コンピューティング方法の例示的な一例では、リソースフィーチャーモデルは、ＣＰＵフィーチャーモデルおよびメモリフィーチャーモデルを含み、コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、コンテナ仕様は、ＣＰＵ仕様およびメモリ仕様を含む。
【００５７】
本コンピューティング方法の例示的な一例では、ステップＳ３７は、以下のステップを含む。プロセッサによってサポートベクトル回帰モジュール生成部を使用して、ジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成するステップ。
【００５８】
第２の実施形態のコンピューティング方法は、本質的に、前回の実施形態のマスタデバイス１１およびスレーブデバイス１３の動作に対応するステップをすべて含む。本発明の当業者は、前回の実施形態の関連する開示に従って、第２の実施形態に記載していないコンピューティング方法を直接理解できる。
【００５９】
以上に記載してきた内容に加えて、第２の実施形態のコンピューティング方法はさらに、前回の実施形態のマスタデバイス１１およびスレーブデバイス１３の他の動作に対応するステップを含む。第２の実施形態のコンピューティング方法が、第２の実施形態で開示していないこれらの対応するステップを実行する方法は、第１の実施形態の関連する開示に基づいて本発明の当業者が容易に理解できるものであるため、本明細書ではこれ以上説明しない。
【００６０】
上記の説明によれば、本発明は、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法を提供する。本発明によれば、マスタデバイスが、各々のスレーブデバイスによって伝送されたデバイス情報を受信し、デバイス情報およびジョブに応じて各々のスレーブデバイスに対するリソースフィーチャーモデルを選択し、各々のリソースフィーチャーモデルに応じて、対応するスレーブデバイスのコンテナ構成パラメータを推定し、各々のコンテナ構成パラメータを対応するスレーブデバイスに伝送し、スレーブデバイスにジョブを割り当てる。
本発明によれば、スレーブデバイスが、スレーブデバイスのデバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも１つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成する。
【００６１】
したがって、本発明のスレーブデバイスによって生成されたコンテナの仕様は、動的に調整でき、よって様々なジョブの様々な特性が原因であるリソースの無駄がなくなる。さらに、コンテナ仕様は本発明の各々のコンテナに対して一定ではないため、本発明のスレーブデバイスのコンテナ数も動的に調整でき、よってリソースのアイドル状態がなくなる。このほか、本発明のスレーブデバイスによって生成されたコンテナ仕様およびコンテナ数を動的に調整できるため、複数のスレーブデバイスが様々なデバイス性能を有する場合であっても、リソースの不適切な割り当てが起こらない。
【００６２】
上記の開示は、詳細な技術内容およびその発明性のある特徴に関するものである。当業者は、本発明の特徴を逸脱しない限り、記載した本発明の開示および提示に基づいて多種多様な修正および置換を加えてよい。ただし、そのような修正および置換は、上記の説明文には完全に開示されていないが、実質的には以下の付属の特許請求の範囲内に含まれている。
【図１】
0006001690.tif 000002
【図２】
0006001690.tif 000003
【図３】
0006001690.tif 000004
【図４】
0006001690.tif 000005
【図５】
0006001690.tif 000006
【図６】
0006001690.tif 000007
【図７】
0006001690.tif 000008