マイクロサービスアプリケーションとしての機械学習 JAPAN CONTAINER DAYS V18.04 Takuma Yamaguchi Machine Learning Engineer

My Background 2001年〜 • 画像認識および機械学習アルゴリズム研究 • 博士(工学) • その他，コンピュータビジョン / オペレーションズリサーチ分野での研究 • CUDA 1.0の頃から GPGPU を利用 2012年〜 • データエンジニア • Hadoop や Spark を中心としたデータ分析基盤の開発・運用 • ユーザ行動トラッキング，LTV 推定等のアルゴリズム開発 2016年〜 • 株式会社メルカリ • 画像認識を中心とした機械学習に基づく機能開発 • コンテナ技術や Docker は，ほぼ素人 • 2017年: 出品時の画像認識機能をリリース (on Kubernetes) 2

3

現状と課題 機械学習・人工知能分野の急速な発展 • 多種多様大量なデータ • GPU を中心としたハードウェアの進展 • ニューラルネットワーク研究の進歩 • ライブラリやフレームワークの整備 • 豊富な学習コンテンツ 多くの企業が期待 • 新しいサービスの提供 • サービス品質の飛躍的向上 • 業務効率化・コスト削減 • 機械学習・人工知能分野の人材不足・獲得合戦 4

Convolutional Neural Networks の原型 5 K. Fukushima: "Neocognitron: A self-organizing neural network model for a mechanism of pattern recognition unaffected by shift in position", Biological Cybernetics, 36[4], pp.193-202 (April 1980).

現状と課題 導入時・運用時の課題 • 処理時間(数百ミリ秒 〜 数秒 / リクエスト) • サーバコスト(要求スペックが高い場合が多い ) • 定期的なモデル学習 • 学習モデル(ファイル)デプロイ • ソースコードと学習モデルの整合性 • Docker イメージに両方含めてしまうのはひとつの手 (モデルサイズ次第) • 学習とサービングで大きく異なる実行環境 • 学習環境でより大きな計算リソースが必要 • 機械学習エンジニアの担当範囲は？ 6

事例 (稼働中のウェブサービス/アプリにおいて) 7 ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要 機械学習を使った機能追加の相談 あなたがインフラ担当なら，どう回答しますか？ 1. 「難しいです(無理です)」 2. 「運用コストが高くて回らないです」 3. 「サーバ用意するんで，あとは自力でやってください」 4. 「手順書用意していただければ構築します」

事例 (稼働中のウェブサービス/アプリにおいて) 8 機械学習を使った機能追加の相談 あなたがインフラ担当なら，どう回答しますか？ ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要 1. 「難しいです(無理です)」 2. 「運用コストが高くて回らないです」 3. 「サーバ用意するんで，あとは自力でやってください」 4. 「手順書用意していただければ構築します」 メルカリにおける画像認識機能の導入時の話

事例 (稼働中のウェブサービス/アプリにおいて) 9 機械学習を使った機能追加の相談 あなたがインフラ担当なら，どう回答しますか？ ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要 1. 「難しいです(無理です)」 2. 「運用コストが高くて回らないです」 3. 「サーバ用意するんで，あとは自力でやってください」 4. 「手順書用意していただければ構築します」 回答: 「とりあえずDockerfile用意してください．なんとかします」

10 メルカリの画像認識機能 • 出品時の作業効率化が目的 • 撮影した商品画像を認識 • 商品名 / カテゴリ / ブランド の自動入力 • 内部的には色識別も行っており，商品検索時の色フィルターに利用

事例 (稼働中のウェブサービス/アプリにおいて) 11 機械学習を使った機能追加の相談 あなたがインフラ担当なら，どう回答しますか？ ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要 1. 「難しいです(無理です)」 2. 「運用コストが高くて回らないです」 3. 「サーバ用意するんで，あとは自力でやってください」 4. 「手順書用意していただければ構築します」 回答: 「とりあえずDockerfile用意してください．なんとかします」

はじめての Dockerfile • Docker を使ったことはあった • ただし知識や経験は非常に少ない状態 • Dockerfile をゼロから書くのは初めて • 丸1日で十分理解できた • ほとんどシェルスクリプト感覚 • ビルド時のキャッシュに気がつくまで作業効率は非常に低かった • Docker を利用して機械学習モデルが動くことまでは確認 • 本番用のモデルは大きいので小さなモデルでテスト 12 素人でも大きくハマることもなく Dockerfile / Docker Image を用意できた

13 1週間後

14 System Architecture

15 System Architecture 機械学習エンジニア の担当部分 画像がS3に保存されていることと GPUの利用のため，バッチサーバはAWSに．

16 System Architecture 通常の運用で見る部分

17 Monitoring & Deployment 通常の運用では，Datadog でのモニタリングと Spinnaker でのデプロイ・リソース管理のみ

はじめての Spinnaker • OSS の Continuous Delivery Platform • なぜ Spinnaker？ • 自動 Deploy に必要な機能が揃っている • Immutable Infrastructure を強制 • http://tech.mercari.com/entry/2017/08/21/092743 • GUIでなんとなく使えてしまう • 手動の場合で数クリックでデプロイ開始 • Pipeline 選択 → Docker Image 選択 → Run • GUI しかないので辛いこともある • 変更箇所がわからない • 入力項目が多い場合に面倒 18

なぜ短期間にこれだけの環境を用意できたか？ 2017年 • 複数の開発拠点 (東京，サンフランシスコ，ロンドン ) • 影響範囲の明確化 • 高速なデプロイ • 技術的バックグラウンドの多様化 US から先行して，Monolithic Architecture から Microservices へ移行 • 全て作り直すのではなく，基本機能は Monolithic のまま • 新機能や大幅な変更が伴う機能は Microservices として実装 19 ● タイミングよく Microservices の基盤が整備されつつあった ● Microservices のメリットを大いに発揮 ● これまでとは全く性質の異なる機能の短期リリースを実現

事例 (稼働中のウェブサービス/アプリにおいて) 20 機械学習を使った機能追加の相談 あなたがインフラ担当なら，どう回答しますか？ 1. 「難しいです(無理です)」 2. 「運用コストが高くて回らないです」 3. 「サーバ用意するんで，あとは自力でやってください」 4. 「手順書用意していただければ構築します」 ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要 実はそれまでの機械学習を使った機能は， ← このやり方で運用

機械学習モデルの手動運用 • 意図的に手動運用 • 多様であろう機械学習モデルの運用がどういうものかが見えてくるまで • モデルをアップデートするたびに SRE に作業依頼 • モデルとコードをデプロイして再起動 • 複数のモデルをサービングできるようなものを作って運用 • 一部のサーバでモデルとコードの不整合 • あるモデルを更新が別のモデルへ影響 • 複数のモデルが動いているためリソース管理が困難 • 汎用的なサービング環境のはずが汎用性不足 • モデルを追加するたびにサービング側のコードも改修 21 運用の限界は，考えていたよりもすぐ目の前にあった

機械学習における Microservices のメリット • 機械学習モデルのサービスへの組み込みが早い • 影響範囲が明確 • 改善の見込みがあれば，現実的な範囲内で計算リソースを気にしなくていい • 機械学習モデルの軽量化はかなり労力が必要 • 新規機能の成果が見えてから取り掛かればいい • ウェブアプリケーションではあまり使わない依存パッケージも自由に使える • TensorFlow，scikit-learn，MeCab，NEologd etc… • 機械学習系パッケージ全部入りの汎用イメージを持つのは筋はよくない • 機械学習モデルだけ更新することも容易 • モデルの Blue-Green Deployment / Immutable Infrastructure • コードと同じくモデルもロールバック可能 22

Blue-Green Deployment 23 機械学習モデルはファイルサイズの都合で Docker Image に含まれないものの， Persistent Volume(ReadOnlyMany)によって，Imutable Infrastructure を実現 モデル更新のたびに Persistent Volumeを生成 コードの更新だけの場合は そのまま (Redisは共通)

機械学習における Microservices の課題 24 • 機械学習エンジニアだけで学習モデル以外のシステム運用もするのか？ • Kubernetes 等のおかげでやれないことはない • ウェブサービスや API 開発の経験があるとは限らない • モデリングに集中できるのが理想的 → 機械学習周りのシステム運用チームを発足予定 • モデリングへの影響 • サービス間連携のオーバーヘッドを考慮 • Microservices ならなんでもありか？ • 運用の属人化が発生しやすい • プロジェクトの雛形や指針を作成し運用コストを低減

まとめ 25 • 機械学習エンジニアの立場から機械学習アプリケーションのシステム構成と運用を紹介 • 実行環境や運用が特殊なことが多く Microservices との親和性が高い • 影響範囲が明確 • アルゴリズム選択の自由度が高い • サービスへの組み込みが早い • Microservices の雛形や指針があれば機械学習エンジニアでもサービス運用は可能 • 機械学習のシステム面を見る専任を用意するのが理想的 • 機械学習エンジニアが専門領域で力を発揮しやすい環境 多くの興味深い機械学習アルゴリズムが日々発表されている中 それらがサービスに容易に組み込めるようになれば，世の中はよりよくなる

余談 26 機械学習を使った機能追加の相談 この次は，200GBのモデルのリリース相談でした ^^; Googleでは1TB+のモデルが動いているようです (https://research.googleblog.com/2017/11/latest-innovations-in-tensorflow-serving.html) ● 機械学習を使った新機能をリリースしたい ● 1サーバで 4リクエスト/秒ほど処理できる(1日のリクエスト数:100万超) ● API (Gunicorn + Django) + Queue + Worker (TensorFlow) ● Worker では，常時 25GB のメモリが必要で起動に 10分かかる ● 機械学習モデルのファイルサイズは 15GB 超 ● モデルは定期的に更新し GPU が必要

Create value in a global marketplace where anyone can buy & sell