こんなことを感じていませんか？
〇AWS運用のために社内のリソースが足りずに困っている
〇障害発生時の対応に不安がある
〇運用だけでなく構成のアドバイスもあると嬉しい
システムの動きを捉える「可視化」は、セキュリティ上、運用効率上で重要なテーマであることは言うまでもありません。オンプレミスよりコスト優位とされるクラウドコンピューティングの利用においても、可視化を行うための監視機能の導入は不可欠です。
AWSではEC2インスタンスなどAWS上で稼働するサービスやサーバーの監視を中心に行えるサービスとして「Amazon CloudWatch（クラウドウォッチ）」が利用できます。
今回は、Amazon CloudWatchのサービス概要から、CloudWatch Logs、Amazon EventBridge（旧CloudWatch Events）などの機能やAWS上での監視方法、利用する際の注意点を解説します。
Amazon CloudWatchとは
Amazon CloudWatchとは、AWS上で動作するさまざまなリソースのメトリクスを収集し稼働状況を監視できるサービスです。
※メトリクスとはEC2インスタンスを例にするとCPU使用率やDisk I/Oなどの情報を指します。
また、AWSの利用料金の変化も監視できます。EC2インスタンスの場合は起動すると使える状態になっており、インストールなどの導入作業は必要ありません。
Amazon CloudWatchでできること・特長
1.システムの異常を検知し、障害時間を短縮する
CloudWatchはシステムの異常を即時に検知し、自動で正常なシステムに切り替えるなどの仕組み作りも可能なため、障害時間の短縮を図れます。
2.システムのリソース配分を最適な状態にする
システムのリソース不足は、システム運用者にとっては心配のもとです。とはいえ、常に余裕のある容量を用意するとなると、過剰の設備となります。また、今どのようなアプリケーションが使われているのか、無駄なシステムの稼働はないかなど、適切な運用を促すようにすることで、最適なシステム環境と、最良のコストバランスを得ることができます。
(1)余剰リソースの調整によるコスト削減
Amazon CloudWatchは、システムの監視のためのモニタリングだけではなく、自動設定などにより、運用管理の負担やコストを削減することもできます。例えば、活用されていないインスタンスを監視・抽出して、自動的に停止することで、従量課金制のAWSでは、パフォーマンスに合った適切なコスト管理も可能になります。
(2)リソース不足時のオートスケーリングなど
EC2のCPUやメモリの使用率を監視し、あらかじめ決めたしきい値を超えた場合に、インスタンス数を自動で増やすなども可能です。
また、しきい値より下がった場合はインスタンス数を自動で減らすこともできます。
Amazon CloudWatchの5つの機能
Amazon CloudWatchで利用システムを可視化する方法は、システムモニタリングデータと運用データをログ、メトリクス、イベントという形式で取得することで実現します。それらのシステムやアプリケーションの運用情報を視覚化して、利用者に提示する仕組みがモニタリング機能です。さらに、これらの情報から察知したイベントの変化などに合わせ、アラームを発信したり、利用システムの自動切り替えなどを設定したりすることが可能なのです。それぞれの形式の概要は、以下のとおりです。
1.メトリクス
メトリクスはパフォーマンスに関するデータであり、例えば、CPU使用率などの情報です。システム稼働状態を定量化し、CloudWatchに送信することで、リスト表示やグラフ化など、わかりやすいかたちでシステムの状態を把握できるようにする機能です。検知レベルの設定で、アラート表示を設定することもできます。
一般的なCPU使用率などは、標準メトリクスとして取得できますが、それ以外のメトリクスは、Amazon CloudWatch Logsを各サーバーにインストールすることで取得対象となります。
メトリクスの保存期間
すべてのメトリクスには保存期間が存在します。
| データポイントの期間 | 保存日数 |
| 60秒未満のデータポイント | 3時間 |
| 1分のデータポイント | 15日間 |
| 5分のデータポイント | 63日間 |
| 1時間のデータポイント | 455日間（15か月） |
短い期間のデータポイントは、保存日数を超えると長期保存するために集約されます。たとえば、1分のデータポイントは15日間その状態で確認できますが、保存日数を超えると「5分のデータポイント」に集約され、5分単位で確認可能です。
また、終了したEC2インスタンスなどのメトリクスデータは15か月間保存されるため、終了後も確認できます。
2.ログの収集 CloudWatch Logs
Amazon CloudWatch Logsは下記AWS各種サービスのログの監視、保存、アクセスが一元管理できる機能です。
・Amazon EC2インスタンス
・AWS CloudTail
・Route 53
・対応しているその他AWSサービス
CloudWatch Logへログやメトリクスを収集するために、監視対象のAmazonEC2にAgent（エージェント）をインストールします。Agentはオンプレミスサーバーにもインストールすることもできて、条件が適合すればログを取得できます。ログは蓄積、フィルタリング、グラフ化、アラート機能の利用などが可能です。さらに、Amazon CloudWatch Logs Insightsを使うと分析も可能になります。
3.イベント駆動 Amazon EventBridge（旧CloudWatch Events）
Amazon EventBridgeは例えばパッチ処理完了や、CPU使用率の上昇などのリソースの変化などのイベントを通じてさまざまなアプリケーションを簡単に接続できるようにするサービスです。AWSのサービスや既存のシステム、SaaS、アプリケーション同士を接続し、イベント駆動型アプリケーションを簡単に構築できます。
Amazon EventBridgeは従来のCloudwatch Eventsから派生・独立したサービスで機能が拡張されて、より使いやすくなっています。Cloudwatch EventsではAWS内のイベントや、cron機能による定時のイベントのみ取り扱う事ができましたが、Amazon EventBridgeではAWS以外のSaaS製品で発生したイベントも取り扱えます。また、異なるリージョン間でのイベントの集約も可能となりました。
Amazon EventBridgeはCloudWatch Eventと同じAPIを使用するため、従来のCloudWatch Eventを利用していた場合も乗り換えをする必要はなくそのままAmazon EventBridgeを利用できます。
4.モニタリング CloudWatch Dashboard
Amazon CloudWatchダッシュボードとは、グラフでグラフィカルにサービスやログを統合的に可視化する機能です。複数の異なるリージョン（地域）にまたがっているリソースやアプリケーションをひとつの画面で監視できます。さらには、AWS上のリソースのメトリクスや、カスタマイズしたアラームの状態なども表示させることができます。
CloudWatchへのアクセスや設定は以下から可能です。
・AWS CLI：AWSサービスを管理するための統合ツール
・CloudWatch API：APIを利用してCloudWatchを自社に適したように設定可能
・AWS SDK：希望する開発言語やプラットフォームでAWSのサービスにアクセスし、管理
5.アラーム通知 CloudWatch Alarm
監視するメトリクスが特定のしきい値を超えた場合に メールを送信するなどの通知アクションを実行します。例えば、EC2インスタンスがCPUの使用率が１分間50%以上に達したときに、CloudWatchからメールを送信するなどです。
▼ AWSサービスを利用した障害の対応方法を解説！
Amazon CloudWatchの料金体系
Amazon CloudWatchの料金体系はどのようになっているのでしょうか。
従量課金
Amazon CloudWatchも、他のAWSサービスと同様に、導入のための初期費用や、月々の基本料金のようなものはありません。従量制の料金体系となり、利用量に応じた料金を月末に支払います。
AWS料金計算ツール
AWS料金計算ツールでは、サービスの設定をいくつかのパターンで想定しつつ、月額料金のシミュレーションをすることができます。また見積りを使わなくても、アジアパシフィック（東京）でのメトリクス、API、ダッシュボード、アラーム、ログ、イベント別に料金の目安が提示されていますので、まずはそちらを参照してみるとよいでしょう。
※AWS料金計算ツールAWS Pricing Calculatorについてはこちらで詳しく解説しています。
請求代行リセールサービス
Amazon CloudWatchの利用料を抑えたい場合には、パートナー企業が提供する請求代行リセールサービスを利用するのも一つの手です。パートナーによってはAWS利用料を割引で提供しているケースもあります。
当社、NHNテコラスが提供するリセールサービスはAWS料金が定価の 8% 割引になります。＜マンガでわかる＞AWSリセールサービスの資料では、無料の申込でなぜAWS料金が安くなるのか？どんなメリットがあるのか？マンガでわかりやすく解説しています。
無料枠
AWSのEC2やS3などのサービスには無料利用枠が用意されており、検討の段階では試用し、評価を行ってから本格的な導入へ移行できるようになっています。Amazon CloudWatchにも無料枠が用意されており、以下を実際に試してみることができます。
メトリクス
基本モニタリングのメトリクス（5分間隔）、詳細モニタリングのメトリクス 10 個 (1 分間隔)、 100 万の API リクエストが可能ですが、GetMetricData および GetMetricWidgetImage には適用されません。
ダッシュボード
毎月最大 50 個のメトリクスに対応するダッシュボード 3 個までです。
アラーム
10 件のアラームメトリクスが設定できますが、高分解能アラームは無料枠からは対象外となります。
ログ
取り込み、ストレージのアーカイブ、Logs Insights クエリによってスキャンされたデータなど、 5 GBまでのログが取得できます。
Amazon EventBridge
AWS のサービスによって発行されたすべての状態変更イベント、AWS およびカスタムスキーマのスキーマレジストリ、また、スキーマの検出は毎月500 万件のイベントが無料です。
これらのモニタリング機能を試すために適したアプリケーションも多数用意されているので、実際の利用を想定したAmazon CloudWatchのパフォーマンスをシミュレーションすることができます。
ただし、上記の無料利用の枠内だけでは、機能や利点の確認には不十分の場合もありえます。他の監視ツールと併用して比較したり、一時的に最小限の範囲に限定し、有料枠で使ってみたりすることをおすすめします。Amazon CloudWatchは初期費用、月額基本料が不要ですので、試用期間の利用料だけのお支払いですみます。AWSの料金体系はすべてそのような設定ですので、Amazon CloudWatchの試用を機会に、他に興味のあるAWSと合わせて試してみることも検討できます。
Amazon CloudWatchを利用したAWSの監視方法
Amazon CloudWatchの設定前に監視計画を立てる
Anazon CloudWatchは、AWSサービスを利用している場合は即座に利用することが可能です。しかし、無計画に利用を開始しても効果的な監視は難しいでしょう。
Amazon CloudWatchの設定を行う前には、しっかりと監視計画を立てることが重要です。その具体的な流れは次のとおりです。
１．モニタリングの優先順位を設定する
２．モニタリング対象を設定する
３．Amazon CloudWatchで設定を行う
AWSを利用する場合、複数のサービスを利用することがほとんどでしょう。しかし、すべてのサービスにおいて監視が必要であっても、監視する優先順位を設定することが大切です。優先順位を指標とすることで、何らかの問題が発生した場合、復旧の手順や優先すべき項目の作業から着手でき、問題を早期に解決することができます。まずは、サービスやインスタンス単位で優先順位を設定することからはじめましょう。
次に、モニタリング対象として以下に挙げる項目を設定します。
１．監視の目的
２．監視頻度
３．通知の有無
４．自動復旧の有無
モニタリングの優先順位にしたがって対象を設定するところまで完了してから、Amazon CloudWatchで設定を行ないます。
Amazon CloudWatchの監視設定
Amazon CloudWatchを使った監視の設定の流れは大まかに次のとおりです。
１．対象インスタンスのメトリクスを追加する
２．アラームを作成する
３．必要に応じてダッシュボードを作成する
はじめに対象インスタンスのメトリクス（標準/カスタム）を作成し、しきい値に応じたアラームを作成します。その後、必要に応じてダッシュボードを作成しましょう。ダッシュボードでは、任意の監視項目を一覧表示できます。
「AWS技術支援・コンサルティングサービス」はこちら
Amazon CloudWatchを利用して監視する際の注意点
カスタムメトリクスを作り込む場合はノウハウが必要
Amazon CloudWatchで利用できる標準メトリクスは、例えばEC2インスタンスのCPU使用率やネットワーク使用率などが用意されていますが、アプリケーションのプロセス数の監視などは行えません。
ウェブページのロードに要する時間、リクエストエラー率、インスタンス上のプロセスやスレッドの数、アプリケーションで実行された作業の量などを監視する場合はカスタムメトリクスを作成しなければなりません。カスタムメトリクスはPutMetricData APIを利用しますが、AWS Systems Manager（SSM）エージェントが必要であったり、IAMロールの設定が必要であったりします。
そのため、カスタムメトリクスを作り込む場合は、ある程度のノウハウが必要になる点は注意が必要です。モニタリングスクリプトのサンプルやプラグイン集が用意されているため、まずはそちらを利用することをおすすめします。
メトリクスは削除ができない
Amazon CloudWatchではメトリクスの削除がサポートされていません。「メトリクスの保存期間」項目で紹介した保存期間スケジュールに基づいて15か月間後に有効期限切れとなり削除されます。
過去 2 週間に新しいデータポイントがないメトリクスは、コンソールに表示されない
過去2週間に新しいデータポイントがないメトリクスは、コンソールに表示されないため注意が必要です。
AWS CLIで「get-metric-data」や「get-metric-statistics」コマンドを入力することで表示することは可能ですが、データポイントがないと原則表示されないことは覚えておきましょう。
しきい値超え、復旧時のアクションをしっかりと確認する
標準メトリクスを利用する場合は、しきい値設定をしっかりと行うことが重要となります。標準メトリクスは手軽に利用できますが、監視する目的を考えればしきい値設定が行えていないとあまり意味をなさないといえるでしょう。
単純にEC2インスタンスなどの稼働状況を見たいだけであれば、しきい値設定は必要ありませんが、稼働状況によってアクションを起こさなければならないことがほとんどであるため、しきい値設定は重要なのです。
また、標準メトリクスごとに単位は異なるものであるため、しきい値として設定する値はパーセントなのか、数値なのかといった細かい部分にも注意が必要となります。
しきい値を超えた際のアクションだけでなく、復旧時のアクションもしっかりとテストして確認することが重要です。
メトリクスデータが欠落した場合の対応を定義しておく
Amazon CloudWatchで監視する際には、しきい値超え/復旧の状態のほかに、メトリクスデータが欠落した状態も考えられます。
メトリクスデータが欠落した状態は、そもそも監視対象項目の監視ができていない、ということですので、この場合の対応も定義しておくことが重要です。
CloudWatch Alarmでは、メトリクスデータが欠落した状態をしきい値超過として設定することが可能ですので、あわせて定義しておきましょう。
復旧までの自動化にはスクリプトなどの知識も求められる
CloudWatch Alarmでは、しきい値によってアクションを設定できるため、ある程度の復旧に対する自動化が行えます。しかし、設定できるアクションとしては、通知、Auto Scaling、EC2アクション のみであり、EC2インスタンスの再起動などしか行えません。
例えば、アプリケーションのプロセス数を監視していて、しきい値を超えた場合に対象アプリケーションのみを再起動する、といった復旧対応を自動化するためには、別途対応アクション用のスクリプトなどが必要になります。
そのため、復旧までの自動化にはスクリプトなどの知識も求められる点は、注意点として覚えておきましょう。
Amazon CloudWatchは無料枠からはじめてみる
AWSをすでに利用している場合は、Amazon CloudWatchの利便性について、無料枠や限定的な有料枠での利用から知ることができます。AWSには各種のサービスが用意されていますが、イベントの変化に合わせた利用システムの自動変更や、稼働の最適化によるコストダウンなどに使えるAmazon CloudWatchについても、これを機会に検討してみてはいかがでしょうか。
もちろん、AWSはこれからというユーザーでも、Amazon CloudWatchを中心に、システムの可視化や最適化を目的として、導入の検討としての無料利用枠から試してみることをおすすめします。
▼ 無料の申込みでAWS料金が安くなり、技術サポートも無料！リセールサービスをマンガで解説します。
