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

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

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

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


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


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


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


「QUANT」の技術スタック 8
 言語(フロント) Ruby(Ruby on Rails) インフラ GCP データ Mysql,Redis,BigTable インフラ構成管理 Terraform

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

「QUANT」のサーバー構成 10


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


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


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


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


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


view_component実装例の紹介 「QUANT」のRails 採用したGemを紹介 16
 index.html.haml # before = render 'search' index.html.haml # after = render Campaigns::SearchComponent.new(form: form)

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


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


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

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

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

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


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

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

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

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

クライアントに寄り添ったデータ取り込みの実現 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

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

GKE Podを使うことでAirflowのワーカーリソースを考慮せずに処理を実行できる データ取り込み-GKE Pod- 30
 データ保管先：S3 ファイル文字コード：Shift-JIS 1ファイルの最大容量：200MB 1回の連携ファイル数：10 クライアントB - メリット - リソースを切り離せる - 文字コードの変換に対応できる - デメリット - Airflowのライブラリは利用できない

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

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


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

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


35