AWSでWebサービスを運用すると、サーバ監視はCloudWatchが最初に思い浮かびます。
EC2のCPU使用率を確認したり、アラームを設定したり、ログを保存したりと、AWS運用では非常に便利なサービスです。
そこで気になるのが、
AWSを使っているなら、サーバ監視はCloudWatchだけで十分なのでは？
という疑問です。
結論からいうと、CloudWatchだけでもかなり幅広い監視ができます。
一方で、
「できること」と「小規模サービスで運用しやすいこと」は別の話
でもあります。
今回は個人開発や小規模なWebサービスを前提に、CloudWatchで何ができるのか、そして監視をどう考えるとよいのか整理してみます。
CloudWatchでは何を監視できる？
CloudWatchというとCPU使用率を見るサービスというイメージを持っている人もいるかもしれません。
実際には、それだけではありません。
代表的なものだけでも、
- AWSリソースのメトリクス監視
- ログの収集・検索
- アラーム
- ダッシュボード
- アプリケーション監視
- 外形監視
などがあります。
AWS環境を監視するための機能はかなり揃っています。
EC2などのメトリクスを監視できる
分かりやすいのが、CPU使用率などのメトリクス監視です。
EC2であれば、
「CPU使用率が一定値を超えた」
といった条件でCloudWatch Alarmを設定できます。
RDSなどAWSの各サービスにも、それぞれ確認できるメトリクスがあります。
こうした情報を見ることで、
- サーバーの負荷が上がっていないか
- データベースに異常がないか
- リソースが不足していないか
といった状態を把握できます。
小規模なWebサービスでも、CPUなど基本的なメトリクスは確認できるようにしておきたいところです。
ログもCloudWatchで監視できる
CloudWatch Logsを利用すると、アプリケーションやサーバーから送信されたログをAWS上で確認できます。
さらにCloudWatchでは、ログを検索するだけでなく、条件に応じてアラームにつなげることもできます。
現在のCloudWatchでは、CloudWatch Logs Insightsのクエリ結果を定期的に評価するLog Alarmや、ログからメトリクスを作成してアラームを設定する方法があります。
たとえば、
- 特定のエラーが急増した
- 500エラーが一定数以上発生した
- 特定のログメッセージが出力された
といった状態を検知する仕組みも作れます。
つまりCloudWatchは、
サーバーの状態を見るだけでなく、アプリケーション側の異常を検知する用途にも使える
ということです。
「CloudWatchでは外から監視できない」は正確ではない
ここは少し注意したいところです。
CloudWatchについて、
「AWS内部のメトリクスしか見られない」
と説明されることがあります。
しかし、現在はそうではありません。
CloudWatchにはCloudWatch Syntheticsという機能があります。
Syntheticsでは「Canary」と呼ばれるスクリプトを定期実行して、WebサイトやAPIを外側から監視できます。
AWS公式ドキュメントでも、エンドポイントやAPIを継続的に監視し、可用性やレイテンシを確認できる機能として説明されています。
そのため、
「Webサイトが実際に表示できるか」
「APIが正常に応答するか」
といった外形監視もCloudWatchの範囲内で実現できます。
ブラウザ操作に近い監視もできる
CloudWatch SyntheticsのCanaryは、単純にURLへHTTPリクエストを送るだけではありません。
Node.jsやPythonなどを使ったスクリプトを実行でき、ブラウザを利用した監視にも対応しています。
そのため、
トップページが表示できるか、
だけではなく、
実際のユーザー操作に近い流れを定期的に確認する
といった監視も可能です。
本格的にAWS上で監視環境を構築するのであれば、かなり強力な機能です。
Application Signalsでアプリケーション単位の監視もできる
CloudWatchにはApplication Signalsという機能もあります。
Application Signalsでは、対応するアプリケーションから、
- レイテンシ
- 障害
- エラー
- 可用性
などの情報を確認できます。
サービス間の依存関係を可視化したり、サービスレベル目標（SLO）を設定したりすることもできます。
そのため、
「CloudWatchではインフラしか見られない」
という認識も、現在ではかなり違ってきています。
AWSだけで本格的なオブザーバビリティ環境を構築することも可能です。
ではCloudWatchだけで十分なのか？
ここまで見ると、
「じゃあCloudWatchだけ使えばいいのでは？」
と思うかもしれません。
技術的には、それで十分なケースも多いと思います。
特に、
- AWSだけでシステムが完結している
- AWS運用に慣れている
- CloudWatchを細かく設定できる
- 必要なアラームやダッシュボードを自分で設計できる
のであれば、CloudWatchを中心に監視環境を作るのは自然です。
問題は、CloudWatchで「できるか」ではなく、
そこまで自分で構築・管理したいか
という部分です。
小規模サービスでは監視環境を作ること自体が仕事になる
個人開発や小規模SaaSでは、インフラ専任担当者がいるとは限りません。
多くの場合、
- アプリケーション開発
- インフラ
- 問い合わせ対応
- 機能改善
- セキュリティ
- 集客
などを少人数、あるいは1人で担当します。
その中で監視まで本格的に構築すると、
CloudWatch Alarmを設定して、
CloudWatch Logsを設定して、
通知を設定して、
必要ならSyntheticsを設定して、
ダッシュボードを作って、
しきい値を調整して……
と、監視環境そのものの管理が増えていきます。
もちろん必要であればやるべきです。
しかし、小規模サービスの場合、
監視環境を作ること自体にどれだけ時間を使うか
は考えた方がいいと思います。
CloudWatchは「原因調査」にも強い
CloudWatchの大きなメリットは、問題が起きたあとに詳しく調査できることです。
たとえば、
Webサイトが遅い
↓
EC2のCPUを確認
↓
ログを見る
↓
アプリケーションのエラーを確認
といった流れで原因を追えます。
監視について考えるときは、
異常に気付くための監視
と、
原因を調べるための監視
を分けて考えると分かりやすくなります。
CloudWatchは特に後者でも非常に重要な存在です。
「異常検知」と「詳しい調査」を分けてもいい
個人開発や小規模サービスなら、すべてを1つの仕組みで完結させる必要はありません。
たとえば、
普段は、
「サービスは正常か」
「何か対応が必要か」
だけ簡単に確認する。
異常が見つかったら、
CloudWatchやログなどを開いて詳しく調査する。
という運用でも十分です。
イメージとしては、
監視サービス
↓
「Webサイトが応答していない」
↓
CloudWatch
↓
CPU、ログ、AWSリソースなどを詳しく調査
という役割分担です。
AWS以外も使っていると少し事情が変わる
もうひとつ考えたいのが、Webサービス全体が必ずしもAWSだけで構成されているとは限らないことです。
たとえば、
- AWS
- GitHub
- Cloudflare
- 外部API
- SaaS
- 独自ドメイン
など、複数のサービスを組み合わせているケースがあります。
この場合、
AWSの状態を見ること
と、
Webサービス全体が正常かを見ること
は少し違ってきます。
CloudWatchは当然ながらAWSとの親和性が非常に高いサービスです。
一方で、運営者として知りたいのは、
「EC2のCPUがどうなっているか」
だけではなく、
「結局、今このサービスは正常なのか」
だったりします。
私自身も「まず状況が分かる」仕組みが欲しかった
私自身、複数のWebサービスやAWS環境を管理していると、
詳しいメトリクスを見る前に、
「今、対応しなければいけない問題があるのか」
を簡単に知りたいと感じることがあります。
CloudWatchには非常に多くの機能があります。
だからこそ、
必要な情報を確認するために設定を作り込み、複数の画面を見ることもあります。
もう少し、
運営しているサービスの状態をシンプルに確認したい。
そう考えたことも、現在開発しているインフラ監視サービス Mimizu（ミミズ） につながっています。
Mimizuでは、CloudWatchを置き換える巨大な監視システムを目指すというより、
「今、自分のサービスに問題があるのか」
を分かりやすく確認できるサービスを目指しています。
Mimizuについては、今後もこのブログで開発状況を紹介していく予定です。
CloudWatchと他の監視サービスは競合するとは限らない
監視ツールについて考えると、
「CloudWatchを使うか、別の監視サービスを使うか」
という二択になりがちです。
しかし実際には、
CloudWatch ＋ 外部の監視サービス
という組み合わせもあります。
CloudWatchで、
- AWSリソース
- メトリクス
- ログ
- 詳細調査
を行い、
別の監視サービスで、
- Webサービスの状態
- 外形監視
- 通知
- 日常的な状態確認
を行うという考え方です。
重要なのはツールを統一することではなく、
異常に早く気付き、必要なときに原因を調査できること
です。
小規模サービスなら最初はシンプルでもいい
AWSには非常に高度な監視環境を構築できる仕組みがあります。
しかし、新しく公開したばかりのサービスで、最初からすべてを使いこなす必要はありません。
まずは、
- Webサービスが利用できるか
- サーバーに異常がないか
- 問題が起きたら通知されるか
- 必要なときにログを確認できるか
といった基本から始めれば十分です。
そしてサービスが成長したら、
- 詳細なログ監視
- Application Signals
- Synthetics
- SLO
- より細かなアラーム
などを追加していけばよいでしょう。
監視もアプリケーションと同じように、必要に応じて成長させていく方が現実的です。
まとめ
「AWSの監視はCloudWatchだけで十分か？」
という問いに対しては、サーバ監視の観点から回答します。
CloudWatchだけでも、かなりのことができる
というのが答えです。
メトリクス、ログ、アラームだけでなく、CloudWatch Syntheticsを使った外形監視や、Application Signalsによるアプリケーション監視も可能です。
そのため、
「CloudWatchではできないから別サービスが必要」
と単純に考えるのは正確ではありません。
一方で、小規模サービスでは、
必要な監視環境を自分で構築・管理する手間
も考える必要があります。
CloudWatchを詳細な監視・調査に使いながら、日常的な状態確認は別の仕組みでシンプルにする。
そんな組み合わせもひとつの方法です。
最終的に重要なのは、
どの監視ツールを使うかではなく、障害に気付き、原因を調べ、対応できる状態になっていること
だと思います。