CloudWatchで出来ること、AWS監視のお作法とは
クラウド運用管理

クラウドへのシステム移行を検討されている企業や組織は増加する一方ですが、移行先の候補の一つとして挙げられるのが国内外で豊富な導入事例を持つAmazon Web Services（以降、AWSと略す）です。そうした企業や組織のシステムを預かる運用部門の方の中には、AWSに合わせて監視運用をどう設計すれば良いのかを悩まれ、まさに現在調査中の方も多くいらっしゃるかと思います。

本記事では、運用の中でもシステム安定稼働に無くてはならない「システム監視」にフォーカスし、

• Amazon CloudWatch（以降、CloudWatchと略す）でどういうことができるのか？
• AWS上でシステム監視を行う場合のお作法や注意点を知りたい

とお悩みの方にぜひ知って頂きたい情報をお伝えします。

1.1 CloudWatchとは？何ができる？

CloudWatch とは、AWS上で提供されるあらゆるサービスを監視するためのサービスです。後述しますが、特にPaaSやSaaSのようにユーザーが管理できる範囲が限られるサービスを監視するためには必要不可欠なサービスです。サービスの特長としては以下が挙げられます。

• 基本料金が無料（利用する機能や監視のデータ量に応じて課金）
• SaaSとして提供されるので、構築不要ですぐに利用を開始できる
• メトリクス（サービス毎のリソース情報）とログ（テキストデータ）を収集できる
• メトリクスの閾値や特定のログ出力などの条件を基に、アラート通知や対処の自動アクションを行うことができる

CloudWatchでは、アラート通知を行うCloudWatch Alarmやログの収集を行うCloudWatch Logs、サービスのイベント（状態）をトリガーにアクションを実行するCloudWatch Eventsなどの機能が提供されており、それらを組み合わせることで、システム監視を行うことが出来ます。以下のようなイメージです。

CloudWatch はAWSのすべてのサービスを監視することが出来ますが、サービスごとに監視できる項目は異なりますし、IaaSとPaaS / SaaSで監視の仕組みそのものも大きく異なります。ここからは、IaaSとPaaS / SaaSにおける監視の仕組みを詳しく説明していきます。

1.2 IaaS（EC2）の監視

AWSでは、Amazon Elastic Compute Cloud（以降、EC2と略す）という仮想サーバー構築サービスが提供されています。IaaSとして提供されるサービスなのでハードウェアやハイパーバイザーの監視は必要ありませんが、OSやアプリケーションのレイヤーはオンプレミスのシステム同様にユーザー側で監視する必要があります。EC2の監視方式として多く採用されるパターンには、以下の2つがあります。

それぞれメリット・デメリットがあるため、運用やシステムの要件に合わせて監視方式を選択する事を推奨しますが、本項では、CloudWatchを中心とした監視を行う場合の方法について解説します。
オンプレミスにおいて、サーバーの死活監視やCPU / メモリー等のリソース監視、OSやアプリケーションが出力するログの監視を実施していた方は多いと思いますが、EC2においてもシステム安定稼働のためにはそれらの監視は必要です。ではCloudWatchでどういう項目を監視できるのか、主な監視項目について簡単にまとめたのが以下です。

• 死活監視
  • EC2インスタンスの状態（「起動中（running）」や「停止中（stopped）」など稼働状態）やステータス（EC2ホストやネットワークなどサービスの異常）を検知できる
  • CloudWatch Eventsで検知し、CloudWatch Alarmで通知する
• リソース監視
  • CPU、メモリー、ディスクの使用量や使用率など、OSのパフォーマンスモニターと同等の情報をメトリクスとして収集できる
  • CloudWatch Alarmで閾値を設定し、閾値を違反した場合に通知する
• ログ監視
  • OSのシステムログやアプリケーションが出力するログファイルのテキストデータを収集できる
  • CloudWatch Logsで収集し、フィルター条件に一致したログテキストを検出時にCloudWatch Alarmで通知する

図で表すと、以下のようなイメージとなります。

システム監視に必要な基本的な監視項目は充足できていることが分かると思います。ただし、監視の項目やルールによってはCloudWatchの無料利用枠に収まらないので、注意が必要です。例えばメモリーやディスクのリソース情報はカスタムメトリクスという有料の機能オプションを利用しないと収集ができません。また、CloudWatchの監視の間隔は標準で5分間隔ですが、間隔を更に短くしようとした場合には料金が発生します。いずれも監視項目1つ（＝1メトリクス）あたりの月額従量課金となりますので、監視項目数や監視対象のEC2インスタンスの数が多いと、思わぬ金額になる場合もあります。CloudWatchの料金はAWSの公開ドキュメント（補足）を参照頂ければと思いますが、オンプレミスと同じ感覚で監視の設計をすると、ランニングコストに跳ね返ってくる恐れがあることは意識しておいた方が良いでしょう。

• （補足）

  Amazon CloudWatchの料金についてはAWSのウェブサイトでご確認ください。

  • Amazon CloudWatchの料金

1.3 PaaS / SaaSの監視

PaaS / SaaSの監視に関しても基本的な考え方はEC2と変わりません。サービスの稼働状況を把握するためには以下のような監視を行う必要があると思いますが、いずれもCloudWatchで実現できます。
CloudWatchで収集できるメトリクスは、サービス毎に様々な項目が定められていますが、本項ではAWSユーザーがよく利用するAmazon Relational Database Service（以降、Amazon RDSと略す）を例に説明します。

• 状態監視
  • サービスのイベント（データベースインスタンスの停止や状態変化など）を検知できる
  • CloudWatch Eventsで検知し、CloudWatch Alarmで通知する
• パフォーマンス監視
  • ストレージの空き容量やディスク書き込みI/O操作数やRead / Writeの性能などをメトリクスとして収集できる
  • CloudWatch Alarmで閾値を設定し、閾値を違反した場合に通知する
• ログ監視
  • Amazon RDSが出力するログを収集できる
  • CloudWatch Logsで収集し、フィルター条件に一致したログテキストを検出時にCloudWatch Alarmで通知する

図で表すと、以下のようなイメージとなります。EC2監視の場合と殆ど同じですが、CloudWatchエージェントを介さずに各種情報を収集できる点が異なります。

また、注意点もEC2監視の場合と同様です。上記で挙げたような項目は標準メトリクス（無料範囲内）で収集できますが、Amazon RDSのデータベースインスタンスが利用するメモリーやスワップ等のデータはカスタムメトリクスでしか収集できませんし、監視間隔の標準が5分間隔という仕様についてもEC2と同様です。そのため、監視の設計にはEC2同様に注意を払う必要があるでしょう。

2.1 CloudWatchでも簡単にできないことがある

CloudWatchでシステム監視を実現できることを説明しましたが、何でも簡単に実施できる訳ではありません。例えばオンプレミスでのシステム監視で実施していた以下のような事が簡単にできない場合もあります。

アプリケーション監視やプロセス監視

サーバー上で稼働するアプリケーションやプロセスの稼働監視をオンプレミスで実施していた方は多いと思いますが、CloudWatchの標準メトリクス等の無料範囲の機能では監視することができません。
具体的にはCloudWatchエージェントを用いたカスタムメトリクスによる監視を行う必要がありますが、CloudWatchエージェント設定ファイルというJSON形式のファイルにプロセス毎・監視項目毎に設定内容を記述する必要があり、設定作業が煩雑になります。EC2インスタンスの数が多くない場合でも、監視する項目やプロセスのパターンがEC2毎に異なるケースでは、設定作業や運用テストのバリエーションが増えることで現場の負担になるかもしれません。

ログ監視のフィルタリングに複雑な条件を設定する

CloudWatch Logsでログファイルやシステムログの監視ができることは前項で解説しましたが、設定できるフィルター条件は単純な文字列一致（ANDやORも可能）で、正規表現など複雑な条件を指定する事はできません。よって、オンプレミスでのシステム監視で複雑なログフィルター条件を使用してメッセージの量を極力減らすような工夫をされていた場合、クラウド移行後に監視メッセージが増えて監視運用の負荷が増す恐れがあります。

2.2 どうすれば良い？

前項で解説したような点や、CloudWatchの監視料金を意識した監視設計は、AWSに精通していたとしても時間と労力を要します。CloudWatchやAWSの様々なサービスを駆使すればクラウド移行後もオンプレミスと変わらぬレベルの監視運用を実現できますが、運用設計の再構築や監視を行うための設定・資材開発が運用部門の新たな負担にもなりかねません。
解決策の一つとして、特に業務アプリケーションが稼働するEC2監視については監視のレベルを維持するために既存の監視ツールで、それ以外のPaaS / SaaSに関してはCloudWatchで監視するというように、監視ツールを使い分けて、かつそれぞれのデータを統合して運用を効率化した事例もあります。
本記事の解説を参考に、システム監視の項目や条件等の必須要件を明確にし、コストや運用性を元に最適な監視運用の方式を検討して頂ければ幸いです。

こちらもおすすめ

皆さんが導入されている今の運用監視ツールで、ICTインフラの変化に追随できていますか？もしくは変化に対応するため、新たに運用監視ツールを導入したものの、負担が増えてしまった。そんな状況に陥っていませんか？富士通の運用管理ソリューションが解決します。

• 関連特集「ICTシステム監視の運用はクラウド化に素早く柔軟に対応できますか？」