バスシステム
【課題】各サーバに要求される負荷を効率よく分散させることが可能なバスシステムを提供する。
【解決手段】クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する。
【解決手段】クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＳＢ（Enterprise Service Bus）などのバスシステムに関する。
【背景技術】
【０００２】
ＳＯＡ（Service-Oriented Architecture）における既存システムのサービス化を行うために利用される技術として、ＥＳＢと呼ばれるバスシステムを利用する方法が存在する。このＥＳＢ概念は、サービス（アプリケーションやコンポーネント）へのアクセスを行い、複数のサービスを協調・連携動作するＳＯＡシステムを、論理的なソフトウェアバスに基づいて構成するというソフトウェア設計上の考え方である。
【０００３】
図９は従来の負荷分散システム５０の構成例を示す図である。
各サーバ１０ａ、１０ｂに実装されたアプリケーションなどのサービスＡ、Ｂと、各クライアント２０ａ〜２０ｃに実装されたクライアントプログラムＣＰ１〜ＣＰ３とは、ＥＳＢシステム３０を介して接続される。各サービスＡ、Ｂと各プログラムＣＰ１〜ＣＰ３との間の通信は、全てＥＳＢシステム３０を介して行われる。なお、各サービスＡ、ＢとＥＳＢシステム３０の間は、汎用的なＨＴＴＰ、ＳＯＡＰ、ＪＭＳ等により通信が行われる。
【０００４】
ここで、ＥＳＢシステム３０は、クライアントアプリケーションＣＰからのリクエストに応じて所望のサービス（例えばサービスＡ）へアクセスを行うが、リクエストを受けたサービスＡを実装したサーバ（例えばサーバ１０ａ）の処理能力が低下している場合には、該サービスＡはリクエストを処理しきれないことがある。
【０００５】
かかる問題を解消するために、負荷分散を実現するロードバランサをＥＳＢシステムに実装することで、単一のサーバに負荷が集中することを防ぐことが昨今では一般的となっている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−１８２６４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図１０および図１１は、ロードバランサ３１を搭載したＥＳＢシステム３０の問題点を説明するための図である。
図１０に示すように、クライアントプログラムＣＰ１がサービスＡを利用している最中に、クライアントプログラムＣＰ２がサービスＢに対してメッセージサイズＭ１のリクエストを行ったとする。この場合、ＥＳＢシステム３０のロードバランサ３１は、クライアントプログラムＣＰ１によってサーバ１０ａのサービスＡが利用されていることから、すでにリソースが使用されているサーバ１０ａのサービスＢではなく、リソースが使用されていないサーバ１０ｂのサービスＢへ該リクエストを送る。この結果、サーバ１０ａにおいては、サービス１０ａが利用されることでリソースの５０％が使用され、サーバ１０ｂにおいては、サービス１０ｂが利用されることでリソースの４０％が使用される（図１０参照）。
【０００８】
その後、図１１に示すように、クライアントプログラムＣＰ３がサービスＢに対して、リソースの６０％の使用が要求される大きなメッセージサイズＭ２（＞Ｍ１）のリクエストを行ったとする。サーバ１０ｂにおいては、すでにサービスＢが利用されていることから、ロードバランサ３１は、サーバ１０ａのサービスＢへのリクエストを試みる。しかしながら、サーバ１０ａにおいては、サービスＡの利用によりリソースの５０％が使用されているため、クライアントプログラムＣＰ３からのリクエストに応えることができない、という問題が生じ得る。
【０００９】
本発明は以上説明した事情を鑑みてなされたものであり、各サーバに要求される負荷を効率よく分散させることが可能なバスシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係るバスシステムは、クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択することを特徴とする。
【００１１】
かかる構成によれば、サーバの負荷状況（別言すればリソースの使用状況）に応じて適切なサーバにリクエストを振り分けるため、効率よくサーバを利用することが可能となる。
【発明の効果】
【００１２】
以上説明したように、本発明によれば、各サーバに要求される負荷を効率よく分散させることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に係る負荷分散システムの概略構成を示す図である。
【図２】同実施形態に係るリソース情報を例示した図である。
【図３】同実施形態に係るステータステーブルを例示した図である。
【図４】同実施形態に係る予測処理性能テーブルを例示した図である。
【図５】同実施形態に係るロードバランサテーブルを例示した図である。
【図６】同実施形態に係るテーブル更新処理を示すシーケンス図である。
【図７】同実施形態に係るリクエスト処理を示すシーケンス図である。
【図８】変形例に係る負荷分散システムの概略構成を示す図である。
【図９】従来の負荷分散システムの概略構成図である。
【図１０】ロードバランサを搭載した従来のＥＳＢシステムの問題点を説明するための図である。
【図１１】ロードバランサを搭載した従来のＥＳＢシステムの問題点を説明するための図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。
【００１５】
Ａ．本実施形態
（１）実施形態の構成
図１は、本実施形態に係る負荷分散システム５００の構成例を示す図である。
複数のサービスを提供するサーバ１００と、各サービスを利用するクライアントプログラムＣＰ１が搭載されたクライアント２００と、クライアントプログラムＣＰからのリクエストを適切なサーバ１００のサービスに割り振り等を行うＥＳＢシステム３００とを備えて構成される。なお、図１では説明の便宜上、サーバを２台、クライアントを１台のみ図示しているが、本来は多数のサーバ、クライアントが存在する。また、各サーバ１００が提供するサービスの種類（本実施形態ではサービスＡ、Ｂ、Ｃを想定）や数等も図１に示したものに限定する趣旨でないのはもちろんである。
【００１６】
各サーバ１００は、クライアントプログラムＣＰからのリクエストに応じて、サービスを提供する。サーバ１００に実装された各サービスは、サーバ１００のハードウェア資源（ＣＰＵやＲＯＭ、ＲＡＭなど）と協働することにより、リスナ手段１１１、アプリケーション実行手段１１２、リソースモニタ手段１１３、エージェント手段１１４を実現する。
【００１７】
リスナ手段１１１は、クライアントプログラムＣＰからＥＳＢシステム３００を介してリクエストを受信する一方、アプリケーション実行手段１１２は、リスナ手段１１１が受信したリクエストに応じて該サービスの処理を実行する。これらリスナ手段１１１やアプリケーション実行手段１１２は、周知のWebサーバソフトウェア（Apache HTTP Serverなど）とHTMLファイルなどによって実現される。
【００１８】
リソースモニタ手段１１３は、サーバ１００が提供するサービスごとに、ハードウェアリソース（ＣＰＵやメモリなど）の使用状況などをあらわす情報（以下、リソース情報という）を所定タイミングで集計し、エージェント手段１１４に送信する。各サービス１００のエージェント手段１１４は、ＥＳＢシステム３００のリスナ手段３１１ｂへ送る。
【００１９】
図２は、サーバ１００ａの各サービスＡ、ＢからＥＳシステム３００へ提供されるリソース情報を例示した図である。
図２に示すように、各サービスＡ、Ｂが提供するリソース情報には、当該サービスを利用するクライアント２００を識別するクライアントＩＤと、当該クライアント２００から送信されるメッセージのサイズ（リクエストメッセージサイズ）と、ハードウェアリソースの詳細な使用状況をあらわす情報（リソース詳細情報）とが含まれている。一例を挙げて説明すると、サービスＡの利用に関し、クライアントαから送信されるリクエストメッセージサイズ「２ＭＢ」のリクエストに応じて、ＣＰＵ使用率「２０％」、メモリ使用量「４０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される一方、クライアントβから送信されるリクエストメッセージサイズ「１ＭＢ」のリクエストに応じて、ＣＰＵ使用率「１０％」、メモリ使用量「２０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される・・・等の情報がサービスＡのリソース情報に含まれている。
【００２０】
同様に、サービスＢの利用に関し、クライアントβから送信されるリクエストメッセージサイズ「２ＭＢ」のリクエストに応じて、ＣＰＵ使用率「２０％」、メモリ使用量「２０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される一方、クライアントγから送信されるリクエストメッセージサイズ「３ＭＢ」のリクエストに応じて、ＣＰＵ使用率「３０％」、メモリ使用量「４０ＫＢ」、ＮＩＣ使用量「１５％」のハードウェアリソースが使用される・・・等の情報がサービスＳＶ２のリソース情報に含まれている。
【００２１】
なお、上記説明では、サーバ１００ａに実装された各サービスＡ、ＢからＥＳＢシステム３００へ提供される各リソース情報を例示したが、他のサーバ１００に実装された各サービスも同様にしてリソース情報を提供する。
【００２２】
ＥＳＢシステム３００は、ＥＳＢシステム３００に実装されたソフトウェアがハードウェア資源と協働することにより、リスナ手段３１１ａ、３１１ｂ、エージェント集計手段３１２、ロードバランサ３１３、レジストリ更新手段３１４を実現する。
【００２３】
リスナ手段３１１ａは、クライアント２００（クライアントプログラムＣＰ）から特定サービス（例えばサービスＡ）のリクエストなどを受信し、これをロードバランサ３１３に送信する。リスナ手段３１１ｂは、各サービスから送信されるリソース情報を受信し、これをエージェント集計手段３１２に渡す。
【００２４】
エージェント集計手段（収集手段）３１２は、各サービスから受信するリソース情報（サーバの負荷状況）をまとめることにより、ステータステーブルＴＡ１を作成する。
図３は、ステータステーブルＴＡ１の登録内容を例示した図である。
ステータステーブルＴＡ１には、サービスの種類と、サービスを提供するサーバ１００の名前と、当該サーバのリソース詳細情報とが対応づけて登録されている。例えば、サービスＡは、サーバ１００ａとサーバ１００ｂによって提供されており、サーバ１００ａは、サービスＡの利用によりＣＰＵ使用率が「６０％」、メモリ使用量が「１ＧＢ」、ＮＩＣ使用量が「４０％」のハードウェアリソースが使用され、サーバ１００ｂは、サービスＳBの利用によりＣＰＵ使用率が「２０％」、メモリ使用量が「０．５ＧＢ」、ＮＩＣ使用量が「２０％」のハードウェアリソースが使用される。
【００２５】
レジストリ更新手段（予測手段）３１４は、各サービスから受信するリソース情報（別言すれば、サービスの過去の処理特性）に基づき、リクエスト毎の予測処理性能テーブルＴＡ２を作成・更新し、これをサービスレジストリ３１４ａに格納する。
図４は、予測処理性能テーブルＴＡ２を例示した図である。
予測処理性能テーブルＴＡ２には、リクエスト詳細情報と、予測リソース情報とが対応づけて登録されている。ここで、リクエスト詳細情報とは、サービス名とリクエストメッセージサイズ（以下、単にメッセージサイズと略称）とを含む情報であり、予測リソース情報とは、予測されるサーバ１００のハードウェア資源の使用状況（すなわち、予測されるサーバの負荷量）をあらわす情報である。例えば、クライアント２００からサービスＡに対してメッセージサイズ２ＭＢのリクエストメッセージが送信された場合には、ＣＰＵ使用率（予測値）が「２０％」、メモリ使用量（予測値）が「４０ＫＢ」、ＮＩＣ使用量（予測値）が「２０％」使用されると予測される。同様に、クライアント２００からサービスＡに対してメッセージサイズ１ＭＢのリクエスメッセージが送信された場合には、ＣＰＵ使用率（予測値）が「１０％」、メモリ使用量（予測値）が「２０ＫＢ」、ＮＩＣ使用量（予測値）が「１０％」使用されると予測される。
【００２６】
ロードバランサ３１３は、各サービスから受信するリソース情報に基づき、ロードバランステーブルＴＡ３を作成・更新し、これをロードバランスレジストリ３１３ａに格納する。さらに、ロードバランサ（選択手段、送信手段）３１３は、ロードバランステーブルＴＡ３等を参照することで、クライアント２００からのリクエストの送信先となるサーバを選択し、選択したサーバ１００のサービス（例えばサーバ１００ａのサービスＡ）に対してリクエストを転送する。
【００２７】
図５は、ロードバランステーブルＴＡ３を例示した図である。
ロードバランステーブルＴＡ３には、サーバ１００の名前と、該サーバ１００が提供するサービスの種類と、該サーバ１００の利用に関する優先度（以下、単に優先度という）と、ステータス（active, nonactiveなど）とが対応づけて登録されている。
【００２８】
ここで、優先度は、数値が高いほどクライアントからのリクエストを割り当てる確率が高いことを意味する。従って、図５に示す例ではサーバ１００ａに設定された優先度が最も高い（具体的には優先度「１０」）であることから、サーバ１００ａは次にクライアントからのリクエストが割り当てられる確率が高いと予測される。
【００２９】
（２）実施形態の動作
２−１．テーブル更新処理
図６は、ＥＳＢシステム３００において実行されるテーブル更新処理を示すシーケンス図である。なお、以下の説明ではサーバ１００ａのサービスＡからＥＳＢシステム３００にリソース情報が送信される場合を想定する。
サービスＡのエージェント手段１１４は、リソースモニタ手段１１３に対して定期的にリソース情報（リクエスト毎または全体のリソース情報）の転送要求を行う（ステップＡ１）。なお、転送要求は、不定期であっても良い。
【００３０】
リソースモニタ手段１１３は、サービスＡが稼動するサーバ１００ａのリソース情報を取得し、これをエージェント手段１１４に返す（ステップＡ２）。リソースモニタ手段１１３が取得するリソース情報には、例えば図２の上段に示すような当該サービスＡを利用するクライアント２００を識別するクライアントＩＤと、当該クライアント２００から送信されるメッセージのサイズ（リクエストメッセージサイズ）と、ハードウェアリソースの詳細な使用状況をあらわす情報（リソース詳細情報）が含まれる。なお、リソース詳細情報には、ＣＰＵ使用率、メモリ使用量、ＮＩＣ使用量のほか、例えば通信接続数やネットワーク帯域使用率など、様々な情報を含んで良いのはもちろんである。
【００３１】
エージェント手段１１４は、リソース情報を取得すると、これをＥＳＢシステム３００のリスナ３１１ｂに送信する（ステップＡ３）。なお、通信プロトコルは特に限定されない。リスナ手段３１１ｂは、サーバ１００ａのサービスＡからリソース情報を受信すると、これをエージェント集計手段３１２に送る（ステップＡ４）。エージェント集計手段３１２は、各サーバ１００の各サービスから送信される様々なリソース情報を集め、図３に示すようなステータステーブルＴＡ１を作成するとともに、該リソース情報に基づいて図４に示すような予測処理性能テーブルＴＡ２を作成・更新する（ステップＡ５）。
【００３２】
そして、エージェント集計手段３１２は、ロードバランサレジストリ３１３ａにアクセスし、ロードバランサテーブルＴＡ３を読みこむ（ステップＡ６）。図５に示すように、ロードバランステーブルＴＡ３には、サーバ１００の名前と、該サーバ１００が提供するサービスの種類と、優先度というと、ステータス（active, nonactiveなど）とが対応づけて登録されている。エージェント集計手段３１２は、例えば図３に示すステータステーブルＴＡ１と図５に示すロードバランサテーブルＴＡ３に基づいて、ロードバランサテーブルＴＡ３の各サービスに対応づけて登録されている優先度（重み付け）を変更し、ロードバランサテーブルＴＡ３の更新を行う（ステップＡ７→ステップＡ８）。この優先度は、当該時点での負荷（すなわちリソースの使用率等）が大きいものほど高く設定される。
【００３３】
以上の処理が終了すると、エージェント集計手段３１２は、レジストリ更新手段３１４に対してサービスレジストリ３１４ａに登録されている予測処理性能テーブルＴＡ２の更新を依頼する（ステップＡ９）。レジストリ更新手段３１４は、エージェント集計手段３１２からの更新依頼を受け、リクエストごとにメッセージサイズと紐付け、メッセージサイズごとの予測リソース情報を更新し（ステップＡ１０）、処理を終了する。なお、優先度の変更ポリシーや優先度の設定ルールなどは、負荷分散システム５００の設計などに応じて適宜設定・変更可能である。
【００３４】
２−２．リクエスト処理
図７は、クライアントからサービスのリクエストがあったときにＥＳＢシステム３００において実行されるリクエスト処理を示すシーケンス図である。
クライアント（クライアントプログラムＣＰ）２００は、特定サービス（例えばサービスＡ）を利用するべく、所定のメッセージサイズ（例えば２ＭＢ）のリクエストをＥＳＢシステム３００に送る（ステップＢ１）。ＥＳＢシステム３００のロードバランサ３１３は、リスナ手段３１１ａからリクエストを受信すると、リクエスト先のサービス（例えばサービスＡ）のプロトコルにあわせてプロトコル変換を行うとともに、ロードバランサテーブルＴＡ３からロードバランサテーブルＴＡ３を取得する（ステップＢ２）。さらに、ロードバランサ３１３は、サービスレジストリ３１４ａに登録されている予測処理性能テーブルＴＡ２を取得し (ステップＢ３)、クライアント２００から送信されるリクエストのメッセージサイズ、リクエスト先のサービスをキーとして、レジストリ更新テーブルＴＡを検索することにより、当該リクエストに応じたサービスを提供する際に必要となるサーバの予測リソース情報（ＣＰＵの使用率、メモリ使用量、ＮＩＣ使用量など）を把握する。
【００３５】
そして、ロードバランサ３１３は、ロードバランサテーブルＴＡ３を参照することでリクエスト先のサービスがデプロイされているサーバ（例えばサーバ１００ａ）を把握するとともに、該サーバが複数ある場合には（例えばサーバ１００ａ、１００ｂ）、各サーバに対応づけて登録されている優先度を参照し、最も優先度の高いサーバ（例えばサーバ１００ａ）を選択する（ステップＢ３）。ここで、優先度はリソースの使用量が高いものほど、高く設定されている。よって、サーバの選択に際しては、当該リクエストを処理できるサーバ１００であって、もっとも余剰リソースの少ないサーバ１００が選択されることとなる。ロードバランサ３１３は、このようにして選択したサーバ１００のサービス（例えばサーバ１００ａのサービスＡ）に対してリクエストを転送し（ステップＢ４）、処理を終了する。
【００３６】
以上説明したように、本実施形態によれば、サーバのリソースの使用状況に応じて適切なサーバにリクエストを振り分けるため、効率よくサーバを利用することができる。
また、各サーバの活性もチェックしているため（ロードバランサテーブルＴＡ３参照）、システムダウンしているサーバにアクセスしてしまう等の動作も未然に防止することが可能となる。さらに、リソース枯渇を抑制することができるため、リクエストを送信してからのTAT（Turn Around Time）を平坦化等することが可能となる。
加えて、活性チェックを行っているため、意図的にサーバを停止させてリソースを動的に変更することも可能となる。
【００３７】
Ｂ．変形例
上述した本実施形態では、ロードバランサテーブルＴＡ３が格納されるロードバランサレジストリ３１３ａをＥＳＢシステム３００の中に設けた態様を例示したが、ＥＳＢシステム３００の外部にロードバランサテーブルＴＡ３が格納されるデータベースＤＢを設けても良い。
【００３８】
図８は、変形例に係る負荷分散システム５００’の構成を示す図であり、図１に対応している。なお、図１に対応する部分には同一符号を付し、詳細な説明は割愛する。
負荷分散システム５００’は、複数のＥＳＢシステム３００ａ、３００ｂを備えており、ＥＳＢシステム３００ａ、３００ｂの外部にはロードバランサテーブルＴＡ３が格納されるデータベースＤＢが設けられている。
【００３９】
ＥＳＢシステム３００ａ、３００ｂの外部にデータベースＤＢを設けた場合には、各ＥＳＢシステム３００ａ、３００ｂがロードバランサテーブルＴＡ３に登録された情報を取得等する際、ネットワーク通信が必要となるが、各ＥＳＢシステム３００ａ、３００ｂが情報を共有できるメリットがある。さらに、信頼性の高いデータベースＤＢを利用することで、データベースＤＢに登録されたデータの紛失や問題発生時のロールバック等を行うことも可能となる。
【００４０】
なお、本実施形態等において示した各処理のステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。さらに本明細書等において、手段とは、単に物理的手段を意味するものではなく、その手段が有する機能をソフトウェアによって実現する場合も含む。さらにまた、１つの手段が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段の機能が１つの物理的手段により実現されてもよい。また、本発明に係るソフトウェアの開発支援プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【００４１】
また、本実施形態や変形例で示した態様の一部又は全部は、付記のように記載することもできるが、これに限定されるものではない。
【００４２】
（付記１）クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とするバスシステム。
【００４３】
（付記２）前記収集手段は、前記各サーバが提供する各サービスから、当該サーバのリソースの使用状況をあらわす情報を収集する、ことを特徴とする付記１に記載のバスシステム。
【００４４】
（付記３）前記サービスの過去の処理特性には、当該サービスの種類、当該サービスのリクエストメッセージサイズ、当該サービスの提供のために要したサーバの負荷量が含まれる、ことを特徴とする付記１または２に記載のバスシステム。
【００４５】
（付記４）前記優先度は、前記選択手段により当該時点での負荷が大きなものほど高く設定される、ことを特徴とする付記１〜３のいずれか１の付記に記載のバスシステム。
【００４６】
（付記５）前記予測手段は、前記収集手段によって収集された各サーバの負荷状況に基づいて、予測する前記リクエストに応じたサービスの提供に係るサーバの負荷量を更新する、付記１〜４のいずれか１の付記に記載のバスシステム。
【００４７】
（付記６）クライアントと、前記クライアントからのリクエストに応じてサービスを提供する複数のサーバと、前記各サーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムと、を備えた負荷分散システムであって、前記バスシステムは、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散システム。
【００４８】
（付記７）クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現する方法であって、前記各サーバの負荷状況を収集する収集ステップと、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測ステップと、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択ステップと、選択されたサーバに前記クライアントからのリクエストを送信する送信ステップとを含み、前記選択ステップにおいては、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散方法。
【符号の説明】
【００４９】
５００，５００’…負荷分散システム、１００…サーバ、１１１，３１１ａ，３１１ｂ…リスナ手段、１１２…アプリケーション実行手段、１１３…リソースモニタ手段、１１４…エージェント手段、２００…クライアント、３００…ＥＳＢシステム、３１２…エージェント集計手段、３１３…ロードバランサ、３１３ａ…ロードバランサレジストリ、３１４…レジストリ更新手段、３１４ａ…サービスレジストリ、ＤＢ…データベース、ＴＡ１…ステータステーブル、ＴＡ２…予測処理性能テーブル、ＴＡ３…ロードバランサテーブル。
【技術分野】
【０００１】
本発明は、ＥＳＢ（Enterprise Service Bus）などのバスシステムに関する。
【背景技術】
【０００２】
ＳＯＡ（Service-Oriented Architecture）における既存システムのサービス化を行うために利用される技術として、ＥＳＢと呼ばれるバスシステムを利用する方法が存在する。このＥＳＢ概念は、サービス（アプリケーションやコンポーネント）へのアクセスを行い、複数のサービスを協調・連携動作するＳＯＡシステムを、論理的なソフトウェアバスに基づいて構成するというソフトウェア設計上の考え方である。
【０００３】
図９は従来の負荷分散システム５０の構成例を示す図である。
各サーバ１０ａ、１０ｂに実装されたアプリケーションなどのサービスＡ、Ｂと、各クライアント２０ａ〜２０ｃに実装されたクライアントプログラムＣＰ１〜ＣＰ３とは、ＥＳＢシステム３０を介して接続される。各サービスＡ、Ｂと各プログラムＣＰ１〜ＣＰ３との間の通信は、全てＥＳＢシステム３０を介して行われる。なお、各サービスＡ、ＢとＥＳＢシステム３０の間は、汎用的なＨＴＴＰ、ＳＯＡＰ、ＪＭＳ等により通信が行われる。
【０００４】
ここで、ＥＳＢシステム３０は、クライアントアプリケーションＣＰからのリクエストに応じて所望のサービス（例えばサービスＡ）へアクセスを行うが、リクエストを受けたサービスＡを実装したサーバ（例えばサーバ１０ａ）の処理能力が低下している場合には、該サービスＡはリクエストを処理しきれないことがある。
【０００５】
かかる問題を解消するために、負荷分散を実現するロードバランサをＥＳＢシステムに実装することで、単一のサーバに負荷が集中することを防ぐことが昨今では一般的となっている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−１８２６４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図１０および図１１は、ロードバランサ３１を搭載したＥＳＢシステム３０の問題点を説明するための図である。
図１０に示すように、クライアントプログラムＣＰ１がサービスＡを利用している最中に、クライアントプログラムＣＰ２がサービスＢに対してメッセージサイズＭ１のリクエストを行ったとする。この場合、ＥＳＢシステム３０のロードバランサ３１は、クライアントプログラムＣＰ１によってサーバ１０ａのサービスＡが利用されていることから、すでにリソースが使用されているサーバ１０ａのサービスＢではなく、リソースが使用されていないサーバ１０ｂのサービスＢへ該リクエストを送る。この結果、サーバ１０ａにおいては、サービス１０ａが利用されることでリソースの５０％が使用され、サーバ１０ｂにおいては、サービス１０ｂが利用されることでリソースの４０％が使用される（図１０参照）。
【０００８】
その後、図１１に示すように、クライアントプログラムＣＰ３がサービスＢに対して、リソースの６０％の使用が要求される大きなメッセージサイズＭ２（＞Ｍ１）のリクエストを行ったとする。サーバ１０ｂにおいては、すでにサービスＢが利用されていることから、ロードバランサ３１は、サーバ１０ａのサービスＢへのリクエストを試みる。しかしながら、サーバ１０ａにおいては、サービスＡの利用によりリソースの５０％が使用されているため、クライアントプログラムＣＰ３からのリクエストに応えることができない、という問題が生じ得る。
【０００９】
本発明は以上説明した事情を鑑みてなされたものであり、各サーバに要求される負荷を効率よく分散させることが可能なバスシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係るバスシステムは、クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択することを特徴とする。
【００１１】
かかる構成によれば、サーバの負荷状況（別言すればリソースの使用状況）に応じて適切なサーバにリクエストを振り分けるため、効率よくサーバを利用することが可能となる。
【発明の効果】
【００１２】
以上説明したように、本発明によれば、各サーバに要求される負荷を効率よく分散させることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態に係る負荷分散システムの概略構成を示す図である。
【図２】同実施形態に係るリソース情報を例示した図である。
【図３】同実施形態に係るステータステーブルを例示した図である。
【図４】同実施形態に係る予測処理性能テーブルを例示した図である。
【図５】同実施形態に係るロードバランサテーブルを例示した図である。
【図６】同実施形態に係るテーブル更新処理を示すシーケンス図である。
【図７】同実施形態に係るリクエスト処理を示すシーケンス図である。
【図８】変形例に係る負荷分散システムの概略構成を示す図である。
【図９】従来の負荷分散システムの概略構成図である。
【図１０】ロードバランサを搭載した従来のＥＳＢシステムの問題点を説明するための図である。
【図１１】ロードバランサを搭載した従来のＥＳＢシステムの問題点を説明するための図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を参照しつつ詳細に説明する。
【００１５】
Ａ．本実施形態
（１）実施形態の構成
図１は、本実施形態に係る負荷分散システム５００の構成例を示す図である。
複数のサービスを提供するサーバ１００と、各サービスを利用するクライアントプログラムＣＰ１が搭載されたクライアント２００と、クライアントプログラムＣＰからのリクエストを適切なサーバ１００のサービスに割り振り等を行うＥＳＢシステム３００とを備えて構成される。なお、図１では説明の便宜上、サーバを２台、クライアントを１台のみ図示しているが、本来は多数のサーバ、クライアントが存在する。また、各サーバ１００が提供するサービスの種類（本実施形態ではサービスＡ、Ｂ、Ｃを想定）や数等も図１に示したものに限定する趣旨でないのはもちろんである。
【００１６】
各サーバ１００は、クライアントプログラムＣＰからのリクエストに応じて、サービスを提供する。サーバ１００に実装された各サービスは、サーバ１００のハードウェア資源（ＣＰＵやＲＯＭ、ＲＡＭなど）と協働することにより、リスナ手段１１１、アプリケーション実行手段１１２、リソースモニタ手段１１３、エージェント手段１１４を実現する。
【００１７】
リスナ手段１１１は、クライアントプログラムＣＰからＥＳＢシステム３００を介してリクエストを受信する一方、アプリケーション実行手段１１２は、リスナ手段１１１が受信したリクエストに応じて該サービスの処理を実行する。これらリスナ手段１１１やアプリケーション実行手段１１２は、周知のWebサーバソフトウェア（Apache HTTP Serverなど）とHTMLファイルなどによって実現される。
【００１８】
リソースモニタ手段１１３は、サーバ１００が提供するサービスごとに、ハードウェアリソース（ＣＰＵやメモリなど）の使用状況などをあらわす情報（以下、リソース情報という）を所定タイミングで集計し、エージェント手段１１４に送信する。各サービス１００のエージェント手段１１４は、ＥＳＢシステム３００のリスナ手段３１１ｂへ送る。
【００１９】
図２は、サーバ１００ａの各サービスＡ、ＢからＥＳシステム３００へ提供されるリソース情報を例示した図である。
図２に示すように、各サービスＡ、Ｂが提供するリソース情報には、当該サービスを利用するクライアント２００を識別するクライアントＩＤと、当該クライアント２００から送信されるメッセージのサイズ（リクエストメッセージサイズ）と、ハードウェアリソースの詳細な使用状況をあらわす情報（リソース詳細情報）とが含まれている。一例を挙げて説明すると、サービスＡの利用に関し、クライアントαから送信されるリクエストメッセージサイズ「２ＭＢ」のリクエストに応じて、ＣＰＵ使用率「２０％」、メモリ使用量「４０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される一方、クライアントβから送信されるリクエストメッセージサイズ「１ＭＢ」のリクエストに応じて、ＣＰＵ使用率「１０％」、メモリ使用量「２０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される・・・等の情報がサービスＡのリソース情報に含まれている。
【００２０】
同様に、サービスＢの利用に関し、クライアントβから送信されるリクエストメッセージサイズ「２ＭＢ」のリクエストに応じて、ＣＰＵ使用率「２０％」、メモリ使用量「２０ＫＢ」、ＮＩＣ使用量「１０％」のハードウェアリソースが使用される一方、クライアントγから送信されるリクエストメッセージサイズ「３ＭＢ」のリクエストに応じて、ＣＰＵ使用率「３０％」、メモリ使用量「４０ＫＢ」、ＮＩＣ使用量「１５％」のハードウェアリソースが使用される・・・等の情報がサービスＳＶ２のリソース情報に含まれている。
【００２１】
なお、上記説明では、サーバ１００ａに実装された各サービスＡ、ＢからＥＳＢシステム３００へ提供される各リソース情報を例示したが、他のサーバ１００に実装された各サービスも同様にしてリソース情報を提供する。
【００２２】
ＥＳＢシステム３００は、ＥＳＢシステム３００に実装されたソフトウェアがハードウェア資源と協働することにより、リスナ手段３１１ａ、３１１ｂ、エージェント集計手段３１２、ロードバランサ３１３、レジストリ更新手段３１４を実現する。
【００２３】
リスナ手段３１１ａは、クライアント２００（クライアントプログラムＣＰ）から特定サービス（例えばサービスＡ）のリクエストなどを受信し、これをロードバランサ３１３に送信する。リスナ手段３１１ｂは、各サービスから送信されるリソース情報を受信し、これをエージェント集計手段３１２に渡す。
【００２４】
エージェント集計手段（収集手段）３１２は、各サービスから受信するリソース情報（サーバの負荷状況）をまとめることにより、ステータステーブルＴＡ１を作成する。
図３は、ステータステーブルＴＡ１の登録内容を例示した図である。
ステータステーブルＴＡ１には、サービスの種類と、サービスを提供するサーバ１００の名前と、当該サーバのリソース詳細情報とが対応づけて登録されている。例えば、サービスＡは、サーバ１００ａとサーバ１００ｂによって提供されており、サーバ１００ａは、サービスＡの利用によりＣＰＵ使用率が「６０％」、メモリ使用量が「１ＧＢ」、ＮＩＣ使用量が「４０％」のハードウェアリソースが使用され、サーバ１００ｂは、サービスＳBの利用によりＣＰＵ使用率が「２０％」、メモリ使用量が「０．５ＧＢ」、ＮＩＣ使用量が「２０％」のハードウェアリソースが使用される。
【００２５】
レジストリ更新手段（予測手段）３１４は、各サービスから受信するリソース情報（別言すれば、サービスの過去の処理特性）に基づき、リクエスト毎の予測処理性能テーブルＴＡ２を作成・更新し、これをサービスレジストリ３１４ａに格納する。
図４は、予測処理性能テーブルＴＡ２を例示した図である。
予測処理性能テーブルＴＡ２には、リクエスト詳細情報と、予測リソース情報とが対応づけて登録されている。ここで、リクエスト詳細情報とは、サービス名とリクエストメッセージサイズ（以下、単にメッセージサイズと略称）とを含む情報であり、予測リソース情報とは、予測されるサーバ１００のハードウェア資源の使用状況（すなわち、予測されるサーバの負荷量）をあらわす情報である。例えば、クライアント２００からサービスＡに対してメッセージサイズ２ＭＢのリクエストメッセージが送信された場合には、ＣＰＵ使用率（予測値）が「２０％」、メモリ使用量（予測値）が「４０ＫＢ」、ＮＩＣ使用量（予測値）が「２０％」使用されると予測される。同様に、クライアント２００からサービスＡに対してメッセージサイズ１ＭＢのリクエスメッセージが送信された場合には、ＣＰＵ使用率（予測値）が「１０％」、メモリ使用量（予測値）が「２０ＫＢ」、ＮＩＣ使用量（予測値）が「１０％」使用されると予測される。
【００２６】
ロードバランサ３１３は、各サービスから受信するリソース情報に基づき、ロードバランステーブルＴＡ３を作成・更新し、これをロードバランスレジストリ３１３ａに格納する。さらに、ロードバランサ（選択手段、送信手段）３１３は、ロードバランステーブルＴＡ３等を参照することで、クライアント２００からのリクエストの送信先となるサーバを選択し、選択したサーバ１００のサービス（例えばサーバ１００ａのサービスＡ）に対してリクエストを転送する。
【００２７】
図５は、ロードバランステーブルＴＡ３を例示した図である。
ロードバランステーブルＴＡ３には、サーバ１００の名前と、該サーバ１００が提供するサービスの種類と、該サーバ１００の利用に関する優先度（以下、単に優先度という）と、ステータス（active, nonactiveなど）とが対応づけて登録されている。
【００２８】
ここで、優先度は、数値が高いほどクライアントからのリクエストを割り当てる確率が高いことを意味する。従って、図５に示す例ではサーバ１００ａに設定された優先度が最も高い（具体的には優先度「１０」）であることから、サーバ１００ａは次にクライアントからのリクエストが割り当てられる確率が高いと予測される。
【００２９】
（２）実施形態の動作
２−１．テーブル更新処理
図６は、ＥＳＢシステム３００において実行されるテーブル更新処理を示すシーケンス図である。なお、以下の説明ではサーバ１００ａのサービスＡからＥＳＢシステム３００にリソース情報が送信される場合を想定する。
サービスＡのエージェント手段１１４は、リソースモニタ手段１１３に対して定期的にリソース情報（リクエスト毎または全体のリソース情報）の転送要求を行う（ステップＡ１）。なお、転送要求は、不定期であっても良い。
【００３０】
リソースモニタ手段１１３は、サービスＡが稼動するサーバ１００ａのリソース情報を取得し、これをエージェント手段１１４に返す（ステップＡ２）。リソースモニタ手段１１３が取得するリソース情報には、例えば図２の上段に示すような当該サービスＡを利用するクライアント２００を識別するクライアントＩＤと、当該クライアント２００から送信されるメッセージのサイズ（リクエストメッセージサイズ）と、ハードウェアリソースの詳細な使用状況をあらわす情報（リソース詳細情報）が含まれる。なお、リソース詳細情報には、ＣＰＵ使用率、メモリ使用量、ＮＩＣ使用量のほか、例えば通信接続数やネットワーク帯域使用率など、様々な情報を含んで良いのはもちろんである。
【００３１】
エージェント手段１１４は、リソース情報を取得すると、これをＥＳＢシステム３００のリスナ３１１ｂに送信する（ステップＡ３）。なお、通信プロトコルは特に限定されない。リスナ手段３１１ｂは、サーバ１００ａのサービスＡからリソース情報を受信すると、これをエージェント集計手段３１２に送る（ステップＡ４）。エージェント集計手段３１２は、各サーバ１００の各サービスから送信される様々なリソース情報を集め、図３に示すようなステータステーブルＴＡ１を作成するとともに、該リソース情報に基づいて図４に示すような予測処理性能テーブルＴＡ２を作成・更新する（ステップＡ５）。
【００３２】
そして、エージェント集計手段３１２は、ロードバランサレジストリ３１３ａにアクセスし、ロードバランサテーブルＴＡ３を読みこむ（ステップＡ６）。図５に示すように、ロードバランステーブルＴＡ３には、サーバ１００の名前と、該サーバ１００が提供するサービスの種類と、優先度というと、ステータス（active, nonactiveなど）とが対応づけて登録されている。エージェント集計手段３１２は、例えば図３に示すステータステーブルＴＡ１と図５に示すロードバランサテーブルＴＡ３に基づいて、ロードバランサテーブルＴＡ３の各サービスに対応づけて登録されている優先度（重み付け）を変更し、ロードバランサテーブルＴＡ３の更新を行う（ステップＡ７→ステップＡ８）。この優先度は、当該時点での負荷（すなわちリソースの使用率等）が大きいものほど高く設定される。
【００３３】
以上の処理が終了すると、エージェント集計手段３１２は、レジストリ更新手段３１４に対してサービスレジストリ３１４ａに登録されている予測処理性能テーブルＴＡ２の更新を依頼する（ステップＡ９）。レジストリ更新手段３１４は、エージェント集計手段３１２からの更新依頼を受け、リクエストごとにメッセージサイズと紐付け、メッセージサイズごとの予測リソース情報を更新し（ステップＡ１０）、処理を終了する。なお、優先度の変更ポリシーや優先度の設定ルールなどは、負荷分散システム５００の設計などに応じて適宜設定・変更可能である。
【００３４】
２−２．リクエスト処理
図７は、クライアントからサービスのリクエストがあったときにＥＳＢシステム３００において実行されるリクエスト処理を示すシーケンス図である。
クライアント（クライアントプログラムＣＰ）２００は、特定サービス（例えばサービスＡ）を利用するべく、所定のメッセージサイズ（例えば２ＭＢ）のリクエストをＥＳＢシステム３００に送る（ステップＢ１）。ＥＳＢシステム３００のロードバランサ３１３は、リスナ手段３１１ａからリクエストを受信すると、リクエスト先のサービス（例えばサービスＡ）のプロトコルにあわせてプロトコル変換を行うとともに、ロードバランサテーブルＴＡ３からロードバランサテーブルＴＡ３を取得する（ステップＢ２）。さらに、ロードバランサ３１３は、サービスレジストリ３１４ａに登録されている予測処理性能テーブルＴＡ２を取得し (ステップＢ３)、クライアント２００から送信されるリクエストのメッセージサイズ、リクエスト先のサービスをキーとして、レジストリ更新テーブルＴＡを検索することにより、当該リクエストに応じたサービスを提供する際に必要となるサーバの予測リソース情報（ＣＰＵの使用率、メモリ使用量、ＮＩＣ使用量など）を把握する。
【００３５】
そして、ロードバランサ３１３は、ロードバランサテーブルＴＡ３を参照することでリクエスト先のサービスがデプロイされているサーバ（例えばサーバ１００ａ）を把握するとともに、該サーバが複数ある場合には（例えばサーバ１００ａ、１００ｂ）、各サーバに対応づけて登録されている優先度を参照し、最も優先度の高いサーバ（例えばサーバ１００ａ）を選択する（ステップＢ３）。ここで、優先度はリソースの使用量が高いものほど、高く設定されている。よって、サーバの選択に際しては、当該リクエストを処理できるサーバ１００であって、もっとも余剰リソースの少ないサーバ１００が選択されることとなる。ロードバランサ３１３は、このようにして選択したサーバ１００のサービス（例えばサーバ１００ａのサービスＡ）に対してリクエストを転送し（ステップＢ４）、処理を終了する。
【００３６】
以上説明したように、本実施形態によれば、サーバのリソースの使用状況に応じて適切なサーバにリクエストを振り分けるため、効率よくサーバを利用することができる。
また、各サーバの活性もチェックしているため（ロードバランサテーブルＴＡ３参照）、システムダウンしているサーバにアクセスしてしまう等の動作も未然に防止することが可能となる。さらに、リソース枯渇を抑制することができるため、リクエストを送信してからのTAT（Turn Around Time）を平坦化等することが可能となる。
加えて、活性チェックを行っているため、意図的にサーバを停止させてリソースを動的に変更することも可能となる。
【００３７】
Ｂ．変形例
上述した本実施形態では、ロードバランサテーブルＴＡ３が格納されるロードバランサレジストリ３１３ａをＥＳＢシステム３００の中に設けた態様を例示したが、ＥＳＢシステム３００の外部にロードバランサテーブルＴＡ３が格納されるデータベースＤＢを設けても良い。
【００３８】
図８は、変形例に係る負荷分散システム５００’の構成を示す図であり、図１に対応している。なお、図１に対応する部分には同一符号を付し、詳細な説明は割愛する。
負荷分散システム５００’は、複数のＥＳＢシステム３００ａ、３００ｂを備えており、ＥＳＢシステム３００ａ、３００ｂの外部にはロードバランサテーブルＴＡ３が格納されるデータベースＤＢが設けられている。
【００３９】
ＥＳＢシステム３００ａ、３００ｂの外部にデータベースＤＢを設けた場合には、各ＥＳＢシステム３００ａ、３００ｂがロードバランサテーブルＴＡ３に登録された情報を取得等する際、ネットワーク通信が必要となるが、各ＥＳＢシステム３００ａ、３００ｂが情報を共有できるメリットがある。さらに、信頼性の高いデータベースＤＢを利用することで、データベースＤＢに登録されたデータの紛失や問題発生時のロールバック等を行うことも可能となる。
【００４０】
なお、本実施形態等において示した各処理のステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。さらに本明細書等において、手段とは、単に物理的手段を意味するものではなく、その手段が有する機能をソフトウェアによって実現する場合も含む。さらにまた、１つの手段が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段の機能が１つの物理的手段により実現されてもよい。また、本発明に係るソフトウェアの開発支援プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。
【００４１】
また、本実施形態や変形例で示した態様の一部又は全部は、付記のように記載することもできるが、これに限定されるものではない。
【００４２】
（付記１）クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とするバスシステム。
【００４３】
（付記２）前記収集手段は、前記各サーバが提供する各サービスから、当該サーバのリソースの使用状況をあらわす情報を収集する、ことを特徴とする付記１に記載のバスシステム。
【００４４】
（付記３）前記サービスの過去の処理特性には、当該サービスの種類、当該サービスのリクエストメッセージサイズ、当該サービスの提供のために要したサーバの負荷量が含まれる、ことを特徴とする付記１または２に記載のバスシステム。
【００４５】
（付記４）前記優先度は、前記選択手段により当該時点での負荷が大きなものほど高く設定される、ことを特徴とする付記１〜３のいずれか１の付記に記載のバスシステム。
【００４６】
（付記５）前記予測手段は、前記収集手段によって収集された各サーバの負荷状況に基づいて、予測する前記リクエストに応じたサービスの提供に係るサーバの負荷量を更新する、付記１〜４のいずれか１の付記に記載のバスシステム。
【００４７】
（付記６）クライアントと、前記クライアントからのリクエストに応じてサービスを提供する複数のサーバと、前記各サーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムと、を備えた負荷分散システムであって、前記バスシステムは、前記各サーバの負荷状況を収集する収集手段と、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散システム。
【００４８】
（付記７）クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現する方法であって、前記各サーバの負荷状況を収集する収集ステップと、前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測ステップと、収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択ステップと、選択されたサーバに前記クライアントからのリクエストを送信する送信ステップとを含み、前記選択ステップにおいては、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散方法。
【符号の説明】
【００４９】
５００，５００’…負荷分散システム、１００…サーバ、１１１，３１１ａ，３１１ｂ…リスナ手段、１１２…アプリケーション実行手段、１１３…リソースモニタ手段、１１４…エージェント手段、２００…クライアント、３００…ＥＳＢシステム、３１２…エージェント集計手段、３１３…ロードバランサ、３１３ａ…ロードバランサレジストリ、３１４…レジストリ更新手段、３１４ａ…サービスレジストリ、ＤＢ…データベース、ＴＡ１…ステータステーブル、ＴＡ２…予測処理性能テーブル、ＴＡ３…ロードバランサテーブル。
【特許請求の範囲】
【請求項１】
クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、
前記各サーバの負荷状況を収集する収集手段と、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、
選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、
前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とするバスシステム。
【請求項２】
前記収集手段は、
前記各サーバが提供する各サービスから、当該サーバのリソースの使用状況をあらわす情報を収集する、ことを特徴とする請求項１に記載のバスシステム。
【請求項３】
前記サービスの過去の処理特性には、当該サービスの種類、当該サービスのリクエストメッセージサイズ、当該サービスの提供のために要したサーバの負荷量が含まれる、ことを特徴とする請求項１または２に記載のバスシステム。
【請求項４】
前記優先度は、前記選択手段により当該時点での負荷が大きなものほど高く設定される、ことを特徴とする請求項１〜３のいずれか１の請求項に記載のバスシステム。
【請求項５】
前記予測手段は、前記収集手段によって収集された各サーバの負荷状況に基づいて、予測する前記リクエストに応じたサービスの提供に係るサーバの負荷量を更新する、請求項１〜４のいずれか１の請求項に記載のバスシステム。
【請求項６】
クライアントと、
前記クライアントからのリクエストに応じてサービスを提供する複数のサーバと、
前記各サーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムと、を備えた負荷分散システムであって、
前記バスシステムは、
前記各サーバの負荷状況を収集する収集手段と、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、
選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、
前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散システム。
【請求項７】
クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現する方法であって、
前記各サーバの負荷状況を収集する収集ステップと、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測ステップと、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択ステップと、
選択されたサーバに前記クライアントからのリクエストを送信する送信ステップとを含み、
前記選択ステップにおいては、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散方法。
【請求項１】
クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムであって、
前記各サーバの負荷状況を収集する収集手段と、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、
選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、
前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とするバスシステム。
【請求項２】
前記収集手段は、
前記各サーバが提供する各サービスから、当該サーバのリソースの使用状況をあらわす情報を収集する、ことを特徴とする請求項１に記載のバスシステム。
【請求項３】
前記サービスの過去の処理特性には、当該サービスの種類、当該サービスのリクエストメッセージサイズ、当該サービスの提供のために要したサーバの負荷量が含まれる、ことを特徴とする請求項１または２に記載のバスシステム。
【請求項４】
前記優先度は、前記選択手段により当該時点での負荷が大きなものほど高く設定される、ことを特徴とする請求項１〜３のいずれか１の請求項に記載のバスシステム。
【請求項５】
前記予測手段は、前記収集手段によって収集された各サーバの負荷状況に基づいて、予測する前記リクエストに応じたサービスの提供に係るサーバの負荷量を更新する、請求項１〜４のいずれか１の請求項に記載のバスシステム。
【請求項６】
クライアントと、
前記クライアントからのリクエストに応じてサービスを提供する複数のサーバと、
前記各サーバの負荷状況を収集し、収集結果に基づき負荷分散を実現するバスシステムと、を備えた負荷分散システムであって、
前記バスシステムは、
前記各サーバの負荷状況を収集する収集手段と、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測手段と、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択手段と、
選択されたサーバに前記クライアントからのリクエストを送信する送信手段とを備え、
前記選択手段は、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散システム。
【請求項７】
クライアントからのリクエストに応じてサービスを提供する複数のサーバの負荷状況を収集し、収集結果に基づき負荷分散を実現する方法であって、
前記各サーバの負荷状況を収集する収集ステップと、
前記各サーバが提供したサービスの過去の処理特性に基づき、前記リクエストに応じたサービスの提供に係るサーバの負荷量を予測する予測ステップと、
収集された前記各サーバの負荷状況と、予測された前記サーバの負荷量に基づいて、リクエスト先となるサーバを選択する選択ステップと、
選択されたサーバに前記クライアントからのリクエストを送信する送信ステップとを含み、
前記選択ステップにおいては、前記リクエストに応じたサービスを提供することができ、かつ、前記各サーバの負荷状況に応じて設定される優先度の最も高いサーバを、前記リクエスト先となるサーバとして選択する、ことを特徴とする負荷分散方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−１７０７５１（Ｐ２０１１−１７０７５１Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−３５９３３（Ｐ２０１０−３５９３３）
【出願日】平成２２年２月２２日（２０１０．２．２２）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２２年２月２２日（２０１０．２．２２）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]