Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナを用いたISPネットワーク検証システムとトラヒックシミュレーションによる作業事前検証の実施
Search
tjmtrhs
September 12, 2024
Technology
0
2
コンテナを用いたISPネットワーク検証システムとトラヒックシミュレーションによる作業事前検証の実施
2024年 電子情報通信学会 ソサイエティ大会
依頼シンポジウムセッション
[BI-3]DX時代を支えるICTシステム構築運用自動化の最前線
tjmtrhs
September 12, 2024
Tweet
Share
More Decks by tjmtrhs
See All by tjmtrhs
ISP機器設定ファイルをもとにトポロジモデルを抽出し仮想検証環境構築と運用手順確認に利用する手法
tjmtrhs
0
38
皆がすなるカオスエンジアリングといふものを、ネットワークオペレーションでもしてみむとてするなり
tjmtrhs
0
380
ネットワーク機器もエージェントで監視できるのかやってみた mackerel meetup 14 LT
tjmtrhs
0
1.7k
ネットワーク設定の抽象化とコンテナルータを用いた検証環境の立ち上げ支援
tjmtrhs
0
1k
もし本番ネットワークをまるごと仮想環境に”コピー”できたらうれしいですか?
tjmtrhs
0
100
モデルを基に本番環境を再現して事前に検証可能にする運用サイクル
tjmtrhs
0
21
ASを越えたE2E TEを実現するMulti-AS SR アーキテクチャの提案と検証
tjmtrhs
1
39
機器設定ファイルからのトポロジモデル抽出による机上検査を含めた設計支援システム
tjmtrhs
1
160
NW運用におけるモデル定義とReconciliation Loopへの挑戦
tjmtrhs
3
1.3k
Other Decks in Technology
See All in Technology
[FOSS4G 2024 Japan LT] LLMを使ってGISデータ解析を自動化したい!
nssv
1
210
Platform Engineering for Software Developers and Architects
syntasso
1
520
ドメインの本質を掴む / Get the essence of the domain
sinsoku
2
150
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
180
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
隣接領域をBeyondするFinatextのエンジニア組織設計 / beyond-engineering-areas
stajima
1
270
Can We Measure Developer Productivity?
ewolff
1
150
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
990
Engineer Career Talk
lycorp_recruit_jp
0
160
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
Featured
See All Featured
Become a Pro
speakerdeck
PRO
25
5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
860
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Embracing the Ebb and Flow
colly
84
4.5k
Done Done
chrislema
181
16k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Scaling GitHub
holman
458
140k
What's in a price? How to price your products and services
michaelherold
243
12k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Transcript
コンテナを用いたISPネットワーク検証システムと トラヒックシミュレーションによる 作業事前検証の実施 2024/09/12 2024年電子情報通信学会 ソサイエティ大会 BI-3-03 1 田島 照久
(NTTコミュニケーションズ株式会社), 萩原 学 (TIS株式会社), 滝口 敏行, 前野 洋史 (ビッグ ローブ株式会社), 山口 大樹, 武藤 匠汰 (伊藤忠テクノソリューションズ株式会社), 新里 康晃 (一般社団 法人 沖縄オープンラボラトリ)
NW運用における検証作業 • 本番NW環境作業のリスクが大きい → 机上予測には限界があり、事前の確認が重要 • ISPのようなマルチベンダ・大規模・複雑なNW → 機器単体の局所的な検証では全体への影響がわからない 2
本番環境 検証環境 XXを作りたい ・変更したい 検証環境を 立ち上げよう 試行錯誤 結果を 反映しよう
検証作業の成果物=環境と手順書 • 操作対象の周辺も含めて意図した状態変化になるか確かめる (不確実性の低減) 1. 検証環境を立ち上げる 2. 適切な状態変化を起こせるか試行錯誤する(作業内容に依存) 3. 実施すべきタスクを手順書として確定させる
→ 検証環境を本番環境に近づけ 品質の良い手順書を作る 3 検証環境 検証環境を 立ち上げよう 試行錯誤
現在の運用プロセスと課題 • 十分な検証環境が無く、手順書が机上検討の場合がある • 実行するとどうなるのか、が読み手の解釈に委ねられている • レビュー品質がレビュワーの経験に依存(属人的で不確実) • 特定要員への負荷集中でボトルネックが発生 4
品質向上=不確実性を減らす • 不確実なところ • 手順書のコマンドそのもの → トレーニング等、本提案の対象外 • 手順書実施後の系の状態 →
こちらを解決する → コンテナで検証環境を用意 • 環境準備速度向上、スケールアウトにより手順書作成支援 • 可搬性担保によりレビューが動作検証を兼ねられる 5
コンテナで自NW全体を再現 • メリット • 全体が再現できる → 一部では系としての不確実性を減らし切れない。 そもそも「一部」を切り出すこと自体が難しい(人に依存する) • リソース効率がよい
• 可搬性と再現性がある • デメリット • configを変換しないといけない → config変換を備えた検証環境自動構築システムを作る 6
システム化による利点 • 作業者視点 • 勘で作業を組み立てるのでは無く、実際に動かしながら検証できる • レビュー者視点 • 机上検討ではなく実際の結果を見て判断できる •
管理者視点 • 作業の並列化が可能になる 7
検証システムへの要求まとめ • マルチベンダで構成されるbrown fieldの検証環境を作成 • ネットワーク全体を模擬 • 検証環境でトラヒックが流せる • 何度でも同じ検証ができる
8
トポロジ表現で抽象化し可搬性を確保 NWの構造を抽象化 • 環境に依存する文法ではなく トポロジとしてとらえる • 各レイヤのトポロジを グラフとして表現する 各環境へ翻訳 •
単純にデータ変換ではなく 「同等なもの」にする • 各環境の文法をテンプレ エンジンで生成する 9 Hardware Container 本番環境と検証環境で アーキテクチャ・OS・コンフィグいずれも異なる 本番環境 検証環境 Topology Data
関連する取り組み 10 IIJ Engineers Blog, IXP 管理のフルスタック自動化, https://eng-blog.iij.ad.jp/archives/8668 白紙から構成情報を作る: トポロジをGUIで入力すると
configが出力されるシステム 設定から構成情報を再構築する: AWS上の既存コンポーネントの 依存関係を図示するシステム AWS ソリューションライブラリ, AWS でのワークロード検出, https://aws.amazon.com/jp/solutions/implementati ons/workload-discovery-on-aws/ グラフ形式ではない構成情報: Cisco Configをクラスのインスタ ンスの依存関係で示すシステム 他、Intent Based Networking 多数 藤田ら, 静的解析によるネットワーク構成モデルの 自動検証, IPSJ SIG Technical Reports Vol.2024-IOT-64 No.5
構成情報を中心に本番環境と検証環境を 相互に変換するシステム 11 Original Env. Emulated Env. Convert Hardware Container
Config Topology Data Config ① ② Operator Operator ① 本番configをパースし 構成情報を作成 ② 構成情報から検証環境 を構築 ③ 検証環境でトラヒック 再現など試行錯誤 ③
再現する対象のNWとシナリオ • AS65518を自ASとし、PNIとしてAS65550、POIとして AS65520に接続するISP • PNIとは3台の境界ルータで接続 • PNIとの流量が増えてきたので 広告するprefixを調整したい 12
システム構成 13 Original Env. Emulated Env. Config (Given) L1 topology
(Given) BGP Policy Parser External AS Topology (Given) Config Direct operation Direct operation Cisco Juniper cRPD Converter (convert table) Multilayer Topology Data Step1-1 コンフィグから トポロジデータ生成 Step1-2 トポロジデータの拡張 (データ追加) Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 Operation (手動)検証作業 ターゲットユースケースに合わせた拡張 実行時状態の調整
デモ動画 14
Step1-1 トポロジデータ生成 • 与えられたコンフィグから仮想環境の構築に使用する トポロジデータを生成 • BGPとOSPFの情報はBatfishを通して抽出 • Batfishが対応していない箇所は独自パッチで対応 •
各機材間のL1接続情報はBatfish+NetBox+スクリプトで抽出 • インターフェース情報のデスクリプションから抽出 • デスクリプションの例: Switch-01 Ethernet1 15 Config (Given) L1 topology (Given) BGP Policy Parser External AS Topology (Given) Direct operation Cisco Juniper Step1-1 コンフィグからトポロジデータ生成 Step1-2 トポロジデータの拡張(データ追加)
Step1-2 トポロジデータの拡張 • その1. 外部ASノードの補完 • 外部ASはコンフィグがない • ピア情報からトポロジを拡張する •
その2. BGPポリシーの共通モデルへの変換 • 仮想環境ではIOS-XRのノードをJunos(cRPD)で再現 • JunosとIOS-XRのポリシーを共通のデータ構造に変換 16 Config (Given) L1 topology (Given) BGP Policy Parser External AS Topology (Given) Direct operation Cisco Juniper Step1-1 コンフィグからトポロジデータ生成 Step1-2 トポロジデータの拡張(データ追加) ASレイヤ BGPレイヤ
Step2-1 トポロジデータからの仮想環境構築 • ここまで生成したトポロジデータを使用して仮想環境を構築 • 仮想環境の構築にはconatinerlabを使用 • ネットワーク機器はcRPDで再現 • L2ドメインはOVSで再現
• トポロジデータからコンフィグを生成して各ノードに投入 • jinja2を使用してモデルデータから生成 17 Config Direct operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整
Step2-2 仮想環境設定 • 実施するオペレーションに合わせて仮想環境の設定を変更 • 外部ASから見た優先ピアの変更 • 自ASのトラフィック受信インターフェースを本番環境と合わせる • 内部的には外部ASノードに対してLPを変えたコンフィグを投入
• トラフィックの模擬 • 外部ASのノードの奥にiperfを実行するノードを用意 • 流す際にはプリフィックスごとの帯域が実環境 (実測したフロー情報)と同等の比率になるように調整 18 Config Direct operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整
仮想環境での検証作業 • オペレーションがトラフィックに与える影響を一目で 判断できるように可視化の仕組みを用意 • 仮想環境のノードは全てコンテナなのでコンテナのメトリクスを 取得するcAdvisorとGrafana+Prometheusで可視化 19 Config Direct
operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整
評価 • 検証システムとして ルータは計5+2台, スイッチ1台, EBGP ピア6本, OSPF Area 2つ
コンテナは合計1.57GBのメモリ使用量 configパース~コンテナ起動に3分半 • レビューワークフローとして • 再現試験で機械的にチェックでき 正確性が上がった • 経験の浅い人でもpeer作業できる ようになった • 今まで確認できなかった、対向か らの経路確認などのチェック項目 を作れた • Prefixを移植するベテランの感覚 をロジカルにシミュレートできて いる • 手順書作成がまだ手動なので時間 短縮にはならない 20
future work 「トポロジデータ」の評価 • 本番環境で起こりうるケースをどれだけカバーできているか コンテナにより検証の速度や並列度があがる → より広い範囲の模擬や検討が可能 • ピア先の模倣
(サイズ方面への拡張) • 未来シミュレーション (時間軸方面への拡張) 21
まとめ 検証作業においてISPのトラヒックシミュレーションが可能な コンテナベースの環境構築自動化システムを提案 フィールドトライアルを通じて手順書の精度向上を確認 22