Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
ZOZOTOWNにおける画像検索の 運用・改善について 株式会社ZOZOテクノロジーズ MLOpsチーム 平田 拓也 Copyright © ZOZO Technologies, Inc.
Slide 2
Slide 2 text
© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ MLOps 平田 拓也 2018年入社。データ基盤チームでETLツールのリプレイスを 行なった後に、MLOpsチームで画像検索プラットフォームや WEARのレコメンデーション機能の開発・インフラ構築を行 なっている。Elixirとブロッコリーが好き。 2
Slide 3
Slide 3 text
© ZOZO Technologies, Inc. 目次 ● 画像検索プラットフォームの構成 ● アプリケーションのCI/CD及び監視 ● 画像検索改善のためにやっていること ● ワークローエンジンとしてのCloud Composerの運用改善 ● まとめ 3
Slide 4
Slide 4 text
© ZOZO Technologies, Inc. https://zozo.jp/ ● 日本最大級のファッション通販サイト ● 1,200以上のショップ、7,300以上のブランドの取り扱い(ともに2019年6 月末時点) ● 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払い など 4
Slide 5
Slide 5 text
© ZOZO Technologies, Inc. 5 ● 画像からアイテムを検出 ● ZOZOTOWNで販売されている類似ア イテムを表示する ZOZO 画像検索とは
Slide 6
Slide 6 text
© ZOZO Technologies, Inc. https://wear.jp/ ● 日本最大級のファッションコーディネートアプリ ● 1,300万ダウンロード突破、コーディネート投稿総数は900万件以上(と もに2019年9月末時点) ● 全世界(App Store / Google Playが利用可能な全ての国)でダウンロー ドが可能 ● 200万人以上のフォロワーを持つユーザー(WEARISTA)も誕生 6
Slide 7
Slide 7 text
© ZOZO Technologies, Inc. https://zozo.jp/multisize/ ● 身長と体重を選択するだけで理想のサイズの商品が見つかる新しい洋 服の買い方 ● ZOZOSUITで得た100万件以上の体型データを活用し、20~50サイズ のマルチサイズ(多サイズ)に展開 ● 2019年秋冬アイテムから、人気ブランドのマルチサイズアイテムを販売 開始 【参加企業】 株式会社アーバンリサーチ、株式会社ストライプインターナショナル、 株式会社デイトナ・インターナショナル、株式会社パル、株式会社ビームス、 株式会社ベイクルーズ、MARK STYLER株式会社、リーバイ・ストラウス ジャパン株式会社 など 7
Slide 8
Slide 8 text
© ZOZO Technologies, Inc. 8 画像検索プラットフォームの構成
Slide 9
Slide 9 text
© ZOZO Technologies, Inc. 9 画像検索プラットフォームのチーム構成 青山研究所 ● 機械学習の基礎研究 福岡研究所 ● 機械学習を用いたプロトタイプの開発 iOS, Android, ZOZO Web ● 画像検索APIを叩いて、ユーザーに結果を表示する部分の開発 MLOps ● 機械学習基盤周りの担当
Slide 10
Slide 10 text
© ZOZO Technologies, Inc. 10 ZOZOにおけるMLOpsチームのミッション ● MLエンジニアや研究者が機械学習モデルの開発に集中できる環境を提供する ● プロトタイプをプロダクションレベルに引き上げる
Slide 11
Slide 11 text
© ZOZO Technologies, Inc. 11 使用されているアルゴリズム 物体検出アルゴリズム ● 画像から物体の検出とクラス分類をする 特徴量抽出アルゴリズム ● 画像から多次元ベクトルの特徴量を抽出する 近似再最近傍探索(ANN) ● 高速に多次元のベクトルを探索する https://github.com/spotify/annoy CNN Feature
Slide 12
Slide 12 text
ソフトウェアスタック サーバアプリケーション ● Python/Flask/Gunicorn/Swagger/gRPC ● Chainer/CuPy(TensorFlow/TPU も検証) インフラ ● 推論 API: Google Kubernetes Engine(GKE)+ Memorystore(Redis) ● Cloud Load Balancer (LB) / 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 13
Slide 13 text
アーキテクチャ全体 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 14
Slide 14 text
なぜGCP? データ基盤 ● 既存のデータ基盤がBigQuery上に構築されている GPUワークロード ● マネージドサービスでGPUを使える環境が必要 ○ GKE, Cloud Run
Slide 15
Slide 15 text
なぜ Kubernetes (GKE)? コンテナを使いたい ● 時代の流れ ● ポータビリティ ● Dev(コンテナ)と Ops(Kubernetes)の責任分界点 GPU を使いたい ● 推論エンジンを使うのに GPU を使わないと遅い ● Google App Engine(GAE)では GPU を使えない ● Cloud Run(on GKE)は技術選定時にはまだ発表されていなかった → 他に選択肢がない
Slide 16
Slide 16 text
API アーキテクチャ on K8s マイクロサービス ● HTTP API フロント ● gRPC バックエンド ノードプール ● GPU を使うプール ● マシンスペック毎のプール api 8080 api-pool nns 50051 nns-pool detect 50051 metric 50051 gpu-pool gRPC Cloud Load Balancing https http
Slide 17
Slide 17 text
K8s上のアプリケーションをプロダクションレベルにするために 行ったこと Google Cloud Next '19 in TokyoにてMLOpsチームリーダーの瀬尾が発表 https://techblog.zozo.com/entry/cloudnext19tokyo-imagesearch
Slide 18
Slide 18 text
© ZOZO Technologies, Inc. 18 アプリケーションのCI/CD及び監視
Slide 19
Slide 19 text
© ZOZO Technologies, Inc. 19 CI/CD CircleCI コンテナイメージのビルド ● アプリリポジトリでイメージをビルド ● Staging & Production で同じイメージを利用 デプロイ ● インフラ リポジトリにモデル/ANN Index/イメージハッシュ の変更を PR ● master ブランチへのマージで Staging に、release ブランチへのマージで Production に terraform & kubectl apply
Slide 20
Slide 20 text
© ZOZO Technologies, Inc. 20 監視項目 テーマ: クラウド時代の監視 ● インスタンスの CPU 使用率についてはオートスケールするので見ない ● システムの健康状態について見る 監視するもの ● レスポンスタイム/ステータスの監視 ● ユーザリクエスト数 / sec(ユーザアクセスが想定より増えていないか) ● APM (Application Performance Monitoring) Kubernetes ならでは ● K8s pod warning log が 30 分以上で続けていないか(設定ミス) ● コンテナのメモリ使用量が limits の 50% を超えていないか
Slide 21
Slide 21 text
© ZOZO Technologies, Inc. 21 監視ソフトウェア Stackdriver + Datadog + Sentry ● GCP は標準で Stackdriver にデータを送ってくれている ● Stackdriver でしか見れないメトリクスもある(Memorystore, etc) ● 方針: Datadog の便利機能だけ Datadog を使う ● Sentry: エラー トラッキング サービス 利用している Datadog の機能 ● Datadog APM(gRPC マイクロサービスにも対応) ● Datadog Synthetics(外形監視) Stackdriver
Slide 22
Slide 22 text
© ZOZO Technologies, Inc. 22 Stackdriverで見ているメトリクス ● K8S Pod Warning Log ● Memorystoreメモリ使用率 ● Filestoreの使用率 ● Cloud NAT Droppedパケット ● GCLBのHTTPステータス ● GCLBのreq/sec Stackdriver
Slide 23
Slide 23 text
© ZOZO Technologies, Inc. 23 K8S Pod Warning Log Stacdriver Loggingを用いて、Warningログを監視 ● 変更適用時にバリデーションが走らず、 間違えた設定を反映させるとWarningログが出続ける挙動をする ● 毎分1件以上のWarningが30分で続けたら通知 Stackdriver
Slide 24
Slide 24 text
© ZOZO Technologies, Inc. 24 Cloud NAT Droppedパケット 経緯 デフォルトのNATの設定だと、1VMに対して64ポート割り振っている(64,000 port/1 public ip) Stackdriver 画像データ収集の際に64ポート以上使用してしまい、実行時間が大幅に伸びた NATに複数Public IPを割り当て、ポートの制限を緩めた
Slide 25
Slide 25 text
© ZOZO Technologies, Inc. 25 画像検索改善のためにやっていること
Slide 26
Slide 26 text
© ZOZO Technologies, Inc. 26 現状の課題 ● レイテンシが大きい ● 急激なトラフィックの増加に対応できない
Slide 27
Slide 27 text
© ZOZO Technologies, Inc. 27 レイテンシーが大きい ● 物体検出と特徴量抽出の推論に時間がかかるため
Slide 28
Slide 28 text
© ZOZO Technologies, Inc. 28 急激なトラフィックの増加に対応できない ● GPUインスタンスのスケールアウトに時間がかかる ○ Kubernetes上でGPUを使うためnvidia-driver-installerの初期化処理がある ■ 初期化が終わるまでPodをノードに割り当てることができない ○ Docker Imageのpullに時間がかかる ● スケールアウトが遅いためリクエストに対して余裕を持って GPUインスタンスを立てておく必要がある
Slide 29
Slide 29 text
© ZOZO Technologies, Inc. 29 現状の課題の根本原因を探る ● レイテンシが大きい ● 急激なトラフィックの増加に対応できない GPUを使う部分がボトルネックになっている
Slide 30
Slide 30 text
© ZOZO Technologies, Inc. 問題を改善するために... APIから物体検出及び特徴量抽出の推論を行わない ● GPUインスタンスを無くすことで、運用コストの削減 ● 推論に関するレイテンシの改善 ● 急激なトラフィックの増加に対応することができる
Slide 31
Slide 31 text
© ZOZO Technologies, Inc. 31 現状の画像検索APIの詳解&おさらい API 特徴量抽出 近傍探索 商品マスタDB ❺売り切れではない商品の検索 ❷商品画像から商品の位置を検出 ❸商品の特徴量を抽出 ❹検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 物体検出 商品画像とカテゴリなどでクエリ
Slide 32
Slide 32 text
© ZOZO Technologies, Inc. 32 現状の画像検索APIの詳解&おさらい API 特徴量抽出 近傍探索 商品マスタDB ❺売り切れではない商品の検索 ❷商品画像から商品の位置を検出 ❸商品の特徴量を抽出 ❹検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 物体検出 問題となっている部分
Slide 33
Slide 33 text
© ZOZO Technologies, Inc. どうやって推論を行わないようにするか ZOZOTOWNでは毎日新商品が出るため、 日次のワークフローで新商品の特徴量を計算して近似最近某探索のインデックス を再構築している.... 33
Slide 34
Slide 34 text
© ZOZO Technologies, Inc. どうやって推論を行わないようにするか ZOZOTOWNでは毎日新商品が出るため、 日次のワークフローで新商品の特徴量を計算して近似最近某探索のインデックス を再構築している.... 34 日次のワークフローで計算する特徴量をキャッシュし、それをAPIで再利用する
Slide 35
Slide 35 text
© ZOZO Technologies, Inc. 35 画像検索プラットフォームでのワークフロー モデルの学習(手動) ● アイテム検出器の学習 / メトリックラーニング ● 画像を集めてリサーチャーが手動で実行 ● 更新頻度: 3 ヶ月〜 ● ref. Google が開発した AI プロセッサ『Cloud TPU』と ZOZOTOWN での 活用事例 https://www.youtube.com/watch?v=jJ0zoTPBBho ANN Index の再構築(Composer を利用) ● ZOZO に新たに出品された商品画像を集める ● 特徴量抽出 & ANN Index 再構築 ● 更新頻度: 日時(将来の展望: イベント駆動) Cloud Storage Developer 画像ストレージ モデルストレージ 学習 Kubernetes Engine ANN index モデル GPU BigQuery ZOZO の既存システム Cloud Filestore Cloud Composer ZOZO 画像 サーバー
Slide 36
Slide 36 text
© ZOZO Technologies, Inc. 36 Cloud Composerとは マネージドワークフローサービス ● OSS ワークフローエンジン ● Apache Airflow のマネージドサービス ● GCPのサービスに関するオペレーターがある ○ GKEPodOperator, BigQueryやGCSなどのオペレーターなど 特徴 ● Python で記述する (Airflow の特徴) ● Google Kubernetes Engine(GKE)で workflow job を実行 ● Google App Engine(GAE)で Airflow の Web UI を提供 ● 他にも Cloud SQL / SQL Proxy / Redis / Cloud PubSub / GCS / GCR なども利用 Cloud Composer
Slide 37
Slide 37 text
© ZOZO Technologies, Inc. 37 現状の検索インデックスの再作成 BigQuery 1. BigQuery テー ブルのバックアッ プ(前日差分計算 用) 2. 新規商品の一 覧化 4. 新規商品の特 徴量を抽出 3. 新規商品画像 のダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ (キャッシュ) BigQuery ZOZO ZOZO 画像 サーバー Cloud Filestore 別 GKE(GPU) BigQuery
Slide 38
Slide 38 text
© ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(step1) BigQuery 1. BigQuery テー ブルのバックアッ プ(前日差分計算 用) 2. 新規商品の一 覧化 4.b 新規商品の 特徴量を抽出 3. 新規商品画像 のダウンロード 5. 全商品のANN index 再構築 6. デプロイ Cloud Storage モデル・Index ストレージ 画像ストレージ (キャッシュ) BigQuery ZOZO Cloud Filestore BigQuery 4.a 新規商品の 位置を検出 Pub/Sub ZOZO 画像 サーバー
Slide 39
Slide 39 text
© ZOZO Technologies, Inc. 検索インデックスの作成ワークフローを改修する(step2) 4.b 新規商品の 特徴量を抽出 5. 全商品のANN index 再構築 7. デプロイ Cloud Storage モデル・Index ストレージ BigQuery Pub/Sub Memorystore 6. 商品URLを キーに商品の特 徴量をredisへと 格納する
Slide 40
Slide 40 text
© ZOZO Technologies, Inc. 40 改修後の画像検索API API 近傍探索 商品マスタDB ❹売り切れではない商品の検索 ❸検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 特徴量DB ❷商品の特徴量を返す 商品画像とカテゴリなどでクエリ
Slide 41
Slide 41 text
© ZOZO Technologies, Inc. 41 良さそう API 近傍探索 商品マスタDB ❹売り切れではない商品の検索 ❸検出された商品と近い商品情報を取得 キャッシュDB ❶キャッシュが存在すれば返す 特徴量DB ❷商品の特徴量を返す 商品画像とカテゴリなどでクエリ 改修後の画像検索API
Slide 42
Slide 42 text
© ZOZO Technologies, Inc. 42 Cloud Composerの運用改善
Slide 43
Slide 43 text
© ZOZO Technologies, Inc. 43 Cloud Composer(Airflow)の良いところ ● DAGをPythonで定義することができる ● インフラを自分達で構築する必要がない ● GCPでも使用できるオペレーターが用意されている
Slide 44
Slide 44 text
© ZOZO Technologies, Inc. 44 GCPでも使用できるオペレーターが用意されている ● Google Kubernetes Pod Operator ● Google Cloud Bigtable Operators ● Google Cloud Build Operators ● Google Compute Engine Operators ● Google Cloud Functions Operators ● Google Cloud Storage Operators ● Google Cloud Natural Language Operators ● Google Cloud Spanner Operators ● Google Cloud Text to Speech Operators ● Google Cloud Speech to Text Operators ● Google Cloud Sql Operators ● Google Cloud Transfer Service Operators ● Google Cloud Translate Operators ● Google Cloud Speech Translate Operators ● Google Cloud Video Intelligence Operators ● Google Cloud Vision Operators
Slide 45
Slide 45 text
© ZOZO Technologies, Inc. 45 Cloud Composer(Airflow)の辛いところ ● 新しいバージョンのリリース頻度が遅い ○ Cloud Composerの最新Airflowは ver1.10.2 ● タスク同士の切れ間に30秒程度の空白が発生する ● Dagを編集した時やDagを実行した時に、Dagを管理しているMySqlでdeadlockが発生する ● Composerが動いているノード自体をオートスケールすることができない ● ローカルで動作確認ができないため、多くの開発時間を搾取される ● GKEPodOperatorでresourceにnvidia.com/gpuを指定できないため、GPUを使うタスクを実行できない。 ○ Airflow ver1.10.4で修正されている ● GKEPodOperatorでカーネルパラメータの設定をできない ● DAG全体のSLAチェックがない ● 値段が高い(1日あたり1600yen)
Slide 46
Slide 46 text
© ZOZO Technologies, Inc. 46 Composerのリリース頻度 2019 2020 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Airflow ver1.10.2 Airflow ver1.10.3 Composer ver1.7.0 Airflow ver1.10.2 もう少しAirflowのバージョンアップのリリー ス頻度を上げて欲しい Composer ver1.7.7 Airflow ver1.10.2 Composer ver1.7.9 Airflow ver1.10.2 Composer ver1.7.6 Airflow ver1.10.2 Composer ver1.7.5 Airflow ver1.10.2 Composer ver1.7.4 Airflow ver1.10.2 Composer ver1.7.3 Airflow ver1.10.2 Airflow ver1.10.4 Composer ver1.7.2 Airflow ver1.10.2 Composer ver1.7.1 Airflow ver1.10.2 Composer ver1.6.1 Airflow ver1.10.1 Composer ver1.6.0 Airflow ver1.10.1 Composer ver1.5.2 Airflow ver1.10.1 Composer ver1.5.0 Airflow ver1.10.1 Composer ver1.5.0 Airflow ver1.10.1
Slide 47
Slide 47 text
© ZOZO Technologies, Inc. 47 タスク同士の切れ間に30秒程度の空白が発生する 原因 ● Scheduler プロセスが DAG の解析と GCS からの DAG のダウンロードをひたすら繰り 返していて CPU を使っている ● Task の起動も Scheduler が行うため、ブロックされて起動までに時間がかかる 改善 ● Composer インスタンスの CPU 数を増強すると 12 sec ぐらいに短縮された ● scheduler-job_heartbeat_sec を小さくすることで普通の Airflow なら改善できるらしい ○ Composerでは設定できない
Slide 48
Slide 48 text
© ZOZO Technologies, Inc. 48 GKEPodOperatorでresourceの指定にnvidia.com/gpuを指定できない GKEPodOperatorでカーネルパラメータの設定をできない 回避策 ● 動かしたいKubernetes JobのYAMLを用意しBashOperatorからkubectl applyをする ref. initContainerの中でカーネルパラメータを変更する https://qiita.com/sonots/items/60721e34c0e31367efa2 原因 ● Airflow ができるように実装していない ● gpu の指定は Airflow 1.10.4 ならできる
Slide 49
Slide 49 text
© ZOZO Technologies, Inc. 49 DAG全体のSLAをチェックできない def notify_if_not_satisfy_sla(**context): yesterday_datetime = datetime.datetime.strptime( context["yesterday_ds"], "%Y-%m-%d" ).astimezone(datetime.timezone.utc) dags_not_satisfy_sla = [ dagrun.execution_date for dagrun in DagRun.find(dag_id="create_index_from_diff") if dagrun.state != State.SUCCESS and dagrun.execution_date > yesterday_datetime ] if len(dags_not_satisfy_sla) > 0: task_contradict_sla_slack_alert() PythonOperatorで上記関数を定期実行することで、昨日のタスクが 終わっていない場合にアラートを飛ばす
Slide 50
Slide 50 text
© ZOZO Technologies, Inc. 50 Composer Pros ● マネージドサービス ● Python で DAG を書けるので自由度が高い(Airflow の感想) Cons ● 自由度が低い(GPU が使えない etc) ● 挙動が不安定 ● バージョンアップを追随してくれていない
Slide 51
Slide 51 text
© ZOZO Technologies, Inc. 51 まとめ
Slide 52
Slide 52 text
© ZOZO Technologies, Inc. 52 ● 地理的に離れた研究所のエンジニアたちと一体となって極力内部のリソースだけで プロジェクトを回している ● 新規プロジェクトだからこそ新しめの技術を使いつつ、短いサイクルでMLパイプラインを含む、 アプリケーションの改善を継続的に行えている ● マイクロサービスとして国内最大級を誇る大きなアプリケーションへの新機能を提供 まとめ
Slide 53
Slide 53 text
No content