JP6595952B2 - リソース割り当てシステム、および、リソース割り当て方法 - Google Patents

Description

本発明は、リソース割り当てシステム、および、リソース割り当て方法に関する。

近年、仮想化や分散技術の進展に伴い、コンピューティングやストレージ、ネットワーク等のリソースをプール化して複数のサービスでシェアするモデルが普及している。このモデルにおいて各サービスは、プールされたリソースを必要な時に必要な分だけ利用することができる。

図７は、第１比較例におけるリソース割り当てシステムの構成図である。
リソースプール５１は、物理サーバ５２ａ〜５２ｄを備え、これら物理サーバ５２ａ〜５２ｄが備えるコンピューティングやストレージ、ネットワーク等のリソースをプール化している。以下、各物理サーバ５２ａ〜５２ｄを特に区別しないときには、単に物理サーバ５２と記載する。

この物理サーバ５２ａ〜５２ｄは、それぞれＨｙｐｅｒＶｉｓｏｒ５３によって複数のＶＭ（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）を備えている。これにより各リソースプール５１の需要曲線は、異なる傾向となる。
このようにリソースプール５１は、ハードウェアタイプやロケーション等によって分けられている。

各リソースプール５１を構成する物理サーバ（不図示）は、それぞれハイパーバイザによって複数のＶＭ４４を含むリソース４を具現化している。リソースプールＰ（５１ｐ）が具現化したリソース４ａ，４ｂは、サービス３に払い出される。リソースプールＱ（５１ｑ）が具現化したリソース４ｃ，４ｄは、サービス３に払い出される。リソースプールＳ（５１ｓ）が具現化したリソース４ｅ，４ｆは、サービス３に払い出される。サービス３は、割り当てられたリソース４ａ〜４ｆを用いて、ユーザに所定のサービスを提供する。

リソース４ａは、ＶＭ４４と、ＯＳ４３と、クラスタリングミドルウェア４２と、アプリケーションプログラム（Ａｐｐ）４１とを含んで構成される。各ＶＭ４４は仮想のコンピュータであり、各ＶＭ４４上でそれぞれＯＳ４３が並列に実行される。このＯＳ４３上に、クラスタリングミドルウェア４２と、アプリケーションプログラム４１とが実行される。他のリソース４ｂ〜４ｆも同様に構成されている。

リソース需要監視装置２は、各リソースプール５１の需要を監視する。リソース管理装置１は、リソース需要監視装置２による監視情報に基づき、或るサービス３に払い出すリソース４を、需要曲線が異なる複数のリソースプール５１に分散させる。これにより、リソース逼迫時に奪取されるリソース４の量（比率）を抑え、より安定的にサービス３を維持することができる。

図２は、各リソースプール５１のリソース需要推移の一例を示すグラフである。グラフの縦軸は各リソースプール５１に要求されたリソース需要を示し、横軸は時間の経過を示している。
ここでは、リソースプールＰ（５１ｐ）のリソース需要を実線で示している。リソースプールＱ（５１ｑ）のリソース需要を一点鎖線で示している。リソースプールＲ（５１ｒ）のリソース需要を破線で示している。リソースプールＳ（５１ｓ）のリソース需要を二重線で示している。
各リソースプール５１のリソース需要推移のうち、リソースプールＰ（５１ｐ）のリソース需要推移とリソースプールＲ（５１ｒ）のリソース需要推移とは、同様な曲線となっている。また、リソースプールＰ（５１ｐ）のリソース需要と、リソースプールＱ（５１ｑ）のリソース需要とは、変化の方向が反対となっている。リソースプールＲ（５１ｒ）のリソース需要と、リソースプールＱ（５１ｑ）のリソース需要とも、変化の方向が反対となっている。

図３は、リソース管理装置１が実行する処理を説明するフローチャートである。
リソース管理装置１は、各リソースプール５１のリソース需要傾向を、リソース需要監視装置２に問い合わせる（ステップＳ１０）。リソースプール５１のリソース需要傾向は、例えば問い合わせ時点におけるリソース需要の値や、問い合わせ時点におけるリソース需要の値の時系列情報や、問い合わせ時点におけるリソース需要の変化量などであってもよく、限定されない。

次いでリソース管理装置１は、リソース需要監視装置２から、各リソースプール５１のリソース需要傾向を受信する（ステップＳ１１）。リソース管理装置１は、需要の傾向が異なる複数のリソースプール５１からリソース４を払い出して、サービス３を構成させる。このようにサービス３を構成するリソース４を割り当てるので、リソースの逼迫する場合が少なくなり、よって低価格でより安定したサービス３を構成させることが可能である。

例えば図１に示したサービス３では、リソース需要の傾向が似ているリソースプールＰ（５１ｐ）とリソースプールＲ（５１ｒ）のうちいずれか一方を選択してリソース４を払い出している。これにより、サービス３を構成する各リソース４ａ〜４ｆを払い出した各リソースプール５１は、同時にリソースが逼迫することが少なくなる。よって、サービス３を、より安定に動作させることができる。
本実施形態のリソース管理装置１は、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値未満であるとき、リソース需要の傾向が似ていると判断する。またリソース管理装置１は、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、リソース需要の傾向が異なると判断する。
リソース管理装置１は、需要曲線が異なる複数のリソースプール５１のリソースを組み合わせることで、リソースの逼迫の頻度を低下させ、奪取されるリソースの割合を抑えている。

図４は、リソース管理装置１が実行する処理の詳細を説明するフローチャートである。この処理は、図３に示したステップＳ１２で実行される。
リソース管理装置１は、全てのリソースプール５１について、ステップＳ２０〜Ｓ２５の処理を繰り返す。

最初、リソース管理装置１は、このリソースプール５１の需要と、他の各リソースプール５１の需要とを比べる（ステップＳ２１）。リソース管理装置１は、他の全てのリソースプール５１の需要とは傾向が異なると判別したならば（ステップＳ２２→Ｙｅｓ）、このリソースプール５１を払い出し対象に加える（ステップＳ２３）。リソース管理装置１は、いずれかのリソースプール５１の需要と傾向が類似する判別したならば（ステップＳ２２→Ｎｏ）、このリソースプール５１および類似するリソースプール５１のうち一つを、払い出し対象に加える（ステップＳ２４）。

ステップＳ２３，Ｓ２４の処理の後、リソース管理装置１は、全てのリソースプール５１について処理を繰り返したか否かを判別する（ステップＳ２５）。この判別条件が成立したならば、リソース管理装置１は、払い出し対象のリソースプール５１からリソース４を按分して払い出す（ステップＳ２６）。図１に示した例で、リソース管理装置１は、払い出し対象をリソースプールＰ（５１ｐ）、リソースプールＱ（５１ｑ）、リソースプールＳ（５１ｓ）として判別し、それぞれ２個のリソース４を払い出してサービス３を構成している。なお、本実施形態のサービス３を構成するには、６個のリソース４が必要である。

更に、クラスタリングミドルウェア４２（図１参照）等を利用し、リソースプール５１間でデータレプリケーションを行うことで、リソース奪取の深刻な影響であるデータ欠損を防ぐことができる。或るリソースプール５１のリソースが逼迫しても、他のリソースプール５１には余裕がある場合が多いからである。また、実行中の仮想リソースが奪取された場合には、その仮想マシンのレプリケーションが処理を引き継ぐことでサービス中断を防止することができる。

図５は、クラスタリングミドルウェア４２が実行する処理を説明するフローチャートである。
最初、クラスタリングミドルウェア４２は、自身が稼働しているＶＭ４４が属するリソースプール５１を取得する（ステップＳ３０）。
次いでクラスタリングミドルウェア４２は、このサービス３に払い出されている各ＶＭ４４について、ステップＳ３１〜Ｓ３４の処理を繰り返す。クラスタリングミドルウェア４２は、このＶＭ４４のリソースプール５１を取得し（ステップＳ３２）、自身が稼働しているＶＭ４４が属するリソースプール５１と異なるか否かを判別する（ステップＳ３３）。

ステップＳ３３にて両リソースプール５１が異なるならば（ステップＳ３３→Ｙｅｓ）、クラスタリングミドルウェア４２は、このＶＭ４４（リソース４）にデータのレプリケーションを実施して（ステップＳ３５）、図５の処理を終了する。これにより、異なるリソースプール５１に属するＶＭ４４（リソース４）に、データのレプリケーションを行うことができる。

ステップＳ３３にて両リソースプール５１が異ならないならば（ステップＳ３３→Ｎｏ）、クラスタリングミドルウェア４２は、このサービス３の全てのＶＭ４４について繰り返したか判断する（ステップＳ３４）。全てのＶＭ４４について繰り返したならば、クラスタリングミドルウェア４２は、いずれかのＶＭ４４にデータのレプリケーションを実施し（ステップＳ３６）、図５の処理を終了する。

このように、クラスタメンバ間でのデータレプリケーション、死活監視、フェイルオーバー等の仕組みにより、高可用性（耐障害性）を保証することができる。このクラスタリングミドルウェア４２等により高可用クラスタを構築することで、或るリソースプール５１のリソース逼迫時に、そのリソースが奪取されても、他のリソースプール５１に属するリソース４で処理を継続させることができる。
高可用性（耐障害性）を保証するクラスタリングミドルウェア４２等により、低信頼のリソース４を利用してクラスタを構築している。これによりリソース逼迫時のリソース奪取時にも処理を継続することが可能となり、高信頼なクラスタとすることができる。

《第１の実施形態の効果》
需要曲線が異なる複数のリソースプール５１にリソース４を分散させることで、リソース逼迫時の奪取の影響を抑えられる。
クラスタリングミドルウェア４２等のソフトウェアレイヤで高可用性（耐障害性）を補強することで、リソース逼迫時のデータ欠損を防止し、他リソースプールのリソースで処理を引き継ぐことで、リソース逼迫による影響を更に抑えられる。

《第２の実施形態》
第２の実施形態は、第１の実施形態とは異なり、リソース需要傾向が反対となるリソースプール５１を組み合わせて、サービス３を構成するものである。これにより、一方のリソースプール５１のリソース逼迫時には、他方のリソースプール５１のリソースには余裕があるので、リソース逼迫による影響を打ち消すことができる。

図６は、第２の実施形態におけるリソース管理装置１が実行する処理を説明するフローチャートである。
最初、リソース管理装置１は、各リソースプール５１のリソース需要傾向を、リソース需要監視装置２に問い合わせる（ステップＳ４０）。リソース管理装置１は、リソース需要監視装置２から、各リソースプール５１のリソース需要傾向を受信する（ステップＳ４１）。このステップＳ４０，Ｓ４１の処理は、図４に示したステップＳ１０，Ｓ１１の処理と同様である。

次いでリソース管理装置１は、全てのリソースプール５１について、ステップＳ４２〜Ｓ４６の処理を繰り返す。
リソース管理装置１は、このリソースプール５１の需要と、他の各リソースプール５１の需要とを比べる（ステップＳ４３）。リソース管理装置１は、このリソースプール５１の需要とは傾向が反対のリソースプール５１が有ると判別したならば（ステップＳ４４→Ｙｅｓ）、このリソースプール５１と反対傾向のリソースプール５１とを払い出し対象に加える（ステップＳ４５）。

ステップＳ４５の処理の後、リソース管理装置１は、全てのリソースプール５１について処理を繰り返したか判別する（ステップＳ４６）。この判別条件が成立したならば、リソース管理装置１は、払い出し対象のリソースプール５１からリソース４を按分して払い出す（ステップＳ４７）。図２に示した例でいうと、リソース管理装置１は、払い出し対象をリソースプールＰ（５１ｐ）、リソースプールＲ（５１ｒ）からそれぞれ３個のリソース４を払い出して、サービス３を構成することになる。これにより、図１に示した例と同様に、合計６個のリソース４によってサービス３を構成することができる。
なお、図６の処理において、払い出し対象のリソースプール５１が特定できなかった場合には、例えば図３と図４に示した処理によって、異なる需要傾向のリソースプール５１を特定して、これらを払い出し対象にするとよい。

《変形例》
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｇ）のようなものがある。

（ａ） 上記実施形態では、各リソースプール５１は、ＶＭ４４をサービス３に払い出していた。しかし、これに限られず各リソースプール５１は、コンテナをサービス３に払い出してもよい。なおコンテナとは、ハイパーバイザによる仮想化環境とは異なり、ＯＳで管理されたユーザプロセスをリソースとしてサービスに払い出すものである。

（ｂ） リソースプール５１がサービス３に払い出すリソース４は、仮想マシンやコンテナに限定されず、仮想マシンやコンテナが使用するメモリ、ストレージ、ＣＰＵタイム、ネットワーク帯域などのリソースであってもよい。

（ｃ） リソースプール５１は、各拠点のフロア単位に限定されず、任意の単位であってもよい。例えば、或る拠点に設置されている物理サーバが備えるリソース、或る部屋に設置されている物理サーバが備えるリソース、或るラックに設置されている物理サーバが備えるリソースなどであってもよい。

（ｄ） リソース管理装置１は、単にリソース需要の傾向が異なる複数のリソースプールにサービスのリソースを分散させるだけではなく、リソース需要の合計値が平準化される複数のリソースプールの組合せを算出してもよい。サービスのリソースを、これら複数のリソースプールに分散させることで、リソース需要のピークが打ち消されてリソース逼迫の頻度を抑えられる。

（ｅ） リソース管理装置１は、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、リソース需要の傾向が異なると判断してもよい。

（ｆ） リソース管理装置１は、所定期間内の２つのリソースプールのうち一方のリソース需要の変化率と、他方のリソース需要の変化率との差が所定値以上であるとき、リソース需要の傾向が異なると判断してもよい。
（ｇ） リソース管理装置１は、所定期間内の２つのリソースプールのうち一方のリソース需要と、他方のリソース需要率との相関性が低いとき、リソース需要の傾向が異なると判断してもよい。

１ リソース管理装置 （リソース管理手段）
２ リソース需要監視装置 （リソース需要監視手段）
３，３ａ〜３ｄ サービス
４，４ａ〜４ｆ リソース
４１ アプリケーションプログラム
４２ クラスタリングミドルウェア
４３ ＯＳ
４４ ＶＭ
５ｘ 拠点Ｘ
５ｙ 拠点Ｙ
５１ リソースプール
５２，５２ａ〜５２ｄ 物理サーバ
５３ ＨｙｐｅｒＶｉｓｏｒ

Claims (8)

1. リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
   複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
   前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
   を備えることを特徴とするリソース割り当てシステム。
2. リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
   複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
   前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
   を備えることを特徴とするリソース割り当てシステム。
3. リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
   複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
   前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、所定期間内における２つのリソースプールのうち一方のリソース需要の変化率と、他方のリソース需要の変化率との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
   を備えることを特徴とするリソース割り当てシステム。
4. リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
   複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
   前記リソース需要監視手段から前記リソースプールのリソース需要を取得して、取得した前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要のピークタイムと、他方のリソース需要のピークタイムとの重なりが所定の割合を超えていないとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
   を備えることを特徴とするリソース割り当てシステム。
5. 前記リソースプールのリソース需要とは、仮想マシン、コンテナ、メモリ、ストレージ、ＣＰＵタイム、ネットワーク帯域のうちいずれかである、
   ことを特徴とする請求項１ないし４のうちいずれか１項に記載のリソース割り当てシステム。
6. 異なるリソースプールが備えるリソース間でデータのレプリケーションを行うクラスタリング手段を更に備え、
   実行中のリソースが奪取された場合にレプリケーションが処理を引き継ぐことで、サービス中断を防止する、
   ことを特徴とする請求項１ないし５のうちいずれか１項に記載のリソース割り当てシステム。
7. リソースプールが備えるリソースを顧客に割り当てるリソース割り当てシステムであって、
   複数のリソースプールそれぞれのリソース需要を監視するリソース需要監視手段と、
   前記リソース需要監視手段から各リソースプールのリソース需要の推移情報を取得して、取得した前記リソースプールのうち２つに着目したとき、一方のリソース需要の変化の方向と、他方のリソース需要の変化の方向とが反対方向であるとき、２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるリソース管理手段と、
   を備えることを特徴とするリソース割り当てシステム。
8. リソースプールが備えるリソースを顧客に割り当てるリソース割り当て方法であって、
   複数のリソースプールそれぞれのリソース需要を監視するステップと、
   前記リソースプールのうち２つに着目したとき、２つのリソースプールのうち一方のリソース需要の時間的推移と、他方のリソース需要の時間的推移との差が所定値以上であるとき、前記２つのリソースプールのリソース需要の傾向が異なると判断し、各前記２つのリソースプールのリソースを顧客に割り当てるステップと、
   を含むことを特徴とするリソース割り当て方法。

Images