(57)【要約】【課題】複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、公平性かつ利用効率性を満たすリソース割当を行う。【解決手段】複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当制御を行うリソース割当制御システムは、要求リソースのうち、弾性リソースに対しては、当該弾性リソースのリソース要求量と当該弾性リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しなければ、当該弾性リソースに関する要求を受付可と判定し、非弾性リソースに対しては、公平割当量に基づき、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない範囲で当該非弾性リソースに関する要求を受付可と判定する。【選択図】図１
2018181123.tif 000002
【特許請求の範囲】
【請求項１】
複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当制御を行うリソース割当制御システムであって、
あるユーザからのリソース要求を受信するリソース要求受付手段と、
前記リソース要求を受け付けるか否かを判定するリソース要求受付判定手段と、を備え、
前記リソース要求受付判定手段は、
前記リソース要求における要求リソースのうち、弾力性を持つリソースである弾性リソースに対しては、当該弾性リソースのリソース要求量と当該弾性リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しなければ、当該弾性リソースに関する要求を受付可と判定し、
前記要求リソースのうち、弾力性を持たないリソースである非弾性リソースに対しては、公平割当量に基づき、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない範囲で当該非弾性リソースに関する要求を受付可と判定する
ことを特徴とするリソース割当制御システム。
【請求項２】
前記リソース要求受付判定手段は、前記要求リソースのうちの前記非弾性リソースに対し、
前記ユーザの前記非弾性リソースのリソース利用量が公平割当量を超えていない場合は、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合に要求を受付可と判定し、当該ユーザの当該リソース利用量が公平割当量を超えている場合は、当該非弾性リソースのリソース要求量に予備リソース量を加算した値と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合に要求を受付可と判定する
ことを特徴とする請求項１に記載のリソース割当制御システム。
【請求項３】
前記予備リソース量を、前記非弾性リソースに対する各ユーザの要求量のばらつきに基づき計算する計算手段
を更に備えることを特徴とする請求項２に記載のリソース割当制御システム。
【請求項４】
ユーザ毎の各リソースに対する要求量を、ユーザの過去のリソース要求データから生成した時系列モデルに基づき確率的に予測した予測値を求め、前記予備リソース量を当該予測値に対する実測値の乖離度合いに基づき計算する計算手段
を更に備えることを特徴とする請求項２に記載のリソース割当制御システム。
【請求項５】
前記弾性リソースに対し、当該弾性リソースのリソース要求量のユーザ合計がリソース容量を超える場合において、公平割当量となるように再割当の計算を行い、当該計算により得られた量のリソースを前記ユーザに割り当て、前記非弾性リソースに対しては、前記ユーザの要求通りにリソースを割り当てる割当手段
を更に備えることを特徴とする請求項１ないし４のうちいずれか１項に記載のリソース割当制御システム。
【請求項６】
複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当制御を行うリソース割当制御システムが実行するリソース割当制御方法であって、
あるユーザからのリソース要求を受信するリソース要求受信ステップと、
前記リソース要求を受け付けるか否かを判定するリソース要求受付判定ステップと、を備え、
前記リソース要求受付判定ステップにおいて、前記リソース割当制御システムは、
前記リソース要求における要求リソースのうち、弾力性を持つリソースである弾性リソースに対しては、当該弾性リソースのリソース要求量と当該弾性リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しなければ、当該弾性リソースに関する要求を受付可と判定し、
前記要求リソースのうち、弾力性を持たないリソースである非弾性リソースに対しては、公平割当量に基づき、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない範囲で当該非弾性リソースに関する要求を受付可と判定する
ことを特徴とするリソース割当制御方法。
【請求項７】
コンピュータを、請求項１ないし５のうちいずれか１項に記載のリソース割当制御システムにおける各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウド等のサービスで提供される複数リソースを複数ユーザで共有する技術に関連するものである。
【背景技術】
【０００２】
近年、クラウドサービスに代表される、リソースを複数ユーザで共有するサービスモデルが一般的になりつつある。これはＣＰＵ、メモリ、ストレージなどの計算機リソース、リンク帯域等のネットワークリソースを複数ユーザで共有することにより、ユーザ個々にリソースを用意するモデルと比較し、より少ないリソース量で需要を満たすことができるサービスモデルである。
【０００３】
しかしながら、リソースをユーザ間で共有する場合、個々のユーザの需要（要求と称してもよい）がリソースの上限に達する可能性がある。このような場合に備え、リソース共有モデルにおいては、ユーザの需要に対し、リソースを受け付けるか否か（割り当てるか否か）、もしくはどの程度のリソース量をユーザに割り当てるかを判断する割当制御が必要となる。
【０００４】
ここで割当制御への要件として、リソース利用効率性と、ユーザ間公平性が挙げられる。あるユーザがリソースを占有した場合に、別のユーザに需要が発生し、当該ユーザがリソースに割り当てられない場合は不公平性が発生する。一方、不公平性を避けるためにユーザに割り当てるリソースに上限を設けた場合、他のユーザの需要がない場合であっても、当該ユーザには上限以上のリソースが割り当てられず、リソースの利用効率性が下がるという課題がある。
【０００５】
更に、割り当てるリソース種別が複数の場合、ユーザのリソース種別に対する需要割合や、リソース需要が弾力性を持つか（ｅｌａｓｔｉｃか）否かを考慮して割り当てる必要がある。
【０００６】
例えば、リソース種別がＣＰＵとメモリの２種類の場合に、あるユーザのタスクがＣＰＵを多く必要とし、別のユーザのタスクはメモリを多く必要とする場合、ユーザの需要割合が異なるため、それぞれのリソースを均等割することはユーザのタスク実行の観点から効率的ではない。非特許文献１ではこのような課題に鑑み、ユーザ毎にその需要割合から主要リソース種別（Ｄｏｍｉｎａｎｔ  Ｒｅｓｏｕｒｃｅ）を決定し、主要リソースに関して公平となるようリソースを割り当てる主要リソース公平性（Ｄｏｍｉｎａｎｔ  Ｒｅｓｏｕｒｃｅ  Ｆａｉｒｎｅｓｓ）という手法が開示されている。また、主要リソースのみならず全リソースの占有率の和を公平化する資産公平性（Ａｓｓｅｔ  Ｆａｉｒｎｅｓｓ）という手法も開示されている。
【０００７】
同文献における方式は、各ユーザが無限に実行すべきタスクを持ち、割り当てられたリソースは全て使い切るという環境を想定しており、リソース容量上限まで主要リソースについて公平となるようにリソースを割り当てる方式である。しかしながら一般的なクラウド環境では各ユーザのリソース需要は有限であり、同方式による割当ではリソースが利用されない可能性がある。
【０００８】
更に同文献では、リソース需要が弾力性を持たないと仮定している。ここでリソース需要が弾力性を持つとは、ユーザの需要より少ないリソースを割り当てた場合でもユーザの需要をある程度満たせる特性をいう。例えばリソース種別がＣＰＵの場合、需要がｎ個のＣＰＵであったときにｎ−１個のＣＰＵを割り当てた場合も、タスク実行時間が（約ｎ／ｎ−１倍）増大するだけであり、基本的にはタスクを実行できる。一方で、メモリの場合、需要がｍＧＢのメモリであった場合にｍＧＢのメモリを割り当てないとタスクのデータがメモリに収まらないため、タスク自体が実行できない。従ってタスク実行時間の増大が許容できるのであればＣＰＵ需要は弾力性を持ち、メモリは弾力性を持たないリソースとなる。弾力性を持つリソースの場合、リソース需要の合計がリソース容量を超えた場合でも需要より少ないリソースを割り当てることによって当該需要を収容でき、結果的に他のリソース種別の利用効率性を向上できる可能性がある。しかしながら、このような複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、公平性かつ利用効率性を満たすリソース割当は困難であった。
【０００９】
また、非特許文献１では、ユーザが実行を要求するタスク数に制限を設けず、リソースが割り当てられる限り実行すべきタスクが存在すると仮定している。しかしながら実際にはユーザの実行タスク要求数及びリソース要求量は時々刻々動的に変化する。非特許文献２では、動的に変化するリソース要求に対応するため、非特許文献１で算出される公平割り当てを逐次適用する方式を提案しているが、各ユーザは一度のみリソース要求を発生するモデルを想定しているため、一般的にクラウド環境で発生する各ユーザが複数回リソース要求を発生し、結果的にリソース利用量が非均衡となる場合に適応できないという課題があった。また非特許文献３では複数ユーザが複数回逐次リソース要求する場合に、帯域留保と呼ばれる手法を導入することにより、公平かつ効率的なリソース分配を実現する手法を提案している。しかし同文献は単一リソースの場合のみであり、かつリソースが非弾力のケースのみを想定している。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】A. Ghodsi, M. Zaharia, B. Hindman, A. , S. Shenker, and I. Stoica, "Dominant Resource Fairness: Fair Allocation of Multiple Resource Types," Proc. USENIX NSDI'11, Boston, USA, April, 2011.
【非特許文献２】I.Kash, A.D.Procaccia, N.Shah, "No Agent Left Behind: Dynamic Fair Division of Multiple Resources," AAAMAS'2013.
【非特許文献３】S.C.Borst, D.Mitra, "Virtual Partitioning for Robust Resource Sharing: Computational Techniques for Heterogeneous Traffic," IEEE JSAC 1998.
【非特許文献４】http://www.vmware.com/files/jp/pdf/vsp_40_resource_mgmt_ja.pdf vSphere リソース管理ガイド、平成２９年４月５日検索
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述したように、複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、動的に要求が発生する状況化における、公平性かつ利用効率性を満たすリソース割当は困難であった。
【００１２】
本発明は上記課題に鑑みてなされたものであり、複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、動的に要求が発生する状況化における、公平性かつ利用効率性を満たすリソース割当を実現可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
開示の技術によれば、複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当制御を行うリソース割当制御システムであって、
あるユーザからのリソース要求を受信するリソース要求受付手段と、
前記リソース要求を受け付けるか否かを判定するリソース要求受付判定手段と、を備え、
前記リソース要求受付判定手段は、
前記リソース要求における要求リソースのうち、弾力性を持つリソースである弾性リソースに対しては、当該弾性リソースのリソース要求量と当該弾性リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しなければ、当該弾性リソースに関する要求を受付可と判定し、
前記要求リソースのうち、弾力性を持たないリソースである非弾性リソースに対しては、公平割当量に基づき、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない範囲で当該非弾性リソースに関する要求を受付可と判定する
ことを特徴とするリソース割当制御システムが提供される。
【発明の効果】
【００１４】
開示の技術によれば、複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、動的に要求が発生する状況化における、公平性かつ利用効率性を満たすリソース割当が実現可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態におけるシステム構成図である。
【図２】本発明の実施の形態におけるリソース割当制御システム１００のハードウェア構成例を示す図である。
【図３】非弾性リソースに対する受付制御の具体例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００１７】
（システム構成、動作概要）
図１に、本実施の形態におけるシステム構成例を示す。図１に示すように、本実施の形態に係るシステムには、リソース割当制御システム１００と制御対象リソース群２００が存在する。リソース割当制御システム１００は、各ユーザ（具体的にはユーザの端末）からのリソース要求を受信し、制御対象リソース群２００における各リソースを各ユーザに割り当てる制御を実行する。つまり、リソース割当制御システム１００は、複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当量を制御する。
【００１８】
制御対象リソース群２００は、例えば、クラウドにおける仮想マシンを構成する物理サーバ群であり、リソース割当制御システム１００とネットワークを介して接続されている。なお、制御対象リソース群２００は、クラウドにおける仮想マシンを構成する物理サーバ群を制御する制御装置であってもよい。
【００１９】
制御対象リソース群２００における各リソースの種類には特に限定はないが、例えば、ＣＰＵ（個数）、メモリ（容量）等である。また、制御対象リソース群２００におけるリソースには、弾力性を持つリソースと弾力性を持たないリソースの２種類が存在する。
【００２０】
図１に示すとおり、リソース割当制御システム１００は、リソース要求受付部１０１、リソース要求受付判定部１０２、リソース要求予測部１０３、公平割当計算部１０４、リソース利用量観測部１０５、リソース割当量計算部１０６を有する。各機能部の動作の詳細については後述する。リソース割当制御システム１００の動作概要は以下のとおりである。
【００２１】
リソース割当制御システム１００は、ユーザ毎の各リソースに対するリソース要求に基づき公平割当量を予め算出しておく。リソース要求は例えば要求ベクトルとして表わされる。要求ベクトルは、非特許文献１等にｄｅｍａｎｄ  ｖｅｃｔｏｒとして記載されているものであり、リソース量を表すものである。例えば、あるタスクが１ＣＰＵ、メモリ４ＧＢを必要とする場合、当該タスクの要求ベクトルは（１ＣＰＵ，４ＧＢ）と表せる。公平割当量の算出は、例えば、非特許文献１に開示された主要リソース公平性もしくは資源公平性の手法に基づいて行うことができる。
【００２２】
公平割当量の算出に用いる、ユーザ毎の各リソースに対する要求量に関しては、例えば、ユーザの過去のリソース要求データから生成した時系列モデルに基づき動的（確率的）に予測したものを使用する。
【００２３】
リソース割当制御システム１００は、あるユーザからのリソース要求を受け付けるか否かの判断を、以下のようにして行う。
【００２４】
要求リソースのうち弾力性を持つリソースに対しては、当該リソースのリソース要求量と当該リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しない限り要求を受け付ける。
【００２５】
要求リソースのうち弾力性を持たないリソースに対しては、当該ユーザの当該リソース利用量が公平割当量を超えていない場合は、当該リソースのリソース要求量と当該リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合には要求を受け付け、当該ユーザの当該リソース利用量が公平割当量を超えている場合は、当該リソースのリソース要求量に別途計算される予備リソース量を加算したものと当該リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合に要求を受け付ける。
【００２６】
上記の予備リソース量に関しては、当該リソースに対する各ユーザの要求ベクトル（要求量）のばらつきに基づき計算することができる。また、上記の予備リソース量を、前述した、ユーザの過去のリソース要求データから生成した時系列モデルに基づき動的に予測した予測値に対する実測値の乖離度合いに基づき計算することとしてもよい。
【００２７】
リソース要求の発出元のユーザに関して、弾性・非弾性リソースの全てで、要求を受け付ける判定がなされた場合に当該リソース要求を受け付けるものとする。
【００２８】
リソース割当制御システム１００は、上記のようにして受け付けたリソース要求に対して、要求されたリソースの当該ユーザへの割当を以下のようにして行う。
【００２９】
弾力性を持つリソースに対しては、当該リソースに対する要求量のユーザ合計がリソース容量を超えた場合は、公平割当量となるようにリソースの再割当を行い、弾力性を持たないリソースに対しては、ユーザの要求通りに割り当てる。
【００３０】
＜リソース割当制御システム１００のハードウェア構成＞
本実施の形態におけるリソース割当制御システム１００は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。図２は、本実施の形態におけるリソース割当制御システム１００のハードウェア構成例を示す図である。図２のリソース割当制御システム１００は、それぞれバスＢで相互に接続されているドライブ装置３００、補助記憶装置３０２、メモリ装置３０３、ＣＰＵ３０４、インタフェース装置３０５、表示装置３０６、及び入力装置３０７等を有する。
【００３１】
リソース割当制御システム１００での処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体３０１によって提供される。プログラムを記憶した記録媒体３０１がドライブ装置３００にセットされると、プログラムが記録媒体３０１からドライブ装置３００を介して補助記憶装置３０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体３０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置３０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００３２】
メモリ装置３０３は、プログラムの起動指示があった場合に、補助記憶装置３０２からプログラムを読み出して格納する。ＣＰＵ３０４は、メモリ装置３０３に格納されたプログラムに従ってリソース割当制御システム１００に係る機能を実現する。インタフェース装置３０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置３０６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置３０７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。
【００３３】
（リソース割当制御システム１００の各機能部の動作）
以下、図１に示したリソース割当制御システム１００における各機能部の動作を詳細に説明する。
【００３４】
＜リソース要求受付部１０１＞
リソース要求受付部１０１は、各ユーザからのリソース要求を受信し、リソース要求受付判定部１０２に当該要求を通知する。リソース要求は、例えば、リソース毎の要求量を含む（例：ＣＰＵ：３個、メモリ：１ＧＢ）。なお、リソース要求は、リソース要求予測部１０３にも通知される。各ユーザのリソースの要求量は時々刻々と変化するものであり、各ユーザからは、変化の度にリソース要求が出され、リソース要求受付部１０１は当該リソース要求を受信する。
【００３５】
＜リソース利用量観測部１０５＞
リソース利用量観測部１０５は、制御対象リソース群２００におけるリソース毎、ユーザ毎の利用量を観測する。
【００３６】
＜リソース要求受付判定部１０２＞
リソース要求受付判定部１０２は、ユーザから受信したリソース要求を受け付けるか否かを判定する。「リソース要求を受け付ける」とは、当該ユーザに対し、要求されたリソースの割り当てを行うことを意味する。ただし、要求された量の全部が割り当てられるとは限らない。
【００３７】
本実施の形態におけるリソース要求受付判定部１０２が実行する、基本的なリソース要求受け付け及びリソース割当の考え方は、以下の通りである。
【００３８】
非特許文献１で開示されている主要リソース公平性もしくは資源公平性を、ユーザからのリソース要求の合計がリソース容量を超過したボトルネック状態における望ましい公平状態とする。
【００３９】
非ボトルネック状態において、非弾性リソースについては将来的にボトルネック状態になった場合に望ましい公平状態となるように帯域留保の考え方を用いて受付制御を行う。弾性リソースについてはボトルネック状態になった後に望ましい公平状態となるようにリソース再割当を行う。また、弾性リソースについてはボトルネック状態になった場合でも、ユーザあたりの割当リソース量を要求リソース量より少ないリソース量を割り当てることで、更にリソース要求を受け付けることができる。一方、余りに割当リソース量が少ないと、タスク完了時間が増大し、他のリソースの占有時間が増大するために非効率な状態となってしまう。従って弾性リソースについても割当リソース量が要求リソース量より余りに少ない状態とならないよう受付制御を行う。
【００４０】
上記受付判定に際し、リソース要求受付判定部１０２は、リソース要求予測部１０３にて計算された予備リソース量、及びリソース利用量観測部１０５にて観測されたリソース利用量、及び公平割当計算部１０４で計算された公平割当量に基づき、当該リソース要求を受け付けるか否かを判定する。
【００４１】
リソース要求のうち弾性リソースに対しては、リソース要求受付判定部１０２は、リソース利用量観測部１０５から得られた現在の全ユーザの当該リソースの利用量と、当該ユーザのリソース要求量との和が、リソース容量の予め定められた値の倍率を超えない限り受け付ける。なお、ここでの「受け付ける」とは、弾性リソースの要求に関して受付可であると判定したことを意味する。後述するように、ユーザのリソース要求を受け付けるのは、弾性リソース、非弾性リソース要求全てで受付可となった場合のみである。
【００４２】
上記の倍率は、リソース要求を発生するユーザのタスクに対して、その完了時間は、要求リソースを割り当てた場合の完了時間と比較して増大するが、その増大比で規定される。
【００４３】
例えば、該当リソースのリソース容量を１０とし、上記増大比が規定以下となる倍率が１．５であるとする。そして、現在の全ユーザの当該リソースの利用量が９、該当ユーザのリソース要求量が３であるとすると、和は１２となりリソース容量を超えるが、１５を超えないので、当該要求を受け付ける。
【００４４】
リソース要求のうち非弾性リソースに対しては、リソース要求受付判定部１０２は、当該ユーザの当該リソース利用量が公平割当量を超えていない場合は、当該ユーザの当該リソースのリソース要求量と当該リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合は要求を受け付け、当該ユーザの当該リソース利用量が公平割当量を超えている場合は、当該リソースのリソース要求量に予備リソース量を加算したものと当該リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合は要求を受け付ける。なお、ここでの「受け付ける」とは、非弾性リソースの要求に関して受付可であると判定したことを意味する。
【００４５】
リソース要求受付判定部１０２は、ユーザのリソース要求を、その要求に含まれる弾性リソース、非弾性リソース要求全てで受付可となった場合にのみ受け付ける。なお、これは例であり、ユーザのリソース要求に含まれる弾性リソースの要求、非弾性リソースの要求のいずれかで受付可となった場合に、可となったほうの要求を受け付ける（割り当てを行う）こととしてもよい。
【００４６】
上述した非弾性リソースに対する受付制御の具体例を図３を参照して説明する。図３（ａ）は、リソース１についてのユーザ１の利用量（Ａ１１）とユーザ２の利用量（Ａ１２）を示し、図３（ｂ）は、リソース２についてのユーザ１の利用量（Ａ２１）とユーザ２の利用量（Ａ２２）を示する。リソース１、リソース２の容量はそれぞれＣ１、Ｃ２である。
【００４７】
図３（ａ）、（ｂ）にはそれぞれ、ユーザ１とユーザ２の利用量の合計がリソース容量となる線（Ｄで示す）が示されている。図３（ａ）、（ｂ）における黒丸（●）は、予め算出した公平割当量である。公平割当量は、主要リソース公平の手法もしくは資産公平の手法で算出されるものである。
【００４８】
図３（ａ）、（ｂ）においてＤで示す線上の状態では、リソース利用量が公平割当量未満のユーザからのリソース要求（Ｄで示す線の外側の黒矢印で示す方向の要求）を受け付けることができない。この状態は回避すべき状態である。
【００４９】
そこで、リソース利用状況が、Ｅで示す網掛けの領域に入ったら、将来的な黒矢印の事象を防ぐために、Ｄで示す線の内側の白矢印方向の動きである、リソース利用量が公平分配以上のユーザの新たなリソース要求を拒否する受付制御を行うこととしている。Ｅで示す網掛けの領域のリソース量は、前述した予備リソース量に相当する。
【００５０】
＜リソース要求予測部１０３＞
リソース要求予測部１０３は、リソース要求受付部１０１から得た各ユーザの過去のリソース要求データから、リソース要求を自己回帰モデル等の適切な時系列モデルでモデル化し、将来のリソース要求（具体的には要求ベクトルとして得られる）を確率的に予測する。更に、予め与えられた確率Ｐに対して、リソース要求予測値の上側Ｐ％値に予め与えられた倍率Ｎを乗算した値を予備リソース量としてリソース要求受付判定部１０２に通知する。例えば、リソース要求予測値の上側Ｐ％値が１０、Ｎが１．５である場合、予備リソース量は１５になる。この手法は、予備リソース量を、各ユーザの要求リソース量（具体的には要求ベクトルとして得られる）のばらつきに基づき計算する手法の例でもある。また、予備リソース量を、非弾性リソースに対する各ユーザの要求量のばらつきに基づき計算する方法として、上記以外の方法を用いてもよい。
【００５１】
また、予備リソース量を上記リソース要求予測値に対する実測値の乖離度合いに基づき計算することとしてもよい。
【００５２】
＜公平割当計算部１０４＞
公平割当計算部１０４は、リソース要求予測部１０３から通知されたリソース要求から、主要リソース公平性に基づく公平割当量、又は、資産公平性に基づく公平割当量を計算し、計算した公平割当量をリソース要求受付判定部１０２に通知する。弾力性を持つリソースについての公平割当量はリソース割当量計算部１０６にも通知される。
【００５３】
公平割当計算部１０４は、弾力性を持たないリソースに対する公平割当量については、非特許文献１に開示された方法で計算することができる。弾力性を持つリソースに対する公平割当量については以下のとおりである。
【００５４】
公平割当計算部１０４は、弾力性を持つリソースに対する主要リソース公平性に基づく公平割当量Ａｉｊを、下記最適化問題の解として計算する。
【００５５】
【数１】
2018181123.tif 000003
ここでＣｉはリソース種別ｉ（弾力性を持つリソース）の総リソース量である。すなわち、Ｃｉは、弾性リソースに対する要求量のユーザ合計（リソース容量を超えたもの）である。Ａｉｊはリソース種別ｉのユーザｊへの割当リソース量であり、Ｎは総ユーザ数であり、εは予め定められた小数である。ｃｉはリソース種別ｉの単位リソース量であり、ｄｉｊはリソース種別ｉのユーザｊへの割当リソース数である。
【００５６】
Ｓｕｂｊｅｃｔ  ｔｏにおける式は全てのユーザｊに対して成立するという制約条件である。式２の左辺における第１項は、ユーザｊについての（Ａｉｊ／Ｃｉ）が最大となるリソースにおける（Ａｉｊ／Ｃｉ）の値を示し、第２項は、各ユーザについての（Ａｉｊ／Ｃｉ）が最大となるリソースにおける（Ａｉｊ／Ｃｉ）の値の総ユーザの和をＮで割った値を示す。
【００５７】
上記の計算は、式２の条件の下、Ａｉｊの総ユーザ及び総リソースの和を最大にするＡｉｊを求める計算である。
【００５８】
また、公平割当計算部１０４は、弾力性を持つリソースに対する資産公平性に基づく公平割当量Ａｉｊを、下記最適化問題の解として計算する。
【００５９】
【数２】
2018181123.tif 000004
ここでＣｉはリソース種別ｉ（弾力性を持つリソース）の総リソース量であり、Ａｉｊはリソース種別ｉのユーザｊへの割当リソース量である。Ｎは総ユーザ数であり、εは予め定められた小数である。
【００６０】
Ｓｕｂｊｅｃｔ  ｔｏにおける式は全てのユーザｊに対して成立するという制約条件である。式５の左辺における第１項は、（Ａｉｊ／Ｃｉ）の総リソースの和であり、第２項は、（Ａｉｊ／Ｃｉ）の総ユーザ及び総リソースの和をＮで割った値を示す。
【００６１】
上記の計算は、式５の条件の下、Ａｉｊの総ユーザ及び総リソースの和を最大にするＡｉｊを求める計算である。
【００６２】
＜リソース割当量計算部１０６＞
リソース割当量計算部１０６は、弾力性を持つリソースに対して、当該リソースの利用量がリソース容量に達した場合に、公平割当計算部１０４から通知された公平割当量に基づきリソース割当（再割当）を行う。弾力性を持たないリソースに対しては、ユーザの要求通りにリソース割当を行う。「リソース割当を行う」とは、例えば、リソース割当量計算部１０６が、ユーザに対する割当リソース毎の割当量を制御対象リソース群２００に通知し、制御対象リソース群２００に対し、当該割当量のリソースを当該ユーザに対して確保させることである。
【００６３】
以上説明した本実施の形態に係る技術により、複数リソース種別が存在する場合にリソースへの需要タイプ、需要割合を鑑みて、動的に要求が発生する状況化における、公平性かつ利用効率性を満たすリソース割当が期待できる。
【００６４】
（実施の形態のまとめ）
以上、説明したように、本実施の形態により、複数リソースを複数ユーザで共有する環境において、ユーザのリソース要求に対するリソース割当制御を行うリソース割当制御システムであって、あるユーザからのリソース要求を受信するリソース要求受付手段と、前記リソース要求を受け付けるか否かを判定するリソース要求受付判定手段と、を備え、前記リソース要求受付判定手段は、前記リソース要求における要求リソースのうち、弾力性を持つリソースである弾性リソースに対しては、当該弾性リソースのリソース要求量と当該弾性リソースの全ユーザのリソース利用量合計との和が、リソース容量に基づき予め与えられた閾値を超過しなければ、当該弾性リソースに関する要求を受付可と判定し、前記要求リソースのうち、弾力性を持たないリソースである非弾性リソースに対しては、公平割当量に基づき、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない範囲で当該非弾性リソースに関する要求を受付可と判定することを特徴とするリソース割当制御システムが提供される。
【００６５】
リソース要求受付部１０１はリソース要求受付手段の例であり、リソース要求受付判定部１０２はリソース要求受付判定手段の例である。
【００６６】
前記リソース要求受付判定手段は、例えば、前記要求リソースのうちの前記非弾性リソースに対し、前記ユーザの前記非弾性リソースのリソース利用量が公平割当量を超えていない場合は、当該非弾性リソースのリソース要求量と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合に要求を受付可と判定し、当該ユーザの当該リソース利用量が公平割当量を超えている場合は、当該非弾性リソースのリソース要求量に予備リソース量を加算した値と当該非弾性リソースの全ユーザのリソース利用量合計との和がリソース容量を超えない場合に要求を受付可と判定する。
【００６７】
前記リソース割当制御システムは、前記予備リソース量を、前記非弾性リソースに対する各ユーザの要求量のばらつきに基づき計算する計算手段を備えてもよい。また、前記リソース割当制御システムは、ユーザ毎の各リソースに対する要求量を、ユーザの過去のリソース要求データから生成した時系列モデルに基づき確率的に予測した予測値を求め、前記予備リソース量を当該予測値に対する実測値の乖離度合いに基づき計算する計算手段を備えてもよい。なお、リソース要求予測部１０３は、計算手段の例である。
【００６８】
また、前記リソース割当制御システムは、前記弾性リソースに対し、当該弾性リソースのリソース要求量のユーザ合計がリソース容量を超える場合において、公平割当量となるように再割当の計算を行い、当該計算により得られた量のリソースを前記ユーザに割り当て、前記非弾性リソースに対しては、前記ユーザの要求通りにリソースを割り当てる割当手段を更に備えてもよい。なお、公平割当計算部１０４及びリソース割当量計算部１０６は、割当手段の例である。
【００６９】
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００７０】
１００  リソース割当制御システム
２００  制御対象リソース群
１０１  リソース要求受付部
１０２  リソース要求受付判定部
１０３  リソース要求予測部
１０４  公平割当計算部
１０５  リソース利用量観測部
１０６  リソース割当量計算部
３００  ドライブ装置
３０１  記録媒体
３０２  補助記憶装置
３０３  メモリ装置
３０４  ＣＰＵ
３０５  インタフェース装置
３０６  表示装置
３０７  出力装置
【図１】
2018181123.tif 000005
【図２】
2018181123.tif 000006
【図３】
2018181123.tif 000007