3秒でわかる
サーバーや DB、外部サービスといった構成要素と、その間の通信経路を描いた図。設計時の認識合わせと、障害が起きたときの原因の切り分けに使う。
もう少し詳しく
どういうものか
システムを構成する要素と、その間をどうデータが流れるかを描いた図です。利用者のブラウザ、ロードバランサー、アプリケーションサーバー、データベース、外部 API、といった箱を並べ、通信の向きを矢印でつなぎます。
似た図に、クラスやモジュールの関係を描くソフトウェア寄りの構成図もありますが、ここで言う構成図は主に「どこで動いているか」を示すものです。どのサーバーに何が乗っていて、どの経路で外に出ていくかが読み取れる粒度で描きます。
なぜ必要か
関係者の頭の中の絵をそろえるためです。同じ「API」という言葉でも、自社で動かすサーバーを指す人と、外部サービスを指す人がいます。図にすると認識のずれがその場で見つかります。
障害対応では切り分けの地図になります。応答が返らないとき、疑う場所はブラウザからロードバランサーまでの間か、アプリと DB の間か、外部 API との通信か。経路が描いてあれば順番にログを見ていけますが、無ければ勘で探すことになります。
新しく入った人への説明にも効きます。コードを読ませる前にこの図を一枚見せるだけで、リポジトリのどのディレクトリがどの箱に対応するのかを結び付けられます。
具体例
Mermaid で書けば、テキストのままリポジトリに置いて差分も追えます。
利用者のブラウザ
|
CDN
|
ロードバランサー
|
+--+--+
| |
アプリ1 アプリ2
| |
+--+--+
|
+--+----------+-------------+
| | |
データベース キャッシュ 外部決済 API矢印には何が流れるのかを添えると、読み手が推測しなくて済みます。
利用者のブラウザ
|
CDN
|
ロードバランサー
|
+--+--+
| |
アプリ1 アプリ2
| |
+--+--+
|
+--+----------+-------------+
| | |
データベース キャッシュ 外部決済 APIつまずきやすいところ
似た用語との違い
| 図 | 描くもの |
|---|---|
| システム構成図 | サーバーやサービスの配置と通信経路 |
| ER 図 | テーブルと、テーブル同士の関連 |
| シーケンス図 | 処理が時間の順にどうやり取りされるか |
構成図が地図だとすれば、シーケンス図はその地図の上を通る道順の記録にあたります。
