ネットワーク アーキテクチャ考 (34) SDN とは何であったか – 「イノヴェーションの本質」に迫る（1/2）
尊敬する友人である進藤 資訓さんより、ご著書「Software-Defined Networks – ソフトウェア定義ネットワークの概念・設計・ユースケース」[1] （以下「SDN本」）を贈って戴きました。
この本は、私の師の一人であるBruce Davieが原共著者であり、そして進藤 資訓さん、海老澤 健太郎さん、小林 正幸さんという、日頃から尊敬してやまない業界の盟友が日本語版の監修監訳を手がけておられます。喜び勇んで、今夏の第一課題図書として、熟読させていただきました。内容を一言で言うと、SDNの産みの親というべき人々による、アーキテクチャ・設計・実装論です。SDNの歴史的経緯から今後の展望までバランス良くカバーされており、また日本での実装への補足もあり、大変読み応えのあるものでした。そこでこの機に、SDNという、業界を上げて一大ブームになった現象を振り返ってみたいと思います。ご興味を持って戴けましたら、ぜひぜひ「SDN本」をお手に取ってお読み戴けると嬉しいです。
SDNとは何であったか
ONF(Open Networking Foundation)では、SDNの定義を、「The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices. （ネットワーク制御プレーンと転送プレーンを物理的に分離し、制御プレーンが複数の機器を制御する）」と記述しています [2]。
しかしそれまでのネットワークシステムにおいても、制御プレーンと転送プレーンの分離や、制御プレーンによる複数のネットワーク要素の制御は、実際のデザインパターンとして既に存在していました。また、当初 SDN == Openflowという論調もありましたが、Openflow自体は、全ての動作を逐一予め規定する、プリミティブかつ命令的な方法であり、私にはあまり好ましいものには思えませんでした。SDNにより「自律分散」から「集中制御」へと変遷する、という論調もありました。しかし、「集中・分散」はシンプルな二者択一ということではなく、配分や組み合わせ、または傾向の問題です。特に、システム同士が接続するネットワークシステムにおいては、自律分散性による頑健性やスケーラビリティを軽視することはできません。そのような状況で、「今なぜSDNがそんなに騒がれるのか」、「SDNが意味することは何か」、ということについて、かなり考えあぐねていました。このBlogの過去エントリーを見ても大分迷走しているし、当時ネットワーク業界コミュニティにおいて、SDNが真に意味するところの模索を行ったりもしていました [3] [4]。SDN == Openflowだった時代に、SDN Japanカンファレンスで「抽象化手法としてのBGP」を発表したりして [5] 、我ながら奮闘していたと思います。
しかし、「SDN本」に寄せられた序文を読んで、目を覚まさせられました。SDNブームが起こった理由は「機器ベンダーからイノベーションの主権を取り戻す」ためだった、ということです。話が噛み合わないのも無理はありません。「機器ベンダー」へのアンチテーゼだったのに、「機器ベンダー」に所属しながらあれこれ論考し模索していたこと自体が、ナンセンスだったのかもしれません。一緒に模索に付き合ってくださった業界の仲間には、感謝しかありません。
その後、ONFは「OpenFlowは転送プレーンが行うことを記述するための多くの可能なプログラムのうちの一つに過ぎない」という声明を出し [6]、またGartner社によるエンタプライズネットワーキングに関するハイプサイクルレポートでは、「SDNは安定期に入る前に廃れた(Obsolete)」と判断し [7]、Openflowへの過剰な熱や、SDNブームに対する一時的な熱狂は終焉しました。しかし、SDNというトレンドが、今日も業界に対してネットワークシステムのアーキテクチャ変革をもたらしていることは確かです。ネットワークシステムをより自由に、インテント（意図・目的）に基づき、プログラマブルにし、運用も自動化する、という潮流は揺るぎないものになっているし、”Software-Defined”という用語は、現在も多用されています。SD-WAN, SD-Campus, SD-Access, SD-Perimeter、SD-Fabric、SD-RON(Routed Opttical Networking)など、新たに提唱される技術の多くに、”Software-Deined”という接頭辞がつくようになっています。
抽出された技術要素
SDNの本質的な技術要素は、Openflow自体ではありませんでした。そして自律分散に対抗する「集中制御」でもありませんでした。では、SDNの本質的な技術要素は何でしょうか。私は、SDNがもたらしたアーキテクチャ変革から、主要な技術要素を抽出するとしたら、次の2つではないかと考えています。一つは「分解と統合の境界見直し」、そしてもう一つは「宣言的(Declarative)」制御です。
分解と統合の境界見直し
ルーターというハードウェアボックスに統合されていた機能を分解（Dis-Aggregation）することが重要なSDNの技術要素のひとつです。転送を司るスイッチ、スイッチOS、SAI (Switch Abstraction Interface)、ネットワークOS、Northbound APIといった分解が進みました。一方、分解一辺倒だと、コンポーネント数が増大するばかりとなり、複雑性が増す可能性があります。分解されるものもあれば。統合されるものもある。例えば、これまで別レイヤかつ別システムとして運用されていた、オプティカルトランスポートとIPネットワークを統合するRouted Optical Networkingは、新たな統合アプローチと言えると思います。
注目すべきなのは、分解のための境界自体に対して、従来通りではなく、見直しがかかっている、ということです。このことは、これまでのドメイン境界やインタフェース境界にとらわれず、より俯瞰的なアーキテクチャ変遷を可能にすると考えます。
宣言的制御
SDNにより、機能やコンポーネントの分解や階層化が進み、あるモジュールが制御対象のモジュールを制御し、可能な限り自動化する、というモデルが一般的になりました。ここで問題になるのが、その制御方法のあり方でです。OpenFlowは、フローテーブルを命令的に制御しますが、そのことに対し「命令的か宣言的か」という議論が起こりました。
「命令的か宣言的か (“Imperative vs Declarative”)」という論点は、元々はプログラミングパラダイムを論じるもので、Imperative（命令的）はHowを指定するのに対し、Declarative（宣言的）はWhatを指定する、と言われます。プログラミング言語はその多くが命令的であるが、HaskellやClosureなどの関数型言語、SQLなどのDomain Specific言語が，Declarative型、宣言的な言語とされています。
ネットワークシステムにおける「命令的か宣言的か」議論の発端の一つは、2005年にMark Burgessにより分散システムにおけるポリシー実行手法として提案された”Promise Theory” [8][9]であると考えられます。”Promise”とは，エージェント（分散システムにおける基礎的エンティティ）によって「自発的に」合意された「意図(Intent)」であり，エージェントが”Promise”を遂行することにより，望んだ状態(Desired State)に到達します。管理主体が、トップダウンに全てを詳細に指示する (Imperative) のではなく、できるだけ数理に基づき、エージェントの自律性と、ボトムアップ性を尊重する論点です。
SDNブームにより、アーキテクチャ指向が集中制御寄りに傾きましたが、ネットワークシステムの頑健性とスケーリングのためにはボトムアップとトップダウンの折り合いを付けるためる必要があり、そのために「宣言的制御」が適していると考えられた、という面もあります。現在は、クラウドネイティブを実現する手法としても「宣言的制御」が注目されているようになっており [10]、宣言的制御は、その重要性を確立したと思います。
SDN本のご監訳者である進藤さんと共同で、「宣言的ネットワーキング」に関するセッション [11] をやったのも、私にとっては大きな節目となりました。今回献本いただいた時のメッセージにも、「また宣言的ネットワークの話をどこかでやりましょう」と書いて下さっており、胸熱案件であります。
さて、ここまで、SDN本を読ませて戴いたとをきっかけに、ネットワーク業界において一大ブームを引き起こしたSDNという現象を振り返り、SDNの本質的技術要素として
- 分解と統合の境界見直し
- 宣言的制御
を抽出しました。
長くなったので、前編はここまでとし、後編で「イノヴェーション」の本質に迫りたいと思います。
(References)
[1] https://www.shoeisha.co.jp/book/detail/9784798172040
[2] https://opennetworking.org/sdn-definition
[3] MPLS Japan 2012 パネルディスカッション「SDN meets MPLS―よくある歴史の繰り返しか、新たなアーキテクチャ可能性か」https://mpls.jp/2012/index.html
https://cellistmiya.typepad.jp/blog/2012/10/アーキテクチャ変遷の本質-mpls-japan-sdn-panel-session-1.html
[4] SDN Japan 2012 パネルディスカッション 「技術者から見たSDNとその実現技術」https://onic.jp/archive/2012/1207.html
[5] 「抽象化手法としてのBGP」、河野 美也、SDN Japan 2012 https://onic.jp/archive/2012/material-SDN_Japan_2012/7th-panel/MK_BGP_SDN-Japan2012.pdf
[6] https://opennetworking.org/news-and-events/blog/clarifying-the-differences-between-p4-and-openflow/
[8] Mark Burgess, An approach to understanding policy based on autonomy and voluntary cooperation, In IFIP/IEEE 16th international workshop on distributed systems operations and management (DSOM), in LNCS 3775, pages 97–108, 2005
[9] Jan Bergstra and Mark Burgess, Promise Theory, XtAxis Press, February 2014
[10] CNCF, Cloud Native Definition https://github.com/cncf/toc/blob/main/DEFINITION.md
[11] 「宣言的（declarative）ネットワーキング」、進藤 資訓・河野 美也、JANOG45（2020年1月）https://www.janog.gr.jp/meeting/janog45/program/declarative/
Tags:
