マルチベンダに対応したネットワークコントローラを OSS として公開している話 (NTT Tech Conference 2023)

NTT Tech Conference 2023（https://ntt-developers.github.io/ntt-tech-conference/2023/）
マルチベンダに対応したネットワークコントローラを OSS として公開している話
Track1 16:15〜

Transcript

1. © NTT Communications Corporation All Rights Reserved. マルチベンダに対応したネットワーク コントローラを OSS として開発している話 NTT コミュニケーションズ イノベーションセンター テクノロジー部⾨ Testbed-Service PF PJ ⽵中 幹
2. © NTT Communications Corporation All Rights Reserved. 2 名前: ⽵中 幹 (たけなか もとき) 所属: イノベーションセンター テクノロジー部⾨ Testbed-Service PF PJ 出⾝: 兵庫県 加古川市 趣味: ちいかわ、ポーカー 業務: Multi-AS Segment Routing (SR-MPLS, SRv6) に関する技術検証 SR網運⽤効率化のためのコントローラ開発 =>本セッションの関連内容 Testbed の運⽤・更改 ⾃⼰紹介
3. © NTT Communications Corporation All Rights Reserved. 3 Pola PCE Segment Routing ネットワークにおいてパス管理を⾏うことができるネットワークコントローラ Go ⾔語による実装 • クライアントサーバシステムを導⼊しやすい標準機能 RFC/I-D 準拠・マルチベンダ対応 • ルータとの通信に利⽤するプロトコルが双⽅を満たす実装 OSS 公開 • コミュニティによる既存機能のメンテナンス & 新規機能の追加 • 利⽤者が増えることによるクライアント実装の充実 • NTT Com のプレゼンス向上 本セッションでは Pola PCE の開発・運⽤の中で得た知⾒をお話しします︕
4. © NTT Communications Corporation All Rights Reserved. 4 本セッションで話すこと・話さないこと
5. © NTT Communications Corporation All Rights Reserved. 5 本セッションで話すこと Pola PCE を OSS として実装してみて ü RFC/I-D 準拠・マルチベンダ対応したネットワークコントローラ実装について • RFC/I-D に準拠した実装 • マルチベンダに対応した実装 ü OSS 化するにあたって • プロダクトを使ってもらうための⼯夫 • コントリビュータを増やすための⼯夫 • 良いコードを書くための⼯夫 ü Go ⾔語でクライアントサーバシステムを実装してみた感想 • 学習コストについて • goroutine と channel によるサーバ実装 • interface を使ってコード整理
6. © NTT Communications Corporation All Rights Reserved. 6 本セッションで話さないこと ü OSS の詳細 • 発表資料 https://speakerdeck.com/watal/da-gui-mo-srwang-falseyun-yong-woxiao-lu-hua- surunetutowakukontororafalsekai-fa-ntt-tech-conference-2022 • Pola PCE に関するブログ https://engineers.ntt.com/entry/2022/12/20/090000 • GitHub https://github.com/nttcom/pola ü Segment Routing 技術に関する話 • 発表資料 https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf • ブログ https://engineers.ntt.com/entry/2022/06/13/090000 ü NTT グループにおいて OSS 公開にいたるまでの事務的な⼿続きあれこれ
7. © NTT Communications Corporation All Rights Reserved. 7 Pola PCE (再掲) Segment Routing ネットワークにおいてパス管理を⾏うことができるネットワークコントローラ Go ⾔語による実装 • クライアントサーバシステムを導⼊しやすい標準機能 RFC/I-D 準拠・マルチベンダ対応 • ルータとの通信に利⽤するプロトコルが双⽅を満たす実装 OSS 公開 • コミュニティによる既存機能のメンテナンス & 新規機能の追加 • 利⽤者が増えることによるクライアント実装の充実 • NTT Com のプレゼンス向上 TCP コネクションの上で新しめのプロトコルを 複数のクライアント(ルータ)と対話するネットワーク管理サーバのようなもの
8. © NTT Communications Corporation All Rights Reserved. 8 RFC/I-D 準拠・マルチベンダ対応した ネットワークコントローラ実装について
9. © NTT Communications Corporation All Rights Reserved. 9 RFC/I-D に準拠したサーバ実装 例えば HTTP サーバの場合... 引⽤: https://gobyexample.com/http-servers サーバ機能に必要な • クライアントからのリクエストパケットの受信 • リクエストパケットの解析 • レスポンスパケットの作成 • クライアントへのレスポンスパケットの送信 を net/http ライブラリが⾏なっている
10. © NTT Communications Corporation All Rights Reserved. 10 RFC/I-D に準拠したサーバ実装 なぜ net/http ライブラリの処理が多種多様なクライアントとの通信に使えるか? => HTTP の標準化された技術仕様に従った通信や処理を⾏っているから 通信プロトコルはインターネット標準化団体 IETF によって 標準仕様が決められる RFC(Request For Comment): IETF の発⾏するインターネット技術仕様などについての⽂書群 ⽂書ごとに通番が与えられる I-D (Internet-Draft): RFC 登録前の草案⽂書 https://datatracker.ietf.org/doc/html/rfc9112
11. © NTT Communications Corporation All Rights Reserved. 11 RFC/I-D に準拠したコントローラ実装 ネットワークコントローラ実装において、通信プロトコル⽤のライブラリが 1. あるとき • 通信部分は既存ライブラリで賄えば良い • ネットワーク機器との間でどのような情報を受け渡しするかのみ考慮 2. ないとき • 通信プロトコルライブラリから実装する • サーバ処理は⾃作プロトコルライブラリを import しつつ書く 本セクション、より正確には RFC/I-D に準拠したコントローラ実装 Þ RFC/I-D に準拠したプロトコルライブラリ & コントローラ実装 について⾔及します
12. © NTT Communications Corporation All Rights Reserved. 12 RFC/I-D に準拠したコントローラ実装 プロトコルライブラリがない場合... RFC に従ってパケットの構造とプロトコルセッションの動作を把握して実装する必要有︕ 例えば: • やりとりされるメッセージの種類・⽤途・パケット構造は? • プロトコルの Capability の指定⽅法は? • セッション終了の判断は? 実装⽅法 1. 既存製品のコントローラ・ルータ間のセッションをキャプチャしてパケット解析 • 挙動を理解しつつ製品実装を真似したパケットを⽣成するだけのため⽐較的簡単 2. ルータのクライアント実装と RFC/I-D から各挙動をステップバイステップで実装 • RFC を読んで挙動を理解した上で実装しないと動かないので難しい どちらにしても コードの修正が⾟い... ->->
13. © NTT Communications Corporation All Rights Reserved. 13 実装中のコード修正 プログラムエラー … コンパイル時・実⾏時にエラーの⾏数とエラー内容を出⼒ プロトコルエラー … パケット解析するしかない... プロトコルのエラーメッセージ Wireshark の parse エラー バイト列と RFC を⾒⽐べて各フィールドのデータ・データ⻑・パディングなどが正しいか確認
14. © NTT Communications Corporation All Rights Reserved. 14 RFC/I-D 実装 == マルチベンダ実装 ? RFC に沿った実装を⾏えばマルチベンダに対応した実装になる? HTTP などの枯れたプロトコルの実装に関していえば YES Ø プロトコルの定義やその挙動が RFC によって詳細に標準化され、また共通認識されているため ⼀⽅で、 新しめのプロトコルに関しては NO Ø ⼀部、値の定義が TBD (To Be Determined) となっている場合 • 各ベンダーごとにルータのクライアント実装が独⾃で⾏われたりする Ø プロトコルでの特定の情報のやりとり⾃体が未定義 • 同様に各ベンダーごとに実装が独⾃で⾏われたりする RFC/I-D のバージョン追跡状況によってルータ側で実装がされていない可能性有
15. © NTT Communications Corporation All Rights Reserved. 15 マルチベンダに対応したコントローラ実装 セッションごとに Vendor Type のようなものを管理 Vendor Type 判別はセッション確⽴時に利⽤したメッセージなど から⾏う 良い点: • マルチベンダ対応ツールとして拡張・利⽤できる • (RFC 準拠実装が正しく⾏われていれば) ベンダー実装が RFC 準拠に アップデートされても正常に動作し続ける 悪い点: • ベンダー実装が “⼀部” RFC 準拠にアップデートされた場合想定しない挙動となる コード管理に問題もつきまとうが、マルチベンダ環境で動いた時は⼀番楽しい︕
16. © NTT Communications Corporation All Rights Reserved. 16 OSS 化するにあたって
17. © NTT Communications Corporation All Rights Reserved. 17 OSS に関与してもらう⼈を増やすために せっかく OSS 化したので広く関与してもらいたい • プロダクトを使ってもらうための⼯夫 • コントリビューターを増やすための⼯夫 • プロダクトの品質を⾼めるための⼯夫
18. © NTT Communications Corporation All Rights Reserved. 18 プロダクトを使ってもらうための Example ツールをすぐに試せる環境を準備 ネットワークコントローラとしての課題: • 管理対象のネットワークそのものがまず必要 • 試す環境の作成はコスト⾼すぎ問題 Example を公開 ワンコマンドでネットワーク & コントローラが準備できる (⼀部機能に制限があるが) FRRで構成される環境もあり
19. © NTT Communications Corporation All Rights Reserved. 19 Docker Image を提供中 • 実利⽤時のデプロイ簡略化 • ホスト環境を汚さずにデプロイ GitHub Actions によってタグを打ったタイミングで作成、 アップロードされるように image は GitHub Container Registry より Download 可能 利⽤開始までの README も完備 プロダクトを使ってもらうための Docker Image
20. © NTT Communications Corporation All Rights Reserved. 20 コードの⽤途ごとに配置するディレクトリを決定 プロトタイプ作成段階で勉強会 & 設計会実施 Pola PCE においては • ディレクトリ構成は Standard Go Project Layout (https://github.com/golang-standards/project- layout) を踏襲 • ディレクトリの⽤途・コードの配置・各命名規則は GoBGP (https://github.com/osrg/gobgp) を踏襲 あらかじめの設計で機能拡張やリファクタリング のストレス減 最初期のディレクトリ構成案 コントリビュータを増やすための リポジトリ設計
21. © NTT Communications Corporation All Rights Reserved. 21 実装の対象となる RFC/I-D が多い RFC 5440, 8231, 8281, 8664 pce-segment-routing-policy-cp など 各構造体や定数などに対象となる RFC/I-D の番号・ セクションを記載 => コードや挙動の理解補助 コントリビュータを増やすための RFC 対応コメント
22. © NTT Communications Corporation All Rights Reserved. 22 ディレクトリの定義は済んでいるため、細かいファイル単位での整理 before (Pola PCE v1.0.0) after (Pola PCE v1.2.1) コード修正や機能追加の際の修正箇所特定が容易に︕ プロダクトの品質を⾼めるための リファクタリング
23. © NTT Communications Corporation All Rights Reserved. 23 プロダクトの品質を⾼めるための コード品質評価 コードの品質を定量的に評価したい Go report Card を⽤いてオンラインで評価 • go vet • 問題となり得る疑わしいコードがないか • gofmt • コードに整形できる箇所がないか • gocyclo • 循環的複雑度の⾼い関数がないか • ineffassign • 無駄な変数割り当てがないか • license • ライセンスがあるか • misspell • ミススペルがないか README にバッジをつけられる
24. © NTT Communications Corporation All Rights Reserved. 24 単体テスト、結合テスト共に未実装(犯罪) ü 単体テスト • 単なるサボり • ⼈⼿が...機能拡張優先... • プロトコルエラーの解消に貢献しづらい • VS Code の Go 拡張機能で⾃動⽣成できるらしい (Go Generate Unit Test) ü 結合テスト • ないのがキツすぎる • 拡張・リファクタリング後の IPv4/IPv6 での動作確認に⼤体 30m ~ 1h ほど • テストのためのマルチベンダネットワークがそもそも必要 • できれば GitHub Actions で⾃動化したい ネットワークコントローラのテスト⼿法のアドバイス募集中...︕ プロダクトの品質を⾼めるための Test について
25. © NTT Communications Corporation All Rights Reserved. 25 Go ⾔語でクラサバシステムを実装してみた感想
26. © NTT Communications Corporation All Rights Reserved. 26 学習コストについて 開発者 2⼈とも Go をまともに触ったことがなかった Go 不安ポイント: • 特殊な基本構⽂ • goroutine と channel による並⾏処理 • interface の⽤途 どのスレッドで何を実⾏するかをイメージして構成を練れば実装は⽐較的容易
27. © NTT Communications Corporation All Rights Reserved. 27 なぜ Go? クライアントサーバシステムのサーバ実装と相性が良さそうな標準機能が豊富 goroutine … 指定した関数をマルチスレッドで⾮同期に実⾏するための機能 各セッションごとにスレッドを分けて簡単に管理するなどが可能 channel … スレッド間で情報(データ・シグナル)を共有する機能 分割されたスレッドから分割元スレッドへ同期処理を依頼することが可能 goroutine で簡潔にセッションをスレッド分割しつつ、必要に応じて channel で同期処理が可能
28. © NTT Communications Corporation All Rights Reserved. 28 サーバ実装のサンプルモデル サーバ クライアント サーバ操作者 gRPC サーバ クライアント クライアント TCP コネクション待受 TCP コネクション 上位層 プロトコル 処理 TCP コネクション 上位層 プロトコル 処理 TCP コネクション 上位層 プロトコル 処理 サーバ情報の 受信・更新 コネクション 維持 プロトコルでの 情報交換 ① ① ② ③ ② ② ③ ③
29. © NTT Communications Corporation All Rights Reserved. 29 Go によるサーバ簡易実装例 サーバメインスレッド gRPC Server ⽤ スレッド TCP コネクション 待機⽤スレッド error 受信待ち goroutine での スレッド分割 channel での 同期処理 メインスレッドから 2 スレッド作成 • gRPC リクエストの待ち受け • クライアントとの通信待ち受け どちらかのスレッドで処理が失敗した場合 プログラム終了 実装ポイント① 実装ポイント② 実装ポイント③ TCPコネクション 待機⽤スレッド TCP コネクション ⽤スレッド1 TCP コネクション ⽤スレッド2 TCP コネクション ⽤スレッド3 TCP コネクション ⽤スレッド TCP上位層プロトコル 処理⽤スレッド 終了受信待ち & Keepalive TCP コネクション待機スレッドから クライアント要求に応じてスレッド作成 各コネクションスレッドで処理が失敗・終了 してもコネクション待機スレッドは認知しない TCP コネクションスレッドから 上位層プロトコルの処理スレッド作成 プロトコル処理スレッドからの close シグナルを待ちながら Keepalive
30. © NTT Communications Corporation All Rights Reserved. 30 実装ポイント① サーバ全体処理: サーバメインスレッド gRPC Server ⽤ スレッド TCP コネクション 待機⽤スレッド goroutine goroutine channel channel error 受信待ち
31. © NTT Communications Corporation All Rights Reserved. 31 実装ポイント② TCP コネクション待機処理: TCPコネクション 待機⽤スレッド TCP コネクション⽤ スレッド1 goroutine TCP コネクション⽤ スレッド2 goroutine TCP コネクション⽤ スレッド3 goroutine
32. © NTT Communications Corporation All Rights Reserved. 32 実装ポイント③ TCP コネクション処理: TCP コネクション⽤ スレッド TCP上位層プロトコル 処理⽤スレッド goroutine channel 終了受信待ち & Keepalive
33. © NTT Communications Corporation All Rights Reserved. 36 まとめ • RFC/I-D 準拠実装とマルチベンダ対応実装の⽅法 • RFC 準拠とは • 必ずしも RFC/I-D 準拠 ≠マルチベンダ対応ではない • 実装⽅法について • OSS 化に向けたプロダクト整理 • 公開したプロダクトをさせるために⾏なった⼯夫について共有 • プロダクトが繁栄することを願って... • Test は近いうちに実装しないといけない • Go でクラサバシステムを実装して⾒た感想 • ⾮同期処理が簡単に書けるのでサーバ実装との相性は良い • interface の仕様に馴染むのが個⼈的には難しい
34. © NTT Communications Corporation All Rights Reserved. 37 © NTT Communications Corporation All Rights Reserved. 37 © NTT Communications Corporation All Rights Reserved. ※画像背景⽤（淡⾊） スライドマスターよりコピー＆ペーストにて使⽤ください。
35. © NTT Communications Corporation All Rights Reserved. 38 © NTT Communications Corporation All Rights Reserved. 38 © NTT Communications Corporation All Rights Reserved. ※背景画像使⽤イメージ 38 © NTT Communications Corporation All Rights Reserved.