Monitoring
システムの監視ポリシーについて述べる。
監視の定義
あるべき状態が保たれていることを、適切な頻度で確認し続けること。そして保たれなくなったら検知すること。
- あるべき状態の例
- サービスが動いている
- SaaSの費用をちゃんと払っている。そして金額も妥当な範囲に収まっている
- バッチが時間内に終わっている。途中で停止せず処理が最後まで行われている
-> どういう状態であってほしいのかから入る。手段からスタートしない。
- 適切な頻度で確認し続けることの例
- DBの停止や再起動は起きたら即
- WEBサービスの外形監視はN分おき
- 指標のトレンド確認は週次でいいことがほとんど
-> 対応の緊急性に応じて合理的に設定。やりすぎはコストを増やす。
- 保たれなくなったら検知することの例
- 緊急性の高いアラートはメールだけでなく電話も使って受け損ねを防止
- 重要だが緊急ではないエラーのアラートは随時メール
- 重要でも緊急でもないエラーはサマリーレポートを毎日決まった時間に確認
-> こちらも緊急性に応じて受ける方法を用意。監視漏れも監視疲れもよくない
なにを監視すべきか、すべきでないか
監視対象は、まずあるべき姿を洗い出し、そこからどう正常性を確認するのかを考えていく。あるべき姿はプロジェクトの性格によって異なるため、プロジェクトの性格に応じてカスタマイズする。監視内容によってはアプリケーションに可観測性のための機能を持たせる。どんなサービスでもこれだけやっておけば妥当と保証できるチートシートは元から存在しないのであり、手段から対象を決めるべきでない。
監視対象の違いの例)
- B2Cの情報提供系サービス : 24時間365日サービスが落ちないこと、レスポンス速度も妥当であること -> サービスの外形監視、レスポンス速度の監視等
- バッチ処理系のサービス: 処理時間が突き抜けないこと、途中で止まっていないこと、また過去の実施時と比べて極端に取り扱うデータ量が減っていないこと -> 処理時間や実行結果をログでだすようにした上でのログ監視、アプリケーション組み込みの簡易なレポートを定期的に確認する等
また監視は対応とセットである。対応ノウハウの共有のため、可能なものは手順や判断基準をあらかじめドキュメント化しておく。それが難しいものは対応後に記録を残して関係者が（許されるならAIも）いつでも参照できるようにする。
ノイズアラートの防止
不要な監視は行わない。メンバーの疲弊やアラートの見落としを誘発するためである。 このため追加は本当に必要か検討した上で行う。一度追加してしまうと、実際はフォールスポジティブばかりで役に立たないアラートでさえ、責任問題となるリスクにより削除しづらくなる。
まず、アラートの発報を伴う監視は対応可能性とセットで考える。対応不要あるいは対応不能なことに発報すべきでない。
意味のあるアラートの例
- データベース用サーバーのメモリ残量のひっ迫 -> スケールアップやスケールアウト
- 特定IPからの大量不正アクセス -> WAFやアプリケーションにフィルタ追加
意味のないアラートの例
- オートスケールの実行時にアラート -> 対応が必要ない
- AWSのCloudFrontの死活監視 -> 対応できることがない
具体例
ポリシーとしては上記のみであるが、理解の促進のためWEBアプリケーションを例にとって具体例を付け加える。
この場合、まずエンドユーザーつまり利用者にサービスが提供し続けられていること。ひっくり返すと、提供し続けられなくなるような事態になっていないこと（異常検知）、もしくはいずれ重大な障害が出ると予想されないこと（予兆検知）が必要である。この前提で、WEBアプリケーションで各レイヤごとに監視すると例えばこのようになる。
- ユーザー体験: 外形監視、レイテンシ監視など
- アプリケーション: ログ監視、エラー時の直接発報、ジョブキューの過剰滞留など
- インフラ: リクエストのエラー率（5XX）、アプリケーションサーバの稼働数（スケールアウトに関係）、マネージドサービスの強制メンテナンス予定、EOL予定、ドメインや証明書の残り日数など
次にそのサービスを続けていけること。このために具体的にはセキュリティやコストを監視する。
- セキュリティ: 脆弱性、マルウェア、悪意のあるアクティビティなど
- コスト: 通常ではありえない額の課金、Reserved Instance等割引サービスの残り日数など
また監視はアラートだけセットするのではなく、トレンドを見るためのメトリクスとそれをまとめたダッシュボードも用意する。問題の存在を告げるトレンドが出ていたら対応が必要である。例えばレイテンシが悪化していく一方であったり、メモリの残量が下がっていく一方であったりするなら、なんらかの不具合が隠れている可能性が高い。
- CPU使用率・メモリ使用率
- レイテンシ
一方で必要性の薄いアラート、有用性の低いアラートは流さない。
- オートスケーリング発動: 対応不要のため鳴らす意味がない
- CPU負荷の変化率(※): フォールスポジティブに悩まされやすく有用性が低い
※ 例えば30%の急上昇をセットするとCPU負荷が10%から13%になるだけで発報される。このようなことでメンバーに確認を要求するのは不適切である
監視の必要性そのものを削る
監視とアラート対応は本質的に重たい業務であるから、極力監視対象や発報を減らせるシステムを最初から設計する。
例)
- オートスケーリングを導入してCPU負荷による発報を事実上ゼロにする
- オートリカバリ付きのマネージドサービスを使うことで、サービスダウンしても人が再起動しなくてよいようにする
逆にEC2のような自前でサーバーを運用するタイプのリソースは、脆弱性・マルウェア・悪意あるアクティビティ・プロセスの死活・ストレージの残量・CPUやメモリの使用率等大量に監視項目を必要とするため、極力最初から避ける。
さらに、これはビジネスレイヤにまで上がってくるため本ドキュメントの議論の範疇からは外れるが、そもそも割に合わないサービスを作らない・あるいは適切にクローズすることはとても大きな効果を発揮する。
アラート対応をいつ誰が行うか
アラート対応は極力システムによるカバーを行う。どの場合も最終的には担当の責任者が最後の砦となるが、この砦は摩耗しやすくコストも高い。そのため検知・通知・一次対応は可能な限り自動化または半自動化する。
またアラート対応の責任範囲と対応時間はあらかじめ定義する。例えば以下のように整理する。
- 緊急性が高いもの：即時対応
- 重要だが緊急でないもの：営業時間内に対応
- 低優先度のもの：定期レビューで確認
「念のため」でアラートを関係者全員に送る運用は、メンバーの消耗を招くため極力避け、対応の当番にのみ送る。また誰が最終的に解決責任を持つかを明確にする。
実際は誰が行えるのか？
実際に誰が対応を行うかは、現実的なリソース制約を踏まえて決定する。対応体制は以下のいずれか、または組み合わせで設計する。
- オンコール体制を構築し、担当者・部署・外部サービスに責任を割り当てる
- 限定された担当者による当番制とし、順次エスカレーションする
- 対応不能なケースが発生することを前提に、許容できる影響範囲を事前に検討する
理想としては専門の運用体制を設けることが望ましい。だがプロジェクトの状況次第では他業務と兼任する形での対応もやむを得ない。ただし兼任は本来の業務や生活への影響を招くことが避けられず、対応品質の著しい低下や甚だしきは離職につながるため、持続可能な体制を前提に設計する。特に夜間対応については慎重に取り扱う。
いずれの場合も、関係者の消耗を最小限に抑えるため、誰が対応責任を持つかを明確にする――逆に言えば、責任を曖昧にすることで全員を責任者扱いするのは避ける。また夜間のアラートは本当に必要なものだけにする。
対応体制は理想ではなく現実に合わせ、過剰な負担や、問題が起きた際に後付けで責任を追及する運用は避ける。
利用するサービスの選定とコスト最適化(How, Cost)
監視基盤の選定は、プロジェクトの性格（チーム規模・監視対象の規模・カスタマイズ要件・コスト構造等）を踏まえて判断する。通常、単一のツールやサービスで完結させることは現実的でないため、メトリクス・ログ・トレース・アラート管理など様々なサービスやツールを組み合わせる。
監視設計は、収集・保存・可視化（活用）の各段階に分け、それぞれ必要最小限となるよう設計する。コスト最適化のため過剰なデータ収集や高頻度の監視は避け、必要な分だけ利用する。特に大量のログの収集と保存はコスト増の要因となりやすいため出力レベル・フィルタ・サンプリング・保持期間を適切に設計する。
またメトリクスを並べたダッシュボードが複数あることも許容する。全データを一サービスにまとめるためのコストは大きく、しかも一望できるメトリクスはどの道限られるからである。
ツールの選定
運用負荷の軽減と属人化防止の観点から、基本的にマネージドサービスやSaaSの利用を優先的に検討する。これらは一見コストが高く見えても運用負荷の軽減や属人化防止、運用品質等のメリットを考慮に入れると総合的には有利になりやすい。また、設定をIaC化し、Gitで管理することで再現性と変更履歴の透明性を担保できるものを選ぶ。
強いカスタマイズ要件等、特別な条件がある場合には様々な課題を受け入れて自前で構築・運用することを検討する。ただしこの場合は監視基盤自体の信頼性も確保する必要が生じることに留意する。監視システムが落ちていたり、あるいは一部の監視が止まっていることに気づかず数日以上放置されるケースは珍しいものではない。
なおどのようなツールを用いる場合も、監視基盤は定期的に利用状況をチェックする。時間をかけすぎるのも問題であるが、コスト最適化の観点から、使わないにもかかわらずログを読ませていたり、必要なくなった監視が残っていたりするような状態は改善が必要である。
参考
Show Text to Shareシステムの監視ポリシー Monitoring https://www.tricrow.com/policies/monitoring.html
