メルカリの写真検索を支えるバックエンド

メルカリのAI EngineeringでTech Leadを務めている中河です。今回は3/18に正式リリースされた「写真検索機能」を支えるバックエンド・インフラをシステム側からの視点でご紹介します。

写真検索とは

所謂、画像検索機能で商品名を知らなくても画像から商品を検索できる機能の事です。詳しくは下記の公式リリースをご覧ください。

about.mercari.com

基本的な写真検索の仕組みは、Deep Neural Networks (DNN)を使用して商品画像から特徴ベクトルを取得し、取得した特徴ベクトルをApproximate Nearest Neighbor Index(ANN Index)に追加して画像indexを構築。
検索時には同じく商品画像からDNNを介して特徴量ベクトルを取得し、ANN Indexから検索します。

アーキテクチャの概要

f:id:hnakagawa14:20190322132720p:plain
Figure1

上記がアーキテクチャの概要図(Figure1)です。弊社では現在マイクロサービス化を進めており、写真検索機能もマイクロサービスとしてKubernetes(k8s)上に実装されています。インフラとしてはGCPとAWSを使用するマルチクラウド構成で、機械学習に関連するAPI群は内製のML Platformを使用してETLやbatchを管理・自動化しています。ここではまず図(Figure1)を元に写真検索機能のIndexingからServingまでの基本的な流れを説明します。

1. Creating training custom resource

ML Platformの仕組み上、ANN indexingはtrainingフェーズとして扱っており、ANN indexingはAWSのマネージドk8sサービスであるEKSに構築されたTraining Clusterで動いています。indexingのトリガにはk8sのCronJobを使用しており、CronJobがML PlatformのTraining CRD resourceを定期的に作成し、ML Platformは作成されたTraining CRD resourceを元にETLを実行、index構築を行っています(図 Figure2)。

f:id:hnakagawa14:20190322140508p:plain
Figure2

この仕組みによって、全てのbatch実行情報がCRD resourceとしてk8s上に残る為、batchの再実行を伴う障害復旧作業が容易になります。

2. Download images

ETLパイプラインの中でImage store(S3)上に存在する商品画像をダウンロードしています。実はパイプライン上の処理で一番時間が掛かるはこの工程で、写真検索ではダウンロードした商品画像をk8sのPersistent Volume(PV)に保存し一定期間キャッシュする事によって、再インデックスが必要な時には素早くETLを回せるようにしています。

3. Upload assets

ML PlatformはETLパイプラインの成果物、写真検索では特徴ベクトルとANN indexを、GCS上に構築されたModel Repositoryと呼ばれるモデルストアにバージョン管理された状態で保存します。

4. Build image

Model RepositoryをImage Builderと呼ばれるdaemonが監視しており、新しいindexが追加されると自動でServingコンテナ・イメージをビルドしContainer Registry(GCR)にプッシュします。

5. Creating serving custom resource

Image BuilderはServingコンテナ・イメージをビルドしたあと、Serving ClusterにServing CRD resourceを作成します。Serving ClusterはGCPのk8sサービスであるGKE上に構築されており、ML Platformは作成されたServing CRD resourceを元にDeployment、Service等のk8sリソースを作成しIndex serviceとしてdeployします(図 Figure3)。

f:id:hnakagawa14:20190322150619p:plain
Figure3
6. Service discover

現在indexは、hourly、daily、monthly、の各単位で自動で構築されServing Clusterにdeployされています。異なる期間のindexが自動でdeployされ続ける仕組みのため、各index serviceを利用するフロントのREST APIは最適なindex serviceを自動で検出・利用する仕組みを持っています。基本的なindex選択の戦略はなるべく大きな粒度のindexを選択し、使用するindex serviceの数を最小化するというシンプルな物です(図 Figure4)。

f:id:hnakagawa14:20190322150117p:plain
Figure4

以上が、写真検索システムの基本的な仕組みとなります。写真検索は、大きな画像データを複雑なETLパイプラインで処理する自動化された仕組みが必要で、またServing時の負荷設計も慎重に行う必要があるサービスです。そのため細かな工夫がまだまだ有るのですが書ききれないため、弊社のTech Event等また別の機会に説明したいと思います。

ML Platform Lykeion

最後に唐突にメルカリ内製のML Platform Lykeion(リュケイオン)の紹介をします。

f:id:hnakagawa14:20190322151304p:plain
Lykeion Logo

メルカリではLykeionと呼ばれる内製のML Platformを2017年末頃からML違反検知システム等で運用しており、 主な機能として、YAMLで記述するコンテナベースETL、モデル管理を行うためのModel Repository、コンテナ・イメージの自動ビルドを行うImage Buider、モデルの自動Serving機能等、今回の写真検索システムで使用している機能群があり、現在もサービスに合わせ随時機能拡張を行っています。

参考: Mercari Tech Conf 2018 speakerdeck.com

まとめ

今回も難産でしたが、どうにかこうにか出せて本当に良かったです。関係者の方々お疲れ様でした。また色々ご迷惑をお掛けしました(汗。お客様につきましては今後も機能向上や関連機能の予定がありますので、楽しみにして頂ければ幸いです:-)

  • X
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加