仮想化と監視運用自動化
サービスを提供するサービスプロバイダー(モバイルオペレータ等)にとって運用の自動化は見果てぬ夢であるが、ETSI ZSM ISGを中心に監視運用の自動化が注目され始めている。特にDeep LearningをはじめとしてAI技術が実用レベルに来たこともあり、それを応用して監視保守を自動化したいようだ。
監視保守運用自動化の歴史
運用自動化の歴史は古く、インターネットが普及し始めた1980年後半以降、SNMPの仕様制定やAIの探求などによって各企業様々な方法で監視保守の運用効率化を行なってきた。背景にあるのは、メインフレームのような集中型システムから、ネットワークを利用した分散システムがトレンドになったことで監視対象が劇的に増えたこともあるだろう。1990年にはIBMのTivoli、2000年にはNTTのHinemosといった運用自動化の走りのような製品が出始めている。自動化システムの特徴としては、大きく2つのアプローチがあるようだ。
- 正常なサービス状態を定義し、そこから外れたことを元に戻すためのアクションを行う(プロアクティブ監視)
- 様々なKPIや測定項目を定義し、各項目の正常値から統計的に外れた場合い異常と判断する
- 異常を検出した場合は、その差分(Delta)を埋めるRuleが差分を順次埋めて正常値(Desirable State)に戻す
- Tivoli
- 障害発生のイベントを登録し、イベントに応じた措置手順をシナリオとして定義する(ECAモデル)
ECAモデルの場合、基本的には保守者が自分で行なっている作業をConditionとActionとして定義していくことになるが、当然保守者の運用事例が先行するため“保守者のマクロ“的な位置が限界であった。
このように、自動化は長い年月をかけて各企業が取り組んでいたものの、現状では保守者の運用支援の域から出られず、デファクトとなるような運用自動化システムは存在しなかった。
何故今再び自動化か？
標準化仕様について①で記載した通り、仮想化の導入によって、Actionの幅が広がったことが大きい。従来であれば、HWの障害は自動化によって修理することは難しかったが、仮想化された装置はヒーリングや再インスタンシエーションなどをすれば良くなった。
また、AIの登場によって、プロアクティブ監視で検討が必要となるKPIや測定項目を人手で抽出する必要がなくなった。AIの学習が完了すれば勝手にプロアクティブ監視が始まり、そしてRuleとしては最悪再インスタンシエーションとすれば良くなった。
また、3GPP SA5 28.540や28.541によると、5Gの登場によって、従来のNetwork Element単位の監視保守からSlice単位の監視になった。この結果、各Network Elementが強調して故障監視できる必要があり、ETSI ZSM ISGで仕様策定が進んでいるようなClosed loopという運用方法やETSI ENI ISGのモバイルネットワーク自体の自律制御やO-RANのRIC(RAN Intelligent Controller)が注目され始めているようだ。
ETSI NFV ISGにおける自動化
ETSI NFV ISGでは、元々措置のためのアクションとしてVNF LCM APIを提供しており、OSS等の上位装置と連携して自動化を推進しやすい仕様を整えてきた。しかし、Rel4になってNFV IFA041“Autonomous mgmt”やNFV IFA042 “Policy Model”によって、更に高度な自動化を推進しているようだ。最終的にはPublishされるドキュメントを参照して頂きたいが、現在確認できるDraftによれば、現在大きな拡張として入る機能は
- Intentベースの制御：保守者にとってのDesirable Stateさえ入力すれば、NFV-MANOの中その状態になるようにGAP分析と自動設計を行う制御方式
- Policyの高度化： 保守者がStaticにECAモデルのシナリオをNFV-MANOに投入することで、NFV-MANOの中でも高度な自動保守監視が可能となる自動化アプローチ
- Machine Learning(ML)による自動化の高度化： 学習データを投入することで、Dynamicにプロアクティブな監視とRuleやDesirable Stateの自動生成を行う
- 従来のVNF LCM + Policy：従来の運用上の課題をPolicyとして記述
- モバイルネットワークの場合、規模が大きいために必ずどこかで故障が発生したり工事が行われたりしているようだ。そのため、いきなりMLによってDesirable Stateを生成することは難しいだろう。
- 同様に保守者であっても、工事や故障を想定した正しいDesirable Stateを記述することは困難だろう。そのため、Policyを発展させながらDesirable Stateのノウハウを蓄積していくことになるだろう。
- Intentベースの制御＋Policy： Desirable Stateが明確になった部分は細かい設計を行わずIntentベースの制御でNFV-MANOに任せることになる
- Desirable Stateが保守者の想定と一致しやすい部分はIntentベースの制御になるかもしれない
- しかし、障害時の原因解析を踏まえるとStaticな自動化を当分モバイルオペレータは好むのではないだろうか。
- 従来のVNF LCM＋ML： MLでのチューニングが適切な極一部の業務はMLを利用するかもしれない
- トラヒック分析などのKPIやDesirable Stateの学習のためにはMLを使うかもしれない
- まだまだ技術もUsecaseも未知なことが多いため、RuleにMLを使うことは想定しにくい
- Intentベースの制御＋ML： 基本的には完全自動化
- この運用に到達するまでにはかなりの時間(5年以上？)がかかるだろう
コメント
コメントを投稿