※本記事は網屋 Tech Blog Advent Calendar 2024の12月15日分の記事です。

こんにちは。@RefactorRavenです。
みなさんのクラウドサービスではエラー監視をやっていますか？

サービス内での不具合を運用者が監視するための手段として、予期されるエラーの発生時にSlackへ通知を飛ばすというものがあります。

しかし、実際に運用してみると通知が思いのほか多く、重要な通知が埋もれて気づかれにくくなってしまうということもあるあるなんじゃないかなと思います。

そこで今回は、重要なアラート通知をできるだけ派手にする方法について書いていきます。

やりたいこと

運用中のクラウドサービスで緊急度高めのアラートが発生したときに派手に通知させたい
- 緊急度高めのアラート: ヘルスチェックに失敗してますよとか
- 誰かが気づくまで繰り返し通知してほしい

こんなイメージ↓

この記事の趣旨

通知機構を実現するためのAWSアーキテクチャの概要

実装の詳細

左上あたりから順にみていきます。

サービスに重要なエラーが発生した際、何らかの経路で緊急用のSNSトピック（Critical）にpublishされることが前提
Lambda関数 CriticalNotifierStarter がSNSトピック（Critical）をサブスクライブしており、トピックに対するpublishをトリガーとして呼び出される
CriticalNotifierStarter はStep Functionsのステートマシン CriticalNotification をスタートする
CriticalNotification の冒頭ではSystems Manager Parameter Storeのパラメータ /Monitoring/IsAlertingCritical（後述）が true にセットされる
CriticalNotification の内部では Lambda関数 CriticalNotifierMain が10秒おきに繰り返し呼び出される
- 無限ループはしてほしくないのでタイムアウト値や繰り返し上限値を設定しておくとよい
CriticalNotifierMain はSlackのチャンネルに通知を行う
- 1回の呼び出しごとに1回通知する
通知の繰り返し続行条件はSSMパラメータ /Monitoring/IsAlertingCritical が true であること
Slack通知メッセージ内のボタンを押すとAPI GatewayにGETリクエストが送られ、Lambda関数 CriticalNotifierStopper が /Monitoring/IsAlertingCritical を false にセットして通知を止める
SFn内でエラーが発生した場合はSNSトピック（Info）にpublishし、その旨を通知する
- 通知手段は本通知同様Slackでも、メールでもなんでもOK

SFnステートマシンの起動にLambda関数を経由しているのはSNSから直接SFnを起動する手段が見つからなかったから
ステートマシンの処理冒頭でSSMパラメータを true にセットしているのは、パラメータがAPI経由で false にされていた場合に処理が行われなくなってしまうのを防ぐため
Lambda関数の繰り返し実行をSFnで制御しているのは、非自明なループの形成によるLambda関数の再帰実行を恐れているため
- たとえばLambda関数が別のLambda関数を呼び出すという構成にはしていない
- Lambdaのタイムアウト値上限が短いこともあり、関数内部でのループは行っていない
Slack通知のボタンからAPI Gatewayにアクセスするところの詳細は認証などをちゃんとやろうとすると面倒で、本記事では割愛します

本機構を実際に実装して使ってみたところ、

ｽｯｺｺｺ

ｽｯｺｺｺ

なんかめっちゃSlackの通知来てるな～何かあったのかな？

重要なアラートが発生している！　対処しなきゃ！

と重要な通知にすぐ気づくことができるようになりました。