【Data Superhero セッション 】 Snowflake基盤を途中からIaC化する：Terraform × Terragrunt × 環境分離設計

Snowflake Tech Fast Track 2026 データ ウェアハウス トラック 15:10 - 15:35
https://www.snowflake.com/snowflake-tech-fast-track/

Snowflake基盤を途中からIaC化する：Terraform × Terragrunt × 環境分離設計
Snowflakeを大規模に運用している環境に対し、TerraformおよびTerragruntを用いたInfrastructure as Code導入の実践事例を紹介します。既存リソースを止めずにTerraform管理へ移行する際の課題（state import、設計分割、組織合意形成）と、その解決アプローチを解説します。さらにdev/stg/prodの環境分離設計、TerragruntによるDRY化、state分割による大規模基盤対応、CI/CD連携まで、実運用に耐えるIaC設計戦略を共有します。

Transcript

1. © 2026 Snowflake Inc. All Rights Reserved Snowflake基盤を途中からIaC化する： Terraform × Terragrunt × 環境分離設 計 是枝 達也 Data Superhero 株式会社GA technologies, Data本部 Data Management チーフ
2. © 2026 Snowflake Inc. All Rights Reserved 自己紹介 名前 是枝 達也 / Tatsuya Koreeda 略歴 株式会社GA technologies, Data本部 Data Management チーフ 活動 ・Snowflake UG リーダー（WEST / HCLS） ・SnowVillage Mayors 趣味 バイオインフォマティクス研究 Snowflakeで好きな機能 Snowpark Container Service
3. © 2026 Snowflake Inc. All Rights Reserved アジェンダ 01 背景‧課題 なぜSnowflakeのIaC化が必要か 02 Snowflake基盤IaC化 途中からTerraformを⼊れる壁 03 Terraform導⼊のポイント CI/CD‧環境分割‧Terragrunt‧DRY化 04 途中からIaC化する際のポイント リソース範囲‧import‧AI活⽤ 05 まとめ 得られた成果と今後
4. © 2026 Snowflake Inc. All Rights Reserved このセッションの対象者 • Snowflakeを使っているが、リソース管理がGUI頼みになっている⽅ • Terraformに興味はあるが、何から始めればいいかわからない⽅ • IaC化したいが、既存環境があるため踏み出せずにいる⽅ • Terraform導⼊済みだが、設定の重複やstate管理に悩んでいる⽅
5. © 2026 Snowflake Inc. All Rights Reserved 背景・課題
6. © 2026 Snowflake Inc. All Rights Reserved 一般的なSnowflake基盤の運用
7. © 2026 Snowflake Inc. All Rights Reserved 一般的なSnowflake基盤の構成が抱える課題 運⽤管理の属⼈化 特定の担当者しか知らない リソース‧設定が存在し、 全体像の把握が困難 ぶっつけ本番 本番環境に直で リソース変更するため、 ユーザー影響の確認ができない レビュー不可 GUIでの操作なので、 他のメンバーの レビューを通せない 環境の再現性がない 同じ構成を正確に再現することが 困難
8. © 2026 Snowflake Inc. All Rights Reserved 現場を離れます ・integrationが大量にあるけど 　用途も経緯もわからない… ・ロールの付与ルールが 　どこにも書かれていない… 属⼈化がもたらすリスク 全てを把握している担当者 残されたチームメンバー
9. © 2026 Snowflake Inc. All Rights Reserved 強制力のない仕組み化の末路 ユーザー発⾏⼿順 リソース管理台帳 Snowflake Worksheet Google スプレッドシート ユーザー発⾏の⼿順書として作成 → ⼿順が増えるたびに形骸化 → 直接UIから操作する⽅が早い リソース管理の台帳として作成 → 更新⽇が1年前で放置状態 → 実態との乖離が拡⼤し続ける 強制⼒がない仕組みは、だんだん使われなくなる
10. © 2026 Snowflake Inc. All Rights Reserved Snowflake基盤IaC化
11. © 2026 Snowflake Inc. All Rights Reserved Terraformを使ったSnowflake基盤の管理 Provider設定 Snowflake接続情報を定義し リソース操作の認証基盤を構築 リソースをコードで宣⾔ Database‧Warehouse等を HCLで宣⾔的に定義‧管理 権限もコードで管理 Grant設定をコード化し ロールベースのアクセス制御を実現 # Provider設定 provider "snowflake" { organization_name = "your_org" account_name = "your_account" user = "SYSTEM_TERRAFORM" role = "SYSADMIN" authenticator = "SNOWFLAKE_JWT" } # Database作成 resource "snowflake_database" "analytics" { name = "ANALYTICS" is_transient = false } # Warehouse作成 resource "snowflake_warehouse" "etl" { name = "ETL_WH" warehouse_size = "X-SMALL" auto_suspend = 60 auto_resume = true } # 権限付与 resource "snowflake_grant_privileges_to_account_role" "grant" { account_role_name = "ANALYST" privileges = ["USAGE"] on_account_object { object_type = "DATABASE" object_name = snowflake_database.analytics.name } }
12. © 2026 Snowflake Inc. All Rights Reserved Terraform + CI/CD運用 コード レビュー CI/CD パイプライン 保証 プロセスを経由 コードで定義し、レビューを経て CI/CDで⾃動適⽤する流れ 適切なプロセスで品質を担保 属⼈化を排除し、再現性のある 品質管理を実現
13. © 2026 Snowflake Inc. All Rights Reserved Terraform + 環境分離による最低限の構成
14. © 2026 Snowflake Inc. All Rights Reserved Terraform + 環境分離によるメリット 課題 解決 運⽤管理の 属⼈化 コード化により 誰でも同じ品質で 運⽤可能 ぶっつけ 本番 段階的な検証環 境で本番前に影 響確認 レビュー 不可 GitHub PR を通 じた変更レ ビューを必須化 環境の 再現性がない 同⼀構成を コードから即座 に再構築可能 野良リソースの 発⽣ システムユーザー のみが強い権限を 保持
15. © 2026 Snowflake Inc. All Rights Reserved AI時代だからこそ、 IaC化のメリットが大きい コード⽣成の⺠主化 AIがHCLコードを⽣成するため、Terraform 未経験者でもIaC運⽤が可能に 学習コスト激減 AIが構⽂やベストプラクティスを即座に提 案。学習時間が1/10に AIレビューが可能に コード化されているからAIによるレビューが 可能。GUI操作はレビューできない 属⼈化から脱却 コード+AIで誰でも理解‧修正が可能。 GUIの暗黙知が不要に AIがリソースを作る時代で、作成されたリ ソースがどんなものか確認するのは大変。 IaC化されていればAIが作成したリソースを コード上で確認できる
16. © 2026 Snowflake Inc. All Rights Reserved 途中からTerraformを導入する困難 技術的困難 • 既存リソースをTerraformで再定義し、stateにimportする⼤変な作業 • 数千近くの⼿動作成済みリソースの設定値を完全に反映させる必要がある ビジネス⾯の困難 • IaC化だけでは売上や利益は⽣まれない • 価値ある新機能開発が優先され、IaC化はどうしても優先度が下がりがち
17. © 2026 Snowflake Inc. All Rights Reserved Terraform導入のポイント
18. © 2026 Snowflake Inc. All Rights Reserved CI/CD・環境分割の方針 dev 開発者が⽇常的に検証‧試⾏ UIからの変更可 / ローカルから plan/apply可 stg 本番と同等構成の検証環境 developブランチが反映 / UIから の変更禁⽌ prod 本番データが存在 mainブランチ+リリースタグでのみ apply / UI変更禁⽌ → 本番環境にはGitHub Actionsから しかリソース変更できない設計 CI/CDパイプライン構成
19. © 2026 Snowflake Inc. All Rights Reserved Terraformのみの構成の課題感 各モジュールで同じProvider設定を重複して記述する必要がある # database/main.tf terraform { required_providers { snowflake = { source = "snowflakedb/snowflake" version = "~> 2.9" } } } provider "snowflake" { account = "your-account" user = "SYSTEM_TERRAFORM" role = "SYSADMIN" } # schema/main.tf ← 同じ設定を再度記述 terraform { required_providers { snowflake = { source = "snowflakedb/snowflake" version = "~> 2.9" } } } provider "snowflake" { account = "your-account" user = "SYSTEM_TERRAFORM" role = "SYSADMIN" } モジュールが増えるたびにこの重複が増殖 → Provider変更時に全ファイル修正が必要
20. © 2026 Snowflake Inc. All Rights Reserved Terragrunt導入 Provider設定を1箇所で管理 → 各モジュールはincludeで継承するだけ # root.hcl（全環境共通） generate "provider" { path = "provider.tf" if_exists = "overwrite_terragrunt" contents = <<EOF terraform { required_providers { snowflake = { source = "snowflakedb/snowflake" version = "~> 2.9" } } } provider "snowflake" { account = var.account_name user = "SYSTEM_TERRAFORM" role = var.role authenticator = "SNOWFLAKE_JWT" private_key_path = var.private_key_path } # database/terragrunt.hcl include { path = find_in_parent_folders("root.hcl") } terraform { source = "../../modules/database" } # schema/terragrunt.hcl include { path = find_in_parent_folders("root.hcl") } terraform { source = "../../modules/schema" } Provider変更時はroot.hcl 1箇所のみ → 全モジュールに⾃動反映
21. © 2026 Snowflake Inc. All Rights Reserved Terragruntを利用したディレクトリ構造 ./ ├── root.hcl # ルート設定（全環境共通） ├── common/ # 全環境共通のリソース定義 │ ├── databases.yaml │ ├── schemas.yaml │ ├── warehouses.yaml │ └── account_roles.yaml ├── envs/ │ ├── dev/ │ │ ├── env.hcl # 環境固有の変数 │ │ ├── common/ # dev環境固有のリソース定義 │ │ │ └── databases.yaml │ │ ├── database/ │ │ │ └── terragrunt.hcl │ │ ├── schema/ │ │ │ └── terragrunt.hcl │ │ └── warehouse/ ... │ ├── stg/ (同じ構造) │ └── prod/ (同じ構造) └── modules/ ├── database/ │ ├── main.tf / variables.tf / outputs.tf ├── schema/ ... └── warehouse/ ... root.hcl Provider‧Backend設定を全環境共通で⼀元管理 common/ databases‧schemas‧warehouses等をYAMLで 宣⾔。全環境で共有 envs/<env>/ env.hcl に環境固有の変数を定義。common/ で環 境固有リソースを追加。各リソースディレクトリ に terragrunt.hcl を配置 modules/ Terraformモジュール本体（main.tf / variables.tf / outputs.tf）。環境間で共通利⽤
22. © 2026 Snowflake Inc. All Rights Reserved # common/databases.yaml databases: analytics: name: ANALYTICS is_transient: false application: name: APPLICATION is_transient: false data_management: name: DATA_MANAGEMENT is_transient: false ‧Terraform経験がないメンバーの学習コスト ‧HCL構⽂の理解が運⽤参加の障壁に YAMLさえ書ければ運⽤可能に 課題 解決 common/databases.yaml YAMLベースのリソース定義
23. © 2026 Snowflake Inc. All Rights Reserved stateの分割戦略 # リソース種別ごとにディレクトリ = state分割 envs/prod/ ├── database/ │ └── terragrunt.hcl → state: database.tfstate ├── schema/ │ └── terragrunt.hcl → state: schema.tfstate ├── warehouse/ │ └── terragrunt.hcl → state: warehouse.tfstate ├── role/ │ └── terragrunt.hcl → state: role.tfstate └── grant/ └── terragrunt.hcl → state: grant.tfstate 実⾏時間の短縮 単⼀stateだとplan/applyが数⼗分〜数時間かかる リソース種別単位の分割で数秒〜数分に短縮 チーム開発の並列化 各担当者が独⽴したstate lockで同時作業可能 Database担当とRole担当が競合なく並列開発
24. © 2026 Snowflake Inc. All Rights Reserved Snowflake環境を途中から IaC化するポイント
25. © 2026 Snowflake Inc. All Rights Reserved 管理するSnowflakeリソース範囲を決める 管理ツール 対象リソース Terraform Warehouse / Database / Schema / Role / Grant / Policy / Service User など dbt Table / View（分析要件で頻繁に変更、SQLベースで馴染みやすい） 管理対象外 User（IdP連携を利⽤）
26. © 2026 Snowflake Inc. All Rights Reserved Cortex Code CLIによる既存リソースの洗い出し
27. © 2026 Snowflake Inc. All Rights Reserved Snowflake Terraform Providerのサイトをチェック ‧どのリソースがTerraformに対 応しているのかを確認できる ‧Preview中のリソースだと、 後々破壊的変更が⼊る可能性が あるので注意 https://registry.terraform.io/providers/snowflakedb/snowflake/latest/docs
28. © 2026 Snowflake Inc. All Rights Reserved 最新のリリース情報をチェックする ‧terraform-provider-snowflake のリリース頻度はとても多い ‧新規で対応されたリソースを チェックできる https://github.com/snowflakedb/terraform-provider-snowflake/releases
29. © 2026 Snowflake Inc. All Rights Reserved 既存リソースの importの大変さ terraform import とは GUIで⼿動作成済みの既存リソースをTerraformのstate管理下に取り込む作業 なぜ⼤変か ‧既存リソースの設定値をHCLで完全に再定義する必要がある ‧定義が不完全だとplanで差分が出続ける ‧数千近くのリソースを1つずつimportする必要がある ‧リソース間の依存関係も正しく定義しないといけない
30. © 2026 Snowflake Inc. All Rights Reserved 本番環境の import手順 Step 1 リソース情報取得 → YAML定義⽣成 Snowflake CLIでJSON取得し、AIに渡して YAML定義を⾃動⽣成 Step 2 importコマンド⾃動⽣成‧実⾏ YAML + JSONをAIに渡し、importスクリプト を⾃動⽣成 → 実⾏ Step 3 plan確認 → PR → apply planで"No changes"を確認するまで定義を 修正PRレビュー後にGitHub Actionsから apply # 1. リソース定義を書く resource "snowflake_database" "analytics" { name = "ANALYTICS" comment = "分析用データベース " # ...全パラメータを正確に記述 } # 2. importコマンドで stateに取り込み terragrunt import \ snowflake_database.analytics \ "ANALYTICS" # 3. planで差分がないことを確認 terragrunt plan # → "No changes" になるまで # 定義を修正し続ける ...
31. © 2026 Snowflake Inc. All Rights Reserved まとめ • データ基盤のIaC化は⻑期的に⼤きな価値を⽣む投資 • 組織のスケーラビリティ‧変更の安全性‧運⽤の効率性を実現 • AI開発が主流の昨今、基盤のIaC化は早期に取り組むほど恩恵が⼤きい • Terragrunt + YAML運⽤ + AI活⽤で導⼊‧運⽤のハードルを下げる
32. © 2026 Snowflake Inc. All Rights Reserved THANK YOU