Mercari Server Side Tech Talk Vol.2 〜CREナイト〜 機械学習によるマーケット健全化施策を支える技術 by hnakagawa

1. 機械学習によるマーケット
健全化施策を支える技術
Mercari Server Side Tech Talk Vol.2 〜CREナイト〜
hnakagawa

2. 自己紹介
• Hirofumi Nakagawa
(hnakagawa)
• 2017年7月入社
• 所属はSRE
• デバイスドライバ開発からフロ
ントエンド開発までやる何でも
屋
• NOT MLエンジニア
• https://github.com/hnakagaw
a

3. お仕事 & Agenda
• ML Platform開発
• MLエンジニアとSREのスキルギャップを埋め
る
• ML Reliability, SysML?, MLOps?
• SREの立場からCREチームを助ける

4. ML Platform
• 内製のML Platform
• kubernetesベース
• ローカル環境とクラスタ環境の
差を抽象化する
• 便利API群
• 既存のML Frameworkを使用し
簡単にTraining/Servingを行う
環境を提供

5. そのうちOSSで公開予定(多分

6. 今日のAgendaは
CREプロジェクト

7. リアルタイム商品監視システム
• 通称 Lovemachine
• ML Platform上に実装されている
ML Platform (training cluster)
Lovemachine
GCS
GKE
PubSub
ML Platform (serving cluster)
Lovemachine

8. ML ModelのServing….?

9. Model Serving APIの構成例
TensorFlow
Serving
TF
Model
TF
Model
Flask
SK
Model
SK
Model
SK
Model
gRPC
Mercari API
REST
Flaskで前処理を行い
裏のTensorFlow Servingに投げている

10. Model Serving API
Streaming ver の構成例
TensorFlow
Serving
TF
Model
TF
Model
ML Platform
Framework
or
Apache Beam
SK
Model
SK
Model
SK
Model
gRPC
PubSub

11. TensorFlow Serving
• TensorFlow projectが提供して
いるServing環境
• Python処理系を介さずにTFの
modelをservingできる
• 標準の実装ではgRPCでAPIを
提供

12. Modelとコンテナ・イメージ
• 巨大なML Modelをコンテナ・イメージに含め
るか否か
• 含めないのであれば何処に配置するか
• ポータビリティ性とロード時間のトレードオフ
• 良いアイディアがあれば教えて下さい…

13. 通常のAPIとは違う
• 扱うリソース、Modelサイズが大きくなる場合
が多い(数百MB〜数GB)
• CPU・メモリリソースの消費が激しい
• 場合によってはGPUも使う

14. メモリ消費問題
• LovemachineのPython実装部分は実行時に約
2GBメモリを消費する→今後さらに増える予
定もある
• Scikit-learnで記述されたTF-IDF等の前処理部
分が大きくなる事が多い

15. Pythonと並列性
• 当然Threadが使えない(GILのため)
• プロセス毎にModelをロードすると必要なメモ
リサイズが大きくなる→ Blue-Green Deploy
の障害になる

16. 正直PythonでのServingは
インフラ的に辛い事が多い…

17. メモリを賢く使う
• forkする前にmodelをロードしCopy on Write
を効かす
• k8sのone process per containerセオリはあ
えて破っている

18. Copy On Writeの復習
メモリ
親プロセス 子プロセス
2.fork
Page A
1.allocation 同じ領域を参照

19. プロセスがメモリの内容を
書き換えると…
メモリ
親プロセス 子プロセス
Page A Page B
OSが別の領域をAllocationして元データをコピーする
別の領域を参照

20. Current Issues
• Mercari APIとのつなぎ込みに苦労
→ 一通り作れば後は再利用できるはず
• 人間の行動を相手にしている為、データの傾向が変
わりやすかったり、予想外の問題が発生したりして
、対応し続ける必要がある
→ ML Model作成者に負担が掛かり続ける
→ SREとしては自動化を含んだ仕組みで解決した
い

21. Future Plans
• 社内のデータから特徴量を抽出するして
Embeddingする汎用の仕組み
→適当な分類器と組み合わせれば、誰でもそこそ
この分類モデルを作成できる?
→FBLearner Flow的なやつ?
• 社内の問題解決に特化した専用のAutoML的な何
か?

22. まとめ
• ML ModelのServingには、少し通常と違うインフラ
が必要になる
→まだベスト・プラクティスは分からない
• 人の行動を相手にするのは大変
• そもそもMLな機能を本格運用しようとすると、大
幅な自動化・仕組み化を進めないと上手く行かな
い

23. ご清聴ありがとうございました!!

24. We are Hiring!!

25. SRE ML Reliability
• SysML? MLOps? 新しいJob description
• SREスキル+ML分野の基礎知識
• MLインフラの自動化・仕組み化を推し進めて
くれる人材
• もちろん他の職種も絶賛募集中!!

26. 詳細はこちら
https://careers.mercari.com/