Terraformでデータ基盤をIaC化する方法――Snowflake/BigQuery編

データ基盤のインフラを手動クリックで管理する時代は終わりました。本記事では、SnowflakeとBigQueryをTerraformで宣言的に管理する具体的な方法をコード付きで解説します。結論から述べると、Terraformはデータ基盤のIaC化における事実上の標準であり、DB・スキーマ・ウェアハウス・ロール・権限の5要素をコード管理することで、監査性・再現性・権限統制のいずれも一気に向上します。

なぜデータ基盤にIaCが必要か

データ基盤の運用で最も厄介なのは「誰が・いつ・何を変更したか分からない」状態です。手動で付与された権限が忘れ去られ、退職者のアカウントが残り続け、検証用に作ったはずのロールが本番環境で使われ続ける――どれもIaC化されていない環境でよく見る光景です。

Terraformなどを使ってインフラをコード化すれば、変更はすべてGitで追跡され、レビュー可能になります。データ基盤は「権限がビジネスクリティカル」という性質を持つため、一般的なアプリケーションインフラよりもIaCの恩恵が大きい領域なのです。

Terraformの基本とデータ基盤での活用範囲

Terraformはプロバイダーと呼ばれるプラグインを通じて各種クラウドリソースを管理します。データ基盤で使う主要なプロバイダーは、Snowflake(Snowflake社公式のSnowflake Terraform Provider)、Google(BigQuery、IAM、Cloud Storage)、AWS(Redshift、S3、IAM)などです。

管理対象は「アプリケーションから見たインフラ層」、すなわちデータベース・スキーマ・ウェアハウス・ロール・権限が中心です。テーブル定義や変換ロジックはdbtの管轄となるため、Terraformで触るのは境界までにしておくのが鉄則です。

【Terraformでの管理対象】

  [Terraform管理レイヤー]
       |
       +--> Database / Schema
       +--> Warehouse / Compute
       +--> Role / User / Group
       +--> Grant / Permission
       +--> Network Policy
       |
  [dbt管理レイヤー]
       |
       +--> Table / View / Materialized View
       +--> Business Logic / Tests / Docs

※ テーブル定義はdbtで管理し、Terraformはインフラの境界まで。

Snowflake × Terraform 実装例

まずはSnowflake Providerの基本設定から始めます。認証情報は環境変数やtfvarsで外部化しておき、コードにハードコードしないのが鉄則です。

terraform {
  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "~> 0.90"
    }
  }
}

provider "snowflake" {
  account = var.snowflake_account
  role    = "TERRAFORM_ADMIN"
}

次にデータベース、スキーマ、ウェアハウス、ロールを作成します。命名規約を明確にして、環境ごとの接尾辞を変数化しておくと管理しやすくなります。

resource "snowflake_database" "analytics" {
  name = "ANALYTICS_${upper(var.env)}"
}

resource "snowflake_schema" "marts" {
  database = snowflake_database.analytics.name
  name     = "MARTS"
}

resource "snowflake_warehouse" "compute" {
  name           = "COMPUTE_WH_${upper(var.env)}"
  warehouse_size = "XSMALL"
  auto_suspend   = 60
  auto_resume    = true
}

resource "snowflake_role" "analyst" {
  name = "ANALYST_ROLE_${upper(var.env)}"
}

最後に権限付与です。SnowflakeのRBACは階層が深いので、ロール間のgrantとオブジェクトへのgrantを分けて整理します。

resource "snowflake_grant_privileges_to_role" "analyst_select" {
  privileges = ["USAGE", "SELECT"]
  role_name  = snowflake_role.analyst.name
  on_schema_object {
    all {
      object_type_plural = "TABLES"
      in_schema          = "${snowflake_database.analytics.name}.${snowflake_schema.marts.name}"
    }
  }
}

BigQuery × Terraform 実装例

BigQueryはGoogle Providerで管理します。SnowflakeほどRBACが複雑ではなく、データセット単位でIAMポリシーを付けるシンプルな構造です。

resource "google_bigquery_dataset" "marts" {
  dataset_id  = "marts_${var.env}"
  location    = "asia-northeast1"
  description = "Gold層データマート"

  default_table_expiration_ms = 31536000000  # 365日
  labels = {
    env   = var.env
    owner = "data-platform"
  }
}

resource "google_bigquery_dataset_iam_member" "analyst_reader" {
  dataset_id = google_bigquery_dataset.marts.dataset_id
  role       = "roles/bigquery.dataViewer"
  member     = "group:analysts@example.com"
}

IaCのベストプラクティス

Terraformコードを量産するだけでは運用は楽になりません。モジュール化、state管理、CI/CD連携、drift検知の4点を押さえることで、初めて「IaCを運用できる」状態になります。

プラクティス	概要	具体的な実装方法
モジュール化	再利用可能な単位に分割	database、role、grantごとにmoduleを作成
Remote State管理	複数人で安全に操作する	GCS / S3バックエンドとstate lock
環境分離	dev/stg/prodで独立	workspaceまたはディレクトリ分離
CI/CD連携	PRで自動Plan、mergeで自動Apply	GitHub Actions / Atlantis
Drift検知	手動変更を検出する	日次でterraform planを実行し差分通知
Secretsの分離	認証情報をコードから除外	Secret Manager / Vault / tfvars暗号化

次にIaCツール自体の選択肢を比較しておきます。データ基盤ではTerraformが事実上の標準ですが、他の選択肢も知っておいて損はありません。

観点	Terraform	Pulumi	AWS CDK
記述言語	HCL	TypeScript / Python / Go 他	TypeScript / Python 他
データ基盤対応	Snowflake / BigQuery / Databricks 全般	Snowflake / BigQuery 対応	AWS中心
学習コスト	HCLを覚える必要あり	既存のプログラミング言語が使える	AWS SDKに近い
コミュニティ	最大	成長中	AWS内で大きい
向く用途	マルチクラウド、データ基盤	ロジック多めのインフラ	AWS特化

IaC導入の注意点

IaC化は銀の弾丸ではありません。導入時に特に注意が必要な3つの落とし穴をお伝えします。

第一に、state管理の重要性です。stateファイルはインフラの実態とTerraformコードを結びつける要であり、ローカルPCに置いたまま運用すると事故のもとになります。必ずリモートバックエンド（GCS、S3など）とstate lockを併用してください。

第二に、既存リソースのimportです。すでに手動で作ったデータベースや権限を後からTerraform管理下に置く場合、`terraform import`コマンドで取り込む必要があります。一気に全部importしようとせず、段階的にコードと実態を合わせていくのが安全です。

第三に、Plan/Applyのレビュー体制です。Planの出力は長くなりがちで、目視だけでは見落としが起きます。削除系の変更には特に気をつけ、CODEOWNERSやレビュー必須ルールで守る体制を整えましょう。

まとめ

データ基盤のIaC化は、監査・再現性・権限統制の3点で劇的な改善をもたらします。Terraformという強力な道具を手にした以上、次の一歩はモジュール化とCI/CD連携です。小さく始めて、徐々に管理範囲を広げていきましょう。

よくある質問

データ基盤でTerraformは何を管理しますか?

DWHのデータベース・スキーマ・ウェアハウス・ロール・権限付与を管理します。テーブル定義やデータ変換はdbtの管轄で、Terraformはインフラ層を担います。役割分担を明確にすることで、どちらのコードで何を変えるべきかが迷わず判断できます。

既存のSnowflake環境にTerraformを導入できますか?

はい。`terraform import`コマンドで既存リソースをstate管理下に取り込めます。段階的に管理範囲を広げるアプローチが安全です。最初は新規リソースのみTerraformで作成し、軌道に乗ったら既存リソースをimportしていく二段構えが現実的です。

TerraformとPulumiのどちらがデータ基盤に向いていますか?

データ基盤ではTerraformの方がプロバイダーの成熟度が高く、情報も豊富です。TypeScript/Pythonでインフラを書きたい場合はPulumiが選択肢になります。チームのスキルセットとプロバイダーの対応範囲から判断するとよいでしょう。