情報システム障害解析のための知識グラフ構築の試み

(1)

1

情報システム障害解析のための知識グラフ構築の試み

Constructing a knowledge graph for information system trouble shooting

髙雄慎二

1_*

Shinji TAKAO

1

_{日本電信電話株式会社}

1

_{Nippon Telegraph and Telephone Corporation}

Abstract: Knowledge graphs have been getting attention because of its relevance to interpretable AI. Not

only that, they also can be useful as a knowledge sharing mean which enable non-experts to utilize experts’ knowledge. We aim to report findings from constructing a knowledge graph through eliciting experts’ knowledge and building a knowledge database. We also suggest the possibilities and issues of knowledge graph as a knowledge sharing mean.

1.

はじめに

我々は，企業グループ内の情報システム管理者からの依頼を受けて障害解析支援を行っているが，その際には，障害の根本原因対処や顧客説明のための理由説明を求められることが多い．このような要請に短期間で対応しなくてはならないことが多いため，対象ソフトウェアや過去に発生した障害について熟練した専門技術者の知識を必要としている．しかし近年，クラウド技術の普及等に伴う使用ソフトウェアの種類増加や，専門技術者の流動化等の為，従来のやり方では十分に知識を保つことが難しくなりつつある．この課題に対して，完全な自動化を直ちに行うのではなく，まずは何らかの支援システムと人間の相互作用を通して，異種ソフトウェア技術者や初心者等の非専門家も，専門家と同様の判断を行えるようにすることが必要と考えられる．そのため，知識表現としてのわかりやすさに注目し，情報システム障害解析のための専門知識をグラフ構造で表現する知識流通手段の構築を試みた． 2.

先行研究

知識グラフとは，さまざまな知識・データをグラ *連絡先：NTT OSS センタ〒108-8019 東京都港区港南 1-9-1 NTT 品川 Twins ビル 11F Email: [email protected] フ構造で整理したグラフデータベースと定義され，近年，理由説明や演繹的判断ができるAI 等との関連で注目さている[1]．機械学習やAI による判断・決定過程を説明可能にする必要性は，欧州連合のGDPR による要請[2]，米国DARPA の人間の監督下での AI の活用を目指す説明的AI (XAI) 研究プログラム[3]，総務省による「透明性の原則」及び「アカウンタビリティ（説明責任）の原則」を盛り込んだ「AI 開発ガイドライン」[4]などを通して必要性が示されていることなどから，近年研究の機運が高まっている．説明的 AI の研究の手法は幾つかあるが，その中で，より構造的・解釈可能・因果的なモデルを構築する手法(interpretable models) のひとつとして，知識グラフを位置づけることができる．ノードと，ノード間を結ぶエッジとで構成されるグラフ構造は，理解が比較的容易であるからである．ナレッジグラフチャレンジ[1] は， Resource Description Framework (RDF)で記述した知識グラフに対して，RDF の標準的クエリ言語 SPARQL 等にて推論・推定を行った．これは統計的傾向でないルールのみの知識グラフに依拠しており，高い説明性を追及した取り組みとして注目される．他方，機械学習の文脈における知識グラフは，グラフ構造を持つ確率モデル（グラフィカルモデル）として，何らかの統計的傾向を反映したものを指すことが多い．その一つとして，有向グラフで表現さ

(2)

2 れ，条件付き確率によって様々な条件化での蓋然性を示すことができるベイジアンネットワーク (BN)[5][6]は，説明可能性との関連からも注目されている[7]．BN は，1970 年代に発するエキスパートシステム/意思決定支援システムにおいて，不確実性を伴う推論を可能にすることで，医療などで活用された．BN によるモデルは明瞭に解釈可能で専門的基礎に基づく正当化が可能，かつ主観的見積と統計的データを併用できる等のメリットがある．一方，それ以前のルールのみのモデルと比較した場合に推論結果の説明が難しいことも指摘されている[8][9]． 3.

対象領域

障害は，稀に発生する予期せざる事態である．そのため，通常の運用現場での必要性を越えた専門知識を要し，かつ，解析結果を迅速かつ高い確度で提供する必要がある．これらは障害解析の事例と対象ソフトウェアの知識に精通した専門技術者により行われてきた．しかし，専門技術者の異動や退職などが発生した場合，それらの専門知識も同時に失われるリスクがある．さらに，クラウド技術の普及を背景に，システムの複雑化・大規模化が進むことで，対応が必要なソフトウェアの種類やそれらの相互依存関係も複雑化し，もともと数が限られる専門技術者の人的な努力だけでは対応が限界に達すると見込まれる．クラウド上のシステムについては，近年，自動的な障害回復機能をシステムの設計に含めることが推奨されている．しかし，それらは一時的な対症療法にとどまるので，別途，根本的原因の解明と再発防止策の策定を行わなければならない．再発防止策の決定には，しばしば組織的判断が必要であり，そのため人間が理解可能な納得性のある理由説明が必要となる．したがって，一時的な自動対処と平行して，問題の根本原因と理由の提示を行わなくてはならない．この作業について，現状では完全自動化は現実的ではなく，なんらかの支援システムにより，異種ソフトウェア技術者による多能工的対応や，非熟練技術者による適切・迅速な判断を支援することが有効と考えられる． 4.

タスク分析

4.1

原因解析と障害予兆確認

障害解析のタスクは，大きく原因解析と障害予兆確認の二つに分けることができる．原因解析は，システムの処理速度低下や処理停止など，サービスに影響する問題が発生した場合に，その原因を解明する．この場合，「画面が固まった」「エラーメッセージが表示された」等，何らかの問題事象を基点とし，ログ等のエビデンスを基に根本原因を解明する[図 1 上]．一方、障害予兆確認は，システムは機能しているが，監視対象ログが正常時とは異なる値・出力を示しているような場合，それが何らかの潜在的な問題の兆候かどうかを調査する．この場合，ログ出力情報を基点とし，サービスに影響する問題に繋がるような潜在的異常の有無を調査する[図 1 下]．もしも異常が存在する場合は，障害解析と同様に根本原因を解明する．図1 原因解析と障害予兆確認「根本原因」とは，サービス影響事象の原因となる他の事象である．図1 では模式化のために一段階としているが，実際には幾つかの事象の繋がりである．その発生有無を確認するために，関連するログ確認も行われる．以上のようなログ確認と根本原因調査の流れを模式的に図示したものが[図 2]である．図2 ログ確認と根本原因調査このように，原因解析と障害予兆確認は「原因から結果」だけでなく，「結果から（考えられうる）原因」へ遡ったり，複数の原因と結果の間を行き来しながら行う仮説の選定・検証・棄却の繰り替えしと考えられる．なお，事象の中には，ログの取得が困難等のために，ログによって直接観察されないものも存在する．その場合，他の情報からその事象が発生している可能性を推測して解析を先に進めることになる．

(3)

3 4.2

原因切り分けと影響確認

一つの事象の原因となりうる事象は，一つとは限らない．そのため，考え得る複数の原因候補のうち，もっとも可能性の高いものを仮説とし，ログ確認等で検証を行う．検証の結果，仮説が棄却された場合，残りの仮説のうち可能性の高いものに対して検証を行う．このように仮説選択と検証を繰り返し，根本原因を絞り込むことを，本タスクでは原因切り分けと呼ぶ．原因切り分けの模式図を[図 3]に示す．図3 原因切り分け図4 影響確認一方，原因切り分けとは逆に，ある事象が及ぼす影響を，原因から結果の方向へ辿る場合もある．これを影響確認と呼ぶ[図 4]．原因解析と障害予兆確認のいずれにおいても，原因切り分けおよび影響確認を，十分な結論を得られるまで繰り返すことが基本的な手順となる． 4.3

知識モデルと支援システムの要件

このような複数の因果関係のつながりに関する知識を情報システム全体としてみた場合に，ひとつのモデルを構成し得る．本節では，前節までに見たタスクの特徴から，タスクの表現に必要なモデルの要件を示す．その上で，タスクを支援するシステムに必要とされる要件を検討する． (1) モデルの要件 (1-1) 事象を，目的変数にも説明変数にもなり得るものとして表現すること． (1-2) 因果関係の方向性を表現すること． (1-3) 直接観測可能な事象と観測不可能な事象の両方を表現すること．本タスクで扱う事象は，目的変数にも説明変数にもなり得る．したがって目的変数を一つに定める必要がある決定木や回帰分析・判別分析などのモデル化手法は本タスクには適さず，複数のノード間の複雑な関係を表現できるグラフ構造が適している．なお，グラフのノードが本タスクの事象に相当し，ノードの連結関係としては，事象間の因果関係に相当する方向性を持つ有向グラフとなる．なお，本タスクの知識を表現する際，ログと事象は異なるものとして扱う．すなわち，ログは事実を示し，事象は，事実に基づき下された判断結果を示す．例えば，「応答時間が５秒を越えている」ことはログに示される事実であり，「処理速度低下事象の発生」は判断の結果である．このように区別することで，判断基準の変化に対して柔軟性を持たせ，また，より簡潔で説明性のあるグラフを得ることができる．次に，前節までに見てきた障害解析・障害予兆確認における原因切り分けの手順をもとに，支援システムの要件を抽出すると，以下の通りとなる． (2) 支援システムの要件 (2-1) 事象の発生有無を判断する方法を示すこと． (2-2) 事象の原因仮説を示すこと． (2-3) 事象の影響を示すこと． (2-4) 事象の原因と影響の理由について理解可能な形で示すこと． (2-1) から(2-3)は，グラフによって表現された因果関係の探索を通して実現できると考えられる．(2-4) については，グラフそのものを図示することのほかに，原因仮説や影響を提示する際に文字によって説明する方法も考えられる． 5.

プロトタイプの作成

本試行では，あるプログラミング言語によるソフトウェアを実行するサーバにおいて，応答時間が長時間化する性能低下問題を対象とし，知識グラフと支援システムプロトタイプを構築した．なお，本手順に関与したのは，５年以上の障害解析の経験を持

(4)

4 つ複数の専門家である．知識グラフ作成は以下の手順で行った．なお，事象とログの双方をノードとしてしまうと人間が理解する上で複雑になりすぎてしまうため，グラフには事象のみを含め，ログは，因果関係の説明等と共に別途の関連情報とした．１．初期グラフの作成：KJ 法[10]を参考に，発生しうる事象を思いつく限り付箋紙に書き出して大きめの紙に貼り，相互の因果関係を矢印で記した[図 5]．図5 初期グラフ２．グラフの精緻化：初期グラフを図形描画ソフトで電子化し，また，各事象の概要とログ確認方法，考えられる原因とその理由などの関連情報を表計算ソフトに整理した．これらについて専門家の意見を聞き，修正を繰り返した．なお，同グラフに含まれる因果関係の一部に，通常のログからは直接確認ができない事象があった．この部分についてはデバッグ用の特殊なログを収集して統計解析を行い，入手容易なログから同事象の発生を間接的に推定できることを確認した[11]．３．ベイジアンネットワーク(BN)の作成：4.3 節のモデルの要件(1-1～1-3)を満たす手段として，複数の原因と結果が交錯する知識グラフにおいて，迅速に原因の仮説を絞り込めるBN を採用した．前項までに作成したグラフをもとに，オープンソースの機械学習ソフトウェアである Weka[12]を使用し，BN を作成した[13][図 6]．４．RDBMS ツールの作成：BN で扱えない文字情報を管理し，4.3 節の支援システムの要件(2-1～2-4) を満たすことを目指し，各種情報をフォーム形式で表示するツールをRDBMS 上で作成した．本ツールは，知識グラフ自体は表示しないが，事象の原因や影響先について，因果関係上隣接するものを一覧表示した．さらに，事象の概要や因果関係の解説，ログ等の関連情報を表示した[図 7]．５．ドキュメントの作成：４．で作成したRDBMS ツールの内容を，印刷可能な文書にし，障害解析時での使用手順を明記してドキュメント化した．図6 ベイジアンネットワーク(BN)の例図7 RDBMS ツール画面例 6.

結果

前節で，BN，RDBMS ツール，ドキュメントの３つの形態の支援システムプロトタイプを作成した．これらについて，4.3 節で定義した支援システムの要件を満たすかを評価した結果を[表 1]に示す． BN は，因果関係を視覚的に良く表現し，条件付き確率によって可能性の高い原因仮説や影響をわかりやすく迅速に提示できた．一方，その他に表示できる情報が少なく，それだけでは障害解析を進める上で十分でなかった．なお，本試行で使用したWeka では日本語が使用できず，事象をわずかな英数字で表現する必要があるなど，使い勝手にも課題があった．この点については，商用ソフトの活用により改善できる可能性がある[14]． RDBMS ツールは，事象の辞書として有効であった．すなわち，各々の事象について，その発生有無をログから確認する方法や，原因や影響先の候補に

(5)

5 関する理由などの知識を豊富に表示できた．一方，グラフを表示せず，因果関係について隣接する事象しか表示できなかったため，根本原因に至る仮説を迅速に提示することはできなかった．理論的には，隣接する事象から出発し，順次検証すれば根本原因に辿り付くことができると考えられる．しかし，それを回答期限内に人手で行うことは，実質的には困難であることがわかった．このような手順では，専門技術者が行う迅速な根本原因仮説の提示を再現できない可能性が高い．ドキュメントでは，因果関係を，一種の索引表の形で表現したが，複雑な因果関係を表現するには不十分であり，人手で使用することは困難であった．表1 形態別プロトタイプの評価要件 BN RDBMS Document 2-1 － ○ ○ 2-2 △ △ × 2-3 △ △ × 2-4 － ○ × ○利用可能，△要改善，×利用困難，－機能無し 7.

考察

情報システム障害解析において原因仮説や事象の影響を迅速に提示するには，ドキュメントや文字による情報表示には限界があり，知識グラフによる提示が有効であった．一方で，知識グラフのみでは，情報システム障害解析を行うには情報が不足していることも判明した．また，現状のグラフの見やすさが，グラフが一層複雑化した場合にも保たれるかどうかについても留意すべきと考える．以上から，知識グラフと関連情報を統合的に表示し，複雑なグラフも見やすく示せるようにグラフの関係部分を強調する等の改善が望まれる．このような知識グラフツールの改善案の例を[図 8]に示す．知識グラフの作成は手間がかかり，専門家の主観が反映されるうえ，知識そのものも変化する．そのため，一度に十分な知識グラフを作ることは難しく，継続的改善を行う必要がある．その際，本試行で行ったように，レビューや承認といった共同作業を通して，複数の専門家の知識を集約できることが望ましい．なお，知識グラフ改善案の作成に際して，障害解析事例は重要な情報となる．しかし，我々が現在使用している事例データベースは文字情報を中心としているため，そのままでは知識グラフとの結びつきが弱いことが課題である．ところで，知識グラフ上で推論を行い仮説提示するには，現時点では，ベイズの条件付き確率による方法，すなわち BN が有望である．障害事象は，複数の原因が可能性として考えられ，また，必要なログを得られず確認できない場合があるなど，不確実性を伴う意思決定である．そのため，条件付き確率によって不確実性下の判断を支援できる BN は，現時点では最も有望と考えられる．図8 知識グラフツール改善案の例 BN に必要とされる条件付き確率は，現時点では専門家の主観的評価によって付与している．障害とは稀に起こるものである性質上，各条件について十分な事例が集まりにくい一方，実務において原因切り分けを行っている専門家の直観は，一定の有用性があると考えられるからである．しかし，障害解析事例が知識グラフと連携した形で十分に蓄積されたならば，条件付き確率も統計的結果に基づいて更新されることが望ましい．以上から，知識グラフを基礎とした障害解析知識流通システムを構想する場合，以下の要件を満たす必要があると考えられる．また，これらの要件を満たすシステムの一例を[図 9]に示す．図9 障害解析知識流通システムの例

(6)

6 (3) 障害解析知識流通システムの要件 (3-1) 障害事例を知識グラフ上に位置づけて分類し管理できること． (3-2) 事象や因果関係の追加・削除・修正を容易にできること．その際，複数の専門家によるレビューや承認などの共同作業をサポートすること． (3-3) 蓄積された障害事例を基に，条件付き確率を統計的に精緻化できること． 8.

まとめ

本稿では，理由説明や演繹的判断ができるAI 等との関連で注目される知識グラフを，専門家の知識を非専門家も活用可能にする知識流通手段として用いることを目指し，プロトタイプの作成と評価を行った．その結果，知識グラフは情報システム障害解析の知識流通手段，特に仮説を迅速に提示する手段として有望であること，ただし実際に活用するためには，関連情報を統合的に表示するなど使い勝手の改善や，知識グラフを継続的に改善するための関連システムが必要であることを述べ，それらに必要とされる要件を示した．

謝辞

本件に関する研究発表の機会を与えて頂いたNTT サービスイノベーション総合研究所ソフトウェアイノベーションセンタの毎田泉氏，岡順一氏，木下透氏，寺本純司氏に謹んで感謝の意を表する．また，NTT 研究企画部門の小西史和氏，NTT テクノクロス株式会社の岩田雅彦氏，湯口徹氏，NTT アドバンステクノロジ株式会社の和氣弘明氏，NTT コムウェア株式会社の高木浩則氏には，NTT サービスイノベーション総合研究所ソフトウェアイノベーションセンタ在籍のおり，本発表の基となった研究の機会を頂き，ご指導を頂いた．株式会社NTT データの末永恭正氏，LINE 株式会社の久保田祐史氏，NTT アドバンステクノロジ株式会社の山崎秀夫氏には，当時，筆者の同僚として，本件に関する知識グラフ構築等の一連の手順にご協力を頂いた．以上の方々に謹んで感謝の意を表する．

参考文献

[１] 川村隆浩, 江上周作, 田村光太郎他: 第 1 回ナレッジグラフ推論チャレンジ 2018 開催報告─説明性のある人工知能システムを目指して─, 人工知能, Vol. 34, No. 3, pp. 396-412, (2019)

[２] Guidotti, R., Monreale, A., Ruggieri, S., Turini, F., Pedreschi, D., Giannotti, F. : A survey of methods for explaining black box models, ACM Computing Surveys (CSUR), Vol. 51, No. 5, Article No. 93, (2019)

[３] 川村隆浩: 機械学習の説明可能性への取り組み－ DARPA XAI プロジェクトを中心に－, 人工知能学会全国大会（第33 回）企画セッション, 講演 2, (2019) [４] 総務省: 国際的な議論のためのＡＩ開発ガイドライン案, ＡＩネットワーク社会推進会議報告書 2017, 別紙1, (2017) [５] 本村陽一: ベイジアンネットワーク：入門からヒューマンモデリングへの応用まで, 日本行動計量学会セミナー資料, (2004) [６] 安田宗樹, 片岡駿, 田中和之: 確率的グラフィカルモデル－ベイジアンネットワークとその周辺－, オペレーションズ・リサーチ：経営の科学, Vol. 58, No. 4, pp. 191-197, (2013)

[７] Biran, O., and Cotton, C.: Explanation and Justification in Machine Learning: A Survey, IJCAI 2017 Workshop on Explainable Artificial Intelligence (XAI) , (2017) [８] Lacave,C., Díez, F.J.: A review of explanation methods for

Bayesian networks, The Knowledge Engineering Review 17 (2), 107-127, (2002)

[９] Suermondt, H.J.: Explanation in Bayesian Belief Networks. PhD thesis, Stanford, CA, USA, 1992. UMI Order No. GAX92-21673. [１０] 川喜多二郎: 発想法, 中央公論社, (1967) [１１] 髙雄慎二，高木浩則，和氣弘明，湯口徹: CMS GC における Java ヒープメモリ断片化の要因, 2016-SE194, ソフトウェア工学研究発表会, 情報処理学会, (2016) [１２] Weka, https://www.cs.waikato.ac.nz/ml/weka/, retrieved 2019.8.20, (2017)

[１３] Takao, S., : How to deal with Java troubles on microservices, Oracle Code One 2018, BOF5902 (Site: San Francisco, California, USA, Date: October, 22-25), (2018)

[１４] BayoLink, https://www.msi.co.jp/bayolink/, retrieved 2019.8.20, (2019)