SLI/SLO 完全ガイド
メディア統括本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、SRE としてチームへ参加した時に SLI/SLO をチーム内で浸透を行うまでのステップを具体的な資料やテンプレートを用いて説明した社内向け資料を、いくらか情報を制限してご紹介します。
なにかの役に立てば幸いです。
はじめに0. 心構え1. 信頼度の獲得Toil の削減コスト削減定例の出席2. アラート基盤の整理Datadog と Grafana の例アラート管理を IaC にする理由3. SLI/SLO の導入用語の説明CUJ (Critical User Journey)SLI (Service Level Indicator)SLO (Service Level Objective)エラーバジェット (Error Budget)バーンレート (Burn Rate)チームメンバーを探すメンバーとやる場合一人でやる場合最初はスモールスタートCUJ を決めるSLI を決めるレイテンシと可用性の SLI は別々にするか、一緒にするかSLO を決めるアラートの設定とエラーバジェットバーンレートGrafana + Cloud Monitoring でのクエリ例Datadog でのクエリ例Fast, Slow バーンレートについてアラートノイズ）リクエストが少ない時間帯で頻発するアラートの対処法4. SLO 文化醸成チーム内勉強会振り返り会の頻度振り返り会の内容振り返り会テンプレートカテゴリPdM やエンジニア以外への浸透浸透の定義ゴールまでを明確にPdM やエンジニア以外へ展開する際の勧誘ワード5. SLI/SLO の調整全 SLO 振り返りのやり方是正すべきをリスト化する使用例最初に確認することSLO を調整するか、SLI を調整するかSLI 調整ガイドSLI 調整時に必要なものパターン別 SLI 調整例外部API によるレイテンシ悪化レイテンシの調整は要注意概要不明パターン概要1. SLI に誤りがないか確認2. 該当エンドポイントのレイテンシを見る変更履歴を分かりやすくするActions yaml開始からゴールまでのフローTipsPrometheus パーセンタイルの意味終わりに
はじめに
みなさんはどのようにして「運用するサービスの体験が徐々に悪化していく」ことを防いでいますか？
インターネットサービスは月日が経てば DB のレコード数が増えてレイテンシが悪化し、もしくはサービスの成長でリクエスト数が増えて高負荷になりユーザー体験が損なわれているかもしれません。
SLI/SLO をやることでこれらの潜在的なサービスのデグレを品質として定量的な数値で可視化し、対応することができます。
この記事では、筆者が Embedded SRE として別チームに参加し、実際に SLI/SLO を導入した際の手順やノウハウをまとめています。
この内容を読むことで、あなたが別チームに Embedded SRE として参画したときに、スムーズに SLI/SLO を導入できるためのヒントを得られます。
0. 心構え
SLI/SLO の導入から、チームが自律的に SLI/SLO の運用が行われている状態に持っていくには半年以上かかる可能性があります。忍耐強さが必要不可欠です。
道中では SLI/SLO によるメリットを享受できる場面が出てきます。それを一度体験し、そのメリットをモチベーションにして維持することができます。例えば、潜在的なサービス品質の悪化を早期に発見できたり、エンジニア以外のチームメンバーと共通言語ができたりします。
1. 信頼度の獲得
別チームに参画していきなり SLI/SLO の話をしても、相手がその価値を見いだせず「工数ばかりかかる」と思われる可能性があります。
そこで、開発チーム・PdM やエンジニア以外、双方から「この人は頼りになる」「この人の取り組みに参加するとメリットがある」と認識してもらうためのフェーズが必要です。
Toil の削減
- Toil とは、繰り返し行われる退屈な作業や、インフラやコードのメンテナンスに伴う単純作業を指します。
- チームに合流したら、まずはインフラ構成やデプロイフローを把握し、すぐに削減できる Toil を探しましょう。
- 例:
- メンテナンスされていない IaC の掃除
- デプロイフローの高速化
- 過剰なリソース割り当ての見直し
Toil の削減は、開発メンバーの負担を減らし、余力を生み出すために非常に有効です。
「自分が入ったことで単調作業が減った」という実感を得てもらうことで、まずはチームの信頼を得やすくなります。
コスト削減
- コスト削減は、エンジニア以外にもわかりやすい成果として示すことができます。
- リソース過剰割り当ての見直しや不要なリソースの停止など、比較的簡単に取り組めるタスクでも大きなインパクトを出せる可能性があります。
定例の出席
- 毎日・毎週の定例会議や夕会に積極的に参加することで、チームとのコミュニケーションを図ることが重要です。
- いざ SLI/SLO の導入を本格的に始める段階で、エンジニア以外やエンジニアリングチームとの話し合いがスムーズに進むよう、早い段階から関係を築いておきましょう。
2. アラート基盤の整理
SLI/SLO を導入する前に、アラートの整備を行うことが望ましい です。
アラートが乱立している、あるいは複数のツールに分散しているなどの状態では、運用負荷が高くなるだけでなく、SLO 違反を検知しても適切な対応ができません。
- 「どのアラートが最重要か？」「ノイズになっているアラートはないか？」を整理する
- 運用コストが高すぎないよう、アラートの発火基準や通知先のグループを見直す
Datadog と Grafana の例
- Datadog
- UI が充実しており、ログベースのカスタム指標 (カスタムメトリクス) やレイテンシ・可用性の SLO をまとめて扱いやすい
- Grafana
- Prometheus や Cloud Monitoring など幅広いデータソースに対応
- Alertmanager を統合したり、Terraform 連携して IaC 化できるなど柔軟な構成が可能
アラート管理を IaC にする理由
- 変更履歴の管理
- Git などでアラートルールの変更をトラッキングできる
- 環境の一貫性
- 本番環境とステージング環境で同じ定義を使い回せる
- 再現性が高い
- 新規プロジェクトや新規チームにすばやく適用可能
アラートをコードで管理することで、チームでのレビューも容易になります。
3. SLI/SLO の導入
信頼度を獲得し、アラート基盤を整理してチームの運用がスムーズになったところで、いよいよ本丸となる SLI/SLO の導入に取りかかります。
ここでは主な用語と、導入のヒントを簡単に紹介します。
用語の説明
CUJ (Critical User Journey)
- ユーザーがサービス上で行うもっとも重要な操作の流れ を定義したものです。
- 例: EC サイトであれば「トップページ → 商品ページの閲覧 → カートに入れる → 決済完了」の一連の流れ
- CUJ をまず定めることで、どの指標を計測すべきか（SLI）を明確化します。
SLI (Service Level Indicator)
- サービスの品質を数値化した指標です。
- 例えば、API の応答時間、エラー率、正常系リクエスト率などが該当します。
- 「CUJ を満たすためにどの部分のメトリクスを どのように 計測するか」をチームで合意することが大事です。
SLO (Service Level Objective)
- SLI をどの程度達成すべきかを示す「目標値」です。
- 例えば、「99.9% のリクエストが 3秒以内にレスポンスを返す」など。
- この目標値によって、サービスがどのくらい安定しているか、もしくは改善の余地があるかを把握できます。
エラーバジェット (Error Budget)
- SLO の目標を 100% とせずに設定する「許容量」とも言える指標です。
- 例: 「SLO 99.9% → 30日間で合計 0.1% のエラーを許容する」
- エラーバジェットが枯渇したら追加開発をストップして信頼性回復にリソースを振り向ける、といったチームルールづくりが重要です。
バーンレート (Burn Rate)
- エラーバジェットが消費されていく速度 を示します。
- 例えば、30日間の目標に対してバーンレート 2 は「15日間でエラーバジェットを使い果たすペース」になります。
- 短期 (5分) と長期 (1時間) の複数ウィンドウでバーンレートを監視することで、突発的な障害も慢性的な劣化も検出しやすくなります。
チームメンバーを探す
一人で進めても良いですが、SLO を導入することに前向きなエンジニアのメンバーを探してみてください。
もし居なければ 1. で獲得した信頼をもとに打診してみると良いかもしれません。
メンバーとやる場合
自分に足りない箇所を埋めてくれるようなメンバーが好ましいです。
今回の例でいくと、視野が狭い＆リーダーシップが苦手なのでここを埋めてくれる人を探しました。
あと社内知名度が高い人だともっと良いかもです。
一人でやる場合
私が初めて SLO をやった、ドットマネーは一人でやりました。
まだメンバーに教えられるほど SLO に対して知識がなかったので一人で黙々と進め、導入と事業責任者を交えてエラーバジェット枯渇時の動き方まで決めました。
一人で進め、徐々にエンジニア内に浸透させていく、という流れもアリだと思います。
最初はスモールスタート
CUJ から SLO の導入まで、最初から PdM, エンジニア以外を巻き込む必要はありません。
サーバーチーム内でまずは SLI/SLO の感覚を掴むことが重要です。
サーバーチームである程度運用ができるようになり、そこで得られたメリットをもとにエンジニア以外へ展開していくのが効果的です。
CUJ を決める
最初は簡単なものから始めるのが良いでしょう。
例えば、ログイン API のような基本的な機能から始めるのがおすすめです。
いきなりたくさんの CUJ を決める必要はありません。最初は 3個程度でも十分です。徐々に増やしていけば良いでしょう。
SLI を決める
SLI の取得先としては、ロードバランサーのログを使用するのがベストです。
これによりユーザーに最も近い位置でのメトリクスを取得できます。
LB のログの取得が難しい場合は、バックエンドが出力するメトリクスを使用しても構いません。
SLI を決める際は、curl などの自動化されたリクエストや悪意あるリクエストを除外できるようにすることが重要です。
そうしないと、実際のユーザー体験を反映しない数値になってしまう可能性があります。
レイテンシと可用性の SLI は別々にするか、一緒にするか
レイテンシと可用性の SLI を別々に設定するか、一緒に設定するかには、それぞれメリットとデメリットがあります。
| 別々 | 一緒 | |
|---|---|---|
| メリット | 別々なので原因特定と分析が用意 | 1つの SLO で全体のサービス品質を把握しやすい |
| デメリット | 管理する SLI が増える | 詳細な問題分析が難しくなる可能性がある |
個人的には、別々に設定することを推奨します。
問題の根本原因を特定しやすく、より細かな改善活動につなげやすいからです。また、レイテンシと可用性は異なる性質を持つため、別々に管理することでそれぞれに適した対策を立てやすくなります。
SLO を決める
Target SLO を決める際には、現段階の SLI で実現できそうな値に設定するのが良いでしょう。もしエラーバジェットがずっと 100% の状態が続くようであれば、その後徐々に調整していけば良いです。
SLI/SLO を整理するためのスプレッドシートを用意しました。
初期段階ではこれを利用して、チーム内で SLI と SLO の管理を行うことをおすすめします。
SLI 調査・整理用スプレッドシート
アラートの設定とエラーバジェットバーンレート
SLO の導入まで行えたらアラートを設定していきます。
アラートはエラーバジェットバーンレートに対して設定することをオススメします。
Cloud Monitoring と Datadog ではバーンレートに取り扱いの仕方が違います。
Cloud Monitoring
を利用し、値 1 であれば理想、> 1 ではルックバック期間中内にエラーバジェットが枯渇することを意味します。
Datadog
バーンレートを自分で計算する必要がありますが、Datadog の公式ドキュメントに表が乗っています。
Grafana + Cloud Monitoring でのクエリ例
Datadog でのクエリ例
Fast, Slow バーンレートについて
バーンレートは fast と slow の 2つの種類が存在します。
それぞれ下記の特徴があります。
- fast
- 5m などの短いルックバック期間でバーンレートを監視します。
- 主にリリース時の不具合、インフラ変更時のデグレ、外部 API のデグレを検知する目的があります。
- 具体的な話をするとリリース時に Graceful Shutdown がうまく動いていない場合、fast バーンレートが有効です。
- slow
- 1h などの長いルックバック期間でバーンレートを監視します。
- 主に fast の突発的なサービス品質悪化を検知するよりも徐々に悪化している（＝DBレコード数によるクエリのレイテンシ増加や、リリースした新機能コードの n+1 など）ことを検知することが目的です。
fast と slow を組み合わせた合成バーンレートアラート
Datadog の例では、5m(fast) と 1h(slow) を合成したアラートを利用しています。
5m と 1h で両方閾値に達した場合に発砲されるためアラートノイズの抑制になります。
しかし即時性のメリットがなくなります。
アラートノイズ）リクエストが少ない時間帯で頻発するアラートの対処法
深夜、早朝では分母となる合計リクエストが少なく、Bad リクエストの影響度が大きくなるためアラートが鳴りやすくなります。
この対処方法では上述した fast + slow の合成バーンレートアラートが有効ですが即時性のメリットがなくなってしまいます。
では、どうしたらいいでしょうか。
今回の例では
エラーバジェットが枯渇したとしても深夜帯に対応をする必要はないので営業時間外のバーンレートアラートをミュートにする
という方針を取っています。
エラーバジェット枯渇時はタイムラグを許容し、隔週の SLI/SLO 振り返り会でカバーしています。
妥協も大事です。
4. SLO 文化醸成
サーバーチーム内へ SLO 文化を醸成するためのステップは以下の通りです：
- SLI/SLO の基本的な概念と重要性について、チーム全体で勉強会を実施する
- 定期的な SLO レビュー会を設定し、チーム全体で参加する
- SLO 違反時の対応フローを確立し、チーム内で共有する
- SLO の改善に貢献したメンバーを称賛し、チーム全体で成果を共有する
- 新しい機能や変更を導入する際に、SLO への影響を考慮することを習慣化する
チーム内勉強会
まずはチーム内に浸透させるために勉強会、振り返り会をやっていきます。
エンジニア用、SLI/SLO 勉強会資料
masked
振り返り会の頻度
振り返り会の頻度は、週に1回では高頻度すぎて疲弊する可能性があります。
SLO の量とチームのリソース状況に応じて適切な頻度を設定することが重要です。
今回の事例では、2週間に1回の頻度で SLO レビュー会を実施しています。
これにより、短期的な変動にとらわれすぎず、かつ長期的なトレンドも把握できるバランスの取れた頻度となっています。
振り返り会の内容
振り返り会では以下の内容を扱うことをおすすめします：
- 各 SLO の現状確認：エラーバジェットの消費状況、バーンレートの確認
- SLO 違反があった場合の原因分析と対策の検討
- 新しい SLI/SLO の提案や既存の SLO の調整の検討
- SLO 改善のための施策の進捗確認
- チーム内での SLO に関する知識共有や疑問点の解消
具体的には、Grafana などのダッシュボードを確認しながら、エラーバジェットが枯渇しているものや、バーンレートが高いものを重点的に議論します。
また、前回のレビューで問題となっていた SLO の改善状況も確認します。これらの議論を通じて、チーム全体で SLO の重要性を理解し、サービスの品質向上に向けた継続的な改善活動を促進することができます。
振り返り会テンプレート
ここでは Wrike を利用した振り返り会テンプレートを紹介します。
重要な点は下記です。
- SLI/SLO名（もしくはエラーバジェット名）
- カテゴリ
- レイテンシ or 可用性
- タスク化の可否
- 外部要因などのどうしようもないときはタスク化は不要です
- エラーバジェット
- 振り返り会のタイミングで値を更新します
カテゴリ
必須ではないですが、最初から定義しておくことで数が増えたときに楽になるかもしれません。
今回のサービスの場合、SLO が120個あり、カテゴリごとにチーム分けをしてレビューをします。
PdM やエンジニア以外への浸透
PdM やエンジニア以外への浸透の目的は、SLI/SLO をサービス全体の共通言語として確立し、技術的な指標をビジネス上の意思決定に活用することです。
これにより、サービスの品質向上とビジネス目標の達成を同時に推進することができます。
そして、PdM やエンジニア以外への浸透ができると、エンジニア以外から称賛されるためサーバーチームのモチベーション向上にも繋がる可能性があります。
エンジニア以外への説得用資料
masked
浸透の定義
PdM やエンジニア以外が自主的に SLI/SLO を利用（発言）し、サーバーチームと議論できている状態とします。
具体的には、PdM やエンジニア以外がSLI/SLOの数値を理解し、それに基づいてサービスの改善提案や優先順位付けを行えるようになることを指します。
ゴールまでを明確に
「どのような状態になっていたら、PdM やエンジニア以外を引っ張ってこれて浸透できるか」を可視化します。
今回の例ではサーバーチームと仲が良いビジネス職のチームメンバーが居たため、この人に浸透させることでそこから広がっていくことを狙いました。
PdM やエンジニア以外へ展開する際の勧誘ワード
- SLI/SLOの導入により、サービス品質と顧客満足度の向上が期待できます。
- Amazonや Googleの研究によると、わずか0.1秒のレイテンシ改善が売上に大きな影響を与えることが分かっています。
- SLI/SLOを活用することで、障害対応時の判断材料となるだけでなく、長期的にはサービス品質の向上により障害頻度が減少し、PdM やエンジニア以外の方の時間的拘束も軽減されます。
- 一緒にサービスの信頼性を高め、ビジネス成果につなげていきましょう
実際にPdM やエンジニア以外へ説明を行った際に用いた資料を添付します。
masked
5. SLI/SLO の調整
品質改善を行っていく過程で常時エラーバジェットが 100% は健全な状態でないため、SLI/SLO を調整し、エラーバジェットがちょうど 0 になるように調整します。
これにより、サービスの品質向上と技術的挑戦のバランスを取ることができます。
全 SLO 振り返りのやり方
設定した SLO は 3ヶ月 または 6ヶ月の周期で見直しを行います。
これの目的は下記です：
- 品質を改善していくとエラーバジェットに余裕がある状態ができてしまうのでそれを是正する
- 設定した SLO が甘く、エラーバジェットに余裕がある状態を是正する
後述する vigil というツールを用いることで是正するべき SLO のリストを取得できます。
是正すべきをリスト化する
vigil というスクリプトで是正すべき SLO をエクセルファイルで出力することができます。
vigil が抽出する SLO は下記です：
- 指定した期間、エラーバジェットが n% を 1度も下回っていない、余裕がある SLO
- 指定した期間の 50% がマイナスのエラーバジェットになっている SLO
使用例
出力されたエクセルファイルをスプレッドシートなどに転記し、それぞれ議論を行います。
最初に確認すること
クエリが正しいか確認してください。
例えばそれぞれの Good/Total に BOT によるアクセスを除外しているかどうか、意図してはいないリクエストが除外されているか確認してください。
SLO を調整するか、SLI を調整するか
レイテンシの SLO では SLO の調整はしてはいけません。
クエリが正しいことを確認できたら可用性 SLO では SLO の調整を行います。
レイテンシ SLO では SLI を調整します。
SLI 調整ガイド
SLI 調整時に必要なもの
- 既存の閾値
- SLO
- SLI（レイテンシ、可用性であればステータスコードなど）
- 該当の SLI のグラフ
パターン別 SLI 調整例
外部API によるレイテンシ悪化
概要
サービスが外部依存している API 側で一時的にデグレが発生しました。その影響でサービスの SLI が悪化、エラーバジェットが枯渇しましたがその後は安定しています。
これの対応は不要です。
不明パターン
概要
SLO 追加時に設定した SLI が厳しく、定常的に SLO を下回っています。
SLO を新しく追加したときなどによく起こります。
この場合 SLI を再確認する必要があります。
1. SLI に誤りがないか確認
現状の SLI を確認します。
この例の場合、max 1600 の閾値だけではなく SLI として利用する条件が間違っていないかも確認してください。
例えば、レイテンシ SLO であれば 2xx のレスポンス且つ 0 - 1600ms のレスポンスを Good として期待していますが、status の条件式が間違って 5xx も含まれてしまっているなどがありえます。
レイテンシ SLO の場合、SLO は 99.9% で固定しているため、SLO を変更することはできません。 SLI のレイテンシ側を調整してください。
2. 該当エンドポイントのレイテンシを見る
SLI の条件式に定義されているエンドポイントから Grafana などを用いて、レイテンシを観察します。
デフォルトでは Group by function が平均(mean)になっているので 99th percentile にします。
SLI では 1600ms までがレスポンスタイムが Good となっていますが、実際には日中の p99 の平均値を取ると 1600ms を超えていることが分かります。
そのため 1600ms 以上に設定することが良いと分かります。
最初から最適値を見つけるのは難しいため 1800ms に変更し、エラーバジェットが常時 100% になるような場合は 1700ms にして厳しくする。という手法を取ることができます。
変更履歴を分かりやすくする
SLO が大きく動いた際に原因が分からない場合、SLI/SLO を調整した可能性があります。
それを追従しやすいために変更履歴は分かりやすくする必要があります。
GitHub Actions を利用して、SLI/SLOの変更が行われた際に自動的にコミットメッセージにタグを付けるなどの工夫をすることで、変更履歴を追跡しやすくなります。
これがアラートや SLI/SLO を IaC に落とし込む理由の 1つです。
Actions yaml
レイテンシの調整は要注意
レイテンシは SLI のレスポンスタイムを調整することをオススメします。
Target SLO を調整することでも調整することができますが、ある人は SLI のレスポンスタイムで調整し、別の人は Target SLO を調整するかもしれません。
こういった作業のばらつきを発生させないように「レスポンスタイムで調整する」ということを前もって決めておくと良いでしょう。
これにより、チーム内での一貫性が保たれ、SLI/SLOの管理がより効率的になります。
開始からゴールまでのフロー
Tips
Prometheus パーセンタイルの意味
バケットはコードを見ると下記のようになります。
25, 50, 100, 200, 400, 800, 1600, 3200, 6400
100個のリクエストがバケットに分布している例です。
この分布を図で表すと、以下のようになります。
p99を求めるには、まず、各バケットのリクエスト数を累積していきます。
100個のリクエストの99%は、99個のリクエストに相当します。累積リクエスト数が99以上になる最初のバケットは、バケット7（800ms - 1600ms）です。つまり、p99は1600msになります。
これは、100個のリクエストのうち、99%のリクエストが1600ms以下で処理されたことを意味します。
終わりに
SLI/SLO の導入少しでも役に立てれれば幸いです。