IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

7113840計算ノード管理プロトコルのためのシステムおよび方法
<>
  • -計算ノード管理プロトコルのためのシステムおよび方法 図1
  • -計算ノード管理プロトコルのためのシステムおよび方法 図2
  • -計算ノード管理プロトコルのためのシステムおよび方法 図3
  • -計算ノード管理プロトコルのためのシステムおよび方法 図4
  • -計算ノード管理プロトコルのためのシステムおよび方法 図5
  • -計算ノード管理プロトコルのためのシステムおよび方法 図6
  • -計算ノード管理プロトコルのためのシステムおよび方法 図7
  • -計算ノード管理プロトコルのためのシステムおよび方法 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-07-28
(45)【発行日】2022-08-05
(54)【発明の名称】計算ノード管理プロトコルのためのシステムおよび方法
(51)【国際特許分類】
   G06F 9/50 20060101AFI20220729BHJP
【FI】
G06F9/50 150A
G06F9/50 150C
【請求項の数】 20
(21)【出願番号】P 2019550755
(86)(22)【出願日】2018-03-12
(65)【公表番号】
(43)【公表日】2020-04-09
(86)【国際出願番号】 US2018022033
(87)【国際公開番号】W WO2018169876
(87)【国際公開日】2018-09-20
【審査請求日】2019-09-13
(31)【優先権主張番号】15/459,725
(32)【優先日】2017-03-15
(33)【優先権主張国・地域又は機関】US
【前置審査】
(73)【特許権者】
【識別番号】506332063
【氏名又は名称】セールスフォース ドット コム インコーポレイティッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】トッシュ,ジョージ
【審査官】漆原 孝治
(56)【参考文献】
【文献】特開2008-077281(JP,A)
【文献】特開2005-234931(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/50
(57)【特許請求の範囲】
【請求項1】
人工知能問題解決能力を提供する、ネットワークにわたる計算ノードに対して、計算上の問題を割り当てるための方法であって、
計算ノードから、プロトコルマネージャが、ノード関連処理属性に関する情報を受信するステップであり、前記計算ノードは、前記人工知能問題解決能力および問題解決速度に関して異種の計算ノードであり、前記ノード関連処理属性は、前記計算ノードが解決できる事前設定された問題のタイプの表示、前記計算ノードが前記事前設定された問題を解決できる速度の表示、および、前記計算ノードに関連付けされたネットワーク待ち時間属性を含む、ステップと、
前記プロトコルマネージャが、リクエスト側ポイントに関連付けされた外部のコンピュータから、解決すべき計算上の問題を受信するステップと、
前記計算ノードの前記ノード関連処理属性に基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を解決する能力があるか、および、各計算ノードが前記計算上の問題を解決するのに要する時間の量を決定するために、前記プロトコルマネージャが前記計算ノードの前記ノード関連処理属性を使用するステップと、
前記計算ノードのネットワークロケーション、および、前記計算上の問題を提供したコンピュータに関連付けされたリクエスト側ポイントからのネットワーク距離ベクトルを計算することによって、前記計算ノードに関連付けされたネットワーク待ち時間メトリックを決定し、それにより、前記ネットワーク待ち時間属性を処理するステップと、
計算上の問題を解決する能力がある前記計算ノードのうちの1つ、および、前記計算上の問題を解決するのに要する時間の量の前記決定に基づいて、かつ、前記ネットワーク待ち時間メトリックに基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定するステップと、
含み、
人工知能管理プロトコルは、前記計算ノードの前記人工知能問題解決能力を交換し、かつ、分析するためにそれぞれの問題ルーティングテーブルにアクセスする分配ポイントを使用することによって、前記計算ノード間の情報交換を標準化し、さらに、
前記プロトコルマネージャが、前記計算上の問題を前記決定された1つまたはそれ以上の前記計算ノードに送信するステップと、
前記計算上の問題が計算ノードによって受信されると、前記計算ノードが、前記問題を解決するためにリソースを使用するステップ、および、前記計算ノードが、前記外部のリクエストコンピュータに結果を返すステップと、
を含む、方法。
【請求項2】
前記計算ノードは、異なる人工知能問題解決能力を提供するための人工知能ベースの処理コンポーネントを含む、
請求項1に記載の方法。
【請求項3】
前記方法は、さらに、
人工知能クラスタに配置されている前記計算ノードと関連付けされた技術的能力の自己発見のために、前記人工知能管理プロトコルによるサービスを提供するステップ、
を含む、請求項に記載の方法。
【請求項4】
前記ノード関連処理属性は、前記計算ノードがどの人工知能アルゴリズムを扱うかに関するデータを含み、前記ノード関連処理属性は、前記計算ノードと関連付けされた処理コンポーネントのタイプに基づく処理速度情報を含む、
請求項1乃至のいずれか一項に記載の方法。
【請求項5】
前記計算ノードは、中央処理装置、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、および、グラフィカルプロセッサ装置のうち、2つまたはそれ以上の異なるタイプの処理コンポーネントタイプを含み、
前記2つまたはそれ以上の異なるタイプの処理コンポーネントタイプは、前記計算ノードのための異種の処理環境を構成する、
請求項に記載の方法。
【請求項6】
前記方法は、さらに、
前記処理速度情報を分析するための前記計算ノードの処理コンポーネントタイプを決定するステップ、を含み、
1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定する前記ステップは、前記決定された処理コンポーネントのタイプに基づくものである、
請求項4または5に記載の方法。
【請求項7】
前記方法は、さらに、
前記計算ノードの前記決定された処理コンポーネントのタイプに関する計算上の問題リクエストを検査し、かつ、前記計算上の問題を解決するために、前記計算ノードに関連付けされた人工知能計算リソースを検査するステップと、
前記計算ノードに関連するヘルス情報およびノード故障情報を検査するステップであり、前記検査されたヘルス情報は、前記計算ノードが、計算ノードの各人工知能計算リソースについてアルゴリズムのヘルスチェックをパスするか否かに基づいて決定される、ステップと、
前記計算ノードの負荷を検査するステップと、を含み、
1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定する前記ステップは、前記決定された処理コンポーネントのタイプ、前記検査された計算上の問題リクエスト、前記検査されたヘルス情報およびノード故障情報、前記検査された負荷、および前記決定されたネットワーク待ち時間メトリックに基づいている、
請求項に記載の方法。
【請求項8】
前記方法は、さらに、
情報交換のために、プライマリ分配ポイントとセカンダリ分配ポイントを使用することにより問題ルーティングテーブルにアクセスするステップであり、前記計算ノードの前記人工知能問題解決能力に関する情報を前記計算ノード間で通信する、ステップ、
を含む、請求項1乃至いずれか一項に記載の方法。
【請求項9】
前記方法は、さらに、
前記計算上の問題を解決する特定用途向け集積回路の問題解決速度よりも速い問題解決速度を有するハードウェアのタイプに合わせて、前記プライマリ分配ポイントと前記セカンダリ分配ポイントを使用することにより問題ルーティングテーブルにアクセスする、ステップ、
を含む、請求項に記載の方法。
【請求項10】
人工知能問題解決能力を提供する、ネットワークにわたる計算ノードに対して、計算上の問題を割り当てるためのシステムであって、
1つまたはそれ以上のデータプロセッサと、
前記1つまたはそれ以上のデータプロセッサにオペレーションを実行させるように構成可能である実行可能な命令を含む、メモリ記憶デバイスと、を含み、
前記オペレーションは、
計算ノードから、プロトコルマネージャが、ノード関連処理属性に関する情報を受信するステップであり、前記計算ノードは、前記人工知能問題解決能力および問題解決速度に関して異種の計算ノードであり、前記ノード関連処理属性は、前記計算ノードが解決できる事前設定された問題のタイプの表示、前記計算ノードが前記事前設定された問題を解決できる速度の表示、および、前記計算ノードに関連付けされたネットワーク待ち時間属性を含む、ステップと、
前記プロトコルマネージャが、リクエスト側ポイントに関連付けされた外部のコンピュータから、解決すべき計算上の問題を受信するステップと、
前記計算ノードの前記ノード関連処理属性に基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を解決する能力があるか、および、各計算ノードが前記計算上の問題を解決するのに要する時間の量を決定するために、前記プロトコルマネージャが前記計算ノードの前記ノード関連処理属性を使用するステップと、
前記計算ノードのネットワークロケーション、および、前記計算上の問題を提供したコンピュータに関連付けされたリクエスト側ポイントからのネットワーク距離ベクトルを計算することによって、前記計算ノードに関連付けされたネットワーク待ち時間メトリックを決定し、それにより、前記ネットワーク待ち時間属性を処理するステップと、
計算上の問題を解決する能力がある前記計算ノードのうちの1つ、および、前記計算上の問題を解決するのに要する時間の量の前記決定に基づいて、かつ、前記ネットワーク待ち時間メトリックに基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定するステップと、
含み、
人工知能管理プロトコルは、前記計算ノードの前記人工知能問題解決能力を交換し、かつ、分析するためにそれぞれの問題ルーティングテーブルにアクセスする分配ポイントを使用することによって、前記計算ノード間の情報交換を標準化し、さらに、
前記プロトコルマネージャが、前記計算上の問題を前記決定された1つまたはそれ以上の前記計算ノードに送信するステップと、
前記計算上の問題が計算ノードによって受信されると、前記計算ノードが、前記問題を解決するためにリソースを使用するステップ、および、前記計算ノードが、前記外部のリクエストコンピュータに結果を返すステップと、
を含む、システム。
【請求項11】
前記計算ノードは、異なる人工知能問題解決能力を提供するための人工知能ベースの処理コンポーネントを含む、
請求項10に記載のシステム。
【請求項12】
人工知能クラスタに配置されている前記計算ノードと関連付けされた技術的能力の自己発見のためのサービスが提供される、
請求項10に記載のシステム。
【請求項13】
前記ノード関連処理属性は、前記計算ノードがどの人工知能アルゴリズムを扱うかに関するデータを含み、前記ノード関連処理属性は、前記計算ノードと関連付けされた処理コンポーネントのタイプに基づく処理速度情報を含む、
請求項10乃至12のいずれか一項に記載のシステム。
【請求項14】
前記計算ノードは、中央処理装置、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、および、グラフィカルプロセッサ装置のうち、2つまたはそれ以上の異なるタイプの処理コンポーネントタイプを含み、
前記2つまたはそれ以上の異なるタイプの処理コンポーネントタイプは、前記計算ノードのための異種の処理環境を構成する、
請求項13に記載のシステム。
【請求項15】
前記1つまたはそれ以上のデータプロセッサによって実行される前記オペレーションは、
前記処理速度情報を分析するための前記計算ノードの処理コンポーネントタイプを決定するステップ、を含み、
1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定する前記ステップは、前記決定された処理コンポーネントのタイプに基づくものである、
請求項13または14に記載のシステム。
【請求項16】
前記1つまたはそれ以上のデータプロセッサによって実行される前記オペレーションは、
前記計算ノードの前記決定された処理コンポーネントのタイプに関する計算上の問題リクエストを検査し、かつ、前記計算上の問題を解決するために、前記計算ノードに関連付けされた人工知能計算リソースを検査するステップと、
前記計算ノードに関連するヘルス情報およびノード故障情報を検査するステップであり、前記検査されたヘルス情報は、前記計算ノードが、計算ノードの各人工知能計算リソースについてアルゴリズムのヘルスチェックをパスするか否かに基づいて決定される、ステップと、
前記計算ノードの負荷を検査するステップと、を含み、
1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定する前記ステップは、前記決定された処理コンポーネントのタイプ、前記検査された計算上の問題リクエスト、前記検査されたヘルス情報およびノード故障情報、前記検査された負荷、および前記決定されたネットワーク待ち時間メトリックに基づいている、
請求項15に記載のシステム。
【請求項17】
情報交換のために、プライマリ分配ポイントとセカンダリ分配ポイントを使用することにより問題ルーティングテーブルがアクセスされ、前記計算ノードの前記人工知能問題解決能力に関する情報を前記計算ノード間で通信する、
請求項10乃至16いずれか一項に記載のシステム。
【請求項18】
前記計算上の問題を解決する特定用途向け集積回路の問題解決速度よりも速い問題解決速度を有するハードウェアのタイプに合わせて、前記プライマリ分配ポイントと前記セカンダリ分配ポイントを使用することにより前記問題ルーティングテーブルがアクセスされる、
請求項17に記載のシステム。
【請求項19】
コンピュータで実行可能な命令を含み、プロセッサによって実行されると、コンピュータに方法を実行させる固定のコンピュータ読取可能媒体であって、前記方法は、
計算ノードから、プロトコルマネージャが、ノード関連処理属性に関する情報をネットワークにわたり受信するステップであり、前記計算ノードは、人工知能問題解決能力および問題解決速度に関して異種の計算ノードであり、前記ノード関連処理属性は、前記計算ノードが解決できる事前設定された問題のタイプの表示、前記計算ノードが前記事前設定された問題を解決できる速度の表示、および、前記計算ノードに関連付けされたネットワーク待ち時間属性を含む、ステップと、
前記プロトコルマネージャが、リクエスト側ポイントに関連付けされた外部のコンピュータから、解決すべき計算上の問題を受信するステップと、
前記計算ノードの前記ノード関連処理属性に基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を解決する能力があるか、および、各計算ノードが前記計算上の問題を解決するのに要する時間の量を決定するために、前記プロトコルマネージャが前記計算ノードの前記ノード関連処理属性を使用するステップと、
前記計算ノードのネットワークロケーション、および、前記計算上の問題を提供したコンピュータに関連付けされたリクエスト側ポイントからのネットワーク距離ベクトルを計算することによって、前記計算ノードに関連付けされたネットワーク待ち時間メトリックを決定し、それにより、前記ネットワーク待ち時間属性を処理するステップと、
計算上の問題を解決する能力がある前記計算ノードのうちの1つ、および、前記計算上の問題を解決するのに要する時間の量の前記決定に基づいて、かつ、前記ネットワーク待ち時間メトリックに基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定するステップと、
含み、
人工知能管理プロトコルは、前記計算ノードの前記人工知能問題解決能力を交換し、かつ、分析するためにそれぞれの問題ルーティングテーブルにアクセスする分配ポイントを使用することによって、前記計算ノード間の情報交換を標準化し、さらに、
前記プロトコルマネージャが、前記計算上の問題を前記決定された1つまたはそれ以上の前記計算ノードに送信するステップと、
前記計算上の問題が計算ノードによって受信されると、前記計算ノードが、前記問題を解決するためにリソースを使用するステップ、および、前記計算ノードが、前記外部のリクエストコンピュータに結果を返すステップと、
を含む、コンピュータ読取可能媒体。
【請求項20】
コンピュータで実行可能な命令を含み、プロセッサによって実行されると、コンピュータに方法を実行させるコンピュータプログラムであって、前記方法は、
計算ノードから、プロトコルマネージャが、ノード関連処理属性に関する情報をネットワークにわたり受信するステップであり、前記計算ノードは、人工知能問題解決能力および問題解決速度に関して異種の計算ノードであり、前記ノード関連処理属性は、前記計算ノードが解決できる事前設定された問題のタイプの表示、前記計算ノードが前記事前設定された問題を解決できる速度の表示、および、前記計算ノードに関連付けされたネットワーク待ち時間属性を含む、ステップと、
前記プロトコルマネージャが、リクエスト側ポイントに関連付けされた外部のコンピュータから、解決すべき計算上の問題を受信するステップと、
前記計算ノードの前記ノード関連処理属性に基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を解決する能力があるか、および、各計算ノードが前記計算上の問題を解決するのに要する時間の量を決定するために、前記プロトコルマネージャが前記計算ノードの前記ノード関連処理属性を使用するステップと、
前記計算ノードのネットワークロケーション、および、前記計算上の問題を提供したコンピュータに関連付けされたリクエスト側ポイントからのネットワーク距離ベクトルを計算することによって、前記計算ノードに関連付けされたネットワーク待ち時間メトリックを決定し、それにより、前記ネットワーク待ち時間属性を処理するステップと、
計算上の問題を解決する能力がある前記計算ノードのうちの1つ、および、前記計算上の問題を解決するのに要する時間の量の前記決定に基づいて、かつ、前記ネットワーク待ち時間メトリックに基づいて、1つまたはそれ以上の前記計算ノードのうちどれが前記計算上の問題を処理するのかを決定するステップと、
含み、
人工知能管理プロトコルは、前記計算ノードの前記人工知能問題解決能力を交換し、かつ、分析するためにそれぞれの問題ルーティングテーブルにアクセスする分配ポイントを使用することによって、前記計算ノード間の情報交換を標準化し、さらに、
前記プロトコルマネージャが、前記計算上の問題を前記決定された1つまたはそれ以上の前記計算ノードに送信するステップと、
前記計算上の問題が計算ノードによって受信されると、前記計算ノードが、前記問題を解決するためにリソースを使用するステップ、および、前記計算ノードが、前記外部のリクエストコンピュータに結果を返すステップと、
を含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明開示は、計算ノード(compute node)システムに関する。そして、より特定的には、計算ノード管理プロトコルに関する。
【0002】
この出願は、2017年3月15日提出の米国特許出願第15/459725号に基づく優先権を主張するものである。
【背景技術】
【0003】
計算ノードのクラスタとして配置されている分散コンピューティングシステム(distributed computing systems)は、技術的な複雑性が増加している計算上の問題(computational problem)を解決するのに役立つ。例えば、計算上の問題は、データにおけるパターンを明らかにするために、大規模なデータセットに対する洗練されたアルゴリズム(例えば、人工知能ベースのアルゴリズム)を適用することを含み得る。問題の複雑性が増加していることを考慮して、そうしたシステムのための計算上の要件も、また著しく増加してきた。
【0004】
現在、大部分のアルゴリズムベースのソリューション(solutions)は、様々な機能の計算ノード間に負荷(load)を分散すること(spreading)によって動作する。しかし、これらの異なるメカニズムを管理することは、実装前(before implementation)及び容量変更が発生する場合の両方で、かなりの考察と計画を必要とする。加えて、マシンのクラスタが増える(grow)につれて、リソースの非効率的な利用が生じ得る。
【図面の簡単な説明】
【0005】
本発明は、以下に与えられる詳細な説明から、および、本発明の様々な実施形態に係る添付の図面から、より完全に理解されるだろう。しかしながら、それは、本発明を所定の実施形態について限定するように理解されるべきではなく、説明および理解のためだけのものである。
図1図1は、一つの実施形態に従って、計算環境(computing environment)を示すブロック図である。
図2図2は、計算ノードを示すブロック図であり、それらの技術的能力をアドバタイジング(advertising)している。
図3図3は、計算ノード属性(attributes)の分析を示すブロック図である。
図4図4は、ネットワークの待ち時間特性(latency characteristics)および処理環境特性の解析を示すブロック図である。
図5図5は、能力をアドバタイジングしている計算ノードを含む、動作シナリオを表すフローチャートである。
図6図6は、計算上の問題を解決するための計算ノードリソースの割り当てを含む、動作シナリオを表すフローチャートである。
図7図7は、計算ノードリソースの管理を促進するためのプロトコルデータ構造を示すブロック図である。
図8図8は、オンデマンド(on-demand)マルチテナント(multi-tenant)データベースシステムの一つの例示的な実施形態を表すブロック図である。
【発明を実施するための形態】
【0006】
ここにおいて説明される技術的事項(subject matter)は、計算ノードの処理能力に対してユーザアクセスを提供する技術および物品(articles)を提供する。複雑な問題を解決するために人工知能ベース(AI-based)の計算ノードを使用するため、といったものである。いくつかの実施例において、ここにおいて開示される装置、システム、技術、および物品は、AIベースの計算ノードの大規模な実装を管理するためのプロトコルを提供する。いくつかの実施例において、ここにおいて開示されるシステムおよび方法は、計算ノードのアルゴリズム関連の処理属性を分析し、計算上の問題を解決するためにどのAIベースのコンポーネントが最も適しているかを決定する。
【0007】
図1および以下の説明は、ここにおいて説明される実施態様が実施され得る例示的な環境に係る一つの限定することの無い(non-limiting)実施例の簡単で、一般的な説明を提供するように意図されている。当業者であれば、ここにおいて説明される実施形態は、他のコンピューティング環境を用いて実施され得ることを理解するだろう。
【0008】
図1は、AI処理コンポーネント(AI processing components)102を管理するためのシステムに係る一つの例示的な実施形態100を示している。AI処理コンポーネント102は、複雑な計算上の問題を解決するために使用され、そして、計算ノード(compute node)104と呼ばれる、サーバのクラスタ上で動作する。計算ノード104は、相互に通信して、AI処理コンポーネント102によって提供される一式のサービスをクライアントが利用できるようにする。
【0009】
大きなマルチユーザクラスタが大量のデータにアクセスし、かつ、処理することを要するときに、タスクスケジューリングは、複雑なアプリケーション環境を伴う異種クラスタ(heterogeneous cluster)において特に、技術的なチャレンジ(challenge)を提示し得る。そうした異種環境の一つの例は、中央処理装置(central processing unit、CPU)リソースを使用するいくつかの計算ノードを含み得る。一方で、所定の計算上の問題を解決するために、特定用途向け集積回路(Application Specific Integrated Circuit、ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array、FPGA)、またはグラフィカル処理装置(Graphical Processor Unit、GPU)リソースを使用し得る。一つの例示として、108における計算ノード1は、この実施例において、ペリフェラルコンポーネントインターコネクト(Peripheral Component Interconnect、PCI)バスに接続された、マップ縮小機能(map reduction function)を取り扱うための3つの専用ASICを有しており、一方で、108における計算ノード2は、DNAシーケンシング(sequencing)を分析するためにCPU実装の(CPU-implemented)機械学習(machine learning)アルゴリズムを使用する。
【0010】
システム100は、大量のデータを処理するためのAIベースの計算ノード104の実装の管理を支援するためにAI管理プロトコル110を提供する。AI管理プロトコル102は、AIベースの計算ノード104によって提供される利用可能な計算リソースを活用することを可能にする。より具体的には、AI管理プロトコル110は、AI空間において大きく複雑な数学的問題を解決する目的のために、ASIC、FPGA、GPU、CPU、および他のデバイスの利用に備えている。
【0011】
計算ノード104は、AI管理プロトコル110を使用して、それぞれのハードウェア/ソフトウェアの問題解決能力に関して、データ通信ネットワーク112を介して相互に情報を交換する。計算ノード104からのそうした情報に基づいて、プロトコルマネージャ114は、システムのAIリソースのうちのどれがリクエスト(request)116を処理すべきかを決定することによって、計算上の問題リクエスト116を取り扱う。
【0012】
データ通信ネットワーク112は、一式の処理サービスが分散AIベースのコンピューティングアプリケーションを通じて利用可能であるように、計算ノード104を相互接続する。計算ノード106間で情報の交換を取り扱うデータ通信ネットワーク112は、デバイス、システム、またはコンポーネント間で、メッセージまたはデータを送信することができる任意のデジタルまたは他の通信ネットワークであってよい。所定の実施形態において、データ通信ネットワーク112は、パケットベースのデータ通信、アドレス指定(addressing)、およびデータルーティングを促進するパケット交換ネットワーク(packet switched network)を含んでいる。パケット交換ネットワークは、例えば、ワイドエリアネットワーク、インターネット、等であり得る。様々な実施形態において、データ通信ネットワーク112は、任意の数の通信プロトコルをサポートする任意の数のパブリックまたはプライベートなデータ接続、リンク、またはネットワーク接続を含んでいる。データ通信ネットワーク112は、例えば、インターネット、もしくは、TCP/IPまたは他の従来のプロトコルに基づく他の任意のネットワークを含み得る。様々な実施形態において、データ通信ネットワーク112は、また、イーサネット(Ethernet)またはインフィニバンド(Infiniband)通信リンク(EthernetおよびInfinibandは商標(trademark)である)、並びに、移動電話、パーソナルデジタルアシスタント、及び/又は、類似のものと通信するためのセルラー通信ネットワークといった、無線及び/又は有線電話ネットワークを組み込むこともできよう。データ通信ネットワーク112は、また、1つまたはそれ以上のIEEE 802.3、IEEE 802.16、及び/又は、IEEE 802.11ネットワーク、及び/又は、短距離(例えば、Bluetooth(登録商標))プロトコルを実装するネットワークといった、任意の種類の無線または有線のローカル及び/又はパーソナルエリアネットワークを組み込むこともできる。簡潔のために、データ伝送、信号伝達(signaling)、ネットワーク制御、および、システムの他の機能的態様(および、システムの個々の動作コンポーネント)に関連する従来技術は、ここにおいて詳細には説明されていない。
【0013】
図2は、システム100内のリソースに対して計算上の問題を適切に割り当てることに使用するためのノード処理属性データ200を提供することによって、その技術的能力をアドバタイジングしている(advertising)計算ノード104を示す。プロトコルマネージャ114は、計算ノード104によって送信されたノード処理属性データ200を管理するためのアドバタイジング処理機能202を含んでいる。アドバタイジング処理プロセス202は、計算ノード104の技術的能力を保管し、そして、システム100内の他の計算ノード104と情報を交換する。このようにして、プロトコルマネージャ114は、人工知能クラスタにおける計算ノード104の自己発見(self-discovery)およびクラスタ内の技術的能力のアドバタイズ(advertisement)のためのサービスを提供する。
【0014】
ノード処理属性データ200は、計算ノード104に関連した問題解決能力に関する異なるタイプの情報を含むことができる。例えば、ノード処理属性データ200は、特定の計算ノードが取り扱うことができる特定のアルゴリズムを示すことができる。AI管理プロトコル110は、また、ノード毎に複数のアルゴリズム計算リソースをサポートするように構成することもできる。アルゴリズム計算リソースは、多くの異なるタイプのAIアルゴリズムを構成することができる。例えば、システム100は、ニューラルネットワークアルゴリズム、サポートベクトルマシン(support vector machine)アルゴリズム、遺伝的アルゴリズム、等を有し得る。
【0015】
アルゴリズム能力情報は、ASIC(非常に高速で所定のアルゴリズムを解決することができるが、単一の問題に限定されるもの)といった特殊化されたハードウェア、および、CPU(多種多様なタスクを取り扱うことができるが、非常に低速度であるもの)といった特殊化されていないハードウェアを使用する問題を扱う(address)のに役立つ。特殊化されたハードウェアを使用する計算ノードの一つの例は、反陽子物理実験(antiproton physics experiments)における粒子検出のためのFPGAベースのシステムを含む。このシステムの例において、FPGAベースの計算ノードは、粒子イベント分析のためにマルチギガビット毎秒(Gbit/s)の帯域幅(bandwidth)能力を備えている。より具体的に、計算ノードは、リングイメージングチェレンコフ検出器(ring-imaging Cherenkov detectors)、クラスタ探索(cluster searching)、等のためにパターン認識を実行する。さらに、XILINX Virtex 4 FXシリーズといったFPGAは、Rocket IO、並びに、GBit Ethernetを介して高速接続を提供する。以下の参考文献は、追加的な情報を提供するものであり、そして、あらゆる目的のために、それにより、ここにおいて組み込まれている。W.Kuhnら著、”PGA-Based Compute Nodes for the PANDA Experiment at FAIR”、IEEE Xplore、2007年4月、DOI:10.1109/RTC.2007.4382729、である。多くの他のタイプのクラスタアーキテクチャを使用することができる。米国特許第9325593号(タイトル”Systems,methods,and devices for dynamic resource monitoring and allocation in a cluster system”)に記載されているハードウェアシステムおよび通信経路(communication pathways)といったものであり、あらゆる目的のために、それにより、ここにおいて組み込まれている。
【0016】
ノード処理属性データ200は、クラスタ全体を通じて共有されているアルゴリズムIDを使用することによって、計算ノードのアルゴリズム能力を示している。共有されるアルゴリズムIDを用いて、クラスタによって実行されることが可能な各アルゴリズムは、アルゴリズムを解決することができるメトリック識別速度(metric identifying speed)と共にクラスタ全体を通じてアドバタイジングされる。例えば、クラスタ内の単一のアルゴリズムに対するASICの能力、および、複数のアルゴリズムに対するCPUの能力が、そうしたIDを用いて、システム100全体を通じて一貫して通信され得る。
【0017】
図3は、コンポーネント割り当てプロセス302が、計算上の問題を取り扱うための計算ノードを適切に決定することができるように、計算ノード104の技術的能力のアドバタイジングを取り扱うだけでなく、それらの能力を300において分析する、プロトコルマネージャ114を示している。コンポーネント割り当てプロセス302は、計算上の問題が、典型的に、コンピュータのハードウェアまたはソフトウェアによって異なる方法で解決できることを認識している。属性分析プロセス300によって実行された分析を用いて特定の計算上の問題リクエストを検査する(examining)ことによって、コンポーネント割当てプロセス302は、システム100内のハードウェアおよびソフトウェアのどのコンポーネントが最も効率的に問題を解決できるかを決定することができる。
【0018】
プロトコルマネージャ114は多くの異なる方法で構成され得ることが理解されるべきである。例えば、分配(distribution)計算ノード(バックアップも同様)は、プロトコルマネージャ114として動作するよう割り当てられ得る。そうした計算ノードは、ネットワーク上の各マシンの能力およびコストが分かっている。
【0019】
図4は、リソース割り当ての決定において、属性分析プロセス300がコンポーネント割り当てプロセス302による検討のために分析することができる属性の一つの例を示している。例えば、計算ノード104は、AI管理プロトコル110を通じて、それぞれの処理能力、どのアルゴリズムをそれらが取り扱うことができるか、および、計算ノードに関する負荷(load)とヘルス(health)情報をアドバタイジングすることができる。プロトコルマネージャ114は、そうした情報を分析するための追加の機能を含んでいる。例えば、ノード分析プロセス400は、計算ノードが、それが有する各AI計算リソースについてアルゴリズムヘルスチェックをパスするか否かを決定することによって、計算ノード104からのヘルス情報およびノード故障情報(health and node failure information)を評価することができる。一つの例として、コンピュータノードが、そのPCIバスに接続されたマップ低減機能(map reduction function)を取り扱うために3個の専用ASICを有しており、かつ、ASICのうち1個が故障した場合に、コンピュータノードは、AI管理プロトコル110がどのように構成されてきたかに基づいて、クラスタから自身を完全に除去するか、または、劣化した状態において自身をクラスタに対してアドバタイジングし続け得るか、いずれかである。
【0020】
負荷分析プロセス401は、計算ノード104の負荷を評価する。AI管理プロトコル110に従って、各アルゴリズムは、ハードウェアに対してアルゴリズムのサンプル(algorithmic sample)またはプルーフ(proof)を実行することによって生成され、かつ、マイクロ秒で測定される特定の負荷メトリック(load metric)を有している。プルーフは、システム100において使用されるハードウェアのタイプに基づいて変動し得る。例えば、ASICは、CPUよりも典型的に速いGPUよりも、典型的には速い。これは、次いで、システム負荷メトリックと組み合わされて、最終システム負荷メトリックを生成することができ、それによって、プロトコルマネージャ114は、ハードウェアプロファイルごとに負荷をカスタマイズすることができ、同様に、どのマシンが最初または最後に使用されるかについて制御することができる。
【0021】
プロトコルマネージャ114は、さらに、ネットワーク待ち時間(latency)分析プロセス402を含むことができる。ネットワーク待ち時間分析プロセス402は、既知のリクエスト側ポイント(requestor point)からのネットワーク距離ベクトルを計算する。この分析は、データセンター内の既知のリクエスト側ポイントへの待ち時間に関して、AIクラスタにおける計算ノード104を測定することを含んでいる。例えば、外部エンドユーザがリクエストを開始するときに、外部ゲートウェイのルータに最も近い計算ノードは、より小さな計算上の問題について、機能的にネットワーク待ち時間分析402によって、より速い候補とみなされ得る。このことは、いつディザスタリカバリ(Disaster Recovery、DR)データセンター内のノードが利用できるか、および、ネットワークの待ち時間と期待される利用に基づいて、いつワーク(work)を送信することがより効率的であろうかを識別するのに役立つ。
【0022】
図5および図6は、計算ノードがその能力をアドバタイジングする動作シナリオを提供する。計算上の問題を解決するように計算ノードリソースを割り当てるために使用されるものである。図5の動作シナリオにおいて、プロトコルマネージャは、問題を解決する(problem-solving)ノード能力の交換のために分配ポイント(distribution points)を使用することによって、計算ノードについてAI管理プロトコルを実施する。より具体的に、計算ノードは、プロセスブロック500において、プロトコルマネージャが最初に起動した後で、プロトコルマネージャのIPアドレスに関する情報を取得する。この実施例において、プロトコルマネージャは、情報交換のためにプライマリ分配ポイント(primary distribution point、PDP)およびセカンダリ分配ポイント(secondary distribution point、SDP)を使用する。これらのアドレスは、学習したノード機能の完全なテーブルのブロードキャストのために、その後、既定の時間(例えば、30分毎など)に使用される。このことは、ネットワーク上の全てのマシンが、同期しており、かつ、ネットワーク上の他のマシンの能力を知っていることを確実にしている。
【0023】
ネットワークリンク上のアドバタイジング能力の目的のために、以下のマルチキャストIPアドレスを使用することができる。プライマリ分配ポイント:224.0.0.240、UDP 849、および、セカンダリ分配ポイント:224.0.0.241、UDP 849である。AI管理プロトコルのフレキシビリティは、現在で利用可能な最も高速なハードウェア(例えば、ASIC)の使用を超えて、将来において実装され得る新しいタイプのハードウェアに合わせて調整する(scaling)分配ポイントによって部分的に提供されている。
【0024】
この動作シナリオにおいて、計算ノードは同じローカルマルチキャストネットワークの一部である。しかしながら、他の構成が使用され得ることが理解されるべきである。例えば、マルチキャストルーティング(routing)とMPBGP(MultiProtocol BGP)を通して、複数のサイトにわたり機能を拡張することができる。
【0025】
プロセスブロック502において、各マシンは、それらが学習した事前に構成された問題のタイプおよびコストに関する情報を、全ての隣接するマシンに伝える。この動作シナリオにおいて、マシンは、共通の問題識別子(problem identifiers)を用いて、相互に問題解決能力の通信を標準化するために構成されている。
【0026】
計算ノードは、PDPと通信し、そして、次いで、構成されている能力のリストをPDPに対して送信する。PDPは、プロセスブロック504において、この情報をノード情報テーブルに追加し、そして、プロセスブロック506において、ネットワーク上のマシンの能力の完全なリストをマシンに対して提供する。この時点で、マシンは、プロセスブロック508において示されるように、分配ポイントによって送信されたリクエストの処理を開始する準備ができている。
【0027】
図6は、外部リクエストコンピュータ(external requesting computer)が、解決するためにはかなりのリソースを必要とする計算上の問題を有している動作シナリオを提供する。プロセスブロック600において、外部リクエストコンピュータからのリクエストは、事前に構成された仮想IPアドレスに対して送信される。プロセスブロック602においては、問題を現在のアクティブな分配ポイントに対して送信するために、ロードバランサが使用される。負荷分散(load balancing)は、単一のノードが、単に最も高速なハードウェアを有しているために、常に特定の問題がそのノードにルーティングされるようにすることによって圧倒される(overwhelmed)ことにならないことを確保している。
【0028】
プロセスブロック604において、分配ポイントは、次いで、どの計算ノードが使用されるべきかを決定するために、その問題ルーティングテーブルを使用する。アルゴリズムIDは、どのリソースが計算上の問題を取り扱うことができるかを決定することができる。この動作シナリオにおいて、ネットワーク内でAI管理プロトコルに従って動作しているマシンは、実行する計算のタイプそれぞれについて固有のIDを有している。例えば、CPUを有するマシンは、アルゴリズムタイプについてのフィールドにワイルドカード(例えば、"*")を有することができる。それらは、より高いコストではあるが、あらゆるタイプのアルゴリズムを解決することができるからである。計算上の問題を取り扱うことができないマシンは、考慮から除外される。
【0029】
プロセスブロック604は、さらに、他の追加的な要因を考慮する。アルゴリズム速度のコストメトリック(cost metric)、および、計算上の問題を取り扱うためにどのリソースが最低のコストを有するかを決定するためのネットワークのコストメトリック、といったものである。最低コストの計算は、ダイクストラのアルゴリズム(Dijkstra's algorithm)を使用することによって目標に到達するための最低コストのパス(path)を見つける、といった、多くの異なる方法で行うことができる。
【0030】
当技術分野において一般に知られているように、ダイクストラのアルゴリズムは、目標に到達するための異なるパスにわたりコストを割り当てるものである。図6の特定的な動作シナリオにおいては、ノードリソースを評価するためのダイクストラのアルゴリズムにおけるコストとして、以下のアルゴリズムコストを使用することができる。ASIC=100、FPGA=200、GPU=300、およびCPU=400である。これらの値は、ミリ秒単位で測定された、計算上の問題を処理するための総時間を示している。より低い値が計算上の問題を解決するためには好ましく、そして、それにより、ダイクストラのアルゴリズムは最低の値をネイティブに選択することができる。システムエンジニアが特定の目的のためにこれらの値を操作する必要がある場合には、また、これらの値を操作することも可能である。
【0031】
ダイクストラのアルゴリズムは、ネットワークコストといった、他のコストを使用することができる。ネットワークコストは、ミリ秒単位で測定される、現在アクティブな分配ポイントからワーカー(worker)計算ノードへアルゴリズムを送信するための総コストに基づいている。このようにして、ネットワーク待ち時間および解決される問題に対するその影響が考慮されている。例えば、プロトコルマネージャは、より単純な計算上の問題について、遠隔に配置されたASICよりも、ソースに物理的により近いGPUに対して問題をルーティングすることがより安価であることを決定することができる。ここでは、ASICに対して問題をルーティングすることによって、ネットワーク待ち時間がパフォーマンスゲインを上回るだろう。分配ポイントは、ダイクストラのアルゴリズムを使用して、最も適したワーカー計算ノードを選択するために、それ自身と、リモートルータまたはネットワークデスティネーションとの間でネットワークを通じた最短パスを計算することができる。
【0032】
プロセスブロック604において、リソースが決定された後で、計算上の問題は、プロセスブロック606において、このタイプの問題を処理するのに十分に適した計算ノードまたは複数の計算ノードに対して送信される。ワーカー計算ノードによって問題が受信されると、ワーカー計算ノードは、問題を解決するためにそのリソースを使用し、そして、プロセスブロック608において、外部リクエストコンピュータに対して結果を返す。
【0033】
図7は、AI管理プロトコル110が、計算ノード104を管理するためにプロトコルデータ構造(protocol data structure)700を使用できることを示している。一つの実施形態において、プロトコルデータ構造700は、多層データ構造(multi-tiered data structure)を使用することができ、702で示されるように、ノード処理属性データ200および計算ノードの他の情報を保管し、そして、分析する。例えば、プロトコルデータ構造700は、ノード1のデータフィールドを計算するために、702において示されるように、アルゴリズムID、負荷情報、および、ヘルス(health)とノード状態情報、を含むことができる。これにより、特に、プロトコルマネージャ114は、1つまたはそれ以上の計算ノードから欠落している情報を識別することができる。
【0034】
本発明を開示するため、そして、また、あらゆる当業者が本発明を製造し、かつ、使用できるようにするために、実施例が使用されてきているが、本発明の特許可能な範囲は、請求項によって定義されるものであり、そして、そうした当業者について生じる他の実施例を含み得るものである。従って、ここにおいて開示された実施例は、限定するものではないと考えられるべきである。
【0035】
ここにおいて開示されるシステムおよび方法の広い範囲の一つの例として、隣接するマシンと情報を交換するために使用される計算ノードのインターフェイスは、異なる方法で構成されてよい。2台のマシンだけがAI管理プロトコルを用いて動作している場合に、2つのルータは、それらがリンク上で唯一の「アドバタイズメント(”advertisements”)」であることを知っており、そして、それらは相互に能力情報を交換する。この場合には、いずれのマシンも分配ポイントの役割を実行することができる。
【0036】
生産ネットワークの場合には、多くの異なるマシンが一つのネットワークセグメント上に存在し得る。生産リンクにおけるネットワークトラフィックの量を最小化するために、プロトコルマネージャは、ネットワーク内の各マシンの能力およびコストを学習するプライマリ分配マシン(primary distribution machine)(バックアップも同様)を選択する。
【0037】
ここにおいて開示されたシステムおよび方法の広い範囲の別の実施例として、システムおよび方法は、AIクラスタにおける計算ノードサービスの自己発見(self-discovery)、および、クラスタの中で能力のアドバタイズメントができるように構成することができる。そうした機能を用いて、AIクラスタを管理するために必要な人材の数が削減され、一方で、AIクラスタによる最も効率的なリソースの使用を確保している。このことは、高い可用性とフォールトトレランス(fault tolerance)をサポートし、同様に、事前決定されたアルゴリズムプルーフに基づいて精度を確保するように、組み込み(built-in)ヘルスチェックをサポートしている。
【0038】
ここにおいて開示されるシステムおよび方法は、事前に決定された計算(例えば、ネットワーク待ち時間、対アルゴリズム実行時間、対利用可能なハードウェアのタイプおよび量)に基づいて、ディザスタリカバリ(Disaster Recovery、DR)ハードウェアについて、使用することが効率的であるときに、そうすることができるように構成することができる。さらに、認証されていないデバイスがクラスタに参加するのを防ぐように、認証をサポートすることができる。
【0039】
ここにおいて開示されるシステムおよび方法の広い範囲のさらに別の実施例として、多くの異なるタイプのコンポーネントが異種の(heterogeneous)処理環境を構成することができる。中央処理装置(CPU)、グラフィック処理装置(GPU)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、等といったものである。CPUは、汎用プロセッサである。それは、多種多様なオペレーションを実行するようにデザインされているという意味において、汎用(general purpose)である。CPUは多くのタスクを実行し得るが、達成されるパフォーマンスは、より計算集約的なアプリケーションにとって十分ではないことがある。
【0040】
GPUは、コンピュータディスプレイのための画像の作成を促進するようにデザインされている。CPUは、典型的に、シーケンシャルな直列処理のために最適化された少数のコアで構成されているが、一方で、GPUは、典型的に、複数のタスクを同時に取り扱うためにデザインされた、数多くの(thousands of)より小さく、より効率的なコアで構成されている。それらは、テクスチャマッピング(texture mapping)、画像回転(image rotation)、変換(translation)、シェーディング(shading)、等の機能を実行するようにデザインされている。それらは、また、加速されたビデオ復号化のためのオペレーション(例えば、モーション補正など)をサポートすることもできる。
【0041】
FPGAは、プログラムメモリの中に保管されたプログラムを実行しないので、それ自体はプロセッサではないという意味で、CPUまたはGPUとは異なっている。FPGAは、多数のプログラマブルインターコネクトにおいてサスペンドされた(suspended)一式の再構成可能なデジタル論理回路として考えることができる。典型的なFPGAは、また、専用メモリブロック、デジタルクロックマネージャ、I/Oバンク、および、異なるベンダとモデルにわたり変動する他の機能も有し得る。それらは、製造後にカスタマー側で構成することができるので、任意の論理機能(これに限定されるわけではないが、プロセッサコアを含む)を実装するために使用することができる。このことが、再構成可能なコンピューティングおよびアプリケーション固有の処理について理想的ものとしている。
【0042】
ASICは、単一の目的のためにデザインされたチップであり、そして、数学的な問題を解決すること、といった特定の機能だけ実行することができる。ASICの利点は、それが解決するようにデザインされた問題を解決することについて、あらゆる他のソリューションよりも相当に速いことである。不利な点は、それらが構築された目的である問題を解決するためにだけ使用することができるという点で、それらは単一目的であるということである。このことは、特定の問題については役立つが、しかしながら、あらゆる他のタイプの問題については、それらを使用され得ないものにしている。
【0043】
ここにおいて開示されるシステムおよび方法は、また、多くの異なるタイプのコンピュータ読取可能な記憶媒体においても提供され得る。ここにおいて説明されるオペレーションを実行し、そして、システムを実施するためのプロセッサによる実行における使用のための命令(例えば、ソフトウェア)を含む、コンピュータ記憶メカニズム(例えば、CD-ROM、ディスケット、RAM、フラッシュメモリ、コンピュータのハードドライブ、等といった固定の(non-transitory)媒体)を含むものである。
【0044】
さらに、なお、システムおよび方法は、多くの異なるタイプの環境において実施され得る。一時的、永久的、半永久的、またはそれらの組み合わせのいずれかで、1つまたはそれ以上のデータを保管するように構成されたメモリを有する、ここにおいて説明されるコンピュータノードおよび他のコンピューティングシステム、といったものである。さらに、メモリは、揮発性メモリ、不揮発性メモリ、またはそれらの組み合わせを含んでよく、そして、複数のデバイスにわたり分散されてよい。様々な実施形態において、計算ノードおよびコンピューティングデバイスは、半永久的または実質的に永久的な形態でデータを保管するように構成された記憶媒体を含んでよい。様々な実施形態において、記憶媒体は、メモリへと統合され得る。
【0045】
図8は、ここにおいて説明されたシステムおよび方法をユーザが使用することができる環境の別の実施例を示している。図8は、オンデマンドマルチテナント(on-demand multi-tenant)データベースシステム800内で動作しているユーザの一つの例示的な実施形態を示している。図示された図8のマルチテナントシステム800は、複数のテナント間で共有される共通データベース830からのデータ832に基づいて仮想アプリケーション828を動的に作成し、そして、サポートするサーバ802を含んでいる。代替的に、ここにおいては、マルチテナントデータベースとして参照されるものである。仮想アプリケーション828によって生成されるデータおよびサービスは、希望通りに、ネットワーク845を介して任意の数のクライアント装置840に対して提供される。各仮想アプリケーション828は、マルチテナントシステム800に加入している(subscribing)様々なテナントそれぞれについてデータベース830におけるデータ832に対する安全なアクセスを提供する共通アプリケーションプラットフォーム810を使用して、実行中に(またはオンデマンドで)適切に生成される。1つの限定的でない実施例に従って、マルチテナントシステム800は、複数のテナントに係る任意の数の認証されたユーザをサポートすることができる、オンデマンドマルチテナント顧客関係管理システム(customer relationship management、CRM)の形態で実装されている。
【0046】
ここにおいて使用されているように、「テナント(”tenant”)」または「組織(”organization”)」は、マルチテナントデータベース830内でデータの共通サブセットに対するアクセスを共有する1つまたはそれ以上のユーザまたはエンティティのグループを参照するものとして理解されるべきである。この点に関して、各テナントは、それぞれのテナントに関連付けされ、割り当てられ、または、そうでなければ所属する、一人またはそれ以上のユーザを含んでいる。別の言葉で言えば、マルチテナントシステム800内の各ユーザそれぞれは、マルチテナントシステム800によってサポートされている複数のテナントの特定のテナントに対して、関連付けされ、割り当てられ、または、そうでなければ所属している。テナントは、顧客(customer)、顧客部門、事業または法務組織、及び/又は、マルチテナントシステム800内(すなわち、マルチテナントデータベース830において)で特定のセットのユーザについてデータを維持する他の任意のエンティティを代表し得る。例えば、アプリケーションサーバ802は、マルチテナントシステム800によってサポートされている1つまたはそれ以上のテナントと関連付けされ得る。複数のテナントは、サーバ802およびデータベース830に対するアクセスを共有し得るが、サーバ802から各テナントへ提供される特定のデータおよびサービスは、他のテナントへ提供されるものから安全に隔離することができる(例えば、フィルタリングのクライテリア(criterion)としてそのテナントの固有の組織識別子(organization identifier)を使用して、他のテナントが特定のテナントのデータにアクセスすることを制限することによる)。マルチテナントアーキテクチャにより、従って、他のテナントに属するか、または、そうでなければ関連付けされたデータ832のいずれかを必ずしも共有することなく、異なるセットのユーザは、機能性およびハードウェアリソースを共有することができる。
【0047】
マルチテナントデータベース830は、任意の数のテナントと関連付けされたデータ832を保管および管理することができる任意の種類のリポジトリ(repository)または他のデータ記憶システムである。データベース830は、任意のタイプの従来のデータベースサーバのードウェアを使用して、実装され得る。様々な実施形態において、データベース830は、サーバ802と処理ハードウェア804を共有している。他の実施形態において、データベース830は、ここにおいて説明される種々の機能を実行するためにサーバ802と通信する、別個の物理的及び/又は仮想データベースサーバのハードウェアを使用して、実装されている。一つの例示的な実施形態において、データベース830は、仮想アプリケーション828によって開始、または、そうでなければ提供されるクエリに応答して、仮想アプリケーション828のインスタンスについて、データ832の特定のサブセットを検索し、そして、提供するための最適なクエリ計画(query plan)を決定することができる、データベース管理システムまたは他の同等なソフトウェアを含んでいる。マルチテナントデータベース830が、アプリケーションプラットフォーム810によって生成されるオンデマンド仮想アプリケーション828に対して実行中にデータを提供する(または、提供するために利用可能である)という点で、マルチテナントデ得る。
【0048】
実際に、データ832は、アプリケーションプラットフォーム810をサポートするように、任意の方法でオーガナイズされ(organized)、そして、フォーマットされ得る。様々な実施形態において、データ832は、セミアモルファス(semi-amorphous)な「ヒープ(”heap”)」タイプのフォーマットを維持するために、比較的に少数の大きなデータテーブルへと適切にオーガナイズされている。データ832は、次いで、特定の仮想アプリケーション828のために、必要に応じて、オーガナイズされ得る。様々な実施形態において、従来のデータ関係は、インデックス付け(indexing)、一意性(uniqueness)、エンティティ間の関係、及び/又は、希望通りに従来のデータベース組織(organization)の他の態様を確立する任意の数のピボットテーブル834を使用して確立されている。さらに、データ操作およびレポートのフォーマッティング(formatting)は、一般的に、様々なメタデータコンストラクト(constructs)使用して、実行中に行われる。ユニバーサルデータディレクトリ(universal data directory、UDD)836内のメタデータは、例えば、任意の数のフォーム(forms)、レポート、ワークフロー、ユーザアクセス権、ビジネスロジック、および、複数のテナントに共通する他のコンストラクトを記述するために使用することができる。テナント特有のフォーマッティング、機能、および、他のコンストラクトは、希望通りに、各テナントについてテナント特有のメタデータ838として維持され得る。データ832を、全てのテナントおよびアプリケーションに共通なフレキシブルでないグローバル構造へと強制するより、むしろ、データベース830は、必要に応じて追加的な構造を提供するピボットテーブル834およびメタデータ838を用いて、比較的アモルファスであるように構成されている。この目的のために、アプリケーションプラットフォーム810は、仮想アプリケーション828の「仮想(”virtual”)」コンポーネントを生成するために、ピボットテーブル834及び/又はメタデータ838を適切に使用して、データベース830から比較的にモルファスなデータ832を論理的に取得し、処理し、そして、提示する。
【0049】
サーバ802は、仮想アプリケーション828を生成するための動的アプリケーションプラットフォーム810を集合的に提供する、1つまたはそれ以上の現実及び/又は仮想コンピューティングシステムを使用して実装されている。例えば、サーバ802は、典型的には、従来のネットワーク通信、クラスタ管理、負荷分散、および他の適切な機能に伴って、相互に関連して動作する現実及び/又は仮想サーバのクラスタを使用して実装され得る。サーバ802は、プロセッサ805、メモリ806、入力/出力機能807、等といった、任意の種類の従来の処理ハードウェア804を用いて動作する。入力/出力機能807は、一般的に、ネットワーク(例えば、ネットワーク845、もしくは、あらゆる他のローカルエリア、ワイドエリア、または他のネットワーク)、大容量記憶装置、表示装置、データ入力装置、及び/又は類似のもの、に対するインターフェイスを表す。プロセッサ805は、1つまたはそれ以上のプロセッサ、コントローラ、マイクロプロセッサ、マイクロコントローラ、処理コア、及び/又は、任意の数の「クラウドベース(”cloud-base”)」または他の仮想システムを含む、任意の数の分散または統合システムにわたり広がった他の計算リソースといった、任意の適切な処理システムを使用して実装され得る。メモリ806は、プロセッサ805上で実行するためのプログラミング命令を保管することができる任意の固定の短期または長期の記憶装置、もしくは、他のコンピュータ読取可能媒体を表し、任意の種類のランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、フラッシュメモリ、磁気または光大容量記憶装置、および/または、類似のものを含んでいる。コンピュータ実行可能プログラミング命令は、サーバ802及び/又はプロセッサ805によって読み出され、かつ、実行されるとき、サーバ802及び/又はプロセッサ805に、アプリケーションプラットフォーム810及び/又は仮想アプリケーション828を作成し、生成し、または、そうでなければ促進させ、かつ、ここにおいて説明される1つまたはそれ以上の追加的なタスク、オペレーション、機能、及び/又は、プロセスを実行させる。メモリ806は、そうしたコンピュータ読取り可能媒体の一つの適切な実装を表しており、そして、代替的または追加的に、サーバ802は、ポータブルまたは移動可能なコンポーネントまたはアプリケーションプラットフォームとして具現化されている外部のコンピュータ読取り可能媒体、例えば、ポータブルハードドライブ、USBフラッシュドライブ、光ディスク、等を受け入れ、かつ、それらと協働し得るだろうことに留意すべきである。
【0050】
アプリケーションプラットフォーム810は、クライアント装置840に対してデータ及び/又はサービスを提供する仮想アプリケーション828を生成する、あらゆる種類のソフトウェアアプリケーションまたは他のデータ処理エンジンである。一つの典型的な実施形態において、アプリケーションプラットフォーム810は、任意の種類の従来または独自(proprietary)のオペレーティングシステム808を使用して、処理リソース、通信インターフェイス、および、処理ハードウェア804の他の機能に対するアクセスを得る。仮想アプリケーション828は、典型的に、クライアント装置840から受信した入力に応答して、実行中に生成される。図示された実施形態について、アプリケーションプラットフォーム810は、バルクデータ処理エンジン812、クエリジェネレータ814、テキストのインデックスおよび他の検索機能を提供する検索エンジン816、および、ランタイムアプリケーションジェネレータ820を含んでいる。これらの機能それぞれは、別個のプロセスまたは他のモジュールとして実装されてよく、そして、多くの等価な実施形態は、希望通りに、異なる、かつ/あるいは、追加の機能、コンポーネント、または他のモジュールを含み得るだろう。
【0051】
ランタイムアプリケーションジェネレータ820は、クライアント装置840から受信した特定のリクエストに応答して、動的に仮想アプリケーション828を構築し、そして、実行する。仮想アプリケーション828は、典型的には、テナント特有の(tenant-specific)メタデータ838に従って構築されている。特定のアプリケーション828の特定のテーブル、レポート、インターフェイス、及び/又は、他の特徴を記述するものである。様々な実施形態において、各仮想アプリケーション828は、必要に応じて、そのクライアント装置840に関連付けされたブラウザまたは他のクライアントプログラム842に提供され得るダイナミックWebコンテンツを生成する。
【0052】
ランタイムアプリケーションジェネレータ820は、クエリジェネレータ814と適切にインタラクションして、クライアント装置840のユーザによって開始されるか、そうでなければ、提供される入力クエリに応答して、必要に応じて、データベース830からマルチテナントデータ832を効率的に取得する。典型的な実施形態において、クエリジェネレータ814は、特定の機能をリクエストしているユーザのアイデンティティ(identity)を考慮し、そして、次いで、システム全体(system-wide)のメタデータ836、テナント特有メタデータ838、ピボットテーブル834、及び/又は、他の利用可能なリソースを使用して、データベース830に対するクエリを(ユーザが関連するテナントと共に)構築し、そして、実行する。この実施例におけるクエリジェネレータ814は、従って、クエリが、リクエストを開始したユーザ及び/又はテナントに付与された(granted)アクセス権と一致していることを確保することによって、共通データベース830のセキュリティを維持している。このようにして、クエリジェネレータ814は、必要に応じて、データベース830からユーザ及び/又はテナントへアクセス可能なデータ832のリクエストされたサブセットを適切に取得し、ユーザ及び/又はテナントについて、特定の仮想アプリケーション828のテーブル、レポート、または、他の特徴を取り込む(populate)。
【0053】
なおも、図8を参照すると、データ処理エンジン812は、アップロードまたはダウンロード、アップデート、オンライントランザクション処理、及び/又は、類似のもの、といった、データ832上のバルク処理オペレーション(bulk processing operations)を実行する。多くの実施形態においては、処理リソースが利用可能になるにつれて、より緊急でないデータ832のバルク処理が発生するようにスケジュールされ得る。それによって、クエリジェネレータ814、検索エンジン816、仮想アプリケーション828、等による、より緊急なデータ処理を優先することができる。
【0054】
例示的な実施形態において、アプリケーションプラットフォーム810は、サポートするテナントについてデータ駆動型(data-driven)仮想アプリケーション828を作成、かつ/あるいは、生成するために利用されている。そうした仮想アプリケーション828は、カスタム(またはテナント特有)スクリーン824、標準(またはユニバーサル)スクリーン822、等といった、インターフェイス機能を利用することができる。任意の数のカスタム及び/又は標準オブジェクト826も、また、テナントが開発した(tenant-developed)仮想アプリケーション828への統合のために利用可能であり得る。ここにおいて使用されるように、「カスタム(”custom”)」は、それぞれのオブジェクトまたはアプリケーションが、テナント特有(例えば、マルチテナントシステムにおける特定のテナントに関連付けされたユーザだけに利用可能)であり、または、ユーザ特有(例えば、マルチテナントシステムにおける特定のユーザのサブセットだけに利用可能)であることを意味していると理解されるべきである。一方で、「標準(”standard”)」または「ユニバーサル(”universal”)」アプリケーションまたはオブジェクトは、マルチテナントシステムにおける複数テナントにわたり利用可能である。例えば、仮想CRMアプリケーションは、「アカウント(”account”)」オブジェクト、「機会(”opportunity”)」オブジェクト、「接触(”contact”)」オブジェクト、等といった、標準オブジェクト826を利用することができる。各仮想アプリケーション828に関連付けされたデータ832が、必要に応じて、データベース830に提供され、そして、リクエストされるか、または必要とされるまで、その特定の仮想アプリケーション828の所定の特徴(例えば、レポート、テーブル、ファンクション、オブジェクト、フィールド、数式、コード、等)を記述するメタデータ838と共に保管されている。例えば、仮想アプリケーション828は、テナントへアクセス可能な多数のオブジェクト826を含んでよく、ここで、テナントにアクセス可能な各オブジェクト826について、そのそれぞれのオブジェクトタイプに関連付けされる様々なフィールドに対する値と共に、そのオブジェクトタイプに属している情報は、データベース830においてメタデータ838として維持されている。この点に関して、オブジェクトタイプは、それぞれのオブジェクト826の構造(例えば、フォーマット、機能、および他の構成)および、それと関連付けされる種々のフィールドを定義する。
【0055】
なおも、図8を参照すると、サーバ802によって提供されるデータおよびサービスは、ネットワーク845上の任意の種類のパーソナルコンピュータ、移動電話、タブレット、または、他のネットワーク可能なクライアント装置840を使用して取り出す(retrieve)ことができる。一つの例示的な実施形態において、クライアント装置840は、マルチテナントデータベース830から取り出されたデータ及び/又は情報をグラフィカルに提示することができるモニタ、スクリーン、または、別の従来の電子ディスプレイといった、ディスプレイ装置を含んでいる。典型的に、ユーザは、ハイパーテキストトランスポートプロトコル(hypertext transport protocol、HTTP)等といった、ネットワークプロトコルを使用して、ネットワーク845を介してサーバ802にコンタクトするために、クライアント装置840によって実行される従来のブラウザアプリケーションまたは他のクライアントプログラム842を動作させる。ユーザは、典型的には、サーバ802の後に続く通信においてユーザを識別するセッション識別子(”Session ID”)を取得するために、サーバ802に対する自身のアイデンティティを認証する。識別されたユーザが、仮想アプリケーション828へのアクセスをリクエストすると、ランタイムアプリケーションジェネレータ820は、必要に応じて、メタデータ838に基づいて、実行中に好適にアプリケーションを作成する。上述のように、仮想アプリケーション828は、クライアント装置840上で実行されている従来のクライアントソフトウェアを使用して提示することができる、Java(登録商標)、ActiveX、または他のコンテンツを含んでよく、他の実施形態は、必要に応じて、ユーザによって提示され、そして、見ることができる動的なウェブまたは他のコンテンツを単純に提供し得る。
【0056】
一つのテナント(例えば、企業における一つの部署)によって保管されている、知識アーティクル(knowledge article)といった、データアイテムは、別のテナント(例えば、同じ企業における別の部署)に関連(relevant to)し得る。別のテナントドメインにおけるユーザに、物品(article)へのアクセスを提供する一つの方法は、物品の第2インスタンスを第2テナントのテナントドメインに保管することである。ここにおいて説明される装置、システム、技術、および物品は、第2コピーを保管することによってリソースを浪費することなく、別のテナントドメインにおけるユーザに、物品へのアクセスを提供する別の方法を提供する。
図1
図2
図3
図4
図5
図6
図7
図8