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
エラーバジェット枯渇の原因 - 偽陽性との戦い -
Search
Tomonori Hayashi
January 26, 2025
Technology
1
120
エラーバジェット枯渇の原因 - 偽陽性との戦い -
SRE Kaigi 2025 LT 大会で登壇させていただいた際の資料です。
https://2025.srekaigi.net/
Tomonori Hayashi
January 26, 2025
Tweet
Share
More Decks by Tomonori Hayashi
See All by Tomonori Hayashi
Vertex AI Experimentsの実態 - コードを辿った先にあったもの -
phaya72
2
630
オブザーバビリティと開発優先度との向き合い方
phaya72
4
760
Cloud Service Mesh への期待が止まらない!!
phaya72
2
1.2k
とあるソフトウェアエンジニアの小さく始めるオブザーバビリティ
phaya72
2
370
OpenTelemetry Collector の Connectors って何者?
phaya72
2
1.7k
Cloud Service Mesh に触れ合う
phaya72
3
1.5k
Cloud Deploy と仲良くなりたい
phaya72
1
660
Cloud Run に日々感謝
phaya72
1
330
Other Decks in Technology
See All in Technology
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.3k
SREが実現する開発者体験の革新
sansantech
PRO
0
120
滑らかなユーザー体験も目指す注文管理のマイクロサービス化〜注文情報CSVダウンロード機能の事例〜
demaecan
0
130
Re:VIEWで書いた「Compose で Android の edge-to-edge に対応する」をRoo Codeで発表資料にしてもらった
tomoya0x00
0
240
Agile TPIを活用した品質改善事例
tomasagi
0
570
NLP2025 参加報告会 / NLP2025
sansan_randd
2
120
Multitenant 23ai の全貌 - 機能・設計・実装・運用からマイクロサービスまで
oracle4engineer
PRO
2
160
20250328_OpenAI製DeepResearchは既に一種のAGIだと思う話
doradora09
PRO
0
170
「ラベルにとらわれない」エンジニアでいること/Be an engineer beyond labels
kaonavi
0
220
大規模サービスにおける カスケード障害
takumiogawa
3
770
Beyond {shiny}: The Future of Mobile Apps with R
colinfay
0
170
20250326_管理ツールの権限管理で改善したこと
sasata299
1
600
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Code Reviewing Like a Champion
maltzj
522
39k
A designer walks into a library…
pauljervisheath
205
24k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
A Tale of Four Properties
chriscoyier
158
23k
Navigating Team Friction
lara
184
15k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
51
2.4k
Making Projects Easy
brettharned
116
6.1k
Transcript
エラーバジェット 枯渇の原因 - 偽陽性との戦い - SRE Kaigi 2025 LT 大会
- Tomonori Hayashi 1
Tomonori Hayashi • NTT コミュニケーションズ ◦ ノーコード AI ツール「Node-AI」の開発/運用 ◦
ソフトウェアエンジニア ▪ Front:TypeScript - React/Next.js ▪ Infra:Google Cloud • Google Cloud Partner Top Engineer 2024 - 2025 • Google Cloud Partner Tech Blog Challenge 2024 個人カテゴリ 優秀ブログ • Google Cloud All Certifications • コミュニティ ◦ Google Cloud 公式ユーザーコミュニティ「 Jagu’e’r」 ▪ オブザーバビリティ分科会 運営 ▪ エバンジェリスト 2 @pHaya72 @t_hayashi
エラーバジェットを導入してみて 経験した話です
改めて定義をおさらい 4 エラーバジェット とは “エラーバジェットは、 100% を信頼性の目標とすることは、基本的にいかな る場合にも間違って いるという所見から生じたもの です。
… 企業やプロダクトは、システムの可用性のターゲットをはっきりさせなければ なりません。そのターゲットがはっきりすれば、 エラーバジェットはその可用 性のターゲットを 1 から引いたもの になります。 … エラーバジェットの利用は、開発と SRE との間の動機付けの構造的な競合 を解決します。...SRE とプロダクト開発者は、 機能のリリース速度を最大化 するためにエラーバジェットを使うことを目標にします 。” — 書籍「サイトリライアビリティエンジニアリング」 1章 イントロダクション
エラーバジェット導入までの道のり 5 オブザーバビリティに本腰を入れて取り組み始める
エラーバジェット導入までの道のり 6 検証を経て仕組みの構築・ SLI/SLO の決定
エラーバジェット導入までの道のり 7 実際に運用することで味わう難しさ
偽陽性のエラーがはびこっていた 8 適切なエラーハンドリングの重要性 バーンレートアラートによって、 ある程度の頻度でサービス異常に気づきデバッ グする機会を得られるようになった 一方で、挙がったエラーが必ずしも「対応すべきサービス異常」であるかというと そうではなかった → 実装の中で「
適切でないエラーハンドリングにより 500 番台のステータス コードを挙げている 」部分が多々存在した 本来、エラーバジェットが削られるようなエラーではない( = 偽陽性のエラー ) にも関わらず、とりあえずのエラーハンドリングによりアラートが飛んでいる こ とがわかった
偽陽性のエラーがはびこっていた 9 適切なエラーハンドリングの重要性 バーンレートアラートによって、 ある程度の頻度でサービス異常に気づきデバッ グする機会を得られるようになった 一方で、挙がったエラーが必ずしも「対応すべきサービス異常」であるかというと そうではなかった → 実装の中で「
適切でないエラーハンドリングにより 500 番台のステータス コードを挙げている 」部分が多々存在した 本来、エラーバジェットが削られるようなエラーではない( = 偽陽性のエラー ) にも関わらず、とりあえずのエラーハンドリングによりアラートが飛んでいる こ とがわかった まずはこのエラーハンドリングから 継続的に見直していく必要がある
前述したエラーバジェットの利用まだ先 10 サービス異常を検知するために 元々解決したい課題感としては、「サービスの異常を発見できない」「異常が発見で きても迅速にデバックできない」というものだった 特に前者を解決するために「 何かしらの基準でアラートを仕掛けたい 」というモチ ベーションがあった 今回は「設定した時間内にエラーバジェットを枯渇する速度
」=「バーンレートア ラート 」を採用して「サービスの異常を発見できない」課題にアプローチ • リクエストの総数に対して、 200~400 番台のリクエストを成功 • リクエストが偽陽性を含む 500 番台をあげる たびにアラートしていてはオ オカミ少年になりかねない → サービス異常を緩く検知する意図でバーンレートアラートを利用
前述したエラーバジェットの利用まだ先 11 サービス異常を検知するために 元々解決したい課題感としては、「サービスの異常を発見できない」「異常が発見で きても迅速にデバックできない」というものだった 特に前者を解決するために「 何かしらの基準でアラートを仕掛けたい 」というモチ ベーションがあった 今回は「設定した時間内にエラーバジェットを枯渇する速度
」=「バーンレートア ラート 」を採用して「サービスの異常を発見できない」課題にアプローチ • リクエストの総数に対して、 200~400 番台のリクエストを成功 • リクエストが偽陽性を含む 500 番台をあげる たびにアラートしていてはオ オカミ少年になりかねない → サービス異常を緩く検知する意図でバーンレートアラートを利用 リリース速度を最大化するような エラーバジェットの利用はまだまだ先になりそう
エラーバジェットを導入しみて初めてわかる難しさ • 適切なエラーハンドリングができていないことで不要な 500 番台のステータスコードが挙がっていた → エラーバジェットを枯渇させる原因となっていて、本来の使い方までの道のりはまだまだ 今回の取り組みを通しての学び • サービスがこのような現状であることは、今回の取り組みがなければ気づくことができなかった
→ まずは流行ってみる精神で 信頼性も含めたソフトウェア品質を向上するきっかけを得ることができた まとめと学び
CREDITS: This presentation template was created by Slidesgo, and includes
icons by Flaticon, and infographics & images by Freepik Thanks! 13 @pHaya72 @t_hayashi