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
520
オブザーバビリティと開発優先度との向き合い方
phaya72
4
710
Cloud Service Mesh への期待が止まらない!!
phaya72
2
1.1k
とあるソフトウェアエンジニアの小さく始めるオブザーバビリティ
phaya72
2
340
OpenTelemetry Collector の Connectors って何者?
phaya72
2
1.7k
Cloud Service Mesh に触れ合う
phaya72
3
1.4k
Cloud Deploy と仲良くなりたい
phaya72
1
590
Cloud Run に日々感謝
phaya72
1
300
Other Decks in Technology
See All in Technology
ユーザーストーリーマッピングから始めるアジャイルチームと並走するQA / Starting QA with User Story Mapping
katawara
0
220
2025-02-21 ゆるSRE勉強会 Enhancing SRE Using AI
yoshiiryo1
1
400
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
3
1.7k
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
7k
Active Directory攻防
cryptopeg
PRO
5
3k
深層学習と古典的画像アルゴリズムを組み合わせた類似画像検索内製化
shutotakahashi
0
180
ハッキングの世界に迫る~攻撃者の思考で考えるセキュリティ~
nomizone
13
5.3k
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
290
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
26
7.5k
The Future of SEO: The Impact of AI on Search
badams
0
220
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
130
Featured
See All Featured
Writing Fast Ruby
sferik
628
61k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
630
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
51k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Done Done
chrislema
182
16k
The World Runs on Bad Software
bkeepers
PRO
67
11k
A better future with KSS
kneath
238
17k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.8k
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