SRE本 6章 (輪読会予習)

社内の有志数人でゆるっと読書会をしているのでその予習資料です。 これまで、テキストメモにしたり、qiitaに下書きしたり、いろいろしてたのですが、今回は はてなブログで書いてみたので、せっかくなので公開します。

(私の解釈によるものや誤読が紛れているかもしれませんので、そのこころづもりで見ていただけたらうれしいです。)

モニタリングの章なので、ところどころ心にしみる箇所がたくさんありました。 大まかにはモニタリングをいかにシンプルに、かつ根本原因にクリティカルパスでたどり着けるようにメンテナンスしていくかという内容だったと解釈しました。 最後に書いてあった、それほど重要ではない進行中の問題はダッシュボードにしてアラートの対象にしない、というのは参考になるなと思いました。

分散システムのモニタリング

定義

  • モニタリング
  • ホワイトボックスモニタリング
  • ブラックボックスモニタリング
  • ダッシュボード
  • アラート
  • 根本原因
    • ソフトウェアの欠陥やヒューマンエラーで、修正されれば同じことが同じように起こることはないと確信できるもの
  • ノードとマシン
    • 一つのサーバやコンテナで複数のサービスが同居していることがある
  • プッシュ

モニタリングの必要性

  • 長期的なトレンドの分析
  • 時間や、実験グループ間での比較
  • アラート
  • ダッシュボードの構築
  • アドホック(限定的な、その場限りの)な振り返りの分析の進行(でバッキングなど)

モニタリングはビジネス分析やセキュリティ侵害の分析にも役立つが、SREの文脈では取り扱わない。 システムが壊れているときは、モニタリングとアラートを組み合わせて人に通知できる。人は時間を割いて対応をする。アラートは「少し何かおかしい」というレベルであげるべきではない。 アラートによるページの発生が頻繁になると、以下のようなことを招く。

  • 従業員が勘ぐる
  • 表面だけを見る
  • やってきたアラートを無視する
  • ノイズに隠れた「本物の」ページを見逃す
  • ノイスは迅速な診断と修正の妨げとなり、障害が長引く

モニタリングにおける妥当な期待値の設定

  • 10-12人程度のSREチームでも、1-2人はモニタリング担当となる。
  • 問題がないか画面をみている必要があるよな状況は避ける
  • 自動的に因果関係を検出しようとするような「魔法の」システムは避けている
    • 仕組みを紐解いて理解できないようなシステムのことかな?
  • エンドユーザのリクエストレートの予想外の変化を検出するルールは例外
    • シンプルなルールで検出できる
  • 複雑な依存関係の扱いはうまくいったことがない
    • データベースの速度が落ちているなら、データベースの速度低下アラートを出す。そうでなければWebサイトの全体的な速度が落ちているというアラートを出す、など。
  • 重要なのは、「プロダクション環境での問題から発する人間へのページ、基本的な切り分けと深いでバッキングに至るクリティカルパス」を、チーム全員でシンプルかつ包括的なものに保つ
  • ノイズを減らし、シグナルをはっきりさせておく

症状と原因

  • 症状が起きている故障で、原因はなぜ故障したか
  • 「何が」と「なぜ」の区別がモニタリングルールを書く上で重要

ブラックボックスとホワイトボックス

  • ホワイトボックス:システムの中で何が起きているかを細かく把握するのには便利。目に見えないけれど起きている問題や、今後起きうる問題を発見するのに便利。システムのボトルネックを探すことなどにも使える。これを元にシステムの改修もできる。
  • ブラックボックス:人間のページを発生させるのに便利。すぐに人間が動かないといけないのは、目に見える問題だから。

4大シグナル

  • レイテンシ
    • リクエストを処理してレスポンスを返すまでの時間
  • トラフィック
    • システムに対するリクエストの量
  • エラー
    • 処理に失敗したリクエストのレート
  • サチュレーション
    • リソースがどれだけ手一杯になっているか

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

  • パーセンタイルも見ようねっていう話

適切な計測の粒度の選択

  • 適切に粒度を選びましょう
  • あまり細かく取りすぎると分析が大変

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

NG

  • さまざまなメトリクスに閾値、アラートが設定されている
  • 考えられる原因(起きていないものも含め)を検出して知らせるための追加コード
  • 考えられる原因のそれぞれに関連するダッシュボード

GOOD

  • シンプルで予想しやすいルール
  • ほとんど使われないルールやデータの集計は消す
  • 収集されているけど、どのダッシュボードにも表示されずアラートにも使われていないメトリックは削除候補のひとつ

複雑に組み合わせず、疎結合に保つのがGOOD。

原則のとりまとめ

書かれている質問をすると問題が明るみになるかも。

アラート関連

  • ルールが検出する事象は、緊急で、対応が可能で、ユーザ影響があるものか?そのルール以外では検出されないものか?
  • アラートは間違いなくユーザ影響があることを示しているか?
  • アラートに対して、取れるアクションはあるのか?
    • そのアクションは緊急か?翌朝まで待てるか?
    • そのアクションは安全に自動化できるか?
    • そのアクションは長期間にわたる修正効果を待つもの?それとも短期間だけ有効な回避策?
  • アラートでページが発生する人は複数いたら、不要なページが混ざっている

ページ関連

  • ページは緊急であるもの。対応できるページは1日に数回が限度。
  • すべてのページは具体的な対応が可能でないとダメ
  • すべてのページには知性が必要でないとダメ。そうでなければ自動化しよう
  • ページは新たなものかこれまで見たことがないイベントに関するものであるべき

長期にわたるモニタリング

システムは変化する。

  • 今後も起こりうるうか?頻繁に起こりうるか?
  • 根本原因に対策すべきか?
    • その対応のために一時的に可用性を落とすべきか?

などを長期の視点で検討していこう。

BigtableのSRE:過剰なアラートの物語

  • アラートが出すぎて短期的な対応しかできなくなったで、一時的に可用性を落として、対策に取れる時間を増やしたら結果、より短い時間で解決できた例

Gmailスクリプト化された予測可能なレスポンスの手動送信

  • 暫定対応をとるか、根本対策をとるかで議論した例。マネージャーはそこのバランスをきちんとおさえておく必要がある。

長期的な視点

すべての問題を独立したイベントととらえず、全体をみて長期的に戦略をたてましょう。 ページの頻度などを四半期に一度程度見直しましょう。

まとめ

メールアラートの価値は限定的で、ノイズ化するのも簡単。 それほど重要でない進行中の問題はダッシュボードでモニタリングしてアラートの対象にしない、ということもよい。(アラートグループ的な考え) アラートは差し迫った本当の問題だけにしよう。