(57)【要約】      （修正有）【課題】簡単な構成でアプリケーションサーバにおけるアクセス処理を不要にして、システム可用性を向上させる方法を提供する。【解決手段】ロードバランサ14が、負荷分散処理に加え、セッションデータの永続化を行う。具体的には、ロードバランサにおける負荷分散処理によって選択されたアプリケーションサーバは、クライアント端末12からのリクエストパケットに応じてアプリケーションを実行してセッションデータを作成してレスポンスパケットをロードバランサへ返送する際に、レスポンスパケットに作成したセッションデータを付加してロードバランサへ返送する。ロードバランサでは、レスポンスパケットに付加されているセッションデータを記憶部に記憶し、レスポンスパケットからセッションデータを削除してクライアント端末へ転送する。【選択図】図１
2010079523.tif 000002
【特許請求の範囲】
【請求項１】
負荷分散装置を経由して複数のアプリケーションサーバと接続するクライアント端末に関するセッションデータを、該複数のアプリケーションサーバ間で共有する方法において、該方法は、
前記セッションデータを作成したアプリケーションサーバから前記負荷分散装置へ、該セッションデータを送信する第１の送信工程と、
前記負荷分散装置で前記セッションデータを記憶する記憶工程とを有することを特徴とするセッションデータ共有方法。
【請求項２】
請求項１に記載の方法において、該方法はさらに、
前記負荷分散装置に記憶されている第１のセッションデータを検索する検索工程と、
第１のセッションデータを前記複数のアプリケーションサーバのうちの１つへ送信する第２の送信工程と、
第１のセッションデータを基にして所定のアプリケーションを実行し、第２のセッションデータを作成するアプリケーション実行工程とを含み、
第１の送信工程は、第２のセッションデータを前記負荷分散装置へ送信し、
前記記憶工程は、第２のセッションデータを記憶することを特徴とするセッションデータ共有方法。
【請求項３】
請求項２に記載の方法において、前記検索工程は、前記クライアント端末から送信されたパケットに含まれている情報を利用して第１のセッションデータを検索することを特徴とするセッションデータ共有方法。
【請求項４】
請求項２に記載の方法において、第１の送信工程は、第１のセッションデータと第２のセッションデータとで一致する部分を除いた差分データを前記負荷分散装置へ送信することを特徴とするセッションデータ共有方法。
【請求項５】
請求項４に記載の方法において、前記記憶工程は、前記差分データを基にして、前記負荷分散装置における第１のセッションデータを更新して記憶することを特徴とするセッションデータ共有方法。
【請求項６】
ネットワークを介して互いに接続されたクライアント端末、負荷分散装置、および少なくとも２つのアプリケーションサーバを含み、該クライアント端末は該負荷分散装置を経由して該アプリケーションサーバと接続し、前記負荷分散装置は、前記クライアント端末からの要求を前記アプリケーションサーバのうちの１つに割り当てるアプリケーションサーバシステムであって、
前記アプリケーションサーバは、前記クライアント端末に関する情報であるセッションデータを前記負荷分散装置に送信する送信手段を含み、
該負荷分散装置は、該セッションデータを記憶する記憶手段を含むことを特徴とするアプリケーションサーバシステム。
【請求項７】
請求項６に記載のアプリケーションサーバシステムにおいて、前記負荷分散装置はさらに、前記クライアント端末のセッションデータを、前記記憶手段に記憶されているセッションデータから検索する検索手段を含むことを特徴とするアプリケーションサーバシステム。
【請求項８】
請求項６に記載のアプリケーションサーバシステムにおいて、前記検索手段は、前記クライアント端末から送信されたパケットに含まれているデータを利用して、該クライアント端末のセッションデータを検索することを特徴とするアプリケーションサーバシステム。
【請求項９】
請求項６に記載のアプリケーションサーバシステムにおいて、
前記アプリケーションサーバはさらに、前記負荷分散装置の記憶手段に記憶されている第１のセッションデータを受信する受信手段を含み、
前記送信手段は、第１のセッションデータと前記セッションデータ作成手段で作成された第２のセッションデータとで一致する部分を除いた差分データを前記負荷分散装置に送信し、
該負荷分散装置は、該差分データを用いて前記記憶手段における第１のセッションデータを更新することを特徴とするアプリケーションサーバシステム。
【請求項１０】
ネットワークを介してクライアント端末および少なくとも２つのアプリケーションサーバとそれぞれ接続し、該クライアント端末から送信されたリクエストパケットを受信して、負荷分散処理を行って該リクエストパケットを前記少なくとも２つのアプリケーションサーバのうちの任意の１つに転送し、該アプリケーションサーバからレスポンスパケットを受信して、該レスポンスパケットを前記クライアント端末に転送する負荷分散装置において、該装置は、
前記アプリケーションサーバで作成された、前記クライアント端末に関するセッションデータを、該アプリケーションサーバから受信する受信手段と、
該セッションデータを記憶する記憶手段とを含むことを特徴とする負荷分散装置。
【請求項１１】
請求項１０に記載の装置において、前記負荷分散装置はさらに、前記記憶手段に記憶されているセッションデータから、所定のクライアント端末のセッションデータを検索する検索手段を有することを特徴とする負荷分散装置。
【請求項１２】
請求項１１に記載の装置において、前記検索手段は、前記リクエストパケットに含まれる情報を基にして前記所定のクライアント端末のセッションデータを検索することを特徴とする負荷分散装置。
【請求項１３】
請求項１０に記載の装置において、前記セッションデータは、前記レスポンスパケットに含まれ、
前記負荷分散装置はさらに、該レスポンスパケットから該セッションデータを削除する削除手段を有することを特徴とする負荷分散装置。
【請求項１４】
負荷分散装置を介してクライアント端末と接続し、該クライアント端末へアプリケーションを提供するアプリケーションサーバであって、該サーバは、
前記クライアント端末に関する情報であるセッションデータを前記負荷分散装置へ送信する送信手段を含むことを特徴とするアプリケーションサーバ。
【請求項１５】
請求項１４に記載のアプリケーションサーバにおいて、該サーバは、前記セッションデータを更新した場合、該更新したセッションデータと更新する前のセッションデータとで一致する部分を除いた差分データを前記負荷分散装置へ送信することを特徴とするアプリケーションサーバ。
【請求項１６】
請求項１ないし５のいずれかに記載のセッションデータ共有方法の各工程をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーションサーバでセッションデータを共有する方法に関し、とくに、負荷分散装置を利用して共有する方法に関する。
【背景技術】
【０００２】
一般にアプリケーションサーバは、アプリケーションを実行中のクライアント、すなわちユーザに関する情報をセッションデータとして内部で管理する仕組みを有している。この際、冗長構成の実現を目的とした、アプリケーションサーバを複数台有するシステムでは、このセッションデータをアプリケーションサーバ間で共有する必要がある。
【０００３】
セッションデータを共有する従来の方式として、例えば、「データベースサーバ共有方式」および、「インメモリデータベース共有方式」が一般的に採用されている。
【０００４】
データベースサーバ共有方式では、クライアントはリクエストを負荷分散装置すなわちロードバランサへ送信し、ロードバランサからアプリケーションサーバへリクエストが転送される。その後、アプリケーションサーバはアプリケーション処理を実行し、セッション情報を生成し、またデータベースサーバ、すなわちDBサーバにアクセスして、生成されたセッション情報、すなわちセッションデータを、DBサーバへ登録する。登録後、アプリケーションサーバはレスポンスをロードバランサへ返送し、ロードバランサからクライアントへレスポンスが転送される。
【０００５】
またインメモリデータベース共有方式では、クライアントはリクエストをロードバランサへ送信し、ロードバランサからアプリケーションサーバへリクエストが転送される。その後、アプリケーションサーバはアプリケーション処理を実行し、セッション情報を生成する。アプリケーションサーバは、インメモリDBの機構を利用し、他のセッション共有対象アプリケーションサーバとセッションデータを共有する。なお、共有対象アプリケーションサーバは複数台の場合もある。その後、アプリケーションサーバは、ロードバランサへレスポンスを返送し、ロードバランサはクライアントへレスポンスを転送する。
【０００６】
例えば特許文献１には、他のアプリケーションサーバからセッションデータを取得するWebアプリケーションサーバシステムが開示されている。
【特許文献１】特開２００５−２８５００７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、このような従来の方式では、アプリケーションサーバにおいてアクセス処理が発生する。例えば、DBサーバ共有方式ではアプリケーションサーバからDBサーバへのアクセス処理が必要であり、またインメモリDB共有方式ではアプリケーションサーバから他の共有対象アプリケーションサーバへのアクセス処理が必要となる。しかし、このようなアクセス処理は、例えば、ネットワーク負荷や、アプリケーションサーバにおけるCPU負荷の増大や、スループットの低下等の原因となっていた。とくにデータベース共有方式の場合、システムを構成するノードが多くなった場合には、例えばレスポンスの遅延や、システム可用性の低下等の原因となっていた。
【０００８】
本発明はこのような従来技術の欠点を解消し、簡単な構成で、アプリケーションサーバにおけるアクセス処理を不要にするセッションデータ共有方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述の課題を解決するために、本発明によるセッションデータ共有方法では、ロードバランサが、負荷分散処理に加えて、セッションデータの永続化を行う。具体的には、ロードバランサにおける負荷分散処理によって選択されたアプリケーションサーバが、クライアント端末からのリクエストパケットに応じてアプリケーションを実行する際に作成したセッションデータを、ロードバランサへ返送するレスポンスパケットに付加してロードバランサへ返送する。ロードバランサでは、レスポンスパケットに付加されているセッションデータを記憶部に記憶し、レスポンスパケットからセッションデータを削除してクライアント端末へ転送する。その後の処理では、ロードバランサに記憶されているセッションデータを利用して、クライアント端末は、ロードバランサを経由してアプリケーションサーバと通信する。
【発明の効果】
【００１０】
本発明によれば、セッションデータを共有するために、アプリケーションサーバによるデータベースサーバへアクセスや、他の共有対象アプリケーションサーバへのアクセスを不要とすることが可能である。よって、１リクエスト／レスポンスで必要となるノード間通信を従来よりも少なくすることが可能になり、レスポンス時間を短縮することが可能である。また、アプリケーションサーバのCPU負荷を下げることが可能であるため、スループットを向上させることが可能である。
【００１１】
さらに本発明では、例えば、アプリケーションサーバを増設するまたは減らす場合には、ロードバランサの内部管理テーブルの更新のみを行うだけでアプリケーションサーバの増減設を実施することが可能であるため、煩雑な運用手順を実施する必要がない。
【発明を実施するための最良の形態】
【００１２】
次に添付図面を参照して本発明の実施例を詳細に説明する。図１を参照すると、本発明によるアプリケーションサーバデータ共有システム10の実施例が概略的にブロック図で示されている。実施例のアプリケーションサーバデータ共有システム10は、クライアント端末12、ロードバランサ14、アプリケーションサーバ、すなわちAPサーバ16、18、20を含んでいる。なお本発明の理解に直接関係のない部分は、図示を省略し冗長な説明を避ける。本明細書および図面において、同じ参照符号は同様の構成要素を示す。
【００１３】
図１において、クライアント端末12は、例えばインターネットやイントラネットなどのIPネットワーク22に接続された公知のパーソナルコンピュータなどの、APサーバ16〜20にリクエストを送信するノード全般である。本実施例では、クライアント端末12は、ロードバランサ14を経由してAPサーバ16〜20と接続している。なお図１に示す例では、代表例として1つのクライアント端末12が示されているが、クライアント端末は任意の数あってよい。
【００１４】
ロードバランサ14は、ネットワーク22を介してクライアント端末12と接続し、またネットワーク24を介してAPサーバ16〜20と接続し、クライアント端末12からの要求をAPサーバ16〜20のいずれかに割り当てるという、一般的なロードバランシング機能を備えている。さらに本実施例では、ロードバランサ14は、APサーバ16〜20のセッションデータを永続化する機能も備えている。なおネットワーク24は、任意のネットワークであってよく、例えばネットワーク22と同様のIPネットワークであってもよいし、逆にネットワーク22とは別のネットワーク、例えば内部ネットワークなどであってもよい。
【００１５】
図２を参照して、ロードバランサ14についてより詳細に説明する。ロードバランサ14は、制御部30、パケット受信部32、パケット送信部34、ロードバランシング処理部36、セッションデータ処理部38を有し、このセッションデータ処理部38はさらにデータ抽出・付加部40、記憶部42、および検索部44を有している。
【００１６】
制御部30は、ロードバランサにおける各部の動作を統合的に制御するものである。パケット受信部32、およびパケット送信部34は、対応するネットワーク22、24（図１）を介して送られてきたパケットを受信し、およびネットワーク22、24へ向けてパケットを送信するものである。ロードバランシング処理部36は、ロードバランシング処理を行うものであり、このロードバランシング処理は公知の処理であってよい。具体的に説明すると、本実施例ではロードバランシング処理部36にはパケット受信部32が受信したパケットが渡され、ロードバランシング処理部36は、このパケットに含まれている情報を基にして、事前にロードバランシング処理部36に設定されている公知の負荷分散アルゴリズムに従って最適なサーバを選択し、この選択したサーバに処理を割り振るために、パケット送信部34から選択したサーバへパケットを送信させている。これらの制御部30、パケット受信部32、パケット送信部43、ロードバランシング処理部36は公知のものを採用することが可能である。
【００１７】
セッションデータ処理部38は、ユーザ、すなわち図１に示すクライアント端末12のセッション情報を管理するものである。具体的には本実施例では、セッションデータ処理部38は、データ抽出・付加部40、記憶部42、および検索部44を含んでいる。
【００１８】
データ抽出・付加部40は、パケット受信部32が受信したパケットが供給され、このパケットから必要な情報を抽出する機能、パケットから必要な情報を削除する機能、およびパケット送信部34が送信するパケットに必要なデータを付加する機能を有している。具体的には、データ抽出・付加部40は、パケット受信部32が受信したパケットから、これに含まれているセッションデータを抽出、すなわち抜き出して記憶部42に記憶させ、また受信パケットから抜き出したセッションデータを消去し、消去されずに残ったデータをパケット送信部34から他のノードへ送信させている。またデータ抽出・付加部40は、受信パケットから検索部44における検索に必要な情報、例えばクッキーなどを抽出して検索部44に供給し、また検索部44による検索によって特定されたセッションデータをパケット送信部から送信されるパケットに付加している。
【００１９】
なお本実施例では、データ付加・除去部40がパケットからの情報の抽出、削除、および必要な情報のパケットへの付加を行っているが、本発明はこれに限定するわけではなく、任意の他の部分、例えばパケット受信部32、パケット送信部34、記憶部42、または検索部44がこれらの処理を行うようにすることも可能である。例えば、パケット受信部32が情報の抽出、削除を行い、パケット送信部34が情報の付加を行うようにしてもよい。
【００２０】
記憶部42は、公知の記憶回路であり、ここにセッションデータが記憶される。記憶回路は、書き換え可能であってよい。本実施例では、記憶部42に記憶されるセッションデータは、リクエストパケットを受信したAPサーバ16〜20（図１）で作成され、リクエストパケットに含まれているリクエストの実行によって作成される応答信号、すなわちレスポンスパケットに付加されてAPサーバ16〜20から送信され、パケット受信部32で受信され、データ抽出・付加部40で抽出されて、記憶部42に記憶されている。
【００２１】
記憶部42は、セッションデータを任意の形態で記憶しておくことが可能である。例えば、検索部44で行われる検索に沿うように記憶しておいてもよいし、また例えば名前順やセッションデータが作成された日時順やクライアント端末やAPサーバ毎等に記憶しておくことも可能である。また記憶部42に記憶されているセッションデータは任意のタイミングで削除や更新することが可能であり、例えば、同一のクライアント端末に対する新たなセッションデータがAPサーバから供給された場合に、これまでのセッションデータから新たなセッションデータへ更新するようにてもよいし、また例えば、ある一定期間セッションデータが使用されなかった場合に、そのセッションデータを削除するようにしてもよい。
【００２２】
検索部44は、記憶部42に記憶されているセッションデータから、必要なセッションデータ、たとえばある特定のクライアント端末のセッションデータを検索するものである。この検索部44における検索には、任意のやり方を採用することが可能であり、例えば本実施例では、検索部44における検索に必要な情報をデータ抽出・付加部40で得て、検索部44はこのデータ抽出・付加部40で得られた情報を基にして検索を行っている。より具体的には、本実施例は、HTTP（HyperText Transfer Protocol）を使用している環境であるため、データ抽出・付加部40で受信したパケットから、クッキー(Cookie)を抽出し、これを利用してクライアント端末を特定することによって、対応するセッションデータを特定している。
【００２３】
図１に戻って、APサーバ16、18、20は、ネットワーク24、例えばIPネットワーク上に配置され、アプリケーションソフトウエアを実行するコンピュータまたはソフトウエアである。図１に示す例では代表例として３つ示すが、任意の数あってよい。
【００２４】
図３を参照してAPサーバ16の各部について詳細に説明する。なおAPサーバ18、20もAPサーバ16と同様の構成である。本実施例では、APサーバ16は、制御部50、通信制御部52、アプリケーション実行部54を含んでいる。制御部50は、APサーバにおける各部の動作を統合的に制御するものであり、公知のものを採用することが可能である。通信制御部52は、ネットワークを介してアクセスしてきた他のノード、例えば図１に示すロードバランサ14との接続を制御するものである。具体的には本実施例では、通信制御部52は、図１に示すネットワーク24を介して送られてきたパケットを受信し、またネットワーク24へパケットを送信している。なお通信制御部52は、アプリケーション実行部が作成したセッションデータを、レスポンスパケットに付加してロードバランサへ返信している。
【００２５】
アプリケーション実行部54は、通信制御部52が受信したパケットに含まれている情報を基にして、公知のやり方で所定のアプリケーションを実行、処理するものである。またアプリケーション実行部54は、セッションデータを作成する機能を有し、本実施例では、このセッションデータは、通信制御部52によってロードバランサ14（図１）へ返送されるレスポンスパケットに付加され、ロードバランサへ送信される。
【００２６】
以上のような構成のシステム10において、APサーバ16、18、20間でセッションデータの共有を必要とする処理、例えば初期リクエストの処理、後続リクエストの処理、およびフェールオーバ時の処理は、例えば図４〜図７に示すように行われる。図４を参照して、初期リクエストの処理動作について説明する。図４において、まずクライアント端末12は、時刻T10にてリクエストを送信、すなわちリクエストパケットを送信すると、ロードバランサ14がネットワークを介してこのリクエストパケットを受信し、負荷分散アルゴリズムに従って最適なAPサーバ、たとえば図４に示す例ではAPサーバ16を選択し、時刻T12にてリクエストパケットをAPサーバ16に転送する。なお、図４に示す例ではAPサーバ16にリクエストパケットが転送されているが、APサーバ18または20に転送することもでき、この場合も、APサーバ16と同様の処理が行われる。
【００２７】
APサーバ16では、リクエストパケットを受信し、時刻T14にて、この受信したリクエストパケットに基づいてアプリケーション処理を実行して、セッション情報を生成する。その後APサーバ16は、時刻T16にてレスポンスパケットにセッション情報を付加してロードバランサ14へ返送する。ロードバランサ14では、時刻T18にて、APサーバ16からのレスポンスパケットに付加されているセッションデータを取り出して、記憶部に記憶し、またレスポンスパケットから取り出したセッションデータを消去する。その後ロードバランサ14は、時刻T20にて、セッションデータを消去した後のレスポンスパケットを、クライアント端末12に転送する。
【００２８】
その後、クライアント端末12が継続してリクエストパケットをアプリケーションサーバ16、18、20のいずれかへ送信する場合、すなわち後続リクエスト処理が行われる場合には、図５に例示するように負荷分散装置14を経由する際に、負荷分散装置14によって、この装置14に記憶されているセッションデータがリクエストパケットに付加されてアプリケーションサーバ16、18、20のいずれかへ送信される。
【００２９】
図５を参照して、後続リクエストの処理動作についてより詳細に説明する。図５において、クライアント端末12は、時刻T100にてリクエストパケットを送信する。ロードバランサ14は、ネットワークを介してリクエストパケットを受信する。その後ロードバランサ14は、時刻T112にて、記憶部に記憶されているセッションデータからクライアント端末12のセッションデータを検索する。具体的には、リクエストパケットにおけるクッキーを用いてクライアント端末12の特定を行い、特定されたクライアント端末12に対応するセッション情報を記憶部で検索する。またロードバランサ14は、負荷分散処理を行って、リクエストパケットを送信するのに適当なAPサーバを選択する。なお、初期リクエストと後続リクエストとで同じAPサーバを選択してもよいし、それぞれが異なっていてもよい。例えば、本実施例では、ロードバランサ14は、APサーバ16を選択する。
【００３０】
その後、ロードバランサ14は、時刻T104にてリクエストパケットに検索により特定されたセッション情報を付加し、選択したAPサーバ16へ、リクエストパケットを転送する。なお、検索の際、記憶部にセッション情報が記憶されていないと判断された場合は、ロードバランサ14は、選択したAPサーバ16にリクエストパケットをそのまま転送する。
【００３１】
ネットワークを介してリクエストパケットを受信したAPサーバ16は、時刻T106にてアプリケーション処理を実行し、セッションデータを新たに作成、すなわち、これまでのセッションデータを変更したり、またはこれまでのセッションデータに別のデータを追加する。その後APサーバ16は、時刻T108にて、レスポンスパケットに新たに作成されたセッションデータを付加し、ロードバランサ14へ返送する。このときにレスポンスパケットには、追加や変更のあったセッションデータ全体を付加してもよいし、また例えば公知のやり方で追加や変更のあった部分のみを特定し、この追加や変更のあった部分のみ、換言すれば一致する領域を除いた部分のみ、すなわち差分データを付加することも可能である。
【００３２】
例えば本実施例では、APサーバ16における通信制御部で、時刻T104にロードバランサ14から送られてきたそれまでのセッションデータと、時刻T106にAPサーバで新たに作成されたセッションデータとで一致する部分を除いた差分データを作成し、この差分データをレスポンスパケットに付加し、ロードバランサ14へ返送している。このように一致する部分を除いた残りの部分、すなわち相違する部分のみをレスポンスパケットに付加することでパケット量を少なくすることが可能である。なおセッション情報に追加や変更のない場合は、APサーバは、レスポンスパケットにセッションデータを付加しないでロードバランサへ返送してもよいし、変更や追加のない旨を知らせるデータを付加して返送してもよいし、さらにはそれまでと同じセッションデータを付加して返送してもよく、任意のやり方を採用することが可能である。
【００３３】
ロードバランサ14では、APサーバ16から送信されたレスポンスパケットを受信し、時刻T110にてこのパケットに付加されているセッションデータを取り出して、記憶部にある対応するセッションデータを更新する。この更新は、任意のやり方を採用することが可能であり、例えば、ロードバランサにおけるデータ抽出・付加部がレスポンスパケットから新たなセッションデータを取り出して、取り出したセッションデータを記憶部に上書きすることによって行ってもよいし、またレスポンスパケットに差分データのみが付加されている場合には、データ抽出・付加部によってこの差分データと、記憶部に記憶されている古いセッションデータとから新しいセッションデータを作成して記憶部に上書きするようにすることも可能である。なお、セッションデータが変更されていない場合には、ロードバランサ14は更新を行わなくてもよいし、逆に同じセッションデータを上書きするようにしてもよく、任意のやり方を採用することが可能である。その後、ロードバランサ14は、レスポンスパケットからセッションデータ、または差分データが付加されている場合には差分データを除去し、時刻T112にてセッションデータや差分データを消去した後のレスポンスパケットをクライアント端末12に返送する。
【００３４】
図６を参照して、フェールオーバ時、すなわちロードバランサが負荷分散処理によって特定したAPサーバに障害が発生し、別のAPサーバが処理を引き継ぐときの処理動作の一例について説明する。なお図６では、後続リクエスト処理中にAPサーバがダウンした状況を示しているが、所期リクエスト処理中にAPサーバがダウンした場合も、APサーバへ初期リクエストパケットが転送される以外は同様の処理が行われる。
【００３５】
図６において、クライアント端末12からロードバランサ14へのリクエストパケットの送信、ロードバランサ14におけるセッションデータの検索、および負荷分散処理により選択されたAPサーバへのリクエストパケットの転送の処理は、図５における時刻T100〜T104までの処理と同様である。リクエストパケットを受信したAPサーバ16は、リクエストパケットに付加されているデータを基にして、所定のアプリケーションを実行する。しかし、APサーバ16は、処理中に何らかの障害でダウンしてしまい、レスポンスパケットをロードバランサ14へ送信できなくなる。
【００３６】
ロードバランサ14は、時刻T202にて、レスポンスパケットが所定期間内に受信できなかったことから、APサーバ16のリクエストタイムアウトを検出し、時刻T204にて、負荷分散処理を行って別のAPサーバ、例えば本実施例ではAPサーバ18にリクエストパケットを転送する。APサーバ18では送信されてきたリクエストパケットを受信すると、時刻T206にて、所定のアプリケーションを実行し、またセッション情報を更新、または変更する。その後の処理、すなわち、APサーバ18におけるレスポンスパケットへセッションデータの付加および送信、ロードバランサにおけるセッションデータの記憶およびレスポンスパケットのクライアント端末12への転送は、図５に示す時刻T108〜T112と同様である。
【００３７】
図７を参照して、図４から図６に示した処理が行われる際のロードバランサ14における処理手順を概略的に説明する。図７において、ロードバランサ14は、クライアント端末12からリクエストパケットを受信すると（ステップS10）、リクエストパケットに含まれる情報を基にしてクライアント端末を特定し、それによってクライアント端末12と対応するセッションデータを記憶部42で検索する（ステップS12）。また、ロードバランサ14は、公知の負荷分散処理を行う。ステップS12における検索の結果、セッションデータが記憶部42に記憶されている場合には（ステップS14, Yes）、ロードバランサ14は、リクエストパケットにセッション情報を付加し（ステップS16）、負荷分散処理によって選択されたAPサーバにリクエストパケットを転送する（ステップS18）。一方、セッションデータが記憶部42に記憶されていななかった場合には（ステップS14, No）、負荷分散処理によって選択されたAPサーバにリクエストパケットをそのまま転送する（ステップS18）。
【００３８】
その後、ロードバランサ14は、リクエストパケットを転送したAPサーバから指定時間内にレスポンスパケットの返送があるか否かを判断し（ステップS20）、レスポンスがなかった場合には、このAPサーバがダウンしたと判断して負荷分散処理によって別のAPサーバを選択し、リクエストパケットをその別のAPサーバに転送する（ステップS22）。この場合、ロードバランサ14は、この別のAPサーバからレスポンスパケットの返送があるか否かをさらに判断し、レスポンスパケットの返送があるまで、さらなる別のAPサーバへリクエストパケットの転送処理を繰り返す。
【００３９】
ステップS20において、リクエストパケットを転送したAPサーバから指定時間内にレスポンスパケットの返送があった場合には、ロードバランサ14は、レスポンスパケットに付加されているセッションデータを記憶部42に記憶することによりセッションデータを更新する（ステップS24）。その後、ロードバランサ14は、レスポンスパケットからセッションデータを除去し、クライアント端末12にレスポンスパケットを転送する（ステップS26）。
【００４０】
以上のようにして本発明によるシステム10では、APサーバで作成されたセッション情報はロードバランサ14へ送信され、ロードバランサ14で記憶される。よって、APサーバから別のデータベースサーバへのアクセスや、リクエストを受信したAPサーバから、他の共有対象のAPサーバへのアクセス処理、例えば図１で説明すればAPサーバ16からAPサーバ18へのアクセス処理が不要であり、レスポンス時間を短縮することが可能である。また、APサーバから他のノードへのアクセス処理が減るため、APサーバの負荷を減らすことが可能、すなわちスループットを向上させることが可能である。
【００４１】
またシステム10にさらにAPサーバを増減する際は、ロードバランサ14における管理テーブルのみを更新すればよく、例えば、データベースアクセスクライアントの数やセッションデータ共有対象アプリケーションサーバリストの更新といった煩雑な処理を行う必要がなくなるため、容易にAPサーバを増減することが可能である。
【００４２】
なお、上述の実施例で示された各部の機能は、コンピュータにプログラムを解読実行させることによっても実現可能である。
【図面の簡単な説明】
【００４３】
【図１】本発明によるアプリケーションサーバシステムを概略的に示したブロック図である。
【図２】図１に示す実施例におけるロードバランサの構成例を概略的に示したブロック図である。
【図３】図１に示す実施例におけるアプリケーションサーバの構成例を概略的に示したブロック図である。
【図４】図１に示すシステムにおけるクライアント端末、ロードバランサ、APサーバでの初期リクエストの処理動作の処理手順の一例を示したシーケンシャルチャートである。
【図５】図１に示すシステムにおけるクライアント端末、ロードバランサ、APサーバでの後続リクエストの処理動作の処理手順の一例を示したシーケンシャルチャートである。
【図６】図１に示すシステムにおけるクライアント端末、ロードバランサ、APサーバでのフェールオーバ時の処理動作の処理手順の一例を示したシーケンシャルチャートである。
【図７】ロードバランサにおける処理手順の一例を概略的に示した流れ図である。
【符号の説明】
【００４４】
10  アプリケーションサーバシステム
12  クライアント端末
14  ロードバランサ
16  アプリケーションサーバ
【図１】
2010079523.tif 000003
【図２】
2010079523.tif 000004
【図３】
2010079523.tif 000005
【図４】
2010079523.tif 000006
【図５】
2010079523.tif 000007
【図６】
2010079523.tif 000008
【図７】
2010079523.tif 000009