458-AWS SAP AWS 「理論・実践・一問道場」Amazon CloudWatch

type

status

date

slug

summary

理論

1. CloudWatch Logs メトリックフィルター

目的: CloudWatch Logsに保存されているログデータから、特定のパターンを抽出してメトリックを作成する。

利点: アプリケーションのコード変更を最小限に抑え、既存のログを活用して運用データをメトリック化できます。

使用シーン: ログインやエラーイベントなど、アプリケーションで発生した重要なアクションをメトリックとして監視する場合。

2. カスタムメトリックの作成

目的: アプリケーションやシステムの動作を詳細に追跡するために、ユーザー定義のメトリックを作成する。

方法: AWS SDKやAWS Lambdaを使用してメトリックをカスタムで記録する方法がありますが、アプリケーションコードの変更やLambda関数の設定が必要です。

3. AWS Lambda の使用

目的: 自動化された処理を行うために、ログのストリームを消費して処理を行い、結果をメトリックとして記録する。

利点: スケーラブルで自動化された処理を実現できますが、設定に手間がかかる場合があります。

4. CloudWatchのディメンション

目的: メトリックをさらに細かく分類するために、ディメンションを設定して特定の属性（ユーザー名、クライアント名など）を追跡します。

使用例: ログインの成功数をユーザーやクライアント別に分類して、パフォーマンス指標として使用する。

これらの知識を活用することで、CloudWatch Logsを効果的に利用し、アプリケーションのパフォーマンスやユーザーアクションを監視することができます。

実践

略

一問道場

企業は、ユーザー別ライセンススキーマへの移行戦略の一環として、アプリケーションからの主要業績評価指標（KPI）を記録したいと考えています。アプリケーションは、WebベースのUIを持つマルチティアアプリケーションです。企業は、CloudWatchエージェントを使用してすべてのログファイルをAmazon CloudWatchに保存しています。アプリケーションへのログインはすべてログファイルに保存されています。

新しいライセンススキーマの一環として、企業は毎日、毎週、毎月ごとのユニークなユーザー数を把握する必要があります。

どのソリューションがアプリケーションへの変更を最小限に抑えた状態でこの情報を提供できますか？

A. Amazon CloudWatch Logsのメトリックフィルターを設定し、各成功したログインをメトリックとして保存します。ユーザー名とクライアント名をメトリックのディメンションとして設定します。

B. アプリケーションロジックを変更して、各成功したログインがAWS SDKを呼び出し、ユーザー名とクライアント名のディメンションを含むカスタムメトリックをインクリメントするようにします。

C. CloudWatchエージェントを設定して、ログから成功したログインメトリックを抽出します。さらに、CloudWatchエージェントを設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックとして成功したログインメトリックを保存します。

D. AWS Lambda関数を設定して、アプリケーションログのAmazon CloudWatch Logsストリームを消費します。さらに、Lambda関数を設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックをCloudWatchでインクリメントします。

解説

この問題では、アプリケーションのログイン情報を元にユニークなユーザー数を計測し、それをAmazon CloudWatchでメトリックとして記録する方法を求めています。最小限のアプリケーション変更でこの要件を満たす方法を選ぶ必要があります。

各選択肢の解説：

A. Amazon CloudWatch Logsのメトリックフィルターを設定し、各成功したログインをメトリックとして保存します。ユーザー名とクライアント名をメトリックのディメンションとして設定します。

メリット: この方法はアプリケーションの変更を最小限に抑えつつ、CloudWatch Logsを活用してメトリックを抽出できます。ログインに関する情報はすでにCloudWatchに保存されているため、ログの内容に基づいてメトリックフィルターを設定することで、ユーザーごとの成功ログイン回数を簡単に計測できます。

最適な選択肢: 変更はログに基づいたメトリック設定のみで、アプリケーションコードに対する変更はほとんど必要ありません。

B. アプリケーションロジックを変更して、各成功したログインがAWS SDKを呼び出し、ユーザー名とクライアント名のディメンションを含むカスタムメトリックをインクリメントするようにします。

デメリット: アプリケーションのロジックを変更してAWS SDKを呼び出す必要があり、これは大きな変更になります。特に既存のアプリケーションに対して、メトリックのインクリメントを直接アプリケーションコードに組み込むのは手間がかかり、エラーの可能性も増えます。

C. CloudWatchエージェントを設定して、ログから成功したログインメトリックを抽出します。さらに、CloudWatchエージェントを設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックとして成功したログインメトリックを保存します。

デメリット: CloudWatchエージェントを設定してメトリックを抽出するのは可能ですが、エージェントで直接ログからメトリックを抽出してカスタムメトリックを生成するのは少し複雑です。さらに、CloudWatchエージェントを設定するには多少の手間がかかります。

D. AWS Lambda関数を設定して、アプリケーションログのAmazon CloudWatch Logsストリームを消費します。さらに、Lambda関数を設定して、ユーザー名とクライアント名をディメンションとして使用するカスタムメトリックをCloudWatchでインクリメントします。

デメリット: Lambda関数を設定することで処理を自動化できますが、これも設定や維持に一定のコストと手間がかかります。Lambda関数を利用する場合、ストリームからデータを処理してメトリックをインクリメントするため、特にスケーラビリティが求められる場合に適していますが、最小限の変更で対応する目的には少し過剰かもしれません。