こんにちは。ソウゾウの Software Engineerの @takashi です。連載：メルカリShops 開発の裏側 Vol.2の20日目を担当させていただきます。
はじめに
メルカリShops においてアプリ内での商品検索というのはとても重要な機能です。
メルカリShops の検索は「メルカリShopsのためのWebViewの技術」でもお伝えしたように、メルカリアプリ内で統合されており、メルカリアプリ内でメルカリShopsの商品も検索することができます。そのため、メルカリShopsで販売された商品は、メルカリで出品されているものと同じく月間2000万人以上のユーザーの方が検索でき、購入することができます。
購入された商品のうち、検索経由での購入は大きな割合を占めており、出店者さまが販売された商品が「すぐに」売れる体験を提供するために、検索を改善することはメルカリShopsにおいても重要です。
今回はそんなメルカリShopsの検索、そして改善を効果的に行うためのABテストがどのような仕組みで動いているのかをご紹介します。
商品のインデックス
前述のとおり、メルカリShopsの商品はメルカリアプリ内で検索することができ、メルカリの商品に混ざって表示されています。しかしメルカリShopsはメルカリと別のサービスであり、もちろん商品情報を格納するデータベースも異なります。
そのため、メルカリShopsの商品を検索に出すためには、メルカリShopsの商品情報を検索サービスにインデックスする必要があります。下にインデックスの処理の流れを簡単に図解します。
ここでは4つのサービスが登場しています。 product like searchadapter mercari_search です。順を追って説明します。
まず前提として、メルカリの検索は Elasticsearch を利用しています 。そして Elasticseach への インデックス はメルカリが持つ検索サービスが担当しており、今回はこれを mercari_search と呼びます。そしてその mercari_search へメルカリShopsの商品をインデックスするためのリクエストを送信するのがメルカリShops側のマイクロサービスである searchadapter です。この searchadapter は商品に関するイベントを Cloud PubSub 経由で購読し、受け取ったイベントに応じて mercari_search に対して gRPC を通じてインデックスのリクエストを送信します。
商品に関連するイベントは、商品の「作成」、「更新」、「削除」、そして商品に対する「いいね！」などがあります。 product や like サービスがそれらのイベントに応じて Cloud PubSub のイベントを送信しています。
また、実際にメルカリアプリで商品が検索され、表示される際、商品の更新からインデックスまでに若干のタイムラグがあるため、mercari_search で searchadapter から最新の情報を取得するようにしています。
検索の改善と AB テスト
前述した仕組みでメルカリShopsの商品をメルカリアプリ内で検索するということを実現しています。この仕組みを改善していくことで、より商品を売れやすくすることを目指しており、具体的には商品をインデックスするイベントの追加、削除などをすることでより商品が検索にヒットしやすくなるようにしています。
検索に関連する新しい機能を実装する際には、原則 AB テストを行いながらリリースを行っています。前述の通り、検索は商品が売れるという、メルカリShopsのコアな体験に直結する部分なので、慎重に検証しながらリリースをする必要があります。
では具体的に、検索のインデックスを行う部分をどのようにABテストしているのか、について説明していきます。
まず、メルカリShopsでのABテストに利用しているUnleashについて説明します。Unleash については「メルカリShops の技術スタック、その後」でも触れていますが、Feature Toggle 的な使い方の他に、 AB テストのような使い方ももちろん可能です。
また、Unleash は複数の Strategy からどのようにフラグをクライアント側に伝えるかを選択することができます。
例えば限られた社員のユーザーアカウントだけに機能を開放したい場合は UserID strategy を選択したり、IP アドレスを指定することで社内ネットワークからのみアクセスできるようにすることも可能です。そして今回のようなABテストを実施したい場合は、2つの選択肢を取ることができます。一つは Gradual Rollout Strategy を選択し、指定した割合のユーザーに対して機能を公開する方法、もう一つは Variants を利用して、指定した割合に応じてユーザーを Variant に割り当てる方法です。
1つめのやり方はシンプルですが、機能を公開する/しないの2つの値しか扱うことができないため3つ以上のユーザーグループを作成したい場合には適していませんでした。
2つめの Variant は任意の個数のユーザーグループを作成することができる点が Gradual Rollout とは異なります。
メルカリShops の検索ABテストではユーザーグループを3つ以上作成する必要があったため、2つめの Variant を利用しています。
次に、メルカリShops の検索において実際にはどのようにUnleash を利用しているかを説明します。
例えば商品を作成する際の検索へのインデックス更新処理に一部変更を加え、その効果を AB テストで測定したいとします。ユーザーのうち 50% にその機能を提供したい場合、searchadapter で対象ユーザーかどうかを判別する必要があります。
Unleash を利用する場合、サーバーへのリクエスト時にはリクエストヘッダーにABテストに関するVariantが追加されます。この情報をマイクロサービスでも参照するため、BFF でヘッダーの情報をパースし、再度マイクロサービスへのリクエストヘッダーに情報を詰めて渡しています。
最後にこの情報を、Cloud PubSub 経由で searchadapter に渡しています。Cloud PubSub はイベントデータの他にCustom Attributesが送信できる ため、それを利用しています。
おわりに
今回はメルカリShopsの検索と、その改善のためのABテストの仕組みについて書かせていただきました。複数のマイクロサービスをまたいで実施する ABテストでも、Cloud PubSub などを利用することでクライアントからの値を一貫性をもって受け渡すことを実現しています。
しかしまだまだ改善するところは多く、これからメルカリShopsを成長させていくために開発することがたくさんありますので、ソウゾウではメンバーを大募集中です。メルカリShopsの開発やソウゾウに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。
- Software Engineer
- Software Engineer, Site Reliability
- Software Engineer, Machine Learning
- Software Engineer, QA Test
- Software Engineer (Internship) – Mercari Group （※新卒採用に応募するにはまずインターンへの参加をお願いしています。）
またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらの申し込みフォームよりぜひご連絡ください。
