システムの価値を維持・向上させるために必要な“監視”　5つのありがちなアンチパターンとベストプラクティス

自己紹介

はまーん氏（以下、はまーん）：監視ってまぁ面倒くさいですよね。「メトリクスとログ集めてるだけです」「無視してるアラートが実はいっぱいあるんです」「なんで監視してるんだっけ」。こんなことを思ったことないでしょうか。僕は昔、思ったことがあります。

僕のほうからは、今日の事例祭り始めるに当たってのイントロダクションというか。「システム監視ってなんだっけ」を考えて、AWS上で小さく、そして的確に監視を始めるためのスタートラインに立てるようなお話をします。

はじめましての方ははじめまして。お久しぶりの方はお久しぶりです。AWSでSA（ソリューションアーキテクト）をしている、ハマと申します。大阪のSAとして、SaaSをやってるお客さまの担当のSAやエンタープライズなお客さま担当のSAを経て、4月から西のスタートアップSAとしてジョインしました。スタートアップのみなさん、これからよろしくお願いします。

（AWSとは）関係ないところで趣味があって。僕、家を作るのが趣味で。家作るのが趣味っておかしいですが、最近関西の田舎で一軒家をぶっ建てました。この1年間、ずっと家のことばかり考えていたので、今はもしかしたらAWSのこと以上に詳しいかもしれません。

引っ越してからはもっぱらIoT大臣として動いてるので、もし家の購入を検討していて質問したいという方は、DMとかもらえればと思います。

セッションのアジェンダ

ちょっと余談が過ぎましたが本題です。アジェンダです。以下の内容で進めていきます。まずはそもそもなぜサービスを監視するのか。監視システムにはどんな要素が必要なのか。その基本を振り返りたいと思います。

それから、ありがちな監視におけるアンチパターンや、それに対する解決策。考え方をこういくつか紹介したうえで、スタートアップのみなさまがAWS上で稼働するサービスに対して、小さく、そして的確に監視を始める際の技術選定についてのエッセンスや指針を紹介できればと思います。

最後にまとめと、このセッションを聞いた後のネクストアクションなどを紹介できればと思います。

なぜサービスを監視する必要があるのか？

まずは、「なぜサービスを監視するのか？」「監視システムにはどんな要素が必要なのか？」、その基本を振り返りたいと思います。このセッションを聞いている方の中には、「それぐらい知ってるよ」という方もいると思いますが、本日参加されているみなさんの前提をそろえるために、まずは監視についての基本的なところをお話ししていきます。

なぜサービスを監視する必要があるのでしょうか。大前提ですが、システムはある日突然壊れたり、よくわからない状態に陥ります。これはもう、残念ながらそういうものです。システムそのものが起因することもあれば、取り巻く環境によっても左右されます。

わかりやすい環境の例でいうと、Webシステムにおける、ブラウザやエンドユーザー環境に起因するトラブルです。そして、この「突然壊れる（事象）」に対して、サービスプロバイダは定期的に継続的にシステムを観測して、これを検知・予知して対応する必要があるわけです。

監視とはまさにこのことで、異常を検知して復旧させることにほかならないのですが、もっとポジティブに広い意味でいうと、監視とは「定期的・継続的に観測することでシステムの価値を維持・向上させるために行う行為すべてを指す」と言えます。

ではその監視ですが、さまざまです。監視といってもいろいろあります。みなさんは“監視”と聞いて、いったい何を思い浮かべたでしょうか。

インフラ周りをやってきた人なら、サーバー監視を（思い）浮かべた人が多いんですかね。アプリケーションエンジニアだったら、アプリケーション監視。セキュリティエンジニアだったら、セキュリティ監視。まさに今日のテーマの1つであるセキュリティに関する事象も、もちろんこの監視の対象なわけです。

監視システムは3つの要素で構成されている

ではその監視システムですが、大まかに3つの要素で構成されているといえます。（スライドを示して）この図はかなり簡略化して表現しています。観測、データ収集、そしてデータ利用です。

観測はCloudWatchで表現していますが、一律にインストールしてるCloudWatchエージェントがまさにそれです。監視対象を観測し、データを取得する。

これはプッシュ型なのでこのようなかたちですが、例えばプル型の監視システムだったら監視システムそのものがアクセスしていくので、そこがデータの観測部分になったりします。

データ収集です。取得した部分を監視しているシステムに集める部門です。CloudWatchだったらCloudWatch Metricsだったり、Logsだったり、いろいろありますね。

最後にデータ利用です。これが必要なわけです。集めたデータを利用して、正常性の判定や通知を行います。プッシュ、SMSでショートメッセージ送ったり、クエリエンジンでこうログを解析したり、ダッシュボードで可視化したり、いろいろありますね。

CloudWatchで表現しているので「まぁそういうもんだろ」と見えるかもしれませんが、裏側にはたくさんいろんなコンポーネントがあるわけです。

例えばデータ収集の部分でいうと、データを格納するデータベースみたいなものも必要になります。時系列データベースとか、そういったものが必要になってくるわけですね。監視システムだって、ダッシュボードを可視化するためのクライアントの仕組みとか、いろいろものが必要になってきます。

こうしたさまざまな要素が集まって、監視システムを構成しています。どうでしょう。作ろうと思うと「複雑だな」ということが伝わったんじゃないでしょうか。

アンチパターン1：監視ツールを選んでそこから進まない

続いて監視にまつわる、ありがちなアンチパターン。それに対する考え方や、ベストプラクティスをいくつか紹介していきます。

まずアンチパターン1です。監視ツールを選ぶところから始めてしまう。これはどういうことかというと、監視ツールは手段ですよね。それを選ぶところから入ってしまって、結果そこで満足をしてしまう。その先が進まないわけです。これがなぜだめなのかが、この後の改善策に入っていきます。

本来ツール選定というのは、監視計画と一緒に考えるべきです。ツールはあくまでも1つの手段なので、それに至る何かを考えてこないと（いけない）。そこで満足してしまうと、その先がなくて、本来の、最初に言った「なぜ監視するのか」が実現できなくなってしまいます。

例えばモニタリングの目的は？　なぜモニタリングするのか。モニタリングは何を対象にするのか。どれくらいの頻度でこれらのリソースにモニタリングするのか。で、ツールは？　誰がやるのか。そして問題が発生した時に誰が通知を受け取るのか。

いろいろ考える必要があるわけです。「あくまでツールの選定は手段の一つでしかなくて、さまざまな事象と併せて一緒に考えるべきだ」というところが1つのベストプラクティスです。

アンチパターン2：メトリクスとログをとりあえず集めて満足する

2つ目のアンチパターンが、メトリクスとログをとりあえず集めて満足。これ、やったことある人が多いんじゃないかなぁと思います。メトリクスとログのデータを収集して終わっているパターンです。集めてはいるんです。集めてはいるけれど、それを見るとか、この先の改善とか維持に活かしてるかといったらそんなことはないんですね。

障害発生後、初めてこれらのデータを見る。そうするとどうなるか。見方や調査方法がわからなくて、てんやわんやに。

改善策はシンプルです。監視データの分類と、対応パターンを定義するということです。具体的に何かってかはこの後のスライドにあるので、そこで説明します。

ただただ監視するだけではなくて、デイリーやウィークリー、マンスリーで監視データを、例えばチームミーティングみたいな場でウォッチする。

「これはこういう目的だから大丈夫だ」「これはおかしいから調査する必要がある」「この通知はちょっと要らないよね」とか、監視項目やデータを継続的に確認する場が必要です。

そしてこれも大事です。調査対応時は複数名で当たり、ノウハウを共有してください。これについては別のアンチパターンで紹介しますが、「特定の個人に依存しないようにしましょう」というところですね。

アンチパターン3：アラート疲れになる

そしてアンチパターン3。無視していいアラートがいっぱいある。これはどういうことかというと、たくさんのアラートが飛んでくるわけですね。監視して、いろいろな監視に対して「とりあえず通知しよう」となった結果、アラートがいっぱい飛んでくると。

結果どうなるか。アラート疲れ、アラート燃え尽き症候群になってしまいます。これはどういうことかというと、たくさんアラートメールが飛んできますが、基本は対応の必要がないアラートなんです。対応していないとか。

例えばCPU使用率80パーセント（のアラート）とか。わからないけれど、見た感じ大丈夫そうなので放置してエラーとか。CPU使用率80パーセントというアラートも必要そうに見えますが、これ自体特に意味はないんです。この先（に起こること）で、例えばシステムやサービスがダウンしている、レスポンスタイムが劣化している。これらが問題です。

ただ、使用率が80パーセントそのものには意味がないわけです。こういうものがいっぱい飛んでくると、「見た目上は問題ないんだけどなぁ」とアラート疲れをしていくわけです。

そして結果どうなるか。ある日、重要なアラートを見逃して大障害につながる。“オオカミ少年”になってしまうわけです。

このアンチパターン3に対する改善策としては、さっきと一緒です。監視データの分類と対応パターンを定義することが重要です。

「何に、どのデータに、どの監視項目に対してはこういうアラートをする」とか。例えばメールが必要なタイプ。「チャットや電話が必要」とか、「これは別に見れればいいよね」「これはそもそもたまってるだけでいいよね」などの分類が必要なわけです。

そして、この分類の中で即時対応が必要な異常に対して、強力な通知を行うようにしてください。強力な通知というのは、先ほども言ったような、例えば電話とかチャットとかDMとか、そういったものです。

具体的に即時対応が必要なケースというのは、HTTPのレスポンスコードとかリクエスト時間とか、ユーザーから近い部分です。今すぐに対応しないといけない。こういったものは強い通知にしましょう。また、オートリカバリーみたいなものを含んでしまえば、そこに関してもリカバリーしていけるわけです。

あとは誤検知も含め、定期的にアラートをメンテナンスしましょう。これが意外とできてない方が多くて。アラートを出しっ放しで、その後ちゃんと「これ要らないよね」「これが必要だね」ということが、意外とできてなかったりします。

先ほどから言っていた、監視データの分類と対応パターンです。（スライドを示して）これは下の文献から引っ張ってきたものですが、大きく4つに分けられると思います。

異常を検知して、即時対応したい。システム自体がダウンしてる時とかはまさにそうですね。もちろん観測はするし、異常性の判断もする。通知は強いものにして、対応完了のチケット管理みたいなものもします。

もう1つは、異常を検知するけれども、即時対応はしなくていい。そういったものもありますよね。こういったものは、通知はチケット起票とか、そういったものでいいです。

あとは対応はしないけれど、異常があったことは知りたい。例えば冗長化されてるシステムとかはあるかもしれないですね。オートスケールで増えたとか、場合によっては片側のサーバーがダウンしたけども、SPOF（Single Point Of Failure）がなかったので切り抜けることができたとか。そんなところがいろいろあります。

アンチパターン4：監視トラブルを特定の人に任せきりにしている

アンチパターンの4です。監視トラブル対応が特定の人任せのケースです。監視トラブル対応を特定の人に依存しているケースです。人が定常的に不足しているスタートアップのみなさんでは、もしかしたらこのケース多いかもしれませんが、特定の人に依存していると。

また、オンコールの対応を決めていない。特定の人が対応できない日に大障害につながる。よくある話ですね。

改善策としては、そもそも監視はできる限り開発チーム全員で取り組みましょうということです。まさにYou build it, you run itですね。そしてオンコール担当を決めるのはもちろんなですが、おすすめは、メインとサブの担当をして、ノウハウを人にためないかたちでローテーションしながら、ノウハウを蓄積していく方法が1つ考えられます。