📚 GCP PCA 学習: 2026-06-03

セクション: 5.1 開発/運用チームへのアドバイス 前回からの繋がり: 信頼性運用の目標値（SLO・SLI・エラーバジェット）を定めたら、次はそれを実装・保守・改善するための「仕組み」を整える。これが IaC・構成管理・デプロイベストプラクティス。

① 一言サマリー

「IaC（Infrastructure as Code）とは、サーバーやネットワークを『手作業』ではなく『コード』で定義して管理する仕組みです」

② たとえ話

建築に例えると：

手作業での運用 = 大工がその場で判断しながら建てる（建て方がバラバラ、後から修正が複雑）

IaC = 設計図（コード）を先に作成して、誰が実行しても同じ建物が建つ仕組み

「コード化」の効果： - 再現性: 同じコードを実行すれば、環境は常に同じ状態 - バージョン管理: Git で過去のコンフィグに戻せる - テスト: デプロイ前にコードレビュー・検証ができる - スケーラビリティ: 手作業なしに 100 個のサーバーを同時構築

③ 図解

graph LR
    A["開発チーム
コード作成"] -->|Git Push| B["リポジトリ
Terraform / DM"]
    B -->|変更検証
Plan| C["レビュー
承認ゲート"]
    C -->|Apply| D["GCP リソース
自動構築"]
    D -->|監視| E["ドリフト検出
Config Mgmt"]
    E -->|不一致検出| F["アラート
自動修復"]
    F -->|Sync| D

IaC の流れ：Define（定義） → Version Control（版管理） → Plan（計画） → Apply（実行） → Monitor（監視） → Remediate（修復）

④ 仕組みの深掘り

IaC ツールの役割

Terraform（推奨・マルチクラウド対応） - 宣言型言語（HCL）で「目指すべき状態」を記述 - terraform plan で実行前に差分を確認 - terraform apply で実行、terraform destroy で削除 - State ファイル（.tfstate）で「現在の状態」を追跡 - 最大の利点: GCP / AWS / Azure 同時管理可能

Cloud Deployment Manager（GCP 特化） - YAML + Python/Jinja テンプレート - GCP サービス統合が深い - ただし学習曲線が高い、コミュニティが小さい - 新規プロジェクトには Terraform 推奨

ドリフト検出（Drift Detection）とは

ドリフト = コードと実環境の不一致

例：main.tf では Compute Engine インスタンスが 3 台なのに、誰かが手作業で 1 台削除した

GCP での実装： - Cloud Config Management: VM のコンフィグを定期確認、不一致時はアラート - Terraform State ファイルとの比較: terraform refresh で現在状態を再取得 - Policy as Code（Terraform Cloud）: デプロイ申請時に自動検証

なぜ重要？ - 本番環境がドキュメント（Terraform）と乖離すると、災害復旧時に再構築に失敗する - セキュリティ: ファイアウォールルールが勝手に変わっていても検出できない - コスト: 不要なリソースが残っていても気づかない

構成管理（Configuration Management）

全リソースの「一覧」と「状態」を統一的に把握する仕組み

GCP での実装： - Cloud Asset Inventory: 全プロジェクト・全リージョンのリソース一覧を 5 分ごとに自動スキャン - IAM バインディング、VPC、ストレージ、コンピュートを一元管理 - JSON フォーマットで BigQuery にエクスポート可能 - Terraform State: terraform state list で定義済みリソースを確認

実務での使い分け： - Cloud Asset Inventory = 「全体把握」（監査・コンプライアンス） - Terraform State = 「IaC で管理してる部分」（詳細な変更履歴）

⑤ 他サービスとの使い分け

graph LR
    A["インフラ管理方式"] -->|手作業| B["❌ 非推奨
スケーラビリティ×"]
    A -->|スクリプト
bash/gcloud| C["△ 検証段階
ドリフト対応×"]
    A -->|IaC
Terraform| D["✅ 本番推奨
再現性〇
バージョン管理〇"]
    A -->|IaC + CI-CD| E["🏆 最高峰
自動化・検証完全"]

PCA 試験の判定軸： - 「本番環境の再現性をどう確保するか」が問われる - IaC がなければ即×（「手作業では DHA は確保できない」が模範回答） - Terraform と Deployment Manager は同等の評価（GCP 特化は不要）

⑥ 実務への応用

シナリオ 1: Web アプリケーション本番運用（スタートアップ向け）

Day 0: Terraform で本番環境（GKE + Cloud SQL + Cloud CDN）を定義・構築
         → 12 時間で本番 Ready

Day 1-7: コード変更が発生
         → Terraform Plan で検証
         → CI-CD で自動テスト・適用
         → ブルーグリーンデプロイで無停止

Week 2: キャパシティ足りない
        → main.tf の GKE node_count を 5 → 10 に変更
        → terraform apply
        → 30 分で自動スケーリング完了
        → 手作業 0（従来なら 2-3 日待ちで外注）

シナリオ 2: マルチクラウド移行（大企業向け）

既存環境: AWS EC2 + RDS
新環境: GCP Compute Engine + Cloud SQL

Terraform コード:
  - AWS と GCP 両方の定義を 1 つのリポジトリで管理
  - 段階的に AWS リソースを減らし、GCP リソースを増やす
  - ロードバランサーで 90% GCP / 10% AWS に配分
  → 6 ヶ月で完全移行、ダウンタイム 0

シナリオ 3: 災害復旧（RPO/RTO 達成）

本番環境がダウン（リージョン障害）

Disaster Recovery フロー:
1. us-central1 の Terraform state を us-east1 にコピー
2. terraform apply -var="region=us-east1"
3. 10 分で完全に同じ環境が us-east1 に起動
   → RTO 10 分達成（手作業なら 2-3 日かかる）

⑦ よくある誤解・落とし穴

誤解 1: 「Terraform は初期段階の環境構築用」

現実: Terraform は「管理」のためのツール。本番環境こそ必須。

• 開発環境で Terraform を使わない → 本番で急に導入 → 既存環境との不整合
• 「既存環境は手作業、新機能は Terraform」は最悪パターン（ドリフト放置）
• 正解: Day 1 から全環境で IaC 統一

誤解 2: 「State ファイルをローカルに保存すれば大丈夫」

現実: State ファイルは「DB」。複数人で同時編集できず。

❌ ローカル保存パターン:
  - 開発者 A が terraform apply
  - 同時に開発者 B が terraform apply
  → State ファイル破損、環境が不整合

✅ 正解（Terraform Cloud / Google Cloud Storage 使用）:
  - 全チーム共有のリモート State
  - Lock 機構で同時実行を防止
  - 変更履歴を自動記録

PCA 試験: State ファイルの管理方法が問われるパターンあり

誤解 3: 「Plan ステップは不要、Apply で一気に実行」

現実: Plan ステップは「デプロイ前のコードレビュー」の命

❌ 危険: terraform apply
  → 何が変わるか事前に分からない
  → 本番で critical なリソースを削除してしまう

✅ 正解: 3 段階制御
  1. terraform plan → 差分レポート生成
  2. レビュー・承認（変更管理ゲート）
  3. terraform apply → 承認済みの変更のみ実行

法令遵守（Section 3.2）との連携: 監査ログに「誰が・いつ・何を承認したか」を記録

誤解 4: 「構成管理は Cloud Asset Inventory だけで十分」

現実: Asset Inventory は「スナップショット」、Terraform は「意図の宣言」

• Asset Inventory = 「今の環境はこういう状態」（読み取り専用）
• Terraform = 「環境はこうあるべき」（目指す状態・管理可能）
• 組み合わせ: 定期スキャンで Terraform State との差分検出 → ドリフト自動修復

誤解 5: 「Terraform は万能。手作業は不要」

現実: Terraform では定義できない設定がある。

例： - Application コンテナの起動スクリプト → Cloud Build + Container Registry - Kubernetes manifest（YAML）の詳細設定 → Helm + Kustomize - 既存オンプレミスリソースとの統合 → 手作業 + VPN 設定

正解: 「IaC で 90%、その他の 10% はスクリプト + ドキュメント」がバランス

⑧ 理解度チェック

シナリオ:

「スタートアップが Compute Engine（3 台）+ Cloud SQL（本番）を GCP に移行した。現在、チーム内で環境構成がバラバラで、『誰が何をしたのか』が不明。また、新しいサーバーを追加するとき、毎回セットアップに 3-4 日かかる。

SLA 99.9%（月 43 分ダウンタイム許容）を達成するため、開発チームにアドバイスするなら？」

• (A) 全チームを Google Cloud Console でトレーニング。手作業スキルを高める。
• (B) Terraform で Compute Engine + Cloud SQL をコード化。Git で版管理。本番環境を IaC で統一。
• (C) Cloud Logging・Cloud Monitoring を導入。リアルタイム監視で問題を素早く検出。
• (D) Migrate for Compute Engine で既存環境を自動分析。最適な構成を提示。

⑨ 深掘り補足（最新 GA 機能）

最新リリース：MIG Bulk Mode（Compute Engine）- GA

2026-06-01 GA：Managed Instance Group（MIG）で Bulk Mode が一般提供開始。

仕組み： - 通常の MIG：target_size: 10 → 1 台ずつ起動。スケールアップに 10-15 分 - Bulk Mode：target_size: 10 → 10 台を並列に起動。スケールアップに 2-3 分

# Terraform 例
resource "google_compute_instance_group_manager" "hpc_cluster" {
  name              = "hpc-mig"
  instance_template = google_compute_instance_template.compute.id
  target_size       = 100

  update_policy {
    type = "PROACTIVE"
  }

  # Bulk Mode 有効化（新規）
  all_instances_config {
    properties {
      mode = "BULK"  # 全 100 台を並列起動
    }
  }
}

適用場面： - HPC（高性能計算）: 100-1000 ノードのバッチジョブを秒単位でスケーリング - バッチ処理: Deep Learning 分散訓練で全 GPU ノード同時起動 - スパイク対応: トラフィック急増時に一気にキャパシティ拡張

注意： - Bulk Mode は全リソースを同時起動するため、リージョンのクォータ上限に達しやすい - GCP サポートに「Bulk Mode 用のクォータ引き上げ」を事前申請推奨

次回: 5.2 GCP SDK を使った Google Cloud との連携（gcloud / gsutil / bq コマンド）