0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

前置き

前回の記事の続きです。

UMLの 配置図(Deployment Diagram) は、まさにその2つの目的のために使われる、非常に強力なモデルです。

1. 配置図 =「どこに何を置くか」の地図 🗺️

配置図は

「どのソフトウェア成果物(コンポーネント)を、どの物理的なノードに配置するか」

を考えるためのモデルです。

よく下図のような形で表現されることもあるし、AWSとかのアーキテクチャ図も、
おおよそ配置図と思っていただいて大丈夫です。

image.png

ソフトウェア成果物 (Artifact)

注文サービス.jarWebフロントエンド.warNginxコンテナ など、実際にデプロイされる「モノ」です。

ノード (Node)

これらが配置される「場所」です。

ノードは、物理サーバー、VM、Kubernetesクラスタ、あるいは 「ネットワークセグメント(例: DMZ, App-Zone)」 といった、物理的・論理的なリソースの単位を表します。

配置図を作ることで、「決済サービスは、セキュリティレベルが高いDataセグメントのサーバーに配置する」といった、アーキテクチャ上の物理的な決定を可視化できます。

この図を作ることで、

決済サービスは、セキュリティがより高いDataセグメントのサーバーに配置する」

といった、アーキテクチャ上の物理的な決定を可視化できます。

コンポーネント図との違い

似たようなものに「コンポーネント図」というものがあります。

これは

物理配置する際に、どのようにグルーピングするのか?

を表現します。

たとえば、複数の集約をグルーピングして、1つのマイクロサービス量子として扱うとか。

このコンポーネント図では、どこに配置するか?という、場所の制約は考えません。

そのため、コンポーネント図は、配置図からしたら、論理モデルという立ち位置として扱ってしまう方がいいでしょう。

2. 配置図 = レイテンシーの予測ツール ⚡️🐢

マイクロサービス間通信による、整合が取れるまでのネットワークレイテンシーの予測は、配置図を使う最も重要な理由の一つです。

物理的な配置(トポロジー)は、そのままコンポーネント間の通信コスト(レイテンシー)に直結するからです。

通信速度は、有限なので。当然距離が遠くなるほど、レイテンシーは長くなる傾向にあります。

配置図を見ることで、アーキテクトはシステムが抱えるパフォーマンス上のボトルネックを 「おおよそ予測」 できます。

📍 ケース1:同じノード(Pod)内の通信

配置

AppコンテナSidecarコンテナが、同じPod(ノード) に配置されている。

image.png

予測

通信はlocalhost(IPC)で行われる。レイテンシーはほぼゼロ(マイクロ秒単位)。

📍 ケース2:同じセグメント内の通信

配置

注文サービスPod在庫サービスPod が、同じネットワークセグメント(例: App-Zone) 内の異なるノードに配置されている。

image.png

予測

1回のネットワークホップ。レイテンシーは非常に低い(1ms未満〜数ms)。

📍 ケース3:異なるセグメント間の通信

配置

注文サービスPod(App-Zone)が、顧客DB(Data-Zone)にアクセスする。

image.png

予測

ネットワークセグメントをまたぐため、必ずファイアウォールを経由する。

レイテンシーは 中程度(数ms〜数十ms) になる可能性がある。

📍 ケース4:異なるデータセンター(リージョン)間の通信

配置

東京リージョンのサービスが、大阪リージョン のDR(災害復旧)用DBにアクセスする。

image.png

予測

物理的な距離(光の速度)が支配的。レイテンシーは非常に高い(数十ms〜数百ms)。

配置図の役割のまとめ

「配置が離れているほど、一般的にはレイテンシーが大きくなる」というメカニズムは、
光の速度が有限という事実と配置図が提供する核心的な価値です。

1. 物理配置の可視化 🗺️

配置図は、ソフトウェアの成果物(Artifact、例:注文サービス.jarWebフロントエンド.war)が、どの実行環境(ノード)にデプロイされるかを示します。

この「ノード」は、物理サーバー、仮想マシン、Kubernetesクラスタ、あるいはご指摘の**ネットワークセグメント(例: DMZ, App-Zone)といった単位を表します。

これにより、「どのコンポーネントが、どのセキュリティゾーンやインフラ上に存在するか」が一目瞭然になります。

2. レイテンシーの予測 ⚡️🐢

配置図を見ることで、アーキテクトはシステムが抱えるパフォーマンス上のボトルネックを おおよそ予測できます。

同じノード(例: Pod)内

通信はlocalhost経由。レイテンシーはほぼゼロ。

同じセグメント内(異なるノード)

1回のネットワークホップ。レイテンシーは非常に低い(例: 1ms未満)。

異なるセグメント間(同じDC内)

ファイアウォールを経由。レイテンシーは中程度(例: 数ms)。

異なるデータセンター間

物理的な距離が支配的。レイテンシーは高い(例: 数十ms以上)。

配置図は、アーキテクチャの物理的な側面を考慮し、パフォーマンスやセキュリティといった非機能要件を設計段階で検討するために不可欠なモデルです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?