1 Vertex AI Matching Engine と CLIP を使って EC サービスの 類似画像検索機能を作る 財津 ⼤夏｜GMOペパボ株式会社 2023.08.05 GDG Cloud Fukuoka ミートアップ 

2 ⾃⼰紹介 GMOペパボ株式会社 技術部データ基盤チーム シニア Google Cloud Professional Data Engineer 財津 ⼤夏 Hiroka Zaitsu ● データ基盤「Bigfoot」の開発運⽤ ● 𝕏 @HirokaZaitsu #Google Cloud #Airflow #MLOps #データマネジメント #ドライブ #スバル 

3 話すこと 1. ペパボとデータ基盤「Bigfoot」 2. できるようになったこと 3. システム構成 4. 今後やりたいこと 

4 ペパボと データ基盤「Bigfoot」 マスコットキャラクター Bigfootくん キャラクターグッズあります https://suzuri.jp/zaimy/designs/13278107 

5 

ペパボとデータ基盤「Bigfoot」 Source 6 Bigfoot の構成 Pipeline Viewer Extract Analytics/ML Monitor Ingest Pub/Sub Cloud Storage Dataflow Batch Vertex AI BigQuery Looker Studio Orchestrator Cloud Composer Cloud Monitoring Cloud Logging 

ペパボとデータ基盤「Bigfoot」 Source 7 Bigfoot の構成 Pipeline Viewer Extract Analytics/ML Monitor Ingest Pub/Sub Cloud Storage Dataflow Batch Vertex AI BigQuery Looker Studio Orchestrator Cloud Composer Cloud Monitoring Cloud Logging このあたりの話 

ペパボとデータ基盤「Bigfoot」 8 ● 商品推薦 ● バンディットアルゴリズム ● ⽣産性指標（Four Keys）の測定 ● 類似画像検索 データ活⽤の例 エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 

9 できるようになったこと 

セクションタイトル 10 できるようになったこと キャトルハム / みぞぐちともや ( tomoya_mizo )のスタンダード Tシャツ - https://suzuri.jp/tomoya_mizo/2721053/t-shirt/s/white 仙台弁こけし（んでまず） / 仙台弁こけし ( kokesu )のビッグシルエット Tシャツ - https://suzuri.jp/kokesu/3150177/big-t-shirt/l/white 

できるようになったこと 11 キャトルハム / みぞぐちともや ( tomoya_mizo )のスタンダード Tシャツ - https://suzuri.jp/tomoya_mizo/2721053/t-shirt/s/white 仙台弁こけし（んでまず） / 仙台弁こけし ( kokesu )のビッグシルエット Tシャツ - https://suzuri.jp/kokesu/3150177/big-t-shirt/l/white 

できるようになったこと 12 Flower ロンT / kamitamoのロングスリーブ Tシャツ - https://suzuri.jp/kamitamo/8453720/long-sleeve-t-shirt/s/white りんごの花 / shirokumasaanのスタンダード Tシャツ - https://suzuri.jp/shirokumasaan/645888/t-shirt/s/white 

システム構成 13 

Vertex AI Matching Engine ペパボとデータ基盤「Bigfoot」 14 システム構成 Batch Cloud Storage Cloud Composer 画像ダウンロードジョブ 特徴量変換ジョブ index / endpoint 画像オブジェクト 特徴量オブジェクト 

システム構成 15 ● 画像ダウンロードと特徴量変換のイメージを実⾏ ● rinna/japanese-clip-vit-b-16 で特徴量変換 ○ 事前学習済の CLIP モデル ○ ⾃然⾔語と画像のマルチモーダルモデル Batch でやっていること 

システム構成 16 ● GPU が利⽤できてリソースが独⽴している ○ Cloud Composer 2 で KubernetesPodOperator の実績あり ■ Cloud Composer の環境と分離したい ■ GKE Autopilot なので GPU がサポート外 ● Cloud Storage のバケットをボリュームマウントできる ○ ⼊出⼒になるファイル（オブジェクト）の受け渡しが簡単 Batch の選択理由 

システム構成 17 ● ジョブとタスク（VM とその上のコンテナ）は 1:n ● ジョブにタスク数と並列数を指定できる ○ BATCH_TASK_COUNT （タスク数） ○ BATCH_TASK_INDEX （実⾏中のタスクのインデックス） ● ジョブの処理対象のリストを元にタスクごとの処理対象を決定 ● ワークフローエンジン側で振り分けを⾏う必要がなく実装が簡素 Batch で複数のタスクに処理を振り分ける 

システム構成 18 ● Cloud Composer を使ってワークフロー化 ○ 全件登録と差分登録を同じパイプラインで管理できる ○ 条件を変えて index を複数作ってバンディットで競わせる Matching Engine の index 作成とデプロイ エンドポイント作成 index 作成/更新（パターン1） デプロイ（パターン1） index 作成/更新（パターン2） デプロイ（パターン2） 

システム構成 19 ● 安価なマシンタイプでも 95%ile のレイテンシはほぼ変わらない ○ 費⽤は約 3 分の 2 ○ シャード, ノード数も異なりますが参考まで Matching Engine のレイテンシ マシンタイプ / シャード / ノード数 50%ile 95%ile e2-standard-16 / MEDIUM 1 / 1ノード 約 5.8 ms 約 7.8ms n1-standard-16 / SMALL 2 / 2ノード 2.0~2.5ms 7.2~7.6ms 

システム構成 20 ● 特徴量は数百万ベクトル ● Batch: 数千円程度, 処理時間は10数時間 ● Matching Engine: 主にエンドポイントのサービングコスト ○ インスタンスサイズにより約 1 万円/⽉〜 ○ e2-standard-16 で約 7 万円/⽉ ● ⾃社開発/運⽤している近似近傍検索エンジンを置換できそう ⾦額と時間的コスト 

今後やりたいこと 21 

今後やりたいこと 22 ● 現在は素朴に GCS のオブジェクトとして管理 ● 特徴量変換と Matching Engine の index 登録の間に Feature Store を導⼊ ○ メタデータ管理 ○ ストリーミング取り込み（Streaming Ingestion） 特徴量管理の改善