Terraformの大規模運用における「ディレクトリ構造」の深淵：Workspacesはなぜ罠なのか
クラウドインフラをコードで定義する際、我々SREが直面する最大の壁は「環境間の差異」と「状態（State）の分離」だ。多くの初心者がTerraformの`workspaces`機能に魅了されるが、大規模・高信頼性が求められるプロダクション環境において、それは「時限爆弾」となり得る。
今日は、数千のリソースが蠢くエンタープライズ環境で、私がなぜディレクトリ分離を強く推奨するのか、そしてその先にある「完全自動化の極致」について語ろう。
—
1. Terraform Workspacesの「甘い罠」
TerraformのWorkspacesは、単一のバックエンド構成の中で状態ファイルを切り替えるための機能だ。しかし、以下の理由により大規模環境では即座に廃止すべきである。
- Stateの共有リスク: 誤操作により、別環境のStateを破壊するリスクが常につきまとう。
- コードの複雑化: `terraform.workspace` を利用した条件分岐（`count`や`for_each`の乱用）が増え、コードが「スパゲッティ化」する。
- 権限分離の不可能: ひとつのStateファイルに環境が混在するため、IAMによるStateロックの粒度を環境別に制御できない。
結論： Workspacesは、小規模なプロトタイプや個人プロジェクトの遊び場だ。ビジネスの基盤を預けるなら、物理的なディレクトリ分離こそが唯一の正解である。
—
2. 推奨ディレクトリ構造：モジュール依存の完全制御
私が採用しているのは、以下の「環境駆動型ディレクトリ構造」だ。
.
├── modules/ # 再利用可能な純粋なリソース定義
│ ├── vpc/
│ └── eks/
├── environments/ # 環境ごとのライブ設定（Terragrunt推奨）
│ ├── prod/
│ │ ├── us-east-1/
│ │ │ └── eks/
│ │ │ └── terragrunt.hcl
│ └── stg/
なぜこの構造か？
- Blast Radius（影響範囲）の最小化: `prod`に影響を与えず、`stg`のみをPlan/Applyできる。
- Stateの物理的分離: S3バケット上のパスが完全に分離され、S3のPrefix単位でIAM権限を絞り込める。
- バージョニングの徹底: `source = “../../modules/vpc?ref=v1.2.0″` のように、モジュールのバージョンを明示的に固定することで、環境ごとのリリースラグを安全に管理できる。
—
3. 次世代の運用：TerragruntによるDRYと自動化の極致
ディレクトリを分けると「コードの重複」が課題になる。ここで登場するのがTerragruntだ。これはTerraformのラッパーではなく、Terraformが本来持つべき「構成管理の論理層」を補完する至高のツールである。
TerragruntによるState管理の自動化ハック
個別の `backend.tf` を手書きするのは2010年代のやり方だ。Terragruntを使えば、ルートの `terragrunt.hcl` でState設定を一元管理し、子ディレクトリで自動生成させる。
root terragrunt.hcl
remote_state {
backend = “s3”
generate = {
path = “backend.tf”
if_exists = “overwrite”
}
config = {
bucket = “my-terraform-state-${get_aws_account_id()}”
key = “${path_relative_to_include()}/terraform.tfstate”
region = “ap-northeast-1”
encrypt = true
dynamodb_table = “terraform-lock”
}
}
これにより、新規環境を立ち上げる際、State設定をコピー＆ペーストする必要は一切なくなる。
—
4. パフォーマンスと信頼性を突き詰める：エキスパートのハック
1. `terraform-graph` との対話
大規模な依存関係を持つインフラでは、`terraform plan` がメモリを食いつぶす。私はCI/CDパイプラインにおいて、`TF_LOG=DEBUG` を活用しつつ、特定のモジュールのみをターゲットにするよう `–target` を賢く使う（ただし、これは最後の手段だ。基本は依存関係の解消を目指すべき）。
2. APIを用いた独自自動化
CLIに頼らず、Terraform CloudのAPIや、GitHub Actionsの出力をJSONでパースし、プルリクエストに「コスト変動予測」や「リソース変更差分」を自動コメントするボットを構築せよ。
現場で使われるCI用の最適化コマンド例
terraform plan -json | jq -r ‘.resource_changes | map(select(.change.actions[] != “no-op”)) | length’ > change_count.txt
変更数が多すぎる場合はパイプラインを止めるガードレールを仕込む
3. Stateファイルのロック競合回避
DynamoDBのロックテーブルの書き込み容量（WCU）がボトルネックになるケースがある。大規模開発ではDynamoDBの読み書き容量をオンデマンドモードに設定し、秒間数百回のAPIコールにも耐えうる設計にしておくこと。
—
最後に：インフラエンジニアの矜持
ツールを使いこなすのではない。ツールに「どうあるべきか」を強制させるのだ。
ディレクトリ構造を物理的に分離し、TerragruntでDRYを徹底し、CI/CDで人間を排除する。このサイクルを完成させたとき、インフラは「構築するもの」から「自律的に最適化されるシステム」へと進化する。
次にTerraformのコードを書くとき、その一行が「三年後の自分」を助けるものかどうか、自問自答してほしい。その設計思想こそが、伝説を創る第一歩となる。