サイトリライアビリティエンジニアリングを読んで、Googleが提唱したSREという概念のインプットを行います。 本を読みつつドキュメントとしてアウトプットする過程を通じて、SREおよびDevOpsの考え方を学べたらと考えています。

今回は「4章 サービスレベル目標」です。みんな大好きSLI、SLOについて書かれています。

※ ここに書かれている内容は、オライリージャパンが出版したSRE サイトリライアビリティエンジニアリングから、自分の解釈を加えて引用した内容になります。

4.1 サービスレベルに関する用語 🔗

4.1.1 指標 🔗

SLI = サービスレベル指標 → 提供されるサービスのレベルの性質に関して、慎重に定義された計測量のこと。

重要なSLI

• リクエストのレイテンシ
  • リクエストに対するレスポンスを返すまでにかかった時間
• エラー率
  • 受信したリクエストに対するエラーの比率
• システムスループット
  • 毎秒のリクエスト数（データ量）
• 可用性
  • サービスが利用できる時間の比率
• 耐久性
  • 長期間にわたってデータが保持されている確率
  • （データストレージシステムの場合重要な指標）

どの指標も理想は直接的に計測することだが、場合によっては代用の値を用いることになる。

4.1.2 目標 🔗

SLO = サービスレベル目標 → SLIで計測されるサービスレベルのターゲット値またはターゲット値の範囲のこと。

SLOの自然な構造

• SLI <= ターゲット
• 下限 <= SLI <= 上限

QPSなどユーザーの動向によって決まる値にSLOを設定することは現実的に難しい。 SLOを選択しユーザーに公表することで、サービスの挙動に対する期待を設定でき、サービスのパフォーマンスについてユーザーとの間で認識の乖離をなくすことができる。

4.1.3 アグリーメント 🔗

SLA = ユーザーとの間で結ぶ明示的な契約。内部にSLOを含み、そのSLOを満たした（あるいは満たせなかった）場合に関する規定などを取り決めたもの。

SLOとSLAの違いは「SLOが満たされなかったときにはどうなるか？」が規定されているか否かで判断できる。

SREはSLAの構築には関わらない → SLAがビジネスやプロダクトに関する判断と密接に関わるものだから。（とはいえSLOとSLIの定義支援はSREの業務スコープにある。）

SLAを定義しているかいないかに関わらず、SLIとSLOを定義しその元でサービスを管理することは価値のあること。

4.2 指標の実際 🔗

4.2.1 サービスの提供者とユーザーの関心事 🔗

モニタリングシステムで追跡できるメトリクス全てをSLIにするのはNG。 ユーザーがシステムに求めていることを理解し、指標を賢明に選択することが大事。

指標は多すぎず、少なすぎず。通常は少数の代表的な指標さえあればシステムの健全性を十分に評価し判断できる。

サービス障害の分類と注意すべき指標

• ユーザーとやり取りするサーバシステム
  • 可用性
    • リクエストに対してレスポンスを返せているか
  • レイテンシ
    • レスポンスを返すのにかかっている時間はどれくらいか
  • スループット
    • 処理できるリクエストの量はどれくらいか
• ストレージシステム
  • レイテンシ
    • データの読み書きにはどれくらい時間がかかるか
  • 可用性
    • 必要な時にデータアクセスできるか
  • 耐久性
    • 必要な時までデータは保存されているか
• ビッグデータシステム
  • スループット
    • 処理しているデータ量はどれくらいか
  • エンドツーエンドのレイテンシ
    • データ取り込みから完了にかかるまでの時間はどれくらいか

また全てのシステムにおいて「正確性」は注意しなければならない。返された答え、取り出されたデータ、分析の結果は正しいか。 通常正確性はSREの責務ではないが、システムの健全性を保つ指標として追跡することは大事なこと。

4.2.2 指標の収集 🔗

多くの指標のメトリクスはサーバーサイドで優秀するのが自然。 これらを収集するためには、Prometheusなどのモニタリングシステムを使用するほか、HTTP500レスポンスの比率などは定期的なログ分析によって行われる。 しかし、システムによってはクライアント側での収集の仕組みが必要になることもある。例えば、ページのJSの問題から発生したレイテンシ低下などは、サーバーサイドのみの収集だと見落としてしまう。

4.2.3 集計 🔗

ほとんどのメトリクスは平均よりも分布（パーセンタイル）として考える方が良い。指標としてパーセンタイルを用いることで、99や99.9などの上位のパーセンタイル帯は通常起こりうる最悪のケースの値として利用でき、50パーセンタイル（中央値）は典型的なケースの値として利用できる。 ロングテイル部分である99.9パーセンタイルの動作が良ければ、通常の体験は確実に良いということにもなる。

統計的な誤謬について、データがまず正規分布しているかどうかを検証する必要がある。（タイムアウトが設定されているものなどは、そのデータの平均と中央値が近い値になるかどうかも仮定できないため。）この点も含め、パーセンタイルを優先的に扱う方が良い。

4.2.4 指標の標準化 🔗

一般的なSLIいついてはその定義を標準化し、毎回1から考えずに済むようにしておくことも大事。

• 集計のインターバル
  • 集計期間は1分とする
• 集計の対象領域
  • クラスタ内の全てのタスク
• 計測の頻度
  • 10秒ごと
• 対象となるリクエスト
  • ブラックボックスモニタリングジョブからのHTTP GET
• データ取得方法
  • モニタリングシステムを通じて、サーバで計測
• データアクセスのレイテンシ
  • 最後のバイトまでの時間

など

4.3 目標の実際 🔗

ユーザーが気にすることが何かを考え知り、、そこから計測する指標を判断することが大事。 単純に計測しやすいことから始めても、あまり有益でないSLOができてしまう。

4.3.1 目標の定義 🔗

できるだけ定義を明快にする。そのために「計測の方法」と「計測値が適正である条件」を指定する。

• Get RPC呼び出しの99パーセンタイルが、100ミリ秒以下で完了すること。

パフォーマンスカーブが重要な場合

• Get RPC呼び出しの90パーセンタイルが、1ミリ秒以下で完了すること。
• Get RPC呼び出しの99パーセンタイルが、10ミリ秒以下で完了すること。
• Get RPC呼び出しの99.9パーセンタイルが、100ミリ秒以下で完了すること。

など複数指定してもよい。

スループットが重要になるバッチ処理のパイプラインと、レイテンシが重要になるAPIクライアントなど、異なるワークロードを持つユーザーがいる場合、それぞれのワークロードタイプに応じて個別の目標を指定することが適切。

• スループットタイプのクライアントのSet RPC呼び出しの95パーセンタイルが、1秒以下で完了すること。
• レイテンシタイプのクライアントの、1kB以下のペイロードを持つSet RPC呼び出しの99パーセンタイルが、10ミリ秒以下で完了すること。

など

SLOを常に満たし続けることは、現実的でも望ましいことでもない。 イノベーションとデプロイの頻度を落としたり、高価で過剰に保守的なソリューションを必要とすることに繋がりかねない。

エラーバジェットによって満たせないSLOを認め、日ごと週ごとに追跡した方が良い。 （エラーバジェットは他のSLOを満たすためのSLO）

4.3.2 ターゲットの選択 🔗

ターゲット（SLO）の選択は純粋に技術的な活動というわけではない。SLI、SLO共にプロダクトやビジネスの事情が反映されるもの。 人や資金、市場投入までの期間、利用できるハードウェアなどからくる制約のなかで何かしらのトレードオフを行わなければならないこともある。 SREはこの議論に参加し、さまざまな選択肢のリスクや実現性についてアドバイスを行う。

この議論の生産性を上げるために役立つこと

• 現在のパフォーマンスに基づいてターゲットを選択してはならない
  • 熟考することなく値を決めると大幅な再構築が必要になる
• シンプルさを保つ
  • 複雑なSLIはシステムのパフォーマンスの変化をぼかしてしまいかねない。
• 「絶対」は避ける
  • ユーザーが満足するレベルを超えて不必要に良いものし、運用コストを大きくする必要はない
• SLOは最小限にとどめる
  • システムの属性をうまくカバーできる必要最小限の目標を選定する
  • 業務の優先順位を決定づけたことがないようなSLOは十分な価値がない
  • とはいえ、全てのプロダクトの属性がSLOの下にあるわけではなく、ユーザーの感動をSLOで規定することは難しい
• 最初から完璧でなくて良い
  • 時間の経過と共にシステムの振る舞いについて学び、いつでも見直しをしていく。
  • 緩めのSLOから厳しくしていく方向の方が良い

4.3.3 計測値のコントロール 🔗

1. システムのSLIのモニタリングと計測を行う
2. SLOに対してSLIを比較し、アクションが必要かどうかを判断する
3. アクションが必要なら、ターゲットを満たすために実現しなければならないことを明らかにする
4. 実行に移す

4.3.4 SLOによる期待の設定 🔗

SLOを公開することで、システムの挙動に対しての期待をどのように持つかが定まる。 ユーザーはサービスが自分のユースケースに適しているかを理解するためにSLOを参考にする。 （「写真共有サービス」と「アーカイブ記録サービス」では、サービスの可用性で求めているラインが異なる。）

ユーザーに公開するにあたっての戦略

• 安全マージンを確保する
  • 内部的なSLOよりもユーザーに表示するSLOをより厳しくしておく
• 過剰達成を避ける
  • 公開しているSLOよりもはるかに優れているパフォーマンスにはしない
  • （特にインフラサービスに当てはまる、過剰な信頼による予期せぬ障害悪化などが懸念される）

4.4 アグリーメントの実際 🔗

SLAは、ビジネス及び法務のチームが違反の際の規定やペナルティを適切に選択することが必要となる。

SREの役割は、SLAに封組まれるSLOを満たせる可能性や難易度を、それらSLAを定める必要のあるチームが理解するために支援をすること。

顧客が多くいればいるほど、SLAの変更や削除は難しいため、ユーザーへ開示する内容は控えめにしておくことが賢明。