(57)【特許請求の範囲】
【請求項１】
複数種類の通信処理のうち何れかの通信処理を実行するサーバ群のうち、１つ以上のサーバが複数の拠点に配備された環境で、各拠点のサーバのリソースの負荷状況情報を他の拠点とネットワーク経由で相互に通信して交換し、実行される通信処理の種類ごとの各拠点のサーバのリソースの前記負荷状況情報を把握する負荷状況把握手段と、
前記負荷状況把握手段により把握された通信処理の種類ごとの各拠点のサーバのリソースの前記負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とを通信処理の種類ごとに比較することで、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理の種類ごとに算出し出力するオーバーヘッド算出手段と、
を備え、
前記オーバーヘッド算出手段は、
各拠点の通信処理の種類ごとのリソースとして、ＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース量を各拠点の通信処理の種類ごとに算出し、
自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として通信処理の種類ごとに算出し、
通信処理の種類ごとの各拠点の最新の負荷状況情報に含まれたＣＰＵ使用率に前記ＣＰＵリソース比率を乗算し、乗算結果を単位時間当たりの処理要求数で割り算して得られた値を正規化ＣＰＵ使用率として各拠点の通信処理の種類ごとに算出し、
通信処理の種類ごとに他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、前記オーバーヘッドとして通信処理の種類ごとに算出し出力する、
リソース管理装置。
【請求項２】
複数種類の通信処理の何れかの通信処理を実行するサーバ群を含んで構成される通信システムに含まれ、複数の拠点それぞれに配備された１つ以上のサーバのリソースを管理することを特徴とする請求項１に記載のリソース管理装置。
【請求項３】
複数種類の通信処理のうち何れかの通信処理を実行するサーバ群のうち、１つ以上のサーバが複数の拠点に配備された環境で、リソース管理装置により実行されるリソース管理方法であって、
各拠点のサーバのリソースの負荷状況情報を他の拠点とネットワーク経由で相互に通信して交換し、実行される通信処理の種類ごとの各拠点のサーバのリソースの前記負荷状況情報を把握する負荷状況把握ステップと、
前記負荷状況把握ステップにより把握された通信処理の種類ごとの各拠点のサーバのリソースの前記負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とを通信処理の種類ごとに比較することで、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理の種類ごとに算出し出力するオーバーヘッド算出ステップと、
を備え、
前記オーバーヘッド算出ステップでは、
各拠点の通信処理の種類ごとのリソースとして、ＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース量を各拠点の通信処理の種類ごとに算出し、
自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として通信処理の種類ごとに算出し、
通信処理の種類ごとの各拠点の最新の負荷状況情報に含まれたＣＰＵ使用率に前記ＣＰＵリソース比率を乗算し、乗算結果を単位時間当たりの処理要求数で割り算して得られた値を正規化ＣＰＵ使用率として各拠点の通信処理の種類ごとに算出し、
通信処理の種類ごとに他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、前記オーバーヘッドとして通信処理の種類ごとに算出し出力する、
リソース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の拠点それぞれに配備された１つ以上のサーバのリソースを管理するリソース管理装置およびリソース管理方法に関する。
【背景技術】
【０００２】
従来から、携帯電話網等の通信システムにおいて、音声通信やメール等の複数種類のサービス（通信処理）が提供されている（例えば、特許文献１参照）。このような通信システムでは、複数種類の通信処理の何れかの通信処理を実行するサーバ群が複数の拠点に配備され、これらサーバ群に対し、提供するサービスの割付けが定められている。例えば、音声通信であれば音声通信用のサーバ群が、メールであればメール用のサーバ群が設けられる。これらのサーバ群の配備に際し、サービス毎に処理要求量が予め想定され、想定された処理要求量に応じた設備量が算出される。そして、サービス毎の設備量に基づいて複数の拠点にサーバ群が配備される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−３００３１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような通信システムにおいて、あるサービスを提供するにあたり、ベースとなる拠点のサーバ群に加え、距離の離れた拠点のサーバ群を用いて、サービスを提供する態様が考えられる。特に、仮想化技術を用いて、オペレータの要求に従い例えばＶＭ（Virtual Machine）の形態で動的にサービス割付け・サービス増強を行うことが考えられる。
【０００５】
ところが、距離の離れた拠点のサーバ群を用いる場合には、トラヒック集中等による拠点間ネットワークの混雑状況に起因して、予め想定された当該サービスの処理要求量に応じた設備量では所望の性能を満たせない恐れがある。
【０００６】
本発明は、上記課題を解決するために成されたものであり、トラヒック集中等による拠点間ネットワークの混雑状況を考慮した上でのサーバ群への適正なサービス割付け・サービス増強に資することを目的とする。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明に係るリソース管理装置は、複数種類の通信処理のうち何れかの通信処理を実行するサーバ群のうち、１つ以上のサーバが複数の拠点に配備された環境で、各拠点のサーバのリソースの負荷状況情報を他の拠点とネットワーク経由で相互に通信して交換し、実行される通信処理の種類ごとの各拠点のサーバのリソースの負荷状況情報を把握する負荷状況把握手段と、負荷状況把握手段により把握された通信処理の種類ごとの各拠点のサーバのリソースの負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とを通信処理の種類ごとに比較することで、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理の種類ごとに算出し出力するオーバーヘッド算出手段と、を備え、オーバーヘッド算出手段は、各拠点の通信処理の種類ごとのリソースとして、ＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース量を各拠点の通信処理の種類ごとに算出し、自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として通信処理の種類ごとに算出し、通信処理の種類ごとの各拠点の最新の負荷状況情報に含まれたＣＰＵ使用率にＣＰＵリソース比率を乗算し、乗算結果を単位時間当たりの処理要求数で割り算して得られた値を正規化ＣＰＵ使用率として各拠点の通信処理の種類ごとに算出し、通信処理の種類ごとに他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、オーバーヘッドとして通信処理の種類ごとに算出し出力する。
【０００８】
上記のようなリソース管理装置では、負荷状況把握手段が、各拠点のサーバのリソースの負荷状況情報を他の拠点とネットワーク経由で相互に通信して交換し、実行される通信処理ごとの各拠点のサーバのリソースの負荷状況情報を把握し、オーバーヘッド算出手段が、負荷状況把握手段により把握された通信処理ごとの各拠点のサーバのリソースの負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とを通信処理ごとに比較することで、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理ごとに算出し出力する。オーバーヘッド算出手段は、各拠点の通信処理ごとのリソースとして、ＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース量を各拠点の通信処理ごとに算出し、自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として通信処理ごとに算出し、通信処理ごとの各拠点の最新の負荷状況情報に含まれたＣＰＵ使用率にＣＰＵリソース比率を乗算し、乗算結果を単位時間当たりの処理要求数で割り算して得られた値を正規化ＣＰＵ使用率として各拠点の通信処理ごとに算出し、通信処理ごとに他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、前記オーバーヘッドとして通信処理ごとに算出し出力する。なお、上記の「負荷状況情報」に含まれた「ＣＰＵ使用率」は、自拠点と他拠点との間の通信遅延と、自拠点と他拠点との間の通信エラーによるパケットロス率と、を含む自拠点と他拠点との間の通信状況、に応じて得られる値である。これにより、オペレータは、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理ごとに把握できるようになる。即ち、本発明により、トラヒック集中等による拠点間ネットワークの混雑状況を考慮した上でサーバ群への適正なサービス割付け・サービス増強に資することができる。
【０００９】
上記のリソース管理装置は、複数種類の通信処理の何れかの通信処理を実行するサーバ群を含んで構成される通信システムに含まれ、複数の拠点それぞれに配備された１つ以上のサーバのリソースを管理してもよい。
【００１１】
上記のリソース管理装置は、さらに、各拠点のサーバにおける利用可能なリソースの情報に基づいて、外部から入力されたリソース増強を要する通信処理要求条件に適合するリソースの一次候補を選出し、通信処理要求条件に加え通信処理に関するオーバーヘッドをさらに基礎として、一次候補から更にリソースの候補を絞り込むとともに各拠点のサーバに対する適正化された通信処理要求条件を導出し、絞り込まれたリソースの候補および適正化された通信処理要求条件を出力する候補選出手段、を備えてもよい。この場合、候補選出手段は、各拠点のサーバにおける利用可能なリソースの情報に基づいて、外部から入力されたリソース増強を要する通信処理要求条件に適合するリソースの一次候補を選出し、通信処理要求条件に加え通信処理に関するオーバーヘッドをさらに基礎として、一次候補から更にリソースの候補を絞り込むとともに各拠点のサーバに対する適正化された通信処理要求条件を導出し、絞り込まれたリソースの候補および適正化された通信処理要求条件を出力する。これにより、オペレータは、通信処理要求条件に加えオーバーヘッドを考慮して得られた、リソースの候補および適正化された通信処理要求条件を把握できるようになり、サーバ群への適正なサービス割付け・サービス増強にさらに資することができる。
【００１２】
上記の候補選出手段は、例えば以下のようにして、リソースの候補を絞り込んで、適正化された通信処理要求条件を導出してもよい。即ち、候補選出手段は、選出されたリソースの一次候補それぞれについて、通信処理要求条件に含まれるＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース要求条件に、当該通信処理に関するオーバーヘッドを乗算して得られた積を、ＣＰＵリソース要求条件として算出し、算出されたＣＰＵリソース要求条件をＣＰＵクロックで割り算して得られた値をＣＰＵコア数要求条件として算出し、一次候補から、算出されたＣＰＵコア数要求条件が当該一次候補のＣＰＵコア数以下である一次候補を絞り込み、絞り込まれた一次候補に関するＣＰＵコア数要求条件を含んだ「適正化された通信処理要求条件」を導出してもよい。
【００１３】
ところで、本発明は、上記のようにリソース管理装置の発明として記述できる他に、以下のようにリソース管理方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。
【００１４】
即ち、本発明に係るリソース管理方法は、複数種類の通信処理のうち何れかの通信処理を実行するサーバ群のうち、１つ以上のサーバが複数の拠点に配備された環境で、リソース管理装置により実行されるリソース管理方法であって、各拠点のサーバのリソースの負荷状況情報を他の拠点とネットワーク経由で相互に通信して交換し、実行される通信処理の種類ごとの各拠点のサーバのリソースの負荷状況情報を把握する負荷状況把握ステップと、負荷状況把握ステップにより把握された通信処理の種類ごとの各拠点のサーバのリソースの負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とを通信処理の種類ごとに比較することで、通信処理の実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドを通信処理の種類ごとに算出し出力するオーバーヘッド算出ステップと、を備え、オーバーヘッド算出ステップでは、各拠点の通信処理の種類ごとのリソースとして、ＣＰＵクロックとＣＰＵコア数との積であるＣＰＵリソース量を各拠点の通信処理の種類ごとに算出し、自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として通信処理の種類ごとに算出し、通信処理の種類ごとの各拠点の最新の負荷状況情報に含まれたＣＰＵ使用率にＣＰＵリソース比率を乗算し、乗算結果を単位時間当たりの処理要求数で割り算して得られた値を正規化ＣＰＵ使用率として各拠点の通信処理の種類ごとに算出し、通信処理の種類ごとに他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、オーバーヘッドとして通信処理の種類ごとに算出し出力する。
【発明の効果】
【００１５】
本発明によれば、トラヒック集中等による拠点間ネットワークの混雑状況を考慮した上でのサーバ群への適正なサービス割付け・サービス増強に資することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態に係る通信システムの全体構成図である。
【図２】リソース管理装置の機能ブロック構成図である。
【図３】リソース管理装置のハードウェア構成例を示す図である。
【図４】通信システムにて実行される処理を示すフロー図である。
【図５】拠点Ａのリソース管理装置が保持するリソース管理ＤＢの内容と要求条件例を示す図であり、（ａ）は初期状態でのリソース管理ＤＢの内容を、（ｂ）は複数のサービス増強後のリソース管理ＤＢの内容を、（ｃ）はサービス１の要求条件例を、（ｄ）はサービス２の要求条件例を、それぞれ示す。
【図６】拠点Ａのリソース管理装置が保持する各拠点の負荷状況ＤＢの内容を示す図である。
【図７】拠点Ａのリソース管理装置が保持するオーバーヘッド情報ＤＢの内容を示す図である。
【図８】オーバーヘッド情報ＤＢの更新処理のフロー図である。
【図９】オーバーヘッド情報を考慮したサービス配備拠点候補の選出処理のフロー図である。
【図１０】図９の処理でサーバプールＡ−１についてＣＰＵコア数要求条件を算出する過程を説明するための図である。
【図１１】図９の処理でサーバプールＢ−１についてＣＰＵコア数要求条件を算出する過程を説明するための図である。
【発明を実施するための形態】
【００１７】
以下、図面と共に、本発明に係るリソース管理装置及びリソース管理方法の実施形態について説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。また、本実施形態では説明を分かりやすくするため、さまざまな数値例を示すが、これらの数値はあくまでも一例を示したにすぎない。
【００１８】
［通信システムおよびリソース管理装置の構成］
図１に、本実施形態に係る通信システム１の全体構成図を示す。図１に示すように、通信システム１は、複数の拠点に配備された、通信処理（以下では「サービス」と称する）を実行するサーバ群（以下「サーバプール」と称する）２０およびサーバプール２０のリソースを管理するリソース管理装置１０Ａ〜１０Ｄ（「リソース管理装置１０」と総称する）を含んで構成され、各拠点には、１つのリソース管理装置１０と１つ以上のサーバプール２０とが配備されている。例えば、拠点Ａに配備されたリソース管理装置は「リソース管理装置１０Ａ」と称し、拠点Ａに配備されたサーバプールは「サーバプールＡ−１」、「サーバプールＡ−２」などと称する（以下同様）。このとき、サーバプール２０のリソースは、サービスを提供するＶＭへ動的なリソースの割当てが可能な仮想化資源としてリソース管理装置１０に管理されている。このため、図４のフロー図に示すような、オペレータの要求に応じた動的なサービス割付け・増設が可能となっている。なお、上記の通信処理（本実施形態における「サービス」）としては、音声通信、電子メール、動画（リッチメディア）を送受信する通信などが挙げられる。また、図１に示すように、拠点間は、無線又は有線のネットワーク３０を介して相互に通信可能とされている。
【００１９】
図２に、リソース管理装置１０の機能ブロック構成図を示す。図２に示すように、リソース管理装置１０は、リソース管理部１１、負荷状況把握部１２、オーバーヘッド算出部１３、および候補選出部１４を備える。このうち負荷状況把握部１２は、特許請求の範囲に記載された「負荷状況把握手段」に相当し、オーバーヘッド算出部１３は「オーバーヘッド算出手段」に相当し、候補選出部１４は「候補選出手段」に相当する。なお、リソース管理部１１、負荷状況把握部１２、オーバーヘッド算出部１３、および候補選出部１４は、相互にデータや制御信号等を送受信することが可能とされ、内蔵されたＤＢ（後述するリソース管理ＤＢ１１Ａ、各拠点の負荷状況ＤＢ１２Ａ、オーバーヘッド情報ＤＢ１３Ａ）を相互に参照可能とされている。
【００２０】
リソース管理部１１は、各拠点のサーバプールのリソース状況を記憶したリソース管理ＤＢ１１Ａを含み、リソース管理ＤＢ１１Ａによって、自己の拠点だけでなく各拠点（本実施形態では拠点Ａ〜Ｄ）のサーバプールのリソースを管理する。リソース管理ＤＢ１１Ａにより保持されるリソース状況の具体例は、図５を用いて後述する。
【００２１】
負荷状況把握部１２は、各拠点のサーバプールのリソースの負荷状況を記憶した各拠点の負荷状況ＤＢ１２Ａを含み、各拠点のサーバプールのリソースの負荷状況を他拠点のリソース管理装置の負荷状況把握部と相互に情報交換して、実行されるサービスごとの各拠点の最新の負荷状況情報を把握する。各拠点の負荷状況ＤＢ１２Ａにより保持されるリソースの負荷状況の具体例は、図６を用いて後述する。
【００２２】
オーバーヘッド算出部１３は、後述する手順で、負荷状況把握部１２により把握されたサービスごとの各拠点の最新の負荷状況情報に基づいて、他拠点の負荷状況と自拠点の負荷状況とをサービスごとに比較することで、サービス実行に要する必要リソース量について、自拠点の必要リソース量に対する他拠点の必要リソース量の相対値であるオーバーヘッドをサービスごとに算出し出力する。また、オーバーヘッド算出部１３は、算出されたオーバーヘッドを記憶するオーバーヘッド情報ＤＢ１３Ａを内蔵する。オーバーヘッド情報ＤＢ１３Ａにより保持される情報の具体例は、図７を用いて後述する。
【００２３】
候補選出部１４は、後述する手順で、リソース増強時に、サービス要求条件に加え上記オーバーヘッドをさらに基礎として、リソースの候補を絞り込み、候補ごとの「適正化されたサービス要求条件」（本実施形態ではＣＰＵコア数要求条件）を導出する。
【００２４】
図３に、リソース管理装置１０のハードウェア構成例を示す。図３に示すようにリソース管理装置１０は、例えば、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read OnlyMemory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述したリソース管理装置１０の機能が発揮される。なお、リソース管理装置１０は複数のサーバ装置からなるコンピュータシステムによって構成されてもよい。
【００２５】
［通信システム全体で実行される処理］
引き続いて、図４のフロー図を用いて、通信システム１において実行される処理を説明する。
【００２６】
図４のステップＳ１では、複数のサービスについてのリソース配備を行う。ここでは、例えば、拠点Ａをベース拠点とするサービス１について、ベース拠点Ａのリソースを用いてサービス１のＶＭを新規配備するとともに他拠点Ｂ、Ｄのリソースを用いてサービス１のＶＭを配備しサービス１を増強する。また、拠点Ａをベース拠点とするサービス２について、ベース拠点Ａのリソースを用いてサービス２のＶＭを新規配備するとともに他拠点Ｃのリソースを用いてサービス２のＶＭを配備しサービス２を増強する。
【００２７】
そして、通信システム１では、各拠点のリソース管理装置１０Ａ〜１０Ｄは、定期的に各拠点のリソース情報をやり取りし、リソース管理ＤＢ１１Ａ、各拠点の負荷状況ＤＢ１２Ａ、およびオーバーヘッド情報ＤＢ１３Ａを更新する（ステップＳ２）。各ＤＢの内容については図５〜図７を用いて後述する。オーバーヘッドの算出処理については図８を用いて後述する。
【００２８】
その後、オペレータから拠点Ａのリソース管理装置１０Ａに対し、拠点Ａのサービス１のリソース増強指示およびサービス要求条件が入力されると（ステップＳ３）、リソース管理装置１０Ａは、オーバーヘッド情報を考慮してサービスのＶＭ配備先候補を選択する（ステップＳ４）。この処理については図９〜図１１を用いて後述する。
【００２９】
リソース管理装置１０Ａが、処理結果（サービスのＶＭ配備先候補の一覧と適正化されたサービス要求条件）をオペレータに提示すると（ステップＳ５）、オペレータは、サービスのＶＭ配備先候補の一覧から１つの拠点（ここでは例えば拠点Ｂ）を選択する（ステップＳ６）。
【００３０】
これを受け、リソース管理装置１０Ａは、拠点Ｂのリソース管理装置１０Ｂに対しサービス増設要求を送信する（ステップＳ７）。これを受けたリソース管理装置１０Ｂは、サービス増設要求に応じたサービス増設を行い、リソース管理ＤＢ１１Ａを更新する（ステップＳ８）。
【００３１】
そして、リソース管理装置１０Ｂがリソース管理装置１０Ａに対しサービス増設が完了した旨の応答を送ると（ステップＳ９）、リソース管理装置１０Ａは、オペレータに対し拠点Ａのサービス１のＶＭを拠点Ｂに増設したことを通知する（ステップＳ１０）。これにより、オペレータは、拠点Ａのサービス１のＶＭを拠点Ｂに増設したことにより、拠点Ａのサービス１のリソース増強が完了したことを認識することができる。
【００３２】
なお、上記のような拠点Ｂでのサービス増設後のリソース状況は、各拠点のリソース管理装置１０Ａ〜１０Ｄ同士で情報交換され、各リソース管理装置１０が備えるリソース管理ＤＢ１１Ａが更新される。
【００３３】
［各ＤＢの内容］
ここで、図５〜図７を用いて各ＤＢの内容を説明する。
【００３４】
図５（ａ）には初期状態の拠点Ａリソース管理装置１０Ａが備えるリソース管理ＤＢ１１Ａの一例を示す。この図５（ａ）に示すように、リソース管理ＤＢ１１Ａには、各拠点のサーバプールごとのリソース状況として、ＣＰＵクロック、ＣＰＵコア数、使用可能なメモリ容量（図５（ａ）では「メモリ」と略記）、および予め測定された自拠点と他拠点間の遅延時間（図５（ａ）では「遅延」と略記）が、サーバプールのＩＤ（Ａ−１、Ａ−２など）に対応付けられて記憶されている。同様に、図５（ｂ）には複数のサービス増強後の拠点Ａリソース管理装置１０Ａが備えるリソース管理ＤＢの一例が示されている。
【００３５】
図５（ｃ）にはサービス１の要求条件として、ＣＰＵクロック、ＣＰＵコア数、メモリおよび許容される最大遅延時間（図５（ｃ）では「遅延」と略記）のそれぞれの数値、即ち、１．７ＧＨｚ、５０、１ＴＢ、１０ｍｓが記載されている。図５（ａ）のリソース管理ＤＢ１１Ａの内容に照らし、サービス１の要求条件を充足するサーバプールとして、例えば、サーバプールＤ−１が挙げられ、仮にサービス１の要求条件に沿ったリソース増強時（図４のステップＳ１）にサーバプールＤ−１が充当されたとすると、図５（ｂ）に示すようにリソース管理ＤＢ１１ＡにおけるサーバプールＤ−１に関するＣＰＵコア数、メモリはそれぞれ、初期状態から「５０」、「１ＴＢ」が減算され、ともに「０」に更新されることとなる（図４のステップＳ２のリソース管理ＤＢ更新）。
【００３６】
同様に、図５（ｄ）にはサービス２の要求条件（ＣＰＵクロック、ＣＰＵコア数、メモリおよび許容される最大遅延時間）が記載されており、図５（ａ）のリソース管理ＤＢ１１Ａの内容に照らし、サービス２の要求条件を充足するサーバプールとしては、例えば、サーバプールＣ−３が挙げられる。仮にサービス２の要求条件に沿ったリソース増強時（図４のステップＳ１）にサーバプールＣ−３が充当されたとすると、図５（ｂ）に示すようにリソース管理ＤＢ１１ＡにおけるサーバプールＣ−３に関するＣＰＵコア数、メモリはそれぞれ、初期状態から「５０」、「１ＴＢ」が減算され、ともに「０」に更新されることとなる（図４のステップＳ２のリソース管理ＤＢ更新）。
【００３７】
図６には、拠点Ａのリソース管理装置１０Ａが保持する各拠点の負荷状況ＤＢ１２Ａの一例を示す。この図６に示すように、各拠点の負荷状況ＤＢ１２Ａには、各拠点のサーバプールのＩＤ（Ａ−１、Ｂ−１など）に対応付けられて、ＣＰＵクロック、割当ＣＰＵコア数、単位時間（例えば１秒）当たりの受信要求数（図６では「受信要求数」と略記）、ＣＰＵ使用率、サービスのベース拠点（ここでは拠点Ａ）との間の遅延時間（図６では「遅延」と略記）、およびパケットロス率が記憶されている。また、各拠点の負荷状況ＤＢ１２Ａでは、提供されるサービス（サービス１、２など）ごとに、複数のサーバプールがグルーピングされて上記の各種情報が管理されている。上記の単位時間当たりの受信要求数、ＣＰＵ使用率、サービスのベース拠点との間の遅延時間、およびパケットロス率は、状況によって時々刻々と変化する値であり、これらの値は図４のステップＳ２において定期的に更新されている。なお、上記のうち「ＣＰＵ使用率」は、自拠点と他拠点との間の通信状況（通信エラーに起因したパケットロス率や通信遅延などの要因）に応じて得られる測定値であるため、「ＣＰＵ使用率」には、図６中の「遅延」、「パケットロス率」の要因が反映された値となっている。したがって、後述の実施形態では、「遅延」、「パケットロス率」の要因が反映された「ＣＰＵ使用率」を用いて、本発明に係るオーバーヘッド（本実施形態のＣＰＵオーバーヘッド）を算出する例を説明する。
【００３８】
図７には、拠点Ａのリソース管理装置１０Ａが保持するオーバーヘッド情報ＤＢ１３Ａの一例を示す。この図７に示すように、オーバーヘッド情報ＤＢ１３Ａには、各拠点のサーバプールのＩＤ（Ａ−１、Ｂ−１など）に対応付けられて、後に算出方法を説明するＣＰＵリソース量、ＣＰＵリソース比率、正規化されたＣＰＵ使用率（以下「正規化ＣＰＵ使用率」という）およびＣＰＵオーバーヘッドが記憶されている。また、オーバーヘッド情報ＤＢ１３Ａでは、提供されるサービス（サービス１、２など）ごとに、複数のサーバプールがグルーピングされて上記の各種情報が管理されている。
【００３９】
［オーバーヘッド情報ＤＢの更新処理］
以下、図４のステップＳ２の中で実行されるオーバーヘッド情報ＤＢ１３Ａの更新処理を、図８のフロー図に沿って説明する。
【００４０】
まず、負荷状況把握部１２が、他拠点との情報のやりとりによって他拠点から負荷状況を収集し、自拠点および他拠点の最新の負荷状況により、各拠点の負荷状況ＤＢ１２Ａを更新する（図８のステップＳ１１）。
【００４１】
次に、オーバーヘッド算出部１３が、各拠点の負荷状況ＤＢ１２Ａを参照し、各拠点のサービスのＶＭに割り当てられたＣＰＵクロックとＣＰＵコア数とを掛け合わせたものを、ＣＰＵリソース量として算出しオーバーヘッド情報ＤＢ１３Ａに記憶する（ステップＳ１２）。図６、図７の例では、例えば、サービス１のリソースを提供するサーバプールＡ−１については、ＣＰＵクロック「１．８」（単位：ＧＨｚ）と割当ＣＰＵコア数「５０」とを掛け合わせて得られた「９０」がＣＰＵリソース量として算出され、図７に示すようにサーバプールＡ−１に関するＣＰＵリソース量として記憶される。他のサーバプールについても同様に、ＣＰＵリソース量が算出・記憶される。
【００４２】
そして、オーバーヘッド算出部１３は、自拠点のＣＰＵリソース量に対する他拠点のＣＰＵリソース量の比率を、ＣＰＵリソース比率として各拠点のサービスごとに算出しオーバーヘッド情報ＤＢ１３Ａに記憶する（ステップＳ１３）。図６、図７の例では、サービス１のリソースを提供する他拠点ＤのサーバプールＤ−１については、サーバプールＤ−１のＣＰＵリソース量「８５」を自拠点ＡのサーバプールＡ−１のＣＰＵリソース量「９０」により割り算することで、ＣＰＵリソース比率「０．９４４」が算出され、図７に示すようにサーバプールＤ−１に関するＣＰＵリソース比率として記憶される。他のサーバプールについても同様に、ＣＰＵリソース比率が算出・記憶される。
【００４３】
さらに、オーバーヘッド算出部１３は、各拠点のサービスごとに、ステップＳ１３で求めたＣＰＵリソース比率をＣＰＵ使用率に乗算し、乗算結果を単位時間当たりの受信要求数で割り算して得られた値を、正規化ＣＰＵ使用率として算出しオーバーヘッド情報ＤＢ１３Ａに記憶する（ステップＳ１４）。図６、図７の例では、サービス１のリソースを提供する拠点ＤのサーバプールＤ−１については、サーバプールＤ−１のＣＰＵリソース比率「０．９４４」をＣＰＵ使用率「３０％」に乗算し、乗算結果を単位時間当たりの受信要求数「１０」で割り算して得られた値「２．８３３％」が、正規化ＣＰＵ使用率として算出され、図７に示すようにサーバプールＤ−１に関する正規化ＣＰＵ使用率として記憶される。他のサーバプールについても同様に、正規化ＣＰＵ使用率が算出・記憶される。
【００４４】
最後に、オーバーヘッド算出部１３は、他拠点の正規化ＣＰＵ使用率を自拠点の正規化ＣＰＵ使用率で割り算して得られた値を、ＣＰＵオーバーヘッドとして算出し、得られたＣＰＵオーバーヘッドをオーバーヘッド情報ＤＢ１３Ａに記憶するとともにオペレータ向けに出力する（ステップＳ１５）。図６、図７の例では、サービス１のリソースを提供する他拠点ＤのサーバプールＤ−１については、サーバプールＤ−１の正規化ＣＰＵ使用率「２．８３３％」を自拠点ＡのサーバプールＡ−１の正規化ＣＰＵ使用率「２％」で割り算して得られた値「１．４１７」が、ＣＰＵオーバーヘッドとして算出され、図７に示すようにサーバプールＤ−１に関するＣＰＵオーバーヘッドとして記憶されるとともにオペレータ向けに出力される。他のサーバプールについても同様に、ＣＰＵオーバーヘッドが算出・記憶されオペレータ向けに出力される。
【００４５】
以上説明した図８のオーバーヘッド情報ＤＢの更新処理により、オペレータは各拠点のサービスごと（サーバプールごと）のＣＰＵオーバーヘッドを把握できるようになり、これにより、トラヒック集中等による拠点間ネットワークの混雑状況を考慮した上でのサーバ群への適正なサービス割付け・サービス増強に資することができる。
【００４６】
なお、図８のステップＳ１１が特許請求の範囲に記載された「負荷状況把握ステップ」に相当し、ステップＳ１２〜Ｓ１５が「オーバーヘッド算出ステップ」に相当する。
【００４７】
［オーバーヘッド情報を考慮したサービス配備拠点候補の選出処理］
以下、図４のステップＳ４の中で実行される、オーバーヘッド情報を考慮したサービス配備拠点候補の選出処理を、図９のフロー図に沿って説明する。
【００４８】
図４のステップＳ３でサービス要求条件（ここでは拠点Ａのサービス１のリソース増強に関するサービス要求条件）が入力されると、図９の処理が開始される。
【００４９】
まず、リソース管理装置１０の候補選出部１４は、リソース管理ＤＢ１１Ａを参照し、サービス要求条件に合う拠点とサーバプールを候補Ｓとして選出する（図９のステップＳ２１）。図１０、図１１に示す例では、例示されたサービス１の要求条件（ＣＰＵクロック：１．７ＧＨｚ、ＣＰＵコア数：５０、使用可能なメモリ容量：１ＴＢ、許容される遅延時間：１０ｍｓ）に合う拠点とサーバプールの候補Ｓとして、リソース管理ＤＢ１１Ａ内の拠点ＡのサーバプールＡ−１と拠点ＢのサーバプールＢ−１とが選出されたものとする（図１０、図１１の処理(1)）。
【００５０】
次に、候補選出部１４は、サービス要求条件のＣＰＵクロックとＣＰＵコア数とを掛け合わせて得られた値をＣＰＵリソース要求条件Ｐとして算出する（図９のステップＳ２２）。図１０、図１１に示す例では、ＣＰＵクロック「１．７ＧＨｚ」とＣＰＵコア数「５０」とを掛け合わせて得られた値「８５」がＣＰＵリソース要求条件Ｐとして算出される（図１０、図１１の処理(2)）。
【００５１】
そして、候補Ｓの全てのサーバプールＸそれぞれについて、以下に述べるステップＳ２４〜Ｓ２９の処理が繰り返し実行される。
【００５２】
まず、候補選出部１４は、処理対象とするサーバプールＸがオーバーヘッド情報ＤＢ１３Ａに記憶されているか否かを確認する（図９のステップＳ２４）。図１０、図１１に示す例では、候補Ｓとして選出されたサーバプールＡ−１、Ｂ−１はともにオーバーヘッド情報ＤＢ１３Ａに記憶されていることが確認される（図１０、図１１の処理(3)）。なお、サーバプールＸがオーバーヘッド情報ＤＢ１３Ａに記憶されていない場合（図９のステップＳ２４でＮＯの場合）は、そのサーバプールＸのオーバーヘッド情報が存在せず、ステップＳ２５〜Ｓ２９の処理が実行できないため、当該サーバプールＸについての処理を終え、次のサーバプールＸについての処理に移る。
【００５３】
サーバプールＸがオーバーヘッド情報ＤＢ１３Ａに記憶されている場合（図９のステップＳ２４でＹＥＳの場合）、候補選出部１４は、ステップＳ２２で算出されたＣＰＵリソース要求条件Ｐに、オーバーヘッド情報ＤＢ１３Ａに記憶されたサーバプールＸのＣＰＵオーバーヘッドを乗算して得られた積を、ＣＰＵリソース要求条件Ｑとして算出する（図９のステップＳ２５）。ここで算出されたＣＰＵリソース要求条件Ｑは、サーバプールＸのＣＰＵオーバーヘッドを加味して得られた値である。図１０の例ではサーバプールＡ−１について、ＣＰＵリソース要求条件「８５」にサーバプールＡ−１のＣＰＵオーバーヘッド「１」を乗算して得られた積「８５」がＣＰＵリソース要求条件Ｑとして算出される（図１０の処理(4)）。図１１の例ではサーバプールＢ−１について、ＣＰＵリソース要求条件「８５」にサーバプールＢ−１のＣＰＵオーバーヘッド「２」を乗算して得られた積「１７０」がＣＰＵリソース要求条件Ｑとして算出される（図１１の処理(4)）。
【００５４】
そして、候補選出部１４は、サーバプールＸについて算出されたＣＰＵリソース要求条件ＱをＣＰＵクロックで割り算して得られた値をＣＰＵコア数要求条件Ｙとして算出する（図９のステップＳ２６）。図１０の例ではサーバプールＡ−１について、ＣＰＵリソース要求条件「８５」をＣＰＵクロック「１．８」（単位：ＧＨｚ）で割り算して得られた値「４８」（実際には47.222が得られ、小数点以下が切り上げられて４８となる）が、ＣＰＵコア数要求条件Ｙとして算出される（図１０の処理(5)）。図１１の例ではサーバプールＢ−１について、ＣＰＵリソース要求条件「１７０」をＣＰＵクロック「１．８」（単位：ＧＨｚ）で割り算して得られた値「９５」（実際には94.444が得られ、小数点以下が切り上げられて９５となる）が、ＣＰＵコア数要求条件Ｙとして算出される（図１１の処理(5)）。
【００５５】
さらに、候補選出部１４は、リソース管理ＤＢ１１Ａに記憶されたサーバプールＸのＣＰＵコア数がＣＰＵコア数要求条件Ｙを満たすか否か、即ち、サーバプールＸのＣＰＵコア数がＣＰＵコア数要求条件Ｙ以上であるか否かを判断する（図９のステップＳ２７）。
【００５６】
サーバプールＸのＣＰＵコア数がＣＰＵコア数要求条件Ｙを満たす場合（図９のステップＳ２７でＹＥＳの場合）、候補選出部１４は、ＣＰＵコア数要求条件ＹをサーバプールＸに対する適正化されたサービス要求条件として保持する（図９のステップＳ２８）。
【００５７】
一方、サーバプールＸのＣＰＵコア数がＣＰＵコア数要求条件Ｙを満たさない場合（図９のステップＳ２７でＮＯの場合）、サーバプールＸでは性能要件が満たせないため、候補選出部１４は、サーバプールＸを候補Ｓから除外する（図９のステップＳ２９）。
【００５８】
図１０の例ではサーバプールＡ−１のＣＰＵコア数「５０」がＣＰＵコア数要求条件「４８」以上であるため、図９のステップＳ２７でＹＥＳと判断され、ＣＰＵコア数要求条件「４８」はサーバプールＡ−１に対する適正化されたサービス要求条件として保持される。図１１の例ではサーバプールＢ−１のＣＰＵコア数「１５０」がＣＰＵコア数要求条件「９５」以上であるため、図９のステップＳ２７でＹＥＳと判断され、ＣＰＵコア数要求条件「９５」はサーバプールＢ−１に対する適正化されたサービス要求条件として保持される。
【００５９】
その後、候補Ｓの全てのサーバプールＸそれぞれについて、ステップＳ２４〜Ｓ２９の処理が繰り返し実行完了すると、候補Ｓの各サーバプールに対する適正化されたサービス要求条件（本実施形態ではＣＰＵコア数要求条件）が蓄積される。ここで、候補選出部１４は、図１１の左下に記載した増設先候補および適正化されたサービス要求条件（即ち、候補Ｓの各サーバプールの情報およびＣＰＵコア数要求条件Ｙ）を出力して（図９のステップＳ３１）、処理を終了する。
【００６０】
以上説明した「オーバーヘッド情報を考慮したサービス配備拠点候補の選出処理（図９）」により、オペレータは、サービス要求条件に加えオーバーヘッドを考慮して得られた、増設先候補および適正化されたサービス要求条件を把握できるようになり、これにより、サーバ群への適正なサービス割付け・サービス増強にさらに資することができる。
【符号の説明】
【００６１】
１…通信システム、１０、１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ…リソース管理装置、１１…リソース管理部、１１Ａ…リソース管理ＤＢ、１２…負荷状況把握部、１２Ａ…各拠点の負荷状況ＤＢ、１３…オーバーヘッド算出部、１３Ａ…オーバーヘッド情報ＤＢ、１４…候補選出部、２０…サーバプール、３０…ネットワーク、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…記憶装置。
【図１】
0005984866.tif 000002
【図２】
0005984866.tif 000003
【図３】
0005984866.tif 000004
【図４】
0005984866.tif 000005
【図５】
0005984866.tif 000006
【図６】
0005984866.tif 000007
【図７】
0005984866.tif 000008
【図８】
0005984866.tif 000009
【図９】
0005984866.tif 000010
【図１０】
0005984866.tif 000011
【図１１】
0005984866.tif 000012