JP4502815B2 - トラフィック・パターン認識に基づくＷｅｂサイト・トラフィックのコロケーションおよびオフロードのための装置および方法 - Google Patents

Description

本発明は、トラフィック・パターン認識に基づくＷｅｂサイト・トラフィックのコロケーション（co-location）およびオフロードのための装置および方法を対象とする。より具体的には、本発明は、Ｗｅｂサイトのプロファイルを作成し、どのＷｅｂサイトをコロケーションしなければならないかならびに他のサーバへのＷｅｂトラフィックのオフロードをいつ実行しなければならないかを判別するための装置および方法を対象とする。

インターネットおよびそのアプリケーションの人気の増大により、サービス品質（ＱｏＳ：Quality of Service）を提供するためのリソースの割振りはより困難になっている。リソース割振りの問題の複雑さは、インターネット・インフラストラクチャおよびアプリケーションの異種性ならびにユーザの振る舞いによって悪化している。

リソース割振り問題に対する手法の１つは、他のエンティティからリソースを借りることによって任意の所与のエンティティに関するピーク負荷条件を処理できるように、Ｗｅｂサイトなどの複数のエンティティ間でＷｅｂサーバなどのリソースを共用することである。このようなメカニズムは往々にしてコロケーションと呼ばれる。このパラダイムにおける重要な問題は、リソース共用のためのＷｅｂサイトのクラスタ化に関係がある。すなわち、どのＷｅｂサイトがリソースを共用しなければならないかを識別することは、困難かつ不正確な手動プロセスである場合が多い。

もう１つの手法は、コロケーションに対する補足的なものであり、あるエンティティ用の作業を外部リソース（exogenous resources）に動的にオフロードすることからなる。オフロードにより、現在、過負荷状態になっている特定のＷｅｂサーバ向けのＷｅｂサイト・トラフィックは、そのトラフィックの処理を扱うために他のサーバにリダイレクトされる。オフロードの重要な問題は、作業をオフロードする場所と時期を決定することである。作業をオフロードする場所と時期を決定するための既知のメカニズムは概して、作業の一部を他のサーバに送ることによりワークロードのバランスを取らなければならないかどうかを判別するために現在の状態情報を使用する、ロード・バランシングの分野に該当する。このようなワークロード・バランシング・メカニズムは、反応性（reactionary）のものであり、サーバが過負荷になる前にオフロードを開始するために既知のトラフィック・パターンを使用しない。

したがって、どのＷｅｂサイトをコロケーションしなければならないかならびにＷｅｂサイトへのトラフィックをいつ他のＷｅｂサーバにオフロードしなければならないかを判別するための改良された装置および方法を有することは有益になるであろう。
１９８４年にＳｐｒｉｎｇｅｒ−Ｖｅｒｌａｇから発行され、Ａｕｓｉｅｌｌｏ、Ｌｕｃｅｒｔｉｎｉ、およびＳｅｒａｆｉｎｉによって編集されたＡｌｇｏｒｉｔｈｍ Ｄｅｓｉｇｎ ｆｏｒ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎに掲載されたＥ． Ｇ． Ｃｏｆｆｍａｎ， Ｊｒ．他の「Ａｐｐｒｏｘｉｍａｔｉｏｎ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｂｉｎ−Ｐａｃｋｉｎｇ −− Ａｎ Ｕｐｄａｔｅｄ Ｓｕｒｖｅｙ」 １９７４年にＪｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｓｙｓｔｅｍ Ｓｃｉｅｎｃｅｓ ８の２７２〜３１４ページに掲載されたＤａｖｉｄ Ｓ． Ｊｏｈｎｓｏｎによる「Ｆａｓｔ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｂｉｎ Ｐａｃｋｉｎｇ」 １９９４年にＩＭＳ Ｌｅｃｔｕｒｅ Ｎｏｔｅｓ − Ｍｏｎｏｇｒａｐｈ Ｓｅｒｉｅｓ、ｖｏｌ．２３に掲載されたＣａｒｌｓｔｅｉｎ他による「Ｃｈａｎｇｅ−Ｐｏｉｎｔ Ｐｒｏｂｌｅｍｓ」

本発明は、Ｗｅｂサイトへのトラフィックの到着を特徴付けるテンプレートに基づいて、Ｗｅｂサイトへのトラフィック・パターンを識別するための装置および方法を提供する。これらのテンプレートに基づいて、リソース割振りを最適化するために、どのＷｅｂサイトをコロケーションしなければならないかに関する判別が行われる。具体的には、そのテンプレートが補足的なものである、すなわち、第１のＷｅｂサイトが時間ｔ１で到着トラフィックのピークを有し、第２のＷｅｂサイトが時間ｔ１で到着トラフィックのトラフを有するＷｅｂサイトがコロケーション用の候補として指定される。

加えて、本発明は、トラフィックを他のサーバにオフロードするためのしきい値を決定するために、Ｗｅｂサイトのトラフィック・パターンについて識別されたテンプレートを使用する。これらのしきい値は、オフロードを実行しなければならない第１のしきい値と、オフロードを開始するために必要な進み時間（lead time）を考慮する第２のしきい値と、他のサーバへのトラフィックのオフロードをすべて停止するために必要な遅れ時間（lag time）を考慮する第３のしきい値とを含む。

本発明の上記その他の特徴および利点は、以下の好ましい実施形態の詳細な説明に記載されるか、または以下の好ましい実施形態の詳細な説明を考慮して当業者にとって明らかなものになるであろう。

本発明の好ましい実施形態は分散データ処理環境で実現され、その環境ではトラフィック・データがコンパイルされ、Ｗｅｂサイトのプロファイル作成、クラスタ化、およびカテゴリ化に使用される。本発明は分散データ処理環境で実現されるので、本発明が機能するコンテキストを提供するために、まず、この環境の簡単な説明を提供する。

次に図面に関して説明すると、図１は、本発明を実現可能なデータ処理システムのネットワークの図表現を図示している。ネットワーク・データ処理システム１００は、本発明を実現可能なコンピュータのネットワークである。ネットワーク・データ処理システム１００はネットワーク１０２を含み、このネットワークは、ネットワーク・データ処理システム１００内に一緒に接続された様々なデバイスおよびコンピュータ間の通信リンクを提供するために使用されるメディアである。ネットワーク１０２は、ワイヤ、ワイヤレス通信リンク、または光ファイバ・ケーブルなどの接続部を含むことができる。

図示した例では、サーバ１０４は、ストレージ・ユニット１０６とともにネットワーク１０２に接続されている。加えて、クライアント１０８、１１０、および１１２はネットワーク１０２に接続されている。これらのクライアント１０８、１１０、および１１２は、たとえば、パーソナル・コンピュータまたはネットワーク・コンピュータにすることができる。図示した例では、サーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータをクライアント１０８〜１１２に提供する。クライアント１０８、１１０、および１１２はサーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、図示していない追加のサーバ、クライアント、およびその他のデバイスを含むことができる。

図示した例では、ネットワーク・データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ：Transmission Control Protocol/Internet Protocol）というプロトコル・スイートを使用して互いに通信するネットワークとゲートウェイの世界的な集合を表すネットワーク１０２を備えたインターネットである。インターネットの中心には、データおよびメッセージを経路指定する何千もの商用、官用、教育用、およびその他のコンピュータ・システムからなる、メジャー・ノードまたはホスト・コンピュータ間の高速データ通信回線のバックボーンがある。当然のことながら、ネットワーク・データ処理システム１００は、たとえば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）、または広域ネットワーク（ＷＡＮ：wide area network）など、いくつかの異なるタイプのネットワークとして実現することもできる。図１は、一例としてのものであり、本発明に関するアーキテクチャ上の制限としてのものではない。

図２を参照すると、図１のサーバ１０４などのサーバとして実現可能なデータ処理システムのブロック図が本発明の好ましい実施形態により図示されている。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２および２０４を含む対称型マルチプロセッサ（ＳＭＰ：symmetric multiprocessor）システムにすることができる。代わって、シングル・プロセッサ・システムを使用することもできる。また、システム・バス２０６には、ローカル・メモリ２０９へのインターフェースを提供するメモリ・コントローラ／キャッシュ２０８も接続されている。入出力バス・ブリッジ２１０は、システム・バス２０６に接続され、入出力バス２１２へのインターフェースを提供する。メモリ・コントローラ／キャッシュ２０８と入出力バス・ブリッジ２１０は、図示した通り、統合することができる。

入出力バス２１２に接続された周辺装置相互接続（ＰＣＩ：peripheral component interconnect）バス・ブリッジ２１４は、ＰＣＩローカル・バス２１６へのインターフェースを提供する。ＰＣＩローカル・バス２１６には、いくつかのモデムを接続することができる。典型的なＰＣＩバス実現例は、４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートすることになる。図１のクライアント１０８〜１１２への通信リンクは、アドイン・ボードによりＰＣＩローカル・バス２１６に接続されたモデム２１８およびネットワーク・アダプタ２２０により提供することができる。

追加のＰＣＩバス・ブリッジ２２２および２２４は追加のＰＣＩローカル・バス２２６および２２８用のインターフェースを提供し、それにより追加のモデムまたはネットワーク・アダプタをサポートすることができる。このように、データ処理システム２００は複数のネットワーク・コンピュータへの接続を可能にする。また、入力バス２１２には、図示した通り、直接または間接に、メモリマップ・グラフィックス・アダプタ２３０およびハード・ディスク２３２も接続することができる。

当業者であれば、図２に図示したハードウェアが変化する可能性があることが分かるであろう。たとえば、図示したハードウェアに加えてまたはその代わりに、光ディスク・ドライブなどの他の周辺装置も使用することができる。図示した例は、本発明に関するアーキテクチャ上の制限を示すものではない。

図２に図示したデータ処理システムは、たとえば、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ社の製品であり、拡張対話式エグゼクティブ（ＡＩＸ：Advanced Interactive Executive）オペレーティング・システムまたはＬＩＮＵＸオペレーティング・システムを実行するＩＢＭ ｅＳｅｒｖｅｒ ｐＳｅｒｉｅｓシステムにすることができる。

次に図３に関して説明すると、本発明を実現可能なデータ処理システムを示すブロック図が図示されている。データ処理システム３００はクライアント・コンピュータの一例である。データ処理システム３００は、周辺装置相互接続（ＰＣＩ）ローカル・バス・アーキテクチャを使用する。図示した例はＰＣＩバスを使用しているが、アクセラレイテッド・グラフィックス・ポート（ＡＧＰ：Accelerated Graphics Port）およびインダストリー・スタンダード・アーキテクチャ（ＩＳＡ：Industry Standard Architecture）などの他のバス・アーキテクチャを使用することもできる。

プロセッサ３０２およびメイン・メモリ３０４は、ＰＣＩブリッジ３０８によりＰＣＩローカル・バス３０６に接続されている。また、ＰＣＩブリッジ３０８は、プロセッサ３０２用の統合メモリ・コントローラおよびキャッシュ・メモリも含むことができる。ＰＣＩローカル・バス３０６への追加の接続は、直接コンポーネント相互接続によるかまたはアドイン・ボードにより行うことができる。図示した例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホスト・バス・アダプタ３１２、および拡張バス・インターフェース３１４は直接コンポーネント接続によりＰＣＩローカル・バス３０６に接続されている。対照的に、オーディオ・アダプタ３１６、グラフィックス・アダプタ３１８、およびオーディオ／ビデオ・アダプタ３１９は、拡張スロットに挿入されたアドイン・ボードによりＰＣＩローカル・バス３０６に接続されている。拡張バス・インターフェース３１４は、キーボードおよびマウス・アダプタ３２０、モデム３２２、および追加のメモリ３２４用の接続部を提供する。小型コンピュータ・システム・インターフェース（ＳＣＳＩ：small computer system interface）ホスト・バス・アダプタ３１２は、ハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、およびＣＤ−ＲＯＭドライブ３３０用の接続部を提供する。典型的なＰＣＩローカル・バス実現例は、３つまたは４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートすることになる。

オペレーティング・システムは、プロセッサ３０２上で実行され、図３のデータ処理システム３００内の様々なコンポーネントを調整し制御するために使用される。オペレーティング・システムは、マイクロソフト社から入手可能なＷｉｎｄｏｗｓＸＰなどの市販のオペレーティング・システムにすることができる。Ｊａｖａなどのオブジェクト指向プログラミング・システムは、オペレーティング・システムに併せて実行し、データ処理システム３００上で実行されるＪａｖａプログラムまたはアプリケーションからオペレーティング・システムへの呼出しを提供することができる。「Ｊａｖａ」はサン・マイクロシステムズ社の商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、およびアプリケーションまたはプログラムに関する命令は、ハード・ディスク・ドライブ３２６などのストレージ・デバイス上に位置し、プロセッサ３０２による実行のためにメイン・メモリ３０４にロードすることができる。

当業者であれば、図３に図示したハードウェアが実現例に応じて変化する可能性があることが分かるであろう。図３に図示したハードウェアに加えてまたはその代わりに、フラッシュ読取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、または光ディスク・ドライブなどのその他の内部ハードウェアまたは周辺装置を使用することができる。また、本発明のプロセスは、マルチプロセッサ・データ処理システムに適用することもできる。

他の例として、データ処理システム３００は、何らかのタイプのネットワーク通信インターフェースを当てにせずにブート可能になるように構成されるスタンドアロン・システムにすることができる。さらに他の例として、データ処理システム３００は、オペレーティング・システム・ファイルあるいはユーザ生成データまたはその両方を保管するための不揮発性メモリを提供するために、ＲＯＭあるいはフラッシュＲＯＭまたはその両方とともに構成される、携帯情報端末（ＰＤＡ：personal digital assistant）装置にすることができる。

図３に図示した例および上述の例は、アーキテクチャ上の制限を示すものではない。たとえば、データ処理システム３００は、ＰＤＡの形を取ることに加えて、ノートブック・コンピュータまたはハンドヘルド・コンピュータにすることもできる。また、データ処理システム３００は、キオスクまたはＷｅｂアプライアンスにすることもできる。

前述の通り、本発明は、Ｗｅｂサイトをカテゴリ化するためのメカニズムを提供する。このようなカテゴリ化は、ワークロードの特徴付け、パフォーマンスのモデル化、ワークロードおよびパフォーマンスの予測、キャパシティ・プランニングなどで使用するためのサポート機能である。基本的に、これらの様々な機能のそれぞれは、リソース使用状況を最適化し、所定のレベルのサービスをクライアント・デバイスに与えるためにＷｅｂサイトが経験するトラフィックを処理するために使用可能なリソースが十分あることを確認することを対象とする。本発明によるＷｅｂサイトのカテゴリ化は、上記のその他の機能で使用するためのＷｅｂサイトの正確なモデル化を保証するための重要なサポート機能になる可能性がある。

本発明の基本部分は、ワークロードの特徴付け、パフォーマンスのモデル化、ワークロードおよびパフォーマンスの予測、およびキャパシティ・プランニングの問題の解決を支援するために活用可能なトラフィック特性のパターンをＷｅｂサイトが反復しているという発見である。これらのパターンは、ヒット数、バイト数、ページ・ビュー数、アクセス数、アクセスあたりのヒット数、アクセスあたりのページ・ビュー数、ページ・ビューあたりの秒数、アクセスあたりの秒数など、様々な異なる尺度について存在する可能性がある。その上、これらのパターンは、月次、週次、日次、毎時などを含む様々な時間目盛りについて存在する可能性がある。トラフィック特性の反復パターンを例証するために、複数の例示的な商用Ｗｅｂサイトに関し１週間の時間間隔の間の１時間あたりのヒット数について考慮する。

図４〜６は、例示的な商用Ｗｅｂサイトに関し１週間という期間の間の毎時ヒット数の例示的な図である。図４〜６に示したプロットでは、曜日ごとのクライアント・デバイスからの着信要求パターンを特徴付けるために、１時間あたりのヒット数という尺度が使用されている。

図４〜６により分かるように、他の曜日に対して土曜日と日曜日に要求レート（ヒット数とページ数の両方）の大幅な低下が発生する日次アクセス・パターンを多数のＷｅｂサイトが示している。種々の業界にわたるＷｅｂサイトのいくつかでは往々にして、図４および図５の１番目のプロット４１０、３番目のプロット４２０、９番目のプロット４３０、および１１番目のプロット４４０に図示した通り、明確な週末パターンを有し、週末に要求レートの著しい低下が発生している。４５０などのその他のＷｅｂサイトでは、より弱いが依然として優勢な週末パターンを有し、週末における要求レートの低下はそれほど著しくない。４６０などのさらに他のＷｅｂサイトでは、いかなる週末パターンも示していない。

種々の時間目盛り、たとえば、日次、週次、月次に関するトラフィック・データならびに要求パターンのその他の尺度、たとえば、バイト数、ページ・ビュー数、アクセス数、アクセスあたりのヒット数などに関するトラフィック・データでは、同様のパターンが優勢である。図７〜９は、様々な尺度に関し図４〜６の例示的な商用Ｗｅｂサイトのいくつかの日次時系列プロットの例示的な図である。図７〜９により、これらの他の尺度でもＷｅｂサイトについて程度が変化する週末効果が存在することが分かる。また、週末パターンを有する特定のＷｅｂサイトでは、要求尺度が１週間ごとにあまり変化しない、非常に一貫性のある週単位の振る舞いも示している。

要するに、図４〜６および図７〜９に示した経験データにより、多くのＷｅｂサイトがそれぞれのトラフィック・パターンを経験することは明確なことである。上記の経験特性に加えて、Ｗｅｂサイトのトラフィックについて種々の時間目盛りでユーザ要求パターンの最も複雑な特性のいくつかを識別し検査するために、様々な統計尺度を使用することができる。このような特性としては、たとえば、トラフィック変動性およびピーク対平均比を含み、これらはあまり目立たず、時系列データから計算できるだけである。

要求時系列の変動性のいくつかの有用な態様は、要求ボリューム全体の変動係数（ＣＶ：coefficient of variation）、すなわち、平均に対する標準偏差の比率によって検査することができる。たとえば、図１０は、例示的な商用Ｗｅｂサイトで発生する種々の尺度に関する日次平均の関数として示す、これらの尺度の日次変動係数の例示的な図である。図１０により、ある尺度（たとえば、日次アクセス数プロット６１０）では、種々のサイトが示す変動性はまったく異なるが日次平均は同様であり、他の尺度（たとえば、アクセスあたりの日次ページ・ビュー数６２０）では、種々のサイトが示す変動性は同様であるが日次平均は異なることが分かる。

要求パターンのバースト性（burstiness）に関するおおざっぱな尺度の１つは、特定の時間間隔の間のピーク対平均要求レートの比率である。この尺度は、平均要求ボリュームに対するピーク要求ボリュームを定量化するものである。図１１は、例示的な商用Ｗｅｂサイトで発生する種々の尺度に関する日次平均の関数として示す、これらの尺度の日次ピーク対平均比の例示的な図である。図１１により、図１０と同様の振る舞いが観察され、すなわち、様々な尺度の統計特性が異なると非常に異なる結果が得られる。

したがって、上記の経験および統計データ分析の結果は、Ｗｅｂサイトがそれぞれのトラフィック・パターンを経験することを明確に示しているが、これらの結果のほとんどは、クラスタ化、プロファイル作成、および分類のための基礎として、単独では容易に活用可能ではない。本発明は、ワークロードの特徴付け、パフォーマンスのモデル化、ワークロードおよびパフォーマンスの予測、およびキャパシティ・プランニングで使用するためのＷｅｂサイトの正確なモデルを生成するために、これらのトラフィック・パターンを活用するためのメカニズムを提供する。

本発明は、Ｗｅｂサイトのクラスタ化、プロファイル作成、および特徴付けという３つの基本コンポーネントに分割することができる。Ｗｅｂサイトを特徴付ける第１のステップは、これらのＷｅｂサイトについて入手したトラフィック・データに基づいてＷｅｂサイトのクラスタを生成することである。クラスタを識別すると、各クラスタまたはクラスのプロファイルを作成して、そのクラス用のテンプレートを入手する。その後、あるＷｅｂサイトについて新しいトラフィック・データを入手すると、そのＷｅｂサイトを既知のクラスの１つにカテゴリ化するために、クラスについて確立されたテンプレートに照らし合わせてそのトラフィック・データを比較することができる。代わって、その比較の結果として、そのＷｅｂサイトが既知のクラスのいずれとも十分異なる場合、そのＷｅｂサイトのトラフィック・データを使用して、新しいクラスを生成することができる。次に、そのＷｅｂサイトについて使用可能なリソースを最適化するために、この分類を使用して、ワークロードの特徴付け、パフォーマンスのモデル化、ワークロードおよびパフォーマンスの予測、およびキャパシティ・プランニングなどの機能を実行することができる。

前述の通り、本発明の動作における第１のステップは、複数のＷｅｂサイトからトラフィック・データを入手し、そのトラフィック・データに基づいてＷｅｂサイトをクラスタ化することである。クラスタ化は、Ｗｅｂサイトをクラスタ化するために使用すべきトラフィック・データの尺度を選択することと、次にＷｅｂサイトのそれぞれについて、この選択した尺度に関してトラフィック・データのテンプレートを識別することを含む。次に、所与の許容範囲内で互いに最も似ている複数テンプレートのグループを識別するクラスタ化アルゴリズムを使用して、テンプレートをクラスタ化する。これらのグループまたはクラスは、プロファイル作成および分類を実行するために使用することになるＷｅｂサイトのクラスタである。

前述の通り、クラスタ化を実行するために使用されるトラフィック・データの特定の尺度は、クラスタ化を実行する前に選択しなければならない。使用する尺度データのサブセットに応じて、異なるクラスタ化結果を入手することができる。たとえば、ロード／要求パターン、ユーザ・ナビゲーション・パターン、サイト・ハイパーテキスト構造などに応じて、Ｗｅｂサイトをクラスタ化することができる。これらのクラスタ化はそれぞれ異なり、互いに直交するものと見なすことができる。本発明により実行される特定のクラスタ化は、本発明の特定の実現例および本発明のユーザにとって最も重要である尺度に基づいて選択することができる。

本発明の例示的な一実施形態では、ロード・パターンに応じてクラスタ化が実行される。このため、着信要求トラフィック・パターンを特徴付けるための代表的なトラフィック・データとして、１時間あたりのヒット数を使用する。図１２は、この例示的な実施形態により、Ｗｅｂサイトをクラスタ化する際に使用するための例示的な商用Ｗｅｂサイトから収集した１日の間の１時間あたりの要求数を示す例示的な図である。

クラスタ化を実行するために使用すべきトラフィック・データの尺度を選択すると、次にトラフィック・データを分析して、この選択した尺度に関してトラフィック・データのテンプレートまたは典型的な形状を識別する。このテンプレートは本質的に、選択した尺度に関する時系列データ値または選択した尺度に関するこの時系列データ値の関数である。

本発明のこの例示的な実施形態では、あるＷｅｂサーバで発生する毎時要求パターン・プロファイルの加重平均を表す加重平均要求パターンｌ_i（ｈ）をそのＷｅｂサイト用のテンプレートとして使用する。加重平均要求パターンｌ_i（ｈ）は以下の式を使用して求める。

式中、ｘ_i（ｈ，ｄ）は、ｉ番目のＷｅｂサーバがｄ日のｈ時に受信する経験データからの要求の数を示し、ｈ＝０，１，・・・，ｎであり、重みａ_i（ｄ）は、異なる複数の日のワークロードが同じ平均に正規化されるようにサイトｉのｄ日に関する重みである。その上、この例示的な実施形態では、ピーク負荷レジーム（regime）はＷｅｂサーバ・パフォーマンスにより重大な影響を及ぼすので、クラスタ化の焦点になると判断される。したがって、各加重平均要求パターンはその最大値によって正規化され、そのピーク時トラフィック・パターンは以下のように定義される。

式中、ｍ_i＝ｍａｘ_h｛ｌ_i（ｈ）｝である。

ピーク時パターン間の非相似性尺度（dissimilaritymeasure）は以下のように定義される。

式中、ｈ^dは、たとえば、時間帯の差を有する異なるＷｅｂサーバからの２つのトラフィック・パターンを比較するときに必要な毎時シフトとして使用される。この非相似性尺度は、Ｗｅｂサイトｉの正規化加重平均要求パターンと、時間帯の差がある場合にその差を補償するためにシフトされたＷｅｂサイトｊの正規化加重平均要求パターンとの最大差の最小値である。この非相似性尺度は、Ｗｅｂサイトのクラスにパターンをクラスタ化するために、互いに最も似ている正規化加重平均要求パターンを識別するために使用される。

この例示的な実施形態では、非相似性尺度に基づいて正規化加重平均要求パターンをクラスタ化するために、完全リンケージ（linkage）または最遠隣接（furthestneighbor）アルゴリズムが使用される。すなわち、第１のステップでは、各パターンがそれ自体のクラスタを表し、これらのパターン間の距離は上記の式３で示される非相似性尺度によって定義される。次に、最小距離を有する２つのパターンがまとめてリンクされる。この新しいクラスタと残りのクラスタ（または個別パターン）との距離は、それぞれのクラスタ内の任意の２つのパターン間の最大距離によって、すなわち、最遠隣接によって定義される。この結果、アルゴリズムは、後続ステップで、もっと多くのパターンをまとめてリンクし、所定のしきい値内でもっと大きいクラスタを集約し始める。

この例示的な実施形態では、完全リンケージ・アルゴリズムでしきい値を使用して、図１２に示した要求パターンが４つの別個のクラスにクラスタ化される。図１３は、図１２のＷｅｂサイトがクラスタ化される４つの別個の要求パターン・クラス用のパターンを示す例示的な図である。図１３により、様々なクラスについて以下の観察を行うことができる。クラス１のパターンの場合、要求トラフィック・ロードは正午までにピーク・レベルまで増加し、その後、午後に著しく低下する。これは、毎日の天気予報のチェックのように、このようなＷｅｂサイトに関するユーザの関心がより瞬間的であることを示唆している。そのＷｅｂサイトは主としてそのローカル・エリアで人気がある。

クラス２のパターンの場合、要求トラフィック・ロードは正午にピーク・レベルまで増加し、午後に高い状態を保持し続けるが、晩に非常に低くなる。これは、ユーザが主として勤務時間中にこれらのＷｅｂサイトに関する関心を示すことを示唆している。クラス３のパターンの場合、要求トラフィック・ロードは正午をいくらか過ぎてピーク・レベルまで増加し、午後の大半の間、高い状態を保持する。晩には、ユーザは、これらのＷｅｂサイトに関する関心をある程度示し続ける。

クラス４のパターンの場合、要求トラフィック・ロードは正午前から晩までの長期間にわたって高レベルを保持する。これは、ユーザのほとんどが勤務時間中かまたは自分の余暇にこれらのＷｅｂサイトにアクセスすることと、ユーザがおそらく国中さらに世界中に広がっていることを示唆している。

これらの異なるクラスのそれぞれに該当するＷｅｂサイトの特性についてこのような観察を行うことにより、後でこれらのクラスの１つに分類されるＷｅｂサイトの使用法を予測することは可能である。したがって、このような予測により、そのＷｅｂサイトが経験すると思われるトラフィックを処理するために、様々な尺度を使用することができる。

したがって、本発明の好ましい一実施形態により、Ｗｅｂサイトのクラスタ化は、複数のＷｅｂサイトに関するトラフィック・データを入手することと、クラスタ化の基礎として使用するためにトラフィック・データの尺度を決定することと、選択した尺度によりトラフィック・データのパターンを識別することと、トラフィック・データに関する非相似性または相似性関係を定義することと、次にこの非相似性または相似性関係に基づいてＷｅｂサイトをクラスタ化するためにクラスタ化アルゴリズムを使用することを含む。これらのクラスタを識別すると、その後のＷｅｂサイトの分類とともに使用可能なクラスタ用のテンプレートを識別するためにクラスタのプロファイル作成を実行する。

プロファイル作成は、まずトラフィック・プロファイルの基礎になるメトリックを決定することを含む。例示的な一実施形態では、識別されたクラスのＷｅｂサイトに関するプロファイルを生成するために、加重平均ロードｌ_i（ｈ）を使用する。あるクラスに関するプロファイルを生成する際に、そのクラスのすべてのメンバに最も似ている要求パターンとして定義される、そのクラス用のテンプレートを識別する。

あるクラス用のテンプレートを見つけるための手法の１つは、そのクラスのすべてのメンバを単純に平均することである。これはそのクラス用のテンプレートを入手するために実行することができるが、その結果は概して、そのクラス用のテンプレートとしてよい選択にはならない。というのは、そのクラスの外部メンバがこのテンプレートから離れているが、他のクラスのテンプレートに近くなる可能性があるからである。もう１つの基礎となる考慮事項は、種々のクラスについて定義されたテンプレートが互いに離れていなければならないことである。したがって、あるクラス用のテンプレートは、そのクラス内のすべてのメンバに対する最大差を最小限にするように定義される。

Ｇ_kはクラスｋに属す要求パターンのセットを示すものと想定する。形状は似ているが、クラスｋ内のメンバ、すなわち、Ｗｅｂサイトは、実際には異なる時間帯内に位置するかまたはシフトされた振る舞いの任意の他のソースを含む可能性がある。したがって、テンプレートを定義するためには、まず、シフトしたときにすべてのメンバが最も近い形状を有するように正しいシフト・バイアス｛ｈ_i ^d，ｉｃＧ_k｝を識別することが必要である。このようなシフト・バイアスは、以下の数式を介して解決することができる。

すなわち、シフト｛ｈ_i ^d，ｉｃＧ_k｝時に、そのクラスの任意の２つのメンバ間の最大差は最小限にならなければならない。例示的な一実施形態では、以下に示すようなシフト・アルゴリズムを使用して、この特定のシフトを識別することができる。この特定のシフトを識別するためのその他のアルゴリズムも、本発明の精神および範囲を逸脱せずに使用することができる。

例示的な一実施形態では、シフト・アルゴリズムは、このセット｛ｈ_i ^d，ｉｃＧ_k｝が０〜２３（時間単位で可能なシフト）の間の任意の整数になる第１のステップを含む。次に、以下のように、それぞれのｉｃＧ_kについて、シフト値ｈ_i ^dを更新する。

次に、｛ｈ_i ^d，ｉｃＧ_k｝が局所最適値（local optimum）に収束するまで、このステップを繰り返す。

したがって、シフト時にメンバｉがそのクラスの他のすべてのメンバに近くなるように、それぞれのｉｃＧ_kについてｈ_i ^dを選択する。次に、それ以上の改善がまったく得られなくなるまで、この手順を反復的に繰り返す。

最適シフト・バイアス｛ｈ_i ^d，ｉｃＧ_k｝を識別すると、クラスｋのテンプレートを以下のように定義する。

この場合、ｈ＝０，１，・・・，２３である。すなわち、このテンプレートは、そのクラスのすべてのメンバ用のパターンに最も似ているパターンである。図１４は、本発明のクラスタ化およびプロファイル作成を使用して生成された図１３の４つの要求パターン・クラス用の４つのテンプレートを示す例示的な図である。この同じクラスタ化およびプロファイル作成を経験データに適用すると、曜日、週、月など、異なるトラフィック効果について異なるテンプレートを生成することができる。たとえば、図１５に示した通り、図４〜６のＷｅｂサイトに関する経験データに本発明のクラスタ化およびプロファイル作成を適用することにより生成された曜日パターンが示される。

上述のクラスタ化およびプロファイルを使用して生成された各種クラス用のテンプレートは、着信要求パターンを認識するために使用することができる。まず、このテンプレートを使用して、既存のサンプルを認識し、この認識の結果がクラスタ化と一貫しているかどうかをチェックする。その後、テンプレートに基づいて、要求パターンを要求のクラスと突き合わせる。この突き合わせにより、そのクラスの一部である残りのＷｅｂサイトの特性に基づいて、Ｗｅｂサイト・トラフィックの特定の特性を見分けることができる。

好ましくは、分類を実行するために、上記の式１および２を使用して、新たに収集したデータについて正規化ピーク時要求パターンを計算する。その後、好ましくは式３を使用して、着信要求パターン・データと４つのテンプレートに関するデータとの距離尺度を計算する。この距離尺度に基づいて、最も近い一致テンプレートを識別し、着信要求パターンを対応するクラスに分類することができる。

所定のテンプレートは可能な要求パターンをすべてカバーするわけではない可能性があるので、新しいタイプの要求パターンまたは異常要求パターンは、所定のテンプレートのすべてから離れる可能性があり、すなわち、最小距離がしきい値量より大きくなる。このような場合、新しい要求パターンは、新しい要求パターン・クラス用の新しいテンプレートとして追加することができる。

本発明によりＷｅｂサイトをクラスタ化し、プロファイル作成し、分類することにより、同じクラスに該当するＷｅｂサイトに基づいて、Ｗｅｂサイト・トラフィックに関する特性を識別することができる。この分類は、トラフィック予測、キャパシティ・プランニング、ホットスポット検出、動的オフロード、Ｗｅｂサイト・コロケーションなどを含む、多くの異なるタイプのアプリケーションとともに使用することができる。

トラフィック予測に関して、キャパシティ・プランニングの際に重要な問題の１つはワークロードの振る舞いの予測である。この予測メカニズムは、長期傾向、周期性、依存関係、および変動性という特性を捕捉する必要がある。単一技法を使用して、これらの要因をすべて捕捉することは困難である。したがって、より正確な手法は、マクロ・レベル統計とマイクロ・レベル統計の両方に関するハイブリッド技法を使用することになるであろう。長期傾向は線形回帰方法を使用して測定することができるが、種々のスケール（たとえば、月次、週次、日次など）の周期性は本発明のクラスタ化およびプロファイル作成技法を使用して処理することができる。

本発明のクラスタ化手法は、キャパシティ・プランニング・タスクを大幅に単純化することができる。本発明では、種々のクラスタ（またはクラス）のテンプレート（またはプロファイル）を使用して、各個別プロファイルごとのキャパシティ需要、倍率の影響、およびあるＷｅｂサーバ・ファーム、クラスタなどに含まれるサーバに関するプロファイルの混合を分析することができる。新しい顧客が現れると、必要であればキャパシティ要件を調整するように、本発明の分類技法を使用して、その新しい顧客のトラフィックが属すクラスタを決定することができる。同じように、特殊イベント、Ｗｅｂサイト再設計などのために、あるＷｅｂサイトによりクラスタが変化させられる場合、短期キャパシティ・プランニング決定を容易に調整することもできる。

特殊イベント、たとえば、ｅ−ｃｏｍｍｅｒｃｅ Ｗｅｂサイトの休日特売の場合、あるＷｅｂサイトでは大量に負荷がかかり、したがって、必要なサービス品質を達成するために特定の追加操作を必要とする可能性がある。このような操作の例としては、オフロードと、新しいリソースの追加を含む。このような特殊イベントは「ホットスポット」を表す。ホットスポット検出では、その目標は、ホットスポットを処理するための適切なメカニズムがトリガされるように、ホットスポットを検出することである。本発明のプロファイル作成手法では、テンプレートによって記述される典型的な振る舞いから現行ワークロードが著しく逸脱していることが観察されると、これらのホットスポットを検出することができる。

前述の通り、時には、ホットスポットが発生した場合などのサーバ過負荷を緩和するために、動的オフロード操作が必要になる。この動的オフロードを達成するための方法の１つは、余分な負荷の一部のオフロード先にすることができるサーバ（Ａｋａｍａｉサーバなど）に対するオフロード可能オブジェクト（イメージなど）の参照を含むＷｅｂページの新しいバージョンを作成（または異なるバージョンを使用）することである。本発明のテンプレートの適切な使用により、それを上回るトラフィックをオフロードしなければならないしきい値が何であるかを決定することは容易である。その上、このオフロード方式は、オフロード方式の遅れ時間を補償するために、サーバが飽和状態になる前に開始することができる。この新しいしきい値、すなわち、遅れ時間を補償するしきい値は、遅れ時間とともにテンプレートから決定することができる。

Ｗｅｂサイト・コロケーションでは、その目標は、残りのエンティティからリソースを借りることにより任意の所与のＷｅｂサイトのピーク負荷条件を処理できるように、複数のＷｅｂサイト間でリソースを共用することである。このパラダイムにおける重要な問題は、リソース共用のためのＷｅｂサイトのクラスタ化に関係する。観察されたトラフィック・テンプレートに基づいて、種々のサイトに関するピーク・レジームの形状ならびに種々の時間および種々の地理的時間帯における種々のトラフィック・ピークと谷を容易に識別することができる。その場合、最も平滑で可能な全体的ピーク負荷を入手するために、最適化ツールを使用して、いくつかのＷｅｂサイトにわたってロード・バランシングを達成することができる。この最適化問題は、項目がテンプレートになる一般的なビン詰め問題（bin packing problem）と見なすことができる。また、これは、整数計画法問題として公式化する（formulate）こともできる。

要求パターンに関して本発明の上記の諸実施形態を述べてきたが、本発明はこのようなものに制限されないことに留意されたい。むしろ、Ｗｅｂサイトに関する任意の尺度データを使用して、本発明のクラスタ化、プロファイル作成、および分類を実行することができる。たとえば、本発明は、サーバ使用状況データ、帯域幅消費データなどに作用することができる。

図１６は、本発明によるＷｅｂサイト分類デバイスの例示的なブロック図である。図１６に示した諸要素は、本発明の精神および範囲を逸脱せずに、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの任意の組合せで実現することができる。好ましい一実施形態では、Ｗｅｂサイト分類デバイスの諸要素は、１つまたは複数のプロセッサによって実行されるソフトウェア命令として実現される。

図１６に示した通り、Ｗｅｂサイト分類デバイスは、コントローラ１１１０と、入出力インターフェース１１２０と、Ｗｅｂサイト・データ・ストレージ・デバイス１１３０と、クラスタ化エンジン１１４０と、プロファイル作成エンジン１１５０と、分類エンジン１１６０とを含む。これらの要素１１１０〜１１６０は、制御／データ信号バス１１７０を介して互いにやりとりしている。

コントローラ１１１０は、Ｗｅｂサイト分類デバイスの全体的な動作を制御し、他の要素１１２０〜１１６０の動作を調整する。コントローラ１１１０は、入出力インターフェース１１２０を介してＷｅｂサイトからＷｅｂサイト・トラフィック・データを受信し、このＷｅｂサイト・トラフィック・データをＷｅｂサイト・データ・ストレージ・デバイス１１３０に保管する。次にコントローラ１１１０は、それに関するデータがＷｅｂサイト・データ・ストレージ・デバイス１１３０に保管されるＷｅｂサイトをクラスタ化するようクラスタ化エンジン１１４０に指示する。

クラスタ化を実行し、そのＷｅｂサイトを特定のＷｅｂサイト・クラスに割り当てると、コントローラ１１１０は、それぞれのクラスについてテンプレートまたはプロファイルを生成するようプロファイル作成エンジン１１５０に指示する。クラスタ化およびプロファイル作成は、新しいＷｅｂサイト・トラフィック・データが使用可能になったときにＷｅｂサイト分類デバイスによって維持されるクラスタと、それに対応するテンプレートまたはプロファイルが更新されるように、周期的に実行することができる。代わって、新しいＷｅｂサイトからトラフィック・データを受信するたびに、この新しいＷｅｂサイトをＷｅｂサイト分類デバイスによって維持されるクラスタおよびテンプレートに含めるように、クラスタ化およびプロファイル作成を更新することができる。

新しいＷｅｂサイトからトラフィック・データを受信すると、Ｗｅｂサイト分類デバイスによって維持される様々なクラス用のテンプレートとそのトラフィック・データとを比較する。この比較により、新しいＷｅｂサイトに関するトラフィック・データに基づいて新しいクラスおよびテンプレートの作成を保証するように、新しいＷｅｂサイトに関するトラフィック・データが１つのクラス用のテンプレートに適合するかまたは全クラス用のすべてのテンプレートに十分似ていないかどうかに関する判別を行うことができる。新しいＷｅｂサイトに関するトラフィック・データのこの分類により、新しいＷｅｂサイトを特定のＷｅｂサイト・クラスに割り当てるか、または新しいＷｅｂサイトを使用してそれ自体のＷｅｂサイト・クラスを生成する。上記の通り、この分類は、ワークロードの特徴付け、パフォーマンスのモデル化、ワークロードおよびパフォーマンスの予測、キャパシティ・プランニングなどのリソース管理機能を実行するために種々のプロセスによって使用することができる。

図１７は、本発明の例示的な動作の概略を示す流れ図である。図１７に図示した通り、本発明の動作は、複数のＷｅｂサイトからＷｅｂサイト・トラフィック・データを受信することから始まる（ブロック１２１０）。次に、上述のクラスタ化技法を使用して、Ｗｅｂサイト・トラフィック・データをクラスタ化する（ブロック１２２０）。各クラスタまたはクラスごとにテンプレートまたはプロファイルを生成する（ブロック１２３０）。

次に動作は、新しいＷｅｂサイトからのトラフィック・データを待つ（ブロック１２４０）。次に、新しいＷｅｂサイトに関するトラフィック・データを受信したかどうかに関する判別を行う（ブロック１２５０）。受信していない場合、動作はブロック１２４０に戻り、新しいＷｅｂサイトからのトラフィック・データを待ち続ける。新しいＷｅｂサイトに関するトラフィック・データを受信した場合、既存のＷｅｂサイト・クラスに基づいて、新しいＷｅｂサイトに関するトラフィック・データを分類する（ブロック１２６０）。次に動作は終了する。

図１８は、Ｗｅｂサイトをクラスタ化するための本発明の例示的な動作の概略を示す流れ図である。図１８に示した通り、本発明のクラスタ化動作は、それによりクラスタ化を実行するためのトラフィック・データ尺度を選択することによって始まる（ブロック１３１０）。次に、選択したトラフィック・データ尺度に関してＷｅｂサイトのトラフィック・データのテンプレートを識別する（ブロック１３２０）。次に、クラスタ化アルゴリズムを使用して、テンプレートをクラスタ化する（ブロック１３３０）。

図１９は、Ｗｅｂサイトのプロファイルを作成するための本発明の例示的な動作の概略を示す流れ図である。図１９に示した通り、動作は、トラフィック・プロファイルの基礎になるメトリックを決定することから始まる（ブロック１４１０）。この選択したメトリックに基づいて、そのクラス内の各Ｗｅｂサイトのトラフィック・データ用のテンプレートを生成する（ブロック１４２０）。次に、必要であれば、シフト・バイアス量だけテンプレートをシフトして、種々の時間帯などの要因を補償する（ブロック１４３０）。次に、そのクラス内のＷｅｂサイト用のすべてのテンプレートに最も似ているプロファイルを選択することにより、プロファイルを生成する（ブロック１４４０）。この動作は、各Ｗｅｂサイト・クラスごとに実行することができる。

図２０は、Ｗｅｂサイトを分類するための本発明の例示的な動作の概略を示す流れ図である。図２０に示した通り、Ｗｅｂサイトを分類するための動作は、新しいＷｅｂサイトに関するトラフィック・データの受信から始まる（ブロック１５１０）。新しいＷｅｂサイトに関するトラフィック・データ用のテンプレートを生成し（ブロック１５２０）、そのテンプレートを既存のＷｅｂサイト・クラス用のテンプレートと比較する（ブロック１５３０）。一致テンプレートが識別されたかどうかに関する判別を行う（ブロック１５４０）。識別された場合、そのＷｅｂサイトを一致テンプレートに関連するクラスに分類する（ブロック１５５０）。識別されない場合、新しいクラス用のテンプレートを生成するための基礎として新しいＷｅｂサイトに関するトラフィック・データを使用して、新しいクラスを生成する（ブロック１５６０）。次に動作は終了する。

したがって、本発明は、そのトラフィック・データに基づくＷｅｂサイトのクラスタ化、プロファイル作成、および分類のためのメカニズムを提供する。本発明では、今後、最も経験しそうなワークロードを予測しプランニングする際に使用するために、それぞれが経験するトラフィックに関してＷｅｂサイト間の相似性を識別することができる。したがって、本発明は、それらがホストとして処理するＷｅｂサイトに関してＷｅｂサーバ用のリソース管理を実行できるツールを提供する。

上述のようなＷｅｂサイトのクラスタ化、プロファイル作成、および分類をリソース割振りに適用して、Ｗｅｂサイト・グループに関する最適化リソース割振りを入手することができる。本発明では、前述のメカニズムにより、あるＷｅｂ・サイト・グループ内のＷｅｂサイト用のテンプレートを入手すると、これらのテンプレートを使用して、グループ内のどのＷｅｂサイトがコロケーション用の候補であるかならびに他のＷｅｂサーバにいつトラフィックをオフロードしなければならないかを決定することができる。これらのコロケーションおよびオフロードの機能をさらに組み合わせて、これらのＷｅｂサイトにアクセスするクライアント・デバイスに必要なサービス品質（ＱｏＳ）を提供するためにリソース割振りをさらに最適化することができる。

コロケーションでは、その目標は、Ｗｅｂサイトに関連するテンプレートに基づいて、種々の時間にトラフィックのピークおよびトラフを有するＷｅｂサイトをコロケーションすることである。すなわち、この目標は、かなり一貫しているリソース使用状況を入手するかまたは少なくともすべての期間において必要なサービス品質を提供するためにテンプレート同士が互いに補完する、２つまたはそれ以上のＷｅｂサイトに関するトラフィックを処理する単一サーバ（またはサーバ・スイート）を有することである。

解決できるコロケーション問題には、いくつかの変形がある。１つの例は、Ｗｅｂサーバが所与のトラフィック・キャパシティを備えていなければならないことである。これは、経験する可能性のある非正規トラフィック・ボリュームを処理するためにＷｅｂサーバ・プロバイダがすべての時期に特定のキャパシティを保持したいと希望する、典型的なケースである。

このタイプのコロケーション問題は、まずコロケーションに関して考慮中の各Ｗｅｂサイトに関するトラフィックのテンプレートを決定することにより、本発明によって解決される。このテンプレートは、Ｗｅｂサイトのトラフィック・ログから決定される。このテンプレートは、前述のクラスタ化メカニズム、プロファイル作成メカニズム、あるいは分類メカニズム、またはこれらの組合せにより入手することができる。

考慮中のそれぞれのＷｅｂサイト用のテンプレートを入手すると、整数計画法（ＩＰ：integer programming）問題を公式化する。この整数計画法問題は、Ｗｅｂサーバに対するＷｅｂサイトの割当てである決定変数を有する。この整数計画法問題の制約は、任意の時期に任意のサーバに関するキャパシティ制限である。目的関数は、種々のサーバにおけるサーバ・キャパシティとピーク負荷との最小距離の増加関数である。

この整数計画法問題を公式化した後、最適または近似アルゴリズムを使用してそれを解決する。整数計画法問題を解決するための標準的な方法およびアルゴリズムとしては、分岐限定法、切除平面アルゴリズム、ＬＰ緩和法などを含む。

たとえば、合計Ｊ台のサーバで供応しなければならないＩ個のサイトが存在し、それぞれがキャパシティＣ_jを有し、ｊ＝１〜Ｊであると想定する。ＷｅｂサイトｉのトラフィックはテンプレートＴ_i（ｔ）によって特徴付けることができ、ｉ＝１〜Ｉであると仮定する。２進決定変数はｘ_ijであり、ｉ＝１〜Ｉおよびｊ＝１〜Ｊであり、サイトｉがサーバｊに割り当てられる場合にｘ_ij＝１になり、そうではない場合にｘ_ij＝０になる。

次に、このコロケーション問題を以下の２進整数計画法問題として公式化することができ、その場合、ｂはターゲット使用状況である。

式中、ｘ_ijは２進整数である。

上記の手法では、目的関数は、たとえば、負荷の経験的変動など、他のロード・バランシング基準にすることもできる。また、ピーク負荷が特定の量だけサーバ・キャパシティより低くなるように、制約に何らかの遊びを採り入れることもできる。このようにして、要求の平均応答時間の上限が定められることになる。

コロケーション問題のもう１つの例は、異なるＷｅｂサービス業者が異なるコストを有し、少なくとも１つのＷｅｂサイトがそれに割り当てられた場合にコストが発生すると仮定した場合に、Ｗｅｂサーバの全コストを最小限にすることである。このケースでは、コロケーション問題は以下のように解決することができる。

コロケーション問題の前の変形と同様に、プロセスの第１のステップは、コロケーションに関して考慮中の各Ｗｅｂサイトに関するトラフィックのテンプレートを識別することである。テンプレートを識別すると、同じく決定変数がＷｅｂサーバに対するＷｅｂサイトの割当てになる整数計画法問題を公式化する。制約は、任意の時期に任意のサーバに関するキャパシティ制限である。しかし、目的関数は、少なくとも１つのＷｅｂサイトが割り当てられるすべてのＷｅｂサーバのコストの合計である。この整数計画法問題は、最適または近似アルゴリズムを使用して解決される。

コロケーション問題のこの変形の一例として、前述のケースを考慮するが、Ｗｅｂサーバｊを使用するとＰ_jというコストを要し、ｊ＝１〜Ｊであると仮定した場合に、その目標はＷｅｂサーバの全コストを最小限にすることになる。このようなケースでは、前の例の目的関数を以下の式で置き換える。

式中、関数１（ａ）は、ステートメントが真である場合に１になり、そうではない場合に０になる。したがって、この２進整数計画法問題は以下のように公式化される。

式中、ｘ_ijは２進整数である。

上記の問題のより単純なバージョンは、サーバ・キャパシティが同一であり、サーバ・コストも同一であることである。このケースでは、この問題は、ビンがサーバであり、品目がトラフィック・テンプレートである、２次元ビン詰め問題になる。したがって、問題は以下のように解決することができる。

まず、すべてのコロケーション問題と同様に、コロケーションに関して考慮中のＷｅｂサイト用のテンプレートを識別する。次に、使用するビンの数を最小限にするという目標とともに、このビン詰め問題を公式化する。その後、高速または近似アルゴリズムを使用して、２次元ビン詰め問題を解決する。このような高速および近似アルゴリズムは当技術分野で既知のものであり、このような高速および近似アルゴリズムに関する詳細は、たとえば、１９８４年にＳｐｒｉｎｇｅｒ−Ｖｅｒｌａｇから発行され、Ａｕｓｉｅｌｌｏ、Ｌｕｃｅｒｔｉｎｉ、およびＳｅｒａｆｉｎｉによって編集されたＡｌｇｏｒｉｔｈｍ Ｄｅｓｉｇｎ ｆｏｒ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎに掲載されたＥ． Ｇ． Ｃｏｆｆｍａｎ， Ｊｒ．他の「Ａｐｐｒｏｘｉｍａｔｉｏｎ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｂｉｎ−Ｐａｃｋｉｎｇ −− Ａｎ Ｕｐｄａｔｅｄ Ｓｕｒｖｅｙ」ならびに１９７４年にＪｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｓｙｓｔｅｍ Ｓｃｉｅｎｃｅｓ ８の２７２〜３１４ページに掲載されたＤａｖｉｄ Ｓ． Ｊｏｈｎｓｏｎによる「Ｆａｓｔ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｂｉｎ Ｐａｃｋｉｎｇ」で見つけることができる。

したがって、図２１に示した通り、コロケーション問題の各変形により、Ｗｅｂサーバに対するＷｅｂサイトの割当てと、その結果、Ｗｅｂサイトのコロケーションを決定するための動作は、考慮中のＷｅｂサイト用のテンプレートを識別することによって始まる（ブロック１６１０）。次に、Ｗｅｂサイトの割振りに関する所望の最適化を実施する目的関数により、このコロケーション問題を整数計画法問題として公式化する（ブロック１６２０）。決定変数がＷｅｂサーバに対するＷｅｂサイトの割当てであり、制約が任意の時期に任意のサーバに関するキャパシティ制限であるように、整数計画法問題を公式化する。整数計画法問題を公式化すると、最適または近似アルゴリズムにより整数計画法問題を解決する（ブロック１６３０）。上記の通り、キャパシティおよびコストなどの特定の特性がすべてのサーバについて同一と見なされるときに、この整数計画法問題をビン詰め問題にすることができる。

前述の通り、本発明は、他のＷｅｂサイトへのトラフィックのオフロードにさらに適用することができる。オフロード・メカニズムは、あるＷｅｂサイトの負荷が重くなり、したがって、必要なサービス品質を達成するために特定の追加のサービス・キャパシティを必要とするときに、着信要求の一部をバックアップまたはその他の負荷が小さいサーバにリダイレクトすることを含む。オフロード・メカニズムがオンになると、たとえば、ＨＴＴＰリダイレクト応答コード３０１または３０２を使用してクライアントのブラウザに異なるＷｅｂサーバでその要求を再試行させるか、またはＷｅｂサーバの前にＩＢＭ Ｎｅｔｗｏｒｋ ＤｉｓｐａｔｃｈｅｒあるいはＣｉｓｃｏ Ｇｌｏｂａｌ Ｄｉｒｅｃｔｏｒのようなロード・バランシング・デバイスを配置し、本発明の制御下で種々の時期に種々のサーバに要求を送信するためのこのようなデバイスの能力を使用することにより、要求をリダイレクトすることができる。

重要な問題は、このように負荷が大きい状況を未然に検出または予測し、その結果、正しい時間にオフロード・メカニズムをトリガする方法に関係する。本発明によりオフロードするためのしきい値が付いたＷｅｂサイト用のテンプレートを示す図２２に関連して、本発明によるオフロードについて説明する。

本発明によるオフロードにより、前述のようにＷｅｂサイトのトラフィック・ログから考慮中の各Ｗｅｂサイトに関するトラフィックのテンプレートを決定する。図２２は、あるＷｅｂサイト用のこのような１つのテンプレートを示している。好ましい一実施形態では、時間単位あたりの要求の数に関してテンプレートを決定する。

サービス品質（ＱｏＳ）基準を保証するために、それを上回るトラフィックの一部分をホームＷｅｂサーバからオフロードしなければならない第１のしきい値１７１０をトラフィック量に関して計算する。このしきい値１７１０は、全トラフィックの周辺分布およびオフロード可能なトラフィックの量に基づいて決定する。より正確には、ｈ₁がしきい値１７１０であり、ａがオフロード可能なトラフィックの比率であり、Ｅ［Ｓ_o］およびＥ［Ｓ_no］がオフロード可能要求およびオフロード不能要求あたりの予想サービス要件であり、Ｃが考慮中のボトルネック・リソースのキャパシティであり、ｂがシステムによって保証する必要のあるＱｏＳによって決定されるターゲット・リソース使用状況である場合、以下の式により第１のしきい値１７１０を決定することができる。

上述のように第１のしきい値１７１０を計算すると、ローからハイへの遷移レジームにおけるトラフィック量に関して第２のしきい値１７２０を計算する。ハイからミディアムへの遷移レジームにおけるトラフィック量に関して第３のしきい値１７３０を計算する。第２のしきい値１７２０の計算は、動的オフロード・メカニズムの反応時間およびトラフィックの統計パターンに基づいて、しきい値１７１０に適合するように進み時間を考慮に入れる。同様に、第３のしきい値１７３０の計算は、動的オフロード・メカニズムの反応時間およびトラフィックの統計パターンに基づいて、遅れ時間を考慮に入れる。したがって、第２のしきい値１７２０はしきい値１７１０から進み時間を減算することによって計算することができ、第３のしきい値１７３０はしきい値１７１０に遅れ時間を加算することによって計算することができる。

テンプレートを識別し、しきい値を計算すると、ロー・レジームからハイ・レジームへおよびハイ・レジームからミディアム・レジームへのオンライン遷移を検出する。この検出は、いくつかの統計技法を使用して実行することができる。このような技法の１つは、着信トラフィックの周辺分布を計算することからなる換点（change-point）検出である。この技法により、この周辺分布の偏差を検出する。換点検出に関する詳細は、たとえば、１９９４年にＩＭＳ Ｌｅｃｔｕｒｅ Ｎｏｔｅｓ − Ｍｏｎｏｇｒａｐｈ Ｓｅｒｉｅｓ、ｖｏｌ．２３に掲載されたＣａｒｌｓｔｅｉｎ他による「Ｃｈａｎｇｅ−Ｐｏｉｎｔ Ｐｒｏｂｌｅｍｓ」で見つけることができる。遷移を検出するためのより単純な方法は、トラフィック量の移動平均を計算することである。この移動平均は、数分台または数十分台という極めて粗い時間目盛りで取ることができる。たとえば、移動平均を計算する方法の１つは、いくつかの最新観測値とともに前の推定値の加重合計（weighted sum）を計算することである。たとえば、以下のようになる。

式中、ｃ₁・・・ｃ_kは負でない重みである。その要件は、ｃ₁＋・・・＋ｃ_k［１である。

上記の手法により、オフロード・メカニズムは、トラフィック量がしきい値１７２０を超えるとオンになり、トラフィック量がしきい値１７３０未満に低下するとオフになる。

図２３は、本発明によりトラフィックをオフロードするための本発明の例示的な動作の概略を示す流れ図である。図２３に示した通り、動作は、考慮中の各Ｗｅｂサイト用のテンプレートを識別することから始まる（ブロック１８１０）。全トラフィックの周辺分布およびオフロード可能なトラフィックの量に基づいて、トラフィック量に関して第１のしきい値を計算する（ブロック１８２０）。次に、第１のしきい値と、オフロード・メカニズムの進み時間および遅れ時間に基づいて、第２および第３のしきい値を計算する（ブロック１８３０）。

その後、ロー・レジームからハイ・レジームへおよびハイ・レジームからミディアム・レジームへの遷移が存在するかどうかを判別するためにオンライン・トラフィックをモニターする（ブロック１８４０）。遷移が検出されたかどうかに関する判別を行う（ブロック１８５０）。検出されない場合、動作は、終了条件が発生したかどうか、たとえば、オフロードが使用不可になったかどうかを判別する（１８６０）。そうである場合、動作は終了する。そうではない場合、動作はブロック１８４０に戻り、遷移についてモニターし続ける。

遷移が検出された場合、それがローからハイへの遷移であるかどうかに関する判別を行う（ブロック１８７０）。そうである場合、トラフィック・オフロード・メカニズムを使用可能にし、トラフィックを他のサーバにオフロードする（ブロック１８８０）。遷移がローからハイではない場合、遷移はハイからミディアムへの遷移であり、オフロード・メカニズムを使用不可にする（ブロック１８９０）。

したがって、上述の通り、そのトラフィック・ログに基づいてＷｅｂサイトをクラスタ化し、プロファイル作成し、分類し、それにより、Ｗｅｂサイトに関するトラフィックのテンプレートを生成するという本発明は、コロケーションおよびオフロードなどのリソース割振りメカニズムに適用することができる。前述の通り、本発明は、コロケーションとオフロードの組合せにさらに適用することができる。Ｗｅｂサーバが複数のＷｅｂサーバをホストとして処理しており、サーバの負荷がそのキャパシティを超えたときに、オフロード可能なトラフィックを他のＷｅｂサーバにオフロードしなければならないという状況では、往々にしてコロケーションとオフロードの組合せ問題が発生することになる。このような状況では、本発明は、コロケーションしたＷｅｂサイトについてオフロードを実行するために、以下のように実現することができる。

前のすべてのメカニズムと同様に、まず、考慮中のそれぞれのＷｅｂサイト用のテンプレートを決定しなければならない。次に、決定変数がＷｅｂサイトからＷｅｂサーバへのトラフィックの一部分の割当てである数理計画法問題を公式化する。制約は、任意の時期に任意のサーバに関するキャパシティ制限である。目的関数は、少なくとも１つのＷｅｂサイトが割り当てられるすべてのＷｅｂサーバのコストの合計である。

一例として、前のコロケーション問題で記述したのと同様の条件を想定する。決定変数ｘ_ijはもはや２進整数である必要がないことに留意されたい。その代わりに、ｘ_ijはサーバｊに割り当てることができるＷｅｂサイトｉからのトラフィックの一部分を示し、ｉ＝１〜Ｉであり、ｊ＝１〜Ｊである。したがって、０＜＝ｘ_ij＜＝１であり、この数理計画法問題は以下のように公式化される。

公式化した後、最適または近似アルゴリズムを使用して、この数理計画法問題を解決する。この数理計画法問題は、線形制約を有し、サーバ・コストがその使用状況に比例すると想定される場合に線形計画法問題になる。

各Ｗｅｂサイトごとに、そのトラフィックの一部分が割り当てられるＷｅｂサーバのうちの１つをそのホーム・サーバとして指定する。ホーム・サーバに割り当てられるトラフィックの一部分は、そのホーム・サーバにおけるＷｅｂサイトのしきい値１とも呼ばれる。

各Ｗｅｂサイトごとに、ローからハイへの遷移レジームにおけるトラフィック量に関してしきい値２を計算し、ハイからミディアムへの遷移レジームにおけるトラフィック量に関してしきい値３を計算する。これらのしきい値は、オフロード・メカニズムが必要とする進み時間および遅れ時間を考慮するものである。これらの進み時間および遅れ時間は、動的オフロード・メカニズムの反応時間と、トラフィックの統計パターンと、このサーバをホーム・サーバとして使用する他のすべてのＷｅｂサイト間でホーム・サーバのキャパシティを共用する際のそのＷｅｂサイトの割当て分との組合せである。

各Ｗｅｂサイトごとに、ロー・レジームからハイ・レジームへおよびハイ・レジームからロー・レジームへのオンライン遷移を検出する。前述の通り、この検出は、周辺分布に基づく換点検出または移動平均技法などのいくつかの統計技法を使用して実行することができる。

各Ｗｅｂサイトごとに、オフロード・メカニズムは、トラフィック量がしきい値２を超えるとオンになり、トラフィック量がしきい値３未満に低下するとオフになる。トラフィックがオフロードされる宛先およびこのような宛先に送信すべきトラフィックの一部分は、前に解決された線形計画法問題の解決策によって定義される。

図２４は、コロケーションとオフロードの両方の組合せに関する本発明の例示的な動作の概略を示す流れ図である。図２４に示した通り、動作は、考慮中のそれぞれのＷｅｂサイト用のテンプレートを決定することから始まる（ブロック１９１０）。次に、決定変数がＷｅｂサイトからＷｅｂサーバへのトラフィックの一部分の割当てである数理計画法問題を公式化する（ブロック１９２０）。この数理計画法問題の制約は、任意の時期に任意のサーバに関するキャパシティ制限である。目的関数は、少なくとも１つのＷｅｂサイトが割り当てられるすべてのＷｅｂサーバのコストの合計である。

公式化した後、最適または近似アルゴリズムを使用して、この数理計画法問題を解決する（ブロック１９３０）。次に、各Ｗｅｂサイトごとに、そのトラフィックの一部分が割り当てられるＷｅｂサーバのうちの１つをそのホーム・サーバとして指定し（ブロック１９４０）、そのＷｅｂサイトのしきい値１をそのホーム・サーバに割り当てられるトラフィックの一部分として定義する（ブロック１９５０）。

各Ｗｅｂサイトごとに、ローからハイへの遷移レジームにおけるトラフィック量に関してしきい値２を計算し、ハイからミディアムへの遷移レジームにおけるトラフィック量に関してしきい値３を計算する（ブロック１９６０）。これらのしきい値は、オフロード・メカニズムが必要とする進み時間および遅れ時間を考慮するものである。各Ｗｅｂサイトごとに、ロー・レジームからハイ・レジームへおよびハイ・レジームからロー・レジームへのオンライン遷移を検出する（１９７０）。オフロード・メカニズムは、トラフィック量がしきい値２を超えるとオンになり、トラフィック量がしきい値３未満に低下するとオフになる（１９８０）。

図２５は、リソース割振り決定システムのブロック図である。図２５に示した通り、リソース割振り決定システムは、コントローラ２０１０と、図１６のＷｅｂサイト分類デバイスへのインターフェース２０２０と、Ｗｅｂサーバとオフロード・メカニズムとの間でリソース割振りメッセージを送受信するための入出力インターフェース２０３０と、コロケーション決定デバイス２０４０と、オフロード使用可能化デバイス２０５０とを含む。これらの要素２０１０〜２０５０は、制御／データ信号バス２０６０を介して互いにやりとりしている。

図２５に示した諸要素は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの任意の組合せで実現することができる。好ましい一実施形態では、諸要素２０１０〜２０５０は、１つまたは複数のプロセッサによって実行されるソフトウェア命令として実現される。

コントローラ２０１０は、リソース割振り決定システムの全体的な動作を制御し、他の要素２０２０〜２０５０の動作を調整する。コントローラ２０１０は、インターフェース２０３０を介してコロケーション、オフロード、またはコロケーションとオフロードの組合せを決定するための要求を受信し、インターフェース２０２０を介してＷｅｂサイト分類デバイスから入手したＷｅｂサイト用のテンプレートを使用して、コロケーションあるいはオフロードまたはその両方を決定するよう諸要素２０４０〜２０５０に指示する。要素２０４０および２０５０は、前述のようにＷｅｂサイトのコロケーションあるいはオフロードまたはその両方を決定するための動作を実行し、結果をコントローラ２０１０に返す。次にコントローラ２０１０は、Ｗｅｂサイトをコロケーションするかあるいは他のＷｅｂサーバにトラフィックをオフロードするかまたはその両方を行うための動作を実行するために、Ｗｅｂサーバあるいはオフロード・メカニズムまたはその両方にメッセージを伝送することができる。

したがって、本発明は、Ｗｅｂサイトのトラフィック・ログから入手したＷｅｂサイト・トラフィック・データのクラスタ化、プロファイル作成、あるいは分類、またはこれらの組合せを使用して識別したトラフィック・パターンのテンプレートに基づいて、Ｗｅｂサイトのコロケーションを決定するための装置および方法を提供する。その上、本発明は、Ｗｅｂサイトに関するトラフィック・パターンのこのようなテンプレートに基づいて、あるＷｅｂサーバから他のＷｅｂサーバへのトラフィックのオフロードを決定するための装置および方法を提供する。本発明により、必要な保証サービス品質を入手するために、Ｗｅｂサイトの最適コロケーションおよびオフロードの動的決定を実行することができる。

留意すべき重要なこととして、完全に機能するデータ処理システムに関連して本発明を説明してきたが、当業者であれば、本発明のプロセスがコンピュータ可読命令メディアの形および様々な形式で配布可能であり、その配布を実行するために実際に使用される信号担持媒体の特定のタイプにかかわらず、本発明が等しく適用可能であることが分かるであろう。コンピュータ可読メディアの例としては、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの書込み可能タイプのメディアと、ディジタルおよびアナログ通信リンクなどの伝送タイプのメディアを含む。

本発明の説明は、例示および記述のために提示されたものであり、網羅的なものであるかまたは開示された形式の本発明に制限するためのものではない。多くの変更および変形は当業者には明らかなものになるであろう。この実施形態は、本発明の原理、実際的な適用を最もよく説明し、他の当業者が企図する特定の使用法に適したものとして様々な変更を含む様々な実施形態に関して本発明を理解できるようにするために、選択され記述されたものである。

本発明を実現可能な分散データ処理システムの例示的な図である。 本発明によるサーバ・コンピューティング・デバイスの例示的なブロック図である。 本発明によるクライアント・コンピューティング・デバイスの例示的なブロック図である。 例示的な商用Ｗｅｂサイトに関し１週間という期間の間の毎時ヒット数の例示的な図である。 例示的な商用Ｗｅｂサイトに関し１週間という期間の間の毎時ヒット数の例示的な図である。 例示的な商用Ｗｅｂサイトに関し１週間という期間の間の毎時ヒット数の例示的な図である。 図４〜６の例示的な商用Ｗｅｂサイトの日次時系列プロットの例示的な図である。 図４〜６の例示的な商用Ｗｅｂサイトの日次時系列プロットの例示的な図である。 図４〜６の例示的な商用Ｗｅｂサイトの日次時系列プロットの例示的な図である。 例示的な商用Ｗｅｂサイトで発生する種々の尺度に関する日次平均の関数として示す日次変動係数の例示的な図である。 例示的な商用Ｗｅｂサイトで発生する種々の尺度に関する日次平均の関数として示す日次ピーク対平均比の例示的な図である。 Ｗｅｂサイトをクラスタ化する際に使用するための例示的な商用Ｗｅｂサイトから収集した１日の間の１時間あたりの要求数を示す例示的な図である。 図１２のＷｅｂサイトがクラスタ化される４つの要求パターン・クラス用のパターンを示す例示的な図である。 図１３の４つの要求パターン・クラス用の４つのテンプレートを示す例示的な図である。 図４〜６のＷｅｂサイトに関する経験データに本発明のクラスタ化およびプロファイル作成を適用することにより生成された曜日パターンを示す例示的な図である。 本発明によるＷｅｂサイト分類デバイスの例示的なブロック図である。 本発明の例示的な動作の概略を示す流れ図である。 Ｗｅｂサイトをクラスタ化するための本発明の例示的な動作の概略を示す流れ図である。 Ｗｅｂサイトのプロファイルを作成するための本発明の例示的な動作の概略を示す流れ図である。 Ｗｅｂサイトを分類するための本発明の例示的な動作の概略を示す流れ図である。 どのＷｅｂサイトがコロケーション用の候補であるかを判別するための本発明の例示的な動作の概略を示す流れ図である。 本発明によるオフロードのためのしきい値が図示されている、Ｗｅｂサイト用のテンプレートを示す図である。 本発明によりトラフィックをオフロードするための本発明の例示的な動作の概略を示す流れ図である。 コロケーションとオフロードの両方の組合せに関する本発明の例示的な動作の概略を示す流れ図である。 リソース割振り決定システムのブロック図である。

Claims (13)

1. 複数のＷｅｂサイトにリソースを割り振るためのコンピュータ・プログラムにおいて、
   前記複数のＷｅｂサイト内の各Ｗｅｂサイトに関するトラフィック・パターンを、前記各Ｗｅｂサイトのトラフィック特性を使用して識別してクラスタ分けするための第１のステップと、
   前記トラフィック・パターンに基づいて、前記複数のＷｅｂサイト内の各Ｗｅｂサイトが分類されるクラスタ用のテンプレートを識別するための第２のステップと、
   前記複数のＷｅｂサイト内の各Ｗｅｂサイト用の前記識別されたテンプレートに基づいて、前記複数のＷｅｂサイト内のＷｅｂサイトにリソースを割り振るための第３のステップであって、
   前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための第２のステップと、
   コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトの前記第２のステップでの識別に基づいて、前記２つまたはそれ以上のＷｅｂサイトにリソースを割り振るためのステップとを含む、第３のステップと、
   をコンピュータに実行させる、コンピュータ・プログラム。
2. Ｗｅｂサイトにリソースを割り振るための前記第３のステップが、
   前記複数のＷｅｂサイト内の各Ｗｅｂサイトについて、前記Ｗｅｂサイト用の前記テンプレートに基づいて、事前指定のサービス品質要件を達成するためにそのホスティングＷｅｂサーバが処理できるトラフィック・ロードの最大量を表す第１のしきい値を計算するためのステップと、
   前記第１のしきい値に基づいて第２のしきい値を計算するためのステップであって、前記Ｗｅｂサイトに関するトラフィック量（intensity）が前記第２のしきい値に一致するかまたはそれを超えるときにトラフィックのオフロードが使用可能になるステップと、
   前記第１のしきい値に基づいて第３のしきい値を計算するためのステップであって、前記Ｗｅｂサイトのトラフィック量が前記第３のしきい値に一致するかまたはそれ未満に低下するときにトラフィックのオフロードが使用不可になるステップと、を含む、請求項１に記載のコンピュータ・プログラム。
3. Ｗｅｂサイトにリソースを割り振るための前記第３のステップが、
   前記複数のＷｅｂサイト内の各Ｗｅｂサイトについて、前記Ｗｅｂサイト用の前記テンプレートに基づいて、
   その事前指定のサービス品質要件が満足された状態でそれ未満の値でホスティングＷｅｂサーバ上のすべてのトラフィック・ロードに供応できる第１のしきい値を計算するためのステップと、
   前記第１のしきい値に基づいて第２のしきい値を計算するためのステップ
   であって、前記Ｗｅｂサイトに関するトラフィック量が前記第２のしきい値に一致するかまたはそれを超えるときにトラフィックのオフロードが使用可能になるステップと、
   前記第１のしきい値に基づいて第３のしきい値を計算するためのステップであって、前記Ｗｅｂサイトのトラフィック量が前記第３のしきい値に一致するかまたはそれ未満に低下するときにトラフィックのオフロードが使用不可になるステップと、を含む、請求項１に記載のコンピュータ・プログラム。
4. 前記複数のＷｅｂサイトのうちの１つのＷｅｂサイトのトラフィックが前記第２のしきい値を超えるかどうかを判定するために、あるＷｅｂサーバ上で前記トラフィックをモニターするための第４のステップと、
   前記Ｗｅｂサイトの前記トラフィックが前記第２のしきい値を超える場合に前記トラフィックの少なくとも一部分を他のＷｅｂサーバにオフロードするための第５のステップと、
   をさらにコンピュータに実行させる、請求項２に記載のコンピュータ・プログラム。
5. 前記複数のＷｅｂサイトのうちの１つのＷｅｂサイトのトラフィックが前記第３のしきい値未満に低下するかどうかを判定するために、あるＷｅｂサーバ上で前記トラフィックをモニターするための第６のステップと、
   前記Ｗｅｂサイトの前記トラフィックが前記第３のしきい値未満に低下する場合に前記他のＷｅｂサーバへの前記トラフィックのオフロードを使用不可にするための第７のステップと、
   をさらにコンピュータに実行させる、請求項４に記載のコンピュータ・プログラム。
6. 前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための前記ステップが、
   第１の期間セットにおいてトラフィックのピークを有する第１のＷｅｂサイトを識別するためのステップと、
   前記第１の期間セットとは異なる第２の期間セットにおいてトラフィックのピークを有する第２のＷｅｂサイトを識別するためのステップと、を含む、請求項１に記載のコンピュータ・プログラム。
7. 前記第１のＷｅｂサイトがトラフィックのピークを有するのとほぼ同じ時間に前記第２のＷｅｂサイトがトラフィックのトラフ（trough）を有する、請求項６に記載のコンピュータ・プログラム。
8. 前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための前記ステップが、
   前記同じＷｅｂサーバを共用するＷｅｂサイトからの合計必要サービス・キャパシティが前記Ｗｅｂサーバの使用可能キャパシティを超えないように、共通共用Ｗｅｂサーバ上にコロケーションできる前記２つまたはそれ以上のＷｅｂサイトを識別するためのステップを含む、請求項１に記載のコンピュータ・プログラム。
9. 前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための前記ステップが、
   前記複数のＷｅｂサイトをホストとして処理するすべてのＷｅｂサーバの全コストが最小限になるように、共通共用Ｗｅｂサーバ上にコロケーションできる前記２つまたはそれ以上のＷｅｂサイトを識別するためのステップを含む、
   請求項１に記載のコンピュータ・プログラム。
10. 前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための前記ステップが、
    複数のＷｅｂサーバに対する前記複数のＷｅｂサイトの割当てである決定変数と、任意の時期に任意のサーバに関するキャパシティ制限である制約と、前記複数のＷｅｂサーバのうちの種々のサーバにおけるサーバ・キャパシティとピーク負荷との最小距離の増加関数である目的関数とを有する整数計画法問題を公式化するためのステップを含む、請求項１に記載のコンピュータ・プログラム。
11. 前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するための前記ステップが、
    複数のＷｅｂサーバに対する前記複数のＷｅｂサイトの割当てである決定変数と、任意の時期に任意のサーバに関するキャパシティ制限である制約と、少なくとも１つのＷｅｂサイトが割り当てられるすべてのＷｅｂサーバのコスト
    の合計である目的関数とを有する整数計画法問題を公式化するためのステップを含む、請求項１に記載のコンピュータ・プログラム。
12. 複数のＷｅｂサイトにリソースを割り振る方法において、
    前記複数のＷｅｂサイト内の各Ｗｅｂサイトに関するトラフィック・パターンを前記各Ｗｅｂサイトのトラフィック特性を使用して識別してクラスタ分けするステップと、
    前記トラフィック・パターンに基づいて、前記複数のＷｅｂサイト内の各Ｗｅｂサイトが分類されるクラスタ用のテンプレートを識別するステップと、
    前記複数のＷｅｂサイト内の各Ｗｅｂサイト用の前記識別されたテンプレートに基づいて、前記複数のＷｅｂサイト内のＷｅｂサイトにリソースを割り振るステップと、を有し、前記リソースを割り振るステップが、
    前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別するためのステップと、
    コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトの前記識別に基づいて、前記２つまたはそれ以上のＷｅｂサイトにリソースを割り振るためのステップと、
    を含む、方法。
13. 複数のＷｅｂサイトにリソースを割り振るための装置において、
    前記複数のＷｅｂサイト内の各Ｗｅｂサイトに関するトラフィック・パターンを前記各Ｗｅｂサイトのトラフィック特性を使用して識別してクラスタ分けするための手段と、
    前記トラフィック・パターンに基づいて、前記複数のＷｅｂサイト内の各Ｗｅｂサイトが分類されるクラスタ用のテンプレートを識別するための手段と、
    前記複数のＷｅｂサイト内の各Ｗｅｂサイト用の前記識別されたテンプレートに基づいて、前記複数のＷｅｂサイト内のＷｅｂサイトにリソースを割り振るための手段とを含み、
    前記リソースを割り振る手段は、前記複数のＷｅｂサイトのうち、２つまたはそれ以上のＷｅｂサイト用の前記テンプレートに基づいて、コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトを識別し、
    コロケーション用の候補である前記２つまたはそれ以上のＷｅｂサイトの前記識別に基づいて、前記２つまたはそれ以上のＷｅｂサイトにリソースを割り振る、装置。

Images