(57)【要約】  複数のサーバを用いてクライアントに対してサービスを提供する場合に、より少ない負荷で通信の維持を図ることを課題とする。ロードバランサを有する情報処理システムに、複数のサーバ１のうち、ロードバランサによって通信が割り当てられたサーバ１であるオーナーを特定するサーバ特定部２１と、複数のサーバのうちの１または複数のサーバ１を、通信を識別するためのセッション情報の複製先である複製先サーバとして決定する複製先サーバ決定部２３と、セッション情報を、複製先サーバにおいて複製して保持させる複製部２４と、オーナーを特定可能な情報を、複製先サーバに通知する通知部２５と、を備えた。
2013186837.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバの何れかにクライアントとの通信を割り当てることで該クライアントに対してサービスを提供し、前記通信の割り当て先を決定するロードバランサを有する情報処理システムであって、
前記複数のサーバのうち、前記ロードバランサによって前記通信が割り当てられた第一のサーバを特定するサーバ特定手段と、
前記複数のサーバのうちの１または複数のサーバを、前記通信を識別するための通信識別情報の複製先である第二のサーバとして決定する複製先サーバ決定手段と、
前記通信識別情報を、前記第二のサーバにおいて複製して保持させる複製手段と、
前記第一のサーバを特定可能な情報を、前記第二のサーバに通知する通知手段と、
を備える情報処理システム。
【請求項２】
前記複製先サーバ決定手段は、前記通信識別情報の一部または全部を、入力に対して再現性を有する所定のアルゴリズムに基づいて処理することで、前記第二のサーバを決定する、
請求項１に記載の情報処理システム。
【請求項３】
前記ロードバランサが前記第一のサーバ以外のサーバに通信を割り当てた場合に、前記通信の内容から抽出された前記通信識別情報を前記所定のアルゴリズムに基づいて処理することで前記第二のサーバを索出するサーバ索出手段を更に備える、
請求項２に記載の情報処理システム。
【請求項４】
前記ロードバランサによって前記通信が前記第一のサーバに割り当てられた際に、前記第一のサーバにおいて前記通信識別情報を生成する通信識別情報生成手段を更に備える、
請求項１から３の何れか一項に記載の情報処理システム。
【請求項５】
前記複製先サーバ決定手段は、１の前記第二のサーバが前記第一のサーバと同一であった場合、更に１以上のサーバを前記第二のサーバとして決定する、
請求項１から４の何れか一項に記載の情報処理システム。
【請求項６】
前記サーバは、夫々不揮発性の記憶装置を有し、
前記複製先サーバ決定手段によって、複数のサーバが前記複製先のサーバとして決定された場合、少なくとも１のサーバは、前記通信識別情報を前記不揮発性の記憶装置に記録しない、
請求項１から５の何れか一項に記載の情報処理システム。
【請求項７】
前記複製先サーバ決定手段は、前記第一のサーバが前記通信識別情報の複製先として決定したサーバを、前記第二のサーバとして決定する、
請求項１から６の何れか一項に記載の情報処理システム。
【請求項８】
複数のサーバの何れかにクライアントとの通信を割り当てることで該クライアントに対してサービスを提供し、前記通信の割り当て先を決定するロードバランサを有する情報処理システムが、
前記複数のサーバのうち、前記ロードバランサによって前記通信が割り当てられた第一のサーバを特定するサーバ特定ステップと、
前記複数のサーバのうちの１または複数のサーバを、前記通信を識別するための通信識別情報の複製先である第二のサーバとして決定する複製先サーバ決定ステップと、
前記通信識別情報を、前記第二のサーバにおいて複製して保持させる保持ステップと、
前記第一のサーバを特定可能な情報を、前記第二のサーバに通知する通知ステップと、
を実行する情報処理方法。
【請求項９】
複数のサーバの何れかにクライアントとの通信を割り当てることで該クライアントに対してサービスを提供し、前記通信の割り当て先を決定するロードバランサを有する情報処理システムを、
前記複数のサーバのうち、前記ロードバランサによって前記通信が割り当てられた第一のサーバを特定するサーバ特定手段と、
前記複数のサーバのうちの１または複数のサーバを、前記通信を識別するための通信識別情報の複製先である第二のサーバとして決定する複製先サーバ決定手段と、
前記通信識別情報を、前記第二のサーバにおいて複製して保持させる複製手段と、
前記第一のサーバを特定可能な情報を、前記第二のサーバに通知する通知手段と、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明に係る技術は、ロードバランサを有する情報処理に関する。
【背景技術】
【０００２】
従来、ロードバランサにおける負荷分散処理によって選択されたアプリケーションサーバが、レスポンスパケットにセッションデータを付加してロードバランサへ返送し、ロードバランサが、レスポンスパケットに付加されているセッションデータを記憶し、レスポンスパケットからセッションデータを削除してクライアント端末へ転送するセッションデータ共有方法がある（特許文献１を参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−７９５２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来、クライアントとサーバとの間の通信を識別するために、セッションＩＤ等の通信識別情報が用いられている。また、複数のサーバを用いてクライアントに対してサービスを提供する場合に、通信を維持する目的で、通信識別情報を複数のサーバ間で複製することが行われている。【０００５】
しかし、全てのサーバに対して通信識別情報を複製する方法では通信の量や複製回数等の面から負荷が大きく、一方、一部のサーバに対して通信識別情報を複製する方法では、通信識別情報を保持していないサーバに通信が割り当てられてしまう可能性がある。【０００６】
本発明では、上記した課題に鑑み、複数のサーバを用いてクライアントに対してサービスを提供する場合に、より少ない負荷で通信の維持を図ることを課題とする。
【課題を解決するための手段】
【０００７】
本発明に係る情報処理システムの一側面は、複数のサーバの何れかにクライアントとの通信を割り当てることで該クライアントに対してサービスを提供し、前記通信の割り当て先を決定するロードバランサを有する情報処理システムであって、前記複数のサーバのうち、前記ロードバランサによって前記通信が割り当てられた第一のサーバを特定するサーバ特定手段と、前記複数のサーバのうちの１または複数のサーバを、前記通信を識別するための通信識別情報の複製先である第二のサーバとして決定する複製先サーバ決定手段と、前記通信識別情報を、前記第二のサーバにおいて複製して保持させる複製手段と、前記第一のサーバを特定可能な情報を、前記第二のサーバに通知する通知手段と、を備える情報処理システムである。【０００８】
また、前記複製先サーバ決定手段は、前記通信識別情報の一部または全部を、入力に対して再現性を有する所定のアルゴリズムに基づいて処理することで、前記第二のサーバを決定してもよい。【０００９】
また、本発明に係る情報処理システムは、前記ロードバランサが前記第一のサーバ以外のサーバに通信を割り当てた場合に、前記通信の内容から抽出された前記通信識別情報を前記所定のアルゴリズムに基づいて処理することで前記第二のサーバを索出するサーバ索出手段を更に備えてもよい。【００１０】
また、本発明に係る情報処理システムは、前記ロードバランサによって前記通信が前記第一のサーバに割り当てられた際に、前記第一のサーバにおいて前記通信識別情報を生成する通信識別情報生成手段を更に備えてもよい。【００１１】
また、前記複製先サーバ決定手段は、１の前記第二のサーバが前記第一のサーバと同一であった場合、更に１以上のサーバを前記第二のサーバとして決定してもよい。【００１２】
また、前記サーバは、夫々不揮発性の記憶装置を有し、前記複製先サーバ決定手段によって、複数のサーバが前記複製先のサーバとして決定された場合、少なくとも１のサーバは、前記通信識別情報を前記不揮発性の記憶装置に記録しなくてもよい。【００１３】
また、前記複製先サーバ決定手段は、前記第一のサーバが前記通信識別情報の複製先として決定したサーバを、前記第二のサーバとして決定してもよい。【００１４】
また、本発明は、情報処理装置、１または複数の情報処理装置を有する情報処理システム、コンピュータによって実行される方法、またはコンピュータに実行させるプログラムとしても把握することが可能である。また、本発明は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものでもよい。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることが出来る記録媒体をいう。
【発明の効果】
【００１５】
本発明に係る情報処理によれば、複数のサーバを用いてクライアントに対してサービスを提供する場合に、より少ない負荷で通信の維持を図ることが可能となる。
【図面の簡単な説明】
【００１６】
【図１】実施形態に係るシステムのハードウェア構成の概略を示す図である。
【図２】実施形態に係るシステムの機能構成の概略を示す図である。
【図３】実施形態において用いられるＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇによる複製先サーバの選択手法の概要を示す図である。
【図４】実施形態に係る、セッション情報管理処理の流れを示すフローチャート（１）である。
【図５】実施形態に係る、セッション情報管理処理の流れを示すフローチャート（２）である。
【図６】実施形態に係る、セッション情報管理処理の流れを示すフローチャート（３）である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態について、図面に基づいて説明する。なお、以下に説明する実施の形態は例示であって、本発明を以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の形態毎に具体的構成が適宜採用されてよい。
【００１８】
＜システムの構成＞
図１は、本実施形態に係るシステムのハードウェア構成の概略を示す図である。本実施形態に係るシステムは、インターネット等のネットワークを介して互いに通信可能に接続された、複数のサーバ１およびロードバランサ２を備える。また本実施形態に係るシステムには、ネットワークを介して、クライアント端末９が接続される。なお、サーバ１およびロードバランサ２は、夫々、単一の筐体によって構成されてもよいし、ネットワーク等を介して接続された複数の筐体によって構成されてもよい。
【００１９】
サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２およびＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１３等からなる制御部１０と、不揮発性の補助記憶装置１４と、入力装置１５と、出力装置１６と、ネットワークインターフェース１７と、を備える情報処理装置である。但し、本発明の実施にあたって、本発明に係る情報処理装置は、上記した構成と同一の構成である必要はない。情報処理装置の具体的なハードウェア構成に関しては、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。
【００２０】
ロードバランサ２は、サーバ１と同様、ＣＰＵ、ＲＡＭおよびＲＯＭ等からなる制御部と、補助記憶装置と、入力装置と、出力装置と、ネットワークインターフェースと、を備える情報処理装置である（図示は省略する）。また、クライアント端末９は、サーバ１と同様、ＣＰＵ、ＲＡＭおよびＲＯＭ等からなる制御部と、補助記憶装置と、入力装置と、出力装置と、ネットワークインターフェースと、を備える情報処理装置である（図示は省略する）。
【００２１】
図２は、本実施形態に係るシステムの機能構成の概略を示す図である。本実施形態に係るサーバ１は、ＣＰＵ１１が、ＲＡＭ１２に展開された各種プログラムを解釈および実行して、サーバ１に備えられた各種ハードウェアを制御することで、サーバ特定部２１、通信識別情報生成部（セッション情報生成部）２２、複製先サーバ決定部２３、複製部２４、通知部２５およびサーバ索出部２６、を備える情報処理装置として機能する。また、本実施形態では、これらの機能がいずれも汎用のＣＰＵ１１によって実行される例について説明するが、これらの機能は、その一部または全部が、１または複数の専用のプロセッサによって実現されてもよい。
【００２２】
本実施形態において、複数のサーバ１は、Ｗｅｂサイトを管理し、ＨＴＴＰによるコンテンツ取得要求に応じてＨＴＭＬコンテンツを送信する機能を有するサーバである。サーバ１は、クライアント端末９からの要求に応じて、Ｗｅｂサイト中のコンテンツを配信する。但し、本実施形態では、サーバ１によって提供されるサービスの例としてＷｅｂサービスを挙げて説明しているが、本発明の実施にあたって、サーバ１はＷｅｂサービスを提供するためのサーバに限定されない。本発明は、その他のサービスを提供するためのサーバ群にも適用可能である。
【００２３】
本実施形態において、クライアント端末９からのＷｅｂサイトへの通信は、はじめにロードバランサ２によって受信される。ロードバランサ２は、クライアント端末９からの通信を受信すると、当該通信を複数のサーバ１の何れかに割り当てることで、Ｗｅｂサイトへの負荷を複数のサーバ１に分散する負荷分散装置である。本実施形態において用いられるロードバランサ２は、負荷分散先としてクライアント端末９からの通信を割り当てる先のサーバ１を、何らかの負荷分散アルゴリズムに従って決定する。基本的に、ロードバランサ２は、クライアント端末９とサーバ１との間のセッションを維持するために、同一のクライアント端末９からの通信を同一のサーバ１に割り当てる。但し、サーバ側の事情やロードバランサ側の事情により、同一のクライアント端末９からの通信がそれまでとは異なるサーバ１に割り当てられる可能性がある。ここで、サーバ側の事情としては、例えばサーバ１が落ちている場合等が挙げられる。ロードバランサ側の事情としては、ロードバランサが処理速度を向上させる目的等で割当先サーバを変更した場合や、ロードバランサの性能に問題がある場合等が挙げられる。
【００２４】
ロードバランサ２によってクライアント端末９からの通信を割り当てられたサーバ１は、少なくともクライアント端末９またはユーザを一意に特定可能なセッションＩＤを、クライアント端末９に対して発行する。以降、サーバ１は、セッションＩＤを用いて、クライアント端末９とサーバ１との間での通信を識別し、このセッションＩＤによって識別されるセッション情報を用いて、クライアント端末９とサーバ１との間での通信を管理する。このため、セッションＩＤの発行後は、サーバ１とクライアント端末９との間で送受信されるパケットには、セッションＩＤが含まれる。なお、セッションＩＤは、ユーザ端末やユーザとの通信を識別して、ユーザ端末やユーザ毎にサービスを提供するための識別子であり、本発明の通信識別子に相当する。
【００２５】
クライアント端末９は、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）に指定されたＷｅｂサイトに対してパケットを送信する機能、および、ロードバランサによって当該パケットの割当を受けたサーバ１から返信されたコンテンツを受信する機能を備える。また、クライアント端末９は、Ｗｅｂサーバから受信した、接続先のサーバ１との間の通信を管理するためのセッションＩＤを保持する。
【００２６】
本実施形態では、何れかのサーバ１によって発行されたセッションＩＤを含むセッション情報は、１または複数のサーバ１に対して複製される。ここで、セッション情報の複製先として決定されたサーバ１を、「複製先サーバ」と称する。セッション情報の複製先サーバの決定には、全てのサーバ間で共通するアルゴリズムが使用される。また、この際に用いられるアルゴリズムは、入力（本実施形態では、セッションＩＤ）に応じて選択されるサーバ１に再現性のあるアルゴリズムであればよい。このようなアルゴリズムを用いてサーバ１が複製先サーバとして決定されるため、セッションＩＤを用いて複製先サーバが決定された後、同アルゴリズムを、複製先サーバの索出に用いることが出来る。そして、本実施形態では、このようなアルゴリズムを利用した複製先サーバの選択手法として、Ｃｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇによる複製先サーバの選択手法が用いられる。
【００２７】
図３は、本実施形態において用いられるＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇによる複製先サーバの選択手法の概要を示す図である。Ｃｏｎｓｉｓｔｅｎｔ  Ｈａｓｉｎｇでは、０から所定の数値ｎ（例えば、２＾３２−１）までの連続した整数が円周上の同一方向回り（図では時計回り）に等間隔に定められた円（ｃｏｎｔｉｎｕｕｍ）が用いられる。このため、ｃｏｎｔｉｎｕｕｍ上を同一方向回り（時計回り）に辿っていくと、ｃｏｎｔｉｎｕｕｍ上の数値は、円周上を進むに従って０から１ずつ増加し、ｃｏｎｔｉｎｕｕｍを一周することでｎに到達すると、その次で０に戻る。本実施形態に係るＷｅｂサイトで用いられる複数のサーバ１には、この０からｎまでの整数のうちの何れかが、サーバ識別子として割り当てられている。換言すれば、本システムにおいて用いられるサーバ１は、ｃｏｎｔｉｎｕｕｍ上にマッピングされる。
【００２８】
サーバ１は、全てのサーバ間で共通するハッシュ演算アルゴリズムを用いることで、セッション情報の複製先サーバを決定する際や、セッション情報の複製先サーバを索出する際に、同一のセッションＩＤに対して一意のハッシュ値を得る。ここで、ハッシュ値は、セッションＩＤの一部または全部を入力値とするハッシュ演算を行うことで得られてもよいし、セッションＩＤとして０からｎの範囲内のハッシュ値が用いられているような場合には、セッションＩＤがそのままｃｏｎｔｉｎｕｕｍ上の点を特定するためのハッシュ値として参照されてもよい。
【００２９】
まず、複製先サーバ決定部２３またはサーバ索出部２６は、求められたハッシュ値に対応するｃｏｎｔｉｎｕｕｍ上の点を開始地点として同一方向回り（図では時計回り）に探索を開始し、最初に発見されたサーバ１を、セッション情報の複製先として決定（または取得元として索出）する。複製先サーバを１つとする場合や、ここで索出されたサーバ１からセッション情報が取得出来た場合等には、ここで探索は終了する。しかし、複製先サーバを２つ以上とする場合や、ここで索出されたサーバ１からセッション情報が取得出来なかった場合等には、ｃｏｎｔｉｎｕｕｍの同一方向回り（図では時計回り）に探索が継続され、次に発見されたサーバ１が、更にセッション情報の複製先として決定（または取得元として索出）される。なお、探索中に、ｃｏｎｔｉｎｕｕｍの探索位置の値が限界値ｎ（例えば２＾３２−１）を超えた場合、探索位置はｃｏｎｔｉｎｕｕｍの開始地点（即ち、０）に戻り、探索が継続される。
【００３０】
＜処理の流れ＞
次に、図４から図６を用いて、本実施形態に係る処理の詳細を説明する。なお、本実施形態において説明される処理の具体的な内容および順序等は、実施する上での一例である。具体的な処理内容および順序等は、実施の形態に応じて適宜選択されてよい。
【００３１】
図４から図６は、本実施形態に係る、セッション情報管理処理の流れを示すフローチャートである。本フローチャートに示された処理は、クライアント端末９によって送信されたパケットが、ロードバランサ２に割当られたサーバ１によって受信されたことを契機として開始される。
【００３２】
ステップＳ１０１では、クライアント端末９からの通信が受信される。クライアント端末９によって送信されたパケットは、サーバ１によって受信される前に、ロードバランサ２によって受信される。ロードバランサ２は、クライアント端末９によって送信されたパケットを受信すると、複数のサーバ１の中から、所定の負荷分散アルゴリズムに従ってパケットの割当先となるサーバ１を決定し、決定されたサーバ１に対してパケットを転送する。このようにして、パケットは複数のサーバ１のうちの何れかのサーバ１にたどり着き、ロードバランサ２による通信の割当を受けたサーバ１は、クライアント端末９から送信されたパケットを受信する。以下、パケットを受信したサーバ１を「受信サーバ」と称する。その後、処理はステップＳ１０２へ進む。
【００３３】
ステップＳ１０２では、受信パケットにセッションＩＤが設定されているか否かが判定される。受信サーバは、ステップＳ１０１で受信されたパケットを参照して、当該パケットに、サーバ１とクライアント端末９との間の通信を識別するためのセッションＩＤが含まれているか否かを判定する。パケットにセッションＩＤが含まれている場合、換言すれば、既に何れかのサーバ１からクライアント端末９に対してセッションＩＤが発行済である場合、処理はステップＳ１１０へ進む。一方、セッションＩＤが含まれていない場合、換言すれば、送信元のクライアント端末９に対してセッションＩＤが未発行である場合、処理はステップＳ１０３へ進む。
【００３４】
ステップＳ１０３からステップＳ１０８の処理は、送信元のクライアント端末９に対してセッションＩＤが未発行である場合に、セッションＩＤを発行し、またこのセッションＩＤに係るセッション情報を他のサーバ１に複製するための処理である。
【００３５】
ステップＳ１０３では、オーナーが特定される。受信サーバのサーバ特定部２１は、自身（受信サーバ）を、オーナーとして特定する。本実施形態において、オーナーとは、複数のサーバ１のうち、セッション情報の複製処理においてセッション情報の「オーナー」として扱われるサーバ１であり、本発明の「第一のサーバ」に相当する。本実施形態では、オーナーとして、ロードバランサによって通信が割り当てられたサーバ１であり、セッション情報の生成者である受信サーバが選定されるが、オーナーには、セッション情報を所有するサーバ１が指定されればよく、セッション情報の生成を行うサーバ１や受信サーバに限定されない。その後、処理はステップＳ１０４へ進む。
【００３６】
ステップＳ１０４およびステップＳ１０５では、セッション情報の生成および通知が行われる。受信サーバの通信識別情報生成部２２は、パケットの送信元のクライアント端末９とサーバ１との間の通信を識別するための情報として、セッションＩＤを含むセッション情報を生成する（ステップＳ１０４）。そして、受信サーバは、生成されたセッション情報を、パケットの送信元クライアント端末９に通知する（ステップＳ１０５）。その後、処理はステップＳ１０６へ進む。
【００３７】
ステップＳ１０６では、セッションＩＤに基づいて複製先サーバが決定される。受信サーバの複製先サーバ決定部２３は、上述したＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇを用いて、複製先サーバを決定する。より具体的には、受信サーバは、セッションＩＤの一部または全部を入力値とするハッシュ演算を行い、ハッシュ値を得る。ここで用いられるハッシュ演算は、入力に対して再現性を有する。そして、サーバ１は、求められたハッシュ値に対応するｃｏｎｔｉｎｕｕｍ上の点を開始地点として探索を行い、発見された順に、所定の数のサーバ１を、複製先サーバとして決定する。複製先サーバは、本発明の「第二のサーバ」に相当する。その後、処理はステップＳ１０７へ進む。
【００３８】
なお、ステップＳ１０６では、オーナーと複製先サーバの重複の有無が判定されてもよい。受信サーバは、ステップＳ１０３で決定されたオーナーのサーバ識別子と、ステップＳ１０６で発見された１又は複数の複製先サーバのサーバ識別子と、を比較することで、オーナーと複製先サーバが重複しているか否かを判定する。オーナーと複製先サーバとが重複している（１の複製先サーバがオーナーと同一である）と判定された場合、複製先サーバ決定部２３は、複製先サーバを再選定する。ここで、複製先サーバ決定部２３は、求められたハッシュ値に対応するｃｏｎｔｉｎｕｕｍ上の点を開始地点として探索を行い、発見された順に、オーナーと重複しない所定の数のサーバ１を、複製先サーバとして決定する。即ち、本フローチャートに示された処理では、オーナーと重複しない所定の数の複製先サーバが選定されるまで、複製先サーバの決定処理が繰り返される。所定の数の複製先サーバの決定が完了した場合、処理はステップＳ１０７へ進む。
【００３９】
ステップＳ１０７およびステップＳ１０８では、セッション情報が複製先サーバに複製され、更にオーナーの識別子が複製先サーバに通知される。受信サーバの複製部２４は、ステップＳ１０４で生成されたセッション情報を、ステップＳ１０６において決定された複製先サーバに対して送信することによって、セッション情報を複製先サーバに複製し、複製先サーバに保持させる（ステップＳ１０７）。
【００４０】
なお、複製先サーバが複数決定され、複数の複製先サーバに対してセッション情報が複製される場合、セッション情報を不揮発性の補助記憶装置１４に保持する複製先サーバは、複数の複製先サーバのうちの一部（例えば、１台）であってよい。セッション情報を一部の複製先サーバにおいてのみ不揮発性の補助記憶装置１４に保持させる場合、この一部の複製先サーバを除く他の複製先サーバは、セッション情報をＲＡＭ１２に保持する。このようにすることで、セッション情報の複製のために用いる補助記憶装置１４の領域を節約することが出来る。
【００４１】
そして、オーナーである受信サーバの通知部２５は、ｃｏｎｔｉｎｕｕｍにおいて用いられる自身のサーバ識別子を、オーナーを特定可能な情報として、ステップＳ１０６において決定された複製先サーバに対して通知する（ステップＳ１０８）。オーナーのサーバ識別子が複製先サーバに通知されるため、複製先サーバは、セッション情報のオーナーであるサーバ１（セッション情報を生成したサーバ１）を知ることが出来る。なお、ステップＳ１０７におけるセッション情報の複製と、ステップＳ１０８におけるオーナー識別子の通知とは、別々のパケットによって行われてもよいし、同一のパケットによって行われてもよい。また、ステップＳ１０７とステップＳ１０８との処理順序は逆であってもよい。その後、本フローチャートに示された処理は終了する。
【００４２】
ステップＳ１１０では、受信サーバがセッション情報を保持しているか否かが判定される。受信パケットにセッションＩＤが設定されている場合、受信サーバは、自身が、受信したパケットに設定されているセッションＩＤに対応するセッション情報を保持しているか否かを判定する。ここで、受信サーバがセッション情報を保持していると判定された場合、受信サーバは、このセッション情報を用いてクライアント端末９との間で行われる通信内容を管理する。そして、処理はステップＳ１１７へ進む。一方、受信サーバがセッション情報を保持していない場合、処理はステップＳ１１１へ進む。
【００４３】
ステップＳ１１１からステップＳ１１５の処理は、受信されたパケットにセッションＩＤが設定されている（ステップＳ１０２：ＹＥＳ）が、受信サーバがセッション情報を有していない場合（ステップＳ１１０：ＮＯ）に、他のサーバ１からセッション情報を取得するための処理である。本実施形態に係るシステムによれば、セッションＩＤを有さないサーバ１にロードバランサが通信を割り当ててしまった場合であっても、後述するステップＳ１１１からステップＳ１１５の処理によって、通信の割当を受けたサーバ１が、セッションＩＤから複製先サーバを索出し、セッション情報を取得することが出来る。
【００４４】
ステップＳ１１１では、セッションＩＤに基づいてサーバ１が索出される。受信サーバのサーバ索出部２６は、上述したＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇを用いて、サーバ１を索出する。より具体的には、受信サーバは、セッションＩＤを入力値とするハッシュ演算を行い、ハッシュ値を得る。そして、サーバ１は、求められたハッシュ値に対応するｃｏｎｔｉｎｕｕｍ上の点を開始地点として探索を行い、最初に発見されたサーバ１を索出する。ステップＳ１１１で索出に用いられるアルゴリズムは、ステップＳ１０６において複製先サーバを決定する際に用いたアルゴリズムと同一（本実施形態では、同一のｃｏｎｔｉｎｕｕｍを用いるＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇ）である。このため、ステップＳ１１１では、ステップＳ１０６において決定され、セッション情報の複製がなされた複製先サーバが優先的に索出される。その後、処理はステップＳ１１２へ進む。
【００４５】
ステップＳ１１２では、索出されたサーバ１からのセッション情報の取得が試みられる。受信サーバは、ステップＳ１１１で索出されたサーバ１に対して、受信パケットに設定されていたセッションＩＤに対応するセッション情報を要求する。ここで、要求先のサーバ１がセッション情報を有していた場合、セッション情報の取得は成功する。しかし、要求先のサーバ１が複製先サーバでなかった場合や、要求先のサーバ１に障害が発生している場合等、何らかの事情でセッション情報の取得が出来ない可能性がある。
【００４６】
ステップＳ１１３からステップＳ１１５では、セッション情報が取得できるまで、セッションＩＤに基づくサーバ１の索出とセッション情報の要求が繰り返される。このため、受信サーバは、ステップＳ１１２においてセッション情報を取得できたか否かを判定する（ステップＳ１１３）。セッション情報が取得できたと判定された場合、受信サーバは、取得されたセッション情報を用いてクライアント端末９との間で行われる通信内容を管理する。そして、処理はセッション情報の更新のため、ステップＳ１１７へ進む。
【００４７】
一方、セッション情報が取得できなかったと判定された場合、受信サーバのサーバ索出部２６は、セッションＩＤに基づいて次のサーバ１を索出し（ステップＳ１１５）、索出されたサーバ１に対してセッション情報を要求する（ステップＳ１１２）。ここで索出される「次のサーバ」とは、図３を用いて説明したＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇにおける探索を継続することによって、直前のステップＳ１１２において発見されたサーバ１の次に発見されるサーバ１である。次のサーバ１の索出とセッション情報の要求とは、セッション情報が取得できるまで（ステップＳ１１３：ＹＥＳ）繰り返し実行される。但し、本実施形態では、複製先サーバは、上記ステップＳ１０３からステップＳ１０８で説明した通り所定数（１または複数）選択されているものの、複製先サーバの数には限りがある。このため、探索がｃｏｎｔｉｎｕｕｍを一周し、全てのサーバ１に対して問い合わせ済みとなったがセッション情報の取得が出来なかった場合には（ステップＳ１１４：ＹＥＳ）、セッション情報の取得は失敗し、本フローチャートに示された処理は終了する。
【００４８】
なお、ステップＳ１１３からステップＳ１１５では、索出されたサーバ１が複製先サーバであるか否かに拘らず、セッション情報が取得できるまで、セッションＩＤに基づくサーバ１の索出とセッション情報の要求が繰り返されるが、これは、Ｃｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇ手法を用いたセッション情報複製処理の信頼性を高めるための補助的な処理であり、省略されてもよい。
【００４９】
ステップＳ１１７からステップＳ１２７では、オーナーおよび複製先サーバに保持されているセッション情報の更新が行われる。
【００５０】
ステップＳ１１７では、セッション情報の更新が必要となるか否かが判定される。受信サーバは、クライアント端末９との通信に応じて、当該クライアント端末９と受信サーバとの間で用いられるセッション情報の更新の要否を判定する。セッション情報は、クライアント端末９と受信サーバとの間での通信が進行し、通信において管理すべき内容の変更、追加および削除等があった場合に変更される。セッション情報の更新が不要であると判定された場合、本フローチャートに示された処理は終了する。一方、セッション情報の更新が必要であると判定された場合、処理はステップＳ１１８へ進む。
【００５１】
ステップＳ１１８およびステップＳ１１９では、セッション情報が更新され、更新されたセッション情報がクライアントに通知される。受信サーバは、セッション情報を更新し（ステップＳ１１８）、クライアントへの返信パケットに含めて送信することで、更新されたセッション情報をクライアントに通知する（ステップＳ１１９）。セッション情報の更新および通知は従来のサーバ／クライアント間通信において行われている処理であるため、詳細な説明は省略する。その後、処理はステップＳ１２０へ進む。
【００５２】
ステップＳ１２０からステップＳ１２２では、受信サーバがオーナーである場合に、複製先サーバのセッション情報が更新される。受信サーバは、自身が受信パケットに設定されたセッションＩＤに係るセッション情報のオーナーであるか否かを判定する（ステップＳ１２０）。ここで、受信サーバがセッション情報のオーナーでないと判定された場合、処理はステップＳ１２３へ進む。一方、受信サーバがセッション情報のオーナーであると判定された場合、受信サーバのサーバ索出部２６は、セッションＩＤに基づいて複製先サーバを索出し（ステップＳ１２１）、複製先サーバが保持するセッション情報を更新する（ステップＳ１２２）。オーナーが保持するセッション情報は、ステップＳ１１８において更新済みである。ステップＳ１２１の処理の詳細については、ステップＳ１１１において説明した処理と概略同様であるため、説明を省略する。ステップＳ１２２において、受信サーバは、ステップＳ１１８で更新されたセッション情報を、ステップＳ１２１において索出された複製先サーバに対して送信することによって、複製先サーバによって保持されているセッション情報を更新する（ステップＳ１２２）。受信サーバがオーナーであった場合、ステップＳ１１８からステップＳ１２２に示された処理によって、オーナーおよび複製先サーバによって保持されているセッション情報が更新される。その後、本フローチャートに示された処理は終了する。
【００５３】
ステップＳ１２３およびステップＳ１２４では、受信サーバがオーナーの識別子を保持している場合に、オーナーのセッション情報が更新される。受信サーバは、自身がセッション情報のオーナーでない場合（ステップＳ１２０：ＮＯ）、自身がオーナーの識別子を保持しているか否かを判定する（ステップＳ１２３）。例えば、受信サーバが複製先サーバのうちの１つであった場合、受信サーバは、ステップＳ１０８の処理によって通知されたオーナーのサーバ識別子を保持している。受信サーバがオーナーのサーバ識別子を保持していないと判定された場合、処理はステップＳ１２５へ進む。一方、受信サーバがオーナーのサーバ識別子を保持していると判定された場合、受信サーバは、ステップＳ１１８で更新されたセッション情報を、オーナーのサーバ識別子に示されたサーバ１に対して送信することによって、オーナーによって保持されているセッション情報を更新する（ステップＳ１２４）。その後、処理はステップＳ１２１へ進む。
【００５４】
その後、受信サーバのサーバ索出部２６は、セッションＩＤに基づいて他の複製先サーバを索出し（ステップＳ１２１）、他の複製先サーバが保持するセッション情報を更新する（ステップＳ１２２）。その後、本フローチャートに示された処理は終了する。
【００５５】
ステップＳ１２５からステップＳ１２７では、セッションＩＤに基づいて複製先サーバが索出され、次に索出された複製先サーバが有するオーナーのサーバ識別子からオーナーが特定される。受信サーバがオーナーでなくオーナーの識別子も保持していない場合（ステップＳ１２０：ＮＯ、ステップＳ１２３：ＮＯ）、受信サーバのサーバ索出部２６は、セッションＩＤに基づいて複製先サーバを索出し（ステップＳ１２５）、索出された複製先サーバにオーナー情報を要求することで、オーナーのサーバ識別子を取得する（ステップＳ１２６）。受信サーバは、ステップＳ１１８で更新されたセッション情報を、オーナーのサーバ識別子に示されたサーバ１に対して送信することによって、オーナーによって保持されているセッション情報を更新する（ステップＳ１２７）。
【００５６】
その後、受信サーバは、ステップＳ１１８で更新されたセッション情報を、ステップＳ１２６において索出された複製先サーバに対して送信することによって、複製先サーバが保持するセッション情報を更新する（ステップＳ１２２）。その後、本フローチャートに示された処理は終了する。
【符号の説明】
【００５７】
１  サーバ
２  ロードバランサ
９  クライアント端末
【図１】
2013186837.tif 000003
【図２】
2013186837.tif 000004
【図３】
2013186837.tif 000005
【図４】
2013186837.tif 000006
【図５】
2013186837.tif 000007
【図６】
2013186837.tif 000008
【国際調査報告】
2013186837.tif 000009
2013186837.tif 000010