分散要求ルーティング
クライアント要求を処理する複数のサーバが、それらの間で要求を転送することにより負荷の平衡化を達成する。サーバは、最初にクライアント要求を受け取ると、ファーストチャンスサーバと呼ばれる、複数のサーバのうちの別のサーバを無作為に選択し、要求をこのサーバに転送する。ファーストチャンスサーバは、要求を受け取ると、過負荷であるか否かを判断し、そうでない場合に要求を処理する。しかし過負荷の場合は、その負荷を１つ又は複数の所定の隣接サーバの負荷と比較する。隣接サーバ（複数可）の方がファーストチャンスサーバより高負荷の場合、ファーストチャンスサーバは要求を処理する。そうでない場合、ファーストチャンスサーバは要求を最も負荷のかかっていない隣接サーバに転送する。要求を受け取る隣接サーバは、それを直接処理するか、又はその現負荷及びその隣接サーバ（複数可）の負荷に基づいて別の隣接サーバに要求を転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
［発明の分野］
本発明は、包括的には負荷分散に関する。詳細には、本発明は、要求を処理のために複数のサーバの間で平衡化する要求ルーティング方法に関する。
【背景技術】
【０００２】
［発明の背景］
クライアント・サーバアプリケーションは、次第に複数のサーバにわたって配備されるようになってきている。これらのサーバは、異なる地理的場所にあってもなくてもよく、合せて特定のアプリケーションに対するバックエンド処理能力を提供する。たとえば、サーバは、ウェブページをキャッシュしクライアントウェブブラウザからの要求に応答する、地理的に分散したウェブキャッシュプロキシ等、コンテンツ配信網をサポートすることができる。サーバはまた、インターネットに配備されるグリッド（ＧＲＩＤ）機能の汎用コンピューティングマシン（ＰＣ、ワークステーション、…）であってもよく、そこでは、各サーバは、グリッドクライアントユーザによって提出されるタスクを受け取り処理する。サーバはまた、共有ディスク並列データベースサーバ若しくは共有メモリ並列データベースサーバ又はレプリケーションデータベースサーバ等のデータベースサーバであってもよい。同様に、複数のコンピューティングマシンにわたってピア・ツー・ピアアプリケーションも配備されており、ピア群からの任意のピアが別のピア／サーバントからの要求を処理する。（なお、説明を容易にするために、クライアント・サーバの用語及び例を使用して本発明を説明することに留意されたい。しかしながら、本発明は、ピア・ツー・ピアアーキテクチャを含む他のアーキテクチャ／アプリケーションにも適用可能であることが理解されるべきである。）
【０００３】
説明の目的で、特定のアプリケーションのための要求／タスクを処理することを目的とするｍ個のサーバ（０、１、…、ｍ−１と番号を付す）と、これらのサーバに対して要求／タスクを送信することができる任意の数のクライアントとがあると想定する。従来、これらのマルチサーバ環境では、ｍ個のサーバのうち、クライアントの要求を最初に受け取ったサーバが、この要求の処理を行い、結果をクライアントに返す。しかしながら、これらの複数サーバ環境では、クライアント要求をサービスするために次第に要求ルーティングを使用するようになってきている。要求ルーティングでは、実際にクライアント要求を受け取るサーバは、何らかの方式を使用してｍ個のサーバのうちの別のサーバを確定し、その後、要求を処理のためにこの確定したサーバに転送する。たとえば、図１は、サーバ１０２〜１０５と、処理のためにこれらのサーバに要求／タスクを送信するクライアント１１０〜１１５とを含む一例としてのネットワーク１００を示す。クライアント１１２がサーバ１０３に要求１２０を送信すると想定する（サーバ１０３の選択は、無作為であっても所定の選択であってもよい）。サーバ１０３は、この要求を受け取ると、要求ルーティング方式を実行して、サーバ１０５等、この要求を実際にサービスする別のサーバを確定する。そして、サーバ１０３は、要求１２０をクライアント１１２からこのサーバ１０５に転送する。そして、サーバ１０５は、この要求を処理し、結果１２１をサーバ１０３に返し、そして、サーバ１０３は結果をクライアント１１２に転送する。
【０００４】
管理者は、これらのマルチサーバ環境において、様々なことを目的として要求ルーティング方式を使用する。これらの目的は、たとえば、クライアントが求めているコンテンツ情報を有する可能性がより高いサーバに要求をルーティングするため、クライアントへの近接性に基づいてサーバ／ネットワークに要求をルーティングするため、帯域幅の可用性に基づいて要求をルーティングするため、及びサーバ間で負荷を平衡化するために要求を
ルーティングするためなどである。最後の用途、すなわち負荷分散は、ここでは特に重要である。より具体的には、任意の数のクライアントをサポートするｍ個のサーバから成るマルチサーバ環境の場合、優れた性能スケーラビリティを達成することを目的として、サーバ間でクライアント要求を分散させるために要求ルーティングの使用することが増えている。負荷分散要求ルーティング方式によれば、クライアント要求到着率が増減するのに合わせて、ｍ個のサーバの各々における負荷も一様に増減することが保証される。それにより全体的に応答時間（たとえば、ウェブページダウンロード時間、タスク完了時間）が短くなり、スループットが高くなり、且つクライアント要求に対する可用性が高くなることが確実になる。それにも拘わらず、クライアント要求率及び／又はサーバの数が増大する際にスケーラブルであり、且つ分散サーバ間での平衡化した負荷を達成する負荷分散要求ルーティング方式は、システム全体の動的性質のため、且つ予測不可能なタスク到着パターン及びタスクサイズのため、得ることが困難である。
【０００５】
従来、負荷分散には、以下を含むいくつかの要求ルーティング方式／方法が使用されてきた。すなわち、（１）「最低負荷」、（２）「２つのランダム選択」、（３）「ランダム」及び（４）「ラウンドロビン」である。「最低負荷」要求ルーティング方法は、クライアント要求が受け取られた時の全サーバの負荷を知っているサーバに依存する。特に、この方法は、通常、非集中化式か又は集中化式で実装される。非集中化の実装では、ｍ個のサーバのいずれもが最初にクライアント要求を受け取ることができる。サーバは、要求を受け取ると、ｍ個のサーバ群の中で、その時点で負荷が最低であるサーバを確定し、その後、そのサーバに対し処理のために要求をルーティング／転送する。集中化の実装では、ディスパッチャが使用される。このディスパッチャが、まず、任意のクライアント要求を受け取り、その要求をその時点で負荷が最低であるサーバに転送する。
【０００６】
実装に拘わらず、「最低負荷」方法においては、ディスパッチャ／初期（initial）サーバが、要求を受け取って転送する時点での他の全サーバの負荷を知っていれば、サーバ間で負荷を最適に分散することができる。これらの条件下であれば、最低負荷方法は、サーバ間で負荷を平衡化することができ、且つスケーラブルであって、クライアント要求率が増大するに従い、クライアント要求に対する全応答時間は緩やかに増大する。しかしながら、これらの理想的な条件が満足されず、サーバにおける現負荷情報が正確ではない（すなわち、陳腐化する）場合、負荷分散はあまり正確でなくなり、クライアント要求に対する平均応答時間は急激に増大することになる。
【０００７】
「最低負荷」方法においてサーバ間で負荷情報を広める一方法は、ポーリング方法を用いる方法である。ここでは、ディスパッチャ又は各サーバは、他のサーバに現在の負荷を定期的にポーリングする。ディスパッチャ／サーバが他のサーバの現負荷に関して最新状態を保持できるように、ポーリング率は非常に高く設定されることが理想的である。しかしながら、ポーリングには、ディスパッチャ／サーバ毎におよそＯ（ｍ）のメッセージオーバヘッドが必要である。同様に、ネットワークが拡大し、サーバの数ｍが増大するに従い、ディスパッチャ／サーバにおけるポーリング負荷もまた増大する。このため、オーバヘッドを増大させるが負荷情報を最新に維持する高い／適当なポーリング率と、オーバヘッドを低減するが陳腐化した負荷情報をもたらす低ポーリング率との間にトレードオフがある。
【０００８】
ピギーバック方法は、メッセージオーバヘッドが大きいポーリング方法に対する代替方法である。通常は、サーバが別のサーバに処理をしてもらうために要求を転送する場合、処理サーバは、転送サーバに対して応答を返すことになる。ピギーバック方法では、処理サーバは、この応答を返す時に転送サーバに対してその現負荷も送信する。転送サーバは、後続するクライアント要求を処理する時にこの負荷情報を利用する。その結果、この方法では、ポーリング方法のオーバヘッド問題が起こらない。しかしながら、上記と同様に
、各サーバにおいて負荷情報が最新でない場合、サーバは、負荷が最低ではないサーバにクライアント要求を転送する可能性があり、それによりクライアント要求に対する平均応答時間が増大することになる。
【０００９】
より詳細には、ピギーバック方法での負荷情報の配布は、要求率に直接連動する。要求率が増大すると、各サーバは初期クライアントの要求をより頻繁に受け取ることになる。そして、各サーバが要求をより頻繁に転送し、それにより負荷情報をより頻繁に受け取ることになる。このため、要求率が低すぎる場合、負荷情報が最新の状態に維持されないことになる。この問題に幾分か関連して、ネットワークが拡大しサーバの数ｍが増大するに従い、要求がより広く分散／分配されるため、各サーバが他のすべてのサーバにおいて最新であり続けることはより困難となる。特に、ディスパッチャ方法は、これらの問題のいくつかを克服する可能性があるが、ディスパッチャがシステムに対するボトルネック及び単一障害点（single point of failure）となる。
【００１０】
「最低負荷」方法では、負荷情報の陳腐化に直接関連する「フラッシュクラウド（flashing crowd）」問題もある。一般に、あるサーバが他のサーバより比較的負荷が低いと想定する。このサーバに関する負荷情報が他のすべてのサーバに対して十分頻繁に広められていない場合、他のサーバは、常にこのサーバの負荷が低いと判断し、要求をこのサーバにすべて転送することになり、このサーバが突然過負荷になってしまう。そして、問題は連鎖する。残りのサーバは、この時、次に負荷が低いサーバを検知し、要求を再びそのサーバに転送し、このサーバが過負荷になる。このシナリオは、サーバの各々において順に続き、最後には負荷を平衡化するという当初の意図が覆される。
【００１１】
「２つのランダム選択」方法について述べると、ここではサーバは、最初にクライアントから要求を受け取る度に、すべてのサーバの中から一様にランダムに他の２つのサーバを選択する。そして、最初のサーバは、２つのランダムに選択したサーバの負荷を比較し、負荷の低い方のサーバに処理をさせるために要求を転送する。たとえば、図１において、クライアント１１０がサーバ１０３に要求を送信すると想定する。サーバ１０３は、この要求を受け取ると、サーバ１０２及びサーバ１０４等の他の２つのサーバをランダムに決定する。そして、サーバ１０３は、サーバ１０２の現負荷とサーバ１０４の現負荷とを比較し、負荷の低い方のサーバに要求を転送する。そして、要求を転送されたサーバは、結果をサーバ１０３に返し、サーバ１０３は結果をクライアント１１０に転送する。
【００１２】
「最低負荷」方法と同様に、「２つのランダム選択」方法では、理想的には、各サーバが、要求が転送されている時点で他のすべてのサーバの負荷を知っていることが必要である（２つのランダムに選択されるサーバがどのサーバでもあり得るため）。これらの理想的な条件が満たされると想定すると、「２つのランダム選択」方法は、「最低負荷」方法と略同様に適切に機能し且つスケールし、クライアント要求率が増大するに従い、クライアント要求に対する全応答時間が緩やかに増大する。しかしながら、上記のように、「２つのランダム選択」方法は、実際にはピギーバック方法又はポーリング方法を使用し、サーバ毎におよそＯ（ｍ）のメッセージオーバヘッドが必要である。したがって、２つの「ランダム選択」方法には、上述した「最低負荷」方法と同じ問題がある。すなわち、負荷情報がサーバ間で充分頻繁に広められない場合、各サーバにおける情報が陳腐化し、その結果、クライアント要求に対する平均応答時間が急激に増大する。したがって、この方法でもまた、フラッシュクラウド問題が起こる可能性がある。
【００１３】
「ランダム要求」ルーティング方法に関して述べると、サーバは、クライアントから最初に要求を受け取る度に、すべてのサーバの中から一様に無作為に選択された別のサーバにその要求を転送する。負荷情報がまったく使用されないため、この方法は、「最低負荷」方法及び「２つのランダム選択」方法で負荷情報を順に回す際に発生する欠点のすべて
を回避する。メッセージオーバヘッドがなく、したがって陳腐化問題もない。したがって、この方法では、「フラッシュクラウド」問題がなく、サーバの数ｍが増大する際に悪影響を受けず、クライアント要求に対する応答時間は一定のままである。
【００１４】
しかしながら、ランダム要求方法は適切にスケールせず、ｍ個のサーバ間で負荷を均等に拡散させないということが証明され且つ経験的に示されている。より詳細には、クライアント要求率が増大するに従い、サーバによっては他のサーバより負荷が重くなり、他のサーバより早く最大負荷容量に達する。その結果、過負荷サーバが利用不可能となるか又は要求の処理に遅延が生じるようになるに従って、ｍ個のサーバ間のクライアント要求に対する全応答時間が増大する。したがって、「最低負荷」方法及び「２つのランダム選択」方法での負荷情報が正確に保たれると想定すると、これらの２つの方法は「ランダム」方法よりかなり適切に機能する。
【００１５】
「ラウンドロビン」要求ルーティング方法について述べると、サーバは、最初にクライアントから受け取る各要求について、その要求を他のサーバに処理させるためにラウンドロビン式で連続的に転送する（すなわち、最初のサーバは、要求ａをサーバｉに転送し、要求ｂをサーバｉ＋１に転送し、要求ｃをサーバｉ＋２に転送する、等である）。このメカニズムにより、サーバを選択するための乱数発生器の使用が回避され、この場合もまた、サーバ間で負荷情報を渡さなければならないマイナス面が回避される。しかしながら、概して、この方法にはスケーラビリティに関し「ランダム」方法と同じ問題があることが一般に知られている。クライアント要求率が増大するに従い、サーバによっては他のサーバより負荷が重くなり、クライアント要求に対する応答時間が急速に増大する。さらに、この方法の下でサーバが同期化されてしまい、各サーバが要求を続けて同じサーバに転送する可能性があり、それにより「フラッシュクラウド」シナリオがもたらされる。
【００１６】
示したように、「最低負荷」方法及び「２つのランダム選択」方法は、負荷情報がそれほど陳腐化しないと想定すると、「ランダム」方法及び「ラウンドロビン」方法よりかなり適切に機能する。負荷情報を交換する要求ルーティング方法であって、負荷情報が陳腐化する場合であっても負荷を適切に平衡化することが示されている他の要求ルーティング方法がさらに存在する。しかしながら、これらの他の方法でも、「最低負荷」方法及び「２つのランダム選択」方法のように、ポーリングが使用される場合に相当量の負荷メッセージオーバヘッドが必要である。より重要なことには、これらの他の方法は、すべてのサーバが全体のクライアント要求到達率を事前に知っていると想定しているが、それは通常現実的ではない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
全般的に、要求ルーティング負荷分散の従来の方法にはいくつかの欠点がある。「最低負荷」方法及び「２つのランダム選択」方法は、適切に機能し且つ要求率が増大してもスケールする。しかしながら、これらの方法は、他のすべてのサーバの負荷を知っていること、及びこの情報が正確であり続けることに依存する。ポーリング方法によればこの精度を提供することができるが、メッセージオーバヘッドが大きくなってしまう。ピギーバック方法は、メッセージオーバヘッド問題を克服するが、要求率が高くない限りすべてのサーバを正確に維持しない。これらの方法には、フラッシュクラウド問題もある。他の方法は、負荷情報の陳腐化による影響が少なく、これらの２つの方法と同程度に適切に機能するが、すべてのサーバが要求到着率を知っていることに依存し、それは実際的ではない。「ランダム」方法及び「ラウンドロビン」方法では、負荷情報を交換する必要がなく、それにより関連する問題が回避されるが、これらの方法は適切にスケールせず、要求到着率が増大するに従って性能が急速に劣化する。
【課題を解決するための手段】
【００１８】
［本発明の概要］
したがって、従来技術のこれらの不都合及び他の不都合を克服し、適切に機能し且つ要求率が増大する際に適切にスケールし、サーバ間の負荷情報を維持するためのオーバヘッドが大きくならない、負荷分散要求ルーティング方法を提供することが望ましい。本発明によれば、ｍ個のサーバ群の中の１つのサーバが最初にクライアントから処理要求を受け取ると、そのサーバはｍ個のサーバ群から別のサーバを無作為に選択し、このサーバに処理させるために要求を転送する。この無作為に選択されたサーバを、ファーストチャンスサーバ（first-chance server）と呼ぶ。
【００１９】
ファーストチャンスサーバは、転送された要求を受け取ると、自身の現負荷を過負荷定数と比較して、現在過負荷であるか否かを判断する。過負荷でない場合、ファーストチャンスサーバは、要求を処理し、応答をクライアントに直接又は転送サーバを介して転送し戻す。しかしながら、ファーストチャンスサーバは、過負荷である場合には、自身の現負荷を所定の隣接サーバの負荷と比較する。ファーストチャンスサーバは、その隣接サーバより低い負荷がかかっているか又は比較的等しい負荷がかかっている場合には、要求を処理する。そして、応答をクライアントに転送し戻す。
【００２０】
しかしながら、ファーストチャンスサーバに隣接サーバより重い負荷がかかっている場合には、要求を隣接サーバに転送する。より詳細には、ファーストチャンスサーバは、この要求を直接転送するか、又は別の方法として最初の転送サーバに隣接サーバについて通知する。この後者の場合、転送サーバは、処理のために要求を隣接サーバに送信する。
【００２１】
本発明の一実施の形態によれば、隣接サーバが要求をいかに受け取るかに拘わらず、隣接サーバは要求を処理し、応答をクライアントに直接、又はファーストチャンスサーバ／転送サーバを介して転送する。また、本発明のさらなる実施形態によれば、隣接サーバは要求を自動的には処理はせずに、ファーストチャンスサーバと同様に続行し、過負荷でないと判断した場合に要求を処理する。過負荷である場合、隣接サーバは自身の負荷を自身に隣接するサーバの負荷と比較し、この第２の隣接サーバより負荷が低い場合には要求を自身で処理し、逆にこの第２の隣接サーバより負荷が重い場合には、要求をこの第２の隣接サーバに転送する。転送される場合、プロセスは同様に続く。
【００２２】
本発明のまたさらなる実施形態によれば、ファーストチャンスサーバは、上述したように１つの隣接サーバのみではなく、２つ以上の隣接サーバを保持する。この場合もまた、ファーストチャンスサーバが過負荷でない場合には、要求を自身で処理する。しかしながら、過負荷である場合には、ファーストチャンスサーバは自身の負荷をその隣接サーバの負荷と比較する。これらの隣接サーバのうちの１つがファーストチャンスサーバより低負荷の場合、ファーストチャンスサーバは要求を処理のためにこの隣接サーバに転送する。そうでない場合、ファーストチャンスサーバは自身で要求を処理する。
【発明の効果】
【００２３】
全体として、本発明はスケーラブルであり、要求率が増大する際、従来技術による方法と比較して優れていなくても同等な性能を得る。さらに、本発明によるサーバは、より正確な負荷情報を維持し、その結果、大幅に優れた性能を達成する。
【発明を実施するための最良の形態】
【００２４】
本発明は、ｍ（０〜ｍ−１）個の複数のサーバ間での負荷の平衡化を目的として、これら複数のサーバのうちの任意のサーバにクライアント要求／タスクを分散させる、簡単かつスケーラブルな要求ルーティング方法である。要求／タスクを処理のためにｍ個のサーバに送信することができるクライアントの数は任意である。さらに、要求に対応する初期
サーバをクライアントがどのように選択するかは種々の方法を採用できる。クライアントは、要求のすべてに対して常に同じサーバを選択しても良いし、各要求に対してサーバを無作為に選択しても良い。（なお、本発明を、クライアント・サーバの用語及び例を使用して説明するが、本発明は、ピア・ツー・ピアアーキテクチャを含む他のアーキテクチャ／アプリケーションに適用可能である、ということが理解されるべきである。）
【００２５】
本発明によれば、各サーバｉ（ｉ＝０〜ｍ−１）は、サーバの現在の作業負荷を表す指標ｗiを保持する。たとえば、ｗiは、サーバｉにおける未解決の要求（すなわち、完了していない要求）の数を示してもよい。現負荷に関し、各サーバはまた、２つの閾値Ｗi及びθiも保持する。Ｗiは、各サーバに固有であっても、いくつかのサーバ又はすべてのサーバにわたって同じであってもよい。Ｗiは、サーバｉが過負荷になり、可能であれば要求を別のサーバにゆだねるべきである点を表す閾値である。θiもまた、各サーバに固有であっても、いくつかのサーバ又はすべてのサーバにわたって同じであってもよい。θiは、隣接サーバがサーバｉより低負荷であり、したがってサーバｉに代わって追加の要求を処理することができる点を示す、サーバｉと隣接サーバとの間の比較閾値である。概して、θiは、サーバｉと隣接サーバとの間の相対的な計算能力に基づいて設定されるべきである。
【００２６】
各サーバはまた、ハッシュ関数Ｈａｓｈ：Ｑi−＞｛０，１，…，ｍ−１｝も保持する（ただしＱiはクライアント要求すべての空間であり、各要求をゼロ（０）とｍ−１との間の乱数に等しい確率でマッピングする）。Ｑi等のハッシュ関数は容易に利用可能であり、本発明に特有なものではない。たとえば、ウェブページ要求ｑ（ただしｑはＵＲＬである）の場合、Ｑi＝「ＵＲＬにおけるすべての文字の和 ｍｏｄ ｍ」である。最後に、各サーバはまた、独自の隣接サーバを有するように隣接サーバの概念も保持する。たとえば、ｍ個のサーバを論理的にリング状に順番に並べることができ、その場合、サーバｉの「隣接サーバ」を、「隣接サーバ＝サーバ（ｉ＋１） ｍｏｄ ｍ」として定義することができる。隣接サーバを保持することに加えて、各サーバｉはまた、後述するように、この隣接サーバの現負荷ｗnext-neighborを測定することも可能である。
【００２７】
サーバ間でクライアント要求を要求ルーティングする本発明の第１の実施形態は、図３Ａ、図３Ｂ及び図３Ｃの方法ステップ及び図２の例示的な例によって示すように、３つのモジュールを含む。説明の目的で、本発明の要求ルーティング方法の一部であるｍ個のサーバのすべてが、３つのモジュールの各々を実行すると想定する。サーバがあるモジュールを実行するか否か及びいつ実行するかは、後述するように、それが要求ｑをいかに受け取るかによって決まる。しかしながら、各サーバがすべてのモジュールを実行する必要はない、ということが理解されるべきである。たとえば、サーバは、最初にクライアント要求を受け取ったときに、図３Ａの方法を実行する。あるサーバが最初のクライアント要求を決して受け取らない場合は、図３Ａの方法を実行する必要はない。さらに、図３Ａ、図３Ｂ及び図３Ｃの方法があるサーバにおいて１つのプロセスとして実行されるか、又はいくつかのプロセスとして実行されるは、本発明では限定されない。
【００２８】
本発明の第１の実施形態の個々のステップについて述べると、クライアント２１０等のクライアントが、最初のサービス要求ｑをサーバ２０２等の任意のサーバｉに対して行うと、サーバｉ２０２は図３Ａの方法を実行する。具体的には、ステップ３０２において、サーバｉ２０２はまず、クライアント２１０から要求ｑを受け取る（２２０に示すように）。サーバｉ２０２は、要求を受け取ると、ステップ３０４に進み、ｍ個のサーバからサーバ２０４等のサーバｋを無作為に決定するために要求ｑに基づいてハッシュ関数Ｑiを実行する（すなわち、ｋ＝０〜ｍ−１の場合、ｋ＝Ｑi（ｑ））。ここで、サーバ２０４を、要求ｑの「ファーストチャンス」サーバと呼ぶ。サーバｋ２０４が決定すると、サーバｉ２０２はステップ３０６に進み、要求ｑを処理のためにサーバｋ２０４に転送する（
２２２に示すように）。そして、サーバｉ２０２はステップ３０８に進み、サーバｋからの応答を待つ。なお、説明の目的で、サーバｋ及びサーバｉを異なるサーバとして示すことに留意されたい。しかしながら、サーバｉは、ランダムサーバｋを選択する時、ｍ個のサーバからの自分自身を選択する場合もある（すなわち、ｋはｉに等しい場合もある）。
【００２９】
サーバｋ２０４は、サーバｉからサービス要求ｑ２２２を受け取ると、図３Ｂの方法を実行する。大まかにいうと、サーバｋは、自身の現負荷をその隣接サーバの負荷と比較し、この比較に基づいて、要求ｑを直接サービスすべきか、要求をその隣接サーバにゆだねるべきであるかを判断する。より具体的には、ステップ３１０で開始して、サーバｋ２０４は、サーバｉ２０２から要求ｑを受け取る。そして、サーバｋはステップ３１２に進み、自分自身の現負荷ｗkを閾値Ｗkと比較する。ｗkがＷk以下である場合（すなわち、ｗk≦Ｗkである場合）、サーバｋは過負荷ではない。この場合、サーバｋはステップ３１４に進み、要求ｑを処理する。そして、サーバｋは、ステップ３１６において要求ｑに対する応答をサーバｉ２０２に返す（２２８に示すように）。サーバｉは、ステップ３１８においてサーバｋからこの応答を受け取り、ステップ３２０においてこの応答をクライアント２１０に返す（２３０に示すように）。なお、ステップ２０２において、サーバｋが要求ｑに対する応答をクライアント２１０に直接返すことは妨げられるものではなく、本発明はいずれの代替形態にも等しく適用可能である、ということに留意されたい。
【００３０】
しかしながら、ステップ３１２において、サーバｋ２０４が過負荷である（すなわちｗk＞Ｗkである）と判断した場合、次に、要求ｑを処理のためにその隣接サーバ（ここでは、たとえばサーバ２０３）に転送すべきか否かを判断する。具体的には、ステップ３２２において、サーバｋは、その現負荷ｗkをその隣接サーバ２０３の現負荷ｗnext-neighborと比較し、２つの負荷が閾値θk内にあるか（すなわちｗk−ｗnext-neighbor≦θk）否かを判断する。なお、サーバｋ２０４がその隣接サーバの現負荷ｗnext-neighborを確定するタイミングは本発明では限定されないことに留意されたい。たとえば、サーバｋは、ステップ３２２の一部として隣接サーバの現負荷を要求してもよい。サーバｋが要求ｑを処理のために隣接サーバに転送する場合、隣接サーバは、サーバｋに返信する応答とともにその現負荷をピギーバックすることができる。そして、サーバｋは、ファーストチャンスサーバとして受け取る後続するクライアント要求に対してこの負荷を使用する。同様に、サーバｋは、バックグラウンドポーリングプロセスの一部として負荷を定期的に要求してもよい。あるいは、隣接サーバ２０３は、その負荷をサーバｋに定期的に送信してもよい。
【００３１】
ステップ３２２においてサーバｋが２つの負荷が閾値θk内にあると判断する場合、サーバｋはその隣接サーバより低い負荷がかかっているか、又は２つのサーバは比較的等しい負荷がかかっている。この場合、サーバｋはステップ３１４に進み、自分自身で要求ｑを処理する。ステップ３１６において、サーバｋ２０４は、要求ｑに対する応答をサーバｉ２０２に返す（２２８に示すように）。サーバｉは、ステップ３１８において、サーバｋからこの応答を受け取り、ステップ３２０において応答をクライアント２１０に返す（２３０に示すように）。（この場合もまた、サーバｋは、別の方法として、要求ｑに対する応答を直接クライアント２１０に送信することができる。）
【００３２】
しかしながら、サーバｋ２０４が、ステップ３２２において、２つの負荷が閾値θk内になく、隣接サーバ２０３にサーバｋ２０４自体より軽い負荷がかかっていると判断した場合、隣接サーバ２０３が要求ｑを処理することに適している。この場合、隣接サーバを、要求ｑの「セカンドチャンスサーバ（second-chance server）」と呼ぶ。したがって、サーバｋ２０４はステップ３２４に進み、要求ｑを処理のためにその隣接サーバ２０３に転送する（２２４に示すように）。そして、サーバｋ２０４はステップ３２６に進み、その隣接サーバ２０３からの応答を待つ。
【００３３】
隣接サーバ２０３は、サーバｋ２０４から要求ｑを受け取ると、「セカンドチャンスサーバ」となり、したがって図３Ｃの方法を実行する。より具体的には、ステップ３３０で開始して、サーバ２０３はサーバｋ２０４から要求ｑを受け取る。そして、サーバ２０３はステップ３３２に進み、要求ｑを処理した後、ステップ３３４に進み、要求ｑに対する応答をサーバｋ２０４に返す（２２６に示すように）。ステップ３２８において、サーバｋは、サーバ２０３からこの応答を受け取り、ステップ３１６において応答をサーバｉ２０２に返す（２２８に示すように）。そして、サーバｉ２０２はステップ３２０においてクライアント２１０に対する応答を返す（２３０に示すように）。（この場合もまた、隣接サーバ２０３は、別の方法として、要求ｑに対する応答をクライアント２１０に直接送信することができる。同様に、サーバｋは、サーバ２０３から応答を受け取ると、サーバｉをバイパスして応答を直接クライアント２１０に送信することができる。）
【００３４】
本発明の第２の実施形態によれば、サーバｋ２０４は、その隣接サーバ２０３が要求ｑを処理すべきであると判断した場合（すなわちステップ３２２）、ステップ３２４において処理のために隣接サーバ２０３に要求ｑを転送するのではなく、サーバｉ２０２に、隣接サーバ２０３がこの要求を処理すべきであることを通知する（すなわち、ステップ３２４〜３２６〜３２８〜３１６がバイパスされる）。したがって、ステップ３２２から、サーバｋ２０４は、隣接サーバ２０３に関する情報を転送することによってサーバｉに迅速に応答する。サーバｉは、この情報を受け取ることに応じて、隣接サーバ２０３に要求ｑを直接転送し、その後サーバ２０３からの応答を待つ。上記と同様に、サーバ２０３は、要求ｑを受け取ると、それを処理し、その後応答をサーバｉ２０２に直接転送し戻し、それによりサーバｉ２０２は応答をクライアント２１０に返す。あるいは、サーバ２０３が応答を直接クライアント２１０に送信してもよい。
【００３５】
全体として、本発明によれば、要求は、サーバｋの負荷が少なくともＷkであり、且つ隣接サーバの負荷より少なくともθk大きい場合にのみ、無作為のファーストチャンスサーバｋからセカンドチャンス／隣接サーバに転送されることに留意されたい。Ｗk及びθkをともにゼロに設定することは、隣接サーバの負荷がサーバｋの負荷より低い場合は、要求ｑが隣接サーバに転送されることを意味する。しかしながら、それとは正反対に、Ｗk又はθkを大きい数に設定すると、本方法は「ランダム負荷」方法に戻り、サーバｋは常に要求を処理して決して隣接サーバを考慮しない。概して、管理者は、個々の環境及びアプリケーションに基づいてＷk及びθkをこれらの２つの両極端の間で変更することができる。たとえば、サーバｋとその隣接サーバとの間で要求を転送することにより、幾分かの余分の通信オーバヘッドがもたらされる（ただし、後述するように、このサーバｋと隣接サーバとの間での要求の転送により、従来技術の純粋な「ランダム」方法と比較して負荷分散が強化される）。したがって、管理者は、負荷分散とこのオーバヘッドとをトレードオフするために、Ｗk及びθkに対して適当な値を採用することができる。異なる観点から、ｍ個のサーバはウェブキャッシュプロキシであると想定する。ここで、管理者は、Ｗk及びθkを、サーバｋをその隣接サーバより優先する値に設定することができ、それには、サーバｋにおけるキャッシュヒット率を増大させるという効果がある。この場合もまた、これは負荷分散を犠牲にする可能性がある。したがって、管理者は、キャッシュヒット率と負荷分散とのバランスをとるような２つのパラメータに対する適当な値を採用することができる。
【００３６】
全体として、本発明はスケーラブルであり、「ランダム」方法及び「ラウンドロビン」方法より優れた性能を提供し、「最低負荷」方法及び「２つのランダム選択」方法より優れていなくても同等な性能を提供する。この利点に加えて、本発明は、使用する方法に関わらず「最低負荷」方法及び「２つのランダム選択」方法と比較してメッセージパッシングのオーバヘッドが最小であり、それにより、本発明の実装の複雑さが軽減し且つ単純と
なる。同様に、本発明は、陳腐化した負荷情報の影響を受けにくくなる。
【００３７】
スケーラビリティに関して、図４は、到着率が増大する際の全応答時間に関して「ランダム」方法、「２つのランダム選択」方法及び本発明を比較する、例示的なシミュレーションを示す。このシミュレーションは、本発明でのすべてのサーバと、「２つのランダム選択」方法によるすべてのサーバとが、他のすべてのサーバの負荷を常に正確に知っているという理想的な条件の下で、且つ本発明でのＷk及びθkがすべてのサーバに対してゼロ（０）に設定されて、行われた。図から分かるように、本発明は、要求率が増大するに従って性能が急速に劣化する「ランダム」方法より十分に適切に機能した（この場合もまた、「ラウンドロビン」方法は「ランダム」方法と同様の性能を有するものと推定される）。重要なことに、本発明は、「２つのランダム選択」方法とまさに同程度によく機能した（この場合もまた、「最低負荷」方法は、「２つのランダム選択」方法と同様の性能を有するものと推定される）。
【００３８】
特に、サーバ毎の定期的なポーリング率を高くすることで、このシミュレーションが実行された理想的な条件を達成することができる。重要なことに、「最低負荷」方法及び「２つのランダム選択」方法でのポーリング方法では、各サーバが他のすべてのサーバの現負荷を知っていることが必要であり、サーバ毎にＯ（ｍ）という相当量の負担が課せられる。この相当量のオーバヘッドとは反対に、本発明では、各サーバが、その隣接サーバの現負荷のみを知っていればよく、サーバ毎の複雑性はＯ（１）である。この場合もまた、ピギーバック方法により、本発明のメッセージパッシングのオーバヘッドは「最低負荷」方法及び「２つのランダム選択」方法と同じになる。しかしながら、この場合でさえ、サーバはそれ自体の負荷及び隣接サーバの負荷のみを保持すればよいため、本発明での複雑性が低くなる。「最低負荷」方法及び「２つのランダム選択」方法では、すべてのサーバがそれ自体の負荷と他のすべてのサーバの負荷とを保持しなければならない。このため、本出願では、従来技術の方法に比較して優れていないまでも同等な性能が得られ、より適切に機能する従来の方法に比較してメッセージオーバヘッド及び／又は複雑性が大幅に低減する。
【００３９】
陳腐化した負荷情報に対する影響の受け易さに関し、図５は、要求／到着率が一定に維持されるがサーバの数が増大する際の全応答時間に関して、「最低負荷」方法、「２つのランダム選択」方法、「ランダム」方法及び本発明を比較する、別の例示的なシミュレーションを示す。ここでは、サーバ間で負荷情報を広めるためにピギーバック方法が使用された。したがって、応答を渡す副次的効用として負荷が渡されるため、すべての方法のメッセージオーバヘッド及び複雑性は同じである。さらに、本発明の場合、Ｗk及びθkはすべてのサーバに対してゼロ（０）に設定された。全体として、シミュレーションは、陳腐化した負荷情報を有するサーバの影響を示す。図示するように、「２つのランダム選択」方法及び「最低負荷」方法は陳腐化した負荷情報の影響を受けやすく、「２つのランダム選択」方法は「ランダム」方法まで劣化し、「最低負荷」方法には本質的にフラッシュクラウド効果がもたらされる。全体として、本発明によるサーバは、より正確な負荷情報を保持し、その結果、大幅に優れた性能を達成する。
【００４０】
いくつかの他の点を強調すべきである。第１に、本方法は無作為にファーストチャンスサーバを選択し、各サーバは固有の隣接サーバを有するため、本発明ではフラッシュクラウド問題がない。第２に、上述したように、他の従来技術による要求ルーティング方法は良い性能を達成するが、各サーバが他のすべてのサーバの負荷を知っており、且つ各サーバが要求到着率を知っている必要がある。この場合もまた、本発明は、これらの方法に比較して簡略化され、各サーバはその隣接するサーバの負荷のみを知っていればよい。
【００４１】
ここで本発明のさらなる実施形態を参照する。例示的な一例を図６に示す本発明の第３
の実施形態によれば、隣接サーバ２０３は、「セカンドチャンスサーバ」として作用しサーバｋ２０４からサービス要求ｑを受け取ると、図３Ｃの方法を実行して要求を処理するのではなく、図３Ｂの方法を実行する（本発明のこの実施形態によれば、図３Ｃの方法は不要である）。より具体的には、要求ｑを受け取ると、隣接サーバ２０３はその現負荷を定数Ｗnext-neighbor203と比較する。サーバ２０３の負荷がＷnext-neighbor203以下である場合、それは過負荷ではなく、サービス要求ｑを処理して、応答を直接又はサーバｋ２０４やサーバｉ２０２を介してクライアント２１０に転送し戻す。
【００４２】
しかしながら、隣接サーバ２０３は、それが過負荷であると判断した場合、次に、その隣接サーバ（たとえばサーバ６０２）にかかっている負荷がより軽いためそのサーバに対して要求ｑを処理のために転送すべきであるか否かを判断する。この場合もまた、この判断は、閾値θnext-neighbor203に対するサーバ２０３及びサーバ６０２の負荷の相対的な比較に基づく。サーバ２０３は、サーバ６０２より低負荷又は２つのサーバが比較的等しい負荷であると判断すると、自分自身で要求ｑを処理し、応答をクライアント２１０に直接又はサーバｋ２０４やサーバｉ２０２を介して転送し戻す。
【００４３】
しかしながら、サーバ２０３は、サーバ６０２の負荷の方が軽く要求ｑを処理するのに適していると判断すると、要求ｑを処理のためにサーバ６０２に転送する（６１０に示すように）。したがって、その後サーバ６０２は、また図３Ｂの方法を実行し、要求を実行して応答をクライアントに返す（６１２に示すように）か、又は要求ｑをその隣接サーバに渡す。したがって、あるサーバが十分に利用されておらず、且つ／又はその隣接サーバより負荷が低くなるまで、要求ｑはサーバ間で連続的に渡される。この場合もまた、このように各サーバが要求ｑをその隣接サーバに渡すのではなく、第２の実施形態で説明したように、サーバはその隣接サーバをサーバｉにゆだねてもよく、その後サーバｉは要求をその隣接サーバに転送してもよい（すなわち、サーバ２０４はサーバｉ２０２をサーバ２０３に向けさせ、サーバ２０３はサーバｉをサーバ６０２に向けさせる等）ことにも留意されたい。
【００４４】
図７Ａ、図７Ｂ及び図７Ｃは、本発明の第４の実施形態を示し、図８は、この実施形態の例示的な一例を示す。この実施形態によれば、各サーバは、１つではなく２つ以上の隣接サーバを保持する（説明を容易にするために、図７Ａ、図７Ｂ及び図７Ｃ並びに図８は２つの隣接サーバに関する）。この実施形態は、第１の実施形態と同様に進み、サーバｉ２０２は図３Ａと同じステップである図７Ａの方法ステップを実行する。図７Ｂに進み、サーバｋ２０４はステップ３１０においてサーバｉから要求を受け取る。上記のように、サーバｋが過負荷でない場合、サーバｋが自分自身で要求ｑを処理する（ステップ３１２〜３２０）。
【００４５】
しかしながら、サーバｋ２０４は、過負荷である場合、ステップ７０２に進み、その作業負荷をその隣接サーバ（たとえばサーバ２０３及び８０２）の各々と相対的に比較して、いずれかの隣接サーバがサーバｋ自身よりかかっている負荷が軽く、したがって要求ｑを処理するのにより適しているか否かを判断する。本発明のこの実施形態によれば、サーバｋは、この比較のために別々の定数θk1及びθk2を保持してもよい。この場合もまた、各θを、比較される２つのサーバ間の相体的な計算能力に基づいて設定すべきである。いずれの隣接サーバも負荷がより軽くない場合、サーバｋ２０４はそれ自身で要求ｑを処理し、応答をクライアント２１０に返す（ステップ３１４〜３１６）。しかしながら、いずれかの隣接サーバ２０３／８０２の負荷がより軽い場合、サーバｋはステップ７０６に進み、要求ｑを処理のためにより利用されていないサーバに転送する（８１０／８１４に示すように）（この場合もまた、サーバｋ２０４は、要求を隣接サーバ２０３／８０２に転送するのではなく、サーバｉに隣接サーバを通知しサーバｉに要求を転送させてもよい）。そして、サーバｋは、サーバ２０３／８０２からの応答を待ち（８１２／８１６に示す
ように）、最後にクライアントに応答を返す（ステップ７０８、７１０、３１６、３１８及び３２０）。（なお、さらなる代替形態として、サーバｋは、その負荷を同時に両隣接サーバと比較するのではなく、その負荷をまず１つの隣接サーバと比較し、その隣接サーバの負荷の方が低い場合には要求を処理のためにこの隣接サーバに転送してもよい。サーバｋは、第１の隣接サーバがサーバｋより負荷が重い場合にのみ第２の隣接サーバを検査する。）この場合もまた、要求を処理する隣接サーバは第１の実施形態と同様に進み、図３Ｃと同じステップである図７Ｃの方法ステップを実行してもよく、又は第３の実施形態と同様に進んで図７Ｂの方法ステップを実行してもよい。
【００４６】
本発明の上述した実施形態は例示的であるようにのみ意図されている。当業者には、本発明の精神及び範囲から逸脱することなく多数の他の実施形態が考案されてもよい。
【図面の簡単な説明】
【００４７】
【図１】図１は、従来技術による負荷分散要求ルーティング方法の例示的な一例の図である。
【図２】図２は、図３Ａ、図３Ｂ及び図３Ｃに示すような本発明の第１の実施形態の例示的な例を示す図である。
【図３】図３Ａ、図３Ｂ及び図３Ｃは、サーバが単一の隣接サーバを有する場合の、負荷の平衡化を達成するためにサーバ間でクライアント要求／タスクを分散させる、本発明の第１の例示的な実施形態の方法ステップを示す。
【図４】図４は、要求到着率が変化する際の全応答時間に関し、従来技術による負荷分散要求ルーティング方法と本発明とを比較する、例示的なシミュレーションのスケーラビリティ結果を示す図である。
【図５】図５は、陳腐化した負荷情報による各方法の影響の受け易さに関し、従来技術による負荷分散要求ルーティング方法と本発明とを比較する例示的なシミュレーションを示す図である。
【図６】図６は、サーバ間でクライアント要求／タスクを分散させる本発明のさらなる実施形態の例示的な例を示す図である。
【図７】図７Ａ、図７Ｂ及び図７Ｃは、サーバが２つ以上の隣接サーバを有する場合の、負荷の平衡化を達成するためにサーバ間でクライアント要求／タスクを分散させる、本発明のまたさらなる例示的な実施形態の方法ステップを示す図である。
【図８】図８は、図７Ａ、図７Ｂ及び図７Ｃに示すような本発明の例示的な一例を示す図である。
【技術分野】
【０００１】
［発明の分野］
本発明は、包括的には負荷分散に関する。詳細には、本発明は、要求を処理のために複数のサーバの間で平衡化する要求ルーティング方法に関する。
【背景技術】
【０００２】
［発明の背景］
クライアント・サーバアプリケーションは、次第に複数のサーバにわたって配備されるようになってきている。これらのサーバは、異なる地理的場所にあってもなくてもよく、合せて特定のアプリケーションに対するバックエンド処理能力を提供する。たとえば、サーバは、ウェブページをキャッシュしクライアントウェブブラウザからの要求に応答する、地理的に分散したウェブキャッシュプロキシ等、コンテンツ配信網をサポートすることができる。サーバはまた、インターネットに配備されるグリッド（ＧＲＩＤ）機能の汎用コンピューティングマシン（ＰＣ、ワークステーション、…）であってもよく、そこでは、各サーバは、グリッドクライアントユーザによって提出されるタスクを受け取り処理する。サーバはまた、共有ディスク並列データベースサーバ若しくは共有メモリ並列データベースサーバ又はレプリケーションデータベースサーバ等のデータベースサーバであってもよい。同様に、複数のコンピューティングマシンにわたってピア・ツー・ピアアプリケーションも配備されており、ピア群からの任意のピアが別のピア／サーバントからの要求を処理する。（なお、説明を容易にするために、クライアント・サーバの用語及び例を使用して本発明を説明することに留意されたい。しかしながら、本発明は、ピア・ツー・ピアアーキテクチャを含む他のアーキテクチャ／アプリケーションにも適用可能であることが理解されるべきである。）
【０００３】
説明の目的で、特定のアプリケーションのための要求／タスクを処理することを目的とするｍ個のサーバ（０、１、…、ｍ−１と番号を付す）と、これらのサーバに対して要求／タスクを送信することができる任意の数のクライアントとがあると想定する。従来、これらのマルチサーバ環境では、ｍ個のサーバのうち、クライアントの要求を最初に受け取ったサーバが、この要求の処理を行い、結果をクライアントに返す。しかしながら、これらの複数サーバ環境では、クライアント要求をサービスするために次第に要求ルーティングを使用するようになってきている。要求ルーティングでは、実際にクライアント要求を受け取るサーバは、何らかの方式を使用してｍ個のサーバのうちの別のサーバを確定し、その後、要求を処理のためにこの確定したサーバに転送する。たとえば、図１は、サーバ１０２〜１０５と、処理のためにこれらのサーバに要求／タスクを送信するクライアント１１０〜１１５とを含む一例としてのネットワーク１００を示す。クライアント１１２がサーバ１０３に要求１２０を送信すると想定する（サーバ１０３の選択は、無作為であっても所定の選択であってもよい）。サーバ１０３は、この要求を受け取ると、要求ルーティング方式を実行して、サーバ１０５等、この要求を実際にサービスする別のサーバを確定する。そして、サーバ１０３は、要求１２０をクライアント１１２からこのサーバ１０５に転送する。そして、サーバ１０５は、この要求を処理し、結果１２１をサーバ１０３に返し、そして、サーバ１０３は結果をクライアント１１２に転送する。
【０００４】
管理者は、これらのマルチサーバ環境において、様々なことを目的として要求ルーティング方式を使用する。これらの目的は、たとえば、クライアントが求めているコンテンツ情報を有する可能性がより高いサーバに要求をルーティングするため、クライアントへの近接性に基づいてサーバ／ネットワークに要求をルーティングするため、帯域幅の可用性に基づいて要求をルーティングするため、及びサーバ間で負荷を平衡化するために要求を
ルーティングするためなどである。最後の用途、すなわち負荷分散は、ここでは特に重要である。より具体的には、任意の数のクライアントをサポートするｍ個のサーバから成るマルチサーバ環境の場合、優れた性能スケーラビリティを達成することを目的として、サーバ間でクライアント要求を分散させるために要求ルーティングの使用することが増えている。負荷分散要求ルーティング方式によれば、クライアント要求到着率が増減するのに合わせて、ｍ個のサーバの各々における負荷も一様に増減することが保証される。それにより全体的に応答時間（たとえば、ウェブページダウンロード時間、タスク完了時間）が短くなり、スループットが高くなり、且つクライアント要求に対する可用性が高くなることが確実になる。それにも拘わらず、クライアント要求率及び／又はサーバの数が増大する際にスケーラブルであり、且つ分散サーバ間での平衡化した負荷を達成する負荷分散要求ルーティング方式は、システム全体の動的性質のため、且つ予測不可能なタスク到着パターン及びタスクサイズのため、得ることが困難である。
【０００５】
従来、負荷分散には、以下を含むいくつかの要求ルーティング方式／方法が使用されてきた。すなわち、（１）「最低負荷」、（２）「２つのランダム選択」、（３）「ランダム」及び（４）「ラウンドロビン」である。「最低負荷」要求ルーティング方法は、クライアント要求が受け取られた時の全サーバの負荷を知っているサーバに依存する。特に、この方法は、通常、非集中化式か又は集中化式で実装される。非集中化の実装では、ｍ個のサーバのいずれもが最初にクライアント要求を受け取ることができる。サーバは、要求を受け取ると、ｍ個のサーバ群の中で、その時点で負荷が最低であるサーバを確定し、その後、そのサーバに対し処理のために要求をルーティング／転送する。集中化の実装では、ディスパッチャが使用される。このディスパッチャが、まず、任意のクライアント要求を受け取り、その要求をその時点で負荷が最低であるサーバに転送する。
【０００６】
実装に拘わらず、「最低負荷」方法においては、ディスパッチャ／初期（initial）サーバが、要求を受け取って転送する時点での他の全サーバの負荷を知っていれば、サーバ間で負荷を最適に分散することができる。これらの条件下であれば、最低負荷方法は、サーバ間で負荷を平衡化することができ、且つスケーラブルであって、クライアント要求率が増大するに従い、クライアント要求に対する全応答時間は緩やかに増大する。しかしながら、これらの理想的な条件が満足されず、サーバにおける現負荷情報が正確ではない（すなわち、陳腐化する）場合、負荷分散はあまり正確でなくなり、クライアント要求に対する平均応答時間は急激に増大することになる。
【０００７】
「最低負荷」方法においてサーバ間で負荷情報を広める一方法は、ポーリング方法を用いる方法である。ここでは、ディスパッチャ又は各サーバは、他のサーバに現在の負荷を定期的にポーリングする。ディスパッチャ／サーバが他のサーバの現負荷に関して最新状態を保持できるように、ポーリング率は非常に高く設定されることが理想的である。しかしながら、ポーリングには、ディスパッチャ／サーバ毎におよそＯ（ｍ）のメッセージオーバヘッドが必要である。同様に、ネットワークが拡大し、サーバの数ｍが増大するに従い、ディスパッチャ／サーバにおけるポーリング負荷もまた増大する。このため、オーバヘッドを増大させるが負荷情報を最新に維持する高い／適当なポーリング率と、オーバヘッドを低減するが陳腐化した負荷情報をもたらす低ポーリング率との間にトレードオフがある。
【０００８】
ピギーバック方法は、メッセージオーバヘッドが大きいポーリング方法に対する代替方法である。通常は、サーバが別のサーバに処理をしてもらうために要求を転送する場合、処理サーバは、転送サーバに対して応答を返すことになる。ピギーバック方法では、処理サーバは、この応答を返す時に転送サーバに対してその現負荷も送信する。転送サーバは、後続するクライアント要求を処理する時にこの負荷情報を利用する。その結果、この方法では、ポーリング方法のオーバヘッド問題が起こらない。しかしながら、上記と同様に
、各サーバにおいて負荷情報が最新でない場合、サーバは、負荷が最低ではないサーバにクライアント要求を転送する可能性があり、それによりクライアント要求に対する平均応答時間が増大することになる。
【０００９】
より詳細には、ピギーバック方法での負荷情報の配布は、要求率に直接連動する。要求率が増大すると、各サーバは初期クライアントの要求をより頻繁に受け取ることになる。そして、各サーバが要求をより頻繁に転送し、それにより負荷情報をより頻繁に受け取ることになる。このため、要求率が低すぎる場合、負荷情報が最新の状態に維持されないことになる。この問題に幾分か関連して、ネットワークが拡大しサーバの数ｍが増大するに従い、要求がより広く分散／分配されるため、各サーバが他のすべてのサーバにおいて最新であり続けることはより困難となる。特に、ディスパッチャ方法は、これらの問題のいくつかを克服する可能性があるが、ディスパッチャがシステムに対するボトルネック及び単一障害点（single point of failure）となる。
【００１０】
「最低負荷」方法では、負荷情報の陳腐化に直接関連する「フラッシュクラウド（flashing crowd）」問題もある。一般に、あるサーバが他のサーバより比較的負荷が低いと想定する。このサーバに関する負荷情報が他のすべてのサーバに対して十分頻繁に広められていない場合、他のサーバは、常にこのサーバの負荷が低いと判断し、要求をこのサーバにすべて転送することになり、このサーバが突然過負荷になってしまう。そして、問題は連鎖する。残りのサーバは、この時、次に負荷が低いサーバを検知し、要求を再びそのサーバに転送し、このサーバが過負荷になる。このシナリオは、サーバの各々において順に続き、最後には負荷を平衡化するという当初の意図が覆される。
【００１１】
「２つのランダム選択」方法について述べると、ここではサーバは、最初にクライアントから要求を受け取る度に、すべてのサーバの中から一様にランダムに他の２つのサーバを選択する。そして、最初のサーバは、２つのランダムに選択したサーバの負荷を比較し、負荷の低い方のサーバに処理をさせるために要求を転送する。たとえば、図１において、クライアント１１０がサーバ１０３に要求を送信すると想定する。サーバ１０３は、この要求を受け取ると、サーバ１０２及びサーバ１０４等の他の２つのサーバをランダムに決定する。そして、サーバ１０３は、サーバ１０２の現負荷とサーバ１０４の現負荷とを比較し、負荷の低い方のサーバに要求を転送する。そして、要求を転送されたサーバは、結果をサーバ１０３に返し、サーバ１０３は結果をクライアント１１０に転送する。
【００１２】
「最低負荷」方法と同様に、「２つのランダム選択」方法では、理想的には、各サーバが、要求が転送されている時点で他のすべてのサーバの負荷を知っていることが必要である（２つのランダムに選択されるサーバがどのサーバでもあり得るため）。これらの理想的な条件が満たされると想定すると、「２つのランダム選択」方法は、「最低負荷」方法と略同様に適切に機能し且つスケールし、クライアント要求率が増大するに従い、クライアント要求に対する全応答時間が緩やかに増大する。しかしながら、上記のように、「２つのランダム選択」方法は、実際にはピギーバック方法又はポーリング方法を使用し、サーバ毎におよそＯ（ｍ）のメッセージオーバヘッドが必要である。したがって、２つの「ランダム選択」方法には、上述した「最低負荷」方法と同じ問題がある。すなわち、負荷情報がサーバ間で充分頻繁に広められない場合、各サーバにおける情報が陳腐化し、その結果、クライアント要求に対する平均応答時間が急激に増大する。したがって、この方法でもまた、フラッシュクラウド問題が起こる可能性がある。
【００１３】
「ランダム要求」ルーティング方法に関して述べると、サーバは、クライアントから最初に要求を受け取る度に、すべてのサーバの中から一様に無作為に選択された別のサーバにその要求を転送する。負荷情報がまったく使用されないため、この方法は、「最低負荷」方法及び「２つのランダム選択」方法で負荷情報を順に回す際に発生する欠点のすべて
を回避する。メッセージオーバヘッドがなく、したがって陳腐化問題もない。したがって、この方法では、「フラッシュクラウド」問題がなく、サーバの数ｍが増大する際に悪影響を受けず、クライアント要求に対する応答時間は一定のままである。
【００１４】
しかしながら、ランダム要求方法は適切にスケールせず、ｍ個のサーバ間で負荷を均等に拡散させないということが証明され且つ経験的に示されている。より詳細には、クライアント要求率が増大するに従い、サーバによっては他のサーバより負荷が重くなり、他のサーバより早く最大負荷容量に達する。その結果、過負荷サーバが利用不可能となるか又は要求の処理に遅延が生じるようになるに従って、ｍ個のサーバ間のクライアント要求に対する全応答時間が増大する。したがって、「最低負荷」方法及び「２つのランダム選択」方法での負荷情報が正確に保たれると想定すると、これらの２つの方法は「ランダム」方法よりかなり適切に機能する。
【００１５】
「ラウンドロビン」要求ルーティング方法について述べると、サーバは、最初にクライアントから受け取る各要求について、その要求を他のサーバに処理させるためにラウンドロビン式で連続的に転送する（すなわち、最初のサーバは、要求ａをサーバｉに転送し、要求ｂをサーバｉ＋１に転送し、要求ｃをサーバｉ＋２に転送する、等である）。このメカニズムにより、サーバを選択するための乱数発生器の使用が回避され、この場合もまた、サーバ間で負荷情報を渡さなければならないマイナス面が回避される。しかしながら、概して、この方法にはスケーラビリティに関し「ランダム」方法と同じ問題があることが一般に知られている。クライアント要求率が増大するに従い、サーバによっては他のサーバより負荷が重くなり、クライアント要求に対する応答時間が急速に増大する。さらに、この方法の下でサーバが同期化されてしまい、各サーバが要求を続けて同じサーバに転送する可能性があり、それにより「フラッシュクラウド」シナリオがもたらされる。
【００１６】
示したように、「最低負荷」方法及び「２つのランダム選択」方法は、負荷情報がそれほど陳腐化しないと想定すると、「ランダム」方法及び「ラウンドロビン」方法よりかなり適切に機能する。負荷情報を交換する要求ルーティング方法であって、負荷情報が陳腐化する場合であっても負荷を適切に平衡化することが示されている他の要求ルーティング方法がさらに存在する。しかしながら、これらの他の方法でも、「最低負荷」方法及び「２つのランダム選択」方法のように、ポーリングが使用される場合に相当量の負荷メッセージオーバヘッドが必要である。より重要なことには、これらの他の方法は、すべてのサーバが全体のクライアント要求到達率を事前に知っていると想定しているが、それは通常現実的ではない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
全般的に、要求ルーティング負荷分散の従来の方法にはいくつかの欠点がある。「最低負荷」方法及び「２つのランダム選択」方法は、適切に機能し且つ要求率が増大してもスケールする。しかしながら、これらの方法は、他のすべてのサーバの負荷を知っていること、及びこの情報が正確であり続けることに依存する。ポーリング方法によればこの精度を提供することができるが、メッセージオーバヘッドが大きくなってしまう。ピギーバック方法は、メッセージオーバヘッド問題を克服するが、要求率が高くない限りすべてのサーバを正確に維持しない。これらの方法には、フラッシュクラウド問題もある。他の方法は、負荷情報の陳腐化による影響が少なく、これらの２つの方法と同程度に適切に機能するが、すべてのサーバが要求到着率を知っていることに依存し、それは実際的ではない。「ランダム」方法及び「ラウンドロビン」方法では、負荷情報を交換する必要がなく、それにより関連する問題が回避されるが、これらの方法は適切にスケールせず、要求到着率が増大するに従って性能が急速に劣化する。
【課題を解決するための手段】
【００１８】
［本発明の概要］
したがって、従来技術のこれらの不都合及び他の不都合を克服し、適切に機能し且つ要求率が増大する際に適切にスケールし、サーバ間の負荷情報を維持するためのオーバヘッドが大きくならない、負荷分散要求ルーティング方法を提供することが望ましい。本発明によれば、ｍ個のサーバ群の中の１つのサーバが最初にクライアントから処理要求を受け取ると、そのサーバはｍ個のサーバ群から別のサーバを無作為に選択し、このサーバに処理させるために要求を転送する。この無作為に選択されたサーバを、ファーストチャンスサーバ（first-chance server）と呼ぶ。
【００１９】
ファーストチャンスサーバは、転送された要求を受け取ると、自身の現負荷を過負荷定数と比較して、現在過負荷であるか否かを判断する。過負荷でない場合、ファーストチャンスサーバは、要求を処理し、応答をクライアントに直接又は転送サーバを介して転送し戻す。しかしながら、ファーストチャンスサーバは、過負荷である場合には、自身の現負荷を所定の隣接サーバの負荷と比較する。ファーストチャンスサーバは、その隣接サーバより低い負荷がかかっているか又は比較的等しい負荷がかかっている場合には、要求を処理する。そして、応答をクライアントに転送し戻す。
【００２０】
しかしながら、ファーストチャンスサーバに隣接サーバより重い負荷がかかっている場合には、要求を隣接サーバに転送する。より詳細には、ファーストチャンスサーバは、この要求を直接転送するか、又は別の方法として最初の転送サーバに隣接サーバについて通知する。この後者の場合、転送サーバは、処理のために要求を隣接サーバに送信する。
【００２１】
本発明の一実施の形態によれば、隣接サーバが要求をいかに受け取るかに拘わらず、隣接サーバは要求を処理し、応答をクライアントに直接、又はファーストチャンスサーバ／転送サーバを介して転送する。また、本発明のさらなる実施形態によれば、隣接サーバは要求を自動的には処理はせずに、ファーストチャンスサーバと同様に続行し、過負荷でないと判断した場合に要求を処理する。過負荷である場合、隣接サーバは自身の負荷を自身に隣接するサーバの負荷と比較し、この第２の隣接サーバより負荷が低い場合には要求を自身で処理し、逆にこの第２の隣接サーバより負荷が重い場合には、要求をこの第２の隣接サーバに転送する。転送される場合、プロセスは同様に続く。
【００２２】
本発明のまたさらなる実施形態によれば、ファーストチャンスサーバは、上述したように１つの隣接サーバのみではなく、２つ以上の隣接サーバを保持する。この場合もまた、ファーストチャンスサーバが過負荷でない場合には、要求を自身で処理する。しかしながら、過負荷である場合には、ファーストチャンスサーバは自身の負荷をその隣接サーバの負荷と比較する。これらの隣接サーバのうちの１つがファーストチャンスサーバより低負荷の場合、ファーストチャンスサーバは要求を処理のためにこの隣接サーバに転送する。そうでない場合、ファーストチャンスサーバは自身で要求を処理する。
【発明の効果】
【００２３】
全体として、本発明はスケーラブルであり、要求率が増大する際、従来技術による方法と比較して優れていなくても同等な性能を得る。さらに、本発明によるサーバは、より正確な負荷情報を維持し、その結果、大幅に優れた性能を達成する。
【発明を実施するための最良の形態】
【００２４】
本発明は、ｍ（０〜ｍ−１）個の複数のサーバ間での負荷の平衡化を目的として、これら複数のサーバのうちの任意のサーバにクライアント要求／タスクを分散させる、簡単かつスケーラブルな要求ルーティング方法である。要求／タスクを処理のためにｍ個のサーバに送信することができるクライアントの数は任意である。さらに、要求に対応する初期
サーバをクライアントがどのように選択するかは種々の方法を採用できる。クライアントは、要求のすべてに対して常に同じサーバを選択しても良いし、各要求に対してサーバを無作為に選択しても良い。（なお、本発明を、クライアント・サーバの用語及び例を使用して説明するが、本発明は、ピア・ツー・ピアアーキテクチャを含む他のアーキテクチャ／アプリケーションに適用可能である、ということが理解されるべきである。）
【００２５】
本発明によれば、各サーバｉ（ｉ＝０〜ｍ−１）は、サーバの現在の作業負荷を表す指標ｗiを保持する。たとえば、ｗiは、サーバｉにおける未解決の要求（すなわち、完了していない要求）の数を示してもよい。現負荷に関し、各サーバはまた、２つの閾値Ｗi及びθiも保持する。Ｗiは、各サーバに固有であっても、いくつかのサーバ又はすべてのサーバにわたって同じであってもよい。Ｗiは、サーバｉが過負荷になり、可能であれば要求を別のサーバにゆだねるべきである点を表す閾値である。θiもまた、各サーバに固有であっても、いくつかのサーバ又はすべてのサーバにわたって同じであってもよい。θiは、隣接サーバがサーバｉより低負荷であり、したがってサーバｉに代わって追加の要求を処理することができる点を示す、サーバｉと隣接サーバとの間の比較閾値である。概して、θiは、サーバｉと隣接サーバとの間の相対的な計算能力に基づいて設定されるべきである。
【００２６】
各サーバはまた、ハッシュ関数Ｈａｓｈ：Ｑi−＞｛０，１，…，ｍ−１｝も保持する（ただしＱiはクライアント要求すべての空間であり、各要求をゼロ（０）とｍ−１との間の乱数に等しい確率でマッピングする）。Ｑi等のハッシュ関数は容易に利用可能であり、本発明に特有なものではない。たとえば、ウェブページ要求ｑ（ただしｑはＵＲＬである）の場合、Ｑi＝「ＵＲＬにおけるすべての文字の和 ｍｏｄ ｍ」である。最後に、各サーバはまた、独自の隣接サーバを有するように隣接サーバの概念も保持する。たとえば、ｍ個のサーバを論理的にリング状に順番に並べることができ、その場合、サーバｉの「隣接サーバ」を、「隣接サーバ＝サーバ（ｉ＋１） ｍｏｄ ｍ」として定義することができる。隣接サーバを保持することに加えて、各サーバｉはまた、後述するように、この隣接サーバの現負荷ｗnext-neighborを測定することも可能である。
【００２７】
サーバ間でクライアント要求を要求ルーティングする本発明の第１の実施形態は、図３Ａ、図３Ｂ及び図３Ｃの方法ステップ及び図２の例示的な例によって示すように、３つのモジュールを含む。説明の目的で、本発明の要求ルーティング方法の一部であるｍ個のサーバのすべてが、３つのモジュールの各々を実行すると想定する。サーバがあるモジュールを実行するか否か及びいつ実行するかは、後述するように、それが要求ｑをいかに受け取るかによって決まる。しかしながら、各サーバがすべてのモジュールを実行する必要はない、ということが理解されるべきである。たとえば、サーバは、最初にクライアント要求を受け取ったときに、図３Ａの方法を実行する。あるサーバが最初のクライアント要求を決して受け取らない場合は、図３Ａの方法を実行する必要はない。さらに、図３Ａ、図３Ｂ及び図３Ｃの方法があるサーバにおいて１つのプロセスとして実行されるか、又はいくつかのプロセスとして実行されるは、本発明では限定されない。
【００２８】
本発明の第１の実施形態の個々のステップについて述べると、クライアント２１０等のクライアントが、最初のサービス要求ｑをサーバ２０２等の任意のサーバｉに対して行うと、サーバｉ２０２は図３Ａの方法を実行する。具体的には、ステップ３０２において、サーバｉ２０２はまず、クライアント２１０から要求ｑを受け取る（２２０に示すように）。サーバｉ２０２は、要求を受け取ると、ステップ３０４に進み、ｍ個のサーバからサーバ２０４等のサーバｋを無作為に決定するために要求ｑに基づいてハッシュ関数Ｑiを実行する（すなわち、ｋ＝０〜ｍ−１の場合、ｋ＝Ｑi（ｑ））。ここで、サーバ２０４を、要求ｑの「ファーストチャンス」サーバと呼ぶ。サーバｋ２０４が決定すると、サーバｉ２０２はステップ３０６に進み、要求ｑを処理のためにサーバｋ２０４に転送する（
２２２に示すように）。そして、サーバｉ２０２はステップ３０８に進み、サーバｋからの応答を待つ。なお、説明の目的で、サーバｋ及びサーバｉを異なるサーバとして示すことに留意されたい。しかしながら、サーバｉは、ランダムサーバｋを選択する時、ｍ個のサーバからの自分自身を選択する場合もある（すなわち、ｋはｉに等しい場合もある）。
【００２９】
サーバｋ２０４は、サーバｉからサービス要求ｑ２２２を受け取ると、図３Ｂの方法を実行する。大まかにいうと、サーバｋは、自身の現負荷をその隣接サーバの負荷と比較し、この比較に基づいて、要求ｑを直接サービスすべきか、要求をその隣接サーバにゆだねるべきであるかを判断する。より具体的には、ステップ３１０で開始して、サーバｋ２０４は、サーバｉ２０２から要求ｑを受け取る。そして、サーバｋはステップ３１２に進み、自分自身の現負荷ｗkを閾値Ｗkと比較する。ｗkがＷk以下である場合（すなわち、ｗk≦Ｗkである場合）、サーバｋは過負荷ではない。この場合、サーバｋはステップ３１４に進み、要求ｑを処理する。そして、サーバｋは、ステップ３１６において要求ｑに対する応答をサーバｉ２０２に返す（２２８に示すように）。サーバｉは、ステップ３１８においてサーバｋからこの応答を受け取り、ステップ３２０においてこの応答をクライアント２１０に返す（２３０に示すように）。なお、ステップ２０２において、サーバｋが要求ｑに対する応答をクライアント２１０に直接返すことは妨げられるものではなく、本発明はいずれの代替形態にも等しく適用可能である、ということに留意されたい。
【００３０】
しかしながら、ステップ３１２において、サーバｋ２０４が過負荷である（すなわちｗk＞Ｗkである）と判断した場合、次に、要求ｑを処理のためにその隣接サーバ（ここでは、たとえばサーバ２０３）に転送すべきか否かを判断する。具体的には、ステップ３２２において、サーバｋは、その現負荷ｗkをその隣接サーバ２０３の現負荷ｗnext-neighborと比較し、２つの負荷が閾値θk内にあるか（すなわちｗk−ｗnext-neighbor≦θk）否かを判断する。なお、サーバｋ２０４がその隣接サーバの現負荷ｗnext-neighborを確定するタイミングは本発明では限定されないことに留意されたい。たとえば、サーバｋは、ステップ３２２の一部として隣接サーバの現負荷を要求してもよい。サーバｋが要求ｑを処理のために隣接サーバに転送する場合、隣接サーバは、サーバｋに返信する応答とともにその現負荷をピギーバックすることができる。そして、サーバｋは、ファーストチャンスサーバとして受け取る後続するクライアント要求に対してこの負荷を使用する。同様に、サーバｋは、バックグラウンドポーリングプロセスの一部として負荷を定期的に要求してもよい。あるいは、隣接サーバ２０３は、その負荷をサーバｋに定期的に送信してもよい。
【００３１】
ステップ３２２においてサーバｋが２つの負荷が閾値θk内にあると判断する場合、サーバｋはその隣接サーバより低い負荷がかかっているか、又は２つのサーバは比較的等しい負荷がかかっている。この場合、サーバｋはステップ３１４に進み、自分自身で要求ｑを処理する。ステップ３１６において、サーバｋ２０４は、要求ｑに対する応答をサーバｉ２０２に返す（２２８に示すように）。サーバｉは、ステップ３１８において、サーバｋからこの応答を受け取り、ステップ３２０において応答をクライアント２１０に返す（２３０に示すように）。（この場合もまた、サーバｋは、別の方法として、要求ｑに対する応答を直接クライアント２１０に送信することができる。）
【００３２】
しかしながら、サーバｋ２０４が、ステップ３２２において、２つの負荷が閾値θk内になく、隣接サーバ２０３にサーバｋ２０４自体より軽い負荷がかかっていると判断した場合、隣接サーバ２０３が要求ｑを処理することに適している。この場合、隣接サーバを、要求ｑの「セカンドチャンスサーバ（second-chance server）」と呼ぶ。したがって、サーバｋ２０４はステップ３２４に進み、要求ｑを処理のためにその隣接サーバ２０３に転送する（２２４に示すように）。そして、サーバｋ２０４はステップ３２６に進み、その隣接サーバ２０３からの応答を待つ。
【００３３】
隣接サーバ２０３は、サーバｋ２０４から要求ｑを受け取ると、「セカンドチャンスサーバ」となり、したがって図３Ｃの方法を実行する。より具体的には、ステップ３３０で開始して、サーバ２０３はサーバｋ２０４から要求ｑを受け取る。そして、サーバ２０３はステップ３３２に進み、要求ｑを処理した後、ステップ３３４に進み、要求ｑに対する応答をサーバｋ２０４に返す（２２６に示すように）。ステップ３２８において、サーバｋは、サーバ２０３からこの応答を受け取り、ステップ３１６において応答をサーバｉ２０２に返す（２２８に示すように）。そして、サーバｉ２０２はステップ３２０においてクライアント２１０に対する応答を返す（２３０に示すように）。（この場合もまた、隣接サーバ２０３は、別の方法として、要求ｑに対する応答をクライアント２１０に直接送信することができる。同様に、サーバｋは、サーバ２０３から応答を受け取ると、サーバｉをバイパスして応答を直接クライアント２１０に送信することができる。）
【００３４】
本発明の第２の実施形態によれば、サーバｋ２０４は、その隣接サーバ２０３が要求ｑを処理すべきであると判断した場合（すなわちステップ３２２）、ステップ３２４において処理のために隣接サーバ２０３に要求ｑを転送するのではなく、サーバｉ２０２に、隣接サーバ２０３がこの要求を処理すべきであることを通知する（すなわち、ステップ３２４〜３２６〜３２８〜３１６がバイパスされる）。したがって、ステップ３２２から、サーバｋ２０４は、隣接サーバ２０３に関する情報を転送することによってサーバｉに迅速に応答する。サーバｉは、この情報を受け取ることに応じて、隣接サーバ２０３に要求ｑを直接転送し、その後サーバ２０３からの応答を待つ。上記と同様に、サーバ２０３は、要求ｑを受け取ると、それを処理し、その後応答をサーバｉ２０２に直接転送し戻し、それによりサーバｉ２０２は応答をクライアント２１０に返す。あるいは、サーバ２０３が応答を直接クライアント２１０に送信してもよい。
【００３５】
全体として、本発明によれば、要求は、サーバｋの負荷が少なくともＷkであり、且つ隣接サーバの負荷より少なくともθk大きい場合にのみ、無作為のファーストチャンスサーバｋからセカンドチャンス／隣接サーバに転送されることに留意されたい。Ｗk及びθkをともにゼロに設定することは、隣接サーバの負荷がサーバｋの負荷より低い場合は、要求ｑが隣接サーバに転送されることを意味する。しかしながら、それとは正反対に、Ｗk又はθkを大きい数に設定すると、本方法は「ランダム負荷」方法に戻り、サーバｋは常に要求を処理して決して隣接サーバを考慮しない。概して、管理者は、個々の環境及びアプリケーションに基づいてＷk及びθkをこれらの２つの両極端の間で変更することができる。たとえば、サーバｋとその隣接サーバとの間で要求を転送することにより、幾分かの余分の通信オーバヘッドがもたらされる（ただし、後述するように、このサーバｋと隣接サーバとの間での要求の転送により、従来技術の純粋な「ランダム」方法と比較して負荷分散が強化される）。したがって、管理者は、負荷分散とこのオーバヘッドとをトレードオフするために、Ｗk及びθkに対して適当な値を採用することができる。異なる観点から、ｍ個のサーバはウェブキャッシュプロキシであると想定する。ここで、管理者は、Ｗk及びθkを、サーバｋをその隣接サーバより優先する値に設定することができ、それには、サーバｋにおけるキャッシュヒット率を増大させるという効果がある。この場合もまた、これは負荷分散を犠牲にする可能性がある。したがって、管理者は、キャッシュヒット率と負荷分散とのバランスをとるような２つのパラメータに対する適当な値を採用することができる。
【００３６】
全体として、本発明はスケーラブルであり、「ランダム」方法及び「ラウンドロビン」方法より優れた性能を提供し、「最低負荷」方法及び「２つのランダム選択」方法より優れていなくても同等な性能を提供する。この利点に加えて、本発明は、使用する方法に関わらず「最低負荷」方法及び「２つのランダム選択」方法と比較してメッセージパッシングのオーバヘッドが最小であり、それにより、本発明の実装の複雑さが軽減し且つ単純と
なる。同様に、本発明は、陳腐化した負荷情報の影響を受けにくくなる。
【００３７】
スケーラビリティに関して、図４は、到着率が増大する際の全応答時間に関して「ランダム」方法、「２つのランダム選択」方法及び本発明を比較する、例示的なシミュレーションを示す。このシミュレーションは、本発明でのすべてのサーバと、「２つのランダム選択」方法によるすべてのサーバとが、他のすべてのサーバの負荷を常に正確に知っているという理想的な条件の下で、且つ本発明でのＷk及びθkがすべてのサーバに対してゼロ（０）に設定されて、行われた。図から分かるように、本発明は、要求率が増大するに従って性能が急速に劣化する「ランダム」方法より十分に適切に機能した（この場合もまた、「ラウンドロビン」方法は「ランダム」方法と同様の性能を有するものと推定される）。重要なことに、本発明は、「２つのランダム選択」方法とまさに同程度によく機能した（この場合もまた、「最低負荷」方法は、「２つのランダム選択」方法と同様の性能を有するものと推定される）。
【００３８】
特に、サーバ毎の定期的なポーリング率を高くすることで、このシミュレーションが実行された理想的な条件を達成することができる。重要なことに、「最低負荷」方法及び「２つのランダム選択」方法でのポーリング方法では、各サーバが他のすべてのサーバの現負荷を知っていることが必要であり、サーバ毎にＯ（ｍ）という相当量の負担が課せられる。この相当量のオーバヘッドとは反対に、本発明では、各サーバが、その隣接サーバの現負荷のみを知っていればよく、サーバ毎の複雑性はＯ（１）である。この場合もまた、ピギーバック方法により、本発明のメッセージパッシングのオーバヘッドは「最低負荷」方法及び「２つのランダム選択」方法と同じになる。しかしながら、この場合でさえ、サーバはそれ自体の負荷及び隣接サーバの負荷のみを保持すればよいため、本発明での複雑性が低くなる。「最低負荷」方法及び「２つのランダム選択」方法では、すべてのサーバがそれ自体の負荷と他のすべてのサーバの負荷とを保持しなければならない。このため、本出願では、従来技術の方法に比較して優れていないまでも同等な性能が得られ、より適切に機能する従来の方法に比較してメッセージオーバヘッド及び／又は複雑性が大幅に低減する。
【００３９】
陳腐化した負荷情報に対する影響の受け易さに関し、図５は、要求／到着率が一定に維持されるがサーバの数が増大する際の全応答時間に関して、「最低負荷」方法、「２つのランダム選択」方法、「ランダム」方法及び本発明を比較する、別の例示的なシミュレーションを示す。ここでは、サーバ間で負荷情報を広めるためにピギーバック方法が使用された。したがって、応答を渡す副次的効用として負荷が渡されるため、すべての方法のメッセージオーバヘッド及び複雑性は同じである。さらに、本発明の場合、Ｗk及びθkはすべてのサーバに対してゼロ（０）に設定された。全体として、シミュレーションは、陳腐化した負荷情報を有するサーバの影響を示す。図示するように、「２つのランダム選択」方法及び「最低負荷」方法は陳腐化した負荷情報の影響を受けやすく、「２つのランダム選択」方法は「ランダム」方法まで劣化し、「最低負荷」方法には本質的にフラッシュクラウド効果がもたらされる。全体として、本発明によるサーバは、より正確な負荷情報を保持し、その結果、大幅に優れた性能を達成する。
【００４０】
いくつかの他の点を強調すべきである。第１に、本方法は無作為にファーストチャンスサーバを選択し、各サーバは固有の隣接サーバを有するため、本発明ではフラッシュクラウド問題がない。第２に、上述したように、他の従来技術による要求ルーティング方法は良い性能を達成するが、各サーバが他のすべてのサーバの負荷を知っており、且つ各サーバが要求到着率を知っている必要がある。この場合もまた、本発明は、これらの方法に比較して簡略化され、各サーバはその隣接するサーバの負荷のみを知っていればよい。
【００４１】
ここで本発明のさらなる実施形態を参照する。例示的な一例を図６に示す本発明の第３
の実施形態によれば、隣接サーバ２０３は、「セカンドチャンスサーバ」として作用しサーバｋ２０４からサービス要求ｑを受け取ると、図３Ｃの方法を実行して要求を処理するのではなく、図３Ｂの方法を実行する（本発明のこの実施形態によれば、図３Ｃの方法は不要である）。より具体的には、要求ｑを受け取ると、隣接サーバ２０３はその現負荷を定数Ｗnext-neighbor203と比較する。サーバ２０３の負荷がＷnext-neighbor203以下である場合、それは過負荷ではなく、サービス要求ｑを処理して、応答を直接又はサーバｋ２０４やサーバｉ２０２を介してクライアント２１０に転送し戻す。
【００４２】
しかしながら、隣接サーバ２０３は、それが過負荷であると判断した場合、次に、その隣接サーバ（たとえばサーバ６０２）にかかっている負荷がより軽いためそのサーバに対して要求ｑを処理のために転送すべきであるか否かを判断する。この場合もまた、この判断は、閾値θnext-neighbor203に対するサーバ２０３及びサーバ６０２の負荷の相対的な比較に基づく。サーバ２０３は、サーバ６０２より低負荷又は２つのサーバが比較的等しい負荷であると判断すると、自分自身で要求ｑを処理し、応答をクライアント２１０に直接又はサーバｋ２０４やサーバｉ２０２を介して転送し戻す。
【００４３】
しかしながら、サーバ２０３は、サーバ６０２の負荷の方が軽く要求ｑを処理するのに適していると判断すると、要求ｑを処理のためにサーバ６０２に転送する（６１０に示すように）。したがって、その後サーバ６０２は、また図３Ｂの方法を実行し、要求を実行して応答をクライアントに返す（６１２に示すように）か、又は要求ｑをその隣接サーバに渡す。したがって、あるサーバが十分に利用されておらず、且つ／又はその隣接サーバより負荷が低くなるまで、要求ｑはサーバ間で連続的に渡される。この場合もまた、このように各サーバが要求ｑをその隣接サーバに渡すのではなく、第２の実施形態で説明したように、サーバはその隣接サーバをサーバｉにゆだねてもよく、その後サーバｉは要求をその隣接サーバに転送してもよい（すなわち、サーバ２０４はサーバｉ２０２をサーバ２０３に向けさせ、サーバ２０３はサーバｉをサーバ６０２に向けさせる等）ことにも留意されたい。
【００４４】
図７Ａ、図７Ｂ及び図７Ｃは、本発明の第４の実施形態を示し、図８は、この実施形態の例示的な一例を示す。この実施形態によれば、各サーバは、１つではなく２つ以上の隣接サーバを保持する（説明を容易にするために、図７Ａ、図７Ｂ及び図７Ｃ並びに図８は２つの隣接サーバに関する）。この実施形態は、第１の実施形態と同様に進み、サーバｉ２０２は図３Ａと同じステップである図７Ａの方法ステップを実行する。図７Ｂに進み、サーバｋ２０４はステップ３１０においてサーバｉから要求を受け取る。上記のように、サーバｋが過負荷でない場合、サーバｋが自分自身で要求ｑを処理する（ステップ３１２〜３２０）。
【００４５】
しかしながら、サーバｋ２０４は、過負荷である場合、ステップ７０２に進み、その作業負荷をその隣接サーバ（たとえばサーバ２０３及び８０２）の各々と相対的に比較して、いずれかの隣接サーバがサーバｋ自身よりかかっている負荷が軽く、したがって要求ｑを処理するのにより適しているか否かを判断する。本発明のこの実施形態によれば、サーバｋは、この比較のために別々の定数θk1及びθk2を保持してもよい。この場合もまた、各θを、比較される２つのサーバ間の相体的な計算能力に基づいて設定すべきである。いずれの隣接サーバも負荷がより軽くない場合、サーバｋ２０４はそれ自身で要求ｑを処理し、応答をクライアント２１０に返す（ステップ３１４〜３１６）。しかしながら、いずれかの隣接サーバ２０３／８０２の負荷がより軽い場合、サーバｋはステップ７０６に進み、要求ｑを処理のためにより利用されていないサーバに転送する（８１０／８１４に示すように）（この場合もまた、サーバｋ２０４は、要求を隣接サーバ２０３／８０２に転送するのではなく、サーバｉに隣接サーバを通知しサーバｉに要求を転送させてもよい）。そして、サーバｋは、サーバ２０３／８０２からの応答を待ち（８１２／８１６に示す
ように）、最後にクライアントに応答を返す（ステップ７０８、７１０、３１６、３１８及び３２０）。（なお、さらなる代替形態として、サーバｋは、その負荷を同時に両隣接サーバと比較するのではなく、その負荷をまず１つの隣接サーバと比較し、その隣接サーバの負荷の方が低い場合には要求を処理のためにこの隣接サーバに転送してもよい。サーバｋは、第１の隣接サーバがサーバｋより負荷が重い場合にのみ第２の隣接サーバを検査する。）この場合もまた、要求を処理する隣接サーバは第１の実施形態と同様に進み、図３Ｃと同じステップである図７Ｃの方法ステップを実行してもよく、又は第３の実施形態と同様に進んで図７Ｂの方法ステップを実行してもよい。
【００４６】
本発明の上述した実施形態は例示的であるようにのみ意図されている。当業者には、本発明の精神及び範囲から逸脱することなく多数の他の実施形態が考案されてもよい。
【図面の簡単な説明】
【００４７】
【図１】図１は、従来技術による負荷分散要求ルーティング方法の例示的な一例の図である。
【図２】図２は、図３Ａ、図３Ｂ及び図３Ｃに示すような本発明の第１の実施形態の例示的な例を示す図である。
【図３】図３Ａ、図３Ｂ及び図３Ｃは、サーバが単一の隣接サーバを有する場合の、負荷の平衡化を達成するためにサーバ間でクライアント要求／タスクを分散させる、本発明の第１の例示的な実施形態の方法ステップを示す。
【図４】図４は、要求到着率が変化する際の全応答時間に関し、従来技術による負荷分散要求ルーティング方法と本発明とを比較する、例示的なシミュレーションのスケーラビリティ結果を示す図である。
【図５】図５は、陳腐化した負荷情報による各方法の影響の受け易さに関し、従来技術による負荷分散要求ルーティング方法と本発明とを比較する例示的なシミュレーションを示す図である。
【図６】図６は、サーバ間でクライアント要求／タスクを分散させる本発明のさらなる実施形態の例示的な例を示す図である。
【図７】図７Ａ、図７Ｂ及び図７Ｃは、サーバが２つ以上の隣接サーバを有する場合の、負荷の平衡化を達成するためにサーバ間でクライアント要求／タスクを分散させる、本発明のまたさらなる例示的な実施形態の方法ステップを示す図である。
【図８】図８は、図７Ａ、図７Ｂ及び図７Ｃに示すような本発明の例示的な一例を示す図である。
【特許請求の範囲】
【請求項１】
複数のサーバ間で負荷分散されるように要求を処理する方法であって、
前記複数のサーバのうちのいずれかにより無作為に第１のサーバに転送される要求を、前記第１のサーバにおいて受け取るステップと、
過負荷である場合、前記第１のサーバの現負荷を、前記第１のサーバに対してあらかじめ定められている前記複数のサーバのうちの第２のサーバの現負荷と比較するステップと、
前記第１のサーバの負荷が前記第２のサーバの負荷を超える場合、前記要求を処理のために前記第２のサーバに転送するステップと、
を含む。
【請求項２】
前記第１のサーバの負荷が前記第２のサーバの負荷より低いか又はそれと同等である場合、前記要求を処理するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記比較するステップの前に、前記第１のサーバが過負荷であるか否かを判断するために前記第１のサーバの現負荷を過負荷定数と比較するステップをさらに含む、請求項１に記載の方法。
【請求項４】
過負荷でない場合に前記要求を処理するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記第１のサーバは、前記第１のサーバが前記要求を受け取った転送サーバを通して前記第２のサーバに前記要求を転送する、請求項１に記載方法。
【請求項６】
前記受け取るステップの前に、前記第２のサーバからメッセージを受け取るステップをさらに含み、該第２のサーバの現負荷は前記メッセージにピギーバックされる、請求項１に記載の方法。
【請求項７】
前記複数のサーバは、ピア・ツー・ピアネットワーク内のピアである、請求項１に記載方法。
【請求項８】
前記第２のサーバの負荷が前記第１のサーバの負荷を超える場合、前記第１のサーバの現負荷を、前記第１のサーバに対してあらかじめ定められている前記複数のサーバのうちの第３のサーバの現負荷と比較するステップと、
前記第１のサーバの負荷が前記第３のサーバの負荷を超える場合、前記要求を処理のために前記第３のサーバに転送するステップと
をさらに含む、請求項１に記載の方法。
【請求項９】
前記第１のサーバの負荷が前記第２のサーバの負荷及び前記第３のサーバの負荷より低いか又はそれらと同等である場合、前記要求を処理するステップ、
をさらに含む、請求項８に記載方法。
【請求項１０】
複数のサーバ間で負荷分散されるように要求を処理する方法であって、
前記複数のサーバのいずれかにより無作為にファーストチャンス（first-chance）サーバに転送される要求を、前記ファーストチャンスサーバにおいて受け取るステップと、
過負荷でない場合に前記要求を処理するステップと、
過負荷である場合、前記ファーストチャンスサーバの現負荷を、前記ファーストチャンスサーバに対してあらかじめ定められている少なくとも２つの他のサーバの現負荷と比較するステップでと、
前記ファーストチャンスサーバの負荷が前記少なくとも２つの他のサーバのうちのいずれかの負荷を超える場合、前記要求を処理のために前記少なくとも２つの他のサーバのうちの１つに転送するステップと
を含む方法。
【請求項１１】
前記ファーストチャンスサーバは、その現負荷を過負荷定数と比較することにより過負荷であるか否かを判断する、請求項１０に記載の方法。
【請求項１２】
前記ファーストチャンスサーバが過負荷であり、且つ前記ファーストチャンスサーバの負荷が前記少なくとも２つの他のサーバの負荷と同等であるか又はそれより低い場合に、前記要求を処理するステップをさらに含む、請求項１０に記載の方法。
【請求項１３】
前記少なくとも２つの他のサーバからメッセージを受け取るステップをさらに含み、該少なくとも２つの他のサーバの現負荷は前記メッセージにピギーバックされる、請求項１０に記載の方法。
【請求項１４】
複数のサーバ間で負荷分散されるようにクライアント要求を処理する方法であって、
第１のサーバにおいてクライアント要求を受け取るステップと、
前記複数のサーバから第２のサーバを無作為に選択するとともに、前記クライアント要求を前記第１のサーバから該第２のサーバに転送するステップと、
該第２のサーバが過負荷である場合、該第２のサーバの現負荷を、該第２のサーバに対してあらかじめ定められている第１の隣接サーバの現負荷と比較するステップと、
前記第２のサーバの負荷が前記第１の隣接サーバの負荷を超える場合、前記クライアント要求を前記第１の隣接サーバに転送するとともに、該第１の隣接サーバが前記クライアント要求を処理するステップと
を含む方法。
【請求項１５】
前記ファーストチャンスサーバが過負荷でない場合、該ファーストチャンスサーバは前記要求を処理する、請求項１４に記載の方法。
【請求項１６】
前記複数のサーバの各々は事前に確定された固有の隣接サーバを有する、請求項１４に記載の方法。
【請求項１７】
前記第１の隣接サーバによる前記処理するステップは、
該第１の隣接サーバが過負荷である場合、該第１の隣接サーバの現負荷を第２の隣接サーバの現負荷と比較するステップと、
前記第１の隣接サーバの負荷が前記第２の隣接サーバの負荷を超える場合、前記クライアント要求を前記第２の隣接サーバに転送するとともに、該第２の隣接サーバが前記クライアント要求を処理するステップと
をさらに含む請求項１４に記載の方法。
【請求項１８】
前記第２のサーバが過負荷であり、且つ前記第１の隣接サーバの負荷が前記ファーストチャンスサーバの負荷を超える場合、
前記第２のサーバの現負荷を、該第２のサーバに対してあらかじめ定められている第２の隣接サーバの現負荷と比較するステップと、
前記第２のサーバの負荷が前記第２の隣接サーバの負荷を超えている場合、前記クライアント要求を該第２の隣接サーバに転送するとともに、該第２の隣接サーバが前記クライアント要求を処理するステップと
をさらに含む請求項１４に記載の方法。
【請求項１】
複数のサーバ間で負荷分散されるように要求を処理する方法であって、
前記複数のサーバのうちのいずれかにより無作為に第１のサーバに転送される要求を、前記第１のサーバにおいて受け取るステップと、
過負荷である場合、前記第１のサーバの現負荷を、前記第１のサーバに対してあらかじめ定められている前記複数のサーバのうちの第２のサーバの現負荷と比較するステップと、
前記第１のサーバの負荷が前記第２のサーバの負荷を超える場合、前記要求を処理のために前記第２のサーバに転送するステップと、
を含む。
【請求項２】
前記第１のサーバの負荷が前記第２のサーバの負荷より低いか又はそれと同等である場合、前記要求を処理するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記比較するステップの前に、前記第１のサーバが過負荷であるか否かを判断するために前記第１のサーバの現負荷を過負荷定数と比較するステップをさらに含む、請求項１に記載の方法。
【請求項４】
過負荷でない場合に前記要求を処理するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記第１のサーバは、前記第１のサーバが前記要求を受け取った転送サーバを通して前記第２のサーバに前記要求を転送する、請求項１に記載方法。
【請求項６】
前記受け取るステップの前に、前記第２のサーバからメッセージを受け取るステップをさらに含み、該第２のサーバの現負荷は前記メッセージにピギーバックされる、請求項１に記載の方法。
【請求項７】
前記複数のサーバは、ピア・ツー・ピアネットワーク内のピアである、請求項１に記載方法。
【請求項８】
前記第２のサーバの負荷が前記第１のサーバの負荷を超える場合、前記第１のサーバの現負荷を、前記第１のサーバに対してあらかじめ定められている前記複数のサーバのうちの第３のサーバの現負荷と比較するステップと、
前記第１のサーバの負荷が前記第３のサーバの負荷を超える場合、前記要求を処理のために前記第３のサーバに転送するステップと
をさらに含む、請求項１に記載の方法。
【請求項９】
前記第１のサーバの負荷が前記第２のサーバの負荷及び前記第３のサーバの負荷より低いか又はそれらと同等である場合、前記要求を処理するステップ、
をさらに含む、請求項８に記載方法。
【請求項１０】
複数のサーバ間で負荷分散されるように要求を処理する方法であって、
前記複数のサーバのいずれかにより無作為にファーストチャンス（first-chance）サーバに転送される要求を、前記ファーストチャンスサーバにおいて受け取るステップと、
過負荷でない場合に前記要求を処理するステップと、
過負荷である場合、前記ファーストチャンスサーバの現負荷を、前記ファーストチャンスサーバに対してあらかじめ定められている少なくとも２つの他のサーバの現負荷と比較するステップでと、
前記ファーストチャンスサーバの負荷が前記少なくとも２つの他のサーバのうちのいずれかの負荷を超える場合、前記要求を処理のために前記少なくとも２つの他のサーバのうちの１つに転送するステップと
を含む方法。
【請求項１１】
前記ファーストチャンスサーバは、その現負荷を過負荷定数と比較することにより過負荷であるか否かを判断する、請求項１０に記載の方法。
【請求項１２】
前記ファーストチャンスサーバが過負荷であり、且つ前記ファーストチャンスサーバの負荷が前記少なくとも２つの他のサーバの負荷と同等であるか又はそれより低い場合に、前記要求を処理するステップをさらに含む、請求項１０に記載の方法。
【請求項１３】
前記少なくとも２つの他のサーバからメッセージを受け取るステップをさらに含み、該少なくとも２つの他のサーバの現負荷は前記メッセージにピギーバックされる、請求項１０に記載の方法。
【請求項１４】
複数のサーバ間で負荷分散されるようにクライアント要求を処理する方法であって、
第１のサーバにおいてクライアント要求を受け取るステップと、
前記複数のサーバから第２のサーバを無作為に選択するとともに、前記クライアント要求を前記第１のサーバから該第２のサーバに転送するステップと、
該第２のサーバが過負荷である場合、該第２のサーバの現負荷を、該第２のサーバに対してあらかじめ定められている第１の隣接サーバの現負荷と比較するステップと、
前記第２のサーバの負荷が前記第１の隣接サーバの負荷を超える場合、前記クライアント要求を前記第１の隣接サーバに転送するとともに、該第１の隣接サーバが前記クライアント要求を処理するステップと
を含む方法。
【請求項１５】
前記ファーストチャンスサーバが過負荷でない場合、該ファーストチャンスサーバは前記要求を処理する、請求項１４に記載の方法。
【請求項１６】
前記複数のサーバの各々は事前に確定された固有の隣接サーバを有する、請求項１４に記載の方法。
【請求項１７】
前記第１の隣接サーバによる前記処理するステップは、
該第１の隣接サーバが過負荷である場合、該第１の隣接サーバの現負荷を第２の隣接サーバの現負荷と比較するステップと、
前記第１の隣接サーバの負荷が前記第２の隣接サーバの負荷を超える場合、前記クライアント要求を前記第２の隣接サーバに転送するとともに、該第２の隣接サーバが前記クライアント要求を処理するステップと
をさらに含む請求項１４に記載の方法。
【請求項１８】
前記第２のサーバが過負荷であり、且つ前記第１の隣接サーバの負荷が前記ファーストチャンスサーバの負荷を超える場合、
前記第２のサーバの現負荷を、該第２のサーバに対してあらかじめ定められている第２の隣接サーバの現負荷と比較するステップと、
前記第２のサーバの負荷が前記第２の隣接サーバの負荷を超えている場合、前記クライアント要求を該第２の隣接サーバに転送するとともに、該第２の隣接サーバが前記クライアント要求を処理するステップと
をさらに含む請求項１４に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２００８−５０４６００（Ｐ２００８−５０４６００Ａ）
【公表日】平成２０年２月１４日（２００８．２．１４）
【国際特許分類】
【出願番号】特願２００７−５１８０３１（Ｐ２００７−５１８０３１）
【出願日】平成１７年３月２４日（２００５．３．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００９８６４
【国際公開番号】ＷＯ２００６／０１１９２９
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
【公表日】平成２０年２月１４日（２００８．２．１４）
【国際特許分類】
【出願日】平成１７年３月２４日（２００５．３．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００９８６４
【国際公開番号】ＷＯ２００６／０１１９２９
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【Ｆターム（参考）】
[ Back to top ]