JP6926979B2 - データ収集方法、情報処理装置および分散処理システム - Google Patents

Description

本発明は、データ収集方法等に関する。

ネットワークに接続された各エッジサーバは、自律的に、高負荷時にタスクを他のエッジサーバに分散することが知られている。例えば、各エッジサーバは、全エッジサーバから全リソースに関するリソースの使用率を定期的に収集する。そして、エッジサーバに処理負荷が集中したときに、このエッジサーバは、要求を満たすエッジサーバにタスクを分散する。

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

しかしながら、各エッジサーバが全エッジサーバから全リソースに関するリソースの使用状況を定期的に収集すると、収集する際のメッセージの数が膨大になるという第１の問題がある。

ここで、メッセージの数が膨大になることを抑制するために、各エッジサーバが、隣接のエッジサーバでそれぞれグループを作り、グループ内の各リソースの使用状況を定期的に収集することも考えられる。しかしながら、各エッジサーバは、処理負荷が集中したときに、グループ内でタスクを分散できない場合には、ホップバイホップで探索することとなり、分散対象をみつけるのに時間がかかるという第２の問題がある。

１つの側面では、メッセージの数を抑えつつ、リソース探索時間を削減することを目的とする。

本願の開示する分散処理システムのデータ収集方法では、第１の情報処理装置は、収集対象の複数のリソースの中で、要求リソース量を満たす情報処理装置を探索する時間がかかる所定のリソースを絞り込み、該絞り込んだ所定のリソースの情報を前記第１の情報処理装置の第１のグループに属する第２の情報処理装置に通知する。前記第２の情報処理装置は、前記第２の情報処理装置が属するグループであって、第１のグループと異なる第２のグループに属する情報処理装置から前記収集対象の複数のリソースのリソース量を定期的に収集し、予め定められたタイミングで、前記収集した情報から前記第２のグループに属する情報処理装置の前記所定のリソースのリソース量を取得し、前記所定のリソースのリソース量が予め定められるリソース量を満たしていれば、前記所定のリソースのリソース量を満たす情報処理装置の装置情報を、前記第２の情報処理装置の前記収集対象の複数のリソースのリソース量に追加して前記第１の情報処理装置へ定期的に通知する、処理を実行する。

１つの態様によれば、メッセージの数を抑えつつ、リソース探索時間を削減することができる。

図１は、実施例１に係る分散処理システムの機能構成を示す図である。 図２は、実施例１に係る事前探索リソース決定を説明する図である。 図３は、平均探索ホップ数と希少度との関係を説明する図である。 図４は、実施例１に係る定期通知を説明する図である。 図５は、実施例１に係るデータ収集処理の流れの一例を示す図である。 図６は、実施例１に係るデータ収集処理のシーケンスの一例を示す図である。 図７は、希少度情報の一例を示す図である。 図８は、要求頻度情報の一例を示す図である。 図９は、リソース値情報の一例を示す図である。 図１０は、アドレス情報の一例を示す図である。 図１１は、要求リソース情報の一例を示す図である。 図１２は、データ情報の一例を示す図である。 図１３は、タスク情報の一例を示す図である。 図１４は、定期通知の一例を示す図である。 図１５は、リソース探索要求の一例を示す図である。 図１６は、事前探索要求の一例を示す図である。 図１７は、再探索要求の一例を示す図である。 図１８は、実施例１に係る事前探索リソース決定部の処理のフローチャートの一例を示す図である。 図１９は、実施例１に係る定期通知部の処理のフローチャートの一例を示す図である。 図２０は、実施例１に係るリソース探索部の処理のフローチャートの一例を示す図である。 図２１Ａは、実施例１に係る応答部の処理のフローチャートの一例を示す図（１）である。 図２１Ｂは、実施例１に係る応答部の処理のフローチャートの一例を示す図（２）である。 図２２Ａは、実施例１に係る登録部の処理のフローチャートの一例を示す図（１）である。 図２２Ｂは、実施例１に係る登録部の処理のフローチャートの一例を示す図（２）である。 図２３は、実施例１に係るタスクスケジューラの処理のフローチャートの一例を示す図である。 図２４は、実施例２に係るデータ収集処理の流れの一例を示す図である。 図２５は、データ収集プログラムを実行するコンピュータの一例を示す図である。

以下に、本願の開示するデータ収集方法、情報処理装置および分散処理システムの実施例を図面に基づいて詳細に説明する。なお、実施例では、実施例によりこの発明が限定されるものではない。

［分散処理システムの構成］
図１は、実施例１に係る分散処理システムの機能構成を示す図である。分散処理システム９では、エッジサーバ（ＥＳ）１は、自己のエッジサーバ１で処理負荷が集中したときにタスクを分散させるため、他のエッジサーバ１のリソースのリソース量を把握する必要がある。このため、エッジサーバ１は、グループに属するエッジサーバから全リソースのリソース量を定期的に収集し、さらに、希少度が高いリソースについて要求リソース量を満たすグループ外のエッジサーバ１のサーバ情報を事前に収集するようにする。なお、以降、ＥＳとは、エッジサーバの略語であるとする。

ここでいう「グループ」は、例えば、ネットワークの遅延が小さいエッジサーバ１同士を纏め、エッジサーバ１を重複して組み合わせたものである。すなわち、各エッジサーバ１は、複数のグループに属する。

ここでいう「希少度」とは、リソースについて要求リソース量を満たさない度合いのことをいい、例えば、リソースについて要求リソース量を満たさないエッジサーバの全エッジサーバに対する割合のことをいう。希少度が高いリソースとは、要求リソース量を満たさないエッジサーバの数が他のリソースより多いリソースのことを意味する。希少度が高いリソースは、要求リソース量を満たすエッジサーバの数が少ないので、エッジサーバ１は、リソース量を定期的に収集する際に、希少度が高いリソースの要求リソース量を満たすグループ外のエッジサーバ１のサーバ情報を把握しておく。

分散処理システム９は、複数のエッジサーバ１と、管理サーバ２と、を有する。複数のエッジサーバ１は、ネットワークを介して互いに接続する。また、複数のエッジサーバ１は、それぞれネットワークを介して管理サーバ２と接続する。

管理サーバ２は、分散処理システム９内の複数のエッジサーバ１の負荷を監視する。例えば、管理サーバ２は、エッジサーバ１で収集される全リソースに対する希少度を、予め定められた時点毎に算出する。管理サーバ２は、所定のタイミングで、全リソースに対する希少度を全エッジサーバ１に送信する。なお、所定のタイミングは、全リソースのうちいずれかのリソースの希少度が変化したタイミングであっても良いし、予め定められた定期的または不定期的なタイミングであっても良い。

エッジサーバ１は、制御部１０および記憶部３０を有する。

制御部１０は、ＣＰＵ（Central Processing Unit）等の電子回路に対応する。そして、制御部１０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１０は、受信部１１、分散リソース管理部１２、事前探索リソース決定部１３、定期通知部１４、リソース探索部１５、応答部１６および登録部１７を有する。加えて、エッジサーバ１は、データ受信部１８、データ・タスク管理部１９、タスク配備場所決定部２０およびタスク実行部２１を有する。なお、データ受信部１８、データ・タスク管理部１９、タスク配備場所決定部２０およびタスク実行部２１は、タスクスケジューラに含まれる。

記憶部３０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置である。記憶部３０は、希少度情報３１、要求頻度情報３２、リソース値情報３３、アドレス情報３４、要求リソース情報３５、データ情報３６およびタスク情報３７を有する。

希少度情報３１は、リソース毎の希少度に関する情報である。例えば、希少度情報３１は、リソースに対する希少度から得られる要求リソース量を満たすまでの平均探索ホップ数の情報である。希少度は、例えば、リソースについて要求リソース量を満たさないエッジサーバの全エッジサーバに対する割合である。したがって、リソースについて、希少度が高ければ高い程、要求リソース量を満たすまでの平均探索ホップ数が大きくなるという関係がある。一方、リソースについて、希少度が低ければ低い程、要求リソース量を満たすまでの平均探索ホップ数が小さくなるという関係がある。つまり、希少度情報３１は、希少度に関する情報として、平均探索ホップ数の情報を適用する。なお、希少度情報３１の一例は、後述する。

要求頻度情報３２は、リソース毎の要求頻度に関する情報である。なお、要求頻度情報３２の一例は、後述する。

リソース値情報３３は、グループ内のエッジサーバ１およびグループ外のエッジサーバ１のリソース値に関する情報である。グループ内のエッジサーバ１のリソース値は、全リソースに対するリソース値である。グループ外のエッジサーバ１のリソース値は、希少度情報３１と要求頻度情報３２とをリソース毎に畳み込み演算することで決定されるリソースのリソース値である。畳み込み演算は、例えば、加算であっても乗算であっても良い。以降では、畳み込み演算を乗算として説明する。なお、リソース値情報３３の一例は、後述する。

アドレス情報３４は、グループ内に属するエッジサーバ１のアドレス、グループ外のエッジサーバ１のアドレスに関する情報である、アドレス情報３４には、グループ内で要求リソースが枯渇する場合にグループ外に要求リソースがある場合には、要求リソースを探索中であることを示すフラグがアドレスに対応付けて設定される。なお、アドレス情報３４の一例は、後述する。

要求リソース情報３５は、タスク毎に要求するリソース（要求リソース）に関する情報である。要求リソース情報３５には、タスクが要求する要求リソースおよびリソース使用量が対応付けて設定される。なお、要求リソース情報３５の一例は、後述する。

データ情報３６は、処理対象データに関する情報である。なお、データ情報３６の一例は、後述する。

タスク情報３７は、タスクに関する情報である。例えば、タスク情報３７は、実行するタスクとタスクが処理する処理対象データとの対応付けを示す情報である。なお、タスク情報３７の一例は、後述する。

受信部１１は、他のエッジサーバ１および管理サーバ２から各種の主信号メッセージを受信する。

分散リソース管理部１２は、分散したリソースを管理する。分散リソース管理部１２は、事前探索リソース決定部１３、定期通知部１４、リソース探索部１５、応答部１６、登録部１７およびタスク配備場所決定部２０に、それぞれの所定のタイミングで制御メッセージを送信する。

事前探索リソース決定部１３は、希少度情報３１および要求頻度情報３２を参照し、事前に探索するリソースを決定する。例えば、事前探索リソース決定部１３は、管理サーバ２から送信される全リソースに対する希少度を希少度情報３１に変換する。すなわち、事前探索リソース決定部１３は、各リソースについて、要求リソース量を満たさないエッジサーバの全エッジサーバに対する割合から、要求リソース量を満たすまでの平均探索ホップ数へ変換する。そして、事前探索リソース決定部１３は、各リソースについて、平均探索ホップ数を希少度に関する情報として希少度情報３１に設定する。そして、事前探索リソース決定部１３は、リソース毎に、希少度情報３１と要求頻度情報３２とを乗算し、乗算して得られた値の上位から、予め定められた個数のリソースを選択する。そして、事前探索リソース決定部１３は、選択したリソースのランキングが変動したか否かを判定する。事前探索リソース決定部１３は、選択したリソースのランキングが変動した場合には、選択した事前探索リソースの情報を含む事前探索要求をグループ内のエッジサーバ１に送信する。ここでいう「事前探索要求」とは、リソースが枯渇する前に事前に依頼する探索要求のことをいう。すなわち、事前探索リソース決定部１３は、枯渇しやすいリソースを決定し、決定したリソースが枯渇する前に定期通知の際に探索するように、グループ内のエッジサーバ１に依頼する。なお、事前探索リソース決定部１３は、選択したリソースのランキングが変動しない場合には、グループ内のエッジサーバ１に既に依頼済みであるので、事前探索要求を送信しない。

ここで、事前探索リソース決定を、図２および図３を参照して説明する。図２は、実施例１に係る事前探索リソース決定を説明する図である。なお、事前探索リソース決定部１３は、管理サーバ２から送信される全リソースに対する希少度を希少度情報３１に変換したものとする。図２に示すように、事前探索リソース決定部１３は、リソース毎に、希少度情報３１と要求頻度情報３２とを乗算する。ここでは、希少度情報３１には、リソース毎の平均探索ホップ数が表わされている。平均探索ホップ数は、希少度に関する情報として適用されている。

図３は、平均探索ホップ数と希少度との関係を説明する図である。図３に示すように、上図には、リソース毎の要求リソース量を満たすエッジサーバ数が表わされている。ここでは、要求リソース量を満たすエッジサーバ数が少なければ少ない程、希少度が高いリソースとなる。言い換えれば、要求リソース量を満たさないエッジサーバ数が多ければ多い程、希少度が高いリソースとなる。すなわち、要求リソース量を満たさないエッジサーバ数が多ければ多い程、要求リソース量を満たさないエッジサーバの全エッジサーバに対する割合が高いリソースとなる。つまり、希少度が高いリソースとなる。例えば、ｋに対するリソースが、希少度が最も高い。

下図には、リソース毎の、要求リソース量を満たすまでの平均探索ホップ数が表わされている。リソースに対して希少度が高ければ高い程、平均探索ホップ数が大きくなるという関係がある。要求リソース量を満たすエッジサーバ数が少ないと、要求リソース量を満たすまでの平均探索ホップ数が大きくなり、探索に時間がかかるからである。同様に、リソースに対して希少度が低ければ低い程、平均探索ホップ数が小さくなるという関係がある。要求リソース量を満たすエッジサーバ数が多いと、要求リソース量を満たすまでの平均探索ホップ数が小さくなり、探索に時間がかからないからである。したがって、平均探索ホップ数は、希少度に関する情報として適用できる。

図２に戻って、事前探索リソース決定部１３は、リソース毎に乗算された計算値の上位から予め定められた個数だけ事前探索するリソースを絞り込む。事前探索するリソースの個数は、システムの大きさに応じて決定されれば良い。ここでは、リソース６とリソース７が絞り込まれる。この後、事前探索リソース決定部１３は、絞り込んだリソースのランキングが変動した場合には、絞り込んだ事前探索リソースの情報を含む事前探索要求をグループ内のエッジサーバ１に送信する。

定期通知部１４は、定期的に、定期通知メッセージをグループ内のエッジサーバ１に通知する。

例えば、定期通知部１４は、予め定められたタイミングで、リソース値情報３３から、事前探索リソースに対して、グループ内のエッジサーバ１のリソース値を取得する。そして、定期通知部１４は、事前探索リソースに対して、要求リソース量を満たすエッジサーバ１があるか否かを判定する。定期通知部１４は、要求リソース量を満たすエッジサーバ１がある場合には、アドレス情報３４から当該エッジサーバ１のアドレスを取得する。そして、定期通知部１４は、自身の全リソースのリソース値情報に、事前探索リソースに対して要求リソース量を満たすエッジサーバ１のアドレスを追加した定期通知メッセージをグループ内のエッジサーバ１に送信する。定期通知部１４は、要求リソース量を満たすエッジサーバ１がない場合には、自身の全リソースのリソース値情報だけを含む定期通知メッセージをグループ内のエッジサーバ１に送信する。

また、定期通知部１４は、グループ外のエッジサーバ１から後述するリソース探索要求が受信されている場合には、以下の処理を行う。定期通知部１４は、リソース値情報３３からリソース探索要求されたリソースのリソース値を取得し、グループ外のエッジサーバ１の通知先に対して、自身のリソース値情報と結果情報を含む定期通知メッセージを送信する。「リソース探索要求」とは、グループ内でリソースが枯渇した場合に枯渇したリソースの探索をグループ外に依頼する探索要求のことをいう。

リソース探索部１５は、リソースが枯渇した場合に、枯渇したリソースについて、要求リソース量を満たす他のエッジサーバ１を探索する。例えば、リソース探索部１５は、各リソースについて、以下の処理を行う。リソース探索部１５は、リソースについて、リソース値情報３３からグループ内のエッジサーバ１毎のリソース値を取得する。リソース探索部１５は、リソースについて、グループ内のエッジサーバ１毎に取得したリソース値を合計し、合計値が閾値を超える場合には、このリソースが枯渇したと判断する。リソース探索部１５は、アドレス情報３４から、このリソースの要求リソース量を満たすエッジサーバ１がグループ外にあるか否かを判定する。リソース探索部１５は、このリソースの要求リソース量を満たすエッジサーバ１がグループ外にある場合には、このリソースに対するリソース探索要求を、当該エッジサーバ１に送信する。リソース探索部１５は、このリソースの要求リソース量を満たすエッジサーバ１がグループ外にない場合には、このリソースに対するリソース探索要求を、トポロジ情報から得られるネットワーク遅延の小さいエッジサーバ１へ送信する。

応答部１６は、リソース探索要求を受信した場合に、応答する。例えば、応答部１６は、要求されたリソースに対するリソース値をリソース値情報３３から取得する。応答部１６は、自身がリソースの要求リソース量を満たす場合には、要求されたリソースに対するリソース値を含む定期通知要求（定期通知メッセージ）を登録部１７に送信する。応答部１６は、自身がリソースの要求リソース量を満たさず、他のエッジサーバ１がリソースの要求リソース量を満たす場合には、当該他のエッジサーバ１に、リソース探索要求を転送する。応答部１６は、自身がリソースの要求リソース量を満たさず、他のエッジサーバ１がリソースの要求リソース量を満たさない場合には、リソース探索要求元に再探索要求を転送する。

また、応答部１６は、再探索要求を受信した場合に、応答する。例えば、応答部１６は、アドレス情報３４を参照し、リソース探索要求を直近に送信したエッジサーバ１の次に近いエッジサーバ１を選択する。そして、応答部１６は、選択したエッジサーバ１にリソース探索要求を送信する。

登録部１７は、事前探索要求を受信した場合に、事前探索要求に含まれたリソースの情報をアドレス情報３４の要求リソースの欄に登録する。そして、登録部１７は、事前探索要求を、グループ内のエッジサーバ１の数に応じた事前探索要求範囲（ＴＴＬ：Time To Live）のエッジサーバ１に転送する。ここでいう事前探索要求範囲は、任意のホップ数で表わされれば良い。一例として、グループ内にエッジサーバ１が２台であれば、ホップ数を１とすれば良い。グループ内にエッジサーバ１が６台であれば、ホップ数を５とすれば良い。すなわち、登録部１７は、事前探索要求範囲を用いて、グループ内のエッジサーバ１全てに事前探索要求を転送する。

また、登録部１７は、定期通知メッセージを受信した場合に、定期通知メッセージに含まれる、通知元のエッジサーバ１のリソースのリソース値をリソース値情報３３に登録する。そして、登録部１７は、定期通知メッセージにグループ外の情報が含まれている場合には、グループ外の情報に含まれるアドレスと事前探索リソースの種類とをアドレス情報３４に登録する。

データ受信部１８は、ＩｏＴ（Internet of Things）デバイスからデータを受信する。ＩｏＴデバイスには、例えば、携帯通信機器であるが、インターネットを通じて接続され、監視や制御を可能にするデバイスであれば良い。

データ・タスク管理部１９は、データやタスクを管理する。例えば、データ・タスク管理部１９は、データ受信部１８によって受信されたデータを処理対象データとしてデータ情報３６に登録する。データ・タスク管理部１９は、実行するタスクを処理対象データと紐付けて、タスクを管理する。データ・タスク管理部１９は、タスク毎に要求するリソースをリソース使用量とともに管理する。

タスク配備場所決定部２０は、タスクを配備する場所を決定する。例えば、タスク配備場所決定部２０は、タスクが要求するリソースに対するリソース使用量を要求リソース情報３５から取得する。タスク配備場所決定部２０は、リソース値情報３３を参照して、リソースの要求を満たす場所（アドレス）がある場合には、この場所にタスクを配備する。タスク配備場所決定部２０は、リソース要求を満たす場所がない場合には、このタスクを待ちキュー（queue）に入れる。

タスク実行部２１は、タスク配備場所決定部２０によって配備されたタスクを実行する。

［定期通知の説明］
ここで、定期通知を、図４を参照して説明する。図４は、実施例１に係る定期通知を説明する図である。なお、Ａ、Ｂ、Ｃは、それぞれエッジサーバ１である。ＡおよびＢは、グループαに属する。ＢおよびＣは、グループβに属する。Ｂは、複数のグループに属する。図４では、ＢからＡに定期通知する場合に着目して説明する。Ｂは、同じグループαに属するＡから事前探索リソースの情報を含む事前探索要求を受け取っているとする。

図４に示すように、定期通知部１４は、定期タイマーにより予め定められた時点で、事前探索リソースについて、グループβ内のエッジサーバＣのリソース値を取得する。そして、定期通知部１４は、エッジサーバＣのリソース値が要求リソース量を満たす場合には、自身の全リソースのリソース値情報に、エッジサーバＣのアドレスを追加した定期通知メッセージをグループα内のエッジサーバＡに送信する。すなわち、エッジサーバＢの定期通知部１４が、エッジサーバＡに通知する定期通知メッセージに希少度が高いリソースの要求リソース量を満たすグループ外（β）のエッジサーバＣの情報を追加する。そして、定期通知部１４は、当該定期通知メッセージをグループα内のエッジサーバＡに送信する。

この後、エッジサーバＡのリソース探索部１５は、希少度が高いリソースがグループα内で枯渇した場合に、このリソースに対するリソース探索要求をグループ外のエッジサーバＣに送信する。これにより、リソース探索部１５は、リソースがグループ内で枯渇しても、リソースの要求リソース量を満たすと予想されるグループ外のエッジサーバ１にリソース探索を要求できるため、探索時間を削減できる。

［データ収集処理の流れ］
図５は、実施例１に係るデータ収集処理の流れの一例を示す図である。なお、図５では、ａ、ｂ、ｃは、それぞれエッジサーバ１である。ａおよびｂは、グループαに属する。ｂおよびｃは、グループβに属する。ｂは、複数のグループに属する。

エッジサーバａでは、受信部１１が、管理サーバ２から希少度を受信する。事前探索リソース決定部１３は、希少度から変換された希少度情報３１および要求頻度情報３２から、事前に探索するリソースを決定する（＜１＞）。そして、事前探索リソース決定部１３は、事前探索要求をグループα内のエッジサーバｂに送信する（＜２−１＞）。

エッジサーバｂでは、登録部１７が、事前探索要求を受信すると、事前探索要求に含まれたリソースの情報をアドレス情報３４に登録する（＜２−２＞）。

エッジサーバｃでは、定期通知部１４が、定期タイマーにより予め定められた時点で、同じグループβのエッジサーバｂに定期通知を行う（＜３−１＞，＜３−２＞）。例えば、定期通知部１４は、自身の全リソースのリソース値情報を含む定期通知メッセージをエッジサーバｂに送信する。

エッジサーバｂでは、登録部１７が、定期通知メッセージを受信すると、グループβ内の通知元のエッジサーバｃのリソース値情報を登録する（＜３−３＞）。そして、定期通知部１４が、定期タイマーにより予め定められた時点で、同じグループαのエッジサーバａに定期通知を行う（＜５−１＞，＜５−２＞）。例えば、定期通知部１４は、事前探索リソースに対して要求リソース量を満たすエッジサーバ１がある場合には、自身の全リソースのリソース値情報にこのエッジサーバ１のアドレスを追加した定期通知メッセージをエッジサーバａに送信する。ここでは、事前探索リソースに対して要求リソース量を満たすエッジサーバ１としてエッジサーバｃがあれば、定期通知部１４は、このエッジサーバｃのアドレスと事前探索リソースの種類とを追加した定期通知メッセージをエッジサーバａに送信する。

エッジサーバａでは、登録部１７が、定期通知メッセージを受信すると、グループα内の通知元のエッジサーバｂのリソース値情報を登録する（＜５−３＞）。加えて、登録部１７は、グループ外のエッジサーバｃのアドレスとリソースの種類とをアドレス情報３４に登録する（＜６＞）。

エッジサーバａでは、リソース探索部１５が、グループα内であるリソースの閾値が超えたとする（＜７＞）。すると、リソース探索部１５は、閾値を超えたリソースの要求リソース量を満たすグループ外のアドレスの有無を判定する（＜８＞）。リソース探索部１５は、閾値を超えたリソースの要求リソース量を満たすグループ外のアドレスが有る場合には、このアドレスのエッジサーバｃにリソース探索要求を送信する（＜９−１＞）。

エッジサーバｃでは、応答部１６は、リソース探索要求を受信すると、自身が要求された要求リソースのリソース量を満たすか否かを判定する（＜９−２＞）。応答部１６は、自身が要求された要求リソースのリソース量を満たす場合には、定期通知要求（定期通知メッセージ）を登録部１７に送信する（＜１０−１＞）。そして、登録部１７は、通知元のエッジサーバｃの要求された要求リソースのリソース量をリソース値情報３３に登録するとともに、要求リソースと要求元アドレスとをアドレス情報３４に登録する（＜１０−２＞）。この後、定期通知部１４が、リソース探索要求された要求元アドレスが示すグループ外のエッジサーバａに対して、登録部１７によって登録された自身のリソース値情報と結果情報を含む定期通知メッセージを送信する。また、応答部１６は、自身が要求された要求リソースのリソース量を満たさず、他のエッジサーバ１が満たす場合には、当該他のエッジサーバ１に、リソース探索要求を転送する（＜１２＞）。応答部１６は、自身が要求された要求リソースのリソース量を満たさず、他のエッジサーバ１も満たさない場合には、リソース探索要求元のエッジサーバａに再探索要求を転送する（＜１３＞）。

エッジサーバａでは、リソース探索部１５が、閾値を超えたリソースの要求リソース量を満たすグループ外のアドレスが無い場合には、リソース探索要求をトポロジ情報から得られるネットワーク遅延の小さいエッジサーバ１へ送信する（＜１４＞）。

［データ収集処理のシーケンス］
図６は、実施例１に係るデータ収集処理のシーケンスの一例を示す図である。なお、図６では、ａ、ｂ、ｃ、ｄ、ｅ、ｆは、それぞれエッジサーバ１である。ａ、ｂおよびｃは、グループαに属する。ｂおよびｄは、グループβに属する。ｃおよびｅは、グループγに属する。ｂおよびｃは、複数のグループに属する。また、図６では、管理サーバ２をＣｅｎｔＥＳと記載する。

エッジサーバａは、管理サーバ２から希少度を受信する（Ｓ１１）と、希少度が変化したか否かを判定する（Ｓ１２）。希少度が変化しない場合には（Ｓ１２；Ｎｏ）、エッジサーバａは、事前探索するリソースを決定しない。一方、希少度が変化する場合には（Ｓ１２；Ｙｅｓ）、エッジサーバａは、事前探索するリソースを決定する（Ｓ１３）。

エッジサーバａは、決定した事前探索リソースの情報を含む事前探索要求をグループα内のエッジサーバｂ，ｃに送信する（Ｓ１４，Ｓ１５）。

エッジサーバｂは、同じグループβ内のエッジサーバｄからエッジサーバｄの全リソースのリソース値情報を受信したものとする。なお、エッジサーバｄから受信したリソース値情報は、事前探索リソースの要求を満たさないものとする。エッジサーバｃは、同じグループγ内のエッジサーバｅからエッジサーバｅの全リソースのリソース値情報を受信したものとする。なお、エッジサーバｅから受信したリソース値情報は、事前探索リソースの要求を満たすものとする。

このような状況の下、エッジサーバｂは、エッジサーバａから送信された事前探索リソースの要求を満たすエッジサーバがグループβ内で存在するか否かを判定する（Ｓ１６）。エッジサーバｂは、事前探索リソースの要求を満たすエッジサーバがグループβ内で存在しないので、エッジサーバｂの全リソースのリソース値情報だけを含む定期通知メッセージをエッジサーバａに送信する（Ｓ１７）。

エッジサーバｃは、エッジサーバａから送信された事前探索リソースの要求を満たすエッジサーバがグループγ内で存在するか否かを判定する（Ｓ１６）。エッジサーバｃは、事前探索リソースの要求を満たすエッジサーバがグループγ内で存在するので、エッジサーバｃの全リソースのリソース値情報に、事前探索リソースの要求を満たすエッジサーバｅのアドレスを追加した定期通知メッセージをエッジサーバａに送信する（Ｓ１８）。

この後、エッジサーバａは、グループα内で、事前探索リソースのリソース値が閾値を超えると、事前探索リソースの要求を満たすと予想されるエッジサーバｅにリソース探索要求を送信する（Ｓ１９，Ｓ２０）。これにより、エッジサーバａは、リソースがグループα内で枯渇しても、リソースの要求リソース量を満たすと予想されるグループ外のエッジサーバｅにリソース探索を要求できるため、探索時間を削減できる。

エッジサーバａは、エッジサーバｅへのリソース探索に成功すると、グループαにエッジサーバｅを追加してグループαを拡大しても良い（Ｓ２１，Ｓ２２）。これにより、エッジサーバａは、グループαを拡大した後、リソース探索をグループ外に要求しなくても、グループ内で直接探索することができ、探索時間を削減できる。

エッジサーバａは、エッジサーバｅへのリソース探索に失敗すると、事前探索リソースの再探索要求をトポロジ情報から得られるネットワーク遅延の小さいエッジサーバｆへ送信する（Ｓ２３〜Ｓ２５）。

そして、エッジサーバａは、エッジサーバｆへのリソース探索に成功すると、グループαにエッジサーバｆを追加してグループαを拡大しても良い（Ｓ２６，Ｓ２７）。これにより、エッジサーバａは、グループαを拡大した後、リソース探索をグループ外に要求しなくても、グループ内で直接探索することができ、探索時間を削減できる。

図７〜図１３は、記憶部３０に記憶された各種情報の一例を示す図である。

［希少度情報の一例］
図７は、希少度情報の一例を示す図である。図７に示すように、希少度情報３１は、リソースと平均探索ホップ数とを対応付けた情報である。リソースは、対象となるリソースである。平均探索ホップ数は、リソースが要求する要求リソース量を満たすまで探索を要する平均的なホップ数である。平均探索ホップ数は、希少度に対応する。一例として、リソースが「ＣＰＵ」である場合に、平均探索ホップ数として「２ホップ」が設定されている。リソースが「ＧＰＵ」である場合に、平均探索ホップ数として「７ホップ」が設定されている。図７の例では、「ＧＰＵ」が、希少度が高いリソースである。

［要求頻度情報の一例］
図８は、要求頻度情報の一例を示す図である。図８に示すように、要求頻度情報３２は、リソースとリソース要求回数とを対応付けた情報である。リソースは、対象となるリソースである。リソース要求回数は、リソースに対して一定時間内に要求する回数である。一例として、リソースが「ＣＰＵ」である場合に、リソース要求回数として「４０回」が設定されている。リソースが「ＧＰＵ」である場合に、リソース要求回数として「２０回」が設定されている。

［リソース値情報の一例］
図９は、リソース値情報の一例を示す図である。図９に示すように、リソース値情報３３は、アドレス、自ｏｒ他フラグ、リソースおよびリソース使用量を対応付けた情報である。アドレスは、エッジサーバ１のアドレスである。アドレスは、一例として、ＩＰ（Internet Protocol）アドレスである。自ｏｒ他フラグは、自身のエッジサーバ１か他のエッジサーバ１かを判定するフラグである。一例として、自身のエッジサーバ１である場合には、「０」が設定される。他のエッジサーバ１である場合には、「１」が設定される。リソースは、対象となるリソースである。リソース使用量は、リソースの使用量である。一例として、アドレスが「ａａａ」である場合に、自ｏｒ他フラグとして「０」、リソースとして「ＣＰＵ」、リソース使用量として「４０％」と設定されている。アドレスが「ａａａ」である場合に、自ｏｒ他フラグとして「０」、リソースとして「ＧＰＵ」、リソース使用量として「６０％」と設定されている。アドレスが「ｂｂｂ」である場合に、自ｏｒ他フラグとして「１」、リソースとして「ＣＰＵ」、リソース使用量として「４０％」と設定されている。アドレスが「ｂｂｂ」である場合に、自ｏｒ他フラグとして「１」、リソースとして「ＧＰＵ」、リソース使用量として「６０％」と設定されている。

［アドレス情報の一例］
図１０は、アドレス情報の一例を示す図である。図１０に示すように、アドレス情報３４は、アドレス、グループフラグ、要求リソース、事前探索リソース、探索フラグおよび遅延を対応付けた情報である。アドレスは、エッジサーバ１のアドレスである。アドレスは、リソース値情報３３のアドレスに対応する。グループフラグは、グループ内であるか否かを判定するフラグである。一例として、グループ内である場合には、「０」が設定される。グループ外である場合には、「１」が設定される。要求リソースは、定期通知で通知されたリソースである。一例として、全リソースが通知された場合には、「ａｌｌ」が設定される。事前探索リソースが通知された場合には、そのリソースの種類が設定される。事前探索リソースは、事前探索で要求されるリソースである。探索フラグは、リソース探索要求で探索されているか否かを判定するフラグである。一例として、探索されている場合には、「１」が設定される。探索されていない場合には、「０」が設定される。遅延は、アドレスが示すエッジサーバ１との間のネットワーク遅延時間である。なお、探索フラグへの「１」（探索中）は、リソース探索部１５によって設定される。

一例として、アドレスが「ａａａ」である場合に、グループフラグとして「０」、要求リソースとして「ａｌｌ」、事前探索リソースとして「ＧＰＵ」、探索フラグとして「０」、遅延として「ｔ１」が設定されている。アドレスが「ｃｃｃ」である場合に、グループフラグとして「１」、要求リソースとして「メモリ」、事前探索リソースとして「Ｎｕｌｌ」、探索フラグとして「０」、遅延として「ｔ３」が設定されている。アドレスが「ｄｄｄ」である場合に、グループフラグとして「１」、要求リソースとして「ＧＰＵ」、事前探索リソースとして「Ｎｕｌｌ」、探索フラグとして「１」、遅延として「ｔ４」が設定されている。

［要求リソース情報の一例］
図１１は、要求リソース情報の一例を示す図である。図１１に示すように、要求リソース情報３５は、タスクＩＤ（IDentifier）、要求リソースおよびリソース使用量を対応付けた情報である。タスクＩＤは、タスクを特定する識別子である。要求リソースは、タスクが要求するリソースである。リソース使用量は、リソースが要求リソースを使用する使用量である。一例として、タスクＩＤが「１」である場合に、要求リソースとして「ＣＰＵ」、リソース使用量として「２０％」が設定されている。

［データ情報の一例］
図１２は、データ情報の一例を示す図である。図１２に示すように、データ情報３６は、データＩＤおよびデータを対応付けた情報である。データＩＤは、データを特定する識別子である。データは、処理対象データである。

［タスク情報の一例］
図１３は、タスク情報の一例を示す図である。図１３に示すように、タスク情報３７は、タスクＩＤおよびデータＩＤを対応付けた情報である。タスクＩＤは、実行タスクを特定する識別子である。データＩＤは、データを特定するＩＤである。タスクＩＤは、要求リソース情報３５のタスクＩＤに対応する。データＩＤは、データ情報３６のデータＩＤに対応する。

図１４〜図１６は、各種メッセージの一例を示す図である。

［定期通知の一例］
定期通知部１４によって送信される定期通知メッセージの一例を、図１４を参照して説明する。図１４は、定期通知の一例を示す図である。図１４に示すように、定期通知メッセージは、通知フラグ、リソース、リソース使用量およびグループ内エッジサーバアドレスを対応付けたメッセージである。通知フラグは、定期収集であるか事前探索であるかを判定するフラグである。一例として、定期収集である場合には、「０」が設定される。事前探索である場合には、「１」が設定される。リソースは、収集したリソースの種類である。リソース使用量は、リソースの使用量である。グループ内エッジサーバアドレスは、定期通知メッセージを送信する自身のエッジサーバ１のグループ内の他のエッジサーバ１のアドレスである。一例として、自身のエッジサーバ１である場合には、「Ｎｕｌｌ」が設定される。他のエッジサーバ１である場合には、このエッジサーバ１のアドレスが設定される。すなわち、定期通知部１４は事前探索リソースに対して要求リソース量を満たすグループ内の他のエッジサーバ１がある場合には、自身の全リソースのリソース値情報に、他のエッジサーバ１のアドレスおよび事前探索リソースの種類を追加した定期通知メッセージを送信する。

一例として、通知フラグが「０」である場合に、リソースとして「ＣＰＵ」、リソース使用量として「２０％」、グループ内エッジサーバアドレスとして「Ｎｕｌｌ」が設定されている。通知フラグが「１」である場合に、リソースとして「ＧＰＵ」、リソース使用量として「Ｎｕｌｌ」、グループ内エッジサーバアドレスとして「ｘｘｘ」が設定されている。

［リソース探索要求の一例］
リソース探索部１５によって送信されるリソース探索要求のメッセージの一例を、図１５を参照して説明する。図１５は、リソース探索要求の一例を示す図である。図１５に示すように、リソース探索要求のメッセージは、要求リソースおよび要求リソース使用量を対応付けたメッセージである。要求リソースは、リソースが枯渇した場合に、要求されるリソースである。要求リソース使用量は、要求リソースの要求するリソース使用量である。一例として、要求リソースが例えば「ＣＰＵ」である場合に、要求リソース使用量として「２０％」が設定されている。

［事前探索要求の一例］
事前探索リソース決定部１３によって送信される事前探索要求のメッセージの一例を、図１６を参照して説明する。図１６は、事前探索要求の一例を示す図である。図１６に示すように、事前探索要求のメッセージは、リソースおよび要求リソース使用量を対応付けたメッセージである。リソースは、事前探索リソースである。要求リソース使用量は、事前探索リソースの要求するリソース使用量である。一例として、リソースが例えば「ＣＰＵ」である場合に、要求リソース使用量として「２０％」が設定されている。

［再探索要求の一例］
応答部１６によって送信される再探索要求のメッセージの一例を、図１７を参照して説明する。図１７は、再探索要求の一例を示す図である。図１７に示すように、再探索要求のメッセージは、リソースの種類を含む。リソースは、再探索するリソースである。一例として、リソースとして例えば「ＣＰＵ」が設定されている。

図１８〜図２３は、各種処理のフローチャートの一例を示す図である。

［事前探索リソース決定処理のフローチャート］
図１８は、実施例１に係る事前探索リソース決定部の処理のフローチャートの一例を示す図である。なお、事前探索リソース決定部１３は、管理サーバ２から受信された全リソースに対する希少度から希少度に関する情報である希少度情報３１に変換したとする。

図１８に示すように、事前探索リソース決定部１３は、定期タイマーにより予め定められたタイミングで、リソース毎に要求頻度と希少度に関する情報を収集する（ステップＳ１１１）。例えば、事前探索リソース決定部１３は、要求頻度情報３２からリソース毎のリソース要求回数を収集する。事前探索リソース決定部１３は、希少度情報３１からリソース毎の平均探索ホップ数を収集する。

そして、事前探索リソース決定部１３は、リソース毎に要求頻度と希少度に関する情報を乗算し、ランキングを計算する（ステップＳ１１２）。例えば、事前探索リソース決定部１３は、リソース毎にリソース要求回数と平均探索ホップ数とを乗算し、乗算して得られた計算値からランクをつける。

そして、事前探索リソース決定部１３は、計算した値の上位からＸ個のリソースを選択する（ステップＳ１１３）。なお、Ｘは、予め定められた個数であれば良い。

そして、事前探索リソース決定部１３は、選択したリソースについて、ランキングが変動したか否かを判定する（ステップＳ１１４）。ランキングが変動していないと判定した場合には（ステップＳ１１４；Ｎｏ）、事前探索リソース決定部１３は、事前探索リソース決定処理を終了する。

一方、ランキングが変動したと判定した場合には（ステップＳ１１４；Ｙｅｓ）、事前探索リソース決定部１３は、グループ内の全てのエッジサーバ１に事前探索要求を送信する（ステップＳ１１５）。例えば、事前探索リソース決定部１３は、アドレス情報３４を参照し、グループフラグがグループ内のアドレスが示すエッジサーバ１に、選択したリソースを事前探索リソースとして、事前探索リソースの情報を含む事前探索要求を送信する。そして、事前探索リソース決定部１３は、事前探索リソース決定処理を終了する。

［定期通知処理のフローチャート］
図１９は、実施例１に係る定期通知部の処理のフローチャートの一例を示す図である。

図１９に示すように、定期通知部１４は、定期タイマーにより予め定められたタイミングで、アドレス情報３４から通知先を取得する（ステップＳ１２１）。例えば、定期通知部１４は、アドレス情報３４から自身のエッジサーバ１のアドレス以外のアドレスを通知先として取得する。

定期通知部１４は、通知先がグループ内ＥＳであるか否かを判定する（ステップＳ１２２）。通知先がグループ内エッジサーバ（ＥＳ）１であると判定した場合には（ステップＳ１２２；Ｙｅｓ）、定期通知部１４は、アドレス情報３４からグループ内の通知先に対する事前探索リソースを取得する（ステップＳ１２３）。定期通知部１４は、リソース値情報３３から、事前探索リソースに対して、グループ内のエッジサーバのリソース値を取得する（ステップＳ１２４）。

定期通知部１４は、要求リソース量を満たすエッジサーバ１があるか否かを判定する（ステップＳ１２５）。要求リソース量を満たすエッジサーバ１があると判定した場合には（ステップＳ１２５；Ｙｅｓ）、定期通知部１４は、アドレス情報３４から、要求リソース量を満たすエッジサーバ１のアドレスを取得する（ステップＳ１２６）。

そして、定期通知部１４は、定期通知メッセージに、自身のエッジサーバ１の全リソースのリソース値情報と、取得したアドレスとを記載し、通知先のエッジサーバ１に送信する（ステップＳ１２７）。そして、定期通知部１４は、定期通知処理を終了する。

一方、要求リソース量を満たすエッジサーバ１がないと判定した場合には（ステップＳ１２５；Ｎｏ）、定期通知部１４は、以下の処理を行う。定期通知部１４は、リソース値情報３３から、自身のエッジサーバ１の全リソースのリソース値情報を取得する。定期通知部１４は、定期通知メッセージに自身のエッジサーバ１の全リソースのリソース値情報を記載し、通知先のエッジサーバ１に送信する（ステップＳ１２８）。そして、定期通知部１４は、定期通知処理を終了する。

ステップＳ１２２において、通知先がグループ内エッジサーバ（ＥＳ）１でないと判定した場合には（ステップＳ１２２；Ｎｏ）、定期通知部１４は、アドレス情報３４から通知先のアドレスに対する要求リソースを取得する（ステップＳ１２９）。すなわち、自身のエッジサーバ１のリソース探索部１５が、リソース探索要求を受信し、要求リソースの要求リソース量を満たしている場合である。通知先の一例として、図１０のアドレスが「ｃｃｃ」である場合であり、要求リソースとして「メモリ」が取得される。

そして、定期通知部１４は、リソース値情報３３から、自身のエッジサーバ１の、要求リソースに対するリソース値を取得する（ステップＳ１３０）。定期通知部１４は、グループ外エッジサーバ１の通知先に対して、定期通知メッセージに自身のリソース値情報を記載し送信する（ステップＳ１３１）。そして、定期通知部１４は、定期通知処理を終了する。

［リソース探索処理のフローチャート］
図２０は、実施例１に係るリソース探索部の処理のフローチャートの一例を示す図である。

図２０に示すように、リソース探索部１５は、定期タイマーにより予め定められたタイミングで、リソースを選択する（ステップＳ１４１）。リソース探索部１５は、リソース値情報３３から、選択したリソースについて、グループ内エッジサーバ１毎のリソース値を取得し、その合計値を計算する（ステップＳ１４２）。

リソース探索部１５は、合計値が閾値を超えるか否かを判定する（ステップＳ１４３）。合計値が閾値を超えないと判定した場合には（ステップＳ１４３；Ｎｏ）、リソース探索部１５は、リソース探索しない。そして、リソース探索部１５は、ステップＳ１４７に移行する。

一方、合計値が閾値を超えると判定した場合には（ステップＳ１４３；Ｙｅｓ）、リソース探索部１５は、アドレス情報３４から、選択したリソースに対するグループ外のエッジサーバ１のエントリーがあるか否かを判定する（ステップＳ１４４）。選択したリソースに対するグループ外のエッジサーバ１のエントリーがあると判定した場合には（ステップＳ１４４；Ｙｅｓ）、リソース探索部１５は、当該エッジサーバ１に、要求リソースを指定したリソース探索要求を送信する（ステップＳ１４５）。そして、リソース探索部１５は、ステップＳ１４７に移行する。

一方、選択したリソースに対するグループ外のエッジサーバ１のエントリーがないと判定した場合には（ステップＳ１４４；Ｎｏ）、リソース探索部１５は、アドレス情報３４から、遅延が小さいエッジサーバ１を選択し、選択したエッジサーバ１に要求リソースを指定したリソース探索要求を送信する（ステップＳ１４６）。このとき、リソース探索部１５は、アドレス情報３４において、選択したエッジサーバ１のアドレスに対する探索フラグに探索中である「１」を設定し、要求リソース欄に要求リソースを設定する。そして、リソース探索部１５は、ステップＳ１４７に移行する。

ステップＳ１４７において、リソース探索部１５は、全てのリソースを選択したか否かを判定する（ステップＳ１４７）。全てのリソースを選択していないと判定した場合には（ステップＳ１４７；Ｎｏ）、リソース探索部１５は、次のリソースを選択すべく、ステップＳ１４１に移行する。

一方、全てのリソースを選択したと判定した場合には（ステップＳ１４７；Ｙｅｓ）、リソース探索部１５は、リソース探索処理を終了する。

［応答処理のフローチャート］
図２１Ａおよび図２１Ｂは、実施例１に係る応答部の処理のフローチャートの一例を示す図である。図２１Ａは、リソース探索要求を受信した場合の応答部の処理のフローチャートの一例を示す図である。図２１Ｂは、再探索要求を受信した場合の応答部の処理のフローチャートの一例を示す図である。

図２１Ａに示すように、応答部１６は、リソース探索要求を受信すると（ステップＳ１５１）、リソース探索要求に含まれる要求リソースに対するリソース値をリソース値情報３３から取得する（ステップＳ１５２）。

応答部１６は、自身のエッジサーバ１が要求リソースの要求リソース使用量を満たすか否かを判定する（ステップＳ１５３）。自身が要求リソースの要求リソース使用量を満たすと判定した場合には（ステップＳ１５３；Ｙｅｓ）、応答部１６は、要求元が定期通知先でないか否かを判定する（ステップＳ１５４）。要求元が定期通知先であると判定した場合には（ステップＳ１５４；Ｎｏ）、応答部１６は、応答処理を終了する。

一方、要求元が定期通知先でないと判定した場合には（ステップＳ１５４；Ｙｅｓ）、応答部１６は、要求元に要求リソースを定期通知登録する（ステップＳ１５５）。例えば、応答部１６は、要求リソースに対するリソース値を含む定期通知要求を登録部１７に送信する。そして、応答部１６は、応答処理を終了する。

ステップＳ１５３において、自身が要求リソースの要求リソース使用量を満たさないと判定した場合には（ステップＳ１５３；Ｎｏ）、応答部１６は、リソース値情報３３から、他のエッジサーバ１が要求リソースの要求リソース量を満たすか否かを判定する（ステップＳ１５６）。他のエッジサーバ１が要求リソースの要求リソース量を満たすと判定した場合には（ステップＳ１５６；Ｙｅｓ）、応答部１６は、要求リソース量を満たすエッジサーバ１にリソース探索要求を転送する（ステップＳ１５７）。そして、応答部１６は、応答処理を終了する。

一方、他のエッジサーバ１が要求リソースの要求リソース量を満たさないと判定した場合には（ステップＳ１５６；Ｎｏ）、応答部１６は、リソース探索要求元に再探索要求を転送する（ステップＳ１５８）。そして、応答部１６は、応答処理を終了する。

図２１Ｂに示すように、応答部１６は、再探索要求を受信すると（ステップＳ１６１）、アドレス情報３４から、リソース探索要求を直近に送信したエッジサーバ１の次に近いエッジサーバ１を選択する（ステップＳ１６２）。

応答部１６は、選択したエッジサーバ１にリソース探索要求を送信する（ステップＳ１６３）。そして、応答部１６は、応答処理を終了する。

［登録処理のフローチャート］
図２２Ａおよび図２２Ｂは、実施例１に係る登録部の処理のフローチャートの一例を示す図である。図２２Ａは、事前探索要求を受信した場合の登録部の処理のフローチャートの一例を示す図である。図２２Ｂは、定期通知を受信した場合の登録部の処理のフローチャートの一例を示す図である。

図２２Ａに示すように、登録部１７は、事前探索要求を受信すると（ステップＳ１７１）、事前探索要求に含まれる要求リソースと要求元である宛先をアドレス情報３４に登録する（ステップＳ１７２）。

登録部１７は、事前探索要求範囲（ＴＴＬ）が０より大きいか否かを判定する（ステップＳ１７３）。ＴＴＬが０より大きいと判定した場合には（ステップＳ１７３；Ｙｅｓ）、登録部１７は、グループ内のエッジサーバ１全てに事前探索要求を転送する（ステップＳ１７４）。そして、登録部１７は、登録処理を終了する。

一方、ＴＴＬが０より大きくないと判定した場合には（ステップＳ１７３；Ｎｏ）、登録部１７は、事前探索要求を転送しないで登録処理を終了する。

図２２Ｂに示すように、登録部１７は、定期通知を受信すると（ステップＳ１８１）、アドレス情報３４からリソースを探索中でないか否かを判定する（ステップＳ１８２）。リソースを探索中でないと判定した場合には（ステップＳ１８２；Ｙｅｓ）、登録部１７は、ステップＳ１８４に移行する。

一方、リソースを探索中であると判定した場合には（ステップＳ１８２；Ｎｏ）、登録部１７は、アドレス情報３４の探索中のエントリーについて、探索フラグを探索中でないことを示す「０」に設定し、要求リソースをＮｕｌｌに設定する（ステップＳ１８３）。そして、登録部１７は、ステップＳ１８４に移行する。

ステップＳ１８４において、登録部１７は、定期通知メッセージに含まれる、定期通知の通知元のリソース値をリソース値情報３３に登録する（ステップＳ１８４）。そして、登録部１７は、定期通知メッセージにグループ外情報があるか否かを判定する（ステップＳ１８５）。グループ外情報があると判定した場合には（ステップＳ１８５；Ｙｅｓ）、登録部１７は、グループ外情報に含まれるアドレスと事前探索リソースの種類をアドレス情報３４に登録する（ステップＳ１８６）。そして、登録部１７は、登録処理を終了する。

一方、グループ外情報がないと判定した場合には（ステップＳ１８５；Ｎｏ）、登録部１７は、登録処理を終了する。

［タスクスケジューラ処理のフローチャート］
図２３は、実施例１に係るタスクスケジューラの処理のフローチャートの一例を示す図である。

図２３に示すように、データ受信部１８は、ＩｏＴデバイスからデータを受信する（ステップＳ１９１）。データ・タスク管理部１９は、受信したデータと実行するタスクとを管理する（ステップＳ１９２）。

タスク配備場所決定部２０は、実行するタスクが要求するリソースに対するリソース値をリソース値情報３３から取得する（ステップＳ１９３）。

タスク配備場所決定部２０は、要求を満たすリソースがあるか否かを判定する（ステップＳ１９４）。要求を満たすリソースがあると判定した場合には（ステップＳ１９４；Ｙｅｓ）、タスク配備場所決定部２０は、要求を満たすリソースがあるアドレスのエッジサーバ１に実行するタスクを配備する（ステップＳ１９５）。そして、タスク実行部２１は、配備したエッジサーバ１でタスクを実行する（ステップＳ１９６）。そして、タスク実行部２１は、タスクスケジューラ処理を終了する。

一方、要求を満たすリソースがないと判定した場合には（ステップＳ１９４；Ｎｏ）、タスク配備場所決定部２０は、実行するタスクを待ちキューに入れる（ステップＳ１９７）。タスク配備場所決定部２０は、タスクスケジューラ処理を終了する。

なお、新たなエッジサーバ１が分散処理システム９に参加する場合がある。かかる場合には、新たなエッジサーバ１は、例えば、管理サーバ２に参加要求を送信すれば良い。参加要求を受け付けた管理サーバ２は、例えば、新たなエッジサーバ１とネットワーク遅延の小さいエッジサーバ１のアドレスを新たなエッジサーバ１に通知する。そして、新たなエッジサーバ１は、通知されたアドレスのエッジサーバ１をグループと判断し、そのグループ内のエッジサーバ１に対して定期通知を依頼する。また、管理サーバ２は、新たなエッジサーバ１を、新たなエッジサーバ１とネットワーク遅延の小さいエッジサーバ１のグループに入れることを、グループ内のエッジサーバ１に伝達する。グループ内のエッジサーバ１は、新たなエッジサーバ１に定期通知を要求する。また、管理サーバ２は、新たなエッジサーバ１が参加した後のシステム全体の変化を、システム内のエッジサーバ１に伝達する。これにより、分散処理システム９は、新たなエッジサーバ１を円滑に参加させることができる。

また、上記実施例１における管理サーバ２は、クラウドの形態で提供されるサービスであっても良い。

また、上記実施例１では、管理サーバ２が、分散処理システム９内の複数のエッジサーバ１の負荷を監視すると説明した。しかしながら、各エッジサーバ１が、管理サーバ２の代わりに、自律分散して管理サーバ２が行っていた負荷監視機能を行うようにしても良い。

［実施例１の効果］
上記実施例１によれば、第１のエッジサーバ１は、収集対象の複数のリソースの中で、要求リソース量を満たす情報処理装置を探索する時間がかかる所定のリソースを絞り込む。第１のエッジサーバ１は、絞り込んだ所定のリソースの情報を第１のエッジサーバ１の第１のグループに属する第２のエッジサーバ１に通知する。第２のエッジサーバ１は、第２のエッジサーバ１が属するグループであって、第１のグループと異なる第２のグループに属するエッジサーバ１から収集対象の複数のリソースのリソース量を定期的に収集する。第２のエッジサーバ１は、予め定められたタイミングで、収集した情報から第２のグループに属するエッジサーバ１の所定のリソースのリソース量を取得する。第２のエッジサーバ１は、所定のリソースのリソース量が予め定められるリソース量を満たしていれば、このエッジサーバ１の装置情報を、第２のエッジサーバ１の収集対象の複数のリソースのリソース量に追加して第１のエッジサーバ１へ定期的に通知する。かかる構成によれば、第１のエッジサーバ１は、所定のリソースが第１のグループで枯渇しても、所定のリソースの要求リソース量を満たすエッジサーバ１の探索時間を削減することが可能となる。また、第１のエッジサーバ１は、所定のリソースの探索に必要なメッセージの数を抑制することが可能となる。

また、上記実施例１によれば、第１のエッジサーバ１は、第１のグループに含まれる全てのエッジサーバ１の所定のリソースのリソース量が満たされない場合には、以下の処理を行う。第１のエッジサーバ１は、所定のリソースのリソース量が満たされると予測される、第２のグループに含まれるエッジサーバ１に対して所定のリソースを探索する。かかる構成によれば、第１のエッジサーバ１は、自己が属しないグループ（第２のグループ）のリソースの情報を用いてグループでリソース量が満たされないリソースを探索できる。これにより、第１のエッジサーバ１は、１回で探索することができ、メッセージ数を抑制することができる。

また、上記実施例１によれば、第１のエッジサーバ１は、リソースの種類毎に得られる、要求リソース量を満たさないエッジサーバ１の数を用いて、要求リソース量を満たすエッジサーバ１を探索できるまでの平均的なホップ数を算出する。第１のエッジサーバ１は、リソースの種類毎に得られる、リソースを要求する要求頻度を取得する。第１のエッジサーバ１は、リソースの種類毎に、算出される探索ホップ数と取得される要求頻度とを畳み込む。第１のエッジサーバ１は、リソースの種類毎に畳み込まれた結果値を用いて、所定のリソースを絞り込む。かかる構成によれば、第１のエッジサーバ１は、リソースが枯渇しやすい所定のリソースを絞り込むことで、所定のリソースを事前探索することができ、定期収集時のメッセージのサイズを抑制することが可能となる。

ところで、実施例１に係るエッジサーバ１は、グループ内のエッジサーバ１の数に応じた事前探索要求範囲（ＴＴＬ）のエッジサーバ１に対して、事前探索要求を転送する。すなわち、エッジサーバ１は、事前探索要求範囲を用いて、グループ内のエッジサーバ１全てに事前探索要求を転送する。事前探索要求範囲は、例えば、ホップ数で示す。一例として、グループ内にエッジサーバ１が２台であれば、ホップ数を１とする。しかしながら、エッジサーバ１は、これに限定されず、事前探索要求範囲を用いて、グループ内だけでなくグループ外のエッジサーバ１に事前探索要求を転送しても良い。事前探索要求範囲は、例えば、システム内のエッジサーバ数やメッセージの数に応じて決定されれば良い。

そこで、実施例２に係るエッジサーバ１は、事前探索要求範囲を用いて、グループ内だけでなくグループ外のエッジサーバ１に事前探索要求を転送する場合を説明する。

［実施例２に係るエッジサーバの構成］
実施例２に係るエッジサーバ１の構成は、実施例１の図１に示すエッジサーバ１と同一であるので、その重複する構成および動作の説明については省略する。

［データ収集処理の流れ］
図２４は、実施例２に係るデータ収集処理の流れの一例を示す図である。なお、図２４では、ａ、ｂ、ｃ、ｄは、それぞれエッジサーバ１である。ａおよびｂは、グループαに属する。ｂおよびｃは、グループβに属する。ｃおよびｄは、グループγに属する。ｂ、ｃは、複数のグループに属する。また、図５で示した実施例１に係るデータ収集処理の流れと重複する処理の説明については省略する。また、図２４の例では、事前探索要求範囲としてのＴＴＬは、「２」であるとする。

エッジサーバａでは、事前探索リソース決定部１３は、事前探索要求をグループα内のエッジサーバｂに送信する。事前探索要求には、リソースの情報およびＴＴＬとして「２」が含まれる。

エッジサーバｂでは、登録部１７が、事前探索要求を受信すると、事前探索要求に含まれたリソースの情報をアドレス情報３４に登録する。加えて、登録部１７は、事前探索要求に含まれるＴＴＬが「２」であるので、ＴＴＬの値をデクリメントする。登録部１７は、事前探索要求をランダムに選んだグループβ内のエッジサーバｃに転送する（＜２１＞）。事前探索要求には、リソースの情報およびＴＴＬとして「１」が含まれる。

エッジサーバｃでは、登録部１７が、事前探索要求を受信すると、事前探索要求に含まれたリソースの情報をアドレス情報３４に登録する。加えて、登録部１７は、事前探索要求に含まれるＴＴＬが「１」であるので、ＴＴＬの値をデクリメントする。すると、登録部１７は、ＴＴＬが０となるので、事前探索要求の転送を中止する（＜２２＞）。

エッジサーバｃでは、登録部１７が、定期通知メッセージを受信すると、グループγ内の通知元のエッジサーバｄのリソース値情報を登録する。そして、定期通知部１４が、定期タイマーにより予め定められた時点で、同じグループβのエッジサーバｂに定期通知を行う（＜２３＞）。例えば、定期通知部１４は、事前探索リソースに対して要求リソース量を満たすエッジサーバ１がある場合には、自身の全リソースのリソース値情報にこのエッジサーバ１のアドレスを追加した定期通知メッセージをエッジサーバｂに送信する。ここでは、事前探索リソースに対して要求リソース量を満たすエッジサーバ１としてエッジサーバｄがあるとすると、定期通知部１４は、このエッジサーバｄのアドレスを追加した定期通知メッセージをエッジサーバｂに送信する。

エッジサーバｂでは、登録部１７が、定期通知メッセージを受信すると、グループβ内の通知元のエッジサーバｃのリソース値情報を登録する。そして、定期通知部１４が、定期タイマーにより予め定められた時点で、同じグループαのエッジサーバａに定期通知を行う（＜２４＞）。例えば、定期通知部１４は、事前探索リソースに対して要求リソース量を満たすエッジサーバ１がある場合には、自身の全リソースのリソース値情報にこのエッジサーバ１のアドレスを追加した定期通知メッセージをエッジサーバａに送信する。ここでは、事前探索リソースに対して要求リソース量を満たすエッジサーバ１としてエッジサーバｄがあるとすると、定期通知部１４は、このエッジサーバｄのアドレスを追加した定期通知メッセージをエッジサーバａに送信する。

エッジサーバａでは、登録部１７が、定期通知メッセージを受信すると、グループα内の通知元のエッジサーバｂのリソース値情報を登録する。加えて、登録部１７は、エッジサーバｄのアドレスが定期通知メッセージに追加されていれば、グループ外のエッジサーバｄのアドレスとリソースの種類とをアドレス情報３４に登録する。

エッジサーバａでは、リソース探索部１５が、グループα内であるリソースの閾値が超えたとする。すると、リソース探索部１５は、閾値を超えたリソースの要求リソース量を満たすグループ外のアドレスの有無を判定する。リソース探索部１５は、閾値を超えたリソースの要求リソース量を満たすグループ外のアドレスが有る場合には、このアドレスのエッジサーバｃにリソース探索要求を送信する。ここでは、エッジサーバｄが事前探索リソースに対して要求リソース量を満たしていれば、エッジサーバａは、直接エッジサーバｄにリソース探索要求を送信する（＜２５＞）。

なお、実施例２では、事前探索要求範囲を、例えば、システム内のエッジサーバ数やメッセージの数に応じて決定すると説明した。しかしながら、事前探索要求範囲は、これに限定されず、希少度情報３１が示す平均探索ホップ数から決定されても良い。平均探索ホップ数は、リソースの要求リソース量の探索において、要求リソース量を満たすまでに要する平均的なホップ数であるからである。

［実施例２の効果］
上記実施例２によれば、エッジサーバ１は、グループ内から派生するエッジサーバ１だけでなく、グループ外から派生するエッジサーバ１についても、事前探索リソースの使用状況を把握できる。この結果、エッジサーバ１は、事前探索リソースがグループ内で枯渇しても、事前探索リソースの要求リソース量を満たすエッジサーバ１の探索時間を削減することが可能となる。また、エッジサーバ１は、事前探索リソースの探索に必要なメッセージの数を抑制することが可能となる。

なお、実施例１、２では、リソース探索部１５が、グループ内のリソースが閾値を超える場合には、超えたリソース（探索リソース）の要求リソース量を満たすエッジサーバ１がグループ外にあるか否かを判定する。そして、リソース探索部１５は、探索リソースがグループ外にない場合には、探索リソースに対するリソース探索要求を、トポロジ情報から得られるネットワーク遅延の小さいエッジサーバ１へ送信すると説明した。しかしながら、リソース探索部１５は、これに限定されず、グループ内のエッジサーバ１からランダムに１つ選択し、探索リソースに対するリソース探索要求を送信しても良い。さらに、リソース探索要求を受信したエッジサーバ１では、応答部１６が、自身が探索リソースの要求リソース量を満たさず、他のエッジサーバ１が探索リソースの要求リソース量を満たさない場合には、以下の処理を行う。応答部１６は、リソース探索要求元に再探索要求を転送せず、他のエッジサーバ１からランダムに１つ選択して、探索リソースに対するリソース探索要求を送信する。これにより、リソース探索要求を受信したエッジサーバ１が、探索リソースが閾値を超えた場合に送信する再探索要求のメッセージ数を削減することができる。

［その他］
上記実施例１，２では、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、事前探索リソース決定部１３、定期通知部１４、リソース探索部１５、応答部１６および登録部１７を統合して分散リソース管理部１２としても良い。また、例えば、データ受信部１８、データ・タスク管理部１９、タスク配備場所決定部２０およびタスク実行部２１を統合してタスクスケジューラ部としても良い。また、例えば、登録部１７を、事前探索要求を受信した場合の処理部と、定期通知メッセージを受信した場合の処理部とに分散しても良い。また、例えば、応答部１６を、リソース探索要求を受信した場合の処理部と、再探索要求を受信した場合の処理部とに分散しても良い。また、記憶部３０をエッジサーバ１の外部装置として通信ネットワーク経由で接続するようにしても良い。

また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することによって実現することができる。そこで、以下では、図１に示したエッジサーバ１と同様の機能を実現するデータ収集プログラムを実行するコンピュータの一例を説明する。図２５は、データ収集プログラムを実行するコンピュータの一例を示す図である。

図２５に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ（Hard Disk Drive）２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、データ収集プログラム２０５ａおよびデータ収集関連情報２０５ｂを記憶する。

ＣＰＵ２０３は、データ収集プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、エッジサーバ１の各機能部に対応する。データ収集関連情報２０５ｂは、エッジサーバ１の記憶部３０に記憶された情報に対応する。そして、例えばリムーバブルディスク２１１が、データ収集プログラム２０５ａ等の各情報を記憶する。

なお、データ収集プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Video Disk）、光磁気ディスク、ＩＣカード等の「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらからデータ収集プログラム２０５ａを読み出して実行するようにしても良い。

１ エッジサーバ
２ 管理サーバ
９ 分散処理システム
１０ 制御部
１１ 受信部
１２ 分散リソース管理部
１３ 事前探索リソース決定部
１４ 定期通知部
１５ リソース探索部
１６ 応答部
１７ 登録部
１８ データ受信部
１９ データ・タスク管理部
２０ タスク配備場所決定部
２１ タスク実行部
３０ 記憶部
３１ 希少度情報
３２ 要求頻度情報
３３ リソース値情報
３４ アドレス情報
３５ 要求リソース情報
３６ データ情報
３７ タスク情報

Claims (5)

1. 複数の情報処理装置を含むグループを複数有する分散処理システムのデータ収集方法であって、
   第１の情報処理装置は、
   収集対象の複数のリソースの中で、要求リソース量を満たす情報処理装置を探索する時間がかかる所定のリソースを絞り込み、
   絞り込んだ所定のリソースの情報を前記第１の情報処理装置の第１のグループに属する第２の情報処理装置に通知し、
   前記第２の情報処理装置は、
   前記第２の情報処理装置が属するグループであって、第１のグループと異なる第２のグループに属する情報処理装置から前記収集対象の複数のリソースのリソース量を定期的に収集し、
   予め定められたタイミングで、前記収集した情報から前記第２のグループに属する情報処理装置の前記所定のリソースのリソース量を取得し、前記所定のリソースのリソース量が予め定められるリソース量を満たしていれば、前記所定のリソースのリソース量を満たす情報処理装置の装置情報を、前記第２の情報処理装置の前記収集対象の複数のリソースのリソース量に追加して前記第１の情報処理装置へ定期的に通知する
   処理を実行することを特徴とするデータ収集方法。
2. 前記第１の情報処理装置は、
   前記第１のグループで前記所定のリソースのリソース量が満たされない場合には、前記所定のリソースのリソース量が満たされると予測される、前記第２のグループに含まれる情報処理装置に対して前記所定のリソースを探索する
   処理を実行することを特徴とする請求項１に記載のデータ収集方法。
3. 前記絞り込む処理は、
   リソースの種類毎に得られる、前記要求リソース量を満たさない情報処理装置の数を用いて、前記要求リソース量を満たす情報処理装置を探索できるまでの平均的なホップ数を算出し、
   前記リソースの種類毎に得られる、リソースを要求する要求頻度を取得し、
   前記リソースの種類毎に、算出される探索ホップ数と取得される要求頻度とを畳み込み、
   前記リソースの種類毎に畳み込まれた結果値を用いて、前記所定のリソースを絞り込む
   処理を実行することを特徴とする請求項１に記載のデータ収集方法。
4. 自情報処理装置が属する第１のグループに属する情報処理装置から、要求リソースを満たす情報処理装置を探索する時間がかかる所定のリソースの情報を受信する受信部と、
   前記第１のグループと異なる第２のグループに属する情報処理装置から、収集対象の複数のリソースのリソース量を定期的に収集する収集部と、
   予め定められたタイミングで、前記収集部によって収集された収集情報から前記第２のグループに属する情報処理装置の前記所定のリソースのリソース量を取得し、前記所定のリソースのリソース量が予め定められるリソース量を満たしていれば、前記所定のリソースのリソース量を満たす情報処理装置の装置情報を、自情報処理装置の前記収集対象の複数のリソースのリソース量に追加して前記第１のグループに属する情報処理装置へ定期的に通知する通知部と、
   を有することを特徴とする情報処理装置。
5. 複数の情報処理装置を含むグループを複数有する分散処理システムであって、
   第１の情報処理装置は、
   収集対象の複数のリソースの中で、要求リソース量を満たす情報処理装置を探索する時間がかかる所定のリソースを絞り込む絞込部と、
   前記絞込部によって絞り込まれた所定のリソースの情報を前記第１の情報処理装置の第１のグループに属する第２の情報処理装置に通知する第１の通知部と、を有し、
   前記第２の情報処理装置は、
   前記第２の情報処理装置が属するグループであって、第１のグループと異なる第２のグループに属する情報処理装置から前記収集対象の複数のリソースのリソース量を定期的に収集する収集部と、
   予め定められたタイミングで、前記収集部によって収集された情報から前記第２のグループに属する情報処理装置の前記所定のリソースのリソース量を取得し、前記所定のリソースのリソース量が予め定められるリソース量を満たしていれば、前記所定のリソースのリソース量を満たす情報処理装置の装置情報を、前記第２の情報処理装置の前記収集対象の複数のリソースのリソース量に追加して前記第１の情報処理装置へ定期的に通知する第２の通知部と、
   を有することを特徴とする分散処理システム。

Images