ことえりブログ

SREサイトリライアビリティエンジニアリングを読んだので、要点をメモ。

現行のシステム管理の問題点

• サービスが成長すると運用コストも増加する
• 開発チームと運用チームでの対立が発生する

Googleのシステム管理について

• SRE (サイトリライアビリティエンジニアリング) というアプローチを取る
• SREとは(Google的には)ソフトウェアエンジニアに運用チームの設計を依頼したときにできるもの
• UNIXシステム内部とネットワーキングに関する専門知識と、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正が必要
• 運用チームで行ってきたことをソフトウェアで自動化する
  • こうしたことをしない場合、サービス成長とともに運用負荷が増大し続け、多くの人員が必要となる
• Googleの場合、運用の業務は全体の50%の時間以内に収めるようにしている
  • 残りの時間はサービスを安定して運用できるようにするための開発作業に当てる

エラーバジェットについて

• 開発チームとSREチームの対立を解決するための仕組み
• 100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っているとする
  • 99.999%と100%の可用性は、他の要素（PC/SP, Wi-Fi, ISP, 電力網等)のノイズに紛れてしまう上に、0.001%を埋める労力はユーザーにメリットがない (リリースも遅く、少なくなってしまう）
• 次の3点を考慮に入れた上で可用性のターゲットを決める。1からそれを引いたものがエラーバジェットとなる (可用性が99.9%の場合は0.1%がエラーバジェット)
  • ユーザーが満足する可用性のレベル
  • 満足できなかったユーザーにとっての大対策はどのようなものがあるか
  • 可用性のレベルを変更したとしてユーザーのプロダクトの利用の仕方にに何が起こるか
• エラーバジェットは超過しない限り自由に使うことができる
  • 機能のローンチに関わるリスク (段階的ロールアウトや1% experiment)のために使うことができる
  • SREの目的をサービス障害をゼロにすることではなく機能のリリース速度を最大化するためにエラーバジェットを使うことになる
  • サービス障害を予測済みのものにすることができ、これが悪いことではなくなる。コントロールすることができるようになる。
  • 必要以上に信頼性をあげない
  • SREと開発者との間でリリース速度と可用性の利害を一致させることができ、リスクについて揉めることなく共通の結論にすることができる

モニタリングについて

• 人間がメールを読み、何らかの対応アクションの必要性を判断しなければならないシステムは根本的に問題がある
  • アラートはソフトウェアが解釈を行い、人間はアクションを行わなければならないときのみ通知を受けるようになっているべき
• MTTF (平均故障時間)とMTTR (平均修復時間)を考える
• たとえ障害が多くとも、手作業での介入を必要としないシステムは、介入を必要とする障害が少ないシステムより高い可用性を持つ
• 人間の作業は手順書に記録していくことで、MTTRに3倍の改善が見られた (Google談)
• およそ70%のサービス障害は動作中のシステム変更によって生じるもの (Googleの場合)
• ベストプラクティスは自動化によって下記3点を実現すること。
  • 漸進的なロールアウトの実装
  • 高速かつ正確な問題の検出
  • 安全なロールバック
• 需要予測とキャパシティプランニングは次の2点を考慮に入れる必要がある。
  • 自然な成長 (プロダクトの利用が進むなど)
  • 突発的な成長 (機能のリリースやマーケティングキャンペーン等)

リスクについて

• 信頼性と機能追加等のリリースはトレードオフの関係にある
  • そのため必要以上に信頼性をあげない
• 可用性はリクエスト数を集計(成功したリクエスト数/総リクエスト数)すると、バッチやストレージ等にも当てはめることができる
• 可用性のターゲットレベルは下記のことを考慮するべき
  • 期待されているサービスのレベル
  • サービスが直接的に収入(顧客と自身の)につながっているか
  • サービスの有償・無償
  • 競合サービスのレベル
  • コンシューマー向け・企業向け
• 可用性のレベルを変更してどれだけのコストに影響があるかも考える必要がある
  • サービスの収益がXXX円だから、可用性0.1%の改善はYYYの収益改善になる。これはコストに見合うかどうか等
  • 上記の計算が難しいならISPのエラー率を参考にする(ISPのエラー率より低いならこのノイズに紛れるため)
    • Googleの計測では0.01%から1%の間
• 処理の重要度によって可用性のレベルを変更しコストを抑えるのもあり
  • 重要なデータとそうでないデータを、それぞれ冗長で高速なストレージと結果整合性の安価なストレージに格納する。など

サービスレベル目標

用語の定義から

SLA (service level agreements)

• ビジネスサイドが決めるもので、SLOが満たす/満たされなかった場合の規定
  • 裁判や金銭的ペナルティのことを指す
  • 上記以外の規定はSLOのことを指す

SLI (service level indicators)

• サービスレベルの計測量
  • リクエストのレイテンシ、システムスループット、エラー率等が挙げられる

SLO (service level objectives)

• SLIで計測されるサービスレベルのターゲット値の範囲 * SLOを公開するとユーザーの不満を減らすことができる * SLOが明示されていない場合、ユーザーは希望するパフォーマンスについて、過剰な信頼もしくは損失をもってしまう

• SLIはユーザーがシステムに求めていることを考慮し、少数の指標に抑える。

  • 多ければ大切な指標に適切なレベルで注意が払えなくなる

• サーバサイドでメトリクスを収集するのが一般的だが、クライアントサイドのメトリクスも重要 (ユーザの実体験にそっている）

• メトリクスは平均ではなく分布(パーセンタイル)で考えると良い

  • 1分平均のメトリクスでは、数秒の間のバーストが検知できない

• SLIは定義をテンプレート化すると良い。例えば

  • 集計インターバル: 1分
  • 対象領域: クラスタ内すべてのタスク
  • 収集頻度: 10秒
  • 対象リクエスト: ブラックボックスモニタリングジョブからのHTTP GET
  • 取得方法: モニタリングシステムを通じて、サーバで計測
  • データアクセスのレイテンシ: 最期のバイトまでの時間

• SLOでは計測方法と適切であるかの条件を指定するべき

  • SLOを常に満たし続けることを求めるのは望ましくない
    • リリースのペースを落とし、コストが上がってしまう
    • SLOを満たせない比率のエラーバジェットを設定し、定期的に追跡する方が良い
  • 現実的なターゲットを設定する
  • できるだけシンプルな集計を心がける
  • 安全マージンを取る(内部的なSLOを大概的なSLOより厳しくする)
  • 過剰設定を避ける (スロットリングやシステムをオフラインにする)
    • 過度な期待を避けるため

モニタリングについて

特に重要なシグナルは次の4つ

• レイテンシ
  • 成功処理のレイテンシと失敗処理のレイテンシは必ず分けて計測
• トラフィック
  • リクエスト数や同時セッション数等
• エラー
  • 処理に失敗したリクエストのレート
  • HTTPの500や200でありつつも内容に間違いがある、SLO違反のリクエスト等
• サチュレーション
  • 最も制約のあるリソースに重点を置いたシステムの利用率
  • もうすぐ発生しそうなサチュレーション (ディスク空き容量の低下等）

適切な粒度について

• 1分毎のメトリクスからでは長時間に渡る変化がわかりづらい

• ディスク空き容量は1,2分に1回以上にする必要はない

• 粒度が細かすぎると収集・保存・分析のコストが高くなる

  • サーバでサンプリングしてから収集・保存・分析すると良い

• 複雑なモニタリングシステムは変更が難しく、脆く、メンテのコストが高くなる

  • できるだけシンプルにする
    • ほとんど実施されない収集・集計・アラートの設定は削除されるべき
    • 収集されるがダッシュボードにもアラートにも作られないものは削除を検討