前回は、サービスレベル目標の内、それを定義する言葉について、学びました。
今回は、その中でも特にSLI（Service Level Indicator：サービスレベル目標）についてみていきます。
指標の在り方
システムを表すメトリクスは、様々なものがあります。なので、様々な定義を行うことができます。しかし、その指標はあればあるほど良いのでしょうか？仮に一つの指標でシステムの状態すべてが表されているのなら、なんら問題はなく、その指標以外があることは、本当に価値のある基準が埋もれてしまう結果になります。
一方で指標が少なすぎれば、サービスの挙動を正確に測ることができなくなります。
以下は、特定のシステムの代表的な指標です。
ユーザーとやり取りするサーバーシステム
- 可用性
- レイテンシ
- スループット
ストレージシステム
- レイテンシ
- 可用性
- 耐久性
ビッグデータシステム
- スループット
- エンドツーエンドのレイテンシ
正確性
この指標は、システムそのものというより、システムが正確にデータを返せているか。
バックアップの復元時にデータが問題ないかなどです。
はっきりSREの責務なわけではないですが、システムの健全性を図る上で重要です。
指標の収集
多くの指標のメトリクスは、サーバーサイドで収集するのが、自然です。
しかし、システムによっては、クライアント側での指標の収集が必要になります。
これは、サーバーサイドのみで計測していると、ユーザーにだけ影響を及ぼしている種類の問題を見逃してしまうかもしれないからです。
ユーザビリティの改善の観点からすると、クライアント側からの指標を収集する方が、状況をよく表してます。
自分にはありがちですが、そのデータを取る意味を深く考えなかったり、データがもつ意味について、理解が及ばない時があります。
本当に意味のあるデータは何だろうと考えるべきだと思いました。
集計
例えば、可用性の計測として、毎秒のリクエスト数を考えます。
単純に多くのリクエストを捌けていれば、可用性の高いシステムと考えられると思います。
しかし、平均の100レスポンスを返すシステムがあったとき、コンスタントに100レスポンス返す場合でも、偶数秒の時は、0レスポンス、奇数秒の時、200レスポンス返す場合でも、平均で100レスポンス返すことになります。レスポンス数としては、変わりませんが、後者の場合は、奇数秒のとき、負荷が2倍になってしまいます。平均でみると、実際のデータの変化を隠して、しまうことがあるかもしれないので、データの分布で考えてみることも重要です。
Googleの場合は、パーセントタイルでデータを分析する場合が多いようです。
人は、レスポンスタイムにばらつきがあるシステムより、遅いが安定しているシステムを好む傾向があるので、99%タイルのみに注力するSREチームもあるようです。
指標の標準化
一般的なSLIは、その定義を標準化し、毎回一から考えずに済むようにすることが奨められています。以下のような例が示されています。
- 集計のインターバル：「集計は1分とする」
- 集計の対象領域：「クラスタ内のすべてのタスク」
- 計測の頻度：「10秒ごと」
- 対象となるリクエスト：「ブラックボックスモニタリングジョブからのHTTP GET」
- データの取得方法：「モニタリングシステムを通じて、サーバーで計測」
- データアクセスのレイテンシ：「最後のバイトまでの時間」
標準化の際には、そのデータを計測する目的を書いておいた方がいいと思います。
ただ有用であるから使うとなると、その方法への偶像崇拝になってしまうと思うからです。
##まとめ
- データの意味や有用性について、意識する
- 指標の標準化を行う。
雑記
少しただ続けているだけの状態に陥り始めている。
1割だけ変えてみる。自分の意見を少しだけ入れる。
引用
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 42-45