JP6700848B2 - 管理システム、制御方法 - Google Patents

Description

本発明は、ソフトウェアや設定ファイルなどに係るシステムイメージファイルの管理のための制御方法に関する。

近年、インターネット上にあるサーバで動作する各種アプリケーションを利用することができるサービスとして、クラウドサービスがある。ＩａａＳやＰａａＳなどのクラウドサービスでは、クラウドサービスベンダーが、ネットワークを介して、仮想マシンやストレージなどのリソースをクラウドサービス利用者に提供する。仮想マシンとは、仮想化技術によって、サーバコンピュータを物理的な構成にとらわれずに論理的な単位で分割し、分割したそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピュータである。クラウドサービス利用者は、クラウドサービスベンダーによって提供される仮想マシンやストレージなどのリソースを用いて、顧客に対して独自のサービスを提供するためのシステム（以降、処理システムと呼ぶ）を構築することができる。処理システムは、Ｗｅｂアプリケーションやデータベース、ロードバランサ、ＤＮＳサーバなどで構成され、それらの構成要素間は互いにネットワークで接続される。

このような仮想化技術を利用したクラウドサービスにおいては、アプリケーションやミドルウェアといったソフトウェア、設定ファイルなどをインストールした仮想マシンをＯＳごとシステムイメージファイルとしてファイル化することが可能である。通常、作成したシステムイメージファイルはクラウドサービス上で保管される。作成したシステムイメージファイルから仮想マシンを起動することで、ソフトウェアのインストールや各種設定等が既に行われた状態の仮想マシンを容易に任意の台数起動することが可能である。

このシステムイメージファイルを利用して、同じアプリケーションなどが動作する仮想マシンを起動することができる。ここで、起動された仮想マシンを含む処理システムを構築し、ネットワーク上のＰＣなどを介して、その処理システムにより提供されるサービスを利用可能な状態とすることを、デプロイと呼ぶ。

処理システムは、例えば、開発、評価、本番などの目的に応じたデプロイ環境にデプロイされる。なお、以降の説明で、デプロイ環境のことを単に「環境」と呼ぶこともある。開発用、評価用、本番用のデプロイ環境をそれぞれ、開発環境、評価環境、本番環境と呼ぶ。ここで、本番環境とは、顧客へサービスを提供する処理システムをデプロイ可能なデプロイ環境である。なお、顧客は、ＰＣなどを介して、本番環境内にデプロイされた処理システムへアクセスして、サービス提供を受ける。開発用、評価用のデプロイ環境は、本番環境に処理システムをデプロイする前に利用される環境である。例えば、開発環境内にデプロイされた複数の処理システムのうちのその一部に対応するシステムイメージファイルを用いて評価環境内にデプロイされることで、システムが移行される。評価環境では、移行された処理システムを評価し、その評価環境にデプロイされた複数の処理システムのうちの一部に対応するシステムイメージファイルを用いて、本番環境へのシステム移行が行われることとなる。このように一度デプロイに使用したシステムイメージファイルを再び使用してデプロイをする場合がある。

近年、ソフトウェアの品質を継続的に確認しながら開発を進めることで高い品質を得る、継続的インテグレーション（ＣＩ：Ｃｏｎｔｉｎｕｏｕｓ Ｉｎｔｅｇｒａｔｉｏｎ）という手法がソフトウェア開発において利用されている。ＣＩでは１日に数回から数十回という高い頻度でソースコードのビルドやテストを行い、品質が維持されているかを確認する。ビルドとは、ソースコードをコンピュータによって解析し、アプリケーションを生成することを指す。さらに、ＣＩに基づく処理システムの開発においては、ソースコードのビルド・テストを行った後に、上述したシステムイメージファイルを作成する場合がある。近年では、ＣＩ支援ツールといったソフトウェアの機能を提供するクラウドサービスも登場している。

このようなＣＩを採用した処理システムの開発においては、システムイメージファイルに含まれる設定ファイルのパラメータなどを一部変更するたびに新たなシステムイメージファイルを作成することになる。例えば、数種類の仮想マシンで構成される処理システムを一日に１０回程度デプロイすると、一日に数十個のシステムイメージファイルが作成されることとなる。また、１つのシステムイメージファイルのデータサイズは数ＧＢに及ぶこともある。クラウド上のストレージなどのリソース節約のために、不要になったシステムイメージファイルを適宜削除する必要がある。

ここで、仮想マシンに関するイメージファイルを管理する技術として特許文献１がある。特許文献１では、仮想マシンのＯＳおよびアプリケーションプログラムがインストールされた記憶領域中のファイルなどからなるマスタイメージを管理者が指定したグループで管理し、そのグループに基づくマスタイメージの削除処理について記載されている。管理者の削除指示したマスタイメージが、グループに属していない場合に限りそのマスタイメージを削除するといった開示がある。

特開２００５−３３２２２３号公報

上述したシステムイメージファイルの削除に関して、例えば、システムイメージファイルの作成日が古いものから順番に削除することが考えられる。この場合、他のデプロイで再び使用しないシステムイメージファイルは不要であるにも関わらず、作成日が新しいため、しばらくの間削除されずに保持されてしまう。

一方、他のデプロイで再び使用するシステムイメージファイルは必要であるに関わらず、作成日が古いために削除されるおそれがある。削除された場合、そのシステムイメージファイルを他のデプロイ環境などへのデプロイに用いることができなくなる。そこで、既に構築されていて稼働中の処理システム内の仮想マシンからシステムイメージファイルを生成することも考えられる。しかしながら、処理システムが削除されている場合にはこの方法をとることはできない。

上述した特許文献１では、ＣＩを採用した処理システムの構築を前提としていない。さらに、システムイメージファイルを用いて処理システムがデプロイされたデプロイ環境などを考慮して、該システムイメージファイルの削除を行うといった点については想定していない。

本発明は、システムイメージファイルを利用して処理システムを構築した環境などの条件を考慮して、該システムイメージファイルの削除判定を行うための仕組みを提供することを目的とする。

上記課題を解決するために、本発明の管理システムは、少なくとも仮想マシンで動作するソフトウェアの情報を含むシステムイメージファイルを保存する記憶装置から、前記システムイメージファイルを削除するための管理システムであって、システムイメージファイルを用いて起動された仮想マシンを含む処理システムが構築された環境に対応する属性の値を該システムイメージファイルへ付与するよう指示する付与指示手段と、前記付与指示手段の指示によりシステムイメージファイルに付与される属性の値に応じた条件として、該システムイメージファイルが作成されてから経過した時間が、該システムイメージファイルに付与される属性の値に応じた所定時間を超えるか否かに基づき、該システムイメージファイルを削除すべきか否かを判定する第１の判定手段と、前記第１の判定手段により削除すべきであると判定されたシステムイメージファイルを前記記憶装置から削除するよう指示する削除指示手段と、を有し、システムイメージファイルを用いて起動された仮想マシンを含む処理システムを構築できる環境として、少なくとも第１の環境および第２の環境があり、前記第１の環境に対応する属性の値に応じた第１の所定時間と、前記第２の環境に対応する属性の値に応じた第２の所定時間とは、異なることを特徴とする。

本発明によれば、システムイメージファイルを利用して処理システムを構築した環境などの条件を考慮して、該システムイメージファイルの削除判定を行うことができる。

本発明の実施形態に係るネットワークシステムの構成例を示す図である。 情報処理装置のハードウェア構成例を示す図である。 フロントサーバ１５２およびバッチサーバ１５３の構成例を示す図である。 システムイメージファイルを含むデータの構成例を示す図である。 システムマネージャ１０１の構成例を示す図である。 タグ更新順序テーブルの例を示す図である。 システムイメージファイル作成指示処理の流れの例を示すフローチャートである。 タグ更新指示処理の流れの例を示すフローチャートである。 タグ４１２に応じたシステムイメージファイルの削除条件テーブルの例を示す図である。 システムイメージファイル削除処理の流れの例を示すフローチャートである。 タグ４１２に応じたデプロイ可能なデプロイ環境テーブルの例を示す図である。 実施例２におけるタグ更新指示処理の流れの例を示すフローチャートである。 実施例３におけるデプロイ環境の構成例を示す図である。 実施例３におけるシステムマネージャ１０１の構成例を示す図である。 システムイメージファイルの管理テーブルの例を示すフローチャートである。 実施例３におけるタグ更新指示処理およびシステムイメージファイル削除指示処理の流れの例を示すフローチャートである。 実施例４におけるタグ更新指示処理の流れの例を示すフローチャートである。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施例１）
図１は、本発明の実施形態に係るネットワークシステムの構成例を示す図である。図１（ａ）で示すように、システム１００は、管理者コンピュータ１０５や評価者コンピュータ１０６と、ネットワーク１０７を介して接続している。システム１００は、クラウドサービスによって提供されるリソースとしての仮想マシンやストレージを用いて構築される。仮想マシンとは、仮想化技術によって、データセンター上のサーバコンピュータを物理的な構成にとらわれずに論理的な単位で分割し、分割したそれぞれで独立したオペレーティングシステムをもって動作する論理的なコンピュータである。１台のサーバコンピュータ上で動作する複数の仮想マシンを用いて、システム１００が構築される。

管理者コンピュータ１０５は、システム１００の管理者や開発者が操作するコンピュータなどが想定される。管理者コンピュータ１０５は、ブラウザ機能や、システムマネージャ１０１との通信機能などを備える。評価者コンピュータ１０６は、システム１００の後述する評価環境１２０にデプロイされた処理システムのテストなどを行う評価担当者が操作するコンピュータなどが想定される。ネットワーク１０７は、ＬＡＮやＷＡＮ、インターネット等が想定される。

システム１００は、システムマネージャ１０１、サービスマネージャ１０２、ＤＢ１０４、開発環境１１０、評価環境１２０および本番環境１３０を含む。システムマネージャ１０１及びサービスマネージャ１０２は、仮想マシンとして実現することも、物理的なサーバコンピュータであってもよい。

システムマネージャ１０１は、サービスマネージャ１０２に対して、システムイメージファイルの作成や削除などを指示する管理システムとして機能する。システムマネージャの処理について、図５を用いて後述する。サービスマネージャ１０２は、システムマネージャ１０１からの指示を受けて、システムイメージファイルの作成や削除などの処理を実行する。サービスマネージャ１０２の機能は、クラウドサービスベンダーによって提供される機能であってもよい。ＤＢ１０４は、本システムを実現するためのプログラムや、ユーザにサービスを提供するための各種データ、およびシステムイメージファイルなどが格納されるデータベースなどの記憶装置である。

ここで、システムイメージファイルを利用して起動された仮想マシンを含む処理システムを構築し、ユーザや開発者がサービスを利用可能な状態とすることを、デプロイと呼ぶ。開発、評価、本番などの目的に応じたデプロイ環境をそれぞれ、開発環境、評価環境、本番環境と呼ぶ。各環境には、処理システムを複数構築することが可能である。ここで、本番環境とは、システムの外部にあるクライアントコンピュータ（不図示）からのリクエストを受け付けてサービスを提供することが可能な環境を指す。なお、図示しないが、システム１００には、開発、評価、本番以外の目的のデプロイ環境（先行リリースのための環境、デモンストレーションのための環境、本番リハーサルのための環境など）が存在してもよい。

図１（ａ）では、開発環境１１０内には１１０Ａと１１０Ｂの処理システムがデプロイされている状態を示している。このようにそれぞれのデプロイ環境には、複数の処理システムをデプロイして、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントを用いてシステムのバージョンアップを行うことができる。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントについては実施例３で説明する。

図１（ｂ）は処理システムの構成例を示す図である。開発環境１１０内にデプロイされた処理システム１１０Ａは、１以上の仮想マシンで実現される、ロードバランサ１５１、フロントサーバ１５２およびバッチサーバ１５３を含む。なお、１１０Ｂ、１２０Ａ、１２０Ｂ、１３０Ａおよび１３０Ｂなどの処理システムについても、基本的には１１０Ａの処理システムと同様の構成を備えるものとする。

ロードバランサ１５１は、受信したリクエストをフロントサーバ１５２に分散させる負荷分散装置である。フロントサーバ１５２は、ロードバランサ１５１から受信した要求を受け付けて処理する。バッチサーバ１５３は所定の時刻に処理を実行する。フロントサーバ１５２、バッチサーバ１５３はそれぞれ複数存在してよい。

なお、フロントサーバ１５２やバッチサーバ１５３において実行される処理の内容は、システム１００が提供する機能に応じて変わり得るものであり、本発明においては限定しない。また、システム１００が提供する機能に応じて、フロントサーバ１５２やバッチサーバ１５３以外の異なる種類のサーバがあってもよい。異なる種類のサーバとして、例えば、フロントサーバ１５２からの要求を受け付けて処理するバックエンドサーバや、外部からシステム１００にアクセスするコンピュータにＵＩ画面を提供するＷｅｂＵＩサーバなどが存在し得る。

図２は、情報処理装置のハードウェア構成例を示す図である。本実施例における情報処理装置としては、システム１００が構築されるデータセンター上に存在するサーバコンピュータ、管理者コンピュータ１０５、評価者コンピュータ１０６がある。

情報処理装置は、ＲＯＭ２５３に格納されているプログラムを実行するＣＰＵ２５１を備え、内部バス２５６を介して各デバイスを総括的に制御する。内部バス２５６には、ＲＡＭ２５２、ＲＯＭ２５３、記憶装置２５４、ネットワークＩ／Ｆ２５５、入出力Ｉ／Ｆ２５７が接続されている。また入出力Ｉ／Ｆ２５７は、例えばＰＳ／２やＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ Ｉ／Ｆ）、アナログやデジタルのディスプレイＩ／Ｆを備える。入出力Ｉ／Ｆ２５７により、情報処理装置に対して、不図示のキーボードやマウス、ＣＲＴや液晶ディスプレイなどを接続することができる。情報処理装置はネットワークＩ／Ｆ２５５によりＬＡＮ、イントラネット環境、インターネットを介した通信を行う。それにより、情報処理装置は、ネットワークデバイスや、他の情報処理装置と通信を行うことができる。ＣＰＵ２５１は、ＲＡＭ２５２やＲＯＭ２５３と共にプログラムの実行処理を行う。さらに、ＣＰＵ２５１は、仮想化技術を実現するためのプログラムを実行することも可能である。また、ＣＰＵ２５１は、記憶装置２５４等の記録媒体にデータを記録する処理を行う。記憶装置２５４は外部記憶装置として機能し、様々な情報を記憶するほか、ＲＡＭ２５２に代わって、各種システム情報及び処理情報を保存することも可能である。

図３は、フロントサーバ１５２およびバッチサーバ１５３の構成例を示す図である。フロントサーバ１５２およびバッチサーバ１５３は、仮想マシンで実現される。

図３（ａ）で示すフロントサーバ１５２は、フロントアプリケーション３０１、ミドルウェア３０２、設定ファイル３０３、ＯＳ３０４を有する。

フロントアプリケーション３０１は、システム１００が提供する機能の一部または全部を実現するアプリケーションである。ミドルウェア３０２は、例えば、フロントアプリケーションを起動するための機能の提供やロードバランサ１５１からの要求をフロントアプリケーション３０１に渡す機能を提供するＷｅｂサーバなどのソフトウェアである。設定ファイル３０３は、フロントアプリケーション３０１やミドルウェア３０２が機能を実現するために必要となる設定情報が記載されたファイルである。ＯＳ３０４は、フロントアプリケーション３０１やミドルウェア３０２に対して、仮想マシンのハードウェアリソースを利用するためのインタフェースなどを提供するコンピュータプログラムである。

図３（ｂ）は、バッチサーバ１５３の構成例を示す図である。バッチサーバ１５３はバッチアプリケーション３５１、ミドルウェア３５２、設定ファイル３５３、ＯＳ３５４を有する。

バッチアプリケーション３５１は、システム１００が提供する機能の一部または全部を実現するアプリケーションである。ミドルウェア３５２は、例えば、バッチアプリケーション３５１を起動するための機能を提供するソフトウェアである。設定ファイル３５３は、バッチアプリケーション３５１やミドルウェア３５２が機能を実現するために必要となる設定情報が記載されたファイルである。ＯＳ３５４は、バッチアプリケーション３５１やミドルウェア３５２に対して、仮想マシンのハードウェアリソースを利用するためのインタフェースを提供するコンピュータプログラムである。

上述したように、フロントサーバ１５２とバッチサーバ１５３などサーバの種類に応じて、ＯＳ、設定ファイル、ミドルウェア、アプリケーションのうち少なくともいずれかが異なる。

図４は、システムイメージファイルを含むデータの構成例を示す図である。システムイメージファイルを含むデータは、ＤＢ１０４に保存される。

システムイメージファイル４１３は、図３（ａ）および図３（ｂ）で示したサーバの構成要素を、一つあるいは複数のバイナリ形式のファイルとしたものである。システムイメージファイル４１３は、特定のクラウドサービスにおいては、ゴールデンイメージ（Ｇｏｌｅｄｅｎ Ｉｍａｇｅ）とも呼ばれる。本実施例においては、処理システムのデプロイに際して、仮想マシンを起動する際にこのシステムイメージファイル４１３が使用される。仮想マシンからシステムイメージファイルを作成することを仮想マシンのイメージ化と呼ぶこととする。

また、クラウドサービスを用いて構築されるシステムでは、システム管理者の設定に従い、受け付けるリクエストの量やそれらの処理のための負荷に応じて、自動的に仮想マシンの台数を増減させるなどして、リソース量を調整することができる。仮想マシンの台数を増やすために、新しく仮想マシンを起動することとなり、この際にもシステムイメージファイルを用いて仮想マシンを起動することが可能である。

なお、システムイメージファイルには、図３（ａ）や図３（ｂ）で示した構成要素以外のものが含まれていてもよいし、また、ＯＳ３０４およびＯＳ３５４以外のものは必ずしも含まれていなくともよい。

識別子４１１は、本システムイメージファイルを用いて起動されるサーバの種類とファイルの作成日時を少なくとも表す識別子である。例えば、識別子の形式は４１１のように表されるが、表現の仕方はこれに限定されない。

タグ４１２は、本システムイメージファイルを用いて起動された仮想マシンが含まれる処理システムがデプロイされた環境との対応付けを示すシステムイメージファイルの属性の１つである。タグには、例えば、ＴＲ、ＴＳ、ＰＲＶ、ＤＥＭ、ＲＨ、ＰＲＤなどといった値が設定される。それぞれ、開発目的の環境（ＴＲ）、品質保証のための評価目的の環境（ＴＳ）、先行リリースのための環境（ＰＲＶ）、デモンストレーションのための環境（ＤＥＭ）、本番リハーサルのための環境（ＲＨ）、本番目的の環境（ＰＲＤ）などがある。タグ４１２の値の間には、順序関係があり、この順序関係によりタグ４１２の値の更新が制限される場合がある。なお、システムイメージファイルとデプロイ環境との対応付けを管理する方法はタグの付与に限らず、例えば、ＤＢ１０４においてシステムイメージファイルとデプロイ環境との対応付けをテーブルなどで管理するようにしてもよい。また、用途が類似するいくつかのデプロイ環境については、タグの値として、同じ値を設定するといったことも可能である。

なお、ＤＢ１０４が複数ある場合には、識別子４１１、タグ４１２、ファイルデータ４１３に共通のＩＤを振った上で、それらを複数のＤＢ１０４に分けて保存してもよい。

図５は、システムマネージャ１０１の構成例を示す図である。図５に示す機能は、データセンター上のサーバコンピュータのＣＰＵ２５１が、記憶装置２５４に記録されたプログラムを読み出して実行することにより実現される。システムマネージャ１０１は、アプリケーション作成部５０１、ファイル作成指示部５０２、デプロイ実行指示部５０３、タグ付与指示部５０４、削除判定部５０５、ファイル削除指示部５０６を含む。

アプリケーション作成部５０１は、管理者コンピュータ１０５からの入力に従い、ソースコードをビルドし、フロントアプリケーション３０１およびバッチアプリケーション３５１を作成する。

ファイル作成指示部５０２は、仮想マシン上に、ソフトウェアをインストールし、設定ファイルを保存する。ソフトウェアとしては、図３で示したフロントアプリケーション３０１、ミドルウェア３０２、ＯＳ３０４、バッチアプリケーション３５１、ミドルウェア３５２、ＯＳ３５４などが含まれる。その後、ファイル作成指示部５０２は、仮想マシンをイメージ化してシステムイメージファイルを作成するための指示を、システム１００内のサービスマネージャ１０２に対して行う。その後、サービスマネージャ１０２は、ファイル作成指示部５０２からの指示に基づき、システムイメージファイルを作成する。作成されたシステムイメージファイルは、ＤＢ１０４に保存される。

デプロイ実行指示部５０３は、ファイル作成指示部５０２で作成したシステムイメージファイル４１３を用いて仮想マシンを起動し、デプロイ環境に処理システムを構築し、サービスを利用可能な状態にする。

タグ付与指示部５０４は、システムイメージファイル４１３を用いて処理システムのデプロイが実行された後、システムイメージファイル４１３にタグ４１２の値の付与、またはその値の更新をサービスマネージャ１０２に対して指示する。付与または更新されるタグの値は、該処理システムがデプロイされたデプロイ環境を示すタグの値である。その後、サービスマネージャ１０２は、タグ付与指示部５０４からの指示に基づき、システムイメージファイルにタグの値の付与または更新を行う。

削除判定部５０５は、所定の条件に従い、システムイメージファイルのそれぞれについて、削除すべきか否かを判定する。具体的には、削除判定部５０５は、システムイメージファイル４１３に付与されているタグ４１２の値に応じた条件に基づき、そのシステムイメージファイルを削除すべきか否かを判定する。タグ４１２の値に応じた条件については、図９を用いて後述する。

ファイル削除指示部５０６は、タグの値に応じた削除条件を満たす場合に、該当のシステムイメージファイル４１３をＤＢ１０４から削除するようサービスマネージャに対して指示する。その後、サービスマネージャ１０２は、ファイル削除指示部５０６からの指示に基づき、ＤＢ１０４に保存されているシステムイメージファイル４１３を削除する。

なお、アプリケーション作成部５０１は、システムマネージャ１０１内ではなく、管理者コンピュータ１０５内に存在してもよい。

図６は、タグ更新順序テーブルの例を示す図である。当該テーブルは、ＤＢ１０４によって保持される。本テーブルには、システムイメージファイル４１３の現在のタグ４１２の値ごとに、更新可能なタグ４１２の値が記載されている。

システムマネージャ１０１のタグ付与指示部５０４は、レコード６１１から６１６で示されるタグ４１２の値を参照する。例えば、システムイメージファイル４１３のタグ４１２の値がＴＲである場合、更新可能なタグ４１２はＴＳのみである。タグ４１２の値がＴＳである場合は、タグ付与指示部５０４は、該当のタグ４１２の値をＰＲＶ、ＤＥＭ、ＲＨに更新することが可能である。また、タグ４１２の値がＰＲＤである場合は、どの値にもタグ４１２を更新することはできない。タグ４１２の値がＰＲＤであるシステムイメージファイル４１３を用いて、処理システムをいずれのデプロイ環境にデプロイしたとしても、当該システムイメージファイル４１３のタグ４１２の値はＰＲＤが維持される。

図７は、システムイメージファイル作成指示処理の流れの例を示すフローチャートである。システムマネージャ１０１は、管理者の要求に応じて、または所定の時刻に、本フローチャートのシステムイメージファイル作成処理を実行する。

Ｓ７０２で、アプリケーション作成部５０１は、ソースコードをビルドしてアプリケーションを作成する。Ｓ７０３で、アプリケーション作成部５０１は、アプリケーションのインストール先となる仮想マシンを起動する。Ｓ７０４で、ファイル作成指示部５０２は、Ｓ７０２で作成したアプリケーションをＳ７０３で起動した仮想マシンにインストールする。この時、ファイル作成指示部５０２は、ミドルウェアや設定ファイルもインストールする。Ｓ７０５で、ファイル作成指示部５０２は、Ｓ７０４でアプリケーションなどをインストールした仮想マシンをイメージ化してシステムイメージファイル４１３を作成するための指示を、サービスマネージャ１０２に対して行う。その後、サービスマネージャ１０２は、ファイル作成指示部５０２からの指示に基づき、システムイメージファイルを作成し、作成したシステムイメージファイルをＤＢ１０４に保存する。

本フローチャートのシステムイメージファイル作成指示処理は、開発環境に対してデプロイされる処理システムを構成するサーバの種類ごとに実施される。例えば、２種類のサーバで構成される処理システムを一日に１０回デプロイする場合、一日に最大で２０個のシステムイメージファイルが作成されることとなる。システムイメージファイル１つあたりデータサイズは数ＧＢに及ぶこともあり、クラウド上のストレージ容量が多く必要となる。

図８は、タグ更新指示処理の流れの例を示すフローチャートである。システムマネージャ１０１は、管理者からの要求に応じて、または所定の時刻に本フローチャートのタグ更新指示処理を実行する。

Ｓ８０２で、デプロイ実行指示部５０３は、管理者の指示する又は予め定められたデプロイ環境への処理システムのデプロイの実行をサービスマネージャ１０２に対して指示する。その後、サービスマネージャ１０２は、デプロイ実行指示部５０３からの指示に基づき、デプロイを実行する。ここでのデプロイには、管理者の要求に応じたシステムイメージファイル４１３が使用される。なお、システムイメージファイル作成指示処理（図７）から続けて、タグ更新指示処理（図８）が実行される場合は、ここでのデプロイには、Ｓ７０５で作成したシステムイメージファイル４１３が使用される。

デプロイが実行された後Ｓ８０３では、タグ付与指示部５０４は、当該システムイメージファイル４１３のタグ４１２の値とタグ更新順序テーブルを参照し、タグ４１２の値を更新可能であるかどうかを判定する。タグ付与指示部５０４は、更新可能であればＳ８０４を実行し、更新不可能であればＳ８０５を実行する。Ｓ８０４では、タグ付与指示部５０４は、当該システムイメージファイル４１３のタグ４１２の値を、Ｓ８０２でデプロイしたデプロイ環境を示す値に更新するよう、サービスマネージャ１０２に指示する。その後、サービスマネージャ１０２は、タグ付与指示部５０４からの指示に基づき、タグの値を更新する。

なお、Ｓ８０２で、デプロイ実行指示部５０３が開発環境に処理システムをデプロイした場合は、Ｓ８０４に処理が進められて、タグ付与指示部５０４は、ＴＲのタグ４１２の値を付与する。また、例えば、ＴＲのタグが付いたシステムイメージファイルを用いて開発環境へのデプロイを実行した場合、タグの値は更新されずにＴＲの値が維持されることとなる。

図９は、タグ４１２に応じたシステムイメージファイル４１３の削除条件テーブルの例を示す図である。当該テーブルは、ＤＢ１０４によって保持され、タグ４１２の値ごとに、システムイメージファイル４１３の削除条件が記載されている。本テーブルは、図１０を用いて後述するシステムイメージファイル４１３の削除処理にて参照される。

削除判定部５０５は、例えば、レコード９１１から９１６で示される削除条件を参照する。削除判定部５０５は、システムイメージファイルが作成されてから経過した時間が、タグごとに定められる所定時間を超えている場合に、そのシステムイメージファイルを削除対象であると判定する。例えば、システムイメージファイル４１３のタグ４１２がＴＲの場合、作成から３日以上経過している場合に削除する。タグ４１２がＴＳの場合、作成から１５日以上経過している場合に削除する。このように、システムイメージファイルに付与されるタグの値に応じて適切な削除条件を適用する。これにより、削除判定部５０５は、システムイメージファイルを用いて構築した環境を考慮して、当該システムイメージファイルについて削除すべきか否かの判定を行うことができる。

タグ更新順序テーブル（図６）で示した通り、ＴＲのタグをＴＳのタグに更新することが可能であり、ＴＲの場合よりもＴＳの場合の方が削除条件に係る所定時間が長い。例えば、本願に係るシステムでは、ＴＲのタグが付いたシステムイメージファイル１０個のうち、タグの値がＴＳに更新されるシステムイメージファイルはおよそ１個程度であることを想定している。つまり、ＴＲのタグが付与されるシステムイメージファイルは大量に作成されるため、ＴＲの場合の削除条件に係る所定時間は、ＴＳの場合の削除条件に係る所定時間に対して十分に短い必要がある。少なくともＴＲの場合の所定時間とＴＳの場合の所定時間との差分は、ＴＲの場合の所定時間以上であることが望ましい。これにより、ＴＳのタグが付いているシステムイメージファイルを、作成後に長い時間保持することができ、かつ、タグの値がＴＳに更新されずにＴＲのタグが維持されるシステムイメージファイルを早めに削除することができる。

また、タグ４１２がＰＲＤの場合、作成から経過した日時に関わらず削除は行わない。本番環境のデプロイに使用されてＰＲＤのタグが付与されたシステムイメージファイルを削除せずに保存することが可能となる。なお、後述する実施例３に記載の方法を用いることで、ＰＲＤのタグが付与されていて利用されなくなったシステムイメージファイルについても削除することができる。

削除条件テーブルに記載されている削除条件の日数は一例であり、特定の日数に限定されるものではない。ただし、削除条件ごとの日数には大小関係を持たせることで、より重要なシステムイメージファイル４１３の保持期間を長くすることができる。例えば、この実施例の場合にはシステムイメージファイル４１３の重要度は、ＴＲ＜ＴＳ＜ＰＲＶ≦ＤＥＭ＜ＲＨ＜ＰＲＤのようになっているため、削除条件の日数の大小関係もこれに従っている。なお、作成されてからの経過時間ではなく、タグの値が更新されてからの経過時間に基づいて削除条件が定められてもよい。

図１０は、システムイメージファイル削除指示処理の流れの例を示すフローチャートである。システムマネージャ１０１は、管理者の要求に応じて、または所定の時刻に、本フローチャートで示すシステムイメージファイルの削除処理を実行する。本フローチャートの処理は、例えば、一日に１回程度の頻度で、夜間などに実行される。

Ｓ１００２では、ファイル削除指示部５０６は、システムイメージファイル４１３の一覧を取得する。Ｓ１００３〜Ｓ１００７は、取得した各システムイメージファイル４１３に対して、繰り返し処理が実行される。Ｓ１００４では、ファイル削除指示部５０６は、システムイメージファイル４１３に付与されているタグ４１２の値を取得する。Ｓ１００５では、ファイル削除指示部５０６は、削除条件テーブルを参照し、システムイメージファイル４１３が削除条件を満たすかを判断する。削除条件を満たす場合、ファイル削除指示部５０６はＳ１００６を実行する。Ｓ１００６ではシステムイメージファイル４１３の削除をサービスマネージャ１０２に対して指示する。Ｓ１００７で、取得したすべてのシステムイメージファイルに対して処理が行われた場合に、ファイル削除指示部５０６は、本フローチャートの処理を終了する。

本実施例では、システムイメージファイルとデプロイ環境との対応付けを示すタグを付与して、タグに応じて削除条件を切り替えた。本実施例によれば、システムイメージファイルごとの適切な保持期間を管理でき、さらに保持期間を経過したシステムイメージファイルを削除することができる。

（実施例２）
実施例１では、システムイメージファイルについているタグの値に関係なく、そのシステムイメージファイルを用いてデプロイを実行可能としていた。それに対して本実施例では、システムイメージファイルについているタグの値に基づいて、そのシステムイメージファイルを用いてデプロイ実行の可否を判断するようにする。本実施例では、図１１と図１２を用いて実施例１との差異を中心に記述する。

図１１は、タグ４１２に応じたデプロイ可能なデプロイ環境テーブルの例を示す図である。当該テーブルは、ＤＢ１０４で保持され、システムイメージファイル４１３のタグの値ごとに、システムイメージファイル４１３を用いてデプロイ可能なデプロイ環境が記載されている。本テーブルを利用することにより、タグの値に応じて、デプロイ環境の構築の際に使用可能なシステムイメージファイルを判別できる。

システムマネージャ１０１のデプロイ実行指示部５０３は、例えば、レコード１１１１から１１１６で示されるデプロイ可能なデプロイ環境の値を参照して、デプロイの可否を判断する。例えば、システムイメージファイル４１３のタグ４１２の値がＴＲの場合、当該システムイメージファイルを用いてデプロイ可能なデプロイ環境はＴＲおよびＴＳのみである。これによりデプロイ実行指示部５０３が、ＴＲのタグが付いたシステムイメージファイルを用いてＰＲＶやＰＲＤなどにデプロイすることを防ぐことができる。

また、システムイメージファイル４１３のタグ４１２の値がＤＥＭの場合、当該システムイメージファイルをデプロイ可能なデプロイ環境はＰＲＤ以外である。これにより、ＤＥＭなどのタグが付いたシステムイメージファイルを用いて、ＰＲＤにデプロイすることを防ぐことができる。

図１２は、本実施例におけるタグ更新指示処理の流れの例を示すフローチャートである。システムマネージャ１０１は、管理者の要求に応じて、または所定の時刻に、本フローチャートで示す、デプロイ可否判定を伴うデプロイ処理を実行する。

実施例１の図８との差異はＳ１２０２が追加されている点であるため、その差異についてのみ説明する。

Ｓ１２０２では、デプロイ実行指示部５０３は、デプロイ環境テーブル（図１１）を参照し、デプロイしようとするシステムイメージファイル４１３のタグ４１２の値から、デプロイ可能なデプロイ環境の一覧を取得する。取得したデプロイ環境の一覧に、ユーザが要求した、または所定のデプロイ環境が含まれている場合、デプロイ実行指示部５０３は、Ｓ８０２を実行し、含まれていない場合、本フローチャートの処理を終了する。

例えば、ＴＳの評価環境で実施される品質保証部門による動作確認を経ていないシステムイメージファイル４１３を用いて、誤ってＰＲＤの本番環境にデプロイしてしまうことを防ぐことが可能となる。

本実施例では、システムイメージファイルに付与したタグを用いて、システムイメージファイル４１３ごとにデプロイの可否を判断した。本実施例によれば、システムイメージファイルに付与したタグの種類によって、デプロイ可能なデプロイ環境を制限することができる。

（実施例３）
実施例１、２では、本番環境へのデプロイに使用されたシステムイメージファイルは削除されなかった。それに対して本実施例では、Ｂｌｕｅ−ＧｒｅｅｎデプロイメントによりＢｌｕｅ環境が切り替えられていくことを利用して、システムイメージファイルを削除するための仕組みを説明する。本実施例では、図１３、図１４、図１５を用いて実施例１との差異を中心に記述する。

まず、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントについて説明する。

処理システムのバージョンアップの方法として、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが利用されている。このＢｌｕｅ−Ｇｒｅｅｎデプロイメントでは、現行バージョンのアプリケーションが動作するＢｌｕｅ環境の稼働中に、新しいバージョンのアプリケーションが動作するＧｒｅｅｎ環境を生成する。バージョンアップの予定日時に、ＤＮＳサーバのＤＮＳレコードをＢｌｕｅ環境からＧｒｅｅｎ環境に変更する。これにより、外部のネットワークシステムに属するコンピュータなどのクライアントからのリクエストを受け付ける処理システムがＢｌｕｅ環境からＧｒｅｅｎ環境に切り替えられて、サービスのバージョンアップが行われる。Ｂｌｕｅ環境やＧｒｅｅｎ環境は、デプロイ環境内に構築される処理システムを指す。

なお、Ｇｒｅｅｎ環境は、デプロイ環境内に複数含まれても良い。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントを実行する際には、切り替え先の処理システムとして任意のＧｒｅｅｎ環境を選択するといったことも可能である。

なお、本番環境以外の開発環境や評価環境などにおいても、上述のＣＩの中でＢｌｕｅ−Ｇｒｅｅｎデプロイメントを実施する。開発環境や評価環境などにおいては、例えば、テスト用として用意したクライアントからのリクエスト送信先を切り替えることで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが行われる。

また、以降の説明では、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行直前のＢｌｕｅ環境のことを、実行後においては現Ｂｌｕｅ環境に対して“１世代前のＢｌｕｅ環境”（旧Ｂｌｕｅ環境）と呼ぶこととする。さらに、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行直前の旧Ｂｌｕｅ環境のことを、実行後においては現Ｂｌｕｅ環境に対して“２世代前のＢｌｕｅ環境”と呼ぶこととする。

図１３は、本実施例におけるデプロイ環境の構成例を示す図である。なお、図１３では、本番環境を示しているが、本番環境に限らず他のデプロイ環境であってもよい。また、Ｂｌｕｅ環境やＧｒｅｅｎ環境として機能する処理システムは、ＣＰＵやＲＡＭ、ＲＯＭを少なくとも備えるサーバコンピュータによってユーザに提供されるリソースを用いて構築される。

図１３（ａ）は、処理システム１３０Ｂと処理システム１３０ＣとについてのＢｌｕｅ−Ｇｒｅｅｎデプロイメントが実行される前の状態を示している。ここでは、処理システム１３０Ａは１世代前のＢｌｕｅ環境であり、処理システム１３０Ｂは現Ｂｌｕｅ環境であり、処理システム１３０ＣはＧｒｅｅｎ環境である。

図１３（ｂ）は、処理システム１３０Ｂと処理システム１３０ＣとについてのＢｌｕｅ−Ｇｒｅｅｎデプロイメントが実行された後の状態を示している。このＢｌｕｅ−Ｇｒｅｅｎデプロイメントによって、処理システム１３０Ｂが１世代前のＢｌｕｅ環境となり、処理システム１３０ＣがＢｌｕｅ環境となった。また、処理システム１３０Ａが現Ｂｌｕｅ環境に対して２世代前のＢｌｕｅ環境となった。

ここで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントでは、１世代前のＢｌｕｅ環境をすぐに削除するのではなく一定時間保持しておく。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによる切り替え後に何らかの問題が生じた場合には、１世代前のＢｌｕｅ環境へ戻される場合があるためである。それに対して、２世代前のＢｌｕｅ環境へは戻される可能性がないため、図１３（ｂ）における処理システム１３０Ａを削除する。本実施例では、２世代前のＢｌｕｅ環境が削除されることに応じて、該Ｂｌｕｅ環境のデプロイに使用されたシステムイメージファイルを削除するようにする。

図１４は、本実施例のシステムマネージャ１０１の構成例を示す図である。本実施例のシステムマネージャ１０１は、図５に記載の構成に加えて、処理システム削除指示部１４０７とテーブル更新部１４０８がある。

処理システム削除指示部１４０７は、２世代前のＢｌｕｅ環境となった処理システムなどを削除する。テーブル更新部１４０８は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントの実行後に、図１５を用いて後述する、システムイメージファイルを管理するためのテーブルのレコードを更新する。

図１５は、システムイメージファイルの管理テーブルの例を示す図である。本テーブルは、ＤＢ１０４で保持され、デプロイ環境ごとに、Ｂｌｕｅ環境と旧Ｂｌｕｅ環境で使用されたシステムイメージファイル４１３の識別子が記載される。各レコードはテーブル更新部１４０８によって更新され、削除判定部５０５によって参照される。

削除判定部５０５は、例えば、レコード１５１１から１５１６で示される現在使用中のシステムイメージファイル４１３の値を参照して、システムイメージファイル４１３を削除すべきか否かを判断する。図１５のテーブルでは、Ｂｌｕｅ環境のデプロイに使用されたシステムイメージファイルと、１世代前のＢｌｕｅ環境のデプロイに使用されたシステムイメージファイルの情報が保持されている。一方、図１５のテーブルでは、２世代前のＢｌｕｅ環境となった処理システムのデプロイに使用されたシステムイメージファイルの情報は保持されていない。例えば、図１５のテーブルでは、“Ｆｒｏｎｔ−２０１４０４０１−１５００００”という識別子を持つシステムイメージファイル４１３のデータは記載されていない。そのため、削除判定部５０５は、そのシステムイメージファイルを削除することが可能であると判断できる。一方で、２世代前のＢｌｕｅ環境となった処理システムのデプロイに使用されたシステムイメージファイルが、他のデプロイ環境において構築されている処理システムのために使用されている場合、当該システムイメージファイルの情報は本テーブルに記載される。したがって、削除判定部５０５は、当該イメージファイルを削除すべきでないと判断できる。

テーブル更新部１４０８は、例えば、開発環境のＢｌｕｅ−Ｇｒｅｅｎデプロイメント後に次の処理を実施する。まず、テーブル更新部１４０８は、当該テーブルのＴＲのＢｌｕｅ環境のシステムイメージファイルに記載されている識別子を、ＴＲの旧Ｂｌｕｅ環境のシステムイメージファイルに記載する。そして、テーブル更新部１４０８は、Ｂｌｕｅ環境のデプロイに使用されたシステムイメージファイル４１３の識別子を、ＴＲのＢｌｕｅ環境のシステムイメージファイルに記載する。これにより、各デプロイ環境のＢｌｕｅ環境およびその１世代前のＢｌｕｅ環境で使用されているシステムイメージファイル４１３を管理することができる。テーブルで管理されなくなった２世代前のＢｌｕｅ環境のシステムイメージファイルは、図１６を用いて後述するデプロイ処理において、削除されることとなる。

なお、Ｂｌｕｅ環境、１世代前のＢｌｕｅ環境、及び２世代前のＢｌｕｅ環境のそれぞれで使用されるシステムイメージファイルには異なる識別子が付与されて、異なるファイルとして管理されてもよい。また、ある処理システムで使用される複数のシステムイメージファイルのうち一部は、他の処理システムで使用されるシステムイメージファイルと同じでもよい。

図１６は、本実施例におけるタグ更新指示処理およびシステムイメージファイル削除指示処理の流れの例を示す図である。システムマネージャ１０１は、管理者の要求に応じて、または所定の時刻に、本フローチャートで示す、システムマネージャ１０１によるシステムイメージファイル４１３の削除を伴うデプロイ処理を実行する。本実施例では、本番環境についてのデプロイ処理として説明しているが、本番環境についてのデプロイに限定されるものではない。実施例１の図８との差異はＳ１６０６以降であるため、その差異についてのみ記述する。

Ｓ１６０６では、システムマネージャ１０１は、システム１００内にあるＤＮＳサーバ（不図示）上のＤＮＳレコードを書き換えるようサービスマネージャ１０２に対して指示する。ＤＮＳサーバは、クライアントからのリクエストの受信に応じて当該クライアントへの応答のための情報として、当該リクエストの送信先を示すレコードを保持する。指示を受けたサービスマネージャ１０２がＤＮＳレコードを書き換えることで、Ｂｌｕｅ環境となる処理システムが切り替わる。これによりＳ８０２での指示によりデプロイされたＧｒｅｅｎ環境がＢｌｕｅ環境となる。

Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが実行された後、Ｓ１６０７で、処理システム削除指示部１４０７は、現Ｂｌｕｅ環境に対して２世代前のＢｌｕｅ環境となった処理システムの削除をサービスマネージャ１０２に対して指示する。図１３（ｂ）の例では、処理システム１３０Ａの削除の指示が行われることになる。この指示を受けたサービスマネージャ１０２は、その２世代前のＢｌｕｅ環境となった処理システムを削除する。

Ｓ１６０８で、ファイル削除指示部５０６は、システムイメージファイル４１３の一覧を取得する。ここで取得されるシステムイメージファイルの一覧には、Ｓ１６０７で削除指示された２世代前のＢｌｕｅ環境に対応する複数のシステムイメージファイルが少なくとも含まれる。

その後Ｓ１６０９で、テーブル更新部１４０８は、テーブル（図１５）のレコード１５１６を更新する。テーブル更新部１４０８は、Ｂｌｕｅ環境のシステムイメージファイルの値を１世代前のＢｌｕｅ環境のシステムイメージファイルにコピーする。そして、テーブル更新部１４０８は、Ｂｌｕｅ環境のシステムイメージファイルには、Ｓ８０２におけるデプロイで使用したシステムイメージファイル４１３の識別子を記載する。

Ｓ１６１０〜Ｓ１６１３で、Ｓ１６０９で取得したシステムイメージファイル４１３それぞれに対して、繰り返し処理が実行される。Ｓ１６１１で、ファイル削除指示部５０６は、当該システムイメージファイル４１３がテーブル（図１５）のレコード１５１１から１５１６に記載されていないかを判定する。もし本テーブルに記載されていれば、すなわち、他のデプロイ環境で既に構築されているＢｌｕｅ環境や１世代前のＢｌｕｅ環境のために当該システムイメージファイルが用いられていれば、当該システムイメージファイルを削除しないようにする。本テーブルに記載されていない場合、ファイル削除指示部５０６は、Ｓ１６１２を実行する。Ｓ１６１２で、ファイル削除指示部５０６は、該当のシステムイメージファイル４１３の削除をサービスマネージャ１０２に対して指示する。Ｓ１６１３で、取得したすべてのシステムイメージファイルに対して処理が行われた場合に、本フローチャートの処理が終了する。

本実施例では、Ｂｌｕｅ−ＧｒｅｅｎデプロイメントによりＢｌｕｅ環境が切り替えられていくことを利用して、現行のＢｌｕｅ環境に対して２世代前のＢｌｕｅ環境のデプロイに使用されたシステムイメージファイルを削除した。実施例１、２では、ＰＲＤのタグが付いたシステムイメージファイルを削除しなかったが、本実施例により、ＰＲＤのタグが付いたシステムイメージファイルを、一定の保持期間が経過後に削除することが可能となる。また、ＰＲＤ以外のタグが付いていて不要となったイメージファイルについても、削除条件テーブル（図９）に記載の条件にしたがって削除するよりも、早いタイミングで該システムイメージファイルを削除することができる可能性がある。つまり、システムイメージファイルに付与されたタグの値に依存せずに、再利用性の低いシステムイメージファイルの削除を判定することができる。

（実施例４）
本実施例では、システムイメージファイルを用いてデプロイを行った後に、処理システムの動作確認を行い、その確認結果によってその後の処理を切り分けるようにする。

図１７は、本実施例におけるタグ更新指示処理の流れの例を示すフローチャートである。実施例１との差異を中心に記述する。

Ｓ８０２でのシステムイメージファイルを用いたデプロイの後、Ｓ１７０３で処理システムの動作確認が行われる。動作確認は、システム１００の外部にあるクライアントコンピュータ（不図示）、あるいはそれを模したものを利用して処理システムにアクセスし、想定通りの挙動を示すかの確認が行われる。動作確認で実施する内容はデプロイ環境ごとに異なる場合が考えられる。例えば、開発環境では開発者による簡易的なテストによる評価が実施され、評価環境では品質保証の担当者による厳密な評価が実施される。さらに、リハーサル環境では本番リリース前の手順確認が行われ、本番環境では実際のユーザへのサービス提供を含む確認などが行われる。

Ｓ１７０４では、Ｓ１７０３で実行した動作確認によって問題が確認されなかった場合にはＳ８０３に処理が進められ、問題が確認された場合には本フローチャートの処理を終了する。Ｓ８０３以降の処理は、図８と同様である。

なお、Ｓ１７０３での処理システムの動作確認は、別のタイミングで実行されてもよい。例えば、タグを更新した後であって、かつ、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが実行される前であってもよい。

本実施例によれば、処理システムの動作確認で問題が確認された場合には、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントなどを実行しないようにした。このように、処理システムの動作確認の結果により、その後の処理を変更することが可能となる。

以上説明した実施例１〜実施例４をそれぞれ組み合わせることが可能である。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１００ システム
１１０ 管理者コンピュータ
５０５ 削除判定部
５０６ ファイル削除指示部

Claims (13)

1. 少なくとも仮想マシンで動作するソフトウェアの情報を含むシステムイメージファイルを保存する記憶装置から、前記システムイメージファイルを削除するための管理システムであって、
   システムイメージファイルを用いて起動された仮想マシンを含む処理システムが構築された環境に対応する属性の値を該システムイメージファイルへ付与するよう指示する付与指示手段と、
   前記付与指示手段の指示によりシステムイメージファイルに付与される属性の値に応じた条件として、該システムイメージファイルが作成されてから経過した時間が、該システムイメージファイルに付与される属性の値に応じた所定時間を超えるか否かに基づき、該システムイメージファイルを削除すべきか否かを判定する第１の判定手段と、
   前記第１の判定手段により削除すべきであると判定されたシステムイメージファイルを前記記憶装置から削除するよう指示する削除指示手段と、を有し、
   システムイメージファイルを用いて起動された仮想マシンを含む処理システムを構築できる環境として、少なくとも第１の環境および第２の環境があり、
   前記第１の環境に対応する属性の値に応じた第１の所定時間と、前記第２の環境に対応する属性の値に応じた第２の所定時間とは、異なることを特徴とする管理システム。
2. 前記第１の判定手段は、前記システムイメージファイルが作成されてから経過した時間が、該システムイメージファイルに付与される属性の値に対応する所定時間を超える場合に、該システムイメージファイルを削除すべきであると判定することを特徴とする請求項１に記載の管理システム。
3. 前記第１の判定手段は、
   第１の環境に対応する属性の値が付与されているシステムイメージファイルについて、該システムイメージファイルが作成されてから経過した時間が第１の所定時間を超える場合に、前記第１の環境に対応する属性の値に応じた条件を満たすとして、該システムイメージファイルを削除すべきであると判定し、
   前記付与指示手段の指示により前記第１の環境に対応する属性の値から更新可能な第２の環境に対応する属性の値が付与されているシステムイメージファイルについて、該システムイメージファイルが作成されてから経過した時間が第２の所定時間を超える場合に、前記第２の環境に対応する属性の値に応じた条件を満たすとして、該システムイメージファイルを削除すべきであると判定し、
   前記第２の所定時間は前記第１の所定時間よりも長く、かつ、前記第１の所定時間と前記第２の所定時間との差分は前記第１の所定時間以上であることを特徴とする請求項１または２に記載の管理システム。
4. システムイメージファイルに付与される属性の値に基づき、システムイメージファイルに付与される属性の値を更新可能であるか否かを判定する第２の判定手段を有し、
   前記付与指示手段は、システムイメージファイルを用いて起動された仮想マシンを含む処理システムが構築された際に、前記第２の判定手段により更新可能であると判定された前記システムイメージファイルの属性の値の更新を指示することを特徴とする請求項１乃至３のいずれか１項に記載の管理システム。
5. システムイメージファイルに付与される属性の値に基づき、処理システムの構築の際に、該システムイメージファイルを使用可能であるか否かを判定する第３の判定手段と、
   前記第３の判定手段により使用可能であると判定されたシステムイメージファイルを用いて起動された仮想マシンを含む処理システムが構築されることを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
6. システムイメージファイルを用いて起動された１以上の仮想マシンを含む処理システムが複数構築される環境について、
   該構築される複数の処理システムに、第１の処理システム、第２の処理システム及び第３の処理システムが含まれる場合に、
   前記第１の判定手段は、所定のネットワークシステムに含まれるクライアントからのリクエストを受け付ける処理システムが前記第１の処理システムから前記第２の処理システムに切り替えられた後、前記クライアントからのリクエストを受け付ける処理システムが前記第２の処理システムから前記第３の処理システムに切り替えられた際に、前記第１の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルを削除すべきであると判定することを特徴とする請求項１乃至５のいずれか１項に記載の管理システム。
7. システムイメージファイルを用いて起動された１以上の仮想マシンを含む処理システムが構築できる複数の環境があり、
   前記第１の判定手段は、前記複数の環境のうち特定の環境以外のいずれかの環境に対応する属性の値が付与されているシステムイメージファイルについて、該システムイメージファイルが作成されてから経過した時間が、該システムイメージファイルに付与された属性の値に対応する所定時間を超える場合に、当該環境に対応する属性の値に応じた条件を満たすとして、該システムイメージファイルを削除すべきであると判定し、
   さらに、前記第１の判定手段は、前記複数の環境のうちシステムイメージファイルを用いて起動された１以上の仮想マシンをそれぞれ含む第１の処理システム、第２の処理システム及び第３の処理システムが構築された環境について、所定のネットワークシステムに含まれるクライアントからのリクエストを受け付ける処理システムが前記第１の処理システムから前記第２の処理システムに切り替えられた後、前記クライアントからのリクエストを受け付ける処理システムが前記第２の処理システムから前記第３の処理システムに切り替えられた際に、前記第１の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルを、該システムイメージファイルに付与された属性の値に依らず、削除すべきであると判定することを特徴とする請求項１乃至５のいずれか１項に記載の管理システム。
8. 前記第１の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルと、前記第２の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルと、前記第３の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルとは、それぞれ異なることを特徴とする請求項６または７に記載の管理システム。
9. 前記第１の判定手段は、前記第１の処理システムに含まれる仮想マシンの起動に使用されたシステムイメージファイルが、既に構築されている処理システムのために用いられていない場合に、当該システムイメージファイルを削除すべきであると判定することを特徴とする請求項６乃至８のいずれか１項に記載の管理システム。
10. 前記クライアントからのリクエストを受け付ける処理システムを切り替えるための指示を行う切り替え指示手段を有し、
    前記指示に応じて、前記クライアントからのリクエストを受け付ける処理システムの切り替えのために、前記クライアントからのリクエストの受信に応じて前記クライアントへの応答を行うＤＮＳサーバで保持されるリクエストの送信先を示すレコードが書き換えられることを特徴とする請求項６乃至９のいずれか１項に記載の管理システム。
11. システムイメージファイルを用いて起動された仮想マシンを含む処理システムの動作確認を行う確認手段を有し、
    前記付与指示手段は、前記確認手段による動作確認で問題が確認されなかった場合に、前記システムイメージファイルへの属性の値の付与または更新を指示することを特徴とする請求項１乃至１０のいずれか１項に記載の管理システム。
12. 前記仮想マシンを含む複数の仮想マシンは、１台のサーバコンピュータ上で動作することを特徴とする請求項１乃至１１のいずれか１項に記載の管理システム。
13. 少なくとも仮想マシンで動作するソフトウェアの情報を含むシステムイメージファイルを保存する記憶装置から、前記システムイメージファイルを削除するための管理システムの制御方法であって、
    前記管理システムが、システムイメージファイルを用いて起動された仮想マシンを含む処理システムが構築された環境に対応する属性の値を該システムイメージファイルへ付与するよう指示する付与指示工程と、
    前記管理システムが、前記付与指示工程での指示によりシステムイメージファイルに付与される属性の値に応じた条件として、該システムイメージファイルが作成されてから経過した時間が、該システムイメージファイルに付与される属性の値に応じた所定時間を超えるか否かに基づき、該システムイメージファイルを削除すべきか否かを判定する第１の判定工程と、
    前記管理システムが、前記第１の判定工程において削除すべきであると判定されたシステムイメージファイルを前記記憶装置から削除するよう指示する削除指示工程と、を有し、
    システムイメージファイルを用いて起動された仮想マシンを含む処理システムを構築できる環境として、少なくとも第１の環境および第２の環境があり、
    前記第１の環境に対応する属性の値に応じた第１の所定時間と、前記第２の環境に対応する属性の値に応じた第２の所定時間とは、異なることを特徴とする制御方法。

Images