JP2004507128A - ミラーデータセンタ間のグローバル負荷分散 - Google Patents

Abstract

本発明はグローバル負荷分散を行うインテリジェントトラヒック再方向付けシステムである。それは、エンドユーザが複製されたリソースにアクセスする必要のあるどんな状況でも使用できる。この方法では、レプリカへのルートがネットワークの見地から良好で、レプリカが過負荷にならないように、エンドユーザが適当なレプリカに向けられる。この手法では好ましくは、ドメインネームサービス（ＤＮＳ）を使用して適当なレプリカにＩＰアドレスを与える。最も普通の用途はトラヒックをミラーウェブサイトに向かわせることである。

Description

【０００１】
（技術分野）
本発明は一般に高性能で、フォールトトレラントなコンテントデリバリに関するものであり、特にグローバルコンピュータネットワークの中のミラーデータセンタの負荷を分散するためのシステムと方法に関するものである。
【０００２】
（関連技術の説明）
ミラーデータセンタにウェブ型コンテントを記憶し、ネットワークトラヒック条件に基づいてデータセンタに対するこのようなコンテント要求を負荷分散することは知られている。既存のグローバル負荷分散プロダクトはインタネットトラヒック条件のマップを作成するための数個の異なるアプローチを使用する。一つのアプローチはボーダゲートウェイプロトコル（ＢＧＰ）データを使用する。しかし、ＢＧＰデータは非常に粗になり得るので、ＢＧＰに基づくルーチングは次善のものとなり得る。他のアプローチは、最適マッピングを実時間で演算した後、マッピング情報をキャッシュしようとする。この手法では、初期の「ヒット」の間の貧弱なターンアラウンド時間となり、相次ぐ要求に対する陳腐なマッピングとなる可能性がある。更に、エンドポイントに対する測定の品質は雑音を伴う傾向がある。これらのマッピング手法の欠陥のために、結果として行われる負荷分散は決して有効でない。
【０００３】
現在の負荷分散装置は通常、インタネット全体のようなコンピュータネットワーク全体に対する最適マップを演算することができない。現在、インタネットは何億ものホストとルータをそなえている。一組のミラーデータセンタへのインタネット全体の接続時間の推定、たとえば、サーバと各ホストまたはルータとの間のネットワークを評価することによる推定は信じられないほど時間がかかり、余りに多くの帯域幅を消費する。もちろん、実時間のルーチング判断が必要なときには、このような手法は実際的でない。
【０００４】
また、このような測定は雑音を含み、不正確になる傾向があり、またファイアウォールが接触するシステム管理者を悩ますことがあり得る。ファイアウォールの後ろのローカルネームサーバには達せられず、（たとえば、ダイヤル呼出し接続等による）「ラストマイル」上の遅い接続は接続ピクチャ（ｃｏｎｎｅｃｔｉｖｉｔｙ ｐｉｃｔｕｒｅ）を混乱させがちである。したがって、地球のまわりに位置するミラーデータセンタ間の負荷分散とともにインテリジェントトラヒックリダイレクション（ｒｅｄｉｒｅｃｔｉｏｎ）を行うために使用することができる最適ネットワーク接続マップ（ｃｏｎｎｅｃｔｉｖｉｔｙ ｍａｐ）を生成する有効な手法は従来技術には残っていない。
【０００５】
（発明の概要）
本発明はグローバル負荷分散を行うインテリジェントトラヒックリダイレクションシステムである。それは、エンドユーザが複製されたリソースにアクセスする必要のあるどんな状況でも使用できる。この方法では、レプリカへのルートがネットワークの見地から良好で、レプリカが過負荷にならないように、エンドユーザが適当なレプリカに向けられる。この手法では好ましくは、ドメインネームサービス（ＤＮＳ）を使用して適当なレプリカにＩＰアドレスを与える。最も普通の用途はトラヒックをミラーウェブサイトに向かわせることである。他の用途は、キャッシュを記憶サーバに向かわせること、ストリーミングサーバを信号取得ポイントに向かわせること、ロギングプロセスをログアーカイブサーバに向かわせること、メールプロセスをメールサーバに向かわせること等である。
【０００６】
好適実施例では、この方法はインタネット全体のユーザベースに対して連続的に生成されるネットワークマップに依存する。従来技術固有の問題は、一組のミラーデータセンタに対する相対結合性（ｒｅｌａｔｉｖｅ ｃｏｎｎｅｃｔｉｖｉｔｙ）を推定する問題のディメンジョナリティを非常に削減することにより克服される。「データセンタ」は通常、スペースを賃貸しし、インタネットへの結合性を販売する電気通信設備に配置されている。与えられたデータセンタで多数のコンテントプロバイダがそれらのウェブサイトのホストとなることがある。ミラーデータセンタに接続され得る各ローカルネームサーバ（または他のホスト）を精査する代わりに、ネットワークマップが「コア」（または「共通」）ポイントと呼ばれる、ずっと少ない一組の代理ポイントに対する結合性を表す。このとき、コアポイントは、データセンタの視点からはポイントを共用する一組のローカルネームサーバ（または他のホスト）の代表となる。ミラーデータセンタの各組は一組のコアポイントを表す対応するマップをそなえる。
【０００７】
本発明の好適実施例によれば、コアポイントは次のようにして発見される。一組のミラーデータセンタの各々から、データセンタに記憶されているレプリカに対する要求を解決するためにクライアントが使用し得るローカルネームサーバに、インクリメンタルなトレースルートが実行される。次に、共通ルーチングポイントでのトレースルートの交差が識別される。したがって、たとえば、共通ルーチングポイントは、データセンタの視点から見たとき、トレースルートに対する第一の共通ポイント（またはローカルネームサーバの視点から見たとき、トレースルートに対する最後の共通ポイント）であってもよい。このとき、共通ルーチングポイントはローカルネームサーバに対するコアポイントとして識別される。同様に、他のローカルネームサーバ（または他のホスト）に対してコアポイントが識別される。したがって、後で説明されるように、与えられた一組のミラーデータセンタはそれらに対応して、その一組のデータセンタへの相対結合性を推定する際に有用である一組のコアポイントをそなえてもよい。
【０００８】
コアポイントが識別されると、システマティックな方法を使用して、ミラーデータセンタの各々から、与えられたコアポイントまでの予測された実際のダウンロードタイムを推定する。本発明によれば、ＩＣＭＰ（またはいわゆる「ピング」（ｐｉｎｇ）パケット）を使用して、データセンタとコアポイントとの間のラウンドトリップタイム（ＲＴＴ）および待ち時間（ｌａｔｅｎｃｙ）を測定する。したがって、たとえば、コアポイントを周期的に（たとえば、３０秒毎に）ピングし、対応する待ち時間およびパケット損失データを収集してもよい。このようなデータを使用して、好ましくはすべての前の測定と新しい測定の指数的に時間重み付けされた平均を使用して平均待ち時間が計算される。類似の機能を使用して、平均パケット損失を計算する。その結果を使用して、データセンタの一つとコアポイントとの間の各パスに対するスコアが生成される。スコアは平均待ち時間を修正することにより生成されてもよい。たとえば、平均待ち時間を特有の仕方で重み付けすることによりダウンロード予測を行う与えられたペナルティ係数で平均待ち時間を修正することにより、スコアが生成されてもよい。このとき、（その時間スライスに対する最良の動作を行うネットワークの結合性を表す）最良のスコアをどのデータセンタがそなえても、そのデータセンタはコアポイントと結合される。
【０００９】
コアポイント／データセンタのデータ組をＩＰブロック／データセンタのデータ組に対して一般化することにより完全なネットワークマップが作成される。この「単一化」により、完全になり、ネットワークマップのサイズが小さくなり、新しいローカルネームサーバに対してトラヒックのリダイレクションが実行されることが可能となる。
【００１０】
次に、生成されたネットワークマップを使用して、トラヒック再方向付けと負荷分散が行われる。特に、ユーザのローカルネームサーバが（一組のミラーデータセンタの中に配置された）コンテントプロバイダのウェブサイトに対して要求を行うとき、この方法は好ましくはネットワークマップを使用して、最適データセンタでのウェブサーバＩＰアドレスのリストをローカルネームサーバに返送する。ユーザのローカルネームサーバがピングデータを利用できない（それのＩＰブロックが単一化によって拡張されていない）場合には、ＢＧＰまたは地理ルーチング（ｇｅｏ−ｒｏｕｔｉｎｇ）を使用してデフォルトルーチング判断を行うことができる。コンテントプロバイダによって指定された負荷分散の好みも、データセンタ間で、または特定のデータセンタ内で容易に実行することもできる。
【００１１】
以上、本発明の、より適切な目的および特徴のいくつかの概要を説明した。これらの目的は、本発明のより顕著な特徴と応用のいくつかを表したものに過ぎないと考えるべきである。
【００１２】
本発明とその利点の、より完全な理解のために、付図とともに次の詳細な説明を参照すべきである。
【００１３】
（好適実施例の詳細な説明）
簡単な背景により、従来技術ではウェブコンテントプロバイダがそのウェブサイトを分散させること、または「ミラー」構成にすることにより、サイトが常に利用でき、グローバルカストマベースに許容できる性能を与えることが知られている。一旦ウェブサイトが分散されると、通常、グローバルトラヒック管理（ＧＴＭ：ｇｌｏｂａｌ ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ）の解を使用してユーザを種々のミラーサイトに向かわせる。ＧＴＭの解は種々の方法を使用して、どれがユーザを向かわせる「最良の」ミラーサイトであるかを判定する。しかし、インタネット条件は絶えず変化しているので、特定のユーザに対する「最良の」サイトもこれらの条件とともに変化する。本発明は、ミラーデリバリサイトのアベイラビリティと性能を最大にするＧＴＭ解である。
【００１４】
次に説明する好適実施例では、グローバルトラヒック管理の解は、サービスプロバイダ、たとえばコンテントデリバリネットワーク（ＣＤＮ）サービスプロバイダ（ＣＤＮＳＰ）によって提供される管理されたサービスである。周知のように、ＣＤＮは第三者のコンテントプロバイダに代わってディジタルコンテント（たとえば、ウェブコンテント、ストリーミングメディア、およびアプリケーション）の効率的なデリバリのために配置される地理的に分散されたコンテントデリバリノードのネットワークである。与えられたコンテントに対する要求するエンドユーザからの要求は「最良」のレプリカに向けられる。「最良」は通常、コンテントプロバイダのオリジンサーバからフェッチするために要する時間に比べて素早くクライアントにアイテムがサービスされるということを意味する。通常、ＣＤＮは、コンテントデリバリインフラストラクチャ、要求ルーチングメカニズム、およびディストリビューションインフラストラクチャの組み合わせとして実現される。コンテントデリバリインフラストラクチャは通常、要求しているエンドユーザにコンテントのコピーを配信するための戦略的ロケーション（たとえば、インタネット存在ポイント、ネットワークアクセスポイント等）に配置された一組の「サロゲート」（代理）オリジンサーバを含む。要求ルーチングメカニズムは要求しているクライアントにコンテントデリバリインフラストラクチャ内のサーバを割り当てるが、その際、ウェブコンテントの配信の場合は与えられたクライアントの応答時間を最小にするように、そしてストリーミングメディアの配信の場合は最高の品質が与えられるように割り当てを行う。ディストリビューションインフラストラクチャは、コンテントをオリジンサーバからサロゲートに移動するオンデマンドまたはプッシュ型メカニズムで構成される。有効なＣＤＮは、与えられた要求しているクライアントに対して最適であるサロゲートからの、しばしばアクセスされるコンテントにサービスする。代表的なＣＤＮでは、単一のサービスプロバイダが要求ルータ、サロゲート、およびコンテントディストリビュータを運用する。更に、そのサービスプロバイダはコンテントパブリッシャとビジネス関係を確立し、それらのオリジンサーバに代わって分散したデリバリシステムを提供するように作用する。ウェブコンテントおよびメディアストリーミングを提供する周知の商用ＣＤＮはマサチューセッツ州ケンブリッジ（Ｃａｍｂｒｉｄｇｅ，Ｍａｓｓａｃｈｕｓｅｔｔｓ）のアカマイテクノロジーズ社（Ａｋａｍａｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．）により提供される。
【００１５】
したがって、一実施例では、本発明はコンテントプロバイダのミラーウェブサイトのグローバル負荷分散のための管理されたサービスを実行する。図１は基本的なインプリメンテーション環境を示す。この例では、グローバルトラヒック管理サービス１００は、（同じドメイン、たとえば、ｗｗｗ．ａｋａｍａｉ．ｃｏｍで表される）一対のミラーウェブサイト１０２および１０４を運用しているコンテントプロバイダにグローバルトラヒック管理を提供する。ＧＴＭサービス１００はウェブサイトにアクセスしているエンドユーザ１０６および１０８を最良ま動作を行うミラーサイトに向かわせることにより、エンドユーザ１０６および１０８に改善された反応の速さを与える。図２は、ミラーウェブサイトを運用しているコンテントプロバイダに代わって、管理されたサービスとしてＣＤＮＳＰまたは他のエンティテイ（「管理されたサービスプロバイダ」）によって上記のように実行されるＧＴＭサービスの高レベルの技術的アーキテクチャを示す。もちろん、当業者には理解されるように、本発明の機能は全体または一部がプロダクトに基づく解として実現してもよい。
【００１６】
説明のためだけであるが、図２に示すように、好適なＧＴＭサービス２００は多数の構成要素、すなわち、一組のネットワークエージェント２０２、一組のウェブサーバエージェント２０４、一組のマップ生成サーバ２０６、および一組のネームサーバ２０８を含む。このような構成要素は各々通常はサーバ、たとえば、リナックスオペレーティングシステムを動作させ、後で説明する機能を実行するためのアプリケーションソフトウェア、またはこのようなマシン上で実行される一つ以上のプロセスをそなえるペンティアム（登録商標）に基づくボックスである。後で説明するように、データはネットワークエージェントおよびウェブサーバエージェントによって収集され、マップ生成サーバに渡される。マップ生成サーバはデータを分析し、少なくとも一つのマップサーバがネームサーバのＩＰアドレス／ブロックを領域に割り当てるマップを作成する。次に、少なくとも一つのマップがネームサーバにアップロードされる。サービスによって管理されているミラーサイトドメインへのアクセスをエンドユーザが要求するとき、ユーザが接続されるべき「最良の」データセンタを表すＩＰデリゲーションをネームサーバの一つが戻す。
【００１７】
図に示された構成要素の特定の配置は代表的なものであり、どの特定のエンティテイも特定のマシンを所有したり、制御することも必要条件ではない。この実施例では、ミラーウェブサイトのホストの役目を果たす各データセンタの中のそれらのネットワークセグメントの中または近くにあるネットワークエージェントをコンテントプロパイダがそなえている。したがって、たとえば、一対のネットワークエージェント２０２ａおよび２０２ｂがデータセンタ２０３ａ内のコンテントプロパイダ専用のものであり、一対のネットワークエージェント２０２ｃおよび２０２ｄがデータセンタ２０３ｂ内のコンテントプロパイダ専用のものであるが、これは必要とされない。これらのネットワークエージェントは好ましくは、コンテントプロパイダのウェブサーバと同じネットワークを共用する。したがって、たとえば、データセンタ２０３ａ内のネットワークエージェント２０２ａおよび２０２ｂはコンテントプロパイダのウェブサーバ２０７ａ−ｃとネットワーク接続を共用する。管理されたサービスプロバイダがＣＤＮを運用する場合、ＣＤＮがその中に配置されるデータセンタ内に一組のネットワークエージェントを配置してもよい。もちろん、多数のコンテントプロパイダが、与えられたデータセンタでそれらのウェブサイトのホストとしての役目を果たし、ネットワークエージェントを共用してもよい。したがって、与えられたネットワークエージェントは与えられたロケーションで第一のコンテントプロパイダに対して一度データを収集した後、同じデータセンタの中に一緒に配置された他のすべてのコンテントプロパイダとデータを共用してもよい。データセンタは通常、スペースを賃貸しし、インタネットへの結合性を売る電気通信設備（たとえば、Ｅｘｏｄｕｓ、Ｆｒｏｎｔｉｅｒ　Ｇｌｏｂａｌ、ＵＵＵＮｅｔ等）に配置される。
【００１８】
ネットワークエージェントは二つの主要な機能、すなわち、「コアポイント」ディスカバリ（ＣＰＤ）を動作させて一組の「コア」ポイントを判定すること、および各コアポイントに対するネットワーク性能を監視することをそなえている。後で説明するように、本発明のシステムは、好ましくはインタネット全体のユーザベースに対して、最適マップを予備演算する。これは有効に行うことができる。インタネットの部分を集合させて、それらを「コア」ポイントで表現することにより、システムが問題のスケールを縮小するからである。コアポイントは通常、与えられたネットワークロケーション（たとえば、データセンタ）の視点からポイントを共用する一組のローカルネームサーバ（または他のホスト）を表す。通常、コアポイントはインタネット上のルータであるが、これは要件ではない。コアポイントディスカバリプロセスから収集された情報は比較的頻繁に、たとえば、３０秒毎に１回マップ生成サーバに与えられ、これにより、特定のミラーサイトのホストとなるデータセンタへの結合性を損なったり、影響を及ぼす可能性のあるダウンルート、輻輳、ルート変更、および他のネットワークトラヒック条件が表される。
【００１９】
本発明の好適実施例によれば、コア（または「共通」）ポイントが次のように発見される。一組のミラーデータセンタの各々から、データセンタに記憶されたレプリカに対する要求を解決するためにクライアントが使用し得るローカルネームサーバに、インクリメンタルトレースルートが実行される。次に、共通ルーチングポイントでのトレースルート相互の交差が識別される。したがって、たとえば、共通ルーチングポイントは、データセンタの視点から見たとき、トレースルートに対する第一の共通ポイント（またはローカルネームサーバの視点から見たとき、トレースルートに対する最後の共通ポイント）であってもよい。このとき、共通ルーチングポイントはローカルネームサーバに対するコアポイントとして識別される。同様に、他のローカルネームサーバ（または他のホスト）に対してコアポイントが識別される。したがって、後で説明されるように、与えられた一組のミラーデータセンタはそれらに対応して、その一組のデータセンタへの相対結合性を推定する際に有用である一組のコアポイントをそなえてもよい。
【００２０】
図３は、本発明の一実施例によるコアポイントディスカバリプロセスの概略図である。例示の目的だけであるが、図３で、データセンタ３００は西海岸に配置されたデータセンタに対応し、データセンタ３０２は東海岸に配置されたデータセンタに対応する。もちろん、データセンタのロケーションは代表的なものに過ぎない。各データセンタは与えられたコンテントプロバイダに対するミラーサイトのホストとしての役目を果たすことができる。本発明によれば、コアポイント３０５は次のように発見される。一組のミラーデータセンタ３００、３０２の各々から、クライアントマシン３１０が使用し得るローカルネームサーバ３０４、３０６、３０８に、インクリメンタルトレースルートが実行される。たとえば、図３で、（図示されない）ネットワークエージェントはデータセンタ３００とローカルネームサーバ３０４、３０６、および３０８との間で第一組のトレースルートを実行し、データセンタ３０２とローカルネームサーバ３０４、３０６、および３０８との間で第二組のトレースルートを実行した。周知のように、それぞれのデータセンタとローカルネームサーバ（一つまたは複数）との間のネットワークパスはルータホップを含む。コアポイントを突き止めるために、ネットワークエージェントは、図３にコアポイント３０５として示されている共通のルーチングポイントでのトレースルートの交差点の、またはそれに近いロケーションを識別する。たとえば、共通のルーチングポイントは、データセンタ３００および３０２の視点から見たとき、トレースルートに対する第一の共通ポイント（またはローカルネームサーバ３０４の視点から見たとき、トレースルートに対する最後の共通ポイント）であってもよい。このとき、共通ルーチングポイントはローカルネームサーバに対するコアポイント３０５として識別される。図７は代表的なコアポイントディスカバリプロセスのトレースを示す。
【００２１】
たとえば、二つ以上の異なるパスがトレースされ、すべてのパスの少なくとも一部に同じルート（一つまたは複数）が現れた場合には、共通のルーチングポイントはルートのその共通部分に沿ったどこかにあり得る。上記のように、一般に、コアポイントはデータセンタの視点から見たときのトレースルートに対する第一の共通ポイントであり、これはローカルネームサーバの視点から見たときのトレースルートに対する最後の共通ポイントと同じである。
【００２２】
コアポイント３０５はトレースルートの「正確な」交差点にある必要はない。コアポイント３０５はたとえば、交差点の近傍、または実質的な近傍に配置することができる。コアポイント３０５は交差点に隣接して配置することもできるし、またはそのポイントに対して行われた測定が交差点で行われる測定を代表するような任意の近傍のポイントに配置することができる。
【００２３】
ネットワークエージェントは他のローカルネームサーバ（または他のホスト）に対する他のコアポイントを同様に識別する。したがって、後で説明されるように、与えられた一組のミラーデータセンタはそれらに対応して、その一組のデータセンタへの相対結合性を推定する際に有用である一つ以上のコアポイントをそなえる組をそなえてもよい。インタネット上のネットワークパスが頻繁に変化している場合には、ネットワークエージェントは好ましくは同じ頻度でコアポイントディスカバリを動作させる。
【００２４】
上記のようにネットワークエージェントは、既にマッピングされた一つ以上のローカルネームサーバに割り当てられたコアポイントを周期的にチェックする機能も果たす。次に、このプロセスについて説明する。
【００２５】
ネットワークエージェントは好ましくは、インタネットコントロールメッセージングプロトコル（ＩＣＭＰ）（またはいわゆる「ピング」（ｐｉｎｇ）パケット）を使用してコアポイントに対する測定を行うことにより、ラウンドトリップタイム（ＲＴＴ）、パケット損失、およびルータホップ数のような情報を評価する。したがって、図３の例を使用して、与えられたネットワークエージェントは周期的に（たとえば、３０秒毎に）コアポイントを「ピング」し、対応する待ち時間（ｌａｔｅｎｃｙ）およびパケット損失を収集する。このようなデータを使用して、ネットワークエージェントは平均待ち時間を計算する。一実施例では、ネットワークエージェントはすべての前の測定と新しい測定の指数的に時間重み付けされた平均を使用して平均待ち時間を計算する。ネットワークエージェントは類似の機能を使用して、平均パケット損失を計算する。この計算については、後で更に詳しく説明する。その結果を使用して、ネットワークエージェントはデータセンタの一つとコアポイントとの間の各パスに対する「スコア」を生成する。たとえば、平均待ち時間を特有の仕方で重み付けすることによりダウンロード予測を行う与えられたペナルティ係数で平均待ち時間を修正することにより、スコアが生成される。このとき、（その時間スライスに対する最良の動作を行うネットワークの結合性を表す）最良のスコアをどのデータセンタがそなえても、そのデータセンタはコアポイントと結合される。
【００２６】
図２に戻って、ウェブサーバエージェント２０４はすべてのウェブサーバＩＰアドレスまたはローカル負荷分散装置にテストダウンロードを行うことにより、（すなわち、データセンタミラーまたはウェブサーバ毎に）ミラーサイトのアベイラビリティまたは「アライブネス」をテストする。通常、ウェブサーバエージェントはオブジェクト、たとえば、ＨＴＴＰ　ＧＥＴ要求を介してウェブサーバ上で利用し得る２０バイトのファイルをテストし、エラーとダウンロード時間をチェックする。代表的な実施例では、測定は周期的に、たとえば、１０秒毎に行われるが、好ましくは顧客（ｃｕｓｔｏｍｅｒ）がタイムアウトを変更できる。ウェブサーバエージェントの中の与えられたパーセントより多くのウェブサーバエージェントがタイムアウト閾値内にテストオブジェクトをダウンロードすることができなければ、ＩＰアドレスは「デッド」と宣言される。これにより、顧客は応答時間に閾値を設定することにより、システムが性能が影響を受けるデータセンタにトラヒックを送らないようにできる。ウェブサーバエージェントは好ましくは、地理的に、またネットワークベースで分散されたロケーションが共通の設備内に分散される。更に、当業者には理解されるように、ウェブサーバエージェントの上記の機能は別の構成要素、たとえば、ネットワークエージェント、マップ生成サーバ、または他のあるサーバによって遂行することができる。更に、本発明のある実施例については、ウェブサーバエージェントもそれの機能（たとえば、データセンタのアライブネスのテストを行うこと）も必要でない。
【００２７】
マップ生成サーバ２０６はネットワークエージェントおよびウェブサーバエージェントからデータを受信し、このデータを使用してマップを生成する。マップは、各ＩＰアドレスブロックに対して最適であるミラーサイトを記述する。好適実施例では、ウェブサーバエージェントデータ、待ち時間とパケット損失の時間重み平均、およびＢＧＰと地理の情報によってマップが達成される。好ましくは、各顧客に対して二つのマップ生成サーバプロセスがあり、マップは周期的に、たとえば、３−５分毎に生成される。制約ではないが、好ましくは、マップ生成サーバはＩＰブロックをインタネット「領域」と結合することにより、与えられたマップでＩＰブロックが領域番号に対応するようにする。代表的な実施例では、（ＩＰブロックを領域＃に対応させる）マップが２、３分毎に生成された後、ネームサーバにアップロードされる。
【００２８】
ネームサーバ２０８は要求しているエンドユーザに最適データセンタのＩＰアドレス（一つまたは複数）を与える。通常、ネームサーバ応答は約５分の生存時間（ＴＴＬ：ｔｉｍｅ ｔｏ ｌｉｖｅ）をそなえているが、この値は顧客が形成してもよい（ｃｕｓｔｏｍｅｒ−ｃｏｎｆｉｇｕｒａｂｌｅ）。代表的な実施例ではネームサーバは、エンドユーザの要求をＣＤＮコンテントサーバへルーチングするのを容易にするためにＣＤＮＳＰによって使用されるのと同じネームサーバである。
【００２９】
図４はカスタマウェブサイトがどのように本発明のトラヒックリダイレクティングシステムに統合されるかを示す。代表的な実施例では、顧客が少なくとも二つ以上のミラーサイトの分散ウェブサイトをそなえているとする。本発明のシステムは、多数のサブドメイン／プロパティが同じデータセンタ内にあれば、それらのサブドメイン／プロパティの負荷分散を行う。統合のためには単に、顧客の、権限をもつネームサーバ４００がＣＮＡＭＥをＧＴＭネームサーバ４０８に返すように顧客が設定しさえすればよい。その後、ＧＴＭネームサーバ４０８を使用して、ミラーカスタマサイトに対するＤＮＳ問合わせを解決する。顧客の、権限をもつネームサーバで再帰もディセーブル（ｄｉｓａｂｌｅ）される。動作については、エンドユーザ４０２は従来のウェブブラウザ等を使用してミラーサイトに対して要求を行う。エンドユーザのローカルネームサーバ４０４は権限をもつネームサーバ４００に（または必要があればルートサーバに、ルートサーバは権限をもつネームサーバを表すデータを返す）要求を出す。次に、権限をもつネームサーバは管理されたサービス内のネームサーバ４０８のネームを返す。
【００３０】
次に、ローカルネームサーバはネームサーバ４０８にＩＰアドレスを問い合わせる。応答してネームサーバ４０８は、その与えられたローカルネームサーバに対して、したがって要求しているエンドユーザに対して「最適」である一つ以上のＩＰアドレスを含むセットでネームサーバ４０８は応答する。上記のように、ＩＰアドレスの最適セットは、ネットワーク上の代表的なコアポイントの性能をテストすることにより作成されたネットワークマップに基づいて生成される。ローカルネームサーバは「最適」ＩＰアドレスリストからＩＰアドレスを選択し、要求しているエンドユーザクライアントブラウザにこのＩＰアドレスを返す。次に、ブラウザはＩＰアドレスに接続されて、所望のコンテント、たとえば、要求されたサイトのホームページが検索される。
【００３１】
図５は、マップを作成するためにデータがどのように処理されるかを示す高レベルフローチャートである。周期的に（たとえば、３０秒毎に）、ネットワークエージェントは各データセンタから各コアポイントをピングする。これがステップ５００である。各ネットワークエージェントで、待ち時間の時間重み付けされた平均と損失の時間重み付けされた平均が演算される。これがステップ５０２である。後で説明されるように、重みは形成可能な時定数で時間とともに指数的に減衰する。ステップ５０４で、データが更に処理されることにより、コアポイント当たり各データセンタに対してスコアが作成される。次に、ステップ５０６で、各コアポイントは、そのコアポイントが代理であったネームサーバと結合される。ステップ５０８で、マップ生成プロセスはデータのすべてを通過し、各ネームサーバに対する一組の候補データセンタを決定する。このとき、ウェブサーバエージェントが「アライブ」でないと判定するどのデータセンタも捨てられる。ステップ５１０で、マップ生成プロセスはネームサーバに対するそれの判断をＩＰブロックに対する判断に拡張する。単一化アルゴリズムが使用されることにより、この機能が果たされる。このアルゴリズムは一般に次のように動作する。ＢＧＰ地理ブロックの中のすべてのネームサーバが一致するピング判断をそなえている場合には、どのデータセンタが「最適」であるかという判断がブロック全体に適用される。逆に、不一致がある場合には、各サブブロックですべてのネームサーバが一致するように、ブロックが最大の可能なサブブロックに分解される。ネームサーバをそなえないどのブロックに対しても、ＢＧＰ地理候補を使用してもよい。
【００３２】
次に、図５に戻ってステップ５１２で、各ブロックに対する候補でマップが作成される。多数の候補がある場合には、できる限り負荷分散の目標に近くなるように割当てが行われる。負荷分散の目標は通常、コンテントプロバイダによって規定され、これらの目標は所望のトラヒック量をデータセンタで分類するパーセント（合計すると１００％になる）であってもよい。これにより、マップ生成プロセスが完了する。
【００３３】
上記のように、ステップ５０２では待ち時間の時間重み付けされた平均と損失の時間重み付けされた平均が生成される。より一般的には本発明のこの側面は、種々のフロー制御プロトコル、たとえば、ＴＣＰに対する実際のダウンロード時間を予測するための組織的な方法を提供する。知られているように、ＴＣＰは今日インタネットで最も普通に使用されるフロー制御プロトコルである。他のプロトコルはＵＤＰの上に作られる。しかし、インタネット上のルートの状態を監視するためにＴＣＰパケットもＵＤＰパケットも使用することができない。本発明によれば、好ましい時点で（たとえば、ネットワークエージェントにより）ＩＣＭＰパケットがネットワークに注入された後、適切に選択された中間のコアポイントにルーチングされる。次にシステムは、待ち時間とパケット損失を演算することにより、ＩＣＭＰプローブによって誘導されるインタネットの動作を見る。待ち時間はサーバとコアポイントとの間のラウンドトリップタイム（ＲＴＴ）の尺度である。損失と待ち時間の時間系列を維持することから、システムは（コアポイントに対応するネームサーバを使用する）クライアントがサーバからのダウンロードを開始し、完了するのに要する時間量を有効に予測することができる。この予測の品質は有効なマッピングのために重要である。クライアントがウェブ要求を行い、サーバに至る可能性のある多数のウェブサーバがあるときには、どのウェブサーバが最良の接続性を正しく予測できることが重要であるからである。これは一般に困難な問題である。インタネットは非常にバースト性があり、非常に変化しやすいトラヒック条件を示すからである。
【００３４】
次の例は、本発明の一実施例によれば、時間重み付けされた平均がどのように演算されるかを示す。例示の目的だけで、コンテントプロバイダ（図３）が二つのデータセンタ３００（西海岸）と３０２（東海岸）に配置されたミラーサイトをそなえているものとする。ネットワークエージェントは各データセンタからコアポイント３０５を「ピング」する。ネットワークエージェントは行われる各測定に対して待ち時間とパケット損失を記憶する。待ち時間と損失のパラメータはネットワークエージェントが追跡することができる信号伝送パラメータの型を代表しているに過ぎないことは理解されるはずである。測定し得る他のパラメータは、速度、品質やネットワークパスの効率を判定するのに役立つ任意のパラメータ、たとえば、パスの機能停止、信号の強さの損失、エラー制御データ、ルート変更等を表すパラメータを含む。
【００３５】
各データセンタからコアポイントへの、また各データセンタへの各「ピング」について、それぞれのネットワークエージェントはデータのロギングを行う。表１は、データセンタとコアポイントとの間で３０秒毎に行われる測定の進行中にネットワークエージェントが集めるデータの型の例を示す。表１は待ち時間の測定値の表（データは秒単位）であり、現在の測定値（ｔ＝０）の後に前に測定された値を示す。
【表１】

【００３６】
表１が示すように、待ち時間に基づいて、この例では東海岸のデータセンタは西海岸のデータセンタに比べてより小さいコアポイントに対する平均待ち時間をそなえるように現れている。次に、待ち時間の時間重み付けされた平均と損失の時間重み付けされた平均が演算される。重みは形成可能な時定数（たとえば、３００秒の時定数）で時間とともに指数的に減衰する。ｔ_ｉがｉ番目の測定時点、ｘ_ｉが測定された値（たとえば、ｘ_ｉは待ち時間の測定値ｌａｔ_ｉまたは損失の測定値ｌｏｓｓ_ｉであり得る）である測定系列（ｔ_ｉ，ｘ_ｉ）に対して、待ち時間の時間重み付けされた平均が次のように演算される。

【００３７】
時定数Ｃ＝３００秒と仮定し、表１のデータを使用して、平均待ち時間の時系列は次のように演算される。
データを使用して、データセンタ３００に対する平均待ち時間は次のように演算される。

【００３８】
指数的に時間重み付けされた平均を演算するために、ネットワークエージェントは各重み付けされた待ち時間の測定値（たとえば、３１．８８）を加算し、この和を重み係数の和（すなわち、ｅ^{−３０／３００}＋ｅ^{−６０／３００}　．．．等）で割る。このようにして、データセンタ３００に対する指数的に時間重み付けされた平均待ち時間は次のように演算される。
指数的に時間重み付けされた平均＝３１．８８／４．０８９４
指数的に時間重み付けされた平均＝７．７９５
【００３９】
これらの演算が示すように、指数的に時間重み付けされた平均は７．７９であり、これは演算された平均７．７８とは異なる。この差はこの例では顕著ではないが、長期間にわたって平均された測定値についてはより顕著になり得る。より新しい測定値はより古い測定値に比べて大きな重みを与えられるからである。ネットワークエージェントは、一度最適とみなされたコアポイントがまだそうであるか、（与えられた期間の間）良好に動作していたコアポイントが今は劣化したか、等を動的に判定する。指数的に時間重み付けされた平均は測定されたデータの時間による異常をならすのにも役立ち、傾向を示すのに役立つ。
【００４０】
同じ情報を使用して、東海岸データセンタ３０２に対する時間重み付けされた平均待ち時間が同様にして演算される。更に、ここには示されていないが、ネットワークエージェントは同様に損失の時間重み付けされた平均を演算する。
【００４１】
上記のように、次に時間重み付けされた平均を処理することにより、コアポイント当たり各データセンタに対するスコアを作成する。好適スコアリング関数は次の通りである。
スコア関数＝平均待ち時間＋｛［ｍａｘ（１００，平均待ち時間）］^＊
（ペナルティ係数）｝
ここで、スコアはミリ秒を単位として表された値である。各値はミリ秒単位であるが、ペナルティ係数だけは無単位である。値「１００」はフロアまたはベースのレベルの値であり、これはパケットが東海岸と西海岸との間を進むのに必要な通常のラウンドトリップタイムを表す。フロアは可変である。「ｍａｘ」という用語は値「１００」と平均待ち時間のうち、どちらか大きい方を選択することを表す。次に、その値にペナルティ係数が乗算され、その結果が平均待ち時間に加算されて、スコアが生成される。ペナルティ係数は好ましくは、時間重み付けされた平均損失の関数である。したがって、一実施例では、ペナルティ係数は時間重み付けされた平均損失のある倍数である。乗数はたとえば、損失のパーセントの関数として変えてもよく、パケット損失が大きくなるほど、ペナルティ係数の寄与が大きくなる。
【００４２】
本発明によれば、時間重み付けされた平均待ち時間が時間重み付けされた平均損失のペナルティ係数で重み付けされたものに基づく上記のようなスコアリング関数はデータセンタから平均エンドユーザへの平均サイズ（たとえば、１０Ｋバイト）のファイルに対するダウンロードタイムの良好な近似すなわち「代わり」を与えるということが見出された。もちろん、ファイルサイズが変えられるにつれてファイルのダウンロードタイムは変化すると予想されるが、上記のスコアリング関数はなお、ミラーセットのどのデータセンタがより良い性能を与えるかを獲得する傾向があるということが見出された。換言すれば、与えられたスコアの絶対値はデータセンタ特有の（たとえば、西海岸対東海岸の）値ほど重要でない。
【００４３】
スコアがマップ生成プロセスに与えられるとき、ネットワークエージェントはコアポイントを、そのコアポイントが「代わり」としての役目を果たすローカルネームサーバと結合する。
【００４４】
次に、コンテントプロバイダに代わってミラーウェブサイトを運用することを提供する管理されたサービスとしてのグローバルトラヒック再方向付けシステムの特定の構成を説明する。図６はシステム全体のアーキテクチャ６００を示す。上記のように、これらのプロセスは通常、システム内の多数のサーバを通る。これらのプロセスの三つの論理的なグループ分けがある。第一に、ピングサーバ（ＰｉｎｇＳｅｒｖｅｒ）６０２、ピングプロセッサ（ＰｉｎｇＰｒｏｃｅｓｓｏｒ）６０４、およびテストピングサーバ（ＴｅｓｔＰｉｎｇＳｅｒｖｅｒ）６０６は、コンテントプロバイダのデータセンタ内に配置されたネットワークエージェント上で動作している。第二に、マップメーカ（ＭａｐＭａｋｅｒ）６０８、マップテスタ（ＭａｐＴｅｓｔｅｒ）６１０、およびＤＢプッシャ（ＤＢＰｕｓｈｅｒ）６１２はもう一組のサーバ上で動作している。しかし、これらは、グローバルトラヒック管理システムが動作するネットワーク内でサーバが不足している場合には、ネットワークエージェントマシン上で動作させてもよい。マップノートウェブ６１４およびマップノートＤＮＳ６１６と呼ばれるもう一組のプロセスは一緒に、システムのすべての顧客に対してマシンの比較的静的な組上で動作する。プロセス６０２、６０４、６０８、６１０、６１２、６１４および６１６は通常、連続的に動作する。アラート（ａｌｅｒｔ）プロセッサ（図示しない）はネットワーク上の一つ以上のマシンが機能を果たしていないかを検出し、一つ以上の対応する警報を送る。アーカイブプロセス（図示しない）は、周期的にファイルおよび他のシステムファイルの自動的ロギングをおこなうために使用される。ファイル移動プロセス（図示しない）は、データファイルを移動するために使用される。各サーバは総称プロセスモニタ（図示しない）を動作させてもよく、総称プロセスモニタはデータをサービスプロバイダ問合せシステムに報告する。
【００４５】
説明したように、グローバルトラヒック管理システム６００は数個のデータを収集し、その結果、マップがＧＴＭネームサーバ６１５にアップロードされる。初めに、コアポイントディスカバリ（ＣＰＤ）は（コアポイントを表す）ファイル内のＩＰアドレスのリストを作成する。このファイルは各ピングサーバ６０２に送られる。好ましくは、コンテントプロバイダのデータセンタ（図示しない）内に配置されるネットワークエージェントの各々で動作するピングサーバプロセス６０２がある。この実施例では、各データセンタに一対のマシンがあり、一方のピングサーバプロセスだけがプライマリである。他方のピングサーバプロセスは動作しているが、プライマリがダウンした場合だけ引き継ぐ。各ピングサーバプロセス６０２は約３０秒毎にコアポイントの各々をピングする。
【００４６】
次に、ピングの結果はピングプロセッサ６０４に送られる。ピングプロセッサ６０４は好ましくはマップメーカ６０８と同じマシン上で動作するが、これは必要条件ではない。ピングプロセッサ６０４はピングの結果を処理し、マップメーカ６０８に対してデータファイルを降ろす。マップメーカ６０８はマップノートウェブエージェント６１４からのデータも必要とする。マップノートウェブエージェント６１４はコンテントプロバイダのウェブサーバからのダウンロードをテストするウェブサーバエージェントである。これらのテストは、説明したようなデータセンタ内のウェブサーバのアライブネスを判定するために使用される。
【００４７】
マップメーカ６０８はピングデータとともにマップノートウェブデータを見て、トップレベルネームサーバに対するトップレベルマップを作成する。次に、マップはマップテスタ６１０（これは通常、同じマシン上で動作している）に送られる。マップテスタ６１０はテストピングサーバ６０６からのテストピングデータを使用して、マップ内の与えられた数の（たとえば、２００−３００個の）ＩＰアドレスをチェックする。これはマップが正しいことを確かめるために行われるが、この処理は選択的である。最後に、マップがテストに合格すれば、マップはネームサーバ６１５へのアップロードのために列に並ばされる。
【００４８】
ＤＢプッシャ６１２は、好ましくはマップメーカ６０８と同じマシンで動作する他の一つのプロセスである。トップレベルネームサーバ６１５にＤＢファイルを押し出すのはこのプロセスの単独責任である。このＤＢファイルはトップレベルネームサーバ６１５に対するルックアップデータを完成させる。すなわち、マップメーカ６０８からのマップは仮想領域番号へのＩＰアドレスのマッピングを含む。ＤＢファイルは物理ＩＰアドレスへの領域番号のマッピングを実際にそなえるデータファイルである。ＤＢプッシャ６１２はマップノートウェブデータを監視し、失敗の場合には更新されたＤＢファイルをネームサーバに押し出す。
【００４９】
ピングサーバ６０２はＲＴＴとパケット損失をコアポイントのリストに対して測定する責任がある。コアポイントのリストは次のように決められる。好ましくは、コンテントプロバイダが共通に配置される各データセンタに各コンテントプロバイダに対して動作するピングサーバプロセスがある。したがって、一実施例では、サービスプロバイダはコンテントプロバイダのデータセンタのすべてにサーバを配置する。もう一つの実施例（図示しない）では、特定のデータセンタに共にあるすべての顧客に対してピングデータが共有され、ＧＴＭサービスプロバイダは単に「ポピュラーな」ホスティング設備にサーバを予め配置することにより、システムを使用するように新しい顧客を統合する際の時間を節減する。
【００５０】
ピングサーバプロセスはデータセンタ内のネットワークエージェントの各々で動作させる。リーダ選択プロセス（図示しない）を使用して、その同じデータセンタ内でプライマリが失敗した場合には非リーダが引き継げることができるようにしてもよい。ピングサーバはＩＰアドレスのリストをピングするために使用されるプロセスを含み、ＩＰアドレスのリストはピングサーバがシステムソースから受信する。また、リストがピングされる前に、限定されたリスト上にあるどのＩＰアドレスもフィルタアウトされる。特に、ピングサーバへのプライマリ入力は次の通りである。
・　限定されたトリー　−　ピングされないＩＰアドレスのリスト。
・　ルータファイル　−　コアポイントディスカバリを使用して発見されたＩＰアドレスのリスト。
ピングサーバの出力は次の通りである。
・　ピングの結果　−　ピングしているＩＰアドレスのなま結果。
・　ルータファイル　−　ピングサーバが使用したすべてのＩＰアドレスのリスト。
【００５１】
ピングプロセッサはピングサーバからなま測定データを取り込んで、時間重み付けされた平均を演算する責任がある。コアポイントに対するＲＴＴとパケット損失測定値の両方に対して時間重み付けされた平均が演算される。時間重み付けされた平均は次のように演算される。ピングプロセッサプロセスのプライマリ入力は次の通りである。
・　ピングサーバからのピング結果
・　ピングサーバからのルータファイル
ピングプロセッサの出力は次の通りである。
・　ネームサーバリスト
・　処理されたピングデータ
【００５２】
マップメーカはトップレベルネームサーバに対するマップを作成する。マップメーカはピングプロセッサからの処理されたピングデータとマップノートウェブからのアライブネスデータを取り込み、マップを作成する。このマップはあるＩＰブロックと領域番号との間の関係を含む。マップメーカの入力は次の通りである。
・　ピングプロセッサからのネームサーバ
・　ピングプロセッサからのピングスコア
・　ＢＧＰ−地理トリー情報
マップメーカの出力はたとえば、
・　デバッグマップ
・　マップ状態ファイル
・　マップ
・　ピングデータ
を含み得る。
【００５３】
マップテスタは、マップがトップレベルネームサーバにアップロードされる前の最後のプロセスである。マップテスタはマップメーカから候補マップを受信する。次に、マップテスタは（後で更に詳しく説明される、テストピングサーバを使用してピングされる）テストＩＰアドレスのマッピングを探す。差の数がある閾値より下である場合には、マップは受け入れ可能であるとみなされる。
【００５４】
次に、マップはトップレベルネームサーバにアップロードされる。マップテスタのプロセスの入力は次の通りである。
・　デバッグマップ
・　テストピングデータ
・　状態ファイル
・　マップ
・　ピングデータ
マップテスタのプロセスの出力は次の通りである。
・　マップ
【００５５】
テストピングサーバはＩＰアドレスの小さな部分集合に対するＲＴＴとパケット損失情報を収集する。マップメーカによって作成されたマップが妥当であることを確実にするために、このデータが収集される。マップが良好であるものとして、次にマップテスタはマップをトップレベルネームサーバにロードする。テストピングサーバの入力は次の通りである。
・　限定されたトリー
・　テストすべきＩＰアドレスのリスト
テストピングサーバの出力は次の通りである。
・　テストピングデータ
【００５６】
上記のように、マップメーカマップはＩＰブロックと領域番号との間のマッピングを提供するだけなので、好ましくは別のプロセスを使用して領域番号とウェブサーバ（一つまたは複数）の実際のＩＰアドレスとの間のマッピングを提供する。ＤＢプッシャはマップノートウェブを処理し、トップレベルネームサーバにアップロードされるＤＢファイルを作成する責任がある。次に、トップレベルネームサーバは、マップ内の与えられたＩＰに対する領域番号を判定した後、対応するＤＢファイル内で、与えるべきＩＰアドレスの正しい組を見出す。ＤＢプッシャの入力は次の通りである。
・　マップノートウェブデータ
ＤＢプッシャの出力は次の通りである。
・　ネームサーバに対するＤＢファイル　−　このファイルはＤＢプッシャにより直接ネームサーバに押し出される。
【００５７】
マップノートウェブは、トラヒック管理システムを使用するすべての顧客に対する選択された数のサーバで動作させられる。マップノートウェブは、それがその上でテストダウンロードを行うターゲットＵＲＬのリスト（これは、たとえば、それの構成ファイルに記憶され得る）を使用する。好ましくは、これらのテストは簡単なＨＴＴＰ　ＧＥＴ要求であり、時間とエラーだけが重要である。このデータを解釈することにより、データセンタまたはウェブサーバがアライブかデッドかを判定することができる。ダウンロードタイムは時間重み付けされた平均を使用して履歴的に記憶される。マップメーカとＤＢプッシャはともにこのデータを使用する。マップノートウェブは次の通りである。
・　（構成ファイルに記憶された）測定すべきターゲット
マップノートウェブに対する出力は次の通りである。
・　テスト結果のダウンロード
【００５８】
ウェブサーバを監視する代わりにマップノートＤＮＳはネームサーバを監視することを除いて、マップノートＤＮＳはマップノートウェブに関連している。それの基礎的機能は、あるネームに対するネームサーバで測定を行い、時間を報告することである。答えが戻ってこない場合には、プロセスは失敗を起こしたのがネームサーバかネットワークかを判定するためにピングしょうとする。マップノートＤＮＳへの入力は次の通りである。
・　テストすべきネームサーバ
・　テストすべきドメイン
マップノートＤＮＳの出力は次の通りである。
・　ＤＮＳ問合せ結果
【００５９】
詳細には説明しないが、（本発明に関連しない）種々のテストを実行して上記プロセスの各々が正しく動作しているか判定してもよい。
【００６０】
本発明のインテリジェントトラヒックリダイレクションシステムは多数の利点をそなえている。本システムは絶えず、インタネット全体のユーザに基づく（または、希望される場合には、それの与えられた小部分）に対する最適マップを事前演算する。これを有効に行うことができるのは、システムがインタネットの部分を集合させて、それらをコアポイントで表すことにより問題の規模を縮小しているからである。システムは複製されている（ｂｅｉｎｇ ｒｅｐｌｉｃａｔｅｄ）サービスに応じて異なる種類の測定を行うこともできる。本システムはコアポイントに対するこれらの測定を組み合わせて判断とし、たとえば、ＢＧＰと地理情報を使用してＩＰアドレス空間のフォールバックパーティションを越えた単一化を使用して（ｕｓｉｎｇ ｕｎｉｆｉｃａｔｉｏｎ ｏｖｅｒ ａ ｆａｌｌｂａｃｋ ｐａｒｔｉｔｉｏｎ）本システムはそれらの判断をインタネット全体に拡張する。本システムはコスト最少化のための負荷分散の能力でも独特である。
【００６１】
本システムはすべての時点でインタネット全体に対する最適マッピングを事前演算することができる。不良ネットワーク条件に対する反応能力が極めて早いだけでなく、その応答も極めてきめ細かである。本システムは不良サーバ条件を素早く検出することができ、また多数のローカル負荷分散器とインタフェースすることができる。コアポイントを演算することにより、本システムはファイアウォールおよび他の検出機構に侵入するという問題を緩和する、すぐれた測定を行う。更に、従来技術と異なり、本システムは帯域幅コストを最小にするように負荷分散を行うことができる。
【００６２】
単一化アルゴリズムは、それが部分空間に対して高品質の信頼できる情報を使用し、低品質の情報に後退するのではなく高品質の信頼できる情報を空間全体に拡張するという点で有利である。これは、インタネットルータが高速ルックアップを可能にするためＩＰアドレスを集合させるためのＣＩＤＲ方式を利用するという事実とともに、ＣＩＤＲに基づくＩＰアドレシングの自然なトリー状階層構成を利用することにより達成される。この手法により、再方向付けシステムはＩＰアドレスの空間全体の部分集合から高品質情報の利点を拡張することができる。これは、インタネットが指数的に成長しつつあるので、非常に重要である。単一化アルゴリズムにより、サービスプロバイダははじめてＣＤＮにアクセスしつつある新しいホストをインテリジェントに扱う手段が得られる。現在のテクノロジーはこのようにマッピング判断を拡張する手段をそなえていない。現在のテクノロジーは低品質情報に後退するか、または本質的に何らの情報も具体化しない、たとえば、ラウンドロビンのようなデフォルト手法を使用する。
【００６３】
ＩＣＭＰプローブと時系列手法を使用するダウンロードタイムの予測にも多数の利点がある。この手法はファイルサイズの範囲とダウンロードの型にいかなる制限も課さず、また異なるサイズのＩＣＭＰプローブをインテリジェント使用することによりパケット損失を有効に推定する。この手法は、時系列を追跡するための状態はほとんど必要とせず、すべての前の測定値と新しい測定値の指数的に時間重み付けされた平均を使用して新しい推定を素早く演算することができる。ＴＣＰフローの確率的モデルを作ろうとするのではなく、本発明の手法はＩＣＭＰプローブに基づくダウンロードタイムの良好な予測器を抽出するための一般的な方法を提供する。
【００６４】
好適実施例では、インテリジェントなトラヒック再方向付けシステムを使用することにより、トラヒックをミラーウェブサイトに向かわせる。一般的に言うと、本発明のシステムと管理されたサービスは、エンドユーザが複製されたリソースにアクセスする必要のあるどんな状況でも使用することができる。上記のように、システムはエンドユーザを適当なレプリカに向かわせ、レプリカへのエンドユーザのルートがネットワークの見地から良好で、レプリカが過負荷にならないようにする。「エンドユーザ」はどのクライアントシステム、マシン、プログラム、またはプロセスに一般化してもよい。したがって、本システムの他の用途には制約なしに、キャッシュを記憶サーバに向かわせること、ストリーミングサーバを信号取得ポイントに向かわせること、ロギングプロセスをログアーカイブサーバに向かわせること、メールプロセスをメールサーバに向かわせること等を含めてもよい。
以上、我々の発明を説明した。
【００６５】
（関連出願）
本出願は２０００年５月２６日に出願された仮出願番号６０／２０８，０１４に基づいており、それにより優先権を主張する。
【図面の簡単な説明】
【図１】本発明によるグローバルトラヒックマネジャによって管理されるミラーウェブサイトの図である。
【図２】ＧＴＭサービスの構成要素の高レベル図である。
【図３】本発明のコアポイント発見プロセスの概略図である。
【図４】管理されるサービスに統合されたミラーウェブサイトに対する本発明のグローバルトラヒックリダイレクションシステムによってエンドユーザ要求がどのように処理されるかを示す概略図である。
【図５】ＧＴＭシステムによってどのようにマップが生成されるかを示すフローチャートである。
【図６】本発明のグローバルトラヒック管理システムの一つの実施例の概略ブロック図である。
【図７】コアポイント発見プロセスの間に生成される代表的なトレースルートである。

Claims (11)

1. 一組のコンテントプロバイダミラーサイトの中のどれがエンドユーザの最初のコンテント要求を受信すべきかを決定する方法であって、
   一組のミラーサイトの各々から発して与えられたネームサーバに向かうトレースが交差するインタネット内の与えられたポイントを各代理ポイントが表す、一組の代理ポイントを識別することと、
   代理ポイントを精査することにより、与えられたデータを生成することと、
   前記与えられたデータに基づいて各ミラーサイトに対するダウンロード予測子スコアを生成することと、
   前記ダウンロード予測子スコアに基づいてどのミラーサイトが最良のダウンロード性能を与えるかを識別することと、
   与えられたネームサーバＩＰアドレスを前記識別されたミラーサイトと結合することと、
   与えられたローカルネームサーバに対するエンドユーザの最初のコンテント要求に応答して、前記識別されたミラーサイトのＩＰアドレスを返送することと
   を含む決定方法。
2. 一組のミラーサイトで複製される（ｒｅｐｌｉｃａｔｅｄ）コンテントプロバイダウェブサイトに対するユーザの最初の要求を最適化する方法であって、
   前記コンテントプロバイダウェブサイトに要求を行っているエンドユーザのローカルネームサーバに応答して、一組の代理ポイントからミラーサイトへの相対接続性を推定するネットワークマップをそなえるグローバル負荷分散サービスに前記要求を向かわせることと、
   前記ネットワークマップを使用して、前記要求がサービスを受けられる最適のミラーサイトを表すＩＰアドレスを前記エンドユーザのローカルネームサーバに返送することと
   を含む最適化方法。
3. 各コアポイントがミラーサイトから発してローカルネームサーバに至るトレースルートの交差点を表す、請求項２記載の最適化方法。
4. 一組のミラーサイトで複製されるコンテントプロバイダウェブサイトに対するユーザの最初の要求をルーチングする方法であって、
   前記コンテントプロバイダウェブサイトに要求を行っているエンドユーザのローカルネームサーバに応答して、一組の代理ポイントからミラーサイトへの相対接続性を推定するネットワークマップをそなえるグローバル負荷分散サービスに前記要求を向かわせることと、
   前記エンドユーザのローカルネームサーバを前記ミラーサイトの一つに結合するデータを前記ネットワークマップが含むかどうかを判定することと、
   前記データを前記ネットワークマップが含まない場合には、デフォルトルーチング機構を使用して前記要求に応答すべき与えられたミラーサイトを識別することと
   を含む要求ルーチング方法。
5. 前記デフォルトルーチング機構がＢＧＰである、請求項４記載の要求ルーチング方法。
6. 前記デフォルトルーチング機構が地理ルーチング（ｇｅｏ−ｒｏｕｔｉｎｇ）である、請求項４記載の要求ルーチング方法。
7. ミラーサイトを運用している一組のコンテントプロバイダに対するグローバルトラヒックリダイレクションの管理方法であって、
   ミラーサイトのホストとなる一組のデータセンタの各々から、一組のコアポイントの各々に対して、与えられたネットワークテストを実行することと、
   前記与えられたネットワークテストを実行することにより生成されたデータに基づいて、与えられた計量の時間重み付けされた平均を生成することと、
   コアポイント当たり各データセンタに対するスコアを生成することと、
   一組のネームサーバの各々に対する一組の候補データセンタを生成することと、
   候補データセンタを一組のＩＰアドレス空間ブロックの各々に結合することによりマップを生成することと、
   前記マップをネームサーバに与えることと、
   前記マップを使用することにより、ミラーサイトに対するエンドユーザの要求を与えられたデータセンタに向かわせることと
   を含むグローバルトラヒックリダイレクション管理方法。
8. 前記与えられたネットワークテストがピングテスト（ｐｉｎｇ ｔｅｓｔ）である、請求項７記載のグローバルトラヒックリダイレクション管理方法。
9. 前記与えられた計量が待ち時間（ｌａｔｅｎｓｙ）またはパケット損失である、請求項７記載のグローバルトラヒックリダイレクション管理方法。
10. 前記一組の候補データセンタから、与えられた運用基準に適合しないどのデータセンタをも廃棄するステップをも含む、請求項７記載のグローバルトラヒックリダイレクション管理方法。
11. 前記与えられた運用基準がファイルダウンロードテストを使用して評価される、請求項１０記載のグローバルトラヒックリダイレクション管理方法。

Images