(57)【要約】  サーバ選択装置（１０）は、サーバに対する性能要件が第１の閾値以上のスループット及び／又は第２の閾値以下のレイテンシーである場合に（ステップＳ１２ｂＹｅｓ）、サーバ種別としてベアメタルを選択する。サーバ選択装置（１０）は、性能要件が第１の閾値以上のスループット及び／又は第２の閾値以下のレイテンシーでない場合に（ステップＳ１２ｂＮｏ）、サーバに対する機能要件が所定のＯＳ（例えばLinux（登録商標）等のカスタマイズされていないＯＳ）以外のＯＳ又はカスタマイズＯＳであることを要するとき（ステップＳ１２ｄＹｅｓ）、サーバ種別として仮想マシンを選択し、機能要件が所定のＯＳ以外のＯＳ及びカスタマイズＯＳであることを要しないとき（ステップＳ１２ｄＮｏ）、サーバ種別としてコンテナを選択する。
2016167086.tif 000002
【特許請求の範囲】
【請求項１】
サーバを含む仮想環境の構成を記述した第１のテンプレートと、ユーザが該サーバに対して要求するスループット又はレイテンシーを示す性能要件ならびに該サーバ上で動作させるＯＳ（Operating  System）の情報を示す機能要件との入力を受け付ける受付部と、
前記性能要件が第１の閾値以上のスループット又は第２の閾値以下のレイテンシーを示す性能条件に該当する場合に、前記サーバの種別としてベアメタルサーバを選択し、前記性能要件が前記性能条件に該当せず、かつ、前記機能要件が所定のＯＳ以外のＯＳ又はカスタマイズを要するＯＳを示す機能条件に該当する場合に、前記サーバの種別として仮想マシンを選択し、前記性能要件が前記性能条件に該当せず、かつ、前記機能要件が前記機能条件に該当しない場合に、前記サーバの種別としてコンテナ型仮想サーバを選択する選択部と
を備えることを特徴とするサーバ選択装置。
【請求項２】
前記選択部により選択された前記サーバの種別を前記第１のテンプレートに対して反映した第２のテンプレートを生成するテンプレート生成部
をさらに備えることを特徴とする請求項１に記載のサーバ選択装置。
【請求項３】
前記第２のテンプレートをもとに前記仮想環境を生成する仮想環境生成部と、
前記仮想環境に含まれる前記サーバへインストールされるソフトウェアの情報及び各前記サーバ間の接続構成を解析する解析部と、
前記解析部により解析された前記ソフトウェアの情報及び各前記サーバ間の接続構成をもとに、前記仮想環境に含まれる各前記サーバで動作するソフトウェアのソフトウェア毎、グループ毎もしくは機能毎の分類ならびに該ソフトウェアの接続パターンを判定し、該分類毎の試験パターン及び該接続パターン毎の試験パターンをデータベースから取得する取得部と、
前記取得部により取得された試験パターンを前記仮想環境に対して実行し、前記仮想環境に含まれる各前記サーバの性能及び該仮想環境のシステム性能を測定するテスト実行部と
をさらに備えることを特徴とする請求項２に記載のサーバ選択装置。
【請求項４】
サーバ選択装置が実行するサーバ選択方法であって、
サーバを含む仮想環境の構成を記述した第１のテンプレートと、ユーザが該サーバに対して要求するスループット又はレイテンシーを示す性能要件ならびに該サーバ上で動作させるＯＳ（Operating  System）の情報を示す機能要件との入力を受け付ける受付ステップと、
前記性能要件が第１の閾値以上のスループット又は第２の閾値以下のレイテンシーを示す性能条件に該当する場合に、前記サーバの種別としてベアメタルサーバを選択し、前記性能要件が前記性能条件に該当せず、かつ、前記機能要件が所定のＯＳ以外のＯＳ又はカスタマイズを要するＯＳを示す機能条件に該当する場合に、前記サーバの種別として仮想マシンを選択し、前記性能要件が前記性能条件に該当せず、かつ、前記機能要件が前記機能条件に該当しない場合に、前記サーバの種別としてコンテナ型仮想サーバを選択する選択ステップと
を含むことを特徴とするサーバ選択方法。
【請求項５】
前記選択ステップにより選択された前記サーバの種別を前記第１のテンプレートに対して反映した第２のテンプレートを生成するテンプレート生成ステップ
をさらに含むことを特徴とする請求項４に記載のサーバ選択方法。
【請求項６】
前記第２のテンプレートをもとに前記仮想環境を生成する仮想環境生成ステップと、
前記仮想環境に含まれる前記サーバへインストールされるソフトウェアの情報及び各前記サーバ間の接続構成を解析する解析ステップと、
前記解析ステップにより解析された前記ソフトウェアの情報及び各前記サーバ間の接続構成をもとに、前記仮想環境に含まれる各前記サーバで動作するソフトウェアのソフトウェア毎、グループ毎もしくは機能毎の分類ならびに該ソフトウェアの接続パターンを判定し、該分類毎の試験パターン及び該接続パターン毎の試験パターンをデータベースから取得する取得ステップと、
前記取得ステップにより取得された試験パターンを前記仮想環境に対して実行し、前記仮想環境に含まれる各前記サーバの性能及び該仮想環境のシステム性能を測定するテスト実行ステップと
をさらに含むことを特徴とする請求項５に記載のサーバ選択方法。
【請求項７】
請求項１、２又は３に記載のサーバ選択装置としてコンピュータを機能させるサーバ選択プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ選択装置、サーバ選択方法及びサーバ選択プログラムに関する。
【背景技術】
【０００２】
近年、ホスティングサービスやＩａａＳ（Infrastructure  as  a  Service）型クラウドサービス等のような、ユーザに対して仮想資源をプロビジョニングするクラウドサービスが普及してきている。ユーザは、サービス事業者と契約することで、仮想サーバ、仮想ネットワーク、仮想ルーター、仮想ストレージ、仮想ロードバランサー等の仮想機器をオンデマンドで利用できる（例えば、Amazon  Web  Services（登録商標）、＜http://aws.amazon.com/ec2＞）。例えば、ユーザは、ＯＳ（Operating  System）や、ＤＢ（Data  Base）サーバ、Ｗｅｂサーバ、メールサーバ等のミドルウェアを仮想サーバ上で動作させることにより、自身でハードウェアを用意せずとも、自身専用のサーバを構築できる。【０００３】
また、ＩａａＳを実現するオープンソースソフトウェアも普及してきており、例えば、OpenStack（登録商標、以下同様）を基盤とする商用クラウドサービスが数多く開始されている（例えば、Rackspace（登録商標）  Public  Cloud  Powered  by  OpenStack,<http://www.rackspace.com/cloud/>）。【０００４】
ここで、従来から、仮想サーバは、Ｘｅｎ（登録商標、以下同様）、ＫＶＭ（Kernel  based  Virtual  Machine）等のハイパーバイザー上で動作する仮想マシンが主流である。しかし、ハイパーバイザーは、仮想化オーバーヘッドが大きいため、仮想化オーバーヘッドがより小さいコンテナ型仮想サーバや、仮想化を行わないベアメタルサーバを提供する事業者が現れてきている。そして、サーバ種別が、ベアメタルサーバ、コンテナ型仮想サーバ、仮想マシンと増えることにより、ＩａａＳ等のクラウドサービスの活用が促進されると考えられる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】R.  Kumar  and  B.  B.  Parashar,  “Dynamic  Resource  Allocation  and  Management  Using  OpenStack,”  Network  and  service  management  (cnsm),  2012  8th  international  conference  and  2012  workshop  on  systems  virtualiztion  management  (svm)  ,  pp.309-315,  Oct.  2012.
【非特許文献２】W.  Felter,  A.  Ferreira,  R.  Rajamony  and  J.  Rubio,  “An  Updated  Performance  Comparison  of  Virtual  Machines  and  Linux  Containers,”  IBM  Research  Report,  July  2014.
【非特許文献３】Fuyang  Peng,  Bo  Deng  and  Chao  Qi,  “CASTE:  a  Cloud-Based  Automatic  Software  Test  Environment,”  World  Academy  of  Science,  Engineering  &  Technology,  Issue  71,  pp.1449-1452,  Nov.  2012.
【非特許文献４】Y.  Yamato,  “Automatic  verification  technology  of  software  patches  for  user  virtual  environments  on  IaaS  cloud,”  Springer  Journal  of  Cloud  Computing  2015,  4:4,  DOI:  10.1186/s13677-015-0028-6,  Feb.  2015.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記の従来技術は、ベアメタルサーバ、コンテナ型仮想サーバ、仮想マシンの適切な使い分けを行うものではない。例えば、上記の非特許文献１は、OpenStackを用いたクラウド管理に関する技術に関し、OpenStack上でベアメタルサーバをプロビジョニングするための技術としてIronicを開示する。しかし、Ironicは、ベアメタルサーバと仮想マシンとの適切な使い分けを行うものではない。【０００７】
また、例えば、上記の非特許文献２は、ベアメタルサーバ、Dockerによるコンテナ型仮想サーバ、ＫＶＭによる仮想マシンの性能を比較するに過ぎず、ベアメタルサーバとコンテナ型仮想サーバと仮想マシンとの使い分けを行うものではない。【０００８】
また、例えば、上記の非特許文献３は、クラウド上での試験自動化に関する技術であるが、事前に数多くのスクリプトの準備が必要であり、ユーザ環境毎に性能試験を行うものではない。また、例えば、非特許文献４は、クラウド上の仮想機器のＯＳやソフトウェアへ適用する修正プログラム（パッチ）の検証自動化に関する技術であるが、個々の仮想機器に対する試験であり、複数の仮想機器に跨る試験を行うものではない。ユーザ毎に選択されるサーバ種別、接続関係、インストールソフトウェアは異なるため、事前にそのユーザ環境に合わせた試験パターンを準備しておくことは多大な工数を要する。そのため、現状、クラウドで構築されたシステムに対する性能試験の自動化はなされていない。【０００９】
すなわち、上記の従来技術は、ユーザの性能要件に応じて、ベアメタルサーバ、コンテナ型仮想サーバ、仮想マシンのなかからサーバ種別を選択して、選択した仮想サーバを含むユーザ毎の仮想環境を設計し、設計した仮想環境における複数の仮想機器に跨ってシステムの性能検証を自動的に行うものではない。このため、上記の従来技術は、ユーザの性能要件を満たす仮想環境を構築することが容易でない。【００１０】
本願が開示する実施形態の一例は、上記に鑑みてなされたものであって、ユーザの性能要件を満たす仮想環境を容易に構築することを目的とする。
【課題を解決するための手段】
【００１１】
本願が開示する実施形態の一例において、サーバ選択装置及びサーバ選択方法は、サーバを含む仮想環境の構成を記述した第１のテンプレートと、ユーザがサーバに対して要求するスループット又はレイテンシーを示す性能要件ならびにサーバ上で動作させるＯＳ（Operating  System）の情報を示す機能要件との入力を受け付ける。そして、サーバ選択装置及びサーバ選択方法は、性能要件が第１の閾値以上のスループット又は第２の閾値以下のレイテンシーを示す性能条件に該当する場合に、サーバの種別としてベアメタルサーバを選択し、性能要件が性能条件に該当せず、かつ、機能要件が所定のＯＳ以外のＯＳ又はカスタマイズを要するＯＳを示す機能条件に該当する場合に、サーバの種別として仮想マシンを選択し、性能要件が性能条件に該当せず、かつ、機能要件が機能条件に該当しない場合に、サーバの種別としてコンテナ型仮想サーバを選択する。
【発明の効果】
【００１２】
本願が開示する実施形態の一例によれば、例えば、ユーザの性能要件を満たす仮想環境を容易に構築することができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、サーバ選択システムを含む仮想機器システムの構成の一例を示す図である。
【図２Ａ】図２Ａは、仮想機器システムにおけるサーバ選択処理の一例を示す図である。
【図２Ｂ】図２Ｂは、ユーザテナントにおいて複数の仮想サーバに機能が跨る構成の一例を示す図である。
【図３】図３は、ソフトウェア関係テーブルの一例を示す図である。
【図４】図４は、接続パターン情報テーブルの一例を示す図である。
【図５】図５は、テストケーステーブルの一例を示す図である。
【図６Ａ】図６Ａは、仮想機器システムにおけるサーバ選択処理の一例を示すシーケンス図である。
【図６Ｂ】図６Ｂは、サーバ選択装置におけるサーバ選択処理の一例を示すフローチャートである。
【図７Ａ】図７Ａは、抽象テンプレートの一例を示す図である。
【図７Ｂ】図７Ｂは、具体テンプレートの一例を示す図である。
【図８】図８は、プログラムが実行されることにより、サーバ選択装置が実現されるコンピュータの一例を示す図である。
【発明を実施するための形態】
【００１４】
［実施形態］
以下、本願が開示するサーバ選択装置、サーバ選択方法及びサーバ選択プログラムの実施形態を説明する。なお、以下の実施形態は、一例を示すに過ぎず、本願が開示する技術を限定するものではない。また、以下に示す実施形態及びその変形例は、矛盾しない範囲で適宜組合せてもよい。
【００１５】
以下の実施形態では、「ユーザ」は、ベアメタル、コンテナ、仮想マシン等の仮想機器を含むユーザ毎の仮想環境であるユーザテナントの契約者を指す。
【００１６】
以下、実施形態の説明に先立ち、「ベアメタル」、「コンテナ」、「仮想マシン」について説明する。「ベアメタル」は、ベアメタルサーバであり、仮想化されない物理マシンを指す。また、「コンテナ」は、コンテナ型仮想サーバであり、１つの物理マシンで動作するＯＳの仮想化により、ＯＳのカーネル空間を共有しつつ、物理マシンのリソースをコンテナ単位のユーザ空間毎に隔離することで１つの物理マシン上で動作する１以上の仮想サーバを指す。また、「仮想マシン」は、１つの物理マシンのハードウェアの仮想化により、物理マシンで動作するハイパーバイザーによりエミュレートされた１以上のハードウェア上で動作する仮想サーバを指す。
【００１７】
ベアメタルは、例えば、従来のDedicated  Hostingと同様である。例えば、ＩＢＭ（登録商標）のSoftLayer（登録商標）は、物理マシンに、プロビジョニングや従量課金等のクラウドの特性を加えることで、ベアメタルクラウドとしてサービス化している。また、例えば、OpenStackは、Ironicというコンポーネントがベアメタルのプロビジョニングを行う。ベアメタルは、専用の物理マシンであるため、コンテナと比較してサーバ構築の自由度が高い。また、ベアメタルは、専用の物理マシンであるため、コンテナ及び仮想マシンと比較して、性能が高い。一方、ベアメタルは、コンテナ及び仮想マシンと比較して、プロビジョニングされ起動するまでの時間が長く、また、ライブマイグレーションが出来ない。
【００１８】
コンテナは、例えば、従来から、ＶＰＳ（Virtual  Private  Server）において用いられているOpenVZ等のＯＳ仮想化技術により提供される。コンテナは、コンテナと呼ばれる単位でコンピュータリソースを隔離することで仮想化を行うが、ＯＳのカーネルを共有する点で、仮想マシンを動作させるハイパーバイザーとは異なる。コンテナは、2013年にＬＸＣ（Linux（登録商標、以下同様）  Container）を用いたDockerが登場して以来、使い勝手の良さから利用が増えている。コンテナは、カーネルの自由度はないが、プロセスを立ち上げるだけで作成されるため、ベアメタル及び仮想マシンと比較して起動時間が最も短い。また、コンテナは、仮想マシンと比較して性能劣化も小さい。また、コンテナを提供する、例えばOpenVZはライブマイグレーションが可能だが、例えばDockerやＬＸＣは現状不可である。
【００１９】
仮想マシンは、従来から、ハイパーバイザー上でハードウェアをエミュレートするハードウェア仮想化技術により提供される。仮想マシンは、エミュレートされたハードウェア上で動作するため、自由にＯＳをカスタマイズできる。ハイパーバイザーには、例えば、Ｘｅｎ、ＫＶＭ、VMware  ESX（登録商標）がある。仮想マシンは、コンテナと比較してＯＳの自由度が高い。また、仮想マシンは、ライブマイグレーションが可能である。一方、仮想マシンは、ハードウェアのエミュレーションのオーバーヘッドのため、ベアメタル及びコンテナと比較して、性能で劣る。また、仮想マシンは、コンテナと比較して、起動時間が長い。
【００２０】
また、以下の実施形態では、ベアメタル、コンテナ、仮想マシンを総称する場合、「サーバ」とする。
【００２１】
（仮想機器システムの構成）
図１は、サーバ選択システムを含む仮想機器システムの構成の一例を示す図である。仮想機器システムＳは、ユーザ端末１、サーバ選択システム１００、クラウドコントローラ２００、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３を含む。少なくともクラウドコントローラ２００、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３は、例えばデータセンタ内に設置される。
【００２２】
ユーザ端末１は、サーバ選択システム１００を操作するユーザの端末である。また、ユーザ端末１は、クラウドコントローラ２００を介してベアメタル３０１−１、及び、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３上の仮想資源を操作するユーザの端末でもある。
【００２３】
図１は、コンテナ用物理マシン３０１−２上で、コンテナ３０１ａ−２、３０１ｂ−２が動作する例を示す。また、図１は、物理マシン３０１−３上で、仮想マシン３０１ａ−３、３０１ｂ−３が動作する例を示す。また、図１は、物理マシン３０２上で、仮想ルーター３０２ａ、仮想ネットワーク３０２ｂ、仮想ロードバランサー３０２ｃが動作する例を示す。また、図１は、物理マシン３０３上で、仮想ストレージ３０３ａ、３０３ｂが動作する例を示す。コンテナ３０１ａ−２、３０１ｂ−２、仮想マシン３０１ａ−３、３０１ｂ−３、仮想ルーター３０２ａ、仮想ネットワーク３０２ｂ、仮想ロードバランサー３０２ｃ、仮想ストレージ３０３ａ、３０３ｂは、仮想機器の一例である。
【００２４】
なお、ユーザ端末１、サーバ選択システム１００は、クラウドコントローラ２００、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３と同一のデータセンタ内に設置されてもよいし、異なるデータセンタ内に設置されてもよい。
【００２５】
また、図１に示すユーザ端末１、サーバ選択システム１００、クラウドコントローラ２００、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３の数は、一例を示すに過ぎず、仮想機器システムＳの構成に応じて適切な数とすることができる。また、図１では、仮想マシン３０１ａ−３、３０１ｂ−３が動作する物理マシンを物理マシン３０１−３、仮想ルーター３０２ａ、仮想ネットワーク３０２ｂ、仮想ロードバランサー３０２ｃ等の仮想ネットワーク機器が動作する物理マシンを物理マシン３０２、仮想ストレージ３０３ａ、３０３ｂが動作する物理マシンを物理マシン３０３とする。しかし、各物理マシンへの各仮想機器の配置及び数は、これに限られるものではない。
【００２６】
（サーバ選択システムの構成）
サーバ選択システム１００は、サーバ選択装置１０、テストケースＤＢ２０を含む。サーバ選択装置１０は、ネットワーク等の所定の通信回線を介して、ユーザ端末１と接続される。また、サーバ選択装置１０は、ネットワーク等の所定の通信回線を介して、テストケースＤＢ２０と接続される。
【００２７】
テストケースＤＢ２０は、ソフトウェア関係テーブル２０ａ、接続パターン情報テーブル２０ｂ、テストケーステーブル２０ｃを有する。ソフトウェア関係テーブル２０ａは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」のカラムを有する。接続パターン情報テーブル２０ｂは、「接続パターン名」「接続定義情報」のカラムを有する。テストケーステーブル２０ｃは、「接続パターン」「機能分類」「ソフトウェアグループ」「ソフトウェア名」「テストケース」「テストケース種類」「確認対象」のカラムを有する。ソフトウェア関係テーブル２０ａ、接続パターン情報テーブル２０ｂ、テストケーステーブル２０ｃの詳細は、後述する。
【００２８】
（サーバ選択装置の構成）
サーバ選択装置１０は、抽象テンプレート及び要件解析部１１、サーバ選択部１２、具体テンプレート生成部１３、テナント生成部１４、テストケース取得部１５、テスト実行部１６を有する。
【００２９】
抽象テンプレート及び要件解析部１１は、ユーザ端末１から、Ｗｅｂブラウザ又は所定のＵＩ（User  Interface）アプリケーションを介して入力された抽象テンプレート、性能要件及び機能要件を解析する。詳細は後述するが、テンプレートは、ユーザテナントの構成を、例えばＸＭＬ（eXtensible  Markup  Language）のタグ付き言語等、ＪＳＯＮ（JavaScript（登録商標）  Object  Notation）等の形式で記述したテキストで示す構成テンプレートである。抽象テンプレートは、ベアメタル、コンテナ、仮想マシンのサーバ種別が少なくとも未設定の構成テンプレートである。ユーザテナントは、ユーザ毎に、ベアメタル３０１−１、ならびに、コンテナ用物理マシン３０１−２、物理マシン３０１−３、物理マシン３０２、物理マシン３０３上で動作する仮想機器を含んで構築されたユーザ毎のコンピューティング環境である。
【００３０】
また、性能要件は、ユーザテナントに対してユーザが要求する、例えばサーバの演算処理、入出力、ネットワーク転送等に関するスループット（応答時間）やレイテンシー（処理遅延時間）等のシステムの性能である。
【００３１】
また、機能要件は、ＯＳが、所定のＯＳ（例えばLinux）か否か、カーネルをカスタマイズしたカスタマイズＯＳか否か等の情報であり、コンテナを利用できるか否かを判定するための情報となる。
【００３２】
抽象テンプレート及び要件解析部１１は、ユーザ端末１から入力された抽象テンプレートにおいてアタッチされているボリュームで使用するボリュームイメージを解析する。例えば、抽象テンプレート及び要件解析部１１は、入力された抽象テンプレートにおいて記述されているボリュームイメージから、当該ボリュームイメージが含むソフトウェアを特定する。ここで、ソフトウェアは、ＯＳ、ミドルウェア、アプリケーションを含む。
【００３３】
ボリュームイメージは、ＯＳ、当該ＯＳ上で動作するソフトウェアのバイナリデータを含む、サーバにおける実行環境のイメージファイルである。ボリュームイメージは、例えば、仮想ストレージ３０３ａ、３０３ｂ等にマウントされるボリュームへ展開されることにより、当該ボリュームがアタッチされているサーバの動作環境が提供される。ボリュームイメージは、サービス事業者により提供されるものでもよいし、ユーザ独自のものでもよい。
【００３４】
なお、抽象テンプレート及び要件解析部１１は、ボリュームイメージがサービス事業者により提供されたものである場合には、図示しない記憶部に、当該ボリュームイメージが含むソフトウェアの情報が予め格納されており、この情報を参照することにより、当該ボリュームイメージが含むソフトウェアを特定するとしてもよい。また、抽象テンプレート及び要件解析部１１は、ボリュームイメージがサービス事業者により提供されたものではなく、例えばユーザ独自のものである場合には、ボリュームイメージを所定のボリュームへ展開し、展開したボリュームを調査することにより、当該ボリュームイメージが含むソフトウェアを特定するとしてもよい。
【００３５】
また、抽象テンプレート及び要件解析部１１は、ユーザにより入力された抽象テンプレートから、各サーバ間の接続構成を解析する。
【００３６】
サーバ選択部１２は、抽象テンプレート及び要件解析部１１により特定されたソフトウェアと、性能要件と、機能要件とに基づき、当該イメージファイルを展開して動作環境を構築するサーバのサーバ種別を、ベアメタル、コンテナ、仮想マシンのうちから選択する。
【００３７】
具体テンプレート生成部１３は、サーバ選択部１２により選択されたサーバ種別を、抽象テンプレートのサーバ種別を示す項目へ設定して、具体テンプレートを生成する。そして、具体テンプレート生成部１３は、生成した具体テンプレートを、ユーザ端末１のＷｅｂブラウザ又は所定のＵＩアプリケーションを介してユーザへ提示する。ユーザは、ユーザ端末１を介して提示された具体テンプレートを確認し、当該具体テンプレートを承認又は却下する旨をユーザ端末１からサーバ選択装置１０へ入力する。サーバ選択装置１０は、具体テンプレートが却下された場合には、再度、ユーザ端末１から抽象テンプレート、性能要件及び機能要件の入力を受け付け、これらを解析する。
【００３８】
テナント生成部１４は、ユーザにより承認された具体テンプレートをもとに、１以上のサーバを含んで構築される、当該具体テンプレートにより構成が規定されるユーザテナントの生成を、クラウドコントローラ２００へ指示する。そして、テナント生成部１４は、当該具体テンプレートに記述されるボリュームへ当該具体テンプレートに記述されるボリュームイメージを展開するようにクラウドコントローラ２００へ指示する。
【００３９】
なお、テンプレートの展開は、「OpenStack  Heat，https://wiki.openstack.org/wiki/Heat」、「Amazon  CloudFormation（登録商標、以下同様），http://aws.amazon.com/cloudformation/」，「Y．Yamato，M．Muroi，K．Tanaka  and  M．Uchimura，“Development  of  Template  Management  Technology  for  Easy  Deployment  of  Virtual  Resources  on  OpenStack”，Springer  Journal  of  Cloud  Computing，DOI：10.1186/s13677-014-0007-3，July  2014」等の既存技術を用いることができる。
【００４０】
テストケース取得部１５は、抽象テンプレート及び要件解析部１１により解析された、ユーザテナントが含む各サーバ間の接続構成及び各サーバへのインストールソフトウェアの解析結果に基づき、テストケースＤＢ２０からテストケースを取得する。具体的には、テストケース取得部１５は、各サーバへのインストールソフトウェアの解析結果が含むソフトウェアを「ソフトウェア名」「ソフトウェアグループ」「機能分類」の３つの階層で分類する。
【００４１】
最下位階層の「ソフトウェア名」は、ソフトウェアの具体的製品名及びそのバージョン情報を含む。中位階層の「ソフトウェアグループ」は、「ソフトウェア名」で特定される各ソフトウェアを、ベンダ及び／又は製品ファミリーで分類する区分である。上位階層の「機能分類」は、「ソフトウェアグループ」で区分されたソフトウェアを、ＯＳ、データベース、Ｗｅｂ等の機能で分類する区分である。
【００４２】
また、テストケース取得部１５は、抽象テンプレート及び要件解析部１１により解析された、ユーザテナントが含む各サーバ間の接続構成に基づき、ユーザテナントの環境情報が含む各ソフトウェアが実装された各サーバの「接続パターン」を判定する。
【００４３】
そして、テストケース取得部１５は、テストケーステーブル２０ｃを参照し、「接続パターン」「ソフトウェア名」「ソフトウェアグループ」「機能分類」の各階層に項目値が合致するテストケースのレコードをテストケーステーブル２０ｃから抽出する。例えば、テストケース取得部１５は、判定した「接続パターン」が「Ｗｅｂ  ３−ｔｉｅｒ」（Ｗｅｂ三層モデル）である場合、テストケーステーブル２０ｃにおいて「接続パターン」“Ｗｅｂ  ３−ｔｉｅｒ”に該当するレコードをテストケースとして抽出する。
【００４４】
また、例えば、テストケース取得部１５は、ユーザテナントにインストールされているソフトウェアの情報を分類した結果、「ソフトウェア名」“ＯＳ＃Ａ  Ｓｅｒｖｅｒ  ２０１２”が得られたとする。この場合、テストケース取得部１５は、テストケーステーブル２０ｃにおいて「ソフトウェア名」“ＯＳ＃Ａ  Ｓｅｒｖｅｒ  ２０１２”に該当するレコードをテストケースとして抽出する。
【００４５】
また、例えば、テストケース取得部１５は、ユーザテナントが含むソフトウェアの情報として、「ソフトウェアグループ」“ＯＳ＃Ａ”が得られたとする。この場合、テストケース取得部１５は、テストケーステーブル２０ｃにおいて「ソフトウェアグループ」“ＯＳ＃Ａ”に該当するレコードをテストケースとして抽出する。
【００４６】
また、例えば、テストケース取得部１５は、ユーザテナントが含むソフトウェアの情報として、「機能分類」“ＯＳ”が得られたとする。この場合、テストケース取得部１５は、テストケーステーブル２０ｃにおいて「機能分類」“ＯＳ”に該当するレコードをテストケースとして抽出する。
【００４７】
なお、テストケース取得部１５は、「接続パターン」又は「ソフトウェアグループ」又は「機能分類」のみについて、項目値が合致するテストケースのレコードをテストケーステーブル２０ｃから抽出するとしてもよい。
【００４８】
そして、テスト実行部１６は、テナント生成部１４により作成されたユーザテナントに対して、Jenkins等の従来技術を用いて、テストケース取得部１５によりテストケーステーブル２０ｃから抽出されたテストケースを実行する。なお、テスト実行部１６は、実行するテストケースの「確認対象」が“データ”である場合には、テストデータをテスト実行対象であるユーザテナントに対して設定後に、当該ユーザテナントに対してテストを実行する。テスト実行部１６が実行するテストケースの「確認対象」は、例えば“機能”“データ”等がある。
【００４９】
例えば、テストケースが、日本語Ｗｅｂページの表示であれば、パッチ適用前に例えば日本語のサンプルｈｔｍｌ等の文字表示のためのファイルを設定しておき、パッチ適用後にそのｈｔｍｌが正常表示されるか否かの確認等を行う。表示の正常確認は、パッチ適用前後の表示キャプチャの比較、パッチ適用前後の文字コード比較等、既存の手法を用いてもよい。
【００５０】
そして、テスト実行部１６は、テナント生成部１４により生成されたユーザテナントに対して実行した各テストケースの結果を分析し、テスト結果の詳細情報を、ユーザ端末１へ送信する。例えば、テスト実行部１６は、サーバ上で動作するアプリケーションが、ユーザの性能要件の項目について性能を測定し、測定した結果がユーザの性能要件を満たすか否かを判定した結果をテスト結果の詳細情報としてユーザ端末１へ送信する。
【００５１】
ユーザ端末１を操作するユーザは、テスト実行部１６から受信したテスト結果の詳細情報をもとに、当該具体テンプレートをもとに生成したユーザテナントがユーザの性能要件を満たすか否かを判定する。ユーザは、当該具体テンプレートをもとに生成したユーザテナントがユーザの性能要件を満たすと判定した場合には、ユーザ端末１からサーバ選択装置１０へ、当該ユーザテナントを実運用へ移行するように指示する。サーバ選択装置１０は、ユーザ端末１から当該ユーザテナントを実運用へ移行するように指示を受けると、クラウドコントローラ２００に対して、当該ユーザテナントを実運用へ移行するよう指示する。
【００５２】
一方、ユーザは、当該具体テンプレートをもとに生成したユーザテナントがユーザの性能要件を満たさないと判定した場合には、ユーザ端末１からサーバ選択装置１０へ、新たな抽象テンプレート、性能要件及び機能要件を入力する。抽象テンプレート及び要件解析部１１は、ユーザ端末１から新たに入力された抽象テンプレート、性能要件及び機能要件を解析する。以降、抽象テンプレート及び要件解析部１１、サーバ選択部１２、具体テンプレート生成部１３、テナント生成部１４、テストケース取得部１５、テスト実行部１６は、上記と同様の処理を繰り返す。
【００５３】
（クラウドコントローラの構成）
クラウドコントローラ２００は、制御部２０１、クラウドコントローラＤＢ２０２を有する。制御部２０１は、クラウドコントローラ２００全体の制御を実行し、クラウドコントローラ２００が提供する各種サービスを実行する。クラウドコントローラＤＢ２０２は、クラウドコントローラ２００が提供する各種サービスに関する状態や設定に関する情報を格納する。
【００５４】
クラウドコントローラ２００は、例えばOpenStack等を用いることができる。クラウドコントローラ２００は、サーバ選択装置１０のテナント生成部１４からの指示に応じて、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３に対して、ユーザテナントを構成する仮想機器の作成依頼又は削除依頼を送信する。なお、ベアメタル３０１−１上に作成されたユーザ環境は、ベアメタル３０１−１を１つの物理サーバとして動作させるが、説明の便宜上、ベアメタル３０１−１も１つの仮想機器とする。
【００５５】
ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３は、仮想機器の作成依頼又は削除依頼に応じて、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３上にそれぞれ仮想機器を作成したり、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３上からそれぞれの仮想機器を削除したりする。OpenStackのコアサービスには、Compute、Identity、Networking、Block  Storage等がある。クラウドコントローラＤＢ２０２は、コアサービスの状態や設定に関する情報を格納する。
【００５６】
（仮想機器システムにおけるサーバ選択処理）
図２Ａは、仮想機器システムにおけるサーバ選択処理の一例を示す図である。図２Ａは、クラウドコントローラ２００としてOpenStackを用いる場合を示す。また、図２Ａは、クラウドコントローラ２００の制御部２０１が、ＡＰＩ（Application  Programming  Interface）部２０１ａ、クラウド構築部２０１ｂ、仮想計算機管理部２０１ｃ、仮想ネットワーク制御部２０１ｄを有する場合を示す。
【００５７】
ＡＰＩ部２０１ａは、クラウドコントローラ２００と外部との連携を司るＡＰＩであり、OpenStackの場合は“OpenStack  API”が該当する。クラウド構築部２０１ｂは、クラウド上のリソース配置やシステム構成を定義し、システムの構築及び運用を自動化するクラウドオーケストレーション機能であり、OpenStackの場合は“Heat”が該当する。
【００５８】
仮想計算機管理部２０１ｃは、HyperVisor上で動作する仮想マシン等により適用される仮想計算機をリソースプールとして管理し、提供する機能であり、OpenStackの場合は“Nova”が該当する。
【００５９】
仮想ネットワーク制御部２０１ｄは、ＯＶＳ（Open  vSwitch）等の仮想スイッチや、仮想ルーター、仮想ネットワーク、仮想サブネット、仮想ポート等のネットワーク機能を制御対象とするコンポーネントであり、OpenStackの場合は“Neutron”が該当する。
【００６０】
また、図２Ａに示す例では、サーバ選択装置１０によりユーザテナントの生成が指示された場合に、ユーザテナント４０１が生成されるとする。なお、ユーザテナント４０１は、ＬＲ（Logical  Router：論理ルーター、仮想ルーター）４０１ａ、サーバ４０１ｂ−１〜４０１ｂ−３、ＶＯＬ（Volume：仮想ボリューム、仮想ストレージ）４０１ｃ−１〜４０１ｃ−３を有する。
【００６１】
例えば、OpenStack  Heatで用いられる具体テンプレートは、ＪＳＯＮやＨＯＴの記述で各仮想機器の属性や接続関係を示す。具体テンプレートに基づいて生成されたユーザテナント４０１は、一例として、図２Ｂに示す接続構成である。また、具体テンプレートのパースにより、ユーザテナント４０１は、図２Ｂに示す接続構成であることが分かる。
【００６２】
図２Ｂは、ユーザテナントにおいて複数の仮想サーバに機能が跨る構成の一例を示す図である。図２Ｂに示すように、ユーザテナント４０１は、ＬＲ４０１ａの配下に、Ｌ２ネットワーク４０１ｎ−１を介して、サーバ４０１ｂ−１及びサーバ４０１ｂ−２が接続される。サーバ４０１ｂ−１の配下のＶＯＬ４０１ｃ−１には、“ＯＳ＃Ｂ６．１”“Ｗｅｂ＃Ｂ２．１”“ＡＰ＃Ａ６．０”を含むボリュームイメージが展開されている。また、サーバ４０１ｂ−２の配下のＶＯＬ４０１ｃ−２には、“ＯＳ＃Ｂ６．１”“Ｗｅｂ＃Ｂ２．１”“ＡＰ＃Ａ６．０”を含むボリュームイメージが展開されている。そして、サーバ４０１ｂ−１、４０１ｂ−２、４０１ｂ−３は、Ｌ２ネットワーク４０１ｎ−２を介して接続される。また、サーバ４０１ｂ−３の配下のＶＯＬ４０１ｃ−３には、“ＯＳ＃Ｂ６．１”“ＤＢ＃Ｂ５．０”を含むボリュームイメージが展開されている。
【００６３】
図２Ｂにおいて、サーバ４０１ｂ−１、４０１ｂ−２、４０１ｂ−３のそれぞれは、配下のＶＯＬ４０１ｃ−１、４０１ｃ−２、４０１ｃ−３にそれぞれ展開されるＯＳ、ミドルウェア、アプリケーションを含むソフトウェアの性能要件及び機能要件に応じて、ベアメタル、コンテナ、仮想マシンのなかから選択されたそれぞれのサーバ種別のサーバである。
【００６４】
サーバ選択装置１０は、ユーザにより入力された抽象テンプレートから、例えば図２Ｂに示すユーザテナント４０１の各サーバ間の接続構成を解析する。サーバ選択装置１０は、抽象テンプレートをパースすると、例えば｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝という接続情報を得る。後述するように、サーバ選択装置１０は、得られた｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝という接続情報をもとに、接続パターン情報テーブル２０ｂを検索すると、「接続定義情報」“｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝”は、「接続パターン名」“Ｗｅｂ３−ｔｉｅｒ”であると認識する。
【００６５】
なお、サービス事業者は、契約情報として、ユーザテナントへアクセスするためのＩＤ（Identifier）、パスワード、アクセス方法等を管理する。
【００６６】
以下、図２Ａを参照して、仮想機器システムＳにおけるサーバ選択処理を説明する。先ず、ステップＳ１において、ユーザは、抽象テンプレート、性能要件及び機能要件を満たす具体テンプレートの提案を、サーバ選択装置１０へ依頼する。なお、上記のように、テンプレートとは、OpenStack  HeatやAmazon  CloudFormation等で利用される、仮想機器の一括プロビジョニングを行うための、構成情報が記述されたＪＳＯＮやＨＯＴ形式のテキストファイルである。
【００６７】
また、OpenStack  Heatへ入力されるテンプレートには、サーバのflavor（フレーバー、スペック情報）を指定する必要があるが、抽象テンプレートの段階ではフレーバーは未指定でよい。テンプレートには、利用するＯＳやアプリケーション等のイメージファイルの指定も行う。イメージは、サービス事業者が提供するイメージでも、ユーザ独自のイメージでもよい。ユーザは、抽象テンプレートの入力とともに、各サーバの機能要件及び性能要件を指定する。性能要件は、例えば、サーバの演算処理時間、ネットワーク転送時間、ファイル入出力時間等のスループット及び／又はレイテンシーに関する要件である。機能要件は、例えば、ＯＳが、例えばLinux以外のＯＳか、カーネルのカスタマイズが必要なＯＳか等の情報であり、コンテナが利用できるかの判定に用いる。
【００６８】
次に、ステップＳ２において、サーバ選択装置１０は、ユーザにより入力された抽象テンプレートから、各サーバ間の接続構成及び各サーバへのインストールソフトウェアを解析する。抽象テンプレートには、イメージの記載が含まれている。ユーザ独自のイメージである場合は、サーバ選択装置１０は、どのソフトウェアが入っているかの解析のため、イメージをボリュームへ一旦展開してから情報取得する。この場合、サーバ選択装置１０は、ステップＳ１でユーザからログイン情報の入力を受け付ける。サーバ選択装置１０は、解析の結果、例えば、図２Ｂのようなシステム構成を把握する。
【００６９】
次に、ステップＳ３において、サーバ選択装置１０は、ステップＳ１でユーザにより指定された性能要件に基づいてサーバタイプを選択し、サーバタイプを具体的に記述した具体テンプレートを生成し、ユーザに対して出力する。ユーザに対する具体テンプレートの出力は、抽象テンプレートの各フレーバーへ具体的なサーバ種別を指定したもので、ユーザがベアメタル、コンテナ、仮想マシンの区別がつくようになっている。
【００７０】
次に、ステップＳ４において、ユーザは、ステップＳ３においてサーバ選択装置１０により出力された具体テンプレートを確認し、問題がなければ、ユーザ端末１を介してサーバ選択装置１０へ承認を送信する。サーバ選択装置１０は、ユーザからの承認を受信後、フレーバーが指定された具体テンプレートを確定する。
【００７１】
次に、ステップＳ５において、サーバ選択装置１０は、クラウドコントローラ２００に対し、展開先テナントを指定して具体テンプレートの展開を依頼する。次に、ステップＳ６において、クラウドコントローラ２００は、具体テンプレートに記述される仮想機器群を含む指定テナントとして、ユーザテナント４０１を生成（一括プロビジョニング）する。
【００７２】
次に、ステップＳ７において、サーバ選択装置１０は、一括プロビジョニングしたユーザテナントが含む仮想機器の性能が十分であることを検証するため、生成したユーザテナント４０１に応じた性能検証テストケースを、ステップＳ２による各サーバ間の接続構成及び各サーバへのインストールソフトウェアの解析結果に基づき、テストケースＤＢ２０から自動抽出する。性能検証テストケースは、個々のサーバの性能だけでなく、複数のサーバが連携する性能（例えば、Ｗｅｂ三層システムのトランザクション処理等）を対象とするテストケースも抽出される。
【００７３】
次に、ステップＳ８において、サーバ選択装置１０は、テストケースＤＢ２０から取得したテストケースをJenkins等の既存の自動化ツールを用いて、ユーザテナント４０１に対して実行する。テストケースの実行によるユーザテナントの性能検証は、ユーザテナント４０１が含むサーバに対する性能検証を目的とするが、テストケースは、ユーザテナント４０１が含む全ての仮想機器を対象に実行される。例えば、仮想ロードバランサー配下にサーバが複数配置され、サーバにＷｅｂサーバが導入されている場合に、Ｗｅｂサーバ性能検証は、仮想ロードバランサーを介して行う。
【００７４】
そして、ステップＳ８において、サーバ選択装置１０は、実行したテストケースの結果を収集し、ユーザ毎にどのテストを行い、結果がどうであったかの集計をJenkins等の既存の自動化ツールで行う。
【００７５】
次に、ステップＳ９において、サーバ選択装置１０は、集計した情報を、ユーザ端末１を介してユーザに対してメールやＷｅｂ等で通知する。情報が通知されたユーザは、一括プロビジョニングされたユーザテナント４０１が含む全ての仮想機器が性能要件及び機能要件を満たすことを確認した後、ユーザテナント４０１の実運用を開始する。なお、ユーザは、一括プロビジョンされたユーザテナント４０１が含む仮想機器が性能要件又は機能要件を満たさない場合は、ユーザテナント４０１を、サーバ選択装置１０を介してクラウドコントローラ２００のＡＰＩ部２０１ａにより削除する。そして、ユーザは、ステップＳ１に戻り、新たに、抽象テンプレート、性能要件及び機能要件を満たす具体テンプレートの提案を、サーバ選択装置１０へ依頼する。以降、上記のステップＳ１〜Ｓ９の処理が同様に実行される。
【００７６】
（ソフトウェア関係テーブル）
図３は、ソフトウェア関係テーブルの一例を示す図である。ソフトウェア関係テーブル２０ａは、ソフトウェア、ソフトウェアを束ねた概念である「ソフトウェアグループ」、ソフトウェアグループを束ねた概念である「機能分類」に関する情報を保持している。ソフトウェア関係テーブル２０ａは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」のカラムを有する。
【００７７】
図３に示すように、例えば、「機能分類」“ＯＳ”の場合に、「ソフトウェアグループ」として“ＯＳ＃Ａ”“ＯＳ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“ＯＳ＃Ａ”グループには、“ＯＳ＃Ａ  Ｓｅｒｖｅｒ  ２０１２”“ＯＳ＃Ａ  ８．１”等がある。また、例えば、「機能分類」“ＤＢ”の場合に、「ソフトウェアグループ」として“ＤＢ＃Ａ”“ＤＢ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“ＤＢ＃Ａ”グループには、“ＤＢ＃Ａ  １１ｇ”“ＤＢ＃Ａ  １０ｇ”等がある。また、例えば、「機能分類」“Ｗｅｂ”の場合に、「ソフトウェアグループ」として“Ｗｅｂ＃Ａ”“Ｗｅｂ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“Ｗｅｂ＃Ａ”グループには、“Ｗｅｂ＃Ａ  ２．１”“Ｗｅｂ＃Ａ  ２．２”等がある。また、例えば、「機能分類」“ＡＰ”の場合に、「ソフトウェアグループ」として“ＡＰ＃Ａ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“ＡＰ＃Ａ”グループには、“ＡＰ＃Ａ  ６．０”“ＡＰ＃Ａ  ７．０”等がある。
【００７８】
（接続パターン情報テーブル）
図４は、接続パターン情報テーブルの一例を示す図である。接続パターン情報テーブル２０ｂは、「接続パターン名」「接続定義情報」のカラムを有する。図４に示す接続パターン情報テーブル２０ｂの例は、接続パターンがＷｅｂ３層（Ｗｅｂ  ３−ｔｉｅｒ）である。例えば、図４に示す｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝という「接続定義情報」は、Ｗｅｂサーバ及びアプリケーション（ＡＰ）サーバが１つのサーバに、ＤＢサーバが別のサーバにインストールされていることを示す。すなわち、｛ｘ，ｙ｝のように、１つの括弧で括られたソフトウェアは、同一のサーバに実装されていることを示し、併記される他の括弧で括られたソフトウェア要素は、他の同一のサーバに実装されていることを示す。
【００７９】
そして、１つの「接続定義情報」は、互いに連携する複数のソフトウェアが複数のサーバに分散配置された構成を示す。例えば、サーバ選択装置１０は、ユーザテナントの接続情報と、各仮サーバへのインストールソフトウェア情報と、ソフトウェア関係テーブル２０ａとから、ユーザテナントが含むサーバが｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝の配置構成であることが判定できる。そして、サーバ選択装置１０は、接続パターン情報テーブル２０ｂから、｛Ｗｅｂ，ＡＰ｝｛ＤＢ｝と合致する「接続定義情報」と対応する「接続パターン名」が“Ｗｅｂ  ３−ｔｉｅｒ”（Ｗｅｂ３層モデル）であることが判定できる。その他の配置構成についても、同様にして「接続パターン名」が特定できる。
【００８０】
（テストケーステーブル）
図５は、テストケーステーブルの一例を示す図である。テストケーステーブル２０ｃには、Jenkins等で実行可能なテストケースと、そのテストケースの属性情報を保持している。テストケーステーブル２０ｃに保持されるテストケースは、そのテストケース種別として、個別ソフトウェア毎のテストケースか、個別ソフトウェアを束ねたグループであるソフトウェアグループ毎のテストケースか、ソフトウェアグループを束ねた機能分類毎のテストケースか、複数の仮想マシンに分散配置される各機能の結合試験のテストケースかの情報を保持している。テストケーステーブル２０ｃは、「接続パターン」「機能分類」「ソフトウェアグループ」「ソフトウェア名」「テストケース」「テストケース種類」「確認対象」のカラムを有する。
【００８１】
例えば、「テストケース」“テーブルのＣＲＵＤ（Create、Read、Update、Delete）”は、ＳＱＬ（Structured  Query  Language）でサンプルデータのＣＲＵＤを行えばよいため、「機能分類」“ＤＢ”で共通的に利用できるテストケースである。また、テーブルのＣＲＵＤは、「確認対象」“機能”である。そして、ＣＲＵＤの際のスループットやレイテンシー等が測定される。
【００８２】
また、例えば、「テストケース」“日本語データ表示文字チェック”というテストケースは、ＳＱＬでデータを確認するため、「機能分類」“ＤＢ”で共通的に利用できるテストケースである。また、パッチ適用後に表示文字が正常表示されているか否かは、データ正常性確認のため、「確認対象」は“データ”である。そして、データ表示の際のスループットやレイテンシー等が測定される。
【００８３】
また、例えば、「テストケース」“管理ツールによるアクセス正常”は、「ソフトウェアグループ」“ＤＢ＃Ｂ”のＷｅｂ  ＧＵＩでのアクセスツールである場合、“ＤＢ＃Ｂ”のソフトウェアグループで共通的に利用できるテストケースであり、「確認対象」は“機能”である。そして、管理ツールによるアクセスの際のスループットやレイテンシー等が測定される。
【００８４】
また、例えば、「テストケース」“トランザクションベンチマーク”は、「接続パターン」“Ｗｅｂ  ３−ｔｉｅｒ”の接続パターンを有する仮想マシンで共通的に利用できるテストケースである。すなわち、Ｗｅｂ三層モデルの場合、テストケースとして、“トランザクションベンチマーク”、例えばＴＰＣ−Ｗ（Transaction  Processing  performance  Council  benchmark  for  Web）等が利用できる。
【００８５】
その他の「接続パターン」「機能分類」「ソフトウェアグループ」「ソフトウェア名」についても、上記と同様である。
【００８６】
（サーバ選択処理を示すシーケンス図）
図６Ａは、仮想機器システムにおけるサーバ選択処理の一例を示すシーケンス図である。先ず、ユーザ端末１は、サーバ選択装置１０に対して、抽象テンプレート、性能要件及び機能要件を入力して、抽象テンプレート、性能要件及び機能要件を満たす具体テンプレートの提案を依頼する（ステップＳ１１）。次に、サーバ選択装置１０は、ステップＳ１１で入力された抽象テンプレートから、抽象テンプレートに記述される各サーバ間の接続構成及び各サーバへのインストールソフトウェアを特定し、特定したインストールソフトウェアからサーバを選択するサーバ選択処理を実行する（ステップＳ１２）。なお、サーバ選択処理の詳細は、後述する。
【００８７】
次に、サーバ選択装置１０は、ステップＳ１２で選択したサーバ種別を記述した具体テンプレートをユーザ端末１へ送信し、ユーザに対して具体テンプレートの確認及び承認を要求する（ステップＳ１３）。次に、ユーザ端末１は、サーバ選択装置１０により送信された具体テンプレートがユーザにより承認された場合に、サーバ選択装置１０へ承認応答を送信する（ステップＳ１４）。
【００８８】
次に、サーバ選択装置１０は、ステップＳ１４でユーザにより承認された具体テンプレートを展開するよう、クラウドコントローラ２００へ依頼する（ステップＳ１５）。次に、クラウドコントローラ２００は、ステップＳ１５でサーバ選択装置１０により展開依頼された具体テンプレートを、その記述内容に従って、ベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３、３０２、３０３へ仮想機器の作成依頼を行う。
【００８９】
先ず、クラウドコントローラ２００は、具体テンプレートに含まれる仮想ストレージを仮想機器として用いる記述に従って、物理マシン３０３に対して、具体テンプレートに基づく仮想ストレージの作成依頼を送信する（ステップＳ１６）。そして、物理マシン３０３は、自装置上に、ステップＳ１６で作成依頼された仮想ストレージを作成する（ステップＳ１７）。そして、物理マシン３０３は、クラウドコントローラ２００に対して、仮想ストレージ作成応答を送信する（ステップＳ１８）。クラウドコントローラ２００及び物理マシン３０３は、具体テンプレートに規定される仮想ストレージの数だけ、ステップＳ１６〜Ｓ１８の処理を繰り返す。
【００９０】
次に、例えば、クラウドコントローラ２００は、具体テンプレートがベアメタルを仮想機器として用いる記述を含む場合に、ベアメタル３０１−１に対して、具体テンプレートに基づくユーザ環境の作成依頼を送信する（ステップＳ１９）。そして、ベアメタル３０１−１は、自装置上に、ステップＳ１９で作成依頼されたユーザ環境を、ステップＳ１７で作成された仮想ストレージを用いて作成する（ステップＳ２０）。そして、ベアメタル３０１−１は、クラウドコントローラ２００に対して、ユーザ環境作成応答を送信する（ステップＳ２１）。クラウドコントローラ２００及びベアメタル３０１−１は、具体テンプレートに規定されるベアメタルの数だけ、ステップＳ１９〜Ｓ２１の処理を繰り返す。なお、ベアメタルは、１つの物理サーバ上に１つのユーザ環境を構築する、１ユーザ専用の物理サーバであるため、複数のベアメタルにユーザ環境を作成する場合には、異なるそれぞれのベアメタルに対してユーザ環境の作成依頼が送信される。また、クラウドコントローラ２００及びベアメタル３０１−１は、具体テンプレートに規定されるベアメタルの数が０である場合には、ステップＳ１９〜Ｓ２１の処理は実行しない。
【００９１】
また、例えば、クラウドコントローラ２００は、具体テンプレートがコンテナを仮想機器として用いる記述を含む場合に、コンテナ用物理マシン３０１−２に対して、具体テンプレートに基づくユーザ環境であるコンテナの作成依頼を送信する（ステップＳ２２）。そして、コンテナ用物理マシン３０１−２は、自装置上に、ステップＳ２２で作成依頼されたコンテナを、ステップＳ１７で作成された仮想ストレージを用いて作成する（ステップＳ２３）。そして、コンテナ用物理マシン３０１−２は、クラウドコントローラ２００に対して、コンテナ作成応答を送信する（ステップＳ２４）。クラウドコントローラ２００及びコンテナ用物理マシン３０１−２は、具体テンプレートに規定されるコンテナの数だけ、ステップＳ２２〜Ｓ２４の処理を繰り返す。なお、複数のコンテナ用物理マシンにそれぞれコンテナを作成する場合には、異なるそれぞれのコンテナ用物理マシンに対してコンテナの作成依頼が送信される。また、クラウドコントローラ２００及びコンテナ用物理マシン３０１−２は、具体テンプレートに規定されるコンテナの数が０である場合には、ステップＳ２２〜Ｓ２４の処理は実行しない。
【００９２】
また、例えば、クラウドコントローラ２００は、具体テンプレートが仮想マシンを仮想機器として用いる記述を含む場合に、物理マシン３０１−３に対して、具体テンプレートに基づくユーザ環境である仮想マシンの作成依頼を送信する（ステップＳ２５）。そして、物理マシン３０１−３は、自装置上に、ステップＳ２５で作成依頼された仮想マシンを、ステップＳ１７で作成された仮想ストレージを用いて作成する（ステップＳ２６）。そして、物理マシン３０１−３は、クラウドコントローラ２００に対して、仮想マシン作成応答を送信する（ステップＳ２７）。クラウドコントローラ２００及び物理マシン３０１−３は、具体テンプレートに規定される仮想マシンの数だけ、ステップＳ２５〜Ｓ２７の処理を繰り返す。なお、複数の物理マシンに仮想マシンをそれぞれ作成する場合には、異なるそれぞれの物理マシンに対して仮想マシンの作成依頼が送信される。また、クラウドコントローラ２００及び物理マシン３０１−３は、具体テンプレートに規定される仮想マシンの数が０である場合には、ステップＳ２５〜Ｓ２７の処理は実行しない。
【００９３】
また、例えば、クラウドコントローラ２００は、具体テンプレートが仮想ルーターを仮想機器として用いる記述を含む場合に、物理マシン３０２に対して、具体テンプレートに基づく仮想ルーターの作成依頼を送信する（ステップＳ２８）。そして、物理マシン３０２は、自装置上に、ステップＳ２８で作成依頼された仮想ルーターを作成する（ステップＳ２９）。そして、物理マシン３０２は、クラウドコントローラ２００に対して、仮想ルーター作成応答を送信する（ステップＳ３０）。クラウドコントローラ２００及び物理マシン３０２は、具体テンプレートに規定される仮想ルーターの数だけ、ステップＳ２８〜Ｓ３０の処理を繰り返す。なお、複数の物理マシンに仮想ルーターをそれぞれ作成する場合には、異なるそれぞれの物理マシンに対して仮想ルーターの作成依頼が送信される。また、クラウドコントローラ２００及び物理マシン３０２は、具体テンプレートに規定される仮想ルーターの数が０である場合には、ステップＳ２８〜Ｓ３０の処理は実行しない。
【００９４】
次に、クラウドコントローラ２００は、サーバ選択装置１０に対して、具体テンプレートの展開完了を送信する（ステップＳ３１）。
【００９５】
次に、サーバ選択装置１０は、ステップＳ１２で把握した各サーバ間の接続構成及び各サーバへのインストールソフトウェアに基づき特定される「ソフトウェア名」及び／又は「接続パターン名」を引数として、テストケースＤＢ２０から「ソフトウェアグループ」「機能分類」「接続パターン」を検索し、該当の「機能分類」及び／又は「ソフトウェアグループ」及び／又は「接続パターン」と対応する「テストケース」をテストケースＤＢ２０から抽出する（ステップＳ３２及びＳ３３）。ステップＳ３３で抽出された「テストケース」は、Jenkins等のテスト自動ツールを用いて、サーバ選択装置１０により実行される。なお、サーバ選択装置１０は、「テストケース」の実行前に、性能要求検証のために必要であれば、確認用データをベアメタル３０１−１、コンテナ用物理マシン３０１−２、物理マシン３０１−３へ設定する（ステップＳ３４）。
【００９６】
次に、サーバ選択装置１０は、対象のベアメタル３０１−１、コンテナ用物理マシン３０１−２上のコンテナ、物理マシン３０１−３上の仮想マシンに対して、ステップＳ３３で抽出されたテストケースを実施する（ステップＳ３５）。そして、サーバ選択装置１０は、テスト結果を収集し、ユーザ毎のテストケース結果を、ユーザ端末１へ送信する（ステップＳ３６）。ユーザは、テストケース実施結果に基づき、ステップＳ１３で提案された具体テンプレートが妥当であるか判断できる。
【００９７】
（サーバ選択装置におけるサーバ選択処理）
図６Ｂは、サーバ選択装置におけるサーバ選択処理の一例を示すフローチャートである。図６Ｂは、図６ＡのステップＳ１２の詳細処理を示す図である。一般に、サーバの価格は、コンテナ＜仮想マシン＜ベアメタルとなる。そこで、安価なコンテナでは実現できないサーバ機能に対して、仮想マシン、ベアメタルを提案することが図６Ｂのサーバ選択処理の趣旨である。
【００９８】
図６Ｂに示すように、先ず、サーバ選択装置１０は、ユーザ端末１から、Ｗｅｂブラウザ又は所定のＵＩアプリケーションを介して入力された抽象テンプレート、性能要件及び機能要件を解析する（ステップＳ１２ａ）。次に、サーバ選択装置１０は、ステップＳ１２ａによる解析結果に基づき、サーバに対する性能要件が第１の閾値以上のスループット及び／又は第２の閾値以下のレイテンシーか否かを判定する（ステップＳ１２ｂ）。
【００９９】
サーバ選択装置１０は、サーバに対する性能要件が第１の閾値以上のスループット及び／又は第２の閾値以下のレイテンシーであると判定した場合には（ステップＳ１２ｂＹｅｓ）、ステップＳ１２ｃへ処理を移す。一方、サーバ選択装置１０は、サーバに対する性能要件が第１の閾値以上のスループット及び／又は第２の閾値以下のレイテンシーでないと判定した場合には（ステップＳ１２ｂＮｏ）、ステップＳ１２ｄへ処理を移す。
【０１００】
ステップＳ１２ｃでは、サーバ選択装置１０は、サーバ種別としてベアメタルを選択し、ステップＳ１２ｇへ処理を移す。
【０１０１】
ステップＳ１２ｄでは、サーバ選択装置１０は、ステップＳ１２ａによる解析結果に基づき、サーバに対する機能要件が、所定のＯＳ（例えばLinux等のカスタマイズされていないＯＳ）以外のＯＳ又はカスタマイズＯＳであることを要するか否かを判定する。サーバ選択装置１０は、ＯＳが、所定のＯＳ以外のＯＳ又はカスタマイズＯＳであることを要すると判定した場合に（ステップＳ１２ｄＹｅｓ）、ステップＳ１２ｅへ処理を移す。一方、サーバ選択装置１０は、サーバに対する機能要件が、所定のＯＳ以外のＯＳ及びカスタマイズＯＳであることを要しないと判定した場合に（ステップＳ１２ｄＮｏ）、ステップＳ１２ｆへ処理を移す。
【０１０２】
ステップＳ１２ｅでは、サーバ選択装置１０は、サーバ種別として仮想マシンを選択し、ステップＳ１２ｇへ処理を移す。また、ステップＳ１２ｆでは、サーバ選択装置１０は、サーバ種別としてコンテナを選択し、ステップＳ１２ｇへ処理を移す。
【０１０３】
ステップＳ１２ｇでは、サーバ選択装置１０は、ステップＳ１２ｃ、Ｓ１２ｅ、Ｓ１２ｆで選択したサーバ種別を、ステップＳ１２ａで解析した抽象テンプレートにおいてサーバ種別を示すフレーバーへ設定し、具体テンプレートを生成する。ステップＳ１２ｇが終了すると、サーバ選択装置１０は、図６ＡのステップＳ１３へ処理を移す。
【０１０４】
すなわち、図６Ｂに示すサーバ選択処理では、まず、スループット、リアルタイム性が強く求められるサーバである場合には、ベアメタルを選択する。上記の第１の閾値及び第２の閾値は、各サーバの実性能から決まる値で、ユーザが指定する性能要件が、第１の閾値以上のスループット又は第２の閾値以下のレイテンシーの場合は、ベアメタルを選択する。具体的には、Ｗｅｂショッピングシステムのオーダー管理ＤＢ等は、強い一貫性が求められ、分散処理させることが困難であるため、一定以上の規模のシステムの場合には、ベアメタルを選択することが適切となる。一方、強い一貫性が求められず、Eventual  Consistencyを許容するＤＢシステムであれば、memcached等の分散Key-Value型ＤＢによりスケールアウトすることが可能であるため、コンテナや仮想マシンが選択対象となる。
【０１０５】
図６Ｂに示すサーバ選択処理では、次に、サーバのＯＳによりサーバ種別の絞り込みを行う。具体的には、サーバＯＳが、例えば通常のLinuxでよいか、Linux以外やLinuxであってもカスタマイズが必要かのユーザの機能要件を参照し、Linux以外やLinuxであってもカスタマイズが必要である場合は仮想マシンを選択する。図６Ｂに示すサーバ選択処理では、最後に、Ｗｅｂサーバ等、スケールアウトが可能かつLinuxで問題が無いサーバに関しては、コンテナが選択される。すなわち、従来は、同じサーバ種別のサーバのなかからより近接するサーバを選択していたが、実施形態は、複数のサーバ種別のサーバのなかからより近接するサーバを選択することができる。
【０１０６】
（抽象テンプレート及び具体テンプレート）
図７Ａは、抽象テンプレートの一例を示す図である。また、図７Ｂは、具体テンプレートの一例を示す図である。実施形態は、ユーザから指定される、図７Ａに示すような抽象テンプレートから、サーバ接続構成とインストールソフトウェアを判定した後、ユーザの機能要件、性能要件により、サーバ種別の絞り込みを行い、構成提案として、図７Ｂに示すような具体テンプレートを提供する。
【０１０７】
図７Ａは、一例として挙げる抽象テンプレートｔ１の一部で、OpenStack  Heatで使われるＪＳＯＮテンプレートのフォーマットで記述されている。抽象テンプレートｔ１は、サーバ“vm-1”の構成を定義する抽象テンプレートである。抽象テンプレートｔ１は、サーバ種別を示す“flavor”が指定されていない（枠囲み部分ｐ１参照）。また、抽象テンプレートｔ１は、ボリュームとして利用されるイメージが指定されており（枠囲み部分ｐ２及びｐ３参照）、指定イメージからソフトウェアが判断される。図７Ａに示す例では、CentOS6がイメージとして指定されている（枠囲み部分ｐ３参照）。抽象テンプレートｔ１は、サーバ“vm-1”の属性、ネットワーク情報、使用するイメージファイル等を定義する。複数のサーバについて抽象テンプレートを定義する場合は、抽象テンプレートｔ１をサーバ毎に繰り返して記述する。
【０１０８】
図７Ｂは、一例として挙げる具体テンプレートｔ２の一部で、OpenStack  Heatで使われるＪＳＯＮテンプレートのフォーマットで記述されている。具体テンプレートｔ２は、サーバ“vm-1”の構成を定義する具体テンプレートである。具体テンプレートｔ２は、サーバ“vm-1”のサーバ種別としてベアメタルが選択されたため、サーバ種別を示す“flavor”に、例えばベアメタルを示す“baremetal”が指定される（枠囲み部分ｐ４参照）。また、サーバ“vm-1”のサーバ種別として、例えばＣＰＵのコア数がａ個、ＲＡＭ（Random  Access  Memory）の容量がｂＧＢであるコンテナが選択される場合は、“flavor”に、例えば“container（ＣＰＵ：ａ，ＲＡＭ：ｂＧＢ）”が指定される。同様に、サーバ“vm-1”のサーバ種別として、例えばＣＰＵのコア数がｃ個、ＲＡＭの容量がｄＧＢである仮想マシンが選択される場合は、“flavor”に、例えば“virtualmachine（ＣＰＵ：ｃ，ＲＡＭ：ｄＧＢ）”が指定される。すなわち、コンテナ及び仮想マシンには、ＣＰＵのコア数及びＲＡＭの容量等のリソース量が異なる複数のflavorがある。よって、サーバ“vm-1”のサーバ種別として、コンテナ又は仮想マシンが選択される場合には、サーバ種別に、ＣＰＵのコア数及びＲＡＭの容量等のリソース量の規定を含んだflavorが指定される。なお、具体テンプレートｔ２におけるボリュームとして利用されるイメージの指定は、抽象テンプレートｔ１と同様である（枠囲み部分ｐ２及びｐ３参照）。具体テンプレートｔ２は、サーバ“vm-1”のサーバ種別、属性、ネットワーク情報、使用するイメージファイル等を定義する。複数のサーバについて具体テンプレートを定義する場合は、具体テンプレートｔ２をサーバ毎に繰り返して記述する。
【０１０９】
（実施形態による効果）
実施形態によれば、サーバに対するユーザの性能要件、機能要件に適切なサーバ種別が自動的に選択されるため、サーバ設計を行う工数が低減できる。更に、実施形態は、提案された具体テンプレートをユーザが承認した後に一括プロビジョニングを行い、一括プロビジョニングした仮想資源群に対する性能検証のためのテストケースを自動抽出して実行する。このため、実施形態では、ユーザは、クラウドで構築されたシステムの性能が性能要求を満たすことを容易に確認することができ、性能検証のための工数を低減できる。また、実施形態において、ユーザは、適切なサーバ種別を選択して仮想環境を構築し、構築した仮想環境が性能要件及び機能要件を満たすか否かの確認し、仮想環境の実運用開始まで、オンデマンドで、容易に行うことができる。
【０１１０】
（実施形態の変形例）
実施形態は、抽象テンプレートをパースした結果に基づき、各サーバ間の接続構成及び各サーバへインストールされるソフトウェアを把握する。しかし、これに限らず、抽象テンプレートへサーバ種別を設定した具体テンプレートをパースした結果に基づき、各サーバ間の接続構成及び各サーバへインストールされるソフトウェアを把握してもよい。または、具体テンプレートに基づき生成したユーザテナントのボリューム内を調査し、ユーザテナントのどの仮想機器にどのようなソフトウェアがどのような接続関係で実装されているかを分析した結果をもとに、各サーバ間の接続構成及び各サーバへインストールされるソフトウェアを把握するとしてもよい。
【０１１１】
また、実施形態は、サーバ種別が未設定の抽象テンプレートへ、サーバ種別選択処理により選択されたサーバ種別を設定して具体テンプレートを生成する。しかし、これに限らず、サーバ種別が設定済みのテンプレートに対して、サーバ種別選択処理により選択されたサーバ種別を上書き設定して具体テンプレートを生成するとしてもよい。
【０１１２】
また、実施形態は、サーバ種別選択処理により、ベアメタル、コンテナ、仮想マシンのいずれかのサーバ種別を選択する。しかし、これに限らず、サーバ種別を選択するとともに、予め用意された同一のサーバ種別毎の性能（例えばＣＰＵコア数、メモリ容量、通信インターフェースの種別や性能等）が異なる個々のサーバを、各サーバ間の接続構成及び各サーバへインストールされるソフトウェアや、性能要件、機能要件に応じて更に選択するようにしてもよい。
【０１１３】
また、実施形態は、「接続パターン」として、Ｗｅｂ３層モデルを一例としてあげたが、これに限らず、送信サーバ、受信サーバ、ウィルスチェックサーバ等の複数の電子メールサーバの各機能を、複数の仮想マシンに分散して配置するような例に対しても適用可能である。すなわち、実施形態は、少なくとも２つ以上の機能を少なくとも２つ以上の仮想マシンに分散して配置して１つの機能を提供する場合にも適用可能である。
【０１１４】
（サーバ選択装置の装置構成について）
図１に示すサーバ選択装置１０の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、サーバ選択装置１０の機能の分散及び統合の具体的形態は図示のものに限られず、全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合して構成することができる。
【０１１５】
また、サーバ選択装置１０において行われる各処理は、全部又は任意の一部が、ＣＰＵ（Central  Processing  Unit）等の処理装置及び処理装置により解析実行されるプログラムにて実現されてもよい。また、サーバ選択装置１０において行われる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。
【０１１６】
また、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともできる。もしくは、実施形態において説明した各処理のうち、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。
【０１１７】
（プログラムについて）
図８は、プログラムが実行されることにより、サーバ選択装置が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。コンピュータ１０００において、これらの各部はバス１０８０によって接続される。
【０１１８】
メモリ１０１０は、ＲＯＭ（Read  Only  Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１０６１に接続される。
【０１１９】
ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、サーバ選択装置１０の各処理を規定するプログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、例えばハードディスクドライブ１０３１に記憶される。例えば、サーバ選択装置１０における機能構成と同様の情報処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。
【０１２０】
また、上記の実施形態での処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
【０１２１】
なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local  Area  Network）、ＷＡＮ（Wide  Area  Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【０１２２】
以上の実施形態ならびに実施形態の変形例は、本願が開示する技術に含まれると同様に、請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０１２３】
Ｓ              仮想機器システム
１              ユーザ端末
１０            サーバ選択装置
１１            抽象テンプレート及び要件解析部
１２            サーバ選択部
１３            具体テンプレート生成部
１４            テナント生成部
１５            テストケース取得部
１６            テスト実行部
２０            テストケースＤＢ
２０ａ            ソフトウェア関係テーブル
２０ｂ            接続パターン情報テーブル
２０ｃ            テストケーステーブル
１００            サーバ選択システム
２００            クラウドコントローラ
３０１−１          ベアメタル
３０１−２          コンテナ用物理マシン
３０１ａ−１、３０１ｂ−１  コンテナ
３０１−３、３０２、３０３  物理マシン
３０１ａ−３、３０１ｂ−３  仮想マシン
３０２ａ          仮想ルーター
３０２ｂ          仮想ネットワーク
３０２ｃ          仮想ロードバランサー
３０３ａ、３０３ｂ      仮想ストレージ
１０００          コンピュータ
１０１０          メモリ
１０２０          ＣＰＵ
【図１】
2016167086.tif 000003
【図２Ａ】
2016167086.tif 000004
【図２Ｂ】
2016167086.tif 000005
【図３】
2016167086.tif 000006
【図４】
2016167086.tif 000007
【図５】
2016167086.tif 000008
【図６Ａ】
2016167086.tif 000009
【図６Ｂ】
2016167086.tif 000010
【図７Ａ】
2016167086.tif 000011
【図７Ｂ】
2016167086.tif 000012
【図８】
2016167086.tif 000013
【国際調査報告】
2016167086.tif 000014
2016167086.tif 000015