助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30324
問題を開く
ELB配下に複数のEC2インスタンスがWebアプリケーションとして稼働している。アプリケーションの利用状況を監視するため、リクエスト数やリクエストの応答時間がしきい値を超えたら管理者宛にメールで通知されるようにしたい。
要件を満たすために最適のアプローチはどれか。
要件を満たすために最適のアプローチはどれか。
正解
Amazon CloudWatchで必要なメトリクスを監視対象に設定し、メール通知されるよう設定する
解説
Amazon CloudWatchは、AWSサービスやオンプレミス(自社運用)のシステムを監視し、運用を支援するサービスです。ある一定の値を超える・下回るなどした場合に管理者に通報するなど、サービスのリソース(CPU使用率やストレージの使用状況など)の状態に応じたアクションを取らせることができます。
CloudWatchが監視する様々なリソースの情報は「メトリクス」と呼ばれます。インスタンスのCPU使用率やディスクの使用状況(読み取り・書き込みの量)など、予め定義されているメトリクスを標準メトリクスと呼びます。標準メトリクスはサービスごとに提供されています。
例)
【EC2】CPU使用率、ディスクの読み取り・書き込み量
【ELB】リクエスト数、リクエストの応答時間
設問のケースではアプリケーションが受けるリクエスト数とリクエストの応答時間が監視対象になります。リクエスト数とリクエストの応答時間は、それぞれELBのメトリクスRequestCountとLatencyに対応しています。
CloudWatchのメトリクスとしてRequestCountとLatencyを監視対象に加え、それぞれにしきい値を定義しメール通知の設定を行うことで、設問の要件を満たすことができます。
以上より正解は
・Amazon CloudWatchで必要なメトリクスを監視対象に設定し、メール通知されるよう設定する
です。
実際の設定画面は以下の通りです。
その他の選択肢については以下の通りです。
・Amazon CloudWatch Logs Insightsでアプリケーションのログを解析し、メール通知の設定を行う
CloudWatch Logs Insightsはログの解析を行うサービスです。設問の要件はログの解析を必要としないため、CloudWatch Logs Insightsは適していません。
・EC2インスタンスへCloudWatchエージェントをインストールする
CloudWatchエージェントは、EC2インスタンスのログやカスタムメトリクスを収集する場合にインストールします。
リクエスト数やリクエストの応答時間はELBの標準メトリクスで収集できます。CloudWatchエージェントをインストールする必要はないため誤りです。
・EC2インスタンスのダッシュボードからインスタンスの詳細情報を監視する
EC2インスタンスのダッシュボードを参照してもアプリケーションが何件リクエストを受け取ったかはわかりませんので誤りです。
CloudWatchが監視する様々なリソースの情報は「メトリクス」と呼ばれます。インスタンスのCPU使用率やディスクの使用状況(読み取り・書き込みの量)など、予め定義されているメトリクスを標準メトリクスと呼びます。標準メトリクスはサービスごとに提供されています。
例)
【EC2】CPU使用率、ディスクの読み取り・書き込み量
【ELB】リクエスト数、リクエストの応答時間
設問のケースではアプリケーションが受けるリクエスト数とリクエストの応答時間が監視対象になります。リクエスト数とリクエストの応答時間は、それぞれELBのメトリクスRequestCountとLatencyに対応しています。
CloudWatchのメトリクスとしてRequestCountとLatencyを監視対象に加え、それぞれにしきい値を定義しメール通知の設定を行うことで、設問の要件を満たすことができます。
以上より正解は
・Amazon CloudWatchで必要なメトリクスを監視対象に設定し、メール通知されるよう設定する
です。
実際の設定画面は以下の通りです。
その他の選択肢については以下の通りです。
・Amazon CloudWatch Logs Insightsでアプリケーションのログを解析し、メール通知の設定を行う
CloudWatch Logs Insightsはログの解析を行うサービスです。設問の要件はログの解析を必要としないため、CloudWatch Logs Insightsは適していません。
・EC2インスタンスへCloudWatchエージェントをインストールする
CloudWatchエージェントは、EC2インスタンスのログやカスタムメトリクスを収集する場合にインストールします。
リクエスト数やリクエストの応答時間はELBの標準メトリクスで収集できます。CloudWatchエージェントをインストールする必要はないため誤りです。
・EC2インスタンスのダッシュボードからインスタンスの詳細情報を監視する
EC2インスタンスのダッシュボードを参照してもアプリケーションが何件リクエストを受け取ったかはわかりませんので誤りです。
参考
【Amazon CloudWatch】
サービスを継続して運用するために、管理者はストレージがすべて使い切られる前に余剰を確保しておいたり、負荷が高くなり機能不全に陥る前に追加のリソースを用意したりと、状況に応じた適切な処置を行う必要があります。
Amazon CloudWatchは、AWSサービスやオンプレミス(自社運用)のシステムを監視し、しきい値(境界値)を超える・下回るなどした場合に管理者に通報するなど、サービスのリソース(CPU使用率やストレージの使用状況など)の状態に応じたアクションを取らせることができます。管理者はCloudWatchを利用することにより、サービスの安定した運用やパフォーマンスの向上、サービスの改善に役立てることができます。
[CloudWatchのイメージ図]
CloudWatchには、大きく分けて、「メトリクスの収集・監視」「アラームとアクション」「ログの収集・分析」の3つの機能があります。
■メトリクスの収集・監視
CloudWatchが監視する様々なリソースの情報は「メトリクス」と呼ばれます。インスタンスのCPU使用率やディスクの読み取り・書き込みの量など、予め定義されているメトリクスを標準メトリクスと呼びます。標準メトリクスはサービスごとに提供されており、CloudWatchのダッシュボードから確認することができます。
[CloudWatchのダッシュボード]
以下は標準メトリクスとして監視可能な項目の例です。
【EC2】CPU使用率、ディスクの読み取り・書き込み量
【S3】バケットサイズ、ファイル(オブジェクト)数
【ELB】リクエスト数、リクエストの応答時間
【RDS】ストレージの空き容量、秒間の読み取り・書き込み操作の量
標準メトリクスでカバーされない項目、例えばメモリ使用量やディスクの空き容量などは、管理者が「カスタムメトリクス」として定義し、CloudWatchエージェントをインストールしたEC2インスタンスからAWS CLIコマンドやAPIを用いてCloudWatchへ送信することで監視できます。
以下はEC2インスタンスの代表的な監視項目です。
■アラームとアクション
CloudWatchでは、設定したメトリクスに基づいてアラームを設定し、条件を満たした際に特定のアクションを自動的に実行することができます。例えば、EC2インスタンスのCPU使用率が80%を超えた場合、管理者宛にメール通知するというアクションを設定できます。この通知機能は、Amazon Simple Notification Service (SNS)と連携して実現されます。また、インスタンスの自動再起動や停止、終了など、さまざまなアクションを設定することが可能です。
EC2インスタンスについては、メール通知だけではなく、インスタンスの再起動・停止・終了・復旧というアクションも用意されています。例えば、必要な処理が完了したらインスタンスを停止・終了することでコストを削減できます。また、復旧アクションを選択すると、ハードウェア異常が発生した際に自動的に新たなインスタンスで復旧します。
〇複合アラーム
複数のメトリクスがしきい値を超えたときに通知を出したい場合は「複合アラーム」を作成します。例えば「CPU使用率が80%を超えたとき」に通知するアラームと、「受信ネットワークトラフィック量が60MB/分を超えたとき」に通知するアラームが両方アラーム状態になった場合に、複合アラームを通知するという設定ができます。複合アラームを使用してアラームの通知条件を厳密にすることで、対応不要な通知を減らす効果が期待できます。
■ログの収集・分析
CloudWatch Logsは、AWSサービスやEC2インスタンスのOSやアプリケーションのログを収集し、一元管理するサービスです。例えば、CloudTrailにおけるAWSサービスの操作ログや、VPCフローログなどを収集できます。収集したログは、メッセージの内容をフィルタリングして管理者に通知させることができます。(例:EC2インスタンスのOSログで"Error"の文字列を1時間に5回検出した場合、管理者へメール通知する)
なお、EC2インスタンス上のアプリケーションやOSのログを収集するには、対象のEC2インスタンスへ「CloudWatchエージェント」をインストールする必要があります。
さらに、フィルタリングしたログをAmazon Data FirehoseやAWS Lambda、Amazon OpenSearch Serviceなどの別のサービスへ転送し、ログをリアルタイムに解析したり、ログの内容に応じてプログラムを実行させる、といった連携も可能です。
別のサービスへ転送するには、CloudWatch Logsのサブスクリプションフィルターで、データの転送先を設定します。
〇CloudWatch Logs Insights
CloudWatch Logsで収集したログのインタラクティブな検索や分析を行うことができます。CloudWatch Logsの管理コンソールでは単語検索によるフィルタリングを行えますが、CloudWatch Logs Insightsではクエリの実行にも対応しており、例えば「特定のアプリケーションが一定期間に出力した"Error"を含むメッセージをカウントする」など柔軟なログ解析が可能です。
【CloudWatchダッシュボードの共有】
CloudWatchのダッシュボードは「ダッシュボードの共有」機能を使用することで、AWSアカウントを持たない相手と共有することが可能です。これにより、新規にAWSアカウントやIAMユーザーを作成することなく、共有先のEメールアドレスを指定して、普段AWSを利用していないメンバーや社外の関係者とダッシュボード上の情報を簡単に共有することができます。
「ダッシュボードの共有」機能を使用した場合、共有を受けたメンバーにはそのダッシュボードの情報を参照するために必要な最小限の権限のみが自動的に付与されます。CloudWatchダッシュボード以外のリソース(ログやアラームの定義など)に対するアクセス権限は付与されないため、最小権限の原則に則った安全な共有を実現することができます。
【Amazon CloudWatch Container Insights】
Amazon CloudWatch Container Insightsは、コンテナ環境のメトリクスやログデータを収集するサービスです。Amazon ECS、Amazon EKS、Amazon EC2上のKubernetesで管理されているコンテナに対して、メトリクスやログデータを自動的に収集します。Container Insightsが収集したデータを元に、CloudWatchでアラームを出すこともできます。
ECSでContainer Insightsを使用にするには、クラスターの作成画面で「Container Insightsの使用」を有効にする他、既存のクラスターも設定変更で有効にできます。
サービスを継続して運用するために、管理者はストレージがすべて使い切られる前に余剰を確保しておいたり、負荷が高くなり機能不全に陥る前に追加のリソースを用意したりと、状況に応じた適切な処置を行う必要があります。
Amazon CloudWatchは、AWSサービスやオンプレミス(自社運用)のシステムを監視し、しきい値(境界値)を超える・下回るなどした場合に管理者に通報するなど、サービスのリソース(CPU使用率やストレージの使用状況など)の状態に応じたアクションを取らせることができます。管理者はCloudWatchを利用することにより、サービスの安定した運用やパフォーマンスの向上、サービスの改善に役立てることができます。
[CloudWatchのイメージ図]
CloudWatchには、大きく分けて、「メトリクスの収集・監視」「アラームとアクション」「ログの収集・分析」の3つの機能があります。
■メトリクスの収集・監視
CloudWatchが監視する様々なリソースの情報は「メトリクス」と呼ばれます。インスタンスのCPU使用率やディスクの読み取り・書き込みの量など、予め定義されているメトリクスを標準メトリクスと呼びます。標準メトリクスはサービスごとに提供されており、CloudWatchのダッシュボードから確認することができます。
[CloudWatchのダッシュボード]
以下は標準メトリクスとして監視可能な項目の例です。
【EC2】CPU使用率、ディスクの読み取り・書き込み量
【S3】バケットサイズ、ファイル(オブジェクト)数
【ELB】リクエスト数、リクエストの応答時間
【RDS】ストレージの空き容量、秒間の読み取り・書き込み操作の量
標準メトリクスでカバーされない項目、例えばメモリ使用量やディスクの空き容量などは、管理者が「カスタムメトリクス」として定義し、CloudWatchエージェントをインストールしたEC2インスタンスからAWS CLIコマンドやAPIを用いてCloudWatchへ送信することで監視できます。
以下はEC2インスタンスの代表的な監視項目です。
■アラームとアクション
CloudWatchでは、設定したメトリクスに基づいてアラームを設定し、条件を満たした際に特定のアクションを自動的に実行することができます。例えば、EC2インスタンスのCPU使用率が80%を超えた場合、管理者宛にメール通知するというアクションを設定できます。この通知機能は、Amazon Simple Notification Service (SNS)と連携して実現されます。また、インスタンスの自動再起動や停止、終了など、さまざまなアクションを設定することが可能です。
EC2インスタンスについては、メール通知だけではなく、インスタンスの再起動・停止・終了・復旧というアクションも用意されています。例えば、必要な処理が完了したらインスタンスを停止・終了することでコストを削減できます。また、復旧アクションを選択すると、ハードウェア異常が発生した際に自動的に新たなインスタンスで復旧します。
〇複合アラーム
複数のメトリクスがしきい値を超えたときに通知を出したい場合は「複合アラーム」を作成します。例えば「CPU使用率が80%を超えたとき」に通知するアラームと、「受信ネットワークトラフィック量が60MB/分を超えたとき」に通知するアラームが両方アラーム状態になった場合に、複合アラームを通知するという設定ができます。複合アラームを使用してアラームの通知条件を厳密にすることで、対応不要な通知を減らす効果が期待できます。
■ログの収集・分析
CloudWatch Logsは、AWSサービスやEC2インスタンスのOSやアプリケーションのログを収集し、一元管理するサービスです。例えば、CloudTrailにおけるAWSサービスの操作ログや、VPCフローログなどを収集できます。収集したログは、メッセージの内容をフィルタリングして管理者に通知させることができます。(例:EC2インスタンスのOSログで"Error"の文字列を1時間に5回検出した場合、管理者へメール通知する)
なお、EC2インスタンス上のアプリケーションやOSのログを収集するには、対象のEC2インスタンスへ「CloudWatchエージェント」をインストールする必要があります。
さらに、フィルタリングしたログをAmazon Data FirehoseやAWS Lambda、Amazon OpenSearch Serviceなどの別のサービスへ転送し、ログをリアルタイムに解析したり、ログの内容に応じてプログラムを実行させる、といった連携も可能です。
別のサービスへ転送するには、CloudWatch Logsのサブスクリプションフィルターで、データの転送先を設定します。
〇CloudWatch Logs Insights
CloudWatch Logsで収集したログのインタラクティブな検索や分析を行うことができます。CloudWatch Logsの管理コンソールでは単語検索によるフィルタリングを行えますが、CloudWatch Logs Insightsではクエリの実行にも対応しており、例えば「特定のアプリケーションが一定期間に出力した"Error"を含むメッセージをカウントする」など柔軟なログ解析が可能です。
【CloudWatchダッシュボードの共有】
CloudWatchのダッシュボードは「ダッシュボードの共有」機能を使用することで、AWSアカウントを持たない相手と共有することが可能です。これにより、新規にAWSアカウントやIAMユーザーを作成することなく、共有先のEメールアドレスを指定して、普段AWSを利用していないメンバーや社外の関係者とダッシュボード上の情報を簡単に共有することができます。
「ダッシュボードの共有」機能を使用した場合、共有を受けたメンバーにはそのダッシュボードの情報を参照するために必要な最小限の権限のみが自動的に付与されます。CloudWatchダッシュボード以外のリソース(ログやアラームの定義など)に対するアクセス権限は付与されないため、最小権限の原則に則った安全な共有を実現することができます。
【Amazon CloudWatch Container Insights】
Amazon CloudWatch Container Insightsは、コンテナ環境のメトリクスやログデータを収集するサービスです。Amazon ECS、Amazon EKS、Amazon EC2上のKubernetesで管理されているコンテナに対して、メトリクスやログデータを自動的に収集します。Container Insightsが収集したデータを元に、CloudWatchでアラームを出すこともできます。
ECSでContainer Insightsを使用にするには、クラスターの作成画面で「Container Insightsの使用」を有効にする他、既存のクラスターも設定変更で有効にできます。
ELBを利用している旨を問題文に明記
投稿日 2022/12/14
こちらELBのメトリクスであるRequestCountとLatencyを使って監視するのが正解となっていますが、問題文からはELB配下で動作していることが読み取れなかったので明記したほうが良いかと感じました。
スタッフからの返信
この投稿に対して返信しませんか?
s staff_satomi
2022/12/14 11:17
nanasi2424様 ご指摘の点を修正いたしました。 ご報告下さり、誠にありがとうございます。