Terraformの`depends_on`は「逃げ」である。依存関係の深淵から脱却するアーキテクチャ設計論
Terraformを触り始めて数年、「どうしてもリソースが作成順序を守ってくれない」という壁にぶつかり、思考停止で`depends_on`を書き殴った経験はないだろうか。
はっきり言おう。`depends_on`の多用は、Terraformコードに対する「敗北宣言」だ。
グラフ理論に基づき、リソース間の依存関係を暗黙的に解決するTerraformの美しいアーキテクチャを破壊し、保守性を劇的に下げる。今回は、この「アンチパターン」の正体を暴き、真にスケーラブルなコードを書くための作法を伝授する。
—
1. なぜ`depends_on`が「害悪」なのか
Terraformの実行計画（Plan）は、リソース間の参照関係（`id`や`arn`などのプロパティ参照）を解析し、DAG（有向非巡回グラフ）を構築することで並列実行の最大効率を追求する。
ここに`depends_on`を差し込むとどうなるか：
1. 並列処理の阻害: 本来は独立して作成可能なリソースまで直列化され、デプロイ時間が線形に増加する。
2. スパゲッティ依存の誘発: 「Aが壊れたらBも作り直し」という連鎖がブラックボックス化し、`terraform destroy`が予測不可能な挙動を示す。
3. リファクタリングの拒絶: モジュール化しようとした瞬間、ハードコードされた依存関係が邪魔をして、コードの移動や再利用が不可能になる。
2. 「暗黙の依存」を活かす正しい設計アプローチ
依存関係を明示する必要がある場合、それは「参照すべき値が足りていない」というサインだ。
悪い例：無理やり順番を固定する
resource “aws_iam_role” “app_role” { … }
resource “aws_instance” “app_server” {
# 意味のないdepends_onで順序を強制している
depends_on = [aws_iam_role.app_role]
iam_instance_profile = aws_iam_instance_profile.app_role.name
}
良い例：属性参照でグラフを構築する
IAMプロファイルの`name`を直接参照することで、Terraformは「インスタンス作成にはプロファイルの完了が必須」と自動的に理解する。`depends_on`は1行も不要だ。
resource “aws_iam_instance_profile” “app_profile” {
role = aws_iam_role.app_role.name
}
resource “aws_instance” “app_server” {
# 属性参照により、暗黙的に依存関係が解決される
iam_instance_profile = aws_iam_instance_profile.app_profile.name
}
—
3. 開発速度を劇的に高める「プロの道具箱」
ツールに踊らされるのではなく、ツールを掌で転がす。これがSREの鉄則だ。
VS Code神プラグイン
- Terraform (HashiCorp公式): 言わずもがな。
- TFLint: `depends_on`の乱用や、クラウド特有の非推奨設定をCI前に検知する「守護神」。
- Error Lens: エラー箇所を行末に表示。修正までのコンテキストスイッチをゼロにする。
開発を爆速にするキーボードショートカット (VS Code)
- `Ctrl + P` (Quick Open): ファイル間を瞬時に移動。
- `Alt + Shift + F`: Terraformの自動整形（`terraform fmt`を保存時に自動実行する設定が必須）。
- `Ctrl + B` (サイドバー開閉): 画面を広く使い、コードに集中する。
チーム開発における「絶対設定」
`.vscode/settings.json`をリポジトリルートに置き、チーム全員の環境を統一せよ。これが「環境差異によるバグ」を消す最短ルートだ。
{
“editor.formatOnSave”: true,
“terraform.languageServer”: {
“enabled”: true,
“args”: [“serve”]
},
“editor.codeActionsOnSave”: {
“source.fixAll.terraform”: “explicit”
}
}
—
4. リファクタリングの作法：依存の鎖を断ち切る
もし現行コードに`depends_on`が溢れているなら、以下の手順でリファクタリングせよ。
1. データソース化: 依存先リソースを`data`ブロックとして参照できないか検討する。
2. Outputの活用: モジュール境界を跨ぐ場合は、必ず`output`で必要な属性を渡し、呼び出し元でそれを参照する形に書き換える。
3. `terraform graph`で可視化: `terraform graph | dot -Tpng > graph.png`で現状の依存ツリーを出力せよ。スパゲッティになっている箇所は一目でわかる。
—
最後に：コードは「インフラの設計書」である
`depends_on`は、料理で言えば「材料が届くのを待つ」のではなく「店員に『待て』と命令する」ようなものだ。材料（参照）さえあれば、自動的に調理（作成）は始まる。
Terraformの真価は、宣言的な記述によって「あるべき状態」を定義することにある。手続き的な順序付けに頼るのではなく、リソース同士の論理的な結びつきをコードに落とし込むこと。それこそが、エンジニアとしての格を上げる唯一の道だ。
さあ、今すぐ`depends_on`を検索し、削除する作業から始めよう。そこから、君たちのインフラは真の自律性を手に入れるはずだ。