Webサービスを公開すると、まず気になるのはアクセス数やユーザー数かもしれません。
しかし、公開直後にもうひとつ考えておきたいことがあります。
それが、
「サービスが正常に動いていることを、どうやって確認するか」
です。
開発中は自分で何度もアクセスするため、異常があれば比較的すぐに気付けます。
ところが、公開してしばらくすると、自分自身が毎日すべての画面を確認することはなくなっていきます。
その状態で障害が起きると、
「ユーザーから問い合わせが来て初めて気付いた」
ということも起こります。
そこで今回は、個人開発や小規模なWebサービスを公開したあとに、最低限設定しておきたい監視を5つに絞って紹介します。
1. Webサービスの死活監視
最初に設定しておきたいのが、Webサービスの死活監視です。
死活監視では、一定間隔でWebサイトやAPIへアクセスし、
- 正常に接続できるか
- HTTPステータスが正常か
- タイムアウトしていないか
- 5xxエラーになっていないか
などを確認します。
たとえば5分ごとに監視していれば、サービスが停止した場合でも比較的早く気付けます。
サーバーが起動していても安心とは限らない
AWS EC2などを使っていると、
「インスタンスがrunningになっているから大丈夫」
と思ってしまうことがあります。
しかし、EC2が起動していても、
- nginxが停止している
- PHP-FPMが停止している
- Laravelで500エラーが発生している
- データベースへ接続できない
といった状態になる可能性があります。
そのため、サーバーそのものだけを見るのではなく、
実際にユーザーがアクセスするURLを監視する
ことが重要です。
どのURLを監視する？
最初はトップページだけでも構いません。
その後、必要に応じて、
- ログインページ
- API
- 管理画面
- ヘルスチェックURL
などを追加していきます。
重要なのは、最初から大量に登録することではなく、
サービスが利用可能かどうかを確認できるURLを1つ監視すること
です。
2. SSL/TLS証明書の有効期限監視
現在のWebサービスではHTTPSがほぼ必須です。
そのため、SSL/TLS証明書の有効期限も監視しておきたい項目です。
Let’s Encryptなどを利用している場合は、自動更新を設定していることが多いと思います。
しかし、
- 自動更新処理が失敗する
- DNS設定を変更する
- Webサーバー設定が変わる
- 更新処理のジョブが停止する
などの理由で、自動更新されない可能性もあります。
証明書が期限切れになると、ユーザーのブラウザに警告が表示されるため、サービスへの信頼にも影響します。
期限切れ当日に気付いても遅い
SSL証明書監視では、
「期限切れになった」
ではなく、
「あと30日で期限切れ」
「あと14日で期限切れ」
のように、事前に通知されることが重要です。
余裕を持って対応できるようにしておきましょう。
3. レスポンスタイムの監視
Webサイトが表示されるだけでは、必ずしも正常とは言えません。
たとえば、
通常は1秒で表示されるページが、突然10秒以上かかるようになった場合です。
サービスそのものは落ちていなくても、ユーザーにとってはかなり使いづらい状態です。
レスポンスタイムを監視しておけば、
「最近少しずつ遅くなっている」
という変化にも気付きやすくなります。
遅くなる原因はさまざま
レスポンスが遅くなる原因には、
- CPU負荷の上昇
- メモリ不足
- データベース負荷
- 遅いSQL
- 外部APIの遅延
- アクセス急増
などがあります。
レスポンスタイムだけで原因を特定することはできません。
ただし、
「何かがおかしい」ことに気付くきっかけ
として非常に役立ちます。
4. CPU・メモリ・ディスクなどのリソース監視
Webサービスを運営するなら、サーバー内部のリソースも確認しておきたいところです。
特に重要なのは、
- CPU
- メモリ
- ディスク
です。
CPU
CPU使用率が一時的に高くなること自体は珍しくありません。
問題なのは、高負荷状態が長時間続いている場合です。
アクセス急増や、重いバッチ処理、プログラムの問題などが原因になっている可能性があります。
メモリ
メモリ不足になると、アプリケーションやプロセスが正常に動かなくなることがあります。
特に、
- PHP-FPM
- MySQL
- Redis
- Docker
- キューワーカー
などを1台のサーバーで動かしている場合は注意が必要です。
ディスク
ディスクは個人開発でも特に注意したい項目です。
ログやバックアップが増え続けることで、
「気付いたらディスク使用率100%」
ということがあります。
ディスクがいっぱいになると、
- ログが書けない
- データベースが書き込めない
- 一時ファイルを作れない
- アプリケーションが異常終了する
など、さまざまな問題が起きます。
そのため、ディスク使用率は早い段階から監視しておくのがおすすめです。
5. 異常時の通知
最後に重要なのが通知です。
監視だけ設定していても、異常が発生したことを誰も見ていなければ意味がありません。
そのため、
- メール
- Slack
- Discord
- Microsoft Teams
- その他普段利用している通知先
などにアラートを送れる状態にしておきます。
通知は多ければよいわけではない
ここで注意したいのが、通知の出しすぎです。
たとえばCPU使用率が一瞬だけ高くなるたびに通知が来ると、
「また通知か」
と無視するようになってしまいます。
これでは本当に重要な障害通知まで見落とす可能性があります。
そのため、
- 一定時間継続した場合だけ通知
- 同じ障害を何度も通知しない
- 復旧したときにも通知
- 重要度によって通知方法を変える
などの工夫が必要です。
まずはこの5つで十分
ここまで紹介した5つをまとめると、
- 死活監視
- SSL証明書監視
- レスポンスタイム監視
- CPU・メモリ・ディスク監視
- 異常時の通知
です。
この5つだけでも、
「サービスが正常に動いているか」
をかなり把握しやすくなります。
大規模なシステムであれば、
- データベース監視
- ログ監視
- APM
- キュー監視
- 外部API監視
- セキュリティ監視
- コスト監視
なども必要になってきます。
しかし、個人開発や小規模SaaSの場合は、最初からすべてを入れる必要はありません。
サービスの規模に合わせて少しずつ追加していけば十分です。
監視は「検知」と「調査」を分けて考える
監視について考えるとき、
すべての情報を1つの監視ツールで確認したくなることがあります。
しかし、
異常を検知するための情報
と、
原因を調査するための情報
は分けて考えた方が分かりやすいです。
たとえば、
「Webサイトが応答しない」
という異常を死活監視で検知したあと、
CloudWatchやログを確認して原因を調査する、
という形です。
監視の段階で原因まで完全に特定できる必要はありません。
まずは、
「今、何か問題が起きている」
と分かることが重要です。
AWSを使っている場合はCloudWatchも活用できる
AWSを利用している場合、Amazon CloudWatchを使えば、
- EC2のCPU使用率
- RDSのメトリクス
- ログ
- アラーム
などを確認できます。
AWS内部の状態を見るうえでは非常に便利です。
ただし、CloudWatchだけでは、
「ユーザーから見てWebサービスが正常に使えるか」
という部分が分かりにくい場合もあります。
そのため、
AWS内部の監視
と、
外部からのWebサービス監視
を組み合わせると、より状況を把握しやすくなります。
個人開発では「管理が楽」であることも大切
監視項目を増やしすぎると、今度は監視環境そのものを管理する必要が出てきます。
特に個人開発では、
開発、問い合わせ対応、インフラ、運用、マーケティングなどを1人で担当することもあります。
そのため、
監視のために毎日複数の管理画面を巡回する
という状態になると、本末転倒です。
必要な情報がまとまっていて、
「問題があるかどうか」
をすぐ確認できる方が運用しやすいと感じます。
こうした課題からMimizuを開発しています
私自身もWebサービスやAWS環境を管理している中で、
- サービスは正常に動いているか
- サーバーに異常はないか
- AWS側で問題が起きていないか
- 対応が必要なことはあるか
といった情報を、もっと簡単に確認したいと感じることがありました。
そこで現在、インフラ監視サービス Mimizu（ミミズ） を開発しています。
Mimizuでは、
「今、問題があるのか」
をできるだけ分かりやすく確認できるサービスを目指しています。
Mimizu
https://www.mimizu.dev/
このブログでも今後、Mimizuの開発だけでなく、サーバー監視やAWS運用について紹介していく予定です。
まとめ
Webサービスを公開したあと、最低限設定しておきたい監視は次の5つです。
- Webサービスの死活監視
- SSL/TLS証明書の有効期限監視
- レスポンスタイム監視
- CPU・メモリ・ディスク監視
- 異常時の通知
最初から完璧な監視システムを作る必要はありません。
まずは、
「サービスに問題が起きたら、自分が気付ける状態」
を作ることが重要です。
そのうえで、サービスが成長してきたら、データベースやログ、キュー、コストなどの監視を追加していけばよいでしょう。
公開して終わりではなく、
公開後も正常に動いていることを確認できる仕組み
まで含めて、Webサービス運営と考えておくと安心です。