Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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/

Supership株式会社

October 21, 2022
Tweet

More Decks by Supership株式会社

Other Decks in Programming

Transcript

  1. SnowflakeのRBACを用いて
    安全なデータ活用を促進する
    2022.10.21
    KGDC Tech Conference #3 KDDIグループの「ごったに!」会
    Supership 今村 豊

    View full-size slide

  2. 自己紹介
    今村 豊 (いまむら ゆたか)
    Supership プロダクト開発本部 アドテクノロジーセンター
    ScaleOut DSPのデータ基盤や広告配信基盤のSRE業務など浅く広く担当しています。
    2

    View full-size slide

  3. アウトライン
    ● はじめに
    ● 背景と課題
    ● 解決
    ● 次の課題
    ● おわりに
    3

    View full-size slide

  4. はじめに
    4

    View full-size slide

  5. はじめに
    ScaleOut DSPのデータ活用基盤をオンプレのHadoop基盤からSnowflakeへと移行しました。
    5
    本スライドではSnowflakeへの移行によって手に入れたデータアクセス制御の設計について事例紹介しま
    す。

    View full-size slide

  6. 広告配信ログのライフサイクル: いままで
    6
    オンプレミスデータセンター
    広告配信 広告データ集約 データ活用・分析
    開発者 データアナリスト
    ScaleOut DSPの広告配信ログはオンプレ→クラウドを経由しつつ集約・加工の上で活用される。
    プロダクト企画
    セールス
    ここを移行しました

    View full-size slide

  7. 広告配信ログのライフサイクル: 現在
    7
    オンプレミスデータセンター
    広告配信 広告データ集約 データ活用・分析
    開発者 データアナリスト
    基本的にアドホック分析系ユースをSnowflakeに集約。
    プロダクト企画
    セールス
    ここを移行しました

    View full-size slide

  8. 背景と課題
    8

    View full-size slide

  9. ScaleOut DSPの配信ログデータ管理の難しい点
    事業者とのデータ利用契約と用途の組み合
    わせに応じた細かなデータアクセス
    広告配信プラットフォーム ScaleOut はDSP機能をOEM販売しており、OEM契約先の事業者のブランドで
    ScaleOutのソリューションを提供できる。
    こうした契約形態があるため、配信データ(広告配信の実績を示すログなど)について、一部OEM提供先
    の契約に従い個社別の扱いが必要。
    → 個社別の事情をデータアクセス制御に反映させる必要がある。
    9

    View full-size slide

  10. ScaleOut DSPの配信ログデータ管理の難しい点: 例
    OEM提供先事業者Xの配信ログは統計化したとしても他社の広告配
    信・分析にデータ利用不可。
    (要は事業者Xのためにのみデータを利用可能)
    10
    事業者X
    事業者Y
    入稿
    事業者X
    配信ログ
    抽出・分析 分析結果提供
    配信サーバ
    システム的にここはブロックしたい

    View full-size slide

  11. 課題のポイント
    OEM契約先のデータ利用に対する制約

    データを活用したい利用者の用途

    適切に関連づいた状態
    を実現するのがアクセス制御。
    11

    View full-size slide

  12. スキーマオブジェクトとRBACを駆使して課題を解く
    13
    制約
    Snowflakeの (Secure) Viewを利用する。
    用途
    「プロジェクト」という概念を表現したDatabaseを利用する。
    関連付け
    Snowflakeのロールベースのアクセス制御(RBAC)を利用する。

    View full-size slide

  13. 制約: Snowflakeの (Secure) Viewを利用する。
    14
    Main データベース
    フィルタなし生データ
    Y社向け分析プロジェクト用データベース
    CREATE VIEW YYY AS
    SELECT
    ..
    FROM
    ..
    WHERE
    事業者コード = Y社
    CREATE VIEW ZZZ AS
    SELECT
    ..
    FROM
    ..
    WHERE
    事業者コード = Z社
    Z社向け分析プロジェクト用データベース
    フィルタのかかっていないデータに対して抽出条件の制約をかけたViewを定義する。
    事業者ごとに参照が許可されたデー
    タだけを抽出する。

    View full-size slide

  14. 用途: 「プロジェクト」という概念を表現したDatabaseを利用する。
    特定の目的を達成するための社内ユーザの活動の集合を「プロジェクト」という用語を導入。
    (Snowflakeのオブジェクトとしてはもちろん存在しない。この設計独自の用語)
    プロジェクトはその目的に従った「用途」を表すものとして設計した。
    「プロジェクト」ごとのサンドボックス環境をSnowflakeのDatabaseとして定義することで、「用途」を
    Snowflakeのスキーマオブジェクトとして扱えるようになった。
    15
    広告配信枠の在庫を調査し
    提案に役立てたい。
    Z社との連携の取り組みで
    データをエクスポートしたい。
    PJ_STOCK_RESEARCH
    PJ_Z_INTEGRATION
    「用途」ごとの空間を作る。

    View full-size slide

  15. ユーザ
    職能ロール
    アクセス制御
    ロール
    関連付け:
    Snowflakeのロールベースのアクセス制御(RBAC)を利用する。
    16
    Y社向け分析プロジェクト用
    データベース
    Y社プロジェクト
    実績レポートロール
    Y社配信実績SELECT可
    Y社配信実績
    Y社配信ユーザ Y社プロジェクト
    セグメント分析ロール
    Y社配信ユーザSELECT可
    セールス
    アナリスト
    用途×制約×ユーザの対応をロール
    として割り当てる。

    View full-size slide

  16. このアプローチのPros/Cons
    Pros
    ● 管理対象オブジェクトはDatabase, View, Roleだけでありシンプル
    ● データのコピーを作らずにビューで処理しているので、制約条件が変わっても過去データのバック
    フィル不要
    Cons
    ● 同じ制約条件のついたデータアクセス(= 同じ定義のビュー)であってもプロジェクトごとに定義する
    ので重複は多い
    ○ 構成はTerraformでやっているので繰り返しについてはあまりつらみがない
    ■ terraform planが長い、などはあるが。。。
    17

    View full-size slide

  17. 次なる課題
    18

    View full-size slide

  18. 次なる課題
    制約と用途を組み合わせる基盤はできた。
    しかし組み合わせが正しいと判断するのは非常に難しい。
    なぜなら以下の3つの要素を集めて判断する必要があるから。
    1. どんなデータであるか → データを作るプロダクト管理者のノウハウ
    2. どんなデータ利用契約か → 法務担当のノウハウ
    3. どんな用途で誰を利するプロジェクトか → セールス担当のノウハウ
    円滑に判断し実装するためのワークフローを検討・構築中。。。
    19

    View full-size slide

  19. おわりに
    20

    View full-size slide

  20. おわりに
    今回紹介したデザインはSupership独力ではなく、グループ会社である
    ● ちゅらデータ 菱沼さん
    ● DATUM STUDIO 城内さん
    に多大なご支援を頂きながらなんとか完成に漕ぎ着けました
    本当に助かりました。ありがとうございます!
    他にもコスト最適化などまだ課題山盛りですが頑張ります。
    今回紹介したような大量データ(1PB)を取り巻く基盤に関わる業務に興味がある方向けのポジションの募
    集もありますので、気になる方は以下のエンジニア職種の募集要項をご確認ください。
    https://supership.jp/recruit/
    ご清聴頂きありがとうございました。
    21

    View full-size slide

  21. 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

    View full-size slide

  22. Appendix: 移行規模感
    移行前Hadoopクラスタサイズ
    ● 133台
    ● トータルvcore 4032
    ● トータルRAM 42TB
    Snowflake保存中のデータ→
    1,002.5 TB
    23

    View full-size slide