JP2016540465A - 分散システムにおける集中ネットワーク構成 - Google Patents

Abstract

分散システムにおける集中ネットワーク構成方法及び装置を開示する。分散システムにおける複数ソースからのネットワーク関連メトリクスは、ネットワーク構成サーバにおいて取得される。ネットワーク構成オプションを分散システムのノードに関連する特定のトラフィックカテゴリに適用するのに使用される一連の規則は、収集されたメトリクス及びネットワーク管理方針に基づき判断される。一連の規則の表示は、ネットワーク構成オプションに従いネットワーク送信の予定を組む分散システムのノードに送信される。【選択図】図１

Description

多くの企業及び他の組織は、同一場所に配置された（例えば、ローカルネットワークの一部として）、またはその代わりに地理的に異なる複数の場所に配置された（例えば、１以上のプライベートまたは公衆中間ネットワークを介して接続された）計算システムなど、数多くの計算システムを相互接続してそれらの動作を支援するコンピュータネットワークを運用している。例えば、単一の組織によりその組織のために運用されているプライベートデータセンタや、ビジネスとして顧客に計算資源を提供するエンティティによって運用されている公共データセンタなど、膨大な数の相互接続された計算システムを収容するデータセンタが一般的になってきている。公共データセンタの運営者の中には、ネットワークアクセス、電力、及び多様な顧客が所有するハードウェア用の安全な設置施設を提供するものもあれば、顧客が利用可能なハードウェア資源も含め「フルサービス」施設を提供するものもある。しかしながら、標準的なデータセンタの規模及び範囲が増大するにつれ、物理的な計算資源の提供、管理、及び運営タスクがますます複雑化してきている。

市販ハードウェアを対象とした仮想化技術が出現したことで、多様なニーズを有する数多くの顧客に大規模計算資源を管理する恩恵がもたらされ、多様な計算資源を複数の顧客が効率的にかつ安全に共有することが出来るようになった。例えば、仮想化技術により、１台の物理コンピュータマシンにホストされた１以上の仮想マシンを各ユーザに提供することで１台の物理コンピュータマシンを複数のユーザで共有できるようにしてもよい。そのような各仮想マシンは、個別の論理計算システムとして動作するソフトウェアシミュレーションであり、ユーザに所定のハードウェア計算資源の唯一のオペレータ及びアドミニストレータであると思わせ、一方、多様な仮想マシン間でアプリケーションを隔離し安全性も提供する。さらに、仮想化技術の中には、別個の複数の物理計算システムを繋ぐ複数の仮想プロセッサを有する単一の仮想マシンなど、２以上の物理資源を繋ぐ仮想資源を提供できるようにするものがある。

仮想化した計算、記憶、及びネットワーク資源のプロバイダがサポートする機能が増大し特徴が多様になるにつれ、また、大規模プロバイダが使用するハードウェアプラットフォームグループが増大するにつれ、管理ネットワークトラフィックフローなど、プラットフォームでの管理制御動作の実施は、かなり複雑になる。多くの場合、そのようなプラットフォーム上で実行されるアプリケーションの機能性及び操作性は、プロバイダネットワークのその他の部分との、及び／または、クライアントまたは第三者などの外部エンティティとのネットワーク通信に広く依存してもよい。所望のアプリケーション実行レベルを達成しようとする場合、そのような分散システムのオペレータは、一般的に高帯域幅ネットワークインフラをセットアップしてもよい。しかし、高帯域幅ネットワークデバイス及びリンクを設けても、特に、配置したアプリケーションの多くのタイプに対する時変位置依存の帯域幅要件では、多くの場合ネットワーク帯域幅がボトルネック資源となるかもしれない。単一のハードウェアプラットフォームで実施される多様な仮想マシンは、幅広いネットワーク要件をプラットフォームの共有ネットワークコンポーネントを用いて満たさなければならず、また、一連のアプリケーション、及び、所定のハードウェアプラットフォームでインスタンス化される仮想マシンが、時間とともに変化するため、仮想化すると、管理ネットワーク帯域幅（レイテンシ及び他のネットワーク特性についても）がさらに難しい問題となるかもしれない。

少なくともいくつかの実施形態において、集中ネットワーク構成サービスを実施し、分散型計算環境の複数ノードでネットワークトラフィックを管理するシステムの実施例を示す。 少なくともいくつかの実施形態において、それぞれのネットワーク構成サーバが複数の可用コンテナのそれぞれに設置されたプロバイダネットワーク環境の実施例を示す。 少なくともいくつかの実施形態において、仮想化計算サービスのインスタンスホストにおいてトラフィック分類メタデータを解釈可能なネットワーク管理モジュールの実施例を示す。 少なくともいくつかの実施形態において、インスタンスホストへのトラフィック分類メタデータの送信に用いられてもよいプロトコルのそれぞれの実施例を示す。 少なくともいくつかの実施形態において、分散システムの装置におけるネットワーク構成のネットワークトラフィックカテゴリの表示に使用されてもよい分類ツリーデータ構造の実施例を示す。 少なくともいくつかの実施形態において、データセンタにおける複数のインスタンスホストに関するネットワークトラフィックカテゴリ情報の結合に使用されてもよい階層式データ構造の実施例を示す。 少なくともいくつかの実施形態において、分類ツリーと併せて使用しネットワークトラフィック単位のカテゴリを判断してもよいトラフィック分類プロシージャグラフの実施例を示す。 少なくともいくつかの実施形態において、トラフィック分類プロシージャグラフでのルックアップテーブルノードの使用実施例を示す。 少なくともいくつかの実施形態において、ネットワーク構成サービスの１以上のパラメータ値の判断に利用されてもよい応答性メトリクスの実施例を示す。 少なくともいくつかの実施形態において、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実施されてもよい動作態様を示すフロー図である。 少なくともいくつかの実施形態において、ネットワーク構成サービスのトラフィック分類メタデータを生成し配布するよう実施されてもよい動作態様を示すフロー図である。 少なくともいくつかの実施形態において、トリガイベントに応答してネットワーク管理パラメータを変更するよう実施されてもよい動作態様を示すフロー図である。 少なくともいくつかの実施形態において、ネットワーク関連状態情報の統合図を分散システムのクライアントに提供するよう実施されてもよい動作態様を示すフロー図である。 少なくともいくつかの実施形態において使用されてもよい例示的な計算装置を示すブロック図である。

本明細書では、複数の実施形態及び説明図を例に挙げ実施形態を説明するが、当業者であれば実施形態が説明の実施形態または図に限定されるものではないとわかるであろう。図及び図の詳細説明は、開示した特定の形態に実施形態を限定する意図はなく、反対に、あらゆる変更、均等物及び代替物を、添付の請求項で定める趣旨及び範囲に含めることを意図する。本明細書で使用する見出しは、単に構成上の理由によるものであり、本説明または本請求項の範囲を限定するものではない。本出願を通して用いるように、「してもよい」「かもしれない」は許容を意味し（すなわち、可能性があることを意味する）、命令の意味（すなわち、しなければならないを意味する）ではない。同様に、「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」は、含むがそれに限定されないことを意味する。

プロバイダネットワークなど大規模分散システムでのネットワーク運用の構成方法及び構成装置の多様な実施形態を説明する。ある実施形態において、分散システムの多数のノード（ホスト及びネットワークデバイスなど）の帯域幅制限、レイテンシ管理、及び、その他トラフィック形成パラメータについて１以上のネットワーク構成サーバ（ＮＣＳ）においてなされた様々な判断に従い、集中ネットワーク構成管理スキームを実行してもよい（ある実施形態において、ネットワーク構成サーバを、「帯域幅調整サーバ」としてもよい。多様なトラフィックカテゴリにそれぞれの帯域幅制限を課した、分散システムのコンポーネントでの帯域幅使用管理が、サーバの第一義的責任であるためである）。例えば、判断を実施するのに使用するメタデータは、トラフィック分類プロシージャまたは規則、及び、多様なトラフィックカテゴリに対するネットワーク構成オプションを含むが、当該メタデータは、ＮＣＳから分散システムのノードに、移動可能な解析しやすいフォーマットで送信されてもよい。分散システムのノードにおいて、受信メタデータを、例えば、仮想化管理ソフトウェア内のネットワーク管理モジュールにより解釈し、ネットワークトラフィック予定のパケットまたはその他単位を、パケットまたはその他単位が生成または受信された時に分類し、ＢＡＳでの判断を適用してトラフィック送信の予定組み及び／または調整を行ってもよい。トラフィック形成（少なくともいくつかの場合において、多様なソースから得られる重要な一連の入力データの解析を要してもよい）に使用するロジックを生成する役割を集中ネットワーク構成サーバが担い、比較的単純な制御モジュールがロジックを多様なノードに適用してもよい。所定のノードに送信されたメタデータは、少なくともいくつかの実施形態において、ノードから収集したメトリクス、及び、当該ノードで実行されるアプリケーションの特性などに基づいて、当該ノード専用にカスタマイズされてもよい。いくつかの実施形態において、ネットワーク構成管理技術はプログラマチックインタフェースをサポートしてもよく、当該プログラマチックインタフェースにより、分散システムのクライアントが、対象資源のネットワークの関係性を示す統合または連結図を入手し得る。また、少なくともいくつかの実施形態において、プログラマチックインタフェースを実施し、クライアント及び／またはアドミニストレータが、集中ネットワーク構成システムに多様な構成要求を出せるようにし、そのことで、例えば、ＮＣＳで判断され多様なノードに発信された分類関連規則及び／またはネットワーク設定を変更することになってもよい。少なくともいくつかの実施において、一部または全てのネットワーク構成スキームを、例えば１以上のウェブサービスなどのウェブサービスとして実施し、プログラマチックインタフェースによるネットワーク構成サーバとの多様な対話をサポートしてもよい。

以下の説明において多くの場合、プロバイダネットワークを分散システムの実施例としており、当該分散システムでは、集中ネットワーク構成技術を実施してもよい。ネットワークは、企業または公共組織などの主体により設定され、インターネット及び／またはその他ネットワークを介して一連の分散クライアントにアクセス可能な１以上のネットワークアクセス可能サービス（様々なクラウド型のデータベース、計算または記憶サービスなど）を提供する。当該ネットワークを、本明細書ではプロバイダネットワークと呼んでもよい。少なくともいくつかのサービスを、クライアントが使用できるよう「インスタンス」と呼ばれるサービス単位にまとめ、例えば、仮想化計算サービスによりインスタンス化された仮想マシンを「計算インスタンス」とし、記憶サービスによりインスタンス化されたブロックレベルボリュームなどの記憶装置を「記憶インスタンス」としてもよい。いくつかの実施形態において、上位サービスのインスタンスを計算インスタンス及び／または記憶インスタンスを用いてまとめてもよく、例えば、いくつかの実施形態において、計算及び記憶インスタンスを組み合わせて、データベースインスタンスを構築してもよい。プロバイダネットワークの多様なネットワークアクセス可能サービスをそのような単位にしたサーバ及び／または記憶装置などの計算装置を、本明細書では「インスタンスホスト」、またはより簡潔に「ホスト」とするかもしれない。以降本書では、所定の通信元（ソース）または通信先として使用される用語「クライアント」を、計算装置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールのいずれかとしてもよく、当該計算装置、プロセス、ハードウェアモジュールまたはソフトウェアモジュールは、プロバイダネットワークの少なくとも１つのネットワークアクセス可能サービスへのアクセス及び使用が可能な主体（組織、複数ユーザグループ、または単独ユーザなど）により所有され、または管理され、あるいは主体に割り当てられている。

所定のプロバイダネットワークは、多くのデータセンタ（地理的に異なる地域に分散されてもよい）を備えてもよく、当該データセンタは、物理及び／または仮想コンピュータサーバ、それぞれが１以上の記憶装置を有する記憶サーバ、ネットワーク設備などの集まりなど、多様な資源プールをホストし、プロバイダが提供するインフラ及びサービスの実施、構成及び分散には必要である。多種多様なハードウェア及び／またはソフトウェアコンポーネントの中には、種々のデータセンタで、または地理的に異なる地域でインスタンス化または実行されるものがあるが、多様な実施形態において、当該多種多様なハードウェア及び／またはソフトウェアコンポーネントをまとめて使用し、各サービスを実施してもよい。クライアントは、クライアントが所有またはクライアントが管理する設備、または、プロバイダネットワークの外部にあるデータセンタに設置された装置から、及び／または、プロバイダネットワーク内にある装置からの資源及びサービスとプロバイダネットワークにおいて対話してもよい。少なくともいくつかの実施形態において、多様な計算インスタンスを提供する仮想化計算サービスをプロバイダネットワーク内で実施し、そのような計算インスタンスをクライアントに割当ててもよい。外部からのアクセスと同様、そのような計算インスタンスからプロバイダネットワークの別のサービスにアクセスしてもよい。本明細書で説明する帯域幅管理技術の多くを実施する１つの例示的なコンテキストとしてプロバイダネットワークは機能を果たしているが、当該技術をプロバイダネットワーク以外の別の分散システム、例えば、アプリケーションの種々のコンポーネントが時変帯域幅を要するような大規模分散型環境に、適用してもよいことに注意する。

少なくとも一つの実施形態によれば、ＮＣＳの数及び分散を、例えば、以下で説明する性能及び／または可用性基準に基づき判断し、多数のＮＣＳをプロバイダネットワーク内の様々な位置でインスタンス化してもよい。プロバイダネットワークで実施される多様なサービスのインスタンスホストから、及び／または、多様なネットワークデバイス（スイッチ、ルータ、ゲートウェイなど）からなど、プロバイダネットワークの多様なノードから、ネットワーク関連メトリクスを取得するようＮＣＳを構成し、帯域幅管理での判断をしやすくしてもよい。多様な実施形態において、例えば、ある時間間隔における所定ホストでの実流入出ネットワークトラフィック、ある時間間隔に破棄したパケット数、現帯域幅制限で送信が遅延したパケット数、パケットサイズ、アプリケーションのために所定ノードで流入出トラフィックが発生するアプリケーション、クライアントのためにトラフィックが開始されるクライアント、及び／または、多様な送信に係わるエンドポイントのＩＰアドレスなど、多様な情報を収集してもよい。また、いくつかの実施形態において、別のソースからの入力を帯域幅管理の判断に使用してもよい。例えば、セキュリティサービスをいくつかのプロバイダネットワークで実施し、分散サービス妨害（ＤＤＯＳ）攻撃などのネットワーク侵入または攻撃を特定しようとし、潜在的攻撃を警戒し、帯域幅制限を変更するかトラフィックカテゴリの定義に反映させてもよい。少なくとも一つの実施形態において、プロバイダネットワークは、例えば、管理及び／または課金するため、ＩＰアドレス毎にまたはクライアント毎にネットワークトラフィックメトリクスを集めるサービスを備え、そのようなアグリゲータがＮＣＳに入力を行ってもよい。いくつかの実施形態において、プロバイダネットワークの１以上のネットワークアクセス可能サービスのクライアント及び／またはアドミニストレータは、帯域幅関連要求またはその他構成要求をＮＣＳに出し、例えば、特定のインスタンスホストまたはネットワークデバイスの１以上の帯域幅管理パラメータをオーバーライドしてもよい。また、そのような要求をＮＣＳで行う判断に反映させてもよい。

少なくとも一部のそのような入力に基づいて、所定のＮＣＳは、プロバイダネットワークの所定ノードで使用する、多様なネットワーク構成オプション及び／またはプロシージャを判断してもよい。パラメータを判断する際は場合により、１以上のグローバル及び／またはローカルネットワーク管理方針も考慮してもよい。一実施形態において、一連のトラフィックカテゴリまたはトラフィックカテゴリのヒエラルキを、カテゴリ毎に、帯域幅制限、レイテンシ目標または制約などの多様なネットワーク構成オプションと合わせ、判断してもよい。いくつかの実装では、フラットな分類（１階層しかないヒエラルキに相当する）を使用してもよいが、その他の実装では、種々の階層のノード間で親子関係を有する複数階層ヒエラルキを使用してもよい。以下の説明において、本明細書で使用する用語「ヒエラルキ」は、１階層分類またはフラット分類、及び、親子関係を示す複数階層分類の両方を包含するものとする。ヒエラルキに加えて、任意の所定のネットワークパケット（または、データ転送に適した任意の単位）をいずれかのカテゴリに分類するために使用されるプロシージャ（例えば、一連の判断ステップまたは適用される規則）も判断してもよい。トラフィックカテゴリに関する情報、及び、カテゴリに対するトラフィック単位のマッピングに用いるロジックまたは規則を、本明細書ではまとめて「トラフィック分類メタデータ」または「分類メタデータ」と呼んでもよい。少なくともいくつかの実施形態において、所定のホストが、他のホストとは異なるサービスインスタンスの組合せを備えてもよく、また、所定のホストのサービスインスタンスで実行されるアプリケーションのネットワーク要件は、他のアプリケーション（同一ホストか他のホストのいずれかにおいて）のネットワーク要件とは異なってもよいので、ホスト毎に、適する一連のネットワーク構成パラメータが異なってもよい。これにより、少なくともいくつかの実施形態において、分類メタデータは、少なくともいくつかのノード用にカスタマイズされてもよい。例えば、インスタンスホストＩＨ１などプロバイダネットワークの１つのノード用に生成された分類メタデータは、インスタンスホストＩＨ２など別のノード用に生成された分類メタデータとは異なってもよい。種々の一連のトラフィックカテゴリを種々のノード用に定義してもよく、例えば種々の帯域幅制限またはレイテンシ要件を同一のトラフィックカテゴリに設定してもよく、あるいは、トラフィック単位分類プロシージャの少なくともいくつかのステップが異なってもよい。少なくともいくつかの実装において、スイッチ、ルータ、ゲートウェイ、またはロードバランサなどの多様なネットワークデバイス用、またはネットワークに取り付けられた記憶装置用に判断されたネットワーク構成パラメータを、デバイスに関連するかデバイスに影響を受ける一連のホストの帯域幅管理パラメータの少なくとも一部から導出してもよい。例えば、特定のスイッチを８つのホストとの流入出トラフィックに使用する場合、あるトラフィックカテゴリ用のスイッチの帯域幅制限を８つのホストの帯域幅制限から導出してもよい。

所定ノードのＮＣＳにより定義されるトラフィックカテゴリは、種々の実施形態で様々な特性において互いに異なってもよい。一実施形態において、種々の一連のネットワークエンドポイントに種々のカテゴリが生成されてもよい。例えば、トラフィック先（またはソース）のＩＰ（インタネットプロトコル）アドレスを使用し、トラフィックを分類してもよい。別の実施形態において、アプリケーションのためにトラフィックが流れるアプリケーションの種類をトラフィック分類に使用してもよい。例えば、データベース関連トラフィックを１つのカテゴリとし、高性能計算関連トラフィックをまた別のカテゴリとしてもよい。いくつかの実施形態において、クライアントのためにトラフィックが生成されるクライアントを作成し、及び／または、クライアントの予算、または、クライアントとの契約上の合意の態様を用いて、トラフィックカテゴリを定義してもよい。分散システムで複数のネットワークアクセス可能サービスを実施するいくつかの実施形態において、サービスのために特定のトラフィック単位が生成されるサービスに基づき、トラフィックカテゴリを定義してもよい。サービスベースの分類を現在使用し、所定パケットが２以上のサービスに関連する場合、例えば、データパケットを、データベースサービスのデータベースインスタンスのために記憶サービスから転送すれば、多様な実施形態において、パケットは、ソースサービス（すなわち、送信側）または通信先サービス（受信側）に属するとして分類されてもよい。少なくとも一つの実施形態において、クライアントは、ネットワーク構成サービスにより使用されトラフィック単位を分類できる１以上のプロパティを指示してもよい。例えば、クライアントは、少なくとも一時的にいくつかの一連の計算インスタンスが優先度の高いインスタンスであると特定されるよう要求し、当該インスタンスとの流入出トラフィックを、帯域幅制限が広く優先度が高いトラフィックとして分類してもよい。

いくつかの実施形態において、ＮＣＳは、ツリー型などの階層データ構造を用いて、各帯域幅制限及び／またはその他ネットワーク構成オプションをツリーの各ノードに割当て、所定プロバイダネットワークノードのトラフィックカテゴリをモデル化するか表示してもよい。少なくともいくつかの実施において、帯域幅集計方針を分類ツリーに適用してもよい。そのような方針に従い、ツリーにおいて子ノードＣ１、Ｃ２・・・、Ｃｋを有する所定の親ノードＰがＸビット／秒の帯域幅制限を有している場合、所定時間間隔の子ノードＣ１、Ｃ２・・・、Ｃｋに関連する実トラフィックの合計が親の帯域幅制限を超えなくてもよい。Ｐの流出トラフィックの帯域幅制限を１Ｇビット／秒に設定し、Ｐが２つの子ノードＣ１及びＣ２を有し、それぞれの流出トラフィックの帯域幅制限も１Ｇビット／秒に設定する一実施例を例にとる。所定秒中に、Ｃ１のトラフィックとして分類された０．６Ｇビットのトラフィックがインスタンスから流れた場合、Ｃ２に対し定義された個別の制限が高くても、Ｃ２のトラフィックとして分類されたわずか０．４Ｇビットのトラフィックを許容することができる。多様な実施形態において、当然、レイテンシ制約または目標、サービス品質目標、パケットフラグメンテーション設定、または少なくとも一部のパケットサイズに応じた設定など、ＮＣＳが判断するネットワーク構成オプションの中には、親子関係に基づく集計方針が適さないか、有用でないものがあってもよい。

一連のトラフィックカテゴリの表示にツリー構造またはツリー状構造を用いる他に、いくつかの実施形態において、ＮＣＳは第二データ構造も生成し、トラフィック単位をカテゴリに分類するのに使用するプロシージャをモデル化してもよい。第二データ構造は、分類プロシージャグラフと呼ばれ、いくつかの実装において、１以上の列の判断ノードを備えており、所定列の一続きのノードにより、トラフィック単位をより詳細なカテゴリに分類するのに使用する１以上の基準を示してもよい。少なくとも一つの実装において、分類プロシージャグラフの判断ノードの中には、複数のカテゴリ選択の中から１カテゴリを選択するのに使用するルックアップテーブル（例えばハッシュテーブル）を備えるものがあってもよい。ルックアップテーブルのエントリを、分類対象のネットワークトラフィック単位の１以上のプロパティに基づいてインデックス化してもよい。例えば、送付先またはソースＩＰアドレスの一部または全てをインデックス化するのに使用し、あるいは、別のパケットヘッダフィールドまたはパケット本体コンテンツの一部を使用しテーブル内の特定のエントリを探すようにしてもよい。少なくともいくつかの実施形態において、ルックアップテーブルのエントリが、順番に別の分類プロシージャグラフまたはサブグラフに繋がっていてもよい。このため、そのような実装において、パケットの所定プロパティが、まず、複数あるルックアップテーブルのエントリ候補の中からルックアップテーブルのエントリを一つ選択することに繋がり、選択したルックアップテーブルのエントリを処理することで、順番に別の１連の判断ノード（判断ノード自体が別のルックアップテーブルを備えてもよい）をトラバースすることになり、最終的にパケットのカテゴリを特定してもよい。多様な実施形態において、そのようなプロシージャステップを用いて、ネットワークパケット及び／またはその他トラフィック単位をかなり詳細に分類するきめの細かいカテゴリマッピングを定義し、高性能なトラフィック形成を可能にしてもよい。少なくともいくつかの実装において、流入出トラフィックに種々の分類ヒエラルキ及び／またはプロシージャを生成してもよい。

いくつかの実施形態において、ＮＣＳは、ネットワーク構成オプションと関連する一連のトラフィックカテゴリ、及び、ネットワークトラフィック単位をカテゴリにマッピングするロジックを備えるメタデータを前もって生成しておき、メタデータが適用されるノードに送信するためのメタデータの移動可能表示を生成してもよい。例えば、多様な実装において、メタデータの１つまたは双方のコンポーネントを、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＹＡＭＬ（シリアライゼーション形式であり、そのアクロニムの由来は、「Ｙｅｔ Ａｎｏｔｈｅｒ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（また別のマークアップ言語）」または「ＹＡＭＬ Ａｉｎ’ｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＹＡＭＬはマークアップ言語ではない）」など多数ある）などの業界標準プロトコルまたは言語に従い、コード化してもよい。別の実装において、独自コード化技術またはプロトコルを使用し、移動可能型データ構造を生成してもよい。

移動可能表示を、プロバイダネットワークまたは分散システムの対象ノードに送信してもよく、当該ノードは、例えば、ネットワーク管理モジュールなどの制御／管理モジュールなどであるが、表示解析も、プロシージャグラフが示すプロシージャの実施もできるわけではない。受信メタデータを用いて、多様なトラフィック単位を対象ノードで適切なカテゴリに継続して分類し、各トラフィックカテゴリに示す帯域幅制限またはレイテンシ要件などのネットワーク構成オプションに従い、多様なネットワーク送信の予定し、及び／または、調整しまたは延期してもよい。そのような送信中に収集したメトリクスをＮＣＳにフィードバックし、後のためにメタデータを改良可能にしてもよい。フィードバックループをＮＣＳとノードとの間に確立し、ＮＣＳでなされた決定を当該ノードで最終的に実施する。こうして、ネットワーク管理パラメータの長期的な動的調整が可能になる。多様な実施形態において、そのようなカスタム可能なトラフィック分類及び構成技術を用いることにより、集中ネットワーク構成システムがプロバイダネットワークの様々な部分でトラフィックを所望する粒度まで制御し形成できるようになる。

種々の実施形態において、多様な手法を用いて対象ノードに分類メタデータを配布してもよい。例えば、一実施形態において、ＮＣＳは、当該ＮＣＳを割り当てられた各ホスト及び／または各ネットワークデバイスに定期的に（例えば、少なくともＸ分毎に１回）分類メタデータを「プッシュ」するよう設定されてもよい。いくつかの実施形態において、多様なトリガイベント（潜在的なネットワーク侵入または攻撃の検出など）を要因として、新規の分類メタデータを配布してもよい。例えば、攻撃による影響を軽減または限定的にするために、以下で詳述するように、いくつかの１連のノードで帯域幅制限を狭めるか、低帯域幅制限の新しいカテゴリを定義してもよい。別の実施形態において、プロバイダネットワークの少なくともいくつかのノードは、割り当てられたＮＣＳからトラフィック分類メタデータを「プル」してもよく、例えば、ＮＣＳにメタデータ要求を送信し、応答でメタデータを受信する。いくつかの実施形態において、予定プッシュ技術、トリガイベント型メタデータ配布、及び／またはノード開始型プル技術を組み合わせて用いてもよい。

いくつかの実施形態において、プロバイダネットワークまたは別の分散システムを、地理的に異なる複数地域に構成し、各地域は１以上の可用コンテナを備えてもよい。可用コンテナを本明細書では「可用ゾーン」とも呼ぶ。また、可用コンテナは１以上の異なる地点またはデータセンタを備え、所定の可用コンテナにある資源を別の可用コンテナで起きた故障から切り離すよう設計されてもよい。つまり、１つの可用コンテナでの故障が、時間的にまたは原因となって別の可用コンテナでの故障に繋がることがないようにし、資源インスタンスまたは制御サーバの可用プロファイルが、別の可用コンテナの資源インスタンスまたは制御サーバの可用プロファイルから分離されるようにしてもよい。クライアントは、各可用コンテナで複数のアプリケーションインスタンスを起動させて、単一の地点で起きた故障からクライアントのアプリケーションを保護できるようしてもよい。それと同時に、いくつかの実装において、同じ地理的地域内にある資源インスタンス間を安価でレイテンシの少ないネットワークで接続してもよい（また、同じ可用コンテナの資源間でのネットワーク送信を一層高速にしてもよい）。ネットワーク構成システムの可用性及び／または性能を所望のレベルまで引き上げるために、そのようないくつかの実施形態において、少なくとも一つのネットワーク構成サーバを各可用ゾーンにセットアップしてもよい。いくつかの実施形態において、少なくも一つのＮＣＳを各データセンタ内に設置してもよい。いくつかの実施形態において、所与の地域、可用コンテナ、またはデータセンタに設置するＮＣＳの数を、少なくとも一部の性能要件に基づき判断してもよい。例えば、ネットワーク構成システムが、変更帯域幅制限を生成し、適した一連のノードに変更制限を適用して、ネットワーク攻撃またはその他トリガイベントに対応できる即応性に基づき判断する。

一実施形態によれば、ネットワーク構成システムにより１以上のプログラマチックインタフェース（ＡＰＩ（アプリケーションプログラミングインタフェース）、ウェブページ、コマンドラインツール、グラフィカルユーザインタフェースなど）を実施し、プロバイダネットワークのクライアント及び／またはその他サービスにより使用可能にしてもよい。そのような一実施形態において、上述したように、多様なサービスのクライアントまたはアドミニストレータは、帯域幅オーバーライド要求などの構成要求を出し、特定のサービスインスタンスまたはホストのネットワーク構成オプションを設定または変更してもよい。クライアントの中には、例えば、少なくともある時間間隔の少なくともいくつかのアプリケーションに対する帯域幅制限の拡大（または縮小）を望むものがあるかもしれない。いくつかの実施形態において、所定のクライアントに、多数のサービスインスタンス（何百何千もの計算インスタンス、記憶インスタンス、データベースインスタンスなど）を割り当て、当該クライアントが、サービスインスタンスのサブセットの最新ネットワーク連結図（利用可能帯域幅制限、レイテンシ設定などを含む）の入手を希望するかもしれない。いくつかの実施形態において、例えば、プロバイダネットワークのコンソールサービス、または、その他連結ネットワーク図作成装置で、ネットワーク構成サービスのプログラマチックインタフェースを用いて、そのような統合図を提供してもよい。また、いくつかの実施形態において、起動予定の新サービスインスタンス用のインスタンスホストの特定を担うインスタンス配置サービスなどの他のサービスで、プログラマチックインタフェースを用いてもよい。新サービスインスタンスの候補として特定のインスタンスホストを検討する場合、そのような配置サービスは、プログラマチックインタフェース上で用いてネットワーク構成サービスから情報を入手し、新サービスインスタンスの配置判断にそのような情報を使用してもよい。当該情報は、例えば、当該候補での最近の帯域幅使用傾向、最近調整されたネットワーク送信回数、及び／または、当該インスタンスホストの現在確立されているネットワーク帯域幅制限またはレイテンシ設定などである。
システム環境の実施例

図１は、少なくともいくつかの実施形態において、集中ネットワーク構成サービスを実施しネットワークトラフィックを分散計算環境の複数のノードで管理する、システム１００の実施例を示す。図示したように、ＮＣＳ１８０Ａ及びＮＣＳ１８０Ｂなどのネットワーク構成サーバ１８０のプール１８２を設置してもよい。いくつかの実施形態において、図２に示し以下で説明するように、複数のＮＣＳ１８０を計算環境の多様なデータセンタに分散させてもよい。種々の実施形態において、所定のＮＣＳ１８０は、例えば、１以上のソフトウェア及び／またはハードウェアモジュールを備えてもよく、場合により、ＮＣＳ自体を複数の計算装置を用いて実施してもよい。多種多様なソースから入力を受信するようＮＣＳ１８０を構成してもよい。ＮＣＳは、分散計算環境の多様な要素で適用される帯域幅制限など、カスタム可能トラフィック分類ロジック及びネットワーク構成オプションを、入力に基づいて、及び／または、図の実施形態のグローバルネットワーク管理方針１２２を考慮して、判断してもよい。ネットワーク構成サービスの面から、分散計算環境の要素を、測定関連コンポーネント１０７、判断コンポーネント１０８、及び実施コンポーネント１０９の３つの上位カテゴリに分類してもよい。測定関連コンポーネント１０７は、ＮＣＳへの多様な入力ソースを備えてもよい。判断コンポーネント１０８は、ＮＣＳ自体を備えてもよい。実施コンポーネント１０９は、判断を実行してネットワークトラフィックを形成するか、判断コンポーネントによって生成された出力を他の目的に利用するエンティティであってもよい。フィードバックループについては、従来通りの制御システムフィードバックループと類似のフィードバックループが構築され、いくつかの実施コンポーネント（サービスインスタンスホスト１４４及び／またはネットワークデバイス１４５など）から測定値を入手し、メトリクスを用いてＮＣＳ１８０により以後の判断を行ってもよい。当該判断の結果、測定をさらに行い、以後の判断に影響を与えることになってもよい。

図の実施形態において、例えば、多種多様なネットワーク関連メトリクスが、メトリクスコレクタ１２５によりインスタンスホスト１４４及び／またはネットワークデバイス１４５から集められ、ＮＣＳ１８０がアクセス可能なメトリクスデータベース１９０に配置されてもよい。例えば、そのようなメトリクスは、ある時間間隔における所定のホストでの流入出ネットワークトラフィクレート（例えば、バイトまたはパケットで表示する）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）またはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）など多様なプロトコルに対応するネットワーク接続数、ある時間間隔における廃棄パケット数及びパケット廃棄原因、現帯域幅制限の実施による通信遅延パケット数、パケットサイズ分布、アプリケーションのために所定ノードとのトラフィック流入出がなされるアプリケーション、クライアントのためにトラフィックが開始されるクライアント、パケット送出に関連するレイテンシ、及び／または多様な送信に係わるエンドポイントのＩＰアドレスを含んでもよい。データベース１９０に保存されたメトリクスの他に、ＮＣＳは、例えば、セキュリティサービス１１１またはトラフィックメトリクスアグリゲータ１１２などの、システム１００の追加入力データソース１１０からの入力も受信してもよい。システム１００の様々な部分でトラフィックパターンを監視するようセキュリティサービス１１１を構成し、ネットワーク侵入または攻撃（システム１００の外部の、例えば、公衆インターネットの多様な位置が送信元であるものもあれば、インスタンスホスト１４４自体が送信元であるものもあるかもしれない）を検出してもよい。不審なトラフィックパターンを検出した場合、例えば、所定のネットワークアドレスに向けたトラフィックが突如連続してバーストした場合、セキュリティサービス１１１は、ＮＣＳ１８０に知らせ軽減対策を取ってもよい。例えば、ＮＣＳ１８０が新トラフィックカテゴリ、及び、対応する適用帯域幅制限を設けるか、既存のカテゴリの帯域幅制限を変更し、新規変更または生成した分類メタデータを適したホストに送信し、潜在的なセキュリティイベントの影響を限定的にしてもよい。トラフィックメトリクスアグリゲータ１１２は、コレクタ１２５から送信されたメトリクスを、例えば、各ＩＰアドレス専用バケットまたは各クライアント専用バケットなどのバケットにまとめ、バケット表示をＮＣＳに対し利用可能にし、ネットワーク構成の判断をする際に検討する。

図１に示す実施形態において、クライアントオーバーライド要求１３０及び／またはアドミニストレータオーバーライド要求１３１も、ＮＣＳ１８０が行う判断に寄与してもよい。例えば、グローバル方針１２２及びその他のメトリクスに基づき、ＮＣＳ１８０は、インスタンスホスト１４４におけるトラフィックの所定のカテゴリＣ１に対する帯域幅制限を、次回時間間隔を考慮して２Ｇビット／秒に設定すると判断してもよい。しかし、図に示す実施形態において、あるクライアントの計算インスタンスが当該インスタンスホストでインスタンス化されることになった場合、当該クライアントは、当該計算インスタンスに対し５Ｇビット／秒の帯域幅を要求してもよく、または、当該インスタンスホストで実施されるサービスのアドミニストレータが帯域幅を１Ｇビット／秒に制限する要求を出してもよく、ＮＣＳがそのような要求を用いて別の因子をオーバーライドしてもよい。クライアントのトラフィック量に応じてクライアントにネットワークトラフィックの課金を行う実施形態において、クライアントの中には、帯域幅使用に上限を設けるコスト管理を要望してもよく、そのような上限もオーバーライド要求１３０の実施例であるとしてもよい。

いくつかの実施形態によれば、所定のＮＣＳ１８０は、当該ＮＣＳを割り当てられた１以上のインスタンスホスト１４４及び／またはネットワークデバイス１４５のトラフィック分類メタデータを生成してもよい。少なくともいくつかの実施形態において、分類メタデータを、ネットワーク接続ストレージ（ＮＡＳ）デバイスなどの記憶装置についても生成してもよい。メタデータは、ツリーデータ構造で表されるトラフィックカテゴリの１以上のレベルを有するヒエラルキを備え、例えば、当該構造では、ツリーの各ノードが各トラフィックカテゴリを表し、関連する一連のネットワーク構成オプションまたは設定（帯域幅制限またはレイテンシ要件）を有する。いくつかの実施形態において、図５を参考に以下で説明するように、１つの親ノードに複数の子ノードがあるように表すトラフィックカテゴリに対する実トラフィックレートが親ノードの帯域幅制限を超えないよう、トラフィック集計方針を分類ツリーに適用してもよい。インスタンスホスト１４４毎に各分類ツリーを生成するようないくつかの実施形態において、図６を参考に以下で説明するように、ホストレベル分類ツリーは、ＮＣＳ１８０によりラックレベルツリーまたはデータセンタレベル分類ツリーに連結されてもよい。そのような上位レベルツリーを用い、例えば、ネットワークトラフィックの流れに関するより広い視点を取得し、及び／または、インスタンスホスト毎またはネットワークデバイス毎ではなく、より上位の判断を行ってもよい。

分類ツリーの他に、トラフィック分類メタデータは、図に示す実施形態における分類ツリーで定義された多様なカテゴリにパケットなどのネットワークトラフィック単位をマッピングするのに使用するプロシージャも備える。プロシージャステップを、例えば、プロシージャグラフの判断ノードとして表示してもよい。所定のプロシージャグラフは、いくつかの実装において１以上の判断ノード列を備え、連続したノードが、より詳細なトラフィックカテゴリにネットワークトラフィック単位をマッチさせるのに用いる基準を指示することを含む。少なくとも一つの実装において、判断ノードの中にはハッシュテーブルなどのルックアップテーブルを備えるものがあってもよい。そのようなルックアップテーブルノードを用いて、所定パケットまたはトラフィック単位を、単一グラフノードを用いて多種多様なカテゴリの１つにマッピングして、プロシージャグラフのサイズを小さくし、複雑さを低減してもよい。場合により、ルックアップテーブルのノードのエントリを別のプロシージャグラフまたはサブグラフへのポインタにし、細かく分類するロジックまたは基準を使用できるようにさせてもよい。プロシージャグラフ及びルックアップテーブルに組み込まれている判断ノードの実施例を、図６及び図７に示し、以下で詳述する。少なくともいくつかの実施形態において、分類メタデータを分類データベース１９２で保存し、さらに、適切なインスタンスホスト１４４及び／またはネットワークデバイス１４５に配布してもよい。

いくつかの実施形態によれば、ＮＣＳ１８０で生成されたメタデータを、所望の配布先に配布システム１２７を介して送信してもよい。配布システム１２７は、いくつかの実装において、それ自体で複数の中間ノードを備え、ルーティング情報及び／またはアクセス制御リストなど、他のタイプのメタデータをシステム１００の多様なノードに配布するために使用してもよい。データベース１９２を生成メタデータのリポジトリとして使用する実施形態において、配布システム１２７のノードに、例えば、データベース１９２が更新された時に通知し（例えば、通知機構をサブスクライブして）、新規メタデータを適した配布先に転送してもよい。いくつかの実施形態において、ＮＣＳ自体か配布システム１２７かのいずれかにより、ＪＳＯＮ、ＸＭＬ、ＹＡＭＬなどのプロトコル、あるいは、独自技術または言語などを用いて、メタデータの移動可能表示（例えば、分類ツリー及びプロシージャ）を生成してもよい。一つの実装において、移動可能表示をデータベース１９２に保存してもよい。送付先において受信メタデータ表示を解析してもよく、例えば、図３に示し以下で詳述するようにインスタンスホスト１４４の場合では、仮想管理ソフトウウェアスタックのネットワーク管理モジュールにより解析する。

一実施形態において、１以上のＡＰＩサーバ１７０をセットアップし、実施サブシステム１０９の他の出力先１５０からＮＣＳ１８０に向けた要求を処理してもよい。例えば、１以上のサーバを連結ネットワーク図作成装置１５２として構成し、分散環境の選択位置でのネットワーク状態の統合図をクライアントに提供してもよい。一実装において、例えば、多様なインスタンスホストでクライアントに何百何千ものサービスインスタンスを割り当て、当該インスタンスが、図作成装置１５２で実施されるコンソールを介してインスタンスの多様なメトリクス（最新の流入出トラフィックレート、廃棄パケットレート、適用帯域幅制限など）を見えるようにしてもよい。少なくとも一つの実施形態において、配置サービス１５１はネットワーク帯域幅制限及びその他メトリクスをＮＣＳからＡＰＩサーバ１７０を介して入手可能にしてもよく、開始予定の新サービスインスタンスに使用するインスタンスホストについて判断するか、既存のサービスインスタンスを帯域幅の競合が少ないインスタンスホストに動かすのに役立てもよい。

図２は、少なくともいくつかの実施形態において、ネットワーク構成サーバが複数の可用コンテナそれぞれに設置されているプロバイダネットワーク環境の実施例を示す。図のように、図に示す実施形態において、プロバイダネットワーク２０２は、２０３Ａ、２０３Ｂ、及び２０３Ｃなど複数の可用コンテナ２０３を備えてもよい。各可用コンテナはさらに、可用コンテナ２０３Ａはデータセンタ２０５Ａ及び２０５Ｂ、可用コンテナ２０３Ｂはデータセンタ２０５Ｃ、及び可用コンテナ２０３Ｃはデータセンタ２０５Ｄというように、１以上のデータセンタ２０５を備えてもよい。前述したように、各可用コンテナ２０３は、任意の所定可用コンテナでの多様な故障イベントの影響が一般的に当該可用コンテナに限定されるよう（例えば、電源などのそれぞれ独立したインフラ要素において、可用コンテナ同士を地理的に離して）、計画設計されてもよい。従って、故障及び／またはエラーは一般的に可用コンテナの境界を超えて広がらず、種々の可用コンテナは独立した故障プロファイルまたは独立した可用プロファイルを有するものと見なしてもよい。例えば、所定の可用コンテナが自然災害に遭った場合でも、他の可用コンテナは引き続き動作可能であることを期待されてもよい。

可用コンテナ同士の依存関係を防ぎまたは低減させることを設計目標とし、図に示す実施形態において、少なくとも一つのＮＣＳ１８０を各可用コンテナ２０３に設置してもよい。例えば、ＮＣＳ１８０Ａ及び１８０Ｂを、可用コンテナ２０３Ａのデータセンタ２０５Ａ及び２０５Ｂにそれぞれセットアップし、ＮＣＳ１８０Ｃを可用コンテナ２０３Ｂのデータセンタ２０５Ｃに設置し、ＮＣＳ１８０Ｄを可用コンテナ２０３Ｃのデータセンタ２０５Ｄに配置する。データセンタ２０５Ａで実施される１以上のネットワークアクセス可能サービス（仮想化計算サービスまたは記憶サービス）のインスタンスホスト１４４Ａ用、及び、データセンタ２０５Ａに配置されたネットワークデバイス１４５Ａ用の分類メタデータを生成するよう、ＮＣＳ１８０Ａを構成してもよい。同様に、ＮＣＳ１８０Ｂにインスタンスホスト１４４Ｂ及びネットワークデバイス１４５Ｂ用の分類メタデータを生成するタスクを割り当て、ＮＣＳ１８０Ｃにインスタンスホスト１４４Ｃ及びネットワークデバイス１４５Ｃ用の分類メタデータの生成を担当させ、インスタンスホスト１４４Ｄ及びネットワークデバイス１４５Ｄ用の分類メタデータを生成するようＮＣＳ１８０Ｄを構成してもよい。図２に示す実施形態において、単一のＮＣＳを各データセンタ２０５に表示しているが、少なくともいくつかの実施形態において、複数のＮＣＳを所定のデータセンタ２０５にセットアップしてもよい（例えば、性能要件に応じ、及び／または、データセンタでのメタデータ生成を要するノード数に応じる）。一実施形態において、可用コンテナ（２０３Ａなど）がＮ個のデータセンタを備え、帯域幅管理についての性能要件をＮ個より少ない数のＮＣＳで満たしてしまう場合、データセンタの中にはＮＣＳを構成する必要がないものがあるとするのではなく、一以上のデータセンタであっても単一のＮＣＳで足りるとしてもよい。他の実施形態において、一以上の可用コンテナでノード用メタデータを生成するよう所定のＮＣＳ１８０を構成してもよい。

図に示す実施形態において、ネットワーク構成サービスマネジャ２２２がＮＣＳ１８０の数及び配置を判断してもよい。ＮＣＳマネジャ２２２は、いくつかの実装において、それ自体で複数のハードウェア及び／またはソフトウェアコンポーネントを備え、当該ハードウェア及び／またはソフトウェアコンポーネントの中には、多様な可用ゾーン２０３のデータセンタ２０５に分散されるものがあってもよい。図に示す実施形態において、ＮＣＳマネジャが、必要に応じてＮＣＳ１８０の構成変更を起動してもよい。例えば、ＮＣＳが用いる新型ソフトウェアモジュールを展開する場合、ＮＣＳマネジャが指示して展開させてもよい。

図に示す実施形態において、プロバイダネットワークの多数の他のサービスが、ネットワーク構成システムと対話してもよい。例えば、統合コンソールサービス２７８は、クライアント２６５が所望の資源のネットワーク状態を問い合わせ、要求情報をプログラムで受信することが可能な、１以上のプログラマチックインタフェース２４０（ウェブページ、ＡＰＩ、ＧＵＩ、及び／またはコマンドラインツールなど）を実施してもよい。統合コンソールサービス２７８は、図１の連結ネットワーク図作成装置１５２の一つの実施例であってよい。プログラマチックインタフェース２４０により、クライアントが、例えば、特定の時間間隔中、多様なサービスインスタンスまたはインスタンスホストに対する現在の適用帯域幅制限を上下させるなどの構成要求を出せるようにしてもよい。

いくつかの実施形態において、デバイス正常性管理サービス２７６をプロバイダネットワーク２０２で実施し、多様なインスタンスホスト及びネットワークデバイスから応答性情報を収集（例えば、ハートビート機構を用いて）してもよい。図に示す実施形態において、正常性管理サービス２７６を用いて、ＮＣＳ１８０による入力として使用するネットワーク関連メトリクスを収集してもよく、例えば、正常性状態メッセージ上でネットワークメトリクスをピギーバック伝送するなどする。このように、正常性管理サービス２７６のノードは、図１に示すメトリクスコレクタ１２５の実施例であると見なしてもよい。また、いくつかの実施形態において、正常性管理サービスをメタデータ配布システム１２７として用いてもよい。例えば、多様なインスタンスホストに送信されるハートビートメッセージが、ピギーバック伝送された分類メタデータを備えてもよい。プロバイダネットワーク内での対象へのサービス妨害攻撃、及び／または、外部対象にプロバイダネットワーク２０２内から開始されたサービス妨害攻撃を検出するようＤＤＯＳ検出サービス２７４を構成し、例えば、所定の一連のＩＰアドレスに対する異常な高流入出トラフィックパターンの検出などを行ってもよい。潜在的なＤＯＳ攻撃を認識すると、ＤＤＯＳ検出サービス２７４は、潜在的なネットワーク攻撃または侵入について該当するＮＣＳ１８０に入力し、潜在攻撃の影響を軽減するため、ＮＣＳ１８０に帯域幅制限を狭くさせるか、少なくとも一時的に、いくつかのインスタンスホストまたはネットワークデバイスに対し他のネットワーク構成オプションへ変更させてもよい。インスタンス配置サービス２７２は、最新の入手可能なネットワーク関連メトリクス及び構成設定をＮＣＳ１８０から取得し、帯域幅に新規インスタンスを起動する余裕があるインスタンスホストを選択するか、ネットワークトラフィックの変更状態の面から見て既存のインスタンスから移すべきだとするインスタンスホストを選択してもよい。
インスタンスホストにおける分類メタデータの使用

種々の実施形態において、上述したように、ネットワーク構成サーバはトラフィック分類メタデータの表示を多様なネットワークアクセス可能サービスのインスタンスホストに送信してもよい。図３は、少なくともいくつかの実施形態において、仮想化計算サービスのインスタンスホスト１４４においてトラフィック分類メタデータの解釈が可能なネットワークマネジャモジュールの実施例を示す。インスタンスホスト１４４は、多種多様なクライアントアクセス可能仮想マシンのインスタンス化及び管理が可能な仮想化管理ソフトウェアスタック（ＶＭＳＳ）３１０、または計算インスタンス３５０Ａ及び３５０Ｂなどの計算インスタンス３５０を備えてもよい。いくつかの実装において、ＶＭＳＳ３１０は、例えば、ハイパーバイザ３１７、及び、「ドメインゼロ」または「ｄｏｍ０」オペレーティングシステムと呼ばれるオペレーティングシステム３１５の管理インスタンスを備えてもよい。ｄｏｍ０オペレーティングシステムは、クライアントのために計算インスタンス３５０が実行を行うクライアントによりアクセスできなくてもよく、むしろ、計算インスタンス３５０への流入出ネットワークトラフィックの処理を含む、仮想化オペレーティングシステムの多様な管理動作または制御プレーン動作を担当してもよい。

図に示す実施形態において、ｄｏｍ０オペレーティングシステム３１５は、ネットワークマネジャコンポーネント３５７を含む多様な制御モジュールを備え、当該ネットワークマネジャコンポーネントは、さらに、分類メタデータインタプリタモジュール３５９を備えてもよい。ネットワークマネジャコンポーネントは、例えば、上記の分類ツリー及び／または分類プロシージャの表示を含む、ＮＣＳ１８０により生成されたインスタンスホスト１４４用の分類メタデータを受信してもよい。インタプリタ３５９はメタデータを解析し、メタデータに示されたプロシージャを、多様な計算インスタンス３５０との流入出トラフィックパケットに適用してもよい。例えば、多様なトラフィックカテゴリの帯域幅制限を実施するために、１以上のインスタンスパケットキュー（ＩＰＱ）３１９（例えば、ＩＰＱ３１９Ａ及び３１９Ｂ）を構成してもよい。特定のインスタンス３５０での特定のカテゴリの流入出トラフィックレートが、所定の時間間隔において当該カテゴリの帯域幅制限を超える場合、流入出パケットの一部を特定の当該インスタンスのＩＰＱ３１９内のキューに入れてもよい。いくつかの実装において、一以上のパケットキューを所定の計算インスタンスのためにインスタンス化し、例えば、１トラフィックカテゴリにつき１パケットキューを設定してもよい。他の実装において、複数のインスタンス３５０に関連するキュー状パケットには、単一パケットキューで対応するとしてもよい。また、多様な実施形態において、ＩＰＱまたは他の類似構造を用いて、ＮＣＳから受信したメタデータに従い、例えば、レイテンシ要件、その他サービス品質目標（例えば、種々のトラフィックカテゴリに関する相対ネットワーク送信プロパティ）、パケットフラグメンテーション設定、またはパケットサイズに応じた設定など、他のネットワーク構成オプションを実施してもよい。

図のように、図の実施形態において、各計算インスタンス３５０は、計算インスタンス３５０ＡにはＯＳ３７０Ａ、計算インスタンス３５０ＢにはＯＳ３７０Ｂというように、対応するクライアントアクセス可能オペレーティングシステム３７０を備えてもよい。オペレーティングシステム３７０はそれぞれ、自身のネットワークスタック３７２（例えば、インスタンス３５０Ａにはネットワークスタック３７２Ａ、インスタンス３５０Ｂにはネットワークスタック３７２Ｂ）を備え、ネットワークマネジャ３５７と通信し、流入出トラフィック用のインスタンスホスト１４４のハードウェアネットワークインタフェースを使用してもよい。クライアントのために計算インスタンス３５０が実施されるクライアント側から見ると、各インスタンスは不足なく機能的なサーバであり、使用するネットワーク構成技術の実施（ＩＰＱでのパケットキュー状態など）をクライアントが詳細に承知していなくてもよい。図３に示す分類メタデータと同様の分類メタデータの解釈及び使用技術を、種々の実施形態においても同じく、多様なタイプの記憶装置またはデータベースサービスなど、他のタイプのネットワークアクセス可能仮想化サービスのインスタンスホストに用いてもよいことに注意する。また、いくつかの実施形態において、分類メタデータの少なくとも一部を、ＶＭＳＳ３１０のネットワークマネジャ３５７の代わりに、またはネットワークマネジャ３５７に加え、インスタンス３５０のネットワークスタック３７２で解釈及び／または使用してもよいことにも注意する。
メタデータ送信モード

種々の実施形態において、ＮＣＳ１８０が生成したメタデータ表示を、種々のプロトコルまたは転送モードに従いインスタンスホスト１４４またはネットワークデバイス１４５などの対象に提供してもよい。図４ａから図４ｃはそれぞれプロトコルの実施例を示し、少なくともいくつかの実施形態において、当該プロトコルを使用して、トラフィック分類メタデータをインスタンスホストに送信してもよい。種々の実施形態において、１以上のプログラマチックインタフェースを用い、ＮＣＳまたはメタデータの受信側が使用プロトコルに従いインタフェースを呼び出して、メタデータをインスタンスホストに、または分散システムの他のノードに提供してもよい。

図４ａに示す実施形態において、分類メタデータを、ＮＣＳ１８０により開始された予定「プッシュ」動作４０１でインスタンスホスト１４４に（あるいは、ネットワークデバイス１４５または記憶装置に）送信してもよい。例えば、各自の予定を組んで各ＮＣＳを構成し、ＮＣＳが所定のメタデータ対象にメタデータを送信する（例えば、毎分、または５分に一度など）ようにしてもよい。いくつかの実装において、メタデータが所定のＮＣＳから種々の対象に送信された実回数は、メタデータの転送自体が引き起こすネットワーク輻輳が起きないよう調整されてもよい。例えば、メタデータが毎分６つのインスタンスホストに所定のＮＣＳからプッシュされる場合、１０秒間隔での各インスタンスホストへのメタデータ転送の予定を組んでもよい。

図４ｂに示す実施形態において、トリガイベントがメタデータを転送させるようにしてもよい。例えば、イベント検出器４２１は、潜在的なＤＤＯＳの検出などのイベントを検出したことをＮＣＳに知らせ、ＮＣＳはイベントの影響軽減に適したメタデータを生成してもよい。いくつかの実施形態において、特定のタイプのイベントに関し、イベントに即応できるよう、メタデータが生成されるとすぐに最優先で、生成したメタデータのトリガ型プッシュ４０２を開始してもよい。他のタイプのトリガイベントに関し、例えば、アドミニストレータが既に生成済みのメタデータにオーバーライドするよう要求を出した場合には、メタデータのプッシュを即時または最優先で行う必要はない。

図４ｃに示す実施形態において、インスタンスホスト１４４は最新分類メタデータのプル要求４０３をＢＡ１８０に出してもよく、メタデータは応答４０４でインスタンスホストに送信されてもよい。多様な実施形態において、図４ａから４ｃに示す３つの手法のいずれかを組合せて、インスタンスホスト１４４、ネットワークデバイス１４５、または記憶装置のいずれかに使用してもよい。少なくとも一つの実施形態において、メタデータ送信に差分手法を用いてもよく、つまり、現メタデータと最新の提供メタデータとの差分のみの表示を、インスタンスホスト、ネットワークデバイス、または記憶装置に送信してもよい。他の実施形態において、メタデータ全体を転送の各回に送信してもよい。
分類ツリー

図５は、少なくともいくつかの実施形態において、分散システムのデバイスにおけるネットワーク構成のネットワークトラフィックカテゴリの表示に使用されてもよい分類ツリーデータ構造５０１の実施例を示す。ツリー５０１の各ノードは、図５の各ノードに示す個々の帯域幅制限など、ノードに表示された各カテゴリに関連する一連のネットワーク構成オプションまたは設定を有してもよい。各ノードに適用するネットワーク構成オプションの他の実施例として、パケットレイテンシ要件または目標、種々のトラフィックカテゴリ間の相対的な優先順位などの他のサービス品質目標、パケットフラグメンテーション／リアセンブリ設定、または、パケットサイズに応じた構成設定を含んでもよい。種々の実施形態において、多様なプロパティの差分に基づきトラフィックカテゴリを定義してもよい。当該プロパティの差分は、例えば、トラフィックと関連するアプリケーションのカテゴリ、対応するコンポーネントが受送信端部にあたるサービス、エンドポイントでのネットワークアドレス（場合により、アドレス自体がアプリケーションタイプを示してもよい）、転送サイズ、クライアントのためにトラフィックが生成されるクライアント、互いに関連したエンドポイントの位置（例えば、プロバイダネットワークノードからの下りパケットの向先がローカルデータセンタ内か、ローカル可用コンテナか、ローカル領域か、プロバイダネットワークの別領域か、またはプロバイダネットワークの外部か）などである。図に示した分類ツリー５０１において、例えば、ノード５０４は、一つのクラスのアプリケーション（高性能計算）のトラフィックを示し、ノード５２０はデータベーストラフィックを示し、ノード５０６は高性能ブロックストレージトラフィック（すなわち、高入／出力レートをサポートするよう構成されたブロック記憶装置と関連するトラフィック）を示す。ノード５２０で示されるデータベースカテゴリ内には、位置に基づくサブカテゴリのノードが３つ定義されており、ノード５２２はイントラデータセンタトラフィック、ノード５２４はイントラ領域トラフィック、及びノード５２６は外部領域トラフィックがある。

多様なカテゴリ用に定義されるネットワーク構成オプションが帯域幅制限を含む実施形態において、多様なトラフィック集計方針または規則を分類ツリーに適用してもよく、親ノードに対する子ノードの帯域幅制限間の関係性を決定してもよい。例示した実施例において、次に挙げる規則を適用してもよい。（ａ）ツリー内の子ノードはいずれも、当該親の帯域幅制限を超える帯域幅制限を持たない。（ｂ）ある親ノードの子ノードの帯域幅制限の合計は当該親の帯域幅制限を超えるかもしれないが、所定時間間隔における、子ノードが示すカテゴリの実トラフィックレートの合計は、当該親の帯域幅制限を超えない。

当該規則に従い、ルートノード（分類グラフが作成されたインスタンスホストまたはネットワークデバイスに定義されたトラフィックカテゴリの全てをまとめて示す）の帯域幅制限は、Ｋ Ｇビット／秒であり、当該ルートノードのいずれの子ノードの帯域幅制限もＫ Ｇビット／秒を超えない。よって、Ａ＜Ｋ、Ｂ＜Ｋ、Ｃ＜Ｋ、及び、Ｄ＜Ｋである。ノード５２０の場合、子ノード（ノード５２２、５２５及び５２６）の帯域幅制限の合計が親ノードの帯域幅制限になるよう割り当てられ、上記の両規則を満たす。ノード５３０の場合、総称「その他」トラフィックカテゴリを示し帯域幅制限はＤ Ｇビット／秒であり、子ノード５３２（その他のブロックストレージトラフィック）、５３４（インターネットトラフィック）、５３６（イントラサービストラフィック）、及び５３８（他のいずれのリーフノードにも当てはまらない雑多なまたは未分類トラフィック）の帯域幅制限もそれぞれ、Ｄ Ｇビット／秒である。子ノードの名目帯域幅制限の合計が（この場合４Ｄ Ｇビット／秒）親ノードの帯域幅制限（Ｄ Ｇビット／秒）を超えるような設定では、上記の第２の規則に従うものと捉えてもよい。原則的に子ノードの各カテゴリのトラフィックレートは最大Ｄ Ｇビット／秒であるが、実際には、任意の所定秒間（またはその他適した時間単位）における全ての子ノードの実トラフィックフロー合計はＤ Ｇビット／秒を超えない。このため、「その他のブロックストレージトラフィック」カテゴリ（ノード５３２）のトラフィックレートが特定秒間に０．６Ｄ Ｇビット／秒である場合、ノード５３４、５３６及び５３８を組み合わせたトラフィックレートは、０．４Ｄを超えることはない。

いくつかの実施形態において、ＮＣＳ１８０により所定インスタンスホストまたはネットワークデバイスでの流入出トラフィックについて、それぞれツリーが生成されてもよいが、ネットワーク構成オプション及び／またはカテゴリにおいて、流入トラフィックについてのツリーが流出トラフィックについてのツリーとは異なってもよい。いくつかの実施形態において、分類ツリーの一部または全てのノードに関し、持続的な帯域幅について（例えば、Ｔ秒を超える期間での平均帯域幅使用に適用する）、及びバースト帯域幅について（例えば、所定インスタンスホストの持続的な帯域幅制限が１Ｇビット／秒に設定されている場合であっても、当該インスタンスホストでは、４Ｇビット／秒の短期バーストトラフィックレートを最長２秒間許可するとしてもよい）、種々の制限値を定義してもよい。既に述べたが、いくつかの実装において、所定インスタンスホスト、ネットワークデバイス、または記憶装置に関するトラフィック分類ヒエラルキを、複数階層に分けず、フラットにしてもよい。

いくつかの設定において、分散システムの種々のエンティティの分類ツリーをより高次のツリーに統合することは、管理面の面では有用であってもよい。図６は、少なくともいくつかの実施形態において、データセンタにおける複数のインスタンスホストに関するネットワークトラフィックカテゴリ情報の結合に使用されてもよい階層式データ構造６０１の実施例を示す。図のように、データセンタにおける多数のインスタンスホストについてそれぞれ、分類ツリー（Ｃツリー）を生成してもよく、Ｃツリー６０１Ａ、６０１Ｂ、６０１Ｍ、及び６０１Ｎなどがある。図に示した実施形態において、データセンタは、多数の種々の空間に配置された複数のサーバラックを備えてもよい。ＮＣＳは所定ラックに含まれるインスタンスホストのＣツリーを集め、６０３Ａや６０３ＢなどのラックレベルのＣツリーを形成してもよい。次レベルのアグリゲーションでは、データセンタの所定空間またはサブセットにある全ラックについてのラックレベルＣツリー６０３を統合し、例えば、空間レベルＣツリー６０５Ａまたは６０５Ｂの形式にしてもよい。いくつかの実施形態において、空間レベルツリーを統合して、データセンタについてまとめて単一合成ツリー６０７を作成してもよい。いくつかの実施形態において、全体を可用コンテナ、地理的領域、またはプロバイダネットワークでのレベル分けなどした高次ツリーヒエラルキを構成してもよい。

そのような合成ツリーヒエラルキは、ネットワーク構成システム及びプロバイダネットワークのアドミニストレータには多くの点で有用であり、特に、ヒエラルキのカスタム可能な可視化表示をプログラム的に利用可能にする（例えば、統合コンソールサービスで）場合に有用である。データセンタまたはプロバイダネットワークの様々な部分での帯域幅使用の均等性または不均一性がそのようなヒエラルキで全体的に把握でき、それにより構成または配置を変更することになり、ネットワークの利用レベルが改善されまたはバランスがとれるようにしてもよい。そのような高次ヒエラルキを検討する際、利用可能な帯域幅の多様なトラフィックカテゴリの間の配分をより明確にし、プロバイダネットワークの収益改善に繋がる価格変更に役立ててもよい（例えば、より人気のあるカテゴリに関連するトラフィックの価格設定を引き上げる）。高次ツリーヒエラルキが配置サービスにも役立ち、例えば、新サービスインスタンスに適したインスタンスホストを選ぶ際、ラックレベル帯域幅の使用の判断などで役立ててもよい。
分類プロシージャグラフ

上記のように、少なくともいくつかの実施形態において、ネットワーク構成サーバは、プロシージャのステップまたは規則を判断してもよく、当該プロシージャを使用し、パケットなどのネットワークトラフィック単位を、所定のインスタンスホストまたはネットワークデバイスを定義したカテゴリに分類可能である。図７は、少なくともいくつかの実施形態において、分類ツリーと併せて使用しネットワークトラフィック単位のカテゴリを判断してもよい、トラフィックプロシージャグラフ７５０の実施例を示す。そのようなグラフ７５０は複数の判断ノードを備え、当該判断ノードのそれぞれにおいて、ネットワークトラフィックに対するそれぞれの一連の分類基準を示す。少なくともいくつかの実施形態において、少なくとも一つのサブセットの判断ノードを一列に配し、当該列の連続ノードが順により詳細なカテゴリへ対応するようにしてもよい。例えば、ノード７０１、７０２、及び７０３の列において、ノード７０１に示す基準を満たすトラフィックのサブセットは、ノード７０２に示す基準を満たし、ノード７０２に示す基準を満たすトラフィックのサブセットは、ノード７０３に示す基準を満たしてもよい。ネットワークトラフィックの所定単位が列の最終ノードの基準を満たさず終了する場合、当該トラフィック単位を別の列で評価せざるを得ない。例えば、あるパケットがノード７０１及び７０２の基準を満たす（ノード７０１及び７０２の結果を「はい」で示す）が、ノード７０３に示す基準を満たさない（ノード７０３の結果を「いいえ」で示す）場合、当該パケットをノード７０４及び７０５の列で評価せざるを得ない。

一般的に、所定のトラフィック単位が所定のノード列の全ての基準を満たす場合、そのカテゴリであると判断してもよい。例えば、ノード７０１、７０２、及び７０３の基準を満たす場合カテゴリＣ１パケットとし、ノード７０７及び７０８の基準を満たす場合カテゴリＣ６パケットとし、ノード７０６の基準を満たす場合カテゴリＣ５パケットとし、ノード７０９の基準を満たす場合カテゴリＣ７パケットとして分類してもよい。種々の実施形態において、所定ノードに示す基準を、ネットワークトラフィック単位の多様なプロパティで表示してもよい。例えば、ソースまたは送付先ＩＰアドレス、ポートナンバ、または使用するネットワークプロトコルなど、パケットの１以上のヘッダのコンテンツを用いて、パケットのカテゴリを判断してもよく、ボディコンテンツを用いてもよい。プロシージャを用いて所定のトラフィック単位が分類された各カテゴリは、図に示す実施形態において、ＮＣＳが生成した分類ツリーの対応ノードに該当してもよい。

少なくともいくつかの実施形態において、少なくとも原則として、パケット分類に任意の細かい基準を用い、判断ノード列を任意に長くしてもよい。例えば、分類基準を、パケットボディの具体的なコンテンツを基にするか（例えば、特定のバイト領域「０ｘｆｆ」がパケットのオフセットＯ１に発生するかどうか）、パケットまたはヘッダコンテンツの任意の組合せを基にするなどしてもよい。分類プロシージャグラフ７５０のサイズを小さくし複雑さを低減するために、いくつかの実施形態において、複数の結果が得られる判断ノードを用いてもよい。例えば、プロシージャグラフ７５０において、ルックアップテーブル７７０を備えるノード７０５を備える。そのようなルックアップテーブルには列が複数あり、所定のトラフィック単位のプロパティ（パケットの送付先ＩＰアドレスなど）を基にしてそれぞれインデックス化または選択され分類判断されてもよい。ノード７０５の実施例において、分類判断は、パケットがカテゴリＣ２、Ｃ３またはＣ４に属するかどうかについてなされる。判断ノード列を追加してパケットを評価し、分類判断する場合もある。例えば、ルックアップテーブルのエントリが、他の分類グラフまたはサブグラフへのポインタとしての機能を果たしてもよい。

図８は、少なくともいくつかの実施形態において、トラフィック分類プロシージャグラフでのルックアップテーブルノード８０５の使用実施例を示す。図に示す実施形態において、ハッシュ関数８５０をネットワークパケット８１０部に適用し、パケットのカテゴリ分けに使用するノード８０５のルックアップテーブル７７０Ａのエントリを特定してもよい。ルックアップテーブルノード８０５自体には、プロシージャの他の判断ノードで評価された後に達した場合もある。すなわち、ハッシュ関数８５０を適用する前に、少なくともいくつかのレベルのカテゴリ分けがパケット８１０に対し既になされていてもよい。図に示す実施例でのパケットは、送付先ＩＰアドレス「Ｐ．Ｑ．Ｒ．Ｓ」８０１であるアウトバウンドパケットであり、送付先ＩＰアドレスの４つの要素のうち第三要素「Ｒ」をハッシュ関数８５０のへの入力に使用し、パケット８１０に該当するルックアップテーブルのエントリを判断する。多様な実施形態において、パケット８１０の複数プロパティのいずれかをそのようなハッシュ関数への入力に使用してもよく、例えば、送付先ＩＰアドレスまたはソースＩＰアドレスの他の部分の値、他のヘッダフィールド８０２の値、またはパケットのボディ８０３のコンテンツなどを使用してもよい。いくつかの実施形態において、パケットのどのプロパティを使用しルックアップテーブルのエントリを選択するかについての規則、及び、プロパティに適用する関数（ハッシュ関数８５０など）は、分類メタデータと合わせてＮＣＳ１８０が、インスタンスホストまたはネットワークデバイスなどの対象デバイスでのコントロールモジュールに提供してもよい。

場合により、選択する（例えば、送付先ＩＰアドレス要素をハッシュ化した結果として）ルックアップテーブルのエントリは、該当するパケットのトラフィックカテゴリを直接示してもよい。例えば、図８において、ルックアップテーブル７７０Ａの要素から１つを選択するとカテゴリＡになる。ルックアップテーブルの他のエントリはそれ自体が、図８のグラフ８８０Ａ及び８８０Ｂなど、追加プロシージャグラフへのポインタとしての役割を果たし、パケット８１０のカテゴリを判断するためには、当該追加プロシージャグラフの判断ノードはナビゲートされなくてはならない。異なるグラフのノードで基準を評価した結果到達するような追加プロシージャグラフを、本明細書ではサブグラフともいう。図に示した実施例において、判断ノード８５１、８５２（それ自体がルックアップテーブル７７０Ｂを備えたノード）、及び／または８５３に示す基準は、ハッシュ関数８５０が７７０Ａの一つのエントリに繋がっているかどうかを評価する必要があるが、判断ノード８５４、８５５及び／または８５６が示す基準は、ハッシュ関数８５０がルックアップテーブル７７０Ａの異なるエントリを選択したかを評価する必要があってもよい。図８の実施例において、プロシージャグラフ８８０Ｂに達し、要素８５４及び８５５に示す基準を満たせば、例えば、パケット８１０はトラフィックカテゴリＬに属すると見なしてもよい。ルックアップテーブル７７０を分類プロシージャグラフ７５０の多様なノードに含めることで、複雑な細分化ロジックを使って分類する場合でも、トラフィック分類ロジックを大幅に縮小して表示できるようにしてもよい。
トリガイベントに対するネットワーク構成システムの応答性

いくつかの実施形態において、上述したように、ネットワーク攻撃または侵入など、損害を与え得るイベントの検出などのイベントに応答して、帯域幅管理を判断してもよい。例えば、分散システムの特定のサブセットに設定すべきＮＣＳの数、または、ネットワーク構成システムに必要な計算能力及びメタデータ分散能力の種類を決定する際など、ネットワーク構成システムを構成する際に検討すべき要素の一つに、そのようなイベントに対する応答性が必要であるとしてもよい。図９は、少なくともいくつかの実施形態において、ネットワーク構成サービスの１以上のパラメータ値の判断に利用されてもよい応答性メトリクスの実施例を示す。

図９は、時間値が左から右に向かって増加する例示的なタイムラインを示す。時間Ｔ１において、ブロック９０２に示すように、集中ネットワーク構成を実施している分散システムのセキュリティサービスが、ＤＤＯＳ攻撃などの潜在的なネットワーク攻撃を検出する。潜在的な攻撃を、例えば、分散システムの１以上のノードに対する流出入トラフィックレートが突如増加したことを基に特定してもよい。そのような攻撃は、分散システムの内部（プロバイダネットワークの一連の計算インスタンスを用いて実施されているｅ−ビジネスのウェブサイトなど）、または、分散システムの外部（例えば、高レートでプロバイダネットワークの一連の計算インスタンスから外部のウェブサイトに、要求が繰り返し送信されるかもしれない）の、１以上の対象に向けられるかもしれない。正当な理由でトラフィックが増加する場合があってもよい。例えば、ウェブサイトで、販売開始する製品への関心が突如バーストするなどである。しかし、多くの実施形態において、セキュリティサービスは高度な分析技術を採用してそのような誤検出が起きる可能性を低減してもよい。

潜在的な攻撃が実際の攻撃となるかどうかにかかわらず、図に示す実施形態において、例えば、新規の分類メタデータ、及び／または、分散システムに適したノードに対する帯域幅制限などの新規の構成オプションを設け、早急に新規メタデータを適用するなどして対応するようネットワーク構成システムを構成してもよい。ブロック９０４に示すように、一連のノードに関する変更メタデータを、図に示すタイムラインにおける時間Ｔ２で生成してもよい。例えば、ＩＰアドレスＫ．Ｌ．Ｍ．ＮからＩＰアドレスＥ．Ｆ．Ｇ．Ｈに向けられたアウトバウンドＤＤＯＳ攻撃を表すトラフィックが検出された場合、当該ＩＰアドレスに対し帯域幅制限の適用を担うＮＣＳは新規メタデータを生成してもよい。新規メタデータは、例えば、Ｋ．Ｌ．Ｍ．Ｎから発するか、Ｅ．Ｆ．Ｇ．Ｈで受信する全てのトラフィックに、単に新規帯域幅制限（少なくとも一時的に）を課すだけでもよい。或いは、１以上の新規トラフィックカテゴリを、Ｋ．Ｌ．Ｍ．ＮからＥ．Ｆ．Ｇ．Ｈに流れるトラフィックに対し特に定義し、当該特定カテゴリに対する帯域幅制限を設け徹底してもよい。

ブロック９０６に示すように、変更分類メタデータが適切なインスタンスホストまたは他のノードに配布され、図９の例示的なタイムラインにおける時間Ｔ３で実行に移されてもよい（その後、例えば、ネットワーク攻撃が終了するか、攻撃をうかがわせるトラフィックが正当であると判明した場合、分類メタデータを再変更してもよい）。例えば、時間間隔（Ｔ３−Ｔ１）で示される、そのようなトリガイベントに対するネットワーク構成サービスの応答性を、例えば、ネットワーク構成サービスマネジャ２２２が経時的に追跡し、応答性を用いて、採用するＮＣＳの数、またはメタデータ配布システムの多様なプロパティを調整してもよい。
集中ネットワーク構成サービスの実施方法

図１０は、少なくともいくつかの実施形態において、ネットワーク構成サービスのコンポーネントを構成し初期化するよう実行されてもよい動作態様を表すフロー図である。要素１００１に示すように、サービスの多様な初期値パラメータまたはデフォルトパラメータを、例えば、ネットワーク構成を実施しているサービスのグローバル帯域幅管理方針、有用性、及び／または、性能要件の面で判断してもよい。そのようなパラメータは、例えば、各可用コンテナまたは各データセンタに構成するＮＣＳ１８０の数、メタデータ送付予定及びプロトコル（例えば、ＮＣＳがメタデータ転送を開始する際のプッシュプロトコルをデフォルトで使用するかどうか、または、インスタンスホストが分類メタデータを必要に応じ要求する際にプルプロトコルを使用するかどうか）、メタデータ転送に繋がる追加トリガイベントのタイプ、ＮＣＳへの入力ソース、及び／または、ＮＣＳの判断結果を出力する出力先を含む。

少なくともいくつかの実施形態において、一連のプログラマチックインタフェースを実施して（要素１００４）、クライアント及び／またはアドミニストレータがＮＣＳの判断を選択的にオーバーライドできるようにしてもよい。例えば、一実施形態において、クライアントの中には、ＮＣＳが選択した制限に比べ多様な帯域幅制限を広げる（例えば、アプリケーションワークロードレベルの増加見通しに基づき）よう要求を出し、または、ＮＣＳが判断する制限に比べ特定のトラフィックカテゴリの帯域幅制限を抑える（例えば、トラフィック関連請求費用を削減するため）よう要求を出すものもいる。レイテンシ関連設定、及びサービス品質設定など、他の多様なタイプのオプションに対しクライアント及び／またはアドミニストレータから出される構成要求をサポートしてもよい。

適切な数のＮＣＳ１８０を、要素１００１に対応する動作で判断したパラメータに従い、選択した位置でインスタンス化してもよい（要素１００７）。ＮＣＳと、分散システムまたはプロバイダネットワークの他の多様な要素との間にそれぞれ、ネットワーク接続を確立してもよい（要素１０１０）。例えば、ＮＣＳとインスタンスホスト１４４との間、ＮＣＳとＮＣＳによる判断を実施するその他ネットワークデバイス１４５との間、ＮＣＳとＮＣＳの判断に影響を与える入力データソースとの間、及び、ＮＣＳとＮＣＳからのネットワーク情報の継続的な取得に関与する任意の出力先との間などがある。少なくともいくつかの実施形態において、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）などの安全なネットワークプロトコルを、ＮＣＳと、分散システムのその他要素の少なくとも一部との間のネットワーク接続に使用してもよい。

図１１は、少なくともいくつかの実施形態において、ネットワーク構成サービスのトラフィック分類メタデータを生成し配布するよう実施されてもよい動作態様を示すフロー図である。図に示す実施形態において、ＮＣＳは反復手法を採用してもよい。当該手法では、イテレーション毎に一連の入力を用い、一連の対象ノード（例えば、インスタンスホスト）に配布され適用されるネットワーク管理パラメータを判断する。その後、メトリクスは、対象ノード及びその他ソースから収集され、入力値としてフィードバックされ、次のイテレーションに対するパラメータに反映させる、またはパラメータを判断する。要素１１０１に示すように、所定のＮＣＳは、インスタンスホスト、及び／または、スイッチ、ルータ、ゲートウェイなどのネットワークデバイスなど、分散システムの多様なノードから入手された一連のネットワーク関連メトリクスを、所定の時間間隔に受信してもよい。例えば、測定流入出トラフィックレート、パケットロスレート、パケット調整レートなどを含むメトリクスを使用し、ＮＣＳが次のイテレーションのトラフィック分類メタデータを生成してもよい。場合により、例えば、正常性監視サービスノードなど、メトリクス収集システムノードを介してＮＣＳにメトリクスを提供してもよい。さらに、ＮＣＳは、図に示す実施形態において、セキュリティ関連サービス、各ＩＰアドレス専用トラフィックアグリゲータ、各クライアント専用トラフィックアグリゲータなどを含む他の入力ソースから多様な入力も取得してもよい。クライアント及び／またはアドミニストレータは、ＮＣＳが１以上のトラフィックカテゴリに以前適用した帯域幅制限を広げるか狭くする要求などの構成要求をＮＣＳに出してもよい。また、そのような構成要求を、トラフィック分類メタデータの次のイテレーションを判断する時に、入力として使用してもよい。

図に示す実施形態において、ＮＣＳでは、メトリクス及び受信入力値を用いて、例えば、グローバル及び／またはローカルネットワーク管理方針の面から、トラフィック分類メタデータを判断してもよい（要素１１０４）。グローバル方針は、例えば、ネットワークインフラの様々な部分での対象利用制限、同様のサービスレベルを契約した多様なクライアントからのトラフィック処理に関する公平性要件、実施中の多様なネットワークアクセス可能サービスへのネットワークトラフィックに対する相対的な優先度などを示してもよい。ローカル方針は、例えば、他の可用コンテナまたはデータセンタとはネットワークインフラ及び能力が異なるような所定の可用コンテナまたは所定のデータセンタに適用する規則を示してもよい。分散システムの所定対象ノード用に生成された分類メタデータは、対象ノードで使用されるトラフィック分類ヒエラルキ（例えば、図５で示すツリーデータ構造に類似した構造で表示可能なヒエラルキ）、及び、当該ヒエラルキで定義されたカテゴリにネットワークトラフィック単位を分類するのに使用されるプロシージャまたは一連の規則（例えば、図７で示すグラフに類似したグラフで表示可能なプロシージャ）を含んでもよい。ヒエラルキで定義されたトラフィックカテゴリ毎に、１以上の該当する帯域幅制限などのネットワーク構成オプションを判断してもよく、例えば、平均トラフィックに対し定義した帯域幅制限、及び、短期バースト、レイテンシ要件、パケットサイズに応じた要件、または優先度設定に対し定義した異なる帯域幅制限などである。場合により、一連のカテゴリ及び／またはオプションのそれぞれを流入出トラフィックについて定義してもよい。少なくともいくつかの実施形態において、分類ヒエラルキ及び／またはプロシージャを、種々のインスタンスホスト及び／またはネットワークデバイス用にカスタマイズしてもよい。例えば、１組のクライアントアプリケーションに使用している所定のホストＨ１には、別の１組のクライアントアプリケーションが実施されている別のホストＨ２とは異なるトラフィックカテゴリが定義され、異なる帯域幅制限が当該カテゴリに課されてもよい。

図に示す実施形態において、トラフィック分類ヒエラルキ及び分類プロシージャの各移動可能表示またはコード化を、ＮＣＳが対象ノードへの送信用に生成してもよい（要素１１０７）。いくつかの実装においてＪＳＯＮ、ＸＭＬ、ＹＡＭＬなどの業界の標準プロトコルまたは言語を使用してもよく、他の実装では独自コード化スキームを使用してもよい。移動可能表示を、メタデータが適用または使用される対象に送信してもよい（要素１１１０）。少なくとも一つの実装において、分類カテゴリ及びプロシージャ双方に対し、個別コード化または統合コード化してもよく、他の実装では分類カテゴリ及びプロシージャの個別表示が使用されてもしてもよい。いくつかの実施形態において、例えば、前回イテレーションから変更があったメタデータ部分のみを対象に送信する差分メタデータ送信技術を用いてもよい。他の実施形態において、イテレーション毎にメタデータ全体を送信するフル送信手法を用いてもよい。多様な実施形態において、予定プッシュ送信（ＮＣＳが主導して対象にメタデータをプッシュする）、プル送信（対象からの要求に応答してＮＣＳが分類メタデータを送信する）、及び、イベントトリガ型メタデータ送信（所定のイベントタイプを検出するとＮＣＳがメタデータを生成及び／または送信する）を組み合せて用いてもよい。所定のイテレーションでメタデータを適切な対象に送信した後、ＮＣＳは、例えば、要素１１０１に対応する動作から次へと繰り返すなどして、次のイテレーションを開始してもよい。

分散システムの対象ノードにおいて、メタデータ表示を受信し解釈するよう制御モジュール（図３に示すネットワークマネジャ３５７など）を構成してもよい。メタデータを用いて、パケットなどのネットワークトラフィック単位を分類し、該当する帯域幅制限を適用してトラフィック単位送信の予定策定及び／または調整してもよい（要素１１１３）。いくつかの実装において、ノードで既に利用可能な「ｔｃ」などの、オペレーティングシステムのユーティリティまたはツールを用いて、ＮＣＳが生成したロジックを実行してもよい。他の実装において、カスタムツールまたはユーティリティを使用してもよい。メトリクスは、例えば、多様なパフォーマンスツールなどを用いてターゲットノードから収集され、ＮＣＳへの入力として用いられてもよい。

図１２は、少なくともいくつかの実施形態において、トリガイベントに応答してネットワーク管理パラメータを変更するよう実施される動作態様を示すフロー図である。要素１２０１に示すように、潜在的なＤＤＯＳ攻撃などの、トラフィック分類メタデータの変更に繋がるイベントを検出してもよい。いくつかの実施形態において、プロバイダネットワークは１以上のセキュリティサービスを設定し、多様にある潜在的攻撃を示す不審なトラフィックパターンを特定してもよい。そのようなサービスはネットワーク構成システムと通信してもよい。図に示す実施形態において、攻撃から影響を受けるか、攻撃に加担してしまう分散システムの特定ノード（例えば、インスタンスホスト、及び／または、スイッチ、ルータなどのネットワークデバイス）を、例えば、そのようなセキュリティサービスによって、ＮＣＳによって、または、セキュリティサービスとＮＣＳとの組み合わせによってのいずれかで特定してもよい（要素１２０４）。

一連の変更トラフィック分類メタデータをＮＣＳで生成し、攻撃の影響を軽減させてもよい（要素１２０７）。変更部分には、例えば、新しく定義された（例えば、不審なトラフィックの送信及び／または受信にかかわる特定ノードのアドレスを基に）トラフィックカテゴリ、及び／または、新しく適用される帯域幅制限またはその他ネットワーク構成オプションを含んでもよい。いくつかの実施形態において、次に、新メタデータを、分散システムの一連の選択ノードに送付してもよく、当該選択ノードには、攻撃に係わるか攻撃対象となる特定のノード、及び／またはその他ノード（例えば、不審なトラフィックが使うパス上で仲介となるネットワークデバイス）を含んでもよい。

例えば、状態の検出から新規メタデータの適用までの時間など、トリガ状態の対応に要する時間を計測し記録してもよい（要素１２１０）。そのようなトリガイベントに対するネットワーク構成システムの応答性、及び／または、ネットワーク構成システムが取る動作の効果について傾向を継続して分析し、構成変更が必要かを判断してもよい（要素１２１３）。応答性が不十分であるとわかれば、例えば、多数ある構成変更のうちいずれかを実行してもよい。例えば、ＮＣＳの数を増やす、イベントデテクタとＮＣＳとの間の接続性を向上させる、メタデータ分散システムを向上させる、及び／または、ＮＣＳまたは対象ノードにおけるロジックを変更し、より効果的に検出イベントに対応させるなどである。

図１３は、少なくともいくつかの実施形態において、ネットワーク関連状態情報の統合図を分散システムのクライアントに提供するよう実施されてもよい動作態様を示すフロー図である。要素１３０１に示すように、１以上のプログラマチックインタフェース（ウェブページまたはコンソール、ＡＰＩ、ＧＵＩ、或いは、コマンドラインツールなど）を、クライアントに係わる多様な分散システム資源のネットワーク状態の統合カスタマイズ図を提供するために設定してもよい。例えば、クライアントは、割り当てられた仮想化計算サービスの計算インスタンスを多数有し、直近１５分間の帯域幅調整でどの特定インスタンスが影響を受けたかを判別しようとしてもよい。プログラマチックインタフェースにより、クライアントは多様なフィルタが使用可能になり、表示するネットワークプロパティ、及び／または、プロパティが表示される一連の資源を指定してもよい。

メトリクス及び関連資源を指定するネットワーク状態要求を、そのようなインタフェースを介して受信してもよい（要素１３０４）。ネットワーク構成システムは、例えば、メトリクスデータベース１９０から、またはＮＣＳにおけるキャッシュから、要求されたメトリクスを検索してもよい（要素１３０７）。いくつかの実施形態において、要求対応に適した分類メタデータを分類データベース１９２から、またはＮＣＳにおけるメタデータキャッシュから検索してもよい（要素１３１０）。収集した情報を用いて、ネットワーク状態要求に対する応答を作成しプログラマチックインタフェースを介して要求側に提供してもよい（要素１３１３）。

多様な実施形態において、図１０、１１、１２、及び１３のフロー図で示す動作以外の動作で、ネットワーク構成サービス機能を実行してもよく、また、示した一部の動作を実施しなくてもよく、或いは、異なる順でまたは経時的ではなく平行して実行してもよいことに注意する。例えば、いくつかの実施形態において、図１０に示した複数の動作流れを平行して実行し、各対象ノード用の一連の分類メタデータをそれぞれ生成し送信するような、複雑化したＮＣＳを実施する場合もあってよい。

本開示の実施形態を次に挙げる条項の観点で説明する。
１. 複数の計算装置を備えるシステムにおいて、当該計算装置は、
ネットワーク構成サービスの１以上の集中サーバにおいて複数のソースからメトリクスを取得し、当該メトリクスは、プロバイダネットワークのネットワークアクセス可能サービスを実施するよう構成された一連のノードにおいて収集されたトラフィックメトリクスを含み、
当該ネットワーク構成サービスにおいて、当該メトリクスの少なくとも一部及びネットワーク管理方針の少なくとも一部に基づき、当該一連ノードの特定ノードにおいて当該ネットワークアクセス可能サービスのサービスインスタンスと関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用されるメタデータを判断し、
当該一連ノードの特定ノードにおいて制御モジュールに当該メタデータの表示を送信し、
当該特定ノードにおいて、ネットワーク構成サービスで判断された当該メタデータにより示されるプロシージャを実施し、１以上のネットワーク送信の予定を組むよう実装される。
２. １項に記載のシステムにおいて、
当該ネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該システム。
３. １項に記載のシステムにおいて、
当該複数ソースが、１以上の（ａ）サービス妨害検出器、（ｂ）各ネットワークアドレス専用トラフィックメトリクス収集サービス、または（ｃ）各クライアント専用トラフィックメトリクス収集サービスを備える、当該システム。
４. １項に記載のシステムにおいて、
当該メタデータの当該表示が、（ａ）既定予定、（ｂ）トリガイベントの発生、または（ｃ）当該特定ノードからの要求、のうち一つの少なくとも一部に基づき送信される、当該システム。
５. １項に記載のシステムにおいて、
当該ネットワーク構成サーバで判断された当該メタデータが、ネットワークトラフィック単位を当該特定カテゴリに、（ａ）当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、（ｂ）クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または（ｃ）アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される１以上の規則を備える、当該システム。
６. １項に記載のシステムにおいて、
当該複数計算装置はさらに、
（ａ）当該ネットワークアクセス可能サービスのクライアントまたは（ｂ）当該ネットワークアクセス可能サービスのアドミニストレータ、のどちらかにより出された構成要求の指示を受信し、
当該構成要求に従い当該メタデータの１以上の要素を変更する、
よう構成された、当該システム。
７. 複数の計算装置によって実行する方法において、当該実行では、
ネットワーク構成サーバにおいて、プロバイダネットワークのネットワークアクセス可能サービスに関連する複数のソースからメトリクスを取得し、
当該ネットワーク構成サーバにおいて、当該メトリクスの少なくとも一部に基づき、当該ネットワークアクセス可能サービスのサービスインスタンスと関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用されるプロシージャを判断し、
当該ネットワーク構成サーバから、当該サービスインスタンスに関連する当該プロバイダネットワークの特定ノードに、当該プロシージャの表示を送信し、
当該特定ノードにおいて、当該ネットワーク構成サーバで判断された当該プロシージャを実施し、当該ネットワーク構成オプションに従い１以上のネットワーク送信の予定を組む。
８. ７項に記載の方法において、当該ネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該方法。
９. ７項に記載の方法において、当該複数ソースが、１以上の（ａ）当該特定ノード、（ｂ）サービス妨害検出器、（ｃ）各ネットワークアドレス専用トラフィック収集サービス、または（ｄ）各クライアント専用トラフィック収集サービス、を備える、当該方法。
１０. ７項に記載の方法において、当該表示の該送信が、（ａ）既定予定、（ｂ）トリガイベントの発生、または（ｃ）当該特定ノードからの要求、のうち一つの少なくとも一部に基づき開始される、当該方法。
１１. ７項に記載の方法において、当該ネットワーク構成サーバで判断された当該プロシージャが、ネットワークトラフィック単位を当該特定カテゴリに、（ａ）当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、（ｂ）クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または（ｃ）アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される１以上の規則を備える、当該方法。
１２. ７項に記載の方法において、当該プロバイダネットワークが、個々に故障プロファイルを有する複数の可用コンテナを備え、当該複数計算装置による実行ではさらに、
少なくとも一つのネットワーク構成サーバを、当該複数可用コンテナの各可用コンテナにおいて構成する、当該方法。
１３. ７項に記載の方法において、当該複数計算装置による実行ではさらに、
ネットワーク構成オプションの変更に繋がるイベントの検出から、変更されたプロシージャを実施し当該変更を当該ネットワーク構成オプションに適用するまでの時間間隔に関連する性能要件の少なくとも一部に基づき、インスタンス化される多数のネットワーク構成サーバを判断する、当該方法。
１４. ７項に記載の方法において、当該プロシージャの該判断を、（ａ）当該ネットワークアクセス可能サービスのクライアント、または（ｂ）当該ネットワークアクセス可能サービスのアドミニストレータ、のどちらかからの要求に応答して実行する、当該方法。
１５. ７項に記載の方法において、当該プロシージャの当該表示の送信先である当該特定ノードが、（ａ）サービス単位で当該ネットワークアクセス可能サービスを実施するよう構成可能なインスタンスホスト、（ｂ）スイッチ、（ｃ）ルータ、（ｄ）ゲートウェイ、（ｅ）ロードバランサ、または（ｆ）記憶装置、のいずれか一つを備える、当該方法。
１６. ７項に記載の方法において、当該複数計算装置による実行ではさらに、
１以上のプログラマチックインタフェースを介して、当該ネットワークアクセス可能サービスをサポートするよう構成可能な複数のノードのネットワーク状態の連結図を提供する、当該方法。
１７. ７項に記載の方法において、当該複数計算装置による実行ではさらに、
当該ネットワーク構成サーバから、当該ネットワークアクセス可能サービスに関連するインスタンス配置コンポーネントに、当該ネットワークアクセス可能サービスの複数のインスタンスホストのネットワーク状態情報の指示を提供し、また、当該ネットワークアクセス可能サービスのサービスインスタンスが開始される特定のインスタンスホストを選択するのに当該指示を利用するよう当該インスタンス配置コンポーネントが構成される、当該方法。
１８. プログラム命令を保存する非一時的コンピュータアクセス可能記憶媒体において、１以上のプロセッサ上で当該プログラム命令が実行されると、当該プログラム命令は、
ネットワーク関連メトリクスを複数のソースから取得し、
１以上のネットワーク管理方針に従い当該ネットワーク関連メトリクスの少なくとも一部に基づき、計算装置に関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用される一連の規則を判断し、
当該計算装置にネットワーク構成サーバから、当該ネットワーク構成オプションに従い１以上のネットワーク送信の予定を組むのに使用される当該一連規則の表示を送信する。
１９. １８項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該ネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該記憶媒体。
２０. １８項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該複数ソースが、１以上の（ａ）当該計算装置、（ｂ）サービス妨害検出器、（ｃ）各ネットワークアドレス専用トラフィック収集サービス、または（ｄ）各クライアント専用トラフィック収集サービス、を備える、当該記憶媒体。
２１. １８項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該命令が当該１以上のプロセッサ上で実行されると、当該命令が、
当該１以上のネットワーク管理方針に従い当該ネットワーク関連メトリクスの少なくとも一部に基づき、別の計算装置において個々のトラフィックカテゴリに１以上のネットワーク構成オプションを適用するのに使用される別の一連の規則を判断し、
当該別の計算装置に、当該別の一連規則の表示を送信する、当該記憶媒体。
２２. １８項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該一連規則が、ネットワークトラフィック単位を当該特定のカテゴリに、（ａ）当該ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、（ｂ）クライアントのために当該ネットワークトラフィック単位が生成されるクライアント、または（ｃ）アプリケーションのために当該ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される１以上の規則を備える、当該記憶媒体。
２３. １８項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該計算装置が、（ａ）仮想化計算サービス、（ｂ）記憶サービス、または（ｃ）データベースサービス、のいずれか一つを備えるネットワークアクセス可能サービスのサービスインスタンスを実施するよう構成される、当該記憶媒体。
２４. 複数の計算装置を備えるシステムにおいて、当該計算装置は、
ネットワーク構成サーバにおいて、分散システムのネットワーク管理方針の少なくとも一部に基づき、ネットワークトラフィックカテゴリのヒエラルキ、及び、当該ヒエラルキの当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを構築して、当該分散システムの特定の計算装置に適用し、
当該特定計算装置においてネットワークトラフィック単位を当該ヒエラルキのネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの１以上のステップを、当該ネットワーク構成サーバにおいて判断し、
当該ネットワーク構成サーバから当該特定計算装置に、当該ヒエラルキを示す第一データ構造及び当該プロシージャを示す第二データ構造のそれぞれの表示を送信し、
当該特定計算装置において当該第二データ構造に示された当該プロシージャを使って、特定ネットワークトラフィック単位が属する当該ヒエラルキの特定ネットワークトラフィックカテゴリを特定し、
当該特定ネットワークトラフィックカテゴリについて当該第一データ構造に示された特定のネットワーク構成オプションに従い、当該特定ネットワークトラフィック単位を送信する、よう構成される。
２５. ２４項に記載のシステムにおいて、当該特定ネットワーク構成オプションは、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該システム。
２６. ２４項に記載のシステムにおいて、当該第一データ構造が特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードに対し示された帯域幅制限を超えない、当該システム。
２７. ２４項に記載のシステムにおいて、カテゴリの当該ヒエラルキが、当該特定ネットワークカテゴリとは、（ａ）当該ネットワークトラフィックの１以上のネットワークエンドポイントアドレス、（ｂ）クライアントのために当該トラフィックが生成されるクライアントにより指示される１以上のプロパティ、または（ｃ）アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、の少なくとも一つが異なる別のネットワークトラフィックカテゴリを備える、当該システム。
２８. ２４項に記載のシステムにおいて、当該第二データ構造が、続けて詳細分類された当該ヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える、当該システム。
２９. ２４項に記載のシステムにおいて、当該第二データ構造が、当該第二データ構造を用いて分類される当該ネットワークトラフィック単位の１以上のプロパティに基づきインデックス化された複数のエントリを有するルックアップテーブルを表示する少なくとも一つの判断ノードを備える、当該システム。
３０. 複数の計算装置によって実行する方法において、当該実行では、
ネットワーク構成サーバにおいて、１以上の階層を備えるネットワークトラフィックカテゴリのヒエラルキ、及び、当該ヒエラルキの当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを生成し、
当該ネットワーク構成サーバにおいて、ネットワークトラフィック単位を当該ヒエラルキのネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの１以上のステップを判断し、
当該ネットワーク構成サーバから特定の計算装置に、当該ヒエラルキ及び当該プロシージャを示す１以上のデータ構造のそれぞれの表示を提供し、
当該プロシージャを使って、当該ネットワークトラフィックカテゴリについて当該ヒエラルキに示された特定のネットワーク構成オプションに従いネットワークトラフィックカテゴリが判断されるネットワークトラフィック単位を、当該特定計算装置から送信する。
３１. ３０項に記載の方法において、当該特定ネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該方法。
３２. ３０項に記載の方法において、当該１以上のデータ構造が当該ヒエラルキを示す第一データ構造を備え、当該第一データ構造は特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードに対し示された帯域幅制限を超えない、当該方法。
３３. ３０項に記載の方法において、カテゴリの当該ヒエラルキが、当該特定ネットワークトラフィックカテゴリとは、（ａ）当該ネットワークトラフィックの１以上のネットワークエンドポイントアドレス、（ｂ）クライアントのために当該トラフィックが生成されるクライアントにより指示される１以上のプロパティ、（ｃ）アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、または、（ｄ）当該トラフィックが生成されるネットワークアクセス可能サービスの指示、の少なくとも一つが異なる別のネットワークトラフィックカテゴリを備える、当該方法。
３４. ３０項に記載の方法において、当該１以上のデータ構造が、続けて詳細分類された当該ヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える特定のデータ構造を備える、当該システム。
３５. ３４項に記載の方法において、当該特定データ構造が、当該特定データ構造を用いて分類される当該ネットワークトラフィック単位の１以上のプロパティに基づきインデックス化された複数のエントリを有するルックアップテーブルを備える少なくとも一つの判断ノードを備える、当該方法。
３６. ３５項に記載の方法において、当該１以上のプロパティが、（ａ）送信先ＩＰアドレスの少なくとも一部、（ｂ）ソースＩＰアドレスの少なくとも一部、（ｃ）ヘッダの少なくとも一部、（ｄ）ボディコンテンツの少なくとも一部、または（ｅ）ネットワークトラフィック単位に関連するクライアント識別子の少なくとも一部、のいずれか一つを備える、当該方法。
３７. ３６項に記載の方法において、当該複数エントリの特定エントリが、当該特定エントリに関連する基準を満たすネットワークトラフィック単位を分類するのに使用される別の判断ノードの指示を備える、当該方法。
３８. ３０項に記載の方法において、当該１以上のデータ構造の当該表示が、当該特定計算装置に、（ａ）既定予定、（ｂ）トリガイベントの発生、または（ｃ）当該特定計算装置からの要求、のうち一つの少なくとも一部に基づき提供される、当該方法。
３９. ３０項に記載の方法において、該１以上のデータ構造が、１以上の（ａ）サービス妨害検出器、（ｂ）各ネットワークアドレス専用トラフィックメトリクス収集サービス、（ｃ）各クライアント専用トラフィックメトリクス収集サービス、または（ｄ）当該分散システムの複数の計算装置、から受信されたメトリクスに応答して生成される、当該方法。
４０. ３０項に記載の方法において、当該１以上のデータ構造の当該表示が、（ａ）ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）、（ｂ）ＹＡＭＬ、（ｃ）ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、または（ｄ）独自コード化スキーム、のうちの一つに従いフォーマットされる、当該方法。
４１. プログラム命令を保存する非一時的コンピュータアクセス可能記憶媒体において、１以上のプロセッサ上で当該プログラム命令が実行されると、当該プログラム命令は、
ネットワーク構成サーバにおいて、ネットワークトラフィックカテゴリの分類、及び、当該分類の当該ネットワークトラフィックカテゴリに関連する個々のネットワーク構成オプションを生成し、
当該ネットワーク構成サーバにおいて、ネットワークトラフィック単位を当該分類のネットワークトラフィックカテゴリに分類するのに使用可能なプロシージャの１以上のステップを判断し、
当該ネットワーク構成サーバにおいて、当該分類及び当該プロシージャを示す１以上のデータ構造を構成し、
当該ネットワーク構成サーバから特定の計算装置に、当該特定計算装置においてネットワーク送信の予定を組むのに使用される当該１以上のデータ構造の表示を提供する。
４２. ４１項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該分類のネットワークトラフィックカテゴリに関連する特定のネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、当該記憶媒体。
４３. ４１項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該１以上のデータ構造が特定の親ノードが複数の子ノードを有するツリーを備え、また、当該ツリーに関連する帯域幅集計方針に従い、特定の時間間隔中では当該複数子ノードに関連するトラフィックの実転送レートの合計値が、当該特定親ノードについて示された帯域幅制限を超えない、当該記憶媒体。
４４. ４１項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該分類が第一ネットワークトラフィックカテゴリ及び第二ネットワークトラフィックカテゴリを備え、当該第一ネットワークトラフィックカテゴリは、当該第二ネットワークトラフィックカテゴリとは、（ａ）当該ネットワークトラフィックの１以上のネットワークエンドポイントアドレス、（ｂ）クライアントのために当該トラフィックが生成されるクライアントにより指示される１以上のプロパティ、（ｃ）アプリケーションのために当該トラフィックが生成されるアプリケーションカテゴリ、または（ｄ）当該トラフィックが生成されるネットワークアクセス可能サービスの指示、の少なくとも一つが異なる、当該記憶媒体。
４５. ４１項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該１以上のデータ構造が、続けて詳細分類されたヒエラルキのカテゴリを表す列に配列された複数の判断ノードを備える、当該記憶媒体。
４６. ４１項に記載の非一時的コンピュータアクセス可能記憶媒体において、当該以上のデータ構造の当該表示が、（ａ）ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）、（ｂ）ＹＡＭＬ、（ｃ）ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、または（ｄ）独自コード化スキーム、のうちの一つに従いフォーマットされる、当該記憶媒体。
ユースケース

一組に集中させたネットワーク構成サーバを構築し分散システムの多数のノードにおいてネットワークトラフィックを形成する前述の技術は、多くの場合有用であってもよい。例えば、プロバイダネットワークは、複数のデータセンタに分散された何百何千ものインスタンスホスト及び多数のネットワークデバイスを備え、プロバイダネットワークの収入の少なくとも一部をインスタンスホストとのネットワーク流入出トラフィック量に基づき得てもよい。各インスタンスホストまたはネットワークデバイスにおいて、ローカルモジュールを用いてネットワーク管理判断を行うと、そのような大規模環境においては数多くの問題を引き起こすかもしれない。第一に、所定のインスタンスホストにおいて、高度なネットワーク管理判断に要する全ての入力を入手することは出来ないかもしれない。第二に、インスタンスホストにおいて必要とされる判断ロジックが複雑なため、インスタンスホストには相当な量の計算能力が必要となり、クライアントに求められる、残るサービスインスタンス用計算能力が減少するかもしれない。ネットワーク管理ロジックの変更が必要な場合、変更内容が全インスタンスホストに送信、適用される必要があり、資源が集中した間違いが起きやすい実行といえるかもしれない。

上記とは違い、トラフィック形成に使用される判断ロジックを少数のネットワーク構成サーバに分離することで、一連のより多くのソースから入力が収集され、より豊富な情報量での判断を行えるようにしてもよい。ネットワーク構成サーバは、他のサービスと共有される必要がない専用計算資源を使って実施され、計算能力の競合が起きないようにしてもよい。何百何千ものインスタンスホストを更新しなければならない場合に比べ、ネットワーク構成ロジックの更新が各段に容易になるかもしれない。最後に、集中ネットワーク構成サービスは、集中ネットワーク構成サービスでなければ入手困難であろうネットワーク状態統合図を、クライアントに容易に提供できてもよい。
例示的なコンピュータシステム

少なくともいくつかの実施形態において、ネットワーク構成サーバ、ネットワーク構成サービスマネジャ、及び／またはインスタンスホストを実施する技術を含む、本明細書で説明する１以上の技術の一部または全てを実行するサーバは、１以上のコンピュータアクセス可能媒体を含むか当該媒体にアクセスするよう構成された汎用コンピュータシステムを含んでもよい。図１４は、そのような汎用計算装置３０００を示す。図に示す実施形態において、計算装置３０００は、入力／出力（Ｉ／Ｏ）インタフェース３０３０を介してシステムメモリ３０２０と接続された１以上のプロセッサ３０１０を備える。計算装置３０００はさらに、Ｉ／Ｏインタフェース３０３０に接続されたネットワークインタフェース３０４０を備える。

多様な実施形態において、計算装置３０００は、一つのプロセッサ３０１０を備えるユニプロセッサシステムであってもよく、複数のプロセッサ３０１０（例えば、２つ、４つ、８つ、または他の適切な数）を備えるマルチプロセッサシステムであってもよい。プロセッサ３０１０は、命令実行が可能で命令実行に適した任意のプロセッサであってよい。例えば、多様な実施形態において、プロセッサ３０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ ＩＳＡ、あるいは、その他任意の適した命令セットアーキテクチャ（ＩＳＡ）など、多様なＩＳＡのいずれでも実行する汎用プロセッサまたは埋め込み型プロセッサであってもよい。マルチプロセッサシステムにおいて、プロセッサ３０１０はそれぞれ一般的には同じＩＳＡを実施するが、必ずしも同じでなくてもよい。いくつかの実装において、一般的なプロセッサの代わりにまたは追加して、グラフィック処理ユニット（ＧＰＵ）を使用してもよい。

システムメモリ３０２０は、プロセッサ３０１０により入手可能に命令及びデータを保存するよう構成されてもよい。多様な実施形態において、システムメモリ３０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期式ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、またはその他メモリタイプなど、任意の適したメモリ技術を用いて実施されてもよい。図に示す実施形態において、上記のような方法、技術及びデータなど、１以上の所望の機能を実施するプログラム命令及びデータを示し、コード３０２５及びデータ３０２６としてシステムメモリ３０２０に保存する。

一実施形態において、Ｉ／Ｏインタフェース３０３０は、プロセッサ３０１０、システムメモリ３０２０、及び、装置の任意の周辺デバイスの間のＩ／Ｏトラフィックを調整するよう構成されてもよく、当該周辺デバイスには、ネットワークインタフェース３０４０、または、データ対象パーティションの物理レプリカの保存に使用される多様な持続的及び／または揮発性記憶装置などのその他周辺インタフェースを含む。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０は、任意の必要なプロトコル、タイミング、またはその他データ変換を実行し、あるコンポーネント（例えば、システムメモリ３０２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ３０１０）での使用に適したフォーマットに変換してもよい。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０は、例えば、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス標準またはＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）標準の変種など、多様なタイプの周辺バスを介して取付けられたデバイスへのサポートを含んでもよい。いくつかの実施形態において、Ｉ／Ｏインタフェース３０３０の機能を、例えば、ノースブリッジ及びサウスブリッジなど、二以上の個別コンポーネントに分割してもよい。また、いくつかの実施形態において、システムメモリ３０２０に対するインタフェースなど、Ｉ／Ｏインタフェース３０３０の一部または全ての機能をプロセッサ３０１０に直接組み込んでもよい。

ネットワークインタフェース３０４０は、計算装置３０００とその他装置３０６０との間でデータ交換が出来るよう構成されてもよく、当該その他装置は、例えば、図１から図１３に示すその他コンピュータシステムまたは装置などで、ネットワーク３０５０に接続している。多様な実施形態において、ネットワークインタフェース３０４０は、例えば、Ｅｔｈｅｒｎｅｔネットワークのタイプなど、一般的な有線または無線の任意のデータネットワークを介した通信をサポートしてもよい。さらに、ネットワークインタフェース３０４０は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどのテレコミュニケーション／テレフォニネットワークを介し、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ＳＡＮなどのストレージエリアネットワークを介し、或いはその他任意のタイプのネットワーク及び／またはプロトコルを介し、通信をサポートしてもよい。

いくつかの実施形態において、システムメモリ３０２０は、コンピュータアクセス可能媒体の一つの実施形態であり、図１から図１３に関し上述したように、対応する方法及び装置の実施形態を実施するプログラム命令及びデータを保存するよう構成されてもよい。しかし、他の実施形態において、種々のタイプのコンピュータアクセス可能媒体上で、プログラム命令及び／またはデータを受信し、送信し、保存してもよい。一般的には、コンピュータアクセス可能媒体は、例えば、Ｉ／Ｏインタフェース３０３０を介して計算装置３０００に接続されたディスクまたはＤＶＤ／ＣＤなど、磁気または光メディアといった非一時的な記憶媒体またはメモリ媒体を含んでもよい。また、非一時的コンピュータアクセス可能記憶媒体は、システムメモリ３０２０または他のタイプのメモリとして計算装置３０００のいくつかの実施形態に含まれる、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなど、任意の揮発性または不揮発性媒体を含んでもよい。さらに、コンピュータアクセス可能媒体は、ネットワークインタフェース３０４０を介して実施されるような、ネットワーク及び／または無線リンクなど通信媒体を介し搬送される電気、電磁またはデジタル信号などの伝送媒体または信号を含んでもよい。多様な実施形態において、図１４に示す複数の計算装置の一部または全てを使用して、説明した機能を実施してもよい。例えば、多種多様な装置及びサーバ上で実行するソフトウェアコンポーネントは、連携により機能を提供してもよい。いくつかの実施形態において、説明した機能の一部を、汎用コンピュータシステムを使用した実施に加えまたは代わりに、記憶装置、ネットワークデバイス、または専用コンピュータシステムを使って実施してもよい。本明細書で使用する用語「計算装置」は、少なくともあらゆるこれらのタイプの装置をいい、これらのタイプの装置に限定するものではない。
結論

多様な実施形態には、コンピュータアクセス可能媒体上で前述の内容に従い実施された命令及び／またはデータの受信、送信または保存を含んでもよい。一般的に、コンピュータアクセス可能媒体は記憶媒体またはメモリメディアを含んでもよく、当該媒体には、ネットワーク及び／または無線リンクなど通信媒体を介し搬送される電気、電磁またはデジタル信号などの伝送媒体或いは信号の他に、例えば、ディスクまたはＤＶＤ／ＣＤ―ＲＯＭなどの磁気または光メディア、及び、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性または不揮発性媒体がある。

本図及び本明細書にて説明する多様な方法は、例示的な方法の実施形態を表す。当該方法をソフトウェア、ハードウェア、またはそれらの組合せで実施してもよい。方法の順番を変更し、多様な要素を追加し、再配列し、組み合わせ、削除し、変更するなどしてもよい。

本開示の恩恵を受ける当業者には明らかなように、多様な変形及び変更を行ってもよい。本開示は、そのようなあらゆる変形及び変更を包含し、従って、上記の説明は例示であって限定な意味とするものではないと見なすものである。

Claims (15)

1. 複数の計算装置によって実行する方法において、前記実行では、
   ネットワーク構成サーバにおいて、プロバイダネットワークのネットワークアクセス可能サービスに関連する複数のソースからメトリクスを取得し、
   前記ネットワーク構成サーバにおいて、前記メトリクスの少なくとも一部に基づき、前記ネットワークアクセス可能サービスのサービスインスタンスと関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用されるプロシージャを判断し、
   前記ネットワーク構成サーバから、前記サービスインスタンスに関連する前記プロバイダネットワークの特定ノードに、前記プロシージャの表示を送信し、
   前記特定ノードにおいて、前記ネットワーク構成サーバで判断された前記プロシージャを実施し、前記ネットワーク構成オプションに従い１以上のネットワーク送信の予定を組むことを含む、方法。
2. 前記ネットワーク構成オプションが、１以上の（ａ）帯域幅制限、（ｂ）レイテンシ制約、（ｃ）サービス品質目標、（ｄ）パケットフラグメンテーション構成設定、または（ｅ）少なくとも一部のパケットサイズに応じた構成設定、を備える、請求項１に記載の方法。
3. 前記複数ソースが、１以上の（ａ）前記特定ノード、（ｂ）サービス妨害検出器、（ｃ）各ネットワークアドレス専用トラフィック収集サービス、または（ｄ）各クライアント専用トラフィック収集サービス、を備える、請求項１に記載の方法。
4. 前記表示の該送信が、（ａ）既定予定、（ｂ）トリガイベントの発生、または（ｃ）前記特定ノードからの要求、のうち一つの少なくとも一部に基づき開始される、請求項１に記載の方法。
5. 前記ネットワーク構成サーバで判断された前記プロシージャが、ネットワークトラフィック単位を前記特定カテゴリに、（ａ）前記ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、（ｂ）クライアントのために前記ネットワークトラフィック単位が生成されるクライアント、または（ｃ）アプリケーションのために前記ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される１以上の規則を備える、請求項１に記載の方法。
6. 前記プロバイダネットワークが、個々に故障プロファイルを有する複数の可用コンテナを備え、前記複数計算装置による実行ではさらに、
   少なくとも一つのネットワーク構成サーバを、前記複数可用コンテナの各可用コンテナにおいて構成する、請求項１に記載の方法。
7. において、前記複数計算装置による実行ではさらに、
   ネットワーク構成オプションの変更に繋がるイベントの検出から、変更されたプロシージャを実施し前記変更を前記ネットワーク構成オプションに適用するまでの時間間隔に関連する性能要件の少なくとも一部に基づき、インスタンス化される多数のネットワーク構成サーバを判断する、請求項１に記載の方法。
8. 前記プロシージャの該判断を、（ａ）前記ネットワークアクセス可能サービスのクライアント、または（ｂ）前記ネットワークアクセス可能サービスのアドミニストレータ、のどちらかからの要求に応答して実施する、請求項１に記載の方法。
9. 前記プロシージャの前記表示の送信先である前記特定ノードが、（ａ）サービス単位で前記ネットワークアクセス可能サービスを実施するよう構成可能なインスタンスホスト、（ｂ）スイッチ、（ｃ）ルータ、（ｄ）ゲートウェイ、（ｅ）ロードバランサ、または（ｆ）記憶装置、のいずれか一つを備える、請求項１に記載の方法。
10. 前記複数計算装置による実行ではさらに、
    １以上のプログラマチックインタフェースを介して、前記ネットワークアクセス可能サービスをサポートするよう構成可能な複数のノードのネットワーク状態の連結図を提供する、請求項１に記載の方法。
11. 前記複数計算装置による実行ではさらに、
    前記ネットワーク構成サーバから、前記ネットワークアクセス可能サービスに関連するインスタンス配置コンポーネントに、前記ネットワークアクセス可能サービスの複数のインスタンスホストのネットワーク状態情報の指示を提供し、また、前記ネットワークアクセス可能サービスのサービスインスタンスが開始される特定のインスタンスホストを選択するのに前記指示を利用するよう前記インスタンス配置コンポーネントが構成される、請求項１に記載の方法。
12. プログラム命令を備える１以上のメモリに接続された１以上のプロセッサを備えるシステムにおいて、前記プログラム命令が前記１以上のプロセッサにより実行されると、前記プログラム命令が前記システムに、
    複数ソースからネットワーク関連メトリクスを取得させ、
    １以上のネットワーク管理方針に従い前記ネットワーク関連メトリクスの少なくとも一部に基づき、計算装置に関連する特定のトラフィックカテゴリにネットワーク構成オプションを適用するのに使用される一連の規則を判断させ、
    前記計算装置にネットワーク構成サーバから、前記ネットワーク構成オプションに従い１以上のネットワーク送信の予定を組むのに使用される前記一連規則の表示を送信させる。
13. 前記複数ソースが、１以上の（ａ）前記計算装置、（ｂ）サービス妨害検出器、（ｃ）各ネットワークアドレス専用トラフィック収集サービス、または（ｄ）各クライアント専用トラフィック収集サービスを備える、請求項１２に記載のシステム。
14. 前記命令が前記１以上のプロセッサ上で実行されると、前記命令が前記システムに、
    前記１以上のネットワーク管理方針に従い前記ネットワーク関連メトリクスの少なくとも一部に基づき、別の計算装置において個々のトラフィックカテゴリに１以上のネットワーク構成オプションを適用するのに使用される別の一連の規則を判断させ、
    前記別の計算装置に、前記別の一連の規則の表示を送信させる、請求項１２に記載のシステム。
15. 前記一連の規則が、ネットワークトラフィック単位を前記特定カテゴリに、（ａ）前記ネットワークトラフィック単位に関連するネットワークエンドポイントアドレス、（ｂ）クライアントのために前記ネットワークトラフィック単位が生成されるクライアント、または（ｃ）アプリケーションのために前記ネットワークトラフィック単位が生成されるアプリケーション、のうち一つの少なくとも一部に基づき分類するのに使用される１以上の規則を備える、請求項１２に記載のシステム。

Images