【保存版】Terraform depend_onの完全ガイド：5つの重要ポイントと実装例

SHARE

目次

目次へ

depends_onとは？基本概念を理解しよう

リソース依存関係の重要性とdepends_onの役割

Terraformにおけるdepends_onは、リソース間の依存関係を明示的に定義するための重要なメタ引数です。インフラストラクチャのプロビジョニングでは、リソースの作成順序が極めて重要となります。例えば、データベースインスタンスを作成する前にVPCが必要であったり、アプリケーションをデプロイする前にロードバランサーが必要であったりします。

depends_onの主な役割は以下の3つです：

  1. デプロイ順序の制御
  • リソースの作成順序を明示的に指定
  • 依存関係に基づいた適切な順序でのデプロイを保証
  • 破壊的変更時の安全な順序を確保
  1. 暗黙的な依存関係の補完
  • Terraformが自動検出できない依存関係を定義
  • 複雑な依存関係を確実に管理
  • エッジケースでの動作を制御
  1. インフラストラクチャの整合性確保
  • リソース間の関係性を明確に表現
  • 設定の誤りによる問題を防止
  • 安定したデプロイメントを実現

以下は、基本的な使用例です：

# VPCの定義
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main"
  }
}

# RDSインスタンスの定義
resource "aws_db_instance" "example" {
  # ... other configurations ...

  # VPCが作成されてから実行されることを明示
  depends_on = [aws_vpc.main]
}

暗黙的な依存関係と明示的な依存関係の違い

Terraformでは、2種類の依存関係が存在します：

  1. 暗黙的な依存関係（Implicit Dependencies）
  • リソース間の参照関係から自動的に推測される依存関係
  • コード内での変数や属性の参照により生成
  • Terraformが自動的に解決

例えば、以下のコードでは、セキュリティグループがVPCを参照することで暗黙的な依存関係が生まれます：

resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_security_group" "example" {
  vpc_id = aws_vpc.main.id  # 暗黙的な依存関係が生成される

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
  1. 明示的な依存関係（Explicit Dependencies）
  • depends_onを使用して明示的に定義される依存関係
  • 開発者が意図的に指定する必要がある
  • 以下のような場合に特に重要：
    • リソース間に直接の参照関係がない場合
    • 特定の順序でデプロイする必要がある場合
    • Terraformが依存関係を検出できない場合

明示的な依存関係が必要なケースの例：

# カスタムポリシーの作成
resource "aws_iam_role_policy" "example" {
  name = "example_policy"
  role = aws_iam_role.example.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:*"]
        Resource = ["*"]
      }
    ]
  })
}

# Lambda関数の作成
resource "aws_lambda_function" "example" {
  filename      = "lambda_function_payload.zip"
  function_name = "example_lambda"
  role          = aws_iam_role.example.arn
  handler       = "index.handler"
  runtime       = "nodejs14.x"

  # ポリシーが完全に適用されてから関数を作成
  depends_on = [aws_iam_role_policy.example]
}

この違いを理解することは、効果的なTerraformコードの作成に不可欠です。暗黙的な依存関係は可読性が高く保守が容易ですが、明示的な依存関係は特定のユースケースで必要不可欠となります。ベストプラクティスとしては、可能な限り暗黙的な依存関係を使用し、必要な場合のみdepends_onを使用することが推奨されます。

depends_onの具体的な実装方法

基本的な構文と使用例

depends_onの基本的な構文は非常にシンプルで、リソースブロック内で配列として定義します。以下が基本的な構文パターンです：

resource "リソースタイプ" "リソース名" {
  # リソースの設定

  depends_on = [
    依存するリソース1,
    依存するリソース2
  ]
}

実際の使用例として、ECSサービスとALBの依存関係を見てみましょう：

# Application Load Balancerの作成
resource "aws_lb" "app" {
  name               = "example-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.lb.id]
  subnets            = aws_subnet.public[*].id
}

# ALBターゲットグループの作成
resource "aws_lb_target_group" "app" {
  name        = "example-tg"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"
}

# ECSサービスの作成
resource "aws_ecs_service" "app" {
  name            = "example-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 2

  load_balancer {
    target_group_arn = aws_lb_target_group.app.arn
    container_name   = "web"
    container_port   = 80
  }

  # ALBとターゲットグループが完全に作成されてから
  # ECSサービスを作成することを保証
  depends_on = [
    aws_lb.app,
    aws_lb_target_group.app
  ]
}

複数リソースへの依存関係の定義方法

複数のリソースに依存関係を持つ場合、配列内に全ての依存リソースを列挙します。以下は、RDSインスタンスが複数のリソースに依存する例です：

# サブネットグループの作成
resource "aws_db_subnet_group" "example" {
  name       = "example"
  subnet_ids = aws_subnet.private[*].id
}

# パラメータグループの作成
resource "aws_db_parameter_group" "example" {
  family = "mysql8.0"
  name   = "example"

  parameter {
    name  = "character_set_server"
    value = "utf8mb4"
  }
}

# RDSインスタンスの作成
resource "aws_db_instance" "example" {
  identifier        = "example-db"
  engine            = "mysql"
  engine_version    = "8.0"
  instance_class    = "db.t3.micro"
  allocated_storage = 20

  db_subnet_group_name   = aws_db_subnet_group.example.name
  parameter_group_name   = aws_db_parameter_group.example.name
  vpc_security_group_ids = [aws_security_group.db.id]

  # 複数のリソースへの依存関係を定義
  depends_on = [
    aws_db_subnet_group.example,
    aws_db_parameter_group.example,
    aws_security_group.db,
    aws_vpc.main          # VPCとその関連リソース
  ]
}

モジュールレベルでの依存関係の設定

モジュールレベルでの依存関係は、モジュール間の実行順序を制御する場合に使用します。以下は、VPCモジュールとRDSモジュールの依存関係を定義する例です：

# VPCモジュール
module "vpc" {
  source = "./modules/vpc"

  vpc_cidr = "10.0.0.0/16"
  environment = "production"
}

# RDSモジュール
module "rds" {
  source = "./modules/rds"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnet_ids

  # VPCモジュールの完了を待つ
  depends_on = [module.vpc]
}

# ECSモジュール
module "ecs" {
  source = "./modules/ecs"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnet_ids
  db_host    = module.rds.endpoint

  # VPCとRDSモジュールの完了を待つ
  depends_on = [
    module.vpc,
    module.rds
  ]
}

モジュール内部でのリソースの依存関係は、出力値を使用して制御することもできます：

# modules/rds/outputs.tf
output "endpoint" {
  value = aws_db_instance.main.endpoint

  # 全ての必要なリソースが作成されていることを保証
  depends_on = [
    aws_db_instance.main,
    aws_db_subnet_group.main,
    aws_security_group.db
  ]
}

この方法により、モジュールの出力が確実に全ての必要なリソースが作成された後にのみ利用可能となります。これは、大規模なインフラストラクチャの管理において特に重要です。

depends_onのベストプラクティス5選

必須の依存関係定義で速度を確保

depends_onの過剰な使用はTerraformの実行速度を低下させる原因となります。以下のベストプラクティスに従うことで、最適なパフォーマンスを維持できます：

  1. 暗黙的な依存関係を優先する
# 非推奨: 明示的な依存関係を使用
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  depends_on = [aws_vpc.main]  # 不要な依存関係
}

# 推奨: 暗黙的な依存関係を利用
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = aws_vpc.main.subnet_ids[0]  # 暗黙的な依存関係
}
  1. 並列実行可能なリソースは依存関係を避ける
# 非推奨: 不要な依存関係による直列実行
resource "aws_s3_bucket" "logs" {
  bucket = "my-logs-bucket"
  depends_on = [aws_s3_bucket.data]  # 不要な依存関係
}

# 推奨: 並列実行による高速化
resource "aws_s3_bucket" "logs" {
  bucket = "my-logs-bucket"
}

resource "aws_s3_bucket" "data" {
  bucket = "my-data-bucket"
}

依存関係の可視化とドキュメント化

依存関係を明確に理解し管理するために、以下の方法を実践しましょう：

  1. コメントによる依存関係の説明
# データベースリソースグループ
# 依存関係: VPC -> サブネットグループ -> パラメータグループ -> RDSインスタンス
resource "aws_db_subnet_group" "main" {
  name       = "main"
  subnet_ids = aws_subnet.private[*].id

  tags = {
    DependencyGroup = "database"
    DependencyOrder = "1"
  }
}

resource "aws_db_instance" "main" {
  # ... 設定項目 ...

  depends_on = [aws_db_subnet_group.main]

  tags = {
    DependencyGroup = "database"
    DependencyOrder = "2"
  }
}
  1. グラフ生成のための依存関係タグ付け
locals {
  dependency_tags = {
    "terraform.dependency.group" = "application-stack"
    "terraform.dependency.layer" = "database"
  }
}

resource "aws_db_instance" "main" {
  # ... 設定項目 ...

  tags = merge(local.dependency_tags, {
    Name = "main-db"
  })
}

循環依存を防ぐための設計指針

循環依存関係はTerraformのデプロイを阻害する主な要因です。以下の設計指針に従うことで、循環依存を防ぐことができます：

  1. リソースの階層構造を明確にする
# 基盤層（Foundation Layer）
module "networking" {
  source = "./modules/networking"
}

# プラットフォーム層（Platform Layer）
module "database" {
  source = "./modules/database"
  vpc_id = module.networking.vpc_id
  depends_on = [module.networking]
}

# アプリケーション層（Application Layer）
module "application" {
  source = "./modules/application"
  db_endpoint = module.database.endpoint
  vpc_id = module.networking.vpc_id
  depends_on = [module.database]
}
  1. 共有リソースを独立したモジュールに分離
# 共有リソースモジュール
module "shared" {
  source = "./modules/shared"
}

# サービスAモジュール
module "service_a" {
  source = "./modules/service_a"
  shared_resources = module.shared.outputs
  depends_on = [module.shared]
}

# サービスBモジュール
module "service_b" {
  source = "./modules/service_b"
  shared_resources = module.shared.outputs
  depends_on = [module.shared]
}
  1. データソースを活用した依存関係の解決
# 既存リソースの参照にはdata sourceを使用
data "aws_vpc" "existing" {
  id = var.vpc_id
}

resource "aws_security_group" "example" {
  name   = "example"
  vpc_id = data.aws_vpc.existing.id

  # depends_onは不要
}

これらのベストプラクティスを適用することで、以下のメリットが得られます：

  • デプロイ時間の短縮
  • コードの保守性向上
  • エラーの発生率低下
  • チーム間のコラボレーション改善
  • インフラストラクチャの安定性向上

また、これらのプラクティスはチーム全体で共有し、新規メンバーのオンボーディング時にも活用することをお勧めします。

よくあるトラブルと解決方法

デプロイ順序問題とその対処法

デプロイ順序に関する問題は、depends_onを使用する際によく発生するトラブルの一つです。以下の主な問題パターンと解決方法を解説します：

  1. リソースが完全に作成される前に依存リソースがデプロイされる
# 問題のあるコード
resource "aws_iam_role" "lambda" {
  name = "lambda-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_lambda_function" "example" {
  filename      = "lambda.zip"
  function_name = "example"
  role          = aws_iam_role.lambda.arn
  handler       = "index.handler"
  runtime       = "nodejs14.x"

  # IAMロールのポリシーが完全に適用される前にLambda関数が作成される
}

解決方法：

# 修正後のコード
resource "aws_iam_role_policy_attachment" "lambda" {
  role       = aws_iam_role.lambda.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_lambda_function" "example" {
  filename      = "lambda.zip"
  function_name = "example"
  role          = aws_iam_role.lambda.arn
  handler       = "index.handler"
  runtime       = "nodejs14.x"

  # ポリシーのアタッチメント完了を待つ
  depends_on = [aws_iam_role_policy_attachment.lambda]
}
  1. 削除順序の問題
# 問題のあるコード - 削除時にエラーが発生する可能性あり
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "example" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

解決方法：

# 修正後のコード - 適切な削除順序を保証
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "example" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"

  # VPCの削除前にサブネットが削除されることを保証
  depends_on = [aws_vpc.main]
}

パフォーマンス低下時の最適化テクニック

  1. 不要な依存関係の削除
# パフォーマンスが低下するコード
resource "aws_s3_bucket" "log" {
  bucket = "my-log-bucket"
  depends_on = [
    aws_s3_bucket.data,    # 不要な依存関係
    aws_s3_bucket.backup,  # 不要な依存関係
    aws_s3_bucket.archive  # 不要な依存関係
  ]
}

# 最適化後のコード
resource "aws_s3_bucket" "log" {
  bucket = "my-log-bucket"
  # 依存関係不要のため削除
}
  1. 並列実行の最適化
# パフォーマンスを改善するためのリファクタリング例
# Before: 全てのリソースが直列に作成される
module "application" {
  source = "./modules/application"
  depends_on = [
    module.networking,
    module.security,
    module.database
  ]
}

# After: 必要な依存関係のみを定義し、可能な限り並列実行
module "application" {
  source = "./modules/application"

  vpc_id     = module.networking.vpc_id
  db_endpoint = module.database.endpoint

  depends_on = [
    module.security  # セキュリティ設定のみ完了を待つ
  ]
}

エラーメッセージの解読と対応方法

よく遭遇するエラーメッセージとその対処方法を解説します：

  1. 循環依存エラー
Error: Cycle: aws_iam_role.example, aws_iam_role_policy.example

このエラーは、リソース間に循環参照が存在する場合に発生します。以下のように解決します：

# 問題のあるコード
resource "aws_iam_role" "example" {
  name = "example"
  depends_on = [aws_iam_role_policy.example]
}

resource "aws_iam_role_policy" "example" {
  role = aws_iam_role.example.id
  depends_on = [aws_iam_role.example]
}

# 修正後のコード
resource "aws_iam_role" "example" {
  name = "example"
}

resource "aws_iam_role_policy" "example" {
  role = aws_iam_role.example.id
  depends_on = [aws_iam_role.example]
}
  1. リソース未作成エラー
Error: Error creating Lambda function: InvalidParameterValueException: The role defined for the function cannot be assumed by Lambda.

このエラーは、IAMロールの伝搬遅延によって発生します。以下のように解決します：

# 問題の解決
resource "aws_lambda_function" "example" {
  # ... other configuration ...

  # IAMロールの伝搬を待つ
  depends_on = [aws_iam_role_policy_attachment.lambda_logs]

  # 追加のウェイトタイムを設定
  provisioner "local-exec" {
    command = "sleep 10"
  }
}

これらのトラブルシューティング手法を理解し、適切に対応することで、より安定したTerraformの運用が可能となります。

実践的なユースケース集

データベースとアプリケーションの依存関係管理

複雑なアプリケーションスタックでは、データベースとアプリケーションの適切な依存関係管理が重要です。以下は、RDSとECSを使用したマイクロサービスの実装例です：

# データベース層
resource "aws_db_instance" "main" {
  identifier        = "production-db"
  engine           = "postgres"
  engine_version   = "13.7"
  instance_class   = "db.t3.medium"
  allocated_storage = 20

  db_name  = "myapp"
  username = "admin"
  password = var.db_password

  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name

  backup_retention_period = 7
  multi_az               = true

  tags = {
    Environment = "production"
    Layer       = "database"
  }
}

# アプリケーション層（ECSサービス）
resource "aws_ecs_service" "api" {
  name            = "api-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2

  network_configuration {
    subnets         = aws_subnet.private[*].id
    security_groups = [aws_security_group.api.id]
  }

  # データベースが完全に準備できてから起動
  depends_on = [
    aws_db_instance.main,
    aws_alb_listener.front_end,
  ]

  # 環境変数でDB接続情報を渡す
  environment = [
    {
      name  = "DB_HOST"
      value = aws_db_instance.main.endpoint
    },
    {
      name  = "DB_NAME"
      value = aws_db_instance.main.db_name
    }
  ]
}

マルチリージョンデプロイメントでの活用例

災害対策やレイテンシー最適化のために、マルチリージョンデプロイメントを実装する場合の例です：

# プライマリーリージョンのリソース
provider "aws" {
  alias  = "primary"
  region = "ap-northeast-1"
}

# セカンダリーリージョンのリソース
provider "aws" {
  alias  = "secondary"
  region = "ap-northeast-2"
}

# プライマリーリージョンのS3バケット
resource "aws_s3_bucket" "primary" {
  provider = aws.primary
  bucket   = "my-primary-bucket"

  versioning {
    enabled = true
  }
}

# セカンダリーリージョンのS3バケット（レプリケーション先）
resource "aws_s3_bucket" "secondary" {
  provider = aws.secondary
  bucket   = "my-secondary-bucket"

  versioning {
    enabled = true
  }

  # プライマリーバケットが作成されてから作成
  depends_on = [aws_s3_bucket.primary]
}

# レプリケーション設定
resource "aws_s3_bucket_replication_configuration" "replication" {
  provider   = aws.primary
  role       = aws_iam_role.replication.arn
  bucket     = aws_s3_bucket.primary.id

  rule {
    id     = "everything"
    status = "Enabled"

    destination {
      bucket = aws_s3_bucket.secondary.arn
    }
  }

  # 両方のバケットが作成されてから設定
  depends_on = [
    aws_s3_bucket.primary,
    aws_s3_bucket.secondary
  ]
}

マイクロサービスアーキテクチャでの実装パターン

マイクロサービスアーキテクチャにおける複雑な依存関係を管理する例を示します：

# 共有インフラストラクチャモジュール
module "shared_infrastructure" {
  source = "./modules/shared"

  vpc_cidr = "10.0.0.0/16"
  environment = "production"
}

# データストアモジュール
module "datastores" {
  source = "./modules/datastores"

  vpc_id     = module.shared_infrastructure.vpc_id
  subnet_ids = module.shared_infrastructure.private_subnet_ids

  # VPCが完全に構築されてから作成
  depends_on = [module.shared_infrastructure]
}

# サービスモジュール群
module "auth_service" {
  source = "./modules/services/auth"

  vpc_id      = module.shared_infrastructure.vpc_id
  subnet_ids  = module.shared_infrastructure.private_subnet_ids
  db_endpoint = module.datastores.auth_db_endpoint

  depends_on = [module.datastores]
}

module "user_service" {
  source = "./modules/services/user"

  vpc_id      = module.shared_infrastructure.vpc_id
  subnet_ids  = module.shared_infrastructure.private_subnet_ids
  db_endpoint = module.datastores.user_db_endpoint

  # 認証サービスが利用可能になってから作成
  depends_on = [
    module.datastores,
    module.auth_service
  ]
}

module "api_gateway" {
  source = "./modules/api-gateway"

  vpc_id     = module.shared_infrastructure.vpc_id
  subnet_ids = module.shared_infrastructure.private_subnet_ids

  auth_service_url = module.auth_service.service_url
  user_service_url = module.user_service.service_url

  # 全てのバックエンドサービスが利用可能になってから作成
  depends_on = [
    module.auth_service,
    module.user_service
  ]
}

# 監視設定
module "monitoring" {
  source = "./modules/monitoring"

  vpc_id     = module.shared_infrastructure.vpc_id
  subnet_ids = module.shared_infrastructure.private_subnet_ids

  services = {
    auth = module.auth_service.monitoring_config
    user = module.user_service.monitoring_config
    api  = module.api_gateway.monitoring_config
  }

  # 全てのサービスが構築されてから監視を設定
  depends_on = [
    module.auth_service,
    module.user_service,
    module.api_gateway
  ]
}

これらのユースケースは、実際の業務で遭遇する可能性が高いシナリオを想定しています。各実装例では以下の点に注意を払っています：

  1. リソースの論理的なグループ化
  2. 適切な依存関係の定義
  3. セキュリティとパフォーマンスの最適化
  4. スケーラビリティの確保
  5. 保守性の向上

これらの実装パターンを参考に、プロジェクトの要件に応じて適切にカスタマイズすることで、より堅牢なインフラストラクチャを構築することができます。

前の記事

【保存版】TerraformでS3を構築する完全ガイド2024…

次の記事

【保存版】TerraformとAnsibleで実現 AWS環境…