はじめに
技術部データプラットフォームグループのグループリーダーの富士谷です。 技術部は去年まで、テクノロジカルマーケティング部でしたが、今年から組織が大きくなって名前が変わりました。
私事ですが、リブセンスに入社してから約5年、データプラットフォームグループでEngineering Managerをはじめて2年ちょっとが経ちました。 去年はこのブログでSoftware Designへの寄稿の話やOpenAI API社内利用環境を整えた話、レビューの話を書きましたが、普段は、リブセンスのデータ基盤の開発をしています。
リブセンスにはデータ基盤が大きく分けて2つあります
- Livesense Analytics
- データ分析基盤（データ収集・蓄積基盤）
- Livesense Brain
- データ活用基盤（推薦・機械学習基盤）
この2年で、特にLivesense Analyticsをドラスティックに変えてきたのですが、改めてリブセンスのデータ基盤とともに、取り組んだ課題や今後の展望をまとめて紹介しようと思います。
リブセンスとデータ
リブセンスはデータによる意思決定を大事にする文化があり、企画職や営業職など色んな人が社内でSQLを書いています。 少し昔の資料ですが、SQLを書く文化については、以下が参考になります。今でこそ、データ活用は世間一般に浸透していますが、当時は先進的だったのではないかと思います。
www.slideshare.net
データプラットフォームグループは、データを収集、蓄積し、データ活用につなげることに取り組む専門の横断組織です。成り立ちはこちらにあります。
それぞれ内容の細かいところは変わっていますが、思想やカルチャーは変わってないと思います。
Livesense AnalyticsとLivesense Brain
リブセンスのデータ分析を支える、データ収集や蓄積のためのシステム群がLivesense Analyticsです。要は、Google Analyticsのようなものを内製しています。 Livesense Analyticsでは、Webのアクセスログやネイティブアプリの行動ログ、プロダクトのDB上のデータや、外部データを集めて、データウェアハウス（今はRedshift）に集約しています。 主にはAWSで実装していますが、最近、GCPに移し始めています。 ちなみに、Livesense Analytics の誕生日がはっきりしませんが、2012年くらいの情報が社内には残っているので、少なくとも11年は経ってそうです。
一方、Livesense Brainは、主には、Livesense Analyticsで収集した情報を使って、情報推薦や機械学習モデルを実行させ、プロダクトで活用しています。 こちらも少し昔の資料ですが、成り立ちはこちらにあります。
Livesense Brainは、GCP上に構築しており、GKE Autopilot上でArgo Workflowを動かしています。APIの開発のため、Cloud Runなども利用しています。 機械学習に限らず、一般的なWebページやバッチ処理が開発しやすい構成になっているので、最近は、OpenAIのAPIの実行環境やRedashとスプレッドシートの連携ツールを動かすなど、データ活用一般を支える基盤になっています。
2年前の課題意識
さて、そんなデータプラットフォームグループですが、私がEMになった2年前には、色々と課題がありました。
システムの課題
Livesense Analyticsは「10年物」で内製部分が多いこともあり、技術的な負債が蓄積していました。
一言で言えば「システムが複雑」でした。例えば、データ加工の処理も、「このシステムではScala使ってEMRでバッチでETL」「このシステムではnode.js使ってLambdaでイベントドリブンにETL」「このシステムはPython使ってSQLでELT」みたいに様々で、同じことをやるのに3つくらい違う方法で実装されていたりしました。 当時は要件上、それがベターだったのかもしれませんが、要件を見直すとそうでもなさそうでした。
他にも、「中途半端な状態でシステムが残っている」ものもありました。 あるプロダクト向けに利用されるところまでシステムを作ったのは良いのですが、他のプロダクトへの導入が途中で止まっており、新旧どちらの機構も残ったままになっている、ようなものもところどころにありました。
総じていえば、開発効率が悪く、すべてをひっくるめて再設計・再実装が必要な状態でした。
チームの課題
私は「システムはチームを反映する鏡」のようなもので、システムの課題はチームの課題と表裏一体だと思っています。 「課題管理が適切にされていない」ことが、前述の負債の背景にはありました。 負債の存在自体は一定チームとしても認識があったようではありますが、具体的に「どこがどう大変なのか」「どう直せそうなのか」が、ほとんど言語化されていませんでした。 私自身、入社以来Livesense Brainを開発していたので、EMになった当時は、Livesense Analyticsのシステムのことは何もわかっておらず、「どこが課題で、どう考えていたんだかよくわからない…」とよく思っていました。
また、正直に言えば当時、何人かのメンバーが続いて離職していましたが、人的リソースの活用も効率的とは言えない状態でした。 Livesense Brainは、開発環境が整っており開発体験は高い状態だったので「データソースのLivesense Analyticsを変えて、Livesense Brainもどんどん大きく変えていこう」と考えても、Livesense AnalyticsとLivesense Brainのそれぞれの採用技術の差異が大きく、ハードルが高い状態でした。
まずはLivesense Analyticsをリブートさせ、土台を作り変えなければ、という状態にありました。
ここ2年で変えたこと
課題管理と地道な整理
「負債が多い」といえども、「課題」として扱われていないような状態だったので、何がどう問題なのかを把握するところから始める必要がありました。 全体の構成を理解しながら、GitHubでたくさんissueを作成して、それらをまとめてプロジェクトやタスクにしていくなど、課題管理を見直していきました。 また、プロジェクトやタスクが適切に終えられるように、スコープを適切に設定することを心がけました。 例えば、リプレイスなら作って動かすまで、ではなくて、古いシステムを削除するまでやりきる。 PoCであるなら、流れでそのまま運用まで進めずに、やめるか作り込むかを判断する。 小さなシステムも含めてリプレイスしつつ、使ってないシステムやテーブルを削除するなど、地道な整理を進めて行きました。 特別なことではなく普通のことですが、基本を忠実に、負債に取り組みました。
採用技術の統一
システムをリプレイスする過程で、採用技術も少しづつ標準化していきました。 グループ内で採用技術を統一するため、Pythonをはじめとして、Livesense Brainと極力同じ構成を採用しています。 複雑性が解消されつつあり、収集から活用まで、大きな垣根がない開発が簡単になりつつあります。
とはいえ、すべて一気に変えると、多くのコード資産を捨てることになり、それはそれで大変です。 例えば、ECS on EC2/Fargateを使ったり、Airflow on EC2 から MWAAにしたりするなど、ワンクッション置いてAWS内でリプレイスしたりもしています。
Google AnalyticsとBigQueryの活用
Livesense Analyticsの中核の一つであるWebのログ収集は、これまで内製していましたが、Google Analytics 4 をベースとしたシステムに変えました。 デファクトスタンダードなサービスを使うことで、運用も楽になり、世の中の変化や進化にも追従しやすくなります。巨人の肩に乗れるところは乗ろう、という思想ですね。
近々、ネイティブアプリのログ収集部分もGoogle Analytics 4ベースに変更する予定で、このために、GA360も導入しました。 これが完遂すれば、さらに相当量が整理される予定です。
Google Analytics 4のBigQuery Exportを利用していますが、これをきっかけにして、BigQueryの活用を他のシステムにも広げています。 従来は、EMR（Spark）などでETLをしていましたが、BigQueryとSQLのELTにすることで、処理を相当にシンプルにできます。
今後2年でやりたいこと
目下の課題は解決しつつありますが、まだ、変えていきたいことはあります。 直近で取り組んでいることを紹介します。
RedshiftからBigQueryへ移行
Livesense AnalyticsではRedshiftにデータを集約しています。 ある程度は、安価で便利に使えてはいるのですが、少々、苦労していることもあります。 コストパフォーマンスの面から、長期間DC2を利用していますが、メンテナンスタイムがあったり、コンピュートもデータもスケールもさせ辛く、なにかとマシンを意識しないといけません。 Redshift Spectrumも活用しているものの、データの配置先を考えたりする必要があったり、Redshiftそのものとは使い勝手が少々違います。 また、前述の通り、Google Analytics 4の主要なデータがBigQueryに蓄積されていますが、利用者はRedshiftを使っているため、BigQueryからRedshiftへのデータ移動を行う必要があり、これもまた大変です。
RedshiftからBigQueryに移行する、というのがこの2年くらいの主な計画です。 上述の負担を減らすだけでなく、機能性も高められると思っています。 BigQueryは半構造化データの型もリッチにサポートされていますし、BI EngineやBigQuery MLにも期待しています。 BigQueryでは、プロジェクトでデータを分けやすくもなるので、各部署との連携もやりやすくなるのではと思っています。 メリットは十分にあると考えています。
現在、Redshiftには数百のテーブルがあるので、これらをBigQueryにうまく移していかないといけません。 利用者も多いため、ユーザの混乱を招かないようにする必要もあります。 今は様々な準備を続けていますが、最後までやりきるために、コツコツと着実に進めていこうと思っています。
AWSからGCPへの完全移行
プロダクトの開発では、AWSを利用していることが多いものの、データウェアハウスをRedshiftからBigQueryに変えれば、Livesense BrainやGCPとのシナジーのほうが高く、AWSで構築する意味はほぼなくなると考えています。 すでに、Livesense Analyticsの複数のシステムをAWSからGCPに移行していますが、AWS内でワンクッション置いてリプレイスしたシステムも含めてさらにもう一歩踏み込んで移行することで、運用コストやシステムコストを下げていく予定です。
その後の展望
上述の開発が終われば、土台が整ってくると思っています。上述の開発の後、または同時に、やっていきたいことはたくさんあります。 要約すれば、「データを集めるだけでは価値はなく、データは使われて初めて価値が生まれるのだから、基盤ではなくソリューションに目を向けていきたいんだ」という感じですが、私の現時点の考えを書いておこうと思います。
データの多くはプロダクトで生成され、分析や活用もプロダクト側が主体で行われることが多いですが、上流（データソース）と下流（分析や活用）のどちらにも一歩踏み込んで、より高度化したい。 Google Analyticsを例に取れば、上流で言えば、Google Analyticsの収集ではカバーできないユースケースもありそうなので、将来的には再度、収集部分を内製することもあるかもしれませんし、下流で言えば、SQLだけでは大変なアトリビューション分析とか他サービスとの連携とかに活用を広げていきたいです。
他にも、Livesense AnalyticsはA/Bテストに使われることも多いですが、ツールの開発や勉強会（A/B テストを本気で考える）などに取り組んではいるものの、まだまだ、歩きはじめ*1という感じです。全社のデータ活用のスキルアップにも貢献していきたいですね。
活用の一端を担うLivesense Brainも、特に推薦は一定のパフォーマンスを得られており投資対効果が高い状態ではありますが、古典的な手法でベースラインを構築している事も多く、「次のベースライン」を作りたい。 Livesense Brainでは階層ベイズを用いて検索で利用するデータも作っていますが、検索周りでもパフォーマンスチューニングとか検索順位RAG(Retrieval-Augmented Generation)とかまだまだ取り組める課題は多数あると思っています。
Livesense Analyticsのデータ基盤も必要なピースがまだ足りていません。使っていきたい技術やツールはまだまだあります。 Dataformやdbtは早めに検証しようと思っていますが、他にも、DatastreamやAirbyteなどでのCDC（Change Data Capture）、VertexAIあたりも検証していきたいです。
上述のことをやるのに、今のデータプラットフォームグループという枠組みが適切なのかはわかりません。 すでに、Livesense AnalyticsとLivesense Brainの垣根は曖昧になりつつありますし、グループ内だけでなく、もっと、プロダクトに飛び込んだり、逆にプロダクトから我々に飛び込んできてもらえるようにしていきたい。あわせて、今のメンバーはデータエンジニアが中心だと考えていますが、アナリティクスエンジニア、機械学習エンジニア、推薦・検索エンジニア、データサイエンティストなど、より専門性が高いポジションを確立していきたいと思っています。 データ基盤の改善とデータ活用の推進の両輪を回しながら、チームも進化させるつもりです。
さいごに
リブセンスのデータ基盤であるLivesense Analyticsは少なくとも10年以上開発されてきましたが、ドラスティックに変わりつつあります。 今はまだ、データ基盤の利用者への影響を少なく、裏側のシステムを変えるようなフェーズですが、今後、良くも悪くもさらに大きな影響を利用者に与えていくことになり、挑戦が続きます。 リブセンスのデータ基盤を成長させ、かつ、データ基盤がリブセンスの成長ドライバーとなることを目指し、開発を続けていきます。
データプラットフォームグループでは採用を強化しています。 今後やっていくことは、本記事に記載したことに必ずしも限定しません。一緒によりよいデータ基盤を作りませんか。 もし興味があれば、下記の求人をご確認ください。
*1:A/Bテスト実践ガイドに書かれている実験成熟度モデルでいえば、多くはクロールフェーズで、一部ウォークフェーズに入りかけているかなと思っています
