技報第 28 号

2016

効率的な障害処置順位や中央装置における障害予兆検知の提案機能
阪神高速技術(株)技術部情報管理課
阪神高速技術(株)技術部情報管理課
阪神高速道路(株)神戸管理部施設工事課

棚橋吉田原田卓也
翔克彦………………………………………………………………………………
要旨

阪神高速道路の安全・安心・快適な走行のために,道路上には情報提供や情報収集する設備や ETC 設備などの多種多様な電気通信機器と,それらのデータを処理し,管理する中央装置が 24 時間 365 日稼働している.
これら高速道路における基幹システムの障害は利用されるお客さまに対して,サービス提供の停止等の不便をおかけすることになるため,効率良く障害対応を行うためには,障害の兆候を早期に発見することが重要である.
本稿では,中央装置の稼働状況や各種統計情報を駆使し,平常時の計測データと比較することで異常値を見つける手法や,多種のアラームのなかから,処置の優先順位を示すことで効率的な補修運用を行った事例を紹介する.
キーワード：障害監視,パレート分析,障害処置順位,水準値分析,システムリソース,予兆検知

はじめに行い,処置の優先順位を示すことで効率的な補修運用を行った事例を,第 2 章で中央装置のリソー

阪神高速道路の安全・安心・快適な走行のためス（CPU とメモリ）使用状況を用いて,平常時のに,道路上にある情報提供や情報収集する設備やリソース使用状況と比較することで異常値を発見

ETC 設備などの電気通信機器（以降,端末装置）する分析手法により,中央装置の異常状態を早期と,それら設備からのデータの処理および管理やに検知し,対処した事例をそれぞれ報告する.

お客さまからの問い合わせを処理する中央装置が24 時間 365 日稼働している.
これら端末装置および中央装置で構成される基幹システムの障害は利用されるお客さまに対して,サービス停止等の不便をおかけすることになるため,効率良く障害対応したり,障害の兆候を早期に発見し処理することで,極力サービスの停止時間を少なくすることが重要である.
本稿では,第 1 章で端末装置の多種のアラームを統計し,その発生傾向を把握するための分析を

図-1 基幹システムの構成- 114 -１ ．端末装置における障害処置順位の提案機能
1-1 障害監視運用と課題
阪神高速道路には情報提供や情報収集する設備や ETC 設備といった端末装置が約 35 万台設置されており,それらの障害発生時は昼夜問わず迅速な対応が求められる.
しかし,障害の発生を通知するアラームが月約70 万件にもおよぶため,障害対応要員を効果的に配置し,障害処置を行うための優先順位の判断にノウハウを必要としていた.

図-3 全系統における設備別のアラーム発生割合

1-2 分析手法の検討(2) 分析手法

(1) アラーム発生の傾向

車両検知ヘッドについて,アラームが多く発生アラーム発生件数の多い設備を特定するため,5 つの系統（電力系,通信系,トンネル防災系,営している装置を特定するために,パレート分析を行った.

業管理系,交通管制系）別にアラーム発生件数をパレート分析は,構成比率の大きな順に最上位集計した後,アラーム発生件数の最も多い系統のの少数(A グループ),中位の少数(B グループ),下設備別のアラーム発生割合を集計した.

位の多数(C グループ)に分類し,それぞれを重要集計結果からアラーム発生件数は,系統別では度に応じた異なる扱いにすることで,対処すべき交通管制系が全体の約 80％であり,さらに詳細の対象グループに優先度をつけ管理効率を高める際設備別では,車両検知ヘッドが全体の約 50％であに用いられる手法であり,今回の分析では以下のることが判明した.

手順でパレート分析を行った.

これより,車両検知ヘッドのアラームを削減で①アラーム発生件数の順に端末装置を並べる.

きれば,障害対応要員のアラーム確認時間を大幅②アラーム発生件数の合計を 100 とし構成比率をに削減でき,効率的な障害処置が可能となる.

算出.

図-2 は系統別のアラーム発生件数,図-3 は全系③アラーム発生件数の順に構成比率の累計を算出.

統における設備別のアラーム発生割合のグラフで④構成比率の累計によってグループ分けを実施.

ある.

今回は構成比率を以下のグループで実施した.
（単位：％）A グループ： 0～70
B グループ：71～90
C グループ：91～100
図-4 は車両検知ヘッドのアラーム発生件数のパレート図である.

図-2 系統別のアラーム発生件数- 115 -

表-1 車両検知ヘッドアラーム発生状況
No

アラーム発生日時

アラーム復旧日時

アラーム継続時間1

2013/7/1 0:01

2013/7/1 0:02

0:01:00

大阪地区 1号環状線

地区

環4.5 -03 車両検知ﾍｯﾄﾞ2

2013/7/1 0:02

2013/7/1 0:03

0:00:30

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ3

2013/7/1 0:04

2013/7/1 0:04

0:00:30

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ4

2013/7/1 0:05

2013/7/1 0:06

0:00:30

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ5

2013/7/1 0:07

2013/7/1 0:07

0:00:30

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ6

2013/7/1 0:08

2013/7/1 0:090:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

7

2013/7/1 0:09

2013/7/1 0:10

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ8

2013/7/1 0:11

2013/7/1 0:12

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

9

2013/7/1 0:12

2013/7/1 0:13

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

10

2013/7/1 0:14

2013/7/1 0:15

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

11

2013/7/1 0:15

2013/7/1 0:16

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ::::30015

2013/7/31 23:54

2013/7/31 23:55

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

30016

2013/7/31 23:55

2013/7/31 23:56

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

30017

2013/7/31 23:57

2013/7/31 23:58

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

30018

2013/7/31 23:58

2013/7/31 23:59

0:01:00

大阪地区 1号環状線

環4.5 -03 車両検知ﾍｯﾄﾞ

:

路線名

:

設備名称

:

図-4 車両検知ヘッドのアラーム発生件数のパレート図(2) 効果アラーム発生状況の分析結果より,障害の予兆

1-3 パレート分析による成果が大量のアラームを発生させていることが分かっ(1) 分析結果

た.

車両検知ヘッドのアラームについて,パレート

したがって,車両検知ヘッドに障害の予兆が発分析を行った結果,全ヘッド 2,286 台の内, A グ生した段階で予防処置を行えば,大量のアラームループに属する 8 台の設備について対策を行うだが削減できるため,車両検知ヘッドの障害発生件

けで,車両検知ヘッドで発生しているアラームの数を毎月集計し,毎月上位 5 台について予防処置うち約 70%が削減でき, B グループに属する 6 台を行う運用を試行した結果,5 ヵ月で 80 万件からの設備も加えた計 14 台を対策すれば,車両検知ヘ50 万件にアラーム件数が削減された.

ッドのアラームの約 90%が削減できることから,ごく一部の車両検知ヘッドでアラームの大部分を

図-5 は,試行運用後のアラーム件数削減推移のグラフである.

占めていることが判明した.
また A,B グループの車両検知ヘッドのアラーム内容を詳細に分析した結果,発生しているアラームの継続時間（アラーム復旧時間-アラーム発生時間）が 30 秒～1 分程度で,復旧後に即,次のアラームが発生していることが判明した.本事象はこれまでの障害対応実績より,車両検知ヘッドの故障の予兆が多いことが確認できている.

図-5 試行運用後のアラーム発生件数推移

これより,アラーム発生件数の多い車両検知ヘ
ッドは完全に故障してはいないが,障害の予兆を示している状態である事が判明した.

化し,出力できるシステムを導入すれば,容易で均

表-1 は A グループに属するある 1 台の車両検知ヘッドのアラーム発生状況の例である.

このため,アラーム発生件数の集計割合を帳票一的な処置が誰でも可能となり,効率的な運用が可能と考えた.

- 116 -

図-6 は設備種別指定画面,図-7 は帳票出力画面

２ ．中央装置の障害予兆検知である.
2-1 障害監視運用とその問題点
中央装置の障害監視の運用は,中央装置の稼働状況,とりわけ OS・ミドルウェア・アプリケーションプログラムといったソフトウェアの稼働状況を把握することは難しく,かつこれらは冗長構成等の対策もとれない.
したがって,障害が発生してから対処する「受動的な維持管理」により,障害が復旧するまではお客さまに対して影響があった.
図-6 設備種別指定画面
2-2 分析手法の検討
電力系

通信系

営業管理系

交通管制系

日付TN
防災系

差割合

平成26年06月

372,644-23,58286.3%

431,983

平成26年07月

387,838

15,194

82.1%

472,432

494,591

106,753

83.4%

平成26年09月

468,633-25,958

平成26年10月

409,225-59,408

平成26年11月

336,394-72,831

平成26年08月～(1) 中央装置のシステムリソース

総計

件数

中央装置は様々なシステムリソースから構成され,それらシステムリソースは使用状況を計測す

592,995ることができる.表-2 は,代表的なシステムリソ

89.0%

526,266ースとその計測可能項目の一覧である.

88.0%

464,909

82.8%

406,097～

表-2 代表的なシステムリソースとその計測可能

図-7 帳票出力画面

項目
システムリソース

システム化後,アラーム発生原因の特定が容易

計測可能項目CPU・CPU使用率（単位時間当たりの使用時間）

メモリ・メモリ使用率（物理メモリ量に対しての使用量）

ディスク・ディスクへI/O率（単位時間当たりの書込み量・読込み量）
・ディスク使用量（物理ディスク量に対しての使用量）となり効率的な障害処置が可能となったことで,アラーム発生件数が,夏季に多数の車両検知ヘッドが故障したことによる一時的な増加はあったものの,徐々に減少し,最終的にはアラーム発生件数ネットワークが 30 万件と当初の半分以下となった.
図-8 はシステム化後のアラーム発生件数推移
である.

・ネットワーク流量（単位時間当たりの送受信量）

これらシステムリソースは OS・ミドルウェ
ア・アプリケーションプログラムの障害時に変化することが想定されるため,これらに起因したシステム障害を未然に防ぐことが期待できると考えた.
(2) 分析手法
中央装置の正常運用時のシステムリソースを計測し水準値を把握することで,通常運用時のシステムリソースの使用の変動と比較すれば,中央装置の異常を検知できると考えた.

図-8 システム化後のアラーム発生件数推移

中央装置の主要リソースである,CPU とメモリに焦点をあて,それらの水準値を策定するために- 117 -

1 ヵ月間,正常稼働時の使用状況を取得した.また

2-3 水準値分析による成果

CPU およびメモリの特性を考慮し,以下の集計方(1) CPUの使用異常によるプログラムの不具合を法とした.

早期に発見

・CPUは同時間帯でどのような使用がされている

1)事象か判断するため,横軸を時間とし,1ヵ月分のデー

2014年9月の集計結果において,WEB装置でCPUのタの同時間帯の値から最大値を算出し,グラフ化

使用状況が通常は最大でも約30％にも関わら・メモリは1ヵ月間を通して,メモリが解放されなず,9/10 21:20～21:40の間に最大で100％に達し,い事象（メモリリーク）を把握するために,横軸高負荷状態となったことを確認した.

を日とし,グラフ化

WEB 装置の CPU が高負荷状態になると,阪神高

上記の集計方法をもとに約200台の中央装置の速の各種 WEB サービス（企画割引申込 WEB・環境水準値を策定した.図-9および図-10はETCの利用

ロードプライシング申込 WEB・回数券付替サービ

明細の入口・出口のマッチングを行う装置AのCPU

ス WEB・課金訂正受付 WEB・阪高割引施策受付およびメモリの変動パターンである.

WEB）の処理が遅延したり,最悪の場合,システム本装置を例にとると,CPU に関しては,0 時～2時の時間帯はバックアップ処理により最大でダウンし各種 WEB サービスを提供できず,お客さまに影響を及ぼす.

100％に達し,それ以外の時間帯は 30％～60％が

図-11は水準値と2014年9月の計測値をグラフ化

本装置の変動パターンの水準値である.一方でメしたもの,図-12は2014年9月の計測値をより詳細

モリに関しては約 75％で一定して使用するのが,に把握するために,異常の時間帯を拡大したもの

本装置の変動パターンの水準値であることが分かである.

る.

図-11 WEB装置における水準値と計測値
図-9 CPU変動パターンによる水準値例

図-12 WEB装置における計測値（詳細）図-10 メモリ変動パターンによる水準値例（2014/9/10 20:00-22:00）

通常運用時に集計したリソース使用状況が,策2)原因調査定した変動パターンによる水準値のグラフから逸脱していないか比較することとした.

異常を検知できた時間帯の全5つのWEBサービスのアプリケーションログを調査したところ,環境- 118 -ロードプライジングのアプリケーションのログに,・行追加ボタンの削除申込画面の「行追加ボタン」を押下したログが1・標準で100件まで登録できる入力フォームを秒間に10件のペースで断続的に30分間押下された準備およびスクロールバーの追加ログが出力されていた.

システム改修以降は同事象が発生することはな

また最大で100件までしか「行追加ボタン」でく,安定稼働している.

行を追加できないにも関わらず,100件以上行を追加しようとするログも出力されていた.図-13はアプリケーションログの抜粋である.

図-15 対策後の申込画面(2) メモリの使用異常によるWindowsの既知不良を早期に発見
1)事象
図-13 アプリケーションログ（抜粋）コンタクトセンターの装置において,水準値の変動パターンから逸脱し,かつ日々上昇し続け,メ「行追加ボタン」の連続押下により,システムモリが解放されない事象（メモリリーク）を確認の高負荷が続いたと考えた.断続的に高負荷状態した.また水準値の策定のために,データを取得しとなると,システム停止やレスポンス低下を引き始めた直後から,発生していることも合わせて確起こす可能性がある.図-14は環境ロードプライジ認した.

ング申込画面と行追加ボタンである.（標準は5件コンタクトセンター関連装置のメモリが不足すまで登録できる入力フォームが用意されており,ると,お客さまとの電話中に切断したり,オペレー

最大100件まで「行追加ボタン」で行を追加できタがお客さまの情報を入力するシステムで異常がる仕様）発生し入力できないといった影響がある.
またコンタクトセンター関連装置9台のうち6台で同事象が確認できた.図-16は6台のうちの1台（コンタクトセンター装置A）のメモリ使用状況である.

図-14

環境ロードプライジング申込画面と行追加ボタン

3)対策
当初の設計における想定外の利用方法によるこ

図-16 コンタクトセンター装置Aのメモリ使用率とから,以下のシステム改修を行った.
- 119 -

2)原因調査
水準値の変動パターンから逸脱し,かつ1ヵ月に数％メモリ使用率が上昇している要因がどのプログラムかを特定するために,2015年1月の月初と月末でモニタリングしところ,svchost.exeというWindowsの各サービスを起動するための親プログラムがメモリ上昇の要因であることが分かった.
また本事象が確認できた6台の装置の共通点を調査すると,OSがWindowsであり,かつバージョン

図-18 修正パッチ適用後のコンタクトセンターも2012を搭載している装置であることが確認でき装置Aのメモリ使用率た.前述したとおり,本事象はデータを取得し始めた当初から発生していることも合わせて確認でき

３ ．まとめている.
したがって,Windows2012に共通的な不具合があ

本稿では,今まで活用されていなかった端末装ると推測し,Microsoft社が公開している技術サポ

置のアラームおよび中央装置のリソースデータをート一覧を調査したところ,Windows2012にメモリ活用・分析することで,効果が得られた事例を紹が解放されない既知の不具合があることが判明し介した.
端末装置に関しては,大量のアラームを発してた.図-17はMicrosoft社の技術サポートの公開情いる装置が特定でき,効率的な補修運用を行うこ報である.とで,大量のアラームが削減された.また結果的に特定した装置のアラームが障害の予兆であることも合わせて特定でき,予防保全を実施することで障害発生によるお客さまに対するサービス停止を未然に防ぐ効果もあった.
今後は大量のアラームに埋もれていた他アラームについても傾向分析を行うことでさらに有効な施策を探っていきたい.
一方,中央装置に関しても,障害発生前の予兆を示す装置が特定でき,2 件の大規模なシステム障図-17 Microsoft社の技術サポート公開情報

害の可能性を未然に防ぐことができた.
今後は,今回調査対象から除外したディスクお3)対策

よびネットワーク関連のリソースを用いたシステ

Microsoft社はこの不具合に対する対策版（修ム障害の予兆検知方法も検討していきたい.

正パッチ）を公開しているので,検証環境での確認後,対策版（修正パッチ）を適用した.

謝辞：本論文を執筆するにあたり,ご協力いただ

図-18は修正パッチ適用後のメモリ使用状況でいた大阪管理局保全部システム保全課,ならびにあるが,約30%で安定して稼働していることが分か

大阪管理局保全部施設工事課の方々に深く感謝のる.

意を表します.

- 120 -DETECTION OF SIGNS OF SERVER FAILURE AND PRIORITY SETTING FOR FIXINGTERMINAL EQUIPMENT FAILURES
Takuya TANAHASHI, Sho YOSHIDA and Katsuhiko HARADAFor ensured safety, reliability and comfort of vehicles, there are a variety of electrical communicationequipment on the Hanshin Expressway including traffic control equipment, electronic toll collection
equipment and their servers which are operated 24 hours a day, 365 days a year. Since failures of themission-critical system cause serious consequences to users, it is important to detect failure signs earlyand fix them efficiently. This report proposes a method to detect server failure signs by comparing
current status data with normal-state measurements, and also presents a sample case of efficient
implementation of repairs based on priorities set by using statistically processed alarm data.

棚橋 卓也

吉田 翔

原田 克彦

阪神高速技術株式会社
技術部 情報管理課
Takuya Tanahashi

阪神高速技術株式会社
技術部 情報管理課
Sho Yoshida

阪神高速道路株式会社
神戸管理部 施設工事課
Katsuhiko Harada

121