Share
Embed
Terragrunt x Snowflake + dbt で作るマルチテナントなデータ基盤構築プラットフォーム
FrostyFridayの配信を隔週でやってまーす
Terragruntはいいぞ!インフラ(Terragrunt/Terraform)とデータアプリ(dbt, DAG)を分けてマルチなテナント・組織向けなデータ基盤を作るお話をしようかな〜
Gaku TASHIRO
May 18, 2026
Transcript
53 slides
-
Terragrunt x Snowflake + dbt で作る マルチテナントなデータ基盤構築プラットフォーム 2026年5月18日 ちゅらデータ 田代
学 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. -
• 自己紹介 • Terraformとは • Terragruntとは • データ基盤を作るに辺り、どこで何をするか • 初期構築/インフラ構築/データアプリケーション構築の境界
• マルチテナント(組織)向けデータ基盤プラットフォーム • レポジトリディレクトリ構成例の紹介 • CI/CD概要 • まとめ © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 本日のAgenda -
• データパイプライン(データ・アプリケーション)をどう作るか?(dbtとDAG) • データモデリング(Raw、Intermediata、Mart)どうするか? • ロール設計(RBACなやつ) • 生成AIの活用! © 2026
Chura DATA inc. PROPRIETARY & CONFIDENTIAL. やらないこと -
• 名前:田代 学(がく) • 1974年12月12日生まれ(51歳) • 奈良県奈良市出身 • 埼玉県川越市在住 •
略歴 • Sharp株式会社に新卒で入社 • 株式会社サイバーエージェントにてサーバーサイドエンジニア→ データエンジニア→16年働いてました • 2022年9月ちゅらデータにJOIN(在職3年半) • Snowflakeコミュニティ • Snoflake Squad 2026 • Frosty Friday Live Challenge やってます! • 2年ほどやってます。隔週木曜日に公開! • 真夜中のデータエンジニアリングユニオン 隔週日曜日22時開催 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 自己紹介 -
• Frosty Fridayとは • https://www.frostyfri.day/ • Snowflakeのスキルを練習し、向上させるための、毎週 のチャレンジシリーズ • Frosty
Friday Live Challengeとは • Youtube Live、隔週木曜日22時 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Frosty Friday Live Challange -
• Frosty Fridayとは • https://www.frostyfri.day/ • Snowflakeのスキルを練習し、向上させるための、毎週 のチャレンジシリーズ • Frosty
Friday Live Challengeとは • Youtube Live、隔週木曜日22時 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Frosty Friday Live Challange チャレンジャー絶賛募集中! -
• 2026年5月号 • 第2特集 モダンなデータ基盤設計の最前線 • 2章 モバイルデータパイプライン構築の実践 書きました!書いちゃいました! ©
2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 最近、SoftwareDesign誌に寄稿しました -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 次回の技術書典#21では dbtの薄い本
vol.2 リベンジするつもりです! -
• HashiCorp製のオープンソースInfra as Code(IaC)ツール • インフラを宣言的に管理 • AWSやSnowflakeなど多くのプラットフォームがProviderを提供 • バージョン管理が可能
• planで差分確認し、applyで構築 • stateファイルで状態を管理 • Terraform-provider-snowflakeの最新版は、v2.16.0 • https://registry.terraform.io/providers/snowflakedb/snowflake/latest • 注意)現在は、snowflakedbで提供、Snowflake-Labsは古いので注意 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Terraformとは -
• メタ情報のコードがDRYにならない • provider.tfとかいろんなディレクトリに配備必要 • Backendをs3などにすることができるが、環境ごとに分けることが難しい • ハードコーディング必要的な • 以前は、DynamoDBが必要だったが今は不要
• Stateファイルが大きくなる問題 • Terraformが大きくなってくるとPlanやApplyに時間が大きくかかるように • 分割してチームでの開発がしにくい © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Terraformの課題 -
• Gruntwork社が開発するTerraformの「薄い」ラッパーツール • terraformのサブコマンドがそのままterragruntに置き換わるだけ • v1.0.0 リリース!(2026年3月31日) • 最新版は、v1.0.4 ©
2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Terragruntとは -
• メタ情報のコードもDRYに記述できる • provider.tf が一つでOK • Backend設定も一つでOK、generateコマンドで自動生成・配置 • Steteファイルの分割が楽 •
チーム開発がしやすい • 環境間での影響を分離可能 • plan/apply の時間が短縮可能 • 分割したStateファイル間での依存関係もかける • ・・・が、結構めんどい • ルートのtfファイル(root.tfとかterragrunt.hcl)に共通定義 • find_parent_folders がめっちゃ強力 • 各環境では、親terragrut.hclをincludeして、差分だけ書けばOK • Run-all でディレクトリ配下全部実行可能 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Terragruntのメリット -
• メタ情報のコードもDRYに記述できる • provider.tf が一つでOK • Backend設定も一つでOK、generateコマンドで自動生成・配置 • Steteファイルの分割が楽 •
チーム開発がしやすい • 環境間での影響を分離可能 • plan/apply の時間が短縮可能 • 分割したStateファイル間での依存関係もかける • ・・・が、結構めんどい • ルートのtfファイル(root.tfとかterragrunt.hcl)に共通定義 • find_parent_folders がめっちゃ強力 • 各環境では、親terragrut.hclをincludeして、差分だけ書けばOK • Run-all でディレクトリ配下全部実行可能 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Terragruntのメリット 使わない理由がない! -
• もともと2つのDevOpsコンサル(?)会社 • Terraformをつくりまくり • 同じ解決策を毎回作り直していることに気づく • →再利用可能なスクリプト・テンプレート・ベストプラク ティスのライブラリを作成したった •
ビジネスモデルは • Terragrunt本体は無料のOSS • 収益はEnterpriseサポート・コンサル・モジュールライ ブラリ • という典型的なオープンコアモデル © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Gruntwork社とは -
• もともと2つのDevOpsコンサル(?)会社 • Terraformをつくりまくり • 同じ解決策を毎回作り直していることに気づく • →再利用可能なスクリプト・テンプレート・ベストプラク ティスのライブラリを作成したった •
ビジネスモデルは • Terragrunt本体は無料のOSS • 収益はEnterpriseサポート・コンサル・モジュールライ ブラリ • という典型的なオープンコアモデル © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Gruntwork社とは -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. SimpleForm山岸さんの 「DataOpsNight#8Terragruntを用いたスケーラブルなSnowflakeインフラ管理」
Zenn:Snowflake リソースの Terragrunt 管理方法を改めた話 必読の資料 -
1. 初期構築 • 手動で実行 • Terragruntでall destroyしても、再度applyでインフラ構築可能 • → Terragruntですべてのリソースは管理しない
2. インフラ構築 • ユーザやロール、データベースオブジェクト、スキーマ • ※テーブルは作ってない 3. データアプリケーション(データパイプライン)開発 • テーブルやストアドプロシージャなど • DAG、データモデリング © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 大きく分けて3つ(初期構築・インフラ構築・データ・アプリケーション開発) データ基盤を作るに辺り、どこで何をするか -
• Terraform関連の設定 • データ関連のロール作成(SYSADMIN系) • ユーザ・ロール定義関連のロール作成(SECURITYADMIN系) • グローバル権限の付与 • EXECUTE
TASK、CREATE DATABASE等(Pre-Defined System Role使うなら不要) • Terraform用Warehouseの作成 • Terraformユーザの作成 • DBT用ユーザ、コストモニター用の作成 • 色々強めのロール必要だったりするやつ © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜初期構築 Terragruntですべてのリソース管理はしない ↓ Terragruntでall destroyしても動かせば再度構築で きるようにするため すべてをIaCで管理しない。destoryしても再度構築可能な状態へ -
• データベース/スキーマ • ロール(アカウントロール、データベースロール、アプリケーションロールなど) • ユーザ(サービスユーザ、場合によってはパーソンユーザも) • ウェアハウス、タグ、ポリシー、インテグレーション • 外部ステージ、外部ボリューム(S3の構築なども含めて)
• ストアドプロシージャやUDF(共通) © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜インフラ構築 変更頻度が低く、意図せず変わらないもの。PRでのチェック、環境差分なくす -
• データベース/スキーマ • ロール(アカウントロール、データベースロール、アプリケーションロールなど) • ユーザ(サービスユーザ、場合によってはパーソンユーザも) • ウェアハウス、タグ、ポリシー、インテグレーション • 外部ステージ、外部ボリューム(S3の構築なども含めて)
• ストアドプロシージャやUDF(共通) © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜インフラ構築 Providerが対応していないものは・・・・ツライ Shell書いたり、 snowflake_execute使ったり 変更頻度が低く、意図せず変わらないもの。PRでのチェック、環境差分なくす -
• テーブル(取込) • こちらでやっちゃってます • フォーマットやストアドプロシージャ(個別) • DAGの構築 • データ取込(COPY
INTO) • dbtの実行 • ※データ取込の前に、データのバリデーションを入れることも • データモデリング(dbt) • Raw層、Cleansing層、Intermediata層、Mart層 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜データアプリケーション構築 変更頻度:高、ビジネスロジックが入るもの -
• データ取込テーブルの定義の例 • DAG( • dbt © 2026 Chura DATA
inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜データアプリケーション構築 基本、取込テーブルなどは dbtでやってます(Posthookなど) select null::varchar as METADATA_FILENAME, null::int as METADATA_FILE_ROW_NUMBER, null::datetime as METADATA_FILE_LAST_MODIFIED, null::datetime as METADATA_START_SCAN_TIME, null::varchar as UP_DATE, null::varchar as UP_TIME, null::varchar as SHIP_NO, null::varchar as TABLE_NAME where false {{ config( tags=["fileformat"], pre_hook="CREATE OR REPLACE FILE FORMAT HOGE TYPE = CSV COMPRESSION = 'NONE‘ (中略) ERROR_ON_COLUMN_COUNT_MISMATCH = FALSE REPLACE_INVALID_CHARACTERS = FALSE EMPTY_FIELD_AS_NULL = TRUE SKIP_BYTE_ORDER_MARK = TRUE ENCODING = 'SHIFTJIS'" ) }} -- フォーマット作成用テーブル(処理用のダミーテーブル) select 1 as dummy_column 取込テーブルのモデル(_load_hoge.sql) fileformatのモデル(_fileformat_hoge.sql) -
• 初期設定 vs インフラ(IaC) • Terragruntですべてのリソースを管理しない • Destroy しても再構築できるように •
インフラ(IaC)とデータアプリケーション • インフラは「意図せず変わらない」「変更頻度:低」 • データアプリケーションは「変更頻度:高」 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. データ基盤を作るに辺り、どこで何をするか〜考え方のまとめ 迷ったら 「頻繁に変えたいか、変えたくないか」 それぞれの境界の考え方 -
• 技術要素 • Snowflake • dbt-core ( OSS ) •
AWS • S3 • MWAA • ECS Fargate ( dbtの実行環境) • Terragrunt • Github Enterprise, Github Actions (Self-Hosted Runner) • aqua cli © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. マルチテナント向けデータ分析基盤プラットフォーム 要素技術 -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 3層構造に分けることで実リソースの影響範囲を分離 設計思想:3層構造〜プラットフォーム・プロバイダ・テナント
プラットフォーム 全体 プロバイダ/◯◯本部 エンドユーザーが利用する サービス提供元 プラットフォーム プロバイダA/営業本部 プロバイダB/経理本部 プロバイダC/技術本部 テナント エンドユーザー テナントA1 1局 テナントA2 1局 共通テナントC1 CoE テナントB1 業務推進 テナントB2 経理部 -
• マルチテナント/組織向けデータ分析基盤プラットフォーム • プラットフォーム/会社 • Snowflake、AWSなど。全体 • プロバイダ/◯◯本部 • 親テナントでもある。サービス提供元
• (営業本部とか経理本部とか、そういうレイヤー) • テナント/〇〇局 • エンドユーザ。子テナントでもある • (営業本部1局、2局みたいな、そういうレイヤー) © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. 今回は3層にしてますが、2層でもいいかも 3層について -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. テナント/部署はDBで分離(Snowflakeは環境ごとに1アカウント) スキーマ構造を共通、IFは外部ステージ、各テナント/部署のデータを受け取り、モデリングして、BIなどで閲覧
最終的なデータプラットフォームのアーキテクチャ Snowflake 主アカウント AWS テナントA用DB テナントB用DB テナントC用DB Databricks RAW MART MWAA ECS RAW MART RAW MART 別Snowflake Webアップローダ S3レプリ データシェアリング -
レポジトリ の ディレクトリ構成 © 2026 Chura DATA inc. PROPRIETARY &
CONFIDENTIAL. -
• .github • workflow(CI/CD) • applications • MWAAのDAG, • dbt
• infrastrunctures • init : 初期スクリプト • terragrunt : インフラ © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. レポジトリ構成〜概要 モノレポで構成 -
• aws • snowflake © 2026 Chura DATA inc. PROPRIETARY
& CONFIDENTIAL. レポジトリ構成〜初期設定(インフラ) infrastrunctures ディレクトリに配備 -
• live • 「どこに・何を・どの設定で作るか」を入れる場所 • 環境:dev, stg, prd • modules
• 「どう作るか」の定義を入れる場所 • root.hcl • 「全環境共通の設定をまとめた親ファイル」 • 子の terragrunt.hcl から include ブロックで読み込み、 DRYに設定を継承させる © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. レポジトリ構成〜インフラ(Terragrunt) live/ と module/ , root.hcl ※命名はTerragruntのベスプラより -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. レポジトリ構成〜インフラ(Terragrunt) modules/
• common • provider.tf.tmpl • 共通設定 • platform • provider • tenant • 3層構造 -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. レポジトリ構成〜インフラ(Terragrunt) live/
• env_vars.hcl • 環境ごとの設定 • platform_vars.hcl • provider_vars.hcl • tenant_vars.hcl • それぞれのレイヤーでの設定 • terragrunt.hcl • 親ディレクトリの root.hcl をinclude -
• platform • 共通で使うアプリ • Provider • プロバイダ/組織ごと • dbt/mwaa
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. レポジトリ構成〜データアプリケーション(DAG、dbt) モノレポで構成 -
• Branch: • 作業ディレクトリのパス: • infrastructures/terragrunt/live/<環境>/ • platform/snowflake • tenant/eigyo/common/snowflake
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Git Action Workflowによるインフラのリリース -
© 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. Git Action
Workflowによるインフラのリリース -
• Infurastructure as Codde (Terraform/Terragrunt)とはなにか? • データ基盤を作るに辺り、 • 初期構築(手動) •
インフラ構築 by IaC ( Terragrunt ) • データアプリケーション開発 © 2026 Chura DATA inc. PROPRIETARY & CONFIDENTIAL. まとめ -
終わりに(宣伝) • We're Recruting !!! • 積極チャレンジャー募集中です! • FrostyFridayやってみませんか! •
気軽にDMをくださいね! • SnowVillageの #frostyfridayでも!