背景
監視はシステム運用において必須です。
監視は「システム上の異常を検知し通知する」という目的があり、それを達成するためにはシステムから以下 ３ つのデータを収集し通知する仕組みが必要です。
- メトリクス(CPU使用率などの数値データ)
- ログ
- トレース(処理の繋がり)
その仕組みのうち、データ収集部分については Amazon CloudWatch が代表サービスです。
通知部分については Amazon Simple Notification Service が代表サービスですが、
2023 年 5 月に GA した AWS User Notifications (以下、AUN) も候補になります。
今回は、AUN を実際に運用で使ってみて惜しいなと感じた 4 点をまとめたいと思います。
AWS User Notifications について
概要
AUN は、Amazon CloudWatch Alarm や AWS Health イベントなどの通知設定を一元的に設定・管理できるサービスです。サービス自体は グローバルサービス となります。
後述しますが、内部的には指定したリージョンに AWS管理の Amazon EventBridge ルール が作成され、検知したイベントを AWS Management Console Notifications Center と、指定した以下通知先に通知します。
- Eメール
- AWS Chatbot
- AWS Console Mobile App
料金
AUN 自体に料金はかかりません。
ただし、内部的には EventBridge を作成していますので、検知したイベント数に応じて料金が発生します。
仕組み
全体像
全体像は以下に示すようなイメージとなります。
Notification hubs (通知ハブ)
通知ハブは、通知データを 保存・処理・複製 するためのコンポーネントです。
アカウントレベルで設定するもので、最低 1 つ、最大 3 つのリージョンを設定することができます。
AUN はグローバルサービスであることから、初めて設定する際は以下のようにバージニア北部リージョンが入っていますが、変更可能です。
実際のところ、通知ハブの設定に関わらず、デフォルトリージョンであるバージニア北部リージョンには通知データが保存されます。
また後述する通知設定を作成したリージョンにも、通知データは保存されるようです。そのため、基本的には通知設定を作成するリージョンに合わせて通知ハブのリージョンを設定するのが良いと思います。
Important
Notification hubs only set the Regional boundaries of notifications. User Notifications stores the notification configuration's data in the default Region, US East (N. Virginia). This data is also stored in individual Regions that you have configured rules for.
Notification configurations (通知設定)
通知設定は、検知したい AWS サービスのイベントとルールを定義し、通知先の配信チャネルを設定するコンテナです。
以下の例では Amazon CloudWatch Alarm のステータスが Alarm 状態になったイベントを検知するための通知設定です。EventBridge での設定と変わらない使用感ですね。
特別な設定として リージョン という項目がありますが、ここで指定したリージョンに
AWS 管理の EventBridge ルール が作成されます。
このルールは AWS 管理であるため、編集することはできません。
実際に EventBridge ルール の中身を見てみると以下の通りです。
イベントパターンに AUN の画面で設定した 高度なフィルター の値が入っていませんが、
ちゃんとフィルターしてくれるので安心してください。
ターゲットを見てみると実は 入力トランスフォーマー が設定されています。
入力トランスフォーマーの中身は以下の通りです。
入力パス で EventBridge ルール が検出した JSON 形式のイベントをそのまま event 変数に格納し、入力テンプレート で使用しています。
実際のところは入力テンプレート 通りの形式ではなく、配信チャネル に合わせて
AWS 側で変換して通知します。
例えば Eメール であれば HTML 形式のメール文に変換されます。
通知設定におけるその他設定項目としては 集約設定 と 配信チャネル があります。
集約設定 は大別すると、イベントが発火されたら即座に通知 か 一定期間 ( 5 分 or 12 時間 ) に発火されたイベントをまとめて通知 の 2 パターンです。ここは監視対象イベントの重要度に合わせて設定する項目となります。
配信チャネル は、検知したイベントの通知先の設定となります。複数指定可能 です。
Delivery channels (配信チャネル)
前述した通りで、検知したイベントの通知先の設定となります。
現時点では以下 3 つを配信チャネルとして設定できます。
ちなみに余談ですが、Eメール に関しては 全体像 で図示した通り、AWS 管理の EventBridge ルール を作成したリージョンと同じリージョンの Amazon SES API Endpoints を経由するそうです。
※ 特にマネジメントコンソールからは確認できませんでした。内部的なリソースのようです。
セキュリティ
マネージドサービス なので意識するところではないですが念のため記載します。
データにフォーカスしますが、AWS 所有の KMS キー で暗号化されています。また AUN からのデータ通信は TLS で暗号化 されています。
Data encrypted with AWS owned key
- Notification events
- Notification configurations
- Event rules
- Notification hubs
- Email contacts
Encryption in transit
All data sent to and from User Notifications is encrypted using standard TLS.
惜しいところ
本記事の本題です。
実際に使ってみて 惜しいなと感じた 4 点 を記載していきます。
全てのイベントに対応していない
一例ではありますが、EventBridge では AWS Directory Service からのイベントを検知するルールを作成できますが、AUN では作成できません。
このように、AUN では検知できないイベントが存在します。
そのため利用する際は、事前に検知したいイベントが AUN で対応しているか検討する必要があります。
対応イベントについて具体的に明記されたページは見つけられませんでしたが、現在 100 を超える AWS サービスからのイベントに対応しているようです。
AWS ユーザー通知がサポートしている通知タイプを教えてください。
AWS ユーザー通知により、ユーザーは CloudWatch アラームの状態変化などの任意の EventBridge イベントを選択し、通知を生成するように設定できます。現在、100 を超える AWS のサービスが EventBridge にイベントを発行しています。
一部イベントはメールから詳細が分かりにくい
Amazon CloudWatch Alarm などは Eメール 本文に Alarm 名や メトリクス名が記載されているので判断しやすいのですが、例えば以下のような ACM の証明書有効期限前通知 なんかだと、どの証明書が対象なのか Eメール 本文から判断できません。
そのため、追加調査が必要となります。
通知文をカスタマイズできれば良いのですが、現時点ではサポートされていません。
通知をカスタマイズできますか? つまり、通知のタイトルまたは本文を変更できますか?
現在、このサービスはカスタマイズ機能をサポートしていません。
EventBridge のフィルタリング機能が一部使えない
AUN におけるイベントのフィルタリングで使用できる比較演算子は以下の 3 つです。
- Suffix filtering
- $or matching
- Equals-ignore-case - ignore case sensitivity
ちなみに ワイルドカードは使用不可 であることが明記されています。
Wildcards aren't currently supported.
EventBridge で使用できる比較演算子の数と比較するとかなり少ないので、柔軟なフィルタリングができないことになります。
イベントソース ( AWS サービス) のクォータが厳しい
以下図の赤枠で囲ったところが個人的にはネックだなと思います。
上記赤枠のクォータにより、同タイミングで異なるソース ( AWS サービス ) からイベントが発火された場合に、1 つソースからのイベントしか拾えない ということになります。
つまり拾えなかったソースからのイベントは、「設定した通知先に通知が飛ばない」「AWS Management Console Notifications Center で確認できない」ということになります。
イメージは以下のような感じです。
実際に私の環境でもスロットルが発生し、拾われなかったソースからのイベント通知は届かず、AWS Management Console Notifications Center でも確認ができませんでした。
残念ながらこのクォータは 変更不可 です。そのため苦し紛れではありますが、スロットルを監視し 、スロットル監視通知が来た場合、捨てられたソースの状態をマネジメントコンソールで確認する という対処をする必要があります。
そのためなのかはわかりませんが、AUN が出力する唯一のメトリクスがスロットルに関するメトリクスです。
上記メトリクスに対する Amazon CloudWatch Alarm を作成し監視することでイベントを見逃す確率は下げられます。
以下 2 点を考えるとかなり致命的なところかなと個人的には思っています。
- スロットルで検知した後の調査が大変
- スロットル監視用 Amazon CloudWatch Alarm の通知を AUN でやろうとすると、このイベントもスロットルで捨てられる可能性があるため、
SNS など AUN ではない別の通知を設定するのがベターであり、
通知の一元化ができない
まとめ
今回は、AUN を実際に運用で使ってみて惜しいなと感じた 4 点をまとめました。
通知というのは運用担当者の初動においてとても重要なインプット材料だと思います。
「とにかく通知がこれば良い」ということであれば、AUN で良いのかなと個人的には思います。
「通知からより詳細な情報が知りたい」ということであれば、EventBridge 入力トランスフォーマー か AWS Lambda を仲介させる必要があります。
その点踏まえた通知部分の設計をしておくと運用フェーズで困らないかなと思います。
こちらの記事が誰かの役に立てば幸いです。