Home
Get Started
実践ガイド
外部仕様設計
バッチ処理仕様設計
UAC 仕様設計
データ仕様設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
インフラ システム構成
システムの安定稼働とスケーラビリティを実現するため、環境・サーバー・ミドルウェア・ネットワーク・ハードウェアの構成を体系的に定義し、運用基盤を確立します。
🎯 概要
- 目的: システムを稼働させるために必要なインフラストラクチャの構成(環境、サーバー、ミドルウェア、ネットワーク、ハードウェア)を定義し、安定した運用基盤とスケーラブルなシステム基盤を確立する
- スコープ: 環境定義(開発・テスト・本番)、サーバー構成(物理/仮想/コンテナ)、ミドルウェア構成、ネットワーク構成(セグメント・ファイアウォール)、ハードウェア構成(オンプレミスの場合)をカバーする。アプリケーション層の論理設計や詳細なコーディング規約は対象外
- 推奨する実施タイミング: 基本設計の中盤〜後半。システムアーキテクチャ設計と非機能要件の実現方式が固まり、性能・可用性・セキュリティの要件が明確になった後に実施する
- 関連するステークホルダー: インフラチーム、システムアーキテクト、セキュリティチーム、運用チーム、プロジェクトマネージャー、調達担当(オンプレミスの場合)
📥 重要な前提知識・インプット
- 前提知識: ネットワーク基礎(TCP/IP、サブネット、VLAN、ファイアウォール)、サーバー仮想化技術(VM、コンテナ)、クラウドサービス(AWS/Azure/GCP)またはオンプレミスのインフラ構成、冗長化・可用性設計(Active-Standby、ロードバランシング)、ミドルウェア(Webサーバー、APサーバー、DBMS)の基礎知識
- インプット: システムアーキテクチャ設計書、非機能要件一覧(性能・可用性・拡張性・セキュリティ)、セキュリティ要件仕様書、ネットワーク要件、既存インフラ構成情報、予算・コスト制約、ライセンス方針
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]インフラ システム構成図
- 必須要素: 環境定義一覧、システム全体構成図、サーバー構成図(物理/論理)、ミドルウェア構成一覧、ネットワーク構成図、ファイアウォールルール一覧、ハードウェア仕様一覧(オンプレミスの場合)
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 環境分離の妥当性 | 開発・テスト・本番環境が適切に分離され、アクセス制御が定義されているか |
| 可用性設計 | 重要なコンポーネントに冗長構成が適用され、単一障害点が排除されているか |
| セキュリティ境界 | ネットワークセグメントが適切に分割され、ファイアウォールルールが最小権限の原則に従っているか |
| スケーラビリティ | 負荷増加時のスケーリング方法(垂直/水平)が明確に定義されているか |
| 技術選定の妥当性 | ミドルウェアやOSのバージョン選定理由が文書化され、サポート期限が考慮されているか |
👁️🗨️ レビュー観点:
- 非機能要件との整合性: 性能・可用性・セキュリティの要件がインフラ構成に適切に反映されているか
- 運用性: 監視、バックアップ、障害復旧、デプロイの運用手順が実行可能な構成か
- コスト妥当性: ハードウェア・ライセンス・クラウド利用料が予算内に収まるか
- 技術的実現可能性: 構築・運用に必要なスキルセットがチームに存在するか、または習得可能か
🧪成果物のサンプル
# システム構成
## 環境定義一覧
本システムでは、以下の環境を構築する。
| 環境名 | 用途 | 構成 | アクセス制限 |
|--------|------|------|------------|
| 開発環境(Dev) | 開発・単体テスト | 単一サーバー | 開発者のみ |
| テスト環境(Test) | 結合テスト・受入テスト | 本番同等の冗長構成 | 開発者・QA・ユーザー |
| ステージング環境(Staging) | リリース前検証 | 本番同等の冗長構成 | 運用チームのみ |
| 本番環境(Production) | 本番稼働 | 冗長構成 | 運用チームのみ |
**環境間のデータ移行ルール**
- 本番データは開発環境に直接コピーしない(個人情報保護のため)
- テストデータは匿名化・マスキング処理後に使用
- 環境間でのコード移行はCI/CDパイプラインを経由
---
## システム構成図
システム全体の構成を以下に示す。

**構成図作成ツール**: [draw.io](https://draw.io) を使用して作成
**主要コンポーネント**
- Webサーバー: Nginx(リバースプロキシ・SSL終端)
- アプリケーションサーバー: Node.js / Java(Spring Boot)
- データベース: PostgreSQL / MySQL
- キャッシュ: Redis
- メッセージキュー: RabbitMQ / AWS SQS
- ストレージ: S3(ファイル保存)
---
## サーバー構成
### サーバー一覧
| サーバー種別 | ホスト名 | OS | スペック | 台数 | 用途 |
|------------|---------|----|---------|----|------|
| Webサーバー | web-01, web-02 | Ubuntu 22.04 | 4vCPU, 8GB RAM | 2 | リバースプロキシ・静的コンテンツ配信 |
| APサーバー | app-01, app-02 | Ubuntu 22.04 | 8vCPU, 16GB RAM | 2 | アプリケーション実行 |
| DBサーバー | db-primary | Ubuntu 22.04 | 16vCPU, 64GB RAM, SSD 500GB | 1 | データベース(プライマリ) |
| DBサーバー | db-standby | Ubuntu 22.04 | 16vCPU, 64GB RAM, SSD 500GB | 1 | データベース(スタンバイ) |
| キャッシュサーバー | cache-01, cache-02 | Ubuntu 22.04 | 4vCPU, 16GB RAM | 2 | Redis(マスター・レプリカ) |
| バッチサーバー | batch-01 | Ubuntu 22.04 | 8vCPU, 16GB RAM | 1 | バッチ処理 |
### サーバー構成図

---
## ミドルウェア構成
### ミドルウェア一覧
| カテゴリ | 製品名 | バージョン | 用途 |
|---------|--------|----------|------|
| OS | Ubuntu Server | 22.04 LTS | サーバーOS |
| Webサーバー | Nginx | 1.24.x | リバースプロキシ・SSL終端 |
| アプリケーションサーバー | Node.js | 20.x LTS | バックエンドAPI実行 |
| データベース | PostgreSQL | 15.x | メインデータベース |
| キャッシュ | Redis | 7.x | セッション管理・キャッシュ |
| メッセージキュー | RabbitMQ | 3.12.x | 非同期処理 |
| 監視 | Prometheus + Grafana | Latest | メトリクス収集・可視化 |
| ログ管理 | Fluentd + Elasticsearch | Latest | ログ収集・検索 |
### ミドルウェア構成図
各サーバーにインストールされるミドルウェアの構成を以下に示す。

---
## ネットワーク構成
### ネットワーク構成図

---
### ネットワークセグメント一覧
| セグメント名 | ネットワークアドレス | 用途 | 接続可能範囲 |
|------------|------------------|------|-----------|
| Public Subnet | 10.0.1.0/24 | ロードバランサー・NATゲートウェイ | インターネット |
| Private Subnet 1 | 10.0.10.0/24 | Webサーバー | Public Subnet, Private Subnet 2 |
| Private Subnet 2 | 10.0.20.0/24 | アプリケーションサーバー | Private Subnet 1, 3 |
| Private Subnet 3 | 10.0.30.0/24 | データベース・キャッシュ | Private Subnet 2 |
### ファイアウォールルール
**インバウンドルール**
| 送信元 | 宛先 | プロトコル | ポート | 許可/拒否 |
|-------|------|----------|--------|---------|
| インターネット | ロードバランサー | HTTPS | 443 | 許可 |
| ロードバランサー | Webサーバー | HTTP | 80 | 許可 |
| Webサーバー | アプリケーションサーバー | HTTP | 8080 | 許可 |
| アプリケーションサーバー | データベース | PostgreSQL | 5432 | 許可 |
| アプリケーションサーバー | キャッシュ | Redis | 6379 | 許可 |
| 管理端末 | 全サーバー | SSH | 22 | 許可(VPN経由) |
---
## ハードウェア構成(オンプレミス環境の場合)
### 物理サーバー仕様
| サーバー種別 | 型番 | CPU | メモリ | ストレージ | ネットワーク | 台数 |
|------------|------|-----|--------|----------|-----------|------|
| Webサーバー | Dell PowerEdge R450 | Xeon Silver 4314 (16コア) | 64GB | SSD 480GB × 2 (RAID1) | 10GbE × 2 | 2 |
| APサーバー | Dell PowerEdge R650 | Xeon Gold 5320 (26コア) | 128GB | SSD 960GB × 2 (RAID1) | 10GbE × 2 | 2 |
| DBサーバー | Dell PowerEdge R750 | Xeon Gold 6338 (32コア) | 512GB | NVMe SSD 1.92TB × 4 (RAID10) | 25GbE × 2 | 2 |
### ネットワーク機器
| 機器種別 | 型番 | ポート数 | 用途 | 台数 |
|---------|------|---------|------|------|
| コアスイッチ | Cisco Catalyst 9300 | 48ポート (10GbE) | サーバー間通信 | 2 (冗長構成) |
| ファイアウォール | Palo Alto PA-3220 | 16ポート (10GbE) | 外部接続・セキュリティ | 2 (Active-Standby) |
| ロードバランサー | F5 BIG-IP 4000s | 8ポート (10GbE) | 負荷分散 | 2 (Active-Standby) |
### ストレージ
| 種別 | 型番 | 容量 | 接続方式 | 用途 | 台数 |
|------|------|------|---------|------|------|
| SAN | Dell PowerStore 500T | 50TB (実効容量) | iSCSI (10GbE) | データベース用ストレージ | 1 |
| NAS | QNAP TS-h1290FX | 100TB | NFS/SMB (10GbE) | ファイル共有・バックアップ | 1 |
### ラック構成図
物理的なラック配置を以下に示す。

**ラック配置の考慮事項**
- 冗長構成のサーバーは別ラックに配置(電源・ネットワーク障害の影響を最小化)
- 重量のある機器(ストレージ・UPS)は下段に配置
- 発熱量の多い機器は空調効率を考慮して配置
--- 🔄 設計の進め方・プロセス
🏗️ プロセス1: 環境定義と環境構成方針
設計対象:
開発・テスト・本番など、システムで必要な環境を定義し、各環境の目的・構成・アクセス制御を決定する。
具体例:
- 開発環境、テスト環境、ステージング環境、本番環境をどのように構成するか
- 各環境でのサーバースペック(開発環境は単一サーバー、本番環境は冗長構成など)
- 環境間のデータ移行ルール(本番データのマスキング、匿名化)
- 各環境へのアクセス権限(開発者、QA、運用チーム)
設計原則:
- 環境の分離: 開発・テスト・本番環境を物理的またはネットワーク的に分離し、相互の影響を防ぐ
- 本番同等性: テスト環境・ステージング環境は可能な限り本番環境と同等の構成とし、検証の信頼性を高める
- セキュリティとプライバシー: 本番データを開発環境で使用する際は匿名化・マスキングを徹底する
- コスト最適化: 開発環境は最小構成とし、テスト・本番環境にリソースを集中させる
文書化の推奨表現:
- 環境一覧表の作成: 環境名、用途、構成、アクセス制限を一覧表で整理する
- 環境間のデータ移行ルールの明記: データの取り扱いルール、マスキング方針を文書化する
- CI/CDパイプラインとの連携: 環境間のコード移行フローを明確にする
🏗️ プロセス2: サーバー構成とミドルウェア選定
設計対象:
システムを構成するサーバー(Webサーバー、APサーバー、DBサーバーなど)の台数・スペック・配置を決定し、各サーバーにインストールするミドルウェアを選定する。
具体例:
- Webサーバー(Nginx、Apache)の台数と配置(ロードバランサー配下に2台など)
- アプリケーションサーバー(Node.js、Java、Python)のスペック(CPU、メモリ)
- データベースサーバー(PostgreSQL、MySQL)の冗長構成(プライマリ・スタンバイ)
- キャッシュサーバー(Redis、Memcached)の配置
- バッチサーバーの必要性と構成
設計原則:
- 冗長化による可用性確保: 重要なサーバーは2台以上の冗長構成とし、障害時の自動フェイルオーバーを実現する
- 負荷分散: ロードバランサーを使用してWebサーバー、APサーバーの負荷を分散する
- 適切なスペック選定: 非機能要件(性能、スループット)に基づき、CPU・メモリ・ストレージを決定する
- ミドルウェアのバージョン管理: LTS(長期サポート)版を選定し、サポート期限を確認する
文書化の推奨表現:
- サーバー一覧表の作成: サーバー種別、ホスト名、OS、スペック、台数、用途を一覧で整理する
- ミドルウェア一覧表の作成: カテゴリ(OS、Webサーバー、DBMS、監視ツールなど)別に製品名、バージョン、用途を記載する
- サーバー構成図の作成: 各サーバーの配置と接続関係を視覚的に表現する
🏗️ プロセス3: ネットワーク構成とセキュリティ設計
設計対象:
ネットワークセグメントの分割、IPアドレス設計、ファイアウォールルール、ロードバランサー配置を決定し、セキュリティ境界を明確にする。
具体例:
- Public Subnet(インターネットからアクセス可能)とPrivate Subnet(内部のみ)の分割
- DMZ(非武装地帯)の設置とWebサーバーの配置
- データベースサーバーを最も内側のセグメントに配置し、外部から直接アクセスできないようにする
- ファイアウォールルール(許可するプロトコル、ポート、送信元IPの定義)
- VPN経由での管理アクセス
設計原則:
- セグメント分離の徹底: 外部公開サーバーと内部サーバーを異なるセグメントに配置し、ファイアウォールで保護する
- 最小権限の原則: ファイアウォールルールは必要最小限の通信のみを許可し、デフォルトは拒否とする
- 多層防御: ロードバランサー、Webサーバー、APサーバー、DBサーバーの各層でセキュリティ対策を実施する
- 管理アクセスの制限: SSH、RDPなどの管理アクセスはVPN経由に限定し、送信元IPを制限する
文書化の推奨表現:
- ネットワーク構成図の作成: セグメント、サーバー配置、ファイアウォール、ロードバランサーを視覚的に表現する
- ネットワークセグメント一覧の作成: セグメント名、ネットワークアドレス、用途、接続可能範囲を一覧で整理する
- ファイアウォールルール一覧の作成: 送信元、宛先、プロトコル、ポート、許可/拒否を表形式で明記する
🏗️ プロセス4: ハードウェア構成(オンプレミスの場合)
設計対象:
オンプレミス環境の場合、物理サーバー、ネットワーク機器、ストレージの仕様を決定し、ラック配置を設計する。
具体例:
- 物理サーバーの型番、CPU、メモリ、ストレージ、台数
- ネットワーク機器(スイッチ、ファイアウォール、ロードバランサー)の選定
- ストレージ(SAN、NAS)の容量と接続方式
- ラック配置(冗長構成のサーバーを別ラックに配置)
設計原則:
- 物理的な冗長性: 冗長構成のサーバーは別ラックに配置し、電源・ネットワーク障害の影響を最小化する
- 適切なRAID構成: データの重要度に応じてRAID1、RAID10などの冗長構成を選択する
- 発熱と電源の考慮: 発熱量の多い機器の配置と空調効率、消費電力とUPS容量を考慮する
- 拡張性の確保: 将来のサーバー増設を見越したラックスペースとネットワークポートを確保する
文書化の推奨表現:
- 物理サーバー仕様一覧の作成: サーバー種別、型番、CPU、メモリ、ストレージ、ネットワーク、台数を一覧で整理する
- ネットワーク機器一覧の作成: 機器種別、型番、ポート数、用途、台数を記載する
- ストレージ仕様一覧の作成: 種別、型番、容量、接続方式、用途、台数を整理する
- ラック構成図の作成: 物理的な機器配置を視覚的に表現する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『インフラ設計の教科書』、『AWSインフラ設計の教科書』、『Site Reliability Engineering(SRE)』、各クラウドベンダーのベストプラクティスガイド
- 関連する他のガイド: 📄
システムアーキテクチャ設計、📄
非機能要件の実現方式、📄
セキュリティ仕様・方式、データベース設計ガイド、運用設計ガイド
- ツール・テンプレート: draw.io(ネットワーク構成図・サーバー構成図作成)、Terraform(Infrastructure as Code)、Ansible(構成管理)
テンプレートサイト: 📄テンプレート集