SRE サイトリアイアビリティエンジニアリング 4章まとめ

前章はこちら

www.te-nu.com

4章 サービスレベル目標

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

• サービスを適切に管理するためには、サービスの中で重要な振る舞いがどれかということと、その計測と評価の方法を理解する必要がある
• Googleでは以下を定義している
  • サービスレベル指標（service level indicators=SLI）
  • サービスレベル目標（service level objectives=SLO）
  • サービスレベルアグリーメント（service level agreements=SLA）
    • サービス品質保証と言われていることもある
• これらを適切に設定し、計測することで何かあった際に適切なアクションを取れるし、サービスが健全であるという確信にもつながる
• SLIはサービスのレベルの性質に関して定義された計測量で、多くのサービスではリクエストのレイテンシを考慮する、他にはエラー率やシステムスループットがある
  • サービスの性質に応じて計測するものが変わる
• これは直接計測することが理想だができない場合は代用の値を計測することがある、フロントで計測したいがサーバサイドでしか出来ない場合はサーバサイドでの計測値を使うケースがある
• SREにとって重要なもう一つの項目が可用性である。これはサービスを利用できる時間率やリクエスト率で表される100%はありえないため、99%（2ナインズ）や99.999%（5ナインズ）といった"9"の数で表現する
• SLOはSLIで計測されるサービスレベルのターゲット値、あるいはその範囲であり、SLOの自然な構造はSLI <= ターゲットあるいは下限<=SLI<=上限となる
• 検索結果を高速に返したい場合は、検索結果に対する平均レイテンシを100ms以下にするようSLOを設定する
• 適切なSLOを設定するのは複雑な作業である。全リクエストを100msにすることは現実的ではないが、平均を100msにするということは可能であり、こういったゴールを設定することは、低レイテンシのためのアプローチに対する良い動機づけになる
• SLOを設定し、ユーザーに公表することはサービスの挙動に対する期待を設定するということである、これによって隠れた不満を減らせる
• 明示していない場合、ユーザは独自の考えを持ち、過剰な信頼もしくは信頼の損失を引き起こす要因となる
• SLAはユーザとの間で結ぶ契約であり、SLOを満たした場合やそうでなかった場合に関する規定が含まれる。金銭やペナルティがわかりやすい例だがそれ以外もある
• SLOとの違いをはっきりさせるためには「SLOが満たされなかった場合はどうなるか」という問いが効果的で、明確な規定があればSLA、そうでなければSLOである
• SREはビジネスに密接に関係するSLAの構築には関わらない。SLOを達成することや、SLIを策定することに関わる

指標の実際

• モニタリングできるメトリクスの全てをSLIにすべきではない、ユーザがシステムにもとめていることを理解すれば、賢明に選択はできる。逆に少なすぎても重要な挙動を検証できなくなってしまう
• サービスの障害はいくつかに分類ができる
  • ユーザとやりとりをするサーバシステム
    • 可用性
    • レイテンシ
    • スループット
  • ストレージシステム
    • レイテンシ
    • 可用性
    • 耐久性
  • ビッグデータ
    • スループット
    • E2Eのレイテンシ
  • 全て
    • 正確性
• 多くの指標はサーバサイドで収集するのが自然で、500レスポンスの比率などといったものを定期的なログ分析を使って行う。しかし、javascript問題から生じるレイテンシの低下などを見落とす恐れもあるため、クライアント側での収集が必要なこともある
• 単純さと使いやすさのために生の計測値が集計されるが、単純そうに見える集計値でも本当に必要なものが隠れている場合があり、注意が必要である。１分毎の平均リクエストを集計していれば、そのうち数秒だけバーストしていても隠されてしまう
• ほとんどのメトリクスは平均よりも分布で考えるほうが良く、SREは優先的にパーセンタイルを用いて分布の様子と様々な属性について検討を行う
• 一般的なSLIに対しては定義を標準化し毎回最初から考えずに済むようにしておくことをすすめる
  • 例
    • 集計のインターバル：1分
    • 集計の対象領域：クラスタ内の全てのタスク
    • 計測の頻度：10秒
    • 計測方法：モニタリングシステムを通じて、サーバで計測

目標の実際

• まずはユーザが気にすることがなにかを考え（または知る）必要があり、それが数値化し辛いものであれば他の数値で近似しなければならない。単純に計測のしやすさで決めてしまうと適切ではないSLOが生まれることになる
• 定義を明快にするため、SLOは計測の方法と計測値が適正である条件を指定するべきである
  • GetRPC呼び出しの99%(1分間での平均)が100ms以下で完了すること
  • GetRPC呼び出しの99%が100ms以下で完了すること
• パフォーマンスカーブの形が重要であれば、SLOのターゲットを複数指定することもできる
  • GetRPC呼び出しの90%が1ms以下で完了すること
  • GetRPC呼び出しの99%が10ms以下で完了すること
  • GetRPC呼び出しの99.9%が100ms以下で完了すること
• スループットが重要になる処理とレイテンシが重要になる処理といった具合に異なるワークロードを持つユーザがいるのであればそれそれに対して目標を設定することが良いかもしれない
• SLOを常に満たし続けるのは望ましくない、それはイノベーション・デプロイメントの速度の低下、高価で過剰に保守的なソリューションにつながる。それよりもSLOを満たせない比率を示すエラーバジェットを認めて、日毎・週毎で追跡するのが良い。SLOの未達成率はユーザから見たサービスの健全性の指標になる
• SLOの選択は純粋に技術的な活動では無く、ビジネスの事情（スタッフ・資金など）がSLI・SLOどちらにも反映されるはずであり、SREもその選択の議論に参加しアドバイスを行うべきである。その議論を生産的に行う上で役立つことを経験から学んだ
  • 現在のパフォーマンスに基づいて決めてはいけない
    • 満たすために超人的な努力が必要なケースがある
  • シンプルに
  • 絶対を避ける
    • 常に無限スケールして利用できるシステムを求めたくなるが、ユーザが満足するレベルを超えていることになる
  • SLOは最小限に留める
    • 業務の優先順位に関与したことがないSLOには価値がない、しかし全てのプロダクトの属性がSLOの下にあるわけではない
    • ユーザの感動をSLOで規定することは困難
  • 最初から完璧でなくともよい
    • 見直していく
    • 緩め→厳しめが良い
  • SLOはユーザの関心事が反映されるため、開発者の仕事の優先順位に大きく関与する。
  • よく考えられていないSLOは超人的な努力を強いることになったり、甘すぎるSLOのせいでプロダクトの質が落ちたりするため賢明に利用することが大事
• SLIとSLOはシステム管理のサイクルに欠かせない
  • 計測する
  • SLOとSLIを比較、アクションが必要か判断
  • 必要なら何が必要かを定義
  • 実行
• SLOがなければアクションが必要かどうかも判断できなくなる
• SLOを公開することでシステムの挙動に対する期待について定まる、現実的な期待をユーザのために設定するには以下の戦略を検討すると良い
  • 安全マージンの確保
    • 公表するSLOを内部のSLOより少し厳しくしておく、ユーザの失望を招かずに行動が取れる
  • 過剰達成を避ける
    • 公表されているSLOよりはるかに提供しているものの方が優れていた場合、ユーザは後者に依存するようになる

アグリーメントの実際

• SLAを工夫するにはビジネス及び法務が違反のペナルティを適切に選択する必要がある
• SREの役割はSLAに含まれるSLOを満たせる可能性をビジネス及び法務に理解してもらうことを支援すること
• 顧客が幅広くいる場合はSLAの変更や削除が難しくなるので、ユーザに公表する情報は控えめにしておくのが賢明

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム