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
敵対的SRE: 300個のジョブをAIチーム全員で支える技術
Search
Ryo Kitagawa
August 03, 2024
Technology
8
4.9k
敵対的SRE: 300個のジョブをAIチーム全員で支える技術
Ryo Kitagawa
August 03, 2024
Tweet
Share
More Decks by Ryo Kitagawa
See All by Ryo Kitagawa
GKEでのMLバッチ運用のコツ
kitagry
1
130
MLバッチの監視
kitagry
1
490
Other Decks in Technology
See All in Technology
AI Builder について
miyakemito
1
150
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
9
120k
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
140
AWS re:Inventを徹底的に楽しむためのTips / Tips for thoroughly enjoying AWS re:Invent
yuj1osm
1
510
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
170
Vueで Webコンポーネントを作って Reactで使う / 20241030-cloudsign-vuefes_after_night
bengo4com
4
2.5k
急成長中のWINTICKETにおける品質と開発スピードと向き合ったQA戦略と今後の展望 / winticket-autify
cyberagentdevelopers
PRO
1
160
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
Amazon_CloudWatch_ログ異常検出_導入ガイド
tsujiba
1
250
一休.comレストランにおけるRustの活用
kymmt90
3
550
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
290
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
210
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.6k
Building Your Own Lightsaber
phodgson
102
6k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Speed Design
sergeychernyshev
24
570
We Have a Design System, Now What?
morganepeng
50
7.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Transcript
敵対的SRE: 300個のジョブ をAIチーム全員で支える技術 エムスリー株式会社 北川 亮 1
自己紹介 • 北川 亮 • エムスリー株式会社 AI・機械学習チーム所属 SRE • 京都オフィス所属
• Vim/Go/Kubernetesが好き 2
自己紹介 • 北川 亮 • エムスリー株式会社 AI・機械学習チーム所属 SRE • 京都オフィス所属
• Vim/Go/Kubernetesが好き チーム所属のSRE というEmbedded SREという立場 3
(※) 2023年10月時点 日本の医師のエムスリー会員率 エムスリーが事業展開している国の数 エムスリーが占める全世界で医師会員の割合 全世界で医師会員合計 17 カ国 (※) 50
%以上 (※) 650 万人以上 (※) 90 %以上 エムスリー が展開する医療従事者向け情報 サイト「m3.com」は32万人を突破、日本 の医師の9割以上が会員。(※) 日本の医師の9割が登録するエムスリーのサービス グローバルでも医師の5割以上が会員、医療業界に根付く事業基盤 圧倒的な医療データへのアクセス容易性を活かしたAI開発 4
エムスリーのプロダクトに根ざしたAI技術活用事例 ToB・ToC・グローバルプロダクトにも展開 医療の疑問に医師が答えるAskDoctors 検索エンジン開発 海外版m3.comの記事やQuizのレコメンド AIチームメンバーがUS出張開始 シェアNo.1のクラウド電子カルテ 病名入力補完APIの開発 医療業界のビッグデータを活用 マーケティング向けデータ分析
医療画像やウェアラブルデバイスデータを活用 医療業界のAI活用を推進 5
アジェンダ 1. 敵対的SREとは 2. 実例1: アラートに付加情報をのせる 3. 実例2: 成功を監視する 4.
実例3: 必要な監視に絞る 5. まとめ 6
敵対的SREとは 7
敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視かフィードバック 8
敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視かフィードバック 9
敵対的生成ネットワーク 生成器 識別器 GAN(Generative Adversarial Network)と呼ばれる深層学習アーキテクチャ データを生成 生成されたものか判定 10
敵対的生成ネットワーク 画像生成などで良く使われる 偽 or 真 11
敵対的生成ネットワーク 生成器 識別器 GAN(Generative Adversarial Network)と呼ばれる深層学習アーキテクチャ データを生成 生成されたものか判定 正しいデータ の特徴を学習
納得させる データを学習 12
良い学習のためにはバランスが重要 生成器 識別器 生成したデータが良いかどうか をフィードバック出来ない 13
GANを応用した敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視の 特徴を学習 納得させる 監視を生成 14
良い監視体制を目指す フィードバック
GANを応用した敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視の 特徴を学習 納得させる 監視を生成 15
良い監視体制を目指す フィードバック
チームメンバー • 2024年8月現在で14人 • プロダクト数が50個ほど ◦ 定期ジョブは約300個 • 各メンバーが自身のプロダクトを運用している ◦
もちろん手が回らない場合はサポートなどを行う • SRE自身もプロダクト開発をしている 16
GANを応用した敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視の 特徴を学習 納得させる 監視を生成 17
フィードバック
SRE • AI・機械学習チームに所属するSRE ◦ メンバーの中の7人がSREタスクを行っている • チームの開発基盤の作成から監視の作成まで行う 18
フィードバック GANを応用した敵対的SREとは? SRE チーム メンバー 監視を生成 良い監視の 特徴を学習 納得させる 監視を生成
ここが大事 19
何故、メンバーからのフィードバックが大事か? • 監視とは運用を効果的にするためにサポートするものである • 実際に良いかどうか判断するのは運用者 ◦ SREが良かれと思って監視を作っても効果は分からない 20
ここまでのまとめ • 敵対的SRE: SREとメンバーが互いに学習しながら監視を安定させる • 良い監視を学習するためにはメンバーからのフィードバックが重要 • エムスリーAI・機械学習チームは敵対的SREを通して、14人で50個のプロダ クトを運用している 21
実例の紹介 22
当初の(良くある)アラート Kubernetes Jobが落ちたら通知 23
当初の(良くある)アラート Kubernetes Jobが落ちたら通知 Cloud Logging エラーログを確認 24
単に落ちただけじゃなく、何故落ちたかまで知りたい SRE チーム メンバー 情報量を増やしたい 単純なアラートを生成 25
改善内容 • PythonのTraceback文のような決まった定型文をエラーと共に通知した ◦ Cloud Logging対応することによって、severityなどの統一も 得られた効果 • 徐々にジョブが増えていく中で、原因探索時間が短くなった Kubernetes
改善1: アラートに付加情報を加える Jobが落ちたら通知 26
学び: より情報量が多いアラートが良いアラートである SRE チーム メンバー 情報量が多 いほど良い アラート Pythonの Stacktrace
が良い付加 情報になり そう 27
実例2: 成功を監視する 28
ジョブの終了が遅いアラートが欲しい AI・機械学習チーム 別チーム ジョブ ジョブ BigQuery 10:00に取り込み 9:30に完了 29
ジョブの終了が遅いアラートが欲しい AI・機械学習チーム 別チーム ジョブ ジョブ BigQuery 10:30に完了 10:00に取り込み 徐々にデータ量が増え ていくなど
30
ジョブの終了が遅いアラートが欲しい AI・機械学習チーム 別チーム ジョブ ジョブ BigQuery 10:30に完了 10:00に取り込み 必要なデータが存在し なくてエラー
31
ジョブの終了が遅いアラートが欲しい AI・機械学習チーム 別チーム ジョブ ジョブ BigQuery 10:30に完了 従来のアラートでは気 付けないエラー 10:00に取り込み
32
ジョブの終了が遅いアラートが欲しい SRE チーム メンバー 落ちたという 情報はエ ラーの一部 に過ぎない 成功を監視したい エラー情報を通知
33
改善内容 • 何時までにBigQueryにデータ連携すれば成功かを定義 • 成功しなかったものを通知 得られた効果 • 今までに発見出来なかった遅くなっていたジョブを検知 改善2: 成功を監視する
BigQuery table更新が間に合わな ければアラート 34
学び: 成功を定義して監視をするのが重要 SRE チーム メンバー アウトプッ トを監視し ないといけ ない テーブルの
作成時間が ジョブの SLOである 35
実例3: 必要な監視に絞る 36
アラート多すぎ問題 • 2024年現在 チームで定期的に動くジョブは約300個 • 5分毎に動くジョブも3ヶ月に1度動くジョブも同じアラート Jobが落ちたら通知 Kubernetes 37
対応が必要なアラートだけが欲しい SRE チーム メンバー 対応が必要なアラートに絞りたい エラー等もすべて同様に通知 38
対応が必要なアラートとは? • 実例2でSLOを定義してそれを監視するのが良いことを学習した 39
各ジョブのSLOを考えてみる 5分に一回動くジョブ 40 10:00 10:05 10:10
各ジョブのSLOを考えてみる 失敗する 41 5分に一回動くジョブ 10:00 10:05 10:10 10:15
各ジョブのSLOを考えてみる 次成功すればOK 42 5分に一回動くジョブ 10:00 10:05 10:10 10:15 10:20
各ジョブのSLOを考えてみる ずっと失敗してい るならアウト 43 5分に一回動くジョブ 10:00 10:05 10:10 10:15 10:20
各ジョブのSLOを考えてみる 3ヶ月に一回動くジョブ 1回でも失敗した らアウト 44
各ジョブのSLOを考えてみる • 5分に一回動くジョブ → 30分の間に1度以上成功すればOK • 3ヶ月に一回動くジョブ → 3ヶ月に1度成功すればOK 45
各ジョブのSLOを考えてみる • 5分に一回動くジョブ → 30分の間に1度以上成功すればOK • 3ヶ月に一回動くジョブ → 3ヶ月に1度成功すればOK ジョブごとに◯時までに一度成功しているかを監視すれば良い
46
Kubernetes 必要な監視に絞る • すべてのジョブにSLOを定義して通知 SLOを満たさなければ通知 47
Kubernetes 必要な監視に絞る • すべてのジョブにSLOを定義して通知 → 今までのエラーは付加情報として SLOを満たさなければ通知 48
必要な監視に絞る 改善内容 • 成功監視を全ジョブに広げて通知を行った • 今までの失敗アラートは付加情報として別チャンネルに 得られた効果 • アラートが対応が必要なものだけに絞られた •
事例1・2で学んだ付加情報や成功監視が出来ている状態 49
学び: 行動につながるアラートだけを最低限に SRE チーム メンバー ジョブの特 徴によって SLOは異な る 行動につな
がるものだ けをアラー トする 50
まとめ • 敵対的SRE: SREとメンバーが互いに学習しながら監視を安定させる • 一方的に監視を作成するのはアンチパターン(本当の敵になってしまう) • チームで学んだこと ◦ 重要なのはSLOを定義し、それを補助するアラートを作成すること
◦ SLO監視が行動につながるアラートになる ◦ それ以外のメトリクスは補助のために利用してもよい 51
ちょっと雑談 • 行動につながるアラートだけに絞るために1週間ノーアラートで焼き肉チャ レンジを行った • 目的 ◦ チーム全体の運用コストを最低限に ◦ 全サービスのSLOを見直すモチベーションに
• CfPを出した(2024/6/25)時点では最長6日と8時間 52
ちょっと雑談 • 行動につながるアラートだけに絞るために1週間ノーアラートで焼き肉チャ レンジを行った • 目的 ◦ チーム全体の運用コストを最低限に ◦ 全サービスのSLOを見直すモチベーションに
• CfPを出した(2024/6/25)時点では最長6日と8時間 なんと出した当日に達成 🎉🎉🎉 53
エンジニア採用ページ https://jobs.m3.com/engineer/ プロダクト紹介ページ https://jobs.m3.com/product/ エムスリーテックブログ https://www.m3tech.blog/ エムスリーをもっと詳しく 54 社員インタビュー https://www.wantedly.com/companies/m3_inc
VPoE登壇資料 fukabori.fm https://fukabori.fm/episode/59 https://fukabori.fm/episode/60 Connpass公式グループ https://m3-engineer.connpass.com/ エンジニア公式Twitter(X) https://twitter.com/m3_engin eering エンジニア公式YouTube https://www.youtube.com/channel /UC_DkAOcwgmtQnJLDctci4rQ
https://jobs.m3.com/engineer/ カジュアル面談・応募はこちら プロダクトの内容、技術的な内容 どちらでも気になった場合は気軽にご応募ください!