こんにちは、殿内(@tonoccho)です
今学校でSoftware Defined Networkを勉強しています。略してSDNですね。自分自身ネットワークに関しては、業務経験皆無、ルータやらスイッチやらのコンポーネントの名前は知っているものの、これらがどういう仕組みで働いているのかもよくわかっていません。そんな自分が勉強したSDNの感想を書いておきます。
カタカナで書くと舌を噛む、もしくは指を釣ることが期待される言葉ですが、英語で書いたら指がきっと疲れます。これまではルータやスイッチをかっちりと要件定義をした上で設定して、導入する、ということが求められていました。なので、ネットワーク技術者に「一体どういうネットワークでホストが何台ですか、ポートは何番を開けますか、うんたらかんたら」と言われては凹まされて帰る人をみましたが、よく考えたらなんでそこまで業務拒否してたのかイマイチわかりませんね。
そういったところから、「スイッチを導入してコントローラとつなぎました、コントローラをこういう風にアップデートしてください」というふうになります。このコントローラがキモになります。
SDNでは、スイッチはパケットが来たら、「このパケットどうするんですか」とコントローラに聞いて、コントローラが「こうしなさい」ということをスイッチに返します。スイッチはこの内容を一定期間保持してパケットを処理します。ということは、コントローラさえきちんと管理できていれば、SDN対応のスイッチを取り替えればそのまま使えるということになります、冪等性ですね。
このコントローラがいくつかあるようで、かつそれらの間の互換性もないためにベンダーロックインは起こり得るのが問題点といえば問題点ですが、この辺の互換性を隠蔽してくれるフレームワークもあったりしますので、気になるならそれを使えば良いでしょう。
変な配置にするとコントローラがSPOFになる上に、コントローラが死ぬとネットワークが全滅する、という点でしょうか。なので、コントローラのデプロイには気を使う必要があります。また、複数のコントローラを配置することも可能なのですが、その場合は、コントローラ相互に矛盾が発生すると死ぬ、とか、そういうことも起こるので、コントローラの設計も大切になります。
それと、技術的には結構な変化になっているので、既存のネットワーク技術者がこれをキャッチアップするのはしんどそうだな、というのもありますね。当然ネットワークのバックグラウンドがある方が有利だとは思いますが。
SDNではネットワーク自体がプログラマブルになるので、DevOpsなんかと相性が良さそうだな、と思っているんですが、授業でいろんな論文を見たのだけど、テストについてのことがあまり書かれておらず、むしろ「こうやってテストしようよ!」というような論文がありましたので、いまはまだ作っている途中なのかもしれません。
いろんな記事を見るとCucumberなんかを使ってテストをする、というのがあるんですけど、「こういうTCPパケットを送るとこうなる」というようなことをGherkinで書くのもなんだかめんどくさそうだなとも思います。ていうか、As誰だよ、という感じです。
またそういったフォーマルなTDDの方法が出来上がっていないSDNという技術なので、いまはとんがった人が大喜びで食いついている時期なのかもしれません。
ネットワークをパーティション化するツールを利用することで、プロダクションネットワークを利用してテストが行えるとか、そういうツールは面白いと思います。Googleがたまに新しいプロトコルを作ってるけど、それもSDNでやっているのでしょうきっと。
なので、現段階のSDNは結構なパワーを持った企業さんとかが導入する段階かなと思っています。あとは、SDNを導入することのコストメリットが激しく大きいところ、電話会社とか?
ただ、もうちょっと気軽にSDNに触れられて、テストもしやすくなってくることで、裾野は広がっていくんではないかと思いました。