Site Reliability Engineering #3
第Ⅱ部 原則
トイルを撲滅することはSREにとって最も重要なタスクの一つである。 トイルの定義は日常的に繰り返される価値を生み出さない、サービスの成長に比例してスケールする運用作業である。
3章リスクの受容
Googleは過度の信頼性がプロダクトの提供速度の鈍化、過剰なコストの増大を生むと考えている。
3.1 リスクの管理
システムの信頼性とコストの関係は比例ではなく、次の要因によってコストが100倍になることもある。
- 設備の冗長化による、定期/予定外のメンテナンスコスト
- ユーザに見えない、リスクを減らすためのシステムや機能の構築
SREはサービスの信頼性を管理する要因としてリスク管理を重視している。
3.2 サービスリスクの計測
システムの特徴を表す客観的なメトリクスを見出し、パフォーマンスの評価や改善、劣化の追跡ができるようになる。
メトリクスの例として次の指標が挙げられる。
- 計画外の停止時間
- 可用性を99.99％か、99.99999%を目指すかが明快
ただし、googleはグローバルに分散したサービスなのでどこかの地域がレスポンスを返すため常に稼働中に見えてしまう。
代わりにリクエスト成功率を可用性として定義する。
このメリットはユーザに直接見えないバックエンドのシステムに対しても同一のメトリクスを適用しやすくなる。 バッチシステムの場合は成功したレコード数、失敗したレコード数に置き換えて計算できる。
3.3 サービスのリスク許容度
多くの場合、アプリケーションのビジネスを担当するプロダクトマネージャーがいて、サービスの信頼性を議論する。 リスク許容度を議論するにあたって次の要素を元に検討する。
- 可用性のレベル
- サービスの性質、競合他社のレベル、BtoB、BtoCかなど
- 障害の種類によるサービスへの影響の違い
- ビジネスの時間帯に稼働していれば済むのか
- リスク曲線上サービスを伸ばすことが優先されるか(機能開発速度が重視されるか)
- 可用性を1桁上げた場合の収益と追加コスト
- 考慮すべきその他重要メトリクス
- ユーザの体感速度に応じたレイテンシの設定ができたら、コストを抑制できる
インフラストラクチャの場合はコンシューマと違い異なる特性を持つ多様なクライアントの要求が存在する。
- 可用性のレベル
- 低レイテンシ高可用性のサービス vs スループット重視のサービス
- 同一インフラで実現することはコストが掛かりすぎるので、インフラを分割し、独立したレベルのサービスとして扱う。
インフラストラクチャは明示的に示したサービスレベルでサービスを提供することで、クライアント側がリスクとコストの適切なトレードオフを選択できる。
3.4 エラーバジェット
プロダクト開発者のパフォーマンス指標の開発速度と、SREのパフォーマンス指標の信頼性で評価すると緊張が生まれる。
評価の指標をエラーバジェットに置き換えてイノベーションと信頼性の適切なバランスを見出す。
エラーバジェットのルールは次の通り。
- SLOに基づくエラーバジェットはプロダクトマネージャーが規定する
- 稼働時間は第三者のモニタリングシステムで計測する
- 目標と実績の差異を四半期の「損失可能な信頼性」という「予算」として管理する
- 稼働時間がSLOを超えていれば、リリース可能とする。
エラーバジェットにより、プロダクトの開発チームが自己統制をするように促せるメリットがある。
