バッチ処理のSLOをどう設計するか

TechBrew in 東京 〜バッチ処理 最適化の取り組み〜
https://findy.connpass.com/event/312637/

Transcript

1. バッチ処理のSLOをどう設計するか @TechBrew in 東京 〜バッチ処理 最適化の取り組み〜 2024/03/26 Cloudbase 株式会社 @ryuke
2. 株式会社メルカリ Microservices Platform CI/CD @ryuke 岩井 ⿓之介 Cloudbase株式会社 Scanner & Platform チーム Go / terraform / Datadog 前職 現在 SNS https://twitter.com/i_ryuke
4. システム構成
5. システム構成
6. スキャンワークフローをStep Functionsで実現 +
7. 今⽇の話
8. バッチ処理の死活監視を いい感じにしたい！
9. バッチジョブの死活監視 • Datadogを使い、ジョブの実⾏状況を可視化 • ジョブがこけたらSlackに通知が⾶び、オンコール担当が対応
10. バッチジョブの死活監視における課題 • ⼀部のエラーに対して、全体を落とすかログを吐くだけにするか ◦ ⼤量のデータを⼀括で処理するため、⼀部の処理でどうしてもエラー （ex. レートリミット、タイムアウト、予期しない⼊⼒）が出てしまう ◦ 「⼀つでもエラーが起きたら全体を落とす」は、データ量が増えるに つれて現実的でなくなる（All or Nothing） ◦ とはいえ、全てのエラーで毎回アラートを上げると アラート地獄にハマる
11. サービスレベル指標 • SREのベストプラクティスでは、サービスの信頼性を 測定するためのトップレベル指標として 「サービスレベル指標（SLI / SLO）」を設定する • メトリクスが⽬標値を下回る = インシデント 開発の⼿を⽌めて必要な是正措置を取る • アラート疲れを防ぎ、本質的なシステムの問題 に集中するための⽅法 https://amzn.asia/d/4CWdelE （偉そうに載せているがまだ読んでないですすみません）
12. いい感じの サービスレベル指標を考える
13. よくあるSLI / SLO • SLOといえば、「可⽤性99.9%」「エラー率0.5%以下」「95パーセンタイ ルレイテンシー1秒以下」など • いずれもオンラインシステム（API）を前提としており、バッチ処理に当て はめようとしてもうまくいかない ◦ 可⽤性：特定⽇時に実⾏されればよく常時稼働性は不要 ◦ エラー率：後述 ◦ レイテンシー：特定の時間までに完了していればよく、実⾏時間⾃体 は問題にならないことが多い
14. ⼿頃な指標として、「ジョブの成功率」 • 「ジョブの成功率」をサービスレベル指標として使うと...？ ◦ 「ジョブの成功 ≠ 全ての処理の成功」 ▪ 全体のジョブは正常に完了していても個々の処理が全て失敗して いたら、それは「正常」と⾔えるか？ ◦ 実⾏頻度の低いジョブでは機能するSLOにならない ▪ 「エラー率1%以下」= 実質1回ジョブが失敗したら⼤体即インシ デントになり、パーセント指定する意味がない • 我々はジョブの失敗に怯えながら眠るしかないのか...？
15. バッチ処理の存在意義から考える
16. バッチ処理の存在意義から考える • SRE⽤語では、CUJ = クリティカルユーザージャーニー • そのシステムを必要とする⼈の⽴場から考える • バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム • バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず！
17. バッチ処理の存在意義から考える • SRE⽤語では、CUJ = クリティカルユーザージャーニー • そのシステムを必要とする⼈の⽴場から考える • バッチ処理におけるユーザーとは、多くの場合エンドユーザーではなく特定の システム • バッチ処理が稼働しているということは、期待されている「出⼒」や「変 化」、「理想状態」があるはず！ • 多くの場合、バッチ処理に求められるのは 「⼤量のデータを処理して加⼯されたデータに 変換し、それを必要とするシステムに届けること」
18. バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である
19. バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である • バッチ処理に求められる信頼性とはデータの「納期」と「品質」である
20. バッチ処理に求められる信頼性とは • バッチ処理における成果とは「データ」である • バッチ処理に求められる信頼性とはデータの「納期」と「品質」である • 納期までに求められる品質を満たすデータが届けられるのであれば、どん な⼿段を使っても良い ◦ ジョブが100回失敗しても、 101回⽬のリトライで成功すれば良い ◦ 計算が夜通しかかっても、 社員が出勤する朝に終わっていれば良い 出典：DEATH NOTE コミックス12巻 より
21. 「データの品質」から バッチ処理のSLOを定義してみる
22. Cloudbaseにおける実践：データ品質の定義 • Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 • セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 • これを踏まえたセキュリティスキャンデータの品質とは？
23. Cloudbaseにおける実践：データ品質の定義 • Cloudbaseのバッチ処理における出⼒は「セキュリティスキャンの結果」 • セキュリティスキャンに求められるのは、「リスクが正確かつ網羅的に、 できるだけ少ない遅延で検出されること」 • これを踏まえたセキュリティスキャンデータの品質とは？ ◦ 安定性：検出されたリスクが正しく、同じリスクが重複して検出され ないこと ◦ 網羅性：全てのリソースに対するリスクが網羅的に検出されること ◦ 最新性（納期）：環境の最新の状態を反映したスキャンが数時間‧数 ⽇以内に完了していること
24. Cloudbaseにおける実践：データ品質に基づいたサービスレベル指標 • データの品質定義を元にした3つのSLOを策定 ◦ 安定性： ▪ リスクイベントの件数を測定し、⼀定の範囲に収まっているか ◦ 網羅性： ▪ エラー件数を測定し、スキャンがエラーなく完了しているリソー スの割合が⼀定以下であるか ◦ 最新性（納期）： ▪ DBを定期的に⾛査し、最新のスキャンが⼀定時間以内に完了して いるか
25. Cloudbaseにおける実践：達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理
26. Cloudbaseにおける実践：達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理 • 不正確なアラート問題 ◦ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ◦ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK
27. Cloudbaseにおける実践：達成できたこと • 「ジョブの成功 ≠ 全ての処理の成功」問題 ◦ 部分的なエラーをより正確に評価できるようになった ◦ 結果として、部分的な障害に対する耐性も向上 → ストリーミング処理 • 不正確なアラート問題 ◦ ⼤雑把すぎるアラート or 細かすぎるアラートの代わりに、 実際に深刻な影響がある場合のみアラートが⾶ぶように ◦ ⼀時的にジョブが失敗しても、適切にリトライが⾛ればOK • 「実装」に対する検査から、「成果」に対する検査へ
28. まとめ • バッチ処理の死活監視を効果的に設計するためには、適切なサービスレベ ル指標を定義することが重要 • バッチ処理の出⼒データの「納期」と「品質」に注⽬することで、実装で はなく成果に注⽬した効果的なサービスレベル指標を⽴てることができる • 結果として、バッチ処理の部分的な障害に対する測定性が向上し、 エンジニアを疲弊させない正確なアラートティングの実装 に繋がる
29. ク ラ ウ ド 運 ⽤ を 安 全 に