AWS CloudWatchとは?できることやサービス詳細を解説
監視ツールにはさまざまな種類がありますが、その中でも代表的なツールとされているものがAWS(Amazon Web Services)が提供するAmazon CloudWatchです。クラウドサービスの普及により、多くのアプリケーションやサービスがAWS環境で開発されるようになったことで、Amazon CloudWatchを使用する機会は増えてきています。
ここでは、Amazon CloudWatchの概要やサービス詳細を解説するとともに、Amazon CloudWatchとオープンソース監視ツールの違いについても詳しく紹介します。
INDEX[非表示]
>> 「Amazon CloudWatch」に関するお悩み・ご相談はこちら
Amazon CloudWatchとは?
Amazon CloudWatch(以下、CloudWatch)は、AWSが提供する監視ツールです。Amazon EC2やAWS BackupなどのAWSサービスや、AWSで動作している仮想サーバなどを監視できます。
各サービスやサーバのリソース状態やログを監視すれば、リソースが変更されたときに何らかのアクションを起こしたり、異常が発生した場合にアラートを通知したりすることが可能です。
CloudWatchは「SaaS」として提供されているため、導入後すぐ利用を開始できる特徴があります。SaaSは、サービス提供者側で稼働しているソフトウェアをインターネットを通じて利用できる形態のため、基本的には開発作業の必要がありません。
AWSが提供するすべてのサービスはCloudWatchで監視できますが、サービスごとに監視できる項目が異なります。
例えばAmazon EC2のような仮想サーバ構築サービスの場合、サーバが正常に稼働しているかどうかを監視する「死活監視」、サーバのCPUやメモリの使用量および使用率を監視する「リソース監視」、OSやサーバのログを監視する「ログ監視」の3つが主な監視項目です。
Amazon RDSのようなデータ運用サービスの場合は、前述のログ監視に加え、サービスの状態変化を検知する「状態監視」、ストレージの空き容量やディスク読み書き回数などのパフォーマンスデータを収集する「パフォーマンス監視」の3つが主な監視項目です。
また、CloudWatchはさまざまなAWSサービスと連携できます。
具体的には、CloudWatchで取得したログをAmazon S3へ移行させたり、なにかイベントが発生した際にアクションを起こし、Amazon Lambdaと連携してプログラムを実行させたりすることが可能です。もちろん他のAWSシステムとも連携できるため、うまく活用できればさまざまな応用ができます。
CloudWatchをうまく活用すれば一部運用の自動化も実現できるため、AWSを利用していくうえでおすすめのサービスです。
CloudWatchの6つのサービスについて
CloudWatchは大きく6つのサービスに分類でき、サービスごとに異なる特徴をもっています。具体的にどのようなことができるのか、どのような場合にサービスが使われるのか、などを詳しく見ていきましょう。
CloudWatchメトリクス
CloudWatchメトリクスは、CloudWatchの基本となる概念です。メトリクスとは、監視対象のシステムのパフォーマンスに関するデータポイントのセットです。サーバのCPU使用率やディスク読み書き回数などがメトリクスにあたり、これらは監視項目としてあらかじめ用意されているため、すぐに監視を始められます。
また、CloudWatchでは「基本モニタリング」と「詳細モニタリング」の2つのカテゴリのモニタリングが提供されています。メトリクスのセットをCloudWatchに公開することでモニタリングは提供されており、多くのAWSのサービスで基本モニタリングを無料で使うことができます。
一方で詳細モニタリングは一部のサービスのみで提供されており、料金も発生します。
例えばAmazon EC2の場合、基本モニタリングではデータ取得タイミングが5分間隔で公開されるメトリクスが、詳細モニタリングではより高い頻度の1分間隔でデータ取得をおこなうメトリクスを有償で公開しています。
また、取得したメトリクスは利用できる期間が定められています。具体的な期間は以下のとおりです。
取得間隔が1分未満のメトリクス |
3時間利用可能 |
---|---|
取得間隔が1分のメトリクス |
15日間利用可能 |
取得間隔が5分のメトリクス |
63日間利用可能 |
取得間隔が1時間のメトリクス |
455日間利用可能 |
なお、取得間隔が短いメトリクスは最終的に長期保存のために集約されます。
例えば、取得間隔が1分のメトリクスが取得から15日以上経過した場合、1分間隔のメトリクスとしては利用できなくなりますが、5分間隔のメトリクスとしてなら利用可能です。同様に5分間隔のメトリクスは63日以降、1時間間隔のメトリクスに集約されるため、メトリクスは455日間利用可能です。
CloudWatchではメトリクスのグラフ化も可能です。グラフ化の際は「Minimum」「Maximum」「Sum」「SampleCount」「Average」などの統計を使用できます。各統計の詳細は以下のとおりです。
Minimum |
指定された期間の最小値 |
---|---|
Maximum |
指定された期間の最大値 |
Sum |
指定された期間のすべての値の合計値 |
SampleCount |
指定された期間のデータポイント数 |
Average |
SumをSampleCountで割った値 |
メトリクスをグラフ化することで、トラブルシューティングに役立てたり、時間経過による傾向を確認できたりと、より発展的にデータ表示ができます。
参考:Amazon CloudWatch「Amazon CloudWatch の概念」
CloudWatchエージェント
CloudWatchエージェントを使用すると、Amazon EC2インスタンスやサーバから追加のメトリクスを「カスタムメトリクス」として取得できます。仮想サーバのメモリ使用率やディスク書き込み動作の回数など、内部システムレベルのメトリクスを取得可能です。カスタムメトリクスは、CloudWatchメトリクスで取得したメトリクスと同様に、CloudWatchで保存・表示できます。
また、CloudWatchエージェントは、仮想サーバだけでなくオンプレミスサーバにもインストールできるため、オンプレミスサーバの内部システムレベルのメトリクスも取得可能です。CloudWatchメトリクスだけでは取得できないような、より詳細なメトリクスを取得したい場合に使用すると良いでしょう。
なお、CloudWatchエージェントを使用するためには、CloudWatchエージェント設定ファイルを作成しなければなりません。このファイルは取得したいメトリクス、ログ、トレースをJSONで指定したものです。ウィザードを使用する、もしくは1から手動で作成する必要があります。
CloudWatch Alarm
CloudWatch Alarmは、メトリクスに対するアラームを作成できるサービスです。一つのメトリクス、もしくは複数のメトリクスに基づくアラームを作成でき、作成したアラームはメトリクスが特定の値になった際に一つ以上のアクションを実行します。
実行するアクションは、Amazon SNSへのメッセージ送信による「ユーザーへの通知」が一般的です。
例えば、AWSアカウントへの請求が定義された値を超えた場合や、CPU使用率が定義された値を超えた場合などにユーザーへ通知できるようになります。
また、通常のアラームとは異なる「複合アラーム」も作成可能です。複合アラームは、他のアラームの状態を考慮したルール式を含むアラームで、ルールの条件がすべて満たされた場合のみアクションが実行されます。複雑なアラーム条件の作成も可能なため、アラームのノイズを低減できるでしょう。
CloudWatch Alarmで作成するアラームには「OK」「ALARM」「INSUFFICIENT_DATA」の3つの状態があります。「OK」はメトリクスが定義したしきい値の範囲内にある状態、「ALARM」はメトリクスが定義したしきい値を超えている状態、「INSUFFICIENT_DATA」はアラームが開始直後である、もしくはメトリクスを利用できないまたはメトリクス用のデータが不足しているため、アラームの状態を正常に判定できない状態です。そのため、アラームのアクションが実行されるのは状態が「ALARM」の場合となります。
CloudWatch Alarmはログに対するアラームも作成可能です。ロググループのメトリクスフィルターを作成すれば、メトリクスフィルターに基づいたアラームを作成できます。「ログ」については後述する「CloudWatch Logs」で解説しています。
状況に合わせてユーザーへ通知する役割があるため使用頻度が高く、CloudWatchの基本的なサービスの一つです。
CloudWatch Logs
CloudWatch Logsは、その名のとおりログに関連したサービスです。Amazon EC2やAWS CloudTrailなどのサービスからログを取得し、ログの保存や分析ができます。
例えばAmazon EC2の場合、取得したログを使用してアプリケーションとシステムをモニタリングすることで、CloudWatch Logsにエラーの数がトラッキングされていきます。エラー率が定義した値を超えた際に管理者に通知を送ることが可能です。また、AWS CloudTrailの場合は、AWS CloudTrailが受け取った特定のAPIアクティビティの通知を、トラブルシューティングの実行に使用できるようになります。
CloudWatch Logsの使用により、さまざまなAWSサービスログの一元管理が可能です。取得したログを分析し、問題の解決や原因特定に役立てたい場合に使用する機会が多いでしょう。
CloudWatch Logsで取得したログは、基本的に保持期間に制限はありませんが、ロググループごとに保持ポリシーを調整することで、1日間~10年間の保持期間を選択できます。
ログデータを分析する場合は「CloudWatch Logs Insights」を使用しましょう。CloudWatch Logs Insightsではサンプルのクエリやコマンドの説明、クエリの自動補完機能やログフィールドの検出機能などが提供されているため、簡単に使用を開始でき、サービス運用における問題の効率的な対処が可能です。「Live Tail」を併用すれば取得したログのリアルタイム表示およびフィルタリングが可能なため、より迅速に問題を解決できるでしょう。
なお、前述したCloudWatchエージェントを使用すれば、Amazon EC2内のアプリケーションやオンプレミスサーバからもログを取得可能です。取得したログは一定期間が経過したあと、ログローテートやAmazon S3に移動できます。
CloudWatch Events(Amazon EventBridge)
CloudWatch Eventsは、メトリクスやAPIをトリガーとして任意のアクション(イベント)を自動で実行するように設定できるサービスです。なお、現在はCloudWatch Eventsではなく、CloudWatch Eventsの機能をすべて備えたサービス「Amazon EventBridge」として提供されています。Amazon EventBridgeの使用により、イベントを通じてさまざまなアプリケーション同士を簡単に接続可能です。
Amazon EventBridgeは、「イベントバス」と「パイプ」と呼ばれる2つの方法でイベントを処理できます。
イベントバスの役割は、イベントを受信するルーターです。イベントを複数のターゲットに送信したい場合に適しており、オプションを活用すれば送信前にイベントを変換することもできます。
また、イベントバスは「デフォルトイベントバス」「カスタムイベントバス」「パートナーイベントバス」の3種類があります。
デフォルトイベントバスは、AWSサービスやカスタムアプリケーションで発生したイベントに使用できるイベントバスです。AWSアカウントにデフォルトで一つ作られます。
カスタムイベントバスはカスタムアプリケーションで発生したイベントに使用でき、自由に作成可能です。
パートナーイベントバスは、AWSサービス以外のSaaSサービス経由で発生したイベントに使用できます。ただし、基本的にはSaaSサービス側で登録しなければ使用できません。
パイプはAmazon EventBridgeから追加された機能です。イベントを生成しているソースを選択しターゲットに接続すれば、ターゲットへイベントをシームレスに送信できます。
イベントバスとパイプの2つの方法は同時に使用されることが多く、イベントバスをターゲットとしたパイプの作成が一般的な使用方法です。このように使用することで、パイプが受け取ったイベントをイベントバス経由で複数のターゲットに送信できます。
仮にAmazon EventBridgeのような、イベントをやり取りする機能をもつアプリケーションを作成した場合、負荷に応じたスケールやバージョンアップ対応などのメンテナンス負荷が懸念点です。しかし、Amazon EventBridgeはサーバレスなAWSサービスのため、スケールやバージョンアップは自動的におこなわれます。料金も安価なため、サービス間でイベントのやり取りが発生するようなシステムを構築する場合は使用をおすすめします。
CloudWatchダッシュボード
CloudWatchダッシュボードを使用すると、メトリクス・アラーム・ログ・イベントを可視化し、表示できます。さまざまなカスタマイズができ、別リージョンのメトリクスも一つの画面でモニタリング可能です。
例えば、選択されたメトリクスとアラームのための単一ビューを作成すれば、複数リージョンにまたがるリソースやアプリケーションの正常性を評価することができます。
ダッシュボードは、ユーザーがカスタマイズし作成する「カスタムダッシュボード」と、AWSが自動で作成してくれる「自動ダッシュボード」があり、カスタムダッシュボードは有料、自動ダッシュボードは無料で利用可能です。
また、作成したダッシュボードは他のユーザーと共有できます。AWSアカウントに直接アクセスできないユーザーとも共有できるため、同じ組織・チームに所属していないユーザーともダッシュボードの共有が可能です。
さまざまなリソースを可視化し表示すれば、効率的にリソースの利用状況などを把握できるでしょう。
CloudWatchとオープンソース監視ツールの違い
CloudWatchのような監視ツールはさまざまな種類があり、オープンソースで利用できる無料の監視ツールも少なくありません。CloudWatchとオープンソース監視ツールにはどのような違いがあるのでしょうか。今回は、CloudWatchとZabbixの違いを紹介します。
Zabbixは、ネットワークやサーバ、クラウドなどさまざまな対象を監視できるオープンソース監視ツールです。監視間隔は最小で1秒に設定でき、数値やテキストなどあらゆる形式でデータを収集できます。書籍やコミュニティが充実しているため、有用な情報を得やすいです。
CloudWatchとZabbixを5つの項目で比較した詳細は下記のとおりです。
CloudWatch |
Zabbix |
|
---|---|---|
料金 |
従量課金制 (一部機能は無料で利用可能) |
無料で利用可能 |
サーバ |
サーバレス |
監視システムのサーバ構築が必要 |
監視対象 |
AWSサービス向け |
オンプレミスサーバや Azure・GCPにも対応 |
導入難易度 |
設定不要ですぐに利用可能 |
機能や設定項目が多く難易度は高め |
カスタマイズ性 |
やや低め |
細かいカスタマイズが可能 |
Amazon EC2を監視したいのであれば、基本的にCloudWatchが有力候補となるでしょう。CloudWatchはAWSが提供しているツールのため、AWSサービスの監視に関しては最良のツールといえます。
上記を踏まえたうえで、CloudWatchとオープンソース監視ツールでどちらを導入するべきか迷っている場合は、監視ツールを利用するにあたってなにを重視するかを選択基準にすると良いでしょう。
例えば、できるだけ早く監視ツールを利用したいなら設定不要なCloudWatchが適しており、細かいカスタマイズをおこないたいならオープンソース監視ツールをおすすめします。
CloudWatchの料金形態について
CloudWatchは従量課金制のため、初期費用は不要です。利用したサービスごとに使った分だけ料金を支払う形態です。また、すべてのサービスが有料なわけではなく、以下のような一部のサービスは無料で利用できます。
- 基本モニタリングのメトリクス(5分間隔)
- 詳細モニタリングのメトリクスやカスタムメトリクス10個(1分間隔)
- 100万件のAPIリクエスト
- 毎月最大50個のメトリクスに対応するダッシュボード3個
- 10件のアラームメトリクス
- 5GBのログデータ
- カスタムイベント以外のすべてのイベント
最小限の機能動作であれば無料で利用できる範囲でも十分に可能ですが、大量のメトリクスやログを取得し、より詳細にシステムを監視したい場合は、料金を支払い有料利用枠のサービスを利用したほうが良いでしょう。有料利用枠の料金は以下をご覧ください。
サービス名 |
要件 |
月額料金 |
---|---|---|
詳細モニタリング
カスタムメトリクス
|
最初の10,000メトリクス |
メトリクス一つあたり0.3ドル |
次の240,000メトリクス |
メトリクス一つあたり0.1ドル |
|
次の750,000メトリクス |
メトリクス一つあたり0.05ドル |
|
1,000,000を超えるメトリクス |
メトリクス一つあたり0.02ドル |
|
アラーム |
標準解像度アラームメトリクス |
アラームメトリクスあたり0.1ドル |
高解像度アラームメトリクス |
アラームメトリクスあたり0.3ドル |
|
複合アラーム |
複合アラームあたり0.5ドル |
|
ログ |
収集 (スタンダード) |
1GBあたり0.76ドル |
収集 (低頻度アクセス) |
1GBあたり0.38ドル |
|
保存 (アーカイブ) |
1GBあたり0.033ドル |
|
分析 (Logs Insights のクエリ) |
スキャンしたデータ1GBあたり 0.0076ドル |
|
検出およびマスク (データ保護) |
スキャンされたデータ1GB あたり 0.12ドル |
|
分析 (Live Tail) |
1分あたり0.01ドル |
|
イベント |
カスタムイベント |
イベント100万件あたり1.00ドル |
クロスアカウントイベント |
イベント100万件あたり1.00ドル |
|
ダッシュボード |
カスタムダッシュボード |
1ヵ月あたりのダッシュボードあたり 3.00ドル |
(※2024年1月時点の東京リージョンの料金の一部を記載しております。)
要件ごとに細かく料金が設定されていますが、AWS公式サイトでは「AWS料金計算ツール」が公開されています。メトリクスやログの数を入力すればすぐに見積もりを作成できるため、CloudWatchを導入する際は事前に見積もりを作成しておくと良いでしょう。
Amazon EC2の詳細モニタリングやログを使用したモニタリングなど、利用方法ごとの料金例も紹介されているため確認をおすすめします。ツールではなく、詳細な見積もりを希望する場合は、AWSのスペシャリストによるサポートを受けることも可能です。
参考:AWS「Amazon CloudWatch の料金」
CloudWatchの監視事例
最後に、実際にCloudWatchを導入し、活用している企業の監視事例を紹介します。
双日ロイヤルインフライトケイタリング株式会社さま
双日ロイヤルインフライトケイタリング株式会社は、航空機内食の調製・販売や海外への食品販売を手掛けています。親会社の変更にともない、7ヵ月間で新しい社内システムの構築を求められたことが、AWSおよびCloudWatchの導入を決意したきっかけです。
拠点ネットワークの切替えや、ユーザー端末設定変更には新しい社内システムの稼働が前提とされたため、AWSマネージドサービスを活用して短期間で環境を再構築しました。新しい社内システムと拠点ネットワークの監視運用にCloudWatchを利用しており、お客様の運用負荷軽減に役立っています。
>> CloudWatchを利用した監視運用事例の詳細はこちら
まとめ
今回紹介したようにCloudWatchにはさまざまなサービスがあり、他のAWSサービスの監視に適したツールといえます。各サービスを使いこなすことで、効率的なサーバ・サービスの監視が可能となるでしょう。
株式会社エヌアイデイは、AWSアドバンストティアサービスパートナーとして、お客様の課題に合わせた幅広いクラウドソリューションを提供しています。お客様の経営課題の解決に向けた最適なクラウドソリューションを提案いたしますので、お気軽にご相談ください。
>> エヌアイデイのクラウドソリューションについて詳しくはこちら
またエヌアイデイでは、IT精通した専門チームによる24時間/365日のリモート運用・監視サービスも提供しています。
長年にわたりシステム運用をおこなってきた知見と体制による、セキュアで高品質な運用監視が可能です。
>> 運用監視サービスならエヌアイデイ「MesoblueMSP」