この記事について
| 記事 | タイトル | 状態 |
|---|---|---|
| 第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. 参考リンク
（続く）