はじめに

こんにちは, IT基盤部ネットワークグループ (NOC) の nagi です.

NOC では, データセンタ, オフィス, 横浜スタジアムなどの数十拠点のネットワークを運用しています. 個々の拠点の規模感は大小様々ではありますが, すべてを合わせると管理するべきネットワーク機器の台数は膨大になります.

これら多数の機器を管理するために, config管理ツール nwcli を内製開発し活用してきました. nwcli についてはぜひ前記事( NW機器config管理ツールを内製した話 )も参照してください.

nwcli について簡単に紹介すると, 3点の課題を解決するために開発されました.

• (課題1) 背景も変更者も分からない謎な設定が残っている.
  • Gitの履歴, YAMLでのコメント管理が可能
  • 定期差分確認により設定の除去漏れを防止
• (課題2) 新規拠点構築時の設定漏れ/不要設定留置
  • テンプレートRoleを作成し共通設定を一元管理
• (課題3) 複数機器に対して設定を一括投入する手段がない
  • Ansible を使い複数機器に対して設定を一括投入可能に

当時はあくまで補助ツールの立ち位置だった nwcli ですが, LLM により開発が進み自動化システムの中核を担う存在にまでなりました.

本記事では, 確立しつつある nwcli と AI が連携するネットワーク運用について述べます.

nwcliの進化

前述通り nwcli は LLM により大きく進化しました. 主要な変更点について簡単にまとめます.

実装言語の変更

Python で構成されていたスクリプト群を Go で書き直しました. ただすべてを書き直したわけではなくコアエンジンのみで, Ansible のラッパー部分は Python のままにしています. LLM との親和性が高く並行処理の実装が容易な Go を採用することで, 開発速度の高速化及びシステムの堅牢性を高めました.

インフラ構成の変更

元々は1台のサーバ上に投げやりでデプロイされたキメラ構成でしたが, AWS上で ECS, Lambda を利用した構成に再構築しました. エンジン部分は ECS 上で動作させ, Ansible 実行を Lambda に委譲することでスケーラビリティを向上させました.

通常 Lambda では Ansible を実行することができません. 実行に必要な仮想デバイス (/dev/ptmx, /dev/shm) が存在しないためです. ¹ しかしこれらのデバイスを, Python で再実装しモンキーパッチで実行時にねじ込むことで Lambda 上での実行を可能にしました. 可能な限りCPUコアが欲しいので, 過剰ですがメモリを9,216MBほど割り当てています.

キャッシュサーバの導入

ネットワーク機器の config 読み出しは低速です. また AI による実機アクセスもなるべく避けたいです. そこで config を丸ごとキャッシュし, ネットワーク機器に擬態する kagemusya というツールを別途開発しました.

Playbook内に分岐を挟みdebugモードの場合は, 接続先を kagemusya に切り替えることで, 設定変更の検証を高速に実施することが可能になりました.

対応範囲の拡大

元々は Cisco Catalyst やJuniper SRX などの限定された機器にしか対応していませんでしたが, DeNA で運用されているほぼすべての機器に対応するようになりました. Switch, Firewallにとどまらず, Meraki や Mist などの無線アプライアンス, 内製の資産管理システムへの接続も実現しています.

configの取り扱い

機器 config を構造化データに変換し扱っていましたが, 生の config をそのまま扱うように変更しました. 機器全体で共通化していた config も, 機器ごとに記述するよう仕様変更しました. 元々は人間の扱いやすさを重視し抽象化していましたが, 人間の編集作業が LLM により不要になったため, 実装がシンプルになる方向に倒しました.

構造化データをやめたことで, configパーサとジェネレータが最低限になりました. 新しい機種への対応も接続方式を実装するだけで済みます.

また config 共通化をやめたことで安全性が高まり複雑性が低減しました. 共通化はテンプレートの変更が意図しない機器にまで波及するリスクと常に隣り合わせで, 一部の機器だけ例外にしたい場面では分岐が増え続けます. 機器ごとに config を持てば記述は冗長になりますが, 1機器の変更が他機器に波及しません.

結果として, 機器に投入されるコマンドがほぼそのままの形で並ぶことになりました.

運用について

ここからは実際の運用について述べます. 個々の説明の前に全体図を示します.

基本概念 - IDEALとFACT

まず nwcli の基本的な考え方について説明します. nwcli は管理対象の機器それぞれについて, IDEAL と FACT という2種類のデータを持ちます.

FACT は稼働中の機器に実際に設定されている config データです.² 機器から設定を読み出す factcheck と呼ばれる定期処理によって自動生成されるため, 人が手を入れることはありません. 取得した FACT は nwcli 内部のキャッシュに保持されます. 前述の kagemusya が機器に擬態する際はこのキャッシュを参照します.

一方の IDEAL は機器のあるべき姿です. こちらはオペレータが編集するデータで手順書の役割も兼ねています.

nwcli の主な役割はシンプルで, IDEAL と FACT を比較して差分を提示し, その解消を促すことです. 差分が出たときの解消方向は2つあります. IDEALが正しいのであれば機器へ設定を投入してFACTを追従させ, 機器側の状態が正しいのであればIDEALを書き換えます. どちらに倒すかはオペレータが判断します.

なおすべての設定を差分管理の対象にしているわけではありません. クレデンシャルのように管理したくない設定は予め管理対象外コマンドとして除外されており, 差分にも機器への投入対象にもなりません.

runbook

IDEAL は runbook と呼ばれるリポジトリで管理しています. このリポジトリは手順書の役割も兼ねています.

runbook は拠点ごとのディレクトリで構成されており, 拠点全体の設定を持つ YAML と, 機器ごとの設定を持つ YAML (IDEAL) が置かれています. IDEAL には, running-config 相当のコマンド列がほぼそのまま書かれています. Ansible の role や group_vars はこの IDEAL から実行時に自動生成されるため, リポジトリ上で管理するのはあくまで IDEAL だけです.

手順書としての機能は, 作業の進め方そのものをリポジトリの構造に埋め込むことで実現しています. runbook init コマンドを実行すると作業用ブランチ, そしてレポート用ディレクトリが同時に作られます. あとは IDEAL の YAML を編集し, スキーマ検証をかけ, dryrun で設定適用を流してレポートを生成する, という流れをなぞるだけです. 最終的には IDEAL の差分と投入予定コマンドの一覧, そして作業内容を記述したサマリがひとつの PR にまとまります.

dryrun では接続先が kagemusya に切り替わるため, 実機に一切触れることなく投入コマンドの妥当性を確認できます. 図の下側で Ansible から kagemusya へ伸びている矢印がこれにあたります. レビューを通過してはじめて実機への適用に進む, という順序が作業フローとして固定されています.

つまり手順書を別途書き起こす作業が存在せず, 差分そのものが手順書になります. レビュアーは投入されるコマンドを直接目にすることになるため, 手順書と実作業の乖離が原理的に発生しません. 作業記録も .reports/ 配下に日付と作業名で残り続けるため, 後から「いつ誰が何を入れたか」を追うことができます.

diffcheck

IDEAL と FACT の比較は設定作業時だけでなく定期的にも実施しています. 図の上部にある diffcheck がそれにあたり, 全機器分の差分算出を nwcli に投げ, 結果を差分レポートとして通知します.

これは冒頭で挙げた課題1への直接的な対策です. 誰かが緊急対応で機器に直接設定を入れた場合も, 一時的に入れた設定を戻し忘れた場合も, 次の diffcheck で必ず差分として浮かび上がります. IDEAL に書かれていない設定が機器上に生き残り続けることがなくなり, 「背景も変更者も分からない設定」が生まれる余地を塞いでいます.

オペレータはその差分をどちらの方向に解消するかを判断します. 機器側が正しければ IDEAL を修正し, 切り戻しが必要であれば設定適用を実行して機器側を IDEAL に追従させます. いずれの場合も runbook の PR を経由するため, 定期チェックで見つかった差分にも作業記録が残ります.

factcheck

diffcheck と並んでもうひとつ動いているのが factcheck です. 全機器から設定を読み出して FACT を最新化し, あわせて2つのリポジトリ(nw-fact, nw-config)にバックアップを残します. 定期実行のほかに, 機器へ設定を適用した直後にも自動で実行されます. 適用した時点で FACT は古い状態になるため, 次の diffcheck が誤った差分を報告しないよう, その場で FACT を揃えておく必要があるからです.

nw-fact には, nwcli が内部で扱う FACT がそのまま格納されます. FACTはキャッシュにも保存されますが, 最新の状態しか保存できないため, 履歴の保全はこのリポジトリのGit履歴が担います.

nw-config には, FACT から running-config のみを抜き出したプレーンテキストが格納されます. こちらは機械ではなく人が読むためのものです.

いずれも factcheck の結果から自動生成されるため, 人が直接編集することはありません. ジョブが失敗した場合はアラートが発報されるので, バックアップが静かに止まっていたという事態を避けられます.

AI Agentとの協調

nwcli-mcp

nwcli は内製Agent³ と連携するためにMCPサーバを実装しています. Agent は nwcli から FACT を取得しネットワーク状態を把握できます.

また FACT だけではなく, 障害履歴やメンテナンス情報を EVENT として扱えるようにしました. ネットワーク情報を nwcli に集約することで構成をシンプルにし, またより精度の高い判断が可能になります.

Agentによるオペレーション

前節の内製Agentとは別に, DeNA ではAI社員⁴と呼ばれる Agent が部署に配置されています. AI社員は人間同様にGoogleアカウントを持ち, 様々な社内リソースにアクセスが可能です. またメールやカレンダー, Slackなどに接続するコネクタも持ち合わせており社内情報の収集に適しています.

現在, nwcli の操作権限を付与しオペレーションの委譲を進めています. サーバ設置の制限付きクライアントを用いて実行させるため, 危険な本番操作はできないようになっています.

まず先述した EVENT データの登録を担っています. 障害対応やメンテナンスの情報はメールや Slack に散らばっているため, コネクタで日々の情報を拾える AI社員はこの役割に適しています.

次に diffcheck で検出された差分の解消判断です. 差分を見たときに必要なのは config の読解ではなく, 「この設定が入った経緯は何か」という背景情報です. 前記事では心当たりのある担当者が対応していましたが, 現在は AI社員が収集済みの情報から判断し, IDEAL の修正や切り戻しの PR を作成します.

さらに社内からの変更依頼対応も担っています. 依頼内容から IDEAL を編集し PR を作成するところまでが担当範囲となっています.

まとめ

今回は, AI 時代に合わせて作り変えた nwcli と, その運用について紹介しました.

• キャッシュサーバの導入
  • kagemusya で機器に擬態し, 検証の高速化と安全性を担保
• configの取り扱い
  • 人間が編集することを前提に抽象化していた設定をやめ, 生の config をそのまま扱う方式に変更
• 内製 Agent との協調
  • ネットワーク状態を集約し Agent の品質を向上
• Agentによるオペレーション
  • AIが差分解消の判断まで担当することで, 人間はレビューに集中できるようになった

大きなアップデートがあればまた記事にします. ありがとうございました.