本を読む会 SRE サイトリライアビリティエンジニアリング #3

読み会予習ログです。

第II部

Google - Site Reliability Engineering

  • SREが仕事を進めるうえでの原則が語られている
    • SREのオペレーション全般
    • SREの振る舞い
    • SREの関心ごと

#3 リスクの受容

Google - Site Reliability Engineering

読み解きたいこと

  • SREのリスクマネジメントのあり方
  • SREのサービス/システム視点、関心

読書メモ

まえがき

  • 信頼性は大切であるが100%を目指してはいない。過度の信頼性はコストである
    • 新しい機能開発やユーザへのプロダクト提供速度が落ちることになる
  • 「リスクマネジメントとデバイスとのバランスを鑑みたうえでユーザの満足度を維持する=信頼性」と定義できそう？

3.1 リスクの管理

  • 信頼性を担保するためにかけるコスト
    • 冗長なマシン・コンピュートリソースにコストをさく
      • 冗長化することで、メンテナンスのやりやすさ、パリティコードブロックを保存するための領域を持てる
    • エンジニア組織が、障害リスクを減らすためのシステムや機能を構築するためにエンジニアリソースを当てる
  • つまり信頼性の担保＝リスクを管理することと言える
    • リスクマネジメントをしっかりとおこなう組織とシステム整備が重要
  • リスクへの考え方
    • 連続的なものであり、信頼性を高めるためのエンジニアリングと障害許容レベルの定義を決める
    • それは（おそらく）サービスにより異なる。ビジネスが許容できるラインをしっかりと理解していることが求められる
  • 可用性のラインを理解することでリスクマネジメントを行う

3.2 サービスリスクの計測

  • システム（サービス）ごとにどういったメトリクスを計測すればよいかを見いだすことは信頼性の担保に非常に有益
    • パフォーマンスの改善、劣化の追跡が可能になる
  • 計画外の停止時間
    • リスクの許容度をもっとも単純明快に表す方法。計画外の停止時間は、サービスの可用性が実際のところどの程度求められるのかによる
  • Googleでは時間を基にした可用性は定義していない（世界中で展開するサービスのため、時間を基にしたメトリクスにあまり意味がない）
    • 総リクエスト数に対する成功したリクエスト数を可用性を測るメトリクスとしている
  • 四半期単位で可用性のターゲットを設定。そこから週・日単位にブレークダウン
    • 定量目標の設定は四半期ごとに見直すくらいがちょうどよいのだろうなあ半期だと長すぎる

3.3 サービスのリスク許容度

  • Googleではサービスのリスク許容度は明確に定義していない
  • するなら、SREがビジネス観点（事業側の定量目標やクライアントとの契約内容、パフォーマンス）を把握し、エンジニアリングで解決可能な目標に変換する必要がある
  • SREとプロダクトマネージャーの協働が必要
  • とはいえ簡単なことではない
    • プロダクトや事業サイドの責任構造はあっても、インフラストラクチャサービスの構造がないあるいは一致しないことがしょっちゅう
      • サービス側と人事との難しさと共通しているように感じる
      • (CRE目線なら）クライアント先の事例を集め、サービスやシステム構造によって何をプライマリメトリクスとするかの提案ができるとよいのだろうか

3.3.1 コンシューマサービスにおけるリスク許容度の明確化

  • SREとプロダクトマネージャ（ビジネスやユーザーに対する可用性/可用性をどうみなすかについて議論できるポジション）の目線合わせが重要
    • プロダクトマネージャにはある程度システムやSREの思想がわかっているとなおよい
  • 双方で明確化するリスク許容度
    • 必要な可用性レベル
  • 障害の種類とサービスへの影響
  • 「リスク曲線上にサービスを位置づける上で、サービスコストはどのように利用できるか」 > 日本語の意味がわからなかった
    • How can we use the service cost to help locate a service on the risk continuum?
      • リスクは連続して起こりうるものだと定義した上で、サービスコストをどこまで払うことが可能であるか、と訳せそう
  • 可用性を満たすために考慮すべきメトリクスがなにであるかの合意形成
3.3.1.1 可用性のターゲットレベル

可用性をどう設定するかは、そのサービスがユーザに提供する機能と市場におけるサービスの位置付けに依存。またはサービス機能の開発ステージ（途上なのか過程なのか充足なのか）にも依る。

  • ユーザーが期待するサービスレベル
  • サービスの収入構造
    • ビジネスモデル
  • 競合との差
  • toB or toC
3.3.1.2 障害の種類

「上り一日下り一時」「好事 門を出でず、悪事 千里を走る」を想起させ、SREの役割には頭が上がらない。

  • 障害の種類により、障害レベル、ユーザに対する信頼度、ビジネス影響など複数の影響範囲を知った上での判断が必要
3.3.1.3 コスト

コスト意識を数字で可視化。なんとなくふわっとではなく。

  • 可用性を1桁改善したら収益がどれだけ増すのか？とか
  • その収益増加は、信頼性を担保するためにかけるコストに見合う価値があるか

収益で測れないケースでは、ISPのバックグラウンドエラー率を考えることも有効。はてなでもそういったケースは多そう。

3.3.1.4 サービスの他のメトリクス

リスクマネジメントをやる上で、可用性以外のメトリクスも考えておけるとよいですよというお話。

  • 例、Google Adsにおいては、Web検索機能の速度
    • 数字だけじゃなくて、人の体感速度にまで気を使っているのがさすがー
  • サービスにより（Ads とAdsense) 優先づけができる
    • Adsenseはパブリッシャ側のレイテンシにもよるため、Adsに比べるとほんの少し緩めで設定できますよん、など

3.3.2 インフラストラクチャサービスのリスク許容度の明確化

コンシューマサービスとの基本的な違いはインフラストラクチャのコンポーネントの複雑さ。複数のクライアントを持ち、各クライアントの要求が多様。

3.3.1.1 可用性のターゲットレベル

システムの可用性定義は、複雑かつ大規模な分散システムの特性や働きを理解するところから。どのメトリクスを重視するかもことなりそう。より高い信頼性が求められることが多い。
インフラストラクチャのシステムの要求を理解するには、リクエストキュー の状態を調べてみるのがよい。 https://wa3.i-3-i.info/word14716.html

3.3.2.2 障害の種類

システムたちそれぞれの仕組みと特性の違いについて。

  • 低レイテンシのユーザにとっての成功は、オフライン分析に関心があるユーザにとっては失敗。
3.3.2.3 コスト > 要確認

前半の記載内容がよくわからなかった。
システムに何をさせるか（どんなデータを持たせて、そのシステムにどんな仕事をさせるか）により、何をコストとみなすかは変わるよという話？
システムを分散化し、持たせるデータとシステムの特性により、システムごとの可用性と信頼性を設定していくことが大事よ、と書かれてある気がする。

3.3.2.4 例）フロントエンドのインフラストラクチャ

いくらインフラストラクチャレベルで信頼性可用性が担保されたとしても、サーバサイドの例えばリバートブロキしやロードバランシングが含まれるようなシステムの信頼性が提供されていないと意味がありません、という話。
リスク許容度は、単眼的一役割的に判断するのではなく、複眼的に議論判断する必要があり、それによりリスクマネジメントを敷いてそれぞれの可用性を設定する必要がある。

3.4 エラーバジェットの活用

プロダクトチームとSREの典型的な認識の分断例。

  • ソフトウェア障害の許容度
    • Dev vs Opsのおさらい
  • テスト
    • 開発速度とシステム信頼性のバランシング
  • プッシュの頻度
    • デプロイ作業。たくさんデプロイしたいプロダクトチーム/デプロイ頻度が高まるほど障害懸念を予想できるSREチーム
  • カナリアテストの期間と規模
    • 新機能のリリース時における昨日全体のQAのようなもの？

プロダクト・SREチーム双方にとって最適なバランスで価値のあるサービス・システムを提供するために、双方による交渉ではなく、客観的かつ明確なデータで判断できることが望ましい。そうすることで障害に対するリスクマネジメントをプロダクト/SREチームで合意できるようにしようね

3.4.1 エラーバジェットの形成

Googleのプロダクトチーム・ SREチーム間のエラーバジェットのやり方。

  • プロダクトマネージャによるSLO(サービスレベル目標/Service Level Objectives)を規定。四半期間に期待するサービス稼働時間を設定
  • 実稼働時間は、モニタリングシステムで計測
    • Mackerelの出番か
  • この2つの数値差が、3ヵ月間の「損失可能な信頼性」と「予算」残分となる
  • 稼働時間がSLOを超えた場合は（うれしい）つまりエラーバジェット残分がある場合は、新たなリリースをデプロイできると解釈可能
3.4.2 メリット

適切なエラーバジェットを設定することにより、SLOに対する双方のコミットが高まる。
エラーバジェットの消費が高い場合は、SLOが正しい内容であるかを照らす基準にもなる。その場合はSLOを緩めるなど、サービスの現状に適した選択肢を判断するための材料としても使う。

www.slideshare.net

わかったこと

ふんわりです。

  • サービスの信頼性担保＝リスクマネジメントと言えそう?
  • サービスの特性とビジネスモデルにより、優先すべきリスクととってもよいコストを定義しておけるとよい
  • SREはコンシューマ、インフラストラクチャ、両サイドのリスクを理解しておく必要があり、障害時にはリスクの度合いによりどこにコストを割くかを的確に判断する必要がある
  • エラーバジェット＝SREとプロダクトチーム間で共同所有する指針
    • エラーバジェットがあることにより、リスクとコストを双方の尺度で判断し、同じ目的に到達することができる

感想

SREチームは技術領域の幅広さだけでなく、サービスについても広く多角的に認識している必要があることを知った。じゃないと、何をメトリクスにするか、エラーバジェットの作成、障害時に即時適切な判断ができない。手術を担当する外科医、症状から病を推測する医師、航空機におけるパイロットに似ている。
「サービスの信頼性を担保することはリスクマネジメントを徹底することである」逆説の考え方が興味深い。いま何をすべきかを決める時に、何をしないか何を捨てるかを考えるのだ。
Googleはその判断基準をデータや数値重視を徹底することで知られるが、そのことを実感できた章だった。

  • 参加者　missasanさん, yuukiさん, tomomii