Amazon CloudWatchについて語ってみた

はじめに

　今回はAmazon Cloud Watchについて記載しますが、その前に「オブザーバビリティ」についてお話しさせてください。

1. オブザーバビリティとは？

　クラウドネイティブなアプリケーションを目指す場合、さまざまなマネージサービスを組み合わせて利用することになりますよね？
　各種サービスを組み合わせた分散システムとしての規模が大きくなると、障害が発生した際の原因や影響範囲の特定が難しくなり、迅速な原因特定と復旧に努めなければなりません。こんな経験ありませんか？

「どこで何か起こっているのか、どうやって特定するのか？」

このような問題に対処するために登場したのが、オブザーバビリティと呼ばれる概念です。
オブザーバビリティとは？
「いつ、どこで、なにが起こっているのか、システムの状態を把握できる能力・状態」

　まさに5W1Hですね。ただ、これら３つを独立して利用するものではなく、組み合わせることでシステムの状態を理解するために役立ちます。この３つの要素は重要ですが、システムの状態から深い洞察を得るためには、ただデータを集めるだけでなく、収集結果の可視化や特定のクラウドサービスに対して洞察を得るためのしくみが求められます。

※ちなみに、AWSにおけるモニタリングとオブザーバビリティについての記載は、下記公式サイトを参考ください。
”モニタリングとオブザーバビリティ – AWS クラウドオペレーション”

　前述のとおり、扱うクラウドコンポーネントや開発したソフトが巨大になればなるほど、システム構成が複雑化し、迅速な内部状態の把握が困難になります。クラウドネイティブなシステムでは、開発アジリティを高めることを容易にする一方、システムの複雑化も加速しやすく、こういったモニタリングやオブザーバビリティの獲得がより重要になってきます。

そのオブザーバビリティをAWSで実現するサービスがAmazon CloudWatchです。
（他社製品には、DATADOGやsplunkなどあります）

※Amazon CloudWatchについての記載は、下記公式サイトを参考ください。
”Amazon CloudWatch”

2. 運用監視要件の定義

　それでは、上記オブザーバビリティの考え方を参考に、システム運用監視に関する要件を定義し、実際のシーンに合わせてCloudWatchを活用したリソース監視を行うための方針を記載してみます。

1. はじめに

　本ユースケースとして、収集したデータをAWS GlueでETL処理し、そのデータを開発したアプリや分析パッケージをEC2インスタンス上で稼働させて活用したデータ分析基盤を構築したとし、そのシステムの運用監視に関する要件を定義してみます。
※各サービスでCloudWatchを使用したイメージはこんな感じです

2. 監視対象

2.1 EC2 インスタンス

　- CPU 使用率、メモリ使用率、ディスク使用率、ネットワークトラフィック -

2.2 AWS Glue

　- ジョブの実行状況、データ処理遅延、ジョブのリソース使用率 -

3. 監視要件

3.1 EC2 インスタンス

　①CPU 使用率・・・過度な負荷をリアルタイムで検出すること
　②メモリ使用率・・・メモリリークをリアルタイムで特定すること
　③ディスク使用率・・・ディスク容量の不足をリアルタイムで検出すること
　④ネットワークトラフィック・・・トラフィックの増加や異常なアクティビティを検出すること

3.2 AWS Glue

　①ジョブの実行状況・・・ジョブの実行状況を監視し、ジョブが正常に実行されているか、エラーや異常終了が発生していないかを確認すること
　②データ処理遅延・・・ジョブデータ処理遅延を監視し、データ処理の問題を特定すること
　③ジョブのリソース使用率・・・ジョブのリソース使用率（CPU、メモリ、ネットワーク）を監視し、ジョブが適切なリソースを利用しているかを確認すること

3. 運用監視要件の対策＆手順

　要件が固まったということで、次に対策と手順について考えてみます。

1. EC2 インスタンス

1.1 対策と手順：

　CloudWatchエージェントをEC2インスタンスにインストールおよび設定をし、各種メトリクスを収集します。
　また、CloudWatchコンソールに移動し、EC2インスタンス用のCloudWatchアラームを作成します。アラームのトリガー条件（各種使用率が一定の閾値を超え）と通知先を設定します。

2. AWS Glue

2.1 ジョブの実行状況

　対策：
　　GlueジョブのログをCloudWatch Logsに送信します。
　　ジョブごとにCloudWatchアラームを設定して、ジョブの異常終了を検出し、通知を受けるように設定します。
　手順：
　　Glueジョブ設定でジョブのログ出力先をCloudWatch Logsに設定します。
　　CloudWatchコンソールに移動し、Glueジョブ用のアラームを作成します。アラームのトリガー条件と通知先を設定します。

2.2 データ処理遅延

　対策：
　　Glueジョブのログデータを分析してデータ処理の遅延を監視します。
　　ジョブごとにCloudWatchアラームを設定して、処理時間が一定の閾値を超えた場合に通知を受けるように設定します。
　手順：
　　GlueジョブのログデータをCloudWatch Logsから取得し、データ処理の遅延を監視および分析します。
　　CloudWatchコンソールに移動し、ジョブ用のアラームを作成します。アラームのトリガー条件と通知先を設定します。

2.3 ジョブのリソース使用率

　対策：
　　Glueジョブのリソース使用率メトリクスをCloudWatchで監視し、必要に応じてジョブのリソースを調整します。
　　ジョブごとにCloudWatchアラームを設定して、リソース使用率が設定された閾値を超えた場合に通知を受けるように設定します。
　手順：
　　Glueジョブのリソース使用率メトリクスをCloudWatchで監視します。
　　CloudWatchコンソールに移動し、ジョブ用のアラームを作成します。アラームのトリガー条件と通知先を設定します。

4. ところでCloudWatch Logsって何？

　上記にも記載した通り、CloudWatch Logsを使用することで、ログデータの収集、監視、アラート設定、分析を効果的に行うことができます。ログデータを活用してシステムのトラブルシューティングやパフォーマンスの最適化を行うために、CloudWatch Logsの設定と管理が重要です。

1. CloudWatch Logs に保存可能なログの種類

CloudWatch Logsに保存可能なログとしては主に次の通りです
①アプリケーションログ
②AWSサービスログ

2. CloudWatch Logs の構成要素

①ログイベント
　各アプリケーションやAWSサービスによって出力されたログ内容です。レコード単位で記録され、タイムスタンプとログメッセージで構成されます。
②ログストリーム
　EC2インスタンスやECSタスクなど、同じソースから出力された複数のログインイベントを束ねたものです。
③ロググループ
　複数のログストリームをまとめたものです。多くのケースではアプリケーションや各AWSサービスの定義単位でグルーピングされます。
※図にするとこんな感じです

3. ロググループの一般的なまとめ方

ロググループは一般的にアプリケーションやコンポーネントごとにまとめられます。
①EC2インスタンスの場合
　インスタンス毎に個別のロググループを作成
②Glueジョブの場合
　ジョブ毎に個別のロググループを作成

4. EC2やGlueでの使用

4.1 EC2の場合

　インスタンスからのログデータは、CloudWatch Logsエージェントをインストールし、設定ファイルでロググループとログストリームを指定して送信します。
出力手順）
　(1) IAMロールの作成
　　EC2インスタンスがCloudWatch Logsにログデータを送信できるように、ログデータを送信するためのIAMロールを作成します。このロールにはCloudWatchAgentServerPolicyポリシーが必要です。
　(2) IAMロールを割り当て
　　EC2インスタンスを起動する際、上記で作成したIAMロールを割り当てます。これにより、EC2インスタンスはCloudWatch Logsへのアクセス権を持つことができます。
　(3) CloudWatch Logs エージェントのインストール
　　①まずは、CloudWatch Logs エージェントダウンロード

wget https://s3.ap-northeast-1.amazonaws.com/amazoncloudwatch-agent-ap-northeast-1/centos/amd64/latest/amazon-cloudwatch-agent.rpm

　　　②ダウンロードしたら、CloudWatch Logs エージェントをインストール

rpm -U ./amazon-cloudwatch-agent.rpm

　　　③CloudWatch Logs エージェントのインストール確認

yum list installed | grep amazon-cloudwatch-agent

　(4) CloudWatch Logs エージェントの設定
　　ウィザードを使用して、CloudWatch Logs エージェントの設定ファイルを編集します。

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

　　※設定ファイルは /opt/aws/amazon-cloudwatch-agent/bin/config.json に保存されます
　(5) CloudWatch Logs エージェントの起動
　エージェントを起動します。
　　以下のコマンドで CloudWatch エージェントが EC2 インスタンスから AWS リージョンを自動的に検出し、指定された構成ファイルを使用して開始されます。
　エージェントのステータスを確認します。

systemctl status amazon-cloudwatch-agent

　自動起動の有効を確認します。

systemctl is-enabled amazon-cloudwatch-agent

　(6) ログデータの確認:
　　CloudWatch Logsコンソールに移動し、指定したロググループ内でログデータが正常に収集されていることを確認します。

※結構面倒ですよね　でも、所用時間として10分くらいだったかな

4.2 AWS Glueジョブの場合

　ジョブ設定でロググループを指定し、ログデータをCloudWatch Logsに送信できます。
　AWS Glueのログ収集をAWS CloudWatch Logsを使用して行う手順は以下の通りです。
出力手順）
　(1) AWS Glueジョブの設定
　　AWS Glueコンソールにログインし、ジョブを選択または新しいジョブを作成します。
　(2) ログ出力先
　　ログ出力のための設定は特に不要。

EC2とは違い、特に何もしなくていいから楽
※ちなみに、CloudWatch Logs のロググループは以下の通りです

項目	ログ種別	ロググループ
Job / PySpark - Glue1.0	標準出力	/aws-glue/jobs/output
	エラー出力	/aws-glue/jobs/error
Job / PySpark - Glue2.0		/aws-glue/jobs/logs-v2
Job / Python shel	標準出力	/aws-glue/python-jobs/output
	エラー出力	/aws-glue/python-jobs/error
クローラ		/aws-glue/crawlers
テスト接続		/aws-glue/testconnection

以上、こんな感じで語ってみましたが、参考になれば幸いです。