JP2015503146A - 大規模メディア・クラウドのための分散型マッピング機能 - Google Patents

Abstract

本明細書は、クラウド・コンピューティングに関する。特に、本明細書は、クラウド内でのアプリケーション・コンポーネントの効率的で柔軟な配置を可能にするクラウド・コンピューティングのための方法およびシステムに関する。分散型クラウド・コンピューティングのために適合されたコンピューティング・デバイス（１０１）が、説明される。コンピューティング・デバイス（１０１）は、第１のトポロジーのエリア（１０２）内に位置付けられ、第１のトポロジーのエリア（１０２）以外の複数のトポロジーのエリア（１０２）にそれぞれ位置付けられる複数の基準コンピューティング・デバイスを示すトポロジーのリスト（６０２）を含み、コンピューティング・デバイス（１０１）、およびコンピューティング・デバイス（１０１）の近隣に位置付けられた少なくとも１つの近隣のコンピューティング・デバイス（１０１）の利用可能なコンピューティング・リソースを示すローカル・リソース・リスト（６０１）を含み、アプリケーション（７００）のコンポーネント（７０３）に関するコンポーネント配置要求を受信すると、トポロジーのリスト（６０２）に基づいて、コンポーネント（７０３）が、第１のトポロジーのエリア（１０２）に置かれるべきであるか、または第１のトポロジーのエリア（１０２）以外の複数のトポロジーのエリア（１０２）のうちの１つに置かれるべきであるかを判定し、コンポーネント（７０３）が第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに置かれるべきであると判定される場合、第１のトポロジーのエリア以外の複数のトポロジーのエリアのそれぞれのトポロジーのエリアの基準コンピューティング・デバイスにコンポーネント配置要求を渡し、コンポーネント（７０３）が第１のトポロジーのエリア（１０２）に配置されるべきであると判定される場合、ローカル・リソース・リスト（６０１）から、アプリケーションのコンポーネントを実行するためのコンピューティング・リソースを有する選択されたコンピューティング・デバイスを特定するように適合される。

Description

本明細書は、クラウド・コンピューティングに関する。特に、本明細書は、クラウド内でのアプリケーション・コンポーネントの効率的で柔軟な配置を可能にするクラウド・コンピューティングのための方法およびシステムに関する。

インターネットは、ユーザがメディアを消費する方法を変えつつある。インターネット技術によって可能にされて、発展は、ライブ３Ｄ放送、ライブ・イベントの時間をずらした視聴、またはいつでも望まれるとき、どこでも必要とされるところで、任意の好ましいデバイスでのビデオ・オン・デマンドのようなメディア・サービスをユーザが楽しむことを可能にするところに急速に向かっている。さらに、インターネットでは、ユーザは、単なる見物人ではなく没頭している参加者になる。ウェブに基づくサービスは、リアルタイムのマルチメディア・コンテンツの大規模な共有、または没入型のマルチメディア通信のような新しいパーソナライズされたメディア中心のアプリケーションの部類の全体に対する触媒である。これらのサービスは、純粋なコンテンツ・ストリームとして実現されるのではなく、適切な時間、場所、およびフォーマットで要求されたデータを提供するメディア処理機能の編成されたフローとして実現される。高精細ビデオ・フォーマットの導入により、転送されるデータ量が、データ変換プロセスにおけるコードの構築のサイズを上回る。したがって、分散型のサービス・インフラストラクチャにインテリジェントな方法でサービス・コンポーネントを配置することは、将来のインターネット・インフラストラクチャのスケーリングを向上させる方法を提供する。言い換えると、転送されるデータ量が増えるにつれて、分散型アプリケーションのＳＷコンポーネントをクラウド・ネットワーク内の適切な位置に転送し、配置することが一層効率的になる可能性がある。

Ishfaq Ahmad、「Multi-View Video:Get Ready for Next-Generation Television」、IEEE Distributed Systems Online、第８巻、第３号、２００７年、論文番号0703-o3006 OnLive、http://www.onlive.com/

本明細書は、サービス／アプリケーション・コンポーネントの効率的で柔軟な配置を可能にするコンピューティング・デバイス（ノードとも呼ばれる）のクラウドを提供する技術的な問題に対処する。

一態様によれば、分散型クラウド・コンピューティングのために適合されたコンピューティング・デバイス（コンピューティング・ノードまたはノードとも呼ばれる）が説明される。コンピューティング・デバイスは、第１のトポロジーのエリア（topological area）内に位置付けられる。通常、複数のそのようなコンピューティング・デバイスを含む分散型クラウド（本明細書においてはメディア・クラウドと呼ばれる）は、複数のトポロジーのエリアに分けられる（それらのエリアは１つまたは複数の領域にさらに細分される可能性がある）。コンピューティング・デバイスは、第１のトポロジーのエリア以外の複数のトポロジーのエリア内にそれぞれ位置付けられる複数の基準コンピューティング・デバイス（reference computing device）を示すトポロジーのリスト（topological list）を含む。言い換えると、コンピューティング・デバイスは、分散型クラウドのその他のエリア（または領域）のそれぞれの中に位置付けられた少なくとも１つの基準コンピューティング・デバイスの指示（例えば、ネットワーク識別子）を提供するトポロジーのリストを保有する。トポロジーのリストは、その他のエリア（または領域）毎に１つまたは２つの基準コンピューティング・デバイスを含む可能性がある。通常は、基準コンピューティング・デバイスは、各コンピューティング・デバイスが領域に対する異なるアンカー・ポイント（anchor point）を有することを保証し、それによって単一障害点を取り除くために、領域内のコンピューティング・デバイスの利用可能なリストからランダムに選択される。

コンピューティング・デバイスは、コンピューティング・デバイス、およびコンピューティング・デバイスの近隣に位置付けられた少なくとも１つの近隣のコンピューティング・デバイスの利用可能なコンピューティング・リソースを示すローカル・リソース・リストを含む。コンピューティング・デバイスの近隣は、少なくとも１つの近隣のコンピューティング・デバイスによって満たされる必要がある１つまたは複数の近隣の条件によって定義される可能性がある。１つまたは複数の近隣の条件は、コンピューティング・デバイスと少なくとも１つの近隣のコンピューティング・デバイスとの間の最大往復遅延時間を含む可能性がある。代替的にまたは追加的に、１つまたは複数の近隣の条件は、少なくとも１つの近隣のコンピューティング・デバイスが第１のトポロジーのエリア、つまり、同じトポロジーのエリア内に位置付けられているという条件を含む可能性がある。

アプリケーションのコンポーネントに関するコンポーネント配置要求を受信すると、コンピューティング・デバイスは、トポロジーのリスト（のみ）に基づいて、コンポーネントが第１のトポロジーのエリアに配置されるべきか、または第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに配置されるべきかを判定するように適合される。概して、コンポーネント配置要求は、コンポーネント／アプリケーションのシンクまたはソースの好ましい場所に関する情報を含む。例として、コンポーネントのシンクまたはソースの好ましい場所に関する情報は、特定のコンポーネント、および特定のコンポーネントが連係して動作しているアプリケーションのその他のコンポーネントの要件の記述から導出され得る。コンピューティング・デバイスは、好ましい場所をそのコンピューティング・デバイス自身の場所およびメディア・クラウドのトポロジーのエリアの場所と比較することができる。

コンポーネントが第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに置かれるべきであると判定される場合、コンピューティング・デバイスは、第１のトポロジーのエリア以外の複数のトポロジーのエリアのそれぞれのトポロジーのエリアの基準コンピューティング・デバイスにコンポーネント配置要求を渡すように適合される。言い換えると、別のトポロジーのエリアが好ましい場所により近いと判定される場合、配置要求は、別のトポロジーのエリアの基準コンピューティング・デバイスに（または基準コンピューティング・デバイスのうちの１つに）渡され、基準コンピューティング・デバイス（つまり、基準コンピューティング・デバイスへの指示）は、コンピューティング・デバイスのトポロジーのリストから得られる。したがって、コンピューティング・デバイスは、別のコンピューティング・デバイスまたは上位レベルのネットワーク管理エンティティと調整することを必要とせずに、そのコンピューティング・デバイスのトポロジーのリストに基づいてトポロジー管理タスクを実行するように適合される。言い換えると、トポロジー管理タスクは、コンピューティング・デバイスによって自律的に実行される。

コンポーネントが第１のトポロジーのエリアに配置されるべきであると判定される場合、コンピューティング・デバイスは、ローカル・リソース・リストから、アプリケーションのコンポーネントを実行するためのコンピューティング・リソースを有する選択されたコンピューティング・デバイスを特定するように適合される。言い換えると、コンピューティング・デバイスが、コンポーネントの好ましい場所が第１のトポロジーのエリア内に（またはコンピューティング・デバイスの領域内に）あることを判定する場合、コンピューティング・デバイスは、別のコンピューティング・デバイスまたは上位レベルのネットワーク管理エンティティと調整することを必要とせずに、そのコンピューティング・デバイスのローカル・リソース・リスト内の利用可能なリソース情報に基づいてリソース管理タスクを実行する。これは、リソース管理タスクがコンピューティング・デバイスによって自律的に実行されることを意味する。

コンピューティング・デバイスは、少なくとも１つの近隣のコンピューティング・デバイスから少なくとも１つの近隣のコンピューティング・デバイスのコンピューティング・リソースに関する情報を受信するように適合される可能性がある。この情報は、（例えば、周期的に）（１つまたは複数の）近隣のコンピューティング・デバイスによってプッシュされる可能性がある。代替的に、コンピューティング・デバイスは、（例えば、周期的に）（１つまたは複数の）近隣のコンピューティング・デバイスからこの情報をプルする可能性がある。これは、リソース管理タスクを実行するためにローカル・リソース・リストが最新に保たれることを保証する。少なくとも１つの近隣のコンピューティング・デバイスからの１つまたは複数の近隣のコンピューティング・デバイスのコンピューティング・リソースに関する情報は、記憶された情報の信頼性に関するカテゴリーまたは指示に関連付けられる可能性があることに留意されたい。記憶された情報の信頼性は、情報が受信されてから経過した時間の量とともに減少する可能性がある。例として、第１のカテゴリーは、コンピューティング・デバイスに関する正確な（すなわち、適時の）情報を示す可能性があり、第２のカテゴリーは、正確性の劣る（すなわち、幾分古い）情報を示す可能性があり、以下同様である。

コンピューティング・デバイスは、第１のトポロジーのエリア内に含まれる第１のコンピューティング・デバイスのリストを受信するように適合される可能性がある。第１のコンピューティング・デバイスのリストは、第１のトポロジーのエリア内に含まれるすべてのコンピューティング・デバイスの完全なリストである可能性がある。このリストは、（例えば、コンピューティング・デバイスの初期化段階で）コンピューティング・デバイスによる要求に応じて受信される可能性がある。コンピューティング・デバイスは、ローカル・リソース・リストのために、第１のコンピューティング・デバイスのリストから複数の近隣のコンピューティング・デバイスを選択するように適合され得る。近隣のコンピューティング・デバイスの数は、所定の数に制限される可能性がある。近隣のコンピューティング・デバイスの数は、第１のコンピューティング・デバイスのリストに含まれる第１のコンピューティング・デバイスの数未満である可能性がある。

コンピューティング・デバイスは、第１のコンピューティング・デバイスのコンピューティング・リソースに基づいて、ならびに／またはコンピューティング・デバイスと第１のコンピューティング・デバイスとの間のリンクの帯域幅に基づいて、および／もしくはコンピューティング・デバイスと第１のコンピューティング・デバイスとの間の往復遅延時間に基づいて複数の近隣のコンピューティング・デバイスを選択するように適合される可能性がある。例として、複数の近隣のコンピューティング・デバイスは、選択されたコンピューティング・デバイスのリンクのリンクの負荷またはリンクの占有に基づいて選択される可能性がある。したがって、コンピューティング・デバイスは、第１のコンピューティング・デバイスのリストからローカル・リソース・リストを構築するように適合される可能性がある。これは、初期化段階で実行される可能性がある。加えて、コンピューティング・デバイスは、ローカル・リソース・リストの近隣のコンピューティング・デバイスを、第１のコンピューティング・デバイスのリストからの新しい近隣のコンピューティング・デバイスによって置き換え、それによって、ローカル・リソース・リスト（およびリソース管理タスク）をメディア・クラウド内の変更に適合させるように適合される可能性がある。

上で示されたように、トポロジーのエリアは、１つまたは複数の領域に細分される可能性がある。この場合、トポロジーのリストは複数のトポロジーのエリアの１つまたは複数の領域内に位置付けられた複数の基準コンピューティング・デバイスを示す可能性がある。さらに、コンピューティング・デバイスのローカル・リソース・リストは、コンピューティング・デバイスと同じ領域の近隣のコンピューティング・デバイスに制限される可能性がある。

コンピューティング・デバイスは、アプリケーションのコンポーネントを実行するための実行環境を含み得る。実行環境は、コンポーネントを実行するためのプロセッサの能力およびメモリの容量を提供することができる。加えて、実行環境は、コンポーネントによって処理されるデータを受信および送信するための送信および受信の能力を提供することができる。コンピューティング・デバイスのコンピューティング・リソースは、コンピューティング・デバイスのプロセッサ・リソース、コンピューティング・デバイスのメモリ・リソース、コンピューティング・デバイスへのリンクの帯域幅、およびコンピューティング・デバイスとの通信に関する往復遅延時間のうちの任意の１つまたは複数である可能性がある。

別の態様によれば、クラウド・コンピューティングのための分散型ネットワークが説明される。分散型ネットワークは、本明細書においてはメディア・クラウドと呼ばれる。ネットワークは、メディア・クラウドの第１のトポロジーのエリア内の第１の複数のコンピューティング・デバイスと、メディア・クラウドの第２のトポロジーのエリア内の第２の複数のコンピューティング・デバイスとを含む。第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスは、本明細書において概要を説明されるように設計される可能性がある。特に、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスは、対応する第１の複数のトポロジーのリストおよび対応する第２の複数のトポロジーのリストを含む。言い換えると、コンピューティング・デバイスのそれぞれは、対応するトポロジーのリストを含む。第１の複数のトポロジーのリストは、第２の複数のコンピューティング・デバイスの対応する第１の複数の基準コンピューティング・デバイスを示し、第２の複数のトポロジーのリストは、第１の複数のコンピューティング・デバイスの対応する第２の複数の基準コンピューティング・デバイスを示す。特に、第１の複数の基準コンピューティング・デバイスは、第２の複数のコンピューティング・デバイスのランダムな選択である可能性があり、第２の複数の基準コンピューティング・デバイスは、第１の複数のコンピューティング・デバイスのランダムな選択である可能性がある。結果として、単一障害点のリスクが削減される。

分散型ネットワークは、第１のトポロジーのエリアおよび第２のトポロジーのエリアに第１のコントローラ・ノードおよび第２のコントローラ・ノードをそれぞれさらに含む可能性がある。第１のコントローラ・ノードおよび第２のコントローラ・ノードは、それぞれ、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスの指示を提供することができる。第１のコントローラ・ノードおよび第２のコントローラ・ノードは、メディア・クラウドのそれぞれのコンピューティング・デバイス内に統合される可能性がある。第１のコントローラ・ノードおよび第２のコントローラ・ノードは、コンピューティング・デバイスがそれらのコンピューティング・デバイスのトポロジーのリストおよびそれらのコンピューティング・デバイスのローカル・リソース・リストを構築することを可能にするためにコンピューティング・デバイスのそれぞれによってアクセスされ得る。第１のコントローラ・ノードおよび第２のコントローラ・ノードは、それぞれ、第１のトポロジーのエリアおよび第２のトポロジーのエリア内に含まれるコンピューティング・デバイスの完全な像（ｖｉｅｗ）を有する可能性がある。したがって、コンピューティング・デバイスは、そのコンピューティング・デバイスのローカル・リソース・リストおよびそのコンピューティング・デバイスのトポロジーのリストのために適切な近隣のコンピューティング・デバイスおよび代表コンピューティング・デバイスを選択することができる。さらに、第１のコントローラ・ノードは、第２のコントローラ・ノードに指示を提供し、第２のコントローラ・ノードは、第１のコントローラ・ノードに指示を提供し、それによって、第１のトポロジーのエリアのコンピューティング・デバイスが第２のコントローラ・ノードにアクセスすることを可能にすることができる。

概して、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスのそれぞれは、それぞれのコンピューティング・デバイスの近隣の所定の数の近隣のコンピューティング・デバイスのコンピューティング・リソースを示すローカル・リソース・リストを含む。したがって、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスのそれぞれは、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスのうちの他方とは無関係に、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスのそれぞれのローカル・リソース・リストと、第１の複数のコンピューティング・デバイスおよび第２の複数のコンピューティング・デバイスのそれぞれのトポロジーのリストとに（のみ）基づいてコンポーネント配置要求を処理するように適合される。言い換えると、メディア・クラウド内のコンピューティング・デバイスは、（そのコンピューティング・デバイスのローカル・リソース・リストおよびそのコンピューティング・デバイスのトポロジーのリストに含まれる限られたリソースおよびトポロジー情報に基づいて）メディア・クラウド内のその他のコンピューティング・デバイスとは無関係にコンポーネント配置要求を処理することができる。

さらなる態様によれば、コンピューティング・デバイスの分散型ネットワークにおいてアプリケーションのコンポーネントを配置するための方法が説明される。コンピューティング・デバイスは、本明細書において概要を説明されるように設計される可能性がある。方法は、第１のトポロジーのエリア内の第１のコンピューティング・デバイスにおいてコンポーネント配置要求を受信するステップを含む。方法は、第１のコンピューティング・デバイスのトポロジーのリストに基づいて、コンポーネントが第１のトポロジーのエリアに配置されるべきか、または第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに配置されるべきかを判定することで進行する。コンポーネントが第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに置かれるべきであると判定される場合、コンポーネント配置要求は、第１のトポロジーのエリア以外の複数のトポロジーのエリアのそれぞれのトポロジーのエリアの基準コンピューティング・デバイスに渡される。コンポーネントが第１のトポロジーのエリアに置かれるべきであると判定される場合、アプリケーションのコンポーネントを実行するためのコンピューティング・リソースを有する選択されたコンピューティング・デバイスが、第１のコンピューティング・デバイスのローカル・リソース・リストから特定される。

選択されたコンピューティング・デバイスは、コンポーネント配置要求を受信することができ、その選択されたコンピューティング・デバイスが、選択されたコンピューティング・デバイスのローカル・リソース・リストから、アプリケーションのコンポーネントを実行するためのコンピューティング・リソースを有する別のコンピューティング・デバイスを特定する可能性があることに留意されたい。収束を保証するために、ローカル・リソース・リストの別のコンピューティング・デバイスにコンポーネント配置要求を渡すことは、改善条件にしたがう可能性があり、例えば、別のコンピューティング・デバイスによって提供されるコンピューティング・リソースがローカル・リソース・リストのルート・ノードのコンピューティング・リソースを所定の量（例えば、２０％）だけ超えることが課せられる可能性がある。

上で示されたように、コンポーネント配置要求は、コンポーネントまたはアプリケーションによって処理されるデータのソースのシンクの場所に関する情報を含む可能性がある。コンポーネントを配置するためのトポロジーのエリアは、ソースのシンクの場所に基づいて決定される可能性がある。

方法は、初期化段階の間に、Ｖｉｖａｌｄｉアルゴリズムを使用して分散型ネットワークのコンピューティング・デバイスの相対的な位置を決定するステップと、Ｍｅｒｉｄｉａｎアルゴリズムを使用して、コンピューティング・デバイスを、第１のトポロジーのエリア、および第１のトポロジーのエリア以外の複数のトポロジーのエリアにクラスタ化するステップとを含む可能性がある。

さらなる態様によれば、ソフトウェア・プログラムが説明される。ソフトウェア・プログラムは、プロセッサでの実行のために適合され、コンピューティング・デバイスで実行されるときに、本明細書において概要を説明される方法のステップを実行するように適合される可能性がある。

別の態様によれば、ストレージ媒体が説明される。ストレージ媒体は、プロセッサでの実行のために適合され、コンピューティング・デバイスで実行されるときに本明細書において概要を説明される方法のステップを実行するように適合されたソフトウェア・プログラムを含み得る。

さらなる態様によれば、コンピュータ・プログラム製品が説明される。コンピュータ・プログラムは、コンピュータで実行されるときに本明細書において概要を説明される方法のステップを実行するための実行可能命令を含み得る。

本明細書において概要を説明される方法およびシステムの好ましい実施形態を含む方法およびシステムは、単体で、または本明細書において開示されるその他の方法およびシステムと組み合わせて使用され得ることに留意されたい。さらに、本明細書において概要を説明される方法およびシステムのすべての態様は、任意に組み合わされ得る。特に、請求項の特徴は、互いに任意に組み合わされ得る。

本発明が、添付の図面を参照して以下で例示的に説明される。

クラウド内のコンピューティング・ノードの例示的な配置を示す図である。 クラウド内のコンピューティング・ノードの例示的な領域のグループ分けを示す図である。 複数のコンピューティング・ノードの領域のグループ分けの例示的な図である。 コンピューティング・ノードの例示的なブロック図である。 例示的なリソースおよびトポロジー・グラフを示す図である。 図５のグラフをコンピューティング・ノードの例示的なメモリ・テーブルとして示す図である。 アプリケーションの例示的なコンポーネントを示す図である。 リソース・グラフの例示的な最適化プロセスを示す図である。

今日まで、ネットワークの増大する転送容量の需要は、主に、技術の飛躍的進歩かまたは新しいインフラストラクチャの要素の設置かのどちらかによってネットワークの設置される帯域幅を広げることによって達せられている。しかし、増大する容量の需要に影響されるネットワークのこの発展は、少なくとも無理のないコストでは継続すると期待され得ないという大きな懸念がある。将来のネットワークの改良がますます難しくなるので、増大する容量の需要を満たすための代替的な手法が必要とされている。ネットワーク容量の増大する需要に対処する十分に確立された手法は、ネットワークに「上位層の（higher layer）」インテリジェンスを追加することである。追加される「上位層の」インテリジェンスは、例えば、トラフィックを局所化することによって全体的なトラフィックを削減し、したがって、利用可能な転送量を増やすことを目標とする。「上位層の」インテリジェンスのこの概念の最初の成功は、コンテンツ・デリバリ・ネットワーク（ＣＤＮ）の導入であった。ＣＤＮは、基本的に、インターネットにおいて放送配信の特徴を含む（メディア）サービスの大規模な採用を可能にする。

しかし、メディア・ストリームがインターネット内のどこかで、すなわち、クラウドで処理を受けることを要し、それによって、例えば、ＩＰ−ＴＶをパーソナライズされた「多視点」ビデオ・サービスに発展させることを可能にする（例えば、Ishfaq Ahmad、「Multi-View Video:Get Ready for Next-Generation Television」、IEEE Distributed Systems Online、第８巻、第３号、２００７年、論文番号０７０３−ｏ３００６参照）か、または「ＯｎＬｉｖｅ」（例えば、OnLive、http://www.onlive.com/参照）のようなクラウドに基づくゲーム・サービスを可能にする必要があるパーソナライズされたメディア・ストリームへの潮流が起こりつつある。ＣＤＮは同じコンテンツを多数の受信者に効率的に配信するために構築されるが、ネットワーク内での処理を必要とする個別化されたコンテンツ・ストリームの新しい潮流は、インターネット・インフラストラクチャを課題としている。

今日のアプリケーションおよび対応するクラウド・インフラストラクチャは、概して、データが、アプリケーションが実行される専用の場所（すなわち、データセンター）にネットワークを通じて移動させられるように設計される。将来のインターネット設計にこのクラウド・コンピューティングのパラダイムを残すことは、メディア・ストリームの処理機能が置かれている「任意の」データセンターに転送される必要がある膨大な量のトラフィックをもたらすこととなる。本明細書では、指定されたデータセンターでの集中型のアプリケーション処理のこのパラダイムを変更することが提案される。特に、アプリケーションの要件にしたがってアプリケーションまたはアプリケーションの一部の移動を施行するインテリジェントなインフラストラクチャが提案される。そのような方式は、トラフィックを局所化することによってネットワークからの不必要な「長距離」トラフィックをオフロードすることができ、したがって、将来のネットワークにおける転送容量の限られた可用性の問題を克服するのに役立つ。

今日のクラウド・インフラストラクチャでも、コンピューティング・インフラストラクチャをインターネットにオフロードすることが、欠かせないものとなっている。Amazon EC2、Rackspace、またはMicrosoft Azureのようなクラウド・コンピューティング・プロバイダは、自身のインフラストラクチャまたはプラットフォームを、FacebookまたはAnimotoのようなインターネットに基づくサービスの極めて動的なニーズをサポートする、自動化されたスケーラビリティおよび即座の展開のような特徴を提供するサービスとして提供する。

しかし、今日の手法は、大きなコストがかかり、トラフィックを局所的に保つのではなくより多くのトラフィックが（クラウド・コンピューティング・プロバイダによって提供される）集中型のデータセンターにルーティングされるのでコア・ネットワークに対する全体的な負荷を増やす。集中型のデータセンターは、データを処理し、そのデータを要求元に送り返す。これはこれまでの要求／応答に基づくウェブ・サービスに関しては実現できそうであるが、この集中型の手法は、パーソナライズされたMultiViewビデオのレンダリングのような巨大なメディア中心のリアルタイム・アプリケーションのための実際のインターネット・アーキテクチャの設計をだめにする可能性がある。

インターネットが、開発者およびエンド・ユーザがそれらの開発者およびエンド・ユーザのパーソナライズされたアプリケーションを統合されたネットワークおよびコンピューティング・インフラストラクチャで実行することを可能にするサービス指向のコンピューティング・パラダイムを直接サポートする固有の能力を組み込むことが、提案される。

自律的なサービスが、そのようなアプリケーションが構築され得るコンポーネントであるべきである。自律的なサービスは、そのマシン上でのそれらのサービスの物理的なインスタンス化によってアドレス指定される特定のホスト・インフラストラクチャ・ハードウェアに拘束されるべきでなく、分散型のコンピューティング・リソース上に動的に展開され、データ・フローのソースとシンクとの間でデータ・フローに対して並べて配置（collocate）され得る移動可能なオブジェクトになるべきである。

自律的なサービスは、サービスの動的な組み立てと、ワークフローまたはコンテキストの条件が変わる場合のサービスの潜在的な適合または再配置とを可能にするために、サービスの明確に定義された抽象化モデルを利用する可能性がある。サービス・コンポーネントの疎結合が、要求に応じてサービスのワークフローの相互接続を可能にすべきであり、（サービスおよびそれらのサービスのインターフェースが何らかの意味的なサービスの記述を有するとすれば）サービスの組み立てを修正することによって、ユーザに同じ関連するデータを提供するために必要とされるワークフローの適合を容易にすべきである。

ユーザの視点から見ると、通常、クラウドは、集中型のサーバのように振る舞う。それにもかかわらず、通常、クラウドは、一貫した方法で、空きリソースの集約されたまたは分散された集合を利用する。計算負荷およびネットワーク・リソースを監視することによって、インスタンスを動的に拡大および縮小し、必ずしもデータ・パスにＱｏＳ（サービス品質）管理メカニズムを適用することなくネットワーク負荷を管理することができる。

特にメディア・アプリケーションにおいて、そのようなコンポーネントは、別のデータ・ストリームを生成するためにデータを消費するデータ変換サービス、すなわち、エンティティとして実装される可能性がある。言い換えると、メディア・アプリケーションは、一連のデータ変換サービスとしてモデル化され得る。したがって、ビデオ・カメラは、ビデオ・データを生成したデータ・ソースである。ビデオ・コーデック、スケーリング・コンポーネント、またはフレーム化コンポーネントのようなビデオ処理コンポーネントは、メディア・ストリームを、例えば、モバイル端末またはＴＶディスプレイのためのふさわしいフォーマットに適合するためのデータの変換を可能にする可能性がある。画像認識は、ビデオ信号からオブジェクトを特定することができ、それらのオブジェクトは、シーンの３Ｄモデルを生成するために異なるソースからマージされる可能性がある。

そのようなデータ変換モデルおよびカメラの元のビデオ・ストリームを用いて、ユーザのための新しいパーソナライズされた像がレンダリングされ、ディスプレイに送信される可能性がある。そのようなサービスは、有向グラフによって表される可能性があり、展開時にインスタンス化されることになる。インスタンス化プロセス中に、必要とされるリソースが、利用可能なリソース・プールから選択される。必要とされるリソースをインスタンス化プロセス中に選択することの結果として、ネットワークに対してサービスによって課されるトラフィック全体が削減される。言い換えると、リソース選択プロセスは、ネットワークに対してサービスによって課されるトラフィック全体を削減することを目的とする可能性がある。リソース選択プロセスは、サービスの消費者のＱｏＥ（体感品質）の点を最適化することをさらに考慮する可能性がある。

さまざまなサービスの特徴を有するアプリケーションは、メディア・クラウド（ＭＣ）の概念から恩恵を受ける程度が異なる可能性がある。大きな恩恵は、特定の期間にわたり連続的なデータの安定したフローを必要とするアプリケーション、または処理のために大量のデータの転送を必要とするアプリケーションで実現され得る。一方、ごく限られたデータの転送しか必要としないアプリケーションに関しては、サービスの転送のオーバーヘッドおよびインスタンス化のコストが、得られる恩恵を上回る可能性がある。したがって、データに関連する「メタ情報」の取得を可能にするメカニズムを提供することが、ＭＣの概念で有益である可能性がある。データに関連するそのような「メタ情報」は、データが一定のメディア（例えば、ビデオ）ストリームであるか若しくはサービスの実行前に転送される必要がある限られた量のデータ（例えば、データ・ファイル）に過ぎないかどうか、データがどこにあるか、またはサービスの実行のためにどれだけのデータが転送される必要があるかに関する情報を提供する可能性がある。

ネットワーク・アーキテクチャによって本質的にメディア・クラウドの筋書きをサポートするために、既存のインターネット・アーキテクチャのいくつかの基本的な原理が再考されるべきである。第１に、コンテンツ・ネットワーキングのよく知られている原理が、本明細書に記載のＭＣの手法をサポートするように拡張されるべきである。コンテンツ・ネットワークは、データの局所性を探る、つまり、ソースにおけるデータに対する要求を満たすのではなく、データのローカルのキャッシュされたコピーが配信される。コンテンツを直接アドレス指定し、コンテンツが生成された場所をルーティングの決定のために使用するのではなくこの情報をルーティングの目的に使用する方式が、提案され得る。

上述の方式の拡張は、コンテンツをアドレス指定すべきであるだけでなく、さらに、要求されたデータを提供することができるサービスをアドレス指定し、必要な変換を行うための処理パイプラインをインスタンス化すべきである。単一のドメイン内のすべてのユーザに集中型の処理を実行する代わりに、メディア・フローは、利用できる場合、ネットワーク・レイヤの固有の「マルチキャスト」能力を利用して適切な場所で組み合わされるか、または分割される可能性がある。これは、マルチキャストが、「マルチキャスト」がネットワークでサポートされるかどうかを知らないサービスの開発者によって明示的に組み込まれる必要があり、したがって、オーバーレイ・メカニズムによってのみ実現され得る既存の方式よりも有益である。

異なるサービス・コンポーネント間で交わされる（メディア）フローのトラフィック・パターンが正確に予測される場合、本明細書に記載のＭＣ対応ネットワークは、パケット毎にルーティングの決定を実行する代わりに、直接、そのようなフロー・パターンに対して動作することができる。したがって、ＭＣ対応ネットワークは、サービス・コンポーネント間で交わされるメディア・ストリームの利用可能なメタ情報をネットワークに提供することによって効率的なフローに基づくスイッチングを可能にすることができる。この情報は、そのようなＭＣ対応ネットワークの制御プレーンが全体的なスループットを向上させることを可能にすることができる。

ＭＣ方式は、フローに基づくスイッチング・パラダイムが、概して、フロー制御ハンドラにおいてより大きな動的さをサポートすることを代償として実現されることをやはり考慮し得る。そのような代償を「制限する」ために、ＭＣ対応ネットワークは、同じデータセンターで実行されるサービス・コンポーネント間のパスを共有している複数のデータ・ストリームを集約する能力を提供すべきである。データセンター間のジョイント・ストリームの集約された粒度（granularity）を導入することによって、コア・ネットワーク自体の制御の複雑性が制限され得る。

ＭＣを提供するときのネットワークに対するさらなる要件は、もはやマシンではなくサービス（すなわち、サービス・コンポーネント）であるメディア・フローのエンドポイントの途切れることのない再配置がサポートされるようにしてフローがネットワークで処理されるべきであることである。したがって、ＭＣ対応ネットワークに関しては、ソケット・インターフェースのようなクライアントのＡＰＩが修正される必要がある可能性がある。ＭＣ対応サービスは、概してデータの（１つまたは複数の）入力ストリームに対して動作して、このサービスの後続のコンシューマ・コンポーネントにその後配信される自身の出力データを生成する自己充足的なコンポーネントから構築されるので、通信を目的とする専用のソケットの使用はもはや十分ではない可能性があり、新しいパラダイムが将来のインターネットに関連して考えられる必要がある可能性がある。

図１は、コンピューティング・ノード（コンピューティング・デバイスとも呼ばれる）１０１の集合１００を示す。これらのコンピューティング・ノード１０１は、階層のないフラットな構成を形成し、つまり、集合１００のコンピューティング・ノード１０１のいずれも全体の制御または管理機能を持たない。コンピューティング・ノード１０１のそれぞれは、その他のコンピューティング・ノード１０１とは独立して働き、コンピューティング・ノード１０１で利用可能な集合１００の構造の個々の情報にのみ依存する。集合１００は、本明細書においてはメディア・クラウド（ＭＣ）１００と呼ばれる。さまざまなノード１０１は、インターネットなどの通信ネットワーク１０３を介して相互接続される。

（集中型の方法とは対照的に）分散型の方法でサービスまたはアプリケーションを提供するためにクラウド・コンピューティング機器１０１の分散型の構成１００を使用することが、提案される。サービスまたはアプリケーションの分散型のプロビジョニングの結果として、サービスまたはアプリケーションは、（とりわけ通信ネットワーク１０３の必要とされる送信リソースに関して）リソースがより効率的に利用される方法で提供され得ると期待される。この文脈で、クラウド・コンピューティング機器１０１に関する完全に分散型のリソース管理（ＲＭ）システムが記述され、それにより、クラウド・コンピューティング機器１０１で提供されるＲＭ機能のいずれも、利用可能なリソースおよび構成１００のトポロジーに関する完全な知識を持たない。全体として、ＭＣ１００のノード１０１のそれぞれの自律的な分散型の自立したリソース管理（ＲＭ）機能を提供することが望ましい。

この文脈で、「自律的な」ＲＭ機能とは、各ノード１０１が、実行されるアプリケーションまたはアプリケーションのコンポーネントをどこに持つべきかを決定するために、そのノード１０１のローカルのリソースの近隣のノードについて自律的に決定することを意味する。さらに、「自律的な」ＲＭ機能は、別のクラウドのリソースの領域の代表を自律的に決定する。言い換えると、ＭＣ１００は、複数のクラウドのエリア１０２に細分される可能性があり、第１のエリア１０２のノード１０１のそれぞれが、第２のエリア１０２全体（または第２のエリア１０２の下位領域）の代表である第２のエリアのノード１０１を自律的に選択することができる。したがって、各ノード１０１は、ノードのエリア１０２内のノード１０１の近隣で利用可能であるリソースのローカル・リソース・グラフを自律的に構築することができる。さらに、各ノード１０１は、ＭＣ１００のその他のエリア１０２の代表ノードのトポロジーのリストを構築し、それによって、各ノード１０１にＭＣ１００のすべてのエリア１０２（およびおそらくは下位領域のすべて）への入り口の点（point of entry）を提供することができる。

各ノード１０１のＲＭ機能は、リソース管理機能があらゆるノード１０１に置かれるという点で「分散型」である。一実施形態においては、ノード１０１のいずれも、いかなる特定の特殊な役割（例えば、調整の役割）も持たない。各ノード１０１は、そのノード１０１のＲＭ機能を「自立」して実行し、つまり、ＭＣ１００内でソフトウェア・コンポーネントをどこに置くかの決定が、（上位レイヤの制御機能と調整することなく）当該ノードのＲＭ機能によって単独で実行される。「自立」して働くために、各ノード１０１は、（例えば、ローカル・リソース・グラフによる）近くの／ローカルのリソースの個々の像と、（例えば、トポロジーのリストによる）その他のエリアおよび／または（下位）領域への個々のつながりとを保持する。

ＭＣ１００のノード１０１は、ＭＣ１００内のすべてのノード１０１の位置の共通の全体的なネットワーク・マップを共有しない。その代わりに、各ノード１０１が、ＭＣ１００全体の当該ノードの像を反映する個々のネットワーク・マップを含む。個々のネットワーク・マップは、ローカル・リソース・グラフ（それにより同じエリアまたは領域１０２内の近隣のノードの一部を示す）と、トポロジーのリスト（それによりＭＣ１００の各エリア１０２（または領域）の少なくとも１つの代表ノードを与える）とを含む可能性がある。

図２は、図１と同様のノード１０１の構成（ＭＣ）１００を示す。ノード１０１は、異なるトポロジー上の場所に位置付けられる（例えば、ノード１０１は、異なる国および／または大陸にまたがって分散される）。ＭＣ１００のノード１０１の完全な集合は、ノード１０１のネットワーク１００の地理的エリアと一致する可能性がある複数のエリア１０２に細分される。以下で概要を説明されるように、エリア１０２は、１つまたは複数の領域に細分され得る。ノード１０１は、分散型のＶｉｖａｌｄｉアルゴリズムを使用してＭＣ１００全体の構造を決定し、それによって、ＭＣ１００内の各ノード１０１に関するいわゆるＶｉｖａｌｄｉネットワーク座標を決定することができる。Ｖｉｖａｌｄｉアルゴリズムは、分散型の技術を使用して、ネットワーク１００内のノード１０１間の伝播時間（または往復遅延時間）を推定することができる。推定された伝播時間（または往復遅延時間）は、ＭＣ１００内の各ノード１０１の「座標」を決定し、それによって、ＭＣ１００のトポロジーの全体像を提供するために使用され得る。ノード１０１のＶｉｖａｌｄｉネットワーク座標に対してＭｅｒｉｄｉａｎアルゴリズムを使用して、１つまたは複数の所定の条件（例えば、グループ内での最大往復遅延時間に関する条件）を満たすノード１０１のグループが形成され得る。言い換えると、ＭＣ１００のノード１０１が、各クラスタが１つまたは複数の所定の条件を満たすようにクラスタ化され得る。クラスタは、本明細書においては、トポロジーのエリアまたはトポロジーの領域と呼ばれる（エリアは、領域に細分される可能性がある）。したがって、ＭＣ１００のノード１０１は、トポロジーのエリアまたはトポロジーの領域へのノード１０１のクラスタ化を自律的に決定することができる。結果として、各ノード１０１は、１つ丁度のトポロジーのエリアと、（エリアが（１つまたは複数の）領域に細分される場合は）１つ丁度のトポロジーの領域とに割り振られる。

ノード１０１のトポロジーのクラスタ化３００が、図３に示される。上で示されたように、ＭＣ１００のトポロジーは、（例えば、１つまたは複数の領域３０２を含むエリア１０２の）階層のレベルに順序付けられる可能性がある。したがって、ノード１０１（例えば、図３のノードＢ）は、領域３０２（例えば、領域α）に属すると考えられる可能性があり、領域３０２自体は、エリア１０２（例えば、エリアａ）に属すると考えられる。

特定のノード１０１は、ＭＣ１００全体の限られた像しか持たない可能性がある。ＭＣ１００のこの限られた像は、「自律的な」ＲＭ機能を実行するためにノード１０１によって使用される。ＲＭ機能のこの部分は、ノード１０１によって実行されるトポロジー管理と呼ばれる可能性がある。ＭＣ１００の各エリア１０２（または領域３０２）に到達可能であるために、各ノード１０１は、別のエリア１０２（または領域３０２）の１つの（場合によってはいくつかの）代表をそのノード１０１のトポロジー・ツリーまたはトポロジー・リスト（トポロジーのリストとも呼ばれる）に追加する。ＭＣ１００のノードが１つの階層のレベル、例えば、エリア１０２内に（領域３０２へのいかなる細分化もなしに）編成される場合、各ルート・ノード１０１が、すべてのその他のエリア１０２の（任意の）代表を記憶すべきである。ノード１０１が２つの階層のレベル、例えば、領域３０２およびエリア１０２に編成される（各エリア１０２は１つまたは複数の領域３０２を保有する）場合、各ルート・ノード１０１が、すべてのその他のエリア１０２の（任意の）代表と、このエリア１０２内の領域３０２のいずれかの（任意の）代表とを記憶すべきである。

したがって、各ノード１０１は、エリア１０２内（または領域３０２内）のリソース管理を実行する能力をノード１０１に与えるそのノード１０１のローカル・リソース・グラフ（ＲＧ）のルートの位置にそのノード１０１自身を置く。さらに、各ノード１０１は、そのノード１０１のトポロジーグラフ（またはトポロジー・リスト）のルートの位置にそのノード１０１自身を置く。これは、ノード１０１に、ネットワークのそのノード１０１の個々の像を与える。各（ルート）ノード１０１は、そのノード１０１のトポロジー・グラフ（ＴＧ）にその他の領域３０２（および／またはエリア１０２）の１つまたは複数の代表を追加する。領域３０２内の任意のノードがこの領域３０２の代表になる可能性があり、つまり、すべてのノードは同等であり、エリア１０２または領域３０２のノードのいずれも特別なタスクを持たないことに留意されたい。（エリア１０２および領域３０２を含む）２階層のトポロジーの場合、ノード１０１のＴＧを使用してノード１０１のそれぞれから正しい領域３０２をアドレス指定するために、最大で２つのステップが必要とされる。

図４は、例示的なノード１０１のブロック図を示す。特に、ノード１０１は、ノード１０１のＲＭ機能のために使用されるマッピング機能４０１を含む。さらに、ノード１０１は、１つまたは複数のアプリケーションの１つまたは複数のコンポーネントＣ０、Ｃ１、．．．、Ｃｎを実行するための実行環境４０３を含む。実行環境４０３は、ノード１０１で利用可能なノードのリソース、例えば、メモリまたは処理能力を提供する。さらに、実行環境４０３は、ノード１０１にアクセスするために利用可能なリンクに関する情報を提供することができる。特に、ノード１０１へのリンクの帯域幅、遅延、またはジッタに関する情報が、提供される可能性がある。

図５は、ノード１０１の例示的なグラフ５００を示す。上で示されたように、各ノード１０１（エリアａの領域αのノードＢ）は、同じエリア／領域内のその他のノードのリストを含むローカル・リソース・グラフ５０１を含む。ローカルグラフ５０１は、階層的に編成される可能性があり、階層は、グラフのルート・ノードに対するその他のノードの距離（ｄ）を示す可能性がある。距離（ｄ）は、（距離（ｄ）または階層のレベルが大きくなるにつれて）その他のノードのコンピューティング・リソースに関して利用可能である情報の精度または信頼性が下がることを示すことができる。ローカル・リソース・グラフ５０１に加えて、グラフ５００は、ＭＣ１００のその他のエリア１０２または領域３０２の代表であるノードを示すトポロジー・グラフ５０２を含み得る。

ローカルのおよび領域のトポロジーの情報は、図６に示されるテーブル６００に記憶され得る。テーブル６００は、ローカル・リソース・グラフ６０１のそれぞれのノードに関連するコスト６１１を含めて、ローカル・リソース・グラフ６０１のノードを示す。別のノードのコスト６１１は、別のノードに付与されるリソース値、例えば、利用可能な処理リソース、利用可能なリンクの帯域幅、利用可能なメモリ・リソース、実現可能な往復遅延時間などを含む可能性がある。さらに、テーブル６００は、その他の領域および／またはエリアの代表ノードを示すトポロジー・リスト６０２を提供する。トポロジー情報のエントリは、（領域／エリア毎に単一のエントリではなく）複数の選択肢を保有する可能性もある。したがって、メモリ・テーブル６００は、ＭＣ１００のノードの観点の表現である。通常、ローカル・リソース・グラフ６０１内のノードの数は、エリア／領域内のノードの総数未満の所定の数に制限される。トポロジー・リスト６０２内のエリア／領域毎のノードの数は、エリア／領域内のノードの総数未満のいくつかのノード（例えば、１つまたは２つのノード）に制限される。これは、各ノード１０１が完全なＭＣ１００の制約された像しか持たないことを意味する。

ノード１０１は、テーブル６００のリソースおよびトポロジーを管理する（グラフ５００が、例示を目的として使用される）。リソース・エントリ６１１は、近隣のノードから受信されたコストのタプルの情報を記憶する。ルート要素からの距離（ｄ）に依存して、コストのタプルの値の精度は、正確性、現実性、集約された像（ａｇｇｒｅｇａｔｅｄ ｖｉｅｗ）などに関して変わる可能性がある。コストのタプルは、処理、メモリ、リンクの帯域幅、ＲＴＴ（往復遅延時間）などのリソース値を含み得る。コンポーネントのインスタンス化プロセス（すなわち、コンポーネントの配置プロセス）の場合、ノードは、まず、そのノード自身のリソースの状態を分析し、次いで、それをＲＧ６０１のノードと比較する。ノードは、コンポーネントをローカルでインスタンス化するのか、またはＲＧ６０１内の近隣のノードに要求を転送するのかを決定する。

ローカル・リソース・グラフ５０１、６０１は、ノード１０１によって実行されるリソース管理のために使用され得る。上で示されたように、各ノードは、ノード１０１で利用可能な限られた情報に基づいて、特に、ローカル・リソース・グラフ５０１に基づいて、独立したリソース管理機能を実行する。ローカル・リソース・グラフ５０１は、（概して同じ領域から取得される）ノードの部分集合に基づく。複数の領域３０２の間の境界の近くに位置付けられているノード１０１に関しては、ローカル・リソース・グラフ５０１の近隣のノードが、その他の領域のノードを含む可能性があることに留意されたい。概して、ローカル・リソース・グラフ（ＲＧ）の木の深さは、（近くのネットワークの近隣のノード、または近傍に）制限される。ノード１０１のブート・プロセスにおいて、ローカル・リソース・グラフ内の位置が、（領域の）ノードの所与の集合からネゴシエーションされる可能性がある。言い換えると、ノード１０１は、ローカル・リソース・グラフ内に置かれるべき利用可能なノードの適切な部分集合を選択することができる。継続的な（時間のかかる）最適化プロセスが、ノードを同じ領域内のその他のノードで置き換えることを可能にする。つまり、ルート・ノード１０１は、そのルート・ノード１０１のローカル・リソース・グラフ内のノードがノード１０１のリソース管理機能に（あまり）寄与しないことを見つける場合、寄与しないノードを、ルート・ノード１０１の近隣の別のノードで置き換えることを決定する可能性がある。

したがって、ルート・ノード１０１は、そのルート・ノード１０１のローカルＲＧ５０１の永続的な最適化プロセスを実行することができる。これが、ローカルＲＧ５０１の例示的な更新プロセス８００を示す図８に示される。２つのルート・ノード（Ａ、Ｂ）は、自身のローカルＲＧを独立に設定してある。ＲＧのすべてのノードは、同じ領域内にある。ルート・ノードは、それらのルート・ノードのローカルＲＧのためのよりふさわしいノードを特定するための調査を永続的に実行し、それらを置き換える（可能性がある）（参照番号８０２）。ノードは、実行されているコンポーネントにまったく影響せずに置き換えられる（参照番号８０１）。通常、各ノードは、ＲＧの近隣ノードの最大数を有する可能性があり、そのノードは、ルート・ノードＡのＲＧから出て行く必要があり、別のノード−ここではＸ−によって置き換えられなければならない（参照番号８０３）。言い換えると、各ノードは、所定の最大数のその他のノードのローカル・リソース・グラフの一部である可能性がある。所定の最大数は、利用可能なコンピューティング・リソースに関する情報をその他のノードに報告するために必要とされる労力が無理のないレベルに保たれるように選択され得る。これは、所定の最大数に達する場合、ノードが、それ以上、さらなるローカル・リソース・グラフに属すると考えられ得ないことを意味する。代替的に、ノードは、引き続き、新しいローカル・リソース・グラフに属すると考えられ得るが、同時に、別のローカル・リソース・グラフから削除される必要がある。これが、図８に示されている。

上で示されたように、ローカルＲＧの各ノード１０１は、コストのスカラ／タプル６１１を与えられる。このタプル６１１は、新しいコンポーネントのインスタンス化要求がどこに行われる必要があるかを決定するのに役立つ。言い換えると、ＭＣ１００内でアプリケーションのコンポーネントの実行をどこに委ねるべきかを決定するとき、ノード１０１は、ローカルＲＧ５０１を調べ、ノードによって与えられるコスト６１１に基づいて、ローカルＲＧ５０１内に含まれるノードのうちの１つにコンポーネントを委ねる可能性がある。ローカルＲＧ５０１のノードは、それらのノードのＲＧのルート・ノード１０１に現在のリソースの状態を定期的に知らせる。言い換えると、ローカルＲＧ５０１のノードは、それらのノードのリソースに関する情報をルート・ノード１０１にプッシュし、それによって、ルート・ノード１０１が、裏付けのあるリソース管理の決定を行うことができることを保証する。特に、ローカルＲＧの情報（例えば、コスト６１１）は、（ルート・ノード自身を含む）ローカルＲＧ内のノードのうちの１つをコンポーネントの配置のための適切なノードとして特定するために使用される。コンポーネントの配置プロセスは、数回繰り返される可能性があることに留意されたい。一方、リソース管理機能を実行するためのいかなる中央機能または部分的な中央機能も存在せず、それによって、単一障害点のリスクをなくす。

したがって、各ノード１０１は、ローカル・リソース・グラフ５０１と、その他の領域の１つまたは複数の代表ノードを示すトポロジーのグラフ５０１とを含む限られたネットワークの像５００を有する。上で示されたように、ＭＣ１００のトポロジーは、ＶｉｖａｌｄｉおよびＭｅｒｉｄｉａｎアルゴリズムを用いて分散するようにして決定され得る。初期化段階では、各ノード１０１が、同じ領域／エリア内のノードの完全なリストにアクセスできる可能性がある。ノード１０１は、このノードのリストを使用してローカル・リソース・グラフ５０１を構築する。さらに、初期化段階では、各ノード１０１が、残りの領域／エリアから少なくとも１つのノードを選択する可能性がある。残りの領域／エリアの少なくとも１つのノードの選択は、領域のノードがその他の領域の異なる代表ノードを有することを保証し、それによって、単一障害点または欠陥を防止するために、ランダムに実行されるべきである。

以下で、ノード１０１によって提供されるマッピング機能４０１に関するさらなる詳細が、説明される。ノードで利用可能なトポロジーおよびリソース情報（すなわち、情報５００、６００）に基づいて、ＭＣ１００のノードは、メディア・クラウド・システム１００のノード１０１上のソフトウェア（メディア）コンポーネントの（最適な）配置に関する決定を行うことができる。図７に示されるように、アプリケーション７００は、概して、複数のコンポーネント７０３からなる。例として、電話会議アプリケーションは、複数のオーディオ・コーデック（符号化／復号）コンポーネント（電話会議の各参加者につき１つずつ）と、（参加者の音声チャネルを接続するための）ミキサー・コンポーネントとを含む。通常、アプリケーション７００（およびコンポーネント７０３）は、ソース７０１（データの提供元）およびシンク７０２（データの提供先）を有する。上述の例においては、電話会議アプリケーションの個々の参加者が、ソースおよびシンクであると考えられ得る。コンポーネントの配置プロセスのタスクは、通信ネットワーク１０３のリソースの消費を削減するために、アプリケーション７００のコンポーネント７０３をＭＣ１００内の適切な場所に置くことである。例として、電話会議アプリケーションのオーディオ・コーデック・コンポーネントをそれぞれの参加者の近くに配置することによって、（符号化された音声トラフィックのみが通信ネットワーク１０３を通じて送信されるので）アプリケーションにより必要とされる送信帯域幅が削減され得る。さらに、電話会議アプリケーションのミキサー・コンポーネントは、電話会議の参加者の間の中心の場所に置かれるべきである。

図７において、異なるコンポーネント７０３の間およびソース７０１とシンク７０２との間のリンクの異なる幅は、リンクに関する異なる要件を示す（ラバー・バンド・モデル）。より大きなばね乗数を示すコンポーネント７０３の間のバンドは、コンポーネント７０３が互いに近くに（例えば、同じノードに）置かれるべきであることを示す。

配置手順は、利用可能なノードのリソースおよび利用可能なリンクのリソースを考慮に入れるべきである。さらに、（例えば、プロセッサ・リソース、メモリ・リソース、リンクの帯域幅、遅延、ジッタに関する）アプリケーション・コンポーネント７０３の要件が、考慮に入れられるべきである。

そのような配置の決定は、集中型の方法で実行され得る。しかし、概して、コンポーネントの配置の集中式またはメッシュ式の解決策は、大規模なシステムに見合わない。さらに、そのような集中式の解決策は、単一障害点をもたらす傾向がある。

メディア・クラウド１００のノード１０１において利用可能な限られた情報を用いる分散型の配置方式を利用することが、本明細書において提案される。分散型の配置方式は、個々のノード１０１によって実行される個々のマッピング機能４０１を利用する。これらのマッピング機能は、２つの下位タスク、すなわち、トポロジー管理とリソース管理とに分けられる。トポロジー管理は、ノード１０１のそれぞれで利用可能なトポロジー情報（特に、トポロジー・グラフ５０２またはトポロジー・リスト６０２）を利用する。コンポーネント配置要求は、通常、アプリケーション（またはコンポーネント）のシンクまたはソースについての領域の情報をともなう。ノードは、このトポロジー情報を調べ、トポロジー情報がそのノード自身のトポロジー情報に合致しない場合、要求を領域（またはエリア）の代表に転送する。言い換えると、ノードは、コンポーネントの所望のシンクまたはソースの場所がノードの領域と一致するかどうかを検証する。一致しない場合、コンポーネント配置要求は、（トポロジー・リスト６０２から）ノードに知られている適切なエリアまたは領域の代表ノードに渡される。２階層のトポロジー（領域およびエリア）においては、正しい領域３０２をアドレス指定するために、最大で２つのステップが必要とされる。複数のコンポーネントに関する配置要求の場合、トポロジー・プロセスは、１回実行されれば十分である。言い換えると、（同じサービスまたはアプリケーションに属する）一連の関連するコンポーネントは、単一のステップで配置され得る。

リソース管理は、ＭＣ１００の異なるノードの負荷の状態に応じたローカルのリソース配置を対象とする。ノードは、コンポーネント配置要求を受信し、コンポーネントがそのノードの領域内に置かれるべきであると判定する場合、そのノードのローカル・リソース・グラフ５０１またはテーブル６０１を調べて、コンポーネントを実行するための必要なリソースを有するグラフ５０１内のノードを特定する。概して、ネットワークの異なるノード１０１は、配置されるべきコンポーネントのコピーを既にキャッシュしてある。したがって、通常、特定されたノードでコンポーネントのインスタンス化を開始するだけで十分である。そうでなければ、特定されたノードは、中央コンポーネント・データベースからコンポーネントをダウンロードすることができる。

一例においては、図３のノード３１１（ソース）が、ノード３１２（シンク）を含むシンクを有するアプリケーションの設定を要求する。問題は、ノード３１１がシンクの近くにあるノードをどのようにして発見することができるか（またはその逆）である。上で示されたように、ＭＣ１００の各ノード１０１のマッピング機能（ＭＦ）４０１は、そのノード自身および近隣のノードのリソースの占有およびトポロジー情報を記憶し、したがって、各ノードは、自立してそのノードの配置の決定を行うことができる。第１に、利用可能なトポロジーの情報が、シンクかソースかのどちらかに近いネットワークの領域を発見するために使用される。第２に、選択された領域内の近隣のノードのローカルのリソース情報が使用され、その結果、ノードは、そのノードの近隣のどこに新しいコンポーネントを置くべきかを決定することができる。上述の配置方式を使用すると、ノードのいずれも、ＭＣ１００の完全で厳密なリソースおよびトポロジー情報を知る必要がない。それでも、実現される配置は、ほぼ完全である。本明細書において概要を説明される配置方式においては、ＭＣのノード１０１のいずれも、オンライン処理中に特別な役割を持たないことに留意されたい。結果として、任意のＭＣのノード１０１のうちの１つまたはいくつかが、システムの停止を引き起こさずに故障する可能性がある。

ノードのマッピング決定プロセスは、以下のステップを含み得る。第１のステップにおいて、（コンポーネント配置要求で要求された）シンクがそのノードと同じエリア／領域内にあるかどうかが調べられる可能性がある。そうでない場合、ノードは、要求されたシンクに合致するに違いないエリア／領域内の代表ノードに関してそのノードのテーブル６０２を検索する。ノードは、代表ノードにコンポーネント配置要求を転送する。代表ノードは、シンクがその代表ノードのエリアおよび領域内にあると確認し、そうでなければ、送り先の領域からその個々の代表に要求を転送する必要がある。代表ノードは、近くにあり、コンポーネントを実行するために最良のコスト値を有する最もふさわしいＭＣのノードに関してその代表ノードのローカルＲＧ６０１を調べる。概して、アプリケーションは複数のコンポーネントからなるので、したがって、これらのコンポーネント間の相互接続はさまざまな要件を有することに留意されたい。配置の決定は、アプリケーションのグラフ情報の全体またはより大きな部分がより全体的なマッピングの決定のために提供され得る場合、改善される可能性がある。

上で示されたように、各ノード１０１は、ローカル・リソース・グラフ６０１を含む。コンポーネント配置要求を受信するとき、ノード１０１は、そのノード１０１のローカル・リソース・グラフ６０１内で適切なノードを探索し、このノードにコンポーネント配置要求を転送する。このノードも、ローカル・リソース・グラフ６０１を含み、コンポーネント配置要求を処理するためのそのノードのローカル・リソース・グラフ６０１内の適切なノードを探索する。この繰り返しのプロセスの収束を保証するために、コンポーネント配置要求の転送は、最低限の必要とされる改善に関する条件にしたがう可能性がある。特に、転送がコンポーネントの配置に関する最低限の必要とされる改善につながる場合（例えば、プロセッサの能力／帯域幅の２０％の削減など）にのみ、コンポーネント配置要求がローカル・リソース・グラフ６０１内のノードに転送され得ると規定される可能性がある。

以下では、特定のエリアおよび／または領域トポロジー・コントローラ３０３を含むメディア・クラウド１００の実施形態が説明される。領域のトポロジー・コントローラ３０３は、この領域のすべてのノードのリストを管理するために使用され得る。トポロジー・コントローラ３０３は、いかなるメディア処理、ストリーミング、またはメッセージングにも関与しないが、ＭＣのノードの個々のトポロジーの像を確立するためにマッピング機能４０１をサポートする。これは、概して、トポロジー・コントローラ３０３が、実際のコンポーネント配置プロセスには関与しないが、ノード１０１のそれぞれの初期化プロセスにのみ関与することを意味する。概して、領域毎に１つのトポロジー・コントローラが存在し、トポロジー・コントローラの機能は領域のＭＣのノードのうちの１つの一部である可能性がある。トポロジー・コントローラは、ローカル・リソース・グラフ６０１に関するノードおよび／またはその他の領域６０２のノードを選択するために、ＭＣのノードのブート時に１回だけ要求される可能性がある。

ブート時に、ノード１０１のマッピング機能４０１は、管理プロセスで事前に設定されたそのマッピング機能４０１のトポロジー・コントローラ３０３をアドレス指定する。マッピング機能４０１は、トポロジー情報、例えば、ノードが位置付けられているエリア、領域を取り出す。この情報は、アプリケーション／コンポーネントのシンクかまたはソースかのどちらかの近くにコンポーネントを配置するために処理中に必要とされる。さらに、マッピング機能４０１は、上位集合から最もふさわしい近隣のノードを選択し、これらの近隣のノードのノードＩＤを（マッピングに関連する属性とともに）そのマッピング機能４０１のローカル・リソース・グラフ６０１に結びつけるためにＭＣのノードがアドレス指定することができる近隣のノード（ＭＣのノード）の上位集合を得る。上で示されたように、（好ましくは）リソース・グラフは、複数レベル（ｄ）からなり、子の所与の最大量（ｎ）を有する木構造を有する。さらに、マッピング関数４０１は、近隣の領域／エリアからトポロジー・コントローラの第２のリストを受信し、それによって、ノードが近隣の領域／エリアの代表ノードを特定することを可能にすることができる。つまり、マッピング機能４０１は、それぞれの近隣の領域の１つの個々の代表を要求することができる。この代表は、通常、利用可能なノードのリストからランダムに選択される。これは、負荷を、領域のノードの間に均等に分散させるのに役立つ。上述のブート・プロセスは、ノードが２つの階層レベル（エリアおよび領域）で編成される場合、同様に働く。

したがって、ブート・プロセス中、新しいノード１０１は、ＭＣ１００内のその他のノードのリストを含む所定のトポロジー・コントローラ３０３のアドレスだけを知っている可能性がある。その他のノードのリストは、（例えば、ＶｉｖａｌｄｉアルゴリズムをＭｅｒｉｄｉａｎプロセスと併せて使用して）新しいノード１０１が属するエリア／領域を決定するために新しいノード１０１によって使用される。結果として、新しいノード１０１は、特定のエリア／領域に割り振られ、このエリア／領域のトポロジー・コントローラ３０３のノードのリストに含められる可能性がある。

言い換えると、特定の領域の各ノード１０１は、以下のタスクを実行する可能性がある。ノード１０１は、領域３０２のコントローラ・ノード３０３を知っている。ブート要求があると、ノード１０１は、すべてのエリア／領域からのコントローラ・ノードのリストを得る。ブート要求があると、ノード１０１は、そのノード１０１の領域３０２と、この領域３０２の関連するコントローラ・ノード３０３とを決定する。ブート要求があると、ノード１０１は、直接の（領域の）近隣のノードの任意のリスト（ＲＧ）を得る。要求があると、ノード１０１は、近隣の領域／エリアから１つの任意のノードを得る。通常、領域３０２のコントローラ・ノード３０３は、領域内のすべてのノード１０１を知っており、上位エリア１０２のコントローラ・ノードを知っている。ノードの要求があると、コントローラ・ノード３０３は、そのコントローラ・ノード３０３の領域内のノードのノードＩＤを提供する。さらに、ノードの要求があると、コントローラ・ノード３０３は、領域の代表ノードを提供する。エリア１０２のコントローラ・ノード３０３は、そのコントローラ・ノード３０３の領域３０２のコントローラ・ノード３０３を知っており、すべてのエリア１０２のコントローラ・ノード３０３を知っており、エリアの要求を近隣のコントローラ・ノードに転送する。

本明細書において、クラウド・コンピューティングのためのネットワークおよび対応するコンピューティング・デバイス（ノード）のアーキテクチャが説明された。説明されたアーキテクチャは、アプリケーションのコンポーネントがコンピューティングクラウド内の適切なノードに置かれることを可能にする非集中型のアプリケーション・コンポーネント配置方式の実装を可能にする。説明されたアーキテクチャは、増大する需要に対してスケーラブルであり、単一障害点を示さない。さらに、説明されたアーキテクチャは、クラウド・コンピューティングを使用するときに通信ネットワーク内で必要とされる帯域幅のリソースの削減を可能にする。

説明および図面は、提案された方法およびシステムの原理を例示するに過ぎないことに留意されたい。したがって、当業者が、本明細書において明示的に説明されていないか、または示されていないが、本発明の原理を具現化し、本発明の精神および範囲内に含まれるさまざまな構成を案出することができることは、理解されるであろう。さらに、本明細書に挙げられたすべての例は、提案された方法およびシステムの原理、ならびに当技術分野の発展のために本発明者らがもたらした概念を読者が理解するのを助ける教示のみを特に目的とするようにもっぱら意図されており、そのような特に挙げられた例および条件に限定されないと解釈されるべきである。さらに、本発明の原理、態様、および実施形態、ならびにそれらの特定の例を説明する本明細書のすべての記述は、それらの均等物を包含するように意図される。

さらに、さまざまな上述の方法のステップおよび説明されたシステムのコンポーネントはプログラムされたコンピュータによって実行され得ることに留意されたい。本明細書において、一部の実施形態は、機械またはコンピュータが読むことができ、前記上述の方法のステップの一部またはすべてを実行する命令の機械が実行できるまたはコンピュータが実行できるプログラムを符号化するプログラム・ストレージ・デバイス、例えば、デジタル・データ・ストレージ媒体を包含するようにやはり意図される。プログラム・ストレージ・デバイスは、例えば、デジタル・メモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、または光学式に読み取り可能なデジタル・データ・ストレージ媒体である可能性がある。実施形態は、上述の方法の前記ステップを実行するようにプログラミングされたコンピュータを包含するようにやはり意図される。

加えて、本特許明細書に記載のさまざまな要素の機能は、専用のハードウェアおよび適切なソフトウェアに関連してソフトウェアを実行することができるハードウェアを使用して提供され得ることに留意されたい。プロセッサによって提供されるとき、機能は、単一の専用のプロセッサ、単一の共有のプロセッサ、または一部が共有される可能性がある複数の個々のプロセッサによって提供される可能性がある。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行することができるハードウェアを排他的に指すと考えられるべきでなく、暗黙的に、限定することなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、および不揮発性ストレージを含む可能性がある。通常のおよび／またはカスタムのその他のハードウェアも、含まれる可能性がある。

最終的に、本明細書の任意のブロック図は、本発明の原理を具現化する例示的な回路の概念図を示すことに留意されたい。同様に、任意のフローチャート、流れ図、状態遷移図、擬似コードなどは、実質的にコンピュータ可読媒体で表現され、したがって、コンピュータまたはプロセッサによって、そのようなコンピュータまたはプロセッサが明示的に示されているか否かにかかわらず実行され得るさまざまなプロセスを表すことが、理解されるであろう。

Claims (15)

1. コンピューティング・デバイス（１０１）であって、
   − 前記コンピューティング・デバイス（１０１）は、第１のトポロジーのエリア（１０２）内に位置付けられ、
   − 前記コンピューティング・デバイス（１０１）は、前記第１のトポロジーのエリア（１０２）以外の複数のトポロジーのエリア（１０２）にそれぞれ位置付けられる複数の基準コンピューティング・デバイスを示すトポロジーのリスト（６０２）を含み、
   − 前記コンピューティング・デバイス（１０１）は、前記コンピューティング・デバイス（１０１）の利用可能なコンピューティング・リソースと、前記コンピューティング・デバイス（１０１）の近隣に位置付けられた少なくとも１つの近隣のコンピューティング・デバイス（１０１）の利用可能なコンピューティング・リソースとを示すローカル・リソース・リスト（６０１）を含み、
   − アプリケーション（７００）のコンポーネント（７０３）に関するコンポーネント配置要求を受信すると、前記コンピューティング・デバイス（１０１）は、
   − 前記トポロジーのリスト（６０２）に基づいて、前記コンポーネント（７０３）が、前記第１のトポロジーのエリア（１０２）に置かれるべきであるか、または前記第１のトポロジーのエリア（１０２）以外の前記複数のトポロジーのエリア（１０２）のうちの１つに置かれるべきであるかを判定し、
   − 前記コンポーネント（７０３）が前記第１のトポロジーのエリア以外の前記複数のトポロジーのエリアのうちの１つに置かれるべきであると判定される場合、前記第１のトポロジーのエリア以外の前記複数のトポロジーのエリアのそれぞれのトポロジーのエリアの前記基準コンピューティング・デバイスに前記コンポーネント配置要求を渡し、
   − 前記コンポーネント（７０３）が前記第１のトポロジーのエリア（１０２）に配置されるべきであると判定される場合、前記ローカル・リソース・リスト（６０１）から、前記アプリケーションの前記コンポーネントを実行するための前記コンピューティング・リソースを有する選択されたコンピューティング・デバイスを特定し、
   − 前記選択されたコンピューティング・デバイスがコンピューティング・デバイス（１０１）である場合、コンピューティング・デバイス（１０１）で前記アプリケーション（７００）の前記コンポーネント（７０３）を実行し、そうでない場合、前記選択されたコンピューティング・デバイスに前記アプリケーション（７００）の前記コンポーネント（７０３）に関する前記コンポーネント配置要求を渡す、
   ように適合されているコンピューティング・デバイス（１０１）。
2. 前記少なくとも１つの近隣のコンピューティング・デバイス（１０１）から前記少なくとも１つの近隣のコンピューティング・デバイス（１０１）の前記コンピューティング・リソースに関する情報を受信するように適合されている請求項１に記載のコンピューティング・デバイス（１０１）。
3. − 前記第１のトポロジーのエリア（１０２）内に含まれる第１のコンピューティング・デバイス（１０１）のリストを受信し、
   − 前記ローカル・リソース・リスト（６０１）のために、第１のコンピューティング・デバイス（１０１）の前記リストから複数の近隣のコンピューティング・デバイス（１０１）を、
   − 前記第１のコンピューティング・デバイス（１０１）の前記コンピューティング・リソース、および／または
   − 前記コンピューティング・デバイス（１０１）のリンクの帯域幅の使用に基づいて選択するように適合されている請求項１に記載のコンピューティング・デバイス（１０１）。
4. − 前記ローカル・リソース・リスト（６０１）の近隣のコンピューティング・デバイス（１０１）を、第１のコンピューティング・デバイス（１０１）の前記リストからの新しい近隣のコンピューティング・デバイス（１０１）によって置き換えるように適合されている請求項３に記載のコンピューティング・デバイス（１０１）。
5. − 前記トポロジーのエリア（１０２）は１つまたは複数の領域（３０２）に細分され、
   − 前記トポロジーのリスト（６０２）は、前記複数のトポロジーのエリア（１０２）の前記１つまたは複数の領域（３０２）内に位置付けられた複数の基準コンピューティング・デバイスを示す、請求項１乃至４のいずれか１項に記載のコンピューティング・デバイス（１０１）。
6. コンピューティング・デバイス（１０１）の前記コンピューティング・リソースは、前記コンピューティング・デバイス（１０１）のプロセッサ・リソース、前記コンピューティング・デバイス（１０１）のメモリ・リソース、および前記コンピューティング・デバイス（１０１）へのリンクの帯域幅のうちの任意の１つまたは複数である、請求項１乃至５のいずれか１項に記載のコンピューティング・デバイス（１０１）。
7. 前記少なくとも１つの近隣のコンピューティング・デバイス（１０１）は、前記第１のトポロジーのエリア（１０２）内に位置付けられる請求項１乃至６のいずれか１項に記載のコンピューティング・デバイス（１０１）。
8. − 第１のトポロジーのエリア（１０２）内の、請求項１乃至７のいずれか１項に記載の第１の複数のコンピューティング・デバイス（１０１）と、
   − 第２のトポロジーのエリア（１０２）内の、請求項１乃至７のいずれか１項に記載の第２の複数のコンピューティング・デバイス（１０１）とを含む分散型ネットワーク（１００）であって、
   前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）は、対応する第１の複数のトポロジーのリスト（６０２）および対応する第２の複数のトポロジーのリスト（６０２）を含み、
   前記第１の複数のトポロジーのリスト（６０２）は、前記第２の複数のコンピューティング・デバイス（１０１）の対応する第１の複数の基準コンピューティング・デバイス（１０１）を示し、
   前記第２の複数のトポロジーのリスト（６０２）は、前記第１の複数のコンピューティング・デバイス（１０１）の対応する第２の複数の基準コンピューティング・デバイス（１０１）を示す、分散型ネットワーク（１００）。
9. 前記第１の複数の基準コンピューティング・デバイス（１０１）は、前記第２の複数のコンピューティング・デバイス（１０１）のランダムな選択であり、前記第２の複数の基準コンピューティング・デバイス（１０１）は、前記第１の複数のコンピューティング・デバイス（１０１）のランダムな選択である、請求項８に記載の分散型ネットワーク（１００）。
10. 前記第１のトポロジーのエリア（１０２）および前記第２のトポロジーのエリア（１０２）にそれぞれ第１のコントローラ・ノード（３０３）および第２のコントローラ・ノード（３０３）をさらに含み、
    前記第１のコントローラ・ノード（３０３）および前記第２のコントローラ・ノード（３０３）は、それぞれ、前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）の指示を提供する、請求項８または９に記載の分散型ネットワーク（１００）。
11. 前記第１のコントローラ・ノード（３０３）は、前記第２のコントローラ・ノード（３０３）に指示を提供し、前記第２のコントローラ・ノード（３０３）は、前記第１のコントローラ・ノード（３０３）に指示を提供する、請求項１０に記載の分散型ネットワーク（１００）。
12. − 前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）それぞれは、それぞれの前記コンピューティング・デバイス（１０１）の近隣の所定の数の近隣のコンピューティング・デバイス（１０１）のコンピューティング・リソースを示すローカル・リソース・リスト（６０１）を含み、
    − 前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）それぞれは、前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）のうちの他方とは無関係に、前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）それぞれのローカル・リソース・リスト（６０１）と、前記第１の複数のコンピューティング・デバイス（１０１）および前記第２の複数のコンピューティング・デバイス（１０１）それぞれのトポロジーのリスト（６０２）とにのみ基づいてコンポーネント配置要求を処理するように適合されている、請求項８乃至１１のいずれか１項に記載の分散型ネットワーク（１００）。
13. 請求項１乃至７のいずれか１項に記載のコンピューティング・デバイス（１０１）の分散型ネットワークにおいてアプリケーション（７００）のコンポーネント（７０３）を配置するための方法であって、
    − 第１のトポロジーのエリア（１０２）内の第１のコンピューティング・デバイス（１０１）においてコンポーネント配置要求を受信するステップと、
    − 前記第１のコンピューティング・デバイス（１０１）のトポロジーのリストに基づいて、前記コンポーネント（７０３）が前記第１のトポロジーのエリア（１０２）に配置されるべきか、または前記第１のトポロジーのエリア以外の複数のトポロジーのエリアのうちの１つに配置されるべきかを判定するステップと、
    − 前記コンポーネント（７０３）が前記第１のトポロジーのエリア（１０２）以外の前記複数のトポロジーのエリア（１０２）のうちの１つに配置されるべきであると判定される場合、前記第１のトポロジーのエリア以外の前記複数のトポロジーのエリアのそれぞれのトポロジーのエリアの基準コンピューティング・デバイス（１０１）に前記コンポーネント配置要求を渡すステップと、
    − 前記コンポーネント（７０３）が前記第１のトポロジーのエリア（１０２）に配置されるべきであると判定される場合、前記第１のコンピューティング・デバイス（１０１）のローカル・リソース・リスト（６０１）から、前記アプリケーションの前記コンポーネントを実行するためのコンピューティング・リソースを有する選択されたコンピューティング・デバイスを特定するステップと、
    − 前記選択されたコンピューティング・デバイスが前記第１のコンピューティング・デバイス（１０１）である場合、前記第１のコンピューティング・デバイス（１０１）で前記アプリケーション（７００）の前記コンポーネント（７０３）を実行し、そうでない場合、前記選択されたコンピューティング・デバイスに前記アプリケーション（７００）の前記コンポーネント（７０３）に関する前記コンポーネント配置要求を渡すステップとを含む、方法。
14. 初期化段階の間に、
    − 例えばＶｉｖａｌｄｉアルゴリズムを使用して、前記分散型ネットワーク（１００）の前記コンピューティング・デバイス（１０１）の相対的な位置を決定するステップと、
    − 例えばＭｅｒｉｄｉａｎアルゴリズムを使用して、前記コンピューティング・デバイス（１０１）を、前記第１のトポロジーのエリア（１０２）、および前記第１のトポロジーのエリア（１０２）以外の前記複数のトポロジーのエリア（１０２）にクラスタ化するステップと、をさらに含む請求項１３に記載の方法。
15. − 前記コンポーネント配置要求は、前記コンポーネントによって処理されるデータのシンク（７０２）またはソース（７０１）の場所に関する情報を含み、
    − 前記コンポーネントを配置するための前記トポロジーのエリア（１０２）は、前記シンク（７０２）または前記ソース（７０１）の前記場所に基づいて決定される、請求項１３乃至１５のいずれか１項に記載の方法。

Images