LIFULL HOME’S 閲覧ユーザー数集計システムを爆速で構築し施策化できた話

こんにちは。エンジニアの江口です。

普段はLIFULLの海外拠点の一つである、LIFULL Tech VietnamのメンバーとともにLIFULL HOME'Sの賃貸領域でサイト改善業務をしています。

今回は、物件の詳細ページを閲覧したユーザー数を集計、取得するシステム（以下rent-pv-counter）を構築したので、その取り組みについて紹介します。

背景

賃貸領域では、A/Bテストによるサイト改善を行っています。特に私の所属するチームでは、より多くの検証を実施し、ユーザーの行動理解を深めることをミッションとしています。しかし、実装工数を削減し、速やかに検証を進められるコストパフォーマンスに優れた施策が主流となる中で、結果的に検証可能な仮説の範囲も限定されてきていました。

その中で、閲覧中の物件の閲覧人数を可視化することが、問合せへの後押しにつながるかの検証を行うことになりました。この施策はバックログとしてはあったのですが、工数の観点で見送られていたものの一つです。今回は、リリースまでどのようなことを意識して開発したのかを共有できればと思います。

システム構成

以下の図は、rent-pv-counter の大まかな構成図です。

APIはExtensible Service Proxy V2 (ESPv2) をAPIゲートウェイとするCloud Runで稼働しています。OpenAPIに準拠したyamlファイルを元に、ESPv2がすべてのリクエストを受け取り、認証等を行ってくれます。さくっと認証付きのAPIを作るにはとても便利でした。また、DBはDatastoreを利用しており、ユーザーの閲覧ログを格納しています。

言語はGoで、WebフレームワークはGin を利用しています。APIはユーザーIDと物件IDを受け取り、その物件IDを閲覧したユーザー数を過去7日間、過去30日間で集計します。

集計結果の取得だけでなく、閲覧データの書き込みも同じエンドポイントで行っています。APIは受け取ったユーザーIDと物件IDをキューに格納し、キューにあるデータは定期的にDBに書き込まれます。こうすることで、DBへの書き込み負荷を軽減しつつ、かつ大きなタイムラグを発生させずに集計結果を返せます。

開発していて意識したポイント

この施策がバックログに留まっていた原因である、開発工数がかかるという懸念について、以下3点を意識しながら削減に取り組み、結果的に企画職（プランナー）に短期間で実装できる可能性を提示することができました。

積極的にマネージドサービスを使う

今回はCloud Run、Datastoreを利用し、基本的にはアプリケーションの実装のみに注力しました。Cloud Runではデプロイ、スケールアウトなどさまざまな処理を行ってくれます。また、Datastoreではエンティティの有効期限を設定し、古くなったデータを自動的に削除されるようにしました。こうすることで、エンティティを削除する処理を作ることなく、ストレージの費用も削減できます。

できるだけ過去の実装を再利用する

以前、物件の詳細ページにレコメンド機能を導入した際、類似のアーキテクチャを採用しました。その時もDatastoreを活用していたため、DBクライアントやWebフレームワークなどの基本構成をほぼそのまま使用しました。

拡張性を意識した設計

今後新たな機能を追加することも考え、アプリケーションはクリーンアーキテクチャを意識した設計にしました。検証の結果がプラスに終わり今後も提供を続けていくとなると、ある程度の拡張性は持たせておきたいと思ったためです。また、閲覧数で集計したり、別のアクション (お気に入り追加など) でも利用できるような設計にすることで、今後の改修の実装工数を下げることを意識しました。