SnowflakeのRBACを用いて 安全なデータ活用を促進する

2022.10.21『KGDC Tech Conference #3 KDDIグループの「ごったに！」会』にて、Supership プロダクト開発本部 アドテクノロジーセンター 今村 豊 が登壇の際に投影した資料です。
イベント詳細はこちら：https://kgdc.connpass.com/event/261136/

広告配信データの活用を目的としたDWHをHadoopベースのオンプレ基盤からSnowflakeに移行しました。この移行に伴い実装した、よりデータを安全に活用できるようにするためのアクセス制御の事例をご紹介しました。

今回紹介したような大量データ(1PB)を取り巻く基盤に関わる業務に興味がある方向けのポジションの募集もありますので、気になる方は以下のエンジニア職種の募集要項をご確認ください。
https://supership.jp/recruit/

Transcript

1. SnowflakeのRBACを用いて 安全なデータ活用を促進する 2022.10.21 KGDC Tech Conference #3 KDDIグループの「ごったに！」会 Supership 今村 豊
2. 自己紹介 今村 豊 (いまむら ゆたか) Supership プロダクト開発本部 アドテクノロジーセンター ScaleOut DSPのデータ基盤や広告配信基盤のSRE業務など浅く広く担当しています。 2
3. アウトライン • はじめに • 背景と課題 • 解決 • 次の課題 • おわりに 3
4. はじめに 4
5. はじめに ScaleOut DSPのデータ活用基盤をオンプレのHadoop基盤からSnowflakeへと移行しました。 5 本スライドではSnowflakeへの移行によって手に入れたデータアクセス制御の設計について事例紹介しま す。
6. 広告配信ログのライフサイクル: いままで 6 オンプレミスデータセンター 広告配信 広告データ集約 データ活用・分析 開発者 データアナリスト ScaleOut DSPの広告配信ログはオンプレ→クラウドを経由しつつ集約・加工の上で活用される。 プロダクト企画 セールス ここを移行しました
7. 広告配信ログのライフサイクル: 現在 7 オンプレミスデータセンター 広告配信 広告データ集約 データ活用・分析 開発者 データアナリスト 基本的にアドホック分析系ユースをSnowflakeに集約。 プロダクト企画 セールス ここを移行しました
8. 背景と課題 8
9. ScaleOut DSPの配信ログデータ管理の難しい点 事業者とのデータ利用契約と用途の組み合 わせに応じた細かなデータアクセス 広告配信プラットフォーム ScaleOut はDSP機能をOEM販売しており、OEM契約先の事業者のブランドで ScaleOutのソリューションを提供できる。 こうした契約形態があるため、配信データ（広告配信の実績を示すログなど）について、一部OEM提供先 の契約に従い個社別の扱いが必要。 → 個社別の事情をデータアクセス制御に反映させる必要がある。 9
10. ScaleOut DSPの配信ログデータ管理の難しい点: 例 OEM提供先事業者Xの配信ログは統計化したとしても他社の広告配 信・分析にデータ利用不可。 (要は事業者Xのためにのみデータを利用可能) 10 事業者X 事業者Y 入稿 事業者X 配信ログ 抽出・分析 分析結果提供 配信サーバ システム的にここはブロックしたい
11. 課題のポイント OEM契約先のデータ利用に対する制約 と データを活用したい利用者の用途 が 適切に関連づいた状態 を実現するのがアクセス制御。 11
12. 解決 12
13. スキーマオブジェクトとRBACを駆使して課題を解く 13 制約 Snowflakeの (Secure) Viewを利用する。 用途 「プロジェクト」という概念を表現したDatabaseを利用する。 関連付け Snowflakeのロールベースのアクセス制御(RBAC)を利用する。
14. 制約: Snowflakeの (Secure) Viewを利用する。 14 Main データベース フィルタなし生データ Y社向け分析プロジェクト用データベース CREATE VIEW YYY AS SELECT .. FROM .. WHERE 事業者コード = Y社 CREATE VIEW ZZZ AS SELECT .. FROM .. WHERE 事業者コード = Z社 Z社向け分析プロジェクト用データベース フィルタのかかっていないデータに対して抽出条件の制約をかけたViewを定義する。 事業者ごとに参照が許可されたデー タだけを抽出する。
15. 用途: 「プロジェクト」という概念を表現したDatabaseを利用する。 特定の目的を達成するための社内ユーザの活動の集合を「プロジェクト」という用語を導入。 (Snowflakeのオブジェクトとしてはもちろん存在しない。この設計独自の用語) プロジェクトはその目的に従った「用途」を表すものとして設計した。 「プロジェクト」ごとのサンドボックス環境をSnowflakeのDatabaseとして定義することで、「用途」を Snowflakeのスキーマオブジェクトとして扱えるようになった。 15 広告配信枠の在庫を調査し 提案に役立てたい。 Z社との連携の取り組みで データをエクスポートしたい。 PJ_STOCK_RESEARCH PJ_Z_INTEGRATION 「用途」ごとの空間を作る。
16. ユーザ 職能ロール アクセス制御 ロール 関連付け: Snowflakeのロールベースのアクセス制御(RBAC)を利用する。 16 Y社向け分析プロジェクト用 データベース Y社プロジェクト 実績レポートロール Y社配信実績SELECT可 Y社配信実績 Y社配信ユーザ Y社プロジェクト セグメント分析ロール Y社配信ユーザSELECT可 セールス アナリスト 用途×制約×ユーザの対応をロール として割り当てる。
17. このアプローチのPros/Cons Pros • 管理対象オブジェクトはDatabase, View, Roleだけでありシンプル • データのコピーを作らずにビューで処理しているので、制約条件が変わっても過去データのバック フィル不要 Cons • 同じ制約条件のついたデータアクセス(= 同じ定義のビュー)であってもプロジェクトごとに定義する ので重複は多い ◦ 構成はTerraformでやっているので繰り返しについてはあまりつらみがない ▪ terraform planが長い、などはあるが。。。 17
18. 次なる課題 18
19. 次なる課題 制約と用途を組み合わせる基盤はできた。 しかし組み合わせが正しいと判断するのは非常に難しい。 なぜなら以下の3つの要素を集めて判断する必要があるから。 1. どんなデータであるか → データを作るプロダクト管理者のノウハウ 2. どんなデータ利用契約か → 法務担当のノウハウ 3. どんな用途で誰を利するプロジェクトか → セールス担当のノウハウ 円滑に判断し実装するためのワークフローを検討・構築中。。。 19
20. おわりに 20
21. おわりに 今回紹介したデザインはSupership独力ではなく、グループ会社である • ちゅらデータ 菱沼さん • DATUM STUDIO 城内さん に多大なご支援を頂きながらなんとか完成に漕ぎ着けました 本当に助かりました。ありがとうございます！ 他にもコスト最適化などまだ課題山盛りですが頑張ります。 今回紹介したような大量データ(1PB)を取り巻く基盤に関わる業務に興味がある方向けのポジションの募 集もありますので、気になる方は以下のエンジニア職種の募集要項をご確認ください。 https://supership.jp/recruit/ ご清聴頂きありがとうございました。 21
22. Appendix: 全体の構成 22 オンプレ AWS データバッファ Snowflake環境 Snowflake Managed Account HDFS S3 bucket Database for cleansed data Database project X external table A’ native table A Database for curated data native table B secure view A secure view B share for customer データ共有先企業 secure view B AWS for processing MWAA distcp storage integration referenced by view referenced by view referenced by share 1) insert/copy 2) insert executed by DAG Databricks Databrick cluster w/ spark connector
23. Appendix: 移行規模感 移行前Hadoopクラスタサイズ • 133台 • トータルvcore 4032 • トータルRAM 42TB Snowflake保存中のデータ→ 1,002.5 TB 23