インタビュー：ソフトウェア定義ネットワーク（SDN）はネットワークのあり方を大きく変えましたが、同時に独自の問題も生み出してきました。パデュー大学のダグ・コーマー氏は、オープンソース・ネットワーク・オペレーティングシステム（ONOS）のようなSDNコントローラーの分散化が、今後の方向性を示す可能性があると考えています。
Comer 氏の名前は、 The Registerの読者のほとんどにとって馴染み深いものであるはずです。同氏は、インターネットの初期の頃から活動しており、インターネット アーキテクチャ委員会の委員を務め、ネットワークについて論じた書籍の小さなライブラリの著者であり、Xinu 組み込みオペレーティング システムを開発しました。
そして彼は、SDN が重くなりすぎてスケーラブルではなくなるのではないかと懸念しており、それが彼の名前が、パデュー大学コンピューターサイエンス学部の博士課程の学生の 1 人である Adib Rastegarnia との共著者として arXiv のこの論文に掲載されている理由です。
論文「ソフトウェア定義ネットワークにおけるパケット処理の外部化」では、SDN が独自のネットワークの世界にもたらしたものと同じことを SDN にも行うこと、つまり、分散化を提案しています。
ハードウェア分野では、これは、かつては専用の専用ボックスにまとめられていた機能を、汎用コンピュータで実行できるソフトウェアに変換することを意味しています。
しかし、SDN では問題が発生しています。コントローラ自体が多数の貢献者による巨大なプロジェクトになっており、その結果、コントローラが環境内のすべてのフローを処理しなければならないボトルネックになっています。
The Registerのネットワーク担当記者に対し、カマー氏はONOSに含まれる「100を優に超える」関数が負担になっていると述べた。リリースから4年以上が経過した現在、ONOSは1万4000件近くのコミットを集め、コード行数は90万行近くに達している。これは、オンザフライで再コンパイルできるようなものではない。
これが、彼と Rastegarnia が、それらの機能の一部をコントローラーから分離すべきだと提案した理由です。
建築
この論文で強調されている SDN アーキテクチャの特徴は次のとおりです。
- モノリシック コントローラはモジュール化されておらず、中断なく更新することはできず、将来のテラビット ネットワークに拡張できない可能性があります。
- SDN の RESTful ノースバウンド API は標準化が不十分で、単一のコントローラーに依存しています。
- ソフトウェア モジュールは、異なるコントローラー間で簡単に再利用できません。
- 今日のコントローラーはプロアクティブなアプローチを前提としており、プログラマーは作成するフロールールにおいてあらゆる可能性のあるケースをカバーする必要があります。（論文では、分散化によってプログラマーは変化に適切に対応できるリアクティブ管理アプリケーションを作成できるようになると主張しています。）
Comer 氏はThe Registerに、そのアイデアはシンプルだと語った。ONOS の中にすべてを入れるのではなく、ONOS と同じことをするが、コントローラーから機能を分離し、「すべてを内部に入れて 1 つの巨大なイメージをコンパイルするのではなく」というものだ。
ソフトウェアを分離するにあたり、カマー氏は「ルートの設定やファイアウォールの設定といったサービスをコントローラー ソフトウェア自体から移動したいだけだ」と語る。
なぜそうするのでしょうか？それは、パケットを関数にルーティングして処理し、ネットワークに送り返すのではなく、分散型のアプローチによって、フローが必要な場所に関数を移動しやすくなるためです、と彼は説明します。
確かに、このようなアプローチにはリスクがあり、その主なものは効率性です。今日の SDN 環境と比較すると、処理と移動するメッセージの数の両方で余分なオーバーヘッドが発生します。
「分散システムというと、必ず誰かが『非効率だ』と言います。確かにその通りです。費用はいくらかかるのでしょうか？これを実現できる技術はあるのでしょうか？」とコーマー氏は言う。
カフカ風
論文で説明されているように、Comer 氏と Rastegarnia 氏は Apache Kafka メッセージ パッシング環境に落ち着きました。
彼らは、コントローラー内のコンポーネントとしてメッセージ ルーティングを実装することにしました。つまり、すべてのメッセージを受信し、どのメッセージをどの機能に転送する必要があるか、また、どのようにメッセージを渡すのが最適かを決定します。
Comer/Rastegarnia論文の中心となるメッセージパッシングアーキテクチャ
- SDNコントローラー内のKafkaメッセージ配信アプリケーションは、受信パケットのコピーを外部プロセスに提供します。受信パケットをリッスンし、外部の管理アプリケーションやプロセスがアクセス可能なクラスターにパブリッシュします。
- アプリケーションとサービスは、HTTP リクエストを使用して Kafka メッセージ配信アプリをサブスクライブします。
カマー氏は、この時点で、arXiv の論文が非常に初期段階の研究であることを忘れてはならないと語る。論文は答えよりも疑問を多く提起しており、メッセージ パッシングは最も重要な疑問の 1 つである。
しかし、彼はこの論文が分散型アプローチの中核的な特徴を示していると考えている。つまり、コントローラーの役割は、フロー設定、ルート設定、転送ルールといった処理に限定されるということだ。彼はThe Regに対し、「もしその方向に進めば、実現可能であることは既に実証済みだ」と語った。
分散化とは、たとえば 10Gbps ネットワークで、コア以外のネットワーク機能がマイクロサービスに変換されていれば、すべてのパケットまたはすべてのフローをコントローラーにプッシュする必要がなくなることを意味します。
「Dockerコンテナはどこにでも置くことができ、必要に応じて移動できます。現時点で最適な場所にコンテナを移動できます」と彼は言います。
「つまり、ネットワーク機能が稼働している物理サーバーにトラフィックをルーティングするのではなく、その機能をデータフローの近くに移動します。」例えば、ファイアウォールのようなものは複製して、ネットワーク内のすべてのネットワークポイントに1つずつ起動することができます。®
