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
バッチ処理のSLOをどう設計するか
Search
Ryunosuke Iwai
March 26, 2024
Technology
10
1.4k
バッチ処理のSLOをどう設計するか
TechBrew in 東京 〜バッチ処理 最適化の取り組み〜
https://findy.connpass.com/event/312637/
Ryunosuke Iwai
March 26, 2024
Tweet
Share
More Decks by Ryunosuke Iwai
See All by Ryunosuke Iwai
2024/08/19 PEK Recap | データで振り返るPEK2024
rynsuke
2
210
スタートアップにおける、チーム拡大を見据えたコンポーネント分割の取り組み
rynsuke
3
3.4k
Error Tracking for Logsを用いたバッチ処理のエラー監視
rynsuke
2
1.4k
Notionではじめるライフハックのススメ
rynsuke
18
1.4k
「Datadog入れてみたらAWSの料金が爆発した話」@ゆるSRE勉強会 #1
rynsuke
12
11k
LLM Meetup Tokyo #2 手続きを記憶するコマンド型エージェントの実装
rynsuke
3
3k
Other Decks in Technology
See All in Technology
君も受託系GISエンジニアにならないか
sudataka
2
430
表現を育てる
kiyou77
1
210
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
360
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
350
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
690
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
2
1.5k
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
350
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
150
白金鉱業Meetup Vol.17_あるデータサイエンティストのデータマネジメントとの向き合い方
brainpadpr
5
720
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
740
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.6k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
2.9k
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
Code Review Best Practice
trishagee
67
18k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Writing Fast Ruby
sferik
628
61k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Fireside Chat
paigeccino
34
3.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Typedesign – Prime Four
hannesfritz
40
2.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Why Our Code Smells
bkeepers
PRO
336
57k
Transcript
バッチ処理のSLOをどう設計するか @TechBrew in 東京 〜バッチ処理 最適化の取り組み〜 2024/03/26 Cloudbase 株式会社 @ryuke
株式会社メルカリ Microservices Platform CI/CD @ryuke 岩井 ⿓之介 Cloudbase株式会社 Scanner &
Platform チーム Go / terraform / Datadog 前職 現在 SNS https://twitter.com/i_ryuke
None
システム構成
システム構成
スキャンワークフローをStep Functionsで実現 +
今⽇の話
バッチ処理の死活監視を いい感じにしたい!
バッチジョブの死活監視 • Datadogを使い、ジョブの実⾏状況を可視化 • ジョブがこけたらSlackに通知が⾶び、オンコール担当が対応
バッチジョブの死活監視における課題 • ⼀部のエラーに対して、全体を落とすかログを吐くだけにするか ◦ ⼤量のデータを⼀括で処理するため、⼀部の処理でどうしてもエラー (ex. レートリミット、タイムアウト、予期しない⼊⼒)が出てしまう ◦ 「⼀つでもエラーが起きたら全体を落とす」は、データ量が増えるに つれて現実的でなくなる(All
or Nothing) ◦ とはいえ、全てのエラーで毎回アラートを上げると アラート地獄にハマる
サービスレベル指標 • SREのベストプラクティスでは、サービスの信頼性を 測定するためのトップレベル指標として 「サービスレベル指標(SLI / SLO)」を設定する • メトリクスが⽬標値を下回る =
インシデント 開発の⼿を⽌めて必要な是正措置を取る • アラート疲れを防ぎ、本質的なシステムの問題 に集中するための⽅法 https://amzn.asia/d/4CWdelE (偉そうに載せているがまだ読んでないですすみません)
いい感じの サービスレベル指標を考える
よくあるSLI / SLO • SLOといえば、「可⽤性99.9%」「エラー率0.5%以下」「95パーセンタイ ルレイテンシー1秒以下」など • いずれもオンラインシステム(API)を前提としており、バッチ処理に当て はめようとしてもうまくいかない ◦
可⽤性:特定⽇時に実⾏されればよく常時稼働性は不要 ◦ エラー率:後述 ◦ レイテンシー:特定の時間までに完了していればよく、実⾏時間⾃体 は問題にならないことが多い
⼿頃な指標として、「ジョブの成功率」 • 「ジョブの成功率」をサービスレベル指標として使うと...? ◦ 「ジョブの成功 ≠ 全ての処理の成功」 ▪ 全体のジョブは正常に完了していても個々の処理が全て失敗して いたら、それは「正常」と⾔えるか?
◦ 実⾏頻度の低いジョブでは機能するSLOにならない ▪ 「エラー率1%以下」= 実質1回ジョブが失敗したら⼤体即インシ デントになり、パーセント指定する意味がない • 我々はジョブの失敗に怯えながら眠るしかないのか...?
バッチ処理の存在意義から考える
バッチ処理の存在意義から考える • SRE⽤語では、CUJ = クリティカルユーザージャーニー • そのシステムを必要とする⼈の⽴場から考える • バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム
• バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず!
バッチ処理の存在意義から考える • SRE⽤語では、CUJ = クリティカルユーザージャーニー • そのシステムを必要とする⼈の⽴場から考える • バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム
• バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず! • 多くの場合、バッチ処理に求められるのは 「⼤量のデータを処理して加⼯されたデータに 変換し、それを必要とするシステムに届けること」
バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である
バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である • バッチ処理に求められる信頼性とはデータの「納期」と「品質」である
バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である • バッチ処理に求められる信頼性とはデータの「納期」と「品質」である • 納期までに求められる品質を満たすデータが届けられるのであれば、どん な⼿段を使っても良い ◦ ジョブが100回失敗しても、
101回⽬のリトライで成功すれば良い ◦ 計算が夜通しかかっても、 社員が出勤する朝に終わっていれば良い 出典:DEATH NOTE コミックス12巻 より
「データの品質」から バッチ処理のSLOを定義してみる
Cloudbaseにおける実践:データ品質の定義 • Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 • セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 • これを踏まえたセキュリティスキャンデータの品質とは?
Cloudbaseにおける実践:データ品質の定義 • Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 • セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 • これを踏まえたセキュリティスキャンデータの品質とは? ◦ 安定性:検出されたリスクが正しく、同じリスクが重複して検出され
ないこと ◦ 網羅性:全てのリソースに対するリスクが網羅的に検出されること ◦ 最新性(納期):環境の最新の状態を反映したスキャンが数時間‧数 ⽇以内に完了していること
Cloudbaseにおける実践:データ品質に基づいたサービスレベル指標 • データの品質定義を元にした3つのSLOを策定 ◦ 安定性: ▪ リスクイベントの件数を測定し、⼀定の範囲に収まっているか ◦ 網羅性: ▪
エラー件数を測定し、スキャンがエラーなく完了しているリソー スの割合が⼀定以下であるか ◦ 最新性(納期): ▪ DBを定期的に⾛査し、最新のスキャンが⼀定時間以内に完了して いるか
Cloudbaseにおける実践:達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 →
ストリーミング処理
Cloudbaseにおける実践:達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 →
ストリーミング処理 • 不正確なアラート問題 ◦ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ◦ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK
Cloudbaseにおける実践:達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 →
ストリーミング処理 • 不正確なアラート問題 ◦ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ◦ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK • 「実装」に対する検査から、「成果」に対する検査へ
まとめ • バッチ処理の死活監視を効果的に設計するためには、適切なサービスレベ ル指標を定義することが重要 • バッチ処理の出⼒データの「納期」と「品質」に注⽬することで、実装で はなく成果に注⽬した効果的なサービスレベル指標を⽴てることができる • 結果として、バッチ処理の部分的な障害に対する測定性が向上し、 エンジニアを疲弊させない正確なアラートティングの実装
に繋がる
ク ラ ウ ド 運 ⽤ を 安 全 に