-
どの振る舞いが本当に問題であるか、どのようにそれらの振る舞いを測定し評価するのかの理解なくしてサービスを正しく管理することはできない
-
そのためにサービスレベルを定義し、それをユーザに伝える
- ユーザが公開APIを使っていようと、内部APIを使っていようと
-
直感と経験とユーザが何を求めているかの理解を持って、SLI, SLO, SLAを決める
-
これらの計測は重要なメトリクスの基本属性や、どの値を取得すべきか、期待されているサービスを提供できなくなった時にどのように反応すべきかを説明する
-
適切なメトリクスを選ぶことによって、何ががおかしくなった際に正しいアクションがとれるようになり、またSREチームはサービスが正常に動いていることを信用できる
-
このチャプターではメトリクスのモデリング、選択、分析を行うためのGoogleが使っているフレームワークについて話す
-
具体例を出さないと抽象的になりすぎるので、Chapter1で説明したシェークスピアサービスを例に出す
- SLAは馴染みがあると思うが、SLIやSLOも重要
- 一般的な使い方ではSLAという単語はコンテキストにより様々な意味を持つ
- 明確さのためにそれらを分離するほうが良いと思う
- SLIは提供されているサービスレベルのいくつかの側面の量的な基準
- サービスのレイテンシやエラー率やスループットなどは一般的なSLI
- それらの値はしばしばパーセンタイルや平均値、比率などとして集約される
- 理想的には、SLIは関心のあるサービスレベルに関する値を直接取得したいが取得や解釈が難しいこともあるので別の値を利用する場合もある
- 例えば本来はクライアントサイドのレイテンシをとりたいが、サーバ側でレイテンシをとる等
- SREにとってのSLIの重要性は他にもあり、それは可用性やサービスが使用可能な時間の割合
- 可用性はしばしば正しい形式のリクエスト中の成功した割合として定義される
- データの耐久性はストレージ・システムにとっては同様に重要である
- 100%の可用性は不可能だが、ほぼ100%の可用性はしばしば簡単に達成できる
- 業界では一般的に、高い可用性を、9の数で表現する
- 99% = 2 nines 99.999% = 5 nines
- GCEの公開された目標は"three and half nine(99.95%)の可用性
- SLOはSLIで取得された値の、目標値や目標範囲
- シェークスピア検索システムは早く返すと決め、SLOとして検索リクエストのレイテンシは100ミリ秒以下とすることにした
- 適切なSLOを選ぶのは難しい
- 第一に、常にその値を選べるわけではない
- サービスにやってくるHTTPリクエストはユーザの需要によって決まるので、QPSのSLOを決めることはできない
- 一方、レイテンシを100ミリ秒以内にしようということはできる
- レイテンシ目標により、そのためのコードを書いたりそのための機器を用意したりするようモチベートされる
- (自分でコントロール出来ない)QPSが上がってきて閾値を越えるとレイテンシが激しく悪化するなどもあり、SLOの決定は最初に思うほど簡単ではない
- SLOは公開して、そのサービスがどのように振る舞うかをユーザに伝える
- これにより"サービスが遅い"等の根拠のない苦情を減らすことができる
- 明示的なSLOが存在しないと、ユーザはシステムの設計と関係なく自分の望む稼働率を想定してしまう
- その想定を下回ると、ユーザは実際異常に"このシステムは信頼性が低い"という思いを抱くことになる
- Chubbyは全世界でreplicaを持っていたが、そのglobal instanceの障害はChubbyに依存する様々なサービスの障害に直結することが分かった
- Chubbyの信頼性が高く見積もられすぎていてChubbyが使えなかった場合を適切に扱えなかった
- これへの対処としてSREはglobal ChubbyのSLOが達成されていることを確認し、任意の四半期でSLOに接しない範囲で意図的にサービスを落とす
- これによりChubbyへの意図しない依存を早期に発見できるようになった
- SLAはユーザとの明示的もしくは暗黙的な契約
- SLAのSLOとの違いは"もしSLOが達成できなかったらどうなるか"が記載されているかどうか
- 金銭的なペナルティを負う場合もあるしそれ以外の場合もある
- SLAはプロダクションやビジネス上の決定に関係するので、SREは一般的にはSLAを決めるのには関与しないが、SLOが達成できない自体を防ぐための助けは行う
- SREはSLOを測定するための、双方が明確に把握できる客観的なSLIの定義も行う。そうしないと双方で意見の相違が発生する場合がある
- SLIは、使用できる全てのメトリクスを使うのではなく、ユーザがシステムから必要としているものを理解し、必要な量のものを選ぶべき
- 多すぎるメトリクスを選ぶとそれらに適切なレベルの注意を向けるのが難しくなる
- 少なすぎるメトリクスの選択は、重要な挙動の変化を放置することとなる
- Googleでは一般的にシステムの健康を把握するための一握りの代表的な指標を使用している
- サービスは以下のどれかのカテゴリに大抵分けることができる
- シェークスピア検索のfrontendのようなユーザに直面したサービスは一般的に可用性、レイテンシ、スループットが重要
- ストレージ・システムはレイテンシ・可用性・耐久性が重要
- data processing pipelineのようなビッグデータシステムはスループットとend to endのレイテンシが気にされがち
- 全てのシステムは"正しい答を返すか"をケアすべき
- 一般的にはインフラというよりもソフトウェアの問題であるため、SREはこの達成には一般的に責任を持たないが、システムの健康度を測る上で重要な値
- 多くの指標はBorgmonやPrometheusを通じてサーバサイドで収集されている
- HTTPの500エラーの割合のカウント等
- サーバサイドだけではJSが遅すぎるなどの、ユーザに関連するクライアントサイドの問題を取得できないので、クライアントサイドでもデータ収集を行う
- データを集約することはよくあるが、気をつけて集約する必要がある
- 分間の平均値をとると、数秒のバーストを隠すことになる
- 偶数秒の時は200リクエストが来て奇数秒の時はリクエストが来ないようなシステムだと分間平均100の倍のリクエストが2秒に1度に来ていることになる
- (レイテンシ等の)平均値をとる場合にも同様なことが言えて、ほとんどのリクエストがとてつもなく高速なので問題が隠されているが、ロングテールの先のほうでは非常にレスポンスが遅いなどがあり得る
- ほとんどのメトリクスにおいて平均よりも分布のほうが役に立つ
- グラフ参照： 一般的なリクエストは5msで返しているが、5%のユーザは20倍以上遅い！このようなものは平均値では隠されてしまう
- 応答時間の分散が大きいほど、一般的なユーザがロングテールの挙動の影響を受けてしまう
- ユーザ研究によると、常に遅いシステムの方が、レスポンスの分散の高いシステムより好まれるということなので、99.9パーセンタイルの指標だけ見ているSREチームもある
- Googleでは平均値よりも分布が好まれる
- レスポンスタイムは0以下にはならない・タイムアウト以上にもならない等あり、一般的に平均値と中央値が近くなることは少ない
- 基本的には確かな確証がある場合を除いて、データポイントは標準分布にそっていないと考えるべき
- 分布が思っていたものと異なっている場合、例えば高いレスポンスを検知してサーバを再起動するようなものは全く再起動しないか、再起動しまくることになるだろう
- 最初に各SLIの共通の定義事項をテンプレートとして持っておき、全てのSLIに適用すると良い。例えば以下の通り
- 集約の粒度： "1分平均"
- 集約の範囲： "clusterの全てのタスク"
- どの頻度で計測を行うか： "10秒に一度"
- どのリクエストについてか: "ブラックボックスなモニタリングツールからのHTTP GET"
- どのようにデータが取得されるか： "サーバで取得された値をモニタリングシステムを使って"
- データアクセスのレイテンシは： "Time to last byte"
- 共通のメトリクスについての再利用可能なSLIテンプレートを持っておくと良い
- このテンプレートはまた、人に"SLIとはどのようなものか"を説明するのを簡単にしてくれる
- 何を計測できるかではなく、ユーザが何に関心があるかを考えるところからはじめよう
- ユーザの関心があるところを計測するのは難しいことが多いので、代替となる方法を採用しよう
- 結果として、今のメトリクスよりもよりユーザの関心に近いメトリクスがあることを発見することもあり、そうすることでターゲットに近づいていける
- 最大限の明確化のため、SLOはどのように計測されるか、どのような状態をvalidとするかを具体的に述べる必要がある
- 括弧内は、前の章のSLIの標準化の部分で決まっているのでわざわざ書かなくていい部分
- (全てのバックエンドサーバにおいて)99%のGetのRPC呼び出し(の1分間の平均値)が100ms以内に完了する必要がある
- 分布が重要な場合は以下のように複数のSLOを決める
- 90%のGet RPC呼び出しが1ms以内に終わる
- 99%のGet RPC呼び出しが10ms以内に終わる
- 99.9%のGet RPC呼び出しが100ms以内に終わる
- スループットが重要なバルクプロセスとレイテンシが重要なインタラクティブのプロセスのように、ワークロードが異なるリクエストが同時に来るような場合は、それぞれに対してSLOを決める
- 95%のスループットクライアントのSet RPC呼び出しは1S以内に終わること
- 99%のレイテンシクライアントでpayloadのサイズが10kb以下のSet RPC呼び出しは10ms以内に終わること
- SLOが100%常に達成されるというのは非現実的
- エラーバジェットを許容するのが良い
- SLOが達成できていない比率はユーザにサービスの健康状態を知らせるのに便利
- 毎日もしくは毎週トラッキングしてトレンドを見ることで潜在的問題に対する早めのアラートとなる
- Upper managementも毎月もしくは四半期ごとには知りたいだろう
- SLO違反率はエラーバジェットとは異なり新機能をリリースするかの判断には使用されない(なんで？)
target: 1msとかそういう値の話っぽい
- SLIやSLOに反映されるべき、ターゲットの決定はプロダクトやビジネスに関係するので純粋な技術的問題ではない
- 人材・マーケットの状況・ハードウェアの可用性・資金調達によっては特定の機能をトレードオフとして落とす必要がある
- SREは上記の決定のための調整に関与するべき
- 以下が重要
- システムの長所と限界を理解することは重要である一方、熟慮をせずにターゲットを決めると大変な努力や重要な再設計が必要になる
- (:point_up: タイトル"Don’t pick a target based on current performance"と合ってない感じがするが、どういうことだろうか…)
- いろいろなSLIを組み合わせたよう複雑なSLIはシステムパフォーマンスの変更を不明瞭にするし推測することが困難になる
- 無限のスケールや100%の可用性は現実的ではない
- 構築の時間はかかるし最終的にユーザのためにならない
- SLOはシステムの属性の必要な分だけをSLOとするべき
- SLOの優先順位の見積もりを行って選んだSLOを守ろう
- 最初は緩いターゲットを設定し、システムの振る舞いについて学ぶにつれて洗練していくと良い
- SLOはユーザの関心にもとづいているので、SREと製品開発者の仕事の優先度付けのための主要な原動力となるべき
- SLOは強力なので賢明に使用すべき
SLIとSLOは以下のようなループを回す。極めて重要。SLOがないと、何をすればいいかが分からない
- SLIを計測しSLOと比較
- アクションが必要かどうかを判断
- ターゲットを達成するためにどのようなアクションを行うかを決定
- アクション実施
- SLOの公開はシステムの振る舞いへの期待を情勢する
- ユーザはしばしば自分のユースケースに会っているかどうかを理解するために、システムにどれだけ期待できるのかを知りたがる
- 現実的な期待をユーザにいだかせるために、以下の戦略を使うことを考えるだろう
- 内部で決めている厳格なSLOよりも低いSLOを公開するする
- 潜在的な問題が出てきた場合のため
- 落としてもいい時間を他のいろいろなところにも使うことができる(エラーバジェットと同様の発想)
- ユーザは、特にインフラにおいて、提示されたSLOよりも、現状を見て(SLOよりも、実際によく動いている場合はよく動くことを想定して)自分のシステムを組み上げる
- それを防ぐため、時にChubbyの例のようにわざとシステムをメンテナンスしたり一部のリクエストをスロットリングしたりすることが重要
- システムがSLOを満たしているかを知ることで、どこに投資すべきかを決めることができる
- 可用性の向上か、速度か、SLOが問題なければ新機能の開発か、技術的負債の解消か、など
- SLAを作ることはビジネスチーム・法律チームと適切な同意をつくり上げること
- SREの役目は上記チームにSLAに含まれるSLO違反の起きる可能性や難しさなどについて理解させること
- SLOの構築に対するアドバイスはSLAにも適用可能
- ユーザに通知するSLAは保守的に組んだほうが良い。一度ユーザに通知すると変更することや削除することは困難