SDNで物理ネットワークのテストを楽にする方法：SDNで始めるネットワークの運用改善（2）（3/4 ページ）

機器への設定投入

　次に、機器への設定投入の自動化ですが、これについては既にさまざまなコミュニティーが盛んに取り組みを行っており、自動化の手段は豊富に存在します。

　現時点で浸透しているのは、本来人間が手動で入力するCLIに対して、expectコマンドなどによって対話を自動化して設定・情報取得を行う手法です。また、APIを前面に配置して機器の差異を抽象化するといった技術も見られます。最近ではAnsibleなどの構成管理ツールがさまざまな機種に対応してきましたので、そうしたツールを用いるのも1つでしょう。

図7　必要に応じたテスト対象機器への設定投入

テスト作業

　最後は、テスト作業の自動化です。ここまで述べてきたことが実現できれば、課題であった結線制御やテストノードの構築と起動、機器のつなぎ込みがソフトウェアで制御可能になり、物理機器を含んだ本番に近い構成の環境で、機能的な試験はある程度実施可能になります。

　しかし、テスト作業自体を手動で行うのではやはり手間が掛かりますので、ここも機械処理に頼りたいところです。そのためには前述した技術に加えて、自動的に通信を行ってくれるソフトウェアや、テストの結果が期待した通りになったかどうかを自動的に確認してくれるツールが必要になります。

　1つの手段としては、仮想サーバやコンテナといったテストノードの中から目的ノードへの通信を発生させるコマンドを実行し、実行結果の文字列で成功判定を行うようなシェルスクリプトを作成する方法があるでしょう。

　しかしそれよりも、せっかくプログラムでの制御を可能にしたのですから、既存のソフトウェア開発や仮想化インフラ運用に利用されているテストフレームワークなどを利用した方が効率は高まります。例えば、ソフトウェアの受け入れテストフレームワークである「Cucumber」や、インフラテストフレームワークである「Infrataster」「Serverspec」などがあります。これらはスクリプト言語であるRubyで作られており、Rubyから実行できることであれば何でも実施可能です。

この手法がもたらすメリット

　以上のようにすることで、物理ネットワークのテストを自動化することができます。ただし、ここまで挙げた手法を取り入れても、（コード化された）テストケースをメンテナンスするコストは当然残ります。ネットワークが変更される度にテストケースを追従させなければテストはすぐに動かなくなってしまいますから、目視による設定内容のチェックがなくなった代わりに、テストケースをレビューする必要が新たに生じます。

　これだけでは一見、「人手で設定内容をチェックするコストがテストケースの作成とレビューのコストに変わっただけ」という風に見えるかもしれません。しかしながら、目視確認はいくら繰り返しても作業が大幅に楽になることがないのに対し（熟練度は向上しますが）、テストケースはコードとして蓄積されていきますし、差分を取るのも機械処理の得意とするところです。つまり、テストケース作成は、初回こそつらいかもしれませんが、毎回設定内容を目視で確認するのに比べれば、結果的に掛かるコストに大きく差が出てきます。

図8　仮想テストノード間のEnd-to-End通信試験の制御

　こうした物理ネットワークテストの自動化に特化したテストフレームワークとして、「NetTester」というオープンソースソフトウェアの開発が始まっています。

　NetTesterは「OpenFlowによる仮想的な結線」「仮想テストノード構築とつなぎ込み」「仮想テストノード内でのテストアプリケーションの起動と結果確認」を自動的に行うことができるフレームワークで、現時点では物理ネットワークの機能的なテストを行うことができます。テスト実行部分のフレームワークとしては現在Cucumberに対応しており、ソフトウェアの受け入れテストを行うのと同様の手法で物理ネットワークのテストが実施できるようになっています。

　また、NetTesterの他にも、今までデータセンターの仮想ネットワーク基盤として開発されていたオープンソースの「OpenVNet」に、物理ネットワーク機器を仮想ネットワークにAPI経由で直接配置できる機能が追加され、「Terraform」や「Cloudify」といったオーケストレーションツールから物理ネットワークのテスト環境をオンデマンドで構築できるようになっています。