JP7166982B2 - トポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラム - Google Patents

Description

本発明は、トポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラムに関する。

ＩＴシステム管理では、性能障害に対する対応や、ＩＴシステム上で動作するアプリケーションの将来負荷予測に対して、将来負荷に耐えるようシステムリソースへの投資を判断する（キャパシティプランニング）等、多種にわたる管理業務が行われている。

例えば、キャパシティプランニングを行う際には、まずアプリケーションの将来負荷に対して、性能上ボトルネックとなるリソースを探し、次にボトルネックとなるリソースを増強するとしたときに影響を及ぼす可能性がある関連リソースを探す。このように、ＩＴシステム管理を行う上では、着目するリソースを切り替えつつ、システムの構成を俯瞰することが行われる。

また、投資判断のような運営の意思決定を行うためには、性能観点だけでなく、例えばコスト観点やビジネス影響度といった様々な観点からＩＴシステムの状態を把握する必要がある。キャパシティプランニングの例では、ビジネス上影響度が大きいアプリケーションの性能ボトルネックとなりえる箇所と、増設に要するコストが大きく、影響範囲が広い箇所は夫々異なる可能性がある。運営を行うマネージャは、それらを総合した上で迅速に判断を下す必要がある。

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

このようなリソース間の関連をトポロジカルに表示する方式として、ツリー形式とグラフ形式とが知られている。

ツリー形式は、例えばリソース種類Ａ、Ｂのリソース群が多対多の関連を持つとき、この関係性を可視化する際に一方のリソース群のリソースを重複させて木の構造で関連を表現する方法である。グラフ形式は、リソースを重複して表示せず、関連のある各リソース間を線（エッジ）でつなぐ方法である。

グラフ形式の場合は、リソースの重複が無いため表示されるリソースの数が少ない場合には全体の構成を俯瞰しつつ、各々のリソースに着目して個々のリソース間の関連を容易に把握することができる。しかしながら、リソース数が多くなる場合にはエッジの交差が多くなり全体の構成や、個々のリソース間の関連を把握することが難しくなる。

ツリー形式の場合は、エッジの交差が発生しないため、リソース数が増大しても根から葉の方向へ個々のリソース間の関連を辿ることは容易である。しかしながら、表示される木のノード数は重複を含むために、リソース数増加に対して指数的に増加する。そのため、葉に近いリソースに関して、関連する全リソースを根の方向に辿る場合には各重複について調べる必要があり、関連を辿ることが難しくなる。また、同様の理由により、全体の構成を把握する事は難しくなる。

ツリー形式でトポロジ情報を表示するものとして、例えば、特許文献１には、クラウドサービス提供システムに接続するクラウド構成可視化システムであって、クラウド構成表示の要求命令のクラウドＩＤでクラウド接続情報ＤＢからクラウド接続情報を取得し、クラウド接続情報からクラウド構成情報を取得するクラウドサービス提供システムを特定し、特定したクラウドサービス提供システムからクラウド構成情報を取得し、クラウド構成情報に基づいて構成要素毎の構成要素アイコンと接続情報とでクラウド構成図を生成し表示する技術が開示されている。

国際公開第２０１６／１０３４２１号

しかし、特許文献１に開示された技術は、多量のリソースがあった場合について、全体の構成や、全体の中から重大なリソースを容易に把握する点について考慮されていない。

また、特許文献１に開示された技術において、リソース間の関連を辿る方向は固定であり、リソース数が増大したときに多対多の関連を持つリソース群について葉から根の方向へ関連を把握することが難しい。

そのため、特許文献１に開示された技術では、多量のリソースがあった場合に、観点を変えつつＩＴシステム全体を俯瞰して重大なリソースを容易に特定し、それらに関連する着目リソースを変えつつ、全体の状況を容易に把握することが困難である。

本発明は上記の課題に鑑みてなされたもので、リソース数が増加した場合であっても、観点や着目リソースを変えつつＩＴシステム全体の状態を容易に俯瞰、把握することが可能なトポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラムを提供することにある。

上記課題を解決すべく、本発明の一つの観点に従うトポロジマップ提示システムは、相互に関連を有する複数のリソースの構成情報及び状態情報を有する管理サーバと、管理サーバが有する構成情報及び状態情報に基づいて、リソースをノードとし、さらに、リソース間の関連に基づいてノード間を結線したトポロジマップをユーザインタフェース装置に表示させる表示処理装置と、トポロジマップを表示画面に表示するユーザインタフェース装置とを有し、トポロジマップは、ノードをリソースの種類毎に定められた表示画面上の高さに階層表示したものであり、ユーザインタフェース装置は基準となる階層の指定入力を受け入れ、表示処理装置は、指定入力により指定された階層に含まれる少なくとも一つのノードから、このノードに関連するノードが表示画面の上下方向に向かって表示されたトポロジマップを表示画面に表示させる。

本発明によれば、リソース数が増加した場合であっても、観点や着目リソースを変えつつＩＴシステム全体の状態を容易に俯瞰、把握することが可能なトポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラムを実現することができる。

実施形態に係るトポロジマップ提示システムの概要を説明する図である。 実施形態におけるトポロジマップのノード種類や、各ノードの階層関係を示す図である。 実施例に係るトポロジマップ提示システムを示す概略構成図である。 実施例に係るノードデータ管理テーブルの一例を示す図である。 実施例に係るグループノードデータ管理テーブルの一例を示す図である。 実施例に係る階層展開状態管理テーブルの一例を示す図である。 実施例に係るトポロジ設定状態管理テーブルの一例を示す図である。 実施例に係る階層定義テーブルの一例を示す図である。 実施例に係る基準管理テーブルの一例を示す図である。 実施例に係る要求項目管理テーブルの一例を示す図である。 実施例におけるグループノード展開操操作時のトポロジデータの一例を示す図である。 実施例におけるグループノード展開操作後にトポロジ管理サーバにデータを要求する際のトポロジデータの一例を示す図である。 実施例におけるトポロジ管理サーバに追加データを要求する際に送信されるデータの一例を示す図である。 実施例に係るクエリ管理テーブルの一例を示す図である。 実施例に係るツリー描画用ビューテーブルの一例を示す図である。 実施例に係るクエリ実行履歴管理テーブルの一例を示す図である。 実施例に係るツリーデータ管理テーブルの一例を示す図である。 実施例に係るトポロジマップ提示システムの動作の一例を示すシーケンス図である。 実施例に係るトポロジマップ提示システムにおけるイベント分析処理部の動作の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるノード展開変更内容計算処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおける子階層変更内容計算処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおける階層グループ化変更内容計算処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるノードグループ化変更内容計算処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるトポロジ再構成内容計算処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるトポロジデータ生成処理部の動作の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるクエリ生成処理の一例を示すフローチャートである。 実施例に係るトポロジマップ提示システムにおけるトポロジ表示構成計算処理部の動作の一例を示すフローチャートである。 実施例におけるノード展開操作が行われた際のトポロジマップの状態変化の一例を示す図である。

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

また、本明細書において「データ」と記されている場合、その個数についての限定はない。さらに、その形式に限定はない。加えて言えば、いわゆるテーブル形式で記憶媒体に保管、格納されているデータ等もここにいう「データ」である。

＜実施形態の概要＞
図１は、本発明の実施形態に係るトポロジマップ提示システムの概要を説明する図である。

図１を用いて、本実施形態の概要を説明する。本実施形態のトポロジマップ提示システムは、表示画面１１５を表示するクライアント１００と、ＩＴシステムを構成するリソース群やアプリケーション、アプリケーションを利用してビジネスを推進するビジネスユニット（ＢＵ）等の構成情報と、性能等の状態情報を保持し、トポロジ構成を管理するトポロジ構成管理サーバ２００とを有する。

表示画面１１５は、トポロジマップを表示するトポロジ表示部１３０、トポロジマップの表示設定を入力するフィルタ入力部１４０、Ｆｅａｔｕｒｅセレクタ１５０、及びＶｉｅｗセレクタ１６０を有する。

フィルタ入力部１４０には、トポロジマップに含まれるノード名が入力される。フィルタ入力部１４０にノード名が入力されると、入力されたノードに直接に、また別のノードを介して間接的に関連するノード群からなるトポロジとなるようにフィルタが設定される。

Ｆｅａｔｕｒｅセレクタ１５０は、例えば"Ｐｅｒｆｏｒａｍｃｅ Ｃａｐａｃｉｔｙ"や"Ｃｏｓｔ"等、業務内容、目的に関連してユーザがリソースの状態を確認する際の観点（Ｆｅａｔｕｒｅ）を選択するセレクタである。

Ｖｉｅｗセレクタ１６０は、例えば"Ａｐｐｌｉｃａｔｉｏｎ"や"Ｓｔｏｒａｇｅ"等、ユーザが特に着目して詳細を確認したいリソースであり、関連を辿る際に起点となるリソースの種類を選択するセレクタである。

トポロジ表示部１３０には、ＩＴシステムを構成するリソースやアプリケーションの関連を表現するトポロジマップが表示される。本実施例のトポロジマップ提示システムは、トポロジマップの一例としてツリー形式のトポロジマップを提示する。

例えば、図１内の表示画面（操作前）１１５ａは、ＢＵからストレージまでの各リソースをノードとするツリーを表示している。また、表示画面（操作後）１１５ｂは、Ｖｉｅｗセレクタの設定値を"Ｓｔｏｒａｇｅ"に変更する操作を行った後のツリーを表示している。ツリーを構成するノードは一個のリソース、または複数個のリソースのグループを表現している。トポロジマップを構成するノードの詳細については図２を用いて後述する。

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

表示画面（操作前）１１５ａでは、Ｖｉｅｗセレクタ１６０には"Ａｐｐｌｉｃａｔｉｏｎ"が設定されているため、各アプリケーションのノードから上下の階層に向かって関連するリソースが辿られ、ツリーが構築されている。例えば、ＧＵＩ（操作前）１１５aでは、"Ａｐｐ１"は"ＶＭ１"と"ＶＭ２"に、"ＶＭ１"は"Ｃｌｕｓｔｅｒ１"に、"Ｃｌｕｓｔｅｒ１"は"Ｆａｂｒｉｃ１"に関連することが表現されている。

"Ｆａｂｒｉｃ１"ノードは"Ｃｌｕｓｔｅｒ１"と"Ｃｌｕｓｔｅｒ２"の両方に関連するが、関連を辿る方向が"Ａｐｐｌｉｃａｔｉｏｎ"から上下への方向であるため、"Ｃｌｕｓｔｅｒ１"と"Ｃｌｕｓｔｅｒ２"の下方に重複して表示されている。そのため、性能に関して異常がみられる"Ａｐｐ１"について、エッジを辿ることで関連するリソースを辿り、マーカーの状態を確認することで各リソースの性能観点での状態を把握することができる。例えば、"Ａｐｐ１"に対して同時に関連する"Ｓｔｏｒａｇｅ２"の性能も異常状態であり、"Ａｐｐ１"の性能低下の原因と推定することができる。

仮に"Ｓｔｏｒａｇｅ２"に実際に問題が発生していた場合、次にユーザは影響の波及する範囲を確認するが、図１ではそのためにＶｉｅｗセレクタ１６０で"Ｓｔｏｒａｇｅ"を選択し、フィルタ入力部１４０に"Ｓｔｏｒａｇｅ２"を入力する操作を行った場合について例示している。表示画面（操作後）１１５ｂでは、Ｖｉｅｗセレクタ１６０に"Ｓｔｏｒａｇｅ"が設定されているため、"Ｓｔｏｒａｇｅ２"のノードから上下の階層に向かって関連するリソースが辿られるように、ツリーが再構築されている。これにより、"Ａｐｐ３"も警告閾値超過の状態であることが分かる。

表示画面（操作前）１１５ａの表示状態から表示画面（操作後）１１５ｂの表示状態へ変更するためには、表示画面（操作前）１１５ａに表示されていないノードに関するデータを取得する必要がある。そのため、クライアント１００は、操作に応じてトポロジを再構築するために必要なデータを計算し、トポロジ構成管理サーバ２００にデータを要求する。トポロジ構成管理サーバ２００はデータ取得要求を受け取り、対応するデータを抽出し、クライアント１００に送信する。クライアント１００は、受信したデータを元にトポロジを再描画する。

しかしながら、大量のリソースが存在した場合、データアクセスに要する処理時間が長時間化し、表示画面の再描画に長時間かかる問題や、表示画面に大量のノードが表示されてしまうために各ノードの状態を把握しづらくなる問題が発生する。そこで、トポロジ構成管理サーバ２００は、トポロジの構造や、操作内容、画面上に表示されている領域等の情報をもとに、取得するデータ量や処理時間の異なる複数のデータ取得クエリを生成し、目標時間内に可能な限り表示画面上の情報量が多くなるデータを取得する。

また、クライアント１００は、トポロジ構成管理サーバ２００から受信したデータから各ノードの表示画面上の座標を計算し、Ｆｅａｔｕｒｅセレクタ１５０で設定されている観点に関して重大度の高いノードが優先して表示されるよう、ノードの表示順序や、重大度の低いノードのグルーピング範囲を設定する。これにより、リソース数が多い環境であっても、現実的な処理時間でＩＴシステム全体の構造を示すトポロジ全体を表示しつつ、着目すべき重大度の高いノードを容易に把握することが可能となる。

図２は、本実施形態におけるトポロジマップのノード種類や、各ノードの階層関係を示した図である。

図２においてレベルＣ１３５３に示すノード群は、個々のリソースを表現するノードであり、最も粒度の細かい単位のノードである。Ｃｏｕｎｔｒｙ１３３１、Ｃｉｔｙ１３３２、ＤＣ１３３３は、それぞれ直下のＡｐｐｌｉｃａｔｉｏｎ１３３５が動作する国、都市、データセンタを表現している。ＢＵ１３３４はビジネスを推進する各組織（Ｂｕｓｉｎｅｓｓ Ｕｎｉｔ）を、Ａｐｐｌｉｃａｔｉｏｎ１３３５はアプリケーションの実体であるソフトウェアを、ＶＭ Ｇｒｏｕｐ１３３６はＶＭ（Ｖｉｒｔｕａｌ Ｍａｔｃｈｉｎｅ）群を、Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒ１３３７は物理サーバ群を、Ｆａｂｒｉｃ１３３８はＦＣ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ）等のＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を構成する物理スイッチ群を、Ｓｔｏｒａｇｅ１３４０はストレージ装置を表現している。また、Ｔｉｅｒ１３３９はストレージが提供するボリュームの性能をクラス分けする、サービスクラスを表現している。具体的には、"Ｇｏｌｄ Ｔｉｅｒ"＝最大１０，０００ＩＯＰＳが保証される等、ボリュームに関するＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ：サービス水準合意）が定義されたものであり、Ｔｉｅｒ１３３９は実際には特定のＳＬＡを約束しているボリューム群に相当する。

図２においてレベルＢ１３５２に示すノード群は、レベルＣ１３５３に示す各リソースに関して、それぞれ同一のリソース種類の複数ノードをグルーピングした場合のノードを表現している。実施形態におけるトポロジマップでは、これらレベルＢ１３５２に示されるノードは、レベルＣ１３５３に示される対応するリソース種類のノードと、表示画面上で同じ高さ（「階層」）に表示される。また、便宜上、以降の説明では、階層の名前として当該階層に含まれるリソース種類に対応するレベルＣ１３５３に示す各ノードの名前（"Ａｐｐｌｉｃａｔｉｏｎ"、"Ｃｉｔｙ"等）を用いる。

図２においてレベルＡ１３５１に示すノード群は、複数のリソース種類にわたり、レベルＢ及びレベルＣに属するノード集合をグルーピングしたノードを表現している。Ｌｏｃａｔｉｏｎｓ１３０１は、位置に関する情報を表現するＣｏｕｎｔｒｙ階層、Ｃｉｔｙ階層、ＤＣ階層のノード群をグルーピングしたノードである。ＢＵｓ ＆ Ａｐｐｌｉｃａｔｉｏｎｓ１３５２は、ビジネス上の関心がもたれる単位であるＢＵ階層、Ａｐｐｌｉｃａｔｉｏｎ階層のノード群をグルーピングしたノードである。ＩＴ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ１３５３は、ＩＴインフラを構成するリソースであるＶＭ Ｇｒｏｕｐ階層、Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒ階層、Ｆａｂｒｉｃ階層、Ｔｉｅｒ階層、Ｓｔｏｒａｇｅ階層のノード群をグルーピングしたノードである。便宜上、以降の説明ではレベルＡ１３５１、レベルＢ１３５２に示すような複数のノード群をグルーピングしたノードのことを、グループノードと呼ぶ。

レベルＡ１３５１に示すノード群は階層単位でのグルーピングであるため、レベルＡ１３５１に示すノード群が表示されている場合には、レベルＢ１３５２、レベルＣ１３５３に示す対応するノード群は表示されない。そのため、レベルＡ１３５１に示されるノードが表示されている場合には、当該ノードの名前を階層名として表示する。

既に説明したように、本実施例のトポロジマップ提示システムが提示するトポロジマップでは、ノード毎にリソースの状態を示すマーカーが表示される。グループノードの状態としては、例えばグループ内のノードの平均値や最悪値をもとに計算した状態である。これら計算の方法は、Ｆｅａｔｕｒｅやリソースの種類によって可変であってもよい。

また、図２に示したリソース間の接続関係は一例であって、形態を限定するものではない。例えば、アプリケーションがＶＭ上でなく、直接サーバ上で実行されている場合にはＡｐｐｌｉｃａｔｉｏｎ１３３５とＳｅｒｖｅｒ Ｃｌｕｓｔｅｒ１３３７が直接接続されるなど、階層が飛ばされる場合があってもよい。また、アプリケーションがコンテナやサーバレスサービス、ＳａａＳサービス、ＰａａＳサービスの組み合わせで構成されている場合もある。例えばこの場合には、コンテナや、パブリッククラウドサービスを表現するノードが、図２に示したノードと組み合わされて表示されても良い。

＜実施形態のトポロジマップ提示システムの構成＞
図３は、本発明の実施例に係るトポロジマップ提示システムを示す概略構成図である。
本実施例のトポロジマップ提示システム１は、クライアント１００とトポロジ構成管理サーバ２００とを有する。トポロジマップ提示システム１を構成するクライアント１００及びトポロジ構成管理サーバ２００は、トポロジマップに表示するリソース群である管理対象リソース群３００とネットワーク４００を介して通信する。

本実施例のトポロジマップ提示システム１を構成するクライアント１００及びトポロジ構成管理サーバ２００は、情報処理機能を有する物理資源（ハードウェア）、好ましくは計算機で動作する。計算機は、好ましくは演算素子、記憶媒体、入出力機器、通信機器等を有する。

演算素子は、例えば、各種情報処理が可能なＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等である。また、記憶媒体は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの磁気記憶媒体、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの半導体記憶媒体等を有する。また、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等の光ディスク及び光ディスクドライブの組み合わせも記憶媒体として用いられる。その他、磁気テープメディアなどの公知の記憶媒体も記憶媒体として用いられる。

記憶媒体にはデータやプログラムが格納されている。演算素子は、トポロジマップ提示システム１の動作開始時（例えばクライアント１００やトポロジ構成管理サーバ２００の電源投入時）に記憶媒体に格納されているファームウェア等のプログラムをこの記憶媒体から読み出して実行し、計算機をクライアント１００及びトポロジ構成管理サーバ２００として機能させて全体制御を行う。

クライアント１００及びトポロジ構成管理サーバ２００はそれぞれ物理的に異なる計算機上で動作していてもよいし、仮想サーバと呼ばれる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク（プロセスやコンテナとも呼ばれる）単位であってもよい。

クライアント１００は、トポロジマップや各種の設定値入力セレクタ等を表示するユーザインタフェース部（ユーザインタフェース装置、以下、「ＵＩ部」と省略して説明する）１１０と、ＵＩ部１１０にトポロジマップを表示するための処理を行う表示処理部（表示処理装置）１２０とを有する。クライアント１００はウェブブラウザ上で動作するＷｅｂアプリケーションであってもよいし、独立したデスクトップアプリケーションであってもよい。

表示処理部１２０は、イベント分析処理部１２１と、トポロジ表示構成計算処理部１２２と、それらの処理で用いられるノードデータ管理テーブルＴ１００と、グループノードデータ管理テーブルＴ１１０と、階層展開状態管理テーブルＴ１２０と、トポロジ設定状態管理テーブルＴ１３０と、ノード状態変化定義テーブルＴ１４０と、階層定義テーブルＴ１５０と、基準管理テーブルＴ１６０と、要求項目管理テーブルＴ１７０と、トポロジデータＴ１８０とを有する。

イベント分析処理部１２１は、ＵＩ部１１０が受け入れた入力に基づいて、トポロジマップの構造の変化の内容とトポロジ構成管理サーバ２００に送出するデータ取得要求とを特定する。言い換えれば、イベント分析処理部１２１は、ユーザのトポロジ操作イベントに対応して、トポロジマップの構造の変化の内容と、その変化のために追加で取得するデータを特定する。

トポロジ表示構成計算処理部１２２は、トポロジ構成管理サーバ２００から送出されたデータに基づいてグループ化の範囲及び表示画面１１５の表示領域におけるノードの表示位置を算出する。言い換えれば、トポロジ表示構成計算処理部１２２は、トポロジ構成管理サーバ２００から取得したデータを元に、実際に表示するノードのグルーピングの範囲や、ノードの座標等を計算する。

トポロジ構成管理サーバ２００は、クライアント１００からのデータ取得要求に対して実際に取得するデータを決定する処理を行うトポロジデータ生成処理部２０１と、その際に用いられるクエリ管理テーブルＴ２００と、リソースデータ管理テーブルＴ２１０と、基準管理テーブルＴ２２０と、クエリ実行履歴管理テーブルＴ２３０と、トポロジデータ管理テーブルＴ２４０とを有する。このうち、基準管理テーブルＴ２２０の内容は、クライアント１００の表示処理部１２０が有する基準管理テーブルＴ１６０と同じであるため、その説明を省略する。

本実施例のトポロジマップ提示システム１では、クライアント１００はトポロジマップを表示するためのデータは永続的には保持せず、トポロジ構成管理サーバ２００が中央集権的に管理する。そのため、トポロジ構成管理サーバ２００は、クライアント１００に対してなされた操作内容や、表示しているトポロジマップの構造のデータも保持している。従って、トポロジ構成管理サーバ２００がそれらのデータをクライアント１００に渡すことで、クライアント１００が初期化を行った場合であっても継続してトポロジマップを表示することができる。また、クライアントがＷｅｂブラウザで実現されている場合等、複数のクライアントが存在する場合もあるため、トポロジ構成管理サーバ２００は、それぞれのクライアントの状態をセッション情報として保持する。

図４は、本実施例に係るノードデータ管理テーブルＴ１００の一例を示す図である。

ノードデータ管理テーブルＴ１００は、トポロジマップを構成するノードについて、ノード間の関連情報や、ノードが対応するリソースの性能等の状態情報を保持するテーブルである。

ノードデータ管理テーブルＴ１００は、セッションＩＤＴ１００１と、ノードＩＤＴ１００２と、ノード名Ｔ１００３と、関連ノードＩＤＴ１００４と、グループフラグＴ１００５と、リソースＩＤＴ１００６と、リソース名Ｔ１００７と、リソース種類Ｔ１００８と、各種の状態情報を含む欄とを有する。

セッションＩＤＴ１００１は、複数のクライアント１００やユーザがトポロジ構成管理サーバ２００にトポロジ情報を要求した際に、各クライアント１００やユーザ毎にトポロジの状態を区別して保持するためのＩＤである。

ノードＩＤＴ１００２はノードを識別するためのＩＤであり、ノード名Ｔ１００３はＵＩ部１１０に表示されるノードの名前である。関連ノードＩＤＴ１００４は、ＵＩ部１１０上で当該ノードの下方向に接続されるノードのＩＤを保持する。グループフラグＴ１００５は、当該ノードがグループノードであるか、否かを保持する欄である。

リソースＩＤＴ１００６は、ノードが対応するリソースのＩＤであり、後述するリソースデータ管理テーブルＴ２１０のリソースＩＤＴ２１０１に対応する。また、当該ノードがグループの場合は対応するリソースが無いことを示す'－'が格納される。リソース種類Ｔ１００８は、リソースの種類を表す情報を保持する欄であり、図２に示すレベルＣ１３５３の階層名に対応する。

応答時間Ｔ１００９からＭｅｍｏｒｙ（ＧＢ）Ｔ１０１８までは、ノードが対応するリソースの性能等の状態情報の例である。応答時間Ｔ１００９はアプリケーションのＡＰＩ応答時間であり、利益Ｔ１０１０は当該アプリケーションが寄与する利益である。ＣＰＵ％（Ｎｏｗ）Ｔ１０１１、Ｍｅｍｏｒｙ％（Ｎｏｗ）Ｔ１０１２は、現時点でのＣＰＵ使用率とメモリ使用率である。

ＣＰＵ％（６ Ｍｏｎｔｈ Ａｆｔｅｒ）Ｔ１０１３、Ｍｅｍｏｒｙ％（６ Ｍｏｎｔｈ Ａｆｔｅｒ）Ｔ１０１４は、６か月後でのＣＰＵ使用率とメモリ使用率の予測である。

閾値超過継続時間（６ Ｍｏｎｔｈ Ａｇｏ）Ｔ１０１５は、ＣＰＵ使用率、メモリ使用率等の性能値予測が、異常判定閾値を超過してからの６か月後時点での経過時間である。閾値超過残時間Ｔ１０１６は、ＣＰＵ使用率、メモリ使用率等の性能値が異常判定閾値を超過するまでの予測残時間である。

ＣＰＵ（ＧＨｚ）Ｔ１０１７、Ｍｅｍｏｒｙ（ＧＢ）Ｔ１１１７はそれぞれ、ＶＭ ＧｒｏｕｐやＳｅｒｖｅｒ Ｃｌｕｓｔｅｒに割り当てられているＣＰＵリソース、メモリリソースの総量である。

これらの状態情報は一例であって、これら以外の情報が含まれていてもよい。また、本実施例で示した６か月という時点は、将来の予測情報の一例であってそれ以外の時点の情報が含まれていても良い。予測値の計算は、過去のデータを学習し、回帰分析を行う既知の機械学習アルゴリズムを用いればよい。

図５は、本実施例に係るグループノードデータ管理テーブルＴ１１０の一例を示す図である。

グループノードデータ管理テーブルＴ１１０は、グループノードの構成等の情報を保持するテーブルである。

グループノードデータ管理テーブルＴ１１０は、セッションＩＤＴ１１０１と、ノードＩＤＴ１１０２と、メンバノードＩＤＴ１１０３と、条件Ｔ１１０４と、全部取得済みフラグＴ１１０５とを有する。

セッションＩＤＴ１１０１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。ノードＩＤＴ１１０２はグループノードのＩＤであり、メンバノードＩＤＴ１１０３はグループに含まれるノードのＩＤである。これらのＩＤは、ノードデータ管理テーブルＴ１００のノードＩＤＴ１００２欄に対応する。

条件Ｔ１１０４は、グルーピングの条件を保持する欄である。図５に示す例では、ＳＱＬ類似の表現で条件式の集合を示している。例えば、"Ｓｅｌｅｃｔ Ａｐｐｌｉｃａｔｉｏｎ"で、リソース種類がＡｐｐｌｉｃａｔｉｏｎであるノード集合であることを、"Ｗｈｅｒｅ ノード名＝Ｇｒｏｕｐ１"で、ノード名が"Ｇｒｏｕｐ１"のノードへの関連が関連ノードＩＤＴ１００４に含まれるノード集合であることを、"Ｏｒｄｅｒｅｄ ｂｙ ［Ｐｅｒｆｏｒｍａｎｃｅ］"で、Ｆｅａｔｕｒｅが"Ｐｅｒｆｏｒｍａｎｃｅ"であるときの基準で整列することを、"Ｏｆｆｓｅｔ ３"で整列後３番目以降のノードの集合であることを示している。

全部取得済みフラグＴ１１０５は、条件Ｔ１１０４に合致するリソースの情報を全てトポロジ構成管理サーバ２００から取得しているか否かを示すフラグである。

図６は、本実施例に係る階層展開状態管理テーブルＴ１２０の一例を示す図である。

階層展開状態管理テーブルＴ１２０は、トポロジマップのノードの階層について、当該階層の単位でグルーピングされているか否かの状態を管理するテーブルである。

階層展開状態管理テーブルＴ１２０は、セッションＩＤＴ１２０１と、階層Ｔ１２０２と、状態Ｔ１２０３とを有する。

セッションＩＤＴ１２０１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。階層Ｔ１２０２はＵＩ部１１０に表示されうる階層の名前（本実施例では図２に示すレベルＡ１３５１とレベルＣ１３５３のノード名）である。また、状態Ｔ１２０３には、階層単位でグループ化されておらず、階層に属す各ノードが表示されている状態（"Ｏｐｅｎ"）、階層単位でグループ化されているか、もしくは複数階層がまとめてグループ化されている状態（"Ｃｌｏｓｅ"）の値が格納される。

図７は、本実施例に係るトポロジ設定状態管理テーブルＴ１３０の一例を示す図である。

トポロジ設定状態管理テーブルＴ１３０は、トポロジマップの設定値（フィルタ、Ｖｉｅｗ、Ｆｅａｔｕｒｅ）の値を保持するテーブルである。

トポロジ設定状態管理テーブルＴ１３０は、セッションＩＤＴ１３０１と、Ｖｉｅｗ階層名Ｔ１３０２と、ＦｅａｔｕｒｅＴ１３０３と、フィルタＴ１３０４とを有する。

セッションＩＤＴ１２０１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。Ｖｉｅｗ階層名Ｔ１３０２の値は、階層定義テーブルＴ１５０の階層名Ｔ１５０１欄の値に対応し、ＦｅａｔｕｒｅＴ１３０３の値は、基準管理テーブルＴ１６０のＦｅａｔｕｒｅＴ１６０１欄の値に対応する。また、フィルタＴ１３０４の値は、ノードデータ管理テーブルＴ１００のノード名Ｔ１００３の値に対応する。

図８は、本実施例に係る階層定義テーブルＴ１５０の一例を示す図である。

階層定義テーブルＴ１５０は、ＵＩ部１１０上での階層間の順序や、階層に含まれるノードの情報を保持するテーブルであり、トポロジマップをＵＩ部１１０に表示する際に各階層とノードの表示位置を計算するために用いる。

階層定義テーブルＴ１５０は、階層名Ｔ１５０１と、上位階層Ｔ１５０２と、下位階層Ｔ１５０３と、所属ノード種類Ｔ１５０４とを有する。

上位階層Ｔ１５０２は、ＵＩ部１１０において階層名Ｔ１５０１に示す当該階層の上部位置に表示される階層であり、下位階層Ｔ１５０３はＵＩ部１１０において階層名Ｔ１５０１に示す当該階層の下部位置に表示される階層である。

所属ノード種類Ｔ１５０４は、グルーピングした際に階層名Ｔ１５０１に示す当該階層に属するノードの種類を示す。例えば、Ｌｏｃａｔｉｏｎｓ階層については、Ｌｏｃａｔｉｏｎｓ、Ｃｏｕｎｔｒｉｅｓ、Ｃｏｕｎｔｒｙ、Ｃｉｔｉｅｓ、Ｃｉｔｙ、ＤＣｓ、ＤＣのノード種類が格納される。

このうち、図２に示すレベルＡ１３５１の階層、例えばＬｏｃａｔｉｏｎｓ階層が表示される場合、階層展開状態管理テーブルＴ１２０の当該行について、状態Ｔ１２０３欄が"Ｃｌｏｓｅ"であるので、Ｃｏｕｎｔｒｙ階層、Ｃｉｔｙ階層、ＤＣ階層は表示されない。従って、ＵＩ部１１０にノードを表示するためにノード位置を計算する際には、Ｌｏｃａｔｉｏｎｓのノード種類しか使用されないが、逆にＣｉｔｙのノードを選択し、Ｌｏｃａｔｉｏｎｓ階層の単位でノードをグルーピングする際には所属ノード種類Ｔ１５０４の情報を用いて、グルーピング範囲のノード種類が決定される。

図９は、本実施例に係る基準管理テーブルＴ１６０の一例を示す図である。

基準管理テーブルＴ１６０は、ＦｅａｔｕｒｅやＶｉｅｗの値毎に、各リソース種類のノードの重大度を計算する際に選択されるメトリックを保持しておくテーブルである。

基準管理テーブルＴ１６０は、ＦｅａｔｕｒｅＴ１６０１と、ＶｉｅｗＴ１６０２と、リソース種類Ｔ１６０３と、メトリックＴ１６０４とを有する。

ＦｅａｔｕｒｅＴ１６０１は、Ｆｅａｔｕｒｅ Ｓｅｌｅｃｔｏｒ１５０に設定されうるＦｅａｔｕｒｅの値であり、ＶｉｅｗＴ１６０２は、Ｖｉｅｗ Ｓｅｌｅｃｔｏｒ１６０に設定されうる階層名である。

図９に示す例では、将来時点で性能が異常判定閾値を下回るように性能観点でのキャパシティプランニングを行う場合（"Ｐｅｒｆｏｒｍａｎｃｅ Ｃａｐａｃｉｔｙ Ｐｌａｎｎｉｎｇ"）を示している。この時、Ｖｉｅｗが"Ａｐｐｌｉｃａｔｉｏｎ"の場合に、管理者がトポロジマップでアプリケーションに関連するＩＴインフラを確認する目的としては、将来時点でアプリケーションの性能（応答時間）が異常判定閾値を超過する場合に、その原因となるＩＴインフラを特定することにある。

そのため、Ｖｉｅｗが"Ａｐｐｌｉｃａｔｉｏｎ"の場合に、リソース種類Ｔ１６０３がＳｅｒｖｅｒ Ｃｌｕｓｔｅｒの場合には、メトリックＴ１６０４には当該Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒが異常判定閾値を超過してからの経過時間が指定されている。

一方で、Ｖｉｅｗが"Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒ"の場合には、管理者はアプリケーションを安定的に運用するため、Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒの性能が枯渇するリスクを最小化することがトポロジマップを表示する目的となる。そのため、メトリックＴ１６０４には異常判定閾値を超過するまでの残時間が指定されている。

また、増強を行う場合には既存のＣＰＵやメモリ等のリソース量によって、追加する必要のあるリソース量が変化し、費用に影響するため、メトリックＴ１６０４にはＣＰＵ、メモリのリソース量も指定されている。例えば、これらの基準は上部に指定される異常判定閾値超過残時間でソート後、第二ソートキーとしてＣＰＵ、メモリのリソース量でソートするなどすればよい。

図１０は、本実施例に係る要求項目管理テーブルＴ１７０の一例を示す図である。

要求項目管理テーブルＴ１７０は、トポロジマップに対してユーザが操作を行った際に、トポロジマップの表示を変化させるためにトポロジ構成管理サーバ２００に要求する必要があるデータ取得項目を保持するテーブルである。要求項目管理テーブルＴ１７０は、リソースデータ管理テーブルＴ２１０からデータを取得する際に、取得するデータを限定するための情報を保持する。

要求項目管理テーブルＴ１７０は、セッションＩＤＴ１７０１と、要求項目ＩＤＴ１７０２と、対象データＴ１７０３と、階層Ｔ１７０４と、制約条件Ｔ１７０５と、個数Ｔ１７０６と、整列順序Ｔ１７０７とを有する。

セッションＩＤＴ７１０１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。要求項目ＩＤＴ１７０２は、一つのデータ取得クエリでデータベースからデータを取得できるような、ひとまとまりのデータを取得する要求の識別ＩＤである。

対象データＴ１７０３から整列順序Ｔ１７０７は、取得データを限定するための情報の例である。図１０に示す例では、ＳＱＬの類似表現で記載している。

対象データＴ１７０３は取得するデータの範囲を示す。一例として、要求項目ＩＤＴ１７０２に示す識別ＩＤが"１"の場合、最初から３番目以降のデータについての全項目（"＊, Ｏｆｆｓｅｔ ３"）である。階層Ｔ１７０４は取得するデータの所属する階層を指定するものである。制約条件Ｔ１７０５は取得するデータを限定する条件である。例えば、"関連リソースＩＤ＝[要求項目ＩＤ＝１]"として、要求項目ＩＤ＝１で取得されるデータのリソースＩＤＴ２１０１が、関連リソースＩＤＴ２１０４に指定されているリソースのデータであることを示している。

個数Ｔ１７０６は取得するデータの個数を示す。例えば"Ｏｖｅｒ １０"として最低個数を指定してもよい。整列順序Ｔ１７０７は、データを整列させる際の基準である。"[Ｐｅｒｆｏｒｍａｃｅ Ｃａｐａｃｉｔｙ Ｐｌａｎｎｉｎｇ]"のように、Ｆｅａｔｕｒｅで指定された場合には、基準管理テーブルＴ１６０を参照し、対応するメトリックＴ１６０４で整列する。

図１４は、本実施例に係るクエリ管理テーブルＴ２００の一例を示す図である。

クエリ管理テーブルＴ２００は、実際にリソースデータ管理テーブルＴ２１０からデータを取得するクエリ群を管理するテーブルである。

クエリ管理テーブルＴ２００は、セッションＩＤＴ２００１と、要求項目ＩＤＴ２００２と、クエリＩＤＴ２００３と、クエリＴ２００４と、必須フラグＴ２００５と、インパクト値Ｔ２００６と、実行時間見積もりＴ２００７とを有する。

セッションＩＤＴ２００１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。要求項目ＩＤＴ２００２は、要求項目管理テーブルＴ１７０の要求項目ＩＤＴ１７０２欄に対応する。クエリＩＤＴ２００３は、対応する要求項目を満たすためのクエリ群を識別するためのＩＤである。クエリＴ２００４は、個々のデータ取得クエリ（図１４に示す例ではＳＱＬの表現で示す）である。

必須フラグＴ２００５は、必ず表示されなければならないデータなど、実行する必要のあるクエリか否かを示すフラグである。インパクト値Ｔ２００６は、仮に要求項目ＩＤＴ２００２のデータ取得要求に対してクエリＩＤＴ２００３のクエリ群を実行し、データを取得してクライアント１００に送信した場合に、トポロジマップの表示上で欠落する項目等の影響の大きさを示したものである。実行時間見積もりＴ２００７は対応するクエリＴ２００４を実行した場合に見積もられる時間である。

図１５は、本実施例に係るリソースデータ管理テーブルＴ２１０の一例を示す図である。

リソースデータ管理テーブルＴ２１０は、リソース間の関連情報や、リソースの性能等の状態情報を保持するテーブルである。

リソースデータ管理テーブルＴ２１０は、リソースＩＤＴ２１０１と、リソース名Ｔ２１０２と、リソース種類Ｔ２１０３と、関連リソースＩＤＴ２１０４と、各種の状態情報を含む欄とを有する。

リソースＩＤＴ２１０１はリソースの識別ＩＤであり、リソース名Ｔ２１０２はリソースの名前である。リソース種類Ｔ２１０３は、リソースの種類を表す情報を保持する欄であり、図２に示すレベルＣ１３５３の階層名に対応する。関連リソースＩＤＴ２１０４は、ＵＩ部１１０の表示画面１１５上で当該リソースの下方向に接続されるリソースのＩＤを保持する。

応答時間Ｔ２１０５からＭｅｍｏｒｙ（ＧＢ）Ｔ２１１３までは、ノードデータ管理テーブルＴ１００の応答時間Ｔ１００９からＭｅｍｏｒｙ（ＧＢ）Ｔ１０１８と同様の情報である。

図１６は、本実施例に係るクエリ実行履歴管理テーブルＴ２３０の一例を示す図である。

クエリ実行履歴管理テーブルＴ２３０は、クエリ実行時間の見積もりを計算するための基礎データを保持するためのテーブルである。

クエリ実行履歴管理テーブルＴ２３０は、対象データＴ２３０１と、階層Ｔ２３０２と、制約条件Ｔ２３０３と、個数Ｔ２３０４と、整列順序Ｔ２３０５と、テーブル行数Ｔ２３０６と、実行時間Ｔ２３０７とを有する。

対象データＴ２３０１から整列順序Ｔ２３０５は、それぞれ要求項目管理テーブルＴ１７０の対象データＴ１７０３から整列順序Ｔ１７０７に対応し、リソースデータ管理テーブルＴ２１０からデータを取得する際に、取得データを限定する情報である。

例えば、クエリ実行履歴管理テーブルＴ２３０の２行目は、ＳＱＬでは"Select * from リソースデータ管理テーブルＴ２１０ where リソース種別=VM Group ordered by [Performance] limit 10"に対応する。テーブル行数Ｔ２３０６は、クエリ実行時のリソースデータ管理テーブルＴ２１０の行数である。実行時間Ｔ２３０７は、クエリ実行に実際に要した時間である。

図１７は、本実施例に係るトポロジデータ管理テーブルＴ２４０の一例を示す図である。

トポロジデータ管理テーブルＴ２４０は、セッション情報と共に、トポロジマップの状態を保持するためのテーブルである。本テーブルは、ＵＩ部１１０に対してユーザが操作を行うことでトポロジマップの状態が変化し、トポロジ構成管理サーバ２００に対して問い合わせが行われた際に更新される。

トポロジデータ管理テーブルＴ２４０は、セッションＩＤＴ２４０１と、トポロジデータＴ２４０２と、Ｖｉｅｗ階層名Ｔ２４０３と、ＦｅａｔｕｒｅＴ２４０４と、フィルタＴ２４０５と、更新時刻Ｔ２４０６とを有する。

セッションＩＤＴ２４０１は、図４に示したノードデータ管理テーブルＴ１００のセッションＩＤＴ１００１と同じ内容である。トポロジデータＴ２４０２は、トポロジマップの構成を示すデータであり、例えば、後述する図１１に示すようなＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式のデータである。Ｖｉｅｗ階層名Ｔ２４０３からフィルタＴ２４０５は、それぞれトポロジ設定状態管理テーブルのＶｉｅｗ階層名Ｔ１３０２からフィルタＴ１３０４に対応する。

＜実施形態のトポロジマップ提示システムの動作＞
図１８は、本実施例に係るトポロジマップ提示システム１の動作の一例を示すシーケンス図である。図１８のシーケンス図は、トポロジマップをＵＩ部１１０に表示するまでの処理シーケンスの概要を示したものである。

まず、ユーザがＵＩ部１１０で最初にトポロジマップを表示した場合を記す。

ユーザがＵＩ部１１０で初めてトポロジマップを表示した場合（Ｓ１０００）、ＵＩ部１１０は表示処理部１２０に対してトポロジマップの初期表示要求を行い（Ｓ１０１０）、それに応じて表示処理部１２０はトポロジ構成管理サーバ２００に対して初期トポロジデータを要求する（Ｓ１０２０）。

トポロジ構成管理サーバ２００は、初期トポロジデータの要求を受けると、トポロジデータ生成処理部２０１が初期トポロジデータを生成する。そして、トポロジ構成管理サーバ２００は、生成したトポロジデータとセッションＩＤを表示処理部１２０に返却する（Ｓ１０３０）。表示処理部１２０は、受領したトポロジデータについて各ノードの表示座標等を計算し、表示画面１１５の描画処理を行う（Ｓ１０４０）。

Ｓ１０５０からＳ１０９０は、トポロジマップに対してユーザの設定変更操作が行われた場合の処理シーケンスである。ユーザの設定変更操作とは、例えばグループノードの展開操作、階層単位でノードをグルーピングする操作、ＲＡＧ単位でノードをグルーピングする操作、Ｖｉｅｗを変更する操作、Ｆｅａｔｕｒｅを変更する操作がある。

ユーザ５００が操作を行うと（Ｓ１０５０）、ＵＩ部１１０は操作の内容や、操作が行われた対象のノードを特定し、表示処理部１２０に対して操作イベントの発生を通知する（Ｓ１０６０）。表示処理部１２０は、操作イベント発生が通知されると、トポロジマップの形態を変化させるためにまずはイベント分析処理部１２１が処理を実行する。これにより、要求する必要のあるデータを特定し、トポロジ構成管理サーバ２００にトポロジデータ取得の要求を送信する（Ｓ１０７０）。

トポロジ構成管理サーバ２００が要求を受信すると、トポロジデータ生成処理部２０１がトポロジデータを更新し、表示処理部１２０に返信する（Ｓ１０８０）。次に、表示処理部１２０のトポロジ表示構成計算処理部１２２が、トポロジ構成管理サーバ２００から受信したトポロジデータより、ＵＩ部１１０に表示する際に重大なノードがスクロールをしなくともユーザが確認しやすい、画面左部に表示されるように、相対的に重大度の低いノードのグルーピング等を計算する。その後、トポロジ表示構成計算処理部１２２が、トポロジマップの最終的な表示用データを元に、トポロジマップの描画処理を行う（Ｓ１０９０）。

なお、ＵＩ部１１０の再描画等を行った場合も、Ｓ１０６０～Ｓ１０９０と同様の処理が行われる。その場合、トポロジマップの形態を変化させる必要はないため、ＵＩ部１１０は、データ取得要求無しでセッションＩＤをトポロジ構成管理サーバ２００に送信する。トポロジ構成管理サーバ２００は、受信したセッションＩＤからトポロジデータ管理テーブルＴ２４０を参照し、各種のトポロジマップ設定情報をクライアント１００に送信する。クライアント１００は受信したトポロジデータと、トポロジマップ設定情報をもとに、トポロジマップの表示データを生成し、ＵＩ部１１０に描画する。

次に、グループノード展開操作を例にとって、イベント分析処理部１２１、トポロジデータ生成処理部２０１、トポロジ表示構成計算処理部１２２の動作の一例を説明する。

図２８は、本実施例におけるノード展開操作が行われた際のトポロジマップの状態変化の一例を示す図である。

図２８の左部はノード展開操作前のトポロジマップ１３６０の一例である。本例では、ＶｉｅｗにＳｅｒｖｅｒ Ｃｌｕｓｔｅｒが設定されており、Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒを起点としたツリー構造となっている。

"Ｓｅｒｖｅｒ１"１３６６に対して、関連するＶＭ Ｇｒｏｕｐとして"ＶＭ１"１３６４と"Ｇｒｏｕｐ１"１３６５がある。また"ＶＭ１"に関連するＡｐｐｌｉｃａｔｉｏｎとして"Ａｐｐ１"１３６１と"Ａｐｐ２"１３６２が、"Ｇｒｏｕｐ１"１３６５に関連するＧｒｏｕｐとして"Ｇｒｏｕｐ２"１３６３がある。

図２８の右部は"Ｇｒｏｕｐ１"１３６５を展開する操作が行われた際のトポロジマップ１３７０の一例である。

"Ｇｒｏｕｐ１"１３６５は展開され、個々のノードが表示されることとなる。そのために必要な、"Ｇｒｏｕｐ１"に含まれるノード群のデータ取得要求が"Ｒｅｑｕｅｓｔ１"１３７１で示されている範囲である。また、同時に"Ｇｒｏｕｐ２"１３６３に関しても、親となるノードが詳細化されるため、"Ｇｒｏｕｐ１"を構成する各ノードに関連するＡｐｐｌｉｃａｔｉｏｎのノードを表示する必要がある。これらの"Ｒｅｑｕｅｓｔ１"の結果である各ノードに関連するＡｐｐｌｉｃａｔｉｏｎのノード群のデータ取得要求が"Ｒｅｑｕｅｓｔ２"で示される範囲である。

図２８に示すトポロジマップのトポロジデータＴ１８０の例（ＪＳＯＮ形式）を図１１，図１２に示す。

図１１は、本実施例におけるグループノード展開操操作時のトポロジデータの一例を示す図であり、図１２は、本実施例におけるグループノード展開操作後にトポロジ管理サーバにデータを要求する際のトポロジデータの一例を示す図である。

図１１に示すトポロジデータは、図２８の左部に示すグループノード展開操作前のトポロジマップを表現するデータＴ１８０Ａであり、図１２に示すトポロジデータは、図２８の右部に示すグループノード操作後にトポロジ構成管理サーバ２００に問い合わせを行う際のトポロジデータＴ１８０Ｂである。

トポロジデータは、クライアント１００にてトポロジマップを表示する際に、表示するトポロジマップの内部表現としてや、トポロジ構成管理サーバ２００にてセッション情報と共に保持し、クライアント１００側の情報が失われた際にトポロジマップを再現するためのデータとして用いられる。

図１１に示すトポロジデータＴ１８０Ａは、階層名をキーとし、「ノード情報」の配列を値とする複数のメンバが含まれるオブジェクトである。例えばトポロジデータＴ１８０Ａでは、"Ｓｅｒｖｅｒ Ｃｌｕｓｔｅｒ"階層のノード群を示すメンバＴ１８１０Ａと、"ＶＭ Ｇｒｏｕｐ"階層のノード群を示すメンバＴ１８２０Ａと、"Ａｐｐｌｉｃａｔｉｏｎ"階層のノード群を示すメンバＴ１８３０Ａが図示されている。

「ノード情報」は、ノード名Ｔ１８０１と、ＲＡＧ状態Ｔ１８０２と、Ｇｒｏｕｐノードであるかを示すフラグＴ１８０３と、当該ノードに関連するノードの名前（Ｃｈｉｌｄｒｅｎ）Ｔ１８０４とを有する。

ＲＡＧ状態Ｔ１８０２の値は、例えば"ｒ"（Ｒｅｄ）、"ａ"（Ａｍｂｅｒ）、"ｇ"（Ｇｒｅｅｎ）である。また、Ｖｉｅｗの値によって、ＵＩ部１１０に表示されるトポロジマップ上でノード間の関連を辿ることができる方向が変化するため、ＣｈｉｌｄｒｅｎＴ１８０４の値は、Ｖｉｅｗの値によって決まる。例えば、Ｖｉｅｗとして指定されている階層のノードであれば、上下の両方向のノードに向かって関連を辿ることができるため、ＣｈｉｌｄｒｅｎＴ１８０４には上下の階層に属するノードの名前が含まれる。一方で、葉に位置するノードの場合には関連を辿る先のノードが無いため、ＣｈｉｌｄｒｅｎＴ１８０４自体が存在しないか、空の配列を値として持つ。以降の説明では簡単のため、関連を辿る元となるノードを親ノード、関連を辿る先のノードを子ノードと記載する。

図１２に示すトポロジデータＴ１８０Ｂは、"Ｇｒｏｕｐ２"１３６５を展開した際に、トポロジ構成管理サーバ２００にデータ取得要求を行う際にトポロジ構成管理サーバ２００に渡されるトポロジデータである。

そのため、トポロジマップとして必要なノードのデータはすべて埋められていない。その代わりに例えば、"ＶＭ Ｇｒｏｕｐ"のノード群（Ｔ１８２０Ｂ）にデータ取得要求項目"Ｒｅｑｕｅｓｔ２"を示す仮ノードが、"Ａｐｐｌｉｃａｔｉｏｎ"のノード群（Ｔ１８３０Ｂ）にデータ取得要求項目"Ｒｅｑｕｅｓｔ２"を示す仮ノードが埋められている。

また、各ノードには"Ｒｅｑｕｅｓｔ１""Ｒｅｑｕｅｓｔ２"を含む形でノード間の関連を示すＣｈｉｌｄｒｅｎＴ１８０４の値が埋められている。これにより、のちにトポロジ構成管理サーバ２００からデータを取得した後、"Ｒｅｑｕｅｓｔ１""Ｒｅｑｕｅｓｔ２"の仮ノードを実ノードで置き換えることで、トポロジマップデータを生成することができる。

イベント分析処理部１２１は、ユーザがトポロジマップに操作を行った際に、操作に応じてトポロジデータへの変更内容を計算する処理を行う。イベント分析処理部１２１により実行される処理のフローチャートを図１９に示す。

図１９は、本実施例に係るトポロジマップ提示システム１におけるイベント分析処理部１２１の動作の一例を示すフローチャートである。

イベント分析処理部１２１は、まず受信した操作イベントに応じてトポロジデータの変更内容計算処理を行う。まず、イベント分析処理部１２１は、操作イベントがノード展開操作であるか否かを判定し（Ｓ２０００）、ノード展開操作であると判定したら（Ｓ２０００においてＹｅｓ）、ノード展開変更内容計算処理１２３を実行する。

一方、ノード展開操作でないと判定したら（Ｓ２０００においてＮｏ）、次に、イベント分析処理部１２１は、操作イベントが階層の単位でノード群をグルーピングする操作であるか否かを判定する（Ｓ２０１０）。そして、階層の単位でノード群をグルーピングする操作であると判定したら（Ｓ２０１０においてＹｅｓ）、階層グループ化変更内容計算処理１２４を実行する。

一方、階層の単位でノード群をグルーピングする操作でないと判定したら（Ｓ２０１０においてＮｏ）、次に、イベント分析処理部１２１は、操作イベントが階層以外の単位でノード群をグルーピングする操作であるか否かを判定する（Ｓ２０２０）。そして、操作イベントが階層以外の単位でノード群をグルーピングする操作であると判定したら（Ｓ２０２０においてＹｅｓ）、ノードグループ化変更内容計算処理１２５を実行する。一方、操作イベントが階層以外の単位でノード群をグルーピングする操作でないと判定したら（Ｓ２０２０においてＮｏ）、イベント分析処理部１２１はトポロジ再構成内容計算処理１２６を実行する。

各トポロジデータの変更内容計算処理（１２４～１２８）を実行後、イベント分析処理部１２１は、操作イベントの内容と、操作イベント後のトポロジデータと、必要な場合にはデータ取得要求とをトポロジ構成管理サーバ２００に送信する（Ｓ２０５０）。

図２０は、本実施例に係るトポロジマップ提示システム１におけるノード展開変更内容計算処理１２３の一例を示すフローチャートである。

ノード展開変更内容計算処理１２３では、イベント分析処理部１２１が操作対象のノードのＩＤを取得すると（Ｓ２１００）、まず、トポロジデータＴ１８０から操作対象のノードを取り除く（Ｓ２１１０）。次に、イベント分析処理部１２１は、グループ展開後のノード群をトポロジデータＴ１８０に挿入する。

ここで、操作されたノード種類が"Ｌｏｃａｔｉｏｎｓ"、"ＢＵｓ＆Ａｐｐｌｉａｔｉｏｎｓ"、"ＩＴ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅｓ"のような、グループノードをさらにグルーピングしたグループノードである場合、ノード展開操作によって新たに表示するノードを、関連を辿って探すことは必要ない。そのため、イベント分析処理部１２１は、展開後のノードもグループノードであるか否かを判定し（Ｓ２１２０）、展開後のノードもグループノードであると判定したら（Ｓ２１２０においてＹｅｓ）、グループノードデータ管理テーブルＴ１１０のメンバノードＩＤＴ１１０３を参照し、ノード展開後のノードをトポロジデータに反映させて処理を終了する（Ｓ２１３０）。

一方、展開後のノードはグループノードでない場合（Ｓ２１２０においてＮｏ）、イベント分析処理部１２１は、トポロジマップに新たに表示するノードをグループノードの親ノードから関連を辿り探す必要がある。また、同様に新たに表示するノードに対して関連を持つ孫ノードを、孫ノードに関連を持つ子孫ノードを、徐々に各階層について走査し、展開するグループノード以下のサブツリーを再構築する必要がある。

そこで、イベント分析処理部１２１は、ノード展開操作対象のグループノードを展開する（Ｓ２１４０～Ｓ２１６０）。まず、イベント分析処理部１２１は、グループノードデータ管理テーブルＴ１１０のノード展開操作対象のグループノードに対応する行を参照する。

この時、イベント分析処理部１２１は、当該行の全部取得済みフラグＴ１１０５がＴｒｕｅであるか否かを判定し（Ｓ２１４０）、全部取得済みフラグＴ１１０５がＴｒｕｅでないと判定したら（Ｓ２１４０においてＮｏ）、イベント分析処理部１２１は、展開後のノードを表示する上で追加のデータを取得する必要があると判断する。そこで、イベント分析処理部１２１は条件欄Ｔ１１０４を参照し、同内容でデータ取得要求を作成し、要求項目管理テーブルＴ１７０に格納する（Ｓ２１５０）。一方、全部取得済みフラグＴ１１０５がＴｒｕｅであると判定したら（Ｓ２１４０においてＹｅｓ）、そのままＳ２１６０に進む。

そして、イベント分析処理部１２１は、当該行のメンバノードＩＤＴ１１０３のノード情報と、Ｓ２１５０で作成した要求項目がある場合には、その要求項目内容を示す仮ノードの情報をトポロジデータに反映させる（Ｓ２１６０）。

次に、イベント分析処理部１２１は、走査を開始する階層から表示画面１１５上においてこの階層から離れる方向に、つまり葉の方向へ向かって、各階層について順番にＳ２１７０からＳ２１９０の処理を実行する。これにより、ノードを展開した後の状態において、Ｓ２１４０～Ｓ２１６０で選択した展開後のノードの子孫ノードに関してトポロジを再構築する。

まず、イベント分析処理部１２１は、選択されている操作対象階層のノード群から（Ｓ２１７０）、操作対象グループノードの親ノードを選択し、もしくは、操作対象グループノードがＶｉｅｗ階層に属する場合は、操作対象グループノードを構成するメンバのノード群を選択する（Ｓ２１８０）。そして、選択した各ノードについて、子階層変更内容計算処理１２９を実行する。次ループ以降は、前のループで選択した各ノードの子ノードをＳ２１８０で選択する。これにより、逐次的に各ノードの子ノード群が子階層変更内容計算処理１２８によってトポロジデータに反映される。

図２１は、本実施例に係るトポロジマップ提示システム１における子階層変更内容計算処理１２８の一例を示すフローチャートである。子階層変更内容計算処理１２８は、指定されたノードについて、トポロジマップに表示するその子ノード群を選択し、トポロジデータに反映させる処理である。

イベント分析処理部１２１が対象となるノードを受信すると（Ｓ２９００）、まずトポロジデータを参照し、対象ノードの子ノードがグルーピングされているグループノードであるか否かを判定する（Ｓ２９１０）。そして、イベント分析処理部１２１が、対象ノードの子ノードがグループノードであると判定したら（Ｓ２９１０においてＹｅｓ）、対象ノードの子ノードは、グループ化によって敢えて詳細の情報がトポロジマップ上に表示されていない状態であることから、これ以上のノードの展開は行わずに処理を終了する。

一方、対象ノードの子ノードがグループノードでないと判定したら（Ｓ２９１０においてＮｏ）、イベント分析処理部１２１はＳ２９００で指定されたノードの子ノード群をトポロジマップ上に表示する必要がある。そこで、イベント分析処理部１２１は、グループノードデータ管理テーブルＴ１１０の条件欄Ｔ１１０４を参照し、子ノードが属する階層に属するノード群であること、対象ノードに関連する（子ノードである）ノード群であること、Ｆｅａｔｕｒｅが同一であること、の条件を満たす行があるか否かを判断し、当該行がある場合には、メンバノードＩＤＴ１１０３に含まれるノードの情報をトポロジデータに反映する（Ｓ２９３０）。

この時、Ｓ２９３０で条件に合うノードが無い場合、あっても当該行の全部取得済みフラグＴ１１０５がＦａｌｓｅの場合（Ｓ２９４０においてＮｏ）、イベント分析処理部１２１は不足のノードのデータをトポロジ構成管理サーバ２００から取得する必要がある。そのため、イベント分析処理部１２１はＳ２９３０で用いた条件と同内容でデータ取得要求を作成し、要求項目管理テーブルＴ１７０に格納する（Ｓ２９５０）。そして、イベント分析処理部１２１は、Ｓ２９５０で作成した要求項目の内容を示す仮ノードの情報をトポロジデータに反映させる（Ｓ２９６０）。

図２２は、本実施例に係るトポロジマップ提示システム１における階層グループ化変更内容計算処理１２４の一例を示すフローチャートである。階層グループ化変更内容計算処理１２４は、階層単位でノード群をグループ化する処理である。

イベント分析処理部１２１は、対象となるノードと、グループとしてまとめる単位の階層を受信し、処理を始める（Ｓ２３００、Ｓ２３１０）。例えば、図２に示すように、Ａｐｐｌｉｃａｔｉｏｎのノードは"Ａｐｐｌｉｃａｔｉｏｎｓ"や"ＢＵｓ＆Ａｐｐｌｉｃａｔｉｏｎｓ"のグループノードに纏められてもよい。このように、一つのノードに対して、グループとしてまとめる階層の単位は複数あり得るため、例えばＵＩ部１１０上で、ノードを右クリック選択等することにより、グループ化の単位の階層を選択させる等の操作を行ってもよい。

次に、イベント分析処理部１２１は、Ｓ２３１０で受信したグループ化単位階層について、階層定義テーブルＴ１５０を参照し、所属ノード種類Ｔ１５０４がすべてグループノードであるか否かを判定する（Ｓ２３２０）。すべてグループノードであると判定したら（Ｓ２３２０においてＹｅｓ）、グループ化後のグループノードは、展開時には既定のグループノードに展開される振る舞い（Ｌｏｃａｔｉｏｎｓが展開されると、Ｃｏｎｔｒｉｅｓと、Ｃｉｔｉｅｓと、ＤＣｓに展開される、等）が期待されることから、イベント分析処理部１２１は、グループノードデータ管理テーブルＴ１１０に初期値として設定されるグループノードのノードＩＤＴ１１０２の値を取得する（Ｓ２３３０）。

一方、グループノードでないノードが含まれていると判定したら（Ｓ２３２０においてＮｏ）、イベント分析処理部１２１はグループノードデータ管理テーブルＴ１１０を参照し、条件欄Ｔ１１０４がグループ化対象のノード群である条件に合致し、全部取得済みフラグＴ１１０５がＴｒｕｅの行が存在するか否かを判定する。存在する場合には、重複する情報を保持することを避けるために、当該行のノードＩＤＴ１１０２の値を取得する。存在しない場合には、新規にグループノードのノードＩＤを採番し、グループノードデータ管理テーブルＴ１１０に追加する（Ｓ２３４０）。この時、対象の階層のノードを全てクライアント１００が保持しているとは限らないため、全部取得済みフラグＴ１１０５はＦａｌｓｅとする。

次に、イベント分析処理部１２１は、グループ化する階層に所属するすべてのノードの情報をトポロジデータから取り除き（Ｓ２３５０）、代わりにＳ２３３０、Ｓ２３４０で特定したグループノードの情報をトポロジデータに反映させる（Ｓ２３６０）。

その後、イベント分析処理部１２１は、子ノード以降のサブトポロジを再計算する。これは、グルーピング操作の前は各ノードに関連するノードが子ノードとして表示されていたが、ノードが階層単位でグルーピングされたことにより、子ノードが特定のノードに関連するかに制約されなくなるためである。イベント分析処理部１２１は、操作対象のノード以降の各階層についてＳ２３７０からＳ２３９０、及び子階層変更内容計算処理１２８を実行する。これらの処理は、ノード展開変更内容計算処理１２３のＳ２１７０～Ｓ２１９０と同様であるため、詳細な説明を省く。

図２３は、本実施例に係るトポロジマップ提示システム１におけるノードグループ化変更内容計算処理１２５の一例を示すフローチャートである。

ノードグループ化変更内容計算処理１２５は、図２２で示した階層グループ化変更内容計算処理でまとめた階層未満の複数ノード群をグループ化する処理である。本実施例では、代表的な例として、ＲＡＧ状態の単位でノードをグルーピングするフローを例として示す。

イベント分析処理部１２１は、対象となるノードを受信し、処理を始める（Ｓ２４００）。まず、イベント分析処理部１２１は、対象ノードのリソース種類と性能等の各種の状態情報をノードデータ管理テーブルＴ１００から取得し、基準管理テーブルＴ１６０を参照し、現在のＦｅａｔｕｒｅに対応する基準でのＲＡＧ状態を求める（Ｓ２４１０）。そして、イベント分析処理部１２１は、グループ化対象のノード群として、トポロジデータから同リソース種類、同ＲＡＧ状態のノードを選択する（Ｓ２４２０）。

次に、イベント分析処理部１２１は、グループノードデータ管理テーブルＴ１１０を参照し、条件欄Ｔ１１０４がグループ化対象のノード群である条件に合致し、全部取得済みフラグＴ１１０５がＴｒｕｅの行が存在するか否かを判定する。存在する場合には、重複する情報を保持することを避けるために、当該行のノードＩＤＴ１１０２の値を取得する。存在しない場合には、新規にグループノードのノードＩＤを採番し、グループノードデータ管理テーブルＴ１１０に追加する（Ｓ２４３０）。

次に、イベント分析処理部１２１は、グループ化するノード群の情報をトポロジデータから取り除き（Ｓ２４４０）、代わりにＳ２４３０で特定したグループノードの情報をトポロジデータに反映させる（Ｓ２４５０）。

その後、イベント分析処理部１２１は、子ノード以降のサブトポロジを再計算する。すなわち、イベント分析処理部１２１は、操作対象のノード以降の各階層について、Ｓ２４６０からＳ２４８０、及び子階層変更内容計算処理１２８を実行する。これらの処理は、ノード展開変更内容計算処理１２３のＳ２１７０～Ｓ２１９０と同様のため、詳細な説明を省く。なお、グループ化したグループノードの子ノードとしては、操作前のノード群の子ノードを、重複を排して整列させてもよい。

本実施例では代表的な例として、ＲＡＧ状態の単位でノードをグルーピングする場合について示したが、任意の単位でノードをグループ化できてもよい。例えば、その場合にはユーザにマウス選択等のＵＩ部１１０上でグルーピングする複数のノードを選択させ、そのノード群の情報をＳ２４００の処理で受信することで、Ｓ２４２０で示したようなグルーピング対象のノード群の情報を取得してもよい。また、その場合では、グループノードのＲＡＧとして、最悪値を表示する等の方法で複数のＲＡＧ状態を統合して表示しても良い。

図２４は、本実施例に係るトポロジマップ提示システム１におけるトポロジ再構成内容計算処理１２６の一例を示すフローチャートである。

トポロジ再構成内容計算処理１２６は、Ｖｉｅｗを変更した場合や、Ｆｅａｔｕｒｅを変更した場合、ＵＩ部１１０を再描画し、トポロジマップを更新した場合等にトポロジを再構成する処理である。

イベント分析処理部１２１は、Ｖｉｅｗ階層名を受信し、処理を始める（Ｓ２５００）。まず、イベント分析処理部１２１は、Ｖｉｅｗ階層のノードについてトポロジデータを更新する。まず、階層展開状態管理テーブルＴ１２０を参照し、Ｖｉｅｗ階層がＯｐｅｎの状態であるか否かを判定する（Ｓ２５１０）。Ｖｉｅｗ階層がＯｐｅｎの状態であると判定したら（Ｓ２５１０においてＹｅｓ）、Ｖｉｅｗ階層で表示されるノードはグループノードのみで変化しないため、Ｓ２５２０からＳ２５４０の処理を行わずにイベント分析処理部１２１はＳ２５５５０の処理を行う。

一方、Ｖｉｅｗ階層がＯｐｅｎの状態でないと判定したら（Ｓ２５１０においてＮｏ）、イベント分析処理部１２１はグループノードデータ管理テーブルＴ１１０を参照し、Ｖｉｅｗ階層に所属するノード群であること、Ｆｅａｔｕｒｅが同一であることの条件に合致する行が存在するか否かを判定する。存在すると判定した場合は、イベント分析処理部１２１は、全部取得済みフラグＴ１１０５がＴｒｕｅであるか否かを判断する（Ｓ２５２０）。全部取得済みフラグＴ１１０５がＴｒｕｅでないと判定したら（Ｓ２５２０においてＮｏ）、トポロジ構成管理サーバ２００から追加でノードの情報を取得する必要があるため、イベント分析処理部１２１は、Ｓ２５２０の条件をもとに要求項目管理テーブルＴ１７０にデータ取得の要求を追加する（Ｓ２５３０）。

一方、全部取得済みフラグＴ１１０５がＴｒｕｅであると判定したら（Ｓ２５２０においてＹｅｓ）、イベント分析処理部１２１は、グループノードデータ管理テーブルＴ１１０の当該行から、メンバノードＩＤＴ１１０３のノードの情報でトポロジデータを更新する。また、Ｓ２５２０において全部取得済みフラグＴ１１０５がＴｒｕｅでないと判定したら、イベント分析処理部１２１は、Ｓ２５３０で追加したデータ取得要求に対応する仮ノードの情報でトポロジデータを更新する（Ｓ２５４０）。

次に、イベント分析処理部１２１は、Ｖｉｅｗ階層の上下の階層に向かってサブトポロジを再構成する。すなわち、イベント分析処理部１２１は、各階層についてＳ２５５０からＳ２５７０、及び子階層変更内容計算処理１２８を実行する。これらの処理は、ノード展開変更内容計算処理１２３のＳ２１７０～Ｓ２１９０と同様のため、詳細な説明を省く。

以上、イベント分析処理部１２１により、操作イベント発生時のトポロジ構成変化を計算し、トポロジデータを更新すると共に、追加で必要なデータのデータ取得要求項目を要求項目管理テーブルＴ１７０に追加する。その後、クライアント１００は、トポロジ構成管理サーバ２００と通信し、操作イベント内容やトポロジデータの更新を通知すると共に、データ取得要求を送信する。トポロジ構成管理サーバ２００は、データを受信すると、トポロジデータ生成処理部２０１を実行し、追加データを取得後のトポロジデータを生成する。

図１３は、本実施例におけるトポロジ構成管理サーバ２００に追加データを要求する際に送信されるデータＴ２５０の一例（ＪＳＯＮ形式）を示す図である。

データＴ２５０は、セッションＩＤＴ２５１０と、操作イベントの内容Ｔ２５２０と、操作対象のノード名Ｔ２５３０と、Ｖｉｅｗ階層名Ｔ２５４０と、Ｆｅａｔｕｒｅ名Ｔ２５５０と、トポロジデータＴ２５６０と、ディスプレイノードＴ２５７０と、要求項目Ｔ２５８０とを有する。

トポロジデータＴ２５６０は図１２に示すデータと同一である。また、ディスプレイノードＴ２５７０は、ＵＩ部１１０に表示されているトポロジの内、フォーカスが当たっており、描画されているノード群を示している。これは、トポロジマップの内、ユーザが現状参照している部分であり、ＵＸの観点で重要性の高い部分である。

要求項目Ｔ２５８０は要求項目管理テーブルＴ１７０と同様の内容である。ＩＤＴ２５８１は要求項目ＩＤＴ１７０２に、"ＴａｒｇｅｔＤａｔａ"Ｔ２５８２は対象データＴ１７０３に、"Ｌａｙｅｒ"Ｔ２５８３は階層Ｔ１７０４に、"Ｗｈｅｒｅ"Ｔ２５８４は制約条件Ｔ１７０５に、"Ｌｉｍｉｔ"Ｔ２５８５は個数Ｔ１７０６に、"Ｏｒｄｅｒ"Ｔ２５８６は整列順序Ｔ１７０７にそれぞれ対応する。

図２５は、本実施例に係るトポロジマップ提示システム１におけるトポロジ構成管理サーバ２００が有するトポロジデータ生成処理部２０１の動作の一例を示すフローチャートである。

トポロジデータ生成処理部２０１は、クライアント１００からデータＴ２５０を受信し、処理を始める（Ｓ４０００）。まず、トポロジデータ生成処理部２０１は、受信したデータの"ＳｅｓｓｉｏｎＩＤ"Ｔ２４１０を参照し、トポロジデータ管理テーブルＴ２４０に当該の値が格納されているか、格納されているならばその値が有効期限内であるなどの有効な値であるか否かを判定する（Ｓ４０１０）。そして、判定が否定されたら（Ｓ４０１０においてＮｏ）、トポロジデータ生成処理部２０１は、初期データとして最も広範囲でグルーピングされている単位のグループノード（"Ｌｏｃａｔｉｏｎｓ"、"ＢＵｓ＆Ａｐｐｌｉｃａｔｉｏｎｓ"、"ＩＴＩｎｆｒａｓｔｒａｃｔｕｒｅｓ"）からなるトポロジデータを返却する（Ｓ４０２０）。これは、ユーザの多様なユースケースに対応できるトポロジマップを初期状態とするためである。

一方、判定が肯定されたら（Ｓ４０１０においてＹｅｓ）、トポロジデータ生成処理部２０１は、さらに"ＲｅｑｕｅｓｔＳｐｅｃ"Ｔ２４８０を参照し、データの取得要求があるか否かを判定する（Ｓ４０３０）。データの取得要求はないと判定したら（Ｓ４０３０においてＮｏ）、トポロジデータ生成処理部２０１は、特にトポロジデータに変更を加えず、受信した"ＴｏｐｏｌｏｇｙＤａｔａ"Ｔ２４６０をそのまま返却する（Ｓ４０４０）。

一方、データの取得要求があったと判定したら（Ｓ４０３０においてＹｅｓ）、トポロジデータ生成処理部２０１は追加をデータ取得を行い、トポロジデータを更新して返却する。

まず、トポロジデータ生成処理部２０１は、詳細を後述するクエリ生成処理２０２を実行し、データ取得要求に対して、対応する複数のデータ取得クエリセットを生成してクエリ管理テーブルＴ２００に格納する。基本的にはＤＢからデータを取得する際には、取得するデータ量が多いほど、また、複雑なクエリを実行するほど、多数のクエリを実行するほど、データ取得に要する時間が長くなる。データ取得にかかる時間が長くなるほど、ＵＩ部１１０上での画面更新に時間がかかる事となり、ユーザビリティが低下する。しかしながら、取得される情報量が少なくなるほど更新後のトポロジマップで表示できる情報が少なくなってしまい、トポロジマップとしての有効性が低下してしまう。そのため、クエリ生成処理２０２では、取得できるデータ量による有効性の低下度合い（以下、インパクトと称する）と、実行時間見積もりが異なる複数パタンのクエリセットとを生成する。

次に、トポロジデータ生成処理部２０１は、クライアント１００に対する目標応答時間内で終了するクエリ群であって、最もインパクトが小さくなるような各データ取得要求に対するデータ取得クエリセットの組み合わせを生成する（Ｓ４０５０）。これには、例えば既知の組み合わせ最適化アルゴリズムを用いて計算すればよい。

次にトポロジデータ生成処理部２０１はクエリを実行してデータを取得する。すなわち、トポロジデータ生成処理部２０１は、インパクトの大きいクエリセットから順番に、各クエリを実行しＤＢからデータを取得する（Ｓ４０６０、Ｓ４０７０）。ここで、もしもトポロジデータ生成処理を実行開始してからの経過時間が目標応答時間を超過した場合、トポロジデータ生成処理部２０１は以降のクエリ実行をキャンセルする（Ｓ４０７５）。

その後、トポロジデータ生成処理部２０１は、"ＴｏｐｏｌｏｇｙＤａｔａ"Ｔ２４６０に含まれる各仮ノードを対応する取得データで置き換えることで完全なトポロジデータに更新し、クライアント１００に返却する（Ｓ４０８０、Ｓ４０９０）。

最後にトポロジデータ生成処理部２０１は、返却するトポロジデータでトポロジデータ管理テーブルを更新し処理を終了する（Ｓ４１００）。

これにより、トポロジデータ生成処理部２０１は可能な限りトポロジマップで表示できる情報量を最低限としつつ、データ取得によるＧＵＩの更新時間を一定時間以下にすることができる。

図２６は、本実施例に係るトポロジマップ提示システム１におけるクエリ生成処理の一例２０２を示すフローチャートである。クエリ生成処理２０２は、データ取得要求に対して、取得データ量の異なる複数のデータ取得クエリを生成し、各クエリを実行した場合のインパクトを見積もる処理である。

基本的には、要求された条件に合致するすべてのデータを返却することが最良だが、すべてのデータを返却することが処理時間的に現実的でない場合には、一部のノードはグループ化して表示してもよいと考えられる。この場合、ユーザの興味がグループ化されたノードにあった場合、再度操作を行う必要が生じるため、データ取得量を少なくしたためにインパクトが発生したといえる。また、これはユーザがＵＩ部１１０で表示している領域に近ければ近い程、再度の操作が発生しやすく、そのような領域のノードに関するデータ取得量を少なくすることのインパクトは大きくなると考えられる。

また、Ｖｉｅｗに近い階層でグループノード化するほど、そのグループノード以降のサブトポロジの大きさは小さくなり、トポロジマップで表示できる情報量は少なくなる。そのため、Ｖｉｅｗに近い階層であるほどデータ取得量を少なくすることのインパクトは大きくなる。

そのため、クエリ生成処理２０２では、各クエリセットのインパクト値をクエリ毎の基本値、対象階層のＶｉｅｗからの距離(a)、階層内での仮ノードの表示範囲左端からの距離(b)の積として計算する。

まず、トポロジデータ生成処理部２０１は、インパクト値を計算するための基本データして、受信したトポロジデータよりトポロジマップに表示される階層と、各階層にて表示されるノードの数を計算する（Ｓ４２００）。そして、各要求項目についてＳ４２２０～Ｓ４２６０を実行し、対応するクエリセットと、そのインパクトを計算する（Ｓ４２１０）。

まず、トポロジデータ生成処理部２０１は対象階層のＶｉｅｗからの距離ａを計算する（Ｓ４２２０）。各階層のａの値は、Ｖｉｅｗ階層に近い程大きい値となる。計算方法としては、例えば、以下のように対象階層のＶｉｅｗからの距離について、逆数をとった値等である。

上記の計算式の場合、例えばＶｉｅｗ階層自体が対象の場合ａ＝１ととなり、Ｖｉｅｗから２階層上の階層の場合、ａ＝１／３となる。なお、上記の計算方法は簡単な例であり、正規分布等の任意の確率分布に従ってaの値が計算されてもよいし、特定の階層についてはaの値が大きくなるように重み付けがなされても良い。例えば、その場合にはその重みがＶｉｅｗの設定によって変動してもよい。

次に、トポロジデータ生成処理部２０１は、階層内での仮ノードの表示範囲左端からの距離ｂを計算する（Ｓ４２３０）。仮ノードのｂの値は、基本的には仮ノードと同一階層の、表示範囲左端のノードからの距離が大きい程小さい値となる。計算方法としては、例えば、以下のように仮ノードと、表示範囲左端のノードからの距離について逆数をとった値等である。

上記の計算式の場合、例えば表示範囲左端のノードから、右に３ノード分離れた位置に仮ノードがある場合、ｂ＝１／４となる。なお、上記の計算方法は簡単な例であり、Ｓ４２２０と同様な他の計算方法でもよい。例えば、表示範囲内のノードであるか、否かによってｂの値を決定する際の重みに差がつけられていても良い。

次に、トポロジデータ生成処理部２０１は、データ取得範囲の異なる複数のデータ取得クエリを生成する（Ｓ４２４０）。クエリの生成パタンとしては、例えば以下（１）～（４）に示すようなパタンである。
（１）要求された条件に合致するすべてのリソースについて、全情報を取得する。
（２）要求された条件に合致するリソースの内、上位１０件は全情報を取得する。それ以外は、ＲＡＧ状態でグループ化した際にリソース数を表示できるように、各ＲＡＧ状態毎にリソース件数の情報のみを取得する。
（３）要求された条件に合致するリソースの内、上位１０件は全情報を取得する。それ以外をグループ化した際にリソース数を表示できるように、リソース件数の情報も取得する。
（４）情報は取得しない。

トポロジデータ生成処理部２０１は、指定された要求項目の値を基に、各パタンのクエリを生成する。具体的なクエリ例は、図１４に示すクエリ管理テーブルＴ２００のクエリＴ２００４に示す通りである。また、これらの各クエリの基本インパクト値はインパクト値Ｔ２００６に示すように、予め決められた値を用いてもよい。図１４に示す例ではパタン（１）は要求データすべてが取得されているので、インパクト値は０となり、パタン（４）では要求データが無いため、インパクト値は１００となる。パタン（２）（３）は０～１００の範囲で設定された値である。

次に、トポロジデータ生成処理部２０１は、Ｓ４２２０～Ｓ４２４０で計算した基本インパクト値とａ、ｂの値を基に、各クエリのインパクト値を計算する（Ｓ４２５０）。

また、トポロジデータ生成処理部２０１は各クエリの実行時間の見積もりを計算する（Ｓ４２６０）。その計算方法としては、例えば過去のクエリに実行記録である図１６のクエリ実行履歴管理テーブルＴ２３０を参照し、クエリの内容が同様である過去クエリ結果の実行時間と、その際のテーブル行数を特定し、それらのデータからテーブル行数を入力、実行時間を出力とする関数式を推定する。そして、推定した関数式をもちいて、現在のテーブル行数からクエリ実行時間を見積もる方法がある。関数式の推定方式としては、例えば既知の回帰分析の手法を用いればよい。

最後に、トポロジデータ生成処理部２０１は、Ｓ４２５０、Ｓ４２６０で計算したインパクト値と実行時間見積もりと共に、要求項目に対応するクエリセットをクエリ管理テーブルＴ２００に格納する。

図２７は、本実施例に係るトポロジマップ提示システム１におけるトポロジ表示構成計算処理部１２２の動作の一例を示すフローチャートである。

トポロジ表示構成計算処理部１２２は、トポロジ構成管理サーバ２００から受信したトポロジデータを元に、ＵＩ部１１０に表示するトポロジマップの構成を計算する。その際に、重要度が高いノードがＵＩ部１１０の表示画面１１５内に表示されるように、ノードの整列順序やグルーピングの範囲を計算する。

トポロジ表示構成計算処理部１２２は、まず、Ｖｉｅｗ階層から上下階層へ向かって、階層毎に同一の親ノードの子ノード群は重要度が高い順番に左から整列して表示されるように、トポロジデータに含まれる各ノードについて、重要度が高い順となるようにノードを整列する（Ｓ４３００）。

次に、トポロジ表示構成計算処理部１２２は、トポロジデータの各ノードについて、ＵＩ部１１０上での表示座標を計算する（Ｓ４３１０）。座標の計算方法としては、例えばトポロジマップの初期表示であった場合には、Ｖｉｅｗ階層の内最も重要度が高いノードを、また、ノードへの操作が行われた場合は、操作対象のノードを、それ以外の場合には表示画面１１５中央に最も近いノードを基準ノードとして選択し、基準ノードの位置をもとに各ノードの座標を計算する。

まず、トポロジ表示構成計算処理部１２２は、基準ノードの座標を再描画前の位置や、初期描画の場合には一定の位置で設定し、次に基準ノードから上下に関連するノードを一定間隔で離れるように配置し、それを葉のノードになるまで調整を繰り返し、サブツリーを構成するノードの座標を計算する。次に基準ノードの左右のノードについて、先に計算したサブツリーと重ならないよう配置し、同様に関連する上下ノードの配置を計算し、サブツリーを構成するノードの座標を計算する。これを、基準ノードと同階層の全ノードに対して行い、各ノードの座標を計算する。

次に、トポロジ表示構成計算処理部１２２は、表示範囲に重要度の高いノードが含まれるようにノードをグルーピングし、相対的に重要度の低いサブトポロジを省略することを計算していく。サブトポロジを省略するとは、同一ノードを親とする１つ以上の複数のノードをグループ化し、その子孫ノードからなるサブトポロジを表示しないようにすることである。ここで、表示範囲とはＵＩ部１１０でフォーカスの当たっている領域であってもよいし、それから一定程度スクロールする範囲を含む領域であってもよい。

次に、トポロジ表示構成計算処理部１２２は階層毎にノードの重要度を正規化し、全ノードの重要度を比較可能とする。そして、表示範囲に、例えば重要度が高い順に５ノードが含まれているか否かを判定する（Ｓ４３２０）。そして、判定が肯定されたら（Ｓ４３２０においてＹｅｓ）、トポロジ表示構成計算処理部１２２は重大なノードがユーザの見やすい位置に表示されていると判断し、処理を終了する。

一方、判定が否定されたら（Ｓ４３２０においてＮｏ）、次に、トポロジ表示構成計算処理部１２２は、表示範囲に含まれるノード群について、グループノードが占める割合が、例えば２０％以上であるか否かを判定する（Ｓ４３３０）。グループノードが占める割合が一定比率以上であると判定したら（Ｓ４３３０においてＹｅｓ）、これ以上グループノードを増やすと通常のノードが少なくなり、トポロジ内でのノード間の詳細な関連が表示されず、ユーザが具体的な判断を行うことができなくなる可能性がある。そのため、トポロジ表示構成計算処理部１２２はグループノードを増加させず、処理を終了する。なお、Ｓ４３２０、Ｓ４３３０で例示した閾値は利用するユーザ等によって適切な値は異なり、可変であってもよい。

一方、グループノードが占める割合が一定比率を下回ると判定したら（Ｓ４３３０においてＮｏ）、トポロジ表示構成計算処理部１２２は、表示範囲に含まれていないノードの内、最も重要度が高いノードが表示範囲に含まれるようにするために省略するサブトポロジを選択する（Ｓ４３４０）。計算方法としては、例えば選択したノードが表示範囲に含まるトポロジ構成の内、省略されたサブトポロジのノード群の重要度の和が最小となる、省略ノードの組み合わせを求める組み合わせ最適化問題を解く方法である。

最後にトポロジ表示構成計算処理部１２２は、Ｓ４３３０で計算したノードを省略するためのノードのグルーピングをトポロジデータに反映させ、処理をＳ４３１０に移す。

＜実施形態のトポロジマップ提示システムの効果＞
このように構成される本実施例によれば、表示処理部１２０が、ＵＩ部１１０が受け入れた基準となる階層の指定入力に基づいて、指定された階層に含まれる少なくとも一つのノードから、このノードに関連するノードが表示画面１１５の上下方向に向かって表示されたトポロジマップをＵＩ部１１０の表示画面１１５に表示させている。

従って、リソース数が増加した場合であっても、観点や着目リソースを変えつつＩＴシステム全体の状態を容易に俯瞰、把握することが可能となる。

また、表示処理部１２０は、トポロジマップに基づく検討の観点（Ｆｅａｔｕｒｅ）についてＵＩ部１１０が受け入れた選択入力及び階層の指定入力に基づいて、リソースの状態の程度である重大度を予め定められた評価基準に基づいて算出し、この重大度の程度に基づいて、マーカーの表示形態とノードの表示整列順序を変更して表示させている。

従って、トポロジマップの全体を把握しつつ、重大度が大きいリソースに優先的に注目することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…トポロジマップ提示システム １００…クライアント １１０…ＵＩ部（ユーザインタフェース装置） １１５…表示画面 １２０…表示処理部（表示処理装置） １２１…イベント分析処理部 １２２…トポロジ表示構成計算処理部 １２３…ノード展開変更内容計算処理 １２４…階層グループ化変更内容計算処理 １２５…ノードグループ化変更内容計算処理 １２６…トポロジ再構成内容計算処理 １２８…子階層変更内容計算処理 １２９…子階層変更内容計算処理 １３０…トポロジ表示部 １４０…フィルタ入力部 １５０…Ｆｅａｔｕｒｅセレクタ １６０…Ｖｉｅｗセレクタ ２００…トポロジ構成管理サーバ（管理サーバ） ２０１…トポロジデータ生成処理部 ２０２…クエリ生成処理 ３００…管理対象リソース群 ４００…ネットワーク

Claims (15)

1. 相互に関連を有する複数のリソースの構成情報及び状態情報を有する管理サーバと、
   前記管理サーバが有する前記構成情報及び前記状態情報に基づいて、前記リソースをノードとし、さらに、前記リソース間の関連に基づいて前記ノード間を結線したトポロジマップをユーザインタフェース装置に表示させる表示処理装置と、
   前記トポロジマップを表示画面に表示する前記ユーザインタフェース装置と
   を有するトポロジマップ提示システムであって、
   前記トポロジマップは、前記ノードを前記リソースの種類毎に定められた前記表示画面上の高さに階層表示したものであり、
   前記ユーザインタフェース装置は基準となる前記階層の指定入力を受け入れ、
   前記表示処理装置は、前記指定入力により指定された前記階層に含まれる少なくとも一つの前記ノードから、このノードに関連する前記ノードが前記表示画面の上下方向に向かって表示された前記トポロジマップを前記表示画面に表示させる
   ことを特徴とするトポロジマップ提示システム。
2. 前記トポロジマップは、前記リソースの状態を示すマーカーを前記ノードの負荷情報としてさらに表示したものであり、
   前記ユーザインタフェース装置は前記トポロジマップに基づく検討の観点の選択入力を受け入れ、
   前記表示処理装置は、前記選択入力及び前記指定入力に基づいて、前記リソースの状態の程度である重大度を予め定められた評価基準に基づいて算出し、この重大度の程度に基づいて、前記マーカーの表示形態と前記ノードの表示整列順序を変更して表示させる
   ことを特徴とする請求項１に記載のトポロジマップ提示システム。
3. 前記選択入力は、将来時点での前記リソースの性能不足を予防することを目的とするキャパシティプランニングであり、
   前記指定入力は、前記リソースがアプリケーションであるときの前記階層であり、
   前記評価基準は、前記階層が前記アプリケーションであるときは将来時点での前記リソースの応答時間予測であり、前記階層がサーバであるときは将来時点での前記リソースの性能異常判定の閾値を超過した継続時間である
   ことを特徴とする請求項２に記載のトポロジマップ提示システム。
4. 前記選択入力は、将来時点での前記リソースの性能不足を予防することを目的とするキャパシティプランニングであり、
   前記指定入力は、前記リソースがサーバであるときの前記階層であり、
   前記評価基準は、前記階層が前記サーバであるときは前記リソースの性能異常判定の閾値を超過するまでの残時間及び前記サーバを構成する要素の性能値の大きさであり、前記階層がアプリケーションであるときは将来時点での前記リソースの応答時間予測である
   ことを特徴とする請求項２に記載のトポロジマップ提示システム。
5. 前記ユーザインタフェース装置は、複数の前記ノードをグループ化し、またはグループ化された前記ノードを展開する操作入力をさらに受け入れ、
   前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは初期化動作を行うことにより前記トポロジマップを更新する際に、前記表示画面中の所定の領域を表示領域とし、この表示領域の内部に前記重大度が上位の前記ノードが所定個数含まれるように前記ノードの表示を省略してグループ化した前記トポロジマップを前記ユーザインタフェース装置に表示させる
   ことを特徴とする請求項２に記載のトポロジマップ提示システム。
6. 前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは前記初期化動作を行うことにより前記トポロジマップを更新する際に、前記表示領域の内部にグループ化された前記ノードが所定比率を下回るように前記ノードの表示を省略してグループ化した前記トポロジマップを前記ユーザインタフェース装置に表示させる
   ことを特徴とする請求項５に記載のトポロジマップ提示システム。
7. 前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは前記初期化動作を行うことにより前記トポロジマップを更新する際に、前記管理サーバに対して前記トポロジマップの更新に必要なデータの取得を要求し、
   前記管理サーバは、前記表示処理装置からのデータ取得要求があったら、このデータ取得要求に基づいてデータ取得範囲の異なる複数のデータ取得クエリを生成し、前記データ取得クエリに基づいて取得された前記データに基づいて前記表示処理装置が前記トポロジマップを更新した際のこのトポロジマップの情報量低下量を算出し、この情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出する
   ことを特徴とする請求項５に記載のトポロジマップ提示システム。
8. 前記管理サーバは、複数の前記データ取得クエリの実行時間を見積もり、前記表示処理装置へ前記データを送出する目標応答時間内に終了されると予想されかつ前記情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出する
   ことを特徴とする請求項７に記載のトポロジマップ提示システム。
9. 前記管理サーバは、前記情報量低下量が低い順に前記データ取得クエリを実行し、前記目標応答時間が経過したらそれ以降の前記データ取得クエリの実行を行わない
   ことを特徴とする請求項８に記載のトポロジマップ提示システム。
10. 前記情報量低下量は、前記データ取得要求の対象である前記階層と前記指定入力に対応する前記階層との前記表示画面中での距離が増加するほど増加する値である
    ことを特徴とする請求項７に記載のトポロジマップ提示システム。
11. 前記情報量低下量は、前記データ取得要求の対象である前記ノードと前記表示領域の左右方向端部との間の距離が増加するほど増加する値である
    ことを特徴とする請求項７に記載のトポロジマップ提示システム。
12. 前記表示処理装置は、
    前記ユーザインタフェース装置が受け入れた入力に基づいて前記トポロジマップの構造の変化の内容と、前記管理サーバに送出する前記データ取得要求とを特定するイベント分析処理部と、
    前記管理サーバから送出された前記データに基づいて前記ノードの表示を省略してグループ化するノードの範囲及び前記表示領域における前記ノードの表示位置を算出するトポロジ表示構成計算処理部と
    を有する請求項７に記載のトポロジマップ提示システム。
13. 前記管理サーバは、前記データ取得要求に基づいて複数の前記データ取得クエリを生成し、前記情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出するトポロジデータ生成処理部を有することを特徴とする請求項１２に記載のトポロジマップ提示システム。
14. 相互に関連を有する複数のリソースの構成情報及び状態情報を有する管理サーバと、表示画面を有するユーザインタフェース装置と、表示処理装置とを有するトポロジマップ提示システムにより実行されるトポロジマップ提示方法であって、
    前記管理サーバが有する前記構成情報及び前記状態情報に基づいて、前記リソースをノードとして前記リソース間の関連に基づいて前記ノード間を結線し、さらに、前記ノードを前記リソースの種類毎に定められた前記表示画面上の高さに階層表示したトポロジマップを前記表示画面に表示するトポロジマップ表示工程と、
    基準となる前記階層の指定入力を受け入れる階層指定入力工程とを有し、
    さらに、前記トポロジマップ表示工程は、前記指定入力により指定された前記階層に含まれる少なくとも一つの前記ノードから、このノードに関連する前記ノードが前記表示画面の上下方向に向かって表示された前記トポロジマップを前記表示画面に表示する工程を有する
    ことを特徴とするトポロジマップ提示方法。
15. 表示画面を有するユーザインタフェース装置に接続されたコンピュータにより実行されるコンピュータプログラムであって、
    管理サーバが有する、相互に関連を有する複数のリソースの構成情報及び状態情報に基づいて、前記リソースをノードとして前記リソース間の関連に基づいて前記ノード間を結線し、さらに、前記ノードを前記リソースの種類毎に定められた前記表示画面上の高さに階層表示したトポロジマップを前記表示画面に表示するトポロジマップ表示機能と、
    基準となる前記階層の指定入力を受け入れる階層指定入力機能とを実現させ、
    さらに、前記トポロジマップ表示機能は、前記指定入力により指定された前記階層に含まれる少なくとも一つの前記ノードから、このノードに関連する前記ノードが前記表示画面の上下方向に向かって表示された前記トポロジマップを前記表示画面に表示する機能を有する
    ことを特徴とするコンピュータプログラム。

Images