この記事で分かること
本記事では、CloudWatchで検知したアラーム状態をSNSでユーザーに通知するための構成・構築手順を解説します。
- 構成の概要
- 登場するAWSサービスの役割
- 特徴
- 利用シーン
- 構築手順
構成解説
本記事では、EC2のメトリクスをCloudWatchで監視し、異常を検知した場合にSNSでユーザーにメール配信する構成を解説します。
上記構成について、以下の観点で解説します。
- 各AWSサービスの役割
- 本構成の特徴
- 本構成の利用シーン
各AWSサービスの役割
本構成では以下のAWSサービスを利用します。以降ではそれぞれの役割について解説します。
- EC2
- CloudWatch
- SNS
AWSサービス①：EC2
EC2はAWSが提供する仮想サーバーサービスで、クラウド上でスケーラブルなコンピューティングリソースを提供します。
ユーザーは必要に応じてインスタンス（仮想マシン）を起動、停止、スケールでき、様々なオペレーティングシステム（OS）やソフトウェアを自由に選んで利用できます。またEC2は、アプリケーションのホスティング、データ処理、機械学習、ウェブサーバーなど、幅広いユースケースに対応しています。
【本構成における役割】
実際にアプリケーションやサービスをホストするインスタンスとして、システムのパフォーマンスやヘルスを監視される対象となります。
AWSサービス②：CloudWatch
CloudWatchは、AWSクラウドリソースの監視および管理を行うサービスです。
システムのメトリクス（CPU使用率、ディスクI/O、ネットワークトラフィックなど）を収集し、ログデータを分析してパフォーマンスや可用性を監視します。またアラーム設定により、異常を検出した際に通知や自動的なアクションをトリガーすることができます。
【本構成における役割】
- まずAWSリソース（EC2）の監視を行い、指定した条件に基づいて異常を検知します。
- 異常を検知すると、CloudWatchアラームがトリガーされ、その結果としてAmazon SNS（Simple Notification Service）を使って通知を送信します。
- これにより、システム管理者や運用チームはリアルタイムで問題に気づき、迅速に対応できるようになります。
AWSサービス③：SNS
SNSはメッセージングサービスで、アプリケーション間やユーザーにリアルタイムで通知を送るために使用されます。
トピックという単位でメッセージを発行し、サブスクライバー（メールアドレス、SMS、HTTPエンドポイント、AWS Lambda関数など）に配信することができます。これにより、システムやアプリケーションからのアラートや情報を効率的に配信できます。
【本構成における役割】
CloudWatchアラームから発行されたメッセージを受け取り、それを定義されたサブスクライバーに送信します。
本構成の特徴
この構成の特徴は、
AWSの監視および通知の連携を利用した、迅速な障害対応と運用効率の向上
にあります。具体的には、以下のポイントが挙げられます。
- 迅速な障害検知
- 運用の効率化
- 高可用性
特徴①：迅速な障害検知
CloudWatchとSNSによる連携により、システムの異常がリアルタイムで検知され、即座にユーザーに通知されます。
これにより、問題が大きくなる前に迅速に対応でき、ダウンタイムの短縮やパフォーマンス低下のリスクを最小限に抑えることができます。特に、24時間体制で監視を行うことができるため、ユーザーは安心してシステムを運用できます。
特徴②：運用の効率化
本構成を採用しない場合は人手でEC2の状態を監視する必要があるため、異常を発見するには多くの時間とリソースが必要となります。
一方でこの構成では、CloudWatchがメトリクスを自動的に収集し、異常を自動で検出してSNSに通知を送るため、運用負担が大幅に軽減されます。
特徴③：高可用性
CloudWatchとSNSはスケーラブルなインフラにも対応しており、負荷の変動に関わらず常に効果的な監視と通知が行われます。これにより、急激なアクセス増加やリソース需要の変動にも柔軟に対応でき、コスト効率も向上します。
また、CloudWatchとSNSはどちらも冗長化されたAWSのサービスであるため、システム監視と通知機能が停止するリスクを最小限に抑える設計がされています。このため、ユーザーにとっては信頼性が高く、安定した運用を実現できるメリットがあります。
本構成の利用シーン
本構成は、一般的なシステムでも広く採用されている標準的な監視・アラート通知の構成です。
特に、リアルタイムでの異常検知と迅速な対応が求められるシステムにおいてその有用性は非常に高く、業界全体で広く採用されている構成です。この構成により、運用の効率化・高可用性・コスト効率・セキュリティ面での強化が実現され、システム管理者や運用チームはより安心してシステムを運営できます。
構築手順
本記事では、赤枠箇所を構築するための手順を解説します。
＜構築手順＞
- CloudWatchアラームの作成
- SNSトピックの作成
- SNSサブスクリプションの作成
構築手順①：SNSトピックの作成
SNSコンソール画面に遷移し、トピック＞トピックの作成の順に選択します。
以下のように設定して、トピックの作成を選択します。
＜設定内容＞
| 項目 | 設定値 |
|---|---|
| タイプ | スタンダード |
| 名前 | 任意の名前 |
| 表示名 | 任意の表示名 |
【SNSトピックの設定項目】
ここでは詳細な設定は割愛していますが、実際にSNSトピックを作成する際は各設定項目を理解しておくことをおすすめします。
以下記事で各設定項目を解説しているので、ご確認ください。
構築手順②：SNSサブスクリプションの作成
- 先ほど作成したSNSトピックを選択します。
サブスクリプションの作成を選択します。
以下のように設定してサブスクリプションの作成を選択します。
＜設定内容＞
| 項目 | 設定値 |
|---|---|
| プロトコル | Eメール |
| エンドポイント | ※通知先のメールアドレス |
【SNSサブスクリプションの設定項目】
ここでは詳細な設定は割愛していますが、実際にSNSサブスクリプションを作成する際は各設定項目を理解しておくことをおすすめします。
以下記事で各設定項目を解説しているので、ご確認ください。
SNSサブスクリプション作成時に設定したメールアドレス宛に検証メールが送信されるので、メール本文のConfirm subscriptionを選択します。
構築手順③：CloudWatchアラームの作成
CloudWatchのコンソール画面に遷移し、すべてのアラーム＞アラームの作成の順に選択します。
メトリクスの選択を選択します。
EC2＞インスタンス別メトリクスの順に選択し、任意のメトリクスを選択した後にメトリクスの選択を選択します。- 今回は「CPU使用率」を基にアラート通知を行うので、「CPUUtilization」を選択します。
- 以下のように設定して次へを選択します。
- ここでは、「CPU使用率が80%を超えたらアラートする」という設定を行っています。
- 用途に応じて設定値を置き換えてください。
| カテゴリ | 項目 | 設定値 |
|---|---|---|
| メトリクス | メトリクス名 | 任意のメトリクス名 |
| 統計 | 平均 | |
| 期間 | 5分 | |
| 条件 | 閾値の種類 | 静的 |
| アラームの条件 | より大きい | |
| 閾値 | 80% |
通知の追加を選択します。
- 以下のように設定して
次へを選択します。
| 項目 | 設定値 |
|---|---|
| アラーム状態トリガー | アラーム状態 |
| 次のSNSトピックに通知を送信 | 既存のSNSトピックを選択 |
| 通知の送信先 | ※作成したSNSトピックを選択 |
任意のアラーム名・説明を設定して、次へを選択します。
設定内容を確認してアラームの作成を選択します。
動作確認
実際にEC2のCPU使用率が閾値を超えた際に、アラート通知が送信されるかを確認します。
監視対象のEC2のCPU使用率は常時3%くらいなので、アラームの閾値を1%に設定変更してみます。
＜EC2のメトリクス（CPU使用率）＞
アラート通知
設定変更してから数分後にアラートメールを受信します。
メール本文には、アラーム名や内容が記載されます。
CloudWatchのコンソール画面
CloudWatchのコンソール画面でもアラーム状態であることが分かります。
関連記事
本記事の解説は以上です。
ここからは、より知識を深めたい人向けに関連記事を紹介します。
本記事で登場したAWSサービス
本記事では「EC2」や「CloudWatch」、「SNS」といったAWSサービスが登場しました。
これらのサービスについては、仕組みや設定項目等についてイラスト多めで図解しているので、もっとよく知りたい方は以下の記事をご覧ください。
コメント