モジュール化と環境分離｜クラウドインフラ

🎓 レベル：発展　|　重要度：B（推奨）

📎 前提：Terraformの基礎（HCL・state）　|　関連：構成管理とImmutable Infrastructure・GitOpsと自動化

要点（BLUF）

モジュール＝再利用できる構成の部品。「Webサービス一式（VM＋LB＋NW）」をモジュール化し、変数で差し替えて何度も使う。コードのDRY化。
環境分離（dev/stg/prod）は state を分けるのが基本。同じモジュールに違う変数を渡し、別々のstateで管理して、本番と検証が混ざらないようにする。
規模が増えるほど「変更の爆発半径（blast radius）を小さく」が効く。state・モジュール・権限を分割して、事故の影響を局所化する。

概念 ── 部品化と作り分け

小さなうちは1ファイルでも回りますが、資源が増え環境が増えると破綻します。解決は2方向。

縦の分割（モジュール）：機能のまとまりを部品化。「ネットワーク」「データベース」「Webサービス」をモジュールにし、組み合わせる。
横の分割（環境）：dev/stg/prod を別々のstateで持ち、同じモジュールに環境ごとの変数を渡す。

flowchart TB
    mod["モジュール: web-service（VM＋LB＋NWの一式）"]
    mod -->|"変数: size=small, count=1"| dev["dev 環境（state-dev）"]
    mod -->|"変数: size=large, count=3"| prod["prod 環境（state-prod）"]

仕組み ── モジュールと変数

# modules/web-service/main.tf （部品の定義）
variable "instance_count" { type = number }
variable "machine_type"   { type = string }

resource "cloud_instance" "web" {
  count        = var.instance_count
  machine_type = var.machine_type
  name         = "web-${count.index}"
}

output "instance_ids" {
  value = cloud_instance.web[*].id
}

# environments/prod/main.tf （部品を呼び出す）
module "web" {
  source         = "../../modules/web-service"
  instance_count = 3          # prod は3台
  machine_type   = "large"
}

# environments/dev/main.tf
module "web" {
  source         = "../../modules/web-service"
  instance_count = 1          # dev は1台
  machine_type   = "small"
}

dev と prod は同じモジュール（同じ作り）に違う変数を渡すだけ。「dev で動いた構成が prod でも同じ形」になり、環境差バグが減ります（再現性＝IaCとは・宣言的構成）。

仕組み ── state 分離と blast radius

環境ごと・コンポーネントごとに state を分けると、apply の影響範囲（爆発半径）が小さくなります。「ネットワークの変更で誤ってDBまで再作成」を防げる。

flowchart LR
    subgraph small["分割されたstate（影響が局所）"]
      s1["network/state"]
      s2["database/state"]
      s3["web/state"]
    end
    note["1つのapplyが触るのは1つのstateだけ → 事故が広がらない"]

なぜ分割するのか

再利用と一貫性のため：モジュールで「正しい作り」を1か所に集約。各環境がそれを使うので、設定のばらつきが消える。
事故の局所化のため：state を分ければ、誤操作・障害の影響が1コンポーネント/1環境に留まる。本番全体を巻き込まない。
権限分離のため：環境ごとに state とクレデンシャルを分ければ、dev の事故が prod に波及しない。最小権限（責任共有モデルとリージョン/AZ）の延長。

⚠️ よくある誤解・落とし穴

「全環境を1つのstateに」→ dev の apply が prod を巻き込む危険。環境ごとにstate分離。
「モジュールを作り込みすぎ」→ 変数が膨大で読めない「神モジュール」に。1モジュール1責務、適度な粒度で。
「dev と prod でコードを別々に手書き」→ ドリフトの温床。同一モジュール＋変数差で揃える。
「count/for_each の付け外しで全再作成」→ インデックス変更が destroy/recreate を誘発。plan で差分を必ず確認。
「リモートstateのロック未設定」→ 複数人の同時 apply でstate破損（Terraformの基礎（HCL・state））。ロック必須。

対応ラボ

なし（設計トピック）。最小モジュール構成の雛形は Terraformの基礎（HCL・state）のローカルラボを modules/ に切り出して拡張すると体験できる。