JP2007133896A - サーバ負荷分散システム、サーバ負荷分散装置、コンテンツ管理装置、及びサーバ負荷分散プログラム - Google Patents

Abstract

【課題】 クライアントが要求するコンテンツを配信するコンテンツサーバを、要求されたコンテンツの特性毎に定められた選択基準に基づいて選択することにより、コンテンツの配信の負荷を適切に分散処理するサーバ負荷分散システムを提供する。
【解決手段】 複数のコンテンツサーバＡ２によりコンテンツのクライアントＤ１への配信を分散処理するサーバ負荷分散システムにおいて、各コンテンツにおける特性毎に当該コンテンツを配信するコンテンツサーバＡ２を決定するための選択基準を設定する転送先サーバ決定ポリシ設定手段Ｃ１２と、クライアントＤ１から要求されたコンテンツを配信するコンテンツサーバＡ２を要求されたコンテンツの特性に該当する選択基準に基づいて決定する転送先サーバ決定手段Ｃ１３を備えることを特徴とする。
【選択図】 図７

Description

本発明は、サーバ負荷の分散に関し、特にＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）コンテンツや動画コンテンツなどの配信用コンテンツを取得するためのクライアントからのリクエストに対して、適切なサーバを選択し、該リクエストを選択したサーバに対して送信するサーバ負荷分散システム、サーバ負荷分散装置、コンテンツ管理装置、コンテンツサーバ、及びサーバ負荷分散プログラムに関する。

近年、インターネットを介したＷＷＷコンテンツや動画コンテンツの配信において、同一コンテンツを複数のサーバに分散配置することにより、サーバの負荷分散及びクライアントの受けるレスポンス時間の短縮を実現する方法が種々提案されている。

このようにコンテンツが網内に分散配置されている環境下においては、コンテンツを取得するためのクライアントからのリクエストをどのサーバに送信すべきかを決定するためのサーバ負荷分散装置が必要になる。

従来技術として、特開２００１−１０１１３４号公報では、サービス毎にサーバの負荷をシミュレーションによって予測し、サーバが過負荷又は高負荷にならないようにクライアントのリクエストを振り分ける装置について記載されている。本公報に記載された装置では、転送先サーバ選択はサーバ負荷のみに着目して行われており、また、転送先サーバはサービス単位で選択される。

また、特開平０９−１９８３４６号公報では、クライアントにおける転送先サーバの選択方式について記載されている。この公報に記載されたサーバ選択方式は、個々のクライアントからの多様なサーバ選択要求に対応するために、ディレクトリサーバへの問い合わせメッセージに選択ポリシを格納することを特徴とする。問い合わせを受けたディレクトリサーバは、メッセージに格納された選択ポリシに基づいて最適なサーバを選択し、クライアントに応答する。本方式はクライアントにおける選択方式であるため、クライアントが本方式を導入せねばならなかった。サーバ負荷分散装置において本方式のように多様な選択基準をサポートできれば、クライアントにおける方式を変更することなく透過的に同等のサービスが実現できる。
特開２００１−１０１１３４号公報 特開平０９−１９８３４６号公報

しかし上述した従来の技術では、以下に述べるような問題点があった。

第１に、コンテンツサーバ内において、必ずしもコンテンツの特性毎にコンテンツがグループ化されておらず、もしされるとしてもその静的な特性だけでなされているという問題点があった。

コンテンツサーバ内のコンテンツは、一般的には、コンテンツ管理者にとって管理しやすいように配置されており、コンテンツの特性という観点でグループ化されていない。例えば、ニュースに関する「／ｎｅｗｓ／」ディレクトリの配下には、ニュースの記事、写真、映像など、ファイルサイズやメディア種類の点で異なる特性をもつコンテンツが混在した状態で一緒に配置されているのが普通である。また、それぞれのコンテンツに対するアクセス頻度といった動的な特性（パラメータ）も考慮されていない。このとき、クライアント側のサーバ負荷分散装置において、「／ｎｅｗｓ／」ディレクトリに対して同一のコンテンツサーバを転送先として選択すると、コンテンツの特性によっては必ずしもコンテンツ取得遅延などの観点から最適ではない可能性がある。従って、転送先サーバ選択は、コンテンツのサイズやアクセス頻度等の観点で同様の特性をもつものを同一グループとしたコンテンツグループ単位でなされるべきである。

第２に、サーバ負荷分散装置において各コンテンツの特性に応じて転送先サーバの選択基準を変えることができないため、効果的な負荷分散を実現できないという問題点があった。

従来技術では、転送先サーバの選択基準は固定的であり、コンテンツの特性に応じて選択基準を変えることができなかった。例えば、サイズの小さいコンテンツと大きいコンテンツの２種類を考えると、クライアントにおけるレスポンス時間は、サイズの小さいコンテンツの場合は転送経路における遅延が大きく影響するのに対し、反対に大きいコンテンツの場合は転送経路の利用可能帯域が大きく影響する。このような場合に、従来技術では、２つ又は２つ以上の異なる種類のコンテンツに対してそれぞれ異なる選択基準を用いるということができなかった。

第３に、クライアント側に配置された各サーバ負荷分散装置が互いに独自に転送先サーバを選択すると、同一のサーバに負荷が集中し、かえって配信品質が劣化してしまう可能性があるという問題点があった。

特に、ストリームや音声などの連続メディアコンテンツの配信の場合に同一のサーバにアクセスが集中すると、予期していた配信品質が得られず、再度転送先サーバ選択を行なう必要がでてくる。更に、配信中のコネクションを同時に全て切り替えると、切り替え後の新規の配信サーバへのアクセス集中によって再度配信品質が劣化し、配信サーバの切り替えを繰り返すという、発振現象が発生する可能性がある。

第４に、コンテンツ又はコンテンツグループ単位で転送先サーバを選択するようなサーバ負荷分散装置は、クライアントからのリクエストの中身をみて、転送先サーバを決定する必要があるため、レイヤ７スイッチを用いて実現する必要があるという問題点があった。

レイヤ７スイッチを用いれば、クライアントからのリクエストをコンテンツ単位で設定された転送先サーバに振り分けることができるが、レイヤ３スイッチやレイヤ４スイッチなどの低レイヤでスイッチングを行なう機器と比較すると、処理性能が低く、またコストも高い。従って、よりリクエストの中身をみる必要なく、低レイヤでスイッチングを行なう機器を用いて同等の機能を実現できることが望ましい。

本発明の第１の目的は、上記従来技術の欠点を解決し、コンテンツサーバ内のコンテンツをその特性に応じて自動的にかつ静的／動的にグループ化することのできるサーバ負荷分散システム、コンテンツ管理装置、コンテンツ管理プログラムを提供することである。

本発明の第２の目的は、上記従来技術の欠点を解決し、各コンテンツの特性に応じて転送先サーバの選択基準を変えることができるサーバ負荷分散システム、サーバ負荷分散装置、及びサーバ負荷分散プログラムを提供することである。

本発明の第３の目的は、上記従来技術の欠点を解決し、連続メディアコンテンツの配信に際して、特定のサーバへ集中しないように適切に分散処理するサーバ負荷分散システム、サーバ負荷分散装置、コンテンツサーバ、及びコンテンツ配信管理プログラムを提供することである。

本発明の第４の目的は、上記従来技術の欠点を解決し、レイヤ７スイッチ機能を必要とせずに、コンテンツグループ単位での転送先サーバ選択を実現するサーバ負荷分散システム、サーバ負荷分散装置、及びサーバ負荷分散プログラムを提供することである。

上記目的を達成するため本発明は、クライアントへコンテンツを配信するコンテンツサーバを、複数のコンテンツサーバの中から選択するサーバ負荷分散装置において、前記クライアントから受信したコンテンツの配信を要求するメッセージもしくはパケットに含まれる情報に基づいて、前記クライアントにコンテンツを配信する前記コンテンツサーバを決定し、決定した前記コンテンツサーバに対して受信した前記コンテンツの配信を要求するメッセージもしくはパケットを転送する手段を備え、受信した前記メッセージもしくはパケットに含まれる情報を用いて、前記情報を一意に示すＦＱＤＮを新規に作成し、前記新規に作成したＦＱＤＮをキーにしてドメインネームサーバに問い合わせることによって前記受信したメッセージもしくはパケットを転送すべき宛先である前記クライアントにコンテンツを配信する前記コンテンツサーバの候補を取得し、前記候補の中から前記クライアントにコンテンツを配信する前記コンテンツサーバを決定することを特徴とする。

本発明によれば、各コンテンツのグループの特性に応じてコンテンツサーバの選択基準を変えることにより、クライアントからのリクエストを常に最適なコンテンツサーバに転送するという効果を達成することができる。

（第１の実施の形態）
次に、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態の構成）
図１を参照すると、本発明の第１の実施の形態は、コンテンツサーバＡ１と、コンテンツ管理装置Ｂ１とによって実現される。また、コンテンツサーバＡ１上のコンテンツに対してアクセスするクライアントＤ１がバックボーン１を介して上記コンテンツ管理装置Ｂ１と接続されている。

コンテンツサーバＡ１は、コンテンツ記憶部Ａ１１と、動的パラメータ格納部Ａ１６を含む。コンテンツ記憶部Ａ１１は、ＷＷＷコンテンツや動画コンテンツなどの配信用コンテンツ自身や、コンテンツに付随するプログラム、プログラム実行に必要なデータベース等を保持している。また、各コンテンツは、クライアント側からは識別子によって識別され、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ではＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）によってコンテンツが識別される。動的パラメータ格納部Ａ１６には、コンテンツ管理装置Ｂ１によって参照される各配信コンテンツ毎のアクセス頻度やＣＰＵ負荷等といった動的な特性としての動的パラメータ（リソース情報）が格納されている。この動的パラメータの内容は、コンテンツサーバＡ１によって逐次更新される。なお、以下でリソース値とは、アクセス頻度やＣＰＵ負荷等を具体的に示す数値である必要はなく、それらの度合いを示す情報であればよい。

コンテンツ管理装置Ｂ１は、分類ポリシ設定部Ｂ１１と、コンテンツ分類部Ｂ１２と、コンテンツ集約部Ｂ１３とを含む。分類ポリシ設定部Ｂ１１は、コンテンツ記憶部Ａ１１内に含まれているコンテンツをその特性（コンテンツの種類やサイズ等の静的な特性及びアクセス頻度等の動的な特性）に応じてグループ化するための分類ポリシを設定する。

ここで、分類ポリシとは、ファイル、ストリーム、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）コンテンツといった、コンテンツをメディアの種類毎に大まかに分類するための情報が格納されている。更に、分類された各種類に対して、更に細かく分類するための情報が含まれていてもよい。例えばファイルに対しては、そのサイズに応じて、大・中・小の３つに分けるといったポリシや、ストリームに対しては、その転送レートに応じて高・中・低の３つに分けるといったポリシがある。あるいは、アクセス頻度の高・中・低といった動的な特性に基づくポリシでもよい。

図２は、分類ポリシ設定部Ｂ１１内に設定されている分類ポリシを示す分類ポリシテーブル１０１の一例である。例えば、ファイルに分類されるコンテンツは、そのサイズによって、大・中・小の３つのグループに分類され、更にサイズ大に分類されたグループは、そのアクセス頻度に応じて高・低の２つのグループに分類される。更に、設定されたポリシによって分類されたコンテンツグループが集約されるべきＵＲＬが示されている。

コンテンツ分類部Ｂ１２は、分類ポリシ設定部Ｂ１１によって設定された分類ポリシに基づいてコンテンツ記憶部Ａ１１内のコンテンツを分類する。この分類の際に、各コンテンツ自身から取得できる種類やサイズといった静的パラメータと、上記動的パラメータ格納部Ａ１６に格納されているアクセス頻度等の動的パラメータが参照される。例えば、まず、コンテンツをファイル、ストリーム、ＣＧＩなどのメディアの種類毎に分類する。次に、各メディアの種類毎に更に細かい分類ポリシが設定されている場合は、そのポリシに従って例えばファイルサイズやアクセス頻度等に応じた複数のコンテンツグループに分類する。

コンテンツ集約部Ｂ１３は、コンテンツ分類部Ｂ１２によってコンテンツを自動分類した結果に基づいて、各コンテンツグループ毎にコンテンツを集約する。ＵＲＬの場合を例に挙げると、ＵＲＬは、コンテンツ記憶部Ａ１１内でコンテンツの配置されているディレクトリを用いて表現される。しかしながら、コンテンツ分類部Ｂ１２によって作成されたコンテンツグループ内の各コンテンツは必ずしも同一のディレクトリの下に集約されているとは限らず、クライアントＤ１で各コンテンツがどのコンテンツグループに属するのかを識別するのは困難である。従って、同一コンテンツグループ内のコンテンツが同一のディレクトリ下に配置されるようにＵＲＬを書き換える処理を行なう。

図２に示す分類ポリシテーブル１０１の一例では、分類されたコンテンツグループが集約されるべきＵＲＬが示されており、例えば、ＣＧＩであり、ＣＰＵに対する負荷が高いと分類されたコンテンツは、全て「／ｃｇｉ／ｈｉｇｈ−ｌｏａｄ／」のディレクトリ配下に変更される。

図３は、ＵＲＬ書き換え処理を具体的に説明するための図である。例えば、オリジナルのディレクトリパスが「／ｐｕｂ／ｚ．ｅｘｅ」であるコンテンツが、設定されたポリシによる分類後、「／ｃｇｉ／ｈｉｇｈ−ｌｏａｄ／」のディレクトリ配下に集約されるべきとされたとする。すると、「／ｃｇｉ／ｈｉｇｈ−ｌｏａｄ／ｚ．ｅｘｅ」というディレクトリパスをもつコンテンツが、「／ｐｕｂ／ｚ．ｅｘｅ」へのシンボリックリンクとして生成される。また、「／ｐｕｂ／ｚ．ｅｘｅ」を参照しているｗｅｂページ内の参照リンクは、全て集約後のディレクトリパスに書き換えられる。

（第１の実施の形態の動作）
次に、図４を参照して、本実施の形態において、コンテンツ管理装置Ｂ１におけるコンテンツの特性に応じた自動的なグループ化の動作について詳細に説明する。

コンテンツ管理装置Ｂ１において、コンテンツ分類部Ｂ１２は、分類ポリシ設定部Ｂ１１内に設定されているコンテンツの分類ポリシを読み出し（図４のステップＳ１０１）、読み出した分類ポリシに従ってコンテンツ記憶部Ａ１１内の各コンテンツを複数メディア種類に分類する（ステップＳ１０２）。

複数メディア種類へのコンテンツの分類が完了すると、コンテンツ分類部Ｂ１２は、分類した各メディア種類毎に各コンテンツを複数のコンテンツグループに分類する（ステップＳ１０３）。このステップはコンテンツのサイズやアクセス頻度などの詳細な特性に応じた分類であり、動的パラメータ格納部Ａ１６に格納されているアクセス頻度等の動的パラメータが参照される。

複数メディア種類への分類、及び各メディア種類毎のコンテンツグループへの分類が完了すると、コンテンツ集約部Ｂ１３を用いてコンテンツグループ毎にコンテンツを集約する（ステップＳ１０４）。

本実施の形態において、コンテンツ管理装置Ｂ１は、ここでは独立したノード内に実現されるものとして説明したが、その他にも、図５に示すようにコンテンツサーバＡ１の一部の機能としてコンテンツ管理装置Ｂ１を実現することもできる。また、第２の実施の形態で説明するサーバ負荷分散装置Ｃ１も含めた任意のノード上で実現することができると共に、ゲートウェイ装置の一機能として実現することもできる。

さらに、上記説明では、一台のコンテンツサーバＡ１がコンテンツ管理装置Ｂ１に接続される場合を説明したが、図６に示すように、コンテンツ管理装置Ｂ１に複数台のコンテンツサーバＡ１が接続され、コンテンツ管理装置Ａ１がコンテンツサーバＡ１毎にコンテンツを分類して管理するように構成することもできる。

（第１の実施の形態の効果）
次に、本実施の形態の効果について説明する。本実施の形態では、コンテンツ管理装置Ｂ１は、コンテンツサーバ内のコンテンツをその特性に応じて自動的に分類する。この分類を動的な特性に応じて行なうこともできるのも特徴である。

更に、分類の結果作成されたコンテンツグループを自動的に集約する。コンテンツサーバ内のコンテンツは、最初から特性毎に同一ディレクトリ下にグループ化されて配置されるわけではない。例えば、ニュースに関する「／ｎｅｗｓ／」ディレクトリの配下には、ニュースの記事、写真、映像など、ファイルサイズやメディア種類の点で異なる特性をもつコンテンツが混在した状態で一緒に配置されているのが普通である。

本実施の形態により、同一の特性をもつコンテンツ群を同一ディレクトリ下に再構成することができ、後述するクライアント側のサーバ負荷分散装置においてこのディレクトリ単位で最適サーバを選択すると、コンテンツの特性に応じた最適なリクエストルーティングを最小のエントリ数で実現することができる。

（第２の実施の形態）
次に、本発明の第２の実施の形態について図面を参照して詳細に説明する。

（第２の実施の形態の構成）
図７を参照すると、本発明の第２の実施の形態は、コンテンツサーバＡ２と、サーバ負荷分散装置Ｃ１と、クライアントＤ１とによって実現される。

コンテンツサーバＡ２は、配信する各種コンテンツを記憶するコンテンツ記憶部Ａ１１と、リクエスト受信／コンテンツ応答部Ａ１２と、リソース応答部Ａ１３とを含む。

リクエスト受信／コンテンツ応答部Ａ１２は、クライアントＤ１側から受信したリクエストを受信し、応答すべきコンテンツを識別する。そしてクライアントＤ１側に対して該コンテンツを送信する。

リソース応答部Ａ１３は、サーバ負荷分散装置Ｃ１からのリソース情報取得要求に応答し、その要求内容に応じて、サーバ負荷、コネクション数、リンク使用率などのリソースパラメータを応答する。サーバ負荷分散装置Ｃ１がコンテンツサーバＡ２に対してリソース情報取得要求を行なわない場合は、このリソース応答部Ａ１３を省くことができる。

サーバ負荷分散装置Ｃ１は、リソース取得部Ｃ１１と、転送先サーバ決定ポリシ設定部Ｃ１２と、転送先サーバ決定部Ｃ１３と、リクエストルーティングテーブルＣ１４と、リクエスト受信部Ｃ１５と、リクエスト転送部Ｃ１６と、コンテンツ受信／転送部Ｃ１７とを含む。このサーバ負荷分散装置Ｃ１は、例えば複数のクライアントからの要求を集中的に管理するプロキシサーバの一部の機能として実現することが可能である。

リソース取得部Ｃ１１は、コンテンツサーバに関するリソース情報、例えばリクエストルーティングテーブルＣ１４に転送先サーバやその他候補サーバとして登録されていない場合に、転送先サーバとして登録するために必要となるリソース情報や、リクエストルーティングテーブルＣ１４内に登録されている転送先サーバやその他の候補サーバに関するリソース情報を取得する。リソース情報の例として、ＷｅｂサーバまでのＲＴＴ（ラウンドトリップタイム； Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）や、転送スループットといった網内リソースパラメータや、Ｗｅｂサーバの負荷、コネクション数といったサーバ自身に関するリソースパラメータなどがある。リソース情報取得には大きく分けて２つの方法がある。

１つは、コンテンツサーバＡ２に対してＣＰＵ負荷、自ノードまでの残余帯域値などの情報を要求して取得する方法（アクティブ型）であり、もう１つは、コンテンツ受信／転送部Ｃ１７から、受信したコンテンツの転送に要した遅延、得られた転送スループットを取得する方法（パッシブ型）である。パッシブ型の方法を用いて、サーバのＣＰＵ負荷やセッション数などを間接的に予測したりすることも可能である。

さらに、取得したリソースパラメータから、他のリソースパラメータを予測したり、あるいは抽出するということも可能である。例えば、（１）サイズの小さいコンテンツに対して計測されたコンテンツ取得時間を、ＲＴＴとみなす、（２）プログラム実行負荷の大きなＣＧＩコンテンツに対するコンテンツ取得時間を、サーバ負荷とみなす、といった方法が考えられる。

転送先サーバ決定ポリシ設定部Ｃ１２は、各コンテンツの特性に応じた転送先サーバを選択するためのポリシを示す転送先サーバ決定ポリシテーブル１０３を設定する。

図８は、転送先サーバ決定ポリシ設定部Ｃ１２内に設定されるポリシを示す転送先サーバ決定ポリシテーブル１０３の一例である。この転送先サーバ決定ポリシテーブル１０３では、ファイルの特性をもつコンテンツグループに対してはコンテンツ取得時の転送スループットが用いられ、この値が最大となるサーバを基準として、６０％までの値をもつサーバが転送先サーバとして選択される。また、ＣＧＩの特性をもつコンテンツグループに対しては、ＣＰＵ負荷にサーバまでのＲＴＴを掛けた値が用いられ、この値が小さい順に３つのサーバが選択される。

転送先サーバ決定部Ｃ１３は、リソース取得部Ｃ１１によって取得したリソースパラメータの中から、転送先サーバ決定ポリシ設定部Ｃ１２において設定されたリソースパラメータを用いて転送先サーバを決定する。

リクエストルーティングテーブルＣ１４は、リクエスト受信部Ｃ１５によって受信したリクエストをどのサーバに転送すべきかを示すテーブルである。テーブル内のエントリは、転送先サーバ決定部Ｃ１３によって書き込まれる。

図９は、リクエストルーティングテーブルＣ１４の一例を示すテーブル１０４である。このテーブル１０４によると、リクエストするコンテンツのＵＲＬに対する転送先サーバのＩＰアドレスが書かれている。

例えばＵＲＬが、「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｎｅｔ／ｃｇｉ／ｈｉｇｈ／＊」のエントリは、ＵＲＬの先頭部分が「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｎｅｔ／ｃｇｉ／ｈｉｇｈ／」を含む全てのＵＲＬを表すＵＲＬプレフィクス表現になっている。このエントリに対応するリクエストは、「１０．２．５．２」のＩＰアドレスをもつコンテンツサーバへ転送される。また、ＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ｃｃｃ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／＊．ｊｐｇ」に対応するエントリは、「ｈｔｔｐ：／／ｗｗｗ．ｃｃｃ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／」以下にあるコンテンツの内、ファイル拡張子としてｊｐｇをもつもの全てに対応する。このエントリに対応するリクエストは、「１０．４．２．１」のＩＰアドレスをもつコンテンツサーバか、「１０．２．５．２」のＩＰアドレスをもつコンテンツサーバへ転送される。

このように複数の転送先サーバＩＰアドレスが指定されている場合は、リクエスト毎にラウンドロビンでいずれかのサーバが選択されるか、あるいはウェイテッドラウンドロビン（Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎ）や重みつきハッシュ関数などを用いて、各サーバ毎に指定されたウェイト、すなわち優先度の比に応じて選択することもできる。

リクエスト受信部Ｃ１５は、クライアントＤ１からのリクエストを受信し、その内容を解析する。該リクエストの内容を解析することによって、クライアントＤ１がリクエストしているコンテンツのＵＲＬを識別する。更に該リクエストをどのサーバに転送すべきかをリクエストルーティングテーブルＣ１４を参照して解決し、リクエスト転送部Ｃ１６へ渡す。

リクエスト転送部Ｃ１６は、リクエスト受信部Ｃ１５から転送すべきリクエストの内容と転送すべきサーバ情報を受け取り、該コンテンツサーバＡ２に対して該リクエストを転送する。

コンテンツ受信／転送部Ｃ１７は、リクエスト転送部Ｃ１６が行なったリクエストに対するコンテンツサーバＡ２からの応答コンテンツを受信し、クライアントＤ１に対して該コンテンツを転送する。

クライアントＤ１は、コンテンツサーバＡ２内のコンテンツを取得するリクエストを出すものである。該リクエストは、サーバ負荷分散装置によって指定されたコンテンツサーバＡ２へと誘導される。ここでは、クライアントＤ１は、１台ではなく、複数のクライアントを示すものとする。

（第２の実施の形態の動作）
次に、図１０〜図１２を参照して、本実施の形態において、サーバ負荷分散装置Ｃ１における各コンテンツの特性に応じて選択基準を変えながら転送先サーバを選択する動作について詳細に説明する。

まず図１０を用いてサーバ負荷分散装置Ｃ１がクライアントＤ１からコンテンツを取得するリクエストを受信したときの動作を説明する。

サーバ負荷分散装置Ｃ１において、リクエスト受信部Ｃ１５がクライアントＤ１からリクエストを受信すると、該リクエストを解析し、リクエストしているコンテンツのＵＲＬを識別する（図１０のステップＳ２０１）。

次に、リクエスト受信部Ｃ１５は、リクエストしているコンテンツの識別子に対して、リクエストルーティングテーブル１０４内に該コンテンツに対するエントリがあるかどうかをチェックする（ステップＳ２０２）。

ステップＳ２０２において、該コンテンツに対するエントリが存在する場合、リクエスト受信部Ｃ１５は該エントリを参照し、リクエストを転送すべきコンテンツサーバＡ２を読み込む（ステップＳ２０３）。そして、リクエスト転送部Ｃ１６は、リクエスト受信部から転送すべきリクエストと転送すべきコンテンツサーバＡ２の情報を受け取り、該コンテンツサーバＡ２へリクエストを転送する（ステップＳ２０４）。

ステップＳ２０２において、該コンテンツに対するエントリが存在しない場合、デフォルトサーバへリクエストを転送し（ステップＳ２０５）、リクエストのあったコンテンツを含むコンテンツグループに対して転送先サーバを決定し、リクエストルーティングテーブルに転送先サーバのエントリを書き込む動作を行なう（ステップＳ２０６）。ここでデフォルトサーバとは、該リクエストをデータとして含むＩＰパケットの宛先ＩＰアドレスに対応するサーバや、該リクエスト中のＵＲＬのＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ：完全修飾ドメイン名）部分から、ドメインネームサーバ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ； ＤＮＳ）を用いて解決したＩＰアドレスに対応するサーバなどを意味する。

上記ステップＳ２０６に対応する動作を詳細に説明するためのフローチャートが図１１である。

転送先サーバ決定部Ｃ１３は、リクエストのあったコンテンツはどのコンテンツグループに属するのかを識別し、該コンテンツグループに対する候補サーバリストを取得する（図１１のステップＳ３０１）。ここでの識別／取得方法として、該リクエスト中のＵＲＬの全部又は一部分をキーにして、コンテンツ管理装置Ｂ１に問い合わせる方法や、直接コンテンツサーバＡ２に問い合わせる方法などがある。ここで、候補サーバとは、該コンテンツグループを保持する全てのコンテンツサーバＡ２、又は該コンテンツグループを保持する全てのコンテンツサーバＡ２の中から一部を抽出したサーバ群のことである。

また、該ＵＲＬに対するコンテンツグループ識別及び候補サーバリスト取得のためにドメインネームサーバを用いる方法もある。この場合は、該コンテンツグループ毎にユニークなＦＱＤＮを求め、該ＦＱＤＮをキーにして解決したＩＰアドレスの各々に対応するコンテンツサーバを候補サーバとする。該コンテンツグループ毎にユニークなＦＱＤＮの生成方法の例として、リクエストされたコンテンツに対するＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｎｅｔ／ｃｇｉ／ｈｉｇｈ／ｐｒｏｇ．ｃｇｉ」である場合、「ｈｉｇｈ．ｃｇｉ．ｗｗｗ．ａａａ．ｎｅｔ」を該コンテンツの属するコンテンツグループに対応するＦＱＤＮとし、該ＦＱＤＮをキーにして候補サーバのＩＰアドレスを解決する方法などがある。

次に、転送先サーバ決定部Ｃ１３は、該コンテンツグループが転送先サーバ決定ポリシ設定部Ｃ１２のどの転送先サーバ決定ポリシに対応するのかを識別し、対応する転送先サーバ設定ポリシを読み込む（ステップＳ３０２）。この対応関係の識別方法として、例えば以下の２つの方法がある。

（１）ステップ３０１でコンテンツ管理装置Ｂ１に問い合わせる場合に、問い合わせ時に該コンテンツグループのコンテンツ特性の情報も一緒に取得する。

（２）サーバ負荷分散装置Ｃ１内に、ＵＲＬや宛先ポート番号に対応するコンテンツ特性をマッピングしたテーブル（例えば、ＵＲＬにｃｇｉ−ｂｉｎを含むコンテンツグループのコンテンツ特性はＣＧＩであり、宛先ポート番号５５４であるコンテンツグループのコンテンツ特性はストリームであるといった対応関係）。

更に、転送先サーバ決定部Ｃ１３は、ステップＳ３０２で読み込んだ転送先サーバ設定ポリシから、該コンテンツグループに対する転送先サーバを決定するために、候補サーバから直接コンテンツを取得することによりリソース取得を行なう、すなわちパッシブ型のリソース測定が必要かどうかをチェックする（ステップＳ３０３）。

パッシブ型のリソース測定が必要のある場合の例として、コンテンツの転送遅延、転送スループットなどのリソースパラメータを転送先サーバ決定に用いる場合が挙げられる。また、反対にパッシブ型のリソース測定を行なう必要のない場合の例として、サーバ負荷、リンク帯域などのリソースパラメータを問い合わせにより取得し、その結果を利用して転送先サーバ決定に用いるアクティブ型のリソース測定が行われる場合が挙げられる。なお、パッシブ型のリソース測定とアクティブ型のリソース測定を混ぜて転送先サーバの決定を行なってもよい。

ステップＳ３０３において、パッシブ型のリソース測定を行なって転送先サーバを調べる必要がある場合、転送先サーバ決定部Ｃ１３は、候補サーバをリクエストルーティングテーブルＣ１４に書き込む（ステップＳ３０４）。

ステップＳ３０４で候補サーバがリクエストルーティングテーブルＣ１４に書き込まれると、リクエストルーティングテーブルＣ１４は、該コンテンツグループに含まれるコンテンツに対するリクエストの転送先として、候補サーバの中から１つのコンテンツサーバを選択する。

このときラウンドロビンで転送先を選択するなどして、リクエストが全ての候補サーバに転送されるようにする。リクエストを各候補サーバへ振り分けることにより、コンテンツ受信／転送部Ｃ１７は各候補サーバからコンテンツを受信し、リソース取得部Ｃ１１はその際の転送遅延、（単位時間あたりのコンテンツの受信量を測定することで）転送スループット等のリソースパラメータを知ることができる（ステップＳ３０５）。

ついで、アクティブ型のリソース測定が必要であるかどうかをチェックする（ステップＳ３０６）。すなわち、ステップ３０５によるパッシブ型のリソース測定だけでは十分なリソースパラメータを取得できない場合等には、アクティブ型のリソース測定が必要であるとして、ステップＳ３０７でアクティブ型のリソース測定がなされる。

ステップＳ３０３において、パッシブ型のリソース測定を行なって転送先サーバを調べる必要がない場合、またステップ３０６でアクティブ型のリソース測定が必要と判定された場合、転送先サーバ決定部Ｃ１３はリソース取得部Ｃ１１を用いて必要なリソースパラメータを測定し取得する（ステップＳ３０７）。

ステップＳ３０５又はステップＳ３０７によって転送先サーバ決定に必要なリソースパラメータを取得すると、転送先サーバ決定部Ｃ１３は該リソースパラメータ及びステップＳ３０１で読み込んだ転送先サーバ設定ポリシを用いて転送先サーバを決定する（ステップＳ３０８）。このとき複数のコンテンツサーバを転送先サーバとして決定してもよい。

そして決定した転送先サーバのエントリをリクエストルーティングテーブルＣ１４における該当コンテンツグループに対するリクエスト転送先として書き込む（ステップＳ３０９）。複数のエントリを書き込む場合、各コンテンツサーバへリクエストが転送される割合、重み付けを同時に書き込んでもよい。

ステップＳ３０９で転送先サーバをリクエストルーティングテーブルＣ１４に書き込むと、書き込んだエントリを維持管理する状態に移行する（ステップＳ３１０）。

ステップＳ３１０に対応する動作を詳細に説明するためのフローチャートが図１２である。

リクエストルーティングテーブルＣ１４は、維持管理すべき転送先サーバエントリに対するリクエストを一定時間以内に受信したかどうかを定期的にチェックする（図１２のステップＳ４０１）。もし一定時間以上リクエストを受信していない場合は該エントリを削除する（ステップＳ４０４）。

一定時間以内に該エントリに対するリクエストを受信している場合は、更に、該エントリに対する候補サーバについて、転送先サーバを決定したときのリソース値と比べて予め設定した閾値以上の変化があるかどうかをリソース取得部Ｃ１１を用いてチェックする（ステップＳ４０２）。このチェックは、ステップＳ３０７で決定した転送先サーバが現在もなお最適であるかどうかを調べるためのものである。閾値以上の変化がない場合は、再度ステップＳ４０１に戻る。

ステップＳ４０２において、閾値以上の変化があった場合は、ステップＳ３０１へ戻り、再度転送先サーバを決定する動作を行なう（ステップＳ４０３）。

（第２の実施の形態の効果）
次に、本実施の形態の効果について説明する。

本実施の形態では、サーバ負荷分散装置は、コンテンツグループ毎に異なるポリシで転送先サーバを決定し、リクエストルーティングテーブルに登録する。従来は、全てのコンテンツグループに対して同一の基準で転送先サーバが選択されていたため、コンテンツグループによっては必ずしも最適なサーバが選択されているとはいえなかった。本実施の形態では、各コンテンツグループの特性に応じて転送先サーバの選択基準を変えることにより、クライアントからのリクエストは常に最適なサーバに転送される。特に、コンテンツの特性に応じてコンテンツグループを自動生成する第１の実施の形態と組み合わせることにより、サーバ選択がより効果的に実現される。

（第３の実施の形態）
次に、本発明の第３の実施の形態について図面を参照して詳細に説明する。

（第３の実施の形態の構成）
図１３を参照すると、本発明の第３の実施の形態は、コンテンツサーバＡ３と、サーバ負荷分散装置Ｃ１とによって実現される。

コンテンツサーバＡ３は、第２の実施の形態におけるコンテンツサーバＡ２の構成に加え、リソース応答ポリシ設定部Ａ１４を含み、リソース応答部Ａ１３の代わりにリソース応答部Ａ１５を含む点が異なる。その他の構成については、図７に示した第２の実施の形態と同様である。

リソース応答ポリシ設定部Ａ１４は、サーバ負荷分散装置Ｃ１から受信したリソース情報取得要求に対して応答する際のポリシが設定されるものである。ここでポリシとは、自コンテンツサーバに過度のアクセスが集中しないようにするために用いられる。例えば、コンテンツサーバＡ３が、自ノードのＣＰＵ負荷が１０％と低い状態であるときに、複数のサーバ負荷分散装置からリソース情報取得要求を受信したとする。このとき、全てのサーバ負荷分散装置に対してＣＰＵ負荷の値を１０％と応答すると、この値を受信したサーバ負荷分散装置はコンテンツサーバＡ３のＣＰＵ負荷が十分に低いと判断し、コンテンツサーバＡ３を、リクエストを転送するべきサーバに選択する可能性がある。その結果、コンテンツサーバＡ３のＣＰＵ負荷が、アクセスの集中により急激に上昇し、十分なサーバ性能を提供できないということが起こりうる。最悪の場合、コンテンツサーバＡ３を転送先サーバとして選択したサーバ負荷分散装置全てが、サーバ性能劣化を検出して他のコンテンツサーバを転送先サーバとして再度選択し、今度は再度選択されたコンテンツサーバがアクセスの集中により性能が劣化してしまうという動作を再帰的に繰り返すという、発振現象が起こってしまう。

このような特定のコンテンツサーバに対するアクセス集中や、発振現象を防ぐためのポリシが設定される。ここでポリシの例としては、一定時間内に所定の閾値以上のリソースを応答しない、あるいは、一定時間内に所定の値以上のリソースを同時に応答するサーバ負荷分散装置の数をある閾値以内に抑えるといった内容等が考えられる。

図１４は、リソース応答ポリシ設定部Ａ１４内に設定されるポリシを示すリソース応答ポリシテーブル１０５の一例である。このリソース応答ポリシテーブル１０５では、リソースの種類に応じて応答ポリシが示されており、例えばＣＰＵ負荷にに関しては、現在のＣＰＵ負荷が０％〜３０％の場合は、３０％の確率で実際のＣＰＵ負荷の２倍の値を応答し（７０％の確率で実際の値を応答する）、３０％〜６０％の場合は、５０％の確率で実際のＣＰＵ負荷の１．５倍の値を応答し、６０％〜１００％の場合は実際の値を応答するという動作をする。

リソース応答部Ａ１５は、第１の実施の形態におけるリソース応答部Ａ１３と同様にサーバ負荷分散装置Ｃ１からのリソース情報取得要求に対して要求されたリソースパラメータを応答する。ただし、リソース応答時に、リソース応答ポリシ設定部Ａ１４内に設定されているリソース応答時のポリシを参照し、該ポリシに従って応答するリソース値を計算する。

（第３の実施の形態の動作）
次に、図１５を参照して、本実施の形態において、コンテンツサーバＡ３がサーバ負荷分散装置Ｃ１からリソース取得要求を受信したときの動作について詳細に説明する。

コンテンツサーバＡ３内のリソース応答部Ａ１５は、サーバ負荷分散装置Ｃ１からリソース情報取得要求を受信すると、自ノードにおける要求されたリソースパラメータに対応するリソース値を取得する（図１５のステップＳ５０１）。

次に、リソース応答部Ａ１５は、リソース応答ポリシ設定部Ａ１４から、該リソースパラメータに対するリソース応答ポリシを取得する（ステップＳ５０２）。

ステップＳ５０２の後、リソース応答部Ａ１５は、ステップＳ５０１で取得したリソースパラメータをその値のまま応答してよいかどうかをチェックする（ステップＳ５０３）。

ステップＳ５０３で、該リソースパラメータをその値のまま応答してよいと判定した場合、リソース応答部Ａ１５は、リソース情報取得要求を行なったサーバ負荷分散装置Ｃ１に対して該リソースパラメータを応答する（ステップＳ５０５）。

ステップＳ５０３で、該リソースパラメータをその値のまま応答しないと判定した場合、リソース応答部Ａ１５は、該リソースパラメータに対するリソース応答ポリシに基づいて、応答するリソース値を計算する（ステップＳ５０４）。そして計算したリソース値を、リソース情報取得要求を行なったサーバ負荷分散装置Ｃ１に対して該リソースパラメータとして応答する（ステップＳ５０５）。

（第３の実施の形態の効果）
次に、本実施の形態の効果について説明する。本実施の形態では、コンテンツサーバは、網内に配置されている複数のサーバ負荷分散装置からのリソース情報取得要求に対し、必ずしも実際のリソース情報をそのまま応答するのではなく、設定したリソース応答ポリシに応じてリソース値を補正して応答する。

各サーバ負荷分散装置は独立に転送先サーバを決定するため、従来技術のように実際のリソース情報をそのまま応答すると、同時に多数のサーバ負荷分散装置が自コンテンツサーバを転送先サーバとして選択することによってリクエストの急激な集中が生じる可能性があった。本実施の形態のように、リソース値を補正して応答することにより、急激なリクエストの集中を抑制することができる。

（第４の実施の形態）
次に、本発明の第４の実施の形態について図面を参照して詳細に説明する。

（第４の実施の形態の構成）
図１６を参照すると、本発明の第４の実施の形態は、コンテンツサーバＡ２と、サーバ負荷分散装置Ｃ２とによって実現される。

サーバ負荷分散装置Ｃ２は、第２の実施の形態におけるサーバ負荷分散装置Ｃ１の構成に加え、ウェイト設定部Ｃ１９を備えている。また、リクエストルーティングテーブルＣ１４の代わりにリクエストルーティングテーブルＣ１８が用いられる。

リクエストルーティングテーブルＣ１８は、第２の実施の形態で説明したリクエストルーティングとその機能は同じであるが、各エントリにおける転送先サーバＩＰアドレス毎に、その転送ウェイト値が指定されている点が異なる。ウェイテッドラウンドロビンや、重みつきハッシュ関数などを用いることにより、各サーバ毎に指定されたウェイト値の比で、リクエスト受信部へ応答するサーバが選択される。

また、リクエストルーティングテーブルＣ１４では、リクエストを転送しないサーバは登録されないが、リクエストルーティングテーブルＣ１８では、該コンテンツグループに対する候補サーバは全て登録される。このとき、リクエストを転送しないサーバはウェイト０％として登録される。図１７に、リクエストルーティングテーブルＣ１８の一例としてのテーブル１０６を示す。

ウェイト設定部Ｃ１９は、リクエストルーティングテーブルＣ１８内の転送ウェイト値を設定／変更する機能を有する。図１７におけるリクエストルーティングテーブル１０６においては、「ｒｔｓｐ：／／ｓｔｒｅａｍ．ｂｂｂ．ｏｒｇ／ｌｉｖｅ／＊」に対する転送先サーバＩＰアドレスは、「１０．５．１．１」、「１０．７．１．１」、「１０．４．２．１」、「１０．２．５．２」に対するウェイト値はそれぞれ２０％、２０％、１０％、５０％であるが、これを例えばそれぞれ３０％、３０％、２０％、２０％に変更するという動作をする。

（第４の実施の形態の動作）
次に、図１８を参照して、本実施の形態において、サーバ負荷分散装置Ｃ２における特定のサーバへの負荷集中を防ぐ動作について詳細に説明する。

転送先サーバ決定部Ｃ１３は、リクエストルーティングテーブルＣ１８内の各エントリ毎に、リソース取得部Ｃ１１を用いて登録されている転送先サーバに対するリソースを取得する（図１８のステップＳ６０１）。取得するリソースの種類は、転送先サーバ決定ポリシ設定部Ｃ１２内に設定されており、エントリ毎に異なっていてもよい。

各転送先サーバに対するリソースを取得すると、次に、転送先サーバ決定部Ｃ１３は、各サーバに対する取得したリソース値を比較し、サーバ間におけるリソース値の違いが予め設定された閾値を超えるかどうかを判別する（ステップＳ６０２）。この判別基準の例として、「取得したサーバ毎のリソース値の最大値は、最小値の２倍以上大きい」、「取得したサーバ毎の転送スループットの最大値と最小値の差は１Ｍｂｐｓ以上である」などが考えられる。

ステップＳ６０２で、サーバ間におけるリソース値の違いが予め設定された閾値を超えない場合はリクエストルーティングテーブルＣ１８において設定されているウェイト値を変更しないが、反対に超える場合は、ウェイト設定部Ｃ１９によって取得したリソース値に応じてウェイト値を再設定する（ステップＳ６０３）。

例えば、サーバＡ、サーバＢ、サーバＣと３つの転送先サーバが登録されており、それぞれに対するウェイト値が、３０％、５０％、２０％であったとする。そして取得した３つのサーバに対する転送スループットがそれぞれ６Ｍｂｐｓ、３Ｍｂｐｓ、１Ｍｂｐｓであったとする。このとき、転送スループットの比に応じて、６０％、３０％、１０％とウェイト値を変更する。

しかしながら、このようにリソース値の比に応じていきなりウェイト値を変更することは発振防止という観点からは望ましくない。上記の例の場合、ウェイト変更後、サーバＡに対するリクエストが３０％から６０％に増えるが、他の負荷分散装置においても同様にサーバＡに対するリクエストの比率を増やしていると、サーバＡの受けるリクエスト数が急激に増加することになり、サーバＡの転送スループットが大きく低下する可能性がある。すると再度ウェイト値の変更が必要になり、ウェイト変更動作が収束せずに発振してしまうことがある。発振を防止するためには、いきなりリソース値の比に応じてウェイト値を変更せずに、ウェイト変更の割合を、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを用いて制限する方法がある。ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙは、一度のウェイト値の変更を抑制するためのパラメータであり、１．０以下の値をとる。上記の例で、リソース値の比に応じてサーバＡに対するウェイト値を３０％→６０％に変更する場合は「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝１．０」に対応する。例えば、上記の例で、「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝０．３」とした場合、サーバＡに対しては、（６０％−３０％）×０．３＝９％だけウェイト値を変更することになり、変更後のウェイト値は３９％となる。同様に、サーバＢ、サーバＣに対しては、変更後のウェイト値はそれぞれ４４％、１７％となる。

このようにｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを用いて徐々にウェイト値を変更することによって、特定のサーバの受けるリクエスト数が急激に増加／減少することが抑制され、発振を抑止することができる。このとき発振が起こらないようにｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙの値を設定することが重要である。例えばフィードバック制御を用いて、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを発振が起こらない値に自動的に調整する方式などが考えられる。

転送先サーバ決定部は、リクエストルーティングテーブルＣ１８内の各エントリ毎に、ステップＳ６０１〜Ｓ６０３の動作を定期的に実行する。

図１８において説明した動作は、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを用い、その値を発振が起こらないように調節する必要があった。次に、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを調節する必要なく（すなわち「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝１．０」のままで）、コンテンツサーバに対する急激なリクエスト数の変動を抑止する方法についてその動作を詳細に説明する。

図１９を参照すると、ステップＳ６０２までは図１８で説明した動作と同様である。ステップＳ６０２において、リソース値の違いが閾値以上の場合、直ちにステップＳ６０３でウェイト値を変更する代わりに、ウェイト値を変更する時刻を決定する（図１９のステップＳ６０４）。ウェイト値を変更する時刻は確率的に決定され、例として、０分後〜１０分後の間の時刻で等確率で決定されるというものなどが考えられる。

ステップＳ６０４で決定した時刻に、再度リソース取得部Ｃ１１を用いて、リクエストルーティングテーブルＣ１８内の各エントリ毎に登録されている転送先サーバに対するリソースを取得する（ステップＳ６０５）。ステップＳ６０５で再度各転送先サーバに対するリソースを取得すると、再度ステップＳ６０２と同様の動作を行ない、各サーバ間におけるリソース値の違いが予め設定された閾値を超えるかどうかを判別する（ステップＳ６０６）。

ステップＳ６０６で、サーバ間におけるリソース値の違いが予め設定された閾値を超えない場合はリクエストルーティングテーブルＣ１８において設定されているウェイト値を変更せずに終了するが、反対に超える場合は、ウェイト設定部Ｃ１９によってステップＳ６０５で再度取得したリソース値に応じてウェイト値を再設定する（ステップＳ６０７）。

本動作では、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを調節する代わりに、ウェイト値を再設定する時刻を確率的に分散させた時間だけ遅延させることにより、コンテンツサーバに対する急激なリクエスト数の変動を抑止する。また、遅延させた時刻において再度ウェイト値を再設定するかどうかを判定し、必要ない場合は再設定を行なわないことにより、ウェイト値の不要な変更動作が抑止され、発振防止の効果が得られる。

（第４の実施の形態の効果）
次に、本実施の形態の効果について説明する。

本実施の形態では、サーバ負荷分散装置における各エントリの転送先サーバに対するウェイト値を取得したリソース値に応じて変更する。このウェイト値の変更を、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを用いて緩やかに行なうことにより、あるコンテンツサーバに対する急激なリクエスト数の変動を抑止することができる。また、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを調節する代わりに、ウェイト値を再設定する時刻を確率的に分散させた時間だけ遅延させることにより、同じ効果を得ることもできる。第３の実施の形態では、コンテンツサーバ側で急激なリクエスト数変動の抑止を実現していたが、本実施の形態では、コンテンツサーバ側に対しては変更を必要とせず、サーバ負荷分散装置側で同等の機能を実現する。

（第５の実施の形態）
次に、本発明の第５の実施の形態について図面を参照して詳細に説明する。

（第５の実施の形態の構成）
図２０を参照すると、本発明の第５の実施の形態は、コンテンツサーバＡ４と、サーバ負荷分散装置Ｃ３と、クライアントＤ２と、ドメインネームサーバＥ１とによって実現される。

コンテンツサーバＡ４は、コンテンツ記憶部Ａ１１と、リクエスト受信／コンテンツ応答部Ａ１２とを含む。それぞれの機能、動作については第２の実施の形態で述べた通りである。

サーバ負荷分散装置Ｃ３は、パケット受信部Ｃ２５と、パケット転送部Ｃ２０と、パケットルーティングテーブルＣ２１と、転送先サーバ決定部Ｃ２２と、ＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ：完全修飾ドメイン名）解決部Ｃ２３と、アドレス解決部Ｃ２４とを含む。

パケット受信部Ｃ２５は、クライアントＤ２からのパケットを受信し、該パケットの宛先ポート番号を調べる。調べた宛先ポート番号が予め設定された値に含まれる場合は、パケットルーティングテーブルＣ２１に登録されているエントリを参照し、該パケットの宛先ＩＰアドレスから、該パケットを転送すべきコンテンツサーバＡ４のＩＰアドレスを調べる。

パケット転送部Ｃ２０は、パケット受信部Ｃ２５が受信したパケットの宛先ＩＰアドレスを、転送すべきコンテンツサーバＡ４のＩＰアドレスに書き換え、該コンテンツサーバＡ４に対して送信する。

また、ＩＰアドレスを書き換えずに、レイヤ２レベルでのヘッダ書き換えのみを行ない、該パケットの転送を行なうこともできる。レイヤ２プロトコルとして、イーサネット（登録商標）が用いられる場合を考えると、転送すべきコンテンツサーバＡ４のＩＰアドレスから、ＡＲＰを用いて該コンテンツサーバＡ４のＭＡＣアドレスを解決し、該パケットの宛先ＩＰアドレスは書き換えずに、解決したＭＡＣアドレスを宛先ＭＡＣアドレスとしてパケットを転送する。以下では簡単のために、ＩＰアドレスを書き換えてパケットを転送する場合だけについて説明を行なう。

パケットルーティングテーブルＣ２１には、パケット受信部Ｃ２５が受信したパケットの宛先ＩＰアドレス／宛先ポート番号に対して、該パケットを転送すべきコンテンツサーバのＩＰアドレスが登録されている。

図２１は、パケットルーティングテーブルＣ２１の一例を示すテーブル１０７である。このテーブル１０７によると、例えば宛先ＩＰアドレスが「１０．１．１．１」、宛先ポート番号が「７０７０」番のパケットに対しては、宛先ＩＰアドレスが「２０．２．２．２」のコンテンツサーバか、「３０．３．３．３」のコンテンツサーバに転送される。

このとき、パケット毎に２つのコンテンツサーバのいずれかを交互に選ぶのではなく、同一のコネクションを同一のコンテンツサーバに接続させるために、同一のソースＩＰアドレス／ソースポート番号の組み合わせでハッシュ関数に掛けて、生成したハッシュ値を基にコンテンツサーバを選ぶという方法などが用いられる。また、受信パケットのＴＣＰヘッダのＳＹＮフラグ受信を契機に、該パケットと同じＩＰアドレス／ポート番号をもつパケットに対しては同じサーバへ転送させるように記憶しておくという方法もある。

転送先サーバ決定部Ｃ２２は、ある宛先ＩＰアドレス／宛先ポート番号をもつパケットに対して、転送先サーバ（コンテンツサーバＡ４）を決定する。ここで転送先サーバの決定には、第２の実施の形態の転送先サーバ決定部Ｃ１３で述べたのと同様の方法が適用できる。決定した転送先サーバを、パケットルーティングテーブルＣ２１のエントリとして書き込む。

ＦＱＤＮ解決部Ｃ２３は、転送先サーバ決定部Ｃ２２が、ある宛先ＩＰアドレス／宛先ポート番号をもつパケットの転送先となるコンテンツサーバＡ４を決定する動作の際に、該宛先ＩＰアドレスに対するＦＱＤＮをドメインネームサーバＥ１に対して問い合わせる。

アドレス解決部Ｃ２４は、転送先サーバ決定部Ｃ２２が、ある宛先ＩＰアドレスをもつパケットの転送先となるサーバを決定する動作の際に、ＦＱＤＮ解決部Ｃ２３によって該宛先ＩＰアドレスに対するＦＱＤＮを解決した後、解決したＦＱＤＮと該パケットの宛先ポート番号を用いて新規にＦＱＤＮを作成し、新規に作成したＦＱＤＮに対するＩＰアドレスを解決する。ここで新規に作成するＦＱＤＮは、パケットの宛先ＩＰアドレスと宛先ポート番号毎にユニークでなければならない。例えば、解決したＦＱＤＮが「ａａａ．ｃｏｍ」であり、該パケットの宛先ポート番号が「７０７０」であるとき、「ｐｏｒｔ７０７０．ａａａ．ｃｏｍ」というＦＱＤＮに対するＩＰアドレスを解決する。ここでは、複数のＩＰアドレスを解決することが可能であり、ＦＱＤＮ解決部Ｃ２３とアドレス解決部Ｃ２４を用いることで、該パケットの転送先となる候補サーバのＩＰアドレスの一覧を取得することができる。

クライアントＤ２は、リクエスト送信部Ｄ１１と、アドレス解決部Ｄ１２とを含む。

リクエスト送信部Ｄ１１は、コンテンツを取得するリクエストをＩＰパケットとして送信する。このとき、取得しようとするコンテンツの識別子であるＵＲＬから、アドレス解決部Ｄ１２を用いて該ＵＲＬのＦＱＤＮに対応するＩＰアドレスを解決し、解決したＩＰアドレスを送信するＩＰパケットの宛先ＩＰアドレスとする。また、ＵＲＬで指定されたポート番号を宛先ポート番号とする。例えば、ＵＲＬが「ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｐｉｃｔ．ｊｐｇ：７０７０」のコンテンツを取得するリクエストを送信する場合、「ａａａ．ｃｏｍ」に対するＩＰアドレスが「１０．１．１．１」であるとすると、宛先ＩＰアドレスが「１０．１．１．１」、宛先ポート番号が「７０７０」のパケットを送信する。

アドレス解決部Ｄ１２は、取得しようとするコンテンツのＵＲＬのＦＱＤＮ部分をキーにして、ドメインネームサーバＥ１に対してＩＰアドレスを問い合わせる。ドメインネームサーバＥ１からの応答には複数のＩＰアドレスが含まれていてもよい。この場合は、任意の１つのエントリを該ＦＱＤＮに対応するＩＰアドレスとして用いる。

ドメインネームサーバＥ１は、アドレス／ＦＱＤＮ解決テーブルＥ１１と、アドレス応答部Ｅ１２と、ＦＱＤＮ応答部Ｅ１３とを含む。

アドレス／ＦＱＤＮ解決テーブルＥ１１は、アドレス応答部Ｅ１２及びＦＱＤＮ応答部Ｅ１３が受けたアドレス解決要求及びＦＱＤＮ解決要求に対して応答する際に参照するテーブルであり、「ＦＱＤＮ→ＩＰアドレス」の変換テーブルであるアドレス解決用テーブル１０８と、「ＩＰアドレス→ＦＱＤＮ」の変換テーブルであるＦＱＤＮ解決用テーブル１０９の２つからなる。

図２２は、アドレス／ＦＱＤＮ解決テーブルＥ１１の例を示すものである。アドレス／ＦＱＤＮ解決テーブルＥ１１は、アドレス解決用テーブル１０８と、ＦＱＤＮ解決用テーブル１０９の２つのテーブルから構成される。アドレス／ＦＱＤＮ解決テーブルＥ１１の特徴として、アドレス解決用テーブル１０８にはあるＦＱＤＮに対して解決されるＩＰアドレスが複数存在してもよいが、ＦＱＤＮ解決用テーブル１０９にはあるＩＰアドレスに対して解決されるＦＱＤＮは１つでなければならない。

このとき、ＦＱＤＮをコンテンツグループの識別子として用いれば、サーバ負荷分散装置Ｃ３は、クライアントＤ２から受信したパケットの宛先ＩＰアドレスと宛先ポート番号からＦＱＤＮを解決することによって、リクエストしているコンテンツグループを識別することが可能になる。更に、該ＦＱＤＮからＩＰアドレスを解決することにより、該ＦＱＤＮに対する候補サーバ一覧を取得することができる。すなわち、ＩＰヘッダ及びトランスポート層（ＵＤＰ／ＴＣＰ）ヘッダの解析のみでリクエストしているコンテンツグループを識別でき、更に上位層の情報を解析する必要がないという効果がある。

アドレス応答部Ｅ１２は、他ノードから受信したアドレス解決要求に対して、要求メッセージ内に含まれるＦＱＤＮをキーとしてアドレス／ＦＱＤＮ解決テーブルを参照し、解決されたＩＰアドレスを応答する。

ＦＱＤＮ応答部Ｅ１３は、他ノードから受信したＦＱＤＮ解決要求に対して、要求メッセージ内に含まれるＩＰアドレスをキーとしてアドレス／ＦＱＤＮ解決テーブルを参照し、解決されたＦＱＤＮを応答する。

（第５の実施の形態の動作）
次に、図２３を参照して、本実施の形態において、クライアントＤ２があるコンテンツを取得するリクエストを送信する際の動作について詳細に説明する。

リクエスト送信部Ｄ１１は、取得しようとするコンテンツのＵＲＬから、ＦＱＤＮ部分を抽出する（図２３のステップＳ７０１）。例えば、ＵＲＬが、「ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｐｉｃｔ．ｊｐｇ：７０７０」であるとすると、「ａａａ．ｃｏｍ」がＦＱＤＮ部分に対応する。

次に、アドレス解決部Ｄ１２を介して、抽出したＦＱＤＮに対応するＩＰアドレスを解決する（ステップＳ７０２）。このとき、アドレス解決部Ｄ１２は、ドメインネームサーバＥ１に対して該ＦＱＤＮをキーにしてアドレス解決要求を行なう。

最後に、リクエスト送信部Ｄ１１は、解決したＩＰアドレスを宛先ＩＰアドレスとして、該コンテンツに対するリクエストパケットを送信する（ステップＳ７０３）。

次に、図２４を参照して、本実施の形態において、サーバ負荷分散装置Ｃ３がクライアントＤ２からパケットを受信したときの動作について詳細に説明する。

パケット受信部Ｃ２５は、受信したパケットの宛先ポート番号を解析し、解析した宛先ポート番号が予め設定された値に一致するかどうかをチェックする（図２４のステップＳ８０１）。

ステップＳ８０１の結果、予め設定された値に一致しない場合、パケット受信部Ｃ２５は、受信パケットを通常のパケットとして処理する（ステップＳ８０３）。すなわち、サーバ負荷分散装置としての動作は行なわない。

ステップＳ８０１の結果、予め設定された値に一致する場合、パケット受信部Ｃ２５は、受信パケットの宛先ＩＰアドレス／宛先ポート番号に対応するエントリがパケットルーティングテーブルＣ２１内に存在するかどうかをチェックする（ステップＳ８０２）。

ステップＳ８０２の結果、エントリが存在する場合、パケット受信部Ｃ２５は、該エントリにおける転送先サーバＩＰアドレスをパケットルーティングテーブルＣ２１に対して問い合わせる（ステップＳ８０４）。

このとき、パケットルーティングテーブルＣ２１は、受信パケットの宛先ＩＰアドレス／ポート番号に対する転送先サーバのＩＰアドレスを応答するが、このとき複数の転送先サーバＩＰアドレスが登録されている場合は、先に説明したように、ハッシュ関数を用いる方法等により、同一のコネクションを同一のコンテンツサーバに接続させるように転送先サーバのＩＰアドレスを応答する。

パケット受信部Ｃ２５は、パケットルーティングテーブルＣ２１から転送先サーバＩＰアドレスを応答されると、受信パケットの宛先アドレスを該転送先サーバＩＰアドレスに書き換えて該受信パケットを送信する（ステップＳ８０５）。

ステップＳ８０２の結果、エントリが存在しない場合は、パケット受信部Ｃ２５は、該受信パケットの宛先ＩＰアドレスを変更せず、そのままオリジナルの宛先ＩＰアドレスへ転送する（ステップＳ８０６）。更に該宛先ＩＰアドレス／宛先ポート番号をもつパケットに対する最適な転送先サーバを決定し、パケットルーティングテーブルＣ２１にエントリを書き込む動作を行なう（ステップＳ８０７）。ステップＳ８０６の後、ステップＳ８０７によって転送先サーバが書き込まれるまでは、該宛先ＩＰアドレス／宛先ポート番号をもつパケットを受信しても、そのままオリジナルの宛先ＩＰアドレスへ転送する。

ステップＳ８０７に対応する動作を詳細に説明するためのフローチャートが図２５である。

転送先サーバ決定部Ｃ２２は、ＦＱＤＮ解決部Ｃ２３を介して、受信パケットの宛先ＩＰアドレスに対するＦＱＤＮを解決する（図２５のステップＳ９０１）。このとき、ＦＱＤＮ解決部Ｃ２３は、ドメインネームサーバＥ１に対して該ＩＰアドレスをキーにしてＦＱＤＮ解決要求を送信し、応答を受信する。

ステップＳ９０１でＦＱＤＮを解決すると、転送先サーバ決定部Ｃ２２は、アドレス解決部Ｃ２４を介して、ステップＳ９０１で解決したＦＱＤＮと該パケットの宛先ポート番号を用いて新規にＦＱＤＮを作成し、新規に作成したＦＱＤＮに対するＩＰアドレスを解決する（ステップＳ９０２）。ここで新規に作成するＦＱＤＮは、パケットの宛先ＩＰアドレスと宛先ポート番号の組み合わせに対して一意でなければならない。例えば、解決したＦＱＤＮが「ａａａ．ｃｏｍ」であり、該パケットの宛先ポート番号が「７０７０」であるとき、「ｐｏｒｔ７０７０．ａａａ．ｃｏｍ」というＦＱＤＮに対するＩＰアドレスを解決する。

ステップＳ９０２では、ステップＳ９０１で解決したＦＱＤＮと該パケットの宛先ポート番号を用いて新規にＦＱＤＮを作成し、この新規に作成したＦＱＤＮをキーとして、ドメインネームサーバに対してＩＰアドレスを解決したが、この他にも、ステップＳ９０１で解決したＦＱＤＮをそのままキーとして用いる方法もある。この場合、ステップＳ９０１で解決したＦＱＤＮ自体がリクエストしているコンテンツグループに対してユニークになっていなければならない。従って、サーバ負荷分散装置Ｃ３が受信したパケットの宛先ＩＰアドレスには、コンテンツグループ毎にユニークである値がつけられている必要がある。またこの場合は、パケットルーティングテーブルＣ２１においては、転送先サーバのＩＰアドレスは宛先ＩＰアドレスだけに対して登録されているだけでよく、宛先ＩＰアドレス／宛先ポート番号の組み合わせに対して登録されている必要はない。

次に、転送先サーバ決定部Ｃ２２は、ステップＳ９０２で解決したＩＰアドレスに対応するサーバの中から、転送先サーバを決定する（ステップＳ９０３）。ここで転送先サーバを決定する詳細な動作については、第２の実施の形態と同様であるため、省略する。

転送先サーバを決定すると、転送先サーバ決定部Ｃ２２は、決定したサーバのＩＰアドレスをパケットルーティングエントリに対して書き込む（ステップＳ９０４）。

（第５の実施の形態の効果）
次に、本実施の形態の効果について説明する。

本実施の形態では、サーバ負荷分散装置は、パケットの宛先ＩＰアドレス／宛先ポート番号からドメインネームサーバを用いてリクエストしているコンテンツの属するコンテンツグループを識別し、該コンテンツグループに対する最適なコンテンツサーバへパケットを転送する。従来のサーバ負荷分散装置は、クライアントからのパケットの中身を解析し、どのコンテンツに対するリクエストであるかを識別する機能をもつ必要があった。すなわち、サーバ負荷分散装置としてレイヤ７スイッチを用いる必要があった。本実施の形態におけるサーバ負荷分散装置は、パケットの宛先ＩＰアドレス及び宛先ポート番号のみを調べるだけでどのコンテンツに対するリクエストであるかを識別することができる。従って、レイヤ４スイッチを用いて実現可能である。一般的に、レイヤ７スイッチの方が１秒あたりのコネクション数などの処理性能が低く、コストも高い。本実施の形態を適用してレイヤ４スイッチで同等の機能を実現できれば、処理性能向上、コスト削減などの観点から効果があるといえる。

なお、この第５の実施の形態と前述した第１の実施の形態のコンテンツ管理装置を組み合わせて適用することができるのは言うまでもない。その場合、図２に示した分類ポリシテーブルにおいて集約ＵＲＬの代わりにポート番号が設定される。また、図３の集約後のディレクトリパスは、「／ｃｇｉ／ｈｉｇｈ−ｌｏａｄ／ｚ．ｅｘｅ：７０７０」といったポート番号を付加したパスに置換えられる。

以下、本発明の実施例について図を参照して説明する。

（第１の実施例）
まず、本発明の第１の実施例を、図面を参照して説明する。かかる実施例は本発明の第２の実施の形態に対応するものである。

図７を参照すると、本実施例は、コンテンツサーバＡ２とサーバ負荷分散装置Ｃ１と、クライアントＤ１とによって構成される網によって行われる。

サーバ負荷分散装置Ｃ１内の転送先決定ポリシ設定部Ｃ１２には、図８の転送先サーバ決定ポリシテーブル１０３に示すポリシが設定されている。また、初期状態としてリクエストルーティングテーブルＣ１４に登録されているエントリはないとする。

クライアントＤ１は、ＵＲＬが「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／ｐｉｃｔ．ｇｉｆ」によって識別されるコンテンツを取得するリクエストをサーバ側へ送信する。

サーバ負荷分散装置Ｃ１は、該リクエストを受信し、リクエストしているＵＲＬを解析する。そして、リクエストルーティングテーブルＣ１４を参照し、該ＵＲＬに対するエントリは存在しないために、該リクエストをデフォルトのコンテンツサーバへ転送する。ＵＲＬのＦＱＤＮ部分である「ｗｗｗ．ａａａ．ｃｏｍ」からドメインネームサーバで解決したＩＰアドレスをデフォルトのコンテンツサーバとする。

該リクエスト転送後、サーバ負荷分散装置Ｃ１は、リクエストルーティングテーブルＣ１４に該ＵＲＬの属するコンテンツグループに対する転送先サーバのエントリを作成しようとする。

まず、転送先サーバ決定部Ｃ１３は、コンテンツサーバＡ２を管理するコンテンツ管理装置に問い合わせることによって、該ＵＲＬに対するコンテンツグループと候補サーバリストを取得する。

問い合わせを受けたコンテンツ管理装置は、該ＵＲＬに対するコンテンツグループは、ファイルの特性をもち、「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／＊」のＵＲＬプレフィクスで識別され、候補サーバリストは、「１０．１．１．１」、「１０．２．２．２」、「１０．３．３．３」の３つであるという情報を応答する。

該ＵＲＬに対する候補サーバリストを取得する他の方法として、該ＵＲＬから、「ｓｍａｌｌ．ｆｉｌｅ．ｗｗｗ．ａａａ．ｃｏｍ」というＦＱＤＮを作成し、該ＦＱＤＮをキーにして対応するＩＰアドレスのリストをドメインネームサーバに問い合わせるという例もある。この例の場合、ドメインネームサーバは該ＦＱＤＮに対するＩＰアドレスは「１０．１．１．１」、「１０．２．２．２」、「１０．３．３．３」の３つであると応答する。

次に、転送先サーバ決定部Ｃ１３は、転送先サーバ決定ポリシ設定部Ｃ１２を参照して該コンテンツグループに対する転送先サーバ決定ポリシを調べ、ファイルの特性をもつコンテンツグループに対してはコンテンツ取得時の転送スループットが用いられ、この値が最大となるサーバを基準として、６０％までの値をもつサーバが転送先サーバとして選択される、というポリシを取得する。

転送先サーバ決定部Ｃ１３は、取得したポリシに従って各候補サーバからの転送スループットを測定するために、リクエストルーティングテーブルＣ１４に「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／＊」のＵＲＬプレフィクスをもつリクエストに対する転送先サーバとして、「１０．１．１．１」、「１０．２．２．２」、「１０．３．３．３」の３つＩＰアドレスを登録する。登録後、クライアントからの該ＵＲＬプレフィクスに該当する各リクエストは、３つのサーバに対してラウンドロビンで転送される。

３つのサーバに対してラウンドロビンで転送されたリクエストに対するコンテンツサーバ側からの応答コンテンツは、コンテンツ受信／転送部Ｃ１７で受信される。リソース取得部Ｃ１１は、コンテンツ受信／転送部Ｃ１７を介してこの応答コンテンツの転送スループットを取得し、取得した情報を転送先サーバ決定部Ｃ１３へ渡す。ここでは、「１０．１．１．１」、「１０．２．２．２」、「１０．３．３．３」に対応するサーバの転送スループットがそれぞれ、１Ｍｂｐｓ、７Ｍｂｐｓ、１０Ｍｂｐｓであったとする。この値が最大となるサーバを基準として、６０％までの値をもつサーバが転送先として選択されるというポリシであったので、転送先サーバ決定部Ｃ１３は、「１０．２．２．２」、「１０．３．３．３」に対応する２つのサーバを転送先として決定する。更にリクエストルーティングテーブルＣ１４の「ｈｔｔｐ：／／ｗｗｗ．ａａａ．ｃｏｍ／ｆｉｌｅ／ｓｍａｌｌ／＊」のＵＲＬプレフィクスをもつリクエストに対する転送先サーバを、「１０．２．２．２」、「１０．３．３．３」の２つに書き換える。この後、該ＵＲＬプレフィクスに該当するリクエストは、この２つのサーバに対してラウンドロビンで転送される。

（第２の実施例）
次に、本発明の第２の実施例を、図面を参照して説明する。かかる実施例は本発明の第３の実施の形態に対応するものである。

図２６を参照すると、本実施例は、コンテンツサーバ２０１とサーバ負荷分散装置３０１〜３０６とによって行われる。コンテンツサーバ２０１は第３の実施の形態におけるコンテンツサーバＡ３と同じ構成をもち、同様にサーバ負荷分散装置３０１〜３０６はサーバ負荷分散装置Ｃ１と同じ構成をもつ。

コンテンツサーバ２０１内には、図１４のリソース応答ポリシテーブル１０５に示されるリソース応答ポリシが設定されている。ここで、コンテンツサーバ２０１において現在のＣＰＵ負荷が２５％であったとする。

ここで、サーバ負荷分散装置３０１〜３０６において転送先サーバを決定するために、各サーバ負荷分散装置からほぼ同時に、コンテンツサーバ２０１に対してＣＰＵ負荷のリソース取得要求を行なうとする。

最初のサーバ負荷分散装置３０１〜３０４からのリソース取得要求に対しては、現在のＣＰＵ負荷が０％〜３０％の範囲内にあるので、７０％の確率で実際のＣＰＵ負荷を応答し、３０％の確率で実際のＣＰＵ負荷の２倍の値を応答する。ここでは、サーバ負荷分散装置３０１〜３０４に対しては実際のＣＰＵ負荷である２５％を応答し、サーバ負荷分散装置３０５、３０６に対しては実際のＣＰＵ負荷の２倍の値である５０％を応答するとする。

もしコンテンツサーバ２０１が実際のＣＰＵ負荷である２５％をサーバ負荷分散装置３０１〜３０６に対して応答した場合、全てのサーバ負荷分散装置がコンテンツサーバ２０１のＣＰＵ負荷が十分低いと判断し、コンテンツサーバ２０１を転送先サーバとして決定するために、リクエストの急激な増加による負荷増大が発生する可能性がある。本実施例では、サーバ負荷分散装置３０５、３０６はコンテンツサーバ２０１のＣＰＵ負荷は十分低くないと判断し、コンテンツサーバ２０１以外のコンテンツサーバを転送先サーバとして決定したとする。そのため、コンテンツサーバ２０１における急激な負荷増大が抑制される。

（第３の実施例）
次に、本発明の第３の実施例を、図面を参照して説明する。かかる実施例は本発明の第４の実施の形態に対応するものである。

図２７を参照すると、本実施例は、コンテンツサーバ２０２、２０３とサーバ負荷分散装置３０７とによって行われる。コンテンツサーバ２０２、２０３は第４の実施の形態におけるコンテンツサーバＡ２と同じ構成をもち、同様にサーバ負荷分散装置３０７はサーバ負荷分散装置Ｃ２と同じ構成をもつ。

まず、サーバ負荷分散装置３０７内のリクエストルーティングテーブルにおいては、図２８のテーブル１１０に示すように、「ｆｔｐ：／／ｆｔｐ．ｃｃｃ．ｅｄｕ／ｐｕｂ／＊」に対する転送先サーバＩＰアドレスとして、「１０．５．１．１」（コンテンツサーバ２０２に対応）、「１０．６．１．１」（コンテンツサーバ２０３に対応）の２つがあり、それぞれに対するウェイト値が９０％、１０％であったとする。

このウェイト値は、転送スループットが最大となるサーバと最小となるサーバとの差が２倍以内になるまで、各サーバからの転送スループット比に応じて再設定されるものとする。ここで、コンテンツサーバ２０２、２０３に対する転送スループットがそれぞれ１Ｍｂｐｓ、９Ｍｂｐｓであったとする。このとき、「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝１．０」であったとすると、それぞれのサーバに対するウェイト値はそれぞれ、９０％→１０％、１０％→９０％と再設定される。ウェイト再設定後、それぞれのサーバに対するリクエスト転送の比率が変わり、次回に転送スループットを測定した際にはそれぞれのスループットが９Ｍｂｐｓ、１Ｍｂｐｓであったとする。すると、ウェイトが再度設定され、１０％→９０％、９０％→１０％と最初の値に戻る。このように、ウェイト変更動作が再帰的に繰り返され、発振してしまう場合はｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙが大きすぎることを示している。

そこで、上記の例で、「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝０．５」であった場合を考える。コンテンツサーバ２０２、２０３に対する転送スループットがそれぞれ１Ｍｂｐｓ、９Ｍｂｐｓであったとすると、それぞれのサーバに対するウェイト値の変動量を「ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙ＝１．０」の場合の０．５倍して、９０％→５０％、１０％→５０％と再設定する。ウェイト再設定後、それぞれのサーバに対するリクエスト転送の比率が変わり、次回に転送スループットを測定した際にはそれぞれのスループットが７Ｍｂｐｓ、３Ｍｂｐｓであったとする。そして同様にそれぞれのウェイト値を５０％→６０％、５０％→４０％に再設定する。ウェイト再設定後、それぞれのサーバに対する転送スループットが、６Ｍｂｐｓ、４Ｍｂｐｓになり、転送スループットが最大となるサーバと最小となるサーバとの差が２倍以内になったので、ウェイト変更動作を終了する。このように、ウェイト変更動作が発振しないようにｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを適当な値に調整することが重要である。

（第４の実施例）
次に、本発明の第４の実施例を、図面を参照して説明する。かかる実施例は本発明の第５の実施の形態に対応するものである。

図２０を参照すると、本実施例は、コンテンツサーバＡ４とサーバ負荷分散装置Ｃ３と、クライアントＤ２と、ドメインネームサーバＥ１とによって構成される網によって行われる。

ドメインネームサーバＥ１内には、図２２に示すアドレス解決用テーブル１０８と、ＦＱＤＮ解決用テーブル１０９が登録されている。

サーバ負荷分散装置Ｃ３内のパケットルーティングテーブルＣ２１に登録されているエントリは初期状態で空であるとする。

クライアントＤ２は、ＵＲＬが「ｈｔｔｐ：／／ａａａ．ｃｏｍ／ｐｉｃｔ．ｊｐｇ：７０７０」によって識別されるコンテンツを取得するリクエストをサーバ側へ送信しようとする。このとき、ＵＲＬのＦＱＤＮ部分である「ａａａ．ｃｏｍ」をキーにしてドメインネームサーバＥ１に対してアドレス解決要求を出す。ドメインネームサーバＥ１は、対応するＩＰアドレスである「１０．１．１．１」を応答する。そしてクライアントＤ２は解決した「１０．１．１．１」を宛先ＩＰアドレスとし、ＵＲＬで指定された「７０７０」を宛先ポート番号としたパケットの形で該リクエストを送信する。

サーバ負荷分散装置Ｃ３は、クライアントＤ２からパケットを受信し、予め指定された宛先ポート番号をもつパケットに対して、パケットルーティングテーブルＣ２１を参照して転送先サーバＩＰアドレスへと転送する。この場合、「７０７０」は予め設定された宛先ポート番号であり、パケットルーティングテーブルＣ２１を調べるが、登録されているエントリはないため、オリジナルの宛先ＩＰアドレスのまま、該パケットを転送する。

該パケット転送後、サーバ負荷分散装置Ｃ２は、パケットルーティングテーブルＣ２１に該パケットに対応するコンテンツグループに対する転送先サーバのエントリを作成しようとする。転送先サーバのエントリが作成されるまでは、該パケットと同じ宛先ＩＰアドレス／宛先ポート番号をもつパケットを受信しても、オリジナルの宛先ＩＰアドレスへ転送する。

このパケットルーティングテーブルＣ２１にパケットに対応するコンテンツグループに対する転送先サーバのエントリを作成する場合の例を、図２９を参照して説明する。クライアントＤ２からは、上記のように「１０．１．１．１」を宛先ＩＰアドレスとし、ＵＲＬで指定された「７０７０」を宛先ポート番号としたパケットの形でリクエストが送信されている。

まず、サーバ負荷分散装置Ｃ２の転送先サーバ決定部Ｃ２２は、ＦＱＤＮ解決部Ｃ２３を介して、ドメインネームサーバＥ１に該パケットの宛先ＩＰアドレスである「１０．１．１．１」をキーとしてＦＱＤＮ解決要求を出す。

問い合わせを受けたドメインネームサーバＥ１のＦＱＤＮ応答部Ｅ１３は、「１０．１．１．１」に対するＦＱＤＮである「ａａａ．ｃｏｍ」を応答する。

次に、転送先サーバ決定部Ｃ２２は、アドレス解決部Ｃ２４を介して、ドメインネームサーバＥ１に応答されたＦＱＤＮである「ａａａ．ｃｏｍ」に宛先ポート番号「７０７０」の情報を付与した、「ｐｏｒｔ７０７０．ａａａ．ｃｏｍ」というＦＱＤＮをキーとしてアドレス解決要求を出す。ここで新規に作成するＦＱＤＮは、該パケットの宛先ＩＰアドレスと宛先ポート番号に対してユニークであればよく、この例の他にも、「７０７０．ｐｏｒｔ．ａａａ．ｃｏｍ」などとしてもよい。ただし、作成するＦＱＤＮに対応するエントリがドメインネームサーバＥ１にも登録されていることが条件である。

問い合わせを受けたドメインネームサーバＥ１のアドレス応答部Ｅ１２は、「ｐｏｒｔ７０７０．ａａａ．ｃｏｍ」に対するアドレスである「１０．１．１．１」、「２０．２．２．２」、「３０．３．３．３」を応答する。

従って、転送先サーバ決定部Ｃ２２は、宛先ＩＰアドレス／宛先ポート番号が「１０．１．１．１／７０７０」のパケットに対する候補サーバの宛先ＩＰアドレスが「１０．１．１．１」、「２０．２．２．２」、「３０．３．３．３」の２つであるとわかる。

次に、転送先サーバ決定部Ｃ２２は、候補サーバの中からパケットルーティングテーブルに登録する転送先サーバを決定する。ここでは、転送先サーバの決定ポリシとして、ＣＰＵ負荷の低い順に２つのサーバを選択するというポリシが設定されているものとし、各サーバに問い合わせた結果、「１０．１．１．１」に対応するサーバのＣＰＵ負荷が８０％、「２０．２．２．２」に対応するサーバのＣＰＵ負荷が３０％、「３０．３．３．３」に対応するサーバのＣＰＵ負荷が５０％であったとする。

その結果、転送先サーバ決定部Ｃ２２は、宛先ＩＰアドレス／宛先ポート番号が「１０．１．１．１／７０７０」であるパケットに対して、「２０．２．２．２」に対応するサーバと「３０．３．３．３」に対応するサーバを転送先として決定し、パケットルーティングテーブルＣ２１に登録する（図２１のパケットルーティングテーブル１０７参照）。

パケットルーティングテーブルＣ２１へのエントリ登録後、宛先ＩＰアドレス／宛先ポート番号が「１０．１．１．１／７０７０」であるパケットは、「２０．２．２．２」又は「３０．３．３．３」のＩＰアドレスをもつサーバへリダイレクトされる。

なお、上記各実施の形態のサーバ負荷分散システムは、サーバ負荷分散装置Ｃ１〜Ｃ３における転送先サーバ決定ポリシ設定部Ｃ１２、転送先サーバ決定部Ｃ１３、Ｃ２２、ＦＱＤＮ解決部Ｃ２３、アドレス解決部Ｃ２４の機能や、コンテンツ管理装置Ｂ１における、コンテンツ分類部Ｂ１２やコンテンツ集約部Ｂ１３の機能や、コンテンツサーバＡ１〜Ａ４における、リソース応答部Ａ１３、Ａ１５やリソース応答ポリシ設定部Ａ１４の機能や、その他の機能をハードウェア的に実現することは勿論として、各機能を備えるコンテンツ配信管理プログラムＡ３９、コンテンツ管理プログラムＢ１９、サーバ負荷分散プログラムＣ２９、Ｃ４９、Ｃ５９を、コンピュータ処理装置のメモリにロードされることで実現することができる。このコンテンツ配信管理プログラムＡ３９、コンテンツ管理プログラムＢ１９、サーバ負荷分散プログラムＣ２９、Ｃ４９、Ｃ５９は、磁気ディスク、半導体メモリその他の記録媒体に格納される。そして、その記録媒体からコンピュータ処理装置にロードされ、コンピュータ処理装置の動作を制御することにより、上述した各機能を実現する。

以上好ましい実施の形態及び実施例をあげて本発明を説明したが、本発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形して実施することができる。

以上説明したように本発明によれば、以下のような効果が達成される。

第１の効果は、コンテンツサーバ内のコンテンツを、同じ特性をもつコンテンツ毎に分類／集約する作業を手動で行なう必要がない。

その理由は、コンテンツ管理装置において同じコンテンツグループとして分類／集約するためのポリシを設定しておくことにより、コンテンツサーバ内のコンテンツの静的／動的な特性に応じて自動的に集約することができるからである。

第２の効果は、サーバ負荷分散装置において、コンテンツの特性に応じた最適なリクエストルーティングを最小のエントリ数で実現することができる。

その理由は、コンテンツ管理装置がコンテンツサーバ内のコンテンツをその静的／動的特性に応じて自動的に分類／集約するからである。

第３の効果は、サーバ負荷分散装置を経由させるだけで、クライアントからのリクエストを、リクエストしているコンテンツの特性に応じた最適なサーバに転送することができる。

その理由は、サーバ負荷分散装置において、各コンテンツグループ毎にその特性に応じた選択基準により転送先サーバを決定し、決定した転送先サーバをリクエストルーティングテーブルに登録しておくと共に、クライアントから受信したリクエストがどのコンテンツグループに属するコンテンツに対するものであるかを識別することにより、対応するコンテンツグループに対する転送先サーバへ該リクエストを転送することができるからである。

第４の効果は、コンテンツサーバに対するクライアントからのリクエストの急激な集中を抑制すると共に、サーバ負荷分散装置のリクエストルーティングテーブルにおいて転送先サーバの決定が収束せずに発振することを抑止することができる。

その第１の理由は、コンテンツサーバにおいて、網内に配置されている複数のサーバ負荷分散装置からのリソース情報取得要求に対し、必ずしも実際のリソース情報をそのまま応答するのではなく、設定したリソース応答ポリシに応じてリソース値を補正して応答することにより、多数のサーバ負荷分散装置が同時に同じコンテンツサーバを転送先として選択することを抑制できるからである。

その第２の理由は、サーバ負荷分散装置において、各エントリの転送先サーバに対するウェイト値を、取得したリソース値に応じて変更し、このウェイト値の変更を、ｍｏｖｅ＿ｇｒａｎｕｌａｒｉｔｙを用いて緩やかに行なうことにより、多数のサーバ負荷分散装置が同時に同じコンテンツサーバを転送先として選択することを抑制できるからである。

その第３の理由は、サーバ負荷分散装置において、各エントリの転送先サーバに対するウェイト値を、取得したリソース値に応じて直ちに再設定するする代わりに、ウェイト値を再設定する時刻を確率的に分散させた時間だけ遅延させ、遅延させた時刻に必要ならばウェイト値を再設定することにより、多数のサーバ負荷分散装置が同時に同じコンテンツサーバを転送先として選択することを抑制できるからである。

第５の効果は、サーバ負荷分散装置としてレイヤ７スイッチを用いずに、レイヤ４スイッチによって、クライアントからのリクエストを最適なコンテンツサーバへ誘導することができ、サーバ負荷分散装置としての処理性能向上、コスト削減を図ることができる。

その理由は、サーバ負荷分散装置において、クライアントから受信したパケットの宛先ＩＰアドレス／宛先ポート番号からドメインネームサーバを用いてリクエストしているコンテンツの属するコンテンツグループを識別し、該コンテンツグループに対する最適なコンテンツサーバへパケットを転送することにより、クライアントからのパケットの中身（ＵＲＬなど）を解析する必要がないからである。

本発明の第１の実施の形態の構成を示すブロック図である。 本発明の第１の実施の形態の分類ポリシ設定部において設定される分類ポリシの例を示す図である。 本発明の第１の実施の形態のコンテンツ集約部が行なうＵＲＬ書き換え処理の例を示す図である。 本発明の第１の実施の形態のコンテンツ管理装置の動作を示す流れ図である。 本発明の第１の実施の形態のコンテンツ管理装置をコンテンツサーバの一部の機能として実現した場合の例を示す図である。 本発明の第１の実施の形態のコンテンツ管理装置に複数台のコンテンツサーバが接続される例を示す図である。 本発明の第２の実施の形態の構成を示すブロック図である。 本発明の第２の実施の形態の転送先サーバ決定ポリシ設定部において設定される転送先サーバ決定ポリシの例を示す図である。 本発明の第２の実施の形態のリクエストルーティングテーブルにおいて登録されるエントリの例を示す図である。 本発明の第２の実施の形態のサーバ負荷分散装置がクライアントからリクエストを受信したときの動作を示す流れ図である。 本発明の第２の実施の形態のサーバ負荷分散装置の転送先サーバ決定部が転送先サーバを決定する動作を示す流れ図である。 本発明の第２の実施の形態のサーバ負荷分散装置においてリクエストルーティングテーブルに登録されているエントリを管理するときの動作を示す流れ図である。 本発明の第３の実施の形態の構成を示すブロック図である。 本発明の第３の実施の形態のリソース応答ポリシ設定部において設定されているリソース応答ポリシの例を示す図である。 本発明の第３の実施の形態においてコンテンツサーバがサーバ負荷分散装置からリソース取得要求を受信したときの動作を示す流れ図である。 本発明の第４の実施の形態の構成を示すブロック図である。 本発明の第４の実施の形態のリクエストルーティングテーブルにおいて登録されるエントリの例を示す図である。 本発明の第４の実施の形態のサーバ負荷分散装置の動作を示す流れ図である。 本発明の第４の実施の形態のサーバ負荷分散装置の動作を示すもう１つの流れ図である。 本発明の第５の実施の形態の構成を示すブロック図である。 本発明の第５の実施の形態のパケットルーティングテーブルにおいて登録されるエントリの例を示す図である。 本発明の第５の実施の形態のアドレス／ＦＱＤＮ解決テーブルにおいて登録されるエントリの例を示す図である。 本発明の第５の実施の形態においてクライアントがコンテンツを取得するリクエストを送信する際の動作を示す流れ図である。 本発明の第５の実施の形態においてサーバ負荷分散装置がクライアントからパケットを受信したときの動作を示す流れ図である。 本発明の第５の実施の形態においてパケットルーティングテーブルにエントリを作成する動作を示す流れ図である。 本発明の第２の実施例における網構成図である。 本発明の第３の実施例における網構成図である。 第３の実施例におけるリクエストルーティングテーブルの例を示す図である。 第４の実施例におけるリクエストルーティングテーブルに転送先サーバのエントリを作成する場合の例を示す図である。

符号の説明

Ａ１〜Ａ４、２０１〜２０３ コンテンツサーバ
Ａ１１ コンテンツ記憶部
Ａ１２ リクエスト受信／コンテンツ応答部
Ａ１３、Ａ１５ リソース応答部
Ａ１４ リソース応答ポリシ設定部
Ａ１６ 動的パラメータ格納部
Ｂ１ コンテンツ管理装置
Ｂ１１ 分類ポリシ設定部
Ｂ１２ コンテンツ分類部
Ｂ１３ コンテンツ集約部
Ｃ１〜Ｃ３、３０１〜３０７ サーバ負荷分散装置
Ｃ１１ リソース取得部
Ｃ１２ 転送先サーバ決定ポリシ設定部
Ｃ１３ 転送先サーバ決定部
Ｃ１４、Ｃ１８、１０４、１０６、１１０ リクエストルーティングテーブル
Ｃ１５ リクエスト受信部
Ｃ１６ リクエスト転送部
Ｃ１７ コンテンツ受信／転送部
Ｃ１９ ウェイト設定部
Ｃ２０ パケット転送部
Ｃ２１、１０７ パケットルーティングテーブル
Ｃ２２ 転送先サーバ決定部
Ｃ２３ ＦＱＤＮ解決部
Ｃ２４ アドレス解決部
Ｃ２５ パケット受信部
Ｄ１、Ｄ２ クライアント
Ｄ１１ リクエスト送信部
Ｄ１２ アドレス解決部
Ｅ１ ドメインネームサーバ
Ｅ１１ アドレス／ＦＱＤＮ解決テーブル
１０８ アドレス解決用テーブル
１０９ ＦＱＤＮ解決用テーブル
Ｅ１２ アドレス応答部
Ｅ１３ ＦＱＤＮ応答部
１ バックボーン網
１０１ 分類ポリシテーブル
１０３ 転送先サーバ決定ポリシテーブル
１０５ リソース応答ポリシテーブル
Ａ３９ コンテンツ配信管理プログラム
Ｂ１９ コンテンツ管理プログラム
Ｃ２９、Ｃ４９、Ｃ５９ サーバ負荷分散プログラム

Claims (7)

1. クライアントへコンテンツを配信するコンテンツサーバを、複数のコンテンツサーバの中から選択するサーバ負荷分散装置において、
   前記クライアントから受信したコンテンツの配信を要求するメッセージもしくはパケットに含まれる情報に基づいて、前記クライアントにコンテンツを配信する前記コンテンツサーバを決定し、決定した前記コンテンツサーバに対して受信した前記コンテンツの配信を要求するメッセージもしくはパケットを転送する手段を備え、
   受信した前記メッセージもしくはパケットに含まれる情報を用いて、前記情報を一意に示すＦＱＤＮを新規に作成し、前記新規に作成したＦＱＤＮをキーにしてドメインネームサーバに問い合わせることによって前記受信したメッセージもしくはパケットを転送すべき宛先である前記クライアントにコンテンツを配信する前記コンテンツサーバの候補を取得し、前記候補の中から前記クライアントにコンテンツを配信する前記コンテンツサーバを決定することを特徴とするサーバ負荷分散装置。
2. 前記作成されるＦＱＤＮは、
   前記クライアントから受信したコンテンツの配信を要求するメッセージに含まれるコンテンツのＵＲＬ又は前記ＵＲＬの一部分を用いて作成されることを特徴とする請求項１に記載のサーバ負荷分散装置。
3. 前記作成されるＦＱＤＮは、
   前記クライアントから受信したコンテンツの配信を要求するパケットの宛先ＩＰアドレス及び宛先ポート番号を用いて、前記宛先ＩＰアドレスと前記宛先ポート番号を一意に示すように作成されること、を特徴とする請求項１に記載のサーバ負荷分散装置。
4. 前記作成されるＦＱＤＮは、
   前記クライアントから受信したコンテンツの配信を要求するパケットの宛先ＩＰアドレスをキーにしてドメインネームサーバに問い合わせることにより解決された第２のＦＱＤＮと、前記パケットの宛先ポート番号の情報を用いて、前記宛先ＩＰアドレスと前記宛先ポート番号を一意に示すように作成されることを特徴とする請求項１に記載のサーバ負荷分散装置。
5. 前記作成されるＦＱＤＮは、
   前記クライアントから受信したコンテンツの配信を要求するパケットの宛先ＩＰアドレスをキーにしてドメインネームサーバに問い合わせて解決した応答が用いられることを特徴とする請求項１に記載のサーバ負荷分散装置。
6. 前記クライアントから受信したコンテンツの配信を要求するパケットの宛先ＩＰアドレスを、当該クライアントに対して要求された前記コンテンツを配信する前記コンテンツサーバのＩＰアドレスに書き換えて当該コンテンツサーバに転送するパケット転送手段を備えることを特徴とする請求項１から請求項５のいずれか１つに記載のサーバ負荷分散装置。
7. 前記クライアントに要求された前記コンテンツを配信する前記コンテンツサーバのＩＰアドレスに対応するＭＡＣアドレスを解決し、前記クライアントから受信したコンテンツの配信を要求するパケットの宛先ＭＡＣを、前記解決したＭＡＣアドレスに書き換えた上で、前記パケットを前記コンテンツサーバに転送することを特徴とする請求項１から請求項５のいずれか１つに記載のサーバ負荷分散装置。

Images