JP6819131B2 - 情報処理装置、情報処理方法、情報処理プログラムおよび情報処理システム - Google Patents

Description

本発明は、情報処理装置、情報処理方法、情報処理プログラムおよび情報処理システムに関する。

従来から、データセンタ内で複数の仮想マシン（ＶＭ：Virtual Machine）を起動させて、各仮想マシンを企業等に提供する、クラウドコンピューティングを利用したクラウドサービス（以下で、クラウドと略記する場合がある）が知られている。近年では、異なる地域や異なる国にデータセンタを配置し、各データセンタが提供する狭域のクラウドを連携させた広域のクラウドも普及している。

このようなクラウドでは、狭域のクラウド内の仮想マシンが使用するリソースを集計して、最適なＶＭホストやストレージを割当てる技術が知られている。また、狭域のクラウド内の仮想マシンが使用するリソースの負荷情報を蓄積してＶＭホストごとの負荷を比較し、仮想マシンをマイグレーションして負荷を平準化する技術が知られている。

特開２０１１−２４３１１９号公報 特開２００９−１６９８５８号公報 特開２０１３−９２９５１号公報 特開２０１１−７６４７０号公報

しかしながら、上記技術では、広域のクラウド、すなわちクラウド全体でみたときに電力量の偏りが発生する。このため、電力料金の高い狭域のクラウドに仮想マシンが集中した場合、クラウド全体の電力料金が高くなるので、仮想マシンを利用する企業等が負担する費用も高くする。一方で、電力料金の低い狭域のクラウドに仮想マシンが集中した場合、クラウド全体の電力料金も安くなるので、仮想マシンを利用する企業等が負担する費用も安くする。このように、同じ仮想マシンを企業等に提供する場合でも、クラウド全体の電力量の偏りによって利用料金が異なることがあり、サービスレベルの低下に繋がる。

１つの側面では、クラウド全体の電力料金を削減することができる情報処理装置、情報処理方法、情報処理プログラムおよび情報処理システムを提供することを目的とする。

第１の案では、情報処理装置は、異なる地域に設置された各データセンタが提供する各クラウドサービスに関し、前記各クラウドサービスで仮想マシンを利用する際の電力に関する料金情報を収集する収集部を有する。情報処理装置は、前記各クラウドサービスで動作する各仮想マシンに関し、前記各仮想マシンの稼働情報を取得する取得部を有する。情報処理装置は、前記各クラウドサービスの料金情報と前記各仮想マシンの稼働状況とに基づいて、前記各仮想マシンの移動計画を生成する生成部を有する。

一実施形態によれば、クラウド全体の電力料金を削減することができる。

図１は、実施例１にかかるシステムの全体構成例を説明する図である。 図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。 図３は、拠点情報ＤＢに記憶される情報の例を示す図である。 図４は、電力会社ＤＢに記憶される情報の例を示す図である。 図５は、電力使用実績ＤＢに記憶される情報の例を示す図である。 図６は、電力使用状況ＤＢに記憶される情報の例を示す図である。 図７は、ＶＭリソース管理ＤＢに記憶される情報の例を示す図である。 図８は、ＤＣリソース管理ＤＢに記憶される情報の例を示す図である。 図９は、環境負荷ＤＢに記憶される情報の例を示す図である。 図１０は、電力需要予測ＤＢに記憶される情報の例を示す図である。 図１１は、レイテンシＤＢに記憶される情報の例を示す図である。 図１２は、帯域管理ＤＢに記憶される情報の例を示す図である。 図１３は、移動計画ＤＢに記憶される情報の例を示す図である。 図１４は、ＶＭゲストの配備時の制御を説明する図である。 図１５は、定期的なＶＭゲストの移動計画を説明する図である。 図１６は、電力料金を考慮したＶＭゲストの移動計画を説明する図である。 図１７は、全体的な処理の流れを示すシーケンス図である。 図１８は、配備・移動計画処理の流れを示すフローチャートである。 図１９は、移動計画処理の流れを示すフローチャートである。 図２０は、再配置計画を説明する図である。 図２１は、再配置前後の具体例を説明する図である。 図２２は、初動配備の制御例を説明する図である。 図２３は、マスタコントローラのハードウェア構成例を示す図である。

以下に、本願の開示する情報処理装置、情報処理方法、情報処理プログラムおよび情報処理システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１にかかるシステムの全体構成例を説明する図である。図１に示すように、このシステムは、異なる地域に設置されたデータセンタが提供するクラウドと、各クラウドを統括的に管理するサーバの一例であるマスタコントローラ３０とが、通信可能に接続されて構成される。図１では、一例として、日本、南アメリカ、オーストラリア、フランスの各国に設置されたデータセンタによってクラウドサービス（以下では、クラウドと記載する場合がある）が提供され、日本に設置されたマスタコントローラ３０が統括管理する例を説明する。なお、本実施例では、各ゾーンによって提供されるクラウドサービスを狭域クラウド、複数の狭域クラウドを全体とした時のクラウドサービスを広域クラウドと記載する場合がある。

ここで、各国には、国や都市などを地域で区別するリージョン名が割与えられている。例えば、日本には、リージョン名として「ＪＰ−１」が設定され、南アメリカには、「ＮＡ−Ｎ１」が設定される。また、各国は、地域等を考慮して複数のデータセンタをグループ化したゾーンを有する。

例えば、日本の場合、データセンタＤＣ００１とＤＣ００２をグループ化したゾーン「ＪＰ−Ｗ１」と、データセンタＤＣ０１１とＤＣ０１２をグループ化したゾーン「ＪＰ−Ｅ１」とを有する。したがって、ゾーン「ＪＰ−Ｗ１」では、データセンタＤＣ００１とＤＣ００２とによって、クラウド環境が提供され、ゾーン「ＪＰ−Ｅ１」では、データセンタＤＣ０１１とＤＣ０１２とによって、クラウド環境が提供される。なお、ゾーン内のデータセンタは同じ地域であることから、料金体系も同じであるとする。また、１つのクラウド環境は、１台のデータセンタで提供することもでき、複数台のデータセンタが連携して提供することもできる。

また、各ゾーンには、各データセンタすなわち各クラウド環境を管理するサーバの一例としてクラウド管理サーバ１０が設置される。例えば、日本の場合、ゾーン「ＪＰ−Ｗ１」とゾーン「ＪＰ−Ｅ１」とのそれぞれにクラウド管理サーバ１０が設置される。なお、ここでは、日本を例に説明したが、各国も同様の構成を有する。また、各国の各クラウド管理サーバも同様の機能を有するので、クラウド管理サーバ１０として説明する。

このようなシステムにおいて、各クラウド管理サーバ１０は、各クラウド内での仮想マシン（以下では、ＶＭまたはＶＭゲストと記載する場合がある）の配備要求に対し、マスタコントローラ３０に問い合わせを行う。また、各クラウド管理サーバ１０は、問い合わせの応答結果にしたがって、自身が管理する狭域クラウドの環境や広域クラウドの環境を用いてＶＭゲストを動作させたり、ＶＭゲストを停止させたりする。また、各クラウド管理サーバ１０は、自身が管理する狭域クラウドのリソースに関する情報、当該狭域クラウドで動作するＶＭゲストに関する情報などを定期的に収集して管理する。

そして、マスタコントローラ３０は、各クラウド管理サーバ１０から、狭域クラウドのリソースに関する情報やＶＭゲストに関する情報を収集する。このようなマスタコントローラ３０は、異なる地域に設置されたデータセンタが提供する狭域クラウドに関し、各狭域クラウド上でＶＭゲストを利用する際の電力に関する料金情報を収集する。また、マスタコントローラ３０は、各狭域クラウドで動作する各ＶＭゲストに関し、各ＶＭゲストがクラウドに配備されてからの累積時間を取得する。そして、マスタコントローラ３０は、各狭域クラウドの料金情報と各ＶＭゲストの累積時間とに基づいて、各ＶＭゲストの移行計画を生成する。

例えば、マスタコントローラ３０は、相対的に稼働時間が長いＶＭゲストを相対的に電力料金が安いクラウドに移動させる移動計画と、相対的に稼働時間が短いＶＭゲストを相対的に電力料金が高いクラウドに移動させる移動計画を生成して、各クラウド管理サーバ１０に移動計画を配信する。そして、各クラウド管理サーバ１０は、指定されたタイミングや任意のタイミングで、配信された移動計画を実行して、各ＶＭゲストを計画されたクラウドにマイグレーションする。この結果、マスタコントローラ３０は、広域クラウド全体でみた時の電力量の偏りを抑制することができ、広域クラウド全体の電力料金を削減することができる。

［機能構成］
次に、図２を用いて、各クラウド管理サーバ１０とマスタコントローラ３０のそれぞれの機能構成について説明する。図２は、実施例１にかかるシステムの機能構成を示す機能ブロック図である。なお、各狭域クラウドの各クラウド管理サーバは、同様の構成を有するので、ここでは、クラウド管理サーバ１０として説明する。

（クラウド管理サーバ１０の機能構成）
図２に示すように、クラウド管理サーバ１０は、通信部１１と記憶部１２と制御部２０とを有する。

通信部１１は、他のクラウド管理サーバ１０、各ＶＭゲスト、マスタコントローラ３０との間の通信を確立して、各種データ等を送受信する処理部である。例えば、通信部１１は、各ＶＭゲストから、ＶＭゲストそれぞれが使用するプロセッサやメモリなどの資源情報を受信し、マスタコントローラ３０から、各種要求や移動計画などを受信する。また、通信部１１は、各ＶＭゲストにマイグレーション指示を送信し、マスタコントローラ３０に各ＶＭゲストの資源情報などの各種情報を送信する。

記憶部１２は、制御部２０が実行するプログラムやデータなどを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、電力契約情報ＤＢ１３、電力使用状況ＤＢ１４、レイテンシＤＢ１５、ＶＭリソース管理ＤＢ１６、ＤＣリソース管理ＤＢ１７を記憶する。なお、各ＤＢが記憶する情報は、マスタコントローラ３０に集約されるので、詳細な説明はマスタコントローラ３０の機能構成で説明する。

電力契約情報ＤＢ１３は、クラウド管理サーバ１０が管理下におき、クラウドサービスを提供するデータセンタが契約する電気料金に関する情報を記憶するデータベースである。例えば、電力契約情報ＤＢ１３は、電力会社名、１ｋＷｈあたりの料金（従量）、夜間料金や夏季料金などの特別料金などを記憶する。

電力使用状況ＤＢ１４は、クラウド管理サーバ１０が管理する各データセンタで使用される電力量を記憶するデータベースである。例えば、電力使用状況ＤＢ１４は、一日の総電力量、夜間の電力量、昼間の電力量、ピーク時の電力量などを記憶する。また、電力使用状況ＤＢ１４は、各日ごとの電力量や各月ごとの電力量などを記憶することもできる。

レイテンシＤＢ１５は、各狭域クラウド間のレイテンシを記憶するデータベースである。具体的には、レイテンシＤＢ１５は、クラウド管理サーバ１０が管理するデータセンタ（ＤＣ００１とＤＣ００２）のそれぞれについて、各国の各データセンタとの間のレイテンシを記憶する。また、レイテンシＤＢ１５は、クラウド管理サーバ１０が管理する各データセンタが契約する帯域などのネットワーク情報を記憶することもできる。

ＶＭリソース管理ＤＢ１６は、クラウド管理サーバ１０が管理する各データセンタで動作する各ＶＭゲストに関する情報を記憶する。例えば、ＶＭリソース管理ＤＢ１６は、データセンタごとに、起動しているＶＭゲストを管理する。また、ＶＭリソース管理ＤＢ１６は、ＶＭゲストごとに、生存時間、稼働時間、使用プロセッサ情報（ｖＣＰＵ（Ｈｚ））、使用プロセッサ数（ｖＣＰＵ（個））、使用メモリ容量（メモリ（ＧＢ））などのリソース情報を記憶する。

ＤＣリソース管理ＤＢ１７は、クラウド管理サーバ１０が管理する各データセンタのリソース情報を記憶するデータベースである。例えば、ＤＣリソース管理ＤＢ１７は、各データセンタについて、各ＶＭゲストに割当て可能な全リソース量および全リソース量のうち実際に使用されているリソース量などを記憶する。

制御部２０は、クラウド管理サーバ１０全体を司る処理部であり、例えばプロセッサなどである。この制御部２０は、電力情報収集部２１、レイテンシ測定部２２、稼働情報収集部２３、移動実行部２４を有する。なお、電力情報収集部２１、レイテンシ測定部２２、稼働情報収集部２３、移動実行部２４は、プロセッサなどの電子回路の一例やプロセッサが実行するプロセスの一例などである。

電力情報収集部２１は、マスタコントローラ３０からの指示を受信した場合や定期的なタイミングで、クラウド管理サーバ１０が管理する各データセンタについて、契約している電力の料金情報や使用した電力料金等に関する情報を収集する処理部である。

例えば、電力情報収集部２１は、契約している電力料金に関する情報を管理者等から受け付けて電力契約情報ＤＢ１３に格納する。また、電力情報収集部２１は、各データセンタから時間単位の使用電力量を収集し、収集した使用電力量にしたがって、電力使用状況ＤＢ１４の各情報を生成して格納する。また、電力情報収集部２１は、マスタコントローラからの要求に応じて、電力契約情報ＤＢ１３に記憶される情報や電力使用状況ＤＢ１４に記憶される情報を、マスタコントローラ３０に送信する。

レイテンシ測定部２２は、クラウド管理サーバ１０が管理する各データセンタと、他のデータセンタとの間のレイテンシを測定する処理部である。例えば、レイテンシ測定部２２は、データセンタ（ＤＣ００１）と他のデータセンタ間のレイテンシを一般的な公知の手法で測定し、レイテンシＤＢ１５に格納する。また、レイテンシ測定部２２は、マスタコントローラ３０からの要求に応じて、レイテンシＤＢ１５に記憶される情報を、マスタコントローラ３０に送信する。

稼働情報収集部２３は、管理下のクラウドで動作するＶＭに関する情報を収集する処理部である。例えば、稼働情報収集部２３は、定期的に、データセンタＤＣ００１で動作するＶＭゲストについて、割り当てられた仮想プロセッサのスペックを示す「ｖＣＰＵ（Ｈｚ）」、割り当てられた仮想プロセッサの数を示す「ｖＣＰＵ（個）」、割り当てられた仮想メモリの容量を示す「メモリ（ＧＢ）」を収集して、ＶＭリソース管理ＤＢ１６に格納する。さらに、稼働情報収集部２３は、各ＶＭについて、クラウドの配備された日付、配備されてからの累積である生存時間（分）、実際に動作している時間の累積である稼働時間（分）などを収集して、ＶＭリソース管理ＤＢ１６に格納する。また、稼働情報収集部２３は、マスタコントローラ３０からの要求に応じて、ＶＭリソース管理ＤＢ１６に記憶される情報を、マスタコントローラ３０に送信する。

さらに、稼働情報収集部２３は、管理下のデータセンタのリソースに関する情報を収集する。例えば、稼働情報収集部２３は、提供可能な全リソースの合計と、定期的に収集したＶＭゲストによって使用されている使用リソースとをＤＣリソース管理ＤＢ１７に格納する。また、稼働情報収集部２３は、全リソース合計から使用リソースを減算して、空きリソースを算出して、ＤＣリソース管理ＤＢ１７に格納する。また、稼働情報収集部２３は、マスタコントローラ３０からの要求に応じて、ＤＣリソース管理ＤＢ１７に記憶される情報を、マスタコントローラ３０に送信する。

（マスタコントローラ３０の機能構成）
図２に示すように、マスタコントローラ３０は、通信部３１と記憶部３２と制御部５０とを有する。

通信部３１は、各クラウド管理サーバ１０との間の通信を制御する処理部である。例えば、通信部３１は、各クラウド管理サーバ１０から、電力情報、ＶＭゲストの稼働情報、データセンタのリソース情報を受信する。また、通信部３１は、各クラウド管理サーバ１０に、各種要求、ＶＭゲストの移動計画や移動指示などを送信する。

記憶部３２は、制御部５０が実行するプログラムやデータなどを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。記憶部３２は、拠点情報ＤＢ３３、電力会社ＤＢ３４、電力使用実績ＤＢ３５、電力使用状況ＤＢ３６、ＶＭリソース管理ＤＢ３７、ＤＣリソース管理ＤＢ３８、環境負荷ＤＢ３９、電力需要予測ＤＢ４０、レイテンシＤＢ４１、帯域管理ＤＢ４２、移動計画ＤＢ４３を記憶する。

拠点情報ＤＢ３３は、クラウドを提供するデータセンタが設置されている拠点に関する情報を記憶するデータベースである。図３は、拠点情報ＤＢ３３に記憶される情報の例を示す図である。図３に示すように、拠点情報ＤＢ３３は、「拠点情報、契約電力会社情報、国情報」を対応付けて記憶する。なお、ここで記憶される情報は、クラウド管理サーバ１０から受信する電力契約情報等を用いて生成することもでき、予め管理者が設定することもできる。

ここで記憶される「拠点情報」は、データセンタの設置場所を示す情報であり、「拠点コード、拠点名」が設定される。「拠点コード」は、拠点を識別する識別子であり、「拠点名」は、拠点の名称である。「契約電力会社情報」は、拠点に電力を提供する電力会社の情報であり、「電力会社コード、契約電力（ｋＷ）」が設定される。「電力会社コード」は、電力会社を識別する識別子であり、「契約電力（ｋＷ）」は、拠点が契約する電力値である。「国情報」は、拠点すなわちデータセンタが設置される国を特定する情報であり、「地域、ＵＴＣ差」が設定される。「地域」は、国を特定する識別子であり、例えば日本の場合は「ＪＰ」、アメリカの場合は「ＵＳ」などが設定される。「ＵＴＣ差」は、世界協定時との時差を示す。

図３の場合、拠点コード「ＤＣ００１」の拠点名「北海道ＤＣ」は、ＵＴＣ時差が「９時間」である地域「日本（ＪＰ）」に設置され、この拠点名「北海道ＤＣ」は、電力会社コードが「Ｐ０５」の電力会社から「１５００ｋＷ／日」の電力契約を結んでいることを示す。

電力会社ＤＢ３４は、各データセンタに電力を供給する電力会社に関する情報を記憶する。ここで記憶される情報は、クラウド管理サーバ１０から受信する電力契約情報等を用いて生成することもでき、予め管理者が設定することもできる。図４は、電力会社ＤＢ３４に記憶される情報の例を示す図である。図４に示すように、電力会社ＤＢ３４は、「国コード、電力会社コード、電力会社名、基本料金単価（ｋＶ）、従量、季節料金」を対応付けて記憶する。なお、ここでは一例として単位は円、小数点以下２桁までを利用する。

ここで記憶される「国コード」は、国を識別する識別子であり、図３の「地域」と同様である。「電力会社コード」は、図３と同様であり、「電力会社名」は、電力会社の名称である。「基本料金単価」は、１ｋＶあたりの電力量の単価である。「従量」は、１ｋＷあたりの従量制の料金を示し、「ピーク時、昼間、夜間」に分けて設定される。「ピーク時」は、１３時から１６時までの電力料金であり、「昼間」は、８時から２２時までの電力料金であり、「夜間」は、２２時から８時までの電力料金である。なお、基本料金は、金料金単価×契約電力×力率（割引や割増）で算出され、ピーク時の設定がない場合は昼間と同じ料金を設定する。「季節料金」は、特別な期間のときだけに設定される特別料金であり、例えば「夏季料金」などの季節料金などである。この「夏季料金」は、開始から終了までの間は、従量に変えて、特別に設定された料金が使用される。

図４の１行目は、日本に設置された「Ｐ０１」の〇電力会社の基本料金単価が「１５２２．８０ｋＶ」であることを示す。また、この〇電力会社は、ピーク時は１ｋＷあたり「１６．８７円」、昼間時は１ｋＷあたり「１５．０９円」、夜間時は１ｋＷあたり「１１．８５円」の従量課金を行う。さらに、この〇電力会社は、「７月１日」から「９月３０日」までの間は、夏季料金として、時間帯に関係なく、１ｋＷあたり「１６．００円」の従量課金を行う。

電力使用実績ＤＢ３５は、各データセンタごとに一日の電力使用状況を記憶するデータベースである。ここで記憶される情報は、クラウド管理サーバ１０から受信する電力契約情報等を用いて生成することができる。図５は、電力使用実績ＤＢ３５に記憶される情報の例を示す図である。図５に示すように、電力使用実績ＤＢ３５は、「拠点コード、Ｔｏｄａｙ電力量（ｋＷ）、夜間（００〜０８）、昼間（０８〜１３）、ピーク時（１３〜１６）、昼間（１６〜２２）、夜間（２２〜２４）、余裕電力、契約電力」を対応付けて記憶する。

ここで記憶される「拠点コード」は、図３等と同様であり、「Ｔｏｄａｙ電力量」は、一日の総使用電力量である。「夜間（００〜０８）」は、０時から８時までに使用された電力量であり、「昼間（０８〜１３）」は、８時から１３時までに使用された電力量であり、「ピーク時（１３〜１６）」は、１３時から１６時までに使用された電力量であり、「昼間（１６〜２２）」は、１６時から２２時までに使用された電力量であり、「夜間（２２〜２４）」は、２２時から２４時までに使用された電力量である。「余裕電力」は、使用可能な電力であり、契約電力に到達するまでの残りの電力量である。「契約電力」は、一日で使用可能な電力量の上限値である。

図５の１行目では、拠点コード「ＤＣ００１」のデータセンタは、一日の電力量の契約が「１５００．００ｋＷｈ」で、一日の使用電力量が「１３７０．００ｋＷｈ」であり、「１３０．００ｋＷｈ」の余裕があることを示している。また、当該データセンタは、０時から８時までの間は「２００．００ｋＷｈ」を使用し、８時から１３時までの間は「１５０．００ｋＷｈ」を使用し、１３時から１６時までの間は「８００．００ｋＷｈ」を使用し、１６時から２２時までの間は「１８０．００ｋＷｈ」を使用し、２２時から２４時までの間は「４０．００ｋＷｈ」を使用したことが示される。なお、ここで記憶される情報は、数日の平均値でよく、各日のデータであってもよい。

電力使用状況ＤＢ３６は、各データセンタについて、一日の各時間における使用電力量を記憶する。ここで記憶される情報は、クラウド管理サーバ１０から受信する情報にしたがって生成することもでき、予め管理者が設定することもできる。図６は、電力使用状況ＤＢ３６に記憶される情報の例を示す図である。図６に示すように、電力使用状況ＤＢ３６は、「拠点コード、年月日、１時間おきの時間帯、電力量（ｋＷｈ）」を対応付けて記憶する。

ここで記憶される「拠点コード」は、図３と同様であり、「年月日」は、電力量データの日付である。「０から２３」は、一日を１時間おきにグループ化したものであり、「電力量」は、一日の総使用電力量である。図６の例では、拠点コード「ＤＣ００１」のデータセンタについて、「２０１５年８月１日」から「２０１５年８月１０日」の各日の各時間帯の使用電力量を示している。

ＶＭリソース管理ＤＢ３７は、各クラウドで動作する各ＶＭに関する情報を記憶するデータベースである。ここで記憶される情報は、クラウド管理サーバ１０から受信する情報にしたがって生成することができる。図７は、ＶＭリソース管理ＤＢ３７に記憶される情報の例を示す図である。図７に示すように、ＶＭリソース管理ＤＢ３７は、ＶＭゲスト毎のリソース管理表とＤＣ別のＶＭリソース集計表を記憶する。

ＶＭゲスト毎のリソース管理表は、「ＶＭゲスト名、配備日、生存時間、稼働時間、ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）」を対応付けて管理する。「ＶＭゲスト名」は、ＶＭゲストを識別する識別子であり、「配備日」は、ＶＭゲストがクラウドに配備された年月日である。「生存時間」は、ＶＭゲストが配備されてから現在までの累積時間であり、「稼働時間」は、ＶＭゲストが実際に稼働している累積時間である。「ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）」は、ＶＭゲストが使用するリソース情報であり、「ｖＣＰＵ（ＧＨｚ）」はＶＭゲストが使用する仮想プロセッサのスペックであり、「ｖＣＰＵ（個）」はＶＭゲストが使用する仮想プロセッサの数であり、「メモリ（ＧＢ）」はＶＭゲストが使用するメモリの容量である。

図７の例では、ＶＭゲスト名「ＶＭ００１」のＶＭが２０１５年６月１５日に、２ＧＨｚの仮想プロセッサ２個と１６ＧＢのメモリ容量を割与えられて、クラウドに配備され、配備されてから３７１５２０分が経過し、そのうち１２４３２０分稼働していることを示す。

ＤＣ別のＶＭリソース集計表は、「拠点コード、ＶＭゲスト名、生存時間、稼働時間、ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）」を対応付けて管理する。各項目は、上述したので詳細な説明は省略する。図７の場合、拠点コード「ＤＣ００１」のデータセンタにおいてＶＭ００１のＶＭゲストが動作していることを示す。

ＤＣリソース管理ＤＢ３８は、各データセンタのリソースに関する情報を記憶するデータベースである。ここで記憶される情報は、クラウド管理サーバ１０から受信する情報にしたがって生成することができる。図８は、ＤＣリソース管理ＤＢ３８に記憶される情報の例を示す図である。図８に示すように、ＤＣリソース管理ＤＢ３８は、ＤＣ毎のリソース集計表を記憶する。

ＤＣ毎のリソース集計表は、各データセンタ（ＤＣ）について、リソースの使用状況および他クラウドからの移入可能なリソース量を記憶する。具体的には、ＤＣ毎のリソース集計表は、「拠点コード、全リソース合計、空きリソース量、移動不可リソース量、移入可能なリソース量」を管理する。ここで記憶される「拠点コード」は、図３等と同様であり、「全リソース合計」は、ＤＣがＶＭゲストに提供可能なリソースの合計である。「空きリソース量」は、ＤＣ内で未使用のリソース量であり、「移動不可リソース量」は、他のクラウドへ移動することができないＶＭゲストが使用するリソース量である。「移入可能なリソース量」は、当該ＤＣが移動可能な（受け入れ可能な）リソース量である。なお、各リソース量は、ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）で表される。

環境負荷ＤＢ３９は、クラウドに存在する全ＶＭゲストに関し、生存時間、稼働時間、割当リソースについて集計した情報を記憶するデータベースである。図９は、環境負荷ＤＢ３９に記憶される情報の例を示す図である。図９に示すように環境負荷ＤＢ３９は、「リージョン名、ゾーン名、ＶＭゲスト名、配備日、生存時間、稼働時間、ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）、リソース負荷指標」を対応付けて記憶する。「リージョン名」は、国や都市などの地域を識別する識別子であり、「ゾーン名」は、地域等を考慮して複数のデータセンタをグループ化したものを識別する識別子であり、「リソース負荷指標」は、ＶＭのリソース負荷を示した情報であり、「ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ）」を乗算した指標である。なお、他の項目は、上述しているので説明を省略する。

図９の例では、ＶＭゲスト「ＶＭ００１」がリージョン「ＳＡ−１」のゾーン「ＳＡ−Ｎ１」のクラウドに「２０１５年６月１５日」に配備されたことを示す。また、このＶＭゲスト「ＶＭ００１」には、２ＧＨｚの仮想プロセッサ２個と１６ＧＢのメモリ容量を割与えられており、移動させるのにかかる負荷が「６４」である。また、このＶＭゲスト「ＶＭ００１」は、クラウドに配備されてから３７１５２０分が経過し、そのうち１２４３２０分稼働していることを示す。

電力需要予測ＤＢ４０は、データセンタ内の時間帯ごとの電力の需要予測と移入可能な電力量を記憶するデータベースである。ここで記憶される情報は、クラウド管理サーバ１０から受信する情報にしたがって格納および生成することができる。図１０は、電力需要予測ＤＢ４０に記憶される情報の例を示す図である。図１０に示すように、電力需要予測ＤＢ４０は、「拠点コード、予測電力量（ｋＷｈ）、夜間（００〜０８）、昼間（０８〜１３）、ピーク時（１３〜１６）、昼間（１６〜２２）、夜間（２２〜２４）、余裕電力、契約電力、移入可能電力量」を対応付けて記憶する。

ここで記憶される拠点コードは、図３等と同様である。夜間（００〜０８）は、０時から８時の間で必要になると予測される電力量であり、例えばデータセンタ（ＤＣ００１）で動作する各ＶＭが０時から８時の間で利用する電力量の合計値以上が設定される。同様に、昼間（０８〜１３）は、８時から１３時の間で必要になると予測される電力量であり、ピーク時（１３〜１６）は、１３時から１６時の間で必要になると予測される電力量であり、昼間（１６〜２２）は、１６時から２２時の間で必要になると予測される電力量であり、夜間（２２〜２４）は、２２時から２４時の間で必要になると予測される電力量である。予測電力量は、夜間（００〜０８）、昼間（０８〜１３）、ピーク時（１３〜１６）、昼間（１６〜２２）、夜間（２２〜２４）を合計した電力量である。契約電力量は、データセンタが契約する電力量の上限値である。余裕電力量は、契約電力量から予測電力量を減算した電力量である。移入可能電力量は、余裕電力量やピーク時の電力量等を用いて制御部５０によって算出された、データセンタが受け入れ可能な電力量である。

図１０の１行目は、拠点コード「ＤＣ００１」のデータセンタについての電力需要予測であり、夜間（００〜０８）に２００ｋＷｈ、昼間（０８〜１３）に１５０ｋＷｈ、ピーク時（１３〜１６）に８００ｋＷｈ、昼間（１６〜２２）に１８０ｋＷｈ、夜間（２２〜２４）に４０ｋＷｈであり、一日の合計電力量が１３７０ｋＷｈであると予測されることを示す。また、拠点コード「ＤＣ００１」のデータセンタは、契約電力量が１５００ｋＷｈであり、余裕電力量が１３０ｋＷｈであり、移入可能電力量として１３０ｋＷｈが算出されたことを示す。

レイテンシＤＢ４１は、データセンタごとに、データセンタ間のレイテンシを記憶するデータベースである。ここで記憶される情報は、例えば各データセンタのクラウド管理サーバ１０が、他のクラウドのデータセンタに存在するクラウド管理サーバ１０に対して測定したレイテンシや各データセンタ内の特定のサーバ間で測定したレイテンシなどである。

図１１は、レイテンシＤＢ４１に記憶される情報の例を示す図である。図１１に示すように、レイテンシＤＢ４１は、「拠点コード、Ｄｅｓｔｉｎａｔｉｏｎ、レイテンシ測定結果、順位」を対応付けて記憶する。「拠点コード」は、図３と同様であり、「Ｄｅｓｔｉｎａｔｉｏｎ」は、レイテンシの測定先を特定する情報である。「レイテンシ測定結果」は、「ｍｉｄｎｉｇｈｔ（００〜０８）、ｍｏｒｎｉｎｎｇ（０８〜１２）、ａｆｔｅｒｎｏｏｎ（１２〜１７）、ｅｖｅｎｉｎｇ（１７〜２２）、ｍｉｄｎｉｇｈｔ（２２〜２４）、ＵＴＣ差」を対応付けて管理する。

「ｍｉｄｎｉｇｈｔ（００〜０８）」は、０時から８時の間で測定されたレイテンシであり、「ｍｏｒｎｉｎｎｇ（０８〜１２）」は、８時から１２時の間で測定されたレイテンシであり、「ａｆｔｅｒｎｏｏｎ（１２〜１７）」は、１２時から１７時の間で測定されたレイテンシであり、「ｅｖｅｎｉｎｇ（１７〜２２）」は、１７時から２２時の間で測定されたレイテンシであり、「ｍｉｄｎｉｇｈｔ（２２〜２４）」は、２２時から２４時の間で測定されたレイテンシであり、「ＵＴＣ差」は、図３と同様である。「順位」は、レイテンシに基づいて移動先として推奨される順位であり、レイテンシが小さいほど上位となる。

図１１の例は、「ＤＣ００１」と他の各ＤＣとのレイテンシの測定結果を示している。図１１の例は、「ＤＣ００１」と「ＤＣ００１」から「ＤＣ００６」の各レイテンシにしたがって、「ＤＣ００５」、「ＤＣ００６」、「ＤＣ００２」、「ＤＣ００４」、「ＤＣ００１」、「ＤＣ００３」の順で移動先を決定することを示す。また、「ＤＣ００１」と「ＤＣ００５」との間では、「ｍｉｄｎｉｇｈｔ（００〜０８）、ｍｏｒｎｉｎｎｇ（０８〜１２）、ａｆｔｅｒｎｏｏｎ（１２〜１７）、ｅｖｅｎｉｎｇ（１７〜２２）、ｍｉｄｎｉｇｈｔ（２２〜２４）」のそれぞれにおけるレイテンシが「１ｍｓｅｃ」であり、ＵＴＣ差が「−１時間」であることを示す。なお、レイテンシが同じ場合は、ＵＴＣ差が小さいＤＣを優先する。

帯域管理ＤＢ４２は、各データセンタが契約するネットワークに関する情報を記憶するデータベースである。ここで記憶される情報は、クラウド管理サーバ１０から受信する情報にしたがって生成することもでき、予め管理者が設定することもできる。

図１２は、帯域管理ＤＢ４２に記憶される情報の例を示す図である。図１２に示すように、帯域管理ＤＢ４２は、「拠点コード、帯域諸元（契約帯域（Ｇｂｐｓ）、使用帯域（Ｇｂｐｓ）、最大使用帯域（Ｇｂｐｓ））を対応付けて記憶する。「拠点コード」は、図３と同様である。「契約帯域」は、データセンタが契約する帯域幅を示し、「使用帯域」は、データセンタが実際に使用する帯域幅を示し、「最大使用帯域」は、過去に使用した最大の帯域幅を示す。図１２の例では、拠点コード「ＤＣ００１」のデータセンタは、１００Ｇｂｐｓの帯域を契約し、一般的には７０Ｇｂｐｓを使用しているが、最大で９０Ｇｂｐｓを使用したことがあることを示す。

移動計画ＤＢ４３は、後述する制御部５０によって生成されたＶＭゲストの移動計画を記憶するデータベースである。図１３は、移動計画ＤＢ４３に記憶される情報の例を示す図である。図１３に示すように、移動計画ＤＢ４３は、「移動対象ＶＭ、移動先ＤＣ、移動予定日時」を対応付けて記憶する。

「移動対象ＶＭ」は、移動対象のＶＭゲストを特定する情報であり、「リージョン名、ゾーン名、拠点コード、ＶＭゲスト名」で特定される。「移動先ＤＣ」は、移動的のデータセンタを特定する情報であり、「リージョン名、ゾーン名、拠点コード」で特定される。「移動予定日時」は、ＶＭの移動実行予定を示す情報である。図１３の例では、２０１６年８月１５日、リージョン名「ＳＡ−１」のゾーン名「ＳＡ−Ｎ１」の拠点コード「ＤＣ００１」のクラウドで動作する「ＶＭ００１」を、リージョン名「ＮＡ−Ｎ１」のゾーン名「ＮＡ−Ｗ１」の拠点コード「ＤＣＮ０１」のクラウド（データセンタ）に移動させることが計画されていることを示す。

制御部５０は、マスタコントローラ３０全体を司る処理部であり、例えばプロセッサなどである。この制御部５０は、収集部５１、電力計画部５２、管理部５３、配備部５４、移動計画部５５、計画実行部５６を有する。なお、収集部５１、電力計画部５２、管理部５３、配備部５４、移動計画部５５、計画実行部５６は、プロセッサなどの電子回路の一例やプロセッサが実行するプロセスの一例などである。

収集部５１は、クラウド全体の電力状況を取得する処理部である。具体的には、収集部５１は、定期的に、狭域クラウドを形成する各データセンタから、契約電力、電力の使用実績、日ごとの電力使用状況などを取得する。例えば、収集部５１は、月に１回、各クラウド管理サーバ１０から契約電力会社の情報を取得して、拠点情報ＤＢ３３に格納する。同様に、収集部５１は、定期的に、各国の電力会社から、電力料金や従量や季節料金などを取得して、電力会社ＤＢ３４に格納する。

また、収集部５１は、１時間ごとに、各データセンタから電力の使用状況を取得して、１時間ごとの電力状況を記憶する電力使用状況ＤＢ３６に格納する。そして、収集部５１は、１日の電力使用状況が収集されると、データセンタごとの１日の電力使用状況を生成して、電力使用実績ＤＢ３５に格納する。

電力計画部５２は、各データセンタの電力の使用状況から、電力需要予測を実行する処理部である。具体的には、電力計画部５２は、各クラウドの現在の電力需要と過去の履歴を定期的に取得し、ピーク時間帯に、各クラウドで契約電力を超えない、かつ目標削減量を満足するように、クラウド間での電力需要を計画する。ここでは、順位付けと電力需要計画について説明する。

（順位付け）
例えば、電力計画部５２は、拠点情報ＤＢ３３を参照して、各データセンタが利用する電力会社を特定し、特定した電力会社の電力料金を、電力会社ＤＢ３４を参照して特定する。続いて、電力計画部５２は、各データセンタについて、特定した電力料金と電力使用状況ＤＢ３６に記憶される１日の電力使用量とを用いて、１日の電力料金を算出する。例えば、電力計画部５２は、基本料金と従量課金とを算出し、これらの合計値を電力料金として算出する。なお、基本料金は、基本料金単価×契約電力×力率で算出される。従量課金は、各時間帯の電力使用量に、各時間帯に設定される料金単価を乗算して算出される。このとき、電力計画部５２は、夏季料金に該当する場合は、従量課金に夏季料金を用いることもできる。

そして、電力計画部５２は、算出した各データセンタの一日の電力料金（基本料金＋従量課金）の安い順に順位付けを行い、安い順で、電力使用実績ＤＢ３５に記憶される情報を並び替える。なお、この手法に限定されず、電力計画部５２は、各データセンタの基本料金の安い順に並び替えてもよい。

（電力需要計画）
例えば、電力計画部５２は、各データセンタの電力需要について、現状の電力量と過去の電力量より、ピーク時を考慮した今後の需要予測を行う。具体的には、電力計画部５２は、電力計画部５２によって生成された電力使用実績ＤＢ３５に記憶される各データセンタについて、使用電力量が契約電力量に到達するまでの残りの電力量（余裕電力量）を算出する。まず、電力計画部５２は、夜間、昼間、ピーク時のそれぞれを合計して一日の使用電力量（Ｔｏｄａｙ電力量）を算出し、契約電力からＴｏｄａｙ電力量を減算して余裕電力量を算出して、電力使用実績ＤＢ３５に格納する。

続いて、電力計画部５２は、各データセンタについて、受け入れ可能な電力量である移入可能電力量を算出する。例えば、電力計画部５２は、契約電力からＴｏｄａｙ電力量を減算して、移入可能電力量を算出する。なお、データセンタには、非常時や緊急時のサーバ起動等に備えて、予め所定の電力量（確保電力量）を確保することもある。したがって、電力計画部５２は、そのようなデータセンタについては、契約電力からＴｏｄａｙ電力量および確保電力量を減算して移入可能電力量を算出することもできる。

そして、電力計画部５２は、各データセンタについて、電力使用実績ＤＢ３５に記憶される「Ｔｏｄａｙ電力量」を「予測電力量」として抽出するとともに、電力使用実績ＤＢ３５に記憶される「夜間（００〜０８）、昼間（０８〜１３）、ピーク時（１３〜１６）、昼間（１６−２２）、夜間（２２〜２４）、契約電力」、算出した「移入可能電力量」を対応付けて、電力需要予測ＤＢ４０に格納する。このようにすることで、各データセンタの電力需要が予測でき、各データセンタが移入可能な電力量が特定される。

図２に戻り、管理部５３は、各クラウドで動作するＶＭの情報、各クラウドを提供するデータセンタのリソース情報、各データセンタが利用するネットワーク情報、各データセンタ間のレイテンシなどを定期的に収集して管理する処理部である。

（ＶＭリソース）
例えば、管理部５３は、各クラウド管理サーバ１０から、クラウド上で動作するＶＭゲストが使用するリソース情報（ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ））と生存時間と稼働時間とクラウドへの配備日を取得する。そして、管理部５３は、取得したこれらの情報を、ＶＭリソース管理ＤＢ３７のＶＭ毎のＶＭリソース集計表に格納する。また、管理部５３は、取得したこれらの情報と、クラウド管理サーバ１０が管理するデータセンタの拠点コードとを対応付けて、ＶＭリソース管理ＤＢ３７のＤＣ別のＶＭリソース集計表に格納する。

（環境負荷情報）
管理部５３は、各ＶＭゲストについて、リソース情報の各項目（ｖＣＰＵ（ＧＨｚ）、ｖＣＰＵ（個）、メモリ（ＧＢ））を乗算して、リソース負荷指標を算出する。また、管理部５３は、各クラウド管理サーバ１０から、各ＶＭゲストが動作するリージョン名およびゾーン名を取得する。そして、管理部５３は、リージョン名、ゾーン名、ＶＭゲスト名、配備日、ＶＭゲストのリソース情報、生存時間、稼働時間、リソース負荷指標を対応付けて、環境負荷ＤＢ３９に格納する。

（ＤＣリソース）
管理部５３は、各クラウド管理サーバ１０から、データセンタの全リソースの合計、移動不可リソース量を取得する。また、管理部５３は、各データセンタについて、全リソースの合計から、移動不可リソース量とＶＭゲストのリソース量とを除いた空きリソース量を算出する。なお、一般的には、この空きリソース量を、データセンタへ移行可能なリソース量である移入可能なリソース量とすることができるが、データセンタには、非常時や緊急時のＶＭゲスト起動等に備えて、予め所定のリソース量（確保リソース量）を確保する必要があることもある。したがって、管理部５３は、そのようなデータセンタについては、全リソースの合計から、移動不可リソース量とＶＭゲストのリソース量に加えてさらに確保リソース量を減算して空きリソース量を算出することもできる。そして、管理部５３は、クラウド管理サーバ１０が管理するデータセンタの拠点コードと、空きリソース量と移動不可リソース量と移入可能なリソース量とを対応付けて、ＤＣリソース管理ＤＢ３８に格納する。

（帯域）
管理部５３は、各クラウド管理サーバ１０から、各データセンタ（拠点）の帯域諸元を取得する。そして、管理部５３は、拠点コードと帯域諸元とを対応付けて、帯域管理ＤＢ４２に格納する。

（レイテンシ）
管理部５３は、各クラウド管理サーバ１０から、各クラウド管理サーバ１０が管理する各データセンタ（拠点）と他のデータセンタとの間のレイテンシ測定結果を取得する。ここで取得されるレイテンシ測定結果は、予め指定されたｍｉｄｎｉｇｈｔなどの各時間帯で測定された測定結果であり、測定元と測定先のＵＴＣ差を含む。そして、管理部５３は、測定元のデータセンタごとに、測定先のデータセンタを示す「Ｄｅｓｔｉｎａｔｉｏｎ」とレイテンシ測定結果とを対応付けて、レイテンシＤＢ４１に格納する。また、管理部５３は、レイテンシＤＢ４１において、データセンタ間のレイテンシが小さい順に、順位付けを行う。なお、順位付けは、レイテンシ測定結果の平均値を比較する。

図２に戻り、配備部５４は、クラウド管理サーバ１０から、新規ＶＭゲストの配備要求を受け付けた場合に、配備先を決定してクラウド管理サーバ１０に通知する処理部である。具体的には、配備部５４は、各クラウドについて、現在の電力需要と過去の履歴を定期的にチェックし、ピーク時間帯に、各クラウドで契約電力を超えない、かつ目標削減量を満足するように、新規ＶＭを配備する。

例えば、配備部５４は、クラウド管理サーバ１０から、起動対象のＶＭゲストのリソース情報、稼働時間帯と稼働時間を含む配備要求を受信する。すると、配備部５４は、ｖＣＰＵやメモリに対して予め設定されている単位時間当たりの電力量を用いて、配備対象のＶＭゲストの予想電力量を算出する。そして、配備部５４は、電力需要予測ＤＢ４０に記憶されるデータセンタ（拠点コード）を上から参照して、ピーク時の電力が閾値未満で、配備対象のＶＭゲストの予想電力量以上の移入可能電力量を有するとともに起動対象のＶＭゲストのリソース量を確保できるデータセンタを、配備先に指定する応答をクラウド管理サーバ１０に送信する。クラウド管理サーバ１０は、この応答で特定されるデータセンタに、ＶＭゲストの配備指示を送信する。

このとき、配備部５４は、レイテンシを考慮することもできる。例えば、配備部５４は、配備要求を送信したクラウド管理サーバ１０が管理するデータセンタとの間のレイテンシが所定値以下のデータセンタを配備先対象として絞り込む。そして、配備部５４は、絞り込んだデータセンタのうち、配備対象のＶＭゲストの予想電力量以上の移入可能電力量を有するデータセンタを、配備先に指定することもできる。

そして、配備部５４は、クラウド管理サーバ１０によるＶＭゲストの配備が行われると、各クラウド管理サーバ１０にリソース情報等の収集を要求し、収集部５１や管理部５３に収集指示を送信する。この結果、収集部５１や管理部５３は、クラウド管理サーバ１０から各種情報を収集して、各種ＤＢを更新する。

また、配備部５４は、配備要求を送信したクラウド管理サーバ１０の管理下にあるデータセンタに優先的に配備することもできる。このとき、配備部５４は、新規ＶＭゲストを当該データセンタに配備することで、予想電力量が超える場合に、上記手法を用いて配備先のクラウドを決定することもできる。

図１４は、ＶＭゲストの配備時の制御を説明する図である。図１４では、リージョンＡのクラウドＡのデータセンタからＶＭゲストの配備要求が送信された例で説明する。図１４の左図に示すように、マスタコントローラ３０は、新規配備時はリージョンＡのクラウドＡの電力実績に余裕があるが、過去の実績を参照することで、新たなＶＭゲストが起動すると、数時間後に目標電力を超えると判定する。これに対して、図１４の右図に示すように、マスタコントローラ３０は、リージョンＢのクラウドＢについては、過去の実績を参照すると、新たなＶＭゲストが起動した後も目標電力を超えないと判定する。このような場合、配備部５４は、クラウド管理サーバ１０に、新規配備の要求元であるリージョンＡのクラウドＡではなく、リージョンＢのクラウドＢに配備先を変更する指示を送信する。なお、目標電力とは、データセンタに設定された使用電力の上限値であり、契約電力と同じであってもよい。

移動計画部５５は、各クラウドの料金情報と各ＶＭの生存時間とに基づいて、各ＶＭの移行計画を生成する処理部である。具体的には、移動計画部５５は、定期的に、各ＤＢを参照して、生存時間が相対的に長いＶＭを電力料金が相対的に高いクラウドに移行し、生存時間が相対的に短いＶＭを電力料金が相対的に安いクラウドに移行する移行計画を生成する。

より詳細には、移動計画部５５は、電力コストが高いクラウドＡから電力コストが安いクラウドＢへの移動を判断する際に、対象のＶＭゲストＸとＶＭゲストＹについて、以下の比較を行う。（１）ＶＭゲストＸより生存時間が短く、その資源量が小さいＶＭゲスＹ、（２）ＶＭゲストＸより生存時間が短く、その資源量が大きいＶＭゲストＹ、（３）ＶＭゲストＸより生存時間が長く、その資源量が小さいＶＭゲストＹ、（４）ＶＭゲストＸより生存時間が長く、その資源量が大きいＶＭゲストＹ。ここで、ＶＭゲストＸよりもＶＭゲストＹの方が生存時間が短いとき、ＶＭゲストＹの環境負荷が低いと判断され、ＶＭゲストＸよりもＶＭゲストＹの方が資源量が小さいときは、ＶＭゲストＹの環境負荷が低いと判断される。クラウドでは頻繁にＶＭゲストの作成や削除が行われるので、生存時間が短いものは削除される可能性が高いと判断する。つまり、長く存在し資源量が大きいもの程、コストが安いクラウドへ動かす効果があると判断する。

図１５は、定期的なＶＭゲストの移動計画を説明する図である。図１５では、リージョンＡのクラウドＡのデータセンタの電力料金（基本料金）の方がリージョンＢのクラウドＢのデータセンタの電力料金（基本料金）よりも安いとする。図１５の左図に示すように、クラウドＡでは、移動計画の作成や見直し時間（ｔ）になった時点で、ＶＭゲストの契約が解放等されることでリソースが解放されており、使用電力量も減少している。一方で、図１５の右図に示すように、クラウドＢでは、移動計画の作成や見直し時間（ｔ）になった時点でも、ＶＭゲストが動作し続けており、使用電力量も高いままである。このような場合、マスタコントローラ３０は、電力料金が高いクラウドＢで動作するＶＭゲストを、電力料金が安いクラウドＡへ移動する計画を生成する。

移動計画としては、ＶＭゲスト１つずつを検討する手法も考えられるが、ここではグループ化する例を説明する。まず、移動計画部５５は、電力使用実績ＤＢ３５の契約電力と電力会社ＤＢ３４の基本料金単価や従量などを参照して、各データセンタについての電力コストである基本料金を算出する。そして、移動計画部５５は、基本料金が安い順に各データセンタをソートする。

次に、移動計画部５５は、環境負荷ＤＢ３９を参照して、広域クラウド上で動作中の各ＶＭゲストの生存時間、リソース情報、リソース負荷指標を取得する。そして、移動計画部５５は、生存時間とリソース負荷指標とを用いて、各ＶＭゲストをデータセンタ数のグループに分類する。例えば、移動計画部５５は、生存時間が第１の閾値以上かつリソース負荷指標が第２の閾値以上のＶＭゲストを第１グループ、生存時間が第１の閾値以上かつリソース負荷指標が第２の閾値未満のＶＭゲストを第２グループ、生存時間が第１の閾値未満かつリソース負荷指標が第２の閾値以上のＶＭゲストを第３グループなどにように、上記（１）から（４）を考慮して、「生存時間×リソース負荷指標」が大きい順に分類する。なお、グループ数は任意であり、データセンタが８か所の場合は８グループになるように閾値等を調整して分類してもよく、データセンタの数よりも少ないグループに分類してもよい。

ここでグループ分けの一例を説明する。移動計画部５５は、グループ１に割当てられるデータセンタ（ＤＣ００１）の移入可能なリソース量をＤＣリソース管理ＤＢ３８から抽出する。続いて、移動計画部５５は、「生存時間×リソース負荷指標」が大きい順にＶＭゲストを選択してグループ１に分類する。このときに、移動計画部５５は、選択したＶＭゲストのリソース情報を環境負荷ＤＢ３９から取得し、データセンタ（ＤＣ００１）の移入可能なリソース量以下に収まる範囲で、ＶＭゲストを選択してグループ１に分類する。続いて、移動計画部５５は、未選択のＶＭゲストのうち、「生存時間×リソース負荷指標」が大きい順にＶＭゲストを選択して、同様の手法でグループ２を生成する。

なお、グループ分けに際してレイテンシを考慮することもできる。例えば、移動計画部５５は、ＶＭゲスト（ＶＭ００５）をグループ１に分類してデータセンタ（ＤＣ００１）に移動すると決定するときに、ＶＭゲスト（ＶＭ００５）が動作しているデータセンタと移動先となるデータセンタ（ＤＣ００１）とのレイテンシを、レイテンシＤＢ４１から取得する。そして、移動計画部５５は、レイテンシが閾値以上であれば、ＶＭゲスト（ＶＭ００５）をグループ１に分類することを抑制し、グループ２への分類を検討する。このときも、レイテンシを考慮して分類が決定される。

このように、移動計画部５５は、生存時間が長く負荷も高いグループ１から順に、電力料金が安いデータセンタへ割当てる。例えば、移動計画部５５は、グループ１を電力料金が最も安いデータセンタ（ＤＣ００１）に割当て、グループ２を電力料金が次に安いデータセンタ（ＤＣ００２）に割当てる。そして、移動計画部５５は、各ＶＭについて移動計画を生成して、移動計画ＤＢ４３に格納する。なお、移動予定日時等は、稼働中サービスへの影響が小さいように、広域クラウド全体で最も通信量が少ない日時などが選択される。

計画実行部５６は、移動計画ＤＢ４３に格納される移動計画を実行する処理部である。例えば、計画実行部５６は、移動計画ＤＢ４３に記憶される移動計画を監視し、移動予定日時になった計画を検出した場合、当該計画を実行する。具体的には、計画実行部５６は、移動対象のＶＭが動作するデータセンタ（拠点コード）を管理するクラウド管理サーバ１０に該当ＶＭのマイグレーションを指示する。なお、マイグレーションは、ライブマイグレーションであっても、コールドマイグレーションであってもよく、クラウド管理サーバ１０が状態に応じて適切に選択して実行する。

図１６は、電力料金を考慮したＶＭゲストの移動計画を説明する図である。ここでは、１クラウドにつき１データセンタであり、クラウド（データセンタ）が６つあり、ＶＭゲストを次の基準で４つのグループに分けて移動させる計画を実行した例を説明する。ここでは、グループ（４）：生存時間が閾値以上かつリソース負荷指標が閾値以上、グループ（３）：生存時間が閾値以上かつリソース負荷指標が閾値未満、グループ（２）：生存時間が閾値未満かつリソース負荷指標が閾値以上、グループ（１）：生存時間が閾値未満かつリソース負荷指標が閾値未満とする。また、データセンタＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの順に電力料金が安いとする。なお、図１６では、移動できないリソースを「固」と表記し、空きリソースを「空」と表記する。

このような状態で、移動計画部５５によって、各データセンタで動作する各ＶＭゲストが上記（１）から（４）に分類される（図１６の上図）。その後、（４）のＶＭゲストがデータセンタＡのクラウドＡに集約し、（３）のＶＭゲストがデータセンタＢのクラウドＢに集約し、（２）のＶＭゲストがデータセンタＣのクラウドＣに集約し、（１）のＶＭゲストがデータセンタＤのクラウドＤに集約するように、移動計画が生成される。そして、計画実行部５６が移動計画を実行することにより、データセンタＡから順に、生存時間が長く負荷も高いＶＭゲストが集約される（図１６の下図）。なお、図１６において、例えばデータセンタＡに（４）以外のＶＭゲストが動作しているのは、例えば移動に伴ってレイテンシが顧客のＳＬＡ（Service Level Agreement）を満たさなくなることを理由に、移動できなかったＶＭゲストなどが存在するからである。

［処理の流れ］
次に、図１に示したシステムで実行される処理について説明する。ここでは、全体的な処理の流れと、マスタコントローラ３０が実行する電力需要計画処理および配備・移動計画処理について説明する。

（全体的な処理の流れ）
図１７は、全体的な処理の流れを示すシーケンス図である。図１７に示すように、マスタコントローラ３０は、電力状況の収集要求を各クラウド管理サーバ１０に送信する（Ｓ１０１とＳ１０２）。各クラウド管理サーバ１０は、管理するデータセンタの電力状況を収集してマスタコントローラ３０に送信する（Ｓ１０３とＳ１０４）。

続いて、マスタコントローラ３０は、各データセンタについて、電力需要計画処理を実行する（Ｓ１０５）。具体的には、マスタコントローラ３０は、各データセンタの電力料金を算出し（Ｓ１０６）、電力料金が安い順にデータセンタの順位付けを行い（Ｓ１０７）、電力需要計画を生成する（Ｓ１０８）。

その後、マスタコントローラ３０は、配備・移動計画処理を実行する（Ｓ１０９）。具体的には、マスタコントローラ３０は、データセンタ毎のリソースを収集する（Ｓ１１０からＳ１１３）。例えば、マスタコントローラ３０が、各クラウド管理サーバ１０に要求を送信し、各クラウド管理サーバ１０が、管理下にあるデータセンタのリソース情報や当該データセンタで動作するＶＭゲストの稼働情報を収集して、マスタコントローラ３０に送信する。

続いて、マスタコントローラ３０は、データセンタ毎のレイテンシと帯域を収集する（Ｓ１１４からＳ１１７）。例えば、マスタコントローラ３０が、各クラウド管理サーバ１０に要求を送信し、各クラウド管理サーバ１０が、管理下にあるデータセンタと他のデータセンタとのレイテンシを測定し、測定結果とデータセンタが契約する帯域諸元とをマスタコントローラ３０に送信する。

その後、マスタコントローラ３０は、環境負荷情報を収集して（Ｓ１１８）、移動計画を生成し（Ｓ１１９）、計画した移動計画を実行する（Ｓ１２０とＳ１２１）。これに伴って、クラウド管理サーバ１０は、ＶＭゲストの移動を実行する（Ｓ１２２）。

（配備・移動計画処理の流れ）
図１８は、配備・移動計画処理の流れを示すフローチャートである。図１８に示すように、電力計画部５２は、データセンタ毎のリソース空き容量を算出し（Ｓ２０１）、データセンタ毎の移入可能なリソース量を算出する（Ｓ２０２）。続いて、電力計画部５２は、電力使用実績ＤＢ３５に記憶される各データセンタを、電力料金の安い順に並び替える（Ｓ２０３）。

また、電力計画部５２は、管理部５３によって取得されたレイテンシと帯域に関する情報を取得し（Ｓ２０４）、クラウド間すなわちデータセンタ間のレイテンシを比較する（Ｓ２０５）。そして、電力計画部５２は、各クラウドについて移動先の優先順位を決定する（Ｓ２０６）。

その後、配備部５４は、新規ＶＭゲストの配備要求を受信した場合（Ｓ２０７：Ｙｅｓ）、新規ＶＭゲストのリソースを該当クラウド管理サーバ１０から取得し（Ｓ２０８）、新規ＶＭゲストの予想電力量を推測する（Ｓ２０９）。

そして、配備部５４は、新規ＶＭゲストのリソース量以上を確保できる移入可能なデータセンタのうち、最も電力料金が安いデータセンタを選択する（Ｓ２１０）。続いて、配備部５４は、選択した結果にしたがって、クラウド管理サーバ１０に配備指示を送信する（Ｓ２１１）。その後、管理部５３、収集部５１などは、リソースや稼働情報などの各種情報を再収集してＤＢを更新する（Ｓ２１２）。

その後、定期時間に到達すると（Ｓ２１３：Ｙｅｓ）、移動計画処理が実行される（Ｓ２１４）。一方、定期時間に到達しない場合は（Ｓ２１３：Ｎｏ）、Ｓ２０７以降を実行する。なお、新規配備要求を待っている間に、定期時間に到達した場合は、移動計画処理が実行される。また、Ｓ２０７において、配備部５４は、新規ＶＭゲストの配備要求を受信していない場合（Ｓ２０７：Ｎｏ）Ｓ２１３を実行する。

（移動計画処理の流れ）
図１９は、移動計画処理の流れを示すフローチャートである。図１９に示すように、移動計画部５５は、ＶＭゲストごとに、生存時間とリソース量を抽出し（Ｓ３０１）、各クラウド（データセンタ）を電力料金でグループ化する（Ｓ３０２）。例えば、同じ電力料金のデータセンタは同じグループに分類する。

そして、移動計画部５５は、グループ数に応じて、生存時間の閾値とリソース量の閾値を決定し（Ｓ３０３）、各ＶＭゲストを生存時間とリソース量でグループ化する（Ｓ３０４）。

続いて、移動計画部５５は、生存時間が長くリソース量も多いＶＭゲストが電力料金の安いデータセンタに移動するように移動計画を生成する（Ｓ３０５）。その後、計画実行部５６は、移動計画を実行する（Ｓ３０６）。

［効果］
上述したように、マスタコントローラ３０は、世界に点在するデータセンタ（クラウド）毎の電力料金や電力量、ＶＭゲストの情報を集約して管理することで、全クラウドにおける電力料金の削減を行うとともに、最適なＶＭ配備や移動を行うことで、稼働率に偏りのないクラウドの運用を行うことができる。

マスタコントローラ３０は、過去の電力需要と現在の状況から、ピークを予測し契約電力を超えないように、クラウド間で稼働するサーバ数を制御し、かつサーバ上のＶＭゲストを移動させることができる。また、マスタコントローラ３０は、クラウド間のＶＭゲストの移動に際して、生存時間やネットワークレスポンス（レイテンシ）を定期的に測定し移動計画に反映することで、最安クラウドへの集中を回避し、移動に伴う利用者への影響を削減することができる。

このように、マスタコントローラ３０は、世界に点在するクラウドで使用する電力量とクラウドの利用状況をコントロールすることで、クラウド全体での電力需要の削減と最適化を実現することができる。さらに、クラウド事業者は電力の削減によるシステム維持費が削減できる。この結果、システム維持費の削減を利用者の利用料金へ反映（安価にできる）することにより他事業者との競争を有利にすることが可能となる。

ところで、実施例１では、負荷の高いＶＭゲストを電力料金の安いデータセンタ（クラウド）に集約させる例を説明したが、これに限定されるものではなく、集約後に、再配置を実行することもできる。

例えば、実施例１による移動を行った後に、電力料金の安いクラウドが混雑し、また、電力料金が高いクラウドが閑散となる状態が発生すると、クラウドを有効活用できない。そこで、実施例２では、実稼働時間を計測し、１日当たりの稼働率の分布から、稼働時間の少ないＶＭゲストを定期的に抽出し、電力料金が高いクラウドへ移動を行う。つまり、稼働率が低い、言い換えると電力消費が少ないＶＭゲストを、電力料金が高いクラウドへ移動し、稼働率が高い、言い換えると電力消費が多いＶＭゲストを、電力料金が安いクラウドへ移動する。

図２０は、再配置計画を説明する図である。図２０に示す図は、図１６で説明した移動計画実施後のクラウドＡに対応する。図２０に示すように、移動計画部５５は、クラウドＡで動作する「（４）の生存時間が閾値以上かつリソース負荷指標が閾値以上」に該当する各ＶＭゲストの生存時間と稼働時間とを、ＶＭリソース管理ＤＢ３７から抽出する。そして、移動計画部５５は、各ＶＭゲストについて、稼働率（＝（稼働時間／生存時間）×１００）を算出する。そして、移動計画部５５は、（４）に該当するＶＭゲストのうち稼働率が５０％未満のＶＭゲストを、電力料金が高いクラウドＦに移動させる。なお、稼働率の閾値は任意に設定変更することができる。

移動計画部５５は、実施例１で説明した移動計画を実行してから所定時間経過後、図２０に示す再配置を各クラウドについて実行する。図２１は、再配置前後の具体例を説明する図である。図２１の上図は、図１６で説明した移動計画実施後の図である（図１６の下図）。図２１に示すように、移動計画部５５は、移動実施後、ＶＭゲストを集約させたクラウドＡ〜Ｄの各ＶＭゲストの稼働率を算出し、稼働率が５０％未満のＶＭゲストを抽出する。そして、移動計画部５５は、クラウドＡ〜Ｄにおいて稼働率が５０％未満のＶＭゲストを、電力料金が高いクラウドＥかクラウドＦに移動させる。なお、クラウドＥかＦかは任意に選択することができる。

具体的には、移動計画部５５は、クラウドＡにおいて、（４）に該当するＶＭゲストのうち稼働率が５０％未満のＶＭゲストを、クラウドＦに移動させる。移動計画部５５は、クラウドＢにおいて、（３）に該当するＶＭゲストのうち稼働率が５０％未満のＶＭゲストを、クラウドＥに移動させる。移動計画部５５は、クラウドＣにおいて、（２）に該当するＶＭゲストのうち稼働率が５０％未満のＶＭゲストを、クラウドＥに移動させる。移動計画部５５は、クラウドＤにおいて、（１）に該当するＶＭゲストのうち稼働率が５０％未満のＶＭゲストを、クラウドＦに移動させる。

このようにすることで、電力料金の安いクラウドの稼働率はより高く、かつ電力料金が高いクラウドも有効に活用することができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

（初動配備）
上記実施例１では、マスタコントローラ３０は、新規のＶＭゲストの配備を電力料金が安いクラウドに配備する例を説明したが、これに限定されるものではない。例えば、マスタコントローラ３０は、最安のクラウドに十分な空きがない場合は、配備要求元のクラウド管理サーバ１０が管理するクラウドに配備する。

図２２は、初動配備の制御例を説明する図である。図２２に示すように、マスタコントローラ３０は、電力料金が最高のクラウドＦを管理するクラウド管理サーバ１０から新規ＶＭゲストの配備要求を受信すると、電力料金が最安のクラウドＡの移入可能なリソース量を取得する。そして、マスタコントローラ３０は、最安のクラウドＡの移入可能なリソース量閾値未満の場合、クラウドＦに配備することをクラウド管理サーバ１０に通知する。このようにすることで、最安のクラウドのパフォーマンスの劣化を抑制することができる。

（電力料金）
上記実施例では、夏季料金などの季節料金を用いる例を説明したが、これに限定されるものではなく、季節なども考慮することができる。例えば、マスタコントローラ３０は、全世界の季節を考慮し、料金が安い季節の国のデータセンタに、稼働率の高いＶＭゲストなどを集約させることもできる。

また、マスタコントローラ３０は、広域クラウドを形成する狭域クラウドをリージョン単位で管理して、ＶＭゲストの移動等を行うこともできる。例えば、マスタコントローラ３０は、日本にある複数のクラウドを一括して管理し、日本が夏で電力料金が高い場合は、日本が夏の間だけ、その時期に冬である他のクラウドに、日本のクラウドで動作する各ＶＭゲストのうち上記（４）等に該当するＶＭゲストを移動させることもできる。

また、マスタコントローラ３０は、日本が昼間で電力料金が高い場合は、日本が昼間の間だけ、その時期に夜である他のクラウドに、日本のクラウドで動作する各ＶＭゲストのうち上記（４）等に該当するＶＭゲストを移動させることもできる。このようにすることで、クラウド全体の料金を安くすることができるので、クラウドの普及やＶＭゲストを使用するユーザの集客が期待できる。なお、移動先を決定するときは、ＶＭゲストごとに、輸出規制などを考慮して、輸出できない国や地域等には移動しないように制御することもできる。

（稼働情報）
上記実施例１では、ＶＭゲストの生存時間を利用したが、これに限定されるものではなく、例えばＶＭゲストが稼働していることを示す情報であればどのような情報であってもよく、例えば稼働時間を採用することもできる。また、各実施例では、生存時間と資源情報（リソース情報）とを用いる例を説明したが、生存時間だけを用いて処理することもできる。例えば、生存時間が相対的に長いＶＭゲストを電力料金の安いクラウドに移動させることもできる。

（ハードウェア）
マスタコントローラ３０と各クラウド管理サーバ１０は、同様のハードウェア構成を有するので、ここでは、マスタコントローラ３０について説明する。図２３は、マスタコントローラ３０のハードウェア構成例を示す図である。図２３に示すように、マスタコントローラ３０は、通信インタフェース３００ａ、ＨＤＤ（Hard Disk Drive）３００ｂ、メモリ３００ｃ、ＣＰＵ（Central Processing Unit）などのプロセッサ３００ｄを有する。また、図２３に示した各部は、バス等で相互に接続される。

通信インタフェース３００ａは、ネットワークインタフェースカードなどである。ＨＤＤ３００ｂは、図２に示した機能を動作させるプログラムやテーブルを記憶する。

プロセッサ３００ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ３００ｂ等から読み出してメモリ３００ｃに展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、マスタコントローラ３００が有する各処理部と同様の機能を実行する。具体的には、プロセッサ３００ｄは、収集部５１、電力計画部５２、管理部５３、配備部５４、移動計画部５５、計画実行部５６等と同様の機能を有するプログラムをＨＤＤ３００ｂ等から読み出す。そして、プロセッサ３００ｄは、収集部５１、電力計画部５２、管理部５３、配備部５４、移動計画部５５、計画実行部５６等と同様の処理を実行するプロセスを実行する。

このようにマスタコントローラ３０は、プログラムを読み出して実行することでクラウド管理方法を実行する情報処理装置として動作する。また、マスタコントローラ３０は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、マスタコントローラ３０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

１０ クラウド管理サーバ
１１ 通信部
１２ 記憶部
１３ 電力契約情報ＤＢ
１４ 電力使用状況ＤＢ
１５ レイテンシＤＢ
１６ ＶＭリソース管理ＤＢ
１７ ＤＣリソース管理ＤＢ
２０ 制御部
２１ 電力情報収集部
２２ レイテンシ測定部
２３ 稼働情報収集部
２４ 移動実行部
３０ マスタコントローラ
３１ 通信部
３２ 記憶部
３３ 拠点情報ＤＢ
３４ 電力会社ＤＢ
３５ 電力使用実績ＤＢ
３６ 電力使用状況ＤＢ
３７ ＶＭリソース管理ＤＢ
３８ ＤＣリソース管理ＤＢ
３９ 環境負荷ＤＢ
４０ 電力需要予測ＤＢ
４１ レイテンシＤＢ
４２ 帯域管理ＤＢ
４３ 移動計画ＤＢ
５０ 制御部
５１ 収集部
５２ 電力計画部
５３ 管理部
５４ 配備部
５５ 移動計画部
５６ 計画実行部

Claims (9)

1. 異なる地域に設置された各データセンタの電力需要と前記各データセンタ間のレイテンシに基づき、前記レイテンシが閾値以下である複数のデータセンタが前記電力需要のピーク時に契約電力を越えない制約のもと、各仮想マシンを前記各データセンタに配備する配備部と、
   前記各仮想マシンの配備後、前記各データセンタが提供する各クラウドサービスに関し、前記各クラウドサービスで仮想マシンを利用する際の電力に関する料金情報を収集する収集部と、
   前記各クラウドサービスで動作する各仮想マシンに関し、前記各仮想マシンの稼働情報を取得する取得部と、
   前記各クラウドサービスの料金情報と前記各仮想マシンの稼働状況とに基づいて、前記各仮想マシンの移動計画を生成する生成部と
   を有することを特徴とする情報処理装置。
2. 前記取得部は、前記各仮想マシンの稼働情報として、前記各仮想マシンが前記クラウドサービス上に配備されてからの時間の累積である生存時間を取得し、
   前記生成部は、前記各仮想マシンの前記生存時間を比較し、前記生存時間が相対的に長い仮想マシンを電力料金が相対的に安いクラウドサービスに移動し、前記生存時間が相対的に短い仮想マシンを電力料金が相対的に高いクラウドサービスに移動する前記移動計画を生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記取得部は、前記各仮想マシンが使用する資源に関する資源情報をさらに取得し、
   前記生成部は、前記生存時間が相対的に長くかつ使用する前記資源が相対的に多い仮想マシンを前記電力料金が相対的に安いクラウドサービスに移動し、前記生存時間が相対的に短くかつ使用する前記資源が想定的に少ない仮想マシンを前記電力料金が相対的に高いクラウドサービスに移動する前記移動計画を生成することを特徴とする請求項２に記載の情報処理装置。
4. 前記生成部は、前記電力の料金が高い季節または時間帯のクラウドサービスを利用する仮想マシンのうち、前記生存時間が相対的に長くかつ使用する前記資源が相対的に多い仮想マシンを、前記季節または前記時間帯の間、前記電力の料金が安い季節のクラウドサービスへ移動する前記移動計画を生成することを特徴とする請求項３に記載の情報処理装置。
5. 前記移動計画が実行された後、所定時間経過後に、前記各仮想マシンの稼働率を算出する算出部と、
   前記電力料金が相対的に安いクラウドサービスに移動した複数の前記仮想マシンのうち、前記稼働率が所定値未満の仮想マシンを、前記電力料金が相対的に高いクラウドサービスに移動する再移動部と、をさらに有することを特徴とする請求項２に記載の情報処理装置。
6. 前記電力料金が相対的に高いクラウドサービスにおいて新規の仮想マシンの配備要求が発生した場合、前記電力料金が相対的に安いクラウドサービスへの配備指示を抑制し、他のクラウドサービスへの配備を指示する配備指示部をさらに有することを特徴とする請求項２に記載の情報処理装置。
7. コンピュータが、
   異なる地域に設置された各データセンタの電力需要と前記各データセンタ間のレイテンシに基づき、前記レイテンシが閾値以下である複数のデータセンタが前記電力需要のピーク時に契約電力を越えない制約のもと、各仮想マシンを前記各データセンタに配備し、
   前記各仮想マシンの配備後、前記各データセンタが提供する各クラウドサービスに関し、前記各クラウドサービスで仮想マシンを利用する際の電力に関する料金情報を収集し、
   前記各クラウドサービスで動作する各仮想マシンに関し、前記各仮想マシンの稼働情報を取得し、
   前記各クラウドサービスの料金情報と前記各仮想マシンの稼働状況とに基づいて、前記各仮想マシンの移動計画を生成する
   処理を実行することを特徴とする情報処理方法。
8. コンピュータに、
   異なる地域に設置された各データセンタの電力需要と前記各データセンタ間のレイテンシに基づき、前記レイテンシが閾値以下である複数のデータセンタが前記電力需要のピーク時に契約電力を越えない制約のもと、各仮想マシンを前記各データセンタに配備し、
   前記各仮想マシンの配備後、前記各データセンタが提供する各クラウドサービスに関し、前記各クラウドサービスで仮想マシンを利用する際の電力に関する料金情報を収集し、
   前記各クラウドサービスで動作する各仮想マシンに関し、前記各仮想マシンの稼働情報を取得し、
   前記各クラウドサービスの料金情報と前記各仮想マシンの稼働状況とに基づいて、前記各仮想マシンの移動計画を生成する
   処理を実行させることを特徴とする情報処理プログラム。
9. 複数の管理サーバと統合サーバとを有する情報処理システムにおいて、
   前記複数の管理サーバそれぞれは、
   異なる地域に設置された各データセンタの電力需要と前記各データセンタ間のレイテンシに基づき、前記レイテンシが閾値以下である複数のデータセンタが前記電力需要のピーク時に契約電力を越えない制約のもと、各仮想マシンが配備された前記各データセンタのうち、管理対象の地域に設置されたデータセンタが提供するクラウドサービスに関し、前記クラウドサービスで仮想マシンを利用する際の電力に関する料金情報を前記統合サーバに送信する第１送信部と、
   前記クラウドサービスで動作する各仮想マシンに関し、前記各仮想マシンの稼働情報を前記統合サーバに送信する第２送信部と、を有し、
   前記統合サーバは、
   前記複数の管理サーバそれぞれから、各クラウドサービスに関する前記料金情報と各仮想マシンに関する前記稼働情報を受信する受信部と、
   前記各クラウドサービスの料金情報と前記各仮想マシンの稼働状況とに基づいて、前記各仮想マシンの移動計画を生成する生成部と
   を有することを特徴とする情報処理システム。

Images