DEIM Forum 2019 D3-4

複数サーバ環境での解決実績に基づいたシステム障害解決支援機構の構築
笠井 貴之†

鷹野 孝典‡†神奈川工科大学大学院工学研究科情報工学専攻 〒243-0292 神奈川県厚木市下荻野 1030
‡神奈川工科大学情報学部情報工学科 〒243-0292 神奈川県厚木市下荻野 1030
E-mail: †s1785009@cco.kanagawa-it.ac.jp,‡takano@ic.kanagawa-it.ac.jp

あらまし システム運用において迅速な障害原因の特定・解決は重要である．障害に柔軟に対応できるシステム
構成や障害検知の自動化が可能となっているが，障害原因特定は多くの場合に人間が行っており，解決までの試行
錯誤を削減するための自動化支援が必要である．既存研究ではルールに基づいて障害原因を特定するものなどがあるが，障害解決の自動化機能は実現されていない．本研究では，システム障害の効率的な解決を目的とした，複数サーバ環境での解決実績に基づいたシステム障害解決支援機構を提案する．提案手法では，対象サーバで障害が発生した際に，障害知識ベースに問い合わせることで解決方法として得られるコマンド群を仮想検証環境上で自動実行することで有効性を検証する．この検証結果を解決実績とし，障害知識ベースにフィードバックすることで記録されたコマンド群に優先順位を付ける．このサイクルにより，障害知識ベースは原因特定・解決に有用であるコマンド群の解決実績情報を継続的に更新し，優先的に障害発生サーバに提供することができる．実験では障害環境を再現した実験環境を用いて提案手法の実現可能性を検証する．
キーワード システム障害，サーバ運用，仮想環境，障害解決，知識ベース削減するための自動化支援が必要になっている．既存

1. は じ め にソ フ ト ウ ェ ア シ ス テ ム の 基 盤 部 分 は Amazon Web
Services[1] やGoogle Cloud Platform[2] ， Microsoft

Azure[3]な ど の ク ラ ウ ド サ ー ビ ス を 利 用 し て 構 築 す る

研究ではルールに基づいて障害原因を特定するものなどがあるが，障害解決の自動化機能は実現されていな
い．

こ と が 一 般 的 に な っ て い る ． Web コ ン ソ ー ル や REST本研究では，システム障害の対象範囲は広く汎用的

API に よ っ て プ ロ グ ラ マ ブ ル に 制 御 可 能 な こ れ ら の ク

な 議 論 が 困 難 で あ る た め ， Web サ ー ビ ス に お い て ユ

ラウドサービスを利用することでシステム管理者は大ーザへのサービス提供が停止した状態を解決すべきシ

規模・複雑なシステム構成を迅速かつ柔軟に構築可能

ステム障害として扱う．これには大別して 2 つの難易となった．また，システムの規模増大・複雑化にとも度設定があると考えられる．1 つ目は設定ファイルやなってシステム管理者の人的コストが飛躍的に増大しデータ格納ディレクトリ権限設定ミスなどの時間をかたため，システム管理者は総合的な運用コストを抑えければ経験や知識が浅い状態でも解決できる単純なア

るために可能な限り運用の自動化を行う必要がある．

プリケーション・ミドルウェアのデプロイ時の障害で

例 え ば シ ス テ ム 障 害 の 自 動 検 知 に つ い て は Datadog[4]あ る ．2 つ 目 は CPU や メ モ リ な ど の サ ー バ リ ソ ー ス のや New Relic[5]の よ う な CPU 使 用 率 や メ モ リ 使 用 量 な

異常消費など豊富な経験や専門知識を有する管理者がどのサーバメトリクス監視サービスを導入することにい な け れ ば 解 決 で き な い OS や ネ ッ ト ワ ー ク レ イ ヤ のよって実現している．しかしながら，依然としてシス障害である．

テム障害の原因調査・解決は多くの場合人間が行って本研究では，システム障害の効率的な解決を目的とおり，クラウドサービスの導入によるドメイン知識のした，複数サーバ環境での解決実績に基づいたシステ増大にともなって経験豊富な管理者であっても障害解ム障害解決支援機構を提案する．提案手法では，対象

決まで多くの試行錯誤が必要と なる．また，このようサーバで障害が発生した際に，障害知識ベースに問いな状況下では運用する対象システム構成の複雑化，規合わせることで解決方法として得 られるコマンド群を模の増大に比例して経験豊富な管理者に知識・経験が仮想検証環境上で自動実行することで有効性を検証す

偏ってしまうことで特定人物に障害解決作業が依存しる．この検証結果を解決実績とし，障害知識ベースにてしまうことや人的コストも増大するという問題を抱フィードバックすることで記録されたコマンド群に優えている．このようにシステム運用に おける迅速な障先順位を付ける．このサイクルにより，障害知識ベー

害原因の特定や解決は重要であ り，システム障害の原

スは原因特定・解決に有用であるコマンド群の解決実因特定と解決の効率化のためには，人間の 試行錯誤を

績情報を継続的に更新し，優先的に障害発生サーバに提供することができる．

てそのノウハウを運用者全員が共有することで再発防本研究の特徴と貢献は下記のようにまとめられる．

止 を 行 っ た [16]． ま た ， 障 害 の 回 避 手 段 の 提 示 に 関 す•

障 害 発 生・解 決 サ イ ク ル を 体 系 的 に 構 築 す る こ

る研究も行われている．加藤らは基本的な障害対処ルと に よ り ，半 自 動 的 な 障 害 知 識 ベ ー ス の 学 習 機ールを記述しておき複雑な障害に対してはそれらを基構を実現している点に障害回避方法を自動生成し運用者への提示を行った

過去の障害解決情報をコマンドとして形式化

[17]．

•

し ，仮 想 検 証 環 境 を 適 用 す る こ と で 部 分 的 に 自••既存研究ではシステムの異常検知や障害環境情報

動的な障害原因分析機能を実現している点の自動収集によって管理者が障害解決を行う際の支援

障害解決可能な知識を解決実績を考慮して評を行っている．しかしながら，実際に障害を解決する

価 す る こ と に よ り ，実 際 的 な 解 決 方 法 を 優 先 的ための操作コマンドの生成・実行といったシステム障に提供できる点

害解決の自動化支援機能は実現されていない．この機

上 記 の 処 理 に よ り ，シ ス テ ム 管 理 者 に 対 し て は能を実現するためには以下の 3 つの課題点があると考障 害 解 決 分 析 に 有 用 な 情 報 を 提 供 し ，意 思 決 定

えられる．

のための支援ができる点

1 つ目は障害原因特定・解決に用いられる過去の経実験で対象とする障害はディレクトリツリーの変験（解決実績）が個人の経験に依存しており，それを更をともなうものである．具体的にはソフトウェアの

普遍的に共有化する方法や活用する仕組みがないとい

デプロイミスや設定ファイル等の権限ミスを起因としう点である．管理者の技量には個人差があり，また，た障害を対象として，障害環境を再現した実験環境を常に同じ管理者がすべての障害解決を行うわけではな

用いて提案手法の実現可能性を検証する．

いので，どうしても知識の偏りが存在する．だからこ
そ知識の共有化を行わなければならないのだが，マニ

2. 関 連 研 究
システム障害・異常検知についての研究が行われている．永井らは障害発生装置の種類・構成要素と障害ュアル等では対応できる幅に限界がある．このため，過去の障害対応知識を有する障害知識ベースの構築が必要であると考えられる．

原因の対応を定義しルールベースで障害原因の推論を

2 つ目は，障害解決という作業が形式化されていな

行 っ た [6] ． ア プ リ ケ ー シ ョ ン レ イ ヤ で は 中 村 が Web

いため，実際の障害環境で作業を行わないとその解決

アプリケーションにおける障害予測の早期化・高精度

方法が障害解決に有効であるか判断できないという点化 の た め に Web ペ ー ジ の ア ク セ ス 時 間 に 対 し て 統 計である．通常管理者が障害原因の特定やその解決を行的な方式を用いたアクセス時間解析方式を提案していう際のアプローチとして，自身の経験や知識を基に原る [7]． Holub， Wang ら は RTCE(Run-Time Correlation

因の推測や解決のための方法を考案し実行する．このEngine) と い う 分 散 シ ス テ ム ロ グ を 収 集 し エ ラ ー と のとき用いられる管理者の知識や経験は個人に依存して相関を分析するエンジンを提案し，クラウド環境でのお り ，マ ニ ュ ア ル 等 で あ る 程 度 知 識 共 有 さ れ て い て も ，

評 価 を 行 っ て い る [8] [9]．Xu ら は コ ン ソ ー ル ロ グ の 文

最終的には個人の技量に依存してしまう．また，考案字列を解析し障害時に発生するログ情報を抽出する手した解決方法の有効性は実際に障害環境で試行しない法 を 提 案 し て い る [10][11]．Mirgorodskiy ら は 複 数 の 運と判断できず，その知識も得ることができない問題が用管理プロセスにおけるログを比較することで問題のあ る ．こ の た め 障 害 解 決 と い う 作 業 を 明 確 に 形 式 化 し ，ある運用管理プロセスを特定する手法を提案している

障害環境とほとんど同じような環境で実際に実行する[12]． Diao ら は 運 用 管 理 者 が 記 述 し た ト ラ ブ ル チ ケ ッことでその有効性を確認する必要があると考えられる．

トに含まれる文字列と障害の原因を関連付けたルール

3 つ目は障害中の環境で無作為に複数の解決方法をに 基 づ い て 原 因 特 定 を 行 う 手 法 を 提 案 し て い る [13]．

試行しても，それが障害解決に有効ではなく，さらな

工藤らはより少ない手間と短い時間でルールが構築でる 障 害 を 引 き 起 こ し て し ま う 可 能 性 が あ る 点 で あ る ．1

きるルール記述方式とルール構築方法，そしてそれをつの障害原因に対して 1 つの解決方法だけであるとは効率的に精度良く実行するための解析ルールのデータ限らず，複数の解決方法がある可能性があるため管理形 式 と 解 析 実 行 方 式 を 提 案 し て い る [14]． 阿 部 ら は イ

者は複数の解決手段を考案し，それらを実行する必要

ベントネットワークのようなマルチベンダ機器で構成がある．しかしながら，それらは無作為に実行してもさ れ る 特 殊 な 環 境 に お い て syslog メ ッ セ ー ジ の 総 量 にその障害を直接解決できるものと解決できないものとよ る 分 析 を 行 い 異 常 検 知 す る 手 法 を 提 案 し て い る [15]．

がある．さらに最悪の場合，新たな障害を発生させる

ま た ，障 害 の 再 発 防 止 に つ い て の 研 究 も 行 わ れ て い る ．

可能性もある．そのため，試行する際には過去に実行

西野らは熟練管理者の障害対処操作対応をルール化ししたことがあり，有効性に関してある程度実績がある

ものを優先的に試行する必要があると考えられる．そなる．このサイクルにより，プライマリ障害知識ベーのため，試行する複数の解決方法には実行優先順位を

スは原因特定・解決に有用であるコマンド群の解決実付加する必要があると考えられる．

績情報を継続的に更新し，優先的に障害発生サーバに以上のことからシステム障害解決の自動化支援機
能の実現は困難であるといえる．

提 供 す る こ と が で き る ．図 1 に 提 案 方 式 の シ ス テ ム 概
要図を示す．
セカンダリ知識ベース

3. 提 案 方 式

実績情報フィードバック

本研究では，システム障害の効率的な解決を目的と

検証結果

した，複数サーバ環境での解決実績に基づいたシステ

解決候補コマンド群の検証実行

ム障害解決支援機構を提案する．提案方式は以下の 3

仮想検証環境つの特徴を持つ．
1.

Server_1
・・・

障 害 発 生・解 決 サ イ ク ル を 体 系 的 に 構 築 す る

ことにより半自動的な障害知識ベースの学習機構を実実績でランキングされた
解決候補コマンド群

プライマリ障害知識ベース

セカンダリ知識ベース

現する
2.

実績情報フィードバック

過去の障害解決情報をコマンドとして形式
検証結果化し仮想検証環境を適用することで（部分的に）自動解決候補コマンド群の検証実行

的な障害原因分析機能を実現する
3.

実績でランキングされた
解決候補コマンド群

仮想検証環境障害解決可能な知識を解決実績を考慮してServer_N

評価することにより，実際的な解決方法を優先的に提図 1 提案システムの概要供する提案方式では過去の障害知識を普遍的な知識として活用可能であり，共有可能なものとするために障害提案システムの実行手順は以下の通りである．

知識ベースを構築する．この障害知識ベースには過去

1.

過去のシステム障害時に出力されたシステムに発生した障害のエラーログや管理者が実行したコマ

エラーログメッセージとその解決に使用されンド，人間が手動で解決できるものか否かを表すフラたコマンド群が記録されたプライマリ障害知グ等が記録され，将来の障害に対応するための知識を

識ベースを構築する．

記録する．障害知識ベースはプライマリ障害知識ベー

2.

障害発生中のサーバ上に記録されたログメッ

スと管理対象の複数サーバ上で稼働するセカンダリ障

セージをクエリにプライマリ障害知識ベース

害知識ベースから構成される．

上 で 検 索 を 行 い ，障 害 内 容 の 解 決 に 適 し た 複 数

・害時のシステムログと解決のために実行した・のコマンド群を優先度付きで抽出する．

プ ラ イ マ リ 障 害 知 識 ベ ー ス：解 決 し た 過 去 の 障
3.

障 害 発 生 中 の 対 象 サ ー バ 上 で Union File System

コマンド群を記録する．

を用いて実環境ファイルシステム上に実環境

セ カ ン ダ リ 障 害 知 識 ベ ー ス：プ ラ イ マ リ 障 害 知に近い状態の仮想的なファイルシステムを構築する．

識ベースから得たコマンド群を仮想検証環境
上 で 実 環 境 に 影 響 を 与 え ず に 実 際 に 実 行 し ，実4.

て返ってきたコマンド群を自動的に仮想検証

行結果を保持する．

環境で実行する．

セカンダリ障害知識ベースは，管理対象サーバ上で障害が発生した際，プライマリ障害知識ベースから得プライマリ障害知識ベースから検索結果とし

5.

検証結果をセカンダリ障害知識ベースに記録たコマンド群について解決方法の有効性を検証する．

し ，解 決 実 績 と し て プ ラ イ マ リ 障 害 知 識 ベ ー ス

この検証結果は解決実績としてプライマリ障害知識ベにフィードバックする．

ースにフィードバックされ，記録されたコマンド群の優 先 順 位 付 け に 用 い ら れ る ． ま た ， Union File System

3.1. 障 害 知 識 ベースの構 築を用いて実環境ファイルシステム上に実環境に近い状

過去にシステム障害が発生したソフトウェアのシ態の仮想的なファイルシステムを構築し，この仮想検

ステムエラーログメッセージとその障害を解決するた

証環境上でファイルシステムの変更をともなうシステ

めに管理者が用いたシステムコマンドの対応付けを記

ム障害の解決作業を実行する．これによって管理者は録する障害知識ベースを構築する．

ほぼ実環境と同じ環境で，実環境に影響を与えること

障害知識ベースを構築する際には， 全文検索エンジ

無く障害解決に必要な調査・検証を行うことが可能とンに対して，障害発生時に自動または手動で収集した

エラーログをキー，その障害を解決するために実行しReadonly な Lower デ ィ レ ク ト リ ツ リ ー と い う 2 つ を マたコマンドを値として自動または手動で記録する．検ージし 1 つのディレクトリツリーとして見せるファイ

索時に，エラーログをクエリに用いて検索を行うこと

ルシステムであり，ある時点のディレクトリツリーので，発生中の障害に似た過去の障害事例が検索可能とスナップショットを維持したままいつでも破棄可能ななる．検索結果として返ってくるコマンド群を発生中変更を行うことを可能とする．これを用いて障害発生の障害を解決する可能性のあるコマンド群 とし，仮想時 の デ ィ ス ク の 状 態 を Readonly の レ イ ヤ と し て 作 成

検 証 環 境 上 で 実 際 に 実 行 す る ．表 1 に プ ラ イ マ リ 障 害

し ，そ の 上 に Readable/Writable な レ イ ヤ（ 仮 想 検 証 環

知 識 ベ ー ス の ス キ ー マ ，表 2 に セ カ ン ダ リ 障 害 知 識 ベ境）を作成し，その環境上でコマンド群を試行する．

ースのスキーマを示す．

例として，ファイルの権限操作を行う場合の手順を 図

表 1 プライマリ障害知識ベースのスキーマ

2 に 示 す ． Step1 で は Readonly な 不 正 権 限 フ ァ イ ル にfield

description

対 し て 正 常 な 権 限 へ 戻 す た め の 操 作 を 行 う ． Step2 で

eid

デ ー タ IDは Readonly な フ ァ イ ル を 編 集 す る た め に 中 間 層 に 操

type

障害の種類
（ e.g. disk,network,memory）

作 対 象 の フ ァ イ ル の コ ピ ー を 行 う ． こ の 時 点 で Union

success_number

成功実績

間層にコピーされたファイルが見えている．最後のfailure_number

失敗実績

Step3 で は 中 間 層 に コ ピ ー さ れ た 操 作 対 象 フ ァ イ ル にowner

障害が発生したサーバ名

対 し て Step1 で 行 わ れ た 権 限 操 作 が 行 わ れ る ． こ れ に

障害発生時のエラーログメッセー
ジ
管理者が解決のために実行したコ
マンド

よって最終的にユーザから見えるのはディレクトリツ

log_messages
resolve_cmd

表 2 セカンダリ障害知識ベースのスキーマ

File System を マ ウ ン ト し た デ ィ レ ク ト リ ツ リ ー で は 中

リー内に存在する正常な権限を持ったファイルとなり，権限操作が透過的に行われたように見える．
提案方式で構築する仮想検証環境は，実環境のディ
レクトリツリーのみ複製するため，実行中のプロセス

field

description

やサーバ外部のネットワーク上で発生した障害は再現

flag_auto

自動的に解決できたかできないという点が実環境と異なる．このためこの仮

flag_human

人間が手動で解決できたか

想検証環境で再現可能となる障害はディレクトリツリ

システム障害には多くの種類があり，大まかに分類ーの変更に起因するものに限られる．例えば，特定のするとシステム的に自動的に解決できるものと自動的ソフトウェアのパッケージ依存問題や操作権限を原因に解決できなくとも人間が手動で作業すれば解決できとした障害に対しては有効であるが，メモリリーク なるものが存在すると考えられる．提案シス テムにおいどの実行中のプロセスに起因するもの，サーバ外のネてこれらを区別するために，セカンダリ障害知識ベーットワーク上での障害は再現することができない．

スではその障害が自動的に解決できたか，もしくは人間が手動で解決できたかという知識を記録する．これ

Step 1

Step 2

Step 3

権限修正操作の開始

操作ファイルのコピー

操作の適用

不正権限
ファイル

正常権限
ファイル

不正権限
ファイル

正常権限
ファイル

不正権限
ファイル

不正権限
ファイル

を用いる利点として，管理者に対して有効な解決方法を提示する際，より適当な情報を提供できるという点がある．自動解決できる障害に対しては，障害知識ベースに蓄積された知識から直接的な解 決方法を管理者に提示する．もしくは自動解決できない問題に対しては，試行され解決に失敗した方法を提示する．障害知

仮想検証環境Readable
Writable

不正権限
ファイル

中間層
Writable

識ベースには失敗した方法に対応した障害原因も記録されているので，障害原因の候補から除外することが障害環境
Readonly

不正権限
ファイル

可能となり，この失敗知識も障害原因推測に活用できると考えられる．

3.2. 仮 想 検 証 環 境 の構 築

図 2 仮想検証環境の概要

3.3. 障 害 知 識 ベースからのコマンド抽 出

実環境上のファイルシステムを変更せずファイル解決に効果のあるコマンドを障害知識ベースからシステムの状態を保ったままの仮想検証環境の構築に取得する際は，発生した障害のエラーログメッセージ

は Union File System を 用 い た ． Union File System と は

errMsg を ク エ リ と し て 障 害 知 識 ベ ー ス に 入 力 し 検 索

Readable/Writable な Upper デ ィ レ ク ト リ ツ リ ー とを行う．クエリとして入力した障害エラーログ，および 全 て の 過 去 の 障 害 エ ラ ー ロ グ pastErrMsg x と の 類 似度は以下の類似度スコア計算式を用いて計算される．

解決候補コマンドを提示

解決コマンドX

解決コマンドX

実績+1

実行

解決できたので
実績+1

実績フィードバック

𝑠𝑐𝑜𝑟𝑒𝑠𝑖𝑚 (𝑞, 𝑑) = 𝑐𝑜𝑜𝑟𝑑(𝑞, 𝑑) × 𝑞𝑢𝑒𝑟𝑦𝑁𝑜𝑟𝑚(𝑞)障害X× ∑ (𝑡𝑓(𝑡 𝑖𝑛 𝑑) × 𝑖𝑑𝑓(𝑡)2 × 𝑏𝑜𝑜𝑠𝑡(𝑡) × 𝑛𝑜𝑟𝑚(𝑡, 𝑑))𝑡 𝑖𝑛 𝑞

自動解決できた場合
自動解決可能フラグをセット

類 似 度 ス コ ア score si m (errMsg, pastErrMsg x )の 高 い 順に検索結果として，コマンド候補群を 抽出する．次に

障害X発生

プライマリ
障害知識ベース

手動解決可能かTrue

自動解決可能か

True

セカンダリ
障害知識ベース

図 3 解決実績フィードバックサイクルの流れ

早期に障害解決可能なコマンドを実行するために，エラーログによる類似度スコアだけでなく，障害知識ベ

4. 実 験

ースに記録された各解決候補コマンドの実績スコアに4.1. 実 験 目 的

よって仮想検証環境上で実行する際の優先順位を付け
る ．解 決 候 補 コ マ ン ド を resolveCandCmd x ，そ の コ マ ン
ド の 成 功 実 績 を successPerf x ， 失 敗 実 績 を failurePerf xと し た と き 実 績 ス コ ア score perf は 以 下 の 式 で 求 め ら れる．
𝑠𝑐𝑜𝑟𝑒𝑝𝑒𝑟𝑓 (𝑟𝑒𝑠𝑜𝑙𝑣𝑒𝐶𝑎𝑛𝑑𝐶𝑚𝑑𝑥 ) = 𝑠𝑢𝑐𝑐𝑒𝑠𝑠𝑃𝑒𝑟𝑓𝑥 − 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑃𝑒𝑟𝑓𝑥
発 生 し た 障 害 failure x に 対 し て 抽 出 さ れ た 解 決 候 補
コ マ ン ド resolveCandCmd x の 類 似 度 ス コ ア score si m お よび 実 績 ス コ ア score perf の 高 い 順 に 検 索 結 果 と し て ， 仮
想検証環境において実行するコマンド候補群を返す ．

本実験では，提案方式を障害環境を再現した実験環境上で実行し，以下の点を確認することでその実現可能性を確認する．
•

対象サーバ上での解決実績を障害知識ベースへ
継続的にフィードバックすること．

•

障害知識ベースにフィードバックされた解決実績を基に推薦コマンド群に優先順位が反映されること．

4.2. 実 験 環 境
実験環境では OS として Linux (Ubuntu16.04)を使用した
3 台の管理対象サーバと 1 台の障害知識ベースを VirtualBox

3.4. 仮 想 検 証 環 境 での実 行障害知識ベースから検索したコマンド群は，そのま
ま実行するだけで障害解決できるものと解決には至らないもののその過程に貢献できるものが混在する．コ
マンド 1 つごとに仮想検証環境を構築し，実際に実行することを自動的に繰り返すことで，どのコマンドが障害解決に効果があるかを検証 する．

上に仮想マシンとして構築した．管理対象サーバでは，仮想検証環境の構築のために Linux 上の Union File System である OverlayFS を 使 用 す る ． 障 害 知 識 ベ ー ス の 構 築 に はElasticsearch を使用する
実験において障害知識ベースとして使用するデータを 20件用意した．障害内容とその原因，解決に用いるコマンドの一部を表 3 に示す．また実験環境上で擬似的に障害を発生させるための障害原因コマンド一覧，その障害が解決したこと

3.5. 解 決 実 績 のフィードバック
仮想検証環境上での各コマンドの実行結果は各サーバ環境における解決実績としてセカンダリ障害知識
ベースに記録される．また，今後類似する障害が発生した場合優先的に問い合わせ結果となるようにプライ
マリ障害知識ベースに解決実績をフィードバックする．
プライマリ障害知識ベースにエラーログおよび実行したコマンド内容とその実行が成功した場合には成功実
績 success に +1 点 ， 失 敗 し た 場 合 は 失 敗 実 績 fail に +1点というように継続的に解決実績を更新する．このサイクルにより，障害知識ベースは原因特定・解決に有用であるコマンド群の解決実績情報を継続的に更新し，優先的に障害発生サーバに提供することができる． 解
決実績のフィードバックサイクルの流れを図 3 に示す．

を確認するための解決確認コマンド一覧，および障害時に発生したエラーログメッセージを，それぞれ表 4，表 5，表 6に示す．
実現可能性の検証のために，表 7 のコマンドによっ て 引 き 起 こ さ れ る 障 害（ 実 験 デ ー タ に お け る eid=7）を想定した実験を行う．提案方式で実行される障害知
識ベースへの問い合わせに用いる 疑似障害によって出力されたエラーログメッセージを表 8 に示す．

eid

1

表 3 実験に使用する障害データ
障害内容 / 障害原因
障害解決コマンドhttps を用いるリポジ
トリからパッケージ
パッケージマネージャがをダウンロードできhttps 対応していないないsudo apt install -y apt-transport-https2

Elasticsearch が起動しない動作するために必要な JDKがインストールされていないsudo apt install -y openjdk-8-jdk
プロキシ下でパッケージがダウンロード
できない

3

4

表 5 解決確認コマンド
eid
1 sudo apt update
2 sudo systemctl start elasticsearch.service
3 sudo apt update
4 sudo systemctl restart mysql.service
5 sudo systemctl restart mysql.service
6 sudo apt update
7 sudo systemctl restart mysql.service
表 6 エラーログメッセージeid

E: The method driver /usr/lib/apt/methods/https①echo '#!/bin/bash' > /etc/profile.d/proxy.bash②echo export ¥http_proxy=http://ccproxy.kanagawa-it.ac.jp:10080'¥>> /etc/profile.d/proxy.bash③echo export 'https_proxy=$http_proxy' ¥>> /etc/profile.d/proxy.bash④echo ¥
Defaults env_keep+=¥"http_proxy https_proxy¥" ¥>> /etc/sudoers

N: Is the package apt-transport-https installed?

MySQL が起動しない

could not be found.
1

MySQL が起動しない

プロキシ下でパッケージがダウンロード
できない

ble/InRelease...
Nov 28 05:56:17 ubuntu-xenial elasticsearch[11810]:
2

W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/xenial/InRel

データベースディレクトリ
内での操作権限不足

ease7

http://archive.ubuntu.com/ubuntu/dists/xenial-upda
3...
2019-01-08T16:23:12.907580Z 0 [ERROR] InnoDB:
The innodb_system data file 'ibdata1' must be
writable2019-01-08T16:23:12.907658Z 0 [ERROR] InnoDB:
4

error

②unset https_proxy...

4 sudo chmod 000 -R /var/lib/mysql

2019-01-08T16:23:12.907580Z 0 [ERROR] InnoDB:

5 sudo chown root.root /var/lib/mysql

7①sudo chown root.root /var/lib/mysql②sudo chmod 000 /var/lib/mysql

writable
Plugin initialization aborted with error Generic①unset http_proxy| xargs -I{} sed -i -r '/Acquire::https?::proxy.+/d' {}The innodb_system data file 'ibdata1' must be
2019-01-08T16:23:12.907675Z 0 [ERROR] InnoDB:

2 sudo apt remove -y openjdk-8-jdk

6Could not resolve'archive.ubuntu.com'①sudo chown mysql.mysql /var/lib/mysql②sudo chmod 755 /var/lib/mysql

find /etc/apt/apt.conf.d/ -type f ¥'archive.ubuntu.com'

ports/InRelease

1 sudo apt remove -y apt-transport-https3

Could not resolve

http://archive.ubuntu.com/ubuntu/dists/xenial-back

データベースディレクトリ
内での操作権限不足

障害原因コマンド

tes/InRelease

W: Failed to fetch

表 4 障害原因コマンド
eid

Could not resolve 'archive.ubuntu.com'

W: Failed to fetch①echo 'Acquire::http::proxy¥"http://ccproxya.kanagawa-it.ac.jp:10080/¥";' >/etc/apt/apt.conf.d/10proxy②echo 'Acquire::https::proxy¥"http://ccproxya.kanagawa-it.ac.jp:10080/¥";' >>/etc/apt/apt.conf.d/10proxy
MySQL が起動しない

could not find java; set JAVA_HOME or ensure java
is in PATH

データベースディレクトリ
内での操作権限不足

apt でのプロキシ環境下用の設定がされていない

E: Failed to fetch
https://artifacts.elastic.co/packages/6.x/apt/dists/sta

sudo chown mysql.mysql /var/lib/mysql

6

エラーログメッセージ

http_proxy 環境変数の設定がされていない

sudo chmod 755 /var/lib/mysql
5

解決確認コマンドThe innodb_system data file 'ibdata1' must be
5

writable2019-01-08T16:23:12.907658Z 0 [ERROR] InnoDB:
The innodb_system data file 'ibdata1' must bewritableとで，解決実績が障害知識ベースへフィードバックさ

2019-01-08T16:23:12.907675Z 0 [ERROR] InnoDB:

れていることを確認する．また，障害知識ベースへのPlugin initialization aborted with error Generic

問い合わせ結果が解決実績によって優先順位が付けらerror

れていることを確認する．

...
W: Failed to fetch

4.4. 実 験 結 果

http://archive.ubuntu.com/ubuntu/dists/xenial/InRel
ease

6

Could not resolve 'archive.ubuntu.com'

W: Failed to fetch

提 案 方 式 を 適 用 し た あ と の 問 い 合 わ せ 結 果 を 表 10 に

http://archive.ubuntu.com/ubuntu/dists/xenial-upda

示す．

tes/InRelease

Could not resolve

表 9 フィードバック前の障害知識ベース'archive.ubuntu.com'
W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease

Could not resolve'archive.ubuntu.com'...
2019-01-08T16:23:12.907580Z 0 [ERROR] InnoDB:
The innodb_system data file 'ibdata1' must be
writable2019-01-08T16:23:12.907658Z 0 [ERROR] InnoDB:
7

障害原因コマンドを実行したあと，提案方式を適用
す る ．提 案 方 式 適 用 前 の 検 索 結 果 を 表 9 に 示 す ．ま た ，

順位
1
2
3
4
5
6
7
8
9
10

eid
14
4
6
20
3
11
17
0
9
19

に対する問い合わせ結果
成功実績
失敗実績
検索スコア
0
0
11.22
0
0
7.93
0
0
7.93
0
0
7.93
0
0
5.86
0
0
5.86
0
0
0.36
0
0
0.34
0
0
0.34
0
0
0.34

The innodb_system data file 'ibdata1' must be
writable2019-01-08T16:23:12.907675Z 0 [ERROR] InnoDB:
Plugin initialization aborted with error Generic
error
...
表 7 実験で実行した障害コマンド① sudo chown root.root /var/lib/mysql② sudo chmod 000 /var/lib/mysql

表 10 フ ィ ー ド バ ッ ク 後 の 問 い 合 わ せ 結 果
eid
順位
成功実績
失敗実績
検索スコア
1
6
1
0
7.93
2
14
0
1
11.22
3
4
0
1
7.93
4
20
0
1
7.93
5
3
0
1
5.86
6
11
0
1
5.86
7
17
0
1
0.36
8
0
0
1
0.34
9
9
0
1
0.34
10
19
0
1
0.34

表 8 疑似障害により出力されたエラーログメッセージ[ERROR] InnoDB: The innodb_system data file 'ibdata1'
must be writable

4.5. 実 験 考 察
実 験 結 果 よ り 表 9 と 表 10 の 比 較 か ら ， 障 害 知 識 ベースから提示された解決候補コマンド群の成功実績および失敗実績の値が更新されていることがわかる．こ4.3. 実 験 方 法

れは，障害発生サーバ上において，仮想検証環境にお障害知識ベース上にある既知の障害を対象として，ける解決候補コマンドの実行結果を解決実績情報とし

表 4 の 障 害 原 因 コ マ ン ド を 実 行 す る こ と に よ り ，擬 似て障害知識ベースへフィードバックしたためである．

的に障害を発生させる．障害が発生している状態で仮

ま た ，実 験 結 果 よ り フ ィ ー ド バ ッ ク 前 後 で eid=14 と想検証環境の構築を行うことで障害環境を再現し，提eid=6 の 順 位 が 変 動 し て い る こ と が わ か る ． eid=14 の案 方 式 を 用 い て 表 3 の 内 容 と ダ ミ ー デ ー タ を 含 む 20

順位が低下した理由として，失敗実績が更新されたた件のデータを障害知識ベースとして構築し障害解決をめ で あ る と 考 え ら れ る ．提 案 方 式 適 用 前 は 表 9 よ り 検

行 う ．ま た ，障 害 解 決 作 業 の あ と 表 5 の 解 決 確 認 コ マ

索 結 果 順 位 と し て eid=14 が 1 位 と し て 返 っ て き て い る

ンドを実行することで，障害が解決されたかの判定をた め eid=14 が 最 初 に 検 証 実 行 さ れ る が ，検 証 結 果 と し行いその結果を解決実績として障害知識ベースにフィて解決に失敗すると失敗実績が更新される．反対にードバックする．このとき障害知識ベース内の解決実

eid=6 の 順 位 が 向 上 し た 理 由 と し て 検 証 環 境 で の 障 害

績部分が初期値から更新されていることを確認するこ解決に成功し成功実績が更新されたためである．このことから障害知識ベースへの問い合わせ結果が解決実績によって優先順位をつけることが可能であると確認できた．
これらのことから，提案方式によって障害知識ベースに記録されている解決候補コマンド群が現在の障害を解決可能かどうか検証し，その結果を解決実績情報として障害知識ベースにフィードバックする サイクル
を継続的に行うことで，過去の実績から，より有効であるとされる解決候補コマンドを管理者に優先的に提案することが可能であると考えられる．
しかしながら，提案方式で自動解決できる障害はディレクトリツリーに関係するものに限られ るためこれ以外のネットワークやプロセスに起因する障害に対応すること，また解決実績情報は解決できたかどうかの二値判定であるので部分的な障害解決に関する実績を反映することが今後の課題である．

5. ま と め
本研究では，システム障害の効率的な解決を目的とした，複数サーバ環境での解決実績情報に基づいたシステム障害解決支援機構を提案し，その実現可能性について検証した．
提案手法では，過去の障害知識を記録する障害知識
ベースに現在の障害内容を問い合わせることで解決方法として得られるコマンド群を仮想検証環境上で自動実行し，その検証結果を解決実績として障害知識ベー
スにフィードバックすることで記録されたコマンド群に優先順位を付ける．このサイクルにより，障害知識
ベースは原因特定・解決に有用であるコマンド群の解
決実績情報を継続的に更新し，優先的に障害発生サーバ に 提 供 す る こ と が で き る ． 実 験 で は Linux 上 に 構 築した障害環境を再現した実験環境を用いて ，障害知識
ベースに記録された解決候補コマンド群を仮想検証環
境上で実行し，その解決実績情報が障害知識ベースへ反映されることで検索結果の優先順位に影響を与えることが可能であると確認できた．
今後の課題としてネットワークやプロセス起因の障害への対応，部分的な障害解決 実績の反映，より実際のサーバ稼働環境に近いデータ による評価が考えら
れる．

参

考

文

献

[1] “Amazon Web Services”, https://aws.amazon.com,
参 照 Jan. 2019.
[2] “Google Cloud Platform”, https://cloud.google.com,
参 照 Jan. 2019.
[3] “Microsoft Azure”, https://azure.microsoft.com, 参
照 Jan. 2019.
[4] “Datadog”, https://www.datadoghq.com/, 参 照 Jan.
2019.

[5] “New Relic”, https://newrelic.com/, 参 照 Jan. 2019.
[6] 永 井 崇 之 ， 名 倉 正 剛 ， ”迅 速 な 危 機 回 復 を 目 的 とす る 大 規 模 環 境 向 け 障 害 原 因 解 析 シ ス テ ム ”, 情報 処 理 学 会 論 文 誌 , Vol.54, No.3, pp.1109-1119,
2013[7] 中 村 友 洋 ， ”Web ア プ リ ケ ー シ ョ ン の 障 害 を 予 測
す る “ ア ク セ ス 時 間 解 析 方 式 ” の 提 案 ”， 情 報 処
理 学 会 論 文 誌 コ ン ピ ュ ー テ ィ ン グ シ ス テ ム（ ACS），
Vol.47， No. SIG12(ACS15)， pp. 349-357， 2006
[8] Holub，Viliam，et al.，”Run-time correlation engine
for system monitoring and testing”， Proceedings of
the 6th international conference industry session on
Autonomic computing and communications industry
session， pp.9-18， 2009[9] Wang, Miao, et al.， ”Scalable Run-Time Correlation
Engine for Monitoring in a Cloud Computing
Environment” ， Engineering of Computer-Based
Systems ， IEEE International Conference onthe(ECBS)， pp.29-38， 2010[10] Xu，Wei，et al.，”Online system problem detection bymining patterns of console logs”，Data Mining, 2009.
ICDM'09. Ninth IEEE International Conference on.
IEEE， pp.588-597， 2009[11] Xu ， Wei ， et al. ， ”Detecting large-scale systemproblems by mining console logs”， Proceedings ofthe 27th International Conference on Machine
Learning (ICML-10)， pp. 37-46， 2010[12] Mirgorodskiy ， Alexander V. ， et al. ， ”Problem
diagnosis in large-scale computing environments”，
Proceedings of the 2006 ACM/IEEE conference on
Supercomputing， p.88， 2006[13] Diao, Yixin ， et al. ， ”Rule-based problem
classification in it service management”， 2009 IEEE
International Conference on Cloud Computing. IEEE ，pp.221-228， 2009[14] 工 藤 裕 ， 森 村 知 弘 ， 菅 内 公 徳 ， 増 石 哲 也 ， 薦 田 憲
久 ， ”障 害 原 因 解 析 の た め の ル ー ル 構 築 方 法 と 解析 実 行 方 式 ”，電 気 学 会 論 文 誌 C（ 電 子・情 報・シス テ ム 部 門 誌 ）， Vol.132， No.10， pp.1689-1697，
2012[15] 阿 部 博 ， 敷 田 幹 文 ， 篠 田 陽 一 ， ”イ ベ ン ト ネ ッ ト
ワ ー ク に お け る syslog を 用 い た 異 常 検 知 手 法 の 提案 と 実 デ ー タ を 用 い た 評 価 ”， 情 報 処 理 学 会 論 文
誌 ， Vol.59， No.3， pp. 1006-1015， 2018[16] 西 野 博 之 , 坂 下 幸 徳 , 敷 田 幹 文 , “大 規 模 デ ー タ セ
ンターにおける運用ノウハウ共有による障害再発 防 止 方 式 の 提 案 ”, イ ン タ ー ネ ッ ト と 運 用 技 術
シ ン ポ ジ ウ ム 2013 論 文 集 , Vol.2013, pp.87-94,
2013[17] 加 藤 裕 , 敷 田 幹 文 , “障 害 予 測 に お け る 最 適 な 障 害
回 避 手 段 の 提 示 法 ”, イ ン タ ー ネ ッ ト と 運 用 技 術
シ ン ポ ジ ウ ム 2012 論 文 集 , Vol. 2012, pp.110-116,
2012