de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

UMLデプロイメント図：ソフトウェアとインフラストラクチャのマッピング

Table of Contents hide
1 物理アーキテクチャの構造
1.1 1. ノード：ハードウェアと実行環境
1.2 2. アーティファクト：デプロイ可能なソフトウェア
1.3 3. 通信経路：接続
2 トポロジーの可視化
3 デプロイメント図を使う理由は？

一方でコンポーネント図はコードモジュールの論理的構成に注目するのに対し、UMLデプロイメント図現実とのギャップを埋めます。重要な問いに答えるのです：「このすべてのコードは実際にどこに存在するのか？」

この図は、物理的な実行環境に特化した唯一のUMLモデルです。ソフトウェアアーティファクトがハードウェアターゲットにどのようにマッピングされるかを可視化し、システムのコンポーネントがサーバー、データベース、モバイルデバイス、クラウドインフラストラクチャの間でどのように分散されているかを示します。クラウドコンピューティング、マイクロサービス、IoTの時代において、この物理的アーキテクチャを理解することは、かつてないほど重要です。

物理アーキテクチャの構造

の主な目的はデプロイメント図システムの物理的なトポロジーを示すことです。つまり、ハードウェア（ノード）とそれら上で実行されるソフトウェア（アーティファクト）です。

1. ノード：ハードウェアと実行環境

デプロイメント図の基本的な構成要素はノードです。ノードは、アーティファクトが実行のためにデプロイされる計算リソースを表します。3Dのボックス（立方体）として描かれます。

ノードには主に2つの種類があります：

  • デバイスノード：これらは処理能力を持つ物理的なハードウェアリソースを表します。

    • 例： アプリケーションサーバー、データベースサーバー、モバイルフォン、IoTセンサー、またはロードバランサー。

  • 実行環境ノード（実行環境）： これらはデバイスノード内で実行され、特定の種類のアーティファクトをホストするソフトウェアベースのコンテナです。展開されたコンポーネントを管理するソフトウェア層を表しています。

2. アーティファクト：デプロイ可能なソフトウェア

1つのアーティファクトアーティファクトはソフトウェアコンポーネントの具体的な物理的表現を表します。一方、「コンポーネント」はクラスの論理的グループ化であるのに対し、「アーティファクト」はサーバーに実際にインストールされるファイルです。

アーティファクトは通常、キーワード「«artifact»」を含む長方形、または角に小さな文書アイコンとして描かれます。通常、配置される場所を示すためにノードの内部にに配置されます。

  • 例： user-service.jar, index.html, database-schema.sql, config.xml、またはpayment-api.exe.

3. 通信経路：接続

ノードはほとんどが孤立して動作することはない。通信経路ノード間の物理的接続または関連を表し、情報のやり取りの仕方を示す。

これらは2つのノードを結ぶ実線として描かれる。重要なのは、通信プロトコルや使用されているネットワークタイプを示すために、しばしばスタereotypeでラベル付けされていることである。

  • 例： «HTTP/HTTPS», «TCP/IP», «JDBC», «RMI»、または «メッセージキュー».

Communication Paths: The Connections

トポロジーの可視化

一般的な配置図は、システムの実行時構造について物語を伝えます。たとえば、標準の3層Webアプリケーションは、次のように可視化できます：

  1. クライアント層： 1つモバイルデバイス（ノード）に含まれるモバイルアプリ（アーティファクト）。

  2. ミドル層： 1つWebサーバー（デバイスノード）がホストするDockerコンテナ（実行環境）、その内部にはAPI Service.jar（アーティファクト）。

  3. データ層： A データベースサーバー （デバイスノード）でホストされている PostgreSQL インスタンス（実行環境）、これは ユーザー・データ （アーティファクト）。

これらのノードを接続するには、ラベルが付いた線を使用する。«HTTPS» （モバイルとWebサーバーの間）および «JDBC» （Webサーバーとデータベースの間）。

デプロイメント図を使う理由は？

デプロイメント図はDevOpsエンジニア、システムアーキテクト、ネットワーク管理者にとって不可欠である。

  • デプロイメント計画： リリース管理の決定的なマップとして機能し、どのファイルがどのサーバーに配置されるかを正確に示す。

  • パフォーマンス分析： 処理の分布とネットワークリンクを可視化することで、アーキテクトは潜在的なボトルネック（例：低出力のノードに多数のアーティファクトが配置されている、または頻繁に通信するサービス間のネットワークリンクが遅いなど）を特定できる。

  • セキュリティモデリング： これらは、外部ネットワーク（公開インターネット）に露出しているノードと、ファイアウォールの背後に隔離されているノードを強調することで、セキュリティリスクを特定するのを支援します。

  • インフラストラクチャ as Code (IaC) デザイン： モダンな DevOps では、これらの図は、クラウドリソースをプロビジョニングするための Terraform または CloudFormation スクリプトを書くための概念的なブループリントを提供します。

UML および AI アシスト可視化に関する詳細情報については、こちらのUML リソースハブ.