中途3年目、堀越です。

ゆるふわっと読書会を始めてから三ヶ月が経過し、SREとはなんたるかの理解が進んできました。今回は、SREの文脈でも極めて重要と認識している、サービスレベル指標・目標・アグリーメント（SLI, SLO, SLA）について書きたいと思います。

サービスを適切に管理するために

サービスを適切に管理するためには...

サービスの中で特に重要な振る舞い
振る舞いの計測と評価の方法

を理解しなければならない。
そのために、サービスレベルを定義する。

サービスレベルを定義するということ

下記のような、旨味がある。

適切なメトリクスを選択することで問題があったときに適切なアクションを取りやすくなる。
サービスが健全な状態にあることを確信できる。

サービスレベル定義の際は、直感、経験、ユーザーの要求などを活用する。

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

サービス指標 - service level indicators = SLI

SLIはサービスレベル指標(service level indicators)の略。
サービスレベルの性質に関して定義された計測量のこと。

一般的な指標

指標	説明
リクエストのレイテンシ	リクエストに対してレスポンスを返すまでにかかった時間
エラー率	リクエストに対するエラーの比率
システムスループット	時間帯(例: 秒間)のリクエスト数
可用性	サービスが利用できる時間の比率

可用性はSREにとって重要な指標で、処理に成功した正常なリクエスト数で計測される。可用性は別の呼び方でイールドと呼ばれることがある。

可用性の表現

可用性のパーセンテージに並ぶ「9」の数を使って高可用性を表現する。
99%や99.999%の可用性をそれぞれ「2ナインズ」、「5ナインズ」の可用性であると表現する。

Google Compute Engine の可用性として公開されているターゲットは「3.5ナインズ」すなわち99.95%の可用性。

サービスレベル目標 - service level objective = SLO

SLOはサービスレベル目標(service level objective)の略。
SLOはSLIで計測されるサービスレベルのターゲット値、あるいはターゲット値の範囲である。したがってSLOとして自然な構造は、 SLI ≦ ターゲット あるいは 下限 ≦ SLI ≦ 上限 となる。

SLO選定で注意すべきポイント

ユーザーの動向によって決まるようなメトリクスにSLOを設定することは望ましくない。リクエスト毎のレイテンシをを100ミリ秒にするというような設定のほうがよい。

SLOをユーザーに公表する

これはつまりサービスの挙動に対する期待を設定するということ。この方策により例えばサービスの挙動が遅いといったユーザーの不満を減らすことができる。

SLOが明示されていない場合、ユーザーはサービスへ過剰な信頼を寄せ、最終的には信頼を損失する結果につながる。

サービスレベルアグリーメント - service level agreement = SLA

SLAはサービスレベルアグリーメント(service level agreement)の略。
SLAは、ユーザーとの間で結ぶ明示的、あるいは暗黙的の契約であり、SLOを満たした場合、あるいは満たせなかった場合に関する規定が含まれる。

通常、SREはSLAの構築には関わらない。これは、SLAがビジネスプロダクトに関する判断に密接に関わるものであるため。

SLI - 指標の実際

SLIの選定で気をつけたいこと

モニタリングシステムで追跡できるメトリクス全てをSLIにするべきではない。指標が多ければ大切な指標に適切なレベルで注意する難しくなるし、少なすぎるとシステムの重要な挙動を検証できなくなる。

システムと注目すべき指標の分類

システム	SLI	補足説明
ユーザーとやりとりをするサーバーシステム	可用性、レイテンシ、スループットに注意する。	リクエストに対してレスポンスを返せているか、レスポンスを返すのにかかっている時間はどれくらいか。処理できるリクエストの量はどれくらいかということ。
ストレージシステム	レイテンシ、可用性、耐久性に注意する。	データの読み書きにはどれだけの時間がかかるか、必要なときにデータにアクセスできるか、必要なときまでデータは保存されているかということ。
ビックデータシステム	スループットやエンドツーエンドのレイテンシに注意する。	処理しているデータはどれほどか、データの取り込みから処理の完了までにかかる時間はどれくらいかということ。
システム間で共通	正確性は全てのシステムで注意しなければならない。	返された答え、取り出されたデータ、分析の結果など。これらを満たすことはSREの責務ではないがシステムの健全性の指標として追跡することは重要。

指標の収集

多くの指標のメトリクスは、サーバーサイドで収集するのが自然。あるいは全リクエストに対する HTTP 500 のレスポンスの比率といった、定期的なログ分析を使って行う。

一方で、クライアント側での収集の仕組みが必要なこともある。サーバーサイドのメトリクスに気を取られていると、JavaScriptの問題から生じるレイテンシの低下を見落とす可能性がある。このような場合はブラウザでページが利用できるまでにかかる時間を計測する方が適切。

指標の集計

メトリクスは平均で考えるべきでない

ex.) レスポンスが返された毎秒のリクエスト数に関する考察

この数値は毎秒1回取得されているのだろうか、あるいは1分間に対する平均のリクエストだろうか。後者であれば数秒間だけリクエスト数がバーストして高くなっていても隠蔽されてしまうだろう。

ex.) レイテンシを平均することへの考察

「レスポンスが返された毎秒のリクエスト数」と同様にレイテンシも平均で考えた場合は、重要な細部をぼかすことになってしまう。つまりほとんどのリクエストは高速に処理されるが、リクエスト中のロングテイルの部分はそれとは比較にならないくらいほど低速ということがありえる。

メトリクスは分布で考えるべき

単純な平均では、レイテンシなどの変化がぼかされてしまうことから、ほとんどのメトリクスは分布として考えるほうが良い。

指標としてパーセンタイルを使えばさまざまな属性を検討してみることができる。すなわち、99や99.9といった上位のパーセンタイルは、通常起こりうる最悪のケースの値を示すが、50パーセンタイル（中央値）は典型的なケースを示す。

ユーザーの研究からは、人々は通常、レスポンスタイムにばらつきがあるシステムより速度が遅くても一定のレスポンスタイムを保つシステムを好む傾向があることから、99.9パーセンタイルの動作が良ければ、ユーザー体験は良いものになるということになる。

指標の標準化

一般的なSLIは、その定義を標準化し、毎回一から考えずに済むようにしておくことがおすすめ。以下に例を示す。

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

手間を省くため、再利用できるSLIテンプレートを、よく使われるメトリクス毎に構築しておくと特定のSLIの意味を理解するのが、誰にとっても単純なことになる。

SLO - 目標の実際

自分たちが計測できることでなく、ユーザーが気にすることを考えるべき。
ユーザーが気にすることの計測が難しい場合は、何かしらの方法で近似する。
単純に計測しやすいことから始めてしまうと、あまり有益でないSLOができてしまうことになる。
理想の目標から特定の指標へ遡るほうが、指標を選択してからターゲットを決めるよりもいい場合がある。

目標の定義

定義を明確にするために、SLOでは計測の方法と、計測値が適性である条件を指定するべき。

Example

Get RPC呼び出しの99%が、100ミリ秒以下で完了すること。

パフォーマンスカーブの形が重要ならば、ターゲットを複数指定する。

Get RPC呼び出しの90%が、1ミリ秒以下で完了すること。
Get RPC呼び出しの99%が、10ミリ秒以下で完了すること。
Get RPC呼び出しの99.9%が、100ミリ秒以下で完了すること。

スループットが重要になるバルク処理のパイプラインと、レイテンシが重要になるインタラクティブなクライアントといったように、異なるワークロードを持つユーザーがいるなら、それぞれのワークロードのタイプに応じて、個別の目標を定義するのが適切かもしれない。

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

SLOは満たし続ければ良いというものではない

SLOを常に満たし続けることは、現実的でも望ましいことでもない。それはイノベーションとデプロイメントのペースを落とし、高価で、過剰に保守的なソリューションを必要とすることにつながる。

日ごと、週ごとでSLO・SLO違反を追跡し、トレンドを把握すると共に、実際に発生する前に潜在的な問題の早期警報を掴んでおくとサービスの健全性を把握するのに役に立つ。

SLOの違反の比率は、エラーバジェットと比較できる。その差異は、新しいリリースのロールアウト時期を判断するプロセスの参考資料になる。

ターゲットの選択

SLO選定に役立つTips

現在のパフォーマンスにもとづいてターゲットを選択してはならない

何も考えずに決めると、ターゲットを満たすのに超人的努力が必要で、大幅に再設計しないと改善できないシステムのサポートをし続けることになってしまうため。

シンプルさを保つ

集計が複雑なSLIは、原因の追求も難しいことから。

「絶対」は避ける

理想が強すぎると、開発・運用に莫大なコストがかかる。
ユーザーが満足するレベル必要以上に超えることに価値はない。

SLOは最小限にとどめる

システムの属性をカバーできる最小限を選択するべき。
業務の優先順位を決定づけたことのないSLOに、SLOの価値はない。
- SLOに関する議論に勝てたことさえないのであれば、そのプロダクトにSREチームを持たせる必要はない。

最初から完璧でなくてもよい

SLOの定義とターゲットは、時間と共にシステムの振る舞いについて学ぶにつれて見直しが可能。
最初は緩めに設定して、徐々に厳しくするほうが良い。

計測値のコントロール

SLI・SLOを扱ったシステム管理のサイクル。

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

SLOによる期待の設定

SLOを公表する

SLOを公表することによって、システムの挙動に対しての期待値が定まる。
ユーザーは、サービスが自分のユースケースに適しているかを理解するため、サービスに期待できることを知ろうとする。

現実的な期待値を設定するための戦略

安全マージンを確保する

内部的なSLOをユーザーに提示するSLOよりも厳しくしておくことで、問題があっても外部に見えるようになる前に対応する余裕が生まれる。

SLOのバッファはコストやメンテナンスの容易さなどその他の属性を改善するような再実装をユーザーの失望させずに行う余地を作ってくれる。

過剰達成を避ける

実際のパフォーマンスがSLOよりも優れているとユーザーは実際のパフォーマンスに依存するようになる。

時おり、システムをオフラインにしたり、一部のリクエストをスロットリングしたり、低負荷の際にもシステムが高速に動作しないように設計すれば、過度に依存されるのを避けられる。

SLA - アグリーメントの実際

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

SREの役割は、SLAに含まれるSLOを満たせる可能性や難易度をそういったチームが理解するための支援をすること。

顧客が幅広くいればいるほど、扱いづらいSLAを変更・削除するのが難しくなるので、ユーザーに開示する内容は控えめにしておくのが懸命。

まとめ

サービスの適切な管理

サービスを適切に管理するためにサービスレベルを定義する。
サービスレベルを定義するメリット。
- 問題があったときの適切なアクションが取りやすい。
- サービスが健全な状態にあるか把握できる。

SLI - サービス指標

指標は多過ぎても少なすぎてもダメ。
システムの性質によって注目する指標は異なる。
指標の収集は基本的にはバックエンドで行う。
JavaScript の問題によるレイテンシ低下などを検知したい場合はクライアントで収集する。
指標の集計は平均せずに分布で考える。
指標は標準化しておくと一から考えなくて済む。

SLO - サービスレベル目標

自分たちが計測できることでなくユーザーが気にすることをSLOにするべき。
計測の方法と、計測値が適性であるべき。
SLOは満たし続ければ良いというものではない。
SLOはサービスの健全性を把握するためのもの。
ターゲットの選定について。
- 現在のパフォーマンスにもとづいて選択してはならない。
- シンプルさを保つ。
- 絶対は避ける。
- 最小限にとどめる。
システム管理のサイクルは、モニタリング→アクション判断→タスク可視化→実行。
SLOを開示してユーザーの期待値をコントロールする。
安全マージンを確保し、過剰達成を避ける。

SLA - サービスレベルアグリーメント

SREはSLA定義に直接関わらない。
SREはSLAに含まれるSLOを満たせる可能性・難易度を理解してもらうための支援を行う。
SLAは変更・削除が難しいのでユーザーへの開示は控えめにしておくのが懸命。

終わりに

サービスを適切に管理するため、サービスの健全性を把握するために、SLI、SLOが役に立つことがわかりました。

日々の業務においてサービスの健全性を満足に把握できているかどうかでいうと自信を持って回答することはできません。

少しエネルギーが必要そうですが自分の所属しているプロダクトでSLI・SLOを定義できるように動いていけたらなと思います。

p.s. 告知

来月の3/12(火)、弊社で定期開催しているトークイベント「新宿 Geek Lounge」をSREをテーマに開催予定です。僭越ながらわたしも喋る予定です。ご都合よろしい方、是非遊びにいらしてください。お待ちしております。

shinjuku-geek-lounge.connpass.com