※本記事は網屋 Tech Blog Advent Calendar 2024の12月15日分の記事です。
こんにちは。@RefactorRavenです。
みなさんのクラウドサービスではエラー監視をやっていますか？
サービス内での不具合を運用者が監視するための手段として、予期されるエラーの発生時にSlackへ通知を飛ばすというものがあります。
しかし、実際に運用してみると通知が思いのほか多く、重要な通知が埋もれて気づかれにくくなってしまうということもあるあるなんじゃないかなと思います。
そこで今回は、重要なアラート通知をできるだけ派手にする方法について書いていきます。
やりたいこと
- 運用中のクラウドサービスで緊急度高めのアラートが発生したときに派手に通知させたい
- 緊急度高めのアラート: ヘルスチェックに失敗してますよとか
- 誰かが気づくまで繰り返し通知してほしい
こんなイメージ↓
この記事の趣旨
書くこと
通知機構を実現するためのAWSアーキテクチャの概要
書かないこと
実装の詳細
想定読者
- AWS・Slack appsに関する基本的な知識がある
- LambdaからのSlack通知方法が知りたい方には @ymat19さんの記事 がオススメです！
- 運用中のクラウドサービスにおいて重要な問題が発生した際、Slackに派手に通知がきてほしいと思っている
構成
左上あたりから順にみていきます。
- サービスに重要なエラーが発生した際、何らかの経路で緊急用の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の通知来てるな～何かあったのかな？
重要なアラートが発生している！ 対処しなきゃ！
と重要な通知にすぐ気づくことができるようになりました。