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
110
エラーバジェット枯渇の原因 - 偽陽性との戦い -
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
1
490
オブザーバビリティと開発優先度との向き合い方
phaya72
4
700
Cloud Service Mesh への期待が止まらない!!
phaya72
2
1.1k
とあるソフトウェアエンジニアの小さく始めるオブザーバビリティ
phaya72
2
340
OpenTelemetry Collector の Connectors って何者?
phaya72
2
1.7k
Cloud Service Mesh に触れ合う
phaya72
3
1.3k
Cloud Deploy と仲良くなりたい
phaya72
1
570
Cloud Run に日々感謝
phaya72
1
290
Other Decks in Technology
See All in Technology
ObservabilityCON on the Road Tokyoの見どころ
hamadakoji
0
240
君はPostScriptなウィンドウシステム 「NeWS」をご存知か?/sunnews
koyhoge
0
570
[JAWS-UG栃木]地方だからできたクラウドネイティブ事例大公開! / jawsug_tochigi_tachibana
biatunky
0
170
Ask! NIKKEIの運用基盤と改善に向けた取り組み / NIKKEI TECH TALK #30
kaitomajima
0
160
パフォーマンスとコスト改善のために法人データ分析基盤をBigQueryに移行した話
seiya303
1
110
バクラクの組織とアーキテクチャ(要約)2025/01版
shkomine
13
3.2k
Power BI は、レポート テーマにこだわろう!テーマのティア表付き
ohata_ds
0
140
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
120k
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
330
さいきょうのアーキテクチャを生み出すセンスメイキング
jgeem
0
350
A Hidden Pitfall of K8s DNS with Spring Webflux
musaprg
0
200
Grafanaのvariables機能について
tiina
0
200
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
6
240
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
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