(57)【要約】      （修正有）【課題】仮想システムの構成変更に関してユーザを支援する。【解決手段】判定方法は、仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付けＳ１、第１の仮想システムの構成データに基づき、第１の仮想システムで実現される機能に関する機能要件を抽出しＳ３、第１の仮想システムについて用いられる運用プロセスについてのデータと機能要件とに基づき、第１の仮想システムを実現するための運用要件を抽出しＳ５、機能要件及び運用要件と第２の仮想システムの構成要素から特定される制約条件とに基づき、第２の仮想システムへの変更の可否を判定する処理Ｓ９、Ｓ１１を含む。【選択図】図４
2016071562.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出し、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出し、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する
処理を、コンピュータに実行させるための判定プログラム。
【請求項２】
前記運用要件を抽出する処理が、
仮想システムに含まれるべき機能についての第１の要件と当該機能に関連して用いられるべき運用プロセスについての第２の要件とを各々含む、運用要件についての複数のパターンから、前記機能要件と前記第１の仮想システムについて用いられる運用プロセスについてのデータとに基づき、前記第１の仮想システムが第１及び第２の要件を満たすパターンを抽出する処理
を含む請求項１記載の判定プログラム。
【請求項３】
前記判定する処理が、
前記第２の仮想システムへの変更を、前記機能要件に適用することで、変更後の機能要件を生成し、
前記変更後の機能要件及び前記運用プロセスについてのデータから特定される構成が、前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とを満たすか否かを判定する
処理を含む請求項１又は２記載の判定プログラム。
【請求項４】
前記第２の仮想システムへの変更の可否を判定する処理において前記第２の仮想システムへの変更が否と判定された場合、前記第２の仮想システムに追加すべき機能と前記第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれかを探索する処理
をさらに前記コンピュータに実行させるための請求項１乃至３のいずれか１つ記載の判定プログラム。
【請求項５】
前記探索する処理は、
前記第２の仮想システムに追加すべき機能と前記第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれか及び前記変更後の機能要件及び前記運用プロセスについてのデータから特定される構成から、前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とを満たす上で影響がない機能と運用プロセスとのうち少なくともいずれかを削除する
処理を含む請求項４記載の判定プログラム。
【請求項６】
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出し、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出し、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する
処理を含み、コンピュータが実行する判定方法。
【請求項７】
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付ける入力部と、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出する第１の抽出部と、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出する第２の抽出部と、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する処理部と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の仮想マシンを含む仮想システムの構成変更を支援するための技術に関する。
【背景技術】
【０００２】
近年、クラウドの利用が一般化して、ユーザが特定のクラウドの要件に合せてシステムを構築する段階から、さらに様々なクラウドを臨機応変に組み合わせてビジネスを実現する段階に移行しつつある。
【０００３】
例えば、パブリッククラウドを利用して小規模システムでビジネスをスタートした後、ビジネス拡大に応じてコストパフォーマンスが高いプライベートクラウドにアプリケーションを移行するといったアプリケーションマイグレーションを行う場合がある。また、プライベートクラウドで稼働させているサービスが一時的に過負荷になったので、アプリケーションの一部機能をパブリッククラウドに複製し、負荷分散させるといったクラウドバースティングを行う場合もある。
【０００４】
このようにシステム構成は、最初に設計及び構築したら変化しないものではなく、常に構成変化が起こりうるものである。また、クラウドを組み合わせて利用している場合には、その組み合わせ自体にも様々な変化が起こりうる。
【０００５】
しかしながら、あるクラウド（例えばクラウドＡ）のインフラストラクチャ（単にインフラと略する場合もある）で稼働させていた機能を他のクラウド（例えばクラウドＢ）に移動又は複製させる場合には、クラウドＡでは正常に動作していたとしてもクラウドＢでは正常に動作しなくなる可能性がある。
【０００６】
例えば、クラウドＡでは負荷分散機能を標準で提供しているが、クラウドＢには負荷分散機能が無い。このような場合にクラウドＢを利用しようとすると、クラウドＢでは仮想マシンを１つ追加で起動して、負荷分散機能を自前で準備するための運用プロセスを実行することになる。
【０００７】
また、ファイアウォールを有しないクラウドＡで稼働しているサービスで実行される一部アプリケーションを、ファイアウォールを有するクラウドＢに移行する場合には、クラウドＡ−クラウドＢ間の通信が遮断される可能性がある。そのため、ファイアウォール設定を正しく行うための運用プロセスを実行することになる。
【０００８】
運用プロセスは、意図した仮想システムの機能を実現するためのスクリプトで実現される場合が多く、トリガと処理とで定義される。トリガは、処理を実行するための契機であり、処理は、システム又はアプリケーションに対して行う処理の内容を表す。
【０００９】
具体的には、過負荷に対応するためのＷｅｂサーバのスケールアウトのための運用プロセスにおけるトリガは、Ｗｅｂサーバの過負荷の検出であり、処理は、Ｗｅｂサーバの追加起動と、アプリケーションの配備とを含む。
【００１０】
また、データの定期バックアップの運用プロセスにおけるトリガは、所定の時刻であり、処理は、データベースサーバのデータをバックアップ用のストレージにコピーするものである。
【００１１】
一般的に、運用管理ツール（例えばscalr）がエージェント経由でイベントのモニタを行って、イベントが運用プロセスについてのトリガに相当する場合には、当該トリガに対応する処理を実行することになる。
【００１２】
ユーザは、上で述べたアプリケーションマイグレーションやクラウドバースティングを含む、仮想システムの構成変更を計画したとしても、その仮想システムの構成変更が、何らの問題なく実現できるのかということを判断することは困難な場合が多い。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特表２０１３−５１６６６８号公報
【特許文献２】特表２０１３−５４４４１７号公報
【特許文献３】特開２０１２−８４１２９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
従って、本発明の目的は、一側面として、仮想システムの構成変更に関してユーザを支援するための技術を提供することである。
【課題を解決するための手段】
【００１５】
本発明に係る判定方法は、（Ａ）仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、（Ｂ）第１の仮想システムの構成データに基づき、第１の仮想システムで実現される機能に関する機能要件を抽出し、（Ｃ）第１の仮想システムについて用いられる運用プロセスについてのデータと機能要件とに基づき、第１の仮想システムを実現するための運用要件を抽出し、（Ｄ）機能要件及び運用要件と第２の仮想システムの構成要素から特定される制約条件とに基づき、第２の仮想システムへの変更の可否を判定する処理を含む。
【発明の効果】
【００１６】
一側面としては、仮想システムの構成変更に関してユーザを支援できるようになる。
【図面の簡単な説明】
【００１７】
【図１】図１は、実施の形態に係る情報処理装置の構成例を示す図である。
【図２】図２は、変更前の仮想システムの一例を示す図である。
【図３】図３は、変更後の仮想システムの一例を示す図である。
【図４】図４は、実施の形態に係る処理フローを示す図である。
【図５】図５は、変更前の仮想システムの構成データの一例を示す図である。
【図６】図６は、変更前の仮想システムの運用プロセス定義の一例を示す図である。
【図７】図７は、システム変更データの一例を示す図である。
【図８】図８は、機能要件の一例を示す図である。
【図９】図９は、デザインパターンの一例を示す図である。
【図１０】図１０は、述語論理式形式で記述されたデザインパターンの一例を示す図である。
【図１１】図１１は、プロバイダ固有のプロバイダ制約データの一例を示す図である。
【図１２】図１２は、プロバイダ共通制約条件（ファイアウォール要件）の一例を示す図である。
【図１３】図１３は、述語論理式形式で記述された運用プロセス定義の一例を示す図である。
【図１４】図１４は、スクリプト格納部に格納されるデータの一例を示す図である。
【図１５】図１５は、述語論理式形式で記述されたスクリプトのデータの一例を示す図である。
【図１６】図１６は、制約充足分析部に入力される第１のデータの一例を示す図である。
【図１７】図１７は、条件充足の場合の実装例を示す図である。
【図１８】図１８は、変更後の第１のデータを示す図である。
【図１９】図１９は、変更処理の処理フローを示す図である。
【図２０】図２０は、変更処理の具体例を説明するための図である。
【図２１】図２１は、変更処理の具体例を説明するための図である。
【図２２】図２２は、変更処理の具体例を説明するための図である。
【図２３】図２３は、変更処理の具体例を説明するための図である。
【図２４】図２４は、変更処理の処理フローを示す図である。
【図２５】図２５は、変更処理の具体例を説明するための図である。
【図２６】図２６は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１８】
本発明の実施の形態に係る情報処理装置１００の機能構成例を図１に示す。本情報処理装置１００は、入力部１０１と、入力データ格納部１０２と、第１抽出部１０３と、第１データ格納部１０４と、第２抽出部１０５と、第２データ格納部１０６と、スクリプト格納部１０７と、デザインパターン格納部１０８と、制約データ格納部１０９と、制約充足分析部１１０と、変更後処理部１１１と、出力データ格納部１１２と、出力部１１３とを有する。
【００１９】
入力部１０１は、ユーザ又は他のコンピュータから仮想システムの構成変更に係るデータの入力を受け付け、入力データ格納部１０２に格納する。第１抽出部１０３は、入力データ格納部１０２に格納されているデータから、変更前の仮想システムで実現される機能についての機能要件を抽出し、当該機能要件についてのデータを第１データ格納部１０４に格納する。機能要件は、より具体的には、要求されている機能を提供するために直接用いられるコンポーネント（例えばＷｅｂサーバ、ＤＢサーバ、ファイアウォールなど）の構成を含む。
【００２０】
デザインパターン格納部１０８は、運用要件を実現するための機能についての要件と当該機能に関連して実行が求められるスクリプトのデータとを含むデザインパターンを運用要件毎に格納する。
【００２１】
制約データ格納部１０９は、プロバイダ固有の制約条件についてのデータと、プロバイダ共通の制約条件についてのデータとを格納している。プロバイダ固有の制約条件は、特定のクラウドではファイアウォールが必須であるという条件、他の特定のクラウドではロードバランサ機能が標準提供であるという条件などである。また、プロバイダ共通の制約条件については、ファイアウォールを実現するための機能についての要件と当該機能に関連して実行が求められる運用プロセスについてのデータとを含む。
【００２２】
スクリプト格納部１０７は、運用プロセスのためのスクリプトのデータを格納する。
【００２３】
第２抽出部１０５は、入力データ格納部１０２、第１データ格納部１０４、デザインパターン格納部１０８、制約データ格納部１０９及びスクリプト格納部１０７に格納されているデータを用いて、変更前の仮想システムについての運用要件を抽出し、処理に用いたデータ及び運用要件についてのデータを第２データ格納部１０６に格納する。なお、第２抽出部１０５は、制約充足分析部１１０と連携して処理を行う。制約充足分析部１１０は、例えばＡｌｌｏｙ  ａｎａｌｙｚｅｒなどの検証器（ソルバー）であり、例えば変更前の仮想システムの構成（機能及び運用プロセスで特定される構成）が、与えられた運用要件（すなわちデザインパターン）及びプロバイダの制約条件を充足するか否かを判定する。
【００２４】
変更後処理部１１１は、入力データ格納部１０２、制約データ格納部１０９、スクリプト格納部１０７及び第２データ格納部１０６に格納されているデータを用いて、ユーザによる問い合わせに係る仮想システムの構成変更の可否について判定する。ここでも、変更後処理部１１１は、制約充足分析部１１０と連携して処理を行う。すなわち、制約充足分析部１１０は、変更後の仮想システムの構成（機能及び運用プロセスで特定される構成）が、抽出された運用要件及びプロバイダの制約条件を充足するか否かを判定する。
【００２５】
仮想システムの構成変更が可である場合には、変更後処理部１１１は、その旨のデータ等を出力データ格納部１１２に格納する。
【００２６】
仮想システムの構成変更が否と判定されると、変更後処理部１１１は、制約充足分析部１１０と連携して、抽出された運用要件及びプロバイダの制約条件を満たすために追加すべき機能又は運用プロセス又はその両方を特定し、追加すべき構成に関するデータ及び追加すべき構成が追加された後の構成のデータを、出力データ格納部１１２に格納する。
【００２７】
出力部１１３は、出力データ格納部１１２に格納されているデータを、表示装置、印刷装置、他のコンピュータなどの出力装置に出力する。
【００２８】
次に、図２乃至図２５を用いて、情報処理装置１００の処理内容について説明する。なお、処理内容を分かりやすくするために、変更前の仮想システムとして、図２に示すような仮想システムを想定する。
【００２９】
すなわち、変更前の仮想システムは、フロントエンドのＷｅｂサーバとして動作する複数のＷｅｂＶＭ（Virtual Machine）と、データを蓄積するデータベース（ＤＢ）サーバとして動作するＤＢＶＭとを含む。変更前の仮想システムは、クラウドインフラＣ１上で稼働する。また、クラウドインフラＣ１が標準で提供する負荷分散機能（ロードバランサ）を利用して、複数のＷｅｂＶＭ間で負荷分散が行われている。より具体的には、ＷｅｂＶＭの負荷情報に基づき、ロードバランサが、ＷｅｂＶＭを増減させるオートスケールを実行する。なお、負荷分散機能をユーザの意図通りに実現するために、運用プロセスとしてオートスケール処理が実行される。
【００３０】
一方、システムの管理者は、図３に示すようなシステムへの変更を計画している。すなわち、クラウドインフラＣ１よりも安価なクラウドインフラＣ２が出現したので、フロントエンドのＷｅｂＶＭをクラウドインフラＣ２に移行させる。一方、ＤＢＶＭについてはクラウドインフラＣ１上に維持する。但し、クラウドインフラＣ２では、クラウドインフラＣ１で標準提供されている負荷分散機能が提供されていない。また、クラウドインフラＣ２では、ファイアウォールの使用が必須となっている。
【００３１】
まず、入力部１０１は、変更前の仮想システムの構成データ及び運用プロセス定義、並びにシステム変更データの入力を受け付け、入力データ格納部１０２に格納する（図４：ステップＳ１）。入力部１０１が、このようなデータを、他のコンピュータ（場合によっては変更前の仮想システム）から取得するようにしても良い。
【００３２】
構成データは、例えば、図５に模式的に示すように、変更前の仮想システムにおける仮想マシン及び機能についてのデータである。図５の例では、クラウドＣ１上に搭載されている変更前の仮想システムは、２つのＷｅｂＶＭと、１つのＤＢＶＭと、クラウドインフラＣ１で標準提供されているロードバランサ（Load Balancer）とを含む。識別子（ＩＤ）については、任意で設定される。
【００３３】
また、変更前の仮想システムのための運用プロセス定義は、例えば図６に示すようなデータである。図６の例では、運用プロセス毎に、当該運用プロセスの適用対象と、トリガと、処理内容（実行すべきスクリプトの名称）とが含まれる。より詳しくは、変更前の仮想システムには、運用プロセスＰ１が適用されており、この運用プロセスＰ１の実行対象はFunction1（ロードバランサ）である。そして、２種類のトリガ（ロードアベレージ（Load average）が５より大きい場合、ロードアベレージが２より小さい場合）と、各トリガに応じて実行すべきスクリプトとが含まれる。
【００３４】
さらに、システム変更データは、例えば図７に示すようなデータである。すなわち、システム変更データは、変更処理（新規追加（ａｄｄ）、削除（ｄｅｌｅｔｅ）、移動（ｍｏｖｅ）、修正（ｍｏｄｉｆｙ）など）と、変更対象機能のＩＤと、変更内容とを含む。
【００３５】
次に、第１抽出部１０３は、入力データ格納部１０２に格納されている構成データから機能要件を抽出する（ステップＳ３）。本実施の形態では、制約充足分析部１１０で処理できるように、構成データを述語論理式形式の機能要件に変換する。より具体的には、ＶＭ及び機能（Function）の配置についての記述と、ＶＭ及びFunctionの役割（機能）についての記述とを含む記述に変換する。図５に示した例では、図８に示すように、ＶＭ及びFunctionの配置「deployed」という属性についてクラウドＣ１が設定されており、ＶＭ及びFunctionの役割「role」という属性についてＷｅｂ、ＤＢ又はLoadBalancerが設定されている。
【００３６】
また、第２抽出部１０５は、入力データ格納部１０２に格納されている運用プロセス定義と、第１データ格納部１０４に格納されている機能要件と、制約データ格納部１０９及びスクリプト格納部１０７に格納されているデータとに基づき、デザインパターン格納部１０８に格納されているデザインパターンから、運用要件を抽出し、運用要件のデータ及び処理途中のデータを第２データ格納部１０６に格納する（ステップＳ５）。
【００３７】
デザインパターンは、例えば図９に示すようなデータを、述語論理式形式で表したものである。図９は、クラウド内Ｗｅｂオートスケールのためのデザインパターンを表しており、運用プロセスに対する要件と、機能要件に対する要件とが含まれている。このように、仮想システムで実現又は使用される機能についての運用要件が、デザインパターンとして規定される。
【００３８】
デザインパターンについても制約充足分析部１１０で解釈できるように述語論理式形式で記述される。図９の例は、図１０のように表現される。図１０において、上段は、ｐというプロセスのためのスクリプトの目的が、スケールアップとスケールダウンとであり、プロセスｐがｚというオブジェクト（リソースとも呼ぶ。ＶＭやクラウドで提供される機能）に実装されるという運用プロセスに対する要件を表している。下段は、オブジェクトｘ及びｙの役割がＷｅｂであり、オブジェクトｚの役割がロードバランサであり、オブジェクトｘ、ｙ及びｚが同じクラウドに実装されるという機能要件に対する要件を表している。
【００３９】
制約データ格納部１０９に格納されるデータは、プロバイダ共通制約条件とプロバイダ固有のプロバイダ制約データとを含む。クラウドＣ１では、ロードバランサが標準提供されるが、ロードバランサの使用は必須とはされていない。従って、上で述べた例では、クラウドＣ１についてのプロバイダ制約データは存在しない。
【００４０】
一方、クラウドＣ２では、ファイアウォールが必須となっている。従って、プロバイダ制約データとしては、図１１に示すようなデータである。図１１の例では、クラウドＣ２にはファイアウォールが必須であることが記述されている。また、プロバイダ共通制約条件として、ファイアウォールを用いる際のファイアウォール要件が規定される。
【００４１】
ファイアウォール要件は、ファイアウォールをまたぐシステムを構築する場合、具体的には複数のクラウドインフラを利用し、そのうち最低１つにファイアウォールがある場合には、それら全てのファイアウォールの設定スクリプトを実行し、通信を可能にするという制約条件である。プロバイダ共通制約条件としてのファイアウォール要件は、例えば図１２に示すように表される。
【００４２】
図１２の例では、オブジェクトｘの役割はファイアウォール（Firewall）であり、クラウドｙに配備されており、オブジェクトｘとは異なるオブジェクトｗがｙとは異なるクラウドｚに配備されている場合には、ｔというタスク（実質的にはスクリプトの実行）が運用プロセスｐについての作業（operation）の集合に含まれ、且つタスクｔのスクリプトの目的はファイアウォール設定（CONFIG_FIREWALL）であり、且つタスクｔのスクリプトはクラウドｙにおいて使用可能となっていることが要件である。
【００４３】
また、入力データ格納部１０２に格納されている運用プロセス定義は、制約充足分析部１１０で処理できるように述語論理式形式のデータに変換される。図６の例は、例えば図１３に示すような形式に変換される。図１３の例では、運用プロセスＰ１には、タスクｔ１及びｔ２が含まれており、タスクｔ１はｃ１＿ｓｃａｌｅ＿ｕｐというスクリプトによるタスクで、機能Function1に対して実行され、タスクｔ２はｃ１＿ｓｃａｌｅ＿ｄｏｗｎというスクリプトによるタスクで、機能Function1に対して実行されることが表される。なお、トリガについては、本実施の形態では用いられない。
【００４４】
さらに、スクリプト格納部１０７には、図１４に模式的に示すようなデータが格納されている。図１４の例では、スクリプトの種類と、スクリプトの各種類についてクラウドＣ１で実行可能な運用プロセスのスクリプトの名称と、スクリプトの各種類についてクラウドＣ２で実行可能な運用プロセスのスクリプトの名称とが登録される。
【００４５】
このようなデータは、制約充足分析部１１０で処理できるように述語論理式形式のデータに変形されてスクリプト格納部１０７に格納されている。例えば、図１５に示すようなデータで表される。図１５の例では、スクリプト毎にその目的が定義され、スクリプト毎に実行可能なクラウドが定義されている。
【００４６】
本実施の形態では、機能要件とプロセス定義とスクリプトのデータとを結合して、図１６に示すような第１のデータを生成する。図１６の例では、スクリプトのデータの部分Ｘと、運用プロセス定義の部分Ｙと、機能要件の部分Ｚと、ＸＹＺに関連する定義部分Ｈとが連結される。
【００４７】
定義部分Ｈは、運用プロセス、クラウド、ＶＭ、タスク、目的、機能、スクリプト、及び役割について、ＸＹＺの部分に出現するものを定義している。
【００４８】
また、第２抽出部１０５は、このような第１のデータに関連する第２のデータを制約データ格納部１０９から抽出する。すなわち、配備先のクラウドに関係するプロバイダ固有のプロバイダ制約データと当該プロバイダ制約データに関連するプロバイダ共通制約条件とを読み出す。上で述べた例では、クラウドＣ１についてはプロバイダ固有のプロバイダ制約データは存在しないので、プロバイダ共通制約条件も読み出されない。
【００４９】
さらに、第２抽出部１０５は、デザインパターン格納部１０８から、１つずつデザインパターンを読み出して、第１及び第２のデータと共に制約充足分析部１１０に出力して、制約充足分析部１１０に、第１のデータ（機能要件及び運用プロセス定義）が、第２のデータによる制約条件及びデザインパターンによる運用要件を充足しているか否かを判断させる。本実施の形態では、制約充足分析部１１０は、第１のデータが、第２のデータによる制約条件及びデザインパターンによる運用要件を充足している場合には、条件充足を表すデータとその実装例とを出力する。第２抽出部１０５は、条件充足を表すデータが得られた場合には、その際に出力したデザインパターンを運用要件として特定する。一方、第１のデータが第２のデータによる制約条件及びデザインパターンによる運用要件を充足していない場合には、条件充足せずということを表すデータを出力する。
【００５０】
いずれか１つのデザインパターンについて制約充足分析部１１０に処理させても、条件充足という結果を得られない場合には、第２抽出部１０５は、２以上のデザインパターンの組み合わせ全てについて、制約充足分析部１１０に処理させることで、条件充足という出力が得られるデザインパターンを運用要件として特定する。
【００５１】
本実施の形態では、特定された運用要件及びその際の実装例と、第１のデータ及び第２のデータとを、第２データ格納部１０６に格納する。
【００５２】
一般的に変更前の仮想システムは稼働しているので、条件充足とされるデザインパターンが少なくとも１つは特定される。上で述べた例では、図９に示したクラウド内Ｗｅｂオートスケールのためのデザインパターンが抽出される。また、上で述べた例では、制約充足分析部１１０から、図１７に示すような実装例のデータが出力される。図１７は、実質的に図２に示すような仮想システムを表している。
【００５３】
次に、変更後処理部１１１は、第２データ格納部１０６に格納されている機能要件のデータ（より具体的には第１のデータ（図１６））を、システム変更データに基づき変更し、例えば第２データ格納部１０６に格納する（ステップＳ７）。
【００５４】
図７に示すようなシステム変更データが得られた場合には、ＷｅｂＶＭの配備先がクラウドＣ１からクラウドＣ２に変更される。従って、図１８に示すように、第１のデータにおいて機能要件の一部分Ｍに変更が反映される。
【００５５】
そして、変更後処理部１１１は、制約データ格納部１０９から、変更後の第１のデータ（すなわち変更後の機能要件及び運用プロセス定義）に関連する第３のデータを、制約データ格納部１０９から抽出する。すなわち、配備先クラウドに関係するプロバイダ固有のプロバイダ制約データと当該プロバイダ制約データに関連するプロバイダ共通制約条件とを読み出す。ここでは、ＶＭ及びFunctionの配備先はクラウドＣ１及びクラウドＣ２であるから、クラウドＣ２についてのプロバイダ固有のプロバイダ制約データと当該プロバイダ制約データに関連するプロバイダ共通制約条件とを抽出する。クラウドＣ１についてのプロバイダ固有のプロバイダ制約データは存在しないので、クラウドＣ１についてはデータが得られない。従って、図１１及び図１２に示すデータが、第３のデータとなる。
【００５６】
その後、変更後処理部１１１は、変更後の第１のデータが、第３のデータによる制約条件及び抽出されたデザインパターンによる運用要件を充足しているか否かを、制約充足分析部１１０に判定させる（ステップＳ９）。
【００５７】
ステップＳ５と同様に、制約充足分析部１１０は、条件充足と判定した場合にはその旨を表すデータと実装例とを出力し、条件充足ではないと判定した場合にはその旨を表すデータを出力する。
【００５８】
上で述べた例では、クラウドＣ２ではファイアウォールの設定が必須であるのに拘わらず、変更後の第１のデータにはファイアウォールについての記述が含まれないため、条件充足ではないと判定される。
【００５９】
但し、条件充足と制約充足分析部１１０で判定されると（ステップＳ１１：Ｙｅｓルート）、変更後処理部１１１は、判定結果及び実装例のデータを、出力データ格納部１１２に格納する。そうすると、出力部１１３は、出力データ格納部１１２に格納されているデータから、システム変更を行っても問題が無い旨を表すデータ等（実装例のデータを含む場合もある）を、出力装置に出力する（ステップＳ１３）。
【００６０】
このようにすれば、運用管理者は、計画しているシステム変更をそのまま実行することができるということを認識できるようになる。
【００６１】
一方、条件充足ではないと制約充足分析部１１０で判定されると（ステップＳ１１：Ｎｏルート）、変更後処理部１１１及び制約充足分析部１１０は、機能及び運用プロセスについての変更処理を実行する（ステップＳ１５）。その後、処理は終了する。変更処理については、図１９乃至図２５を用いて説明する。
【００６２】
まず、変更後処理部１１１は、追加する運用プロセスの個数についてのカウンタｐと、追加するリソース（例えば仮想マシン）の個数についてのカウンタｒとを０に初期化する（図１９：ステップＳ２１）。
【００６３】
その後、変更後処理部１１１は、ｐ＋１個の運用プロセスとｒ個のリソース（例えばＶＭ）とを変更後の第１のデータに追加すると、第３のデータによる制約条件及び抽出されたデザインパターンによる運用要件を充足できるかを、制約充足分析部１１０に判定させる（ステップＳ２３）。
【００６４】
本実施の形態では、まずは不足している運用プロセス又はリソースを追加することで動作可能な仮想システムを特定する。
【００６５】
初期的には、１つの運用プロセスを追加することで、条件を充足できるのかを判定することになる。システム変更データを単純に適用した場合の状態は図２０に模式的に示すような状態である。この状態においては、クラウドインフラＣ２上のＷｅｂＶＭについてロードバランサの機能及び運用プロセスが不足しているためクラウド内Ｗｅｂオートスケール要件を満たしておらず、クラウドインフラＣ２で必須のファイアウォールに対する運用プロセスが適用されていないのでプロバイダ制約条件を満たしていない。これに対して、例えばファイアウォール設定の運用プロセスを１つ追加すると、図２１に模式的に示すような状態となる。このようにすれば、ファイアウォールについては問題が無くなるが、クラウド内Ｗｅｂオートスケール要件が満たされていないので、条件充足とは判断されない。どのような運用プロセスを追加するかについては、例えば総当たり方式で決定する。この際、例えば変更後の第１のデータに、リソースなどの追加を反映させる。
【００６６】
条件充足と判定される場合には（ステップＳ２５：Ｙｅｓルート）、処理は端子Ａを介して図２４の処理に移行する。一方、条件充足と判定されない場合には（ステップＳ２５：Ｎｏルート）、変更後処理部１１１は、ｐ個の運用プロセスとｒ＋１個のリソース（例えばＶＭ）とを変更後の第１のデータに追加すると、第３のデータによる制約条件及び抽出されたデザインパターンによる運用要件を充足できるかを、制約充足分析部１１０に判定させる（ステップＳ２７）。この際、例えば変更後の第１のデータに、リソースなどの追加を反映させる。
【００６７】
例えば、図２２に模式的に示すように、図２０の状態に対して追加リソースとして負荷分散ＶＭを追加しても、負荷分散ＶＭについて運用プロセスが適用されていないので、条件充足とは判定されない。
【００６８】
条件充足と判定される場合には（ステップＳ２９：Ｙｅｓルート）、処理は端子Ａを介して図２４の処理に移行する。一方、条件充足と判定されない場合には（ステップＳ２９：Ｎｏルート）、変更後処理部１１１は、ｐ及びｒが予め設定された上限値に達したか否かを判断する（ステップＳ３１）。ｐ及びｒが条件値に達していない場合には、変更後処理部１１１は、ｐ及びｒを１インクリメントする（ステップＳ３３）。そして処理はステップＳ２３に戻る。
【００６９】
この例では、ｐ＝１及びｒ＝１になると、ステップＳ２３において、運用プロセスを２つ、リソースを１つ追加することになる。ここで、追加運用プロセスとして、ファイアウォール設定及びオートスケールを選択し、追加リソースとして負荷分散ＶＭを選択する。そうすると、クラウドインフラＣ２におけるオートスケールが可能となり、クラウドインフラＣ２についてのファイアウォールが有効化されることになる。
【００７０】
このような場合には、制約充足分析部１１０は、図２３に示すような条件充足時の実装例を変更後処理部１１１に出力する。図２３の例において、点線ａで囲まれる部分は、追加リソースとして負荷分散ＶＭ（ＶＭｅｘ１）と追加運用プロセスとしてオートスケール（Ｐｅｘ１：WebLoadBalance）とを含む。なお、タスクはスケールアップとスケールダウンの２つに分けられている。これによってクラウドインフラＣ２においてオートスケールが可能となる。また、点線ｂで囲まれる部分は、追加運用プロセスとしてファイアウォール設定（Ｐｅｘ２：Firewall）を含む。こちらは１つのファイアウォール設定のタスクのみを含む。その他の部分は、変更後の構成をそのまま示すものである。但し、クラウドインフラＣ１上に、使用しなくなったロードバランサの機能が残っている。
【００７１】
なお、ステップＳ３１で、ｐ及びｒが予め設定された上限値に達した場合には、変更後処理部１１１は、条件を充足するシステム構成及び運用プロセスが特定できない旨のメッセージを出力データ格納部１１２に格納する。そして、出力部１１３は、出力データ格納部１１２に格納された当該メッセージを出力装置に出力する（ステップＳ３５）。そして処理を終了する。
【００７２】
端子Ａを介して図２４の処理の説明に移行して、変更後処理部１１１は、制約充足分析部１１０から受け取った、条件を充足するシステム構成及び運用プロセスのデータを、例えば第２データ格納部１０６に格納する（ステップＳ３７）。
【００７３】
さらに、変更後処理部１１１は、条件を充足するシステム構成及び運用プロセスから、条件を充足しつつ最小構成となるシステム構成及び運用プロセスを探索する（ステップＳ３９）。
【００７４】
より具体的には、条件を充足するシステム構成及び運用プロセスから、運用プロセス又はリソースを削除してみて、その状態で条件を充足するか否かを制約充足分析部１１０に判定させる。例えば総当たり的に削除する運用プロセス又はリソース若しくは両方を選択して、条件を充足しつつ最小構成となるシステム構成及び運用プロセスを特定する。
【００７５】
上で述べた例では、クラウドインフラＣ１上ではＷｅｂＶＭのオートスケールは不要となったので、図２５に模式的に示すように、クラウドインフラＣ１上のオートスケールのための運用プロセス及び機能を削除する状態までは、条件を充足すると判定される。それ以上運用プロセス又はリソースを削除すると、どのような状態についても条件を充足するとは判定されなくなる。
【００７６】
従って、条件を充足しつつ最小構成となるシステム構成及び運用プロセスが検出されない場合には（ステップＳ４１：Ｎｏルート）、処理はステップＳ４５に移行する。
【００７７】
一方、条件を充足しつつ最小構成となるシステム構成及び運用プロセスが検出されると（ステップＳ４１：Ｙｅｓルート）、変更後処理部１１１は、条件を充足しつつ最小構成となるシステム構成及び運用プロセスのデータを、出力データ格納部１１２に格納する（ステップＳ４３）。
【００７８】
そして、出力部１１３は、出力データ格納部１１２に格納されているシステム構成及び運用プロセスのデータ等を読み出して、出力装置に出力する（ステップＳ４５）。そして処理は端子Ｂを介して終了する。
【００７９】
なお、例えば、追加された運用プロセス及びリソースと、ステップＳ３９で削除された運用プロセス及びリソースとを識別可能な形態で示すようにしても良い。例えば、色分けしたり、枠を付すような形であっても良い。
【００８０】
なお、条件を充足する構成が複数特定された場合には、それらを全て出力とするようにしても良い。また、何らかのコストを規定して、条件を充足する構成をコスト順に並べるようにしても良い。
【００８１】
このように、運用管理者は、自身が計画しているシステム変更の可否を事前に検証できるようになる。また、システム変更に伴い必要となるさらなる変更についても自動的に抽出されるようになるので、システム変更の計画見直しに役立てることができるようになる。
【００８２】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。本実施の形態を、例えばクラウド間で初期的なＶＭイメージに差がある場合にも対応することができる。
【００８３】
また、図１に示した機能ブロック構成は一例であって、プログラムモジュール構成とは一致しない場合もある。また、上で述べた処理フローは一例であって、処理結果が変わらない限り、処理順番を入れ替えたり、複数ステップを並列実行するようにしても良い。
【００８４】
なお、上で述べた情報処理装置１００は、コンピュータ装置であって、図２６に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００８５】
以上述べた本実施の形態をまとめると、以下のようになる。
【００８６】
本実施の形態に係る判定方法は、（Ａ）仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、（Ｂ）第１の仮想システムの構成データに基づき、第１の仮想システムで実現される機能に関する機能要件を抽出し、（Ｃ）第１の仮想システムについて用いられる運用プロセスについてのデータと機能要件とに基づき、第１の仮想システムを実現するための運用要件を抽出し、（Ｄ）機能要件及び運用要件と第２の仮想システムの構成要素から特定される制約条件とに基づき、第２の仮想システムへの変更の可否を判定する処理を含む。
【００８７】
このようにすれば、仮想システムの変更について計画を事前に検証できるようになる。すなわち、システム変更に関してユーザの支援が実現される。なお、第２の仮想システムの構成要素から特定される制約条件は、例えば仮想マシンの配備先クラウドが変更になることによって導出されるクラウドについての制約条件である。
【００８８】
上で述べた運用要件を抽出する処理が、（ｃ１）仮想システムに含まれるべき機能についての第１の要件と当該機能に関連して用いられるべき運用プロセスについての第２の要件とを各々含む、運用要件についての複数のパターンから、機能要件と第１の仮想システムについて用いられる運用プロセスについてのデータとに基づき、第１の仮想システムが第１及び第２の要件を満たすパターンを抽出する処理を含むようにしても良い。このような複数のパターンを予め用意することで、容易に運用要件を抽出できるようになる。
【００８９】
さらに、上で述べた判定する処理が、（ｄ１）第２の仮想システムへの変更を、機能要件に適用することで、変更後の機能要件を生成し、（ｄ２）変更後の機能要件及び運用プロセスについてのデータから特定される構成が、運用要件と第２の仮想システムの構成要素から特定される制約条件とを満たすか否かを判定する処理を含むようにしても良い。判定の具体的な手法については、既存の制約充足分析手法（すなわちソルバー）を用いるようにしても良い。
【００９０】
さらに、本判定方法は、（Ｅ）第２の仮想システムへの変更の可否を判定する処理において第２の仮想システムへの変更が否と判定された場合、第２の仮想システムに追加すべき機能と第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれかを探索する処理をさらに含むようにしても良い。例えば、機能又は運用プロセスを漸増させつつ条件充足を判定するような手法が考えられる。このような処理を行えば、第２の仮想システムへの変更には、さらにどのように変更を行うべきかを認識できるようになる。
【００９１】
また、上で述べた探索する処理は、（ｅ１）第２の仮想システムに追加すべき機能と第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれか及び変更後の機能要件及び運用プロセスについてのデータから特定される構成から、運用要件と第２の仮想システムの構成要素から特定される制約条件とを満たす上で影響がない機能と運用プロセスとのうち少なくともいずれかを削除する処理を含むようにしても良い。機能又は運用プロセスを増加させると不要な機能又は運用プロセスが温存される可能性もあるので、例えば機能又は運用プロセスを漸減させつつ条件充足を判定すれば、条件充足に必要十分な構成が得られるようになる。
【００９２】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【００９３】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【００９４】
（付記１）
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出し、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出し、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する
処理を、コンピュータに実行させるための判定プログラム。
【００９５】
（付記２）
前記運用要件を抽出する処理が、
仮想システムに含まれるべき機能についての第１の要件と当該機能に関連して用いられるべき運用プロセスについての第２の要件とを各々含む、運用要件についての複数のパターンから、前記機能要件と前記第１の仮想システムについて用いられる運用プロセスについてのデータとに基づき、前記第１の仮想システムが第１及び第２の要件を満たすパターンを抽出する処理
を含む付記１記載の判定プログラム。
【００９６】
（付記３）
前記判定する処理が、
前記第２の仮想システムへの変更を、前記機能要件に適用することで、変更後の機能要件を生成し、
前記変更後の機能要件及び前記運用プロセスについてのデータから特定される構成が、前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とを満たすか否かを判定する
処理を含む付記１又は２記載の判定プログラム。
【００９７】
（付記４）
前記第２の仮想システムへの変更の可否を判定する処理において前記第２の仮想システムへの変更が否と判定された場合、前記第２の仮想システムに追加すべき機能と前記第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれかを探索する処理
をさらに前記コンピュータに実行させるための付記１乃至３のいずれか１つ記載の判定プログラム。
【００９８】
（付記５）
前記探索する処理は、
前記第２の仮想システムに追加すべき機能と前記第２の仮想システムについて用いられるべき運用プロセスとのうち少なくともいずれか及び前記変更後の機能要件及び前記運用プロセスについてのデータから特定される構成から、前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とを満たす上で影響がない機能と運用プロセスとのうち少なくともいずれかを削除する
処理を含む付記４記載の判定プログラム。
【００９９】
（付記６）
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付け、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出し、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出し、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する
処理を含み、コンピュータが実行する判定方法。
【０１００】
（付記７）
仮想マシンを含む第１の仮想システムから第２の仮想システムへの変更に関する問い合わせを受け付ける入力部と、
前記第１の仮想システムの構成データに基づき、前記第１の仮想システムで実現される機能に関する機能要件を抽出する第１の抽出部と、
前記第１の仮想システムについて用いられる運用プロセスについてのデータと前記機能要件とに基づき、前記第１の仮想システムを実現するための運用要件を抽出する第２の抽出部と、
前記機能要件及び前記運用要件と前記第２の仮想システムの構成要素から特定される制約条件とに基づき、前記第２の仮想システムへの変更の可否を判定する処理部と、
を有する情報処理装置。
【符号の説明】
【０１０１】
１０１  入力部
１０２  入力データ格納部
１０３  第１抽出部
１０４  第１データ格納部
１０５  第２抽出部
１０６  第２データ格納部
１０７  スクリプト格納部
１０８  デザインパターン格納部
１０９  制約データ格納部
１１０  制約充足分析部
１１１  変更後処理部
１１２  出力データ格納部
１１３  出力部
【図１】
2016071562.tif 000003
【図２】
2016071562.tif 000004
【図３】
2016071562.tif 000005
【図４】
2016071562.tif 000006
【図５】
2016071562.tif 000007
【図６】
2016071562.tif 000008
【図７】
2016071562.tif 000009
【図８】
2016071562.tif 000010
【図９】
2016071562.tif 000011
【図１０】
2016071562.tif 000012
【図１１】
2016071562.tif 000013
【図１２】
2016071562.tif 000014
【図１３】
2016071562.tif 000015
【図１４】
2016071562.tif 000016
【図１５】
2016071562.tif 000017
【図１６】
2016071562.tif 000018
【図１７】
2016071562.tif 000019
【図１８】
2016071562.tif 000020
【図１９】
2016071562.tif 000021
【図２０】
2016071562.tif 000022
【図２１】
2016071562.tif 000023
【図２２】
2016071562.tif 000024
【図２３】
2016071562.tif 000025
【図２４】
2016071562.tif 000026
【図２５】
2016071562.tif 000027
【図２６】
2016071562.tif 000028