AWS上のサービスをCloudWatchで死活監視する方法を徹底解説

Amazon Web Services(AWS)ではCloudWatchでさまざまな監視をすることができます。今回は、運用監視の現場で10年のキャリアを持ち、オンプレミス環境やAWS環境での監視設計および設定・運用、さらには監視ツールの選定・導入まで、さまざまな現場を経験し、今もシニアエンジニアとして働く筆者が、CloudWatchでAWS上のサービスを死活監視する方法を徹底的に解説します。

目次

サービスの死活監視とは

システム監視をする上で一番重要なことはユーザーがサービスを問題なく利用できることであり、問題が発生した際にはすぐに検知して復旧させることです。そのためには、ユーザー目線でサービスが利用できているか監視し、検知して対応できる監視の仕組みが必要不可欠です。また、ユーザーはシステムを利用できているが、システムが遅くて使い物にならないといったケースについても、すぐに検知し対応しなければなりません。サービスの死活監視とは、サーバーがダウンしているか否かだけではなく、そのような状態まで含めて監視することをいいます。

ユーザーからのアクセスは問題ないか

アクセスはできているか（URL監視）

まず、ユーザーからシステムへアクセスが問題なく出来ているかというのが最も基本的で重要な監視になります。ユーザーがアクセスできないというのはネットワークの問題、サーバーの設定の問題、あるいはアプリケーションの問題など、様々な要因が考えられますが、まずはユーザーがアクセスして使えているかというところが一番重要です。ユーザーがアクセスできるかをCloudWatchで監視する具体的な手順は以下を参考にしてみてください。

CloudWatchでURL外形監視を始める手順とコストの目安と他の手段：
https://www.site24x7.jp/blog/cloudwatch-url-monitoring/

データは取得できているか（DB監視）

次に重要なのはユーザーがシステムを使うことができているかです。ほとんどのシステムではデータベースへのアクセスができなければシステムを利用することはできません。ですのでデータベースへの接続ができてデータが取得できているかの監視はURL監視と合わせて重要な監視になります。データベースへのアクセスができるかの監視設定手順は以下を参考にしてみてください。

CloudWatch Syntheticsの活用法を詳しく解説：
https://www.site24x7.jp/blog/cloudwatch-synthetics/

ここまでが、サービスの死活監視の最も重要な監視になります。

ユーザーからのアクセスはできるがサイトの状態が悪い（スピードが遅いなど）

次に、システムへはアクセスできているが、サイトが使いづらい状態の監視になっていないかという監視が重要になってきます。アクセスはできるけど、ページの表示に10秒もかかっていれば、ユーザーとしては使えないシステムということになってしまいます。そこで、サイトが使いづらい状態になっていないかを検知する監視項目を紹介します。

CloudWatch SyntheticsでURL死活監視

CloudWatchのURL外形監視でユーザーからのアクセスの状態と速度を確認することができます。URL外形監視ではユーザーの立場で利用する際のシナリオを作成して監視することができます。その際、速度や使い勝手についてもアラートで飛ばすことができます。具体的な手順は以下で紹介しています。

CloudWatchでURL外形監視を始める手順とコストの目安と他の手段：
https://www.site24x7.jp/blog/cloudwatch-url-monitoring/

CloudWatchでRDSの死活監視

URL監視に次いでデータベースはシステムにおいて重要な役割をしています。データベースの状態はシステムの全体のパフォーマンスに影響すると言っても過言ではありませんので、データベースへの監視は手厚くする必要があります。データベースへのCPUやメモリの監視だけでは不十分です。CPUやメモリが問題なくても、データベースへの接続数やIOPSが問題になってデータベースへのアクセスが遅くなったり、アクセスできなくなる場合があるからです。RDSの具体的な監視設定方法については以下のページを参考にしてみてください。

CloudWatchでRDSを監視する方法とそのコストを詳しく解説：
https://www.site24x7.jp/blog/cloudwatch-rds-monitoring/

CloudWatch Syntheticsの活用法を詳しく解説：
https://www.site24x7.jp/blog/cloudwatch-synthetics/

CloudWatchでS3の死活監視

ストレージの使い方としては、バックアップデータや静的コンテンツを格納している場合が多いと思います。バックアップデータにアクセスできなくなるのはシステムのユーザーに対しては大きな問題ではないですが、ユーザーから静的コンテンツが見れなくなることは、CX（カスタマー・エクスペリエンス）の観点で大きな問題になります。ほとんど画像が表示されていないサイトや表示が崩れているサイトに、ユーザーは継続してアクセスしてこないでしょう。S3の具体的な監視方法については以下のページを参考にしてみてください。

CloudWatchでS3を監視する方法を詳しく解説：
https://www.site24x7.jp/blog/cloudwatch-s3-monitoring/

CloudWatch Syntheticsの活用法を詳しく解説：
https://www.site24x7.jp/blog/cloudwatch-synthetics/

予防的な監視

多くのシステムでは冗長化を考慮して構築されているため、ここで紹介する監視設定で異常を検知したとしても、即時に対応する必要がないかもしれません。ですが、気づけないまま放置しておけば、いずれ障害に発展するでしょう。ここからは緊急度は高くないですが、システム障害を未然に防ぐための監視について優先度の高い順に説明していきます。

ログ監視

まず、予防的な監視で重要なのはログ監視になります。ログ監視はアプリケーションやミドルウェア、OSなどのシステムのメッセージを検知することができます。アプリケーションのログには、ユーザー個別に問題が発生している場合に検知することができます。また、冗長化構成を組んでいる場合には、システムの切り替わりのログなどを監視することができます。具体的なログ監視の設定方法については以下のページを参考にしてみてください。

CloudWatchでログ監視を始める手順と同じことを5分で実現する方法：
https://www.site24x7.jp/blog/cloudwatch-log-monitoring/

プロセス監視

冗長化構成を組んでいるシステムの場合にはプロセスがダウンしたからといって早急に対応しないといけない場合は少ないでしょう。ただ、中には冗長化していない機能もシステムの中にはあると思います。例えばシステム側からメールを送ったり、タスクスケジューラやCronで定期的に実行するバッチは冗長化を組んでいない場合が多いと思います。これらの監視はプロセス監視で検知することができます。プロセス監視を設定する具体的な手順は以下のページを参考にしてみてください。

CloudWatchでプロセス監視する手順をLinuxとWindowsともに詳しく紹介：
https://www.site24x7.jp/blog/cloudwatch-process-monitoring/

EC2の死活監視

EC2の死活監視は通信として接続できているか確認できます。冗長化している場合には一台のサーバーが通信できなくても大きな問題にならないですが、正常なサーバーが少なくなり負荷に耐えきれなければ正常なサーバーまでダウンしてしまう可能性があります。CloudWatchでEC2の死活監視をする手順は以下を参考にしてみて下さい。

CloudWatchでPing監視したい時の代替手段と同じことを簡単に始める方法：
https://www.site24x7.jp/blog/cloudwatch-ping-monitoring/

ポート監視

ポート監視についてもEC2の死活監視と同じで冗長化構成をとっている場合には大きな影響はありません。他の監視方法でシステム全体がダウンした際に、障害を調査するのに役立ちます。

CloudWatchとRoute53でポート監視する手順と同じことを簡単に始める方法：
https://www.site24x7.jp/blog/cloudwatch-port-monitoring/

EC2のリソース監視

リソース監視はシステムのリリース直後に問題なければ、監視設定をしないまま放置してしまいがちですが、忘れた頃にリソースが足りなくなって突然サーバーがダウンしてしまうことがあります。また、トラブル時の調査をするのにCPUやメモリの負荷などを調べることで問題解決の足掛かりにすることができます。さらには今後のサーバーの増強計画をするのにも役立ちます。サーバーの処理能力を向上させるスケールアップや、 サーバーの台数を増やし分散処理によってシステム全体の処理能力や可用性を高めるスケールアウトはリソース監視をしていなければできないでしょう。CloudWatchでリソース監視をする具体的な手順は以下を参考にしてみてください。

CloudWatchでリソース監視する手順（メモリ / CPU / ディスクの使用率）：
https://www.site24x7.jp/blog/cloudwatch-resource-monitoring/

4つのデメリット

CloudWatchでAWS上のサービスの死活監視をするメリットは、機能が豊富で作り込むことで柔軟な監視をすることができます。

一方のデメリットは、以下の4つがあります。

1. 設定が複雑で管理が難しい

メリットの機能が豊富で作り込むことで柔軟な監視が可能であることの裏返しになるのですが、設定が複雑になると管理が大変になります。監視設定をした人がそのまま運用をするのであれば問題ないかもしれませんが、監視運用する担当者が変わった場合には引き継ぎが必要になります。設定内容が複雑であれば、設計書にきちんとまとめる必要がありますし、引き継ぎ担当者の学習コストも高くなります。

2. 監視ダッシュボードが見にくく使いやすくするためには作り込みが必要

CloudWatchの監視ダッシュボードは見にくいという問題があります。そのため、運用し易いダッシュボードにするには作り込む必要があります。監視項目が少なければ問題ないかもしれませんが、サービスを提供しサービスの監視をしっかりやるためにはどうしても監視項目は増えていきますのでダッシュボードを考えて設定する必要があります。

3. 従量課金のため設定次第では高額になる

コストの問題があります。AWSは基本的に従量課金ですが、設定項目が多くなればそれ相当のコストが発生していきます。特に、ユーザーからのアクセスやスピードなどの監視は重要であるため、監視間隔を短くすると、それだけコストが高くかかってしまいます。

4. AWSのサービス全体がダウンすると障害の検知ができない

ITサービスはシステム障害がつきものですが、AWSも例外ではなく今までに何度か大規模な障害が発生して使えない状態になっています。CloudWatchはAWSのサービスですのでAWSのサービス全体が使えなくなると障害検知ができなくなってしまいます。

デメリットまで解消する代替SaaS

SaaS型フルスタック監視ツールの「Site24x7（サイトトゥエンティーセブン）」はAWS上のサービスの死活監視を実現し、かつ前項のCloudWatchのデメリットを解消します。簡単な操作で運用に必要な監視設定が素早くでき、ダッシュボードも最初から作り込まれているので特に手を加えることなく利用することができます。料金も低価格かつ定額で提供されるため、一度予算を組めば追加の費用はかかりません。CloudWatchの設定方法を見て、少しでも難しいと感じたら、Site24x7を検討してみることをお勧めします。

Site24x7ホームページ：
https://www.site24x7.jp/

まとめ

この記事ではCloudWatchでサービスの死活監視をする設定を紹介しました。サービスの死活監視を考える上で一番重要なのが、ユーザーが使える状態を監視することを紹介しました。続いて、ユーザーが体感する速度などユーザーの使い勝手が悪くなっていないかの監視が重要になります。そして、予防的な監視では、冗長化しているシステムであれば即時対応する必要はないですが、障害の復旧の観点では重要な監視になります。

また、CloudWatchでサービスの死活監視するメリットとデメリットについても紹介し、CloudWatchの代替手段としてSite24x7を紹介しました。

Site24x7は有料プランもスモールスタートが可能です。また、設定によるトラブルも少なくスムーズに設定することが可能です。CloudWatchでの設定に少しでも難しさを感じるようであれば、SaaS型の監視ソリューションであるSite24x7を採用してみてはいかがでしょうか。

プリープランのサインアップはこちら：
https://www.site24x7.jp/signup.html?pack=1&l=ja

プランと価格の詳細はこちら：
https://www.site24x7.jp/pricing.html

関連記事

 

免責事項：ここに記載されているすべての著作権、商標、商号は、元の所有者の所有物です。このWebページに含まれる情報は、一般的な情報提供のみを目的としており、そのような情報は、正確性、信頼性、または完全性について調査、監視、または確認されていません。 当社は、ここに含まれる情報への依存に起因する誤り、または損失に対する責任を明示的に否認します。