SLI /SLOの取り決めかた
こんにちは、季節はすっかり秋になってきましたね。 涼しくなり、非常にお酒が美味しい季節になってきました。のんべーにはたまりません。秋刀魚とビール最高です。
立ち話しはここまでにして、タイトル通りなんですが、自分自身SREエンジニアであるものの、経験が浅くSLI/SLOはどうやって取り決めるの？？と考えていました。
サービースの信頼性の指標の為にSLI設定し、その指標をもとにSLOを定める。SLOの実際のギャップを埋める為に、エラーバジェットの概念がありますが、どうやってSLI/SLO決めたらいいのと考えてました。
答えは、SRE nextにありました！！！
動画は下記へ掲載しておきます。
さてさて、動画の内容を拝見してみると、前提にCUJが大切であると理解しました。
誰が信頼性があるサイトを決めるのか
システムのメトリクスがサイトの信頼性を取り決めるのか メトリクスではなく、そのサービスを利用するuserこそが信頼性があるサイトだと決めるのです。 なのでuserからすれば、そのサーバーのメトリクスなんて関心ごととして意識はないです。サクサク動いて使いやすいなーとかを抱くものです。 そいった観点から、userの行動を洗い出す必要があります。
どうやってCUJを洗い出す？？
userがよく使う機能にフォーカスして、インフラコンポーネントレベルで洗い出すこと(関連性を考える)
コンポーネントが洗い出せたら、リクエストやapi単位でシーケンス図を書く。
これを行うことで、対処のコンポーネントを洗い出すことができると感じました。
SLIの取り決め方
CUJで割り出したえエンドポイントをもとにSLIを設定していく。
サービスの特性などにもよるが、今回は可用性とレイテンシーに関して考えていく。
SLIは良いイベントをもとに設定していく。
SLI：(良いイベント/有効なイベント) * 100% //あるイベントのHTTPリクエストレスポンスの全体の件数のうち、全体のリクエスト成功数 SLI = 成功リクエストレスポンス/全体のリクエストレスポンス * 100%
上記をかみしてSLIを考えると下記になる
// /hogeはCUJで割り出したエンドポイント ロードバランサーで測定したステータスが、 /hogeまたは /hgoe/profileに対する HTTP GETリクエストのうち、200番台、3xxまたは4xxを返す割合 // レイテンシー ロードバランサで測定した、/hogeに対するHTTP GETリクエスト のうちX msの範囲内にレスポンス全体を送信したものの割合
SLIが決まったらSLOを設定する
- SLIをもとにどうやってuserの満足度が測れる？
- ここで目標値を決めることは理解したが、やってはいけないことはエンジニアだけで取り決めてはだめ。プロダクトマネージャー、ビジネス側と一緒に決めること。
- 明確に目標値が決めれない時は過去の平均レイテンシーなどを考慮して取り決める
エラーバジェット
- 開発の舵取りを行える指標。SLOで作成した目標値から100％をもとに差し引きしたもの。例えば全体のリクエスト内、2xx台および3xx台, 4xx台の割合を99.99%に設定した際のエラーバジェットは0.01％になる。この0.01％の許容できる範囲を逸脱しなければ、開発を続けれるし、これを逸脱するばいいは改善作業をしていく取り組みをする。
終わりに
SLI/SLOの具体的な決め方などを知ることができました。SRE本を読んでいてわからなかったことが、この動画で補完できたと思います。
