個人でWebサービスやSaaSを公開すると、意外と悩むのがサーバー監視をどこまでやるかです。
企業が運営する大規模サービスなら、
- 24時間365日の監視
- CPU・メモリ・ディスク監視
- アプリケーション監視
- ログ監視
- データベース監視
- 外形監視
- セキュリティ監視
- オンコール対応
など、本格的な監視体制を構築できます。
しかし、個人開発で同じことをしようとすると、監視するだけで疲れてしまいます。
では、個人開発や小規模なWebサービスでは、どこまで監視すればいいのでしょうか。
結論からいうと、
「問題が起きたことに気付けて、原因調査を始められる状態」
をまず作るのがおすすめです。
この記事では、個人開発で最低限設定しておきたい監視を、優先順位ごとに整理してみます。
監視は「全部見る」より優先順位を決める
サーバー監視について調べると、非常に多くの監視項目が出てきます。
CPU使用率、ロードアベレージ、メモリ、ディスク、ネットワーク、プロセス、データベース接続数、レスポンスタイム、エラーレート……。
これらをすべて監視しようとすると、設定するだけでもかなり大変です。
個人開発の場合は、まず次の3段階に分けて考えると分かりやすくなります。
レベル1：サービスが使えるか
最優先です。
ユーザーがWebサービスへアクセスできるかを確認します。
レベル2：サーバーが危険な状態になっていないか
CPUやメモリ、ディスクなどを確認します。
サービス停止につながる前兆を見つけるための監視です。
レベル3：なぜ問題が起きたのか調査できるか
ログやエラー情報などを残して、障害発生後に原因を追えるようにします。
個人開発では、まずこの3段階を押さえておけば、かなり実用的な監視環境になります。
優先度A：まず絶対に見ておきたい監視
最初に設定するなら、以下の監視です。
Webサービスの死活監視
最優先で設定したい項目です。
一定間隔でWebサイトへアクセスし、
- HTTP 200が返っているか
- タイムアウトしていないか
- 5xxエラーになっていないか
などを確認します。
サーバーが起動していても、アプリケーションが正常とは限りません。
そのため、実際にユーザーがアクセスするURLを外部から確認することが重要です。
トップページだけではなく、
- ログイン画面
- 重要なAPI
- ヘルスチェック用URL
などを監視する方法もあります。
ただし最初から大量のURLを監視する必要はありません。
まずはサービスを代表する1つのURLから始めても十分です。
SSL証明書の有効期限
SSL/TLS証明書も監視しておきたい項目です。
自動更新を設定していれば基本的には問題ありませんが、
- 自動更新処理が失敗していた
- DNS設定が変わった
- Webサーバーの設定変更で更新できなくなった
といった理由で、更新されない可能性があります。
証明書期限が切れると、ブラウザに警告が表示されるため、ユーザーへの影響も大きくなります。
期限切れの直前ではなく、ある程度余裕を持って通知されるようにしておくと安心です。
ディスク使用率
個人開発では意外と見落としやすいのがディスク容量です。
たとえば、
- アクセスログ
- エラーログ
- Dockerログ
- アップロードファイル
- バックアップファイル
- 一時ファイル
などが増え続けることで、いつの間にかディスクがいっぱいになることがあります。
ディスク容量がなくなると、
- ログが書き込めない
- データベースが正常に動かない
- アプリケーションがエラーになる
など、さまざまな問題につながります。
そのため、ディスク使用率は早い段階から監視しておいた方がいい項目です。
優先度B：できれば見ておきたい監視
次に設定したいのが、サーバーリソースの監視です。
CPU使用率
CPU使用率が一時的に高くなること自体は珍しくありません。
問題なのは、
高い状態が長時間続いている場合
です。
たとえば、
- 想定以上にアクセスが増えた
- 重い処理が実行され続けている
- バックグラウンドジョブが暴走している
- プログラムに問題がある
といった可能性があります。
単純に「80%を超えたら即通知」とすると通知が多くなりやすいため、
一定時間以上、高い状態が続いたら通知する
といった設計の方が実用的です。
メモリ使用量
メモリ不足もWebサービス停止の原因になります。
特に、
- PHP-FPM
- MySQL
- Redis
- Dockerコンテナ
- バックグラウンドワーカー
などを同じサーバーで動かしている場合、少しずつ使用量が増えていくことがあります。
メモリが不足すると、プロセスが強制終了されることもあります。
CPUと同じく、瞬間的な値よりも継続的な変化を見る方が重要です。
レスポンスタイム
Webサイトが表示されていても、
「ページ表示に15秒かかる」
のであれば、正常に動いているとは言いにくい状態です。
レスポンスタイムを監視していると、
- データベースが遅くなっている
- 外部APIの応答が遅い
- サーバーリソースが不足している
- アクセスが急増している
といった問題に気付ける場合があります。
死活監視と一緒に確認すると、よりサービスの状態が分かりやすくなります。
優先度C：サービスが成長したら追加したい監視
最初から必須ではありませんが、利用者が増えてきたら追加したい項目もあります。
アプリケーションエラー
LaravelなどのWebアプリケーションなら、例外やエラーを記録しているはずです。
500エラーが頻発している場合、
Webサイト自体は表示できていても、特定の機能だけ壊れている可能性があります。
アクセス可能かどうかだけでは分からないため、サービスが成長してきたらアプリケーションエラーも確認したいところです。
データベース
データベースについても、
- 接続できるか
- CPU負荷
- 接続数
- ストレージ
- 遅いクエリ
など、さまざまな監視があります。
ただし、個人開発の初期段階で細かく監視しすぎる必要はありません。
まずは、
データベースの問題によってWebサービスが停止していないか
を検知できれば十分です。
アクセス数やデータ量が増えてきてから、より詳細な監視を追加していけばよいでしょう。
バックグラウンドジョブ
メール送信、データ集計、外部API連携などにキューを使っている場合は、
「Web画面は正常だけれど、裏側の処理だけ止まっている」
という状態が発生することがあります。
サービスの中でバックグラウンド処理の重要度が高くなったら、
- ワーカーが動いているか
- ジョブが大量に溜まっていないか
- 失敗ジョブが増えていないか
といった監視も検討します。
通知先は増やしすぎない
監視を設定したら、次に考えるのが通知です。
メール、Slack、Discord、LINEなど、さまざまな通知方法があります。
しかし、通知先を増やしすぎると管理が大変になります。
個人開発なら、
自分が確実に見る場所を1つか2つ
に絞った方が運用しやすいです。
重要なのは通知手段の数ではなく、
異常が発生したら自分が気付くこと
です。
「警告」と「障害」を分ける
監視を始めると、すべての通知が同じ重要度ではないことに気付きます。
たとえば、
ディスク使用率70%
と、
Webサービスが完全に停止
では緊急度がまったく違います。
そこで、
警告
今すぐサービス停止ではないが、確認した方がいい状態
障害
ユーザーへの影響が発生している状態
というように分けると管理しやすくなります。
たとえば、
- CPUが少し高い → 警告
- ディスク容量が残り少ない → 警告
- SSL期限が近い → 警告
- HTTP 500が継続 → 障害
- Webサイトに接続できない → 障害
といったイメージです。
監視のために運用が複雑になっては意味がない
個人開発では、監視そのものを目的にしないことも大切です。
監視ツールをいくつも導入して、
- Aサービスで死活監視
- Bサービスでログ監視
- AWSでメトリクス監視
- Cサービスでエラー監視
- Dサービスで通知
となると、今度は監視環境そのものを管理する必要が出てきます。
もちろん、大規模サービスなら専門ツールを組み合わせる価値があります。
しかし個人開発では、
必要な情報をできるだけ簡単に確認できること
も重要です。
私なら最初はこの7つを見る
個人で新しいWebサービスを公開するとしたら、まずは次の7項目から始めます。
- Webサービスへアクセスできるか
- HTTPエラーが発生していないか
- レスポンスが極端に遅くないか
- SSL証明書に問題がないか
- ディスク容量が不足していないか
- CPU・メモリに異常がないか
- 問題発生時に確実に通知されるか
その後、サービスの構成に応じて、
- データベース
- キューワーカー
- 外部API
- アプリケーションエラー
- AWSコスト
などを追加していきます。
最初から完璧を目指すより、サービスの成長に合わせて監視項目を増やした方が現実的です。
Mimizuでも「必要なものを簡単に見る」を目指しています
私自身も複数のWebサービスやAWS環境を管理しているため、
監視項目を増やし続けるより、
「今、自分のサービスに問題があるのか」
をすぐ確認できる方が便利だと感じています。
そこで現在、インフラ監視サービス Mimizu（ミミズ） を開発しています。
目指しているのは、専門のインフラ担当者だけが使う巨大な監視システムではなく、
個人開発者や小規模なサービス運営者でも、
- サービスが正常か
- 問題が起きていないか
- 対応が必要なことがあるか
を分かりやすく把握できるサービスです。
Mimizu
https://www.mimizu.dev/
開発状況や、実際のサーバー監視・AWS運用については、今後もこのブログで紹介していきます。
まとめ
個人開発のサーバー監視では、最初から大規模サービスと同じ監視環境を作る必要はありません。
まずは、
サービスが使えるか
サーバーが危険な状態になっていないか
問題が起きたときに調査を始められるか
の3つを意識すれば十分です。
特に、
- 死活監視
- SSL証明書
- ディスク
- CPU
- メモリ
- レスポンスタイム
- 通知
あたりから始めると、最低限の監視環境を作りやすくなります。
監視は多ければ多いほど良いわけではありません。
「異常が起きたときに気付き、必要な対応を始められること」
が一番重要です。