SLI はサービスレベル指標の略で、サービスレベルの性質の計測量。
- リクエストのレイテンシ(レスポンスを返した時刻-リクエストを受信した時刻)
- エラー率(エラーになったリクエスト数/受信したリクエスト数)
- システムスループット(処理したリクエスト数/s)
これらの計測料は多くのサービスで使われるもので、生データを収集し、レート・平均・パーセンタイルに変換した値が SLI として使用されることも多い。
また可用性も重要な SLI で、これはサービスが利用できる時間の比率を表す。 具体的にはイールド(yield?)と呼ばれる、処理に成功した正常なリクエスト数の比率が多く使われる。 (データストレージシステムの場合は可用性と共にデータが長期間に渡って保持されている確立を示す耐久性も重要。)
100% の可用性を達成することは不可能だが、100% に近い可用性が達成されることはよくある。 これは可用性のパーセンテージに並ぶ 9 の数を使って表現する。 2 ナインズであれば 99%、5 ナインズ であれば 99.999%、Compute Engine は 3.5 ナインズで 99.95% の可用性。
SLO はサービスレベル目標の略で、SLI で計測される値の範囲を示す。
したがって SLO = SLI <= ターゲット(SLIによってはSLO = SLI >= ターゲットにもなる気がする…) もしくは SLO = 下限 <= SLI <= 上限 で表される。
適切な SLO を選択するのは難しい。 例えば外部に公開しているサービスの毎秒のクエリ数 (QPS) はユーザーの動向によって決まる値なので、これに対して SLO を設定することは現実的ではない。 一方でリクエストのレイテンシを平均 100ms 以下にする SLO は実現可能。
SLO を定義して公開するということはサービスの挙動に対する期待を設定するということ。 これを行うことでユーザーがサービスへ過剰な信頼を持ったりすることを防ぐ。
Google 内部で使用されている分散ロックシステムの Chubby のサービスダウンは非常に稀であったが、これに依存するサービスの責任者たちが Chubby は落ちることはないという仮定で Chubby に依存していた。 この依存を意識させるために SRE は SLO を達成している場合は意図的に Chubby を落とし、SLO を過度に超えないようにした。
SLA はサービスレベルアグリーメントの略で、ユーザーとの間で結ぶ契約を示す。 SLA は SLO が達成されなかった時の規約であり、これはビジネス的な側面を含む為 SRE はこの定義には関与しない。
たとえ SLA を定義していなくても SLO を達成することはユーザーの評判やビジネス収入に関わることなので、SLI と SLO を定義してその元手サービスを管理することには価値がある。
SLI の指標が多すぎる場合は本当に大切な指標への注意をそらしてしまい、少なすぎる場合はシステムの重要な挙動を検証できなくなってしまう。
例: 42頁〜43頁
これ以外にシステムレイヤーの指標として正確性がある。 正確性は SRE の責務外だが、システムの健全性の指標としては重要。
大体の指標のメトリクスは(Borgmon や Prometheus によって)サーバーサイドで収集するのが自然。 しかし、JavaScript の問題によるページが利用できるまでの遅延などのメトリクスはクライアント側で収集する必要がある。
大体の指標は生データよりも集計したものを使用する。 平均をとったりすると異常値などが隠れてしまうため、慎重に集計する必要がある。 パーセンタイルを使えば最悪のケース、典型的なケースなどに対応ができる。
計測しやすいメトリクスから初めてしまうと有益でない SLO が出来上がってしまうので、 自分たちが計測できることから考えるのではなく、ユーザーが気にすることを考える。
計測値とそれが適正である条件を書いて定義を明快にする。 パフォーマンスカーブの形が重要であれば複数の SLO ターゲットを定義してもよい。 ユーザーからの使われ方(ワークロード)が複数ある場合は、それぞれの使われ方に対して SLO を定義する。
例: 46頁
SLO を常に満たし続けようとするとデプロイメントのペースを落としたり過剰に保守的になってしまい、現実的ではない。
SLI, SLO の選択は純粋な技術的な活動ではない。 ビジネス上の事情、スタッフ、市場投入までの期間、利用できるハードウェア、資金などの制約とプロダクト特性とのトレードオフ。 SRE はこれらの議論に参加してアドバイスを行う。
例: 47頁〜48頁
SLO は SRE や開発者の仕事の優先順位を決める主要な要因となるべき。 何故ならば適切に設定された SLO はユーザーの関心事が反映されているはずだから。 厳しすぎる SLO はチームに超人的な努力を強い、甘すぎる SLO はプロダクトの品質を落とし兼ねない。
SLI を監視して SLO を満たせなくなりそうならアクションを起こしましょう。
SLO を公開することで、そのサービスを使うユーザーは自分のユースケースにあっているかを判断できるようになる。
ユーザーからの失望を招かない為に安全マージンを確保する(49頁) 外部 SLO よりも厳しい内部的な SLO を設定する
ユーザーからの過度な期待とサービスへの依存を防ぐ為に SLO の過剰達成を避ける(49頁) インフラなどのサービスに顕著で、SLO よりも遥かに優れたパフォーマンスを持つサービスではユーザーが SLO 以上の依存をするようになる。 それを防ぐために計画的な停止や、リクエストのスロットリングなどを行う。(例:Chubby)
ビジネスや法務のチームが違反の際の規定を適切に設定する必要がある。 SRE は SLO 達成の難易度や可能性をチームに理解させる為の支援をする。 顧客が多いほど SLA は変更しづらくなるので、内容は控えめにしておくのが賢明。