特表 2024-504023 エッジサイト選択およびメトリックキャプチャのためのシステムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-01-30

(54)【発明の名称】エッジサイト選択およびメトリックキャプチャのためのシステムおよび方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240123BHJP

【ＦＩ】

G06F9/50 120Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023539845

(86)(22)【出願日】2021-12-29

(85)【翻訳文提出日】2023-08-24

(86)【国際出願番号】 US2021065514

(87)【国際公開番号】W WO2022147126

(87)【国際公開日】2022-07-07

(31)【優先権主張番号】63/132,611

(32)【優先日】2020-12-31

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/138,919

(32)【優先日】2021-01-19

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/476,708

(32)【優先日】2021-09-16

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

２．ＭＯＮＧＯ

３．ＭＯＮＧＯＤＢ

(71)【出願人】

【識別番号】518236786

【氏名又は名称】センチュリーリンク インテレクチュアル プロパティー エルエルシー

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】ベナッシ、ウィリアム アール．

(72)【発明者】

【氏名】オブライエン、ウィリアム

(57)【要約】

コンピューティングネットワークにおけるメトリックキャプチャおよび使用のためのシステムおよび方法が提供される。例において、ネットワークエレメント（ネットワークデバイスおよびワークロードなど）をネットワークにプロビジョニングするプロセスの一部としてネットワークエレメントがメトリック収集のために搭載されることを可能にするためのシステムおよび方法が提供される。例において、ネットワークエレメントに関連付けられたメトリックを収集するための収集コンポーネントを生成するために用いられ得る収集テンプレートが、顧客に提供される。例において、収集されたメトリックは、エッジ推奨システムにより、ネットワークエレメントが最適化基準に従って配置されるべき１つまたは複数の推奨されるエッジサイトを決定するために格納および使用され得る。

【特許請求の範囲】

【請求項1】

ネットワーク内のメトリックをキャプチャする方法であって、
第１の顧客のために第１のネットワークエレメントを第１のネットワークエッジサイトにおいて構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する段階、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む；
リファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する段階；
前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからメトリックのインスタンスをメトリックストレージシステムにおいて受信する段階；
前記メトリックの要求を前記メトリックストレージシステムにおいて受信する段階；および
前記メトリックの前記インスタンスを提供する段階
を備える、方法。

【請求項2】

前記メトリックの前記要求は、エッジ推奨システムから受信され、メトリックの前記インスタンスは、前記エッジ推奨システムに提供され、前記方法は、
前記エッジ推奨システムが第２の顧客の第２のワークロードの推奨されるエッジネットワークサイトを決定する段階；および
前記第２のワークロードの前記推奨されるエッジネットワークサイトを前記第２の顧客に提供する段階
をさらに備える、請求項１に記載の方法。

【請求項3】

前記第１のキャプチャコンポーネントをキャプチャコンポーネントレポジトリに格納する段階；
第２の顧客のために第２のネットワークエレメントを第２のネットワークエッジサイトにおいて構成するための第２の要求を前記ネットワークユーティリティにおいて第２のクライアントデバイスから受信する段階、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスまたは前記第２のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第２のネットワークエレメントの第２の構成ファイルを送信する段階、ここで、前記第２の構成ファイルは、メトリック収集の第２のキャプチャテンプレートを含む；および
リファクタリングされた第２のキャプチャテンプレートを含む第２のキャプチャコンポーネントを含む前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成する段階
をさらに備える、請求項２に記載の方法。

【請求項4】

前記第２の要求の受信に応答して、前記第２のネットワークエレメントは前記第１のネットワークエレメントと同様のタイプのものである、と判断する段階
をさらに備え、
前記第２の構成ファイルを送信する段階は、前記第１のキャプチャテンプレートに基づいて前記第２のキャプチャテンプレートを生成する段階を有する、
請求項３に記載の方法。

【請求項5】

前記第１のネットワークエレメントが前記第１のネットワークデバイスである場合、前記第１のキャプチャコンポーネントは、キャプチャエージェントであり、前記第１のネットワークエレメントが前記第１のワークロードである場合、前記第１のキャプチャコンポーネントは、前記第１のワークロード内の埋め込みＡＰＩである、請求項１から４のいずれか一項に記載の方法。

【請求項6】

前記ネットワークユーティリティは、コンポーネントのインターネット（ＩｏＣ）ファクトリである、請求項１から５のいずれか一項に記載の方法。

【請求項7】

前記第１のキャプチャコンポーネントは、前記第１のキャプチャコンポーネントから前記メトリックの前記インスタンスへのアクセスに関する許可を示すパラメータを含み、前記方法は、
前記メトリックの前記インスタンスを提供する段階の前に、前記許可をチェックする段階
をさらに備える、請求項１から６のいずれか一項に記載の方法。

【請求項8】

前記第１の構成ファイルは、必須メトリックのセットを指定し、前記方法は、前記第１のキャプチャコンポーネントが前記必須メトリックのセットを収集するように搭載されている場合にのみ、前記第１のネットワークエッジサイトにおいて前記第１のネットワークエレメントを構成する段階をさらに備える、請求項１から７のいずれか一項に記載の方法。

【請求項9】

前記第１のキャプチャコンポーネントは、コマンドラインランナーおよび搭載テンプレートを含む、請求項１から８のいずれか一項に記載の方法。

【請求項10】

前記第１のキャプチャコンポーネントは、
ナッシュ均衡アルゴリズム；
入札アルゴリズム；
ポーリングアルゴリズム；
サンプリングアルゴリズム；
予測アルゴリズム；または
確率アルゴリズム
という、前記推奨されるエッジネットワークサイトの決定において用いられるアルゴリズムのうちの少なくとも１つのアルゴリズムに関与するように構成されている、
請求項２に記載の方法。

【請求項11】

前記少なくとも１つのアルゴリズムは、メトリックプレゼンテーションエンジンにより部分的に実行される、請求項１０に記載の方法。

【請求項12】

ネットワークエッジサイトを推奨する方法であって、
第１の顧客のために第１のネットワークエレメントを構成するようプロバイダネットワーク内のネットワークエッジサイトに推奨するための第１の要求を第１のクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含み、前記第１の要求は、第１のコンポーネント情報および第１の最適化基準を含む；
前記第１のコンポーネント情報および前記第１の最適化基準に基づいて第１の関連メトリックを決定する段階；
前記第１の関連メトリックについてメトリックストレージシステムをクエリする段階、ここで、前記メトリックストレージシステムは、前記プロバイダネットワーク上で動作する他のネットワークエレメントからの前記第１の関連メトリックのインスタンスを格納する；
前記第１の関連メトリックの前記インスタンスを受信する段階；
前記第１の関連メトリックの前記インスタンスを用いて、前記第１のネットワークエレメントの少なくとも第１のネットワークエッジサイトの推奨を生成する段階；および
前記推奨を前記第１のクライアントデバイスに提供する段階
を備える、方法。

【請求項13】

前記第１のネットワークエッジサイトの選択を受信する段階；および
前記第１の顧客のために前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する段階
をさらに備える、請求項１２に記載の方法。

【請求項14】

第２の顧客のために第２のネットワークエレメントを構成するよう前記プロバイダネットワーク内のネットワークエッジサイトに推奨するための第２の要求を第２のクライアントデバイスから受信する段階、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスおよび第２のワークロードのうちの少なくとも一方を含み、前記第２の要求は、第２のコンポーネント情報および第２の最適化基準を含む；
前記第２のコンポーネント情報および前記第２の最適化基準に基づいて、前記第１の関連メトリックとは異なる第２の関連メトリックを決定する段階；
前記第２の関連メトリックについて前記メトリックストレージシステムをクエリする段階、ここで、前記メトリックストレージシステムは、前記プロバイダネットワーク上で動作する他のネットワークエレメントからの前記第２の関連メトリックのインスタンスを格納する；
前記第２の関連メトリックの前記インスタンスを受信する段階；
前記第２の関連メトリックの前記インスタンスを用いて、前記第２のネットワークエレメントの少なくとも第２のネットワークエッジサイトの推奨を生成する段階；および
前記推奨を前記第２のクライアントデバイスに提供する段階
をさらに備える、請求項１２または１３に記載の方法。

【請求項15】

前記第１の関連メトリックは、前記第１のネットワークエレメントのタイプに固有である、請求項１２から１４のいずれか一項に記載の方法。

【請求項16】

少なくとも１つのプロセッサ；および
前記少なくとも１つのプロセッサに動作可能に接続され、命令を格納したメモリ
を備えるシステムであって、
前記命令は、前記少なくとも１つのプロセッサにより実行された場合、
第１の顧客のためにプロバイダネットワーク内の第１のネットワークエッジサイトにおいて第１のネットワークエレメントを構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する手順、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する手順、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む；
リファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する手順；
前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからの第１のメトリックのインスタンスをメトリックストレージシステムに格納する手順；
第２の顧客のために第２のネットワークエレメントを構成するよう前記プロバイダネットワーク内のネットワークエッジサイトに推奨するための要求を第２のクライアントデバイスから受信する手順、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスおよび第２のワークロードのうちの少なくとも一方を含み、推奨するための前記要求は、コンポーネント情報および最適化基準を含む；
前記コンポーネント情報および前記最適化基準に基づいて関連メトリックを決定する手順；
前記関連メトリックについて前記メトリックストレージシステムをクエリする手順；
前記関連メトリックの前記インスタンスを受信する手順；
前記関連メトリックの前記インスタンスを用いて、前記第２のネットワークエレメントの少なくとも第２のネットワークエッジサイトの推奨を生成する手順；および
前記推奨を前記第２のクライアントデバイスに提供する手順
を含む方法を前記システムに実行させる、
システム。

【請求項17】

前記関連メトリックは、前記第１のメトリックのうちの少なくともいくつかを含む、請求項１６に記載のシステム。

【請求項18】

前記関連メトリックを決定する手順は、前記コンポーネント情報を前記第１のネットワークエレメントについての情報と比較し、前記コンポーネント情報が前記第１のネットワークエレメントについての前記情報の少なくとも一部と一致している場合、前記関連メトリックは前記第１のメトリックのうちの少なくともいくつかを含んでいる、と判断する手順を有する、請求項１６または１７に記載のシステム。

【請求項19】

前記方法は、
前記第１のキャプチャコンポーネントをキャプチャコンポーネントレポジトリに格納する手順；
前記第２の顧客のために前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成するための第２の要求を前記ネットワークユーティリティにおいて前記第２のクライアントデバイスから受信する手順；
前記ネットワークユーティリティが前記第２のネットワークエレメントの第２の構成ファイルを送信する手順、ここで、前記第２の構成ファイルは、メトリック収集の第２のキャプチャテンプレートを含む；および
リファクタリングされた第２のキャプチャテンプレートを含む第２のキャプチャコンポーネントを含む前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成する手順
をさらに含む、
請求項１６から１８のいずれか一項に記載のシステム。

【請求項20】

前記方法は、
前記第２の要求の受信に応答して、前記第２のネットワークエレメントは前記第１のネットワークエレメントと同様のタイプのものである、と判断する手順
をさらに含み、
前記第２の構成ファイルを送信する手順は、前記第１のキャプチャテンプレートに基づいて前記第２のキャプチャテンプレートを生成する手順を有する、
請求項１９に記載のシステム。

【発明の詳細な説明】

【背景技術】

【0001】

［関連出願］
本願は、２０２０年１２月３１日に出願された、「エッジコンピューティングの最良のノードを決定するためのシステム」と題する米国仮特許出願第６３／１３２，６１１号、２０２１年９月１６日に出願された、「コードプラットフォームとしてのオブジェクト指向インフラストラクチャ（ＯＯＩＡＣＰ）」と題する米国特許出願第１７／４７６，７０８号、２０２１年１月１９日に出願された、「コードプラットフォームとしてのオブジェクト指向インフラストラクチャ（ＯＯＩＡＣＰ）」と題する米国仮特許出願第６３／１３８，９１９号の利益を主張する。これらの出願の全ては、参照により、教示の全てについて、その全体が組み込まれる。適切である限りにおいて、上で説明された出願の各々につき、優先権の主張が行われる。

【0002】

コンピューティングネットワークはますます、大型かつ複雑になっている。コンピューティングネットワークの顧客は、様々な要因に基づいて、コンピューティングネットワーク内の異なる場所における特定のネットワークエレメント（ネットワークデバイスまたはワークロードなど）のインスタンス化を所望し得る。特定のコンポーネントをインスタンス化するためのネットワーク内の最適な位置を決定するには、ネットワーク性能の知識が必要となり得る。これは、本願の態様が関連するこの一般的な環境に関するものである。

【発明の概要】

【0003】

この概要は、以下の発明を実施するための形態においてさらに説明される概念の一部を、簡略化した形態で紹介するために提供される。この発明の概要は、特許請求される主題の重要な特徴または必須の特徴を識別することを意図されておらず、特許請求される主題の範囲を限定するために用いられることも意図されていない。

【0004】

本願の態様は、方法を含み、前記方法は、第１の顧客のためにネットワークエレメントを第１のネットワークエッジサイトにおいて構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む、を備える。前記方法は、前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する段階、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む、により続く。前記方法は、リファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する段階、および前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからメトリックのインスタンスをメトリックストレージシステムにおいて受信する段階をさらに備える。さらに、前記方法は、前記メトリックの要求を前記メトリックストレージシステムにおいて受信する段階；および前記メトリックの前記インスタンスを提供する段階を備え得る。

【0005】

他の態様において、本願は、別の方法を説明し、別の方法は、第１の顧客のために第１のネットワークエレメントを構成するようプロバイダネットワーク内のネットワークエッジサイトに推奨するための第１の要求を第１のクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含み、前記要求は、第１のコンポーネント情報および第１の最適化基準を含む、を備える。前記方法は、前記第１のコンポーネント情報および前記第１の最適化基準に基づいて第１の関連メトリックを決定する段階、および前記第１の関連メトリックについてメトリックストレージシステムをクエリする段階、ここで、前記メトリックストレージシステムは、前記プロバイダネットワーク上で動作する他のネットワークエレメントからの前記第１の関連メトリックのインスタンスを格納する、を続ける。前記方法は、前記第１の関連メトリックの前記インスタンスを受信する段階、前記第１の関連メトリックの前記インスタンスを用いて、前記第１のネットワークエレメントの少なくとも第１のネットワークエッジサイトの推奨を生成する段階、および前記推奨を前記第１のクライアントデバイスに提供する段階により続く。

【0006】

別の態様において、本願は、少なくとも１つのプロセッサ；および前記少なくとも１つのプロセッサに動作可能に接続され、命令を格納したメモリを備えるシステムであって、前記命令は、前記少なくとも１つのプロセッサにより実行された場合、方法を前記システムに実行させる、システムを開示する。態様において、前記方法は、第１の顧客のためにネットワークエレメントをプロバイダネットワーク内の第１のネットワークエッジサイトにおいて構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する手順、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む、を備える。前記方法は、前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する手順、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む、およびリファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する手順をさらに含む。さらに、前記方法は、前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからの第１のメトリックのインスタンスをメトリックストレージシステムに格納する手順、および第２の顧客のために第２のネットワークエレメントを構成するよう前記プロバイダネットワーク内のネットワークエッジサイトに推奨するための要求を第２のクライアントデバイスから受信する手順、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスおよび第２のワークロードのうちの少なくとも一方を含み、推奨するための前記要求は、コンポーネント情報および最適化基準を含む、を備え得る。前記方法は、前記コンポーネント情報および前記最適化基準に基づいて関連メトリックを決定する手順、前記関連メトリックについて前記メトリックストレージシステムをクエリする手順、および前記関連メトリックの前記インスタンスを受信する手順をさらに含む。前記方法は、前記関連メトリックの前記インスタンスを用いて、前記第２のネットワークエレメントの少なくとも第２のネットワークエッジサイトの推奨を生成する手順；および前記推奨を前記第２のクライアントデバイスに提供する手順も含み得る。

【図面の簡単な説明】

【0007】

以下の図を参照して、非限定的かつ非網羅的な例を説明する。

【0008】

【図1】本願の態様による例示的なシステムを示す。

【0009】

【図2】本願の態様による別の例示的なシステムを示す。

【0010】

【図3】本願の態様による例示的な方法を示す。

【0011】

【図4】本願の態様による別の例示的な方法を示す。

【0012】

【図5】本願の態様と共に用いられ得る例示的なコンピューティング環境を示す。

【発明を実施するための形態】

【0013】

例において、本願は、メトリックキャプチャのためのシステムおよび方法、およびコンピューティングネットワークにおける使用を説明する。例において、ネットワークエレメント（ネットワークデバイスおよびワークロードなど）をネットワークにプロビジョニングするプロセスの一部としてネットワークエレメントがメトリック収集のために搭載されることを可能にするためのシステムおよび方法が提供される。例において、ネットワークエレメントに関連付けられたメトリックを収集するための収集コンポーネントを生成するために用いられ得る収集テンプレートが、顧客に提供される。例において、収集されたメトリックは、エッジ推奨システムにより、ネットワークエレメントが最適化基準に従って配置されるべき１つまたは複数の推奨されるエッジサイトを決定するために格納および使用され得る。

【0014】

図１における例示的なシステム１００を参照すると、ネットワークユーティリティ１０２が提供される。例において、ネットワークユーティリティ１０２は、ネットワークマーケットプレイス１０４およびコンポーネントのインターネットファクトリ１０６を含む。ネットワークマーケットプレイス１０４は、顧客がプロバイダネットワーク１０８からのサービスを発見および注文することを可能にするためのシステムを含み得る。例において、顧客は、エッジサイト（エッジノードとも称される）においてネットワークエレメントをプロビジョニングすべく、ネットワークユーティリティ１０２にアクセスし得る。例えば、クライアントデバイス１１０は、ネットワークエレメント（ネットワークデバイス１１２またはワークロード１１４など）を顧客による使用のためにプロバイダネットワーク１０８のエッジサイト１１６上に展開するために用いられ得る。

【0015】

例えば、プロバイダネットワーク１０８は、ルータ、スイッチ、ゲートウェイデバイス、データストレージデバイス、サーバおよび他のコンピューティングデバイスを含み得る。例において、プロバイダネットワーク１０８は、プロバイダネットワーク１０８の顧客による使用のためのコンピューティング能力を提供し得る複数のエッジサイト１１６、１２６も含み得る。２つのエッジサイトが示されているが、任意の数のプロバイダサイトが提供され得る。例において、エッジサイト１１６、１２６は、プロバイダネットワーク１０８のエッジに位置し、またはこのエッジに近い。例えば、プロバイダサイト１１６、１２６は各々、例えばクライアントデバイス１１０および１２０が存在し得る顧客サイトからの通信のためのプロバイダネットワーク１０８への入口ポイントとして動作する少なくとも１つのプロバイダエッジルータを含み得る。顧客サイトは、様々な顧客のために、地理的に分散され得る。加えて、単一の顧客は、複数の地理的に分散された顧客サイトを有し得る。エッジサイト１１６、１２６は、エッジサイト１１６、１２６がコンピューティングサービスをホストすることを可能にするためのコンピューティング能力（例えば、サーバ）およびデータストレージも含み得る。エッジサイト１１６、１２６は、プライベートネットワーク、パブリックネットワーク、および／またはパブリックおよびプライベートネットワークのハイブリッドを含む様々な他のネットワークまたは通信リンクを通じて、顧客サイトに動作可能に接続され得る。例において、プロバイダネットワーク１０８のエッジに、またはこのエッジの近くにエッジサイト１１６、１２６を有することで、特に、エッジサイトが、そのプロバイダサイトへのアクセスに必要な当該プロバイダサイトの顧客サイトへの近接度に基づいて部分的に選択される場合、顧客サイトは、（とりわけ）レイテンシを最小化することが可能になる。加えて、エッジサイト１１６、１２６は、一様でなくてよく、例えば、コンピューティング能力、セキュリティ証明、拡張能力、データストレージ可用性、ネットワーク接続タイプ（例えば、パブリックインターネット、プライベートネットワーキング、パブリック／プライベートのハイブリッド）等が異なっていてよい。それに応じて、顧客サイトによるアクセスのためにホストされる特定のネットワークエレメント（例えば、ネットワークデバイスまたはワークロード）についてのエッジサイト１１６、１２６の選択は、様々な要因に基づいて最適化され得る。

【0016】

例において、クライアントデバイス１１０は、ネットワークマーケットプレイス１０４にアクセスし、エッジサイト１１６におけるネットワークデバイス１１２および／またはワークロード１１４のプロビジョニングを第１の顧客が（例えば、クライアントデバイス１１０を用いて）所望していることを示し得る。エッジサイト１１６は、例えば、図２に関連して以下で論じられるエッジサイト推奨システムを第１の顧客が用いることにより、選択され得る。ネットワークマーケットプレイス１０４は、とりわけ、ネットワークエレメントのネットワークリソースを確保し得る。例えば、ネットワークマーケットプレイス１０４（またはネットワークユーティリティ１０２の別のエレメント）は、ネットワークデバイスのプロビジョニング、１つまたは複数のＩＰアドレスの確保、仮想ローカルエリアネットワーク（ＶＬＡＮ）の割り当て等を行い得る。また、ネットワークマーケットプレイス１０４は、ネットワークエレメントを構成するようクライアントデバイス１１０をＩｏＣファクトリ１０６へリダイレクトし得る。

【0017】

ＩｏＣファクトリは、ネットワークユーティリティ１０２内のプログラミング環境におけるオブジェクト、機能または方法であってよい。ＩｏＣファクトリ１０６は、ライフサイクルへ標準化されてＩａＣ（コードとしてのインフラストラクチャ）コンポーネントインフラストラクチャおよび／またはそのワークロードを大規模に動作させ得る周知のパターンおよび基礎となる自動化の「ＡＰＩファースト」実装を提供し得る。これは、Ｍｏｒｐｈｅｕｓ（Ｍｏｒｐｈｅｕｓ Ｄａｔａ， ＬＬＣから入手可能）など、既製のセルフサービスクラウド管理プラットフォームシステムと相補的なものであってよい。

【0018】

ＩｏＣファクトリ１０６は、ネットワークマーケットプレイス１０４の背後のＡＰＩプロビジョニングサーバとして機能してよく、ネットワークマーケットプレイス１０４では、「製品」が、十分に定義され、複数のユースケースにおける進行中のカスタムプロビジョニングのために押しボタン自動化を大規模に提供する。ＩｏＣファクトリ１０６は、ヒエラルキーが製品スイート（すなわち、ドメイン）、製品（すなわち、提供品）および製品オプション（すなわち、提供品のカスタマイズ）であるマーケットプレイスメタファーを使用し得る。例において、ＩｏＣファクトリは、ネットワークエレメントをプロビジョニングしつつ、メトリック収集に必要なＡＰＩをプロビジョニングすることにより、ネットワークエレメントがＩｏＣファクトリからライフサイクル設定される場合にメトリック収集用に自動的に搭載されることを可能にし得る。ＩｏＣファクトリ１０６の例は、米国特許出願第１７／４７６，７０８号において説明されており、当該特許出願は、参照により、その教示の全てが本明細書に組み込まれる。

【0019】

例えば、ネットワークユーティリティは、ネットワークマーケットプレイス１０４からの特定のネットワークエレメントの選択をクライアント１１０から受信し得る。ＩｏＣファクトリは、１つまたは複数のキャプチャテンプレートをキャプチャコンポーネントレポジトリ１１８から選択するように構成され得る。例において、キャプチャコンポーネントレポジトリ１１８内のキャプチャテンプレートは、デフォルトテンプレート（例えば、全てのランナブル）を含んでよく、または、ネットワークマーケットプレイス１０４から選択される特定のタイプのネットワークエレメントのために以前にリファクタリングおよび／または使用されたテンプレートであってよい。

【0020】

一例において、ネットワークユーティリティ１０２は、エッジサイト１１６におけるネットワークデバイス１１２へプロビジョニングされる、第１の顧客が望んでいるネットワークマーケットプレイス１０４からの特定のワークロード１１４（例えば、アプリケーション）の選択をクライアント１１０から受信する。ＩｏＣファクトリ１０６は、そのタイプのワークロード１１４用にカスタマイズされたキャプチャコンポーネントレポジトリ１１８からのデフォルトキャプチャテンプレートおよび／またはキャプチャテンプレートをクライアントに提供し得る。ＩｏＣファクトリ１０６は、キャプチャテンプレートをクライアントデバイス１１０に提供し得る。

【0021】

例において、クライアントデバイス１１０は次に、キャプチャテンプレートをリファクタリングして、ワークロード１１４に関連付けられたキャプチャコンポーネントによりキャプチャされるメトリックをカスタマイズするために用いられ得る。例えば、キャプチャテンプレートは、コマンドラインランナーおよび搭載テンプレートを含み得る。ＲＥＳＴ－ｆｕｌ作成、取得、更新、削除、リストおよびバルク書き込み（ＣＲＵＤＬＢ）ＡＰＩの例示的なキャプチャテンプレートからの引用が、以下に示される。

【数1】

【数2】

【数3】

【数4】

【数5】

【数6】

【0022】

キャプチャテンプレートは、特定の所望のメトリックキャプチャについて、（例えば、クライアントデバイス１１０により）リファクタリングされてよく、リファクタリングされたテンプレート（ここでは、キャプチャコンポーネント）は、（例えば、コマンドラインインタフェース内のｆａｔ ｗａｒまたはｆａｔ ｊａｒとして、または別様で）ワークロード１１４と共に展開されてよい。キャプチャコンポーネントがメトリックをキャプチャする頻度も、例えば、以下に非排他的に示される頻度基準または時刻基準によりカスタマイズされ得る。

【数7】

【0023】

さらに、顧客は、特定のメトリック、キャプチャコンポーネントを用いてキャプチャされるメトリックのアクセス制御を詳述し得る。いくつかの例において、メトリックは、それらを要求する任意のクライアントプロセスにとって利用可能であってよい。他の例において、（一度キャプチャされた）メトリックにアクセスし得るのは、（例えば、役割ベースのアクセス制御（ＲＢＡＣ）を用いて、または別様で）そのようにする許可を有するクライアントプロセスのみである。いくつかの例において、特定のメトリックは、以下で説明されるエッジ推奨システムのような少なくとも特定のクライアントプロセスへアクセス可能であることをプロバイダネットワーク１０８により強制的に要求され得る。他の例において、特定のメトリックは、プライベートに保持されてよく、キャプチャコンポーネントがプロビジョニングされるネットワークエレメントをプロビジョニングする顧客に対してのみアクセス可能であってよい。例において、キャプチャされたメトリックは、任意のメトリック消費プロセスまたはシステムにとって利用可能になる前に匿名化され得る。

【0024】

加えて、構成毎に、各ランナブルは、組み込まれたメトリックキャプチャを有しており、レイテンシおよび／または将来開発される他の定義メトリックを測定すべく、環境変数毎に範囲を設定して他のランナブル（「回路」）との間のキャプチャメトリック交換を定義し得る。「パブリック」が定義される場合、メトリックは、ドメインにおける全ての他の「パブリックな」構成されたランナブルと共に、（ＲＥＳＴコールの＄ＢＯＤＹにおいて指定され、かつ、例えばグローバルロードバランサの作用を受けるように）経験的に収集されるので、「閉回路」を表す。パブリックとして単にインスタンス化することにより、それらは、公衆回線における全てのメトリック（例えば、レイテンシ）のメトリック収集に自動的に関与することになる。代替的に、各ランナブルは、閉回路内にあることを自己が望んでいるランナブルを表すシリアル番号のセットを代わりに指定し得る。

【0025】

パブリック構成において、各ランナブルは、結果としてデータベースコマンドラインインタフェース（シリアル番号の後に名前が付される）を用いるＣＲＵＤＬＢ ＲＥＳＴ ＡＰＩ内のＣＲＥＡＴＥを単に呼び出すことにより、その選択されたターゲットドメインにおいてメトリックデータベース（以下で論じられる）を自動的にインスタンス化し、データベースコマンドラインインタフェースは、全ての他のランナブルと共に上記メトリックを閉回路に記録する。同様に、ピアランナブルは、非パブリックについて同じことを行う。メトリックプレゼンテーションのために後にクエリされる場合において、依然として閉鎖されている回路を用いて回路内の全てのランナブルが依然として構成されているときは、メトリックデータは返される。そうでない場合、メトリックデータは、返されない。最終的に、閉回路を容易にすべく、ランナブルデータグリフは、インターネット制御メッセージプロトコル（ＩＣＭＰ）を介してレイテンシメトリックを収集するために回路内の他のランナブルによりデコードされ得るＩＰアドレスおよびポートを内部に有する。

【0026】

例において、ネットワークユーティリティ１０２は、他のクライアントがプロバイダネットワーク１０８内の異なるエッジサイトにおける追加のネットワークエレメントをプロビジョニングおよび構成することを可能にするように動作し得る。例えば、クライアントデバイス１２０も、ネットワークユーティリティ１０２を用いて、エッジサイト１２６におけるネットワークデバイス１２４上の異なるワークロード１２２をプロビジョニングし得る。例において、ワークロード１２２がワークロード１１４とは異なるタイプのものである場合、ネットワークユーティリティ１０２によりクライアントデバイス１２０へ返されるキャプチャテンプレートは、ネットワークユーティリティ１０２によりクライアントデバイス１１０へ返されるキャプチャテンプレートとは異なり得る。例えば、ワークロード１２２は、ワークロード１１４とは異なるアプリケーションであってよく、ワークロード１２２と同様のタイプのアプリケーションのキャプチャテンプレートは、キャプチャコンポーネントレポジトリ１１８内で以前にカスタマイズおよび格納されていてよい。それに応じて、そのワークロード１２２の適切なテンプレートが取得され、クライアントデバイス１２０へ返され得る。他の例において、デフォルトキャプチャテンプレートは、特定のタイプのワークロードのキャプチャテンプレートの代わりに、またはこのキャプチャテンプレートに加え、返される。

【0027】

いくつかの例において、プロビジョニングされているネットワークエレメントは、ワークロードではなく、インフラストラクチャコンポーネントであってよい。例えば、顧客（例えば、クライアントデバイス１２０を用いる第２の顧客）が新しいサーバ（例えば、ネットワークデバイス１２４）のプロビジョニングを所望しているというインジケーションをネットワークユーティリティ１０２が受信した場合、ネットワークユーティリティ１０２は、キャプチャエージェントテンプレートをレポジトリ１１８からクライアントデバイス１２０へ返し得る。キャプチャエージェントは、（ワークロード１２２などのワークロードに埋め込まれるのとは反対に）スタンドアロンエージェントとして動作し得る。次に、キャプチャエージェントテンプレートも、ネットワークデバイス１２４を用いてプロビジョニング／構成されるキャプチャコンポーネントを作成するために、（例えば、クライアントデバイス１２０により）リファクタリング／カスタマイズされ得る。

【0028】

例において、キャプチャテンプレートは、構成ファイルの一部として、ネットワークユーティリティ１０２によりクライアントデバイス（例えば、クライアントデバイス１２０）へ返され得る。本明細書において用いられる構成ファイルは、プロバイダネットワーク１０８のエッジサイト（例えば、エッジサイト１２６）上でネットワークエレメント（例えば、ワークロード１２２またはネットワークデバイス１２４）をプロビジョニングすべくクライアントデバイスにより用いられ得る１つまたは複数のプロビジョニングテンプレートとして、広く定義される。例において、キャプチャテンプレートをネットワークエレメントのプロビジョニングプロセスに含めることにより、メトリックキャプチャが、全てのネットワークエレメントのプロビジョニングに自動的に（かつデフォルトとして）含まれる。これにより、一貫性が促進されると共に、ワークロードメンテナンスと同期する別個のメトリック収集システムを保持する必要性が排除される（メトリック収集はワークロードの一部なので）。キャプチャテンプレートがＩｏＣファクトリ１０６により取得されるような特定の例が本明細書において論じられているが、ＩｏＣファクトリを用いることなくキャプチャコンポーネントレポジトリ１１８をクライアントデバイス１１０、１２０に対して利用可能にするのも可能であることにも留意されたい。

【0029】

さらに、いくつかの例において、１つまたは複数のキャプチャコンポーネントが、クライアントデバイス（例えば、クライアントデバイス１１０、１２０、またはワークロード１１４、１２２にアクセスする他のクライアントデバイス、および／またはネットワークデバイス１１２、１２４）上に実装され得る。例えば、いくつかの例において、メトリックは、顧客の自社内の機械にキャプチャされることを所望され得る。本明細書において説明されるように搭載されるキャプチャコンポーネントも、そのようなクライアントデバイス、およびエッジサイト１１６、１２６上で動作するデバイスに展開され得る。さらに、エッジコンピューティングシステム内の例が本明細書において説明されるが、本明細書において説明されるメトリックキャプチャシステムの例は、任意のコンピューティングネットワーク内で用いられ得る。

【0030】

図２は、エッジコンピューティング環境におけるメトリックを収集および提示するための例示的なシステム２００を示す。例において、クライアントデバイス２１０、２１２にはそれぞれ、例えば、システム１００に関して上で説明されたシステムおよび方法を用いて、キャプチャコンポーネント２１４、２１６が搭載されている。例において、クライアントデバイス２１０は、エッジコンピューティングサイト２１８上のワークロードと協働するクライアントワークロードを実行し得る。例えば、エッジサイト２１８は、図１のエッジサイト１１６であってよく、エッジサイト２１８は、ワークロード１１４を動作させるネットワークデバイス１１２を含み得る。一例において、エッジサイト２１８におけるネットワークデバイス１１２およびワークロード１１４には、上で説明されるように、キャプチャコンポーネント２２０が搭載され得る。同様に、エッジサイト２２２は、図１のエッジサイト１２６を含んでよく、キャプチャコンポーネント２２４が搭載されたネットワークデバイス１２４およびワークロード１２２を含んでよい。

【0031】

上で論じたように、キャプチャコンポーネント２１４、２１６、２２０および２２４は、メトリックのインスタンスをメトリックストレージシステム２２６へ伝送するために搭載され得る。メトリックストレージシステム２２６は、メトリックプレゼンテーションエンジン２３０に面した１つまたは複数のＡＰＩ２２８を備え得る。メトリックストレージシステム２２６は、複数のメトリックデータベース（またはデータベースクラスタ）２３２、２３４も備え得る。加えて、メトリックストレージシステム２２６に格納されたメトリックへのアクセスは、メトリックアクセス制御システム２３６により部分的に制御され得る。

【0032】

例において、メトリックストレージシステム２２６は、エッジ推奨システム２４０など、１つまたは複数のクライアントプロセスに対し、メトリックを利用可能にし得る。エッジ推奨システムは、例えば、プロバイダネットワーク１０８によりホストされてよく、顧客がネットワークエレメントを展開すべき特定のエッジサイトの推奨を提供するために用いられてよい。例において、エッジ推奨システム２４０は、クライアントデバイス２４２により、１つまたは複数のネットワーク接続を介してアクセスされ得る。

【0033】

例において、プロバイダネットワーク１０８などのプロバイダネットワークの顧客（または潜在的な顧客）がプロバイダネットワーク１０８内のネットワークエレメントのプロビジョニングに関心を有している場合、エッジ推奨システム２４０は、ネットワークエレメントのための推奨されるエッジサイトを（例えば、メトリックの収集されたインスタンスに基づいて）決定するために使用され得る。例において、この推奨は、クライアントデバイス２４２での表示のためにエッジ推奨システム２４０により提供されるユーザインタフェースを通じて顧客により選択、重み付けおよび／またはランク付けされ得る様々な最適化基準に基づき得る。加えて、エッジ推奨システム２４２はまた、顧客がプロバイダネットワーク１０８へのプロビジョニングに関心を有しているネットワークエレメントを記述したコンポーネント情報を（例えば、クライアントデバイス２４２上のユーザインタフェースを通じて）受信し得る。

【0034】

例えば、エッジ推奨システム２４２は、実行されるソフトウェアアプリケーションのタイプ、データストレージ要件、オペレーティングシステム、ネットワーク接続（例えば、パブリックインターネット、プライベートネットワーキング、ハイブリッド等）、セキュリティ要件（例えば、必要とされる特定のセキュリティであり、決済カード業界（ＰＣＩ）セキュリティ証明などである）、レイテンシ要件（例えば、最大平均レイテンシ）、到達の必要があるインターネットプロトコル（ＩＰ）アドレスおよび／または宛先／エンティティ、サービスとの間で送信されるデータトラフィックのタイプ（例えば、音声、ビデオ）およびネットワークエレメントにアクセスすることになる顧客サイトの物理位置等、コンポーネント情報を受信し得る。

【0035】

また、エッジ推奨システム２４０は、例えば、性能、信頼性（例えば、アップタイム）、特定のネットワークエレメント間の平均レイテンシ、コスト、セキュリティ格付け等、最適化基準を受信し得る。例えば、最適化基準の予め定められたセットが、ユーザインタフェースを通じてクライアントデバイス２４２に提示されてよく、ユーザは、最適化基準を重要度に関してランク付けおよび／または重み付けするための機会を提供されてよい。他の例において、最適化基準の標準セットが用いられてよく、または、ホストされるネットワークエレメントのタイプに固有の最適化基準が用いられてよい。

【0036】

次に、エッジ推奨システム２４０は、エッジサイトの推奨に関連するメトリックを決定し得る。例えば、エッジサイト推奨システム２４０は、顧客に供給されるコンポーネント情報および最適化基準を調査して、プロバイダネットワーク１０８によりキャプチャされるどのメトリックがネットワークエレメントの最適なエッジサイトの決定に最も関連しているかを判断し得る。例において、エッジ推奨システム２４０は、コンポーネント情報（例えば、同じまたは同様のタイプのワークロード、同様のデータ伝送プロファイル、同じまたは同様のタイプのデバイスまたはデバイス特性等）により記述されるネットワークエレメントと同様のネットワークエレメントに関連付けられたキャプチャエージェントからキャプチャされるメトリックを決定し得る。また、エッジ推奨システム２４０は、ネットワークエレメントにアクセスし、以前に収集されたどのメトリックが推定レイテンシの決定に最も関連しているかの判断においてその情報を用いる顧客サイトの位置をコンポーネント情報から決定し得る。最適化基準は、関連メトリックの決定においても用いられ得る。例えば、顧客がコストおよびレイテンシの最適化を望んでいるがセキュリティを省略していることを最適化基準が示している場合、関連メトリックは、推定コストおよびレイテンシを決定するために必要とされるもののみを含み得る。

【0037】

ネットワーク内で既に動作しているキャプチャコンポーネント（例えば、２１４、２１６、２２０、２２４）は、関連メトリックを収集するために搭載され得る。例えば、最適化基準が特定のネットワークエレメント間の平均レイテンシである場合、関連ネットワークエレメントにおけるレイテンシ情報をキャプチャし、それらのメトリックのインスタンスをメトリックストレージシステム２２６へ伝送するために、キャプチャコンポーネントが搭載され得る。次に、エッジ推奨システム２４０は、データベースクラスタ２３２および／または２３４に格納された関連メトリックのインスタンスについてメトリックストレージシステムを（例えば、ＡＰＩ２２８および／またはメトリックプレゼンテーションエンジン２３０を通じて）クエリして、特定のネットワークエレメントに推奨するための１つまたは複数の最適化されたエッジサイトを決定できる。

【0038】

例において、推奨プロセスの結果は、例えば顧客により最適化基準が選択および／または重み付け／ランク付けされるようにランク付けおよび／または重み付けされた最適化基準に従って順序付けられたエッジサイト候補のリストとして返され得る。いくつかの例において、エッジ推奨システム２４０は、スコアリングマトリクスを使用して、ランク付けおよび／または重み付けされた最適化基準（および対応するメトリック）に基づきエッジサイト候補をスコア付けし得る。エッジサイト候補のリストは、ネットワークエレメントをホストするエッジサイトの選択のために、ユーザに提示され得る。エッジサイト候補のリストは、例えば、エッジサイト候補の各々に関連付けられた推定コスト、性能、信頼性、セキュリティ格付け、平均レイテンシ等をユーザが選択すべきエッジサイトの決定に際して閲覧できるように、最適化基準のいくつかまたは全ての基礎となるメトリックと共に提示され得る。例において、エッジサイト候補のリストはまた、とりわけ、最適化基準のいずれかでユーザによりソート可能であってよい。例えば、エッジサイト候補のリストは、まず、コストの昇順で提示され得るが、次に、推定レイテンシの昇順で順序付けられるようにユーザによりソートされ得る。他の例において、エッジサイト候補のリストは、（例えば、クライアントデバイス２４２をネットワークユーティリティ１０２へ導くことにより）ネットワークエレメントが特定のエッジサイトへプロビジョニングされるようにするために用いられ得る。

【0039】

さらに、論じられるように、顧客は、特定のメトリック、キャプチャコンポーネント２１４、２１６、２２０、２２４を用いてキャプチャされるメトリックのインスタンスのアクセス制御を詳述し得る。いくつかの例において、メトリックの格納されたインスタンスは、それらを要求する任意のクライアントプロセスにとって利用可能であってよい。他の例において、（一度キャプチャされた）メトリックのインスタンスにアクセスし得るのは、（例えば、役割ベースのアクセス制御（ＲＢＡＣ）を用いて、または別様で）そのようにする許可を有するクライアントプロセスのみである。メトリックの格納されたインスタンスへのアクセスは、例えばメトリックアクセス制御システム２３６により制御され得る。例えば、クライアントプロセス（エッジ推奨システム２４０など）からのメトリックの要求は、そのような要求をしているプロセスがメトリックの要求されたインスタンスを閲覧するための必要な許可を有しているかどうかを判断するために調査され得る。いくつかの例において、特定のメトリックは、エッジ推奨システム２４０のような少なくとも特定のクライアントプロセスへアクセス可能であることをプロバイダネットワーク１０８により強制的に要求され得る。他の例において、特定のメトリックは、プライベートに保持されてよく、キャプチャコンポーネントがプロビジョニングされるネットワークエレメントをプロビジョニングする顧客に対してのみアクセス可能であってよい。他の許可スキーマが可能である。

【0040】

いくつかの例において、メトリックの格納されたインスタンスに基づいて１つまたは複数の推奨されるエッジサイトを決定するために、メトリックプレゼンテーションエンジン２３０および／またはエッジ推奨システム２４０によりアルゴリズムが実行され得る。例えば、１つの最適化基準は、コストであってよい。キャプチャコンポーネント２２０および２２４は、コスト（例えば、様々なネットワークサービスのためにエッジサイト２１８および２２２をそれぞれ用いている顧客に現在課金されている価格）に関連付けられたメトリックをキャプチャするために搭載され得る。エッジ推奨システム２４０および／またはメトリックプレゼンテーションエンジン２３０に実装されたアルゴリズムは、未処理のメトリックのインスタンスを取得し、それらを、エッジサイト２１８および２２２のうちの１つまたは複数において特定のネットワークエレメントがプロビジョニングされるはずであると予想され得るコストに相関付け得る。例において、このアルゴリズムは、例えば、ポーリングアルゴリズム、入札アルゴリズム、サンプリングアルゴリズム、機械学習アルゴリズム、ナッシュ均衡入札アルゴリズム等、様々な形態を取り得る。いくつかの例示的なアルゴリズムの詳細を以下で説明する。

【0041】

例において、エッジ推奨システム２４０は、受信したコンポーネント情報および最適化基準を用いて、メトリックストレージシステム２２６から要求するための関連メトリックを決定し得る。例えば、洗練されたエッジ推奨システムは、（クライアント２４２から受信されるコンポーネント情報において記述されるように）プロビジョニングされるネットワークエレメントおよびそこからメトリックが収集されてメトリックストレージシステム２２６に格納されたネットワークエレメントの記述間でパターンマッチングできてよい。

【0042】

例えば、メトリックストレージシステム２２６に格納されたメトリックのインスタンスは、導出元であるネットワークエレメントのインジケーションで格納され得る。例えば、特定のタイプのワークロード（アプリケーション）に関連付けられた各キャプチャコンポーネント（例えば、２２０、２２４）が、そのタイプのワークロードに固有のデータベース（例えば、２３２、２３４）へ収集されたメトリックのインスタンスを送信するために搭載され得る。そのため、そのタイプのワークロードをホストする特定のエッジサイトを推奨するための要求をエッジ推奨システム２４０が受信した場合、エッジ推奨システム２４０は、メトリックストレージシステム２２６からのそのタイプのワークロードに関連付けられたメトリックを要求し得る。

【0043】

要求するための関連メトリックのより複雑な判断も可能である。例えば、メトリックストレージシステム２２６は、ワークロード、ワークロードタイプ、データ転送プロファイル、ハードウェアシステム、オペレーティングシステム、利用可能な帯域幅、サーバ負荷についての情報、および、そこからメトリックインスタンスがキャプチャされてメトリックストレージシステム２２６に格納されるシステムに関連する任意の他の環境データを格納／インデックスし得る。次に、そのような情報は、例えばエッジ推奨システム２４０により、新しいネットワークエレメントの提案されたプロビジョニングとの関連性が最も高いメトリックを要求するために用いられ得る。

【0044】

そのため、ネットワークエレメントをホストするためのエッジサイトの推奨を（例えば、１つまたは複数のクライアントデバイス２４２を用いる）２つの異なる顧客が要求し、かつ、異なるコンポーネント情報を提供する場合、エッジ推奨システム２４０により決定されてエッジストレージシステム２２６から要求される関連メトリックは、別個であってよい。さらに、非常に類似したコンポーネント情報を２つの異なる顧客が提供する場合でも、異なる顧客が異なる最適化基準を提供し得る。例えば、１つの顧客がレイテンシの重要度に大いに重み付けし得るが、別の顧客は、コストの重要度に大いに重み付けし得る。それに応じて、メトリックストレージシステム２２６から決定および要求される関連メトリックが同じであっても、異なっていても、エッジ推奨システム２４０は、異なるエッジサイトを異なる顧客に推奨し得る（または、推奨される候補エッジサイトを異なるようにランク付けし得る）。

【0045】

例において、エッジ推奨システム２４０により特定のエッジサイトが推奨された後、（例えば、クライアントデバイス２４２を用いる）顧客は、特定のサイトを選択し得る。次に、クライアントデバイス２４２は、ネットワークユーティリティ１０２へ導かれてよく、ネットワークエレメントは、説明されるようにプロビジョニングされてよい（かつ、メトリック収集のために搭載されてよい）。

【0046】

例において、図１および２のシステム１００および２００は共に、ネットワークエレメントにキャプチャコンポーネントを搭載し、キャプチャコンポーネント（例えば、２２０、２２４）を用いてメトリックを収集し、次に使用のためのメトリックを提示するメトリックエコシステムを表し得る。顧客がネットワークエレメントをエッジサイトへ展開している一例において本願のメトリック搭載、キャプチャおよびプレゼンテーションシステムが論じられているが、メトリック搭載、キャプチャおよびプレゼンテーションシステムの使用は、そのようには限定されない。

【0047】

本明細書において説明されるメトリックエコシステムの例は、ＡＰＩ、エージェントおよびアルゴリズムという３つのアーティファクトタイプを含み得る。このことは、メトリックの状態収集、ライフサイクルおよびプレゼンテーションのためのメトリックストレージメカニズムと相まって、ネットワーク顧客がメトリックキャプチャをそれぞれのアプリケーションへシームレスに統合することを可能にする。

【0048】

アプリケーションのＡＰＩ（および場合によっては他のコンポーネント）の設計パターンは、メトリックアクセス制御システム２３６の対象になるデータベース内のＣＲＵＤＬＢ（作成、取得、更新、削除、リスト、バルク書き込み）ＲＥＳＴ－ｆｕｌインタフェースを用いるメトリックストレージシステム２２６へ戻るイベントメトリックに搭載され得る。この構成は、プロバイダネットワーク１０８内の全てのテナントアプリケーションについてデフォルトかつ自動的である。ＡＰＩまたはアプリケーションランナブルを超えてメトリックのキャプチャが必要である場合（例えば、プロビジョニング／構成されているネットワークエレメントが、ワークロード１１４に対向するネットワークデバイス１１２である場合）、エージェントが関与する。メトリックの単純収集におけるＡＰＩの典型的な範囲を超えるより高次の考慮事項（例えば、ナッシュ均衡）には、アルゴリズムが関与する。

【0049】

以下は、本システムおよび方法による例示的なＡＰＩの特徴の集合である。

【0050】

カテゴリヒエラルキー、副詞－動詞／形容詞－名詞ユースケース分解：このユースケースは、ＡＰＩおよびコマンドラインインタフェース（ＣＬＩ）へと純化され、そのようなものとして説明される。カテゴリは、役割ベースのアクセス制御（ＲＢＡＣ）、セキュリティ、ルーティング等において適宜、動的に作用する。

【数8】

【0051】

ユニバーサルエンドユーザメトリックＡＰＩ（サーバサイドエッジメトリックプレゼンテーションエンジン）：全てのメトリックのユニバーサルエンドユーザメトリックＡＰＩの一例が、以下に示されており、＄ＢＯＤＹ環境変数／パラメータをオーバーライドすることにより、個々のイベント毎にカスタマイズされ得る。メトリック毎のＲＢＡＣおよびポリシーにより制約を受けるサービスエクスポージャ（別名：メトリックデータベース）。例において、これは、公開されたＡＰＩのＣＲＵＤＬＢカテゴリ内に存在する。

【数9】

【0052】

ユニバーサルエンドユーザメトリックＡＰＩ（全てのランナブル）：全てのランナブルのユニバーサルエンドユーザメトリックＡＰＩサブカテゴリの一例が下に示されている。／保持／有効は、このＡＰＩファーストプラットフォームにおける各コンポーネントのフェイルオーバを管理するために用いられ、／インベントリは、そのそれぞれの論理（例えば、Ｔｅｒｒａｆｏｒｍコンポーネントインフラストラクチャ）または仮想（ＶＭ Ｇｕｅｓｔワークロード）インベントリを用いてエッジメトリックエコシステムを更新するためのものである。／アーティファクトは、コンテンツルーティング可能シリアル番号に基づく呼び出されたアーティファクトのコンポジット部分である基礎となるＡＰＩに関する詳細を返すためのものである。／ピングは、ＩＣＭＰを用いたルートが適用不可能である場合にセカンダリメトリック収集オプションのＲＥＳＴを実行するために用いられる。ＲＥＳＴは、エッジメトリックエコシステム内の一意識別情報を報告するために用いられ得る。例におけるインベントリ更新は、ｃｒｏｎ ｊｏｂ１つ当たり２４時間以上になり、また、所与のランナブルのそれぞれのＲＥＳＴインタフェースを実行することにより、アドホックで生成され得る。メトリックの使用は、エッジメトリックプレゼンテーションエンジン２３０における状態をクエリしてトランザクションを方向付ける、および、トランザクションのフェーズ２中にターゲット／インベントリを再びクエリしてメトリックの精度をユースケースにより必要とされているように／場合に保証する、という２つのフェーズであってよい。

【数10】

【0053】

ユニバーサルエンドユーザアーティファクトＡＰＩ：全てのアーティファクトの例示的なユニバーサルエンドユーザアーティファクトＡＰＩが、以下に示されており、＄ＢＯＤＹ Ｂａｓｈベースのアルゴリズムを指定してそのように効果をもたらすことにより、個々のイベント毎にカスタマイズされ得る。ｕｕｅｎｃｏｄｅは、ＲＥＳＴコールにおける移送のためのバイナリからテキストへの変換に用いられ得る。アーティファクト毎のＲＢＡＣおよびポリシーにより制約を受けるサービスエクスポージャ。

【数11】

ＡＰＩ ＬＯＧＩＣＡＬからエッジ物理への変換：ＡＰＩプレゼンテーションは、エッジサイト１１６のようなエッジサイトにおける物理エッジアーティファクトへのＡＰＩアーティファクトの論理的事前カテゴリ化に基づき得る。例：クラウド管理プラットフォームにおいて論理的に操作されるアーティファクトは、使用目的毎の、一方のベンダ用の１つの物理構成および他方のベンダ用の別の物理構成を意味し得る。

【0054】

ＡＰＩ ＬＯＧＩＣＡＬからエッジ物理への変換：ＡＰＩプレゼンテーションは、エッジサイト１１６のようなエッジサイトにおける物理エッジアーティファクトへのＡＰＩアーティファクトの論理的事前カテゴリ化に基づき得る。例：クラウド管理プラットフォームにおいて論理的に操作されるアーティファクトは、使用目的毎の、一方のベンダ用の１つの物理構成および他方のベンダ用の別の物理構成を意味し得る。

【0055】

ＡＰＩ汎用からエッジ固有ＡＰＩプレゼンテーションへの変換は、特定のエッジアーティファクトへのＡＰＩアーティファクトの汎用事前操作に基づき得る。例：「複数の領域にわたるスケール」ＡＰＩは、ベンダがそれぞれの構成毎にスケーリングすることを可能にするために、複数のベンダにわたるクラウド管理プラットフォームにおいて操作され得る。

【0056】

加えて、エッジサイト１１６および／または１２６などのエッジサイトにおいてプロビジョニング／構成される特定のネットワークエレメントと共に用いるためのキャプチャエージェントが、キャプチャコンポーネントレポジトリ１１８からダウンロードされ得る。例えば、直接搭載され得るワークロードをネットワークエレメントが含まない場合、別個のキャプチャエージェントが用いられ得る。例において、キャプチャコンポーネントレポジトリ１１８からダウンロード可能なキャプチャエージェントは、自己分散および管理のための機能を有してよく、（例えば、ＯｐｅｎｓｔａｃｋおよびＶＭ Ｗａｒｅをサポートするために）複数のバックエンドテレメトリへのプラグアンドプレイ抽象化を含んでよい。

【0057】

さらに、いくつかの例において、メトリックキャプチャアルゴリズムが、より高次のメトリックキャプチャシステムにおけるエッジサイト推奨決定のために実装され得る。他のアルゴリズムが可能であり、以下は単なる例示である。

【0058】

イベント、ポーリング：帯域内エッジ選択（物理）：イベントベースの選択―イベントが指定された基準毎にクライアントサイドワークロードへ送信され得る。クライアントサイドワークロードがイベントを、したがって、指定された基準毎のエッジ選択を判定する。ポーリング（およびベンチマーキング、スケジューリング）ベースの選択－クライアントサイドワークロードは、キャプチャコンポーネントに対して指定された基準毎にグローバルロードバランサ（例えば、Ｃｉｔｒｉｘ）を介して、（ベンチマークまたはスケジュール）をポーリングする。エッジは、標準Ｃｉｔｒｉｘメカニズム毎に選択され得る。

【0059】

サンプリング：帯域外エッジプレゼンテーションエンジンベースの選択（物理）：空間（確率場）サンプリングベースの選択－クライアントサイドワークロードは、指定された濃度のキャプチャコンポーネントに対して指定された基準毎にＣｉｔｒｉｘを介してポーリングし、指定された「空間」は、初回メトリック収集について生存期間（ＴＴＬ）を有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、新しく生成されたキャッシュデータベースに保存されたメトリックを用いて、指定された次元においてサンプリングされる。その後、エッジメトリックプレゼンテーションエンジン２３０は、まず、キャプチャされたメトリックについてクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。時間的（ポイントプロセス）サンプリングベースの選択－クライアントサイドワークロードは、指定された濃度のキャプチャコンポーネントに対して指定された基準毎にＣｉｔｒｉｘを介してポーリングし、指定された「ポイントまたはプレーン」は、初回メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、指定された次元における「空間」内で、新しく生成されたキャッシュデータベースに保存されたメトリックを用いて、指定された時間にわたって、指定されたレートでサンプリングされる。その後、エッジメトリックプレゼンテーションエンジン２３０は、まず、キャプチャされたメトリックについてクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。

【0060】

入札：帯域外エッジプレゼンテーションエンジンベースのエッジ選択（論理）：標準入札ベース選択（個々の競合入札）－クライアントサイドワークロードは、指定された濃度のキャプチャコンポーネントに対して指定された基準毎にＣｉｔｒｉｘを介してポーリングし、指定された個々の競合「入札」は、指定された次元において要求される。ターゲットエッジサイト（例えば、２１８、２２２）は、初回メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、新しく生成されたキャッシュデータベースに保存されたメトリックのインスタンスで応答する。その後、エッジメトリックプレゼンテーションエンジン２３０は、まず、キャプチャされたメトリックについてクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。ナッシュ均衡ベースの選択（ゼロサムゲーム理論／コミュニティ共同申請入札）－クライアントサイドワークロードは、指定された濃度のキャプチャコンポーネントに対して指定された基準毎にＣｉｔｒｉｘを介してポーリングし、指定されたコミュニティ「入札」は、指定された次元において要求される。ターゲットエッジサイト（例えば、２１８、２２２）は、平衡に到達するための指定された時間または終了状態について指定された基準毎にＣｉｔｒｉｘを介して、ポーリングを用いてそれら自体の間の入札を判定する。次に、ターゲットエッジサイト（例えば、２１８、２２２）は、初回メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたって、新しく生成されたキャッシュデータベースに保存されたメトリックで応答する。その後、エッジメトリックプレゼンテーションエンジン２３０は、まずクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。

【0061】

機械学習：帯域外エッジプレゼンテーションエンジンベースのエッジ選択（物理）：機械学習に関して、ここでの可能なユースケースは、エッジサイト選択である。したがって、機械学習アルゴリズムのために維持される任意の状態が、エッジメトリックプレゼンテーションエンジン２３０の背後のメトリックストレージシステム２２６に存在し得る。同様に、機械学習推論は、そのようなものを計算するために、Ｐｙｔｈｏｎ（登録商標）のようなツールを必要とし得る。したがって、Ｐｙｔｈｏｎ（登録商標）アルゴリズムが、全てのエッジメトリックプレゼンテーションエンジン２３０にわたる新しく生成されたキャッシュデータベースに結果が依然として格納されるそれぞれのＳｐｒｉｎｇ Ｂｏｏｔ ４（ブロッキング）または５（ノンブロッキング）選択エージェントから依然として呼び出され得る。

【0062】

予測／投影ベースの選択（絶対）：適切な機械学習メカニズムが、初回（および／または進行中の）メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、新しく生成されたキャッシュデータベースに保存された「絶対」というメトリックを用いて導入され得る。その後、エッジメトリックプレゼンテーションエンジン２３０は、まずクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。

【0063】

確率ベースの選択（尤度）：適切な機械学習メカニズムが、初回（および／または進行中の）メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、新しく生成されたキャッシュデータベースに保存された「尤度」というメトリックを用いて導入され得る。その後、エッジメトリックプレゼンテーションエンジン２３０は、まずクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。

【0064】

インベントリ：帯域外エッジプレゼンテーションエンジンベースのエッジ選択：インベントリクライアントサイド／またはエッジサイドエージェントベースの選択：適切なエッジキャプチャエージェントメトリックが、指定されたインベントリ基準毎のエッジサイト選択のために適宜キャプチャされる。

【0065】

コンポジット：帯域外エッジプレゼンテーションエンジンベースのエッジ選択：コンポジットクライアントサイドおよび／またはエッジサイドエージェントベースの選択：適切なエッジキャプチャエージェントメトリックが、指定された基準毎のエッジ選択のために適宜評価されたメトリックと組み合わされる。

【0066】

ＣＲＵＤＬＢ：帯域外エッジプレゼンテーションエンジンベースのエッジ選択：クライアントサイドおよび／またはエッジサイドエージェントベースの選択－適切なＣＲＵＤＬＢエッジキャプチャエージェントメカニズムが、初回（および／または進行中の）メトリック収集についてＴＴＬを有する全てのエッジメトリックプレゼンテーションエンジン２３０にわたるＣｉｔｒｉｘを介して、新しく生成されたキャッシュデータベースに保存されたメトリックと共に導入される。その後、エッジメトリックプレゼンテーションエンジンは、まずクエリされ、上記のことをＴＴＬ満了毎に再び実行するのみである。例において、全ての他のエージェントは、このエージェントに基づき得る。

【0067】

特定の例において、メトリックストレージシステム２２６は、個々のデータベースが互いに位置合わせされたマスタアプリケーションリスト（ＭＡＬ）内のテナントアプリケーション間でデフォルトで共有されるマルチアプリケーションテナントデータベースプラットフォームを備え得る。例えば、これは、「小」Ｔシャツ構成と称され得る。同様に、必要が生じた場合、バックエンドデータベースプラットフォームは、代わりに、ＭＡＬ間のマルチテナントであってよく、オペレータにより独立して管理されてよい。性能向上および単一のアプリケーションテナンシーを必要とするユースケースについて、他のＴシャツサイズのデータベースが、次に説明されるよに利用可能である。以下の例において、「Ｍｏｎｇｏ」は、例えばメトリックストレージシステム２２６により使用されるデータベースシステムである。

【0068】

メトリックＴシャツサイズ化
小：（持続性プロファイルがキャッシュである）
マルチアプリケーション－テナント×３レプリカセット
ＤＢおよびドキュメントのデフォルトＴＴＬ
バックアップなし
標準ＳＬＡ
ＤＢのＴＴＬ：９１日
ドキュメントのＴＴＬ：２５時間
ＲＥＳＴ ＡＰＩアクセスのみ、トランザクション毎接続
定型判断なし
デフォルトＣｅｄｅｘｉｓルーティング
デフォルト展開トポロジ
デフォルトスケール
５００ＧＢ／データ
ネイティブアプリケーション認証および許可
Ｍｏｎｇｏ ＣＬＩに基づくＣＲＵＤＬＢ ＡＰＩ
レコードのシステムではない
部分ワードマッチなし
フロック（）ベースの反応性バックエンド挙動
パブリックネットワークＡＰＩ公開のみ
大：（持続性プロファイルがＤＢである）
ＭＡＬシングルアプリケーションテナント×５個の分散レプリカセット
ＤＢおよびドキュメントのカスタムＴＴＬ
カスタムバックアップ
カスタムＳＬＡ
カスタムＤＮＳ
カスタムＣｅｄｅｘｉｓルーティング
カスタム展開トポロジ
カスタムスケール（Ｋ８オペレータを必要とし得る）
定型判断が利用可能
定型ＣＲＵＤＬＢ Ｓｐｒｉｎｇ ＢｏｏｔベースのＡＰＩアクセス
ｍｏｎｇｏｄ：／／アクセス、メッセージ、ブローカＡＰＩアクセス、ＲＥＳＴ置き換え
永続的Ｍｏｎｇｏクライアント接続
５００ＧＢ／データ
ＳＡＭＬベースの認証および許可
可能なレコードのシステム
高度反応性バックエンド挙動ツール技術（Ｓｃａｌａ、反応性ストリーム等）
カスタムプライベートネットワークＡＰＩ公開が利用可能

【0069】

ＮＸＬ：
大きい構成×Ｎ個の５００ＧＢ／データ断片

【0070】

Ｍｏｎｇｏ ＤＢおよび収集ＴＴＬ：小Ｔシャツのみにおいて、Ｍｏｎｇｏは専ら、所与のＤＢおよびＤＢ内の収集についてのＴＴＬを有するキャッシュとして扱われ得る。それは、所与のデータベース上にこれらのＴＴＬセットを有しない例外とみなされ得る。これにより、（プラットフォームがほぼメンテナンスフリーなので）大きいスケールをグローバルに可能にすることに加え、メンテナンス問題が最小化され、一般的なユースケースのためのインフラストラクチャが節約され得る。進行中のＤＢ持続性を必要とするより高次のユースケースは、より大きいＴシャツサイズのインスタンスへ移行し得る。たいてい、小Ｔシャツサイズの構成が適切になる。

【0071】

Ｒｅａｃｔｉｖｅ Ｍｏｎｇｏ、部分ワードマッチング：小を上回るＴシャツサイズにおいて、２つの次元におけるノンブロッキング挙動を実装するために、Ｒｅａｃｔｉｖｅ Ｍｏｎｇｏドライバが導入され得る。１つ目は、ＥＳと同期するために用いられるＳｃａｌａノンブロッキングドライバを用いた部分ワードマッチングのためのＥｌａｓｔｉｃ ＳｅａｒｃｈとＭｏｎｇｏを同期させるために用いられ得る。ＥＳ同期を超えて、Ｍｏｎｇｏ Ｊａｖａ Ｒｅａｃｔｉｖｅ Ｓｔｒｅａｍｓドライバは、所与のユースケースにおいて実装された場合に反応性挙動を実装するために導入され得る。

【0072】

Ｍｏｎｇｏ変更ストリームおよびメトリック閾値化：Ｍｏｎｇｏ変更ストリームは、全てのインスタンスにわたってユニバーサルモニタリングおよびアラームシステムを戦略的に提供すべく、「戦略的」メトリック（複数のインスタンスにわたって同じ閾値を有する、エッジメトリックエコシステムにおける自動関与毎にメトリックがＭｏｎｇｏデータベースへトランザクトされるもの）に対して閾値化するために用いられ得る。戦術メトリックは、依然としてランナブル毎に個々に閾値されてよく、やはり閾値化され得る「アラーム」というキーワードを用いることにより同じアラームを用いてよい。レイテンシが１つのデフォルトメトリックであるが、任意のメトリックが、Ｍｏｎｇｏに格納されてよく、したがって、閾値化されてよい。

【0073】

ＭｏｎｇｏＤＢのＫｕｂｅｒｎｅｔｅｓ Ｏｐｅｒａｔｏｒ：Ｋｕｂｅｒｎｅｔｅｓが利用可能である場合、（ＶＭ Ｇｕｅｓｔに基づく内部Ｍｏｎｇｏ自動化を用いて別様に経験されるのではなく、）Ｐｅｒｃｏｎａ Ｋｕｂｅｒｎｅｔｅｓ Ｏｐｅｒａｔｏｒは、限定されたＤＢ機能を有する大きいスケール用のＭｏｎｇｏＤＢのＰｅｒｃｏｎａサーバのためにスワップされ得る。

【0074】

図３は、本明細書において説明される例毎の、ネットワークエレメントにキャプチャコンポーネントを搭載する例示的な方法３００を示す。動作３０２において、第１のネットワークエッジサイトにおけるネットワークエレメントを構成するための第１の要求が受信される。例において、要求は、第１のクライアントデバイス（例えば、クライアントデバイス１１０）を用いる第１の顧客からネットワークユーティリティ１０２において受信され得る。例において、ネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含み得る。

【0075】

例において、フローは動作３０３へ進み、ここで、キャプチャテンプレートが選択される。例において、動作３０３は、ネットワークエレメントが以前にプロビジョニングされたネットワークエレメントと同様のタイプのものであるかどうかを判断する段階を含み得る。そうである場合、その特定のタイプのネットワークエレメントのキャプチャテンプレートが選択され得る。そうでない場合、デフォルトキャプチャテンプレートが選択され得る。キャプチャテンプレートを選択する他の方法が可能である。

【0076】

フローは動作３０４へ進み、ここで、ネットワークエレメントの第１の構成ファイルが送信される。例において、第１の構成ファイルは、ネットワークユーティリティ１０２によりクライアントデバイス１１０へ送信され得る。例において、第１の構成ファイルは、動作３０３において選択されるメトリック収集の第１のキャプチャテンプレートを含む。例えば、第１のキャプチャテンプレートは、コマンドラインランナーおよび搭載テンプレートを含み得る（例えば、ネットワークエレメントがワークロードを含む場合）。他の例において、キャプチャテンプレートは、キャプチャエージェントテンプレートを含み得る（例えば、ネットワークエレメントがネットワークデバイスを含む場合）。

【0077】

フローは動作３０６へ進み、ここで、第１のネットワークエレメントが、第１のエッジサイトにおいて構成される。例において、第１のキャプチャコンポーネントは、プロビジョニングされたネットワークエレメントを用いて構成およびインストールされる。第１のキャプチャコンポーネントは、第１のキャプチャテンプレートのリファクタリングバージョンを含み得る。例えば、顧客は、第１のキャプチャテンプレートをカスタマイズして、ネットワークエレメントにおける特に関心があるメトリックをキャプチャし得る。加えて、キャプチャコンポーネントは、キャプチャテンプレートとしての将来の使用のために、（例えば、キャプチャコンポーネントレポジトリ１１８に）格納され得る。

【0078】

いくつかの例において、キャプチャコンポーネントは、そのキャプチャコンポーネントによりキャプチャされたメトリックへのアクセスの許可を示すパラメータを含み得る。メトリックアクセス制御システム（例えば、２３６）は、キャプチャコンポーネントによりキャプチャされたメトリックへのアクセスを可能にする前に、そのような許可をチェックし得る。いくつかの例において、許可は、顧客により制御可能である；しかしながら、いくつかの例において、構成ファイルは、必須メトリックのセットを収集するために第１のキャプチャコンポーネントが搭載される場合にのみ第１のネットワークエレメントが第１のネットワークエッジサイトにおいてプロビジョニングされるように、必須メトリックのセットを指定し得る。

【0079】

さらに、いくつかの例において、キャプチャコンポーネントは、ナッシュ均衡アルゴリズム、入札アルゴリズム、ポーリングアルゴリズム、サンプリングアルゴリズム、予測アルゴリズム、機械学習アルゴリズムまたは確率アルゴリズムなど、１つまたは複数のメトリックキャプチャアルゴリズムに関与するように構成され得る。キャプチャコンポーネント、メトリックプレゼンテーションシステム（例えば、２３０）および／またはエッジ推奨システム２４０などのクライアントプロセスのうちの１つまたは複数により、アルゴリズムが実行され得る。

【0080】

フローは動作３０８へ進み、ここで、第１のネットワークエレメントの第１のキャプチャコンポーネントからのメトリックのインスタンスが、メトリックストレージシステムにおいて受信される。例えば、キャプチャコンポーネント（例えば、２２０）からのメトリックのインスタンスが、メトリックストレージシステム２２６において受信され得る。メトリックストレージシステム２２６は、メトリックの受信したインスタンスを例えばデータベース２３２、２３４に格納し得る。

【0081】

フローは動作３１０へ進み、メトリックの要求が受信される。例えば、メトリックストレージシステム２２６は、エッジ推奨システム２４０または別のクライアントプロセスから、メトリックのインスタンスを返すための要求を受信し得る。動作３１２において、メトリックのインスタンスは、例えばエッジ推奨システム２４０に提供される。

【0082】

メトリックがエッジ推奨システムにより要求／受信される例を続けると、フローは動作３１４へ進み、ここで、推奨されるエッジサイトが決定される。例えば、顧客（例えばクライアントデバイス２４２を用いる）は、第２のワークロードがプロビジョニングされる／動作するように構成されるエッジサイトの推奨を要求し得る。動作３１４において、この推奨は、例えばエッジ推奨システム２４０によりクライアントデバイス２４２へ返され得る。

【0083】

例において、フローは判断動作３１６へ進んでよく、ここで、ネットワークエレメントを構成するための別の要求が受信されたかどうかの判断が行われる。そうである場合、フローは動作３０３へ戻ってよく、ここで、第２のエッジサイトにおいてプロビジョニング／構成される第２の（または後続の）ネットワークエレメントについて、プロセスが繰り返される。例えば、第２のクライアント１２０は、第２のネットワークエレメント（例えば、ネットワークデバイス１２４またはワークロード１２２）をエッジサイト１２６にプロビジョニングするようにとの第２の顧客からの要求を発行し得る。後続の要求が受信されなかった場合、フローは、別の要求が受信されるまで待機動作３１８へ進み得る。

【0084】

図４は、コンピューティングネットワーク内のネットワークエレメントをプロビジョニングするためのエッジサイトを推奨する例示的な方法４００を示す。非排他的な例において、方法４００のいくつかのまたは全ての動作は、エッジ推奨システム２４０など、エッジ推奨システムにより実行され得る。フローは動作４０２において始まり、ここで、ネットワークエッジサイトを推奨するための要求が受信される。例において、この要求は、プロバイダネットワーク内の第１のネットワークコンポーネント（ネットワークデバイスまたはワークロードなど）を構成することを所望する第１の顧客からのものであってよい。例において、この要求は、第１のコンポーネント情報および第１の最適化基準の両方を含む。例えば、コンポーネント情報は、構成されるネットワークエレメントおよびこのネットワークエレメントにアクセスする顧客サイトについての情報を含み得る。最適化基準は、例えば、レイテンシ、コスト、セキュリティ等、顧客がエッジサイト選択の最適化を所望する要因を含み得る。例において、最適化基準はまた、異なる基準の相対的な重要度を顧客に示すために顧客により入力される基準の重み付けまたはランク付けと共にエッジ推奨システム２４０に提供され得る。

【0085】

フローは動作４０４へ進み、ここで、第１のコンポーネント情報および第１の最適化基準に基づいて、関連メトリックが決定される。例えば、エッジサイト推奨システム（例えば、エッジサイト推奨システム２４０）は、第１のコンポーネント情報および第１の最適化基準を調査して、プロバイダネットワークによりキャプチャされるどのメトリックがネットワークエレメントの最適なエッジサイトの決定に最も関連しているかを判断し得る。例において、エッジ推奨システム２４０は、コンポーネント情報（例えば、同じまたは同様のタイプのワークロード、同様のデータ伝送プロファイル、同じまたは同様のタイプのデバイスまたはデバイス特性等）により記述されるネットワークエレメントと同様のネットワークエレメントに関連付けられた展開済みのキャプチャエージェントからキャプチャされるメトリックを決定し得る。また、エッジ推奨システム２４０は、ネットワークエレメントにアクセスし、以前に収集されたどのメトリックが例えば推定レイテンシの決定に最も関連しているかの判断においてその情報を用いる顧客サイトの位置をコンポーネント情報から決定し得る。最適化基準は、関連メトリックの決定においても用いられ得る。例えば、顧客がコストおよびレイテンシの最適化を望んでいるがセキュリティを省略していることを、動作４０２において受信された最適化基準が示している場合、関連メトリックは、推定コストおよびレイテンシを決定するために必要とされるもののみを含み得る。

【0086】

フローは動作４０６へ進み、ここで、メトリックストレージシステムが関連メトリックについてクエリされる。例えば、エッジ推奨システム２４０は、ＡＰＩ２２８を通じ、関連メトリックについてメトリックストレージシステム２２６をクエリし得る。例において、メトリックストレージシステム２２６は、プロバイダネットワーク上で動作する他のネットワークエレメントからの関連メトリックのインスタンスを格納する。例において、関連メトリックについてメトリックストレージシステム２２６をクエリすることで、アルゴリズム（またはその部分）が、関連メトリックのいくつかまたは全てを提供するために、メトリックプレゼンテーションエンジン２３０により実行され得る。

【0087】

フローは動作４０８へ進み、ここで、関連メトリックのインスタンスが受信される。例えば、動作４０６におけるクエリに応答して、エッジ推奨システム２４０は、メトリックストレージシステム２２６から関連メトリックのインスタンスを受信し得る。

【0088】

フローは動作４１０へ進み、ここで、関連メトリックのインスタンスは、プロバイダネットワーク内の少なくとも１つのエッジサイトの推奨を生成するために用いられる。例えば、エッジ推奨システム２４０は、顧客から受信される最適化基準のランク付け／重み付けとの組み合わせで関連メトリックのインスタンスを用いて、ネットワーク１０８内の１つまたは複数の推奨されるエッジサイトを決定し得る。例えば、エッジ推奨システム２４０は、例えば顧客により最適化基準が選択されおよび／または順序付けられるようにランク付けおよび／または重み付けされた最適化基準に従ってランク付けされたエッジサイト候補のリストを生成し得る。いくつかの例において、エッジ推奨システム２４０は、スコアリングマトリクスを使用して、ランク付けおよび／または重み付けされた最適化基準（および対応するメトリック）に基づきエッジサイト候補をスコア付けし得る。また、エッジ推奨システム２４０は、インベントリシステムなど、他のデータソースを参照して、特定のエッジサイトが必要なコンピューティング能力、帯域幅、セキュリティ証明等を有しているかどうか、および／またはそれらが顧客のそのような要件を満たすためにアップグレードされ得るかどうかを判断し得る。

【0089】

動作４１２において、推奨が提供される。例えば、エッジ推奨システム２４０は、推奨（例えば、候補エッジサイトの順序付けられたリスト）をクライアント２４２に提供し得る。エッジサイト候補のリストは、ネットワークエレメントをホストするエッジサイトの選択のために、ユーザに提示され得る。エッジサイト候補のリストは、例えば、エッジサイト候補の各々に関連付けられた推定コスト、性能、信頼性、セキュリティ格付け、平均レイテンシ等をユーザが選択すべきエッジサイトの決定に際して閲覧できるように、最適化基準のいくつかまたは全ての基礎となるメトリックインスタンスと共に提示され得る。例において、エッジサイト候補のリストはまた、とりわけ、最適化基準のいずれかでユーザによりソート可能であってよい。例えば、エッジサイト候補のリストは、まず、コストの昇順で提示され得るが、次に、推定レイテンシの昇順で順序付けられるようにユーザによりソートされ得る。

【0090】

フローは動作４１４へ進み、ここで、エッジサイトの選択が受信される。例えば、顧客は、推奨されるエッジサイトのうちの１つを（例えば、クライアントデバイス２４２上に提示されるユーザインタフェースを通じて）選択し得る。動作４１６において、ネットワークエレメントは、選択されたエッジサイトにおいてプロビジョニングされ得る。次に、クライアントデバイス２４２は、例えば、ネットワークエレメントのためのプロビジョニングプロセスとなるように、ネットワークユーティリティ１０２へリダイレクトされ得る。例えば、ネットワークエレメントは、方法３００を用いたメトリック収集のためにプロビジョニング（少なくとも部分的に）および搭載され得る。

【0091】

フローは判断動作４１８へ進み、ここで、エッジサイト推奨の別の（例えば、第２のまたは後続の）要求が受信されているかどうかの判断が行われる。そうである場合、フローは動作４０４へループバックし、ここで、（例えば、第２のエッジサイトにおける第２のネットワークエレメントの構成を所望する第２の顧客のために）行われる第２の（または後続の）推奨について、プロセスが繰り返される。例えば、第２のクライアントデバイス２４２は、ネットワーク１０８内でプロビジョニングされている第２のネットワークエレメントに関連する推奨についての第２の顧客からの要求を発行し得る。コンポーネント情報および／または最適化基準が第１の要求とは異なる例において、エッジ推奨システム２４０は、異なるエッジサイトを第２の顧客に推奨し得る。後続の要求が受信されなかった場合、フローは、別の要求が受信されるまで待機動作４２０へ進み得る。

【0092】

図５は、本システムおよび方法の態様が実施され得る例示的な環境５００を示す。例えば、クライアントデバイス１１０、１２０、２１０、２１２、２４２、ネットワークユーティリティ１０２、キャプチャコンポーネントレポジトリ１１８、エッジサイト１１６、１２６、２１８、２２２、メトリックストレージシステム２２６およびエッジ推奨システム２４０のうちの１つまたは複数は、全体的または部分的に、図５における環境５００の形態を取り得る。

【0093】

最も基本的な構成において、動作環境５００は、典型的には、少なくとも１つの処理ユニット５０２およびメモリ５０４を含む。コンピューティングデバイスの正確な構成およびタイプに応じて、（本明細書において開示される技術を実行するための命令を格納した）メモリ５０４は、揮発性（ＲＡＭなど）、不揮発性（例えば、ＲＯＭ、フラッシュメモリ等）、またはこれら２つの何らかの組み合わせであってよい。この最も基本的な構成は、図５において破線５０６により示されている。さらに、環境５００は、限定されるわけではないが磁気または光ディスクまたはテープを含むストレージデバイス（リムーバブル（５０８）および／またはノンリムーバブル（５１０））も含み得る。同様に、環境５００は、例えば、キーボード、マウス、ペン、音声入力等、入力デバイス５１４、および／または、例えば、ディスプレイ、スピーカ、プリンタ等、出力デバイス５１６も有し得る。環境には、例えば、ＬＡＮ、ＷＡＮ、ポイントツーポイント等、１つまたは複数の通信接続５１２も含まれ得る。実施形態において、この接続は、ポイントツーポイント通信、接続指向通信、コネクションレス通信等を容易にするように動作可能であってよい。

【0094】

動作環境５００は、典型的には、少なくとも何らかの形態のコンピュータ可読媒体を含む。コンピュータ可読媒体は、処理ユニット５０２、またはこの動作環境を備える他のデバイスによりアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を備え得る。コンピュータ記憶媒体は、例えばコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータといった情報の格納のための任意の方法または技術において実装される、揮発性および不揮発性、リムーバブルおよびノンリムーバブルの媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または所望の情報を格納するために用いられ得る任意の他の有形の非一時的媒体を含む。コンピュータ記憶媒体は、通信媒体を含まない。

【0095】

通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを、例えば搬送波または他の搬送メカニズムといった変調されたデータ信号に具現化し、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内の情報をエンコードするように設定または変更された特性のうちの１つまたは複数を有する信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続など、有線媒体、および、音響、ＲＦ、赤外線、マイクロ波および他の無線媒体など、無線媒体を含む。上記のもののいずれの組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。

【0096】

動作環境５００は、１つまたは複数のリモートコンピュータへの論理接続を用いてネットワーク接続環境において動作する単一のコンピュータであってよい。リモートコンピュータは、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通のネットワークノードであってよく、典型的には、上で説明された要素の多くまたは全て、およびそのようには言及されていない他のものを含む。論理接続は、利用可能な通信媒体によりサポートされる任意の方法を含み得る。そのようなネットワーキング環境は、オフィス規模、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいてよく見られる。

【0097】

本明細書ソフトウェアいおいて説明される実施形態は、本明細書において開示されるシステムおよび方法をハードウェアまたはソフトウェアおよびハードウェアの組み合わせを用いて実装および実行するために使用され得る。特定の機能を実行するものとして特定のデバイスが本開示の全体を通じて記載されてきたが、これらのデバイスは、例示の目的で提供されており、本開示の範囲から逸脱することなく、本明細書において開示される機能を実行するために他のデバイスが使用され得ることを、当業者であれば理解するであろう。

【0098】

「１つの例」または「一例」への言及は、この例に関連して説明される特定の特徴、構造または特性が本開示の少なくとも１つの例に含まれることを意味する。本明細書の様々な箇所における「１つの例において」という語句の出現は、全てが必ずしも同じ例に言及しているわけでもなく、他の例と相互に排他的な別個のまたは代替的な例でもない。さらに、他の例ではなくいくつかの例により示され得る様々な特徴が説明されている。

【0099】

本開示は、可能な実施形態のいくつかのみが示された添付図面を参照して、本技術のいくつかの実施形態を説明している。しかしながら、他の態様は、多くの異なる形態で具現化されてよく、本明細書において記載された実施形態に限定されるものと解釈されるべきはない。むしろ、これらの実施形態は、本開示が十分かつ完全であり、かつ、可能な実施形態の範囲を当業者へ完全に伝えるように、提供された。

【0100】

本明細書において特定の実施形態が説明されているが、本技術の範囲は、それらの特定の実施形態に限定されない。当業者であれば、本技術の範囲および趣旨内である他の実施形態または改良を認識するであろう。したがって、具体的な構造、動作または媒体は、例示的な実施形態としてのみ開示されている。本技術の範囲は、以下の特許請求の範囲およびその中のあらゆる均等物により定義される。
［他の可能な項目］
［項目１］
ネットワーク内のメトリックをキャプチャする方法であって、
第１の顧客のためにネットワークエレメントを第１のネットワークエッジサイトにおいて構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する段階、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む；
リファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する段階；
前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからメトリックのインスタンスをメトリックストレージシステムにおいて受信する段階；
前記メトリックの要求を前記メトリックストレージシステムにおいて受信する段階；および
前記メトリックの前記インスタンスを提供する段階
を備える、方法。
［項目２］
前記メトリックの前記要求は、エッジ推奨システムから受信され、メトリックの前記インスタンスは、前記エッジ推奨システムに提供され、前記方法は、
前記エッジ推奨システムが第２の顧客の第２のワークロードの推奨されるエッジネットワークサイトを決定する段階；および
前記第２のワークロードの前記推奨されるエッジネットワークサイトを前記第２の顧客に提供する段階
をさらに備える、項目１に記載の方法。
［項目３］
前記第１のキャプチャコンポーネントをキャプチャコンポーネントレポジトリに格納する段階；
第２の顧客のために第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成するための第２の要求を前記ネットワークユーティリティにおいて第２のクライアントデバイスから受信する段階、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスまたは前記第２のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第２のネットワークエレメントの第２の構成ファイルを送信する段階、ここで、前記第２の構成ファイルは、メトリック収集の第２のキャプチャテンプレートを含む；および
リファクタリングされた第２のキャプチャテンプレートを含む第２のキャプチャコンポーネントを含む前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成する段階
をさらに備える、項目２に記載の方法。
［項目４］
前記第２の要求の受信に応答して、前記第２のネットワークエレメントは前記第１のネットワークエレメントと同様のタイプのものである、と判断する段階
をさらに備え、
前記第２の構成ファイルを送信する段階は、前記第１のキャプチャテンプレートに基づいて前記第２のキャプチャテンプレートを生成する段階を有する、
請求項３に記載の方法。
［項目５］
前記第１のネットワークエレメントが前記ネットワークデバイスである場合、前記第１のキャプチャコンポーネントは、キャプチャエージェントであり、前記第１のネットワークエレメントが前記第１のワークロードである場合、前記第１のキャプチャコンポーネントは、前記第１のワークロード内の埋め込みＡＰＩである、項目１に記載の方法。
［項目６］
前記ネットワークユーティリティは、コンポーネントのインターネット（ＩｏＣ）ファクトリである、項目１に記載の方法。
［項目７］
前記第１のキャプチャコンポーネントは、前記第１のキャプチャコンポーネントから前記メトリックの前記インスタンスへのアクセスに関する許可を示すパラメータを含み、前記方法は、
前記メトリックの前記インスタンスを提供する段階の前に、前記許可をチェックする段階
をさらに備える、項目４に記載の方法。
［項目８］
前記第１の構成ファイルは、必須メトリックのセットを指定し、前記方法は、前記第１のキャプチャコンポーネントが前記必須メトリックのセットを収集するように搭載されている場合にのみ、前記第１のネットワークエッジサイトにおいて前記第１のネットワークエレメントを構成する段階をさらに備える、項目１に記載の方法。
［項目９］
前記第１のキャプチャコンポーネントは、コマンドラインランナーおよび搭載テンプレートを含む、項目１に記載の方法。
［項目１０］
前記第１のキャプチャコンポーネントは、
ナッシュ均衡アルゴリズム；
入札アルゴリズム；
ポーリングアルゴリズム；
サンプリングアルゴリズム；
予測アルゴリズム；または
確率アルゴリズム
という、前記推奨されるエッジネットワークサイトの決定において用いられるアルゴリズムのうちの少なくとも１つのアルゴリズムに関与するように構成されている、
項目２に記載の方法。
［項目１１］
前記少なくとも１つのアルゴリズムは、メトリックプレゼンテーションエンジンにより部分的に実行される、項目１０に記載の方法。
［項目１２］
ネットワークエッジサイトを推奨する方法であって、
第１の顧客のために第１のネットワークエレメントを構成するようプロバイダネットワーク内のネットワークエッジサイトに推奨するための第１の要求を第１のクライアントデバイスから受信する段階、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含み、前記要求は、第１のコンポーネント情報および第１の最適化基準を含む；
前記第１のコンポーネント情報および前記第１の最適化基準に基づいて第１の関連メトリックを決定する段階；
前記第１の関連メトリックについてメトリックストレージシステムをクエリする段階、ここで、前記メトリックストレージシステムは、前記プロバイダネットワーク上で動作する他のネットワークエレメントからの前記第１の関連メトリックのインスタンスを格納する；
前記第１の関連メトリックの前記インスタンスを受信する段階；
前記第１の関連メトリックの前記インスタンスを用いて、前記第１のネットワークエレメントの少なくとも第１のネットワークエッジサイトの推奨を生成する段階；および
前記推奨を前記第１のクライアントデバイスに提供する段階
を備える、方法。
［項目１３］
前記第１のネットワークエッジサイトの選択を受信する段階；および
前記第１の顧客のために前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する段階
をさらに備える、項目１２に記載の方法。
［項目１４］
第２の顧客のために第２のネットワークエレメントを構成するよう前記プロバイダネットワーク内のネットワークエッジサイトに推奨するための第２の要求を第２のクライアントデバイスから受信する段階、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスおよび第２のワークロードのうちの少なくとも一方を含み、前記要求は、第２のコンポーネント情報および第２の最適化基準を含む；
前記第２のコンポーネント情報および前記第２の最適化基準に基づいて、前記第１の関連メトリックとは異なる第２の関連メトリックを決定する段階；
前記第２の関連メトリックについて前記メトリックストレージシステムをクエリする段階、ここで、前記メトリックストレージシステムは、前記プロバイダネットワーク上で動作する他のネットワークエレメントからの前記第２の関連メトリックのインスタンスを格納する；
前記第２の関連メトリックの前記インスタンスを受信する段階；
前記第２の関連メトリックの前記インスタンスを用いて、前記第２のネットワークエレメントの少なくとも第２のネットワークエッジサイトの推奨を生成する段階；および
前記推奨を前記第２のクライアントデバイスに提供する段階
をさらに備える、項目１２に記載の方法。
［項目１５］
前記第１の関連メトリックは、前記第１のネットワークエレメントのタイプに固有である、項目１２に記載の方法。
［項目１６］
少なくとも１つのプロセッサ；および
前記少なくとも１つのプロセッサに動作可能に接続され、命令を格納したメモリ
を備えるシステムであって、
前記命令は、前記少なくとも１つのプロセッサにより実行された場合、
第１の顧客のためにプロバイダネットワーク内の第１のネットワークエッジサイトにおいてネットワークエレメントを構成するための第１の要求をネットワークユーティリティにおいてクライアントデバイスから受信する手順、ここで、前記第１のネットワークエレメントは、第１のネットワークデバイスおよび第１のワークロードのうちの少なくとも一方を含む；
前記ネットワークユーティリティが前記第１のネットワークエレメントの少なくとも第１の構成ファイルを送信する手順、ここで、前記第１の構成ファイルは、メトリック収集の第１のキャプチャテンプレートを含む；
リファクタリングされた第１のキャプチャテンプレートを含む第１のキャプチャコンポーネントを含む前記第１のネットワークエレメントを前記第１のネットワークエッジサイトにおいて構成する手順；
前記第１のネットワークエレメントの前記第１のキャプチャコンポーネントからの第１のメトリックのインスタンスをメトリックストレージシステムに格納する手順；
第２の顧客のために第２のネットワークエレメントを構成するよう前記プロバイダネットワーク内のネットワークエッジサイトに推奨するための要求を第２のクライアントデバイスから受信する手順、ここで、前記第２のネットワークエレメントは、第２のネットワークデバイスおよび第２のワークロードのうちの少なくとも一方を含み、推奨するための前記要求は、コンポーネント情報および最適化基準を含む；
前記コンポーネント情報および前記最適化基準に基づいて関連メトリックを決定する手順；
前記関連メトリックについて前記メトリックストレージシステムをクエリする手順；
前記関連メトリックの前記インスタンスを受信する手順；
前記関連メトリックの前記インスタンスを用いて、前記第２のネットワークエレメントの少なくとも第２のネットワークエッジサイトの推奨を生成する手順；および
前記推奨を前記第２のクライアントデバイスに提供する手順
を含む方法を前記システムに実行させる、
システム。
［項目１７］
前記関連メトリックは、前記第１のメトリックのうちの少なくともいくつかを含む、項目１６に記載のシステム。
［項目１８］
前記関連メトリックを決定する手順は、前記コンポーネント情報を前記第１のネットワークエレメントについての情報と比較し、前記コンポーネント情報が前記第１のネットワークエレメントについての前記情報の少なくとも一部と一致している場合、前記関連メトリックは前記第１のメトリックのうちの少なくともいくつかを含んでいる、と判断する手順を有する、項目１６に記載のシステム。
［項目１９］
前記方法は、
前記第１のキャプチャコンポーネントをキャプチャコンポーネントレポジトリに格納する手順；
前記第２の顧客のために前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成するための第２の要求を前記ネットワークユーティリティにおいて前記第２のクライアントデバイスから受信する手順；
前記ネットワークユーティリティが前記第２のネットワークエレメントの第２の構成ファイルを送信する手順、ここで、前記第２の構成ファイルは、メトリック収集の第２のキャプチャテンプレートを含む；および
リファクタリングされた第２のキャプチャテンプレートを含む第２のキャプチャコンポーネントを含む前記第２のネットワークエレメントを前記第２のネットワークエッジサイトにおいて構成する手順
をさらに含む、
項目１６に記載のシステム。
［項目２０］
前記方法は、
前記第２の要求の受信に応答して、前記第２のネットワークエレメントは前記第１のネットワークエレメントと同様のタイプのものである、と判断する手順
をさらに含み、
前記第２の構成ファイルを送信する手順は、前記第１のキャプチャテンプレートに基づいて前記第２のキャプチャテンプレートを生成する手順を有する、
項目１９に記載のシステム。

【図1】

【図2】

【図3】

【図4】

【図5】

【国際調査報告】