$30 off During Our Annual Pro Sale. View Details »

クリエイターツール「QUANT」の開発の話 & クライアントに寄り添ったデータ分析基盤の構築

クリエイターツール「QUANT」の開発の話 & クライアントに寄り添ったデータ分析基盤の構築

GREE Tech Conference 2022で発表された資料です。
https://techcon.gree.jp/2022/session/TrackA-1

gree_tech
PRO

October 25, 2022
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. Glossom株式会社 エンジニアマネージャー 菊井 昭夫
    クリエイターツール「QUANT」の開発の話 &
    クライアントに寄り添ったデータ分析基盤の構築
    Glossom株式会社 データエンジニア 飯山 誠也

    View Slide

  2. 自己紹介
    2

    名前:菊井 昭夫
    所属:
    Glossom株式会社
    プロダクト事業本部
    開発
    経歴:
    2011年 グリー株式会社へ中途入社
    2013年 Glossom株式会社へ転籍

    View Slide

  3. Glossom株式会社の紹介
    3

    Glossom株式会社は、
    グリーグループで広告・マーケティング領域を担う
    グリー株式会社の100%子会社です。
    今回は
    Glossomの持つプロダクトの一つである
    クリエイターツール「QUANT」の開発の話をさせていただきます。

    View Slide

  4. QUANT(クアント)とは
    インフルエンサーを中心としたソーシャルコマース
    支援サービス
    クリエイターツール「QUANT」の紹介
    4


    View Slide

  5. クリエイターツール「QUANT」の紹介
    5


    View Slide

  6. クリエイターツール「QUANT」の紹介
    6


    View Slide

  7. 機能項目
    - インフルエンサー向け画面
    - マイページ
    - 案件管理
    - 収益管理
    - ショップ管理
    - 社内管理向け画面
    - キャンペーン管理
    - ユーザー管理
    - クリエイティブ審査
    - インフルエンサーデータ計測機能
    - 発信したコンテンツのクリック計測機能
    - 商品購入などの成果計測機能
    クリエイターツール「QUANT」の紹介
    7


    View Slide

  8. 「QUANT」の技術スタック
    8

    言語(フロント) Ruby(Ruby on Rails)
    インフラ GCP
    データ Mysql,Redis,BigTable
    インフラ構成管理 Terraform

    View Slide

  9. リダイレクタ
    成果計測
    集計
    レポート
    クリック 成果地点
    URL発行
    インフルエンサー発信
    Cloud
    Run
    ログ収集/蓄積
    BigQuery
    BigTable
    Data
    Studio
    「QUANT」のコンポーネント構成
    設定
    分析
    Mysql

    View Slide

  10. 「QUANT」のサーバー構成
    10


    View Slide

  11. 特色のある実装部分をご紹介させていただきます。
    「QUANT」の実装について
    11


    View Slide

  12. https://cloud.google.com/bigtable?hl=ja より
    Cloud Bigtable
    最大 99.999% の可用性で大規模な分析ワークロードにも運用ワークロードにも対応で
    きる、フルマネージドでスケーラブルな NoSQL データベース サービス。
    「QUANT」のCloud Bigtable採用について
    12


    View Slide

  13. 用途
    ● 案件情報の保持
    Click時に案件の有効判定、リダイレクト先URLの取得
    ● Clickログ情報の保持
    成果計測時に成果判定としてClick情報との突き合わせ
    サービス運用でのURL拡散による
    Click時のアクセス負荷対策として
    ボトルネックになりがちなMysqlでななくBigTableを保存先に採用しました
    「QUANT」のCloud Bigtable採用について
    13


    View Slide

  14. 実装紹介
    ● データの書き込み
    expireを適切に設定し削除を考慮せずに追記更新を常に続けております。
    ● データの読み込み
    読み込み時にフィルタを利用することで
    追記更新した値の最新バージョンのみを返すように指示をしております。
    上記により
    アプリケーションレイヤーでのデータ削除や
    追記更新時や読み込み時に既存のキーのデータ重複を考慮せずに実装できるので
    KVSとして使いやすく、性能に現在も満足して利用しております。
    「QUANT」のBigTable採用について
    14


    View Slide

  15. view_component採用理由
    より良いサービスにするため日々機能を追加していった結果
    業務ロジックが複雑化し、Viewが肥大化しました
    テストコストや、ロジックの可読性が落ちたので
    view_componentを採用することで
    コンポーネント化でロジックを分割することで
    コンポーネント単位のテストが可能になりました。
    「QUANT」のRails 採用したGemを紹介
    15


    View Slide

  16. view_component実装例の紹介
    「QUANT」のRails 採用したGemを紹介
    16

    index.html.haml
    # before
    = render 'search'
    index.html.haml
    # after
    = render Campaigns::SearchComponent.new(form: form)

    View Slide

  17. view_component実装例の紹介
    「QUANT」のRails 採用したGemを紹介
    17

    # search_component.rb
    class Campaigns::SearchComponent < ApplicationComponent
    attribute :form
    end
    # search_component.html.haml
    = simple_form_for form, url: campaigns_path do |f|
    = f.input :hogehoge
    # search_component_spec.rb
    # RSpec.configure で type: :componentを追加する必要があります
    RSpec.describe Campaigns::SearchComponent, type: :component do
    describe ……
    end

    View Slide

  18. view_componentを採用して良かったこと
    巨大なView表示するための、大量のテストデータの用意や
    分割することでSpecが書きやすくなりました。
    リリース当初は採用していませんでしたが、
    こちらを採用しコンポーネント化することにより
    ロジックの整理やテスト品質を保つことが出来ておりました。
    Viewが肥大化した際には、こちらのGemをおすすめさせていただきます。
    「QUANT」のRails 採用したGemを紹介
    18


    View Slide

  19. subdomain実装について
    「QUANT」のサービスは複数のドメインで構成されてます。
    プロフィール管理画面(pf.quant.jp)
    マイページ画面(quant.page)
    ショップ画面(shop.quant.page)
    楽に開発管理や、実装共有をしたかったので
    Rails Projectを分けずにsubdomain実装により実現してます。
    「QUANT」のRails実装例について紹介
    19


    View Slide

  20. subdomain実装例
    「QUANT」のRails実装例について紹介
    20

    routes.rb
    constraints subdomain: ENV.fetch('SUBDOMAIN',
    'subdomain').to_s do
    scope module: :'subdomain' do
    resources :tops, only: [:index]
    end
    end

    View Slide

  21. 「QUANT」のサービスの今後
    今後の展望
    21

    インフルエンサーマーケティングの市場は
    今後も発展していくと思っております。
    クリエイターツール「QUANT」は
    計測したデータをより活用することや
    インフルエンサーを支援する機能を追加することを予定しており
    今後もより良いサービスを目指していきます。
    ご清聴ありがとうございました。

    View Slide

  22. クライアントに寄り添ったデータ分析基盤の構築
    Glossom株式会社 データエンジニア 飯山 誠也

    View Slide

  23. 名前:飯山 誠也
    所属:
    Glossom株式会社
    DXC事業本部
    アカウントエグゼクティブ3部
    データ・エンジニアリングチーム
    経歴:
    2018年 Glossom株式会社へ入社
    2019年よりデータ分析基盤の構築運用業務を担当
    自己紹介
    23


    View Slide

  24. Glossomが展開するデジタル化推進支援の流れ
    24

    コンテンツに接触したユーザ
    ページを閲覧したユーザ
    申込ユーザ
    利用ユーザ
    分析DB
    認知・興味 申込転換 アクティブ化 ロイヤル化
    BIの構築
    分析による施策仮説の立案、施策の展開、施策の効果検証
    購買データ
    顧客データ
    トラッキングデータ
    分析DBへデータの取り込み、データ更新

    View Slide

  25. データ分析基盤の構成
    25

    Big Query
    データ分析基盤はGCP環境を使用
    Cloud Composerを活用することで、分析DBを構築
    各種データ
    各種データ
    各種データ
    クエリ実行
    データ取り込み実行
    データ書き出し
    データ書き出し
    データ書き出し
    Kubernetes
    Engine
    Cloud
    Composer
    (Airflow)
    Dataflow
    Looker
    Studio

    View Slide

  26. DAG:
    有向非巡回グラフ
    単一のDAG内に依存関係のある複数のタスクを内包
    する
    Task:
    データを取り込んだり、他のシステムを呼び出したり
    といった処理を実行する
    Airflowには様々な処理を行う機能(Operator)が
    標準で設けられている
    データ分析基盤の主要ツール -Cloud Composer-
    26

    Airflowをベースとしたワークフロー管理ツール
    TaskA
    TaskB
    TaskC
    TaskD
    TaskE
    TaskF
    DAG
    標準Operatorが活用できると、より手軽にデータ取
    り込みが実現できる

    View Slide

  27. クライアントによって異なるIT活用状況
    27

    クライアントごとに異なる状況に寄り添ったデータ取り込みが必要
    データ管理の体制が整っておらず、データの保管先が点在している
    連携するファイル数も把握できていない
    データを所定の保管先に連携できる担当者やエンジニアがいない
    データの保管先は社内政治的に既に決まってしまっている

    View Slide

  28. クライアントに寄り添ったデータ取り込みの実現
    28

    データ保管先:kintone
    ファイル文字コード:UTF-8
    1ファイルの最大容量:50MB
    1回の連携ファイル数:3
    クライアントA
    データ保管先:S3
    ファイル文字コード:Shift-JIS
    1ファイルの最大容量:200MB
    1回の連携ファイル数:10
    クライアントB
    データ保管先:GCS
    ファイル文字コード:UTF-8
    1ファイルの最大容量:1GB
    1回の連携ファイル数:20
    クライアントC
    データの取り込み方法はクライアントのIT活用状況によって左右される
    Airflow
    Custom Operator
    Google Kubernetes
    Engine Pod
    (GKE Pod)
    Dataflow

    View Slide

  29. データ取り込み-Airflow Custom Operator-
    29

    Airflowの標準Operatorでは対応できないクラウドツールからのデータ取り込みが可能
    クライアントA
    - メリット
    - 開発が比較的容易に行える
    - Airflowのライブラリを利用できる
    - apiなどの認証情報を統合できる
    - デメリット
    - 環境構築が難しい場合がある
    - Airflowのライブラリが競合する可能性がある
    - 他のタスクの実行に影響を与える可能性がある
    データ保管先:kintone
    ファイル文字コード:UTF-8
    1ファイルの最大容量:50MB
    1回の連携ファイル数:3

    View Slide

  30. GKE Podを使うことでAirflowのワーカーリソースを考慮せずに処理を実行できる
    データ取り込み-GKE Pod-
    30

    データ保管先:S3
    ファイル文字コード:Shift-JIS
    1ファイルの最大容量:200MB
    1回の連携ファイル数:10
    クライアントB
    - メリット
    - リソースを切り離せる
    - 文字コードの変換に対応できる
    - デメリット
    - Airflowのライブラリは利用できない

    View Slide

  31. データ取り込み-Dataflow-
    31

    Google CloudのETLサービスであり、大規模データのバッチ処理とストリーミング処理を行うこと
    が可能
    データ保管先:GCS
    ファイル文字コード:UTF-8
    1ファイルの最大容量:1GB
    1回の連携ファイル数:20
    クライアントC
    - メリット
    - リソースを切り離せる
    - オートスケール機能があり、大規模データの取り
    込みに対応できる
    - デメリット
    - 自由度が低い

    View Slide

  32. メリット デメリット 使い分け
    Airflow
    Custom Operator
    - 開発が比較的容易に
    行える
    - 環境構築が難しい
    場合がある
    - 他タスク実行に影響
    を与える
    - Airflowのライブラリも活
    用して取り込みをしたい
    GKE Pod
    - リソースを切り離せる
    - 文字コードの変換に対
    応できる
    - Airflowのライブラリ
    は利用できない
    - リソースを分けたい
    - 文字コードを変換したい
    Dataflow
    - リソースを切り離せる
    - 大規模データの取り込
    みに対応
    - Airflowのライブラリ
    は利用できない
    - 自由度が低い
    - リソースを分けたい
    - UTF-8で連携
    - GCSに存在している
    データ取り込み手法の使い分けまとめ
    32


    View Slide

  33. - メリット
    - Airflowを操作する必要がないため、基盤担当者
    以外でも活用できる
    - クライアントから連携されてきたデータにアジャスト
    した取り込みが可能
    - 細かな仕様の変化にも柔軟に対応できる
    - デメリット
    - 都度ファイル形式が変わる場合、自動化されてい
    ないコード修正作業が増えるため、データ欠損な
    どのインシデントの危険性が高まる
    データ取り込み-おまけ-
    33

    より柔軟な対応が求められる場合にGoogle Colaboratoryでスポット取り込みを行う
    クライアントD
    エクセルでのデータ連携
    連携頻度は不定期
    カラム数やカラム名はその都度変
    わる

    View Slide

  34. • データ分析基盤の機能面の充実化
    • Dataflow Primeの導入検討
    • 環境構築後のワーカーCPUとメモリのオートスケーリングが可能
    • データリネージツールの導入検討
    • Dataform
    • dbt etc..
    今後の展望
    34


    View Slide

  35. 35


    View Slide