JP2004086317A

JP2004086317A - 負荷分散方法及び装置

Info

Publication number: JP2004086317A
Application number: JP2002243630A
Authority: JP
Inventors: Yoshiharu Kurose; 黒瀬　義敏
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2002-08-23
Filing date: 2002-08-23
Publication date: 2004-03-18

Abstract

【課題】キャッシュサーバに特別な負荷機能を設けることなく、ユーザから要求されたコンテンツデータのヒット率を向上させ、レスポンスタイムを短縮した負荷分散方法及び装置を提供する。
【解決手段】負荷分散装置２は、ユーザ１が希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積しているキャッシュサーバ３の内、そのコンテンツを蓄積しているものを検出し、そのコンテンツを取得してユーザ１に送信する。また、希望のコンテンツを蓄積しているキャッシュサーバ３が分からないときには、予め決めたキャッシュサーバ３に対してオリジンサーバ群４からそのコンテンツを取得してキャッシュさせてからユーザ１に転送すると共に、希望のコンテンツのキーワードに基づいてジャンルに対応したキャッシュサーバ３を検出し、検出したキャッシュサーバ３に対してそのコンテンツをオリジンサーバ群４に要求し直させてキャッシュさせる。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、負荷分散方法及び装置に関し、特にネットワーク上に分散配置された複数の通信端末としてのサーバがファイルオブジェクトをキャッシュしてユーザが位置する通信端末としてのクライアントに通信回線を経由して提供する時の負荷分散方法及び装置に関するものである。
【０００２】
このようにファイルオブジェクトをキャッシュするサーバはキャッシュサーバと呼ばれ、クライアントのコンテンツ要求を代理或いは転送し、応答として中継したコンテンツを蓄積するものであり、この場合、蓄積したコンテンツが要求されたコンテンツと一致すれば別の通信端末であるコンテンツサーバへの要求は行わないで自らクライアントへデータを送信するものである。
【０００３】
このようなキャッシュサーバの配置形態としては、リバースプロキシ（特定のＷＷＷサーバ用のキャッシュ）、透過型キャッシュ（ユーザは、キャッシュの指定をすることは無く、ルータ等が強制的にパケットをキャッシュに蓄積するもの）などがある。
【０００４】
この場合、ユーザのコンテンツ要求全体数に対してキャッシュサーバ自らコンテンツを送信した数の比率をヒット率と称する。また、ユーザ要求を始点としてネットワークが該当データをユーザに提供するまでの時間をレスポンスタイムと称し、キャッシュサーバが構築されている場合は、キャッシュサーバが該当コンテンツをキャッシュとして保持していた場合にその該当コンテンツを検出しユーザに提供するまでの時間を示している。
【０００５】
このように、キャッシュサーバにおいては、ヒット率が高く、レスポンスタイムが短くなることにより、キャッシュサーバを負荷としたときの負荷分散を向上させる必要がある。
【０００６】
【従来の技術】
このようなキャッシュサーバによる負荷分散の従来技術としては次のようなものがある。
（１）ディレクトリサーバにおける負荷分散例
図１４には、ディレクトリサーバ（データサーバ）の検索において、検索時間の短縮を目的としてキャッシュする場合の構築例を機能別に示している。
【０００７】
同図（１）はアクセス数によるキャッシュ蓄積の構築例を示しており、例えばアクセスが「検索」が３回続けば、キャッシュサーバＡにはアクセスに応じたデータの蓄積が行われるようにしている。
また同図（２）は、アクセス要求の種類で振分を行う構築例を示しており、キャッシュサーバＢにおいて、アクセス要求が「検索」、「確認」、「変更」の順にあったとき、これらの種類に応じてデータを分類して蓄積するようにしている。
【０００８】
上記のような構築例では、同図（１）の場合には、アクセス数が多い種類については非常にヒット率が良くなるが、突発的なアクセス数により蓄積されるデータに偏りが生じてしまう。
また、同図（２）のようなキャッシュサーバＢにおいてはアクセス数だけによらないデータ蓄積が可能であり、このようにキャッシュ蓄積をアクセス要求の種類別に分類して管理すると、ある一つの種類の検索要求によって大量にデータが抽出された場合に、他の種類のデータがキャッシュから削除されないのでヒット率を高く確保することが可能となる。
【０００９】
その一方、アクセスが無いにも関わらずその予め決められた種類に応じて振分けされるので、アクセスの無い種類のキャッシュが存在してしまい、結果としてヒット率が低下してしまう場合が生じる。
（２）アダプティブ・オブジェクト・リプレイスメントによる負荷分散例
これは、限られたディスク容量から、高いヒット率を実現するために自動的にキャッシュされたファイルオブジェクトのアクセス頻度を調べ、最もアクセス数が少なく、最も取得時間が短く、サイズの小さいファイルオブジェクトから適応的に削除して行く方式である。
【００１０】
（３）キャッシュサーバの負荷分散例
一般に複数のキャッシュサーバに対して負荷分散を行う場合には、キャッシュサーバ群とユーザ間にロードバランサー（負荷分散装置）を置いてラウンドロビン方式又はキャッシュサーバのＣＰＵ負荷率などに基づいて、接続させるキャッシュサーバを決定し、ユーザからのコンテンツ等の要求をそのキャッシュサーバに転送するようにしている。
【００１１】
図１５（１）の例では、このようなロードバランサー５をユーザ（クライアント）１と、ネットワーク運用を行うサイト１０との間に配置し、このサイト１０内にキャッシュサーバ群３を経由してロードバランサー５に接続される、コンテンツ等を保有したオリジンサーバ群４を配置している。
【００１２】
また、同図（２）の場合には、ユーザ１とロードバランサー５とキャッシュサーバ群３とがサイト１０内に設けられ、インターネット６を経由してサイト１０にオリジンサーバ群４が接続されている。
（４）拡張ＤＮＳサーバを用いたリクエスト・リルーティングによる負荷分散例
この例では、図１６に示すように、複数のサーバを設け、最適なサーバとユーザとの通信を行わせるように負荷分散を行うものであり、以下にその動作を説明する。
【００１３】
▲１▼ユーザ１は、ネットワーク３０内のオリジンサーバ４（ＩＰアドレス：Ａ）と通信を行うために、ユーザ１が存在するネットワーク２０内にあるＤＮＳサーバ７にオリジンサーバ４の名前解決要求（ＩＰアドレスの要求）を出す。
▲２▼ＤＮＳサーバ７は、オリジンサーバ４のネットワーク３０の名前空間を管理する拡張ＤＮＳサーバ８に対し、ユーザ１から受けた名前解決要求を転送する。
【００１４】
▲３▼拡張ＤＮＳサーバ８は、問い合わせて来たＤＮＳサーバ７に対して、広域負荷分散の観点（この例では単にランダムにサーバを振り分けるとする。）からオリジンサーバ４のＩＰアドレスＡではなく、最適サーバとしてオリジンサーバ４のキャッシュサーバ３のＩＰアドレスＢを回答することを決定する。ただし、この例では、拡張ＤＮＳサーバ８は、単に予め登録しているオリジンサーバ４のキャッシュサーバ群のＩＰアドレスをランダムに回答するものとする。
【００１５】
▲４▼拡張ＤＮＳサーバ８は、キャッシュサーバ３のＩＰアドレスＢを名前解決応答としてＤＮＳサーバ７に通知する。
▲５▼ＤＮＳサーバ７は、受信したＩＰアドレスＢに基づき、ユーザ１に対してＩＰアドレスＢを通知する。
【００１６】
▲６▼ユーザ１は、本来のオリジンサーバ４ではなく、キャッシュサーバ３と通信を行う。
このようにして、ユーザ１は拡張ＤＮＳサーバ８が指定したキャッシュサーバ３と通信することで、オリジンサーバ４の負荷が軽減され、ユーザ１は処理負荷の低いキャッシュサーバ３と通信することが可能となる。
【００１７】
また、この例では、拡張ＤＮＳサーバ８が選ぶキャッシュサーバはランダムであるとしたが、選択アルゴリズムによっては、ユーザ１側のＤＮＳサーバ７のＩＰアドレスから距離的に近いと考えられるキャッシュサーバを指定することも可能であり、その場合にはユーザ−サーバ間の距離的な遅延増加を防ぐことが可能となる。
【００１８】
【発明が解決しようとする課題】
図１４に示したディレクトリサーバのキャッシュ機能による負荷分散は、ヒット率は向上するが、求められているデータを効率良くキャッシュサーバから探し出す手法を備えていないので、検出速度、すなわちレスポンスタイムが遅い。また、キャッシュサーバがデータ蓄積時にコンテンツをフィルタリングする機能が必要になる。
【００１９】
また、図１５に示すようなロードバランサーを用いたキャッシュサーバの負荷分散例は、ラウンドロビン方式やＣＰＵ負荷率などにより、接続するキャッシュサーバを決定するため、決定したキャッシュサーバが、ユーザ要求の該当データをキャッシュしている可能性が低い。
【００２０】
さらに、拡張ＤＮＳサーバを用いた図１６に示すリクエスト・リルーティング方式は、データ要求を、該当するキャッシュに分散誘導する機能を有しているが、オリジンサーバ群を運営しているサイト側のシステムが必要であるため、全てのサーバに対しては有効とは言えない。
【００２１】
このように、いずれの従来技術においても、ユーザからのコンテンツの要求をそのキャッシュサーバに適切に分散誘導しヒット率を向上させることができないという問題があった。
従って本発明は、ユーザがネットワークからコンテンツ（データ）を取得する際、ユーザからの要求をキャッシュサーバに対して特別な付加機能を設けることなく、自動的に該当するデータを蓄積すること及びその該当データのヒット率を向上させ、以ってユーザクライアントに対して要求したコンテンツの提供におけるレスポンスタイムを短縮できる負荷分散方法及び装置を提供することを目的とする。
【００２２】
【課題を解決するための手段】
上記の目的を達成するため、本発明では、ユーザが位置する第１の通信端末と、コンテンツを一時的に蓄積することが可能な複数の第２の通信端末と、該コンテンツを予め保持している第３の通信端末とで構成されるネットワークの負荷分散方法及び装置において、該第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している該第２の通信端末の内、該希望のコンテンツを蓄積しているものを検出し、該検出した第２の通信端末に該希望のコンテンツを要求することにより取得して該第１の端末に送信することを特徴としている（請求項１，４／付記１，９）。
【００２３】
すなわち、本発明は、図１に示すように、複数のユーザ（クライアント）１＿１，１＿２，１＿３，・・・から成る第１の通信端末１と、コンテンツを一時的に蓄積することが可能な複数のキャッシュサーバ３＿１，３＿２，３＿３，・・・から成るキャッシュサーバ群の第２の通信端末３と、該コンテンツを予め保持しているオリジンサーバ群４＿１，４＿２，４＿３，・・・から成る第３の通信端末４とで構成されたネットワークを負荷分散装置２によって負荷分散を実現するものである。
【００２４】
このような本発明の負荷分散方法及び装置の動作原理を、図１の一部分を取り出して示した図２により以下に（　）符号のステップに沿って順次説明する。
（１）まずユーザ１は、希望するコンテンツの要求を負荷分散装置２に送信する。
（２）負荷分散装置２は、予め持っている情報に基づき、ユーザ１からのコンテンツ要求を、該当するキャッシュサーバ群３に送信する。この場合、キャッシュサーバ群３においては、キャッシュサーバ３＿１及び３＿２がそれぞれジャンル別にコンテンツを一時的に蓄積しているものとすると、負荷分散装置２は、ユーザ１からのコンテンツ要求に基づき、ユーザ１が希望したコンテンツを蓄積しているキャッシュサーバとして例えばキャッシュサーバ３＿１を検出し、このキャッシュサーバ３＿１に対してコンテンツ要求を送信する。
【００２５】
（３）キャッシュサーバ３＿１は自分が蓄積しているコンテンツの内要求されたものを負荷分散装置２に送信する。
（４）負荷分散装置２は、キャッシュサーバ３＿１から受信したコンテンツをユーザ１に転送する。
【００２６】
このように、本発明では従来技術と異なり、ユーザ要求に対応するキャッシュサーバを決定する際に、アクセス数、ＣＰＵ負荷率、オリジンサイト指定の情報等を用いず、全てのサイトに対して自動的にジャンル別コンテンツをキャッシュサーバに収集した状態で、そのキャッシュサーバへコンテンツ要求を誘導することでユーザへのレスポンスタイムを向上させている。
【００２７】
すなわち、本発明では、オリジンサイトに関係なく、自動的にキャッシュサーバのレスポンスタイムを短縮させているため、ユーザからのコンテンツ要求をジャンル毎に接続するキャッシュサーバを振り分けることで、ニッチな要求をする少数のユーザに対してヒット率を向上させることができる。
【００２８】
（５）上記の例では、キャッシュサーバ３＿１にコンテンツ要求に係るコンテンツがキャッシュされているものと仮定したが、このような希望のコンテンツを蓄積しているキャッシュサーバが無い初期動作時には、負荷分散装置２は、予め決めたキャッシュサーバとして、例えばキャッシュサーバ３＿１を経由してオリジンサーバ４に該コンテンツを要求する。
【００２９】
（６）オリジンサーバ４は、要求されたコンテンツをキャッシュサーバ３＿１に送信する。
（７）これにより、キャッシュサーバ３＿１は、受け取ったコンテンツをキャッシュしつつ、負荷分散装置２に受け取ったコンテンツを送信する。
【００３０】
（８）負荷分散装置２は、受け取ったコンテンツをユーザ１に送信する。
（９）上記（７）によりキャッシュサーバ３＿１からコンテンツを受信した負荷分散装置２は、そのコンテンツ中のキーワードを検出し、且つこのキーワードに基づいてどのキャッシュサーバがそのコンテンツを、ジャンルに対応して蓄積していることが望ましいかを検出する。
【００３１】
この場合、予め決めたキャッシュサーバ３＿１ではなく、キャッシュサーバ３＿２が適切なキャッシュサーバであるとすると、負荷分散装置２は、このキャッシュサーバ３＿２に該希望のコンテンツを要求する。
（１０）キャッシュサーバ３＿２は、未だそのコンテンツは蓄積していないので、そのコンテンツ要求をオリジンサーバ４に対して送ることにより、コンテンツの要求し直しを実行する。
【００３２】
（１１）オリジンサーバ４はコンテンツ要求に対応するコンテンツをキャッシュサーバ３＿２に送信する。
（１２）キャッシュサーバ３＿２はそのコンテンツをキャッシュしつつ、負荷分散装置２に送信する。
【００３３】
（１３）負荷分散装置２は、受け取ったコンテンツのジャンルを分類し、情報を保持するとともに、受け取ったデータをユーザ１に送信する（請求項２，５／付記２，１０）。
このようにして、キャッシュサーバ群３においてコンテンツが何も未だ蓄積されていない場合、又は蓄積すべきキャッシュサーバが決まらない場合は、コンテンツのキーワードに基づいてジャンル別に分類した形でキャッシュサーバ群３にそれぞれコンテンツがキャッシュされることとなる。
【００３４】
従って、このような学習を繰り返すことにより、キャッシュサーバ群３はジャンル別にコンテンツを蓄積し、以ってユーザからのコンテンツ要求に対するヒット率を上げると共にレスポンスタイムを短縮することが可能となる。
上記の場合の希望のコンテンツの要求し直しは、上記（９）のように即座に行ってもよいし、或いはステップ（１４）に示すように、ユーザ１からのコンテンツ要求を契機として行ってもよい（請求項３／付記３，１１）。
【００３５】
或いは、負荷分散装置１は希望のコンテンツの要求し直しを、定期的に行ってもよい（付記４，１２）。
また本発明に係る負荷分散方法及び装置では、該コンテンツを要求したユーザ（第１の通信端末）の識別子と該要求の宛先となるキャッシュサーバ（第２の通信端末）とを関連付けた履歴を記録することができる（付記５，１３）。
【００３６】
また本発明に係る負荷分散方法及び装置では、キャッシュサーバ（第２の通信端末）とコンテンツのキーワードとユーザ（第１の通信端末）のコンテンツ要求とを関連付けた履歴を保持することにより、どのキャッシュサーバ（第２の通信端末）がどのユーザ（第１の通信端末）からどんなキーワードのコンテンツが要求されたのかを保持するようにしてもよい（付記６，１４）。
【００３７】
また本発明に係る負荷分散方法及び装置では、該履歴を、外部から参照又は変更可能にすることができる（付記７，１５）。
さらに本発明に係る負荷分散方法及び装置では、上記第２の通信端末としてキャッシュサーバを用い、該第３の通信端末としてオリジンサーバ群を用いることができる（付記８，１６）。
【発明の実施の形態】
図３は、図１及び図２に示した本発明に係る負荷分散方法及び装置のネットワーク構成例を全体的に示した図である。この実施例では、ネットワークは、ユーザクライアント（ＩＰアドレスＤ）１と、負荷分散装置（ＩＰアドレスＥ）２と、キャッシュサーバ３＿１（ＩＰアドレスＡ）、キャッシュサーバ３＿２（ＩＰアドレスＢ）、キャッシュサーバ３＿３（ＩＰアドレスＣ）から成るキャッシュサーバ群３と、インターネット上のオリジンサーバ群４で構成されている。これらの各構成要素は以下の機能を備えている。
【００３８】
ユーザ１：
・負荷分散装置２或いはキャッシュサーバ群３、或いはオリジンサーバ（コンテンツサーバ）４にコンテンツを要求し、受信することが可能である。
インターネット４：
・オリジナルのコンテンツを予め保持しているサーバ群であり、要求されたコンテンツを要求元に提供することが可能である。
【００３９】
キャッシュサーバ群３：
・オリジナルコンテンツを内部に一時蓄積することが可能である。
・コンテンツ要求に対して、もし内部に蓄積しているコンテンツがあればそれを用いてコンテンツを応答として返すことが可能である。
【００４０】
・コンテンツ要求に対して、もし内部に蓄積しているコンテンツがなければ、オリジナルのコンテンツを外部に要求することが可能である。
負荷分散装置２：
・要求されたコンテンツのジャンルに対応していると想定されるキャッシュサーバを決定することが可能である。
【００４１】
・要求されたコンテンツのジャンル分類が可能である。
・要求されたコンテンツを外部にさらに要求し、応答として受信したコンテンツを要求元に送信することが可能である。
図４は図３に示した負荷分散装置２の構成実施例を示したものであり、この実施例では、受信部１１と通信記録部１２とコンテンツ分類部１３とユーザインタフェース部１４と通信記録ＤＢ（Ｄａｔａ　Ｂａｓｅ）１５とキャッシュ決定部１６とキャッシュＤＢ１７と宛先変更部１８とタイマー部１９と要求代行部２０と送信部２１とで構成されている。
【００４２】
以下、この実施例の動作を、図３のネットワーク構成例及び図５〜１３に示した各部のフローチャートを参照して説明する。
なお、キャッシュＤＢ１７は、コンテンツ分類などに用いる情報として、この実施例では下記の表１の内容（１）を初期値として持っているものとする。
【００４３】
【表１】

【００４４】
［１］まず、ユーザ１は、予め設定してある（ウエブブラウザのプロキシ設定などがなされている）負荷分散装置２に対しコンテンツを要求する。この場合の要求メッセージ（１）を下記の表２に示す。
【００４５】
【表２】

【００４６】
これは、送信元を、ＩＰアドレスが“Ｄ”のユーザ１としてポート番号“１０００”に出力し、宛先を、ＩＰアドレスがＥの負荷分散装置２としてポート番号“８０８０”に入力し、そのデータ内容が“ｗｗｗ．ｋｕｒｏｓａｗａ．ｃｏｍ”であることを示している。
【００４７】
［２］負荷分散装置２では受信部１１において、図５のフローチャートに示すように、上記の要求メッセージ（１）を受信したことがステップＳ１で判定され、次に該メッセージ（１）が後述する「代行要求の応答」ではないことがステップＳ２で分かるので、ステップＳ４で進む。ここでは、メッセージ（１）の状態が「要求」であることが分かるので、ステップＳ５に進み、メッセージ（１）を通信記録部１２に送る。
【００４８】
［３］通信記録部１２は、図６のフローチャートに示すように、ステップＳ１１でメッセージ（１）を受信した後、ステップＳ１２において、受信メッセージ（１）内の、送信元ＩＰアドレスＤとそのポート番号１００００、及び宛先ＩＰアドレスＥとそのポート番号８０８０を通信記録ＤＢ１５に記録する。この結果、通信記録ＤＢ１５の内容（１）は下記の表３のようになる。
【００４９】
【表３】

【００５０】
なお、この場合、ユーザ１を送信元▲１▼とし、負荷分散装置２を宛先▲１▼としている。送信元▲２▼及び宛先▲２▼については後述する。
［４］また、通信記録部１２は、図６のステップＳ１３により、該要求メッセージ（１）をキャッシュ（サーバ）決定部１６に送信する。
【００５１】
［５］キャッシュ決定部１６は、図７のフローチャートに示すように、キャッシュＤＢ１７の情報に基づいてその要求メッセージ（１）を送信すべきキャッシュサーバを決定する。
すなわち、ユーザ１からの要求メッセージ（１）は、表２に示したように、コンテンツのデータ内部が、“ｗｗｗ．ｋｕｒｏｓａｗａ．ｃｏｍ”となっており、図７のステップＳ２１でメッセージ（１）を受信した後、ステップＳ２２においてキャッシュＤＢ１７に予め保持されている表１に示すキーワードと比較すると、キャッシュＤＢ１７のキーワードと一致するものは無く、ステップＳ２３においてキャッシュＤＢ１７の要求履歴と一致するものも無く、さらにステップＳ２４においてキャッシュＤＢ１７の要求履歴と送信元ＩＰアドレスが一致するものも無いことが分かる。
【００５２】
従って、ステップＳ２５に示すように、キャッシュサーバを、表１に示すワイルドカード（デフォルト）のキャッシュサーバ３＿３に暫定的に決定してキャッシュＤＢ１７に要求メッセージを記録する。
この記録に際しては、表１に示すキャッシュ位置の行内で、一番上位に来るように行われる。従って、このときのキャッシュＤＢ１７の内容（２）は下記の表４に示すように更新される。
【００５３】
【表４】

【００５４】
［６］キャッシュ決定部１６は、さらにステップＳ２８により、要求メッセージ（１）を、ステップＳ２５で決定したキャッシュ位置と共に宛先変更部１８に送信する。
［７］宛先変更部１８においては、図８のフローチャートに示すように、ステップＳ３１でメッセージ（１）を受信した後、ステップＳ３２においてメッセージ（１）の状態が「要求」であることが分かるから、ステップＳ３３において、決定したキャッシュ位置Ｃに基づき、要求コンテンツはそのままで、送信者が負荷分散装置２であり、受信者が、決定したキャッシュサーバ３＿３である要求メッセージを作成し、ステップＳ３４において、通信記録ＤＢ１５に記録されているユーザメッセージ情報の行に対して、作成したメッセージのデータを、送信元▲２▼ＩＰアドレスＥ及びそのポート番号２００００並びに宛先▲２▼ＩＰアドレスＣ及びそのポート番号８０８０として記録する。この結果、通信記録ＤＢ１５の内容（２）は次のように更新される。
【００５５】
【表５】

【００５６】
この場合の作成したメッセージ（２）は以下のとおりである。
【００５７】
【表６】

【００５８】
［８］宛先変更部１８は、ステップＳ３７により、作成したメッセージを送信部２１に送信する。
［９］送信部２１は、図９のフローチャートに示すように、ステップＳ４１でメッセージ（２）を受信した後、ステップＳ４２において、受信したメッセージを宛先ＩＰアドレスＣ（キャッシュサーバ３＿３）に向けて送信する。
【００５９】
この結果、キャッシュサーバ３＿３は、該メッセージ（２）を送信部２１から受信し、メッセージ内のデータ内部のコンテンツを外部のオリジンサーバ群４から取得し、この取得したコンテンツを蓄積しつつ、そのコンテンツを負荷分散装置２に送信する。
【００６０】
この場合のメッセージ（３）は次の通りである。
【００６１】
【表７】

【００６２】
なお、キャッシュサーバ３＿３に予めコンテンツが蓄積されている場合には、外部のオリジンサーバ群４からコンテンツを取得する必要は無く、自分が蓄積しているコンテンツを送信すればよいことは言うまでもない。
［１０］受信部１１においては、図５のフローチャートに示す如く、ステップＳ１，Ｓ２，Ｓ４を通ってステップＳ６により、受信したメッセージ（３）が「提供」の状態であることが分かるので、該提供メッセージ（３）をステップＳ７に示すようにコンテンツ分類部１３に送る。
【００６３】
［１１］コンテンツ分類部１３においては、図１０のフローチャートに示すように、ステップＳ５１でメッセージ（３）を受信した後、ステップＳ５２において、メッセージ（３）内のデータ内部にキャッシュＤＢ１７のキーワードと一致するものがあるか否かを判定する。
【００６４】
この場合には、上記の表７に示すメッセージ（３）がデータ内部に「映画」及び「監督」をキーワードとして含んでいるので、表４に示したキャッシュＤＢ１７の内容（２）においてキャッシュサーバ３＿１に該当するとステップＳ５３で判定し、このコンテンツはキャッシュ位置Ａに該当すると判定する。そして、キャッシュＤＢ１７の内容をメッセージ（３）と通信記録ＤＢ１５の内容（２）に基づいて更新する。
【００６５】
すなわち、ステップＳ５３においてメッセージ（３）内の送信元ＩＰアドレスＣと、キーワードが一致した行のキャッシュ位置Ａが一致しているか否かを判定し、一致していれば何もせずに該メッセージ（３）を宛先変更部１８に送るが、この場合は一致していない（Ａ≠Ｂ）ので、ステップＳ５４に進む。
【００６６】
ステップＳ５４では、通信記録ＤＢ１５の内容（２）から、コンテンツを要求していたユーザ（送信元▲１▼ＩＰ）アドレスを検出し、そのユーザの要求ＵＲＬをキャッシュＤＢ１７の内容（２）から獲得し、受信したメッセージ（３）内のデータがキーワードと一致したキャッシュサーバＡを指定して要求代行部２０に該当要求ＵＲＬを送信する。
【００６７】
そして、ステップＳ５５において、該当するＵＲＬ及びメッセージ（３）内部のデータから、ランダムにキーワードを抽出し、該当する行のキャッシュＤＢ１７のキーワード部分に加入し、ステップＳ５６において、該当する要求履歴を、データ内部が一致したキャッシュ位置の行の要求履歴の先頭に移動させる。
【００６８】
このようにして更新されたキャッシュＤＢ１７の内容（３）は次のようになる。
【００６９】
【表８】

【００７０】
［１３］またコンテンツ分類部１３は、ステップＳ５７により、宛先変更部１８に対して受信したメッセージを送信する。
宛先変更部１８では、図８に示すようにステップＳ３１及びＳ３２を経由してステップＳ３５においてメッセージの状態が「提供」であることが分かるので、ステップＳ３６において、メッセージの送信元ＩＰアドレスと宛先ＩＰアドレスとを入れ替えたメッセージを作成し、ステップＳ３７によりこのメッセージを送信部２１に送信する。
【００７１】
この場合のメッセージ（４）は次のようになる。
【００７２】
【表９】

【００７３】
送信部２１は、上記［９］と同様に、受信したメッセージ（４）をユーザ１に対して送信し、ユーザ１は要求したコンテンツを受信することになる。
［１４］一方、コンテンツ分類部１３は、図１０のステップＳ５４で説明したように、コンテンツを提供したキャッシュサーバがキャッシュサーバ３＿３であり、現在分類したキャッシュサーバ３＿１と異なることから、要求代行部２０に対してキャッシュサーバ３＿１に対するコンテンツ要求のやり直しを指示する。
【００７４】
［１５］要求代行部２０は、図１２に示すように、ステップＳ７１でメッセージ（３）を受信した後、ステップＳ７２でコンテンツ分類部１３からのメッセージであることを検出し、ステップＳ７３において、指定されたＵＲＬのコンテンツを、指定されたキャッシュサーバに要求するメッセージを、要求代行と判別できる識別子（例えばポート番号５００００）を加えて作成し、ステップＳ７６により送信部２１に送信する。
【００７５】
このようにして作成したメッセージ（５）は次のようになる。
【００７６】
【表１０】

【００７７】
そして、送信部２１は、要求代行部２０から送られて来たメッセージ（５）をキャッシュサーバ３＿１に対して送信する。
キャッシュサーバ３＿１は、該メッセージ（５）を受信し、メッセージ内のデータ内部のコンテンツを上記と同様に外部のオリジンサーバ群４から取得し、この取得したコンテンツを蓄積し（或いは蓄積されていたデータから得て）、該当コンテンツを負荷分散装置２に送信する。
【００７８】
この場合のメッセージ（６）は以下のようになる。
【００７９】
【表１１】

【００８０】
受信部１１においては、ステップＳ１でメッセージ（６）を受信した後、ステップＳ２においてメッセージ（６）が「代行要求の応答」であることが分かるので、ステップＳ３に示すように受信メッセージを廃棄する。
［１６］一方、タイマー部１９は、一定周期を計時しており、図１１のステップＳ６１及びＳ６２に示す如く、予め設定された時間間隔が経過すると、要求代行部２０に対して要求代行を行うように指示することができる。
【００８１】
［１７］要求代行部２０は、タイマー部１９から指示を受けると、キャッシュＤＢ１７の情報に基づき、各キャッシュ位置の上位にある要求コンテンツに対して該当キャッシュサーバに対してコンテンツ要求を行うメッセージを作成し送信部２１に送信する。
【００８２】
すなわち、図１２において、ステップＳ７１でメッセージを受信した後、ステップＳ７２を経由してステップＳ７４においてタイマー部１９からのメッセージであることを検出した後、ステップＳ７５において、キャッシュＤＢ１７から、各キャッシュサーバに対して各キャッシュ位置の行にある要求履歴の先頭から所定個数（例えば１個）だけ要求コンテンツを取得して、対応するキャッシュサーバに対して要求メッセージを、要求代行と分かる識別子（ポート番号５００００）を加えて作成し、ステップＳ７６によりそのメッセージを送信部２１に送信する。
【００８３】
送信部２１は、該当するキャッシュサーバに対して該要求メッセージを送信し、要求を受けた各キャッシュサーバは、それぞれ最新のコンテンツを取得してそれぞれ最新のコンテンツを外部のオリジンサーバ群４から取得し、そのコンテンツを負荷分散装置２に送信する。このコンテンツは、上記と同様に廃棄される。
【００８４】
［１８］また、外部からユーザインタフェース部１４に対して指示が与えられた場合には、受信部１１は、図５において、ステップＳ１，Ｓ２，Ｓ４，Ｓ６を経由してステップＳ８においてメッセージの状態が「ユーザインタフェース（ＵＩ）指示」であることを検出するので、そのメッセージをユーザインタフェース部１４に送信する。
【００８５】
この場合のメッセージ（７）は次の通りである。
【００８６】
【表１２】

【００８７】
［１９］ユーザインタフェース部１４は、図１３のステップＳ８１でメッセージ（７）を受信した後、ステップＳ８２において通信記録ＤＢ１５へのアクセス支持であることを検出し、この場合指定に基づき通信記録ＤＢ１５の内部データを変更、取得、又は追加する。
【００８８】
［２０］同様にしてユーザインタフェース部１４はキャッシュＤＢ１７に対し、図１３のステップＳ８４により、ステップＳ８５と同様にキャッシュＤＢ１７の内部データを変更、取得、又は追加する。
［２１］さらにユーザインタフェース部１４は、図１３のステップＳ８６により、タイマー部１９へのアクセス指示を判定したとき、ステップＳ８７により、タイマー部１９の時間間隔を変更又は取得する。
【００８９】
［２２］そしてユーザインタフェース部１４は、送信部２１に対し、ステップＳ８８に示す如く作業結果をデータ内部とし、受信したメッセージの送信者を宛先としたメッセージを作成し、ステップＳ８９により作成したメッセージを送信部２１に送信する。
【００９０】
このときのメッセージ（８）は次の通りである。
【００９１】
【表１３】

【００９２】
このメッセージ（８）は送信部２１から外部に送信される。
なお、上記の実施例においては、分類したコンテンツに対応するキャッシュサーバが検出できない場合、予め決めたキャッシュサーバを介してオリジンサーバからそのコンテンツを取得するようにしているが、負荷分散装置の側で、別のキャッシュサーバにそのコンテンツが蓄積されていることが分かれば、オリジンサーバからコンテンツを取得する代わりに、その蓄積しているキャッシュサーバからコンテンツを取得するようにしてもよい。
（付記１）
ユーザが位置する第１の通信端末と、コンテンツを一時的に蓄積することが可能な複数の第２の通信端末と、該コンテンツを予め保持している第３の通信端末とで構成されるネットワークの負荷分散方法において、
該第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している該第２の通信端末の内、該希望のコンテンツを蓄積しているものを検出する第１ステップと、
該検出した第２の通信端末に該希望のコンテンツを要求することにより取得して該第１の通信端末に送信する第２ステップと、
を備えたことを特徴とする負荷分散方法。
（付記２）付記１において、
該希望のコンテンツを蓄積している第２の通信端末を検出できないとき、該第２の通信端末の内で予め決めたものを介して該第３の通信端末に要求することにより該希望のコンテンツを取得し、該第２の通信端末にキャッシュさせてから該第１の通信端末に転送する第３ステップと、
該第２の通信端末の内で該ジャンルに対応して該希望のコンテンツを蓄積すべきものを該コンテンツ中のキーワードに基づいて検出し、この第２の通信端末を介して該希望のコンテンツを該第３の通信端末に要求し直すことにより取得し、該第２の通信端末にキャッシュさせる第４ステップと、
をさらに備えたことを特徴とする負荷分散方法。
（付記３）付記２において、
該第４ステップでは、該希望のコンテンツの要求し直しを、即座に、又は該第１の通信端末からのコンテンツ要求を契機として行うことを特徴とした負荷分散方法。
（付記４）付記２において、
該第４ステップでは、該希望のコンテンツの要求し直しを、定期的に行うことを特徴とした負荷分散方法。
（付記５）付記２において、
該コンテンツを要求した該第１の通信端末の識別子と該コンテンツ要求の宛先となる該第２の通信端末とを関連付けた履歴を記録することにより、現在どの第１の通信端末がどのコンテンツを要求し、このコンテンツをどの第２の通信端末に要求したかを記録する第５ステップをさらに備えたことを特徴とする負荷分散方法。
（付記６）付記２において、
該第２の通信端末と該キーワードと該第１の通信端末のコンテンツ要求とを関連付けた履歴を保持することにより、どの第２の通信端末がどの第１の通信端末からどんなキーワードのコンテンツが要求されたのかを保持する第６ステップをさらに備えたことを特徴とする負荷分散方法。
（付記７）付記６において、
該履歴を、外部から参照又は変更可能にしたことを特徴とする負荷分散方法。
（付記８）付記１において、
該第２の通信端末がキャッシュサーバであり、該第３の通信端末がオリジンサーバ群であることを特徴とする負荷分散方法。
（付記９）
ユーザが位置する第１の通信端末と、コンテンツを一時的に蓄積することが可能な複数の第２の通信端末と、該コンテンツを予め保持している第３の通信端末とで構成されるネットワークの負荷分散装置において、
該第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している該第２の通信端末の内、該希望のコンテンツを蓄積しているものを検出する第１手段と、
該検出した第２の通信端末に該希望のコンテンツを要求することにより取得して該第１の通信端末に送信する第２手段と、
を備えたことを特徴とする負荷分散装置。
（付記１０）付記９において、
該希望のコンテンツを蓄積している第２の通信端末を検出できない時、該第２の通信端末の内で予め決めたものを介して該第３の通信端末に要求することにより該希望のコンテンツを取得し、その第２の通信端末にキャッシュさせてから該第１の通信端末に転送する第３手段と、
該第２の通信端末の内で該ジャンルに対応して該希望のコンテンツを蓄積すべきものを該コンテンツ中のキーワードに基づいて検出し、この第２の通信端末を介して該希望のコンテンツを該第３の通信端末に要求し直すことにより取得し、該第２の通信端末にキャッシュさせる第４手段と、
をさらに備えたことを特徴とする負荷分散装置。
（付記１１）付記１０において、
該第４手段は、該希望のコンテンツの要求し直しを、即座に、又は該第１の通信端末からのコンテンツ要求を契機として行うことを特徴とした負荷分散装置。
（付記１２）付記１０において、
該第４手段は、該希望のコンテンツの要求し直しを、定期的に行うことを特徴とした負荷分散装置。
（付記１３）付記１０において、
該コンテンツを要求した該第１の通信端末の識別子と該コンテンツ要求の宛先となる該第２の通信端末とを関連付けた履歴を記録することにより、現在どの第１の通信端末がどのコンテンツを要求し、このコンテンツをどの第２の通信端末に要求したかを記録する記録部をさらに備えたことを特徴とした負荷分散装置。
（付記１４）付記１０において、
該第２の通信端末とコンテンツのキーワードと該第１の通信端末のコンテンツ要求とを関連付けた履歴を保持することにより、どの第２の通信端末がどの第１の通信端末からどんなキーワードのコンテンツが要求されたのかを保持する保持部をさらに備えたことを特徴とする負荷分散装置。
（付記１５）付記１４において、
該履歴を、外部から参照又は変更可能にしたことを特徴とする負荷分散装置。（付記１６）付記９において、
該第２の通信端末がキャッシュサーバであり、該第３の通信端末がオリジンサーバ群であることを特徴とする負荷分散装置。
【００９３】
【発明の効果】
以上説明したように本発明に係る負荷分散方法及び装置によれば、第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している第２の通信端末の内、その希望のコンテンツを蓄積しているものを検出し、この検出した第２の通信端末にその希望のコンテンツを要求することにより取得して第１の通信端末に送信するように構成したので、ユーザからの要求を該当するジャンルのキャッシュサーバに最適に振り分けることができ、ユーザからの要求に対してヒット率を向上させ、レスポンスタイムの短縮を実現することができる。
【００９４】
また、その希望のコンテンツを蓄積している第２の通信端末が分からないときには、予め決めた第２の通信端末を介して第３の通信端末から希望のコンテンツを取得し第２の通信端末にキャッシュさせてから第１の通信端末に転送すると共に、該第２の通信端末の内でジャンルに対応して希望のコンテンツを蓄積すべきものをコンテンツのキーワードに基づいて検出し、この第２の通信端末を介して希望のコンテンツを第３の通信端末に対して要求し直すことにより取得し、第２の通信端末にキャッシュさせるようにすれば、対応したジャンルの最新のコンテンツが順次学習により蓄積されて行くことになる。
【００９５】
また、内部に保持する履歴を外部から参照又は変更可能にすることで、外部から状態確認や制御を行うことが可能となる。
【図面の簡単な説明】
【図１】本発明に係る負荷分散方法及び装置のネットワーク概要図である。
【図２】本発明に係る負荷分散方法及び装置の動作原理を説明するための図である。
【図３】本発明に係る負荷分散方法及び装置の実施例の全体を示した図である。
【図４】本発明に係る負荷分散方法及び負荷分散装置を実現する実施例を示したブロック図である。
【図５】本発明に係る負荷分散方法及び装置に用いる受信部の動作例を示したフローチャート図である。
【図６】本発明に係る負荷分散方法及び装置に用いる通信記録部の動作例を示したフローチャート図である。
【図７】本発明に係る負荷分散方法及び装置に用いるキャッシュ決定部の動作例を示したフローチャート図である。
【図８】本発明に係る負荷分散方法及び装置に用いる宛先変更部の動作例を示したフローチャート図である。
【図９】本発明に係る負荷分散方法及び装置に用いる送信部の動作例を示したフローチャート図である。
【図１０】本発明に係る負荷分散方法及び装置に用いるコンテンツ分類部の動作例を示したフローチャート図である。
【図１１】本発明に係る負荷分散方法及び装置に用いるタイマー部の動作例を示したフローチャート図である。
【図１２】本発明に係る負荷分散方法及び装置に用いる要求代行部の動作例を示したフローチャート図である。
【図１３】本発明に係る負荷分散方法及び装置に用いるユーザインタフェース部の動作例を示したフローチャート図である。
【図１４】従来から知られているキャッシュサーバの構築例を示した図である。
【図１５】キャッシュサーバの一般的な負荷分散例を示したブロック図である。
【図１６】従来から知られているリクエスト・リルーティングシステムによる負荷分散例を示した図である。
【符号の説明】
１（１＿１，１＿２，１＿３，・・・）　ユーザ（クライアント）
２　　負荷分散装置
３（３＿１，３＿２，３＿３，・・・）　キャッシュサーバ
４（４＿１，４＿２，４＿３，・・・）　オリジンサーバ群
１１　受信部
１２　通信記録部
１３　コンテンツ分類部
１４　ユーザインタフェース部
１５　通信記録部
１６　キャッシュ決定部
１７　キャッシュＤＢ
１８　宛先変更部
１９　タイマー部
２０　要求代行部
２１　送信部
図中、同一符号は同一又は相当部分を示す。

Claims

ユーザが位置する第１の通信端末と、コンテンツを一時的に蓄積することが可能な複数の第２の通信端末と、該コンテンツを予め保持している第３の通信端末とで構成されるネットワークの負荷分散方法において、
該第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している該第２の通信端末の内、該希望のコンテンツを蓄積しているものを検出する第１ステップと、
該検出した第２の通信端末に該希望のコンテンツを要求することにより取得して該第１の通信端末に送信する第２ステップと、
を備えたことを特徴とする負荷分散方法。
請求項１において、
該希望のコンテンツを蓄積している第２の通信端末を検出できないとき、該第２の通信端末の内で予め決めたものを介して該第３の通信端末に要求することにより該希望のコンテンツを取得し、該第２の通信端末にキャッシュさせてから該第１の通信端末に転送する第３ステップと、
該第２の通信端末の内で該ジャンルに対応して該希望のコンテンツを蓄積すべきものを該コンテンツ中のキーワードに基づいて検出し、この第２の通信端末を介して該希望のコンテンツを該第３の通信端末に要求し直すことにより取得し、該第２の通信端末にキャッシュさせる第４ステップと、
をさらに備えたことを特徴とする負荷分散方法。
請求項２において、
該第４ステップでは、該希望のコンテンツの要求し直しを、即座に、又は該第１の通信端末からのコンテンツ要求を契機として行うことを特徴とした負荷分散方法。
ユーザが位置する第１の通信端末と、コンテンツを一時的に蓄積することが可能な複数の第２の通信端末と、該コンテンツを予め保持している第３の通信端末とで構成されるネットワークの負荷分散装置において、
該第１の通信端末が、希望するコンテンツを要求したとき、ジャンル別にコンテンツをそれぞれ蓄積している該第２の通信端末の内、該希望のコンテンツを蓄積しているものを検出する第１手段と、
該検出した第２の通信端末に該希望のコンテンツを要求することにより取得して該第１の通信端末に送信する第２手段と、
を備えたことを特徴とする負荷分散装置。
請求項４において、
該希望のコンテンツを蓄積している第２の通信端末を検出できない時、該第２の通信端末の内で予め決めたものを介して該第３の通信端末に要求することにより該希望のコンテンツを取得し、その第２の通信端末にキャッシュさせてから該第１の通信端末に転送する第３手段と、
該第２の通信端末の内で該ジャンルに対応して該希望のコンテンツを蓄積すべきものを該コンテンツ中のキーワードに基づいて検出し、この第２の通信端末を介して該希望のコンテンツを該第３の通信端末に要求し直すことにより取得し、該第２の通信端末にキャッシュさせる第４手段と、
をさらに備えたことを特徴とする負荷分散装置。