SDNは、ネットワーク業界における最も重要なトピックの1つだが、受け入れに関してハードルを感じている企業はまだ多い。さらに普及するために、SDN製品が克服すべき課題とは何なのだろうか。
過去4年近くにわたり、ネットワーク業界を賑わせてきたSDN(Software-Defined Networking)。関連製品は多数提供されるようになってきた。だが全体としては、まだ多くの企業に受け入れられているとはいえないだろう。
どんな技術でも、それが画期的なものに見えるほど、大きな期待が生まれる。中には、「何でもできてしまうのではないか」、あるいは「導入しさえすれば、ほとんどの問題は解決してしまうのではないか」といった過度な期待もある。
関連ベンダーはこの期待の波に乗って製品を市場に送り出すが、「過度な期待」に応えられるわけはない。そこでユーザー企業の「期待外れ」が発生する。だが、その技術の正しい姿が理解されるようになるにつれ、普及が進むというのが一般的な流れだ。
SDNの場合はどうだろうか。その発想は、全体として画期的であり、多くの組織にとってのメリットにつながる可能性があるにもかかわらず、実際に提供されている製品は、残念ながら「適度な期待」にも応えにくいものになってしまっているのではないだろうか。
SDN製品がさらに普及するために、克服すべき5つの課題を解説する。
SDNは、潜在的に大きな可能性を秘めている。だが現実の製品では、その可能性をユーザー企業にとっての明確なメリットに結実させることができていないケースが多い。これでは数年後に振り返ってみると、「SDNは当初騒がれた割には普及しなかった」ということにもなりかねない。
では、SDNが普及するために、SDN製品が克服すべき課題とは何なのか。5つのポイントで説明する。
SDN製品は、「ネットワーク製品のインテリジェンスをソフトウェアに移行することで、ハードウェアに基づく従来のネットワーク製品の限界を超える」ことをテーマとしている。ただし、これまでも、主要ネットワーク製品の機能はソフトウェアとして開発され、これを高いパフォーマンスと安定性で実行するためにハードウェアの最適化がなされてきた。ネットワークの世界がソフトウェアと無縁だったわけではない。
SDN製品ベンダーは一般的に、「ネットワーク機能をソフトウェア化するのがあるべき姿だ」と訴えてきた。だが、なぜソフトウェア化することが「あるべき姿」なのかを、ユーザー企業に対して説明しきれていないケースが多い。今後SDN製品が普及するためには、「ソフトウェア化が自己目的化している」と批判されないようにしなければならない。
上記と大きく関係するが、SDN製品では、ユーザー企業にとってのメリットが曖昧なケースが多い。「この製品を使うと、誰がどのようにうれしいのか」、さらには「この製品を採用すると、組織としてどんなメリットが得られるのか」がはっきりしないと、採用したくても具体的な理由が見つからないことになってしまう。
SDN製品ベンダーは、よく「VLANの『4096の壁』」を指摘する。既存のイーサネットスイッチでネットワークを論理的に分割して管理する「VLAN」という機能が、最大4096個までの分割しかできず、クラウドサービス事業者のマルチテナントニーズに対応できないのだ。また、クラウドサービス事業者が、顧客にITリソースを払い出す際、従来型のデータセンタースイッチでは、ネットワークの準備に時間がかかり過ぎるが、SDNでは迅速に準備が可能という主張もなされる。
実際には、従来型のデータセンタースイッチでも、4096の壁を超えることはできる。また、クラウド基盤との連係により、ITリソースの払い出し時にネットワーク関連の設定を自動的に行えるようになっている。
SDNの具体的なメリットが、「VLANの壁の克服」と「ネットワーク設定の自動化」だけなのであれば、なぜソフトウェア化しなければならないのかが、判然としない。
ネットワークに関して最終的に重要なのは、安定的なパフォーマンスと拡張性だ。SDNがターゲットの1つとしている、商用あるいは企業内のデータセンターでは、データをやりとりする物理/仮想のサーバの数が急増し、データセンターの外との通信量が増えるだけでなく、それ以上のペースでデータセンター内の通信量が増大している。
SDNで先進的な機能が実現できても、パフォーマンスが出ない、あるいは運用規模が拡大すると性能上の限界に達してしまうのでは、本末転倒だ。これらについての確証が得られない限り、「使えない技術」という烙印を押されかねない。
つなげることが本質であるネットワークの世界では、相互接続性が何よりも重んじられてきた。それにもかかわらず、SDN製品ベンダーは、「SDNで、ネットワークの世界をオープンなものに変えることができる」と主張してきた。
では、SDNは、従来のネットワークの世界を超える「オープンさ」を実現できたのか。ソフトウェア化によって、今度はソフトウェアを担当するベンダーが、ユーザー企業のデータセンターネットワーク全体を自社ソフトウェアの制御下に置こうとしている。そこにエコシステムの広がりがないのであれば、ベンダー間の競争をしていることにしかならない。実質的なオープンさがないのなら、ユーザー企業にとってはSDNを採用しにくいだろう。
ほとんどのユーザー企業にとっては、ネットワーク自体が重要なのではない。企業の目的はビジネスであり、そのためのITにおける主役はアプリケーションだ。つまり、ユーザー企業にとって理想的なのは、アプリケーションをデプロイするだけで、そのアプリケーションに最適なネットワークやセキュリティサービスが、自動的に適用されることだ。現実にそこまでは難しくとも、アプリケーション担当者が、デプロイするアプリケーションに必要なネットワーク設定やセキュリティ設定を、他人に頼むことなく自分で即座に適用できるようにしたい。
このような、ユーザーニーズの本質的な部分に応えるものでないと、幅広い企業にSDNを受け入れてもらうことは難しい。
シスコシステムズは、上記のようなSDNの課題を全てクリアするソリューションを、現時点で提供している。それが「Cisco Application Centric Infrastructure」(以下、Cisco ACI)だ。
Cisco ACIは、その名の通り、アプリケーション中心のインフラを目指すアーキテクチャであり、極めて「DevOps」的な考え方に基づいている。DevOpsは、開発と運用を一体化し、効率的な運用体制を実現する考え方のことである。
アプリケーション担当者は、自分のデプロイするアプリケーションに対して、ネットワークやセキュリティに関する設定を抽象化した形で記述した「アプリケーションネットワークプロファイル」を選択するだけで、これらを適用できる。詳細な指示書を書いてネットワーク運用担当者に依頼する必要はない。このため、アプリケーション投入にかかる時間を大幅に短縮できる。
アプリケーションネットワークプロファイルは、実際のところネットワーク担当者が作成するケースが多いが、Cisco ACIでは、その作成作業を大幅に自動化する仕組みも備えている。
アプリケーションネットワークプロファイルの作成者は、アプリケーションが必要とするネットワーク/セキュリティ機能を、抽象的な表現で指定するだけでいい。これで、適切なネットワーク/セキュリティ製品の適切な機能が半自動的にひも付けられる。
ここには、ネットワーク製品1つひとつに対する設定作業はないし、設定対象の製品によって異なるツールやコマンドを使い分けることもない。つまり、アプリケーション担当者だけでなく、ネットワーク担当者の作業も自動化、簡略化される。
上で「抽象的な表現で指定する」と説明した。だが、「それでは個々の製品の機能を十分生かせないのではないか」「最大公約数的な機能しか使えないのなら、事実上使いものにならないのではないか」という懸念が生まれて当然だ。しかし、Cisco ACIではさまざまなベンダーの各種ネットワーク/セキュリティ製品が、標準的な手続きを通じて自らの機能を“広告”、つまりユーザー企業へ通知できるようにしている。従って、アプリケーションネットワークプロファイル作成者は、標準的な機能のみを活用することもできるし、ある製品にしか備わっていない高度な機能を生かすこともできる。
Cisco ACIは、オープンなフレームワークの上に構築されている点も重要な特徴だ。その中核となるプロトコルおよびインタフェースは標準化されている。加えて、シスコは「OpenDaylight Project」などで他社と協力し、Cisco ACIのプロトコルやインタフェースが業界全体で採用されるように活動を続けている。Cisco ACIは現時点でも多数の関連ベンダーが賛同し、大規模なエコシステムを構成している。オープン性を確保して強化する活動がCisco ACIの将来をさらに確かなものにしている。
Cisco ACIの基盤となっているのは、VXLANというプロトコルによるネットワーク仮想化だ。ネットワーク仮想化に関する全ての処理を、データセンタースイッチ「Cisco Nexus 9000」が担うことで、仮想サーバ、物理サーバのいずれからも利用可能なネットワークを構築でき、さらに重要なこととして、安定的な性能を担保している。
SDNは、ユーザーの期待に応えられない限り、幅広い普及は難しい。一方、Cisco ACIは、ユーザーの期待に先回りして答えることで一般的なSDNを超えるSDNを実現し、世界各国での導入が進んでいる。
提供:シスコシステムズ合同会社
アイティメディア営業企画/制作:TechTargetジャパン編集部