JP5421305B2

JP5421305B2 - 割当決定装置、割当決定方法、割当システム及び割当決定プログラム

Info

Publication number: JP5421305B2
Application number: JP2011033707A
Authority: JP
Inventors: 博胡; 邦夫波戸; 純一村山; 祐一村田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2011-02-18
Filing date: 2011-02-18
Publication date: 2014-02-19
Anticipated expiration: 2031-02-18
Also published as: JP2012173869A

Description

本発明は、割当決定装置、割当決定方法、割当システム及び割当決定プログラムに関する。

ネットワークのリソースやサーバのリソースなどを提供するクラウドシステムがある。クラウドシステムは複数あり、各クラウドシステムが独自にリソースを提供する。クラウドシステムにより提供されるリソースを利用するユーザは、例えば、ユーザ自身が管理していたサーバを、クラウドシステムにより提供されるサーバに移行することで、サーバの管理負担を軽くする。

ここで、ユーザは、異なる種類のリソースを組み合わせて利用することがある。例えば、ユーザは、クラウドシステム「Ａ」により提供されるネットワークのリソースと、クラウドシステム「Ｂ」により提供されるサーバのリソースとを組み合わせて利用することがある。

小川琢也、得永真吾他著「仮想マシン群の効率的な配置に関する一検討」社団法人電子情報通信学会信学技報 ICM2009-30（2009-11） Ruben Van den Bossche、 Kurt Vanmechelen and Jan Broeckhove著「Cost-Optimal Scheduling in Hybrid IaaS Clouds for Deadline Constrained」 2010 IEEE 3rd International Conference on Cloud Computing,（米国）, IEEE Computer Society, p.228-p.235 Hui Zhang.、 Guofei Jiang.、 Kenji Yoshihira.、 Haifeng Chen. and Akhilesh Saxena.著「Intelligent Workload Factoring for A Hybrid Cloud Computing Model」 2009 Congress on Services−I,（米国）,IEEE Computer Society, p.701-p.708

しかしながら、上述の手法では、異なる種類のリソースを組み合わせるのに手間がかかるという課題がある。例えば、上述の手法では、異なる種類のリソースをどのように組み合わせるかをユーザが決定することになると考えられ、手間がかかる。

開示の技術は、上述に鑑みてなされたものであって、異なる種類のリソースを適切に組み合わせ可能である割当決定装置、割当決定方法、割当システム及び割当決定プログラムを提供することを目的とする。

開示する割当決定装置は、１つの態様において、異なる管理装置により提供される複数種類のリソースのうち異なる種類の前記リソースと併せて用いられる前記リソースの割り当てを要求する割当要求の入力を受け付ける受付部を備える。また、割当決定装置は、複数ある前記リソース各々のうち、前記受付部により受け付けられた前記割当要求により要求されるリソースの種類に属する第１のリソースを選択し、選択した該第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースとの組み合わせを生成する生成部を備える。また、割当決定装置は、前記生成部により生成された組み合わせについて、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが組み合わせ可能なリソースであるか否かを判定する判定部を備える。また、割当決定装置は、前記判定部により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する選択部を備える。また、割当決定装置は、前記選択部により選択された組み合わせを出力する出力部を備える。

開示する割当決定装置の１つの態様によれば、異なる種類のリソースを適切に組み合わせ可能であるという効果を奏する。

図１は、実施例１に係る割当決定装置の構成の一例を示すブロック図である。図２は、実施例１に係る割当決定装置の実施形態の一例を示す図である。図３は、実施例１における制約条件テーブルに記憶された情報の一例を示す図である。図４は、実施例１におけるリソース情報テーブルに記憶された情報の一例を示す図である。図５は、実施例１に係る割当決定装置による処理の流れの一例を示すフローチャートである。図６は、実施例２におけるインタークラウドサーバの全体像について示す図である。図７は、実施例２におけるＡＳＰ運用者に新規にリソースを割り当てられる新設時における動作概要を示す図である。図８は、実施例２におけるＡＳＰ運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要を示す図である。図９は、実施例２におけるＡＳＰ運用者に割り当てられたリソースを開放する廃止時における動作概要を示す図である。図１０は、実施例２におけるインタークラウドサーバのユースケースの一例を示す図である。図１１は、実施例２における新設時における処理の流れの一例を示すシーケンス図である。図１２は、実施例２における増設・減設時における処理の流れの一例を示すシーケンス図である。図１３は、実施例２における廃止時における処理の流れの一例を示すシーケンス図である。図１４は、実施例２におけるＤＣ−ＯＰＳについての管理情報の一例を示す図である。図１５は、実施例２におけるＮＷ−ＯＰＳについての管理情報の一例を示す図である。図１６は、実施例２における制約条件ＤＢに記憶された制約条件の一例を示す図である。図１７は、実施例２におけるＤＣについての利用状況情報の一例を示す図である。図１８は、実施例２におけるＤＣについての空きリソース情報の一例を示す図である。図１９は、実施例２におけるＤＣリソース情報の一例を示す図である。図２０は、実施例２におけるＤＣについてのリソース割当の一例を示す図である。図２１は、実施例２におけるＮＷについての利用状況情報の一例を示す図である。図２２は、実施例２におけるＮＷについての空きリソース情報の一例を示す図である。図２３は、実施例２におけるＮＷリソース情報の一例を示す図である。図２４は、実施例２におけるＮＷについてのリソース割当の一例を示す図である。図２５−１は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２５−２は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２５−３は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２５−４は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２５−５は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２６は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示すフローチャートである。図２７は、実施例２におけるユーザのＤＣ制約条件によるＤＣ選択処理の流れの一例を示すフローチャートである。図２８は、図２７に示される一連の処理について説明する図である。図２９は、実施例２におけるユーザのＮＷ制約条件によるＤＣ選択処理の流れの一例を示すフローチャートである。図３０は、図２９に示される一連の処理により出力されるＮＷ条件による制約ＤＣリストの一例を示す図である。図３１は、実施例２における利用者条件を満たせるＮＷをＤＣ別ＮＷ制約リストにピックアップする処理の流れの一例を示すフローチャートである。図３２は、実施例２におけるリソース種類別のＤＣ判定の流れの例を示すフローチャートである。図３３は、実施例２におけるリソース種類別のＤＣ判定について説明する図である。図３４は、実施例２におけるデータセンタプラン作成の流れの一例を示すフローチャートである。図３５は、実施例２におけるデータセンタプラン作成の流れを説明する図である。図３６は、実施例２におけるプランのリソース提供・返却可能性判定の流れの一例を示すフローチャートである。図３７は、実施例２における要求ＶＭ増分の変更の処理の流れの一例を示すフローチャートである。図３８は、実施例２におけるＤＣ―ＤＣ間のＮＷ制約条件によるプラン選択の流れの一例を示すフローチャートである。図３９は、実施例２におけるＤＣ―ＤＣ間に条件を満たすＮＷはあるか否かの判定について説明する図である。図４０は、実施例２におけるユーザ条件を満たせるＮＷをＤＣ間ＮＷ制約リストにピックアップする処理の流れの一例を示すフローチャートである。図４１は、実施例２におけるアルゴリズムによるプラン選択の流れの一例を示すフローチャートである。図４２は、実施例２におけるコスト最小アルゴリズムによる処理の一例を示すフローチャートである。図４３は、実施例２における利用者所在地-ＤＣ間のＮＷ料金合計を算出する流れの一例を示すフローチャートである。図４４は、実施例２におけるＤＣ−ＤＣ間のＮＷ料金合計を算出する流れの一例を示すフローチャートである。図４５は、実施例２における帯域最大アルゴリズムによる処理の一例を示すフローチャートである。図４６は、実施例２における利用者所在地-ＤＣ間の対地リストを作成する流れの一例を示すフローチャートである。図４７は、実施例２におけるＤＣ−ＤＣ間の対地リストを作成する流れの一例を示すフローチャートである。図４８は、実施例２における制約条件の最大価格を超えない、帯域最大となるクラスの組み合わせを選択する流れの一例を示すフローチャートである。図４９は、実施例２における記録されたプランより選択したプランの帯域が大きければそのプランを記録する流れの一例を示すフローチャートである。図５０は、実施例２における遅延最小アルゴリズムによる処理の一例を示すフローチャートである。図５１は、実施例２における制約条件の最大価格を超えない、遅延最小となるクラスの組み合わせを選択する流れの一例を示すフローチャートである。図５２は、実施例２における記録されたプランより選択したプランの遅延が小さければそのプランを記録開始する流れの一例を示すフローチャートである。図５３は、実施例２における集中アルゴリズムによる処理の一例を示すフローチャートである。図５４は、実施例２におけるＶＭプランの配分後の分散値の算出の流れの一例を示す図である。図５５は、実施例２における分散アルゴリズムによる処理の流れの一例を示すフローチャートである。図５６は、実施例３における空きリソース情報と利用状況情報とを管理装置から収集する割当決定装置の構成の一例を示すブロック図である。図５７は、インタークラウドサーバによる一連の処理を実行するプログラムであるリソース管理プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。

以下に、開示する割当決定装置、割当決定方法、割当システム及び割当決定プログラムの実施例について、図面に基づいて詳細に説明する。なお、本実施例により開示する発明が限定されるものではない。各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［実施例１による構成］
図１を用いて、実施例１に係る割当決定装置１００の構成の一例を示す。図１は、実施例１に係る割当決定装置の構成の一例を示すブロック図である。図１に示す例では、割当決定装置１００は、入力部１０１と、出力部１０２と、記憶部１１０と、制御部１２０とを有する。以下に詳細に説明するように、割当決定装置１００は、リソースの割り当てを要求する割当要求の入力を受け付けると、割り当てるリソースの組み合わせを出力する。

実施例１におけるリソースについて更に説明する。リソースには複数の種類があり、異なる種類のリソースと併せて用いられる。また、同一の種類に属するリソースが複数ある。また、リソースは、異なる管理装置により提供される。

ここで、リソースの一例について説明する。例えば、リソースには、クラウドシステムにより割り当てられるサーバのリソースとネットワークのリソースとがある。また、例えば、リソースには、スマートグリッドにおいて用いられる発電所のリソースと送電網のリソースとがある。また、例えば、リソースには、物流システムにおける倉庫のリソースと交通網のリソースとがある。また、例えば、リソースには、旅行システムにおける泊地のリソースとフライトのリソースとがある。

クラウドシステムにより割り当てられるサーバのリソースとネットワークのリソースとについて更に説明する。例えば、利用者がサーバのリソースを利用する場合、サーバのリソースにアクセスするためのネットワークのリソースがサーバのリソースと併せて利用される。言い換えると、サーバのリソースは、単体で利用されるのではなく、異なる種類のリソースとなるネットワークのリソースと併せて用いられる。この場合、割当決定装置１００は、サーバのリソースを要求する割当要求の入力を受け付けると、利用者に割り当てるサーバのリソースとネットワークのリソースとの組み合わせを出力する。

スマートグリッドにおいて用いられる発電所のリソースと送電網のリソースとについて更に説明する。例えば、利用者が動力資源を利用する場合、動力資源を提供する発電所から利用者の居場所まで電力が流れる送電網のリソースが、発電所のリソースと併せて利用される。言い換えると、発電所のリソースは、単体で利用されるのではなく、異なる種類のリソースとなる送電網のリソースと併せて利用される。

物流システムにおける倉庫のリソースと交通網のリソースとについて更に説明する。例えば、利用者が倉庫の格納空間を利用する場合、倉庫の格納空間まで利用者がアクセスするための交通網のリソースが併せて利用される。言い換えると、倉庫のリソースは、単体で利用されるのではなく、異なる種類のリソースとなる交通網のリソースと併せて利用される。

旅行システムにおける泊地のリソースとフライトのリソースとについて更に説明する。例えば、旅行者が泊地を利用する場合、泊地までのアクセス手段となるフライトのリソースが併せて利用される。言い換えると、泊地のリソースは、単体で利用されるのではなく、異なる種類のリソースとなるフライトのリソースと併せて利用される。なお、上述したリソースは一例であり、これに限定されるものではなく、任意のリソースを用いて良い。

以下では、割当要求により要求されるリソースの種類に属するリソースを「主のリソース」や「第１のリソース」とも称し、「主のリソース」や「第１のリソース」と併せても用いられる種類のリソースを「第２のリソース」や「従のリソース」とも称する。例えば、利用者によりサーバのリソースが要求された場合には、サーバのリソースが「主のリソース」又は「第１のリソース」となる。また、サーバのリソースを用いる場合には、ネットワークのリソースが併せて用いられる。この結果、ネットワークのリソースが「従のリソース」又は「第２のリソース」となる。

また、以下では、詳細な例をあげて説明する場合には、割当決定装置１００が、サーバのリソースを要求する割当要求の入力を受け付け、サーバのリソースとネットワークのリソースとの組み合わせを出力する場合を用いて説明する。

図２は、実施例１に係る割当決定装置の実施形態の一例を示す図である。図２に示す例では、サーバのリソースとなるサーバ４０１−１〜９と、ネットワークのリソースとなるネットワーク４０２−１〜３とがある場合を示した。また、図２に示す例では、ユーザにより用いられるユーザ端末３００−１〜３を併せて示した。ユーザ端末３００は、例えば、リソースの新規割当を要求する新規割当要求を割当決定装置１００に送信する。なお、図２に示す例では、記載の便宜上、ユーザ端末３００と割当決定装置１００とが接続してない場合を示したが、これに限定されるものではない。例えば、ユーザ端末３００と割当決定装置１００とが接続されても良い。

また、図２に示す例では、管理装置２００−１〜３が、それぞれ、サーバのリソースとして、サーバ４０１−１〜３、サーバ４０１−４〜６、サーバ４０１−７〜９を管理する場合を示した。また、図２に示す例では、管理装置２００−４〜管理装置２００−６が、それぞれ、ネットワークのリソースとして、ネットワーク４０２−１、ネットワーク４０２−２、ネットワーク４０２−３を管理する場合を示した。

ここで、管理装置２００−１〜６は、サーバのリソースやネットワークのリソースをユーザ端末３００に割り当てたり、ユーザ端末３００からリソースを回収したりする。複数ある管理装置２００−１〜６は、それぞれ独自のリソースを管理し、独自に管理するリソースをユーザに割り当てる。

また、図２に示す例では、ユーザ端末３００−１が、ネットワーク４０２−１とサーバ４０１−７とを利用している場合を示した。また、図２に示す例では、ユーザ端末３００−２が、ネットワーク４０２−２とサーバ４０１−５及びサーバ４０１−９とを利用している場合を示した。また、図２に示す例では、ユーザ端末３００−３が、ネットワーク４０２−３とサーバ４０１−１及びサーバ４０１−６とを利用している場合を示した。

ここで、割当決定装置１００は、例えば、異なる管理装置２００により割り当てられるリソース各々について、リソースの空き状況を示す空きリソース情報とリソースの利用状況を示す利用状況情報とを収集する。そして、割当決定装置１００は、収集した利用状況情報を解析することで、既に割り当てられているリソースの過不足を判定し、過不足を解消する割り当てを決定する。そして、割当決定装置１００は、決定したリソースの割当を管理装置２００に出力する。

すなわち、例えば、割当決定装置１００は、異なる種類のリソース各々について空きリソース情報と利用状況情報とを収集し、収集した情報に基づいて利用者に割り当てるリソースの組み合わせを決定し、決定した組み合わせをリソース割当として管理装置２００に出力する。この結果、異なる種類のリソースを簡単に組み合わせ可能となる。

なお、図２に示した構成は一例であり、これに限定されるものではない。例えば、図２に示す例では、管理装置２００が６つあり、サーバ４０１のリソースが９つあり、ネットワーク４０２のリソースが３つある場合を示したが、これに限定されるものではなく、任意の数であって良い。

図２を用いての説明では、割当決定装置１００が、空きリソース情報と利用状況情報とを自ら収集するものとして説明したが、これに限定されるものではない。例えば、割当決定装置１００は、他の装置により収集された空きリソース情報と利用状況情報とを用いてリソースの組み合わせを決定しても良く、予め記憶していた空きリソース情報と利用状況情報とを用いてリソースの組み合わせを決定しも良い。以下では、割当決定装置１００が、空きリソース情報と利用状況情報とを予め記憶しており、予め過不足が判定されている場合を用いて説明する。つまり、割当決定装置１００が、過不足を解消するリソースの割り当てを如何に決定するかについて詳細に説明する。

図１の説明に戻る。入力部１０１は、制御部１２０と接続される。入力部１０１は、情報や指示を利用者から受け付け、受け付けた情報や指示を制御部１２０に入力する。入力部１０１は、例えば、利用者から情報の入力を受け付けるためのキーボードやマウス、マイクなどが該当する。また、入力部１０１は、例えば、他の装置から情報の入力を受け付ける情報入出力端子などが該当する。出力部１０２は、制御部１２０と接続される。出力部１０２は、制御部１２０から情報を受け付け、受け付けた情報を出力する。出力部１０２は、モニタや情報入出力端子などが該当する。

なお、入力部１０１によって受け付けられる情報や、出力部１０２によって出力される情報の詳細については、ここでは説明を省略し、関係する各部について説明する際に併せて説明する。

記憶部１１０は、制御部１２０と接続される。記憶部１１０は、制御部１２０による各種処理に用いるデータを記憶する。記憶部１１０は、例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、又は、ハードディスクや光ディスクなどが該当する。図１に示す例では、記憶部１１０は、制約条件テーブル１１１と、リソース情報テーブル１１２とを有する。

制約条件テーブル１１１は、ユーザを識別するユーザＩＤ（Identifier）と、リソースの割当に関する制約条件とを対応付けて記憶する。図３は、実施例１における制約条件テーブルに記憶された情報の一例を示す図である。図３に示すように、制約条件テーブル１１１は、ユーザＩＤと対応付けて制約条件を記憶する。例えば、図３に示す例では、制約条件テーブル１１１は、ユーザＩＤ「ＵＳＥＲ０００１」やユーザＩＤ「ＵＳＥＲ０００２」などについて制約条件を記憶する。

また、図３に示す例では、制約条件テーブル１１１は、制約条件の一例として、「料金の上限値」と「リソースの属性」と「リソースの上限値」と「リソースの下限値」とを記憶する場合を示した。「料金の上限値」は、ユーザが許容する料金の上限値を示す。「リソースの属性」は、ユーザが割当可能とするリソースの属性を示す。リソースの属性とは、例えば、リソースの所在地が該当する。「リソースの上限値」と「リソースの下限値」とは、それぞれ、ユーザが割当可能とするリソースのリソース量の範囲を示す。

図３に示す例では、制約条件テーブル１１１は、ユーザＩＤ「ＵＳＥＲ０００１」に対応付けて、料金の上限値「１００万円／月」と、リソースの属性「サーバの所在地：東京」と、リソースの上限値「１００Ｍｂｐｓ」と、リソースの下限値「１０Ｍｂｐｓ」とを記憶する。すなわち、制約条件テーブル１１１は、ユーザＩＤ「ＵＳＥＲ０００１」により識別されるユーザが許容する料金の上限値が「１００万円／月」であり、東京にあるサーバのリソースを割当可能とすることを記憶する。また、制約条件テーブル１１１は、ユーザＩＤ「ＵＳＥＲ０００１」により識別されるユーザに対して、「１００Ｍｂｐｓ」から「１０Ｍｂｐｓ」の範囲に収まるリソースを割当可能とすることを記憶する。

なお、制約条件テーブル１１１に記憶される情報は、例えば、ユーザ端末３００により新規割当要求とともに割当決定装置１００に送信される。すなわち、例えば、割当決定装置１００は、ユーザＩＤと制約条件とを含む新規割当要求をユーザ端末３００から受信すると、受信した新規割当要求に含まれるユーザＩＤと制約条件とを対応付けて制約条件テーブル１１１に格納する。

また、図３に示した制約条件テーブル１１１は一例であり、これに限定されるものではない。すなわち、制約条件テーブル１１１は、任意の情報を制約条件として記憶して良い。例えば、制約条件テーブル１１１は、サーバのリソースについての制約条件として、耐震基準やセキュリティ基準、稼働率についての基準など、任意の条件を記憶して良い。

リソース情報テーブル１１２は、リソースについての情報を記憶する。具体的には、リソース情報テーブル１１２は、各種のリソースについての情報を記憶する。例えば、リソース情報テーブル１１２は、リソース各々についての空きリソース情報と利用状況情報とを記憶する。また、例えば、リソース情報テーブル１１２は、異なるリソース間における依存関係を記憶する。

図４は、実施例１におけるリソース情報テーブルに記憶された情報の一例を示す図である。図４に示す例では、「リソース名」に対応付けて、リソースの種類を示す「リソース種類」と、従となるリソースの種類を示す「従となるリソース」と、「リソース属性」とを記憶する。図４において、「リソース種類」と「従となるリソース」との対応付けは、異なるリソース間における依存関係の一例を示す。また、図４において、「リソース属性」は、リソースについての各種情報や空きリソース情報、利用状況情報を示す。なお、図４の「リソース属性」には、記載の便宜上、リソースについての各種情報として、リソースの所在地を示した。

図４に示す例では、リソース情報テーブル１１２は、リソース名「サーバリソースＡ」に対応付けて、リソース種類「サーバ」と、従となるリソース「ネットワーク」と、リソース属性「東京都港区」とを記憶する。つまり、リソース情報テーブル１１２は、「サーバリソースＡ」は、「東京都港区」にあり、リソースの種類が「サーバ」であり、従となるリソースが「ネットワーク」であることを記憶する。

制御部１２０は、入力部１０１、出力部１０２及び記憶部１１０と接続される。制御部１２０は、各種の処理手順などを規定したプログラムを記憶する内部メモリを有し、種々の処理を制御する。制御部１２０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）などが該当する。図１に示す例では、制御部１２０は、受付部１２１と、生成部１２２と、判定部１２３と、選択部１２４とを有する。

受付部１２１は、リソースの割り当てを要求する割当要求の入力を受け付ける。例えば、受付部１２１は、入力部１０１に入力された割当要求を受け付ける。割当要求は、リソースの割当先となるユーザのユーザＩＤと、割当要求により要求されるリソース量を示す情報とが含まれる。

ここで、割当要求により要求されるリソース量は、利用者が必要とするリソース量と、現在利用者が割り当てられているリソース量との差分となる。この結果、割当要求により要求されるリソース量は、利用者が必要とするリソース量が、現在利用者が割り当てられているリソース量よりも少ない場合には、現在利用者が割り当てられているリソース量のうち利用者にとって不要であり返却が必要なリソース量となる。また、割当要求により要求されるリソース量は、利用者が必要とするリソース量が、現在利用者が割り当てられているリソース量よりも多い場合には、利用者に足りない分を補うための追加が必要なリソース量となる。

生成部１２２は、複数あるリソース各々のうち、受付部１２１により受け付けられた割当要求により要求されるリソースの種類に属する第１のリソースを選択し、選択した第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースとの組み合わせを生成する。

サーバのリソースが要求された場合を用いて生成部１２２について更に説明する。この場合、生成部１２２は、要求情報により要求されたリソースの種類となるサーバのリソースを１つ選択する。そして、生成部１２２は、サーバのリソースと組み合わせて用いられる種類のリソースであるネットワークのリソースを１つ選択し、選択したサーバのリソースとネットワークのリソースとの組み合わせを生成する。なお、割当要求は、サーバのリソースを要求するものであっても良く、サーバのリソースとネットワークのリソースとを両方要求するものであっても良い。

より詳細な一例をあげて説明すると、生成部１２２は、割当先となるユーザのユーザＩＤに対応付けられた制約条件を制約条件テーブル１１１から読み出す。そして、生成部１２２は、要求情報により要求されたリソースの種類となるサーバのリソースとして、読み出した制約条件を満たすサーバのリソースを選択する。例えば、制約条件によりサーバの所在地が「日本」に制約される場合には、所在地が「日本」となっているサーバのリソースを選択する。そして、生成部１２２は、選択したサーバと利用者の所在地との間を結ぶネットワークのリソースとして、制約条件を満たすネットワークのリソースを選択する。そして、生成部１２２は、選択したサーバのリソースとネットワークのリソースとの組み合わせを生成する。

ここで、制約条件を満たすサーバのリソースや、制約条件を満たすネットワークのリソースが複数ある場合がある。この場合、生成部１２２は、制約条件を満たすサーバのリソースとネットワークのリソースとの全組み合わせを生成する。

また、サーバにより割り当てられるリソースに、複数の種類がある場合について説明する。例えば、サーバにより割り当てられるのがＶＭ（仮想マシン、Virtual Machine）であり、ＶＭには処理能力の違う複数のＶＭタイプがある場合を用いて説明する。また、割当要求により要求されるリソース量が、ＶＭタイプごとに指定される場合を用いて説明する。この場合、生成部１２２は、ＶＭタイプごとに、制約条件を満たすサーバのリソースを選択する。言い換えると、生成部１２２は、割当要求により要求されたＶＭタイプ各々についてサーバのリソースを選択する。

また、生成部１２２は、第１のリソースと第２のリソースとに加えて、複数の第１のリソース又は複数の第２のリソースを用いる際に併せて用いられる種類のリソースである第３のリソースを更に組み合わせた組み合わせを生成する。

例えば、サーバのリソースとして、複数のサーバのリソースの組み合わせが選択された場合を用いて説明する。この場合、複数のサーバ間を結ぶネットワークのリソースが更に用いられることになる。このことを踏まえ、生成部１２２は、複数のサーバのリソースの組み合わせと、選択されたサーバと利用者の所在地との間についてのネットワークのリソースとに加えて、複数のサーバ間を結ぶネットワークのリソースとして、制約条件を満たすネットワークのリソースを選択する。

つまり、例えば、第１のリソースとなるデータセンタのリソースを複数利用する場合、それぞれのデータセンタにアクセスするためのリソースが併せて用いられる。具体的には、ユーザとデータセンタ間のネットワークが第２のリソースとして併せて用いられる。また、第１のリソースとなるデータセンタのリソースを複数利用する場合、複数あるデータセンタ各々にあるリソースを一つのデータセンタのリソースとして利用するためのリソースが併せて用いられる。具体的には、データセンタ間のネットワークが第３リソースとして併せて用いられる。すなわち、生成部１２２は、例えば、複数のサーバのリソースと、サーバとユーザとの間のネットワークのリソースとに加えて、サーバ間のネットワークのリソースを加えて組み合わせを生成する。

判定部１２３は、生成部１２２により生成された組み合わせについて、組み合わせに含まれる第１のリソースと第２のリソースとが組み合わせ可能なリソースであるか否かを判定する。具体的には、判定部１２３は、生成部１２２により生成された組み合わせ各々について、組み合わせに含まれるリソースの提供元が、割当要求により要求されるリソース量を割当可能か否かを判定する。例えば、判定部１２３は、組み合わせに含まれるリソース各々が利用可能なリソースであるか否かについて判定する。

例えば、割当要求により要求されるサーバのリソース量が、ＶＭタイプ１について「１０台」であり、ＶＭタイプ２について「２台」であり、ＶＭタイプ３について「２台」である場合を用いて説明する。この場合、組み合わせに含まれるリソースの提供元となるサーバが、ＶＭタイプ１について「１０台」割当可能であり、ＶＭタイプ２について「２台」割当可能であり、ＶＭタイプ３について「２台」割当可能であるか否かをＶＭタイプごとに判定する。

また、判定部１２３は、生成部１２２により生成された組み合わせについて、組み合わせに含まれる第１のリソースと第２のリソースとが同時に利用可能であるか否かを判定することで、組み合わせ可能なリソースであるか否かを判定する。

例えば、判定部１２３は、同一のサーバが異なるＶＭタイプ各々について同時に割当可能であるかを判定する。例えば、同一のサーバが、異なるＶＭタイプ各々についてそれぞれリソースを割り当てる場合を用いて説明する。例えば、サーバ「１」が、ＶＭタイプ１について「１０台」割り当てるとともに、ＶＭタイプ２について「２台」割り当てることになる組み合わせを用いて説明する。この場合、判定部１２３は、サーバ「１」が、ＶＭタイプ１について「１０台」割り当てると共に、ＶＭタイプ２について「２台」割り当てることが可能であるか否かを判定する。

つまり、サーバのリソースの提供元は、ＶＭタイプ１のリソース１０台割り当てることが可能であり、また、ＶＭタイプ２のリソース２台割り当てることが可能であったとしても、ＶＭタイプ１のリソース１０台とＶＭタイプ２のリソース２台とを同時に割り当てることはできない場合がある。例えば、ＶＭタイプ１の１０台分のリソースはＶＭタイプ２を割り当てる際にも用いられる場合がある。この場合、サーバのリソースの提供元は、ＶＭタイプ１を１０台割り当てるとともに、同時に、ＶＭタイプ２を２台割り当てることはできない。このことを踏まえ、判定部１２３は、異なるＶＭタイプ各々について同一のサーバが割り当てる場合に、ＶＭタイプ各々を同時に割り当て可能であるか否かを判定する。

なお、ここでは、同一のサーバが異なるＶＭタイプ各々についてリソースを割り当てる場合を例に説明したが、これに限定されるものではない。例えば、ネットワークのリソースの提供元が、異なるタイプのリソース各々を割り当てる場合についても同様である。

また、例えば、判定部１２３は、組み合わせに含まれるサーバのリソースとネットワークのリソースとが、同時に利用可能な組み合わせとなるか否かを判定する。例えば、判定部１２３は、組み合わせに含まれるネットワークのリソースが、ユーザの所在地とサーバのリソースの場所とを結ぶネットワークであるか否かを判定する。ここで、判定部１２３は、組み合わせに含まれるネットワークのリソースが、ユーザの所在地とサーバのリソースの場所とを結ぶネットワークであると判定した場合には、同時に利用可能な組み合わせであると判定する。一方、判定部１２３は、組み合わせに含まれるネットワークのリソースが、ユーザの所在地とサーバのリソースの場所とを結ぶネットワークでないと判定した場合には、同時に利用可能な組み合わせでないと判定する。

なお、上述の説明では、生成部１２２が組み合わせを生成した上で、判定部１２３が判定を行う場合を用いて説明したが、これに限定されるものではない。例えば、生成部１２２が組み合わせを生成する際に、判定部１２３が適宜判定処理を実行し、生成部１２２が、判定部１２３により組み合わせ可能なリソースであると判定されたリソースを用いて組み合わせを生成しても良い。

選択部１２４は、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する。具体的には、選択部１２４は、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせから、組み合わせについての所定の基準に従って組み合わせを１つ選択する。例えば、選択部１２４は、リソースの提供元やリソースの要求元により要求された基準に従って、組み合わせを１つ選択する。つまり、選択部１２４は、リソースの利用者またリソースの提供元の意思を反映した上で、組み合わせを選択する。

例えば、選択部１２４は、所定の基準としての複数のアルゴリズムのうち任意のアルゴリズムのうち任意のアルゴリズムに従って組み合わせを１つ選択する。この場合、選択部１２４は、リソースの提供元やリソースの要求元により使用することが要求されたアルゴリズムを用いて、組み合わせを１つ選択する。言い換えると、選択部１２４は、リソースの提供元又はリソースの要求元による要求を満たす組み合わせを選択するアルゴリズムを所定の基準として用いて、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせから１つの組み合わせを選択する。

ここで、所定の基準により選択される組み合わせの一例を示す。例えば、選択部１２４は、リソースを利用する上で必要となる料金が低い組み合わせを、料金が高い組み合わせより優先して選択する。また、例えば、選択部１２４は、ネットワークのリソースの平均帯域が高い組み合わせを、平均帯域が低い組み合わせより優先して選択する。また、例えば、選択部１２４は、ネットワークのリソースの遅延が小さい組み合わせを、遅延が大きい組み合わせより優先して選択する。また、例えば、選択部１２４は、組み合わせに含まれるリソースを割り当てることでリソースの提供元となるサーバが集中する組み合わせを、リソースの提供元となるサーバが分散する組み合わせより優先して選択する。また、例えば、選択部１２４は、組み合わせに含まれるリソースを割り当てることでリソースの提供元となるサーバが分散する組み合わせを、集中する組み合わせより優先して選択する。

ここで、組み合わせに含まれるリソースを割り当てることでリソースの提供元となるサーバが集中する組み合わせを優先して選択する場合について、更に説明する。選択部１２４は、アルゴリズムとして、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせごとに、組み合わせに含まれるリソースを割り当てた場合における複数あるリソースごとの割当状況を算出する。そして、判定部１２３は、複数あるリソース間における分散度合いを組み合わせごとに算出する。そして、選択部１２４は、算出された分散度合いが低い組み合わせを分散度合いが高い組み合わせより優先して選択する。

より詳細な一例をあげて説明する。ここでは、サーバのリソースとして、データセンタが備えるコアを割り当てる場合を用いて説明する。また、データセンタ１が、処理を実行する「コア」を１００個備え、データセンタ２が「コア」を５０個備える場合を用いて説明する。また、組み合わせを実行する結果、データセンタ１が有する１００個のコアのうち、８０個のコアが割当中となり、データセンタ２が有する５０個のコアのうち、３０個のコアが割当中となる場合を用いて説明する。この場合、選択部１２４は、リソースごとの割当状況として、割当状況をデータセンタごとに算出する。例えば、データセンタ１についての割当状況は「８０％」となり、データセンタ２についての割当状況は「６０％」となる場合には、選択部１２４は、「８０％」と「６０％」の分散値を算出することで、リソース間の分散度合いを算出する。

ここで、分散値が最大となる組み合わせを選択するということは、各リソース間における割当状況の差が最も大きくなることを示す。例えば、データセンタごとに、割当状況の差が最も大きくなることを示す。言い換えると、コアが多く利用されるデータセンタと、コアがあまり利用されないデータセンタとがあることを示す。この場合、リソースの提供元は、例えば、割当状況が小さくなるデータセンタについて、コアの一部を一時的にシャットダウンすることで、消費電力を低減させることが可能となる。

また、分散値が最小となる組み合わせを選択するということは、各リソース間における割当状況の差が最も小さくなる組み合わせを選択することを示す。例えば、データセンタごとに、割当状況の差が最も小さくなることを示す。言い換えると、どのデータセンタについても同じように利用されることになることを示す。この場合、リソースの提供元は、例えば、各データセンタに対する処理負荷を均一にすることが可能となる。

また、選択部１２４は、出力部１０２を介して、選択した組み合わせを出力する。ここで、選択部１２４により選択された組み合わせが、リソースの要求元に対するリソースの割当を示すリソース割当となる。その後、例えば、選択部１２４により出力されたリソース割当に従って管理装置２００がリソースを割り当てる。

［実施例１による処理］
図５は、実施例１に係る割当決定装置による処理の流れの一例を示すフローチャートである。図５に示すように、割当決定装置１００では、割当要求の入力を受付部１２１が受け付けると（ステップＳ１０１肯定）、生成部１２２が、組み合わせを生成する（ステップＳ１０２）。つまり、生成部１２２は、複数あるリソース各々のうち、割当要求により要求されるリソースの種類に属する第１のリソースを選択し、選択した第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースとの組み合わせを生成する。

そして、判定部１２３は、生成部１２２により生成された組み合わせについて、組み合わせに含まれる第１のリソースと第２のリソースとが組み合わせ可能なリソースであるか否かを判定する（ステップＳ１０３）。

例えば、割当要求により要求されるサーバのリソース量が、ＶＭタイプ１について「１０台」であり、ＶＭタイプ２について「２台」であり、ＶＭタイプ３について「２台」である場合を用いて説明する。この場合、判定部１２３は、組み合わせ各々について、ＶＭタイプ１について「１０台」割当可能であり、ＶＭタイプ２について「２台」割当可能であり、ＶＭタイプ３について「２台」割当可能であるか否かを判定する。また、判定部１２３は、同一のサーバが、異なるＶＭタイプ各々についてそれぞれリソースを割り当てる場合には、ＶＭタイプ１について「１０台」割り当てると共に、ＶＭタイプ２について「２台」割り当てることが可能であるか否かを判定する。

また、例えば、判定部１２３は、組み合わせに含まれるサーバのリソースとネットワークのリソースとが、同時に利用可能な組み合わせとなるか否かを判定する。例えば、判定部１２３は、組み合わせに含まれるネットワークのリソースが、ユーザの所在地とサーバのリソースの場所とを結ぶネットワークであるか否かを判定する。

そして、選択部１２４は、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する（ステップＳ１０４）。例えば、選択部１２４は、リソースの提供元又はリソースの要求元による要求を満たす組み合わせを選択するアルゴリズムを所定の基準として用いて、判定部１２３により組み合わせ可能なリソースであると判定された組み合わせから、組み合わせを１つ選択する。

そして、選択部１２４は、出力部１０２を介して、選択した組み合わせを出力する（ステップＳ１０５）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［実施例１の効果］
上述したように、実施例１によれば、割当決定装置１００は、割当要求の入力を受け付ける。また、割当決定装置１００は、複数あるリソース各々のうち、受け付けられた割当要求により要求されるリソースの種類に属する第１のリソースを選択し、選択した第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースとの組み合わせを生成する。また、割当決定装置１００は、生成した組み合わせについて、組み合わせに含まれる第１のリソースと第２のリソースとが組み合わせ可能なリソースであるか否かを判定する。また、割当決定装置１００は、組み合わせ可能なリソースであると判定された組み合わせを１つ選択し、出力する。この結果、異なる種類のリソースを適切に組み合わせ可能である。

また、実施例１によれば、割当決定装置１００は、組み合わせに含まれる第１のリソースと第２のリソースとが同時に利用可能であるか否かを判定することで、組み合わせ可能なリソースであるか否かを判定する。この結果、組み合わせ可能な組み合わせを確実に１つ出力することが可能である。

また、実施例１によれば、割当決定装置１００は、複数の第１のリソース又は複数の第２のリソースに加えて、第１のリソース又は第２のリソースを用いる際に併せて用いられる種類のリソースである第３のリソースを更に組み合わせた組み合わせを生成する。この結果、第１のリソースと第２のリソースとは別に更にリソースが併せて用いられる場合であっても、利用可能な組み合わせを出力することが可能である。

また、実施例１によれば、割当決定装置１００は、組み合わせ可能なリソースであると判定された組み合わせから、組み合わせについての所定の基準に従って組み合わせを１つ選択する。この結果、組み合わせ可能なリソースであると判定された組み合わせが複数あったとしても、１つの組み合わせを選択可能である。

また、実施例１によれば、割当決定装置１００は、所定の基準としての複数のアルゴリズムのうち任意のアルゴリズムのうち任意のアルゴリズムに従って組み合わせを１つ選択する。この結果、組み合わせ可能なリソースであると判定された組み合わせが複数あったとしても、１つの組み合わせを選択可能である。

また、実施例１によれば、割当決定装置１００は、リソースの提供元による要求を満たす組み合わせを選択するアルゴリズムを所定の基準として用いて、組み合わせ可能なリソースであると判定された組み合わせから組み合わせを１つ選択する。この結果、リソースの利用者又はリソースの提供元が制御したいポリシを反映した上で、組み合わせを１つ選択することが可能である。

また、実施例１によれば、割当決定装置１００は、アルゴリズムとして、組み合わせ可能なリソースであると判定された組み合わせ各々について、組み合わせに含まれるリソースを割り当てた場合における複数あるリソースごとの割当状況を算出する。また、割当決定装置１００は、組み合わせごとに算出された割当状況の複数あるリソース間における分散度合いを算出する。また、割当決定装置１００は、算出された分散度合いが高い組み合わせを低い組み合わせと比較して優先して選択し、又は、算出された分散度合いが低い組み合わせを高い組み合わせと比較して優先して選択するアルゴリズムを有する。この結果、リソースの割り当て状況が分散する又は集中する組み合わせを選択可能である。

また、実施例１によれば、割当決定装置１００は、第１のリソースは、データセンタのサーバリソースであり、第２のリソースは、ネットワークのリソースである。この結果、ネットワークのリソースやサーバのリソースなどを提供する複数のクラウドシステムについて、複数のクラウドシステムを横断したリソースの割当を出力することが可能である。

実施例２では、割当決定装置が、ネットワークのリソースとサーバのリソースとを割り当てる場合について詳細に説明する。また、サーバのリソースとして、データセンタのリソースを割り当てる場合を用いて説明する。具体的には、以下に説明するように、リソース割当装置が、リソースを管理する管理装置各々から、リソースについての情報を収集し、収集した情報に基づいてリソース割当を決定する場合について説明する。以下では、割当決定装置を「インタークラウドサーバ」とも称する。

なお、以下では、クラウドシステムにより提供されるリソースが、ＡＳＰ（Application Service Provider）運用者やユーザに割り当てられる場合を用いて説明する。なお、ＡＳＰ運用者により提供されるサービスは、ユーザにより利用される。

図６は、実施例２におけるインタークラウドサーバの全体像について示す図である。実施例２におけるインタークラウドサーバ５００は、データセンタのリソースやネットワークのリソースを提供するクラウドシステム各々について、リソースの状況を示す情報を収集し、異なるクラウドシステムに属するリソース各々をＡＳＰ運用者に割り当てる。例えば、実施例２におけるインタークラウドサーバ５００は、異なるクラウドシステムにより提供されるリソースを組み合わせて提供することで、スケールアウト等のマイグレーションを支援する。

図６に示す例では、インタークラウドサーバ５００に加えて、オペレータ端末６０１と、ＡＳＰ端末６０２と、ＤＣ−ＯＰＳ（Data Center−Operation System）６０３と、ＮＷ−ＯＰＳ（Network−Operation System）６０４と、ＤＣ（Data Center、データセンタ）６０５と、Ｒ（Router、ルータ）６０６と、ユーザ端末６０７とを併せて示した。

オペレータ端末６０１は、インタークラウドサーバ５００と接続される。オペレータ端末６０１は、インタークラウドサーバ５００を管理するオペレータにより用いられる。オペレータ端末６０１は、Ｗｅｂブラウザを有する。例えば、オペレータ端末６０１は、インタークラウドサーバ５００の設定や運用、管理等を行うためのインタフェースをＷｅｂブラウザ上に表示する。

ＡＳＰ端末６０２は、インタークラウドサーバ５００と接続される。ＡＳＰ端末６０２は、クラウドシステムにより提供されるリソースを用いてサービスを提供するＡＳＰ運用者により用いられる。ＡＳＰ端末６０２は、Ｗｅｂブラウザを有する。例えば、ＡＳＰ端末６０２は、インタークラウドサーバ５００の設定や運用、管理等を行うためのインタフェースをＷｅｂブラウザ上に表示する。

Ｒ６０６は、ＮＷ−ＯＰＳ６０４及びＤＣ６０５、ユーザ端末６０７と接続される。Ｒ６０６は、ネットワーク装置であり、例えば、ルータである。Ｒ６０６は、ネットワークを形成する。なお、Ｒ６０６により形成されるネットワーク６０８により、ＤＣ６０５とユーザ端末６０７とが接続され、複数あるＤＣ６０５各々が接続される。Ｒ６０６は、ＮＷ−ＯＰＳ６０４により管理される。

ＤＣ６０５は、ＤＣ−ＯＰＳ６０３及びＲ６０６と接続される。ＤＣ６０５は、仮想マシンサービスを提供する。ＤＣ６０５は、ＤＣ−ＯＰＳ６０３により管理される。なお、仮想マシン（ＶＭ、Virtual Machine）とは、ソフトウェアによって提供される仮想的なＰＣを示す。なお、以下では、ＤＣ６０５を「データセンタ６０５」とも記載する。

ＤＣ−ＯＰＳ６０３は、インタークラウドサーバ５００及びＤＣ６０５と接続される。ＤＣ−ＯＰＳ６０３は、ＤＣ６０５のリソースを管理する管理装置である。具体的には、ＤＣ−ＯＰＳ６０３は、ＤＣ６０５の利用状況情報をＡＳＰ運用者ごとに把握し、ＤＣ６０５各々の空きリソース情報を把握する。例えば、ＤＣ−ＯＰＳ６０３は、１つ又は複数のＤＣ６０５を管理する。

ＮＷ−ＯＰＳ６０４は、インタークラウドサーバ５００及びＲ６０６と接続される。ＮＷ−ＯＰＳ６０４は、Ｒ６０６を管理する管理装置である。具体的には、ＮＷ−ＯＰＳ６０４は、Ｒ６０６により形成されるネットワーク６０８各々について、ネットワーク６０８の利用状況情報をＡＳＰ運用者ごとに把握し、Ｒ６０６により形成されるネットワーク６０８各々について空きリソース情報を把握する。例えば、ＮＷ−ＯＰＳ６０４は、１つ又は複数のＲ６０６を管理する。

なお、図６に示す例では、説明の便宜上、オペレータ端末６０１が１つあり、ＡＳＰ端末６０２が１つあり、ＤＣ−ＯＰＳ６０３が４つあり、ＮＷ−ＯＰＳ６０４が４つあり、ＤＣ６０５が４つあり、Ｒ６０６が４つあり、ユーザ端末６０７が３つある場合を示した。ただし、これに限定されるものではなく、各装置の数は任意であって良い。例えば、ＡＳＰ端末６０２が２つ以上あっても良く、ＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４、ＤＣ６０５、Ｒ６０６などが３つ以下でも良く、５つ以上でも良い。

また、図６に示す例では、オペレータ端末６０１と、ＡＳＰ端末６０２と、ユーザ端末６０７とが別装置である場合を例に示したが、これに限定されるものではない。例えば、オペレータ端末６０１と、ＡＳＰ端末６０２と、ユーザ端末６０７とのうち、任意の装置を組み合わせて１つの装置としても良い。

インタークラウドサーバ５００は、各種のハードウェアを有し、ＯＳやミドルウェアなどの各種プログラムが予めインストールされる。具体的には、インタークラウドサーバ５００は、詳細については後述するように、インタークラウドサーバ５００が有する各種のハードウェアにより実行されるプログラムとして、ＩＣＳソフトウェア５０１と、ＲＡＦ（リソース要件推定アルゴリズム）５０２とを実行する。

なお、ＩＣＳソフトウェア５０１は、実施例１における制御部１２０の各部により実行される処理を実行する。また、ＲＡＦ５０２は、ＡＳＰ運用者に割り当てられているリソースについての利用状況情報と制約条件とに基づいて、ＡＳＰ運用者に割り当てることが推奨されるリソースのリソース要件を推定する。例えば、ＲＡＦ５０２は、利用状況情報を解析することで、ＡＳＰ運用者が必要とするリソース量を推定し、制約条件に合致して推定したリソース量を満たすリソース要件を推定する。なお、ＲＡＦ５０２による推定処理は、任意の手法を用いて良い。

また、実施例２におけるＩＣＳソフトウェア５０１は、後述するように、過不足しているリソースの要件を判定する場合に、ＲＡＦ５０２により推定されたリソース要件と、利用状況情報により示される利用中のリソースとを比較する。そして、実施例２におけるＩＣＳソフトウェア５０１は、後述するように、ＲＡＦ５０２により推定されたリソース要件と、利用状況情報により示される利用中のリソースとの差分について、空きリソースのうち制約条件を満たす任意のリソースを新たに追加するリソース割当を決定したり、利用状況情報により示される利用中のリソースのうち任意のリソースを開放するリソース割当を決定したりする。

なお、以下では、ＲＡＦ５０２が、ＩＣＳソフトウェア５０１と同一のコンピュータにインストールされたプログラムである場合を用いて説明する。ただし、ＲＡＦ５０２は、これに限定されるものではなく、ＩＣＳソフトウェア５０１とは別のコンピュータにインストールされても良く、インタークラウドサーバ５００とは別の装置としても良い。

［実施例２におけるインタークラウドサーバによるリソース割当処理の動作概要］
実施例２におけるインタークラウドサーバ５００によるリソース割当処理の動作概要について説明する。具体的には、リソース割当処理の動作概要として、ＡＳＰ運用者に新規にリソースを割り当てられる新設時における動作概要と、ＡＳＰ運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要と、ＡＳＰ運用者に割り当てられたリソースを開放する廃止時における動作概要とを順に説明する。

［新設時における動作概要］
図７は、実施例２におけるＡＳＰ運用者に新規にリソースを割り当てられる新設時における動作概要を示す図である。図７に示すように、インタークラウドサーバ５００は、制約条件ＤＢ５１１と、管理情報ＤＢ５１２とを有する。なお、図７のＮＷ６０８−１は、ＮＷ−ＯＰＳ６０４−１により管理されるＲ６０６により形成されるネットワーク６０８である。なお、以下では、ネットワーク６０８を「ＮＷ６０８」とも称する。

制約条件ＤＢ５１１は、クラウドシステムにより提供されるリソースが割り当てられるＡＳＰ運用者を識別するユーザ識別情報と制約条件とを対応付けて記憶する。言い換えると、制約条件ＤＢ５１１は、ＡＳＰ運用者ごとの制約条件を記憶する。制約条件とは、例えば、ＡＳＰ運用者に割り当てるリソースの上限値や下限値、ＡＳＰ運用者に割り当てるリソースの属性などが該当する。

なお、制約条件ＤＢ５１１に記憶された情報は、例えば、ＡＳＰ運用者によって入力され、リソースを割り当てる際に用いられる。実施例２における制約条件ＤＢ５１１に記憶される情報の詳細な一例については、後述する。

管理情報ＤＢ５１２は、リソースを管理する管理装置についての管理情報を記憶する。具体的には、ＤＣ−ＯＰＳ６０３についての管理情報を記憶し、ＮＷ−ＯＰＳ６０４についての管理情報を記憶する。管理情報とは、例えば、管理装置の識別名や管理装置にアクセスする際に用いられるＵＲＬ、管理装置にアクセスする際に用いられるパスワードなどが該当する。

なお、管理情報ＤＢ５１２に記憶された情報は、例えば、オペレータによってインタークラウドサーバ５００に入力され、インタークラウドサーバ５００が管理装置にアクセスする際に用いられる。実施例２における管理情報ＤＢ５１２に記憶される管理情報の詳細な一例については、後述する。

リソースの新設時には、ＡＳＰ端末６０２は、ＡＳＰ運用者から制約条件を受け付け、新規割当要求をインタークラウドサーバ５００に送信する。ここで、ＡＳＰ端末６０２により送信される新規割当要求には、ＡＳＰ運用者から受け付けた制約条件が含まれる。

すると、図７の（１）に示すように、インタークラウドサーバ５００では、制約条件を含む新規割当要求をＡＳＰ端末６０２から受信する。そして、ＩＣＳソフトウェア５０１は、受信した制約条件を制約条件ＤＢ５１１に格納する。また、図７の（２）に示すように、ＩＣＳソフトウェア５０１は、リソースの空き状況を示す空きリソース情報を管理装置に要求する。図７に示す例では、ＩＣＳソフトウェア５０１は、管理情報ＤＢ５１２からＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４の管理情報を読み出し、読み出した管理情報を用いて空きリソース情報をＤＣ−ＯＰＳ６０３−１に要求する。また、同様に、ＩＣＳソフトウェア５０１は、空きリソース情報をＤＣ−ＯＰＳ６０３−２に要求し、空きリソース情報をＮＷ−ＯＰＳ６０４−１に要求する。すなわち、ＩＣＳソフトウェア５０１は、異なるクラウドシステムにより割り当てられるリソース各々について、空きリソース情報を収集する。なお、実施例２における空きリソース情報の詳細な一例については、後述する。

そして、図７（３）に示すように、ＩＣＳソフトウェア５０１は、所定のアルゴリズムに基づいて、リソース配分計算を実行する。すなわち、ＩＣＳソフトウェア５０１は、空きリソース情報により示される空きリソースから、新規割当要求に含まれる制約条件を満たす任意のリソースを選択し、選択した任意のリソースを割り当てるリソース割当を決定する。

そして、図７の（４）に示すように、ＩＣＳソフトウェア５０１は、決定したリソース割当を管理装置に出力する。図７の（４）に示す例では、ＩＣＳソフトウェア５０１は、管理情報ＤＢ５１２からＤＣ−ＯＰＳ６０３−１についての管理情報を読み出す。そして、ＩＣＳソフトウェア５０１は、読み出した管理情報を用いて、ＤＣ６０５−１のリソースを割り当てるリソース割当をＤＣ−ＯＰＳ６０３−１に出力する。つまり、ＩＣＳソフトウェア５０１は、リソース配分計算により決定されたリソースの配分を出力する。また、同様にＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２にリソース割当を出力し、ＮＷ−ＯＰＳ６０４−１にリソース割当を出力する。

その後、各管理装置は、受信したリソース割当に従ってリソースを割り当てる。例えば、ＤＣ６０５−２のリソースとＮＷ（ネットワーク）６０８−１のリソースがＡＳＰ運用者「Ａ」に割り当てられた場合を用いて説明する。この結果、例えば、ユーザＡは、ＡＳＰ運用者「Ａ」により提供されるサービスを、ネットワーク６０８−１を介してＤＣ６０５−２から提供される。

［増設・減設時における動作概要］
図８は、実施例２におけるＡＳＰ運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要を示す図である。以下に説明するように、ＩＣＳソフトウェア５０１は、既にリソースを利用しているＡＳＰ運用者のリソースの利用状況を収集する。そして、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２による推測により、リソースの既存の割り当てが妥当ではなくなったＡＳＰ運用者について、リソースを追加したり削減したりする。なお、ＩＣＳソフトウェア５０１は、以下に説明する一連の処理を任意のタイミングにて実行する。例えば、ＩＣＳソフトウェア５０１は、利用者によって予め設定された時間間隔ごとに実行する。

図８の（１）に示すように、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者ごとの利用状況情報を管理装置に要求する。図８に示す例では、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４の管理情報を管理情報ＤＢ５１２から読み出し、読み出した管理情報を用いてＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４に利用状況情報を要求する。すなわち、ＩＣＳソフトウェア５０１は、異なるクラウドシステム各々について、ＡＳＰ運用者ごとの利用状況情報を収集する。

そして、図８の（２）に示すように、ＩＣＳソフトウェア５０１は、制約条件ＤＢ５１１から制約条件を読み出し、収集した利用状況情報と読み出した制約条件とをＲＡＦ５０２に出力する。すなわち、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２に、ＡＳＰ運用者に割り当てられているリソースの過不足の判定を依頼する。

ここで、ＲＡＦ５０２は、ＩＣＳソフトウェア５０１により収集された利用状況情報と制約条件とを解析することで、ＡＳＰ運用者に既に割り当てられているリソースの過不足をＡＳＰ運用者ごとに判定する。言い換えると、ＲＡＦ５０２は、割り当てられているリソースにユーザが満足しているかを利用状況情報と制約条件とに基づいて判定し、ユーザが満足するリソースの要件を利用状況情報と制約条件とに基づいて推定する。

ＲＡＦ５０２は、過不足していると判定したＡＳＰ運用者については、過不足しているリソースのリソース要件を判定する。例えば、ＲＡＦ５０２は、不足しているリソースのリソース量を判定したり、余っているリソースのリソース量を判定したりする。そして、図８の（３）に示すように、ＲＡＦ５０２は、判定結果となるリソース要件をＩＣＳソフトウェア５０１に出力する。なお、ＲＡＦ５０２による判定処理は、任意の手法を用いて良い。

そして、図８の（４）に示すように、ＩＣＳソフトウェア５０１は、図７の（２）と同様に、空きリソース情報を管理装置に要求する。そして、図８の（５）に示すように、ＩＣＳソフトウェア５０１は、所定のアルゴリズムに基づいて、リソース配分計算を実行する。すなわち、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２によりリソースが不足していると判定されたＡＳＰ運用者に対して、空き状況情報により示される異なる種類の空きリソースのうち、制約条件を満たす任意のリソースを割り当てるリソース割当を決定する。また、ここで、ＩＣＳソフトウェア５０１が割り当てるリソースは、ＲＡＦ５０２による判定結果となるリソース要件を満たすリソースとなる。また、同様に、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２によりリソースが余っていると判定されたＡＳＰ運用者に対して、利用状況情報により示される利用中のリソースのうち、ＲＡＦ５０２による判定結果となるリソース要件を満たすリソース分、任意のリソースを開放するリソース割当を決定する。

そして、図８の（６）に示すように、ＩＣＳソフトウェア５０１は、図７の（４）と同様に、決定したリソース割当を管理装置に出力する。

［廃止時における動作概要］
図９は、実施例２におけるＡＳＰ運用者に割り当てられたリソースを開放する廃止時における動作概要を示す図である。リソースの割当をＡＳＰ運用者が終了する時には、ＡＳＰ端末６０２は、ＡＳＰ運用者から廃止する旨の指示を受け付け、割当廃止要求をインタークラウドサーバ５００に送信する。

すると、図９の（１）に示すように、ＩＣＳソフトウェア５０１は、割当廃止要求をＡＳＰ端末６０２から受信する。そして、図９の（２）に示すように、ＩＣＳソフトウェア５０１は、図８の（１）と同様に、ＡＳＰ運用者ごとの利用状況情報を管理装置に要求する。つまり、異なるクラウドシステム各々について、ＡＳＰ運用者ごとの利用状況情報を収集する。言い換えると、ＡＳＰ運用者に割り当てられたリソースの利用状況を確認する。

そして、図９の（３）に示すように、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者に割り当てられているリソースを開放するリソース割当を決定し、決定したリソース割当を管理装置に出力する。

［実施例２におけるインタークラウドサーバのユースケース］
図１０は、実施例２におけるインタークラウドサーバのユースケースの一例を示す図である。以下では、図１０を用いて、オペレータ端末６０１を用いるインタークラウドサーバ５００のオペレータや、ＡＳＰ端末６０２を用いるＡＳＰ運用者により、インタークラウドサーバ５００がどのように用いられるかの一例を示す。

なお、図１０では、説明の便宜上、インタークラウドサーバ５００に加えて、オペレータ端末６０１と、ＡＳＰ端末６０２と、ＤＣ−ＯＰＳ６０３と、ＮＷ−ＯＰＳ６０４とを併せて示した。

以下では、インタークラウドサーバ５００のユースケースの一例として、７つのユースケースを順に説明する。具体的には、システム情報を登録する場面と、リソース配分を行う場面と、新設を実行する場面と、廃止を実行する場面と、制約条件を登録する場面と、クラウドサービス利用中のＡＳＰ運用者の削除する場面と、利用状況を確認する場面とについて、順に説明する。

［システム情報を登録する場面］
図１０の（１）に示すように、システム情報を登録する場面について説明する。具体的には、インタークラウドサーバ５００が各種の処理を実行する上で用いられる各種設定の登録を行う場面について説明する。図１０の（１）に示すように、システム情報を登録する場面については、ＩＣＳ運用者により利用される。

この場合、インタークラウドサーバ５００の運用者は、リソース配分計算にて用いるアルゴリズムをオペレータ端末６０１から、インタークラウドサーバ５００に登録する。また、インタークラウドサーバ５００のオペレータは、オペレータ端末６０１から、管理情報を管理情報ＤＢ５１２に格納したり、管理情報を更新したりする。また、インタークラウドサーバ５００のオペレータは、ＤＣ−ＯＰＳ６０３についての管理情報を管理情報ＤＢ５１２に格納したり、ＮＷ−ＯＰＳ６０４についての管理情報を管理情報ＤＢ５１２に格納したり、管理情報に変更があった場合に管理情報ＤＢ５１２を更新したりする。

［リソース配分を行う場面］
図１０の（２）に示すように、リソースを配分する場面について説明する。具体的には、ＩＣＳソフトウェア５０１が、リソースを増設したり減設したりする場面について説明する。図１０の（２）に示すように、リソースを配分する場面については、ＩＣＳ運用者により利用される。なお、図１０の（２）に示すリソースを配分する場面については、クラウドシステムを利用しているＡＳＰ運用者が存在することが前提となる。

この場合、例えば、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者各々についての利用状況情報をオペレータ端末６０１から受信すると、ＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４各々から、全ＡＳＰ運用者について利用状況情報を収集する。そして、ＩＣＳソフトウェア５０１は、収集した利用状況情報をオペレータ端末６０１に出力する。

そして、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２にリソース要件を要求する指示をオペレータ端末６０１から受信すると、全ＡＳＰ運用者についての利用状況情報と制約条件とをＲＡＦ５０２に出力し、ＲＡＦ５０２にリソース要件を要求する。

そして、ＲＡＦ５０２は、ＩＣＳソフトウェア５０１から受信した利用状況情報と制約条件とに基づいてＡＳＰ運用者ごとのリソース要件を推定し、推定結果となるＡＳＰ運用者ごとのリソース要件をＩＣＳソフトウェア５０１に出力する。そして、ＩＣＳソフトウェア５０１は、ＲＡＦ５０２からＡＳＰ運用者ごとのリソース要件を受信すると、オペレータ端末６０１に出力する。

ここで、ＩＣＳ運用者は、ＡＳＰ運用者ごとのリソース要件を確認し、増設・減設が必要なＡＳＰ運用者を１人選択し、オペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。なお、増設・減設が必要なＡＳＰ運用者がいない場合には、処理終了となる。

そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とから空きリソース情報を収集し、ＩＣＳ運用者により選択されたＡＳＰ運用者についての利用状況情報と空きリソース情報とをオペレータ端末６０１に出力する。

ここで、ＩＣＳ運用者は、オペレータ端末６０１に出力された情報を確認し、任意のリソース配分計算を実行するアルゴリズムを選択し、オペレータ端末６０１からＩＣＳソフトウェア５０１にリソース配分計算を行う指示を出力する。

そして、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により選択されたアルゴリズムを用いて、リソース配分計算を行い、リソース配分計算により得られたリソース割当をオペレータ端末６０１に出力する。

そして、ＩＣＳ運用者は、オペレータ端末６０１に出力されたリソース割当を確認し、リソース割当を実行する指示をオペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。

そして、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により指示されたリソース割当をＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４に出力する。また、その後、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とから処理結果を受信し、受信した処理結果をオペレータ端末６０１に出力する。その後、ＩＣＳ運用者は、オペレータ端末６０１に出力された処理結果を確認する。

なお、上述の説明では、ＩＣＳソフトウェア５０１が、ＩＣＳ運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ＩＣＳソフトウェア５０１は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ＩＣＳ運用者が、増設・減設が必要なＡＳＰ運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ＩＣＳソフトウェア５０１が、増設・減設が必要なＡＳＰ運用者を識別し、識別したＡＳＰ運用者各々について一連の処理を実行しても良い。

［新設を実行する場面］
図１０の（３）に示すように、新設を実行する場面について説明する。具体的には、ＩＣＳソフトウェア５０１が、新たなＡＳＰ運用者に新規にリソースを割り当てる場面について説明する。図１０の（３）に示すように、新設を実行する場合については、ＩＣＳ運用者により利用される。なお、図１０の（３）に示す新設を実行する場面については、ＡＳＰ運用者により制約条件が制約条件ＤＢ５１１に登録された後、新設が実行されていないことを前提として説明する。言い換えると、新設処理待ちのＡＳＰ運用者がある場合を用いて説明する。

この場合、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により、新設処理待ちのＡＳＰ運用者の一覧を要求されると、要求された一覧をオペレータ端末６０１に出力する。

ここで、ＩＣＳ運用者は、新設処理待ちのＡＳＰ運用者一覧から、新設を実行するＡＳＰ運用者を選択し、オペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。なお、新設処理待ちのＡＳＰ運用者がいない場合には、処理が終了することになる。

そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とから空きリソース情報を収集し、収集した空きリソース情報をオペレータ端末６０１に出力する。

そして、ＩＣＳ運用者は、オペレータ端末６０１に出力された空きリソース情報を確認し、リソース配分計算を実行するアルゴリズムを選択し、オペレータ端末６０１からＩＣＳソフトウェア５０１にリソース配分計算を行う指示を送信する。

そして、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により選択されたＡＳＰ運用者について、ＩＣＳ運用者により選択されたアルゴリズムを用いてリソース配分計算を行い、計算結果となるリソース割当をオペレータ端末６０１に出力する。

ここで、ＩＣＳ運用者は、オペレータ端末６０１に出力されたリソース割当を確認し、リソース割当を実行する指示をオペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。その後、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とにリソース割当を出力し、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とから処理結果を受信し、受信した処理結果をオペレータ端末６０１に出力する。そして、ＩＣＳ運用者は、オペレータ端末６０１に出力された処理結果を確認する。

なお、上述の説明では、ＩＣＳソフトウェア５０１が、ＩＣＳ運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ＩＣＳソフトウェア５０１は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ＩＣＳ運用者が、新設が必要なＡＳＰ運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ＩＣＳソフトウェア５０１が、新規割当要求を受信すると、新設することを要求されたＡＳＰ運用者について自動的に一連の処理を実行しても良い。

［廃止を実行する場面］
図１０の（４）に示すように、廃止を実行する場面について説明する。具体的には、ＩＣＳソフトウェア５０１が、ＡＳＰ運用者に新規にリソースを割り当てる場面について説明する。図１０の（３）に示すように、新設を実行する場合については、ＩＣＳ運用者により利用される。なお、図１０の（３）に示す新設を実行する場面については、ＡＳＰ運用者により、ＡＳＰ運用者廃止が登録されているが、未だ廃止されていない場合を前提として説明する。言い換えると、廃止待ちのＡＳＰ運用者がある場合を用いて説明する。

この場合、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により、廃止処理待ちのＡＳＰ運用者の一覧を要求されると、要求された一覧をオペレータ端末６０１に出力する。

ここで、ＩＣＳ運用者は、廃止処理待ちのＡＳＰ運用者の一覧から、廃止を実行するＡＳＰ運用者を選択し、オペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。なお、廃止処理待ちのＡＳＰ運用者がいない場合には、処理が終了することになる。

そして、ＩＣＳソフトウェア５０１は、廃止するＡＳＰ運用者についての利用状況情報をＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４から収集し、収集した利用状況情報をオペレータ端末６０１に出力する。

そして、ＩＣＳ運用者は、オペレータ端末６０１に出力された利用状況情報を確認し、廃止を実行するリソース割当を実行する指示をオペレータ端末６０１からＩＣＳソフトウェア５０１に出力する。

そして、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により選択されたリソース割当を
ＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４に出力し、ＤＣ−ＯＰＳ６０３とＮＷ−ＯＰＳ６０４とから処理結果を受信し、受信した処理結果をオペレータ端末６０１に出力する。その後、ＩＣＳ運用者は、オペレータ端末６０１に出力された処理結果を確認する。

なお、上述の説明では、ＩＣＳソフトウェア５０１が、ＩＣＳ運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ＩＣＳソフトウェア５０１は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ＩＣＳ運用者が、廃止が必要なＡＳＰ運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ＩＣＳソフトウェア５０１が、割当廃止要求を受信すると、廃止することが要求されたＡＳＰ運用者について自動的に一連の処理を実行しても良い。

［制約条件を登録する場面］
図１０の（５）に示すように、制約条件を登録する場面について説明する。具体的には、ＩＣＳソフトウェア５０１の制約条件ＤＢ５１１に、ＡＳＰ運用者ごとの制約条件を格納する場面について説明する。図１０の（５）に示すように、制約条件を登録する場面については、ＡＳＰ運用者により利用される。

この場合、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者により用いられるＡＳＰ端末６０２から、制約条件を含む新規割当要求を受信する。ここで、ＩＣＳソフトウェア５０１は、例えば、受信した制約条件を制約条件ＤＢ５１１に格納すると共に、受信した旨の返信をＡＳＰ端末６０２に出力する。その後、例えば、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力された返信を確認する。

また、ここで、例えば、ＡＳＰ運用者は、ＡＳＰ運用者により用いられるＡＳＰ端末６０２から、登録済みのＡＳＰ運用者の一覧をＩＣＳソフトウェア５０１に要求する。すると、ＩＣＳソフトウェア５０１は、登録済みのＡＳＰ運用者の一覧をＡＳＰ端末６０２に出力する。

そして、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力された登録済みのＡＳＰ運用者一覧を確認し、制約条件を登録したＡＳＰ運用者を選択し、利用状況情報の確認をＩＣＳソフトウェア５０１に要求する。すると、ＩＣＳソフトウェア５０１は、選択されたＡＳＰ運用者についての利用状況情報を収集し、収集した利用状況情報をＡＳＰ端末６０２に出力する。

その後、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力された利用状況情報を確認し、選択したＡＳＰ運用者にリソースが割り当てられていれば完了となる。一方、ＡＳＰ運用者は、割り当てられていなかった場合には、再度一連の処理を実行する。

［ＡＳＰ運用者を削除する場面］
図１０の（６）に示すように、クラウドサービス利用中のＡＳＰ運用者を削除する場面について説明する。言い換えると、制約条件が制約条件ＤＢ５１１に東独されているＡＳＰ運用者のユーザＩＤを削除する場合について説明する。図１０の（６）に示すように、ＡＳＰ運用者の削除する場面については、ＡＳＰ運用者により利用される。なお、図１０の（６）に示す場面については、クラウドシステムにより提供されるリソースを利用しているＡＳＰ運用者がある場合を前提として説明する。

この場合、例えば、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者により用いられるＡＳＰ端末６０２から、クラウドシステムにより提供されるリソースを利用中のＡＳＰ運用者の一覧が要求されると、制約条件ＤＢ５１１に制約条件が登録されたＡＳＰ運用者の一覧を出力する。

すると、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力されたＡＳＰ運用者の一覧を確認し、ＡＳＰ運用者を１人選択して廃止する旨の指示をＡＳＰ端末６０２からＩＣＳソフトウェア５０１に出力する。

そして、ＩＣＳソフトウェア５０１は、ＡＳＰ端末６０２から廃止する旨の指示を受信すると、受信した旨を返信するとともに、廃止対象となるＡＳＰ運用者についての制約条件を制約条件ＤＢ５１１から削除する。その後、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力された返信を確認する。

また、ここで、例えば、ＡＳＰ運用者は、ＡＳＰ運用者により用いられるＡＳＰ端末６０２から、登録済みのＡＳＰ運用者の一覧をＩＣＳソフトウェア５０１に要求する。すると、ＩＣＳソフトウェア５０１は、登録済みのＡＳＰ運用者の一覧をＡＳＰ端末６０２に出力する。そして、ＡＳＰ運用者は、ＡＳＰ端末６０２に出力された登録済みのＡＳＰ運用者一覧を確認し、廃止したＡＳＰ運用者がなくなっていることを確認する。

［利用状況を確認する場面］
図１０の（７）に示すように、利用状況を確認する場面について説明する。図１０の（７）に示すように、利用状況を確認する場面については、ＡＳＰ運用者やＩＣＳ運用者により利用される。なお、図１０の（７）に示す場面については、クラウドシステムにより提供されるリソースを利用しているＡＳＰ運用者がある場合を前提として説明する。

この場合、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により用いられるオペレータ端末６０１から、ＡＳＰ運用者の一覧が要求されると、制約条件ＤＢ５１１に制約条件が登録されたＡＳＰ運用者の一覧をオペレータ端末６０１に出力する。

そして、ＩＣＳ運用者は、オペレータ端末６０１に出力されたＡＳＰ運用者の一覧からＡＳＰ運用者を１人選択し、選択したＡＳＰ運用者についての利用状況情報をＩＣＳソフトウェア５０１に要求する。

すると、ＩＣＳソフトウェア５０１は、ＩＣＳ運用者により選択されたＡＳＰ運用者について、ＲＡＦ５０２にリソース要件の判定を依頼し、ＲＡＦ５０２による処理結果をオペレータ端末６０１に出力する。その後、ＩＣＳ運用者は、オペレータ端末６０１に出力されたリソース要件を確認する。

なお、上述の説明では、ＩＣＳ運用者を例に説明したが、ＡＳＰ運用者が実行する場合であっても同様である。また、上述の説明では、ＩＣＳソフトウェア５０１が、ＲＡＦ５０２にリソース要件の判定を依頼し、ＲＡＦ５０２による処理結果となるリソース要件を出力する場合を用いて説明したが、これに限定されるものではない。例えば、ＩＣＳソフトウェア５０１は、割り当てられているリソース全てが制約条件を満たしているかを確認し、確認結果をオペレータ端末６０１に出力しても良く、任意の情報を出力して良い。

［実施例２におけるインタークラウドサーバによる処理の流れ］
以下では、シーケンス図を用いて、実施例２におけるインタークラウドサーバ５００による処理の流れの一例について説明する。具体的には、新設時における処理の流れと、リソースの増設・減設時における処理の流れと、リソースの廃止時における処理の流れとを順に説明する。なお、以下に説明する各処理の流れは、図７〜図９を用いて説明した動作概要に対応する。

［新設時における処理の流れ］
図１１は、実施例２における新設時における処理の流れの一例を示すシーケンス図である。図１１に示す例では、説明の便宜上、インタークラウドサーバ５００のＩＣＳソフトウェア５０１に加えて、１つのＡＳＰ端末６０２と、２つのＤＣ−ＯＰＳ６０３と、２つのＮＷ−ＯＰＳ６０４とを用いて説明する。

図１１に示すように、ＡＳＰ運用者がＡＳＰ端末６０２からＩＣＳソフトウェア５０１に制約条件を入力すると（ステップＳ３０１）、ＩＣＳソフトウェア５０１は、受け付け完了をＡＳＰ端末６０２に出力する（ステップＳ３０２）。つまり、ＩＣＳソフトウェア５０１は、制約条件を受け付けた旨をＡＳＰ端末６０２に出力する。

そして、ＩＣＳソフトウェア５０１は、図１１の「Ｌｏｏｐ．１」に示すように、全ＤＣ−ＯＰＳ６０３について空きリソース情報を収集する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１に対して、ＤＣ−ＯＰＳ６０３−１により管理されるＤＣ６０５の空きリソース情報を要求する（ステップＳ３０３）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１から空きリソース情報を収集する（ステップＳ３０４）。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２に対して、ＤＣ−ＯＰＳ６０３−２により管理されるＤＣ６０５の空きリソース情報を要求する（ステップＳ３０５）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２から空きリソース情報を収集する（ステップＳ３０６）。

また、ＩＣＳソフトウェア５０１は、図１１の「Ｌｏｏｐ．２」に示すように、全ＮＷ−ＯＰＳ６０４について空きリソース情報を収集する。具体的には、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１に対して、ＮＷ−ＯＰＳ６０４−１により管理されるＮＷ６０８の空きリソース情報を要求する（ステップＳ３０７）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１から空きリソース情報を収集する（ステップＳ３０８）。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２に対して、ＮＷ−ＯＰＳ６０４−２により管理されるＮＷ６０８の空きリソース情報を要求する（ステップＳ３０９）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２から空きリソース情報を収集する（ステップＳ３１０）。

そして、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者各々について、リソース分散計算を行う（ステップＳ３１１）。つまり、ＩＣＳソフトウェア５０１は、所定のアルゴリズムに基づいて、リソースの過不足を解消するリソース割当を決定する。例えば、ＩＣＳソフトウェア５０１は、空きリソース情報により示される空きリソースから、新規割当要求に含まれる制約条件を満たす任意のリソースを選択し、選択した任意のリソースを割り当てるリソース割当を決定する。

そして、ＩＣＳソフトウェア５０１は、図１１の「Ｌｏｏｐ．３」に示すように、配分が必要な全ＤＣ−ＯＰＳ６０３に対して、リソース割当を出力する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソース割当を出力し（ステップＳ３１２）、ＤＣ−ＯＰＳ６０３−１から結果を取得する（ステップＳ３１３）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２にリソース割当を出力し（ステップＳ３１４）、ＤＣ−ＯＰＳ６０３−２から結果を取得する（ステップＳ３１５）。

また、ＩＣＳソフトウェア５０１は、図１１の「Ｌｏｏｐ．４」に示すように、配分が必要な全ＮＷ−ＯＰＳ６０４に対して、リソース割当を出力する。例えば、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソース割当を出力し（ステップＳ３１６）、ＮＷ−ＯＰＳ６０４−１から結果を取得する（ステップＳ３１７）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２にリソース割当を出力し（ステップＳ３１８）、ＮＷ−ＯＰＳ６０４−２から結果を取得する（ステップＳ３１９）。

［増設・減設時における処理の流れ］
図１２は、実施例２における増設・減設時における処理の流れの一例を示すシーケンス図である。図１２に示す例では、説明の便宜上、インタークラウドサーバ５００のＩＣＳソフトウェア５０１とＲＡＦ５０２とに加えて、２つのＤＣ−ＯＰＳ６０３と、２つのＮＷ−ＯＰＳ６０４とを用いて説明する。

ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．１」に示すように、全ＤＣ−ＯＰＳ６０３について、ＡＳＰ運用者ごとの利用状況情報を収集する。具体的には、図１２の「Ｌｏｏｐ．２」に示すように、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ４０１）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ４０２）。また、同様に、図１２の「Ｌｏｏｐ．３」に示すように、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ４０３）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ４０４）。

また、ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．４」に示すように、全ＮＷ−ＯＰＳ６０４について、ＡＳＰ運用者ごとの利用状況情報を収集する。具体的には、図１２の「Ｌｏｏｐ．５」に示すように、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ４０５）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ４０６）。また、同様に、図１２の「Ｌｏｏｐ．６」に示すように、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ４０７）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ４０８）。

そして、ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．７」に示すように、全ＡＳＰ運用者について、ＲＡＦ５０２にリソース要件を推定させる。具体的には、ＩＣＳソフトウェア５０１は、ＡＳＰ運用者ごとの利用状況情報と制約条件とをＲＡＦ５０２に出力する（ステップＳ４０９）。その後、ＲＡＦ５０２は、ＡＳＰ運用者に割り当てられているリソースについての利用状況情報と制約条件とに基づいて、ＡＳＰ運用者に割り当てることが推奨されるリソースのリソース要件を推定する（ステップＳ４１０）。例えば、ＲＡＦ５０２は、利用状況情報を解析することで、ＡＳＰ運用者が必要とするリソース量を推定し、制約条件に合致して推定したリソース量を満たすリソース要件を推定する。その後、ＲＡＦ５０２は、推定結果となるリソース要件の計算結果をＩＣＳソフトウェア５０１に出力する。

その後、ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．８」に示すように、リソースの増設や減設が必要となった全ＡＳＰ運用者について、リソース割当を決定し、ＤＣ−ＯＰＳ６０３やＮＷ−ＯＰＳ６０４に出力する。すなわち、ＲＡＦ５０２による計算結果となるリソース要件と、利用状況情報により示される利用中のリソースとの間に過不足があるＡＳＰ運用者各々について、過不足を解消するリソース割当を決定し、決定したリソース割当をリソースの管理装置に出力する。

具体的には、図１２の「Ｌｏｏｐ．９」に示すように、ＩＣＳソフトウェア５０１は、全ＤＣ−ＯＰＳ６０３について空きリソース情報を収集する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１に対して、ＤＣ−ＯＰＳ６０３−１により管理されるＤＣ６０５の空きリソース情報を要求する（ステップＳ４１１）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１から空きリソース情報を収集する（ステップＳ４１２）。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２に対して、ＤＣ−ＯＰＳ６０３−２により管理されるＤＣ６０５の空きリソース情報を要求する（ステップＳ４１３）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２から空きリソース情報を収集する（ステップＳ４１４）。

また、図１２の「Ｌｏｏｐ．１０」に示すように、ＩＣＳソフトウェア５０１は、全ＮＷ−ＯＰＳ６０４について空きリソース情報を収集する。具体的には、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１に対して、ＮＷ−ＯＰＳ６０４−１により管理されるＮＷ６０８の空きリソース情報を要求する（ステップＳ４１５）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１から空きリソース情報を収集する（ステップＳ４１６）。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２に対して、ＮＷ−ＯＰＳ６０４−２により管理されるＮＷ６０８の空きリソース情報を要求する（ステップＳ４１７）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２から空きリソース情報を収集する（ステップＳ４１８）。

そして、ＩＣＳソフトウェア５０１は、ソースの増設や減設が必要となった全ＡＳＰ運用者について、リソース分散計算を行う（ステップＳ４１９）。

そして、ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．１１」に示すように、配分が必要な全ＤＣ−ＯＰＳ６０３に対して、リソース割当を出力する。つまり、リソースを再配分する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソース割当を出力し（ステップＳ４２０）、ＤＣ−ＯＰＳ６０３−１から結果を取得する（ステップＳ４２１）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２にリソース割当を出力し（ステップＳ４２２）、ＤＣ−ＯＰＳ６０３−２から結果を取得する（ステップＳ４２３）。

また、ＩＣＳソフトウェア５０１は、図１２の「Ｌｏｏｐ．１２」に示すように、配分が必要な全ＮＷ−ＯＰＳ６０４に対して、リソース割当を出力する。つまり、リソースを再配分する。例えば、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソース割当を出力し（ステップＳ４２４）、ＮＷ−ＯＰＳ６０４−１から結果を取得する（ステップＳ４２５）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２にリソース割当を出力し（ステップＳ４２６）、ＮＷ−ＯＰＳ６０４−２から結果を取得する（ステップＳ４２７）。

［廃止時における処理の流れ］
図１３は、実施例２における廃止時における処理の流れの一例を示すシーケンス図である。図１３に示す例では、説明の便宜上、インタークラウドサーバ５００のＩＣＳソフトウェア５０１に加えて、１つのＡＳＰ端末６０２と、２つのＤＣ−ＯＰＳ６０３と、２つのＮＷ−ＯＰＳ６０４とを用いて説明する。

図１３に示すように、ＡＳＰ運用者がＡＳＰ端末６０２からＩＣＳソフトウェア５０１に割当廃止要求を入力すると（ステップＳ５０１）、ＩＣＳソフトウェア５０１は、受け付け完了をＡＳＰ端末６０２に出力する（ステップＳ５０２）。つまり、ＩＣＳソフトウェア５０１は、割当廃止要求を受け付けた旨をＡＳＰ端末６０２に出力する。

そして、ＩＣＳソフトウェア５０１は、図１３の「Ｌｏｏｐ．１」に示すように、全ＤＣ−ＯＰＳ６０３について、ＡＳＰ運用者ごとの利用状況情報を収集する。具体的には、ＩＣＳソフトウェア５０１は、割当廃止要求による廃止の対象となるＡＳＰ運用者について、ＡＳＰ運用者ごとの利用状況情報を収集する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ５０３）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ５０４）。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ５０５）。そして、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ５０６）。

そして、ＩＣＳソフトウェア５０１は、図１３の「Ｌｏｏｐ．２」に示すように、全ＮＷ−ＯＰＳ６０４について、ＡＳＰ運用者ごとの利用状況情報を収集する。具体的には、ＩＣＳソフトウェア５０１は、割当廃止要求による廃止の対象となるＡＳＰ運用者について、ＡＳＰ運用者ごとの利用状況情報を収集する。例えば、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ５０７）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ５０８）。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２に対して、ＡＳＰ運用者ごとの利用状況情報を要求する（ステップＳ５０９）。そして、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２からＡＳＰ運用者ごとの利用状況情報を収集する（ステップＳ５１０）。

そして、ＩＣＳソフトウェア５０１は、図１３の「Ｌｏｏｐ．３」に示すように、指定ＡＳＰ運用者が使用中の全ＤＣ−ＯＰＳ６０３について、リソースの割当を廃止するリソース割当を出力する。言い換えると、ＩＣＳソフトウェア５０１は、割当廃止要求による廃止の対象となるＡＳＰ運用者にリソースを割り当てているＤＣ−ＯＰＳ６０３各々に対して、リソースの割当を廃止するリソース割当を出力する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソース割当を出力し（ステップＳ５１１）、ＤＣ−ＯＰＳ６０３−１から結果を取得する（ステップＳ５１２）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−１にリソースの割当を廃止するリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＤＣ−ＯＰＳ６０３−２にリソース割当を出力し（ステップＳ５１３）、ＤＣ−ＯＰＳ６０３−２から結果を取得する（ステップＳ５１４）。

また、ＩＣＳソフトウェア５０１は、図１３の「Ｌｏｏｐ．４」に示すように、指定ＡＳＰ運用者が使用中の全ＮＷ−ＯＰＳ６０４について、リソースの割当を廃止するリソース割当を出力する。言い換えると、ＩＣＳソフトウェア５０１は、割当廃止要求による廃止の対象となるＡＳＰ運用者にリソースを割り当てているＮＷ−ＯＰＳ６０４各々に対して、リソースの割当を廃止するリソース割当を出力する。例えば、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソース割当を出力し（ステップＳ５１５）、ＮＷ−ＯＰＳ６０４−１から結果を取得する（ステップＳ５１６）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−１にリソースの割当を廃止するリソース割当を実行させ、実行結果を取得する。また、同様に、ＩＣＳソフトウェア５０１は、ＮＷ−ＯＰＳ６０４−２にリソース割当を出力し（ステップＳ５１７）、ＮＷ−ＯＰＳ６０４−２から結果を取得する（ステップＳ５１８）。

［実施例２において用いられる各種データのデータ構造の一例］
実施例２において用いられる各種データのデータ構造の一例について説明する。以下では、管理情報の一例と、制約条件の一例と、ＤＣについての利用状況情報の一例と、ＤＣについての空きリソース情報の一例と、ＤＣについてのリソース割当の一例と、ＮＷについての利用状況情報の一例と、ＮＷについての空きリソース情報の一例と、ＮＷについてのリソース割当の一例とを順に説明する。

なお、実施例２において用いられる各種データのデータ構造の一例について説明する際には、データ構造に含まれるテーブル各々を識別する「テーブル番号」と、テーブルに含まれる要素を示す「要素」と、テーブルに要素がいくつあるかを示す「個数」と、要素についての説明となる「備考」とを用いて説明する。

［管理情報］
図１４及び図１５を用いて、実施例２における管理情報ＤＢ５１２に記憶される管理情報の詳細な一例を示す。管理情報ＤＢ５１２は、以下に説明するように、ＤＣ−ＯＰＳ６０３についての管理情報を記憶し、ＮＷ−ＯＰＳ６０４についての管理情報を記憶する。

図１４は、実施例２におけるＤＣ−ＯＰＳについての管理情報の一例を示す図である。図１４のテーブル番号「１」に示すように、管理情報ＤＢ５１２は、ＤＣ−ＯＰＳ管理情報リストを記憶する。ここで、ＤＣ−ＯＰＳ管理情報リストには、ＤＣ−ＯＰＳ６０３についての管理情報であるＤＣ−ＯＰＳ管理情報が複数含まれる。すなわち、ＤＣ−ＯＰＳ管理情報リストには、ＤＣ−ＯＰＳ６０３とＤＣ６０５との対応表が複数含まれる。ＤＣ−ＯＰＳ管理情報は、例えば、ＩＣＳソフトウェア５０１の初期設定として入力される。

ＤＣ−ＯＰＳ管理情報の詳細な一例について説明する。図１４のテーブル番号「２」に示すように、ＤＣ−ＯＰＳ管理情報は、例えば、１つの「ＤＣ−ＯＰＳ名」と、１つの「ＤＣ−ＯＰＳのＵＲＬ」と、１つの「アクセスＩＤ」と、１つの「パスワード」と、１つの「コメント」と、１つの「フラグ」とを含む。

ここで、「ＤＣ−ＯＰＳ名」は、ＤＣ−ＯＰＳの識別名である。「ＤＣ−ＯＰＳのＵＲＬ」は、ＤＣ−ＯＰＳ６０３にアクセスするためのＵＲＬである。「アクセスＩＤ」は、ＤＣ−ＯＰＳ６０３にアクセスするためのアクセスＩＤである。「パスワード」は、ＤＣ−ＯＰＳ６０３にアクセスするためのパスワードである。「コメント」は、ＤＣ−ＯＰＳ６０３の注釈等情報である。「フラグ」は、ＤＣ−ＯＰＳ６０３の有効、無効などの情報である。

例えば、ＤＣ−ＯＰＳ管理情報は、ＤＣ−ＯＰＳ名「Ｎ社の管理装置」と、ＤＣ−ＯＰＳのＵＲＬ「www.123〜」と、アクセスＩＤ「ＵＳＥＲ０００１」と、パスワード「sakura」と、コメント「使い勝手が良い」と、フラグ「有効」を含む。この場合、ＤＣ−ＯＰＳ管理情報には、例えば、Ｎ社の管理装置というＤＣ−ＯＰＳについて、ＵＲＬが「www.123〜」であることが含まれ、アクセスする際にはアクセスＩＤ「ＵＳＥ０００１」とパスワード「sakura」とを用いることが含まれ、「使い勝手が良い」というコメントが含まれ、「有効」であるというフラグが含まれる。

図１５は、実施例２におけるＮＷ−ＯＰＳについての管理情報の一例を示す図である。図１５のテーブル番号「３」に示すように、管理情報ＤＢ５１２は、ＮＷ−ＯＰＳ管理情報リストを記憶する。ここで、ＮＷ−ＯＰＳ管理情報リストには、ＮＷ−ＯＰＳ６０４についての管理情報であるＮＷ−ＯＰＳ管理情報が複数含まれる。すなわち、ＮＷ−ＯＰＳ管理情報リストには、ＮＷ−ＯＰＳ６０４とＮＷ６０８との対応表が複数含まれる。ＮＷ−ＯＰＳ管理情報は、例えば、ＩＣＳソフトウェア５０１の初期設定として入力される。

ＮＷ−ＯＰＳ管理情報の詳細な一例ついて説明する。図１４のテーブル番号「４」に示すように、ＮＷ−ＯＰＳ管理情報は、例えば、１つの「ＮＷ−ＯＰＳ名」と、１つの「ＮＷ−ＯＰＳのＵＲＬ」と、１つの「アクセスＩＤ」と、１つの「パスワード」と、１つの「コメント」と、１つの「フラグ」とを含む。

［制約条件］
図１６は、実施例２における制約条件ＤＢに記憶された制約条件の一例を示す図である。図１６のテーブル番号「５」に示すように、制約条件ＤＢ５１１は、制約条件リストを記憶する。ここで、制約条件リストには、ＡＳＰ運用者ごとの制約条件となる制約条件テーブルが複数含まれる。制約条件リストは、例えば、ＡＳＰ運用者によって入力される。

制約条件テーブルの詳細な一例について説明する。図１６のテーブル番号「６」に示すように、制約条件テーブルは、例えば、１つの「ユーザＩＤ」と、１つ又は複数の「ＶＭリスト」と、１つ又は複数の「ユーザ所在地」と、１つの「ＮＷ帯域」と、１つの「ＮＷ遅延」と、１つの「料金上限」と、１つ又は複数の「ＤＣ地域指定」と、１つ又は複数の「セキュリティ」と、１つの「ＤＣ稼働率」とを含む。

ここで、「ユーザＩＤ」は、ＡＳＰ運用者を識別するユーザＩＤである。「ＶＭリスト」は、ＡＳＰ運用者により要求されたＶＭのリストを示す。なお、ＶＭリストの詳細については、後述する。「ユーザ所在地」は、リソースの割当を要求したユーザの所在地を示す。「ＮＷ帯域」は、要求されたネットワークの帯域を示す。「料金上限」は、ユーザが許容する料金の上限値を示す。「ＤＣ地域指定」は、割り当て可能となるＤＣ６０５の地域についての情報を示す。「セキュリティ」は、リソースに備えられたセキュリティについての情報を示す。「ＤＣ稼働率」は、割当可能となるＤＣ６０５の許容最低稼働率を示す。「ＮＷ遅延」は、ネットワークの遅延量として許容される値を示す。

例えば、制約条件テーブルは、ユーザＩＤ「ＵＳＥＲ０００１」と、ＶＭリスト「Ａ」と「Ｂ」と、ユーザ所在地「東京」「大阪」と、ＮＷ帯域「各ユーザ−ＤＣまでの帯域は１００Ｍｂｐｓ」と、ＮＷ遅延「１ｓｅｃ」と、料金上限「月額２００万以下」と、ＤＣ地域指定「日本国内」と、セキュリティ「特になし」と、ＤＣ稼働率「９９．９９％」を含む。この場合、制約条件テーブルは、ユーザＩＤ「ＵＳＥＲ０００１」についての制約条件を含む。具体的には、制約条件テーブルは、制約条件として、「ＵＳＥＲ０００１」にＶＭリスト「Ａ」と「Ｂ」とにより識別されるＶＭが要求されることと、「各ユーザ−ＤＣまでの帯域は１００Ｍｂｐｓ」であることを含む。また、制約条件テーブルは、制約条件として、ＮＷ遅延「１ｓｅｃ」以内となることと、料金上限が「月額２００万以下」となることと、「日本国内」にあるＤＣであることと、ＤＣ稼働率が「９９．９９％」であることとを含む。

［ＤＣについての利用状況情報］
図１７は、実施例２におけるＤＣについての利用状況情報の一例を示す図である。図１７のテーブル番号「７」に示すように、ＤＣ６０５についての利用状況情報には、ＤＣ６０５の利用状況を示すＤＣ利用状況テーブルが複数含まれる。

ＤＣ利用状況テーブルの詳細な一例について説明する。図１７のテーブル番号「８」に示すように、ＤＣ利用状況テーブルは、１つの「ユーザＩＤ」と、１つ又は複数の「ＤＣリソース」と、１つの「利用料金」とを含む。ここで、「ＤＣリソース」は、ＤＣ６０５のリソースを示す。なお、ＤＣ利用状況テーブルに含まれるＤＣリソースは、ユーザＩＤにより識別されるＡＳＰ運用者により利用されているＤＣ６０５のリソースを示す。「ＤＣリソース」の詳細については、後述する。

例えば、ＤＣ利用状況テーブルは、ユーザＩＤ「ＵＳＥＲ０００１」と、利用料金「合計で２４万／月」を含む。この場合、ＤＣ利用状況テーブルは、「ＵＳＥＲ０００１」により利用されている「ＤＣリソース」と、「ＵＳＥＲ０００１」により利用されているＤＣ６０５のリソースの料金が「合計で２４万／月」であることを含む。

［ＤＣについての空きリソース情報］
図１８は、実施例２におけるＤＣについての空きリソース情報の一例を示す図である。図１８のテーブル番号「９」に示すように、ＤＣ６０５についての空きリソース情報であるＤＣ空きリソース情報は、ＤＣリソースを複数含む。

図１９は、実施例２におけるＤＣリソース情報の一例を示す図である。図１９のテーブル番号「１０」に示すように、ＤＣリソースには、ＤＣ６０５を識別する「ＤＣ名」が１つ含まれ、ＤＣ６０５の所在地を示す「ＤＣ所在地」が１つ含まれ、ＤＣ６０５を管理するＤＣ−ＯＰＳ６０３の「ＤＣ−ＯＰＳ名」が１つ含まれ、ＤＣ６０５により提供されるリソースを示す「ＶＭリスト」が複数含まれる。

ＶＭリストの詳細な一例について説明する。図１９のテーブル番号「１１」に示すように、ＶＭリストは、ＶＭのタイプを示す「ＶＭタイプ」が１つ含まれ、ＶＭの数を示す「ＶＭ数」が１つ含まれ、ＶＭの使用率を示す「使用率」が１つ含まれる。例えば、ＶＭリストは、ＶＭタイプ「Ｔｙｐｅ１」とＶＭ数「１０台」と使用率「５０％」とを含む。この場合、ＶＭリストには、Ｔｙｐｅ１のＶＭが１０台あり、そのうちの５０％のＶＭが使用されていることが含まれる。

ＶＭタイプの詳細な一例について説明する。図１９のテーブル番号「１２」に示すように、ＶＭタイプは、ＶＭタイプのタイプ名を示す「ＶＭタイプ名」と、ＶＭのコア数を示す「コア数」と、ＶＭのメモリ容量を示す「メモリ」と、ＶＭのＨＤＤ容量を示す「ＨＤＤ」と、ＶＭの料金を示す「料金」を１つ含む。すなわち、ＶＭタイプは、ＤＣ６０５により提要されるＶＭについての詳細を含む。

［ＤＣについてのリソース割当］
図２０は、実施例２におけるＤＣについてのリソース割当の一例を示す図である。図２０に示す例では、ＡＳＰ運用者ごとのリソース割当を例として示した。図２０のテーブル番号「１３」に示すように、ＤＣのリソース割当には、リソースの割当の対象となるＡＳＰ運用者を示す「ユーザＩＤ」が１つ含まれる。また、割り当てられるリソースを示す「ＶＭ割当」が複数含まれる。

ここで、「ＶＭ割当」各々には、リソース割当が実行されるＤＣ６０５を示す「ＤＣ名」が１つと、ＶＭのタイプごとの割当を示す「タイプ別ＶＭ割当」を複数含む。「タイプ別ＶＭ割当」は、ＶＭのタイプごとに、リソース割当前の「ＶＭリスト」と、リソース割当後の「ＶＭリスト」とが含まれる。図２０に示すリソース割当では、ＡＳＰ運用者ごとに、複数のＤＣに対して、複数のＶＭの割り当てが行えるようになっている。

［ＮＷについての利用状況情報］
図２１は、実施例２におけるＮＷについての利用状況情報の一例を示す図である。図２１のテーブル番号「１４」に示すように、ＮＷ６０８についての利用状況情報には、ＮＷ６０８の利用状況を示すＮＷ利用状況テーブルが複数含まれる。

ＮＷ利用状況テーブルの詳細な一例について説明する。図２１のテーブル番号「１５」に示すように、ＮＷ利用状況テーブルは、１つの「ユーザＩＤ」と、１つ又は複数の「ＮＷリソース」と、１つの「利用料金」とを含む。ここで、「ＮＷリソース」は、ＮＷ６０８のリソースを示す。なお、ＮＷ利用状況テーブルに含まれるＮＷリソースは、ユーザＩＤにより識別されるＡＳＰ運用者により利用されているＮＷ６０８のリソースを示す。「ＮＷリソース」の詳細については、後述する。

［ＮＷについての空きリソース情報］
図２２は、実施例２におけるＮＷについての空きリソース情報の一例を示す図である。図２２のテーブル番号「１６」に示すように、ＮＷ６０８についての空きリソース情報であるＮＷ空きリソース情報は、ＮＷリソースを複数含む。

図２３は、実施例２におけるＮＷリソース情報の一例を示す図である。図２３のテーブル番号「１７」に示すように、ＮＷリソースには、ＮＷ６０８を識別する「ＮＷ名」が１つと、ＮＷ６０８を管理するＮＷ−ＯＰＳ６０４の「ＮＷ−ＯＰＳ名」が１つと、ＮＷ６０８により提供されるリソースを示す複数の「ＮＷリスト」とが含まれる。

なお、図２３に示す例では、ＮＷ名として、どこからどこまでのネットワークであるかを示す名称を用いる場合を示した。例えば、ＮＷ名「Ｅｎｄ−ｔｏ−Ｅｎｄ」は、ＤＣ６０５とユーザ端末６０７との間のネットワークと、ＤＣ６０５間のＮＷとの両方を含むネットワークを示す。

ＮＷリストの詳細な一例について説明する。図２３のテーブル番号「１８」に示すように、ＮＷリストは、ネットワークの始点を示す「始点」が１つと、ネットワークの終点を示す「終点」が１つと、ネットワークのタイプを示す「ＮＷタイプ」が１つと、ネットワークの数を示す「ＮＷ数」が１つと、ネットワークの使用率を示す「使用率」を１つ含む。なお、図２３のテーブル番号「１８」における「ＮＷ数」と「使用率」とは、「ＮＷタイプ」のネットワークの数と使用率とを示す。

ＮＷタイプの詳細な一例について説明する。図２３のテーブル番号「１９」に示すように、ＮＷタイプは、ネットワークのタイプ名を示す「ＮＷタイプ名」が１つと、ネットワークの帯域を示す「回線帯域」が１つと、ネットワークの遅延を示す「回線遅延」が１つと、ネットワークの料金である「料金」を１つ含む。

［ＮＷについてのリソース割当］
図２４は、実施例２におけるＮＷについてのリソース割当の一例を示す図である。図２４に示す例では、ＡＳＰ運用者ごとのリソース割当を例として示した。図２４のテーブル番号「２０」に示すように、ＮＷのリソース割当には、リソースの割当の対象となるＡＳＰ運用者を示す「ユーザＩＤ」が１つ含まれる。また、割り当てられるリソースを示す「ＮＷ割当」が複数含まれる。

ここで、「ＮＷ割当」各々には、リソース割当が実行されるＮＷ６０８を示す「ＮＷ名」が１つと、ＮＷのタイプごとの割当を示す「タイプ別ＮＷ割当」を複数含む。「タイプ別ＮＷ割当」は、ＮＷのタイプごとに、リソース割当後の「ＮＷリスト」が含まれる。図２４に示すリソース割当では、ＡＳＰ運用者ごとに、複数のＮＷに対して、複数のＮＷの割り当てが行えるようになっている。

［ＩＣＳソフトウェアによるリソース配分計算］
以下に、ＩＣＳソフトウェア５０１によるリソース配分計算の詳細について説明する。以下に詳細に説明するように、ＩＣＳソフトウェア５０１は、空きリソース情報や利用状況情報、制約条件、割当要求が入力されると、管理情報ＤＢ５１２に記憶された管理情報を用いてリソース配分計算を実行し、計算結果としてリソース割当を決定する。

［リソース配分計算の全体像］
図２５−１〜図２５−５は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示す図である。図２５−１〜図２５−５において、ＤＣ利用状況情報７０１と、ＤＣ空きリソース情報７０２と、ＮＷ利用状況情報７０３と、ＮＷ空きリソース情報７０４と、制約条件７０５と、割当要求情報７０６は、それぞれ、リソース配分計算を実行する際に入力される情報となる。また、図２５−１〜図２５−５において、ＤＣ利用可能リソース情報７１１と、ＮＷ利用可能リソース情報７１２と、ＤＣ条件による制約ＤＣリスト７１３と、ＮＷ条件による制約ＤＣリスト７１４と、ＶＭタイプ別ＤＣ候補リスト７１５と、ＶＭタイププランリスト７１６と、ＮＷ制約プランリスト７１７とは、リソース配分計算の過程において生成される情報となる。

なお、ＤＣ利用状況情報７０１は、ＤＣ６０５についての利用状況情報である。ＤＣ空きリソース情報７０２は、ＤＣ６０５についての空きリソース情報である。ＮＷ利用状況情報７０３は、ＮＷ６０８についての利用状況情報である。ＮＷ空きリソース情報７０４は、ＮＷ６０８についての空きリソース情報である。制約条件７０５は、ユーザごとの制約条件である。ＤＣ利用可能リソース情報７１１〜ＮＷ制約プランリスト７１７の詳細については、適宜後述する。

図２５−１のＤＣ利用可能リソース計算７２１に示すように、ＩＣＳソフトウェア５０１は、ＤＣ利用状況情報７０１とＤＣ空きリソース情報７０２とを用いて、ＤＣ６０５についての利用可能なリソースを示すＤＣ利用可能リソース情報７１１を生成する。つまり、ＩＣＳソフトウェア５０１は、空きリソース情報と利用状況情報とを統合し、ユーザごとのリソース割当を決定する際に用いることが可能なＤＣ６０５についてのリソースを特定可能な情報を生成する。

また、図２５−２のＮＷ利用可能リソース計算７２２に示すように、ＩＣＳソフトウェア５０１は、ＮＷ利用状況情報７０３とＮＷ空きリソース情報７０４とを用いて、ＮＷ６０８についての利用可能リソースを示すＮＷ利用可能リソース情報７１２を生成する。つまり、ＩＣＳソフトウェア５０１は、空きリソース情報と利用状況情報とを統合し、ユーザごとのリソース割当を決定する際に用いることが可能なＮＷ６０８についてのリソースを特定可能な情報を生成する。

そして、図２５−３の「ユーザのＤＣ制約条件によるＤＣ選択７２３」に示すように、ＩＣＳソフトウェア５０１は、ＤＣ利用可能リソース情報７１１と制約条件７０５とを用いて、制約条件７０５を満たすＤＣ６０５のリストである「ＤＣ条件による制約ＤＣリスト７１３」を生成する。

そして、図２５−３の「ユーザのＮＷ制約条件によるＤＣ選択７２４」に示すように、ＩＣＳソフトウェア５０１は、ＮＷ利用可能リソース情報７１２と、ＤＣ条件による制約ＤＣリスト７１３と、制約条件７０５とに基づいて、ＮＷ条件による制約ＤＣリスト７１４を生成する。つまり、ＩＣＳソフトウェア５０１は、制約条件のうちＮＷ６０８についての制約条件により、ユーザの所在地とＤＣ６０５との間で使用可能なＮＷ６０８を選択し、選択したＮＷ６０８のリストがＤＣ６０５に対応付けて登録されたリストとなるＮＷ条件による制約ＤＣリスト７１４を生成する。

そして、図２５−４の「ＶＭタイプ別ＤＣ候補リスト選択７２５」に示すように、ＩＣＳソフトウェア５０１は、ＤＣ利用可能リソース情報７１１と、ＮＷ条件による制約ＤＣリストと、割当要求情報とに基づいて、ＶＭタイプ別ＤＣ候補リストを生成する。つまり、ＩＣＳソフトウェア５０１は、ＶＭの割り当て要求により要求されるＶＭを確保できるか否かをＶＭタイプごとに確認し、ＶＭタイプごとに割り当て可能となるＤＣ６０５のリストとなるＶＭタイプ別ＤＣ候補リスト７１５を生成する。

そして、図２５−４の「ＶＭタイププラン選択７２６」に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイプごとのＤＣ候補の可能な組み合わせを列挙したプランリストであるＶＭタイププランリスト７１６を生成する。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストから、組み合わせ可能なＤＣ６０５を組み合わせたリストを生成する。

そして、図２５−５の「ＤＣ−ＤＣ間のＮＷ制約条件によるプラン選択７２７」に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイププランリスト７１６に含まれるプランにおいて使用されるＤＣ６０５間にて使用可能なＮＷ６０８を制約条件により選択し、選択されたＮＷ６０８を含むリストであるＮＷ制約プランリスト７１７を生成する。

そして、図２５の「アルゴリズム選択７２９」に示すように、ＩＣＳソフトウェア５０１は、プランを選択するためのアルゴリズムを１つ選択し、選択したアルゴリムに従って、制約条件を用いて、ＮＷ制約プランリスト７１７からプランを１つ選択する。そして、「アルゴリズムによるプラン選択７２８」に示すように、ＩＣＳソフトウェア５０１は、選択した１つのプランを「最も条件を満たすプラン出力７１８」として出力する。ここで、ＩＣＳソフトウェア５０１によって出力されたプランが、リソース割当となる。

［リソース配分計算の流れの全体像］
図２６は、実施例２におけるＩＣＳソフトウェアによるリソース配分計算の全体像を示すフローチャートである。図２６に示すフローチャートでは、記載の便宜上、図２５に示す処理のうち、ＤＣ利用可能リソース計算７２１とＮＷ利用可能リソース計算７２２とについては記載を省略した。なお、図２６を用いて説明する際には、各処理について簡単に説明するに留め、各処理の詳細については後述する。

図２６に示すように、ＩＣＳソフトウェア５０１は、ユーザのＤＣ制約条件によるＤＣ判定を行う（ステップＳ６０１）。つまり、ＩＣＳソフトウェア５０１は、制約条件のうちＤＣ６０５についての制約条件に基づいて、制約条件を満たすＤＣ６０５を選択する。つまり、ＩＣＳソフトウェア５０１は、ＤＣ条件による制約ＤＣリストを生成する。

そして、ＩＣＳソフトウェア５０１は、ユーザのＮＷ制約条件によるＤＣ判定を行う（ステップＳ６０２）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、制約条件のうちＮＷ６０８についての制約条件に基づいて、ユーザの所在地とＤＣ６０５との間で使用可能なＮＷ６０８を選択し、選択したＮＷ６０８のリストを生成する。ここで、ＩＣＳソフトウェア５０１は、ユーザ所在地とＤＣ６０５との間のネットワークが存在しないＤＣ６０５や、制約条件を満たすネットワーク６０８が１つもないＤＣ６０５について、ＤＣ条件による制約ＤＣリストから削除し、削除後のリストをＮＷ条件による制約ＤＣリストとする。

そして、ＩＣＳソフトウェア５０１は、リソース種類別のＤＣ判定を行う（ステップＳ６０３）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、ＶＭタイプごとに、ユーザに割り当てられる量のＶＭを確保できるか否かを判定し、ＶＭタイプごとのＤＣ６０５のリストである割当可能ＤＣリストを生成する。ここで、ＩＣＳソフトウェア５０１は、ユーザに割り当てられる量のＶＭを確保できるＤＣ６０５がないＶＭタイプがある場合には、ユーザに割り当てられる量を減らした上で、再度確保可能であるかを判定し、処理を繰り返す。

そして、ＩＣＳソフトウェア５０１は、データセンタプランを生成する（ステップＳ６０４）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ６０３にて生成された割当可能ＤＣリストから、ＶＭタイププランリストを生成する。ここで、ＶＭタイププランリストに含まれる組み合わせ各々をプランとも記載する。ここで、ＩＣＳソフトウェア５０１は、割当可能ＤＣリストに基づいて、総当たりにてプランを生成し、生成したプランのリストであるＶＭタイププランリストを生成する。

そして、ＩＣＳソフトウェア５０１は、プランのリソース提供・返却可能性を判定する（ステップＳ６０５）。つまり、ＩＣＳソフトウェア５０１は、同一のＤＣ６０５に対して複数のタイプのリソースが要求された場合に、あるタイプのリソース確保によって、他のＶＭタイプについてもリソースを確保可能であるか否かを判定し、リソースが確保できないプランをＶＭタイププランリストから削除する。

そして、ＩＣＳソフトウェア５０１は、利用可能なプランがあるか否かを判定する（ステップＳ６０６）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ６０５による処理の後、ＶＭタイププランリストにプランが残っているか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、利用可能なプランがあると判定した場合には（ステップＳ６０６肯定）、ＤＣ間ＮＷの制約条件によるプラン選択を行う（ステップＳ６０７）。つまり、各プランで使用されるＤＣ６０５間において使用可能なＮＷ６０８を、ＮＷ６０８についての制約条件により選択し、選択したＮＷ６０８が登録されたＮＷ制約プランリストを生成する。ここで、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストに含まれるプランのうち、プランに含まれるＤＣ６０５間にネットワーク６０８がないプランや、制約条件を満たすネットワーク６０８については、ＮＷ制約プランリストに登録されない。

そして、ＩＣＳソフトウェア５０１は、利用可能なプランがあるか否かを再度判定する（ステップＳ６０８）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ６０７による処理の後、ＮＷ制約プランリストにプランがあるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、利用可能なプランがあると判定した場合には（ステップＳ６０８肯定）、アルゴリズムによるプラン選択を行う（ステップＳ６０９）。つまり、ＩＣＳソフトウェア５０１は、選択されたアルゴリズムによってＮＷ制約プランリストから最適なプランを選択する。

そして、ＩＣＳソフトウェア５０１は、利用可能なプランがあるか否かを判定する（ステップＳ６１０）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ６０９による処理により、選択されたプランが１つ以上あるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、利用可能なプランがあると判定した場合には（ステップＳ６１０肯定）、プランのうち１つを解として選択する（ステップＳ６１１）。ここで、ＩＣＳソフトウェア５０１により選択されたプランが、ＩＣＳソフトウェア５０１により決定されたリソース割当となる。

なお、ここで、上述したステップＳ６０６、ステップＳ６０８、ステップＳ６１０において、利用可能なプランがないと判定した場合について説明する。この場合（ステップＳ６０６否定又はステップＳ６０８否定又はステップＳ６１０否定）、ＩＣＳソフトウェア５０１は、要求ＶＭ増分を変更する（ステップＳ６１２）。つまり、ＩＣＳソフトウェア５０１は、条件を満たすプランがなくなってしまった場合、ユーザに割り当てるＶＭを減らすことで、条件を満たすプランがでないかを試行する。

そして、ＩＣＳソフトウェア５０１は、要求増分が「０」となるか否かを判定する（ステップＳ６１３）。つまり、ＩＣＳソフトウェア５０１は、ユーザに割り当てるＶＭを減らした結果、ユーザに割り当てるＶＭが全てのタイプで「０」となるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、要求増分が「０」となると判定した場合には（ステップＳ６１３肯定）、新規にＶＭを割り当てられないことになり、エラーとして処理を終了する。一方、ＩＣＳソフトウェア５０１は、要求増分が「０」とならないと判定した場合には（ステップＳ６１３否定）、上述したステップＳ６０３に戻り、処理を繰り返す。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［ユーザのＤＣ制約条件によるＤＣ選択処理の流れ］
図２７は、実施例２におけるユーザのＤＣ制約条件によるＤＣ選択処理の流れの一例を示すフローチャートである。図２７に示す一連の処理は、図２６におけるステップＳ６０１に対応する。つまり、ＤＣ６０５についての制約条件に基づいてＤＣ６０５を選択する処理の流れについて説明する。

なお、以下では、ＤＣ６０５についての制約条件として、制約条件ＤＢ５１１が、地域についての制約条件である指定地域条件と、セキュリティについての制約条件であるセキュリティ基準と、耐震基準についての制約条件である耐震条件と、稼働率についての制約条件である稼働率条件とを記憶する場合を用いて説明する。ただし、これに限定されるものではなく、任意の制約条件を用いて良い。

図２７に示すように、ＩＣＳソフトウェア５０１は、ＤＣ利用可能リソース情報の個数分、処理をループする（ステップＳ７０１）。言い換えると、ＩＣＳソフトウェア５０１は、ＤＣ利用可能リソース情報各々について、ＤＣ利用可能リソース情報の個数分ループＥＮＤ（ステップＳ７０７）までの処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、ＤＣ６０５についての制約条件全てについて、ＤＣ６０５ごとに満たすか否かを判定する。図２７に示す例では、ＩＣＳソフトウェア５０１は、ＤＣ６０５各々について、指定地域条件を満たせるか否かを判定し（ステップＳ７０２）、セキュリティ基準を満たせるか否かを判定し（ステップＳ７０３）、耐震条件が満たせるか否かを判定し（ステップＳ７０４）、稼働率条件が満たせるか否かを判定する（ステップＳ７０５）。

すなわち、ＩＣＳソフトウェア５０１は、ＤＣ６０５各々について、制約条件に含まれる指定地域条件を満たしているかを判定する。なお、ＩＣＳソフトウェア５０１は、指定地域条件がない場合には、満たしていると判定する。また、ＩＣＳソフトウェア５０１は、制約条件に含まれるセキュリティ基準を満たしているかを判定する。ここで、ＩＣＳソフトウェア５０１は、セキュリティ基準により要求されるセキュリティよりＤＣ６０５のセキュリティが同じか上であれば、条件を満たすと判定する。また、ＩＣＳソフトウェア５０１は、制約条件に含まれる耐震条件を満たしているかを判定する。ここで、ＩＣＳソフトウェア５０１は、耐震条件により要求される耐震性よりＤＣ６０５の耐震性が同じか上であれば、条件を満たすと判定する。また、ＩＣＳソフトウェア５０１は、制約条件に含まれる稼働率条件を満たしているかを判定する。ここで、ＩＣＳソフトウェア５０１は、稼働率条件により要求される稼働率よりＤＣ６０５の稼働率が同じか上であれば、条件を満たすと判定する。

ここで、ＩＣＳソフトウェア５０１は、制約条件全てについて満たすと判定したＤＣ６０５について（ステップＳ７０２肯定及びステップＳ７０３肯定及びステップＳ７０４肯定及びステップＳ７０５肯定）、ＤＣ条件による制約ＤＣリストに登録する（ステップＳ７０６）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ６０５についての制約条件全てを満たすＤＣ６０５のリストである制約ＤＣリストを生成する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ利用可能リソース情報の個数分ループが終了すると（ステップＳ７０７）、ＤＣ条件による制約ＤＣリストを出力する（ステップＳ７０８）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ７０６にて制約ＤＣリストに登録されたＤＣ６０５のリストを出力する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、ステップＳ７０２〜Ｓ７０５について、任意の順番に変更しても良い。

図２８は、図２７に示される一連の処理について説明する図である。図２８の（１）に示すように、例えば、ＤＣ６０５として、「ＤＣＡ」「ＤＣＢ」「ＤＣＣ」「ＤＣＤ」について、ＤＣ利用可能リソース情報がある場合を用いて説明する。言い換えると、「ＤＣＡ」と「ＤＣＢ」と「ＤＣＣ」と「ＤＣＤ」とについて処理を実行する場合を用いて説明する。また、「ＤＣＤ」が、指定地域条件を満たさない場合を用いて説明する。なお、図２８に示す例では、ＤＣ６０５各々について、ＶＭの台数をＶＭタイプごとに示した。

この場合、図２８の（２）に示すように、ＩＣＳソフトウェア５０１は、ＤＣ６０５のリストから、ＤＣ６０５についての制約条件を満たさない「ＤＣＤ」を削除する。この結果、図２８の（２）に示すように、ＤＣ６０５のリストには、ＤＣ６０５についての制約条件を満たす「ＤＣＡ」と「ＤＣＢ」と「ＤＣＣ」とが残る。

［ユーザのＮＷ制約条件によるＤＣ選択処理の流れ］
図２９は、実施例２におけるユーザのＮＷ制約条件によるＤＣ選択処理の流れの一例を示すフローチャートである。図２９に示す一連の処理は、図２６におけるステップＳ６０２に対応する。つまり、ＩＣＳソフトウェア５０１が、ＤＣ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、ＮＷについての制約条件により、ユーザの所在地とＤＣ６０５との間で使用可能なＮＷ６０８を選択し、選択したＮＷ６０８のリストがＤＣ６０５に対応付けて登録されたリストとなるＮＷ条件による制約ＤＣリストを出力する処理ついて説明する。

すなわち、例えば、ＩＣＳソフトウェア５０１が、ＤＣ６０５についての制約条件を満たすＤＣ６０５について、帯域確保条件や本数条件などのネットワーク６０８についての制約条件を全て満たし、利用者からＤＣ６０５までアクセス可能となるネットワーク６０８があるか否かを判定する処理の流れについて説明する。

図２９に示すように、ＩＣＳソフトウェア５０１は、ＤＣ条件による制約ＤＣリストの個数分、処理をループする（ステップＳ８０１）。言い換えると、ＩＣＳソフトウェア５０１は、ＤＣ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、ＤＣ条件による制約ＤＣリストの個数分ループＥＮＤ（ステップＳ８０９）までの処理を繰り返す。なお、ＤＣ条件による制約ＤＣリストは、図２７による一連の処理の結果得られるＤＣ６０５のリストであって、ＤＣ６０５についての制約条件を全て満たすＤＣ６０５のリストである。

具体的には、ＩＣＳソフトウェア５０１は、ＤＣ別ＮＷ制約リストを初期化する（ステップＳ８０２）。つまり、ＤＣ６０５ごとにピックアップするＮＷ６０８のリストを初期化する。そして、ＩＣＳソフトウェア５０１は、利用者の所在地の個数分、処理をループする（ステップＳ８０３）。言い換えると、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５について、利用者の所在地全てについて、利用者の所在地の個数分ループＥＮＤ（ステップＳ８０７）までの処理を繰り返す。

利用者の所在地全てについて繰り返す処理について説明する。ＩＣＳソフトウェア５０１は、利用者の所在地と処理対象となるＤＣ６０５との間にＮＷ６０８があるか否かを判定する（ステップＳ８０４）。つまり、ユーザの所在地とＤＣ６０５との間にＮＷ６０８がない場合には、処理対象となるＤＣ６０５を使用できないことを踏まえ、ユーザの所在地とＤＣ６０５との間にＮＷ６０８があるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、利用者の所在地と処理対象となるＤＣ６０５との間にＮＷ６０８があると判定した場合には（ステップＳ８０４肯定）、利用者条件を満たせるＮＷ６０８をＤＣ別ＮＷ制約リストにピックアップする（ステップＳ８０５）。つまり、ＩＣＳソフトウェア５０１は、利用者の所在地と処理対象となるＤＣ６０５との間にあるネットワーク６０８のうち、ネットワーク６０８についての制約条件を満たすネットワーク６０８をピックアップし、ピックアップしたネットワーク６０８のリストとなるＤＣ別ＮＷ制約リストを生成する。なお、ステップＳ８０５の処理の詳細については、後述する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ別ＮＷ制約リストに制約条件を満たすＮＷ６０８があるか否かを判定する（ステップＳ８０６）。つまり、制約条件を満たすＮＷ６０８が利用者の所在地と処理対象となるＤＣ６０５との間になければ、処理対象となるＤＣ６０５は使用できないことを踏まえ、制約条件を満たすＮＷ６０８があるか否かを判定する。

ここで、利用者の所在地全てについて、利用者の所在地と処理対象となるＤＣ６０５との間にＮＷ６０８があると判定し（ステップＳ８０４肯定）、制約条件を満たすＮＷ６０８があると判定した場合には（ステップＳ８０６肯定）、ＮＷ条件による制約ＤＣリストに該当ＤＣ６０５とＤＣ別ＮＷ制約リストを登録する（ステップＳ８０８）。つまり、ＩＣＳソフトウェア５０１は、ネットワーク６０８についての制約条件を満たすＮＷ６０８を全てのユーザ所在地について確保可能なＤＣ６０５と、ユーザの所在地とＤＣ６０５との間において利用可能なネットワーク６０８のリストとが対応付けられたリストを生成する。ここで生成されるリストが、ＮＷ制約プランリストとなる。

なお、ＩＣＳソフトウェア５０１は、利用者の所在地と処理対象となるＤＣ６０５との間にＮＷ６０８がないと判定した場合や（ステップＳ８０４否定）、制約条件を満たすＮＷ６０８がないと判定した場合には（ステップＳ８０６否定）、処理対象となるＤＣ６０５をＮＷ制約プランリストに登録することなく、処理対象となるＤＣ６０５についての処理を終了する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ条件による制約ＤＣリストに含まれるＤＣ６０５各々について処理を実行すると（ステップＳ８０９）、ＮＷ条件による制約ＤＣリストを出力する。つまり、制約条件を満たすＤＣ６０５と、制約条件を満たすＤＣ６０５に対応づけられた利用可能なネットワーク６０８のリストとを出力する（ステップＳ８１０）。

図３０は、図２９に示される一連の処理により出力されるＮＷ条件による制約ＤＣリストの一例を示す図である。図３０に示す例では、ユーザの所在地として、「ユーザの所在地Ａ」と「ユーザの所在地Ｂ」と「ユーザの所在地Ｃ」とがある場合を示した。図３０において、「ＮＷｃｌａｓｓ１」と「ＮＷｃｌａｓｓ２」と「ＮＷｃｌａｓｓ３」とは、それぞれ、ネットワーク６０８の種類を示す。「×」は、ユーザの所在地とＤＣ６０５との間にネットワーク６０８がないことを示す。また、ネットワーク６０８についての情報として、帯域と、利用料金とを記載した。また、図３０において、ネットワーク６０８についての情報の上に斜線が引かれている場合については、ネットワーク６０８が制約条件を満たさないことを示す。

図３０に示す例では、「ＤＣＣ」については、「ユーザの所在地Ａ」と「ＤＣＣ」との間にネットワーク６０８がない。この結果、「ＤＣＣ」の上に斜線が引かれているように、「ＤＣＣ」がＮＷ条件による制約ＤＣリストから除外されることになる。

［利用者条件を満たせるＮＷをＤＣ別ＮＷ制約リストにピックアップする処理］
図３１は、実施例２における利用者条件を満たせるＮＷをＤＣ別ＮＷ制約リストにピックアップする処理の流れの一例を示すフローチャートである。図３１に示す一連の処理は、図２９におけるステップＳ８０５に対応する。

なお、以下では、ＮＷ６０８についての制約条件として、帯域についての制約条件である帯域確保条件と、回線の本数についての制約条件である本数条件と、帯域についての制約条件である帯域条件と、遅延時間についての制約条件である遅延条件と、ネットワーク６０８についての制約条件であるセキュリティ条件とがある場合を用いて説明する。ただし、これに限定されるものではなく、任意の制約条件を用いて良い。

図３１に示すように、ＩＣＳソフトウェア５０１は、ユーザの所在地とＤＣ６０５間のＮＷクラス個数分、処理をループする（ステップＳ９０１）。言い換えると、ＩＣＳソフトウェア５０１は、ユーザの所在地とＤＣ６０５との間にあるＮＷ６０８各々について、所在地-ＤＣ間のＮＷクラス個数分ループＥＮＤ（ステップＳ９０８）までの処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、ＮＷ６０８についての制約条件全てについて、ＮＷ６０８ごとに満たすか否かを判定する。図３１に示す例では、ＩＣＳソフトウェア５０１は、ＮＷ６０８各々について、帯域確保条件を満たせるか否かを判定し（ステップＳ９０２）、本数条件を満たせるか否かを判定し（ステップＳ９０３）、帯域条件を満たせるか否かを判定し（ステップＳ９０４）、遅延条件を満たせるか否かを判定し（ステップＳ９０５）、セキュリティ条件を満たせるか否かを判定する（ステップＳ９０６）。

そして、ＩＣＳソフトウェア５０１は、制約条件全てについて満たすと判定したＮＷ６０８について（ステップＳ９０２肯定及びステップＳ９０３肯定及びステップＳ９０４肯定及びステップＳ９０５肯定及びステップＳ９０６肯定）、ユーザ所在地とクラスをＤＣ別ＮＷ制約リストに登録する（ステップＳ９０７）。つまり、ＩＣＳソフトウェア５０１は、全ての制約条件を満たすＮＷ６０８を、ＤＣ６０５に対応付けてＤＣ別ＮＷ制約リストに登録する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、ステップＳ９０２〜Ｓ９０６について、任意の順番に変更しても良い。

［リソース種類別のＤＣ判定］
図３２は、実施例２におけるリソース種類別のＤＣ判定の流れの例を示すフローチャートである。つまり、図３２を用いて、ＮＷ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、ＶＭの割り当て要求により要求されるＶＭを確保できるか否かをＶＭタイプごとに確認し、ＶＭタイプごとに割り当て可能となるＤＣ６０５のリストとなるＶＭタイプ別ＤＣ候補リストを生成する処理の流れの一例を示す。

具体的には、以下に説明するように、ＩＣＳソフトウェア５０１は、ＤＣ６０５を選択し、各タイプの仮想マシンを提供できるかどうかを判定し、ＶＭタイプ別ＤＣ候補リストを出力する。また、ここで、ＩＣＳソフトウェア５０１は、全てのデータセンタが必要なリソースを提供できないＶＭタイプについては、割り当てるＶＭ数を減らした上で再度処理を実行する。なお、図３２に示す一連の処理は、図２６におけるステップＳ６０３に対応する。

図３２に示すように、ＩＣＳソフトウェア５０１は、ＮＷ条件による制約ＤＣリストの個数分、処理をループする（ステップＳ１００１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ条件による制約ＤＣリストに含まれるＤＣ６０５各々について、ＮＷ条件による制約ＤＣリスト個数分ループＥＮＤ（ステップＳ１００７）までの処理を繰り返す。これにより、ＩＣＳソフトウェア５０１は、ＤＣ６０５ごとにＶＭタイプ各々について実際に割り当て可能か確認する。

具体的には、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５について、選択したＤＣのＶＭタイプの個数分、処理をループする（ステップＳ１００２）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ各々について選択したＤＣのＶＭタイプの個数分ループＥＮＤ（ステップＳ１００６）までの処理を繰り返す。これにより、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５について、ＶＭタイプごとに実際に割り当て可能か確認する。

ここで、ＩＣＳソフトウェア５０１は、ユーザが必要なＶＭタイプか否かを判定し（ステップＳ１００３）、ユーザが必要なＶＭタイプであると判定すると（ステップＳ１００３肯定）、当該ＶＭタイプが必要数確保できるか否かを判定する（ステップＳ１００４）。ＩＣＳソフトウェア５０１は、該当ＶＭタイプのリソース分、ＤＣの使用可能リソースから引いたものが０以上か確認する。

そして、ＩＣＳソフトウェア５０１は、当該ＶＭタイプが必要数確保できると判定した場合には（ステップＳ１００４肯定）、ＶＭタイプ別ＤＣ候補リストに登録する（ステップＳ１００５）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別に利用可能なＤＣ候補をリストとして登録する。ここで、ＩＣＳソフトウェア５０１が、ＶＭタイプ別に利用可能なＤＣ候補を登録したリストをＶＭタイプ別ＤＣ候補リストと称する。

なお、ＩＣＳソフトウェア５０１は、ユーザが必要なＶＭタイプでないと判定した場合には（ステップＳ１００３否定）、処理対象となるＶＭタイプについての処理を終了する。これは、ユーザの要求がないＶＭタイプについては、当該ＶＭタイプが必要数確保できるか否かを判定する必要がないからである。

その後、ＩＣＳソフトウェア５０１は、ＮＷ条件による制約ＤＣリストの個数分、処理をループすると（ステップＳ１００７）、割り当てられるＤＣが１つもないタイプがあるか否かを判定する（ステップＳ１００８）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストにおいて、ＤＣ候補が１つもないＶＭタイプがあるか否か確認する。

ここで、ＩＣＳソフトウェア５０１は、割り当てられるＤＣが１つもないタイプがないと判定した場合には（ステップＳ１００８否定）、ＶＭタイプ別ＤＣ候補リストを出力する（ステップＳ１００９）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別に利用可能と思われるＤＣ６０５のリストを出力する。

一方、ＩＣＳソフトウェア５０１は、割り当てられるＤＣが１つもないタイプがあると判定した場合には（ステップＳ１００８肯定）、割り当てられるＤＣが１つもないタイプの要求ＶＭ増分を１つ減らし（ステップＳ１０１０）、上述したステップＳ１００１に戻り、処理を繰り返す。つまり、ＩＣＳソフトウェア５０１は、どのＤＣ６０５にも割り当てられないＶＭタイプの要求を１つ減らし、処理を繰り返す。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ１００３をＳ１００４の後に実行しても良い。

図３３は、実施例２におけるリソース種類別のＤＣ判定について説明する図である。図３３に示す例では、要求されているＶＭが、「ＶＭＴｙｐｅ１」が「５台」であり、「ＶＭＴｙｐｅ２」が「２台」であり、「ＶＭＴｙｐｅ３」が「２台」である場合を用いて説明する。また、図３３の（１）に示す例では、図２８や図３０に示すように、「ＤＣＣ」と「ＤＣＤ」とについては、リストから除外されている場合を例に示した。ここで、図３３の（２）に示すように、ＩＣＳソフトウェア５０１は、「ＤＣＡ」及び「ＤＣＢ」について、各ＤＣ６０５のＶＭタイプごとに、要求されているＶＭの台数を割当可能であるか否かを判定する。図３３の（２）に示す例では、「ＤＣＡ」は、「ＶＭＴｙｐｅ３」の台数が「１台」であり、要求されている「２台」を満たさない。この結果、図３３の（２）に示す例では、「ＤＣＡ」の「ＶＭＴｙｐｅ３」について、斜線が記載されている。この結果、図３３の（３）に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストにおいては、「ＤＣＡ」と「ＤＣＢ」とが記載され、「ＤＣＡ」の「ＶＭＴｙｐｅ３」については不可となる。

［データセンタプラン作成の流れ］
図３４は、実施例２におけるデータセンタプラン作成の流れの一例を示すフローチャートである。つまり、図３４は、ＶＭタイプごとのＤＣ候補の可能な組み合わせを列挙したプランリストであるＶＭタイププランリスト作成の流れの一例を示す。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストから、組み合わせ可能なＤＣ６０５を組み合わせたリストを作成する。なお、図３４に示す一連の処理は、図２６におけるステップＳ６０４に対応する。なお、以下では、ＶＭのタイプとして、ＶＭタイプ１とＶＭタイプ２とＶＭタイプ３とがある場合を用いて説明する。

図３４に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイプ１のＤＣ候補リストの個数分、処理をループする（ステップＳ１１０１）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストに含まれるＤＣ６０５のうち、ＶＭタイプ１を割当可能なＤＣ６０５各々について、ＶＭタイプ１のＤＣ候補リストの個数分ループＥＮＤ（ステップＳ１１０７）までの処理を繰り返す。

また、ＩＣＳソフトウェア５０１は、ＶＭタイプ２のＤＣ候補リストの個数分、処理をループする（ステップＳ１１０２）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストに含まれるＤＣ６０５のうち、ＶＭタイプ２を割当可能なＤＣ６０５各々について、ＶＭタイプ２のＤＣ候補リストの個数分ループＥＮＤ（ステップＳ１１０６）までの処理を繰り返す。

また、ＩＣＳソフトウェア５０１は、ＶＭタイプ３のＤＣ候補リストの個数分、処理をループする（ステップＳ１１０３）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストに含まれるＤＣ６０５のうち、ＶＭタイプ２を割当可能なＤＣ６０５各々について、ＶＭタイプ２のＤＣ候補リストの個数分ループＥＮＤ（ステップＳ１１０５）までの処理を繰り返す。

ここで、ＩＣＳソフトウェア５０１は、処理対象となったＶＭタイプごとのＤＣ６０５の組み合わせをＶＭタイププランリストに登録する（ステップＳ１１０４）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストに登録された全てのＶＭタイプについてＤＣ候補の可能な組み合わせを１つずつリストに登録する。このように、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストから、ＶＭタイプ各々について、割当可能なＤＣ６０５全てについて処理をループすることで、ＶＭタイプとＤＣの全組み合わせを取得し、ＶＭタイププランリストに登録する。

そして、ＩＣＳソフトウェア５０１は、ＶＭタイプ１のＤＣ候補リストの個数分ループＥＮＤ（ステップＳ１１０７）となると、ＶＭタイププランリストを出力する（ステップＳ１１０８）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイプ別ＤＣ候補リストに登録されたＤＣ６０５の組み合わせ全てを列挙したＶＭタイププランリストを出力する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ１１０１〜ステップＳ１１０３を任意の順番にてループしても良い。

図３５は、実施例２におけるデータセンタプラン作成の流れを説明する図である。図３５の（１）は、ＶＭタイプ別ＤＣ候補リストを示す。ここで、図３５の（２）に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイプそれぞれについて、ＶＭタイプ別ＤＣ候補リストにより割当可能とされているＤＣ６０５を１つ選択したリストとなるＶＭタイププランリストを生成する。つまり、図３５の（２）に示す例では、「プラン１」〜「プラン４」を含むＶＭタイププランリストを生成する。

［プランのリソース提供・返却可能性判定］
図３６は、実施例２におけるプランのリソース提供・返却可能性判定の流れの一例を示すフローチャートである。図３６は、同一のＤＣに対して複数のＶＭタイプのリソースが要求された場合に、あるタイプのリソース確保によって、他のタイプのリソースが、足りなくなる場合がないかをチェックする処理について説明する。なお、図３６に示す一連の処理は、図２６におけるステップＳ６０５に対応する。

図３６に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストの個数分、処理をループする（ステップＳ１２０１）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストに含まれるプラン各々について、ＶＭタイププランリストの個数分ループＥＮＤ（ステップＳ１２０６）までの処理を繰り返す。言い換えると、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストから、条件を満たすプランをピックアップする処理を実行する。

ここで、ＩＣＳソフトウェア５０１は、処理対象となるプランの内ＤＣ６０５の個数分、処理をループする（ステップＳ１２０２）。つまり、ＩＣＳソフトウェア５０１は、プラン内のＤＣ６０５個数分ループＥＮＤ（ステップＳ１２０５）までの処理を繰り返す。言い換えると、ＩＣＳソフトウェア５０１は、処理対象となるプランのＶＭタイプ全てについてリソースが確保できるか否かを確認することを目的として、処理をループする。

具体的には、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５にプラン内のＴｙｐｅのリソースが全て割り当て可能であるか否かを判定する（ステップＳ１２０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて、同一のＤＣ６０５により複数のタイプのＶＭが提供される場合に、複数のタイプ全てについて、対象となるＤＣ６０５がＶＭを割当可能であるか否かを判定する。つまり、例えば、ＤＣ６０５が、ＶＭタイプ１を１０台割り当て可能であり、ＶＭタイプ２を５台割り当て可能であり、ＶＭタイプ３を１台割り当て可能である場合を用いて説明する。ここで、ＤＣ６０５は、ＶＭタイプ１を１０台割り当てるとともに、同時に、ＶＭタイプ２を５台割り当てることができない場合がある。例えば、ＶＭタイプ１の１０台分のリソースはＶＭタイプ２を割り当てる際にも用いられる場合には、ＶＭタイプ１を１０台割り当てるとともに、ＶＭタイプ２を５台割り当てることはできない。このことを踏まえ、ＩＣＳソフトウェア５０１は、各ＤＣ６０５が、プランに含まれるＶＭタイプ各々を同時に割り当て可能であるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５にプラン内のＴｙｐｅのリソースが全て割り当て可能であると判定した場合には（ステップＳ１２０３肯定）、該当プランをＤＣリソース提供条件プランリストに登録する（ステップＳ１２０４）。一方、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５にプラン内のＴｙｐｅのリソースが全て割り当て可能でないと判定した場合には（ステップＳ１２０３否定）、ＤＣリソース提供条件プランリストに登録することなく、次の処理を実行する。

そして、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストの個数分、処理をループすると（ステップＳ１２０６）、ＤＣリソース提供条件プランリストを出力する（ステップＳ１２０７）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［要求ＶＭ増分の変更］
図３７は、実施例２における要求ＶＭ増分の変更の処理の流れの一例を示すフローチャートである。つまり、図３７は、制約条件を満たすプランがなくなってしまった場合に、要求されたＶＭ数を減らすことで制約条件を満たすプランがでる可能性があることを踏まえ、要求されたＶＭ数を変更する。

つまり、以下では、仮想マシンの増設・減設の要求に対して台数分の増減ができない場合に、要求台数を再計算する場合における処理の流れを示す。言い換えると、仮想マシンの増設に必要なリソースは全てのプランが提供できない場合、ＩＣＳソフトウェア５０１が、台数の最も多いタイプのうち、スペックの最も低い仮想マシンの要求を減らし、再度プランの組み合わせを生成する場合について説明する。なお、図３７に示す一連の処理は、図２６におけるステップＳ６１２に対応する。

図３７に示すように、ＩＣＳソフトウェア５０１は、要求増分が最も多いＶＭタイプを選択する（ステップＳ１３０１）。例えば、ＩＣＳソフトウェア５０１は、「ＶＭタイプ１」と「ＶＭタイプ２」と「ＶＭタイプ３」とのうち、要求された台数が最も多いＶＭタイプを選択する。

そして、ＩＣＳソフトウェア５０１は、該当のＶＭタイプが複数あるか否かを判定する（ステップＳ１３０２）。ここで、ＩＣＳソフトウェア５０１は、複数あると判定した場合には（ステップＳ１３０２肯定）、スペックが低いタイプを選択する（ステップＳ１３０３）。

そして、ＩＣＳソフトウェア５０１は、該当タイプの要求を一台減らす（ステップＳ１３０４）。つまり、該当タイプのＶＭの割り当て要求数を１つ減らす。なお、ＩＣＳソフトウェア５０１は、該当のＶＭタイプが複数ないと判定した場合には（ステップＳ１３０２否定）、スペックが低いタイプを選択することなく、１つのＶＭタイプについてＶＭの割り当て要求数を１つ減らす。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。また、例えば、上述した処理では、ＶＭタイプが複数ある場合にスペックが低いタイプを選択する場合を例に示したが、これに限定されるものではなく、任意の観点からＶＭタイプを選択して良い。また、上述した処理では、要求数を１つ減らす場合を用いて説明したが、これに限定されるものではなく、任意の数減らして良い。

［ＤＣ間のＮＷ制約条件によるプラン選択］
図３８は、実施例２におけるＤＣ―ＤＣ間のＮＷ制約条件によるプラン選択の流れの一例を示すフローチャートである。図３８は、ＶＭタイププランリストに含まれるプランにおいて使用されるＤＣ６０５間にて使用可能なＮＷ６０８を制約条件により選択し、選択されたＮＷ６０８を含むリストであるＮＷ制約プランリストを生成する。

すなわち、以下では、仮想マシンを提供可能としたプランのうち、複数のデータセンタ６０５を利用するものに対して、全てのデータセンタ６０５同士間におけるネットワーク６０８の有無、及び、制約条件を満たせるかどうかを判定する。この結果、ＩＣＳソフトウェア５０１は、データセンタ６０５間を接続するネットワーク６０８が利用可能となるプランを出力する。

なお、ＤＣ６０５間のネットワーク６０８が存在しない場合や、制約条件を満たすＮＷ６０８が１つもないプランについては、ＮＷ制約プランリストに登録されないことになる。なお、図３８に示す一連の処理は、図２６におけるステップＳ６０７に対応する。

図３８に示すように、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストの個数分、処理をループする（ステップＳ１４０１）。つまり、ＩＣＳソフトウェア５０１は、Ｍタイププランリストの個数分ループＥＮＤ（ステップＳ１４０７）までの処理を繰り返す。言い換えると、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストに含まれるプランのうち、条件を満たすものをピックアップする。

具体的には、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストを初期化し（ステップＳ１４０２）、処理対象となるプランが複数のＤＣ６０５で構成されているか否かを判定する（ステップＳ１４０３）。例えば、ＩＣＳソフトウェア５０１は、プランごとに処理を行う際に用いられるメモリを初期化する。

ここで、ＩＣＳソフトウェア５０１は、処理対象となるプランが複数のＤＣ６０５で構成されていると判定した場合には（ステップＳ１４０３肯定）、ユーザ条件を満たせるＮＷをＤＣ間ＮＷ制約リストにピックアップする（ステップＳ１４０４）。つまり、ＤＣ６０５間接続で制約条件を満たすＮＷ６０８の選択を行う。なお、ステップＳ１４０４の詳細については、後述する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ６０５間に条件を満たすＮＷ６０８はあるか否かを判定する（ステップＳ１４０５）。ここで、ＩＣＳソフトウェア５０１は、ＤＣ６０５間に条件を満たすＮＷ６０８はあると判定した場合には（ステップＳ１４０５肯定）、ＮＷ制約プランに該当プランとプラン別ＮＷ制約リストを登録する（ステップＳ１４０６）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランと、処理対象となるＤＣ６０５間で制約条件を満たすＮＷ６０８とが登録されたリストを生成する。ここで、ＩＣＳソフトウェア５０１により生成されたリストが制約プランリストとなる。

なお、ＩＣＳソフトウェア５０１は、処理対象となるプランが複数のＤＣ６０５で構成されていないと判定した場合には（ステップＳ１４０３否定）。処理対象となるプランをそのままＮＷ制約プランリストに登録する。これは、処理対象となるプランが１つのＤＣ６０５で構成されている場合、ＤＣ６０５間での接続がないからである。

その後、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストを出力する（ステップＳ１４０８）。つまり、ＩＣＳソフトウェア５０１は、ＶＭタイププランリストに含まれるプランのうち条件を満たすプランをピックアップし、ピックアップされたプランが登録されたＮＷ制約プランリストを出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

図３９は、実施例２におけるＤＣ―ＤＣ間に条件を満たすＮＷはあるか否かの判定について説明する図である。図３９に示す例では、「ＤＣＡ」と「ＤＣＢ」とを含むプランが処理対象となっている場合を用いて説明する。また、「ＤＣＡ」と「ＤＣＢ」との間には、ＮＷ６０８として、「ＮＷｃｌａｓｓ１」と「ＮＷｃｌａｓｓ２」とがある場合を用いて説明する。なお、図３９に示す例では、「ＤＣＡ」と「ＤＣＢ」との間には「ＮＷｃｌａｓｓ３」はない場合を示した。ここで、例えば、ネットワーク６０８についての制約条件として、「８０Ｍｂｐｓ以上」と「１１０万以下」という制約条件がある場合を用いて説明する。この場合、ＩＣＳソフトウェア５０１は、「ＮＷｃｌａｓｓ１」については条件を満たさず、「ＮＷｃｌａｓｓ２」については条件を満たすと判定する。この結果、ＩＣＳソフトウェア５０１は、「ＤＣＡ」と「ＤＣＢ」とを含むプランについて、「ＮＷｃｌａｓｓ２」と対応付けた上でＮＷ制約プランリストに登録する。

［ユーザ条件を満たせるＮＷをＤＣ間ＮＷ制約リストにピックアップする処理］
図４０は、実施例２におけるユーザ条件を満たせるＮＷをＤＣ間ＮＷ制約リストにピックアップする処理の流れの一例を示すフローチャートである。図４０は、ＤＣ６０５間を接続するＮＷ６０８について、制約条件に基づいて使用可能なクラスのＮＷを選択する。なお、以下では、制約条件として、帯域確保条件と、本数条件と、帯域条件と、遅延条件と、セキュリティ条件とがある場合を用いて説明する。図４０に示す一連の処理は、図３８におけるステップＳ１４０４に対応する。

図４０に示すように、ＩＣＳソフトウェア５０１は、処理対象となるプランに含まれるＤＣ６０５間のＮＷ個数分、処理をループする（ステップＳ１５０１）。つまり、例えば、ＩＣＳソフトウェア５０１は、ＤＣ６０５間にあるＮＷ６０８各々について、ＤＣ６０５間のＮＷ個数分ループＥＮＤ（ステップＳ１５０８）までの処理を繰り返すことで、制約条件を満たすか否かを判定する。

具体的には、ＩＣＳソフトウェア５０１は、帯域確保条件を満たすか否かを判定し（ステップＳ１５０２）、本数条件を満たすか否かを判定し（ステップＳ１５０３）、帯域条件を満たすか否かを判定し（ステップＳ１５０４）、遅延条件を満たすか否かを判定し（ステップＳ１５０５）、セキュリティ条件を満たすかを判定する（ステップＳ１５０６）。

ここで、ＩＣＳソフトウェア５０１は、全てを満たすと判定した場合に（ステップＳ１５０２肯定及びステップＳ１５０３肯定及びステップＳ１５０４肯定及びステップＳ１５０６肯定）、ＤＣ６０５間とクラスとをＮＷ制約プランリストに登録する（ステップＳ１５０７）。つまり、全てを満たすと判定ＮＷ６０８をＮＷ制約プランリストに登録する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ１５０２〜Ｓ１５０６を任意の順番にて実行しても良い。

［アルゴリズムによるプラン選択］
図４１は、実施例２におけるアルゴリズムによるプラン選択の流れの一例を示すフローチャートである。図４１は、ＮＷ制約プランリストに含まれるプランのうち、選択されたアルゴリズムによって最適なプランを選択する処理を示す。ＩＣＳソフトウェア５０１は、利用者又は事業者の規定したポリシを反映できるアルゴリズムを選択する。

図４１に示すように、ＩＣＳソフトウェア５０１は、アルゴリズムを１つ選択する（ステップＳ１６０１）。例えば、ＩＣＳソフトウェア５０１は、任意の選択基準に従って、アルゴリズムを１つ選択する。

例えば、ＩＣＳソフトウェア５０１は、アルゴリズムとしてコスト最小アルゴリズムを選択すると、ＮＷ制約プランリストからコストが最小となるプランを１つ選択する（ステップＳ１６０２）。つまり、ＩＣＳソフトウェア５０１は、価格が最小のプランをＮＷ制約プランリストから選択する。

また、例えば、ＩＣＳソフトウェア５０１は、アルゴリズムとして帯域最大アルゴリズムを選択すると、ＮＷ制約プランリストから帯域が最大となるプランを１つ選択する（ステップＳ１６０３）。つまり、ＩＣＳソフトウェア５０１は、制約条件の価格を満たした上でネットワークの帯域の平均が最大となるプランをＮＷ制約プランリストから選択する。

また、例えば、ＩＣＳソフトウェア５０１は、アルゴリズムとして遅延最小アルゴリズムを選択すると、ＮＷ制約プランリストから遅延が最小となるプランを１つ選択する（ステップＳ１６０４）。つまり、ＩＣＳソフトウェア５０１は、プランの中から制約条件の価格を満たした上でネットワークの遅延の平均が最小となるプランをＮＷ制約プランリストから選択する。

また、例えば、ＩＣＳソフトウェア５０１は、アルゴリズムとして集中アルゴリズムを選択すると、割り当て元となるリソースが集中するプランをＮＷ制約プランリストから１つ選択する（ステップＳ１６０５）。つまり、ＩＣＳソフトウェア５０１は、制約条件の価格を満たした上でＤＣ６０５の使用率の分散度合いが最大となるＮＷ制約プランリストから選択する。言い換えると、ＩＣＳソフトウェア５０１は、特定のＤＣ６０５に負担が集中することになるプランを選択する。

また、例えば、ＩＣＳソフトウェア５０１は、アルゴリズムとして分散アルゴリズムを選択すると、割り当て元となるリソースが分散するプランをＮＷ制約プランリストから１つ選択する（ステップＳ１６０６）。つまり、ＩＣＳソフトウェア５０１は、制約条件の価格を満たした上でＤＣ６０５の使用率の分散度合いが最小となるプランをＮＷ制約プランリストから選択する。言い換えると、ＩＣＳソフトウェア５０１は、特定のＤＣ６０５に負担が集中することなく、平均してＤＣ６０５を使用することになるプランを選択する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。また、上述した例では、アルゴリズムが５種類ある場合を用いて説明したが、これに限定されるものではなく、任意の数のアルゴリズムがあって良い。

［コスト最小アルゴリズム］
図４２は、実施例２におけるコスト最小アルゴリズムによる処理の一例を示すフローチャートである。図４２に示す一連の処理は、図４１におけるステップＳ１６０２に対応する。すなわち、以下では、プラン各々について、利用者とデータセンタ６０５との間におけるネットワーク６０８と、データセンタ６０５間を接続するネットワーク６０８とについて、最もコストが小さくなるネットワーク６０８を選択し、仮想マシンについての料金とネットワークの料金との合計料金をそれぞれ計算し、合計金額が最も小さくなるプランを出力する場合について説明する。

図４２に示すように、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに登録されたプランとなるＮＷ制約プランの個数分、処理をループする（ステップＳ１７０１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、ＮＷ制約プランの個数分ループＥＮＤ（ステップＳ１７０８）までの処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、処理対象となるプランのＶＭ料金を合算しＤＣ料金を算出する（ステップＳ１７０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、ＶＭの割当数に、処理対象となるプランにおけるＤＣ６０５のＶＭタイプの料金を掛けて算出し、算出した料金を合算することでプランのＤＣ６０５についての合計金額を算出する。

そして、ＩＣＳソフトウェア５０１は、利用者所在地-ＤＣ間のＮＷ料金合計を算出する（ステップＳ１７０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、全てのユーザ所在地からＤＣ６０５までの間において最も安いＮＷ６０８の料金の合計を算出する。なお、ステップＳ１７０３の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ６０５−ＤＣ６０５間のＮＷ料金合計を算出する（ステップＳ１７０４）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、全てのＤＣ６０５間について、最も安いＮＷ６０８のクラスの料金の合計を算出する。なお、ステップＳ１７０４の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、各料金を合算する（ステップＳ１７０５）。つまり、ＩＣＳソフトウェア５０１は、ＶＭの料金とＮＷ料金の合計を算出する。

そして、ＩＣＳソフトウェア５０１は、合計が記録最安プランより安いか否かを判定する（ステップＳ１７０６）。つまり、ＩＣＳソフトウェア５０１は、ループを実行する過程にて算出されたＶＭの料金とＮＷ料金の合計の最安値と比較して、ステップＳ１７０５にて算出した直近の合計金額が安いか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、記録最安プランより安いと判定した場合には（ステップＳ１７０６肯定）、処理対象となる該当プランを最安プランとして記録する（ステップＳ１７０７）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランについての金額が、最安値となる。一方、ＩＣＳソフトウェア５０１は、記録最安プランより安いと判定しなかった場合には（ステップＳ１７０６否定）、直近に算出した合計金額を最安値として記憶することなく、次の処理に進む。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分ループＥＮＤまでの処理を繰り返すと（ステップＳ１７０８）、最安値が利用者制約条件の所定コスト以下であるか否かを判定する（ステップＳ１７０９）。つまり、ＩＣＳソフトウェア５０１は、算出した合計金額を最安値が、制約条件により示される料金の上限以下となるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、最安値が利用者制約条件の所定コスト以下であると判定した場合には（ステップＳ１７０９肯定）、記録してある最もコストの安いプランを出力する（ステップＳ１７１０）。つまり、ＩＣＳソフトウェア５０１は、合計金額を最安値となったプランをリソース割当として出力する。

一方、ＩＣＳソフトウェア５０１は、最安値が利用者制約条件の所定コスト以下でないと判定した場合には（ステップＳ１７０９否定）、解なしとして出力する（ステップＳ１７１１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるリスト各々が、制約条件により示される料金の上限を満たさないことを踏まえ、プランなしとして出力する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップ１７０２〜Ｓ１７０４を任意の順番にて実行しても良い。

［利用者所在地-ＤＣ間のＮＷ料金合計を算出］
図４３は、実施例２における利用者所在地-ＤＣ間のＮＷ料金合計を算出する流れの一例を示すフローチャートである。図４３は、処理対象となるプランにおいて、全てのユーザ所在地とＤＣ６０５との間において、最も安いＮＷのクラスの料金の合計を算出する処理を示す。図４３に示す一連の処理は、図４２におけるステップＳ１７０３に対応する。

図４３に示すように、ＩＣＳソフトウェア５０１は、合計値をクリアする（ステップＳ１８０１）。つまり、ＩＣＳソフトウェア５０１は、ユーザ所在地-ＤＣ６０５間の、ＮＷ料金の最安合計値を積算する前にメモリをクリアする。

そして、ＩＣＳソフトウェア５０１は、処理対象となるプラン内のＤＣの個数分、処理をループする（ステップＳ１８０２）。つまり、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分ループＥＮＤ（ステップＳ１８０７）となるまで処理を繰り返すことで、処理対象となるプランに含まれるＤＣ６０５各々についてチェックする。

具体的には、ＩＣＳソフトウェア５０１は、処理対象となる該当ＤＣ６０５に対応するＤＣ別ＮＷ制約リストの利用者所在地の個数分、処理をループする（ステップＳ１８０３）。つまり、ＩＣＳソフトウェア５０１は、該当ＤＣに対応するＤＣ別ＮＷ制約リストの利用者所在地の個数分ループＥＮＤ（ステップＳ１８０６）となるまで処理を繰り返すことで、処理対象となるＤＣ６０５について、ユーザの所在地全てについてチェックする。

ここで、ＩＣＳソフトウェア５０１は、ＤＣ６０５と利用者の所在地との間における最安クラス料金を選択する（ステップＳ１８０４）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５とユーザの所在との間におけるネットワーク６０８のうち、最も安価となるネットワーク６０８の料金を選択する。

そして、ＩＣＳソフトウェア５０１は、合計に料金を加算する（ステップＳ１８０５）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ１８０２からＳ１８０７までのループにおいて、ステップＳ１８０４にて選択された料金を積算する。

そして、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５について、利用者の所在地各々についての処理を終了し（ステップＳ１８０６）、処理対象となるプランに含まれるＤＣ６０５各々についての処理を終了すると（ステップＳ１８０７）、合計値を出力する（ステップＳ１８０８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて、ユーザの全ての所在地とＤＣ６０５とを接続する上で必要となるネットワーク６０８の合計金額の最安値を出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［ＤＣ６０５−ＤＣ６０５間のＮＷ料金合計を算出］
図４４は、実施例２におけるＤＣ−ＤＣ間のＮＷ料金合計を算出する流れの一例を示すフローチャートである。図４４は、処理対象となるプランにおいて、全てのＤＣ６０５間において、最も安いＮＷのクラスの料金の合計を算出する処理を示す。図４４に示す一連の処理は、図４２におけるステップＳ１７０４に対応する。

図４４に示すように、ＩＣＳソフトウェア５０１は、合計値をクリアする（ステップＳ１９０１）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ６０５間を接続するＮＷ６０８の料金の最安合計値を積算する前にメモリをクリアする。

そして、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストのＤＣ６０５−ＤＣ６０５間個数分、処理をループする（ステップＳ１９０２）。つまり、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストのＤＣ−ＤＣ間個数分ループＥＮＤ（ステップＳ１９０５）となるまで処理を繰り返すことで、処理対象となるプランに含まれるＤＣ６０５間各々全てについてチェックする。

具体的には、ＩＣＳソフトウェア５０１は、ＤＣ６０５−ＤＣ６０５間の最安クラス料金を選択する（ステップＳ１９０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５間について、最も料金の安いネットワーク６０８を選択する。つまり、処理対象となるＤＣ６０５間にあるネットワーク６０８において、最も料金の安いクラスを選択する。

そして、ＩＣＳソフトウェア５０１は、合計に料金を加算する（ステップＳ１９０４）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ１９０２からＳ１９０５までのループにおいて、ステップＳ１９０３にて選択された料金を積算する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ６０５間各々についての処理が終了すると（ステップＳ１９０５）、合計値を出力する（ステップＳ１９０６）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて、ＤＣ６０５間を接続する上で必要となるネットワーク６０８の合計金額の最安値を出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［帯域最大アルゴリズム］
図４５は、実施例２における帯域最大アルゴリズムによる処理の一例を示すフローチャートである。図４５は、プランの中から制約条件の価格を満たした上で、ネットワークの帯域の平均が最大となるプランを選択する処理を示す。すなわち、図４５では、プランのうち、料金の上限値を超えない範囲プランであって、利用者とデータセンタ６０５との間のネットワーク６０８の帯域と、データセンタ６０５間を接続するネットワーク６０８の帯域との平均帯域が最も大きくなるプランを出力する場合について説明する。なお、図４２に示す一連の処理は、図４１におけるステップＳ１６０３に対応する。

図４５に示すように、ＩＣＳソフトウェア５０１は、プラン内で最小のＤＣ使用数を記録する（ステップＳ２００１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプランのうち、ＤＣ６０５の使用数が少ないプランのＤＣ使用数を記録する。例えば、ＤＣ６０５の使用数が「１」となるプランが含まれる場合には、後述するステップＳ２００３に示されるように、ＩＣＳソフトウェア５０１は、「１」を記憶し、ＤＣ６０５の使用数が「１」となるプランが以降の処理対象とする。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分、処理をループする（ステップＳ２００２）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、ＮＷ制約プランの個数分ループＥＮＤ（ステップＳ２００９）までの処理を繰り返す。

ここで、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて使用されるＤＣ６０５の数が、最小ＤＣ使用数を超えないか否かを判定する（ステップＳ２００３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランに含まれるＤＣ６０５の数が、ステップＳ２００１にて記憶した最小のＤＣ使用数となるか否かを判定する。例えば、ＩＣＳソフトウェア５０１は、ＤＣ６０５の使用数が「１」である場合には、ＤＣ６０５の使用数が「１」となるプランについてのみ、以降の処理対象となる。

そして、ＩＣＳソフトウェア５０１は、最小ＤＣ使用数を超えると判定した場合には（ステップＳ２００３否定）、処理対象となるプランについてのループ処理を終了する。

一方、ＩＣＳソフトウェア５０１は、最小ＤＣ使用数を超えないと判定した場合には（ステップＳ２００３肯定）、プランのＶＭ料金を合算しＤＣ料金を算出する（ステップＳ２００４）。つまり、ＩＣＳソフトウェア５０１は、ＶＭの割当数に、処理対象となるプランにおいて用いられるＤＣ６０５におけるＶＭタイプの料金を掛けた料金をＶＭタイプごとに合算し、処理対象となるプランにおけるＤＣ６０５についての料金を算出する。

そして、ＩＣＳソフトウェア５０１は、利用者所在地-ＤＣ間の対地リストを作成する（ステップＳ２００５）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて、全てのユーザ所在地とＤＣ６０５との間についての対地リストを作成する。なお、利用者所在地-ＤＣ間の対地リストは、処理対象となるプランに含まれるＤＣ６０５各々と、利用者の所在地各々との間の区間各々のリストとなる。言い換えると、利用者の所在地とＤＣ６０５とを接続するためのネットワーク６０８が用いられる区間各々のリストとなる。ステップＳ２００５の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ６０５−ＤＣ６０５間の対地リストを作成する（ステップＳ２００６）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランに含まれるＤＣ６０５間各々についての対地リストを作成する。なお、ステップＳ２００６の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、制約条件の最大価格を超えない、帯域最大となるクラスの組み合わせを選択する（ステップＳ２００７）。つまり、ＩＣＳソフトウェア５０１は、対地リストに含まれる区間各々について、制約条件を満たした上で帯域の平均値が最大となるネットワーク６０８のクラスの組み合わせを選択する（ステップＳ２００７）。なお、ステップＳ２００７の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、記録されたプランより選択したプランの帯域が大きければそのプランを記録する（ステップＳ２００８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランについての平均帯域が、プラン各々について今までに算出された値よりも高い場合いは、処理対象となったプランを帯域最大プランとして記録する。なお、ステップＳ２００８の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、ＮＷ制約プランの個数分ループＥＮＤとなると（ステップＳ２００９）、解があるか否かを判定する（ステップＳ２０１０）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について処理をループした結果、上述したステップＳ２００８において記録されたプランがあるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、解があると判定した場合には（ステップＳ２０１０肯定）、帯域最大プランを出力する（ステップＳ２０１１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプランのうち、平均帯域が最大となるプランをリソース割当として出力する。一方、ＩＣＳソフトウェア５０１は、解がないと判定した場合には（ステップＳ２０１０否定）、解なしとして出力する（ステップＳ２０１２）。つまり、ＩＣＳソフトウェア５０１は、制約条件を満たすプランが存在しない旨を出力する。

なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。例えば、上記のステップＳ２００５とＳ２００６とを入れ替えて実行しても良い。

［利用者所在地-ＤＣ間の対地リストを作成］
図４６は、実施例２における利用者所在地-ＤＣ間の対地リストを作成する流れの一例を示すフローチャートである。図４６に示す一連の処理は、図４５のステップＳ２００５に対応する。つまり、以下では、処理対象となるプランについて、利用者の所在地とＤＣ６０５とを接続するためのネットワーク６０８が用いられる区間各々のリストを作成する場合について説明する。

図４６に示すように、ＩＣＳソフトウェア５０１は、対地リストを初期化する（ステップＳ２１０１）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて対地リストを作成する前に、メモリをクリアする。

そして、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分、処理をループする（ステップＳ２１０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランに含まれるＤＣ６０５各々について、プラン内のＤＣの個数分ループＥＮＤ（ステップＳ２１０６）となるまで処理を繰り返すことで、プラン内のユーザ所在地とＤＣ６０５との間の区間全てをリストアップする。

具体的には、ＩＣＳソフトウェア５０１は、該当ＤＣに対応するＤＣ別ＮＷ制約リストの利用者所在地の個数分、処理をループする（ステップＳ２１０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５について、該当ＤＣに対応するＤＣ別ＮＷ制約リストの利用者所在地の個数分ループＥＮＤ（ステップＳ２１０５）となるまで処理を繰り返すことで、処理対象となったＤＣ６０５と利用者の所在地との間の区間全てをリストアップする。

ＩＣＳソフトウェア５０１は、ＤＣ、利用者所在地間を対地リストに追加する（ステップＳ２１０４）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったＤＣ６０５と利用者の所在地との間の区間を対地リストに登録する。

そして、ＩＣＳソフトウェア５０１は、該当ＤＣに対応するＤＣ別ＮＷ制約リストの利用者所在地の個数分ループＥＮＤ（ステップＳ２１０５）となり、プラン内のＤＣの個数分ループＥＮＤ（ステップＳ２１０６）となると、対地リストを出力する。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランに含まれるＤＣ６０５全てについて、利用者の全所在地との間の区間を対地リストにリストアップすると、作成した対地リストを出力する（ステップＳ２１０７）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［ＤＣ−ＤＣ間の対地リストを作成］
図４７は、実施例２におけるＤＣ−ＤＣ間の対地リストを作成する流れの一例を示すフローチャートである。図４７に示す一連の処理は、図４５のステップＳ２００６に対応する。つまり、以下では、処理対象となるプランに含まれるＤＣ６０５各々間の箇所各々のリストを作成する場合について説明する。

図４７に示すように、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストのＤＣ−ＤＣ間個数分、処理をループする（ステップＳ２２０１）。つまり、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストのＤＣ−ＤＣ間個数分ループＥＮＤ（ステップＳ２２０３）となるまで、処理を繰り返すことで、処理対象となるプランに含まれるＤＣ６０５各々全てについて、処理を実行する。

そして、ＩＣＳソフトウェア５０１は、ＤＣ６０５−ＤＣ６０５間を対地リストに追加する（ステップＳ２２０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるＤＣ６０５間の区間を対地リストに登録する。なお、対地リストには、図４６に示す一連の処理の結果、利用者の全所在地との間の区間が既に登録されている。

そして、ＩＣＳソフトウェア５０１は、プラン別ＮＷ制約リストのＤＣ−ＤＣ間個数分ループＥＮＤ（ステップＳ２２０３）となると、対地リストを出力する（ステップＳ２２０４）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ６０５各々とユーザの所在地全てとの間についての全区間に加え、ＤＣ６０５間の全区間が登録された対地リストを出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［制約条件の最大価格を超えない、帯域最大となるクラスの組み合わせを選択］
図４８は、実施例２における制約条件の最大価格を超えない、帯域最大となるクラスの組み合わせを選択する流れの一例を示すフローチャートである。つまり、以下では、対地リストに含まれる全区間についてのネットワーク６０８の組み合わせのうち、制約条件を満たした上で帯域の平均が最大となる組み合わせを選択する処理について説明する。図４８に示す一連の処理は、図４５のステップＳ２００７に対応する。

なお、以下では、対地リストにＮ個の区画が登録されている場合を用いて説明する。つまり、ＤＣ６０５間の区間やＤＣ６０５とユーザの所在地との間の区間がＮ個あり、Ｎ個の区間各々についてネットワーク６０８を割り当てることになる場合を用いて説明する。

図４８に示すように、ＩＣＳソフトウェア５０１は、対地リスト１のクラス個数分、選択可能なネットワーク６０８を選択する処理をループし（ステップＳ２３０１）、同様に、対地リストＮのクラス個数分、選択可能なネットワーク６０８を選択する処理をループする（ステップＳ２３０２）。つまり、ＩＣＳソフトウェア５０１は、（ステップＳ２３０１）及び（ステップＳ２３０２）により、対地リストに含まれる区間各々についてループを実行する。具体的には、ＩＣＳソフトウェア５０１は、対地リストＮのクラス個数分ループＥＮＤ（ステップＳ２３０６）となり、対地リスト１のクラス個数分ループＥＮＤ（ステップＳ２３０７）となるまで処理を繰り返すことで、対地リストに含まれる区間各々について、各区間において選択可能なネットワーク６０８の組み合わせ全てについて処理を繰り返す。

ここで、ＩＣＳソフトウェア５０１は、処理対象となった区間ごとに選択されたネットワーク６０８の組み合わせについて、ＶＭ分を加えて制約条件の最大価格を超えないかを判定する（ステップＳ２３０３）。つまり、ＩＣＳソフトウェア５０１は、選択されたネットワーク６０８の組み合わせによる料金と、ＶＭの料金とを合計した金額が、制約条件により示される料金の上限を超えていないかを判定する。

そして、ＩＣＳソフトウェア５０１は、ＶＭ分を加えて制約条件の最大価格を超えたと判定した場合には（ステップＳ２３０３否定）、処理対象となったネットワーク６０８の組み合わせについて処理を終了する。一方、ＩＣＳソフトウェア５０１は、ＶＭ分を加えて制約条件の最大価格を超えないと判定した場合には（ステップＳ２３０３肯定）、最大記録より帯域が大きいかを判定する（ステップＳ２３０４）。つまり、ＩＣＳソフトウェア５０１は、今までに選択されたネットワーク６０８の組み合わせについての帯域と比較して、処理対象となるネットワーク６０８の組み合わせについての帯域が大きい否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、最大記録より帯域が大きいと判定した場合には（ステップＳ２３０４肯定）、最大記録にクラスの組み合わせを記録する（ステップＳ２３０５）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるネットワーク６０８の組み合わせを記録する。

そして、ＩＣＳソフトウェア５０１は、対地リストに含まれる区間各々について、各区間において選択可能なネットワーク６０８の組み合わせ全てについて処理を繰り返すと（ステップＳ２３０６、ステップＳ２３０７）、記録されたクラスの組み合わせを出力（ステップＳ２３０８）。つまり、ＩＣＳソフトウェア５０１は、制約条件により示される料金の上限以下となり、対地リストに含まれる区間全てについての帯域の平均値が最も高くなるネットワーク６０８の組み合わせを出力する。より詳細には、ＩＣＳソフトウェア５０１は、各区間において適用されるネットワーク６０８のクラスの組み合わせを出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［記録されたプランより選択したプランの帯域が大きければそのプランを記録］
図４９は、実施例２における記録されたプランより選択したプランの帯域が大きければそのプランを記録する流れの一例を示すフローチャートである。つまり、処理対象となるプランについて選択されたネットワーク６０８の組み合わせについての平均帯域が、今までに処理されたプランについての平均帯域より大きければ、処理対象となるプランを記録する。なお、図４９に示す一連の処理は、図４５のステップＳ２００８に対応する。

図４９に示すように、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、制約条件を超えない解はあるか否かを判定し（ステップＳ２４０１）、最大記録より帯域が大きいか否かを判定する（ステップＳ２４０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、制約条件を満たすネットワーク６０８のクラスの組み合わせが存在するかを判定し、既に処理済みのプランのうち最も平均帯域が高かったプランについての平均帯域よりも平均帯域が高いかを判定する。

ここで、ＩＣＳソフトウェア５０１は、制約条件を超えない解があると判定し（ステップＳ２４０１肯定）、最大記録より帯域が大きいと判定した場合には（ステップＳ２４０２肯定）、最大記録にプランを記録する（ステップＳ２４０３）。つまり、ＩＣＳソフトウェア５０１は、既に処理済みのプランのうち最も平均帯域が高かったプランとして、処理対象となるプランを記録する。

一方、ＩＣＳソフトウェア５０１は、制約条件を超えない解があると判定したり（ステップＳ２４０１否定）、最大記録より帯域が大きくないと判定したりした場合には（ステップＳ２４０２否定）、処理対象となるプランについての処理を終了する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［遅延最小アルゴリズム］
図５０は、実施例２における遅延最小アルゴリズムによる処理の一例を示すフローチャートである。図５０は、ＮＷ制約プランリストに含まれるプランの中から、制約条件の価格を満たした上で、ネットワークの遅延の平均が最小となるプランを選択する処理を示す。すなわち、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、利用者とデータセンタ６０５との間の区間と、データセンタ６０５間の区間とにおけるネットワーク６０８の組み合わせを算出し、各ネットワーク６０８の組み合わせにおけるネットワーク６０８の平均遅延を算出する。また、ＩＣＳソフトウェア５０１は、仮想マシンとネットワークの合計料金をそれぞれ計算する。また、ＩＣＳソフトウェア５０１は、コストが制約条件を超えない組み合わせの中、平均遅延の最も小さいデータセンタ６０５とネットワーク６０８との組み合わせを出力する。なお、図５０に示す一連の処理は、図４１におけるステップＳ１６０４に対応する。

図５０に示すように、ＩＣＳソフトウェア５０１は、プラン内で最小のＤＣ使用数を記録する（ステップＳ２５０１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプランのうち、ＤＣ６０５の使用数が最も少ないプランのＤＣ６０５使用数を記録する。

ここで、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分、処理をループする（ステップＳ２５０２）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分ループＥＮＤ（ステップＳ２５０９）となるまで処理を繰り返すことで、ＮＷ制約プランリストに含まれるプラン各々について処理を実行する。

具体的には、ＩＣＳソフトウェア５０１は、処理対象となるプランにおいて使用されるＤＣ６０５の数が、最小ＤＣ使用数を超えないか否かを判定する（ステップＳ２５０３）。ここで、ＩＣＳソフトウェア５０１は、最小ＤＣ使用数を超えると判定した場合には（ステップＳ２５０３否定）、処理対象となるプランについての処理を終了する。

一方、ＩＣＳソフトウェア５０１は、最小ＤＣ使用数を超えないと判定した場合には（ステップＳ２５０３肯定）、プランのＶＭ料金を合算しＤＣ料金を算出する（ステップＳ２５０４）。つまり、ＩＣＳソフトウェア５０１は、ＶＭの割当数に処理対象となるプランにおけるＤＣ６０５のＶＭタイプの料金を掛けた料金を算出し、ＶＭタイプごとに合算することで、プランのＤＣ料金を算出する。

そして、ＩＣＳソフトウェア５０１は、利用者所在地-ＤＣ６０５間の対地リストを作成し（ステップＳ２５０５）、ＤＣ６０５−ＤＣ６０５間の対地リストを作成する（ステップＳ２５０６）。なお、ステップＳ２５０５とＳ２５０６は、それぞれ、図４５におけるステップＳ２００５とＳ２００６とに対応する。

そして、ＩＣＳソフトウェア５０１は、制約条件の最大価格を超えない、遅延最小となるクラスの組み合わせを選択する（ステップＳ２５０７）。つまり、ＩＣＳソフトウェア５０１は、対地リストに含まれる区間各々についてのネットワーク６０８のクラスの全組み合わせから、制約条件を満たした上で、遅延の平均が最小となる組み合わせを選択する。なお、ステップＳ２５０５とＳ２５０７の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、記録されたプランより選択したプランの遅延が小さければそのプランを記録（ステップＳ２５０８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランについての遅延の平均値が、今までに処理済みのプランについての遅延のうち最小の値と比較して小さい場合には、遅延が最小となるプランとして処理対象となるプランを記憶する。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランに含まれるプラン全てについて処理を実行すると（ステップＳ２５０９）、解があるか否かを判定する（ステップＳ２５１０）。つまり、ＩＣＳソフトウェア５０１は、条件を満たすプランが存在するか確認する。ここで、ＩＣＳソフトウェア５０１は、解があると判定した場合には（ステップＳ２５１０肯定）、遅延が最小となったプランをリソース割当として出力する。（ステップＳ２５１１）。一方、ＩＣＳソフトウェア５０１は、解がないと判定した場合には（ステップＳ２５１０否定）、解なしとして出力する（ステップＳ２５１２）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［制約条件の最大価格を超えない、遅延最小となるクラスの組み合わせを選択］
図５１は、実施例２における制約条件の最大価格を超えない、遅延最小となるクラスの組み合わせを選択する流れの一例を示すフローチャートである。つまり、以下では、処理対象となるプランについて、対地リストに含まれる区間各々についてのネットワーク６０８の全組み合わせから、制約条件を満たした上で遅延の平均が最小となる組み合わせを選択する。なお、図５１に示す一連の処理は、図５０のステップＳ２５０７に対応する。

図５１に示すように、ＩＣＳソフトウェア５０１は、対地リスト１のクラス個数分、処理をループし（ステップＳ２６０１）、同様に、対地リストＮのクラス個数分、処理をループする（ステップＳ２６０２）。つまり、ＩＣＳソフトウェア５０１は、ステップＳ２６０１及びステップＳ２６０２により、対地リストに含まれる区間各々についてループを実行する。具体的には、ＩＣＳソフトウェア５０１は、対地リストＮのクラス個数分ループＥＮＤ（ステップＳ２６０６）となり、対地リスト１のクラス個数分ループＥＮＤ（ステップＳ２６０７）となるまで処理を繰り返すことで、対地リストに含まれる区間各々について、各区間において選択可能なネットワーク６０８の組み合わせ全てについて処理を繰り返す。

ここで、ＩＣＳソフトウェア５０１は、処理対象となった区間ごとに選択されたネットワーク６０８の組み合わせについて、ＶＭ分を加えて制約条件の最大価格を超えないかを判定する（ステップＳ２６０３）。つまり、選択されたネットワーク６０８の組み合わせによる料金と、ＶＭの料金とを合計した金額が、制約条件により示される料金の上限を超えているか否かを判定する。

そして、ＩＣＳソフトウェア５０１は、ＶＭ分を加えて制約条件の最大価格を超えたと判定した場合には（ステップＳ２６０３否定）、処理対象となったネットワーク６０８の組み合わせについて処理を終了する。一方、ＩＣＳソフトウェア５０１は、ＶＭ分を加えて制約条件の最大価格を超えないと判定した場合には（ステップＳ２６０３肯定）、最小記録より遅延が小さいかを判定する（ステップＳ２６０４）。つまり、ＩＣＳソフトウェア５０１は、今までに選択されたネットワーク６０８の組み合わせについての遅延と比較して、処理対象となるネットワーク６０８の組み合わせについての遅延が小さいか否かを判定する。

そして、ＩＣＳソフトウェア５０１は、最小記録より遅延が小さいと判定した場合には（ステップＳ２６０４肯定）、最小記録にクラスの組み合わせを記録する（ステップＳ２６０５）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるネットワーク６０８の組み合わせを記録する。一方、ＩＣＳソフトウェア５０１は、最小記録より遅延が小さいと判定しなかった場合には（ステップＳ２６０４否定）、処理対象となったネットワーク６０８の組み合わせについて処理を終了する。

そして、ＩＣＳソフトウェア５０１は、対地リストに含まれる区間各々について、各区間において選択可能なネットワーク６０８の組み合わせ全てについて処理を繰り返すと（ステップＳ２６０６、ステップＳ２６０７）、記録されたクラスの組み合わせを出力する（ステップＳ２６０８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、制約条件により示される料金の上限以下となり、遅延が最小となるネットワーク６０８の組み合わせを出力する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［記録されたプランより選択したプランの遅延が小さければそのプランを記録開始］
図５２は、実施例２における記録されたプランより選択したプランの遅延が小さければそのプランを記録開始する流れの一例を示すフローチャートである。つまり、以下では、ＮＷ制約プランリストに含まれるプラン各々について算出される遅延のうち、遅延が最小となるプランを選択する処理について説明する。なお、図５２に示す一連の処理は、図５０のステップＳ２５０８に対応する。

図５２に示すように、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、制約条件を超えない解はあるか否かを判定し（ステップＳ２７０１）、最小記録より遅延が大小さいか否かを判定する（ステップＳ２７０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、制約条件を満たすネットワーク６０８のクラスの組み合わせが存在するかを判定し、既に処理済みのプランのうち最も平均帯域が高かったプランについての平均帯域よりも平均帯域が高いかを判定する。

ここで、ＩＣＳソフトウェア５０１は、制約条件を超えない解がないと判定し（ステップＳ２７０１肯定）、最小記録より遅延が小さいと判定した場合には（ステップＳ２７０２肯定）、最小記録にプランを記録する（ステップＳ２７０３）。つまり、ＩＣＳソフトウェア５０１は、既に処理済みのプランのうち最も遅延が小さかったプランとして、処理対象となるプランを記録する。

一方、ＩＣＳソフトウェア５０１は、制約条件を超えない解があると判定したり（ステップＳ２７０１否定）、最小記録より遅延が小さくないと判定したりした場合には（ステップＳ２７０２否定）、処理対象となるプランについての処理を終了する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［集中アルゴリズム］
図５３は、実施例２における集中アルゴリズムによる処理の一例を示すフローチャートである。図５３は、ＮＷ制約プランリストに含まれるプランのうち、制約条件の価格を満たした上で、ＤＣ６０５の使用率の分散が最大となるプランを選択する処理を示す。言い換えると、特定のＤＣ６０５に集中することになるプランを選択する場合について説明する。

すなわち、以下に説明するように、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、コストの最も小さいネットワーク６０８を選択し、各プランにおけるリソース割当後の各データセンタ６０５の使用率の分散値を算出する。また、ＩＣＳソフトウェア５０１は、仮想マシンとネットワークの合計料金を算出する。そして、ＩＣＳソフトウェア５０１は、制約条件により示される料金の上限以下となり、分散値が最も大きくなるプランをリソース割当として出力する。

図５３に示すように、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分、処理をループする（ステップＳ２８０１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、ＮＷ制約プランの個数分ループＥＮＤ（ステップＳ２８１０）までの処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、ＶＭプランの配分後の分散値を算出する（ステップＳ２８０２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランを実行した場合におけるＤＣ６０５の使用率の分散パラメータを算出する。より詳細な一例をあげて説明すると、ＩＣＳソフトウェア５０１は、各ＤＣ６０５のコアの使用率の分散パラメータを算出する。なお、ステップＳ２８０２の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、分散値が記録値以上となるか否かを判定する（ステップＳ２８０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて算出された分散パラメータの値が、今までに処理済みのプランについて算出された分散値の最大値よりも大きいか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、分散値が記録値以上とならない場合には（ステップＳ２８０３否定）、処理対象となるプランについての処理を終了する。一方、ＩＣＳソフトウェア５０１は、分散値が記録値以上となる場合には（ステップＳ２８０３肯定）、プランのＶＭ料金を合算しＤＣ料金を算出する（ステップＳ２８０４）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、ＶＭの割当数に、処理対象となるプランにおけるＤＣ６０５のＶＭタイプの料金を掛けて算出し、算出した料金を合算することでプランのＤＣ６０５についての合計金額を算出する。

そして、ＩＣＳソフトウェア５０１は、利用者所在地-ＤＣ６０５間のＮＷ料金合計を算出し（ステップＳ２８０５）、ＤＣ６０５−ＤＣ６０５間のＮＷ料金合計を算出する（ステップＳ２８０６）。なお、ステップＳ２８０５とＳ２８０６とは、それぞれ、図４２のステップＳ１７０３とＳ１７０４とに対応する。

そして、ＩＣＳソフトウェア５０１は、各料金を合算する（ステップＳ２８０７）。つまり、ＩＣＳソフトウェア５０１は、ＶＭの料金とＮＷ料金の合計を算出する。

そして、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下であるか否かを判定する（ステップＳ２８０８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランの料金が、制約条件により示される料金の上限以下となるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下となると判定した場合には（ステップＳ２８０８肯定）、処理対象となるプランを最集中プランとして記録する（ステップＳ２８０９）。一方、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下とならないと判定した場合には（ステップＳ２８０８否定）、処理対象となったプランについての処理を終了する。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分ループＥＮＤまでの処理を繰り返すと（ステップＳ２８１０）、解があるか否かを判定する（ステップＳ２８１１）。ここで、ＩＣＳソフトウェア５０１は、解があると判定した場合には（ステップＳ２８１１肯定）、記録してあるプランを出力する（ステップＳ２８１２）。すなわち、ここで出力されたプランが、リソース割当となる。一方、ＩＣＳソフトウェア５０１は、解がないと判定した場合には（ステップＳ２８１１否定）、解なしとして出力する（ステップＳ２８１３）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［ＶＭプランの配分後の分散値を算出］
図５４は、実施例２におけるＶＭプランの配分後の分散値の算出の流れの一例を示す図である。図５４に示す一連の処理は、図５３におけるステップＳ２８０２に対応する。

図５４に示すように、ＩＣＳソフトウェア５０１は、全ＤＣの個数分、処理をループする（ステップＳ２９０１）。つまり、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分ループＥＮＤ（ステップＳ２９０４）となるまで処理を繰り返すことで、処理対象となったプランに含まれるＤＣ６０５各々について、処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、各ＤＣのコア使用率を取得する（ステップＳ２９０２）。つまり、ＩＣＳソフトウェア５０１は、空きリソース情報から、処理対象となるＤＣ６０５についてのコア使用率と総コア数とを取得する。そして、ＩＣＳソフトウェア５０１は、処理対象となったプランのＶＭ配分後のＤＣの使用率を算出する（ステップＳ２９０３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランを実行した場合に、処理対象となるＤＣ６０５の使用率を算出する。

そして、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分ループＥＮＤとなると（ステップＳ２９０４）、すなわち、処理対象となるプランについて、ＤＣ６０５各々について使用率を算出すると、ＤＣ６０５のコア使用率平均を求める（ステップＳ２９０５）。つまり、ＩＣＳソフトウェア５０１は、ＤＣ６０５各々について算出した使用率の平均値を算出する。

そして、ＩＣＳソフトウェア５０１は、処理対象となったプランに含まれる全ＤＣの個数分、処理をループする（ステップＳ２９０６）。つまり、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分ループＥＮＤ（ステップＳ２９０９）となるまで処理を繰り返すことで、処理対象となったプランに含まれる全ＤＣ６０５各々について処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、各ＤＣの配分後コア使用率の偏差を計算し（ステップＳ２９０７）、偏差の２乗を積算する（ステップＳ２９０８）。

そして、ＩＣＳソフトウェア５０１は、プラン内のＤＣの個数分ループＥＮＤとなると（ステップＳ２９０９）、偏差の２乗の平均値を出力する（ステップＳ２９１０）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランについての分散値を算出する。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

［分散アルゴリズム］
図５５は、実施例２における分散アルゴリズムによる処理の流れの一例を示すフローチャートである。図５５は、ＮＷ制約プランリストに含まれるプランのうち、制約条件により示される料金の上限を満たした上で、ＤＣ６０５の使用率の分散が最小となるプランを選択する処理を示す。言い換えると、全体のＤＣに使用率が分散することになるプランを選択する場合について説明する。

すなわち、以下に説明するように、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、コストの最も小さいネットワーク６０８の組み合わせを選択する。また、ＩＣＳソフトウェア５０１は、各プランにおける配分後の分散値を算出し、分散値が最も小さくなるプランをリソース割当として出力する。

図５５に示すように、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分、処理をループする（ステップＳ３００１）。つまり、ＩＣＳソフトウェア５０１は、ＮＷ制約プランリストに含まれるプラン各々について、ＮＷ制約プランの個数分ループＥＮＤ（ステップＳ３０１０）までの処理を繰り返す。

具体的には、ＩＣＳソフトウェア５０１は、ＶＭプランの配分後の分散値を算出する（ステップＳ３００２）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランを実行した場合におけるＤＣ６０５の使用率の分散パラメータを算出する。より詳細な一例をあげて説明すると、ＩＣＳソフトウェア５０１は、各ＤＣ６０５のCoreの使用率の分散パラメータを算出する。なお、ステップＳ３００２の詳細については後述する。

そして、ＩＣＳソフトウェア５０１は、分散値が記録値以下となるか否かを判定する（ステップＳ３００３）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて算出された分散パラメータの値が、今までに処理済みのプランについて算出された分散値の最大値よりも小さいか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、分散値が記録値以下とならない場合には（ステップＳ３００３否定）、処理対象となるプランについての処理を終了する。一方、ＩＣＳソフトウェア５０１は、分散値が記録値以下となる場合には（ステップＳ３００３肯定）、プランのＶＭ料金を合算しＤＣ料金を算出する（ステップＳ３００４）。つまり、ＩＣＳソフトウェア５０１は、処理対象となるプランについて、ＶＭの割当数に、処理対象となるプランにおけるＤＣ６０５のＶＭタイプの料金を掛けて算出し、算出した料金を合算することでプランのＤＣ６０５についての合計金額を算出する。

そして、ＩＣＳソフトウェア５０１は、利用者所在地-ＤＣ間のＮＷ料金合計を算出し（ステップＳ３００５）、ＤＣ６０５−ＤＣ６０５間のＮＷ料金合計を算出する（ステップＳ３００６）。なお、ステップＳ３００５とＳ３００６とは、それぞれ、図４２のステップＳ１７０３とＳ１７０４とに対応する。

そして、ＩＣＳソフトウェア５０１は、各料金を合算する（ステップＳ３００７）。つまり、ＩＣＳソフトウェア５０１は、ＶＭの料金とＮＷ料金の合計を算出する。

そして、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下であるか否かを判定する（ステップＳ３００８）。つまり、ＩＣＳソフトウェア５０１は、処理対象となったプランの料金が、制約条件により示される料金の上限以下となるか否かを判定する。

ここで、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下となると判定した場合には（ステップＳ３００８肯定）、処理対象となるプランを最分散プランとして記録する（ステップＳ３００９）。一方、ＩＣＳソフトウェア５０１は、合計額が利用者制約条件の最大価格以下とならないと判定した場合には（ステップＳ３００８否定）、処理対象となったプランについての処理を終了する。

そして、ＩＣＳソフトウェア５０１は、ＮＷ制約プランの個数分ループＥＮＤまでの処理を繰り返すと（ステップＳ３０１０）、解があるか否かを判定する（ステップＳ３０１１）。ここで、ＩＣＳソフトウェア５０１は、解があると判定した場合には（ステップＳ３０１１肯定）、記録してあるプランを出力する（ステップＳ３０１２）。すなわち、ここで出力されたプランが、リソース割当となる。一方、ＩＣＳソフトウェア５０１は、解がないと判定した場合には（ステップＳ３０１１否定）、解なしとして出力する（ステップＳ３０１３）。なお、上記の処理手順は、上記の順番に限定されるものではなく、処理内容を矛盾させない範囲で適宜変更しても良い。

以下では、空きリソース情報と利用状況情報とを管理装置から収集する場合における割当決定装置の構成の一例について説明する。図５６は、実施例３における空きリソース情報と利用状況情報とを管理装置から収集する割当決定装置の構成の一例を示すブロック図である。

図５６に示す例では、割当決定装置８００は、管理装置やユーザ端末と情報を送受信する通信部８０１と、記憶部８１０と、制御部８２０とを有する。また、記憶部８１０は、制約条件テーブル８１１と、リソース情報テーブル８１２とを有する。ここで、制約条件テーブル８１１と、リソース情報テーブル８１２とは、それぞれ、制約条件テーブル１１１と、リソース情報テーブル１１２及び管理情報ＤＢ５１２に対応するため、説明を省略する。

制御部８２０は、受信部８２１と、収集部８２２と、過不足判定部８２３と、決定部８２４と、割当出力部８２５と、制約条件判定部８２６と、判定結果出力部８２７とを有する。ここで、制御部１２０の各部は、決定部８２４に対応する。

受信部８２１は、新規割当要求や割当廃止要求、判定指示を受信する。ここで、受信部８２１は、新規割当要求を受信すると、受信した新規割当要求に含まれる制約条件を制約条件テーブル８１１に格納する。例えば、受信部８２１は、ユーザＩＤ「ＵＳＥＲ０００１」により送信された新規割当要求を受信した場合には、ユーザＩＤ「ＵＳＥＲ０００１」と制約条件との対応付けを制約条件テーブル８１１に格納する。

また、受信部８２１は、割当廃止要求を受信すると、割当廃止要求の送信元となるユーザについての制約条件を制約条件テーブル８１１から削除する。例えば、受信部８２１は、ユーザＩＤ「ＵＳＥＲ０００３」から新規割当要求を受信すると、ユーザＩＤ「ＵＳＥＲ０００３」に対応付けられた制約条件を制約条件テーブル８１１から削除する。

収集部８２２は、異なる種類のリソースを提供する各々の管理装置２００各々について、リソースの状況を示す情報を収集する。例えば、収集部８２２は、管理装置各々から、空きリソース情報とユーザごとの利用状況情報を収集する。つまり、異なる種類のリソースを提供する各々のクラウドシステム各々について、リソースの状況を示す情報を収集する。

例えば、収集部８２２は、異なる事業者により割り当てられるリソース各々について、リソースの状況を示す情報を収集する。また、例えば、収集部８２２は、異なる種類のリソース各々について、リソースの状況を示す情報を収集する。

例えば、収集部８２２は、空きリソース情報として、リソースの総量と、割り当てられていないリソースについての情報とを収集する。また、例えば、収集部８２２は、リソースについての情報として、リソースの利用料金の値や、リソースの属性などを収集する。また、例えば、収集部８２２は、利用状況情報として、割り当てられたリソースのうち、実際に利用されているリソースについての情報と、利用されていないリソースについての情報とを収集する。

ネットワークのリソースについて収集する場合を用いて、更に詳細な一例をあげて説明する。収集部８２２は、空きリソース情報として、ネットワークの確保済帯域と未確保帯域と総帯域とを収集したり、ネットワークの遅延値を収集したりする。また、収集部８２２は、利用状況情報として、ネットワークの利用帯域と未利用帯域と総帯域とを収集したり、ネットワークの遅延値を収集したりする。

サーバのリソースについて収集する場合を用いて、更に詳細な一例をあげて説明する。収集部８２２は、空きリソース情報として、サーバのＣＰＵ、メモリ並びにディスクの割当状況と未割当状況と総量とを収集する。また、収集部８２２は、利用状況情報として、サーバのＣＰＵ、メモリ並びにディスクの利用状況と未利用状況と総量とを収集する。

なお、収集部８２２は、任意のタイミングにて、空きリソース情報や利用状況情報を収集する。例えば、利用者によって予め設定されたタイミングにて、空きリソース情報や利用状況情報を収集する。また、収集部８２２は、受信部８２１によって新規割当要求が受信されると、空きリソース情報を収集する。また、収集部８２２は、受信部８２１によって割当廃止要求が受信されると、利用状況情報を収集する。また、収集部８２２は、受信部８２１によって判定指示が受信されると、利用状況情報を収集する。

過不足判定部８２３は、収集部８２２により異なる種類のリソース各々について収集された利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を判定する。例えば、過不足判定部８２３は、ネットワークのリソースについての利用状況情報と、サーバのリソースについての利用状況情報とをくくりつけた上で解析することで、異なるリソース各々についてのユーザ毎の過不足を判定する。また、過不足判定部８２３は、利用状況情報に加えて、制約条件テーブル８１１に格納された制約条件を用いて過不足を判定する。

例えば、過不足判定部８２３は、利用状況情報を解析することで、割り当てられたリソースにおいて利用されていないリソースが占める割合を識別し、識別した割合が所定の割合以下になった場合に、不足していると判定する。また、同様に、過不足判定部８２３は、利用状況情報を解析することで、割り当てられたリソースにおいて利用されていないリソースが占める割合を識別し、識別した割合が所定の割合以上になった場合に、余っていると判定する。

また、ネットワークのリソースを例に、制約条件を併せて用いて過不足を判定する場合について説明する。例えば、過不足判定部８２３は、制約条件テーブル８１１から、リソースの上限値「１００Ｍｂｐｓ」と、リソースの下限値「１０Ｍｂｐｓ」とを制約条件として読み出した場合を用いて更に説明する。また、「５０Ｍｂｐｓ」のネットワークのリソースが割り当てられており、「５０Ｍｂｐｓ」のネットワークのリソース全てが利用されている場合を用いて説明する。この場合、過不足判定部８２３は、割り当てられた全てのリソースが利用されており、割り当てられているリソース量がリソースの上限値「１００Ｍｂｐｓ」に達していないので、不足していると判定する。

なお、上述した過不足判定部８２３による判定処理は一例であり、任意の手法を用いて判定して良い。例えば、上述した説明では、利用されていないリソースが占める割合に基づいて過不足を判定する場合について説明したが、これに限定されるものではなく、任意の手法を用いて判定して良い。

決定部８２４は、リソースの割当を決定する。具体的には、以下に説明するように、受信部８２１により新規割当要求又は割当廃止要求が受信された場合や、過不足判定部８２３により不足していると判定されたり余っていると判定されたりした場合に、リソースの割当を決定する。

例えば、決定部８２４は、受信部８２１により新規割当要求が受信された場合には、新規割当要求により示されるリソースを割り当てるリソースの割当を決定する。また、例えば、決定部８２４は、受信部８２１により割当廃止要求が受信された場合には、割当廃止要求により示されるリソース割当を解消するリソースの割当を決定する。

受信部８２１により新規割当要求が受信された場合について、より詳細な一例をあげて説明する。上述したように、受信部８２１は、新規割当要求を受信すると、受信した新規割当要求に含まれる制約条件を制約条件テーブル８１１に格納する。この場合、決定部８２４は、受信部８２１によって新たな制約条件が制約条件テーブル８１１に格納されると、新たに格納された制約条件を満たすリソースを割り当てるリソース割当を決定する。

受信部８２１により割当廃止当要求が受信された場合について、より詳細な一例をあげて説明する。上述したように、受信部８２１は、割当廃止要求を受信すると、受信した割当廃止要求に含まれる制約条件を制約条件テーブル８１１から削除する。この場合、決定部８２４は、受信部８２１によって制約条件が制約条件テーブル８１１から削除されると、削除された制約条件についての割り当てを開放するリソース割当を決定する。

また、決定部８２４は、過不足判定部８２３によりリソースが不足していると判定された場合には、空きリソース情報により示される空きリソースを追加するリソースの割当を決定する。具体的には、決定部８２４は、空き状況情報により示される異なる種類の空きリソースをくくりつけ、くくりつけた中からリソース割当を決定する。また、決定部８２４は、過不足判定部８２３によりリソースが余っていると判定された場合には、利用状況情報により示される利用中のリソースを開放するリソース割当を決定する。

ここで、決定部８２４により割り当てられるリソースについて更に説明する。決定部８２４は、制約条件を満たすリソースの割当を決定する。言い換えると、決定部８２４は、空きリソース情報により示される空きリソースのうち、制約条件を満たす任意の空きリソースを割り当てる割り当てを決定する。

また、決定部８２４は、ユーザごとのリソース割当を決定する。言い換えると、例えば、決定部８２４は、割り当てを決定する対象となるユーザについての制約条件を制約条件テーブル８１１から取得し、空きリソース情報により示される空きリソースのうち、制約条件を満たす任意のリソースを割り当てるリソース割当を決定する。

また、決定部８２４により開放されるリソースについて更に説明する。決定部８２４は、例えば、制約条件を満たすリソースの割当を決定する。言い換えると、決定部８２４は、利用状況情報により示される利用中のリソースのうち、任意のリソースを開放する。なお、決定部８２４による処理の詳細については、実施例１や実施例２にて詳細に説明したことを踏まえ、説明を省略する。

割当出力部８２５は、決定部８２４により決定されたリソース割当を出力する。具体的には、割当出力部８２５は、ユーザごとのリソース割当を出力する。また、割当出力部８２５は、リソースを管理する管理装置にリソース割当を通知することで、決定部８２４により決定されたリソースの割当を管理装置に実行させる。

制約条件判定部８２６は、収集部８２２により収集された利用状況情報を解析することで、既に割り当てられているリソースが制約条件を満たしているか否かを判定する。具体的には、制約条件判定部８２６は、利用状況情報に含まれる情報各々について、制約条件を満たしているか否かを判定する。

例えば、収集部８２２により収集されたユーザ「ＵＳＥＲ０００１」についての利用状況情報に、ネットワーク帯域「３０Ｍｂｐｓ」が含まれている場合を用いて説明する。この場合、制約条件判定部８２６は、制約条件テーブル８１１からユーザＩＤ「ＵＳＥＲ０００１」に対応付けられた制約条件として、リソースの上限値「１００Ｍｂｐｓ」とリソースの下限値「１０Ｍｂｐｓ」とを取得する。そして、制約条件判定部８２６は、利用状況情報を解析することでリソース量を識別し、識別したリソース量が「１００Ｍｂｐｓ」から「１０Ｍｂｐｓ」との間にあるか否かを判定する。ここで、制約条件判定部８２６は、例えば、識別したリソース量が「３０Ｍｂｐｓ」であり、制約条件を満たしていると判定する。

なお、制約条件判定部８２６は、任意のタイミングにて判定処理を実行する。例えば、受信部８２１によって判定指示が受信され、収集部８２２によって利用状況情報が収集されると、制約条件判定部８２６は、判定処理を実行する。また、例えば、制約条件判定部８２６は、判定処理を受信部８２１が受信したか否かに関係なく、任意のタイミングにて判定処理を実行する。

判定結果出力部８２７は、制約条件判定部８２６による判定結果を出力する。具体的には、判定結果出力部８２７は、リソースの過不足を判定するための情報として判定結果を過不足判定部８２３に出力する。その後、過不足判定部８２３は、判定結果出力部８２７により出力された判定結果を用いて、過不足を判定することになる。

また、例えば、判定結果出力部８２７は、判定結果をユーザ端末３００に出力する。より詳細な一例をあげて説明すると、判定結果出力部８２７は、制約条件判定部８２６により満たしていると判定されると、満たしている旨の判定結果をユーザ端末３００に出力し、制約条件判定部８２６により満たしていないと判定されると、満たしていない旨の判定結果をユーザ端末３００に出力する。ここで、判定結果出力部８２７は、例えば、判定結果を、判定の対象となったリソースの割当先となるユーザにより用いられるユーザ端末３００に出力する。

なお、上述した割当決定装置１００や管理装置は、例えば、任意のサーバが該当する。また、ユーザ端末３００は、例えば、パーソナルコンピュータやＰＤＡ（Personal Data Assistance）、あるいは携帯電話やＰＨＳの如き移動体通信端末などが該当する。例えば、割当決定装置１００は、任意のサーバに対して、図１に示した記憶部１１０や制御部１２０などの各機能を搭載することによって実現される。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、その他の実施例にて実施されても良い。そこで、以下では、その他の実施例を示す。

［ログイン機能］
例えば、割当決定装置は、アクセス時に、パスワードを要求しても良い。すなわち、システムの使用時に許可されたオペレータのみがログインできるように、ログイン時にユーザ名とパスワードとを用いて認証処理を実行しても良い。

［システム構成］
また、本実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は１部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は１部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については（図１〜図５７）、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、図１に示す例では、記憶部１１０を割当決定装置１００の外部装置としてネットワーク経由で接続するようにしても良い。

［プログラム］
図５７は、インタークラウドサーバによる一連の処理を実行するプログラムであるリソース管理プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。図５７に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０と、ハードディスクドライブ３０８０と、ネットワークインタフェース３０７０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。

メモリ３０１０は、図５７に例示するように、ＲＯＭ３０１１及びＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。

ここで、図５７に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の技術に係るリソース管理プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。例えば、制御部１２０の各部と同様の情報処理を実行する手順各々が記述されたプログラムモジュール３０８３が、ハードディスクドライブ３０８０に記憶される。

また、記憶部１１０に記憶されるデータのように、リソース管理プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。

なお、リソース管理プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、更新プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ３０２０は、ネットワークインタフェース３０７０を介して他のコンピュータにアクセスすることで各種データを読み出す。

［その他］
なお、本実施例で説明したリソース管理プログラムは、インターネットなどのネットワークを介して配布することができる。また、リソース管理プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１００割当決定装置
１０１入力部
１０２出力部
１１０記憶部
１１１制約条件テーブル
１１２リソース情報テーブル
１２０制御部
１２１受付部
１２２生成部
１２３判定部
１２４選択部
２００管理装置
３００ユーザ端末
５００インタークラウドサーバ
５０１ＩＣＳソフトウェア
６０１オペレータ端末
６０２ＡＳＰ端末
６０５データセンタ
６０７ユーザ端末
６０８ネットワーク
７０１ＤＣ利用状況情報
７０２ＤＣ空きリソース情報
７０３ＮＷ利用状況情報
７０４ＮＷ空きリソース情報
７０５制約条件
７０６割当要求情報
７１１ＤＣ利用可能リソース情報
７１２ＮＷ利用可能リソース情報
７１３ＤＣ条件による制約ＤＣリスト
７１４ＮＷ条件による制約ＤＣリスト
７１５ＶＭタイプ別ＤＣ候補リスト
７１６ＶＭタイププランリスト
７１７ＮＷ制約プランリスト
７２１ＤＣ利用可能リソース計算
７２２ＮＷ利用可能リソース計算
８００割当決定装置
８０１通信部
８１０記憶部
８１１制約条件テーブル
８１２リソース情報テーブル
８２０制御部
８２１受信部
８２２収集部
８２３過不足判定部
８２４決定部
８２５割当出力部
８２６制約条件判定部
８２７判定結果出力部

Claims

異なる管理装置により提供される複数種類のリソースのうち異なる種類の前記リソースと併せて用いられる前記リソースの割り当てを要求する割当要求の入力を受け付ける受付部と、
複数ある前記リソース各々のうち、前記受付部により受け付けられた前記割当要求により要求されるリソースの種類に属する第１のリソースを選択し、第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースと前記第１のリソースとの対応付けを記憶するテーブルにより示されて選択した該第１のリソースと併せて用いられる種類の第２のリソースとの組み合わせを生成する生成部と、
前記生成部により生成された組み合わせについて、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが同時に利用可能であるか否かを判定することで、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが組み合わせ可能なリソースであるか否かを判定する判定部と、
前記判定部により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する選択部と、
前記選択部により選択された組み合わせを出力する出力部と
を備えたことを特徴とする割当決定装置。
前記判定部は、前記組み合わせに含まれる前記第１のリソースと前記第２のリソースとのうち少なくとも一方に、同一提供元により提供される異なる種類のリソースが含まれている場合に、前記異なる種類のリソース各々を前記提供元が同時に提供可能であるか否かを判定することを特徴とする請求項１に記載の割当決定装置。
前記第１のリソースは、データセンタのサーバリソースであり、前記第２のリソースは、ネットワークのリソースであって、
前記判定部は、前記組み合わせに含まれるネットワークのリソースが、ユーザの所在地と、前記サーバリソースの提供元となるデータセンタの所在地とを結ぶネットワークであるか否かを判定することで、前記組み合わせに含まれる前記サーバリソースと前記ネットワークのリソース各々を同時に提供可能であるか否かを判定することを特徴とする請求項１に記載の割当決定装置。
前記生成部は、前記第１のリソースと前記第２のリソースとに加えて、複数の該第１のリソース又は複数の該第２のリソースを用いる際に併せて用いられる種類のリソースである第３のリソースを更に組み合わせた組み合わせを生成することを特徴とする請求項１に記載の割当決定装置。
前記選択部は、前記判定部により組み合わせ可能なリソースであると判定された組み合わせから、前記組み合わせについての所定の基準に従って組み合わせを１つ選択することを特徴とする請求項１〜４のいずれか１つに記載の割当決定装置。
前記選択部は、前記所定の基準としての複数のアルゴリズムのうち任意のアルゴリズムのうち任意のアルゴリズムに従って組み合わせを１つ選択することを特徴とする請求項５に記載の割当決定装置。
前記選択部は、前記リソースの提供元による要求を満たす組み合わせを選択するアルゴリズムを所定の基準として用いて、前記判定部により組み合わせ可能なリソースであると判定された組み合わせから、組み合わせを１つ選択することを特徴とする請求項５又は６に記載の割当決定装置。
前記選択部は、前記アルゴリズムとして、前記判定部により組み合わせ可能なリソースであると判定された組み合わせ各々について、該組み合わせに含まれるリソースを割り当てた場合における前記複数あるリソースごとの割当状況を算出し、該組み合わせごとに算出された割当状況の前記複数あるリソース間における分散度合いを算出し、算出された分散度合いが高い組み合わせを前記分散度合いが低い組み合わせより優先して選択し、又は、算出された分散度合いが低い組み合わせを前記分散度合いが高い組み合わせより優先して選択するアルゴリズムを有することを特徴とする請求項７に記載の割当決定装置。
異なる管理装置により提供される複数種類のリソースのうち異なる種類の前記リソースと併せて用いられる前記リソースの割り当てを要求する割当要求の入力を受け付ける受付工程と、
複数ある前記リソース各々のうち、前記受付工程により受け付けられた前記割当要求により要求されるリソースの種類に属する第１のリソースを選択し、第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースと前記第１のリソースとの対応付けを記憶するテーブルにより示されて選択した該第１のリソースと併せて用いられる種類の第２のリソースとの組み合わせを生成する生成工程と、
前記生成工程により生成された組み合わせについて、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが同時に利用可能であるか否かを判定することで、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが組み合わせ可能なリソースであるか否かを判定する判定工程と、
前記判定工程により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する選択工程と、
前記選択工程により選択された組み合わせを出力する出力工程と
を含んだことを特徴とする割当決定方法。
異なる管理装置により提供される複数種類のリソースのうち異なる種類の前記リソースと併せて用いられる前記リソースの割り当てを要求する割当要求の入力を受け付ける受付部と、
複数ある前記リソース各々のうち、前記受付部により受け付けられた前記割当要求により要求されるリソースの種類に属する第１のリソースを選択し、第１のリソースが属する種類のリソースと併せて用いられる種類のリソースである第２のリソースと前記第１のリソースとの対応付けを記憶するテーブルにより示されて選択した該第１のリソースと併せて用いられる種類の第２のリソースとの組み合わせを生成する生成部と、
前記生成部により生成された組み合わせについて、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが同時に利用可能であるか否かを判定することで、該組み合わせに含まれる前記第１のリソースと前記第２のリソースとが組み合わせ可能なリソースであるか否かを判定する判定部と、
前記判定部により組み合わせ可能なリソースであると判定された組み合わせを１つ選択する選択部と、
前記選択部により選択された組み合わせを、前記リソースを管理する管理装置に出力する出力部と、
を備えた割当決定装置と、
前記割当決定装置により出力された組み合わせに基づくリソース割当を実行する割当部を備えたことを特徴とする前記管理装置と
を備えた割当システム。
コンピュータを請求項１〜８のいずれか１つに記載の割当決定装置として機能させるための割当決定プログラム。