NetBoxを利用した作業効率化の試み_NetDevNight4

Transcript

1. NetBoxを利用した作業効率化の試み 2026年7月23日 野原 拓実
2. 自己紹介 経歴 2016 〜 2025 :SIerでNW設計構築、自動化開発に従事 自動化はscriptingが中心 2026 〜 現在 : BIGLOBEにてNW自動化・モデル化を担当 趣味嗜好 野原 拓実 のはら たくみ BIGLOBE ビール : BREWDOG PUNK IPA キーボードサイズ : 60% or 40% (GoForty良いよ！) その他趣味 : カメラ (富士フイルム, RICOH) / バイク (Aprilia) / コーヒー / クラフトビール / 自作PC Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 2
3. アジェンダ • • • • 背景 NetBoxによる作業効率化取り組み 取り組み結果と得られた知見 展望 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 3
4. 背景 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 4
5. 背景 マルチベンダによるバックボーンネットワークの構成・運用 各装置はベンダに関わらず、単一のポリシーのもとで動作するように設計。 内外の接続におけるポリシーは確立しているが、ドキュメントにとどまっており、ドキュメントからConfigへ翻訳する必要があった。 BB内接続・対外接続 ポリシー A社 Config route-policy xxx if xxx then set xx done ... B社 Config policy-options { policy-statement xxx { term xx { from { ... C社 Config configure { policy-options { policy-statement “xxx” { entry xx { from { 単一の意図・動作 ①翻訳作業 IX ISP CDN ピアリング バックボーンネットワーク ②装置へ適用 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 5
6. 背景 手作業による対外接続作業の課題 課題1: 設計からConfigへの変換負荷 • ポリシーでは意図が示されていても、最後は機器別のConfigへ翻訳する必要がある • 作業者は毎回ポリシードキュメントを参照し、必要な記述を頭の中で組み立てていた • ベンダ/OS差を吸収するため、レビューでも「設計意図どおりか」と「記法として正しいか」の両方を見る必要があった 課題2: 手順書作成とレビューの負荷 • 手順書作成が手作業で、Config作成後に別の文書として再構成する必要があった • 人が作成 → 人がレビューの連鎖がボトルネックで、作業件数が増えるほど滞留しやすい • レビューでは、可変パラメータだけでなく固定的な説明文まで毎回追うことになり、漏れの余地が生まれる ポリシーDoc 課題1 過去実績 現Config 課題2 参照 参照 参照 レビュー レビュー Config作成 手順書作成 作業者 1次レビュア 2次レビュア Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 6
7. NetBoxによる作業効率化取り組み Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 7
8. NetBoxによる作業効率化取り組み NetBoxとは ネットワーク機器やデータセンターの情報を一元管理するためのプラットフォーム。DCIMとIPAMの両方の機能を持つ。 REST/GraphQLといったAPIを利用した他システム連携により、NW自動化におけるSSoTの役割を担うことができる。 ※ DCIM: DataCenter Infrastructure Management, IPAM: IP Address Management, SSoT: Single Source of Truth. SoT(Source of Truth)ともいう Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 8
9. NetBoxによる作業効率化取り組み 各課題への解決方針 課題 方針 ねらい 1. Config変換の負荷 Config・ポリシーを中立データで表現 Config変換をロジックに置き換える 2. 手順書作成・レビューの負荷 テンプレート+パラメータ化 作成とレビューを標準化 NetBoxをSSoTとして使い、インテントベースの自動化基盤を構築 →元々、NetBoxをインベントリ管理ツールとしては使っていなかったため、純粋なSSoTツールとして使うことができた。 全体Config Configレンダリング ②コンフィグ生成 作業者 フォーム画面 手順生成 ワークフロー 手順書テンプレート Config差分 ＝投入Config ①データ登録&取得 &不整合検知 作業手順書 ③作業手順書生成 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 9
10. NetBoxによる作業効率化取り組み 課題1: Config変換の負荷 対外接続はBGPピアリングが中心、ただし標準のNetBoxにBGP向けテーブルが不足 ドキュメントベースのポリシーとパラメータの対応関係をデータとして保持したい → netbox-bgpプラグインを採用 → custom-objectsプラグインを採用 Configの1行1行をそのまま保存するのではなく、「どの条件で、どんな挙動を実現したいか」を表す単位に分解する。 各OSのConfig表現の差はテンプレート＋フィルタが吸収し、設計意図そのものは共通の形で管理できるようにした。 ポリシー: 東阪2拠点でピアリングしている状況で内向きトラ フィックを東京に寄せる場合、東京のMEDをxxx 中立的なデータ route-adv-pollicies table: location attr value tokyo med xxx osaka med yyy netbox-bgp A社 テンプレート B社 テンプレート A社 Config 内製フィルタ custom-objects C社 テンプレート ポリシーデータ例 custom-objectsで作成 B社 Config C社 Config テンプレート+フィルタが変換 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 10
11. NetBoxによる作業効率化取り組み 課題1: Config変換の負荷 フィルタによるOS差の吸収の例: Prefix List OS prefix list仕様 route policyへの適用 IOS-XR prefix + ge/leをエントリごとに定義 prefix listを適用 Junos prefix のみ定義 • • prefix listを適用 + prefix長範囲を指定 route policyに直接定義 (prefix list不使用) IOS-XR と Junos では上記の仕様の差がある → NetBoxとしては、prefix listはge/le込みのデータを保持する。 (IOS-XRの仕様に寄せる) JunosのConfigをレンダリングする場合、フィルタで表現方法を判断する。 • • prefix list: 表現が不可能である場合、レンダリングしない route policy: prefix listで表現できない場合、直接定義する Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 11
12. NetBoxによる作業効率化取り組み 課題1: Config変換の負荷 フィルタによるOS差の吸収の例: Prefix List IOS-XR テンプレート prefix-set customer1 192.0.2.0/24 ge 25 le 28, 198.51.100.0/24 le 32, 203.0.113.0/24, end-set route-policy customer1 if destination in customer1 then set med 100 done endif end-policy フィルタ Junos テンプレート policy-options { policy-statement customer1 { term 10 { from { router-filter 192.0.2.0/24 prefix-length-range /25-/28; router-filter 198.51.100.0/24 prefix-length-range /24-/32; router-filter 192.0.2.0/24 exact; } then { metric 100; accept; } } } } Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 12
13. NetBoxによる作業効率化取り組み 課題1: Config変換の負荷 フィルタによるOS差の吸収の例: Prefix List IOS-XR テンプレート prefix-set customer1 192.0.2.0/24 ge 25 le 28, 198.51.100.0/24 le 32, 203.0.113.0/24, end-set route-policy customer1 if destination in customer1 then set med 100 done endif end-policy フィルタ Junosではこのデータでprefix listの Configにすることはできない。 そのため、prefix listは作らず、 route policyでは直接定義する。 Junos テンプレート policy-options { policy-statement customer1 { term 10 { from { router-filter 192.0.2.0/24 prefix-length-range /25-/28; router-filter 198.51.100.0/24 prefix-length-range /24-/32; router-filter 192.0.2.0/24 exact; } then { metric 100; accept; } } } } Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 13
14. NetBoxによる作業効率化取り組み 課題2: 手順書作成・レビューの負荷 フォーム入力と手順書テンプレートから作業手順書の生成: 新しい対外接続を行う際に、フォームにパラメータを入力しNetBoxでバリデーションをしつつ、データ登録。 フォームパラメータ+NetBoxから取得したデータ+手順書テンプレートで、作業手順書と投入Configを生成する。 生成された文書は、NetBoxでデータ不整合が起きない(=適用できるConfig)が保証されている。 作業者にはフォームというフロントを見せることで、NetBoxに必要なデータを取りこぼさない+入力ルールを自動的に守らせる。 全体Config Configレンダリング ②コンフィグ生成 作業者 フォーム画面 手順生成 ワークフロー 手順書テンプレート Config差分 ＝投入Config ①データ登録&取得 &不整合検知 作業手順書 ③作業手順書生成 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 14
15. NetBoxによる作業効率化取り組み 課題2: 手順書作成・レビューの負荷 投入Configの生成: netbox-branchingを採用。NetBoxがGitのようにブランチを持てるようになり、ブランチごとに異なるデータを保持できる。 ワークフローから登録されたデータは、メインブランチから派生させた作業ブランチに対し登録。 メインブランチは現在の状態、 作業ブランチは未来の状態となり、2者間のデータの差分を表すことが可能になる。 それぞれのブランチでConfigをレンダリング → “作業－メイン=差分Config”を投入Configとして生成する。 メインブランチ netbox-branching ④Configレンダリング 作業者 ①ブランチ作成 フォーム画面 手順生成 ワークフロー ②派生 ⑤diff 投入Config ③作業ブランチに対して データ登録 ④Configレンダリング 作業ブランチ Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 15
16. NetBoxによる作業効率化取り組み 作業手順書作成フローのBefore/After Before ポリシーDoc 過去実績 現Config 参照 参照 参照 レビュー レビュー Config作成 手順書作成 作業者 1次レビュア 2次レビュア After 手順生成ワークフロー レビュー レビュー Config作成 手順書作成 作業者 1次レビュア 2次レビュア Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 16
17. NetBoxによる作業効率化取り組み 作業手順書作成フローのBefore/After Before ポリシーDoc 過去実績 現Config 課題2 参照 課題1 参照 参照 レビュー レビュー Config作成 手順書作成 作業者 1次レビュア 2次レビュア After レビュアは、 NetBoxと手順書テンプレートが 信頼できる情報である前提のもと、 生成されたConfigと手順書は 与えられたパラメータだけを見れば レビュー可能となり負荷が低減。 作業者は余分な文脈を 持つ必要なく、 ワークフローより 作業準備を開始できる。 場合によっては2次レビュアも 不要となる。 手順生成ワークフロー レビュー レビュー Config作成 手順書作成 作業者 1次レビュア 2次レビュア Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 17
18. 取り組み結果と得られた知見 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 18
19. 取り組み結果 効果1: Config品質の安定化 • • • データ + ロジックから生成されるため、作業者ごとの書き方のブレが出にくくなった 「この接続でさせたい挙動」が先にデータとして定義されるため、ポリシーとの対応関係を追いやすい レンダリング結果を基準として扱えるので、実Configとの差分を見たときにドリフトを発見しやすくなった → 単にConfigを作るのが速くなるだけでなく、正しい状態を継続的に判断するための物差しを持てるようになった。 効果2: 手順作成とレビューの効率化 • • • • 手順書作成スピードが向上し、Config作成後に別文書へ転記・整形する負荷を減らせた テンプレート化により、説明順序や確認観点のばらつきが減り、手順書の品質を揃えやすくなった レビューではテンプレートそのものではなく、入力パラメータと生成結果の妥当性に集中しやすくなった レビュアーは毎回全文を読み直すよりも、本当に変わる部分を重点的に確認する運用へ寄せられた → 作成者にとっては負荷軽減、レビュアーにとっては確認観点の明確化という、両側の改善につながった。 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 19
20. 知見 1. NetBoxで全Configデータを表現しない（できない） Configは運用管理・アドレッシング・プロトコル・セキュリティなど多岐に渡る。 →それら全ての情報をNetBoxのデータに登録することは不可能 データは2種類に大別してNetBoxに登録する。 • インベントリとして参照したいデータ（デバイス/IF/IPアドレス/BGPセッション等） • パラメータのみのデータ パラメータのみのデータは、Configがパターン化されている場合に有効。 パターン化ができなくなるとインベントリとして管理する必要がある。 ・hostname ・syslog/snmp ・netflow ・interface/lag ・ipaddress ・vlan ・static route ・ospf/ospfv3 ・bgp ・mpls ・vrrp ・route policy ・acl ・qos それぞれについてのテーブルを NetBoxで持たせることは非現実的 IPアドレス テーブル デバイス テーブル VLAN テーブル BGP テーブル ACL: A QoS: B netflow: C OSPF: D カスタムフィールドやロールなどで パラメータを保持 Interface テーブル Configテンプレート インベントリ管理したい情報に絞って テーブル化 テンプレートが生成ロジックを持つ Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 20
21. 知見 2. データの一貫性の保持 フィールドへの入力ルールに加えて、オブジェクト間の関係についても一貫性を持たせ、ルールを作る。 例) InterfaceテーブルでIPアドレスを関連付けさせるのは必ず「仮想」タイプにする Junosのunit、SR OSのinterfaceに寄せ、IOS-XRデバイスでも同様にする 一貫性が保たれていないとSSoTとして成り立たなくなる。 → インベントリ管理のNetBoxからSSoTのそれへの移行では、データの持ち方のルール決めと移行(クレンジング)で苦労すると予想 IOS-XR 重視したポイント： 異ベンダでもテンプレート切り替えでConfigレンダリングができる 「仮想」タイプのIPアドレスを（SubIFでなければ)物理IFのIPアドレスとして レンダリングするように、テンプレート側で制御 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 21
22. 知見 2. データの一貫性の保持 フィールドへの入力ルールに加えて、オブジェクト間の関係についても一貫性を持たせ、ルールを作る。 例) InterfaceテーブルでIPアドレスを関連付けさせるのは必ず「仮想」タイプにする Junosのunit、SR OSのinterfaceに寄せ、IOS-XRデバイスでも同様にする 一貫性が保たれていないとSSoTとして成り立たなくなる。 → インベントリ管理のNetBoxからSSoTのそれへの移行では、データの持ち方のルール決めと移行(クレンジング)で苦労すると予想 重視したポイント： 異ベンダでもテンプレート切り替えでConfigレンダリングができる Junos 「仮想」タイプはunitと紐づく Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 22
23. 知見 2. データの一貫性の保持 フィールドへの入力ルールに加えて、オブジェクト間の関係についても一貫性を持たせ、ルールを作る。 例) InterfaceテーブルでIPアドレスを関連付けさせるのは必ず「仮想」タイプにする Junosのunit、SR OSのinterfaceに寄せ、IOS-XRデバイスでも同様にする 一貫性が保たれていないとSSoTとして成り立たなくなる。 → インベントリ管理のNetBoxからSSoTのそれへの移行では、データの持ち方のルール決めと移行(クレンジング)で苦労すると予想 重視したポイント： 異ベンダでもテンプレート切り替えでConfigレンダリングができる SR OS Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 23
24. 知見 3. ユニークなConfigと自動化のトレードオフ OSごとに存在するユニークな記法は自動生成を難しくする 例) IOS-XRのif文のネスト 柔軟な条件を設定可能だが、Configレンダリングのロジックが複雑化し、他OSと互換性を保つのが難しくなる。 対応: 既存Config側を見直し、NetBoxに落とし込みやすい形へ 学び: 自動化に合わせて設計/記述側も歩み寄る route-policy asXXXX-customer-1 if as-path in asXXXX-1 or as-path in asXXXX-2 then if destination in asXXXX-prefixes then set local-preference 100 set community customer additive done elseif … then … endif endif drop end-policy route-policy asXXXX-customer-1 if as-path in asXXXX-1 and destination in asXXXX-prefixes then set local-preference 100 set community customer additive done elseif as-path in asXXXX-2 and destination in asXXXX-prefixes then set local-preference 100 set community customer additive done endif drop end-policy ・orを分解し、それぞれ独立したルールに ・ネストされたif文のルールを、ネスト元のルールにandで連結 人の目で見ると冗長な書き方に見えるが、 自動化観点ではこちらの方が管理しやすい Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 24
25. 展望 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 25
26. 展望 1. 対象サービス拡大 現在対応できているのはBBNWへの対外接続の一部のため、対応できるサービスを拡大してゆく。 2. リプレース時のConfig変換 テンプレートの差し替えで即座に別OSのConfigを生成、リプレース作業の期間を短縮。 3. 人手介在を減らしシステム直接実行へ 今回は作業を人が実施する前提のシステムを作り上げたが、 将来的にはNetBoxのデータ追加/変更と連携し、自動で装置へConfigの変更を行えるように。 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 26
27. 以上 Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 27
28. Appendix 本資料で紹介したNetBoxプラグイン • netbox-bgp https://github.com/netbox-community/netbox-bgp • netbox-custom-objects https://github.com/netboxlabs/netbox-custom-objects • netbox-branching https://github.com/netboxlabs/netbox-branching Copyright ©BIGLOBE Inc. 2026. All rights reserved.｜ 28