Terraformの「データソース地獄」を脱却せよ：大規模インフラを高速化する極限の最適化戦略
現場でTerraformを叩いている諸君、`terraform plan` を実行してコーヒーを淹れに行けるほど待たされる経験はないか？
データソース（`data`）は便利だ。しかし、その甘美な利便性の裏側には、「実行のたびにAPIを叩きに行く」という設計上の罠が潜んでいる。数百のリソースを管理する環境で、ループ処理の中にデータソースを投げ込むようなコードを書けば、計画実行は指数関数的に遅延する。
今日は、大規模インフラを「爆速」で回し、IaCの生産性を極限まで高めるための技術的ブレイクスルーを伝授する。
—
1. なぜ「データソース」はパフォーマンスを殺すのか？
Terraformのデータソースは、実行プランの計算フェーズで対象のリソースを読み込む。問題は、Terraformがこれらを並列実行しようと試みるが、API制限（Rate Limiting）に抵触したり、依存関係の連鎖によってボトルネックが発生することだ。
特に、`count` や `for_each` 内でデータソースを多用すると、Terraformのグラフ構築コストが爆発する。これが「Planに5分かかる」という現象の正体だ。
解決の鉄則
- 「動的な参照」を「静的な変数」へ引き剥がす: 可能であれば、データソースではなく `tfvars` や `remote state` を活用せよ。
- 依存関係を断ち切る: `depends_on` の安易な使用はグラフを複雑化させる。必要な属性のみを抽出した `local` 変数を活用し、計算量を減らせ。
—
2. 依存関係の連鎖を防ぐ：ローカル変数によるキャッシュ戦略
Terraformには公式なキャッシュ機能は存在しないが、「ローカル変数による集約」で擬似的なキャッシュを実現できる。
アンチパターン
ループ内で直接データソースを叩く（最悪の例）
resource “aws_instance” “app” {
for_each = var.instance_names
ami = data.aws_ami.latest[each.key].id # ここで毎回APIが飛ぶ
}
推奨プラクティス：データの一元化
事前に必要なデータを一度だけ取得し、ローカル変数にマップする
data “aws_ami” “base” {
# …フィルタリング設定…
}
locals {
# 一度の呼び出しで全データをメモリ上のマップに変換する
ami_map = { for ami in data.aws_ami.base : ami.name => ami.id }
}
resource “aws_instance” “app” {
for_each = var.instance_names
ami = local.ami_map[each.key] # メモリ上のマップを参照するだけ（爆速）
}
—
3. 大量リソース取得の最適化：フィルタリングの極意
数千のタグやリソースを走査する場合、`filter` を活用してAPIレスポンスのペイロードを最小化せよ。
- APIレスポンスを絞る: `data` ブロック内で `most_recent = true` や精密な `filter` を行い、Terraformが保持する状態量を減らす。
- DataSourceの分割: `data.tf` を肥大化させず、機能ごとに分割せよ。Terraformはファイル単位で読み込むため、不要なデータソースの評価を回避できる。
—
4. プロの現場で差がつく「必須の神設定」とツール群
開発スピードを底上げするツール
1. `tflint`: 絶対に入れろ。AWSプラグインを導入し、`terraform plan` 前に静的解析でリソースの整合性を確認する。
2. `infracost`: コストの可視化はもはや必須。CIに組み込み、「このPlanでいくらかかるか」をPR上で明示させる。
3. VS Code 拡張: `HashiCorp Terraform` は必須だが、さらに `Error Lens` を入れることで、構文エラーをリアルタイムで視覚化できる。
チーム開発のベストプラクティス
YAMLでリソース定義を管理し、Terraform側で `yamldecode()` する構成が最も拡張性が高い。
config.yaml (構成管理ファイル)
instances:
web-01: { size: “t3.medium”, env: “prod” }
web-02: { size: “t3.medium”, env: “prod” }
main.tf (ロジック)
locals {
config = yamldecode(file(“${path.module}/config.yaml”))
}
resource “aws_instance” “servers” {
for_each = local.config.instances
# …
}
—
5. 伝説のエンジニアからの「最後のアドバイス」
最後に、生産性を劇的に上げるためのショートカットと心構えだ。
- ショートカット: ターミナルで `alias tf=terraform` は基本中の基本。さらに、`complete -C /usr/local/bin/terraform terraform` で補完を効かせること。
- 環境構築: `tfenv` や `asdf` を使い、チーム全員のバイナリバージョンを強制統一せよ。バージョン差異によるPlanの差異は、デバッグ時間を無駄にする最大の要因だ。
- 設計思想: 「Terraformコードは、将来の自分へのラブレターである」。冗長な記述を避け、モジュール化し、抽象化のレイヤーを適切に保て。
技術はただ使うのではなく、「どう動いているか」という深淵を覗き込み、その挙動を制御する側に回れ。そうすれば、インフラは「管理される対象」から「意のままに操れる武器」へと変わるはずだ。
次は、Terraformのプロバイダー開発についても語りたいところだが……今日はこの辺にしておこう。現場でコードを叩く諸君の健闘を祈る。