運用者の試行錯誤を想定したNWモデル上での並列検証システム

Okinawa Open Days 2024

ネットワークの変更作業による影響は予測が困難で、複数の作業案を事前検証するニーズがありますが、機材や時間面の制約があり十分な検証ができません。
本プロジェクトでは、本番NWの構成情報をデータとして抽出し、候補となる作業案の生成〜仮想環境での再現〜状態の収集を自動化します。
運用者は再現結果を見て良い案を選べます。
このようなNW構成変更時の事前検討・検証プロセス改善策を提案します。

Transcript

1. 運用者の試行錯誤を想定した NWモデル上での 並列検証システム Model Driven Network DevOps Project 1 2024-12-06 Okinawa Open Days 2024 TIS株式会社 NTTコミュニケーションズ株式会社 ビッグローブ株式会社 伊藤忠テクノソリューションズ株式会社 萩原 田島 滝口・前野・島袋 山口・武藤 © 2024 Okinawa Open Laboratory
2. 課題・実現したいこと 2 © 2024 Okinawa Open Laboratory
3. NW運用の課題…不確実さへの対応 3 観測・操作可能なのは特定のポイントのみ: 流量、flow、受け取っている/広報している経路… 他の出入り口でどうなるか? 出入り口を増やしたらどうなるか? NW全体の動作はどうなるか? 空間的な観点での 予測の難しさ・不確実性 今はこれくらい流れてるけど、 明日これくらいまで増えたらどうなる? あのpeerから予告があったイベント日は どんな状態になりそう? 時間的な観点での 予測の難しさ・不確実性 内部の 状態変化 外部NW (ブラックボックス) の状態変化 これらのパターンの組合せ……「やってみないとわからない」にどう向き合うか? © 2024 Okinawa Open Laboratory
4. 不確実さへの対処…システム化 • 空間的・時間的不確実さへの対処: 検討範囲が広い • NW全体の挙動を考える……これまでは人の頭の中 • 人力で検討・検証可能な範囲(パターン)は限られる • この部分を何らかの形で「システム化」しないとスケールさせられない • 現状、人が頭の中で考えて理解・検討・判断している運用操作のシナリオをどう やって機械に落としていく(システム化する)か? • 経験、暗黙的なノウハウ、職人芸…etc © 2024 Okinawa Open Laboratory 4 設計・対応案検討 部分的な機能検証・案の絞り込み 詳細動作検証(1-2案) 方式決定 実施 機器設定の自動化で対応可能なのは、 プロセス全体からすると一部 やりたいこと 要件 人が頭の中で考えていること…NWの構造を基に行っていることを 機械でもできるようにする(システム化)する 現在の プロセス 人力で検討可能な範囲や検証可能なパターンは 時間的にも計算機リソース的にも制約がある
5. モデル化 • NWに対する操作を、NWの構成・構造を基に考えているので あれば、その情報を機械でも扱えるようにする必要がある • ネットワークの「モデル」が必要 5 運用対象の 実NW NW全体を表現する データ NWに対する操作 設計書・構成図… 最後はNW機器コマンドの列 NWに対する操作 データ操作 人が頭の中で考えていた操作 (NWに対するオペレーション)を データ操作の形で表現できるようにする 等価 © 2024 Okinawa Open Laboratory
6. モデル中心アプローチ 6 あらゆる情報処理、判断を人が行う 人がボトルネックになる 人が扱える情報量には限界がある 人はスケールしない 人には揺らぎがある 情報処理をシステムで支援する 人は重要な判断や操作にシフトする 情報量や複雑さに マシンパワーとロジック(アルゴリズム)で対抗する モデルと ロジック © 2024 Okinawa Open Laboratory
7. 応用: 検証プロセス 7 これまで 運用者の知識と経験で 試行錯誤の果てに欲し い状態を得ていた これから 環境操作をデータ操作 に変換して並列実行・ 運用者は結果を見て判 断をくりかえす 本番環境 (as-is) 本番環境 (to-be) 検証環境 モデルデータ (as-is) 運用者による試行錯誤 モデルデータ (to-be) commit ! rollback ! それぞれ仮想環境を建てて、 トラヒックを流し、流量計測 運用者による モデル選択 想定される操作を加えた モデルデータを生成 複数の候補モデル (candidate) • • • commit ! 必要に応じてくりかえし 必要に応じてくりかえし rollback ! 試行錯誤をデータ操作として実装 まとめて検証を実施し、 結果を確認して良いものを選ぶ © 2024 Okinawa Open Laboratory
8. 実装とユースケース 8 © 2024 Okinawa Open Laboratory
9. システム構成 9 検証環境 本番環境 データ操作 検証環境(worker)操作 cAdvisor Prometheus • • • 本番環境 コンフィグ等 トポロジデータ (as-is) トポロジデータ (candidate) 検証環境 コンフィグ等 状態観測 データ収集 データ可視化 得られたcandidateトポロジを基に 本番NWオペレーションを実施 (今回はフォーカス外) ノード 操作 トラフィック 生成 iPerf3 環境 操作 batfish コンフィグ解析 フローデータ等 Juniper cRPD © 2024 Okinawa Open Laboratory 検証結果を見て選択 コントロール
10. ユースケース • PNIまたはIXで接続されている複 数のASがある • PNI(AS-A)からのトラフィックが 増えてあふれそう • AS-Aからのトラフィックをどの ように制御するか? • NW全体を見て判断 …AS-Bからのトラフィックも考慮 © 2024 Okinawa Open Laboratory 10 自AS 65518 AS-A 65550 AS-B 65560 AS-C 65520 edge01 edge02 edge03 edge11 core (RR) ! 外部AS/トラフィック流量は、 実環境で測定したフロー データを基に設定する IX
11. configからモデルの構築 • input: configuration + topology data (L1) + usecase params • output: original model © 2024 Okinawa Open Laboratory 11 本番環境 (original env) • コンフィグ • L1トポロジ batfish コンフィグ解析 BGPポリシ パーサー トポロジデータ (original as-is) 自ASのみ Batfishで解析できない コンフィグの 解析・取得・マージ 外部AS トポロジ コンフィグからは取得で きない外部AS情報の 生成・マージ ユースケース パラメタ トポロジデータ (original as-is) 外部AS含む
12. モデルを変更 • input: original model • 一つの操作に見立て、モデルを編集する • 候補(candidate)が複数できる • output: candidate models © 2024 Okinawa Open Laboratory 12 • • • トポロジデータ (candidate) トポロジデータ (original as-is) 外部AS含む • ユースケースパラメタ • (フローデータ) Candidate モデル生成 名前空間の変換 やりたいことに対して想 定されるNW操作をデータ 操作の形で実装する 従来の”試行錯誤" 想定されるモデルの バリエーションをどう作るか
13. • • • 各候補モデルでシミュレーション • input: original model, candidate models • output: stats © 2024 Okinawa Open Laboratory 13 検証環境 cAdvisor • コンフィグ • 検証環境定義 状態観測 ノード 操作 トラフィック 生成 iPerf3 環境 操作 Juniper cRPD Prometheus データ収集・表示 テンプレート エンジン トポロジデータ (candidate) iperf設定 生成 フローデータ worker 各トポロジデータについて トラフィック流した 結果(各所の流量)を収集する 変更前(original)と 変更後(candidate)の データ収集 各トポロジデータについて 検証環境を分離する (workerとして扱う) Grafana トポロジデータ (original as-is)
14. 運用者が結果を見て判断 • input: stats xN • output: どのcandidate modelが良いか © 2024 Okinawa Open Laboratory 14 Prometheus データ収集 • • • トポロジデータ (candidate) Stateの集計と それぞれの比較 流量のグラフ化 • • • 変更前(original)と 変更後(candidate)の比較 結果がよかったモデルを選択する トポロジデータ (original as-is) 検証環境 比較元 (変更前) 比較先 (変更後)
15. 運用者が結果を見て判断 • 1つ解決できれば終わりではない • 連動してほかの個所が問題になる • NW全体で判断・確認が必要 © 2024 Okinawa Open Laboratory 15 ! 最初に問題になったポイントで制御 その結果他のポイントが問題に 次のステップで制御する 選択した Candidate model
16. 次の操作を模擬するため再度候補作成 • input: 先ほど選択したmodel • output: candidate models © 2024 Okinawa Open Laboratory 16 • • • トポロジデータ (candidate) トポロジデータ (candidate) • ユースケースパラメタ • (フローデータ) Candidate モデル生成 Prometheus 基になるトポロジを変えて再実行 起点を変えて他のバリエーションを 探索する 同様に、変更前(original)と変更後 (candidate)を比較して、結果がよ かったモデルを選択
17. 次の操作を模擬するため再度候補作成 • 最終的に全体のトラフィックをバ ランスさせられたことを確認して 終了 © 2024 Okinawa Open Laboratory 17 選択した Candidate model
18. 最終的に得られるもの • output: to-be model • 差分コンフィグの生成等は昨年度成果で報告しているので今回は省略 © 2024 Okinawa Open Laboratory 18 トポロジデータ (original to-be) トポロジデータ (original as-is) テンプレート エンジン 差分データ 生成 変更後(to-be) コンフィグ 本番環境 (original env) トポロジデータ (candidate) 名前空間の 変換 本番環境への適用は 既存の運用フローに従って実施
19. 技術的な課題と対応 • 状態計測(流量)における変換個所の設定 • 状態(流量)の可視化・加工を複数個所で行うようになる……Prometheusの前で変換をかけた がパフォーマンス問題 • 名前(識別子)だけでなく流量(どれくらいスケールダウンしてトラフィックを流すか)について も変換が必要 • BGPポリシの考え方の違い/標準化 • C/Jのprefix-setに対するマッチ条件の考え方が異なる • Workerの分離 • k8sバックエンドを検討したが、コンセプトはともかく実動としては使えなかったので、 containerlab 単位での分離で実装 • 将来的にはk8sバックエンドでの実現が視野に入るだろう • 環境操作API: EDAで実現→環境操作のステートをどのように管理するか(終了判定) • 並列に複数環境を起動したときの流量測定データの取り扱い © 2024 Okinawa Open Laboratory 19
20. 拡張余地 • 「賢さ」の導入 • GenAIでもheuristicsでも、あとから入れられる • 幅方向のスケール • 並列度を上げると、かかる時間はO(深さ)にしか依存しない • 職人技のコード化 • 高度な技をコードにして再利用しよう © 2024 Okinawa Open Laboratory 20
21. まとめ 21 © 2024 Okinawa Open Laboratory
22. まとめ • 運用プロセス全体をシステム化する • 人がやっていた「試行錯誤」のシステム化 • 探索的な検証アプローチ • 「実現したいこと」へのフォーカス • 実際に動かして得られた結果(状態変化)をもとに判断: 役割分担 • データドリブンな運用: トラフィックデータ等の利活用 • 不確実さへの対応 • より広く速く、計算機リソース次第で探索範囲を向上させる • 人力では難しい範囲(パターン)の変更案探索 © 2024 Okinawa Open Laboratory 22
23. Future work • こういった応用方法を前提にした時の、現行システムの情報 (フローデータ等)の集め方・使い方の見直し • 時間的な不確実さへの対処…現状をベースにした将来予想 • モデルデータ操作エンジンのバリエーション • LLM応用などの可能性 • リソースプール(worker backend)の効率化 • おそらく将来的にはk8sバックエンドに置き換えられるはず • 関連プロダクトの調査・検証 © 2024 Okinawa Open Laboratory 23
24. © 2024 Okinawa Open Laboratory ”モデル”を核とした運用プロセス 24 platform interface 実機 ハードウェア製品 VM ソフトウェア製品 コンテナ ソフトウェア製品 k8s等のオーケストレータ UI 必要なデータの選択 可視化・操作 検査 システム構成要素の 関係性を踏まえた Validation シミュレーション 実機がなくても 可能なテスト 宣言的なシステム運用 CI/自動テストなど ソフトウェア開発やクラウド開発の ベストプラクティスのとりこみ デプロイ前のテストと予測可能性 静的な検査・動的なテスト 練習・トレーニング・育成 CI 自動テスト システム 構成データ
25. 成果公開 • プロジェクトページ • https://www.okinawaopenlabs.org/mdnd • 開発したツール、デモ用のデータ等はGithubで公開しています • https://github.com/ool-mddo/playground • デモ動画 • https://youtu.be/jO3bj1aNNeA 25 © 2024 Okinawa Open Laboratory