JP7311384B2 - 表示情報処理装置、表示情報処理方法および表示情報処理プログラム - Google Patents

Description

本発明は、表示情報処理装置、表示情報処理方法および表示情報処理プログラムに関する。

ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システム管理では、性能障害に対する対応およびキャパシティプランニング等、多種にわたる観点（性能および容量等。以降、前記観点をＦｅａｔｕｒｅとも記す。）で管理業務が行われている。例えば、性能障害に対応する場合には、問題であるインフラリソースの性能状態を確認するとともに、複数問題の対処の優先順位をつけるために、影響を受ける関連アプリケーションリソースを確認する。このように、ＩＴシステム管理を行う上では、問題の重要性を測る指標となるアプリケーションリソースと、問題のあるインフラリソースのシステム構成の両方を俯瞰することが行われる。

上記の通り、ＩＴシステムの管理業務を効率的に行うためには観点を適宜切り替えつつ、インフラリソースとアプリケーションリソースの両方を含むＩＴシステム全体を容易に俯瞰し、把握できることが求められる。このような要求に対して、ＩＴシステムを構成する諸リソース間の関連をトポロジカルに表示する技術がある。

例えば、特許文献１では、クラウド環境上に構築されたＩＴシステムについて、ＩＴシステムを構成するリソースや、管理上のグループ単位（仮想ＤＣ、仮想サーバおよびセキュリティグループ等）の構成情報を収集し、それらの構成情報を基にシステム構成図を可視化する技術が開示されている。

また、構成要素とその関係を表示するためのグラフ描画アルゴリズムとして、非特許文献１に示す杉山フレームワークが知られている。杉山フレームワークでは、ノードの種類ごとに画面上のＹ座標が固定されるようなグラフについて、ノードの座標を効率的に計算することができる。この杉山フレームワークを用いてＩＴシステムの構成要素とその関係を表示できる。

また、特許文献２では、大規模ＩＴシステムをトポロジカルに表示した際に、ノード数が大量となり、視認性が低下することに鑑み、ユーザがズーム操作を行った場合に、ズームの度合いに応じて適切にノードを表示する技術が開示されている。

特願２０１６－５６５７７６号明細書 特願２０１５－５２９７２８号明細書

Ｋ． Ｓｕｇｉｙａｍａ， Ｓ． Ｔａｇａｗａ ａｎｄ Ｍ． Ｔｏｄａ， "Ｍｅｔｈｏｄｓ ｆｏｒ ｖｉｓｕａｌ ｕｎｄｅｒｓｔａｎｄｉｎｇ ｏｆ ｈｉｅｒａｒｃｈｉｃａｌ ｓｙｓｔｅｍ ｓｔｒｕｃｔｕｒｅｓ，" ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｓｙｓｔｅｍｓ， Ｍａｎ， ａｎｄ Ｃｙｂｅｒｎｅｔｉｃｓ， １１， ｐｐ． １０９－１２５， １９８１．

しかしながら、世界中に拠点を持つような大規模ＩＴシステム環境の管理において、インフラリソースを地理的要素でグルーピングしてトポロジ上に表示すると、各インフラノードが配置され得る画面上の座標が制限されることとなる。杉山フレームワークなどのグラフ描画アルゴリズムでは、ノード間のリンクの長さおよび交点数を極小化することを目的にノード配置を調整するため、局所解に陥る可能性が高まる。

それにより、あるアプリケーションが複数の仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：ＶＭとも言う）を利用している場合に、それらのＶＭノードが画面上の離れた場所に配置される場合が生じる。この場合には、例えば、アプリケーションノードとＶＭノード間のリンクの総距離を最小化しようとし、アプリケーションノードがどのＶＭノードからも離れた場所に配置されることがある。

このように、アプリケーションノードと、それに関連するＶＭノードが離れた画面上の場所に配置されると、ズームアウトし、ＩＴシステムの全体が表示される状態にしないと、アプリケーションノードとＶＭノードの両方を同時に、一画面で表示させることができなくなる。ＩＴシステムの全体を表示させた状態では、一画面に表示される情報量が多く、問題個所の詳細構成を把握することができなくなる。一方で、問題個所の詳細構成を把握するために、アプリケーションノードと、それに関連するＶＭノードが離れた状態でズームインすると、アプリケーションノードとＶＭノードを一画面に同時に表示することができなくなる。

本発明は、上記事情に鑑みなされたものであり、その目的は、ノード間の全体構成の視認性の低下を抑制しつつ、詳細構成の関連性の視認性を向上させることが可能な表示情報処理装置、表示情報処理方法および表示情報処理プログラムを提供することにある。

上記目的を達成するため、第１の観点に係る表示情報処理装置は、トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定し、前記指標に基づいて前記ノード間の距離を求め、前記ノード間の距離に基づいて、前記ノードの表示位置を設定する。

本発明によれば、ノード間の全体構成の視認性の低下を抑制しつつ、詳細構成の関連性の視認性を向上させることができる。

図１は、第１実施形態に係る表示情報処理装置で制御される表示画面例を示す図である。 図２は、第１実施形態に係る表示画面のズーム操作時の画面遷移例を示す図である。 図３は、第１実施形態に係る表示情報処理装置が適用されるシステムの構成を示すブロック図である。 図４は、図３のアプリ構成管理テーブルの構成例を示す図である。 図５は、図３のＶＭ構成管理テーブルの構成例を示す図である。 図６は、図３のサーバ構成管理テーブルの構成例を示す図である。 図７は、図３のファブリック構成管理テーブルの構成例を示す図である。 図８は、図３のボリューム管理テーブルの構成例を示す図である。 図９は、図３のストレージ構成管理テーブルの構成例を示す図である。 図１０は、図３のカタログ管理テーブルの構成例を示す図である。 図１１は、図３のノードデータ管理テーブルの構成例を示す図である。 図１２は、図３のリンクデータ管理テーブルの構成例を示す図である。 図１３は、図３の地理クラスタ配置情報管理テーブルの構成例を示す図である。 図１４は、図３のノード配置管理テーブルの構成例を示す図である。 図１５は、図３のインフラ重要度管理テーブルの構成例を示す図である。 図１６は、図３のアプリ重要度管理テーブルの構成例を示す図である。 図１７は、図３の注目度管理テーブルの構成例を示す図である。 図１８は、図３のトポロジデータの構成例を示す図である。 図１９は、トポロジマップの描画処理の概略を示すシーケンス図である。 図２０は、図３のトポロジ生成処理を示すフローチャートである。 図２１は、図３のノード座標計算処理を示すフローチャートである。 図２２は、図３のイベント分析処理を示すフローチャートである。 図２３は、第３実施形態に係る表示情報処理装置で用いられる構成情報例を示す図である。 図２４は、図３の表示情報処理装置のハードウェア構成例を示すブロック図である。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また、実施形態の中で説明されている諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために、「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。さらに、テーブル内の各列の値からなる情報要素を欄またはエントリと呼び、「ａａａテーブル」のエントリを、説明のために、「ａａａテーブルエントリ」と称する。

また、以下の説明では、単に管理計算機及びサーバを主語として処理を説明する場合があるが、これら処理は、計算機が備える制御デバイスが有するプロセッサ（例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されていることを示す。

図１は、第１実施形態に係る表示情報処理装置で制御される表示画面例を示す図である。
図１において、表示情報処理システムは、クライアント１００と、トポロジ構成管理サーバ２００を備える。クライアント１００は、例えば、パーソナルコンピュータなどの端末である。

トポロジ構成管理サーバ２００は、ＩＴシステムを構成するリソース群やアプリケーションの構成情報２０２と、性能等の状態情報２０３を保持し、トポロジ構成を管理する。そして、トポロジ構成管理サーバ２００は、クライアント１００からの要求に応じて、トポロジデータをクライアント１００に送信する。トポロジは、点（ノードとも言う）と線（エッジまたはリンクとも言う）を用いてモデル化された接続形態である。

クライアント１００は、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）１１０を表示する。ここで、クライアント１００は、トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定し、その指標に基づいてノード間の距離を求め、ノード間の距離に基づいて、ノードの表示位置を設定する。エンティティは、例えば、ＩＴシステムに用いられるインフラリソースおよびアプリケーションである。インフラリソースの少なくとも一部は仮想化されていてもよい。このとき、クライアント１００は、トポロジを構成するノードをシンボル化またはアイコン化して表示してもよい。各ノードは、ユーザのクリックなどによって選択可能としてもよい。

また、エンティティ間の関連性に関する指標は、エンティティ間の関連性の大小を反映するように設定することができる。このとき、クライアント１００は、エンティティ間の関連性が大きいときは、それらのエンティティに割り当てられたノードを結線するリンクの長さを小さくして、それらのノードが近接して表示されるようにし、エンティティ間の関連性が小さいときは、それらのエンティティに割り当てられたノードを結線するリンクの長さを大きくして、それらのノードが離れて表示されるようにすることができる。また、第１エンティティが割り当てられた第１ノードと第２エンティティが割り当てられた第２ノードが結線されているときに、第１エンティティから見た第２エンティティの重要度に基づいて、第１エンティティに対する第２エンティティの関連性に関する指標を設定することができる。

ＧＵＩ１１０は、トポロジ表示部１３０と、サーチボックス１４０と、Ｆｅａｔｕｒｅセレクタ１５０を含む。トポロジ表示部１３０は、ＩＴシステムを構成するインフラリソースとアプリケーションの関連を表現するトポロジマップを表示する。ＩＴシステムを構成するインフラリソースは、例えば、ＶＭ、サーバ、ファブリックおよびストレージである。このとき、トポロジマップには、アプリケーションノード１３１と、ＶＭノード１３２と、サーバノード１３３と、ファブリックノード１３４と、ストレージノード１３５と、それら各ノード間のリンクが含まれる。

また、トポロジマップでは、例えば、各ノードは、リソースの種類ごとに画面の同じ高さ（Ｙ座標）に配置されていてよい。このとき、各ノードは、リソースの種類ごとに異なるシンボルで表現してもよい。また、ノードが必要以上に密集しないよう、Ｘ、Ｙ座標ともに各ノードは、一定以上の距離を持って離れている。各ノードは、特定のリソースを表現し、複製はない。そのため、トポロジマップは、多対多のグラフの形式で表現されている。

サーチボックス１４０は、ノード名を入力し、ノードを選択する。Ｆｅａｔｕｒｅセレクタ１５０は、例えば“Ｐｅｒｆｏｒａｍｃｅ”や“Ｃａｐａｃｉｔｙ”等、業務内容または目的に関連して、ユーザがリソースの状態を確認する際の観点を選択する。

各ノードには、リソースの状態を示すマーカ１３６が表示される。マーカ１３６は、Ｆｅａｔｕｒｅセレクタ１５０で選択された観点において、リソースの状態を表示する。例えば、図１の例は、現在のアプリケーションの性能状態を確認するために、Ｆｅａｔｕｒｅセレクタ１５０に“Ｐｅｒｆｏｒｍａｃｅ”の値を設定した場合である。このとき、ＧＵＩ１１０は、性能を計測する指標、例えばレスポンスタイムが異常判定閾値を超えた状態を黒塗りの丸、警告閾値を超えた状態を斜線の丸、正常な状態を白塗りの丸として表現することができる（以降、この３段階の状態をＲＡＧ（Ｒｅｄ，Ａｍｂｅｒ，Ｇｒｅｅｎの各状態の集合の略字）と記す）。なお、表現形式は一例であって、ＧＵＩ１１０は、リソースの状態に応じて、例えば、赤、黄または緑などの色を付してもよい。

ＧＵＩ１１０は、ユーザがクライアント１００にアクセスすると、トポロジマップの初期状態を示した初期画面１３０Ａをトポロジ表示部１３０に表示する。このとき、クライアント１００は、ノード座標計算処理１２２を実行する。ノード座標計算処理１２２は、トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標に基づいて、それらのノード間の距離を求め、それらのノード間の距離に基づいて、初期画面１３０Ａで表示されるノードの表示座標を設定する。

例えば、ノード座標計算処理１２２は、インフラリソースの状態およびインフラリソースにかけられているコストを基に、各アプリケーションが同時に確認される可能性の高いインフラリソースを推定し、当該インフラリソースのより近くにアプリケーションが配置されるようにノードの表示座標を設定する。

図１の例では、トポロジマップは、ＴｏｋｙｏデータセンタとＮｅｗＹｏｒｋデータセンタという地理クラスタの単位でグルーピングしてインフラリソースのノードを表示し、そのインフラリソースに関連するアプリケーションのノードを結線して表示している。ここで、Ｔｏｋｙｏデータセンタでは、例えば、最上位階層には、ＶＭ名がＶＭ１～ＶＭ３という３つのＶＭノード１３２が表示され、ＮｅｗＹｏｒｋデータセンタでは、例えば、最上位階層には、ＶＭ名がＶＭ４～ＶＭ６という３つのＶＭノード１３２が表示されている。ＶＭ名がＶＭ１～ＶＭ６という６つのＶＭノード１３２は、ＴｏｋｙｏデータセンタとＮｅｗＹｏｒｋデータセンタを示す枠内の最も高い位置にＹ座標を揃えてＸ軸に沿って並べて配置されている。

また、アプリ名がＡＰ１というアプリケーションに対し、ＶＭ名がＶＭ１というＶＭと、ＶＭ名がＶＭ５というＶＭが割り当てられ、アプリ名がＡＰ２というアプリケーションに対し、ＶＭ名がＶＭ３というＶＭが割り当てられているものとする。このとき、このトポロジマップでは、アプリ名がＡＰ１というアプリケーションノード１３１が、ＶＭ名がＶＭ１というＶＭノード１３２と、ＶＭ名がＶＭ５というＶＭノード１３２に結線され、アプリ名がＡＰ２というアプリケーションノード１３１が、ＶＭ名がＶＭ３というＶＭノード１３２に結線される。

そして、ＶＭ名がＶＭ１、ＶＭ４～ＶＭ６のＶＭノード１３２には、レスポンスタイムが正常な状態を示す白塗りの丸で表現されたマーカ１３６が付され、ＶＭ名がＶＭ３のＶＭノード１３２には、レスポンスタイムが警告閾値を超えた状態を示す斜線の丸で表現されたマーカ１３６が付され、ＶＭ名がＶＭ２のＶＭノード１３２には、レスポンスタイムが異常判定閾値を超えた状態を示す黒塗りの丸で表現されたマーカ１３６が付されている。

この場合では、ユーザは、ＴｏｋｙｏデータセンタにあるＶＭ名がＶＭ２というＶＭについて、優先度を上げて対応すべきか否かを判断するため、そのＶＭに関連するアプリケーションを見る。そのため、ＮｅｗＹｏｒｋデータセンタにある異常の発生していないＶＭ名がＶＭ５というＶＭに比べ、ＴｏｋｙｏデータセンタにあるＶＭ名がＶＭ２というＶＭの方が、ユーザがアプリケーションと同時に確認しようとする可能性が高い。

ここで、ノード座標計算処理１２２は、各ＶＭのレスポンスタイムを基に、各アプリケーションが同時に確認される可能性の高いＶＭを推定し、当該ＶＭのより近くにアプリケーションが配置されるようにノードの表示座標を設定する。例えば、ノード座標計算処理１２２は、ＶＭ名がＶＭ２、ＶＭ５というＶＭに関連するアプリ名がＡＰ１というアプリケーションについて、そのアプリケーションノード１３１をＶＭ名がＶＭ２のＶＭノード１３２の近くに配置する。

これにより、ユーザは、ＴｏｋｙｏデータセンタとＮｅｗＹｏｒｋデータセンタについて一画面上で異常のあるＶＭを確認することが可能となるとともに、異常のあるＶＭとアプリケーションとの関連性を詳細に確認するために、ユーザがズームイン操作を行った場合においても、ＧＵＩ１１０は、異常のあるＶＭと、そのＶＭに関連するアプリケーションを一画面に含めたまま表示することができる。

また、ＧＵＩ１１０は、ユーザがＶＭノード１３２を選択すると、その選択結果に応じてトポロジマップのアプリケーションノード１３１の位置を変更した変更画面１３０Ｂをトポロジ表示部１３０に表示する。ノードの選択方法は、例えば、マウスによるクリック操作であってもよいし、サーチボックス１４０へのノード名の入力であってもよい。

例えば、現状では異常は無いが異常の発生しているリソースの近傍にあるなどの場合には、ユーザが特定のノードを指定し、状態および構成を確認する場合がある。この場合では、ユーザは、仮にインフラリソースに異常が発生した場合に、影響が波及するアプリケーションを確認する動作をする。

このため、ノード座標計算処理１２２は、ユーザのノードの選択状態も加味し、各アプリケーションから見たインフラリソースの重要度を再計算し、アプリケーションノードの配置を変更する。例えば、ユーザが、ＶＭ名がＶＭ５というＶＭに注目し、ＶＭ５というＶＭ名をサーチボックス１４０に入力したものとする。このとき、ノード座標計算処理１２２は、ノード選択情報１３８に基づいてノード間の距離を求め、ノード間の距離に基づいて、変更画面１３０Ｂで表示されるノードの表示座標を設定する。ＧＵＩ１１０は、ＶＭ名がＶＭ５というＶＭに関連するアプリ名がＡＰ１というアプリケーションについて、そのアプリケーションノード１３１をＶＭ名がＶＭ５のＶＭノード１３２の近くに表示する。

これにより、ユーザは、ＴｏｋｙｏデータセンタとＮｅｗＹｏｒｋデータセンタについて一画面上で異常のあるＶＭに関連するアプリケーションに関連する異常のないＶＭを確認することが可能となるとともに、そのアプリケーションと異常のないＶＭとの関連性を詳細に確認するために、ユーザがズームイン操作を行った場合においても、ＧＵＩ１１０は、そのアプリケーションと異常のないＶＭを一画面に含めたまま表示することができる。

図２は、第１実施形態に係る表示画面のズーム操作時の画面遷移例を示す図である。
図２において、図１のクライアント１００は、ＩＴシステム全体の構成を示すトポロジマップを保持し、トポロジマップの一部をトポロジ表示部１３０に表示する。

ユーザがＧＵＩ１１０にアクセスすると、ＧＵＩ１１０は、表示画面１３０ａをトポロジ表示部１３０に表示する。表示画面１３０ａには、トポロジマップの初期状態であるＩＴシステム全体が表示される。この時、インフラリソースノード群は国の単位でクラスタ化され、トポロジマップ上には国を示す矩形（以下、国などの地理の単位でまとめられた矩形を地理クラスタ、またはまとめられている単位毎にｘｘクラスタ（例：国クラスタ）と呼ぶ。）が表示される。

図２の例では、日本単位およびアメリカ単位でそれぞれまとめられた国クラスタ１６１、１６２が表示範囲Ｈ１Ａに表示され、国クラスタ１６１、１６２に関連するアプリケーションノード１３１が表示されている。

より詳細なインフラ構成を表示するため、ユーザは、例えば、マウスによる上下スクローリング操作や、タッチ操作によるピッチイン操作によって、指定箇所を中心に、トポロジマップをズームイン（拡大）することができる。これにより、トポロジマップ全体に対する表示範囲の幅および高さは小さくなり、ＧＵＩ１１０は、その表示範囲をトポロジ表示部１３０に縮尺を合わせて表示することで、ノードやリンクの画面上の大きさが大きくなる。また、例えば、マウスによるグリッド操作により、ユーザは表示範囲を変更することができる。

表示画面１３０ａにおいて、ユーザが表示範囲Ｈ２Ａについてズームイン操作を行い、トポロジマップの一部を拡大したものとする。このとき、ＧＵＩ１１０は、表示画面１３０ｂをトポロジ表示部１３０に表示する。ここで、国クラスタ１６１、１６２が表示される状態からユーザがズームイン操作を行っていくと、任意のズームの度合い（以降、ズーム率と呼ぶ）に達したタイミングで、国クラスタ１６１、１６２の内部にデータセンタクラスタが表示される。図２の例では、国クラスタ１６１には、Ｏｓａｋａデータセンタ単位でまとめられたＤＣクラスタ１７１と、Ｔｏｋｙｏデータセンタ単位でまとめられたＤＣクラスタ１７２が表示範囲Ｈ１Ｂに表示され、国クラスタ１６２には、ＮｅｗＹｏｒｋデータセンタ単位でまとめられたＤＣクラスタ１７３が表示範囲Ｈ１Ｂに表示され、ＤＣクラスタ１７２、１７３に関連するアプリケーションノード１３１が表示されている。

表示画面１３０ｂにおいて、ユーザが表示範囲Ｈ２Ｂについてズームイン操作を行い、トポロジマップの一部を拡大したものとする。このとき、ＧＵＩ１１０は、表示画面１３０ｃをトポロジ表示部１３０に表示する。図２の例では、ＤＣクラスタ１７２には、サーバノードとＶＭノードがまとめられたサーバクラスタ１８１、１８２とサーバクラスタ１８１、１８２に結線されたファブリックノード１３４と、ファブリックノード１３４に結線されたストレージノード１３５が表示範囲Ｈ１Ｃに表示され、ＤＣクラスタ１７３には、サーバノードとＶＭノードがまとめられたサーバクラスタ１８３とサーバクラスタ１８３に結線されたファブリックノード１３４と、ファブリックノード１３４に結線されたストレージノード１３５が表示範囲Ｈ１Ｃに表示され、サーバクラスタ１８１、１８３に関連するアプリケーションノード１３１が表示されている。

表示画面１３０ｃにおいて、ユーザが表示範囲Ｈ２Ｃについてズームイン操作を行い、トポロジマップの一部を拡大したものとする。このとき、ＧＵＩ１１０は、表示画面１３０ｄをトポロジ表示部１３０に表示する。図２の例では、アプリケーションノード１３１と、ＤＣクラスタ１７２に含まれるＶＭノード１３２と、サーバノード１３３と、ファブリックノード１３４と、ストレージノード１３５が表示範囲Ｈ１Ｄに表示され、ＶＭノード１３２に結線されたアプリケーションノード１３１が表示範囲Ｈ１Ｄに表示されている。

なお、表示画面１３０ａ～１３０ｄには地理クラスタの単位で表示する場合を例示したが、国クラスタおよびＤＣクラスタ以外の単位で表示するようにしてもよい。例えば、国よりも下の単位に市が含まれていてもよい。また、各地理クラスタを表示するズーム率は、各地理クラスタで一定である必要もない。例えば、データセンタまたはサーバクラスタが少ない国と、地理クラスタまたはリソースが多い国がある場合には、後者に比べ前者の構成の複雑さは低いため、クライアント１００は、ズーム度合いがより低い段階で各ノードとリンクを表示してもよい。

図３は、第１実施形態に係る表示情報処理装置が適用されるシステムの構成を示すブロック図である。
図３において、計算機システムは、クライアント１００と、トポロジ構成管理サーバ２００と、ＩＴシステム３００を備える。ＩＴシステム３００は、トポロジマップに表示されるリソース群である管理対象リソース群を備える。このリソース群は、例えば、アプリケーション群３１０、ＶＭ群３２０、サーバ群３３０、ファブリック群３４０およびストレージ群３５０を備える。ＩＴシステム３００は、例えば、ある企業で管理されるデータセンタ群である。これらのデータセンタ群は、世界中の各国に分散配置されていてもよい。

クライアント１００と、トポロジ構成管理サーバ２００と、ＩＴシステム３００は、ネットワーク４００を介して通信する。これらサーバおよびツールは、それぞれがＣＰＵ、メモリおよびハードディスクなどからなる計算機で動作する。その動作形態は、それぞれ物理的に異なる計算機上で動作していてもよいし、仮想サーバと呼ばれる物理的な計算機が論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク（プロセスやコンテナとも呼ばれる）単位で動作してもよい。

クライアント１００は、階層化されたトポロジマップおよび各種の設定値入力セレクタ等を表示するＧＵＩ１１０と、ＧＵＩ１１０にトポロジマップを表示する処理を行う表示処理部１２０を含む。クライアント１００は、ウェブブラウザ上で動作するＷｅｂアプリケーションであってもよいし、独立したデスクトップアプリケーションであってもよい。

表示処理部１２０は、イベント分析処理１２１と、ノード座標計算処理１２２を実行し、それらの処理で用いられるデータを保持する各種テーブルを備える。イベント分析処理１２１は、ユーザのノード選択操作に対応して、ノードの注目度を更新する。ノード座標計算処理１２２は、インフラリソースノードおよびアプリケーションノードの座標を計算する。

このとき、ノード座標計算処理１２２は、各ノードの配置座標の計算時に、例えば、インフラリソースの重要度（以下、インフラ重要度と言うことがある）と、アプリケーションの重要度（以下、アプリ重要度と言うことがある）を計算し、アプリケーションノードとインフラノードとの間の距離をインフラリソースの重要度の逆数で荷重し、より重要なインフラノードの近くにアプリケーションノードが配置されるよう、アプリケーションノードの配置を決める。また、ノード座標計算処理１２２は、アプリケーションの重要度を基に、より重要なアプリケーションがインフラノードの近くに配置されるよう、アプリケーションノードの配置を決める。

このとき、例えば、インフラリソースの重要度は、アプリケーション毎にインフラリソースの状態と、コストを基に計算され、アプリケーションの重要度は、アプリケーションが関連するインフラリソースのコストの合計値から計算される。これにより、リソース数が増加した場合であっても、ユーザは、観点および着目リソースを変えつつＩＴシステム全体の状態を容易に俯瞰し把握することが可能となる。

トポロジ構成管理サーバ２００は、トポロジ生成処理２０１を実行し、ＩＴシステム３００の構成情報およびトポロジマップの構成情報を保持する各種テーブルを備える。トポロジ構成管理サーバ２００は、ＩＴシステム３００の構成情報を収集してトポロジデータを生成し、クライアント１００の要求に応じて、トポロジデータを送信する。

図４は、図３のアプリ構成管理テーブルの構成例を示す図である。
図４において、アプリ構成管理テーブルＴ２００は、アプリケーションの基本情報と、インフラリソースとの関連を保持する。

アプリケーション構成管理テーブルＴ２００は、アプリケーションリソースＩＤ Ｔ２００１、アプリケーション名Ｔ２００２およびＶＭリソースＩＤ Ｔ２００３の情報を含む。アプリケーションリソースＩＤ Ｔ２００１は、アプリケーションを識別するためのＩＤである。ここで、アプリケーションとは、ビジネス部門等のエンドユーザに対してあるサービスを提供する単位であり、例えば、会計業務処理を提供するシステムなどである。その実体は、コンテナ技術を用いていてもよいし、ＦａａＳ（Ｆｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅ）などで構成されていてもよい。ＶＭリソースＩＤ Ｔ２００３は、アプリケーションに関係するＶＭリソースのＩＤである。

アプリケーション構成管理テーブルＴ２００は、図１のＧＵＩ１１０で表示されるアプリケーションノード１３１とＶＭノード１３２の関連性を示す。図４の例では、アプリケーションリソースＩＤが１のアプリケーションにＶＭリソースＩＤが２と５のＶＭが割り当てられ、アプリケーションリソースＩＤが２のアプリケーションにＶＭリソースＩＤが３のＶＭが割り当てられていることを示し、この関係に従って、図１のＡＰ１のアプリケーションノードがＶＭ２とＶＭ５のＶＭノードに結線され、ＡＰ２のアプリケーションノードがＶＭ３のＶＭノードに結線されたトポロジマップが生成される。

図５は、図３のＶＭ構成管理テーブルの構成例を示す図である。
図５において、ＶＭ構成管理テーブルＴ２１０は、ＶＭの基本情報と、各種インフラリソースとの関連を保持する。

ＶＭ構成管理テーブルＴ２１０は、ＶＭリソースＩＤ Ｔ２１０１、ＶＭ名Ｔ２１０２、インスタンスタイプＩＤ Ｔ２１０３、サーバリソースＩＤ Ｔ２１０４、ボリュームリソースＩＤ Ｔ２１０５、国Ｔ２１０６およびデータセンタＴ２１０７の情報を含む。ＶＭリソースＩＤ Ｔ２１０１は、ＶＭを識別するためのＩＤである。インスタンスタイプＩＤ Ｔ２１０３は、ＶＭのスペックおよび価格を示すインスタンスタイプの識別ＩＤである。サーバリソースＩＤ Ｔ２１０４は、ＶＭが動作するサーバリソースを識別するＩＤである。ボリュームリソースＩＤ Ｔ２１０５は、ＶＭに対して割り当てられているストレージボリュームを識別するＩＤである。国Ｔ２１０６とデータセンタＴ２１０７は、ＶＭが稼働する国名とデータセンタ名である。

ＶＭ構成管理テーブルＴ２１０は、図１のＧＵＩ１１０で表示されるＶＭノード１３２とサーバノード１３３の関連性を示す。また、ＶＭ構成管理テーブルＴ２１０は、ＶＭノード１３２とサーバノード１３３がどの地理クラスタに属するかも示す。図５の例では、例えば、図１のＶＭ１～ＶＭ３のＶＭノード１３２がＤＣクラスタ１７２に配置され、ＶＭ４～ＶＭ６のＶＭノード１３２がＤＣクラスタ１７３に配置される。

図６は、図３のサーバ構成管理テーブルの構成例を示す図である。
図６において、サーバ構成管理テーブルＴ２２０は、サーバの基本情報と、各種インフラリソースとの関連を保持する。

サーバ構成管理テーブルＴ２２０は、サーバリソースＩＤ Ｔ２２０１、サーバ名Ｔ２２０２、ファブリックリソースＩＤ Ｔ２２０３、サーバクラスタＴ２２０４、国Ｔ２２０５およびデータセンタＴ２２０６の情報を含む。サーバリソースＩＤ Ｔ２２０１は、サーバを識別するためのＩＤである。ファブリックリソースＩＤ Ｔ２２０３は、サーバが接続されているＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）ファブリックを識別するためのＩＤである。サーバクラスタＴ２２０４は、サーバが属するサーバクラスタの名前であり、国Ｔ２２０５とデータセンタＴ２２０６は、サーバが稼働する国名とデータセンタ名である。

サーバ構成管理テーブルＴ２２０は、図１のＧＵＩ１１０で表示されるサーバノード１３３とファブリックノード１３４の関連性を示す。また、サーバ構成管理テーブルＴ２２０は、サーバノード１３３がどの地理クラスタに属するかも示す。

図７は、図３のファブリック構成管理テーブルの構成例を示す図である。
図７において、ファブリック構成管理テーブルＴ２３０は、ＳＡＮファブリックの基本情報と、各種インフラリソースとの関連を保持する。

ファブリック構成管理テーブルＴ２３０は、ファブリックリソースＩＤ Ｔ２３０１、ファブリック名Ｔ２３０２、国Ｔ２３０３、データセンタＴ２３０４の情報を含む。ファブリックリソースＩＤ Ｔ２３０１は、ＳＡＮファブリックを識別するためのＩＤである。国Ｔ２３０５とデータセンタＴ２３０６は、ＳＡＮファブリックが稼働する国名とデータセンタ名である。ファブリック構成管理テーブルＴ２３０は、ファブリックノード１３４がどの地理クラスタに属するかを示す。

図８は、図３のボリューム管理テーブルの構成例を示す図である。
図８において、ボリューム構成管理テーブルＴ２４０は、ストレージボリュームの基本情報と、各種インフラリソースとの関連を保持する。

ボリューム構成管理テーブルＴ２４０は、ボリュームリソースＩＤ Ｔ２４０１、ボリューム名Ｔ２４０２、インスタンスタイプＩＤ Ｔ２４０３、ストレージリソースＩＤ Ｔ２４０４、国Ｔ２４０５およびデータセンタＴ２４０６の情報を含む。ボリュームリソースＩＤ Ｔ２４０１は、ストレージボリュームを識別するためのＩＤである。インスタンスタイプＩＤ Ｔ２４０３は、ストレージボリュームのスペックや価格を示すインスタンスタイプの識別ＩＤである。ストレージリソースＩＤ Ｔ２４０４は、ストレージボリュームが属するストレージ装置を識別するＩＤである。国Ｔ２４０５とデータセンタＴ２４０６は、ストレージボリュームが稼働する国名とデータセンタ名である。

ボリューム構成管理テーブルＴ２４０は、図１のＧＵＩ１１０で表示されるストレージノード１３５に関連するボリュームを示す。また、ボリューム構成管理テーブルＴ２４０は、ストレージノード１３５に関連するボリュームがどの地理クラスタに属するかも示す。

図９は、図３のストレージ構成管理テーブルの構成例を示す図である。
図９において、ストレージ構成管理テーブルＴ２５０は、ストレージ装置の基本情報と、各種インフラリソースとの関連を保持する。

ストレージ構成管理テーブルＴ２５０は、ストレージリソースＩＤ Ｔ２５０１１、ストレージ名Ｔ２５０２、ファブリックリソースＩＤ Ｔ２５０３、国Ｔ２５０４およびデータセンタＴ２５０５の情報を含む。ストレージリソースＩＤ Ｔ２５０１は、ストレージ装置を識別するためのＩＤである。ファブリックリソースＩＤ Ｔ２５０３は、ストレージ装置が接続するＳＡＮファブリックを識別するＩＤである。国Ｔ２４０５とデータセンタＴ２４０６は、ストレージ装置が稼働する国名とデータセンタ名である。

ストレージ構成管理テーブルＴ２５０は、、図１のＧＵＩ１１０で表示されるストレージノード１３５とファブリックノード１３４との関連性を示す。また、ストレージ構成管理テーブルＴ２５０は、ストレージノード１３５がどの地理クラスタに属するかも示す。

図１０は、図３のカタログ管理テーブルの構成例を示す図である。
図１０において、カタログ管理テーブルＴ２６０は、ＶＭおよびストレージボリュームについて、スペックと、それに対する価格を保持する。

カタログ管理テーブルＴ２６０は、インスタンスタイプＩＤ Ｔ２６０１、インスタンスタイプ名Ｔ２６０２、種類Ｔ２６０３、メモリＴ２６０４、ＣＰＵＴ２６０５、デバイスタイプＴ２６０６および価格Ｔ２６０７の情報を含む。インスタンスタイプＩＤ Ｔ２６０１は、ＶＭおよびストレージボリュームのスペックと価格を示すインスタンスタイプを識別するＩＤである。種類Ｔ２６０３は、ＶＭまたはストレージボリューム等、インスタンスタイプの種類を示す。メモリＴ２６０４とＣＰＵ Ｔ２６０５は、ＶＭのスペックを保持する欄であり、デバイスタイプＴ２６０６は、ストレージボリュームのスペックを保持する欄である。価格Ｔ２６０７は、各スペックに対する価格である。

カタログ管理テーブルＴ２６０で管理される情報は、インフラリソースの重要度の計算に用いることができ、インフラリソースの重要度は、図１のＧＵＩ１１０で表示されるアプリケーションノードとインフラリソースノードの距離の計算に用いることができる。

図１１は、図３のノードデータ管理テーブルの構成例を示す図である。
図１１において、ノードデータ管理テーブルＴ２７０は、トポロジデータのノードの基本情報と、性能などの各種リソースの状態情報を保持する。

ノードデータ管理テーブルＴ２７０は、ノードＩＤ Ｔ２７０１、ノード名Ｔ２７０２、リソースＩＤ Ｔ２７０３、リソース名Ｔ２７０４、リソース種類Ｔ２７０５、応答時間Ｔ２７０６、国Ｔ２７０７およびデータセンタＴ２７０８の情報を含む。ノードＩＤ Ｔ２７０１は、トポロジマップのノードを識別するＩＤであり、ノードデータ管理テーブルＴ２７０でユニークな値である。リソース種類Ｔ２７０５にはリソースの種類を示す値が格納され、リソースＩＤ Ｔ２７０３、リソース名Ｔ２７０４、国Ｔ２７０７およびデータセンタＴ２７０８にはそれぞれ、リソース種別Ｔ２７０５に対応する構成管理テーブルＴ２００～Ｔ２５０に格納されている対応データが格納される。応答時間Ｔ２７０６は、各リソースがストレージアクセスする際のレスポンスタイムが格納される。なお、あるリソースが複数のボリュームまたはストレージアクセス経路を保持している場合には、最悪値が格納される。

ノードデータ管理テーブルＴ２７０で管理される情報は、図１のＧＵＩ１１０で表示されるノードの生成に用いることができる。また、ノードデータ管理テーブルＴ２７０で管理される情報は、インフラリソースの重要度の計算に用いることができ、インフラリソースの重要度は、図１のＧＵＩ１１０で表示されるアプリケーションノードとインフラリソースノードの距離の計算に用いることができる。

図１２は、図３のリンクデータ管理テーブルの構成例を示す図である。
図１２において、リンクデータ管理テーブルＴ２８０は、トポロジマップのノード間の各リンクの情報を保持する。リンクデータ管理テーブルＴ２８０は、リンクの起点ノードのＩＤを保持する欄Ｔ２８０１と、終点ノードのＩＤを保持する欄Ｔ２８０２を保持する。

リンクデータ管理テーブルＴ２８０で管理される情報は、図１のＧＵＩ１１０で表示されるリンクの生成に用いることができる。例えば、ＧＵＩ１１０は、起点ノードＩＤが１０１と終点ノードＩＤが２０２という情報に従って、ＡＰ１のアプリケーションノードとＶＭ２のＶＭノードを結線し、起点ノードＩＤが１０１と終点ノードＩＤが２０５という情報に従って、ＡＰ１のアプリケーションノードとＶＭ５のＶＭノードを結線し、起点ノードＩＤが１０２と終点ノードＩＤが２０３という情報に従って、ＡＰ２のアプリケーションノードとＶＭ３のＶＭノードを結線する。

図１３は、図３の地理クラスタ配置情報管理テーブルの構成例を示す図である。
図１３において、地理クラスタ配置管理テーブルＴ１１０は、ＩＴシステム全体をトポロジにマッピングした際の各地理クラスタの座標および大きさを保持する。地理クラスタ配置管理テーブルＴ１１０は、クラスタ名 Ｔ１１０１、Ｘ座標Ｔ１１０２、Ｙ座標Ｔ１１０３、高さＴ１１０４および幅Ｔ１１０５の情報を含む。各座標の値は、トポロジマップの左上頂点を原点とし、左方向にＸ座標が大きくなり、下方向にＹ座標が大きくなるような座標系の値である。値の単位は限定していない。ピクセルであってもよいし、ミリメートルであってもよい。

図１４は、図３のノード配置管理テーブルの構成例を示す図である。
図１４において、ノード配置管理テーブルＴ１２０は、ＩＴシステム全体をトポロジにマッピングした際の各ノードの座標を保持する。ノード配置管理テーブルＴ１２０は、ノードＩＤ Ｔ１２０１、Ｘ座標Ｔ１２０２およびＹ座標Ｔ１２０３の情報を含む。座標系と単位は、図１３の地理クラスタ配置管理テーブルＴ１１０と同様である。

図１５は、図３のインフラ重要度管理テーブルの構成例を示す図である。
図１５において、インフラ重要度管理テーブルＴ１３０は、各アプリケーションにとっての各インフラリソースの重要度を保持する。ここで、重要度とは、ユーザがトポロジマップを表示した際に、問題が発生しているなど、トポロジマップのうち優先して注目する可能性の高さを示す値である。

インフラ重要度管理テーブルＴ１３０は、ノードＩＤ Ｔ１３０１、関連ノードＩＤ Ｔ１３０２、応答時間Ｔ１３０３、コストＴ１３０４、重要度Ｔ１３０５の情報を含む。ノードＩＤ Ｔ１３０１は、アプリケーションノードのＩＤであり、関連ノードＩＤ Ｔ１３０２は、ノードＩＤ Ｔ１３０１に関連しているインフラノードのＩＤである。なお、本実施形態では、インフラ重要度管理テーブルＴ１３０には、アプリケーションノードに直接関連するＶＭノードのＩＤを格納する。

応答時間Ｔ１３０３は、関連ノードにおけるストレージアクセスの応答時間である。応答時間Ｔ１３０３は、性能観点でのリソースの状態を示し、大きいほど性能問題が発生している可能性が高く、ユーザが着目しやすい。コストＴ１３０４は、関連ノードに対してユーザが支払っているコストである。本実施形態では、ＶＭとボリュームにかかる費用を示す。このコストが高いほど、当該リソースは、ユーザにとって大切なアプリケーションに用いていると考えられる。重要度Ｔ１３０５は、ユーザがトポロジマップで優先して着目する可能性の高さであり、例えば、リソースの状態とリソースのコストから計算される。

図１６は、図３のアプリ重要度管理テーブルの構成例を示す図である。
図１６において、アプリ重要度管理テーブルＴ１４０は、アプリケーションの重要度を保持する。アプリ重要度管理テーブルＴ１４０は、ノードＩＤ Ｔ１４０１、コストＴ１４０２、重要度Ｔ１４０３、国Ｔ１４０４、データセンタＴ１４０５の情報を含む。

ノードＩＤＴ１４０１は、アプリケーションノードのＩＤである。コストＴ１４０２はアプリケーションが関連するインフラリソースの総コストであり、データセンタＴ１４０５毎に保持する。重要度Ｔ１４０３は、コストＴ１４０２の値が大きいほど、大きくなる値である。これは、コストがより多くかけられているアプリケーションほど、ユーザにとって大切であるとの仮定による。

また、アプリケーションが各データセンタに使用リソースを分散させる理由が、各地域からのアクセスに対してレスポンス性能を担保するためであったり、ＤＲ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ）等の可用性の向上のためであると考えられるため、アプリケーションにとって各データセンタのリソースの重要性にばらつきがある。そのため、インフラ視点から見てもデータセンタ毎にアプリケーションの重要度が変わると考えられるため、データセンタ毎に重要度Ｔ１４０３を計算する。

図１７は、図３の注目度管理テーブルの構成例を示す図である。
図１７において、注目度管理テーブルＴ１５０は、トポロジマップの中でユーザが着目している箇所からの距離を示す。注目度管理テーブルＴ１５０は、ノードＩＤ Ｔ１５０１と、注目度Ｔ１５０２の情報を含む。

図３のクライアント１００は、ユーザのノード選択操作に基づき注目度を計算する。ユーザがノードを選択した際には、選択されたノードの注目度Ｔ１５０２には１の値を登録し、その他の各ノードには選択されたノードまでのホップ数で減衰させた値を登録する。例えば、選択されたノードから直接リンクが張られているときに、１ホップで到達するノードでは０．５、２ホップで到達するノードでは０．２５などの値が登録される。

図１８は、図３のトポロジデータの構成例を示す図である。
図１８において、トポロジデータＴ１００は、例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式で記述される。トポロジデータＴ１００は、少なくともノードデータＴ１０１０と、リンクデータＴ１０２０を含む。

ノードデータＴ１０１０は、図１１のノードデータ管理テーブルＴ２７０に含まれるデータと同等であり、例えば、ノード名や、状態のＲＡＧを含む。また、リンクデータＴ１０２０は、図１２のリンクデータ管理テーブルＴ２８０に含まれるデータと同等である。

図１９は、トポロジマップの描画処理の概略を示すシーケンス図である。
図１９において、Ｓ１０００からＳ１０４０は、図１の初期画面１３０ＡがＧＵＩ１１０で表示されるまでの処理の流れを示し、Ｓ１０５０からＳ１０７０は、図１の変更画面１３０ＢがＧＵＩ１１０で表示されるまでの処理の流れを示す。

ユーザ５００がトポロジマップの初期表示をＧＵＩ１１０に指示すると（Ｓ１０００）、ＧＵＩ１１０は、図３の表示処理部１２０に対してトポロジマップの初期表示要求を行う（Ｓ１０１０）。表示処理部１２０は、初期表示要求に応じてトポロジ構成管理サーバ２００に対してトポロジデータを要求する（Ｓ１０２０）。トポロジ構成管理サーバ２００は、トポロジデータの取得要求を受けると、トポロジデータ生成処理２０１を実行し、トポロジデータを生成する。そして、トポロジ構成管理サーバ２００は、生成したトポロジデータを表示処理部１２０に送信する（Ｓ１０３０）。

表示処理部１２０は、受信したトポロジデータについて、ノード座標計算処理１２２を実行し、ＧＵＩ１１０の描画処理を行う（Ｓ１０４０）。

次に、ユーザ５００がノード選択操作を行うと（Ｓ１０５０）、ＧＵＩ１１０は、操作が行われた対象ノードを特定し、表示処理部１２０に対して操作イベントの発生を通知する（Ｓ１０６０）。

表示処理部１２０は、操作イベント発生が通知されると、イベント分析処理１２１を実行し、各ノードの注目度を更新する。次に、表示処理部１２０は、ノード座標計算処理１２２を実行し、更新された注目度に基づいてインフラリソースの重要度を再計算し、再計算したインフラリソースの重要度に基づいて、ノードの座標を再計算する。

次に、表示処理部１２０は、再計算したノードの座標をＧＵＩ１１０に通知し、ＧＵＩ１１０は、再計算されたノードの座標を基にトポロジマップを更新する（Ｓ１０７０）。

図２０は、図３のトポロジ生成処理を示すフローチャートである。
図２０において、トポロジ生成処理２０１は、図３の各構成管理テーブルＴ２００～Ｔ２５０を参照し、ＩＴシステム３００についての各種の構成情報を収集する（Ｓ２０００）。トポロジ生成処理２０１は、任意のタイミング、例えば、決められた時刻で、これらの構成情報をＩＴシステム３００から取得すればよい。また、トポロジ生成処理２０１は、ＩＴシステム３００または他の管理ソフトウェア等を参照し、各リソースの状態情報を収集する。

次に、トポロジ生成処理２０１は、これらの構成情報と状態情報を基に、ＩＴシステム３００に用いられるインフラリソースおよびアプリケーションに関するノード情報を生成し、ノードデータ管理テーブルＴ２７０を更新する（Ｓ２０１０）。

次に、トポロジ生成処理２０１は、これらの構成情報を基に、ノード間を結線するリンク情報を生成し、リンクデータ管理テーブルＴ２８０を更新する（Ｓ２０２０）。トポロジ生成処理２０１は、Ｓ２０１０で更新したノードデータ管理テーブルＴ２７０と、Ｓ２０２０で更新したリンクデータ管理テーブルＴ２８０の値に基づいて、トポロジデータＴ１００を生成し、処理を終了する。

図２１は、図３のノード座標計算処理を示すフローチャートである。
図２１において、ノード座標計算処理１２２は、トポロジデータＴ１００を参照し、インフラノードの座標を計算する（Ｔ３０００）。図２に示したように、本実施形態では、地理クラスタの単位でインフラノードがまとめられ、各インフラノードは、矩形で描画される地理クラスタの内部に表示される。なお、本実施形態では、地理クラスタが表示される画面上の順番は、例えば、アルファベット順である。

インフラノードの座標の計算では、ノード座標計算処理１２２は、グラフ描画アルゴリズムを用いることができる。グラフ描画アルゴリズムは、例えば、杉山フレームワークである。このとき、ノード座標計算処理１２２は、地理クラスの表示領域が重複しないよう、異なる地理クラスタに属するインフラノードが入り混じらないように地理クラスタを配置する。そのため、ノード座標計算処理１２２は、地理クラスタ毎にインフラノードの座標を計算し、個々に計算した地理クラスタ単位でのトポロジを組み合わせて全体のトポロジマップを生成する。

次に、ノード座標計算処理１２２は、各インフラノードが含まれる矩形として、地理クラスタの座標と大きさを計算する（Ｓ３０１０）。

次に、ノード座標計算処理１２２は、アプリケーションノードの配置を計算するために、各インフラリソースとアプリケーションの重要度を推定する。すなわち、表示処理部１２０は、アプリケーション毎に、各アプリケーションが関連するインフラリソースの重要度を計算する（Ｓ３０２０）。

インフラリソースの重要度は、例えば、リソースの状態、コストおよび注目度から求める。リソースの状態を定量的に評価するためのメトリックは、Ｆｅａｔｕｒｅ Ｓｅｌｅｃｔｏｒ１５０で指定されている値毎に異なる。例えば、”Ｐｅｒｆｏｒｍａｎｃｅ”は、性能の状態を示すストレージアクセスの応答時間の日平均値である。コストは、例えば、当該リソースが消費しているコストの日平均などである。注目度は、注目度管理テーブルＴ１５０に格納された値である。

インフラリソースの重要度の計算には、例えば、偏差値を用いる。このとき、リソースの状態とコストのそれぞれのメトリックについて偏差値を計算し、それらの合計と注目度の積を、そのインフラリソースが割り当てられたノードの重要度とする。ノード座標計算処理１２２は、インフラノードの重要度の計算結果をインフラ重要度管理テーブルＴ１３０に格納する。

次に、ノード座標計算処理１２２は、各アプリケーションの重要度を求める（Ｓ３０３０）。アプリケーションの重要度は、各地理クラスタ毎にアプリケーションが関連するインフラリソースの総コストを計算し、これをメトリックとして用いる。アプリケーションの重要度の計算には、例えば、Ｔ３０２０の処理と同様に偏差値を用いることができる。ノード座標計算処理１２２は、アプリケーションの重要度の計算結果をアプリ重要度管理テーブルＴ１４０に格納する。

次に、ノード座標計算処理１２２は、Ｓ３０２０とＳ３０３０で求めた計算結果を用いて、アプリケーションノードの座標を計算する（Ｓ３０４０）。トポロジデータＴ１００に基づくアプリケーションノードの座標の計算では、例えば、杉山フレームワークなどのグラフ描画アルゴリズムを用いることができる。

また、ノード座標計算処理１２２は、各ノードおよびリンクの重要度を変更することで、アプリケーションノードの座標を変更する。例えば、ノード座標計算処理１２２は、各アプリケーションノードが、より重要なインフラノードに近づいて配置されるよう、アプリケーションノードとインフラノード間のリンクの長さに、Ｓ３０２０で求めたインフラリソースの重要度の逆数を掛け、全体がバランスするアプリケーションノードの座標を計算する。また、例えば、ノード座標計算処理１２２は、最も近い地理クラスタのアプリケーションの重要度に基づいてアプリケーションノードの座標を計算する。このとき、ノード座標計算処理１２２は、アプリケーションノードのＹ座標はアプリケーションレイヤとして固定し、アプリケーションノードのＸ座標を変化させることができる。

また、ノード座標計算処理１２２は、アプリケーションノード同士が過度に密集せず、より重要なアプリケーションノードがインフラノードノードの近くに配置されるよう、Ｓ３０３０で求めたアプリケーションの重要度の大きさでアプリケーションを順位付けし、一定距離以上の間隔を開けてインフラノードの近くから順位の高い順にアプリケーションノードを配置する。これにより、ノード座標計算処理１２２は、状態が悪いまたはコストが高いインフラリソースほど、アプリケーションノードの近くに配置されるトポロジマップを生成することができる。

図２２は、図３のイベント分析処理を示すフローチャートである。
図２２において、イベント分析処理１２１は、ユーザが選択したノードを特定すると（Ｓ４０００）、そのノードにリンクが接続されているノード群を特定する（Ｓ４０１０）。

次に、イベント分析処理１２１は、ユーザが最初に選択したノードの注目度を１とし、そのノードから関連ノードまでの辿る際のリンクのホップ数に基づいて、１から値を半減させつつ、注目度として設定する（Ｓ４０２０）。例えば、１ホップで辿れる関連ノードの注目度は０．５、２ホップで辿れる関連ノードの注目度は０．２５とする。

イベント分析処理１２１は、Ｓ４０１０およびＳ４０２０の処理を各ノードに対し、関連ノードが辿れなくなるまで繰り返す（Ｓ４０３０）。イベント分析処理１２１は、以上の処理で求めた注目度に基づいて注目度管理テーブル１５０を更新する。

以下の第２実施形態では、図３のノード座標計算処理１２２が、コストに関する情報、すなわちカタログ管理テーブルＴ２６０に保持する情報を取得できない場合について説明する。このとき、ノード座標計算処理１２２は、コストの情報を用いず、各インフラリソースの構成情報と、稼働率などの状態情報を用いてインフラ重要度と、アプリ重要度を計算する。

第２実施形態に係る計算機システムの構成は、第１実施形態と同様のため図示は省略する。第２実施形態に係る計算機システムでは、ノードデータ管理テーブルＴ２７０には、ＶＭの割り当てメモリ量、割り当てＣＰＵ数、割り当てディスク量およびデバイス種類などの情報もさらに設定する。また、第１実施形態では、ノード座標計算処理１２２は、図２１のＳ３０２０およびＳ３０３０の処理において、コストを基に重要度を計算したが、第２実施形態では、インフラリソースの規模を示すリソース量を基に重要度を計算する。例えば、ＶＭの場合は、リソース量は、メモリ量、ＣＰＵ数およびディスク容量である。アプリケーションの重要度は、そのアプリケーションの関連する少なくとも一部のインフラリソースの割り当て量に基づいて計算する。

以下、ＶＭの場合を例に計算方法を示す。具体的には、ノード座標計算処理１２２は、Ｓ３０２０の処理において、コストの偏差値の代わりに、各リソース毎に割り当て量の偏差値を計算し、それぞれリソースの偏差値の平均をとる。また、ノード座標計算処理１２２は、Ｓ３０３０の処理においても、コストの偏差値の代わりに、各割り当てリソースの偏差値の平均値とする。

これにより、ノード座標計算処理１２２は、割り当てリソース量をコストに変換せずに、インフラリソースの重要度とアプリケーションの重要度を推定することができる。

以下の第３実施形態では、図３のノード座標計算処理１２２が、コストに関する情報、すなわちカタログ管理テーブルＴ２６０に保持する情報および状態に関する情報を取得できない場合について説明する。このとき、ノード座標計算処理１２２は、各インフラリソースの構成情報を用いてインフラ重要度と、アプリ重要度を計算する。

図２３は、第３実施形態に係る表示情報処理装置で用いられる構成情報例を示す図である。
図２３において、第３実施形態に係る計算機システムの構成では、図３の表示処理部１２０は、図３の構成に加え、アプリケーション割り当て数管理テーブルＴ１６０をさらに備える。

アプリケーション割り当て数管理テーブルＴ１６０は、国、データセンタおよびサーバクラスタ毎に、その地理クラスタに含まれるインフラリソースを利用しているアプリケーションの数を保持する。アプリケーション割り当て数管理テーブルＴ１６０が保持する情報は、各地理クラスタへのアプリケーションの偏り具合を示している。アプリケーションが複数の地域のリソースを用いる理由が、応答性能の向上や負荷分散である場合、アプリケーションがより多く偏って配置されている地域は、ビジネス上で重要性が高い地域の可能性が高いと考えられる。

第３実施形態では、ノード座標計算処理１２２は、アプリケーション割り当て数管理テーブルＴ１６０を参照し、インフラリソースを利用しているアプリケーションの数に基づいて、インフラ重要度を計算する。具体的には、図２１のＳ３０２０の処理において、ノード座標計算処理１２２は、計算対象のインフラリソースの所属する国、データセンタの地理クラスタ、およびアプリケーションからインフラリソースにまで辿る際に経由するサーバクラスタについて、アプリケーション割り当て数管理テーブルＴ１６０からアプリケーション数を抽出し、合計する。ノード座標計算処理１２２は、各インフラリソースについて、この合計値を計算し、この合計値の偏差値を求め、この偏差値をインフラ重要度として使用する。

図２４は、図３の表示情報処理装置のハードウェア構成例を示すブロック図である。
図２４において、表示情報処理装置１０は、図１のクライアント１００として用いることができる。表示情報処理装置１０は、プロセッサ１１、通信制御デバイス１２、通信インタフェース１３、主記憶デバイス１４、補助記憶デバイス１５および入出力インタフェース１７を備える。プロセッサ１１、通信制御デバイス１２、通信インタフェース１３、主記憶デバイス１４、補助記憶デバイス１５および入出力インタフェース１７は、内部バス１６を介して相互に接続されている。主記憶デバイス１４および補助記憶デバイス１５は、プロセッサ１１からアクセス可能である。

また、表示情報処理装置１０には、入力装置２０および出力装置２１が設けられている。入力装置２０および出力装置２１は、入出力インタフェース１７を介して内部バス１６に接続されている。入力装置２０は、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置等である。出力装置２１は、例えば、画面表示装置（液晶モニタ、有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、グラフィックカード等）、音声出力装置（スピーカ等）、印字装置等である。

プロセッサ１１は、表示情報処理装置１０全体の動作制御を司るハードウェアである。プロセッサ１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であってもよいし、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であってもよい。プロセッサ１１は、シングルコアロセッサであってもよいし、マルチコアロセッサであってもよい。プロセッサ１１は、処理の一部または全部を行うハードウェア回路（例えば、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ））を備えていてもよい。プロセッサ１１は、ニューラルネットワークを備えていてもよい。

主記憶デバイス１４は、例えば、ＳＲＡＭまたはＤＲＡＭなどの半導体メモリから構成することができる。主記憶デバイス１４には、プロセッサ１１が実行中のプログラムを格納したり、プロセッサ１１がプログラムを実行するためのワークエリアを設けたりすることができる。

補助記憶デバイス１５は、大容量の記憶容量を備える記憶デバイスであり、例えば、ハードディスク装置またはＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。補助記憶デバイス１５は、各種プログラムの実行ファイルやプログラムの実行に用いられるデータを保持することができる。補助記憶デバイス１５には、表示情報処理プログラム１５Ａおよび管理情報１５Ｂを格納することができる。表示情報処理プログラム１５Ａは、表示情報処理装置１０にインストール可能なソフトウェアであってもよいし、表示情報処理装置１０にファームウェアとして組み込まれていてもよい。管理情報１５Ｂは、表示情報処理プログラム１５Ａの処理で用いられるデータであり、図３のクライアント１００が保持する各種テーブルである。

通信制御デバイス１２は、外部との通信を制御する機能を備えるハードウェアである。通信制御デバイス１２は、通信インタフェース１３を介してネットワーク１９に接続される。ネットワーク１９は、インターネットなどのＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷｉＦｉまたはイーサネット（登録商標）などのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷＡＮとＬＡＮが混在していてもよい。

入出力インタフェース１７は、入力装置２０から入力されるデータをプロセッサ１１が処理可能なデータ形式に変換したり、プロセッサ１１から出力されるデータを出力装置２１が処理可能なデータ形式に変換したりする。

プロセッサ１１が表示情報処理プログラム１５Ａを主記憶デバイス１４に読み出し、表示情報処理プログラム１５Ａを実行することにより、トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定し、その指標に基づいて、それらのノード間の距離を求め、それらのノード間の距離に基づいて、ノードの表示位置を設定することができる。

なお、表示情報処理プログラム１５Ａの実行は、複数のプロセッサやコンピュータに分担させてもよい。あるいは、プロセッサ１１は、ネットワーク１９を介してクラウドコンピュータなどに表示情報処理プログラム１５Ａの全部または一部の実行を指示し、その実行結果を受け取るようにしてもよい。

なお、上述した第１、第２および第３実施形態は、組み合わせて用いてもよい。例えば、第１実施形態と第３実施形態を同時に適用し、コストおよび状態情報のインフラ側の情報と、アプリケーション割り当ての偏りのビジネス側の情報を用いることで、より多角的な分析が可能となる。

また、上述した実施形態では、インフラリソースの重要度を計算するために、インフラリソースの構成、インフラリソースの状態、インフラリソースのコスト、インフラリソースの割り当て量、インフラリソースへの注目度およびインフラリソースへのアプリケーションの割り当て数のいずれか少なくとも１つを用いる方法について説明したが、インフラリソースへのアクセス回数などのその他の情報を用いるようにしてもよい。また、アプリケーションの重要度を計算するために、アプリケーションの起動回数などのその他の情報を用いるようにしてもよい。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。

１００ クライアント、２００ トポロジ構成管理サーバ、３００ ＩＴシステム、４００ ネットワーク

Claims (14)

1. トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定し、
   前記指標に基づいて前記ノード間の距離を求め、
   前記ノード間の距離に基づいて、前記ノードの表示位置を設定し、
   前記エンティティは、ＩＴシステムに用いられるインフラリソースおよびアプリケーションである、表示情報処理装置。
2. 前記ノードが割り当てられるエンティティの種類に基づいて、前記ノードの表示位置を階層的に設定する請求項１に記載の表示情報処理装置。
3. 同一階層のノードの表示位置を同一線上に設定し、
   異なる階層のノードの表示位置を互いに異なる線上に設定する請求項２に記載の表示情報処理装置。
4. 前記指標は、前記インフラリソースの重要度および前記アプリケーションの重要度のいずれか少なくとも１つから選択され、
   前記インフラリソースの重要度は、前記インフラリソースの構成、前記インフラリソースの状態、前記インフラリソースのコスト、前記インフラリソースの割り当て量、前記インフラリソースへの注目度および前記インフラリソースへのアプリケーションの割り当て数のいずれか少なくとも１つに基づいて計算され、
   前記アプリケーションの重要度は、前記アプリケーションのコスト、前記アプリケーションの関連するインフラリソースの割り当て量のいずれか少なくとも１つに基づいて計算される請求項１に記載の表示情報処理装置。
5. 前記アプリケーションのノードと前記インフラリソースのノードとの間の距離を、前記インフラリソースの重要度の逆数で荷重し、前記アプリケーションのノードの配置を決める請求項４に記載の表示情報処理装置。
6. 各アプリケーションが関連するインフラリソースのコストの合計値を基に、各アプリケーションの重要度を計算し、複数のアプリケーションのノードが、前記インフラリソースのノードに隣接して配置される場合に、前記重要度の高い方のアプリケーションのノードが、前記インフラリソースのノードにより近くになるように前記アプリケーションのノードの表示位置を設定する請求項４に記載の表示情報処理装置。
7. 前記インフラリソースはＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）であり、前記インフラリソースの状態情報は、ストレージアクセス時のレスポンスタイムである請求項４に記載の表示情報処理装置。
8. 前記インフラリソースのノードを地理クラスタの単位でグルーピングして表示し、
   前記アプリケーションの重要度を前記地理クラスタの単位で計算し、
   最も近い地理クラスタのアプリケーションの重要度に基づいて前記アプリケーションのノードの表示位置を設定する請求項４に記載の表示情報処理装置。
9. 前記地理クラスタは、前記アプリケーションのノードを含まず、前記インフラリソースのノードを含む位置に矩形としてトポロジマップに重ね合わせて表示される請求項８に記載の表示情報処理装置。
10. 前記地理クラスタと、前記トポロジを構成するノードおよびリンクは、ズーム操作に応じて拡大縮小され、前記ズームの度合いに応じて、前記地理クラスタと、前記トポロジを構成するノードおよびリンクの表示の詳細構成が設定される請求項９に記載の表示情報処理装置。
11. 前記ノードの選択操作に基づいて各インフラリソースの注目度を計算し、前記注目度が高いインフラリソースの重要度がより高くなるように前記インフラリソースの重要度を再計算し、再計算した前記インフラリソースの重要度に基づいて、前記アプリケーションのノードの表示位置を再設定する請求項１０に記載の表示情報処理装置。
12. 前記インフラリソースに割り当てられたアプリケーションの数を基に、各インフラリソースの重要度を計算し、前記アプリケーションが割り当てられた数の多い方のインフラリソースのノードに前記アプリケーションのノードがより近くになるように前記アプリケーションのノードの表示位置を設定する請求項４に記載の表示情報処理装置。
13. トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定し、
    前記指標に基づいて前記ノード間の距離を求め、
    前記ノード間の距離に基づいて、前記ノードの表示位置を設定し、
    前記エンティティは、ＩＴシステムに用いられるインフラリソースおよびアプリケーションである、表示情報処理方法。
14. トポロジを構成するノードが割り当てられるエンティティ間の関連性に関する指標を設定する処理と、
    前記指標に基づいて前記ノード間の距離を求める処理と、
    前記ノード間の距離に基づいて、前記ノードの表示位置を設定する処理とをコンピュー
    タに実行させ、
    前記エンティティは、ＩＴシステムに用いられるインフラリソースおよびアプリケーションである、表示情報処理プログラム。

Images