AI・機械学習によるネットワークオペレーションの高度化に向けた取り組み
NTTネットワークサービスシステム研究所

NTTアクセスサービスシステム研究所
NTTネットワークイノベーションセンタ
2021年12月16日
Copyright(c)2021 NTT Corp. All Rights Reserved.

本日の発表内容の概要• 現在、ネットワークの安定運用を目的として、ネットワークから収集したデータの分析に基づいたオペレーションの高度化・自動化が注目されています。
• 特にAI関連技術の発展は近年著しく、関連領域への適用が強く期待されています。
• 本発表では、大規模故障や激甚災害など想定外事象への迅速な対応が求められる一方で、 人手による作業が多く運用現場の疲弊が問題となっている保全領域について、 NTT研究所における関連技術の検討状
況や適用例についてご説明します。
Copyright(c)2021 NTT Corp. All Rights Reserved.

1

取り組みの全体像

Copyright(c)2021 NTT Corp. All Rights Reserved.

2オペレーション保全領域における高度化
運用対象となるネットワークの各種リスクに対して①監視、②分析、③措置を行うため、各フェーズで知能化を図ると共に、そのベースとなる④構成情報を収集・活用するための仕組みや、監視・分析・措置を⑤ループとして回すために必要なワークフローに関するNTT研究所の取り組みついて、本発表では説明する。
運用対象となるネットワーク

NW外部情報

仮想ネットワーク

NW内部情報

仮想
サーバ

仮想ルータ

リスク発生
NW内部情報輻輳故障

物理ネットワーク
観測情報

構成情報

Copyright(c)2021 NTT Corp. All Rights Reserved.

監視

分析

措置

輻輳検知

要因特定

故障検知

影響把握

経路制御・
機能配置変更故障対応

文献[1]の図1をベースに作成[1] 原田, 渡辺, 中野, 池田, 松尾, 小林, 鈴木, 川原, "プロアクティブ制御型ネットワークの実現に向けた取り組みの紹介," 信学会総合大会, B-7-32, 2017.

措置・制御情報

ループを回すためのワークフロー

3

以降の説明内容① 監視に関する技術

異常検知技術「DeAnoS」② 分析に関する技術

故障箇所推定技術「DeAnoS-RCA」
故障箇所推定技術「Sherlook」③ 措置に関する技術


対処レコメンド技術
ワークフロー可視化技術
復旧コマンド列の生成技術④ 構成情報の収集・活用に関する技術

ネットワークリソース管理技術
トポロジ推定技術⑤ ループを回すためのワークフローに関する技術

オーケストレータ技術（カタログ記述量削減技術）

Copyright(c)2021 NTT Corp. All Rights Reserved.

4

監視に関する技術- 異常検知技術「DeAnoS」

Copyright(c)2021 NTT Corp. All Rights Reserved.

5

目指す世界
潜在的な性能劣化リスク（故障・輻輳等）や需要変化を異常として予見的・早期に検知し、事前の制御・早期/自動復旧を目指す
従来

将来（経路切替で対応不可の場合）

サーバ切替

事前の
経路切替

リアクティブ
な経路切替
故障
発生

輻輳
発生

駆け付け保守
復旧作業の長期化

Copyright(c)2021 NTT Corp. All Rights Reserved.

QoE劣化

事前の
機器交換

自動
復旧

予兆検知

NW・システムログ、外部情 QoE維持
報（イベント情報等）

6

現状の問題点とアプローチ• 問題点– 現状の異常検知は閾値ベースで実施しているケースが多いが、多種の時系
列データ（トラフィック、リソース（CPU、メモリ、etc…））に対する
閾値設定は非常に手間がかかる– 閾値は予め想定した事象に設定するものであり、想定外の事象（サイレント故障などの特異故障）は検知できない場合がある• アプローチ– ディープラーニングを用いて、ネットワークや各種システムから取得される多様なデータに基づいて、それらの正常状態を学習– 学習した正常状態からの乖離を基に異常検知を実施– 異常検知後、異常要因となる特徴量を推定

Copyright(c)2021 NTT Corp. All Rights Reserved.

7

「DeAnoS」技術概要
 多様なデータに潜む性能劣化リスクを事前・早期に検知する技術を開発中
 数値やテキストログを含む多様なデータ間の正常時の関係性を学習することで、現在の状態の異常度を判定
syslog

前処理・特徴生成後の数値ベクトル

STEP1
多様なデータを収集し、前処理・特徴量生成2016/12/01 00:00 {0.2, 0.4,
0.7, ....}
2016/12/01 00:01 {0.4, 0.8,
0.3, ....}
...

MIB

netflow

異常検知
異常度

STEP2
オートエンコーダ(AE)による異常検知時刻

STEP3
検知後の異常要因推定

特徴量A（異常要因）
特徴量B

異常検知結果から異常要因となる特徴量を推定

特徴量C

Copyright(c)2021 NTT Corp. All Rights Reserved.

・
・
・

8

前処理・特徴量生成(STEP1)• 前処理– AEは入力特徴量として正規化（または標準化）された数値ベクトルを取るが、システムから取得したデータにはトラヒック量のように時間的なトレンドを持ち正規化が難しい（最大値を定義しにくい）数値データや、syslogのような文字列である非数値データを含む
 観測データを用いてリアルタイムにモデルを再学習させる事で、時間的なトレンドに追従した正規化を実施。
syslogについてはIDを付与し、IDの出現回数を特徴量とする事で数値ベクトル化• 特徴量生成– トラヒックデータ（MIB、netflowなど）に加え、syslogも用いて特徴量の時系列を作成
 例）毎分の「TCP通信の総バイト数」 「syslog ID xx の出現回数」 「ホスト××における総入力バイト数／秒」 etc.．
 syslogはテキストログなので、テンプレート化してからそのIDの出現回数を特徴量とするシスログを用いた特徴量生成例（ログテンプレート化技術で付与されたIDの出現回数を特徴量とする場合）

syslog（ID付与済み）

12:04の
特徴量の
集計対象

時刻

messageID

12:03:02

ikeda login failed

0

12:03:17

nakano login failed

0

12:03:36

received power low warning1

12:03:48

free disk space is less than 20%

2

12:04

12:03:58

free disk space is less than 10%

2

12:05

12:04:01...

Copyright(c)2021 NTT Corp. All Rights Reserved.

t

ID_0
...
2
...
...

ID_1

ID_2

1

2

...

9

オートエンコーダ(AE)による異常検知(STEP2)

Deep learningによる異常検知技術として注目[x1][x2][x3]。正常時のデータを入力した時に、出力が入力と近くなるように学習。テスト時には入力データと出力データの平均二乗誤差を確認し、その値が大きい場合は入力データが異常と判断
正常時の入力データがメトリック間で相関関係を持ち、低次元に圧縮可能であることを利用。
異常時には入力データの相関関係が崩れ、圧縮が正しく行われずに入力データと出力データとの差MSE（mean squared error）が大きくなる

学習時

テスト時

出力
データ

入力
データ

近くなるように学習

入力
データ

出力
データ

1

MSE = 𝑛 σ𝑛𝑖=1(𝑥ො𝑖 − 𝑥𝑖 )2

異常度として出力[x1] T. Tagawa et al., “Structured Denoising Autoencoder for Fault Detection and Analysis,” JMLR: Workshop and Conference Proceedings, 2014.
[x2] 櫻田麻由他, “オートエンコーダを用いた次元削減による宇宙機の異常検知,”人工知能学会全国大会論文集 28, 1-3, 2014.
[x3] Jinwon An et al., “Variational Autoencoder based Anomaly Detection using Reconstruction Probability,” SNUDM-TR-2015-03.
Copyright(c)2021 NTT Corp. All Rights Reserved.

10AEベース異常検知の特徴
 各監視データ間に跨る（非線形な）関係性に基づいて、異常か否かを判定

トラヒック量 トラヒック量例）間欠的な疎通不良を検知したい場合（イメージ図）A→B

ネットワーク
B

A

閾値ベース

B→C
閾値を下回る
ことを検知

Copyright(c)2021 NTT Corp. All Rights Reserved.

C

ルータ

見逃し

検知

間欠的に
通らない！

関係性を見て
正しく検知

AEベース

トラヒック量 トラヒック量閾値ベース異常検知では、各監視項目に対して適切な閾値設定を行う必要あり（設定を誤ると誤検知・見逃しが発生）【下図】
多様なデータ間の関係性（例：syslogの出現有無も考慮するような場合）は非線形となる可能性があり、そのような場合にも対応可能と期待

時刻

検知

誤検知

異常度



検知

時刻

閾値

11

検知後の異常要因推定（STEP3）••

AEは特徴量間の相関関係の崩れから異常を検知するが、どの特徴量が要因で崩れが生じているかまでは分からないAEが出力する異常度への影響が大きい特徴量を、特徴量を変化に対する異常度の変化を観測することにより探索、探索結果を異常要因として推定

特徴量

異常度

特徴量を変化させた場合の異常度の変化を観測
Copyright(c)2021 NTT Corp. All Rights Reserved.

12

実施イメージ
ネ
ッ
ト
ワ
ー
ク

×

故障発生

データ収
集

閾値ベース
収
集
デ
ー
タ
の
時
系
列

AutoEncode
r

異常度

AEベース
即座に検知

異常度を最小化する
ベクトル探索

故障発生前
に誤検知
・・
・

Copyright(c)2021 NTT Corp. All Rights Reserved.

故障発生したが、変化が小さく検知できない

The degree of abnormality
router-c ibps : -0.05
router-c obps : -0.04
故障箇所も特定13

今後の改善について

Copyright(c)2021 NTT Corp. All Rights Reserved.

14参考：各技術の詳細• DeAnoSのご紹介– https://www.youtube.com/watch?v=Anp7Toi6bM0• DeAnoS-RCAのご紹介– https://www.youtube.com/watch?v=R5g5hBNUSFQ

Copyright(c)2021 NTT Corp. All Rights Reserved.

15参考： @DeAnoSの製品化について（１）Copyright(c)2021 NTT Corp. All Rights Reserved.

16参考： @DeAnoSの製品化について（２）Copyright(c)2021 NTT Corp. All Rights Reserved.

17

分析に関する技術- 故障箇所推定技術「DeAnoS-RCA」- 故障箇所推定技術「Sherlook」

Copyright(c)2021 NTT Corp. All Rights Reserved.

18

故障箇所特定に関する現状の問題点とアプローチ• 問題点– ネットワークにおける故障発生時には、異常が伝播して多数のアラートが発報されるケースが散見されます– オペレータは、多数のアラームを読み解いて、故障箇所を特定して問題の解決を図る必要がありますが、熟練のオペレータでも時間を要す場合があります• アプローチ– そこで、アラームなどの観測情報から故障箇所を推定する技術を開発して、故障箇所の特定を効率化する技術の検討を進めています。
• モデルベース：DeAnoS-RCA– 事前のルールの学習は不要である一方、計算量を要する• ルールベース：Sherlook– 事前のルール学習を要するが、計算量は小さい
Copyright(c)2021 NTT Corp. All Rights Reserved.

19

分析に関する技術- 故障箇所推定技術「DeAnoS-RCA」※モデルベース

Copyright(c)2021 NTT Corp. All Rights Reserved.

20

「DeAnoS-RCA」技術概要– 事前構築した故障箇所と観測値（各機器のアラーム有無）の因果関係をもとに、分析技術で故障箇所を推定– 想定外の故障にも対応するため、因果関係の修正をしながら故障箇所を推定
Before

障害時の多量ログや想定外事象の発生時は、故障箇所を特定するルールがないため、故障切り
分けが長時間化管理者
Copyright(c)2021 NTT Corp. All Rights Reserved.

After

トポロジーから因果関係を事前に構成しておくことで、故障発生時は自動で故障箇所を推定し、切り分け時
間を短縮化

管理者
21

技術のポイント•••

ネットワークトポロジーや、過去の故障時のデータから各機器の故障と観測データの因果関係を規定。
因果関係をまとめた因果モデルを構築（※1）
Syslog、アラートやDeAnoSの出力結果などの観測情報を入力とし故障箇所を推定。想定外の特異事象にも対応するため、因果モデルの修正などを同時に実施
本技術領域における主要な既存技術であるshrink[1]と比較（定型的な故障にのみ対応可能）––

非定型な故障に対応することで本技術が既存技術よりも高精度に推定できることを確認（※2）
シミュレーションでは、最大30%の精度改善により100%の精度を達成。実際のNW故障の実例に対しても100%の精度を達成

本技術※1：技術の利用にはトポロジーデータ or 過去の故障時のデータが必要となります※2：シミュレーション/実際に起きた過去の故障に対する精度であり、全故障種類に対しての精度ではありません[1] S. Kandula, D. Katabi, and J.-p. Vasseur, “Shrink: A tool for failure diagnosis in IP networks,” Proceedings of the 2005 ACM SIGCOMM workshop on Mining network data, pp. 173–178, 2005.
Copyright(c)2021 NTT Corp. All Rights Reserved.

22

本技術とDeAnoSの関係•

DeAnoSの要因推定技術のアウトプット（データの主要因となる特徴量）をインプットとし、故障機器を推定– DeAnoSにより異常発生検知、異常の主要因となるデータを推定するが、NWの機器故障の場
合、異常が伝搬するため異常の主要因を絞りきることができず、故障箇所を特定できない– 本技術を用いて、複数の異常なデータから故障機器を特定する
DeAnoS

検知

異常の主要因（ ）となる
特徴量を推定本技 主要因となる複数特徴量
から故障機器を推定術
サーバＡ

複数特徴量が主要因となり故障機器が不明
本技術の入力とする
入力
データ

サーバＢ
ルータＣ

出力
データ

ルータＤ
ルータＥ
ルータＦ
ルータC

ルータC
サーバB
サーバA

x1

サーバB

x3

サーバA
ルータD

ルータE

ルータF

x6

x2

x5

x4

Copyright(c)2021 NTT Corp. All Rights Reserved.

x1

ルータC

x3
ルータD

サーバB
サーバA

ルータE

ルータF

x6

x2

x5

x4

x6

x1

x2

x3
ルータD

ルータE

ルータF

x5

x4

23

分析に関する技術- 故障箇所推定技術「Sherlook」※ルールベース

Copyright(c)2021 NTT Corp. All Rights Reserved.

24

ネットワーク保守の現状と問題点• 保守者のスキルやノウハウに頼って、アラーム分析や切り分けを実施• 多様化・複雑化したネットワークの障害対応で、復旧に多大な時間と保守者稼働が必要
アラーム分析
アラーム・ログ稼働【障害対応フロー】
障害箇所
切り分け指示② 多種多様なアラーム発生
スキル

切り分け試験

監視システムアラーム
ＮＷ① 障害発生

③ アラーム等を分析④ 切り分け試験

試験ツール
稼働 スキル

スキル
稼働⑤ 障害箇所を特定⑥ 対処方法の検討⑦ 対処実施Copyright 2020 NTT CORPORATION

25

「Sherlook」技術概要
保守者のスキルやノウハウに頼っていたネットワーク障害発生時のアラーム分析・切り分け・対処手順検討を支援し、保守者の稼働を削減• 特徴① 障害発生時のアラーム・障害箇所に基づき、障害箇所を推定するルールを学習• 特徴② 障害に対する過去の対処（復旧方法）実績に基づき、最適な対処方法を提示（レコメンド）
アラーム分析
障害箇所
切り分け指示アラーム・ログ
稼働

対処レコメンド

障害箇所推定分析・切り分け試験不要

スキル

切り分け試験

対処実績

障害箇所
ルール
推定システム

対応結果を記録

ルール学習
監視システム

アラーム

試験ツール
稼働

スキル

ＮＷ

人力での
分析作業
監視システム

障害対応記録から新たなルールを学習・蓄積

アラーム

ＮＷ

Copyright 2020 NTT CORPORATION

監視システム特徴的なアラームから障害箇所を推定し、対処方法を提示26

障害箇所推定ノウハウの例①アラームの監視
監視システムアラームA③保守者の知識（ルール）・故障αの時は故障装置からアラームAが発生
・故障αの時は隣接装置からもアラームBが発生

アラームB
アラームX

装置1

装置2

・装置１からアラームAが発生
・装置２からアラームBが発生
分析②構成情報の確認
装置1④分析結果
・障害箇所は装置１・障害原因は故障α

装置2・装置１と装置２は隣接（接続）関係
Copyright 2020 NTT CORPORATION

27

ルール学習の仕組み（a） 障害αが発生 → 装置Eを障害箇所としてルール学習
アラームa

アラームe

アラームd

D

E

[凡例]

アラームc

B

A

Copyright 2020 NTT CORPORATION

アラームb

障害α

C

アラームf

F

新規ルール生成障害αのルール

ルール学習

障害固有アラーム（a, b, c, d, e, f）

スイッチ
アラーム
障害原因箇所

障害α発生時に出ていたアラームをルールとして学習

28

ルール学習の仕組み（a） 障害αが発生 → 装置Eを障害箇所としてルール学習
アラームa

アラームb

障害αのルール

B

A

アラームe

アラームd

E

障害α

C

F

（b） 障害βが発生 → 装置Eを障害箇所としてルール学習障害βのルール生成、障害αのルール修正
アラームa

アラームg

アラームc

B

A

アラームh

アラームd

E

D

障害β

C

アラームi

F

新規ルール生成障害βのルール
障害固有アラーム（g, h, i）

ルール学習
障害αのルール

障害αと障害βとで、アラーム a, c, d が共通して発生Copyright 2020 NTT CORPORATION

スイッチ
アラーム
障害原因箇所

障害固有アラーム（a, b, c, d, e, f）

アラームf

D

[凡例]

アラームc

既存ルール修正障害固有アラーム（a, b, c, d, e, f）

学習済みの障害αと比較して、障害βで固有なアラームの組み合わせ（g, h, i）を抽出

他の障害（障害β）と比較して、障害αで固有なアラームの組み合わせ（b, e, f）を再抽出

29

画面イメージ

Copyright 2020 NTT CORPORATION

30

画面イメージ

アラーム
第一候補

第二候補

特長①
障害箇所の候補を瞬時に可視化
Copyright 2020 NTT CORPORATION

31

画面イメージ

アラーム情報特長②推定に使用したアラームを表示
Copyright 2020 NTT CORPORATION

32

画面イメージ

第一候補のみ特長③
学習を繰り返すことで推定精度が向上
Copyright 2020 NTT CORPORATION

33

【参考】ルール学習パターン
× … アラーム

学習パターン（１）： 新規ルール生成異なる障害ケースと比較し、各障害ケース特有のアラームの組み合わせを自動抽出

障害ケースＡ×××××

障害ケースＢ
×

×

×
×

×

障害ケースＣ

学習パターン（２）： 新規ルール強制生成（部分集合）

障害ケースＡ

障害ケース特有のアラームの組み合わせが存在しない

学習パターン（３）： 既存ルール汎化
同一の障害ケースで発生していたアラームと比較し、その発生頻度から重要アラームを自動抽出

××※特定のアラームが「発生していない」ことを条件とするルールを学習することも可能×

障害ケースＡ
5/1発生

×

×

×
×
×

×

障害ケースＡ
5/8発生

×

×
×

Copyright 2020 NTT CORPORATION

障害ケースＢ××

×

障害ケースＡ
5/25発生※いずれのパターンにおいても、フィードバックした障害ケース以外の既存ルールを併せて適正化

34

措置に関する技術- 対処レコメンド技術- ワークフロー可視化技術- 復旧コマンド列の生成技術
Copyright(c)2021 NTT Corp. All Rights Reserved.

35

措置に関する技術- 対処レコメンド技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

36

「対処レコメンド」技術概要
Sherlookによる障害箇所推定の後、障害原因に対して対処実績を様々な属性情報とともに蓄積し、復旧までの対処時間/回数について最も少ないと推定されるパターンの対処をレコメンド
従来

対処レコメンド＜障害箇所推定＞
故障
装置
PKG故障

＜復旧対処＞

変更
前後

ｹｰﾌﾞﾙ交換（失敗）＜障害箇所推定＞
故障
装置
PKG故障

＜復旧対処＞
設定替え
（失敗）

再起動
（成功）

課題：経験による対処作業により復旧時間の長時間化

故障装置

装置の対処実績を様々な属性情報とともに蓄積

対処: ｹｰﾌﾞﾙ交換 ？
対処: 設定替え ？
対処: シャーシ再起動 ？

Copyright 2020 NTT CORPORATION＜優先対処＞

①装置種別

再起動

故障
装置

②メーカ

設定替え

PKG故障

③年数

ケーブル交換過去の対処実績から作業回数、作業時間を参考に、
回数・時間が最も少ないパターンの対処をレコメンド。

障害箇所を提示
障害対処案を提示

対処＜属性情報＞

装置の対処実績から対処実施属性情報をもとに優先すべき対処を
提示

対処を
レコメンド

対処1: シャーシ再起動
対処2: 設定替え
対処3: ｹｰﾌﾞﾙ交換

37

措置に関する技術- ワークフロー可視化技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

38

「ワークフロー可視化技術」技術概要
 蓄積された作業記録からの作業手順の自動抽出により、サービスの運用品質向上・定型化コスト削減を実現

サービス多様化により故障対応が複雑化。多様な懸念事項で定型化が難しくなり、故障対応が運用者の知識に依存
運用者の記述した作業記録を機械学習(AI)技術で解釈し、暗黙知である対処の判断条件・故障原因・対処手順を取り出し、ワークフローとして可視化

サービス運用における課題

確立技術
異常発生

多様化したネットワーク

対処判断で運用者が考慮すべき要素は多様
影響ユーザ

顧客との契約条件

残存セッション数
冗長構成

ご連絡先
即時対応条件

一刻を争う復旧
SLA

故障原因
エラーログ
固有設定

システム負荷過去の故障歴...

運用者の暗黙知依存の故障対応・切迫した故障対応での作業漏れ
・知識不足による故障対応の停止・長期化
Copyright(c)2021 NTT Corp. All Rights Reserved.

多量の作業記
録
履歴ID

発生日時

012345

2016/7/7 9:00

事象名Moduleの故障

機械学習(AI)による作業手順の可視化
故障対応のワークフロー

作業記録
07/07 アラーム発生装置ログインし異常確認#show system
Module Error
モジュールが停止中
11:00 現地到着の連絡有
11:15 モジュール交換
11:30 復旧しました
12:00 ベンダ解析依頼
Mail from : xxxx
交換完了でクローズします

・作業記録は大量で、知見獲得に多大な労力が必要
・自由記述のため、記述された作業内容の解析は困難

対処の判断条件、故障原因、対処手順を明確化
・作業漏れを防止
・故障対応を迅速化

39

技術のポイント

故障対応作業記録（トラブルチケットログ）から作業手順（ワークフロー）を抽出・可視化する技術により、故障対応定型化・自動化を目指す。
機械学習による複数作業記録の比較分析によって、記述レベル・内容にばらつきがある運用者自由記述である作業記録からワークフローを抽出。
作業分岐の切り分け、判断の根拠を可視化可能。

Copyright(c)2021 NTT Corp. All Rights Reserved.

40

措置に関する技術- 復旧コマンド列の生成技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

41

復旧シナリオに関する現状の問題点
 復旧シナリオ作成に多大な稼働が必要
 復旧事例ごとに、「ログ/アラームと復旧コマンド列を紐づけるルール」、及び「復旧コマンド列そのもの」を、有識者が多大な時間をかけて作成

 復旧シナリオの自動実行には信頼度の考慮が必要
 信頼度：復旧シナリオが適切な処置である可能性、復旧シナリオの一意性
 信頼度が低い場合、実行には人の判断が必要
 復旧シナリオの信頼性

 復旧シナリオ作成の困難性
Jun 19 14:00:00 proc01 DEBUG [req-12345] accepted ( IPv4, 12345) server /***/***/***
Jun 19 14:00:01 proc02 INFO [req-56789] Get http://***
Jun 19 14:00:03 proc01 DEBUG [req-24680] Failed to fetch instance by id server1 get /***/***
Jun 19 14:00:03 proc01 DEBUG [req-13579] Returning 404 to user: Could not find instance ***Jun 19 14:00:03 proc01 DEBUG [req-98765] HTTP exception thrown: Could not find instance ***Jun 19 14:00:04 proc01 DEBUG [req-43210] Returning 404 to user: Could not find instance ***

IF

case1
IDs={1,2}

case2

IDs={1,4}&{
5}

THEN
・
・
・

Copyright(c)2021 NTT Corp. All Rights Reserved.

大量のログ

case3

どんなログをトリガとするか？

どんなコマンドを設定するかIDs={1}&{3,4}

どんなときも必ずこの対処

場合により異なる対処かも

信頼度高

信頼度低

42

復旧コマンド列の生成技術「技術概要」
 ログ/アラームを入力として、人手を介さずに復旧コマンド列を生成したい 有識者稼動の大幅削減

 構築した復旧コマンド列の「信頼度」を定量評価したい 信頼度に基づいて、保守者の自動実行判断を支援

出力

入力
自動

or 人手少なめ

ログ/アラーム列
Jun 19 14:00:00 proc01 DEBUG [req-12345] accepted ( IPv4, 12345) server /***/***/***
Jun 19 14:00:01 proc02 INFO [req-56789] Get http://***
Jun 19 14:00:03 proc01 DEBUG [req-24680] Failed to fetch instance by id server1 get /***/***
Jun 19 14:00:03 proc01 DEBUG [req-13579] Returning 404 to user: Could not find instance ***Jun 19 14:00:03 proc01 DEBUG [req-98765] HTTP exception thrown: Could not find instance ***Jun 19 14:00:04 proc01 DEBUG [req-43210] Returning 404 to user: Could not find instance ***・・・

自動化指標としての利用
信頼度90%以上なので
パターン①を自動実行しよう
Copyright(c)2021 NTT Corp. All Rights Reserved.

復旧コマンド列＆信頼度/影響度# openstack-status | grep downnova-scheduler ***# systemctl restart nova-scheduler# openstack status | grep scheduler*** running(finish)

99%
98%
99%
99%
97%
-

候補① （信頼度：93%）# openstack-status | grep downnova-compute ***# systemctl restart nova-compute# openstack status | grep compute*** running(finish)候補②# openstack-status | grep down*** Critical Error ***# shutdown –r now# openstack status | grep down(finish)候補③

43

技術のポイント：Seq2Seq（Sequence-to-sequence）
 翻訳タスクなどで用いられるニューラルネットワークモデルの一種
 系列データを別の系列データに変換 e.g.) 英語 →仏文 自然言語も1対1対応ではない + 不定長も扱える

Copyright(c)2021 NTT Corp. All Rights Reserved.

44

構成情報の収集・活用に関する技術- ネットワークリソース管理技術- トポロジ推定技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

45

構成情報の収集・活用に関する技術- ネットワークリソース管理技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

46

情報収集活用基盤とは
検出

原因特定

影響把握

対処決定

統一データモデル

AI

正確な構成情報
仮想スライス

統合管理

ユーザ収容
VNF

VNF

VNF

スライス

IP

レイヤ横断

イーサ
伝送

領域横断
ホーム

オフィス

Copyright 2020 NTT CORPORATION

無線

47

情報収集活用基盤の現状の問題点とアプローチ
現状

今後

オペレーションはネットワークやレイヤ毎に分散設計⇒構成情報管理を個々に実施

・サービス多様化による因果関係の複雑化・自動化に向け正確な構成情報が必要化⇒すべてのネットワークの正確な構成情報を統一的に管理原因特定／影響把握の一元化

横断的な管理が困難
IP

イーサ

影響
把握

VNF

VNF

VNF

スライス

ＩＰ

IP

イーサ

影響
把握

伝送
イーサ

伝送

障害箇所
を把握
伝送

Copyright 2020 NTT CORPORATION

48

「情報収集活用基盤」技術概要• TM Forumのリファレンス規定を拡張した実装フレームワーク• 「点」や「接続性」という、装置やネットワークに依存しない汎用的なデータ形式• 装置やNWごとに異なる属性等は外部定義化して拡張に対応

汎用形式

影響把握
AP

（点や接続性）

SO設定
AP等

・・・

影響把握

リファレンス規定を基に、フレームワークを実現

IPレイヤ
イーサレイヤ

IP特性

影響把握

伝送特性

SID
ビル 装置 装置

（ネットワーク非依存）

ｲｰｻ特性

影響把握

伝送レイヤ

TM Forum

汎用ロジック

拡張可能
装置

ケーブル

装置 装置 装置

（外部定義）

テレコム業務ドメイン横断に業務プロセス実現に必要なデータモデル等をリファレンスドキュメント化
Copyright 2020 NTT CORPORATION

49

参考：統一モデルの複数レイヤ表現例• 同一レイヤ内のつながりに加えて、レイヤ間のつながりも定義• 複数VLANなど、1対多の関係も記述可能

トポロジ
TPE1-1

FRE1(VLAN：1000用) TPE1-2

JSON表現{"objectId": "TPE1-2","_freRefList": [“FRE1"],"_tpeRefList": [“TPE2-2"],"_encapsulatedLtList": [{"layerProtocolNameList": [“イーサ"],"transmissionParameterList": {"VID": “1000",}}]}{

TPE2-1

Copyright 2020 NTT CORPORATION

FRE2(伝送：1用)

TPE2-2"objectId": "TPE2-2","_freRefList": [“FRE2"],"_tpeRefList": [“TPE1-2"],"_encapsulatedLtList": [{"layerProtocolNameList": [“伝送"],"transmissionParameterList": {“波長番号": “1"
}}]}

50

参考：即時影響把握の具体例• 障害発生時に、面的な、また別レイヤに波及する影響の把握を迅速に行うことが可能■上位階梯ビルの電源断に伴う伝送障害波及シミュレーション
影響把握AP画面イメージ
影響把握
AP
影響把握
影響なし
（波及警報のみ）

OpS

DB

OpS

DB

OpS

DB

IP特性

IP

ｲｰｻ特性
伝送特性
ビル
装置 装置 装置

ケーブル装置 装置 装置

レイヤ間特性

イーサ

伝送

障害発生

注目したいレイヤ（図はビル）を指定して図示（影響ありは赤、片系影響は黄など）
Copyright 2020 NTT CORPORATION

51

構成情報の収集・活用に関する技術- トポロジ推定技術

Copyright(c)2021 NTT Corp. All Rights Reserved.

52

現状の問題点とアプローチ• 課題– DeAnoS-RCAやSherlook等のネットワークの運用に用いられるAI技術の多くは装置間のIF（インターフェース）の接続関係を示す構成情報を活用している。
⇒AIの推定精度を高めるには正確な構成情報が必要不可欠である。
– しかし、装置台数が膨大なネットワークでは、管理すべき構成情報が非常に多く、また接続関係は工事や故障対応で変わるため、それらの管理は容易ではない。

• アプローチ– 「向かい合うIF同士はトラヒック量が等しい」という特徴に着目し、全IF間のトラヒック一致度からトポロジ情報を推定– トラヒックに特徴がないIF（予備系等）もトラヒックを印可することで推定– トラヒック情報を用いることで、レイヤ・装置ベンダを問わずNW全体に適用可能
Copyright(c)2021 NTT Corp. All Rights Reserved.

53

背景:通信事業者NWとその管理システム構成例••

通信事業者NWは、その役割に応じた複数レイヤで構成されており、代表的なNWレイヤとして、 IPレイヤや伝送レイヤがある。
通信事業者NWはその規模が膨大であり、かつ異なる技術を利用したレイヤに分かれているため、レイヤやNW毎に異なる管理システムが導入されている。

通信事業者NWの構成例
IPレイヤ#1
構成
構成
構成
情報
情報
情報

管理システムA
IPレイヤ#2...

Copyright(c)2021 NTT Corp. All Rights Reserved.

管理システムB

IPレイヤ
運用者

...

...
伝送
レイヤ

構成
構成
構成
情報
情報
情報

構成
構成
構成
情報
情報
情報

管理システムC

伝送レイヤ
運用者

54

背景:「正確な構成情報DB」の不在••

IP-伝送間などの網間の正確な構成情報DBが不在であり、これまでは保守者が、正確な構成情報
DBがなくても、主体的に情報を収集、連携させ、暗黙知を基に補完することで分析してきた
AIのインプットにトポロジ情報が用いられる場合も多く、「正確な構成情報DB」の整備が、喫緊の課題
正確な構成情報不在のオペレーション
瞬断ALM！

？

？

？

IP網
構成情報DB

保守者が主体的に情報を収集、連携させ暗黙知を基に補完してきた

IPオペレー
タ

IP網

？

？
伝送網
原因？
原因？

構成情報DB

NW間の構成情報DB

NW間の正確な構成情報DBがない！
伝送網
構成情報DB？

OSS
OSS

暗黙知に含まれる
高スキル者が 構成情報
知る構成情報？
？
伝送オペレータ

Copyright(c)2021 NTT Corp. All Rights Reserved.

正確な他のツールや
ファイルに記された
構成情報

が必要…

分析AI

AIが人の代わりに業務を行うために、「正確な構成情報DBの整備」が喫緊の課題

55

「トポロジ推定技術」技術概要•

2つのサブ技術により、マルチレイヤNW全体の構成情報を担保可能とする技術① トポロジ推定：トラヒック量を基に、向かい合うIFペアを推定する技術② 印加量等算出：トラヒックがないIFに、少量のトラヒックを印加して①の推定を可能とするための技術【トポロジ推定技術】
マルチレイヤNW全体の構成情報を担保可能とする
分析・判断

①トポロジ
推定

ﾄﾗﾋｯｸDB

収集

構成情報
DB

OUTPUT②印加量等算出

トポロジ推定技術

制御
Ping
ツール

IP網
？

伝送網
Copyright(c)2021 NTT Corp. All Rights Reserved.

？
？

？

56

技術①トポロジ推定••「向かい合うIF同士はトラヒックが等しい」というアイデアを具現化し、全IF間のトラヒック一致度から向かい合うIFペアを推定
トラヒック情報を用いることで、レイヤ・ベンダを問わずNW全体に適用可能！
全IF間でトラヒック一致度を比較
INPUT：トラヒックデータ
全IFのデータを取得

NE

NE

NE

NE

NE

NE

スコアS=

σ𝑇𝑡=0

𝐼𝐹𝑖 𝑡 . 𝑖𝑛 − 𝐼𝐹𝑗 (𝑡). 𝑜𝑢𝑡
𝐼𝐹𝑗 𝑡 . 𝑖𝑛 − 𝐼𝐹𝑖 (𝑡). 𝑜𝑢𝑡+
𝐼𝐹𝑖 (𝑡). 𝑖𝑛 + 𝐼𝐹𝑗 (𝑡). 𝑜𝑢𝑡
𝐼𝐹𝑗 (𝑡). 𝑖𝑛 + 𝐼𝐹𝑖 (𝑡). 𝑜𝑢𝑡
𝑇

運
用
系
：
ト
ラ
ヒ
ッ
ク
量
多

OUTPUT：IFペア情報

マルチレイヤNW全体のトポロジを推定可能

予
備
系
：
ト
ラ
ヒ
ッ
ク
量
少

NW
トラヒック量多IF
トラヒック量少IF
凡例 トラヒックデータのグラフ
ﾄﾗﾋｯｸ量

最も一致度が高い
IFペアを抽出

送信トラヒック
受信トラヒック
時間

Copyright(c)2021 NTT Corp. All Rights Reserved.

57

技術②印加量等算出••

予備系など、トラヒックがないIFに、少量のトラヒックを印加して推定可能とする
商用NWへの負荷が最小限となるよう、印加の向き、量、タイミングを算出する
本技術が加わることで、NW全体のIFペアを推定可能！

技術ポイント①

技術ポイント②

トラヒックを印加する向きの決定

トラヒック印加量・タイミングの決定

方式上片方向のトラヒック印加で推定が可能なため、トラヒッ
クの少ないIFを抽出

トラヒック量の少ない方向(in)を選択

スコア算出式の片方の項に変化を与える

正解ペアの一致度を向上させる最低限の印加量を算出

スコア

•

予備系IF
（印加前）

正しい推定
が可能

予備系IF
（印加後）

※印加量は対象NWにより調整する。評価では標準偏差の4倍を採用
Copyright(c)2021 NTT Corp. All Rights Reserved.

58

参考

Copyright(c)2021 NTT Corp. All Rights Reserved.

59

技術ポイント②-1印加対象抽出技術•【目的】不要なトラヒック印加回避のため、接続関係の推定が困難なIFのみを抽出•【技術内容】技術①の結果、トラヒック一致度が複数IFとの間で高い（スコアが低い）IFを抽出し（STEP1）、さらに変動係数が低いIFを抽出する（STEP2）。STEP1のみでは複数IF間でトラヒッ
クが類似する運用系LAG IFが含まれるが、技術①で正しく推定可能であるため、STEP2で運用系
LAG IFを除外する。
技術ポイント(STEP1)

技術ポイント(STEP2)★運用系・予備系・LAGにおける各IF間とのスコア値の算出結果

各トラヒックデータにおける、変動係数※を分析すること
で、予備系のみを抽出可能(運用系IFのLAGを除外可能)※ 時系列データf(t)の時間変化の指標、変動係数𝑪. 𝑽 =𝟏 𝒏𝟐σ𝒏 𝒏=𝟏(𝒇 𝒕𝒊 − 𝒇(𝒕))
𝒇(𝒕)

予備系抽出

Copyright(c)2021 NTT Corp. All Rights Reserved.

60

技術ポイント②-2印加トラヒック量算出技術•【目的】NW負荷最小化のため、推定に必要な最低限のトラヒック印加量を算出【技術内容】技術②-1で抽出したIFに対して、印加後のNW負荷が少なくなるようにトラヒック量の少ない方向(upstream/downstream）を選出し（STEP1）、その上で正解IFとの一致度を相対的に向上させるため、個々のIF単位で必要なスコア差分を得るための最低限の印加量※、さらに各IFへの印加トラヒックを識別可能とするため、OpSのデータ取得間隔に合わせた印加タイミング（印加時間＋インターバル時間）を算出する（STEP2）。
技術ポイント(STEP1)

技術ポイント(STEP2)

トラヒック印加方向の決定
スコア算出方式上、片方向のトラヒック印加で正しい推定が可能

トラヒック量の少ない方向(in)を選択

トラヒック印加量・タイミングの決定
正しい推定が可能なように、正解ペアにおけるスコアを相対的に向上させる最低限の印加量を算出

スコア

•

正しい推定
が可能

スコア算出式の片方の項に変化を与える

予備系IF
（印加前）

予備系IF
（印加後）

※印加量は対象NWにより調整する。評価では標準偏差の4倍を採用
Copyright(c)2021 NTT Corp. All Rights Reserved.

61

本技術の評価
IP装置と伝送装置から取得した運用系32IF・予備系342IFのトラヒックデータを用いて、本技術の推定
精度を評価した。
 ベンダ、レイヤの異なる装置群※において、①トポロジ推定技術のみで運用系は精度100%、②印加対象抽出/トラヒック量算出技術を加えることで、予備系も100％の精度で推定できることを確認した。
※伝送レイヤ：2社6種別、IPレイヤ：4社6種別

検証の条件

評価結果
①トポロジ推定技術のみ

評価対象NW表2. 評価結果(従来)

IP網
推
定
対
象
伝送網

トポロジ
推定技術

トラヒック
データ取得

csv

タイミングをずらしてトラヒックを印加

タイムスタンプ,
送受信トラヒック量
データ数
96点(15分間隔×24時間)
Copyright(c)2021 NTT Corp. All Rights Reserved.

運用系：100％(32/32)
予備系：3.6％(14/342)

精度向上

表3. 評価結果(高精度版)

解析対象IF数

データ内容

トポロジ
推定技術
(従来)

①トポロジ推定技術＋②印加対象抽出/トラヒック量算出技術

表1. 評価条件

374 IF分(運用系：32 IF、
予備系：342 IF)
データ取得間隔 15分間隔

結果

印加対象
抽出技術
印加トラヒック量
算出技術

トポロジ
推定技術

結果
トポロジ
運用系：100%(32/32)
推定技術
予備系：100%(342/342)(高精度版)

62

ループを回すためのワークフローに関する技術- オーケストレータ技術（カタログ
記述量削減技術）

Copyright(c)2021 NTT Corp. All Rights Reserved.

63

現状の問題点とアプローチ• 問題点– ここまでご紹介してきた技術によって、保守者のオペレーションにおける分析・判断プロセスを部分的に自動化することはできる。
– しかし、更なる自動化を推進していくためには、各種AI技術を連携させて人手を介さないようにする技術が必要である。

• アプローチ– 各AI技術やDBをAPIで連携させるオーケストレータを用いた故障対応の全自動化を実現– 故障対応業務の複雑な工程や条件分岐を汎用化した部品の組み合わせでシ
ナリオの記述を可能にし、記述量の削減や部品の再利用化を可能にした

Copyright(c)2021 NTT Corp. All Rights Reserved.

64

背景：通信事業者の故障対応業務•

通信事業者の故障対応業務は、多数発生する警報に対して、様々なシステム・ツール・DB等を駆使して収集した情報の応じて対処を変更する必要があり、条件分岐が複雑である。

■人手による通信キャリアの故障対応業務
原因

数万警報
オペレータ

情報収集

工事 履歴

NW装置群
（数十万）

対処判断
etc

システム・ツール・DB等（10以上）

Copyright(c)2021 NTT Corp. All Rights Reserved.

完了
遠隔措置

代替機手配
150を超える
条件分岐

原因装置

65

背景：これまでの故障対応業務の自動化••

故障対応業務の保守者の判断プロセスをAI等に置き換えるだけでは部分的な自動化にとどまってしまう。
各種AIやシステム・ツール・ DBをAPIベースで連携させるオーケストレータを用いた故障対応の全自動化を実現し、抜本的な保守稼働の削減を行いたい■従来の自動化完了
AIAI

部分的な自動化■故障対応の全自動化
・・
・

オーケストレータ
AI・システム・
ツール・ DB群

・・
・

カタログ

・・
・

完了
66

課題：複雑かつ巨大な故障対応のカタログ化•（複雑で巨大）対応の根拠となる情報を収集すべく、フローには下記などが必要。
––•

対処実施までに、サービス影響を把握するためのNW構成の参照といった確認作業。
複数の警報から根本原因を絞り込むなどの判断作業。

（更新頻度大）対応手順が未知である故障の発生時や、新規サービス・新規装置のリリース時には新たな対応フローが必要となり、これらは頻繁に発生。
⇒運用のためには、これらのフローをカタログとして容易に作成・更新できる必要がある。
フロー上必要な要素
・対応の根拠の収集
・装置への誤操作防止
・早期回復のための決定など

新装置の導入150以上の分岐・10以上の連携先カタログの新規作成
頻繁に発生
カタログの変更

既存フローの変更
オペレータ（カタログ作成者）

カタログの容易な作成・更新が必要

67

要素技術：カタログ記述量削減技術••

フロー複雑化の原因となっている、対処内容の説明を行うための様々な確認作業や判断作業を汎用タス
クとよぶテンプレートにまとめることで、カタログの再利用性を高め、記述量を削減した。
各工程における業務上のデータを処理するフロー（データフロー）と、業務工程の流れを示すフロー（業務フロー）を分離した。
––

業務フローの表現：フローの表現や注釈に特化したBusiness Process Model Notation（BPMN）を適用し可読性を向上。
BPMNをGUIで扱い複雑な業務フローを容易に把握・編集することを実現。

業務フロー

本技術適用前のカタログ

データフロー

情報確認

分離

遠隔措置

回復通知

業務フロー内の文字の整形・数値
計算や条件式

装置手配

汎用タスク

68

•
•
•

カタログ記述量の削減と記述の容易性が向上

下記にプロトタイプと本技術のカタログ表現の比較イメージを示す。BPMNとGUIを利用することで、記述の稼働削減のみならず、可読性の向上を実現した。
特定ユースケースでカタログ記述量を約82%削減、作業時間を50~60%削減することができた。
本技術は、フロー中に同一の工程が繰り返されるような場合、特に有効である。

■本技術適用前のカタログ{"sourceOffering": {"add": ["http://marble.ntt.co.jp/catalogManagement/v1/productOffering/process_check_construction","http://marble.ntt.co.jp/catalogManagement/v1/productOffering/process_check_failure_history",
・・・]},"sourceOrderSetting": {"addRules": {"receivedOrderRules": [{"scope": "$order(http://marble.ntt.co.jp/catalogManagement/v1/productOffering/process_check_construction)","attributes": [{"name": "$item(1).$charValue(executeFlg)","value": "$String(false)"},{"name": "$item(1).$charValue(resource.1.resourceParam.alarmId)","value": "$parentOrder.$item(1).$charValue(alarmId)"},
・・・"receivedStateChangeRules": [{"source": "$order(http://marble.ntt.co.jp/catalogManagement/v1/productOffering/process_check_failure_history)","condition": [{"attributeName": "state","attributeValue": "$String(Completed)","operator": "eq","condition": [{"attributeName": "$parentProduct.$charValue(getAlarmStatusInfoNextOrder)","attributeValue": "$String(process_x)","operator": "eq"}

■本技術適用したカタログ：すべて同じ工程（トラチケ記入）

69

まとめ

Copyright(c)2021 NTT Corp. All Rights Reserved.

70

まとめ
• NTT研究所で取り組んでいる、保全領域の自動化・高度化に関連する技術について、ご紹介させていただきました。
• 新たな技術の適用先も模索しており、技術の内容や適用先、あるいは現場での課題など、様々な観点でディスカッションさせていただければと考えています。

Copyright(c)2021 NTT Corp. All Rights Reserved.

71

ご清聴ありがとうございました

Copyright(c)2021 NTT Corp. All Rights Reserved.

72