JP6450759B2 - 分散システムにおける顧客志向ネットワークの限界 - Google Patents

分散システムにおける顧客志向ネットワークの限界 Download PDF

Info

Publication number
JP6450759B2
JP6450759B2 JP2016533633A JP2016533633A JP6450759B2 JP 6450759 B2 JP6450759 B2 JP 6450759B2 JP 2016533633 A JP2016533633 A JP 2016533633A JP 2016533633 A JP2016533633 A JP 2016533633A JP 6450759 B2 JP6450759 B2 JP 6450759B2
Authority
JP
Japan
Prior art keywords
network
traffic
service
resource usage
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016533633A
Other languages
English (en)
Other versions
JP2016541183A (ja
Inventor
リザック，アヴィチャイ・メンドル
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/089,224 external-priority patent/US9647904B2/en
Priority claimed from US14/089,230 external-priority patent/US9674042B2/en
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016541183A publication Critical patent/JP2016541183A/ja
Application granted granted Critical
Publication of JP6450759B2 publication Critical patent/JP6450759B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5029—Service quality level-based billing, e.g. dependent on measured service level customer is charged more or less

Description

多くの企業や他の組織は、コンピューティング・システムが同一の場所に配置される（例えば、ローカル・ネットワークの一部として）、或いは、多数の別個の地理的場所に配置される（例えば、一つ以上の私的或いは公的中間ネットワークを介して接続された）として、多数のコンピューティング・システムを相互接続するコンピュータ・ネットワークを動作させて、それぞれの動作をサポートする。例えば、単一の組織により且つその代わりに動作される私的データ・センター、および、顧客にコンピューティング資源を提供するようビジネスとしてエンティティによって動作される公的データ・センター等、著しい数の相互接続されたコンピューティング・システムを収容するデータ・センターは一般的になってきている。幾つかの公的データ・センターのオペレーターは、様々な顧客によって所有されるハードウェアについてネットワーク・アクセス、電力、および、安全な設置施設を提供し、他の公的データ・センターのオペレーターは、その顧客によって使用されるよう利用可能にされたハードウェア資源を含む「フルサービス」施設を提供する。しかしながら、典型的なデータ・センターの規模や範囲が増大されると、物理的なコンピューティング資源を提供し、運営し、管理する作業も益々複雑になってくる。
商品ハードウェアに対する仮想化技術の出現は、様々なニーズを持つ多数の顧客に対して大規模なコンピューティング資源を管理することに関して利益をもたらすため、様々なコンピューティング資源が多数の顧客によって効率的に且つ安全に共有されることが可能となる。例えば、仮想化技術によると、単一の物理的なコンピューティング・マシンによってホストされる一つ以上のバーチャル・マシンを各ユーザに提供することで、該単一の物理的なコンピューティング・マシンは多数のユーザ間で共有されることができる。各バーチャル・マシンは、ユーザに所与のハードウェア・コンピューティング資源の唯一のオペレーターであり管理者であるといった錯覚を与える一方で、様々なバーチャル・マシン間でアプリケーション隔離やセキュリティを提供する、別個の論理的コンピューティング・システムとして作用するソフトウェア・シミュレーションとして考えられる。更に、幾つかの仮想化技術は、多数の別個の物理的なコンピューティング・システムにわたる多数の仮想プロセッサを含む単一のバーチャル・マシン等、二つ以上の物理的資源にわたる仮想資源を提供することができる。
仮想化計算、ストレージ、および、ネットワーク資源のプロバイダによってサポートされる機能性や特徴が増大され、大規模なプロバイダによって使用されるハードウェア・プラットホームの隊が増大されると、ネットワーク・トラフィックの流れを管理する等、プラットホームに対する運営管理制御動作の実施自体が比較的複雑になる。多くの場合、このようなプラットホームで実行されるアプリケーションの機能性や有用性は、プロバイダ・ネットワークの他の部分および／またはクライアント、第三者等の外部エンティティとのネットワーク通信に広く依存し得る。分散システムのオペレーターは、所望のアプリケーション性能レベルを実現しようと典型的にセットアップされた高帯域幅ネットワーク・インフラストラクチャを有してもよい。しかしながら、高帯域幅ネットワーク装置およびリンクが提供されたとしても、特に、多くのタイプの展開されたアプリケーションに対して時間的に変化し、場所に依存する帯域幅要件を考慮するとネットワーク帯域幅は、多くの場合、障害資源となり得る。単一のハードウェア・プラットホーム上で実施される様々なバーチャル・マシンがプラットホームの共有ネットワークの構成要素を用いて満たされなくてはならない幅広く変化するネットワーク要件を有し、所与のハードウェア・プラットホームでインスタンス化されるアプリケーションやバーチャル・マシンのセットが時間と共に変化し得るため、仮想化はネットワーク帯域幅（並びに、待ち時間や他のネットワーク特徴）の管理を益々難しい問題にしている。
図１は、少なくとも幾つかの実施形態による、中央化ネットワーク構成サービスが分散コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理するよう実施されるシステムの実施例を例示する。 図２は、少なくとも幾つかの実施形態による、それぞれのネットワーク構成サーバーが幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例を例示する。 図３は、少なくとも幾つかの実施形態による、仮想化されたコンピューティング・サービスのインスタンス・ホストにおいてトラフィック分類メタデータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する。 図４ａ〜図４ｃは、少なくとも幾つかの実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために使用され得るプロトコルの実施例をそれぞれ示す。 図５は、少なくとも幾つかの実施形態による、分散システムの装置においてネットワーク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類ツリー・データ構造の実施例を例示する。 図６は、少なくとも幾つかの実施形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・トラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造の実施例を例示する。 図７は、少なくとも幾つかの実施形態による、ネットワーク・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るトラフィック分類手順グラフの実施例を例示する。 図８は、少なくとも幾つかの実施形態による、トラフィック分類手順グラフのルックアップ・テーブル・ノードの使用の実施例を例示する。 図９は、少なくとも幾つかの実施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定するために利用され得る応答メトリックの実施例を例示する。 図１０は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。 図１１は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのトラフィック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図である。 図１２は、少なくとも幾つかの実施形態による、トリガとなるイベントに応答してネットワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図である。 図１３は、少なくとも幾つかの実施形態による、分散システムのクライアントにネットワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示するフロー図である。 図１４は、少なくとも幾つかの実施形態による、分散システムの少なくともノードのサブセットについてトポロジー可視化サーバーによって生成され得るカスタマイズ可能なヒートマップの実施例を例示する。 図１５は、少なくとも幾つかの実施形態による、サービス管理者およびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る収集されたメトリックスの異なるサブセットの実施例を例示する。 図１６は、少なくとも幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示するために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示する。 図１７は、少なくとも幾つかの実施形態による、プログラマチック・インターフェイスを介してトポロジー可視化サーバーによって受信され得る可視化リクエストの模範的な要素を例示する。 図１８は、少なくとも幾つかの実施形態による、分散システムの様々なノードの性能インジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する。 図１９は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定された、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイプのセットの実施例を例示する。 図２０は、少なくとも幾つかの実施形態による、ネットワーク構成サーバーによって受信され得る資源使用限界低減リクエストの模範的な要素を例示する。 図２１は、少なくとも幾つかの実施形態による、ネットワーク・アクセス可能サービスのクライアント・アカウントに対する全体的な資源使用限界設定の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。 図２２は、少なくとも幾つかの実施形態による、クライアントがネットワーク・アクセス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよう実施される動作の態様を例示する。 図２３は、少なくとも幾つかの実施形態による、クライアントが分散システムのノードにおいて資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される動作の態様を例示する。 図２４は、少なくとも幾つかの実施形態において使用され得る模範的なコンピューティング装置を例示するブロック図である。
本願では、幾つかの実施形態に対する実施例および例示的図面を用いて実施形態が説明されるが、当業者には、実施形態が記載する実施形態または図面に制限されないことが分かるであろう。図面およびそれに伴う詳細な説明は、実施形態を開示する特定の形態に制限することを意図せず、反対に、添付の特許請求の範囲によって定められる精神および範囲内の全ての変更態様、等価物、および、代替物を網羅することが意図されることは理解されるであろう。本願で使用される見出しは、整理目的のためのみに提供され、明細書または特許請求の範囲の範囲を制限するために使用されることは意図されていない。本願を通じて使用されるように、「得る」といった言い方は、強制的な意味合い（即ち、必須の意味）よりもむしろ、許容的な意味合い（即ち、可能性があるといった意味）で用いられる。同様にして、「含む」、「含んでいる」、および、「含み」といった用語は、含むことを意味しているが、これに制限されない。
プロバイダ・ネットワーク等の大規模な分散システムにおいてネットワーク動作を構成する方法および装置の様々な実施形態を説明する。幾つかの実施形態では、中央化ネットワーク構成管理スキームが実施され、それによると、分散システムの帯域幅限界、待ち時間の管理、および、多数のノード（ホストおよびネットワーク装置等）に対する他のトラフィック・シェーピング・パラメータに関する様々なタイプの決定が、一つ以上のネットワーク構成サーバー（ＮＣＳ）でなされる。（幾つかの実施形態では、サーバーの主な責任が様々なトラフィック・カテゴリーに対してそれぞれの帯域幅限界を課すことで分散システムの構成要素で帯域幅の使用を管理することであるため、ネットワーク構成サーバーは「帯域幅仲裁サーバー」と称されてもよい）。例えば、トラフィック分類手順またはルール、および、トラフィックの様々なカテゴリーに対するネットワーク構成オプションを含む決定を実施するために使用されるべきメタデータは、ＮＣＳから分散システムのノードへポータブルで解析しやすいフォーマットで送信され得る。分散システムのノードでは、受信されたメタデータが、例えば、仮想化管理ソフトウェア内のネットワーク管理モジュールによって解釈されることで、ネットワーク・トラフィック・スケジュールのパケットまたは他の単位が生成された或いは受信されたままの状態で分類され、ＢＡＳでなされた決定が適用されることでトラフィックの送信がスケジューリングされるおよび／または制限される。そのため、トラフィック・シェーピングのために使用されるべき論理を生成する責任（少なくとも幾つかの場合では、様々なソースから取得された重要な入力データ・セットの分析を必要とする）は、中央化ネットワーク構成サーバーによって扱われてもよく、論理は比較的簡単な制御モジュールによって様々なノードで適用されてもよい。少なくとも幾つかの実施形態では、所与のノードに送信されるメタデータは、ノードから収集されるメトリックス、当該ノードで行われるアプリケーションの性質等に基づき、当該ノード専用にカスタマイズされてもよい。ネットワーク構成管理技術は、幾つかの実施形態において、分散システムのクライアントが関心のある資源のネットワーク関連のステータスの統一或いは統合見解を得ることを可能にする、プログラマチック・インターフェイスに対するサポートを含んでもよい。少なくとも幾つかの実施形態では、資源使用インジケータ（例えば、適用可能な帯域幅限界に対する測定された帯域幅の比等）は、ヒートマップまたは他の可視化ツールを用いて表示されてもよい。プログラマチック・インターフェイスは、少なくとも幾つかの実施形態において、クライアントおよび／または管理者が中央化ネットワーク構成システムに様々なタイプの構成リクエストを要請できるよう実施されてもよく、その結果、例えば、ＮＣＳで確定され様々なノードに広められた分類関連のルールおよび／またはネットワーク設定が変化される。少なくとも幾つかの実施形態では、クライアントは、サービス・インスタンス等、様々な資源について帯域幅限界（または他のタイプの資源使用限界）の軽減をリクエストすることができる。少なくとも幾つかの実施では、ネットワーク構成スキームの一部或いは全部がウェブサービスとして実施されてもよく、例えば、一つ以上のウェブサービス・プログラマチック・インターフェイスがネットワーク構成サーバーとの様々なタイプの相互作用についてサポートされ得る。
以下の説明の大半では、中央化ネットワーク構成技術が実施され得る分散システムの実施例として、プロバイダ・ネットワークが使用される。クライアントの分散されたセットにインターネットおよび／または他のネットワークを介してアクセス可能な一つ以上のネットワーク・アクセス可能サービス（例えば、様々なタイプのクラウドベースのデータベース、コンピューティングまたはストレージ・サービス）を提供するよう企業または公共部門組織等のエンティティによってセットアップされたネットワークは、本願ではプロバイダ・ネットワークと称されてもよい。少なくとも幾つかのサービスは、「インスタンス」と呼ばれるサービス単位でクライアント使用のためにパッケージ化されてもよい。例えば、仮想化されたコンピューティング・サービスによってインスタンス化されるバーチャル・マシンは「計算インスタンス」を表し、ストレージ・サービスによってインスタンス化されるブロックレベルの容積等のストレージ装置は「ストレージ・インスタンス」と呼ばれる。幾つかの実施形態では、より高いレベルのサービスのインスタンスが計算インスタンスおよび／またはストレージ・インスタンスを用いてパッケージ化されてもよく、例えば、幾つかの実施形態では、計算およびストレージ・インスタンスの組み合わせを用いてデータベース・インスタンスが構築されてもよい。プロバイダ・ネットワークの様々なネットワーク・アクセス可能サービスのこのような単位が実施されるサーバーおよび／またはストレージ装置等のコンピューティング装置は、本願では「インスタンス・ホスト」と呼ばれ、より簡単に「ホスト」と呼ばれる。本文書の残りでは、所与の通信のソース或いは宛先として使用される場合、「クライアント」といった用語は、プロバイダ・ネットワークの少なくとも一つのネットワーク・アクセス可能サービスにアクセスし利用することができるエンティティ（例えば、組織、多数のユーザを含むグループ、または、単一のユーザ）に所有され、管理され、或いは、割り付けられる全てのコンピューティング装置、プロセス、ハードウェア・モジュール、または、ソフトウェア・モジュールのいずれかを示す。
所与のプロバイダ・ネットワークは、プロバイダによって提供されるインフラストラクチャおよびサービスを実施し、構成し、分散するのに必要な物理的および／または仮想化されたコンピュータ・サーバー、それぞれが一つ以上のストレージ装置を含むストレージ・サーバー、ネットワーク機器等の集まりを含む様々な資源プールをホストする多数のデータ・センター（異なる地理的領域にわたって分散され得る）を含み得る。幾つかの異なるハードウェアおよび／またはソフトウェア・コンポーネントは、その幾つかが異なるデータ・センターにおいて、または、異なる地理的領域においてインスタンス化される或いは実行され、様々な実施形態において各サービスを実施するために集合的に使用されてもよい。クライアントは、クライアント所有の或いはクライアント管理の土地に位置する装置、または、プロバイダ・ネットワーク外にあるデータ・センターから、および／または、プロバイダ・ネットワーク内の装置から、プロバイダ・ネットワークで資源およびサービスと相互に作用してもよい。少なくとも幾つかの実施形態では、様々なタイプの計算インスタンスを提供する仮想化されたコンピューティング・サービスは、プロバイダ・ネットワーク内で実施されてもよく、このような計算インスタンスはクライアントに割り付けられてもよい。プロバイダ・ネットワークの他のサービスは、このような計算インスタンスから、並びに、外部の場所からアクセスされ得る。プロバイダ・ネットワークは、本願記載の帯域幅管理技術の多くが実施され得る一つの模範的な状況として機能するが、これらの技術は、例えば、アプリケーションの異なるコンポーネントが時間的に変化する帯域幅のニーズを持つ大規模な分散アプリケーション環境等、プロバイダ・ネットワークよりも他のタイプの分散システムに適用されてもよいことに注意する。
少なくとも一つの実施形態によると、幾つかのＮＣＳは、プロバイダ・ネットワーク内の様々な場所でインスタンス化されてもよく、このとき、ＮＣＳの数および分散は、例えば、以下に説明する性能および／または利用可能性基準に基づいて確定される。ＮＣＳは、帯域幅管理の決定を補助するよう、プロバイダ・ネットワークの様々なノードから、例えば、プロバイダ・ネットワークにおいて実施される様々なタイプのサービスのインスタンス・ホストから、および／または、様々なタイプのネットワーク装置（スイッチ、ルーター、ゲートウェイ等）からネットワーク関連のメトリックスを取得するよう構成され得る。例えば、時間間隔中の所与のホストにおける実際の入来する／出発するネットワーク・トラフィックに関する情報、時間間隔中にドロップされたパケットの数、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズ、トラフィックを所与のノードに或いは所与のノードから生じさせたアプリケーション、トラフィックを開始させたクライアント、および／または、様々な送信に伴われるエンドポイントのＩＰアドレスが、様々な実施形態において収集されてもよい。幾つかの実施形態では、他のソースからの入力が帯域幅管理の決定を行う際に使用されてもよい。例えば、分散型サービス妨害攻撃（ＤＤＯＳ）等のネットワーク侵入または攻撃を特定するようセキュリティ・サービスが幾つかのプロバイダ・ネットワークで実施されてもよく、潜在的な攻撃に関する警報は帯域幅限界の変化またはトラフィック・カテゴリーの定義に影響を及ぼし得る。少なくとも一つの実施形態では、プロバイダ・ネットワークは、例えば、管理および／または請求目的のために、ＩＰアドレス毎にまたはクライアント毎にネットワーク・トラフィック・メトリックスを集めるサービスを含んでもよく、このような集める側はＮＣＳに入力を供給してもよい。幾つかの実施形態では、プロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスのクライアントおよび／または管理者は、例えば、特定されたインスタンス・ホストまたはネットワーク装置に対する一つ以上の帯域幅管理パラメータを無効にするよう、ＮＣＳに帯域幅関連リクエストまたは他の構成リクエストを要請してもよく、このようなリクエストはＮＣＳで行われる決定にも寄与し得る。
このような入力に少なくとも部分的に基づき、所与のＮＣＳは、プロバイダ・ネットワークの所与のノードで使用されるべき様々なネットワーク構成オプションおよび／または手順を確定してもよい。幾つかの場合では、パラメータを確定する際、一つ以上のグローバルおよび／またはローカル・ネットワーク管理ポリシーも考慮され得る。一実施形態では、カテゴリーそれぞれについて、帯域幅限界、待ち時間の目標または制約等の様々なネットワーク構成オプションと共に、トラフィック・カテゴリーのセットまたは階層が確定されてもよい。幾つかの実施では、フラットな分類（一つのレベルのみを有する階層に等しい）が使用されてもよく、他の実施では、異なるレベルのノード間で親子関係を有する多レベルの階層が使用されてもよい。後続する説明では、本願で使用する「階層」といった用語は、単一レベルのまたはフラットな分類と、親子関係を示す多レベルの分類との両方を網羅することを意図している。階層に加えて、任意の所与のネットワーク・パケット（または、データ転送の全ての適当な単位）をカテゴリーの一つに分類するために使用される手順（例えば、適用されるべき決定ステップまたはルールのシーケンス）が確定されてもよい。トラフィック・カテゴリーに関する情報、および、トラフィック単位をカテゴリーにマッピングするために使用される論理またはルールは、本願では合わせて「トラフィック分類メタデータ」または「分類メタデータ」と呼ばれる。少なくとも幾つかの実施形態において、所与のホストが別のホストとは異なる組み合わせのサービス・インスタンスを有し得、所与のホストのサービス・インスタンスで実施されるアプリケーションのネットワーク要件が他のアプリケーション（同じホストにある、または、他のホストにある）のネットワーク要件と異なり得るため、異なるセットのネットワーク構成パラメータが異なるホストに適当となり得る。したがって、少なくとも幾つかの実施形態では、分類メタデータは少なくとも幾つかのノードについてカスタマイズされてもよく、例えば、インスタンス・ホストＩＨ１等、プロバイダ・ネットワークの一つのノードについて生成された分類メタデータは、インスタンス・ホストＩＨ２等の異なるノードについて生成された分類メタデータと異なってもよい。異なるセットのトラフィック・カテゴリーが異なるノードに対して定められてもよく、例えば、異なる帯域幅限界または待ち時間要件が同じトラフィック・カテゴリーについて設定されてもよく、或いは、トラフィック単位分類手順の少なくとも幾つかのステップが異なってもよい。少なくとも幾つかの実施では、スイッチ、ルーター、ゲートウェイ、または、ロード・バランサ等の様々なネットワーク装置について、または、ネットワーク接続ストレージ装置について確定されるネットワーク構成パラメータは、装置と関連付けられるまたは影響を及ぼされる一組のホストの帯域幅管理パラメータから少なくとも部分的に導出され、例えば、特定のスイッチが八個のホストへの入来／出発トラフィックに使用される場合、トラフィックのあるカテゴリーに対するスイッチの帯域幅限界は八個のホストの帯域幅限界から導出され得る。
所与のノードに対してＮＣＳによって定められるトラフィック・カテゴリーは、異なる実施形態において様々な特性について互いと異なってもよい。一実施形態では、異なるセットのネットワーク・エンドポイントについて異なるカテゴリーが作成されてもよく、例えば、トラフィックの宛先（またはソース）のＩＰ（インターネット・プロトコル）アドレスがトラフィックをカテゴリー化するために使用されてもよい。別の実施形態では、トラフィックが流れる原因となるアプリケーションの種類がトラフィックのカテゴリー化のために使用されてもよく、例えば、データベース関連のトラフィックが一つのカテゴリーに配置され、高性能計算に関連するトラフィックが別のカテゴリーに配置されてもよい。幾つかの実施形態では、トラフィックが生成される原因となるクライアント、および／または、クライアントの予算或いはクライアントが到達した契約上の合意の面がトラフィック・カテゴリーを定めるために使用されてもよい。複数のネットワーク・アクセス可能サービスが分散システムで実施される幾つかの実施形態では、トラフィック・カテゴリーはサービスに基づいて定められてもよく、該サービスによりトラフィックの特定の単位が生成される。サービスベースの分類が使用され、所与のパケットが二つ以上のサービスと関連付けられる場合、例えば、データのパケットがデータベース・サービスのデータベース・インスタンスの代わりにストレージ・サービスから転送される場合、パケットは様々な実施形態においてソース・サービス（即ち、送信側）または宛先サービス（受信側）に属するとして分類されてもよい。少なくとも一つの実施形態では、クライアントは、トラフィック単位を分類するようネットワーク構成サービスによって使用され得る一つ以上の特性の表示を提供してもよく、例えば、クライアントは、幾つかのセットの計算インスタンスが少なくとも一時的に最優先インスタンスと識別されるようリクエストを出してもよく、これらのインスタンスへの或いはこれらのインスタンスからのトラフィックは高帯域幅限界を有する最優先トラフィックとして相応じて分類されてもよい。
幾つかの実施形態では、ＮＣＳは所与のプロバイダ・ネットワークのノードについてトラフィック・カテゴリーをモデル化する或いは表すようツリーまたは同様の階層型データ構造を使用してもよく、このとき、それぞれの帯域幅限界および／または他のネットワーク構成オプションはツリーの各ノードに割り当てられる。少なくとも幾つかの実施では、帯域幅総和ポリシーが分類ツリーに適用されてもよい。このようなポリシーによると、ツリーにおける子ノードＣ１、Ｃ２、．．．Ｃｋを有する所与の親ノードＰがＸビット／秒の帯域幅限界を有する場合、所与の時間期間中に子ノードＣ１、Ｃ２、．．．Ｃｋと関連付けられる実際のトラフィックの総和は親の帯域幅限界を超えてはならない。Ｐの帯域幅限界が出発トラフィックについて１Ｇビット／秒に設定され、Ｐが二つの子ノードＣ１およびＣ２を有する実施例を考慮すると、その帯域幅限界それぞれも出発トラフィックについて１Ｇビット／秒に設定される。所与の１秒にわたって、Ｃ１トラフィックとして分類される０．６Ｇビットのトラフィックがあるインスタンスから流れると、Ｃ２に対して定められる個々の限界はより高いが、Ｃ２トラフィックとして分類されるわずか０．４Ｇビットのトラフィックだけが許可される。親子関係に基づく総和ポリシーは、当然のことながら、待ち時間の制約または目標、サービス品質の目標、パケット・フラグメンテーション設定、または、パケット・サイズについて少なくとも部分的に確定される設定等、ＮＣＳによって確定される幾つかのタイプのネットワーク構成オプションに対しては、様々な実施形態において、関連がない或いは有用でない。
トラフィック・カテゴリーのセットを表すためにツリーまたはツリーのような構造を用いることに加えて、幾つかの実施形態では、ＮＣＳは第二のデータ構造を生成してトラフィック単位をカテゴリーに分類するために使用されるべき手順をモデル化してもよい。分類手順グラフとも呼ばれる第二のデータ構造は、幾つかの実施では決定ノードのシーケンスを一つ以上含んでもよく、所与のシーケンスの連続するノードそれぞれはトラフィック単位をより狭いカテゴリーに分類するために使用されるべき一つ以上の基準を示す。少なくとも一つの実施では、分類手順グラフのうちの幾つかの決定ノードは、多数のカテゴリーの選択肢の中から一つのカテゴリーを選択するために使用され得るルックアップ・テーブル（例えば、ハッシュ・テーブル）を含んでもよい。ルックアップ・テーブルのエントリーは、分類されるべきネットワーク・トラフィック単位の一つ以上の特性に基づいてインデックスを付けられてもよく、例えば、宛先またはソースＩＰアドレスの一部または全部がインデックス付けに使用されてもよく、或いは、別のパケットのヘッダ・フィールドの一部分またはパケットのボディのコンテンツさえもがテーブル中の特定のエントリーを調べるために使用されてもよい。少なくとも幾つかの実施形態では、ルックアップ・テーブルのエントリーは、別の分類手順グラフまたはサブグラフをもたらす。そのため、このような実施では、パケットの所与の特性が、最初に、幾つかの可能なルックアップ・テーブルのエントリーの中からのルックアップ・テーブルのエントリーの選択を生じ、続いて、選択されたルックアップ・テーブルのエントリーの処理が別のセットの決定ノード（これらノード自体が他のルックアップ・テーブルを含む）のトラバースをもたらし、最終的に、パケットのカテゴリーが識別される。様々な実施形態においてこのような手順のステップを用いて、比較的詳細な細かいカテゴリー・マッピングがネットワーク・パケットおよび／または他のトラフィック単位に対して定められ得、それにより、高度なトラフィック・シェーピングが可能となる。少なくとも幾つかの実施において、異なる分類階層および／または手順が入来するおよび出発するトラフィックに対して生成されてもよい。
関連するネットワーク構成オプションを含むトラフィック・カテゴリーのセットと、ネットワーク・トラフィック単位をカテゴリーにマッピングするための論理を有するメタデータを生成した後、幾つかの実施形態では、ＮＣＳはメタデータが適用されるべきノードへの送信のためにメタデータのポータブル表現を生成してもよい。例えば、様々な実施では、メタデータの一つの或いは両方のコンポーネントがＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ），ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ），ＹＡＭＬ（頭字語が“Ｙｅｔ Ａｎｏｔｈｅｒ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ”または“ＹＡＭＬ Ａｉｎ’ｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ”等の幾つかの可能な拡張子を有するシリアル化フォーマット）等の業界標準プロトコルまたは言語に従って符号化されてもよい。他の実施では、独占的符号化技術またはプロトコルを使用してデータ構造のポータブル・バージョンを生成してもよい。
ポータブル表現は、プロバイダ・ネットワークまたは分散システムのターゲット・ノード、例えば、表現を解析して手順グラフによって示される手順を実施する、ネットワーク管理モジュールのような制御／管理モジュールに送信されてもよい。受信したメタデータを用いて、その後様々なトラフィック単位がターゲット・ノードで適当なカテゴリーに分類され、様々なネットワーク送信はそれぞれのトラフィック・カテゴリーについて示される帯域幅限界または待ち時間要件等のネットワーク構成オプションに応じてスケジューリングされるおよび／または制限されるまたは遅延されてもよい。このような送信中に収集されるメトリックスはＮＣＳにフィードバックされ、その後の時間期間にわたるメタデータの改善を可能にする。そのため、ＮＣＳと、ＮＣＳで成される決定が最終的に実施されるノードとの間でフィードバック・ループが確立されてもよく、それにより、時間をかけてネットワーク管理パラメータを動態的調整することが可能となる。このようなカスタマイズ可能なトラフィック分類および構成技術を用いることで、様々な実施形態において、中央化ネットワーク構成システムはプロバイダ・ネットワークの様々な部分におけるトラフィックを任意の所望のレベルの粒度に制御しシェーピングすることが可能となる。
異なる実施形態において、様々なアプローチ法がターゲット・ノードへの分類メタデータの分散に使用されてもよい。例えば、一実施形態では、ＮＣＳは、ＮＣＳが割り当てられたホストおよび／またはネットワーク装置それぞれに分類メタデータを周期的に（例えば、少なくともＸ分に一回）「プッシュ」するよう構成されてもよい。幾つかの実施形態において、様々なタイプのトリガとなるイベント（潜在的なネットワーク侵入または攻撃の検出等）は、新しい分類メタデータの普及につながる。例えば、以下により詳細に説明するように、攻撃の影響を緩和または制限する試みとして、幾つかのセットのノードにおける帯域幅限界が低下されるか、低帯域幅限界を有する新しいカテゴリーが定められてもよい。別の実施形態では、例えば、ＮＣＳにメタデータ・リクエストを送信し、それに応答してメタデータを受信することで、プロバイダ・ネットワークの少なくとも幾つかのノードは、割り当てられたＮＣＳからトラフィック分類メタデータを「プル」してもよい。幾つかの実施形態では、スケジュール化されたプッシュ技術、メタデータのトリガとなるイベントに基づく分散、および／または、ノードで開始されるプル技術の組み合わせが使用されてもよい。
幾つかの実施形態では、プロバイダ・ネットワークまたは他の分散システムは、複数の地理的領域に整理されてもよく、各領域は、本願では「利用可能ゾーン」とも称される一つ以上の利用可能コンテナを含んでもよい。利用可能コンテナは、所与の利用可能コンテナにおける資源が他の利用可能コンテナにおける故障と隔離されるように操作される一つ以上の別個の場所またはデータ・センターを有してもよい。つまり、一つの利用可能コンテナにおける故障は、任意の他の利用可能コンテナにおける故障と時間的に或いは因果的に相互に関係することが予想されないため、資源インスタンスまたは制御サーバーの利用可能プロフィールは異なる利用可能コンテナにおける資源インスタンスまたは制御サーバーの利用可能プロフィールと独立していることが意図される。クライアントは、それぞれの利用可能コンテナにおいて多数のアプリケーション・インスタンスを立ち上げることで単一の場所で故障からそれぞれのアプリケーションを保護することができる。同時に、幾つかの実施では、同じ地理的領域内にある資源インスタンス間に安価で低待ち時間のネットワーク接続が提供される（同じ利用可能コンテナの資源間のネットワーク送信はより速くなる）。ネットワーク構成システムについて所望のレベルの利用可能性および／または性能を実現するために、幾つかの実施形態では、少なくとも一つのネットワーク構成サーバーが各利用可能ゾーンでセットアップされてもよい。幾つかの実施形態では、少なくとも一つのＮＣＳが各データ・センター内に確立されてもよい。幾つかの実施形態では、所与の領域、利用可能コンテナ、または、データ・センター内にセットアップされるべきＮＣＳの数は、性能要件に少なくとも部分的に基づいて確定されてもよく、例えば、変更された帯域幅限界を生成し、変更された限界を適当なセットのノードで適用することで、ネットワーク構成システムがどれだけ早くネットワーク攻撃または他のトリガとなるイベントに反応することができるかに基づいて確定されてもよい。
一実施形態によると、一つ以上のプログラマチック・インターフェイス（例えば、ＡＰＩ（アプリケーション・プログラミング・インターフェイス）、ウェブページ、コマンド・ライン・ツール、グラフィカル・ユーザ・インターフェイス等）は、プロバイダ・ネットワークのクライアントおよび／または他のサービスによる使用のためにネットワーク構成システムによって実施されてもよい。このような実施形態の一つでは、前述の通り、様々なサービスのクライアントまたは管理者は、特定のサービス・インスタンスまたはホストについてネットワーク構成オプションを設定または変更するよう帯域幅無効リクエスト等の構成リクエストを要請してもよい。幾つかのクライアントは、例えば、少なくとも幾らかの時間間隔にわたって少なくとも幾つかのアプリケーションについて帯域幅限界を増加（または低減）させることを望む場合がある。幾つかの実施形態では、多数のサービス・インスタンス（数百または数千の計算インスタンス、ストレージ・インスタンス、データベース・インスタンス等）が所与のクライアントに割り付けられ、クライアントがそのサービス・インスタンスのサブセットのネットワーク・ステータス（適用可能な帯域幅限界、待ち時間設定等を含む）の最新の統合ビューを得ることを望む場合がある。幾つかの実施形態では、例えば、プロバイダ・ネットワークのコンソール・サービスによって、或いは、幾つかの他の統合ネットワーク・ビュー生成部によって統一されたビューを提供するために、ネットワーク構成サービスのプログラマチック・インターフェイスが使用されてもよい。プログラマチック・インターフェイスは、幾つかの実施形態では、新しいサービス・インスタンスが立ち上げられるインスタンス・ホストを識別する責任を担うインスタンス配置サービス等の他のサービスによって使用されてもよい。特定のインスタンス・ホストを新しいサービス・インスタンスに対する候補として考えた場合、配置サービスは、候補における最近の帯域幅使用傾向、ネットワーク送信が最近制限された数、および／または、当該インスタンス・ホストに対する現在確立されているネットワーク帯域幅限界または待ち時間設定等、プログラマチック・インターフェイス上で用いるネットワーク構成サービスから情報を取得し、この情報を用いて新しいサービス・インスタンスの配置を確定してもよい。
模範的なシステム環境
図１は、少なくとも幾つかの実施形態による、中央化ネットワーク構成サービスが分散コンピューティング環境の複数のノードにおいてネットワーク・トラフィックを管理するよう実施されるシステム１００の実施例を例示する。図示するように、ＮＣＳ１８０ＡやＮＣＳ１８０Ｂのようなネットワーク構成サーバー１８０のプール１８２が確立されてもよい。幾つかの実施形態において、図２に例示し、以下に説明するように、ＮＣＳ１８０は、コンピューティング環境の様々なデータ・センターの間で分散されてもよい。所与のＮＣＳ１８０は、例えば、異なる実施形態において一つ以上のソフトウェアおよび／またはハードウェア・モジュールを有し、幾つかのケースでは自身が複数のコンピューティング装置を用いて実施されてもよい。ＮＣＳ１８０は、幾つかの異なるタイプのソースから入力を受信するよう構成され得る。分散コンピューティング環境の様々な要素において適用されるべき帯域幅限界等のカスタマイズ可能なトラフィック分類論理やネットワーク構成オプションは、図示する実施形態において、入力に基づいておよび／またはグローバル・ネットワーク管理ポリシー１２２を考慮してＮＣＳによって確定されてもよい。ネットワーク構成サービスの視点からすると、分散コンピューティング環境の要素は、測定関連コンポーネント１０７、決定コンポーネント１０８、および、実施コンポーネント１０９といった三つの高レベルなカテゴリーに分類されてもよい。測定関連コンポーネント１０７はＮＣＳに対する様々な入力ソースを有し、決定コンポーネント１０８はＮＣＳ自体を有し、実施コンポーネント１０９はネットワーク・トラフィックをシェーピングするために決定が実行される、または、決定コンポーネントによって生成された出力が他の目的のために利用されるエンティティを表す。古典的な制御システム・フィードバック・ループのようなフィードバック・ループは、実施コンポーネント（例えば、サービス・インスタンス・ホスト１４４および／またはネットワーク装置１４５）の幾つかから測定結果を得て、これらのメトリックスを用いてＮＣＳ１８０による後続の決定を確定することで確立されてもよく、ＮＣＳは実施されると将来的な決定に影響を与える追加的な測定につながる。
幾つかのタイプのネットワーク関連のメトリックスは、例えば、メトリックス・コレクタ１２５によってインスタンス・ホスト１４４および／またはネットワーク装置１４５から集められ、図示する実施形態において、ＮＣＳ１８０によってアクセス可能なメトリックス・データベース１９０に配置されてもよい。例えば、このようなメトリックスは、時間間隔（例えば、バイトまたはパケットで表現される）中の所与のホストにおける入来する／出発するネットワーク・トラフィック率、ＴＣＰ（通信制御プロトコル）またはＵＤＰ（ユーザ・データグラム・プロトコル）のような様々なプロトコルに対応するネットワーク接続の数、時間間隔中にドロップされたパケットの数やパケットがドロップされた原因、現在の帯域幅限界の実施により送信が遅延されたパケットの数、パケットのサイズの分散、所与のノードに或いは所与のノードからトラフィックを生じさせたアプリケーション、トラフィックを開始させたクライアント、パケット・デリバリーと関連付けられる待ち時間、および／または、様々な送信に伴われるエンドポントのＩＰアドレスを含んでもよい。データベース１９０に記憶されるメトリックスに加えて、ＮＣＳは、セキュリティ・サービス１１１またはトラフィック・メトリック集合部１１２のようなシステム１００の追加的な入力データ・ソース１１０から入力を受信してもよい。セキュリティ・サービス１１１は、ネットワーク侵入または攻撃（その幾つかはシステム１００の外部で生ずる、例えば、公衆インターネットの様々な場所から生じ、他は幾つかのインスタンス・ホスト１４４自体で生ずる）を検出するよう、システム１００の様々な部分でトラフィック・パターンを監視するよう構成されてもよい。不審なトラフィック・パターンが検出された場合、例えば、所与のネットワーク・アドレスに方向付けられた高トラフィックの急激且つ持続したバーストがあると、セキュリティ・サービス１１１はＮＣＳ１８０に通知する。これは緩和作用を伴い得る。例えば、ＮＣＳ１８０は、新しいネットワーク・カテゴリーおよび適用されるべき対応する帯域幅限界を生成する、または、既存のカテゴリーの帯域幅限界を変更し、新しく変更されたまたは生成された分類メタデータを適当なホストに送信して潜在的なセキュリティ・イベントの影響を制限してもよい。トラフィック・メトリック集合部１１２は、コレクタ１２５から送信されるメトリックスをバケット、例えば、ＩＰアドレス毎のバケットまたはクライアント毎のバケットに組み合わせてもよく、バケットの表現はネットワーク構成の決定を行う際に考慮されるようＮＣＳに利用され得る。
図１に示す実施形態では、クライアント無効リクエスト１３０および／または管理者無効リクエスト１３１もＮＣＳ１８０による決定において役割を担う。例えば、ＮＣＳ１８０は、グローバル・ポリシー１２２および他のメトリックスに基づき、インスタンス・ホスト１４４におけるトラフィックの所与のカテゴリーＣ１に対する帯域幅限界が考慮される次の時間間隔について２Ｇビット／秒に設定されるべきと確定し得る。しかしながら、計算インスタンスがたまたま当該インスタンス・ホストにおいてインスタンス化されるクライアントは、当該計算インスタンスに対して５Ｇビット／秒の帯域幅をリクエストする、または、当該インスタンス・ホストにおいて実施されるサービスの管理者は１Ｇビット／秒に帯域幅を制限するようリクエストする。このようなリクエストは、図示する実施形態において他の要因を無効にするためにＮＣＳによって使用されてもよい。クライアントが、発生したトラフィックの量に比例してネットワーク・トラフィックに対する金額が請求される実施形態では、幾つかのクライアントはコストを制御するために帯域幅使用に上限を課すことを望む場合がある。このような上限も無効リクエスト１３０の実施例を表し得る。
幾つかの実施形態によると、所与のＮＣＳ１８０は、ＮＣＳが割り当てられた一つ以上のインスタンス・ホスト１４４および／またはネットワーク装置１４５に対してトラフィック分類メタデータを生成してもよい。少なくとも幾つかの実施形態では、分類メタデータはネットワーク接続ストレージ（ＮＡＳ）装置等のストレージ装置に対しても生成され得る。メタデータは、例えば、ツリー・データ構造として表されてもよい一つ以上のレベルのトラフィック・カテゴリーの階層を有してもよく、このとき、ツリーの各ノードはそれぞれのトラフィック・カテゴリーを表し、ネットワーク構成オプションまたは設定（例えば、帯域幅限界または待ち時間要件）の関連するセットを有する。幾つかの実施形態では、トラフィック総和ポリシーは、図５を参照して以下に説明するように、分類ツリーに適用されてもよい。図５によると、親ノードの子ノードとして表されるトラフィック・カテゴリーに対する実際のトラフィック率は親ノードの帯域幅限界を超えてはならない。それぞれの分類ツリーが各インスタンス・ホスト１４４に対して生成される幾つかの実施形態によると、図６を参照して以下に説明するように、ホスト・レベルの分類ツリーは、ＮＣＳ１８０によってラックレベルのツリーまたはデータ・センター・レベルの分類ツリーにさえも合わされ得る。このような高レベルのツリーは、例えば、ネットワーク・トラフィックの流れに対するより広い視点を得る、および／または、インスタンス・ホスト毎またはネットワーク装置毎に行われるよりも高レベルの決定を行うために使用されてもよい。
分類ツリーに加え、トラフィック分類メタデータは、図示する実施形態においてパケット等のネットワーク・トラフィック単位を分類ツリーに定められる様々なカテゴリーにマッピングするために使用されるべき手順も含み得る。手順のステップは、例えば、手順グラフの決定ノードとして表されてもよい。所与の手順グラフは、幾つかの実施において一つ以上の決定ノードのシーケンスを有してもよく、このとき、連続するノードは、ネットワーク・トラフィック単位を連続して狭くなるトラフィック・カテゴリーに一致させるために使用されるべき基準の表示を含む。少なくとも一つの実施において、幾つかの決定ノードはハッシュ・テーブルのようなルックアップ・テーブルを含んでもよい。このようなルックアップ・テーブル・ノードを用いると、所与のパケットまたはトラフィック単位が単一のグラフ・ノードを用いて多数の異なるカテゴリーのうちの一つにマッピングされ、それにより、手順グラフのサイズや複雑性が減少される。幾つかのケースでは、ルックアップ・テーブル・ノードのエントリーは他の手順グラフまたはサブグラフへのポインタとして機能してもよく、それにより、非常に細かい分類論理または基準の使用が可能になる。手順グラフやルックアップ・テーブルを組み込む決定ノードの実施例は図６および図７に示され、以下により詳細に説明される。少なくとも幾つかの実施形態では、分類メタデータは、適当なインスタンス・ホスト１４４および／またはネットワーク装置１４５に分散されることに加えて、分類データベース１９２に記憶されてもよい。
幾つかの実施形態によると、ＮＣＳ１８０において生成されるメタデータは、分散システム１２７を介してその意図する宛先に送信されてもよい。分散システム１２７は、それ自体、ルーティング情報および／またはアクセス制御リスト等、他のタイプのメタデータをシステム１００の様々なノードに分散するために使用され得る複数の中間ノードを幾つかの実施において有してもよい。データベース１９２が生成されたメタデータの保存場所として使用される実施形態では、分散システム１２７のノードは、例えば、データベース１９２が更新された場合に（例えば、通知メカニズムに申し込むことで）通知されてもよく、また、相応じて新しいメタデータを適当な宛先に転送してもよい。幾つかの実施形態では、メタデータのポータブル表現（例えば、分類ツリーおよび手順）は、ＪＳＯＮ、ＸＭＬ、ＹＡＭＬ、または、独自の技術または言語等のプロトコルを用いて、ＮＣＳ自体によって、或いは、分散システム１２７によって生成されてもよい。一つの実施では、ポータブル表現がデータベース１９２に記憶されてもよい。図３に例示され以下に更に詳細に説明されるように、宛先では、受信したメタデータの表現が、例えば、インスタンス・ホスト１４４の場合には仮想化管理ソフトウェア・スタックのネットワーク管理モジュールによって解析されてもよい。
一実施形態では、実施サブシステム１０９の他の出力宛先１５０からＮＣＳ１８０に向けられたリクエストを扱うために一つ以上のＡＰＩサーバー１７０がセットアップされ得る。例えば、一つ以上のサーバーは、分散環境の選択された部分のネットワーク・ステータスの統一ビューをクライアントに提供するために、統合ネットワーク・ビュー生成部１５２として構成されてもよい。ある一つの実施では、例えば、クライアントは、様々なインスタンス・ホストにおいて数百または数千のサービス・インスタンスが割り当てられ、ビュー生成部１５２によって実施されるコンソールを介してそれぞれのインスタンスに対する様々なタイプのメトリックス（例えば、最近の入来／出発トラフィック率、ドロップされたパケット率、適用可能な帯域幅限界等）を見ることができる。少なくとも一つの実施形態では、配置サービス１５１もＡＰＩサーバー１７０を介してＮＣＳからのネットワーク帯域幅限界および他のメトリックスにアクセスすることができ、これは、立ち上げられるべき新しいサービス・インスタンスに使用されるインスタンス・ホストに関して決定を行う際、或いは、既存のサービス・インスタンスを帯域幅の競合がより少ないインスタンス・ホストに移動する際に有用となる。
図２は、少なくとも幾つかの実施形態による、それぞれのネットワーク構成サーバーが幾つかの利用可能コンテナそれぞれに確立されるプロバイダ・ネットワーク環境の実施例を例示する。図示するように、プロバイダ・ネットワーク２０２は、図示する実施形態において幾つかの利用可能コンテナ２０３、例えば、２０３Ａ、２０３Ｂ、および、２０３Ｃを有してもよい。各利用可能コンテナは一つ以上のデータ・センター２０５を有してもよく、例えば、利用可能コンテナ２０３Ａにはデータ・センター２０５Ａおよび２０５Ｂが設けられ、利用可能コンテナ２０３Ｂにはデータ・センター２０５Ｃが設けられ、利用可能コンテナ２０３Ｃにはデータ・センター２０５Ｄが設けられる。前述の通り、各利用可能コンテナ２０３は、任意の所与の利用可能コンテナにおける様々なタイプの故障イベントの影響が当該利用可能コンテナに典型的には制限されるよう（例えば、電力源等のそれぞれ独立したインフラストラクチャ素子を有して、且つ、異なる利用可能コンテナ間の幾らかの地理的距離を有して）設計され操作され得る。そのため、故障および／またはエラーは、利用可能コンテナの境界を越えて典型的には広がらず、異なる利用可能コンテナは独立した故障プロフィールまたは独立した利用可能プロフィールを有すると考えられる。例えば、所与の利用可能コンテナが自然災害を受けた場合でも、他の利用可能コンテナは動作可能なままであると予期される。
利用可能コンテナ間依存性を回避或いは低減するといった設計の目標を実現すべく、図示する実施形態において少なくとも一つのＮＣＳ１８０が各利用可能コンテナ２０３に確立されてもよい。例えば、ＮＣＳ１８０Ａおよび１８０Ｂは利用可能コンテナ２０３Ａのデータ・センター２０５Ａおよび２０５Ｂにそれぞれセットアップされ、ＮＣＳ１８０Ｃは利用可能コンテナ２０３Ｂのデータ・センター２０５Ｃに確立され、ＮＣＳ１８０Ｄは利用可能コンテナ２０３Ｃのデータ・センター２０５Ｄに位置される。ＮＣＳ１８０Ａは、データ・センター２０５Ａにおいて実施されている一つ以上のネットワーク・アクセス可能サービス（例えば、仮想化されたコンピューティング・サービスまたはストレージ・サービス）のインスタンス・ホスト１４４Ａ、および、データ・センター２０５Ａに位置するネットワーク装置１４５Ａに対して分類メタデータを生成するよう構成されてもよい。同様にして、ＮＣＳ１８０Ｂには、インスタンス・ホスト１４４Ｂおよびネットワーク装置１４５Ｂに対して分類メタデータを生成するタスクが割り当てられ、ＮＣＳ１８０Ｃはインスタンス・ホスト１４４Ｃおよびネットワーク装置１４５Ｃに対して分類メタデータを生成する責任を担い、ＮＣＳ１８０Ｄはインスタンス・ホスト１４４Ｄおよびネットワーク装置１４５Ｄに対して分類メタデータを生成するよう構成されてもよい。図２に示す実施形態では、単一のＮＣＳが各データ・センター２０５に示されているが、少なくとも幾つかの実施形態では、複数のＮＣＳが（例えば、性能要件および／またはデータ・センターにおいてメタデータが生成されるべきノードの数に依存して）所与のデータ・センター２０５にセットアップされてもよい。一実施形態では、利用可能コンテナ（例えば、２０３Ａ）がＮ個のデータ・センターを有し、帯域幅管理に対する性能要件がＮ個未満のＮＣＳで満たされる場合、幾つかのデータ・センターはどの構成されたＮＣＳも有する必要がなく、代わりに、単一のＮＣＳが二つ以上のデータ・センターに十分となり得る。他の実施形態では、所与のＮＣＳ１８０は、二つ以上の利用可能コンテナにおいてノードに対するメタデータを生成するよう構成され得る。
ＮＣＳ１８０の数および配置は、図示する実施形態においてネットワーク構成サービス・マネージャ２２２によって確定されてもよい。ＮＣＳマネージャ２２２自体は、幾つかの実施において複数のハードウェアおよび／またはソフトウェア・コンポーネントを有し、その幾つかは様々な利用可能ゾーン２０３のデータ・センター２０５にわたって分散されてもよい。ＮＣＳ１８０に対する構成の変化は、図示する実施形態において、必要に応じてＮＣＳマネージャによって開始されてもよく、例えば、ＮＣＳによって使用されるソフトウェア・モジュールの新バージョンが展開されるべき場合、その展開がＮＣＳマネージャによって調整されてもよい。
プロバイダ・ネットワークの幾つかの他のサービスは、図示する実施形態において、ネットワーク構成システムと相互に作用してもよい。例えば、統一コンソール・サービス２７８が一つ以上のプログラマチック・インターフェイス２４０（例えば、ウェブページ、ＡＰＩ、ＧＵＩ、および／または、コマンド・ライン・ツール）を実施することで、クライアント２６５は関心のある資源のネットワーク・ステータスに関するクエリーを出すか、リクエストした情報をプログラムで受信することが可能となる。統一コンソール・サービス２７８は、図１の統合ネットワーク・ビュー生成部１５２の一実施例を表してもよい。プログラマチック・インターフェイス２４０は、クライアントが構成リクエストを要請する、例えば、特定された時間期間にわたって様々なサービス・インスタンスまたはインスタンス・ホストに対する現在適用可能な帯域幅限界を上げるか下げることを可能にする。
装置健康管理サービス２７６は、幾つかの実施形態において、様々なインスタンス・ホストおよびネットワーク装置から応答情報を（例えば、心拍メカニズムを用いて）収集するよう、プロバイダ・ネットワーク２０２で実施される。図示する実施形態では、健康管理サービス２７６は、例えば、健康ステータス・メッセージにネットワーク・メトリックスをピギーバックさせることで、ＮＣＳ１８０によって入力として使用されるべきネットワーク関連のメトリックスの収集に使用されてもよい。そのため、健康管理サービス２７６のノードは、図１に示すメトリックス・コレクタ１２５の実施例として考えられてもよい。健康管理サービスは、幾つかの実施形態においてメタデータ分散システム１２７として使用されてもよく、例えば、様々なインスタンス・ホストに送られる心拍メッセージはピギーバックされた分類メタデータを含んでもよい。ＤＤＯＳ検出サービス２７４は、例えば、所与のセットのＩＰアドレスへの或いは所与のセットのＩＰアドレスからの異常に重いトラフィック・パターンを検出することで、プロバイダ・ネットワーク内のターゲットにおけるサービス攻撃の拒絶および／または外部ターゲットにおけるプロバイダ・ネットワーク２０２内から開始され得たサービス攻撃の拒絶を検出するよう構成されてもよい。潜在的なＤＯＳ攻撃が識別されると、ＤＤＯＳ検出サービス２７４は、潜在的なネットワーク攻撃または侵入に関して適当なＮＣＳ１８０に入力を供給してもよく、これにより、ＮＣＳ１８０は、潜在的な攻撃の影響を緩和させるよう幾つかのインスタンス・ホストまたはネットワーク装置について少なくとも一時的に帯域幅限界を狭めるか他のネットワーク構成オプションを変える。インスタンス配置サービス２７２は、ＮＣＳ１８０から最近の利用可能なネットワーク関連メトリックスおよび構成設定を取得して、新しいインスタンスを立ち上げるに利用可能な十分な余分帯域幅を有するインスタンス・ホストを選択する、または、ネットワーク・トラフィック状態を変えることを考慮して既存のインスタンスを移動すべきインスタンス・ホストを選択する。
インスタンス・ホストにおける分類メタデータの使用
前述の通り、異なる実施形態において、ネットワーク構成サーバーは、様々なネットワーク・アクセス可能サービスのインスタンス・ホストにトラフィック分類メタデータの表現を送信してもよい。図３は、少なくとも幾つかの実施形態による、仮想化されたコンピューティング・サービスのインスタンス・ホスト１４４においてトラフィック分類メタデータを解釈することができるネットワーク・マネージャ・モジュールの実施例を例示する。インスタンス・ホスト１４４は、幾つかの異なるクライアント・アクセス可能バーチャル・マシンまたは計算インスタンス３５０、例えば、計算インスタンス３５０Ａおよび３５０Ｂをインスタンス化し管理することができる仮想化管理ソフトウェア・スタック（ＶＭＳＳ）３１０を含んでもよい。ＶＭＳＳ３１０は、例えば、ハイパーバイザー３１７、および、幾つかの実施において「ドメインゼロ」または「ドム０」と呼ばれるオペレーティング・システム３１５の管理インスタンスを有してもよい。ドム０オペレーティング・システムは、計算インスタンス３５０を実行しているクライアントによってアクセスすることができないが、計算インスタンス３５０への或いは計算インスタンス３５０からのネットワーク・トラフィックを扱うことを含む、仮想化されたオペレーティング・システムの様々な管理または制御面の動作に対して責任を担う。
図示する実施形態では、ドム０オペレーティング・システム３１５は、ネットワーク・マネージャ・コンポーネント３５７を含む様々な制御モジュールを含み、ネットワーク・マネージャ・コンポーネント３５７は分類メタデータ解釈部３５９を有する。ネットワーク・マネージャ・コンポーネントは、例えば、上述の分類ツリーおよび／または分類手順の表示を含む、インスタンス・ホスト１４４についてＮＣＳ１８０によって生成された分類メタデータを受信してもよい。解釈部３５９は、メタデータを解析し、様々な計算インスタンス３５０に或いは計算インスタンス３５０から方向付けられるトラフィックのパケットにメタデータに示される手順を適用し得る。例えば、様々なトラフィック・カテゴリーに対して帯域幅限界を実施するために、一つ以上のインスタンス・パケット・キュー（ＩＰＱ）３１９（例えば、ＩＰＱ３１９Ａおよび３１９Ｂ）が構成されてもよい。特定のインスタンス３５０における特定のカテゴリーの入来または出発トラフィック率が所与の時間間隔中に当該カテゴリーに対する帯域幅限界を超えると、入来または出発パケットの幾つかは当該特定のインスタンスに対するＩＰＱ３１９の待ち行列に入れられてもよい。幾つかの実施では、二つ以上のパケット・キューが所与の計算インスタンスに対してインスタンス化されてもよく、例えば、一つのトラフィック・カテゴリー当たり一つのパケット・キューがセットアップされてもよい。他の実施では、多数のインスタンス３５０と関連付けられるパケットを待ち行列に入れるには単一のパケット・キューで十分である。ＩＰＱまたは他の同様の構成は、様々な実施形態において、待ち時間要件、他のサービス品質の目標（例えば、異なるトラフィック・カテゴリーに対するネットワーク送信の相対的優先順位）、パケット・フラグメンテーション設定、または、パケット・サイズに依存する設定等の他のネットワーク構成オプションをＮＣＳから受信したメタデータに応じて実施するために使用されてもよい。
図示するように、各計算インスタンス３５０は、図示する実施形態において対応するクライアント・アクセス可能オペレーティング・システム３７０、例えば、計算インスタンス３５０ＡのＯＳ３７０Ａや計算インスタンス３５０ＢのＯＳ３７０Ｂを有してもよい。オペレーティング・システム３７０は、入来および出発トラフィックに対してインスタンス・ホスト１４４のハードウェア・ネットワーク・インターフェイスを使用するようネットワーク・マネージャ３５７と通信し得る、独自のネットワーク・スタック３７２（例えば、インスタンス３５０Ａのネットワーク・スタック３７２Ａおよびインスタンス３５０Ｂのネットワーク・スタック３７２Ｂ）をそれぞれ有してもよい。計算インスタンス３５０を実施するクライアントの視点からすると、各インスタンスは完全に機能的なサーバーに見え、クライアントは使用されているネットワーク構成技術の実施の詳細（例えば、ＩＰＱでパケットを待ち行列に入れる）を知らない場合もある。図３に示すのと同様の分類メタデータを解釈し使用する技術が、異なる実施形態において、様々なタイプのストレージ・サービスまたはデータベース・サービス等、他のタイプのネットワーク・アクセス可能な仮想化サービスのインスタンス・ホストにも使用されてもよいことに注意する。更に、幾つかの実施形態において、分類メタデータがＶＭＳＳ３１０のネットワーク・マネージャ３５７の代わりに、或いは、それに加えて、インスタンス３５０のネットワーク・スタック３７２で少なくとも部分的に解釈および／または使用されてもよいことに注意する。
メタデータ送信モード
ＮＣＳ１８０によって生成されたメタデータの表現は、異なる実施形態における異なるプロトコルまたは転送モードに応じて、インスタンス・ホスト１４４またはネットワーク装置１４５等のターゲットに供給されてもよい。図４ａ〜図４ｃは、少なくとも幾つかの実施形態による、インスタンス・ホストにトラフィック分類メタデータを送信するために使用され得るプロトコルの実施例をそれぞれ示す。一つ以上のプログラマチック・インターフェイスは、異なる実施形態においてインスタンス・ホストまたは分散システムの他のノードにメタデータを供給するために使用されてもよく、このときＮＣＳまたはメタデータの受信部のいずれかは、使用されるプロトコルに応じてインターフェイスを呼び出す。
図４ａに示す実施形態では、分類メタデータは、ＮＣＳ１８０によって開始されたスケジューリングされた「プッシュ」動作４０１を介してインスタンス・ホスト１４４に（または、ネットワーク装置１４５またはストレージ装置に）送られてもよい。例えば、各ＮＣＳはそれぞれスケジュールを有して構成されてもよく、ＮＣＳは該スケジュールに応じて所与のメタデータ・ターゲットに（例えば、一分間に一回、または、五分間に一回）メタデータを送る。幾つかの実施において所与のＮＣＳから異なるターゲットにメタデータが送られる実時間は、メタデータ転送自体によって生ずるネットワークの混雑を回避するようずらされる。例えば、メタデータが所与のＮＣＳから六つのインスタンス・ホストに一分間に一回プッシュされるべき場合、各インスタンス・ホストへのメタデータ送信は十秒間隔でスケジューリングされ得る。
図４ｂに示す実施形態では、トリガとなるイベントはメタデータの送信につながり得る。例えば、イベント検出部４２１が潜在的なＤＤＯＳ検出等のイベントが検出されたことをＮＣＳに通知し、ＮＣＳがイベントの影響を緩和するよう適当なメタデータを生成してもよい。あるタイプのイベントについては、イベントになるべく早く対応するよう、幾つかの実施形態では、メタデータが生成されるとすぐに、生成されたメタデータのトリガされたプッシュ４０２が高い優先順位で開始されてもよい。他のタイプのトリガとなるイベントに対して、例えば、管理者が先に生成されたメタデータを無効にするリクエストを出した場合、メタデータはすぐに或いは高い優先順位でプッシュされる必要がない。
図４ｃに示す実施形態では、インスタンス・ホスト１４４は、最近の分類メタデータについてＢＡ１８０にプル・リクエスト４０３を出し、メタデータは相応じて応答４０４でインスタンス・ホストに送られてもよい。様々な実施形態では、図４ａ乃至図４ｃに示す三つのアプローチ法のいずれかの組み合わせが、インスタンス・ホスト１４４に対して、ネットワーク装置１４５に対して、または、ストレージ装置に対して使用されてもよい。少なくとも一実施形態では、メタデータを送信する際に差分アプローチが使用されてもよく、つまり、現在のメタデータと最近供給されたメタデータとの間の差だけの表現がインスタンス・ホスト、ネットワーク装置、または、ストレージ装置に送られてもよい。他の実施形態では、メタデータ全体が各転送において送信されてもよい。
分類ツリー
図５は、少なくとも幾つかの実施形態による、分散システムの装置においてネットワーク構成に対するネットワーク・トラフィック・カテゴリーを表すために使用され得る分類ツリー・データ構造５０１の実施例を例示する。ツリー５０１の各ノードは、ノードによって表されるカテゴリーについて、図５における各ノードに対して例示されるそれぞれの帯域幅限界等のネットワーク構成オプションまたは設定の関連するセットを有してもよい。各ノードに適用され得るネットワーク構成オプションの他の実施例は、パケット待ち時間要件または目標、異なるトラフィック・カテゴリーの相対的優先順位等の他のサービス品質の目標、パケット・フラグメンテーション／再組立設定、または、パケット・サイズに依存する構成の設定を含み得る。トラフィック・カテゴリーは、異なる実施形態において様々な特性における差に基づいて定められ、例えば、トラフィックと関連付けられるアプリケーションのカテゴリー、コンポーネントが送信側または受信側にあるサービス、関連するエンドポイント（幾つかのケースでは、それ自体がアプリケーションのタイプを示す）のネットワーク・アドレス、転送のサイズ、トラフィックを生成したクライアント、互いに対するエンドポイントの場所（例えば、プロバイダ・ネットワーク・ノードからの出発パケットについては、宛先がローカル・データ・センター内、ローカル利用可能コンテナ、ローカル領域、プロバイダ・ネットワークの別の領域、またはプロバイダ・ネットワークの外部か否か）等に基づいて定められる。例示する分類ツリー５０１において、例えば、ノード５０４はアプリケーション（高性能計算）の一つのクラスに対するトラフィックを表し、ノード５２０はデータベース・トラフィックを表し、ノード５０６は高性能ブロック・ストレージ・トラフィック（即ち、高入力／出力速度を支持するよう構成されるブロック・ストレージ装置と関連付けられるトラフィック）を表す。ノード５２０によって表されるデータベース・カテゴリー内では、場所に基づくサブカテゴリーに対して三つのノード、即ち、データ・センター間トラフィックに対するノード５２２、領域間トラフィックに対するノード５２４、および、余剰領域トラフィックに対するノード５２６が定められる。
様々なカテゴリーに対して定められるネットワーク構成オプションが帯域幅限界を含む実施形態では、様々な種類のトラフィック総和ポリシーまたはルールが分類ツリーに適用され得、それにより、親ノードに対する子ノードの帯域幅限界の間の関係に影響が与えられる。例示する実施例では、以下のルールが当てはめられる：（ａ）ツリーにおけるどの子ノードもその親の帯域幅限界を超える帯域幅限界を有さない、および、（ｂ）親ノードの子ノードの帯域幅限界の総和が親の帯域幅限界を超えたとしても、子ノードによって表されるカテゴリーに対する実際のトラフィック率の総和はどの所与の時間期間中にも親の帯域幅限界を超えてはならない。
これらのルールによると、ルート・ノード（分類グラフが生成されるインスタンス・ホストまたはネットワーク装置に対して定められた全てのトラフィック・カテゴリーを総称的に表す）がＫ Ｇビット／秒の帯域幅限界を有するため、ルート・ノードのどの子ノードもＫ Ｇビット／秒よりも大きい帯域幅限界を有さず、Ａ＜Ｋ、Ｂ＜Ｋ、Ｃ＜Ｋ、および、Ｄ＜Ｋとなる。ノード５２０の場合、子ノード（ノード５２２、５２５、および、５２６）の帯域幅限界は、総和が親ノードの帯域幅限界となるよう割り当てられるため、上述の両方のルールが満たされる。Ｄ Ｇビット／秒の帯域幅限界を有する包括的な「他の」トラフィック・カテゴリーを表すノード５３０の場合、子ノード５３２（他のブロック・ストレージ・トラフィック）、５３４（インターネット・トラフィック）、５３６（イントラサービス・トラフィック）、および、５３８（どの他のリーフ・ノードによっても表されない雑または未分類トラフィック）それぞれもＤ Ｇビット／秒の帯域幅限界を有する。子ノードに対する公称帯域幅限界の総和が（この場合４Ｄ Ｇビット／秒）が親ノード（Ｄ Ｇビット／秒）の帯域幅限界を超えるこのようなシナリオは、上述の第二のルールに応じて以下のように解釈され得る。原則としては、子ノードのカテゴリーそれぞれがＤ Ｇビット／秒までのトラフィック率を有することができるが、実際には、どの所与の一秒（または他の適当な時間単位）中にも、全ての子ノードの実際のトラフィック・フローの総和はＤ Ｇビット／秒を超えてはならない。そのため、特定の一秒中「他のブロック・ストレージ・トラフィック」（ノード５３２）といったカテゴリーに対するトラフィック率が０．６Ｄ Ｇビット／秒の場合、ノード５３４、５３６、および、５３８に対するトラフィック率は合わせて０．４Ｄを超えてはならない。
幾つかの実施形態では、それぞれのツリーは所与のインスタンス・ホストまたはネットワーク装置において入来および出発トラフィックに対してＮＣＳ１８０によって生成されてもよく、ネットワーク構成オプションおよび／またはカテゴリーにおいて入来トラフィックに対するツリーは出発トラフィックに対するツリーと異なってもよい。幾つかの実施形態では、分類ツリーの幾つかの或いは全てのノードに関して、持続的帯域幅（例えば、Ｔ秒を超える時間期間にわたって平均的帯域幅使用に適用される）、および、バースト帯域幅（例えば、所与のインスタンス・ホストに対して持続的帯域幅限界が１Ｇビット／秒に設定されているが４Ｇビット／秒の短期間バースト・トラフィック率が当該インスタンス・ホストに対して二秒まで許される）に対して異なる限界が定められてもよい。前述の通り、幾つかの実施では、所与のインスタンス・ホスト、ネットワーク装置、またはストレージ装置に対するトラフィック分類階層は、多数の層を有する代わりに平坦でもよい。
幾つかのシナリオでは、分散システムの異なるエンティティの分類ツリーを高次ツリーに組み合わせることが管理的視点から有用となり得る。図６は、少なくとも幾つかの実施形態による、データ・センターにおいて複数のインスタンス・ホストのネットワーク・トラフィック・カテゴリー情報を組み合わすために使用され得る階層型データ構造６０１の実施例を例示する。図示するように、Ｃツリー６０１Ａ、６０１Ｂ、６０１Ｍ、および、６０１Ｎ等、それぞれの分類ツリー（Ｃツリー）が多数のインスタンス・ホストに対してデータ・センターにおいて生成され得る。データ・センターは、図示する実施形態において幾つかの異なるルームに配置される複数のサーバー・ラックを有する。ＮＣＳは、所与のラックに組み込まれるインスタンス・ホストのＣツリーを統合して６０３Ａおよび６０３Ｂ等のラックレベルのＣツリーを形成する。統合の次のレベルでは、データ・センターの所与のルームまたはサブセットにおける全てのラックに対するラックレベルＣツリー６０３が例えば、ルームレベルＣツリー６０５Ａまたは６０５Ｂの形態で組み合わされてもよい。幾つかの実施形態では、ルームレベルのツリーを組み合わせることで、全体として単一の合成ツリー６０７がデータ・センターに対して形成されてもよい。全体として利用可能コンテナ、地理的領域、または、プロバイダ・ネットワークのレベルにおける等、より高レベルのツリー階層が幾つかの実施形態で構成され得る。
このような合成ツリー階層は、幾つかの方法で、特に、階層のカスマタイズ可能な視覚表示がプログラムで（例えば、統一コンソール・サービスを介して）利用可能にされた実施においてネットワーク構成システムやプロバイダ・ネットワークの管理者を補助する。データ・センターまたはプロバイダ・ネットワークの異なる部分における帯域幅使用の均一性または不均一性の概要は、このような階層を用いて得られ、これは、構成または配置の変化につながってネットワーク利用レベルを改善するまたはバランスを取る。トラフィックの異なるカテゴリー間の利用可能な帯域幅の分散もより高レベルの階層を検査することでより明確になり、これは、プロバイダ・ネットワークの収益の改善を補助する価格変化を行う際に助けとなる（例えば、より普及しているカテゴリーに関連するトラフィックの価格上昇）。配置サービスも、例えば、新しいサービス・インスタンスに対して適当なインスタンス・ホストを選択する際に助けとなるラックレベルの帯域幅使用を確定することで、高レベルのツリー階層から恩恵を受ける。
分類手順グラフ
上述の通り、少なくとも幾つかの実施形態では、ネットワーク構成サーバーは、所与のインスタンス・ホストまたはネットワーク装置に対して定められたカテゴリーにパケット等のネットワーク・トラフィック単位を分類するために使用され得る手順のステップまたはルールを確定してもよい。図７は、少なくとも幾つかの実施形態による、ネットワーク・トラフィックの単位のカテゴリーを確定するために分類ツリーと一緒に使用され得るトラフィック手順グラフ７５０の実施例を例示する。グラフ７５０は、複数の決定ノードを有し、各ノードにおいてネットワーク・トラフィックに対する分類基準のそれぞれのセットが示される。少なくとも幾つかの実施形態では、少なくとも決定ノードのサブセットがシーケンスに配置されてもよく、該シーケンスの連続するノードは連続して狭くなるカテゴリーに対応する。例えば、ノード７０１、７０２、および、７０３のシーケンスでは、ノード７０１に示される基準と一致するトラフィックのサブセットはノード７０２に示される基準と一致してもよく、ノード７０２に示される基準と一致するトラフィックのサブセットはノード７０３に示される基準と一致してもよい。ネットワーク・トラフィックの所与の単位がシーケンスの最後のノードの基準に一致しない場合、当該トラフィック単位は異なるシーケンスを用いて評価され得る。例えば、パケットがノード７０１および７０２の基準に一致する（ノード７０１および７０２に対して「はい」の結果によって示される）が、ノード７０３に示される基準と一致しない（ノード７０３に対して「いいえ」の結果によって示される）場合、パケットはノード７０４および７０５のシーケンスを用いて評価される必要がある。
一般的に、所与のトラフィック単位がノードの所与のシーケンスの基準全てと一致する場合、そのカテゴリーが確定され得る、例えば、ノード７０１、７０２、および、７０３の基準が満たされる場合にはカテゴリーＣ１パケットとして分類され、ノード７０７および７０８の基準が満たされる場合にはカテゴリーＣ６パケットとして分類され、ノード７０６の基準が満たされる場合にはカテゴリーＣ５パケットとして分類され、または、ノード７０９の基準が満たされる場合にはカテゴリーＣ７パケットとして分類される。所与のノードにおいて示される基準は、異なる実施形態においてネットワーク・トラフィック単位の様々な特性に関して表されてもよい。例えば、ソースまたは宛先ＩＰアドレス、ポート番号、または、使用されるネットワーク・プロトコル等のパケットの一つ以上のヘッダのコンテンツがそのカテゴリーを確定するために使用されてもよく、またはボディのコンテンツが使用されてもよい。所与のトラフィック単位が手順を用いて分類されるカテゴリーそれぞれは、図示する実施形態においてＮＣＳによって生成される分類ツリーの対応するノードに対応してもよい。
少なくとも原則としては、少なくとも幾つかの実施形態ではパケット分類のために任意に細かい基準が使用されてもよく、決定ノードの任意に長いシーケンスが生成されてもよい。例えば、分類基準は、パケット・ボディの非常に特定的なコンテンツ（パケットのオフセットＯ１で特定のバイトレンジ「０ｘｆｆ」が生じるか）、または、パケットまたはヘッダ・コンテンツの任意の組み合わせ等に基づいてもよい。分類手順グラフ７５０のサイズおよび複雑性を減少させるために、多数の可能な結果を有する決定ノードが幾つかの実施形態において使用されてもよい。例えば、手順グラフ７５０では、ルックアップ・テーブル７７０を有するノード７０５が含まれる。このようなルックアップ・テーブルそれぞれは、複数の行を有し、その中から所与のトラフィック単位（例えば、パケットの宛先ＩＰアドレス）の特性に基づいて一行がインデックス付けされるまたは選択されて、分類の決定が達せられる。ノード７０５の実施例では、分類の決定とは、パケットがカテゴリーＣ２、Ｃ３、または、Ｃ４に属するか否かである。他の場合では、分類の決定は、決定ノードの追加的なシーケンスを用いてパケットを評価することであり、例えば、ルックアップ・テーブル・エントリーが他の分類グラフまたはサブグラフへのポインタとして機能してもよい。
図８は、少なくとも幾つかの実施形態による、トラフィック分類手順グラフのルックアップ・テーブル・ノード８０５の使用の実施例を例示する。図示する実施形態では、パケットをカテゴリー化するために使用されるべきノード８０５のルックアップ・テーブル７７０Ａのエントリーを識別するよう、ネットワーク・パケット８１０の一部分にハッシュ関数８５０が適用されてもよい。ルックアップ・テーブル８０５は、幾つかの場合では、それ自体が手順の他の決定ノードの評価後に到達され得、即ち、少なくとも幾らかのレベルのカテゴリー化がハッシュ関数８５０の適用前にパケット８１０に対して既に行われていてもよい。図示する実施例におけるパケットは宛先ＩＰアドレス「Ｐ．Ｑ．Ｒ．Ｓ」８０１を有するアウトバウンド・パケットであり、宛先ＩＰアドレスの四つの要素のうちの第三の要素「Ｒ」がハッシュ関数８５０への入力として使用されて、パケット８１０に対応するルックアップ・テーブルのエントリーが確定される。例えば、宛先ＩＰアドレスまたはソースＩＰアドレスの他の部分の値、他のヘッダ・フィールド８０２の値、または、パケットのボディ８０３のコンテンツさえも含む、パケット８１０の幾つかの特性のいずれもが、様々な実施形態においてハッシュ関数への入力として使用され得る。ルックアップ・テーブルのエントリーを選択するためにパケットのどの特性が使用されるべきかに関するルール、および、特性に適用されるべき関数（例えば、ハッシュ関数８５０）は、幾つかの実施形態において、インスタンス・ホストまたはネットワーク装置等のターゲット装置における制御モジュールにＮＣＳ１８０による分類メタデータと一緒に供給されてもよい。
幾つかのケースでは、（例えば、宛先ＩＰアドレス要素のハッシュ法の結果として）選択されたルックアップ・テーブルのエントリーが対応するパケットのトラフィック・カテゴリーを直接示してもよい。例えば、ルックアップ・テーブル７７０Ａの要素のうちの一つを選択することは、図８におけるカテゴリーＡにつながる。ルックアップ・テーブルの他のエントリー自体も図８のグラフ８８０Ａおよび８８０Ｂのような追加的な手順グラフへのポインタとして機能し、その決定ノードはパケット８１０のカテゴリーを確定するためにナビゲートされなくてはならない。異なるグラフのノードから評価される基準の結果として到達される追加的な手順グラフは、本願ではサブグラフとも呼ばれる。図示する実施例では、決定ノード８５１、８５２（それ自体ルックアップ・テーブル７７０Ｂを有するノード）および／または８５３によって示される基準はハッシュ関数８５０が７７０Ａの一つのエントリーにつながる場合には評価される必要があり、決定ノード８５４、８５５、および／または、８５６によって示される基準はハッシュ関数８５０がルックアップ・テーブル７７０Ａの異なるエントリーの選択を結果とする場合には評価される必要がある。手順グラフ８８０Ｂが到達され、要素８５４および８５５に示される基準が満たされると、例えば、パケット８１０は図８の実施例においてトラフィック・カテゴリーＬに属すると考えられる。分類手順グラフ７５０の様々なノードにルックアップ・テーブル７７０を組み込むことで、複雑で細かい論理が分類に使用されたとしてもトラフィック分類の論理の比較的コンパクトな表現が可能となる。
トリガとなるイベントへのネットワーク構成システムの応答
幾つかの実施形態では、前述の通り、ネットワーク攻撃や侵入等の潜在的に損害を与えるイベントの検出等のイベントに応答して、帯域幅管理の決定がなされてもよい。ネットワーク構成システムを構成する際、例えば、分散システムの特定のサブセットに幾つのＮＣＳがセットアップされるべきかを決定する際、または、どのタイプの計算能力およびメタデータ分散能力がネットワーク構成システムに必要かを決定する際に考慮され得る要素の一つがこのようなイベントへの所望の応答となり得る。図９は、少なくとも幾つかの実施形態による、ネットワーク構成サービスの一つ以上のパラメータに対する値を確定するために利用され得る応答メトリックの実施例を例示する。
時間値が左から右に増加する、模範的な時系列が図９に示される。ブロック９０２に示されるように、時間Ｔ１において、中央化ネットワーク構成が実施される分散システムのセキュリティ・サービスがＤＤＯＳ攻撃等の潜在的なネットワーク攻撃が検出される。起こり得る攻撃は、例えば、分散システムの一つ以上のノードにまたは一つ以上のノードから方向付けられるトラフィック率における急な増加に基づいて識別されてもよい。このような攻撃は、分散システム内（例えば、プロバイダ・ネットワークの計算インスタンスのセットを用いて実施されている電子ビジネスのウェブサイト）、または、分散システムの外部（例えば、繰り返されるリクエストがプロバイダ・ネットワークの計算インスタンスのセットから外部のウェブサイトに高い率で送られてもよい）の一つ以上のターゲットにおいて方向付けられてもよい。幾つかのケースでは、トラフィックの増加は、ウェブサイト上でのセール商品に対する急な関心といった正当な理由によるものの場合もあるが、多くの実施形態では、セキュリティ・サービスがこのような誤判定の確率を低減させるよう高度な分析技術を使用してもよい。
潜在的な攻撃が本当に攻撃か否かに関わらず、ネットワーク構成システムは、図示する実施形態において、例えば、分散システムの適当なノードに対する帯域幅限界等、新しい分類メタデータおよび／または新しい構成オプションを生成し、新しいメタデータをなるべく早く適用することで、応答するよう構成され得る。ブロック９０４によって示されるように、図示する時系列の時間Ｔ２において、ノードのセットに対する変更されたメタデータが生成されてもよい。例えば、ＩＰアドレスＫ．Ｌ．Ｍ．Ｎから発生されＩＰアドレスＥ．Ｆ．Ｇ．Ｈで方向付けられるアウトバウンドＤＤＯＳ攻撃を表すトラフィックが検出されると、これらのＩＰアドレスに対して帯域幅限界を適用する責任を担うＮＣＳは新しいメタデータを生成してもよい。例えば、新しいメタデータは、Ｋ．Ｌ．Ｍ．Ｎから発生されるまたはＥ．Ｆ．Ｇ．Ｈで受信される全てのトラフィックに対して単に新しい帯域幅限界を（少なくとも一時的に）課してもよい。代替的には、一つ以上の新しいトラフィック・カテゴリーが、具体的には、Ｋ．Ｌ．Ｍ．ＮからＥ．Ｆ．Ｇ．Ｈに流れるトラフィックに対して定められてもよく、これら特定のカテゴリーに対する帯域幅限界が生成され広められてもよい。
ブロック９０６によって示されるように、図９の模範的な時系列における時間Ｔ３において、変更された分類メタデータは、適当なインスタンス・ホストまたは他のノードに分散され、実施されてもよい（幾らかの時間の後、例えば、ネットワーク攻撃が終了した場合か攻撃を示したトラフィックが正当と分かった場合、分類メタデータは再び変更されてもよい）。例えば、間隔（Ｔ３乃至Ｔ１）によって示されるように、トリガとなるイベントへのネットワーク構成サービスの応答は、例えば、ネットワーク構成サービス・マネージャ２２２によって時間とともに追跡され、使用されるＮＣＳの数またはメタデータの分散システムの様々な特性を調節するために使用されてもよい。
中央化ネットワーク構成サービスを実施する方法
図１０は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施される動作の態様を例示するフロー図である。要素１００１に示されるように、サービスの様々な初期またはデフォルトのパラメータが、例えば、グローバル帯域幅管理ポリシー、ネットワーク構成が実施されるサービスの利用可能性および／または性能要件を考慮して、確定されてもよい。このようなパラメータは、例えば、各利用可能コンテナまたは各データ・センターに構成されるべきＮＣＳ１８０の数、メタデータ搬送スケジュールおよびプロトコル（例えば、ＮＣＳがメタデータ転送を開始するプッシュ・プロトコルがデフォルトとして使用されるべきか否か、または、インスタンス・ホストが必要に応じて分類メタデータをリクエストするプル・プロトコルが使用されるべきか）、メタデータ転送をもたらす追加的なトリガとなるイベントのタイプ、ＮＣＳへの入力ソースおよび／またはＮＣＳの決定の結果が供給される出力の宛先を含んでもよい。
少なくとも幾つかの実施形態では、プログラマチック・インターフェイスのセットが実施されてもよく（要素１００４）、それによりクライアントおよび／または管理者はＮＣＳの決定を選択的に無効にすることができる。例えば、一実施形態では、幾らかのクライアントは、（例えば、アプリケーション・ワークロード・レベルにおける予想増加に基づいて）ＮＣＳによって選択される帯域幅限界を超えて様々な帯域幅限界を増加させるリクエストを出す、または、（例えば、トラフィック関連の請求金額を下げるよう）ＮＣＳが確定する帯域幅限界より下となるようトラフィックのあるカテゴリーに対する帯域幅限界を制限するリクエストを出すことができる。様々な他のタイプのオプションに対するクライアントおよび／または管理者からの構成リクエストも、待ち時間関連の設定、サービス品質の設定等のためにサポートされてもよい。
要素１００１に対応する動作において確定されるパラメータに応じて、適当な数のＮＣＳ１８０が選択された場所でインスタンス化されてもよい（要素１００７）。ネットワーク接続はＮＣＳと分散システムまたはプロバイダ・ネットワークの様々な他の要素との間に確立されてもよく（要素１０１０）、例えば、ＮＣＳとＮＣＳによる決定が実施されるインスタンス・ホスト１４４および他のネットワーク装置１４５との間、ＮＣＳとＮＣＳの決定に影響を及ぼす入力データ・ソースとの間、および、ＮＣＳと継続的にＮＣＳからネットワーク情報を取得することに関心のある全ての出力宛先との間で確立される。少なくとも幾つかの実施形態では、ＴＬＳ（トランスポート層セキュリティ）やＳＳＬ（セキュア・ソケット層）等の安全なネットワーク・プロトコルがＮＣＳと分散システムの少なくとも幾つかの他の要素との間のネットワーク接続のために使用されてもよい。
図１１は、少なくとも幾つかの実施形態による、ネットワーク構成サービスのトラフィック分類メタデータを生成し分散するために実施され得る動作の態様を例示するフロー図である。図示する実施形態では、ＮＣＳは反復アプローチを用いてもよく、各反復中、入力のセットがターゲット・ノード（例えば、インスタンス・ホスト）のセットに分散され適用されるネットワーク管理パラメータを確定するために使用され、メトリックスがターゲット・ノードや他のソースから収集され次の反復に対するパラメータに影響を与えるまたはパラメータを確定するよう入力としてフィードバックされる。要素１１０１に示されるように、所与の時間間隔中、所与のＮＣＳは、インスタンス・ホストおよび／またはスイッチ、ルーター、ゲートウェイ等のネットワーク装置を含む分散システムの様々なノードから取得されるネットワーク関連メトリックスのセットを受信してもよい。例えば、測定された入来／出発トラフィック率、パケット損失率、パケット制限率等を含み得るこのようなメトリックスは、ＮＣＳによるトラフィック分類メタデータの次の反復を生成するために使用され得る。幾つかのケースでは、メトリックスは、例えば、健康管理サービスのノードのようなメトリックス収集システムのノードを介してＮＣＳに供給されてもよい。更に、ＮＣＳは、図示する実施形態において、セキュリティ関連のサービス、ＩＰアドレス毎のトラフィック集合部、クライアント毎のトラフィック集合部等を含む他の入力ソースから様々な入力を取得してもよい。クライアントおよび／または管理者は、ＮＣＳによって一つ以上のトラフィック・カテゴリーに先に適用された帯域幅限界を増加または低減させるためのリクエスト等の構成リクエストをＮＣＳに要請してもよく、このような構成リクエストはトラフィック分類メタデータの次の反復を確定する際に入力として使用されてもよい。
ＮＣＳにおいて、メトリックスや受信した入力は、例えば、グローバルおよび／またはローカル・ネットワーク管理ポリシーを考慮して、図示する実施形態においてトラフィック分類メタデータを確定するために使用されてもよい（要素１１０４）。グローバル・ポリシーは、例えば、ネットワーク・インフラストラクチャの様々な部分のターゲット利用限界、同様のレベルのサービスに登録した異なるクライアントからのトラフィックを扱うための公平要件、実施される異なるネットワーク・アクセス可能サービスに対してネットワーク・トラフィックに与えられるべき相対的優先順位等を示してもよい。ローカル・ポリシーは、例えば、ネットワーク・インフラストラクチャや能力が他の利用可能コンテナまたはデータ・センターのネットワーク・インフラストラクチャや能力と異なる、所与の利用可能コンテナまたは所与のデータ・センターで適用されるルールを示してもよい。分散システムの所与のターゲット・ノードに対して生成された分類メタデータは、ターゲット・ノードで使用されるべきトラフィック分類階層（例えば、図５に示す構造と同様のツリー・データ構造において表される階層）、および、階層において定められるカテゴリーにネットワーク・トラフィックの単位を分類するために使用されるべき手順またはルールのセット（例えば、図７に示すグラフと同様のグラフを用いて表すことができる手順）を含んでもよい。階層において定められる各トラフィック・カテゴリーに対して、例えば、平均的トラフィックに対して定められる帯域幅限界および短期間バーストに対して定められる異なる帯域幅限界、待ち時間要件、パケット・サイズに依存する要件、または、優先順位設定を含む帯域幅限界等の対応するネットワーク構成オプションが一つ以上確定されてもよい。幾つかのケースでは、カテゴリーおよび／またはオプションのそれぞれのセットが入来／出発トラフィックに対して定められてもよい。少なくとも幾つかの実施形態では、分類階層および／または手順は、異なるインスタンス・ホストおよび／またはネットワーク装置に対してカスタマイズされてもよく、例えば、一つのセットのクライアント・アプリケーションに対して使用される所与のホストＨ１は、異なるセットのクライアント・アプリケーションが実施される別のホストＨ２とは定められるトラフィック・カテゴリーが異なり、当該カテゴリーに課せられる帯域幅限界が異なる。
トラフィック分類階層および分類手順のそれぞれのポータブルな表現または符号化は、図示する実施形態では、ターゲット・ノードへの送信のためにＮＣＳにおいて生成され得る（要素１１０７）。ＪＳＯＮ、ＸＭＬ、ＹＡＭＬ等の業界標準プロトコルまたは言語が幾つかの実施において使用され、独自の符号化スキームが他の実施において使用されてもよい。ポータブルな表現は、メタデータが適用されるか使用されるべきターゲットに送信される（要素１１１０）。少なくとも一つの実施において、単一のまたは組み合わされた符号化が分類カテゴリーおよび手順の両方に対して使用され、他の実施において、分類カテゴリーおよび手順のそれぞれの別個の表現が使用されてもよい。幾つかの実施形態では、例えば、先の反復から変更されたメタデータの部分だけがターゲットに送信される差分メタデータ送信技術が使用され得る。他の実施形態では、メタデータ全体が各反復において送信される完全送信アプローチ法が使用され得る。様々な実施形態では、スケジューリングされたプッシュ送信（メタデータがターゲットにＮＣＳ主導でプッシュされる）、プル送信（ＮＣＳがターゲットからのリクエストに応じて分類メタデータを送信する）、および、イベントにトリガされたメタデータ送信（あるタイプのイベントを検出すると、ＮＣＳがメタデータを生成しおよび／または送信する）の組み合わせが使用されてもよい。所与の反復に対するメタデータが適当なターゲットに送られた後、ＮＣＳは、例えば、要素１１０１以降に対応する動作を繰り返すことで次の反復を開始する。
分散システムのターゲット・ノードでは、制御モジュール（例えば、図３に示すネットワーク・マネージャ３５７等）はメタデータ表現を受信し解釈するよう構成され得る。メタデータは、パケット等のネットワーク・トラフィックの単位を分類し、対応する帯域幅限界を適用してトラフィック単位の送信をスケジューリングするおよび／または制限するために使用され得る（要素１１１３）。幾つかの実施では、ノードで既に利用可能な「ｔｃ」等のオペレーティング・システム・ユーティリティまたはツールがＮＣＳによって生成された論理を実施するために使用されてもよい。他の実施では、カスタム・ツールまたはユーティリティが使用されてもよい。メトリックスは、例えば、様々な性能ツール等を用いてターゲット・ノードから収集され、ＮＣＳへの入力として使用されてもよい。
図１２は、少なくとも幾つかの実施形態による、トリガとなるイベントに応答してネットワーク管理パラメータを変更するよう実施され得る動作の態様を例示するフロー図である。要素１２０１に示されるように、潜在的なＤＤＯＳ攻撃等、トラフィック分類メタデータに対する変更を結果としてもたらすイベントが検出され得る。幾つかの実施形態では、プロバイダ・ネットワークは一つ以上のセキュリティ・サービスを確立して様々な種類の起こり得る攻撃を示す疑いのあるトラフィック・パターンを識別してもよい。このようなサービスはネットワーク構成システムと通信されてもよい。攻撃によって影響を与えられるまたは攻撃に寄与する分散システムの特定のノード（例えば、インスタンス・ホストおよび／またはスイッチ、ルーター等のネットワーク装置）は、図示する実施形態では、例えば、セキュリティ・サービス、ＮＣＳ、または、セキュリティ・サービスとＮＣＳの組み合わせのいずれかにより識別される（要素１２０４）。
トラフィック分類メタデータの変更されたセットは、攻撃の影響を緩和するようＮＣＳで生成される（要素１２０７）。変更は、例えば、（例えば、疑いのあるトラフィックを送信するおよび／または受信することに関わる特定のノードのアドレスに基づいて）定められるトラフィックの新しいカテゴリー、および／または、適用されるべき新しい帯域幅限界または他のネットワーク構成オプションを含み得る。続いて、新しいメタデータは、幾つかの実施形態において、攻撃に関連するまたはターゲットとされる特定のノードおよび／または他のノード（例えば、疑いのあるトラフィックが通る路に沿った中間物であるネットワーク装置）を含み得る、分散システムのノードの選択されたセットに送信されてもよい。
トリガとなる状態に応答するのにかかる時間、例えば、状態の検出と新しいメタデータの適用との間の間隔が測定され、記録される（要素１２１０）。このようなトリガとなるイベントへのネットワーク構成システムの応答における傾向および／またはネットワーク構成システムがとる動作の有効性が、時間とともに分析され、構成を変化させる必要があるか否かが確定される（要素１２１３）。応答が不十分とされた場合、例えば、任意の数の構成変化が行われる。例えば、検出されたイベントにより有効的に応答するよう、ＮＣＳの数が増加される、イベント検出部とＮＣＳとの間の接続性が改善される、メタデータ分散システムが向上される、および／または、ＮＣＳまたはターゲット・ノードでの論理が変更される。
図１３は、少なくとも幾つかの実施形態による、分散システムのクライアントにネットワーク関連のステータス情報の統一ビューを提供するよう実施される動作の態様を例示するフロー図である。要素１３０１に示されるように、一つ以上のプログラマチック・インターフェイス（例えば、ウェブページまたはコンソール、ＡＰＩ、ＧＵＩ、または、コマンド・ライン・ツール）は、関心のある様々な分散システム資源のネットワーク・ステータスの統一されたカスタマイズ可能なビューをクライアントに提供するよう確立されてもよい。例えば、クライアントは、仮想化されたコンピューティング・サービスの多数の計算インスタンスが割り当てられてもよく、最後の１５分間でどの特定のインスタンスが帯域幅の制限に影響されたかを知りたいと望む場合がある。プログラマチック・インターフェイスにより、クライアントは様々なフィルタを使用して表示されるべきネットワーク特性および／または特性が表示されるべき資源のセットを特定し得る。
ネットワーク・ステータス・リクエストがインターフェイスを介して受信され、関心のあるメトリックスおよび資源が示される（要素１３０４）。ネットワーク構成システムは、例えば、メトリックス・データベース１９０（要素１３０７）から、または、ＮＣＳにおけるキャッシュからリクエストされたメトリックスを引き出してもよい。幾つかの実施形態では、リクエストに応答する際に有用となり得る適用可能な分類メタデータも分類データベース１９２（要素１３１０）またはＮＣＳにおけるメタデータ・キャッシュから引き出されてもよい。収集された情報を用いて、ネットワーク・ステータス・リクエストに対する応答が生成され、プログラマチック・インターフェイスを介してリクエスタに供給される（要素１３１３）。
ネットワーク・トポロジーに対する資源使用の可視化ツール
上述した通り、ネットワーク構成サービスはプロバイダ・ネットワークのような分散システムの様々なコンポーネントから様々なメトリックスを収集し、これらのメトリックスを用い、少なくとも幾つかのノードに対して帯域幅限界等の設定を確定する。少なくとも一つの実施形態では、性能インジケータまたは資源使用インジケータ（例えば、様々なノードでのそれぞれの測定されたネットワーク・トラフィック率とこれらのノードに対して設定されたそれぞれの帯域幅限界との間の比の色分けされた表現またはヒートマップ）を表示することができる一つ以上の可視化ツールが実施されてもよい。一実施形態によると、資源ヒートマップおよび／または他のタイプの可視化を提供するよう構成されるネットワーク・トポロジー可視化サーバーは、ネットワーク構成サーバー１８０のサブコンポーネントとして実施されてもよい。他の実施形態では、ネットワーク・トポロジー可視化ツールは、ネットワーク構成サーバー１８０とは独立して実施されてもよく、例えば、分散システムの別の中央化サービスとして、または、単独型エンティティとして実施されてもよく、ＮＣＳ１８０と相互に作用する或いはＮＣＳ１８０によって収集されたデータを消費し得る。少なくとも幾つかの実施では、統合ネットワーク・ビュー生成部１５２（図１に示す）は、その特徴の一つとしてトポロジー可視化インターフェイスを含み得る。
中央化トポロジー可視化サーバー（ＴＶＳ）は、少なくとも幾つかの実施形態において分散システムの様々なノード間の論理的および／または物理的関係を確定するよう構成されてもよい。例えば、仮想コンピューティング・サービスが実施される実施形態では、ＴＶＳは、インスタンス・ホストのセットで様々な計算インスタンスが割り当てられるクライアント・アカウントを確定し、アカウント情報を使用して特定のクライアント・アカウントまたはクライアント・アカウントの選択されたセットに割り当てられた計算インスタンスだけを含むトポロジーを生成してもよい。当該クライアント・アカウント（またはアカウントのセット）と関係するクライアントからの可視化リクエストに応答して、当該トポロジーのインスタンスに対する性能インジケータを示すヒートマップが提供されてもよい。一つ以上のデータ・センターで実施されるネットワーク・アクセス可能サービスの管理者に対して、様々なインスタンス、ホストおよび／またはスイッチ、ルーター等のネットワーク装置間の物理的または論理的ネットワーク・リンクを示し得る、より詳細なトポロジーが生成され、サービスの非管理クライアントには典型的にはアクセス可能でない情報を用いて対応するヒートマップが生成され得る。各ケースにおいて、クライアントまたは管理者には、生成されたヒートマップを用いて、様々なタイプの資源の使用統計の理解しやすい視覚表示が提供されてもよい。続いて、使用統計が使用されて、例えば、潜在的な障害または他のタイプの問題が積極的に特定されて、応答作用が行われる。ヒートマップに表示される色の範囲、および、色間の遷移境界は、示されるメトリックのレベルを示すために選択可能である。例えば、一実施では、最近測定されたトラフィック率が当該ノードに対する帯域幅限界に非常に近いことを示すようネットワーク・トポロジーの所与のノードに対して赤色が表示され、測定されたトラフィックが限界をはるかに下回ることを示すよう緑色が使用され、赤から緑への遷移色がトラフィックの中間レベルに対して使用されてもよい。
幾つかの実施形態によると、ＴＶＳは、分散システムにおける様々なソースからメトリックスの集まりを取得し、分散システムの様々なコンポーネントについて関係情報を取得し、収集されたメトリックスおよび関係情報に基づいて様々なタイプのネットワーク・トポリジーについて性能インジケータ（例えば、個別性能メトリックス、または、適用可能な限界へのメトリックスの比）を確定する責任を担う。クライアントまたは管理者が資源性能インジケータのカスタマイズされたまたはフィルタリングされた可視化をリクエストすることを可能にするプログラマチック可視化インターフェイスが実施されてもよく、ＴＶＳはデータ・セットの適当なサブセットを用いて性能インジケータのヒートマップおよび／または他のグラフィカル表現を合成することで可視化リクエストに応えてもよい。幾つかの実施では、一つ以上のこれらタスクは、以下により詳細に説明するように、分散システムの他のコンポーネントまたはサービスとの相互作用を伴い得る。
図１４は、少なくとも幾つかの実施形態による、分散システムの少なくともノードのサブセットについてトポロジー可視化サーバー（ＴＶＳ）１４１０によって生成され得るカスタマイズ可能なヒートマップ１４５０の実施例を例示する。図示する実施形態では、ＴＶＳはネットワーク構成サーバー１８０の構成要素として実施される。他の実施形態では、ＴＶＳ１４１０は、ＮＣＳとは独立した或いはＮＣＳの外部の一つ以上のハードウェアまたはソフトウェア・コンポーネントを用いて実施されてもよく、例えば、中央化可視化サービスは幾つかのこのような実施形態ではＮＣＳが不在の状態で実施されてもよい。ＴＶＳ１４１０は、アカウント管理サービス１４２０、配置サービス１５１、在庫サービス１４３０、並びに、メトリックス・コレクタ１２５を含み、図１４に示す実施形態における幾つかのタイプのデータ・ソースからの入力を取得してもよい。
アカウント管理サービス１４２０は、一つ以上のマルチテナントまたはシングルテナント・サービス・インスタンス（例えば、仮想化されたコンピューティング・サービス、ストレージ装置、または、データベース・サービス）の様々なサービス・インスタンスが割り当てられるクライアント・アカウント（および／または関係するユーザまたはグループ・アカウント）に関する情報をＴＶＳ１４１０に供給してもよい。前述の通り、配置サービス１５１は、様々なサービス・インスタンスが立ち上げられるインスタンス・ホストを特定する責任を担うため、ネットワーク・トポロジーを生成する上で有用となるインスタンス−ホスト・マッピングを少なくとも幾つかの実施形態において提供することができる。在庫サービス１４３０は、一つ以上のデータ・センター内のどこに様々なインスタンス・ホスト、スイッチ、ルーター、および、分散システムの他の機器部品が物理的に位置しているかを記録するデータベースを管理してもよい。図１の文脈で前述した通り、メトリックス・コレクタ１２５は、分散システム内の様々なサービス・インスタンス、ホスト、ネットワーク装置等からネットワーク関連および／または他の資源のメトリックスを集めてもよい。例えば、ネットワーク関連のメトリックスについて、ソースは中でも（ａ）ネットワーク・インターフェイス・カード、（ｂ）仮想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポーネント、（ｃ）計算インスタンスのネットワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（ｆ）ルーター、（ｇ）ゲートウェイ、または（ｈ）ロード・バランサを含んでもよい。幾つかの実施形態において、図１４に示される様々なタイプのデータ・ソースの全てがＴＶＳ１４１０によって使用されないことに注意する。例えば、幾つかの実施では、配置サービスは様々なノードに関する物理的な場所情報を供給することができるため、在庫管理サービスとの相互作用はこのような実施では必要とされない。
これら様々なソースから収集されたデータは、ＴＶＳ１４１０によって合成され、可視化リクエストに応答して模範的なヒートマップ１４５０等の様々なカスタマイズ可能なヒートマップが生成される。ヒートマップ１４５０は、クライアント・アカウントＣＡ１に割り当てられた五つの計算インスタンス（ＣＩ）、例えば、利用可能コンテナ２０３ＡにおけるＣＩ１４４０Ａ、１４４０Ｂ、および、１４４０Ｃ、および利用可能コンテナ２０３ＢにおけるＣＩ１４４０Ｄおよび１４４０Ｅを有するネットワーク・トポロジー１４６０を示す。幾つかのケースでは、ＴＶＳ１４１０によって生成されたトポロジーは、様々な実施形態において、データ・センター境界、利用可能コンテナ境界（図１４に示すような）、または、他の組織的或いは物理的境界をわたる。トポロジー１４６０における各計算インスタンス１４４０について、それぞれの色点けされた性能インジケータ（ＰＩ）１４７０が表示され、例えば、ＣＩ１４４０Ａ、１４４０Ｂ、１４４０Ｃ、１４４０Ｄ、および、１４４０Ｅに対してＰＩ１４７０Ａ、１４７０Ｂ、１４７０Ｃ、１４７０Ｄ、および、１４７０Ｅが示される。ＰＩ１４７０は、異なる実施形態において様々な異なるタイプのメトリックスまたはメトリックスと関連付けられる比を示し、符号化された性能情報のタイプは少なくとも幾つかの実施においてカスタマイズ可能である。例えば、入来および／または出発トラフィックに対する、現在構成されている帯域幅限界に対する測定されたトラフィック率の比が表示されてもよい。このような模範的なシナリオでは、赤色ＰＩは測定されたトラフィックが帯域幅限界に近い（例えば、その７５％より大きい）ことを示し、緑色ＰＩは比が３０％より下であることを示し、黄色ＰＩは比が３０％乃至７５％の間であることを示している。幾つかの実施では、数値またはテキストメッセージが各ノードに対して示されてもよい（例えば、比の値がパーセンテージとして表示されてもよい）。異なる実施形態において、ネットワーク帯域幅関連インジケータ、待ち時間関連インジケータ（例えば、最近測定された待ち時間がパケット待ち時間に対して要求される上界にどれだけ近いか、或いは、測定された平均的パケット転送待ち時間と待ち時間に対するターゲット上界との間の比）、閾値に対するＣＰＵ利用レベル、ストレージ装置利用レベル、メモリ利用レベル等を含む、幾つかの異なるタイプの性能インジケータがＴＶＳによって表示されてもよい。幾つかの実施形態では、ヒートマップに比が示されることに加えて或いはその代わりに（例えば、何らかの定義された閾値に対する測定された値の比）、絶対値が示されてもよい。少なくとも幾つかの実施において、ヒートマップは可視化サービスによって提供された情報に基づいてクライアント側のコンポーネント（例えば、ウェブブラウザまたはＧＵＩツール）によって表示されてもよい。そのため、上述のような実施において、可視化サービスは、メトリックスを取得し、トポロジーや性能インジケータを確定し、クライアント側のコンポーネントに何らかの適当なフォーマットでヒートマットに含まれるようデータの選択されたセットを供給することについて、責任を担っている。クライアント側のコンポーネントは、可視化サービスによって提供されるデータを用いてヒートマップを表示する。少なくとも幾つかの実施形態では、可視化サービスは、バックエンド・コンポーネントとフロントエンド・コンポーネントの両方を有し、バックエンド・コンポーネントはヒートマップの形態で提示され得る基礎データの生成に関与し、フロントエンド・コンポーネントはヒートマップの実際の表示に関与する。
幾つかの実施形態によると、ＴＶＳ１４１０のユーザは、可視化において表示される情報の粒度を調節することができる。例えば、一実施では、ネットワーク関連の性能インジケータに関して、クライアントは次の粒度のいずれかに対して好みを示し得る：（ａ）ポートレベルの粒度（例えば、ＴＣＰまたはＵＤＰポートのレベルでの情報が好ましい）、（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または（ｉ）地理的領域レベルの粒度。粒度の選択肢は、様々な実施形態において、ストレージ関連のメトリックス等、性能インジケータが表示され得る他のタイプの資源またはメトリックスに対して選択されてもよい。ＴＶＳ１４１０は、要求された粒度で収集されたメトリックスを統合して、可視化または表示に含まれるよう性能インジケータを確定してもよい。表示されるネットワーク関連情報の粒度をカスタマイズ化することに加えて、少なくとも一実施形態では、表示が様々なトラフィック・カテゴリーについてカスタマイズ化されてもよい。例えば、分散システムの所与のノードへのまたは所与のノードからのネットワーク・トラフィックはエンドポイントＩＰアドレスに基づいて（例えば、トラフィックがプロバイダ・ネットワーク内の二つのインスタンス間を、または、プロバイダ・ネットワーク外にある公衆インターネット・アドレスに流れているか）、トラフィックのエンドポイントが割り当てられるクライアント・アカウントに基づいて、または、トラフィックが生成されるアプリケーションまたはアプリケーション・タイプ（例えば、データベース関連のトラフィック特有のヒートマップが要求される、または、高性能計算特有のヒートマップが要求される）に基づいて分類されてもよい。図５に例示するようなトラフィック分類は、表示される情報をフィルタリングするために幾つかの実施形態において使用されてもよい。少なくとも幾つかの実施において、ＴＶＳのクライアントは、性能インジケータを表示したいトラフィック・カテゴリーをプログラムで定めてもよい。例えば、クライアントは、その割り当てられた計算インスタンスの一つのセットをソースセットとして指定し、インスタンスの別のセットまたは他のエンドポイント（例えば、特定のデータベース・インスタンス）を宛先として指定し、指定されたセットに基づいてトラフィック・カテゴリーを定めてもよい。
一実施形態では、可視化リクエストは、時間的コンポーネントを含み得、例えば、リクエストは、特定されたタイプのメトリックについて、表示される性能インジケータを生成するためにメトリックスが収集される時間期間を示す。幾つかの実施形態では、クライアントは、例えば、特定された時間期間にわたる所与の性能インジケータの値における変動が示される、動的可視化をリクエストすることができる。可視化のリクエスタに割り当てられる許可能力または役割（例えば、リクエスタがサービスに対して管理的アクセス許可を有するか、非管理的アクセス許可を有するか）は、様々な実施形態において表示され得る情報の種類を制御する暗黙のフィルタとしても機能する。幾つかの実施形態では、中央化可視化サービスは、二つ以上のネットワーク・アクセス可能サービスに関連する資源メトリックスまたは性能インジケータを見ることに有用であり、可視化の消費者は性能インジケータが表示されるサービスを示すことができる。例えば、プロバイダ・ネットワークの所与のクライアント・アカウントは、プロバイダ・ネットワークによって実施される関係型データベース・サービスおよび非関係型データベース・サービスの両方を使用してもよく、別個のヒートマップが二つの異なるタイプのデータベース・サービスに対してそれぞれのトポロジーおよび関連ネットワーク性能インジケータについて生成されてもよい。
トポロジー可視化サーバーの異なる消費者は、収集されたメトリックスの異なるサブセットにアクセスする許可が与えられるため、幾つかの実施形態では異なるレベルの詳細で可視化が提供される。図１５は、少なくとも幾つかの実施形態による、サービス管理者およびサービスの非管理クライアントに対してヒートマップを生成するために使用され得る収集されたメトリックスの異なるサブセットの実施例を例示する。図示するように、管理者アクセス可能メトリックス１５１０は、図示する実施形態において非管理クライアントによってアクセス可能なメトリックスのスーパーセットでもよい。例えば、仮想コンピューティング・サービスおよび一つ以上の仮想化されたストレージ・サービス等の様々な仮想化されたマルチテナント・サービスが実施されるプロバイダ・ネットワークでは、仮想化を実施するために使用される物理的資源に関する情報（例えば、使用されるインスタンス・ホスト、使用されるネットワーク装置、様々なデータ・センター内の物理的資源の配置）が幾つかの理由により秘密と考えられている。使用されるハードウェア・プロセッサおよび装置のタイプ等の詳細をサービス・クライアントに提供することは、ハードウェアの詳細を考慮することなく様々なサービス特徴を絶えず利用するといったクライアントの能力等、仮想化されたサービスを実施する主な目標の一つに反する。しかしながら、仮想化されたサービスの管理者は、例えば、ハードウェア・サーバー、ラック、ネットワーク装置等の適当な数やタイプを提供するために、使用されるハードウェアに関する少なくとも幾らかの詳細を知る必要がある。したがって、管理者は、図示する実施形態において非管理クラアイントに提供されるよりもＴＶＳ１４１０によって生成されるより詳細なヒートマップを見ることができる。
幾つかの実施形態では、非管理クライアントに曝された情報のタイプは、所与のクライアント・アカウントまたはリンク付けされたクライアント・アカウントのセットに割り当てられたインスタンスについて帯域幅限界に対する測定されたネットワーク・トラフィックの比等、サービス・インスタンス・レベルの性能インジケータを含んでもよい。幾つかの実施形態では、クライアント・アカウントは私的部門または公的部門エンティティ、或いは、このようなエンティティ内の部門を含む組織の代わりにプロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスで確立されてもよい。各クライアント・アカウントは、幾つかの実施において幾つかの異なるユーザ・アカウントまたはグループ・アカウントを包含してもよい。少なくとも幾つかの実施形態では、例えば、それぞれクライアント・アカウントが確立された大企業の二つの異なる部門に対する総請求のために、異なるクライアント・アカウントがリンク付けされてもよい。クライアントＣ２にアクセス可能なインスタンス関連メトリックス１５１５Ｂ等、ＴＶＳによって収集されたメトリックスの幾つかは、一つのクライアント・アカウント（例えば、該アカウントに対して定められたユーザ／グループ）にだけ可視である。クライアントＣ１およびＣ２に可視なインスタンス関連メトリックス１５１５Ａ等、他のメトリックスは複数のリンク付けされたクライアント・アカウントと関係するユーザ／グループに可視である。
様々な実施形態において、幾つかのメトリックスのタイプは、非管理ユーザにアクセス可能でない。例えば、スイッチ、ルーター、ゲートウェイ等の特定のネットワーク装置と関連付けられるメトリックス１５５０は、典型的には、非管理者に曝されない。同様にして、インスタンス・ホスト（複数のクライアントに対してサービス・インスタンスを潜在的に実施するハードウェア・コンピューティング装置）について収集されたメトリックスも管理者によってのみアクセスされ得る。図示する実施形態では、データ・センターに関するメトリックス（例えば、特定のデータ・センターに流入し、流出するトラフィック量）も管理的使用にのみ制限されてもよい。
したがって、ＴＶＳ１４１０によって異なる消費者カテゴリーについて生成されたヒートマップのタイプは異なる。図示する実施形態において、クライアントＣ１にはメトリックス１５１５Ａから導出された比較的制限されたヒートマップ１４５０Ａが提供され、クライアントＣ２はソース・メトリックスが１５１５Ａおよび１５１５Ｂの両方を含むヒートマップ１４５０Ｂを見ることができる。管理ユーザは、より大きいメトリックスの集まり１５１０から導出されたヒートマップ１４５０Ｃを見ることができる。所与の可視化リクエストに応答するよう使用されるべきメトリックスのサブセットについての決定は、例えば、許可設定の確定、リクエスタの能力または役割に基づいて、少なくとも幾つかの実施形態では、ランタイムでＴＶＳによってなされてもよい。
可視化のためのプログラマチック・インターフェイス
幾つかの異なるタイプのプログラマチック・インターフェイスが、異なる実施形態において、可視化リクエストを受信し応答するために使用されてもよい。図１６は、少なくとも幾つかの実施形態による、ネットワーク・トポロジーに対するヒートマップを表示するために使用され得るウェブベースのプログラマチック・インターフェイスの実施例を例示する。図示するように、ウェブベースのインターフェイスは、ネットワーク・トポロジーのノード１６１０Ａ、１６１０Ｂ、および、１６１０Ｃが性能インジケータ１６２０Ａ、１６２０Ｂ、および、１６２０Ｃのそれぞれのセットと一緒に表示される、ウェブページ１６０２を有する。
性能インジケータ１６２０は、ネットワーク帯域幅（図１６においてラベル「ＢＷ」によって示される）、ＣＰＵ、ディスク、および、メモリ（ラベル「Ｍｅｍ」によって示される）等、図示する実施例においてノードそれぞれについて複数の資源タイプに対する色付けされたエントリーを示す。ヒートマップを変更するまたはカスタマイズ化する幾つかのウェブベースの制御が図１６に例示される。例えば、ズーム制御１６５０は、トポロジーの異なる部分にズームインする、または、ズームアウトするためにビューアによって使用されてもよい。資源セレクタ１６５２は、可視化から幾つかのタイプの資源をフィルタで除去する、または、資源タイプを追加するために使用されてもよい。同様のセレクタが、表示のための時間期間（即ち、性能インジケータに対するメトリックスの使用の集まりに対応する時間の期間）、ネットワーク・トラフィック・カテゴリー、アプリケーション・タイプ等を選択するためにも有用である。図示する実施形態では、ビューアは、可視化に使用する閾値１６５４を特定することも可能であり、例えば、ビューアは、帯域幅限界の８０％（またはそれより高い）の測定された転送速度が赤色ＢＷ性能インジケータによって示され、３０％未満の値が緑色ＢＷ性能インジケータによって示される等と示してもよい。
図１７は、少なくとも幾つかの実施形態による、プログラマチック・インターフェイス１７７０を介してトポロジー可視化サーバー１４１０によって受信され得る可視化リクエスト１７２０の模範的な要素を例示する。このようなリクエストは、例えば、クラアイントまたは管理者１７１０による制御１６５０、１６５２、または、１６５４と同様の一つ以上の制御の選択に応答して、幾つかの実施形態において、図１６に示すようなウェブページを介して行われてもよい。他の実施形態では、このようなリクエストは異なるＧＵＩ、ＡＰＩ呼び出しを介してまたはコマンド・ライン・ツールから要請されてもよい。
図示するように、リクエスト１７２０は、可視化に含まれるべきサービス・ノードのセットを示すターゲット・サービス・ノード・リスト１７２５を有してもよい。幾つかの実施形態では、特定のセットのノードの表示がリクエスタによって提供されない場合、サービス・ノードのセットに対するデフォルト設定がＴＶＳ１４１０によって使用されてもよい。例えば、デフォルトで、クライアント・アカウントに割り当てられた全ての計算インスタンスが可視化のために選択される、または、管理者がリクエストを要請するデータ・センター内の全てのインスタンス・ホストが可視化に含まれ得る候補として考えられる。ノードのセットは、幾つかの実施形態において明確に示されてもよい（例えば、計算インスタンス識別子等のノード識別子のリストを提供することで）、または、ノードを検索するために使用され得るフィルタリング基準を示すことで（例えば、クライアントは特定された利用可能コンテナにおける計算インスタンスがセットに含まれるべきと示してもよい）。可視化に含まれるべきネットワーク・トラフィックのカテゴリーおよび／または資源も要素１７２８を用いてトポロジー可視化リクエストに示されてもよい。前述した通り、トラフィック・カテゴリーは、幾つかの実施形態において、クライアントによって定められてもよい。他の実施形態では、クライアントまたは管理者１７１０が、クライアントが定めたカテゴリーの代わりに或いはそれに加えて、複数の所定のトラフィック・カテゴリーの中から選択してもよい。幾つかの実施形態では、例えば、計算インスタンスだけを示すヒートマップが提供されるべきか、または、ストレージ・ノードが含まれるべきか等、資源の異なるカテゴリーも選択可能である。
可視化の粒度１７３１は、例えば（ネットワーク・トラフィックに対して）ホスト・レベルのビューが望ましいか、インスタンスレベルのビューが望ましいか等、幾つかの実施形態において、リクエスト１７２０に示されてもよい。可視化を生成するために使用されるべき様々なソースからのメトリックスの集まりの時間範囲は要素１７３４を介して示されてもよい。幾つかの実施では、クライアントは動的可視化をリクエストすることができ、例えば、選択された時間期間にわたる性能インジケータの値の変化が要素１７３７を介して示されるクライアントの好みに応じて表示されてもよい。少なくとも幾つかの実施形態において、リクエスト１７２０の要素に対して利用可能な選択肢のセットがユーザ間で変わり得ることに注意する。例えば、管理者は、可視化機能性の非管理ユーザよりもより広い範囲の好みを特定することができる。少なくとも一実施形態において、管理者には非管理ユーザに提供されものとは異なるセットのプログラマチック・インターフェイス１７７０がＴＶＳ１４１０によって提供されてもよい（例えば、より広範囲のセットのＡＰＩが他のユーザよりも管理資格を有するユーザに利用可能である）。図示する実施形態では、リクエスト１７２０に応答して、ＴＶＳ１４１０はデータの適当なセットを引き出し、ヒートマップ１４５０の形態で対応する表示を提供してもよい。
ネットワーク・トポロジーの可視化のための方法
図１８は、少なくとも幾つかの実施形態による、分散システムの様々なノードの性能インジケータを有するトポロジーの可視化を生成するよう実施される動作の態様を例示する。要素１８０１に示されるように、幾つかのメトリックスが、プロバイダ・ネットワークにおいて実施される様々なネットワーク・アクセス可能サービスのサービス・インスタンス、ルーター、スイッチ、ゲートウェイ等のネットワーク装置、並びに、分散システムのインスタンス・ホスト或いは他のタイプのハードウェアまたはソフトウェア・コンポーネント等、様々なデータ・ソースからＴＶＳ１４１０によって収集されてもよい。収集されたメトリックスは、例えば、ネットワーク関連メトリックス（インバウンドまたはアウトバウンド・トラフィック率、現在適用可能な帯域幅限界、測定されたおよびターゲット化された待ち時間、ネットワーク・エラー・カウント、パケット・サイズ分散、または、ドロップされたパケット・カウント等）、プロセッサ関連メトリックス（全体的なＣＰＵ利用、ターゲット閾値ＣＰＵ利用レベル、カーネル対ユーザ利用スプリット、アクティブ処理／スレッド・カウント等）、メモリ関連メトリックス（例えば、利用可能なフリーメモリの量、ページング速度等）、および、ストレージ関連メトリックス（ディスクまたは他のストレージ装置利用、平均的応答待ち時間、キュー長さ等）を含んでもよい。一実施形態において、現在適用されている限界（例えば、帯域幅限界）または性能ターゲット（例えば、待ち時間ターゲット）に関するメトリックスは、ＮＣＳ１８０から取得されてもよい。幾つかの実施形態では、幾つかのまたは全てのメトリックスは、ＮＣＳ１８０によって例えば、様々な資源の間で帯域幅分散を確定する等、他の目的のために既に収集されていてもよく、ＴＶＳはＮＣＳの他のコンポーネントまたはメトリックス・データベース１９０からメトリックスを取得してもよい。一実施形態では、メトリックスは、様々なデータ・ソースによって他のタイプのメッセージにピギーバックされてもよく、例えば、前述の通り、心拍メッセージが健康管理プロトコルに応じて送られる。
ＴＶＳ１４１０は、例えば、プロバイダ・ネットワークのアカウント管理サービス１４２０から、または、アイデンティティ管理サービスから、分散システムにおいて実施されている様々なサービスに対するクライアント・アカウント情報（図１８の要素１８０４）も取得してもよい。アカウント情報は、異なるクライアント・アカウント間（例えば、幾つかのクライアント・アカウントは統合請求のために他のアカウントとリンク付けされてもよい）、並びに、クライアント・アカウントとユーザ・アカウントまたはグループ・アカウント間等の関係を含んでもよい。少なくとも幾つかの実施において、ＴＶＳはサービス・ノードまたはインスタンス間およびクライアント・アカウント間のマッピング、例えば、所与の計算インスタンスを代わりに立ち上げたクライアント・アカウントを示す情報を取得してもよい。少なくとも幾つかの実施形態において、データ・センターの異なるラックやルームにおけるインスタンス・ホストの配置、分散システムの異なるノードとスイッチやルーター等の様々なネットワーク装置との間のネットワーク・リンクまたは路といった物理的なレイアウト情報が取得されてもよい（要素１８０７）。物理的なレイアウト情報は、例えば、在庫サービスまたは他のデータ・センター管理ツールから取得されてもよい。
一つ以上のネットワーク・トポロジーは、例えば、アカウント情報を物理的なレイアウト情報と合成して、関連するノードまたは資源について確定されてもよい（要素１８１０）。分散システムのサイズやそのユーザ・ベースに依存して、総合的なネットワーク・トポロジーを生成するおよび／または記憶することは、幾つかの実施形態において相当な計算、メモリ、および／または、ストレージ資源を必要とし得る。したがって、例えば、各データ・センターに対して一つ、或いは、各地理的領域に対して一つ等、幾つかの実施形態において幾つかの異なるネットワーク・トポロジーが生成されてもよい。性能インジケータのデータ・セットは、収集されたメトリックスを用いて単一のトポロジーまたは複数のトポロジーに対応して作成されてもよい（要素１８１３）。最近の時間間隔中に測定されたトラフィック率および該間隔中に適用された帯域幅限界の比、ターゲット最大待ち時間に対する時間間隔中に観察されるピーク待ち時間の比、ターゲットとされた最大または最小レベルに対して測定されたＣＰＵ利用等、任意の数の性能インジケータがトポロジーの様々なノードに対して確定されるまたは導出されてもよい。
少なくとも性能インジケータのサブセットに対する可視化リクエストが受信されてもよい（要素１８１６）。リクエスタの許可設定が確定され、リクエストおよび許可設定に対応する性能インジケータのデータ・セットの適当なサブセットが取得される（要素１８１９）。静的または動的ヒートマップの形態の色付けされた可視化が表示されてもよい（要素１８２２）。ブラウザ、ブラウザ・プラグイン、またはＧＵＩ等のクライアント側のコンポーネントは、バックエンドＴＶＳ１４１０によって提供されるデータに基づいてヒートマップを表示するために使用されてもよい。幾つかの実施形態では、性能インジケータのヒストグラム、円グラフ等他のタイプの可視化がＴＶＳ１４１０を用いてリクエストに応じて提供されてもよい。幾つかの実施形態では、トポロジーがオンデマンドで、例えば、可視化リクエストが受信された後、リクエストされた特定のタイプの性能インジケータに基づいて生成されてもよいことに注意する。
クライアント・リクエストされた資源使用限界の低減
幾つかの分散システムでは、様々なサービスに対してクライアントが支払わなくてはならない金額は、クライアントの代わりにサービス・インスタンスで生成されたネットワーク・トラフィックに依存し得る。幾つかのシナリオでは、サービスは、一サービス・インスタンス当たり転送され得るデータの量（または、データ転送の速度）に対して上界を定め、トラフィックに比例する料金がこの上界より低く適用されてもよい。したがって、クライアントは、予算に合うよう、少なくとも一時的にこのような環境においてネットワーク使用を減少させるインセンティブを有する。幾つかのタイプのサービスに対して、幾つかの異なる標準化されたサービス・インスタンス・タイプがクライアントに利用可能であり、このとき、異なるネットワーク限界および／または速度が各インスタンス・タイプに適用可能である。図１９は、少なくとも幾つかの実施形態による、それぞれの帯域幅限界およびそれぞれの帯域幅使用価格決定ポリシーが異なるインスタンス・タイプに設定された、ネットワーク・アクセス可能サービスに対して実施され得る計算インスタンス・タイプのセットの実施例を例示する。仮想コンピューティング・サービスによって定められる、四つの異なる計算インスタンス・タイプ１９０２（「小」、「中」、「大」、「特大」計算インスタンス）に対するネットワーク関連設定を含む表が示される。インスタンス・タイプは、ネットワーク能力および帯域幅関連価格決定における差に加えて、計算力、ストレージ・サイズ限界、メモリ・サイズ、または、全体的な価格決定等、様々な特性において異なり得る。
図示する実施形態では、二つの異なるトラフィック・カテゴリー（カテゴリー「Ａ」と「Ｂ」とそれぞれラベル付けされる）のそれぞれについて、アウトバウンド・トラフィック（列１９０４）およびインバウンド・トラフィック（列１９０８）に対して別個の帯域幅限界が定められてもよい。カテゴリーは、関係するエンドポイントがプロバイダ・ネットワーク内にあるか否か、例えば、トラフィックが公衆インターネットに方向付けられているか否かに関して互いと異なってもよい。異なるインスタンス・タイプに対する帯域幅限界に加えて、図１９は、二つのトラフィック・カテゴリーそれぞれについて別個に特定され得る、アウトバウンドおよびインバウンドの帯域幅価格決定（それぞれ列１９０６および１９１０）も示す。実際には、幾つかの実施形態においてプロバイダ・ネットワーク・オペレーターによって幾つかの価格がゼロに設定されてもよく、例えば、同じデータ・センター内でたまたまインスタンス化された異なる計算インスタンス間のトラフィックが「フリー」でもよいことに注意する。図１９に例示される情報は、仮想コンピューティング・サービスの潜在的クライアントによってアクセスされ得、各タイプのインスタンスをどれだけ取得すべきかを決定する際にクライアントによって（クライアントのアプリケーションの計算性能要件、帯域幅使用に関連しない価格決定ポリシー等の他の要素とともに）考慮されてもよい。幾つかのクライアントは、例えば、図１９に提供される情報の種類を用いてネットワーク関連のコストのための予算を取っておいてもよい。クライアントのアプリケーションのニーズにより、少なくとも幾らかの時間期間中、所与のクライアントはそのインスタンス・タイプをサポートした最大帯域幅よりもはるかに小さい帯域幅を利用する必要があり、そのため、より低い限界を課すことをリクエストすることでより効果的にコストを管理することができる場合がある。例えば、所与のネットワーク・アクセス可能サービスにアクセスする権限が与えられた多数の個人ユーザを所与のビジネス組織が含む環境では、低帯域幅限界を適用することは、個別ユーザにそれぞれの帯域幅使用を自主的に制御することを単にリクエストするよりも、ネットワーク関連のコストを低減させるより信頼できる方法である。
少なくとも幾つかの実施形態では、図１に例示するのと同様の中央化ネットワーク構成サービスは、顧客リクエストされた帯域幅限界および／または他のタイプの資源使用減少限界を実施するために使用されてもよい。幾つかのタイプのネットワーク関連限界のいずれかが様々な実施形態ではクライアント・リクエストに応答して適用されてもよく、例えば、（ａ）幾らかの時間の期間にわたって超えられてはならない平均的トラフィック送信速度、（ｂ）短い時間の期間にわたってさえも超えられてはならないピーク・トラフィック送信速度、（ｃ）転送されたデータの合計バイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限が適用されてもよい。平均的限界および／またはピーク限界が適用される時間の期間は、幾つかの実施形態においてクライアントによって示されてもよい。図２０は、少なくとも幾つかの実施形態による、ネットワーク構成サーバー１８０によって受信され得る資源使用限界低減リクエスト２０２０の模範的な要素を例示する。幾つかの実施形態では、前述の通り、所与の請求可能な顧客アカウントは、それと関連付けられる幾つかのユーザ・アカウントを有し、異なる資源使用限界が異なるユーザ・アカウントに適用されてもよい。図示するように、プログラマチック・インターフェイス２０７０を介して要請されるリクエスト２０２０は、リクエストされた低減が適用されるべき一つ以上のユーザ・アカウントを示す要素２０２３を含んでもよい。幾つかの実施形態ではグループ・アカウントも示され得る。一実施形態では、幾つかの異なる計算インスタンスまたは他の資源が割り付けられたクライアント２０１０は、これら資源の幾つかのサブセットにより低い資源使用限界を適用することを望む場合がある。ターゲットとされた特定ノードまたは資源の識別子は、限界低減リクエスト２０２０の別の要素２０２６を介して示されてもよい。幾つかのセットのサービス・インスタンスに対する組み合わされた資源使用限界は、幾つかの実施においてクライアントによってリクエストされてもよい。例えば、クライアントは、インスタンスＩ１、Ｉ２、および、Ｉ３にＸ ＧＢ／秒の帯域幅限界が集合的に適用されることをリクエストしてもよく、限界はインスタンスの帯域幅使用の合計が特定の時間期間中にＸ ＧＢ／秒を超える場合に満たされたと考えられる。
それぞれの使用限界は、幾つかの実施形態において異なるネットワーク・トラフィック・カテゴリーに適用されてもよい。上述した通り、幾つかの実施形態では、ネットワーク・アクセス可能サービスは、例えば、エンドポイントのネットワーク・アドレスの範囲に基づいて、および、エンドポイントの地理的場所に基づいて、ネットワーク・トラフィックの様々なカテゴリーを定めてもよい。幾つかの実施形態では、例えば、それぞれの限界は、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）プロバイダ・ネットワークによって定められる所与の地理的領域内の二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、（ｄ）プロバイダ・ネットワークによって定められる二つの異なる地理的領域における二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、または、（ｅ）特定のサービス・インスタンスとプロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィック、に適用されてもよい。図２０に示す実施形態では、使用の低減をターゲットとしたトラフィック・カテゴリーまたは複数のカテゴリーは、要素２０２９を介して示されてもよい。
ネットワーク・トラフィックに対する限界に関して、流れ方向（低減された限界がインバウンド・トラフィック、アウトバウンド・トラフィック、または、両方に適用されるべきか）が要素２０３２を介して示されてもよい。新しい限界が適用されるべき時間範囲（例えば、開始時間、終了時間、または、両方）は要素２０３５を介して示されてもよい。リクエストされた限界値（または、現在の限界が低減されるべき程度）は、図示する実施形態では要素２０３８を介して示されてもよい。例えば、要素２０３８は、新しい限界に対して絶対値を特定する代わりに、現在の帯域幅限界が２５％だけ低減されるべきと示してもよい。幾つかの実施では、新しい限界を示す場合、クライアントは使用されるべき測定アプローチの態様を示してもよく、例えば、平均的帯域幅限界への変化がリクエストされる場合、平均が計算されるべき時間期間が特定され、より低いピーク帯域幅がリクエストされた場合、ピーク帯域幅が定量化されるべき時間期間が特定されてもよい。少なくとも幾つかの実施形態では、低減された限界を特定することに加えて、クライアント２０１０はそれぞれの作用がネットワーク構成サーバー１８０によって行われる、要素２０４１を介して限界に対して一つ以上の閾値を定めてもよい。例えば、クライアント２０１０は、計算インスタンスへのまたはからの測定されたトライフィック率がクライアント・リクエストされた帯域幅限界の８０％を超えた場合に通知されることを望む。幾つかの実施では、リクエストは、閾値に到達したときに通知が提供されるべき一つ以上の宛先（例えば、電子メールアカウント）の表示を含んでもよい。それぞれの作用が行われる幾つかの異なる閾値が幾つかの実施において示されてもよい。例えば、帯域幅の８０％では通知が生成され、１００％ではサービスがパケットをドロップするか破棄し始めることが許可される。幾つかのパケットを送信する代わりに一時的に待ち行列に入れる、限界を一時的に緩和するおよび／または増加する等、他の応答作用が、幾つかの実施形態において、クライアントの明確なリクエストに応じて、または、サービス主導で行われ得る。
リクエスト２０２０を受信することに応答して、ＮＣＳ１８０は、リクエストするクライアントに変化の承認２０５０を提供し、リクエストされた限界を適用するよう適当な構成の変化を開始する。例えば、低減された帯域幅限界がインスタンス・ホストで実施された計算インスタンスに適用されるべきシナリオでは、ＮＣＳ１８０はインスタンス・ホストにおいて図３に例示されるスタック３１０と同様の仮想化管理ソフトウェア・スタックのコンポーネントに新しい限界を送信してもよい。幾つかの実施形態では、ＮＣＳ１８０は、承認２０５０を送る前に、構成の変化が約束されるまで待ってもよい。
資源使用限界の低減は、仮想コンピューティング・サービス、様々なタイプのストレージ・サービス、データベース・サービス等、幾つかの実施形態において複数のネットワーク・アクセス可能サービスのいずれかのインスタンスに対してリクエストされてもよい。幾つかの実施形態では、低減された資源使用限界値を直接示す代わりに、クライアントはある示された時間期間中に満たされるべき資源予算限界を示してもよい。それに応答して、ネットワーク構成サービスは、クライアントのサービス・インスタンスの資源使用を監視し、対応する請求金額を（例えば、関連するサービスの請求管理コンポーネントと通信することで）確定してもよい。予算限界に近い閾値（または予算限界自体）が到達されると、クライアントは通知されてもよくおよび／または一つ以上の応答作用が行われてもよい。そのため、資源予算限界は、少なくとも幾つかの実施形態において資源使用限界と類似して処理されてもよい（またはそれに置換されてもよい）。少なくとも幾つかの実施形態において、資源使用限界におけるクライアント・リクエストされた低減をサポートする構成サーバーは、図１のＮＣＳ１８０に関して前述した機能の少なくとも幾つかを実施する必要がないことに注意する。例えば、使用減少リクエスト２０２０に応答する構成サーバーは、図７と同様の手順グラフや図５と同様の分類ツリーを必ずしも生成する必要がない。
上述したように、少なくとも幾つかの実施形態では、所与の請求可能なクライアント・アカウント、例えば、社員がプロバイダ・ネットワークの一つ以上のネットワーク・アクセス可能サービスを使用する組織またはエンティティのために確立されたアカウントは、それと関連する幾つかの異なるユーザ・アカウントまたはグループ・アカウントを有してもよい。このような実施形態では、別個の資源使用限界が異なるユーザまたはグループに対して設定されてもよい。図２１は、少なくとも幾つかの実施形態による、ネットワーク・アクセス可能サービスのクライアント・アカウント２１０４Ａに対する全体的な資源使用限界設定２１１０の確立、および、ユーザ・グループ、個人ユーザ、および、リンク付けされたアカウントに対する関連する資源使用限界設定の確立の実施例を例示する。図示するように、クライアント・アカウント２１０４Ａは、ユーザ・グループ２１２０Ａおよび２１２０Ｂ等の、一つ以上の関係するグループ・アカウント２１２０が定められている。各グループは、グループ２１２０Ｂのユーザ・アカウント２１２３Ｋおよび２１２３Ｌ等、複数のユーザ・アカウント２１２３を有してもよい。幾つかのユーザ・アカウント、例えば、２１２３Ａ、２１２３Ｂ、および、２１２３Ｃはどのユーザ・グループに属さなくてもよい。
図示する実施形態では、全体的な資源使用限界２１１０（例えば、帯域幅限界）は、様々なグループ・アカウント２１２０およびユーザ・アカウント２１２３等、クライアント・アカウント２１０４Ａと関係するアカウント全てに対して確定されてもよい。アカウント２１０４Ｂ等の一つ以上の追加的なクライアント・アカウントは、例えば、総合請求または他の目的のためにクライアント・アカウント２１０４Ａとリンク付けされてもよい。一つの模範的なシナリオでは、クライアント・アカウント２１０４Ａはプロバイダ・ネットワーク資源を用いて特定のアプリケーションを実施する組織Ｏ１に対してセットアップされる一方で、クライアント・アカウント２１０４ＢはＯ１とパートナーとなる或いはＯ１によって実施されるアプリケーションを利用する異なる組織Ｏ２に対してセットアップされ得る。二つのクライアント・アカウントがセットアップされるエンティティの好みにより、全体的な資源使用限界２１１０もリンク付けされたユーザ・アカウントに適用され得る。少なくとも幾つかの実施形態では、所与の時間期間にわたる全てのユーザ、グループ、および、リンク付けされたアカウントの測定された資源使用は、例えば、使用限界総和ポリシー２１９０に応じて、当該期間中、親クライアント・アカウント２１０４Ａに適用される全体的な資源使用限界を超えてはならない。
幾つかの実施形態では、異なるユーザ、グループ、または、リンク付けされたアカウントに対して明確な資源使用限界がリクエストされてもよい。例えば、グループ２１２０Ａおよび２１２０Ｂには、それぞれの限界２１５０Ａおよび２１５０Ｂが割り当てられ、ユーザ２１２３Ａ、２１２３Ｂ、２１２３Ｋ、および、２１２３Ｌには、それぞれの限界２１６０Ａ、２１６０Ｂ，２１６０Ｋ、および、２１６０Ｌが割り当てられる。何人かのユーザ（例えば、２１２３Ｃ）および／またはグループはそれぞれの限界が定められていない場合があり、その場合、その親グループの限界および／またはクライアント・アカウントの限界が適用され得る。リンク付けされたアカウント２１０４Ｂには、独自の資源使用限界２１７０は定められ、これはリンク付けされたアカウント内で定められるユーザおよび／またはグループにも適用され得る。図２１に例示される資源使用限界に関して、クライアント・アカウント２１０４Ａは「親」エンティティと考えられ、グループ、ユーザ、および、リンク付けされたアカウントは「子孫」エンティティと考えられる。図２１に示される異なる粒度またはレベルのいずれかで適用される資源使用限界における低減は、例えば、図２０のリクエスト２０２０と同様のリクエストを介して、少なくとも幾つかの実施形態において要請されてもよい。リクエストされた低減が親エンティティ（例えば、クライアント・アカウント２１０４Ａ）に適用される場合、子孫エンティティに課せられる限界に対する低減の影響は使用限界総和ポリシー２１９０に示され得る。例えば、一実施形態では、全体として帯域幅における１０％の低減がクライアント・アカウントにリクエストされた場合、クライアント・アカウントから由来する各ユーザまたはグループに適用されるべき帯域幅限界も一つの選択されたポリシー２１９０に応じて１０％だけ低減され得る。別のポリシー２１９０によると、（ａ）任意の所与の子孫の限界が親の限界を超えない、且つ、（ｂ）所与の時間期間にわたる全ての子孫ノードの実際の資源使用の総和が親の限界を超えない限り、子孫の限界は変更が明確にリクエストされない限り変更されてはならない。
クライアント・リクエストされた資源使用限界を低減する方法
図２２は、少なくとも幾つかの実施形態による、クライアントがネットワーク・アクセス可能サービスの一つ以上のノードに対する資源使用限界を低減することを可能にするよう実施される動作の態様を例示する。要素２２０１に示すように、一つ以上のプログラマチック・インターフェイスが実施されると、ネットワーク・アクセス可能サービス（プロバイダ・ネットワークで実施されるマルチテナント仮想コンピューティング・サービス等）のクライアントは資源使用限界の低減を、資源使用限界が適用される一つ以上のサービス・インスタンスについてリクエストすることができる。プログラマチック・インターフェイスは、例えば、ウェブページまたはウェブサイト、一つ以上のＡＰＩ、ＧＵＩ、または、コマンド・ライン・ツールを含んでもよい。
限界低減リクエストは、例えば、ネットワーク構成サーバーにおいて、プログラマチック・インターフェイスの一つを介して受信されてもよい（要素２２０４）。限界低減リクエストは、図２０に示すリクエスト２０２０の構成要素の何らかの組み合わせ等、適用されるべき新しい限界に関して様々な構成要素を有してもよい。低減された限界が適用されるべき特定のクライアント・アカウント、トラフィック・カテゴリー、サービス・インスタンス、および／または、時間期間がリクエストに示されてもよい。適当な構成の変化は、リクエストに応じてなされてもよく、例えば、限界が計算インスタンスに適用されるべきシナリオでは、影響されるインスタンス・ホストにおける仮想化ソフトウェア・コンポーネントが新しい限界に関して通知されてもよい。資源使用メトリックスは、時間をかけてターゲットとされたサービス・インスタンスから取得されてもよい（要素２２０７）。測定された資源使用が閾値（閾値が新しく適用された限界について定められ得る）に到達したとの検出に応答して、通知が（例えば、低減された限界のリクエスタに対して、または、リクエスタによって示される一つ以上の指定された通知ターゲットに対して）生成される（要素２２１０）。幾つかの実施形態では、他の作用が閾値に到達したとの検出に応答して行われる。例えば、資源使用限界が帯域幅に適用される場合、一つ以上のパケットがドロップされるか待ち行列に入れられ、幾つかのケースでは、限界が一時的に緩和される。幾つかのケースでは、このような使用限界の緩和は、警告メッセージに伴われる（例えば、クライアントは、限界が一時的に緩和されるが、持続的にまたは繰り返し限界または閾値を超えることはデータ損失につながると警告されてもよい）。少なくとも幾つかの実施形態では、一つ以上のこのような閾値および／または対応する応答作用は、使用限界の低減をリクエストしたクライアントによって示される。
図２３は、少なくとも幾つかの実施形態による、クライアントが分散システムのノードにおいて資源使用限界と関連付けられるクエリーを出すことを可能にするよう実施される動作の態様を例示する。要素２３０１に示されるように、一つ以上のプログラマチック・インターフェイスが様々なタイプのクエリーに対して実施されてもよい。幾つかのクライアントは、例えば、現在利用可能な限界に対して資源使用の現在の状態またはメトリックを確定することを望むことがある。別のシナリオでは、クライアントは、一つ以上の特定されたサービス・インスタンスにおいて経時的な資源使用における変化に関する傾向情報を取得することを望むことがあり、それにより、例えば、クライアントは資源使用限界がいつ変えられるべきかを予想することができる。更に別のシナリオでは、資源使用に関する予算ベースのクエリーがネットワーク構成サーバーによってサポートされてもよく、例えば、クライアントは幾つかのサービス・インスタンスに関してネットワークに対するターゲット予算限界を示し、クライアントのコストを予算内で維持することを助け得る帯域幅限界に対する変更を推奨するリクエストを出してもよい。クエリーは、プログラマチック・インターフェイスの一つを介してクライアントから受信されてもよい（要素２３０４）。クエリーのタイプにより、クエリーが適用されるサービス・インスタンスから収集されるメトリックスに基づいて異なる作用が取られ得る。
クエリーが資源使用の現在の状態に関係する場合（要素２３１０）、資源使用の最近の測定とサービス・インスタンスにおける適用可能な限界との間の差を示す応答が提供される（要素２３５１）。傾向クエリーが受信されると（要素２３１３）、選択された時間間隔にわたる資源使用の変動を示す応答が提供される（要素２３５４）。予算ベースの推奨クエリーが受信されると（要素２３１６）、ネットワーク構成サーバーは、クライアントが予算目標を実現することを可能にする一つ以上の使用限界低減を確定するのに必要な計算を実施し、計算の結果をクエリー応答で提供してもよい（要素２３５７）。幾つかの実施形態では、他のタイプのクエリーがサポートされてもよい。
様々な実施形態において、図１０、図１１、図１２、図１３、図１８、図２２、および、図２３のフロー図で例示される動作以外の動作が、記載するネットワーク構成の機能性の様々な態様を実施するために使用され得、図示する動作の幾つかが実施されず、或いは、順次的でなく異なる順序でまたは並列に実施されてもよいことに注意する。例えば、幾つかの実施形態では、マルチスレッドＮＣＳが実施されてもよく、この場合、図１０に示す動作の幾つかのストリームが並列に実行され、それぞれのターゲット・ノードに対する分類メタデータのそれぞれのセットが生成され送信される。
使用ケース
分散システムの多数のノードでネットワーク・トラフィックをシェーピングし、ヒートマップ・ベースの資源可視化能力を提供し、資源使用限界におけるクライアント・リクエストされた低減を可能にするためにネットワーク構成サーバーの中央化セットを確立する上述の技術は、幾つかのシナリオで有用である。例えば、プロバイダ・ネットワークは幾つかのデータ・センター間で分散される数百の、或いは、数千のインスタンス・ホストおよび多数のネットワーク装置を有してもよく、プロバイダ・ネットワークの収益の少なくとも一部分はインスタンス・ホストに流入するまたは流出するネットワーク・トラフィックの量に基づいて導出される。ネットワーク管理決定を行うために各インスタンス・ホストまたはネットワーク装置でローカル・モジュールを用いることは、このような大きな環境では幾つかの問題を生ずる。第一に、所与のインスタンス・ホストで知的ネットワーク管理決定を行うのに必要な全ての入力を取得することが可能でないこともある。第二に、インスタンス・ホストで要求される決定論理の複雑性は、インスタンス・ホストの相当量の計算能力を必要とし、これは、クライアント・リクエストされたサービス・インスタンスに対して残されるコンピューティング能力を減少し得る。ネットワーク管理論理が変更される必要がある場合、全てのインスタンス・ホストに変更が送信され適用されなくてはならず、これ自体が資源集約的な且つエラーを起こしやすいエクササイズである。
反対に、トラフィック・シェーピングに使用されるべき決定論理を幾つかのネットワーク構成サーバーに隔離することで、より大きなセットのソースからの入力が収集され、より情報を得た上での決定が下され得る。ネットワーク構成サーバーは、コンピューティング能力へのコンテンションを回避しながら、他のサービスと共有される必要がない専用のコンピューティング資源を用いて実施されてもよい。ネットワーク構成論理への更新は、数百或いは数千のインスタンス・ホストが更新される場合よりも、より簡単に適用され得る。中央化ネットワーク構成サービスは、さもなければ取得することが難しいネットワーク・ステータス（構成可能なヒートマップを含む）の統一ビューをクライアントに簡単に提供することができる。特定されたサービス・インスタンス、ユーザ・アカウント、または、グループ・アカウントに対してプログラムで資源使用限界を低減させる能力は、予算を制御しようとするクライアントには有用である。
本開示の実施形態は、以下の付記を考慮して説明され得る。
１．プロバイダ・ネットワークのマルチテナント・ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことを少なくとも時間間隔中にクライアントがリクエストすることを可能にする一つ以上のプログラマチック・インターフェイスを実施し、該低資源使用限界が資源使用依存価格決定ポリシーでネットワーク・トラフィックの少なくとも一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介して、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベルに到達したとの確定に応答して、通知の生成を含む一つ以上の応答作用を開始するよう構成される、複数のコンピューティング装置を備えるシステム。
２．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信速度、（ｂ）超えられてはならないピーク・トラフィック送信速度、（ｃ）転送されたデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記１記載のシステム。
３．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワーク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、（ｄ）該特定のサービス・インスタンスと該プロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネットワーク・トラフィックの複数のカテゴリーから選択される、付記１記載のシステム。
４．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ以上の宛先に流れるトラフィック、（ｂ）一つ以上のソースから該特定のサービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記１記載のシステム。
５．該クライアント・リクエストは、該マルチテナント・ネットワーク・アクセス可能サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適用される、付記１記載のシステム。
６．複数のコンピューティング装置により、
ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことをクライアントがリクエストすることを可能にするプログラマチック・インターフェイスを実施し、該低資源使用限界がサービスと関連付けられるネットワーク・トラフィックの少なくとも一つのカテゴリーに適用され、
該一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介して、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、該特定の低資源使用限界から少なくとも部分的に確定される閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始する、方法。
７．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送されたデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記６記載の方法。
８．該クライアント・リクエストは、該特定の低資源使用限界が適用されるネットワーク・トラフィックの特定のカテゴリーを示し、
該特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、（ｄ）該サービスのノードと該プロバイダ・ネットワークで実施される異なるサービスのノードの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネットワーク・トラフィックの複数のカテゴリーから選択される、付記６記載の方法。
９．該クライアント・リクエストは、（ａ）該特定のサービス・インスタンスから一つ以上の宛先エンドポイントに流れるトラフィック、（ｂ）一つ以上のソースから該特定のサービス・インスタンスに流れるトラフィックの一方を含む、該低資源使用限界が適用されるネットワーク・トラフィック・フローの一つ以上の方向を示す、付記６記載の方法。
１０．該クライアント・リクエストは、マルチテナント・ネットワーク・アクセス可能サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの特定のユーザ・アカウントを示し、
該低資源使用限界は、該特定のユーザ・アカウントに適用され、
異なる資源使用限界は、該複数のユーザ・アカウントの異なるユーザ・アカウントに適用される、付記６記載の方法。
１１．該一つ以上の応答作用は、（ａ）一つ以上のパケットを破棄する、（ｂ）一つ以上のパケットを待ち行列に入れる、または、（ｃ）該特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる資源使用限界を特定の時間期間にわたって増加させることのいずれかを含む、付記６記載の方法。
１２．前記一つ以上のコンピューティング装置により、更に、
該特定のサービス・インスタンスにおいてネットワーク・トラフィックと関連付けられる測定された資源使用をクライアントが確定することを可能にする異なるプログラマチック・インターフェイスを実施し、
該異なるプログラマチック・インターフェイスを介して受信されるリクエストに応答して、該測定された資源使用の表示を提供する、付記６記載の方法。
１３．該クライアント・リクエストは、該特定の低資源使用限界が課せられる時間期間の表示を含む、付記６記載の方法。
１４．該クライアント・リクエストは、（ａ）閾値レベル、または、（ｂ）該一つ以上の応答作用のうちの特定の応答作用の一方の表示を含む、付記６記載の方法。
１５．該ネットワーク・アクセス可能サービスは、プロバイダ・ネットワークのインスタンス・ホストを用いて実施され、該方法は、
該一つ以上のコンピューティング装置により、更に、
該プロバイダ・ネットワークの中央化ネットワーク構成サービスの特定のサーバーにおいて、特定されたサービス・インスタンスにおけるそれぞれの低資源使用限界に対する複数のクライアント・リクエストを受信し、
該特定されたサービス・インスタンスのそれぞれのインスタンス・ホストでインスタンス化されたそれぞれの制御モジュールに該特定のサーバーから該それぞれの低資源使用限界の表示を送信することを含む、付記６記載の方法。
１６．一つ以上のプロセッサで実行されると、
プログラマチック・インターフェイスを介して、ネットワーク・アクセス可能サービスの特定のインスタンスにおいてネットワーク・トラフィックの少なくとも一つのカテゴリーに課せられる特定の低資源使用限界を示すクライアント・リクエストを受信し、
該特定のインスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
該特定のインスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始するプログラム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
１７．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの第一および第二のインスタンスにおいてネットワーク・トラフィックに集合的に課せられる組み合わされた資源使用限界を示す異なるクリアント・リクエストを受信し、
該第一および第二のインスタンスにおけるネットワーク・トラフィックと関連付けられる該資源使用の総和が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１８．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれかを有する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
１９．該命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスの異なるインスタンスにおいて資源をネットワークすることに対するクライアント予算の上界を示す異なるクリアント・リクエストを受信し、
該異なるインスタンスにおける資源をネットワークすることと関連付けられるクライアント請求金額が閾値を超えたとの確定に応答して、一つ以上の応答作用を開始する、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
２０．該特定の低資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送されたデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、付記１６記載の非一過性のコンピュータ・アクセス可能記憶媒体。
２１．プロバイダ・ネットワークの複数のクライアント・アカウントにアクセス可能な少なくとも一つのマルチテナント・ネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含み、複数のソースからメトリックスを取得し、
少なくとも（ａ）該ノードのセットの第一のノードおよび第二のノードが割り当てられるそれぞれのクライアント・アカウント間の関係、および、（ｂ）該第一のノードと該第二のノードとの間の一つ以上のネットワーク・リンクを示すネットワーク・トポロジーを確定し、
該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを含む、該ネットワーク・トポロジーの複数のネットワーク性能インジケータの表現を生成し、
プログラマチック・インターフェイスを介して受信されるリクエストに応答して表示されるカスタマイズ可能な資源ヒートマップに含まれるよう該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを提供するよう構成される一つ以上のコンピューティング装置を備える、システム。
２２．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該マルチテナント・ネットワーク・アクセス可能サービスのために構成されるネットワーク構成サーバーにより該第一のノードについて確定される帯域幅限界との間の比の表示を有する、付記２１記載のシステム。
２３．該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記２１記載のシステム。
２４．該一つ以上のコンピューティング装置は、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域レベルの粒度のうちの一つを有する、カスタマイズ可能な資源ヒートマップに表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該カスタマイズ可能なヒートマップに含まれるよう一つ以上の収集されたメトリックスを統合するよう更に構成される、付記２１記載のシステム。
２５．該プログラマチック・インターフェイスを介して受信される該リクエストに応答して、該一つ以上のコンピューティング装置は、
該リクエストの要請側の許可設定を取得し、
該許可設定に少なくとも部分的に基づいて、該カスタマイズ可能な資源ヒートマップに表される収集された資源メトリックスのサブセットを選択するよう更に構成される、付記２１記載のシステム。
２６．一つ以上のコンピューティング装置により、
プロバイダ・ネットワークの一つ以上のクライアント・アカウントの代わりにネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含むメトリックスをプロバイダ・ネットワークの複数のソースから取得し、
該ノードのセットの第一のノードと第二のノードとの間の一つ以上の関係を表すネットワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう該第一のノードと該第二のノードの、メトリックスの一部分から少なくとも部分的に導出されるそれぞれのネットワーク性能インジケータを提供する、方法。
２７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅限界との間の比の表示を有する、付記２６記載の方法。
２８．該資源ヒートマップは、（ａ）該第一のノードのプロセッサ性能インジケータ、（ｂ）該第一のノードのストレージ性能インジケータ、または、（ｃ）該第一のノードのメモリ性能インジケータのいずれかを有する、付記２６記載の方法。
２９．該第一のノードの該ネットワーク性能インジケータは、測定されたネットワーク待ち時間と、該第一のノードと関連付けられるトラフィックに対するネットワーク待ち時間の上界との間の比の表示を有する、付記２６記載の方法。
３０．該資源ヒートマップはリクエストに応答して生成され、
該リクエストは、トラフィック・フィルタリング基準の表示を有し、該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーは（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記２６記載の方法。
３１．該一つ以上のコンピューティング装置により、
クライアントがネットワーク・トラフィックの一つ以上のカテゴリーを定めるよう異なるプログラマチック・インターフェイスを実施し、
該特定のカテゴリーの定義を該異なるプログラマチック・インターフェイスを介して受信する、付記３０記載の方法。
３２．該一つ以上のコンピューティング装置により、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう一つ以上のメトリックスを統合する、付記２６記載の方法。
３３．該一つ以上のコンピューティング装置により、
該資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された収集時間期間の表示を受信し、
該選択された収集時間期間に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう該一つ以上のメトリックスを統合する、付記２６記載の方法。
３４．該複数のソースは、（ａ）ネットワーク・インターフェイス・カード、（ｂ）仮想化ホストにインストールされる仮想化ソフトウェア・スタックのネットワーク・コンポーネント、（ｃ）仮想化されたコンピューティング・サービスの計算インスタンスのネットワーク・コンポーネント、（ｄ）ネットワーク・タップ装置、（ｅ）スイッチ、（ｆ）ルーター、（ｇ）ゲートウェイ、または、（ｈ）ロード・バランサのうち一つ以上有する、付記２６記載の方法。
３５．該ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれかを有する、付記２６記載の方法。
３６．一つ以上のプロセッサで実行されると、
複数のクライアント・アカウントの代わりに少なくとも一つのネットワーク・アクセス可能サービスを実施するノードのセットから収集されたネットワーク・トラフィック・メトリックスを含む、メトリックスを複数のソースから取得し、
（ａ）該ノードのセットのうちの第一のノードおよび第二のノードが割り当てられるそれぞれのクライアント・アカウント間の関係、または、（ｂ）該第一のノードと該第二のノードとの間の一つ以上のネットワーク・リンクの少なくとも一方を表すネットワーク・トポロジーを生成し、
該ネットワーク・トポロジーに対応する資源ヒートマップに含まれるよう、該メトリックスの一部分から少なくとも部分的に導出される、該第一のノードおよび該第二のノードのそれぞれのネットワーク性能インジケータを提供する、プログラム命令を記憶する非一過性コンピュータ・アクセス可能記憶媒体。
３７．該第一のノードの該ネットワーク性能インジケータは、該第一のノードにおける測定されたネットワーク・トラフィック率と、該第一のノードについて設定される帯域幅限界との間の比の表示を有する、付記１６記載の非一過性コンピュータ・アクセス可能記憶媒体。
３８．命令は、該一つ以上のプロセッサで実行されると、
トラフィック・フィルタリング基準の表示を受信し、
該表示に応じて該第一のノードにおけるネットワーク・トラフィックの複数のカテゴリーのうちの特定のカテゴリーについて該第一のノードの該ネットワーク性能インジケータが確定され、
該特定のカテゴリーが（ａ）エンドポイント・アドレス、（ｂ）エンドポイント・アドレスと関連付けられるクライアント・アカウント、または、（ｃ）ネットワーク・トラフィックを生成するアプリケーションの少なくとも一つについて該複数のカテゴリーのうちの別のカテゴリーと異なる、付記３６記載の非一過性コンピュータ・アクセス可能記憶媒体。
３９．命令は、該一つ以上のプロセッサで実行されると、
（ａ）ポートレベルの粒度、（ｂ）ネットワーク・インターフェイス・レベルの粒度、（ｃ）バーチャル・マシン・レベルの粒度、（ｄ）ホスト・レベルの粒度、（ｅ）ラックレベルの粒度、（ｆ）データ・センター・ルーム・レベルの粒度、（ｇ）データ・センター・レベルの粒度、（ｈ）利用可能コンテナレベルの粒度、または、（ｉ）地理的領域レベルの粒度のうちの一つを有する、資源ヒートマップを介して表示される一つ以上のメトリックスに対する選択された粒度の表示を受信し、
該選択された粒度に少なくとも部分的に基づいて、該資源ヒートマップに含まれるよう一つ以上のメトリックスを統合する、付記３６記載の非一過性コンピュータ・アクセス可能記憶媒体。
４０．命令は、該一つ以上のプロセッサで実行されると、
該ネットワーク・アクセス可能サービスのクライアントが少なくとも該メトリックスのサブセットをリクエストするようプログラマチック・インターフェイスを実施し、
該プログラマチック・インターフェイスを介して特定のクライアントからメトリック・リクエストを受信し、
該メトリック・リクエストに示される一つ以上のメトリックスを取得する許可が該特定のクライアントに与えられているとの確定に応答して、該特定のクライアントに該一つ以上のメトリックスを提供する、付記３６記載の非一過性コンピュータ・アクセス可能記憶媒体。
例示的コンピュータ・システム
少なくとも幾つかの実施形態では、ネットワーク構成サーバー、ネットワーク構成サービス・マネージャ、トポロジー可視化サーバー、および／または、インスタンス・ホストを実施する技術を含む、本願記載の一つ以上の技術の一部または全部を実施するサーバーは、一つ以上のコンピュータ・アクセス可能媒体を含む或いは該媒体にアクセスするよう構成される汎用コンピュータ・システムを含んでもよい。図２４は、汎用コンピューティング装置３０００を示す。例示する実施形態では、コンピューティング装置３０００は、入力／出力（Ｉ／Ｏ）インターフェイス３０３０を介してシステム・メモリ３０２０に接続される一つ以上のプロセッサ３０１０を含む。コンピューティング装置３０００は、更に、Ｉ／Ｏインターフェイス３０３０に接続されるネットワーク・インターフェイス３０４０を含む。
様々な実施形態では、コンピューティング装置３０００は、一つのプロセッサ３０１０を含むユニ・プロセッサ・システム、または、幾つかのプロセッサ３０１０（例えば、二つ、四つ、八つ、または、別の好適な数）を含むマルチプロセッサ・システムでもよい。プロセッサ３０１０は、命令を実行することができる任意の好適なプロセッサでもよい。例えば、様々な実施形態では、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、または、ＭＩＰＳ ＩＳＡ、或いは、任意の他の好適なＩＳＡ等、様々なインストラクション・セット・アーキテクチャ（ＩＳＡ）のいずれかを実施する汎用の或いは組み込みプロセッサでもよい。マルチプロセッサ・システムでは、各プロセッサ３０１０は、必ずではないが、同じＩＳＡを一般的に実施してもよい。幾つかの実施では、グラフィックス・プロセッシング・ユニット（ＧＰＵ）が従来のプロセッサの代わりに、或いは、それに加えて使用されてもよい。
システム・メモリ３０２０は、プロセッサ３０１０によってアクセス可能な命令およびデータを記憶するよう構成されてもよい。様々な実施形態では、システム・メモリ３０２０は、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ・タイプ・メモリ、または、任意の他のタイプのメモリ等、任意の好適なメモリ技術を用いて実施されてもよい。例示する実施形態では、上述の方法、技術、および、データ等、一つ以上の所望の機能を実施するプログラム命令およびデータは、コード３０２５およびデータ３０２６としてシステム・メモリ３０２０内に記憶されるとして示される。
一実施形態では、Ｉ／Ｏインターフェイス３０３０は、プロセッサ３０１０、システム・メモリ３０２０、および、ネットワーク・インターフェイス３０４０や他の周辺インターフェイス、例えば、データ・オブジェクト・パーティションの物理的レプリカを記憶するために使用される様々なタイプの永続性および／または揮発性ストレージ装置を含む、装置における任意の周辺装置の間のＩ／Ｏトラフィックを調整するよう構成されてもよい。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０は、任意の必要なプロトコル、タイミングまたは他のデータ変換を実施して、一つのコンポーネント（例えば、システム・メモリ３０２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ３０１０）による使用に好適なフォーマットに変換してもよい。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０は、例えば、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）バス規格またはユニバーサル・シリアル・バス（ＵＳＢ）規格の変形例等、様々なタイプの周辺機器用バスを介して取り付けられる装置に対するサポートを含んでもよい。幾つかの実施形態では、Ｉ／Ｏインターフェイス３０３０の機能は、例えば、ノース・ブリッジおよびサウス・ブリッジ等の二つの以上の別個の構成要素に分けられてもよい。更に、幾つかの実施形態では、システム・メモリ３０２０へのインターフェイス等、Ｉ／Ｏインターフェイス３０３０の機能性の幾つかまたは全てがプロセッサ３０１０に直接組み込まれてもよい。
ネットワーク・インターフェイス３０４０は、コンピューティング装置３０００と、例えば、図１乃至図２３に例示される他のコンピュータ・システムまたは装置等のネットワークまたは複数のネットワーク３０５０に取り付けられる他の装置３０６０との間のデータ交換を可能にするよう構成されてもよい。様々な実施形態では、ネットワーク・インターフェイス３０４０は、例えば、イーサネット（登録商標）・ネットワークのタイプ等、全ての好適な有線または無線の総合データ・ネットワークを介して通信をサポートしてもよい。追加的には、ネットワーク・インターフェイス３０４０は、アナログ音声ネットワークまたはデジタル・ファイバー通信ネットワーク等の電気通信／電話技術ネットワークを介して、ファイバー・チャネルＳＡＮ等のストレージ・エリア・ネットワークを介して、または、全ての他の好適なタイプのネットワークおよび／またはプロトコルを介して通信をサポートしてもよい。
幾つかの実施形態では、システム・メモリ３０２０は、対応する方法および装置の実施形態を実施するための、図１乃至図２３について上述したようなプログラム命令およびデータを記憶するよう構成されるコンピュータ・アクセス可能媒体の一実施形態でもよい。しかしながら、他の実施形態では、プログラム命令および／またはデータは、異なるタイプのコンピュータ・アクセス可能媒体で受信され、送信され、または、記憶されてもよい。一般的に、コンピュータ・アクセス可能媒体は、例えば、Ｉ／Ｏインターフェイス３０３０を介してコンピューティング装置３０００に接続されるディスクまたはＤＶＤ／ＣＤ等の磁気的または光学的媒体を含む、非一過性ストレージ媒体またはメモリ媒体を含んでもよい。非一過性コンピュータ・アクセス可能ストレージ媒体は、システム・メモリ３０２０または他のタイプのメモリとして、コンピューティング装置３０００の幾つかの実施形態において含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の全ての揮発性または不揮発性媒体を含んでもよい。更に、コンピュータ・アクセス可能媒体は、ネットワーク・インターフェイス３０４０を介して実施され得る、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電気的、電磁的、または、デジタルの信号を含む送信媒体または信号を含んでもよい。図２４に例示されるような多数のコンピューティング装置の一部または全てが様々な実施形態において説明した機能性を実施するために使用されてもよく、例えば、様々な異なる装置やサーバーで実行されるソフトウェア・コンポーネントが協調して機能性を提供してもよい。幾つかの実施形態では、説明した機能性の一部分は、汎用コンピュータ・システムを用いて実施されることに加えて、または、その代わりに、ストレージ装置、ネットワーク装置、または、特殊目的コンピュータ・システムを用いて実施されてもよい。本願で使用される「コンピューティング装置」といった用語は、少なくともこれらのタイプの装置全てを含み、これらのタイプの装置に制限されない。
結論
様々な実施形態は、更に、前述の説明に応じて実施される命令および／またはデータをコンピュータ・アクセス可能媒体で受信し、送信し、または、記憶することを含む。一般的に、コンピュータ・アクセス可能媒体は、磁気的または光学的媒体、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）等の揮発性または不揮発性媒体、ＲＯＭ等を含むストレージ媒体またはメモリ媒体、並びに、ネットワークおよび／または無線リンク等の通信媒体を介して運ばれる電気的、電磁的、または、デジタルの信号等の送信媒体または信号を含んでもよい。
図中に例示され、本願に記載される様々な方法は、方法の模範的な実施形態を示す。該方法は、ソフトウェア、ハードウェア、または、その組み合わせにおいて実施されてもよい。方法の順序は変更されてもよく、様々な要素が追加される、再順序付けされる、組み合わされる、省略される、変更されるなどされてもよい。
本開示の恩恵を得る当業者には明らかであるように、様々な変更および変化がなされてもよい。これらの変更および変化全てを包含することが意図され、それに応じて、上述の説明は限定的でなく例示的として考えられるべきである。

Claims (15)

  1. 複数のコンピューティング装置が、
    ネットワーク・アクセス可能サービスの一つ以上のサービス・インスタンスでリクエスト時に実施される既存の資源使用限界よりも低い資源使用限界を課すことをクライアントがリクエストすることを可能にするプログラマチック・インターフェイスを実装し、前記低い資源使用限界が前記サービスと関連付けられるネットワーク・トラフィックの少なくとも一つのカテゴリーに適用され、
    前記一つ以上のプログラマチック・インターフェイスの特定のインターフェイスを介して、特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる特定の低い資源使用限界を示すクライアント・リクエストを受信し、
    前記特定のサービス・インスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得し、
    前記特定のサービス・インスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、前記特定の低い資源使用限界から決定される少なくとも一つの閾値レベルに到達したとの決定に応答して、一つ以上の応答作用を開始する、方法。
  2. 前記特定の低い資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送されたデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、請求項１記載の方法。
  3. 前記クライアント・リクエストは、前記特定の低い資源使用限界が適用されるネットワーク・トラフィックの特定のカテゴリーを示し、
    前記特定のカテゴリーは、（ａ）一つ以上の公衆インターネット・リンクにわたって流れるトラフィック、（ｂ）プロバイダ・ネットワーク・データ・センター内を流れるトラフィック、（ｃ）二つのプロバイダ・ネットワーク・データ・センター間を流れるトラフィック、（ｄ）前記サービスのノードと前記プロバイダ・ネットワークで実施される異なるサービスのノードとの間を流れるトラフィックを一つ以上含むサービスと関連付けられるネットワーク・トラフィックの複数のカテゴリーから選択される、請求項１記載の方法。
  4. 前記クライアント・リクエストは、（ａ）前記特定のサービス・インスタンスから一つ以上の宛先エンドポイントに流れるトラフィック、（ｂ）一つ以上のソースから前記特定のサービス・インスタンスに流れるトラフィックの一方を含む、前記低い資源使用限界が適用されるネットワーク・トラフィック・フローの一つ以上の方向を示す、請求項１記載の方法。
  5. 前記クライアント・リクエストは、マルチテナント・ネットワーク・アクセス可能サービスにおいてクライアントの代わりに確立される複数のユーザ・アカウントのうちの特定のユーザ・アカウントを示し、
    前記低い資源使用限界は、前記特定のユーザ・アカウントに適用され、
    異なる資源使用限界は、前記複数のユーザ・アカウントの異なるユーザ・アカウントに適用される、請求項１記載の方法。
  6. 前記一つ以上の応答作用は、（ａ）一つ以上のパケットを破棄する、（ｂ）一つ以上のパケットを待ち行列に入れる、または、（ｃ）該特定のサービス・インスタンスにおいてネットワーク・トラフィックに課せられる資源使用限界を特定の時間期間にわたって増加させることのいずれかを含む、請求項１記載の方法。
  7. 前記一つ以上のコンピューティング装置により、更に、
    前記特定のサービス・インスタンスにおいてネットワーク・トラフィックと関連付けられる測定された資源使用をクライアントが確定することを可能にする異なるプログラマチック・インターフェイスを実施し、
    前記異なるプログラマチック・インターフェイスを介して受信されるリクエストに応答して、前記測定された資源使用の表示を提供する、請求項１記載の方法。
  8. 前記クライアント・リクエストは、前記特定の低い資源使用限界が課せられる時間期間の表示を含む、請求項１記載の方法。
  9. 前記クライアント・リクエストは、（ａ）閾値レベル、または、（ｂ）該一つ以上の応答作用のうちの特定の応答作用の一方の表示を含む、請求項１記載の方法。
  10. 前記ネットワーク・アクセス可能サービスは、プロバイダ・ネットワークのインスタンス・ホストを用いて実施され、前記方法は、
    前記一つ以上のコンピューティング装置により、更に、
    前記プロバイダ・ネットワークの中央化ネットワーク構成サービスの特定のサーバーにおいて、特定されたサービス・インスタンスにおけるそれぞれの低い資源使用限界に対する複数のクライアント・リクエストを受信し、
    前記特定されたサービス・インスタンスのそれぞれのインスタンス・ホストでインスタンス化されたそれぞれの制御モジュールに前記特定のサーバーから該それぞれの低い資源使用限界の表示を送信することを含む、請求項１記載の方法。
  11. プログラム命令を含むメモリに接続される一つ以上のプロセッサを有するシステムであって、前記プログラム命令が前記一つ以上のプロセッサで実行されると、システムに、
    プログラマチック・インターフェイスを介して、ネットワーク・アクセス可能サービスの特定のインスタンスにおいてネットワーク・トラフィックの少なくとも一つのカテゴリーに課せられる既存の資源使用限界よりも低い特定の低い資源使用限界を示すクライアント・リクエストを受信させ、
    前記特定のインスタンスにおけるネットワーク・トラフィックの一つ以上のカテゴリーに対応する資源使用メトリックスを取得させ、
    前記特定のインスタンスにおけるネットワーク・トラフィックと関連付けられる資源使用が、前記特定の低い資源使用限界から決定される少なくとも一つの閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始させる、前記システム。
  12. 前記プログラム命令は、該一つ以上のプロセッサで実行されると、システムに
    前記ネットワーク・アクセス可能サービスの第一および第二のインスタンスにおいてネットワーク・トラフィックに集合的に課せられる組み合わされた資源使用限界を示す異なるクリアント・リクエストを受信させ、
    前記第一および第二のインスタンスにおけるネットワーク・トラフィックと関連付けられる前記資源使用の総和が閾値レベルに到達したとの確定に応答して、一つ以上の応答作用を開始させる、請求項１１記載のシステム。
  13. 前記ネットワーク・アクセス可能サービスは、（ａ）仮想コンピューティング・サービス、（ｂ）ストレージ・サービス、または、（ｃ）データベース・サービスのいずれかを有する、請求項１１記載のシステム。
  14. 前記プログラム命令は、前記一つ以上のプロセッサで実行されると、システムに
    前記ネットワーク・アクセス可能サービスの異なるインスタンスにおいて資源をネットワークすることに対するクライアント予算の上界を示す異なるクリアント・リクエストを受信させ、
    前記異なるインスタンスにおける資源をネットワークすることと関連付けられるクライアント請求金額が閾値を超えたとの確定に応答して、一つ以上の応答作用を開始させる、請求項１１記載のシステム。
  15. 前記特定の低い資源使用限界は、（ａ）超えられてはならない平均的トラフィック送信速度、（ｂ）超えられてはならないバースト・トラフィック送信速度、（ｃ）転送されたデータのバイト数に対する上限、または、（ｄ）転送されたネットワーク・メッセージの数に対する上限のいずれかの表示を含む、請求項１１記載のシステム。
JP2016533633A 2013-11-25 2014-11-25 分散システムにおける顧客志向ネットワークの限界 Expired - Fee Related JP6450759B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US14/089,224 US9647904B2 (en) 2013-11-25 2013-11-25 Customer-directed networking limits in distributed systems
US14/089,230 2013-11-25
US14/089,224 2013-11-25
US14/089,230 US9674042B2 (en) 2013-11-25 2013-11-25 Centralized resource usage visualization service for large-scale network topologies
PCT/US2014/067302 WO2015077756A1 (en) 2013-11-25 2014-11-25 Customer-directed networking limits in distributed systems

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018146686A Division JP6679673B2 (ja) 2013-11-25 2018-08-03 分散システムにおける顧客志向ネットワークの限界

Publications (2)

Publication Number Publication Date
JP2016541183A JP2016541183A (ja) 2016-12-28
JP6450759B2 true JP6450759B2 (ja) 2019-01-09

Family

ID=53180290

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2016533633A Expired - Fee Related JP6450759B2 (ja) 2013-11-25 2014-11-25 分散システムにおける顧客志向ネットワークの限界
JP2018146686A Active JP6679673B2 (ja) 2013-11-25 2018-08-03 分散システムにおける顧客志向ネットワークの限界
JP2020047290A Active JP7057796B2 (ja) 2013-11-25 2020-03-18 分散システムにおける顧客志向ネットワークの限界

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2018146686A Active JP6679673B2 (ja) 2013-11-25 2018-08-03 分散システムにおける顧客志向ネットワークの限界
JP2020047290A Active JP7057796B2 (ja) 2013-11-25 2020-03-18 分散システムにおける顧客志向ネットワークの限界

Country Status (6)

Country Link
EP (3) EP3982270A1 (ja)
JP (3) JP6450759B2 (ja)
CN (2) CN112134741B (ja)
AU (2) AU2014352692B2 (ja)
CA (3) CA3051918A1 (ja)
WO (1) WO2015077756A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10002011B2 (en) 2013-11-04 2018-06-19 Amazon Technologies, Inc. Centralized networking configuration in distributed systems
US9256467B1 (en) * 2014-11-11 2016-02-09 Amazon Technologies, Inc. System for managing and scheduling containers
US10261782B2 (en) 2015-12-18 2019-04-16 Amazon Technologies, Inc. Software container registry service
US10135837B2 (en) 2016-05-17 2018-11-20 Amazon Technologies, Inc. Versatile autoscaling for containers
US10742498B2 (en) 2016-06-22 2020-08-11 Amazon Technologies, Inc. Application migration system
US10212031B2 (en) * 2016-06-22 2019-02-19 Amazon Technologies, Inc. Intelligent configuration discovery techniques
US10412022B1 (en) 2016-10-19 2019-09-10 Amazon Technologies, Inc. On-premises scaling using a versatile scaling service and an application programming interface management service
US10409642B1 (en) 2016-11-22 2019-09-10 Amazon Technologies, Inc. Customer resource monitoring for versatile scaling service scaling policy recommendations
EP3549018B1 (en) * 2016-11-29 2021-04-07 Telefonaktiebolaget LM Ericsson (publ) Distribution of resources among actor instances
CN108363671B (zh) * 2018-02-07 2020-01-14 中国平安人寿保险股份有限公司 一种接口切换的方法、终端设备及存储介质
WO2019168532A1 (en) 2018-03-01 2019-09-06 Google Llc High availability multi-single-tenant services
JP6488421B1 (ja) 2018-09-12 2019-03-20 高周波熱錬株式会社 スナバ回路及びパワー半導体モジュール並びに誘導加熱用電源装置
US11290491B2 (en) * 2019-03-14 2022-03-29 Oracle International Corporation Methods, systems, and computer readable media for utilizing a security service engine to assess security vulnerabilities on a security gateway element
US11669365B1 (en) 2019-08-26 2023-06-06 Amazon Technologies, Inc. Task pool for managed compute instances
CN110519183B (zh) 2019-09-29 2022-12-02 北京金山云网络技术有限公司 一种节点限速的方法、装置、电子设备及存储介质
CN113037794B (zh) * 2019-12-25 2023-04-18 马上消费金融股份有限公司 计算资源配置调度方法、装置及系统
CN111585892B (zh) * 2020-04-29 2022-08-12 平安科技（深圳）有限公司 数据中心流量管控方法和系统
CN112073329B (zh) * 2020-08-25 2023-01-24 北京五八信息技术有限公司 分布式限流方法、装置、电子设备和存储介质
CN115348208B (zh) * 2021-04-27 2024-04-09 中移(苏州)软件技术有限公司 一种流量控制方法、装置、电子设备和存储介质
US11323339B1 (en) * 2021-08-27 2022-05-03 Juniper Networks, Inc. Service placement assistance
CN115277469A (zh) * 2022-07-12 2022-11-01 深圳壹账通智能科技有限公司 弱网可视化控制方法、装置、电子设备及可读存储介质
CN115442310B (zh) * 2022-11-10 2023-01-24 中亿(深圳)信息科技有限公司 基于物联网卡的应用程序流量消耗级别划分方法及装置

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5996090A (en) * 1997-10-29 1999-11-30 International Business Machines Corporation Method and apparatus for quantitative diagnosis of performance problems using external representations
US20030046396A1 (en) * 2000-03-03 2003-03-06 Richter Roger K. Systems and methods for managing resource utilization in information management environments
US20020095498A1 (en) * 2000-06-05 2002-07-18 Accordion Networks Network architecture for multi-client units
CN101277220B (zh) * 2002-10-18 2011-03-30 卡里德恩科技有限公司 用于在基于度量路由的网络中执行流量工程的方法和系统
US7457262B1 (en) * 2004-11-05 2008-11-25 Cisco Systems, Inc. Graphical display of status information in a wireless network management system
US7987272B2 (en) * 2004-12-06 2011-07-26 Cisco Technology, Inc. Performing message payload processing functions in a network element on behalf of an application
JP4589847B2 (ja) * 2005-09-05 2010-12-01 日本電信電話株式会社 動的制御用ネットワークリソース制御方法および動的制御用ネットワークリソース制御装置
US7636318B2 (en) * 2005-12-27 2009-12-22 Solana Networks Inc. Real-time network analyzer
JP2007335997A (ja) * 2006-06-12 2007-12-27 Sharp Corp 携帯通信端末装置
US20080002711A1 (en) * 2006-06-30 2008-01-03 Bugenhagen Michael K System and method for access state based service options
US7895353B2 (en) * 2008-02-29 2011-02-22 Oracle International Corporation System and method for providing throttling, prioritization and traffic shaping during request processing via a budget service
US8065559B2 (en) 2008-05-29 2011-11-22 Citrix Systems, Inc. Systems and methods for load balancing via a plurality of virtual servers upon failover using metrics from a backup virtual server
US20100029282A1 (en) * 2008-07-31 2010-02-04 Qualcomm Incorporated Resource partitioning in heterogeneous access point networks
US8572241B2 (en) * 2010-09-17 2013-10-29 Microsoft Corporation Integrating external and cluster heat map data
JP5666620B2 (ja) * 2010-12-07 2015-02-12 株式会社日立製作所 ネットワークシステム、及びそのサービス品質制御方法
US9565074B2 (en) * 2011-04-26 2017-02-07 Openet Telecom Ltd. Systems, devices, and methods of orchestrating resources and services across multiple heterogeneous domains
US8831041B2 (en) * 2011-06-27 2014-09-09 Citrix Systems, Inc. Prioritizing highly compressed traffic to provide a predetermined quality of service
WO2013158926A1 (en) * 2012-04-19 2013-10-24 2Nd Watch, Inc. Cloud computing consolidator billing systems and methods

Also Published As

Publication number Publication date
JP2020096385A (ja) 2020-06-18
EP3982270A1 (en) 2022-04-13
CA2931524C (en) 2019-09-24
CN112134741A (zh) 2020-12-25
CA3051933A1 (en) 2015-05-28
EP3074876B1 (en) 2020-03-18
AU2017251757A1 (en) 2017-11-16
CA3051918A1 (en) 2015-05-28
EP3074876A1 (en) 2016-10-05
JP6679673B2 (ja) 2020-04-15
JP2018170803A (ja) 2018-11-01
AU2014352692A1 (en) 2016-06-09
AU2017251757B2 (en) 2019-09-12
WO2015077756A1 (en) 2015-05-28
JP7057796B2 (ja) 2022-04-20
CN105765556A (zh) 2016-07-13
AU2014352692B2 (en) 2017-08-03
EP3671480A1 (en) 2020-06-24
CN112134741B (zh) 2023-09-05
JP2016541183A (ja) 2016-12-28
CA2931524A1 (en) 2015-05-28
EP3671480B1 (en) 2022-01-05
EP3074876A4 (en) 2017-06-28

Similar Documents

Publication Publication Date Title
JP7057796B2 (ja) 分散システムにおける顧客志向ネットワークの限界
US10855545B2 (en) Centralized resource usage visualization service for large-scale network topologies
US9647904B2 (en) Customer-directed networking limits in distributed systems
JP7116759B2 (ja) 分散システムにおける集中ネットワーク構成

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170523

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170711

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171011

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180803

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180809

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181113

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181210

R150 Certificate of patent or registration of utility model

Ref document number: 6450759

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees