【レポート】メルカリ写真検索における Amazon EKS の活用事例

現在開催されているAWS Summit Tokyo 2019において、以下のセッションを聴講したので、そのレポートをお届けします。

• メルカリ写真検索における Amazon EKS の活用事例

セッション内容

メルカリ写真検索における Amazon EKS の活用事例

セッションスピーカー

株式会社メルカリ　SRE/Team AI　SRE/ML Engineer　中河 宏文様

hnakagawa（@hnakagawa14）さん / Twitter

セッション概要

写真検索とはいわゆる画像検索機能で、複雑なバッチ・ETL(データ抽出、変換、転送処理)とコンテナ・サービス群で構成されています。今回はその仕組みを実現しているバックエンドとインフラを AWS EKS 活用事例とともにご紹介します。

セッション資料

「メルカリ写真検索におけるAmazon EKSの活用事例」

写真検索機能とは

いわゆる写真検索機能。こちらをご参照ください。

• フリマアプリ「メルカリ」、「写真検索機能」を導入 | 株式会社メルカリ

内部仕様は以下の通り。

1. Deep Neural Networks（DNN）を使用して商品画像から特徴ベクトルを取得
2. Approximate Nearest Neighbor Index(ANN Index)に追加して画像indexを構築
3. 検索時には同じく商品画像から、DNNを介して特徴ベクトルを取得し、ANN Indexから検索

バックエンドにEKSを利用。Custom Resource Definitionと呼ばれる独自のリソースを定義できる機能を利用している。

Custom Resource Definitionとは独自にリソースを定義できるk8sの機能。カスタムコントローラが、CRD・リソースのライフサイクル状態に応じてクラスタの状態をコントロールする。

ML Platform Lykeion

内省のML Platformを構築。特徴は以下のとおり。

• Training/Serving CRD
• コンテナベース・パイプライン
• Training/Serving コンテナイメージ・ビルダー
• モデル、レポジトリ

全体アーキテクチャは、AWSとGCPのマルチクラウド構成となっている。

1. Training・リソースの作成

ANN indexingはtrainingフェーズとして利用。Training custom resourceをCronJobが作成。カスタム・コントローラがCRD、リソースで設定されたコンテナベース・パイプラインを実行。実行するバッチ単位としては、Hourly、Daily、Monthlyが存在。

• コンテナベース・パイプライン
  • 各工程を個別のコンテナ・イメージで実行
  • ライブラリの依存関係などはナイーブなため、コンテナで独立性を高めている

全てのバッチ実行情報がCRDリソースとしてk8s上に残る。同じ処理を再実行できるため、バッチの再実行を伴う障害復旧作業が容易となる。

2. 画像のダウンロード

Amazon S3上に存在するメルカリ・イメージストアから商品画像をダウンロード。一番時間がかかっている。

3. アセットのアップロード

• パイプラインの成果物である特徴ベクトルとANN Indexをモデル・レポジトリに保存
• 全ての成果物はバージョン管理された状態で保存
• モデル/レポジトリはGCS上に構築

4. Serving イメージのビルド

1. モデルレポジトリをImage Builderと呼ばれるdaemonが監視
2. 新しいServingすべきリソースが追加されると自動でServingコンテナ・イメージをビルド
3. ビルドされたコンテナ・イメージをコンテナ・レジストリにプッシュ

5. Servingリソースの作成

• Image Builderはコンテナ・イメージをビルドした後、Servingカスタム・リソースを作成
• Serving カスタム・コントローラはCRD・リソースの設定を元に必要なDeployment、Service等を作成
• 本システムでは、構築されたANN Indexを個別のIndexサービスとしてデプロイ

6. サービスディスカバリ

• クラスタ上に存在するIndexサービスをk8sを介して自動的に取得
• 大きな粒度のIndexを使用するよう、異なる基幹・粒度のIndexサービスを自動的に組み合わせる
• REST＜-＞indexサービス間のプロトコルはgRPCを使用

Amazon EKS

k8sといえばGCPというイメージがあるが、EKSもだいぶこなれてきている。

• Pros
  • 素のk8sに近く、そういった意味では柔軟な構成をとることができる
• Cons
  • 他社のマネージド・サービスに比べると、扱いづらい点がある

AWSの良いところ

なんと言っても、RDS、Auroraに代表される、マネージドRDBMSが利用できるところ。最初RDSでつくって、パフォーマンスで困ったらAuroraにするなどもあり。

まとめ

普段自分も使っているサービスの裏側を垣間見ることができて面白いセッションでした。マルチクラウドで、AWSとGCPをフル活用して、写真検索サービスを運用するアーキテクチャは非常に高度で、学びが多くありました。