Infrastructure Manager

解決する課題

インフラを Terraform で宣言的に管理したいが、CI 実行環境の用意・状態ファイル（tfstate）の保管・ロック・権限管理といった「Terraform を動かす土台」の運用が重荷になります。Infrastructure Manager はこの土台をマネージドに引き受けます。

• Terraform の**実行環境（ランナー）**を自前で用意・保守したくない
• 状態ファイルの保管・ロック・暗号化を安全に任せたい
• どのデプロイがいつ・誰の権限で適用されたかを Google Cloud 上で一元的に追跡したい
• IaC を Google Cloud のネイティブな API・IAM・監査ログと統合して運用したい

主要概念と用語

• デプロイ（Deployment）: 管理対象のインフラを束ねる単位。1 つの Terraform 構成に対応し、作成・更新・削除のライフサイクルを持つ
• リビジョン（Revision）: デプロイを適用するたびに作られる履歴。各リビジョンに適用された構成と結果が紐づき、変更の追跡やロールバックの判断に使う
• Terraform 構成（設定）: HCL で書いたインフラ定義。Cloud Storage 上のオブジェクトや Git リポジトリ（ブランチ・ディレクトリ指定）から参照できる
• サービスアカウント: デプロイ実行時に Infrastructure Manager が引き受ける ID。このアカウントの IAM 権限の範囲でリソースが作成・変更される
• 状態ファイル（tfstate）: Terraform が管理する現状の記録。Infrastructure Manager がマネージドに保管し、利用者がバックエンドを構成する必要がない
• プレビュー（Preview）: 実際に適用する前に変更内容を試算する操作。Terraform の plan に相当し、差分を事前確認できる
• 入力変数（input values）: 構成に渡すパラメータ。環境ごとの差分（リージョンやサイズ）を変数で切り替える

仕様・制限・クォータ

• エンジンは Terraform: 独自 DSL ではなく標準の HCL を使うため、既存の Terraform 資産やモジュールを流用しやすい
• 構成ソース: Cloud Storage のオブジェクト、または Git リポジトリ（ブランチ／ディレクトリ／コミットの指定）を入力にできる
• リージョン: デプロイは特定のリージョンで作成・管理する。利用可能なリージョンは公式ドキュメントを参照する
• 状態管理はマネージド: tfstate のバックエンド設定は不要で、ロックや保管をサービス側が担う
• サポートされる Terraform バージョン: 利用できるバージョンには範囲があり、構成側で指定する。具体的な対応版は公式情報で確認する
• クォータ: デプロイ数や同時実行などにプロジェクト単位の上限があり、必要に応じて引き上げ申請が可能

内部の仕組み

Infrastructure Manager は、利用者の Terraform 構成をマネージドな実行環境で plan と apply 相当の処理として実行します。実行はデプロイで指定したサービスアカウントの権限で行われ、生成・変更されたリソースの状態はマネージドな tfstateとして保管されます。

• 構成ソース（Cloud Storage または Git）を取得し、指定された Terraform バージョンで処理する
• 適用のたびにリビジョンが記録され、各リビジョンに構成・入力変数・実行結果が紐づく
• 実行は内部的に Cloud Build などの実行基盤を利用し、ログを通じて適用過程を追跡できる
• API 呼び出しや適用操作は Cloud Audit Logs に記録され、誰がいつどのデプロイを操作したかを監査できる

設計パターン / ベストプラクティス

• 構成は Git リポジトリで管理し、ブランチ／ディレクトリ指定でデプロイと結びつける（変更履歴とレビューを Git に寄せる）
• 実行用サービスアカウントは最小権限にし、デプロイが触る範囲のリソース権限だけを付与する
• 環境（本番／検証）ごとにデプロイと入力変数を分離し、同じ構成をパラメータで切り替える
• 適用前に必ず**プレビュー（plan 相当）**で差分を確認し、想定外の削除や置換を検知する
• モジュールを再利用して構成を DRY に保ち、共通部品はバージョン管理されたモジュールとして切り出す

運用・監視

• デプロイの**状態（適用中・成功・失敗）**とリビジョン履歴を確認し、失敗時は実行ログから原因を追う
• 適用が失敗する場合は、まず実行用サービスアカウントの IAM 権限の不足を疑う
• 操作は Cloud Audit Logs（Admin Activity／Data Access）に記録されるため、変更の追跡と棚卸しに使う
• 構成ドリフト（手動変更による実態とのずれ）が疑われる場合は、プレビューで差分を出して把握する
• 不要になったデプロイは削除し、管理対象とサービスアカウント権限を整理する

コスト

Infrastructure Manager 自体の利用に対する課金の考え方と、デプロイによって作成された Google Cloud リソースの課金は分けて捉えるのが基本です。実行に内部基盤（Cloud Build など）や状態保管のストレージを利用するため、これらの費用も発生し得ます。

セキュリティ

• 実行用サービスアカウントの権限が、そのデプロイの作用範囲の上限になる。広すぎる権限を与えない
• デプロイの作成・更新・削除を IAM で制御し、本番デプロイを操作できる主体を限定する
• 構成ソースの Cloud Storage バケットや Git リポジトリへのアクセスも保護し、改ざんを防ぐ
• 操作は Cloud Audit Logs で監査し、誰がどのデプロイを変更したかを追跡できるようにする
• 機密値は構成へ直書きせず、Secret Manager 等を参照する形にして平文の散在を避ける

Well-Architected の観点

• 運用上の優秀性（operational）: インフラを宣言的にコード化し、Git でレビューと履歴管理を行うことで、手作業の構成変更を排除して再現性を高める。プレビューで変更を事前確認する習慣が運用事故を減らす
• 信頼性（reliability）: マネージドな状態管理とリビジョン履歴により、構成のロールバック判断やドリフト検知がしやすくなる。環境ごとにデプロイを分離することで本番への影響範囲を限定できる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 必要な API を有効化
gcloud services enable config.googleapis.com

# Cloud Storage 上の Terraform 構成からデプロイを作成
# 実行は指定したサービスアカウントの権限で行われる
gcloud infra-manager deployments apply projects/PROJECT_ID/locations/asia-northeast1/deployments/web-stack \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-mgr@PROJECT_ID.iam.gserviceaccount.com \
  --gcs-source gs://my-iac-bucket/web-stack \
  --input-values region=asia-northeast1,instance_count=2

# Git リポジトリのブランチ・ディレクトリを構成ソースに指定する例
gcloud infra-manager deployments apply projects/PROJECT_ID/locations/asia-northeast1/deployments/web-stack \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-mgr@PROJECT_ID.iam.gserviceaccount.com \
  --git-source-repo https://source.example.com/org/iac-repo \
  --git-source-directory web-stack \
  --git-source-ref main

# デプロイの状態とリビジョン履歴を確認
gcloud infra-manager deployments describe projects/PROJECT_ID/locations/asia-northeast1/deployments/web-stack
gcloud infra-manager revisions list --deployment projects/PROJECT_ID/locations/asia-northeast1/deployments/web-stack

# 不要になったデプロイを削除（作成したリソースも破棄される）
gcloud infra-manager deployments delete projects/PROJECT_ID/locations/asia-northeast1/deployments/web-stack