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
SLOは何を実現するのか / What does SLO achieve?
Search
ymotongpoo
July 27, 2023
Technology
2
360
SLOは何を実現するのか / What does SLO achieve?
ymotongpoo
July 27, 2023
Tweet
Share
More Decks by ymotongpoo
See All by ymotongpoo
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
9
1.6k
信頼性を支えるテレメトリーパイプラインの構築 / Building Telemetry Pipeline with OpenTelemetry
ymotongpoo
9
5.8k
オブザーバビリティのマクロからミクロまで / Observability from macro to micro
ymotongpoo
13
6.3k
テレメトリーシグナルの相関、してますか? 第一原理からのデバッグを支える計装 / Do you utilize telemetry correlations?
ymotongpoo
4
740
OpenTelemetryのここ4年の流れ / OpenTelemetry in last 4+ years
ymotongpoo
17
4.5k
信頼性目標とシステムアーキテクチャー / Reliability Objective and System Architecture
ymotongpoo
18
9.3k
継続的プロファイルによる大規模アプリケーションの性能改善 / Improving massive application clusters with continuous profiling
ymotongpoo
0
350
Goのメモリ管理 / Memory management in Go
ymotongpoo
11
5.8k
SREの理念と原則〜SREの「人間的」側面 / SRE from humanism
ymotongpoo
1
1k
Other Decks in Technology
See All in Technology
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
150
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
160
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
150
Reading Code Is Harder Than Writing It
trishagee
2
110
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
130
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
7.1k
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
1
220
現場で役立つAPIデザイン
nagix
35
13k
Active Directory攻防
cryptopeg
PRO
7
4.5k
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
150
コンテナサプライチェーンセキュリティ
kyohmizu
1
110
Goで作って学ぶWebSocket
ryuichi1208
3
2.3k
Featured
See All Featured
Bash Introduction
62gerente
611
210k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
For a Future-Friendly Web
brad_frost
176
9.5k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
250
RailsConf 2023
tenderlove
29
1k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Fireside Chat
paigeccino
34
3.2k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Documentation Writing (for coders)
carmenintech
67
4.6k
Transcript
SLOは何を実現するのか Forkwell Library #28 SLO サービスレベル⽬標 2023/07/25 19:35-20:05 ⼭⼝能迪 (@ymotongpoo)
1
どしどし質問をお待ちしております 2
⼭⼝ 能迪 Developer Relations Engineer Google 3 @ymotongpoo @ymotongpoo
SRE文脈でのSLO 4
SREについて SRE とは本番システムを信頼性高く開発・運用するための一 連のプラクティスと心構え、および職務を指します。 5
信頼性に基づいた開発と運用 6 コンセプト ビジネス 開発 運用 市場 全部署が 信頼性を基準に ビジネスのプロセス
信頼性指標の計測 暗黙的‧明⽰的な期待に応えているから、ユーザーは満⾜する。 7 期待 (⽬標値) 指標
信頼性(Reliability) The probability that [a system] an item will perform
a required function without failure under stated conditions for a stated period of time. (システムが)求められる機能を、定められた条件の下で、定められた期間に わたり、障害を起こす ことなく実⾏する確率 P. O'Connor and A. Kleyner, Practical Reliability Engineering, 5th edition: Wiley, 2012. 8
サービスレベル指標(SLI)とサービスレベル目標(SLO) ユーザーの満⾜度によく相関している指標とその⽬標 9 SLO SLI
信頼性指標の元データ サービスの性質による典型的な信頼性指標の元データ • リクエスト/レスポンス 可用性、レイテンシー、品質 • データ処理 カバレッジ、正確性、鮮度、スループット • ストレージ
スループット、レイテンシー 監視システムは、多くの潜在的な SLI を捉える可能性がありますし、そうあるべきです が、ほとんどはそのままでは SLO を定義するのには使えません。 10
サービスレベル指標(SLI)の定義 次の式のように、定量的かつ慎重に定義します。 可⽤性の場合の例 • 良いイベント: HTTPステータスコードが 2xx、3xx、4xxのレスポンス • 有効なイベント: 全レスポンス
11 SLI : 良いイベント 有効なイベント × 100%
サービスレベル指標(SLI)の共有 組織内で共通認識を持つために⾔語化する 12 SLI の種類: 可⽤性 SLI の仕様: CheckoutService へのリクエストに対するすべてのレスポンスのうち、
HTTP レスポンスコード 2xx、3xx、4xx を返すもの (=良いレスポンス) の割合。 ただし 429 を除く。 SLI の実装: Web アクセスログから HTTP レスポンスコードを特定する
サービスレベル目標(SLO)の定義 SLIの⽬標値。計測期間も定義する必要がある。 • SLI: CheckoutService の良いレスポンスの割合 • SLO: CheckoutService の過去28⽇間の良いレスポンスが99.9%
13
サービスレベル目標(SLO)の共有 SLIと合わせてSLOも共有する 14 SLI の種類 : 可⽤性 SLI の仕様 :
CheckoutService へのリクエストに対するすべてのレスポンスのうち、 HTTP レスポンスコード 2xx、3xx、4xx を返すもの (=良いレスポンス) の割合。 ただし 429 を除く。 SLI の実装 : Web ログから HTTP レスポンスコードを特定する SLO : 過去 28 ⽇間の CheckoutService のレスポンスのうち 99.9% が 良いレスポンスでなければならない 根拠 : 過去に0.1%までのエラーであれば顧客問い合わせがなかった
エラーバジェット SLOが決まるとエラーバジェット(許容できるエラーの量)が決まる ⇨ 不具合が発⽣すると、エラーバジェットを消費することになる エラーバジェットを監視することでサービスの余裕がわかる 15 残りのエラーバジェット 0.1% = 100%
- 99.9%
バーンレートアラート バーンレートが急な場合ほど早く知らせる 16 エラーバジェット 時間 EB 100% (SLI 0.1%) 28
d 想定通りの EB の消費 =バーンレート 1 想定の 2 倍速の EB の消費 =バーンレート 2 14 d 想定の 7 倍速の EB の消費 =バーンレート 7 4 d
ポリシーを設定し更にEBを活用 ➔ しきい値 1: ⾃動アラートが SLO の危険を SRE に通知します ➔
… ➔ しきい値 3: SRE が、SLO を守るためには助けが必要と結論付け、開発者に エスカレーションします ➔ しきい値 4: 30 ⽇間のエラーバジェットを使い切っても根本原因は⾒つかっ ていません。機能リリースは停⽌され、開発チームはより多くのリソースを 割り当てます ➔ しきい値 5: 90 ⽇間のエラーバジェットを使い切っても根本原因は⾒つかっ ていません。SRE は経営陣にエスカレーションを⾏い、安定性のためのエン ジニアリング業務により多くの時間を確保します 17
信頼性に基づいた開発と運用 18 コンセプト ビジネス 開発 運用 市場 SLOを基準に 客観的に判断可能 ビジネスのプロセス
Four Keysとの比較 19
Four Keys (2014〜2017年) 20 デプロイ頻度 変更リードタイム サービス復旧時間 変更障害率 速度 安定性
ソフトウェアデリバリーパフォーマンス
Four Keys はどのタイミングの指標か 障害〜復旧 運⽤ 開発〜デプロイ • デプロイ頻度 • 変更リードタイム
• 変更障害率 • サービス復旧時間 安定時のパフォーマンスは?
「組織のパフォーマンス」再考 ソフトウェアデリバリーパフォーマンス ≠ サービス品質 • リリースされたソフトウェアにユーザーが満⾜しなければ意味がない • 2018年のSODRより組織の能⼒を捕捉するために可⽤性を5番⽬の指標に • 2022年のSODRでは発展させて「信頼性」を5番⽬の指標に
22
運用パフォーマンスとしての信頼性 障害〜復旧 運⽤ 開発〜デプロイ • デプロイ頻度 • 変更リードタイム • 変更障害率
• サービス復旧時間 SLOに基づき運⽤ • 信頼性
エラーバジェット:何を優先させるか? 24 バジェットを消費した場合 信頼性を優先する • ポストモーテムアイテムの優先順位付け • デプロイメントパイプラインの⾃動化 • モニタリングと可観測性の向上
• SRE のコンサルテーションが必要 バジェットが⼗分な場合 ベロシティを優先する • 予想されるシステムの変更 • ハードウェア、ネットワークなどの不可避的 な障害 • 計画的ダウンタイム • 危険な実験
運用パフォーマンスとしての信頼性 障害〜復旧 運⽤ 開発〜デプロイ • デプロイ頻度 • 変更リードタイム • 変更障害率
• サービス復旧時間 エラーバジェットに基づき運⽤ • 信頼性 SLO エラーバジェット バーンレート
どこから始めるのか SLO関連書籍をぜひ参照してみてください 26