以下に、本願の開示する運用仕様分析装置、運用仕様分析方法及び運用仕様分析プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
まず、実施例に係る運用仕様記述について説明する。実施例では、運用仕様は、運用仕様グラフで表される。運用仕様グラフでは、システムの構成要素、構成要素の状態及び構成要素のメソッドが、ノードで表され、構成要素間の関係、構成要素と状態の関係及び構成要素と構成要素に対する操作の関係はノード間のエッジで表される。ここで、構成要素のメソッドとは、構成要素に対する操作である。
図1Aは、現行システムの運用仕様グラフの例を示す図であり、図1Bは、マネージドサービスの運用仕様グラフの例を示す図である。現行システムは、オンプレミス又はプライベートクラウド上で動作する。
図1Aに示すように、現行システムの運用仕様グラフは、現行システムのシステム構成と運用作業に基づいて作成される。図1Aでは、「Linux(登録商標、以下同様)」上で「Apache」が動作するという構成情報から、「Linux」と「Apache」がノードとして表される。また、「Linux」上で「Apache」が動作するという関係は、「Linux」から「Apache」への「has」が付加された矢印で表される。なお、LinuxはOSであり、Apacheは、Webサーバソフトウェアである。
同様に、「Linux」上で「Job管理」が動作するという構成情報から、「Job管理」がノードとして表される。また、「Linux」上で「Job管理」が動作するという関係は、「Linux」から「Job管理」への「has」が付加された矢印で表される。
また、「Apache」には「isAlive」という状態があるという運用作業情報から、「isAlive」がノードとして表される。また、「Apache」には「isAlive」という状態があるという関係は、「Apache」から「isAlive」への「status」が付加された矢印で表される。
同様に、「Linux」には「httpStatus」という状態があるという運用作業情報から、「httpStatus」がノードとして表される。また、「Linux」には「httpStatus」という状態があるという関係は、「Linux」から「httpStatus」への「status」が付加された矢印で表される。
また、「Apache」には「起動」、「停止」及び「アクセスログバックアップ」のメソッドがあるという運用作業情報から、「起動」、「停止」及び「アクセスログバックアップ」がノードとして表される。また、「Apache」には「起動」、「停止」及び「アクセスログバックアップ」のメソッドがあるという関係は、「Apache」と「起動」、「停止」及び「アクセスログバックアップ」それぞれとを接続するエッジで表される。
同様に、「isAlive」には「監視」のメソッドがあるという運用作業情報から、「監視」がノードとして表され、「isAlive」には「監視」のメソッドがあるという関係は、「isAlive」と「監視」とを接続するエッジで表される。同様に、「httpStatus」には「監視」のメソッドがあるという運用作業情報から、「監視」がノードとして表され、「httpStatus」には「監視」のメソッドがあるという関係は、「httpStatus」と「監視」とを接続するエッジで表される。
また、図1Bに示すように、マネージドサービスの運用仕様グラフには、「Webサーバサービス」、「httpstatus」、「isAlive」、「起動」、「停止」及び「監視」で表されるノードが含まれる。「Webサーバサービス」は、マネージドサービスの1つである。「httpstatus」及び「isAlive」は、「Webサーバサービス」の状態である。「起動」及び「停止」は、「Webサーバサービス」のメソッドである。2つの「監視」は、それぞれ「httpstatus」及び「isAlive」のメソッドである。マネージドサービスの運用仕様グラフは、後述するように、マネージドサービスの仕様に基づいて作成される。
なお、「Linux:OS」、「Apache:Webサービス」及び「Webサーバサービス:Webサービス」の「OS」及び「Webサービス」は、クラス名である。クラス名「Webサービス」は、「Apache」と「Webサーバサービス」とのマッチングに用いられる。マッチングについては後述する。
実施例に係る運用仕様分析装置は、図1Aに示した現行システムの運用仕様グラフと図1Bに示したマネージドサービスの運用仕様グラフを比較することで、現行システムの運用仕様のうちマネージドサービスで実現されている範囲を特定する。ただし、現行システムでは、構成要素Xで動作する構成要素Yの状態が構成要素Xの状態として認識される場合がある。
例えば、OSの出力するsyslogから取得される状態「httpStatus」は、OS上で動作するミドルウェア「Apache」の状態を示している。また、ミドルウェア「Job管理」の「スケジュール情報」は、「Job管理」で動作する「ジョブ」の「スケジュール情報」を示している。
そこで、実施例に係る運用仕様分析装置は、構成要素ノードXと「status」の関係にある状態ノードAを、ノードXと「has」の関係にある構成要素ノードYと「status」の関係でつないで、現行システムの運用仕様グラフを拡張する。図2は、図1Aに示した運用仕様グラフの拡張グラフを示す図である。図2に示すように、構成要素「Linux」と構成要素[Apache]は「has」の関係にある。また、構成要素「Linux」と状態「httpStatus」は「status」の関係にあるので、実施例に係る運用仕様分析装置は、構成要素「Apache」に状態「httpStatus」を「status」関係でつなげる。
このように、実施例に係る運用仕様分析装置は、現行システムの運用仕様グラフを拡張し、マネージドサービスの運用仕様グラフと一致する箇所を増やすので、現行システムの運用仕様のうちマネージドサービスで実現されている範囲を正確に特定することができる。
次に、実施例に係る運用仕様分析装置の構成について説明する。図3は、実施例に係る運用仕様分析装置の機能構成を示す図である。図3に示すように、実施例に係る運用仕様分析装置1は、運用仕様グラフ生成部11と、関係情報記憶部12と、対応表記憶部13と、現行グラフ記憶部14と、マネージドサービスグラフ記憶部15と、拡張部16と、拡張グラフ記憶部17とを有する。また、運用仕様分析装置1は、クエリグラフ生成部18と、クエリグラフ記憶部19と、グラフマッチング部20と、マッチング結果記憶部21と、実現範囲生成部22とを有する。
運用仕様グラフ生成部11は、マネージドサービス仕様情報2、現行システム構成情報3及び現行運用作業リスト4を入力し、現行システムの運用仕様グラフ及びマネージドサービスの運用仕様グラフを生成する。運用仕様グラフ生成部11は、マネージドサービス仕様情報2、現行システム構成情報3及び現行運用作業リスト4を、例えば、ファイルから入力する。
マネージドサービス仕様情報2は、移行先のパブリッククラウドが提供するマネージドサービスの仕様に関する情報である。図4は、マネージドサービス仕様情報2の一例を示す図である。図4に示すように、マネージドサービス仕様情報2は、マネージドサービスの状態及びメソッドに関する情報及び状態のメソッドに関する情報である。
例えば、「Webサーバサービス」のメソッドには、「起動」と「停止」がある。また、「Webサーバサービス」の状態には、「isAlive」と「httpStatus」がある。また、「isAlive」及び「httpStatus」のメソッドには「監視」がある。
現行システム構成情報3は、現行システムを構成する構成要素と構成要素間の関係に関する情報である。図5は、現行システム構成情報3の一例を示す図である。図5では、現行システム構成情報3は、XML(eXtensible Markup Language)で記述されている。
図5において、<OSSetting>タグにより、構成要素「Linux:OS」が定義されている。また、<InstalledApplication>タグにより、構成要素「Apache」が定義されている。
現行運用作業リスト4は、現行システムに対する運用作業の情報である。図6は、現行運用作業リスト4の一例を示す図である。図6に示すように、現行運用作業リスト4は、現行システムの構成要素の状態及びメソッドに関する情報及び状態のメソッドに関する情報である。
例えば、「Apache」のメソッドには、「起動」と「停止」がある。また、「Apache」の状態には「isAlive」があり、「Linux」の状態には「httpStatus」がある。また、「isAlive」及び「httpStatus」のメソッドには「監視」がある。
図7は、現行システムの運用仕様グラフの生成を説明するための図である。図7に示すように、運用仕様グラフ生成部11は、現行システム構成情報3から「has」の関係を抽出し、構成要素をノードとするグラフ(A)を作成する。運用仕様グラフ生成部11は、現行システム構成情報3をXMLファイルのパースプログラムによりパースし、関連のある構成要素を抽出する。
現行システム構成情報3から「has」の関係を抽出するためのタグの情報については関係情報記憶部12に記憶される。図8は、関係情報記憶部12が記憶するタグの例を示す図である。図8に示すように、<LogicalServers><OSSetting>,<InstalledApplication><LegacyApplications><LegacyApplication>が「has」の関係を抽出するために使われる。このタグに基づいて、図7に示すように、OS上で動作するミドルウェアとして「Apache」が抽出される。
また、運用仕様グラフ生成部11は、ミドルウェアを抽出した際、対応表記憶部13が記憶する対応表を参照してミドルウェアのクラス名をミドルウェア名に追加する。図7では、「Apache」にクラス名「Webサービス」が追加されている。図9は、対応表の一例を示す図である。図9に示すように、対応表は、構成要素又はマネージドサービスをクラスに対応付ける。例えば、「Apache」は「Webサービス」に対応付けられる。
また、図8の<LogicalServers><OSSetting>,<LogicalServers><OSServices><OSService>も「has」の関係を抽出するために使われる。このタグからは、OSが提供するサービスが構成要素として抽出される。
また、運用仕様グラフ生成部11は、図7に示すように、現行運用作業リスト4から「status」及びメソッドの関係を抽出し、状態及びメソッドをノードとするグラフをグラフ(A)に追加する。すなわち、運用仕様グラフ生成部11は、現行運用作業リスト4の各行について構成要素に対するメソッドのノード(関係はメソッド)、構成要素に対する状態のノード(関係は「status」)を関係を表すエッジとともにグラフ(A)に追加する。また、運用仕様グラフ生成部11は、状態に対するメソッド(関係はメソッド)のノードを関係を表すエッジとともにグラフ(A)追加する。図7では、メソッドの関係はエッジのみで表される。
このように、運用仕様グラフ生成部11は、状態及びメソッドをノードとするグラフをグラフ(A)に追加することで、現行システムの運用仕様グラフを生成する。なお、グラフ表記については、「ノード,エッジ,ノード」組のセットで表す等、後述するマッチングに適した表記であれば限定はない。ここでは、説明の便宜上、グラフは図で表される。
運用仕様グラフ生成部11は、現行システムについて生成した運用仕様グラフの情報を現行グラフ記憶部14に格納する。現行グラフ記憶部14は、現行システムの運用仕様グラフの情報を記憶する。
図10は、マネージドサービスの運用仕様グラフの生成を説明するための図である。運用仕様グラフ生成部11は、マネージドサービス仕様情報2から「status」及びメソッドの関係を抽出し、マネージドサービス、状態及びメソッドをノードとするグラフをマネージドサービスの運用仕様グラフとして生成する。
すなわち、運用仕様グラフ生成部11は、マネージドサービス仕様情報2を用いて、マネージドサービスに対するノード、マネージドサービスに対するメソッドのノード(関係はメソッド)を生成する。また、運用仕様グラフ生成部11は、マネージドサービスに対するノードを生成する際に対応表記憶部13が記憶する対応表を参照してマネージドサービスのクラス名をマネージドサービス名に追加する。また、運用仕様グラフ生成部11は、マネージドサービス仕様情報2を用いて、マネージドサービスに対する状態のノード(関係は「status」)、その状態に対するメソッドのノード(関係はメソッド)を関係を表すエッジとともに生成する。
運用仕様グラフ生成部11は、マネージドサービスについて生成した運用仕様グラフの情報をマネージドサービスグラフ記憶部15に格納する。マネージドサービスグラフ記憶部15は、マネージドサービスの運用仕様グラフの情報を記憶する。なお、運用仕様グラフ生成部11は、特許請求の範囲のグラフ生成部に対応する。
図3に戻って、拡張部16は、現行グラフ記憶部14から現行システムの運用グラフの情報を読み出し、現行システムの運用仕様グラフを状態ノードの接続状況をもとに拡張する。
すなわち、拡張部16は、現行システムの運用仕様グラフの全ノード全エッジに関し、「ノードX,has,ノードY」、「ノードX,status,ノードA」の関係があると「ノードY,status,ノードA」となるエッジ「status」を追加する。ここで、「ノードX,has,ノードY」は、ノードXとノードYがエッジ「has」で接続していることを表し、「ノードX,status,ノードA」は、ノードXとノードAがエッジ「status」で接続していることを表す。
図11は、現行システムの運用仕様グラフの拡張を説明するための図である。図11に示すように、ノードXを「Linux:OS」、ノードYを「Apache:Webサービス」、ノードAを「httpStatus」とすると、拡張部16は、「Y=Apache:Webサービス,status,httpStatus」を追加する。
拡張部16は、現行システムの運用仕様グラフを拡張した拡張グラフの情報を拡張グラフ記憶部17に格納する。拡張グラフ記憶部17は、拡張グラフの情報を記憶する。
クエリグラフ生成部18は、マネージドサービスグラフ記憶部15からマネージドサービスの運用仕様グラフの情報を読み出し、マネージドサービスの運用仕様グラフのルートから各メソッドノードまでの部分木をクエリグラフとして生成する。
図12は、クエリグラフの生成を説明するための図である。図12に示すように、「Webサーバサービス:Webサービス」をルートとし、「httpStatus」の「監視」までの部分木が、クエリグラフ#1として生成される。また、「Webサーバサービス:Webサービス」をルートとし、「isAlive」の「監視」までの部分木が、クエリグラフ#2として生成される。また、「Webサーバサービス:Webサービス」をルートとし、「停止」までの部分木が、クエリグラフ#3として生成される。また、「Webサーバサービス:Webサービス」をルートとし、「起動」までの部分木が、クエリグラフ#4として生成される。
クエリグラフ生成部18は、生成したクエリグラフを用いて図12に示すクエリグラフリスト5を作成し、クエリグラフリスト5の情報をクエリグラフ記憶部19に格納する。クエリグラフリスト5は、クエリグラフを識別するクエリグラフIDとクエリグラフを対応付けたリストである。クエリグラフ記憶部19は、クエリグラフリスト5の情報を記憶する。なお、クエリグラフ生成部18は、特許請求の範囲の部分木生成部に対応する。
グラフマッチング部20は、クエリグラフ記憶部19からクエリグラフリスト5の情報を読み出し、拡張グラフ記憶部17から拡張グラフの情報を読み出す。そして、グラフマッチング部20は、クエリグラフリスト5の各クエリグラフについて、拡張グラフとのグラフマッチングを行う。
グラフマッチング部20は、グラフマッチングを行う際に、構成要素ノードについては、「クラス名」でマッチングする。例えば、「Apache:Webサービス」のクラス名は「Webサービス」であり、「Webサーバサービス:Webサービス」のクラス名は「Webサービス」であるので、「Apache」と「Webサーバサービス」はマッチする。
図13は、グラフマッチングを説明するための図である。図13に示すように、「Apache」と「Webサーバサービス」がマッチするため、クエリグラフ#1は、拡張グラフとマッチする。同様に、クエリグラフ#2〜クエリグラフ#4も拡張グラフとマッチする。
グラフマッチング部20は、グラフマッチングの結果を図13に示すマッチング結果6としてマッチング結果記憶部21に格納する。マッチング結果記憶部21は、マッチング結果6を記憶する。マッチング結果6では、クエリグラフIDと、結果と、状態又は構成要素と、メソッドとがクエリグラフ毎に対応付けられる。
結果は、拡張グラフがクエリグラフを含む場合には「あり」であり、拡張グラフがクエリグラフを含まない場合には「なし」である。状態又は構成要素は、クエリグラフに含まれる状態ノード又は構成要素ノードである。メソッドは、クエリグラフに含まれるメソッドノードである。例えば、クエリグラフ#1は、拡張グラフとマッチするので、結果は「あり」であり、状態又は構成要素は「httpStatus」であり、メソッドは「監視」である。
なお、グラフマッチング部20は、グラフマッチングについてgrepVS等の既存の処理を利用する。grepVSは、グラフ構造をインデックス(各ノードを起点とした長さL以下の全パスの連結)表現で表し、インデックス間の比較によってマッチングを行う。grepVSを利用する場合には、運用仕様グラフのつながりの拡張(追加)はインデックスの追加で表される。グラフマッチング部20は、特許請求の範囲のマッチング部に対応する。
実現範囲生成部22は、マッチング結果記憶部21からマッチング結果6を読み出し、マッチング結果6に基づいて、現行運用作業リスト4の各メソッドの実現可否を特定する。そして、実現範囲生成部22は、特定した実現可否に基づいて、現行運用作業リスト4のうち実現可のメソッドについては運用実現範囲とし、実現否のメソッドについては運用実現不可範囲とする運用実現範囲情報10を生成して出力する。
図14は、運用実現範囲情報10の生成を説明するための図である。図14に示すように、マッチング結果6と現行運用作業リスト4に基づいて、実現可否結果7が生成される。実現可否結果7の実現可否は、マッチング結果6が「あり」である場合には「1」であり、マッチング結果6が「なし」である場合には「0」である。例えば、マッチング結果6において、クエリグラフIDが「3」であるクエリグラフは、結果が「あり」であるので、実現可否結果7の「Webサービス」の「起動」の「実現可否」は「1」となる。
そして、実現可否結果7に基づいて、運用実現範囲8と運用実現不可範囲9が生成され、出力される。運用実現範囲8には、実現可否が「1」である、「Webサービス」の「起動」及び「停止」、「Webサービス」の「isAlive」の「監視」、「Linux:OS」の「httpStatus」の「監視」が含まれる。なお、実現範囲生成部22は、特許請求の範囲の出力部に対応する。
次に、運用仕様分析装置1による処理のフローについて説明する。図15は、運用仕様分析装置1による処理のフローを示すフローチャートである。図15に示すように、運用仕様分析装置1は、現行システム及びマネージドサービスについて、運用仕様グラフを生成する(ステップS1)。
そして、運用仕様分析装置1は、現行システムの運用仕様グラフを拡張し(ステップS2)、マネージドサービスの運用仕様グラフからクエリグラフを生成する(ステップS3)。
そして、運用仕様分析装置1は、各クエリグラフについて、拡張グラフとのグラフマッチングを行い(ステップS4)、マッチング結果6に基づいて、各運用作業の実現可否を判定する(ステップS5)。そして、運用仕様分析装置1は、運用実現範囲情報10を生成し(ステップS6)、出力する。
このように、運用仕様分析装置1は、現行システムの運用仕様グラフとマネージドサービスの運用仕様グラフを比較することで、マネージドサービスによる現行システムの運用実現範囲を特定することができる。
図16は、現行システムの運用仕様グラフを生成する処理のフローを示すフローチャートである。図16は、図15に示したステップS1の処理のうち現行システムに関する処理を示す。図16に示すように、運用仕様グラフ生成部11は、空のグラフを用意し(ステップS11)、ステップS12〜ステップS14の処理を現行システム構成情報3の最後まで繰り返す。
すなわち、運用仕様グラフ生成部11は、現行システム構成情報3のタグを読み込み(ステップS12)、関係情報記憶部12が記憶するタグであるか否かを判定する(ステップS13)。そして、関係情報記憶部12が記憶するタグでない場合には、運用仕様グラフ生成部11は、ステップS12へ戻る。一方、関係情報記憶部12が記憶するタグである場合には、運用仕様グラフ生成部11は、タグから抽出した構成ノードに対応表より取得したクラス名を付加し、エッジ情報を「has」として構成ノードとエッジをグラフに追加し(ステップS14)、ステップS12へ戻る。
そして、現行システム構成情報3の最後まで処理すると、運用仕様グラフ生成部11は、ステップS15及びステップS16の処理を現行運用作業リスト4の最後まで繰り返す。すなわち、運用仕様グラフ生成部11は、現行運用作業リスト4の1行を読み込む(ステップS15)。そして、運用仕様グラフ生成部11は、グラフに、構成要素に対するメソッドノードを追加し、状態の情報がある場合には、構成要素に対してエッジ情報を「status」として状態ノードを追加し、メソッドノードを追加する(ステップS16)。そして、運用仕様グラフ生成部11は、ステップS15に戻る。
そして、現行運用作業リスト4を最後まで処理すると、運用仕様グラフ生成部11は、現行システムの運用仕様グラフの情報として、グラフの情報を現行グラフ記憶部14に格納する(ステップS17)。
図17は、マネージドサービスの運用仕様グラフを生成する処理のフローを示すフローチャートである。図17は、図15に示したステップS1の処理のうちマネージドサービスに関する処理を示す。図17に示すように、運用仕様グラフ生成部11は、マネージドサービスのノードを1つもつグラフを用意し、対応表よりマネージドサービスに対するクラスの情報を得てノード名に追記する(ステップS21)。
そして、運用仕様グラフ生成部11は、ステップS22及びステップS23の処理をマネージドサービス仕様情報2の最後まで繰り返す。すなわち、運用仕様グラフ生成部11は、マネージドサービス仕様情報2の1行を読み込む(ステップS22)。そして、運用仕様グラフ生成部11は、グラフに、マネージドサービスに対するノード及びメソッドノードを追加し、状態の情報がある場合には、エッジ情報を「status」とする状態ノード及びメソッドノードを追加する(ステップS23)。そして、運用仕様グラフ生成部11は、ステップS22に戻る。
そして、現行運用作業リスト4を最後まで処理すると、運用仕様グラフ生成部11は、マネージドサービスの運用仕様グラフの情報として、グラフの情報をマネージドサービスグラフ記憶部15に格納する(ステップS24)。
このように、運用仕様グラフ生成部11が、現行システム及びマネージドサービスの運用仕様グラフを作成することで、運用仕様分析装置1は、現行システムとマネージドサービスの運用仕様を比較することができる。
図18は、現行システムの運用仕様グラフを拡張する処理のフローを示すフローチャートである。図18は、図15に示したステップS2の処理を示す。図18に示すように、拡張部16は、各ノードnodeについて、ステップS31〜ステップS35の処理を行う。
すなわち、拡張部16は、nodeと「has」でつながるノードがあるか否かを判定し(ステップS31)、nodeと「has」でつながるノードがない場合には、ステップS31に戻って次のノードの処理を行う。
一方、nodeと「has」でつながるノードがある場合には、拡張部16は、つながるノードをnode#1として保持し(ステップS32)、nodeと「status」でつながるノードがあるか否かを判定する(ステップS33)。そして、nodeと「status」でつながるノードがない場合には、拡張部16は、ステップS31に戻って次のノードの処理を行う。
一方、nodeと「status」でつながるノードがある場合には、拡張部16は、つながるノードをnode#2として保持し(ステップS34)、node#1とnode#2を[status]で新規につなぐ(ステップS35)。そして、拡張部16は、ステップS31に戻って次のノードの処理を行う。
このように、拡張部16が、現行システムの運用仕様グラフを拡張することで、マネージドサービスの運用仕様グラフとマッチする可能性を高くすることができる。
図19は、クエリグラフを生成する処理のフローを示すフローチャートである。図19は、図15に示したステップS3の処理を示す。図19に示すように、クエリグラフ生成部18は、全てのマネージドサービスに対してステップS41〜ステップS46の処理を行う。
すなわち、クエリグラフ生成部18は、マネージドサービスを1つ選択し(ステップS41)、選択したマネージドサービスの運用仕様グラフの複製をクエリグラフ生成用グラフとする(ステップS42)。そして、クエリグラフ生成部18は、クエリグラフ生成用グラフにメソッドノードがなくなるまでステップS43〜ステップS46の処理を繰り返す。
すなわち、クエリグラフ生成部18は、クエリグラフ生成用グラフのマネージドサービスノードをルートとする木に対し、ルートから深さ優先探索し、リーフにたどりついた時点の経路を記録する(ステップS43)。
そして、クエリグラフ生成部18は、たどり着いたリーフノードがメソッドノードであるか否かを判定し(ステップS44)、メソッドノードである場合には、経路をクエリグラフとしてクエリグラフの情報をクエリグラフ記憶部19に格納する(ステップS45)。そして、クエリグラフ生成部18は、たどりついたリーフノードをクエリグラフ生成用グラフから削除し(ステップS46)、ステップS43に戻る。
図20は、クエリグラフ生成の変遷イメージを示す図である。図20(a)に示すように、クエリグラフ生成部18は、ステップS41において、「Webサーバサービス」を選択し、ステップS43において、「Webサーバサービス」→「httpStatus」→「監視」の経路を記録する。そして、クエリグラフ生成部18は、ステップS45において、経路の情報をクエリグラフ記憶部19に格納し、ステップS46において、(b)に示すように、「httpStatus」の「監視」を削除する。
そして、クエリグラフ生成部18は、ステップS43に戻って、「Webサーバサービス」→「httpStatus」を記録し、ステップS46において、(c)に示すように、「httpStatus」を削除する。
そして、クエリグラフ生成部18は、ステップS43に戻って、「Webサーバサービス」→「isAlive」を記録し、ステップS45において、経路の情報をクエリグラフ記憶部19に格納する。そして、クエリグラフ生成部18は、ステップS46において、(d)に示すように、「isAlive」の「監視」を削除する。
このように、クエリグラフ生成部18は、クエリグラフ生成用グラフのマネージドサービスノードをルートとする木に対し、ルートから深さ優先探索し、リーフのメソッドノードまでの経路をクエリグラフとすることで、クエリグラフを生成することができる。
上述してきたように、実施例では、運用仕様グラフ生成部11が、現行システムの運用仕様グラフとマネージドサービスの運用仕様グラフを生成する。そして、拡張部16が、現行システムの運用仕様グラフを拡張して拡張グラフを作成し、クエリグラフ生成部18が、マネージドサービスの運用仕様グラフからクエリグラフを生成する。そして、グラフマッチング部20が、拡張グラフとクエリグラフのマッチングを行い、実現範囲生成部22が、マッチング結果6に基づいて、運用実現範囲情報10を生成する。したがって、運用仕様分析装置1は、現行システムの運用仕様とマネージドサービスの運用仕様の比較を行うことできる。なお、拡張部16は省略してもよい。
また、実施例では、拡張部16は、現行システムの運用仕様グラフの全ノード全エッジに関し、「ノードX,has,ノードY」、「ノードX,status,ノードA」の関係があると「ノードY,status,ノードA」となるエッジを追加する。したがって、運用仕様分析装置1は、現行システムの運用仕様とマネージドサービスの運用仕様の比較を正確に行うことができる。
なお、実施例では、運用仕様分析装置1について説明したが、運用仕様分析装置1が有する構成をソフトウェアによって実現することで、同様の機能を有する運用仕様分析プログラムを得ることができる。そこで、運用仕様分析プログラムを実行するコンピュータについて説明する。
図21は、実施例に係る運用仕様分析プログラムを実行するコンピュータのハードウェア構成を示す図である。図21に示すように、コンピュータ50は、メインメモリ51と、CPU(Central Processing Unit)52と、LAN(Local Area Network)インタフェース53と、HDD(Hard Disk Drive)54とを有する。また、コンピュータ50は、スーパーIO(Input Output)55と、DVI(Digital Visual Interface)56と、ODD(Optical Disk Drive)57とを有する。
メインメモリ51は、プログラムやプログラムの実行途中結果などを記憶するメモリである。CPU52は、メインメモリ51からプログラムを読み出して実行する中央処理装置である。CPU52は、メモリコントローラを有するチップセットを含む。
LANインタフェース53は、コンピュータ50をLAN経由で他のコンピュータに接続するためのインタフェースである。HDD54は、プログラムやデータを格納するディスク装置であり、スーパーIO55は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。DVI56は、液晶表示装置を接続するインタフェースであり、ODD57は、DVDの読み書きを行う装置である。
LANインタフェース53は、PCIエクスプレス(PCIe)によりCPU52に接続され、HDD54及びODD57は、SATA(Serial Advanced Technology Attachment)によりCPU52に接続される。スーパーIO55は、LPC(Low Pin Count)によりCPU52に接続される。
そして、コンピュータ50において実行される運用仕様分析プログラムは、DVDに記憶され、ODD57によってDVDから読み出されてコンピュータ50にインストールされる。あるいは、運用仕様分析プログラムは、LANインタフェース53を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ50にインストールされる。そして、インストールされた運用仕様分析プログラムは、HDD54に記憶され、メインメモリ51に読み出されてCPU52によって実行される。
また、実施例では、オンプレミス又はプライベートクラウド上で動作する現行システムをパブリッククラウドへ移行する場合について説明した。しかしながら、本発明はこれに限定されるものではなく、パブリッククラウドで動作する現行システムを異なるパブリッククラウドへ移行する場合等で2つの運用仕様を比較する場合に同様に適用することができる。