Snowflakeでデータ基盤を もう一度作り直すなら / rebuilding-data-platform-with-snowflake

https://www.snowflake.com/build-japan-online/

Data Superhero セッション：Snowflakeでデータ基盤をもう一度作り直すなら：初期段階で検討しておきたいこと
データ基盤設計には、一度決定すると変更コストが極めて高い要素が多数あります。
例えば、アカウント分割、権限設計、データベース粒度、周辺ツール選定など、3年以上の運用で学んだ「後悔しても遅い」設計判断のポイントを共有し、技術的負債を回避するための判断基準を提供します。(個別のQ&A対応はありません)

Transcript

1. © 2025 Snowflake Inc. All Rights Reserved 初期段階で検討しておきたいこと Snowflakeでデータ基盤を もう一度作り直すなら 近森 淳平 pei Data Superhero
2. https://speakerdeck.com/pei0804/strongest-data-architecture-discussion
3. Snowflakeベースのデータ基盤を構築してから、 ちょうど3年が経ちました。 この間、弊社の株主、経営体制、開発体制、肩書。 Snowflake自体の進化やChatGPTの登場など、 会社、業界、私自身にも目まぐるしい変化がありました。 それらの変化を超えてきたからこそ、 普遍的に重要だったと思える設計判断がいくつかあります。 ぼくの最高を構築してから3年
4. 今日話すこと 私自身の3年間のデータ基盤運用経験と、 SnowVillageで共有された『あるある』から見えてきた、 初期から考慮すべき設計の勘所についてです。 これから基盤を作る皆さんのヒントになれば幸いです。 また、既に構築済みの方にとっては、 いまの辛さの原因を知る手がかりになるかもしれません。
5. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
6. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
7. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) VP of Data @ CARTA ZERO / CARTA HOLDINGS 2024, 2025 Snowflake Data Superheroes
8. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
9. アカウントはどう分けるべきか？ アカウントの粒度は、早い段階で決める必要があります。 そして後から変更が困難なため、重要な判断です。 結論から言うと、「分けることで何が得られるのか？」に 明確に答えられないなら、分割は避けるべきです。
10. 分かれすぎたアカウントの苦労話 ありがちなのが、プロダクトごとにアカウントを分けるパターンです。 立ち上げ期はうまく回りますが、活用が進むと課題が出てきます。 例えば、複数プロダクトのデータを組み合わせて新しい インサイトを得たいケース。アカウントが分かれていると、 まずシェアリングの設定から始めなければならず、 ちょっとした調査でも一苦労です。かといって後から統合しようにも、 別々に育ったものを1つにまとめるのは容易ではありません。
11. アカウントを分ける観点 では、アカウントを分けるべきケースは？ 判断の軸は以下の3点です。 • 機密レベル • データレジデンシー • エディション
12. 機密レベル 同じアカウント内で、機密性が違うデータが共存する場合、 ロールの権限設定ミスが事故に直結する構造になります。 一方、機密性の高いデータを別アカウントに分離すれば、 「誰がアクセスできるか」という判断そのものが単純になります。 ただし、アカウント管理の手間は増えるため、 漏洩リスクと管理コストを天秤にかけて判断しましょう。
13. データレジデンシー データの保存場所に関する法的・契約的な要件です。 仮に特定の地域にデータを置く必要がある場合、 Snowflakeは、リージョンやクラウドプロバイダーごとに アカウントを作成する仕組み上、分割が事実上必須となります。
14. エディション Snowflakeのエディションによって機能と価格が異なるため、 用途に応じて使い分けることがあります。 例えば、データ変換を行うアカウントはStandardで、 機密データを扱うアカウントはBusiness Criticalといった具合。 ですが、分けることによる管理コストもあるので、 そこも考慮しつつ、どこまで分けるか考えましょう。
15. 基本、理由がないなら、 アカウントは、１つで良い！
16. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
17. どのツールを選ぶか？ Snowflakeを効果的に活用するには、 Snowflake単体で完結しない領域が必ず出てきます。 初期段階から「どのツールを採用するか」という判断が 求められますし、運用が進む中でも選定の局面は繰り返し訪れます。 ただし、ツールは導入より撤退の方がはるかに難しい。 これを念頭に置いておく必要があります。
18. 導入したツールが全く使われなければ、消すだけで済みます。 厄介なのは、中途半端に業務へ浸透してしまったケースです。 特にオーナー不在の状態になると、年単位で放置されることも 珍しくありません。誰かが決断するまで、残り続けます。 だからこそ、「このツールがないと本当に問題は解決しないのか？」 見極めるコストは、導入前に必ず払うべきです。 ツールの撤退は大変
19. 無闇にツールを増やさない。 導入するなら、ちゃんとやり切る。
20. https://speakerdeck.com/pei0804/selecting-the-right-data-technology
21. https://findy-tools.io/companies/cartazero/145/36
22. 多くのユーザーが抱える課題を、 Snowflakeがネイティブ機能で解決するケースは 珍しくありません。 今すぐ解決すべき課題でなければ、 待つことも有効な選択肢の一つです。 待てば、Snowflakeが 解決してくれることもある 参考：https://www.snowflake.com/en/blog/snowflake-acquire-select-star/
23. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
24. ロール設計の全体像 • Access Role ◦ データベース、オブジェクトへのアクセス権限を定義する。 ◦ このロールで直接操作はしない。 • Functional Role ◦ 人間のユーザーが使う。 ◦ Access Roleを組み合わせて構成。 • Service Role ◦ ツール、アプリケーションが使う。 ◦ Access Roleを組み合わせて構成。
25. ロール設計の全体像 https://select.dev/posts/snowflake-rbac-best-practices
26. Functional Roleをどう設計するか？ Access Roleは対象と操作の組み合わせで機械的に決められます。 Service Roleは多くの場合、最小権限の原則に従えば問題ありません。 一方、Functional Roleは誰にどの権限を与えるかの判断が伴います。 この判断は組織構造やビジネス要件に依存するため、 普遍的に使える設計パターンがありません。 • 部署で分ける？ • 職種で分ける？ • 兼務者はどうする？
27. Functional Roleの設計方針 Who（誰であるか）ではなく、What（何をするか）で設計する。 組織構造は変わりやすい。 データへのアクセスパターンは変わりにくい。 変わりにくいものに依存した設計の方が安定します。
28. Who設計の落とし穴 ENGINEERやANALYSTのように役割ごとにロールを分けがちですが、 クロスファンクショナルな協業が始まると破綻します。 例えば、ANALYSTがENGINEERのダッシュボードを見たい時。 回避策は、ANALYSTにENGINEERロールも付与することになります。 しかし、当然逆のケースも出てきて、 最終的には全員が両方のロールを持ち、分けた意味がなくなっていく。
29. Whatで設計するとは Whatで設計するとは、「データを見る」のような行為で ロールを分けることです。 ENGINEERやANALYSTのような役割ではなく、 何をするかを軸にロールを設計します。 では、実際どのくらいの粒度で作ると良いのか？
30. 「データを見る」ロールの設計例 「データを見る」ためのロールは1つだけ作る。 このロールは基本的にすべてのデータを閲覧でき、 NotebookやStreamlitも作成できます。 機微データへのアクセス制御が必要な場合にのみ、別途ロールを追加する。 狙いもなしに「このデータを見る」のように対象で分けると、 データのサイロをデータ基盤上に再現することになります。 見せてはいけないデータがないなら、 全員が同じデータを見れる状態の方が管理も活用もスムーズです。
31. TIPS: READONLYという名前は実態に合わない 「データを見る」ロールにREADONLYと名付けると、 実態に合わないケースがよくあります。 例えば、StreamlitやNotebookでデータを見る場合、 オブジェクトを「作る」行為が伴います。 READONLYなのに書き込み権限が必要になるのです。 私は「データを見る」ロールにDATA_EXPLORERと名付けました。 「データを探索する」という行為を表現した名前です。
32. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
33. データベースをどの粒度で切るか データパイプライン（dbtなど）が扱うデータベースは、 初期段階では3つあれば十分です。よく見かけるのは以下の構成です。 • RAW / PREP / PROD（当スライドはこれを前提に話します） • RAW / STAGING / MART • Bronze / Silver / Gold
34. 各層の役割例 • RAW ◦ 全てのデータが最初に到着する場所。加工は行わない。 • PREP ◦ データの変換と品質担保を行う場所。分析可能な状態に整える。 • PROD ◦ エンドユーザーに提供するデータを置く場所。 BIツールやアプリケーションはここを参照する。
35. https://speakerdeck.com/pei0804/churadata-event-dbt-2022
36. RAWデータベースを分けるパターン • RAW_{NAMESPACE}_{LOADER} ◦ RAW_NETSUITE_LOADMAN, RAW_NETSUITE_FIVETRAN ローダー名を含めるのは、一見アンチパターンに見えますが、 実運用上のメリットがあります。 ローダー専用のデータベースであれば、 他ツールとの設定競合を気にせずデフォルト設定で運用できます。 また、不具合時の影響範囲を限定でき、 ローダー切り替え時の移行も容易です。
37. PRODデータベースを分けるパターン • PROD_{NAMESPACE} ◦ PROD_PARTNER_A, PROD_PRODUCT_B PROD層を分けるのは、主にデータの公開範囲を制御したい場合です。 データを外部に提供する。機密レベルで分離したいケースで有効です。 スキーマレベルで細かく権限管理するより、運用が簡単です。
38. 専用データベース AlertやStreamlitなどのオブジェクトは、必ずどこかのスキーマに属します ただし、先程の3層のデータベースとは独立して管理したいことがあります。 そのような場合に、用途に特化したデータベースを作ります。 私はこれを「専用データベース」と呼んでいます。 命名ルールは特にありませんが、 オーナーチーム名と、本番か実験用かを区別する命名が多いです。
39. アジェンダ • 自己紹介 • アカウントはどう分けるべきか？ • どのツールを選ぶか？ • Functional Roleをどう設計するか？ • データベースをどう分けるか • おまけ：細かいけど重要
40. Terraformで全てのリソースを管理しない Terraformは変更頻度が低く、再利用したい土台の管理に集中させます。 全てを管理することは本質ではなく、仮に大量のオブジェクトを管理すると Planに1時間かかる状態に陥ります。 具体的には、アカウントオブジェクト（Warehouse、Database、Role、User）、アク セス制御（GRANT）、 インテグレーション（Snowpipe、External Table）などは Terraformで管理するのがおすすめです。
41. PoCという名前でリソースを作らない PoCと名付けたリソースは一時的なものとして作られますが、 実際には削除されずに一生残り続けます。 特に「これ便利じゃん」って使われ始めると消せなくなります。 最初から本番運用を想定した命名規則で作成するか、 削除期限を明確にして問答無用で削除しましょう。
42. Access Roleに `_` Prefixつける _READ_RAW_DATABASEのように先頭にアンダースコアをつけることで、 Functional Roleと視覚的に区別できます。 機能的な違いはありませんが、ロール一覧画面ではAccess Roleと Functional Roleを見分ける手段が提供されていないため、 命名規則による区別が効果的です。 また、アルファベット順でソートされた際に Access Roleがまとまって表示されるため、一覧性も向上します。
43. ロールの階層は深くしすぎない ロール階層はUser → Functional Role → Access Roleというシンプルな 一方向の流れに留めます。逆にAccess Role同士やFunctional Role同士 で階層化すると、権限のデバッグが困難になるためです。 例えば、Functional Roleをネストさせた場合、 「このユーザーはなぜこのテーブルにアクセスできるのか」を 特定するために複数のロールを順に辿る必要が生じ、 トラブルシューティングの時間が大幅に増加します。
44. PREPはUTCのTIMESTAMP_TZに統一する RAWレイヤーではソースシステムの形式をそのまま保持しますが、 PREPは全てUTCのTIMESTAMP_TZ型に統一します。 データを見るたびに「これはどのタイムゾーンか」を確認する手間が 発生するため、統一することが重要です。 TIMESTAMP_NTZでUTCを保存することも可能ですが、 TIMESTAMP_TZはタイムゾーンオフセットが明示されるため、 データの可読性が向上します。オフセット情報による追加のストレージ コストは、一般的なデータ量であれば無視できる範囲です。
45. STATEMENT_TIMEOUT_IN_SECONDSを設定 クエリの最大実行時間 デフォルトは2日間ですが、実運用では長すぎることがほとんどです。 終わらないクエリが何時間も動き続け、 想定外のコストが発生するリスクがあります。 例えば、アカウントレベルで3600秒（1時間）程度に設定しておけば、 問題のあるクエリを自動的に停止できます。 適切な値は用途によって異なりますが、 デフォルトのまま運用することはおすすめしません。
46. DATA_RETENTION_TIME_IN_DAYSは7日 Time Travel（履歴データ保持）の日数 デフォルトは1日ですが、誤削除やバグによるデータ破壊に気づくまでには数日 かかることがあります。特に週末を挟んだ場合、 1日の保持期間では復旧が間に合いません。 初期段階で7日程度に設定しておくことを推奨します。 期間は後から延ばすことができますが、過去に遡って適用することは できません。ストレージコストは増加しますが、 重要なデータを失うリスクと比較すれば許容できる範囲です。
47. ウェアハウスのAUTO_SUSPENDは60秒 非アクティブ時の自動停止までの待機時間 初期値は10分（600秒）ですが、この設定は多くの場合、長すぎます。 基本的には60秒でサスペンドするように設定しておきましょう。 ただし、ワークロードによっては頻繁な停止と起動が 最小課金時間60秒と相性が悪く、 かえってコストが増えるケースもあります。
48. まとめ
49. 本当に必要か？を足す前に考えよう。 消す方が大変。
50. どれだけ考えても、間違える時はある。 けど、続けてさえいれば、やり直せる。
51. © 2025 Snowflake Inc. All Rights Reserved THANK YOU