Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform

https://snowflake-event.jp/world-tour-25/content/LC-102/

Terraformで構築するセルフサービス型データプラットフォーム
中央集権管理からの脱却とデータオーナードリブン開発の実践

データプラットフォームの成長と共に、データチームの中央集権的な体制が開発速度のボトルネックとなるケースは少なくありません。データオーナーへの開発委譲を進めたくても、双方の知識領域が異なるためそれは容易ではありません。当社ではTerraformによるモジュール化でセルフサービス型データ基盤を構築し、知識ギャップを技術的に解決することでデータオーナードリブンな開発体制への転換を実現しました。組織の責任分担を再設計し、開発効率を大幅に向上させた2年半の取り組みを、具体的な実装手法とともに解説します。

Transcript

1. 中央集権管理からの脱却と データオーナードリブン開発の実践 近森淳平 @pei0804 Vice President of Data | CARTA ZERO 竹内 晴貴 データエンジニア | CARTA ZERO Terraformで構築する セルフサービス型データプラットフォーム LC-102
2. © 2025 Snowflake Inc. All Rights Reserved 2 https://techblog.cartaholdings.co.jp/entry/a-third-year-data-engineer-first-appearance-snowflake-summit-2025
3. アジェンダ • はじめに • データオーナーが必要になった理由 • データオーナードリブンの課題 • なぜTerraformを採用したか • Terraformを使った具体的なアプローチ
4. 4 CARTA ZERO - VP of Data CARTA HOLDINGS Data Superheroes 24, 25 @pei0804
5. はじめに
6. © 2025 Snowflake Inc. All Rights Reserved 6 2019年にサイバー・コミュニケーションズとVOYAGE GROUPが 経営統合して誕生した企業です。 デジタルマーケティング、メディア運営、Eコマース、人材サービスなど、 多様な領域で事業を開発しています。 の紹介
7. © 2025 Snowflake Inc. All Rights Reserved 7 2025年7月にCARTA COMMUNICATIONS、CARTA MARKETING FIRM、Barriz の3社を統合して誕生したデジタルマーケティング企業です。 統合的なマーケティングソリューションを武器に、 クライアントの本質的な課題解決と事業成長を支援しています。 の紹介
8. © 2025 Snowflake Inc. All Rights Reserved 8 Snowflakeのユースケース データプラットフォーム "Vision" CARTA ZEROには、 様々な種類のデータがあります。 これらの全てのデータを 1箇所に集約 し、 日々活用しています。 将来的に全てのビジネスプロセスを 分析可能にし、RevOps基盤にします。
9. © 2025 Snowflake Inc. All Rights Reserved 9 データプラットフォーム アーキテクチャ
10. © 2025 Snowflake Inc. All Rights Reserved 10 https://findy-tools.io/companies/cartazero/145/36
11. © 2025 Snowflake Inc. All Rights Reserved 11 データプラットフォームの開発体制
12. © 2025 Snowflake Inc. All Rights Reserved 12 プラットフォームの構築・運用しています。 管理だけではなく、活用支援も行います。 活用ガイドラインを作成したり、 時にはデータを作るとこから支援もします。 データプラットフォームチームは、 以降データチームと呼びます。 データプラットフォームチームの責任範囲
13. © 2025 Snowflake Inc. All Rights Reserved 13 データプラットフォームを用いて、 データをビジネス価値に展開しています。 具体的には、データをロード・変換・提供まで担当 しています。 データオーナーは、主にプロダクトチームが担って いて、彼ら自身が作ったデータを、 自分たちで運用するような体制になってます。 データオーナーの責任範囲
14. © 2025 Snowflake Inc. All Rights Reserved 14 データオーナーは最初から存在していたわけではありません。 データ活用レベルの進化に伴って、必要な存在になりました。 プラットフォームの立ち上げ当初は、中央集権的に開発していました。 しかし、データ活用レベルの向上するにつれ、 中央集権的な開発は、機能しなくなりました。 その結果、作ったデータに対して責任を持つ体制を徐々に移行しました。 中央集権の限界から、データオーナーが誕生した
15. データオーナーが 必要になった理由
16. © 2025 Snowflake Inc. All Rights Reserved 16 開発体制の変遷 1.中央集権型 2.開発委譲型 3.データオーナードリブン型
17. © 2025 Snowflake Inc. All Rights Reserved 17 中央集権型 データプラットフォームの 立ち上げ当初はデータチームが 全ての開発プロセスを担当。 この体制を採用したことで、 スピーディな意思決定と開発を実現。 その結果、立ち上げを迅速に 完了することが出来ました。（ 3ヶ月）
18. © 2025 Snowflake Inc. All Rights Reserved 18 Snowflakeの採用背景について https://speakerdeck.com/pei0804/data-cloud-world-tour-tokyo-2023 https://speakerdeck.com/pei0804/strongest-data-architecture-discussion
19. © 2025 Snowflake Inc. All Rights Reserved 19 中央集権体制の開発速度に限界が見えた データプラットフォームが 活用されるようになり、 要望も順調に増えてきました。 しかし、要望に応えることが 手数的に困難になってきました。 その結果、活用のボトルネックが データチームという構造になりました。 ボトルネック
20. © 2025 Snowflake Inc. All Rights Reserved 20 2.開発委譲型 この問題を解消するために、 基本的な開発タスクは、 利用者自身で行うことにしました。 開発したものを、データチームは、 レビューする体制に移行しました。
21. © 2025 Snowflake Inc. All Rights Reserved 21 レビューがボトルネックへ 最初はうまく作用しましたが、 開発ペースが早くなってきた結果。 今度は、レビュープロセスが ボトルネックになり始めました。 ボトルネック
22. © 2025 Snowflake Inc. All Rights Reserved 22 データチームの人数に対して、 レビューが多すぎるというのと、 特にクリティカルだったのはレビューに 必要な知識が足りてないことです。 Snowflakeについては詳しいのけど、 データの意味や背景を知らない そのため、レビューを行うためには、 まずデータの文脈と目的について 学ぶ必要があります。 知らないデータのレビューは時間がかかる 重要な事実
23. © 2025 Snowflake Inc. All Rights Reserved 23 レビューをしても障害は起きました。 段々とこの開発体制自体に 欠陥があるとわかってきました。 要因分析をして分かったこととして、 真にレビューを成立させるには、 データとビジネスに関する深い理解 が 不可欠であると分かりました。 データチームによるレビューが機能不全に陥る 機能不全
24. © 2025 Snowflake Inc. All Rights Reserved 24 試しに、各チームにデータに関する開発の 全てを任せるようになりました。 この体制は効果的に作用しました。 これによって分かったことは、 データのことを分かっている人たち が、 データの開発、レビューをすることが、 本質的には重要だったということです。 3.データオーナードリブン型
25. © 2025 Snowflake Inc. All Rights Reserved 25 データオーナードリブンへの道のり https://speakerdeck.com/pei0804/centralized-to-dataops-transformation https://speakerdeck.com/pei0804/journey-to-dataops
26. © 2025 Snowflake Inc. All Rights Reserved 26 データオーナーが開発に慣れてくると、 より多く開発プロセスを自分たちで行うようになりました。 例えば、 • ロールの作成 • ロールへの権限付与 • 新しいデータソースの追加 • ユーザーの作成 また、データチームの人員をすぐに増やすことができなかったため、 徐々にデータオーナーにより多くの裁量を与えました。 データオーナー裁量の拡大
27. データオーナードリブンの課題
28. © 2025 Snowflake Inc. All Rights Reserved 28 データオーナーにより多くの裁量を与えた結果、開発速度は向上しました。 しかし、障害発生という形で、問題も発生しました。 最も多かった原因は、Snowflakeに関する知識不足によるものです。 当時、この現象については「成長痛」と捉えました。 なぜなら新しいことを始める際には、常に課題が出てくるもの。 以前の中央集権型に戻したところで、問題を真に解決できないため、 根本原因の解消に焦点を当てることにしました。 体制変更による成長痛
29. © 2025 Snowflake Inc. All Rights Reserved 29 データオーナーは自分たちのデータ とビジネスについて多くの知識を 持っていますが、Snowflakeに関する 知識は相対的に浅いです。 そのため、Snowflakeの技術的な 間違いを犯すことがありました。 誤った変更が発生する理由 重要な事実
30. © 2025 Snowflake Inc. All Rights Reserved 30 Q. データオーナーがSnowflake詳しくなればいいのでは？ A. No データオーナーにとって重要なのは、データを使って課題を解決すること。 Snowflakeは、それを実現するためのツールに過ぎません。 彼らの興味関心を鑑みると、Snowflakeを詳細に学ぶメリットは薄い。 そのため、Snowflakeの専門家になることを、期待すべきではないと考えます。 ※勿論詳しくなってもらっても良いけど、それは再現性のある動きではない。 Snowflakeはデータ活用の手段
31. © 2025 Snowflake Inc. All Rights Reserved 31 データオーナーにSnowflakeの仕組みを抽象化せずに、 そのまま渡すと間違う可能性があります。 この問題を解決するために、複雑さをうまく抽象化する必要がありました。 この抽象化レイヤーとして、 Terraformを採用しました。 抽象化レイヤーとしての Terraform
32. なぜTerraformを採用したか
33. © 2025 Snowflake Inc. All Rights Reserved 33 Terraform Snowflake Providerは、 HashiCorp TerraformとSnowflakeを接続する公式プラグインです。 宣言的なコードを使用して、データベース、スキーマ、ロールなどの 様々なSnowflakeリソースを定義・管理することができます。 インフラストラクチャのバージョン管理と自動化により、 開発環境から本番環境まで一貫したリソース管理が可能になります。 Terraform Snowflake Providerについて
34. © 2025 Snowflake Inc. All Rights Reserved 34 • 宣言的アプローチ ◦ 「あるべき状態」 を定義できるお陰で、 現在の状況を簡単に理解できる • Gitとの統合 ◦ インフラストラクチャ変更の履歴管理、レビュー、ロールバックが容易 • スケーラビリティ ◦ モジュールを使ったよくある実装パターンを簡単に配れる、管理できる • 依存関係の自動解決 ◦ リソース間の関係を考慮した適切な実行をしてくれる（全部ではない） Terraform採用の決め手
35. © 2025 Snowflake Inc. All Rights Reserved 35 Flywayのようなマイグレーションツールは 採用しませんでした。 仕組み上、現在の状態を理解することが困難であり、 レビューやロールバックが難しくなるからです。 次にマイグレーション方式と Terraformのアプローチの違いを示します。 なぜマイグレーションツールを選ばなかったのか
36. © 2025 Snowflake Inc. All Rights Reserved 36 Terraform Flyway resource "snowflake_database" "a_db" { name = "A_D" } resource "snowflake_schema" "a_schema" { database = snowflake_database.a_db.name name = "A_S" } Terraform vs Flyway: リソース作成 -- V1__create_initial_schema.sql CREATE DATABASE A_D; CREATE SCHEMA A_DB.A_S
37. © 2025 Snowflake Inc. All Rights Reserved 37 Terraform Flyway resource "snowflake_database" "a_db" { name = "A_D" } - resource "snowflake_schema" "example_schema" { - database = snowflake_database.example_db.name - name = "A_S" - } Terraform vs Flyway: リソース削除 -- V2__drop_schema.sql DROP SCHEMA A_DB.A_S;
38. © 2025 Snowflake Inc. All Rights Reserved 38 Terraform Flyway resource "snowflake_database" "a_db" { name = "A_D" } Terraform vs Flyway: 最終的な成果物 -- V1__create_initial_schema.sql CREATE DATABASE A_D; CREATE SCHEMA A_D.A_S; -- V2__drop_schema.sql DROP SCHEMA A_DB.A_S;
39. © 2025 Snowflake Inc. All Rights Reserved 39 中央集権型の開発体制で始まったデータプラットフォームの立ち上げから、 徐々にデータオーナードリブン開発 に移行しました。 しかし、データオーナーにとってSnowflakeを理解して実装することは、 困難であると分かりました。 この問題を解決するための、 抽象化レイヤーとして Terraformの採用しました。 まとめ：なぜ Terraformを採用したか
40. 40 CARTA ZERO - Data Engineer CARTA HOLDINGS 竹内 晴貴
41. Terraformを使った 具体的なアプローチ
42. © 2025 Snowflake Inc. All Rights Reserved 42 Terraformを使って管理することのメリットがはっきりしているリソース のみ • Snowflakeを使う上で必要不可欠なリソース ◦ user, role, warehouse, database, integrationなど • 他のクラウドサービスと組み合わせて使う必要があるもの ◦ 複数環境での一貫性を担保するため • 重要なaccount parameters ◦ セキュリティやガバナンスに関連するもの Terraformを使ったリソース管理の方針
43. © 2025 Snowflake Inc. All Rights Reserved 43 • dbtのライフサイクルに含まれるもの ◦ schemaやtable ◦ これらは頻繁に作成・更新される • Terraformリソースが存在しないもの ◦ webhook notification integrationやgit integration ◦ 管理するメリットがはっきりしているものであれば、snowflake_executeを利 用 • 実験や開発のために一時的に作っているもの Terraformで管理していないリソース
44. © 2025 Snowflake Inc. All Rights Reserved 44 データチーム データオーナー • データオーナーが使うmoduleを作る • ベストプラクティスを組み込む • CI/CDのメンテナンス • TerraformとTerraform Providerの バージョンアップ • moduleを使ってリソースを作成する • 作成したリソースの管理 データチームとデータオーナーの責務
45. © 2025 Snowflake Inc. All Rights Reserved 45 Module化によって以下を実現する • 必要なリソースをまとめて作成する • データオーナーにとって必要なものだけをinputとする ◦ 技術的な複雑さをModule内部に隠す データオーナーはどうやって作るか、ではなく何を実現したいかに集中できる データオーナーのためのシンプルなモジュール設計 抽象化による複雑さを閉じ込める
46. © 2025 Snowflake Inc. All Rights Reserved 46 • snowpipe • warehouse • external table • database • functional role • user (human, bot) • etc… Moduleの例
47. © 2025 Snowflake Inc. All Rights Reserved 47 S3バケット（データソース）とDatabase以外（永続化層）のリソースを 一つのmoduleとしてまとめて作成している Snowpipe Moduleの概要
48. © 2025 Snowflake Inc. All Rights Reserved 48 S3を使ったデータロードに関するドキュメント docs.snowflake.com/ja/user-guide/data-load-snowpipe-auto-s3 • 3つの選択肢があるが、どれを使うべきか ◦ どのやり方も複雑 • 毎回データチームのサポートが必要になることが予想される Snowpipeを使ったデータロードの複雑さ Snowpipe guide
49. © 2025 Snowflake Inc. All Rights Reserved 49 module "example_snowpipe" { source = "../modules/snowflake/snowpipe" database_name = "RAW" schema_name = "EXAMPLE_SNOWPIPE" bucket_name = "example_bucket" s3_notification_sns_topic_name = "S3_SNS_TOPIC_NAME" pipe_configs = [{ pipe_name_suffix = "sample_logs" path_prefix = "/sample_logs/" select_s3_partition = local.sample_logs_partition }] } Snowpipe Moduleのインターフェース
50. © 2025 Snowflake Inc. All Rights Reserved 50 データチーム データオーナー • Storage Integration用のIAM RoleとIAM Policy • カラム定義 ◦ “schema on read”のために固定 ◦ 一つのカラムにJSONをそのまま入れ ている • 各リソースの命名規則 • データロード先のDB名 • データロード先のSchema名 • どのS3バケットのデータをロードする か • Pipeの設定 ◦ Pipeの名前 ◦ S3のpath prefix ◦ S3のpathからtimestampを抽出す るロジック Snowpipe Moduleの責任範囲
51. © 2025 Snowflake Inc. All Rights Reserved 51 データオーナーしか知らないこと とデータチームとして守ってほしいこと をそれ ぞれ分離する。 Moduleの責任範囲の考え方 データオーナーしか知らないこと ModuleのInput データチームが守ってほしいこと Module内部で実装
52. © 2025 Snowflake Inc. All Rights Reserved 52 • warehouseとaccess roleをまとめて作成する • access roleに必要なprivilegesをgrant • access roleをfunctional roleにgrant Warehouse Moduleの概要
53. © 2025 Snowflake Inc. All Rights Reserved 53 module "warehouse_example_xs" { source = "../modules/snowflake/warehouse" name = "example_xs" size = "xsmall" statement_timeout_in_seconds = 3600 max_cluster_count = 3 min_cluster_count = 1 cluster_scaling_policy = "STANDARD" usage_roles = ["ROLE_A", "ROLE_B"] } Warehouse Moduleのインターフェース
54. © 2025 Snowflake Inc. All Rights Reserved 54 データチーム データオーナー • 命名規則 ◦ Role名 • Roleの構造 • 権限管理 • Warehouse名 • Warehouseのサイズ • クラスター数 • タイムアウトまでの時間 • どのFunctional RoleがWarehouseを 使いたいか Warehouse Module の責任範囲
55. © 2025 Snowflake Inc. All Rights Reserved 55 1. Pull Requestの作成 2. Github Actions上でTerraform Planを実行 3. データオーナー同士で レビュー 4. ローカルでTerraform Applyを実行 5. Pull Requestのマージ データオーナーのリリースフロー
56. © 2025 Snowflake Inc. All Rights Reserved 56 Terraformの変更を検知しPlan結果がPull Requestにコメントされるようにしている。 差分が理解しやすい。 以下のOSSを利用。 github.com/suzuki-shunsuke/tfcmt. Pull Request上でのTerraform Plan
57. © 2025 Snowflake Inc. All Rights Reserved 57 データオーナーに考えてほしいポイントをModuleのinputとして表現。 データチームとして守ってほしいポイントをModule内に閉じ込める。 この設計方針によりガバナンスを効かせつつ、 データオーナーによる自律的な開発ができるようになりました。 まとめ：Terraformを使った具体的なアプローチ
58. THANK YOU