はじめに

こんにちは、NTTテクノクロスの山口です。
これまでのブログ記事でSONiCやTelemetry、監視基盤、AIなどについて紹介してきました。

今回は、本記事を含めた5記事にわたって、それらを活用したクローズドループを実現できる監視/制御基盤の例を紹介したいと思います。
環境の作り方や動作もご紹介しますので、各技術のイメージやネットワーク世界でのAI活用、クローズドループについて、そしてネットワーク管理の将来像についてイメージを膨らませられれば、と思います。

初回となる本記事では、本連載で作る環境や検証シナリオなどの全体の概要について紹介します。
  ※ 次回から環境構築や動作説明に入りたいと思います。

【目次】

[参考] 関連記事
良ければこちらも参照ください。

クローズドループとは

ネットワーク(NW)の世界ではいかに早くに異常を察知し、手立てが行えるかが極めて重要です。
そこで【監視入門 第2回】記事でも紹介したようにNW機器から様々な情報を取得し、異常の発見や判断に活用します。
また、必要に応じて対処も行います。

図1 NW管理の全体像

これらを自動的/自律的に行い、継続的に循環させる仕組みをもったNWを自律型ネットワークといったりクローズドループ自動化ネットワーク、あるいはインテリジェントネットワークと呼んだりします。
今回はOSSや簡単なプログラムで簡易的な検証環境を作り、イメージを膨らませていければ、と思っています。

本連載で作る環境と検証シナリオ

クローズドループの概念をおさえられたところで、次回から4回にわたり作っていく検証環境の構成概要を以下の図に示します。

図2 本連載で扱う構成の概要

クローズドループの基本要素は「監視」「判断」「制御」ですが、実運用では発生した異常の内容を保守者が理解し、対応内容を確認できることも重要です。
そのため今回は、異常発生時の状況確認や原因整理を支援する要素として、「LLMによる問い合わせ支援」も構成に加えています。
NW領域におけるLLMの活用例の一例としても紹介できれば、と思います。

これらにより実現することは「NWの状態可視化」「NW監視と制御の連携と自動化による対処早期化」「NW異常時の状態把握の早期化」です。
今回はこれを実現するシンプルなシナリオとして、NW機器のトラヒック流量を監視し、普段より多くの通信が来たらAIにて異常と判定、その後経路を自動的に切り替える、ということを行いたいと思います。

監視/可視化基盤でNW機器から情報を取得、かつトラヒック流量を見える化することで「NWの状態を可視化」し、AIによる判断と制御基盤による処理で「NW監視と制御の連携と自動化による対処早期化」を実現、またLLM問い合わせ支援基盤で「異常と判定された理由」をLLMに問い合わせることで「NW異常時の状態把握の早期化」の実現を確認するイメージです。

図3 検証シナリオのイメージ

大量の通信が来た場合に経路を切り替えても、大量通信は減らないのだから本質的に解決しないのでは（異常の内容と対処案が紐づいていないのでは）と思われるかもしれません。
これはご認識の通りで、実際には振り分け(ロードバランス)経路の追加やQoS対応などが該当するかと思いますが、今回はシンプルな例とする為、経路切り替えの例で実施したいと思います。
気になる方は対処内容のところは頭の中で読み替えて見ていただけるとよいかと思います。

このシナリオを実現するために検証環境を作っていきます。
図2の内容をもう少し利用する具体的な技術名も含めて記載すると以下のようになります。

図4 本シリーズが扱う検証環境の構成詳細

NW機器の部分はSONiCが担います。
SONiCはホワイトボックス機器向けのNetwork Operating System(NOS)です。
  [参考] 詳細は【NOS入門 第1回】をご確認ください。

SONiCからのデータ収集はTelemetryを活用したいと思います。
TelemetryはNW機器からデータ収集するための方法の1つです。
  [参考] 詳細は【監視入門 第1回】、【同 第2回】をご確認ください。

Telemetryの取得方式には大きくDial-InとDial-Outがありますが、今回はDial-In方式で実現します。
また、Telemetryの収集コレクタはTelegrafを利用します。
  [参考] Dial-In/Dial-OutやTelegrafについては【監視入門第1回】もご確認ください。

前述の通り、TelegrafはTelemetry収集をするためのコレクタの役割を担います。
TelegrafでSONiCからIFのトラヒック流量を取得し、Prometheus・Grafanaへとあげていきます。
データ管理についてはPrometheus、可視化についてはGrafanaが担います。

データ欠損を極力しないような構成を目指したり複数のデータ管理先にデータを送るのであればBrokerとしてKafkaを入れる、あるいはSyslogやルーティング情報といった文字列を管理するならOpenSearchを利用するのも手かと思いますが、今回はシンプルな構成、かつ管理する情報がトラヒック情報（数値情報）となるのでPrometheusと、Prometheusとかみ合わせの良いGrafanaを利用します。（この点が【監視入門第1回】で挙げた構築例との差分でもあります）

異常判断については、Pythonツールで定期的にPrometheusから直近のデータを受け取りながら、AI、今回はXGBoostの回帰処理という方式を利用して判断します。
XGBoostで検知する「異常」の定義は、傾向外れです。
すなわちXGBoostにて通常時のトラヒック流量の傾向を学習し、傾向から外れた場合に異常と判定します。
傾向外れを異常として検知する理由は、安定運用している状態（通常時）から外れた場合、逆説的に考えると異常につながる可能性や異常が発生している可能性があるためです。

異常と判断された場合はPythonツールにてSONiCの経路を切り替えます。
今回のシナリオでは前述の通り、「普段より多くトラヒックを流す」ケースで試しますが、傾向外れは「普段より減少した場合」も検知できます。

本記事の主題は監視とAIによる判断、制御の連動（クローズドループ化）である為、本題とは少しそれますが、補足としてPrometheusによるルールベース異常の検知とAlertmanagerによる通知も紹介します。

LLMを用いた問い合わせ支援基盤は、保守者が利用しやすいようにチャット画面を用意します。
このGUIの作成にStreamlitを活用し、実際に問い合わせを行うLLMはOpenAI社のモデル(クラウドモデル)を利用します。
【LLM活用入門 第1回】、【同 第2回】で紹介したようにDifyやローカルLLMを使うという手もありますが、今回はシンプルなものとする為、前述のような構成とします。

その他、細かい動作や補足などは、次回以降の「環境の作り方」章で紹介していきたいと思いますので、操作や動きも見ながら細部のイメージを掴んでいただければ、と思います。

なお、今回は検証デモ用でかつ環境準備の簡略化の為、各コンポーネントは説明用に最低限の設定や実装となっておりますこと、ご承知おきください。
また、本記事の内容を用いた開発・運用は、必ずご自身の責任と判断によって行ってください。
開発・運用の結果について、いかなる責任も負いません。

[補足] 監視/制御の関係とIntent-Based Networking 今回の記事では監視されたNWに対し、自動で異常を検知し必要な対処/制御を行う、という内容である為、まずは「監視」が先に来る（監視があって制御が成り立つ）ように見えるかもしれません。 しかし監視と制御は必ずしも常に一体である必要はありません。 例えばサービスオーダーの自動投入や一定の運用自動化を実現する場合には、監視情報と連動しなくても成立できる場合もあります。 監視システム担当チームと制御システム担当チームが別々に存在していて、何か問題が起きた際にはお互いに連携、というようなケースもあるかと思います。 一方でNWを継続的に安定運用させる上では監視と制御をシステム的に組み合わせることが重要です。 設定投入して終わりではなく、その後もNWが問題なく運用できているか確認し、状態が崩れた場合には別途対応する必要がありますが、これをシステム上で一元管理/対応することでスムーズに対処が進む、結果としてサービス影響の最小化につなげていける可能性があるためです。 この考え方は、近年注目されているIntent-Based Networking(IBN)にも通じます。 IBNとは簡単にいうと「やりたいこと(=Intent)」を定義し、それにそってNWが制御されていく、という概念です。 例えば「拠点Aと拠点B間でVPN(仮想専用線)を設定し、遅延をXms以下とする」ということを定義し、それにそってNWが制御されるイメージです。 図5 Intent-Based Networkingのイメージ 最初はIntentに基づいて必要な設定をNW機器へ投入することになるかと思いますが、Intentを満たし続けるためには、やはり設定投入だけでは不十分です。 実際のネットワーク状態を監視し、Intentから外れていないかを確認し、必要に応じて再設定や経路変更などの制御を行う必要があります。 今回の検証はIBNそのものを実装するものではありませんが、監視、判断、制御を組み合わせてNWを自動で望ましい状態へ近づけるという点で、IBNに通じる考え方も含んでいます。 なお、監視と制御を連動させる場合、制御内容に影響を与えるため、監視が極めて重要な要素となります。

[補足] ルールベース検知とAIによる異常検知の違い ルールベースによる異常の検知とAIによる異常検知の違いについて補足します。 ルールベースの検知は、基本的に人が事前に定義した条件によって判断されるものです。 例えば1Gbps帯域のNWにおいて、90%(約900Mbps程度)以上使われていたら、通信帯域枯渇のリスクがあるため、アラートを上げるように設定しておこう、というようなものです。 ところがこのようなパターンでは、実運用での傾向などを細かく反映しづらい点があります。 例えば30%程度(約300Mbps)しか使っていないものの、普段は100Mbpsぐらいなのが直近だと急に300Mbpsに上がった、全体的な傾向をみても通常時の3倍まで上がることは異例、というケースでは異常と判定されません。 直前の通信からn%上がったらアラートを上げる、というようなルールも考えられますが、実際にどの程度の変動があるかはNWや利用用途/サービス特性などにもよります。 AIを活用すると、実際に発生したものの傾向から機械が正常/異常判断をしてくれます。 AIも色々ありますが、このような分野は機械が判断基準を自動で作ることから「機械学習(Machine-Learning/ML)」と呼ばれます。 図6 ルールベースとAIによる異常検知の違い 今回はAIにより傾向外れを検知しますが、これによりルールベースでは定義していない/見つからない異常や異常につながる可能性（予兆）を見つけられる場合があります。 傾向外れを見るという考え方は「通常時の動作を覚えさせる」アプローチですが、別のアプローチとしては「異常が発生したケースをAIに学習させる」方法もあります。 ただし、異常が発生したケースをAIに学習させる方法は、問題が起きたケースのデータをそこまで多く集められないことも多いため、まずは通常時のデータを学習し、通常傾向からの外れを検知するアプローチのほうが取りやすいと考えます。 また、異常の判定方法にも「AIの予測と実績値が一定レベルでずれたら異常（覚えた傾向外れとなっている）」と判定する方法や「これまでの傾向や直近の値から、将来の値をAIで予測し問題となるラインを超えるか判定させる」方法などもあります。 図7 AIによる異常判定方法の違い また、一見AIが便利そうにも見えますが、弱点もあります。 その1つにルールベースによる検知は「異常と判定された場合、なぜ異常とされたのか」説明が極めてしやすいですが、AIは説明性が見えにくかったり誤検知が発生する場合があることがあげられます。 それぞれ一長一短あると思っていますので、併用してそれぞれの短所を補いながら長所を生かす運用をしていくことが理想と考えます。

構築環境と手順に関する前提

ここからは、「本連載で作る環境と検証シナリオ」章で紹介した環境と手順の前提を説明します。

手順の前提として各サーバはVMとし、仮想化ソフト上の設定手順(VMの定義/作成やVM間の内部NW作成など)は記載省略とします。
どの仮想化ソフトを使うかは、NW機器として扱うSONiC(VS版)がKVM上での利用が推奨されるため、KVM、あるいはKVMが使える仮想化ソフトで試せると良いかと思います。

本検証環境のNW構成は以下の通りとなります。

図8 全体NW構成

仮想化ソフト上で内部NWやVM上のIF数設定などを設定しておいてください。
VMに用意されたIF(NIC)にIPアドレスを設定し、起動する点は手順に含みたいと思います。

また、手順では途中でブラウザアクセスするものもありますが、これはVMからではなく、ホストマシンからブラウザでアクセスするものとします。

図9 前提のイメージ

各VMで最低限必要なリソース設定を以下に示します。

利用するOSやOSS/ツールのバージョンは以下の通りです。

Pythonプログラムで利用するライブラリのバージョンは以下の通りとなります。

完成した環境での検証結果概要

本連載で扱う環境ができるとどんなことができるのかをもう少しイメージできるように、実際の実行例を一部示します。
  ※ 細かい検証の流れや結果は「第5回」にて紹介します。

ここで紹介するのは、図3のNo.1～6まで完了した際の状態です。
すはわち「NW機器(SONiC)に流入するトラヒック量が通常時から急激に増え、それをAIが異常(傾向外れ)と判定し、自動で経路切り替えを実施した後」の監視/可視化基盤の画面を紹介します。

以下がその画面です。

図10 作成した環境での検証結果概要(一部)

「AIによる判断と制御基盤」による経路切り替えも含めたイベントの経緯がわかりやすく追えるのがわかるのではないかと思います。
なお、上記の画面には現れませんが、図3 No.7にあたる箇所である「LLM問い合わせ支援基盤」で異常と判定された理由をLLMに問い合わせし、「原因の早期把握」の例は第5回でお見せできれば、と思っています。

前述の通り最終的には検証手順と結果については第5回で紹介しますが、それまでに環境の構築手順/動作例なども要所要所で示すので、内部的にどのように動いているのかおさえながら最後の検証結果を確認できるとより良いかと思います。

おわりに

今回は本記事を含めた5回で構築する環境の全体像や作った環境で試すシナリオといった概要について紹介しました。

本連載で扱う技術はSONiCやTelemetry、Kubernetes、AIなど幅広いものとなる為、次回以降の構築手順などで1つ1つをしっかりおさえられればと思います。

次回は「NW層の実現」と「各VMの設定」について紹介したいと思います。

最後までご覧いただきありがとうございました。
もし何かご意見・コメント・ご質問などがあれば、以下からお問い合わせください。