Slide 1

Slide 1 text

バッチ処理のSLOをどう設計するか @TechBrew in 東京 〜バッチ処理 最適化の取り組み〜 2024/03/26 Cloudbase 株式会社 @ryuke

Slide 2

Slide 2 text

株式会社メルカリ Microservices Platform CI/CD @ryuke 岩井 ⿓之介 Cloudbase株式会社 Scanner & Platform チーム Go / terraform / Datadog 前職 現在 SNS https://twitter.com/i_ryuke

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

システム構成

Slide 5

Slide 5 text

システム構成

Slide 6

Slide 6 text

スキャンワークフローをStep Functionsで実現 +

Slide 7

Slide 7 text

今⽇の話

Slide 8

Slide 8 text

バッチ処理の死活監視を いい感じにしたい!

Slide 9

Slide 9 text

バッチジョブの死活監視 ● Datadogを使い、ジョブの実⾏状況を可視化 ● ジョブがこけたらSlackに通知が⾶び、オンコール担当が対応

Slide 10

Slide 10 text

バッチジョブの死活監視における課題 ● ⼀部のエラーに対して、全体を落とすかログを吐くだけにするか ○ ⼤量のデータを⼀括で処理するため、⼀部の処理でどうしてもエラー (ex. レートリミット、タイムアウト、予期しない⼊⼒)が出てしまう ○ 「⼀つでもエラーが起きたら全体を落とす」は、データ量が増えるに つれて現実的でなくなる(All or Nothing) ○ とはいえ、全てのエラーで毎回アラートを上げると アラート地獄にハマる

Slide 11

Slide 11 text

サービスレベル指標 ● SREのベストプラクティスでは、サービスの信頼性を 測定するためのトップレベル指標として 「サービスレベル指標(SLI / SLO)」を設定する ● メトリクスが⽬標値を下回る = インシデント 開発の⼿を⽌めて必要な是正措置を取る ● アラート疲れを防ぎ、本質的なシステムの問題 に集中するための⽅法 https://amzn.asia/d/4CWdelE (偉そうに載せているがまだ読んでないですすみません)

Slide 12

Slide 12 text

いい感じの サービスレベル指標を考える

Slide 13

Slide 13 text

よくあるSLI / SLO ● SLOといえば、「可⽤性99.9%」「エラー率0.5%以下」「95パーセンタイ ルレイテンシー1秒以下」など ● いずれもオンラインシステム(API)を前提としており、バッチ処理に当て はめようとしてもうまくいかない ○ 可⽤性:特定⽇時に実⾏されればよく常時稼働性は不要 ○ エラー率:後述 ○ レイテンシー:特定の時間までに完了していればよく、実⾏時間⾃体 は問題にならないことが多い

Slide 14

Slide 14 text

⼿頃な指標として、「ジョブの成功率」 ● 「ジョブの成功率」をサービスレベル指標として使うと...? ○ 「ジョブの成功 ≠ 全ての処理の成功」 ■ 全体のジョブは正常に完了していても個々の処理が全て失敗して いたら、それは「正常」と⾔えるか? ○ 実⾏頻度の低いジョブでは機能するSLOにならない ■ 「エラー率1%以下」= 実質1回ジョブが失敗したら⼤体即インシ デントになり、パーセント指定する意味がない ● 我々はジョブの失敗に怯えながら眠るしかないのか...?

Slide 15

Slide 15 text

バッチ処理の存在意義から考える

Slide 16

Slide 16 text

バッチ処理の存在意義から考える ● SRE⽤語では、CUJ = クリティカルユーザージャーニー ● そのシステムを必要とする⼈の⽴場から考える ● バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム ● バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず!

Slide 17

Slide 17 text

バッチ処理の存在意義から考える ● SRE⽤語では、CUJ = クリティカルユーザージャーニー ● そのシステムを必要とする⼈の⽴場から考える ● バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム ● バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず! ● 多くの場合、バッチ処理に求められるのは 「⼤量のデータを処理して加⼯されたデータに 変換し、それを必要とするシステムに届けること」

Slide 18

Slide 18 text

バッチ処理に求められる信頼性とは ● バッチ処理における成果とは「データ」である

Slide 19

Slide 19 text

バッチ処理に求められる信頼性とは ● バッチ処理における成果とは「データ」である ● バッチ処理に求められる信頼性とはデータの「納期」と「品質」である

Slide 20

Slide 20 text

バッチ処理に求められる信頼性とは ● バッチ処理における成果とは「データ」である ● バッチ処理に求められる信頼性とはデータの「納期」と「品質」である ● 納期までに求められる品質を満たすデータが届けられるのであれば、どん な⼿段を使っても良い ○ ジョブが100回失敗しても、 101回⽬のリトライで成功すれば良い ○ 計算が夜通しかかっても、 社員が出勤する朝に終わっていれば良い 出典:DEATH NOTE コミックス12巻 より

Slide 21

Slide 21 text

「データの品質」から バッチ処理のSLOを定義してみる

Slide 22

Slide 22 text

Cloudbaseにおける実践:データ品質の定義 ● Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 ● セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 ● これを踏まえたセキュリティスキャンデータの品質とは?

Slide 23

Slide 23 text

Cloudbaseにおける実践:データ品質の定義 ● Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 ● セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 ● これを踏まえたセキュリティスキャンデータの品質とは? ○ 安定性:検出されたリスクが正しく、同じリスクが重複して検出され ないこと ○ 網羅性:全てのリソースに対するリスクが網羅的に検出されること ○ 最新性(納期):環境の最新の状態を反映したスキャンが数時間‧数 ⽇以内に完了していること

Slide 24

Slide 24 text

Cloudbaseにおける実践:データ品質に基づいたサービスレベル指標 ● データの品質定義を元にした3つのSLOを策定 ○ 安定性: ■ リスクイベントの件数を測定し、⼀定の範囲に収まっているか ○ 網羅性: ■ エラー件数を測定し、スキャンがエラーなく完了しているリソー スの割合が⼀定以下であるか ○ 最新性(納期): ■ DBを定期的に⾛査し、最新のスキャンが⼀定時間以内に完了して いるか

Slide 25

Slide 25 text

Cloudbaseにおける実践:達成できたこと ● 「ジョブの成功 ≠ 全ての処理の成功」問題 ○ 部分的なエラーをより正確に評価できるようになった ○ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理

Slide 26

Slide 26 text

Cloudbaseにおける実践:達成できたこと ● 「ジョブの成功 ≠ 全ての処理の成功」問題 ○ 部分的なエラーをより正確に評価できるようになった ○ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理 ● 不正確なアラート問題 ○ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ○ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK

Slide 27

Slide 27 text

Cloudbaseにおける実践:達成できたこと ● 「ジョブの成功 ≠ 全ての処理の成功」問題 ○ 部分的なエラーをより正確に評価できるようになった ○ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理 ● 不正確なアラート問題 ○ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ○ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK ● 「実装」に対する検査から、「成果」に対する検査へ

Slide 28

Slide 28 text

まとめ ● バッチ処理の死活監視を効果的に設計するためには、適切なサービスレベ ル指標を定義することが重要 ● バッチ処理の出⼒データの「納期」と「品質」に注⽬することで、実装で はなく成果に注⽬した効果的なサービスレベル指標を⽴てることができる ● 結果として、バッチ処理の部分的な障害に対する測定性が向上し、 エンジニアを疲弊させない正確なアラートティングの実装 に繋がる

Slide 29

Slide 29 text

ク ラ ウ ド 運 ⽤ を 安 全 に