「ネットワークのテスト」は何が難しいのか? (2)
組み合わせ
テストの単位
ネットワークの「単体試験」っていったら何をイメージしますか?
明確にコレが「ネットワークの単体試験」だというのはないんですけど、ひとつの考え方としては、ルータとか、スイッチとか、ファイアウォールとか、ひとつのデバイスに対して、使いたい機能(設定)や要求性能を満たし、想定通り動くかどうか確認する、というのがあるでしょう。
さて。「ひとつのデバイス」に対する通信のテスト。
通信って、コミュニケーションなので、1台だけだと会話にならない。必ずデータをやりとりするノード 2個は必要なんですよね。
ひとつは、テスト対象のNW機器を経由して実際に通信するもの。テスト対象の機器に2台ノード(以上)つないで通信することで、NW機器の機能の、何をどこまでテストをできるか、というのがまずある。あとは? ネットワークって普通たくさんのノードがいるので、そういう環境でちゃんと通信できるかどうかを見たいとしたら? 何十台何百台分のノードを用意する……のは限界があるので、たくさんのノードが生成するであろうトラフィックを生成する専用ツールとかを使ったりするわけです。それでも実際に現実世界で流れるトラフィックは、いろんな人のその時々の要求によって流れる量とか流れるデータの種類が変わるわけで、完全に想定される状況を模擬することはできないんですよね。
あともうひとつ。NW機器は、「どういう風にデータを中継すれば良いか」というデータ転送のための制御情報を相互にやりとりしてたりします。NW機器それぞれが、自分が持っているネットワークの情報を他のNW機器と交換して、ネットワーク全体でどうやってデータを中継・転送すれば良いかを決める。
こういうネットワーク機器の機能(動作)をテストしようとしたときにどうするか。NW機器同士がちゃんと制御情報をやりとりできているかをどうやって見る? 制御情報のやりとり・応答を代行するためのテスト用のツールを使う? 実際、そういうプロトコルの適合性試験(conformance test)をやるツールもあったりします。ただ、NW機器のテストなので、制御信号をやりとりした結果、必要なデータ中継がちゃんと行われているのかをどうやって見るのか、というのもあるんだよね。制御信号を交換して、その上でのデータ転送とかの話までみようとすると…。
結局、ネットワーク全体が設計(想定)したとおりに制御情報を交換して通信サービスを実現してくれるかテストしようとすると、実際使う機材を持ってきて、同じ構成の検証環境作る、あるいは実際に組んでみた本番環境用ネットワークが設計あるいは検証環境でためしたとおりに動くかどうかを確認する、という話になっていく。「単体試験」って、どこからどこまででしょう?
隣接機器間の整合性・経路の組み合わせ
関連して。
TCP/IPなネットワークでの通信(情報伝達)はバケツリレーで例えられますが、これはつまり、隣り合ってるNW機器間でデータの受けわたしをしていくわけです。当然、局所的には2者(2台)でのコミュニケーションというのがある。よって、隣接しているノード同士で、データの交換ができるように、お互いがどうやって情報を交換するかという決めごとの整合性がとれていなければいけない。そしてそれが、通信したいノード、end-to-end の経路全体で成立していかなければいけないわけです。
ということで、あるひとつの経路、あるひとつの隣接関係で整合性がとれているからといって、他の所でも問題なく通信できるようになっているかどうかというのは別物なんですよね。相互接続性とか相互運用性とかいう言葉がありますが、違うベンダの機械で仕様上はつながるはずなんだけど実際やってみたら上手くいかないなんてトラブルもあったりするわけです。(機械そのものの作りだけでなく置かれる環境によるものも…たとえば物理メディアの信号強度あるいはノイズ状況とか、交換する制御情報の解釈の仕方が一部違うとか。いろんな原因が考えられる。)
たくさんあるNW機器、それらの隣接関係の中で、どこか不整合があると、そこをまたぐ通信はできない。本当にすべてのデバイス、環境全体の隣接関係すべてで問題なく通信ができるかどうかを確認しようと思ったら、考え得るすべての経路、隣接関係を通るようテストを組まないといけない。
じゃあ、そういう end-to-end で取り得る経路の数ってどれくらいになるでしょう? 組み合わせ計算とかになっていくので、これは結構な数になるんだよね。なんでもかんでも機器間つなげても複雑化するだけなので、なるべくシンプルで全体の複雑さが押さえられつつ、かつ障害児にちゃんと切り替わることとか、将来的な拡張の余地があるように考えないといけない。だからネットワークトポロジ、ネットワークアーキテクチャみたいな話をみんないろいろ考えるわけです。
実際のテスト作業としても、人手だとそんなたくさんやれないわけです。なるべくシンプルになるようにネットワークトポロジ組むといっても全部の組み合わせを人力作業でやるのはたいてい無理なんですよね。なので、制御信号が交換されていて狙った状態になっているから大丈夫だよね、という形にしたり、一部の代表的なパターンでの通信状況だけテストして、そのほかの部分は設定ファイルの差分チェック(設定上のパターンチェック)とかで終わらせたりする。で、ちょっとした設定の抜け漏れとか、整合性のチェックとかが漏れて、トラブルにつながったりするんだけど……。
そして、複数の機器をまたぐ「経路」の組み合わせ、これを、冗長性とかを考えた上で考えていかないといけないんですね。たとえば機材の故障とか、障害が起きたときに通信全部落ちないように別な迂回経路切り替わるようにしておく。どういう障害に対してどういう経路で通信が通るか。こういうときにはこっちに廻るというパターンを出していって、その通りに経路の切り替え・切り戻しができるかどうかをチェックしておかないといけない……。
物理・論理構成のパターン
だんだん書いてて疲れてきた。
その上で仮想化技術を使ったりします。VLANとかVPNとかVRFとか。最近…この先だと Overlay Network とか? 物理的な構成と論理的な構成が必ずしも一致しなくなってきている。テストとしてパターン網羅したいネットワーク・インスタンスとして、どの物理環境を流れる通信なのか、という話と、どの論理環境の中での話なのか、というのの組み合わせが入ってくる。たとえば、あるセグメントの特定のノードだけなぜか通信できなくなった…というときに、特定のフロアの特定のスイッチのあるリンクでVLANの設定ミスってた、とか。
そういうのをどうやって検出しますか? というのを考えないといけない。物理的な配置・局所性と、その上での論理環境とのマッピングとかが見えてないと判断できない。あとで話を出すけど、どこに何が流れているかは「このときにネットワークがどういう状態だったか」という話が組み合わせに入ってきます。障害が起きて代替経路側を通るようになってる状態で…とかね…。
次
それぞれの機械が相互に接続・連携して通信(コミュニケーション)を実現してくれるというのは、たくさんの機器が、情報のやりとりのための「共通認識」をちゃんと持っているということなんだよね。で、使われてる共通認識がたくさんある。どれかひとつでもそこが食い違うと上手く通信できない。ということで、今回はその組み合わせに入ってくる要素でぱっと思いつくものについて挙げてみました。でも多分細かく挙げればまだある。が、きりがないのでまた次の話に行きましょう。一応つぎで最後。
