MogLog

メモというか日記というか備忘録というか

『SRE サイトリライアビリティエンジニアリング』第3章読んだ

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

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

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第3章を読みながらメモをとったもの。第3章は「リスクの受容」というタイトル。


  • Googleは100%の信頼性を持つ、決して障害を起こすことがないサービスの構築に挑んでいると思われているが、実際はそうではない
    • 過度の信頼性はコストに跳ね返る
      • 安定性を最大化しようとすれば、新しい機能の開発やユーザへのプロダクトの提供速度が制限される
    • ユーザはサービスにおける高い信頼性と極端に高い信頼性との差異には気づかない
      • わかりやすく言うならば、99%の信頼性を持つスマートフォンを使っているユーザには、信頼性が99.9%の場合と99.999%の場合との違いはわからない
  • 以上のことから、SREは、単純に稼働時間を最大化するよりも、可用性におけるリスク・イノベーションの速度・サービス運用の効率性というゴールとのバランスを取ろうとする。

  • SREでは、サービスの信頼性を管理する大部分は、リスクを管理することによって行う

    • 信頼性を高めるためのエンジニアリングと、サービスの適切な障害許容レベルを定めることは等しく重要
    • サービスを十分信頼できるものにするために努力はするが、 必要以上に信頼性を高めようとはしない
    • 可用性のターゲットは下限でもあり上限でもある
  • 多くのサービスにおいて、リスクの許容度を最も単純明快に表す方法は、 計画外の停止時間の許容レベルという観点から見てみること

    • 計画外の停止時間はサービスの可用性に求められるレベルによって把握できる
      • ※ 可用性:システムが継続して稼働できる能力のこと
      • 可用性は通常、"99.9%“、"99.99%"などのように表され、稼働時間の比率を基に計算されてきた
      • 稼働時間を基にした可用性 → 「稼働時間 / (稼働時間 + 停止時間)」という式で表される
    • ★ しかし、Googleは稼働時間を基にしたメトリクスを使わず、 リクエスト成功率 という観点から可用性を定義している
      • リクエスト成功率を基にした可用性 → 「成功したリクエスト数 / 総リクエスト数」
      • エンドユーザの観点から見て、全リクエスト数に対する成功したリクエスト数として計算された可用性は、予定外の停止時間の近似値として妥当なものだとGoogleは判断したようだ
    • リクエスト/レスポンスという仕組みに直接関係無いシステムはどうするの?
      • 同じ原則の多くは適用できる
      • 例えば、あるデータを取り出して分析用に変換して別のデータストアに挿入するバッチスクリプトであれば、処理に成功したレコード数と失敗したレコード数という観点でリクエスト成功率を使う
  • エラーバジェットの活用

    • 異なるメトリクスの下で評価される開発チームとSREチーム
      • 開発チームのパフォーマンスは、主にプロダクト開発の速度で評価される。そのため、できる限り早く新しいコードを投入することにインセンティブが生じる
      • SREチームのパフォーマンスは、サービスの信頼性を基に評価される。そのため、変更の頻度を高めることとは反対の方向にインセンティブが生じる
    • こういった中で判断を客観的なデータに基いて下せるようするため、2つのチームは協力しあい、サービスレベルの目標(SLO)に基づく四半期のエラーバジェットを規定する。
    • 以下はGoogleのエラーバジェットの使い方
      • プロダクトマネージャーがSLOを定義する
      • 中立な第三者であるモニタリングシステムによって計測される
      • 上記2つの値の差異が、「損失可能な信頼性」という「予算」の残分となる
      • エラーバジェットがまだ残っている場合は、新しいリリースをプッシュできる
    • エラーバジェットのメリット
      • プロダクト開発者とSREに共通のインセンティブを提供することで、両者がイノベーションと信頼性の適切なバランスを見出すことに注力できるようになること
      • プロダクト開発チームが自己統制するようになる
        • 例えば、エラーバジェットが余っているときは速度優先の開発をしたり、逆にエラーバジェットがほとんど余っていない時は自身でテストをもっとするなどしてリスクを下げようとする
    • 計測されているSLOがネットワークやデータセンターの障害によって減ってしまった場合はどうするか?
      • こうしたイベントもエラーバジェットを消費する
      • SLOに対する責任は全員が共有するもの