デプロイメント図とは何ですか？
A デプロイメント図は構造的な UML図はソフトウェアシステムの物理的実行アーキテクチャをモデル化するものです。統合モデル言語（UML）仕様のコア標準の一つとして、この特定の UML図タイプソフトウェアコンポーネントがハードウェアホスティングターゲット、クラウドインフラ構成要素、またはコンテナランタイムに物理的にデプロイされる方法を示します。開発環境と本番環境の領域にわたって、サーバークラスタの境界、データベースのレプリケーション経路、ロードバランサーのレイヤー、ハードウェアネットワークプロトコルの明確なレイアウトを、システムエンジニア、DevOps専門家、ネットワークアーキテクトに提供します。
With VPasCodeVPasCodeを使えば、複雑なベクターグループ形状や手動での座標マッピングに苦労する必要がありません。シンプルな宣言型スクリプトブロックを使用することで、エンジンが自動的にハードウェアノード構造をグループ化・計算・ネストし、きれいに整理します。
コア構文ガイド：要素と構造
PlantUMLで正確で標準準拠のUMLデプロイメント図を設計するには、ハードウェアノード、実行環境、デプロイメントアーティファクト、ネットワーク接続を習得する必要があります。
1. インフラストラクチャキューブ（ノード）の宣言
デプロイメントレイアウトでは、物理的なコンピューティングリソースは3Dの三次元キューブとして表現されます。これらの要素は、nodeキーワードを使用して宣言するか、またはハードウェア層に関する即時の視覚的コンテキストを読者に与える専用のバリエーションを選択することで行います：
node "ベアメタルアプリケーションサーバ" as CoreServer
node Server1
database "データベースサーバ" as DB_Node
2. クラウドレイヤーと仮想環境のモデル化
現代のアプリケーションは、物理ハードウェアに直接デプロイされることがめったにありません。PlantUMLは、論理実行境界、クラウドプロバイダーの範囲、またはDockerやKubernetesのような仮想コンテナランタイムを表現するために、ネストされたグループ化ラッパーを提供します：
cloud— 外部のパブリックWeb層またはクラウドネットワーク境界（例：AWS、Azure）を表します。frame— 仮想システムまたは組織領域を表します。storage— 物理的なSAN構成またはオブジェクトストアの場所を表します。
cloud "Amazon Web Services VPC" {
node "EC2 Linuxインスタンス" as WorkerNode
}
3. デプロイアーティファクトの定義（どこで実行されるか）
アーティファクトは、ノードにデプロイされる実際の物理ファイル（コンパイルされたJARファイル、静的ビルドフォルダ、または圧縮パッケージなど）を表します。アーティファクトは、次のキーワードを使って宣言します：artifactキーワード、またはハードウェアブロック内に直接配置します：
node "アプリケーションサーバ" {
artifact "api_v1.0.war" as API_File
}
4. ネットワーク通信リンクのマッピング
インフラ構成要素間の接続は、具体的な物理ネットワーク、配線経路、または無線チャネルを表します。これらのリンクは、実線の二重ダッシュ（--）を使用してマッピングし、引用符内にテキストを追加して、使用されるネットワークプロトコルを明確に定義します（例：HTTPS、TCP/IP、SSH）：
node Server1
node DB_Node
Server1 -- DB_Node : "TCP/IP (ポート5432)"
実用的なデプロイマップ作成のベストプラクティス
- 構造を正しくネストする：常に内部コンポーネントやアーティファクトを、
node宣言の波かっこ内に描画して、実行の所在を明確に示してください。 - 通信プロトコルにラベルを付ける：サーバーの間に空白行を描画しないでください。常に接続に主な通信プロトコル（例：
"HTTPS（ポート443）"）をラベルとして付けることで、ネットワークおよびセキュリティレビューを支援してください。 - 可用性ゾーンを分離する： 高可用性クラウド構成を文書化する際は、別々の
フレームラッパーを使用して、分割されたリージョン構成（例：us-east-1a対比してus-east-1b).
実際のPlantUMLデプロイ図の例
例1：クラシックな3層Web構成（ノードとプロトコル）
このテンプレートは、標準的な現代的な企業アプリケーション構造をモデル化しており、外部のコンテンツ配信ネットワーク、アプリケーションサーバークラスタ、およびセキュアな内部データベースホスト層をマッピングしています。
@startuml
cloud "パブリックインターネット" as net
node "Cloudflare CDNエッジ" as cdn
frame "デミリタリゼッドゾーン（DMZ）" {
node "Nginxロードバランサーサーバー" as proxy
}
frame "プライベートアプリケーションVPCサブネット" {
node "Ubuntu Server 22.04" as app_node {
artifact "core_api.jar" as application
}
}
database "マネージドデータベース層" {
node "PostgreSQLプライマリクラスタ" as db_master
}
' トポロジカルな接続線を確立
net -- cdn : "HTTPS"
cdn -- proxy : "HTTPS（TLS 1.3）"
proxy -- app_node : "HTTP（ポート8080）"
app_node -- db_master : "TCP/IP（ポート5432）"
@enduml
構文の分解： このマップは、セキュリティ境界を明確に示しています。コンパイルされたアセットcore_api.jarは、安全にapp_nodeサーバーボックス内にネストされています。ネットワーク経路は滑らかに内側へスケーリングされ、パブリックWebエッジからマネージドデータベース層まで、すべてのセグメントに対して厳格なプロトコル規則が確立されています。
例2：クラウドネイティブコンテナアーキテクチャ（KubernetesおよびAWS Mesh）
この高度なエンタープライズブループリントは、非常にスケーラブルなマルチリージョンクラウドデプロイメントをマッピングしています。ネストされたノードレイアウトを使用して、ロードバランシングされたKubernetesコンテナシステムと独立したクラウドデータベースとの相互作用を可視化しています。
@startuml
cloud "Amazon Web Services（AWS）" {
node "AWSアプリケーションロードバランサー" as alb
frame "可用性ゾーン：us-east-1a" {
node "EC2ワーカーノードノードA" as ec2_a {
node "K8sポッド：Webフロントエンド" as pod_web_a
node "K8sポッド：注文API" as pod_api_a
}
}
frame "可用性ゾーン：us-east-1b" {
node "EC2ワーカーノードノードB" as ec2_b {
node "K8sポッド：Webフロントエンド" as pod_web_b
node "K8sポッド：注文API" as pod_api_b
}
}
storage "AWS Aurora Serverlessクラスタ" {
database "カスタマーデータベース" as rds_db
}
}
' インフラストラクチャオーケストレーションラインをルーティング
alb -- pod_web_a : "HTTPラウンドロビン"
alb -- pod_web_b : "HTTPラウンドロビン"
pod_web_a -- pod_api_a : "内部gRPC"
pod_web_b -- pod_api_b : "内部gRPC"
pod_api_a -- rds_db : "SSL/TCP"
pod_api_b -- rds_db : "SSL/TCP"
@enduml
構文の分解： ノードを子要素にネストすることでnodeターゲットを子要素のノード構造において、このテンプレートはコンテナ化されたレイアウトを完璧にモデル化しています（EC2仮想マシン内での実行中のポッド）。アプリケーションロードバランサーは、可用性ゾーン across にわたって着信要求をスムーズに分散し、クラスタコンポーネントはデータベース呼び出しを共有ストレージプールに戻すルーティングを行います。