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
8
720
バッチ処理の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
スタートアップにおける、チーム拡大を見据えたコンポーネント分割の取り組み
rynsuke
3
2.7k
Error Tracking for Logsを用いたバッチ処理のエラー監視
rynsuke
2
760
Notionではじめるライフハックのススメ
rynsuke
1
660
「Datadog入れてみたらAWSの料金が爆発した話」@ゆるSRE勉強会 #1
rynsuke
12
9.1k
LLM Meetup Tokyo #2 手続きを記憶するコマンド型エージェントの実装
rynsuke
3
2.7k
Other Decks in Technology
See All in Technology
よく聞くけど使ったことないソフトウェアNo.1 KafkaとSnowflake
foursue
4
360
JAWS-UG Bedrock Claude Night
yamahiro
3
620
VS CodeでAWSを操作しよう
smt7174
8
1.7k
20分で完全に理解するGrafanaダッシュボード
hamadakoji
3
700
BPStudyの200回を中心にIT業界を振り返る。そしてこれから
haru860
2
170
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
360
On Your Data を超えていく!
hirotomotaguchi
2
700
Google Cloud Next '24でブログを10本書いた方法と勉強会を沸かせた方法
yasumuusan
0
310
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
5
540
KubeCon EU 2024 Recap “Kubernetes Policy Time Machine: Where to Next?”
ryysud
0
230
web-application-security
matsuihidetoshi
0
170
Kernel MemoryでAzure OpenAI Serviceとお手軽データソース連携
mitsuzono
1
260
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
Building Better People: How to give real-time feedback that sticks.
wjessup
355
18k
Optimizing for Happiness
mojombo
370
69k
The Language of Interfaces
destraynor
151
23k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
14
1.6k
Happy Clients
brianwarren
92
6.4k
Gamification - CAS2011
davidbonilla
76
4.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
21
1.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Designing Experiences People Love
moore
136
23k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
241
1.2M
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 • 「実装」に対する検査から、「成果」に対する検査へ
まとめ • バッチ処理の死活監視を効果的に設計するためには、適切なサービスレベ ル指標を定義することが重要 • バッチ処理の出⼒データの「納期」と「品質」に注⽬することで、実装で はなく成果に注⽬した効果的なサービスレベル指標を⽴てることができる • 結果として、バッチ処理の部分的な障害に対する測定性が向上し、 エンジニアを疲弊させない正確なアラートティングの実装
に繋がる
ク ラ ウ ド 運 ⽤ を 安 全 に