JP6382705B2 - 仮想機器試験装置、仮想機器試験方法及び仮想機器試験プログラム - Google Patents

Description

本発明は、仮想機器試験装置、仮想機器試験方法及び仮想機器試験プログラムに関する。

近年、ホスティングサービス、ＩａａＳ（Infrastructure as a Service）型クラウドサービス等のような、ＶＰＳ（Virtual Private Server）や仮想資源を提供するサービスが普及している。ユーザは、サービス事業者と契約することで、仮想マシン、仮想ネットワーク、仮想ルーター、仮想ストレージ、仮想ロードバランサー等の仮想機器を利用できる。例えば、ユーザは、データベース、Ｗｅｂサーバ、メールサーバ、アプリケーションサーバ等のソフトウェアを仮想マシン上で動作させることにより、自身でハードウェアを用意せずとも、自身専用のサーバを構築できる。

ここで、仮想マシン等で利用されるＯＳやソフトウェアには、セキュリティ脆弱性の解消や機能追加などのため修正プログラム（以下、「ソフトウェアパッチ」又は「パッチ」と呼ぶ）が、ソフトウェア製造元より定期的に提供されている。これらのソフトウェアパッチの仮想マシンへの適用は、ユーザが選択して適用する場合が多く、適用はユーザ責任としているのが通常である。なぜなら、サービス事業者がこれらソフトウェアパッチを仮想マシン等に自動配布した場合に、何らかの不具合が生じる可能性があるためである。

そのため、ユーザは、仮想マシン等に対してソフトウェアパッチを適用前に正常に動作していたソフトウェアによるサービスが、適用後も正常に動作するかの確認が必要であり、ユーザの負担となっている。そこで、ソフトウェアパッチを、ユーザの代わりにサービス事業者が検証して、パッチ適用後もユーザのサービスが正常に動作することを確認することで、ユーザの負担を低減できる。例えば、ユーザのサービスが正常に動作する試験を自動化するツールとして、JenkinsやSelenium等がある。

Alan Mark Berg,"Jenkins Continuous Integration Cookbook"，Packt Publishing，June 2012. A．Holmes and M．Kellogg，"Automating Functional Tests Using Selenium"，IEEE Agile Conference 2006，July，2006. Fuyang Peng，Bo Deng and Chao Qi，"CASTE：a Cloud-Based Automatic Software Test Environment"，World Academy of Science，Engineering and Technology Vol．6 2012-11-22. D．Willmor and S．M．Embury，"An Intensional Approach to the Specification of Test Cases for Database Applications"，In proceedings of the 28 the international conference on Software engineering，pp.102-111．ACM．2006.

しかしながら、上述の従来技術では、サービス事業者が、仮想機器を含むユーザ毎のユーザテナント内で動作するソフトウェアに対する修正プログラムの適用について、適用後の正常性確認を行うために、ユーザテナント毎に試験パターンの組合せを事前に準備しておく必要がある。このため、ユーザ数が多い場合に、事前に準備しておく必要がある試験パターンの組合せが増大し、修正プログラムの適用の正常性確認を容易に行うことができない。

また、上述の従来技術は、同じテストケースを繰り返し実行するためのツールに過ぎず、サービス事業者が個々に異なる設定のユーザテナントに対する修正プログラムの適用の正常性確認を効率よく行うことはできない。例えば、ユーザＸがその仮想マシンにＯＳ（Operating System）としてＯＳ＃Ａ 2012 serverを、データベースアプリケーションとしてＤＢ＃Ｂ ５．１を導入しており、ユーザＹがその仮想マシンにＯＳとしてＯＳ＃Ａ 2012 serverを、ＷｅｂアプリケーションとしてＷｅｂ＃Ａ ２．１を導入している場合に、ユーザＸとユーザＹとで、適用するＯＳ＃Ａ 2012 serverのパッチは同じであっても、パッチ後も正常に動作しているかを確認する対象であるサービスを提供するアプリケーションが、ユーザＸはＤＢ＃Ｂ ５．１であり、ユーザＹはＷｅｂ＃Ａ ２．１であるように異なるため、正常性確認試験の内容が異なる。

よって、サービス事業者にとって、ユーザ毎に設定が異なるユーザテナントに対して、パッチ適用後の正常性確認を検証することは、非常に大きな検証コストがかかる。このため、ユーザ毎に設定が異なるユーザテナントに対するパッチの検証を実施しているサービス事業者は市中に無い。

本願が開示する実施形態の一例は、上記に鑑みてなされたものであって、仮想機器を含むユーザ毎のユーザテナントに対する修正プログラムの適用の正常性確認を容易に行うことを目的とする。

本願が開示する実施形態の一例は、仮想機器試験装置は、環境情報抽出部、取得部、実行部を備える。環境情報抽出部は、物理マシン上で動作する仮想機器を含むユーザ環境において動作するソフトウェアのソフトウェア情報を含むユーザ環境に関する環境情報をユーザ環境から抽出する。取得部は、環境情報抽出部により抽出された環境情報をもとに、環境情報に対応するユーザ環境で動作するソフトウェアを、ソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に分類し、予め登録したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンの中から、前記分類したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に対応し、共通して実行できる試験パターンをデータベースから取得する。実行部は、環境情報抽出部により抽出された環境情報に対応するユーザ環境に対して、ユーザ環境で動作するソフトウェアの修正プログラムを適用後、取得部により取得されたソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンを実行し、実行した試験パターンの実行結果を収集して分析し、各試験パターンの実行結果の正常又は異常の判定結果を出力する。

本願が開示する実施形態の一例によれば、例えば、ユーザ毎の仮想機器に対する修正プログラムの適用の正常性確認を容易に行うことができる。

図１は、パッチ正常性確認システムを含む仮想機器システムの構成の一例を示す図である。 図２は、仮想機器システムにおけるパッチ正常性確認処理の一例を示す図である。 図３は、ソフトウェア関係テーブルの一例を示す図である。 図４は、テストケーステーブルの一例を示す図である。 図５は、仮想機器システムにおけるパッチ正常性確認処理の一例を示すシーケンス図である。 図６は、プログラムが実行されることにより、パッチ正常性確認装置が実現されるコンピュータの一例を示す図である。

［実施形態］
以下、本願が開示する仮想機器試験装置、仮想機器試験方法及び仮想機器試験プログラムの実施形態を説明する。なお、以下の実施形態は、一例を示すに過ぎず、本願が開示する技術を限定するものではない。また、以下に示す実施形態及びその変形例は、矛盾しない範囲で適宜組合せてもよい。以下、「パッチ」は、ＯＳ（Operating System）、アプリケーション等のソフトウェアの不具合修正又は機能向上等のために、定期的又は不定期に配布される修正プログラムを言う。また、以下では、「ユーザ」は、仮想マシン等の仮想機器を含む仮想環境であるユーザテナントの契約者を指す。また、以下では、「オペレータ」は、仮想マシン等の仮想機器を含む仮想環境であるユーザテナントの提供サービスを行うサービス事業者の要員を指す。

（仮想機器システムの構成）
図１は、パッチ正常性確認システムを含む仮想機器システムの構成の一例を示す図である。仮想機器システムＳは、オペレータ端末１、ユーザ端末２、検証起動装置３、パッチ正常性確認システム１００、クラウドコントローラ２００、物理マシン３０１〜３０３を含む。少なくともクラウドコントローラ２００、物理マシン３０１〜３０３は、例えばデータセンタ内に設置される。オペレータ端末１は、パッチ正常性確認システム１００を操作するオペレータの端末である。ユーザ端末２は、クラウドコントローラ２００を介して物理マシン３０１〜３０３上の仮想資源を操作するユーザの端末である。オペレータ端末１、ユーザ端末２、検証起動装置３、パッチ正常性確認システム１００は、クラウドコントローラ２００及び物理マシン３０１〜３０３と同一のデータセンタ内に設置されてもよいし、異なるデータセンタ内に設置されてもよい。また、検証起動装置３は、検証起動プログラム等が動作するコンピュータ等の装置である。

なお、図１に示す、オペレータ端末１、ユーザ端末２、検証起動装置３、パッチ正常性確認システム１００、クラウドコントローラ２００、物理マシン３０１〜３０３の数は、一例を示すに過ぎず、仮想機器システムＳの構成に応じて適切な数とすることができる。また、図１では、説明の便宜上、仮想マシンが動作する物理マシンを物理マシン３０１、仮想ネットワーク機器が動作する物理マシンを物理マシン３０２、仮想ストレージが動作する物理マシンを物理マシン３０３とする。しかし、各仮想マシンへの各仮想機器の配置は、これに限られるものではない。

パッチ正常性確認システム１００は、パッチ正常性確認装置１０、テストケースＤＢ（Data Base）２０を含む。パッチ正常性確認装置１０は、ネットワーク等の所定の通信回線を介して、オペレータ端末１と接続される。また、パッチ正常性確認装置１０は、ネットワーク等の所定の通信回線を介して、テストケースＤＢ２０が接続される。

テストケースＤＢ２０は、ソフトウェア関係テーブル２０ａ、テストケーステーブル２０ｂを有する。ソフトウェア関係テーブル２０ａは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」のカラムを有する。テストケーステーブル２０ｂは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」「テストケース」「テストケース種類」「確認対象」のカラムを有する。ソフトウェア関係テーブル２０ａ及びテストケーステーブル２０ｂの詳細は、後述する。

パッチ正常性確認装置１０は、テンプレート抽出部１１、テナント複製部１２、環境情報抽出部１３、テストケース取得部１４、テスト実行部１５を有する。テンプレート抽出部１１は、オペレータ端末１からのオペレータの指示、もしくは、検証起動装置３の指示により、パッチ正常性確認対象のソフトウェアが動作するユーザを特定し、特定したユーザのユーザテナントの構成情報を当該ユーザテナントから抽出する。なお、検証起動装置３の指示によりパッチ正常性確認装置１０がユーザテナントの構成情報を抽出する場合は、検証起動装置３は、次のように動作する。すなわち、検証起動装置３は、サービス事業者がデータベース等で管理するユーザ毎の契約情報に基づき、検証するユーザを定期的（例えば１か月に１回等）に抽出し、抽出したユーザについてパッチ正常性確認装置１０に検証を依頼することで、自動的に検証を行う。この場合、契約情報は、「定期的に（例えば１か月に１回等）検証する」等の情報を含む。「ユーザテナント」は、ユーザ毎に１以上の物理マシン上に構築された１つの仮想環境、すなわち仮想マシン等の仮想機器を含んで構築された一体のコンピュータ環境である。「構成情報」は、ユーザ毎のテナントの構成を、例えばＸＭＬ（Extensible Markup Language）のタグ付き言語等、ＪＳＯＮ（JavaScript（登録商標） Object Notation）等の形式で記載されたテキストで示すテンプレートである。

テナント複製部１２は、テンプレート抽出部１１により抽出された構成情報をもとに、１以上の物理マシン上に構築される、当該構成情報で構成が規定されるユーザテナントの複製を、同一の物理マシン又は他の物理マシン上に作成する。

環境情報抽出部１３は、テナント複製部１２により作成されたユーザテナントの複製のボリューム内を調査し、当該ユーザテナントの複製にインストールされているソフトウェアの情報を含む、当該ユーザテナントの環境情報を抽出する。そして、テストケース取得部１４は、抽出した環境情報を、ソフトウェア関係テーブル２０ａを参照して分析し、当該ソフトウェアの情報に規定されるソフトウェアを「ソフトウェア名」「ソフトウェアグループ」「機能分類」の３つの階層で分類する。

最下位階層の「ソフトウェア名」は、ソフトウェアの具体的製品名及びそのバージョン情報を含む。中位階層の「ソフトウェアグループ」は、「ソフトウェア名」で特定される各ソフトウェアを、ベンダ及び／又は製品ファミリーで分類する区分である。上位階層の「機能分類」は、「ソフトウェアグループ」で区分されたソフトウェアを、ＯＳ、データベース、Ｗｅｂ等の機能で分類する区分である。

そして、テストケース取得部１４は、テストケーステーブル２０ｂを参照し、「ソフトウェア名」「ソフトウェアグループ」「機能分類」の各階層に項目値が合致するテストケースのレコードをテストケーステーブル２０ｂから抽出する。例えば、テストケース取得部１４は、環境情報抽出部１３により抽出されたボリューム内の環境情報から分析された、ユーザテナントにインストールされているソフトウェアの情報を分類した結果、「ソフトウェア名」“ＯＳ＃Ａ Ｓｅｒｖｅｒ ２０１２”が得られたとする。この場合、テストケース取得部１４は、テストケーステーブル２０ｂにおいて「ソフトウェア名」“ＯＳ＃Ａ Ｓｅｒｖｅｒ ２０１２”に該当するレコードをテストケースとして抽出する。

また、例えば、テストケース取得部１４は、抽出した環境情報に規定されるソフトウェアの情報を分類した結果、「ソフトウェアグループ」“ＯＳ＃Ａ”が得られたとする。この場合、テストケース取得部１４は、テストケーステーブル２０ｂにおいて「ソフトウェアグループ」“ＯＳ＃Ａ”に該当するレコードをテストケースとして抽出する。

また、例えば、テストケース取得部１４は、抽出した環境情報に規定されるソフトウェアの情報を分類した結果、「機能分類」“ＯＳ”が得られたとする。この場合、テストケース取得部１４は、テストケーステーブル２０ｂにおいて「機能分類」“ＯＳ”に該当するレコードをテストケースとして抽出する。

なお、テストケース取得部１４は、「ソフトウェアグループ」又は「機能分類」のみについて、項目値が合致するテストケースのレコードをテストケーステーブル２０ｂから抽出するとしてもよい。

そして、テスト実行部１５は、テナント複製部１２により作成されたユーザテナントの複製に対して「パッチ」を適用する。その後、テスト実行部１５は、テストケース取得部１４によりテストケーステーブル２０ｂから抽出されたテストケースを、テナント複製部１２により作成されたユーザテナントの複製に対して実行する。なお、テスト実行部１５は、実行するテストケースの「確認対象」が“データ”である場合には、テストデータをテスト実行対象であるユーザテナントの複製に対して設定後に、パッチを配布し、ユーザテナントの複製に対してテストを実行する。テスト実行部１５が実行するテストケースの「確認対象」は、例えば“機能”“データ”等がある。

そして、テスト実行部１５は、テナント複製部１２により複製されたユーザテナントの複製に対して実行した各テストケースの結果を分析し、テスト結果の詳細情報とともに正常又は異常の判定結果を、オペレータ端末１へ送信する。このようにして、オペレータ端末１を操作するオペレータは、ユーザテナントに対して「パッチ」を適用しても、正常動作が維持されるか否かを判定できる。オペレータは、パッチの適用によっても正常動作が維持されると判定できる場合には、オペレータ端末１から、複製元のユーザテナントに対してパッチを適用するように指示する。

一般にパッチは、仮想マシンとそのデータが保持される仮想ストレージにのみ配布されるが、パッチ適用正常性確認は仮想マシン及び仮想マシン以外の仮想ルーター、仮想ネットワーク、仮想ロードバランサー、仮想ストレージ等の仮想機器を含む一体として構築されたユーザテナント全体をパッチ適用正常性確認の対象とする。これは、ユーザテナント全体のシステム正常性を確認することが必要だからである。例えば、仮想ロードバランサー配下に２台の仮想マシンが動作している場合は、仮想ロードバランサーを介して仮想マシンにアクセスできることを確認する必要がある。

なお、パッチ正常性確認装置１０は、ユーザテナントの複製に対してパッチを適用して、ユーザテナントの複製の正常動作が維持されると判定される場合には、オペレータの指示によらず、本番のユーザテナントに対してパッチを自動的に適用するとしてもよい。

クラウドコントローラ２００は、制御部２０１、クラウドコントローラＤＢ２０２を有する。制御部２０１は、クラウドコントローラ２００全体の制御を実行し、クラウドコントローラ２００が提供する各種サービスを実行する。クラウドコントローラＤＢ２０２は、クラウドコントローラＤＢ２０２が提供する各種サービスに関する状態や設定に関する情報を格納する。

クラウドコントローラ２００は、例えば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：論理ルーター、仮想ルーター）４０１ａ、ＶＭ（Virtual Machine：仮想マシン）４０１ｂ−１〜４０１ｂ−２、ＶＯＬ（Volume：仮想ボリューム、仮想ストレージ）４０１ｃ−１〜４０１ｃ−２を有する。また、複製テナント４０２は、ＬＲ４０２ａ、ＶＭ４０２ｂ−１〜４０２ｂ−２、ＶＯＬ４０２ｃ−１〜４０２ｃ−２を有する。

サービス事業者は、ユーザ毎に、「“ＯＳ＃Ａ”のパッチリリース時にパッチ適用後の正常性検証を行う」等の契約情報や、ユーザテナント内の仮想マシンで用いるＯＳ等の構成情報を管理しており、その情報を用いて、パッチの対象ユーザを事前抽出する。なお、サービス事業者は、契約情報として、ユーザの仮想マシンやボリュームへアクセスするためのＩＤ（Identifier）、パスワード、アクセス方法等も管理する。

そして、オペレータは、オペレータ端末１を操作し、パッチとパッチ配布対象のユーザテナントをパッチ正常性確認機器１０に対して指定する（ステップＳ１）。なお、ステップＳ１における「パッチとパッチ配布対象のユーザテナントのパッチ正常性確認機器１０に対する指定」は、ユーザ毎の契約情報に基づいて検証起動装置３により実行されてもよい。そして、パッチ正常性確認装置１０は、クラウドコントローラ２００のＡＰＩ部２０１ａを介して、指定されたユーザのテナントを複製するために、ユーザテナントのテンプレートを抽出する（ステップＳ２）。

テンプレートとはOpenStack Heat、Amazon CloudFormation（登録商標）等で利用される、仮想機器の一括作成を行うための、仮想機器の構成情報が記載されたテキストファイルである。クラウドコントローラ２００に対して、抽出されたテンプレートの展開を依頼すると、クラウドコントローラ２００は、ユーザテナントの仮想機器と同じ構成の仮想機器を、指定された別テナントとして作成する。例えば、ユーザテナント４０１の複製として、複製テナント４０２が作成される（ステップＳ３）。

なお、テンプレート抽出と展開は、「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」等の既存技術を用いることができる。

次に、パッチ正常性確認装置１０は、作成された複製テナント４０２内の仮想マシン４０２ｂ−１〜４０２ｂ−２、ＶＯＬ４０２ｃ−１〜４０２ｃ−２内を調査し、どのソフトウェアがインストールされているかを示す環境情報を取得する（ステップＳ４）。なお、ボリュームにアクセスする際のパスワード等は、事前登録されている、もしくは、オペレータ手動実行時に登録される。

そして、パッチ正常性確認装置１０は、取得した環境情報をもとに、仮想マシンへのパッチ適用後に実行するテストケースをテストケースＤＢ２０（図１参照）より取得する（ステップＳ５）。

そして、パッチ正常性確認装置１０は、パッチを複製した複製テナント４０２のＶＭ４０２ｂ−１〜４０２ｂ−２へ適用する。パッチ配布及び適用は、例えばＯＳがＷｉｎｄｏｗｓ（登録商標）であれば、Windows Update（登録商標）等の従来のパッチ適用技術を用いることができる。

そして、パッチ正常性確認装置１０は、パッチ適用後の複製テナント４０２に対して、ステップＳ５で取得したテストケースを実行する（ステップＳ６）。ここで、テストケースは、パッチ適用後に機能が正常に動作するかの機能確認と、パッチ適用前のデータがパッチ適用後も正常か否かのデータ確認の２種類に大きく分けられる。データ確認については、パッチ適用前に確認用データを準備し、パッチ適用後に確認が行われる。その場合は、ステップＳ５を終えて、パッチ配布する前に、確認用データを複製テナントである複製テナント４０２に対して設定する。

例えば、テストケースが、日本語Ｗｅｂページの表示であれば、パッチ適用前に例えば日本語のサンプルｈｔｍｌ等の文字表示のためのファイルを設定しておき、パッチ適用後にそのｈｔｍｌが正常表示されるか否かの確認等を行う。表示の正常確認は、パッチ適用前後の表示キャプチャの比較、パッチ適用前後の文字コード比較等、既存の手法を用いてもよい。

そして、パッチ正常性確認装置１０は、取得したテストケースの実行について、Jenkins等の従来技術により、テストケースの実行が可能である。そして、パッチ正常性確認装置１０は、実行したテストケースの結果を収集し、ユーザ毎に、行ったテスト、及び、テストの実行結果を集計する。そして、パッチ正常性確認装置１０は、集計した情報を、オペレータに通知してもよいし、ユーザにメール等で通知してもよい（ステップＳ７）。また、パッチ正常性確認装置１０は、集計した情報が、全てのテストが正常を示す情報であった場合は、パッチ配布してもユーザサービスには問題がないため、ユーザテナントへパッチを配布してもよい。

そして、パッチ正常性確認装置１０は、検証が終わった仮想機器をクラウドコントローラ２００のＡＰＩ部２０１ａを介して削除する（ステップＳ８）。検証が終わった仮想機器を削除することにより、複製した仮想機器が物理リソースを圧迫することを抑えることができる。ただし、ステップＳ８を実行せず、検証が終わった仮想機器を削除しなくてもよい。ユーザテナントの仮想機器を複製する時間がかかるため、パッチ検証を早く行いたい場合は、事前に仮想機器を複製しておき、パッチ検証後も削除せず、次回のパッチ正常性確認の際に使用するようにしてもよい。

（ソフトウェア関係テーブル）
図３は、ソフトウェア関係テーブルの一例を示す図である。ソフトウェア関係テーブル２０ａは、ソフトウェア、ソフトウェアを束ねた概念である「ソフトウェアグループ」、ソフトウェアグループを束ねた概念である「機能分類」に関する情報を保持している。ソフトウェア関係テーブル２０ａは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」のカラムを有する。

図３に示すように、例えば、「機能分類」“ＯＳ”の場合に、「ソフトウェアグループ」として“ＯＳ＃Ａ”“ＯＳ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“ＯＳ＃Ａ”グループには、“ＯＳ＃Ａ Ｓｅｒｖｅｒ ２０１２”“ＯＳ＃Ａ ８．１”等がある。また、例えば、「機能分類」“ＤＢ”の場合に、「ソフトウェアグループ」として“ＤＢ＃Ａ”“ＤＢ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“ＤＢ＃Ａ”グループには、“ＤＢ＃Ａ １１ｇ”“ＤＢ＃Ａ １０ｇ”等がある。また、例えば、「機能分類」“Ｗｅｂ”の場合に、「ソフトウェアグループ」として“Ｗｅｂ＃Ａ”“Ｗｅｂ＃Ｂ”がある。そして、「ソフトウェアグループ」に属す具体的ソフトウェアとして、“Ｗｅｂ＃Ａ”グループには、“Ｗｅｂ＃Ａ ２．１”“Ｗｅｂ＃Ａ ２．２”等がある。

（テストケーステーブル）
図４は、テストケーステーブルの一例を示す図である。テストケーステーブル２０ｂには、Jenkins等で実行可能なテストケースと、そのテストケースの属性情報を保持している。テストケーステーブル２０ｂに保持されるテストケースは、そのテストケース種別として、個別ソフトウェア毎のテストケースか、個別ソフトウェアを束ねたグループであるソフトウェアグループ毎のテストケースか、ソフトウェアグループを束ねた機能分類毎のテストケースかの情報を保持している。テストケーステーブル２０ｂは、「機能分類」「ソフトウェアグループ」「ソフトウェア名」「テストケース」「テストケース種類」「確認対象」のカラムを有する。

例えば、「テストケース」“テーブルのＣＲＵＤ（Create、Read、Update、Delete）”は、ＳＱＬ（Structured Query Language）でサンプルデータのＣＲＵＤを行えばよいため、「機能分類」“ＤＢ”で共通的に利用できるテストケースである。また、テーブルのＣＲＵＤは、「確認対象」“機能”である。

また、例えば、「テストケース」“日本語データ表示文字チェック”というテストケースは、ＳＱＬでデータを確認するため、「機能分類」“ＤＢ”で共通的に利用できるテストケースである。また、パッチ適用後に表示文字が正常表示されているか否かは、データ正常性確認のため、「確認対象」は“データ”である。

また、例えば、「テストケース」“管理ツールによるアクセス正常”は、「ソフトウェアグループ」“ＤＢ＃Ｂ”のWeb GUIでのアクセスツールである場合、“ＤＢ＃Ｂ”のソフトウェアグループで共通的に利用できるテストケースであり、「確認対象」は“機能”である。

その他の「機能分類」「ソフトウェアグループ」「ソフトウェア名」についても、上記と同様である。

（パッチ正常性確認処理を示すシーケンス図）
図５は、仮想機器システムにおけるパッチ正常性確認処理の一例を示すシーケンス図である。先ず、オペレータ端末１は、パッチ正常性確認装置１０に対して、ユーザテナント及び配布パッチを指定して、パッチ正常性確認を依頼する（ステップＳ１１）。なお、ステップＳ１１における「パッチ正常性確認装置１０に対して、ユーザテナント及び配布パッチを指定して、パッチ正常性確認を依頼」は、ユーザ毎の契約情報に基づいて検証起動装置３により実行されてもよい。そして、パッチ正常性確認装置１０は、クラウドコントローラ２００のＡＰＩ部２０１ａを介して、テンプレート抽出を依頼する（ステップＳ１２）。クラウドコントローラ２００は、抽出したテンプレートを、パッチ正常性確認装置１０へ送信する（ステップＳ１３）。なお、テンプレート抽出は、既存技術を用いればよい。

次に、パッチ正常性確認装置１０は、クラウドコントローラ２００により抽出されたテンプレートの展開を、クラウドコントローラ２００のクラウド構築部２０１ｂに対して依頼する（ステップＳ１４）。クラウドコントローラ２００のクラウド構築部２０１ｂは、パッチ正常性確認装置１０からの依頼に応じて、物理マシン３０１に対して、テンプレートに記載の仮想マシンの作成を依頼する（ステップＳ１５）。次に、物理マシン３０１は、クラウド構築部２０１ｂからの依頼に応じて、仮想マシンを物理マシン３０１上に作成する（ステップＳ１６）。物理マシン３０１は、ステップＳ１６の仮想マシン作成が終了すると、クラウド構築部２０１ｂに対して、作成応答を送信する（ステップＳ１７）。

同様に、クラウド構築部２０１ｂは、パッチ正常性確認装置１０からの依頼に応じて、物理マシン３０２に対して、テンプレートに記載の仮想ルーターの作成を依頼する（ステップＳ１８）。次に、物理マシン３０２は、クラウド構築部２０１ｂからの依頼に応じて、仮想ルーターを物理マシン３０２上に作成する（ステップＳ１９）。物理マシン３０２は、ステップＳ１９の仮想ルーター作成が終了すると、クラウド構築部２０１ｂに対して、作成応答を送信する（ステップＳ２０）。クラウド構築部２０１ｂは、ステップＳ１７及びステップＳ２０の応答を受信したことに応じて、テンプレート展開完了を、パッチ正常性確認装置１０へ送信する（ステップＳ２１）。

次に、パッチ正常性確認装置１０は、クラウドコントローラ２００に対して、ステップＳ１６で作成された仮想マシン（以下、複製仮想マシンと呼ぶ）及びステップＳ１９で作成された仮想ルーター（以下、複製仮想ルーターと呼ぶ）への接続情報を含む環境情報を取得依頼する（ステップＳ２２）。なお、この接続情報は、テンプレートに記載の仮想機器の構成情報と同様の情報である。また、複製仮想マシンは、図２に示すＶＭ４０２ｂ−１〜４０２ｂ−２が該当する。また、複製仮想ルーターは、図２に示すＬＲ４０２ａが該当する。そして、パッチ正常性確認装置１０は、クラウドコントローラ２００から、複製仮想マシン及び複製仮想ルーターへの接続情報の応答を受け付ける（ステップＳ２３）。

次に、パッチ正常性確認装置１０は、契約情報として登録されているパスワード等の情報を用いて、物理マシン３０１上の複製仮想マシンへアクセスし、複製仮想マシンに対して、ソフトウェア情報を含む環境情報の取得を依頼する（ステップＳ２４）。なお、契約情報は、上述するように、サービス事業者によりユーザ毎に管理されている情報であり、オペレータ端末１や検証起動装置３が、契約情報ＤＢ（図示せず）から取得した契約情報をステップＳ１１で渡せばよい。そして、パッチ正常性確認装置１０は、複製仮想マシンから、当該複製仮想マシンのソフトウェア情報を含む環境情報の応答を受け付ける（ステップＳ２５）。

次に、パッチ正常性確認装置１０は、テストケースＤＢ２０に、ステップＳ２５で取得した環境情報が含む、仮想マシンに用いられている「ソフトウェア名」を引数に、「ソフトウェアグループ」、「機能分類」を検索し、該当の「機能分類」及び「ソフトウェアグループ」に対応する「テストケース」を抽出する（ステップＳ２６及びＳ２７）。ステップＳ２７で抽出された「テストケース」は、Jenkins等のテスト自動ツールを用いて、パッチ正常性確認装置１０により実行される。なお、パッチ正常性確認装置１０は、「テストケース」の実行前に、パッチ適用前データがパッチ適用後も正常であることを確認する、データ正常性確認試験のため確認用データを設定する（ステップＳ２８）。

次に、パッチ正常性確認装置１０は、仮想マシンにパッチを配布する（ステップＳ２９）。次に、パッチ正常性確認装置１０は、パッチ配布し、対象の仮想マシンにてパッチ適用後、選択されたテストケースを実施する（ステップＳ３０）。そして、パッチ正常性確認装置１０は、テスト結果を収集する。パッチ正常性確認装置１０は、指定ユーザのテストケース結果を、オペレータ端末１へ通知する（ステップＳ３１）。オペレータは、テストケース結果をユーザに通知してもよい。また、テストケースが正常である場合は、パッチ正常性確認機器は通知をスキップして、ユーザテナントの仮想マシンにパッチを自動配布してもよい。

（実施形態による効果）
パッチ正常性確認装置１０は、物理マシン上で動作する仮想機器を含むユーザ環境において動作するソフトウェアのソフトウェア情報を含むユーザ環境に関する環境情報をユーザ環境から抽出する。パッチ正常性確認装置１０は、抽出された環境情報をもとに、環境情報に対応するユーザ環境で動作するソフトウェアを、ソフトウェア毎、グループ毎又は機能分類毎に分類し、ソフトウェア毎、グループ毎又は機能分類毎の試験パターンをデータベースから取得する。パッチ正常性確認装置１０は、抽出された環境情報に対応するユーザ環境に対して、ユーザ環境で動作するソフトウェアの修正プログラムを適用後、取得されたソフトウェア毎、グループ毎又は機能分類毎の試験パターンを実行する。

よって、実施形態によれば、ユーザの仮想マシン等に対するパッチ配布、適用後のパッチ正常性確認試験を自動で行うことができるため、仮想マシンに対するパッチ適用後の正常動作の検証工程を削減でき、運用コストが低減できる。また、実施形態は、ソフトウェアを、少なくとも「ソフトウェアグループ」「機能分類」と２段階に抽象化し、抽象化したグループ共通で実行できるテストケースを選択可能にするので、予め準備するテストケースの数を抑制できる。また、実施形態は、ユーザテナントを複製してパッチ適用し、正常性確認を行った後、ユーザテナントにパッチ配布を行うので、ユーザが利用中の実サービスに影響を与えることなく、パッチ適用後正常動作の検証が可能である。また、複製テナントは、パッチ適用後の正常動作の検証の期間だけ維持すればよく、検証終了後は複製テナントを削除すればよいため、物理リソースの圧迫を抑制できる。

（実施形態の変形例）
実施形態は、ユーザテナントの複製を行い、複製したユーザテナントに対してパッチ正常性確認を行うとしたが、ユーザテナントの複製を作成せず、ユーザテナントに対して直接パッチを配布してパッチ正常性確認を行うとしてもよい。

また、実施形態は、複製後のユーザテナントのボリューム内を調査し、ユーザテナントの仮想機器にどのようなソフトウェアが実装されているかを分析した結果である環境情報をもとに、仮想機器に実装されるソフトウェアが、いずれの「ソフトウェア名」「ソフトウェアグループ」「機能分類」に該当するかを分類するとする。しかし、これに限らず、ユーザテナントを複製する際に抽出するテンプレートを分析して、ユーザテナント内の仮想機器に実装されるソフトウェアが、いずれの「ソフトウェア名」「ソフトウェアグループ」「機能分類」に該当するかを分類するとしてもよい。この場合、テンプレートは、ユーザテナント内の仮想機器に実装されるソフトウェアの情報も含むとする。

すなわち、図１を参照して説明すると、パッチ正常性確認装置１０は、抽出されたテンプレートから、当該テンプレートに規定されるソフトウェアの情報を抽出するとしてもよい。そして、パッチ正常性確認装置１０は、抽出した当該テンプレートに規定されるソフトウェアの情報を、ソフトウェア関係テーブル２０ａを参照して分析し、当該テンプレートに規定されるソフトウェアを「ソフトウェア名」「ソフトウェアグループ」「機能分類」の３つの階層で分類するとしてもよい。

言い換えると、パッチ正常性確認装置１０は、抽出されたテンプレートから、ユーザテナントの仮想マシン上で動作するＯＳ、ミドルウェア、アプリケーションソフトウェア等のソフトウェアの情報を抽出してもよい。そして、パッチ正常性確認装置１０は、抽出されたテンプレートから、どの「機能分類」どの「ソフトウェアグループ」に属すかの情報を把握する。そして、パッチ正常性確認装置１０は、把握した情報を用いて、実施するテストケースを選択する。具体的には、「機能分類」から機能分類毎のテストケースを選択し、更に「ソフトウェアグループ」からソフトウェアグループ毎のテストケースを選択し、更に「ソフトウェア名」からソフトウェア毎のテストケースを選択してもよい。

また、実施形態は、サービス事業者は、ユーザ毎の契約情報及びユーザ毎の仮想マシンで用いるＯＳ等の構成情報を用いて、パッチ適用対象ユーザを事前抽出し、当該ユーザのユーザテナントの複製を作成し、ユーザテナントの複製がパッチ正常性確認により正常と確認できたユーザテナントに対して実際のパッチ適用を指示するとする。しかし、これに限らず、パッチが公開されると、パッチ適用対象となるユーザを契約情報等から抽出し、対象となるユーザテナントの複製を作成し、ユーザテナントの複製に対してパッチ正常性確認を実行し、パッチ正常性確認が正常であった場合にユーザテナントの実環境に対してパッチを実際に適用し、ユーザテナントの複製を削除するまでの一連の処理を自動化してもよい。すなわち、通常のパッチ適用処理を開始するだけで、ユーザテナントの複製でのテストを実行し、正常であれば実環境のユーザテナントに対しパッチを適用するとしてもよい。なお、パッチ正常性確認が正常でない場合は、エラー通知を出力し、パッチ適用処理を中断するとしてもよい。このようにすることにより、通常のパッチ適用処理の中で、パッチ正常性確認を意識せずとも、ユーザテナントにおけるサービスを正常に継続可能なパッチ適用処理を容易に実現できる。

（パッチ正常性確認装置の装置構成について）
図１に示すパッチ正常性確認装置１０の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、パッチ正常性確認装置１０の機能の分散及び統合の具体的形態は図示のものに限られず、全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合して構成することができる。

また、パッチ正常性確認装置１０において行われる各処理は、全部又は任意の一部が、ＣＰＵ（Central Processing Unit）及びＣＰＵにより解析実行されるプログラムにて実現されてもよい。また、パッチ正常性確認装置１０において行われる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。

また、実施形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部又は一部を手動的に行うこともできる。若しくは、実施形態において説明した各処理のうち、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。

（プログラムについて）
図６は、プログラムが実行されることにより、パッチ正常性確認装置が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。コンピュータ１０００において、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１０６１に接続される。

ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、パッチ正常性確認装置１０の各処理の規定するプログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、例えばハードディスクドライブ１０３１に記憶される。例えば、パッチ正常性確認装置１０における機能構成と同様の情報処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、上述した実施形態での処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

以上の実施形態並びにその変形例は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

Ｓ 仮想機器システム
１０ パッチ正常性確認装置
１１ テンプレート抽出部
１２ テナント複製部
１３ 環境情報抽出部
１４ テストケース取得部
１５ テスト実行部
２０ テストケースＤＢ
２０ａ ソフトウェア関係テーブル
２０ｂ テストケーステーブル
１０００ コンピュータ
１０１０ メモリ
１０２０ ＣＰＵ

Claims (6)

1. 物理マシン上で動作する仮想機器を含むユーザ環境において動作するソフトウェアのソフトウェア情報を含む該ユーザ環境に関する環境情報を該ユーザ環境から抽出する環境情報抽出部と、
   前記環境情報抽出部により抽出された環境情報をもとに、該環境情報に対応するユーザ環境で動作するソフトウェアを、ソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に分類し、予め登録したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンの中から、前記分類したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に対応し、共通して実行できる試験パターンをデータベースから取得する取得部と、
   前記環境情報抽出部により抽出された環境情報に対応するユーザ環境に対して、該ユーザ環境で動作するソフトウェアの修正プログラムを適用後、前記取得部により取得されたソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンを実行し、実行した試験パターンの実行結果を収集して分析し、各試験パターンの実行結果の正常又は異常の判定結果を出力する実行部と
   を備えることを特徴とする仮想機器試験装置。
2. 前記実行部は、前記環境情報抽出部により抽出された環境情報に対応するユーザ環境に対して、該ユーザ環境で用いられるデータを設定した上で前記修正プログラムを適用した後、前記試験パターンを実行し、該試験パターンの実行後における該データの正常性をチェックする
   ことを特徴とする請求項１に記載の仮想機器試験装置。
3. 前記ユーザ環境に関する構成情報を該ユーザ環境から抽出する構成情報抽出部と、
   前記構成情報抽出部により取得された構成情報をもとに、物理マシン上に前記ユーザ環境の複製を作成する複製部とをさらに備え、
   前記環境情報抽出部は、前記環境情報を該ユーザ環境の複製から抽出し、
   前記取得部は、前記環境情報抽出部により抽出された前記環境情報をもとに、該環境情報に対応する該ユーザ環境の複製で動作するソフトウェアを、ソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に分類し、予め登録したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンの中から、前記分類したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に対応し、共通して実行できる試験パターンをデータベースから取得し、
   前記実行部は、前記複製部により作成された前記ユーザ環境の複製に対して、該ユーザ環境の複製で動作するソフトウェアの修正プログラムを適用後、前記取得部により取得されたソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンを実行し、実行した試験パターンの実行結果を収集して分析し、各試験パターンの実行結果の正常又は異常の判定結果を出力する
   ことを特徴とする請求項１に記載の仮想機器試験装置。
4. 前記実行部により前記ユーザ環境の複製に対して前記試験パターンが実行された結果が正常であった場合に、前記ユーザ環境で動作するソフトウェアの修正プログラムを前記ユーザ環境に対して適用する適用部をさらに備える
   ことを特徴とする請求項３に記載の仮想機器試験装置。
5. 仮想機器試験装置が行う仮想機器試験方法であって、
   前記仮想機器試験装置の環境情報抽出部が、物理マシン上で動作する仮想機器を含むユーザ環境において動作するソフトウェアのソフトウェア情報を含む該ユーザ環境に関する環境情報を該ユーザ環境から抽出し、
   前記仮想機器試験装置の取得部が、前記環境情報抽出部により抽出された環境情報をもとに、該環境情報に対応するユーザ環境で動作するソフトウェアを、ソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に分類し、予め登録したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンの中から、前記分類したソフトウェア毎、ソフトウェアグループ毎又は機能分類毎に対応し、共通して実行できる試験パターンをデータベースから取得し、
   前記仮想機器試験装置の実行部が、前記環境情報抽出部により抽出された環境情報に対応するユーザ環境に対して、該ユーザ環境で動作するソフトウェアの修正プログラムを適用後、前記取得部により取得されたソフトウェア毎、ソフトウェアグループ毎又は機能分類毎の試験パターンを実行し、実行した試験パターンの実行結果を収集して分析し、各試験パターンの実行結果の正常又は異常の判定結果を出力する
   ことを含むことを特徴とする仮想機器試験方法。
6. 請求項１〜４の何れか１つに記載の仮想機器試験装置としてコンピュータを機能させる仮想機器試験プログラム。

Images