1. この記事について（6回シリーズ）
実務寄りの自己学習を考えたシリーズの第1弾です。
| 記事 | タイトル | 内容 |
|---|---|---|
| 第1弾 | 設計思考編 | なぜ設計が先なのか |
| 第2弾 | 図解編 | 構成図・フロー図・シーケンス図 |
| 第3弾 | パラメータ設計編 | Terraformパラメータ設計 |
| 第4弾 | Terraform実装編 | コード作成からplan成功まで |
| 第5-1弾 | 実装編 | apply〜アクセス確認 |
| 第5-2弾 | 運用・削除編 | トラブルシューティング〜destroy |
📁 完全なコードはGitHubで公開：GitHub: fargate-iac01
2. はじめに
2-1. AWSで「とりあえずGUIでポチポチ」に疑問
① 動画を見る
② AWS Management Consoleを開く
③ 指示通りにクリック
④ 「できた！」
実務寄りの方法ではないのでは？
2-2. 目指すこと
| キーワード | 説明 |
|---|---|
| ✅ 実務の設計思考 | インフラエンジニアの考え方 |
| ✅ 学習の違和感の正体 | なぜGUIから始めるとダメなのか |
| ✅ 正しい学習フロー | 設計7割、実装3割の意味 |
| ✅ 料理などの比喩 | 直感的に理解できる説明 |
3. なぜGUI操作から始めない？
| GUI問題点？ | 説明 |
|---|---|
| ❌ 全体像が見えない | 「なぜこのVPC CIDRなのか」がわからない |
| ❌ クリック作業員になる | 指示通りに操作するだけ |
| ❌ 応用が効かない | 別の案件で何も作れない |
| ❌ Terraform化が難しい | 後からIaCに移行できない |
4. 実務での設計フロー
4-1. 設計7割、実装2割、テスト1割
| フェーズ | 時間配分 | 内容 |
|---|---|---|
| 設計 | 70% | 要件整理、構成図、パラメータ決定 |
| 実装 | 20% | Terraform/GUI操作 |
| テスト | 10% | 疎通確認、動作確認 |
ポイント:
設計をしっかり行うことで、実装とテストがスムーズになります。
「実装してから考える」と、手戻りが発生してしまう。
5. 実務的な設計フロー
5-1. 今回は8ステップですすめます
| STEP | 工程 | 料理の例え | 記事 |
|---|---|---|---|
| 1 | グランドデザイン | 何人分？どんな味？ | 第1弾 |
| 2-5 | 可視化（図の作成） | キッチン図面、動線図 | 第2弾 |
| 6 | パラメータ設計 | 食材の分量表 | 第3弾 |
| 7 | IaC設計 | レシピの章立て | 第3弾 |
| 8 | 実装・テスト | 実際の調理と味見 | 第4弾〜第5-2弾 |
ポイント:
- STEP 2-5は第2弾でまとめて扱います（基本構成図、詳細構成図、フロー図、シーケンス図）
- STEP 6-7は第3弾でまとめて扱います（パラメータ表とファイル構成）
- STEP 8は第4弾〜第5-2弾の3記事で扱います（plan → apply → トラブルシューティング）
5-2. この順番の理由
| 理由 | 説明 |
|---|---|
| ✅ 後戻りを防ぐ | 実装してから「CIDR間違えた」は遅い |
| ✅ レビューしやすい | 図とパラメータ表でレビュー |
| ✅ 再利用できる | 設計があれば他の案件に転用可能 |
| ✅ チーム共有 | 「なぜこうした」が明確 |
5-3. 今回の題材：Apache on Fargate構成
このシリーズでは、
ApacheコンテナをFargateで公開する構成を題材に、実務的な設計フローを考えていきます。
構成の特徴:
- 最小限の構成（学習用）
- Public Subnetのみ（冗長化なし）
- HTTP（80番ポート）のみ公開
5-3-1. 構成の概要
☁️ インターネット
↓
🌐 Internet Gateway
↓
🏢 VPC (10.0.0.0/16)
↓
📁 Public Subnet (10.0.1.0/24、ap-northeast-1a)
↓
⚡ ECS Fargate
- Apache httpd:2.4
- CPU: 256 (.25 vCPU)
- Memory: 512MB
←
📦 ECR Repository (apache-repo)
主要コンポーネント:
- VPC: 独立したネットワーク空間（10.0.0.0/16）
- Public Subnet: インターネットからアクセス可能（10.0.1.0/24）
- ECS Fargate: サーバーレスでコンテナを実行
- ECR: Dockerイメージを保管
5-3-2. Fargateとは？
| 項目 | 説明 |
|---|---|
| ECS | AWSのコンテナ管理サービス |
| Fargate | サーバーレスでコンテナを実行 |
| メリット | サーバー管理不要、スケーラブル |
料理で例えると：
「自分で調理器具を準備する（EC2）」ではなく、「レンタルキッチンで調理（Fargate）」
6. 実践例：グランドデザイン（要件整理）
ここからは、実際に8ステップの「STEP 1: グランドデザイン」を体験してみましょう。
設計の第一歩は、要件を明確にすることです。
6-1. 今回の要件
| 項目 | 内容 |
|---|---|
| 目的 | Apacheコンテナをインターネット公開 |
| 利用サービス | ECS Fargate / ECR / VPC |
| アクセス元 | インターネット（不特定多数） |
| 稼働要件 | 学習用（1タスクのみ） |
| コスト | 最小限（無料枠内） |
| セキュリティ | HTTP（80番）のみ許可 |
6-2. 設計方針の決定
要件から、設計方針を決めます。
| 項目 | 選択 | 理由 |
|---|---|---|
| VPC | 新規作成（10.0.0.0/16） | 学習用の独立環境 |
| サブネット | Public × 1（1AZ） | 最小構成（冗長化不要） |
| 起動タイプ | Fargate | サーバーレス |
| CPU/メモリ | 256/512 | 最小スペック |
6-3. 料理で例えると
| 要件 | 料理の例え |
|---|---|
| 目的 | 「カレーを作る」 |
| 人数 | 「1人分」 |
| 味 | 「辛口」 |
| 予算 | 「500円以内」 |
これが決まってから、食材や調理器具を選びます。
7. なぜこれが重要なのか？
7-1. 実務での「あるある」
| シーン | 設計なしの場合 | 設計ありの場合 |
|---|---|---|
| レビュー時 | 「なんでこのCIDR？」→ 答えられない | 要件から説明できる |
| トラブル時 | どこが原因かわからない | フロー図で切り分け |
| 引き継ぎ時 | 「よくわからないけど動いてる」 | ドキュメントで説明 |
| 別案件 | ゼロから作り直し | 設計を流用できる |
7-2. GUI操作だけの危険性
「VPC作成」→ 「CIDR？とりあえず10.0.0.0/16」
「Subnet作成」→ 「Public？Private？とりあえずPublic」
「Security Group」→ 「ポート？とりあえず全部開けとく」
これでは、セキュリティリスクや後からの修正不可につながります。
8. まとめ
8-1. この記事で学んだこと
| 項目 | 内容 |
|---|---|
| ✅ GUI中心学習の問題点 | クリック作業員になる |
| ✅ 実務の設計フロー | 設計7割、実装2割、テスト1割 |
| ✅ 8ステップの全体像 | GD → 構成図 → パラメータ → IaC |
| ✅ グランドデザインの重要性 | 要件を明確にする |
8-2. 実務で活きる場面
この設計思考は、以下のような場面で活きます：
- 新規案件の要件定義・設計フェーズ
- 既存環境のリファクタリング
- チームでの設計レビュー
- IaC（Terraform）への移行
9. 次の記事へ
第2弾では、4種類の図の使い分けを学びます。
| 図の種類 | 目的 | いつ使うか |
|---|---|---|
| 基本構成図 | 全体像の把握 | 設計初期、チーム共有 |
| 詳細構成図 | 技術要素の詳細化 | 実装前、レビュー時 |
| フロー図 | データの経路 | トラブルシューティング |
| シーケンス図 | 時系列処理 | 処理順序の確認 |
実際にMermaidで図を描きながら、「なぜこの図が必要なのか」を理解していきましょう。
10. 参考リンク
（次回へ続く）