JP4961146B2 - 負荷分散方法およびシステム - Google Patents

Description

本発明は、セッション情報を扱う業務サービスを提供している業務システムにおける負荷分散方法およびシステムに関する。

近年、業務サービスを提供する情報システムは、多数のクライアントからのリクエストに対処するために、業務サーバを複数設置し、負荷分散装置を用いてリクエストを分散する方法が主流となっている。

この負荷分散に用いるアルゴリズム、すなわち、リクエストを転送する業務サーバを決定する手順は業務システム全体の性能を左右する。負荷分散アルゴリズムが適切でない場合、クライアントからのリクエストが均等にサーバに振り分けられず、業務サーバ間で負荷の不均衡が生じる。負荷の大きいサーバでは、負荷が小さい他の業務サーバと比較すると、リクエストに対する処理時間が大幅に大きくなり、リクエスト処理が遅れてしまう。例えば、インターネット上でのサービスの場合、リクエスト処理の遅れはサービス利用者であるクライアントへの応答の遅れとして顕在化する。

効果的な負荷分散アルゴリズムの方式は非特許文献１に幾つか開示されている。例えばクライアントとの接続数が一番少ない業務サーバを選択する「最小接続数」やリクエストに対する応答時間が一番短い業務サーバを選択する「応答時間」などがよく用いられる方式である。また、非特許文献２では、CPU使用率が一番小さい業務サーバを選択して転送する方式が開示されている。これら負荷分散アルゴリズムは、レイヤ4レベル、つまりTCPコネクション単位で負荷分散を行うため、レイヤ4スイッチングと呼ばれる。

特許文献１では、セッション情報を個々の業務サーバのメモリ上に配置するのではなく、全業務サーバから共有されるセッション情報管理サーバに配置する方法が開示されている。しかし、この方法はリクエスト処理のたびにセッション情報管理サーバに問い合わせを行い、セッション情報を各自のサーバへロードするため、リクエスト処理に時間がかかる。またセッション情報管理サーバに負荷が集中するなどの問題がある。非特許文献３でも、セッション情報を共有のデータベースに配置する方法が開示されているが、同様に性能上の問題が発生してしまう。

通常、ステートフルなアプリケーションが稼働する場合、レイヤ7パーシステンスと呼ばれる負荷分散方式がよく用いられる。レイヤ7パーシステンスとは、クライアントからの初回時のリクエスト（以下、初回リクエストと記述）に対しては、レイヤ４スイッチングに従って任意の業務サーバへ転送し、同一クライアントからの二回目以降のリクエスト（以下、継続リクエストと記述）に対しては、リクエストに含まれているサーバ識別文字列に基づいて、初回時と同じ業務サーバへ転送する負荷分散方式である。サーバ識別文字列とは、負荷分散装置がリクエストの転送先業務サーバを識別するための文字列であり、初回リクエスト転送時に業務サーバによって付与される。

レイヤ7パーシステンスの一例として、サーバ識別文字列をリクエストのCookieヘッダに埋め込む方式が特許文献２に開示されている。

米国特許出願公開第6,098,093号明細書 米国特許出願公開第6,473,802号明細書 John Wiley & Sons 著、"Load Balancing Servers, Firewalls and Caches", Wiley Computer 出版、2002、p.19 M.Garland, S.Grassia, R.Monroe, S.Puri, 的mplementing Distributed Server Group for the World Wide Web", Tech. Rep. CMU-CS-95-114, Carnegie Mellon University, School of Computer Science, Jan. 1995. Scott Hawkins 著、"BEA WebLogic Server Administration Kit"、Prentice Hall Ptr 出版、2003、p.78

特許文献１では、セッション情報を個々の業務サーバのメモリ上に配置するのではなく、全業務サーバから共有されるセッション情報管理サーバに配置する方法が開示されている。しかし、この方法はリクエスト処理のたびにセッション情報管理サーバに問い合わせを行い、セッション情報を各自のサーバへロードするため、リクエスト処理に時間がかかる。またセッション情報管理サーバに負荷が集中するなどの問題がある。非特許文献３でも、セッション情報を共有のデータベースに配置する方法が開示されているが、同様に性能上の問題が発生してしまう。

通常、ステートフルなアプリケーションが稼働する場合、レイヤ7パーシステンスと呼ばれる負荷分散方式がよく用いられる。レイヤ7パーシステンスとは、クライアントからの初回時のリクエスト（以下、初回リクエストと記述）に対しては、レイヤ４スイッチングに従って任意の業務サーバへ転送し、同一クライアントからの二回目以降のリクエスト（以下、継続リクエストと記述）に対しては、リクエストに含まれているサーバ識別文字列に基づいて、初回時と同じ業務サーバへ転送する負荷分散方式である。サーバ識別文字列とは、負荷分散装置がリクエストの転送先業務サーバを識別するための文字列であり、初回リクエスト転送時に業務サーバによって付与される。

レイヤ7パーシステンスの一例として、サーバ識別文字列をリクエストのCookieヘッダに埋め込む方式が特許文献２に開示されている。

しかし、レイヤ7パーシステンスを用いた場合、継続リクエストに対する転送先業務サーバが常に固定されてしまうため、継続リクエストの負荷分散を制御することが不可能となる。このため、ある時点において業務サーバ間で負荷に偏りが生じた場合でも、レイヤ４スイッチングの様に均等に負荷分散することができない。

特に、業務システム全体の負荷が上昇したなどの理由でマシンを新たに増設した場合、既存マシンへの継続リクエストを増設マシンへ切り替えて転送することは出来ないため、既存マシンの負荷を軽減することが出来ない。また、メンテナンス等の理由で、ある特定のマシンを閉塞したい場合、そのマシンへ転送される継続リクエストを他のマシンへ切り替えて転送する事ができないため、マシン上に存在する全てのセッション情報が削除（つまり、全クライアントがログアウトする）されるまで待つ、あるいは強制的にマシンをシャットダウンする必要がある。後者の場合、クライアントはサービス利用中に突然切断される事態が生じてしまう。

前記課題を解決するために、複数の業務サーバ装置と負荷分散装置から構成される業務システムにおいて、クライアントから送信された継続リクエストに対する負荷分散制御方法であって、前記継続リクエストに対する業務処理を前記業務サーバ装置が実行後、前記継続リクエストに括り付けられているセッション情報を他の業務サーバ装置へ移動し、前記移動先サーバ装置を負荷分散装置が識別するための文字列を前記継続リクエストに対するレスポンスへ埋め込み、前記クライアントへ返すことによって、前記クライアントから送信される以降の継続リクエストの転送先業務サーバ装置を切り替えることを特徴とする。

また、前記複数の業務サーバ装置の負荷を監視する監視手段と、前記監視手段によって前記各業務サーバ装置の負荷を記憶する記憶手段と、セッション情報の移動元/移動先となる業務サーバ装置を決定する制御処理手段と、運用管理者から負荷比率を受け付ける入力受付手段と、から構成される運用管理システムであって、前記制御処理手段は、前記記憶手段に記録された前記複数の業務サーバの負荷と前記入力受付手段から運用管理者によって入力された負荷比率を元に、セッション情報の移動元、移動先となる業務サーバ装置を決定し、決定した業務サーバ装置へ移動指示を行うことで、前記各業務サーバ装置間の負荷が、前記運用管理者によって入力された負荷比率へ推移するように、継続リクエストの転送先業務サーバ装置の切り替えを行う。

その他、本願が開示する課題、及びその解決方法は、発明を実施するための最良の形態の欄により明らかにされる。

本発明によれば、あるマシンに対して転送されている継続リクエストを他のマシンへ切り替えて転送することにより、マシンの負荷の低減を実現できる。

以下、負荷分散制御方法について、適宜図面を参照しながら本システムの実施形態について説明する。

レイヤ4スイッチングは、業務サーバ上でクライアントとの会話状態を保持しないステートレスなアプリケーションが稼働している場合は有効に機能する。ステートレスなアプリケーションの場合、各クライアントから発生する一連のリクエストはそれぞれ独立したものであるため、負荷分散装置は各リクエストに対して、その時点で最適な業務サーバを選択して転送することができるからである。

これに対して、業務サーバ上でクライアントとの会話状態を保持するステートフルなアプリケーションが稼働している場合、上記レイヤ４スイッチングを用いると、負荷分散装置からリクエストを受け取った業務サーバ上で、リクエスト処理中にエラーが発生することがある。

このエラー原因について説明する前にまず、ステートフルなアプリケーションについて説明する。

ステートフルなアプリケーションは一般に複数のページから構成される。クライアントは各ページを順次呼び出し、それぞれのページでデータを入力してリクエストを送信する。リクエストを受信した業務サーバは、クライアントが入力したデータを該クライアントに対応付けてメモリ上に保持しており、それらデータは業務処理実行時に使用される。

たとえばショッピングサイトでは、クライアントはログイン後、購入ページにて購入商品名などのデータを入力し、次にユーザ情報入力ページにて住所やクレジットカード番号などのデータを入力する。これらデータは業務サーバのメモリ上に保持され、最後にクライアントが決済ページにて決済ボタンを押下すると、業務サーバの決済処理時に使用される。

これらクライアントと対応づけられたデータ群を格納したテーブル又は構造体をセッション情報と呼び、クライアント毎に存在する。ここで、業務サーバによるセッション情報を使用した業務処理の流れについて、先のショッピングサイトを例にとり、具体的に説明する。

まず、クライアントがログインページにてログインボタンを押下してリクエストを送信すると、業務サーバ上で、そのクライアントと対応づけたセッション情報が新規に作成され、同時に、該クライアントを識別するための識別番号が発行される。業務サーバは発行した識別番号を格納したレスポンスをクライアントへ送信する。以降のクライアントからのリクエストには、該識別番号が含まれることになる。

次に、クライアントが商品購入ページで商品データを入力してリクエストを送信すると、業務サーバはリクエストに含まれる番号と商品データを取り出し、取り出したID番号に対応づけられているセッション情報をメモリ上から取り出す。そして、セッション情報へ商品データを格納し、クライアントへレスポンスを送信する。

次にクライアントはユーザ情報入力ページにて住所やクレジットカードなどのユーザデータを入力してリクエストを送信すると、業務サーバは先ほどと同様にID番号とユーザデータをリクエストから取り出し、ID番号に対応づけられているセッション情報をメモリ上から取り出す。そして、セッション情報へユーザデータを格納し、クライアントへレスポンスを送信する。

最後にクライアントは決済ページにて決済ボタンを押下してリクエストを送信すると、業務サーバはリクエストに含まれるID番号に対応するセッション情報から全てのデータを取り出し、業務処理を実行する。

ステートフルなアプリケーションが稼働している場合、各クライアントから発生する一連のリクエストは独立したものではなく、ある時点でのリクエストは、それ以前に同一クライアントによって生成/更新されたセッション情報を利用する場合がある。このため、ステートフルなアプリケーションが稼働している場合、各クライアントから発生する一連のリクエストは全て同一の業務サーバへ転送する必要がある。

ステートフルなアプリケーションが稼働している場合にレイヤ４スイッチングを用いて負荷分散を行うと、負荷分散装置はクライアントから発生する一連のリクエストに対して、それぞれ、その時点で最適な業務サーバを選択して転送するため、以前と異なる業務サーバにリクエストを転送してしまう場合がある。このとき、業務サーバはクライアントに対応するセッション情報を参照しようとするが、メモリ上に存在しないためエラーとなる。

図１は本実施の形態に係るシステムの全体構成を示す例である。

業務システム101はクライアント102に対して業務サービスを提供する情報処理システムであり、インターネット105と顧客アクセス用ネットワーク113によって通信可能に接続される。また、運用管理装置106は業務システム101を管理する装置であり、運用管理用ネットワーク114によって通信可能に接続される。

クライアント102は業務システム101が提供する業務サービスを利用するために、Webブラウザ141を用いて処理要求を業務システム101へ送信するコンピュータであり、プロセッサ、記憶部、通信部などから構成される。クライアント102は処理要求としてHTTP（Hyper Text Transfer Protocol）リクエスト103を業務システム101へ送信する。また処理要求に対する結果として、HTTPレスポンス104を業務システム101から受け取る。尚、クライアント102は単数でもよいし、複数でもよい。

業務システム101は、負荷分散装置111と複数の業務サーバ装置112から構成される。図１では負荷分散装置111は1台のみとして表されているが、たとえば負荷分散装置111に障害が発生した場合に備えて、複数台を用いた冗長構成としてもよい。

負荷分散装置111は、クライアント102から送信されてくるHTTPリクエスト103を、レイヤ7パーシステンスを用いて、各業務サーバ装置112に振り分ける機能を有しており、プロセッサ、記憶部、通信部などから構成される。なお、負荷分散装置111の機能は、業務サーバ装置112にソフトウェアまたはハードウェアとして組み込まれるようにしてもよい。

業務サーバ装置112は、プロセッサ（CPU）、メモリ、記憶部、通信部などからなる装置である。

業務処理部131はクライアント102に対して業務サービスを提供する。負荷分散装置111から転送されたHTTPリクエスト103に対する業務処理を行い、処理結果を格納したHTTPレスポンス104を生成し、該HTTPレスポンス104をクライアント102へ返信する処理を行う。

業務処理部131が提供する業務サービスの具体例としては、たとえば購買サービスや座席予約サービスが挙げられるが、本実施例においては業務サービスの内容は特に規定しない。但し、クライアント102との会話状態をセッション情報として業務サーバ装置112のメモリ上に保持するステートフルなサービスが稼働していると想定する。

セッション情報管理部132は、セッション情報の移動または受信を行う。セッション情報の移動とは、自身の業務サーバ装置112のメモリから特定のセッション情報を取り出し、他の業務サーバ装置112上のセッション情報管理部132へ送信する処理であり、また、セッション情報の受信とは、他の業務サーバ装置112上のセッション情報管理部132から送信されたセッション情報を受信し、自身の業務サーバ装置112のメモリ上へ格納する処理である。これら2つの処理はそれぞれ別のプロセスとして構成されてもよいし、同一プロセス上の別スレッドとして構成されてもよい。

セッション情報の移動及び受信の具体的な処理については後述する。

業務サーバ装置監視部133は、自身の業務サーバ装置112上の各種負荷情報を、繰り返し、たとえば定期的に収集し、運用管理装置106上の業務サーバ装置管理部124へ送信する処理を行う。

負荷情報とは例えばCPU使用率やメモリ使用率、メモリ使用量、クライアント102との接続数、クライアント102からHTTPリクエスト103を受信してからHTTPレスポンス104を送信するまでのレスポンス時間、所定時間内にクライアント102から受信したHTTPリクエスト103の数、各業務サーバ装置112に配置されているセッション情報の数など、業務サーバ装置112の稼働に関わる様々な情報であり、これらを複数組み合わせて収集することも出来る。

図１の業務処理部131、セッション情報管理部132、業務サーバ装置監視部133は、マイクロチップのようなそれぞれ独立したハードウェアとしてもよいし、業務処理プログラム、セッション情報管理プログラム、業務サーバ装置監視プログラムとしてソフトウェアで実装し、これらプログラムを図１の業務サーバ装置に図示されていないメモリ上に格納し、図示されていないプロセッサ（CPU）によりプログラムを実行することで、各処理部の機能を実現することもできる。

運用管理装置106は、プロセッサ（CPU）、メモリ、記憶部、通信部などからなる装置である。

業務システム101に存在する複数の業務サーバ装置112間でセッション情報の再配置を行いたい場合、運用管理者は運用管理装置106の入力受付部121を通じて再配置を指示する。

再配置を行いたい場合とは、たとえば、業務サーバ装置112を新たに増設したなどの理由で、各業務サーバ装置112間でセッション情報数に偏りが生じてしまい、均等な負荷分散が実現できなくなった場合や、特定の業務サーバ装置112を閉塞する際、該業務サーバ装置112上のセッション情報を削除せずに、かつ短時間で閉塞したい場合などが挙げられる。

各業務サーバ装置112間でセッション情報数に偏りが生じてしまった場合、均等な負荷分散を実現するために、継続HTTPリクエスト103に対して転送先となる業務サーバ装置112の切り替えを行う。この際、該転送先業務サーバ装置112へ、該継続HTTPリクエスト103に括り付けられているセッション情報が移動される。この移動処理は、各業務サーバ装置112間で負荷を均等にするために切り替えられる継続HTTPリクエスト103の数行われる。

特定の業務サーバ装置112を閉塞したい場合、該業務サーバ装置112へ転送されている全ての継続HTTPリクエスト103を、他の業務サーバ装置112へ転送されるように切り替えを行う。この際、切り替え先の業務サーバ装置112へ、該継続HTTPリクエスト103に括り付けられているセッション情報が移動される。この移動処理は、閉塞対象の業務サーバ装置112へ転送される継続HTTPリクエストの数行われる。

セッション情報の再配置はセッション情報移動元決定部122、セッション情報移動先決定部123および、各業務サーバ装置112上のセッション情報管理部132が連携することにより行われるが、詳しい処理内容は後述する。

セッション情報移動元決定部122は、業務システム101上に存在する全業務サーバ装置112の中からセッション情報の移動元となる装置を単数または複数選択し、選択した業務サーバ装置112に対して移動指示を送信する処理を行うモジュールである。

セッション情報移動先決定部123は、セッション情報の移動先となる業務サーバ装置112を決定する処理を行うモジュールである。セッション情報の移動処理を行っている業務サーバ装置112上のセッション情報管理部132は、セッション情報の移動先装置を特定するために、セッション情報移動先決定部123へ移動先装置の問い合わせを行う。該問い合わせに呼応してセッション情報移動先決定部123は移動先となる装置を決定し、問い合わせのあったセッション情報管理部132に対して、決定した業務サーバ装置112を通知する。

業務サーバ装置管理部124は、各業務サーバ装置112の負荷情報を一元管理するモジュールであり、各業務サーバ装置112上の業務サーバ装置監視部133から負荷情報を繰り返し、たとえば定期的に受信し、業務サーバ装置状態テーブル125へ収集した負荷情報を記録する処理を行う。

業務サーバ装置状態テーブル125は業務システム101に存在する全業務サーバ装置112の負荷情報を記録したテーブルであり、業務サーバ装置管理部124によって繰り返し、たとえば定期的に更新される。業務サーバ装置状態テーブル125はセッション情報移動元決定部122とセッション情報移動先決定部123によって参照され、セッション情報移動元決定部122は該テーブル125に記録されている各業務サーバ装置112の負荷情報に基づいて、セッション情報の移動元となる業務サーバ装置112を決定する。同様に、セッション情報移動先決定部123は該負荷情報に基づいて移動先となる業務サーバ装置112を決定する。

なお、業務サーバ装置状態テーブルは、図１に図示されていない記憶部に格納されている。

図１の入力受付部121、セッション情報移動元決定部122、セッション情報移動先決定部123、業務サーバ装置管理部124は、それぞれ独立したハードウェアでもよいし、入力受付プログラム、セッション情報移動元決定プログラム、セッション情報移動先決定プログラム、業務サーバ装置管理プログラムとしてソフトウェアで実装し、これらプログラムを図１の運用管理装置に図示されていないメモリ上に格納し、図示されていないプロセッサ（CPU）によりプログラムを実行することで、各処理部の機能を実現することもできる。

次に、図２〜図６を参照しながらクライアント102、負荷分散装置111、業務サーバ装置112、運用管理装置106について、それぞれが行う処理の詳細を説明する。

クライアント102は業務サービスを利用するために、処理要求を格納したHTTPリクエスト103を業務システム101へ送信し、該業務システム101から処理結果が格納されたHTTPレスポンス104を受信する。

HTTPリクエスト103には、大きく分けて2種類のリクエストが存在する。1つは業務サービスを初めて利用する際に送信する「初回HTTPリクエスト」であり、もう1つは、初回HTTPリクエストを送信後、サービスを継続的に利用する際に送信する「継続HTTPリクエスト」である。

図２Ａ、図２ＢはRFC（Request for Comments）2616において定義されているHTTP1.1のリクエスト構造を表したものであり、本実施形態におけるHTTPリクエスト103の好適な例である。

図２Ａは初回HTTPリクエストの構造を表したものであり、処理要求を表すリクエストライン（201）とリクエストに関する様々な情報を含むヘッダフィールド（202）から構成される。

一方、図２Ｂは継続HTTPリクエスト103の構造を表したものであり、初回HTTPリクエスト103と異なり、Cookieフィールド（211）が付与されている。Cookieフィールド（211）は負荷分散装置111がレイヤ７パーシステンスを用いて継続リクエストを同一の業務サーバ装置112へ転送し続けるために使用する文字列を格納しており、詳しくは後述するが、Cookie名（221）は、それを含むHTTPリクエストが継続HTTPリクエストであることを負荷分散装置111が判断するための文字列、Cookie値（222）はそれを含むHTTPリクエスト103の転送先業務サーバ装置112を負荷分散装置111が識別するための文字列であり、一般に、「Cookie名(221)=Cookie値（222）」という形式で格納される。

本実施形態においては、継続HTTPリクエスト103の転送先となる業務サーバ装置112を負荷分散装置111が識別するための手段として、レイヤ７パーシステンスの一実装であり上記Cookieフィールド（211）を利用したCookieスイッチングを例に説明するが、本実施例においては、継続HTTPリクエスト103から業務サーバ装置112を識別できる手段であれば他のものであってもよい。たとえば、継続HTTPリクエスト103の宛先URLに業務サーバ装置112を識別するための情報を埋め込み、汎用の負荷分散装置に装備されているURLスイッチングを利用して識別する方法や、業務サーバ装置112を識別するためのヘッダフィールドをHTTPリクエスト103へ独自に追加し、汎用の負荷分散装置に装備されているヘッダスイッチングを利用して識別する方法なども本実施例に適用可能である。

図３はRFC2616に定義されているHTTP1.1のレスポンス構造を表したものであり、本実施形態におけるHTTPレスポンス104の好適な例である。HTTPレスポンス104は業務処理部131によって生成され、処理結果の状態を表すステータスライン（301）と、レスポンスに関する様々な情報を含むヘッダフィールド（302）、処理結果が格納されたメッセージボディ（303）から構成される。

ヘッダフィールド（302）に含まれるset-Cookieフィールド（311）は、該フィールド311に記述された文字列を、次回からのHTTPリクエスト103のCookieフィールド（211）に含めることを指示するための属性である。たとえば、set-Cookieフィールド（311）に”ServerID=1”という文字列が記述された場合、そのHTTPレスポンス104を受け取ったクライアント102から送信される以降のHTTPリクエスト103には、”ServerID=1”という文字列を含むCookieフィールド（211）が含まれることになる。

負荷分散装置111が行う処理について説明する。クライアント102から業務システム101へ送信されたHTTPリクエスト103は最初に負荷分散装置111が受信する。負荷分散装置111は、業務システム101に存在する複数の業務サーバ装置112の中から1台を選択し、該業務サーバ装置112へ受信したHTTPリクエスト103を転送する処理を行う。負荷分散装置111が行う業務サーバ装置112の選択処理はCookieスイッチングに基づいて行われる。

Cookieスイッチングによる選択処理手順の詳細ついて説明する。まず、負荷分散装置111は受信したHTTPリクエスト103が新規HTTPリクエストか、あるいは継続HTTPリクエストかを判断するため、リクエストのCookieフィールド（211）と自身が保持する継続リクエスト振り分けテーブルを照合する。これらスイッチングの処理は、負荷分散装置の有するプロセッサにより実行される。

図４は継続リクエスト振り分けテーブルの一例である。継続リクエスト振り分けテーブルは、負荷分散装置のメモリやハードディスクドライブなどの記憶部に格納されている。

リクエスト識別子フィールド（411）には、受信したHTTPリクエスト103が継続リクエストであるかを判断するための文字列が格納されており、リクエストに含まれるCookieフィールド（211）のCookie名（221）が該文字列と等しい場合、該リクエストを継続HTTPリクエストと判断する。図４に示す例では、受信したHTTPリクエスト103に含まれるCookie名（221）が”ServerID”である場合、該HTTPリクエスト103を継続リクエストと判断する。

サーバ識別子フィールド（412）及び業務サーバ装置アドレスフィールド（413）の役割については後述する。

受信したHTTPリクエスト103が新規リクエストの場合、負荷分散装置111はレイヤ４スイッチングアルゴリズムに基づいて転送先業務サーバ装置112を選択する。レイヤ４スイッチングアルゴリズムは、クライアントとの接続数が一番少ない業務サーバを選択する「最小接続数」やリクエストに対する応答時間が一番短い業務サーバを選択する「応答時間」、CPU使用率が一番小さい業務サーバを選択する「CPU負荷」などが存在するが、本実施形態では上記アルゴリズムを含めて、汎用の負荷分散装置製品に実装されている任意のレイヤ４スイッチングアルゴリズムを用いることができる。

受信したHTTPリクエスト103が継続リクエストの場合、負荷分散装置111は、該HTTPリクエスト103に含まれるCookieフィールド（211）のCookie値（222）と継続リクエスト振り分けテーブル400のサーバ識別子フィールド（412）に基づいて、転送先業務サーバ装置112を選択する。

サーバ識別子フィールド（412）には、継続HTTPリクエスト103の転送先となる業務サーバ装置112を識別するための値が格納されており、業務サーバ装置アドレス413には業務サーバ装置112のアドレスとしてIPアドレスとポート番号の対が格納されている。

負荷分散装置111は、継続リクエストに含まれるCookieフィールド（211）のCookie値（222）をサーバ識別子フィールド（412）と照合し、該Cookie値（222）に一致するサーバ識別子を持つ行が存在する場合、その行に格納されている業務サーバ装置アドレス413をアドレスとして持つ業務サーバ装置112へリクエストを転送する。

たとえば、継続リクエスト振り分けテーブル400に図４に示す値が格納されている場合、受信した継続HTTPリクエスト103のCookie値（222）が”1”の場合、負荷分散装置111は該HTTPリクエスト103を、”192.168.1.10:80”をアドレスとして持つ業務サーバ装置112へ転送する。以上が、Cookieスイッチングによる転送先サーバ装置の選択処理である。

尚、詳しくは後述するが、継続HTTPリクエスト103に含まれるCookieフィールド（211）のCookie名（221）とCookie値（222）は、初回HTTPリクエスト103が転送された業務サーバ装置112によって付与される。

具体的には、業務サーバ装置112は初回HTTPリクエスト103に対するHTTPレスポンス104を生成する際、set-Cookieフィールド（311）のCookie名（321）へ継続リクエスト振り分けテーブル400のリクエスト識別子フィールド（411）と同じ値を、Cookie値（322）へ自身のアドレスと同じ値を持つ業務サーバ装置アドレスフィールド（413）に対応するサーバ識別子フィールド（412）の値を格納する。

このように、負荷分散装置111が保持する継続リクエスト振り分けテーブル400の内容に対応するCookie名（321）とCookie値（322）を各業務サーバ装置112が初回HTTPリクエスト103に対するHTTPレスポンス104へ付与することで、負荷分散装置111は以降の継続HTTPリクエスト103を初回時に転送した業務サーバ装置112と同じ装置へ転送し続けることができる。

業務サーバ装置112が行う処理について説明する。業務処理部131は負荷分散装置111から受信したHTTPリクエスト103に対する業務処理を行い、HTTPレスポンス104を生成する処理を行う。

尚、本実施形態では、業務処理部131上にはクライアント102との会話状態を保持するステートフルなアプリケーションが稼働しており、初回HTTPリクエスト103に対する業務処理を行う際、該HTTPリクエスト103の送信元クライアント102に対応するセッション情報を自身のメモリ上に生成することを想定する。このセッション情報を使用して、業務サーバとの業務処理を行う。

業務処理部131の好適な例としては、J2EE(Java 2 Platform, Enterprise Edition:登録商標) Servlet APIの実装であるApache Tomcatがある。本実施例において業務処理部131はApache Tomcatをベースに説明を行うが、本実施例はApache Tomcatに限定されるものではない。

業務処理部131は業務処理を実行後、HTTPレスポンス104を生成し、該HTTPレスポンス104のステータスライン（301）、ヘッダフィールド（302）、メッセージボディ（303）へ処理結果に応じた値を格納する。

この際、業務サーバ処理部131は、クライアント102から送信される以降の継続リクエスト103が負荷分散装置111によって自身の業務サーバ装置112へ引き続き転送され続けることを実現するために、ヘッダフィールド（302）のset-Cookieフィールド（311）にCookie名（321）とCookie値（322）を格納する。先に説明したように、Cookie名（321）には、負荷分散装置111が保持する継続リクエスト振り分けテーブル（400）のサーバ識別子フィールド（411）と同じ値を、Cookie値（322）には自身のアドレスと同じ値を持つ業務サーバ装置アドレスフィールド（413）に対応するサーバ識別子フィールド（412）と同じ値を格納する。

HTTPレスポンス104に対するset-Cookieフィールド（311）の格納方法には、業務処理部131のアプリケーション側で付与する方法と、業務処理基盤側で付与する方法とがある。

前者の方法は、set-Cookieフィールド（311）へ値を格納するロジックをアプリケーションの業務処理ロジックへ追加する方法であり、その好適な例としては、Servlet API準拠のWebアプリケーションで、HttpServletResponse.addCookieメソッドの引数に、適切なCookie名（321）とCookie値（322）を指定して呼び出す方法がある。

後者の方法は、業務処理基盤側がHTTPレスポンス103のset-Cookieフィールド（311）へ値を格納する方法であり、その好適な例としては、Apache HTTP Serverのmod_headersモジュールを用いる方法がある。この場合、業務処理部131を、mod_headersモジュールを組み込んだApache HTTP ServerとApache Tomcatで構成し、かつApache HTTP Serverの設定ファイルであるhttp.confへset-Cookieフィールド（311）に格納すべき文字列を設定することで、Apache Tomcatが生成したHTTPレスポンス104をApache HTTP Serverが受け取り、該レスポンス104のset-Cookieフィールド（311）へ設定した文字列が格納される。

本実施例では上記いずれの方法でも適用可能である。ただし、各業務処理部131が付加するCookie名（321）とCookie値（322）の値は、先に説明したように、継続リクエスト振り分けテーブル400の内容に従って、予め運用管理者が適切な値を指定する必要がある。

セッション情報管理部132は自身が稼働している業務サーバ装置112のメモリ上に配置されているセッション情報を他の業務サーバ装置112のセッション情報管理部132へ送信するセッション情報移動処理を行う。また、他の業務サーバ装置112上で稼働しているセッション情報管理部132から送信されたセッション情報を受信し、自身の業務サーバ装置112のメモリ上へ格納するセッション情報受信処理を行う。

ここで、セッション情報の送信処理の仕組みについて具体的に説明する。先に説明したとおり、セッション情報はクライアント毎の処理に使用されるデータを格納したテーブルまたは構造体であり、メモリ上にバイト配列として格納される。セッション情報管理部132はセッション情報を表すバイト配列を、運用管理用ネットワーク114を介して送信可能なデータ形式に変換して、移動対象の業務サーバ装置112上のセッション情報管理部132へ送信する。該セッション情報を受信したセッション情報管理部132は、受信したデータを業務処理部131が可読可能なバイト配列に再度変換し直してメモリ上へ格納する。

送信可能なデータ形式は本特許では特に規定せず、送信側セッション情報管理部132が送信したデータを受信側セッション情報管理部132が解析し、セッション情報として組み立て直せるものならば何でもよい。たとえば、HTTPパケット上のボディ部分にセッション情報に格納された各データを文字列として埋め込み、受信側セッション情報管理部132がその文字列を解析して、セッション情報を組み立てる方法などが考えられる。

また、移動元業務サーバから移動先業務サーバにセッション情報を送信する方法の他に、セッション情報を一度、運用管理装置に送信し運用管理装置を介して移動先業務サーバに送信する方法や、共有サーバなどの共有記憶装置にセッション情報を一時記憶して、移動先業務サーバがそれを受信することにより、セッション情報を移動する方法をとることもできる。

各セッション情報の移動は、それぞれのセッション情報に括り付けられている継続HTTPリクエスト103に対する業務処理を業務処理部131が終了した契機に、セッション情報管理部132によって行われる。以下に、セッション情報管理部132が行う移動処理の流れについて具体的に説明する。

まず、業務処理部131は継続HTTPリクエスト103に対する業務処理を実行後、該継続HTTPリクエスト103と、生成したHTTPレスポンス104をセッション情報管理部132へ渡す。継続HTTPリクエスト103をセッション情報管理部132へ渡す理由は、業務処理部131が該継続HTTPリクエスト103に対する業務処理において使用したセッション情報を移動対象として特定するためである。

通常、業務処理部131はHTTPリクエストに対する業務処理を行う際、使用するセッション情報を特定するために、リクエストに格納されているセッション情報を識別するための文字列を使用する。業務処理部131は各セッション情報を該識別文字列に対応させて管理しており、リクエストから取り出した識別文字列を基に使用するセッション情報を特定する。セッション情報管理部132も、業務処理部131と同様の方法を用いて継続HTTPリクエスト101から識別文字列を取り出し、取り出したセッション情報を移動対象として特定する。この識別文字列をセッション情報識別子と呼ぶことにする。

セッション情報識別子は通常、サーバ識別子と同様、継続HTTPリクエスト103のCookieフィールド（211）やURL文字列に含まれるが、本特許では継続HTTPリクエスト103から業務処理部131およびセッション管理部132がセッション情報を識別できる手段であれば、いずれの方法でも適用可能である。

セッション情報移動処理の流れの説明に戻り、セッション情報管理部132は移動するセッション情報を取り出すと、他の業務サーバ装置112上のセッション情報管理部132へ該セッション情報を送信する。この際、セッション情報の移動先となる業務サーバ装置112を特定する必要がある。この為、セッション情報管理部132は、セッション情報移動先決定部123へ移動先となる業務サーバ装置112を問い合わせ、移動先業務サーバ装置112のアドレスとサーバ識別子を取得し、該業務サーバ装置112を移動先装置として特定する。

なお、移動元業務サーバのセッション情報管理部がセッション情報移動先決定部に移動先となる業務サーバ装置を問い合わせるのではなく、運用管理装置のセッション情報移動先決定部が、再配置の指示とともに移動元業務サーバ装置に移動先業務サーバ装置を通知する方法でもよい。

セッション情報移動先決定部123はセッション情報管理部132からの移動先装置の問い合わせに応じて、移動先となる業務サーバ装置112を選択する処理を行う。選択は、各業務サーバ装置112の負荷と運用管理者の入力値に基づいて行われる。運用管理者の入力値とは、詳しくは後述するが、各業務サーバ装置112間で負荷を均等にするための指示や、特定の業務サーバ装置112を閉塞するための指示であり、入力受付部121を通じて行う。

本実施例では、入力値として各業務サーバ装置112の負荷の比率を表す「負荷比率」を用いる。各業務サーバ装置112に対して負荷の比率を割り振ることで、業務サーバ装置112間でその比率に比例した負荷へ推移するようにセッション情報の再配置が行われる。セッション情報移動先決定部123の移動先選択処理の詳細については後述する。

セッション情報の送信後、移動先業務サーバ装置112上のセッション情報管理部132から移動成功通知を受信すると、セッション情報管理部132はメモリ上から、送信したセッション情報を削除し、業務処理部131から先に受け取ったHTTPレスポンス104のset-Cookieフィールド（311）を上書きする処理を行う。

ここでは、Cookie名（322）として、業務処理部131が割り振るCookie名（322）と同じ値（つまり、従来と同じ値）を、Cookie値（322）として先にセッション情報移動先決定部123から受け取ったサーバ識別子を格納する。このように、Cookie値（322）を移動先業務サーバ装置112のサーバ識別子に書き換えることにより、以降の継続HTTPリクエスト103は負荷分散装置111によってセッション情報を移動した先の業務サーバ装置112へ転送されることになる。

セッション情報の送信後、移動先業務サーバ装置112上のセッション情報管理部132から移動失敗通知を受信すると、業務処理部131から先に受け取ったHTTPレスポンス104を書き換えず、クライアント102へ返す。つまり、この場合のセッション移動は行われず、以降の継続HTTPリクエスト103の切り替えも行われない。

以上が、セッション管理部132が行うセッション情報移動手順である。

上記セッション情報移動処理は、業務サーバ装置112間で負荷に偏りが生じた場合や特定の装置を閉塞する場合などに、運用管理者からの再配置指示を受けて開始する。具体的には、再配置指示を受けたセッション情報移動元決定部122がセッション情報管理部132へ移動指示を送ると、該移動指示を受信したセッション情報管理部132は、以降の全ての継続HTTPリクエスト103に対する業務処理終了後に移動処理を行う。

また、再配置の結果、業務サーバ装置112間の負荷が均等になった等の場合、移動処理を終了する必要がある。この場合、セッション情報移動元決定部122は移動処理を終了するセッション情報管理部132を検出し、該セッション情報管理部132に対して移動終了指示を送る。移動終了指示を受信したセッション情報管理部132は移動処理を終了し、以降の継続HTTPリクエスト103の業務処理後、セッション情報の移動処理を行わない。

また、セッション情報管理部132は他の業務サーバ装置112上のセッション情報管理部132から移動されるセッション情報を受信する処理も行う。受信後、セッション情報管理部132は、自身の業務サーバ装置112上のメモリ上へ、受信したセッション情報を格納し、格納に成功した場合、送信元のセッション情報管理部132へ移動成功通知を行う。

しかし、同じセッション情報識別子を持つセッション情報が既にメモリ上に存在している場合やメモリ不足などの理由で格納に失敗した場合、送信元のセッション情報管理部132へ移動失敗通知を行う。

業務サーバ装置監視部133は自身が稼働している業務サーバ装置112の負荷情報を繰り返し、たとえば定期的に収集し、運用管理装置106上の業務サーバ装置管理部124へ送信する。業務サーバ装置管理部124によって受信された各業務サーバ装置112の負荷情報は運用管理装置106上の業務サーバ装置状態テーブル125へ書き込まれ、セッション情報移動元決定部122とセッション情報移動先決定部123によって参照される。

セッション情報移動元決定部122は業務サーバ装置状態テーブル125に記録されている各業務サーバ装置112の負荷と運用管理者の入力値に従って移動元となる業務サーバ装置112を決定する。同様に、セッション情報移動先決定部123は各業務サーバ装置112の負荷と運用管理者の入力値に従って、移動先となる業務サーバ装置112を決定する。

収集する負荷情報とは例えばCPU使用率やメモリ使用率、メモリ使用量、クライアント102との接続数、クライアント102からリクエストHTTPリクエスト103を受信してからHTTPレスポンス104を送信するまでのレスポンス時間、所定時間内にクライアント102から受信したHTTPリクエスト103の数など、業務サーバ装置112の現在の稼働に関わる様々な情報である。

また、負荷分散装置のレイヤ7パーシステンスを利用して負荷分散を行っている場合、各業務サーバ装置112に配置されているセッション情報の数も負荷指標として用いることができる。各業務サーバ装置112に配置されているセッション情報数が多い場合、必然的に送信される継続HTTPリクエストも多くなり、業務処理を頻繁に行うためである。

本実施例では、業務サーバ装置監視部133が収集する属性としては、上記に例示した情報など、様々なものを用いる事ができるが、本実施形態の例では、負荷情報としてセッション情報の数を例に説明を行う。

業務サーバ装置監視部133は定期的に負荷を収集して、負荷情報を業務サーバ装置管理部124へ送信するが、該収集間隔と、該送信間隔は必ずしも同じである必要はない。たとえば、業務サーバ装置監視部133は一定間隔で負荷を収集し続け、負荷の変動を検知したときのみ負荷情報を業務サーバ装置管理部124へ送信し、それ以外は送信しないという方法も可能である。本実施例では、この収集間隔や送信間隔/送信方法は任意に設定可能である。

運用管理装置106が行う処理について説明する。

図５は、入力受付部121が提供する入力画面の一例である。業務サーバ装置112間でセッション情報を再配置したい場合、運用管理者は入力受付部121を通じて再配置指示を行う。業務サーバ装置アドレスフィールド（511）には、業務システム101上で現在稼働している業務サーバ装置112の一覧が示される。負荷比率フィールド（512）は、各業務サーバ装置112間において再形成する負荷の比率を示したもので、運用管理者が任意の値を入力する。

尚、先に述べたように、本実施形態では、各業務サーバ装置112の負荷として、配置されているセッション情報の数を用いる。たとえば、図5の例のように入力した場合、4台の業務サーバ装置112間において、セッション情報数が均等な比率に再配置されるように、各業務サーバ装置112間でセッション情報の移動が繰り返し行われる。

一方、図5において、192.168.1.10:80をアドレスとして持つ業務サーバ装置112を閉塞させたい場合、0:1:1:1と入力することにより、該業務サーバ装置112上の全てのセッション情報が他の3台の業務サーバ装置112へ、均等な比率になるように移動することになる。また、192.168.1.10:80をアドレスとして持つ業務サーバ装置112が他の3台の装置よりも性能が良い、たとえば搭載しているメモリ容量が大きいなどの理由で特定の業務サーバ装置112の負荷を他の装置よりも高くしたい場合、2:1:1:1のように入力することで、異なる負荷比率を実現することもできる。

本実施形態の説明では、運用管理者による明示的な指示に呼応してセッション情報の再配置を行うことを想定しているが、セッション情報再配置の開始を自律的に行うことも本実施例に適用可能である。自律的に行うとは、運用管理者の明示的な指示により再配置を開始するのではなく、各業務サーバ装置112の負荷が基準となる負荷比率を逸脱した場合、それを運用管理装置106上のモジュールが検知して、自動的にセッション情報再配置の開始を運用管理者に代わって指示することである。

運用管理装置106上のモジュールとはたとえば、業務サーバ装置管理部124であり、この場合、運用管理者は入力受付部121から基準となる負荷比率を最初に入力すれば、以降、業務サーバ装置管理部124は業務サーバ装置状態テーブル125を繰り返し、たとえば定期的に監視する。各業務サーバ装置112の負荷の割合が先に運用管理者が入力した負荷比率の逸脱を検知した場合、業務サーバ装置管理部124はセッション情報移動元決定部122へ再配置指示を送ることにより、セッション情報の再配置処理を開始する。

運用管理者が負荷比率を入力してOKボタン513を押下すると、入力受付部121はセッション情報移動元決定部122へ再配置命令を送信する。

セッション情報移動元決定部122は運用管理者が入力した負荷比率フィールド（512）の値と、現在の各業務サーバ装置112の負荷が記録されている業務サーバ装置状態テーブル125を参照して移動元となる業務サーバ装置112を単数または複数決定し、該業務サーバ装置112へ移動指示を送信する。ここでは、まず、業務サーバ装置状態テーブル125について説明する。

図６は業務サーバ装置状態テーブル125の構造を示す一例である。業務サーバ装置状態テーブル125は現時点における各業務サーバ装置112の負荷情報を格納したテーブルである。業務サーバ装置アドレスフィールド（611）は現在稼働している業務サーバ装置112のアドレスが格納されている。サーバ識別子フィールド（612）は各業務サーバ装置112のサーバ識別文字列である。負荷フィールド（613）は現在稼働中の各業務サーバ装置の負荷情報であり、本実施例では、各業務サーバ装置に配置されているセッション情報の数である。該負荷フィールド（613）の内容は業務サーバ装置管理部124によって、繰り返し、たとえば各業務サーバ装置監視部133から負荷情報を受信した契機で更新される。

次に、セッション情報移動元決定部122が行う、移動元業務サーバ装置112の決定手順について説明する。

セッション情報移動元決定部122は、セッション情報の移動元となる業務サーバ装置112を決定するために、まず、業務サーバ装置状態テーブル125を参照し、現時点における各業務サーバ装置112の負荷の合計値を負荷比率フィールド（512）の値に基づいて再配分した値を、各業務サーバ装置112について算出する。以降、この値を「目標負荷値」と呼ぶことにする。たとえば、運用管理者の入力値が図5の例であり、各業務サーバ装置112のセッション情報数が図6の例の場合、各業務サーバ装置112の目標負荷値は、4台の業務サーバ装置112共に（120+180+40+20）/（1+1+1+1） × 1 = 90となる。

セッション情報移動元決定部122は、算出した目標負荷値よりも、現在の負荷値が上回っている業務サーバ装置112に対して、セッション情報の移動元として決定する。たとえば、先の例だと192.168.1.10:80（セッション情報数=120、目標負荷値=90）と192.168.1.11:80（セッション情報数=180、目標負荷値=90）をアドレスとして持つ業務サーバ装置112が移動元業務サーバ装置112として決定される。

セッション情報移動元決定部122は移動元として決定した業務サーバ装置112上のセッション情報管理部132へ移動指示を送信し、移動指示を受けたセッション情報管理部132は自身の業務サーバ装置112上のセッション情報の移動を開始する。

各セッション情報管理部132へ移動指示を送信後、各業務サーバ装置112間の負荷値が負荷比率513に等しくなれば、セッション情報の再配置を終了させる必要がある。このため、セッション情報移動元決定部122は移動指示を出した各セッション情報管理部132に対して、繰り返し、たとえば定期的に移動処理を終了させるための判定処理を行う。

以下に、セッション情報移動元決定部122が行う判定処理について説明する。セッション情報移動元決定部122は、移動指示を出した各業務サーバ装置112に対して、該業務サーバ装置112の現在の負荷値と、その時点で算出した目標負荷値を比較し、現在の負荷値が目標負荷値と等しくなった、または下回った場合、該業務サーバ装置112上のセッション情報管理部132に対して移動終了指示を送信する処理を行う。

セッション情報移動元決定部122は、現在移動処理を行っている全てのセッション情報管理部132に対して、この判定処理を繰り返し行い、全てのセッション情報管理部132が移動処理を終了すれば再配置を終了し、入力受付部121へ再配置終了を表すイベントを発行する。

尚、終了判定処理においては、現在の負荷値と目標負荷値が必ずしも一致するまで移動処理を行う必要はなく、たとえば、業務サーバ装置112の現在の負荷と目標負荷値の差がある一定値以下となった時点で、移動処理を終了すると判定してもよい。これは、移動処理自体、負荷のかかる処理であるため、移動処理をできるだけ早く終わらせたい場合に都合がよい。以降、この値を「許容誤差値」と呼ぶ。

本実施例において、この値は任意に設定可能である。たとえば、許容誤差値を「目標負荷値×0.1」と設定し、業務サーバ装置112-Aの現在のセッション情報数が120、目標負荷値が110の場合、許容誤差値は110×0.1=11となり、セッション情報数と目標負荷値の差はこの値よりも小さいため、移動処理を終了させる。このため、セッション情報移動元決定部122は該業務サーバ装置112上のセッション情報管理部132へ移動終了指示を送信する。

セッション情報移動先決定部123は各業務サーバ装置112上のセッション情報管理部132からの移動先装置問い合わせに対して、セッション情報の移動先となる業務サーバ装置112を決定し、該業務サーバ装置112のアドレスとサーバ識別子を返す処理を行う。

ここで、セッション情報移動先決定部123の移動先決定方法について説明する。

先に説明したように、各業務サーバ装置112上のセッション情報管理部132はセッション情報を移動する際、移動先となる業務サーバ装置112を特定するために、セッション情報移動先決定部123に対して移動先装置の問い合わせを行う。移動先装置問い合わせを受けたセッション情報移動先決定部123は、業務サーバ装置状態テーブル125に記録されている各業務サーバ装置112の負荷情報と、運用管理者の入力した負荷比率フィールド（512）の値から目標負荷値を算出し、算出した値より目標負荷値よりも、現在の負荷値が下回っている業務サーバ装置112を単数または複数、移動先候補装置として選択する。

たとえば、運用管理者の入力値が図５、各業務サーバ装置112の負荷（セッション情報数）が図６の場合、移動先候補装置として、192.168.1.12:80をアドレスとして持つ業務サーバ装置112（目標負荷値=90、セッション情報数40）と192.168.1.13:80をアドレスとして持つ業務サーバ装置112（目標負荷値=90、セッション情報数20）が選択される。

セッション情報移動先決定部123は移動先候補装置の中から任意の1台を選択し、移動先装置として決定する。本実施形態では、各移動先候補装置の中で最小の負荷、つまりここでは、配置されているセッション情報の数が最小である装置を移動先装置として決定する。もし、最小の負荷を持つ装置が複数台存在する場合、その中から任意の一台を選択する。

尚、本実施例においては、移動先候補装置の中から移動先を決定する方式については特に規定しない。上記方式以外に、たとえば、移動候補装置間の負荷値の逆数比に応じて移動先装置を決定するという方式なども本実施例に適用可能である。

以上、セッション情報移動元決定部122とセッション情報移動先決定部123は運用管理者の入力した負荷比率へ推移するように、現在の負荷情報を格納した業務サーバ装置状態テーブル125に基づいて、セッション情報の移動元装置の決定、該移動元装置に対するセッション情報移動処理の終了、及び移動先装置の決定を適切に行う。

上記実施例では、管理者の再配置指示に応じて再配置をおこなうが、あらかじめ負荷の閾値を決めておき、取得した負荷値をこの閾値情報と突き合わせを行い、閾値を超えている場合には、管理者の指示によらず上記再配置指示が送信されるようにしてもよい。この負荷の閾値を示す情報は記憶部に格納しておく。

上記閾値の情報は、業務サーバ装置のメモリとうの使用量に対する、絶対的な閾値を設定したり、複数の業務サーバ装置間の負荷の差を閾値として設定したり、複数の業務サーバ装置間の負荷の割合を閾値として設定することできる。

たとえば図６の例で、各業務サーバ間のセッション情報数の差が１６０を超えることを閾値とすれば、サーバ２に対するセッション数があと１増えれば、サーバ２とサーバ４とのセッション数の差が１６０を超え、セッションの再配置が開始される。

また、各業務サーバ間のセッション情報数の割合が１：１０以上であることを閾値とすれば、サーバ２のセッション数があと２０増加すれば、サーバ２のセッション数は２００となり、サーバ４のセッション数２０との割合が１：１０以上となるため、セッションの再配置が開始される。

これらは、セッション数を閾値とすることに限られず、CPU使用率やメモリ使用率、メモリ使用量、クライアント102との接続数、クライアント102からリクエストHTTPリクエスト103を受信してからHTTPレスポンス104を送信するまでのレスポンス時間、所定時間内にクライアント102から受信したHTTPリクエスト103の数など、業務サーバ装置112の現在の稼働に関わる様々な情報を閾値として用いることができる。

これらの負荷値の情報は、業務サーバから収集してもよいし、負荷分散装置から収集してもよい。セッション数などについては負荷分散装置から収集する方が収集が容易になる。

以下、本実施形態における各処理動作について図７〜図１１のフローチャートを参照しながら具体的に説明する。

図７はセッション情報管理部132が他の業務サーバ装置112上のセッション情報管理部132へセッション情報を移動する「セッション情報移動処理」についての手順を示したものである。尚、ここではセッション情報の移動元をセッション情報管理部132-A、移動先をセッション情報管理部132-Bと記述する。

セッション情報管理部132-Aはセッション情報移動元決定部122から移動指示を受けて処理を開始し、該セッション情報移動元決定部122から移動終了指示を受けるまで（S1010）、S1020〜S1080の処理を繰り返し、業務処理部131が継続HTTPリクエスト103を受信する毎に行う。

まず、セッション情報管理部132-Aは業務処理部131からHTTPリクエスト103とHTTPレスポンス104を受信し、HTTPリクエスト103のヘッダフィールドに含まれるセッション情報識別子に対応するセッション情報を、自身の業務サーバ装置112のメモリから取り出す（S1020）。

次に、セッション情報管理部132-AはS1020で取り出したセッション情報の移動先となる業務サーバ装置112をセッション情報移動先決定部123へ問い合わせ（S1030）、移動先業務サーバ装置112のアドレスとサーバ識別子を該セッション情報移動先決定部123から受信する（S1040）。

次に、S1020で取り出したセッション情報を、S1040で取得したアドレスを持つ業務サーバ装置112上のセッション情報管理部132-Bへ送信し（S1050）、セッション情報管理部132-Bから移動成功通知を受信すると（S1060）、セッション情報管理部132-Aは送信したセッション情報を同装置のメモリ上から消去し（S1070）、S1020で業務処理部131から受信したHTTPレスポンス1040のset-Cookieフィールド(311)へ、Cookie名として継続リクエスト振り分けテーブル400のリクエスト識別子フィールド（411）に記述されている文字列を、Cookie値としてS1040で取得したサーバ識別文字列を書き込み（S1080）、該HTTPレスポンス104をクライアントへ送信する（S1090）。

図８はセッション情報管理部132が他の業務サーバ装置112上のセッション情報管理部132からセッション情報を受信する「セッション情報受信処理」についての手順を示す例である。尚、ここでもセッション情報の移動元をセッション情報管理部132-A、移動先をセッション情報管理部132-Bと記述する。

セッション情報管理部132-Bはセッション情報管理部132-Aからセッション情報を受信すると（S1110）、自身の業務サーバ装置112上のメモリへ該セッション情報の格納を試みる。格納に成功した場合（S1120）、セッション情報管理部132-Aへ移動成功通知を送信する（S1130）。メモリ上に既に同一セッション識別子を持つセッション情報が既に存在するなどの理由で格納に失敗した場合、セッション情報管理部132-Aへ移動失敗通知を送信する（S1140）。

図９はセッション情報移動元決定部122がセッション情報の移動元となる業務サーバ装置112を決定する「移動元装置選択処理」についての手順を示したものである。

セッション情報移動元決定部122は業務サーバ装置状態テーブル125から、各業務サーバ装置の現在の負荷値を取得し（S1210）、入力受付部121から運用管理者が入力した負荷比率を取得する（S1220）。次に、各業務サーバ装置112に対して以下に示すS1240〜S1260までの処理を行う（S1230）。尚、ここでは処理対象中の業務サーバ装置112を業務サーバ装置112-Nと記述する。

まず、S1210で取得した各業務サーバ装置112の負荷値とS1220で取得した負荷比率から、業務サーバ装置112-N の目標負荷値を算出する（S1240）。S1240で算出した目標負荷値よりも現在の業務サーバ装置112-N の負荷値が上回っている場合（S1250）、該業務サーバ装置112-N上のセッション情報管理部132に対して移動指示を送信する（S1260）。

図１０はセッション情報移動元決定部122が、移動指示を送信した各業務サーバ装置112に対して、移動終了を判定し、終了と判断した業務サーバ装置112上のセッション情報管理部132へ移動終了指示を送信する「移動終了判定処理」についての手順を示す例である。

セッション情報移動元決定部122は業務サーバ装置状態テーブル125から、各業務サーバ装置112の現在の負荷値を取得し（S1310）、運用管理者が入力した負荷比率を入力受付部121から取得する（S1320）。次に、全ての業務サーバ装置112上のセッション情報管理部132が移動処理を終了するまで（S1330）、移動処理を行っている各セッション情報管理部132に対し、繰り返し、例えば一定間隔で次に示すS1350〜S1370までの処理を行う（S1340）。

尚、ここでは処理対象中のセッション情報管理部をセッション情報管理部132-Nと記述する。まず、S1310で取得した各業務サーバ装置112上の負荷値とS1320で取得した負荷比率から、セッション情報管理部132-Nが稼働している業務サーバ装置112の目標負荷値を算出する（S1350）。該業務サーバ装置112の負荷値が、S1350で算出した業務サーバ装置112の目標負荷値と許容誤差値の和以下である場合（S1360）、該セッション情報管理部132-Nへ移動終了指示を送信する（S1370）。

図１１はセッション情報移動先決定部123が、移動処理を行っているセッション情報管理部132からの移動先装置問い合わせに対して、移動先となる業務サーバ装置112を決定して、そのアドレスとサーバ識別子を通知する「移動先装置選択処理」についての手順を示したものである。

セッション情報移動先決定部123は、移動処理を行っているセッション情報管理部132から移動先装置問い合わせを受信すると、業務サーバ装置テーブル125から各業務サーバ装置112に配置されている現在の負荷値を取得し（S1410）、入力受付部121から負荷比率を取得する（S1420）。次に、各業務サーバ装置112に対して以下に示すS1440〜S1460までの処理を行う（S1430）。

尚、ここでは処理対象中の業務サーバ装置112を業務サーバ装置112-Nと記述する。まず、S1410で取得した各業務サーバ装置112の負荷値とS1420で取得した負荷比率から、業務サーバ装置112-Nの目標負荷値を算出する（S1440）。業務サーバ装置112-Nの現在の負荷値が、S1440で算出した目標負荷値よりも少ない場合（S1450）、該業務サーバ装置112-Nを移動先候補装置として選択する（S1460）。次に、各業務サーバ装置112に対するS1460の処理で、移動先候補装置として選択された装置の中から、配置されているセッション情報数が最小である装置を移動先装置として決定する。

もし、移動先装置が複数存在する場合は、その中から任意の一台を移動先装置として決定する(S1470)。そして、S1410で移動先装置問い合わせを行ったセッション情報管理部132に対して、S1470で決定した業務サーバ装置112のアドレスとサーバ識別子を送信する（S1480）。

最後に、各業務サーバ装置112上のセッション情報管理部132とセッション情報移動元決定部122、及びセッション情報移動先決定部123が連携して行うセッション情報再配置処理の全体の流れについて、図１２〜図１３を参照しながら具体的に説明する。

まず、業務システム101へ新たに業務サーバ装置112を増設した際、各業務サーバ装置112間で均等な負荷、つまり均等なセッション情報数を実現するために、セッション情報を再配置する流れについて具体例を示しながら説明する。

図１２は、業務サーバ装置112-A、業務サーバ装置112-B、業務サーバ装置112-Cから構成される業務システム101に対して新たに業務サーバ装置112-Dを増設した場合の再配置処理について示す例である。

業務サーバ装置112-A、112-B、112-C、112-Dに予め配置されているセッション情報数は、それぞれ140個、110個、70個、0個とし、各業務サーバ装置112へ1秒当たりに送信される継続HTTPリクエストの件数は、該業務サーバ装置112に配置されているセッション情報数の20%とする。

たとえば、業務サーバ装置112-A（セッション情報数=140）には1秒当たり140×0.2=28件のHTTPリクエスト103が発生することになる。尚、ここでは説明を簡単にするために、新規HTTPリクエスト103は発生しないものと仮定する。

許容誤差値は各業務サーバ装置112の目標負荷値の15%とする。たとえば、現在、移動処理を行っている業務サーバ装置112-Aのセッション情報数が90、目標負荷値が80の場合、許容誤差値は80×0.15=12であり、現在のセッション情報数（=90）が目標負荷値+許容誤差値（90+12=92）以下であるため、セッション情報元移動決定部122は業務サーバ装置112-A上のセッション情報管理部132に対して移動終了指示を送信する。

セッション情報元移動決定部122の移動終了判定処理は1秒間隔で繰り返し行うものとする。また、各業務サーバ装置112上の業務サーバ装置監視部133は配置されているセッション情報数に変動が生じる毎に業務サーバ装置管理部124に対して負荷情報を送信し、業務サーバ装置管理部124は各業務サーバ装置監視部133から負荷情報を受信するタイミングで業務サーバ装置状態テーブル125を更新するものとする。

運用管理者は負荷比率として1:1:1:1を入力受付部121から入力し、OKボタン513を押下すると、再配置処理が開始される。該再配置処理が開始される時刻Tを0とする。

図１２ＡはT=0（秒）〜1（秒）までの処理の流れについて、図１２ＢはT=1（秒）〜2（秒）までの処理の流れについて、図１２ＣはT=2（秒）〜3（秒）までの処理の流れについて示した図である。まず、図１２Ａを参照しながら、T=0（秒）〜1（秒）までに行われる処理の流れについて説明する。

運用管理者からの再配置指示後、セッション情報移動元決定部122は移動元装置選択処理を行う。該処理では各業務サーバ装置112の目標負荷値が、配置されているセッション情報数よりも少ない値を持つ装置が移動元として決定されるため、ここでは業務サーバ装置112-A（セッション情報数：140、目標負荷値：80）と業務サーバ装置112-B（セッション情報数：110、目標負荷値：80）が移動元装置として決定され、該業務サーバ装置112へ移動指示が送信される。

業務サーバ装置112-A、112-B上のセッション情報管理部132は、各継続HTTPリクエストに対する業務処理を行うタイミングで、該HTTPリクエスト103に括り付けられているセッション情報の移動処理を行う。

T=0（秒）〜1(秒)の間に業務サーバ装置112-Aへ送信される継続HTTPリクエストの数は140×0.2 = 28件であるので、28個のセッション情報が移動される。同様に、業務サーバ装置112-Bでは110×0.2 = 22件のセッション情報が移動される。各移動処理では、セッション情報管理部132はセッション情報移動先決定部123に対して移動先装置の問い合わせを行う。

セッション情報移動先決定部123は、移動元装置の問い合わせを受信すると、移動先装置選択処理を行う。該処理では各業務サーバ装置112に配置されているセッション情報数が、自身の目標負荷値よりも少ない値を持つ装置がセッション情報移動先候補装置として選択される。ここでは業務サーバ装置112-C（セッション情報数：70、目標負荷値：80）と業務サーバ装置112-D（セッション情報数：0、目標負荷値：80）が移動先候補装置として選択される。該候補装置の中で、配置されているセッション情報が最も少ない業務サーバ装置112が移動先として選択されるため、T=0（秒）〜1(秒)ではすべての移動先装置問い合わせに対して、業務サーバ装置112-Dを移動先として返答する。

つまり、ここでは業務サーバ装置112-Aから28個、業務サーバ装置112-Bから22個、計50個のセッション情報が業務サーバ装置112-Dへ移動される。

図１２Ｂは時刻T=1（秒）〜2（秒）までの処理の流れについて示したものである。

セッション情報移動元決定部122は1秒間隔で移動終了判定処理を行っている。該処理では移動処理を行っている各業務サーバ装置112の中で、各業務サーバ装置112に配置されているセッション情報数が、目標負荷値と許容誤差値の和以下の値を持つ業務サーバ装置112に対して移動終了指示を送信する。

ここでは、業務サーバ装置112-Bに対して移動終了指示を送信する。業務サーバ装置112-Bに配置されているセッション情報数は88であり、目標負荷値（=80）と許容誤差値（80×0.15=12）の和（80+12=92）以下となったからである。移動終了指示を受信した業務サーバ装置112-Bは移動処理を終了する。

一方、業務サーバ装置112-Aは引き続きセッション情報移動処理を行う。時刻T=1（秒）〜2（秒）では、業務サーバ装置112-Aへは112×0.2≒22件の継続HTTPリクエスト103が送信されているので、セッション情報移動処理が22回行われる。先程と同様、セッション情報移動先決定部123は各移動処理に対する移動元装置問い合わせに対して、移動先業務サーバ装置112を決定する。

移動先候補装置はここでも業務サーバ装置112-Cと業務サーバ装置112-Dが選択され、各装置に配置されているセッション情報数はそれぞれ70個、50個であるので、最初の20件の移動先装置問い合わせに対しては、業務サーバ装置112-Dを移動先として返答する。次の2件の移動先問い合わせに対しては、それぞれ、業務サーバ装置112-D、業務サーバ装置112-Cを移動先として返答する。

つまり、ここでは1個のセッション情報が業務サーバ装置112-Cへ移動され、20+1=21個のセッション情報が業務サーバ装置112-Dへ移動される。

図１２Ｃは時刻T=2〜3までの処理の流れについて示したものである。

セッション情報移動元決定部122は移動終了判定処理を行い、業務サーバ装置112-Aに対して移動終了指示を送信する。業務サーバ装置112-Aに配置されているセッション情報数は90であり、目標負荷値（=80）と許容誤差値（90×0.15≒14）の和（80+14=94）以下となったからである。移動終了指示を受信した業務サーバ装置112-Aは移動処理を終了する。

ここで、移動指示を送信した全ての業務サーバ装置112が移動処理を終了したので、再配置処理を終了する。

以上が、各業務サーバ装置112へセッション情報を均等に再配置する処理の流れである。

次に、業務システム101から1台の業務サーバ装置112を閉塞した際の再配置処理について説明する。

図１３は、業務サーバ装置112-A、B、Cから構成される業務システム101に対して業務サーバ装置112-Aを閉塞した場合の再配置処理が行われる例である。

各業務サーバ装置112-A、112-B、112-Cに予め配置されているセッション情報数は、それぞれ20個、20個、10個とし、各業務サーバ装置112へ1秒当たりに送信される継続HTTPリクエストの件数は、該業務サーバ装置112に配置されているセッション情報数の40%とする。尚、ここでも説明を簡単にするため、新規HTTPリクエスト103は発生しないものとする。

許容誤差値は各業務サーバ装置112の目標負荷値の15%、セッション情報移動元決定部122の終了判定処理は1秒間隔で繰り返し行う。また、各業務サーバ装置112上の業務サーバ装置監視部133は配置されているセッション情報数に変動が生じる毎に業務サーバ装置管理部124に対して負荷情報を送信し、業務サーバ装置管理部124は各業務サーバ装置監視部133から負荷情報を受信するタイミングで業務サーバ装置状態テーブル125を更新するものとする。

運用管理者は負荷比率として0:1:1を入力受付部121から入力し、OKボタン513を押下すると、再配置処理が開始される。ここでも先ほどと同様に、再配置処理が開始される時刻Tを0とする。

図１３ＡはT=0（秒）〜1（秒）までの処理の流れについて示したものである。

運用管理者からの再配置指示後、セッション情報移動元決定部122は、移動元装置選択処理を行う。ここでは目標負荷値が配置されているセッション情報数よりも少ない値を持つ、業務サーバ装置112-A（セッション情報数：20、目標負荷値：0）が移動元として決定され、該業務サーバ装置112へ移動指示が送信される。

業務サーバ装置112-A上のセッション情報管理部132は、各継続HTTPリクエストに対する業務処理を行うタイミングで、該HTTPリクエスト103に括り付けられているセッション情報の移動処理を行う。

T=0（秒）〜1（秒）の間に業務サーバ装置112-Aへ送信される継続HTTPリクエストの数は20×0.4=8件であるので、8個のセッション情報が移動される。各移動処理では、セッション移動先決定部123に対して移動先装置問い合わせが行われる。セッション情報移動先決定部123は、セッション情報管理部132から移動先装置問い合わせを受信すると、セッション移動先選択処理を行う。

ここでは、配置されているセッション情報数が目標負荷値よりも少ない値を持つ業務サーバ装置112-B（セッション情報数：20、目標負荷値：25）と業務サーバ装置112-C（セッション情報数：10、目標負荷値25）が移動先候補装置として選択される。該候補装置の中で、配置されているセッション情報数が最も少ない業務サーバ装置112が移動先として決定されるため、T=0（秒）〜1（秒）ではすべての移動先問い合わせに対して業務サーバ装置112-Cを移動先として返答する。つまり、ここでは業務サーバ装置112-Aから8個のセッション情報が業務サーバ装置112-Cへ移動される。

図１３ＢはT=1（秒）〜4（秒）までの処理の流れについて示したものである。

T=1（秒）〜4（秒）の間において、セッション情報移動元決定部122は1秒間隔で移動終了判定処理を行っているが、この間は業務サーバ装置112-A上のセッション情報管理部132に対して移動終了指示を送信しない。業務サーバ装置112-Aの許容誤差値（0×0.15=0）と目標負荷値（=0）の和は0であるので、配置されているセッション情報数が0になるまで移動処理を行うからである。

T=1（秒）〜2（秒）の間では業務サーバ装置112-Aへは12×0.4≒5件の継続HTTPリクエストが送信され、移動処理が5回行われる。各移動処理において送信される移動先装置の問い合わせをセッション情報移動先決定部123が受信すると、移動先装置選択処理を行い、業務サーバ装置112-B（セッション情報数：20、目標負荷値：25）、112-C（セッション情報数：18、目標負荷値：25）を移動先候補装置として選択する。

T=1(秒)の時点での業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ20、18個であるから、最初の2件の問い合わせに対しては、業務サーバ装置112-Cを移動先装置として返答する。この時点で業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ20個、20個である。

次の3件の問い合わせに関しては、ここでは、それぞれの問い合わせに対して、業務サーバ装置112-C、業務サーバ装置112-B、業務サーバ装置112-Bを移動先装置として返答するものとする。つまり、T=1（秒）〜2秒の間では、業務サーバ装置112-Bへ2個、業務サーバ装置112-Cへ3個のセッション情報が移動されたことになる。

T=2（秒）〜3（秒）の間では業務サーバ装置112-Aへは7×0.4≒3件の継続HTTPリクエストが送信され、移動処理が3回行われる。各移動処理において送信される移動先装置問い合わせをセッション情報移動先決定部123が受信すると、移動先装置選択処理を行い、業務サーバ装置112-B（セッション情報数：22、目標負荷値：25）、112-C（セッション情報数：21、目標負荷値：25）を移動先候補装置として選択する。

T=2(秒)の時点での業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ22、21個であるから、最初の1件の問い合わせに対しては、業務サーバ装置112-Cを移動先装置として返答する。この時点で業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ22個、22個である。

次の2件の問い合わせに関しては、ここでは、それぞれの問い合わせに対して、業務サーバ装置112-C、業務サーバ装置112-Bを移動先装置として返答する。つまり、T=2（秒）〜3秒の間では、業務サーバ装置112-Bへ1個、業務サーバ装置112-Cへ2個のセッション情報が移動されたことになる。

T=3（秒）〜4（秒）の間では業務サーバ装置112-Aへは4×0.4≒2件の継続HTTPリクエストが送信され、移動処理が2回行われる。各移動処理において送信される移動先装置問い合わせをセッション情報移動先決定部123が受信すると、移動先装置選択処理を行い、業務サーバ装置112-B（セッション情報数：23、目標負荷値：25）、112-C（セッション情報数：23、目標負荷値：25）を移動先候補装置として選択する。

T=3(秒)の時点での業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ23個ずつであるから、2件の問い合わせに対しては、ここでは、業務サーバ装置112-C、112-Bを移動先装置として返答する。

図１３ＣはT=4（秒）〜6（秒）までの処理の流れについて示したものである。

T=4（秒）〜5秒の間では業務サーバ装置112-Aへは2×0.4≒1件の継続HTTPリクエストが送信され、移動処理が1回行われる。移動処理において送信される移動先装置問い合わせをセッション情報移動先決定部123が受信すると、移動先装置選択処理を行い、業務サーバ装置112-B（セッション情報数：24、目標負荷値：25）、112-C（セッション情報数：24、目標負荷値：25）を移動先候補装置として選択する。

T=4(秒)の時点での業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ24個ずつであるから、1件の問い合わせに対しては、ここでは、業務サーバ装置112-Cを移動先装置として返答する。

T=5（秒）〜6（秒）の間では業務サーバ装置112-Aへは1件の継続HTTPリクエストが送信され、移動処理が1回行われる。移動処理において送信される移動先装置問い合わせをセッション情報移動先決定部123が受信すると、移動先装置選択処理を行い、業務サーバ装置112-B（セッション情報数：24、目標負荷値：25）、112-C（セッション情報数：25、目標負荷値：25）を移動先候補装置として選択する。

T=5(秒)の時点での業務サーバ装置112-B、112-Cのセッション情報数はそれぞれ24個、25個であるから、1件の問い合わせに対しては、業務サーバ装置112-Bを移動先装置として返答する。

T=6（秒）の時点でセッション情報移動元決定部122が行った移動終了判定処理において、業務サーバ装置112-Aのセッション情報数が0になったので、該業務サーバ装置112上のセッション管理部132へ移動終了指示を送信する。

ここで、移動指示を送信したすべての業務サーバ装置112が移動処理を終了したので、再配置処理を終了する。以上が、特定の業務サーバ装置112を閉塞する際にセッション情報の再配置を行う処理の流れである。

以上、本実施の形態について説明したが、本実施の形態によれば、継続リクエストに括り付けられているセッション情報を他の業務サーバ装置へ移動し、移動先装置のサーバ識別子を該継続リクエストに対するHTTPレスポンスヘッダに埋め込むことで、負荷分散装置による継続リクエストに対する転送先業務サーバ装置の切り替えを実現できる。

この切り替え機能を利用する事により、たとえば業務サーバ装置間で負荷に偏りが生じてしまった場合、セッション情報を適切な割合で再配置することで、継続リクエストに対する均等な負荷分散を実現することができる。

また、特定の業務サーバ装置を閉塞したい場合、該業務サーバ装置の全セッション情報を他の業務サーバ装置へ移動し、各セッション情報に括り付けられている継続HTTPリクエストを移動先業務サーバへ切り替える事で、セッション情報を失うことなく閉塞することができる。

本実施例では、セッション情報を扱うステートフルな業務サービスが稼働しており、かつレイヤ7パーシステンスを利用して負荷分散を行っている業務システムにおいて、複数の業務サーバ間で負荷に偏りが生じた場合、継続リクエストに対する転送先業務サーバの切り替えを行うことで、均等な負荷を実現すること、特に、業務システム全体の負荷が上昇した等の理由で新たにマシンを増設する場合、既存マシンに対して転送されている継続リクエストを増設マシンへ切り替えて転送することにより、既存マシンの負荷の軽減を実現すること、加えて、特定のマシンを閉塞する際に、閉塞対象マシンへ転送される全継続リクエストを他のマシンへ切り替えて転送することで、セッション情報を失わずに、かつ閉塞時間の短縮化を実現することを課題とする。

複数の業務サーバ装置と負荷分散装置から構成される業務システムにおいて、
クライアントから送信された継続リクエストに対する負荷分散制御方法であって、前記継続リクエストに対する業務処理を前記業務サーバ装置が実行後、前記継続リクエストに括り付けられているセッション情報を他の業務サーバ装置へ移動し、前記移動先サーバ装置を識別する文字列を継続リクエストに対するレスポンスへ埋め込み、前記クライアントへ前記レスポンスを返すことによって、以降の継続リクエストの転送先業務サーバ装置を切り替えることを特徴とする。

また、前記複数の業務サーバ装置の負荷を監視する監視手段と、前記監視手段によって前記各業務サーバ装置の負荷を記憶する記憶手段と、セッション情報の移動元/移動先となる業務サーバ装置を決定する制御処理手段と、運用管理者から負荷比率を受け付ける入力受付手段と、から構成される運用管理システムであって、前記制御処理手段は、前記記憶手段に記録された前記複数の業務サーバの負荷と前記入力受付手段から運用管理者によって入力された負荷比率を元に、セッション情報の移動元、移動先となる業務サーバ装置を決定し、決定した業務サーバ装置へ移動指示を行うことで、前記各業務サーバ装置間の負荷が、前記運用管理者によって入力された負荷比率へ推移するように、継続リクエストの転送先業務サーバ装置の切り替えを行う。

上記実施の形態は本発明の理解を容易にするものであり、本発明を限定して解釈するためのものではない。

たとえば、本実施例はブレードサーバにも適用可能である。ブレードサーバとは、1つの筐体で複数台のサーバを搭載させたものであり、具体的には１枚のボードにCPUやメモリを搭載し、1台のサーバと同じ機能を持たせ、このボードを筐体に複数枚挿すことにより実現される。これにより、従来のサーバと比較して単位面積あたりの設置台数が増えるほか、重量と消費電力が大きく削減できるという利点がある。

本実施例をブレードサーバに適用した例では、情報システム101は一台のブレードサーバであり、各業務サーバ装置112はブレードに挿さるボードである。負荷分散装置111はブレードサーバ装置と別の装置であってもよいし、1枚のボードにインストールされたソフトウェアの負荷分散装置であってもよい。同様に、運用管理装置106はブレードサーバと別の装置であってもよいし、1枚のボードを運用管理用マシンとして利用してもよい。

想定される実施例としては、現在稼働中のボードの負荷が上昇した場合、稼働停止中の待機ボードを起動し、運用管理者は入力受付部121を通じて再配置指示を行う。それ以降のセッション情報再配置処理の流れは本実施形態の例で説明した流れと同様である。

また、本実施例は仮想計算機にも適用可能である。仮想計算機とは、ハードウェア（CPU、メモリ、デバイスなど）のエミュレーションをソフトウェアで行い、実マシンと同様の処理（例えばOS等）が可能なソフトウェアである。複数の仮想計算機を稼働させるためのハードウェアをホスト計算機と呼ぶ。典型的には一台のホスト計算機に複数の仮想計算機を稼働させ、各仮想計算機に業務サーバミドルウェアをインストールする。

仮想計算機を適用することの利点として、先に説明したブレードサーバと同様、省スペース化、軽量化、省電力化が挙げられる。

本実施例を仮想計算機に適用した例では、情報システム101は一台のホスト計算機であり、各業務サーバ装置112はホスト計算機上で稼働する仮想計算機である。負荷分散装置のうち111はホスト計算機と別の装置であってもよいし、１つの仮想計算機上にインストールされたソフトウェアの負荷分散装置であってもよい。

例えば、Webサーバの場合、Webサーバの負荷が増加して、負荷が所定の閾値を超えた場合に、Webサーバをスケールアウトして、新たな仮想的なWebサーバを作成する。そして本実施例による、セッション情報の移動を行う負荷分散を実施することで、新たなWebサーバに対しても負荷が均等に分散することになる。この場合、運用管理装置は新たなWebサーバの増加に応じて、セッション情報の移動指示を送信する
また、複数のWebサーバの負荷が全体的に減少して来た場合には、全体の負荷が所定の閾値を下回った場合に、本実施例におけるセッション情報の移動を実施して、１つのWebサーバのセッションをゼロにするような、セッション移動指示を行う。これによりセッション数がゼロになり処理を行わなくなったWebサーバについては、スケールインして、消去してしまえば、計算機の資源を有効に利用することができる。

同様に、運用管理装置106はホスト計算機と別の装置であってもよいし、１つの仮想計算機を運用管理装置106として利用してもよい。想定される実施例としては、現在稼働中の仮想計算機の負荷が上昇した場合、運用管理者はホスト計算機へ新たに仮想計算機とインストールし、該仮想計算機上に業務サーバミドルウェアをインストールしてマシン増設を行う。この後、入力受付部121を通じて再配置指示を行う。それ以降のセッション情報再配置処理の流れは本実施形態の例で説明した流れと同様である。

また、本実施形態の例では業務処理部131には単一の業務アプリケーションのみが稼働していることを想定しているが、業務処理部131に複数の業務アプリケーションが稼働しており、負荷増大の際、その中の特定の業務アプリケーションのみを稼働させたマシンを増設することも適用可能である。

たとえば、各業務サーバ装置112上の業務処理部131にアプリケーション「AP1」とアプリケーション「AP2」が稼働しており、AP1に対するリクエストが上昇したため、新たにAP1のみを稼働させた業務サーバ装置112を増設した場合、既存の業務サーバ装置112へAP1に対するリクエストが発生した時のみ、セッション情報管理部132はAP1用セッション情報の移動処理を行う。

また、運用管理装置の機能をすべて負荷分散装置に持たせることも可能である。セッション数を負荷値として用いる場合には、負荷分散装置自身で各サーバに対するセッション数を管理すればよく、各業務サーバから負荷情報を収集しなくてもよくなるという利点がある。

最後に、本実施例においては、クライアント102からのリクエストはHTTPに限定されるものではない。負荷分散装置112によってサーバを識別するサーバ識別文字列および、業務処理部131によってセッション情報を識別する識別文字列がリクエストに含まれており、該サーバ識別文字列はセッション情報管理部132によって書き換え可能であれば他のものであってもよい。

本実施例によれば、セッション情報を扱うステートフルな業務サービスが稼働しており、かつレイヤ7パーシステンスを利用して負荷分散を行っている業務システムにおいて、複数の業務サーバ間で負荷に偏りが生じてしまった場合でも、負荷の均等化を実現できる。

特に、業務システム全体の負荷が上昇した等の理由で新たにマシンを増設する場合、既存マシンに対して転送されている継続リクエストを増設マシンへ切り替えて転送することにより、既存マシンの負荷の低減を実現できる。また特定のマシンを閉塞したい場合、セッション情報を失うこと無しに、かつセッションタイムアウト時間以内に閉塞作業を完了することが可能となる。

その他、具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

本発明の実施形態の全体構成を示したブロック図例である。 HTTPリクエストの構造を示した図の例である。 HTTPリクエストの構造を示した図の例である。 HTTPレスポンスの構造を示した図の例である。 継続リクエスト振り分けテーブルを示した図の例である。 負荷比率定義画面を示す画面図の例である。 業務サーバ装置状態テーブルを示した図の例である。 セッション情報移動処理の処理フローを示すフローチャートの例である。 セッション情報受信処理の処理フローを示すフローチャートの例である。 移動元装置選択処理の処理フローを示すフローチャートの例である。 終了判定処理の処理フローを示フローチャートの例である。 移動先装置選択処理の処理フローを示すフローチャートの例である。 各業務サーバ装置間で負荷を均等にするための、セッション情報移動の流れについて示したシーケンス図の例である。 各業務サーバ装置間で負荷を均等にするための、セッション情報移動の流れについて示したシーケンス図の例である。 各業務サーバ装置間で負荷を均等にするための、セッション情報移動の流れについて示したシーケンス図の例である。 特定の業務サーバ装置を閉塞するための、セッション情報移動の流れについて示したシーケンス図の例である。 特定の業務サーバ装置を閉塞するための、セッション情報移動の流れについて示したシーケンス図の例である。 特定の業務サーバ装置を閉塞するための、セッション情報移動の流れについて示したシーケンス図の例である。

符号の説明

101 業務システム
102 クライアント
103 HTTPリクエスト
104 HTTPレスポンス
106 運用管理装置
111 負荷分散装置
112 業務サーバ装置
121 入力受付部
122 セッション情報移動元決定部
123 セッション情報移動先決定部
124 業務サーバ装置管理部
125 業務サーバ装置状態テーブル
131 業務処理部
132 セッション情報管理部
133 業務サーバ装置監視部

Claims (18)

1. 受信した処理要求に含まれる識別子に基づいて、処理を行う計算機を特定し、該特定した計算機に処理要求を送信する負荷分散装置と、処理要求に応じて処理を行う複数の計算機と、管理装置とからなる負荷分散システムにおける負荷分散方法であって、
   前記管理装置は、
   移動元となる第１の計算機を特定し、該特定した第１の計算機にセッション移動指示を送信し、
   前記セッション移動指示を受信した前記第１の計算機は、
   前記管理装置から移動先となる第２の計算機を特定する情報を受信し、
   クライアントから受信した処理要求に対して、該処理要求に対する処理を実行後、前記第２の計算機を特定する情報に基づいて、前記第２の計算機を識別する情報を含む処理応答を生成し、該処理応答を前記クライアントに送信し、
   記憶部から取得した前記クライアントと対応付けられたデータ群を格納したテーブル又は構造体であるセッション情報を、前記第２の計算機に送信し、
   前記セッション情報を受信した前記第２の計算機は、
   前記セッション情報を記憶部に記憶し、
   前記第２の計算機を識別する情報に基づいて、前記負荷分散装置から送信された、前記クライアントからの前記第２の計算機を識別する情報を含む前記処理要求の継続処理要求に対し、前記セッション情報を用いて処理を実行することを特徴とする負荷分散システムにおける負荷分散方法。
2. 請求項１記載の負荷分散システムにおける負荷分散方法であって、
   前記移動元となる第１の計算機の特定は、
   前記複数の計算機のうち、計算機の負荷が所定の条件を満たす計算機を、移動元となる
   前記第１の計算機として特定する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
3. 請求項１に記載の負荷分散システムにおける負荷分散方法であって、
   前記複数の計算機のうち、計算機の負荷が最も低い計算機を、移動先となる前記第２の
   計算機として特定する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
4. 請求項１に記載の負荷分散システムにおける負荷分散方法であって、
   前記計算機の負荷は、前記計算機のセッション数であり、前記複数の計算機間のセッシ
   ョン数の割合が所定の条件を満たす場合に、
   前記管理装置は、前記複数の計算機間のセッション数が略均等になるように、前記セッ
   ション情報を移動する移動指示を送信する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
5. 請求項１に記載の負荷分散システムにおける負荷分散方法であって、
   前記管理装置は、
   前記複数の計算機から負荷情報を収集し、前記複数の計算機の負荷の平均値を算出し、
   当該平均値を上回る負荷値を示す一又は複数の計算機を移動元計算機として決定し、
   当該平均値を下回る負荷値を示す一又は複数の計算機を移動先計算機として決定し、
   前記セッション情報を移動する移動指示を送信する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
6. 請求項１に記載の負荷分散システムにおける負荷分散方法であって、
   前記管理装置は、
   前記複数の計算機のそれぞれの計算機に対する負荷目標値を有し、
   該それぞれの計算機に対する負荷目標値を超える負荷値を示す一又は複数の計算機を移
   動元計算機として決定し、
   該それぞれの計算機に対する負荷目標値に満たない負荷値を示す一又は複数の計算機を
   移動先計算機として決定し、
   前記セッション情報を移動する移動指示を送信する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
7. 請求項１に記載の負荷分散システムにおける負荷分散方法であって、
   前記計算機は仮想計算機であり、前記管理装置は、
   前記仮想計算機がスケールアウトすることに応じて、該スケールアウトして新たに追加
   された仮想計算機を移動先計算機として決定し、
   前記セッション情報を移動する移動指示を送信する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
8. 請求項１乃至７のいずれか１つに記載の負荷分散システムにおける負荷分散方法であっ
   て、
   前記処理応答はHTTPレスポンスであり、
   前記第２の計算機を識別する情報を含む処理応答は、前記第２の計算機を識別する情報
   をHTTPレスポンスのCookie領域に格納することにより生成する
   ことを特徴とする負荷分散システムにおける負荷分散方法。
9. 請求項１乃至８のいずれか１つに記載の負荷分散システムにおける負荷分散方法であっ
   て、
   前記計算機はブレードサーバのブレードであり、前記複数の計算機は複数のブレードか
   らなるブレードサーバである
   ことを特徴とする負荷分散システムにおける負荷分散方法。
10. 受信した処理要求に含まれる識別子に基づいて、処理を行う計算機を特定し、
    該特定した計算機に処理要求を送信する負荷分散装置と、処理要求に応じて処理を行う複数の計算機と、管理装置とからなる負荷分散システムであって、
    前記管理装置は、
    移動元となる第１の計算機を特定し、該特定した第１の計算機にセッション移動指示を送信するセッション情報移動元決定部を有し、
    前記第１の計算機は、
    前記管理装置から移動先となる第２の計算機を特定する情報を受信し、記憶部から取得したクライアントと対応付けられたデータ群を格納したテーブル又は構造体であるセッション情報を、前記第２の計算機に送信するセッション情報管理部と、
    前記クライアントから受信した処理要求に対して、該処理要求に対する処理を実行後、前記第２の計算機を特定する情報に基づいて、前記第２の計算機を識別する情報を含む処理応答を生成し、
    該処理応答を前記クライアントに送信する業務処理部とを有し、
    前記第２の計算機は、
    前記第１の計算機から受信したセッション情報を記憶する記憶部と、
    前記第２の計算機を識別する情報に基づいて前記負荷分散装置から送信された、前記クライアントからの前記第２の計算機を識別する情報を含む前記処理要求の継続処理要求に対し、前記セッション情報を用いて処理を実行する処理部とを有することを特徴とする負荷分散システム。
11. 請求項１０記載の負荷分散システムであって、
    前記セッション情報移動元決定部は、
    前記複数の計算機のうち、計算機の負荷が所定の条件を満たす計算機を、移動元となる
    前記第１の計算機として特定する
    ことを特徴とする負荷分散システム。
12. 請求項１０に記載の負荷分散システムであって、
    前記セッション情報移動元決定部は、
    前記複数の計算機のうち、計算機の負荷が最も低い計算機を、移動先となる前記第２の
    計算機として特定する
    ことを特徴とする負荷分散システム。
13. 請求項１０に記載の負荷分散システムであって、
    前記計算機の負荷は、前記計算機のセッション数であり、前記複数の計算機間のセッシ
    ョン数の割合が所定の条件を満たす場合に、
    前記セッション情報移動元決定部は、前記複数の計算機間のセッション数が略均等にな
    るように、前記セッション情報を移動する移動指示を送信する
    ことを特徴とする負荷分散システム。
14. 請求項１０に記載の負荷分散システムであって、
    前記セッション情報移動元決定部は、
    前記複数の計算機から負荷情報を収集した前記複数の計算機の負荷の平均値を算出し、
    前記平均値を上回る負荷値を示す一又は複数の計算機を移動元計算機として決定し、
    前記セッション情報を移動する移動指示を送信し、
    前記セッション情報移動先決定部は、
    前記平均値を下回る負荷値を示す一又は複数の計算機を移動先計算機として決定する
    ことを特徴とする負荷分散システム。
15. 請求項１０に記載の負荷分散システムであって、
    前記管理装置の記憶部は、前記複数の計算機のそれぞれの計算機に対する負荷目標値を
    示す情報を記憶し、
    前記セッション情報移動元決定部は、
    前記それぞれの計算機に対する負荷目標値を超える負荷値を示す一又は複数の計算機を
    移動元計算機として決定し、
    前記セッション情報を移動する移動指示を送信し、
    前記セッション情報移動先決定部は、
    前記それぞれの計算機に対する負荷目標値に満たない負荷値を示す一又は複数の計算機
    を移動先計算機として決定する
    ことを特徴とする負荷分散システム。
16. 請求項１０に記載の負荷分散システムであって、
    前記計算機は仮想計算機であり、前記セッション移動先決定部は、
    前記仮想計算機がスケールアウトすることに応じて、該スケールアウトして新たに追加
    された仮想計算機を移動先計算機として決定する
    ことを特徴とする負荷分散システム。
17. 請求項１０乃至１６のいずれか１つに記載の負荷分散システムであって、
    前記処理応答はHTTPレスポンスであり、
    前記業務処理部は、前記第２の計算機を識別する情報をHTTPレスポンスのCookie領域に
    格納することにより、前記第２の計算機を識別する情報を含む処理応答を生成する
    ことを特徴とする負荷分散システム。
18. 請求項１０乃至１７のいずれか１つに記載の負荷分散システムであって、
    前記計算機はブレードサーバのブレードであり、前記複数の計算機は複数のブレードか
    らなるブレードサーバである
    ことを特徴とする負荷分散システム。

Images