入門監視の内容を分かりやすくまとめてみた【読書メモ】

この記事では、オライリーから出版されている、「入門監視 ―モダンなモニタリングのためのデザインパターン」の内容を分かりやすくまとめてみます。

少しでもシステム監視に興味を持っている方の参考になれば幸いです。

では始めます。

Contents

入門監視の内容を分かりやすくまとめてみた
おわりに:「入門監視」は全エンジニアにおすすめの書籍

入門監視の内容を分かりやすくまとめてみた

個人的に重要と思う箇所をピックアップしてみました。

はじめに:「入門監視」について

「入門監視」はオライリーから出版されているシステム監視に関する書籍です。

以下の定義に当てはまるシステムの「監視」について、基礎的なトピックが分かりやすくまとめられています。

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である

具体的には、以下のようなトピックたちです。

メトリクス
ログ
アラート
オンコール
障害管理
振り返り
統計

監視に興味を持ち始めていて学びたいと思っている初心者には最適の書籍と言えるでしょう。

入門監視

posted with ヨメレバ

Mike Julian/松浦隼人オライリー・ジャパン 2019年01月17日頃

楽天ブックス

Amazon

監視のアンチパターン

監視にはいくつかの「アンチパターン」があります。それは以下の通りです。

ツール依存
- ミッションに合うツールを模索していくのではなく、ツールを決めてからミッションを決めること
- 効率性や発想の自由度から考えても、よろしくない習慣である
役割としての監視
- 「監視」とは、専門的な仕事（役割）ではなく、全てのエンジニアが持ち合わせていなくてはならない「スキル」である
チェックボックス監視
- 「監視すること」が目的になってしまうこと
- 誤検知の多さゆえにアラートを無視することが常態化するなどの悲劇を生むことが多い
- これを防ぐには、サービスが「動いていること」の意味（監視対象）を明確にした上で、それを監視するような仕組みを取り入れることが重要である
監視を支えにする
- システムが壊れてきたときには、監視を増やすのではなく、根本的にシステムを直す方に注力すべきである
手動設定
- 監視設定は自動化すべきである

監視のデザインパターン

監視のデザインパターンを簡単にまとめます。

組み合わせ可能な監視
- 複数のツールを組み合わせて監視のアーキテクチャを構築することで、柔軟で変更に強い監視システムとなる
- 基本的には以下の5つのツールを組み合わせると良いでしょう
  - データ収集
  - データストレージ
  - 可視化
  - 分析とレポート
  - アラート
ユーザー視点での監視
- アプリケーションが動作しているか（ユーザー視点）での監視設定が最優先である
  - HTTPレスポンスコード
  - リクエスト時間（レイテンシ）
作るのではなく買う
- まずはSaaSの監視ツールを使う。それによりプロダクト自身の開発に集中できる
- 成長するアプリケーションにツールが合わなくなってきたら作ることを考えれば良い
継続的改善
- 常に最善を求めて監視の仕組みを改善し続けることが重要である

アラートのデザインについて

ここでの「アラート」の定義は以下の通りです。

アラートを受け取った人に緊急性があり、すぐに対応する必要があることを認識させるためのもの

アラートをより良いものとするには、以下を意識することが重要とされています。

アラートにメールを使うのをやめる
- メールは人を叩き起こすためのものではない
- アラートはSMS等のページャに送るのが良い
手順書を書く
- アラートが来たときに素早く動くためのもの
- 以下の項目について記載しておくことが重要である
  - 何のサービスで、何をするものか
  - 責任者は誰か？
  - どんな依存性を持っているか？
  - インフラの構成はどのようなものか？
  - どんなメトリクスやログを送っていて、それらはどういう意味か？
  - どんなアラートが設定されていて、その理由は何なのか？
- アラートには手順書へのリンクを貼っておくと良いでしょう
固定の閾値を決めることだけが方法ではない
- システムに応じて「アラートを送るべき状況」をイメージして値を設定することが重要である
  - ex.「アプリの種類に関係なくDBのCPU使用率が○%以上になったらアラートを送る」みたいなのは良くないパターン
アラートを削除し、チューニングする
- アラートに慣れてしまう状態（アラート疲れ）を防ぐためにも、アラートはなるべく減らすことが重要である
- アラートを減らすためには、以下の点を意識すると良いでしょう
  - 本当に誰かが反応すべきアラートが出ているかを考える
  - 過去のアラートを振り返り、削除や閾値の変更ができないかを考える
メンテナンス期間を使う
- メンテナンス期間はアラートを送らない設定にしておくことで、メンテナンスのことを知らない人が混乱することを防げる
まずは自動復旧を試す
- 手順書が単純作業のみで構成されているなら、それらを自動化することに挑戦すべきである
- そうすることでアラート疲れを軽減することができる

インシデント管理について

インシデント管理とは、発生した問題を扱う正式な手順のことです。

有名なフレームワークとしては、ITILがあります。

ITILのインシデント対応の手順は以下の通りです。

インシデントの認識
インシデントのロギング
インシデントの分類
インシデントの優先順位付け
初期診断
必要に応じたレベル2サポート（より権限を持って広範囲に影響を及ぼせる人）へのエスカレーション
インシデントの解決
インシデントのクローズ
インシデント発生中におけるユーザコミュニティとのコミュニケーション

ただ、これらは多くのチームにとっては複雑過ぎます。

より簡易的な手順は以下の通りです。

インシデントの認識（監視が問題を認識）
インシデントの記録（インシデントに対して監視の仕組みが自動でチケットを作成）
インシデントの診断、分類、解決、クローズ
必要に応じて問題発生中にコミュニケーションを取る
インシデント解決後、回復力を高めるための改善策を考える

また、インシデント対応のとき、それぞれの対応者の役割は一つにすべきです。

以下に役割を示します。

現場指揮官（IC、incident commander）
- 決断することが仕事
- 調査や改善等の実際の対応はしない
スクライブ（scribe）
- 起こったことを記録する
- 実際の作業はしない
コミュニケーション調整役（communication liaison）
- 社内外問わず利害関係者に最新状況のコミュニケーションを取る
SME（subject mattter expert）
- 実際にインシデント対応する人

統計入門

統計手法を適切に用いることで、システムに応じたより柔軟な監視が可能となります。

以下に統計の基本的な項目をまとめます。

mean（average）
- 集合内の値を全て足し、その数を集合の要素数で割る
- 時系列データにおいては、「移動平均」を使うことが多い
  - 集合の全てを使って平均を算出するのではなく、最近取得したデータポイント群で平均を算出
- 移動平均により、グラフを平滑化することができ、理解しやすいグラフにすることができる
中央値
- その名の通り集合の中央に位置する値
- 一方向に大きな偏りがあるデータセットを扱う場合には平均より有効な場合もある
周期性
- データポイントがパターンを繰り返すこと
- 周期性から未来を予想してシステム保守に役立てることができる
分位数
- データセットのある点を表す統計手法のこと
- 最もよく使われる分位数は「パーセンタイル（パーセンテージでデータセット内の点を表現する手法）」
- パーセンタイルを用いることで、「値の多くがどうだったか？」という情報が得られる
- ただ、極端な値を無視するので注意が必要
標準偏差
- 平均からどの程度離れているかを表現する