JPWO2013145004A1 - 情報処理装置、情報処理方法および情報処理システム - Google Patents

Abstract

【課題】クラウドコンピューティングのアーキテクチャを高い柔軟性で利用することができる情報処理装置、情報処理方法および情報処理システムを提供すること。【解決手段】情報処理装置は、複数の構成要素のそれぞれの運用費用の情報を記憶するとともに、複数の異なる要求元からそれぞれ受信した、前記複数の構成要素の一部又は全部を含む資源の要求情報を記憶する記憶部と、処理部と、を有し、前記処理部は、前記記憶部に記憶された資源の要求情報によって要求された各資源に含まれる割合が所定の基準を超える１又は複数の構成要素を含む資源情報を生成し、前記記憶部を参照して、前記１又は複数の構成要素のそれぞれに対応する運用費用に基づいて、生成した該資源情報についての運用費用の情報を算出し、前記複数の異なる要求元の少なくとも１つの要求元に対して、生成した前記資源情報と、算出した前記運用費用の情報とを提供する、処理を実行する。

Description

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

クラウドコンピューティングは、インターネット等のネットワークを介してユーザがサービスを受ける利用形態であり、近年において普及が進められている。クラウドコンピューティングは、多数のテナント（ユーザ）が大規模なデータセンタなどに設置されたサーバを利用するものである。この利用方法によれば、スケールメリットが生まれるため、データセンタのインフラの利用単価の低減を図ることができる。また、テナントにとっては、サーバの運用管理を、サービスを提供するプロバイダ（サービス提供業者）にアウトソーシングすることができるため、運用管理コストの低減を図ることもできる。

図１は、クラウドコンピューティングを実現するためのマルチテナントアーキテクチャの種類の一例を示す図である。図１（ａ）は、IaaS（Infrastructure as a Service）ベースの仮想化ネイティブPaaS（Platform as a Service）と呼ばれるマルチテナントアーキテクチャである。図１（ａ）に示すように、仮想化ネイティブPaaSは、ハードウェア、仮想マシン、ＯＳ（Operating System）、ＤＢ（Database）、アプリケーションソフトウェア（以降、アプリと呼称する）等の構成要素による階層構造を有している。仮想化ネイティブPaaSでは、ハードウェアインフラのみをテナント間で共用しており、仮想マシン，ＯＳ，ＤＢおよびアプリは、テナント毎に個別のものが用いられている。仮想化ネイティブPaaSの形態によれば、各テナントは、仮想マシン、ＯＳ，ＤＢおよびアプリを自由に選択し、組み合わせることができる。

図１（ｂ）は、マルチテナントネイティブPaaSと呼ばれるマルチテナントアーキテクチャである。図１（ｂ）に示すように、マルチテナントネイティブPaaSのアーキテクチャは、ハードウェア、ＯＳ、ＤＢ、アプリ等の構成要素による階層構造を有している。マルチテナントネイティブPaaSでは、ハードウェアだけでなく、ＯＳ，ＤＢおよびアプリもテナント間で共用されており、本インフラによって実行されるビジネスプロセスだけがテナント毎に異なっている。マルチテナントネイティブPaaSの形態によれば、アプリおよびＤＢをテナント間で共用できるため、インフラの集約効率が高く、運用管理作業の効率を高めることができる。

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

Junichi Niino、「Paasが進化する方向と、仮想化を使わないクラウド」、[online]、[平成２４年３月７日検索]、インターネット＜ＵＲＬ：http://www. publickey1.jp/blog/11/paas_1.html＞

仮想化ネイティブPaaSでは、仮想マシン、ＯＳ、ＤＢおよびアプリがテナント毎に異なるため、実際の運用ではテナント毎に個別に処理を実行させることとなる。このため、アーキテクチャとしては冗長で非効率であり、データセンタのサーバを必ずしも有効に活用できていないという問題がある。さらに、仮想化ネイティブPaaSのプロバイダは、無数の構成要素の組み合わせの管理を行うこととなるため、サーバの運用管理作業が複雑であり、テナントあたりの運用費用（ランニングコスト）も高くなる問題がある。

一方、マルチテナントネイティブPaaSでは、前述のように、ＯＳ、ＤＢおよびミドルウェアを複数のテナントが共用することとなる。このため、各々のテナントが自由にＯＳ、ＤＢおよびアプリの種類を選択することはできず、アーキテクチャを選択する上での柔軟性が低いという問題がある。

１つの側面では、本発明は、クラウドコンピューティングのアーキテクチャを高い柔軟性で利用することができる情報処理装置、情報処理方法および情報処理システムを提供することを目的とする。

発明の一観点によれば、複数の構成要素のそれぞれの運用費用の情報を記憶するとともに、複数の異なる要求元からそれぞれ受信した、前記複数の構成要素の一部又は全部を含む資源の要求情報を記憶する記憶部と、処理部と、を有し、前記処理部は、前記記憶部に記憶された資源の要求情報によって要求された各資源に含まれる割合が所定の基準を超える１又は複数の構成要素を含む資源情報を生成し、前記記憶部を参照して、前記１又は複数の構成要素のそれぞれに対応する運用費用に基づいて、生成した該資源情報についての運用費用の情報を算出し、前記複数の異なる要求元の少なくとも１つの要求元に対して、生成した前記資源情報と、算出した前記運用費用の情報を提供する、処理を実行する情報処理装置が提供される。

一実施態様によれば、クラウドコンピューティングのアーキテクチャを高い柔軟性で利用することができる情報処理装置、情報処理方法および情報処理システムを提供することができる。

図１は、クラウドコンピューティングを実現するためのマルチテナントアーキテクチャの種類の一例を示す図である。 図２は、本発明の実施形態におけるクラウドコンピューティングシステムの一例を示す図である。 図３は、本発明の実施形態における情報処理装置の動作を示すフローチャートである。 図４は、各テナントが利用を要求する資源の一例、およびメモリに格納された資源の情報のデータ構造の一例を示す図である。 図５は、類似度を算出する処理を示すフローチャートである。 図６は、資源の変更方法の種類と、変更の負荷を示す負荷レベルとの対応関係の一例を示す図である。 図７は、各テナントが利用を要求する資源を状態遷移図で表示した一例を示す図である。 図８は、テナントＴ_１が利用する資源とテナントＴ_２が利用する資源との間における距離を算出した一例である。 図９は、図４に示す各テナントが利用を要求する資源同士の類似度を算出した結果の一例を示す図である。 図１０は、共用化対象となるテナントの組み合わせを抽出した一例、および抽出した共用化対象となるテナントの組み合わせを状態遷移図で表示した一例を示す図である。 図１１は、類似資源を決定し、運用費用を算出する処理の一例を示すフローチャートである。 図１２は、類似資源を決定し、運用費用を算出する処理の変形例を示すフローチャートである。 図１３は、類似資源および類似資源の運用費用の情報を対象テナントに提示する一例を示す図である。 図１４は、本発明の実施形態における情報処理装置の動作の変形例を示すフローチャートである。 図１５は、共用化の実行前および実行後における資源の一例を示す図である。 図１６は、共用化の実行前および実行後における資源の構成要素の数および種類を、図１２に基づいて集計した結果を示す図である。 図１７は、本発明の実施形態によって実現可能なマルチテナントアーキテクチャの種類の一例を示す図である。 図１８は、本発明の実施形態によって実現可能なマルチテナントアーキテクチャの種類の別の一例を示す図である。 図１９は、サーバの資源間の距離の定義の別の例を示す図である。

以下、本発明の実施形態について、図１乃至図１９を参照して具体的に説明する。

図２は、本発明の実施形態における情報処理システムの一例を示す図である。図２に示すように、情報処理システムは、クラウドシステムインフラ１と、端末２と、情報処理装置３とを有している。クラウドシステムインフラ１と、端末２と、情報処理装置３とは、相互に通信可能に接続されている。

クラウドシステムインフラ１は、例えばデータセンタ内に備えられ、多数のテナントにサービスを提供するためのサーバ１ａ，１ｂ，１ｃおよび１ｄを有している。各テナントは、インターネット等のネットワークを介してクラウドシステムインフラ１から所望のサービスを受けることができる。サーバ１ａ〜１ｅの各々は、例えばＯＳまたはアプリ等といった複数のソフトウェアを構成要素として含む資源によって動作することができる。

クラウドシステムインフラ１は、管理端末４を有している。管理端末４は、サーバ１ａ〜１ｅと相互に通信可能に接続されており、情報処理装置３から受信した信号に基づいて、サーバ１ａ〜１ｅの各々に対してＯＳのアップグレードまたはソフトウェアのインストール等の処理を実行させることができる。

端末２は、クラウドシステムインフラ１を利用する各テナントが所有するユーザインターフェースである。各テナントはそれぞれ異なる端末を所有しており、図２には、５つのテナントがそれぞれ所有する端末２ａ，２ｂ，２ｃ，２ｄおよび２ｅが例示されている。端末２は、例えばパーソナルコンピュータ（ＰＣ：Personal Computer）または携帯電話等のモバイル型端末である。

以下、情報処理装置３の各部の機能について説明する。情報処理装置１は、メモリ５と、メモリ６と、プロセッサ７と、インターフェース（Ｉ／Ｆ）８と、インターフェース（Ｉ／Ｆ）９とを含む。

メモリ５は、記憶部の一例である。メモリ５は、プロセッサ７と電気的に接続されており、クラウドシステムインフラ１を利用する各テナントが要求する資源の情報である、要求情報を格納することができる。また、メモリ５は、資源の運用費用に関する情報を格納することもできる。メモリ５としては、例えばＲＡＭ（Random Access Memory）やフラッシュメモリなどの半導体メモリ、またはＨＤＤ（Hard Disk Drive）などを用いることができる。なお、メモリ５は複数有していても良い。

メモリ６は、プロセッサ７と電気的に接続されており、資源の共用化（集約）処理を実行するための情報処理プログラムを格納することができる。メモリ６としては、例えばＲＯＭ（Read Only Memory）およびフラッシュメモリなどの半導体メモリ、またはＨＤＤなどを用いることができる。なお、メモリ５は複数有していても良く、メモリ５およびメモリ６は、同一のメモリによって構成されていても良い。

プロセッサ７は、処理部の一例である。プロセッサ７は、メモリ５に格納された資源の情報と資源の運用費用の情報とに基づいて、情報処理プログラムを実行させることができる。プロセッサ７は、情報処理プログラムに従って、後述する資源情報を収集する処理と、類似度を算出する処理と、類似資源を決定する処理と、費用を算出する処理と、共用化を実行する処理とを実行する。プロセッサ７は、例えばＣＰＵ（Central Processing Unit）である。

インターフェース（Ｉ／Ｆ）８は、プロセッサ７とクラウドシステムインフラ１とを送受信可能に接続するための入出力インターフェースの機能を有している。インターフェース（Ｉ／Ｆ）８は、プロセッサ７から受信した信号に基づいて、クラウドシステムインフラ１の管理端末４に信号を送信し、あるいは管理端末４から受信した信号に基づいて、プロセッサ７に信号を送信することができる。

インターフェース（Ｉ／Ｆ）９は、プロセッサ７と各テナントの端末２ａ〜２ｅとを送受信可能に接続するための入出力インターフェースである。インターフェース（Ｉ／Ｆ）９は、プロセッサ７から受信した信号に基づいて、端末２ａ〜２ｅの内の宛先となる端末に信号を送信することができる。また、インターフェース（Ｉ／Ｆ）９は、端末２ａ〜２ｅから送信された信号を受信し、受信した信号に基づいてプロセッサ７に信号を送信することができる。

次に、本発明の実施形態における情報処理装置３の動作について説明する。

図３は、本発明の実施形態における情報処理装置の動作を示すフローチャートである。

プロセッサ７は、各テナントが利用を要求する資源の情報を取得し、取得した資源の情報をメモリ５に格納する（Ｓ１０１）。資源の情報は、例えばハードウェア、ＯＳ、ＤＢ、アプリ等の各構成要素の情報である。各テナントが利用を要求する資源の情報とは、新規のテナントがクラウドシステムインフラ１の利用を申請する際に選択した資源の情報だけでなく、クラウドシステムインフラ１の利用を開始している既存のテナントが採用している資源の情報も含んでいる。以降では、ＯＳおよびアプリの情報を資源の情報として取得した場合の動作例について説明する。

図４（ａ）は、各テナントが利用を要求する資源の一例を示す図である。図４（ｂ）は、メモリに格納された資源の情報のデータ構造の一例を示す図である。図４（ａ）に示す例では、クラウドシステムインフラ１を利用するテナントは、テナントＡ，Ｂ，Ｃ，Ｄ，ＥおよびＦである。

テナントＡは、ＯＳとしてOS-a 4.0、アプリとしてApp-a 2.0を含む資源と、ＯＳとしてOS-a 4.5、アプリとしてApp-a 2.4を含む資源と、ＯＳとしてOS-a 4.2、アプリとしてApp-b 4.1を含む資源とを有するサーバの利用を要求している。テナントＢは、ＯＳとしてOS-a 4.5、アプリとしてApp-a 2.4を含む資源と、ＯＳとしてOS-a 4.5、アプリとしてApp-b 4.1を含む資源とを有するサーバの利用を要求している。

テナントＣは、ＯＳとしてOS-c 1.0、アプリとしてApp-c 2.6の資源と、ＯＳとしてOS-a 4.5、アプリとしてApp-b 4.1を含む資源とを有するサーバの利用を要求している。テナントＤは、ＯＳとしてOS-b 3.0、アプリとしてApp-c 7.0を含む資源と、ＯＳとしてOS-b 1.0、アプリとしてApp-c 6.0を含む資源と、ＯＳとしてOS-b 2.0、アプリとしてApp-d 10を含む資源とを有するサーバの利用を要求している。

テナントＥは、ＯＳとしてOS-b 2.0、アプリとしてApp-c 7.0を含む資源と、ＯＳとしてOS-b 2.0、アプリとしてApp-b 5.0を含む資源とを有するサーバの利用を要求している。テナントＦは、ＯＳとしてOS-b 2.0、アプリとしてApp-c 7.0を含む資源と、ＯＳとしてOS-b 2.0、アプリとしてApp-b 4.0を含む資源とを有するサーバの利用を要求している。

なお、ＯＳおよびアプリの名称の右側に表記されている数字はソフトウェアのバージョン（版数）であり、同種のソフトウェア間では数字が大きいほど新しいバージョンであることを示している。また、テナントＡ，Ｂ，Ｃ，Ｄ，ＥおよびＦの資源は、上述の資源のみとは限らない。

図４（ｂ）は、図４（ａ）のアーキテクチャを元に、各テナントが利用を要求するサーバの資源、すなわちアプリとＯＳとの組み合わせを、テナント毎に列挙したものである。上述の資源の情報の取得方法としては、例えばクラウドシステムインフラ１を利用するテナントに要求して情報を受信する方法や、情報処理装置３が保持しているテナントとの契約情報から、資源の情報を検索して抽出する方法を用いることができる。あるいは、資源の情報を予めメモリ５に格納しておき、格納された情報の最終更新時からの経過時間が所定の時間を超えたテナントのみに対して最新情報を要求し、取得するようにすることもできる。この方法によれば、情報処理プログラムを実行させる際に全てのテナントから情報を取得する必要がないため、資源の情報の取得を効率的に行うことができ、処理時間の短縮を図ることができる。

資源の情報を取得するトリガとしては、例えば新規のテナントがクラウドシステムインフラ１の利用をプロバイダに申請するとき、またはテナント数が一定数を超え、共用化による費用効果が見込めるようになったときを挙げることができる。あるいは、テナント側の変化に関わらず一定または不定期のタイミングをトリガとすることもできる。あるいは、テナント側から利用するサーバの運用費用の削減要求を受けたときや、プロバイダ側においてクラウドシステムインフラ１の運用費用の削減の必要性が生じたときをトリガとすることもできる。

続いて、図３に戻り、プロセッサ７は、取得した資源の情報に基づいて、資源同士の類似度を算出する（Ｓ１０２）。ここで、図５および図６を参照して類似度の算出方法の一例について説明する。

図５は、類似度を算出する処理を示すフローチャートである。

まず、プロセッサ７は、各テナントが利用を要求する資源の情報をメモリ５から読み出す（Ｓ２０１）。

図６は、資源の変更作業の種類と、変更の負荷を示す負荷レベルとの対応関係（負荷レベル情報）の一例を示す図である。サーバの資源の変更方法としては、例えばアップグレード、パッチ適用、インストール、ダウングレード等を挙げることができる。ここで、アップグレードとは、ソフトウェアのバージョンをより新しいバージョンに更新（上書き）するための処理である。パッチ適用とは、パッチファイルと呼ばれる、変更点(差分情報)のみを抜き出して列挙したファイルを用いてプログラムの一部を修正することにより、小規模なバージョンアップを行うための処理である。インストールとは、ソフトウェアをコンピュータの中に新たに組み込んで使用可能な状態にすることである。ダウングレードとは、ソフトウェアのバージョンをより古いバージョンに更新するための処理である。

変更に要する費用や時間等の負荷は、資源の変更方法によって異なる。このため、図６では、資源の変更方法に対応する負荷レベルを資源の変更方法毎に数値で設定している。変更の負荷は、負荷レベルの値が大きいほどが大きく、例えば、ＯＳまたはアプリのアップグレードまたはパッチ適用よりも、アプリのインストールまたはダウングレードの方が変更の負荷が大きい。また、アプリのインストールまたはダウングレードよりも、ＯＳの入れ替え、ＯＳのダウングレードまたはＤＢの変更の方が変更の負荷が大きい。このように、変更の負荷の負荷レベルを数値化する方法によれば、サーバの資源をどのように変更すれば小さい負荷で変更できるのかを定量的に把握することができるため、共用化の効率化を図ることができる。本実施例では、変更の負荷を示す負荷レベルを「距離」と呼称する。図６に示す情報は、予めメモリ５またはメモリ６に登録されており、適宜追加または変更を行うことも可能である。

続いて、図５に戻り、プロセッサ７は、変更元の資源と変更先の資源との組み合わせ毎に距離を算出する（Ｓ２０２）。

図７は、各テナントが利用を要求する資源を状態遷移図で表示した一例を示す図である。図７は、図６に示す負荷レベル情報に基づいて、資源２１、２２，２３，２４、２５、２６および２７の各々を、他の異なる資源に変更する際の距離を算出した結果を示している。矢印の根元に配置されている資源は変更元の資源であり、矢印の先に配置されている資源は変更先の資源である。両矢印は、資源をどちらの方向に変更しても距離が同一であることを示している。なお、図７中のＵＰＧはアップグレード、ＤＮＧはダウングレードを示している。

ここで、資源２１から資源２２に変更する場合の距離の算出方法について説明する。

図７に示すように、資源２１は、ＯＳがOS-a 4.5、アプリがApp-a 2.4である。資源２２は、ＯＳがOS-a 4.5、アプリがApp-a 2.6である。ＯＳは、種類が変更元と変更先とで同一であることから、変更は不要である。よって、図６を参照するとアプリの変更に係る距離は０である。一方、アプリは、種類が同一であるが、資源２１のアプリのバージョンは2.4、資源２２のアプリのバージョンは2.6であり、バージョンが異なっている。アプリのバージョンは資源２１よりも資源２２の方が新しいことから、アプリの変更はアップグレードにより行われることとなる。よって、図６を参照すると、アプリのアップグレードに係る距離は１である。したがって、資源２１から資源２２に変更する場合の距離は、ＯＳに係る距離とアプリに係る距離の和によって求められ、０＋１＝１と算出される。

続いて、上述とは逆方向の変更、すなわち資源２２から資源２１に変更する場合の距離の算出方法について説明する。

ＯＳは、種類が変更元と変更先とで同一であることから、変更は不要である。よって、図６を参照すると、アプリの変更に係る距離は０である。一方、アプリは、種類が同一であるが、資源２２のアプリのバージョンは2.6、資源２１のアプリのバージョンは2.4であり、バージョンが異なっている。アプリのバージョンは資源２２よりも資源２１の方が古いことから、アプリの変更はダウングレードにより行われる。よって、図６を参照するとアプリのダウングレードに係る距離は２である。したがって、資源２２から資源２１に変更する場合の距離は、ＯＳに係る距離とアプリに係る距離の和によって求められ、０＋２＝２と算出される。このように、距離を比較すると、資源２２を資源２１に変更するよりも、資源２１を資源２２に変更する方が、変更の負荷は小さくなっており、資源の変更の方向によって距離が異なる場合があることがわかる。

次に、別の例として、資源２３から資源２４に変更する場合の距離の算出方法について説明する。資源２３は、ＯＳがOS-a 4.0、アプリがApp-a 2.4である。資源２４は、ＯＳがOS-a 4.5、アプリはインストールされていない。ＯＳは、種類が変更元と変更先とで同一であることから、変更は不要である。よって、図６を参照すると、アプリの変更に係る距離は０である。一方アプリは、変更先のアプリがインストールされていないため、アプリの変更はアンインストールにより行われることとなる。よって、図６を参照すると、アプリの変更に係る距離は２である。したがって、資源２３から資源２４に変更する場合の距離は、ＯＳに係る距離とアプリに係る距離の和によって求められ、０＋２＝２と算出される。

続いて、逆方向の変更、すなわち資源２４から資源２３に変更する場合の距離の算出方法について説明する。ＯＳは、種類が変更元と変更先とで同一であることから、変更は不要である。よって、図６を参照すると、アプリの変更に係る距離は０である。一方、アプリは、変更元のアプリがインストールされていないため、アプリの変更はインストールにより行われることとなる。よって、図６を参照すると、アプリの変更に係る距離は２である。したがって、資源２４から資源２３に変更する場合の距離は、ＯＳに係る距離とアプリに係る距離の和によって求められ、０＋２＝２と算出される。このように、本例では資源の変更の方向によらず距離は同じであり、資源をどちらに変更しても負荷は実質的に変わらない場合があることがわかる。

本発明の実施形態によれば、資源の変更方法の種類に応じた変更の負荷を示す数値を設定し、変更元サーバに含まれる資源と変更先サーバとに含まれる資源との組み合わせ毎に数値を割り当て、割り当てた数値を合計する。この方法によれば、２つの構成要件間で、どちらを変更元とし、どちらを変更先とすれば共用化の負荷が小さくなるのかを定量的に把握することができる。

続いて、図５に戻り、プロセッサ７は、テナントが利用を要求する資源同士の類似度を算出する（Ｓ２０３）。各テナントが利用する資源同士の類似度は、式（１）により算出することができる。
式（１）；

ここで、Ｄｉｓ（Ｔ_ｍ，Ｔ_ｎ）は、テナントＴ_ｍからＴ_ｎまでの距離であり、Ｔ_ｍが利用する資源をＴ_ｎが利用する資源に変更することを前提とした場合の、資源間の類似度を示している。Ｃ（Ｔ_ｍ，ｉ）は、テナントＴ_ｍのｉ番目の資源（アプリおよびＯＳ）である。Ｄ（Ｃ（Ｔ_ｍ，ｉ），Ｃ（Ｔ_ｎ，ｊ））は、資源Ｃ（Ｔ_ｍ，ｉ）から資源Ｃ（Ｔ_ｎ，ｊ）までの距離であり、資源Ｃ（Ｔ_ｍ，ｉ）から資源Ｃ（Ｔ_ｎ，ｊ）に変更することを前提とした場合の、資源間の類似度を示している。

図８は、テナントＴ_１が利用する資源とテナントＴ_２が利用する資源との間における距離を算出した一例である。図８に示すように、テナントＴ_１が利用する資源は、２つの資源３１，３２を備えている。テナントＴ_２が利用する資源は、３つの資源３３，３４，３５を備えている。図８に示す矢印は、一方のテナントの中の各資源から最も距離の短い、他方のテナントの資源を指しており、括弧の中の数字は変更の負荷を示す数値である。

テナントＴ_１からテナントＴ_２に変更する場合の距離は、例えば以下のように求めることができる。まず、テナントＴ_１の資源３１，３２をそれぞれテナントＴ_２の資源のいずれかに変更する場合、資源３１，３２からの距離が最も小さい資源を資源３３，３４，３５の中から検索する。図８に示すように、資源３１との距離が最も短いのは資源３３（距離；０）であり、資源３２との距離が最も短いのは資源３５（距離；２）である。よって、テナントＴ_１からテナントＴ_２に変更する場合における双方の類似度Ｄ_ｄｉｓ（Ｔ_１，Ｔ_２）は、式（１）を参照すると２つの距離の和によって求められ、Ｄ_ｄｉｓ（Ｔ_１，Ｔ_２）＝０＋２＝２と算出される。

テナントＴ_２からテナントＴ_１に変更する場合の距離は、例えば以下のように求めることができる。テナントＴ_２の資源３３，３４，３５をそれぞれテナントＴ_１の資源のいずれかに変更する場合、資源３３，３４，３５からの距離が最も小さい資源を資源３１，３２の中から検索する。図８に示すように、資源３３との距離が最も短いのは資源３１（距離；０）であり、資源３４との距離が最も短いのは資源３１（距離；２）であり、資源３５との距離が最も短いのは資源３２（距離；６）である。よって、テナントＴ_２からテナントＴ_１に変更する場合における双方の類似度Ｄ_ｄｉｓ（Ｔ_２，Ｔ_１）は、式（１）を参照すると３つの距離の和によって求められ、Ｄ_ｄｉｓ（Ｔ_２，Ｔ_１）＝０＋２＋４＝６と算出される。

図９は、図４に示すテナントＡ，Ｂ，Ｃ，Ｄ，ＥおよびＦが要求する資源同士の類似度を算出した結果の一例を示す図である。縦軸は変更元の資源を利用するテナント、横軸は変更先の資源を利用するテナントを示しており、類似度を示す数値が小さいほど類似度は高く、変更に要する負荷はより小さい。変更元と変更先とが同一である場合は変更作業が発生しないため、「−」と表示している。図９によれば、変更元の資源を利用するテナントがＣ、変更先の資源を利用するテナントがＥである場合、図９を参照すると類似度は１２であることがわかる。

Ｓ２０３の処理が終了すると、図３に戻り、プロセッサ７は、算出した類似度に基づいて、共用化に係るテナントである対象テナントを決定する（Ｓ１０３）。

Ｓ１０３において、プロセッサ７は類似度の閾値を設定する。そして、図９に示す情報から、設定した閾値未満の類似度を有するテナントの組み合わせを抽出する。図１０は共用化対象となるテナントの組み合わせを抽出した一例を示す図である。本実施例では、類似度の閾値を１０と設定し、図１０（ａ）に示すように、閾値が１０未満の、集約元の資源の利用を要求するテナントと、集約先の資源の利用を要求するテナントとの組み合わせが抽出される。丸で囲んだ数値が、閾値が１０未満の数値を示している。これにより、共用化の対象となる対象テナントとして、テナントＡ，Ｂ，Ｃ，ＥおよびＦが決定される。

続いて、図３に戻り、類似資源を決定し、運用費用を算出する（Ｓ１０４）。

類似資源は、複数のテナントによって共用される対象となり得る、共用化候補の資源である。類似資源は、例えば複数のテナントが既に利用している既存の資源の一部を含むものである。類似資源は、テナントの各々が要求する資源の構成にできるだけ類似していることが好ましい。

図１０および図１１を参照して、類似資源の決定方法および運用費用の算出方法の一例について説明する。図１１は、類似資源を決定し、運用費用を算出する処理の一例を示すフローチャートである。

まず、算出したテナント間の距離に基づいて、テナントをグループ化する（Ｓ３０１）。 図１０（ａ）を参照すると、テナントＡ，Ｂ，Ｃを１つのグループとしてグループ化できる。また、テナントＥ，Ｆを１つのグループとしてグループ化できる。

続いて、各グループ内における類似資源を決定する（Ｓ３０２）。図１０（ｂ）および図１０（ｃ）は、抽出した共用化対象となるテナントの組み合わせを状態遷移図で表示した一例を示す図である。図１０（ｂ）及び図１０（ｃ）において、矢印の根元にあるブロックは、集約元の資源の利用を要求するテナントであり、矢印の先に示すブロックは、集約先の資源の利用を要求するテナントである。

類似資源の決定は、例えば以下のように行うことができる。

まず、図１０（ｂ）を参照して、テナントＡ，Ｂ，Ｃが利用を要求する資源のうち、どの資源に集約すれば集約の負荷が小さいのかを類似度を用いて決定する。

テナントＢ，Ｃの資源をテナントＡの資源に集約する場合、テナントＢの資源からテナントＡの資源への変更に対応する類似度は４である。しかしながら、テナントＣの資源からテナントＡへの変更に対応する類似度は、閾値以上の数値（類似度；１０）であるため抽出されていない。よって、テナントＢ，Ｃの資源からテナントＡの資源へ集約する方法は、類似資源の候補から除外される。

テナントＡ，Ｃの資源をテナントＢの資源に集約する場合、テナントＡの資源からテナントＢの資源への変更に対応する類似度は３であり、テナントＣの資源からテナントＡの資源への変更に対応する類似度は６である。よって、テナントＡ，Ｃの資源からテナントＢの資源へ集約する場合、類似度の和は３＋６＝９と算出される。

テナントＡ，Ｂの資源をテナントＣの資源に集約する場合、テナントＡの資源からテナントＣの資源への変更に対応する類似度は６であり、テナントＢの資源からテナントＣの資源への変更に対応する類似度は６である。よって、テナントＡ，Ｂの資源からテナントＣの資源へ集約する場合、類似度の和は６＋６＝１２と算出される。

以上の算出結果をもとに類似度の和を比較し、類似度の和が最も小さい、テナントＡ，Ｃの資源をテナントＢの資源に集約する方法を類似資源として決定する。

次に、図１０（ｃ）を参照して、テナントＥ，Ｆの資源のうち、どの資源に集約すれば集約の負荷が小さいのかを類似度を用いて決定する。

テナントＥの資源をテナントＦの資源に集約する場合、テナントＥの資源からテナントＦの資源への変更に対応する類似度は２である。一方、テナントＦの資源をテナントＥの資源に集約する場合、テナントＦの資源からテナントＥの資源への変更に対応する類似度は１である。よって、類似度が小さい、テナントＦの資源をテナントＥの資源に集約する方法を類似資源として決定する。

図１２は、類似資源を決定し、運用費用を算出する処理の変形例を示すフローチャートである。決定した類似資源によってはサーバの動作に支障をきたす場合がある。例えば、共用化の実行によりＯＳが旧バージョンにダウングレードされた場合に、既にインストールされているアプリが旧バージョンのＯＳとの互換性を有していないと、アプリが動作しなくなる不具合が生じ得る。そこで、図１２に示す変形例には、類似資源を決定した後に、類似資源による運用が可能かどうかを判定する処理が追加されている。

図１２において、Ｓ３０１以前に行う処理は、図１１に示す処理と同様である。Ｓ３０２で各グループ内における類似資源を決定した後、決定した類似資源による運用が可能かどうか判定する（Ｓ３０４）。運用が可能かどうかの判定は、例えば、メモリ５にＯＳ構成要素間の制約条件に関する情報を格納しておき、これらの情報を検索して運用が可能かどうかを調べることによって行うことができる。決定した類似資源による運用が可能であると判定された場合（Ｓ３０４肯定）、Ｓ３０３に移る。決定した類似資源による運用が不可能であると判定された場合（Ｓ３０４否定）、Ｓ３０２に戻り、当該グループ内における類似資源の決定を再度実行する。

このように、類似資源を決定した後に、類似資源による運用が可能かどうかを判定することによって、動作に適さない資源を排除できるため、類似資源の決定精度の向上を図ることができる。

次に、図１１に戻り、類似資源をテナントが利用した場合の運用費用を算出する（Ｓ３０３）。

プロセッサ７は、Ｓ３０２で決定した類似資源の情報と、メモリ５に格納されている資源の運用費用の情報とに基づいて、類似資源の運用費用に関する情報を算出する。

まず、１テナントあたりの運用費用について説明する。例えば、１テナントあたりの運用費用ｃは
式（２）；

と表すことができる。ここで、Ｓは１テナントあたりの固定費であり、Ｐ×（１−（ｎ−１）／Ｔ）は資源を共用することによる変動費である。Ｐは１テナントあたりの変動費の最大値であり、Ｔは総テナント数、ｎは資源を共用するテナント数である。

例えば、１００テナントが全て個別に異なる資源を使用する場合は、Ｔ＝１００、ｎ＝１であるため、これらを式（２）に代入すると運用費用ｃ_siloは
式（３）；

と表され、費用が最も高くなる。また、例えば、１００テナント全てが１つの資源を共用する場合は、Ｔ＝１００、ｎ＝１００となるため、これらを式（２）に代入すると運用費用ｃ_shareは
式（４）；

と表され、費用が最も低くなる。

また、共用化を実行した場合に得られる資源の運用費用の削減量（削減効果）ｃ_silo−ｃ_shareは、式（３）および式（４）を用いることにより
式（５）；

と求めることができる。

続いて、テナントＡ，Ｃの資源をテナントＢの資源に集約する場合の運用費用ｃ_{（Ａ，Ｂ，Ｃ）}を算出する。この場合、６つのテナントのうち３つのテナントで資源を共用することとなるため、式（２）にＴ＝６、ｎ＝３を代入すると、運用費用ｃ_{（Ａ，Ｂ，Ｃ）}は
式（６）；

と求めることができる。よって、共用化を行うことによる運用費用の削減量ｃ_ｓｉｌｏ−ｃ_{（Ａ，Ｂ，Ｃ）}は、式（３）および式（６）を用いることにより
式（７）；

と求めることができる。

続いて、テナントＡ，Ｃの資源をテナントＢの資源に集約する場合の運用費用ｃ_{（Ｅ，Ｆ）}を算出する。この場合、６つのテナントのうち２つのテナントで資源を共用することとなるため、式（２）にＴ＝６、ｎ＝２を代入すると、運用費用ｃ_{（Ｅ，Ｆ）}は
式（８）；

と求めることができる。よって、共用化を行うことによる運用費用の削減量ｃ_ｓｉｌｏ−ｃ_{（Ｅ，Ｆ）}は、式（３）および式（８）を用いることにより
式（９）；

と求めることができる。

式（２）〜（９）それぞれの実際の運用費用は、例えばメモリ５に格納された資源の運用費用の情報の中からＳおよびＰの値を取得し、取得した値を式（２）〜（９）に代入することによって算出することができる。

Ｓ３０３が終了すると、図３に戻り、対象テナントに、生成した類似資源の情報（資源情報）および類似資源の運用費用の情報を提示する（Ｓ１０５）。

ここで、対象テナントに提示する類似資源の運用費用の情報は、対象テナントが要求する資源を利用した場合の運用費用と、類似資源を利用した場合の運用費用とを提示しても良いし、対象テナントが利用を要求する資源の代わりに、類似資源を利用することによって得られる費用削減量を提示しても良い。ここで費用削減量とは、テナントが要求する資源を利用した場合の運用費用と、類似資源を利用した場合の運用費用との差分である。あるいは、運用費用と費用削減量の両方を提示するようにしても良い。

Ｓ１０５において、プロセッサ７は、情報処理装置３内のインターフェース（Ｉ／Ｆ）９に、類似資源の情報と、Ｓ３０３で算出した類似資源の費用に関する情報とを、対象テナントが有する端末に送信するように指示する信号を送信する。インターフェース（Ｉ／Ｆ）９は、プロセッサ７から受信した信号に基づいて、類似資源の情報と資源の運用費用の削減量の情報とを含む信号を、端末２ａ〜２ｅのうち、対象テナントが有する端末に送信する。

図１３は、類似資源および類似資源の運用費用の情報を対象テナントに提示する一例を示す図である。図１３は、類似資源の運用費用の情報として、運用費用の削減量を提示する場合の一例を示している。

図１３に示すように、情報処理装置３は、テナントＡ，Ｃの資源をテナントＢの資源に集約するための類似資源に係る情報と、当該類似資源を実行した場合に得られる資源の運用費用の削減量ｃ_ｓｉｌｏ−ｃ_{（Ａ，Ｂ，Ｃ）}＝（１／３）×Ｐに係る情報とをテナントＡ，Ｂ，Ｃの端末２ａ，２ｂ，２ｃにそれぞれ送信する。また、情報処理装置３は、テナントＦが利用する資源をテナントＥが利用する資源に集約するための類似資源に係る情報と、当該共用化を実行した場合に得られる資源の運用費用の削減量ｃ_ｓｉｌｏ−ｃ_{（Ｅ，Ｆ）}＝（１／６）×Ｐに係る情報とをテナントＥ，Ｆに提示する。なお、テナントＤは対象テナントではないため、情報処理装置３は、テナントＤの端末２ｄに上述の情報を送信しない。

このように、対象テナントが要求する資源を利用した場合の運用費用と、類似資源を利用した場合の運用費用との差分を対象テナントに提示することによって、対象テナントは本来要求していた資源に類似する資源を選択肢として得られるだけでなく、類似資源を利用することによるコストメリットを定量的に把握することができるため、どちらの資源を採用するかどうかを容易に判断することができる。

続いて、類似資源および資源の運用費用の削減量に係る情報を受信した対象テナントは、類似資源の利用を承認するかどうかを判断する。対象テナントは、資源の変更に伴う諸費用とコストメリットとを比較しながら判断する。対象テナントが類似資源の利用を承認する場合、対象テナントが所有する端末は、承認する旨の信号をインターフェース（Ｉ／Ｆ）９に送信する。対象テナントが類似資源の利用を承認しない場合、対象テナントが所有する端末は、承認しない旨の信号をインターフェース（Ｉ／Ｆ）９に送信する。

続いて、図３に戻り、プロセッサ７は、全ての対象テナントが類似資源の利用を承認したかどうかを判定する（Ｓ１０６）。全ての対象テナントが類似資源を利用することを承認したと判定した場合（Ｓ１０６肯定）、プロセッサ７は、対象資源に共用化を指示する信号をインターフェース（Ｉ／Ｆ）８に送信する。インターフェース（Ｉ／Ｆ）８は、共用化を指示する信号に含まれる情報に基づいて、クラウドシステムインフラ１内の管理端末４に共用化への移行を指示する信号を送信する。共用化への移行を指示する信号を受信した管理端末４は、サーバ１ａ〜１ｄのうちの対象サーバに対してアップグレードまたはインストール等の共用化処理を実行する。

一方、全てのテナントが類似資源の利用を承認しなかったと判定した場合（Ｓ１０６否定）、プロセッサ７は、非承認としたテナントを対象テナントから除外する（Ｓ１０８）。その後、プロセッサ７は、対象テナントが存在するかどうかを判定する（Ｓ１０９）。対象テナントが存在しないと判定した場合（Ｓ１０９否定）、プロセッサ７は、共用化ができないため処理を終了する。対象テナントが存在すると判定した場合（Ｓ１０９肯定）、Ｓ１０４に戻り、プロセッサ７は、残りのテナントが利用する資源に類似する類似資源を決定し、コストメリットの算出を再び行う。

このように、非承認としたテナントを対象テナントから除外し、全ての対象テナントが承認するまで処理を繰り返すことにより、全ての対象テナントの承認の上で、対象テナントの間で採りうる最適な方法で共用化を図ることができる。

なお、承認結果は、プロバイダから対象テナントに類似資源の提示を行ってもすぐに対象テナントから回答が得られるとは限らない。特に、提示を行った殆どのテナントから承認結果が得られている状況下で、一部の対象テナントからの承認結果が得られていない場合は、共用化ができないまま遅延することとなるため、既に承認判断を終えたテナントが不利益を被るだけでなく、運用費用の削減量も市況の変化等により変化してしまう恐れがある。そのため、情報処理装置３から対象テナントに類似資源の情報を送信する際には、送信してからの所定の経過時間を回答期限として設定するのが好ましい。

図１４は、本発明の実施形態における情報処理装置の動作の変形例を示すフローチャートである。図１４において、Ｓ１０５以前に行う処理は、図３に示す処理と同様である。Ｓ１０５において、類似資源および類似資源の運用費用の情報を対象テナントに送信した時点を起点として時間計測を開始する（Ｓ１１０）。時間計測は、例えばプロセッサ７に内蔵されているクロック等を用いることができる。

続いて、プロセッサ７は、対象テナントの端末から承認結果を受信したかどうかを判定する（Ｓ１１１）。対象テナントの端末から承認結果を受信した場合（Ｓ１１１肯定）、Ｓ１０６に移る。対象テナントの端末から承認結果を受信していないと判定された場合（Ｓ１１１否定）、送信してから所定の時間が経過したかどうかを判定する（Ｓ１１２）。送信してから所定の時間が経過したと判定した場合（Ｓ１１２肯定）、プロセッサ７は当該対象テナントが非承認したものと判定する（Ｓ１１３）。送信してから所定の時間が経過していないと判定した場合（Ｓ１１２否定）、Ｓ１１１に戻る。

このように、送信してからの所定の経過時間を回答期限として設定し、回答期限を経過した対象テナントを非承認とみなして対象テナントから除外することで、残りのテナントが利用する資源を前提とした類似資源の決定を迅速に進めることができるため、共用化の遅延を抑えることができる。

図１５は、共用化の実行前および実行後における資源の一例を示す図である。図１５に示すように、テナントＡ，Ｂ，Ｃは、共用化後はＯＳとしてOS-a 4.5、アプリとしてApp-a 2.4を含む資源と、ＯＳとしてOS-a 4.5、アプリとしてApp-b 4.1を含む資源とを有するサーバを利用することとなる。テナントＤは、共用化に係る対象テナントでないため、資源に変更はない。テナントＥ、Ｆは、共用化後はＯＳとしてOS-b 2.0、アプリとしてApp-b 7.0の資源と、ＯＳとしてOS-b 2.0、アプリとしてApp-b 5.0を含む資源とを有するサーバを利用することとなる。このように、テナントＡ，Ｂ，Ｃは、共用化によって資源を減少させることができる。

図１６は、共用化の実行前および実行後における資源の構成要素の数および種類を、図１５に基づいて集計した結果を示す図である。図中の集約率は、集約前の数値に対する集約後の数値で定義され、集約率の数値が小さいほど集約効果が大きいことを示している。図１６に示すように、共用化を実行することによって、構成要素の数および種類をともに削減することが可能となり、集約効果は構成要素の種類よりも数の方が大きいことがわかる。このように、システムの複雑の度合いや規模を抑えながら、運用費用を削減することが可能となる。

以上のように、本発明の実施形態によれば、資源の情報に基づいて算出した類似度に基づいて類似資源を決定し、決定した類似度の運用費用を算出し、類似資源の情報と類似資源の運用費用に関する情報とを対象テナントに提示する。これにより、プロバイダおよびテナント双方にとって、クラウドコンピューティングのアーキテクチャを効率的かつ高い柔軟性で利用することができる。すなわち、プロバイダにとっては、テナントから承認を得た上でデータセンタのサーバのアーキテクチャを簡素化することができ、その結果、サーバの管理の複雑さが改善され、テナントあたりの運用費用の低減を図ることができる。一方、テナントにとっては、プロバイダから提供されたメリットを把握した上で資源を選択することができるため、選択の柔軟性を得ることができる。

図１７は、本発明の実施形態によって実現可能なマルチテナントアーキテクチャの種類の一例を示す図である。図１７（ｂ）の形態は、マルチテナントネイティブPaaSを複数備えた形態である。この形態は、図１７（ａ）に示すように、テナントが利用するサーバが有する資源間で同一または類似のものをグルーピングして集約し、比較的小規模なマルチテナントネイティブPaaSを複数形成することによって実現することができる。

図１８は、本発明の実施形態によって実現可能なマルチテナントアーキテクチャの種類の別の一例を示す図である。図１８（ｂ）の形態は、全てのテナントが１つのマルチテナントネイティブPaaSを利用するのではなく、一部の資源だけを共用するようにした形態である。この形態は、図１８（ａ）を参照しながら、各テナントが利用する資源の中で部分的に共用可能な資源を抽出し、一部を共用化して１つのアーキテクチャとして構成することによって実現することができる。

以上、本発明の好ましい実施例について詳述したが、本発明は特定の実施例に限定されるものではなく、種々の変形や変更が可能である。図１９は、資源間の距離の定義の変形例を示す図である。本実施例では、資源の変更の負荷を示す負荷レベルを数値で表したが、例えば図１９（ａ）に示すように、資源の変更に要する費用を距離の定義として用いることもできる。または、図１９（ｂ）に示すように、資源の変更に要する時間（工数）を距離の定義として用いることもできる。

１：クラウドシステムインフラ
２：端末
３：情報処理装置
４：管理端末
５：メモリ
６：メモリ
７：プロセッサ
８：インターフェース（Ｉ／Ｆ）
９：インターフェース（Ｉ／Ｆ）
２１〜２７：資源
３１〜３５：資源

Claims (7)

1. 複数の構成要素のそれぞれの運用費用の情報を記憶するとともに、複数の異なる要求元からそれぞれ受信した、前記複数の構成要素の一部又は全部を含む資源の要求情報を記憶する記憶部と、
   処理部と、
   を有し、
   前記処理部は、
   前記記憶部に記憶された資源の要求情報によって要求された各資源に含まれる割合が所定の基準を超える１又は複数の構成要素を含む資源情報を生成し、
   前記記憶部を参照して、前記１又は複数の構成要素のそれぞれに対応する運用費用に基づいて、生成した該資源情報についての運用費用の情報を算出し、
   前記複数の異なる要求元の少なくとも１つの要求元に対して、生成した前記資源情報と、算出した前記運用費用の情報とを提供する、処理を実行する情報処理装置。
2. 前記運用費用の情報は、前記要求元から要求された資源を利用した場合の運用費用と、生成した前記資源情報に対応する資源を利用した場合の運用費用との差分の情報である請求項１記載の情報処理装置。
3. 前記処理部は、
   前記資源情報に対応する資源による運用が可能かどうかを判定し、
   運用可能でないと判定された場合に、前記資源情報を再度生成する処理をさらに実行する請求項１又は２に記載の情報処理装置。
4. 前記処理部は、
   生成した前記資源情報と、算出した前記運用費用の情報とを提供された全ての前記要求元が、生成した前記資源情報に対応する資源を利用することを承認しなかった場合に、承認しなかった要求元を除外した残りの要求元により要求された資源に基づいて、前記資源情報を生成する処理と前記運用費用の情報を算出する処理とをさらに実行することを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記処理部は、
   前記資源情報と前記運用費用の情報とを提供してからの所定の経過時間を設定し、
   所定の経過時間まで経過しても前記要求元から承認結果を含む信号を受信しなかった場合に承認しなかったものと判定する請求項１〜４のいずれか１項に記載の情報処理装置。
6. コンピュータが、
   複数の構成要素のそれぞれの運用費用の情報を記憶するとともに、複数の異なる要求元からそれぞれ受信した、前記複数の構成要素の一部又は全部を含む資源の要求情報を記憶し、
   前記記憶部に記憶された資源の要求情報によって要求された各資源に含まれる割合が所定の基準を超える１又は複数の構成要素を含む資源情報を生成し、
   前記記憶部を参照して、前記１又は複数の構成要素のそれぞれに対応する運用費用に基づいて、生成した該資源情報についての運用費用の情報を算出し、
   前記複数の異なる要求元の少なくとも１つの要求元に対して、生成した前記資源情報と、算出した前記運用費用の情報とを提供する、処理を実行する情報処理方法。
7. サーバと、
   複数の構成要素のそれぞれの前記サーバにおける運用費用の情報を記憶するとともに、複数の異なる要求元からそれぞれ受信した、前記複数の構成要素の一部又は全部を含む前記サーバの資源の要求情報を記憶する記憶部と、処理部とを有する情報処理装置と、
   を有し、
   前記処理部は、
   前記記憶部に記憶された資源の要求情報によって要求された各資源に含まれる割合が所定の基準を超える１又は複数の構成要素を含む資源情報を生成し、
   前記記憶部を参照して、前記１又は複数の構成要素のそれぞれに対応する運用費用に基づいて、生成した該資源情報についての運用費用の情報を算出し、
   前記複数の異なる要求元の少なくとも１つの要求元に対して、生成した前記資源情報と、算出した前記運用費用の情報とを提供する、処理を実行する情報処理システム。