Site Reliability Engineering #6
6章 分散システムのモニタリング
6.1 定義
- モニタリング
- システムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと
- ホワイトボックスモニタリング
- システム内部のメトリクスでログ、JavaVM Profiling interfaceなど統計情報が得られるインプット
- ブラックボックスモニタリング
- ユーザが目にする外部の振る舞い
- ダッシュボード
- 主要メトリクスのサマリビュー
- アラート
- 人間に読まれることを意図した通知
- チケット、メールアラート、ページに分類される
- 根本原因
- 修正されたら同一の事象が起きないと確信できる原因
- ノードとマシン
- プッシュ
- サービス動作中のソフトウェア、設定への変更
6.2 モニタリングの必要性
システム自身が壊れた、壊れる予兆を次のモニタリングとアラートによって人間に通知ができる。
人間へページすれば貴重な時間を消費することになる。 効率的なアラートは人間が取り組む対象に絞られた室の高いシグナルに絞り、ノイズを低く抑える。
6.3 モニタリングにおける妥当な期待値の設定
GoogleのSREチームでは10人〜12人のメンバのうち、担当するサービスのモニタリングシステムの構築とメンテナンスに1人か2人を割り当てる。
重要なのはプロダクション環境での人間へのページ、切り分け、デバッギングに至るクリティカルパスをチーム全員でシンプルかつ包括的に保つこと。
6.4 症状と原因
モニタリングシステムは何が壊れたか、なぜ壊れたのかという2つの疑問に答えなければならない。
症状は観測された振る舞い、原因は振る舞いを起こしたメカニズムである。
6.5 ブラックボックスとホワイボックス
ブラックボックスは「現在、システムが正常に動作していない」という症状を扱う。 ホワイトボックスはログやHTTPエンドポイントといったシステム内部を調査する機能に依存する。
6.6 4大シグナル
- レイテンシ
- トラフィック
- エラー
- サチュレーション
6.7 テイルレイテンシに関する懸念(あるいはインスツルメンテーションとパフォーマンス)
レイテンシの傾向を判断するには算術平均よりも、ヒストグラムが優れている。 例えばリクエストの1％が低速の原因を占めることが起きうる。
6.8 適切な計測の粒度の選択
システムの様々な側面が粒度のレベルを変えて測定するべきである。 粒度を細かくしすぎると収集、保存、分析のコストが増大するため、バランスに注意する。
バランスを取るにはバケット化することで知りたい粒度にしながらコストを軽減できる。
6.9 可能な限りシンプルに、ただしやりすぎないこと
モニタリングシステムの設計はシンプルさに目を向ける。 モニタリングシステムが複雑になりすぎると、複雑でメンテンナンスが負担になりうる。
モニタリングの対象を選択するには次のガイドラインに沿って検討する。
- 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで予想しやすく信頼できるものであるべき
- 四半期に1回未満のデータの収集、集計、アラートの設定は削除すべき – 収集されていてもダッシュボードに表示されない、アラートに使われていないシグナルは削除の候補である
6.10 原則の取りまとめ
モニタリングやアラートのルールを作成する際には以下の質問に沿って要否を判断する。
- ユーザに近い将来含めて影響を及ぼす、ルールなしでは検出されないものか
- アラートを放置しても影響がないものか
- ユーザに悪影響が生じていいることを示しているか
- アラートに対してアクションが取れるか、不要不急なものか
- ページを受ける人が複数か、そうであるならば1人にできないか
6.11 長期間に渡るモニタリング
今日発生している一つ一つのページに人が対応するのは、明日のためのシステム改善にあてる時間がなくなる、というトレードオフの関係にある。 システムの長期的な展望を改善するために可用性なパフォーマンスの短期的な低下を受け入れることもある。
6.12 まとめ
メールアラートの価値は限定的でノイズになりやすい。代わりにダッシュボードでモニタリングすると良い。 長期的にはオンコールのローテーションとプロダクションを成功に導くため、達成可能な目標にターゲットを合わせてモニタリングシステムが素早い診断を確実に支援できることが必要である。
