SRE Advent Calendar 12日目の記事を担当させていただきます@bayashi_okです。
この記事では、なぜSLI/SLOが必要なのか、膨大なモノリシックなサービスにどのようにSLI/SLOを入れていけばいいのかを考え、少しでも皆さんの参考になればよいと思い書かせていただきました。
まず、SLI/SLOを策定しようと思ったきっかけと、これを書くに至った経緯を話したいと思います。
なぜSLI/SLOが必要なのか考える
現在自分が所属しているサイトのサービスには目標稼働率はあるもののSLI/SLOが明記されておりません。
稼働率に関しても膨大な機能がある中、どの機能のどの程度までの障害が稼働率に関わってくるのかなど具体的に記載されたものはなく、その期に発生した障害が感覚値で当てはめられOutputされております。
また、稼働率の定義もインフラ要件としての稼働率として計上を行っているためサービス全体を良くしてユーザに対するサービスレベルを上げようといったところまで手が回っておりませんでした。
ただこれは今目に見えるサービスがある程度安定しており、高い稼働率を誇っている事を前提として進められているため現状支障はなく日々「障害が起こりにくいように創意工夫をさせる事」も行われているのですが、やはりSREとしてはサービスを適切に管理するために、適当なメトリクスを定義し、何か問題があった時に適切なアクションを取りやすくしたいという思いから今回SLI/SLOの策定を進めようという決意に至りました。
ここからは余談ですが、Iacという文化からこれまで手動で行ってきた構築をコード化して可視化できるようにしていくことで何が行われているかを明確にしてきたように、
サービスレベルに関しても、これまでは収集し警告を行う事で即時対応を行えるようにしてきたものを、さらに集計し可視化できるようにしていくことで後から見ても誰もがわかるように明確化していくとともにサイトの信頼性を明示的に可視化していくことが、近年SREチームができSLI/SLOに力を入れ始めている流れになってきているのではないかと考えております。
それでは簡単にSLI/SLOとは何かをSRE第4章のサービスレベル目標の部分から考察していきたいと思います。
SLIとは
- サービルレベル指標(service level indicators)
- サービスのレベルの性質に関して慎重に定義された計測量
- また一般的なSLIとしては以下があげられる
| SLI | 重要度 | 説明 |
|---|---|---|
| リクエストのレイテンシ | ◎ | リクエストに対するレスポンスを返すまでにかかった時間 |
| 可用性 | ◎ | サービスが利用できる時間の比率。処理に成功した正常なリクエストの数の比較で計測されることが多い |
| エラー率 | ◯ | 受信したリクエストに対する比率であらわされる場合が多い |
| システムスループット | ◯ | 毎秒のリクエスト数 |
ただ、ここで見ておきたい点としては以下の文です。
「注目しているサービスレベルを直接的に計測することが理想だが、望ましい計測値の取得や解釈が難しい場合は、代用の値を使う場合もある」
つまりSLIに関しても明確な定義はなく、あくまでサービスレベルの中で重要なものを指標として決めていかなければならないという事になります。
SLOとは
- サービルレベル目標(service level objective)
- SLIで計測されるサービスレベルのターゲット値、あるいはターゲットの範囲
これはSLIよりはわかりやすく、SLIの中でどの程度を死守していきたいかという目標値という事になります。
ただ、ここでも注目したい点は「常にSLOの値を選択できるとは限りません」 と記載されている点だ。
ここでは例として、
外界からサービスに対して送信されてくるHTTPリクエストについて、毎秒のクエリ数(QPS)のメトリクスは、基本的にユーザの動向によって決まることになるので、このメトリクスにSLOを設定することは現実的ではありません。
との記載がある
つまり外的要因によって変化する値にSLOを設定することは難しいという事である。
中々難しい話です。
リクエストのレイテンシを一定以下に定めるには、QPSが影響する場合もあるし、
QPSが高ければもちろんレイテンシは大きくなりがちになる、
さらにはQPSが一定以上を超えるとレイテンシが落ちてしまう場合があり時にはQPSが重要になってくる場合もある。
恐らくそういった場合にはユーザ毎によってDDOS防止の策を入れる必要が出てくる場合もあるし、ただキャンペーンのような施策をサービスがうつ事によってQPSの増加が期待される場合やチケットサイトのような早い者勝ちになりがちなサービスはさらに知恵を絞らないといけなくなってくる。
ただこれはサービスとして普通のこととなり、だからそこQPSはSLIとして定めることは現実的ではないと定義されているのだと思いました。
SLOを策定するリスクについて
今回はここについて触れておきたいと思います。
近年SREチームができたことによりSLI/SLOが制定されてきた企業は多くなってきました。
もちろんそれはSREを開始するための責務でもあり、私たちが良くしようとしているサービスが今どんな状態でどのようなアクションをしなければいけないのかという事は絶対に知りたいし、何かおかしなことが発生しているのであれば、そこに対して解決するためのアクションを打ちたいからです。
ただSRE本の中にはSLOに関してこのような記述があります。
「SLOを選択し、ユーザに公表するという事は、サービスの挙動に対する期待を設定するという事です。」
なるほど、わからない。続きを読もう。
もしSLOを策定した場合「サービスの速度が遅い」といったような、ユーザがサービス管理者に対する隠れたを見つけ解消することができます。
ただこれが明示されなければユーザは希望するパフォーマンスについてサービス管理者の意向とは違った独自の考えを持ち始めるということだそうです。
などほど、どこかで聞いたような法則です。
過剰な信頼を寄せるユーザは、サービスがその実態以上に高い信頼性を発揮してくれると誤って信じ込み
サービスを信頼しなさすぎるユーザは、実際以上にシステムの信頼性が低くあてにならないものと思い込んでしまう。
これはどちらのパターンもサービスの過剰な信頼・サービスの過剰な損失に繋がりかねない。
なるほど、じゃあもうSLOなんて定めなくてもいいのでは？？とも考えるがそうではありません。
SREの役割は、SLO違反の規定を実行するようなことがないようにすることを責務としていて、
SREはSLAのようなビジネスやプロダクトに関する判断に密接にかかわるものには関わらず、あくまでSLIやSLOを元にサービスを把握し信頼性を上げることを期待されていると書いてあります。
そしてそのためにはSLAをきちんと定義した上で
- サービスの信頼性を高めるべきか（コストが増え開発速度が落ちる）
- 信頼性をより低くするべきか（開発速度が上がり、機能が増える）
かをチームや関係者と定義しておき、その上で何とかやっていける最低レベルの信頼性をSLOとして定めなくてはならないのです。
なので上記を踏まえると サービスによっては決してSLOが高ければいいということではない ということになります。
例えば組織としての方針が開発速度や利益優先で動く場合、高いSLOをいじるすことは困難になります。
そしてこの
- サービスの信頼性を高めるべきか（コストが増え開発速度が落ちる）
- 信頼性をより低くするべきか（開発速度が上がり、機能は増える）
が時折対立を生んでしまうのではないかとも感じました。
ここらへんのことは以下の本家Googleさんの記事にも詳しく書かれていたりもするので是非SREをやっている人/やろうとしている人は見てほしいと思っています。
(自分の拙い解説よりも100倍わかりやすく書いてあります)
https://cloud.google.com/blog/ja/products/gcp/availability-part-deux-cre-life-lessons
こういった誤解を無くすためにも、SREはSLAを踏まえたうえでまずSLI/SLOを制定し組織として何を行って行くべきかを考え取り組んでいく必要が有ると感じるとともに、やはりSREとしてはSLI/SLOの制定は責務だと改めて感じました。
最後に
この記事を書く前、本当はSLI/SLOについてもう少し先のことを書く予定でした。
（具体的にどういってものをSLI/SLOとして落とし込んでいくかなど）
ただ、自分自身SRE本を改めて読み返し吟味していくうえでそれ以上に気づかされたことが多くあり改めてSREの役割について書かせていただきました。
この記事の続きについてはまた次回どこかで書いていきたいと思います。
また、上記の考えについてはあくまで個人のものとはあり、表現の内容によってはSREとは異なってしまっている部分もあるかもしれません。
ただSRE本の冒頭にもある通りSREについてははっきりと表現できないものだと名義されております。
それでは、サイトリライアビリティエンジニアリング（SRE）とはいったい何なのでしょうか。この名前が、その内容をはっきりとは表現できていないことは認めざるをえません。
そういった中でSREは自分が寄り添うサービスに対しての信頼性を高めるためにそれぞれの視点からアプローチを行い、サービスの信頼性を上げるために日々切磋琢磨して行かないといけないのではないかと感じました。
最後まで読んでいただいた方、誠にありがとうございました。