「ネットワークのテスト」は何が難しいのか? (3)

どうやって状態を変化させるか・どのように状態が変化するか

ステートフル/ステートレス

通常、ネットワークには状態(State)があります。「通常」と書いたのは、ステートレスにする組み方も可能ではある、ということですが…。ある程度の規模がある・冗長性のあるネットワークは普通、ステートフルになっていると思います。

というのは、ネットワークの冗長性を実現する多くのプロトコルがステートフルだという点です。VRRP, OSPF, BGP,... どれもステートフルですね。まあ、機器間ネゴシエーションやタイマ動作があるようなプロトコルはステートフルですよね。あともちろん、クラスタ化して動作するNW機器(active-active/active-standbyとか)なんかもステートフルな動作をしますね。

こういう、個々の機器*1プロトコルの持つ状態それぞれを組み合わせたものが、「ネットワーク(全体)の状態」として扱う情報になります。ステートフルなネットワークでは、あるイベント…たとえばルータのポート障害の発生とそれに伴う経路再計算の動作など…に応じて、どのように次の状態に変化するかは、その時々のネットワークの状態に応じて変化します。

ステートフルなもの・状態遷移のあるものをテストしようとするとどうするか。まず初期状態から一定のイベントを発生させて、そのイベントごとの状態変化と、イベントに応じて「テストしたいもの」= その中を流れる通信状況がどのように変わるか、というのを見ていくことになります。なので、テストは一定の手順(シーケンス)で定義されることになります。

状態変化トリガ

で、テストとしてみるべき「イベント」とは何か。まずは障害試験ですよね。リンクの故障、切断、あるいはデバイスそのものの停止。そういうのをどうやって発生させるか? 実際にケーブルを抜くとか、機材の電源を落とすとか、そういうオペレーションになるわけです。これをネットワーク経由でやりますか? リモート操作でケーブル抜いたり刺したりできないし*2、電源操作は…頑張ればできるでしょうけど、電源切った後どうやって復帰させるとかそういうのがありますよね。復帰させられたとして、「ネットワーク自体が停止するかもしれない」状況に追い込んで、どういう動作をするかを見るわけで、その上での通信保証はないわけです(それをテストする段階なので)。

などなど。こういう操作って他にもいろいろあって、NW機器のOS更新(再起動を伴う)、環境の拡張・縮小(新しくNW機器を追加する・古い機器を止めたり撤去したりする)なんかもそうですね。物理的なケーブル操作とかは現状、手作業に頼らざるを得ないし、機材の操作や情報取得(状態把握)を遠隔でやるなら、テスト対象のネットワークと独立した、NW機器操作用の接続経路とかをちゃんと考えないといけないわけです*3

検証環境でひとつのフロアに模擬環境を組んでやれるのであればまだいいんですよね。これが、遠隔地をつなぐ本番環境ネットワークだと、たとえば東京・九州で構築したシステムだとして、九州で行う環境拡張作業とかその通信テストとか、どうする? というのを考えないといけなくなる。出張しますか? 現地で人を調達できますか? 作業する人用に作業手順書、構築後のテスト手順書書きましたか?

用意できるリソース

これまで書いたようなあれこれを踏まえると、そこそこサイズがあるネットワークとか、複数の場所に移動して作業しなきゃいけないネットワークとかだと、そもそもの作業コストがそれなりにかかるというのはなんとなくわかってもらえる…かな……。本番作業は時間も人手もかかるし、いきなりブッツケ本番作業でいけるっていえるような複雑度じゃなくなっていく。ミスったときの時間的・コスト的リスクがあるので、事前にやった設計で問題なくいけそうかどうかテストするための環境(検証環境)とかを作るし、そこで現地で作業を行う人とか作業用の端末とかを想定してテスト用のリソースを用意したりしますよね。

とはいえ、用意できるリソースにもやっぱり限界があるので、本番環境と同等のものをいつでも全部作れるわけじゃないです。隣接するNW機器や全体の経路の組み合わせを実現させたい、機材の数やサイズの追加・削除とかのオペレーションが可能になるようにしたい……とか、ある程度フォーカスするところとあきらめるところ考えないといけない。機材の数、本番同等の型番機材とOSバージョンの組み合わせ、それらのライセンス費用、保守費用、作業用の端末、作業スケジュールや作業者の人数などなど。準備可能な規模で、どうやってテストしたいことを実現させるか、というのを考えて検証組むわけです。

おわりに

こんな疲れる話を最後まで見る人がどれくらいいるんだろうか?

このシリーズはちょっとした業務上の鬱憤を動機に、業務時間外で作成されました。正直、自分で書いていて疲れました。ちゃんと説明しようと思えば思うほどあさっての方向に転がっていきそうになってしまう。これでもそれなりに話を束ねようとしたんだけど、まだあれが足りてねえとか、イヤそうじゃねえだろとか、いろいろあるでしょうけど、書いていく気力がなくなってきたのでいったんこれで終わりにします…。

まあ何か思うところがありましたらコメントをください。(・ω・)ノシ

*1:TCP自体もステートフルなプロトコルなので、ファイアウォールやロードバランサなどL4の機器はステートフルな動作になります。「情報システムのテスト」の観点ではそうした話も加味した上でテストパターン考えたりします……が、ややこしくなるので今回の話からカットしてます。

*2:電子的に制御できるパッチパネル機材みたいなのを使ってれば別だけどね。

*3:観測側が観測対象から独立していて、観測対象の変化に影響を受けないこと、というのが保証できないと、取得した情報を信頼できない。