図面 (/)

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

出願人 株式会社日立製作所
発明者 鈴木克典林真一
出願日 2019年4月22日 (1年9ヶ月経過) 出願番号 2019-081215
公開日 2020年10月29日 (3ヶ月経過) 公開番号 2020-177581
状態 未査定
技術分野 計算機・データ通信 広域データ交換 デジタル計算機のユーザインターフェイス
主要キーワード 最低個数 性能障害 基準管 性能状態 グルーピング対象 ノード分離 計算機クラスタ トポロジデータ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年10月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

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

解決手段

トポロジマップ提示システム1は、リソースをノードとし、さらに、リソース間の関連に基づいてノード間を結線したトポロジマップをUI部110に表示させる表示処理部120と、トポロジマップを表示画面115に表示するUI部110とを有し、トポロジマップは、ノードをリソースの種類毎に定められた表示画面上の高さに階層表示したものであり、UI部110は基準となる階層の指定入力受け入れ、表示処理部は、指定入力により指定された階層に含まれる少なくとも一つのノードから、このノードに関連するノードが表示画面の上下方向に向かって表示されたトポロジマップを表示画面に表示させる。

概要

背景

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

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

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

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

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

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

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

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

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

概要

リソース数が増加した場合であっても、観点や着目リソースを変えつつITシステム全体の状態を容易に俯瞰、把握することを可能にする。トポロジマップ提示システム1は、リソースをノードとし、さらに、リソース間の関連に基づいてノード間を結線したトポロジマップをUI部110に表示させる表示処理部120と、トポロジマップを表示画面115に表示するUI部110とを有し、トポロジマップは、ノードをリソースの種類毎に定められた表示画面上の高さに階層表示したものであり、UI部110は基準となる階層の指定入力受け入れ、表示処理部は、指定入力により指定された階層に含まれる少なくとも一つのノードから、このノードに関連するノードが表示画面の上下方向に向かって表示されたトポロジマップを表示画面に表示させる。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記トポロジマップは、前記リソースの状態を示すマーカーを前記ノードの負荷情報としてさらに表示したものであり、前記ユーザインタフェース装置は前記トポロジマップに基づく検討の観点の選択入力を受け入れ、前記表示処理装置は、前記選択入力及び前記指定入力に基づいて、前記リソースの状態の程度である重大度を予め定められた評価基準に基づいて算出し、この重大度の程度に基づいて、前記マーカーの表示形態と前記ノードの表示整列順序を変更して表示させることを特徴とする請求項1に記載のトポロジマップ提示システム。

請求項3

前記選択入力は、将来時点での前記リソースの性能不足を予防することを目的とするキャパシティプランニングであり、前記指定入力は、前記リソースがアプリケーションであるときの前記階層であり、前記評価基準は、前記階層が前記アプリケーションであるときは将来時点での前記リソースの応答時間予測であり、前記階層がサーバであるときは将来時点での前記リソースの性能異常判定の閾値超過した継続時間であることを特徴とする請求項2に記載のトポロジマップ提示システム。

請求項4

前記選択入力は、将来時点での前記リソースの性能不足を予防することを目的とするキャパシティプランニングであり、前記指定入力は、前記リソースがサーバであるときの前記階層であり、前記評価基準は、前記階層が前記サーバであるときは前記リソースの性能異常判定の閾値を超過するまでの残時間及び前記サーバを構成する要素の性能値の大きさであり、前記階層がアプリケーションであるときは将来時点での前記リソースの応答時間予測であることを特徴とする請求項2に記載のトポロジマップ提示システム。

請求項5

前記ユーザインタフェース装置は、複数の前記ノードをグループ化し、またはグループ化された前記ノードを展開する操作入力をさらに受け入れ、前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは初期化動作を行うことにより前記トポロジマップを更新する際に、前記表示画面中の所定の領域を表示領域とし、この表示領域の内部に前記重大度が上位の前記ノードが所定個数含まれるように前記ノードの表示を省略してグループ化した前記トポロジマップを前記ユーザインタフェース装置に表示させることを特徴とする請求項2に記載のトポロジマップ提示システム。

請求項6

前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは前記初期化動作を行うことにより前記トポロジマップを更新する際に、前記表示領域の内部にグループ化された前記ノードが所定比率を下回るように前記ノードの表示を省略してグループ化した前記トポロジマップを前記ユーザインタフェース装置に表示させることを特徴とする請求項5に記載のトポロジマップ提示システム。

請求項7

前記表示処理装置は、前記ユーザインタフェース装置が前記指定入力、前記選択入力、または前記操作入力を受け入れること、あるいは前記初期化動作を行うことにより前記トポロジマップを更新する際に、前記管理サーバに対して前記トポロジマップの更新に必要なデータの取得を要求し、前記管理サーバは、前記表示処理装置からのデータ取得要求があったら、このデータ取得要求に基づいてデータ取得範囲の異なる複数のデータ取得クエリを生成し、前記データ取得クエリに基づいて取得された前記データに基づいて前記表示処理装置が前記トポロジマップを更新した際のこのトポロジマップの情報量低下量を算出し、この情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出することを特徴とする請求項5に記載のトポロジマップ提示システム。

請求項8

前記管理サーバは、複数の前記データ取得クエリの実行時間を見積もり、前記表示処理装置へ前記データを送出する目標応答時間内に終了されると予想されかつ前記情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出することを特徴とする請求項7に記載のトポロジマップ提示システム。

請求項9

前記管理サーバは、前記情報量低下量が低い順に前記データ取得クエリを実行し、前記目標応答時間が経過したらそれ以降の前記データ取得クエリの実行を行わないことを特徴とする請求項8に記載のトポロジマップ提示システム。

請求項10

前記情報量低下量は、前記データ取得要求の対象である前記階層と前記指定入力に対応する前記階層との前記表示画面中での距離が増加するほど増加する値であることを特徴とする請求項7に記載のトポロジマップ提示システム。

請求項11

前記情報量低下量は、前記データ取得要求の対象である前記ノードと前記表示領域の左右方向端部との間の距離が増加するほど増加する値であることを特徴とする請求項7に記載のトポロジマップ提示システム。

請求項12

前記表示処理装置は、前記ユーザインタフェース装置が受け入れた入力に基づいて前記トポロジマップの構造の変化の内容と、前記管理サーバに送出する前記データ取得要求とを特定するイベント分析処理部と、前記管理サーバから送出された前記データに基づいて前記ノードの表示を省略してグループ化するノードの範囲及び前記表示領域における前記ノードの表示位置を算出するトポロジ表示構成計算処理部とを有する請求項7に記載のトポロジマップ提示システム。

請求項13

前記管理サーバは、前記データ取得要求に基づいて複数の前記データ取得クエリを生成し、前記情報量低下量が最低となる前記データ取得クエリを実行して前記表示処理装置に前記データを送出するトポロジデータ生成処理部を有することを特徴とする請求項12に記載のトポロジマップ提示システム。

請求項14

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

請求項15

表示画面を有するユーザインタフェース装置に接続されたコンピュータにより実行されるコンピュータプログラムであって、管理サーバが有する、相互に関連を有する複数のリソースの構成情報及び状態情報に基づいて、前記リソースをノードとして前記リソース間の関連に基づいて前記ノード間を結線し、さらに、前記ノードを前記リソースの種類毎に定められた前記表示画面上の高さに階層表示したトポロジマップを前記表示画面に表示するトポロジマップ表示機能と、基準となる前記階層の指定入力を受け入れる階層指定入力機能とを実現させ、さらに、前記トポロジマップ表示機能は、前記指定入力により指定された前記階層に含まれる少なくとも一つの前記ノードから、このノードに関連する前記ノードが前記表示画面の上下方向に向かって表示された前記トポロジマップを前記表示画面に表示する機能を有することを特徴とするコンピュータプログラム。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

先行技術

0011

国際公開第2016/103421号

発明が解決しようとする課題

0012

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

0013

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

0014

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

0015

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

課題を解決するための手段

0016

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

発明の効果

0017

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

図面の簡単な説明

0018

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

0019

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

0020

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

0021

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

0022

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

0023

表示画面115は、トポロジマップを表示するトポロジ表示部130、トポロジマップの表示設定を入力するフィルタ入力部140、Featureセレクタ150、及びViewセレクタ160を有する。

0024

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

0025

Featureセレクタ150は、例えば"Perforamce Capacity"や"Cost"等、業務内容、目的に関連してユーザがリソースの状態を確認する際の観点(Feature)を選択するセレクタである。

0026

Viewセレクタ160は、例えば"Application"や"Storage"等、ユーザが特に着目して詳細を確認したいリソースであり、関連を辿る際に起点となるリソースの種類を選択するセレクタである。

0027

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

0028

例えば、図1内の表示画面(操作前)115aは、BUからストレージまでの各リソースをノードとするツリーを表示している。また、表示画面(操作後)115bは、Viewセレクタの設定値を"Storage"に変更する操作を行った後のツリーを表示している。ツリーを構成するノードは一個のリソース、または複数個のリソースのグループを表現している。トポロジマップを構成するノードの詳細については図2を用いて後述する。

0029

各ノードにはリソースの状態を示すマーカーが表示される。マーカーは、Featureセレクタ150で選択された観点において、リソースの状態(以降、状態の大きさを「重大度」として説明することがある。)を表示するものである。例えば、表示画面(操作前)115aは、現在のアプリケーションの性能状態を確認するために、Featureセレクタ150に"Performace"の値を設定した場合であり、アプリケーションであれば性能を計測する指標、例えばレスポンスタイムが異常判定閾値を超えた状態を黒塗りの丸、警告閾値を超えた状態を斜線の丸、正常な状態を白塗りの丸として表現している(以降、この3段階の状態をRAG(Red,Amber,Greenの各状態の集合略字)と記す)。なお、表現形式は一例であって、例えば赤、黄、緑などの色を用いても良い。

0030

表示画面(操作前)115aでは、Viewセレクタ160には"Application"が設定されているため、各アプリケーションのノードから上下の階層に向かって関連するリソースが辿られ、ツリーが構築されている。例えば、GUI(操作前)115aでは、"App1"は"VM1"と"VM2"に、"VM1"は"Cluster1"に、"Cluster1"は"Fabric1"に関連することが表現されている。

0031

"Fabric1"ノードは"Cluster1"と"Cluster2"の両方に関連するが、関連を辿る方向が"Application"から上下への方向であるため、"Cluster1"と"Cluster2"の下方に重複して表示されている。そのため、性能に関して異常がみられる"App1"について、エッジを辿ることで関連するリソースを辿り、マーカーの状態を確認することで各リソースの性能観点での状態を把握することができる。例えば、"App1"に対して同時に関連する"Storage2"の性能も異常状態であり、"App1"の性能低下の原因と推定することができる。

0032

仮に"Storage2"に実際に問題が発生していた場合、次にユーザは影響の波及する範囲を確認するが、図1ではそのためにViewセレクタ160で"Storage"を選択し、フィルタ入力部140に"Storage2"を入力する操作を行った場合について例示している。表示画面(操作後)115bでは、Viewセレクタ160に"Storage"が設定されているため、"Storage2"のノードから上下の階層に向かって関連するリソースが辿られるように、ツリーが再構築されている。これにより、"App3"も警告閾値超過の状態であることが分かる。

0033

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

0034

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

0035

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

0036

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

0037

図2においてレベルC1353に示すノード群は、個々のリソースを表現するノードであり、最も粒度の細かい単位のノードである。Country1331、City1332、DC1333は、それぞれ直下のApplication1335が動作する国、都市データセンタを表現している。BU1334はビジネスを推進する各組織(Business Unit)を、Application1335はアプリケーションの実体であるソフトウェアを、VM Group1336はVM(Virtual Matchine)群を、Server Cluster1337は物理サーバ群を、Fabric1338はFC(Fibre Channel)等のSAN(Storage Area Network)を構成する物理スイッチ群を、Storage1340はストレージ装置を表現している。また、Tier1339はストレージが提供するボリュームの性能をクラス分けする、サービスクラスを表現している。具体的には、"Gold Tier"=最大10,000IOPSが保証される等、ボリュームに関するSLA(Service Level Agreement:サービス水準合意)が定義されたものであり、Tier1339は実際には特定のSLAを約束しているボリューム群に相当する。

0038

図2においてレベルB1352に示すノード群は、レベルC1353に示す各リソースに関して、それぞれ同一のリソース種類の複数ノードグルーピングした場合のノードを表現している。実施形態におけるトポロジマップでは、これらレベルB1352に示されるノードは、レベルC1353に示される対応するリソース種類のノードと、表示画面上で同じ高さ(「階層」)に表示される。また、便宜上、以降の説明では、階層の名前として当該階層に含まれるリソース種類に対応するレベルC1353に示す各ノードの名前("Application"、"City"等)を用いる。

0039

図2においてレベルA1351に示すノード群は、複数のリソース種類にわたり、レベルB及びレベルCに属するノード集合をグルーピングしたノードを表現している。Locations1301は、位置に関する情報を表現するCountry階層、City階層、DC階層のノード群をグルーピングしたノードである。BUs & Applications1352は、ビジネス上の関心がもたれる単位であるBU階層、Application階層のノード群をグルーピングしたノードである。IT Infrastructure1353は、ITインフラを構成するリソースであるVM Group階層、Server Cluster階層、Fabric階層、Tier階層、Storage階層のノード群をグルーピングしたノードである。便宜上、以降の説明ではレベルA1351、レベルB1352に示すような複数のノード群をグルーピングしたノードのことを、グループノードと呼ぶ。

0040

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

0041

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

0042

また、図2に示したリソース間の接続関係は一例であって、形態を限定するものではない。例えば、アプリケーションがVM上でなく、直接サーバ上で実行されている場合にはApplication1335とServer Cluster1337が直接接続されるなど、階層が飛ばされる場合があってもよい。また、アプリケーションがコンテナサーバレスサービス、SaaSサービス、PaaSサービスの組み合わせで構成されている場合もある。例えばこの場合には、コンテナや、パブリッククラウドサービスを表現するノードが、図2に示したノードと組み合わされて表示されても良い。

0043

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

0044

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

0045

演算素子は、例えば、各種情報処理が可能なCPU(Central Processing Unit)、FPGA(Field−Programmable Gate Array)等である。また、記憶媒体は、例えばHDD(Hard Disk Drive)などの磁気記憶媒体、RAM(Random Access Memory)、ROM(Read Only Memory)、SSD(Solid State Drive)などの半導体記憶媒体等を有する。また、DVD(Digital Versatile Disk)等の光ディスク及び光ディスクドライブの組み合わせも記憶媒体として用いられる。その他、磁気テープメディアなどの公知の記憶媒体も記憶媒体として用いられる。

0046

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

0047

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

0048

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

0049

表示処理部120は、イベント分析処理部121と、トポロジ表示構成計算処理部122と、それらの処理で用いられるノードデータ管理テーブルT100と、グループノードデータ管理テーブルT110と、階層展開状態管理テーブルT120と、トポロジ設定状態管理テーブルT130と、ノード状態変化定義テーブルT140と、階層定義テーブルT150と、基準管理テーブルT160と、要求項目管理テーブルT170と、トポロジデータT180とを有する。

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

ノードデータ管理テーブルT100は、セッションIDT1001と、ノードIDT1002と、ノード名T1003と、関連ノードIDT1004と、グループフラグT1005と、リソースIDT1006と、リソース名T1007と、リソース種類T1008と、各種の状態情報を含む欄とを有する。

0057

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

0058

ノードIDT1002はノードを識別するためのIDであり、ノード名T1003はUI部110に表示されるノードの名前である。関連ノードIDT1004は、UI部110上で当該ノードの下方向に接続されるノードのIDを保持する。グループフラグT1005は、当該ノードがグループノードであるか、否かを保持する欄である。

0059

リソースIDT1006は、ノードが対応するリソースのIDであり、後述するリソースデータ管理テーブルT210のリソースIDT2101に対応する。また、当該ノードがグループの場合は対応するリソースが無いことを示す'−'が格納される。リソース種類T1008は、リソースの種類を表す情報を保持する欄であり、図2に示すレベルC1353の階層名に対応する。

0060

応答時間T1009からMemory(GB)T1018までは、ノードが対応するリソースの性能等の状態情報の例である。応答時間T1009はアプリケーションのAPI応答時間であり、利益T1010は当該アプリケーションが寄与する利益である。CPU%(Now)T1011、Memory%(Now)T1012は、現時点でのCPU使用率メモリ使用率である。

0061

CPU%(6 Month After)T1013、Memory%(6 Month After)T1014は、6か月後でのCPU使用率とメモリ使用率の予測である。

0062

閾値超過継続時間(6 Month Ago)T1015は、CPU使用率、メモリ使用率等の性能値予測が、異常判定閾値を超過してからの6か月後時点での経過時間である。閾値超過残時間T1016は、CPU使用率、メモリ使用率等の性能値が異常判定閾値を超過するまでの予測残時間である。

0063

CPU(GHz)T1017、Memory(GB)T1117はそれぞれ、VM GroupやServer Clusterに割り当てられているCPUリソースメモリリソースの総量である。

0064

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

0065

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

0066

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

0067

グループノードデータ管理テーブルT110は、セッションIDT1101と、ノードIDT1102と、メンバノードIDT1103と、条件T1104と、全部取得済みフラグT1105とを有する。

0068

セッションIDT1101は、図4に示したノードデータ管理テーブルT100のセッションIDT1001と同じ内容である。ノードIDT1102はグループノードのIDであり、メンバノードIDT1103はグループに含まれるノードのIDである。これらのIDは、ノードデータ管理テーブルT100のノードIDT1002欄に対応する。

0069

条件T1104は、グルーピングの条件を保持する欄である。図5に示す例では、SQL類似の表現で条件式の集合を示している。例えば、"Select Application"で、リソース種類がApplicationであるノード集合であることを、"Whereノード名=Group1"で、ノード名が"Group1"のノードへの関連が関連ノードIDT1004に含まれるノード集合であることを、"Ordered by [Performance]"で、Featureが"Performance"であるときの基準で整列することを、"Offset 3"で整列後3番目以降のノードの集合であることを示している。

0070

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

0071

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

0072

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

0073

階層展開状態管理テーブルT120は、セッションIDT1201と、階層T1202と、状態T1203とを有する。

0074

セッションIDT1201は、図4に示したノードデータ管理テーブルT100のセッションIDT1001と同じ内容である。階層T1202はUI部110に表示されうる階層の名前(本実施例では図2に示すレベルA1351とレベルC1353のノード名)である。また、状態T1203には、階層単位でグループ化されておらず、階層に属す各ノードが表示されている状態("Open")、階層単位でグループ化されているか、もしくは複数階層がまとめてグループ化されている状態("Close")の値が格納される。

0075

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

0076

トポロジ設定状態管理テーブルT130は、トポロジマップの設定値(フィルタ、View、Feature)の値を保持するテーブルである。

0077

トポロジ設定状態管理テーブルT130は、セッションIDT1301と、View階層名T1302と、FeatureT1303と、フィルタT1304とを有する。

0078

セッションIDT1201は、図4に示したノードデータ管理テーブルT100のセッションIDT1001と同じ内容である。View階層名T1302の値は、階層定義テーブルT150の階層名T1501欄の値に対応し、FeatureT1303の値は、基準管理テーブルT160のFeatureT1601欄の値に対応する。また、フィルタT1304の値は、ノードデータ管理テーブルT100のノード名T1003の値に対応する。

0079

図8は、本実施例に係る階層定義テーブルT150の一例を示す図である。

0080

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

0081

階層定義テーブルT150は、階層名T1501と、上位階層T1502と、下位階層T1503と、所属ノード種類T1504とを有する。

0082

上位階層T1502は、UI部110において階層名T1501に示す当該階層の上部位置に表示される階層であり、下位階層T1503はUI部110において階層名T1501に示す当該階層の下部位置に表示される階層である。

0083

所属ノード種類T1504は、グルーピングした際に階層名T1501に示す当該階層に属するノードの種類を示す。例えば、Locations階層については、Locations、Countries、Country、Cities、City、DCs、DCのノード種類が格納される。

0084

このうち、図2に示すレベルA1351の階層、例えばLocations階層が表示される場合、階層展開状態管理テーブルT120の当該行について、状態T1203欄が"Close"であるので、Country階層、City階層、DC階層は表示されない。従って、UI部110にノードを表示するためにノード位置を計算する際には、Locationsのノード種類しか使用されないが、逆にCityのノードを選択し、Locations階層の単位でノードをグルーピングする際には所属ノード種類T1504の情報を用いて、グルーピング範囲のノード種類が決定される。

0085

図9は、本実施例に係る基準管理テーブルT160の一例を示す図である。

0086

基準管理テーブルT160は、FeatureやViewの値毎に、各リソース種類のノードの重大度を計算する際に選択されるメトリックを保持しておくテーブルである。

0087

基準管理テーブルT160は、FeatureT1601と、ViewT1602と、リソース種類T1603と、メトリックT1604とを有する。

0088

FeatureT1601は、Feature Selector150に設定されうるFeatureの値であり、ViewT1602は、View Selector160に設定されうる階層名である。

0089

図9に示す例では、将来時点で性能が異常判定閾値を下回るように性能観点でのキャパシティプランニングを行う場合("Performance Capacity Planning")を示している。この時、Viewが"Application"の場合に、管理者がトポロジマップでアプリケーションに関連するITインフラを確認する目的としては、将来時点でアプリケーションの性能(応答時間)が異常判定閾値を超過する場合に、その原因となるITインフラを特定することにある。

0090

そのため、Viewが"Application"の場合に、リソース種類T1603がServer Clusterの場合には、メトリックT1604には当該Server Clusterが異常判定閾値を超過してからの経過時間が指定されている。

0091

一方で、Viewが"Server Cluster"の場合には、管理者はアプリケーションを安定的に運用するため、Server Clusterの性能が枯渇するリスクを最小化することがトポロジマップを表示する目的となる。そのため、メトリックT1604には異常判定閾値を超過するまでの残時間が指定されている。

0092

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

0093

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

0094

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

0095

要求項目管理テーブルT170は、セッションIDT1701と、要求項目IDT1702と、対象データT1703と、階層T1704と、制約条件T1705と、個数T1706と、整列順序T1707とを有する。

0096

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

0097

対象データT1703から整列順序T1707は、取得データを限定するための情報の例である。図10に示す例では、SQLの類似表現で記載している。

0098

対象データT1703は取得するデータの範囲を示す。一例として、要求項目IDT1702に示す識別IDが"1"の場合、最初から3番目以降のデータについての全項目("*, Offset 3")である。階層T1704は取得するデータの所属する階層を指定するものである。制約条件T1705は取得するデータを限定する条件である。例えば、"関連リソースID=[要求項目ID=1]"として、要求項目ID=1で取得されるデータのリソースIDT2101が、関連リソースIDT2104に指定されているリソースのデータであることを示している。

0099

個数T1706は取得するデータの個数を示す。例えば"Over 10"として最低個数を指定してもよい。整列順序T1707は、データを整列させる際の基準である。"[Performace Capacity Planning]"のように、Featureで指定された場合には、基準管理テーブルT160を参照し、対応するメトリックT1604で整列する。

0100

図14は、本実施例に係るクエリ管理テーブルT200の一例を示す図である。

0101

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

0102

クエリ管理テーブルT200は、セッションIDT2001と、要求項目IDT2002と、クエリIDT2003と、クエリT2004と、必須フラグT2005と、インパクト値T2006と、実行時間見積もりT2007とを有する。

0103

セッションIDT2001は、図4に示したノードデータ管理テーブルT100のセッションIDT1001と同じ内容である。要求項目IDT2002は、要求項目管理テーブルT170の要求項目IDT1702欄に対応する。クエリIDT2003は、対応する要求項目を満たすためのクエリ群を識別するためのIDである。クエリT2004は、個々のデータ取得クエリ(図14に示す例ではSQLの表現で示す)である。

0104

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

0105

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

0106

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

0107

リソースデータ管理テーブルT210は、リソースIDT2101と、リソース名T2102と、リソース種類T2103と、関連リソースIDT2104と、各種の状態情報を含む欄とを有する。

0108

リソースIDT2101はリソースの識別IDであり、リソース名T2102はリソースの名前である。リソース種類T2103は、リソースの種類を表す情報を保持する欄であり、図2に示すレベルC1353の階層名に対応する。関連リソースIDT2104は、UI部110の表示画面115上で当該リソースの下方向に接続されるリソースのIDを保持する。

0109

応答時間T2105からMemory(GB)T2113までは、ノードデータ管理テーブルT100の応答時間T1009からMemory(GB)T1018と同様の情報である。

0110

図16は、本実施例に係るクエリ実行履歴管理テーブルT230の一例を示す図である。

0111

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

0112

クエリ実行履歴管理テーブルT230は、対象データT2301と、階層T2302と、制約条件T2303と、個数T2304と、整列順序T2305と、テーブル行数T2306と、実行時間T2307とを有する。

0113

対象データT2301から整列順序T2305は、それぞれ要求項目管理テーブルT170の対象データT1703から整列順序T1707に対応し、リソースデータ管理テーブルT210からデータを取得する際に、取得データを限定する情報である。

0114

例えば、クエリ実行履歴管理テーブルT230の2行目は、SQLでは"Select * fromリソースデータ管理テーブルT210 whereリソース種別=VM Group ordered by [Performance] limit 10"に対応する。テーブル行数T2306は、クエリ実行時のリソースデータ管理テーブルT210の行数である。実行時間T2307は、クエリ実行に実際に要した時間である。

0115

図17は、本実施例に係るトポロジデータ管理テーブルT240の一例を示す図である。

0116

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

0117

トポロジデータ管理テーブルT240は、セッションIDT2401と、トポロジデータT2402と、View階層名T2403と、FeatureT2404と、フィルタT2405と、更新時刻T2406とを有する。

0118

セッションIDT2401は、図4に示したノードデータ管理テーブルT100のセッションIDT1001と同じ内容である。トポロジデータT2402は、トポロジマップの構成を示すデータであり、例えば、後述する図11に示すようなJSON(JavaScript(登録商標) Object Notation)形式のデータである。View階層名T2403からフィルタT2405は、それぞれトポロジ設定状態管理テーブルのView階層名T1302からフィルタT1304に対応する。

0119

<実施形態のトポロジマップ提示システムの動作>
図18は、本実施例に係るトポロジマップ提示システム1の動作の一例を示すシーケンス図である。図18のシーケンス図は、トポロジマップをUI部110に表示するまでの処理シーケンスの概要を示したものである。

0120

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

0121

ユーザがUI部110で初めてトポロジマップを表示した場合(S1000)、UI部110は表示処理部120に対してトポロジマップの初期表示要求を行い(S1010)、それに応じて表示処理部120はトポロジ構成管理サーバ200に対して初期トポロジデータを要求する(S1020)。

0122

トポロジ構成管理サーバ200は、初期トポロジデータの要求を受けると、トポロジデータ生成処理部201が初期トポロジデータを生成する。そして、トポロジ構成管理サーバ200は、生成したトポロジデータとセッションIDを表示処理部120に返却する(S1030)。表示処理部120は、受領したトポロジデータについて各ノードの表示座標等を計算し、表示画面115の描画処理を行う(S1040)。

0123

S1050からS1090は、トポロジマップに対してユーザの設定変更操作が行われた場合の処理シーケンスである。ユーザの設定変更操作とは、例えばグループノードの展開操作、階層単位でノードをグルーピングする操作、RAG単位でノードをグルーピングする操作、Viewを変更する操作、Featureを変更する操作がある。

0124

ユーザ500が操作を行うと(S1050)、UI部110は操作の内容や、操作が行われた対象のノードを特定し、表示処理部120に対して操作イベントの発生を通知する(S1060)。表示処理部120は、操作イベント発生が通知されると、トポロジマップの形態を変化させるためにまずはイベント分析処理部121が処理を実行する。これにより、要求する必要のあるデータを特定し、トポロジ構成管理サーバ200にトポロジデータ取得の要求を送信する(S1070)。

0125

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

0126

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

0127

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

0128

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

0129

図28の左部はノード展開操作前のトポロジマップ1360の一例である。本例では、ViewにServer Clusterが設定されており、Server Clusterを起点としたツリー構造となっている。

0130

"Server1"1366に対して、関連するVM Groupとして"VM1"1364と"Group1"1365がある。また"VM1"に関連するApplicationとして"App1"1361と"App2"1362が、"Group1"1365に関連するGroupとして"Group2"1363がある。

0131

図28右部は"Group1"1365を展開する操作が行われた際のトポロジマップ1370の一例である。

0132

"Group1"1365は展開され、個々のノードが表示されることとなる。そのために必要な、"Group1"に含まれるノード群のデータ取得要求が"Request1"1371で示されている範囲である。また、同時に"Group2"1363に関しても、親となるノードが詳細化されるため、"Group1"を構成する各ノードに関連するApplicationのノードを表示する必要がある。これらの"Request1"の結果である各ノードに関連するApplicationのノード群のデータ取得要求が"Request2"で示される範囲である。

0133

図28に示すトポロジマップのトポロジデータT180の例(JSON形式)を図11図12に示す。

0134

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

0135

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

0136

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

0137

図11に示すトポロジデータT180Aは、階層名をキーとし、「ノード情報」の配列を値とする複数のメンバが含まれるオブジェクトである。例えばトポロジデータT180Aでは、"Server Cluster"階層のノード群を示すメンバT1810Aと、"VM Group"階層のノード群を示すメンバT1820Aと、"Application"階層のノード群を示すメンバT1830Aが図示されている。

0138

「ノード情報」は、ノード名T1801と、RAG状態T1802と、Groupノードであるかを示すフラグT1803と、当該ノードに関連するノードの名前(Children)T1804とを有する。

0139

RAG状態T1802の値は、例えば"r"(Red)、"a"(Amber)、"g"(Green)である。また、Viewの値によって、UI部110に表示されるトポロジマップ上でノード間の関連を辿ることができる方向が変化するため、ChildrenT1804の値は、Viewの値によって決まる。例えば、Viewとして指定されている階層のノードであれば、上下の両方向のノードに向かって関連を辿ることができるため、ChildrenT1804には上下の階層に属するノードの名前が含まれる。一方で、葉に位置するノードの場合には関連を辿る先のノードが無いため、ChildrenT1804自体が存在しないか、空の配列を値として持つ。以降の説明では簡単のため、関連を辿る元となるノードを親ノード、関連を辿る先のノードを子ノードと記載する。

0140

図12に示すトポロジデータT180Bは、"Group2"1365を展開した際に、トポロジ構成管理サーバ200にデータ取得要求を行う際にトポロジ構成管理サーバ200に渡されるトポロジデータである。

0141

そのため、トポロジマップとして必要なノードのデータはすべて埋められていない。その代わりに例えば、"VM Group"のノード群(T1820B)にデータ取得要求項目"Request2"を示す仮ノードが、"Application"のノード群(T1830B)にデータ取得要求項目"Request2"を示す仮ノードが埋められている。

0142

また、各ノードには"Request1""Request2"を含む形でノード間の関連を示すChildrenT1804の値が埋められている。これにより、のちにトポロジ構成管理サーバ200からデータを取得した後、"Request1""Request2"の仮ノードを実ノードで置き換えることで、トポロジマップデータを生成することができる。

0143

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

0144

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

0145

イベント分析処理部121は、まず受信した操作イベントに応じてトポロジデータの変更内容計算処理を行う。まず、イベント分析処理部121は、操作イベントがノード展開操作であるか否かを判定し(S2000)、ノード展開操作であると判定したら(S2000においてYes)、ノード展開変更内容計算処理123を実行する。

0146

一方、ノード展開操作でないと判定したら(S2000においてNo)、次に、イベント分析処理部121は、操作イベントが階層の単位でノード群をグルーピングする操作であるか否かを判定する(S2010)。そして、階層の単位でノード群をグルーピングする操作であると判定したら(S2010においてYes)、階層グループ化変更内容計算処理124を実行する。

0147

一方、階層の単位でノード群をグルーピングする操作でないと判定したら(S2010においてNo)、次に、イベント分析処理部121は、操作イベントが階層以外の単位でノード群をグルーピングする操作であるか否かを判定する(S2020)。そして、操作イベントが階層以外の単位でノード群をグルーピングする操作であると判定したら(S2020においてYes)、ノードグループ化変更内容計算処理125を実行する。一方、操作イベントが階層以外の単位でノード群をグルーピングする操作でないと判定したら(S2020においてNo)、イベント分析処理部121はトポロジ再構成内容計算処理126を実行する。

0148

各トポロジデータの変更内容計算処理(124〜128)を実行後、イベント分析処理部121は、操作イベントの内容と、操作イベント後のトポロジデータと、必要な場合にはデータ取得要求とをトポロジ構成管理サーバ200に送信する(S2050)。

0149

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

0150

ノード展開変更内容計算処理123では、イベント分析処理部121が操作対象のノードのIDを取得すると(S2100)、まず、トポロジデータT180から操作対象のノードを取り除く(S2110)。次に、イベント分析処理部121は、グループ展開後のノード群をトポロジデータT180に挿入する。

0151

ここで、操作されたノード種類が"Locations"、"BUs&Appliations"、"IT Infrastructures"のような、グループノードをさらにグルーピングしたグループノードである場合、ノード展開操作によって新たに表示するノードを、関連を辿って探すことは必要ない。そのため、イベント分析処理部121は、展開後のノードもグループノードであるか否かを判定し(S2120)、展開後のノードもグループノードであると判定したら(S2120においてYes)、グループノードデータ管理テーブルT110のメンバノードIDT1103を参照し、ノード展開後のノードをトポロジデータに反映させて処理を終了する(S2130)。

0152

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

0153

そこで、イベント分析処理部121は、ノード展開操作対象のグループノードを展開する(S2140〜S2160)。まず、イベント分析処理部121は、グループノードデータ管理テーブルT110のノード展開操作対象のグループノードに対応する行を参照する。

0154

この時、イベント分析処理部121は、当該行の全部取得済みフラグT1105がTrueであるか否かを判定し(S2140)、全部取得済みフラグT1105がTrueでないと判定したら(S2140においてNo)、イベント分析処理部121は、展開後のノードを表示する上で追加のデータを取得する必要があると判断する。そこで、イベント分析処理部121は条件欄T1104を参照し、同内容でデータ取得要求を作成し、要求項目管理テーブルT170に格納する(S2150)。一方、全部取得済みフラグT1105がTrueであると判定したら(S2140においてYes)、そのままS2160に進む。

0155

そして、イベント分析処理部121は、当該行のメンバノードIDT1103のノード情報と、S2150で作成した要求項目がある場合には、その要求項目内容を示す仮ノードの情報をトポロジデータに反映させる(S2160)。

0156

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

0157

まず、イベント分析処理部121は、選択されている操作対象階層のノード群から(S2170)、操作対象グループノードの親ノードを選択し、もしくは、操作対象グループノードがView階層に属する場合は、操作対象グループノードを構成するメンバのノード群を選択する(S2180)。そして、選択した各ノードについて、子階層変更内容計算処理129を実行する。次ループ以降は、前のループで選択した各ノードの子ノードをS2180で選択する。これにより、逐次的に各ノードの子ノード群が子階層変更内容計算処理128によってトポロジデータに反映される。

0158

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

0159

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

0160

一方、対象ノードの子ノードがグループノードでないと判定したら(S2910においてNo)、イベント分析処理部121はS2900で指定されたノードの子ノード群をトポロジマップ上に表示する必要がある。そこで、イベント分析処理部121は、グループノードデータ管理テーブルT110の条件欄T1104を参照し、子ノードが属する階層に属するノード群であること、対象ノードに関連する(子ノードである)ノード群であること、Featureが同一であること、の条件を満たす行があるか否かを判断し、当該行がある場合には、メンバノードIDT1103に含まれるノードの情報をトポロジデータに反映する(S2930)。

0161

この時、S2930で条件に合うノードが無い場合、あっても当該行の全部取得済みフラグT1105がFalseの場合(S2940においてNo)、イベント分析処理部121は不足のノードのデータをトポロジ構成管理サーバ200から取得する必要がある。そのため、イベント分析処理部121はS2930で用いた条件と同内容でデータ取得要求を作成し、要求項目管理テーブルT170に格納する(S2950)。そして、イベント分析処理部121は、S2950で作成した要求項目の内容を示す仮ノードの情報をトポロジデータに反映させる(S2960)。

0162

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

0163

イベント分析処理部121は、対象となるノードと、グループとしてまとめる単位の階層を受信し、処理を始める(S2300、S2310)。例えば、図2に示すように、Applicationのノードは"Applications"や"BUs&Applications"のグループノードに纏められてもよい。このように、一つのノードに対して、グループとしてまとめる階層の単位は複数あり得るため、例えばUI部110上で、ノードを右クリック選択等することにより、グループ化の単位の階層を選択させる等の操作を行ってもよい。

0164

次に、イベント分析処理部121は、S2310で受信したグループ化単位階層について、階層定義テーブルT150を参照し、所属ノード種類T1504がすべてグループノードであるか否かを判定する(S2320)。すべてグループノードであると判定したら(S2320においてYes)、グループ化後のグループノードは、展開時には既定のグループノードに展開される振る舞い(Locationsが展開されると、Contriesと、Citiesと、DCsに展開される、等)が期待されることから、イベント分析処理部121は、グループノードデータ管理テーブルT110に初期値として設定されるグループノードのノードIDT1102の値を取得する(S2330)。

0165

一方、グループノードでないノードが含まれていると判定したら(S2320においてNo)、イベント分析処理部121はグループノードデータ管理テーブルT110を参照し、条件欄T1104がグループ化対象のノード群である条件に合致し、全部取得済みフラグT1105がTrueの行が存在するか否かを判定する。存在する場合には、重複する情報を保持することを避けるために、当該行のノードIDT1102の値を取得する。存在しない場合には、新規にグループノードのノードIDを採番し、グループノードデータ管理テーブルT110に追加する(S2340)。この時、対象の階層のノードを全てクライアント100が保持しているとは限らないため、全部取得済みフラグT1105はFalseとする。

0166

次に、イベント分析処理部121は、グループ化する階層に所属するすべてのノードの情報をトポロジデータから取り除き(S2350)、代わりにS2330、S2340で特定したグループノードの情報をトポロジデータに反映させる(S2360)。

0167

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

0168

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

0169

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

0170

イベント分析処理部121は、対象となるノードを受信し、処理を始める(S2400)。まず、イベント分析処理部121は、対象ノードのリソース種類と性能等の各種の状態情報をノードデータ管理テーブルT100から取得し、基準管理テーブルT160を参照し、現在のFeatureに対応する基準でのRAG状態を求める(S2410)。そして、イベント分析処理部121は、グループ化対象のノード群として、トポロジデータから同リソース種類、同RAG状態のノードを選択する(S2420)。

0171

次に、イベント分析処理部121は、グループノードデータ管理テーブルT110を参照し、条件欄T1104がグループ化対象のノード群である条件に合致し、全部取得済みフラグT1105がTrueの行が存在するか否かを判定する。存在する場合には、重複する情報を保持することを避けるために、当該行のノードIDT1102の値を取得する。存在しない場合には、新規にグループノードのノードIDを採番し、グループノードデータ管理テーブルT110に追加する(S2430)。

0172

次に、イベント分析処理部121は、グループ化するノード群の情報をトポロジデータから取り除き(S2440)、代わりにS2430で特定したグループノードの情報をトポロジデータに反映させる(S2450)。

0173

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

0174

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

0175

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

0176

トポロジ再構成内容計算処理126は、Viewを変更した場合や、Featureを変更した場合、UI部110を再描画し、トポロジマップを更新した場合等にトポロジを再構成する処理である。

0177

イベント分析処理部121は、View階層名を受信し、処理を始める(S2500)。まず、イベント分析処理部121は、View階層のノードについてトポロジデータを更新する。まず、階層展開状態管理テーブルT120を参照し、View階層がOpenの状態であるか否かを判定する(S2510)。View階層がOpenの状態であると判定したら(S2510においてYes)、View階層で表示されるノードはグループノードのみで変化しないため、S2520からS2540の処理を行わずにイベント分析処理部121はS25550の処理を行う。

0178

一方、View階層がOpenの状態でないと判定したら(S2510においてNo)、イベント分析処理部121はグループノードデータ管理テーブルT110を参照し、View階層に所属するノード群であること、Featureが同一であることの条件に合致する行が存在するか否かを判定する。存在すると判定した場合は、イベント分析処理部121は、全部取得済みフラグT1105がTrueであるか否かを判断する(S2520)。全部取得済みフラグT1105がTrueでないと判定したら(S2520においてNo)、トポロジ構成管理サーバ200から追加でノードの情報を取得する必要があるため、イベント分析処理部121は、S2520の条件をもとに要求項目管理テーブルT170にデータ取得の要求を追加する(S2530)。

0179

一方、全部取得済みフラグT1105がTrueであると判定したら(S2520においてYes)、イベント分析処理部121は、グループノードデータ管理テーブルT110の当該行から、メンバノードIDT1103のノードの情報でトポロジデータを更新する。また、S2520において全部取得済みフラグT1105がTrueでないと判定したら、イベント分析処理部121は、S2530で追加したデータ取得要求に対応する仮ノードの情報でトポロジデータを更新する(S2540)。

0180

次に、イベント分析処理部121は、View階層の上下の階層に向かってサブトポロジを再構成する。すなわち、イベント分析処理部121は、各階層についてS2550からS2570、及び子階層変更内容計算処理128を実行する。これらの処理は、ノード展開変更内容計算処理123のS2170〜S2190と同様のため、詳細な説明を省く。

0181

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

0182

図13は、本実施例におけるトポロジ構成管理サーバ200に追加データを要求する際に送信されるデータT250の一例(JSON形式)を示す図である。

0183

データT250は、セッションIDT2510と、操作イベントの内容T2520と、操作対象のノード名T2530と、View階層名T2540と、Feature名T2550と、トポロジデータT2560と、ディスプレイノードT2570と、要求項目T2580とを有する。

0184

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

0185

要求項目T2580は要求項目管理テーブルT170と同様の内容である。IDT2581は要求項目IDT1702に、"TargetData"T2582は対象データT1703に、"Layer"T2583は階層T1704に、"Where"T2584は制約条件T1705に、"Limit"T2585は個数T1706に、"Order"T2586は整列順序T1707にそれぞれ対応する。

0186

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

0187

トポロジデータ生成処理部201は、クライアント100からデータT250を受信し、処理を始める(S4000)。まず、トポロジデータ生成処理部201は、受信したデータの"SessionID"T2410を参照し、トポロジデータ管理テーブルT240に当該の値が格納されているか、格納されているならばその値が有効期限内であるなどの有効な値であるか否かを判定する(S4010)。そして、判定が否定されたら(S4010においてNo)、トポロジデータ生成処理部201は、初期データとして最も広範囲でグルーピングされている単位のグループノード("Locations"、"BUs&Applications"、"ITInfrastractures")からなるトポロジデータを返却する(S4020)。これは、ユーザの多様なユースケースに対応できるトポロジマップを初期状態とするためである。

0188

一方、判定が肯定されたら(S4010においてYes)、トポロジデータ生成処理部201は、さらに"RequestSpec"T2480を参照し、データの取得要求があるか否かを判定する(S4030)。データの取得要求はないと判定したら(S4030においてNo)、トポロジデータ生成処理部201は、特にトポロジデータに変更を加えず、受信した"TopologyData"T2460をそのまま返却する(S4040)。

0189

一方、データの取得要求があったと判定したら(S4030においてYes)、トポロジデータ生成処理部201は追加をデータ取得を行い、トポロジデータを更新して返却する。

0190

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

0191

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

0192

次にトポロジデータ生成処理部201はクエリを実行してデータを取得する。すなわち、トポロジデータ生成処理部201は、インパクトの大きいクエリセットから順番に、各クエリを実行しDBからデータを取得する(S4060、S4070)。ここで、もしもトポロジデータ生成処理を実行開始してからの経過時間が目標応答時間を超過した場合、トポロジデータ生成処理部201は以降のクエリ実行をキャンセルする(S4075)。

0193

その後、トポロジデータ生成処理部201は、"TopologyData"T2460に含まれる各仮ノードを対応する取得データで置き換えることで完全なトポロジデータに更新し、クライアント100に返却する(S4080、S4090)。

0194

最後にトポロジデータ生成処理部201は、返却するトポロジデータでトポロジデータ管理テーブルを更新し処理を終了する(S4100)。

0195

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

0196

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

0197

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

0198

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

0199

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

0200

まず、トポロジデータ生成処理部201は、インパクト値を計算するための基本データして、受信したトポロジデータよりトポロジマップに表示される階層と、各階層にて表示されるノードの数を計算する(S4200)。そして、各要求項目についてS4220〜S4260を実行し、対応するクエリセットと、そのインパクトを計算する(S4210)。

0201

まず、トポロジデータ生成処理部201は対象階層のViewからの距離aを計算する(S4220)。各階層のaの値は、View階層に近い程大きい値となる。計算方法としては、例えば、以下のように対象階層のViewからの距離について、逆数をとった値等である。

0202

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

0203

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

0204

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

0205

次に、トポロジデータ生成処理部201は、データ取得範囲の異なる複数のデータ取得クエリを生成する(S4240)。クエリの生成パタンとしては、例えば以下(1)〜(4)に示すようなパタンである。
(1)要求された条件に合致するすべてのリソースについて、全情報を取得する。
(2)要求された条件に合致するリソースの内、上位10件は全情報を取得する。それ以外は、RAG状態でグループ化した際にリソース数を表示できるように、各RAG状態毎にリソース件数の情報のみを取得する。
(3)要求された条件に合致するリソースの内、上位10件は全情報を取得する。それ以外をグループ化した際にリソース数を表示できるように、リソース件数の情報も取得する。
(4)情報は取得しない。

0206

トポロジデータ生成処理部201は、指定された要求項目の値を基に、各パタンのクエリを生成する。具体的なクエリ例は、図14に示すクエリ管理テーブルT200のクエリT2004に示す通りである。また、これらの各クエリの基本インパクト値はインパクト値T2006に示すように、予め決められた値を用いてもよい。図14に示す例ではパタン(1)は要求データすべてが取得されているので、インパクト値は0となり、パタン(4)では要求データが無いため、インパクト値は100となる。パタン(2)(3)は0〜100の範囲で設定された値である。

0207

次に、トポロジデータ生成処理部201は、S4220〜S4240で計算した基本インパクト値とa、bの値を基に、各クエリのインパクト値を計算する(S4250)。

0208

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

0209

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

0210

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

0211

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

0212

トポロジ表示構成計算処理部122は、まず、View階層から上下階層へ向かって、階層毎に同一の親ノードの子ノード群は重要度が高い順番に左から整列して表示されるように、トポロジデータに含まれる各ノードについて、重要度が高い順となるようにノードを整列する(S4300)。

0213

次に、トポロジ表示構成計算処理部122は、トポロジデータの各ノードについて、UI部110上での表示座標を計算する(S4310)。座標の計算方法としては、例えばトポロジマップの初期表示であった場合には、View階層の内最も重要度が高いノードを、また、ノードへの操作が行われた場合は、操作対象のノードを、それ以外の場合には表示画面115中央に最も近いノードを基準ノードとして選択し、基準ノードの位置をもとに各ノードの座標を計算する。

0214

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

0215

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

0216

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

0217

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

0218

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

0219

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

0220

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

0221

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

0222

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

0223

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

0224

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

0225

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

実施例

0226

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

0227

1…トポロジマップ提示システム100…クライアント110…UI部(ユーザインタフェース装置) 115…表示画面 120…表示処理部(表示処理装置) 121…イベント分析処理部 122…トポロジ表示構成計算処理部 123…ノード展開変更内容計算処理124…階層グループ化変更内容計算処理 125…ノードグループ化変更内容計算処理 126…トポロジ再構成内容計算処理 128…子階層変更内容計算処理 129…子階層変更内容計算処理 130…トポロジ表示部 140…フィルタ入力部 150…Featureセレクタ160…Viewセレクタ 200…トポロジ構成管理サーバ(管理サーバ) 201…トポロジデータ生成処理部 202…クエリ生成処理 300…管理対象リソース群 400…ネットワーク

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ