デプロイメント図は、ソフトウェアエンジニアリングの文脈において重要な設計図です。システムの物理的アーキテクチャを可視化し、ソフトウェアコンポーネントがハードウェアノードにどのように配置されているかを詳細に示します。クラス図が静的構造に注目するのに対し、シーケンス図が時間経過に伴う相互作用をマッピングするのとは異なり、デプロイメント図はアプリケーションを現実に根ざすものです。コードが実際にどこで実行されるかという問いに答えるのです。
このアーティファクトを理解することは、DevOps実践者、システムアーキテクト、バックエンドエンジニアにとって不可欠です。抽象的な設計と物理的なインフラの間のギャップを埋めます。このガイドでは、デプロイメント図の核心的な要素、構築方法、戦略的応用について探求します。
🔍 デプロイメント図とは何か？
デプロイメント図は、統一モデリング言語（UML）の一種です。ハードウェア要素、すなわちノードと、それらに配置されたソフトウェアアーティファクトを描写します。実行時アーキテクチャの静的ビューを提供します。この可視化は、システムのトポロジーを理解する上で不可欠です。
現代のウェブアプリケーションを考えてみましょう。それはたいてい、一台のマシン上で動作する単一のモノリスではありません。代わりに、複数のサーバー、データベース、ロードバランサー、クライアントデバイスを含みます。デプロイメント図は、これらのエンティティとその通信チャネルをマッピングします。
主な目的
- インフラ構成計画：プロビジョニングの前に、リソース要件を視覚化するのをチームに助ける。
- 通信マッピング：異なるノードがどのように相互に通信するかを定義する。
- セキュリティ境界：ファイアウォール、ゲートウェイ、信頼されたゾーンを示す。
- スケーラビリティ分析：システムが水平方向または垂直方向にどのように拡張されるかを示す。
🧩 コアコンポーネント
正確なデプロイメント図を構築するには、その構成要素を理解する必要があります。すべての図は、ノード、アーティファクト、接続から構成されます。
1. ノード
ノードは、物理的または仮想的なコンピューティングリソースを表します。アーティファクトのコンテナです。ノードは通常、名前の上に stereotype <<node>> を配置した3Dボックスとして表現されます。
- 計算ノード：データを処理するデバイスです。サーバー、ワークステーション、メインフレーム、モバイルデバイスなどが例です。
- 実行環境：アプリケーションロジックをホストするソフトウェアプラットフォームです。特定の言語用のランタイム環境やオペレーティングシステムが該当します。
- データストア：永続的ストレージに専念した特別なノードです。データベースサーバー、ファイルサーバー、オブジェクトストレージシステムなどが例です。
各ノードには名前があり、実際の実装ではIPアドレスやドメイン名が関連付けられることが多いです。
2. アーティファクト
アーティファクトは、ノードにデプロイされる物理的なソフトウェアの一部です。開発プロセスの成果物を表します。アーティファクトがなければ、ノードはただの空のハードウェアにすぎません。
- 実行可能ファイル：サーバー上で実行されるコンパイル済みコード。
- ライブラリ:実行可能ファイルが機能するために必要な依存関係。
- 設定ファイル:ソフトウェアがその特定の環境でどのように動作するかを規定する設定。
- データベース:データベースノード内に格納されているスキーマ定義またはデータファイル。
- Webページ:クライアントに提供される静的HTMLファイルまたはテンプレート。
アーティファクトは通常、ステレオタイプ <<artifact>> を持つ小さな長方形で表される。これらは、存在するノードの内部に示されることが多い。
3. 接続
接続はノード間の通信経路を示す。データがシステムアーキテクチャをどのように流れているかを示す。これらの線はネットワークリンクを表す。
- ネットワークプロトコル:線に付されたラベルは、TCP/IP、HTTP、HTTPS、またはSQLなどの使用されるプロトコルを示す。
- 通信チャネル:太い線はしばしば高帯域の接続を表し、細い線は管理トラフィックを示すことがある。
- 依存関係:破線は、あるノードが動作のために別のノードに依存していることを示すことができる。
📋 記号の凡例と表記法
標準化により、異なるチームのエンジニアが同じ図を読み取ることができるようになる。以下の表は、デプロイメント図で使用される一般的な記号を概説している。
| 記号 | 名前 | 説明 |
|---|---|---|
| 3Dボックス | ノード | ソフトウェアが実行される物理的または仮想の計算リソース。 |
| <<artifact>> を持つ長方形 | アーティファクト | jarファイルやデータベースのような、デプロイ可能なソフトウェアの一部。 |
| 実線 | 関連 | 2つの要素間の構造的リンク。 |
| 破線 | 依存関係 | 1つの要素が機能するには、もう1つの要素が必要である。 |
| 開放矢印 | ナビゲーション | 依存関係の方向またはデータフローの経路を示す。 |
| クラウド形状 | 外部システム | 第三者のサービスまたは外部ネットワークを表す。 |
| <<device>>を備えた長方形 | デバイス | ルーターまたはスイッチのような特定のハードウェアデバイス。 |
| <<interface>>を備えた長方形 | インターフェース | ノード間の相互作用の契約を定義する。 |
🛠️ デプロイメント図の作成方法
デプロイメント図を作成するには体系的なプロセスが必要です。システムの要件とインフラ構成の制約についての知識が必要です。信頼性の高い地図を作成するには、以下の手順に従ってください。
ステップ1：ハードウェアを特定する
まず、関与するすべての物理デバイスをリストアップしてください。エッジデバイスを省略しないでください。分散システムでは、以下のものが含まれます：
- クライアントデバイス（ラップトップ、携帯電話、タブレット）。
- ネットワーク機器（ルーター、ファイアウォール、ロードバランサー）。
- アプリケーションサーバー。
- データベースサーバー。
- ストレージシステム。
システムがクラウドインフラを用いている場合、これらのノードは物理的なボックスではなく仮想インスタンスですが、図では依然としてノードとして表現されます。
ステップ2：ソフトウェアをマッピングする
ハードウェアが定義されたら、ソフトウェアアーティファクトをそれらの上に配置します。このステップで論理がどこに存在するかが決まります。
- どのサーバーがバックエンドAPIを実行しているかを特定する。
- フロントエンドをホストするWebサーバーの場所を特定する。
- ユーザーのデータを保持するデータベースを指定してください。
- キャッシュレイヤーが配置される場所をマークしてください。
すべてのアーティファクトが互換性のあるノード上に配置されていることを確認してください。たとえば、実行環境がなければ、Javaアプリケーションはデータベースノード上で直接実行できません。
ステップ3：接続を定義する
ノードをつなぐ線を描いてください。これらの線に使用されているプロトコルをラベル付けしてください。
- フロントエンドからバックエンド：通常、TCP上のHTTPまたはHTTPSを使用します。
- バックエンドからデータベース：JDBCやODBCなどの特定のドライバを使用することが多いです。
- 内部サービス：gRPC、REST、またはメッセージキューを使用する可能性があります。
プロトコルについて具体的に記述してください。これにより、セキュリティ監査やパフォーマンスチューニングが容易になります。
ステップ4：セキュリティゾーンを確認する
デプロイメント図には、セキュリティ境界が含まれることが多いです。これらは、同じセキュリティポジションを持つノードをグループ化する論理的なコンテナです。
- DMZ（非武装地帯）：Webサーバーなどの公開対象のサーバーを含みます。
- 内部ネットワーク：インターネットから直接アクセスできないデータベースやアプリケーションサーバーを含みます。
- 信頼ゾーン：機密性の高い管理システムを含みます。
これらのゾーンを視覚的に区別するために、異なる色や陰影を用いてください。
📈 明確性のためのベストプラクティス
複雑すぎる図は、情報を伝えることができません。明確さと実用性を維持するために、これらの原則に従ってください。
- 高レベルで保つ：同じノード上にある場合、すべてのマイクロサービスを含めないでください。論理的にグループ化してください。
- 一貫した名前を使用する：プロジェクト内のすべての図で、ノードに標準的な名前を使用してください。
- プロトコルをラベル付けする：接続線をラベルなしで残してはいけません。曖昧さは構成エラーを引き起こします。
- 関心を分離する： システムが大規模な場合は、図をレイヤーに分割してください（例：クライアントレイヤー、アプリレイヤー、データレイヤー）。
- 定期的に更新する： デプロイメント図は、現在の状態を反映している場合にのみ有用です。インフラ構成の変更時に図を更新してください。
❌ 避けるべき一般的なミス
エンジニアはインフラ構造をモデル化する際にしばしば誤りを犯します。これらの落とし穴を認識することで、ドキュメントにおける技術的負債を防ぐことができます。
1. ネットワーク遅延を無視する
ページ上でノードをあまり近くに配置すると、物理的に近いように誤解される可能性があります。実際には、1つの地域にあるデータベースと別の地域にあるアプリケーションの間には遅延が生じます。地理的な分離を示すために注釈を使用してください。
2. アーティファクトの過剰配置
1つのノードにあまりにも多くのアーティファクトを配置すると、図が見にくくなります。サーバーが複数のサービスをホストしている場合は、サブノードや特定のコンテナの下にグループ化することを検討してください。
3. 外部依存関係の欠落
システムはほとんどが完全に独立して存在することはありません。多くの場合、サードパーティのAPIやSaaSプラットフォームに依存しています。システムが接続する外部のクラウドやサービスは常に含めるようにしてください。
4. 静的と動的な混同
デプロイメント図は静的なものです。トラフィック量やリクエストレートを示すことはできません。静的な線だけを使って動的なロードバランシングの動作を表現しようとしないでください。そのような場合は追加の記法や別々の図を使用してください。
🔗 他の図との関係
デプロイメント図は単独で存在するものではありません。他のモデル化アーティファクトと連携して機能します。
- クラス図： クラス図はコード構造を定義します。デプロイメント図はそのコードが実行される場所を定義します。
- コンポーネント図： コンポーネント図はコードの論理的なグループ化を示します。デプロイメント図はそのグループを物理的なノードにマッピングします。
- シーケンス図： シーケンス図は相互作用の流れを示します。デプロイメント図はその流れが発生する場所の文脈を提供します。
これらの関係を理解することで、一貫性のあるアーキテクチャドキュメントのセットを確保できます。クラス図で変更が加えられた場合、新しいコンポーネントが異なるリソースを必要とするならば、デプロイメント図の更新が必要になる可能性があります。
🌐 実際の応用シナリオ
デプロイメント図は、ソフトウェアライフサイクルのさまざまな段階で使用されます。
1. ディザスタリカバリ計画
障害を想定して計画する際、チームはデプロイメント図を使って単一障害点を特定します。重要なデータベースがバックアップ接続のない単一のノード上にある場合、図はそのリスクを直ちに浮き彫りにします。
2. コスト最適化
クラウドコストはリソースの使用量によって驱动されます。インフラ構造を可視化することで、未利用のノードを特定できます。サービスをより少ない、より強力なノードに統合することで、運用コストを削減できます。
3. セキュリティ監査
セキュリティチームは、機密データが不安定なチャネルを通過しないように確認するために、デプロイメント図を確認します。アプリケーションとデータベースの間の暗号化されていない接続がないかを確認します。
4. 新しいエンジニアのオンボーディング
新しいチームメンバーは、システムのトポロジーを理解するのが難しくなることが多いです。明確なデプロイメント図はナビゲーションの地図として機能します。コードをどこにデプロイすべきか、ログをどこで探すべきかを理解するのに役立ちます。
🔄 メンテナンスと進化
ソフトウェアシステムは進化します。新しい機能には新しいノードが必要です。古いノードは廃止されます。デプロイメント図はシステムと共に進化しなければなりません。
- バージョン管理：図のファイルをコードとして扱う。ソースコードと同じリポジトリに保存する。
- 自動生成：現代の環境では、一部のツールがインフラストラクチャコード（IaC）からデプロイメント図を自動生成できます。これにより、図が自動的に同期された状態を保つことができます。
- レビューのサイクル：主要なアーキテクチャ変更の完了定義に、図の更新を含める。
メンテナンスを無視すると「図の劣化（diagram rot）」が発生します。これはドキュメントが現実と一致しなくなった状態です。古くなった図に基づいてデプロイを試みる開発者にとっては、失敗は避けられません。
📊 主なポイントのまとめ
このガイドでは、デプロイメント図の重要な側面を網羅しました。主要なポイントを再確認しましょう：
- ノードはハードウェアを表す：これらはソフトウェアのコンテナです。
- アーティファクトはソフトウェアを表す：これらはノード上で実行されるファイルやデータです。
- 接続は通信を表す：これらはプロトコルとデータフローを定義します。
- 明確さが最優先：図の可読性を保ち、インフラ構造に焦点を当てる。
- 常に更新する：図がライブ環境と一致していることを確認する。
このスキルを習得することで、堅牢でスケーラブルかつ安全なシステムを設計できるようになります。抽象的な要件を具体的なインフラ構成計画に変換できます。
🚀 今後のステップ
エンジニアリングの道を歩み続ける中で、これらの原則を現在のプロジェクトに適用してください。次にリリースするマイクロサービスのデプロイメント図を描き始めるのが良いでしょう。ノードを特定し、アーティファクトを配置し、接続を描画します。チームとレビューして、物理的なレイアウトについて全員が同じ理解を持っていることを確認しましょう。
ドキュメント作成はシステムの安定性への投資です。適切に描かれたデプロイメント図は、トラブルシューティング、スケーリング、セキュリティレビューの際に大きな利益をもたらします。これをアーキテクチャワークフローの標準的な一部にしましょう。
