JP2016081197A - 負荷分散プログラム、負荷分散装置、負荷分散システム、および負荷分散方法 - Google Patents

Abstract

【課題】負荷分散システムの保守を容易にすることを図ること。【解決手段】図１に示す（１）の処理において、クライアント装置１０１は、第１のサーバとして、サーバＡに、リクエスト１１１を送信する。リクエスト１１１を受信したサーバＡは、所定の条件に基づいて、リクエスト１１１に対する処理をサーバＡで実行するか否かを判断する。サーバＡは、リクエスト１１１に対する処理をサーバＡで実行しないと判断し、図１に示す（２）の処理において、振り分け先サーバとなる第２のサーバとして、サーバＢにリクエスト１１１を送信する。サーバＢは、リクエスト１１１に対する処理をサーバＢで実行すると判断し、リクエスト１１１に対する処理を実行する。そして、サーバＢは、図１に示す（３）の処理において、リクエスト１１１に対する処理の結果１１２を、クライアント装置１０１に送信する。【選択図】図１

Description

本発明は、負荷分散プログラム、負荷分散装置、負荷分散システム、および負荷分散方法に関する。

従来、クライアント装置からの処理要求を複数のサーバのいずれかのサーバに振り分け、いずれかのサーバが処理要求に対する処理を実行する負荷分散システムがある。関連する先行技術として、例えば、複数のサーバ装置に、自己に接続されるクライアント装置の接続上限数をクライアント装置の接続数が超えないように、他のサーバ装置に接続先を変更させるように制御するものがある。また、クライアント装置からの入力イベントに応じた第１のサーバからのＷｅｂページ取得要求を第２のサーバに送信して第２のサーバがＷｅｂページを取得し、第２のサーバからクライアント装置に対しサーバ切替要求を送信する技術がある。また、複数の業務処理を行う分散クラスタ環境において、業務処理毎の優先順位付けや処理を実行する分散ノードの処理能力に応じて個別の負荷分散手法を選択し、負荷分散において利用者が決めた負荷の閾値に対して調整する技術がある。

特開２００９−４２８４２号公報 特開２０１１−３４３４１号公報 特開２０１０−２０４８７６号公報

しかしながら、従来技術によれば、負荷分散システムの保守が困難である場合がある。例えば、処理要求を振り分けるサーバから処理要求が振り分けられたサーバが、処理要求を振り分けるサーバに処理要求に対する結果を返す構成になっていると、処理要求を振り分けるサーバを一旦停止させて負荷分散システムの保守を行うことになる。

１つの側面では、本発明は、負荷分散システムの保守を容易にする負荷分散プログラム、負荷分散装置、負荷分散システム、および負荷分散方法を提供することを目的とする。

本発明の一側面によれば、クライアント装置と接続する複数のサーバのうちの第１のサーバに、クライアント装置から発行された処理要求をクライアント装置、または複数のサーバのうちの第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、処理要求に対する処理を第１のサーバで実行するか否かを判断し、第１のサーバで実行すると判断した場合、処理要求に対する処理を実行して、処理要求に対する処理の結果をクライアント装置に送信し、第１のサーバで実行しないと判断した場合、複数のサーバのうちの第２のサーバに処理要求を送信する負荷分散プログラム、負荷分散装置、負荷分散システム、および負荷分散方法が提案される。

本発明の一態様によれば、負荷分散システムの保守を容易にすることができるという効果を奏する。

図１は、実施の形態１にかかる負荷分散システム１００の動作例を示す説明図である。 図２は、サーバＡのハードウェア構成例を示すブロック図である。 図３は、クライアント装置１０１のハードウェア構成例を示すブロック図である。 図４は、負荷分散システム１００の機能構成例を示すブロック図である。 図５は、振り分け先候補サーバテーブル４１１の記憶内容の一例を示す説明図である。 図６は、自サーバ実行可能状態記憶テーブル４１２の記憶内容の一例を示す説明図である。 図７は、リクエスト識別子記憶テーブル４１３の記憶内容の一例を示す説明図である。 図８は、リクエストのフォーマットの一例を示す説明図（その１）である。 図９は、リクエストのフォーマットの一例を示す説明図（その２）である。 図１０は、振り分け先サーバの決定例を示す説明図である。 図１１は、サーバを追加する場合の動作例を示す説明図である。 図１２は、実施の形態１にかかる分散処理手順の一例を示すフローチャート（その１）である。 図１３は、実施の形態１にかかる分散処理手順の一例を示すフローチャート（その２）である。 図１４は、サーバ追加処理手順の一例を示すフローチャートである。 図１５は、実施の形態２にかかる負荷分散システム１５００の動作を示す図である。 図１６は、実行前データの記憶内容の一例を示す説明図である。 図１７は、実行結果データの記憶内容の一例を示す説明図である。 図１８は、実施の形態３にかかる負荷分散システム１８００の動作を示す図である。 図１９は、負荷分散システム１８００の機能構成例を示すブロック図である。 図２０は、実施の形態３にかかる分散処理手順の一例を示すフローチャート（その１）である。 図２１は、実施の形態３にかかる分散処理手順の一例を示すフローチャート（その３）である。

以下に図面を参照して、開示の負荷分散プログラム、負荷分散装置、負荷分散システム、および負荷分散方法の実施の形態を詳細に説明する。

（実施の形態１の説明）
図１は、実施の形態１にかかる負荷分散システム１００の動作例を示す説明図である。負荷分散システム１００は、クライアント装置１０１から発行された処理要求群を分散して実行するシステムである。負荷分散システム１００は、クライアント装置１０１と、複数のサーバとを有する。複数のサーバとして、負荷分散システム１００は、サーバＡ、Ｂ、Ｃ、…を有する。

以下、発行された処理要求を、「リクエスト」と称する。また、接尾記号“−ｘ”が付与されている符号は、サーバｘに関する符号であることを示している。

複数のサーバの各々のサーバは、ネットワーク１０２を介してお互いに通信することができる。各々のサーバは、リクエストを処理する負荷分散装置である。また、各々のサーバは、パーソナル・コンピュータでもよい。

クライアント装置１０１は、処理要求を発行するコンピュータである。クライアント装置１０１は、１つでもよいし、複数でもよい。また、クライアント装置１０１は、パーソナル・コンピュータでもよいし、携帯端末でもよい。

ここで、負荷分散システムの適用例について説明する。例えば、負荷分散システムの適用例として、ある社内用の複数の業務システムのサーバ間でデータを連携するサービスを提供するシステムとして適用されることがある。この場合、クライアント装置からリクエストを受け取って、複数の業務システムのいずれかのサーバにリクエストを振り分ける被分散装置を有する負荷分散システムとすることが考えられる。さらに、リクエスト数の増大や、データ量の増加によって発生するリソース不足によるサービス運用の停止を避けるため、またはサーバの故障発生によるサービス運用の停止を避けるため、被分散装置を複数有する負荷分散システムとすることが考えられる。

ここで、負荷分散システムに含まれる業務システムのリソースを増やすために、業務システムのサーバの台数を増やしたり、業務システムのサーバの保守のためにサーバを一時停止させる場合がある。このとき、負荷分散システムに含まれる被分散装置は、振り分け先となるサーバ全てを管理するため、サーバの台数の増減やサーバの保守に伴って、サーバ全てを管理する情報やサーバにリクエストを割り振るプログラムの修正をすることになる。このように、負荷分散システムにおける、機能を容易に拡張できることを示す拡張性（スケーラビリティ）や、故障が発生してもサービスを停止させないことを示す保守性（アベイラビリティ）を確保することが困難である。

そこで、負荷分散システム１００は、負荷分散システム１００内のあるサーバが他のサーバから受信したクライアント装置１０１のリクエストに対する処理を実行したらクライアント装置１０１にリクエストに対する処理の結果を直接送信する。これにより、負荷分散システム１００は、リクエストを送信した後は他のサーバがリクエストに関与しないため、負荷分散システム１００の保守や拡張が容易になる。具体的には、他のサーバが、クライアント装置１０１のリクエストを受信してから、あるサーバに送信するまでの以外のタイミングであれば、いつでも負荷分散システム１００が提供するサービスを停止させることなく、他のサーバを保守することができる。

図１に示す（１）の処理において、クライアント装置１０１は、第１のサーバとして、サーバＡに、リクエスト１１１を送信する。リクエスト１１１を受信したサーバＡは、所定の条件に基づいて、リクエスト１１１に対する処理をサーバＡで実行するか否かを判断する。ここで、所定の条件は、予めサーバで決められた条件である。例えば、サーバＡは、サーバＡのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の使用率が所定の閾値以下であれば、サーバＡで実行し、サーバＡのＣＰＵの使用率が所定の閾値より大きければサーバＡでは実行しないと判断する。所定の条件は、各サーバで同じであってもよいし、異なってもよい。

図１の例では、サーバＡは、リクエスト１１１に対する処理をサーバＡで実行しないと判断し、図１に示す（２）の処理において、振り分け先サーバとなる第２のサーバとして、サーバＢにリクエスト１１１を送信する。リクエスト１１１を受信したサーバＢは、所定の条件に基づいて、リクエスト１１１に対する処理をサーバＢで実行するか否かを判断する。図１の例では、サーバＢは、リクエスト１１１に対する処理をサーバＢで実行すると判断し、リクエスト１１１に対する処理を実行する。

リクエスト１１１に対する処理を実行した後、サーバＢは、図１に示す（３）の処理において、リクエスト１１１に対する処理の結果１１２を、クライアント装置１０１に送信する。リクエスト１１１に対する処理の結果１１２の送信先は、リクエスト１１１を送信したクライアント装置１０１でも良いし、クライアント装置１０１とは異なるクライアント装置１０３でもよい。次に、図２を用いて、複数のサーバのうちのサーバＡのハードウェア構成について説明し、図３を用いて、クライアント装置１０１のハードウェア構成について説明する。

図２は、サーバＡのハードウェア構成例を示すブロック図である。図２では、複数のサーバのうちのサーバＡのハードウェア構成例を示す。また、図２では図示していないが、サーバＢ、Ｃ、…も、サーバＡと同様のハードウェアを有する。

図２において、サーバＡは、ＣＰＵ２０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、を含む。また、サーバＡは、ディスクドライブ２０４およびディスク２０５と、通信インターフェース２０６と、を含む。また、ＣＰＵ２０１〜ディスクドライブ２０４、通信インターフェース２０６はバス２０７によってそれぞれ接続される。

ＣＰＵ２０１は、サーバＡの全体の制御を司る演算処理装置である。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される揮発性メモリである。

ディスクドライブ２０４は、ＣＰＵ２０１の制御に従ってディスク２０５に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ２０４には、例えば、磁気ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク２０５は、ディスクドライブ２０４の制御で書き込まれたデータを記憶する不揮発性メモリである。例えばディスクドライブ２０４が磁気ディスクドライブである場合、ディスク２０５には、磁気ディスクを採用することができる。また、ディスクドライブ２０４がソリッドステートドライブである場合、ディスク２０５には、半導体素子によって形成された半導体メモリ、いわゆる半導体ディスクを採用することができる。

通信インターフェース２０６は、ネットワークと内部のインターフェースを司り、他の装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース２０６は、通信回線を通じてネットワークを介して他の装置に接続される。通信インターフェース２０６には、例えば、モデムやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）アダプタなどを採用することができる。

また、負荷分散システム１００の管理者が、サーバＡを直接操作する場合、サーバＡは、ディスプレイ、キーボード、マウスといったハードウェアを有してもよい。

図３は、クライアント装置１０１のハードウェア構成例を示すブロック図である。クライアント装置１０１は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、を含む。また、クライアント装置１０１は、ディスクドライブ３０４と、ディスク３０５と、通信インターフェース３０６と、を含む。また、クライアント装置１０１は、ディスプレイ３０７と、キーボード３０８と、マウス３０９とを含む。また、ＣＰＵ３０１〜ディスクドライブ３０４と、通信インターフェース３０６〜マウス３０９とは、バス３１０によってそれぞれ接続される。

ＣＰＵ３０１は、クライアント装置１０１の全体の制御を司る演算処理装置である。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶する不揮発性メモリである。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される揮発性メモリである。

ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリードおよびライトを制御する制御装置である。ディスクドライブ３０４には、例えば、磁気ディスクドライブ、光ディスクドライブ、ソリッドステートドライブなどを採用することができる。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する不揮発性メモリである。例えばディスクドライブ３０４が磁気ディスクドライブである場合、ディスク３０５には、磁気ディスクを採用することができる。また、ディスクドライブ３０４が光ディスクドライブである場合、ディスク３０５には、光ディスクを採用することができる。また、ディスクドライブ３０４がソリッドステートドライブである場合、ディスク３０５には、半導体素子によって形成された半導体メモリ、いわゆる半導体ディスクを採用することができる。

通信インターフェース３０６は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する制御装置である。具体的に、通信インターフェース３０６は、通信回線を通じてネットワークを介して他の装置に接続される。通信インターフェース３０６には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

ディスプレイ３０７は、マウスカーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する装置である。ディスプレイ３０７には、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＴＦＴ（Ｔｈｉｎ Ｆｉｌｍ Ｔｒａｎｓｉｓｔｏｒ）液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

キーボード３０８は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う装置である。また、キーボード３０８は、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３０９は、マウスカーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う装置である。マウス３０９は、ポインティングデバイスとして同様に機能を有するものであれば、トラックボールやジョイスティックなどであってもよい。

（負荷分散システム１００の機能構成例）
図４は、負荷分散システム１００の機能構成例を示すブロック図である。複数のサーバの各サーバは、制御部４００を有する。制御部４００は、判断部４０１と、決定部４０２と、送信部４０３と、実行部４０４とを含む。図４では、サーバＡが有する機能構成を示す。他のサーバも、サーバＡが有する機能と同等の機能を有する。以下の説明では、サーバＡについて説明する。

制御部４００−Ａは、記憶装置に記憶されたプログラムをＣＰＵ２０１が実行することにより、各部の機能を実現する。記憶装置とは、具体的には、例えば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ディスク２０５などである。また、各部の処理結果は、ＣＰＵ２０１のレジスタや、ＣＰＵ２０１のキャッシュメモリ等に格納される。

また、サーバＡは、振り分け先候補サーバテーブル４１１−Ａ、自サーバ実行可能状態記憶テーブル４１２−Ａ、リクエスト識別子記憶テーブル４１３−Ａにアクセス可能である。振り分け先候補サーバテーブル４１１−Ａ、自サーバ実行可能状態記憶テーブル４１２−Ａ、リクエスト識別子記憶テーブル４１３−Ａは、ＲＡＭ２０３、ディスク２０５といった記憶装置に格納される。

振り分け先候補サーバテーブル４１１は、振り分け先候補のサーバを記憶するテーブルである。振り分け先候補サーバテーブル４１１の記憶内容の一例は、図５で説明する。自サーバ実行可能状態記憶テーブル４１２は、リクエストに対する処理を自サーバで実行するか否かの判断に用いるテーブルである。自サーバ実行可能状態記憶テーブル４１２の記憶内容の一例は、図６で説明する。リクエスト識別子記憶テーブル４１３は、受信したリクエストのリクエスト識別子を記憶するテーブルである。リクエスト識別子記憶テーブル４１３の記憶内容の一例は、図７で説明する。

判断部４０１−Ａは、リクエストを、クライアント装置１０１、または複数のサーバのうちのサーバＡとは異なる他のサーバから受信した場合、所定の条件に基づいて、リクエストに対する処理をサーバＡで実行するか否かを判断する。具体的には、判断部４０１−Ａは、所定の条件として、自サーバ実行可能状態記憶テーブル４１２−Ａを参照してリクエストに対する処理をサーバＡで実行するか否かを判断する。

また、複数のサーバが、３以上のサーバであるとする。さらに、判断部４０１−ＡがサーバＡで実行しないと判断したとする。このとき、決定部４０２−Ａは、振り分け先候補サーバテーブル４１１−Ａを参照して、振り分け先候補サーバテーブル４１１−Ａの優先順位に基づいて、２以上の振り分け先候補のサーバから振り分け先サーバを決定する。振り分け先候補サーバテーブル４１１−Ａは、振り分け先候補のサーバを特定する情報を記憶する。そして、振り分け先候補サーバテーブル４１１−Ａに記憶される振り分け先候補のサーバは、複数のサーバが形成する環状または直線状の論理的な通信経路におけるサーバＡと所定の方向で接続する複数のサーバの数未満であり２以上存在する。環状または直線状の論理的な通信経路、所定の方向については、図１０で説明する。また、振り分け先候補サーバテーブル４１１−Ａは、振り分け先候補のサーバを決定する優先順位として、振り分け先候補のサーバおよびサーバＡの間の論理的な通信経路上での距離を表す情報を記憶する。

実行部４０４−Ａは、サーバＡの運用サービスを提供するアプリケーションソフトウェアの実行処理を行う。

送信部４０３−Ａは、サーバＡで実行すると判断した場合、実行部４０４−Ａにおいて、リクエストに対する処理を実行して、リクエストに対する処理の結果をクライアント装置１０１に送信する。また、送信部４０３−Ａは、サーバＡで実行しないと判断した場合、複数のサーバのうちの振り分け先サーバにリクエストを送信する。また、リクエストは、クライアント装置１０１の識別情報を含む。リクエストのフォーマット例については、図８、図９で説明する。

また、複数のサーバが、３以上のサーバであるとする。このとき、送信部４０３−Ａは、サーバＡで実行しないと判断した場合、複数のサーバが形成する環状または直線状の論理的な通信経路においてサーバＡと隣接しており他のサーバとは異なる振り分け先サーバに、リクエストを送信する。また、送信部４０３−Ａは、決定部４０２−Ａが決定した振り分け先サーバにリクエストを送信してもよい。

図５は、振り分け先候補サーバテーブル４１１の記憶内容の一例を示す説明図である。図５では、サーバＡが有する振り分け先候補サーバテーブル４１１−Ａを用いて説明を行う。振り分け先候補サーバテーブル４１１は、振り分け先候補のサーバを記憶するテーブルである。図５に示す振り分け先候補サーバテーブル４１１−Ａは、レコード５０１−１、２を有する。

振り分け先候補サーバテーブル４１１は、優先順位と、サーバアドレスと、リクエスト再送信待機時間と、リクエスト再送信可能回数と、リクエスト再送信回数と、というフィールドを含む。優先順位フィールドには、振り分け先候補サーバテーブル４１１に登録されている振り分け先候補のサーバから、振り分け先のサーバを決定する優先順位として、論理的な通信経路上での距離を表す値が格納される。サーバアドレスフィールドには、振り分け先候補のサーバのアドレスが格納される。サーバのアドレスとしては、例えば、サーバのＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスでもよいし、サーバのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスでもよい。リクエスト再送信待機時間フィールドには、リクエストを振り分け先候補のサーバに送信して、リクエストを再送する際に待機する時間が格納される。リクエスト再送信可能回数フィールドには、リクエストを振り分け先候補のサーバに送信可能な最大の回数が格納される。リクエスト再送信回数フィールドには、リクエストを振り分け先候補のサーバに送信した回数が格納される。

例えば、レコード５０１−１は、サーバＡの振り分け先候補のサーバ群のうち、サーバＢが、論理的な通信経路上で最も近くにあるため優先順位が１番であることを示す。さらに、レコード５０１−１は、優先順位が１番となるサーバＢのＩＰアドレスを示しており、リクエスト再送信可能回数が５回であり、リクエスト再送信回数が０回であることを示す。

また、振り分け先候補サーバテーブル４１１は、２つ以上のサーバを記憶しておくことが好ましい。これにより、負荷分散システム１００は、あるサーバがサービス停止していたとしても、他のサーバにリクエストを送信することにより、リクエストが停滞することが無いようにサービスの継続性を向上することができる。

また、リクエスト再送信待機時間、リクエスト再送信可能回数、リクエスト再送信回数の各フィールドを有することにより、負荷分散システム１００は、間隔を置いて再送信を行えて、リクエストが周回ループすることを防ぐことができる。

図６は、自サーバ実行可能状態記憶テーブル４１２の記憶内容の一例を示す説明図である。自サーバ実行可能状態記憶テーブル４１２は、リクエストに対する処理を自サーバで実行するか否かの判断に用いるテーブルである。図６では、サーバＡが有する自サーバ実行可能状態記憶テーブル４１２−Ａを用いて説明を行う。自サーバ実行可能状態記憶テーブル４１２は、アプリケーションのリソース管理情報と、データベースリソース管理情報と、サーバのインフラリソース管理情報とを含む。

アプリケーションのリソース管理情報は、アプリケーションリソースの実行可能状態として、ヒープサイズと、スレッド数と、メッセージキューの滞留数とを含む。データベースリソース管理情報は、データベースリソースの実行可能状態として、ＤＢ（ＤａｔａＢａｓｅ）スペース使用率と、ＤＢバッファ使用率とを含む。サーバのインフラリソース管理情報は、サーバのインフラリソースの実行可能状態として、ＣＰＵ使用率と、メモリ使用率と、ディスク利用率とを含む。

サーバＡは、自サーバで処理を実行するか否かを判断する際に、アプリケーションリソースの実行可能状態、データベースリソースの実行可能状態、サーバのインフラリソースの実行可能状態のいずれを参照してもよい。

図７は、リクエスト識別子記憶テーブル４１３の記憶内容の一例を示す説明図である。リクエスト識別子記憶テーブル４１３は、受信したリクエストのリクエスト識別子を記憶するテーブルである。図７では、サーバＡが有するリクエスト識別子記憶テーブル４１３−Ａを用いて説明を行う。図７に示すリクエスト識別子記憶テーブル４１３−Ａは、レコード７０１−１、２を有する。

リクエスト識別子記憶テーブル４１３は、リクエスト識別子というフィールドを含む。リクエスト識別子フィールドには、サーバが受信したリクエストのリクエスト識別子が格納される。リクエスト識別子としては、例えば、ＧＵＩＤ（Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）が使用される。

例えば、図７に示すリクエスト識別子記憶テーブル４１３−Ａは、レコード７０１−１が示すＧＵＩＤ「ｘｘｘｘｘｘｘｘ−ｘ…」を有するリクエストと、レコード７０１−２が示すＧＵＩＤ「ｙｙｙｙｙｙｙｙ−ｙ…」を有するリクエストとを受信したことを示す。

次に、図８、図９で、リクエストのフォーマットの一例を示す。図８では、クライアント装置１０１から受信する際のリクエストのフォーマットを示し、図９では、他のサーバから受信する際のリクエストのフォーマットを示す。

図８は、リクエストのフォーマットの一例を示す説明図（その１）である。図８では、クライアント装置１０１から受信する際のリクエストのフォーマット８０１を示す。フォーマット８０１は、リクエスト識別子、返信先アドレス、実行前データ、送信元アドレス、実行結果データというフィールドを有する。

リクエスト識別子フィールドには、リクエストを一意に識別するリクエスト識別子が格納される。リクエスト識別子としては、例えば、ＧＵＩＤが使用される。また、クライアント装置１０１にＧＵＩＤを付与する機能がない場合、リクエスト識別子フィールドに何も値が入っていない場合もありうる。リクエスト識別子フィールドに何も値が入っていないリクエストを受信したサーバは、該当のリクエストにＧＵＩＤを付与する。

返信先アドレスフィールドには、リクエストの実行結果の返信先となるクライアント装置１０１のアドレスが格納される。クライアント装置１０１のアドレスとしては、ＩＰアドレス、ＭＡＣアドレス以外にも、メールアドレス、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従ったＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のアドレス等でもよい。

実行前データフィールドには、リクエストのデータが格納される。具体的には、例えば、実行前データフィールドには、サーバに処理させる処理の種別と、引数の内容とが格納される。送信元アドレスフィールドには、リクエストを発行したクライアント装置１０１のアドレスが格納される。実行結果データフィールドには、処理結果のデータが格納される。

また、フォーマット８０１が示すように、返信先アドレスフィールドと送信元アドレスフィールドとには、異なるクライアント装置１０１を設定することができる。例えば、負荷分散システム１００内に、複数の業務サービスがある場合に、ある業務サービスを利用するクライアント装置１０１が、他の業務サービスを利用するクライアントとして、処理結果を渡す際に、クライアント装置１０３が設定される。

図９は、リクエストのフォーマットの一例を示す説明図（その２）である。図９では、他のサーバから受信する際のリクエストのフォーマット９０１を示す。フォーマット９０１は、フォーマット８０１に、転送元アドレスフィールドを追加したフォーマットである。フォーマット９０１のうち、フォーマット８０１が有するフォーマットについては、説明を省略する。

転送元アドレスフィールドは、リクエストを送信したサーバのアドレスが格納される。転送元アドレスフィールドの使用例として、例えば、サーバＢが、サーバＡからリクエストを受信したとする。このとき、サーバＢが、サーバＢでリクエストに対する処理を実行することができないと判断した場合、振り分け先候補サーバテーブル４１１に格納されているサーバのうち、転送元アドレスフィールドに格納されたサーバＡ以外のサーバにリクエストを送信する。これによって、同じサーバＡとサーバＢ間で同じリクエストデータの往復が発生することを防止する。

図１０は、振り分け先サーバの決定例を示す説明図である。複数のサーバの各々のサーバは、各々のサーバでリクエストに対する処理が実行できないと判断した場合に、リクエストを振り分ける振り分け先サーバを決定する。図１０では、振り分け先サーバの決定例を示す。同じドメイン内および同じクラスタ内の複数のサーバは、お互いにリクエストを送信しあうことにならないように、複数のサーバで論理的な通信経路を形成し、論理的な通信経路における所定の方向を決めておく。論理的な通信経路は、直線状でもよいし、環状でもよい。論理的な通信経路は、どのようなルールで形成してもよい。例えば、各々のサーバの名称のＡＢＣ順となる方向を所定の方向として、論理的な通信経路を形成してもよいし、各々のサーバのＩＰアドレスの昇順となる方向を所定の方向として、論理的な通信経路を形成してもよい。

図１０では、サーバＡ、Ｂ、Ｃ、Ｄ、Ａ、…を順方向とする環状の論理的な通信経路１００１が形成された例を示す。サーバＡは、振り分け先候補サーバテーブル４１１−Ａに、通信経路１００１上でサーバＡから最も距離が短いサーバＢを優先順位の１番目として、サーバＢの次に距離が短いサーバＣを優先順位の２番目として設定する。以下、図１０、図１１において、優先順位の１番目のサーバへの矢印を実線で示し、優先順位の２番目のサーバへの矢印を点線で示す。

例えば、サーバＡは、サーバＡでリクエストに対する処理が実行できないと判断した場合に、まず、優先順位が最も高いサーバＢを振り分け先サーバとして決定する。そして、サーバＢが故障していたりしてリクエストの送信に対する応答がない場合、サーバＡは、優先順位が次に高いサーバＣを振り分け先サーバとして決定する。ここで、論理的な通信経路１００１は、物理的な通信経路ではないため、サーバＡとサーバＣとは、サーバＢを介さずとも通信することができる。

図１１は、サーバを追加する場合の動作例を示す説明図である。図１１では、負荷分散システム１００にサーバを追加する動作例として、サーバＺを追加する場合を例にして説明を行う。

図１１の例では、追加の一例として、サーバＺを、サーバＢの振り分け先候補のサーバの１つとして追加する例を示す。サーバＺは、サーバＣとサーバＤとを、振り分け先候補サーバテーブル４１１−Ｚに追加する。また、サーバＢは、サーバＺを振り分け先候補サーバテーブル４１１−Ｂに追加する。図１１の例では、サーバＢは、サーバＺを優先順位の３番目として追加しているが、優先順位の１番目として追加してもよい。

サーバＢがサーバＺを振り分け先候補サーバテーブル４１１−Ｂに追加する際には、サーバＢのサービスを一時的に停止させることになる。しかし、サーバＣとサーバＤとは、振り分け先候補サーバテーブル４１１に追加しないため、サーバＺの追加中であってもサービスの運用を続行することができる。また、サーバＢのサービスを一時的に停止しても、サーバＢを振り分け先候補のサーバとするサーバＡは、サーバＢ以外にも他の振り分け先候補のサーバとしてサーバＣがあるため、負荷分散システム１００は、リクエストが停滞することを抑制することができる。

なお、論理的な通信経路上のどこに、サーバを追加するかについては、負荷分散システム１００は、論理的な通信経路のどこに追加してもよい。例えば、負荷分散システム１００は、論理的な通信経路を形成したルールに従って、サーバを追加する。

次に、図１２〜図１４を用いて、負荷分散システム１００が実行するフローチャートについて説明する。

図１２は、実施の形態１にかかる分散処理手順の一例を示すフローチャート（その１）である。また、図１３は、実施の形態１にかかる分散処理手順の一例を示すフローチャート（その２）である。分散処理は、クライアント装置１０１から発行されたリクエスト群に対する処理を複数のサーバで分散する処理である。また、分散処理は、複数のサーバの各々のサーバが行う。図１２、図１３では、サーバＡが実行する例を示す。

サーバＡは、リクエストを受信する（ステップＳ１２０１）。ステップＳ１２０１の処理について、サーバＡは、クライアント装置１０１からリクエストを受信する場合と、サーバＡ以外の他のサーバからリクエストを受信する場合とがある。また、クライアント装置１０１は、複数のサーバのうちのどのサーバにリクエストを送信してもよい。例えば、クライアント装置１０１は、複数のサーバのうちのいくつかのサーバの識別情報として、ＩＰアドレスを有しておく。そして、クライアント装置１０１は、クライアント装置１０１のＩＰアドレスのネットワークアドレスと同一のＩＰアドレスを有するサーバに処理要求を送信する。また、クライアント装置１０１は、複数のサーバのうちの過去に処理要求に対する結果を受けたサーバのＩＰアドレスを記憶しておき、再びリクエストを送信する際には、記憶したサーバに処理要求を送信してもよい。

次に、サーバＡは、受信したリクエストにリクエスト識別子が付与されているか否かを判断する（ステップＳ１２０２）。受信したリクエストにリクエスト識別子が付与されている場合（ステップＳ１２０２：Ｙｅｓ）、サーバＡは、受信したリクエストのリクエスト識別子がリクエスト識別子記憶テーブル４１３−Ａに登録されているか否かを判断する（ステップＳ１２０３）。受信したリクエストのリクエスト識別子がリクエスト識別子記憶テーブル４１３−Ａに登録されている場合（ステップＳ１２０３：Ｙｅｓ）、リクエストが環状の論理的な通信経路を一周したことになるため、サーバＡは、実行不可能であることを示すエラーをクライアント装置１０１に送信する（ステップＳ１２０５）。ステップＳ１２０５の処理終了後、サーバＡは、分散処理を終了する。

なお、複数のサーバが直線状の論理的な通信経路を形成する場合には、論理的な通信経路の端となるサーバを予め識別しておき、端となるサーバは、処理を実行できない場合、実行不可能であることを示すエラーをクライアント装置１０１に送信すればよい。

一方、受信したリクエストにリクエスト識別子が付与されていない場合（ステップＳ１２０２：Ｎｏ）、サーバＡは、受信したリクエストにリクエスト識別子を付与する（ステップＳ１２０４）。ステップＳ１２０４の処理終了後、または、受信したリクエストのリクエスト識別子がリクエスト識別子記憶テーブル４１３−Ａに登録されていない場合（ステップＳ１２０３：Ｎｏ）、サーバＡは、受信したリクエストのリクエスト識別子をリクエスト識別子記憶テーブル４１３−Ａに登録する（ステップＳ１２０６）。

次に、サーバＡは、自サーバ実行可能状態記憶テーブル４１２−Ａを参照して、自サーバで、リクエストに対する処理が実行可能か否かを判断する（ステップＳ１２０７）。リクエストに対する処理が実行可能であると判断した場合（ステップＳ１２０７：Ｙｅｓ）、サーバＡは、リクエストに対する処理を実行する（ステップＳ１２０８）。次に、サーバＡは、実行結果をクライアント装置１０１に送信する（ステップＳ１２０９）。ステップＳ１２０９の処理終了後、サーバＡは、分散処理を終了する。

一方、リクエストに対する処理が実行可能でないと判断した場合（ステップＳ１２０７：Ｎｏ）、サーバＡは、受信したリクエストに、自サーバのアドレスを付与する（ステップＳ１３０１）。次に、サーバＡは、振り分け先候補サーバテーブル４１１−Ａを参照して、振り分け先サーバを決定する（ステップＳ１３０２）。例えば、サーバＡは、リクエスト再送信回数フィールドの値が、リクエスト再送信可能回数フィールドの値以下である振り分け先候補のサーバのうち、優先順位が最も小さい値となる振り分け先候補のサーバを、振り分け先サーバとして決定する。

そして、サーバＡは、自サーバのアドレスを付与したリクエストを振り分け先サーバに送信する（ステップＳ１３０３）。次に、サーバＡは、振り分け先サーバにリクエスト送信ができたか否かを判断する（ステップＳ１３０４）。振り分け先サーバにリクエスト送信ができた場合（ステップＳ１３０４：Ｙｅｓ）、サーバＡは、分散処理を終了する。

一方、振り分け先サーバにリクエスト送信ができない場合（ステップＳ１３０４：Ｎｏ）、サーバＡは、振り分け先サーバへのリクエスト送信の再送信が可能か否かを判断する（ステップＳ１３０５）。ここで、ステップＳ１３０４：Ｎｏとなる場合として、例えば、振り分け先サーバが故障、またはメンテナンス等により電源が供給されておらず、サーバＡが、リクエストを受信したというＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）を受信しなかった場合である。また、リクエスト送信の再送信が可能かの判断としては、例えば、サーバＡは、振り分け先候補サーバテーブル４１１−Ａのリクエスト再送信回数フィールドの値が、リクエスト再送信可能回数フィールドの値以下である場合、再送信が可能と判断する。

振り分け先サーバへのリクエスト送信の再送信が可能でない場合（ステップＳ１３０５：Ｎｏ）、サーバＡは、ステップＳ１３０２の処理に移行する。一方、振り分け先サーバへのリクエスト送信の再送信が可能である場合（ステップＳ１３０５：Ｙｅｓ）、サーバＡは、振り分け先サーバへの再送信回数をインクリメントする（ステップＳ１３０６）。そして、サーバＡは、振り分け先サーバに対応する待機時間分待機する（ステップＳ１３０７）。待機した後、サーバＡは、ステップＳ１３０３の処理に移行する。分散処理を実行することにより、負荷分散システム１００は、クライアント装置１０１から発行されたリクエスト群に対する処理を複数のサーバで分散することができる。

図１４は、サーバ追加処理手順の一例を示すフローチャートである。サーバ追加処理は、負荷分散システム１００にサーバを追加する処理である。サーバ追加処理は、負荷分散システム１００に追加するサーバと、振り分け先候補サーバテーブル４１１に、追加するサーバを追加するサーバとが協働する。図１４では、負荷分散システム１００に追加するサーバをサーバＺとし、振り分け先候補サーバテーブル４１１に、サーバＺを追加するサーバをサーバＢとして説明する。なお、振り分け先候補サーバテーブル４１１に、追加するサーバを追加するサーバは、２以上あってもよい。

サーバＺは、振り分け先候補サーバテーブル４１１−Ｚに、論理的な通信経路における順方向側にある２つ以上のサーバのアドレスを追加する（ステップＳ１４０１）。次に、サーバＺは、運用サービスを開始する（ステップＳ１４０２）。ステップＳ１４０２の処理について、具体的には、サーバＺは、運用サービスを実行するアプリケーションソフトウェアの実行を開始する。

サーバＺは、負荷分散システム１００に追加するサーバであるサーバＺを振り分け先候補サーバテーブル４１１に追加するサーバＢに、追加依頼を指示する（ステップＳ１４０３）。ステップＳ１４０３の処理終了後、サーバＺは、サーバ追加処理を終了する。

追加依頼を受けたサーバＢは、運用サービスを停止させる（ステップＳ１４０４）。ステップＳ１４０４の処理について、具体的には、サーバＢは、運用サービスを実行するアプリケーションソフトウェアの実行を終了する。次に、サーバＢは、振り分け先候補サーバテーブル４１１−Ｂに、負荷分散システム１００に追加するサーバのアドレスを追加する（ステップＳ１４０５）。そして、サーバＢは、運用サービスを開始する（ステップＳ１４０６）。ステップＳ１４０６の処理終了後、サーバＢは、サーバ追加処理を終了する。サーバ追加処理を実行することにより、サーバは、負荷分散システム１００に新たなサーバを追加することができる。

以上説明したように、負荷分散システム１００によれば、負荷分散システム１００内のあるサーバが他のサーバから受信したクライアント装置１０１のリクエストに対する処理を実行したらクライアント装置１０１にリクエストに対する処理の結果を直接送信する。これにより、負荷分散システム１００は、リクエストを送信した後は他のサーバがリクエストに関与しないため、負荷分散システム１００の保守や拡張が容易になる。また、負荷分散システム１００は、クライアント装置１０１にリクエストに対する処理の結果を直接送信するため、負荷分散システム内の通信量を削減することができる。また、負荷分散システム１００によれば、専用の振り分け装置がなくとも、分散処理を行うことができる。

また、負荷分散システム１００によれば、他のサーバに送信する処理要求は、クライアント装置１０１の識別情報を含んでもよい。これにより、他のサーバは、複数のクライアント装置１０１のうちの識別情報で特定されるクライアント装置１０１に、直接処理結果を送信することができる。また、クライアント装置１０１の識別情報を送信することにより、他のサーバは、処理対象の相手を特定することができるため、他のサーバが有するキャッシュを有効利用して、同じ内容のリクエストを高速にすることができる。

また、複数のサーバが３以上であるとする。このとき、負荷分散システム１００によれば、第１のサーバで実行しないと判断した場合、複数のサーバが形成する環状または直線状の論理的な通信経路において第１のサーバと隣接しており他のサーバとは異なる第２のサーバに、処理要求を送信してもよい。これにより、第１のサーバは、複数のサーバのうちの第２のサーバの識別情報のみ記憶すればよいため、複数のサーバのうちの第２のサーバ以外のサーバを停止させる際に影響を受けずにすむ。

また、複数のサーバが３以上であるとする。このとき、負荷分散システム１００によれば、振り分け先候補サーバテーブル４１１内の距離を表す情報に基づいて、振り分け先候補サーバテーブル４１１に登録された２以上の振り分け候補のサーバから第２のサーバを決定してもよい。これにより、第１のサーバは、複数のサーバのうちの振り分け候補のサーバの識別情報のみ記憶すればよい。さらに、第１のサーバは、振り分け候補のサーバのいずれかが停止したとしても、他の振り分け候補のサーバに処理を振り分けることができ、サービスを続行することができる。

また、負荷分散システム１００は、サービスを提供するプログラムを、複数のサーバに動的に配置することが可能になる。また、負荷分散システム１００は、他のサーバにリクエストを送信することに連動して他のサーバの電源をＯＦＦからＯＮにすることで、消費電力を削減することができる。また、負荷分散システム１００は、複数のサーバのスペックに応じた分散配分を行うことができる。

（実施の形態２の説明）
実施の形態１にかかるクライアント装置１０１から発行された処理を要求する対象となるリクエストによっては、当該リクエストに含まれる実行前データの量、および／または、実行結果データの量が大きくなる場合がある。例えば、ギガバイト級のデータサイズの画像データ等が実行前データとして添付され、リクエストされるような場合である。このようなリクエストの場合、リクエストを受取ったサーバＡで実行しないと判断した場合に、振り分け先のサーバＢにデータを送信することによるネットワークへの負荷が高くなる。この負荷はサーバへの振り分けの回数が増加するほど、ネットワークへの負荷が高くなる。

そこで、後述する図１５で示す実施の形態２にかかる負荷分散システム１５００は、リクエストのフォーマット８０１において実行前データに代えて実行前データを格納した格納先アドレスを格納することを可能とする。および／または、負荷分散システム１５００は、実行後データに代えて実行後データを格納した格納先アドレスを格納することを可能とする。格納先アドレスは、例えば、ＵＲＬである。なお、実施の形態１において説明した箇所と同様の箇所については、同一符号を付して図示および説明を省略する。また、説明の簡略化のため、以下の説明における「サーバ」は、特に記載がない場合、実施の形態２にかかるサーバであるとする。

図１５は、実施の形態２にかかる負荷分散システム１５００の動作を示す図である。負荷分散システム１５００は、サーバＡ〜Ｃと、実施の形態２にかかるクライアント装置１５０１とを含む。さらに、負荷分散システム１５００は、フォーマット８０１に格納先アドレスを格納すること可能とするために、実行前データおよび／または実行結果データを格納可能な実行前データ記憶装置１５０２と、実行結果データ記憶装置１５０３とを含む。実行前データ記憶装置１５０２と実行結果データ記憶装置１５０３とは、クライアント装置１５０１と同じネットワーク１５０４を介して通信できる別々のハードウェア装置でもよい。または、実行前データ記憶装置１５０２と実行結果データ記憶装置１５０３とは、クライアント装置１５０１のディスクドライブでもよい。実行前データ記憶装置１５０２が有する実行前データの記憶内容の一例は、図１６で説明する。また、実行結果データ記憶装置１５０３が有する実行結果データ記憶内容の一例は、図１７で説明する。

クライアント装置１５０１は、図１５の（１）の処理において、実行前データ記憶装置１５０２に実行前データ１５１１−Ａを格納する。そして、クライアント装置１５０１は、図１５の（２）の処理において、実行前データ１５１１−Ａに代えて実行前データを格納した格納先アドレスを格納したリクエスト１５１１−Ｂを負荷分散システム１５００に含まれるいずれかのサーバへ送信する。図１５の例では、クライアント装置１５０１は、リクエスト１５１１−ＢをサーバＡに送信する。ここで、クライアント装置１５０１は、実行前データ記憶装置１５０２に実行前データ１５１１−Ａを記憶するか否かを、実行前データ１５１１−Ａのサイズに応じて切り替える制御を行ってもよい。

負荷分散システム１５００に含まれるいずれかのサーバは、受信したリクエストに実行前データを格納した格納先アドレスが格納されている場合、格納先アドレスに対応する実行前データを実行前データ記憶装置１５０２から読み出す。そして、いずれかのサーバは、読み出した実行前データを用いて、リクエストに応じた処理を実行する。また、いずれかのサーバは、リクエストに実行結果データを格納する格納先アドレスが格納されている場合、リクエストに応じた処理の実行結果データを、実行結果データ記憶装置１５０３に設けられた格納先アドレスに対応する格納先に格納する処理を実行する。そして、いずれかのサーバは、リクエストに対する処理の結果を、クライアント装置１５０１に送信する。

図１５の例では、サーバＡは、リクエスト１５１１−Ｂに対する処理をサーバＡで実行しないと判断し、図１５に示す（３）の処理において、振り分け先サーバとなる第２のサーバとして、サーバＢにリクエスト１５１１−Ｂを送信する。そして、サーバＢは、リクエスト１５１１−Ｂに実行前データを格納した格納先アドレスが格納されているため、図１５の（４）の処理において、格納先アドレスに対応する実行前データ１５１１−Ａを実行前データ記憶装置１５０２から読み出す。そして、サーバＢは、読み出した実行前データ１５１１−Ａを用いて、リクエスト１５１１−Ｂに応じた処理を実行する。続けて、サーバＢは、図１５の（５）の処理において、リクエスト１５１１−Ｂに応じた処理の実行結果データ１５１１−Ｃを、実行結果データ記憶装置１５０３に設けられた格納先アドレスに対応する格納先に格納する処理を実行する。実行結果データ１５１１−Ｃを実行結果データ記憶装置１５０３に格納するか、そのままクライアント装置１５０１に送信するかについて、サーバＢは、実行結果データ１５１１−Ｃのデータサイズに基づいて判断してもよい。または、判断リクエスト１５１１−Ｂに予め、実行結果データ１５１１−Ｃを実行結果データ記憶装置１５０３に格納するか、そのままクライアント装置１５０１に送信するかが示されていてもよい。

そして、サーバＢは、図１５の（６）の処理において、リクエスト１５１１−Ｂに対する処理の結果１５１２を、クライアント装置１５０１に送信する。クライアント装置１５０１は、図１５の（７）の処理において、格納先アドレスに対応する実行結果データ１５１１−Ｃを実行結果データ記憶装置１５０３から読み出す。

図１６は、実行前データの記憶内容の一例を示す説明図である。具体的には、実行前データ記憶装置１５０２は、実行前データ記憶テーブル１６００に、実行前データを記憶する。図１６に示す実行前データ記憶テーブル１６００は、レコード１６０１−１〜３を有する。

実行前データ記憶テーブル１６００は、リクエスト識別子と、読出状態と、実行前データというフィールドを含む。リクエスト識別子フィールドには、リクエストのリクエスト識別子が格納される。読出状態フィールドには、実行前データの読出状態を示す識別子が格納される。具体的には、読出状態フィールドには、実行前データがまだ読み出されていないことを示す「未読出」、実行前データが読み出されている間であることを示す「読出処理中」、実行前データが既に読み出されたことを示す「読出済み」のうちのいずれかが格納される。実行前データフィールドには、リクエストのデータが格納される。

図１７は、実行結果データの記憶内容の一例を示す説明図である。具体的には、実行結果データ記憶装置１５０３は、実行結果データ記憶テーブル１７００に、結果データを記憶する。図１７に示す実行結果データ記憶テーブル１７００は、レコード１７０１−１〜３を有する。

実行結果データ記憶テーブル１７００は、リクエスト識別子と、格納状態と、実行結果データというフィールドを含む。リクエスト識別子フィールドには、リクエストのリクエスト識別子が格納される。格納状態フィールドには、実行結果データの格納状態を示す識別子が格納される。具体的には、格納状態フィールドには、実行結果データがまだ格納されていないことを示す「未格納」、実行結果データが格納されている間であることを示す「格納処理中」、実行結果データが既に格納されたことを示す「格納済み」のうちのいずれかが格納される。実行結果データフィールドには、実行結果データが格納される。

実施の形態２にかかるリクエストのフォーマットについては、図８、９で示した通りであるので図示を省略する。ただし、実施の形態２にかかるリクエストにおける実行前データフィールドには、実行前データが格納された格納先アドレスが格納されてもよい。同様に、実施の形態２にかかるリクエストにおける実行結果データフィールドには、実行結果データが格納された格納先アドレスが格納されてもよい。

負荷分散システム１５００が実行するフローチャートについては、後述する実施の形態３にかかる負荷分散システムが実行するフローチャートと同一であるため、実施の形態３の説明の中で行う。

（実施の形態３の説明）
実施の形態３にかかる負荷分散システムは、負荷分散システム１５００の構成に加えて、リクエストを受信したサーバがリクエストの処理を実行しない場合、振り分け先候補サーバテーブル４１１に格納された複数のサーバに対しまとめてリクエストを送信する。なお、実施の形態１、２において説明した箇所と同様の箇所については、同一符号を付して図示および説明を省略する。また、説明の簡略化のため、以下の説明における「サーバ」は、特に記載がない場合、実施の形態３にかかるサーバであるとする。

図１８は、実施の形態３にかかる負荷分散システム１８００の動作を示す図である。ここで、図１８の（１）の処理と（２）の処理とは、それぞれ、図１５の（１）の処理と（２）の処理と同一であるため、説明を省略する。

リクエストを受信したサーバは、受信したリクエストについての処理の可否を判定し、処理ができないと判定した場合に、振り分け先候補サーバテーブル４１１に格納されている複数のサーバに対してまとめてリクエストを送信する。図１８の例では、リクエスト１５１１−Ｂを受信したサーバＡは、リクエスト１５１１−Ｂについての処理を実行しないと判定する。そして、サーバＡは、図１８の（３）の処理として、サーバＢにリクエスト１５１１−Ｂを送信するとともに、図１８の（４）の処理として、サーバＣにリクエスト１５１１−Ｃを送信する。

一方、リクエストを受信したサーバは、受信したリクエストについての処理の可否を判定し、処理ができると判定した場合に、実行前データ記憶装置１５０２から実行前データを読み出す。この際、処理ができると判定したサーバは、実行前データを読み出したことを示す情報を実行前データ記憶装置１５０２に格納する。実行前データを読み出したことを示す情報は、具体的には、図１６に示す「読出済み」である。複数のサーバにリクエストを送信するため、あるサーバが実行前データ記憶装置１５０２に実行前データを読み出したことを示す情報を格納した後、あるサーバとは異なる他のサーバが、受信したリクエストについての処理ができると判定する場合がある。この場合、他のサーバは、実行前データ記憶装置１５０２から実行前データを読み出そうとするが、あるサーバによって実行前データが読み出されているため、他のサーバは、実行前データを読み出さないで処理を終了する。

図１８の例では、サーバＢは、リクエスト１５１１−Ｂに実行前データを格納した格納先アドレスが格納されているため、図１５の（５）の処理において、格納先アドレスに対応する実行前データ１５１１−Ａを実行前データ記憶装置１５０２から読み出す。なお、実行前データ１５１１−Ａを読み出す際には、サーバＢは、実行前データ１５１１−Ａが他のサーバから読み出されていないことを示す情報、すなわち「未読出」であることを確認する。そして、サーバＢは、実行前データ１５１１−Ａに対応する読み出し状態を、「読出済み」に設定する。次に、サーバＢは、読み出した実行前データ１５１１−Ａを用いて、リクエスト１５１１−Ｂに応じた処理を実行する。

一方、サーバＣは、リクエスト１５１１−Ｂに実行前データを格納した格納先アドレスが格納されているため、図１５の（６）の処理において、格納先アドレスに対応する実行前データ１５１１−Ａを実行前データ記憶装置１５０２から読み出そうとする。ここで、サーバＣは、実行前データ１５１１−Ａが既に読み出されていることを示す情報を取得し、実行前データを読み出さないで処理を終了する。図１８の（７）の処理と（８）の処理と（９）の処理とは、それぞれ、図１５の（５）の処理と（６）の処理と（７）の処理と同一であるため、説明を省略する。

このように、負荷分散システム１８００は、サーバを一台ずつリクエストを転送することなく、リクエストが送信された複数のサーバの内の処理の可能なサーバがリクエストについての処理を実行することが可能となる。従って、負荷分散システム１８００は、一台ずつのサーバにリクエストを転送するよりもリクエストについての処理が開始されるまでの時間が短縮できる効果がある。

図１９は、負荷分散システム１８００の機能構成例を示すブロック図である。複数のサーバの各サーバは、制御部１９００を有する。制御部１９００は、判断部４０１と、決定部４０２と、送信部４０３と、実行部４０４と、分散処理部１９０１と、読出部１９０２と、格納部１９０３とを含む。図１９では、サーバＡが有する機能構成を示す。他のサーバも、サーバＡが有する機能と同等の機能を有する。以下の説明では、サーバＡについて説明する。

制御部１９００−Ａは、記憶装置に記憶されたプログラムをＣＰＵ２０１が実行することにより、各部の機能を実現する。記憶装置とは、具体的には、例えば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ディスク２０５などである。また、各部の処理結果は、ＣＰＵ２０１のレジスタや、ＣＰＵ２０１のキャッシュメモリ等に格納される。

分散処理部１９０１−Ａは、受信したリクエストを複数のサーバにまとめて送信する。読出部１９０２−Ａは、受信したリクエストについての処理の可否を判定し、処理ができると判定した場合に、実行前データ記憶装置１５０２から実行前データを読み出す。格納部１９０３−Ａは、実行結果データを、実行結果データ記憶装置１５０３に格納する。

次に、図２０、図２１を用いて、負荷分散システム１８００が実行する実施の形態３にかかる分散処理をフローチャートとして示す。また、負荷分散システム１５００も、図２０、図２１に示すフローチャートに従って動作する。

図２０は、実施の形態３にかかる分散処理手順の一例を示すフローチャート（その１）である。また、図２１は、実施の形態３にかかる分散処理手順の一例を示すフローチャート（その３）である。また、分散処理は、複数のサーバの各々のサーバが行う。図２０、図２１では、サーバＡが実行する例を示す。

ここで、実施の形態３にかかる分散処理手順の一例を示すフローチャート（その２）は、図１３で示したフローチャートと同一であるため、図示および説明を省略する。なお、図１３で示したステップＳ１３０２の処理において、実施の形態３にかかるサーバは、振り分け先サーバを、複数決定する。さらに、図２０に示すステップＳ２００１〜Ｓ２００７、Ｓ２００９、Ｓ２０１０の各処理は、図１２で示したステップＳ１２０１〜Ｓ１２０９の各処理と同一であるため、説明を省略する。

ステップＳ２００７：Ｙｅｓである場合、サーバＡは、受信したリクエストの実行前データが、実行前データ記憶装置１５０２に格納されているか否かを判断する（ステップＳ２００８）。受信したリクエストの実行前データが、実行前データ記憶装置１５０２に格納されていない場合（ステップＳ２００８：Ｎｏ）、サーバＡは、ステップＳ２００９の処理に移行する。

受信したリクエストの実行前データが、実行前データ記憶装置１５０２に格納されている場合（ステップＳ２００８：Ｙｅｓ）、サーバＡは、実行前データの読出状態が次に示す識別子のいずれに一致するかを判断する（ステップＳ２１０１）。次に示す識別子は、「未読出」と、「読出処理中」と、「読出済み」とである。実行前データの読出状態が「読出処理中」か「読出済み」である場合（ステップＳ２１０１：「読出処理中」、「読出済み」）、サーバＡは、リクエストを受信したときに登録したリクエスト識別子記憶テーブル４１３−Ａのリクエスト識別子を削除する（ステップＳ２１０２）。ステップＳ２１０２の処理終了後、サーバＡは、分散処理を終了する。

実行前データの読出状態が「未読出」である場合（ステップＳ２１０１：「未読出」）、サーバＡは、実行前データの読出状態を、「読出処理中」に設定する（ステップＳ２１０３）。次に、サーバＡは、実行前データを、実行前データ記憶装置１５０２から読み出す（ステップＳ２１０４）。そして、サーバＡは、リクエストに対する処理を実行する（ステップＳ２１０５）。

次に、サーバＡは、実行結果データのデータサイズがギガバイトオーダか否かを判断する（ステップＳ２１０６）。実行結果データのデータサイズがギガバイトオーダである場合（ステップＳ２１０６：Ｙｅｓ）、サーバＡは、実行結果データ記憶テーブル１７００の該当のリクエストの格納状態を、「格納処理中」に設定する（ステップＳ２１０７）。次に、サーバＡは、実行結果データを、実行結果データ記憶装置１５０３に書き込む（ステップＳ２１０８）。そして、サーバＡは、実行結果データの格納アドレスをクライアント装置１５０１に送信する（ステップＳ２１０９）。次に、サーバＡは、実行結果データ記憶テーブル１７００の該当のリクエストの格納状態を、「格納済み」に設定する（ステップＳ２１１０）。

一方、実行結果データのデータサイズがギガバイトオーダでない場合（ステップＳ２１０６：Ｎｏ）、サーバＡは、実行結果データをクライアント装置１５０１に送信する（ステップＳ２１１１）。ステップＳ２１１０、またはステップＳ２１１１の処理終了後、サーバＡは、実行前データの読出状態を、「読出済み」に設定する（ステップＳ２１１２）。ステップＳ２１１２の処理終了後、サーバＡは、分散処理を終了する。

なお、実施の形態１〜３で説明した負荷分散方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本負荷分散プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本負荷分散プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態１〜３に関し、さらに以下の付記を開示する。

（付記１）クライアント装置と接続する複数のサーバのうちの第１のサーバに、
前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信する、
処理を実行させることを特徴とする負荷分散プログラム。

（付記２）前記処理要求は、前記クライアント装置の識別情報を含むことを特徴とする付記１に記載の負荷分散プログラム。

（付記３）前記複数のサーバは、３以上のサーバであって、
前記処理要求を送信する処理は、
前記第１のサーバで実行しないと判断した場合、前記複数のサーバが形成する環状または直線状の論理的な通信経路において前記第１のサーバと隣接しており前記他のサーバとは異なる第２のサーバに、前記処理要求を送信することを特徴とする付記１または２に記載の負荷分散プログラム。

（付記４）前記複数のサーバは、３以上のサーバであって、
前記第１のサーバに、
前記第１のサーバで実行しないと判断した場合、前記複数のサーバが形成する環状または直線状の論理的な通信経路における前記第１のサーバと所定の方向で接続する前記複数のサーバの数未満であって２以上のサーバと、前記２以上のサーバの各々のサーバおよび前記第１のサーバの間の前記通信経路上での距離を表す情報と、を関連付けた情報を参照して、前記距離を表す情報に基づいて、前記２以上のサーバから第２のサーバを決定する、処理を実行させ、
前記処理要求を送信する処理は、
決定した前記第２のサーバに前記処理要求を送信する、
処理を実行させることを特徴とする付記１〜３のいずれか一つに記載の負荷分散プログラム。

（付記５）クライアント装置と接続する複数の負荷分散装置のうちの第１の負荷分散装置であって、
前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数の負荷分散装置のうちの前記第１の負荷分散装置とは異なる他の負荷分散装置から受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１の負荷分散装置で実行するか否かを判断し、
前記第１の負荷分散装置で実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
前記第１の負荷分散装置で実行しないと判断した場合、前記複数の負荷分散装置のうちの第２の負荷分散装置に前記処理要求を送信する、
制御部を有することを特徴とする負荷分散装置。

（付記６）クライアント装置と複数のサーバとを有する負荷分散システムであって、
前記クライアント装置は、
前記複数のサーバのうちの第１のサーバに処理要求を発行し、
前記第１のサーバは、
前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信し、
前記クライアント装置は、
前記複数のサーバのうちの前記処理要求に対する処理を実行したサーバから、前記処理要求に対する処理の結果を受信する、
ことを特徴とする負荷分散システム。

（付記７）クライアント装置と接続する複数のサーバのうちの第１のサーバが、
前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信する、
処理を実行することを特徴とする負荷分散方法。

Ａ、Ｂ、Ｃ、Ｚ サーバ
１００、１５００、１８００ 負荷分散システム
１０１、１５０１ クライアント装置
４００ 制御部
４０１ 判断部
４０２ 決定部
４０３ 送信部
４０４ 実行部
４１１ 振り分け先候補サーバテーブル
４１２ 自サーバ実行可能状態記憶テーブル
４１３ リクエスト識別子記憶テーブル

Claims (7)

1. クライアント装置と接続する複数のサーバのうちの第１のサーバに、
   前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
   前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
   前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信する、
   処理を実行させることを特徴とする負荷分散プログラム。
2. 前記処理要求は、前記クライアント装置の識別情報を含むことを特徴とする請求項１に記載の負荷分散プログラム。
3. 前記複数のサーバは、３以上のサーバであって、
   前記処理要求を送信する処理は、
   前記第１のサーバで実行しないと判断した場合、前記複数のサーバが形成する環状または直線状の論理的な通信経路において前記第１のサーバと隣接しており前記他のサーバとは異なる第２のサーバに、前記処理要求を送信することを特徴とする請求項１または２に記載の負荷分散プログラム。
4. 前記複数のサーバは、３以上のサーバであって、
   前記第１のサーバに、
   前記第１のサーバで実行しないと判断した場合、前記複数のサーバが形成する環状または直線状の論理的な通信経路における前記第１のサーバと所定の方向で接続する前記複数のサーバの数未満であって２以上のサーバと、前記２以上のサーバの各々のサーバおよび前記第１のサーバの間の前記通信経路上での距離を表す情報と、を関連付けた情報を参照して、前記距離を表す情報に基づいて、前記２以上のサーバから第２のサーバを決定する、処理を実行させ、
   前記処理要求を送信する処理は、
   決定した前記第２のサーバに前記処理要求を送信する、
   処理を実行させることを特徴とする請求項１〜３のいずれか一つに記載の負荷分散プログラム。
5. クライアント装置と接続する複数の負荷分散装置のうちの第１の負荷分散装置であって、
   前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数の負荷分散装置のうちの前記第１の負荷分散装置とは異なる他の負荷分散装置から受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１の負荷分散装置で実行するか否かを判断し、
   前記第１の負荷分散装置で実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
   前記第１の負荷分散装置で実行しないと判断した場合、前記複数の負荷分散装置のうちの第２の負荷分散装置に前記処理要求を送信する、
   制御部を有することを特徴とする負荷分散装置。
6. クライアント装置と複数のサーバとを有する負荷分散システムであって、
   前記クライアント装置は、
   前記複数のサーバのうちの第１のサーバに処理要求を発行し、
   前記第１のサーバは、
   前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
   前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
   前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信し、
   前記クライアント装置は、
   前記複数のサーバのうちの前記処理要求に対する処理を実行したサーバから、前記処理要求に対する処理の結果を受信する、
   ことを特徴とする負荷分散システム。
7. クライアント装置と接続する複数のサーバのうちの第１のサーバが、
   前記クライアント装置から発行された処理要求を前記クライアント装置、または前記複数のサーバのうちの前記第１のサーバとは異なる他のサーバから受信した場合、所定の条件に基づいて、前記処理要求に対する処理を前記第１のサーバで実行するか否かを判断し、
   前記第１のサーバで実行すると判断した場合、前記処理要求に対する処理を実行して、前記処理要求に対する処理の結果を前記クライアント装置に送信し、
   前記第１のサーバで実行しないと判断した場合、前記複数のサーバのうちの第２のサーバに前記処理要求を送信する、
   処理を実行することを特徴とする負荷分散方法。

Images