MLバッチの監視 - Speaker Deck

MLバッチの監視

by Ryo Kitagawa

Slide 1

Slide 1 text

MLバッチの監視エムスリー AI・機械学習チーム北川亮

Slide 2

Slide 2 text

自己紹介 ● 北川亮 (@kitagry) ● エムスリーに新卒で入社現在3年目 ● Vim/Go/Kubernetesが好き ● 特にすごい肩書きないので作ったもの適当に載せておきます @m3_engineeringをフォローすると、右のようなネタ登壇から真面目な techblogまで色々出てくるので是非フォローしてください

Slide 3

Slide 3 text

今日の内容 ● チーム内での監視の変遷 ● エラー監視だけではなぜ足りないか ● SLO監視とはなにか今回は以下のブログをもとにした内容で発表していきます。 https://www.m3tech.blog/entry/ai-slo-monitoring

Slide 4

Slide 4 text

目次 ● エムスリーのAI・機械学習チームの特徴 ● エラー監視 ● エラー監視で監視出来ない具体例 ● SLO監視

Slide 5

Slide 5 text

目次 ● エムスリーのAI・機械学習チームの特徴 ● エラー監視 ● エラー監視で監視出来ない具体例 ● SLO監視

Slide 6

Slide 6 text

エムスリーのサービスの特徴医療者向けから一般の方向けの多様なサービス多様なサービスで横断的に機械学習プロダクトを開発していく必要がある。

Slide 7

Slide 7 text

AI・機械学習チームの特徴 MLの代表的な領域を網羅し広範なサービスに導入プロダクト数: 30+ チームメンバー14名

Slide 8

Slide 8 text

プロダクトA プロダクトB AI・機械学習チームのインフラ GKE ● GKE ○ Google CloudのマネージドKubernetesエンジン ● gokart ○ エムスリーでOSSとして公開しているPipeline ツール ● 220個の定期実行Job CronJob CronJob CronJob CronJob CronJob

Slide 9

Slide 9 text

各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存

Slide 10

Slide 10 text

各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存他チームから推薦結果を呼び出し

Slide 11

Slide 11 text

各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存自チームや他チームが結果を利用する

Slide 12

Slide 12 text

AI・機械学習チームの特徴 ● 多種多様なサービスを機械学習を使って最適化を行う ● サービスのほとんどはGKE上で動いている ● サービスは少人数で多数のプロダクトを持っている

Slide 13

Slide 13 text

AI・機械学習チームの特徴 ● 多種多様なサービスを機械学習を使って最適化を行う ● サービスのほとんどはGKE上で動いている ● サービスは少人数で多数のプロダクトを持っている => 最小の労力で効果の大きい監視を行う必要がある

Slide 14

Slide 14 text

目次 ● エムスリーのAI・機械学習チームの特徴 ● エラー監視 ● エラー監視で監視出来ない具体例 ● SLO監視

Slide 15

Slide 15 text

エラー監視 MLではデリバリーがちゃんと出来ているかを確認することが大事手っ取り早く実装できる方法としてJobの失敗情報を監視

Slide 16

Slide 16 text

エラー監視の利点 ● エラーを素早く取得することができる ● 具体的に何が起こったか分かりやすい ● バッチがGKE上にあれば、設定の必要がない

Slide 17

Slide 17 text

エラー監視の問題点 ● 大事なエラーが埋もれる ○ 一度くらい失敗してもいいバッチと一度失敗すると問題があるバッチがある ● エラーが出てくるとは限らない ○ バッチがスタックしてエラーも出さないこともある

Slide 18

Slide 18 text

目次 ● エムスリーのAI・機械学習チームの特徴 ● エラー監視 ● エラー監視で監視出来ない具体例 ● SLO監視 ● SLO監視で監視出来ないこと

Slide 19

Slide 19 text

具体的に発生した事例プロダクトA BigQuery プロダクトB BigQuery 8:00~ 12:00~

Slide 20

Slide 20 text

具体的に発生した事例プロダクトA BigQuery プロダクトB BigQuery プロダクトBはAの結果に依存している 8:00~ 12:00~

Slide 21

Slide 21 text

具体的に発生した事例プロダクトA BigQuery プロダクトB BigQuery 予測結果を様々なプロダクトで利用 8:00~ 12:00~

Slide 22

Slide 22 text

具体的に発生した事例プロダクトA BigQuery プロダクトB BigQuery 毎日少しずつデータが減っていることが判明 8:00~ 12:00~

Slide 23

Slide 23 text

具体的に発生した事例プロダクトA BigQuery プロダクトB BigQuery データ増により一部アップロードが間に合わない 8:00~ 12:00~

Slide 24

Slide 24 text

なぜ問題が起こったかどちらのシステムもエラーは一切起こしていない。問題は依存しているタスクが何時までに終わるかの保証が無かったこと。

Slide 25

Slide 25 text

なぜ問題が起こったかどちらのシステムもエラーは一切起こしていない。問題は依存しているタスクが何時までに終わるかの保証が無かったこと。 → これらはエラーの監視だけでは見つけることは出来ない

Slide 26

Slide 26 text

目次 ● エムスリーのAI・機械学習チームの特徴 ● エラー監視 ● エラー監視で監視出来ない具体例 ● SLO監視

Slide 27

Slide 27 text

SLO監視 ● バッチの成功を監視する成功とは何か？今回の例: プロダクトAの成功 = 「プロダクトBが始まる時間までに正常終了すること」各プロダクトのSLO(サービスレベル目標)を設定する必要がある。今回の例で言うと、SLO = バッチの終了時間の目標

Slide 28

Slide 28 text

SLO監視各自が監視したいバッチの情報をスプレッドシートに書く各crontab時間までに成功したjobが無いと通知を行う ● 1回くらい失敗しても良いものは通知しない ● 数日かかるjobでも対応可能

Slide 29

Slide 29 text

SLO監視の利点 ● そもそも動いていなかったJobやスタックしているJobなどを発見 ○ これらはKubernetesの設定によって回避できるが、すべてを把握するのは困難 (のちにGatekeeperの導入) ● SLOの失敗通知 = 何らかのアクションを取らないといけない通知 ○ エラー監視と連携することでエラー内容も素早く把握 SLO監視エラー監視 #fatal #error

Slide 30

Slide 30 text

補助的な監視 AIチームのバッチの多くはPythonで動いている。 PythonのTraceback文をslackに送信することによってエラー時の情報を素早く把握

Slide 31

Slide 31 text

そもそも予測結果の監視をしていればいいのでは？その通り(耳が痛い)

Slide 32

Slide 32 text

そもそも予測結果の監視をしていればいいのでは？その通り(耳が痛い) チームの特徴として多数のプロダクトがあり、それぞれの見るべき指標は異なる。 → 予測結果の監視にはそれ相応のコストがかかる各プロダクト毎にある程度作っていたりするが手が回っていない状態 → 横断的に性能を監視するプロダクトが欲しい

Slide 33

Slide 33 text

まとめ ● エラー監視から始めるのは手軽だが、数が増えていくと大事な情報が埋もれる ● 時間をSLOとして定めて監視を行うことで、大事な通知だけを飛ばすことができた ● 本発表ではいくつもある見るべき指標の中で時間という軸を横断的に監視したに過ぎない俺たちのSLO監視はまだまだこれからだ