SRE界隈に似ている単語があるらしいぞ。
SREの本を読んでいて思いました。
SLIとSLOとSLAの字面が似ていて厄介だなぁ、と。
ということで今回は取っつきやすいように、Webサービスではなく電車のSLI、SLO、SLAを設定してみて、それぞれがどんなものなのかや、設定する時どんなことに気をつければよいのかを説明していこうと思います。
ちなみに今回の記事の内容はポッドキャストでも同じことを話しているので、音声の方が良いという方はぜひこちらで聴いてみてください
#320 電車のSLIとSLOとSLAを設定してみよう！| Spotify
#320 電車のSLIとSLOとSLAを設定してみよう！| Apple Podcast
SLI: Service Level Indicators
SLIはService Level Indicatorsの頭文字を取っており、サービスレベル指標とも呼ばれています。
これは指標なので何を計測するのかということを指すワードです。
それでは電車のSLIを設定して見ましょう。
計測する指標なので、まずは電車の運行について計測可能な情報をリストアップします。
- 予定している時刻に対して何分遅れたか
- 遅れた電車が何本あったか
- 各車両の混雑率
- 発生したトラブルの件数
- 電車の最高スピード
- 消費電力
- 忘れ物の個数
計測できるものなので、考えればいくらでもでてきそうですね。
しかし、測れる情報を全て計測するのはよくありません。
そこで指標を決めるポイントを見ていきましょう。
SLIは多すぎてはいけない
指標を増やすのは一見良いことにも思えますが、あまりに指標を増やしすぎると、大切な指標に対して適切なレベルで注意を払うことができなくなります。
要は大事じゃない情報が増えるとノイズになってしまうということですね。
SLIは少なくてもいけない
だからといって指標を減らしすぎるのも問題です。
これではサービスから発されている重要な挙動を捉えることができなくなります。
適切な量を意識しましょう。
ユーザーがサービスに対して関心を持っている事柄をSLIに設定する
そこで適切な量のSLIを設定するためには、ユーザーがサービスに対して関心を持っていることに関す指標を設定しましょう。
電車のSLIを設定するなら、まずは前提として電車の目的を考えてみるのがよいでしょう。
電車は時間通りお客さんを目的地まで運ぶということを目的にしています。
そのような目標を前提にすると、以下の3つをピックアップするのが妥当に思えます。
- 予定している時刻に対して何分遅れたか
- 遅れた電車が何本あったか
- 各車両の混雑率
特に遅れないというところは大事なポイントに思えるので、「予定している時刻に対して何分遅れたか」や「遅れた電車の本数」などは気になるところです。
混雑率も混みすぎていて乗れないなどの事象が起きるようなら結果的に時間通りに運ぶというところが達成できなくなるので、本数を増やすなどのアクションに繋げるためにも計測しておくと良さそうです。
一方、他は以下の理由で計測しないことにしました。
- 発生したトラブルの件数
→結局遅れに出るので重複して計測することになりそう - 電車の最高スピード
→乗客全員スピード狂なら計測していいかもね - 消費電力
→政府から制限されているとかなら計測が必要になるかもですが - 忘れ物の個数
→乗客は忘れ物したくないと思っているでしょうけど、個数やそれを計測することによってわかる情報には関心なさそうですね
このようにして実際のWebサービスでもユーザーの関心ごとに関するサービスの指標を適切に選択して計測していきます。
SLO: Service Level Objectives
SLOはService Level Objectivesの頭文字を取っており、サービスレベル目標とも呼ばれています。
先ほどピックアップしたSLIに対して、どれくらいの数値目標にするかということを表すワードです。
- 予定している時刻に対して何分遅れたか
- 遅れた電車が何本あったか
- 各車両の混雑率
上記の3つを計測することにしたので、それぞれのSLOを設定していきます。
- 電車の到着時間の95パーセンタイルが20分以内の遅れになること
- 遅延する本数が全体の2%であること
- 各車両の混雑率が250%以内であること
電車の場合、路線や駅が複数あって、どこで計測するかとかも考える必要がありそうですが、簡単のためそこまで深くは踏み込まないようにしています。
SLOも設定する際に気をつけるべきポイントがあります。
過剰達成を目指さない
一つは過剰達成をしないということ。
これは一定のラインを超えると、コストが跳ね上がり効果もわかにくくなるからです。
適度な達成を目指し、余った余力は別の意味があることにさきましょう。
また、Webサービスの場合、過剰に信頼性が高いと他のサービスが現在運用しているサービスの信頼性に依存しすぎてしまうという問題も発生します。
本当かよという話ですが、Googleではあえて過剰達成しないために意図的に止めることもあるそうです。
平均ではなく分布を使う
計測の際は平均ではなく分布、つまりパーセンタイルで計測してあげた方が良いケースが多いです。
パーセンタイルは小さい順に左から並べていった時に位置する情報で、95パーセンタイルなら100個並べたうちの小さい方から95番目のデータを指します。
50パーセンタイルはいわゆる中央値です。
平均が良くないパターンについては具体例を見るとわかりやすいですが、SLOとして電車の遅延時間を平均3分以下に設定します。
3分というと日々電車を使っていればそこまで気になるような遅延ではありません。
しかし、12本連続で30分遅れた場合はどうでしょうか？
これは使う側としてはかなり気になります。
京浜東北線の1日の運行本数が大体140本くらいなのですが、12本が30分遅れた場合でも他がちゃんと時間通りに機能していれば、平均の遅延時間は大体2分半くらいになってしまい、平均では問題を検出できなくなってしまいます。
このように平均には全体を包み隠してしまうという性質があるため、パーセンタイルを使って考えると良いことの方が多いです。
※とはいえ状況に応じて平均の方が良い場合というのもあるとは思うので、ちゃんと考えて適切に設定していく必要はあると思います。
安全マージンを設定しておく
これは設定するにあたって気をつけるべきポイントとは少し異なりますが、安全マージンというのは内部向けと外部向けにそれぞれ異なるSLOを設定し、厳し目の目標を内部に設定しておくことを言います。
こうすることで、先に内部で気づくことができ、外部に影響が出るよりも早く対応にあたることができます。
SLA: Service Level Agreements
最後は、Service Level Agreementsの頭文字を取ったSLAです。ITパスポートとかそういった試験でも出てくるやつですね。
これはあらかじめクライアントとの間で合意を取っている、提供するにあたって担保しているものです。
この合意は必ずあるというわけではありません。
例えばGoogleならGoogle検索という一般向けのサービスもあれば、Google WorkspaceのようなB向けのサービスもありますが、Google検索は利用している全ユーザーとの間にこれくらいを担保しますよという契約は結んでいません。一方Google Workspaceの方は担保しているレベルがあります。
電車だったら厳密には契約という感じではないですが、
- 5分以上遅れたら遅延証明書を発行する
- 運休になったら振替輸送を行う
- 特急が大幅に遅延したら返金を行う
というようなものになります。
SLOとの見分け方
どちらも目標に見えるのでSLOと混同されがちですが、その数値を下回った時に補償する必要があるものはSLAそうでないならSLOという見分け方になります。
とういことで今回はオライリーのSite Reliability Engineeringという本を参考に、SLIとSLOとSLAの違いについてまとめました。
自分はアプリケーションエンジニアですが、SREのテクニックの背景にGoogleの洗練された考え方を学ぶことができてとても面白い書籍なのでぜひ読んでみてください！