JP6070706B2 - クラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法、およびクラウドサービス選択プログラム - Google Patents

Description

本発明は、クラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法、およびクラウドサービス選択プログラムに関する。

近年、サーバのコンピューティング資源をクライアントがインターネット等のネットワークを介して利用する形態が研究および開発されている。利用されるコンピューティング資源には、コンピュータの処理装置および記憶装置といったハードウェアと、コンピュータプログラム、ファイル、およびデータといったソフトウェアとが含まれる。このようなコンピューティングの形態は、クラウドコンピューティングと称される。

クラウドコンピューティングが用いられたサービスは、様々なクラウドサービス事業者によって提供されている。クラウドサービス事業者により提供されるサービスには、例えば、Software as a Services（ＳａａＳ）、Platform as a Services（ＰａａＳ）、およびInfrastructure as a Services（ＩａａＳ）がある。

ＳａａＳは、クラウドサービス事業者が各種のアプリケーションソフトウェアをネットワークを介して利用者に提供するサービスである。ＰａａＳは、クラウドサービス事業者がアプリケーションの開発、実行、および運用の環境、ならびにユーティリティソフトウェアをネットワークを介して利用者に提供するサービスである。例えば、ＩａａＳは、クラウドサービス事業者がサーバ、ストレージ、Operating System（ＯＳ）、およびミドルウェア等のシステム資源をネットワークを介して利用者に提供するサービスである。

上述のようなクラウドコンピューティングを用いて提供されるサービスの品質および料金体系は、クラウドサービス事業者によって異なり得る。そこで、利用者は、クラウドコンピューティング上で稼動させたい業務内容とクラウド事業者が提供するサービスの品質および料金体系とを考慮して、様々なクラウドサービス事業者が提供するサービスの中から適切と考えるサービスを選択する。

なお、アウトソーシング導入支援装置に関する次のような技術が知られている。アウトソーシング導入支援装置は、ネットワークを介してユーザ端末からアクセスを受けると、コンサルティング、運用、およびサービスレベル・アグリーメント（ＳＬＡ）の決定に必要な項目をユーザ端末上に表示させる。これらの項目に対する情報がユーザ端末装置により入力されると、アウトソーシング導入支援装置は、運用設計レベル定義ファイル、高運用設計ガイドラインファイル、ＳＬＡ品質ファイル、および価格リストファイルを用いて、入力された情報を解析する。アウトソーシング導入支援装置は、解析結果に従って作成されたコンサルティング資料および運用見積書をユーザ端末に送信する。

仮想化装置およびクラウド連携管理装置を有する複数のクラウドシステムがネットワークを介して接続されたシステムに関する次のような技術が知られている。各クラウドシステムのクラウド連携管理装置は、自クラウドシステムの上位システム構成情報、上位システム手順データ、リソース情報、ＣＰＵアーキテクチャ情報、ＯＳ情報、および料金情報を連携情報として他のクラウドシステムのクラウド連携管理装置と交換し、交換された連携情報を記録部に記憶する。あるクラウドシステムのクラウド連携管理装置は、クラウド間移行指示と移行対象の上位システムのＩＤを含むコマンドとを受信すると、コマンドに含まれる上位システムのＩＤをキーにして記憶部に記憶されている関連上位システム構成情報を特定する。そして、クラウド連携管理装置は、特定された関連上位システム情報から移行先となり得る他のクラウドシステムのクラウド連携装置のＩＤのリスト、またはそれらのＩＤのリストにより特定される他のクラウドシステムの名称のリストを移行候補先情報として出力する。クラウド連携管理装置は、出力された移行先候補情報の中から移行先のクラウドシステムがユーザにより選択されると、上位システムのＩＤ、自装置のＩＤ、およびクラウド間移行の移行先手順の実行指示を移行先のクラウドシステムのクラウド連携管理装置に送信する。移行先のクラウドシステムのクラウド連携管理装置は、移行先手順の実行指示を受信すると、移行先手順の実行を開始する。

交差階層効率管理システムに関する次のような技術が知られている。交差階層管理システムのデータベースは、多重階層および多重階層間の交差階層に記憶された効率管理データ、および交差階層に設定された効率管理目標を備える。交差階層効率管理システムは、ポートフォリオ・ビュー・セレクションをオペレータから取得すると、ポートフォリオ・ビュー・セレクションにより特定される効率管理データの一部を検索する。交差階層効率管理システムは、交差管理目標を含む検索された効率管理データをポートフォリオ・ビューとして与える。

クラウドフェデレーションに関する次のような技術が知られている。クラウドフェデレータは、契約したクラウドクライアントが異なるクラウドにより提供されるサービスへシームレスにアクセスするために必要なフェデレーションプロファイルを提供する。

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

稼動させる業務の特性に適し、利用者のポリシーを反映した低価格のクラウドサービスを複数のクラウドサービスの中から迅速かつ効率的に選択する。

一実施形態に従ったクラウドサービス選択装置は、クラウド事業者データベース、業務データベース、最適サービス選択部、実効性能取得部、および業務特性収集・分析部を含む。クラウド事業者データベースには、クラウドサービス提供装置によって不特定多数人を対象に提供される複数のクラウドサービスそれぞれの性能指標、付加価値、および料金を含むデータが登録される。業務データベースには、クラウド事業者データベースに登録された複数のクラウドサービスの内の１つのクラウドサービスを用いて稼動される業務の要求性能、付加条件、および利用者ポリシーを含むデータが登録される。最適サービス選択部は、性能指標が要求性能を満たす最適クラウド候補を複数のクラウドサービスの中から抽出し、料金と付加条件および付加価値の一致度とに対して利用者ポリシーによる重み付けを行った評価指標を抽出された最適クラウド候補について算出し、算出された評価指標の最も高い最適クラウド候補を業務に用いられるクラウドサービスとして選択する。実効性能取得部は、クラウド事業者データベースに登録されたクラウドサービスを提供するクラウドサービス提供装置へダミー業務を展開して実行させて測定した該クラウドサービスの実際の性能についての測定結果を取得する。業務特性収集・分析部は、クラウド事業者データベースに登録されたクラウドサービスが用いられて業務が稼働されているときに、業務の稼働データを取得し、取得された稼動データに基づいて業務の要求性能を分析する。最適サービス選択部は、実効性能取得部により取得された性能についての測定結果を用いて性能指標を補正し、補正された性能指標を用いて、業務特性収集・分析部により分析された要求性能を満たす最適クラウド候補であって、且つ、評価指標の最も高い最適クラウド候補を選択する。

実施形態に従えば、稼動させる業務の特性に適し、利用者のポリシーを反映した低価格のクラウドサービスを複数のクラウドサービスの中から迅速かつ効率的に選択することができる。

第１の実施形態に従ったクラウドサービス選択システムの構成図である。 実施形態に従った業務データベースの例図である。 実施形態に従ったクラウド事業者データベースの例図である。 実施形態に従った第１の業務特性収集方法の説明図である。 実施形態に従った第２の業務特性収集方法の説明図である。 実施形態に従った業務特性収集・分析処理フローの例図である。 実施形態に従った業務特性収集・分析処理フローの説明図である。 実施形態に従ったクラウドサービス選択処理フローの例図である。 実施形態に従った最適サービス選択処理フローの例図である。 実施形態に従った業務稼動の可否確認画面の一例である。 実施形態に従った要求性能更新処理フローの例図である。 実施形態に従った未稼働業務に対する要求性能更新処理の説明図である。 実施形態に従ったマイグレーションの可否確認画面の一例である。 実施形態に従った稼働済み業務に対する要求性能更新処理の説明図である。 第２の実施形態に従ったクラウドサービス選択システムの構成図である。 実行性能測定用のダミー業務の例図である。 実施形態に従った実効性能取得処理フローの例図である。 実効性能データを含むクラウド事業者データベースの例図である。 第３の実施形態に従ったクラウドサービス選択システムの構成図である。 第３の実施形態に従ったクラウド事業者データベースの例図である。 第６の実施形態に従ったクラウドサービス選択システムの構成図である。 クラウド事業者データベースに格納されたプライベートクラウドの例図である。 第７の実施形態に従ったクラウドサービス選択プログラムを実行するコンピュータのハードウェア構成図である。

以下図面を参照しながら実施形態を詳細に説明する。
なお、以下の説明において、用語「クラウド」は、断りがない限り、ネットワークを介して不特定多数の一般利用者を対象に提供されるクラウドサービス、すなわち、パブリッククラウドを指す。

＜第１の実施形態＞
数々のクラウドサービス事業者は、異なるサービス品質と異なる料金体系で、ＩａａＳ等のクラウドを利用者に提供している。サービス品質とは、狭義の意味では、稼働率の指標であるService Level Agreement（ＳＬＡ）を指すが、広義の意味では、サービス品質には、サービスの性能とサービスの機能が含まれる。サービスの性能とは、例えば、ＯＳのインスタンスあたりの仮想ＣＰＵのコア数およびクロック数、メモリ容量、ネットワーク帯域、およびストレージ容量等である。ＩａａＳでは、貸し出し単位は、物理または仮想マシンのＯＳのインスタンス単位である。また、サービスの機能とは、例えば、ＯＳの種類、Application Program Interface（ＡＰＩ）の提供、システム監視、ＯＳイメージのコピー、ならびにＯＳイメージおよびストレージを含めたデータのバックアップ等である。

また、クラウドサービス事業者の中には、例えば、サービスの価格対性能比において、ＣＰＵの処理能力が割安なことを売りにしている事業者、メモリ容量が割安なことを売りにしている事業者、ネットワーク帯域が割安なことを売りにしている事業者等が存在し得る。また、クラウドサービス事業者が提供するクラウドの中には、例えば、データ転送量に利用料金が依存しない定額制のサービスや、データ転送量毎に課金する従量制のサービス等が存在し得る。

一方、利用者には、稼動させたい業務の要求仕様と各クラウドサービス事業者が提供するクラウドのサービス品質および料金体系とを比較して、低価格であって業務の稼動に最適なクラウドを選択したい要求がある。

具体的には、利用者がクラウドを利用して稼働させたい業務に要求されるサービス品質は、その業務内容に応じて異なる。例えば、ある業務ではＣＰＵの処理能力が高くなくてはならず、ある業務ではメモリが大容量でなくてはならず、また、ある業務ではネットワーク帯域が広くなくてはならない等である。そこで、利用者には、稼動させたい業務に要求されるサービス品質を備えたクラウドの中から低価格なクラウドを選択したいという要求がある。

また、稼動させた業務の特性が時系列に従って変化する場合には、上述のような利用者の要求を満足する最適なクラウドは、時系列に従って変化し得る。そこで、利用者には、業務の稼動に最適な低価格のクラウドを適宜利用するために、稼働中のシステムを最適な別のクラウドへマイグレーションしたいという要求がある。

さらに、利用者には、稼動させたい業務の要求仕様と各サービス事業者が提供するクラウドのサービス品質および料金体系との比較といった上述のようなコストパフォーマンス以外の観点で、業務の稼動に最適なクラウドを選択したい要求があり得る。すなわち、利用者には、上述のようなコストパフォーマンスの観点の他に、クラウドサービスが有する付加価値を加味して、業務の稼動に最適なクラウドを選択したい要求がある。

クラウドサービスが有する付加価値とは、例えば、クラウドサービス事業者の信頼性が高い、クラウドサービス事業者のホームページで多国語表示がサポートされている、トラブル発生時に電話問い合わせが可能である、クラウドサービス事業者が有するシステムの信頼性が高い、および応答性能がよい等である。システムの信頼性が高いとは、例えば、ＳＬＡで示す稼働率が高い、High Availability（ＨＡ）によるハードウェア耐障害性機能がある等である。応答性能がよいとは、クラウド上で業務を動作させるクライアントの物理的な設置場所と、クラウドが動作するサーバの物理的な設置場所とが地理的に近いことによって、通信経路長に依存したレイテンシが少ないことを指す。また、稼動させたい業務が法令等により国外への持ち出しができない業務である場合には、クライアントと同一国内で提供されるクラウドであることは付加価値となる。

第１の実施形態では、クラウドサービス事業者が提供する様々なクラウドの中から、上述したような利用者の要求を満たすクラウドを選択するクラウドサービス選択装置、クラウドサービス選択システム、およびクラウドサービス選択方法が提供される。また、稼動させた業務の特性に従って上述したような利用者の要求を満たす別のクラウドを再選択するクラウドサービス選択装置、クラウドサービス選択システム、およびクラウドサービス選択方法が提供される。

図１は、第１の実施形態に従ったクラウドサービス選択システムの構成図である。
図１に示すように、第１の実施形態に従ったクラウドサービス選択システム１００は、クラウドサービス選択装置１１０、ｎ個（ｎは２以上の任意の整数）のクラウドサービス提供装置１２０ａ〜１２０ｎ、およびインターネット等のネットワーク１３０を含む。クラウドサービス選択装置１１０は、ネットワーク１３０を介してクラウドサービス提供装置１２０ａ〜１２０ｎと接続する。なお、以下の説明においてクラウドサービス提供装置１２０ａ〜１２０ｎを特に区別しない場合には、クラウドサービス提供装置１２０と記載する。

クラウドサービス提供装置１２０は、各クラウドサービス事業者がクラウドを提供するためのコンピュータハードウェア（サーバ）であり、Central Processing Unit（ＣＰＵ）等のプロセッサ、メモリ、およびストレージ等を含む。また、クラウドサービス提供装置１２０には、クラウドサービス選択装置１１０にクラウドを提供するためのアプリケーションソフトウェア、ファイル、およびデータ等の各種のコンピュータソフトウェアが含まれる。

図１に示したクラウドサービス選択装置１１０に含まれる各構成要素を説明する。
クラウドサービス選択装置１１０は、記憶装置１１１、プロセッサ１１２、情報入力部１１３、および情報出力部１１４を含む。

記憶装置１１１は、例えば、Random Access Memory（ＲＡＭ）等の主記憶装置、およびハードディスク（Hard Disk Drive、ＨＤＤ）等の補助記憶装置である。

記憶装置１１１には、業務データベース（ＤＢ）１１１ａ、業務マスタデータ格納部１１１ｂ、およびクラウド事業者データベース１１１ｃが含まれる。

業務データベース１１１ａは、クラウドを用いて稼働させる業務を管理するための管理データを格納するデータベースである。

図２は、実施形態に従った業務データベースの例図である。
図２に示すように、業務データベース１１１ａのテーブルには、業務Identification Data（ＩＤ）、要求性能初期値、要求性能現在値、要求性能調整値、付加条件、業務特性、ポリシー、格納パス、および稼働中サービス情報の各データが含まれる。

業務ＩＤは、クラウド上で稼働させる個々の業務を識別するためのＩＤである。図２に示した業務データベース１１１ａの一例では、Ｂ１〜Ｂｍ（ｍは２以上の任意の整数）の業務ＩＤが含まれる。

要求性能は、業務ＩＤで識別された当該業務を稼動させるためにクラウドに要求される性能である。図２に示した一例では、要求性能には、ＣＰＵのクロック数／コア数、主記憶装置のメモリ容量、ネットワーク帯域、補助記憶装置のストレージ容量、および動作ＯＳ等のパラメータが含まれる。

図２に示すように、要求性能に関するデータには、要求性能初期値、要求性能現在値、および要求性能調整値がある。

要求性能初期値は、クラウドで稼動させる業務を業務データベース１１１ａに登録する時に利用者が情報入力部１１３を介して設定した要求性能の値である。要求性能初期値は、例えば、利用者が業務に要求されると判断した値が設定される。

要求性能調整値は、クラウドでの稼動中に収集された当該業務の業務特性が設定閾値を超え、業務特性が異常であると判定された場合に、実施形態に従った業務特性収集・分析方法に従って業務特性の異常性が解消される値として計算された要求性能の値である。実施形態に従った業務特性収集・分析方法については後述する。クラウドでの稼動後に当該業務の業務特性の正常性が維持されている場合には、当該業務に対応する要求性能調整値は、未設定を示すデフォルト値が設定される。

要求性能現在値は、未稼働時または稼働中等の当該業務に現在要求される要求性能の値である。例えば、クラウドでの稼働中に業務特性が異常であると判定された業務に対して、要求性能調整値に基づき最適とされる別なクラウドが再選択された場合には、要求性能調整値が要求性能調整値にコピーされる。

図２に示した業務データベース１１１ａの一例では、業務ＩＤがＢ１の業務に対応する要求性現在値および要求性能調整値は、未設定を示すデフォルト値が設定されている。例えば、業務データベース１１１ａに登録された直後においては、当該業務に対応する要求性能現在値および要求性能調整値は、未設定を示すデフォルト値が設定される。

付加条件は、当該業務に利用されるクラウドに対して付加価値として備えることが要求される条件である。図２に示した業務データベース１１１ａの一例では、システムの信頼性、言語、サポート、および稼働地域が設定される。図２に示すように、システムの信頼性については、条件を指定しないことを示す「通常」や、「ＳＬＡ≧99.95」といった条件が設定される。「通常」を示す値が当該業務に対応して設定された場合には、任意のクラウドが当該業務の選択候補となり、「ＳＬＡ≧99.95」といった条件が設定された場合には、設定された条件を満たすクラウドが当該業務の選択候補となる。また、サポートには、電話対応＞メール対応＞掲示板対応といった順列に従って付加条件が設定される。例えば、当該業務に対応するサポート条件に「メール対応」が設定された場合には、掲示板対応のクラウドは当該業務の選択候補とならないが、電話対応のクラウドは当該業務の選択候補となる。それぞれの付加条件は、当該業務に利用されるクラウドに対して必ず要求される必須条件として設定されてもよいし、任意条件として設定されてもよい。

業務特性は、クラウドで稼働中の業務に対する稼動状態を表すデータである。図２に示すように、例えば、クラウドサービスが正常であること、ＣＰＵのボトルネック発生率が平均９０％であること、およびメモリリソースが平均５０％余剰であることといった業務特性が記録される。また、未稼働の業務では、未採取を示すフラグが設定される。

ポリシーには、業務の稼動に用いられるクラウドを選択する際の利用者の方針が設定される。図２に示した業務データベース１１１ａの一例では、ポリシーには、最適なクラウドとして選択する際の優先項目を示す最適化と、利用中のクラウドから別のクラウドへのマイグレーションの実行に関する挙動が含まれる。図２に示した一例では、コストおよび応答性能が最適化として設定され、強制的なマイグレーション、猶予期間後の自動的なマイグレーション、および管理者（利用者）の指示待ち等が挙動として設定される。

格納パスは、当該業務のデータが格納される業務マスタデータ格納部１１１ｂのディレクトリ構造上の位置を示す情報である。

稼働中サービス情報には、業務の稼動に利用中のクラウドサービスを識別するためのサービスＩＤ（Service ID）、Internet Protocol（ＩＰ）アドレスのタイプ(AddrType)、ＩＰアドレス(Addr)、およびアカウント(ID,PW)が含まれる。当該業務が未稼働である場合、対応する稼動中サービス情報には、未割当を示すフラグが設定される。ＩＰアドレスは、クラウドで業務を稼働させる際にクラウド事業者から付与される。稼働中サービス情報は、利用者が当該業務のＯＳを利用するために必要な情報であり、後述するように、業務特性収集・分析部１１２ａ等が利用中のクラウドのサーバ（クラウドサービス提供装置１２０）にアクセスするためにも利用される。

図２に示した業務データベース１１１ａにおいて、業務ＩＤ、要求性能初期値、付加条件、およびポリシーに関するデータは、当該業務をクラウドで稼動させる前に、情報入力部１１３を用いて利用者により登録され得る。これらのデータが登録された後、実施形態に従ったクラウドサービス選択処理が実行されると、要求性能初期値がコピーされた要求性能現在値が設定される。また、クラウドでの当該業務の稼動後には、業務特性収集・分析部１１２ａ、制御部１１２ｂ、および最適サービス選択部１１２ｃによって要求性能現在値、要求性能調整値、業務特性、格納パス、および稼働中サービス情報が設定され得る。

図１に示したクラウド事業者データベース１１１ｃには、クラウドサービス事業者とクラウドサービス事業者が提供するクラウドとを選択するための判断材料となるデータが格納される。

図３は、実施形態に従ったクラウド事業者データベースの例図である。
図３に示すように、クラウド事業者データベース１１１ｃは、事業者ＩＤ、クラウド事業者名、アブストラクタＩＤ、サービスＩＤ、サービス名、性能指標、付加価値、および料金を含む。

事業者ＩＤは、クラウド事業者データベース１１１ｃに登録されたクラウドサービス事業者を識別するためのＩＤである。クラウド事業者名は、事業者ＩＤが付されたクラウドサービス事業者の名前である。

アブストラクタＩＤは、アブストラクタ１１２ｄに接続するためのＩＤである。後述するように、アブストラクタ１１２ｄは、クラウドサービス提供装置１２０によって異なるインタフェースの差分を吸収する。

サービスＩＤは、クラウドサービス事業者によって提供されるクラウドを識別するためのＩＤである。また、サービス名は、サービスＩＤが付されたクラウドの名前である。クラウドサービス事業者によっては、複数のクラウドサービスが提供され得る。その一例としては、クラウドサービス事業者が提供するサーバ（クラウドサービス提供装置１２０）の性能に数段階のランクを設け、それぞれの性能に対して料金を設定する、または異なる課金プランを設定する等が挙げられる。したがって、クラウド事業者データベース１１１ｃには、同一の事業者ＩＤに対応し、且つ互いにユニークなサービスＩＤを有する複数のエントリが存在し得る。

料金は、クラウドの利用料金に関するデータである。図３に示した一例では、料金が従量制か定額制といった課金、課金の単位、基本利用料、およびデータ転送量あたりの料金が含まれる。

性能指標は、クラウドサービス事業者が公表する当該クラウドサービスの性能である。図３に示した一例では、ＣＰＵのクロック数／コア数、主記憶装置のメモリ容量、ネットワーク帯域、補助記憶装置のストレージ容量、および動作ＯＳが含まれる。

付加価値は、前述したようなクラウドサービス事業者が提供するクラウドが有する付加価値である。図３に示した一例では、信頼性、言語、サポート、および事業者地域が含まれる。

クラウド事業者データベース１１１ｃに含まれる事業者ＩＤ、クラウド事業者名、アブストラクタＩＤ、サービスＩＤ、サービス名、性能指標、付加価値、および料金は、例えば、情報入力部１１３を用いて利用者により登録され得る。

図１に示した業務マスタデータ格納部１１１ｂは、システム設定、アプリケーション、およびアプリケーションが処理する業務データといった、個々の業務が持つデータを格納するための記憶装置１１１の格納領域である。ある業務がクラウドのインスタンス（クラウドサービス提供装置１２０）上に展開される際には、アブストラクタ１１２ｄを介して個々の業務が持つこれらのデータが業務マスタデータ格納部１１１ｂからインスタンスへコピーされる。また、業務マスタデータ格納部１１１ｂには、ある業務に対してクラウドの利用が一時的に中止される場合、異なるクラウド間をマイグレーションさせる場合、および、万が一クラウドサービス提供装置が故障した場合に備えてクラウドのインスタンスからバックアップされたデータが格納される。

図１のプロセッサ１１２は、ＣＰＵ等の処理装置である。プロセッサ１１２は、業務特性収集・分析部１１２ａ、制御部１１２ｂ、最適サービス選択部１１２ｃ、アブストラクタ１１２ｄ、ｎ個の個別クラウドサービス提供装置用プラグイン１１２ｅ−ａ〜１１２ｅ−ｎを含む。なお、以下の記載においてｎ個の個別クラウドサービス提供装置用プラグイン１１２ｅ−ａ〜１１２ｅ−ｎを特に区別しない場合には、単に個別クラウドサービス提供装置用プラグイン１１２ｅと記載する。

業務特性収集・分析部１１２ａは、クラウドで稼働中の業務の業務特性を収集および分析する。

業務をクラウドで実際に稼動させた場合、設計段階で当該業務に必要と考えられた要求性能と、実際に当該業務をクラウド上で稼動させた場合に当該業務に必要とされる要求性能との間に差異が生じ得る。

例えば、当該業務の稼動に必要と考えられた要求性能を満たす性能指標を有するクラウドが設計段階で選択された場合であっても、選択されたクラウドで当該業務を稼働させると、クラウドサービス提供装置１２０のリソースにボトルネックが発生したり、リソース余りが発生したりし得る。リソースにボトルネックが発生している場合、その業務が本来の目的を果たせていない可能性があるため、当該リソースよりも上位ランクのリソースを提供するクラウドへの変更が検討される余地がある。一方、パブリッククラウドでは、その性質上、基本料金の範囲ではリソースの利用率が何％でも料金が同じであり得る。そこで、リソース余りが発生している場合には、当該リソースよりも下位ランクのリソースを提供するクラウドへの変更が検討される余地がある。

このように、利用中のクラウドが当該業務の稼動にとって適切ではないと判断された時点で、より適切なクラウドが再選択されることが望ましい。業務特性収集・分析部１１２ａは、業務の稼働実態に応じてより適切なクラウドが選択されるための判断データとなる業務特性を収集および分析する。

実施形態に従った業務特性収集・分析部１１２ａは、以下の二つの方法によって、クラウドで稼働中の業務の稼動データを収集する。

第１の業務特性収集方法は、エージェントソフトウェアによる方法である。
図４は、実施形態に従った第１の業務特性収集方法の説明図である。なお、説明を明確にするために、図４には、図１に示したクラウドサービス選択システム１００の構成要素の一部のみが示されている。

ある業務Ｂｘ（ｘ＝１〜ｎ）をクラウドサービス提供装置１２０のインスタンスで稼動させる時に、制御部１１２ｂは、業務マスタデータ格納部１１１中の当該業務Ｂｘの業務データをインスタンスにコピーする共に、業務特性収集のためのエージェントソフトウェアをインスタンスにインストールする。インストールされたエージェントソフトウェアは、クラウドサービス提供装置１２０のインスタンスのＯＳ上でそれぞれ稼動し、各計算リソースの利用率等の稼動データを収集する。エージェントソフトウェアは、収集された稼動データを業務特性収集・分析部１１２ａにそれぞれ送信する。

第１の業務特性収集方法によれば、クラウドサービス事業者がＡＰＩを有するか否かに関わらず業務特性データを収集できる。

第２の業務特性収集方法は、クラウドサービス提供装置１２０が提供するＡＰＩの利用による方法である。
図５は、実施形態に従った第２の業務特性収集方法の説明図である。なお、説明を明確にするために、図５には、図１に示したクラウドサービス選択システム１００の構成要素の一部のみが示されている。

第２の業務特性収集方法は、監視サービスの機能としてまたは課金のためのデータとして計算リソースの利用状況をクラウドサービス提供装置１２０が保有しており、保有されたデータがＡＰＩから取得可能とされている場合に用いられる方法である。業務特性収集・分析部１１２ａは、クラウドサービス提供装置１２０が提供するＡＰＩを利用して、クラウドサービス提供装置１２０が保有する稼動データを取得する。業務特性収集・分析部１１２ａが稼動データの取得をクラウドサービス提供装置１２０に要求する際には、クラウドサービス提供装置１２０毎に異なるＡＰＩのコマンドが、業務データベース１１１ａの稼働中サービス情報として格納されたＩＰアドレスおよびアカウント情報が用いられてアブストラクタ１１２ｄを介して発行される。

業務特性収集・分析部１１２ａは、当該業務に利用中のクラウドの特定の計算リソースでボトルネックが発生している部分がないか、あるいは特定の計算リソースが余っていないかを収集された稼動データを用いて分析する。例えば、業務特性収集・分析部１１２ａは、あるリソースの利用率の推移が１００％に恒久的にまたは間欠的に張り付いていることを示す稼動データから、当該リソースでボトルネックが発生していると分析する。

第１の業務特性収集方法および／または第２の業務特性収集方法により収集および分析された当該業務に対する稼動状態を表すデータ、すなわち当該業務の業務特性は、業務データベース１１１ａの当該業務のエントリの業務特性の列に業務特性収集・分析部１１２ａにより格納される。図２を参照しながら前述したように、業務特性には、「正常」、「CPUボトルネック発生(平均９０％)」、および「メモリリソース余り(平均３０％)」といったように、クラウドで稼働中の当該業務に対する稼動状態が記録される。

また、業務特性収集・分析部１１２ａは、収集および分析された業務特性に異常がある場合には、業務特性の異常が解消されるために必要な要求性能を分析し、分析された要求性能を業務データベース１１１ａの要求性能調整値として格納する。この結果、要求性能調整値には、例えば、ＣＰＵのボトルネックであれば、より高性能なＣＰＵが設定され、メモリリソース余りであれば、より小さな容量のメモリが設定される。

なお、業務データベース１１１ａは、例えば、業務特性が特定の曜日毎に異なる場合で、かつ曜日毎に最適なクラウドの再選択が可能な場合には、曜日毎の業務特性および要求性能調整値のデータが保持されるように設定されてよい。同様に、年間の季節変動がある場合には、業務データベース１１１ａは、月次や四半期毎のデータが保持されるように設定されてよい。

図１に示した最適サービス選択部１１２ｃは、当該業務に要求されるサービス品質を有し、且つ低価格であるクラウドを実施形態に従った最適サービス選択方法に従って選択する。実施形態に従った最適サービス選択方法の一例は以下の通りである。

まず、最適サービス選択部１１２ｃは、当該業務の要求性能を満たすすべてのクラウドをクラウド事業者データベース１１１ｃから抽出する。未稼働の業務では、業務データベース１１１ａ中の業務特性データが未採取であるため、要求性能初期値として設定された要求性能を満たすクラウドが抽出される。一方、稼動済みの業務では、業務特性収集・分析部１１２ａによって業務データベース１１１ａに格納された業務特性が存在する場合には、業務特性に応じた要求性能調整値として設定された要求性能を満たすクラウドが抽出され得る。

次に、最適サービス選択部１１２ｃは、料金（価格）の安さ、および当該業務の付加条件とクラウドが提供する付加価値との一致度に対して、最適化ポリシーによる重み付けをそれぞれ行った評価指標の算出を抽出されたすべてのクラウドについて行う。そして、最適サービス選択部１１２ｃは、算出された評価指標の中で評価指標の最も優れたクラウドを選択する。

評価指標の算出に用いられる最適化ポリシーとは、図２に示した一例では、コストや応答性能である。例えば、業務の性質によっては与えられた予算内でベストエフォートで稼働することが求められる。このような業務に対しては、最適化ポリシーとして「コスト」が業務データベース１１１ａに設定されることによって、料金の安さが評価指標により大きく反映されるようにする。この結果、与えられた予算内で最適なクラウドサービスを選択することができる。

また、評価指標の算出に用いられる料金の計算に従量課金制リソースの使用量の予測値が用いられる場合には、例えば、稼動実績のない業務では、業務エントリが初期値として入力された際に指定された従量課金制リソースの使用量の予測値が従量課金制リソースの使用量の予測値として用いられる。一方、業務データベース１１１ａに格納された業務特性が利用可能な場合は、リソース使用量の実績として格納されている業務特性が従量課金制リソースの使用量の予測値として用いられる。

なお、上述した最適サービス選択方法は、実施形態の最適サービス選択方法の一例にすぎず、様々な変形が可能である。例えば、当該業務の付加条件が必須条件と付加条件に分けられて登録されている場合には、最適サービス選択部１１２ｃは、当該業務の要求性能および必須条件を満たすすべてのクラウドをクラウド事業者データベース１１１ｃから抽出してもよい。また、最適サービス選択部１１２ｃは、料金の安さ、および当該業務の任意の付加条件とクラウドが提供する付加価値との一致度に対して、最適化ポリシーによる重み付けをそれぞれ行った評価指標の算出を抽出されたすべてのクラウドについて行ってもよい。

図１に示した制御部１１２ｂは、クラウドサービス選択装置１１０に含まれる各構成要素に対して指令を出して、クラウドサービス選択装置１１０全体の処理を統括する。制御部１１２ｂが実行する処理には、例えば、最適サービス選択部１１２ｃが実行する最適サービス選択処理の起動、マイグレーションの可否についての情報出力部１１４を介した利用者への問い合わせ、および業務マスタデータ格納部１１１ｂ中の業務イメージのクラウドサービス提供装置１２０上への展開がある。

図１に示したアブストラクタ１１２ｄは、異なるインタフェースおよびアクセス先を持つクラウドサービス提供装置１２０を共通のインタフェースで扱えるように、その差分を吸収するユニットである。

各クラウドサービス提供装置１２０は、利用者の契約処理の簡易化および自動化等の目的から、契約手段や、課金データの通知、およびユーザIDやパスワードの通知といった画面やデータの送受信手段等の各機能に対応したＡＰＩを提供している。こうしたＡＰＩは、異なるクラウドサービス提供装置１２０間で標準化されたものであり得、また、当該クラウドサービス提供装置１２０独自のものであり得る。アブストラクタ１１２ｄは、このようなＡＰＩを利用して、異なるクラウドサービス提供装置１２０により提供されたすべてのクラウドサービスをクラウドサービス選択装置１１０が同じインタフェースで透過的に利用できるようにする。

アブストラクタ１１２ｄは、例えば、ある業務を稼働させるクラウドのインスタンスが新たに作成される場合や、ある業務がクラウドサービス提供装置１２０が異なるクラウドへマイグレーションされる場合に用いられる。

図１に示した個別クラウドサービス提供装置用プラグイン１１２は、個別のクラウドサービス提供装置１２０へアクセスするためのインタフェースを提供するユニットである。

図１に示した情報入力部１１３は、クラウドサービス選択装置１１０に対する設定や指示といった利用者による入力を受け付けるユニットである。情報入力部１１３は、例えば、キーボードおよびマウス等である。

図１に示した情報出力部１１４は、プロセッサ１１２による処理結果を表示するユニットである。情報出力部１１４は、例えば、液晶ディスプレイである。

上述した構成要素を含むクラウドサービス選択装置１１０の処理動作を以下に説明する。
まず、クラウドサービス選択装置１１０により実行される実施形態に従った業務特性収集・分析処理の一例を図６および図７をさらに参照しながら説明する。

図６は、実施形態に従った業務特性収集・分析処理フローの例図である。図７は、実施形態に従った業務特性収集・分析処理フローの説明図である。

業務特性収集・分析部１１２ａは、業務特性収集・分析処理を開始すると（ステップｓ１０１）、業務データベース１１１ａに登録された業務Ｂ１、Ｂ２、・・・・Ｂｍについて、ステップｓ１０３〜ステップｓ１０７の処理をそれぞれ行う（ステップｓ１０２）。例えば、業務特性収集・分析部１１２ａは、業務データベース１１１ａ中の行番号が小さい順に（図２の一例では、業務Ｂ１から順番に）、ステップｓ１０３〜ステップｓ１０７の処理を行う。

ステップｓ１０３では、業務特性収集・分析部１１２ａは、業務Ｂｘ（ｘは１からｍまでの任意の整数）がクラウドで稼働中であるか否かを判定する。

クラウドで業務Ｂｘが稼動していないと判定された場合（ステップｓ１０３で“ＮＯ”）、業務特性収集・分析部１１２ａは、当該業務Ｂｘに対する業務特性収集・分析処理を終了し、ステップｓ１０８に処理を進める。

一方、クラウドで業務Ｂｘが稼動中であると判定された場合（ステップｓ１０３で“ＹＥＳ”）、業務特性収集・分析部１１２ａは、図４を参照しながら前述した第１の業務特性収集方法（エージェントソフトウェアによる方法）によって業務Ｂｘの稼動データを収集する。あるいは、業務特性収集・分析部１１２ａは、図５を参照しながら前述した第２の業務特性収集方法（クラウドサービス提供装置１２０が提供するＡＰＩの利用による方法）によって業務Ｂｘの稼動データを収集する（ステップｓ１０４）。

ステップｓ１０４において業務特性収集・分析部１１２ａにより収集される稼動データは、例えば、業務Ｂｘがクラウドで稼動している間のＣＰＵ使用率、メモリ使用量、ディスク使用量、およびネットワーク転送量等の履歴データである。

業務特性収集・分析部１１２ａは、ステップｓ１０４で収集された稼動データと、業務特性の正常性判定基準としてリソース毎に予め定められた閾値とを比較し、業務特性が正常か否かをリソース毎に判定する。

例えば、平均ＣＰＵ使用率の正常範囲を示す下限閾値２０％および上限閾値６０％が予め情報入力部１１３を介して設定されたと仮定する。この仮定のケースでは、業務特性収集・分析部１１２ａは、収集されたＣＰＵ使用率の平均値が上限閾値６０％を超えるならばＣＰＵでボトルネック発生、すなわちＣＰＵの業務特性が異常であると判定する。また、業務特性収集・分析部１１２ａは、収集されたＣＰＵ使用率の平均値が下限閾値２０％未満ならばＣＰＵのリソース余り、すなわちＣＰＵの業務特性が異常であると判定する。例えば、ＣＰＵ使用率９０％以上の状態が継続して３０分以上発生した回数が一日に２回であることが閾値として設定されていたケースでは、業務特性収集・分析部１１２ａは、収集されたＣＰＵ使用率がこの閾値を超えるならば、ＣＰＵでボトルネック発生と判定する。

業務特性収集・分析部１１２ａによるリソース毎の業務特性が正常か否か判定処理は、上述した例に限られず、また、複数の判定条件が組み合わされてもよい。また、業務データベース１１１ａに登録されたすべての業務に適合する標準的な判定条件が予め設定されてもよいし、業務毎に異なる判定条件が設定されてもよい。

業務特性収集・分析部１１２ａは、上述のような判定処理により得られた判定結果データを業務データベース１１１ａ中の業務Ｂｘのエントリの「業務特性」の列に格納する（ステップｓ１０５）。図７に示した業務データベース１１１ａの一例では、業務ＩＤＢｘのエントリの「業務特性」の列に、「ＣＰＵボトルネック発生（平均９０％）」および「メモリリソース余り（平均５０％）」が格納される。

ステップｓ１０５において格納される業務特性が正常を示すデータである場合（ステップｓ１０６で“ＮＯ”）、業務特性収集・分析部１１２ａは、当該業務Ｂｘに対する業務特性収集・分析処理を終了し、ステップｓ１０８の処理に進む。

一方、ステップｓ１０５において格納される業務特性が異常を示すデータである場合（ステップｓ１０６で“ＹＥＳ”）、業務特性収集・分析部１１２ａは、業務特性の異常を解消するためにリソースに必要とされる性能、すなわち要求性能調整値を計算する（ステップｓ１０７）。

例えば、ＣＰＵ周波数が２GHzでコア数が４コアである現在稼動中のＣＰＵにおける平均使用率が９０％であり、ＣＰＵの平均使用率の上限閾値として予め設定された値６０％を超えていると仮定する。この仮定のケースでは、業務特性収集・分析部１１２ａは、ＣＰＵの平均使用率を上限閾値６０％以内に収めるために、次の計算式(1)中の要求性能調整値αを求める。
処理能力(CPU=2GHz, 4コア)×90%／100%＝処理能力(α)×60%／100%
・・・(1)

計算式(1)中の要求性能調整値αは、処理の時点で利用可能な最大CPU周波数やコア数、および性能マージン等を考慮して、例えば、ＣＰＵ＝３GHz，4コアまたはCPU=２GHz，６コアが選択される。

なお、複数のリソースについて業務特性が異常である判定される場合には、業務特性収集・分析部１１２ａは、各リソースの業務特性の異常を解消し得るように、各リソースに対する要求性能調整値を計算してもよい。また、業務特性収集・分析部１１２ａは、情報入力部１１３による入力等によって指定されたリソースの業務特性の異常を解消し得るように、指定されたリソースに対する要求性能調整値のみを計算してもよい。

業務特性収集・分析部１１２ａは、計算された要求性能調整値を業務データベース１１１ａ中の業務Ｂｘのエントリの「要求性能調整値」の列に格納する。図７に示した一例では、２GHz，4コアである現在利用中のＣＰＵに発生した「ＣＰＵボトルネック発生（９０％）」という業務特性の異常を解消し得る性能「ＣＰＵ＝３GHz，4コア」を含む要求性能調整値が、業務ＩＤＢｘのエントリの「要求性能調整値」の列に格納される。

ステップｓ１０７における処理が終了すると、業務特性収集・分析部１１２ａは、当該業務Ｂｘに対する業務特性収集・分析処理を終了し、ステップｓ１０８の処理に進む。

ステップｓ１０８において、業務特性収集・分析部１１２ａは、ステップｓ１０２に戻り、業務データベース１１１ａ中に登録された別の業務に対する業務特性収集・分析処理を実行する。例えば、業務特性収集・分析部１１２ａは、業務データベース１１１ａ中に業務Ｂｘの次の行に登録された業務Ｂｘ＋１に対する業務特性収集・分析処理を実行する。こうして、業務データベース１１１ａに登録されたすべての業務に対する業務特性収集・分析処理が実行される。

上述した実施形態の業務特性収集・分析処理に従えば、クラウド上で稼働中の業務に対する稼動データを収集でき、稼動データに基づいて、稼動中のクラウドが当該業務に対して十分な性能を有しているかを判定できる。

また、実施形態の業務特性収集・分析処理に従えば、クラウドが有する性能が不十分と判定される場合には、当該業務の稼動に必要なクラウドの性能が取得される。この結果、取得された性能を用いることによって、当該業務を稼動させるために必要な性能を有する適切なクラウドを再選択することが可能となる。

図６および図７を参照しながら上述した実施形態の業務特性収集・分析処理は、情報入力部１１３を介した入力により設定された所定の時間間隔で実施されてよい。また、実施形態の業務特性収集・分析処理は、未稼働業務に対しては業務データベース１１１ａへの当該業務のエントリ追加時に、稼動済み業務に対してはメンテナンスやスケジュール電源On/Off等による当該業務の一時停止時に実行されてよい。

次に、図８〜図１４をさらに参照しながら、クラウドサービス選択装置１１０により実行される実施形態に従ったクラウドサービス選択処理の一例を説明する。

図８は、実施形態に従ったクラウドサービス選択処理フローの例図である。
制御部１１２ｂは、クラウドサービス選択処理を開始し（ステップｓ２０１）、処理対象の当該業務が業務データベース１１１ａに登録後クラウドで未稼働であるか否かを判定する。

処理対象の当該業務が未稼働であると判定される場合には（ステップｓ２０２で“ＹＥＳ”）、制御部１１２ｂは、実施形態に従った最適サービス選択処理を最適サービス選択部に実行させる（ステップｓ２０３）。

図９は、実施形態に従った最適サービス選択処理フローの例図である。
最適サービス選択部１１２ｃは、最適サービス選択処理を開始すると（ステップｓ３０１）、業務データベース１１１ａに登録された当該業務の付加条件の中で、クラウドサービスが必ず有すべきものとして指定された必須条件を抽出する（ステップｓ３０２）。必須条件は、例えば、情報入力部１１３により入力されて、業務データベース１１１ａに予め設定される。

最適サービス選択部１１２ｃは、クラウド事業者データベース１１１ｃに登録されたクラウドサービスＣａ−１、Ｃａ−２、・・・・Ｃｎについて、ステップｓ３０４〜ステップｓ３０６の最適クラウド候補抽出処理をそれぞれ実行する（ステップｓ３０３）。例えば、最適サービス選択部１１２ｃは、クラウド事業者データベース１１１ｃ中の行番号が小さい順に、ステップｓ３０４〜ステップｓ３０６の最適クラウド候補抽出処理を実行する（ステップｓ３０３）。図３の一例では、最適サービス選択部１１２ｃは、同一のクラウド事業者Ｃａであるクラウドサービスの内、行番号が小さいクラウドＣａ−１から順番に、ステップｓ３０４〜ステップｓ３０６の処理を行う。

ステップｓ３０４〜ステップｓ３０６の最適クラウド候補抽出処理は、当該業務を稼動させるのに最適なクラウドであり得る最適クラウド候補をクラウド事業者データベース１１１ｃから抽出する処理である。

ステップｓ３０４では、最適サービス選択部１１２ｃは、クラウドＣｙ（ｙは、１からクラウド事業者データベース１１１ｃに登録されたクラウド数までの任意の整数）の性能指標が業務データベース１１１ａに登録された当該業務の要求性能を満たすか否かを判定する。

ステップｓ３０４の判定処理では、当該業務が未稼働である場合には、業務データベース１１１ａに登録された要求性能初期値が当該業務の要求性能として用いられる。また、当該業務が稼動済みである場合には、業務データベース１１１ａに登録された要求性能調整値が当該業務の要求性能として用いられる。

クラウドＣｙの性能指標が当該業務の要求性能を満たさないと判定される場合（ステップｓ３０４で“ＮＯ”）、最適サービス選択部１１２ｃは、当該クラウドＣｙに対する最適クラウド候補抽出処理を終了し、ステップｓ３０７の処理に進む。

一方、クラウドＣｙの性能指標が当該業務の要求性能を満たすと判定される場合（ステップｓ３０４で“ＹＥＳ”）、最適サービス選択部１１２ｃは、クラウドＣｙの付加価値がステップｓ３０２で抽出された当該業務の必須条件を満たすか否かを判定する（ステップｓ３０５）。

クラウドＣｙが当該業務の必須条件を満たさないと判定される場合（ステップｓ３０５で“ＮＯ”）、最適サービス選択部１１２ｃは、当該クラウドＣｙに対する最適クラウド候補抽出処理を終了し、ステップｓ３０７の処理に進む。

一方、クラウドＣｙが当該業務の必須条件を満たすと判定される場合（ステップｓ３０５で“ＹＥＳ”）、クラウドＣｙを最適クラウド候補Ｃｃとして最適クラウド候補リストに追加する（ステップｓ３０６）。

ステップｓ３０７において、最適サービス選択部１１２ｃは、ステップｓ３０３に戻って、クラウド事業者データベース１１１ｃ中に登録された別のクラウドに対して最適クラウド候補抽出処理を実行する。例えば、最適サービス選択部１１２ｃは、クラウド事業者データベース１１１ｃ中にクラウドＣｙの次の行に登録されたクラウドに対する最適クラウド候補抽出処理を実行する。こうして、クラウド事業者データベース１１１ｃに登録されたすべてのクラウドに対する最適クラウド候補抽出処理が実行されると、最適サービス選択部１１２ｃは、ステップｓ３０８の処理に進む。

ステップｓ３０８では、最適クラウド候補抽出処理により抽出された最適クラウド候補Ｃｃ１〜Ｃｃｓ（ｓは１から最適クラウド候補リストに追加されたクラウド数までの任意の整数）について、ステップｓ３０９での評価指標算出処理を実行する。例えば、最適サービス選択部１１２ｃは、料金（価格）の安さ、および業務により指定された付加条件とクラウドサービスが提供する付加価値との一致度に対して、最適化ポリシーによる重み付けをそれぞれ行った評価指標の算出をリストに追加されたすべての最適クラウド候補Ｃｃについて行う。

例えば、最適サービス選択部１１２ｃは、最適クラウド候補Ｃｃｚ（ｚは１からｓまでの任意の整数）について、次のような方法により評価指標算出処理を実行する。
まず、最適サービス選択部１１２ｃは、すべての最適クラウド候補Ｃｃｚについて次の計算式(2)により価格C(z)を計算する。
C(z)＝CF(z)＋（ΣCs(z)×当該業務に予想されるリソース利用量）
・・・(2)

計算式(2)中のCF(z)は、最適クラウド候補Ｃｃｚの基本料金であり、Cs(z)は、従量課金制リソースの料金である。

計算式(2)中の当該業務に予想されるリソース利用量には、当該業務に稼動実績がある場合には実績値が用いられる。また、当該業務が未稼働である場合には、業務データベース１１１ａへの登録時に設定された予測値が用いられる。

価格C(z)は低価格であるほど適切であると判断されるので、最適サービス選択部１１２ｃは、当該最適クラウド候補Ｃｃｚの価格C(z)について、すべての最適クラウド候補Ｃｃの中での価格に関する相対評価値CR(z)を次の計算式(3)により計算する。
CR(z) = (CAvg - C(z))/CAvg ・・・(3)
計算式(3)中のCAvgは、すべての最適クラウド候補の価格C(z)の平均値である。

最適サービス選択部１１２ｃは、業務データベース１１１ａに登録された付加条件の中で任意とされたすべての条件ｉ（ｉは、１から任意の条件とされた付加条件の数までの任意の整数）について、次の計算式(4)により任意条件に関する相対評価値VR(z)(i)を計算する。
VR(z)(i)=(V(z)(i) - VAvg(i))/ VAvg(i) ・・・(4)

計算式(4)中のV(z)(i)は、付加価値毎に10点満点の相対評価で予め設定された評価点である。例えば、評価点V(z)(i)は、業務データベース１１１ａに登録された付加条件「サポート」について、電話対応に10点、メール対応に7点、掲示板対応に3点といったように設定される。また、VAvg(i)は、すべての最適クラウド候補の評価点V(z)(i)の平均値である。

最適サービス選択部１１２ｃは、計算式(3)により計算された価格に関する相対評価値CR(z)と計算式(4)により計算された任意条件に関する相対評価値VR(z)(i)とに重み付けを行なった総和を評価指標G(z)として計算する。評価指標G(z)は、次の式(5)により計算される。
G(z) = CR(z)×W0 + V(z)(1)×W1 + V(z)(2)×W2 + …+ V(z)(i)×Wi ・・・(5)

計算式(5)中のWは、当該業務に対する最適化ポリシーに従って設定された重みであり、次の関係式(6)を満たす。
ΣWi = 1 ・・・(6)

例えば、コストで最適化する場合には、W0に大きな値が設定される。この結果、価格が安い最適クラウド候補Ｃｃの評価指標は高くなる。また、特定の付加条件で最適化する場合には、W1〜Wtのうちの何れかまたは複数に大きな値が設定される。こうした重み付けは実装レベルで任意に設定されてもよいし、利用者が重視する項目に従って柔軟に変更できるように設定されてもよい。

ステップｓ３０９での評価指標の算出処理がすべての最適クラウド候補Ｃｃについて実行されると（ステップｓ３１０）、最適サービス選択部１１２ｃは、算出された評価指標が最も高い最適クラウド候補を当該業務の稼動に最適なクラウドとして選択する（ステップｓ３１１）。そして、最適サービス選択部１１２ｃは、一連の最適サービス選択処理を終了する（ステップｓ３１２）。

図８に示したステップｓ２０３での最適サービス選択処理が終了されると、制御部１１２ｂは、最適サービス選択処理により選択されたクラウドを用いて未稼働業務を稼動してよいか否かの判断を利用者に求めるダイアログを情報出力部１１４上に表示する（ステップｓ２０４）。

図１０は、実施形態に従った業務稼動の可否確認画面の一例である。図１０に示した一例のように、最適サービス選択部１１２ｃにより選択された評価指標が最も高い最適クラウドに加えて、評価指標が２番目および３番目に高いクラウドを情報出力部１１４上に同時に表示してもよい。こうした表示によって、利用者がクラウドを最終的に選択する余地を与えることができる。

なお、実施形態によっては、ステップｓ２０４でのダイアログの表示処理を行わずに、評価指標が最も高い最適クラウドが自動的に選択されて、選択されたクラウドで業務が稼動されるように構成してもよい。

ステップｓ２０５において、制御部１１２ｂは、業務データベース１１１ａ中の要求性能の更新処理を実行する。

図１１は、実施形態に従った要求性能更新処理フローの例図である。図１２は、実施形態に従った未稼働業務に対する要求性能更新処理の説明図である。

制御部１１２ｂは、要求性能更新処理を開始し（ステップｓ４０１）、当該業務が未稼働であると判定すると（ステップｓ４０２で“ＮＯ”）、業務データベース１１１ａに登録された当該業務の要求性能初期値を要求性能現在値にコピーする(ステップｓ４０３)。図１１に示した一例では、業務ＩＤＢｘについて、要求性能初期値の値がコピーされて、コピーされた要求性能初期値が要求性能現在値に格納される。

要求性能初期値がコピーされて要求性能現在値に格納されると、制御部１１２ｂは、要求性能更新処理を終了する（ステップｓ４０６）。

ステップｓ２０５での要求性能更新処理が終了すると、制御部１１２ｂは、未稼働業務に対する一連のクラウドサービス選択処理を終了する（ステップｓ２１１）。

一方、ステップｓ２０１での最適サービス選択処理開始後、当該業務が稼働済みであると判定される場合（ステップｓ２０２で“ＮＯ”）、制御部１１２ｂは、ステップｓ２０６の処理に進む。

ステップｓ２０６では、制御部１１２ｂは、前回の最適サービス選択処理の時点からクラウド事業者データベース１１１ｃが更新されたか否かを判定する。例えば、制御部１１２ｂは、クラウド事業者データベース１１１ｃに新たなクラウドが登録されたか否かを判定する。

クラウド事業者データベース１１１ｃが更新されたと判定される場合（ステップｓ２０６で“ＹＥＳ”）、制御部１１２ｂは、ステップｓ２０８の処理に進む。

一方、クラウド事業者データベース１１１ｃが更新されていないと判定される場合（ステップｓ２０６で“ＮＯ”）、制御部１１２ｂは、業務特性収集・分析部１１２ａによって業務データベース１１１ａに格納された当該業務の業務特性に従って利用中のクラウドを再選択する必要があるか否かを判定する（ステップｓ２０７）。

利用中のクラウドを再選択する必要がないと判定される場合（ステップｓ２０７で“ＮＯ”）、制御部１１２ｂは、当該業務に対する一連の最適サービス選択処理を終了する（ステップｓ２１１）。利用中のクラウドを再選択する必要がないと判定されるケースには、例えば、業務データベース１１１ａに格納された当該業務の業務特性が正常であるケースや、業務データベース１１１ａに当該業務の業務特性が格納されていないケースがあり得る。

一方、例えば、業務データベース１１１ａに格納された当該業務の業務特性が異常である等、利用中のクラウドを再選択する必要があると判定される場合（ステップｓ２０７で“ＹＥＳ”）、制御部１１２ｂは、ステップｓ２０８の処理に進む。

ステップｓ２０８では、制御部１１２ｂは、図９を参照しながら前述した最適サービス選択処理を最適サービス選択部１１２ｃに実行させる。最適サービス選択処理では、更新後のクラウド事業者データベース１１１ｃに従って、または業務特性の異常を解消し得る要求性能調整値に従って、クラウド事業者データベース１１１ｃに登録されたクラウドの中から評価指標の最も高い最適なクラウドが選択される。

ステップｓ２０９では、制御部１１２ｂは、ステップｓ２０８の最適サービス選択処理により選択されたクラウドへマイグレーションしてよいか否かの判断を利用者に求めるダイアログを情報出力部１１４上に表示する。

マイグレーションについての利用者の方針は、業務データベース１１１ａ中の当該業務のポリシーの「挙動」に設定され得る。

業務データベース１１１ａ中のポリシーに設定される「挙動」には、例えば、次のような(a)〜(d)の４つのパターンが挙げられる。すなわち、(a)強制的にマイグレーション処理を実行する。(b)一定の猶予期間指示がなければ自動的にマイグレーション処理を実行する。(c)一定の猶予期間指示がなければ自動的にマイグレーション処理をスキップする。(d)管理者（利用者）の指示があるまで処理を待つ。

上記のパターン(b)および(c)に記載される一定の猶予期間は、メンテナンスを行っている間という動的な値であってよく、１時間といった設定可能な固定値であってもよい。

パターン(b)〜(d)では、最適として選択されたクラウドへのマイグレーションの可否だけでなく、例えば、評価指標が上位３位までのクラウドの価格や条件を情報出力部１１４によって利用者に提示し、それらのどれを選択するか、または現状のサービスのまま稼働するかといった情報入力部１１３を通じた利用者からの指示を待つように構成してもよい。

図１３は、実施形態に従ったマイグレーションの可否確認画面の一例である。図１３に示した一例のように、評価指標が最も高い最適クラウドに加えて、評価指標が２番目および３番目に高いクラウドをマイグレーション先のクラウドとして情報出力部１１４上に同時に表示してもよい。こうした表示によって、利用者がクラウドを最終的に選択する余地を与えることができる。

パターン(a)がポリシーとして予め設定される場合には、ステップｓ２０９でのダイアログの表示をせずに、最適として選択されたクラウドへ自動的にマイグレーションするように構成してもよい。

パターン(d)がポリシーとして予め設定され、情報入力部１１３を通じてマイグレーションを許可しないと利用者から指示された場合には、例えば、業務データベース１１１ａに設定された挙動ポリシーがパターン(d)からパターン(c)へ変更されるように構成してもよい。このような構成によれば、例えば、次回のクラウドサービス選択処理において、マイグレーションを許可する意思がない利用者からのマイグレーションの可否の指示を再度待機するといった処理の停滞を抑制することができる。

ステップｓ２１０では、業務データベース１１１ａに格納された要求性能調整値に基づいて選択された別のクラウドへのマイグレーションが許可された場合に、図１１に示した要求性能更新処理が実行される。

図１１に示すように、制御部１１２ｂは、要求性能更新処理を開始し（ステップｓ４０１）、当該業務が稼働済みであると判定すると（ステップｓ４０２で“ＹＥＳ”）、業務データベース１１１ａに登録された当該業務の要求性能調整値を要求性能現在値にコピーする(ステップｓ４０４)。図１４は、実施形態に従った稼働済み業務に対する要求性能更新処理の説明図である。図１４に示した一例では、業務ＩＤＢｘについて、要求性能調整値の値がコピーされて、コピーされた要求性能調整値が要求性能現在値に格納されている。

要求性能調整値がコピーされて要求性能現在値として格納されると、制御部１１２ｂは、図１４にさらに示すように、要求性能調整値および業務特性を初期値に戻す（ステップｓ４０５）。そして、制御部１１２ｂは、要求性能更新処理を終了する（ステップｓ４０６）。

ステップｓ２１０での要求性能更新処理が終了すると、制御部１１２ｂは、稼働済み業務に対する一連のクラウドサービス選択処理を終了する（ステップｓ２１１）。

図８〜１４を参照しながら上述したクラウドサービス選択処理は、当該業務が未稼働である場合には、例えば、次のようなケースが発生すると制御部１１２ｂにより開始される。すなわち、制御部１１２ｂは、業務データベース１１１ａに新たな業務エントリが登録されたことを検出すると、図８に示したクラウドサービス選択処理を開始し、最適サービス選択部１１２ｃに図９に示した最適サービス選択処理の起動を指示する。制御部１１２ｂは、業務データベース１１１ａに新たな業務エントリが登録された後に、最適サービス選択処理の起動を直ちに指示せずに、例えば、当該業務について指定された稼働日時に起動するように最適サービス選択処理をスケジューリングしてもよい。

一方、当該業務が稼動済みである場合には、図８〜１４を参照しながら前述したクラウドサービス選択処理は、メンテナンスやスケジュールによる電源のOn/Off等により業務が一時的に停止された時に実行される。例えば、以下の説明のような構成によって、制御部１１２ｂは、クラウドサービス選択処理を開始する。

例えば、業務特性収集処理において図４を参照しながら前述したエージェントが使用される場合には、業務がシャットダウンする直前に、クラウドサービス選択処理を起動する信号をエージェントから制御部１１２ｂが受信するように構成し得る。また、クラウドサービス提供装置１２０が提供するＡＰＩを用いて、ＯＳが停止したかどうかを制御部１１２ｂが定期的にチェック（ポーリング）し、ＯＳが停止したことを検出すると、制御部１１２ｂは、クラウドサービス選択処理を開始するように構成し得る。

例えば、クラウド事業者データベース１１１ｃへのエントリが追加されたケースや業務データベース１１１ａに設定された最適化ポリシーが変更されたケースでは、利用者には、稼働済みの業務について別の最適なクラウドへ強制的にマイグレーションを行いたい要求があり得る。これらのケースに対応するために、制御部１１２ｂからの指示に従って当該業務が稼働するサーバ上で直接シャットダウンコマンドが実行されるように構成し得る。また、制御部１１２ｂがＡＰＩ経由で直接シャットダウン命令を出すように構成し得る。

クラウド事業者データベース１１１ｃへのエントリの追加を契機として強制的にマイグレーションが実施される場合は、図８のステップｓ２０６でクラウド事業者データベース１１１ｃの更新有りと判定されることによって、ステップｓ２０８での最適サービス選択処理が実行される。一方、メンテナンスやスケジュールによる電源のOn/Offを契機として最適サービス選択処理が実行され場合、ステップｓ２０６での判定処理でクラウド事業者データベース１１１ｃの更新無し、あるいはステップｓ２０７での業務特性に従った再選択の必要性無しと判定され得る。このため、ステップｓ２０８での最適サービス選択処理が不必要に実行されることはない。

図８のステップｓ２１１に進んでクラウドサービス選択処理がすべて完了された後、制御部１１２ｂは、未稼働の業務の稼働または稼動済み業務についてのマイグレーションを実行するための処理を行う。例えば、制御部１１２ｂは、アブストラクタ１１２ｄを経由してクラウドサービス提供装置１２０との契約処理、ＩＰアドレスやＩＤ・パスワードの入手、および業務マスタストレージのデータ転送等の処理を行う。

稼動済みの業務に対する別の最適なクラウドへの移動処理は、メンテナンスやスケジュールによる電源のOn/Off等により業務が一時的に停止される際に行われる。業務が別のクラウドへ移動された場合、異なるクラウドサービス事業者では付与されるIPアドレスが変化する。例えば、業務がドメイン名を利用するクラウドが提供されている場合には、Domain Name System（ＤＮＳ）サーバでアドレスの書き換えが必要である。この処理は、制御部１１２ｂが業務イメージをサーバに送り込む際に実行する機能として組み込んでもよいし、業務側に予め仕込まれたプログラムとして実行してもよい。

なお、最適サービス選択部１１２ｃは、業務データベース１１１ａおよびクラウド事業者データベース１１１ｃのエントリを参照するため、最適サービス選択部１１２ｃには、これらデータベースへアクセスするためのインタフェースが必要である。このインタフェースは、最適サービス選択部１１２ｃが直接アクセスするために最適サービス部１１２ｃが備えてもよいし、制御部１１２ｂが備えてもよい。制御部１１２ｂが備える理由の一例としては、セキュリティやデータ保護等のために最適サービス選択部１１２ｃがアクセスすべきでないデータがこれらのデータベースのテーブルに付加していることが挙げられる。また、最適サービス選択部１１２ｃ以外の構成要素がこれらのデータベースにアクセスするための共通機能として制御部１１２ｂが備える必要があることが挙げられる。実施形態では、業務特性収集・分析部１１２ａがこれらデータベースにアクセスする必要があるため、これらデータベースへアクセスするためのインタフェースを制御部１１２ｂが備えることが望ましい。

以上のように説明した第１の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、クラウド事業者が提供する様々なクラウドサービスの中から当該業務に要求されるサービス品質と利用者のポリシーとを反映した低価格のクラウドサービスを迅速かつ効率的に選択できる。また、業務稼動後においても、クラウドサービスを用いた当該業務の稼働実績から得られる業務特性に従って最適なクラウドサービスを迅速かつ効率的に再選択できる。さらに、クラウドサービス事業者が新たなクラウドサービスを提供した際にも、現在利用中のクラウドサービスが最適か否かを分析して再選択の必要性を迅速かつ効率的に判定できる。このように、業務の稼動前および稼動後において、最適なクラウドを用いて業務を稼動できるので、業務が本来果たすべき性能を少ないコストで発揮させることができる。

＜第２の実施形態＞
図１５は、第２の実施形態に従ったクラウドサービス選択システムの構成図である。
図１５に示した第２の実施形態に従ったクラウドサービス選択システム２００において、図１に示した第１の実施形態に従ったクラウドサービス選択システム１００と同じ構成要素には、同一の参照符号が付加されている。

前述したように、図３に示したクラウド事業者データベース１１１ｃに登録される性能指標は、クラウドサービス事業者が公表する当該クラウドサービスの性能である。第１の実施形態では、クラウドサービス事業者から公表されたこのような性能指標が用いられて、当該業務に適するクラウドが選択される。

しかしながら、クラウドの正確な性能指標をクラウドサービス事業者が公開していないケースがあり得る。また、当該クラウドについて公表された性能指標と現実に稼動した場合に当該クラウドが有する性能との間に差異が生じるケースがあり得る。例えば、事前に公表された性能指標どおりのネットワークの速度が出ない、レイテンシが大きい等の差異が生じ得る。

上記のようなケースに対応するために、第２の実施形態に従ったクラウドサービス選択装置２１０は、図１５に示すようにプロセッサ２１２に実効性能取得部１１２ｆを含む。

実効性能取得部１１２ｆは、当該クラウドの実効性能を実効性能測定用のダミー業務を用いて取得する。実効性能とは、公表された当該クラウドの性能指標と当該クラウドで業務を稼動させた時に実際に有する性能との比である。最適サービス選択部１１２ｃは、実効性能取得部１１２ｆにより取得された実効性能を用いてクラウドの性能指標を補正し、補正されたクラウドの性能指標を用いて当該業務に最適なクラウドを選択する。

クラウドサービス選択装置２１０により実行される実施形態に従った実効性能取得処理を説明する。
まず、業務マスタデータ格納部１１１ｂには、実行性能測定ソフトウェアを有する実効性能測定用のダミー業務のデータが予め格納される。実行性能測定ソフトウェアには、クラウドサービス提供装置１２０の特定システムに負荷をかけるための負荷ツールと稼働時の性能測定を実行するための測定ツールとが含まれる。

また、業務データベース１１１ａには、ダミー業務に対する要求性能初期値を含むデータが情報入力部１１３を介して予め登録される。図１６は、実行性能測定用のダミー業務の例図である。図１６に示した一例では、２つのダミー業務Ｂｘ１およびＢｘ２が登録される。例えば、実際の業務を業務データベース１１１ａに登録するための情報出力部１１４上に表示された登録画面を通じて、図１６に示すようなダミー業務Ｂｘ１およびＢｘ２の各データが業務データベース１１１ａ中に定義される。

図１７は、実施形態に従った実効性能取得処理フローの例図である。
実効性能取得部１１２ｆは、実効性能取得処理を開始すると（ステップｓ５０１）、業務マスタデータ格納部１１１ｂに格納されたダミー業務を測定対象のクラウドサービス提供装置１２０上に制御部１１２ｂを介して展開する（ステップｓ５０２）。

クラウドサービス提供装置１２０上に展開されたダミー業務に含まれる実行性能測定ソフトウェアによって、測定対象のリソースの性能が測定される。測定結果は、実行性能測定ソフトウェアを実行するクラウドサービス提供装置１２０から実効性能取得部１１２ｆへ送信される（ステップｓ５０３）。

測定結果を受信した実効性能取得部１１２ｆは、クラウドサービス事業者により公表された当該クラウドの性能指標とダミー業務の実行結果から得られる当該クラウドの性能との比を実効性能の値として算出する。

実効性能取得部１１２ｆは、算出された実効性能値をクラウド事業者データベース２１１ｃ中の測定対象クラウドの実行性能欄に格納する（ステップｓ５０４）。図１８は、実効性能データを含むクラウド事業者データベースの例図である。図１８に示したように、クラウド事業者データベース２１１ｃには、図３に示したクラウド事業者データベース１１１ｃと同様の各項目に加えて、項目「実効性能」が含まれる。

実行性能がクラウド事業者データベース２１１ｃに格納されると、実効性能取得部１１２ｆは、実効性能取得処理を終了する（ステップｓ５０５）。
実効性能取得処理によってクラウド事業者データベース２１１ｃに格納された実効性能データは、図８および図９を参照しながら前述したクラウドサービス選択処理に用いられる。具体的には、図９に示したステップｓ３０４の最適クラウド候補抽出処理において実効性能データが用いられる。

ステップｓ３０４の最適クラウド候補抽出処理では、例えば、最適クラウド選択処理の対象である当該業務が未稼働である場合には、次の関係式(7)を満たすか否かが判定される。
要求性能初期値≦性能指標×実効性能 ・・・(7)

関係式(7)中の要求性能初期値は、業務データベース１１１ａに登録された当該未稼働業務の要求性能初期値である。関係式(7)中の性能指標および実効性能は、クラウド事業者データベース２１１ｃに登録された処理対象のクラウドの性能指標および実効性能である。

また、当該業務が稼動済みである場合には、次の関係式(8)を満たすか否かが判定される。
要求性能調整値≦性能指標×実効性能 ・・・(8)

関係式(8)中の要求性能調整値は、業務データベース１１１ａに登録された当該稼動済み業務の要求性能調整値である。関係式(8)中の性能指標および実効性能は、関係式(7)と同様、クラウド事業者データベース２１１ｃに登録された処理対象のクラウドの性能指標および実効性能である。

なお、実効性能取得処理の実行に関して以下のように構成してもよい。
例えば、実効性能取得処理によって対象クラウドでダミー業務を稼動させた場合には、ダミー業務をクラウドで稼動させたことによるコストが発生し得る。そこで、ダミー業務の稼動により多大なコストが発生することを抑制するために、対象クラウドの最低契約期間の長さに応じて実効性能取得処理を実行するか否かの命令を制御部１１２ｂが実効性能取得部１１２ｆに指示するように構成してもよい。また、実効性能取得処理を実行するか否かの指示を情報入力部１１３を通じて利用者が入力できるように構成してもよい。

一方、クラウドによっては、リソースの性能に上限を設けたり一度目の利用に限るといった条件を付した上で無償で提供され得る。こうした制限が付された場合には、有償後の当該クラウドの実効性能を正確に取得することができない。そこで、有償のクラウドに限り実効性能取得部１１２ｆが実効性能取得処理を実行するように構成してもよい。

例えば、クラウドサービス事業者は、１〜２年といったサイクルで、技術の進展に応じたより高い性能を有するクラウドサービス装置１２０に更新し得る。そこで、クラウド事業者データベース２１１ｃに登録されたクラウドに対する実効性能を実効性能取得部１１２ｆが定期的に取得するように構成してもよい。

例えば、クラウド事業者データベース２１１ｃに新たなクラウドが登録された場合には、登録された新たなクラウドに対する実効性能が取得される必要が生じ得る。そこで、クラウド事業者データベース２１１ｃに新たなクラウドが登録された場合には実効性能取得部１１２ｆが実効性能取得処理を実行するように構成してもよい。

以上のように説明した第２の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、クラウドクラウドサービスの実効性能を反映した当該業務の稼動により適切なクラウドサービスを選択することが可能である。

また、ある要求性能を有する実際の業務の稼動に先立って、実際の業務と同様の要求性能を有するダミー業務をクラウドサービスで稼動させることができるため、実際の業務を当該クラウドサービスで稼動させても問題がないか否かを確認することが可能である。

＜第３の実施形態＞
図１９は、第３の実施形態に従ったクラウドサービス選択システムの構成図である。
図１９に示した第３の実施形態に従ったクラウドサービス選択システム３００において、図１に示したクラウドサービス選択システム１００および図１５に示したクラウドサービス選択システム２００と同じ構成要素には、同一の参照符号が付加されている。

前述した第１および第２の実施形態では、クラウドサービス選択装置１１０および２１０は、クラウドサービス提供装置１２０により提供されるパブリッククラウドの中から当該業務を稼動させるのに適切なクラウドサービスを選択する。

これに対して、第３の実施形態では、パブリッククラウドの選択肢としてプライベートクラウドを組み込むように構成することによって、パブリッククラウドおよびプライベートクラウドの中から、当該業務を稼動させるのに適切なクラウドサービスが選択される。すなわち、第３の実施形態では、図１９に示したクラウドサービス選択装置３１０は、クラウドサービス提供装置１２０により提供されるパブリッククラウド３２０と、プライベートクラウド３４０とを含むハイブリットクラウドの中から、当該業務を稼動させるのに適切なクラウドサービスを選択する。

プライベートクラウドは、企業内の各部門やグループ企業といった特定の利用者を対象に提供されるクラウドサービスである。また、ハイブリットクラウドは、パブリッククラウドとプライベートクラウドとを組み合わせたクラウドサービスである。

図１９に示すように、プライベートクラウド３２０は、サーバプール３４１およびプライベートクラウド管理装置３４２によって提供される。サーバプール３４１は、プライベートクラウドを提供する複数のサーバを含む。プライベートクラウド管理装置３４２は、イントラネットといった組織内ネットワーク３５０を介して接続するクラウドサービス選択装置３１０とサーバプール３４１とのアクセスを管理する。

図１９に示すように、クラウドサービス選択装置３１０のプロセッサ３１２は、プライベートクラウド用プラグイン１１２ｅーｐ含む。

プライベートクラウド３４０を提供するサーバプール３４１は、インターネット等のネットワーク１３０を介してクラウドサービス選択装置３１０と接続されず、組織内ネットワーク３５０を介してクラウドサービス選択装置３１０と接続される。そこで、第３の実施形態では、アブストラクタ１１２ｄにプライベートクラウド３４０へアクセスするためのプライベートクラウド用プラグイン１１２ｅーｐを追加することによって、クラウドサービス選択装置３１０がプライベートクラウド３４０をパブリッククラウド３２０と同じように透過的に利用できるように構成する。

図２０は、第３の実施形態に従ったクラウド事業者データベースの例図である。
第３の実施形態では、クラウド事業者データベース３１１ｃには、プライベートクラウドを提供するサーバプール３４１があたかもパブリッククラウドを提供するクラウドサービス事業者であるかのように登録される。図２０に示す例では、業務ＩＤがＣｐｂの２種類のプライベートクラウドが登録される。

クラウド事業者データベース３１１ｃにおいて、プライベートクラウドの料金データには、「無料」と登録されてもよく、サーバ取得のための固定費と電気料金などの変動費を合計したTotal Cost of Ownership（ＴＣＯ）を単位時間あたりに換算した金額が登録されてもよい。また、当該エントリがパブリックかプライベートかを示すクラウド種別を図２０のように「付加価値」として登録してもよく、クラウド種別の列をクラウド事業者データベース３１１ｃに追加してもよい。

図２０に示すように、第３の実施形態に従ったクラウド事業者データベース３１１ｃは、図１８に示したクラウド事業者データベース２１１ｃと同様の各項目に加えて、インスタンス数のデータを含む。実用上、インスタンス数に制限のないパブリッククラウドとは異なり、プライベートクラウドには、利用者等により所有されるサーバ機器に依存して、稼働させられるインスタンス数に制限がある。そこで、クラウド事業者データベース３１１ｃにインスタンス数の列を追加する。

図２０に示した一例では、インスタンス数のデータには、予め定義された最大インスタンス数(Max)と、残りインスタンス数(Cur)が含まれる。クラウド事業者データベース３１１ｃへの登録時には、残りインスタンス数の初期値として最大インスタンス数が予めコピーされて格納される。ある業務を動作させるクラウドサービスとして、クラウド事業者データベース３１１ｃに登録された複数のプライベートクラウドＣｐｂの内の１つを最適サービス選択部１１２ｃが選択した場合、選択された当該プライベートクラウドＣｐｂの残りインスタンス数はデクリメントされる。また、当該プライベートクラウドＣｐｂの利用が停止される場合には、利用が停止された当該プライベートクラウドＣｐｂの残りインスタンス数はインクリメントされる。業務特性の異常によりあるプライベートクラウドＣｐｂがマイグレーションされる場合、マイグレーション元である当該プライベートクラウドＣｐｂの残りインスタンス数はインクリメントされる。あるプライベートクラウドＣｐｂの残りインスタンス数がゼロになった場合、最適サービス選択部１１２ｃは、当該プライベートクラウドＣｐｂを選択肢から除外して、残りインスタンス数がゼロになった当該プライベートクラウドＣｐｂの新規インスタンスを作成しないように処理する。

図２０を参照しながら上述した処理以外については、第１の実施形態および第２の実施形態として前述した処理と同様である。

以上のように説明した第３の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、パブリッククラウドおよびプライベートクラウドの中から当該業務を稼動させるのに適切なクラウドサービスを選択することができる。

＜第４の実施形態＞
第３の実施形態では、パブリッククラウドおよびプライベートクラウドの区別をせずに、当該業務を稼動させるのに適切なクラウドサービスが選択される。

これに対して、第４の実施形態では、クラウド事業者データベース３１１ｃに登録されたプライベートクラウドＣｐｂに対する料金の設定値を低くする。このような料金設定がなされた場合、最適サービス選択部１１２ｃは、クラウド事業者データベース３１１ｃに登録されたすべてのクラウドサービスの中から、プライベートクラウドＣｐｂを優先的に選択する。

また、第４の実施形態では、クラウド事業者データベース３１１ｃに登録されたプライベートクラウドＣｐｂに対する料金の設定値を高くする。このような料金設定がなされた場合、最適サービス選択部１１２ｃは、クラウド事業者データベース３１１ｃに登録されたすべてのクラウドサービスの中から、パブリッククラウドを優先的に選択する。

以上のように説明した第４の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、ハイブリッドクラウドにおいて主にプライベートクラウドを使いたか、それとも主にパブリッククラウドを使いたいかという利用者のポリシーを反映して、当該業務に適したクラウドサービスを選択することができる。

＜第５の実施形態＞
第４の実施形態では、クラウド事業者データベース３１１ｃに登録されたプライベートクラウドＣｐｂに対する料金の設定値に従って、主にプライベートクラウドを使いたいか、それとも主にパブリッククラウドを使いたいかという利用者の方針が反映されたクラウドサービスが選択される。

これに対して、第５の実施形態では、図２０に示したようにクラウド事業者データベース３１１ｃ中の「付加価値」のクラウド種別に対して、例えば、プライベート=10、パブリック=0といったように、極端に差がある評価点を予め設定する。このような設定が行なわれた場合、最適クラウド候補に対する評価指標の算出処理（図９のステップｓ３０９）においてクラウド種別の評価点が反映されて、プライベートクラウドまたはパブリッククラウドの評価指標が相対的に高くなる。

以上のように説明した第５の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、ハイブリッドクラウドにおいて主にプライベートクラウドを使いたいか、それとも主にパブリッククラウドを使いたいかという利用者の方針を反映する当該業務に適したクラウドサービスを選択することができる。

＜第６の実施形態＞
図２１は、第６の実施形態に従ったクラウドサービス選択システムの構成図である。
図２１に示した第６の実施形態に従ったクラウドサービス選択システム４００において、クラウドサービス選択システム１００〜３００と同じ構成要素には、同一の参照符号が付加されている。

第３の実施形態に従ったクラウドサービス選択システム３００では、パブリッククラウドの選択肢としてプライベートクラウドを組み込むように構成することによって、パブリッククラウドおよびプライベートクラウドの中から、当該業務を稼動させるのに適切なクラウドサービスが選択される。

これに対して、第６の実施形態に従ったクラウドサービス選択システム４００では、プライベートクラウドの選択肢としてパブリッククラウドを組み込むように構成することによって、パブリッククラウドおよびプライベートクラウドの中から、当該業務を稼動させるのに適切なクラウドサービスが選択される。

第６の実施形態では、図２１に示すプライベートクラウド４４０を提供するサーバプール４４１を構成するサーバには、パブリックなサーバ（クラウドサービス提供装置１２０）のメタデータが仮想的に予め登録される。

例えば、プライベートクラウドでの業務要求の増加によって、サーバプール４４１内のプライベートなサーバが枯渇してきた場合、プライベートクラウド管理装置４４２は、プライベートクラウドでの業務を図２２に示す一例のように業務データベース４１１ａに追加し、その業務データを業務マスタデータ格納部４１１ｂに追加する。図２２に示す一例では、業務ＩＤがＢｐｂ１の業務が業務データベース４１１ａに追加される。

クラウドサービス選択装置４１０は、パブリッククラウドで稼動される新たな業務が業務データベース４１１に追加されたと判定する。そこで、クラウドサービス選択装置４１０は、業務データベース４１１に追加された新たな業務に適するパブリッククラウドを選択する。

第６の実施形態のクラウドサービス選択装置、クラウドサービス選択システム、クラウドサービス選択方法に従えば、第１および第２の実施形態に従ったクラウドサービス選択装置１１０および２１０のシステム制御に大きな変更を加えることなく、ハイブリットクラウドのシステムを実現できる。すなわち、クラウドサービス選択装置１１０および２１０と比較して、クラウドサービス選択装置４１０に次のような処理を追加することで、ハイブリットクラウドのシステムを実現できる。サーバプール４４１から受信したプライベートクラウドでの業務のエントリを業務データベース４１１ａに追加および削除する処理や、サーバプール４４１から受信した業務データを格納するためのＡＰＩを業務マスタデータ格納部４１１ｂに提供する処理である。

＜第７の実施形態＞
第１〜第６の実施形態では、クラウドサービス選択装置１１０〜４１０によって当該業務に適するクラウドサービスが選択される。しかしながら、クラウドサービス選択装置１１０〜４１０が有する構成および処理機能を、クラウドサービス選択プログラムというソフトウェアによって実現することも可能である。したがって、クラウドサービス選択装置１１０〜４１０と同様の処理を、クラウドサービス選択プログラムを実行するコンピュータによって実現することも可能である。

図２３は、第７の実施形態に従ったクラウドサービス選択プログラムを実行するコンピュータのハードウェア構成図である。
図２３に示すように、コンピュータ５００には、入力装置５０１、読み取り装置５０２、通信インタフェース５０３、ハードディスク（ＨＤＤ）５０４、ＣＰＵ５０５、ＲＡＭ５０６、Read Only Memory（ＲＯＭ）５０７、表示装置５０８、およびバス５０９が含まれる。コンピュータ５００に含まれる装置５０１〜５０８は、バス５０９によって相互に接続される。

入力装置５０１は、コンピュータ５００の利用者が行なった操作を検出する装置であり、例えば、マウスおよびキーボードである。

読み取り装置５０２は、磁気ディスク、光ディスク、および光磁気ディスク、Universal Serial Bus（ＵＳＢ）メモリ等の可変記録媒体に含まれるプログラムおよびデータを読み出す装置であり、例えば、Compact Disc/Digital Versatile Disc（ＣＤ／ＤＶＤ）ドライブである。通信インタフェース５０３は、インターネットやLocal Area Network（ＬＡＮ）等の通信ネットワークにコンピュータ５００を接続するためのインタフェースである。ＨＤＤ５０４は、ＣＰＵ５０５が実行するプログラムおよびデータを記憶する記憶装置である。

実施形態に従ったクラウドサービス選択プログラムは、可変記録媒体に記録されたクラウドサービス選択プログラムを読み取り装置５０２が読み取ることによって、ＨＤＤ５０４にインストールされる。または、実施形態に従ったクラウドサービス選択プログラムは、他のコンピュータ装置（不図示）に格納されたクラウドサービス選択プログラムを通信インタフェース５０３を介してコンピュータ５００が取得することによって、ＨＤＤ５０４にインストールされる。

ＣＰＵ５０５は、クラウドサービス選択プログラムをＨＤＤ５０４からＲＡＭ５０６に読み出してクラウドサービス選択プログラムを実行することによって、実施形態に従ったクラウドサービス選択処理を実行する処理装置である。

ＲＡＭ５０６は、ＨＤＤ５０４から読み出されたクラウドサービス選択プログラムの実行途中結果を記憶する主記憶装置の一例である。ＲＯＭ５０７は、定数データ等を記憶する読み出し専用メモリである。

表示装置５０８は、ＣＰＵ５０５の処理結果等を表示する装置であり、例えば、液晶ディスプレイ装置である。

第７の実施形態に従えば、第１〜第６の実施形態に従ったクラウドサービス選択装置が実行する処理をクラウドサービス選択プログラムを実行するコンピュータによって実現することができる。

Claims (7)

1. クラウドサービス提供装置によって不特定多数人を対象に提供される複数のクラウドサービスそれぞれの性能指標、付加価値、および料金を含むデータが登録されるクラウド事業者データベースと、
   前記クラウド事業者データベースに登録された複数のクラウドサービスの内の１つのクラウドサービスを用いて稼動される業務の要求性能、付加条件、および利用者ポリシーを含むデータが登録される業務データベースと、
   前記性能指標が前記要求性能を満たす最適クラウド候補を前記複数のクラウドサービスの中から抽出し、前記料金と前記付加条件および前記付加価値の一致度とに対して前記利用者ポリシーによる重み付けを行った評価指標を抽出された前記最適クラウド候補について算出し、算出された前記評価指標の最も高い最適クラウド候補を前記業務に用いられるクラウドサービスとして選択する最適サービス選択部と、
   前記クラウド事業者データベースに登録されたクラウドサービスを提供するクラウドサービス提供装置へダミー業務を展開して実行させて測定した該クラウドサービスの実際の性能についての測定結果を取得する実効性能取得部と、
   前記クラウド事業者データベースに登録されたクラウドサービスが用いられて前記業務が稼働されているときに、前記業務の稼働データを取得し、取得された稼動データに基づいて前記業務の要求性能を分析する業務特性収集・分析部と
   を含み、
   前記最適サービス選択部は、前記実効性能取得部により取得された前記性能についての測定結果を用いて前記性能指標を補正し、補正された前記性能指標を用いて、前記業務特性収集・分析部により分析された前記要求性能を満たす最適クラウド候補であって、且つ、前記評価指標の最も高い前記最適クラウド候補を選択する
   クラウドサービス選択装置。
2. 前記最適サービス選択部により抽出された前記評価指標の高い順に複数のクラウド候補を表示する情報出力部と、
   前記情報出力部により表示された前記複数のクラウド候補の内の１つのクラウド候補を前記業務に用いられるクラウドサービスとして指定するための情報入力部と、
   情報入力部を介して指定された前記１つのクラウド候補に対応するクラウドサービス提供装置へ前記業務のマスタデータを展開する制御部と
   をさらに含む請求項１に記載のクラウドサービス選択装置。
3. 前記クラウド事業者データベースに登録されたクラウドサービスが用いられて前記業務が稼働された後に、前記情報出力部により表示された前記複数のクラウド候補の内の１つのクラウド候補が前記情報入力部を介して指定された場合に、前記制御部は、前記業務に用いられた前記クラウドサービスに対応するクラウドサービス提供装置から前記情報入力部により指定された前記１つのクラウド候補に対応するクラウドサービス提供装置へ前記業務のマスタデータをマイグレーションする請求項２に記載のクラウドサービス選択装置。
4. 前記クラウド事業者データベースには、前記クラウドサービス選択装置の利用者を含む特定人を対象にサーバプールによって提供されるクラウドサービスがさらに登録され、
   前記最適サービス選択部は、前記サーバプールによって提供される前記クラウドサービスを含む前記クラウド事業者データベースの中から前記評価指標の最も高い最適クラウド候補を選択する
   請求項１〜３の何れか一項に記載のクラウドサービス選択装置。
5. 前記クラウド事業者データベースの前記付加価値は、前記複数のクラウドサービスそれぞれの料金に対する評価点と前記サーバプールによって提供される前記クラウドサービスの料金に対する評価点との差が大きくなるように登録される請求項４に記載のクラウドサービス選択装置。
6. 前記クラウド事業者データベースは、不特定多数人を対象に提供されるクラウドサービスに対する評価点と前記サーバプールによって提供される前記特定人を対象に提供されるクラウドサービス評価点との差が大きくなるように登録されたクラウド種別をさらに含む請求項４に記載のクラウドサービス選択装置。
7. 前記業務データベースには、前記クラウドサービス選択装置の利用者を含む特定人を対象に提供されるクラウドサービスに用いられるサーバプール中の未使用サーバの枯渇により処理できない業務のデータがさらに登録され、
   前記最適サービス選択部は、前記業務データベースに登録された前記未使用サーバの枯渇により処理できない前記業務に用いられるクラウドサービスとして、前記クラウド事業者データベースの中から前記評価指標の最も高い最適クラウド候補を選択する
   請求項１〜３の何れか一項に記載のクラウドサービス選択装置。

Images