JP2012257338A - グローバルトラフィックロードバランシングのためのクライアントの場所及びリゾルバの負荷を判断するためのｄｎｓワイルドカードビーコニング - Google Patents

Abstract

【課題】ＬＤＮＳリゾルバの背後にあるクライアントを特定する。
【解決手段】ウェブビーコンがクライアントに一意のホストネームにおけるゼロコンテンツ画像を取り出す指示。クライアントがＬＤＮＳリゾルバにホストネームを要求してＬＤＮＳはそれを情報提供サーバ／ビーコンリゾルバへ送信。ビーコンリゾルバはＬＤＮＳのＩＰアドレスとホストネームを記録し、ＬＤＮＳはクライアントへ転送されたビーコンコレクションサーバのＩＰアドレスで応答。クライアントは一意のホストネームを含む要求をビーコンコレクションサーバへ送信。ビーコンコレクションサーバはクライアントのＩＰアドレスとホストネームを記録。集約サーバがビーコンリゾルバとビーコンコレクションサーバからデータを収集。ホストネームでクライアントのＩＰアドレスがＬＤＮＳリゾルバのＩＰアドレスにマッピングされ、それでロードバランシングサーバがルーティングを決定。
【選択図】図１

Description

本発明は、ネットワークにおけるグローバルトラフィックロードバランシングに関する。

この項で説明するアプローチは追求できるアプローチではあるが、必ずしも以前から想到又は追求されていたアプローチではない。従って、他に指示がない限り、この項で説明するアプローチのいずれかを、単にこの項に含まれているという理由で従来技術として見なすべきではない。

本明細書で使用する場合、「データセンタ」という用語は、関連するサーバのコロケーションを意味する。特定のデータセンタに属するサーバは同じ建物又は複合施設内に存在するが、データセンタは、通常互いに地理的に離れて位置する。自然災害によって引き起こされた一方のデータセンタにおける突発的故障が他方のデータセンタにおいても故障を引き起こさないように、この地理的な距離により保護が加えられる。例えば、１つのデータセンタがニューヨークのイーストコーストに位置し、別のデータセンタがサンフランシスコのウエストコーストに位置する場合がある。

グローバルロードバランシングすなわち「ＧＬＢ」は、特定のサービスへのクライアントアクセスを複数のサーバに分散させるためのメカニズムである。例えば、特定のサービスがニューヨークのデータセンタに属するサーバとサンフランシスコのデータセンタに属するサーバとによって提供される状況では、ＧＬＢは、ニューヨークのデータセンタに接続されるクライアントの数が、サンフランシスコのデータセンタに接続されるクライアントの数とほぼ同じになるようにクライアントアクセスを分散させることができる。

インターネットとの関連において使用する場合、ＧＬＢは、様々な能動的及び受動的モニタリング技術を使用してインターネットの複雑なマップを生成することができる。このマップに基づき、ＧＬＢは、トラフィックルーティングを決定してクライアントを「最も近い」サーバに接続する。本明細書で使用する場合、「近い」とは、必ずしも決定の基礎を地理的な近さのみに置くことを意味するものではない。本明細書で使用する場合、「近い」サーバとは、クライアントへの接続が最も速いサーバのことである。従って、混雑により、クライアントが２００マイル離れたところにあるサーバに到達するよりも１００マイル離れたところにあるサーバに到達する方が遅い場合、ＧＬＢは、クライアントを２００マイル離れたところにある「より近い」サーバへルーティングする。

ユーザがウェブアプリケーション又はウェブページに接続したいと望む場合、ＤＮＳ要求が行われる。ＤＮＳ要求は、ユーザがクライアントの機械を介して要求を行うことにより、多くの場合はウェブブラウザに（「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ」などの）ドメインをタイピングすることにより開始する。要求は、クライアントからサービスプロバイダのローカルＤＮＳリゾルバ（「ＬＤＮＳ」）へ送信される。ＬＤＮＳリゾルバは、クライアントからの要求を受け付け、ＬＤＮＳリゾルバが要求に対する回答をキャッシュに記憶している場合にはドメインのＩＰアドレスで要求に応答する。ＬＤＮＳが回答を記憶していない場合には、ＬＤＮＳは要求を情報提供(authoritative)ＤＮＳリゾルバへ転送する。情報提供ＤＮＳリゾルバとは、ドメインのネットワークのためのデータを保持するサーバのことである。情報提供ＤＮＳリゾルバは、ＬＤＮＳリゾルバから要求を受信し、ドメインに接続するための特定のサーバのＩＰアドレスでＬＤＮＳリゾルバに応答する。本明細書で使用する場合、ＧＬＢリゾルバは情報提供ＤＮＳリゾルバの一部であってもよい。ＧＬＢリゾルバはまた、情報提供ネームサーバとは別個のものであってもよく、或いは離れて位置していてもよい。これは実施構成ごとに異なることができる。

残念ながら、ＧＬＢの決定が不十分なデータに基づく場合がある。例えば、ＬＤＮＳリゾルバからＧＬＢに要求が行われた場合、この要求はＬＤＮＳに関する情報しか含んでおらず、要求を発信したクライアントに関する情報は含んでいない。従って、ＧＬＢは、クライアントよりもむしろＬＤＮＳリゾルバの場所及び混み具合に基づいて決定を行うことを強要される。

ルーティング情報の基礎をクライアントではなくＬＤＮＳリゾルバに置くことにより、２つの主な問題が生じる可能性がある。第１に、クライアントが、地理上及びネットワーク上でＬＤＮＳリゾルバとは全く異なる場所に位置する可能性がある。この結果、多くの場合ＧＬＢによる近接性マッピングが不正確になる。第２に、ＬＤＮＳリゾルバが応答をキャッシュするので、ＧＬＢは、ＬＤＮＳリゾルバの背後に存在するクライアントにより生成された要求の量を特定することができない。ＤＮＳルックアップを行う１人のユーザ及び１００万人の異なるユーザが、ＧＬＢにおいて同じ量のトラフィックを生成することができる。これにより、ロードバランシングの決定が非常に不正確になる。

ＤＮＳに基づくＧＬＢの例を図１に示す。図１では、２つのデータセンタ又はコロケーションが、地理的に異なるエリアに位置する。一方のデータセンタはニューヨーク１０３に位置し、他方のデータセンタはサンフランシスコ１０１に位置する。ニューヨーク１０３のデータセンタは１．２．３．４というＩＰアドレスを有し、サンフランシスコ１０１のデータセンタは２．２．２．２というＩＰアドレスを有する。

クライアント１０５が、この２つのデータセンタによりホストされるウェブページ「ｗｗｗ．ｓａｍｐｌｅｃｏｎｎｅｃｔｉｏｎ．ｃｏｍ」に接続したいと望む。ＡＣＭＥインターネットサービスプロバイダを使用するクライアント１０５は、ドメインに接続する要求を行う。クライアント１０５からの要求は、まずＡＣＭＥ ＬＤＮＳリゾルバ１０７へ送信される１１１。この要求に基づいて、ＬＤＮＳはキャッシュに回答を記憶しておくことができ、或いはドメインのＩＰアドレスを提供するドメインの情報提供サーバへ要求を転送することができる。

ＡＣＭＥ ＬＤＮＳリゾルバ１０７は、ドメインのＩＰアドレスがＬＤＮＳリゾルバのキャッシュに記憶されているかどうかをチェックする。ＩＰアドレスがキャッシュに記憶されている場合、記憶されているＩＰアドレスが要求に応じてクライアントへ送信される。ドメインへのＩＰアドレスがキャッシュ内で見つからなかった場合、ＬＤＮＳリゾルバは、ドメイン「ｗｗｗ．ｓａｍｐｌｅｃｏｎｎｅｃｔｉｏｎ．ｃｏｍ」に対する要求を情報提供ＤＮＳリゾルバへ送信してＩＰアドレスを取得する。これを、ＧＬＢ及び情報提供ＤＮＳリゾルバ１０９に対して行われるドメイン「ｗｗｗ．ｓａｍｐｌｅｃｏｎｎｅｃｔｉｏｎ．ｃｏｍ」のための要求１１５の形で示している。

次に、（情報提供ＤＮＳリゾルバを含む）ＧＬＢ１０９は、ウェブページに対する要求に基づいて、ニューヨークの１．２．３．４というＩＰアドレス、又はサンフランシスコの２．２．２．２というＩＰアドレスのどちらを戻すかを決定する。ＧＬＢ内の論理が、要求が発信された場所を含む要求、及びサーバの利用可能性及び負荷を分析して、特定のクライアントにとっていずれの特定のサーバが最適であるかを決定する。

残念ながら、情報提供ＤＮＳサーバ１０９は、この要求がノースカロライナにあるＡＣＭＥ ＬＤＮＳリゾルバ１０７の場所から発信されたものであると見なし、アリゾナのクライアント１０５の場所から発信されたものであるとは見なさない。ＬＤＮＳリゾルバ１０７からの情報に基づいて、情報提供ＤＮＳサーバ１０９は、ノースカロライナからの要求に基づいて接続サーバを選択することができ、クライアント１０５からサンフランシスコへのより短い経路１１７ではなく、より地理的に長いニューヨークへの経路１１９が選択される。

情報提供ＤＮＳリゾルバ１０９は、ＬＤＮＳリゾルバの背後に存在する可能性があるクライアントの数を特定することができない。情報提供リゾルバへの１つの要求は、実際にはＬＤＮＳリゾルバの背後の多くのクライアントのためのものである可能性がある。例えば、ＡＣＭＥ ＬＤＮＳ１０７が、クライアント１０５のドメインに対する１つの要求を行う場合がある。最初の要求後に、ＡＣＭＥ ＬＤＮＳ１０７はドメインのＩＰアドレスをキャッシュに記憶する。１秒後に、１万件のさらなる要求が同じドメインに対して行われる。ＬＤＮＳリゾルバのキャッシュにはＩＰアドレスが記憶されているので、このＩＰアドレスが自動的にクライアントへ戻され、応答内の有効期間設定により指定された期間の間、情報提供ＤＮＳリゾルバへさらなる要求が送信されることはない。従って、サーバが過負荷又は故障状態になり、情報提供ＤＮＳサーバ及びＧＬＢ１０９が過負荷又は故障状態のサーバから健全なサーバにクライアントを移行させる必要が生じた場合、情報提供ＤＮＳサーバ１０９は、ＬＤＮＳリゾルバ１０７の背後に存在するクライアントの数を特定することができず、適切なロードバランシングを維持することができない。

本発明を、同じ参照数字が類似の要素を示す添付図面の図に限定としてではなく例示として示す。

クライアントがウェブアプリケーションに接続し、ＤＮＳベースのＧＬＢを介して様々なデータセンタ内にあるサーバに接続することを示す図である。 本発明の実施形態による、集約サーバが、ウェブビーコンに基づいてクライアントのＩＰアドレスをＬＤＮＳリゾルバのＩＰアドレスにどのようにマッピングするかを示す図である。 本発明の実施形態による、クライアントのＩＰアドレス及び特定のコロケーションに基づく接続時間計算テーブルを示す図である。 本発明の実施形態を実施できるコンピュータシステムを示すブロック図である。

ＬＤＮＳリゾルバの背後に存在するクライアントの数及び場所を特定し、この情報をトラフィックルーティング決定に使用するための技術について説明する。以下の説明では、説明を目的として、本発明の完全な理解をもたらすために数多くの特定の詳細について記載する。しかしながら、これらの特定の詳細を伴わずに本発明を実施できることが明らかであろう。その他の場合、本発明を不必要に曖昧にしないために、周知の構造及び装置についてはブロック図形式で示す。

全体の概要
ある実施形態では、特定のＬＤＮＳリゾルバの背後に存在するクライアントの数及び場所を特定するためのデータを生成するために、ＤＮＳワイルドカードビーコニングが使用される。次に、このデータを使用して、特定のＬＤＮＳリゾルバにより生み出されている負荷及びこの特定のＬＤＮＳリゾルバのクライアントがネットワーク内のどこに位置するかを推定する。この情報により、ＧＬＢサーバがより賢く正確なルーティング決定を行えるようになる。

ＤＮＳワイルドカードビーコニング
ある実施形態では、ＤＮＳワイルドカードビーコンが既存のウェブアプリケーションから起動される。本明細書で使用する場合、ウェブビーコンは、ピクセルタグ、クリアＧＩＦ、又はゼロコンテンツ画像としても知られている透明な又は目に見えないグラフィック画像であり、通常は１ｘ１ピクセル以下である。ある実施形態では、作成ウェブページ内に少量のコード又はビーコンコードを配置することによりウェブビーコンが生成される。クライアントは、作成ウェブページを要求し、データセンタ内のウェブサーバからこれを供給される。作成ウェブページがクライアントにより処理されると、ビーコンコードがクライアントブラウザに、ビーコンコード内で指定されたビーコンサーバからウェブビーコンを取り出させる。要求はクライアントのバックグラウンドで行われるので、ウェブサーバからの現在のウェブページのロードと干渉が起きることはない。

ある実施形態では、ウェブビーコンのダウンロードのためのグローバルに一意のワイルドカードホストネームが生成され、このビーコンＵＲＬが既存のウェブ結果に埋め込まれ、この画像のダウンロードを進めるクライアントへ送信される。別の実施形態では、ＨＴＴＰ２０４（すなわち、「ノーコンテンツ」）のダウンロードのためのグローバルに一意のワイルドカードホストネームが生成され、ウェブ結果に配置される。例えば、次のグローバルに一意のワイルドカードホストネームが生成される。
「ｈｔｔｐ：／／１２０９３８９８９７８．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ／ｏｎｅｐｉｘｅｌ．ｇｉｆ」。
グローバルに一意のワイルドカードホストネームは、（１）一意の英数字の並び（「１２０９３８９８９７８」）、（２）ドメインネーム（「＊．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）、及び（３）取り出されるウェブビーコンオブジェクトの名前（「ｏｎｅｐｉｘｅｌ．ｇｉｆ」）を含む。

クライアントがビーコン画像をダウンロードするための処理を開始した場合、クライアントはまず、一意のホストネームからＩＰアドレスを導出する必要がある。クライアントが、クライアントのＬＤＮＳリゾルバへ要求を送信する。ＬＤＮＳリゾルバはＬＤＮＳリゾルバのキャッシュを調べ、要求内で要求されるホストネームにＩＰアドレスが利用可能かどうかを判定する。ＩＰアドレスが利用可能な場合、ＬＤＮＳリゾルバは、ホストネームのＩＰアドレスで要求に応答することになる。しかしながら、ウェブビーコンのためのホストネームはグローバルに一意であるため、ＩＰアドレスはＬＤＮＳリゾルバのキャッシュ内では利用可能でないはずである。

ホストネームのＩＰアドレスがキャッシュから利用できないという理由で、ＬＤＮＳリゾルバは要求を情報提供ＤＮＳリゾルバへ送信する。ある実施形態では、情報提供ＤＮＳリゾルバが、要求されたドメイン（この場合は、「ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）のためのビーコンリゾルバでもある。本明細書で使用する場合、「ビーコンリゾルバ」とは、情報提供ＤＮＳリゾルバにおいて受信された要求に基づいて統計値を測定し、ログに記録するサーバのことである。このビーコンリゾルバが、クライアントがウェブビーコンを取り出すことができるＩＰアドレスも戻す。

ある実施形態では、情報提供ＤＮＳリゾルバ／ビーコンリゾルバが、ドメイン（「＊．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）に対する要求にビーコンコレクションサーバのＩＰアドレスで応答するように構成される。これが行われると、ビーコンリゾルバは、全てのこのような要求に関して（「１２０９３８９８９７８．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」などの）一意のワイルドカードホストネーム及びＬＤＮＳリゾルバのＩＰアドレスをログに記録する。別の実施形態では、ビーコンリゾルバが、ホストネーム内にある一意の英数字の並び（「１２０９３８９８９７８」）及びＬＤＮＳリゾルバのＩＰアドレスを記録する。その後、ＬＤＮＳリゾルバ／ビーコンリゾルバは、ビーコンコレクションサーバのＩＰアドレスをクライアントへ送信する。

この結果、クライアントは、グローバルに一意のホストネームを含む要求を、要求されるＵＲＬのためのビーコンコレクションサーバに提出する。クライアントによる要求は、以下に限定されるわけではないが、ＨＴＴＰ、ＦＴＰ、又はＴＣＰに基づく他のあらゆる通信プロトコルを含むいずれの伝送制御プロトコル（「ＴＣＰ」）ベースのプロトコルであってもよい。ある実施形態では、クライアントが、同じグローバルに一意のホストネーム（すなわち、「１２０９３８９８９７８．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）をＨＴＴＰホストヘッダに挿入したＨＴＴＰ要求を、要求されるＵＲＬのためのビーコンコレクションサーバに提出する。ビーコンコレクションサーバは、クライアントからＨＴＴＰ要求を受信する。ビーコンコレクションサーバは、クライアントの一意のワイルドカードホストネーム及びＩＰアドレスをログに記録する。別の実施形態では、ビーコンコレクションサーバが、クライアントのホストネーム及びＩＰアドレス内の一意の英数字の並びをログに記録する。ビーコンサーバは、要求の性質に応じて、単一ピクセル、ゼロコンテンツ画像、又はＨＴＴＰ２０４をクライアントへ送信することにより要求に応答する。ビーコンリゾルバ内のカーネルモジュールにより、追加の接続品質統計値をログに記録し、測定することができる。

ある実施形態による、ウェブビーコン及びこのウェブビーコンを使用してクライアントを特定のＬＤＮＳリゾルバにどのようにマッピングするかを示す図を図２に示す。クライアント２００がウェブページを要求し、ウェブサーバ２０２からウェブページを供給されたときに処理が開始する。ウェブページ内にはビーコンコードが存在し、これがクライアント２００に、ビーコンコード内で指定された場所からウェブビーコン又はゼロコンテンツ画像を取り出すように指示する。ウェブページがクライアント２００によって処理されると、ウェブビーコンの取り出しが開始する。

（「１２３４５．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」などの）グローバルに一意のホストネームがウェブビーコンの場所として使用される。クライアント２００は、ホストネームからＩＰアドレスを導出するために、クライアント２００のＩＳＰが所有するＬＤＮＳリゾルバ２０４へウェブビーコンに対する要求を送信する。ＬＤＮＳリゾルバは、まずＬＤＮＳキャッシュ内でＩＰアドレスが利用可能かどうかをチェックする。ホストネームは一意であるので、ＬＤＮＳリゾルバは、ホストネームに対する要求を情報提供ＤＮＳリゾルバへ転送する。情報提供ＤＮＳリゾルバは、ホストネーム（すなわち、「＊．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）のためのビーコンリゾルバ２０６でもある。ビーコンリゾルバ２０６は、ＬＤＮＳリゾルバ２０４のＩＰアドレス及びホストネームの一意のワイルドカード（すなわち、「１２３４５」）をログに記録する。次に、ビーコンリゾルバ２０６は、クライアントがウェブビーコンを要求できるビーコンコレクションサーバ２０８のＩＰアドレスをＬＤＮＳリゾルバ２０４へ戻す。ＬＤＮＳリゾルバ２０４は、ビーコンコレクションサーバ２０８のＩＰアドレスをクライアント２００へ転送する。次に、クライアント２００は、ＨＴＴＰ要求（「１２３４５．ｄｎｓｂ．ｃｏｍｐａｎｙ．ｃｏｍ」）をビーコンコレクションサーバ２０８へ送信する。ビーコンコレクションサーバ２０８は、クライアントから要求を受信し、クライアント２００のＩＰアドレス及びホストネームの一意のワイルドカード（すなわち、「１２３４５」）をログに記録する。ビーコンコレクションサーバ２０８は、ゼロコンテンツ画像又はＨＴＴＰ２０４（ノーダウンロード）ステータスでクライアント２００に応答する。

データの集約及び処理
ある実施形態では、集約サーバが、ビーコンリゾルバ及びビーコンコレクションサーバからデータを収集する。ビーコンリゾルバからのデータは、ＬＤＮＳのグローバルに一意のホストネーム及びＩＰアドレスを含む。ビーコンコレクションサーバからのデータは、クライアントのグローバルに一意のホストネーム及びＩＰアドレスを含む。このグローバルに一意のホストネームをキーとして使用して、集約サーバは、クライアントのＩＰアドレスを特定のＬＤＮＳのＩＰアドレスにマッピングすることができる。このようにして、時間をかけてデータを集約することにより、特定のＬＤＮＳの背後に存在するクライアントの数及びＩＰアドレスが特定される。記憶したクライアントのＩＰアドレスに基づいて、ネットワーク内のクライアントの近接性を特定することもできる。その後、より正確なルーティングを行うために、このデータを集約サーバからＧＬＢサーバにエクスポートすることができる。

この処理の図を図２に示す。図２では、ビーコンリゾルバ２０６が、要求からＬＤＮＳリゾルバ２０４のＩＰアドレス及びホストネーム内の一意の並び（「１２３４５」）をログに記録している。ビーコンコレクションサーバは、要求からクライアント２００のＩＰアドレス及びホストネーム内の一意の並び（「１２３４５」）をログに記録している。集約サーバ２１０は、ログに記録されたデータをビーコンリゾルバ２０６及びビーコンコレクションサーバ２０８から収集する。集約サーバ２１０において、一意のホストネームのシーケンスをキーとして使用して、クライアント２００のＩＰアドレスがＬＤＮＳリゾルバ２０４のＩＰアドレスにマッピングされる。従って、この例では、ＬＤＮＳリゾルバ２０４が一意のホストネーム「１２３４５」に関連付けられ、クライアント２００が一意のホストネーム「１２３４５」に関連付けられる。ホストネーム（「１２３４５」）がマッチすることにより、クライアント２００のＩＰアドレスがＬＤＮＳリゾルバ２０４のＩＰアドレスにマッピングされる。ＧＬＢサーバがクライアントの近接性及び負荷に基づいて以降の要求をより良好にルーティングするために、ＬＤＮＳリゾルバ２０４の背後にクライアント２００が存在するという情報が集約サーバ２１０からＧＬＢサーバ２１２へ送信される。

ある実施形態では、所与のＬＤＮＳリゾルバに関連するクライアントＩＰアドレスの数を求めることにより、特定のＬＤＮＳにおける負荷が正確に判断される。例えば、集約されたデータは、１つの特定のＬＤＮＳリゾルバが２０の異なるクライアントＩＰアドレスに関連付けられており、別の特定のＬＤＮＳリゾルバが５万の異なるクライアントＩＰアドレスに関連付けられていることを示すことができる。この技術は、ＬＤＮＳリゾルバから見た要求の種類及び幅に基づいて、負荷に関する推測を強いられるのではなく、ＬＤＮＳリゾルバからの負荷の正確な判定を可能にする。

ある実施形態では、特定のＬＤＮＳリゾルバの背後にあるクライアントのＩＰアドレスを分析することにより、クライアントの近接性マッピングが向上する。クライアントのＩＰアドレスに基づいて、地理的な及びネットワーク内のクライアントの場所の近似値が求められる。従って、ＬＤＮＳリゾルバから要求を受信すると、ＧＬＢは、ルーティング決定の基礎をＬＤＮＳの場所ではなくクライアントの場所に置くことができる。ＬＤＮＳリゾルバが、ＬＤＮＳリゾルバの関連するクライアントの場所から離れて位置する場合、ルーティングの向上は最も大きくなる。

集約サーバデータを使用するロードバランシングサーバ
続いて、グローバルロードバランサが集約サーバからのデータをどのように使用できるかの例を説明する。クライアントが特定のウェブページへの訪問を要求したときにグローバルロードバランシングが行われる。ＤＮＳルックアップを行って、クライアントにより入力された（「ｗｗｗ．ｙａｈｏｏ．ｃｏｍ」などの）ウェブサイトＵＲＬを（「２０９．１３１．３６．１５８」などの）ＩＰアドレスに変換する。ルックアップは、まずＬＤＮＳリゾルバを対象に行われ、ＬＤＮＳリゾルバが情報を所有していなければ、（ロードバランシングサーバでもある）情報提供ネームサーバを対象に行われる。ロードバランシングサーバが、ＬＤＮＳリゾルバの要求側ＩＰアドレスを調べる。次に、要求側ＩＰアドレスが、この特定のネットブロック又はＩＰアドレスの範囲に関する情報と比較される。ロードバランシングサーバが、近接性及び負荷などの様々な統計値によってソートされたリスト上の第１の利用可能なウェブサーバを選択し、ウェブサーバのＩＰアドレスをＬＤＮＳリゾルバへ戻す。ロードバランシングサーバは、ＬＤＮＳリゾルバの背後のクライアントに関する追加情報を有することにより、発信元クライアントを接続性が最もよいウェブサーバへより良好にルーティングする。

本発明の実施形態による、集約サーバからのデータをどのように使用するかを示す図を図３に示す。データは、「ＩＰアドレス」列３００、「コロケーションＡ」列３０２、「コロケーションＢ」列３０４、及び「コロケーションＣ」列３０６を有する。「ＩＰアドレス」列３００は、コロケーションの各々が接続する先のＩＰアドレスをリストしている。行３０８において、ＩＰアドレス「１．１．１．０」は、ｘを０〜２５５の間のいずれかの数とし得る場合にＩＰアドレス「１．１．１．ｘ」における機械がコロケーションＡに１０ミリ秒で、コロケーションＢに２０ミリ秒で、コロケーションＣに４０ミリ秒で接続できることを示している。

行３１０において、ＩＰアドレス「２．２．２．０」は、ｘを０〜２５５の間のいずれかの数とし得る場合にＩＰアドレス「２．２．２．ｘ」における機械がコロケーションＡに５０ミリ秒で、コロケーションＢに８０ミリ秒で、コロケーションＣに３０ミリ秒で接続できることを示している。

集約サーバからのデータは、ＩＰアドレス「５．５．５．５」のＬＤＮＳリゾルバが、半分はＩＰアドレス「１．１．１．ｘ」の、もう半分はＩＰアドレス「２．２．２．ｘ」のクライアントを含むことを示すことができる。この状況下では、接続時間の平均値を求めることにより、３つの異なるコロケーションセンタへの接続時間を求めることができる。

例えば、行３１２はＩＰアドレス「５．５．５．０」を示している。この行はＬＤＮＳリゾルバの接続時間を示す。従って、ＬＤＮＳリゾルバからコロケーションＡへの接続時間は、（「１．１．１．０」からの）１０ミリ秒と（「２．２．２．０」からの）５０ミリ秒との平均値の３０ミリ秒となる。ＬＤＮＳリゾルバからコロケーションＢへの接続時間は、（「１．１．１．０」からの）２０ミリ秒と（「２．２．２．０」からの）８０ミリ秒との平均値の５０ミリ秒となる。ＬＤＮＳリゾルバからコロケーションＣへの接続時間は、（「１．１．１．０」からの）４０ミリ秒と（「２．２．２．０」からの）３０ミリ秒との平均値の３５ミリ秒となる。ＬＤＮＳリゾルバから個々のコロケーションセンタへの接続時間は正確なものではないが、ＩＰアドレスに基づくクライアントの接続時間を考慮に入れることにより正確な推定を行うことができる。

ハードウェアの概要
図４は、本発明の実施形態を実施できるコンピュータシステム４００を示すブロック図である。コンピュータシステム４００は、情報を通信するためのバス４０２又はその他の通信機構、及び情報を処理するための、バス４０２に結合されたプロセッサ４０４を含む。コンピュータシステム４００はまた、プロセッサ４０４により実行される情報及び命令を記憶するための、バス４０２に結合されたランダムアクセスメモリ（ＲＡＭ）又はその他の動的記憶装置などのメインメモリ４０６も含む。メインメモリ４０６を使用して、プロセッサ４０４により実行される命令の実行中に一時的変数又はその他の中間情報を記憶することもできる。コンピュータシステム４００は、プロセッサ４０４のための静的情報及び命令を記憶するための、バス４０２に結合された読出し専用メモリ（ＲＯＭ）４０８又はその他の静的記憶装置をさらに含む。情報及び命令を記憶するための磁気ディスク又は光ディスクなどの記憶装置４１０が提供され、バス４０２に結合される。

コンピュータシステム４００を、バス４０２を介して、コンピュータユーザに情報を表示するためのブラウン管（ＣＲＴ）などのディスプレイ４１２に結合することができる。情報及びコマンド選択をプロセッサ４０４に通信するための英数字及びその他のキーを含む入力装置４１４がバス４０２に結合される。別の種類のユーザ入力装置には、方向情報及びコマンド選択をプロセッサ４０４に通信するとともにディスプレイ４１２上のカーソルの動きを制御するためのマウス、トラックボール、又はカーソル方向キーなどのカーソル制御４１６がある。通常、この入力装置は、装置が平面内で位置を特定できるようにする、（ｘなどの）第１軸及び（ｙなどの）第２軸の２つの軸の形の２つの自由度を有する。

本発明は、本明細書で説明する技術を実施するためのコンピュータシステム４００の使用に関する。本発明の１つの実施形態によれば、これらの技術は、メインメモリ４０６に含まれる１又はそれ以上の命令の１又はそれ以上の連続をプロセッサ４０４が実行することに応答してコンピュータシステム４００により実行される。このような命令を、記憶装置４１０などの別の機械可読媒体からメインメモリ４０６に読み込むことができる。メインメモリ４０６に含まれる一連の命令を実行することにより、本明細書で説明する処理ステップをプロセッサ４０４が実行するようになる。代替の実施形態では、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて配線回路を使用して本発明を実施することができる。従って、本発明の実施形態は、ハードウェア回路とソフトウェアとのいずれの特定の組み合わせにも限定されるものではない。

本明細書で使用する「機械可読媒体」という用語は、特定の様式で機械を動作させるデータを提供することに関与するあらゆる媒体のことを意味する。コンピュータシステム４００を使用して実施される実施形態では、例えば、実行用のプロセッサ４０４に命令を提供することに様々な機械可読媒体が関与する。このような媒体は、以下に限定されるわけではないが、記憶媒体及び送信媒体を含む多くの形を取ることができる。記憶媒体として、不揮発性媒体及び揮発性媒体の両方が挙げられる。不揮発性媒体としては、例えば記憶装置４１０などの光又は磁気ディスクが挙げられる。揮発性媒体としてはは、メインメモリ４０６などの動的メモリが挙げられる。送信媒体として、バス４０２を含むワイヤを含む、同軸ケーブル、銅線及び光ファイバーが挙げられる。送信媒体はまた、電波及び赤外線データ通信中に生成されるような音波又は光波の形を取ることもできる。このような媒体は全て、媒体によって運ばれた命令を、機械に命令を読み込む物理機構により検出できるようにするために有形のものでなければならない。

機械可読媒体の共通形式として、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他のあらゆる磁気媒体、ＣＤ−ＲＯＭ、他のあらゆる光媒体、パンチカード、紙テープ、穴のパターンを含む他のあらゆる物理媒体、ＲＡＭ、ＰＲＯＭ、及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のあらゆるメモリチップ又はカートリッジ、以下で説明するような搬送波、又はコンピュータが読み込むことのできる他のあらゆる媒体が挙げられる。

実行用のプロセッサ４０４に１又はそれ以上の命令の１又はそれ以上のシーケンスを搬送する際に、様々な形の機械可読媒体を関与させることができる。例えば、最初に命令を遠隔コンピュータの磁気ディスクに記憶して搬送することができる。遠隔コンピュータは、命令を自身の動的メモリにロードし、モデムを使用して電話回線を介して命令を送信することができる。コンピュータシステム４００に対してローカルなモデムが、データを電話回線上で受信し、赤外線送信器を使用してこのデータを赤外線信号に変換することができる。赤外線検出器が、赤外線信号の形で搬送されたデータを受信することができ、また適切な回路がこのデータをバス４０２上に配置することができる。バス４０２がデータをメインメモリ３０６に搬送し、ここからプロセッサ３０４が命令を取り出して実行する。プロセッサ４０４による実行の前又は後のいずれかに、メインメモリ４０６により受信された命令を任意に記憶装置４１０に記憶することができる。

コンピュータシステム４００は、バス４０２に結合された通信インターフェイス４１８を含む。通信インターフェイス４１８は、ローカルネットワーク４２２に接続されたネットワークリンク４２０に結合する双方向データ通信を提供する。例えば、通信インターフェイス４１８は、対応する種類の電話回線へのデータ通信接続を提供するための統合デジタル通信サービス網（ＩＳＤＮ）カード又はモデムであってもよい。別の例として、通信インターフェイス４１８は、互換性のあるＬＡＮにデータ通信接続を提供するためのローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクを実現することもできる。あらゆるこのような実施構成において、通信インターフェイス４１８は、様々な種類の情報を表すデジタルデータストリームを搬送する電気、電磁又は光信号を送受信する。

通常、ネットワークリンク４２０は、１又はそれ以上のネットワークを介して他のデータ装置にデータ通信を提供する。例えば、ネットワークリンク４２０は、ローカルネットワーク４２２を介してホストコンピュータ４２４に又はインターネットサービスプロバイダ（ＩＳＰ）４２６により動作されるデータ装置に接続を提供することができる。さらにＩＳＰ４２６は、現在では一般に「インターネット」４２８と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク４２２及びインターネット４２８はともに、デジタルデータストリームを搬送する電気、電磁又は光信号を使用する。コンピュータシステム４００との間でデジタルデータを搬送する、様々なネットワークを介する信号、及び通信インターフェイス４１８を介するネットワークリンク４２０上の信号は、情報を伝送する搬送波の例示的な形である。

コンピュータシステム４００は、（単複の）ネットワーク、ネットワークリンク４２０及び通信インターフェイス４１８を介してメッセージを送信するとともに、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ４３０が、アプリケーションプログラムに求められるコードをインターネット４２８、ＩＳＰ４２６、ローカルネットワーク４２２及び通信インターフェイス４１８を介して送信することができる。

プロセッサ４０４は、受信したコードを受信時に実行することができ、及び／又は後で実行するために記憶装置４１０、又はその他の不揮発性記憶装置に記憶することができる。このようにして、コンピュータシステム４００は、搬送波の形のアプリケーションコードを取得することができる。

上述の明細書では、実施構成に応じて異なり得る数多くの特定の詳細を参照しながら本発明の実施形態について説明した。従って、本発明が何であるか、及び出願人が何を発明として意図しているかを示す唯一かつ排他的なものが、本出願に由来する特許請求の範囲の組であり、このような特許請求の範囲が発行される特定の形には今後のあらゆる補正が含まれる。本明細書に明確に示す、このような特許請求の範囲に含まれる用語のあらゆる定義が、特許請求の範囲で使用するこのような用語の意味を規定するものとする。従って、特許請求の範囲に明確に記載していない限定事項、要素、特性、特徴、利点又は属性により、決してこのような特許請求の範囲を限定すべきではない。従って、明細書及び図面については限定的な意味ではなく例示的な意味でとらえるべきである。

１０１ サンフランシスコのコロケーション
１０３ ニューヨークのコロケーション
１０５ クライアント
１０７ ＡＣＭＥ ＬＤＮＳリゾルバ
１０９ 情報提供ＤＮＳリゾルバ
１１１ 要求
１１５ 要求
１１７ サンフランシスコへの経路
１１９ ニューヨークへの経路

Claims (22)

1. コンピュータにより実行される方法であって、
   複数のクライアントの個々のクライアントに関して、
   （ａ）識別値及び（ｂ）特定のＬＤＮＳサーバを識別するデータを含む第１の接続データを第１のサーバから受信することと、
   （ｃ）前記識別値及び（ｄ）複数のＬＤＮＳサーバのうちの特定のＬＤＮＳサーバの背後に存在する特定のクライアントを識別するデータを含む第２の接続データを第２のサーバから受信することと、
   前記第２の接続データの前記特定のクライアントの識別値を前記第１の接続データの前記特定のＬＤＮＳサーバの識別値とマッチさせることにより、前記特定のクライアントを識別する前記データを、前記特定のＬＤＮＳサーバを識別する前記データにマッピングすることと、
   を実行するステップと、
   前記特定のＬＤＮＳサーバを識別する前記データにマッピングされた前記特定のクライアントを識別する前記データを集約することにより、前記クライアントと、該クライアントを背後に有する前記ＬＤＮＳサーバとの間のマッピングを作成するステップと、
   前記マッピングをコンピュータ可読媒体に記憶するステップと、
   を含むことを特徴とする方法。
2. 前記マッピングをコンピュータ可読媒体に記憶する際に前記マッピングをロードバランシングサーバに出力して、該ロードバランシングサーバが前記複数のＬＤＮＳサーバからの後続のメッセージをどのようにルーティングするかを決定する際に使用するようにするステップをさらに含む、
   ことを特徴とする請求項１に記載の方法。
3. 特定のＬＤＮＳサーバを識別するデータがＩＰアドレスを含む、
   ことを特徴とする請求項１に記載の方法。
4. 特定のクライアントを識別するデータがＩＰアドレスを含む、
   ことを特徴とする請求項１に記載の方法。
5. 第１の接続データが、前記特定のＬＤＮＳサーバから前記第１のサーバへのＤＮＳ要求に基づく、
   ことを特徴とする請求項１に記載の方法。
6. 前記ＤＮＳ要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項５に記載の方法。
7. 第２の接続データが、前記特定のクライアントから前記第２のサーバへのＨＴＴＰ要求に基づく、
   ことを特徴とする請求項１に記載の方法。
8. 前記ＨＴＴＰ要求が、前記クライアントに供給されるウェブビーコンコードから生じる、
   ことを特徴とする請求項７に記載の方法。
9. 後続のメッセージをどのようにルーティングするかを決定するステップが、ＬＤＮＳサーバの背後に存在するクライアントの近接性に基づく、
   ことを特徴とする請求項２に記載の方法。
10. 後続のメッセージをどのようにルーティングするかを決定するステップが、特定のＬＤＮＳサーバの背後に存在するクライアントの数に基づく、
    ことを特徴とする請求項２に記載の方法。
11. 前記ＨＴＴＰ要求が、クライアントが一意のホストネームにおけるゼロコンテンツ画像を取り出すことに基づく、
    ことを特徴とする請求項７に記載の方法。
12. １又はそれ以上の一連の命令を保持するコンピュータ可読媒体であって、前記１又はそれ以上の一連の命令が、１又はそれ以上のプロセッサにより実行された場合、該１又はそれ以上のプロセッサに、
    複数のクライアントの個々のクライアントに関して、
    （ａ）識別値及び（ｂ）特定のＬＤＮＳサーバを識別するデータを含む第１の接続データを第１のサーバから受信することと、
    （ｃ）前記識別値及び（ｄ）複数のＬＤＮＳサーバのうちの特定のＬＤＮＳサーバの背後に存在する特定のクライアントを識別するデータを含む第２の接続データを第２のサーバから受信することと、
    前記第２の接続データの前記特定のクライアントの識別値を前記第１の接続データの前記特定のＬＤＮＳサーバの識別値とマッチさせることにより、前記特定のクライアントを識別する前記データを、前記特定のＬＤＮＳサーバを識別する前記データにマッピングすることと、
    を実行するステップと、
    前記特定のＬＤＮＳサーバを識別する前記データにマッピングされた前記特定のクライアントを識別する前記データを集約することにより、前記クライアントと、該クライアントを背後に有する前記ＬＤＮＳサーバとの間のマッピングを作成するステップと、
    前記マッピングをコンピュータ可読媒体に記憶するステップと、
    を実行させることを特徴とするコンピュータ可読媒体。
13. 前記マッピングをコンピュータ可読媒体に記憶する際に前記マッピングをロードバランシングサーバに出力して、該ロードバランシングサーバが前記複数のＬＤＮＳサーバからの後続のメッセージをどのようにルーティングするかを決定する際に使用するようにするステップをさらに含む、
    ことを特徴とする請求項１２に記載のコンピュータ可読媒体。
14. 特定のＬＤＮＳサーバを識別するデータがＩＰアドレスを含む、
    ことを特徴とする請求項１２に記載のコンピュータ可読媒体。
15. 特定のクライアントを識別するデータがＩＰアドレスを含む、
    ことを特徴とする請求項１２に記載のコンピュータ可読媒体。
16. 第１の接続データが、前記特定のＬＤＮＳサーバから前記第１のサーバへのＤＮＳ要求に基づく、
    ことを特徴とする請求項１２に記載のコンピュータ可読媒体。
17. 前記ＤＮＳ要求が、前記クライアントに供給されるウェブビーコンコードから生じる、ことを特徴とする請求項１６に記載のコンピュータ可読媒体。
18. 第２の接続データが、前記特定のクライアントから前記第２のサーバへのＨＴＴＰ要求に基づく、
    ことを特徴とする請求項１２に記載のコンピュータ可読媒体。
19. 前記ＨＴＴＰ要求が、前記クライアントに供給されるウェブビーコンコードから生じる、
    ことを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 後続のメッセージをどのようにルーティングするかを決定するステップが、ＬＤＮＳサーバの背後に存在するクライアントの近接性に基づく、
    ことを特徴とする請求項１３に記載のコンピュータ可読媒体。
21. 後続のメッセージをどのようにルーティングするかを決定するステップが、特定のＬＤＮＳサーバの背後に存在するクライアントの数に基づく、
    ことを特徴とする請求項１３に記載のコンピュータ可読媒体。
22. 前記ＨＴＴＰ要求が、クライアントが一意のホストネームにおけるゼロコンテンツ画像を取り出すことに基づく、
    ことを特徴とする請求項１８に記載のコンピュータ可読媒体。

Images