特許 6578416 エニーキャストデータトラフィックをロードバランシングするための方法およびシステム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6578416

(24)【登録日】2019年8月30日

(45)【発行日】2019年9月18日

(54)【発明の名称】エニーキャストデータトラフィックをロードバランシングするための方法およびシステム

(51)【国際特許分類】

   H04L 12/803 20130101AFI20190909BHJP

【ＦＩ】

   H04L12/803

【請求項の数】18

【外国語出願】

【全頁数】24

(21)【出願番号】特願2018-111793(P2018-111793)

(22)【出願日】2018年6月12日

(62)【分割の表示】特願2016-565152(P2016-565152)の分割

【原出願日】2015年5月11日

(65)【公開番号】特開2018-164285(P2018-164285A)

(43)【公開日】2018年10月18日

【審査請求日】2018年7月2日

(31)【優先権主張番号】61/992,623

(32)【優先日】2014年5月13日

(33)【優先権主張国】US

(31)【優先権主張番号】14/495,683

(32)【優先日】2014年9月24日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】アイゼンブド，ダニエル・ユージーン

(72)【発明者】

【氏名】ニュートン，サイモン・ジェフリー

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特表２０１２−５２８５５１（ＪＰ，Ａ）

【文献】 特開２００５−０９２８６２（ＪＰ，Ａ）

【文献】 特開２００３−１７４４７３（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１７２１９２（ＵＳ，Ａ１）

【文献】 特表２０１４−５０４４８４（ＪＰ，Ａ）

【文献】 大隅 淑弘 Yoshihiro Ohsumi，地理的に分散したサーバ間のフェイルオーバ・フェイルバックを可能にする複製サーバ冗長化構成，ＦＩＴ２０１３ 第１２回情報科学技術フォーラム 講演論文集 第４分冊 査読付き論文・一般論文 ネットワーク・セキュリティ ユビキタス・モバイルコンピューティング 教育・人文科学 情報システム Forum on Information Technology 2013，２０１３年 ８月２０日，第23-27頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／９５５，２９／００

(57)【特許請求の範囲】

【請求項1】

通信ネットワークにおけるエニーキャストトラフィックをロードバランシングするためのシステムであって、
第１のロードバランシング（ＬＢ）デバイスと、前記第１のＬＢデバイスとは異なる第２のＬＢデバイスとを含む１セットのＬＢデバイスを含み、前記１セットのＬＢデバイスのうちの各々のＬＢデバイスは、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされるアプリケーションインスタンスのグループにおけるアプリケーションインスタンスに関連付けられたエントリを含むデータ構造を維持するように構成され、各々のサーブされたアプリケーションインスタンスが前記データ構造に含まれている頻度は、対応するサーブされたアプリケーションインスタンスの容量に関連付けられた重み値を示しており、前記１セットのＬＢデバイスのうちの各々のＬＢデバイスは、
エニーキャストアドレスにアドレス指定された前記システムにおいて受信されるデータパケットを受信すると、前記受信されたデータパケットのうちの１つ以上のヘッダフィールドに基づいてハッシュ値を生成し、
前記データ構造を用いて、前記生成されたハッシュ値に基づいて前記サーブされたアプリケーションインスタンスのうちの１つのアプリケーションインスタンスの仮想インターネットプロトコル（ＩＰ）アドレスを識別し、
前記識別されたアプリケーションインスタンスに前記データパケットを転送するように構成され、前記システムはさらに、
前記エニーキャストアドレスをブロードキャストする複数のエニーキャストノードを含み、前記複数のエニーキャストノードは、
クライアントデバイスから、前記複数のエニーキャストノードのうちの第１のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定されたセッションの第１のデータパケットを受信すると、前記第１のＬＢデバイスに前記第１のデータパケットを転送し、
前記クライアントデバイスから、前記複数のエニーキャストノードの第２のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定された前記セッションの第２のデータパケットを受信すると、前記クライアントデバイスと前記識別されたアプリケーションインスタンスとの間における既存の接続を維持するために前記第１のＬＢデバイスに前記第２のデータパケットを転送し、
第１のクライアントデバイスとは異なる第２のクライアントデバイスから、前記第１のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定された第３のデータパケットを受信すると、前記第２のＬＢデバイスに前記第３のデータパケットを転送するように構成されている、システム。

【請求項2】

前記１セットのＬＢデバイスのうちの対応するＬＢデバイスに関連付けられた前記重み値は、前記１セットのＬＢデバイスうちの前記対応するＬＢデバイスによってサーブされる処理装置のグループの容量を示している、請求項１に記載のシステム。

【請求項3】

前記アプリケーションインスタンスは、アプリケーションサーバ、コンテンツサーバおよび仮想マシンのうち少なくとも１つに関連付けられている、請求項１に記載のシステム。

【請求項4】

前記１セットのＬＢデバイスのうちの各々のＬＢデバイスはさらに、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされたアプリケーションインスタンスの前記グループにおける各々のアプリケーションインスタンスについての重み値を受信し、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされた前記グループにおけるアプリケーションインスタンスについての前記受信された重み値に基づいて前記データ構造を生成するように構成される、請求項１に記載のシステム。

【請求項5】

前記データ構造を生成する際に、前記１セットのＬＢデバイスのうちの各々のＬＢデバイスはさらに、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされた前記グループのうちの各々のアプリケーションインスタンスについての空データ構造位置の数を選択するように構成され、選択された空データ構造位置の前記数は、前記アプリケーションインスタンスに対応する前記重み値に基づいて決定され、前記１セットのＬＢデバイスのうちの各々のＬＢデバイスはさらに、
前記選択された空データ構造位置の各々において前記アプリケーションインスタンスの仮想ＩＰアドレスを挿入するように構成される、請求項４に記載のシステム。

【請求項6】

前記１セットのＬＢデバイスのうちの各々のＬＢデバイスはさらに、前記アプリケーションインスタンスに関連付けられたオフセット値に基づいて、前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされた前記グループのうちの各々のアプリケーションインスタンスについての空データ構造位置の前記数を選択するように構成される、請求項５に記載のシステム。

【請求項7】

各々のエニーキャストノードは、
接続テーブルを維持し、
第４のデータパケットを受信すると、前記第４のデータパケットが既存のデータフローに対応していると判断し、
前記第４のデータパケットを前記既存のデータフローに関連付けられた宛先に転送するように構成される、請求項１に記載のシステム。

【請求項8】

前記１セットのＬＢデバイスのうちの各々のＬＢデバイスは、
接続テーブルを維持し、
第４のデータパケットを受信すると、前記第４のデータパケットが既存のデータフローに対応していると判断し、
前記第４のデータパケットを前記既存のデータフローに関連付けられた宛先に転送するように構成される、請求項１に記載のシステム。

【請求項9】

データトラフィックロードバランシングのための方法であって、
第１のロードバランシング（ＬＢ）デバイスと、前記第１のＬＢデバイスとは異なる第２のＬＢデバイスとを含む１セットのＬＢデバイスのうちの各々のＬＢデバイスによって、データ構造を維持するステップを含み、前記データ構造は、前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされたアプリケーションインスタンスのグループにおけるアプリケーションインスタンスに関連付けられたエントリを含み、各々のサーブされたアプリケーションインスタンスが前記データ構造に含まれている頻度は、対応するサーブされたアプリケーションインスタンスの容量に関連付けられた重み値を示しており、前記方法はさらに、
エニーキャストアドレスにアドレス指定されたＬＢシステムにおいて受信されるデータパケットを受信すると、前記受信されたデータパケットのうちの１つ以上のヘッダフィールドに基づいてハッシュ値を生成するステップと、
前記データ構造を用いて、前記生成されたハッシュ値に基づいて前記サーブされたアプリケーションインスタンスのうちの１つのアプリケーションインスタンスの仮想インターネットプロトコル（ＩＰ）アドレスを識別するステップと、
前記識別されたアプリケーションインスタンスに前記データパケットを転送するステップと、
複数のエニーキャストノードによって前記エニーキャストアドレスをブロードキャストするステップと、
クライアントデバイスから、前記複数のエニーキャストノードのうち第１のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定されたセッションの第１のデータパケットを受信すると、前記第１のＬＢデバイスに前記データパケットを転送するステップと、
前記クライアントデバイスから、前記複数のエニーキャストノードのうち第２のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定された前記セッションの第２のデータパケットを受信すると、前記クライアントデバイスと前記識別されたアプリケーションインスタンスとの間における既存の接続を維持するために前記第１のＬＢデバイスに前記第２のデータパケットを転送するステップと、
第１のクライアントデバイスとは異なる第２のクライアントデバイスから、前記第１のエニーキャストノードで、前記エニーキャストアドレスにアドレス指定された第３のデータパケットを受信すると、前記第２のＬＢデバイスに前記第３のデータパケットを転送するステップとを含む、方法。

【請求項10】

前記１セットのＬＢデバイスのうちの対応するＬＢデバイスに関連付けられた前記重み値は、前記１セットのＬＢデバイスうちの前記対応するＬＢデバイスによってサーブされるアプリケーションインスタンスのグループの容量を示している、請求９に記載の方法。

【請求項11】

前記アプリケーションインスタンスは、アプリケーションサーバ、コンテンツサーバおよび仮想マシンのうち少なくとも１つに関連付けられている、請求項９に記載の方法。

【請求項12】

前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによって、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされたアプリケーションインスタンスの前記グループにおける各々のアプリケーションインスタンスについての重み値を受信するステップと、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされた前記グループにおけるアプリケーションインスタンスについての前記受信された重み値に基づいて前記データ構造を生成するステップとをさらに含む、請求項９に記載の方法。

【請求項13】

前記データ構造を生成するステップは、
前記１セットのＬＢデバイスのうちの前記ＬＢデバイスによってサーブされた前記グループのうちの各々のアプリケーションインスタンスについての空データ構造位置の数を選択するステップを含み、選択された空データ構造位置の前記数は、前記アプリケーションインスタンスに対応する前記重み値に基づいて決定され、前記データ構造を生成するステップはさらに、
前記選択された空データ構造位置の各々において前記アプリケーションインスタンスの仮想ＩＰアドレスを挿入するステップを含む、請求項１２に記載の方法。

【請求項14】

各々のアプリケーションインスタンスについての空データ構造位置の数を選択するステップは、前記アプリケーションインスタンスに関連付けられたオフセット値に基づいて空データ構造位置の前記数を選択するステップを含む、請求項１３に記載の方法。

【請求項15】

前記複数のエニーキャストノードのうちの各々のエニーキャストノードによって、接続テーブルを維持するステップと、
各々のエニーキャストノードによって、第３のデータパケットを受信すると、前記第３のデータパケットが既存のデータフローに対応していると判断するステップと、
各々のエニーキャストノードによって、前記第３のデータパケットを前記既存のデータフローに関連付けられた宛先に転送するステップとを含む、請求項９に記載の方法。

【請求項16】

前記１セットのＬＢデバイスのうちの各々のＬＢデバイスによって、接続テーブルを維持するステップと、
各々のＬＢデバイスによって、第３のデータパケットを受信すると、前記第３のデータパケットが既存のデータフローに対応していると判断するステップと、
各々のＬＢデバイスによって、前記第３のデータパケットを前記既存のデータフローに関連付けられた宛先に転送するステップとを含む、請求項９に記載の方法。

【請求項17】

各々のエニーキャストノードは、
各々のデータパケットを受信すると、前記受信されたデータパケットのうちの第２の１つ以上のヘッダフィールドに基づいて第２のハッシュ値を生成し、
前記１セットのＬＢデバイスにおけるＬＢデバイスの数を法として、前記生成された第２のハッシュ値に基づいて、前記受信されたデータパケットを宛先のＬＢデバイスに転送するように構成される、請求項１に記載のシステム。

【請求項18】

各々のエニーキャストノードにおいて各々のデータパケットを受信すると、前記エニーキャストノードによって、前記受信されたデータパケットのうちの第２の１つ以上のヘッダフィールドに基づいて第２のハッシュ値を生成するステップと、
前記エニーキャストノードによって、前記１セットのＬＢデバイスにおけるＬＢデバイスの数を法として、前記生成された第２のハッシュ値に基づいて、前記受信されたデータパケットを宛先のＬＢデバイスに転送するステップとを含む、請求項９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連特許出願の相互参照
本願は、２０１４年５月１３日に出願され「エニーキャストデータトラフィックをロードバランシングするための方法およびシステム（METHOD AND SYSTEM FOR LOAD BALANCING
ANYCAST DATA TRAFFIC）」と題された米国仮特許出願第６１／９９２，６２３号の利益
および優先権を主張する、２０１４年９月２４日に出願され「エニーキャストデータトラフィックをロードバランシングするための方法およびシステム（METHOD AND SYSTEM FOR LOAD BALANCING ANYCAST DATA TRAFFIC）」と題された米国特許出願第１４／４９５，６
８３号の利益および優先権を主張するものであって、それらの開示全体が引用によりこの明細書中に援用されている。

【0002】

開示の分野
本開示は、概して、データトラフィックロードバランシングの分野に関する。

【背景技術】

【0003】

背景
世界中のインターネットアクセス可能なコンテンツの多くは、大規模なデータセンタにおいてホストされているサーバによって提供される。このようなデータセンタは、典型的には、複数の地理的位置にわたって分散されており、エンドユーザのためにグローバルに機能している。典型的なデータセンタは、エンドユーザに提供されるさまざまなサービスに関連付けられたソフトウェアアプリケーションの複数のインスタンスをホストする何千ものサーバを収容している。エンドユーザが、たとえばウェブサイト、ソーシャルメディアサービス、ストリーミングメディアコンテンツアイテム、ゲーミングサービスまたは他の何らかのオンラインサービスに関連付けられたインターネットコンテンツについての要求を行う場合、当該要求は、エンドユーザの要求に応えるためにデータセンタによってホストされているサービスに関連付けられたアプリケーションインスタンスに送信される。

【発明の概要】

【課題を解決するための手段】

【0004】

概要
本開示の一局面に従うと、エニーキャストアドレスにアドレス指定されたデータトラフィックをロードバランシングするための方法であって、第１のセットのロードバランシング（load balancing：ＬＢ）デバイスのうちの各々のＬＢデバイスによって第１のデータ構造を維持するステップを含む。第１のデータ構造は、第１のセットのＬＢデバイスのうちのＬＢデバイスによってサーブされるアプリケーションインスタンスのグループにおけるアプリケーションインスタンスに関連付けられたエントリを含む。各々のサーブされたアプリケーションインスタンスが第１のデータ構造に含まれている頻度は、対応するサーブされたアプリケーションインスタンスの容量に関連付けられた重み値を示している。第１のセットのＬＢデバイスにおける或るＬＢデバイスが、もともとエニーキャストアドレスにアドレス指定されていたデータパケットを受信すると、当該ＬＢデバイスは、受信されたデータパケットのうちの第１のセットのヘッダフィールドに基づいて第１のハッシュ値を生成する。第１のセットのうちのＬＢは、次いで、第１のデータ構造を用いて、生成された第１のハッシュ値に基づいて、サーブされたアプリケーションインスタンスのうちの１つのアプリケーションインスタンスの仮想インターネットプロトコル（Internet protocol：ＩＰ）アドレスを識別し、識別されたアプリケーションインスタンスにデータパ
ケットを転送する。当該方法はまた、第２のセットのＬＢデバイスのうちの或るＬＢデバ
イスによって、第１のセットにおけるそれぞれのＬＢデバイスに関連付けられたエントリを含む第２のデータ構造を維持するステップを含む。第１のセットのＬＢデバイスにおける各々のＬＢデバイスが第２のデータ構造に含まれている頻度は、第１のセットの対応するＬＢデバイスに関連付けられた重み値を示している。第２のセットのＬＢデバイスのうちの或るＬＢデバイスが、もともとエニーキャストアドレスにアドレス指定されていたデータパケットを受信すると、当該ＬＢは、受信されたデータパケットのうちの第２のセットのヘッダフィールドに基づいて第２のハッシュ値を生成し、生成された第２のハッシュ値に基づいて、第２のデータ構造を用いて、第１のセットのうちの或るＬＢデバイスを識別する。第２のセットのうちのＬＢは、次いで、データパケットを第１のセットのＬＢデバイスのうちの識別されたＬＢデバイスに転送する。

【0005】

本開示の別の局面に従うと、通信ネットワークにおけるエニーキャストトラフィックをロードバランシングするためのシステムは、第１のセットのロードバランシング（ＬＢ）デバイスを含む。第１のセットのＬＢデバイスのうちの各々のＬＢデバイスは、第１のデータ構造を維持するように構成される。第１のデータ構造は、第１のセットのＬＢデバイスのうちのＬＢデバイスによってサーブされたアプリケーションインスタンスのグループにおけるアプリケーションインスタンスに関連付けられたエントリを含む。各々のサーブされたアプリケーションインスタンスが第１のデータ構造に含まれている頻度は、対応するサーブされたアプリケーションインスタンスに関連付けられた重み値を示している。第１のセットのＬＢデバイスのうちの或るＬＢデバイスが、エニーキャストアドレスにアドレス指定されたシステムにおいて受信されたデータパケットを受信すると、当該ＬＢデバイスは、受信されたデータパケットのうちの１つ以上の第１のヘッダフィールドに基づいて第１のハッシュ値を生成し、第１のデータ構造を用いて、生成された第１のハッシュ値に基づいて、サーブされたアプリケーションインスタンスのうちの１つのアプリケーションインスタンスの仮想インターネットプロトコル（ＩＰ）アドレスを識別する。第１のセットのうちのＬＢデバイスは、次いで、識別されたアプリケーションインスタンスにデータパケットを転送する。システムはまた、第２のセットのロードバランシング（ＬＢ）デバイスを含む。第２のセットのＬＢデバイスのうちの各々のＬＢデバイスは、第１のセットにおけるそれぞれのＬＢデバイスに関連付けられたエントリを含む第２のデータ構造を維持するように構成される。第１のセットのＬＢデバイスにおける各々のＬＢデバイスが第２のデータ構造に含まれている頻度は、第１のセットのうちの対応するＬＢデバイスに関連付けられた重み値を示している。エニーキャストアドレスにアドレス指定されたシステムにおいて受信されたデータパケットを第２のセットのＬＢデバイスにおける或るＬＢデバイスが受信すると、当該ＬＢデバイスは、受信されたデータパケットのうちの１つ以上の第２のヘッダフィールドに基づいて第２のハッシュ値を生成し、生成された第２のハッシュ値に基づいて、第２のデータ構造を用いて、第１のセットのＬＢデバイスのうちの或るＬＢデバイスを識別する。第２のセットのうちの当該ＬＢデバイスは次いで、第１のセットのうちの識別されたＬＢデバイスにデータパケットを転送する。システムはさらに、エニーキャストアドレスに関連付けられたエニーキャストノードを含む。当該エニーキャストノードは、エニーキャストアドレスにアドレス指定されたデータパケットを受信すると、受信したデータパケットを第２のセットのＬＢデバイスにおける或るＬＢデバイスに転送するように構成されている。

【0006】

図面の簡単な説明
本開示の上述および関連の目的、特徴および利点は、添付の図面に関連付けて読まれると、以下の詳細な説明を参照することによって、より十分に理解されるだろう。

【図面の簡単な説明】

【0007】

【図1】エニーキャストアドレスにアドレス指定されたデータトラフィックをロードバランシングするための単層型ロードバランシングシステムの実現例を示すブロック図である。

【図2】単層型ロードバランシングシステムによって実行されるエニーキャストデータパケットを処理するプロセスの実現例を説明するフローチャートである。

【図3】エニーキャストアドレスにアドレス指定されたデータトラフィックをロードバランシングするための２層型ロードバランシングシステムの実現例を示すブロック図である。

【図4】２層型ロードバランシングシステムの別の実現例を示すブロック図である。

【図5】２層型ロードバランシングシステムによって実行されるエニーキャストデータパケットを処理するプロセスの実現例を説明するフローチャートである。

【図6】ロードバランサに採用されているデータ構造を生成するためのプロセスの実現例を説明するフローチャートである。

【図7】図１および図３におけるシステムに採用されているデータ構造を示す図である。

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

【0008】

さまざまな図における同様の参照番号および符号は同様の要素を示している。
詳細な説明
オンラインサービスまたはアプリケーションは、通常、各々のアプリケーションまたはサービスのための複数のアプリケーションインスタンスを含む。各々のアプリケーションまたはサービスのための複数のアプリケーションインスタンスは複数のコンピュータサーバ上に常駐していてもよい。そのため、複数のエンドユーザによるアプリケーションまたはサービスへのアクセスに関連付けられた負荷は、少なくとも、対応する複数のアプリケーションインスタンスのサブセットにわたって分散されていてもよい。また、さまざまな地理的位置にわたって所与のアプリケーションまたはサービスのための複数のアプリケーションインスタンスを分散させることにより、エンドユーザが被るレイテンシを低減させることが容易になる。特に、エンドユーザは、対応する複数のアプリケーションインスタンスのうち１つ以上のアプリケーションインスタンスを有する最も近い地理的位置でサーブされている可能性がある。各々のエンドユーザまたはクライアントが対応する最も近い地理的位置でサーブされていることでレイテンシを低減させる一方で、各々の地理的位置におけるコンピュータサーバとそこにあるアプリケーションインスタンスとが有する容量が有限となる。特定の位置における所与のアプリケーションまたはサービスに対する要求が同じ位置におけるアプリケーションインスタンスの容量を上回っている場合、アプリケーションに対する過剰な要求が次に最も近い位置にまでオーバーフローする可能性がある。

【0009】

コンピュータサーバおよびその上で実行されるアプリケーションインスタンスが有する有限の容量に対処するために、従来より、既存のデータセンタにおいてドメインネームシステム（domain name system：ＤＮＳ）サーバを用いてロードバランシング機能を実行してきた。以下において、エニーキャストデータトラフィックをロードバランシングするためのプロセス、装置およびシステムの実現例が提供される。

【0010】

エニーキャストベースのサービスまたはアプリケーションにおいては、１つ以上のインターネットプロトコル（ＩＰ）アドレスが、エニーキャストを用いてグローバルに複数のサーバからアドバタイズされている。さらに、同じアプリケーションまたはサービスにアクセスする場合、所与のアプリケーションまたはサービスについてのエニーキャストＩＰアドレスがエンドユーザによって用いられる。次いで、エニーキャストアドレスに関連付けられたデータトラフィック、たとえばアプリケーションまたはサービスにアクセスするためのエンドユーザからの要求は、以下に記載される実現例において説明されるように、さまざまな対応するアプリケーションインスタンスにわたってロードバランシングされている。エニーキャストアドレスに関連付けられたデータトラフィックはまた、この明細書
中において、エニーキャストトラフィックまたはエニーキャストデータトラフィックとも称される。ある実現例においては、ステートフルプロトコルに関連付けられたエニーキャストトラフィック、たとえばトランスポートコントロールプロトコル（transport control protocol：ＴＣＰ）がロードバランシングおよびサーブされている一方で、対応する接続はインターネットルーティングテーブルが変化したときでも維持されている。さらに、以下に記載される実現例は、さまざまな位置についての容量または他のロードバランシングメトリクスを特定することを可能にし、かつ、負荷、容量または他のいずれかのロードバランシングメトリクスの変化に対する迅速なロードバランシング応答を可能にする。

【0011】

図１は、エニーキャストアドレスにアドレス指定されたデータトラフィックをロードバランシングするための単層型ロードバランシングシステム１００の実現例のブロック図を示す。システム１００は、複数のエニーキャストリダイレクタノード１１０ａ〜１１０ｃ（以下、個々にまたは総称してエニーキャストノード１１０とも称する）；ロードバランサデバイス１２０ａ〜１２０ｂ（以下、個々にまたは総称してロードバランサ１２０とも称する）；および複数のサーバクラスタ１３０ａ〜１３０ｃ（以下、個々にまたは総称してクラスタ１３０とも称する）を含む。クラスタ１３０の各々はいくつかのアプリケーションインスタンス１３１を含む。

【0012】

エニーキャストアドレスにアドレス指定されたデータパケット１０は、エニーキャストノード１１０によってシステム１００において受信される。たとえば、データパケット１０はエニーキャストノード１１０によって受信される。エニーキャストノード１１０は、エニーキャストアドレスにアドレス指定されたデータパケット１０を受信し、受信されたデータパケットを対応するロードバランサ１２０にリダイレクトするように構成されたデバイスである。場合によっては、エニーキャストノード１１０は、受信されたデータパケット１０を対応するロードバランサ１２０にリダイレクトする。他の場合には、受信側エニーキャストノード１１０は、受信されたデータパケット１０を、システム１００のうち１つ以上のそれぞれのクラスタ１３０にサーブするロードバランサ１２０のプールにリダイレクトする。

【0013】

いくつかの実現例においては、各々のエニーキャストノード１１０は、ソースインターネットプロトコル（ＩＰ）アドレスを、対応するクラスタ１３０またはこのようなクラスタに関連付けられたロードバランサ１２０に対してマッピングするそれぞれのマップを維持するかまたは当該それぞれのマップにアクセスできる。当該マップはソースＩＰマップとも称される。場合によっては、各々のソースＩＰアドレスは、同じソースＩＰアドレスに関連付けられたデータパケットソースに最も近いクラスタ１３０または対応するロードバランサ１２０にマッピングされる。当業者であれば、ソースＩＰアドレスとクラスタ１３０またはロードバランサ１２０との間のマッピングが、たとえばシステム１００のアドミニストレータによってなされる割当てに基づいて、さまざまに規定され得ることを認識するはずである。エニーキャストアドレスにアドレス指定されたデータパケット１０を受信すると、エニーキャストノード１１０は、ソースＩＰマップにおけるパケットのソースインターネットプロトコル（ＩＰ）アドレスを調べ、データパケット１０を、マップされた位置（すなわちソースＩＰマップにおけるソースＩＰアドレスに関連付けられた位置）にリダイレクトする。マップされた位置は、システム１００のロードバランサ１２０またはロードバランサ１２０のプールを示している。

【0014】

いくつかの実現例においては、エニーキャストノード１１０は、受信されたデータパケット１０のうちのいくつかのヘッダフィールドを用いて、受信されたデータパケット１０がリダイレクトされるべきロードバランサ１２０またはロードバランサ１２０のプールを決定する。たとえば、受信側エニーキャストノード１１０は、受信されたデータパケット１０に関連付けられたソースポートおよび（仮想ＩＰ（virtual IP：ＶＩＰ）アドレスな
どの）宛先ＩＰアドレスを用いて、複数のエニーキャストサービスグループのうちの或るエニーキャストサービスグループを決定する。いくつかの実現例においては、受信側エニーキャストノード１１０は、宛先アドレス、宛先ポート、ソースＩＰアドレス、ソースポート、プロトコルまたはそれらのいずれかの組合せを用いて、エニーキャストサービスグループを決定することができる。受信側エニーキャストノード１１０はまた、接続識別子（identifier：ＩＤ）などのデータパケットペイロードに含まれる他の情報を用いてもよい。たとえば、２つのエニーキャストサービスグループが規定されてもよく、そのうち一方のエニーキャストサービスグループはバックエンドロードバランシングのためにエンドポイントサーバを用い、他方のエニーキャストサービスグループは、バックエンドロードバランシングのためにロードバランシングサーバを用いる。エンドポイントサーバは、トランスポートコントロールプロトコル（ＴＣＰ）接続を終了するように構成される。他の例においては、さまざまなエニーキャストサービスグループが規定されてもよい。対応するエニーキャストサービスグループに対してパケットの宛先ＩＰアドレスおよびソースポートをマッピングする際に、受信側エニーキャストノード１１０は、たとえば、このようなマッピングを示す第２のマップまたは構成情報を活用する。受信側エニーキャストノード１１０はさらに、受信されたデータパケット１０のソースＩＰアドレスと受信側エニーキャストノード１１０に関連付けられたソースＩＰマップとを用いて、システム１００のゾーン、たとえば１つ以上のクラスタ１３０を決定する。いくつかの実現例においては、単一のソースＩＰマップがすべてのエニーキャストノード１１０によって共有されている。他の実現例においては、さまざまなエニーキャストノード１１０が別個のソースＩＰマップに関連付けられてもよい。いくつかの実現例においては、各々のソースＩＰマップはそれぞれのサービスに関連付けられている。受信側エニーキャストノード１１０は、次いで、たとえば第３のマップに基づいて、決定されたゾーンおよび決定されたエニーキャストサービスグループをロードバランサ１２０またはロードバランサ１２０のプールにマッピングする。受信側エニーキャストノードは、次いで、受信されたデータパケット１０を、決定されたロードバランサ１２０またはロードバランサ１２０のうち決定されたプールにリダイレクトする。

【0015】

当業者であれば、グローバルマッピング（たとえばソースＩＰマップ）を用いることによってエニーキャストノード１１０によるデータパケット１０のリダイレクトを一致させることを、認識するはずである。言いかえれば、データパケットがエニーキャスト１１０ｂではなくエニーキャストノード１１０ｃにおいて受信される場合、エニーキャストノード１１０ｃは、ソースＩＰマップを用いて、エニーキャストノード１１０ｂによって選択されたであろう同じロードバランサにデータパケット１０をリダイレクトすることとなる。

【0016】

受信側エニーキャストノード１１０はさらに、受信されたデータパケット１０が、受信側エニーキャストノード１１０によって最近サーブされたデータフローまたはセッションに対応しているかどうかを判断するために接続テーブルをチェックするように構成され得る。受信されたデータパケットが接続テーブルにおいて示されるデータフローまたはセッションに対応している場合、受信側エニーキャストノード１１０は、受信されたデータパケット１０を、対応するデータフローまたはセッションに関連付けられた宛先に転送する。そうでない場合、受信側エニーキャストノード１１０は、上述のとおりロードバランサ１２０またはロードバランサ１２０のプールを決定し、受信されたデータパケット１０を、決定されたロードバランサ１２０またはロードバランサ１２０のうちの決定されたプールにリダイレクトする。

【0017】

いくつかの実現例においては、各々のロードバランサ１２０はプロセッサおよびメモリを含むコンピューティングデバイスである。メモリは、データパケット１０がもともとアドレス指定されているエニーキャストアドレスに関連付けられたデータ構造１２１および
コンピュータコード命令を格納している。コンピュータコード命令は、エニーキャストアドレスに関連付けられたデータパケットをロードバランシングするためのソフトウェアロードバランサを含む。いくつかの実現例においては、ソフトウェアロードバランサは仮想マシンである。ロードバランサ１２０は、同じエニーキャストアドレスに関連付けられた複数のソフトウェアロードバランサおよび／または複数のエニーキャストアドレスに関連付けられた複数のソフトウェアロードバランサを含み得る。データ構造１２１は、エニーキャストアドレスに関連付けられたデータパケットを、クラスタ１３０に常駐している対応するアプリケーションインスタンス１３１にマッピングするためにロードバランサ１２０によって用いられる。場合によっては、各々のロードバランサ１２０は、同じロードバランサ１２０によってサーブされた各々のエニーキャストアドレスのための別個のデータ構造を含む。プロセッサは、メモリに格納されたコンピュータコード命令を実行するように構成される。当業者であれば、各々のロードバランサ１２０が複数のプロセッサおよび／または複数のメモリを含み得ることを認識するはずである。ロードバランサ１２０は、コンピュータサーバ、ＴＣＰ接続を終了させるエンドポイントサーバ、この明細書中に記載されるようにロードバランシングを実行するように構成された他の電子デバイス、またはそれらの組合せを含む。

【0018】

場合によっては、ロードバランサ１２０はシステム１００のさまざまな地理的区域にわたって分散されている。たとえば、ロードバランサ１２０ａ、１２０ｂおよび１２０ｃは、それぞれ、対応するクラスタ１３０ａ、１３０ｂおよび１３０ｃにサーブする。他の場合には、ロードバランサ１２０は２つ以上のクラスタ１３０にサーブしてもよい。ロードバランサ１２０はシステム１００のゾーンにサーブしてもよい。ゾーンは、この明細書中においては、システム１００のうち、たとえば対応する地理的位置または他の基準に基づいて関連付けられる１つ以上のクラスタ１３０を指している。たとえば、ゾーンは、同じデータセンタ内などにおいて互いに地理的に近接して位置する複数のクラスタ１３０を含み得る。他の場合においては、ゾーンは、比較的高速の通信リンクによって相互接続されている、互いにより遠くに離れたクラスタ１３０を含み得る。ゾーンは、ロードバランサのプールによってサーブされてもよい。

【0019】

受信されたデータパケット１０がエニーキャストノード１１０によってロードバランサ１２０のプールにリダイレクトされる場合、イコール・コスト・マルチ・パス（equal-cost multi-path：ＥＣＭＰ）ルーティングを採用して、受信されたデータパケットをロー
ドバランサ１２０のプールのうち特定のロードバランサ１２０に転送してもよい。たとえば、データパケット１０を受信するデバイスは、データパケット１０のヘッダフィールド（たとえば、プロトコル、ソースＩＰアドレス、宛先ＩＰアドレス、ソースポートおよび宛先ポートを含むパケットの５タプル）に基づいて整数ハッシュ値を生成する。受信側デバイスは、次いで、ロードバランサ１２０の識別を含むテーブルのサイズを法として、生成されたハッシュ値に基づいて、宛先ロードバランサ１２０を決定する。いくつかの実現例においては、受信側デバイスは、以下にさらに記載されるように、ロードバランサ１２０によって用いられるのと同じかまたは実質的に同様のアルゴリズムを用いて、宛先ロードバランサ１２０を決定する。受信側デバイスは、次いで、宛先ロードバランサ１２０を指し示すようにパケットのレイヤ２イーサネット（登録商標）ヘッダを書換えるか、または、ＧＲＥ（generic routing encapsulation）ヘッダおよびアウターＩＰヘッダでデー
タパケット１０をカプセル化することによって、データパケット１０を宛先ロードバランサ１２０に送達する。受信されたデータパケット１０を複数のソフトウェアロードバランサのうちの１つに転送するために、パケットの宛先ＩＰアドレスにサーブする複数のソフトウェアロードバランサを含むロードバランサ１２０によって同じアプローチが用いられてもよい。

【0020】

データパケット１０を受信すると、受信側ロードバランサ１２０またはその上にあるソ
フトウェアロードバランサが、データパケット１０のうちの１つ以上のヘッダフィールド（たとえば、プロトコル、ソースＩＰアドレス、宛先ＩＰアドレス、ソースポートおよび宛先ポートを含むパケットの５タプル）に基づいてハッシュ値を生成する。いくつかの実現例においては、データ構造１２１は、受信側ロードバランサ１２０によってサーブされるアプリケーションインスタンス１３１のグループに関連付けられたエントリを含む。アプリケーションインスタンス１３１のグループは、システム１００に到達したときにデータパケット１０がアドレス指定されていたエニーキャストアドレスに関連付けられたアプリケーションまたはサービスに対応している。受信側ロードバランサ１２０は、次いで、生成されたハッシュ値およびデータ構造１２１を用いて、受信側ロードバランサ１２０によってサーブされるアプリケーションインスタンスのグループのうちの或るアプリケーションインスタンス１３１の宛先ＩＰアドレスを決定する。受信側ロードバランサ１２０は、さらに、決定されたアプリケーションインスタンス１３１にデータパケット１０を転送する。

【0021】

いくつかの実現例においては、データ構造１２１は、各々のアプリケーションインスタンス１３１がデータ構造１２１に含まれている頻度が、同じアプリケーションインスタンス１３１に関連付けられた重みを反映するように設計されている。アプリケーションインスタンス１３１に関連付けられた重みは、どのアプリケーションインスタンス１３１にデータパケットが転送されるべきかを決定するのに関連する容量、処理時間または他の基準などのロードバランシングメトリックを示している。すなわち、各々のアプリケーションインスタンス１３１に関連付けられた重みは、アプリケーションインスタンス１３１がどれほどビジーであるかまたはどれほどフリーであるかを反映していてもよい。代替的には、所与のアプリケーションインスタンス１３１に関連付けられた重みは、同じアプリケーションインスタンス１３１が用いられている場合に、データパケット１０をどれほど高速で、またはどれほど低速で処理するかを反映していてもよい。各々のアプリケーションの容量は、１秒当たりのパケット、接続、または、１秒当たりの同期（synchronize：ＳＹ
Ｎ）パケット、帯域幅などの点で規定されてもよい。処理時間は、ラウンドトリップタイム（round trip time：ＲＴＴ）または当該技術において公知の他のメトリクスの点から
規定されてもよい。データ構造１２１においては、アプリケーションインスタンス１３１が含まれる頻度が高ければ高いほど、データパケット１０に関連付けられた要求を処理するために同じアプリケーションインスタンス１３１が選択される可能性がより高くなるはずである。

【0022】

受信側ロードバランサ１２０は、生成されたハッシュ値を用いて、データ構造１２１のエントリを選択する。たとえば、受信側ロードバランサ１２０は、データ構造のサイズまたはデータ構造の要素部分のサイズを法として、生成されたハッシュ値に等しいインデックスを含むデータ構造エントリを選択してもよい。データ構造１２１の各々のエントリは対応するアプリケーションインスタンス１３１を示している。たとえば、データ構造１２１の各々のエントリは、対応するアプリケーションインスタンス１３１の宛先ＩＰアドレスを含む。受信側ロードバランサ１２０は、次いで、データパケット１０を、選択されたデータ構造エントリから得られた宛先ＩＰアドレスを有するアプリケーションインスタンス１３１に転送する。

【0023】

いくつかの実現例においては、データ構造１２１は、システム１００の対応する位置（たとえばクラスタ１３０またはゾーン）に関連付けられたアプリケーションインスタンスについてのエントリを含む各々の行または代替的には各々の列を備えた単一のテーブルである。そのため、受信側ロードバランサ１２０は、初めに、行または代替的には列を選択し、次いで、生成されたハッシュ値に基づいて、選択された行または代替的には選択された列内におけるエントリを選択してもよい。いくつかの実現例においては、データ構造１２１は複数のテーブルを含む。各々のテーブルは、システム１００の位置（たとえばゾー
ンまたはクラスタ１３０）に対応している。このような場合、受信側ロードバランサ１２０は初めにテーブルを選択し、次いで、生成されたハッシュ値に基づいて、この選択されたテーブル内のエントリを選択する。

【0024】

受信側ロードバランサ１２０は、さまざまな方法で、システム１００の位置に対応するテーブルまたは行もしくは列などのサブテーブルを選択してもよい。たとえば、この選択は、システム１００の対応する位置にＩＰサブネットを関連付けるマップに基づいていてもよい。このようなマップは、各々のＩＰサブネットからのトラフィックが、通常、システム１００のどの位置に到達するのかを観察することによって規定されてもよい。代替的には、マップは、システム１００のアドミニストレータによってなされる割当てに基づいて、または、システム１００の位置１３０とＩＰサブネットとの間の距離およびＲＴＴに基づいて、規定されてもよい。受信側ロードバランサ１２０は、マップにおける受信されたデータパケット１０に関連付けられたソースＩＰアドレスを調べて、位置または位置の重み付けリストを元に戻す。位置の重み付けリストがマップから検索される場合、受信側ロードバランサは、データパケット１０のうちの１つ以上のヘッダフィールド（たとえば５タプル）を用いて生成された別のハッシュ値および対応する重みに基づいたリストから位置を選択してもよい。しかしながら、重み付けリストが用いられない場合、受信側ロードバランサ１２０は、マップにおいて示されている最も近接している位置がデータパケット１０を処理するために十分な利用可能容量を有しているかどうかをチェックする。十分な利用可能容量を有している場合、最も近接している位置が選択される。十分な利用可能容量を有していない場合、マップに示されている次に最も近接する位置がチェックされる等である。各々の位置が対応するテーブルまたはサブテーブルに関連付けられていると想定すると、受信側ロードバランサ１２０は、マップから位置を選択する際に、データパケット１０のための宛先アプリケーションインスタンス１３１を決定するのに使用されるテーブルまたはサブテーブルを選択する。当業者であれば、データ構造１２１が、代替的には、１つ以上のテーブルではなく１つ以上のツリーまたは当該技術において公知である他の如何なるデータ構造をも含み得ることを認識するはずである。

【0025】

受信側ロードバランサ１２０はまた、アプリケーションインスタンス１３１を選択する前に接続テーブルをチェックして、受信されたデータパケット１０が既存の接続に関連付けられたフローまたはセッションに対応しているかどうかを判断してもよい。受信されたデータパケット１０が既存の接続に関連付けられていることが判明すれば、データパケット１０は、接続テーブルにおける接続に関連付けられたアプリケーションインスタンスに転送される。そうでない場合、受信側ロードバランサ１２０は、データ構造１２１からアプリケーションインスタンス１３１を決定し、データパケット１０を決定されたアプリケーションインスタンス１３１に転送する。また、データパケット１０を受信すると、ロードバランサ１２０はさらに、データパケット１０を、これが予め１回以上カプセル化されていた場合には、デカプセル化してもよい。そのため、受信側ロードバランサ１２０は、内部パケットが到達するまで、データパケット１０をデカプセル化し、次いで、アプリケーションインスタンス１３１を決定する際に使用されるいずれのヘッダフィールドをも検索して、データパケット１０を処理する。

【0026】

各々のクラスタ１３０は、１つ以上のサービスに関連付けられたアプリケーションインスタンスを維持する１つ以上のコンピュータサーバ、たとえばコンテンツデリバリサーバおよび／またはアプリケーションサーバ、を含む。図１においては、クラスタ１３０ａ〜１３０ｃの各々は、システム１００に到達したときにデータパケット１０がアドレス指定されていたエニーキャストアドレスを介してアクセスされたアプリケーションまたはサービスに関連付けられたいくつかのアプリケーションインスタンス１３１を含む。所与のクラスタ１３０におけるアプリケーションインスタンス１３１は、単一のコンピュータサーバに常駐してもよく、または、同じクラスタ１３０のうちの複数のコンピュータサーバ間
で分散されてもよい。アプリケーションインスタンス１３１は対応する宛先ＩＰアドレスを介してアドレス指定される。この明細書中において参照されるアプリケーションインスタンスは、電子メールアプリケーション、ゲームアプリケーション、ソーシャルメディアアプリケーション、カレンダアプリケーションまたは他のいずれかのオンラインアプリケーションなどの、ウェブページまたはアプリケーションのエンドユーザの要求にサーブするサーバアプリケーションのコピーを含む。データパケット１０を受信するアプリケーションインスタンス１３１は、データパケット１０に関連付けられた要求を処理する。

【0027】

図２は、単層型ロードバランシングシステム１００によって実行される、エニーキャストデータパケットを処理するプロセス２００の実現例を説明するフローチャートを示す。プロセス２００は、エニーキャストアドレスにアドレス指定されたデータパケット１０をエニーキャストノード１１０によって受信するプロセス（ステージ２１０）と、受信されたデータパケット１０をエニーキャストノード１１０によってロードバランサ１２０に転送するプロセス（ステージ２２０）と、データパケットが予めサーブされていたフローまたはセッションに関連付けられているかどうかをロードバランサ１２０によって判断するプロセス（ステージ２３０）とを含む。データパケットが予めサーブされていたフローまたはセッションに関連付けられていると判断されると、プロセス２００は、予めサーブされていたフローまたはセッションに関連付けられたアプリケーションインスタンスに対してデータパケット１０を転送するプロセス（ステージ２４０）を含む。その他の場合、プロセス２００は、複数のサブデータ構造から或るサブデータ構造を選択するプロセス（ステージ２５０）と、データパケット１０のうち１つ以上のヘッダフィールドおよび選択されたサブデータ構造に基づいてアプリケーションインスタンス１３１を決定するプロセス（ステージ２６０）と、決定されたアプリケーションインスタンスにデータパケットを転送するプロセス（ステージ２７０）とを含む。

【0028】

エンドユーザがエニーキャストアドレスに関連付けられたオンラインサービスを要求するかまたは消費すると、当該エンドユーザから送信された対応するデータパケットが同じエニーキャストアドレスにアドレス指定される。１つ以上のエニーキャストノード１１０は、エニーキャストアドレスにアドレス指定されたデータパケットを受信する（ステージ２１０）。たとえば、エニーキャストアドレスにアドレス指定された各々のデータパケットは、データパケットのソースに最も近いエニーキャストノード１１０によって受信される。エニーキャストノードにアドレス指定されたデータパケットを受信する（ステージ２１０）と、受信側エニーキャストノードは、受信されたデータパケットが予めサーブされていたフローまたはセッション（たとえば既に確立されていた接続）に関連付けられているかどうかを判断するために、接続テーブルをチェックしてもよい。データパケットが既存のフローまたはセッションに関連付けられていると判断される場合、受信側エニーキャストノード１１０は、既存のフローまたはセッションに関連付けられた次のホップにデータパケットを転送する。接続テーブルのチェックは、受信側エニーキャストノード１１０以外の別のネットワークエレメントまたはデバイスによって実行され得るので、または、全体がスキップされ得るので、任意となる。

【0029】

フローが予め異なるエニーキャストノードによって実行されているかもしくは受信側エニーキャストノード１１０によるチェックが実行されていないデータパケットまたは同期（ＳＹＮ）データパケットなどのデータパケットが既存のフローまたはセッションに関連付けられていないと判断されると、エニーキャストノードはデータパケットをロードバランサ（ＬＢ）１２０に転送する（ステージ２２０）。データパケットを転送する（ステージ２２０）際、受信側エニーキャストノード１１０は、当該受信側エニーキャストノード１１０に関連付けられたデータパケットおよびサブデータ構造のうちの１つ以上のヘッダフィールド（たとえば、ソースＩＰアドレス、宛先ＩＰアドレスおよび／またはソースポート）に基づいてロードバランサ１２０を決定してもよい。また、エニーキャストノード
１１０は、データパケットをロードバランサ１２０に転送する前に、データパケットをデカプセル化してもよく、および／または、当該データパケットを１つ以上の新しいヘッダでカプセル化してもよい。

【0030】

データパケットを受信すると、ロードバランサ１２０は、受信されたデータパケットが予めサーブされていたフローまたはセッション（たとえば既に確立されている接続）に関連付けられているかどうかを判断するために接続テーブルをチェックしてもよい（ステージ２３０）。データパケットが既存のフローまたはセッションに対応していると判断される場合、ＬＢ１２０は、既存のフローまたはセッションにサーブしているアプリケーションインスタンスに対してデータパケットを転送する（ステージ２４０）。接続テーブルのチェックは、ＬＢ１２０以外の別のネットワークエレメントまたはデバイスによって実行され得るので、または、その全体がスキップされ得るので、任意となる。

【0031】

フローが予め異なるエニーキャストノードによって実行されているかもしくはＬＢ１２０によるチェックが実行されていないデータパケットまたは同期（ＳＹＮ）データパケットなどのデータパケットが既存のフローまたはセッションに関連付けられていないと判断されると、ＬＢは、ＬＢ１２０によって維持されているデータ構造１２１からサブデータ構造を選択する（ステージ２５０）。たとえば、データ構造１２１が単一のテーブルである場合、選択されたサブデータ構造はテーブルの行または列であってもよい。データ構造１２１が複数のテーブルを含んでいる他の場合には、選択されたサブデータ構造は複数のテーブルからなるテーブルとなる。サブデータ構造の選択は、データパケットのうちのヘッダフィールドに基づいて、および、ＩＰサブネットとシステム１００の対応する位置との間におけるサブデータ構造に基づいてなされてもよい。代替的には、選択は、データパケットのヘッダフィールド、およびリストにおける各々のサブデータ構造についての重みを反映しているサブデータ構造のリストに基づいていてもよい。データ構造１２１における各々のサブデータ構造は、システム１００の対応する位置（たとえばクラスタ１３０またはゾーン）に関連付けられたアプリケーションインスタンス１３１の冗長リストを表わしている。アプリケーションインスタンス１３１が対応するサブデータ構造に含まれている頻度は、同じアプリケーションインスタンス１３１に関連付けられた重み値に依存している。

【0032】

ＬＢ１２０は、次いで、データパケットのうちの１つ以上のヘッダフィールドを用いて、選択されたサブデータ構造からアプリケーションインスタンス１３１を決定する（ステージ２６０）。たとえば、ＬＢ１２０は、データパケットのうちの１つ以上のヘッダフィールドを用いてハッシュ値を生成し、次いで、生成されたハッシュ値を用いてサブデータ構造のエントリを決定する。ＬＢ１２０は、サブデータ構造のサイズを法として、生成されたハッシュ値を計算し、その結果を、選択されたエントリについてのインデックスとして用いてもよい。当業者であれば、選択されるべきサブデータ構造のエントリを識別するためにさまざまな方法でデータパケットのヘッダフィールドが用いられ得ることを認識するはずである。選択されたサブデータ構造の各々のエントリは、対応するアプリケーションインスタンス１３１に関連付けられたＩＰアドレス（たとえば宛先ＩＰアドレス）を含む。ＬＢ１２０は、次いで、データパケットに関連付けられた要求がサーブされている決定済みアプリケーションインスタンス１３１に対してデータパケットを転送する（ステージ２７０）。

【0033】

図３は、エニーキャストアドレスにアドレス指定されたデータトラフィックをロードバランシングするための２層型ロードバランシングシステム３００の実現例のブロック図を示す。システム３００は、以下において個々にまたは総称してエニーキャストノード３１０とも称されるエニーキャストリダイレクタノード３１０ａ〜３１０ｃと、以下において個々にまたは総称して第１層ロードバランサ３２０とも称される第１層ロードバランサデ
バイス３２０ａ〜３２０ｃと、以下において個々にまたは総称して第２層ロードバランサ３２５とも称される第２層ロードバランサ３２５ａ〜３２５ｃと、以下において個々にまたは総称してクラスタ３３０とも称される複数のサーバクラスタ、たとえばクラスタ３３０ａ〜３３０ｃとを含む。クラスタ３３０ａ〜３３０ｃの各々は、エニーキャストアドレスを通じてアクセスされるサービスに関連付けられたいくつかのアプリケーションインスタンス３３１を含む。

【0034】

エニーキャストノード３１０は、対応するエニーキャストアドレスにアドレス指定された受信されたデータパケット１０を１つ以上の第１の層ＬＢ３２０のうち或る第１の層ＬＢ３２０に転送するように構成される。エニーキャストノード３１０は、エニーキャストノード３１０に関連付けられたデータパケット１０およびサブデータ構造のうちの１つ以上のヘッダフィールド（たとえばソースＩＰアドレス、宛先ＩＰアドレスおよび／またはソースポート）に基づいてデータパケットを転送するための第１の層ＬＢ３２０を決定する。また、エニーキャストノード３１０は、データパケットを選択された第１の層ＬＢ３２０に転送する前に、データパケットをデカプセル化してもよく、および／または、当該データパケットを１つ以上の新しいヘッダでカプセル化してもよい。さらに、エニーキャストノード３１０は、図１に関連付けて説明されたエニーキャストノード１１０と同様に、データパケットを受信したときに接続テーブルをチェックしてもよい。

【0035】

いくつかの実現例においては、各々の第１の層ＬＢ３２０は、受信されたデータパケットをそれぞれの第２の層ＬＢ３２５にマッピングするための第１のデータ構造３２１を含む。場合によっては、第１のデータ構造３２１は、各々の第２の層ＬＢ３２５が第１のデータ構造に含まれている頻度が同じ第２の層ＬＢ３２５または対応する位置に関連付けられている重み値に依存するように、第２の層ＬＢ３２５の冗長リストを含む。たとえば、重みは、各々の対応する位置における利用可能容量、ＲＴＴを、各々の対応する位置、別のロードバランシング基準またはそれらの組合せに反映させてもよい。第１の層ＬＢ３２０は、データパケット１０のうちの１つ以上のヘッダフィールドに基づいて、対応する第１のデータ構造３２１から第２の層ＬＢ３２５を選択する。第１の層ＬＢ３２５は、次いで、選択された第２の層ＬＢ３２５にデータパケット１０を転送する。場合によっては、第１の層ＬＢ３２０は、データパケット１０のヘッダフィールドを用いてハッシュ値を生成し、生成されたハッシュ値に基づいて、第１のデータ構造３２１から第２の層ＬＢ３２５を選択する。他の場合には、第１の層ＬＢ３２０による第２の層ＬＢ３２５の選択は、図２に関連付けて説明されるように、サブデータ構造の選択と同様に実行されてもよい（ステージ２５０）。第１の層ＬＢ３２０による第２の層ＬＢ３２５の選択は、（図２におけるステージ２３０、ステージ２４０およびステージ２５０と同様に）第１の層ＬＢ３２０による接続テーブルのチェックに依存してもよい。

【0036】

各々の第２の層ＬＢ３２５は、システム３００の位置（たとえばゾーンまたはクラスタ３３０）に関連付けられており、システム３００の同じ位置に関連付けられた対応する第２のデータ構造３２６を含む。第２のデータ構造３２６は、同じ位置に関連付けられたアプリケーションインスタンスの冗長リストを含む。各々のアプリケーションインスタンスが第２のデータ構造３２６に含まれている頻度は、同じアプリケーションインスタンスに関連付けられた重み値を反映している。このような重みは、各々のアプリケーションインスタンスにおいて利用可能な容量、ＲＴＴを、各々のアプリケーションインスタンス、他のロードバランシング基準またはそれらの組合せに反映させてもよい。選択された第２の層ＬＢ３２５は、データパケット１０を受信し、データパケット１０のうちの１つ以上のヘッダフィールドに基づいて対応する第２のデータ構造３２６からアプリケーションインスタンスを決定する。たとえば、第１の層ＬＢ３２０は、データパケット１０のうちのヘッダフィールドを用いてハッシュ値を生成し、生成されたハッシュ値に基づいて第１のデータ構造３２１から第２の層ＬＢ３２５を選択する。いくつかの実現例においては、第２
のデータ構造３２６の各々のエントリは、対応するアプリケーションインスタンスに関連付けられたＩＰアドレス（たとえば宛先ＩＰアドレス）を含む。生成されたハッシュ値は、ＩＰアドレスを選択する際に、第２のデータ構造におけるエントリのインデックスとして用いることができる。第２の層ＬＢ３２５は、次いで、決定されたアプリケーションインスタンスにデータパケット１０を転送する。

【0037】

各々のクラスタ３３０は、１つ以上のサービスに関連付けられたアプリケーションインスタンスを維持する１つ以上のコンピュータサーバ（たとえばコンテンツデリバリサーバおよび／またはアプリケーションサーバ）を含む。図３においては、クラスタ３３０ａ〜３３０ｃの各々は、システム３００に到達したときにデータパケット１０がアドレス指定されていたエニーキャストアドレスを通じてアクセスされたアプリケーションまたはサービスに関連付けられたいくつかのアプリケーションインスタンス３３１を含む。所与のクラスタ３３０におけるアプリケーションインスタンス３３１は、単一のコンピュータサーバに常駐してもよく、または、同じクラスタ３３０の複数のコンピュータサーバ間で分散させられてもよい。アプリケーションインスタンス３３１は対応する宛先ＩＰアドレスを介してアドレス指定される。データパケット１０を受信するアプリケーションインスタンス３３１は、データパケット１０に関連付けられた要求を処理する。図３に示されるように、システム３００の各々のクラスタ３３０またはゾーンは１つ以上の第２の層ＬＢ３２５によってサーブされてもよい。たとえば、クラスタ３３０ａが第２の層ＬＢ３２５ａによってサーブされており、クラスタ３３０ｂが２つの第２の層ＬＢ３２５ｂおよびＬＢ３２５ｂ′によってサーブされている。

【0038】

図４は、２層型ロードバランシングシステム３００の別の実現例のブロック図を示す。例示を容易にするために、図４に示されるブロック図は、システム３００のうち、単一のエニーキャストノード３１０、２つの第１の層ＬＢ３２０ａおよび３２０ｂ、２つの第２の層ＬＢ３２５ａおよび３２５ｂ、ならびに２つのクラスタ３３０ａおよび３３０ｂだけを示している。システム３００はまた、第１のコントローラ３１２、第２のコントローラ３２２、第３のコントローラ３２７およびグローバルロードバランシングコントローラ３５０を含む。

【0039】

第１のコントローラ３１２は、ネットワークエレメント、コンピュータサーバまたは別の電子デバイスを含む。第１のコントローラ３１２はエニーキャストノード３１０を構成する。当該エニーキャストノード３１０は、ソースＩＰマップ、接続テーブルなどの情報、および／または、対応するエニーキャストアドレスにアドレス指定された受信済みデータパケット１０を処理する際にエニーキャストノード３１０によって用いられる他の情報を含む。第１のコントローラ３１２は、システム３００の１つ以上のデータベースまたは他のデバイスからこのような情報を取得し、対応する更新をエニーキャストノード３１０に提供してもよい。

【0040】

第２のコントローラ３２２はネットワークエレメント、コンピュータサーバまたは別の電子デバイスを含む。第２のコントローラ３２２は、システム３００の各々の位置（たとえばクラスタ３３０またはゾーン）に関連付けられた重みなどの情報；システム３００の位置にデータパケットをルーティングするためのルーティング情報；接続テーブル；および／または、受信されたデータパケット１０を処理する際に第１の層ＬＢ３２０によって用いられる他の情報、を提供することによって、第１の層ＬＢ３２０ａおよび３２０ｂを構成する。第２のコントローラデバイス３２２は、システム３００のうちのグローバルロードバランシングコントローラ３５０、１つ以上のデータベースまたは他のデバイスからこのような情報を獲得し、対応する更新を第１の層ＬＢ３２０に提供してもよい。

【0041】

第３のコントローラ３２７は、ネットワークエレメント、コンピュータサーバまたは別
の電子デバイスを含む。第３のコントローラ３２７は、システム３００の対応する位置における各々のアプリケーションインスタンス３３１に関連付けられた重みなどの情報；データパケット１０をアプリケーションインスタンス３３１にルーティングするためのルーティング情報；および／または、受信されたデータパケット１０を処理する際に第２の層ＬＢ３２０によって用いられる他の情報；を提供することによって、第２の層ＬＢ３２５ａおよび３２５ｂを構成する。第３のコントローラ３２７は、システム３００のうちの１つ以上のデータベースまたは他のデバイスからこのような情報を獲得し、対応する更新を第２の層ＬＢ３２０に提供してもよい。

【0042】

図４においては、システム３００のさまざまなコンポーネント間における実線は、（データ面とも称される）データパケット経路を示し、破線は、（制御面とも称される）構成情報／指示のフローを示し、破断線は、（制御面の一部でもあり得る）フィードバック経路を示す。いくつかの実現例においては、第１の層ＬＢ３２０が、システム３００のうちのある位置または対応する第２の層ＬＢ３２５にデータパケットを転送するたびに、第１の層ＬＢ３２５はこの転送をグローバルロードバランシングコントローラ３５０に報告する。また、第２の層ＬＢ３２５が、システム３００のグローバルロードバランシングコントローラ３５０および／または別のデバイスにデータパケット１０の転送を報告してもよい。グローバルロードバランシングコントローラ３５０は、第１の層ＬＢ３２０によって報告された情報を用いて、システム３００のさまざまな位置に関連付けられる重みを更新する。第２の層ＬＢ３２５によって報告される情報は、グローバルロードバランシングコントローラ３５０によって、または第２の層ＬＢ３２５に関連付けられた位置においてローカルなデバイスによって用いられて、さまざまなアプリケーションインスタンス３３１に関連付けられた重みを更新する。いくつかの実現例においては、クラスタ３３０は、そのサーバまたはアプリケーションインスタンス３３１のステータス情報をシステム３００におけるグローバルロードバランシングコントローラ３５０および／または他のデバイスに提供するように構成され得る。システム３００におけるグローバルロードバランシングコントローラ３５０または別のデバイスは、クラスタ３３０によって報告された情報を用いて、さまざまなアプリケーションインスタンス３３１に関連付けられた重みを更新することができる。いくつかの実現例においては、グローバルロードバランシングコントローラ３５０はまた、リンク輻輳に関するデータをルータおよび／またはネットワークエレメントから取得する。

【0043】

図５は、２層型ロードバランシングシステム３００によって実行される、エニーキャストデータパケットを処理するプロセス５００の実現例を説明するフローチャートを示す。プロセス２００は、エニーキャストアドレスにアドレス指定されたデータパケット１０をエニーキャストノード３１０によって受信するプロセス（ステージ５１０）と；受信されたデータパケット１０をエニーキャストノード３１０によって第１の層ＬＢ３２０に転送するプロセス（ステージ５２０）と；予めサーブされていたフローまたはセッションにデータパケットが関連付けられているかどうかを第１の層ＬＢ３２０によって判断するプロセス（ステージ５３０）と；予めサーブされていたフローまたはセッションにデータパケット１０が関連付けられていると判断される場合、予めサーブされていたデータフローまたはセッションに関連付けられたアプリケーションインスタンスにデータパケット１０を転送するプロセス（ステージ５４０）と；そうでない場合、第１の層ＬＢ３２０によって維持される第１のデータ構造およびデータパケット１０のうちの１つ以上のヘッダフィールドに基づいて第２の層ＬＢ３２５を選択するプロセス（ステージ５５０）と；選択された第２の層ＬＢ３２５にデータパケットを転送するプロセス（ステージ５６０）と；第２の層ＬＢ３２５によって維持される第２のデータ構造およびデータパケット１０のうちの１つ以上のヘッダフィールドに基づいて、選択された第２の層ＬＢ３２５によってアプリケーションインスタンス３３１を決定するプロセス（ステージ５７０）と；決定されたアプリケーションインスタンスにデータパケットを転送するプロセス（ステージ５８０）と
；を含む。

【0044】

プロセス５００のステージ５１０〜５４０は、（図３および図４に示される）第１の層ＬＢ３２５が（図１に示される）ロードバランサ１２０の代わりに用いられている点を除いては、図２に関連付けて記載されたプロセス２００のステージ２１０〜２４０と同様である。また、接続テーブルのチェックが第１の層ＬＢ３２０以外の別のデバイスによって実行され得るので、ステージ５３０および５４０は任意である。データパケット１０を受信する第１の層ＬＢ３２０は、第１の層ＬＢ３２０によって維持される第１のデータ構造３２１およびデータパケット１０のうちの１つ以上のヘッダフィールドに基づいて第２の層ＬＢ３２５を選択する（ステージ５５０）。第１のデータ構造３２１は、システム３００における第２の層ＬＢ３２５または対応する位置（たとえばクラスタ３３０もしくはゾーン）の冗長リストを含む。各々の第２の層ＬＢ３２５または対応する位置が第１のデータ構造３２１に含まれている頻度は、同じ対応する位置に関連付けられた重み値に依存している。重みは、各々の対応する位置における利用可能な容量、ＲＴＴを、各々の対応する位置、別のロードバランシング基準またはそれらの組合せに反映させてもよい。場合によっては、第１の層ＬＢ３２０は、データパケット１０のヘッダフィールドを用いてハッシュ値を生成し、生成されたハッシュ値に基づいて第１のデータ構造３２１から第２の層ＬＢ３２５を選択する。たとえば、第１の層ＬＢ３２０は、第１のデータ構造から選択されるべきエントリのインデックスとして、第１のデータ構造のサイズを法として、生成されたハッシュ値を用いる。第１の層ＬＢ３２０は、次いで、データパケットを、選択された第２の層ＬＢ３２５に、または、選択された位置に関連付けられた第２の層ＬＢ３２５に転送する（ステージ５６０）。

【0045】

データパケット１０を受信する第２の層ＬＢ３２５は、第２の層ＬＢ３２５によって維持される第２のデータ構造３２６およびデータパケット１０のうちの１つ以上のヘッダフィールドに基づいて、アプリケーションインスタンス３３１を決定する（ステージ５７０）。第２のデータ構造３２６は、アプリケーションインスタンス３３１の冗長リストを含む。各々のアプリケーションインスタンス３３１が第２のデータ構造３２６に含まれている頻度は、アプリケーションインスタンス３３１に関連付けられた重み値に依存している。重みは、各々の対応するアプリケーションインスタンス３３１における利用可能な容量、ＲＴＴを、各々の対応するアプリケーションインスタンス３３１、他のロードバランシング基準またはそれらの組合せに反映させてもよい。第２の層ＬＢ３２５は、データパケット１０のヘッダフィールドを用いてハッシュ値を生成し、生成されたハッシュ値に基づいて第２のデータ構造３２６からアプリケーションインスタンス３３１を決定する。たとえば、第２の層ＬＢ３２５は、第２のデータ構造３２６から選択されるべきエントリのインデックスとして、第２のデータ構造３２６のサイズを法として、生成されたハッシュ値を用いる。第２の層ＬＢ３２５は、次いで、決定されたアプリケーションインスタンス３３１にデータパケット１０を転送する（ステージ５８０）。

【0046】

図６は、ロードバランサによって用いられる冗長リストを生成するためのプロセス６００の実現例を説明するフローチャートを示す。たとえば、エンティティの各々が対応する重み値に関連付けられているリストを想定すると、リストにおけるエンティティの数よりも大きい素数は、生成されるべき冗長リストのサイズとして選択される。プロセス６００を実行するプロセッサは、エンティティの所与のリストにおける各々のエンティティについてのオフセット値およびステップ値を選択する（ステージ６１０）。プロセッサは、次いで、エンティティの所与のリストからエンティティを選択する（ステージ６２０）。この選択は、エンティティの（名前、名前の部分、識別ストリングなどの）識別の擬似ランダム置換に基づいて行うことができる。プロセッサは、選択されたエンティティについての冗長リストに既に含まれていたエントリの数を、対応する動的なしきい値と比較する（ステージ６３０）。たとえば、動的なしきい値は、反復回数を乗じた、選択されたエンテ
ィティに対応する重みとして規定される。既に含まれているエントリの数が動的なしきい値よりも小さいことが判明すると（ステージ６３０）、プロセッサは、生成されるべき冗長リストにおけるオフセット値によって示される位置が空であるかどうかをチェックする（ステージ６４０）。オフセット値によって示される位置が空ではないことが判明した場合、プロセッサは、対応するステップ値でオフセット値をインクリメントし、冗長リストのサイズを法として当該インクリメントされた値を切り捨てることによって、オフセット値を更新する（ステージ６５０）。プロセッサは、次いで、更新されたオフセット値によって示される位置が空であるかどうかをチェックする（ステージ６４０）。空の位置が検出されるまで、ステージ６５０および６４０が繰返される。いずれの時点においても、プロセスの結果（ステージ６４０）が空の位置を示す場合、プロセッサは、空の位置において選択されたエンティティに対応するエントリを追加する（ステージ６６０）。選択されたエンティティについてのエントリが冗長リストに追加される（ステージ６６０）か、または、選択されたエンティティについての既に追加されたエントリの数が動的なしきい値よりも大きいことが判明した（ステージ６３０）場合、プロセッサは、さらに、所与のリストにおけるすべてのエンティティが現在の繰返しにおいて処理されてしまっているかどうかをチェックする（ステージ６７０）。所与のリストにおけるすべてのエンティティが処理されてしまっていない場合、プロセッサは、処理すべき所与のリストから新しいエンティティを選択する（ステージ６２０）。そうでない場合、プロセッサは、繰返し数をインクリメントし（ステージ６８０）、次いで、処理すべき所与のリストからエンティティを選択する（ステージ６２０）。プロセッサは、冗長リストがフルになるまで、図６に示されるステージを繰返す。

【0047】

プロセス６００は、１次元テーブル（たとえば行もしくは列、ツリー、サブツリー、または他のデータ構造）として冗長リストを生成する。所与のリストにおけるエンティティは、アプリケーションインスタンス１３１もしくは３３１、ロードバランサ１２０もしくは３２５、またはロードバランシングシステム１００もしくは３００の位置であってもよい。生成された冗長リストにおいては、各々のエンティティが繰返される頻度は同じエンティティに対応する重み値に依存している。冗長リストのサイズが所与のリストにおけるエンティティの総数よりもはるかに大きくなるように、たとえば１００倍大きくなるように、選択される場合、エンティティが冗長リストに含まれている頻度は対応する重みにほぼ比例するようになる。生成された冗長リストのサイズが所与のリストにおけるエンティティの数と比べて大きければ大きいほど、頻度と同じエンティティの重みとの間の比例関係がより正確になる。

【0048】

図７は、図１および図３におけるシステムによって採用されるデータ構造の例を示す。クラスタＡ（たとえばクラスタ１３０ａまたは３３０ａ）の３つのアプリケーションインスタンスＡ＿１、Ａ＿２およびＡ＿３、ならびにクラスタＢ（たとえばクラスタ１３０ｂまたは３３０ｂａ）の３つのアプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３を考慮すると、図７におけるテーブルの各々の行は、対応するセットの重みに基づいて生成される、（図６に示される）プロセス６００において１７に等しいサイズを有するサンプル出力を示している。たとえば、第１の行は、各々のアプリケーションインスタンスＡ＿１、Ａ＿２およびＡ＿３に関連付けられた重みが１．０に等しく、かつ、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３に関連付けられた重みが０．０に等しくなる出力に対応している。いずれかの行から次の行にまで進むと、アプリケーションインスタンスＡ＿１、Ａ＿２およびＡ＿３についての重み値は０．１ずつデクリメントされ、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３についての重み値は０．１ずつインクリメントされる。

【0049】

アプリケーションインスタンスに関連付けられた重みが図７に示されるテーブルにおいて或る１つの行から次の行へと変化するのが低速であるので、この或る１つ行から次の行
までで観察される変化はほんのわずかである。実際には、重みが或る１つの行から次の行へとわずかしか変化しないので、図７のテーブルの列を調べることによって、各々の列にわたってはほんのわずかな変化しか起こらないことが分かるだろう。

【0050】

図１のクラスタ１３０ａがアプリケーションインスタンスＡ＿１、Ａ＿２およびＡ＿３を含み、これらのアプリケーションインスタンスの各々がオーバーフローを経験しているシナリオを検討する。オーバーフロー需要（たとえば２０％）は、利用可能な容量を含む次に最も近接するクラスタ（たとえば、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３を含む図１のクラスタ１３０ｂ）にリダイレクトされることとなる。そのため、図１のクラスタ１３０ａに関連付けられたエニーキャストトラフィックに対して、０．８の重み値はアプリケーションインスタンスＡ＿１、Ａ＿２およびＡ＿３の各々に関連付けられ、０．２の重み値は、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３の各々に関連付けられている。このような場合、図７におけるテーブルの第３の行は、図１のクラスタ１３０ａに関連付けられたサブデータ構造のサンプルを表わしている。また、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３がクラスタ１３０ｂに到達するエニーキャストトラフィックにサーブするのに十分な帯域幅を有していると想定すると、これらのアプリケーションインスタンスはすべて、図１に示されるクラスタ１３０ｂに関連付けられたエニーキャストトラフィックに到達したときに１．０の等しい重みを有することとなる。そのため、図７におけるテーブルの最後の行は、図１のクラスタ１３０ｂに関連付けられたサブデータ構造のサンプルを表わしている。

【0051】

連続する行のいずれかの対を比較すると、或る１つの行から次の行に変化するエントリがほとんどわずかしかないことが観察できる。このような観察は、重み値のわずかな変化（重み値は１つの行から次の行へと±０．１ずつ変化する）がデータ経路に与える影響がほんのわずかであることを示している。小さな重み値に関連付けられた１つのアプリケーションインスタンスを追加または削除することによっても、それぞれの行またはサブデータ構造のエントリに対して与える影響はほんのわずかになるだろう。（図６に示されるプロセス６００を用いて）行またはサブデータ構造が生成される方法では、結果として、（図１および図３に示される）それぞれのアプリケーションインスタンス１３１または３３１に対する新しい要求の割当てに一貫性が得られる。いくつかの実現例においては、重み値のわずかな変化、および／または、小さな重みに関連付けられたアプリケーションインスタンスの追加／削除により、結果として、データトラフィックの再ルーティング（またはネットワークルータもしくは他のネットワークエレメントにおけるルーティングテーブルの再演算）が行われなくなる。なぜなら、このような変化は、ロードバランシングデータトラフィックにごくわずかな影響しか与えないからからである。

【0052】

アプリケーションインスタンスが図３のクラスタ３３０ａに関連付けられ、アプリケーションインスタンスＢ＿１、Ｂ＿２およびＢ＿３が図３のクラスタ３３０ｂに関連付けられている、同様のシナリオ（たとえば上述の段落において記載されるのと同じ重みが用いられている）を考慮すると、図７におけるテーブルの第３の行は、図３のクラスタ３３０ａに関連付けられた第２のデータ構造３２６のサンプルを表わしている。また、図７におけるテーブルの最後の行は、図３のクラスタ３３０ｂに関連付けられた第２のデータ構造３２６のサンプルを表わしている。

【0053】

本明細書に記載の主題および動作の実現例は、本明細書に開示された構造およびそれらの構造均等物を含むデジタル電子回路、または有形媒体、ファームウェアもしくはハードウェア上で具体化されたコンピュータソフトウェア、またはこれらの１種以上の組合せで実現することができる。本明細書に記載される主題の実現例は、有形媒体上で具体化された１つ以上のコンピュータプログラムとして、すなわち、データ処理装置によって実行されるかまたはデータ処理装置の操作を制御するために、１つ以上のコンピュータ記憶媒体
にエンコードされたコンピュータプログラム命令の１つ以上のモジュールとして実装することができる。コンピュータ記憶媒体は、コンピュータ読み取り可能な記憶装置、コンピュータ読み取り可能な記憶基板、ランダムまたはシリアルアクセスメモリアレイもしくは装置、または１つ以上のこれらの装置の組合せであってもよく、その中に含まれてもよい。コンピュータ記憶媒体は、１つ以上の別個の要素または媒体（たとえば、複数のＣＤ、ディスクまたは他の記憶装置）であってもよく、その中に含まれてもよい。コンピュータ記憶媒体は、有形且つ非一時的なものであってもよい。

【0054】

本明細書に記載の動作は、１つ以上のコンピュータ読み取り可能な記憶装置に記憶されたデータまたは他のソースから受信したデータに従って、データ処理装置によって実行される動作として実現可能である。プロセスフローおよび論理フローは、専用論理回路、たとえばＦＰＧＡ（field programmable gate array：フィールドプログラマブルゲートア
レイ）またはＡＳＩＣ（application specific integrated circuit：特定用途向け集積
回路）としても実装され得る装置によって実行可能である。

【0055】

本明細書は、多くの具体的な実現詳細を記載しているが、これらの詳細は、発明または特許請求の範囲を限定するものとして解釈すべきではなく、特定の発明の特定の実現例に必要な特徴の説明として解釈すべきである。また、本明細書の個別の実現例に記載された特定の特徴は、単一の実現例に組み合わせて実施することができる。逆に、単一の実現例の文脈に記載されたさまざまな特徴は、複数の実現例で別個にまたは実現例の適切な組合せで実施することができる。さらに、上述のとおり特定の組合せで動作するものと記載され最初にこのようにクレームされているにも関わらず、場合によっては、クレームされた組合せに含まれた１つ以上の特徴をその組合せから除去してもよく、クレームされた組合せを別の組合せまたはその変形例に加えてもよい。

【0056】

用語「または」を言及する場合、「または」を用いて記載されたいずれの用語も、単一のもの、複数のものおよび記載されたすべてのものを指し得るように、包含的であると解釈されるべきである。「第１」、「第２」および「第３」などの用語は、必ずしも順序を指すものではなく、一般に同様または類似の項目または要素を区別するために用いられるに過ぎない。

【0057】

主題の特定の実現例を記載してきたが、他の実現例も添付の特許請求の範囲内に含まれる。場合によっては、特許請求の範囲に記載された動作は、異なる順序で実行されても、望ましい結果を達成することができる。また、添付の図面に示された工程は、望ましい結果を達成するために、必ずしも図示された特定の順序または順番である必要はない。いくつかの実現例においては、マルチタスクまたは並列処理が利用されてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】