JP2022540785A - インテリジェントロードバランサ - Google Patents

Abstract

ネットワーク上のリクエストをルーティングするための技法が説明される。幾つかの態様に従うと、動的ルーティング決定を容易にするために、時間ウィンドウは、時間の経過と共に増分又は移動させられる。時間ウィンドウは、ウィンドウが増分されるとき、異なる時間におけるトラフィックを推定又は予測するために、ウィンドウに適用されるポアソン又はガウス確率分布等の適切な確率分布モデルに基づいて、着信リクエストトラフィックを予測又は推定するために使用され得る。各リクエスト又はトラフィックイベントの到来時間及び完了時間がモデル化され得るように、着信リクエストに対する推定実行時間も計算され得る。プロセッサ実装ルーチンは、時間ウィンドウの着信トラフィック推定及び推定実行時間によって定義されるサブ問題を効率的に解決するために用いられ得、原因となる又は全体のルーティング決定問題が、リアルタイムコンテキストを含む動的プロセスを使用して効率的に解決されることを可能にする。

Description

本開示は、一般的に、ネットワーク化された環境におけるトラフィックの負荷分散に関する。

このセクションは、以下で説明及び／又は主張される、本開示の様々な態様に関連し得る技術の様々な態様を読者に紹介することを意図している。この論考は、本開示の様々な態様のより良い理解を容易にするための背景情報を読者に提供するのに役立つと考えられる。したがって、これらの声明は、従来技術の承認としてではなく、この観点から読まれるべきであると理解すべきである。

組織は、規模に関係なく、それらの継続的な運用及び成功のために、情報技術（ＩＴ）並びにデータ及びサービスへのアクセスに依存している。個別の組織のＩＴインフラストラクチャは、関連するハードウェアリソース（例えば、コンピューティングデバイス、ロードバランサ、ファイアウォール、スイッチ等）とソフトウェアリソース（例えば、生産性ソフトウェア、データベースアプリケーション、及びカスタムアプリケーション等）とを有し得る。時間の経過と共に、益々多くの組織が、それらのＩＴインフラストラクチャソリューションを補完又は強化するためにクラウドコンピューティングアプローチに関心を向けている。

クラウドコンピューティングは、インターネットを介して一般的にアクセスされるコンピューティングリソースの共有に関連する。特に、クラウドコンピューティングインフラストラクチャは、個人及び／又は企業等のユーザが、サーバ、ストレージデバイス、ネットワーク、アプリケーション、及び／又はその他のコンピューティングベースのサービス等のコンピューティングリソースの共有プールにアクセスすることを可能にする。そうすることによって、ユーザは、離れた場所に設置されたコンピューティングリソースにオンデマンドでアクセスすることが可能であり、そのリソースは、様々なコンピューティング機能（例えば、大量のコンピューティングデータの格納及び/又は処理）を実施するために使用され得る。企業及びその他の組織のユーザにとって、クラウドコンピューティングは、高価なネットワーク機器を購入すること又はプライベートネットワークインフラストラクチャの確立に多大な時間を費やすこと等、多額の先行投資を発生させることなく、クラウドコンピューティングリソースにアクセスすることの柔軟性を提供する。代わりに、クラウドコンピューティングリソースを利用することによって、ユーザは、それらの企業のコア機能に集中するように、それらのリソースを向け直すことが可能である。

クラウドコンピューティングインフラストラクチャ内のアプリケーションノード間でトラフィックをルーティングするためのアプローチでは、実装が容易で便利な“グリーディ”アルゴリズム（例えば、単一の基準又は条件に基づいてトラフィック又はリクエストを割り当てるアルゴリズム）がしばしば用いられる。こうした“グリーディ”アプローチは、通常、単一の考慮事項にそれらの焦点を合わせることに起因して、プラットフォーム全体での最適な結果を達成しない。しかしながら、プラットフォームに渡ってより最適な結果を提供し得る他のアプローチ、例えば、動的アプローチは、計算量がより多く、実装が難しく、通常、複数の要因を行う基本となる最適なルーティングソリューションを判定するために、リクエスト自体に加えて入力のセットを必要とする。動的ルーティングに対するこうした要件は、通常、リアルタイムのシナリオに合致しないことがある。

本明細書に開示される幾つかの実施形態の概要を以下に記載する。これらの態様は、単に、読者にこれらの幾つかの実施形態の簡単な概要を提供するために提示されており、これらの態様は、この開示の範囲を限定することを意図していないことを理解すべきである。実際、この開示は、以下に記載されないことがある様々な態様を包含し得る。

本アプローチは、動的ルーティング決定を容易にするために、時間の経過と共に増分又は移動させられる時間ウィンドウを用いる。時間ウィンドウは、ウィンドウが増分させられるとき、異なる時間におけるトラフィックを推定又は予測するように、ウィンドウに適用されるポアソン又はガウス確率分布等の適切な確率分布モデルに基づいて着信リクエストトラフィックを予測又は推定するために使用され得る。各リクエスト又はトラフィックイベントの到来時間及び完了時間がモデル化され得るように、着信リクエストに対する推定実行時間も計算され得る。本明細書で説明するように、プロセッサ実装ルーチンは、時間ウィンドウの着信トラフィック推定及び推定実行時間によって定義されるサブ問題を効率的に解決するために使用され、原因となる又は全体のルーティング決定問題が、リアルタイムコンテキストを含む動的プロセスを使用して効率的に解決されることを可能にする。

本開示の様々な態様に関連して、上述の機構の様々な改良が存在し得る。これらの様々な態様に、更なる機構も同様に組み込まれ得る。これらの改良点及び追加の機構は、個々に、又は任意の組み合わせで存在し得る。実例として、説明する実施形態の内の１つ以上に関して以下に論じる様々な機構は、本開示の上で説明した態様の内の何れかに、単独で又は任意の組み合わせで組み込まれ得る。上で提示した簡単な概要は、請求される主題を限定することなく、本開示の実施形態の幾つかの態様及びコンテキストを読者に習熟させることのみを意図している。

この開示の様々な態様は、以下の詳細な説明を読み、以下の図面を参照すると、より良く理解され得る。

本開示の実施形態が動作し得るクラウドアーキテクチャの実施形態のブロック図である。 本開示の実施形態が動作し得るマルチインスタンスクラウドアーキテクチャの実施形態の概略図である。 本開示の態様に従った、図１又は図２に存在し得るコンピューティングシステムで利用されるコンピューティングデバイスのブロック図である。 本開示の態様に従った、仮想サーバがクライアントインスタンスをサポート及び有効化する実施形態を示すブロック図である。 本開示の態様に従った、時間の各ウィンドウ内の予測されたイベント又はリクエストに関連して、時間の経過と共にスライドする時間ウィンドウを描写する。 本開示の態様に従った、ネットワークトラフィックをルーティングするのに適した優先度ツリーの生成での使用に適したステップ及びパラメータのプロセスフローを描写する。 本開示の態様に従った、リクエストキューに到来するネットワークトラフィックをルーティングするのに適した優先度ツリーの一例を描写する。

１つ以上の具体的な実施形態が以下に説明されるであろう。これらの実施形態の簡潔な説明を提供するために、実際の実装の全ての機構が明細書に説明されているわけではない。任意のエンジニアリング又は設計プロジェクトにおいて見られるように、そうした何れかの実際の実装の開発では、ある実装から別の実装に変化し得る、システム関連及び企業関連の制約への準拠等、開発者固有の目標を達成するために、実装固有の多数の決定がなされなければならないことを理解すべきである。更に、そうした開発努力は複雑で時間がかかり得るが、それにもかかわらず、この開示の利益を有する当業者にとっては、設計、製作、及び製造の日常的な作業であろうことを理解すべきである。

本明細書で使用されるとき、用語“コンピューティングシステム”は、非限定的に、単一のコンピュータ、仮想マシン、仮想コンテナ、ホスト、サーバ、ラップトップ、及び／若しくはモバイルデバイス等の電子コンピューティングデバイスを指し、又はコンピューティングシステム上で、若しくはコンピューティングシステムによって実施されると説明される機能を実施するために共同する複数の電子コンピューティングデバイスを指す。本明細書で使用されるとき、用語“媒体”は、その上に格納されると説明されるコンテンツを共に格納する、１つ以上の非一時的コンピュータ可読物理媒体を指す。実施形態は、不揮発性二次的ストレージ、リードオンリーメモリ（ＲＯＭ）、及び／又はランダムアクセスメモリ（ＲＡＭ）を含み得る。本明細書で使用されるとき、用語“アプリケーション”は、１つ以上のコンピューティングモジュール、プログラム、プロセス、ワークロード、スレッド、及び／又はコンピューティングシステムによって実行されるコンピューティング命令のセットを指す。アプリケーションの例示的な実施形態は、ソフトウェアモジュール、ソフトウェアオブジェクト、ソフトウェアインスタンス、及び／又はその他のタイプの実行可能コードを含む。

クラウドコンピューティングインフラストラクチャ内のリソース（例えば、アプリケーションノード）間のトラフィックをルーティングするためのアプローチは、現在のルーティングリクエストを処理するための単一の要因又は基準を通常考慮し、したがって実装が容易で便利な“グリーディ”アルゴリズムを通常用いる。例として、“グリーディ”アルゴリズムは、“ラウンドロビン”アプローチ、又は最も長くアイドル状態であるノードが選択されるアプローチであり得る。そうした“グリーディ”アプローチは、しかしながら、即時のステップ若しくはリクエストを超えたその他の関連する要因の考慮不足に起因してプラットフォーム全体の最適な結果を通常達成しない、予想される将来のネットワークトラフィック負荷及び／又は特定のリソースを必要とする予想されるリクエスト若しくはトラフィック負荷等の他の要因を考慮していないことがある。他の入力及び要因を考慮に入れる他のアプローチ、例えば、動的アプローチは、特に非ローカルなコンテキストにおいて、より最適な結果を提供し得る。しかしながら、そうした動的アプローチは計算量がより多く、実装が難しく、通常、最適なルーティングソリューションを判定するためにリクエスト自体に加えて入力を必要とし、それは、そうしたアプローチをリアルタイムルーティングシナリオでの使用に適さなくし得る。

前述のことを念頭に置いて、本アプローチの一実装では、動的ルーティングに対するトラフィック予測の態様は、時間の経過と共に移動又は増分させられる時間ウィンドウを使用して対処され得る。幾つかの実施形態に従えば、所与のウィンドウ内で、個別の時間において、個別の負荷又はトラフィックタイプに対して予測されるトラフィックは、適切な確率分布モデル（例えば、ポアソン及びガウス等）を使用してマッピングされ得、それによって、所与の時間ウィンドウ内のモデル化されたタイプのネットワークイベント（例えば、リクエスト）の推定又は予想を提供する。また、所与のイベントに対するランタイム推定の態様は、様々な要因（例えば、入力、リクエスト時間、及びサーバ統計等）を説明する線形回帰モデル等の適切な統計モデルを使用して推定され得る。これらの別個の問題のプロセッサベースの解決は、リアルタイムコンテキストを含む、動的ネットワークトラフィックルーティングの結果の改善を可能にし得る。

以下の図は、マルチインスタンスフレームワークで組織にサービスを提供するために用いられ得、本アプローチが用いられ得る様々なタイプの一般化されたシステムアーキテクチャ又は構成に関する。それに応じて、これらのシステム及びプラットフォームの例は、本明細書で論じられる技法が実装され得、さもなければ利用され得るシステム及びプラットフォームにも関し得る。ここで図１に目を向けると、本開示の実施形態が動作し得るクラウドコンピューティングシステム１０の実施形態の概略図が説明されている。クラウドコンピューティングシステム１０は、クライアントネットワーク１２、ネットワーク１４（例えば、インターネット）、及びクラウドベースのプラットフォーム１６を含み得る。幾つかの実装では、クラウドベースのプラットフォーム１６は、構成管理データベース（ＣＭＤＢ）プラットフォームであり得る。一実施形態では、クライアントネットワーク１２は、スイッチ、サーバ、及びルータを含むがこれらに限定されない様々なネットワークデバイスを有するローカルエリアネットワーク（ＬＡＮ）等のローカルプライベートネットワークであり得る。別の実施形態では、クライアントネットワーク１２は、１つ以上のＬＡＮ、仮想ネットワーク、データセンタ１８、及び／又はその他のリモートネットワークを含み得る企業ネットワークを表す。図１に示すように、クライアントネットワーク１２は、クライアントデバイスが相互に及び／又はプラットフォーム１６をホストするネットワークと通信可能であるように、１つ以上のクライアントデバイス２０Ａ、２０Ｂ、及び２０Ｃに接続可能である。クライアントデバイス２０は、例えば、ウェブブラウザアプリケーションを介して、又はクライアントデバイス２０とプラットフォーム１６との間のゲートウェイとして機能し得るエッジデバイスを介してクラウドコンピューティングデバイスにアクセスする、モノのインターネット（ＩｏＴ）と一般的に称されるコンピューティングシステム及び／又はその他のタイプのコンピューティングデバイスであり得る。図１はまた、プラットフォーム１６、他の外部アプリケーション、データソース、及びサービスをホストするネットワークとクライアントネットワーク１２との間のデータの通信を容易にする管理、計装、及び発見（ＭＩＤ）サーバ２４等の運営若しくは管理デバイス、エージェント、又はサーバをクライアントネットワーク１２が含むことを説明する。図１には特に説明されていないが、クライアントネットワーク１２はまた、接続ネットワークデバイス（例えば、ゲートウェイ若しくはルータ）、又は顧客ファイアウォール若しくは侵入保護システムを実装するデバイスの組み合わせを含み得る。

説明する実施形態に対して、図１は、クライアントネットワーク１２がネットワーク１４に結合されることを説明する。ネットワーク１４は、クライアントデバイス２０とプラットフォーム１６をホストするネットワークとの間でデータを転送するための他のＬＡＮ、広域ネットワーク（ＷＡＮ）、インターネット、及び／又は他のリモートネットワーク等の１つ以上のコンピューティングネットワークを含み得る。ネットワーク１４内のコンピューティングネットワークの各々は、電気的及び／又は光学的ドメインで動作する有線及び／又は無線のプログラミング可能デバイスを含み得る。例えば、ネットワーク１４は、セルラーネットワーク（例えば、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）ベースのセルラーネットワーク）、ＩＥＥＥ ８０２．１１ネットワーク、及び／又はその他の適切な無線ベースのネットワーク等の無線ネットワークを含み得る。ネットワーク１４はまた、伝送制御プロトコル（ＴＣＰ）及びインターネットプロトコル（ＩＰ）等の任意の数のネットワーク通信プロトコルを用い得る。図１には明示的に示されていないが、ネットワーク１４は、サーバ、ルータ、ネットワークスイッチ、及び／又はネットワーク１４を介してデータを転送するように構成されたその他のネットワークハードウェアデバイス等の様々なネットワークデバイスを含み得る。

図１において、プラットフォーム１６をホストするネットワークは、クライアントネットワーク１２及びネットワーク１４を介してクライアントデバイス２０と通信可能であるリモートネットワーク（例えば、クラウドネットワーク）であり得る。プラットフォーム１６をホストするネットワークは、クライアントデバイス２０及び／又はクライアントネットワーク１２に追加のコンピューティングリソースを提供する。例えば、プラットフォーム１６をホストするネットワークを利用することによって、クライアントデバイス２０のユーザは、様々な企業、ＩＴ、及び／又は他の組織関連の機能に対するアプリケーションを構築及び実行することが可能である。一実施形態では、プラットフォーム１６をホストするネットワークは、１つ以上のデータセンタ１８上に実装され、各データセンタは、異なる地理的場所に対応し得る。データセンタ１８の各々は、複数の仮想サーバ２６（本明細書では、アプリケーションノード、アプリケーションサーバ、仮想サーバインスタンス、アプリケーションインスタンス、又はアプリケーションサーバインスタンスとも称される）を含み、各仮想サーバ２６は、単一の電子コンピューティングデバイス（例えば、単一の物理ハードウェアサーバ）等の物理コンピューティングシステム上に、又は複数のコンピューティングデバイス（例えば、複数の物理ハードウェアサーバ）に渡って実装され得る。仮想サーバ２６の例は、ウェブサーバ（例えば、ユニタリーＡｐａｃｈｅインストール）、アプリケーションサーバ（例えば、ユニタリーＪＡＶＡ仮想マシン）、及び／又はデータベースサーバ（例えば、ユニタリーリレーショナルデータベース管理システム（ＲＤＢＭＳ）カタログ）を含むが、これらに限定されない。

図１に説明するように、１つ以上のロードバランサ２８は、クライアントデバイス２０からクラウドプラットフォームリソースにトラフィックをルーティングするために提供され得る。こうしたロードバランサ２８は、ハードウェア、ソフトウェア、及びファームウェアの任意の適切な組み合わせとして実装され得る。例として、描写するシナリオでは、１つ以上のロードバランサ２８は、クライアントデバイス２０と仮想サーバ（例えば、アプリケーションノード又はサーバ）２６との間に位置付けられ得る。このシナリオでは、クライアントデバイス２０によってなされるリクエストは、本明細書で論じる技法に従って、個別のアプリケーションノード又はサーバにルーティングされ得る。

プラットフォーム１６内のコンピューティングリソースを利用するために、ネットワークオペレータは、様々なコンピューティングインフラストラクチャを使用してデータセンタ１８を構成するように選択し得る。一実施形態では、サーバインスタンス２６の内の１つが、複数の顧客からのリクエストを処理し、サービスを提供するように、データセンタ１８の内の１つ以上は、マルチテナントクラウドアーキテクチャを使用して構成される。マルチテナントクラウドアーキテクチャを備えたデータセンタ１８は、複数の顧客からのデータを混合して格納し、複数の顧客インスタンスは仮想サーバ２６の内の１つに割り当てられる。マルチテナントクラウドアーキテクチャでは、特定の仮想サーバ２６は、様々な顧客のデータ及びその他の情報を区別し、分離する。例えば、マルチテナントクラウドアーキテクチャは、各顧客からのデータを識別及び分離するために、顧客毎に特定の識別子を割り当て得る。一般的に、マルチテナントクラウドアーキテクチャを実装することは、サーバインスタンス２６の内の特定の１つの障害が、該特定のサーバインスタンスに割り当てられた全ての顧客に対して停止を生じさせる等、様々な欠点に悩まされる。

別の実施形態では、データセンタ１８の内の１つ以上は、全ての顧客に独自のユニークな１つ以上の顧客インスタンスを提供するように、マルチインスタンスクラウドアーキテクチャを使用して構成される。例えば、マルチインスタンスクラウドアーキテクチャは、独自の専用のアプリケーションサーバと専用のデータベースサーバとを各顧客インスタンスに提供し得る。他の例では、マルチインスタンスクラウドアーキテクチャは、顧客インスタンス毎に、１つ以上の専用のウェブサーバ、１つ以上の専用のアプリケーションサーバ、及び１つ以上のデータベースサーバ等の、単一の物理若しくは仮想サーバ２６、並びに／又は物理及び／若しくは仮想サーバ２６のその他の組み合わせを配備し得る。マルチインスタンスクラウドアーキテクチャでは、複数の顧客インスタンスは、１つ以上の個別のハードウェアサーバ上にインストールされ、各顧客インスタンスには、コンピューティングメモリ、ストレージ、処理能力等の物理サーバリソースの幾つかの部分が割り当てられる。そうすることによって、各顧客インスタンスは、データ分離、顧客がプラットフォーム１６にアクセスするための比較的少ないダウンタイム、及び顧客主導のアップグレードスケジュールの利点を提供する独自のユニークなソフトウェアスタックを有する。マルチインスタンスクラウドアーキテクチャ内に顧客インスタンスを実装する例は、図２を参照して以下でより詳細に論じられるであろう。

図２は、本開示の実施形態が動作し得るマルチインスタンスクラウドアーキテクチャ１００の実施形態の概略図である。図２は、マルチインスタンスクラウドアーキテクチャ１００が、相互に地理的に分離され得る２つの（例えば、対にされた）データセンタ１８Ａ及び１８Ｂに接続するクライアントネットワーク１２及びネットワーク１４を含むことを説明する。例として図２を使用すると、ネットワーク環境及びサービスプロバイダクラウドインフラストラクチャクライアントインスタンス１０２（本明細書ではクライアントインスタンス１０２とも称される）は、専用の仮想サーバ（例えば、仮想サーバ２６Ａ、２６Ｂ、２６Ｃ、及び２６Ｄ）並びに専用のデータベースサーバ（例えば、仮想データベースサーバ１０４Ａ及び１０４Ｂ）と関連付けられる（例えば、それらによってサポート及び有効化される）。別の言い方をすれば、仮想サーバ２６Ａ～２６Ｄ並びに仮想データベースサーバ１０４Ａ及び１０４Ｂは、他のクライアントインスタンスと共有されず、個別のクライアントインスタンス１０２に固有である。描写する例では、クライアントインスタンス１０２の可用性を容易にするために、仮想サーバ２６Ａ～２６Ｄ並びに仮想データベースサーバ１０４Ａ及び１０４Ｂは、データセンタ１８の内の１つがバックアップデータセンタとして機能するように、２つの異なるデータセンタ１８Ａ及び１８Ｂに割り当てられる。マルチインスタンスクラウドアーキテクチャ１００の他の実施形態は、ウェブサーバ等の他のタイプの専用の仮想サーバを含み得る。例えば、クライアントインスタンス１０２は、専用の仮想サーバ２６Ａ～２６Ｄ、専用の仮想データベースサーバ１０４Ａ及び１０４Ｂ、並びに追加の専用の仮想ウェブサーバ（図２には示さず）と関連付けられ（例えば、それらによってサポート及び有効化され）得る。

図１及び図２は、クラウドコンピューティングシステム１０及びマルチインスタンスクラウドアーキテクチャ１００の特定の実施形態を夫々説明するが、開示は、図１及び図２に説明する特定の実施形態に限定されない。実例として、図１は、プラットフォーム１６がデータセンタを使用して実装されることを説明するが、プラットフォーム１６の他の実施形態は、データセンタに限定されず、他のタイプのリモートネットワークインフラストラクチャを利用し得る。更に、本開示の他の実施形態は、１つ以上の異なる仮想サーバを単一の仮想サーバに結合し得、又は逆に、複数の仮想サーバを使用して単一の仮想サーバに起因する動作を実施し得る。実例として、例として図２を使用すると、仮想サーバ２６Ａ、２６Ｂ、２６Ｃ、２６Ｄ、及び仮想データベースサーバ１０４Ａ、１０４Ｂは、単一の仮想サーバに結合され得る。更に、本アプローチは、マルチテナントアーキテクチャ、一般化されたクライアント／サーバ実装、及び／又は本明細書で論じた動作の内の幾つか又は全てを実施するように構成された単一の物理プロセッサベースのデバイスを含むがこれらに限定されない他のアーキテクチャ又は構成で実装され得る。同様に、実装の論考を容易にするために仮想サーバ又はマシンが言及され得るが、必要に応じて物理サーバが代わりに用いられ得る。図１及び図２の使用及び論考は、説明及び解説を容易にするための単なる例であり、開示をそこに説明する特定の例に限定することを意図しない。

理解され得るように、図１及び図２に関して論じた個別のアーキテクチャ及びフレームワークは、様々なタイプのコンピューティングシステム（例えば、サーバ、ワークステーション、クライアントデバイス、ラップトップ、タブレットコンピュータ、及び携帯電話等）全体を組み込む。完全を期すために、こうしたシステムで通常見られるコンポーネントの簡単で高レベルの概要が提供される。理解され得るように、本概要は、そうしたコンピューティングシステムにおいて典型的なコンポーネントの高レベルの一般化された図を単に提供することを意図しており、論じられた又は論考から省かれたコンポーネントに関して限定的であるとみなされるべきではない。

背景として、本アプローチは、図３に示されるような１つ以上のプロセッサベースのシステムを使用して実施され得ることが理解され得る。同様に、本アプローチで利用されるアプリケーション及び／又はデータベースは、そうしたプロセッサベースのシステム上に格納され得、用いられ得、及び／又は維持され得る。本コンテキストにおいて、ロードバランサ２８は、図３に示されるように、プロセッサベースのシステムとして提供され得、プロセッサベースのシステムのプロセッサ上で格納されたルーチンを実行することによって、本明細書で論じるような動作（例えば、予測されるネットワークトラフィックに対応する優先度ツリーの生成及び／又は使用に関連する動作）を実施し得る。理解され得るように、図３に示されるようなこうしたシステムは、分散コンピューティング環境、ネットワーク化された環境、又はその他のマルチコンピュータプラットフォーム若しくはアーキテクチャ内に存在し得る。同様に、図３に示されるシステム等のシステムは、本アプローチが実装され得る１つ以上の仮想環境又は計算インスタンスをサポートすること又はそれらと通信することに使用され得る。

これを念頭に置いて、例示的なコンピュータシステムは、図３に描写されるコンピュータコンポーネントの内の幾つか又は全てを含み得る。図３は、一般的に、コンピューティングシステム２００の例示的なコンポーネントと、１つ以上のバス２０４に沿う等したそれらの潜在的な相互接続部又は通信経路とのブロック図を説明している。説明するように、コンピューティングシステム２００は、１つ以上のプロセッサ２０２、１つ以上のバス２０４、メモリ２０６、入力デバイス２０８、電源２１０、ネットワークインターフェース２１２、ユーザインターフェース２１０、及び／又は本明細書に説明する機能を実施するのに有用なその他のコンピュータコンポーネント等の様々なハードウェアコンポーネントを非限定的に含み得る。

１つ以上のプロセッサ２０２は、メモリ２０６内に格納された命令を実施することが可能な１つ以上のマイクロプロセッサを含み得る。追加的又は代替的に、１つ以上のプロセッサ２０２は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、及び／又はメモリ２０６から命令を呼び出すことなく本明細書で論じる機能の内の幾つか又は全てを実施するように設計されたその他のデバイスを含み得る。

その他のコンポーネントに関して、１つ以上のバス２０４は、コンピューティングシステム２００の様々なコンポーネント間にデータ及び／又は電力を提供するための適切な電気チャネルを含む。メモリ２０６は、任意の有形の非一時的でコンピュータ可読のストレージ媒体を含み得る。図１には単一のブロックとして示されているが、メモリ２０６は、１つ以上の物理的な場所に、同じ又は異なるタイプの複数の物理ユニットを使用して実装され得る。入力デバイス２０８は、１つ以上のプロセッサ２０２にデータ及び／又はコマンドを入力するための構造体に対応する。例えば、入力デバイス２０８は、マウス、タッチパッド、タッチスクリーン、及びキーボード等を含み得る。電源２１０は、ライン電源及び／又はバッテリ電源等、コンピューティングデバイス２００の様々なコンポーネントの任意の適した電力源であり得る。ネットワークインターフェース２１２は、１つ以上のネットワーク（例えば、通信チャネル）を介して他のデバイスと通信可能な１つ以上のトランシーバを含む。ネットワークインターフェース２１２は、有線ネットワークインターフェース又は無線ネットワークインターフェースを提供し得る。ユーザインターフェース２１４は、１つ以上のプロセッサ２０２からそれに転送されたテキスト又は画像を表示するように構成されたディスプレイを含み得る。ディスプレイに加えて及び／又は代えて、ユーザインターフェース２１４は、照明（例えば、ＬＥＤ）及びスピーカー等の、ユーザとインターフェースするための他のデバイスを含み得る。

図４に目を向けると、この図は、１つ以上の開示された実施形態に従った、仮想サーバ３００がクライアントインスタンス１０２をサポート及び有効化する実施形態を説明するブロック図である。より具体的には、図４は、上で論じたクラウドベースのプラットフォーム１６を含む、サービスプロバイダのクラウドインフラストラクチャの一部分の例を説明する。クラウドベースのプラットフォーム１６は、（例えば、クライアントデバイス２０のウェブブラウザを介して）クライアントインスタンス１０２内で実行するネットワークアプリケーションへのユーザインターフェースを提供するように、ネットワーク１４を介してクライアントデバイス２０に接続される。クライアントインスタンス１０２は、図２に関して解説したものと同様の仮想サーバ２６によってサポートされ、クライアントインスタンス１０２内の本明細書に説明する開示された機能に対するサポートを示すためにここに説明されている。クラウドプロバイダインフラストラクチャは、一般的に、クライアントデバイス２０等の複数のエンドユーザデバイスを同時にサポートするように構成され、各エンドユーザデバイスは、単一のクライアントインスタンス１０２と通信する。また、クラウドプロバイダインフラストラクチャは、クライアントインスタンス１０２等の任意の数のクライアントインスタンスを同時にサポートするように構成され得、インスタンスの各々は、１つ以上のエンドユーザデバイスと通信する。上述のように、エンドユーザはまた、ウェブブラウザ内で実行されるアプリケーションを使用してクライアントインスタンス１０２とインターフェースし得る。

前述のことを念頭に置いて、本アプローチは、本明細書で説明するようなクラウドプラットフォームのクライアントインスタンスを含むネットワーク環境におけるリクエスト又はその他のネットワークトラフィックをルーティングする、さもなければ管理する使用に適し得る。例として、本アプローチは、そうしたリクエストを処理する幾つかのアプリケーションノード間のリクエスト応答時間及び負荷分散を改善するように、そうしたクラウドプラットフォーム環境においてウェブアプリケーションによりなされるリクエストの負荷分散に有用であり得る。

本アプローチとは対照的に、従来の負荷分散アプローチは、通常、負荷の現在の状態に基づいて動作し、着信トラフィックのポリシーベースのルーティングを実施する。例として、そうしたアプローチは、潜在的に局所的には最適であるが、他の要因を考慮せずに単一の要因又は考慮事項を考慮するのみであることに起因して、より広い（例えば、プラットフォーム全体の）スケールでは最適ではないことがある“グリーディ”アプローチとして特徴付けられるアルゴリズム分類にあるものを用い得る。

このことを念頭に置いて、本アプローチは、他の動的アプローチとは異なり、リアルタイムの方法での使用に適し得る、負荷分散に対する動的プログラミングベースのアプローチを提供する。例として、本アプローチは、プラットフォーム又はより広いスケールでより良い全体的な性能を改善する（“グリーディ”ルーティングアプローチと矛盾するであろう）リクエストの予想される将来の量又はタイプに起因するリクエストへの応答を意図的に遅延させる等の決定をなし得る。

幾つかの実装形態では、定義された幅を有する時間ウィンドウがルーティング決定をなすために用いられる動的ルーティングアプローチが用いられる。この時間ウィンドウは、定義された距離で増分させられ（つまり、スライドし）得、又は定義されたレートでオフセットし得る。このアプローチに従って、適切な確率モデルを使用する等して、所与の時間における時間ウィンドウ（例えば、将来を見据えた時間ウィンドウ）と関連付けられる着信トラフィック（例えば、アプリケーション又はその他のネットワークリクエスト）が予測される。また、機械学習コンテキストで実装され得る線形回帰モデル又はその他の適切な統計モデルを使用する等して、着信リクエストの推定実行時間が計算され得、さもなければ判定され得る。幾つかのそうした実施形態では、様々な要因が考慮され得、又は統計モデル（非限定的に、ユーザ若しくはシステム入力、リクエスト時間、及び／又はサーバ統計等）に入力され得る。組み合わせて、時間ウィンドウ（すなわち、着信トラフィック予測）タスク及び推定実行時間タスクの両方は、そうした動的ルーティングアプローチにより通常使用される追加の先行入力なしにリアルタイムの動的ルーティングを可能にすることを含め、動的ルーティングの性能を改善するために使用され得る。

ネットワーク又はリクエストトラフィック（本明細書では幾つかの箇所で“イベント”と称される）の予測に関連する第１のタスクに関して、所与の時間ウィンドウ内のトラフィック予測は、個別の時間ウィンドウ内の所与のタイプのトラフィックに対する予測分布を提供する（例えば、複数のタイプのリクエスト又はイベントが所与の時間、モデル化され得る）適切な確率分布モデル（例えば、ポアソン、ガウス分布、又はその他の適切な確率分布ベース）によって表され得る。例として、着信トラフィックをモデル化するためにポアソン分布が使用される実装のコンテキストでは、特定の負荷タイプの着信ネットワークトラフィックの確率モデルは、定義された、さもなければ既知のレートで既知の増分又はオフセットを進める固定幅を有する所与の時間ウィンドウに対して計算される。

そうした一時間ウィンドウの実装の一例は、解説を容易にするために図５に示されている。描写する例では、１０秒の幅（δ）３２２を有するウィンドウ３２０は、５秒毎に５秒刻み（ε）３２４で移動させられる（概念的には、ウィンドウ３２０は、時間の経過と共に移動させられている単一のウィンドウ３２０、又は時間の経過と共に相互に時間的にオフセットされて生成されている一連のウィンドウ３２０とみなされ得る）。時間の経過は、図の上部に沿って説明されるタイムライン（秒単位）によって伝えられる。

本コンテキストにおいて、ウィンドウ３２０は、タイムラインに沿った異なる時間におけるトラフィック（例えば、予測されるイベント又はリクエスト）を推定又は予測する目的で、確率分布と関連付けられる。このコンテキストにおいて、関連するパラメータ化された確率分布に基づいた各ウィンドウ３２６は、対象の時間枠内のトラフィック（例えば、アプリケーションリクエスト）の推定としてタイムラインにマッピングされ得る個別の対応する時間間隔に対する、予測されるイベント又はリクエスト３２６のセットを確率的に推定するために使用され得る。

例として、特定の負荷タイプの着信トラフィックが所与のウィンドウ３２０に対して確率的に計算されるように、将来のネットワークトラフィックを予測するためにポアソン分布が用いられ得る。これは、

として表され得、ｌは所与の負荷タイプ（例えば、リクエスト）に対応し、λ_ｔｌは時間間隔ｔで到来するｌタイプのリクエスト又はイベントの平均数である。したがって、式（１）に従って、所与の時間間隔におけるｋ（例えば、１、２、３、・・・、ｎ）個のイベントの確率が与えられる。

これを念頭に置いて、図６に目を向けると、幾つかの実施形態では、ウィンドウ幅δ３４２及び増分又はオフセット３４０εは、ネットワークトラフィックの予測に用いられる時間ウィンドウ３２０を生成、さもなければ判定する（ステップ３４４）ために選択される。ウィンドウ幅δ３４２は、問題のネットワークトラフィックタイプ（すなわち、負荷タイプ３５０）を確率的にモデル化するために（又はより一般的に、１つ以上の確率分布３６０をパラメータ化する（ステップ３５２）ために使用される）ポアソン分布を用いる実装におけるポアソン分布式の時間間隔として最初に使用され得る。対象となる負荷タイプｌ３５０（例えば、幾つかの実装では、小リクエスト、中リクエスト、及び大リクエスト等として一般化及び／又はビニングされ得る、異なるタイプのデータ、クエリ、又はその他の相互作用に対応するリクエスト）毎に、ポアソン式は、時間間隔δ３４２に対して別個に適用される。異なる負荷タイプ（例えば、小、中、及び大）は、異なる確率を各々有し得る。上記の定式化におけるｋの値は、（確率が評価されているウィンドウ３２０内のイベントの数を表す）１からｎまでその後変更され得、個別のウィンドウ３２０内の所与の各負荷タイプｌのイベントの最も可能性の高い数を判定するために最大確率が計算される。動的計画法のコンテキストでの使用に適したもの等のビンパッキングルーチンは、この方法で計算され、時間間隔ｔで到来するｌタイプのリクエスト又はイベントの平均数に対応するλ_ｔｌに対する値に基づいて優先度ツリー３６４（例えば、仮想優先度キュー）を計算する（ステップ３６２）ために使用され得る。そうしたアプローチに従うと、優先度ツリー３６４は、予測されるネットワークトラフィック（例えば、アプリケーションリクエスト）の予想される到着時間を有する仮想ノードから構成される。各ノードは、リソースが割り当てられ得るアプリケーションリソース（例えば、アプリケーションノード）及びノードが割り当てられるべき順序（すなわち、優先度）に対応し得る。

図７に目を向けると、本アプローチの態様を更に解説するために、リクエストキュー３８０と組み合わせたそうした優先度ツリー３６４の使用例が説明されている。以下の論考に関して理解され得るように、１つ以上のロードバランサ２８（図１）に到来する実際のネットワークトラフィックは、クラウドプラットフォームに渡って改善されたルーティング性能を達成するために、本アプローチに従って割り当てられ得、ルーティングされ得る。

この例では、優先度ツリー３６４は、最初に、仮想ノード３７０の階層からなり、各々は、本明細書で論じられるように、スライディングウィンドウ３２０及び関連する確率分布を考慮して判定されるように、リクエストが予想される負荷タイプリクエストｌ及び時間ｔ（すなわち、Ｉ_ｌｔ）によって定義される。モデル化された負荷タイプｌの実際のネットワークトラフィックが時間ｔ（すなわち、Ｔ_ｌｔ）にロードバランサに到来すると、それは、時間ｔ及び負荷タイプｌに関して最も近い仮想ノードに一致され、実際のトラフィックイベント（例えば、リクエスト）は、関連付けられたリソース（例えば、アプリケーションノード）にルーティングされる。一致した仮想ノードは、以前に仮定又は予測された（すなわち、見込みの）タスクであったものへの実際のタスク（例えば、リクエスト）の割り当てを指し示す実際のノードと、ツリー内で置き換えられる。したがって、時間が経過するにつれて、優先度ツリー３６４のノード３７０は、着信する実際のタスクによって“満たされる”。タスクがタイムリーな方法で到来しない（すなわち、満たされない）それらのノード３７０は、それらの関連する時間が経過し、増分させられた時間ウィンドウと関連付けられた新たな予測トラフィックに基づいて（すなわち、問題の時間ｔでのタスクｌに対するウィンドウ３２０と関連付けられた確率分布に基づいて）優先度キュー又はツリーが時間的に前方に延長される場合に、優先度キューからドロップ又はプルーニングされる。例えば、優先度キュー又はツリー３６４は、ウィンドウ３２０が時間の経過と共に移動させられる同じ増分εで（失効した未割り当てのノード３７０を除去し、予測されたトラフィックに基づいて新たなノードを追加して）増分させられ得る。

所与のモデルは、期限切れした（すなわち、実際のトラフィックリクエスト又はイベントに一致しない）ノード３７０の数に基づいて、有効性及び効率について評価され得る。したがって、ウィンドウ３２０のパラメータ化、所与のタスクタイプｌ及び／若しくは時間ｔに用いられる確率分布のパラメータ化、並びに／又は確率分布のタイプ（例えば、ポアソン、ガウス、及び均一等）は、期限切れのノード３７０を最小化するために、時間の経過と共に調整され得る。このようにして、プラットフォームに渡るトラフィックルーティングは、動的な方法で改善され得る。

上で説明した特定の実施形態は例として示され、これらの実施形態は、様々な修正及び代替形態の影響を受けやすいことがあることを理解すべきである。特許請求の範囲は、開示された特定の形態に限定されることを意図せず、むしろ、この開示の精神及び範囲内にある全ての修正物、均等物、及び代替物をカバーすることを意図することを更に理解すべきである。

本明細書で提示及び請求される技法は、本技術分野を明らかに改善し、したがって、抽象的、無形的、又は純粋に理論的ではない実践的性質の有形物及び具体例に言及及び適用される。更に、この明細書の末尾に添付された何れかの請求項が“・・・[機能を]［実施］するための手段”又は“・・・[機能を]［実施］するためのステップ”として指定された１つ以上の要素を含む場合、そうした要素は３５Ｕ．Ｓ．Ｃ１１２（ｆ）の下で解釈されるべきであることを意図する。しかしながら、任意の他の何れかの方法で指定された要素を含む何れかの請求項に対しては、そうした要素は３５Ｕ．Ｓ．Ｃ．１１２（ｆ）の下で解釈されるべきではないことを意図する。

Claims (20)

1. 複数のアプリケーションサーバを含むデータセンタと、
   複数のクライアントデバイスを含むクライアントネットワークであって、前記複数のクライアントデバイスは、前記アプリケーションサーバによって処理されるリクエストを生成する、前記クライアントネットワークと、
   前記リクエストが前記クライアントネットワークと前記データセンタとの間をそれを介して移動するネットワークと、
   予測されたネットワークイベントに基づいた優先度ツリーを使用して前記アプリケーションサーバ間で前記リクエストをルーティングするように構成された１つ以上のロードバランサと
   を含み、前記１つ以上のロードバランサは、
   時間間隔に対応する幅を有する時間ウィンドウを生成することと、
   一連の将来の時間を通して前記時間ウィンドウを段階的に移動させることと、
   前記一連の将来の時間毎に、前記時間ウィンドウに含まれる前記時間間隔内の個別の前記将来の時間における個別のリクエストタイプの予想されるリクエストの最も可能性の高い数を判定するために、前記時間ウィンドウに確率モデルを適用することと、
   前記一連の将来の時間毎の前記個別のリクエストタイプの予想されるリクエストの前記最も可能性の高い数に基づいて、予想されるリクエスト及び予想されるリクエストタイプに対応するノードを含む優先度ツリーを生成することと、
   前記ロードバランサにおいて受信したリクエストを前記優先度ツリーの個別のノードに割り当てることと、
   前記個別のノードへの個別のリクエストの前記割り当てに基づいて、前記個別のリクエストを個別のアプリケーションサーバにルーティングすること
   を含む動作を実施することによって前記優先度ツリーを生成及び使用する、
   クラウドプラットフォーム。
2. 前記クライアントネットワークは、クライアントインスタンスの一部として前記ネットワークを介して前記データセンタと相互作用する、請求項１に記載のクラウドプラットフォーム。
3. 前記確率モデルは、ポアソン確率分布又はガウス確率分布の内の１つを含む、請求項１に記載のクラウドプラットフォーム。
4. 前記リクエストタイプは、前記クライアントデバイスによって生成されたリクエストと関連付けられた異なるタイプのデータ又はクエリに対応する、請求項１に記載のクラウドプラットフォーム。
5. 前記優先度ツリーは、リクエストがいつ到来すると予想されるかに基づいた、時間的に順序付けられたノードのセットを含む、請求項１に記載のクラウドプラットフォーム。
6. 前記１つ以上のロードバランサは、
   前記個別のノードと関連付けられた時間が経過した後に、対応する要求が受信されなかったノードを削除するように、前記優先度ツリーを更新すること
   を含む動作を更に実施する、請求項１に記載のクラウドプラットフォーム。
7. 前記１つ以上のロードバランサは、
   前記時間ウィンドウが前記一連の将来の時間を通って移動するときにノードを追加するように前記優先度ツリーを更新すること
   を含む動作を更に実施する、請求項１に記載のクラウドプラットフォーム。
8. 個別のノードにリクエストを割り当てることは、前記個別のリクエストの到来時間リクエストタイプの内の一方又は両方に基づく、請求項１に記載のクラウドプラットフォーム。
9. 時間ウィンドウを指定された時間増分で時間的に前方に移動させることであって、前記時間ウィンドウは、時間間隔に対応する幅を有することと、
   前記時間ウィンドウが時間的に前方に移動させられるとき、前記時間ウィンドウが移動させられる個別の時間増分に対応する時間毎に１つ以上のリクエストタイプの各々に対してリクエストの予想数を判定することと、
   異なる将来の時間における１つ以上のリクエストタイプの各々に対するリクエストの前記予想数に基づいてノードを含む優先度ツリーを生成することであって、各ノードは、将来の時間における個別のリクエストタイプの予想されるリクエストに対応することと、
   リクエストが受信されるとき、各リクエストを前記優先度ツリーの個別のノードに割り当てることであって、個別のリクエストの割り当ては、前記個別のノードと関連付けられたネットワークリソースにルーティングされる前記個別のリクエストに対応すること
   の動作を含む、ネットワーク上のリクエストを分散するための方法。
10. 前記ネットワークは、クラウドプラットフォーム上のクライアントインスタンスの一部である、請求項９に記載の方法。
11. 時間毎に１つ以上のリクエストタイプの各々に対してリクエストの前記予想数を判定することは、確率モデルを時間毎に前記時間ウィンドウに適用することを含む、請求項９に記載の方法。
12. 前記確率モデルは、ポアソン確率分布又はガウス確率分布の内の１つを含む、請求項１１に記載の方法。
13. 前記１つ以上のリクエストタイプは、異なるタイプのデータに対する、又は前記ネットワーク上のクライアントデバイスにより異なるクエリ毎に生成されるリクエストを含む、請求項９に記載の方法。
14. 前記優先度ツリーは、リクエストがいつ到来すると予想されるかに基づいた、時間的に順序付けられたノードのセットを含む、請求項９に記載の方法。
15. 前記時間ウィンドウが時間的に前方に移動せられるときに前記優先度ツリーを更新することを更に含む、請求項９に記載の方法。
16. 格納されたルーチンを実行するように構成された処理コンポーネントと、
    実行可能ルーチンを格納するように構成されたメモリコンポーネントであって、前記実行可能ルーチンは、前記処理コンポーネントによって実行される場合に、
    時間ウィンドウを指定された時間増分で時間的に前方に移動させることであって、前記時間ウィンドウは、時間間隔に対応する幅を有することと、
    前記時間ウィンドウが時間的に前方に移動させられるとき、前記時間ウィンドウが移動させられる個別の時間増分に対応する時間毎に１つ以上のリクエストタイプの各々に対してリクエストの予想数を判定することと、
    異なる将来の時間における１つ以上のリクエストタイプの各々に対するリクエストの前記予想数に基づいて、ノードを含む優先度ツリーを生成することであって、各ノードは、将来の時間における個別のリクエストタイプの予想されるリクエストに対応することと、
    リクエストが受信されるとき、各リクエストを前記優先度ツリーの個別のノードに割り当てることであって、個別のリクエストの割り当ては、前記個別のノードと関連付けられたネットワークリソースにルーティングされる前記個別のリクエストに対応すること
    を含む動作を前記処理コンポーネントに実施させる、前記メモリコンポーネントと
    を含む、ロードバランサ。
17. 前記ロードバランサは、クライアントインスタンス内の複数のクライアントデバイスから前記クライアントインスタンス内の複数のアプリケーションサーバにリクエストをルーティングするように構成される、請求項１６に記載のロードバランサ。
18. 時間毎に１つ以上のリクエストタイプの各々に対してリクエストの前記予想数を判定することは、確率モデルを時間毎に前記時間ウィンドウに適用することを含む、請求項１６に記載のロードバランサ。
19. 前記確率モデルは、ポアソン確率分布又はガウス確率分布の内の１つを含む、請求項１８に記載のロードバランサ。
20. 前記実行可能ルーチンは、前記処理コンポーネントによって実行される場合に、
    前記時間ウィンドウが時間的に前方に移動させられるとき、前記優先度ツリーを更新すること
    を含む動作を前記処理コンポーネントに更に実施させる、請求項１６に記載のロードバランサ。

Images