大規模Terraformを高速化せよ：数千リソースを制する「並列処理」と「生存戦略」
Terraformで管理するリソースが数百を超えたあたりで、多くのエンジニアが絶望を味わう。「`terraform plan` に5分かかる」「`apply` が終わらずCIがタイムアウトする」。
これはツールが遅いのではない。「Terraformのデフォルト設定が、現代の大規模インフラ環境に対してあまりに保守的すぎる」からだ。
今日は、数千リソースを秒速で調理し、CI/CDパイプラインを爆速化するための「現場の極意」を伝授する。
—
1. `-parallelism` の真実：魔法の数字を見極める
Terraformのデフォルト並列数（`parallelism`）は 10 だ。これは、クラウドのAPI制限やステートロックのリスクを考慮した非常に控えめな数値である。
しかし、現代のクラウド（AWS/GCP/Azure）は、適切に設計すれば数百のAPIリクエストを同時処理できる。
推奨設定と調整の指針
多くの大規模環境では、以下のように調整するだけで実行時間が半分以下になる。
現場でよく使う並列数設定
terraform apply -parallelism=50
- なぜ 50 なのか？
- APIのレート制限（429 Too Many Requests）に抵触しにくく、かつTerraformのグラフ走査のオーバーヘッドを相殺できる限界値が概ねこの辺りだからだ。
- 注意点： 闇雲に上げれば良いわけではない。`100`を超えるとAPI側のスロットリングが多発し、リトライによる待ち時間で結局遅くなる。ログを眺め、「APIエラーが頻発しない限界」を計測せよ。
—
2. `-target` は「諸刃の剣」：安易に使うな
「一部だけ直したいから `-target` を使う」――これは技術的負債への片道切符だ。
`-target` が生む悪夢
- 依存グラフの破壊: 特定のリソースだけを操作すると、Terraformが認識している依存関係（`depends_on`）が無視される可能性がある。
- ステートの不整合: ステートファイルと実際のクラウド環境が乖離し、次に全体適用する際に予期せぬ破壊的変更（Destroy & Recreate）が走る原因になる。
プロの運用ルール:
- 本番環境で `-target` は原則禁止。
- どうしても使う場合は、「一度適用したら、すぐに全体のリソースで `plan` を実行し、差分がないことを確認する」という運用をルール化せよ。
—
3. 大規模環境を爆速化する「実戦的テクニック」
① リソースの断片化（State Sharding）
数千のリソースを一つのStateで管理するのは、もはやアンチパターンだ。数千のリソースを単一のプロセスで計算させるのは、O(n^2)に近い計算コストを強いる。
- 解決策: 境界コンテキスト（Bounded Context）ごとにディレクトリを分割する。モジュール単位でStateを切り出し、`terragrunt` や `terraform workspace` を駆使して、「1ファイルあたりの管理リソース数を500以下」に収めろ。
② Terraform Cloud / Enterprise のバックエンド利用
ローカルのネットワーク帯域やCPUに依存してはいけない。Terraform実行専用のRunnerをクラウド内に配置し、ステートの読み込みを高速化せよ。
—
4. チームの生産性を底上げする「神セットアップ」
推奨VSCodeプラグイン
- HashiCorp Terraform: 言わずもがな。必須。
- TFLint: これを入れないのは裸で戦場に出るのと同じ。リソースの型チェックや、非推奨な設定を静的解析で叩き潰せ。
- Error Lens: エラー箇所をエディタ上に直接表示。数秒のストレスを削る。
設定のベストプラクティス：`tflint.hcl`
プロジェクトルートにこれを置く。
.tflint.hcl
config {
call_module_type = “local”
force = false
}
AWS向けなら、リソースのインスタンスタイプチェックを有効化
plugin “aws” {
enabled = true
version = “0.20.0”
source = “github.com/terraform-linters/tflint-ruleset-aws”
}
チーム開発のルール：`.terraform-version`
チーム全員が同じバイナリバージョンを使うこと。`tfenv` 等を利用し、プロジェクトルートに `.terraform-version` を置くのを強制せよ。
.terraform-version
1.7.0
—
最後に：エンジニアとしての矜持
Terraformのデプロイ速度は、「どれだけコードの依存関係を疎結合に保てているか」という設計スキルの鏡だ。
「遅い」と嘆く前に、以下のチェックリストを確認してほしい。
1. Stateを分割しているか？
2. 不要な `data` ソースで、動的にリソースを取得しすぎていないか？（キャッシュを汚す原因になる）
3. CI/CDでプランの結果をキャッシュし、使い回せているか？
ツールを支配し、クラウドを自在に操る。その先にある「秒でデプロイが完了する快感」を、ぜひ君の現場でも実現してほしい。
さあ、ターミナルを開け。最適化の旅はまだ始まったばかりだ。