ZOZOTOWN の画像検索機能にみるKubernetes を使った機械学習基盤運用の裏側 / ZOZO Image Search Under the Hood with Kubernetes

Transcript

1. 1.

   ZOZOTOWN の画像検索機能にみる
 Kubernetes を使った機械学習基盤運用の裏側
 CloudNative Days Kansai 2019
 2019/11/28
 Copyright

   © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 開発部 MLOpsチーム
 太田 航平

2. 2.

   © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 開発部
 MLOpsチーム エンジニア 太田 航平


   2018年4月にスタートトゥデイテクノロジーズ(現ZOZOテクノロジーズ) に入社。
 開発部のPBチームにてAWSを中心に海外向け自社ECのインフラ開 発や運用などを担当後、SREとして各所のインフラに従事。
 2019年6月より、MLOpsチームに配属となり、主にGCPを使った機械 学習基盤の設計構築や運用などを行っている。
 2
3. 3.

   © ZOZO Technologies, Inc. https://zozo.jp/
 • 日本最大級のファッション通販サイト
 • 1,200以上のショップ、7,300以上のブランドの取り扱い（ともに2019年6 月末時点）


   • 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など
 3
4. 4.

   © ZOZO Technologies, Inc. https://wear.jp/
 • 日本最大級のファッションコーディネートアプリ
 • 1,300万ダウンロード突破、コーディネート投稿総数は900万件以上（と もに2019年9月末時点）


   • 全世界（App Store / Google Playが利用可能な全ての国）でダウンロー ドが可能
 • 200万人以上のフォロワーを持つユーザー（WEARISTA）も誕生
 4
5. 5.

   © ZOZO Technologies, Inc. https://zozo.jp/multisize/
 
 • 身長と体重を選択するだけで理想のサイズの商品が見つかる新しい洋 服の買い方
 •

   ZOZOSUITで得た100万件以上の体型データを活用し、20～50サイズ のマルチサイズ（多サイズ）に展開
 • 2019年秋冬アイテムから、人気ブランドのマルチサイズアイテムを販売 開始
 【参加企業】
 　株式会社アーバンリサーチ、株式会社ストライプインターナショナル、
 　株式会社デイトナ・インターナショナル、株式会社パル、株式会社ビームス、
 　株式会社ベイクルーズ、MARK STYLER株式会社、リーバイ・ストラウス ジャパン株式会社　　など
 5
6. 6.

   © ZOZO Technologies, Inc. • ZOZOTOWN における画像検索
 • 画像検索プラットフォームの構成
 •

   Kubernetes 選定の理由と内部の構成
 • 本番稼働までに抱えた課題とその解決策
 アジェンダ
 6
7. 7.

   © ZOZO Technologies, Inc. 7 ZOZOTOWN における画像検索


8. 8.

   © ZOZO Technologies, Inc. 8 • サイトの画像からアイテムを検出 • カテゴリごとに分類 •

   ZOZOTOWN で実際に販売されてい る類似のアイテムを表示 ↓ 安い商品や、売り切れた商品からの導 線としてサジェストすることでユーザー の購買意欲を促進 ZOZOTOWN における画像検索

9. 9.

   © ZOZO Technologies, Inc. 9 画像検索プラットフォームの構成


10. 10.

    © ZOZO Technologies, Inc. 10 ZOZO グループがもつ情報資産


11. 11.

    © ZOZO Technologies, Inc. 11 画像検索プラットフォームのチーム構成
 青山研究所 (研究者) • ZOZO

    の情報資産を用いた機械学習の基礎研究 福岡研究所 (ML エンジニア) • 機械学習データを用いたプロトタイプの開発 iOS, Android, Web (フロントエンジニア) • 画像検索APIを叩いて、ユーザーに結果を表示する部分の開発 MLOps • モデル作成からWebまで機械学習基盤周りのインフラを全般的に担当
12. 12.

    © ZOZO Technologies, Inc. 12 画像検索プラットフォームのチーム構成
 青山研究所 (研究者) • ZOZO

    の情報資産を用いた機械学習の基礎研究 福岡研究所 (ML エンジニア) • 機械学習データを用いたプロトタイプの開発 iOS, Android, Web (フロントエンジニア) • 画像検索APIを叩いて、ユーザーに結果を表示する部分の開発 MLOps • モデル作成からWebまで機械学習基盤周りのインフラを全般的に担当 今回のメイン
13. 13.

    © ZOZO Technologies, Inc. 13 ZOZO における MLOps チームのミッション
 •

    ML エンジニアや研究者が機械学習モデルの開発に集中できる環境を提供する • プロトタイプをプロダクションレベルに引き上げる → 研究者、ML エンジニアたちが作ったものを実際にサービスインし運用まで行う
14. 14.

    © ZOZO Technologies, Inc. 14 Why 画像検索？


15. 15.

    © ZOZO Technologies, Inc. ZOZOTOWN における商品の検索 • テキストベース (キーワードなどによる) の検索


    • カテゴリ・カラー・性別などで絞り込み
 15 テキストベースの検索 カラーやカテゴリなどから絞り込み
16. 16.

    © ZOZO Technologies, Inc. ファッションドメインにおける商品検索の難しさ 16 • 1. 欲しい商品が漠然としている
 ◦

    ユーザーは大抵特定の商品 (例えば、わかりやすい固有名詞が付いているよう なロボット掃除機・ゲーム用端末など具体的な何か) が欲しい訳ではない
 ◦ 一方で、コモディティ化が進み切ってるかというとそうでもない
 • 2. ファッション用語が分からない・知らない
 ◦ そもそもファッション用語に明確な定義がない場合もある

17. 17.

    © ZOZO Technologies, Inc. ファッションドメインにおける商品検索の難しさ 1. 欲しい商品が漠然としている 17 よく知られた固有名がついていない /

    コモディティ化しきってるわけでもない 欲しいものの固有名詞で探せる 大きな分類で探せばどれでもいい ※版権の関係上公開時に削除 ？
18. 18.

    © ZOZO Technologies, Inc. ファッションドメインにおける商品検索の難しさ 2. ファッション用語が分からない・知らない 18 ファッション用語そのものに関心がないと知り得ない (服との関心とはまた別物)

    ※版権の関係上公開時に削除
19. 19.

    © ZOZO Technologies, Inc. ファッションドメインにおける商品検索の難しさ 2. ファッション用語が分からない・知らない 19 ファッション用語そのものに関心がないと知り得ない (服との関心とはまた別物)

    ファッション用語を知らないユーザー ファッション用語を知っているユーザー 色/白？ベージュ？ 素材/ニット モックネック 素材/ニット 色/アイボリー エルボーパッチ ビッグシルエット ※版権の関係上公開時に削除
20. 20.

    © ZOZO Technologies, Inc. ファッションドメインにおける商品検索の難しさ どのように解決するか 20 • テキストに寄らない検索の方法があると良い
 ◦

    1. 欲しい商品が漠然としている
 ◦ 2. ファッション用語が分からない・知らない
 ...その一つの方法として、画像検索 (今回のお話)

21. 21.

    © ZOZO Technologies, Inc. ZOZOTOWN 画像検索 のしくみ
 21 API 特徴量抽出

    近傍探索 商品マスタDB ❺売り切れではない商品の検索 ❷商品画像から商品の位置を検出 ❸商品の特徴量を抽出 ❹検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 物体検出 商品画像とカテゴリなどでクエリ
22. 22.

    © ZOZO Technologies, Inc. 22 使用されているアルゴリズム
 物体検出アルゴリズム • 画像から物体の検出とクラス分類をする 特徴量抽出アルゴリズム

    • 画像から多次元ベクトルの特徴量を抽出する 近似最近傍探索 (ANN) • 高速に多次元のベクトルを探索する https://github.com/spotify/annoy CNN Feature
23. 23.

    © ZOZO Technologies, Inc. 23 ソフトウェアスタック
 サーバアプリケーション • Python/Flask/Gunicorn/Swagger/gRPC •

    Chainer/CuPy (TensorFlow/TPU も検証) インフラ • 推論 API: Google Kubernetes Engine (GKE) + Memorystore (Redis) • Cloud Load Balancer (L7) + Cloud Armor • 学習: Cloud Composer + GKE + Filestore (NFS) • Cloud Storage (GCS) / Container Registry (GCR) • AWS Route53 (ドメイン発行) / Terraform • Datadog / Stackdriver / Sentry Cloud Composer Kubernetes Engine Cloud Memorystore Cloud Filestore Cloud Load Balancing Cloud Armor Cloud Storage Container Registry Stackdriver
24. 24.

    © ZOZO Technologies, Inc. 24 アーキテクチャ全体
 Cloud Load Balancing Cloud

    Armor Kubernetes Engine Cloud Storage Container Registry Cloud Memorystore Developer 画像ストレージ モデルストレージ コンテナイメージ キャッシュ Cloud Composer 学習 Kubernetes Engine ANN index モデル User 学習 推論 GPU Cloud Filestore
25. 25.

    © ZOZO Technologies, Inc. 25 機械学習環境と既存の Web アプリケーションの違い
 • 機械学習には学習と推論という、ライフサイクルも異なる

    2つのプロセスがある ◦ 学習: データ、入力と出力を元にモデルを生成 ◦ 推論: 作成されたモデルをもとに、任意の入力がどの結果に 最もふさわしいかを導く 学習はアプリケーションや要求仕様の特性に応じてバッチなどで 定期的に行い、モデルを継続的に更新する必要がある アプリケーションは、推論 API を使って任意の結果を受け取り、それを処理 することで AI を活用する
26. 26.

    © ZOZO Technologies, Inc. 26 Kubernetes 選定の理由
 • アプリケーション開発環境としてコンテナを使いたい ◦

    社内でも事例は多くなってきており、メリットを享受したかった ▪ ポータビリティ ▪ 開発サイクルの高速化 ▪ 開発 (コンテナ) と運用 (Kubernetes基盤) の責任分界点 • 以下の条件を踏まえると他に選択肢がなかった ◦ 元来よりデータ基盤として GCP を採用 ◦ 推論に GPU が必要 (CPU では遅い or コストに見合わない) ◦ Google App Engine では GPU をアタッチできない
27. 27.

    © ZOZO Technologies, Inc. 27 Kubernetes 内部のアーキテクチャ
 • マイクロサービス ◦

    フロントは HTTP の API ◦ gRPC を使った内部 API 間通信 • ノードプール (Managed 限定の概念) ◦ GPU ワークロード用のプール ◦ 近傍探索用のプールはメモリ多め → ワークロードに応じた インスタンス選定が可能 api 8080 api-pool nns 50051 nns-pool detect 50051 metric 50051 gpu-pool gRPC Cloud Load Balancing (Ingress) https http Cluster IP
28. 28.

    © ZOZO Technologies, Inc. 28 MLOps 改善の歴史


29. 29.

    © ZOZO Technologies, Inc. 29 インフラ当初の状態
 • MLエンジニアが手動で構築した GKE クラスター

    ◦ 平文の HTTP 通信ができる状態の Service Type: LoadBalancer ◦ ほぼ設定が入っていない状態の Deployment • 単一の環境のみが存在 (本番ステージングなどの区分も無し) • コンテナイメージやモデルは手動でデプロイ • 手元で使う IAM ユーザーをそのまま使用 → つまり、とりあえずモノが動くだけの状態があった
30. 30.

    © ZOZO Technologies, Inc. 30 インフラ構成管理ツール導入の機運
 • 以下の問題を解決するために Terraform を導入

    ◦ ML エンジニアが手動で構築した GKE クラスター ▪ Terraform でパラメーターを全部明示 ◦ 単一の環境のみが存在 (本番ステージングなどの区分も無し) ▪ テンプレートの共通化で一元管理 ◦ 手元で使う IAM ユーザーをそのまま使用 ▪ IaC 化 + サービスアカウントに切り替えたので再利用可能に → Terraform の設定として全てコード化したことによって 少なくとも同一の環境を複数建てることが可能になった
31. 31.

    © ZOZO Technologies, Inc. 31 インフラ構成管理ツールの導入におけるポイント
 GCP 上における Web アプリケーションの本番運用の実績が社内になく

    Terraform の知見もほとんどない状態 最初はかっこいい設計はせずモノリシックな単一のファイルで管理し、tfvars と workspace で頑張った (今は違うやり方になっている)
32. 32.

    © ZOZO Technologies, Inc. 32 インフラ構成管理ツールの導入におけるポイント
 インフラ CI/CD を CircleCI

    で自動化 早期からの構成管理自動化によって、手動で管理したとき特有の問題と 作業の属人化を減らす
33. 33.

    © ZOZO Technologies, Inc. 33 インフラ構成管理ツールの導入におけるポイント
 当時の設計思想は CircleCI のミートアップでも発表 Ref:

    https://speakerdeck.com/inductor/circleci-terraform → 妥協はしないが、これを最高の状態ともせず継続的に改善していく
34. 34.

    © ZOZO Technologies, Inc. 34 インフラ構成管理ツール導入時のパイプライン設計


35. 35.

    © ZOZO Technologies, Inc. 35 Kustomize の導入
 • Kubernetes の

    YAML ファイルを環境ごとに用意するのは大変 Deployment Service Ingress HPA ConfigMap Secrets Deployment Service Ingress HPA ConfigMap Secrets Deployment Service Ingress HPA ConfigMap Secrets Production Staging Development
36. 36.

    © ZOZO Technologies, Inc. 36 Kustomize の導入
 • Kustomize を使うと必要な

    YAML だけをオーバーライドできる Deployment ConfigMap Secrets Deployment ConfigMap Secrets Deployment ConfigMap Secrets Production Staging Development Service Ingress Base
37. 37.

    © ZOZO Technologies, Inc. 37 Helm vs. Kustomize
 • Helm

    は変数を使える ◦ インフラ構成管理に限っていえば、変数は黒魔術の根源になりうると判 断し、採用を見送った (Helm 3はTillerもなくなったので) • Kustomize は変数は使えないが、ベースのテンプレートを継承してオー バーライドできる ◦ kubectl が -k オプションにて統合することを踏まえ、採用
38. 38.

    © ZOZO Technologies, Inc. 38 インフラ構成管理ツール導入後の動き
 • 自動化の範囲を定める ◦ 手動が必要なところは開発と運用双方で主体的に議論する

    ▪ そもそもパイプラインを変えられないか ▪ 方針を見直せないか ▪ どこまで妥協が必要か ▪ 将来的に解消できるのか
39. 39.

    © ZOZO Technologies, Inc. 39 インフラ構成管理ツール導入後の動き
 • 常により良い設計を考える ◦ スケールするに従って設計方針も見直す必要があるかもしれない

    ◦ その自動化は本当に長期的に見て良いものなのか ◦ 余計な変更を加えないでも良いつくりを目指す
40. 40.

    © ZOZO Technologies, Inc. 40 インフラ構成管理ツール導入後の動き
 • 使っているツールの新しい機能を定期的にチェックする ◦ 今まで大変だったことが楽になったかも

    ◦ OSSでもマネージドでも、必要な理由を添えてフィードバック ▪ 必要ならPull Requestを送る
41. 41.

    © ZOZO Technologies, Inc. 41 インフラ構成管理ツール導入後の学び
 • 自動化の範囲を定める ◦ 手動が必要なところはそもそもパイプラインを変えられないか、

    方針を見直せないか、開発運用が一体となって議論する ◦ 常により良い設計を考える ◦ 余計な変更を加えないでも良いつくりを目指す • 使っているツールの新しい機能を定期的にチェックする → Kubernetes リソースと Terraform の Apply 両方を誰がやっても 同じように確認、適用できるパイプラインができた
42. 42.

    © ZOZO Technologies, Inc. 42 構成管理自動化後にわかった、更新時の瞬断
 • インフラ構成を自動化出来るようになったことで、アプリケーションデプロイ の頻度が大幅に高まった ◦

    頻繁にアプリケーションが瞬断していることに気づく → ローリングアップデートの設定が適切に入っていなかった • Deployment リソースに Readiness probe と Liveness probe を導入
43. 43.

    © ZOZO Technologies, Inc. • インフラ構成を自動化出来るようになったことで、アプリケーションデプロイ の頻度が大幅に高まった ◦ 頻繁にアプリケーションが瞬断していることに気づく →

    ローリングアップデートの設定が適切に入っていなかった • Deployment リソースに Readiness probe と Liveness probe を導入 43 構成管理自動化後にわかった、更新時の瞬断
 まだ瞬断する！
44. 44.

    © ZOZO Technologies, Inc. 44 構成管理自動化後にわかった、更新時の瞬断
 • アプリケーション側で Graceful Shutdown

    の対応が入っていなかった ◦ The 12-Factor Apps にも定義されている、アプリケーションの破棄容易性を高 めるために必要な機能 ◦ これがあると、アプリケーションは必ず受けたトラフィックを捌き切ってからプロセ スを殺す • アプリを改修しなくても Python (gunicorn) に対して入れたら改善された
45. 45.

    © ZOZO Technologies, Inc. 45 構成管理自動化後にわかった、更新時の瞬断
 • アプリケーション側で Graceful Shutdown

    の対応が入っていなかった ◦ The 12-Factor Apps にも定義されている、アプリケーションの破棄容易性を高 めるために必要な機能 ◦ これがあると、アプリケーションは必ず受けたトラフィックを捌き切ってからプロセ スを殺す • アプリを改修しなくても Python (gunicorn) に対して入れたら改善された
46. 46.

    © ZOZO Technologies, Inc. 46 本番リリース前に担保しておきたいセキュリティ要件
 • リリース前までは API にアクセス制御を掛けたい

    ◦ GCP 上の Type: LoadBalancer では TLS 終端と IP 制限が難しい ◦ GKE では Ingress に対して Cloud Armor という GCP 上の サービスを紐付けることが出来る ▪ Cloud Armor 自体は FW 的な役割を様々担う予定だが、2019年4 月時点では IP制限機能のみ提供
47. 47.

    © ZOZO Technologies, Inc. 47 本番リリース前に担保しておきたいセキュリティ要件
 Ingress + CertManager +

    BackendConfig (Cloud Armor) を採用した ついでに TLS 終端もできるようになった → このへんは各社クラウドによって出来ることが異なるので注意
48. 48.

    © ZOZO Technologies, Inc. 48 参考情報: Kubernetes における Ingress と

    Service の違い
 • Service Type: LoadBalancer には基本的には L4 ロードバランサの実装が 組み込まれている • Service は Node が持つ外部からアクセス可能なネットワークと、Pod の論 理的な内部ネットワークを繋ぐ
49. 49.

    © ZOZO Technologies, Inc. 49 参考情報: Kubernetes における Ingress と

    Service の違い
 • Ingress は基本的には L7 ロードバランサの実装が組み込まれている • Ingress はパスベースのルーティングができる ◦ 同じ Static IP で複数の Service にトラフィックを振り分けられる ◦ Service をどのみち経由するため、内部の経路が複雑かつ多い 次ページで簡易化した論理的なつながりの図を解説します
50. 50.

    © ZOZO Technologies, Inc. ※簡易的 & 論理的な図なので実際の構成とは違います
 50 Pod A

    Pod B Pod C Pod A Pod C Pod D Pod B Pod C Pod D Node 1 Node 2 Node 3 Node Network Pod Network VM/Baremetal NIC VM/Baremetal NIC VM/Baremetal NIC Container NIC Container NIC Container NIC Container NIC Container NIC Container NIC Container NIC Container NIC Container NIC
51. 51.

    © ZOZO Technologies, Inc. 51 Pod A Pod B Pod

    C Pod A Pod C Pod D Pod B Pod C Pod D Node 1 Node 2 Node 3 Node Network Pod Network Service A Service C Ingress for Service A & C Static IP パブリッククラウドでは L7ロードバラン サで実装されていることが多い パブリッククラウドでは L4ロードバラン サで実装されていることが多い ※簡易的 & 論理的な図なので実際の構成とは違います
 Service D (ClusterIP)
52. 52.

    © ZOZO Technologies, Inc. 52 Service Type: LoadBalancer と Ingress

    の実態はどこ？
 • どちらも、Kubernetes のコンポーネントである「コントローラー」が クラウドプロバイダー上のロードバランサーを制御している • Service の場合は、Cloud Controller Manager が Service Controller を使って Service リソースの管理 + L4ロードバランサーの作成や削除などを行う ◦ Ref: https://github.com/kubernetes?utf8=%E2%9C%93&q=cloud-provider • Ingress の場合は、Ingress Controller が Ingress リソースと各種プロバイダー内部 実装との橋渡し (L7ロードバランサーの作成や削除) を行う ◦ e.g. ingress-nginx, ingress-gce, aws-alb-ingress-controller など
53. 53.

    © ZOZO Technologies, Inc. 53 Service Type: LoadBalancer と Ingress

    の実態はどこ？
 • どちらも、Kubernetes のコンポーネントである「コントローラー」が クラウドプロバイダー上のロードバランサーを制御している • Service の場合は、Cloud Controller Manager が Service Controller を使って Service リソースの管理 + L4ロードバランサーの作成や削除などを行う ◦ Ref: https://github.com/kubernetes?utf8=%E2%9C%93&q=cloud-provider • Ingress の場合は、Ingress Controller が Ingress リソースと各種プロバイダー内部 実装との橋渡し (L7ロードバランサーの作成や削除) を行う ◦ e.g. ingress-nginx, ingress-gce, aws-alb-ingress-controller など つまり、実装はクラウドプロバイダーに依存
54. 54.

    © ZOZO Technologies, Inc. 54 サービスディスカバリの問題
 gRPC の通信が適切にロードバランスされない • gRPC

    は HTTP/2ベースの実装のため、TCP の接続が永続化される ◦ ClusterIP に直接通信すると、ロードバランシングできない • 当初、gRPC を制御するサービスプロキシに Envoy を採用 ◦ NW が複雑化してしまい、かえってトラブルシューティングが大変になった ◦ サービスの規模もまだ小さいため、今回 Envoy の導入は見送り DNSPolicy の設定なども見直しが必要？知見と時間が足りず断念
55. 55.

    © ZOZO Technologies, Inc. 55 サービスディスカバリの問題
 gRPC の通信が適切にロードバランスされない • GKE

    上の kube-proxy が不安定なのも相まって、結局アプリ上にgRPC クライアントを導入 ◦ Kubernetes の Headless Service を使った、名前解決のラウンドロビンと gRPC 接続を張る処理を自前で実装 詳細はチームリーダー 瀬尾の Google Cloud Next ’19 in Tokyo 登壇資料に！
56. 56.

    © ZOZO Technologies, Inc. 56 サービスディスカバリの問題
 gRPC の通信が適切にロードバランスされない • GKE

    上の kube-proxy が不安定なのも相まって、結局アプリ上にgRPC クライアントを導入 ◦ Kubernetes の Headless Service を使った、名前解決のラウンドロビンと gRPC 接続を張る処理を自前で実装 詳細はチームリーダー 瀬尾の Google Cloud Next ’19 in Tokyo 登壇資料に！ サービスプロキシを入れる規模ではないので クライアント実装で解決した
57. 57.

    © ZOZO Technologies, Inc. 57 GPU インスタンスが全然スケールしない
 • API の内部で行われている推論に

    GPU が必要 ◦ GPU がコンテキストスイッチに弱く、複数リクエストを捌けない • GPU を使うためクラスターで nvidia-driver-installer の初期化処理が走る ▪ 初期化が終わるまで Pod をノードに割り当てることができない • コンテナイメージの pull に時間がかかる
58. 58.

    © ZOZO Technologies, Inc. 58 GPU インスタンスが全然スケールしない
 • API の内部で行われている推論に

    GPU が必要 ◦ GPU がコンテキストスイッチに弱く、複数リクエストを捌けない • GPU を使うためクラスターで nvidia-driver-installer の初期化処理が走る ▪ 初期化が終わるまで Pod をノードに割り当てることができない • コンテナイメージの pull に時間がかかる スケールアウトが遅いためリクエストに対して余裕を持っ てGPU インスタンスを立てておく必要がある
59. 59.

    © ZOZO Technologies, Inc. 59 GPU 問題の解決策を探る
 API から物体検出及び特徴量抽出の推論を行わないようにすればよい •

    GPU インスタンスを無くすことによる運用コストの削減 • 推論自体のレスポンスタイム改善 • 急激なトラフィックの増加に対応
60. 60.

    © ZOZO Technologies, Inc. 60 GPU 問題の解決策を探る
 API から物体検出及び特徴量抽出の推論を行わないようにすればよい •

    GPU インスタンスを無くすことによる運用コストの削減 • 推論自体のレスポンスタイム改善 • 急激なトラフィックの増加に対応 Goodbye GPU!
61. 61.

    © ZOZO Technologies, Inc. 現状の画像検索 API の詳解&おさらい
 
 61 API

    特徴量抽出 近傍探索 商品マスタDB ❺売り切れではない商品の検索 ❷商品画像から商品の位置を検出 ❸商品の特徴量を抽出 ❹検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 物体検出 商品画像とカテゴリなどでクエリ
62. 62.

    © ZOZO Technologies, Inc. 62 API 特徴量抽出 近傍探索 商品マスタDB ❺売り切れではない商品の検索

    ❷商品画像から商品の位置を検出 ❸商品の特徴量を抽出 ❹検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 物体検出 問題となっている部分 現状の画像検索 API の詳解&おさらい
 
 商品画像とカテゴリなどでクエリ
63. 63.

    © ZOZO Technologies, Inc. 推論を行わないようにするには ZOZOTOWN では毎日新商品が出るため、日次のワークフローで 新商品の特徴量を計算して近似最近傍探索のインデックスを再構築している 63 日次のワークフローで計算する特徴量をキャッシュし、それを

    API で再利用する
64. 64.

    © ZOZO Technologies, Inc. 64 画像検索プラットフォームのワークフロー モデルの学習（手動） • アイテム検出器の学習 /

    メトリックラーニング • 画像を集めてリサーチャーが手動で実行 • 更新頻度: 3 ヶ月〜 • ref. Google が開発した AI プロセッサ『Cloud TPU』と ZOZOTOWN での 活用事例 https://www.youtube.com/watch?v=jJ0zoTPBBho ANN Index の再構築（Composer を利用） • ZOZOTOWN に新たに出品された商品画像を集める • 特徴量抽出 ＆ ANN Index 再構築 • 更新頻度: 日時（将来の展望: イベント駆動） Cloud Storage Developer 画像ストレージ モデルストレージ 学習 Kubernetes Engine ANN index モデル GPU BigQuery ZOZO の既存システム Cloud Filestore Cloud Composer ZOZOTOWN 画像 サーバー
65. 65.

    © ZOZO Technologies, Inc. 65 現状の検索インデックスの再作成
 BigQuery 1. BigQuery テーブル

    のバックアップ （前日差分計算用） 2. 新規商品の一覧化 4. 新規商品の特徴量 を抽出 3. 新規商品画像の ダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ （キャッシュ） BigQuery ZOZOTOWN ZOZOTOWN 画像 サーバー Cloud Filestore 別 GKE（GPU） BigQuery
66. 66.

    © ZOZO Technologies, Inc. 66 現状の検索インデックスの再作成
 BigQuery 1. BigQuery テーブル

    のバックアップ （前日差分計算用） 2. 新規商品の一覧化 4. 新規商品の特徴量 を抽出 3. 新規商品画像の ダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ （キャッシュ） BigQuery ZOZOTOWN ZOZOTOWN 画像 サーバー Cloud Filestore 別 GKE（GPU） BigQuery ここに手を入れる
67. 67.

    © ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(Step1)
 BigQuery 1. BigQuery テーブルの バックアップ

    (前日差分計算用) 2. 新規商品の 一覧化 4.b 新規商品の 特徴量を抽出 3. 新規商品画像 のダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ （キャッシュ） BigQuery ZOZOTOWN Cloud Filestore BigQuery 4.a 新規商品の 位置を検出 Pub/Sub ZOZOTOWN 画像 サーバー
68. 68.

    © ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(Step1)
 BigQuery 1. BigQuery テーブルの バックアップ

    (前日差分計算用) 2. 新規商品の 一覧化 4.b 新規商品の 特徴量を抽出 3. 新規商品画像 のダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ （キャッシュ） BigQuery ZOZOTOWN Cloud Filestore BigQuery 4.a 新規商品の 位置を検出 Pub/Sub ZOZOTOWN 画像 サーバー Detectionを追加
69. 69.

    © ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(Step2)
 4.b 新規商品の 特徴量を抽出 5. 全商品のANN

    index 再構築 7. デプロイ Cloud Storage モデル・Index ストレージ BigQuery Pub/Sub Memorystore 6. 商品URLを キーに商品の特 徴量をredisへと 格納する
70. 70.

    © ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(Step2)
 4.b 新規商品の 特徴量を抽出 5. 全商品のANN

    index 再構築 7. デプロイ Cloud Storage モデル・Index ストレージ BigQuery Pub/Sub Memorystore 6. 商品URLを キーに商品の特 徴量をredisへと 格納する 生成した情報をRedisに格納
71. 71.

    © ZOZO Technologies, Inc. 71 API 近傍探索 商品マスタDB ❹売り切れではない商品の検索 ❸検出された商品と近い商品情報を取得

    キャッシュDB ❶キャッシュが存在すれば返す 特徴量DB ❷商品の特徴量を返す 商品画像とカテゴリなどでクエリ 改修後の画像検索API
 さっきのRedis
72. 72.

    © ZOZO Technologies, Inc. 72 良さそう API 近傍探索 商品マスタDB ❹売り切れではない商品の検索

    ❸検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 特徴量DB ❷商品の特徴量を返す 商品画像とカテゴリなどでクエリ 改修後の画像検索API

73. 73.

    © ZOZO Technologies, Inc. 73 • 画像検索を ZOZOTOWN の1機能としてではなく、1マイクロサービスとして 様々なシーンで展開し「社内全体における画像検索プラットフォーム」に拡大する

    • 運用をはじめて、ワークフロー設計にもいくつか課題があることがわかってきた ◦ ワークフローエンジンの見直し ◦ Kubeflow が 0.7.0 まで成長してきたので、そろそろ手を出してもよさそう？ • Kubernetes 本番運用の実践例として社内にノウハウを展開していく 今後の展望

74. 74.

    © ZOZO Technologies, Inc. 74 • ZOZOTOWN の画像検索チームは、地理的に離れたエンジニアたちが、一体となって 極力内部のリソースだけでプロジェクトを回している •

    必要な自動化、抽象化、共通化を見極めて常に改善を続けている • 新規プロジェクトだからこそ、新しめの技術を使いつつ、短いサイクルで ML パイプラインを含むアプリケーション全体を継続的に改善できている • マイクロサービスとして、国内最大級を誇る大きなアプリケーションの新機能を提供 まとめ

75. 75.

    None