GREE Tech Conference 2022で発表された資料です。 https://techcon.gree.jp/2022/session/TrackA-1
Glossom株式会社 エンジニアマネージャー 菊井 昭夫クリエイターツール「QUANT」の開発の話 &クライアントに寄り添ったデータ分析基盤の構築Glossom株式会社 データエンジニア 飯山 誠也
View Slide
自己紹介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発行インフルエンサー発信CloudRunログ収集/蓄積BigQueryBigTableDataStudio「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.rbclass Campaigns::SearchComponent < ApplicationComponentattribute :formend# 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 dodescribe ……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.rbconstraints subdomain: ENV.fetch('SUBDOMAIN','subdomain').to_s doscope module: :'subdomain' doresources :tops, only: [:index]endend
「QUANT」のサービスの今後今後の展望21 インフルエンサーマーケティングの市場は今後も発展していくと思っております。クリエイターツール「QUANT」は計測したデータをより活用することやインフルエンサーを支援する機能を追加することを予定しており今後もより良いサービスを目指していきます。ご清聴ありがとうございました。
クライアントに寄り添ったデータ分析基盤の構築Glossom株式会社 データエンジニア 飯山 誠也
名前：飯山 誠也所属：Glossom株式会社DXC事業本部アカウントエグゼクティブ3部データ・エンジニアリングチーム経歴：2018年 Glossom株式会社へ入社2019年よりデータ分析基盤の構築運用業務を担当自己紹介23
Glossomが展開するデジタル化推進支援の流れ24 コンテンツに接触したユーザページを閲覧したユーザ申込ユーザ利用ユーザ分析DB認知・興味 申込転換 アクティブ化 ロイヤル化BIの構築分析による施策仮説の立案、施策の展開、施策の効果検証購買データ顧客データトラッキングデータ分析DBへデータの取り込み、データ更新
データ分析基盤の構成25 Big Queryデータ分析基盤はGCP環境を使用Cloud Composerを活用することで、分析DBを構築各種データ各種データ各種データクエリ実行データ取り込み実行データ書き出しデータ書き出しデータ書き出しKubernetesEngineCloudComposer(Airflow)DataflowLookerStudio
DAG：有向非巡回グラフ単一のDAG内に依存関係のある複数のタスクを内包するTask：データを取り込んだり、他のシステムを呼び出したりといった処理を実行するAirflowには様々な処理を行う機能(Operator)が標準で設けられているデータ分析基盤の主要ツール -Cloud Composer-26 Airflowをベースとしたワークフロー管理ツールTaskATaskBTaskCTaskDTaskETaskFDAG標準Operatorが活用できると、より手軽にデータ取り込みが実現できる
クライアントによって異なるIT活用状況27 クライアントごとに異なる状況に寄り添ったデータ取り込みが必要データ管理の体制が整っておらず、データの保管先が点在している連携するファイル数も把握できていないデータを所定の保管先に連携できる担当者やエンジニアがいないデータの保管先は社内政治的に既に決まってしまっている
クライアントに寄り添ったデータ取り込みの実現28 データ保管先：kintoneファイル文字コード：UTF-81ファイルの最大容量：50MB1回の連携ファイル数：3クライアントAデータ保管先：S3ファイル文字コード：Shift-JIS1ファイルの最大容量：200MB1回の連携ファイル数：10クライアントBデータ保管先：GCSファイル文字コード：UTF-81ファイルの最大容量：1GB1回の連携ファイル数：20クライアントCデータの取り込み方法はクライアントのIT活用状況によって左右されるAirflowCustom OperatorGoogle KubernetesEngine Pod(GKE Pod)Dataflow
データ取り込み-Airflow Custom Operator-29 Airflowの標準Operatorでは対応できないクラウドツールからのデータ取り込みが可能クライアントA- メリット- 開発が比較的容易に行える- Airflowのライブラリを利用できる- apiなどの認証情報を統合できる- デメリット- 環境構築が難しい場合がある- Airflowのライブラリが競合する可能性がある- 他のタスクの実行に影響を与える可能性があるデータ保管先：kintoneファイル文字コード：UTF-81ファイルの最大容量：50MB1回の連携ファイル数：3
GKE Podを使うことでAirflowのワーカーリソースを考慮せずに処理を実行できるデータ取り込み-GKE Pod-30 データ保管先：S3ファイル文字コード：Shift-JIS1ファイルの最大容量：200MB1回の連携ファイル数：10クライアントB- メリット- リソースを切り離せる- 文字コードの変換に対応できる- デメリット- Airflowのライブラリは利用できない
データ取り込み-Dataflow-31 Google CloudのETLサービスであり、大規模データのバッチ処理とストリーミング処理を行うことが可能データ保管先：GCSファイル文字コード：UTF-81ファイルの最大容量：1GB1回の連携ファイル数：20クライアントC- メリット- リソースを切り離せる- オートスケール機能があり、大規模データの取り込みに対応できる- デメリット- 自由度が低い
メリット デメリット 使い分けAirflowCustom Operator- 開発が比較的容易に行える- 環境構築が難しい場合がある- 他タスク実行に影響を与える- Airflowのライブラリも活用して取り込みをしたいGKE Pod- リソースを切り離せる- 文字コードの変換に対応できる- Airflowのライブラリは利用できない- リソースを分けたい- 文字コードを変換したいDataflow- リソースを切り離せる- 大規模データの取り込みに対応- Airflowのライブラリは利用できない- 自由度が低い- リソースを分けたい- UTF-8で連携- GCSに存在しているデータ取り込み手法の使い分けまとめ32
- メリット- Airflowを操作する必要がないため、基盤担当者以外でも活用できる- クライアントから連携されてきたデータにアジャストした取り込みが可能- 細かな仕様の変化にも柔軟に対応できる- デメリット- 都度ファイル形式が変わる場合、自動化されていないコード修正作業が増えるため、データ欠損などのインシデントの危険性が高まるデータ取り込み-おまけ-33 より柔軟な対応が求められる場合にGoogle Colaboratoryでスポット取り込みを行うクライアントDエクセルでのデータ連携連携頻度は不定期カラム数やカラム名はその都度変わる
• データ分析基盤の機能面の充実化• Dataflow Primeの導入検討• 環境構築後のワーカーCPUとメモリのオートスケーリングが可能• データリネージツールの導入検討• Dataform• dbt etc..今後の展望34
35
gree_tech
keiko713
bengo4com
onlinesalon
joker1007
palark
radkmb
h1kita
yoshidashingo
smt7174
rdlabo
chloe463
lwug
iamctodd
samlambert
danielanewman
stephaniewalter
mojombo
sstephenson
keathley
jacobian
rasmusluckow
lauravandoore
jponch
mza