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
150
エラーバジェット枯渇の原因 - 偽陽性との戦い -
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
Pub/Sub vs Cloud Tasks - その違い、わかりますか?-
phaya72
1
130
OpenTelemetry SpanProcessor を Let's カスタマイズ!
phaya72
2
270
非同期処理でも分散トレーシングしたい!- OpenTelemetry × Pub/Sub -
phaya72
1
620
Vertex AI Experimentsの実態 - コードを辿った先にあったもの -
phaya72
2
1k
オブザーバビリティと開発優先度との向き合い方
phaya72
4
850
Cloud Service Mesh への期待が止まらない!!
phaya72
2
1.6k
とあるソフトウェアエンジニアの小さく始めるオブザーバビリティ
phaya72
2
430
OpenTelemetry Collector の Connectors って何者?
phaya72
2
2k
Cloud Service Mesh に触れ合う
phaya72
3
1.8k
Other Decks in Technology
See All in Technology
能登半島地震において デジタルができたこと・できなかったこと
ditccsugii
0
140
サイバーエージェント流クラウドコスト削減施策「みんなで金塊堀太郎」
kurochan
0
240
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
Adapty_東京AI祭ハッカソン2025ピッチスライド
shinoyamada
0
280
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
180
AWS Control Tower に学ぶ! IAM Identity Center 権限設計の第一歩 / IAM Identity Center with Control Tower
y___u
0
150
CoRL 2025 Survey
harukiabe
0
170
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
440
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
3
830
能登半島災害現場エンジニアクロストーク 【JAWS FESTA 2025 in 金沢】
ditccsugii
0
560
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
80k
BI ツールはもういらない?Amazon RedShift & MCP Server で試みる新しいデータ分析アプローチ
cdataj
0
110
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
514
110k
We Have a Design System, Now What?
morganepeng
53
7.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
970
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Fireside Chat
paigeccino
40
3.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Practical Orchestrator
shlominoach
190
11k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
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