仮想化されたネットワーク機能の動的制御に関する研究
クラウドコンピューティングはインターネットを通じてサーバ等の計算資源を供給することで「必要な時に」「必要な量だけ」リソースを利用可能とした。 この結果、アプリケーションの開発に先立ってサーバを確保する手間が省かれ、多くのネットワークを利用したアプリケーションが世に出回るようになった。 これに伴い、計算資源ごとに異なるネットワーク機能を利用したいという要求も誕生した。
しかしネットワーク機能の提供には要求ごとにネットワークを構築する必要があり、サーバ技術と比較して柔軟性に乏しいという課題がある。 本研究はネットワーク機能の柔軟な利用という側面に焦点を当て、計算資源ごとに要求に応じたネットワーク機能を提供するための機構の設計と実装を行う。 本研究によって、ユーザはクラウド環境下においてDPIやファイアウォール等のネットワーク機能を選択して利用できるようになる。
インターネットの今日の進歩の背景にクラウドコンピューティングある。クラウドコンピューティングでは計算サーバやインターネットを利用したアプリケーションに必要となる資源をインターネット上で供給することを通じて、専用のサーバを持たずとも「必要なときに」「必要な量だけ」サーバリソースを利用することを可能にした。この結果、アプリケーションの開発に先立ってサーバリソースを確保する手間が省かれるようになり、多くのネットワークを利用したアプリケーションが世に出回るようになった。 このように、仮想化技術の進展は、計算資源の利用形態をアプリケーションごとに都度ハードウェアを用意するという形から、ハイパーバイザが保有するリソースプールからその用途に必要な分だけ資源を提供するものへ変化させた。その一方、近年のサイバーセキュリティに対する関心の増加やサービスの差別化・複雑化を背景として、計算資源ごとにネットワーク機能を定義したいという要求が生じてきた。例えば特定のサービスについてはファイアウォールとDPI(DeepPacketInspection)を適用したいが、他のサービスについてはDPIを除外したいといった要望がそれに該当する。 こうした要求に応えるためにはネットワーク運用担当者が個別にネットワークの設定を変更し、ユーザが指定したネットワーク機能を経由するようにネットワーク構成を変更することが必要となる。しかし、計算資源ごとにオペレーターが手動で設定を行うことはシステムのダウンタイムを発生させるだけでなく、アプリケーションの設置から公開までの過程におけるボトルネックとなり、迅速なサービス展開の妨げとなる。また、複数のユーザを同一システム上にホスティングするマルチテナント方式のデータセンタなど、ネットワーク構成が複雑な環境である場合、ネットワークの構成変更に必要となる時間や費用が規模に比例して増加するという問題もある。
クラウド環境におけるネットワークの柔軟性を向上させるためには、仮想的にネットワーク機能を提供するだけでなく、提供されたネットワーク機能を適切な順序で制御するための手法やアーキテクチャが必要とされている。そこで、本研究ではクラウド環境下におけるネットワーク機能の柔軟な利用という側面に焦点を当て、アプリケーションごとに要求に応じたネットワーク機能を提供する機構の提案と実装を行う。特に、今後アプリケーションがコンテナ型仮想化技術を用いて提供されることを想定し、コンテナごとにサービスチェイニングを実現するための機構の開発を目的とする。コンテナとしてネットワーク機能を動作させることで、ユーザは仮想マシンよりも少ないオーバーヘッドでネットワーク機能を利用することができる。また、事業者にとってのメリットとして、コンテナごとにサービスチェイニングを設定することで、ユーザごとに柔軟なトラフィックの制御が可能となり、異なる機能要件を同時に満たすことが可能となることが挙げられる。
本研究ではサービスチェイニングに利用するVNF(VirtualNetworkFunction)の実装およびサービスチェイニングを実現するための機構の設計と実装を行う。VNFとは、これまでは専用のハードウェアで提供されていたネットワーク機能をNFVI(NetworkFunctionVirtualizationInfrastructure)と呼ばれる仮想ネットワーク基盤上で動作するように、ファイアウォールやDPIなどの機能をソフトウェアとして実装する手法のことである。評価として、接続するアプリケーションコンテナ数と連鎖させるネットワーク機能を提供するコンテナを増加させたときのシステムパフォーマンスの計測を行う。
実験では仮想マシン上に図1に示すトポロジとなる仮想的なネットワークを構築し、検証を行った。
図1 検証に用いたネットワークのトポロジ
図2 最短経路に基づくパケット転送
図3 Segment Routingを用いたパケット転送の検証結果。青線がPolicy 1を示しており、赤線がPolicy 2 を示している。
このとき、現在の Linux Kernel における IPv6 Segment Routing の実装上の問題で、Policy 1 と Policy 2 を同時に適用、すなわち、Host3に対するルールが一つしか適用できないことがわかった。
本研究では1つの宛先およびエンドノードに対して、実際にサービスチェイニングをすることができた。しかし、実装の過程において現在のLinuxにおけるIPv6SegmentRoutingの実装では、同じ宛先に対してルールが1つ以上適用できないという問題が発覚した。今後はこれに付随する問題の解決を行う。
本研究における対外発表の成果は次のとおりである。