JP5242717B2 - リソース管理サーバ、リソース管理システム、リソース管理方法及びリソース管理プログラム - Google Patents

Description

本発明は、リソース管理サーバ、リソース管理システム、リソース管理方法及びリソース管理プログラムに関する。

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

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

また、ネットワークやサーバに仮想化技術を適用する手法がある。仮想化技術を適用する手法では、ネットワークやサーバなどの物理的なリソースを仮想化技術により複数の論理的なリソースに分割することで、複数のユーザが同一の物理的なリソースを共用する。

西村豪生、中田秀基、松岡聡著 「仮想計算機と仮想ネットワークを用いた仮想クラスタの構築」 情報処理学会研究報告、2006（87）、 73−78、 2006−07−31、社団法人情報処理学会、 小倉 章嗣、河野 健二、松岡 聡、中田 秀基著、「グリッド環境におけるＶＭ上でのジョブ実行の検討」、情報処理学会研究報告 計算機アーキテクチャ研究会報告 2004（20）、 25−30、 2004−03−01、社団法人情報処理学会 立薗 真樹、中田 秀基、松岡 聡、「仮想計算機を用いて負荷分散を行うＭＰＩ実行環境」、信学技報、電子情報通信学会技術研究報告. CPSY、 コンピュータシステム 105（225）、 7−12、 2005−07−28、社団法人電子情報通信学会

しかしながら、上述の手法では、提供元が異なるリソースを組み合わせて利用する場合に、ユーザに手間がかかるという課題がある。例えば、提供元が異なるリソースを組み合わせて利用する場合には、ユーザは、各提供元に対して、それぞれ申し込みを依頼することになる。

開示の技術は、上述に鑑みてなされたものであって、提供元が異なるリソースを簡単に組み合わせて利用可能となるリソース管理サーバ、リソース管理システム、リソース管理方法及びリソース管理プログラムを提供することを目的とする。

開示するリソース管理サーバは、１つの態様において、異なる種類のリソースを提供する各々の管理装置について、該リソースの空き状況を示す空き状況情報と該リソースの利用状況を示す利用状況情報とを収集する収集部を備える。また、ソース管理サーバは、前記収集部により異なる種類の前記リソース各々について収集された前記利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を判定する過不足判定部を備える。また、ソース管理サーバは、前記過不足判定部により前記リソースが不足していると判定された場合には、前記空き状況情報により示される異なる種類の空きリソースをくくりつけて、その中からリソースを追加するリソース割当を決定し、前記過不足判定部により前記リソースが余っていると判定された場合には、前記利用状況情報により示される利用中のリソースを開放する前記リソース割当を決定する決定部を備える。また、ソース管理サーバは、前記決定部により決定された前記リソースの割当を前記管理装置に出力する割当出力部を備える。

開示するリソース管理サーバの１つの態様によれば、提供元が異なるリソースを簡単に組み合わせて利用可能となるという有利な効果を奏する。

図１は、実施例１に係るインタークラウドサーバの構成の一例を示す図である。 図２は、実施例１における管理装置とリソースとユーザ端末との関係の一例を示す図である。 図３は、実施例１における制約条件テーブルに記憶された情報の一例を示す図である。 図４は、実施例１に係るインタークラウドサーバによる割当処理の流れの一例を示すフローチャートである。 図５は、実施例１に係るインタークラウドサーバによる判定処理の流れの一例を示すフローチャートである。 図６は、実施例２に係るインタークラウドサーバの全体像について示す図である。 図７は、実施例２におけるＡＳＰ運用者に新規にリソースを割り当てられる新設時における動作概要を示す図である。 図８は、実施例２におけるＡＳＰ運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要を示す図である。 図９は、実施例２におけるＡＳＰ運用者に割り当てられたリソースを開放する廃止時における動作概要を示す図である。 図１０は、実施例２に係るインタークラウドサーバのユースケースの一例を示す図である。 図１１は、実施例２における新設時における処理の流れの一例を示すシーケンス図である。 図１２は、実施例２における増設・減設時における処理の流れの一例を示すシーケンス図である。 図１３は、実施例２における廃止時における処理の流れの一例を示すシーケンス図である。 図１４は、実施例２におけるＤＣ−ＯＰＳについての管理情報の一例を示す図である。 図１５は、実施例２におけるＮＷ−ＯＰＳについての管理情報の一例を示す図である。 図１６は、実施例２における制約条件ＤＢに記憶された制約条件の一例を示す図である。 図１７は、実施例２におけるＤＣについての利用状況情報の一例を示す図である。 図１８は、実施例２におけるＤＣについての空きリソース情報の一例を示す図である。 図１９は、実施例２におけるＤＣリソース情報の一例を示す図である。 図２０は、実施例２におけるＤＣについてのリソース割当の一例を示す図である。 図２１は、実施例２におけるＮＷについての利用状況情報の一例を示す図である。 図２２は、実施例２におけるＮＷについての空きリソース情報の一例を示す図である。 図２３は、実施例２におけるＮＷリソース情報の一例を示す図である。 図２４は、実施例２におけるＮＷについてのリソース割当の一例を示す図である。 図２５は、インタークラウドサーバによる一連の処理を実行するプログラムであるリソース管理プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。

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

図１は、実施例１に係るインタークラウドサーバの構成の一例を示す図である。インタークラウドサーバ１００は、リソース管理サーバとも称する。図１に示す例では、インタークラウドサーバ１００に加えて、管理装置２００とユーザ端末３００とリソース４００とを併せて示した。なお、以下では、管理装置２００により管理されるリソース４００が、ユーザ端末３００に割り当てられる場合を用いて説明する。

リソース４００は、管理装置２００及びユーザ端末３００と接続される。リソース４００は、管理装置２００によりユーザに割り当てられる。リソース４００は、例えば、サーバのリソースや、ネットワークのリソースなどが該当する。

管理装置２００は、インタークラウドサーバ１００及びリソース４００と接続される。管理装置２００は、リソース４００を管理する。図１に示す例では、管理装置２００は、割当部２０１を有する。割当部２０１は、リソース４００をユーザ端末３００に割り当てたり、ユーザ端末３００に割り当てられたリソース４００を回収したりする。複数ある管理装置２００各々は、それぞれ独自のリソース４００を管理し、独自に管理するリソース４００をユーザに割り当てる。

なお、以下では、異なる種類のリソースを提供する各々のクラウドシステムが、それぞれ異なる管理装置２００を用いてリソース４００を管理する場合を用いて説明する。すなわち、管理装置２００各々が、それぞれ異なるクラウドシステムについてのリソース４００を管理する場合を用いて説明する。ただし、これに限定されるものではなく、管理装置２００は、異なるクラウドシステムにより提供されるリソース４００各々が、１つの管理装置２００により管理されても良い。例えば、管理装置「Ａ」が、クラウドシステム「Ａ」により提供されるリソース及びクラウドシステム「Ｂ」により提供されるリソースを管理しても良い。

なお、ここで、管理装置２００は、複数のサーバのリソース４００が集合したデータセンタ単位でリソース４００を管理しても良い。また、同様に、あるクラウドシステムが複数のネットワークのリソース４００を提供する場合に、ネットワークのリソース４００毎に管理装置２００を用いても良く、クラウドシステム毎に管理装置２００を設けても良い。

また、管理装置２００は、リソース４００の空き状況を示す空きリソース情報をインタークラウドサーバ１００に送信したり、リソース４００の利用状況を示す利用状況情報をインタークラウドサーバ１００に送信したりする。

ユーザ端末３００は、インタークラウドサーバ１００及びリソース４００と接続される。ユーザ端末３００は、管理装置２００により管理されるリソース４００を利用するユーザにより用いられる。ユーザ端末３００は、リソースの新規割当を要求する新規割当要求をインタークラウドサーバ１００に送信する。また、ユーザ端末３００は、リソースの割当の解消を要求する割当廃止要求をインタークラウドサーバ１００に送信する。また、ユーザ端末３００は、リソース割当に関する制約条件を割り当てられたリソース４００が満たしているかを判定する旨の判定指示をインタークラウドサーバ１００に送信する。

図２は、実施例１における管理装置とリソースとユーザ端末との関係の一例を示す図である。図２に示す例では、サーバのリソース４００となるサーバ４０１−１〜サーバ４０１−９と、ネットワークのリソース４００となるネットワーク４０２−１〜ネットワーク４０２−３とがある場合を示した。なお、図２に示す例では、記載の便宜上、ユーザ端末３００とインタークラウドサーバ１００とが接続してない場合を示したが、これに限定されるものではない。例えば、ユーザ端末３００とインタークラウドサーバ１００とが接続されても良い。

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

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

ここで、インタークラウドサーバ１００は、以下に詳細に説明するように、異なるクラウドシステムにより割り当てられるリソース４００各々について、リソースの空き状況を示す空きリソース情報とリソース４００の利用状況を示す利用状況情報とを収集する。そして、インタークラウドサーバ１００は、異なる種類のリソース各々について収集した利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を判定し、過不足を解消する割り当てを決定する。そして、インタークラウドサーバ１００は、決定したリソースの割当を管理装置２００に出力する。

すなわち、以下に詳細に説明するように、インタークラウドサーバ１００が、提供元が異なるリソース４００各々について、クラウドシステムをまたがってリソース４００の状況を収集し、収集した情報に基づいてリソースの割当を決定する。この結果、提供元が異なるリソース４００を簡単に組み合わせて利用することが可能となる。

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

図１の説明に戻り、インタークラウドサーバ１００の構成について説明する。図１に示す例では、インタークラウドサーバ１００は、通信部１０１と、記憶部１１０と、制御部１２０とを有する。通信部１０１は、管理装置２００やユーザ端末３００からの情報を受信し、受信した情報を制御部１２０に送信する。また、通信部１０１は、制御部１２０から受信した情報を管理装置２００やユーザ端末３００に送信する。なお、通信部１０１により送受信される情報の詳細については、後述するため、ここでは説明を省略する。

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

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

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

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

なお、制約条件テーブル１１１に記憶される情報は、ユーザ端末３００により送信された新規割当要求に含まれる。すなわち、ユーザ端末３００が、ユーザＩＤと制約条件とを含む新規割当要求をインタークラウドサーバ１００に送信すると、インタークラウドサーバ１００は、受信した新規割当要求に含まれるユーザＩＤと制約条件とを対応付けて制約条件テーブル１１１に格納する。

制御部１２０は、通信部１０１及び記憶部１１０と接続される。制御部１２０は、各種の処理手順などを規定したプログラムを記憶する内部メモリを有し、種々の処理を制御する。制御部１２０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）などが該当する。図１に示す例では、制御部１２０は、受信部１２１と、収集部１２２と、過不足判定部１２３と、決定部１２４と、割当出力部１２５と、制約条件判定部１２６と、判定結果出力部１２７とを有する。

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

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

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

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

図２に示す例では、収集部１２２は、管理装置２００−１〜管理装置２００−６各々にアクセスし、管理装置２００−１〜管理装置２００−６各々により管理されるリソース４００各々についての空きリソース情報や利用状況情報を収集する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、決定部１２４により開放されるリソース４００について更に説明する。決定部１２４は、例えば、制約条件を満たすリソースの割当を決定する。言い換えると、決定部１２４は、利用状況情報により示される利用中のリソース４００のうち、任意のリソース４００を開放する。

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

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

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

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

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

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

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

［インタークラウドサーバによる割当処理］
図４は、実施例１に係るインタークラウドサーバによる割当処理の流れの一例を示すフローチャートである。以下では、収集部１２２が、任意のタイミングにて、空きリソース情報と利用状況情報とを収集した場合における処理の流れの一例について説明する。

図４に示すように、収集部１２２は、任意のタイミングとなると（ステップＳ１０１肯定）、収集部１２２は、異なる事業者により割り当てられるリソース４００各々について、リソース４００の状況を示す情報を収集する（ステップＳ１０２）。例えば、収集部１２２は、リソース４００を管理する管理装置２００各々から、それぞれ、空きリソース情報や利用状況情報を収集する。

そして、過不足判定部１２３は、収集部１２２により収集された利用状況情報を解析することで、既に割り当てられているリソース４００の過不足を判定する（ステップＳ１０３）。例えば、過不足判定部１２３は、利用状況情報を解析することで、割り当てられたリソース４００において利用されていないリソース４００が占める割合を識別し、識別した割合が所定の割合以下になった場合に不足していると判定する。

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

そして、割当出力部１２５は、決定部１２４により決定されたリソース割当を出力する（ステップＳ１０５）。つまり、割当出力部１２５は、リソース４００を管理する管理装置２００にリソース割当を通知することで、決定部１２４により決定されたリソースの割当を管理装置２００に実行させる。

なお、新規割当要求を受信した場合や、割当廃止要求を受信した場合には、インタークラウドサーバ１００では、上述したステップＳ１０３を実行することなく、収集部１２２がリソース４００の状況を示す情報を収集し、決定部１２４がリソース４００の割当を決定し、割当出力部１２５がリソース割当を出力する。

［インタークラウドサーバによる判定処理］
図５は、実施例１に係るインタークラウドサーバによる判定処理の流れの一例を示すフローチャートである。以下では、制約条件判定部１２６が、受信部１２１によって判定指示が受信されると判定処理を実行する場合を用いて説明する。

図５に示すように、受信部１２１が判定指示を受信すると（ステップＳ２０１肯定）、収集部１２２は、利用状況情報を収集する（ステップＳ２０２）。そして、制約条件判定部１２６は、収集部１２２により収集された利用状況情報を解析することで、既に割り当てられているリソース４００が制約条件を満たしているか否かを判定する（ステップＳ２０３）。例えば、制約条件として、リソースの上限値「１００Ｎｂｐｓ」とリソースの下限値「１０Ｍｂｐｓ」とがある場合を用いて説明する。この場合、制約条件判定部１２６は、利用状況情報を解析することでリソース４００のリソース量を識別し、識別したリソース４００のリソース量が「１００Ｎｂｐｓ」から「１０Ｍｂｐｓ」との間にあるか否かを判定する。

そして、判定結果出力部１２７は、制約条件判定部１２６による判定結果を出力する（ステップＳ２０４）。例えば、判定結果出力部１２７は、制約条件判定部１２６により満たしていると判定されると、満たしている旨の判定結果をユーザ端末３００に出力し、制約条件判定部１２６により満たしていないと判定されると、満たしていない旨の判定結果をユーザ端末３００に出力する。

［実施例１の効果］
上述したように、実施例１によれば、インタークラウドサーバ１００は、リソース４００を提供する異なる管理装置各々について、空き状況情報と利用状況情報とを収集し、異なる種類のリソース各々について収集された利用状況情報をくくりつけて解析することで、既に割り当てられているリソース４００の過不足を判定する。そして、インタークラウドサーバ１００は、リソース４００が不足していると判定された場合には、空きリソース情報により示される異なる種類の空きリソース４００をくくりつけて、その中からリソースを追加するリソース割当を決定し、リソース４００が余っていると判定された場合には、利用状況情報により示される利用中のリソース４００を開放するリソースの割当を決定する。そして、インタークラウドサーバ１００は、決定したリソース割当を管理装置２００各々に出力する。この結果、異なる事業者により提供されるリソースを簡単に組み合わせて利用可能となる。また、この結果、異なる種類のリソースを提供するクラウド全体の品質を効率よく維持することが可能である。

また、実施例１によれば、インタークラウドサーバ１００は、新規割当要求及び割当廃止要求を受信する。また、インタークラウドサーバ１００は、新規割当要求が受信された場合には、新規割当要求により示されるリソース４００を割り当てるリソース割当を決定する。また、インタークラウドサーバ１００は、割当廃止要求が受信された場合には、割当廃止要求により示されるリソース割当を解消するリソース割当を決定する。この結果、ユーザは、異なる事業者により提供されるリソース４００の割当を簡単に新設したり廃止したりすることが可能となる。

また、実施例１によれば、インタークラウドサーバ１００は、制約条件を含む新規割当要求を受信し、制約条件を満たすリソース割当を決定する。この結果、ユーザは、制約条件をインタークラウドサーバ１００に入力することで、異なる事業者により提供されるリソース４００各々から、それぞれ制約条件を満たすリソース４００を簡単に利用することが可能である。

また、実施例１によれば、インタークラウドサーバ１００は、収集された利用状況情報を解析することで、既に割り当てられているリソース４００が制約条件を満たしているか否かを判定し、リソースの過不足を判定するための情報として判定結果を過不足判定部１２３に出力する。この結果、ユーザに割り当てられているリソースが制約条件を満たさなくなった場合に、適宜過不足が判定され、リソース割当が決定されることになり、ユーザに制約条件を満たすリソースを適切に割り当てることが可能である。また、判定結果をユーザに出力することで、異なる事業者により提供されたリソース４００各々について、制約条件をみたしているかをユーザが簡単に確認可能である。

また、実施例１によれば、インタークラウドサーバ１００は、ユーザ毎の利用状況情報を収集し、ユーザ毎のリソース４００の過不足を判定し、ユーザ毎のリソース割当を決定し、ユーザ毎のリソース割当を出力する。この結果、複数いるユーザ毎に、異なる事業者により提供されるリソース４００各々を簡単に割当可能である。

実施例２では、インタークラウドサーバの詳細について更に説明する。実施例２では、インタークラウドサーバ５００にインストールされたプログラムが一連の処理を実行することで、異なるクラウドシステムにより提供されるリソースを割り当てる場合を用いて説明する。より詳細には、インタークラウドサーバ５００が、ネットワークのリソースと、データセンタのリソースとを割り当てる場合を用いて説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は１部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、図１に示す例では、記憶部１１０をインタークラウドサーバ１００の外部装置としてネットワーク経由で接続するようにしても良い。また、例えば、図１に示す例において、制御部１２０が、制約条件判定部１２６と判定結果出力部１２７とを有しなくても良い。

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

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

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

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

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

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

１００ インタークラウドサーバ
１０１ 通信部
１１０ 記憶部
１１１ 制約条件テーブル
１２０ 制御部
１２１ 受信部
１２２ 収集部
１２３ 過不足判定部
１２４ 決定部
１２５ 割当出力部
１２６ 制約条件判定部
１２７ 判定結果出力部
２００ 管理装置
２０１ 割当部
３００ ユーザ端末
４００ リソース
５００ インタークラウドサーバ
５０１ ＩＣＳソフトウェア
５２０ 制御部
６０１ オペレータ端末
６０２ ＡＳＰ端末
６０７ ユーザ端末
６０４ ＮＷ−ＯＰＳ
６０３ ＤＣ−ＯＰＳ
５１１ 制約条件ＤＢ
５１２ 管理情報ＤＢ

Claims (7)

1. 異なる種類のリソースを提供する各々の管理装置について、該リソースの空き状況を示す空き状況情報と該リソースのユーザごとの利用状況を示す利用状況情報とを前記管理装置各々から収集する収集部と、
   前記収集部により異なる種類の前記リソース各々について収集された前記利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を前記ユーザごとに判定する過不足判定部と、
   前記過不足判定部により前記リソースが不足していると判定された場合には、前記空き状況情報により示される異なる種類の空きリソース各々をくくりつけて、その中から追加されるリソースを表すリソース割当を決定し、前記過不足判定部により前記リソースが余っていると判定された場合には、前記利用状況情報により示される利用中のリソース各々のうち、開放されるリソースを表す前記リソース割当を前記ユーザごとに決定する決定部と、
   前記決定部により決定された前記ユーザごとの前記リソース割当を、前記追加又は開放されるリソースを提供する前記管理装置各々に出力する割当出力部と
   を備えたことを特徴とするリソース管理サーバ。
2. 前記リソースの新規割当を要求する新規割当要求及び前記リソースの割当の解消を要求する割当廃止要求を受信する受信部を更に備え、
   前記決定部は、前記受信部により前記新規割当要求が受信された場合には、該新規割当要求により示されるリソースを割り当てる前記リソース割当を決定し、前記受信部により前記割当廃止要求が受信された場合には、該割当廃止要求により示されるリソースの割当を解消する前記リソース割当を決定することを特徴とする請求項１に記載のリソース管理サーバ。
3. 前記受信部は、前記リソース割当に関する制約条件を含む前記新規割当要求を受信し、 前記決定部は、前記制約条件を満たす前記リソースの割当を決定することを特徴とする請求項２に記載のリソース管理サーバ。
4. 前記収集部により収集された前記利用状況情報を解析することで、既に割り当てられているリソースが前記制約条件を満たしているか否かを判定する制約条件判定部と、
   前記制約条件判定部による判定結果を前記過不足判定部へリソースの過不足を判定するための情報として出力する判定結果出力部、
   更に備えたことを特徴とする請求項３に記載のリソース管理サーバ。
5. 異なる種類のリソースを提供する各々の管理装置について、該リソースの空き状況を示す空き状況情報と該リソースのユーザごとの利用状況を示す利用状況情報とを前記管理装置各々から収集する収集部と、
   前記収集部により異なる種類の前記リソース各々について収集された前記利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を前記ユーザごとに判定する過不足判定部と、
   前記過不足判定部により前記リソースが不足していると判定された場合には、前記空き状況情報により示される異なる種類の空きリソース各々をくくりつけて、その中から追加されるリソースを表すリソース割当を決定し、前記過不足判定部により前記リソースが余っていると判定された場合には、前記利用状況情報により示される利用中のリソース各々のうち、開放されるリソースを表す前記リソース割当を前記ユーザごとに決定する決定部と、
   前記決定部により決定された前記ユーザごとの前記リソース割当を、前記追加又は開放されるリソースを提供する前記管理装置各々に出力する割当出力部と
   を備えたリソース管理サーバと、
   前記リソース管理サーバにより出力された前記リソース割当を実行する割当部を備えたことを特徴とする前記管理装置と
   を備えたことを特徴とするリソース管理システム。
6. 異なる種類のリソースを提供する各々の管理装置について、該リソースの空き状況を示す空き状況情報と該リソースのユーザごとの利用状況を示す利用状況情報とを前記管理装置各々から収集する収集工程と、
   前記収集工程により異なる種類の前記リソース各々について収集された前記利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を前記ユーザごとに判定する過不足判定工程と、
   前記過不足判定工程により前記リソースが不足していると判定された場合には、前記空き状況情報により示される異なる種類の空きリソース各々をくくりつけて、その中から追加されるリソースを表すリソース割当を決定し、前記過不足判定工程により前記リソースが余っていると判定された場合には、前記利用状況情報により示される利用中のリソース各々のうち、開放されるリソースを表す前記リソース割当を前記ユーザごとに決定する決定工程と、
   前記決定工程により決定された前記ユーザごとの前記リソース割当を、前記追加又は開放されるリソースを提供する前記管理装置各々に出力する割当出力工程と
   を含んだことを特徴とするリソース管理方法。
7. コンピュータを請求項１〜４のいずれか１つに記載のリソース管理サーバとして機能させるためのリソース管理プログラム。
   
   

Images