Terraformの深淵：Data Source地獄を脱し、極限のプランニング速度を手に入れる戦略的アプローチ
Terraformで「`terraform plan` が終わらない」という現実に直面した時、それは君のインフラが成熟した証であり、同時にアーキテクチャが限界を迎えているサインだ。
多くのエンジニアが陥る罠は、Data Sourceを「外部情報を取得する便利な関数」と勘違いしていることにある。Terraformにとって、Data Sourceは「実行のたびにクラウドAPIを叩きに行く、パフォーマンスの爆弾」だ。数百のリソースを管理する大規模環境において、安易なData Sourceの多用は、APIレートリミットとの戦いと、指数関数的なプラン遅延を引き起こす。
今日は、この「見えないボトルネック」を排除し、IaCの実行速度を物理限界まで引き上げるための極限の最適化戦略を伝授する。
—
1. なぜ「Data Source」はプランを殺すのか：内部メカニズムの真実
Terraformの実行モデルを理解せよ。`plan` フェーズにおいて、Terraformは依存関係グラフを構築する。Data Sourceは、そのグラフの枝葉として配置され、親ノード（リソース）が解決される前に必ずAPIを同期的に呼び出す。
- APIレイテンシの集積: 1つのData Sourceで100msかかるとする。これが100箇所あれば、計算以前に10秒のロスが確定する。
- 依存関係の連鎖: Data Sourceの出力結果を別のData Sourceのフィルタ条件に使うと、直列的なAPI呼び出しが発生する。これは「地獄の数珠つなぎ」だ。
- メモリ消費とStateの汚染: 不必要な情報をData Sourceで大量に取得すると、Terraformのメモリ消費量が増大し、大きな環境ではGC（ガベージコレクション）が頻発する。
—
2. 脱・依存関係地獄：Data Source分離とローカル変数の活用
Data Sourceを「必要な場所で書く」のはアマチュアのやり方だ。真のプロは、「Data Sourceを抽出し、Local変数にカプセル化する」ことで、再計算コストを最小化する。
戦略：Data Sourceの「単一ソース化」と「遅延評価」
Data Sourceをリソースの定義直前に書くのではなく、専用の `data.tf` を作り、可能な限り一箇所に集約する。そして、`for_each` を用いた大量処理は、一度のData Source呼び出しで広範囲のデータを取得し、`locals` でフィルタリングを行うのが鉄則だ。
悪い例：リソースごとにData Sourceを呼ぶ（APIの無駄打ち）
data “aws_subnet” “target” { id = var.subnet_id }
良い例：一度に取得し、Localで加工する（メモリ内処理へ変換）
data “aws_subnets” “all” {
vpc_id = var.vpc_id
}
locals {
# APIを叩くのは一度だけ。あとはメモリ上の処理になる
target_subnets = {
for id in data.aws_subnets.all.ids :
id => id if contains(var.allowed_subnet_ids, id)
}
}
このアプローチにより、API呼び出し回数をO(N)からO(1)に削減できる。
—
3. 大量ループ処理の極限最適化：Providerキャッシュと外部スクリプトの併用
もし、管理対象が数千に及ぶ場合、Terraformのネイティブな `data` 構文すら重荷になる。ここで導入すべきは「外部キャッシュ層」という概念だ。
独自自動化スクリプトによる「Sidecar Cache」の生成
TerraformがAPIを叩く前に、軽量なGoやPythonのスクリプトを走らせ、必要な情報をJSONとして出力する。TerraformはそのJSONを `jsondecode()` で読み込む。
実行前のサイドカー処理（Makefileなどでラップする）
aws ec2 describe-instances –filters … > cache/instances.json
terraform plan
Terraform側はAPIを叩かず、ローカルファイルを読むだけ
locals {
instance_data = jsondecode(file(“${path.module}/cache/instances.json”))
}
resource “aws_instance” “app” {
for_each = { for inst in local.instance_data.Instances : inst.InstanceId => inst }
# …
}
この手法のメリットは圧倒的だ。
1. 冪等性の担保: APIを叩くタイミングをCI/CDパイプライン側で制御できる。
2. 実行速度: JSONのパースはAPI通信に比べて数千倍速い。
3. デバッグの容易性: 取得した生データを人間が直接確認できる。
—
4. プロの隠し武器：Terraformの「State」をAPIと見なせ
上級者はData Sourceを「外部API」ではなく「Terraform State」から取得することを優先する。Terraform Remote Stateは、Data Sourceよりも強力で、かつ計算コストが低い。
- 依存関係をあえて分離する: ネットワーク層、DB層、アプリ層でStateを分け、`terraform_remote_state` データソースで必要な「出力値」だけを吸い上げる。
- 計算の先送り: 複雑なフィルタリングは、データを提供する側のStateで `output` として加工しておき、受け取り側は単に値を参照するだけにする。これが「アーキテクチャとしての最適化」だ。
—
結論：IaCは「静的な構成」から「動的な最適化」へ
Terraformのコードを書き始めた頃は「リソースをどう作るか」に執着する。しかし、真のエンジニアは「どうやって実行プランを最速で導き出すか」に執着する。
1. API呼び出しを最小化せよ: Data Sourceは「必要な時だけ」かつ「一度だけ」呼ぶ。
2. 計算をローカルへ寄せろ: `locals` と `jsondecode` を活用し、API通信を計算処理に置換せよ。
3. Stateを境界線にせよ: 巨大なStateを避け、モジュール間で情報を疎結合に保て。
インフラは、設計者の思考そのものが形となって現れる。君の書くTerraformコードが、明日誰かのプランニング時間を数分短縮するかもしれない。その積み重ねこそが、最高峰のエンジニアへの唯一の道だ。さあ、コードを最適化し、パイプラインを劇的に加速させよう。