今さら聞けない「ロードバランサとSDNの切っても切れない関係」(1) SDNが注目される背景を再確認しよう

いまネットワークの世界で大きな注目を集めるのが、「SDN（Software Defined Networking）」と呼ばれる2011年頃から注目を集めているコンセプトだ。これは、ルータやスイッチなどネットワーク機器にひも付いていた設定や処理統計データなどを個々のネットワーク機器から切り離し、ネットワーク全体を見渡すことができる集中管理ソフトウェアへコントロールを移すアプローチだ。コントローラで集中管理することで、ネットワークに随時発生する要件に対して、従来よりもネットワークを迅速かつ柔軟に構築・運用できるようになる。

SDNが注目される主な背景には、クラウドよるITの消費スタイルの変化やサーバ/ストレージの仮想化技術がデータセンターに浸透する状況において、ネットワークは柔軟性/拡張性/運用性が欠けているアーキテクチャであるという課題認識が高まり、SDNはその課題を解決できる新しいアーキテクチャとして捉えられているからである。

現在、多くの標準化団体やベンダーによりSDNの標準化作業が進められており、具体的な製品も続々と投入されている。このように注目度が高いSDNだが、現時点では話題先行の観もあり、個々の要素技術が注目を集める一方で、その本来の目的が見失われがちである。

そこで本連載では、これまでとは異なる観点からSDNを考察することで、本来の目的を再確認するとともに、SDNをビジネスに役立てるための実践的な情報を紹介していきたい。

SDNというと、真っ先に「OpenFlow」「ネットワーク仮想化」「VXLAN」「APIの仕様」といった個々の要素技術にどうしても目がいきがちだが、その前に確認しておくべきことがある。「そもそもネットワークは何のために存在するのか？」この再確認から始めることで、個々の要素技術やベンダーから発信されるさまざまなうたい文句に惑わされることなくSDNを捉えることができる。

ネットワークは何のために存在し、なぜSDNは生まれたのか？

ネットワークは何のために存在するのか？ユーザーは何をしたくてITを利用するのか？―――この問いに対する最もシンプルな答えは「アプリケーションを利用してビジネスに活用するため」だ。ユーザーは決してネットワークそのものや最新のSDN対応機器、サーバ仮想化技術やストレージ製品を使いたいわけではない。アプリケーションを通じてITサービスを利用したいだけである。つまり、ITを構成する個々の要素技術は最終的にはすべてアプリケーションを稼働するために存在している。この点を、まずは再確認しておきたい。

図1 アプリケーションとインフラ調達スタイルの変化

その上で、近年のアプリケーションとインフラの調達スタイルの変化を俯瞰してみよう。かつてアプリケーションとは、業務要件に合わせてビジネスロジックをプログラムでコーディングし、数年かけて開発するのが主流だった。それに歩調を合わせる形でアプリケーションを動かすためのインフラ(サーバ、ストレージ、ネットワーク)を、アプリケーションのサービスレベルを満たす条件下で「リリースの都度、個別にハードウェアを調達する」という方法が一般的だった。

ところが、ここ数年の間で仮想化技術やクラウドサービスの利用が急速に広がるにつれ、アプリケーションとインフラの調達スタイルには大きな変化が起きている。アプリケーションの開発・運用は「DevOps」というムーブメントが生まれ、スピードが劇的に早くなりつつある。また、各企業の業務に差異が少ないSFA、メール/スケジュール、経費精算などのアプリケーションは開発することなく、SaaSから直接調達するスタイルに変わった。インフラではサーバ仮想化技術が普及することで、「リリースの都度、個別にハードウェアを調達する」のではなく、すでにリソースプール化（ハードウェアが仮想化技術によりいつでも利用可能な状態）されており、「リリースの都度、リソースプールから必要な分だけ切り出して調達する」となり、アプリケーションに必要なインフラを迅速かつ柔軟に提供するというスタイルが主流になった。

このアプリケーションとインフラの調達スタイルの変化は、特にネットワーク管理担当者にとって、これまでにない未知の事態と課題が生まれた。アプリケーションのリリースや変更によって生ずる機能や性能要件に、ネットワークの構築/運用/管理が追い付けずボトルネックとなり、問題視され始めたのだ。かつてはネットワークを時間をかけて安定的に構築/運用していれば、業務アプリケーションを快適に利用できる環境を提供できた。しかし、これからはアプリケーションの要件にレスポンス良く対応できるネットワークを提供できなければビジネス上のボトルネックであるという烙印が押されてしまうのだ。

しかもユーザーからしてみれば、アプリケーションがオンプレミス上であろうが、パブリッククラウド上にあろうが、そんなことはまったく関係ない。とにかくアプリケーションが安定的に快適に利用できればそれでいいのだ。一方で、ネットワーク管理者の視点からすると、オンプレミス、パブリッククラウド、ハイブリッドクラウドという多様なネットワーク環境の管理となると、人手がいくらあっても「リリースの都度、個別にハードを調達する」という従来型の調達スタイルでは破綻してしまう。

そこで、ネットワークインフラはアプリケーションの要件に合わせて個別にハードウェアを調達して作るという従来の発想から、アプリケーションの迅速な開発/運用の要件を事前に見越して、仮想化や自動化技術をネットワークに適用する事でリソースプール化し、アプリケーションをリリースするタイミングで、迅速かつ柔軟にネットワークを切り出して提供するという発想の転換が迫られている。

改めて、全体像からネットワーク管理者に求められる状況を整理してみよう。ビジネス戦略に応じてアプリケーションを調達/稼働させるプライベート/パブリック/ハイブリッドクラウドを選択、その要件に呼応する形でインフラを迅速かつ柔軟に調達という一連のプロセスにおいて、ネットワーク管理者には以前よりもアプリケーションそのものに意識を向け、一連のプロセスにネットワークがシームレスに組み込まれるための仕組み作りが求められている。それを実現するためには、ソフトウェアを通じてネットワークを定義するという発想が合理的であり、SDNはまさにこうした要請から生まれたものなのだ。

今回はSDNが必要とされるようになった背景や課題と、それを解決するためのSDNの大まかなコンセプトについて解説した。読者の中には今回の内容だけでは具体的なイメージがなかなか掴めないという方もいるかもしれない。そこで次回からは、SDNの具体的なソリューション内容について踏み込んで紹介していこう。