はじめに
Step Functions でエラーが発生した際、みなさんはどのように通知設定をしていますか？
今回、通知方法をいくつか調査する機会があったため、それぞれの方法と特徴についてまとめました。
通知方法の一覧
- Catchフィールドを使った通知方法
- Amazon EventBridgeを使った通知方法
- CloudWatchメトリクスを使った通知方法
Catchフィールドを使った通知方法
この方法は、ワークフローのタスクに Catch フィールドを追加し、失敗時に SNS へ通知する仕組みです。
ワークフローイメージ
この方法の適している場合
- ワークフローの一部の処理だけエラーを通知させたい場合
- よく失敗する場所が明確である場合
- SNS をフローに組み込むだけで実装できるため、追加のリソース作成が不要でコストが低い
この方法の適していない場合
- ワークフロー全体でエラー通知したい場合
- すべてのステートに Catch を追加する必要があり、フローが複雑化する可能性がある
Amazon EventBridgeを使った通知方法
この方法は、EventBridge が Step Functions の実行ステータスをイベントとして受け取り、そのイベントをトリガーに通知する仕組みです。
EventBridgeが検知できる主要な実行ステータス以下です。
- STARTED（開始）
- ステートマシンの実行が開始されたときに発生
- 実行の開始を監視したい場合に使用
- SUCCEEDED（成功）
- 実行が正常に完了したときに発生
- すべてのステップの成功を監視したい場合に使用
- FAILED（失敗）
- 実行中にエラーが発生して失敗したときに発生
- エラーを監視したい場合に使用
- TIMED_OUT（タイムアウト）
- ステートマシンの実行がタイムアウトしたときに発生
- 長時間実行される処理の監視に使用
- ABORTED（中止）
- ステートマシンの実行が中止されたときに発生
- 手動での実行停止や外部要因による中止を監視したいときに使用
この方法の適している場合
- Step Functions 全体の失敗を通知したい場合
- 成功/開始など、失敗以外のステータスも通知したい場合
- Lambda を挟むことで、通知内容を細かくカスタマイズしたい場合
この方法の適していない場合
- 各ステップ単位でより細かいエラー検知をしたい場合
-
Express Workflowsの場合
- Express では EventBridge イベントが発行されないため、この方式は利用できない（CloudWatch メトリクスの利用が必要）
CloudWatchメトリクスを使った通知方法
CloudWatch が提供するメトリクスを基に、アラームを設定して通知する方法です。
この方法の適している場合
- 監視したいメトリクス（例：エラー回数、実行回数）が明確な場合
- Express Workflows のエラー検知が必要な場合（EventBridge 非対応のため）
この方法の適していない場合：
- Step Functions 全体の状態変化を通知したいだけの場合
- どのメトリクスを通知に使うべきか決まっていない場合
まとめ
今回調査をしてみて、Step FunctionsのエラーをSNSで通知する方法にもいくつも種類があるんだなと思いました。
要件に沿った方法を選べるように各サービスごと比較をしていくの大事だと思います。
参考になれば幸いです。