Terraformの深淵：`for_each`と`dynamic`ブロックによる「メタプログラミング」の極致
Terraformを単なる「リソース定義言語」だと思っているなら、今すぐその認識を捨てろ。大規模インフラの現場において、Terraformは「宣言的メタプログラミング」のツールだ。
`count`で満足しているジュニアエンジニアを尻目に、我々シニアはリソースのライフサイクルをコードで完全に支配する。今日は、複雑なJSON構造からインフラを自在に錬成する、`for_each`と`dynamic`ブロックの深淵を解剖する。
—
1. なぜ `count` を捨て、 `for_each` に魂を売るべきなのか
`count` はインデックス（0, 1, 2…）に依存する。リストの途中で要素を削除した瞬間、Terraformは全リソースの再構築という悪夢（Index Shift）を引き起こす。
対して `for_each` は「キー（文字列）」を識別子にする。これにより、たとえ設定の順序が変わろうとも、Terraformは変更差分のみをピンポイントで適用する。「冪等性の保証」とは、インフラの変更を「破壊」ではなく「遷移」として制御することにある。
究極のDRY：複雑なMAP構造の展開
単なるキー・バリューではない。実務ではネストされたJSONを扱う機会が多いはずだ。
locals {
# 複雑なプロジェクト構成をJSONライクなlocalsで定義
environments = {
prod = {
instance_type = “c6g.xlarge”
tags = { Env = “Production”, Tier = “Critical” }
}
staging = {
instance_type = “t3.medium”
tags = { Env = “Staging”, Tier = “Dev” }
}
}
}
resource “aws_instance” “app” {
for_each = local.environments
ami = data.aws_ami.amazon_linux.id
instance_type = each.value.instance_type
tags = merge(each.value.tags, { Name = “App-${each.key}” })
}
—
2. `dynamic` ブロック：リソース内の「再帰的な制御」
リソース設定の中で、サブプロパティが可変長になるケース（`ingress`ルールや`network_interface`など）で `dynamic` ブロックを使わずにベタ書きしているコードを見ると、私は絶望する。
悪用厳禁、しかし最強：ネストされたDynamic
`dynamic` はネストできる。これを利用すれば、複雑なWAFのルールやIAMポリシーの生成を、外部JSONファイルから完全に自動化できる。
resource “aws_security_group” “dynamic_sg” {
# ルール定義を外部JSONから読み込む想定
dynamic “ingress” {
for_each = var.ingress_rules # ルールリストを回す
content {
from_port = ingress.value.port
to_port = ingress.value.port
protocol = “tcp”
cidr_blocks = ingress.value.cidrs
}
}
}
—
3. 実践：Terraform内部アーキテクチャを意識した最適化ハック
ここで少しレイヤを下げよう。Terraformのステート（`terraform.tfstate`）は、実行のたびにメモリへ展開され、グラフ構造として解釈される。
① パフォーマンスの最適化：Graphの爆発を防ぐ
`for_each` を過度にネストし、数千のリソースを単一のモジュールで管理すると、Terraformのプランニングフェーズでメモリが枯渇する。
- 対策: リソースの規模が大きい場合、`terraform graph` を定期的に実行し、依存関係がスパゲッティ化していないか可視化せよ。依存の連鎖が深すぎる場合は、モジュールを分割し、`terragrunt` 等で疎結合に制御するのが現場の鉄則だ。
② 外部スクリプトとの協奏：`external` データソースの限界を突破する
`for_each` に渡す複雑な動的データは、`external` データソースを使ってCLIを叩くのが定石だ。
独自管理しているDBのメタデータをAPI経由で取得し、Terraformに流し込む
data “external” “db_config” {
program = [“python3”, “${path.module}/scripts/get_db_meta.py”]
}
resource “aws_db_instance” “dynamic_db” {
for_each = data.external.db_config.result
# …
}
注意: `external` は実行のたびにスクリプトを走らせるため、冪等性を汚染しやすい。必ずキャッシュ機構をスクリプト側に持たせること。
—
4. 伝説的エンジニアからの「極限の知見」
最後に、コードの可読性を保つための「シニアの嗜み」を授ける。
1. `flatten` 関数を愛せ: 複雑なネスト構造を、`for_each` が扱いやすいフラットなリストに変換するには `flatten` が不可欠だ。これを使わずに複雑なループを書くのは愚行である。
2. `try` と `can` で防御的プログラミングを: 動的な設定値には常にnullのリスクが伴う。`can()` を活用し、値が存在しない場合のデフォルト値を `coalesce()` で吸収せよ。
3. モジュール化の誘惑に負けるな: 「何でもかんでもモジュール化」はコードをブラックボックス化する。`dynamic` ブロックを駆使して「宣言的な設定」をリソース定義の直近に置くことで、保守性は劇的に向上する。
結論
Terraformをマスターするとは、「インフラの変化をデータ構造として定義し、再帰的に適用するアルゴリズム」を書くことと同義だ。
`for_each` と `dynamic` を使いこなす者は、もはや単なるオペレーターではない。インフラという巨大なシステムを「コードという言語」で統治するアーキテクトだ。さあ、今すぐ君のコードから `count` を全廃し、より洗練された抽象化へと昇華させてくれ。
それが、現代のSREが備えるべき唯一の正義だ。