より良い監視を実現するために、無駄を省いて監視を最適化しよう

はじめに

前回は、監視とは何か、どのような監視をするべきかについて解説しました。一般的なセオリーに則って構築されたITシステムであれば、本番環境を一切監視していないということは、さすがにないでしょう。しかし、同時に「それっぽい項目を監視して、メトリクスを眺めているだけ」で、適切な監視項目の選定やハンドリングが行われていない監視が多いのも、残念なことに事実です。

そこで今回は、監視を始めた際に陥りがちな、監視のアンチパターンについて解説します。

アンチパターン1：見ている項目が多すぎる

大抵の監視ツールは、導入するだけで主要なメトリクスが取得されるようになっています。また、デフォルトで充実したダッシュボードが提供されているケースも珍しくありません。しかし、それらのメトリクスのうち、本当に監視する価値のあるものは、どれだけあるのでしょうか。

サーバーのCPU負荷、メモリ使用量、ストレージの空き容量、ディスクI/O、ネットワークトラフィック等々、ダッシュボードに所狭しと並んだメトリクスを眺めているのは楽しいですし、まさに監視をしている気分を味わうことができます。しかしダッシュボードの見栄えこそ良くなるものの、不要な情報はノイズにしかなりません。

もちろん、多くのメトリクスを取得することに意味がないとは言いませんが、ダッシュボードには本当に必要な情報のみを登録すべきでしょう。そのグラフは、本当に必要でしょうか?

アンチパターン2：誤報が多すぎる

前回でも述べたように、監視に誤報はつきものです。アラートの条件となる閾値を正確に導出することは難しいため、ある程度の誤報は監視の宿命として受け入れなければならない側面もあります。しかし「仕方ない」と諦めるのではなく、誤報をなくすよう少しずつ閾値をチューニングし、監視の精度を上げていく努力をすべきです。

以下は監視の現場で、よくありがちな会話です。

見なくても良いことが分かっているのであれば、そのアラートは見直す必要があるでしょう。記録に残す必要があるイベントでも、少なくともメールやチャットで担当者に通知を送ることはやめるべきです。こうしたアラートを放置し続けると、アラートはいずれ狼少年になってしまい、最終的には誰もアラート自体を見なくなってしまうでしょう。

また、監視初心者は「せっかく監視しているのだから」と、すべてのメトリクスに閾値とアラートを設定しまいがちです。万が一にも障害を見逃さないよう、万全の体勢で望みたいという気持ちは理解できますが、これも大抵の場合は意味がないでしょう。詳しくは後述しますが、システム全体の稼動に影響を与えないイベントに対して1つ1つアラートを上げる必要はありません。無駄なアラートは運用担当者を疲弊させるだけなのです。

アンチパターン3：イベントの詳細を追跡できていない

アラートで障害の発生に気づき、復旧対応ができることは大前提ですが、監視の役割はそれだけではありません。同じような障害が再発しないよう、原因の究明と解決もまた、監視の重要な役目です。例えばメトリクスを監視していればリソースの変化に気づくこともできますが、メトリクスは単なる数値でしかありませんから、何が起きたのかまでは読み取れません。

こうした例は非常によくありがちです。メトリクスだけでは不十分なため、ログやトレースといった情報も記録し、付き合わせて調査できる必要があります。例えば監視ツールの中には、アラートの発生時にプロセスリストをはじめとするシステムの情報一式を取得し、付随情報として記録するものもあります。こうしたツールを利用してみるのも良いでしょう。

「本当に知りたいことは何か」を考えよう

前回で「監視は手段に過ぎず、あくまで目的はシステムを健全な状態に保つことだ」と解説しました。そのためにはまず、システムがどのような振舞いをしていれば健全な状態と言えるのか、しっかりと定義するところから始めなくてはなりません。例えば一般的なWebアプリであれば「リクエストを受け付け、許容される時間内に、想定通りのレスポンスを返せること」のように定義できるでしょう。

こうしたケースでは、前回紹介した外形監視が有効ですが、Pingのようにネットワークレベルの導通を確認するものでは不十分です。例えば「Pingに応答はあるし、Webサーバーにも接続できていたが、実はアプリケーションエラーで真っ白なページが返っていた」といった障害もありがちです。こうした問題を検出するには、実際にAPIをコールし、ログインなどアプリの機能を利用する高レベルな監視が必要になってきます。

そしてアプリがレスポンスを返せているのであれば、内部のメトリクスが多少変動したからといって、それは些細な問題に過ぎません。前回も挙げた「サーバーのCPU使用率が90％を越えたらアラート」などは非常にありがちなアラートの例ですが、アプリが制限時間内に正しく応答できているのであれば、このアラートを上げる意味はあるのでしょうか。もちろん、想定よりも負荷が上がっているのであれば、それは事実として把握しておくべきです。しかしまだ障害が起きておらず、システムが稼動しているのであれば、こうした些細な問題はアラートとして上げるべきではありません。

同様にサーバーを死活監視し、サーバーダウン時にアラートを上げるのもありがちなパターンですが、これも考えものです。ひと昔前のオンプレミスであればいざ知らず、近年のクラウドを利用したシステムであれば、ロードバランサーと複数インスタンスを利用した高可用性の構成は当たり前になっています。こうした構成では、サーバーが1台停止したからといって、ただちにシステムが機能不全を起こすわけではありません。またヘルスチェックに失敗したサーバーは自動的に排除され、自動起動設定により減った分のサーバーは自動的に補充されるのが一般的でしょう。

こうした自律的な復旧が可能なシステムでは、サーバーが1台ダウンした程度で、いちいちアラートを上げる意味はありません。もちろん想定しないサーバーのダウンは問題ですから、イベント自体の記録は残すべきですが、運用担当者を寝不足にする理由としては不十分でしょう。

インシデント管理の必要性

繰り返しになりますが、監視は手段に過ぎず、あくまで目的はシステムを健全な状態に保つことです。これはアラートについても同じことが言えます。障害を検出し、アラートを送信すればそれで終わりではありません。

ソフトウェア開発において発生したバグは、バグトラッキングシステム(BTS)を使って追跡管理するのが一般的です。バグをシステムで管理しないと、バグ修正に担当者がアサインされず宙に浮いてしまったり、作業状態が把握できなかったり、バグの修正がリリースから漏れてしまったりといった問題が起こる可能性があるためです。そしてBTSに登録されたバグには優先度が決められ(バグトリアージ)、決められた作業フローに沿って修正、テスト、リリースが行われます。

運用時における障害も、これと同じだと言えます。いつ、どのような障害が発生したのか。それはただちに対応する必要があるのか。ならば対応を担当するのは誰なのか。現在の復旧作業はどのような状態になっているのか。そして、いつ障害が解消したのか。発生した障害に場当たり的に対処するのではなく、こうした情報をきちんと管理し、あらかじめ決められたワークフローに従うべきです。これをインシデント管理と呼びます。

インシデント管理はバグ管理と同様に、専用のツールを用いて行います。インシデント管理のためのSaaSとしては「PagerDuty」が非常に有名です。またインシデント管理について理解を深めたいのであれば、PagerDutyが公開しているドキュメントを一読しておくと良いでしょう。

おわりに

より良い監視を実現するためには、まず意味のない監視を減らしましょう。そしてアラートをチューニングして精度を上げましょう。そもそも無駄なアラートは止めてしまいましょう。インフラは可能な限り自律的に復旧できるような構成を目指し、そもそものアラートの原因を減らすことも大切です。

また、アラートにはエスカレーションを設定することをお勧めします。例えばアラートの第一報はオンコール担当者にのみ送信し、一定時間が経過してもアラートが解消されない場合に限り、他のメンバーに第二報を送るといった具合です。適切なエスカレーションを設定することで、オンコールを担当していないメンバーの睡眠時間を守ることができます。

DevOpsの柱の1つに自動化があります。インフラ構築、テスト、ビルド、デプロイなど、様々な場面において、コード化と自動化が推奨されています。しかし監視と障害対応は、どうしても最終的には人間の手に頼らざるを得ない部分があります。これはどうしても避けられないため、可能な限り人間に負担をかけない監視を目指しましょう。