ポリシー定義

ルータ名i(0≤i≤1)とその所属クラスタciの対(i, ci)の集合としてポリシーを定義 する．表5.1が示すポリシーは，6台のルータとRBB,CRP,SVFの3種類の所属クラス タ（組織種別）から構成されている．管理者はルータ0と1，ルータ2と3，ルータ4と 5における観測トラヒックの分類結果が，それぞれRBB,CRP,SVFである事を想定して おり，それがこのポリシーに定義されている．ここでは，この組織種別によるポリシーを 用いて状態把握を説明する．

表5.1 ポリシー

ルータ 0 1 2 3 4 5

所属クラスタ RBB RBB CRP CRP SVF SVF

5.3.3 _状態把握

ここでは，システムは観測された集約トラヒックを事例に基づいて適応的に分類する．

そして，分類結果とポリシーの比較によりネットワークの状態を把握し，管理者に通知す る．管理者はシステムからの通知をきっかけにネットワークを調査し，正しい分類結果を システムに学習させる．

(1) トラヒック分類

ここでは，次の2つの処理を実施する．

i)トラヒック時系列を観測データ全体の分布に対して適応的なラベル時系列に変換 ii)そのラベル時系列の圧縮性特徴量を蓄積された事例に基づいて適応的に分類 これらの処理について下記で説明する．

(i) トラヒック時系列の適応的ラベル時系列表現 ここでは，次の2つの処理を実施する．

a)トラヒックの変化量から短期的特徴を表現する特徴ベクトルT F V(Temporary Feature Vector)を生成する

b)学習機能付き事例データベースDANDELIONに全T F V を学習させ，分布に 応じて変化する適応的ラベルをT F V に付与し，T F V 時系列として表現された トラヒック時系列を適応的ラベルの時系列に変換する

これらの処理について下記で説明する．

a)短期特徴ベクトルT F V の生成

ルータiで観測された一定期間のトラヒック時系列をTiとする．Tiは通常1日分の 時系列である．まず，Tiの時刻jにおける特徴量としてTiの平均変化量θi,j を求める

（図5.12のθi,j）．変化特性の多次元的計測のため複数の平滑化区間δk(k ≥0)を用いて θi,j を多次元ベクトルとして求める．また，θi,j の分布を反映するため，事前に定めた基 準変化量と標準偏差によりθi,j を正規化したθi,jも求める．そして，ベクトル(θi,j,θi,j) の全要素を相互比較のために[0,1]に正規化し，短期特徴ベクトルT F V(i, j)を得る．

図5.12 短期特徴ベクトルT F V

b) T F V 時系列の適応的ラベル時系列への変換

まず，全T F V(i, j)をラベルに変換し，トラヒック時系列Tiをラベル時系列L(i)に 変換する．ここで，DANDELIONはT F V(i, j)の蓄積と同時に適応的ラベルを教師な しで付与する（図5.13の’T F V db’）．集約トラヒックは観測する地点や時点により大き く変化するため，固定的尺度によるラベル変換は困難である．例えば，小規模トラヒッ クに適したラベルで大規模トラヒックを表現する事は不適切である．よって，T F V(i, j)

をDANDELIONに学習させ，トラヒック時系列Tiをその特徴を表現するラベル時系列

L(i)に変換する．

図5.13 適応的ラベル時系列への変換

(ii) 事例に基づく圧縮性特徴量の分類

ここでは，圧縮性特徴空間PRDCにより，適応的ラベル時系列L(i)として表現された トラヒック時系列を低次元の圧縮性特徴ベクトルCF V(i)に変換し，再度DANDELION

により蓄積された事例に基づいて適応的に分類する．事前に独立性の高いz系列の基準ト ラヒックを定めておき，それらの基準トラヒックのラベル時系列b0,· · · , bz−1とL(i)の 正規化圧縮距離NCDによりCF V(i)を定める（図5.14）．

CF V(i) = (N CD(b0, L(i)),· · ·, N CD(bz−1, L(i)))

そして，CF V(i)をDANDELIONのCF V 事例データベースに登録し，Tiの分類ラ ベル（所属クラスタ）を得る．トラヒック分類結果の例を5.2に示す．

図5.14 CF V の分類

表5.2 トラヒック分類結果（ルータ，所属クラスタ）

ルータ 0 1 2 3 4 5

所属クラスタ RBB SVF CRP RBB SVF 未知

(2) ポリシーに基づく評価

ここでは，システムはトラヒック分類結果とポリシーを比較して，管理者に状態通知を 送信する．管理者はシステムからの通知をきっかけにネットワークを調査して新たな経験 知識を獲得し，システムに学習させる．

(i) トラヒック分類結果とポリシーの比較

Tiの分類結果（表5.2）をポリシー（表5.1）と比較して管理者に状態通知を送信す る．状態通知の例を表5.3に示す．この例では，ルータ0,2,4が正常（ポリシーと同一の 分類結果），ルータ1のSVFへの帰属とルータ3のRBBへの帰属が異常，ルータ5が

RBB,CRP,SVFのどれにも帰属しない事が異常として検出されている．

(ii) 管理者の教示による分類事例の学習

管理者はシステムが検出した異常を手動で検査し，正しい分類結果を新たな経験知識 としてシステムに学習させる．この管理者による手動補正の例を表5.4に示す．この例で

表5.3 状態通知

ルータ 0 1 2 3 4 5

分類結果 RBB SVF CRP RBB SVF 未知 ポリシー RBB RBB CRP CRP SVF SVF 判定 正常 異常 正常 異常 正常 異常

＊正答率（ポリシーと一致した分類結果の比率）= 3/6 = 50%

は，管理者はルータ1,3,5の異常判定を検査し，その結果に基づいて学習内容を決定す る．例えば，管理者の調査によりルータ1には異常が発生しているがルータ3,5は正常で ある事が判明したとする．この時，ルータ1の異常判定は正答であり，今後も異常として 検出させるため補正せず，ルータ3,5の異常判定は誤答であるため，それぞれCRP,SVF としてシステムに学習させる（図5.15）．具体的には，システムへのトラヒック分類基準 の教示として，特徴点と分類ラベルの正しい組み合わせをCF V データベースに追加し て学習させる．事例データベースへの登録内容の例を表5.5に示す．この表はルータ3と 5の2015年1月1日におけるCF V 分類ラベルをそれぞれCRPとSVFとして定めて いる．システムはルータ番号と日時からDBに登録されたCF V を特定し，その分類ラ ベルをこの表で指定されたラベルに変更する．複数のモニタリング目的がある場合には，

それらの目的毎にこの作業を実施する．

提案手法では，管理者はシステムが検出した異常だけを検査する．トラヒックパターン は異常時を除き一般に安定的であるため，システムに十分な事例を学習させた後は提案手 法によりほぼ全自動でネットワークの状態を把握できる．表5.3の正答率は観測された ネットワークの状態と管理者の想定が一致した割合である．高い正答率はポリシーがネッ トワークの状態を正しく表現していること，低い正答率はそうではないことを表す．

表5.4 手動補正

ルータ 1 3 5

分類結果 SVF RBB 未知 正しい分類結果 SVF CRP SVF 学習内容 - CRP SVF

表5.5 事例DBへの登録内容

ルータ 分類ラベル 特徴点を特定する 情報（日時等）

3, CRP, 20150101

5, SVF, 20150101

図5.15 管理者による正しい分類結果の教示

トラヒックパターンの実態と整合しない不適切なポリシーや不十分な基準トラヒックで は，学習を継続的しても正答率は改善されない．よって，管理者は基準トラヒックやポリ シーを変更する必要性を認識できる．その様な場合，管理者は調査に基づいて設定を変 更する．管理者はネットワークの状態通知の受領や事例DBへの登録においてはCF V を意識する必要は全くないが，基準トラヒックが適切か否かの確認のためにはCF V を調べる必要がある．例えば，DBに登録されている多数の CF V が特徴空間の端点

(1.0,1.0, ...)や狭い領域に集中的に分布している場合には，基準トラヒックの不足が原因

として考えられる．そのため，管理者はまず基準トラヒックの追加を試し，それでも正答 率が改善されない場合，ポリシーを変更する．

5.3.4 _{使用イメージ}

ここでは，例として，前日分のトラヒックを1日1回モニタリングする場合を取り上げ る．提案手法の日々の使用イメージを図5.16に示す．管理者はモニタリングの開始前に 初期設定を実施する（ポリシー，基準トラヒック，トラヒック平滑化区間，DANDELION の類似度空間減衰率（T F V,CF V））．

図5.16 管理者とシステムの相互作用に基づくモニタリング

(1) 日々の状態通知

システムは蓄積された事例に基づいて把握したネットワークの状態（前節の表5.3）を 把握し，管理者にメールで1日1回通知する．蓄積された事例が乏しいモニタリング開始 当初はあまり正確な状態把握は望めないが，システムの精度は事例の蓄積が進むにつれて 向上する．

(2) 正しい状態の手動登録

管理者はシステムからの状態通知をきっかけとして異常として判定されたトラヒックを 調査し，正しい状態（前節の表5.5）を事例DBに手動で登録する．トラヒックパターン は異常時を除き一般に安定的であるため，管理者は異常判定されたトラヒックだけを調査 すれば良く，作業負担が軽減される．例えば，全体の1割だけが異常の場合，作業負担は 9割削減される．更に，過去に経験がない新たなトラヒックパターンは異常として検出さ れるため，管理者はトラヒックパターンの変化を把握できる．

日々のモニタリング作業（(1),(2)の反復）により，管理者の経験知識は事例DBとし て形成され，他の管理者との共有が可能になる．そのため，モニタリング水準の向上が期 待できる．継続的に学習してもシステムの精度が向上しない場合，管理者は初期設定の見 直しが必要な事を認識できる．よって，管理者はトラヒックに対する理解を深められる．