インフラ システム構成

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

インフラ システム構成

システムの安定稼働とスケーラビリティを実現するため、環境・サーバー・ミドルウェア・ネットワーク・ハードウェアの構成を体系的に定義し、運用基盤を確立します。

🎯 概要


  • 目的: システムを稼働させるために必要なインフラストラクチャの構成(環境、サーバー、ミドルウェア、ネットワーク、ハードウェア)を定義し、安定した運用基盤とスケーラブルなシステム基盤を確立する
  • スコープ: 環境定義(開発・テスト・本番)、サーバー構成(物理/仮想/コンテナ)、ミドルウェア構成、ネットワーク構成(セグメント・ファイアウォール)、ハードウェア構成(オンプレミスの場合)をカバーする。アプリケーション層の論理設計や詳細なコーディング規約は対象外
  • 推奨する実施タイミング: 基本設計の中盤〜後半。システムアーキテクチャ設計と非機能要件の実現方式が固まり、性能・可用性・セキュリティの要件が明確になった後に実施する
  • 関連するステークホルダー: インフラチーム、システムアーキテクト、セキュリティチーム、運用チーム、プロジェクトマネージャー、調達担当(オンプレミスの場合)

📥 重要な前提知識・インプット


  • 前提知識: ネットワーク基礎(TCP/IP、サブネット、VLAN、ファイアウォール)、サーバー仮想化技術(VM、コンテナ)、クラウドサービス(AWS/Azure/GCP)またはオンプレミスのインフラ構成、冗長化・可用性設計(Active-Standby、ロードバランシング)、ミドルウェア(Webサーバー、APサーバー、DBMS)の基礎知識
  • インプット: システムアーキテクチャ設計書、非機能要件一覧(性能・可用性・拡張性・セキュリティ)、セキュリティ要件仕様書、ネットワーク要件、既存インフラ構成情報、予算・コスト制約、ライセンス方針

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]インフラ システム構成図
  • 必須要素: 環境定義一覧、システム全体構成図、サーバー構成図(物理/論理)、ミドルウェア構成一覧、ネットワーク構成図、ファイアウォールルール一覧、ハードウェア仕様一覧(オンプレミスの場合)
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
環境分離の妥当性 開発・テスト・本番環境が適切に分離され、アクセス制御が定義されているか
可用性設計 重要なコンポーネントに冗長構成が適用され、単一障害点が排除されているか
セキュリティ境界 ネットワークセグメントが適切に分割され、ファイアウォールルールが最小権限の原則に従っているか
スケーラビリティ 負荷増加時のスケーリング方法(垂直/水平)が明確に定義されているか
技術選定の妥当性 ミドルウェアやOSのバージョン選定理由が文書化され、サポート期限が考慮されているか

👁️‍🗨️ レビュー観点:

  • 非機能要件との整合性: 性能・可用性・セキュリティの要件がインフラ構成に適切に反映されているか
  • 運用性: 監視、バックアップ、障害復旧、デプロイの運用手順が実行可能な構成か
  • コスト妥当性: ハードウェア・ライセンス・クラウド利用料が予算内に収まるか
  • 技術的実現可能性: 構築・運用に必要なスキルセットがチームに存在するか、または習得可能か
🧪成果物のサンプル
# システム構成

## 環境定義一覧

本システムでは、以下の環境を構築する。

| 環境名 | 用途 | 構成 | アクセス制限 |
|--------|------|------|------------|
| 開発環境(Dev) | 開発・単体テスト | 単一サーバー | 開発者のみ |
| テスト環境(Test) | 結合テスト・受入テスト | 本番同等の冗長構成 | 開発者・QA・ユーザー |
| ステージング環境(Staging) | リリース前検証 | 本番同等の冗長構成 | 運用チームのみ |
| 本番環境(Production) | 本番稼働 | 冗長構成 | 運用チームのみ |

**環境間のデータ移行ルール**
- 本番データは開発環境に直接コピーしない(個人情報保護のため)
- テストデータは匿名化・マスキング処理後に使用
- 環境間でのコード移行はCI/CDパイプラインを経由

---

## システム構成図

システム全体の構成を以下に示す。

![システム構成図](./diagrams/system-architecture.drawio.svg)

**構成図作成ツール**: [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 | バッチ処理 |

### サーバー構成図

![サーバ構成図](./diagrams/server-architecture.drawio.svg)

---

## ミドルウェア構成

### ミドルウェア一覧

| カテゴリ | 製品名 | バージョン | 用途 |
|---------|--------|----------|------|
| 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 | ログ収集・検索 |

### ミドルウェア構成図

各サーバーにインストールされるミドルウェアの構成を以下に示す。

![ミドルウェア構成図](./diagrams/middleware-architecture.drawio.svg)

---

## ネットワーク構成

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

![ネットワーク構成図](./diagrams/network-architecture.drawio.svg)

---

### ネットワークセグメント一覧

| セグメント名 | ネットワークアドレス | 用途 | 接続可能範囲 |
|------------|------------------|------|-----------|
| 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 |

### ラック構成図

物理的なラック配置を以下に示す。

![ラック構成図](./diagrams/rack-layout.drawio.svg)

**ラック配置の考慮事項**
- 冗長構成のサーバーは別ラックに配置(電源・ネットワーク障害の影響を最小化)
- 重量のある機器(ストレージ・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、メモリ、ストレージ、ネットワーク、台数を一覧で整理する
  • ネットワーク機器一覧の作成: 機器種別、型番、ポート数、用途、台数を記載する
  • ストレージ仕様一覧の作成: 種別、型番、容量、接続方式、用途、台数を整理する
  • ラック構成図の作成: 物理的な機器配置を視覚的に表現する

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク



テンプレートサイト: 📄Arrow icon of a page linkテンプレート集