LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

SLI・SLO・SLA — 3つの指標が担う役割の違い

SLI・SLO・エラーバジェットとは、サービスの信頼性を定量的に管理し、開発速度と品質のバランスを保つためにSRE（Site Reliability Engineering、Googleが提唱した信頼性エンジニアリングの実践手法）が用いる指標体系を指します^*1。SLIは測定値、SLOは目標値、エラーバジェットはSLOから導かれる「許容できる不信頼性の残量」という関係にあります。

Googleが公開する「Site Reliability Engineering」（通称SRE Book）は、SLIを「提供されるサービスレベルのある側面を注意深く定義した定量的な尺度」と定義しています^*1。リクエストのレイテンシ・エラー率・スループット・可用性など、サービスの健全性を数値で表したものがSLIです。

SLOはこのSLIに対する目標値・目標範囲です。SRE Bookは「SLOはSLIによって測定されるサービスレベルの目標値または目標範囲である」と説明します^*1。SLIが「今どうなっているか」を示すのに対し、SLOは「どうあるべきか」という基準を定めます。

SLAはユーザーとの契約であり、SLOの達成・未達に応じた結果（違約金や利用料の返金など）を伴う点がSLOとの決定的な違いです。SRE Bookは「SLOが満たされなかった場合に何が起こるかを問えば、明示的な結果がなければそれはSLOと考えてよい」とSLOとSLAの見分け方を示しています^*1。つまり違約や補償の対象になっているかどうかが、SLOとSLAを分ける実務上の境界線です。

SLIの選び方と計測方法

SLIを設計する際、SRE Bookの実践編である「The Site Reliability Workbook」（SRE Workbook）は「SLIは2つの数値の比率、すなわち良いイベント数÷総イベント数として扱うことを推奨する」としています^*2。具体例として、成功したHTTPリクエスト数を総HTTPリクエスト数で割る、あるいは100ミリ秒以内に完了したgRPCコール数を総gRPCリクエスト数で割る、といった形が挙げられています^*2。

SRE Workbookはさらに、SLIを「仕様（specification）」と「実装（implementation）」に分けて考えることを提案します。仕様は「ユーザーにとって重要だと考えられるサービス成果の評価」であり、実装は「その仕様と測定方法」を指します^*2。この分離により、計測手段を後から変更してもSLOの意図を保ったまま指標を運用できます。

代表的なSLIの分類は可用性・レイテンシ・スループット・正確性などに整理できます。可用性は「リクエストが正常に処理された割合」、レイテンシは「一定時間内に応答が返った割合」を測ります。どのSLIを選ぶかは、ユーザーが実際に体感する品質のどの側面を守りたいかで決まります。

SLIの選定にあたって、SRE Workbookは「最初のSLIについては、エンジニアリング作業が最小限で済むものを選ぶ」ことを勧めています^*2。Webサーバーのアクセスログなど、既存のデータソースから抽出できる指標を優先し、新規の計測基盤を最初から作り込まない進め方です。この点は監視基盤そのものの構築（オブザーバビリティ整備）とは異なる工程であり、既存のログ・メトリクス収集の仕組みを土台にSLIを定義する作業が中心になります。

SLOの決め方 — 現状把握から合意形成まで

SLOを決める作業は、目標値を一方的に定めるのではなく、複数の立場の合意を積み上げる進め方になります。SRE Workbookは「完璧な信頼性は誤った目標である」と述べ、完璧な達成を目標に置くこと自体を戒めています^*2。完璧な可用性を目指すほど開発の柔軟性が失われるためです。

SLOの初期値を決める起点として、SRE Workbookは「過去4週間の実際の測定値を初期SLOの基礎として使う」ことを推奨しています^*2。理想値から逆算するのではなく、現状の実測データから出発することで、達成不可能な目標を掲げるリスクを避けられます。

合意形成の対象は、プロダクトマネージャー・開発チーム・SREの三者です。SRE Workbookはこの三者が次の点に同意する必要があるとしています^*2。第一に、そのしきい値がユーザーにとって十分であること。第二に、SLOが通常の運用状況下で防御可能であること。第三に、組織がエラーバジェットを意思決定に使うことにコミットしていることです^*2。

この合意形成を欠くと、SLOは数値として存在するだけで、実際のリリース判断や優先順位付けに使われない「形だけの目標」になります。SLOの決め方は技術検討であると同時に、部門間の期待値調整というプロセスでもあります。

エラーバジェットの考え方とリリース判断への使い方

エラーバジェットとは、SLOから逆算される「その期間内に許容できる不信頼性の残量」を指します。SRE Bookは「この2つの数値の差が、その四分期に残っている『不信頼性』の予算である」と説明しています^*3。たとえば成功率のSLOを99.9%と定めた場合、成功率の上限からSLOを差し引いた0.1%がエラーバジェットに相当し、期間中に許容されるエラー件数として扱われます^*2。

エラーバジェットが果たす中心的な役割は、リリースの継続・停止を判断する客観的な基準を提供することです。SRE Bookは「SLOが満たされる限り、リリースは継続できる」という基本ルールを示す一方、「SLO違反がエラーバジェットを消費するほど頻発した場合、追加のテストや開発に資源を投じる間、リリースは一時的に停止される」と述べています^*3。

この仕組みが機能すると、開発チームは自らの判断で速度を調整するようになります。SRE Bookは「バジェットがほぼ枯渇すると、プロダクト開発チーム自身がより多くのテストや低速なリリースを求めるようになる」としており^*3、信頼性の管理をSREチームだけの責務にせず、開発チームが自律的にブレーキをかける文化を作る点がエラーバジェットの本質です。

エラーバジェットを運用に組み込むには、バジェットの消費速度を可視化し、枯渇が近づいた段階でリリース頻度を落とす・機能追加より安定化を優先するといったルールをあらかじめ決めておく必要があります。この運用ルールの設計こそが、SLI/SLO設計を単なる指標定義で終わらせず、実際の意思決定に使える仕組みにする工程です。

SLI/SLO設計を内製で進める難易度

SLI/SLO設計を内製で進めるには、SREの実践知識に加えて、既存システムのログ・メトリクス構造を理解した人材が必要です。具体的には、どのイベントを「良い」と定義するかの業務要件理解、既存の監視基盤からSLI計測用のクエリを組む実装スキル、SLOの合意形成をリードするファシリテーション能力の3つが求められます。

SLOのしきい値設定を誤ると、実務上の影響は小さくありません。しきい値を厳しく設定しすぎると、些細な変動でもエラーバジェットが枯渇し、リリースが不必要に止まる事態が起こります。逆に緩すぎるSLOは、ユーザーが実際に不満を感じる水準を下回っていても「達成」と表示されてしまい、信頼性目標としての意味を失います。

また、SLOの合意形成は一度きりの作業ではありません。トラフィックパターンやシステム構成が変わればSLIの計測方法もSLOのしきい値も見直しが必要になり、継続的な運用体制が前提になります。プロダクトマネージャー・開発チーム・運用チームの間で定期的にエラーバジェットの消費状況をレビューする場を設けなければ、SLOは形骸化しやすい仕組みです。

専門パートナーに設計を依頼した場合との違いは、SRE領域での設計経験に基づいて、業種・システム特性に応じたSLI候補の選定パターンやSLOレビューの運用フォーマットを最初から使える点にあります。内製で一から試行錯誤する場合は、SLI選定の初期段階でやり直しが発生しやすく、運用ルールが定着するまでに複数回のレビューサイクルを要します。

外注する場合の委託範囲と発注側の準備

SLI/SLO/エラーバジェットの設計を外注する場合、委託範囲は主に4つの工程に分けられます。第一に既存システムのログ・メトリクス調査によるSLI候補の抽出、第二にステークホルダーとのワークショップを通じたSLO合意形成の支援、第三にエラーバジェットの消費を可視化するダッシュボード設計、第四にリリース判断ルール（バジェット消費時の対応フロー）の文書化です。

発注側が準備しておくべき情報としては、現行の監視基盤で取得できているログ・メトリクスの一覧、過去のインシデント発生履歴、リリース頻度と承認フローの現状、SLOの合意形成に参加すべき部門・担当者の特定が挙げられます。これらが整理されているほど、委託先はSLI候補の絞り込みを早く進められます。

委託範囲を決める際は、SLI/SLOの「設計」と、その後の日々の監視・アラート運用を分けて発注することもできます。設計だけを外部パートナーに依頼し、運用フェーズは社内チームが担う形にすれば、自社にSREのノウハウを蓄積しながら初期設計の手戻りを避けられます。

まとめ — 信頼性目標設計を進める3つの軸

本稿では、SLI・SLO・エラーバジェットという3つの信頼性指標の役割の違いと、外注を検討する際の委託範囲・発注準備を整理しました。要点を3つに集約すると次の通りです。第一に、SLIは測定値、SLOは目標値、SLAは契約であり、この階層構造を混同しないことが設計の出発点です。第二に、エラーバジェットはSLOから導かれる「許容できる不信頼性の残量」であり、リリース継続・停止を判断する客観的な基準として機能します。第三に、外注する場合はSLI候補抽出・SLO合意形成・バジェット可視化・運用ルール文書化の4工程に分けて委託範囲を切り分け、発注側は既存の計測状況とインシデント履歴を事前に整理しておくことが成果を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Site Reliability Engineering – Service Level Objectives」（https://sre.google/sre-book/service-level-objectives/）
2. *2　出典：Google「The Site Reliability Workbook – Implementing SLOs」（https://sre.google/workbook/implementing-slos/）
3. *3　出典：Google「Site Reliability Engineering – Embracing Risk」（https://sre.google/sre-book/embracing-risk/）

Tweet