Tweet
Tweet

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監視はまだまだこれからだ