はじめに
AWSリソースを利用するにあたり、ログ収集や監視はどのように行うでしょうかシステムの予期せぬ障害やパフォーマンスの低下に備えるためには、これらの作業が不可欠です。
また、システムを安定的に運用・提供するためには、リソースがどのように動いているのかを常に把握する必要があります。これには、開発者、運用担当者、ビジネスユーザーなど、さまざまな立場からの要求があります。
今回はそんな時に使えるAWSサービスの一つである、CloudWatchについてお話してきます。CloudWatchって色々複雑でよくわかんないよね、と思った私より、業務でこんなことやりたいを実現した運用も含め、学んだことを記載していければと思います。
Observabilityとは
Observabilityという言葉をみなさん聞いたことがありますでしょうか。（一年前ほど前AWS研修で学び、社内向けには展開したこともありました。）
オブザーバビリティとは可観測性を意味します。システムで何がなぜ起こっているかといった動作状況を把握できている状態を指します。特にサーバーレスの分散性により、このオブザーバビリティの重要度が高まっています。この可観測性が高まることにより、早期検出・調査・対応による、可用性や信頼性の向上が見込めます。
参考：AWS Black Belt ~AWS の Observability（可観測性）の全体像~
CloudWatchってなに
さて、このAWSにおけるオブザーブビリティを実現するための、CloudWatchとはどのようなものでしょうか。CloudWatchはアプリケーションを監視し、リアルタイムでログやメトリクスを収集、可視化するツールです。つまりAWSでオブザーバビリティを実現するためにCloudWatchが必要、ということです。
またCloudWatchにはたくさんの機能があります。オブザーブビリティを実現するために利用されるCloudWatchの機能を表にしてみます。
| 機能 | AWSサービス名 | 概要 | 利用方法 |
|---|---|---|---|
| Alarm | CloudWatch Alarm | アラーム | メトリクスに応じたアクション起動 |
| Logs | CloudWatch Log | ログ保管 | AWSリソースから出力されたログ |
| Logs | CloudWatch Logs Insights | ログ分析 | ログの可視化 |
| Metrics | CloudWatch Metrics | メトリクス | AWSリソース状態を監視 |
| Metrics | CloudWatch Metrics Explorer | メトリクス検索 | タグベースでのAWSリソース状態を監視 |
| Metrics | CloudWatch Metrics Stream | 連続リアルタイムなメトリクス | Kinesis分析用抽出 |
| Metrics | CloudWatch Metrics Insights | メトリクス分析 | メトリクスの可視化 |
| Traces | x-Ray (Cloudwatchに統合) | トレース | サービス間の通信や情報を追跡 |
| Events | CloudWatch Events(Event Bridgeに統合) | イベント | AWSリソースへイベントに応じた処理起動 |
| Application Signals | CloudWatch ServiceLens | 分散情報の集約化 | 完全マネージド型可観測性ソリューション |
| Monitor | CloudWatch Internet Monitor | インターネット監視 | 世界中のインターネット下での問題を可視化 |
| Insights | CloudWatch Container Insights | コンテナ分析 | コンテナ特化で、タスクやコンテナレベルでの監視・分析 |
| Insights | CloudWatch Lambda Insights | Lambda分析 | Lambda関数特化で、監視・分析 |
| Insights | CloudWatch Contributor Insights | 高カーディナリティデータ分析 | ログからルールに基づく収集・分析 |
| Insights | CloudWatch Application Insights | アプリケーション監視 | アプリケーションのリソース全体へ監視・分析 |
などなど。。
(自分自身も全ての機能を利用しているわけではないので、認識違いがあれば申し訳ないです。)
こんなにもいっぱい機能があるのか、、となりますね。そんな中から抜粋し機能説明していきます。
参照：
AWS公式
[Youtube]AWS Black Belt ~Amazon CloudWatchの概要と基本~
[投影資料]AWS Black Belt ~Amazon CloudWatchの概要と基本~
料金価格
CloudWatchの利用について、初期費用や最低利用料金はかかりません。支払いは従量課金制となっています。
利用機能、リージョンによって金額が変化しますので、 詳細は以下をご覧ください。もちろん無料枠もありますので、実際の動きがみたい！とかなら利用してみるのもありですね。
色々な機能があるCloudWatchより、軸となるCloudWatch LogsとCloudWatch Metricsを紹介します。
CloudWatch Logs
CloudWatch LogsはAWSリソースに対し、どのようなイベントが起こっているかを示しているログデータを収集・管理・保存しているサービスです。
ログデータはロググループに集約され、各ロググループには複数のログストリームが存在し、その中にログイベントが保存されています。ログは上記表示のようにタイムスタンプとメッセージから成り立ちます。
CloudWatch Logsにログ出力可能なAWSサービスは以下を参照ください。
参考：CloudWatch Logsを発行するAWSサービス
CloudWatch Logs Insights
CloudWatch Logsで収集したログデータを検索・分析を行います。
検索には専用のクエリ言語を利用します。指定したロググループ（最大50まで）内にて条件を満たしたログデータが検索できます。
検索期間は画面上でもクエリに含めてもどちらでも指定可能です。
例えば
「ログに”ERROR”という文字列が存在する上位20件のログを検索する」
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
他にも
「ログに”systemId:123456”を含む上位20件のログを検索する」
fields @timestamp, @message
| filter @message like /systemId:123456/
| sort @timestamp desc
| limit 20
などなど色々なパターンでの検索が可能です。たくさんのログが収集されているロググループより、期間やワードを絞り、確認したいログを探すことができます。
より詳細なクエリ構文は以下を参照ください。
参照：CloudWatch Logs Insights クエリ構文
CloudWatch メトリクス
メトリクスとはAWSリソースの利用状況や内部状態などシステムのパフォーマンス状態を計測、収集されたデータを指します。具体的な観測値は、CPUやメモリの使用率などです。
上記のように期間や統計方法をカスタマイズしながら視覚的にパフォーマンス状態を把握可能です。
AWSのサービスを使用し始めると、基本モニターリングが自動的に有効になり、無料でモニタリングが可能です。
CloudWatch メトリクスを出力可能なAWSサービスは以下を参照ください。
参考：CloudWatch メトリクスを発行するAWSサービス
CloudWatch 運用 通知編
上記より、AWSリソースに対してたくさんの監視ができたり、ログ出力されることがわかりました。しかし皆さんいろんなお仕事に追われる身、全てのログを見る時間なんてありませんし、その中から欲しいログを探す時間もありません。そこで、収集したログからエラーを検知し、SNSを通じてメール通知を行います。
構成図としては以下
CloudWatchのサブスクリプションを利用します。サブスクリプションは、CloudWatch Logsに出力されたログデータから特定の文字列（ERRORなど）を含むデータなどをリアルタイムに検知し、Lamdba関数やKinesisへ送信することが可能です。
上記構成図ではCloudWatch サブスクリプションよりCloudWatch Logsの特定文字を含むログをLambda関数へ送信。Lamdba関数内でSNSメール文を作成し、SNSサブスクリプションにて登録したEメールアドレスへ送信します。
具体的なハンズオンは今回省略させていただきます（調べればたくさんでてくるので。）仕組みは以下をご参照ください。
参考：CloudWatch Logs を文字列検知してログ内容をメールを送信してみた
CloudWatchのサブスクリプションについて
CloudWatch 運用 コスト編
Cloudwatch Logsには常にログが出力されます。このLogは期限をきちんと設定しないと、デフォルトで無期限に保存、蓄積されます。
これを放置しておくと、蓄積された分だけのコスト請求がされるため、次第にコストが嵩む要因の1つになります。
CloudWatch Logsのコスト削減していく方法は何個かありますが、今回はS3バケットへログを移行することでコスト削減していきます。
S3はAWSのバケット機能で、CloudWatch Logsよりも蓄積コストが低いです。そのため長期ログ保管が必要の場合はそちらへはログ保管することが可能です。
他にもログを他システムに取り込み分析するためにS3へ保存したい！という場合でも同様の仕組みを利用可能です。
構成図としては以下
EventBridgeで設定した定期的スケジュール（毎日12時実行や毎月1日実行など）をトリガーにCloudWatch Logsより、エクスポートタスクを実行し、S3バケットへ格納します。
例えば、EventBridgeが2週間ごとで起動し、ログをS3へ移行。CloudWatch Logsの保存期間を2週間、S3ライフサイクルルールにてログ最大保管期間で自動削除するように設定をすれば、不要となったログが自動で削除される仕組みができます。
こちらも具体的なハンズオンは記載しませんので、仕組みは以下をご参照ください。
参考：CloudWatch LogsをS3にエクスポートしてみた
まとめ
今回はCloudWatchについて詳しく調べてみました。調べてみた！といっても、これもまだ序の口。全ての機能を使いこなせているわけでもなく、CloudWatchでできることってたくさんあるなととても感じた学習でした。しかしログ監視は開発において切っても切れない大事な機能なので、必要に応じたリソース把握ができるようにしましょう！
引き続きAWSについて勉強・発信していきますので、よろしくお願いします〜