Terragrunt を用いたスケーラブルな Snowflake インフラ管理 2025.9.29 シンプルフォーム株式会社 山岸 裕樹 

自己紹介 山岸 裕樹 (@roki18d) 2 シンプルフォーム株式会社でテックリードをやっています（インフラエンジニア, データエンジニア） ■ 経歴 株式会社NTTデータに新卒入社 ・分散処理技術 (Hadoop, Spark etc.) に関する R&D・PoC 案件 ・データ基盤・機械学習基盤の構築・運用支援案件 など 2018.4 ~ 2023.1 ~ シンプルフォームにインフラエンジニアとして参画 ・インフラエンジニア（Terragrunt 導入、開発環境整備、コスト最適化 … etc.） ・データエンジニア（データ基盤構築・運用・改善、Snowflake 移行 … etc.） - Snowflake Squad 2024 / SnowPro Core - 2025 Japan AWS All Certifications Engineer 

3 目次 1.1. Terraform 概要 1.2. Snowflake Provider の動き 1.3. 一般的な実装例 1.4. Terraform の課題感 1. Terraform について 2.1. Terragrunt 概要 2.2. Terragrunt の仕組み 2.3. Terragrunt 使用のメリット・注意点 2. Terragrunt について 3. Snowflake で Terragrunt を使用する 3.1. Snowflake 導入初期の構成 3.2. 初期構成で見えてきた課題 3.3. 改善後の構成と効果 3.4. その他の工夫ポイント・Tips 

4 目次 1.1. Terraform 概要 1.2. Snowflake Provider の動き 1.3. 一般的な実装例 1.4. Terraform の課題感 1. Terraform について 2.1. Terragrunt 概要 2.2. Terragrunt の仕組み 2.3. Terragrunt 使用のメリット・注意点 2. Terragrunt について 3. Snowflake で Terragrunt を使用する 3.1. Snowflake 導入初期の構成 3.2. 初期構成で見えてきた課題 3.3. 改善後の構成と効果 3.4. その他の工夫ポイント・Tips 

1.1. Terraform 概要 5 - HashiCorp 社が開発・提供する Infrastructure as Code (IaC) のためのツール - Terraform Cloud という有償版もあるが、CLI 操作であれば OSS でも利用可能 - AWS や Snowflake など、多くのプラットフォームが Provider を提供している （プラットフォームの操作が API 化されていれば、独自 Provider の定義も可能） (AWS) EC2 インスタンスの例 (Snowflake) Warehouse の例 

1.2. Snowflake Provider の動き 6 - 元々は、Chan Zuckerberg Initiative という団体が Provider の開発・管理を行っていた - その後、Snowflake 社が管理する GitHub リポジトリに 移管され、2024年1月には公式にサポートしていく ことを発表 - 多くの改修（破壊的変更を含む）が加えられ、 2025年4月の Version 2.0 リリースを以て GA - GA 後も継続的に改善されており、以下が新規に サポートされている（2025年9月現在は v2.7.0） → Compute Pool, Git Repository, Image Repository, Service & Jobs, Programmatic Access Token (PAT), Listing … etc. 2024.1 2024.12 2025.4 Terraform Provider を Snowflake 社が 公式にサポートしていくことを発表 Provider Version 1.0 がリリース GA に向けた設計の見直し、安定化 Provider Version 2.0 がリリース Snowflake 社による一般提供 (GA) となり、 現在も継続的に改善が行われている 

1.3. 一般的な実装例 (1/2) 7 - Terraform では、デプロイ対象リソース本体のコードとは別に、 作業ディレクトリ毎に メタ情報 にあたるコードが必要になる - メタ情報として記述する必要があるのは、Terraform 本体や 使用する各 Provider の バージョン情報、tfstate 管理に 関する バックエンド定義 … など terraform.tf 実装例 

1.3. 一般的な実装例 (2/2) 8 - 環境が複数存在する場合、それぞれで Terraform コードを 実装していると開発の効率性・保守性を損ねるため、 module に切り出して各環境から呼び出すのが一般的 STG 環境用 module.tf 本番環境用 module.tf 

1.4. Terraform の課題感 9 - モジュール化によってリソース本体のコードは DRY (*) になるが、 メタ情報のコードが DRY になっていない - （tfstate のオブジェクトキー以外）ほぼ共通的な内容であるが、 作業ディレクトリを増やす度に重複記述しなければならない → 作業ディレクトリを増やしづらい（スケールさせづらい） key 以外は基本的に同じ内容 （但し key は重複不可） (*) DRY … Don’t Repeat Yourself 

10 目次 1.1. Terraform 概要 1.2. Snowflake Provider の動き 1.3. 一般的な実装例 1.4. Terraform の課題感 1. Terraform について 2.1. Terragrunt 概要 2.2. Terragrunt の仕組み 2.3. Terragrunt 使用のメリット・注意点 2. Terragrunt について 3. Snowflake で Terragrunt を使用する 3.1. Snowflake 導入初期の構成 3.2. 初期構成で見えてきた課題 3.3. 改善後の構成と効果 3.4. その他の工夫ポイント・Tips 

2.1. Terragrunt 概要 11 - Gruntwork 社が開発・提供する Terraform のラッパーツール - メタ情報のコードも含めて DRY に記述できる - 使用感は、基本的には terraform コマンドが terragrunt コマンドに置き換わるのみ （その他、Terragrunt でのみで利用可能なコマンドもある） 

2.2. Terragrunt の仕組み (1/2) - root.hcl, terragrunt.hcl 12 子 親 root.hcl terragrunt.hcl 

2.2. Terragrunt の仕組み (1/2) - root.hcl, terragrunt.hcl 13 子 親 バックエンド定義 [親] - [子] の相対パスが 自動的に埋め込まれる variables.tf で定義されたモジュールへの入力 モジュール所在の指定 関数で上位ディレクトリを探索する （引数なしの場合、terragrunt.hcl） root.hcl terragrunt.hcl 

2.2. Terragrunt の仕組み (2/2) - コンテキスト共有 14 全環境共通のコンテキストを記述 環境内の共通コンテキストを記述 

2.3. Terragrunt 使用のメリット・注意点 15 - メリット ① find_in_parent_folders() 関数により、メタ情報や共通コンテキストの記述を DRY にできる。 結果的に、作業ディレクトリをスケールさせやすくなる。（≒ tfstate を分割しやすくなる） ② tfstate を分割することで、各 tfstate の管理対象リソースを少なくできるので、 plan , apply 時に 不要なリソース参照を削減でき、実行時間を大幅に短縮できる。 ③ tfstate を分割することで、複数メンバーが開発する場合に競合が起きづらくなる。 - 注意点 ① tfstate を細かく分割できてしまう分、どのリソースをどの tfstate (≒ 作業ディレクトリ) で管理しているのか 把握しやすいよう、事前の入念なディレクトリ設計が必要である。 ② tfstate がいくらでも増えてしまう想定での CI/CD 基盤を整備するのが大変。 

16 目次 1.1. Terraform 概要 1.2. Snowflake Provider の動き 1.3. 一般的な実装例 1.4. Terraform の課題感 1. Terraform について 2.1. Terragrunt 概要 2.2. Terragrunt の仕組み 2.3. Terragrunt 使用のメリット・注意点 2. Terragrunt について 3. Snowflake で Terragrunt を使用する 3.1. Snowflake 導入初期の構成 3.2. 初期構成で見えてきた課題 3.3. 改善後の構成と効果 3.4. その他の工夫ポイント・Tips 

Securable Objects Hierarchy 17 Overview of Access Control - https://docs.snowflake.com/en/user-guide/security-access-control-overview 

3.1. Snowflake 導入初期の構成 18 - Snowflake 導入決定後、まずインフラ管理方法の検討に着手 - オブジェクトレベル毎にディレクトリを切る案も考えたが、 結局、リソースタイプ毎に平に並べるディレクトリ構成とした - リソースタイプは、Snowflake の Terraform リソースタイプ snowflake_{ resource_type } から snowflake_ を除いたもの (*1) - 設計当時のディレクトリ構成の意図 ① ディレクトリ階層の深さを一段少なくできる (*2) ② リソースを作り始める際、オブジェクトレベルを意識する必要がなく、 認知負荷が低い（と当時は思った） (*1) 例えば function などは言語毎にリソースタイプが分かれているものなどは、サブディレクトリで さらに分割するものもある (*2) OS によっては、ファイルまでの絶対パス最大長の制限が厳しい場合があるので、なるべく長く なりすぎないように設計するのがベター 

3.2. 初期構成で見えてきた課題 (1/3) 19 - 運用する中で見えてきた事実 ① Snowflake リソースを Terraform で開発する際、 オブジェクトレベルを意識しない、ということはない = 平に並べる構成が、寧ろ認知負荷を増大させる要因になってしまった ② Database, Schema 毎にディレクトリを分離したくなる = メンバー毎に許可する Terraform 操作を制御可能にしておきたい 

3.2. 初期構成で見えてきた課題 (2/3) 20 子 Schema-Level オブジェクトが属する名前空間の 情報をハードコードする必要がある 

3.2. 初期構成で見えてきた課題 (3/3) 21 - 運用する中で見えてきた事実 ① Snowflake リソースを Terraform で開発する際、 オブジェクトレベルを意識しない、ということはない = 平に並べる構成が、寧ろ認知負荷を増大させる要因になってしまった ② Database, Schema 毎にディレクトリを分離したくなる = メンバー毎に許可する Terraform 操作を制御可能にしておきたい - 課題感 ① 名前空間の情報をハードコードする必要がある = バグが生じやすく、開発安全性の観点からも良いとは言えない ② 同一スキーマに属する別リソースタイプの作業ディレクトリへの 移動が面倒で、開発効率が良くない 

3.3. 改善後の構成と効果 (1/3) 22 - 改善時の変更点 ① オブジェクトレベルごとにディレクトリを分離 ② 名前空間（データベース・スキーマ）情報を設定ファイル namespace_vars.yaml に切り出し、動的に取得 

3.3. 改善後の構成と効果 (2/3) 23 terragrunt.hcl から名前空間情報のハードコードが なくなり、誤った値が渡されるリスクを排除 子 

3.3. 改善後の構成と効果 (3/3) 24 - 改善時の変更点 ① オブジェクトレベルごとにディレクトリを分離 ② 名前空間（データベース・スキーマ）情報を設定ファイル namespace_vars.yaml に切り出し、動的に取得 - 変更によって得られた効果 ① 開発のしやすさ 名前空間情報を動的に取得することで、ハードコードする必要がなくなり、 開発の安全性が向上した。 ② コロケーション 同一スキーマの terragrunt.hcl 同士が近くに配置されるようになり、 開発効率が良くなった。 ③ 認知負荷 ディレクトリ構成が Snowsight の Catalog (旧 Data) タブ上の表示と近くなり、 コードの見通しが良くなった。 

まとめ 25 - Terragrunt を使用することで、メタ情報も含めて DRY な Terraform 開発ができ、 スケーラブルなインフラ管理が実現しやすくなる - ただし、tfstate を細かくできてしまう分、事前の入念な設計が必要になる - Snowflake の場合、オブジェクトレベルを意識したディレクトリ構成を採ることで、 開発安全性が高く、認知負荷の小さい運用を実現できた 

3.4. その他の工夫ポイント・Tips（例外ケースの扱い） 26 - 原則、リソースタイプごとにモジュールを分ける方針にしているが、例外も認めることにしている。 - 例えば、Snowflake Schema を作成する際、一緒に Database Role も作成する場合が多い。 原則で言えば Schema とは分離することになるが、開発効率性の観点から同居させている。 - ただし、どの module で何のリソースの同居を認めるかの方針が定まっていないと、 Terraform 管理している作業ディレクトリの特定が困難になるので、ルールの整備・遵守が大事。 main.tf role_grant._ro.tf 

3.4. その他の工夫ポイント・Tips（dependencyブロック） 27 - terragrunt.hcl の dependency ブロックを使用すると、作業ディレクトリ間の依存関係を定義し、 確定した出力値を別の作業ディレクトリから参照させることができる - Module 出力値は outputs.tf で定義しておく 

3.4. その他の工夫ポイント・Tips（処理ロジックの分離） 28 - Snowflake リソースの中には、作成の際に処理ロジックを埋め込むものが存在する。 代表的なところでは、View, UDF/UDTF, Procedure … など。 - しかし、Terraform コードにヒアドキュメントで処理ロジックを埋め込んでしまうと保守性を損ない、 テストコードを用意するのも難しくなる。 - Terraform の file 関数を使用すると、処理ロジックの記述を外部ファイルに切り出すことが可能。 

3.4. その他の工夫ポイント・Tips（機密情報の IaC 管理） 29 - Terraform で作成するリソースの種類によっては、機密情報の指定が必要になる場合があるが、 平文で Git 管理するわけにはいかないので、暗号化する仕組みが必要になる。 - Mozilla が開発・提供する sops というツールと、Terragrunt の sops_decrypt_file 関数を 使用することで、暗号化キー（AWS KMS キー）などを用いた暗号化・復号化が可能。 - ただし、KMS であれば Decrypt 権限があれば機密情報にアクセスできてしまうので、 キーポリシーなどで適切に権限を付与する必要がある。 

参考 30 - Terragrunt で始めるマルチアカウント Snowflake 環境構築 https://zenn.dev/simpleform_blog/articles/20240701-multi-account-snowflake-with-terragrunt - Snowflake リソースの Terragrunt 管理方法を改めた話 https://zenn.dev/dataheroes/articles/20250420-snowflake-iac-redesign-with-terragrunt - Terraform で作る Snowflake UDF / UDTF https://zenn.dev/dataheroes/articles/20240908-snowflake-udf-udtf-with-terraform - sops × Terragrunt で機密リソースを安全に IaC 管理する https://zenn.dev/simpleform/articles/20230123-01-secrets-with-sops-and-terragrunt 

おわり 31 ご清聴ありがとうございました！