SLA・SLO・SLIの違い ― エラーバジェットとは

クラウドの品質の約束を調べたり、運用で監視の目標を決めたりすると、SLA・SLO・SLIの3つが並んで出てきます。SLIはサービスの良さを測った値で、SLOはそのSLIの目標値です。SLAは、SLOを守れなかったときの返金などの取り決めまで含めて、顧客と結ぶ約束です。

3つの略語は、どれもService Levelで始まります。最後の1字は、指標のIndicator、目標のObjective、合意のAgreementの頭文字です。測る値のSLIには、稼働率や応答時間をよく使います。

Googleの『Site Reliability Engineering』は、3つを上の表のように分けています。この本は、運用をソフトウェアの手法で設計するSREの考え方をまとめたものです。以下の定義も、この本に合わせています。

SLI（Service Level Indicator）は、サービスがどれだけうまく動いているかを数で表したものです。よく使うのは、応答の速さ、エラーの割合、1秒あたりに処理できる量です。

『The Site Reliability Workbook』は、SLIを「良い件数÷全体の件数」の割合で表すことを勧めています。たとえば、成功したリクエストの数を、受け取った全リクエストの数で割ります。割合にしておくと、どのSLIも0%から100%の同じ目盛りで表せます。

応答の速さは平均でなくパーセンタイルで測る

応答時間の平均は、ごく一部のとても遅い応答を隠してしまいます。そこでSREでは、応答を速い順に並べて、ある順位の値を見ます。99パーセンタイルは、100件のうち99件がその時間までに返った、という値です。

SRE本は、99や99.9パーセンタイルは最悪に近い値を、50パーセンタイルは典型的な値を表すと説明しています。SLIにするときは、「300ミリ秒以内に返ったリクエストの割合」のように、割合の形に直して使います。

SLO（Service Level Objective）は、SLIが満たすべき値や範囲です。SLOは、目標値と、その値を測る期間をセットで決めます。「30日間で、成功したリクエストの割合が99.9%以上」のような形です。

期間には、直近の28日のように毎日ずらしながら測る方法と、暦の月で区切る方法があります。ワークブックは、ずらしながら測る場合は週の整数倍の期間を勧めています。30日だと、期間に入る週末が4回のときと5回のときがあり、週末の利用が多いサービスでは比べにくくなるためです。

SLAの中のSLOとSREのSLO

SLAを組織と顧客との間の合意文書と考えると、その中のSLOは、顧客と合意する目標値に当たります。

SRE本のSLOは、顧客と約束しない社内の目標も含みます。SRE本は、Google検索には一般向けのSLAが無いと書いたうえで、SLAの有無に関係なくSLIとSLOを決める価値があると述べています。どちらも「SLIで測る値の目標」である点は同じで、違うのは顧客との約束に入っているかどうかです。

SLA（Service Level Agreement）は、サービスを提供する側と顧客との間で、サービスの水準を約束する合意です。SRE本は、SLAを、含まれるSLOを守れたとき・守れなかったときの結果まで決めた契約と説明しています。結果の例は、返金や違約金です。

SLOとSLAの見分け方として、SRE本は「SLOを守れなかったら何が起きるか」を問うよう勧めています。はっきりした結果が決まっていなければ、ほぼ確実にSLOだとしています。

SLAはSLOより緩く置く

社内のSLOは、顧客に約束するSLAより厳しく置きます。SRE本は、利用者に示す値より厳しい社内の目標を持つことで、問題が外から見える前に対応できると説明しています。SLOを割った時点で手を打てば、SLAの返金の線までにまだ余裕があります。

図の例では、SLAが99.0%、SLOが99.5%、30日間に実際に測ったSLIが99.8%です。SLIはSLOを上回っているので目標は守れていて、SLAの線にも届いていません。SLOと100%の間の幅が、次の節で説明するエラーバジェットです。

エラーバジェットは、1からSLOを引いた値です。SLOが99.9%なら、エラーバジェットは0.1%になります。100%を目指さず、この量までは失敗してよいと先に決めておく考え方です。

ワークブックの例では、4週間に100万件のリクエストを受けるサービスのSLOが99.9%です。このとき、その4週間には1,000件まで失敗が許されます。前の節の図の場合、エラーバジェットは0.5%です。そのうち使った分は、実測値が100%に届かなかった0.2%で、残りは0.3%です。

時間に直すこともできます。30日は43,200分なので、99.9%のエラーバジェットは43,200×0.001で43.2分、つまり43分12秒です。稼働率ごとの停止許容時間の一覧は、可用性とSLAの記事の停止許容時間の表にあります。

次の計算機で、SLOの値と期間、期間中のリクエスト数を選べます。エラーバジェットを、許される失敗の件数と、全面停止に換算した時間の2つで表示します。

SLOの9が1つ増えるごとに、エラーバジェットは10分の1になります。99.99%で7日なら、全面停止に換算して約1分しか止まれません。28日と30日では期間が2日違うので、99.9%でも40分19.2秒と43分12秒に分かれます。

開発チームは新機能を早く出したいと考え、運用チームはサービスを安定させたいと考えるので、両者はぶつかりがちです。SRE本は、エラーバジェットを、両方が同じ数字で判断するための道具として説明しています。エラーバジェットが残っている間はリリースを進め、使い切ったらリリースを止めて信頼性を上げる作業に回します。

ワークブックが例に挙げる方針は、次のような決まりです。

• 直前の4週間でエラーバジェットを超えたら、重大な不具合とセキュリティの修正のほかはリリースを止める
• SLOを満たす状態に戻るまで、止めたままにする
• 1回の障害で4週間分のエラーバジェットの20%を超えて使ったら、原因を振り返る文書を書く

リリースを止めるのは、変更が障害の大きな原因だからです。ワークブックは、この方針がSLOを外したことへの罰ではないとも書いています。リリースを自動で進めるCI/CDのパイプラインも、エラーバジェットが残っているかどうかで止める判断ができます。

エラーバジェットの減る速さを通知に使う方法は、オブザーバビリティの記事で説明しています。

• Google「Site Reliability Engineering」Chapter 4 Service Level Objectives
• Google「Site Reliability Engineering」Chapter 3 Embracing Risk
• Google「The Site Reliability Workbook」Chapter 2 Implementing SLOs
• Google「The Site Reliability Workbook」Appendix B Example Error Budget Policy