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

とはいえ残る課題も

　ここまで、物理ネットワーク運用改善の手法を紹介してきましたが、現時点ではこうした手法にも多くの課題が存在します。

　例えば、「本番で利用されている機器が高価な機材になるほど、テストのための機器を確保するのが難しくなる」「実機を織り交ぜて繰り返しテストを行う場合、初期化の際に考慮すべきことが仮想化インフラと比べて多い」「運用担当者がプログラミングに興味があるとは限らない」といった点です。以下でそれぞれについて解説し、将来的な解決策を考えます。

テスト機器の確保の問題

　高価なテスト用機器の確保に関しては、グレードを下げた機器や、仮想アプライアンスを使って対応することになります。これについては、前回述べたNFVが解決策の1つとなり得ます。今後仮想アプライアンスとしてNFVが発展してくる可能性があり、（もちろん実機と異なる動作をするリスクはあるものの）今回話題にしたような機能テストにおいては、有力な選択肢となるでしょう。

　ただし今のところは、部分部分、例えば「ファイアウォールのポリシー確認だけに絞って実機を調達し、残りは仮想化環境を利用する」といったように用途を絞って実機を利用する方法などが現実的でしょう。

実機を含む自動試験をする場合の初期化の問題

　実機を織り交ぜて自動試験をする場合、仮想化環境であれば簡単に作成・削除ができますが、物理機器に関してはそうはいかない点が課題となります。例えば、「ARPのキャッシュが残ってしまうことによって連続した疎通試験が通らなくなってしまう」などのケースが出てきます。

　これに関しては、ソフトウェア開発のテストで一般的に用いられるTeardown（テストセットが終わる度に呼び出される終了処理）機構を設け、機種ごとに独立した「状態クリアのコマンド群」を流して対処するなどの解決策が考えられます。機器への設定投入同様、各コミュニティーなどによってTeardown処理が部品として蓄積されれば、問題の解決が進むでしょう。

運用担当者のプログラムへの興味の問題

　そして最後の難題は「運用担当者がプログラミングに興味があるとは限らない」という点です。これについては技術者のマインドセット自体の変化も必要なのかもしれませんが、「ソフトウェア開発者と連携する」という選択肢もあります。例えば、「テストケースはどのようであるべきか」「どのように書けばよいのか」といったノウハウをソフトウェア開発者と共有するのです。

　できればネットワーク運用の担当者がコードを理解し、書くことができる方が望ましいのはもちろんですが、ネットワーク運用担当者の目的はコードを書くことではなく、いかに楽に、迅速に、高品質なネットワーク運用を実現するかということですから、仮にコーディングが苦手なのであれば、そこをソフトウェア開発者がカバーする形があってもよいでしょう。

　ここでは深く触れませんが、運用においてソフトウェア開発手法を採用することや、今までドキュメントで分断されていた運用と開発の垣根を越えた協調は、DevOpsの1つの側面といえます。

ぜひ新しい手法へのチャレンジを

　本連載では、物理ネットワーク運用の課題を、SDNを活用して解決する方法について考えてきました。

　今回紹介したSDNをテストに利用する方法は、本番環境に影響を及ぼさないため、SDNを突然本番環境に導入することに比べればハードルの高いものではありません。今すぐに全てのインフラを仮想化するのが難しい組織においても、現状の運用をより効率的にする上で有効な方法ではないでしょうか？

　新しい手法を取り入れるのは大きな壁に感じられるかもしれませんが、最初の一歩さえ踏み出すことができれば、「運用を自動化して楽をする」という具体的なイメージとスキルが身に付きます。そして、今まで人海戦術に当てられていた時間を自分たちのために使うことができるようになり、そのまま技術者自身にとってのメリットにもなります。ぜひ、第一歩を踏み出してみてください。

　本連載で紹介した技術が、今後物理ネットワーク運用現場の救いになれば幸いです。