📖

『SLO サービスレベル目標』読書記録

2023/10/27に公開

https://www.oreilly.co.jp/books/9784814400348/

SLIは、サービスレベル指標

  • ユーザが必要とする動作を行えていることを表現する
  • 例えば、「一覧ページのレスポンスは、2xxまたは3xxのHTTPステータスコードを2000ミリ秒以内に返す。」

SLOは、サービスレベル目標

  • サービスの適切な信頼性水準を表す
  • 信頼性がこの値を上回っていればユーザはサービスに満足しているし、下回っていれば満足していないと判断できる値
  • SLOは例えば、「直近30日での一覧ページのレスポンスの99.9%は、2xxまたは3xxのHTTPステータスコードを2000ミリ秒以内に返す。」

エラーバジェットは、あとどれだけ障害を起こして良いかを表す

  • SLOから現時点の信頼性を引いた値がエラーバジェットとなる
  • エラーバジェットには、イベントベースのものと、時間ベースのものがある
  • イベントベースのものは、「1日あたりあと200回、不良の動作を行える」といった把握が可能になる
  • 時間ベースのものは、「期間内であと35分、不良の動作を行える」といった把握が可能になる

信頼性は、サービスがユーザの必要とする動作を行える時間や確率の計測値を意味する

  • SLOと比較する対象を何と呼ぶべきか、本書ではあまり明確に示されていないが、「信頼性がSLOを超えているときに30分に3件の障害が発生する確率は、ごく小さなものです。」(194p)とあることから、SLOと信頼性を比較すると捉えて良いだろう
  • ただ、他に、「指標」と比較していたり「可用性」と比較していたりする部分があるため、解釈の余地がありそう

SLO基準のアラートを発行することで、ユーザにとっての悪影響がある場合にのみ高優先度で対応するということが実現しやすくなる

  • 例えば、エラー率起因でアラートすることにしていた場合、リクエストが到達していない状況ではこれに気づくことができない
  • また、CPU利用率起因でアラートすることにしていた場合、それが仮に高かったとしてもユーザは特に不満でないこともある
  • ユーザが必要とする動作に基づいてアラートすることで、サービスの信頼性を維持するのに必要十分な検知と対処を行うことができる

SLOは、ユーザが満足すること、ユーザが期待する動作をどれだけできているかを指標とするので、アラートに説得力がある

  • 一方、SLO未達の場合は確かにユーザが必要とする動作をしていない、という点を見つけるのは難しそう
  • だからこそ、本書では、最初はうまくいかない、継続的に改善していく必要がある、ということを繰り返し述べているのだろう

SLO基準のアラートには、高速のアラートと低速のアラートを設けることが推奨される

  • 急激に問題が深刻になっている場合と、問題が徐々にボディブローのように損害を与えつつある場合を補足するため
  • 前者はページとして、後者はチケットとして運用する
  • 前者は固定閾値の場合にもよくある想定だが、後者を適用しやすいのはSLOの利点の1つだろう

SLO未達の場合、つまりエラーバジェットが尽きた場合には、信頼性を回復するための対応に集中する必要がある

  • SLO未達ということは、ユーザが必要とする動作をできていないということなので、これができるように改善する必要がある
  • 機能追加を後回しにして、信頼性回復を優先する
  • 実際に優先できるかという問題は常にあるが、そのための説得力のある理由を提示する

エラーバジェットは、挑戦にも利用できる

  • エラーバジェットがxx残っているので、試験的な対応Aを入れて試してみたい、ということが可能になる
  • カオスエンジニアリングを行う余地にもなる
  • 挑戦に利用するにはSLOへの信頼がかなり固まっている必要がある

チームや組織にSLOを馴染ませていく手順も書かれている

  • どういう壁があって、どう対処するのがベターかを知っておける
  • 組織の各部署について、どの順番で話を通すのが良いか、といったことまで書いてある
  • もちろんそのまま使えることは少ないだろうが、どういう反応がありうるだろうことを準備できるのは価値がある

https://www.oreilly.co.jp/books/9784814400126/
『オブザーバビリティ・エンジニアリング』ではイベントベースのSLOを推奨しているが、本書(『SLO サービスレベル目標』)では、イベントベース・時間ベースどちらも長所短所があるので両方利用することを勧めている

  • 『オブザーバビリティ・エンジニアリング』では、99.99%以上の信頼性を要求するようなサービスの場合を考慮して、イベントベースのSLOを推奨している
  • 時間ベースのSLOだとエラーバジェットが不当に枯渇しやすいため
  • 一方、本書では、一長一短を述べる
      • メトリクスの粒度やカーディナリティが高いレベルに達していない場合にイベントベースの計算に問題が発生すると述べるとともに、レイテンシーの計測についてはイベントベースに分があるという
  • 前者は、オブザーバビリティを得るためには高いカーディナリティを達成することが必要、といった立場のようなので、前提とする考え方が異なるのだと思う

https://www.oreilly.co.jp/books/9784873119137/
『サイトリライアビリティワークブック』では、本書(『SLO サービスレベル目標』)で示されていない道具や視点も提供されているので、併せて見るとより勉強になる

  • SLOの判断マトリクスは、SLO・トイル・顧客満足といった変数をもとにした行動決定の雛形として使える
  • 顧客の階層によってSLOを変える、といった手法も紹介されている
  • 但し、2.2 始めてみよう に書かれているSLO運用が効果を発揮する前提が厳しい
    • この厳しい部分の突破方法、組織に馴染ませる取り組みのことだが、本書はこれについて多くの紙面を割いている

Discussion