AWS CloudWatchとは?ITサービスの運用を自動化する


CloudWatchとは?
CloudWatchとは?

Cloudwatchとは、AWS(Amazon Web Services)で提供されているモニタリングサービスです。
単にAWS上に構築したITサービスをモニタリングするだけでなく、カスタムメトリクスという機能を利用する事で
他のクラウド上やオンプレミス上に構築したITサービスのモニタリングを統合することができます。
また、Cloudwatchを起点として、他のAWSサービスと連携することも可能です。
つまり、このサービスを使いこなすことによって、AWSでのITサービス運用を自動的に、かつ安定的にすることができます。
具体的にどのような機能が存在しているのでしょうか?詳しく見ていきましょう。

CloudWatchを使って何ができるのか?

では、CloudWatchではどのようなことができるか、概要を記載していきます。
CloudWatchは大きく分けて以下の4つの機能が存在しています。

  • CloudWatch
  • CloudWatch Logs
  • CloudWatch Alarm
  • CloudWatch Events

CloudWatchとは?

CloudWatchの主な機能は、AWSで利用しているリソースの監視を行う機能です。
EBSやEC2、RDSといった、AWS上の各サービスについて、具体的にどのようなリソースを監視しているかというと、CPUやネットワークのトラフィック量といった、OSよりも下位のレイヤのリソース情報を取得し、監視しています。
では、メモリ使用率等の、OSよりも上のレイヤのリソースについては監視が不可能なのでしょうか。
そのようなことはなく、カスタムメトリクスという機能を用いて、Githubなどで管理されている、メモリやディスクの容量についての情報を得て、CloudwatchにPushするスクリプトを利用して、CPUなどのリソースと同じように監視を行うことが可能です。
また、取得したリソースから、統計情報として、様々なデータを得ることも可能です。
たとえば、CPU使用率の最大値や最小値、平均値といったデータを得ることも可能ですし、1時間、3時間など、期間を指定してグラフなどで閲覧することも可能です。

CloudWatch Logsとは?

CloudWatch Logsとは、すべてのシステムのログ収集、分析を行えるサービスです。
ログ収集のためには、CloudWatch Logs Agentと呼ばれるエージェントを、導入したい対象にインストールすれば、ログの収集が可能になります。
CloudWatch Logsに収集したデータを、CloudWatch Logs Insightsという機能を使って分析/可視化を行うことも可能です。
CloudWatch Logsは一定期間ログの保管が可能で、一定期間経過後はログをローテーションさせることや、S3などに移すことも可能です。

CloudWatch Alarmとは?

Cloudwatchのメトリクスやログを収集して、メールなどで通知を行うことができる機能です。
例えば、EC2のCPU使用率が90%を超えたときにアラートメールを通知する、といった利用方法が可能です。
加えて、AutoScalingの機能と連動して、一定の条件でサーバの台数を自動的に増やす、といった利用方法もできます。

CloudWatch Eventsとは?

イベントベース、およびスケジュールベースで別のアクションを起こすことができます。
最近では、Amazon Event Bridgeと呼ばれることもあります。
『イベント』とは、AWSにおける何らかの変化を表しています。
例えば、CloudFormationでインフラ環境をデプロイする際に、Deploying→Completeのように、ステータスが変化していくと思いますが、この変化が『イベント』にあたります。
また、Linuxにおけるcronのように、スケジュールベースで指定のアクションを起こすことも可能になっています。

CloudWatchによる監視

CloudWatchの利用にあたり、知っておくべき内容を2点記載します。

メトリクスの概念

ある時間ごとの取得したデータのカタマリを表します。
例えば、EC2のCPU使用率について1か月分のログデータがあるとすると、そのデータのカタマリは『メトリクス』と表すことができます。
AWSのサービス以外がCloudwatchに送信するメトリクスを、『カスタムメトリクス』といいます。
例えばEC2のメモリ使用率のログデータのカタマリを、1か月分CloudWatchにPushた場合は、メモリ使用率のカスタムメトリクスが生成されます。
メトリクスを一意に識別するための名前と値(EC2のインスタンスIDなど)のペアを、ディメンションといいます。

ダッシュボード機能

CloudWatchコンソール上で、ダッシュボードを作ることができます。
このダッシュボード機能はCloudWatchのメイン機能といっても過言ではありません。
他のリージョンの情報も1つのダッシュボードにまとめてモニタリングが可能です。
監視したいメトリクスを組み合わせ、折れ線グラフといった可視化や、マークダウンなどへのテキスト化が可能です。
また、カスタマイズの手間を省きたい場合はAWS推奨のダッシュボードも用意されています。

CloudWatch Alarmの使い方

つぎに、CloudWatch Alarmの使い方について記載します。

アラームの種類

アラームの状態は以下の3つの種類があります。

  • 正常(OK)…定義された閾値を下回っている。
  • ALARM(異常値)…定義された閾値を上回っている。
  • INSUFFICIENT_DATA(判定不能)…CloudWatch特有で、データ不足のため判別できない状況で、異常であるというわけではありません。

ユースケース

では、CloudWatch Alarmの具体的なユースケースを見ていきましょう。
CloudWatch Alarmは以下のサービスと直接連携することができます。

  • Simple Notification Service(SNS)
    • AWS Chatbot
  • EC2(再起動など)
  • AutoScaling
    上記のサービスと連携した場合、どのようなことが実現できるのか、具体的に見ていきましょう。
  • サーバの自動的な増減
    EC2のCPU等が高騰しているときに、CloudWatch AlarmとAutoScalingを開始することが可能です。
    これによって、Webアプリケーションなどで、一時的に高負荷な状態になった場合、
    AutoScalingの機能によりサーバの台数を増やすことが可能です。
  • サーバの自動的な再起動
    EC2が突然応答しなくなった場合など、強制的に再起動やインスタンスの終了を行うことができます。
    これにより、EC2が動かないなどの障害が発生しても、自動的に復旧できるため、
    復旧作業が不要になります。
  • SNSでrootアカウントでのログインを検知する。
    CloudWatchと、CloudTrail(AWSでの操作をロギングするサービス)、SNSを連携させることでログインのモニタリングが可能です。
    AWSのrootアカウントでの操作は、基本的に非推奨であり、不正ログインをされてしまうと大きな被害にあってしまいます。
    しがたって、rootログインが行われた際にCloudWatch Alarmを利用してアカウントの持ち主にメールを送付する、といったセキュリティを強固にする使い方が可能です。
  • Simple Notification Service(SNS)へ通知した内容をSlackに通知する
    2020年のUpdateで利用可能となったAWS Chatbotを利用して
    CloudWatch Alarmの内容をSlackへ通知する事が可能となりました。

CloudWatch Logsの使い方

CloudWatch Logsの使い方について、具体的に記載していきます。

CloudWatch Logsを用いてログ収集の使い方

CloudWatch Logsを用いてログ収集を行うためには、主に以下の2つの手段があります。

  • CloudWatch Logs エージェントを利用する。
  • 各サービスでログを有効化する。

    具体的にどのような方法なのか、見ていきましょう。
  • CloudWatch Logs エージェントを利用する。
    EC2で稼働しているログをCloudWatchに送りたい場合、CloudWatch LogsエージェントをEC2にインストールし、設定ファイルを変更/エージェントを起動することでCloudWatch Logsへログを送ることができます。
  • 各サービスでログを有効化する。
    CloudWatch Logsをインストールできない、PaaSやSaaS(例えばLambdaやRDSなど)は、コンソール画面でロギングを有効にすると、自動的にロググループが作成され、ログの収集が開始されます。
    ただし、AWS WAFなど、中には2020年現在CloudWatch Logsでのロギングが不可能なサービスも存在します。

CloudWatch Logsの階層

CloudWatch Logsは以下の3つの階層に分かれています。

  • ロググループ
    ロググループは、監視の設定やログローテーションの設定を共有するグループです。
  • ログストリーム
    同じソースを共有する1連のログイベントです。
    例えば、同一のEC2や同一のコンテナのログなどは、1つのログストリームに分けることができます。
    複数のログイベントで構成されています。
  • ログイベント
    実際のログデータが格納されています。

他のサービスへの連携

CloudWatch Logsは他のサービスとの連携も可能です。
たとえば、サブスクリプションフィルタという機能を利用し、Kinesisと連携して、ログデータの加工を行ったり、S3にデータを保存できたり、とった連携が可能です。

メトリクスフィルタ

CloudWatch Logs メトリクスフィルタは、膨大なログの中から、特定の文字列をフィルタリングし、アクションを起こせる機能です。
例えば、ELBのログに、5XXのレスポンスコードが5回以上記録されていたら、SNS経由でメール/Slack通知する、といった使い方が可能です。

ログの分析・可視化

  • CloudWatch Logs Insight
    保存されているデータに直接クエリを行い、分析を行える機能です。
    例えば、EC2で構築されたWebサーバの、アクセス数などを表示することができます。
    クエリ結果はグラフ等で可視化することも可能です。

CloudWatch Eventsの使い方

CloudWatchEventについて、具体的に使い方を見ていきましょう。

時間ベースの実行

ここでは、Lambdaを例に使い方について見ていきます。
Lambdaを毎日00:00に実行したい場合は、以下のように設定を行うとできるようになります。
1.CloudWatchコンソールを開き、『イベント』をクリックする。
2.『ルールを作成』を選択する。
3.名前と説明を記載する。
4.ラジオボタンでスケジュールを選択する。
5.Cronを選択し、cron(0 0 * * ? *)と入力する。
6.ターゲットをLambda関数とし、定期実行したいLambda関数名を選択する。
7.任意でタグを入力し、『作成』をクリックする。

これで、Cron以外にも、一定期間おきにイベントを発生させる設定も可能です。
Cronで設定するのは難しい『12分おきに実行』といった設定が可能になります。

イベントベースの実行

次に、イベントベースの実行について、セキュリティインシデントをGuardDutyが検知した場合ににメールを送る、といった使い方を見ていきます。
以下のように設定を行うと可能です。
1.CloudWatchコンソールを開き、『イベント』→『ルールを作成』を選択、名前と説明を記載する。(ここまでは時間ベースの実行と同じです)
2.ラジオボタンイベントパターンを選択する。
3.サービスプロバイダーをAWS,サービス名をGuardDuty、イベントタイプをGuardDutyFindingに設定する。
4.ターゲットをSNSトピックとし、送りたいメールアドレスに紐づいたSNSトピック名を選択する。

イベントタイプはGuardDuty以外にも、CloudFormationやCodepipelineといったAWSのサービスのほか、サードパーティのサービスも指定可能です。

料金

CloudWatchの料金については以下に詳細が記載されています。
https://aws.amazon.com/jp/cloudwatch/pricing/
ここでは、CloudWatchを利用している中で、思わぬ高額利用を防ぐための方法を記載します。

  • CloudWatch Insightで分析をするときは分析対象を絞る
    CloudWatch Insightでの分析は、1GBあたり0.005ドルかかります。
    仮に、1TBのログを分析した場合、1回の分析で5ドルもかかってしまいます。
    したがって、分析対象は極力少なくしましょう。
  • ログは永久に保存しない。
    CloudWatch Logsはログを永久に保管します。
    したがって、時がたつにつれ、課金額が雪だるま式に膨らんでいきます。
    S3にエクスポートするなどして、適切にローテーションしましょう。
  • CloudWatch Alarmで課金アラートを設定する。
    CloudWatch Alarmの機能で、一定の利用料金に達した場合はアラートを上げる機能があります。
    事前に設定することで、高額な請求を防止できます。

CloudWatch vs Zabbix

CloudWatchと同様のシステム監視ツールとしてZabbixが有名ですが、
ZabbixとCloudWatchはどのようなメリット、デメリットがあるのでしょうか。

Zabbix

まずは、Zabbixのメリット、デメリットについてみていきます。

メリット

  • 安い
    ZabbixはOSSとして提供されているため、非常に安価に導入することが可能です。
  • プラットフォームを選ばない
    オンプレミスやGCP、Azureといった環境も、Zabbixは監視可能です。

デメリット

  • 構築の工数がかかる
    ZabbixはOSにインストールして初期設定が必要なので、使い始めるためには工数が必要です。
  • Zabbix自体の運用が必要
    ZabbixはLinuxなどのOSにインストールをして利用します。
    ZabbixをインストールしたOS、Zabbixプロセス、Zabbixインストールと同時にインストールされるMySQLの運用について考慮が必要で、運用工数がかかります。
  • APIはCloudWatchよりも機能が少ない
    ZabbixAPIも、普通のソフトウェアと比べると十分に機能が豊富なのですが、
    CloudWatchと比べてしまうとやはり機能が乏しいです。

CloudWatch

つぎは、CloudWatchのメリット、デメリットについてみていきます。

メリット

  • 豊富な機能
    今まで見てきた通り、Alarm、Event、Logsなど、豊富な機能がメリットです。
  • 高いカスタマイズ性
    ダッシュボードのカスタマイズ性は高く、監視したい対象や期間をすぐに選定することができます。
  • 初期費用、運用費用が不要
    SaaSのような形式で利用が可能であるため、初期費用や運用費用が不要です。
    したがって利用開始までのTCOを低く抑えることができます。

デメリット

  • 他のプラットフォームを監視する場合は追加コストがかかる
    例えばGCPを監視する場合は、GCPからAWSに監視のためのデータ通信が発生するので、
    GCP側で外部データ送信のコストがかかります。
  • 作りこみが必要な部分もある
    例えばメモリの使用率監視はデフォルトで利用できません。
    カスタムメトリクスとして多少の作りこみが発生してしまいます。

まとめ

CloudWatchは見てきた通り、豊富な機能を有しています。
この豊富な機能を使いこなして、有益なシステム監視を行いましょう。
また、CloudWatchEventやCloudWatch Alarmを駆使することで、
疎結合で保守性の高いシステムを設計することができます。
システムアーキテクチャの一部としても、ぜひ一考してみてください。

参考資料
https://aws.amazon.com/jp/cloudwatch/