応答時間の目標を2秒に置くと94.28%が収まりました。1秒に厳しくすると65.11%まで落ちます。
水準の側も同じです。99%なら月に7.2時間止まってよいのに、99.99%だと4分しかありません。
同じ応答時間の分布に対して、目標の線を変えて数えました。線の位置で結果が大きく動きます。
SLO / SLI の目標値をどこに置くかで何が変わるのかを、実際に走らせて数えました。使ったのは裾の重い応答時間10万件です。
同じ分布に対して、1秒から5秒まで線の位置を変えて、収まった割合を数えています。
for (const t of [1000, 1500, 2000, 3000, 5000]) {
const ok = lat.filter((x) => x <= t).length;
const rate = (ok / N) * 100;
// rate が、その目標に収まった割合
}
目標(この時間以内) 収まった割合 超えた件数
1000ミリ秒 65.11% 34,887件
1500ミリ秒 86.52% 13,485件
2000ミリ秒 94.28% 5,716件
3000ミリ秒 98.35% 1,647件
5000ミリ秒 99.42% 581件
上の表を見てください。2秒以内という線なら94.28%が収まります。1秒にすると65.11%です。
1秒と2秒の差は倍ですが、収まる割合は65.11%と94.28%です。超える件数は34,887件と5,716件で、6倍の開きがあります。
つまり目標の値を決めることは、対処すべき件数を決めることです。1秒を目指すなら3万件を相手にします。
目標 許される割合 月10万件での件数 30日での停止時間 99% 1.00% 1,000件 7.2時間 99.5% 0.50% 500件 3.6時間 99.9% 0.10% 100件 43分 99.95% 0.05% 50件 22分 99.99% 0.01% 10件 4分
99%なら月に7.2時間まで止まってよいことになります。99.99%だと4分しかありません。
9を1つ増やすたびに、許される時間は10分の1になります。気づいて直すまでの時間が、そのまま入る枠です。
線を1秒に寄せると、対象が6倍に増える。
An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.原文Google SRE Book「Service Level Objectives」 この内容の有効期限2027-02-18
SLIは測る物差し、SLOはその物差しで引く線です。物差しを決めないと、線も引けません。
SLO / SLI は対になった言葉です。SLIが測る物差し、SLOがその物差しで引く線になります。
Googleの資料は、SLIは提供される水準のある側面についての、注意深く定義された量的な尺度であるとしています。
前の節で使った「応答時間」がこれにあたります。数えられる形になっていることが条件です。
同じ資料は、SLOはSLIで測られる水準に対する目標の値、または値の範囲であるとしています。
前の節でいえば「2秒以内」が線です。その線で94.28%という数字が出て初めて、判断ができるようになります。
外部との約束はさらに別です。資料はSLAは、そこに含まれるSLOを満たすこと、または満たさないことの結果を含む、利用者との明示的または暗黙の契約であるとしています。
つまり結果が伴うかどうかが分かれ目です。社内の目標には結果が伴わないことが多く、その場合はSLOにとどまります。
同じ資料は、指標が多すぎると大事なものに適切な注意を払うのが難しくなり、少なすぎると仕組みの重要な挙動が調べられないまま残るとしています。
応答時間は種を固定した乱数で作っています。実際のシステムを測ったものではありません。ここで見せているのは、線の位置を変えると対象の件数がどう動くかという関係です。分布そのものの測り方はレイテンシ監視の記事で扱っています。
An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided.原文Google SRE Book「Service Level Objectives」 この内容の有効期限2027-02-18
いまの実力をそのまま目標にすることです。維持するために無理を続ける形になります。
SLO / SLI を決めるとき、いちばん手軽なのはいまの数字をそのまま目標にすることです。ここに落とし穴があります。
Googleの資料は、仕組みの利点と限界を理解することは欠かせないとしたうえで、考えずに値を採ると、目標を満たすために並外れた努力を要する仕組みを支え続けることになりかねないと述べています。
前の節の分布でいえば、いまが94.28%だから94%を目標にするという決め方です。改善の余地も、下げてよい余地も見えなくなります。
4番目まで進めてください。99.99%を掲げても、気づくまでに10分かかるなら守れません。許されるのは4分です。
指標の計算を凝りすぎると、逆に見えなくなります。資料もSLIの込み入った集計は、仕組みの性能の変化を覆い隠すことがあり、理解するのも難しくなるとしています。
前の節で使ったのは2秒以内に収まった件数の割合だけです。単純ですが、線を動かした効果ははっきり出ました。
いまの実力ではなく、必要な水準から決める。
Complicated aggregations in SLIs can obscure changes to system performance, and are also harder to reason about.原文Google SRE Book「Service Level Objectives」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る