(57)【要約】【課題】ユーザの負担を軽減しつつ、適切にＶＭを調達する。【解決手段】リソース管理装置１０は、スキーマ変換ルール群１１１に従って、クラウド管理用ＤＢ群１１０に記憶されたデータを、検索クエリにより検索可能な構造のデータに変換する。また、リソース管理装置１０は、ユーザ端末２０によりユーザが要求する計算機リソース上で稼働するＶＭの特徴を示すＶＭ調達ポリシーの指定を受け付けると、該ポリシーに対応するクエリをＶＭ調達ポリシーＤＢ１１３から取得し、該クエリを用いて、スキーマ変換部１０９により変換された情報に対して検索を行い、ポリシーに合致するクラウドサービスを選択する。そして、リソース管理装置１０は、選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する。【選択図】        図１
2015184991.tif 000002
【特許請求の範囲】
【請求項１】
計算機リソースを提供する各クラウドサービスに関する情報を記憶する記憶部と、
前記クラウドサービスに関する情報を基に作成された検索クエリを、前記計算機リソースの特徴を示すポリシーに対応付けて記憶するポリシー記憶部と、
所定の変換ルールに従って、前記記憶部に記憶された情報を、前記検索クエリにより検索可能な構造の情報に変換する変換部と、
ユーザ端末によりポリシーの指定を受け付けると、該ポリシーに対応する検索クエリを前記ポリシー記憶部から取得し、該検索クエリを用いて、前記変換部により変換された情報に対して検索を行い、前記ポリシーに合致するクラウドサービスを選択する選択部と、
前記選択部によって選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する管理部と、
を備えたことを特徴とするリソース管理装置。
【請求項２】
前記変換部は、前記記憶部に記憶された情報に用いられる識別子の形式の統一、表記ゆれの補正、値の型の変換、値の補完、テーブル形式の変換のうち、いずれか一つまたは複数を実行することを特徴とする請求項１に記載のリソース管理装置。
【請求項３】
前記変換部は、前記記憶部に記憶されたクラウドサービスに関する情報同士の関係を表現するグラフデータに変換し、
前記選択部は、前記検索クエリを用いて、前記グラフデータに対して検索を行い、前記ポリシーに合致するクラウドサービスを選択することを特徴とする請求項１または２に記載のリソース管理装置。
【請求項４】
前記計算機リソースの性能に関する情報を各クラウドサービスから取得する監視部と、
前記監視部によって取得された情報を用いて、各クラウドサービスの性能状況を分析し、分析結果を前記記憶部に格納する分析部をさらに備えることを特徴とする請求項１〜３のいずれか一つに記載のリソース管理装置。
【請求項５】
前記記憶部は、前記計算機リソースを提供する各クラウドサービスに関する情報として、前記計算機の性能に関する情報、前記計算機のロケーションに関する情報、前記計算機の価格に関する情報のうち、いずれか一つまたは複数を記憶することを特徴とする請求項１〜４のいずれか一つに記載のリソース管理装置。
【請求項６】
リソース管理装置で実行されるリソース管理方法であって、
前記リソース管理装置が、
計算機リソースを提供する各クラウドサービスに関する情報を記憶する記憶部と、
前記クラウドサービスに関する情報を基に作成された検索クエリを、前記計算機リソースの特徴を示すポリシーに対応付けて記憶するポリシー記憶部と、
を備え、
所定の変換ルールに従って、前記記憶部に記憶された情報を、前記検索クエリにより検索可能な構造の情報に変換する変換工程と、
ユーザ端末によりポリシーの指定を受け付けると、該ポリシーに対応する検索クエリを前記ポリシー記憶部から取得し、該検索クエリを用いて、前記変換工程により変換された情報に対して検索を行い、前記ポリシーに合致するクラウドサービスを選択する選択工程と、
前記選択工程によって選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する管理工程と、
を含んだことを特徴とするリソース管理方法。
【請求項７】
コンピュータを請求項１〜５に記載のリソース管理装置として機能させるためのリソース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース管理装置、リソース管理方法およびリソース管理プログラムに関する。
【背景技術】
【０００２】
近年、計算機の仮想化技術が発達し、１台の物理マシン上に複数のシステムを集約して運用することで、計算機リソースを即座に調達可能にしたクラウドサービスが普及している。このようなクラウドサービスにおける特徴の一つは、資源の集約化によるコストメリットであり、集約化した多量の計算機リソースを多くのユーザに提供することで、計算機リソースを安価に提供することが可能となる。しかし、価格を抑えるために規格化されており、細かなユーザニーズに対応できない。そこで、ユーザニーズに対応するために、複数のクラウドサービスの計算機リソースを組み合わせて提供するハイブリッドクラウドサービスが考えられ、注目されている。
【０００３】
例えば、複数クラウドを統合管理可能なクラウドコントローラ（例えば、PrimeCloud  Controller）は、複数のクラウドサービスが提供するリソースを一元管理することで、ハイブリッドクラウドを構築、運用するための基盤アプリケーションである（例えば、非特許文献１参照）。このようなクラウドコントローラでは、例えば、ユーザ自身がＶＭ調達先を選定し、各クラウドサービスが提供するサービスの違いを意識してＶＭを調達することが行われている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】制御基板「ＰｒｉｍｅＣｌｏｕｄ  Ｃｏｎｔｒｏｌｌｅｒ」、［online］、［平成２６年３月１２日検索］、インターネット＜http://www.primecloud.jp/service/platform/pcc/＞
【非特許文献２】グローバルクラウド基盤連携技術フォーラム、［online］、［平成２６年３月１２日検索］、インターネット＜http://www.gictf.jp/documents.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記した従来の技術では、ＶＭ調達先をユーザが選定するので、ユーザの負担が大きく、また、適切にＶＭを調達することができない場合があるという課題があった。つまり、最適なＶＭ調達先を選定するのはユーザ自身であるため、各クラウドサービスが提供するサービスの違いを意識してＶＭを調達せねばならず、ユーザの負担が大きいという問題があった。
【０００６】
なお、複数のクラウドサービスを柔軟に組合せて、計算機リソースを提供する、クラウドサービス事業者間の連携を行い、ＶＭの調達先を選定する技術として、インタークラウドが知られている（例えば、非特許文献２参照）。インタークラウドでは、ＶＭ調達に際して、プロトコル内でリソースフィッティング処理が規定されており、ユーザの要求に対して他のクラウドサービスからＶＭを自動的に取得することができる。しかし、クラウドサービスの事業者間での連携であるため、ユーザからは実際に調達したＶＭの詳細が見えないため、サービスレベルやロケーションなどの詳細情報をユーザに開示しないため、ユーザ自身がニーズに合致したＶＭを適切に調達することができない場合がある。
【０００７】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、ユーザの負担を軽減しつつ、適切にＶＭを調達することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するため、本発明のリソース管理装置は、計算機リソースを提供する各クラウドサービスに関する情報を記憶する記憶部と、前記クラウドサービスに関する情報を基に作成された検索クエリを、前記計算機リソースの特徴を示すポリシーに対応付けて記憶するポリシー記憶部と、所定の変換ルールに従って、前記記憶部に記憶された情報を、前記検索クエリにより検索可能な構造の情報に変換する変換部と、ユーザ端末によりポリシーの指定を受け付けると、該ポリシーに対応する検索クエリを前記ポリシー記憶部から取得し、該検索クエリを用いて、前記変換部により変換された情報に対して検索を行い、前記ポリシーに合致するクラウドサービスを選択する選択部と、前記選択部によって選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する管理部と、を備えたことを特徴とする。
【０００９】
また、本発明のリソース管理方法は、リソース管理装置で実行されるリソース管理方法であって、前記リソース管理装置が、計算機リソースを提供する各クラウドサービスに関する情報を記憶する記憶部と、前記クラウドサービスに関する情報を基に作成された検索クエリを、前記計算機リソースの特徴を示すポリシーに対応付けて記憶するポリシー記憶部と、を備え、所定の変換ルールに従って、前記記憶部に記憶された情報を、前記検索クエリにより検索可能な構造の情報に変換する変換工程と、ユーザ端末によりポリシーの指定を受け付けると、該ポリシーに対応する検索クエリを前記ポリシー記憶部から取得し、該検索クエリを用いて、前記変換工程により変換された情報に対して検索を行い、前記ポリシーに合致するクラウドサービスを選択する選択工程と、前記選択工程によって選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する管理工程と、を含んだことを特徴とする。
【発明の効果】
【００１０】
本願に開示するリソース管理装置、リソース管理方法およびリソース管理プログラムは、ユーザの負担を軽減しつつ、適切にＶＭを調達することができるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】図１は、第一の実施の形態に係るリソース管理システムの全体構成を示す概略構成図である。
【図２】図２は、クラウド管理用ＤＢ群のクラウドリストＤＢに記憶されるテーブルの構成例を示す図である。
【図３】図３は、クラウド管理用ＤＢ群のラインナップＤＢに記憶されるテーブルの構成例を示す図である。
【図４】図４は、クラウド管理用ＤＢ群のラインナップ価格ＤＢに記憶されるテーブルの構成例を示す図である。
【図５】図５は、クラウド管理用ＤＢ群のラインナップスペック情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図６】図６は、クラウド管理用ＤＢ群のラインナップスペック情報ＤＢに記憶されるテーブルの一例を示す図である。
【図７】図７は、クラウド管理用ＤＢ群のラインナップ性能情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図８】図８は、クラウド管理用ＤＢ群のテナント情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図９】図９は、クラウド管理用ＤＢ群のクラウドサービス登録情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図１０】図１０は、クラウド管理用ＤＢ群のＮＷ管理ＤＢに記憶されるテーブルの構成例を示す図である。
【図１１】図１１は、クラウド管理用ＤＢ群のクラウド間ＮＷ管理ＤＢに記憶されるテーブルの構成例を示す図である。
【図１２】図１２は、クラウド管理用ＤＢ群のＶＭ情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図１３】図１３は、クラウド管理用ＤＢ群のＶＭ稼働情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図１４】図１４は、クラウド管理用ＤＢ群のＶＭテンプレートＤＢに記憶されるテーブルの構成例を示す図である。
【図１５】図１５は、クラウド管理用ＤＢ群の監視設定ＤＢに記憶されるテーブルの構成例を示す図である。
【図１６】図１６は、クラウド管理用ＤＢ群のリソース性能情報ＤＢに記憶されるテーブルの構成例を示す図である。
【図１７】図１７は、ＩＤ名寄せルールの一例を示す図である。
【図１８】図１８は、名寄せ変換テーブル生成ルールの一例を示す図である。
【図１９】図１９は、名寄せ変換テーブルの一例を示す図である。
【図２０】図２０は、名寄せ変換テーブルの一例を示す図である。
【図２１】図２１は、ＲＦＤデータの一例を示す図である。
【図２２】図２２は、ラインナップ価格ＤＢにおけるテーブルの変換例を示す図である。
【図２３】図２３は、ＶＭ稼働情報ＤＢにおけるテーブルの変換例を示す図である。
【図２４】図２４は、ラインナップスペック情報ＤＢにおけるテーブルの変換例を示す図である。
【図２５】図２５は、テーブル変換後のスキーマ構造を示す図である。
【図２６】図２６は、外部データ追加の例を示す図である。
【図２７】図２７は、ＶＭ調達ポリシーＤＢに記憶されるテーブルの構成例を示す図である。
【図２８】図２８は、ＶＭポリシーＤＢに記憶されるテーブルの一例を示す図である。
【図２９】図２９は、第一の実施の形態に係るリソース管理装置におけるスキーマ変換処理の流れを説明するフローチャートである。
【図３０】図３０は、第一の実施の形態に係るリソース管理装置におけるＶＭ作成処理の流れを説明するシーケンス図である。
【図３１】図３１は、第一の実施の形態に係るリソース管理装置におけるＶＭ起動処理の流れを説明するシーケンス図である。
【図３２】図３２は、第一の実施の形態に係るリソース管理装置におけるＶＭ停止処理の流れを説明するシーケンス図である。
【図３３】図３３は、第一の実施の形態に係るリソース管理装置におけるＶＭ削除処理の流れを説明するシーケンス図である。
【図３４】図３４は、リソース管理プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１２】
以下に、本願に係るリソース管理装置、リソース管理方法およびリソース管理プログラムの実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願に係るリソース管理装置、リソース管理方法およびリソース管理プログラムが限定されるものではない。
【００１３】
［第一の実施の形態］
以下の実施の形態では、第一の実施の形態に係るリソース管理システム１の構成、リソース管理装置１０の構成、リソース管理装置１０における処理の流れを順に説明し、最後に第一の実施の形態による効果を説明する。
【００１４】
［第一の実施の形態に係るリソース管理システムの構成］
まず、図１を用いて、第一の実施の形態に係るリソース管理システム１について説明する。図１は、第一の実施の形態に係るリソース管理システムの全体構成を示す概略構成図である。
【００１５】
図１に示すように、リソース管理システム１は、リソース管理装置１０、ユーザ端末２０および管理者端末３０を有する。また、リソース管理システム１は、ハイブリッドクラウドにおいてリソースを管理するシステムであり、クラウドサービスＡおよびクラウドサービスＢが含まれる。なお、以下の説明では、二つのクラウドサービスＡ、クラウドサービスＢを例にして説明するが、これに限定されるものではなく、三つ以上のクラウドサービスがあってもよい。また、リソース管理システム１における各構成品は、ＩＰ接続可能な場所であれば、いずれの場所に配置してもよい。例えば、リソース管理システム１における各構成品は、プライベートクラウドの何れかのＶＭ（Virtual  Machine）上のシステムとして配置される。
【００１６】
リソース管理装置１０は、ユーザ端末２０、管理者端末３０、クラウドサービスＡ、Ｂのリソース管理ＡＰＩ（Application  Programming  Interface）４１Ａ、４１Ｂおよびネットワーク管理ＡＰＩ４２Ａ、４２Ｂと接続されている。なお、図では省略しているが、リソース管理装置１０のリソース管理ＡＰＩ１０５と、クラウドサービスＡ、Ｂの各ＡＰＩとは、インターネット経由で接続されており、性能監視部とクラウドサービスＡ、Ｂの各ＡＰＩとは、ＶＰＮ（Virtual  Private  Network）経由で接続されているものとする。また、クラウドサービスＡとクラウドサービスＢとの間は、ＩＰで接続されていてもよいし、仮想ルータを用いてＶＰＮ接続を確立していてもよい。
【００１７】
また、クラウドサービスＡ、Ｂは、物理機器にアクセス可能なプライベートクラウドであってもよいし、物理機器にはアクセスできないパブリッククラウドであってもよいし、いずれかのクラウドを複数管理するものであってもよい。例えば、クラウドサービスＡ、Ｂは、１つのプライベートクラウドと、１つのパブリッククラウドを管理している。ここで、プライベートクラウドとは、企業などが自分たちのリソースのみを管理するために構築したクラウドである。また、パブリッククラウドとは、パブリッククラウドサービス事業者により提供されるクラウドである。
【００１８】
リソース管理装置１０は、ユーザ端末２０のユーザ用ＵＩ（User  Interface）２１からユーザが要求するＶＭの特徴を示すＶＭ調達ポリシーを受け付けると、ＶＭ調達ポリシーに合致するクラウドサービスを選択し、選択したクラウドサービスからＶＭを調達する。
【００１９】
また、クラウドサービスＡ、Ｂは、複数の物理マシン上にハイパーバイザをインストールしてクラウドを構築している。また、クラウドサービスＡ、Ｂは、クラウドサービス管理機能により仮想リソースの管理がされており、外部サービスとの連携のためのＡＰＩが公開されている。
【００２０】
［リソース管理装置の構成］
図１に示すように、リソース管理装置１０は、ユーザＡＰＩ１０１、リソース管理部１０２、ネットワーク管理部１０３、ネットワーク管理ＡＰＩ１０４、リソース管理ＡＰＩ１０５、性能分析部１０６、性能監視部１０７、クラウド選択部１０８、スキーマ変換部１０９、クラウド管理用ＤＢ群１１０、スキーマ変換ルール群１１１、スキーマ変換後ＤＢ１１２、ＶＭ調達ポリシーＤＢ１１３、名寄せ変換テーブル群１１４および管理用ＩＦ１１５を有する。
【００２１】
ユーザＡＰＩ１０１は、ユーザからのリソース調達依頼を受け付け、リソース管理部１０２への処理を仲介するＡＰＩである。例えば、ユーザＡＰＩ１０１は、ユーザ端末２０のユーザ用ＵＩ（User  Interface）２１からユーザが要求するＶＭの特徴を示すＶＭ調達ポリシーを受け付ける。
【００２２】
リソース管理部１０２は、クラウド選択部１０８によって選択されたクラウドサービスの計算機リソースで稼働するＶＭを制御する。具体的には、リソース管理部１０２は、ユーザＡＰＩ１０５を経由して入力されたユーザからの要求に応じて、ＶＭの作成、ＶＭの起動、ＶＭの停止、ＶＭの削除、リソース情報の取得を行う。例えば、リソース管理部１０２は、クラウド選択部１０８によって選択されたクラウドサービスの計算機リソース上で稼働するＶＭの作成、ＶＭの起動、ＶＭの停止、または、ＶＭの削除を実行する。
【００２３】
ネットワーク管理部１０３は、異なる拠点のクラウドサービス間にあるリソース間の接続制御を行う。例えば、ネットワーク管理部１０３は、リソース間の接続制御として、ＶＰＮの接続、ＶＰＮの切断を行う。
【００２４】
ネットワーク管理ＡＰＩ１０４は、ネットワーク管理部１０３の命令を受けて、個々のクラウドサービスＡ、Ｂ上にあるネットワーク管理ＡＰＩ４２Ａ、４２Ｂに対して、ネットワーク制御を行う。例えば、ネットワーク管理ＡＰＩ１０４は、ネットワーク制御として、ＶＰＮの接続、ＶＰＮの切断を行う。
【００２５】
リソース管理ＡＰＩ１０５は、リソース管理部１０２の命令を受けて、個々のクラウドサービスＡ、Ｂ上にあるリソース管理ＡＰＩ４１Ａ、４１Ｂに対してリソースの管理として、ＶＭの作成、ＶＭの起動、ＶＭの停止、ＶＭの削除、リソース情報の取得を行う。
【００２６】
性能分析部１０６は、性能監視部１０７が取得したリソース性能情報を用いて、各クラウドサービスＡ、Ｂの性能状況を分析し、分析結果を、クラウド性能情報を記憶するＤＢ（図示せず）に格納する。
【００２７】
性能監視部１０７は、リソース管理部１０２からの命令を受け付けて、ハイブリッドクラウドを構成するＶＭの性能情報を取得する機能モジュールである。具体的には、性能監視部１０７は、各リソースや機器にインストールされた監視エージェントや、監視エージェントからリモートアクセスを通じて、計算機リソースの性能に関する情報を各クラウドサービスから取得する性能情報を取得する。
【００２８】
リモートアクセスでは，ＩＣＭＰ（Internet  Control  Message  Protocol）やＳＳＨ（Secure  Shell）やＳＮＭＰ（Simple  Network  Management  Protocol）などの既存のプロトコルを用いて監視対象にアクセスし、コマンド発行して性能情報を取得する。既存のプロトコルとコマンドを用いるため、多くのリソースや機器の情報を取得が可能となる。但し、取得できる性能情報には制限がある。
【００２９】
クラウド選択部１０８は、リソース管理部１０２の命令を受けてＶＭ調達ポリシーに対する最適なクラウドを選択する機能モジュールである。具体的には、クラウド選択部１０８は、ユーザ端末２０によりユーザが要求する計算機リソース上で稼働するＶＭの特徴を示すＶＭ調達ポリシーの指定を受け付けると、該ポリシーに対応するクエリ（検索クエリ）をＶＭ調達ポリシーＤＢ１１３から取得し、該クエリを用いて、スキーマ変換部１０９により変換された情報に対して検索を行い、ポリシーに合致するクラウドサービスを選択する。例えば、クラウド選択部１０８は、検索クエリを用いて、スキーマ変換部１０９により変換されたＲＤＦ（Resource  Description  Framework）データ等のグラフデータに対して検索を行って、ＶＭ調達ポリシーに合致するクラウドサービスを選択する。
【００３０】
例えば、クラウド選択部１０８は、リソース管理部１０２から渡された動作種別（ＶＭの作成、起動、停止、削除）とＶＭ調達ポリシーを基に、「ＶＭ調達ポリシー定義」から「ＶＭ調達クエリ」を検索する。そして、クラウド選択部１０８は、「スキーマ変換後データ」に対して「ＶＭ調達クエリ」を用いて検索を行い、最適なクラウドサービスの情報を得て、リソース管理部１０２に結果を返す。
【００３１】
スキーマ変換部１０９は、スキーマ変換ルール群１１１に従って、クラウド管理用ＤＢ群１１０に記憶されたデータを、検索クエリにより検索可能な構造のデータに変換する。例えば、スキーマ変換部１０９は、クラウド管理用ＤＢ群１１０に記憶された情報に用いられるＩＤの形式の統一、表記ゆれの補正、値の型の変換、値の補完、テーブル形式の変換のうち、いずれか一つまたは複数を実行する。また、スキーマ変換部１０９は、例えば、スキーマ変換ルール群１１１に記憶されたクラウドサービスに関する情報同士の関係を表現するグラフデータに変換する。また、スキーマ変換部１０９は、管理用ＩＦ（Interface）１１５からの開始命令を受けてデータ変換を行い、変換後のデータをスキーマ変換後ＤＢ１１２に格納する。
【００３２】
クラウド管理用ＤＢ群１１０は、ハイブリッドクラウドを運用するために必要なＤＢ群であり、計算機リソースを提供する各クラウドサービスに関する情報を記憶する。例えば、クラウド管理用ＤＢ群１１０は、計算機リソースを提供する各クラウドサービスに関する情報として、計算機の性能に関する情報、計算機のロケーションに関する情報、計算機の価格に関する情報のうち、いずれか一つまたは複数を記憶する。また、クラウド管理用ＤＢ群１１０には、各クラウドサービスのサービス情報を格納したＤＢ、クラウド間を接続するためのネットワーク情報を格納したＤＢ、ハイブリッドクラウドのユーザテナントに関する情報を格納したＤＢ、払い出されたＶＭなどリソースに関する情報を格納したＤＢ、ＶＭなどリソースの性能監視情報を格納したＤＢなど、多数のＤＢが存在する。
【００３３】
スキーマ変換ルール群１１１は、クラウド管理用ＤＢ群１１０のデータを、クラウド選択部１０８で検索できるように、統一されたスキーマ構造のデータへ変換するための変換ルールを格納するＤＢである。
【００３４】
スキーマ変換後ＤＢ１１２は、スキーマ変換部１０９がクラウド管理用ＤＢ群１１０のデータを、スキーマ変換ルールに従って変換した結果のデータを格納したＤＢである。スキーマ変換後ＤＢ１１２に記憶された情報は、クラウド選択部１０８がクラウド選択時に検索に使用する情報である。
【００３５】
ＶＭ調達ポリシーＤＢ１１３は、クラウド選択部１０８がＶＭ調達ポリシーに従ってスキーマ変換後ＤＢ１１２を検索する際に使用するクエリ（検索クエリ）を格納したＤＢである。例えば、ＶＭ調達ポリシーＤＢ１１３は、クラウドサービスに関する情報を基に作成されたクエリを、計算機リソースの特徴を示すＶＭ調達ポリシーに対応付けて記憶する。
【００３６】
［クラウド管理用ＤＢ群の例］
クラウド管理用ＤＢ群１１０は、ハイブリッドクラウドシステムを実現するために必要となるデータベース群である。以下では、クラウド管理用ＤＢ群１１０に記憶される情報の例について説明する。
【００３７】
クラウド管理用ＤＢ群１１０には、クラウドリストＤＢ、ラインナップＤＢ、ラインナップ価格ＤＢ、ラインナップスペック情報ＤＢ、ラインナップ性能情報ＤＢ、テナント情報ＤＢ、クラウドサービス登録情報ＤＢ、ＮＷ管理ＤＢ、クラウド間ＮＷ管理ＤＢ、ＶＭ情報ＤＢ、ＶＭ稼働情報ＤＢ、ＶＭテンプレートＤＢ、監視設定ＤＢ、リソース性能情報ＤＢが含まれる。以下では、図２〜図１６を用いて、各ＤＢについて説明する。各ＤＢは、複数のテーブルカラムを含むテーブルを記憶しており、各テーブルカラムには所定形式（例えば、String）でデータが記憶されている。また、各テーブルカラムについて、プライマリキーであるか否かが設定されている。
【００３８】
まず、図２を用いて、クラウドリストＤＢについて説明する。図２は、クラウド管理用ＤＢ群１１０のクラウドリストＤＢに記憶されるテーブルの構成例を示す図である。クラウドリストＤＢは、ハイブリッドクラウド環境に組み込むことができるクラウドサービスの情報を管理するＤＢである。このＤＢは、ハイブリッドクラウド管理者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。
【００３９】
図２に例示するように、クラウドリストＤＢでは、テーブルカラムとして、ＶＭを提供するクラウドサービスを識別する「クラウドサービスＩＤ」と、ＶＭを提供する計算機環境のある場所を示す「ロケーション」と、クラウドサービス上のＶＭを使用するために必要な初期費用を示す「初期費用」とを有する。
【００４０】
次に、図３を用いて、ラインナップＤＢについて説明する。図３は、クラウド管理用ＤＢ群１１０のラインナップＤＢに記憶されるテーブルの構成例を示す図である。ラインナップＤＢでは、各クラウドサービスによって提供されているラインナップのうち、ハイブリッドクラウド環境に組み込むことができるものを掲載したＤＢである。この情報は、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。提供するラインナップの選択は、ハイブリッドクラウド事業者が行うものとする。
【００４１】
図３に例示するように、ラインナップＤＢは、テーブルカラムとして、クラウドサービスで提供するラインナップを識別するＩＤである「ラインナップＩＤ」と、「クラウドサービスＩＤ」とを対応付けて記憶する。
【００４２】
次に、図４を用いて、ラインナップ価格ＤＢについて説明する。図４は、クラウド管理用ＤＢ群１１０のラインナップ価格ＤＢに記憶されるテーブルの構成例を示す図である。ラインナップ価格ＤＢは、ラインナップの価格に関する情報を格納するＤＢである。この情報は、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。なお、価格設定は、ハイブリッドクラウド事業者が行うことを想定している。
【００４３】
図４に例示するように、ランナップ価格ＤＢは、テーブルカラムとして、「ラインナップＩＤ」と、クラウドサービス上のＶＭを使用する課金形態である「課金形態」、固定課金の場合の期間（月）である「固定課金期間」、ＶＭ価格である「ＶＭ価格」とを対応付けて記憶する。なお、ＶＭ価格は、例えば、１時間あたりのＶＭ価格であってもよいし、固定課金の場合は、固定のＶＭ価格であってもよい。
【００４４】
次に、図５および図６を用いて、ラインナップスペック情報ＤＢについて説明する。図５は、クラウド管理用ＤＢ群１１０のラインナップスペック情報ＤＢに記憶されるテーブルの構成例を示す図である。図６は、クラウド管理用ＤＢ群１１０のラインナップスペック情報ＤＢに記憶されるテーブルの一例を示す図である。ラインナップスペック情報ＤＢは、各ラインナップで提供するＶＭのスペックに関する情報のうち、追加の情報を格納するＤＢである。例えば、クラウド事業者によって各項目の有無や、値の表記方法や単位などが著しく異なり、統一的に管理できない情報を格納する。この情報は、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。
【００４５】
図５に例示するように、ラインナップスペック情報ＤＢは、「ラインナップＩＤ」と、追加情報のカラム名を示す「カラム名」と、カラム名に関する値である「値」とを対応付けて記憶する。
【００４６】
図６に例示するように、例えば、ラインナップスペック情報ＤＢには、ＶＭラインナップＩＤ「クラウドＡ−プランＶ１」と、カラム名「プロセッサアーキテクチャ」と、値「６４ビット」とが対応付けて記憶されている。
【００４７】
次に、図７を用いて、ラインナップ性能情報ＤＢについて説明する。図７は、クラウド管理用ＤＢ群１１０のラインナップ性能情報ＤＢに記憶されるテーブルの構成例を示す図である。ラインナップ性能情報ＤＢは、ハイブリッドクラウド環境に組み込むことができるラインナップの性能に関するＤＢである。ベンチマークを実施している外部の情報提供者や、性能分析部１０６、性能監視部１０７で性能分析した結果を格納して、クラウド間やラインナップ間の性能比較のために用いられる。この情報は，以下のいずれかの方法で情報の更新を行うものとする。ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行う。性能分析部１０６、性能監視部１０７で取得した性能監視情報を分析した結果を格納する。
【００４８】
図７に例示するように、ラインナップ性能情報ＤＢは、性能情報を取得した時刻である「取得時刻」と、「ラインナップＩＤ」と、クラウドに関する性能項目である「性能項目」と、性能項目に対する値である「値」とを対応付けて記憶する。
【００４９】
次に、図８を用いて、テナント情報ＤＢについて説明する。図８は、クラウド管理用ＤＢ群１１０のテナント情報ＤＢに記憶されるテーブルの構成例を示す図である。テナント情報ＤＢは、ハイブリッドクラウドサービスにおけるテナント情報を管理するテーブルを記憶する。この情報は、ハイブリッドクラウド事業者が管理者用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。
【００５０】
図８に例示するように、テナント情報ＤＢは、ユーザテナントを識別する「テナントＩＤ」と、テナントを契約している人物や組織を示す「契約者名」と、テナントユーザがユーザＡＰＩ１０１から操作を行う際に必要とするパスワードである「パスワード」とを対応付けて記憶する。
【００５１】
次に、図９を用いて、クラウドサービス登録情報ＤＢについて説明する。図９は、クラウド管理用ＤＢ群１１０のクラウドサービス登録情報ＤＢに記憶されるテーブルの構成例を示す図である。クラウドサービス登録情報ＤＢは、各テナントごとに、利用登録したクラウドサービスに関する情報を管理するＤＢである。この情報は、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。
【００５２】
図９に例示するように、クラウドサービス登録情報ＤＢは、テナントが利用登録したクラウドサービスを識別するためのＩＤである「クラウドサービス登録ＩＤ」と、登録したクラウドサービスのＩＤである「クラウドサービスＩＤ」と、利用登録したテナントＩＤである「テナントＩＤ」と、クラウドサービスのリソース管理に使用する「ユーザＩＤ」」と、クラウドサービスのリソース管理に使用するパスワードである「パスワード」とを対応付けて記憶する。
【００５３】
次に、図１０を用いて、ＮＷ管理ＤＢについて説明する。図１０は、クラウド管理用ＤＢ群１１０のＮＷ管理ＤＢに記憶されるテーブルの構成例を示す図である。各テナントが利用登録したクラウドサービスごとに、割り当てられたＶＬＡＮ等のＮＷ管理情報を管理するＤＢである。ＮＷ管理情報は、ビジネスモデルによりデータ管理方法が異なる。ユーザが管理するモデルについては、ユーザがユーザＡＰＩ１０１を経由して、データの登録、更新、削除を行う。ハイブリッドクラウド事業者が管理するモデルについては、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行う。
【００５４】
図１０に例示するように、ネットワークを識別するためのＩＤである「ネットワークＩＤ」と、ネットワークがあるクラウドサービスのクラウドサービス登録ＩＤである「クラウドサービス登録ＩＤ」と、ＶＰＮ接続用ゲートウェイのリソースＩＤである「リソースＩＤ」と、ＧＷ用ＶＭテンプレートに設定されたリモートログインのためのユーザＩＤである「ＧＷユーザＩＤ」と、ＧＷ用ＶＭテンプレートに設定されたリモートログインのためのパスワードである「ＧＷパスワード」と、このネットワークが属するＶＬＡＮを識別するＩＤである「ＶＬＡＮ管理ＩＤ」と、ネットワークのグローバルアドレスである「グローバルアドレス」と、ネットワークのローカルアドレス帯である「ローカルアドレス」とを対応付けて記憶する。
【００５５】
次に、図１１を用いて、クラウド間ＮＷ管理ＤＢについて説明する。図１１は、クラウド管理用ＤＢ群１１０のクラウド間ＮＷ管理ＤＢに記憶されるテーブルの構成例を示す図である。クラウド間ＮＷ管理ＤＢは、クラウドサービス間のＮＷ接続に関する情報を管理するＤＢである。ＮＷ構成情報は、ビジネスモデルによりデータ管理方法が異なる。ユーザが管理するモデルについては、ユーザがユーザＡＰＩ１０１を経由して、データの登録、更新、削除を行う。ハイブリッドクラウド事業者が管理するモデルについては、ハイブリッドクラウド事業者が管理用ＩＦ１１５を経由して、データの登録、更新、削除を行う。
【００５６】
図１１に例示するように、クラウド間ＶＰＮ接続を識別するためのＩＤである「クラウド間接続ＩＤ」と、ハイブリッドクラウド上の顧客テナントを識別するＩＤである「テナントＩＤ」と、ＶＬＡＮを識別するためのＩＤである「ＶＬＡＮ管理ＩＤ」と、ＶＰＮ接続の対象となる発ネットワークのＩＤである「発ネットワークＩＤ」と、ＶＰＮ接続の対象となる着ネットワークのＩＤである「着ネットワークＩＤ」とを対応付けて記憶する。
【００５７】
次に、図１２を用いて、ＶＭ情報ＤＢについて説明する。図１２は、クラウド管理用ＤＢ群１１０のＶＭ情報ＤＢに記憶されるテーブルの構成例を示す図である。ＶＭ情報ＤＢは、ＶＭに関する情報を管理するＤＢである。ＶＭ情報ＤＢは、リソース管理部１０２でＶＭが新たに作成された場合に、自動的にデータの登録が行われる。但し、一部の属性情報（ＶＭ種別やＩＰアドレスなど）に関しては，ユーザＡＰＩ１０１を経由してユーザないしはハイブリッド事業者がデータの更新を行うものとする。
【００５８】
図１２に例示するように、ＶＭ情報ＤＢは、ＶＭを識別するＩＤである「ＶＭＩＤ」と、ＶＭが存在するクラウドサービスのＩＤである「クラウドサービスＩＤ」と、クラウドサービスで提供するラインナップを識別するＩＤである「ラインナップＩＤ」と、ＶＭが配置されているクラウドサービスの登録ＩＤである「クラウドサービス登録ＩＤ」と、ＶＭが属するテナントＩＤである「テナントＩＤ」と、ＶＭ作成に使用したＶＭテンプレートＩＤである「ＶＭテンプレートＩＤ」と、ユーザがＶＭを識別するための種別である「ＶＭ種別」と、ＶＭが接続するＶＬＡＮ管理ＩＤである「接続ＶＬＡＮ管理ＩＤ」と、ＶＭのＩＰアドレスである「ＩＰアドレス」と、ＶＭの割当ＣＰＵコア数である「ＣＰＵコア数」と、ＶＭの割当メモリである「メモリ量」とを対応付けて記憶する。
【００５９】
次に、図１３を用いて、ＶＭ稼働情報ＤＢについて説明する。図１３は、クラウド管理用ＤＢ群１１０のＶＭ稼働情報ＤＢに記憶されるテーブルの構成例を示す図である。ＶＭ稼働情報ＤＢでは、ＶＭの状態の稼動状態を管理しており、リソース管理部１０２でＶＭの状態を変更した場合には、自動的に追記される。
【００６０】
図１３に例示するように、ＶＭ稼働情報ＤＢでは、ＶＭの状態が変化した時刻である「時刻」と、ＶＭを識別するＩＤである「ＶＭＩＤ」と、ＶＭの稼働状況である「稼働状態」とを対応付けて記憶する。
【００６１】
次に、図１４を用いて、ＶＭテンプレートＤＢについて説明する。図１４は、クラウド管理用ＤＢ群１１０のＶＭテンプレートＤＢに記憶されるテーブルの構成例を示す図である。ＶＭテンプレートＤＢでは、新規にＶＭを作成する際に、ＶＭ作成に用いるＶＭテンプレートを管理する。ＶＭテンプレートには、ＯＳやミドルウェアや各種設定が施されており、ＶＭ作成に際して１からシステムを構築することなく作成することを可能にする。多くのユーザが利用する機会が多いＷｅｂサーバ、ＤＢサーバなど汎用的な機能や、ＶＰＮ接続を提供する仮想ルータなど、特殊な機能を容易に提供することができる。
【００６２】
また、ＶＭテンプレートは、ＶＭテンプレート作成者が管理するものとする。ハイブリッドクラウド事業者が提供するＶＭテンプレートでは、ハイブリッドクラウド事業者が、管理用ＩＦ１１５を経由してデータの登録、更新、削除を行う。ユーザが作成したＶＭテンプレートでは、ユーザがユーザＡＰＩ１０１を経由して、データの登録、更新、削除を行う。
【００６３】
図１４に例示するように、ＶＭテンプレートＤＢでは、ＶＭテンプレートを識別するＩＤである「ＶＭテンプレートＩＤ」と、ＶＭテンプレートの所有テナントのＩＤである「所有テナントＩＤ」と、ＶＭテンプレートを他テナントに公開するか否かを示す「公開／非公開」と、ＶＭテンプレートに使われているＯＳである「ＯＳ」と、ＶＭ作成時に必要となるテンプレート内に含まれる有償ライセンスの情報である「ライセンスリスト」と、ＶＭテンプレートを用いて作成されたＶＭの監視を行う場合の設定である「監視設定」とを対応付けて記憶する。
【００６４】
次に、図１５を用いて、監視設定ＤＢについて説明する。図１５は、クラウド管理用ＤＢ群１１０の監視設定ＤＢに記憶されるテーブルの構成例を示す図である。監視設定ＤＢでは、ＶＭや物理サーバ、ＮＷ機器に対する監視設定の情報を管理する。ＶＭに対する監視設定情報は、ユーザＡＰＩ１０１を通じてＶＭ作成、起動、停止、削除が行われたときに、自動的に登録、更新、削除される。監視設定において、各構成品に対してどのような監視を行うか設定できる。
【００６５】
主な監視設定には、システムの死活監視を行う「ＩＣＭＰ監視」、「Ｌｉｎｕｘ（登録商標）の性能情報を監視する「Ｌｉｎｕｘ監視」、  ネットワーク機器の性能情報を監視する「ＳＮＭＰ監視」などがある。ＩＣＭＰ監視は、各構成品のＩＰアドレスに対してＰｉｎｇをかけて、システムの死活状態を監視する。また、Ｌｉｎｕｘ監視は、ＳＳＨプロトコルで各構成品にアクセスして、既存のＬｉｎｕｘコマンドを用いて性能情報（ＣＰＵ情報、メモリ情報、Ｉ／Ｏ情報、プロセス情報、トラフィック情報、ｓｙｓｌｏｇ情報など）を取得する。ＳＮＭＰ監視は、ＳＮＭＰプロトコルを用いて、ＳＮＭＰ経由で取得できる性能情報（トラフィック情報、メモリ情報、ＣＰＵ情報）を取得する。
【００６６】
図１５に例示するように、監視設定ＤＢでは、性能情報を取得するリソースのＩＤである「リソースＩＤ」と、「ＶＭＩＤ」と、監視に用いるＩＰアドレスである「監視ＩＰアドレス」と、監視の稼働状態である「監視状態」と、監視設定プラグインのリストである「監視設定」とを対応付けて記憶する。
【００６７】
次に、図１６を用いて、リソース性能情報ＤＢについて説明する。図１６は、クラウド管理用ＤＢ群１１０のリソース性能情報ＤＢに記憶されるテーブルの構成例を示す図である。リソース性能情報ＤＢでは、性能監視部で取得した性能情報を格納するテーブルを記憶する。性能監視部１０７は、稼動中のリソース（ＶＭ、物理サーバ、ＮＷ機器）に対して定期的に情報を取得して、データを追加する。
【００６８】
図１６に例示するように、リソース性能情報ＤＢは、性能情報を取得した時刻である「取得時刻」と、「リソースＩＤ」と、性能監視の項目である「監視項目」と、取得した性能値である「値」とを対応付けて記憶する。
【００６９】
［スキーマ変換処理］
クラウド管理用ＤＢ群１１０は、ハイブリッドクラウドの運用のために最適化されたデータスキーマをとっているため、そのままではデータを網羅的に閲覧することは困難である。そこで、網羅的な閲覧が容易となるような、統一的なデータスキーマに変換する。
【００７０】
異なる複数テーブルで、同一対象を示すＩＤが存在するが、それぞれ異なる形式で表現されている場合には、何れかのテーブルのＩＤの形式に統一する。元々は異なる機能を実現するために必要としたＤＢであるため、それぞれ独自の形式のＩＤを付与していても問題はなかったが、統一的にデータを参照する場合は、ＩＤを統一する必要がある。例えば、ＶＭ情報ＤＢのＩＤである「ＶＭＩＤ」と、監視設定ＤＢのＩＤであるリソースＩＤは、いずれも特定のＶＭを示すＩＤである。
【００７１】
ここでＩＤ名寄せを実現する方法について説明する。ここでＩＤ名寄せとは、異なる複数のＤＢ（テーブル）において、同一対象を示すＩＤであるが、それぞれ異なる形式で表現されているＩＤについて、形式を統一するために行う処理のことをいう。クラウド管理用ＤＢ群１１０へのデータ追加は、リソース管理部１０２からの動的追加、ないしは管理用ＩＦ１１５からデータの手動追加の２パターンがある。まず、ＩＤ名寄せルールの定義として、ハイブリッドクラウド管理者が管理用ＩＦ１１５を通じてスキーマ変換ルールに名寄せルールを登録する。例えば、図１７に例示するように、ＶＭ情報ＤＢのＩＤである「ＶＭＩＤ」と、監視設定ＤＢのＩＤである「リソースＩＤ」、「リソース性能情報ＤＢ」のＩＤである「リソースＩＤ」を名寄せする。その際、「ＶＭ情報ＤＢ」のＩＤに統一する。図１７は、ＩＤ名寄せルールの一例を示す図である。
【００７２】
リソース管理部１０２からの動的追加の場合には、第一の方法として、名寄せ変換テーブル生成ルールを用いて、名寄せ変換テーブルデータを生成し、追加する。また、第二の方法として、テーブル生成が出来ない場合には、リソース管理部１０２によってＩＤがＤＢ登録される際に、名寄せする値を名寄せ変換テーブル群１１４に登録する。なお、管理用ＩＦ１１５からデータの手動追加の場合には、管理用ＩＦ１１５を通じて、名寄せ変換テーブルに手動で投入する。
【００７３】
ここで、名寄せ変換テーブル生成ルールについて説明する。クラウド上で運用するに当たり、異なる形式のＩＤ間の関係性を記録したデータが無ければ一元的な管理はできないため、どこかにＩＤ間の対応関係を示すデータが存在する。例えば、図１８に例示するように、監視設定ＤＢのリソースＩＤとＶＭＩＤが対応関係を示すデータであるため、このデータを利用して名寄せ変換テーブルを生成する方法が、ＳＱＬで示した名寄せ変換テーブル生成ルールに定義されている。図１８は、名寄せ変換テーブル生成ルールの一例を示す図である。
【００７４】
名寄せ変換テーブルにデータ追加した後は、名寄せ変換テーブルを用いてＩＤを名寄せする。ここで、名寄せ変換テーブルの例について、例えば、図１９に例示するように、名寄せ変換テーブルには、「カラム名」ごとに、「名寄せ前値」と「名寄せ後値」とが対応付けて記憶されている。図１９は、名寄せ変換テーブルの一例を示す図である。
【００７５】
異なるクラウドサービスから提供された情報には、同じ意味や値を示す場合でも、異なる表記で示されている表記ゆれが含まれる。他サービスと比較するために、表記ゆれを補正する必要がある。表記ゆれの例として、例えば、「東京」と「アジアパシフィック(東京)」、「Ｔｏｋｙｏ」がある。また、表記ゆれの例として、例えば、「ｖＣＰＵ」と、「ＣＰＵ」、「コア数」、「仮想ＣＰＵ」がある。
【００７６】
また、表記ゆれの補正方法としては、管理用ＩＦ１１５を通じて名寄せ変換テーブルを投入しておき、名寄せ変換テーブルを用いて名寄せを行う。例えば、図２０に例示するように、名寄せ変換テーブルには、「カラム名」ごとに、「名寄せ前値」と「名寄せ後値」とが対応付けて記憶されている。図２０は、名寄せ変換テーブルの一例を示す図である。
【００７７】
また、異なるクラウドサービスから提供された情報には、同じ属性情報の値でも異なる単位で記載されているデータが存在する。比較するためには値の単位を統一させる必要がある。型変換が必要な例として、例えば、ＶＭ価格について、価格が日本円の場合と米ドルの場合とでは、型変更が必要となる。また、メモリについてＭＢ単位の値と、ＧＢ単位の値とでは、型変更が必要となる。型変換の方法としては、型変換ルール（スクリプト等）を定義しておき、ルールを用いて値の変換を行う。
【００７８】
また、クラウド管理用ＤＢ群１１０の中には、明記されていない情報もある。例えば、データを補完しなければ、他のサービスと比較できないため、補完させる必要がある。例えば、値の補完が必要な例として、「ラインナップスペック情報ＤＢ」の「最大ＮＩＣ数」について、あるクラウドサービスでは、ＮＩＣ数は一律Ｎ個と決まっているため、明記されておらず、この値を補完する必要がある。値の補完方法としては、例えば、補完ルール（スクリプト等）を定義しておき、ルールを用いて値の変換を行う。
【００７９】
また、スキーマ変換の処理の一つとして、網羅的な閲覧が困難となる場合には、テーブル形式を変換して、網羅的な閲覧が容易となるように統一的な形式に変換する処理を行う。例えば、網羅的な閲覧が困難となる場合として、同一対象に関するデータが、複数のテーブルに分散されている場合が考えられる。つまり、異なる機能を管理するため、個別にテーブルが作成されたり、処理効率を上げるためにあえてテーブルを分割したりする例がある。具体的な例を挙げて説明すると、クラウドサービスのラインナップに関する情報は、ラインナップ価格ＤＢ、ラインナップスペックＤＢ、ラインナップ性能ＤＢなど、複数のテーブルに分散されている。
【００８０】
また、網羅的な閲覧が困難となる場合として、テーブルへの格納スタイルが異なる場合が考えられる。例えば、一般的なテーブルは、ＩＤに紐づく属性情報を複数のカラム（行）に記載し、１つのレコード（列）が１つの対象に関するデータを示すスタイルで記録される。具体的な例を挙げて説明すると、ラインナップ価格ＤＢにおいて、対象：クラウドサービスのラインナップについて、ＩＤ：ラインナップＩＤ、属性情報：課金形態、固定課金期間、ＶＭ価格が記憶されている。
【００８１】
属性情報の種類が特定できない場合は、一般的なスタイルではデータ格納が難しくなる。そのため、ＩＤと属性情報名及び値の３つ組を格納するスタイルなどで格納される場合がある。例えば、前述したラインナップスペック情報ＤＢに記憶された３組ベースのテーブルである。
【００８２】
変換後の統一的な形式は、一般的なテーブルでも、３組ベースのテーブルでも構わない。ハイブリッドクラウドサービスのデータは、様々な要素が複雑に関連しているため、一般的なテーブル形式よりも、３組ベースのテーブルの方が閲覧しやすい。３組ベースのテーブルには、複雑な意味関係を表現、検索できるＲＤＦが便利である。以降、３組ベースのテーブル相当のＲＤＦデータモデルへの変換方法を説明する。
【００８３】
ＲＤＦデータは、サブジェクト、プロパティ、オブジェクトの３つ組みで表される。例えば、図２１に示した例を挙げて説明すると、図２１の（ａ）における「ｅｍｐ：１２３４１１１」とラベルが付けされた楕円ノードがサブジェクト、「鈴木太郎」とラベルが付けされた長方形ノードがオブジェクト、「ｅｍｐ：氏名」とラベル付けされた有向きエッジがプロパティであらわされる。
【００８４】
ＲＤＦデータでは、楕円ノードで表現されるリソースと、長方形ノードで表現されるリテラルの２種類のノードがある。リソースとプロパティには、ＵＲＩなどユニークに識別できるＩＤをラベルとしてふられる。リソースには、ｒｄｆ：ｔｙｐｅでタイプを割り当てることができる。例えば、図２１の（ｂ）では、リソース「ｅｍｐ：１２３４１１１」のタイプは「ｅｍｐ：社員」である。ＲＤＦデータは，ラベル付き有効グラフで表現できる。
【００８５】
クラウド管理用ＤＢ群１１０のテーブルは、プライマリキー有りテーブルと、プライマリキー無しテーブルと、３つ組みベースのテーブルの３種類に分類することができる。プライマリキー有りテーブルは、最も一般的なテーブルで、１つのプライマリキーを有したテーブルである。例えば、クラウドリストＤＢ、ラインナップＤＢ、ラインナップ価格ＤＢ、テナント情報ＤＢ、クラウドサービス登録情報ＤＢ、クラウド間ＮＷ管理ＤＢ、ＶＭ情報ＤＢ、ＶＭテンプレートＤＢ、監視設定ＤＢがプライマリキー有りテーブルに該当する。
【００８６】
プライマリキー無しテーブルは、プライマリキーが存在しないか、複数のカラムをプライマリキーとして設定されているテーブルである。例えば、プライマリキー無しテーブルは、ＶＭ稼動情報ＤＢ、ラインナップ性能情報ＤＢ、リソース性能情報ＤＢが該当する。
【００８７】
また、３つ組みベースのテーブルは、プライマリキー無しテーブルのうち、ＩＤとカラム名及び値の３つ組で構成されたテーブルであり、例えば、ラインナップスペック情報ＤＢが該当する。
【００８８】
プライマリキー有りテーブルの変換例として、テーブルの各レコードごとに変換する処理について説明する。具体的には、ＩＤ名寄せルールに記載があるカラム名の値はＲＤＦリソースに、それ以外はリテラルにする。また、ＲＤＦリソースのタイプは、ＩＤ名寄せルールの先頭ＩＤ名を用いる。また、プライマリキーをＲＤＦリソースに変換し、これをサブジェクトに、プライマリキー以外のカラム名をプロパティ名に、そのカラムの値をオブジェクトに変換する。また、リスト形式の値の場合は、各値に対してカラム名をプロパティ名に、値をオブジェクトとして加える。なお、ラインナップ価格ＤＢにおけるテーブルのレコードを変換したＲＤＦデータの例と、実際に計算機処理するデータフォーマットの例を図２２に示す。図２２は、ラインナップ価格ＤＢにおけるテーブルの変換例を示す図である。
【００８９】
プライマリキー無しテーブルの変換例として、テーブルの各レコードごとに変換する処理について説明する。ＩＤ名寄せルールに記載があるカラム名の値はＲＤＦリソースに、それ以外はリテラルにする。また、ＲＤＦリソースのタイプは、ＩＤ名寄せルールの先頭ＩＤ名を用いる。ブランクノードをサブジェクトに、カラム名をプロパティ名に、そのカラムの値をオブジェクトに変換する。ブランクノードのタイプは、テーブル名を用いる。なお、ＶＭ稼働情報ＤＢにおけるテーブルのレコードを変換したＲＤＦデータの例を図２３に示す。図２３は、ＶＭ稼働情報ＤＢにおけるテーブルの変換例を示す図である。
【００９０】
３つ組みベースのテーブルの変換例として、テーブルの各レコードごとに変換する処理について説明する。上記のリソースのタイプは、ＩＤ名寄せルールの先頭ＩＤ名を用いる。また、ＩＤ名寄せルールに記載があるカラム名の値はＲＤＦリソースに、それ以外はリテラルにする。また、ＩＤをＲＤＦリソースに変換し、これをサブジェクトに、カラム名の値をプロパティ名にその値をオブジェクトに変換する。なお、ラインナップスペック情報ＤＢにおけるテーブルのレコードを変換したＲＤＦデータの例を図２４に示す。図２４は、ラインナップスペック情報ＤＢにおけるテーブルの変換例を示す図である。
【００９１】
このように、テーブル変換を行った後、図２５に例示するようなＲＤＦデータに対しては、ＳＰＡＲＱＬ等のＲＤＦクエリ言語を用いて、容易にスキーマ構造変換を行うことが可能である。ポリシー検索を行いやすいように、再度スキーマ変換してもよい。また、不要な値を削除したり、矢印の向き（サブジェクトとオブジェクトの関係）を逆転させたりしてもよい。図２５は、テーブル変換後のスキーマ構造を示す図である。
【００９２】
また、より便利なポリシー検索が可能となるように、変換データに対して、外部データを追加してもよい。例えば、図２６に例示するように、都道府県の距離データを変換データに追加するようにしてもよい。図２６は、外部データ追加の例を示す図である。
【００９３】
［ＶＭ調達ポリシーＤＢの例］
ここで、図２７および図２８を用いて、ＶＭ調達ポリシーＤＢに記憶される情報について説明する。図２７は、ＶＭ調達ポリシーＤＢに記憶されるテーブルの構成例を示す図である。図２８は、ＶＭポリシーＤＢに記憶されるテーブルの一例を示す図である。
【００９４】
ＶＭ調達ポリシーとは、複数のクラウドサービスにある計算機リソースの中から、ユーザニーズに合致したラインナップやＶＭを検索するために用いられるクエリのことである。ＶＭ調達ポリシーは、ＶＭ調達ポリシーＤＢに格納されており、ハイブリッドクラウド事業者が、管理用ＩＦ１１５を経由して、データの登録、更新、削除を行うものとする。
【００９５】
図２７に示すように、ＶＭ調達ポリシーＤＢでは、ポリシーを識別するＩＤである「ポリシーＩＤ」と、ポリシーに関するＶＭ操作の種類を記述である「ＶＭ操作」と、検索に必要な入力パラメータのリストである「入力パラメータ」と、検索結果として出される値の種類である「出力パラメータ」と、ポリシーに従ってＶＭ操作する対象のラインナップＩＤを検索するクエリである「クエリ」とを対応付けて記憶する。なお、図２７の例では、クエリは、ＳＰＡＲＱＬ風に表記されている。
【００９６】
ここで、図２８を用いて、図２５に例示したスキーマ構造のスキーマ変換後ＤＢ１１２に対して検索するクエリの例について説明する。図２８に例示するように、例えば、ポリシーＩＤが“性能優先ＶＭ停止”、ＶＭ操作が“ＶＭ停止”、入力パラメータが｛“テナントＩＤ”｝、出力パラメータが“ＶＭＩＤ”であるクエリは、以下のように表記される。
SELECT  ?VMID  ｛
?VMID  テナント  %%テナントID%%.
?VMID  VMラインナップ  ?ラインナップID.
?VMID  稼動状態  “起動”.
?ラインナップID  ラインナップ性能情報  ?ラインナップ性能情報.
?ラインナップ性能情報  CPUベンチマーク結果  ?CPUベンチマーク結果.
｝  ORDER  BY  DESC(?CPUベンチマーク結果)
【００９７】
［リソース管理装置による処理］
次に、図２９〜図３３を用いて、第一の実施形態に係るリソース管理装置１０による処理を説明する。図２９は、第一の実施の形態に係るリソース管理装置におけるスキーマ変換処理の流れを説明するフローチャートである。図３０は、第一の実施の形態に係るリソース管理装置におけるＶＭ作成処理の流れを説明するシーケンス図である。図３１は、第一の実施の形態に係るリソース管理装置におけるＶＭ起動処理の流れを説明するシーケンス図である。図３２は、第一の実施の形態に係るリソース管理装置におけるＶＭ停止処理の流れを説明するシーケンス図である。図３３は、第一の実施の形態に係るリソース管理装置におけるＶＭ削除処理の流れを説明するシーケンス図である。
【００９８】
まず、図２９を用いて、リソース管理装置１０におけるスキーマ変換処理の流れを説明する。図２９に示すように、リソース管理装置１０のスキーマ変換部１０９は、クラウド管理用ＤＢ群１１０に記憶されたデータを読み込み（ステップＳ１０１）、ＩＤの名寄せを行う（ステップＳ１０２）。これにより、テーブルのＩＤの形式に統一する。
【００９９】
そして、スキーマ変換部１０９は、表記ゆれの補正を行い（ステップＳ１０３）、値の型変換を行う（ステップＳ１０４）。続いて、スキーマ変換部１０９は、値が明記されていない場合に、値の補完を行って（ステップＳ１０５）、テーブル形式の変換を行う（ステップＳ１０６）。
【０１００】
そして、スキーマ変換部１０９は、外部データの追加を行い（ステップＳ１０７）、変換後のデータをスキーマ変換後ＤＢ１１２へ出力する（ステップＳ１０８）。クラウド管理用データ群１１０では、ハイブリッドクラウドの運用のために最適化されたデータスキーマをとっており、そのままではデータを網羅的に閲覧することは困難であることから、網羅的な閲覧が容易となるような統一的なデータスキーマに変換するために、上記の処理を行う。
【０１０１】
次に、図３０を用いて、ＶＭ作成処理について説明する。図３０に例示するように、ユーザＡＰＩ１０１は、ユーザ用ＵＩ２１からＶＭ作成条件を受け付けると（ステップＳ２０１）、リソース管理部１０２にＶＭ作成条件を通知する（ステップＳ２０２）。そして、リソース管理部１０２は、作成条件とＮＷ管理情報からＶＭ作成可能なクラウド登録ＩＤを検索する（ステップＳ２０３）。なお、検索の結果、検索件数が２件以上の場合には、ステップＳ２０４に移行し、検索件数が１件の場合には、ステップＳ２０７に移行し、０件の場合には、ステップＳ２１２に移行する。
【０１０２】
そして、リソース管理部１０２は、ＶＭ作成するラインナップ選択依頼をクラウド選択部１０８に通知する（ステップＳ２０４）。続いて、クラウド選択部１０８は、ポリシー定義情報のデータに基づき、ＶＭを作成に適したクラウドサービスラインナップＩＤの選択を行う（ステップＳ２０５）。そして、クラウド選択部１０８は、ＶＭ作成するラインナップ選択結果をリソース管理部１０２に通知する（ステップＳ２０６）。
【０１０３】
その後、リソース管理部１０２は、ＶＭを作成するために必要な情報をクラウドリスト情報とＶＭテンプレート情報とから抽出し、クラウドサービス向けのクエリを作成する（ステップＳ２０７）。そして、リソース管理部１０２は、ＶＭの作成依頼をリソース管理ＡＰＩ１０５にする（ステップＳ２０８）。そして、リソース管理ＡＰＩ１０５は、対象のクラウドサービスのクラウド管理ＡＰＩへＶＭ作成依頼を行い（ステップＳ２０９）、ＶＭ作成依頼結果をリソース管理部１０２に通知する（ステップＳ２１０）。
【０１０４】
そして、リソース管理部１０２は、ＶＭ作成が成功した場合には、リソース情報に新たなＶＭに関する情報を登録し、新たなＶＭの監視設定を監視設定情報に追加する（ステップＳ２１１）。そして、リソース管理部１０２は、ユーザＡＰＩ１０１に返すＶＭ作成結果を作成し（ステップＳ２１２）、ＶＭ作成結果をユーザＡＰＩ１０１に通知する（ステップＳ２１３）。そして、ユーザＡＰＩ１０１は、ＶＭ作成結果をユーザ用ＵＩ２１に送信する（ステップＳ２１４）。
【０１０５】
次に、図３１を用いて、ＶＭを起動するＶＭ起動処理について説明する。図３１に例示するように、ユーザＡＰＩ１０１は、ユーザ用ＵＩ２１からＶＭ起動条件を受け付けると（ステップＳ３０１）、リソース管理部１０２にＶＭ起動条件を通知する（ステップＳ３０２）。そして、リソース管理部１０２は、リソース情報の停止中のＶＭから起動条件に合致するＶＭを検索する（ステップＳ３０３）。なお、検索件数が０件の場合は、ステップＳ３１４に移行し、検索結果内から登録クラウドＩＤが１種類しかない場合は、ステップＳ３０７に移行する。
【０１０６】
そして、リソース管理部１０２は、ＶＭを起動する起動ＶＭＩＤ選択依頼をクラウド選択部１０８に通知する（ステップＳ３０４）。続いて、クラウド選択部１０８は、ポリシー定義情報のデータに基づき、ＶＭが属するクラウドサービスラインナップＩＤの中から適したクラウドサービスラインナップＩＤの選択を行う（ステップＳ３０５）。そして、クラウド選択部１０８は、起動ＶＭＩＤ選択結果をリソース管理部１０２に通知する（ステップＳ３０６）。
【０１０７】
そして、リソース管理部１０２は、選択されたクラウドサービスラインナップＩＤのＶＭを１つ選択し、「クラウドリスト情報」から必要なデータを抽出して、クラウドサービス向けのクエリを作成する（ステップＳ３０７）。そして、リソース管理部１０２は、ＶＭ起動依頼をリソース管理ＡＰＩ１０５に通知し（ステップＳ３０８）、対象のクラウドサービスのクラウド管理ＡＰＩへＶＭ起動依頼を行い（ステップＳ３０９）、ＶＭ起動結果をリソース管理部１０２に通知する（ステップＳ３１０）。
【０１０８】
そして、リソース管理部１０２は、ＶＭ起動が成功した場合に、リソース情報と監視設定情報の更新をする（ステップＳ３１１）。そして、リソース管理部１０２は、ＶＭ性能監視起動を性能監視部１０７に依頼する（ステップＳ３１２）。続いて、性能監視部１０７は、起動ＶＭのリソースＩＤの監視を開始する（ステップＳ３１３）。また、リソース管理部１０２は、ユーザＡＰＩ１０１に返すＶＭ起動結果を作成し（ステップＳ３１４）、ＶＭ起動結果をユーザＡＰＩ１０１に通知する（ステップＳ３１５）。そして、ユーザＡＰＩ１０１は、ＶＭ起動結果をユーザ用ＵＩ２１に送信する（ステップＳ３１６）。
【０１０９】
次に、図３２を用いて、ＶＭを停止するＶＭ停止処理について説明する。図３２に例示するように、ユーザＡＰＩ１０１は、ユーザ用ＵＩ２１からＶＭ停止条件を受け付けると（ステップＳ４０１）、リソース管理部１０２にＶＭ停止条件を通知する（ステップＳ４０２）。そして、リソース管理部１０２は、リソース情報の停止中のＶＭから停止条件に合致するＶＭを検索する（ステップＳ４０３）。なお、検索件数が０件の場合は、ステップＳ４１４に移行し、検索結果内から登録クラウドＩＤが１種類しかない場合は、ステップＳ４０７に移行する。
【０１１０】
そして、リソース管理部１０２は、ＶＭを停止するクラウドサービスラインナップ選択依頼をクラウド選択部１０８に通知する（ステップＳ４０４）。続いて、クラウド選択部１０８は、ポリシー定義情報のデータに基づき、ＶＭが属するクラウドサービスラインナップＩＤの中から適したクラウドサービスラインナップＩＤの選択を行う（ステップＳ４０５）。そして、クラウド選択部１０８は、クラウドサービスラインナップ選択結果をリソース管理部１０２に通知する（ステップＳ４０６）。
【０１１１】
そして、リソース管理部１０２は、選択されたクラウドサービスラインナップＩＤのＶＭを１つ選択し、「クラウドリスト情報」から必要なデータを抽出して、クラウドサービス向けのクエリを作成する（ステップＳ４０７）。そして、リソース管理部１０２は、ＶＭ停止依頼をリソース管理ＡＰＩ１０５に通知し（ステップＳ４０８）、対象のクラウドサービスのクラウド管理ＡＰＩへＶＭ停止依頼を行い（ステップＳ４０９）、ＶＭ停止結果をリソース管理部１０２に通知する（ステップＳ４１０）。
【０１１２】
そして、リソース管理部１０２は、ＶＭ停止が成功した場合に、リソース情報と監視設定情報の更新をする（ステップＳ４１１）。そして、リソース管理部１０２は、ＶＭ性能監視停止を性能監視部１０７に依頼する（ステップＳ４１２）。続いて、性能監視部１０７は、停止ＶＭのリソースＩＤの監視を停止する（ステップＳ４１３）。また、リソース管理部１０２は、ユーザＡＰＩ１０１に返すＶＭ停止結果を作成し（ステップＳ４１４）、ＶＭ停止結果をユーザＡＰＩ１０１に通知する（ステップＳ４１５）。そして、ユーザＡＰＩ１０１は、ＶＭ停止結果をユーザ用ＵＩ２１に送信する（ステップＳ４１６）。
【０１１３】
次に、図３３を用いて、ＶＭを削除するＶＭ削除処理について説明する。図３３に例示するように、ユーザＡＰＩ１０１は、ユーザ用ＵＩ２１からＶＭ削除条件を受け付けると（ステップＳ５０１）、リソース管理部１０２にＶＭ削除条件を通知する（ステップＳ５０２）。そして、リソース管理部１０２は、削除条件とＮＷ管理情報からＶＭ削除可能なクラウド登録ＩＤを検索する（ステップＳ５０３）。なお、検索の結果、検索件数が２件以上の場合には、ステップＳ５０４に移行し、検索件数が１件の場合には、ステップＳ５０７に移行し、０件の場合には、ステップＳ５１２に移行する。
【０１１４】
そして、リソース管理部１０２は、ＶＭ削除するラインナップ選択依頼をクラウド選択部１０８に通知する（ステップＳ５０４）。続いて、クラウド選択部１０８は、ポリシー定義情報のデータに基づき、ＶＭを削除に適したクラウドサービスラインナップＩＤの選択を行う（ステップＳ５０５）。そして、クラウド選択部１０８は、ＶＭ削除するラインナップ選択結果をリソース管理部１０２に通知する（ステップＳ５０６）。
【０１１５】
その後、リソース管理部１０２は、ＶＭを削除するために必要な情報をクラウドリスト情報とＶＭテンプレート情報とから抽出し、クラウドサービス向けのクエリを作成する（ステップＳ５０７）。そして、リソース管理部１０２は、ＶＭの削除依頼をリソース管理ＡＰＩ１０５にする（ステップＳ５０８）。そして、リソース管理ＡＰＩ１０５は、対象のクラウドサービスのクラウド管理ＡＰＩへＶＭ削除依頼を行い（ステップＳ５０９）、ＶＭ削除依頼結果をリソース管理部１０２に通知する（ステップＳ５１０）。
【０１１６】
そして、リソース管理部１０２は、ＶＭ削除が成功した場合には、リソース情報に新たなＶＭに関する情報を登録し、新たなＶＭの監視設定を監視設定情報に追加する（ステップＳ５１１）。そして、リソース管理部１０２は、ユーザＡＰＩ１０１に返すＶＭ削除結果を削除し（ステップＳ５１２）、ＶＭ削除結果をユーザＡＰＩ１０１に通知する（ステップＳ５１３）。そして、ユーザＡＰＩ１０１は、ＶＭ削除結果をユーザ用ＵＩ２１に送信する（ステップＳ５１４）。
【０１１７】
[第一の実施の形態の効果]
上述してきたように、リソース管理装置１０は、計算機リソースを提供する各クラウドサービスに関する情報を記憶するクラウド管理用ＤＢ群１１０と、クラウドサービスに関する情報を基に作成されたクエリを、計算機リソースの特徴を示すＶＭ調達ポリシーに対応付けて記憶するＶＭ調達ポリシーＤＢ１１３と、を有する。リソース管理装置１０は、スキーマ変換ルール群１１１に従って、クラウド管理用ＤＢ群１１０に記憶されたデータを、検索クエリにより検索可能な構造のデータに変換する。また、リソース管理装置１０は、ユーザ端末２０によりユーザが要求する計算機リソース上で稼働するＶＭの特徴を示すＶＭ調達ポリシーの指定を受け付けると、該ポリシーに対応するクエリをＶＭ調達ポリシーＤＢ１１３から取得し、該クエリを用いて、スキーマ変換部１０９により変換された情報に対して検索を行い、ポリシーに合致するクラウドサービスを選択する。そして、リソース管理装置１０は、選択されたクラウドサービスの計算機リソース上で稼働する仮想マシンの作成、仮想マシンの起動、仮想マシンの停止、または、仮想マシンの削除を実行する。このため、ユーザの負担を軽減しつつ、適切にＶＭを調達することが可能である。
【０１１８】
つまり、従来では、ユーザ自身に利用するクラウドサービスを選択させていたため、ユーザがどのクラウドサービスを使えばいいのかが分からず、ユーザ側の負担になっていた。これに対して、第一の実施に係るリソース管理装置１０では、ユーザが個々のクラウドサービスを意識することなく、ニーズに沿ったＶＭを利用可能にしている。事前に登録したクラウドサービスから、性能、価格、ロケーションなどのクラウドサービス情報を登録しておき、ＶＭ調達ポリシーとクラウドサービス選択ルールを定義しておき、ユーザが選択したＶＭ調達ポリシーからＶＭ調達先のクラウドサービスを自動選定し、ＶＭを確保する。このため、複数のクラウドサービスのなかから、ユーザニーズに合わせたＶＭを簡単に提供することが可能になる。これにより、例えば、「価格重視」で安価なＶＭを提供したり、「性能重視」で高性能なＶＭを提供したり、「リスク分散」で複数拠点のＶＭを提供したりすることが可能である。
【０１１９】
また、リソース管理システム１におけるハイブリッドクラウドサービスでは、利用可能なクラウドサービスのサービス情報、ＮＷに関する情報、テナント（顧客）に関する情報、稼動中のＶＭスペックの情報など多方面の情報を管理して運用する。これらの運用情報には、計算機資源の物理的な位置や、ＮＷの回線種類や、提供可能なＶＭのラインナップ（価格やスペック）、ＶＭの性能情報など、ユーザがＶＭ選択で必要とする情報が散在している。リソース管理装置１０では、事前にハイブリッドクラウドサービス管理者がＶＭ調達ポリシーとＶＭ調達クエリのペアを定義しておき、ユーザが選択したＶＭ調達ポリシーに対応するＶＭ調達クエリを用いてハイブリッドクラウドサービスの運用情報を検索することで、ユーザニーズに合致するクラウドサービスを選択する仕組みを提供する。その結果、ユーザはＶＭ調達ポリシーを選択するだけで、ユーザニーズに合致するＶＭを調達することが可能となる。
【０１２０】
また、ハイブリッドクラウドサービスの運用情報は、運用のためのＤＢ群であるため、運用に必要なデータを効率良く検索可能なスキーマ構造となっている。本来の目的外のＶＭ調達ポリシーに基づく検索を行う場合は、検索クエリが複雑になってしまうため、ハイブリッドクラウドサービス管理者によるＶＭ調達ポリシーの追加や修正が困難になる。そこで、ＶＭ調達に関わるデータのみを抜き出すなど、ＶＭ調達の観点から運用情報のデータ構造を変換するスキーマ変換ルールを定義しておき、スキーマ変換後の運用情報に対してクエリを実行する。
【０１２１】
また、スキーマ変換ルールを介した検索を用いることで、ＶＭ調達クエリがシンプルになり、ＶＭ調達ポリシーの追加や修正を容易に行うことが可能となる。更に、ハイブリッドクラウド運用体制の変更などにより、運用情報の変更が発生した場合も柔軟に対応することが可能となる。更に、ユーザに対しては、スキーマ変更ルール適用後の運用情報スキーマ情報と、ＶＭ調達クエリを提示することで、ＶＭ調達の根拠を示すことができ、ユーザサイドのコントロールが可能となる。
【０１２２】
以上のように、リソース管理装置１０では、事前に登録したクラウドサービスから、性能、価格、ロケーションなどのクラウドサービス情報を登録しておき、ＶＭ調達ポリシーとクラウドサービス選択ルールを定義しておき、ユーザが選択したＶＭ調達ポリシーからＶＭ調達先のクラウドサービスを自動選定し、ＶＭを確保するため、ユーザはＶＭ調達ポリシーを選択するだけで、ユーザが必要とするサービススペックを持つクラウドサービス上のＶＭを提供することが可能となる。
【０１２３】
［第二の実施の形態］
さて、これまで本発明の実施の形態について説明したが、本発明は上述した実施の形態以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では第二の実施の形態として本発明に含まれる他の第二の実施の形態を説明する。
【０１２４】
（１）システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１２５】
また、本実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１２６】
（２）プログラム
また、上記実施形態に係るリソース管理装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、リソース管理装置１０と同様の機能を実現するリソース管理プログラムを実行するコンピュータの一例を説明する。
【０１２７】
図３４は、リソース管理プログラムを実行するコンピュータを示す図である。図３４に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
【０１２８】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１およびＲＡＭ（Random  Access  Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。ディスクドライブ１０４１には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。
【０１２９】
ここで、図３４に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
【０１３０】
また、リソース管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明したリソース管理装置１０が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
【０１３１】
また、リソース管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
【０１３２】
なお、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、リソース管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local  Area  Network）やＷＡＮ（Wide  Area  Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【０１３３】
１０  リソース管理装置
１０１  ユーザＡＰＩ
１０２  リソース管理部
１０３  ネットワーク管理部
１０４  ネットワーク管理ＡＰＩ
１０５  リソース管理ＡＰＩ
１０６  性能分析部
１０７  性能監視部
１０８  クラウド選択部
１０９  スキーマ変換部
１１０  クラウド管理用ＤＢ群
１１１  スキーマ変換ルール群
１１２  スキーマ変換後ＤＢ
１１３  ＶＭ調達ポリシーＤＢ
１１４  名寄せ変換テーブル群
１１５  管理用ＩＦ
【図１】
2015184991.tif 000003
【図２】
2015184991.tif 000004
【図３】
2015184991.tif 000005
【図４】
2015184991.tif 000006
【図５】
2015184991.tif 000007
【図６】
2015184991.tif 000008
【図７】
2015184991.tif 000009
【図８】
2015184991.tif 000010
【図９】
2015184991.tif 000011
【図１０】
2015184991.tif 000012
【図１１】
2015184991.tif 000013
【図１２】
2015184991.tif 000014
【図１３】
2015184991.tif 000015
【図１４】
2015184991.tif 000016
【図１５】
2015184991.tif 000017
【図１６】
2015184991.tif 000018
【図１７】
2015184991.tif 000019
【図１８】
2015184991.tif 000020
【図１９】
2015184991.tif 000021
【図２０】
2015184991.tif 000022
【図２１】
2015184991.tif 000023
【図２２】
2015184991.tif 000024
【図２３】
2015184991.tif 000025
【図２４】
2015184991.tif 000026
【図２５】
2015184991.tif 000027
【図２６】
2015184991.tif 000028
【図２７】
2015184991.tif 000029
【図２８】
2015184991.tif 000030
【図２９】
2015184991.tif 000031
【図３０】
2015184991.tif 000032
【図３１】
2015184991.tif 000033
【図３２】
2015184991.tif 000034
【図３３】
2015184991.tif 000035
【図３４】
2015184991.tif 000036