理解しやすいネットワーク設計図を描く取り組み
ネットワーク構成をよりよく理解するために、「ネットワーク設計図をプログラムで描く」という取り組みをはじめました。少し前の IEICE ICM研究会 で発表を行う予定でしたが、残念ながら新型コロナウィルス拡大により、研究会が中止になりました。
せっかくなので概要をまとめておこうと思います。
取り組んでいる課題
ネットワーク設計図は「ネットワークがどうあるべきか」を視覚的に理解しやすくするためのものです。記載される内容は
- 装置・回線の地理的位置・ネットワーク上の論理的位置・種別
- レイヤーごとの接続関係
- 動作する技術・プロトコル・パラメーター・そのふるまい
などなど多岐にわたります。正しいネットワーク設計図は理解の助けになる反面、それを正しい状態に維持することはコストがかかる作業です。そこで コストを抑えるために、記述を省略するなど 正しさを犠牲にしたりします。
たとえば、次の図を見てください。
架空のネットワークの「IS-IS 隣接関係・メトリック」「BGP 経路集約」を表現した図です。当然ながら、それぞれの図は表現したいポイントにフォーカスし、それぞれの図の中できれいに表現できるようレイアウトします。一見言いたいことは伝わるかもしれませんが、
など、2つの図を見比べた上で「全体としてネットワークがどのようにふるまうか」を考えるときに理解しやすいとは言えません。しかしながら、両者の関連を明示するのは大変困難です。原因はいくつかあります。
原因1. 図が量産される
複雑なネットワーク設計を表現するにあたり、あらゆる情報を1枚のネットワーク図で表現することはできません。当然ながらフォーカスするポイントが違うネットワーク図が量産されます。キャリアクラスのネットワークになれば、設計書に掲載されるネットワーク図は100を超えてきますが、100枚の図すべてに全ルーターを記載するわけにいきません。そもそも紙面が限られていますし、ひとつの修正 (例: HK から撤退したので、消して回らなければならない) に対するコストが高くなるためです。
実際にはネットワーク上の特定の位置・レイヤー・プロトコルだけに注目し、それ以外を省略することが多いですが、他の図との関連を把握しにくくなってしまうトレードオフがあります。どのようなバランスで表現するかは、多くの場合 書き手の判断で決めていると思われます。
原因2. 組織的な課題
ネットワーク規模が大きくなるにつれ、組織も大きくなります。ひとつのチームでは設計・構築・運用できないため、ネットワークレイヤー別に分けたり、サービス毎に分けたりします。大規模事業者になれば、ポリシー設計・リソース管理・工事を別々の組織が担当することも普通です。「あるポートにIPアドレスを設定する」という例でいえば
- IPアドレスの採番ルールを決めるチーム
- 1 のルールにしたがって、アドレスを採番するチーム
- 2 のアドレスを設定するチーム
に分かれているイメージです。組織横断でネットワーク設計図を維持する場面が増えるほど、書き手は他の図との関連を意識しにくくなりがちです。
研究内容
上記の課題を解決するには、ネットワーク図を人が描くのではなく、プログラムによって描画する必要があると考えています。
- 注目するポイントが違う個々のネットワーク図、および全体像を低コストで描けること
- 注目するポイントに関連する情報を、選択的に表示できること
をWebブラウザ上で実現するプロトタイプを実装、実環境におけるネットワーク設計書に適用して評価しました。
たとえば先ほどの経路集約の例でいえば、
- ベースとなるネットワーク図を自動描画できる
- ネットワーク図の一部を非表示にしたり、ノード配置を修正できる
- ベースとなるネットワーク図に、経路ごとの集約・被集約をマッピングできる。表示する対象を切り替えられる
- 関連情報を表示できる。表示・非表示を切り替えられる
1~2 の結果をリセットすることなく、3~4 を行います。
本研究はソフトバンク株式会社との共同研究です。
実現方法
データソースとなる設計データは、構成管理データベース (CMDB) に格納されているものを流用します。ただし、
- 設計要旨を表現するのに十分な範囲、今回は地理的に限定された2 エリアのみを描画
- 2 エリア内の設計情報は全て描画し、さらに何かを省略することはしない
- 基本設計から逸脱するイレギュラーを手動で取り除き、「ネットワークがどうあるべきか」をJSON で表現する
設計データには「ルーターAとルーターBが100GEインターフェイスで繋がっている」レベルの接続情報を持ちますが、自動描画するための座標などは含まれていません。そこで、ネットワーク図を描画するための inet-henge というライブラリを利用します。
このライブラリは、前述のような「AとBが繋がっている」レベルの構成情報から自動レイアウトでネットワーク図を描画します。出力形式は SVG であり、CSS や JavaScript によって、ユーザープログラムからノードやリンクのメタデータを表示・操作するための工夫がされています。
今回、このライブラリを使ってSVG 操作するプログラムを JavaScript および CSS で実装し、実際の設計書と同等のネットワーク設計図を描画しました。その後、オリジナルである MS PowerPoint 版と比較・評価しました。
効果
詳細は省略しますが、今回の題材において、先に述べた「ネットワーク設計図の維持コスト」「他の図と関連させて表現させるためのトレードオフ」の課題は大幅に改善されています。ネットワーク図の自動描画によって、設計変更 → ドキュメント内のネットワーク図変更であった作業が、設計変更 → CMDB・プログラム修正 で代用可能です。ネットワーク図の体裁が俗人化してしまうという課題も改善しています。
しかしながら 変更のあった設計項目によっては、CMDB上でのデータ作成・プログラム修正コストが必ずしも小さくなく、全体として低負荷にならない場合がありそうです。
まとめ
最後に、技術報告のまとめを引用します。
本稿では，OSSライブラリのinet-hengeを用いてデータからNW構成図を自動作成し，個々の設計要旨とNWの全体像を同時に表現することで，よりわかりやすいNW構成図を低負荷で作成する方式を検討した．図を作成する過程には課題が残っているが，できたNW構成図は従来の図より利点が多く有望な方式と考える．今後は，4.2.で述べた改善と，適用範囲を設計書だけでなく詳細設計や構築済みNWに拡大した検証を行う予定である．
