← logs

コード化可能なネットワークトポロジー図を描くツールとしてDiagramsは適しているか検証してみた

2024年9月25日

Python の Diagrams でネットワークトポロジー図をコード化できるか、表現力と制約を検証した記録

tags: Python, Network, Documentation

ネットワークトポロジー図をコードで管理できると便利である。

構成変更に合わせて図を更新しやすくなり、レビューもしやすくなる。 手作業で図を直すより、テキストとして差分を見られる方が運用に向いている。

そこで、Pythonの Diagrams がネットワークトポロジー図に向いているかを試した。

結論から言うと、Diagramsはクラウドアーキテクチャ図には向いている。 一方で、ネットワークトポロジー図、特にinterface名、IPアドレス、L2/L3の細かい表現が必要な図には向きにくい。

やりたかったこと

やりたかったことは、ネットワーク構成図をコードで表現することである。

具体的には、次のような図を想定していた。

router
  |
switch
  |
firewall

単にアイコンを並べるだけではなく、以下も表現したかった。

interface名
IPアドレス
VLAN
接続方向
L2 / L3 の境界
機器間の物理的なつながり

この条件で、Diagramsが実用的かを見た。

Diagramsとは何か

Diagramsは、Pythonコードでインフラ構成図を描くためのライブラリである。

AWS、GCP、Azureなどのクラウドサービスのアイコンが用意されており、クラウドアーキテクチャ図を素早く描ける。

たとえば、次のように書ける。

from diagrams import Diagram
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB

with Diagram("Web Service", show=False):
    ELB("lb") >> EC2("web") >> RDS("userdb")

コードとしてはかなり読みやすい。

ELB -> EC2 -> RDS のようなサービス間の関係を表すには向いている。

ネットワーク機器でも試した

Diagramsにはgenericなnetwork iconもある。

Router、Switch、Firewallを使うと、簡単なネットワーク図は書ける。

from diagrams import Diagram
from diagrams.generic.network import Router, Switch, Firewall

with Diagram("Generic Network Topology", show=False):
    router = Router("Router\n192.168.1.1")
    switch = Switch("Switch\n192.168.1.2")
    firewall = Firewall("Firewall\n192.168.1.254")

    router - switch - firewall

シンプルな構成であれば、これでも十分に見える。

ただし、ネットワークトポロジー図として使おうとすると、すぐに制約が見えた。

評価軸

今回見た評価軸は以下である。

1. 機器の関係をコードで表現できるか
2. IPアドレスやinterface名を見やすく出せるか
3. L2 / L3 の境界を表現できるか
4. 物理配線に近い配置を制御できるか
5. 差分管理しやすいか
6. 図として読みやすいか

Diagramsは、1と5はかなり良い。 コードで構成を書けるため、図の変更をGitで管理できる。

一方で、2、3、4は厳しい。

良かったところ

良かったところは、コードが短く、構造が分かりやすい点である。

router >> switch

このように書くだけで、機器間の関係を表現できる。

クラウドサービス間の依存関係や、大まかなアーキテクチャを描くならかなり便利である。

また、Pythonで書けるため、既存の構成情報から図を生成する方向にも発展させやすい。

厳しかったところ

厳しかったのは、ネットワーク図に必要な細かい情報の配置である。

ネットワークトポロジー図では、単に機器がつながっていることだけでなく、以下が重要になる。

Gi0/1
eth0
192.168.1.1/24
VLAN 10
trunk / access
L2 segment
routing boundary

Diagramsでもラベルに文字を入れることはできる。 しかし、interfaceごとのラベルを線の近くにきれいに置く、IPアドレスを左右に分けて出す、物理図に近い配置を細かく制御する、といった用途には向きにくい。

また、Graphvizベースの自動配置に任せる部分が多いため、ネットワーク図として「この線をこの位置に置きたい」という調整がやりにくい。

向いている図

Diagramsが向いているのは、次のような図である。

クラウドアーキテクチャ図
サービス間依存関係
大まかなシステム構成
イベント処理の流れ
コンポーネント間の関係

たとえば、Web frontend、backend、DB、queue、storageのような構成を表すなら使いやすい。

アイコンの種類も多く、サービス名で認識しやすい図を作れる。

向きにくい図

逆に、次のような図には向きにくい。

物理ネットワーク構成図
詳細なL2/L3トポロジー
interface名を線ごとに書く図
IPアドレスやVLANを厳密に見せる図
ケーブル接続の位置関係が重要な図

ネットワークトラブルシューティングで使う図は、細かい情報の位置が意味を持つ。

その用途では、Diagramsの抽象度は少し高すぎる。

代替候補

代替として考えたものは以下である。

Graphviz:
  DOTで書ける
  自動配置は強い
  細かい見た目の調整には慣れが必要

PlantUML:
  テキストから図を生成できる
  UML以外にも使える
  ネットワーク図としての自由度は確認が必要

Cytoscape.js:
  JavaScriptでグラフを扱える
  Web上でインタラクティブに見せる用途に向く
  静的な記事用の図としては少し大きい

ネットワークトポロジー図をコード化したいだけなら、GraphvizやPlantUMLの方が合う可能性がある。

Web UIとして操作したいなら、Cytoscape.jsも候補になる。

結論

Diagramsは、ネットワークトポロジー図を描くための第一候補ではない。

クラウドアーキテクチャ図や、コンポーネント間の大まかな関係を表す図には向いている。

しかし、interface名、IPアドレス、VLAN、L2/L3境界、物理配線に近い配置を表現したい場合は、制約が大きい。

今回の判断はこうである。

クラウド構成図:
  Diagrams は使いやすい

大まかなネットワーク図:
  Diagrams でも書ける

詳細なネットワークトポロジー図:
  Diagrams は適していない

ネットワーク図をコードで管理したい場合は、Diagramsだけでなく、Graphviz、PlantUML、Cytoscape.jsも含めて比較する方がよい。

参考

関連ログ