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

前章はこちら

www.te-nu.com

3章をざっくりとメモしました。こってりした本なので全然進まないです……。

リスクの受容

• Googleは決して障害を起こすことがないサービスを目指していると思われているかもしれないが、実際にはある一線を超えるとサービスやユーザにとってむしろマイナスであることが分かっている

• コストは劇的に増大する一方でユーザは99.99%と99.999%の可用性の違いについてはわからない

• このことを念頭に置き、SREは可用性におけるリスクとイノベーションの速度・サービス運用の効率化のバランスを取り、最適化を図る

• 信頼性のないシステムは急速にユーザの信頼を失うため、障害の可能性は減らさなければならない

• しかし信頼性とコストの関係は比例ではない。ある信頼性を上げるための改修は前回に比べて100倍のコストがかかる場合もある

• このコストには2種類の特徴がある

  • 冗長なマシン/リソースのコスト。冗長化にコストをかけることで、メンテの際に一部をオフラインにしたりできる
  • 機会のコスト。リスク回避のためにエンジニアリソースを割り当てるため、新機能の開発などができなくなる

• 信頼性を高めるためにエンジニアリングを見出すことと、サービスの障害許容レベルを定める事は等しく重要で、ゴールはサービスの取るリスクと、ビジネスが許容できるリスクの歩調を合わせることである

• 最適化したいシステムの特徴を表す客観的なメトリクスを見出すことは非常に有益であり、Googleにおける標準的なプラクティスである

• 潜在的な要素の全てを1つのメトリクスにまとめる方法は一見わからない、そのためGoogleでは扱いやすくするため「計画外の停止時間」に注目している

• リスクの許容度を単純明快に表す方法は計画外の停止時間の許容レベルで見ることである。これは99.9%なのか99.99%なのかといった、達成したい「9」の数で示し、9の追加の度に1桁の改善が必要になる

• これは 可用性=稼働時間/稼働時間+停止時間という式で求めていたがGoogleのようなグローバルに分散されたサービスではあまり意味を持たない

• そのためリクエスト成功率という観点で可用性を定義している、計算方法は 可用性=成功したリクエスト数/総リクエスト数である

• これは直接クライアントに関係しないシステムでも最小限の変更で適応ができる

• Googleは可用性のターゲットを四半期単位で設定し、それに対して月・日単位で追跡する。この方策のおかげで、修復価値のある特異点を見つけ追跡、修復することで高レベルの可用性の目標を掲げてサービスを管理できる

• Googleのコンシューマサービスにはプロダクトマネージャーが存在し、信頼性について議論する相手はそのプロダクトチーム、もしくは構築したエンジニア達になることが多い

• リスク許容度の評価に対しては多くの要素がある

  • 必要な可用性のレベル
  • 障害の種類の違いによるサービスの影響の差
  • リスク曲線上において、サービスコストはどのように利用できるか

• サービス可用性のターゲットレベルは提供する機能と市場におけるサービスの位置づけに依存する

  • ユーザが期待するレベル
  • サービスが直接収入につながっているか
  • 有料か無料か
  • 競合サービスのレベル
  • コンシューマ向けか企業向けか

• Gsuiteの場合は問題発生時にはGoogleだけでなく関連企業への影響も強いため高めのものに設定し、対してYouTube買収時には機能開発の速度に重点を置くべきだったため低めに設定した

• 予想される障害がどのようなものかも重要な検討事項である、低い発生率で障害が続くことと、時々完全にシャットダウンすることとではエラーの絶対数が同じでもビジネスに対するインパクトは大きく異なるかもしれない

• コストは可用性のターゲットを適切に設定する主要な要素である。可用性を1ケタ改善すると収入はどのような増加するか、その増加はコストに見合うかということを分析する

• このようにシンプルに計算できない場合は、インターネットサービスプロバイダのエラー率を考え、そのエラーに紛れられるかどうかで考えると良いかもしれない（0.01~1%の間）

• リスク許容度を検討する際に可用性以外のメトリクスも合わせて考えると有益であり、リスクを取る際に様々なメトリクスの重要性を知っておくことで自由度が増す

• （Bigtable[Cha06]を例に具体的な考え方を書いていたがここでは省略）

• プロダクト開発チームとSREチームは評価軸が開発スピードと信頼性とで大きく異なり、それが両者に緊張を生んでいる

• 緊張で典型的なものとしてはソフトウェア障害の許容度・テスト・プッシュの頻度・カナリアテストといったものがある

• そしてこのバランスは政治や恐怖や願望によって決められているかもしれない(Google SREの非公式のモットーは「希望は戦略にあらず」)

• 対してチームのゴールは交渉を生産的な方向へ導くための客観的なメトリクスを用意し、両者に合意をもらうことである。判断はデータに基づいている程良い

• そのためにSLO（4章で説明）に基づく四半期のエラーバジェットを規定する。これは四半期内でサービスの信頼性が損なわれる許容範囲を示し、このメトリクスは開発者とSRE間の交渉から政治を取り除く

• Googleのやり方はPMがSLO、期待される可動時間を制定する。そして中立的なモニタリングシステムにより計測を行い、期待する稼働時間との差分をエラーバジェットの予算とする、そしてまだ残っていれば新しいリリースをプッシュが可能となる

• エラーバジェットのメリットはプロダクト開発者とSREの間で共通のインセンティブを定期用し、両者がイノベーションと信頼性のバランスに対して注力できるというところにある

• エラーバジェットが底をつきそうなら、リリースの速度を下げたり、ロールバックを行うといった方法がとれる

• エラーバジェットが消費されると開発者が自分で行うテストを増やすといった自己統制を行うこともある

• エラーバジェットは増やしてイノベーションを加速させるという選択肢を取ることもできる

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