2018/11/20開催の「Machine Learning Casual Talks #7」での発表資料です。 チームで開発中の、サイエンティストとエンジニアが効率よく 機械学習や分析結果をプロダクトへ反映するための基盤の紹介です。 https://mlct.connpass.com/event/104874/

1. Jupyterだけで
機械学習ができる基盤
~エンジニアとサイエンティストの共⽣へ〜
2018/11/20 Michihisa HIRATSUKA

2. 平塚 迪久(ひらつか みちひさ)
• リクルートライフスタイル 新卒⼊社 3年⽬
• 仕事
• データ基盤の開発・運⽤
• Web開発 : Flask / Rails / Go / Vue.js
• techeten mihirat

3. CETチーム
プランナー
サイエンティスト
エンジニア
利益創出
サービス横断の利益創出チームにいます

4. アタリを探すABテストをたくさん回して
レコメンド
やりましょう
ユーザーの
離脱下げたい
人工知能！
トレンドの
予測がしたい

5. アタリを⾒つけて

6. 磨き込むのが
筋のよい進め⽅

7. 分析して、良さそう
=> 早くABテストしたい
=> 早く本番から呼べるようにしたい

8. 下記のような業務のイテレーション
企画・
プレ分析
データ開発
モデリング
API 開発
AB テスト
とその評価
本番運⽤
エンハンス
予約⼊⼒で
離脱率下げたい
過去ログ使って
分類モデルを…
Flaskで
サーバー…
改善
するかな？
⽇次バッチの
リトライ

9. サイエンティスト(プランナー兼任)の負担
• 企画探し
• 分析とモデリング
• ロジックの説明など各種調整
• AB振り返り分析
• ↑を複数サービス、複数案件で担当
•エンジニアリングに割くパワーは少ない⽅がよい

10. サイエンティスト⽬線の理想:
サイエンティストだけで⾃⾛できる環境
• 分析 / モデリング
• 潤沢な計算資源
• モデリングではJupyterを使いたい
• 学習
• モデリングをしたら、バッチ⽤のコードを書かなくてよい
• 推論
• サーバーのエラーハンドリングなどを考えなくてよい

11. エンジニアの負担
• 少⼈数 (6⼈+)
• 現在の運⽤システムは15+
• クラウド利⽤、DevOpsで省⼒化
• MLのモデリング
• 障害対応も
• 企画ごとにカスタムでシステムを作ると運⽤で詰む

12. エンジニア⽬線の理想:
⼿動対応が不要な環境
• モデリングコードをそのままバッチコードに
• レビューで品質を担保しつつ
• 環境の⼀貫性
• 「○○環境だと動くんだけど」をなくしたい
• 運⽤の⾃動化
• 継続的な再学習とデプロイ
• 確実なスケーラビリティの担保
• モニタリング

14. 全体像

15. ・⾃由に使えるJupyter環境
・学習、推論と共通のDockerを使⽤
=> 環境差分をなくす

16. ・notebookをGH:Eへpush
=>野良コードの撲滅、引き継ぎ可能に
=>レビューで品質担保・ナレッジ共有

17. ・CI/CDでジョブスケジューラに登録
・notebookをpapermillによりバッチ実⾏
=> バッチコード作成不要

18. ・バッチ実⾏で学習したモデルは都度GCSに保存
・（学習データも同時に保存）
・（学習実⾏時の精度もDBなどに保存）

19. ・GCSにモデルが置かれたことをトリガーとして
そのモデルのAPIサーバーをデプロイ
通知
gs://path/to/model/v1
デプロイ
←の⽂字列だけ
起動コマンドに埋め込む

20. ・GCSにモデルが置かれたことをトリガーとして
そのモデルのAPIサーバーをデプロイ
通知
gs://path/to/model/v1
デプロイ
←の⽂字列だけ
起動コマンドに埋め込む
・（学習時の精度を⾒て
デプロイ可否を決定）

21. ・デプロイされたAPIサーバーは、起動時に
GCSからモデルを取得。取得したモデルの推論
結果を返す
・I/Oの型だけ決め、実際の値のフォーマット
はサイエンティストとAPI利⽤者間で決定
・エラーハンドリングなどはエンジニアが担保

22. ・GKEでのスケーラビリティ
・Istioによるモニタリングの充実やABテスト
・Stackdriverによる監視

23. ・サーバーをいつでもデプロイできるように
dispatcherとの依存関係を切り離し。
upstreamの存在確認はせず、そのまま流す
dispatcher
modelAmodelA modelB modelAmodelC
dispatcher
modelA
リクエストの
pathで
Serviceへ振り分け
Notebookをpushした
リポジトリの階層が
そのままpathになる

24. ・推論結果のログはすべてBigQueryに連携し
モデルの改善やABテストに活⽤
・（オンラインでの精度監視）

25. FAQ
• Dockerがfatでは？
• 共通化を優先して許容
• Scikit-learnしか使えない？分散学習は？
• まずアタリをつけるために、テストファーストが優先事項
• よってモデルはそこまで複雑なものでなくてもよい
• 複雑な要件は割合として⼩さいため、カスタム対応とした
• モデルのオンライン更新は？
• この基盤では対象外（他にリアルタイム施策⽤基盤がある）

26. なんで〇〇を使わないの？
• 現時点で全部の要件を満たすものが⾒つからなかった
• RPS、Docker共通化できるかどうか、etc
• 業務フローに最適化したい
• いずれ、よいものが出てくる⽇に備えて開発
• ⼯数はあまり取らないように（1~2⼈⽉）
• すぐ置き換えできるように疎結合な設計
• GCSを介した連携にし、各コンポーネントを置換可能にしておく
• あくまでも理想とする概念の実装例に過ぎない
• Kubeflowなどで実現できるようになるなら、それでよい

27. Cloud Next 登壇などもしています
https://www.youtube.com/watch?v=X_yavAFAE4I
https://www.slideshare.net/RecruitLifestyle/gcp-118777332
http://www.itmedia.co.jp/enterprise/articles/1809/18/news002.html
https://cloudonair.withgoogle.com/events/cloud-onair-japan-q3-2018/watch?talk=tky_uc_q3&reg=
https://www.slideshare.net/GoogleCloudPlatformJP/cloud-onair-2018712/GoogleCloudPlatformJP/cloud-onair-2018712

28. ⼀緒に開発しませんか！
■Recruiting site: https://engineer.recruit-lifestyle.co.jp/recruiting/
■Tech Blog: https://engineer.recruit-lifestyle.co.jp/techblog/

29. Fin