はやいものでもう12月。今年もアドベントカレンダーがはじまりました。
本エントリは、Mackerelアドベントカレンダー2020の初日です。
監視は難しい
Mackerelがローンチしてから6年が経ちました。この6年間、ぼくもほぼMackerelに関わる仕事をし続けています。6年前と比べて、多少はソフトウェア開発・運用の現場でも、監視の民主化みたいなものが浸透してきたかな、というのは感じつつあります。devopsというワードがバズワードではなく、エンジニア文化をあらわす一般的な用語として認知されつつあるのもそのあらわれでしょうか。
Mackerelを導入すれば、簡単に監視をはじめられますよ、と我々はお客さんに対して説明するわけですが、そうはいってもやはりまだまだ難しいところもあると思います。6年前に当時アプリケーションエンジニアとして正式ローンチ2ヶ月後にチームにジョインした当初のぼくなども、監視についてはほとんど何もわかっていませんでした。
今だとよい手引があります。
『入門監視』などはモニタリングについてひととおり学べるたいへんよい書籍です。
- 作者:Mike Julian
- 発売日: 2019/01/17
- メディア: 単行本（ソフトカバー）
宣伝のようになって恐縮ですが、今回監修という立場で制作に関わらせていただいた、『わかばちゃんと学ぶサーバー監視』も、著者の湊川さんが苦心されて、マンガでたいへんわかりやすく最近の監視界隈をひととおり概観できる書籍になっています。
- 作者:湊川あい
- 発売日: 2020/12/22
- メディア: 単行本（ソフトカバー）
監視すべき項目は環境によって違うから難しい
Mackerelの仕事をしていて、よく聞かれるのは、結局なにを監視したらいいのですか？ CPU使用率の監視閾値は何パーセントにすると良いのですか？ というようなものです。
「この項目に対して閾値をこれこれで監視すればよいですよ！」とズバッと一撃で回答できるとよいのですが、残念ながらそうはいかないところに難しさがあります。というのも、やはり実際に運用されているアプリケーションや環境によって、監視すべき項目というのは異なるからです。
たとえば、CPU使用率を監視して負荷を検知したい、と考えたとしましょう。たくさんCPUを使っている状態は負荷が高いから、80%くらいに閾値を設定すればよいのかしら、と考えたくなりますが、それがそうでもないのです。
オートスケール環境で、アプリケーションを並列に複数のサーバーで動かしている場合、インフラコストの効率化の観点でいえばCPUはなるべく使い切っているほうが効率がよい、となります。10台のサーバーで、それぞれのCPU使用率が60%なのだとすれば、まだそれぞれ40%の余力があることになりますから、台数を減らしてそれぞれCPU使用率90%くらいまで使い切ったほうがコスト面での効率がよい、と考えることができます。負荷が高まればサーバー台数を増やせばよいわけですから。
この場合、負荷はCPU使用率よりもloadavgであるとか、ネットワークトラフィックであるとか、他のメトリックを監視するほうが適切であるともいえるでしょうか。
一方で、簡単にスケーリングしづらいデータベースサーバーなどは、充分に余力をもたせて20%程度の使用率をキープしたい、ということもありえるでしょう。
このように、一口にCPU使用率、という監視項目をみても、アプリケーションの構成や考え方によって、検知したい閾値は大きく異なってくるのです。
悩んだら「ユーザーに近い場所」を監視する
さて、難しいとばかり言っていても先に進みませんから、まずはわかりやすく簡単にはじめられるところから監視を考えていきましょう。
そもそもわたしたちはなぜ監視をしたいのでしょうか？
サービスがダウンしていることに気づかず、復旧が出遅れてしまったり、ユーザーに迷惑をかけてしまうことがないようにしたい、というのがそもそも監視をしたい動機でしょう。
であれば、まずはユーザーがサービスを使えているかどうか、というのをはじめに監視するのがよいということになります。
MackerelにはURL外形監視という機能があります。
これは、実際に稼働しているWebサイトに対してリクエストを行い、そのレスポンスを監視する機能です。
正常に動いていれば、サイトは200のステータスコードを返しているわけですから、そうでないステータスコードを受け取ったときにMackerelはアラートを発生させます。
まずはこれだけやっておけば、サイトがダウンしているのに数時間気づかなかった、というようなことは避けられます。ダウンしてまもなくMackerelからアラートを受け取ることができるからです。
この監視さえ一つ入れておけば、サイトのダウンには気付けるようになります。しかし、できることならダウンする前に、その予兆を察知したいですよね。なので少しずつ監視を育てていきましょう。
URL外形監視には、レスポンスを受け取るまでの時間に対して閾値を設定できます。サイトの応答が遅くなる、というのは何かが発生している予兆です。本来すぐに返事がくるはずのページが、たとえばデータベースの負荷がかかっているなどの理由で重くなっている状態です。
レスポンスタイムを監視すれば、サイトが完全にダウンしてしまうよりも少し前に気づくことができるかもしれません。
少しずつ監視を育てていこう
ステータスコードとレスポンスタイムを監視すれば、障害が発生した瞬間を捉えることができます。厳密に言えば多少の誤差はあるでしょうが、少なくともこのあたりの時刻で不調が起き始めたのだな、ということがわかります。
次に、それを手がかりに他のメトリックを眺めてみましょう。たとえば、レスポンスタイムのアラートが発生した時刻付近で、サーバーの他のメトリックに変調はなかったかどうか。アプリケーションサーバーのメトリックはいつもと変わりないのに、データベースサーバーのloadavgが大きく増えている、といったことがわかれば、原因はデータベースに近いところにあると判断することができます。では、次はもう少しはやく不調に気付けるように、データベースサーバーのloadavgを監視しましょう。継続的にメトリックをとっていれば、普段の正常な数値はわかるはずですから、そこから少し高い数字を閾値に設定します。
このように少しづつ監視を「育てていく」ことで、自分たちのアプリケーション特性に応じた監視項目が整ってくるのです。
ここで大事なのは、情報は普段から継続的にとっておく、ということです。
ある日の朝、体重計に乗ったところ80kgという値でした。この値だけみても良し悪しはなにもわかりません。身長とあわせて判断すればひょっとしたらもう少し何かがわかるかもしれません。ぼくにとって80kgという値は、いますぐ痩せなければならないたいへんな数値ですが、体を鍛えているがっしりした体格の人にしてみれば正常値かもしれません。今日のこの瞬間80kgだった、という数字にはなんの意味もないのです。継続的に計測していて、2ヶ月前は70kgだったのに今は80kgだ、というような継続的な情報の蓄積に基づいて判断してはじめて、数値には意味が生じるのです。
ですので、メトリックはなるべく多く、継続的に取得しておくのが良いでしょう。
メンテナンスしやすいサービスを選ぶ
監視項目は、普段の運用業務での傾向を眺めながら、継続的にデータをとり、チューニングしていくべきものです。
ですので、アプリケーションエンジニアやSREが、気軽に設定を試行錯誤できるようなサービスを選ぶべきです。必ずしもMackerelを使うべき、とは言いませんが、思い立ったらすぐに設定を変えることができるくらい身近に監視サービスがあるのが望ましい気がしますね。
それでは明日からのアドベントカレンダーも、よろしくお願いします。
