この記事について

記事	タイトル	状態
第0回	全体ガイド	✅ 完了
第1回	構成図編	📍今回
第2回	VPC & Subnet	⬜ 未読
第3回	NAT Gateway & Route Table	⬜ 未読
第4回	Security Group	⬜ 未読
第5回	ECR & Docker Image	⬜ 未読
第6回	Public ALB	⬜ 未読
第7回	ECS Front & IAM	⬜ 未読
第8回	ECS API & Internal ALB	⬜ 未読
第9回	RDS MySQL	⬜ 未読
第10回	Secrets Manager & 完成	⬜ 未読

進捗: 9% (1/11記事) | 目標: システム構成図の理解

📁 完全なコードはGitHubで公開：👉 GitHub: fargate-iac-02

1. はじめに

この記事は、docker-composeで動いていたWebアプリケーションをAWS ECS Fargateに移行するために、構成設計を行った記録です。

1-1. この記事で学べること

AWS構成図の書き方（4種類・7図：論理構成図・配置構成図・ネットワーク図×4・データフロー図）
論理構成図と配置構成図の違いと使い分け
実務での図の描き分け方（目的別に4種類）
ECS Fargateの構成設計の考え方
詳細設計で決めるべきこと（命名規則、タグ戦略、変数管理など）

1-2. 対象読者

AWSを少し触ったことがある方
docker-composeは使ったことがある方
インフラ設計を学びたい方
構成図の書き方に悩んでいる方

1-3. 想定環境

AWS: ECS Fargate, RDS, ALB, VPC など
IaC: Terraform（実装は次回の記事で）
言語: Go（API）、HTML/CSS/JS（Frontend）

2. 元の構成（docker-compose）

2-1. 3層アーキテクチャ

移行前の構成は、典型的な3層アーキテクチャです。

Front: Nginx（静的コンテンツ配信）
API: Go言語（ビジネスロジック）
DB: MySQL（データ永続化）

2-2. docker-compose.ymlの構成

services:
  front:
    build: ./front
    ports:
      - "8081:80"
    
  api:
    build: ./api
    ports:
      - "8080:8080"
    environment:
      - DB_SERVERNAME=db-container
    depends_on:
      - db
    
  db:
    image: mysql:latest
    environment:
      MYSQL_ROOT_PASSWORD: cloudtech
    volumes:
      - db-data:/var/lib/mysql

2-3. この構成の課題

ローカル開発環境としては問題ありませんが、本番運用には以下の課題があります：

スケールできない: 1台のPCで動作
可用性が低い: 障害時に自動復旧なし
セキュリティ: すべてのポートが公開
運用負荷: サーバー管理が必要

これらを解決するため、ECS Fargateへの移行を決定しました。

3. 移行先の構成（ECS Fargate）

3-1. なぜECS Fargateか

以下の理由からECS Fargateを選択しました：

要件	ECS Fargate	代替案（EC2）
サーバー管理	不要	必要
Multi-AZ	簡単	手動設定
Auto Scaling	組み込み	別途設定
コスト	使用量課金	常時課金

3-2. 主要なAWSサービス

ECS Fargate: コンテナ実行環境（サーバーレス）
ALB: Application Load Balancer（負荷分散）
RDS: マネージドデータベース（Multi-AZ対応）
VPC: Virtual Private Cloud（ネットワーク分離）
ECR: Elastic Container Registry（イメージ保管）
CloudWatch Logs: ログ集約
Secrets Manager: 機密情報管理

4. 構成図の種類と使い分け

実務では、目的に応じて4種類の図を使い分けます。

図の種類	目的	対象者	詳細度
論理構成図	全体像の理解	全員	低
配置構成図	AZ配置の理解	インフラエンジニア	中
ネットワーク構成図	通信フローとSG設計	インフラ・セキュリティ	高
データフロー図	リクエスト処理の流れ	アプリ開発者	高

4-1. 論理構成図（Logical Architecture Diagram）

目的: システム全体の論理的な構成を俯瞰する
対象者: プロジェクト全員（開発者、PM、営業など）
特徴: 物理配置を無視、コンポーネント間の関係のみ表現

この図で分かること:

システムの主要コンポーネント
3層アーキテクチャの構造
Supporting Servicesの役割

料理で例えると:

Frontend = レストランのホール（お客様対応）
Backend = 厨房（調理）
Data = 冷蔵庫（食材保管）

4-2. 配置構成図（Deployment Architecture Diagram）

目的: Multi-AZ構成と物理配置を理解する
対象者: インフラエンジニア、SRE
特徴: AZ、Subnet、可用性を明示

この図で分かること:

Multi-AZ構成（2つのAZ）
Subnetの分割（Public、Private App、Private DB）
各AZでのリソース配置

可用性のポイント:

AZ-1aが障害 → AZ-1cが処理継続
RDSは自動フェイルオーバー（1-2分）
ALB、ECSは自動的に正常なAZに振り分け

4-3. ネットワーク構成図（Network Diagram）

目的: 通信フロー、Security Group、ポート番号を理解する
対象者: インフラエンジニア、セキュリティエンジニア、アプリケーション開発者
特徴: Security Group、通信プロトコル、ポート番号を明示

4-3-1. 通信フロー図（Communication Flow）

各層の通信経路とポート番号を表現：

📋 通信フローの詳細：

ステップ	送信元	送信先	プロトコル:ポート	Security Group
①	ユーザー	IGW	HTTPS:443 / HTTP:80	-
②	IGW	Public ALB	ルーティング	SG: alb-public
③	Public ALB	ECS Front	HTTP:80	SG: ecs-front
④	ECS Front	Internal ALB	HTTP:80	SG: alb-internal
⑤	Internal ALB	ECS API	HTTP:8080	SG: ecs-api
⑥	ECS API	RDS	MySQL:3306	SG: rds

色の意味:

🔵 青系: ユーザー・Gateway（外部接続）
🟢 緑系: ALB（負荷分散）
🟠 オレンジ系: ECS（コンピュート）
🟣 紫系: RDS（データベース）

4-3-2. External通信（インターネット側）

目的: インターネットからFrontendまでの通信フローとSG設定

この図で分かること:

インターネットからの入口
Public ALBのSG設定（HTTPS/HTTP受付）
FrontendのSG設定（Public ALBからのみ受付）

🔑 External通信のポイント:

Public ALB: インターネット全体（0.0.0.0/0）からHTTPS/HTTP受付
ECS Frontend: Public ALBからのみHTTP:80受付（Security Group参照）
HTTPS終端: Public ALBでHTTPSを終端、内部はHTTP通信

色の意味:

🔴 赤系: Security Group（ファイアウォール）
🟢 緑系: AWSリソース（実体）
🔵 青系: 外部接続
🟡 黄系: ルール詳細

4-3-3. Internal通信（VPC内部）

目的: Frontend以降のVPC内部通信フローとSG設定

この図で分かること:

VPC内部の通信フロー（4段階）
各SGの詳細ルール
APIからAWSサービスへの外部通信

🔑 Internal通信のポイント:

Frontend → Internal ALB: Security Group参照で制御
Internal ALB → API: ポート変換（80 → 8080）
API → RDS: DB専用SGで完全隔離
API → AWS Services: ECR/Secrets Manager接続用のHTTPS:443

色の意味:

🔴 赤系: Security Group（ファイアウォール）
🟢 緑系: AWSリソース（実体）
🔵 青系: 外部接続
🟡 黄系: ルール詳細

4-3-4. Security Groupルール詳細表

目的: 各SGの具体的なInbound/Outboundルールを確認する

📥 Inbound Rules（インバウンド）

SG名	対象リソース	プロトコル	ポート	送信元	説明
alb-public	Public ALB	TCP	443	0.0.0.0/0	HTTPS（インターネット）
		TCP	80	0.0.0.0/0	HTTP（インターネット）
ecs-front	ECS Frontend	TCP	80	sg-alb-public	Public ALBからのみ
alb-internal	Internal ALB	TCP	80	sg-ecs-front	Frontendからのみ
ecs-api	ECS API	TCP	8080	sg-alb-internal	Internal ALBからのみ
rds	RDS MySQL	TCP	3306	sg-ecs-api	APIからのみ

📤 Outbound Rules（アウトバウンド）

SG名	対象リソース	プロトコル	ポート	宛先	説明
alb-public	Public ALB	TCP	80	sg-ecs-front	Frontendへ転送
ecs-front	ECS Frontend	TCP	80	sg-alb-internal	Internal ALBへ転送
alb-internal	Internal ALB	TCP	8080	sg-ecs-api	APIへ転送
ecs-api	ECS API	TCP	3306	sg-rds	RDSへクエリ
		TCP	443	0.0.0.0/0	ECR/Secrets接続
rds	RDS MySQL	-	-	なし	完全隔離

🔑 セキュリティ設計のポイント：

最小権限の原則
- 各SGは必要最小限の通信のみ許可
- 不要なポートは全てブロック
Security Group参照
- IPアドレスではなくSG IDで制御
- リソースのIPが変わっても影響なし
多層防御
- Public → Private → DB と段階的に制限
- RDSは完全隔離（APIからのみアクセス可）
外部通信の最小化
- API ServiceのみHTTPS:443を外部に許可（ECR、Secrets Manager用）
- それ以外は全てVPC内部通信

図と表の使い分け:

図（4-3-2, 4-3-3）: 全体像の把握、通信フローの理解
表（4-3-4）: 実装時の詳細確認、ルール漏れチェック

4-4. データフロー図（Data Flow Diagram）

目的: リクエスト/レスポンスの処理フローを時系列で理解する
対象者: アプリケーション開発者、QAエンジニア
特徴: シーケンス図でリクエストの流れを表現、時間軸順に番号付与

データフロー図は、シナリオ別に3つに分割しました：

デプロイ・起動フロー（初回起動時）
通常リクエストフロー（正常系）
エラーハンドリングフロー（異常系）

例：通常リクエストフロー（DB呼び出し）

レスポンス時間の内訳:

処理	時間	備考
IGW → ALB	~5ms	ネットワーク遅延
ALB → Front	~10ms	HTTP転送
Front → API	~20ms	内部ALB経由
API → RDS	~30ms	SQLクエリ実行
レスポンス返却	~10ms	逆経路
合計	~150ms

ポイント:

時間軸番号: ①②③で処理の順序が明確
レスポンス時間: 各処理の所要時間を記載
HTTPS終端: Public ALBでHTTPSを終端、内部はHTTP

この図を見れば、「リクエストがどう処理されるか」が時系列で分かります。

5. 次回予告

第2回: Phase 1-1 - VPC & Subnetの構築

次回は、構成図をもとに実際にTerraformでAWSリソースを構築していきます。

Phase 1-1で作成するもの:

VPC × 1
Subnet × 6（Public × 2、Private App × 2、Private DB × 2）
Internet Gateway × 1

Phase 1-1を完了すると、ネットワークの基盤が整います。

6. まとめ

この記事では、以下の4種類・7図を作成しました：

論理構成図: システム全体の俯瞰
配置構成図: Multi-AZ構成の理解
ネットワーク構成図:
- 通信フロー図
- External通信図
- Internal通信図
- SGルール詳細表
データフロー図: リクエスト処理の流れ

実務での使い分け:

設計初期: 論理構成図で全体像を共有
詳細設計: 配置構成図とネットワーク構成図で具体化
開発フェーズ: データフロー図でAPI仕様を明確化

次回から、この設計図をもとに実際にTerraformでインフラを構築していきます！

7. 参考リンク

AWS ECS ドキュメント
Terraform AWS Provider

（続く）