Quality consideration of machine learning system in production

1. 機械学習
システムと品質
2020/09/12
Shibui Yusuke

2. 自己紹介
shibui yusuke
● いろいろ → メルカリ → TierIV（いまここ）
● MLOpsエンジニア &
SRE &
ARエンジニア
● もともとクラウド基盤の開発、運用。
● ここ4年くらいMLOpsで仕事。
● Github: @shibuiwilliam
● Qiita: @cvusk
● FB: yusuke.shibui
● 最近の趣味：Edge AIとARと3Dマッピング
cat : 0.55
dog: 0.45
human : 0.70
gorilla : 0.30
物体検知

3. CatOps in work from home
放置しているとネコに
椅子を奪われる。
ネコ障害対応（餌、遊ぶ）。
「遊ぶ」を自動化する。
椅子に座っていても
ハンズフリーで遊べる。
day
奪
わ
れ
回
数
ハンズフリー導入
飽き始める
Dev
Data-driven

4. Agenda
1. MLOps
2. システムとして考える機械学習
3. 機械学習システムの品質
4. 機械学習のスピード
5. 機械学習と可用性
6. まとめ

5. 機械学習のシステム
● ユーザから見たAI
● MLエンジニアから見たML
● ソフトウェアエンジニアから見た
MLシステム
猫！
犬！
猫！
https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
Accuracy
99.99%

6. MLOps
● 機械学習をDevOpsに則って開発、運用する手法と文化。
● 機械学習はモデルを作るだけでなく、モデルを本番環境に導入して
ビジネスインパクトを創出することが重要。
● 本番環境で機械学習モデルを稼働させ、継続的に改善していく
（CI、CD、CT）ことで価値を最大化。
● 機械学習のワークフローをシステムとして開発、運用することが望ましい。

7. システムとして考える機械学習
推論器
インターフェイ
ス
ログ
学習評価
モデル
管理
コード
管理
運用監視
イメージ
管理
スト
レージ
CI
前処理
推論
後処理
BI
→
機械学習で
DevOpsを
回すために必要
↓最低限必要

8. 機械学習システムの品質
機械学習システムの品質を3カテゴリに分類してみる。
1. 機械学習の推論モデル
a. 推論モデルのパフォーマンス
b. 本番データの変化による劣化とエラー
c. 問題定義とソリューション
2. 推論モデルを稼働させるシステム
a. 入出力のデータやデータ型
b. 推論スピードと可用性
c. 例外処理
3. 運用と体制
a. モデルの再現および再学習
b. 推論器の再現およびロールバック
c. 維持可能な運用体制
Client RT LB
int float
test data
accuracy:
99.99%
何のML
だっけ？
1sec/req
モデル作った
VM消したよ
dockerimg:latest
上書き
error率
0.1%
アサイン
変わった
me
too
転
職
商品カテゴリ
追加削除
そして誰も
いなくなった

9. アンチパターン
● 推論器が遅すぎてユーザを待たせてる。 ● 性能劣化した推論器でも継続して
すべてのリクエストに推論を返す。
test data
accuracy:
99.99%
5sec/req
2015年の
test accuracy:
99.99%
ネコ！
イヌ！
2015年
2020年
5秒で離脱

10. 機械学習のスピード
● 学習のスピード：モデル改善の効率。 TensorboardでProfiling可能。
https://www.tensorflow.org/tensorboard/tensorboard_profiling_keras
● 推論のスピード：ユーザ向けサービスのサービスレベル。
○ レスポンススピード：リクエストに対する推論結果の返信所要時間。
○ 負荷耐性：レスポンススピードの安定度。負荷テストで計測。
○ 誰も長く待ちたくない！
入力
前処理
推論
後処理
出力
通信
前処理
推論
後処理
出力
通信
入力
所要時間
通信

11. 機械学習の推論スピード
● 推論器のボトルネックは推論。 Deep learningの場合、9割以上がDeep learningだったりする。
● 学習コストの高いDeep learningは学習後に測定するのではなく、学習前に測っておく。
● Too bigなモデルでない限り、学習後はモデルは変更せず、実行環境やプログラムで高速化、
可用性向上を図るほうが効率的なことがある。
○ モデルをチューニングする費用対効果 ＜ 基盤でチューニングする費用対効果
入力
前処理
推論
後処理
出力
通信
前処理
推論
後処理
出力
通信
入力
所要時間
通信

12. 機械学習と負荷テスト
● 推論器に対して負荷テストを実施。
● 入力が画像やテキストの場合、ランダムなサイズのデータを用意して所要時間や負荷耐性を測る。
● 推論はCPUバウンドのため、高負荷になると CPU使用率が上がるはず。
Load tester LB
計測時間
req/sec
計測時間
RAM
CPU
負荷に対して
CPU使用率が
上がるはず。
計測時間
RAM
CPU
CPU使用率が
低い場合は
以下のいずれか
1. 効率的なモデル
2. サーバの設定漏れ
負荷負荷テストの構成 リソース利用

13. 可用性
● サーキットブレーカー
○ 急激な負荷増で処理能力やスケールアウトが
間に合わない場合、一部のリクエストを
遮断して全断を防ぐ。
○ NginxやEnvoy proxyで標準装備。
● 推論のバックアッププランと例外処理
○ デフォルトの推論結果や挙動を決めておいて、
エラー発生時はデフォルトの挙動を発動。
○ 障害発生時や遅延時に有効。
○ 本番データの傾向が変わって推論器が性能劣化
している場合も環境変数でデフォルトの推論を
返すようにすることもできる。
Client LB
Nginx 推論器
circuit break
over 300rps
Client LB LB
<= 300rps: 推論
> 300rps: default 0

14. まとめ
● 推論結果を返却するまでが機械学習。
● 確率的 & 重い計算処理が含まれる機械学習を本番環境で動かすためには、
正常に動かなかった場合のバックアッププランが必要。
● 機械学習を本番導入するときの転ばぬ先の杖になれば幸いです。
● もっと詳しく
https://www.slideshare.net/yusukeshibui/ml-system-inpython