Software-Defined Networking（SDN）を、わかりやすく解説する特集の最終回。今回は、SDNを検証・開発した企業への取材を基に、2013年当時の理想と現実をまとめた。本記事を最初に公開したのは2013年5月だが、この時期に当時の状況を見直すことで、発展途上にあるSDNの理解を深められるはずだ。
今のところ、現実に存在するSDNは「万能のランプの魔人」ではない。SDNはまだ発展途上なので、足りないところも多いのだ。しかし、きちんと使いどころを選んでいけば、効果的に活用できる。一部の先進ユーザーや事業者などは、そうしたノウハウを蓄積しつつある。
Part3ではまず、そうした「使う側」の企業への取材を基に、SDNの理想と現実を見てみよう。最後の別掲記事では、開発中のSDNのソフトウエアの中で興味深い構成を持つ例や、また、通信事業者の考える今後のSDNの展望なども紹介する。
ネット技術者もプログラムを書く
図3-1の左側に、よく言われるSDNのメリットを挙げた。これらは一面では正しいが、現実にはいくつか制限が伴う（同図の右側）。
SDNの売り文句として「自社でプログラミングして、オリジナルのプロトコルが書ける」というものがある。建前上はその通りだが、現実の開発には手間がかかるし、運用上の制限もある。
SDNのシステムを開発するには、ネットワークに関する深い知識とプログラミングのスキルの両方が必要だ。データセンターの場合、サーバーやストレージに関する知識が要るケースもあるだろう。ところがネットワーク機器の設計・構築・運用を受け持つネットワーク技術者は、必ずしもプログラミングやサーバー、ストレージのことをよく知っているわけではない。
自社のデータセンター向けにSDNのシステムを開発したNECビッグローブの場合は、ネットワーク技術者とサーバー技術者、アプリケーション開発者の混成チームで開発に当たった。ネットワーク技術者はプログラミングを、アプリケーション開発者は大規模ネットワークの構築・運用について互いに教えながら開発を進めたという。
開発後の運用にも、以前とは勝手が違う部分がある。ベンダーから購入した製品の場合、トラブルが起こったらベンダーに問い合わせたり、バグの修正を依頼したりできる。だが自社で開発する場合は、自社で対応しなければならない。トラブル対処へのフローが確立するまでは、今までと勝手が違うため苦労しそうだ。
