インフラ構成図ビルダーのイメージ

あの日の「えっ」という絶望感

「このAPIサーバー、もう1台RabbitMQ挟んでませんでしたっけ？」

ある日のミーティング中、後輩から指摘されたときの血の気が引く感覚、エンジニアの皆さんなら分かってくれるのではないでしょうか。
慌てて社内Wikiを確認すると、そこにポツンと貼られていたインフラ構成図の画像ファイル。その更新日時は、なんと半年前でした。

インフラ構成って、一度決めても日々の開発でちょっとずつ変わっていくんですよね。「負荷高いからRedis追加しようぜ」とか「IP制限の都合でリバースプロキシ置こう」とか。
でも、そのたびに重いGUIツールを立ち上げて、四角いアイコンをズラして、チマチマと矢印を引き直して、画像をエクスポートしてWikiにアップロードする……。正直、めんどくさすぎませんか？ 誰だって「あとで更新しよう（そして永遠にやらない）」って思っちゃいます。

「Diagram as Code」への憧れと挫折

この「一生更新されない構成図問題」をぶっ壊すには、やっぱりコードベースで図を管理する（Diagram as Code）しかない！と目をつけたのが Mermaid.js です。
テキストを書くだけでポンッと図が出てくるなんて、エンジニアにとっては夢のようなツールですよね。

ただ、いざ導入してみると、クラウドのアーキテクチャ図みたいな複雑なグラフ（AWSのVPCの中にEC2があって〜みたいなネスト）を書こうとすると、記号やインデントのルールが意外とややこしくて……。コードレビューを待ってから図の崩れに気づく、なんてこともザラにありました。

ブラウザで「書きながら見る」快適さを求めて

「もっとこう、テキストをカタカタ打ってる最中に、横の画面でリアルタイムに構成図がヌルヌル組み上がっていくプレビュー環境が欲しい！」

そんな僕のワガママから生まれたのが、この「インフラ構成図ビルダー」です。

一番こだわったのは「完全にローカルのブラウザだけで動かす」こと。企業の大事なインフラ構成という超機密情報を、どこの馬の骨ともわからない外部サーバー（つまり僕のサーバーです）に送信するなんて怖くてできないですよね。だから、入力データは一切ネットに送信されず、手元のPC内で完結して描画される設計にしました。

構成図のメンテが億劫になっている方は、ぜひこのツールで適当にカタカタやってみてください。「あっ、今インフラ作ってる！」っていう謎の万能感が味わえるはずです（笑）。

結局、続くのは「軽さ」だった

作ってみて改めて思ったのは、構成図が古くなる原因って、記法の難しさよりも「直すのが面倒」という心理的なハードルなんですよね。重いツールを立ち上げて、アイコンを並べ直して、エクスポートして……という儀式が1つでも挟まると、人は「あとでいいや」を選びます。

だからこのツールでは、とにかく「思いついた瞬間に開いて、5秒で直せる」ことを優先しました。ノード名は短く、線は主要な流れだけ、ノードが10個を超えたら役割ごとに図を分ける。これくらいのゆるさが、結局いちばん長続きします。完璧な1枚より、雑でも更新され続ける図のほうが、半年後の自分を救ってくれます。

よくある質問

Mermaidの記法を覚えないと使えませんか？

いいえ。ノードと接続をポチポチ足していくだけで、裏でMermaidのコードが生成されます。記法を知らなくても図ができあがり、出力されたコードをコピーすればそのままGitHubのREADMEにも貼れます。

入力したインフラ構成は外部に送信されませんか？

送信されません。描画はぜんぶ手元のブラウザの中で完結します。企業のインフラ構成という機密情報を外部サーバーに送るのが怖かったので、最初から「ネットに出さない」設計にしてあります。

作った図はGitHubのREADMEで表示されますか？

はい。MermaidのflowchartはGitHubがそのままレンダリングしてくれるので、画像ファイルではなくテキストで構成図を管理できます。インフラを変えたときの差分も、コードと同じようにPullリクエストで追えます。

ノードが多い大きな構成はどう描けばいいですか？

1枚に全部詰め込まず、役割ごと（ネットワーク／アプリ／データ／監視）に図を分けるのがおすすめです。10ノードを超えたあたりが分割の目安。詰め込みすぎないほうが、結局あとからメンテしやすくなります。