アドベントカレンダー9日目:SREを読んでみた「サービスレベル目標」編③

  • 2020.12.12
120
NO IMAGE

前回は、サービスレベル目標の内、SLI:サービスレベル指標について、学びました。
サービス指標は、システム面から見たサービスレベルの客観的な値になります。SLIは、多すぎず、少なすぎず、システムを把握するのに十分な指標を持つべきであること、データを平均で見ると、実際のデータの変化を隠してしまうことがあるので、分布で把握することが重要であると学びました。
今回は、サービスレベルの残りの項目、SLO(サービスレベル目標)、SLA(サービスレベルアグリーメント)について学びます。

目標の在り方

サービスレベル目標はどのような目標に設定するのが良いのでしょうか?前回のSLIの内容から考えて、レイテンシやレスポンス、可用性などを良くすればいいのでしょうか?目標を定める段階では、できるだけわかりやすい目標を立てたいと考えてしまいます。目標がそのような形になっていることは重要ですが、考えのはじめとして、このように考えることは視野を狭めてしまう場合もあります。
サービスレベル目標を定めるのは、ユーザーに目標を明示することにより、過剰にシステムを信頼したり、疑念を持たれることを避ける意味もあります。目標は、ユーザーが気にすることが何なのか?それに合わせて、設定することが重要です。もちろん、その過程を経た後、サービスレベル目標の決定にSLIを用いることは、

目標の定義

ユーザー間でインタラクティブな処理を行うシステムの場合、レイテンシが重要になります。バルク処理のような、レイテンシよりもスループットが重要なサービスもあります。
このような場合は、ユーザーの目的に応じて、SLOを個別に設定することが適切になります。
また、定義したSLOを常に満たし続けるのは、現実的でも、望ましいことでもありません。
なぜなら、そのような取り組みは、開発やデプロイの速度を落とし、高価で、過剰に保守的なソリューションになってしまうからです。それよりもエラーバジェットを認めて、それに応じた取り組みを行う。エラーバジェットの状態を追跡する方が重要です。

ターゲットの選択

あるシステムに適切なターゲット(SLO)を選択します。
その時のコツとして、以下がGoogleの教訓として、上がっています。

  • 現在のパフォーマンスに基づいて、ターゲットを選択してはならない
  • シンプルさを保つ
  • 「絶対」は避ける
  • SLOは最小限に止める
  • 最初から完璧でなくてもいい

基本的な考えとして、SLOとはサービスの発展と共に変化するものです。
そのための教訓であると考えると理解できます。
SLOは厳しすぎても、チームがその達成の為に労力を使ってしまい、甘すぎてもプロダクトの質が落ちます。
重要なのは、どの程度のサービスの質をユーザーへ提供したいのかをチームで議論していくことです。

SLOによる期待の設定

SLOを設定し、それをユーザーへ説明することは、ユーザーの過剰なシステムの信頼が生まれることを防ぐことができます。また、ユーザーが自分のシステムを構築する上でも、サービスの特徴を知ることができるので、サービスの選択の助けになります。
このようなユーザーの期待を設定するときの戦略として、ユーザーに対するSLOより内部の
SLOを厳しくしたり、SLOを過剰に達成しようとすることを避けることが重要です。

アグリーメントの在り方

SLAは、SLOとSLOが達成できない際のペナルティなどを示したものです。
適切なアグリーメントを設定することは、SREチームの責務ではないですが、SLOの設定の際に支援を行います。また、SLAは顧客へ見せるものなので、顧客の規模が大きくなるほど、変更が難しくなります。そのため、まずは目標は小さく設定しておくことが無難です。

まとめ

  • SLOの定義の際は、まず、ターゲットや目標定義を行うことが重要
  • SLOは、最初から決定されるものではなく、育てるもの

参考文献

  1. Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 47-49