(57)【特許請求の範囲】
【請求項１】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
を備えることを特徴とするリソース割り当てシステム。
【請求項２】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
を備えることを特徴とするリソース割り当てシステム。
【請求項３】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、所定期間内における２つのリソースプールのうち一方のリソース需要の変化率と、他方のリソース需要の変化率との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
を備えることを特徴とするリソース割り当てシステム。
【請求項４】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
を備えることを特徴とするリソース割り当てシステム。
【請求項５】
前記リソースプールのリソース需要とは、仮想マシン、コンテナ、メモリ、ストレージ、ＣＰＵタイム、ネットワーク帯域のうちいずれかである、
ことを特徴とする請求項１ないし４のうちいずれか１項に記載のリソース割り当てシステム。
【請求項６】
異なるリソースプールが備えるリソース間でデータのレプリケーションを行うクラスタリング手段を更に備え、
実行中のリソースが奪取された場合にレプリケーションが処理を引き継ぐことで、サービス中断を防止する、
ことを特徴とする請求項１ないし５のうちいずれか１項に記載のリソース割り当てシステム。
【請求項７】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
前記リソース需要監視手段から各リソースプールのリソース需要の推移情報を取得して、取得した前記リソースプールのうち２つに着目したとき、一方のリソース需要の変化の方向と、他方のリソース需要の変化の方向とが反対方向であるとき、２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
を備えることを特徴とするリソース割り当てシステム。
【請求項８】
リソースプールが備えるリソースを顧客に割り当てるリソース割り当て方法であって、
複数のリソースプールそれぞれのリソース需要を監視するステップと、
前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるステップと、
を含むことを特徴とするリソース割り当て方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース割り当てシステム、および、リソース割り当て方法に関する。
【背景技術】
【０００２】
近年、仮想化や分散技術の進展に伴い、コンピューティングやストレージ、ネットワーク等のリソースをプール化して複数のサービスでシェアするモデルが普及している。このモデルにおいて各サービスは、プールされたリソースを必要な時に必要な分だけ利用することができる。
【０００３】
図７は、第１比較例におけるリソース割り当てシステムの構成図である。
リソースプール５１は、物理サーバ５２ａ〜５２ｄを備え、これら物理サーバ５２ａ〜５２ｄが備えるコンピューティングやストレージ、ネットワーク等のリソースをプール化している。以下、各物理サーバ５２ａ〜５２ｄを特に区別しないときには、単に物理サーバ５２と記載する。
【０００４】
この物理サーバ５２ａ〜５２ｄは、それぞれＨｙｐｅｒＶｉｓｏｒ５３によって複数のＶＭ（Virtual Machine）４４を具現化している。ＨｙｐｅｒＶｉｓｏｒ５３は、コンピュータを仮想化して、複数の異なるＯＳ（Operating System）を並列に実行できるようにするソフトウェアである。
各ＶＭ４４は仮想のコンピュータであり、各ＶＭ４４上で複数の異なるＯＳを並列に実行可能である。各ＶＭ４４は、サービスＡ（３ａ）、サービスＢ（３ｂ）、サービスＣ（３ｃ）、サービスＤ（３ｄ）に適宜割り当てられる。以下、各サービスＡ（３ａ）、サービスＢ（３ｂ）、サービスＣ（３ｃ）、サービスＤ（３ｄ）を特に区別しないときには、単にサービス３と記載する。
これらサービス３は、割り当てられたリソース（ＶＭ４４など）を用いて、ユーザにサービスを提供する。
【０００５】
このようなリソースプール型のインフラストラクチャにおけるプール容量の設計では、コストとサービスレベルとがトレードオフの関係となる。サービスレベルとは、各サービスのリソース需要をどの程度満たせるかの指標である。必要な時に必要な分のリソースを利用できない場合、サービスレベルが低下する。
【０００６】
図８は、第１比較例における各リソースプールのリソース需要推移の一例を示すグラフである。グラフの縦軸は各サービスのリソース需要を示し、横軸は時間の経過を示している。
ここでは、サービスＡ（３ａ）のリソース需要を実線で示している。サービスＢ（３ｂ）のリソース需要を細実線で示している。サービスＣ（３ｃ）のリソース需要を細破線で示している。サービスＤ（３ｄ）のリソース需要を破線で示している。各サービスのリソース需要の合計を太実線で示している。リソースプール５１の容量を、横方向の破線で示している。
【０００７】
各サービス３のリソース需要の合計がリソースプール５１の容量を超えたとき、リソースプール５１は、各サービス３に対して充分なリソースを提供できなくなる。よって、サービスレベルを向上させるには、リソースプール５１の容量を増大させることが必要である。しかし、リソースプール５１の容量の増大には、物理サーバ５２などのハードウェア増設または入替えを要するため、コスト効率は減少する。このように、サービスレベルとコスト効率とは、トレードオフの関係を有している。
【０００８】
前述のトレードオフの関係を踏まえ、サービスに優先度を付けて、高優先のサービスに優先的にリソースを提供するアプローチが普及してきている。非特許文献１，２には、稼働率を保証しない替わりに低価格でインスタンス（リソース）を提供するサービスの例が記載されている。このようなアプローチを、図９と図１０に示した第２比較例で説明する。
【０００９】
図９は、第２比較例における各リソースプールのリソース需要推移の一例を示すグラフである。グラフの縦軸は各サービスのリソース需要を示し、横軸は時間の経過を示している。
ここでは、高優先サービスのリソース需要を実線で示している。低優先サービスのリソース需要を破線で示している。各サービスのリソース需要の合計を太実線で示している。リソースプール５１の容量を、横方向の破線で示している。更に、各サービスのリソース需要の合計が、リソースプール５１の容量を超えた期間Ｐ０〜Ｐ４を、それぞれハッチングで示している。これら期間Ｐ０〜Ｐ４において、低優先サービスには充分にリソースが提供されないおそれがある。
【００１０】
図１０は、第２比較例におけるリソース割り当て処理を説明するフローチャートである。
リソースプール５１の残容量が逼迫すると（ステップＳ５０→Ｙｅｓ）、不図示のリソース管理手段は、高優先サービスに対して優先的にリソースを提供する（ステップＳ５１）。これは、期間Ｐ０〜Ｐ４における処理であり、このとき低優先サービスはリソースを奪取されるおそれがある。
リソースプール５１の残容量が充分ならば（ステップＳ５０→Ｎｏ）、不図示のリソース管理手段は、各サービスに優先度を付けず、要求されたリソースをサービスに提供する（ステップＳ５２）。これは、期間Ｐ０〜Ｐ４以外における処理である。
【００１１】
第２比較例に示したアプローチにおいてリソースが逼迫した場合、低優先のサービスは、自身のリソースを奪取されるおそれがあり、奪取されるリソースの数や比率が見積もれない。そのため、リソース逼迫時の影響度を予測することはできない。そのため、第２比較例のアプローチは、処理中断が許容される用途にしか利用されていない。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】Amazon Web Services,Inc，“Amazon EC2 Spot instances”，[online] ，2016年，[平成２８年５月３０日検索]，インターネット<URL:https://aws.amazon.com/ec2/spot/?nc1=h_ls>
【非特許文献２】Google，“GoogleCloudPlatform PREEMPTIBLE VIRTUAL MACHINES”，[平成２８年５月３０日検索]，インターネット<URL:https://cloud.google.com/preemptible-vms/?hl=en>
【発明の概要】
【発明が解決しようとする課題】
【００１３】
前述した第１比較例の発明においてサービスレベルとコスト効率は、トレードオフの関係を有している。非特許文献１，２に記載の発明や第２比較例の発明によれば、低価格で所定のサービスレベルを提供することができる。その代わりに、リソースが逼迫したときに処理が中断してしまうおそれがある。
【００１４】
そこで、本発明は、低価格で安定したサービスレベルの提供を可能とするリソース割り当てシステム、および、リソース割り当て方法を提供することを課題とする。
【課題を解決するための手段】
【００１５】
前記した課題を解決するため、請求項１に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、を備えることを特徴とするリソース割り当てシステムとした。
【００１６】
このようにすることで、物理リソースの増設なしにリソース逼迫に対処できるので、低価格で安定したサービスレベルの提供を可能とすることができる。そして、容易にリソース需要の傾向を算出することができる。
【００２１】
請求項２に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、を備えることを特徴とするリソース割り当てシステムとした。
【００２２】
このようにすることで、物理リソースの増設なしにリソース逼迫に対処できるので、低価格で安定したサービスレベルの提供を可能とすることができる。そして、リソースのピークタイムが異なる２つのリソースプールを選択できるので、一方のリソースプールにおけるリソース需要のピークタイム時には、他方のリソースプールに属するリソースで対処可能となる。
【００２３】
請求項３に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、所定期間内における２つのリソースプールのうち一方のリソース需要の変化率と、他方のリソース需要の変化率との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、を備えることを特徴とするリソース割り当てシステムとした。
【００２４】
このようにすることで、物理リソースの増設なしにリソース逼迫に対処できるので、低価格で安定したサービスレベルの提供を可能とすることができる。そして、選択したリソースプールのリソース需要の変化率がそれぞれ異なるので、リソース逼迫が同時に発生することは少ない。よって、いずれかのリソースプールのリソースで対処できる蓋然性が高まる。
請求項４に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、を備えることを特徴とするリソース割り当てシステムとした。
請求項５に記載の発明では、前記リソースプールのリソース需要とは、仮想マシン、コンテナ、メモリ、ストレージ、ＣＰＵタイム、ネットワーク帯域のうちいずれかである、ことを特徴とする請求項１ないし４のうちいずれか１項に記載のリソース割り当てシステムとした。
【００２５】
請求項６に記載の発明では、異なるリソースプールが備えるリソース間でデータのレプリケーションを行うクラスタリング手段を更に備え、実行中のリソースが奪取された場合にレプリケーションが処理を引き継ぐことで、サービス中断を防止する、ことを特徴とする請求項１ないし５のうちいずれか１項に記載のリソース割り当てシステムとした。
【００２６】
このようにすることで、或るリソースプールでリソース逼迫しても、そのリソースに格納されるデータは、他のリソースプールに属するリソースにレプリケーションされているので、処理を継続して高可用性を維持することができる。
【００２７】
請求項７に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、前記リソース需要監視手段から各リソースプールのリソース需要の推移情報を取得して、取得した前記リソースプールのうち２つに着目したとき、一方のリソース需要の変化の方向と、他方のリソース需要の変化の方向とが反対方向であるとき、２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、を備えることを特徴とするリソース割り当てシステムとした。
【００２８】
このようにすることで、一方のリソースプールでリソース逼迫しても、他方のリソースプールではリソース逼迫する蓋然性が低いので、その他方のリソースプールのリソースで処理を継続できる。
【００２９】
請求項８に記載の発明では、リソースプールが備えるリソースを顧客に割り当てるリソース割り当て方法であって、複数のリソースプールそれぞれのリソース需要を監視するステップと、前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるステップと、を含むことを特徴とするリソース割り当て方法とした。
【００３０】
このようにすることで、物理リソースの増設なしにリソース逼迫に対処できるので、低価格で安定したサービスレベルの提供を可能とすることができる。そして、容易にリソース需要の傾向を算出することができる。
【発明の効果】
【００３１】
本発明によれば、低価格で安定したサービスレベルの提供が可能となる。
【図面の簡単な説明】
【００３２】
【図１】第１の実施形態におけるリソース割り当てシステムの構成図である。
【図２】各リソースプールのリソース需要の推移の一例を示すグラフである。
【図３】リソース管理装置が実行する処理を説明するフローチャートである。
【図４】リソース管理装置が実行する処理の詳細を説明するフローチャートである。
【図５】クラスタリングミドルウェアが実行する処理を説明するフローチャートである。
【図６】第２の実施形態におけるリソース管理装置が実行する処理を説明するフローチャートである。
【図７】第１比較例におけるリソース割り当てシステムの構成図である。
【図８】第１比較例における各リソースプールのリソース需要推移の一例を示すグラフである。
【図９】第２比較例における各リソースプールのリソース需要推移の一例を示すグラフである。
【図１０】第２比較例におけるリソース割り当て処理を説明するフローチャートである。
【発明を実施するための形態】
【００３３】
以降、本発明を実施するための形態を、各図を参照して詳細に説明する。
【００３４】
図１は、第１の実施形態におけるリソース割り当てシステムの構成図である。
リソース割り当てシステムは、リソース管理装置１と、リソース需要監視装置２とを含んで構成される。これらリソース管理装置１とリソース需要監視装置２とは、ネットワークを介して拠点Ｘ（５ｘ）と拠点Ｙ（５ｙ）とに接続される。
【００３５】
拠点Ｘ（５ｘ）は、第１フロアに設けられたリソースプールＰ（５１ｐ）と、第２フロアに設けられたリソースプールＱ（５１ｑ）を備えている。拠点Ｙ（５ｙ）は、第１フロアに設けられたリソースプールＲ（５１ｒ）と、第２フロアに設けられたリソースプールＳ（５１ｓ）を備えている。以下、リソースプールＰ（５１ｐ）、リソースプールＱ（５１ｑ）、リソースプールＲ（５１ｒ）、リソースプールＳ（５１ｓ）を特に区別しないときには、単にリソースプール５１と記載する。
【００３６】
各リソースプール５１は、異なるハードウェアで構成されている。例えばリソースプールＰ（５１ｐ）を構成する物理サーバ（不図示）は、第Ｎ世代のＣＰＵ（Central Processing Unit）を備えている。リソースプールＱ（５１ｑ）を構成する物理サーバ（不図示）は、第Ｍ世代（Ｍ≠Ｎ）のＣＰＵを備えている。リソースプールＲ（５１ｒ）を構成する物理サーバ（不図示）は、ストレージとしてＳＳＤ（solid state drive）を備えている。リソースプールＳ（５１ｓ）を構成する物理サーバ（不図示）は、ストレージとしてＨＤＤ（Hard Disk Drive）を備えている。これにより各リソースプール５１の需要曲線は、異なる傾向となる。
このようにリソースプール５１は、ハードウェアタイプやロケーション等によって分けられている。
【００３７】
各リソースプール５１を構成する物理サーバ（不図示）は、それぞれハイパーバイザによって複数のＶＭ４４を含むリソース４を具現化している。リソースプールＰ（５１ｐ）が具現化したリソース４ａ，４ｂは、サービス３に払い出される。リソースプールＱ（５１ｑ）が具現化したリソース４ｃ，４ｄは、サービス３に払い出される。リソースプールＳ（５１ｓ）が具現化したリソース４ｅ，４ｆは、サービス３に払い出される。サービス３は、割り当てられたリソース４ａ〜４ｆを用いて、ユーザに所定のサービスを提供する。
【００３８】
リソース４ａは、ＶＭ４４と、ＯＳ４３と、クラスタリングミドルウェア４２と、アプリケーションプログラム（Ａｐｐ）４１とを含んで構成される。各ＶＭ４４は仮想のコンピュータであり、各ＶＭ４４上でそれぞれＯＳ４３が並列に実行される。このＯＳ４３上に、クラスタリングミドルウェア４２と、アプリケーションプログラム４１とが実行される。他のリソース４ｂ〜４ｆも同様に構成されている。
【００３９】
リソース需要監視装置２は、各リソースプール５１の需要を監視する。リソース管理装置１は、リソース需要監視装置２による監視情報に基づき、或るサービス３に払い出すリソース４を、需要曲線が異なる複数のリソースプール５１に分散させる。これにより、リソース逼迫時に奪取されるリソース４の量（比率）を抑え、より安定的にサービス３を維持することができる。
【００４０】
図２は、各リソースプール５１のリソース需要推移の一例を示すグラフである。グラフの縦軸は各リソースプール５１に要求されたリソース需要を示し、横軸は時間の経過を示している。
ここでは、リソースプールＰ（５１ｐ）のリソース需要を実線で示している。リソースプールＱ（５１ｑ）のリソース需要を一点鎖線で示している。リソースプールＲ（５１ｒ）のリソース需要を破線で示している。リソースプールＳ（５１ｓ）のリソース需要を二重線で示している。
各リソースプール５１のリソース需要推移のうち、リソースプールＰ（５１ｐ）のリソース需要推移とリソースプールＲ（５１ｒ）のリソース需要推移とは、同様な曲線となっている。また、リソースプールＰ（５１ｐ）のリソース需要と、リソースプールＱ（５１ｑ）のリソース需要とは、変化の方向が反対となっている。リソースプールＲ（５１ｒ）のリソース需要と、リソースプールＱ（５１ｑ）のリソース需要とも、変化の方向が反対となっている。
【００４１】
図３は、リソース管理装置１が実行する処理を説明するフローチャートである。
リソース管理装置１は、各リソースプール５１のリソース需要傾向を、リソース需要監視装置２に問い合わせる（ステップＳ１０）。リソースプール５１のリソース需要傾向は、例えば問い合わせ時点におけるリソース需要の値や、問い合わせ時点におけるリソース需要の値の時系列情報や、問い合わせ時点におけるリソース需要の変化量などであってもよく、限定されない。
【００４２】
次いでリソース管理装置１は、リソース需要監視装置２から、各リソースプール５１のリソース需要傾向を受信する（ステップＳ１１）。リソース管理装置１は、需要の傾向が異なる複数のリソースプール５１からリソース４を払い出して、サービス３を構成させる。このようにサービス３を構成するリソース４を割り当てるので、リソースの逼迫する場合が少なくなり、よって低価格でより安定したサービス３を構成させることが可能である。
【００４３】
例えば図１に示したサービス３では、リソース需要の傾向が似ているリソースプールＰ（５１ｐ）とリソースプールＲ（５１ｒ）のうちいずれか一方を選択してリソース４を払い出している。これにより、サービス３を構成する各リソース４ａ〜４ｆを払い出した各リソースプール５１は、同時にリソースが逼迫することが少なくなる。よって、サービス３を、より安定に動作させることができる。
本実施形態のリソース管理装置１は、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値未満であるとき、リソース需要の傾向が似ていると判断する。またリソース管理装置１は、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、リソース需要の傾向が異なると判断する。
リソース管理装置１は、需要曲線が異なる複数のリソースプール５１のリソースを組み合わせることで、リソースの逼迫の頻度を低下させ、奪取されるリソースの割合を抑えている。
【００４４】
図４は、リソース管理装置１が実行する処理の詳細を説明するフローチャートである。この処理は、図３に示したステップＳ１２で実行される。
リソース管理装置１は、全てのリソースプール５１について、ステップＳ２０〜Ｓ２５の処理を繰り返す。
【００４５】
最初、リソース管理装置１は、このリソースプール５１の需要と、他の各リソースプール５１の需要とを比べる（ステップＳ２１）。リソース管理装置１は、他の全てのリソースプール５１の需要とは傾向が異なると判別したならば（ステップＳ２２→Ｙｅｓ）、このリソースプール５１を払い出し対象に加える（ステップＳ２３）。リソース管理装置１は、いずれかのリソースプール５１の需要と傾向が類似する判別したならば（ステップＳ２２→Ｎｏ）、このリソースプール５１および類似するリソースプール５１のうち一つを、払い出し対象に加える（ステップＳ２４）。
【００４６】
ステップＳ２３，Ｓ２４の処理の後、リソース管理装置１は、全てのリソースプール５１について処理を繰り返したか否かを判別する（ステップＳ２５）。この判別条件が成立したならば、リソース管理装置１は、払い出し対象のリソースプール５１からリソース４を按分して払い出す（ステップＳ２６）。図１に示した例で、リソース管理装置１は、払い出し対象をリソースプールＰ（５１ｐ）、リソースプールＱ（５１ｑ）、リソースプールＳ（５１ｓ）として判別し、それぞれ２個のリソース４を払い出してサービス３を構成している。なお、本実施形態のサービス３を構成するには、６個のリソース４が必要である。
【００４７】
更に、クラスタリングミドルウェア４２（図１参照）等を利用し、リソースプール５１間でデータレプリケーションを行うことで、リソース奪取の深刻な影響であるデータ欠損を防ぐことができる。或るリソースプール５１のリソースが逼迫しても、他のリソースプール５１には余裕がある場合が多いからである。また、実行中の仮想リソースが奪取された場合には、その仮想マシンのレプリケーションが処理を引き継ぐことでサービス中断を防止することができる。
【００４８】
図５は、クラスタリングミドルウェア４２が実行する処理を説明するフローチャートである。
最初、クラスタリングミドルウェア４２は、自身が稼働しているＶＭ４４が属するリソースプール５１を取得する（ステップＳ３０）。
次いでクラスタリングミドルウェア４２は、このサービス３に払い出されている各ＶＭ４４について、ステップＳ３１〜Ｓ３４の処理を繰り返す。クラスタリングミドルウェア４２は、このＶＭ４４のリソースプール５１を取得し（ステップＳ３２）、自身が稼働しているＶＭ４４が属するリソースプール５１と異なるか否かを判別する（ステップＳ３３）。
【００４９】
ステップＳ３３にて両リソースプール５１が異なるならば（ステップＳ３３→Ｙｅｓ）、クラスタリングミドルウェア４２は、このＶＭ４４（リソース４）にデータのレプリケーションを実施して（ステップＳ３５）、図５の処理を終了する。これにより、異なるリソースプール５１に属するＶＭ４４（リソース４）に、データのレプリケーションを行うことができる。
【００５０】
ステップＳ３３にて両リソースプール５１が異ならないならば（ステップＳ３３→Ｎｏ）、クラスタリングミドルウェア４２は、このサービス３の全てのＶＭ４４について繰り返したか判断する（ステップＳ３４）。全てのＶＭ４４について繰り返したならば、クラスタリングミドルウェア４２は、いずれかのＶＭ４４にデータのレプリケーションを実施し（ステップＳ３６）、図５の処理を終了する。
【００５１】
このように、クラスタメンバ間でのデータレプリケーション、死活監視、フェイルオーバー等の仕組みにより、高可用性（耐障害性）を保証することができる。このクラスタリングミドルウェア４２等により高可用クラスタを構築することで、或るリソースプール５１のリソース逼迫時に、そのリソースが奪取されても、他のリソースプール５１に属するリソース４で処理を継続させることができる。
高可用性（耐障害性）を保証するクラスタリングミドルウェア４２等により、低信頼のリソース４を利用してクラスタを構築している。これによりリソース逼迫時のリソース奪取時にも処理を継続することが可能となり、高信頼なクラスタとすることができる。
【００５２】
《第１の実施形態の効果》
需要曲線が異なる複数のリソースプール５１にリソース４を分散させることで、リソース逼迫時の奪取の影響を抑えられる。
クラスタリングミドルウェア４２等のソフトウェアレイヤで高可用性（耐障害性）を補強することで、リソース逼迫時のデータ欠損を防止し、他リソースプールのリソースで処理を引き継ぐことで、リソース逼迫による影響を更に抑えられる。
【００５３】
《第２の実施形態》
第２の実施形態は、第１の実施形態とは異なり、リソース需要傾向が反対となるリソースプール５１を組み合わせて、サービス３を構成するものである。これにより、一方のリソースプール５１のリソース逼迫時には、他方のリソースプール５１のリソースには余裕があるので、リソース逼迫による影響を打ち消すことができる。
【００５４】
図６は、第２の実施形態におけるリソース管理装置１が実行する処理を説明するフローチャートである。
最初、リソース管理装置１は、各リソースプール５１のリソース需要傾向を、リソース需要監視装置２に問い合わせる（ステップＳ４０）。リソース管理装置１は、リソース需要監視装置２から、各リソースプール５１のリソース需要傾向を受信する（ステップＳ４１）。このステップＳ４０，Ｓ４１の処理は、図４に示したステップＳ１０，Ｓ１１の処理と同様である。
【００５５】
次いでリソース管理装置１は、全てのリソースプール５１について、ステップＳ４２〜Ｓ４６の処理を繰り返す。
リソース管理装置１は、このリソースプール５１の需要と、他の各リソースプール５１の需要とを比べる（ステップＳ４３）。リソース管理装置１は、このリソースプール５１の需要とは傾向が反対のリソースプール５１が有ると判別したならば（ステップＳ４４→Ｙｅｓ）、このリソースプール５１と反対傾向のリソースプール５１とを払い出し対象に加える（ステップＳ４５）。
【００５６】
ステップＳ４５の処理の後、リソース管理装置１は、全てのリソースプール５１について処理を繰り返したか判別する（ステップＳ４６）。この判別条件が成立したならば、リソース管理装置１は、払い出し対象のリソースプール５１からリソース４を按分して払い出す（ステップＳ４７）。図２に示した例でいうと、リソース管理装置１は、払い出し対象をリソースプールＰ（５１ｐ）、リソースプールＲ（５１ｒ）からそれぞれ３個のリソース４を払い出して、サービス３を構成することになる。これにより、図１に示した例と同様に、合計６個のリソース４によってサービス３を構成することができる。
なお、図６の処理において、払い出し対象のリソースプール５１が特定できなかった場合には、例えば図３と図４に示した処理によって、異なる需要傾向のリソースプール５１を特定して、これらを払い出し対象にするとよい。
【００５７】
《変形例》
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｇ）のようなものがある。
【００５８】
（ａ）  上記実施形態では、各リソースプール５１は、ＶＭ４４をサービス３に払い出していた。しかし、これに限られず各リソースプール５１は、コンテナをサービス３に払い出してもよい。なおコンテナとは、ハイパーバイザによる仮想化環境とは異なり、ＯＳで管理されたユーザプロセスをリソースとしてサービスに払い出すものである。
【００５９】
（ｂ）  リソースプール５１がサービス３に払い出すリソース４は、仮想マシンやコンテナに限定されず、仮想マシンやコンテナが使用するメモリ、ストレージ、ＣＰＵタイム、ネットワーク帯域などのリソースであってもよい。
【００６０】
（ｃ）  リソースプール５１は、各拠点のフロア単位に限定されず、任意の単位であってもよい。例えば、或る拠点に設置されている物理サーバが備えるリソース、或る部屋に設置されている物理サーバが備えるリソース、或るラックに設置されている物理サーバが備えるリソースなどであってもよい。
【００６１】
（ｄ）  リソース管理装置１は、単にリソース需要の傾向が異なる複数のリソースプールにサービスのリソースを分散させるだけではなく、リソース需要の合計値が平準化される複数のリソースプールの組合せを算出してもよい。サービスのリソースを、これら複数のリソースプールに分散させることで、リソース需要のピークが打ち消されてリソース逼迫の頻度を抑えられる。
【００６２】
（ｅ）  リソース管理装置１は、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、リソース需要の傾向が異なると判断してもよい。
【００６３】
（ｆ）  リソース管理装置１は、所定期間内の２つのリソースプールのうち一方のリソース需要の変化率と、他方のリソース需要の変化率との差が所定値以上であるとき、リソース需要の傾向が異なると判断してもよい。
（ｇ）  リソース管理装置１は、所定期間内の２つのリソースプールのうち一方のリソース需要と、他方のリソース需要率との相関性が低いとき、リソース需要の傾向が異なると判断してもよい。
【符号の説明】
【００６４】
１  リソース管理装置  （リソース管理手段）
２  リソース需要監視装置  （リソース需要監視手段）
３，３ａ〜３ｄ  サービス
４，４ａ〜４ｆ  リソース
４１  アプリケーションプログラム
４２  クラスタリングミドルウェア
４３  ＯＳ
４４  ＶＭ
５ｘ  拠点Ｘ
５ｙ  拠点Ｙ
５１  リソースプール
５２，５２ａ〜５２ｄ  物理サーバ
５３  ＨｙｐｅｒＶｉｓｏｒ
【図１】
0006595952.tif 000002
【図２】
0006595952.tif 000003
【図３】
0006595952.tif 000004
【図４】
0006595952.tif 000005
【図５】
0006595952.tif 000006
【図６】
0006595952.tif 000007
【図７】
0006595952.tif 000008
【図８】
0006595952.tif 000009
【図９】
0006595952.tif 000010
【図１０】
0006595952.tif 000011