Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MLバッチの監視
Search
Ryo Kitagawa
August 23, 2023
1
490
MLバッチの監視
MLのバッチの監視についてエムスリーでどのような観点で監視をしたかを話しています。
Ryo Kitagawa
August 23, 2023
Tweet
Share
More Decks by Ryo Kitagawa
See All by Ryo Kitagawa
敵対的SRE: 300個のジョブをAIチーム全員で支える技術
kitagry
8
4.9k
GKEでのMLバッチ運用のコツ
kitagry
1
130
Featured
See All Featured
KATA
mclloyd
29
13k
Scaling GitHub
holman
458
140k
Become a Pro
speakerdeck
PRO
24
5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
Why Our Code Smells
bkeepers
PRO
334
57k
Statistics for Hackers
jakevdp
796
220k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
Building Adaptive Systems
keathley
38
2.2k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Six Lessons from altMBA
skipperchong
26
3.5k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Transcript
MLバッチの 監視 エムスリー AI・機械学習チーム 北川亮
自己紹介 • 北川 亮 (@kitagry) • エムスリーに新卒で入社 現在3年目 • Vim/Go/Kubernetesが好き
• 特にすごい肩書きないので作ったもの適当 に載せておきます @m3_engineeringをフォローすると、右のようなネ タ登壇から真面目な techblogまで色々出てくるの で是非フォローしてください
今日の内容 • チーム内での監視の変遷 • エラー監視だけではなぜ足りないか • SLO監視とはなにか 今回は以下のブログをもとにした内容で発表していきます。 https://www.m3tech.blog/entry/ai-slo-monitoring
目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
エムスリーのサービスの特徴 医療者向けから一般の方向けの 多様なサービス 多様なサービスで横断的に機械学 習プロダクトを開発していく必要が ある。
AI・機械学習チームの特徴 MLの代表的な領域を網羅し広範な サービスに導入 プロダクト数: 30+ チームメンバー14名
プロダクトA プロダクトB AI・機械学習チームのインフラ GKE • GKE ◦ Google Cloudのマネー ジドKubernetesエンジン
• gokart ◦ エムスリーでOSSとして 公開しているPipeline ツール • 220個の定期実行Job CronJob CronJob CronJob CronJob CronJob
各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存
各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存 他チームから推薦 結果を呼び出し
各バッチの使われ方 CronJob CronJob RDB API BigQuery 推薦システム DWHに推論結果を保存 自チームや他チーム が結果を利用する
AI・機械学習チームの特徴 • 多種多様なサービスを機械学習を使って最適化を行う • サービスのほとんどはGKE上で動いている • サービスは少人数で多数のプロダクトを持っている
AI・機械学習チームの特徴 • 多種多様なサービスを機械学習を使って最適化を行う • サービスのほとんどはGKE上で動いている • サービスは少人数で多数のプロダクトを持っている => 最小の労力で効果の大きい監視を行う必要がある
目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
エラー監視 MLではデリバリーがちゃんと出来ているかを確認することが大事 手っ取り早く実装できる方法としてJobの失敗情報を監視
エラー監視の利点 • エラーを素早く取得することができる • 具体的に何が起こったか分かりやすい • バッチがGKE上にあれば、設定の必要がない
エラー監視の問題点 • 大事なエラーが埋もれる ◦ 一度くらい失敗してもいいバッチと一度失敗すると問題があるバッチがある • エラーが出てくるとは限らない ◦ バッチがスタックしてエラーも出さないこともある
目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視 •
SLO監視で監視出来ないこと
具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 8:00~ 12:00~
具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery プロダクトBはAの結果に 依存している 8:00~ 12:00~
具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 予測結果を様々なプロ ダクトで利用 8:00~ 12:00~
具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery 毎日少しずつデータが 減っていることが判明 8:00~ 12:00~
具体的に発生した事例 プロダクトA BigQuery プロダクトB BigQuery データ増により一部アップ ロードが間に合わない 8:00~ 12:00~
なぜ問題が起こったか どちらのシステムもエラーは一切起こしていない。 問題は依存しているタスクが何時までに終わるかの保証が無かったこと。
なぜ問題が起こったか どちらのシステムもエラーは一切起こしていない。 問題は依存しているタスクが何時までに終わるかの保証が無かったこと。 → これらはエラーの監視だけでは見つけることは出来ない
目次 • エムスリーのAI・機械学習チームの特徴 • エラー監視 • エラー監視で監視出来ない具体例 • SLO監視
SLO監視 • バッチの成功を監視する 成功とは何か? 今回の例: プロダクトAの成功 = 「プロダクトBが始まる時間までに正常終了すること」 各プロダクトのSLO(サービスレベル目標)を設定する必要がある。 今回の例で言うと、SLO
= バッチの終了時間の目標
SLO監視 各自が監視したいバッチの情報をスプレッ ドシートに書く 各crontab時間までに成功したjobが無い と通知を行う • 1回くらい失敗しても良いものは通知 しない • 数日かかるjobでも対応可能
SLO監視の利点 • そもそも動いていなかったJobやスタックしているJobなどを発見 ◦ これらはKubernetesの設定によって回避できるが、すべてを把握するのは困難 (のちにGatekeeperの導入) • SLOの失敗通知 = 何らかのアクションを取らないといけない通知
◦ エラー監視と連携することでエラー内容も素早く把握 SLO監視 エラー監視 #fatal #error
補助的な監視 AIチームのバッチの多くはPythonで動い ている。 PythonのTraceback文をslackに送信す ることによってエラー時の情報を素早く把 握
そもそも予測結果の監視をしていればいいのでは? その通り(耳が痛い)
そもそも予測結果の監視をしていればいいのでは? その通り(耳が痛い) チームの特徴として多数のプロダクトがあり、それぞれの見るべき指標は異なる。 → 予測結果の監視にはそれ相応のコストがかかる 各プロダクト毎にある程度作っていたりするが手が回っていない状態 → 横断的に性能を監視するプロダクトが欲しい
まとめ • エラー監視から始めるのは手軽だが、数が増えていくと大事な情報が埋もれる • 時間をSLOとして定めて監視を行うことで、大事な通知だけを飛ばすことができた • 本発表ではいくつもある見るべき指標の中で時間という軸を横断的に監視したに過 ぎない 俺たちのSLO監視はまだまだこれからだ