Download to read offline
![BUYMAの商品検索シ
ステム改善の取り組み
株式会社エニグモ
木村
kimura[at]enigmo.co.jp
2017/5/23, ヒカ☆ラボ](https://image.slidesharecdn.com/random-170523111225/85/BUYMA-1-320.jpg)
Uploaded by慎太郎 木村
BUYMAの商品検索システムの改善の取り組み
https://atnd.org/events/87466 商品検索システムをSolrCloudへリプレースし性能を強化した後、データ解析基盤をBigQueryに移行してデータドリブンで機能面でも商品検索を改善してきたことについてお話します。
BUYMAの商品検索システムの改善の取り組み
- 1.
- 2. 自己紹介 • 所属 • 株式会社エニグモ •サービスエンジニアリング 本部 • 基盤開発グループ リード エンジニア • 入社４年目 • 最近 • 検索システムの改善 • レコメンドエンジン の開発
- 3.
- 4. BUYMAのインフラの規模感 • 基本的にオンプレミス • サーバー台数：物理約70台、論理200台強 •一部クラウド化 • AWS、Akamai、GCP • 脱オンプレへと進行中
- 5.
- 6.
- 7.
- 8.
- 9. 問題点 • 単一障害点だらけ • Solrが１つでもダウンすると検索も更新もエラー •障害時にIP管理ファイルのデプロイが必要 • 更新バッチも冗長化してなかった • 復旧が大変 • Solr同士のデータを揃えるのが大変
- 10.
- 11. SolrCloudにしたわけ • 他にもMaster-Slave構成とかありますよね？ • Masterを冗長化しないと単一故障点に •Solrへの間にLBを挟めばいいのでは • LBを冗長化しないと単一故障点に
- 12. rsolr-cloud • SolrCloudの対応のrubyク ライアントを自作 • gemとして公開 •fluentdやlogstashのプラ グインにも取り入れられ ている
- 13.
- 14.
- 15.
- 16. キーワードへの関連度をソート に取り入れた • 以前は商品人気度（秘伝の算出ロジック）での単純なソ ート（クエリ非従属） • solrのクエリーパーサーをedismaxにしてスコアでソート •フィールドごとにスコアの重み付けを指定可能 • e.g. カテゴリ名のフィールドにヒットしたら上位に • 従来の人気度もboost function (bf) で利用
- 17. 形態素解析を導入 • 「ファー」で検索しても「サーファー」や「フ ァースト」などは上位に来なくなった。 • ユーザー辞書の管理ツールも作成 •シノニム辞書も導入して同義語の差異を吸収 • iPhone、アイフォン、アイホン、アイフォー ン
- 18. 秘伝のタレを壊してしまう怖さ • そこそこ上手くいっていた従来の商品人気度(秘伝のタレ ) • 問題ないキーワードが逆に悪くならないの？ •改善したとしてどのぐらいCTR良くなったの？ 検索条件ごとのCTR計測が必要に
- 19.
- 20. 計測すると安心して修正できた • 感覚ではなく数値でロジックの正当性を裏付けられる • 良くわからないけど上手くいってた秘伝のタレにも手 を加えられる •微妙なsolrのクエリパラメータチューニングの効果測 定も可能 • ABテストによる比較も可能
- 21. 今後 • 検索のUIUXも改善していきたい • BigQueryのデータを幅広く活用していく •機械学習 • データ解析など
- 22.
Editor's Notes
- #2 それでは、BUYMAの商品検索システム改善の取り組みというテーマで発表を始めます
- #3 自己紹介ですけど、株式会社エニグモに所属しておりまして、だいたいスタッフはアルバイト等を含めると１００名ぐらいいるんですけど、その中でエンジニアが集まるサービスエンジニアリング本部という部署が30名ほどおりまして、基盤開発グループという、アーキテクチャ設計したりパフォーマンス改善ですとか、検索基盤、データ解析基盤などのシステムの基盤となるところを開発するグループに４名ぐらいおりまして、そこに所属しています。 入社４年目になります。 最近は今日お話します検索システムの改善や、レコメンドエンジンの開発を主にやってます。
- #4 運営しておりますバイマについて軽く紹介しますと、主にファッションアイテムを扱うCtoCのショッピングサイトなんですけど、出品者が世界中いるというのが１つの特徴となっています。会員数は２月に400万人を超えまして、順調に成長しております。できたのは2004年なんですけど、途中でPHPに書き直す、Railsに書き換えたり、ガラケーサイトを閉じたりとか歴史あるサービスになります。
- #5 次にBUYMAのインフラの規模感ですけど、基本的にオンプレの自前のデータセンターで動いていて物理ベースで70台、仮想化してるんですけど論理ベースで200台強となっています。だいたいこれでピークタイムで毎秒1000リクエスト前後ぐらい捌いていると思います。 一部クラウド化していまして、AWS、Akamai、Google Cloud Platformを導入しています。脱オンプレへと進行中です。
- #9 さて、今日お話するのは２つトピックがありまして、 １つは、商品検索システムの耐障害性の向上についてお話します。 ２つ目は、キーワード検索の精度向上についてお話します。 一見どれもレガシーとは関係ないんですけど、どちらも古い仕組みをどうやって改善したかというお話になります。
- #10 では、耐障害性の向上から始めます。 ブログ記事にもなってますので、あとで見てみてください。
- #11 こちらは改善前の構成なんですけど、独立したSolrサーバーが複数台並列に並んでるだけで、バイマはRailsで出来てるんですけど、そのアプリケーション側で負荷分散してSolrへリクエストしていました。更新は絶えず動いているPHPでできた更新バッチがDBから更新データを取得しては全台に対して更新をかけていた状態です。
- #12 SolrのIPはどうやって管理されてたかというと、設定ファイルをSolrのクライアントになる各アプリケーションが持ってい他状態なので、なのでSolrがダウンしても設定ファイルをデプロイし直さないと切り離しとか切り戻しができないという状態でした。ここらへんがレガシーですね。
- #13 この構成の問題点は単一障害点だらけだということです。Solrが１台でもダウンすると検索も更新もエラーになってましたし、復旧するのにデプロイしないといけないという大変さもありました。 また、更新バッチも冗長化してなかったので、絶えず動いているバッチなので、そのサーバーが止まると商品を出品したのに検索結果に出てこないという状態になってしまうのも問題でした。 復旧にも大変で、切り戻すときにSolr同士のデータを揃えるのが大変でした。 経緯としては、このままマスキャンペーンを打ってユーザー数が増えたらひとたまりもないということで、リプレースに踏み切りました。
- #14 そこで、Solrのクラスタ管理を自動化してくれるSolrCloudを導入しました。 IPを設定ファイルで管理していましたが、Zookeeperが管理してくれるようになるので、アクティブなSolrのIPを取得できたり、Solrがダウンして更新されたらクライアント側に逆に通知してくれたりするので、ダウン状態のSolrへはリクエストが行かなくなり、エラーも発生しなくなりました。 更新の仕組みは、バッチサーバーでやってたのをResqueっていうRedisをバックエンドにしたRuby製のバックグラウンドジョブでやるようにしました。これは冗長化が容易だったのでこの点でも単一故障点が解消されました。 SolrCloudは常にLeaderのサーバーが更新されれば他のサーバーへレプリケーションされるという機能があるので、更新するのは常にLeaderのサーバーだけでいいですし、そのLeaderもダウンするとフェールオーバーしてくれて、ReplicaがLeaderに昇格してくれます。
- #15 SolrにはMaster-Slave構成っていうのもあるんですけど、これだとMasterを冗長化しないとそこが単一故障点になりますし、Solrへの負荷分散をLBでやればいいのではというのはLBを冗長化しないと単一故障点になるということで、ある程度負荷が高いところを冗長化するのって管理とかも含めてコストなんで、SolrCloudにしました。
- #16 この改善によって単一障害点を排除できましたし、更新部分もバッチだったのをResqueワーカーにして冗長化できました。 復旧もノードを組み入れるだけでデータが同期されるということで簡単になりました。
- #17 頑張ったところは、SolrCloud対応のRubyクライアントを作ったところです。rsolr-cloudとして公開しています。rsolrっていう有名なsolrのrubyクライアントを拡張したものです。ruby製のツールでfluentdとか、logstashなどのログ収集のツールにも組み入れられていたりして、yahooの検索のエンジニアの人がyahoo社内のログ収集という意外なところでも活用されているようです。
- #18 続きましてキーワード検索の精度向上についてお話します。
- #19 以前、バイマで「ポーチ」を検索しても、全然関係ないものしか上位に来ないという状態でした。他にも同じようなヒットするのに上の方に来ないっていうキーワードがたくさんありました。
- #20 これは何故かと言うと、出品者さんが自分の商品のインプレッション率を高めようとしてSEO対策のようなことをされていて、商品コメントの下の方に商品自体には関係なくても検索されそうなキーワードを下の方に散りばめるテクニックが横行していたことが原因の１つでした。
- #21 そこで、キーワードへの関連度をソートに取り入れました。 以前は、商品人気度を算出する秘伝のロジックがあるんですけど、それで単純にソートしていただけでした。 キーワードとの関連度も取り入れるというのは、具体的には、solrのクエリーパーサーをedismaxにして、スコアでソートします。 フィールドごとにスコアの重み付けを指定可能なので、たとえばカテゴリ名のフィールドにヒットしたら上位に持ってくうるという調整も可能です。 従来の人気度もboost functionというパラーメーターで利用して程よく人気順で並ぶようにしています。
- #22 それから、N-gramしか使ってませんでしたが、形態素解析を導入しました。毛皮とかの「ファー」で検索しても全然関係ない「サーファー」とか「ファースト」などは上位に来なくなりました。誰でも単語登録できるようにユーザー辞書の管理ツールを作成しています。 シノニム辞書も導入して同義語の差異を吸収しています。
- #23 気を使ったのは、秘伝のタレを壊してしまう怖さでした。 ある程度、商品人気度の算出ロジックを壊してしまうので、KPIへの影響が心配でした。問題ないキーワードが逆に悪化しないかとか、改善したとしてどのぐらい検索結果のCTRがよくなったかという評価も必要でした。 そこで、検索条件ごとでCTRの計測が必要になりました。
- #24 CTR計測の仕組みはこのよみなっていて、ブラウザでのクリックやネイティブアプリでのタップのイベントをWeb APIで収集してBigQueryで集計し、re:dashやあとは自前の計測ツールで見れるようにしました。
- #25 この計測の仕組みで秘伝のタレを壊す怖さから開放され、安心して改善に挑むことができました。 感覚ではなく数値でロジックの正当性を裏付けられるようになったのが大きかったです。 微妙なsolrのクエリパラメーターチューニングの効果測定も可能でしたし。 ABテストによるCTR比較も可能になったので、少しづつ様子を見ながら全体にリリースしていくということも可能になりました。
- #26 今後は、検索の並び順だけではなく、UIUXをこの仕組でも改善できたらいいなと考えています。 それから、BigQueryのデータをより幅広く機械学習、データ解析などで活用していきたいと考えています。
- #27 発表は異常なんですけど、これらを一緒にやりたいエンジニアを募集中です。 以上、ご清聴ありがとうございました。