Webサービスを運営していると、死活監視についてふと気になることがあります。
「もし今このサービスが落ちたら、死活監視の観点から自分はすぐに気付けるだろうか？」
毎日管理画面を開いているサービスなら、比較的早く気付くかもしれません。
しかし、正常に動いていることが当たり前になってくると、運営者自身がサービスへアクセスする回数は意外と減っていきます。
その結果、
「ログインできません」
「サイトが開かないのですが」
といったユーザーからの問い合わせで、初めて障害に気付くことがあります。
これはできれば避けたい状態です。
そこで必要になるのが、Webサービスの死活監視です。
死活監視とは？
死活監視とは、サーバーやWebサービスが正常に動いているかを定期的に確認する仕組みです。
たとえば、監視システムから5分ごとにWebサイトへアクセスし、
- 正常なHTTPステータスが返ってくるか
- タイムアウトしていないか
- レスポンスが極端に遅くなっていないか
などを確認します。
異常を検知した場合は、メールやチャットなどで管理者へ通知します。
単純な仕組みに見えますが、Webサービスを運営するうえでは非常に重要です。
サーバーが起動していてもサービスは正常とは限らない
監視というと、
「EC2が起動しているから大丈夫」
「サーバーのCPU使用率をCloudWatchで見ているから問題ない」
と考えてしまうことがあります。
しかし、サーバーそのものが起動していても、Webサービスが正常に使えるとは限りません。
たとえば、
- nginxが停止している
- PHP-FPMが応答していない
- アプリケーションで500エラーが発生している
- データベースへ接続できない
- ディスク容量がいっぱいになっている
- SSL証明書に問題がある
といったケースがあります。
この場合、EC2インスタンス自体は「running」でも、ユーザーから見ればサービスは使えません。
そのため、インフラの状態を見るだけではなく、実際にユーザーがアクセスするURLを外部から監視することが重要です。
ユーザーからの連絡が最初の障害通知になってはいけない
個人開発や小規模サービスでは、24時間監視する専任担当者を置くことは現実的ではありません。
だからこそ、自動監視が役立ちます。
監視していない場合、
障害発生
↓
しばらく誰も気付かない
↓
ユーザーがアクセス
↓
エラーになる
↓
問い合わせが届く
↓
ようやく運営者が気付く
という流れになります。
一方、死活監視を設定していれば、
障害発生
↓
監視システムが異常を検知
↓
管理者へ通知
↓
ユーザーから問い合わせが来る前に確認
という流れにできます。
障害そのものを完全になくすことは難しくても、障害に気付くまでの時間を短くすることはできます。
小規模なWebサービスでも最低限見ておきたいもの
大規模なサービスでは非常に多くの監視項目があります。
しかし、個人開発や小規模SaaSで最初から何十種類もの監視を設定すると、管理すること自体が大変になります。
まずは次のような項目から始めるだけでも十分です。
1. Webサイトが正常に表示できるか
もっとも基本的な監視です。
定期的にURLへアクセスして、正常なレスポンスが返ってくるか確認します。
トップページだけでなく、サービスによってはログイン画面やAPIなど、重要なURLを監視してもよいでしょう。
2. レスポンスが極端に遅くなっていないか
サービス自体は動いていても、ページ表示に10秒、20秒とかかっていたら、ユーザーにとっては正常とは言いにくい状態です。
「落ちているか」だけでなく、「いつもより大幅に遅くなっていないか」も見られると、障害の予兆に気付きやすくなります。
3. SSL証明書に問題がないか
HTTPSを利用しているWebサービスでは、SSL/TLS証明書も重要です。
現在は証明書を自動更新しているケースも多いですが、自動更新が何らかの理由で失敗する可能性はあります。
有効期限が切れてから気付くのではなく、期限が近づいた段階で分かる仕組みがあると安心です。
4. サーバーリソースに異常がないか
CPU、メモリ、ディスクなどのサーバーリソースも確認したい項目です。
特にディスク容量は、ログやアップロードファイルなどが増え続け、ある日突然いっぱいになることがあります。
Webサイトの外形監視と、サーバー内部のメトリクス監視は役割が違うため、可能であれば両方確認できる状態が理想です。
5. 異常が起きたときに通知されるか
監視していても、異常を誰にも知らせなければ意味がありません。
メールやSlack、Discordなど、自分が普段確認する場所へ通知できるようにしておく必要があります。
重要なのは「監視項目を増やすこと」ではなく、問題が発生したときに気付ける状態を作ることです。
AWSならCloudWatchだけで十分？
AWSを利用している場合、Amazon CloudWatchで多くのメトリクスを監視できます。
CPU使用率や各AWSサービスの状態を確認するうえでは非常に便利です。
一方で、
「ユーザーから見てWebサイトが正常に使えるか」
という確認とは少し目的が違います。
そのため、
AWS内部の状態をCloudWatchで確認する
ことと、
外部から実際にWebサービスへアクセスして確認する
ことを組み合わせると、より状況を把握しやすくなります。
どちらか一方だけですべてを監視しようとする必要はありません。
監視は増やしすぎても運用が大変になる
監視項目を増やせば増やすほど安心できそうに思えます。
しかし、実際には通知が多すぎると、
「また通知か」
と感じるようになり、本当に重要なアラートまで見なくなってしまうことがあります。
いわゆるアラート疲れです。
特に個人開発や少人数でサービスを運営している場合は、
- サービスが利用できない
- 明らかにレスポンスが遅い
- リソースが危険な状態になっている
- 証明書などに問題が近づいている
といった、本当に対応が必要な情報から監視する方が現実的です。
自分自身が欲しい監視サービスを作り始めた
私自身、複数のWebサービスやAWS環境を管理していると、
「サービスはちゃんと動いているか」
「AWS側で何か問題が起きていないか」
「異常があったらすぐに知りたい」
といった情報を、もっと簡単に確認したいと感じることがありました。
もちろん、既存の監視サービスやAWSの各種機能を組み合わせれば実現できます。
ただ、個人開発や小規模サービスでは、監視システムそのものを管理することに時間をかけたくありません。
そこで現在、Mimizu（ミミズ）というインフラ監視サービスを開発しています。
目指しているのは、監視項目を大量に並べることではなく、
「今、自分のサービスに問題があるのか」を簡単に把握できること。
です。
Mimizuについては、今後このブログでも開発の過程や、Webサービス監視・AWS運用について紹介していく予定です。
Mimizu
https://www.mimizu.dev/
まとめ
Webサービスを公開したら、機能追加やアクセス数だけでなく、
「正常に動いていることをどう確認するか」
も考えておく必要があります。
特に最初に確認したいのは、
- Webサービスへアクセスできるか
- レスポンスが異常に遅くないか
- SSL証明書に問題がないか
- サーバーリソースに異常がないか
- 問題が発生したときに通知されるか
といった基本的な部分です。
最初から完璧な監視環境を作る必要はありません。
まずは、
「サービスが落ちたとき、ユーザーより先に自分が気付ける状態にする」
ところから始めるのがおすすめです。