(57)【要約】  【課題】業務アプリに対するリクエストを当該業務アプリが稼動しているコンピュータに振り分けて処理するシステムにおいて、各業務アプリのサービスレベルの低下を防止できるようにコンピュータを管理する。  【解決手段】リソース割当管理装置１は、業務アプリケーションが割当てられている各サーバ計算機３の単位時間当たりに処理可能なリクエスト数（リクエスト処理可能数）の総数から、当該業務アプリケーションが割当てられている各サーバ計算機が単位時間当たりに受付けたリクエスト数（リクエスト受信数）の総数を差し引いて、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量を計算する。そして、リソースが余っている業務アプリケーションに割当てられている少なくとも１つのサーバ計算機３の引当てを、リソースが不足している業務アプリケーションに変更する。  【選択図】図１
2006277458.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務アプリケーションのそれぞれを複数のコンピュータのうちの少なくともいずれか一つで稼動させ、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムに対して、業務アプリケーションを稼動させるコンピュータを決定するリソース割当管理装置であって、
業務アプリケーション毎に、当該業務アプリケーションをコンピュータで稼動させた場合に期待できる処理能力値が記憶された処理能力値記憶手段手段と、
業務アプリケーション毎に、当該業務アプリケーションが割り当てられたコンピュータ各々でのリクエスト処理量を記憶するリクエスト処理量記憶手段と、
業務アプリケーション毎に、前記処理能力値記憶手段に記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々の当該業務アプリケーションに対する処理能力値の総数から、前記リクエスト処理量記憶手段に記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々のリクエスト処理量の総数を差し引いた値を、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量として算出する提供可能リソース量算出手段と、
前記提供可能リソース量算出手段で算出したリソース量が第１の所定値より大きい業務アプリケーションであるリソース過剰アプリケーションに引当てられているコンピュータの引当てを、前記提供可能リソース量算出手段で算出したリソース量が第２の所定値未満の業務アプリケーションであるリソース不足アプリケーションへの引当てに変更する構成変更手段と、を有すること
を特徴とするリソース割当管理装置。
【請求項２】
請求項１に記載のリソース割当管理装置であって、
前記構成変更手段は、
前記リソース過剰アプリケーションに引当てられているコンピュータの引当てを前記リソース不足アプリケーションへの引当てに変更すると共に、前記リソース過剰アプリケーションに対して前記提供可能リソース量算出手段が算出したリソース量と前記第１の所定値との差分であるリソース過剰量から前記引当てを変更したコンピュータの当該リソース過剰アプリケーションに対する処理能力値を減算し、且つ、前記リソース不足アプリケーションに対して前記提供可能リソース量算出手段が算出したリソース量と前記第２の所定値との差分であるリソース不足量に前記引当てを変更したコンピュータの前記リソース不足アプリケーションに対する処理能力値を加算する処理を、複数の前記リソース過剰アプリケーションのうちの１つに対して、前記リソース不足量がなくなるか、もしくは、前記前記リソース過剰量がなくなるまで繰り返し、前記リソース過剰量がなくなった場合には、複数の前記リソース過剰アプリケーションの他の１つに対して前記処理を繰り返すこと
を特徴とするリソース割当管理装置。
【請求項３】
請求項１に記載のリソース割当管理装置であって、
前記構成変更手段は、
前記リソース過剰アプリケーションに引当てられているコンピュータの引当てを前記リソース不足アプリケーションへの引当てに変更すると共に、前記リソース過剰アプリケーションに対して前記提供可能リソース量算出手段が算出したリソース量と前記第１の所定値との差分であるリソース過剰量から前記引当てを変更したコンピュータの前記リソース過剰アプリケーションに対する処理能力を減算し、且つ、前記リソース不足アプリケーションに対して前記提供可能リソース量算出手段が算出したリソース量と前記第２の所定値との差分であるリソース不足量に前記引当てを変更したコンピュータの前記リソース不足アプリケーションに対する処理能力値を加算する処理を、前記リソース過剰量を有する複数の前記リソース過剰アプリケーションの各々に対して、前記リソース不足量がなくなるまで繰り返すこと
を特徴とするリソース割当管理装置。
【請求項４】
請求項１乃至３のいずれか一項に記載のリソース割当管理装置であって、
前記処理能力値記憶手段は、
業務アプリケーション毎に、当該業務アプリケーションに引当てられたコンピュータの他の業務アプリケーションへの引当てを許可するか否かを示す引当フラグを、コンピュータの当該業務アプリケーションに対する処理能力値と共に記憶しており、
前記構成変更手段は、
前記リソース過剰アプリケーションに対応付けられて前記処理能力値記憶手段に記憶されている引当フラグが「引当拒否」を示している場合は、当該リソース過剰アプリケーションに引当てられているコンピュータの引当てを、前記リソース不足アプリケーションへの引当てに変更しないこと
を特徴とするリソース割当管理装置。
【請求項５】
請求項１乃至３のいずれか一項に記載のリソース割当管理装置であって、
前記処理能力値記憶手段は、
業務アプリケーション毎に、当該業務アプリケーションの優先順位を、コンピュータの当該業務アプリケーションに対する処理能力値と共に記憶しており、
前記構成変更手段は、
前記リソース過剰アプリケーションに対応付けられて前記処理能力値記憶手段に記憶されている優先順位が前記リソース不足アプリケーションに対応付けられて前記処理能力値記憶手段に記憶されている優先順位よりも高い場合は、当該リソース過剰アプリケーションに引当てられているコンピュータの引当てを、前記リソース不足アプリケーションへの引当てに変更しないこと
を特徴とするリソース割当管理装置。
【請求項６】
請求項１乃至５のいずれか一項に記載のリソース割当管理装置であって、
前記構成変更手段により引当てが変更されやコンピュータに、前記リソース不足アプリケーションを送信して、稼動する業務アプリケーションを前記リソース過剰アプリケーションから前記リソース不足アプリケーションに変更させる業務アプリケーション配布手段をさらに有すること
を特徴とするリソース割当管理装置。
【請求項７】
請求項１乃至６に記載のリソース管理装置と、
複数のコンピュータと、
業務アプリケーションに対するリクエストを、前記複数のコンピュータのうちの当該業務アプリケーションが稼動しているコンピュータに振り分けるロードバランサと、を有すること
を特徴とするリソース割当管理システム。
【請求項８】
複数の業務アプリケーションのそれぞれを複数のコンピュータのうちの少なくともいずれか一つで稼動させ、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムに対して、業務アプリケーションを稼動させるコンピュータを決定するリソース割当方法であって、
前記リソース割当管理装置の記憶装置には、
業務アプリケーション毎に、当該業務アプリケーションをコンピュータで稼動させた場合に期待できる処理能力値が記憶された処理能力値管理テーブルと、
業務アプリケーション毎に、当該業務アプリケーションが割り当てられたコンピュータ各々でのリクエスト処理量を記憶するリクエスト処理量管理テーブルと、が記憶されており、
前記リソース割当管理装置の演算装置は、
業務アプリケーション毎に、前記処理能力値管理テーブルに記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々の当該業務アプリケーションに対する処理能力値の総数から、前記リクエスト処理量管理テーブルに記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々のリクエスト処理量の総数を差し引いた値を、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量として算出する提供可能リソース量算出ステップと、
前記提供可能リソース量算出ステップで算出したリソース量が第１の所定値より大きい業務アプリケーションであるリソース過剰アプリケーションに引当てられているコンピュータの引当てを、前記提供可能リソース量算出ステップで算出したリソース量が第２の所定値未満の業務アプリケーションであるリソース不足アプリケーションへの引当てに変更する構成変更ステップと、を行うこと
を特徴とするリソース割当方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータの中から所望の業務アプリケーションに割り当てるコンピュータを決定する技術に関する。
【背景技術】
【０００２】
特許文献１には、リアルタイムアプリケーションシステムに対して特定のリソースを予約するための技術が開示されている。該技術では、サービスレベルと、プロセッサ、メモリおよびディスク帯域各々のリソース量との対応をデータベースに蓄積しておく。そして、要求されるサービスレベルに対応付けられているリソース量からアプリケーションに割り当てるリソース量を決定し予約する。該技術によれば、特に複雑なパラメータの指定を行うことなく、容易にリソースの予約が行え、リソース量の予約によるリソース量浪費を防止することができる。
【０００３】
【特許文献１】特開２００１−３３１３３２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、データセンタでは、複数の業務アプリケーション（例えばＷｅｂサービスプログラム）のそれぞれを複数のコンピュータのうちの少なくともいずれか一つで稼動させ、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムが構築されている。このようなシステムでは、業務アプリケーションが割り当てられていないコンピュータをプールしておき、処理数の多い業務アプリケーションにプールしておいたコンピュータを割り当てて、割り当てたコンピュータで当該業務アプリケーションを稼動させることにより、当該処理数の多い業務アプリケーションに対するリソース（コンピュータ）量を増やす。このようにすることで、当該処理数の多い業務アプリケーションのサービスレベルの低下を防止している。ここで、サービスレベルとは、サービス提供者からサービス利用者に対して提供されるサービスのレベルのことであり、例えばサービス利用者の端末がリクエストを送信してから、該リクエストに対する結果を該サービス利用者の端末に応答するまでの時間で表される。上記特許文献１に記載の技術は、上記のシステムにおいて、各業務アプリケーションへのリソース（コンピュータ）の割り当てに適用することも可能である。しかし、上記特許文献１に記載の技術は次の点を考慮していない。
【０００５】
（１）プールされているコンピュータが常に存在するとは限らない。
【０００６】
（２）業務アプリケーションによって、また、時期、時刻によって、エンドユーザからのリクエスト数が異なる場合がある。
【０００７】
このため、複数の業務アプリケーションのそれぞれを複数のコンピュータのうちの少なくともいずれか一つで稼動させ、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムにおいて、各業務アプリケーションへのリソース（コンピュータ）の割り当てに上記特許文献１に記載の技術を適用した場合、効率のよい（リソースが不足したり、あるいは、リソースが過剰に割当てられることのない）リソースの割り当てが困難である。
【０００８】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムにおいて、各業務アプリケーションのサービスレベルの低下を防止できるように、各業務アプリケーションに割り当てるコンピュータを管理することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明では、業務アプリケーション毎に、業務アプリケーションが提供可能なサービスレベルと、当該業務アプリケーションが実際に要求されているサービスレベルとの差分、つまり、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量を計算する。例えば、業務アプリケーションが割当てられている各コンピュータの処理能力値から、当該業務アプリケーションが割当てられている各コンピュータのリクエスト処理量の総数を差し引いて、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量を計算する。そして、該リソース量が正の値を持つ業務アプリケーション、つまりリソースが余っている業務アプリケーションに割当てられている少なくとも１つのコンピュータの引当てを、当該リソース量が負の値を持つ業務アプリケーション、つまりリソースが不足している業務アプリケーションに変更する。
【００１０】
例えば、複数の業務アプリケーションのそれぞれを複数のコンピュータのうちの少なくともいずれか一つで稼動させ、業務アプリケーションに対するリクエストを当該業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムに対して、業務アプリケーションを稼動させるコンピュータを決定するリソース割当管理装置であって、
業務アプリケーション毎に、当該業務アプリケーションをコンピュータで稼動させた場合に期待できる処理能力値が記憶された処理能力値記憶手段手段と、
業務アプリケーション毎に、当該業務アプリケーションが割り当てられたコンピュータ各々でのリクエスト処理量を記憶するリクエスト処理量記憶手段と、
業務アプリケーション毎に、前記処理能力値記憶手段に記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々の当該業務アプリケーションに対する処理能力値の総数から、前記リクエスト処理量記憶手段に記憶されている、当該業務アプリケーションが割当てられたコンピュータ各々のリクエスト処理量の総数を差し引いた値を、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量として算出する提供可能リソース量算出手段と、
前記提供可能リソース量算出手段で算出したリソース量が第１の所定値より大きい業務アプリケーションであるリソース過剰アプリケーションに引当てられているコンピュータの引当てを、前記提供可能リソース量算出手段で算出したリソース量が第２の所定値未満の業務アプリケーションであるリソース不足アプリケーションへの引当てに変更する構成変更手段と、を有する。
【発明の効果】
【００１１】
本発明によれば、各業務アプリケーションのサービスレベルの低下を防止できるように、各業務アプリケーションに割り当てるコンピュータを管理することができる。
【発明を実施するための最良の形態】
【００１２】
以下に、本発明の実施の形態を説明する。
【００１３】
図１は本発明の一実施形態が適用されたリソース割当管理システムの概略図である。
【００１４】
図示するように、本実施形態のリソース割当管理システムは、リソース割当管理装置１と、複数のロードバランサ２１〜２ｎ（以下、単にロードバランサ２とも称する）と、複数のサーバ計算機３１〜３ｍと（以下、単にサーバ計算機３とも称する）と、インターネット７に接続されたルータ４と、を有する。
【００１５】
リソース割当管理装置１、ロードバランサ２、サーバ計算機３およびルータ４は、業務用ネットワーク５および管理用ネットワーク６のそれぞれを介して互いに接続されている。業務用ネットワーク５は、サーバ計算機３が業務アプリケーションによるサービスをインターネット７に接続されたクライアント端末（不図示）に提供するために使用されるネットワークである。また、管理用ネットワーク６は、リソース割当管理装置１がロードバランサ２、サーバ計算機３およびルータ４の保守・管理に用いるためのネットワークである。業務用ネットワーク５および管理用ネットワーク６は、別々のケーブルを用いて物理的に異ならせて構築してもよいし、あるいは、同じケーブル上に論理的に異ならせて構築してもよい。
【００１６】
ルータ４は、ロードバランサ２毎に、グローバルＩＰアドレスとローカルＩＰアドレスとの対応関係が記憶されたルーティングＴＬ（テーブル）４１を有する。ルータ４１は、インターネットを介してクライアント端末（不図示）から受信したリクエストを、ルーティングＴＬ４１に従い、該リクエストの宛先として指定されているグローバルＩＰアドレスに対応するローカルＩＰアドレスを持つロードバランサ２に送信する。また、ロードバランサ２から受信した該リクエストの処理結果を、インターネット７を介して当該リクエストの送信元であるクライアント端末（不図示）に送信する。ルータ４の他の機能は、既存のルータと同様であるので、その詳細な説明を省略する。
【００１７】
ロードバランサ２は、業務用ネットワーク５を介して少なくとも１つのサーバ計算機３と業務アプリケーションの負荷分散（水平スケーリング）システムを形成する。ロードバランサ２は、自身が利用可能なサーバ計算機３の情報が登録されたリソース管理ＴＬ２１を有する。そして、ルータ４から送られてきたリクエストを、業務用ネットワーク５を介して、リソース管理ＴＬ２１に登録されているサーバ計算機３のうち負荷状態が低いサーバ計算機３に送信し、当該サーバ計算機３に当該リクエストを処理させる。また、業務用ネットワーク５を介して、リソース管理ＴＬ２１に登録されているサーバ計算機３からリクエストの処理結果を受信し、この処理結果をルータ４を介して該リクエストの送信元に返信する。また、ロードバランサ２は、管理用ネットワーク６を介してリソース割当管理装置１から受信した指示に従い、リソース管理ＴＬ２１を更新する。ロードバランサ２のその他の機能は、既存の負荷分散システムで用いられているロードバランサと同様であるので、その詳細な説明を省略する。
【００１８】
サーバ計算機３は、実行中のモジュールＰＧ（プログラム）に従って、業務用ネットワーク５を介して受信したリクエストを処理し、自サーバ計算機３と共に負荷分散システムを形成するロードバランサ２あるいは他のサーバ計算機３にその結果を送信する。また、サーバ計算機３は、管理用ネットワーク６を介してリソース割当管理装置１より受信した指示に従い、モジュールＰＧの実行を制御する。業務アプリケーションは少なくとも１つのモジュールＰＧからなる。
【００１９】
図示するように、サーバ計算機３は、業務用ネットワーク５および管理用ネットワーク６に接続するためのネットワークＩＦ（インターフェース）部３１と、メトリック情報計測部３２と、インストーラ３３と、モジュール実行部３４と、を有する。
【００２０】
メトリック情報計測部３２は、自サーバ計算機３のメトリック情報を計測し、管理用ネットワーク６を介してリソース割当管理装置１に送信する。本実施形態では、メトリック情報として、単位時間当たりに業務用ネットワーク５から受信するリクエストの数（リクエスト受信数）を計測する。そして、計測したメトリック情報を、自サーバ計算機３の識別情報（例えばローカルアドレス）である計算機ＩＤと共に、管理用ネットワーク６を介してリソース割当管理装置１に送信する。
【００２１】
インストーラ３３は、管理用ネットワーク６を介してリソース割当管理装置１より受信した指示に従い、リソース割当管理装置１より指定されたモジュールＰＧをインストールして、モジュール実行部３４に実行させる。あるいは、モジュール実行部３４に実行中のモジュールＰＧを停止させ、該モジュールＰＧをアンインストールする。
【００２２】
そして、モジュール実行部３４は、インストーラ３３の指示に従ってモジュールＰＧを実行あるいは停止する。これにより、モジュール実行部３４は、実行中の業務アプリケーションに従い、業務用ネットワーク５を介して受信したリクエストを処理し、その結果を、業務用ネットワーク６を介して、自サーバ計算機３と共に負荷分散システムを形成するロードバランサ２あるいは他のサーバ計算機３に送信する。
【００２３】
サーバ計算機３のその他の機能は、既存の負荷分散システムで用いられているサーバ計算機と同様であるので、その詳細な説明を省略する。なお、本実施形態では、全てのサーバ計算機３が同じスペックを持つことを前提としている。
【００２４】
リソース割当管理装置１は、業務アプリケーション毎に、当該業務アプリケーションのサービスレベル余裕率を計算する。ここで、サービスレベル余裕率とは、業務アプリケーションが提供可能なサービスレベルに対する、当該業務アプリケーションが実際に要求されているサービスレベルの比率のことである。本実施形態では、サービスレベル余裕率を、各サーバ計算機３が単位時間当たりに処理可能な業務アプリケーションのリクエスト数（リクエスト処理可能数）の総数に対する、当該業務アプリケーションが割当てられている各サーバ計算機３のリクエスト受信数の総数の比率で表している。
【００２５】
また、リソース割当管理装置１は、サービスレベル余裕率がリソース不足を示している業務アプリケーションと、サービス余裕率がリソース過剰を示している業務アプリケーションとを特定する。そして、リソース過剰の業務アプリケーションに割当てられているサーバ計算機３の少なくとも１つの引当てを、当該業務アプリケーションからリソース不足の業務アプリケーションに変更する。
【００２６】
図示するように、リソース割当管理装置１は、業務用ネットワーク５および管理用ネットワーク６に接続するためのネットワークＩＦ部１１と、演算部１２と、記憶部１３と、を有する。
【００２７】
記憶部１３は、業務アプリ構成管理ＴＬ１３１と、リソース管理ＴＬ１３２と、メトリック情報管理ＴＬ１３３と、余裕率管理ＴＬ１３４と、調整計画管理ＴＬ１３５と、モジュール記憶部１３６と、ロードバランサ管理ＴＬ１３７と、を有する。
【００２８】
業務アプリ構成管理ＴＬ１３１には、各業務アプリケーションを構成するモジュールの情報が記憶される。図２は業務アプリ構成管理ＴＬ１３１を模式的に示す図である。図示するように、業務アプリ構成管理ＴＬ１３１には、モジュールＰＧ毎にレコード１３１０が登録される。レコード１３１０は、対象のモジュールＰＧを構成要素とする業務アプリケーションの識別情報である業務ＩＤを登録するフィールド１３１１と、当該業務アプリケーションが提供するサービスの種別を示すサービス種別を登録するフィールド１３１２と、当該モジュールＰＧが提供する機能を登録するフィールド１３１３と、当該モジュールＰＧの識別情報であるモジュールＩＤを登録するフィールド１３１４と、当該モジュールＰＧを複数のサーバ計算機３で並列に実行させること、つまり多重化が可能か否かを登録するフィールド１３１５と、当該モジュールＰＧをサーバ計算機３で実行させた場合にに当該サーバ計算機３で単位時間当たりに処理可能なリクエスト数であるリクエスト処理可能数（件/（分・台））を登録するフィールド１３１６と、を有する。
【００２９】
なお、上述したように、本実施形態では全てのサーバ計算機３が同じスペックを持つことを前提としているので、あるレコード１３１０のフィールド１３１６に登録されているリクエスト処理可能数は、全てのサーバ計算機３に対して当該レコード１３１０のフィールド１３１４に登録されているモジュールＩＤを持つモジュールＰＧを実行する場合に適用される。
【００３０】
リソース管理ＴＬ１３２には、サーバ計算機（リソース）３毎に、実行中のモジュールＰＧの情報が記憶される。図３はリソース管理ＴＬ１３２を模式的に表した図である。図示するように、リソース管理ＴＬ１３２には、サーバ計算機３毎にレコード１３２０が登録される。レコード１３２０は、対象のサーバ計算機３の識別情報である計算機ＩＤを登録するフィールド１３２１と、当該サーバ計算機３に割当てられた業務アプリケーションの業務ＩＤを登録するフィールド１３２２と、当該サーバ計算機３で稼動中のモジュールＰＧのモジュールＩＤを登録するフィールド１３２３と、を有する。プールされているサーバ計算機３のレコード１３２０では、フィールド１３２２、１３２３に、モジュールＰＧが未だ割り当てられていないことを示す「未割当」が登録される。
【００３１】
メトリック情報管理ＴＬ１３３には、モジュールＰＧを実行している各サーバ計算機３から受信したメトリック情報が記憶される。図４はメトリック情報管理ＴＬ１３３を模式的に表した図である。図示するように、メトリック情報管理ＴＬ１３３には、モジュールＰＧを実行中のサーバ計算機３毎にレコード１３３０が登録される。レコード１３３０は、対象のサーバ計算機３の計算機ＩＤを登録するフィールド１３３１と、当該サーバ計算機３に割当てられた業務アプリケーションの業務ＩＤを登録するフィールド１３３２と、当該サーバ計算機３で稼動中のモジュールＰＧのモジュールＩＤを登録するフィールド１３３３と、当該サーバ計算機３で計測されたメトリック情報を登録するフィールド１３３４と、本レコード１３３０の登録日時を登録するフィールド１３３５と、を有する。本実施形態では、メトリック情報として、単位時間当たりに業務用ネットワーク５から受信したリクエストの数（リクエスト受信数）を計測している。
【００３２】
余裕率管理ＴＬ１３４は、モジュールＰＧ各々のサービスレベル余裕率が記憶される。図５は余裕率管理ＴＬ１３４を模式的に表した図である。図示するように、余裕率管理ＴＬ１３４には、モジュールＰＧ毎にレコード１３４０が登録される。レコード１３４０は、対象のモジュールＰＧを構成要素とする業務アプリケーションの業務ＩＤを登録するフィールド１３４１と、当該モジュールＰＧのモジュールＩＤを登録するフィールド１３４２と、当該モジュールＰＧが割当てられているサーバ計算機３の台数（現状台数）を登録するフィールド１３４３と、当該モジュールＰＧに対するリクエストを適正に（遅滞なく）処理するために必要なサーバ計算機３の台数（適正台数）を登録するフィールド１３４４と、当該モジュールＰＧのサービスレベル余裕率を登録するフィールド１３４５と、当該モジュールＰＧに割当てられているサーバ計算機３のうち、引当てを解除して他のモジュールＰＧに提供可能なサーバ計算機３の台数（提供可能台数）を登録するフィールド１３４６と、を有する。なお、フィールド１３４６に登録されている提供可能台数が負の値である場合、この値は不足しているサーバ計算機３の数を示すことになる。
【００３３】
調整計画管理ＴＬ１３５には、モジュールＰＧへの引当てが変更されたサーバ計算機３各々の変更前後のモジュールＰＧに関する情報が記憶される。図６は調整計画管理ＴＬ１３５を模式的に表した図である。図示するように、調整計画管理ＴＬ１３５には、サーバ計算機３の計算機ＩＤを登録するフィールド１３５１と、引当変更前の業務アプリケーションの情報、つまり引当変更前に当該サーバ計算機３に引当てられていたモジュールＰＧのモジュールＩＤおよび当該モジュールＰＧを構成要素とする業務アプリケーションの業務ＩＤを登録するフィールド１３５２と、引当変更後の業務アプリケーションの情報、つまり引当ての引当変更後に当該サーバ計算機３に引当てられるモジュールＰＧのモジュールＩＤおよび当該モジュールＰＧを構成要素とする業務アプリケーションの業務ＩＤを登録するフィールド１３５３と、引当変更が計画された日時（調整日時）を登録するフィールド１３５４と、反映フラグ１３５５と、を有する。なお、フィールド１３５２のモジュールＩＤおよび業務ＩＤが「未割当」の場合、対象のサーバ計算機３が引当変更前にプールされていたことを示す。反映フラグ１３５５には、レコード１３５０の内容がリソース管理ＴＬ１３２に反映されたか否かを示すフラグが登録される。
【００３４】
モジュール記憶部１３６には、各モジュールＰＧが、モジュールＩＤおよび当該モジュールＰＧを構成要素とする業務アプリケーションの業務ＩＤに対応付けられて登録されている。
【００３５】
そして、ロードバランサ管理ＴＬ１３７には、業務アプリケーション毎に、当該業務アプリケーションの業務ＩＤと、当該業務アプリケーションを処理するロードバランサ２の識別情報（例えばローカルアドレス）であるロードバランサＩＤとが対応付けられて記憶されている。
【００３６】
演算部１２は、メトリック情報収集部１２１と、余裕率算出部１２２と、調整計画決定部１２３と、構成変更指示部１２４と、モジュール配布・設定部１２５と、を有する。
【００３７】
メトリック情報収集部１２１は、モジュールＰＧを実行中の各サーバ計算機３からメトリック情報を、管理用ネットワーク６を介して受信し、受信したメトリック情報に基づいてメトリック情報管理ＴＬ１３３を更新する。具体的には、サーバ計算機３からメトリック情報を受信すると、当該サーバ計算機３の計算機ＩＤを持つレコード１３２０をリソース管理ＴＬ１３２から検索する。次に、メトリック情報管理ＴＬ１３３に新たなレコード１３３０を追加し、該レコード１３３０に、当該サーバ計算機３の計算機ＩＤと、リソース管理ＴＬ１３２から検索したレコード１３２０に登録されている業務ＩＤおよびモジュールＩＤと、当該サーバ計算機３から受信したメトリック情報とを、登録日時と共に登録する。
【００３８】
余裕率算出部１２２は、業務アプリ構成管理ＴＬ１３１、リソース管理ＴＬ１３２およびメトリック情報管理ＴＬ１３３を用いて、モジュールＰＧ毎に、現状台数、適正台数、サービスレベル余裕率および提供可能台数を計算する。そして、余裕率管理ＴＬ１３４の各レコード１３４０を、当該レコード１３４０のフィールド１３４２に登録されているモジュールＩＤを持つモジュールＰＧに対して計算した現状台数、適正台数、サービスレベル余裕率および提供可能台数で更新する。
【００３９】
調整計画決定部１２３は、余裕率管理ＴＬ１３４に基づいて、引当てを変更するサーバ計算機３を決定し、決定したサーバ計算機３の引当変更前後のモジュールＰＧに関する情報が記述されたレコード１３５０を、調整計画管理ＴＬ１３５に登録する。
【００４０】
構成変更指示部１２４は、調整計画管理ＴＬ１３５に従い、サーバ計算機３に引当てるモジュールＰＧの変更およびモジュールＰＧの引当てが変更されたサーバ計算機３を利用するためのロードバランサ２の設定変更を行う。また、リソース管理ＴＬ１３２を更新して、リソース管理ＴＬ１３２に該変更内容を反映させる。
【００４１】
そして、モジュール配布・設定部１２５は、構成変更指示部１２４の指示に従い、管理用ネットワーク６を介してサーバ計算機３にアクセスし、当該サーバ計算機３にモジュールＰＧのアンインストールを指示する。あるいは、モジュール記憶部１３５からモジュールＰＧを読出すと共に、読み出したモジュールＰＧを当該サーバ計算機３に送信して当該モジュールＰＧのインストールを指示する。あるいは、管理用ネットワーク６を介してロードバランサ２にアクセスし、リソース管理ＴＬ２１に登録されている当該モジュールＰＧを実行するサーバ計算機３の情報を更新する。
【００４２】
上記構成のリソース割当管理装置１は、例えば図７に示すような、ＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭやＩＣカードなどの記憶媒体からデータを読み取る読取装置９０４と、キーボードやマウスなどの入力装置９０６と、モニタやプリンタなどの出力装置９０７と、管理用ネットワーク６に接続するための通信装置９０８と、これらの各装置を接続するバス９０９と、を備えた一般的なコンピュータにおいて、ＣＰＵ９０１がメモリ９０２上にロードされたプログラムを実行することで実現できる。このプログラムは、読取装置９０４を介して記憶媒体から、あるいは、通信装置９０８を介して管理用ネットワーク６から、外部記憶装置９０３にダウンロードされ、それから、メモリ９０２上にロードされてＣＰＵ９０１により実行されるようにしてもよい。あるいは外部記憶装置９０３を経由せずに、メモリ９０２上に直接ロードされ、ＣＰＵ９０１により実行されるようにしてもよい。なお、この場合において、記憶部１３にはメモリ９０２や外部記憶装置９０３や読取装置９０４に搭載された記憶媒体が利用される。また、ネットワークＩＦ部１１には通信装置９０８が利用される。
【００４３】
次に、上記構成のリソース割当管理装置１の動作を説明する。
【００４４】
図８はリソース割当管理装置１の動作フローを説明するための図である。なお、このフローには示さないが、上述したように、メトリック情報収集部１２１は、管理用ネットワーク６を介して各サーバ計算機３からメトリック情報を受信して、メトリック情報管理ＴＬ１３３をこのメトリック情報で更新する処理を常に行っている。
【００４５】
さて、図８において、演算部１２は、図示していない内蔵タイマを用いて、所定時間の経過や所定時刻の到来などのリソース割当判定タイミングを検出すると、あるいは、図示していない入力装置を介してユーザよりリソース割当判定指示を受け付けると（Ｓ１０でＹＥＳ）、余裕率算出部１２２に余裕率管理ＴＬ更新処理の実施を指示する。
【００４６】
これを受けて、余裕率算出部１２２は、余裕率管理ＴＬ更新処理を実施する（Ｓ１１）。すなわち、業務アプリ構成管理ＴＬ１３１、リソース管理ＴＬ１３２およびメトリック情報管理ＴＬ１３３を用いて、モジュールＰＧ毎に、現状台数、適正台数、サービスレベル余裕率および提供可能台数を計算する。そして、余裕率管理ＴＬ１３４の各レコード１３４０を、当該レコード１３４０のフィールド１３４２に登録されているモジュールＩＤを持つモジュールＰＧに対して計算した現状台数、適正台数、サービスレベル余裕率および提供可能台数で更新する。
【００４７】
図９は図８のＳ１１（余裕率管理ＴＬ更新処理）の動作フローを説明する図である。
【００４８】
先ず、余裕率算出部１２２は、余裕率管理ＴＬ１３４の登録内容をクリアする（Ｓ１１０２）。次に、余裕率算出部１２２は、業務アプリ構成管理ＴＬ１３１から、フィールド１３１５に多重化「可」が登録されているレコード１３１０であって未注目のレコード１３１０を特定し、このレコード１３１０を注目レコード１３１０とする（Ｓ１１０２）。
【００４９】
次に、余裕率算出部１２２は、注目レコード１３１０の業務ＩＤ、モジュールＩＤを持つレコード１３２０をリソース管理ＴＬ１３２から検索し、検索した各レコード１３２０のフィールド１３２１に登録されている計算機ＩＤ、つまり、注目レコード１３１０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧが現在稼動中のサーバ計算機３の計算機ＩＤを、稼動中計算機ＩＤに設定する。また、稼動中計算機ＩＤの総数を求め、これを現状台数とする（Ｓ１１０３）。
【００５０】
次に、余裕率算出部部１２２は、メトリック情報管理ＴＬ１３３から、フィールド１３３１にいずれかの稼動中計算機ＩＤが登録されているレコード１３３０を全て検索し、検索したレコード１３３０各々のフィールド１３３４にメトリック情報として登録されているリクエスト受信数の総和を求める（Ｓ１１０４）。そして、求めたリクエスト受信数の総和を、注目レコード１３１０のフィールド１３１６に登録されている処理可能数で割算し、算出結果の小数点を切り上げることで、適正台数を求める。また、この適正台数に対するＳ１１０３で設定した現状台数の比率をサービスレベル余裕率として求める。さらに、Ｓ１１０３で設定した現状台数から適正台数を減算して提供可能台数を求める（Ｓ１１０５）。例えば、業務アプリ構成管理ＴＬ１３１、リソース管理ＴＬ１３２およびメトリック情報管理ＴＬ１３３が図２〜図４に示すとおりであり、注目レコード１３１０の業務ＩＤ、モジュールＩＤがそれぞれ「ＡＰＰ＿０１」、「ＷＥＢ＿０１」である場合、処理可能数は図２に示す業務アプリ構成管理ＴＬ１３１から２０件/（分・台）となり、現状台数は図３に示すリソース管理ＴＬ１３２から４台となり、リクエスト受信数の総数は図４に示すメトリック情報管理ＴＬ１３３から１５０件/分となる。したがって、適正台数は（リクエスト受信数の総数１５０）／（処理可能数２０）＝７．５なので８台となり、サービスレベル余裕率は（（現状台数４）／（適正台数８））×１００＝５０％となり、そして、提供可能台数は（現状台数４）−（適正台数８）＝−４台（４台分のリソース不足）となる。
【００５１】
次に、余裕率算出部１２２は、注目レコード１３１０の業務ＩＤ、モジュールＩＤがフィールド１３４１、１３４２に登録されているレコード（更新対象レコード）１３４０が、余裕率管理ＴＬ１３４０に登録されているか否かを調べる（Ｓ１１０５）。登録されている場合は、更新対象レコード１３４０のフィールド１３４３〜１３４６の登録内容を、Ｓ１１０３で設定した現状台数、および、Ｓ１１０５で求めた適正台数、サービスレベル余裕率、提供可能台数に更新する（Ｓ１１０７）。一方、登録されていない場合は、余裕率管理ＴＬ１３４に新たなレコード１３４０を追加し、このレコード１３４０のフィールド１３４１〜１３４６に、注目レコード１３１０の業務ＩＤ、モジュールＩＤ、Ｓ１１０３で設定した現状台数、および、Ｓ１１０５で求めた適正台数、サービスレベル余裕率、提供可能台数を登録する（Ｓ１１０８）。
【００５２】
さて、余裕率計算部１２２は、業務アプリ構成管理ＴＬ１３１に登録されている、フィールド１３１５に多重化「可」が登録されている全てのレコード１３１０について注目したならば（Ｓ１１０９でＹＥＳ）、調整計画決定部１２３に調整計画管理ＴＬ更新処理を指示して、このフローを終了する。一方、未注目のレコード１３１０があるならば（Ｓ１１０９でＮＯ）、Ｓ１１０２に戻る。
【００５３】
図８に戻って説明を続ける。調整計画決定部１２３は、余裕率算出部１２２から調整計画管理ＴＬ更新処理を指示されると、調整計画管理ＴＬ更新処理を実施する。すなわち、余裕率管理ＴＬ１３４に基づいて、引当てを変更するサーバ計算機３を決定し、決定したサーバ計算機３の引当変更前後のモジュールＰＧに関する情報が記述されたレコード１３５０を、調整計画管理ＴＬ１３５に登録する（Ｓ１２）。
【００５４】
図１０および図１１は図８のＳ１２（調整計画管理ＴＬ更新処理）の動作フローを説明する図である。
【００５５】
先ず、調整計画決定部１２３は、余裕率管理ＴＬ１３４に登録されている各レコード１３４０を、フィールド１３４６の提供可能台数が大きい順にソートする（Ｓ１２０１）。また、カウント値ｎを１に設定する（Ｓ１２０２）。
【００５６】
次に、調整計画決定部１２３は、余裕率管理ＴＬ１３４に登録されているソートされたレコード１３４０の下からｎ番目のレコード１３４０を特定し、このレコード１３４０を注目レコード１３４０とする（Ｓ１２０３）。そして、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数が負の値であるか否かを調べる（Ｓ１２０４）。負の値である場合（Ｓ１２０４でＹＥＳ）はＳ１２０５に進む。そうでない場合、つまり、提供可能台数が０以上である場合（Ｓ１２０４でＮＯ）は、リソースが不足している全てのモジュールＰＧに対してサーバ計算機３の追加引当てが終了したことになる。この場合、構成変更指示部１２４に構成変更処理を指示して、このフローを終了する。
【００５７】
Ｓ１２０５において、調整計画決定部１２３は、リソース管理ＴＬ１３２を参照し、フィールド１３２２、１３２３の業務ＩＤ、モジュールＩＤが共に「未割当」のレコード１３２０であって、かつ当該レコード１３２０のフィールド１３２１に登録されている計算機ＩＤを持つレコード１３５０が調整計画管理ＴＬ１３５に登録されていない（引当先が決定していない）レコード１３２０を検索する。
【００５８】
そのようなレコード１３２０がない場合（Ｓ１２０５でＮＯ）、全てにサーバ計算機３でモジュールＰＧが稼動しているか、あるいは、モジュールＰＧが稼動していないサーバ計算機３があっても該サーバ計算機３にはモジュールＰＧの引当てが予定されていることになる。この場合はＳ１２１０に移行する。
【００５９】
一方、そのようなレコード１３２０がある場合（Ｓ１２０５でＹＥＳ）、このレコード１３２０に登録されている計算機ＩＤを持つサーバ計算機３は、モジュールＰＧが稼動しておらず、且つ、モジュールＰＧの引当てが予定されていないことになる。この場合、調整計画決定部１２３は、調整計画管理ＴＬ１３５に新たなレコード１３５０を追加する。そして、追加したレコード１３５０のフィールド１３５１に、Ｓ１２０５で検索したレコード１３２０のフィールド１３２１に登録されている計算機ＩＤを、フィールド１３５２に、Ｓ１２０５で検索したレコード１３２０のフィールド１３２２、１３２３に登録されている業務ＩＤ、モジュールＩＤ（この場合、ともに「未割当」）を、フィールド１３５３に、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを、フィールド１３５４に現在日時を、そして、フィールド１３５５に、リソース管理ＴＬ１３２への反映が未だ行われていないことを示す反映フラグ「オフ」をそれぞれ登録する（Ｓ１２０６）。
【００６０】
次に、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数を、当該提供可能台数に１を加算した値に更新する（Ｓ１２０７）。それから、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数が負の値であるか否かを調べる（Ｓ１２０８）。負の値である場合（Ｓ１２０８でＹＥＳ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧは未だリソース（サーバ計算機３）が不足していることを示す。そこで、この場合はＳ１２０５に戻る。一方、負の値でない場合（Ｓ１２０８でＮＯ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧはリソース不足が解消したことを示す。そこで、この場合はカウント値ｎを１つインクリメントし（Ｓ１２０９）、それからＳ１２０３に戻って、余裕率管理ＴＬ１３４に登録されているソートされたレコード１３４０の順番上、注目レコード１３４０よりも１つ上のレコード１３４０に処理を移す。
【００６１】
Ｓ１２１０において、調整計画決定部１２３はカウント値ｍを１に設定する。次に、調整計画決定部１２３は、余裕率管理ＴＬ１３４に登録されているソートされたレコード１３４０の上からｍ番目のレコード１３４０を特定し、このレコード１３４０を引当対象レコード１３４０とする（Ｓ１２１１）。
【００６２】
次に、調整計画決定部１２３は、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能台数が正の値（１以上）であるか否かを調べる（Ｓ１２１２）。正の値である場合（Ｓ１２１２でＹＥＳ）はＳ１２１３に進む。そうでない場合、つまり、提供可能台数が０以下である場合（Ｓ１２１２でＮＯ）は、リソースが余っている全てのモジュールＰＧについて、リソース過剰部分に相当するサーバ計算機３の他モジュールＰＧへの引当てが終了したことになる。この場合、構成変更指示部１２４に構成変更処理を指示して、このフローを終了する。
【００６３】
Ｓ１２１３において、調整計画決定部１２３は、引当対象レコード１３４０の業務ＩＤ、モジュールＩＤを持つレコード１３２０を、リソース管理ＴＬ１３２から検索する。また、検索したレコード１３２０各々ついて、当該レコード１３２０のフィールド１３２１に登録されている計算機ＩＤを持つレコード１３５０であって、フィールド１３５２に登録されている業務ＩＤおよびモジュールＩＤが注目レコード１３４０の業務ＩＤおよびモジュールＩＤと一致し、フィールド１３５３に登録されている業務ＩＤおよびモジュールＩＤが引当対象レコード１３４０の業務ＩＤおよびモジュールＩＤと一致し、且つ、フィールド１３５４に登録されている調整日時が現在日時の所定時間（例えば１時間）前から現在日時までの間に属するレコード１３５０が、調整計画管理ＴＬ１３５に登録されているか否かを調べ、登録されている場合は、同じ業務アプリケーション間におけサーバ計算機３の頻繁な引当変更を防止するために、当該レコード１３２０を対象から除外する。そして、最終的に残ったレコード１３２０各々のフィールド１３２１に登録されているサーバ計算機３を引当候補とする。
【００６４】
次に、調整計画決定部１２３は、引当候補の中から未注目の引当候補に注目し、引当候補の計算機ＩＤを持つレコード１３２０をリソース管理ＴＬ１３２から検索する（Ｓ１２１４）。それから、調整計画決定部１２３は、調整計画管理ＴＬ１３５に新たなレコード１３５０を追加し、追加したレコード１３５０のフィールド１３５１に、引当候補の計算機ＩＤを、フィールド１３５２に、Ｓ１２１４で検索した引当候補の計算機ＩＤを持つレコード１３２０のフィールド１３２２、１３２３に登録されている業務ＩＤ、モジュールＩＤを、フィールド１３５３に、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを、フィールド１３５４に現在日時を、そして、フィールド１３５５に、リソース管理ＴＬ１３２への反映が未だ行われていないことを示す反映フラグ「オフ」をそれぞれ登録する（Ｓ１２１５）。
【００６５】
次に、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数を、当該提供可能台数に１を加算した値に更新する。また、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能台数を、当該提供可能台数から１を減算した値に更新する（Ｓ１２１６）。
【００６６】
それから、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数が負の値であるか否かを調べる（Ｓ１２１７）。負の値である場合（Ｓ１２１７でＹＥＳ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧは未だリソース（サーバ計算機３）が不足していることを示す。そこで、この場合はＳ１２１８に進む。一方、負の値でない場合（Ｓ１２１７でＮＯ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧはリソース不足が解消したことを示す。そこで、この場合はカウント値ｎを１つインクリメントし（Ｓ１２０９）、それからＳ１２０３に戻って、余裕率管理ＴＬ１３４に登録されているソートされたレコード１３４０の順番上、注目レコード１３４０よりも１つ上のレコード１３４０に処理を移す。
【００６７】
Ｓ１２１８において、調整計画決定部１２３は、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能台数が正の値（１以上）であるか否かを調べる。正の値である場合（Ｓ１２１８でＹＥＳ）はＳ１２１４に戻る。そうでない場合、つまり、提供可能台数が０以下である場合（Ｓ１２１８でＮＯ）は、カウント値ｍを１つインクリメントし（Ｓ１２１９）、それからＳ１２１１に戻る。
【００６８】
図８に戻って説明を続ける。構成変更指示部１２４は、調整計画決定部１２３から構成変更処理を指示されると、構成変更処理を実施して、サーバ計算機３に引当てるモジュールＰＧの変更およびモジュールＰＧの引当てが変更されたサーバ計算機３を利用するためのロードバランサ２の設定変更を行う。また、リソース管理ＴＬ１３２を更新して、リソース管理ＴＬ１３２に該変更内容を反映させる。
【００６９】
図１２は図８のＳ１３（構成変更処理）の動作フローを説明する図である。
【００７０】
先ず、構成変更指示部１２４は、調整計画管理ＴＬ１３５から、フィールド１３５５に反映フラグ「オフ」が登録されているレコード１３５０を１つ抽出する（Ｓ１３０１）。
【００７１】
次に、構成変更指示部１２４は、抽出したレコード１３５０のフィールド１３５３に登録されている業務ＩＤおよびモジュールＩＤをモジュール配布・設定部１２５に通知する。これを受けて、モジュール配布・設定部１２５は、構成変更指示部１２４より通知された業務ＩＤおよびモジュールＩＤより特定されるモジュールＰＧを、モジュール記憶部１３５から読み出し、該モジュールＰＧを、管理用ネットワーク６を介して、選択したレコード１３２０の計算機ＩＤにより特定されるサーバ計算機３へ送信する（Ｓ１３０２）。これにより、サーバ計算機３のインストーラ３３が、モジュール実行部３４で実行中のモジュールＰＧの実行を停止させ、該モジュールＰＧをアンインストールする。それから、リソース割当管理装置１から受信したモジュールＰＧをインストールして、モジュール実行部３４に実行させる。
【００７２】
また、モジュール配布・設定部１２５は、Ｓ１３０１で抽出したレコード１３５０のフィールド１３５２に登録されている業務ＩＤに対応付けられてロードバランサ管理ＴＬ１３６に登録されているロードバランサＩＤを特定し（Ｓ１３０３）、該ロードバランサＩＤを持つロードバランサ２に、管理用ネットワークを介してアクセスする。そして、当該ロードバランサ２のリソース管理ＴＬ２１から、Ｓ１３０１で抽出したレコード１３５０のフィールド１３５１に登録されている計算機ＩＤと該レコードのフィールド１３５２に登録されているモジュールＩＤとの組を削除する（Ｓ１３０４）。
【００７３】
また、モジュール配布・設定部１２５は、Ｓ１３０１で抽出したレコード１３５０のフィールド１３５３に登録されている業務ＩＤに対応付けられてロードバランサ管理ＴＬ１３６に登録されているロードバランサＩＤを特定し（Ｓ１３０５）、該ロードバランサＩＤを持つロードバランサ２に、管理用ネットワークを介してアクセスする。そして、当該ロードバランサ２のリソース管理ＴＬ２１に、Ｓ１３０１で抽出したレコード１３５０のフィールド１３５１に登録されている計算機ＩＤと該レコードのフィールド１３５２に登録されているモジュールＩＤとの組を設定する（Ｓ１３０６）。
【００７４】
それから、モジュール配布・設定部１２５は、処理の終了を構成変更指示部１２４に通知する。これを受けて、Ｓ１３０１で抽出したレコード１３５０のフィールド１３５５に登録されている反映フラグを「オフ」から「オン」に変更する（Ｓ１３０７）。
【００７５】
次に、構成変更指示部１２４は、調整計画管理ＴＬ１３５に、フィールド１３５５に反映フラグ「オフ」が登録されているレコード１３５０が存在するか否かを調べ（Ｓ１３０８）、存在する場合（Ｓ１３０８でＹＥＳ）はＳ１３０１に戻る。存在しない場合（Ｓ１３０８でＮＯ）はこのフローを終了する。これにより、図８に示すフローが終了する。
【００７６】
以上、本発明の一実施形態について説明した。
【００７７】
本実施形態において、リソース割当管理装置１は、業務アプリケーション毎に、当該業務アプリケーションに引当てられたサーバ計算機３のうち他の業務アプリケーションに引当て変更することのできるサーバ計算機３の数つまり提供可能台数を計算する。そして、提供可能台数が正の値（リソースが余っている）業務アプリケーションに割当てられている少なくとも１つのサーバ計算機３の引当てを、当該業務アプリケーションから、提供可能台数が負の値（リソースが不足している）業務アプリケーションに変更する。したがって、本実施形態によれば、各業務アプリケーションのサービスレベルの低下を防止できるように、各業務アプリケーションに割り当てるコンピュータを管理することができる。
【００７８】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【００７９】
例えば上記の実施形態では、リソースが不足している業務アプリケーション（余裕率管理ＴＬ１３４において提供可能台数が負の値を持つレコード１３４０）に対して、最も多くのリソースが余っている業務アプリケーション（余裕率管理ＴＬ１３４において提供可能台数がより大きな正の値を持つレコード１３４０）に引当てられているサーバ計算機３を引当てるように引当てを変更し、最も多くのリソースが余っている業務アプリケーションに引当てられているサーバ計算機３の過剰部分がなくなったならば（当該業務アプリケーションに対応するレコード１３４０の提供可能台数が０になったならば）、その次に多くのリソースが余っている業務アプリケーションに引当てられているサーバ計算機３を引当てるように引当てを変更する。この処理をリソースが不足している業務アプリケーションのリソース不足が解消するまで（当該業務アプリケーションに対応するレコード１３４０の提供可能台数が０になるまで）繰り返す（図８に示す調整計画管理ＴＬ更新処理Ｓ１２を参照）。しかし、本発明はこれに限定されない。
【００８０】
リソースが不足している業務アプリケーションに対して、リソースが余っている業務アプリケーションに引当てられているサーバ計算機３を、当該リソースが余っている業務アプリケーションがリソース不足とならない範囲で引当てるように引当てを変更するものであればよい。
【００８１】
図１３は図８に示す調整計画管理ＴＬ更新処理Ｓ１２の変形例を説明するための図である。
【００８２】
図１３において、調整計画決定部１２３は、図１０に示すＳ１２０１〜Ｓ１２０９と同じ処理を行う（Ｓ１２５０）。つまり、Ｓ１２０３において、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数が０以上である場合は、構成変更指示部１２４に構成変更処理を指示して、このフローを終了する。そして、Ｓ１２０５において、フィールド１３２２、１３２３の業務ＩＤ、モジュールＩＤが共に「未割当」のレコード１３２０であって、かつ当該レコード１３２０のフィールド１３２１に登録されている計算機ＩＤを持つレコード１３５０が調整計画管理ＴＬ１３５に登録されていない（引当先が決定していない）レコード１３２０がない場合に、Ｓ１２５１に移動する。
【００８３】
Ｓ１２５１において、調整計画決定部１２３はカウント値ｍ´を１に設定する。次に、調整計画決定部１２３は、余裕率管理ＴＬ１３４に登録されているソートされたレコード１３４０の上からｍ´番目のレコード１３４０を特定し、このレコード１３４０を引当対象レコード１３４０とする（Ｓ１２５２）。
【００８４】
次に、調整計画決定部１２３は、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能台数が正の値（１以上）であるか否かを調べる（Ｓ１２５３）。正の値である場合（Ｓ１２５３でＹＥＳ）はＳ１２５４に進む。そうでない場合、つまり、提供可能台数が０以下である場合（Ｓ１２５４でＮＯ）は、リソースが余っている全てのモジュールＰＧについて、リソース過剰部分に相当するサーバ計算機３の他モジュールＰＧへの引当てが終了したことになる。この場合、構成変更指示部１２４に構成変更処理を指示して、このフローを終了する。
【００８５】
Ｓ１２５４において、調整計画決定部１２３は、引当対象レコード１３４０の業務ＩＤ、モジュールＩＤを持つレコード１３２０を、リソース管理ＴＬ１３２から検索する。また、検索したレコード１３２０各々ついて、当該レコード１３２０のフィールド１３２１に登録されている計算機ＩＤを持つレコード１３５０であって、フィールド１３５２に登録されている業務ＩＤおよびモジュールＩＤが注目レコード１３４０の業務ＩＤおよびモジュールＩＤと一致し、フィールド１３５３に登録されている業務ＩＤおよびモジュールＩＤが引当対象レコード１３４０の業務ＩＤおよびモジュールＩＤと一致し、且つ、フィールド１３５４に登録されている調整日時が現在日時の所定時間（例えば１時間）前から現在日時までの間に属するレコード１３５０が、調整計画管理ＴＬ１３５に登録されているか否かを調べ、登録されている場合は、同じ業務アプリケーション間におけサーバ計算機３の頻繁な引当変更を防止するために、当該レコード１３２０を対象から除外する。そして、最終的に残ったレコード１３２０のうちのいずれか１つのレコード１３２０のフィールド１３２１に登録されているサーバ計算機３を引当候補とする。
【００８６】
次に、調整計画決定部１２３は、引当候補の計算機ＩＤを持つレコード１３２０をリソース管理ＴＬ１３２から検索する。それから、調整計画決定部１２３は、調整計画管理ＴＬ１３５に新たなレコード１３５０を追加し、追加したレコード１３５０のフィールド１３５１に、引当候補の計算機ＩＤを、フィールド１３５２に、当該検索した引当候補の計算機ＩＤを持つレコード１３２０のフィールド１３２２、１３２３に登録されている業務ＩＤ、モジュールＩＤを、フィールド１３５３に、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを、フィールド１３５４に現在日時を、そして、フィールド１３５５に、リソース管理ＴＬ１３２への反映が未だ行われていないことを示す反映フラグ「オフ」をそれぞれ登録する（Ｓ１２５５）。
【００８７】
次に、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数を、当該提供可能台数に１を加算した値に更新する。また、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能台数を、当該提供可能台数から１を減算した値に更新する（Ｓ１２５６）。
【００８８】
それから、調整計画決定部１２３は、注目レコード１３４０のフィールド１３４６に登録されている提供可能台数が負の値であるか否かを調べる（Ｓ１２５７）。負の値である場合（Ｓ１２５７でＹＥＳ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧは未だリソース（サーバ計算機３）が不足していることを示す。そこで、この場合はカウント値ｍ´を１つインクリメントし（Ｓ１２５８）、それからＳ１２５２に戻る。一方、負の値でない場合（Ｓ１２５７でＮＯ）、注目レコード１３４０の業務ＩＤ、モジュールＩＤにより特定されるモジュールＰＧはリソース不足が解消したことを示す。そこで、この場合はＳ１２５０（図１０のＳ１２０９）に戻る。
【００８９】
図１３に示すフローのように、調整計画管理ＴＬ更新処理を修正することで、より多くのリソースが余っている業務アプリケーションからリソースが不足している業務アプリケーションにサーバ計算機３の引当てを変更することができる。
【００９０】
また、上記の実施形態では、全てのサーバ計算機３が同じスペックを持つことを前提としている。しかし、本発明はこれに限定されない。サーバ計算機３のそれぞれが異なるスペックを持っていてもよい。この場合、業務アプリケーションが割当てられている各サーバ計算機の単位時間当たりに処理可能なリクエスト数（リクエスト処理可能数）の総数から、当該業務アプリケーションが割当てられている各サーバ計算機が単位時間当たりに受付けたリクエスト数（リクエスト受信数）の総数を差し引いて、当該業務アプリケーションが他の業務アプリケーションに提供可能なリソース量を計算する。そして、該リソース量が第１の所定値（例えば+１）以上である業務アプリケーション、つまりリソースが余っている業務アプリケーションに割当てられている少なくとも１つのサーバ計算機の引当てを、該リソース量が第２の所定値（例えば−１）以下である業務アプリケーション、つまりリソースが不足している業務アプリケーションに変更する。
【００９１】
具体的には、例えば、業務アプリ構成管理ＴＬ１３１のレコード１３１０のフィールド１３１６に、各サーバ計算機３の処理可能数をサーバ計算機３の計算機ＩＤに対応付けて登録しておく。また、図９のＳ１１０３において、余裕率管理ＴＬ１３４のレコード１３４０のフィールド１３４３に、現状台数に代えて、フィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤにより特定される業務アプリケーションが割当てられている各サーバ計算機３のリクエスト受信数の総数を登録し、図９のＳ１１０５において、フィールド１３４４に、適正台数に代えて、フィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤにより特定される業務アプリケーションが割当てられている各サーバ計算機３の処理可能数の総数を登録し、フィールド１３４５には、サービスレベル余裕率として、該処理可能数の総数に対する該リクエスト受信数の総数の比率を登録し、フィールド１３４６には、提供可能台数に代えて、該処理可能数の総数から該リクエスト受信数の総数を減算した値を提供可能数として登録する。ここで、フィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤにより特定される業務アプリケーションが割当てられている各サーバ計算機３の処理可能数は、フィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを有する業務アプリ構成管理ＴＬ１３１のレコード１３１０のフィールド１３１６に登録されている各サーバ計算機３の処理可能数から算出することができる。
【００９２】
また、図１０のＳ１２０４、Ｓ１２０８と、図１１のＳ１２１７と、図１３のＳ１２５７とにおいて、注目レコード１３４０の提供可能数が第２の所定値（例えば−１）以下であるか否かを判断し、図１１のＳ１２１２、Ｓ１２１８と、図１３のＳ１２５３とにおいて、引当対象レコード１３４０の提供可能数が第１の所定値（例えば+１）以上であるか否かを判断する。
【００９３】
また、図１０のＳ１２０７において、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを有する業務アプリ構成管理ＴＬ１３１のレコード１３１０のフィールド１３１６から、Ｓ１２０６で引当てたサーバ計算機３の処理可能数を特定し、注目レコード１３４０のフィールド１３４６に登録されている提供可能数を、該提供可能数に該特定した処理可能数を加算した値に更新する。
【００９４】
また、図１１のＳ１２１６において、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを有する業務アプリ構成管理ＴＬ１３１のレコード１３１０のフィールド１３１６から、Ｓ１２１６で引当てたサーバ計算機３の処理可能数を特定し、注目レコード１３４０のフィールド１３４６に登録されている提供可能数を、該提供可能数に該特定した処理可能数を加算した値に更新する。また、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能数を、該提供可能数から該特定した処理可能数を減算した値に更新する。
【００９５】
また、図１３のＳ１２５６において、注目レコード１３４０のフィールド１３４１、１３４２に登録されている業務ＩＤ、モジュールＩＤを有する業務アプリ構成管理ＴＬ１３１のレコード１３１０のフィールド１３１６から、Ｓ１２５５で引当てたサーバ計算機３の処理可能数を特定し、注目レコード１３４０のフィールド１３４６に登録されている提供可能数を、該提供可能数に該特定した処理可能数を加算した値に更新する。また、引当対象レコード１３４０のフィールド１３４６に登録されている提供可能数を、該提供可能数から該特定した処理可能数を減算した値に更新する。
【００９６】
また、上記の実施形態では、各サーバ計算機３にメトリック情報計測部３２を設け、リソース割当管理装置１のメトリック情報収集部１２１が各サーバ計算機３からメトリック情報を収集している。しかし、本発明はこれに限定されない。各ロードバランサ２にモジュールＰＧ毎にメトリック情報を計測するメトリック情報計測部を設け、リソース割当管理装置１のメトリック情報収集部１２１が各ロードバランサ２からモジュールＰＧ毎にメトリック情報を収集してもよい。
【００９７】
また、上記の実施形態において、特定の業務アプリケーションについてはリソースに余裕がある場合でも、当該業務アプリケーションに引当てられたサーバ計算機３の他の業務アプリケーションへの引当変更を禁止するようにしてもよい。例えば、業務アプリ構成管理ＴＬ１３１のレコード１３１０に、当該レコード１３１０に登録されている業務ＩＤおよびモジュールＩＤにより特定されるモジュールＰＧに引当てられたサーバ計算機３の他のモジュールＰＧへの引当変更を認めるか否かを示す引当禁止フラグを含めておく。そして、図９のＳ１１０８において、余裕率管理ＴＬ１３４に新たなレコード１３４０を追加する際に、注目レコード１３１０に含まれている引当禁止フラグを追加するレコード１３４０に含める。また、図１１のＳ１２１１に先立ち、余裕率管理ＴＬ１３４のソートされたレコード１３４０の上からｍ番目のレコード１３４０の引当禁止フラグを調べ、該フラグが「引当変更許可」を示している場合にのみＳ１２１２に移動し、該フラグが「引当変更拒否」を示している場合は、直ちにＳ１２１９に移動する。また、図１５のＳ１２５１に先立ち、余裕率管理ＴＬ１３４のソートされたレコード１３４０の上からｍ´番目のレコード１３４０の引当禁止フラグを調べ、該フラグが「引当変更許可」を示している場合にのみＳ１２５８に移動し、該フラグが「引当変更拒否」を示している場合は、直ちにＳ１２５２に移動する。
【００９８】
また、上記の実施形態において、各業務アプリケーションに優先順位を付与し、ある業務アプリケーションについてリソースに余裕がある場合でも、当該業務アプリケーションに引当てられたサーバ計算機３の引当ての当該業務アプリケーションよりも優先順位の低い業務アプリケーションへの引当変更を禁止するようにしてもよい。例えば、業務アプリ構成管理ＴＬ１３１のレコード１３１０に、当該レコード１３１０に登録されている業務ＩＤおよびモジュールＩＤにより特定されるモジュールＰＧに付与された優先順位を含めておく。そして、図９のＳ１１０８において、余裕率管理ＴＬ１３４に新たなレコード１３４０を追加する際に、注目レコード１３１０に含まれている優先順位を追加するレコード１３４０に含める。また、図１１のＳ１２１１に先立ち、余裕率管理ＴＬ１３４のソートされたレコード１３４０の上からｍ番目のレコード１３４０の優先順位を調べ、該優先順位が注目レコード１３４０の優先順位より低い場合にのみＳ１２１２に移動し、高い場合は直ちにＳ１２１９に移動する。また、図１５のＳ１２５１に先立ち、余裕率管理ＴＬ１３４のソートされたレコード１３４０の上からｍ´番目のレコード１３４０の優先順位を調べ、該優先順位が注目レコード１３４０の優先順位より低い場合にのみＳ１２５８に移動し、高い場合は直ちにＳ１２５２に移動する。
【００９９】
また、上記の実施形態では、管理用ネットワーク５と、業務用ネットワーク６とを別々に設けているが、１つのネットワークで管理用ネットワークおよび業務用ネットワークを兼用するようにしてもよい。
【０１００】
また、上記の実施形態では、リソース割当管理装置１がモジュールＰＧをサーバ計算機３に配布するようにしているが、サーバ計算機３に予めモジュールＰＧを記憶させておき、インストーラ３３がリソース割当管理装置１より指定されたモジュールＰＧをインストールして、該モジュールＰＧをモジュール実行部３４に実行させるようにしてもよい。
【図面の簡単な説明】
【０１０１】
【図１】図１は本発明の一実施形態が適用されたリソース割当管理システムの概略図である。
【図２】図２は業務アプリ構成管理ＴＬ１３１を模式的に示す図である。
【図３】図３はリソース管理ＴＬ１３２を模式的に表した図である。
【図４】図４はメトリック情報管理ＴＬ１３３を模式的に表した図である。
【図５】図５は余裕率管理ＴＬ１３４を模式的に表した図である。
【図６】図６は調整計画管理ＴＬ１３５を模式的に表した図である。
【図７】図７はリソース割当管理装置１にハードウエア構成例を示す図である。
【図８】図８はリソース割当管理装置１の動作フローを説明するための図である。
【図９】図９は図８のＳ１１（余裕率管理ＴＬ更新処理）の動作フローを説明する図である。
【図１０】図１０は図８のＳ１２（調整計画管理ＴＬ更新処理）の動作フローを説明する図である。
【図１１】図１１は図８のＳ１２（調整計画管理ＴＬ更新処理）の動作フローを説明する図である。
【図１２】図１２は図８のＳ１３（構成変更処理）の動作フローを説明する図である。
【図１３】図１３は図８に示す調整計画管理ＴＬ更新処理Ｓ１２の変形例を説明するための図である。
【符号の説明】
【０１０２】
１…リソース割当管理装置、２…ロードバランサ、３…サーバ計算機、４…ルータ、５…管理用ネットワーク、６…業務用ネットワーク、１１…ネットワークＩＦ部、１２…演算部、１３…記憶部、２１…リソース管理ＴＬ、３１…ネットワークＩＦ部、３２…メトリック情報計測部、３３…インストーラ、３４…モジュール実行部、４１…ルーティング管理ＴＬ、１２１…メトリック情報収集部、１２２…余裕率算出部、１２３…調整計画決定部、１２４…構成変更指示部、１２５…モジュール配布・設定部、１３１…業務アプリ構成管理ＴＬ、１３２…リソース管理ＴＬ、１３３…メトリック情報管理ＴＬ、１３４…余裕率管理ＴＬ、１３５…調整計画管理ＴＬ、１３６…モジュール記憶部、１３７…ロードバランサ管理ＴＬ
【図１】
2006277458.tif 000003
【図２】
2006277458.tif 000004
【図３】
2006277458.tif 000005
【図４】
2006277458.tif 000006
【図５】
2006277458.tif 000007
【図６】
2006277458.tif 000008
【図７】
2006277458.tif 000009
【図８】
2006277458.tif 000010
【図９】
2006277458.tif 000011
【図１０】
2006277458.tif 000012
【図１１】
2006277458.tif 000013
【図１２】
2006277458.tif 000014
【図１３】
2006277458.tif 000015