(57)【要約】【課題】リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の再設定を行う。【解決手段】リソース共有システム１０は、複数のユーザ２０（ユーザ端末）でリソース３０を共有する。リソース予約管理装置４２は、ユーザ２０からリソース３０の予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に利用予約を設定する予約設定部４０２と、予約を設定したリソース３０が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定する予約変更部４０４とを備える。予約変更部４０４は、再設定すべき利用予約に対して他のリソース３０のリソース量が不足する場合、再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、他のリソース３０に利用予約を再設定する。【選択図】図６
2019211890.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、
前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定部と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、
前記予約変更部は、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理装置。
【請求項２】
前記予約要求は、当該利用予約の優先度を示す情報を含んでおり、
前記予約変更ポリシーは、前記優先度が高い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項３】
前記予約要求は、前記リソースを利用する日時を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソースの利用開始日時が早い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項４】
前記予約要求は、利用する前記リソースのリソース量を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソース量が少ない前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項５】
前記予約要求は、前記リソースを利用する期間を示す情報を含んでおり、
前記予約変更ポリシーは、前記リソースの利用期間が短い前記利用予約を優先して再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項６】
前記予約要求は、前記リソースを利用する日時を示す情報、利用する前記リソースのリソース量を示す情報、前記リソースを利用する期間を示す情報のうち、少なくとも２つの情報を含んでおり、
前記予約変更ポリシーは、前記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて優先して再設定する前記利用予約を決定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項７】
前記予約変更ポリシーは、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用予約を再設定する規定である、
ことを特徴とする請求項１に記載のリソース予約管理装置。
【請求項８】
複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、
前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定工程と、
前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、
前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、
ことを特徴とするリソース予約管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のユーザでリソースを共有するリソース共有システムにおけるリソース予約管理装置およびリソース予約管理方法に関する。
【背景技術】
【０００２】
従来、IaaS（Infrastructure as a Service）のようなクラウドサービスにおいて、複数のユーザ（サービスやアプリケーション等）でリソース（コンピュート、ネットワーク、ストレージ等）を共有し、各ユーザが必要な時に必要な分だけリソースを利用するモデルが普及している。
一方で、共有リソースは有限であるため、ユーザが確実にリソースを利用できるように、リソースの予約を可能とする提案もなされている（例えば、非特許文献１および非特許文献２参照）。特に、リソースが限られる小規模プライベートクラウドサービスでは、予約の重要性がより大きくなる。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“Blazar, the OpenStack Reservation Service”［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://docs.openstack.org/blazar/latest/>
【非特許文献２】“Amazon EC2 リザーブドインスタンス”［online］、［平成３０年５月１４日検索］、インターネット<ＵＲＬ：https://aws.amazon.com/jp/ec2/pricing/reserved-instances/>
【非特許文献３】Weijia Song, et. al, “Adaptive Resource Provisioning for the Cloud Using Online Bin Packing”, IEEE Transactions on Computers, Volume: 63, Issue: 11, Nov. 2014
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述したようなリソース共有システムにおいて、予約済みのリソースが故障した場合には、空きのある他のリソース（代替リソース）に当該予約を振り替えることで、ユーザへの影響を解消ないし低減することができる。
しかしながら、システム内の空きリソースが足りない場合、一部の予約が不成立（予約したのにリソースを使えない状況）になる可能性があるという課題がある。
【０００５】
本発明は、このような事情に鑑みなされたものであり、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことを目的とする。
【課題を解決するための手段】
【０００６】
上述の目的を達成するため、請求項１に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理装置であって、前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定部と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更部と、を備え、前記予約変更部は、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理装置とした。
【０００７】
また、請求項８に記載の発明は、複数のユーザ端末でリソースを共有するリソース共有システムにおけるリソース予約管理方法であって、前記ユーザ端末から前記リソースの予約要求を受け付け、前記リソース共有システム内の所定のリソースに利用予約を設定する予約設定工程と、前記所定のリソースが利用不可となった場合に、前記リソース共有システム内の他のリソースに前記利用予約を再設定する予約変更工程と、を含み、前記予約変更工程では、再設定すべき利用予約に対して前記他のリソースのリソース量が不足する場合、前記再設定すべき利用予約のうちいずれの利用予約を優先して再設定するかを規定する予約変更ポリシーに基づいて、前記他のリソースに前記利用予約を再設定する、ことを特徴とするリソース予約管理方法とした。
【０００８】
このようにすることで、所定のリソースが利用不可となり、かつ再設定すべき利用予約に対して他のリソースのリソース量が不足する場合に、優先的に再設定する予約を一意に決定し、システムの効率を向上させることができる。
【０００９】
また、請求項２に記載の発明は、前記予約要求が、当該利用予約の優先度を示す情報を含んでおり、前記予約変更ポリシーが、前記優先度が高い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１０】
このようにすることで、利用予約の再設定順序にユーザの意思を反映することができ、ユーザの利便性を向上させることができる。
【００１１】
また、請求項３に記載の発明は、前記予約要求が、前記リソースを利用する日時を示す情報を含んでおり、前記予約変更ポリシーが、前記リソースの利用開始日時が早い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１２】
このようにすることで、利用不可となったリソースが復旧するまでに開始される可能性が高い予約を優先して再設定することができ、予約不成立となる予約数を低減することができる。
【００１３】
また、請求項４に記載の発明は、前記予約要求が、利用する前記リソースのリソース量を示す情報を含んでおり、前記予約変更ポリシーが、前記リソース量が少ない前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１４】
このようにすることで、限りある空きリソースにより多くの予約を設定することができ、不成立となる予約の数を低減することができる。
【００１５】
また、請求項５に記載の発明は、前記予約要求が、前記リソースを利用する期間を示す情報を含んでおり、前記予約変更ポリシーが、前記リソースの利用期間が短い前記利用予約を優先して再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１６】
このようにすることで、限りある空きリソースにより多くの予約を設定することができ、不成立となる予約の数を低減することができる。
【００１７】
また、請求項６に記載の発明は、前記予約要求が、前記リソースを利用する日時を示す情報、利用する前記リソースのリソース量を示す情報、前記リソースを利用する期間を示す情報のうち、少なくとも２つの情報を含んでおり、前記予約変更ポリシーが、前記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて優先して再設定する前記利用予約を決定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００１８】
このようにすることで、優先して再設定する予約を決定する際に複数の要因を反映することができる。
【００１９】
また、請求項７に記載の発明は、前記予約変更ポリシーが、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な前記利用予約の数が最大となるように前記利用予約を再設定する規定である、ことを特徴とする請求項１に記載のリソース予約管理装置とした。
【００２０】
このようにすることで、リソース共有システム全体で実行可能な予約を最大化することができ、より効率的に予約を設定することができる。
【発明の効果】
【００２１】
本発明によれば、リソース共有システムで予約済みのリソースが利用不可となった場合に、効率的に予約の振り替えを行うことができる。
【図面の簡単な説明】
【００２２】
【図１】本実施形態に係るリソース共有システムの構成例を示す図である。
【図２】本実施形態に係るリソース予約管理装置の機能的構成を示すブロック図である。
【図３】リソースの予約要求の一例を模式的に示す説明図である。
【図４】リソースの予約テーブルを模式的に示す説明図である。
【図５】リソースの予約テーブルを模式的に示す説明図である。
【図６】本実施形態に係るリソース予約管理装置による予約受付処理の手順を示すフローチャートである。
【図７】ポリシー１を適用した場合の予約再設定順序を示す説明図である。
【図８】ポリシー２を適用した場合の予約再設定順序を示す説明図である。
【図９】ポリシー３を適用した場合の予約再設定順序を示す説明図である。
【図１０】ポリシー４を適用した場合の予約再設定順序を示す説明図である。
【発明を実施するための形態】
【００２３】
以下に添付図面を参照して、本発明に係るリソース予約管理装置４２およびリソース予約管理方法の好適な実施の形態（以下、「実施形態」と称する。）を詳細に説明する。
図１は、本実施態に係るリソース共有システム１０の構成例を示す図である。
【００２４】
リソース共有システム１０は、複数のユーザ２０で複数のリソース３０を共有するためのシステムである。
それぞれのユーザ２０は、例えば、リソース共有を実現するためのアプリケーションが格納されたユーザ端末（図示省略）である。リソース３０は、例えばベアメタル、仮想マシン、コンテナ、各種ストレージ等である。各リソース３０は、共通ネットワーク３２に接続されており、例えばＯｐｅｎＳｔａｃｋのようなクラウドオペレーティングシステム３４により管理されている。
【００２５】
クラウドオペレーティングシステム３４は、システム管理装置４０上のダッシュボードを通じて管理され、管理者がＷＥＢインターフェイスを通じてリソース３０をプロビジョニングできるように構成されている。また、システム管理装置４０は、リソース共有システム１０のモニタリングやツールの提供を行う。
ここで、リソース共有システム１０では、Ｂｌａｚａｒのようなサービスを用いてユーザ２０によるリソース３０の予約が可能である。本実施形態では、システム管理装置４０は、リソース３０の予約を管理するリソース予約管理装置４２として機能する。
【００２６】
図２は、本実施形態に係るリソース予約管理装置４２の機能的構成を示すブロック図である。
リソース予約管理装置４２は、制御手段、記憶手段および入出力手段（いずれも図示省略）を備えるコンピュータ等により実現される。そして、制御手段は、予約設定部４０２と、予約変更部４０４とを備える。
【００２７】
予約設定部４０２は、ユーザ２０からリソース３０の予約要求を受け付け、リソース共有システム１０内の所定のリソース３０に利用予約を設定する。ユーザ２０からの利用要求には、図３に示すようなリソース３０の利用条件が含まれており、予約設定部４０２は、所定のリソース３０に対して利用条件に沿った利用予約を設定する。なお、予約設定部４０２は、後述する予約変更部４０４により利用予約の再設定が行われている間は、新規の予約要求の受け付けを停止する。
【００２８】
予約変更部４０４は、所定のリソース３０（利用予約が設定されたリソース３０）が利用不可となった場合に、リソース共有システム１０内の他のリソース３０に利用予約を再設定する。リソース３０が利用不可となる場合とは、例えばリソース３０が故障した場合やリソース３０とユーザ２０との間のネットワークに障害が生じた場合などである。以下、利用不可となったリソース３０に設定されていた予約を「変更対象予約」という。
【００２９】
図３は、リソース３０の予約要求の一例を模式的に示す説明図である。
ユーザ２０からの予約要求には、例えば当該予約を識別する予約識別子（図３の例では「プロジェクトＡ」）、リソース３０を利用する日時（図３の例では「２０１８／０２／１０／０：００〜２０１８／０２／１２／２３：５９」）、リソース３０を利用する期間（図３の例では「７２時間」）、利用するリソース３０の種類および容量（図３の例では「４コア、８ＧＢ  ＲＡＭ、１００ＧＢ  ｄｉｓｋのデバイス４台」）などが含まれている。
【００３０】
予約要求を受けた予約設定部４０２は、リソース共有システム１０内のリソース３０に、利用条件に沿った利用予約を設定する。各リソース３０の予約状態は、図４に示すような予約テーブルで管理され、予約テーブルに沿って、ユーザ２０にリソース３０の利用権が与えられる。
【００３１】
図４は、リソース３０の予約テーブルを模式的に示す説明図である。
図４では、リソース３０の一例として４台のホストマシン（ホスト１〜ホスト４）を示している。
例えばホスト２は、日曜日はフリー（空き状態）であり、月曜日から火曜日にかけてはプロジェクトＡ、水曜日から木曜日にかけてはプロジェクトＢ、金曜日から土曜日にかけてはプロジェクトＤにより予約されている。
また、リソース量が足りるのであれば、１つのリソース３０を複数のユーザ２０が同時に予約することも可能である。例えばホスト１は、日曜日から火曜日にかけてプロジェクトＡおよびプロジェクトＢにより予約されている。すなわち、１つのリソース３０を部分的に予約することも可能である。
【００３２】
ここで、図４のような予約状態である時にホスト１とホスト２が故障して利用不可となった場合、ホスト１とホスト２に設定されている利用予約、すなわち図５で太実線に囲まれた予約が変更対象予約となる。この場合、予約変更部４０４は、基本的には故障していない他のリソース３０（ホスト３およびホスト４）に予約を再設定（振り替え）する。
例えば図示の例では、図５で太点線に囲まれた領域、すなわちホスト４は全時間帯が、ホスト３は日曜日が、それぞれフリー（空き状態）であるため、予約変更部４０４は、これら空きのあるリソース３０へと変更対象予約を割り振る。しかしながら、ホスト１〜ホスト４のスペックが同等の場合、月曜日以降は空きのあるリソース３０が変更対象予約の実行に必要なリソース量の半分となり、全ての変更対象予約を再設定することはできない。
【００３３】
このように、再設定すべき利用予約に対して故障していないリソース３０（他のリソース３０）のリソース量が不足する場合、予約変更部４０４は、リソース共有システム１０の管理者によって設定された予約変更ポリシーに基づいて他のリソース３０に利用予約を再設定する。
予約変更ポリシーとは、変更対象予約の全てを他のリソース３０に再設定することが不可能な場合に、いずれの利用予約を優先して再設定するかを規定するポリシーである。
予約変更ポリシーに基づいて利用予約を再設定することにより、限られたリソース３０をより効率的に利用することができ、予約済みのリソース３０が利用不可となったことによるユーザ２０への影響を最小限にすることができる。
【００３４】
以下、より詳細に予約変更部４０４による予約変更処理ついて説明するが、これに先立って、リソース予約管理装置４２による予約受付処理について説明する。
図６は、リソース予約管理装置４２による予約受付処理の手順を示すフローチャートである。
【００３５】
予約に先立って、リソース予約管理装置４２の予約変更部４０４は、リソース共有システム１０の管理者から予約変更ポリシーの設定を受け付けておく（ステップＳ１００）。なお、予約変更ポリシーの設定内容は、任意のタイミングで変更可能である。
【００３６】
そして、リソース予約管理装置４２の予約設定部４０２は、ユーザ２０（ユーザ端末）から予約要求を受信したか否かを判定する（ステップＳ１０２）。そして、受信した場合（ステップＳ１０２：Ｙｅｓ）、予約設定部４０２は、所定のリソース（ユーザ２０が指定した種類のリソース３０）に利用予約を設定する（ステップＳ１０４）。一方、予約設定部４０２は、予約要求を受信していない場合には（ステップＳ１０２：Ｎｏ）、受信するまで待つ。
【００３７】
予約設定部４０２は、利用予約を設定したリソース３０に故障等が発生せず、利用可能な場合は（ステップＳ１０６：Ｙｅｓ）、ステップＳ１０２に戻り、利用予約の受付を継続する。なお、図示は省略しているが、利用予約に設定された利用日時となった場合、リソース予約管理装置４２は適宜ユーザ２０にリソース３０の利用権を与える（予約の実行）。
【００３８】
一方、利用予約を設定したリソース３０に故障等が発生し、利用不可となった場合（ステップＳ１０６：Ｎｏ）、予約設定部４０２は、新規の予約要求の受付を停止する（ステップＳ１０８）。
これは、新規予約の受付よりも、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の再設定（振り替え）を優先させるためである。このようにすることで、新規の予約により元々設定されていた利用予約の振り替えが不成立となることを防止することができる。
【００３９】
また、予約変更部４０４は、利用可能なリソース３０（他のリソース３０）の空き状況の情報を取得し（ステップＳ１１０）、利用不可となったリソース３０に入っていた利用予約（変更対象予約）の全てを他のリソース３０に振り替え可能か否かを判断する（ステップＳ１１２）。
【００４０】
リソース３０に空きが十分ある場合など、全ての変更対象予約を他のリソース３０に振り替え可能な場合（ステップＳ１１２：Ｙｅｓ）、予約変更部４０４は、全ての変更対象予約を他のリソース３０に振り替える（ステップＳ１１４）。
【００４１】
一方、リソース３０に空きが少ない場合など、全ての変更対象予約の振り替えが不可能な場合は（ステップＳ１１２：Ｎｏ）、ステップＳ１００で設定された予約変更ポリシーに基づいて優先度の高い利用予約から順に他のリソース３０に再設定する（ステップＳ１１６）。この結果、優先度の低い利用予約は予約不成立となる可能性がある。
【００４２】
利用予約の振り替えまたは再設定が完了すると、予約設定部４０２は新規の予約要求の受付を再開し（ステップＳ１１８）、ステップＳ１０２に戻り以降の処理を繰り返す。なお、予約受付再開後は、利用可能なリソース３０にのみ利用予約を割り振る。
【００４３】
つぎに、予約変更ポリシーに基づく利用予約の再設定（図６のステップＳ１１６）の詳細について説明する。
本実施形態では、予約変更ポリシーとして以下の６つの基準を例示する。
図６のステップＳ１００では、下記ポリシー１〜６のいずれを採用するかをリソース共有システム１０の管理者が決定し、リソース予約管理装置４２の予約変更部４０４がそれを受け付けて設定しておく。
【００４４】
ポリシー１：ユーザ指定優先度ベース
ポリシー２：先発優先
ポリシー３：小容量優先
ポリシー４：短時間優先
ポリシー５：混合型
ポリシー６：実行予約数最大化
以下、各ポリシーの詳細について説明する。
【００４５】
＜ポリシー１：ユーザ指定優先度ベース＞
ポリシー１では、予約要求時にユーザ２０が当該予約の優先度を指定する。そして、予約再設定時には、優先度が高い予約から順に（優先的に）再設定する。
すなわち、ユーザ２０からの予約要求は当該利用予約の優先度を示す情報を含んでおり、予約変更ポリシー（ポリシー１）は、優先度が高い利用予約を優先して他のリソース３０に再設定すると規定する。
このようにすることで、利用予約の再設定順序にユーザの意思を反映することができ、ユーザの利便性を向上させることができる。
【００４６】
ポリシー１を採用した場合、優先度が低い予約は予約不成立となる可能性が高くなる。
これに伴い、各予約の優先度に偏りが生じる（例えば全ての予約が優先度の最大値に設定されるなど）のを防ぐため、例えばプロジェクトやユーザ２０ごとに優先度の制限をかけたり、全体の優先度要求状況を考慮して各ユーザ２０からの優先度要求の優先度を正規化するなどしてもよい。
【００４７】
図７は、ポリシー１を適用した場合の予約再設定順序を示す説明図である。
図７には、４つの予約（予約１〜予約４）の内容を例示しており、左から順に予約識別子、利用日時、利用期間、利用リソースおよびユーザ２０により設定された優先度を示している。図７では利用日時および利用期間を日単位で示している。
【００４８】
図７の例では、優先度の値が大きい順に優先度が高くなっており、優先度１０の予約１、優先度８の予約３、優先度５の予約４、優先度１の予約２の順に（優先して）他のリソース３０へと再設定する。既に予約が入っているリソース３０には予約が設定できないため、優先度が低い予約ほど予約が不成立となる可能性が高くなる。
【００４９】
＜ポリシー２：先発優先＞
ポリシー２では、利用開始日時が早い予約（先発予約）から順に再設定する。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報を含んでおり、予約変更ポリシー（ポリシー２）は、リソース３０の利用開始日時が早い利用予約を優先して再設定すると規定する。
これは、利用不可となったリソース３０はいずれ復旧されるため、喫緊に影響を受ける予約を優先的に復旧するものである。つまり、利用不可となったリソース３０が復旧するまでに開始される可能性が高い予約を優先して再設定することができ、予約不成立となる予約数を低減することができる。
【００５０】
図８は、ポリシー２を適用した場合の予約再設定順序を示す説明図である。
図８に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図８の例では、利用開始日時が２０１８／０２／１０の予約３、２０１８／０３／１２の予約１、２０１８／０４／０１の予約２、２０１８／０４／０２の予約４の順に（優先して）他のリソース３０へと再設定する。
利用開始日時が遅い予約は当初は予約不成立となる可能性が高くなるが、利用開始日時までにリソース３０が復旧すれば予約の再設定が可能となる。
【００５１】
＜ポリシー３：小容量優先＞
ポリシー３では、利用リソース量の小さい予約から順に再設定する。
すなわち、ユーザ２０からの予約要求は、利用するリソース３０のリソース量を示す情報を含んでおり、予約変更ポリシー（ポリシー３）は、リソース量が少ない利用予約を優先して再設定すると規定する。
これは、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
【００５２】
図９は、ポリシー３を適用した場合の予約再設定順序を示す説明図である。
図９に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図９の例では、予約リソース量が（１コア、２ＧＢ  ＲＡＭ、５ＧＢ  ｄｉｓｋ）×１台の予約４、（２コア、４ＧＢ  ＲＡＭ、１０ＧＢ  ｄｉｓｋ）×３台の予約１、（４コア、８ＧＢ  ＲＡＭ、１００ＧＢ  ｄｉｓｋ）×４台の予約３、（８コア、１６ＧＢ  ＲＡＭ、１００ＧＢ  ｄｉｓｋ）×４台の予約２の順に（優先して）他のリソース３０へと再設定する。
利用リソース量が大きい予約では１つの予約でリソース３０を消費してしまう場合でも、利用リソース量が小さい予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
【００５３】
＜ポリシー４：短時間優先＞
ポリシー４では、利用期間の短い予約から順に予約再設定を行う。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する期間を示す情報を含んでおり、予約変更ポリシー（ポリシー４）は、リソース３０の利用期間が短い利用予約を優先して再設定すると規定する。
これは、ポリシー３同様、再設定可能な予約数をなるべく多くし、不成立となる予約の数を低減させるためである。
【００５４】
図１０は、ポリシー４を適用した場合の予約再設定順序を示す説明図である。
図１０に示す４つの予約（予約１〜予約４）の内容は図７と同様である。
図１０の例では、利用期間が３日間の予約２、６日間の予約３、１６日間の予約１、２９日間の予約４の順に優先して他のリソース３０へと再設定する。
利用期間が長い予約では１つの予約でリソース３０を消費してしまう場合でも、利用期間が短い予約を割り当てれば複数の予約を割り当て可能となる可能性が高くなる。
【００５５】
＜ポリシー５：混合型＞
ポリシー５では、上記ポリシー２〜４の各指標、すなわち利用開始日時（先発優先）、利用リソース量（小容量優先）、利用期間（短時間優先）にそれぞれ重みづけを行って積算したスコアＳを計算し、スコアＳの高いものから順に予約再設定する。
このようにすることで、優先して再設定する予約を決定する際に複数の要因を反映することができる。なお、先発優先（ポリシー２）で設定される優先順序を「先発優先度」とし、小容量優先（ポリシー３）で設定される優先順序を「容量優先度」とし、短時間優先（ポリシー４）で設定される優先順序を「期間優先度」とする。
【００５６】
スコアＳは、例えば下記（式１）のように算出する。
スコアＳ  ＝  先発優先度×ｗ１＋容量優先度×ｗ２＋期間優先度×ｗ３・・（式１）
（ｗ１，ｗ２，ｗ３：  各指標の重み）
【００５７】
なお、先発優先度、容量優先度、期間優先度の３つの指標を用いるのではなく、上記３つの指標のうち任意の２つの指標を用いてスコアを算出してもよい。
すなわち、ユーザ２０からの予約要求は、リソース３０を利用する日時を示す情報、利用するリソース３０のリソース量を示す情報、リソース３０を利用する期間を示す情報のうち、少なくとも２つの情報（指標）を含んでおり、予約変更ポリシー（ポリシー５）は、上記少なくとも２つの情報に対してそれぞれ重み付けを行ってスコア化し、スコアの大小に基づいて（優先して）再設定する利用予約を決定すると規定する。
【００５８】
＜ポリシー６：実行可能予約数最大化＞
ポリシー６では、例えばＢｉｎ  ｐａｃｋｉｎｇのような全体最適化アルゴリズム（非特許文献３参照）を利用し、予約変更に失敗する予約数が最小となるような順番で予約を再設定する。
すなわち、予約変更ポリシー（ポリシー６）は、Ｂｉｎ  Ｐａｃｋｉｎｇ問題を解決するアルゴリズムを用いて、実行可能な利用予約の数が最大となるように利用予約を再設定すると規定する。
このようにすることで、リソース共有システム１０全体で実行可能な予約を最大化することができ、より効率的に予約を設定することができる。
【００５９】
なお、本実施形態において、再設定の対象となる予約は以下の２パターンが考えられる。
＜パターン１＞
利用不可となったリソース３０に設定されている予約（変更対象予約）
パターン１の場合、利用不可となったリソース３０に設定されていた利用予約のみが再設定（振り替え）対象となり、障害等が発生していない利用可能なリソース３０に入っていた予約は影響を受けない。
＜パターン２＞
全てリソース３０に設定されている予約（変更対象予約＋利用可能なリソース３０に設定されている予約）
パターン２の場合、全ての利用予約が再設定対象となり、利用可能なリソース３０に設定されている予約も影響（予約不成立など）を受ける可能性がある。
【００６０】
例えばポリシー１は、予約要求時に指定された優先度が高い予約を優先して再設定するが、パターン１を採用した場合には、障害が発生していないリソース３０では当初の予約通りに優先度が低い予約が実行され、障害が発生したリソース３０に予約されていた比較的優先度が高い予約が実行できない、という事象が発生する可能性がある。
これに対して、パターン２を採用した場合には、障害が発生していないリソース３０に元々設定されていた予約を含めて、全ての予約について優先度が高い順に再設定されるため、より確実に優先度が高い予約を実行することができる。
すなわち、パターン２を用いることでシステム全体の予約を最適化することができる。
一方で、パターン１は変更対象予約のみが再設定対象であるため、リソース予約管理装置４２の処理負荷を軽減することができ、リソース３０の障害発生時により迅速に対応することができる。
【００６１】
以上説明したように、本実施形態に係るリソース共有システム１０のリソース予約管理装置４２によれば、所定のリソース３０が利用不可となり、かつ再設定すべき利用予約に対して空きのある他のリソース３０のリソース量が不足する場合に、優先的に再設定する予約を一意に決定し、システムの効率を向上させることができる。
【符号の説明】
【００６２】
１０  リソース共有システム
２０  ユーザ（ユーザ端末）
３０  リソース
３２  共通ネットワーク
３４  クラウドオペレーティングシステム
４０  システム管理装置
４２  リソース予約管理装置
４０２  予約設定部
４０４  予約変更部
【図１】
2019211890.tif 000003
【図２】
2019211890.tif 000004
【図３】
2019211890.tif 000005
【図４】
2019211890.tif 000006
【図５】
2019211890.tif 000007
【図６】
2019211890.tif 000008
【図７】
2019211890.tif 000009
【図８】
2019211890.tif 000010
【図９】
2019211890.tif 000011
【図１０】
2019211890.tif 000012