これは Livesense Advent Calendar 2024 DAY 4 の記事です。
概要
技術部データプラットフォームグループでデータエンジニアをしている富士谷です。 さて、11/28に開催されたやってやったぜ！技術的負債解消 LT会 〜コードの整理整頓から未来の基盤構築まで〜（yabaibuki.dev #3）で発表しました。 発表資料を抜粋しつつ、簡単に内容を紹介します。
はじめに
リブセンスのデータ基盤は大きく分けて、収集・蓄積などデータ分析が主目的のLivesense Analyticsと、推薦や機械学習などデータ活用が主目的のLivesense Brainの2つがあります。 最近はデータウェアハウスの進化も著しく、収集や蓄積を変えていかないと活用も進化させにくいと考えていて、最近は特に、Livesense Analyticsの方を作り変えています。
リプレイスの概要はリブセンスの「10年物」のデータ基盤を作り変えている話に書いたのですが、この記事の公開から半年が過ぎ、状況が変わっているので、アップデートしています。 リプレイス前後の構成図も追加しています。
以前の分析基盤
本格的にリプレイスを始める前、2022年末ごろの構成図は以下のようなものでした。
都合上、いくつかのデータ収集機構やデータカタログ（当時はdmemo。24年現在はSchemaSpy）など、構成図に含めていないシステムもあります。 主要なデータソースは以下のようなものがあります。
- Webログ（フロントエンドからのログ）
- ネイティブアプリログ
- プロダクトのデータベース
- バックエンドログ（サーバサイドのアクセスログ、メール送信設定ログなど）
- その他ログ（メールクライアントからのログ、各種SaaSのログ）
これらの収集や加工は、Beanstalkとかlambdaなど、AWSのいろいろなサービスを使って実装されていました。 今から見れば「だいたいFargateでまとめられるのでは」とか「RedshiftでSQLで加工するとよいのでは」と思うところもあります。 が、構築当時はFargateが出たところだったり、SQLでの加工は複雑だったり、いろいろな事情があったようです。 加えてアーキテクチャを変えていくリプレイスもほとんどやってこなかったので、都度様々な思想で開発されていた、というのが実情でした。
現在の分析基盤
まだ一部リプレイス中のところもありますが、今はおおむねこのような構成図になってます。
主な変更点は以下のとおりです。
- Webログ・ネイティブアプリログは内製からGA4に
- AWSからGoogle Cloudに移行し、データ基盤の利用技術を標準化（Argo Workflows, Cloud Run, Python, etc...）
- プロダクトDBからのデータ収集はオンプレからEC2、ECSを経て、GKEに
- データをBigQueryに集約し加工もBigQueryで
多くは前述のブログ記事に書いているので省略しますが、特にBigQueryの活用について補足しておきます。 加工処理をRedshiftに集約してRedshift Serverlessを使うとか、いっそのことSnowflakeに移るとかの案もありました。 Redshift ServerlessやSnowflakeを深く検証したわけではないですが、以下のような理由でBigQueryを選択しています。
- GA4のエクスポートでBigQueryを必ず利用する
社内でGoogle WorkspaceやSearch ConsoleなどGoogle系プロダクトを様々利用している
もともとLivesense BrainでGoogle Cloudを使っていて様々な知見があり、新たに契約する必要がなく使い始めやすい
- Redshift Serverlessは60秒の最低料金で、最低のキャパシティも8 RPUあり、軽量だが頻発するクエリがあるとコストが高くなる
個人的にはSnowflakeのほうがBigQueryより勢いがあるようにも感じていますが、競合相手が居ることで相互に切磋琢磨して利便性が高まっていくといいな、と思っています。
少し未来の分析基盤
少し未来はこうしたい、という構成図が以下です。
今はBigQueryとRedshiftを併用しています。 BigQueryは主にローデータの保管や加工で利用し、利用者が限定的です。 一方、Redshiftは利用者が多いですが、インスタンス課金であり、実行されるクエリ管理をあまり厳密にせずにある程度自由に利用してもらっています。 結果的に二重課金も少なく、運用コストもおおむね限定的で運用できてはいます。
とはいえ、複数のデータウェアハウスを利用し続けるのは少々大変なので、RedshiftからBigQueryに移行したいと考えています。 ただ、特にRedashにクエリがたくさんあり、この移行がボトルネックになるだろうと推測しています。
先にクエリを整理するためにデータマートを拡充するか、それとも整理は少なめにしてクエリを移行してからデータマートを拡充するか、移行戦略は少々悩ましく、これから詳細を詰めていく予定です。 BigQueryには移行のための各種ツールが提供されていますが、より効率的に行うため追加のツールを開発したり、既存実装を変えたり、利用者の増加に備えてクエリ管理とかBigQuery Editionsの検証もしようと思っています。
一方で、しばらくはRedshiftを運用する必要があります。 こっちはこっちでインスタンス種別をra3に変えたり、一部でのみ利用しているRedshift Spectrumをやめたり対応が必要なところがあります。 移行は既存のデータ基盤を運用しながら徐々に、関係者の負担をできるだけ少なく、確実に進めていきたいと考えています。
最後に
システム面での課題は少なくなってきたので、より本質的な課題、例えばデータウェアハウスやデータ、業務、事業に関する課題に注力できるようになりつつあります。 俺達の戦いはこれからだ、という気持ちですね。
さて、登壇は技術広報チームの方々に、リプレイスにおいては技術部インフラグループや各事業部の方々に多大なご協力をいただきました。この場を借りて皆様に感謝します。ありがとうございました。
