MogLog

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

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

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

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

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


定義

  • モニタリング
    • システムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと
    • 例:クエリの回数と種類、エラーの回数と種類、処理時間
  • ホワイトボックスモニタリング
    • システムの内部によって公開されているメトリクスに基づくモニタリングのこと
  • ブラックボックスモニタリング
    • ユーザが目にする外部の振る舞いをテストする
  • ダッシュボード
    • サービスの主要メトリクスのサマリビューを提供するアプリケーション
  • アラート
    • 人間に読まれることを意図した通知で、メールアドレスやページャなどのシステムにプッシュされる
  • 根本原因
    • ソフトウェアの欠陥やヒューマンエラーのうち、修正されれば同じことが同じように起こることがないと確信できるもの
  • ノードとマシン
  • プッシュ
    • サービス動作中のソフトウェアあるいはその設定に対する変更
    • memo: デプロイに近い??

モニタリングの必要性

  • なぜシステムをモニタリングするのか。その理由。
  • 長期的なトレンドの分析 のため
    • 日次のアクティブユーザがどういったペースで増加しているのか、など
  • 時間や、実験グループ間での比較 のため
    • ライブラリAとライブラリBではどちらの方が高速なのかを比較したり、サイトの速度が先週と比べてどうなっているかを比較したり
  • アラート のため
    • 何かが壊れていることや壊れそうなことを通知する
  • ダッシュボードの構築 のため
    • ダッシュボードは、サービスに関する基本的な疑問に答えるべきもの
  • アドホックな振り返り分析の進行(デバッギングなど) のため
    • レイテンシが急上昇したが、同タイミングで他に何らかの変化が生じていなかったか、など

症状と原因

  • モニタリングシステムは、2つの疑問に答えなければならない。それは、 “何が壊れたのか"と"なぜ壊れたのか” という疑問である。
    • “何が壊れたのか"という疑問は 症状 を示す
    • “なぜ壊れたのか"という疑問は 原因 を示す
  • “何が"と"なぜ"の区別は、シグナルを最大化し、ノイズを最小化する優れたモニタリングルールを書く上で最も重要な区別である

症状と原因の例

症状 原因
HTTP500もしくは400が返されている データベースサーバが接続を拒否している
レスポンスの速度が低下している CPUに過大な負荷がかかっている

4大シグナル

  • モニタリングにおける4大シグナルは、 レイテンシ、トラフィック、エラー、サチュレーション である。ユーザが直接利用するシステムで、メトリクスを4つだけ計測できるとするならば、この4つに集中する
  • レイテンシ
    • リクエストを処理してレスポンスを返すまでにかかる時間
  • トラフィック
    • システムに対するリクエストの量で、システム固有の高レベルのメトリックで計測される
    • Webサービスの場合、通常は毎秒のHTTPリクエスト数で計測されるが、リクエストの性格によって区分けされることになる
      • オーディオストリーミングのシステムであれば、ネットワークIOレートや同時セッション数に計測の焦点があたるが、キーバリューストレージシステムであれば、毎秒のトランザクションや取得数を計測することになるだろう
  • エラー
    • 処理に失敗したリクエストの割合
    • 失敗には明示的な場合、暗黙的な場合、ポリシーによる場合とがある
      • 明示的な場合:HTTPの500番台
      • 暗黙的な場合:HTTP200の成功レスポンスが返されているが、内容に間違いがある
      • ポリシーによる場合:例えば「レスポンスタイムを1秒以下にすると約束しているなら、1秒以上かかったリクエストはエラーである」というようなもの
  • サチュレーション
    • サービスがどれだけ「手一杯」になっているかを示す
    • そのシステムにおいて最も制約のあるリソース(メモリ、IOなど)に重点を置いて、システムの利用率を計測する

テイルレイテンシに関する懸念

  • 平均値のメトリクスの収集は危険になる場合がある。例えばCPU使用率やデータベースの平均使用率など、状況によって簡単にアンバランスになり得るものがあるため
  • 動作させているWebサービスの平均のレイテンシが毎秒1000リクエストの状況下で100msだったとして、リクエストの1%が5秒を占めることは容易に起こり得る
  • 低速な平均と、非常に低速なリクエストの「テイル」を最もシンプルに区別するには、レイテンシそのものよりも、レイテンシでパケット化したリクエストカウントを収集する。
    • 例:0 ~ 10ms、10 ~ 30ms、30ms ~ 100ms、100 ~ 300msといったような時間で処理したリクエストはそれぞれいくつだったかを見る

適切な計測の粒度の選択

  • システムの様々な側面は、粒度のレベルを変えて測定するべきである
  • 例えば、CPU使用率を毎秒収集すれば興味深いデータが得られるかもしれない。しかしこのような頻度での計測は収集、保存、分析のコストが非常に大きくなる。
  • サーバ内でサンプリングを行っておき、それらのサーバから順次データを収集して集計を行うように外部システムを設定すればそれらのコストを下げることができる(あくまで例)

可能な限りシンプルに、ただしやり過ぎないこと

  • これらの要求を全て積み上げると、モニタリングシステムは非常に複雑になってしまう
  • モニタリングシステムの設計をする際は、シンプルさに目を向けるようにする。以下は、モニタリングの対象を選択する上でのガイドライン
    • 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべき
    • ほとんど実施されないデータの収集、集計、アラートの設定は削除すべき
    • 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示せず、どのアラートにも使われていないシグナルは、削除の候補

原則の取りまとめ

※ ここは全くの写しになりそうなので書籍参照。