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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© ZOZO Technologies, Inc. https://wear.jp/  ● 日本最大級のファッションコーディネートアプリ  ● 1,300万ダウンロード突破、コーディネート投稿総数は900万件以上（ともに2019年9月末時点）  ● 全世界（App Store / Google Playが利用可能な全ての国）でダウンロードが可能  ● 200万人以上のフォロワーを持つユーザー（WEARISTA）も誕生  4

Slide 5

Slide 5 text

© ZOZO Technologies, Inc. https://zozo.jp/multisize/    ● 身長と体重を選択するだけで理想のサイズの商品が見つかる新しい洋服の買い方  ● ZOZOSUITで得た100万件以上の体型データを活用し、20～50サイズのマルチサイズ（多サイズ）に展開  ● 2019年秋冬アイテムから、人気ブランドのマルチサイズアイテムを販売開始  【参加企業】  　株式会社アーバンリサーチ、株式会社ストライプインターナショナル、  　株式会社デイトナ・インターナショナル、株式会社パル、株式会社ビームス、  　株式会社ベイクルーズ、MARK STYLER株式会社、リーバイ・ストラウスジャパン株式会社　　など  5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 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

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© 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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 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

Slide 36

Slide 36 text

© ZOZO Technologies, Inc. 36 Kustomize の導入  ● Kustomize を使うと必要な YAML だけをオーバーライドできる Deployment ConfigMap Secrets Deployment ConfigMap Secrets Deployment ConfigMap Secrets Production Staging Development Service Ingress Base

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

© ZOZO Technologies, Inc. 44 構成管理自動化後にわかった、更新時の瞬断  ● アプリケーション側で Graceful Shutdown の対応が入っていなかった ○ The 12-Factor Apps にも定義されている、アプリケーションの破棄容易性を高めるために必要な機能 ○ これがあると、アプリケーションは必ず受けたトラフィックを捌き切ってからプロセスを殺す ● アプリを改修しなくても Python (gunicorn) に対して入れたら改善された

Slide 45

Slide 45 text

© ZOZO Technologies, Inc. 45 構成管理自動化後にわかった、更新時の瞬断  ● アプリケーション側で Graceful Shutdown の対応が入っていなかった ○ The 12-Factor Apps にも定義されている、アプリケーションの破棄容易性を高めるために必要な機能 ○ これがあると、アプリケーションは必ず受けたトラフィックを捌き切ってからプロセスを殺す ● アプリを改修しなくても Python (gunicorn) に対して入れたら改善された

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

© 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

Slide 51

Slide 51 text

© 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)

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

© 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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

No content