MLバッチの監視

MLのバッチの監視についてエムスリーでどのような観点で監視をしたかを話しています。

Transcript

1. MLバッチの 監視 エムスリー AI・機械学習チーム 北川亮
2. 自己紹介 • 北川 亮 (@kitagry) • エムスリーに新卒で入社 現在3年目 • Vim/Go/Kubernetesが好き • 特にすごい肩書きないので作ったもの適当 に載せておきます @m3_engineeringをフォローすると、右のようなネ タ登壇から真面目な techblogまで色々出てくるの で是非フォローしてください
3. 今日の内容 • チーム内での監視の変遷 • エラー監視だけではなぜ足りないか • SLO監視とはなにか 今回は以下のブログをもとにした内容で発表していきます。 https://www.m3tech.blog/entry/ai-slo-monitoring
4. 目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
5. 目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
6. エムスリーのサービスの特徴 医療者向けから一般の方向けの 多様なサービス 多様なサービスで横断的に機械学 習プロダクトを開発していく必要が ある。
7. AI・機械学習チームの特徴 MLの代表的な領域を網羅し広範な サービスに導入 プロダクト数: 30+ チームメンバー14名
8. プロダクトA プロダクトB AI・機械学習チームのインフラ GKE • GKE ◦ Google Cloudのマネー ジドKubernetesエンジン • gokart ◦ エムスリーでOSSとして 公開しているPipeline ツール • 220個の定期実行Job CronJob CronJob CronJob CronJob CronJob
9. 各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存
10. 各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存 他チームから推薦 結果を呼び出し
11. 各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存 自チームや他チーム が結果を利用する
12. AI・機械学習チームの特徴 • 多種多様なサービスを機械学習を使って最適化を行う • サービスのほとんどはGKE上で動いている • サービスは少人数で多数のプロダクトを持っている
13. AI・機械学習チームの特徴 • 多種多様なサービスを機械学習を使って最適化を行う • サービスのほとんどはGKE上で動いている • サービスは少人数で多数のプロダクトを持っている => 最小の労力で効果の大きい監視を行う必要がある
14. 目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
15. エラー監視 MLではデリバリーがちゃんと出来ているかを確認することが大事 手っ取り早く実装できる方法としてJobの失敗情報を監視
16. エラー監視の利点 • エラーを素早く取得することができる • 具体的に何が起こったか分かりやすい • バッチがGKE上にあれば、設定の必要がない
17. エラー監視の問題点 • 大事なエラーが埋もれる ◦ 一度くらい失敗してもいいバッチと一度失敗すると問題があるバッチがある • エラーが出てくるとは限らない ◦ バッチがスタックしてエラーも出さないこともある
18. 目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視 • SLO監視で監視出来ないこと
19. 具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 8:00~ 12:00~
20. 具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery プロダクトBはAの結果に 依存している 8:00~ 12:00~
21. 具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 予測結果を様々なプロ ダクトで利用 8:00~ 12:00~
22. 具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 毎日少しずつデータが 減っていることが判明 8:00~ 12:00~
23. 具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery データ増により一部アップ ロードが間に合わない 8:00~ 12:00~
24. なぜ問題が起こったか どちらのシステムもエラーは一切起こしていない。 問題は依存しているタスクが何時までに終わるかの保証が無かったこと。
25. なぜ問題が起こったか どちらのシステムもエラーは一切起こしていない。 問題は依存しているタスクが何時までに終わるかの保証が無かったこと。 → これらはエラーの監視だけでは見つけることは出来ない
26. 目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
27. SLO監視 • バッチの成功を監視する 成功とは何か？ 今回の例: プロダクトAの成功 = 「プロダクトBが始まる時間までに正常終了すること」 各プロダクトのSLO(サービスレベル目標)を設定する必要がある。 今回の例で言うと、SLO = バッチの終了時間の目標
28. SLO監視 各自が監視したいバッチの情報をスプレッ ドシートに書く 各crontab時間までに成功したjobが無い と通知を行う • 1回くらい失敗しても良いものは通知 しない • 数日かかるjobでも対応可能
29. SLO監視の利点 • そもそも動いていなかったJobやスタックしているJobなどを発見 ◦ これらはKubernetesの設定によって回避できるが、すべてを把握するのは困難 (のちにGatekeeperの導入) • SLOの失敗通知 = 何らかのアクションを取らないといけない通知 ◦ エラー監視と連携することでエラー内容も素早く把握 SLO監視 エラー監視 #fatal #error
30. 補助的な監視 AIチームのバッチの多くはPythonで動い ている。 PythonのTraceback文をslackに送信す ることによってエラー時の情報を素早く把 握
31. そもそも予測結果の監視をしていればいいのでは？ その通り(耳が痛い)
32. そもそも予測結果の監視をしていればいいのでは？ その通り(耳が痛い) チームの特徴として多数のプロダクトがあり、それぞれの見るべき指標は異なる。 → 予測結果の監視にはそれ相応のコストがかかる 各プロダクト毎にある程度作っていたりするが手が回っていない状態 → 横断的に性能を監視するプロダクトが欲しい
33. まとめ • エラー監視から始めるのは手軽だが、数が増えていくと大事な情報が埋もれる • 時間をSLOとして定めて監視を行うことで、大事な通知だけを飛ばすことができた • 本発表ではいくつもある見るべき指標の中で時間という軸を横断的に監視したに過 ぎない 俺たちのSLO監視はまだまだこれからだ