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

Transcript

1. ZOZOTOWN の画像検索機能にみる

   Kubernetes を使った機械学習基盤運用の裏側

   CloudNative Days Kansai 2019

   2019/11/28

   Copyright © ZOZO Technologies, Inc.
   株式会社ZOZOテクノロジーズ

   開発部 MLOpsチーム

   太田 航平

   

   View Slide

2. © ZOZO Technologies, Inc.
   株式会社ZOZOテクノロジーズ

   開発部

   MLOpsチーム エンジニア
   太田 航平

   2018年4月にスタートトゥデイテクノロジーズ(現ZOZOテクノロジーズ)
   に入社。

   開発部のPBチームにてAWSを中心に海外向け自社ECのインフラ開
   発や運用などを担当後、SREとして各所のインフラに従事。

   2019年6月より、MLOpsチームに配属となり、主にGCPを使った機械
   学習基盤の設計構築や運用などを行っている。

   2
   

   View Slide

3. © ZOZO Technologies, Inc.
   https://zozo.jp/

   ● 日本最大級のファッション通販サイト

   ● 1,200以上のショップ、7,300以上のブランドの取り扱い（ともに2019年6
   月末時点）

   ● 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商
   品を掲載

   ● 即日配送サービス

   ● ギフトラッピングサービス

   ● ツケ払い など

   3
   

   View Slide

4. © ZOZO Technologies, Inc.
   https://wear.jp/

   ● 日本最大級のファッションコーディネートアプリ

   ● 1,300万ダウンロード突破、コーディネート投稿総数は900万件以上（と
   もに2019年9月末時点）

   ● 全世界（App Store / Google Playが利用可能な全ての国）でダウンロー
   ドが可能

   ● 200万人以上のフォロワーを持つユーザー（WEARISTA）も誕生

   4
   

   View Slide

5. © ZOZO Technologies, Inc.
   https://zozo.jp/multisize/

   

   ● 身長と体重を選択するだけで理想のサイズの商品が見つかる新しい洋
   服の買い方

   ● ZOZOSUITで得た100万件以上の体型データを活用し、20～50サイズ
   のマルチサイズ（多サイズ）に展開

   ● 2019年秋冬アイテムから、人気ブランドのマルチサイズアイテムを販売
   開始

   【参加企業】

   　株式会社アーバンリサーチ、株式会社ストライプインターナショナル、

   　株式会社デイトナ・インターナショナル、株式会社パル、株式会社ビームス、

   　株式会社ベイクルーズ、MARK STYLER株式会社、リーバイ・ストラウス ジャパン株式会社　　など

   5
   

   View Slide

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

   ● 画像検索プラットフォームの構成

   ● Kubernetes 選定の理由と内部の構成

   ● 本番稼働までに抱えた課題とその解決策

   アジェンダ

   6
   

   View Slide

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

   

   View Slide

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

   

   View Slide

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

   

   View Slide

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

    

    View Slide

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

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

    View Slide

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

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

    View Slide

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

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

    View Slide

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

    

    View Slide

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

    ● カテゴリ・カラー・性別などで絞り込み

    15
    テキストベースの検索
    カラーやカテゴリなどから絞り込み
    

    View Slide

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

    ○ ユーザーは大抵特定の商品 (例えば、わかりやすい固有名詞が付いているよう
    なロボット掃除機・ゲーム用端末など具体的な何か) が欲しい訳ではない

    ○ 一方で、コモディティ化が進み切ってるかというとそうでもない

    ● 2. ファッション用語が分からない・知らない

    ○ そもそもファッション用語に明確な定義がない場合もある

    

    View Slide

17. © ZOZO Technologies, Inc.
    ファッションドメインにおける商品検索の難しさ
    1. 欲しい商品が漠然としている
    17
    よく知られた固有名がついていない / コモディティ化しきってるわけでもない
    欲しいものの固有名詞で探せる 大きな分類で探せばどれでもいい ※版権の関係上公開時に削除
    ？
    

    View Slide

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

    View Slide

19. © ZOZO Technologies, Inc.
    ファッションドメインにおける商品検索の難しさ
    2. ファッション用語が分からない・知らない
    19
    ファッション用語そのものに関心がないと知り得ない (服との関心とはまた別物)
    ファッション用語を知らないユーザー ファッション用語を知っているユーザー
    色/白？ベージュ？
    素材/ニット
    モックネック
    素材/ニット
    色/アイボリー
    エルボーパッチ
    ビッグシルエット
    ※版権の関係上公開時に削除
    

    View Slide

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

    ○ 1. 欲しい商品が漠然としている

    ○ 2. ファッション用語が分からない・知らない

    ...その一つの方法として、画像検索 (今回のお話)

    

    View Slide

21. © ZOZO Technologies, Inc.
    ZOZOTOWN 画像検索 のしくみ

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

    View Slide

22. © ZOZO Technologies, Inc.
    22
    使用されているアルゴリズム

    物体検出アルゴリズム
    ● 画像から物体の検出とクラス分類をする
    特徴量抽出アルゴリズム
    ● 画像から多次元ベクトルの特徴量を抽出する
    近似最近傍探索 (ANN)
    ● 高速に多次元のベクトルを探索する
    https://github.com/spotify/annoy
    CNN Feature
    

    View Slide

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
    

    View Slide

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
    

    View Slide

25. © ZOZO Technologies, Inc.
    25
    機械学習環境と既存の Web アプリケーションの違い

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

    View Slide

26. © ZOZO Technologies, Inc.
    26
    Kubernetes 選定の理由

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

    View Slide

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
    

    View Slide

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

    

    View Slide

29. © ZOZO Technologies, Inc.
    29
    インフラ当初の状態

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

    View Slide

30. © ZOZO Technologies, Inc.
    30
    インフラ構成管理ツール導入の機運

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

    View Slide

31. © ZOZO Technologies, Inc.
    31
    インフラ構成管理ツールの導入におけるポイント

    GCP 上における Web アプリケーションの本番運用の実績が社内になく
    Terraform の知見もほとんどない状態
    最初はかっこいい設計はせずモノリシックな単一のファイルで管理し、tfvars と
    workspace で頑張った (今は違うやり方になっている)
    

    View Slide

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

    インフラ CI/CD を CircleCI で自動化
    早期からの構成管理自動化によって、手動で管理したとき特有の問題と
    作業の属人化を減らす
    

    View Slide

33. © ZOZO Technologies, Inc.
    33
    インフラ構成管理ツールの導入におけるポイント

    当時の設計思想は CircleCI のミートアップでも発表
    Ref: https://speakerdeck.com/inductor/circleci-terraform
    → 妥協はしないが、これを最高の状態ともせず継続的に改善していく
    

    View Slide

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

    

    View Slide

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
    

    View Slide

36. © ZOZO Technologies, Inc.
    36
    Kustomize の導入

    ● Kustomize を使うと必要な YAML だけをオーバーライドできる
    Deployment
    ConfigMap
    Secrets
    Deployment
    ConfigMap
    Secrets
    Deployment
    ConfigMap
    Secrets
    Production Staging Development
    Service
    Ingress
    Base
    

    View Slide

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

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

    View Slide

38. © ZOZO Technologies, Inc.
    38
    インフラ構成管理ツール導入後の動き

    ● 自動化の範囲を定める
    ○ 手動が必要なところは開発と運用双方で主体的に議論する
    ■ そもそもパイプラインを変えられないか
    ■ 方針を見直せないか
    ■ どこまで妥協が必要か
    ■ 将来的に解消できるのか
    

    View Slide

39. © ZOZO Technologies, Inc.
    39
    インフラ構成管理ツール導入後の動き

    ● 常により良い設計を考える
    ○ スケールするに従って設計方針も見直す必要があるかもしれない
    ○ その自動化は本当に長期的に見て良いものなのか
    ○ 余計な変更を加えないでも良いつくりを目指す
    

    View Slide

40. © ZOZO Technologies, Inc.
    40
    インフラ構成管理ツール導入後の動き

    ● 使っているツールの新しい機能を定期的にチェックする
    ○ 今まで大変だったことが楽になったかも
    ○ OSSでもマネージドでも、必要な理由を添えてフィードバック
    ■ 必要ならPull Requestを送る
    

    View Slide

41. © ZOZO Technologies, Inc.
    41
    インフラ構成管理ツール導入後の学び

    ● 自動化の範囲を定める
    ○ 手動が必要なところはそもそもパイプラインを変えられないか、
    方針を見直せないか、開発運用が一体となって議論する
    ○ 常により良い設計を考える
    ○ 余計な変更を加えないでも良いつくりを目指す
    ● 使っているツールの新しい機能を定期的にチェックする
    → Kubernetes リソースと Terraform の Apply 両方を誰がやっても
    同じように確認、適用できるパイプラインができた
    

    View Slide

42. © ZOZO Technologies, Inc.
    42
    構成管理自動化後にわかった、更新時の瞬断

    ● インフラ構成を自動化出来るようになったことで、アプリケーションデプロイ
    の頻度が大幅に高まった
    ○ 頻繁にアプリケーションが瞬断していることに気づく
    → ローリングアップデートの設定が適切に入っていなかった
    ● Deployment リソースに Readiness probe と Liveness probe を導入
    

    View Slide

43. © ZOZO Technologies, Inc.
    ● インフラ構成を自動化出来るようになったことで、アプリケーションデプロイ
    の頻度が大幅に高まった
    ○ 頻繁にアプリケーションが瞬断していることに気づく
    → ローリングアップデートの設定が適切に入っていなかった
    ● Deployment リソースに Readiness probe と Liveness probe を導入
    43
    構成管理自動化後にわかった、更新時の瞬断

    まだ瞬断する！
    

    View Slide

44. © ZOZO Technologies, Inc.
    44
    構成管理自動化後にわかった、更新時の瞬断

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

    View Slide

45. © ZOZO Technologies, Inc.
    45
    構成管理自動化後にわかった、更新時の瞬断

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

    View Slide

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

    ● リリース前までは API にアクセス制御を掛けたい
    ○ GCP 上の Type: LoadBalancer では TLS 終端と IP 制限が難しい
    ○ GKE では Ingress に対して Cloud Armor という GCP 上の
    サービスを紐付けることが出来る
    ■ Cloud Armor 自体は FW 的な役割を様々担う予定だが、2019年4
    月時点では IP制限機能のみ提供
    

    View Slide

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

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

    View Slide

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

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

    View Slide

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

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

    View Slide

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
    

    View Slide

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)
    

    View Slide

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 など
    

    View Slide

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 など
    つまり、実装はクラウドプロバイダーに依存
    

    View Slide

54. © ZOZO Technologies, Inc.
    54
    サービスディスカバリの問題

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

    View Slide

55. © ZOZO Technologies, Inc.
    55
    サービスディスカバリの問題

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

    View Slide

56. © ZOZO Technologies, Inc.
    56
    サービスディスカバリの問題

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

    View Slide

57. © ZOZO Technologies, Inc.
    57
    GPU インスタンスが全然スケールしない

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

    View Slide

58. © ZOZO Technologies, Inc.
    58
    GPU インスタンスが全然スケールしない

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

    View Slide

59. © ZOZO Technologies, Inc.
    59
    GPU 問題の解決策を探る

    API から物体検出及び特徴量抽出の推論を行わないようにすればよい
    ● GPU インスタンスを無くすことによる運用コストの削減
    ● 推論自体のレスポンスタイム改善
    ● 急激なトラフィックの増加に対応
    

    View Slide

60. © ZOZO Technologies, Inc.
    60
    GPU 問題の解決策を探る

    API から物体検出及び特徴量抽出の推論を行わないようにすればよい
    ● GPU インスタンスを無くすことによる運用コストの削減
    ● 推論自体のレスポンスタイム改善
    ● 急激なトラフィックの増加に対応
    Goodbye GPU!
    

    View Slide

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

    

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

    View Slide

62. © ZOZO Technologies, Inc.
    62
    API 特徴量抽出
    近傍探索
    商品マスタDB
    ❺売り切れではない商品の検索
    ❷商品画像から商品の位置を検出
    ❸商品の特徴量を抽出
    ❹検出された商品と近い商品情報を取得
    キャッシュDB
    ❶キャッシュが存在すれば返す
    物体検出
    問題となっている部分
    現状の画像検索 API の詳解&おさらい

    

    商品画像とカテゴリなどでクエリ
    

    View Slide

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

    View Slide

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
    画像
    サーバー
    

    View Slide

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
    

    View Slide

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
    ここに手を入れる
    

    View Slide

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
    画像
    サーバー
    

    View Slide

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を追加
    

    View Slide

69. © ZOZO Technologies, Inc.
    検索インデックスの作成ワークフローを改修する(Step2)

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

    View Slide

70. © ZOZO Technologies, Inc.
    検索インデックスの作成ワークフローを改修する(Step2)

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

    View Slide

71. © ZOZO Technologies, Inc.
    71
    API
    近傍探索
    商品マスタDB
    ❹売り切れではない商品の検索 ❸検出された商品と近い商品情報を取得
    キャッシュDB
    ❶キャッシュが存在すれば返す
    特徴量DB
    ❷商品の特徴量を返す
    商品画像とカテゴリなどでクエリ
    改修後の画像検索API

    さっきのRedis
    

    View Slide

72. © ZOZO Technologies, Inc.
    72
    良さそう
    API
    近傍探索
    商品マスタDB
    ❹売り切れではない商品の検索 ❸検出された商品と近い商品情報を取得
    キャッシュDB
    ❶キャッシュが存在すれば返す
    特徴量DB
    ❷商品の特徴量を返す
    商品画像とカテゴリなどでクエリ
    改修後の画像検索API

    

    View Slide

73. © ZOZO Technologies, Inc.
    73
    ● 画像検索を ZOZOTOWN の1機能としてではなく、1マイクロサービスとして
    様々なシーンで展開し「社内全体における画像検索プラットフォーム」に拡大する
    ● 運用をはじめて、ワークフロー設計にもいくつか課題があることがわかってきた
    ○ ワークフローエンジンの見直し
    ○ Kubeflow が 0.7.0 まで成長してきたので、そろそろ手を出してもよさそう？
    ● Kubernetes 本番運用の実践例として社内にノウハウを展開していく
    今後の展望

    

    View Slide

74. © ZOZO Technologies, Inc.
    74
    ● ZOZOTOWN の画像検索チームは、地理的に離れたエンジニアたちが、一体となって
    極力内部のリソースだけでプロジェクトを回している
    ● 必要な自動化、抽象化、共通化を見極めて常に改善を続けている
    ● 新規プロジェクトだからこそ、新しめの技術を使いつつ、短いサイクルで
    ML パイプラインを含むアプリケーション全体を継続的に改善できている
    ● マイクロサービスとして、国内最大級を誇る大きなアプリケーションの新機能を提供
    まとめ

    

    View Slide

75. View Slide