【ITニュース解説】Detect EventBridge target failure: Part 1 - with dead letter queue

システム開発において、イベントの確実な配信は非常に重要だ。Amazon EventBridgeは、あるシステムで発生したイベント（メッセージ）を、別のシステムやサービス（ターゲット）へ自動的に、そして効率的に振り分ける役割を担う。しかし、EventBridgeがメッセージをターゲットに配信する際、常に成功するとは限らない。例えば、ターゲットへのアクセス権限が不足していたり、ターゲットサービスが一時的に停止していたり、あるいは急激な負荷によって処理が間に合わなかったり、AWSシステム自体の一時的な不具合など、さまざまな理由でメッセージの配信が失敗することがある。このような配信失敗が発生した場合、それを早期に検知し、何が原因で失敗したのかを把握し、迅速に対応できる仕組みを持つことは、システム全体の安定稼働にとって極めて重要である。

この課題を解決するための一つの有効な手段が、「デッドレターキュー（DLQ）」の活用だ。デッドレターキューとは、文字通り「配達できなかった手紙（メッセージ）」が一時的に保管される特別な場所（キュー）のことで、イベント駆動型アーキテクチャにおけるシステムの堅牢性を高める上で非常に有用な機能として知られている。設定も比較的簡単で、運用コストも低く抑えられるため、多くのシステムで利用されている。

EventBridgeには、大きく分けて二種類のデッドレターキューが存在する。一つはEventBridgeバス全体に設定する「バスレベルのDLQ」だ。これは、メッセージがターゲットに届く前に、EventBridge自体がメッセージを暗号化する際に何らかの問題が発生した場合に利用される。例えば、メッセージの暗号化に使う鍵（KMSキー）に問題があった場合などに、暗号化できなかったメッセージがここに送られる。AWSコンソール上でも、カスタマーマネージドKMSが使用されている場合の暗号化設定の一部としてこのDLQ設定が表示される。しかし、このバスレベルのDLQは、メッセージがターゲットへ実際に配信される際の失敗を捕捉するようには設計されていない。つまり、ターゲット側の権限問題やサービスの一時停止などによる配信失敗は、このDLQでは検知できないため、今回の目的には適さない。

今回の本題となるのが、もう一つの「EventBridgeターゲットレベルのDLQ」である。これは、EventBridgeのルールによって指定された「個々のターゲット」に対して設定されるデッドレターキューだ。EventBridgeがメッセージを特定のターゲットに配信しようとした際に、何らかの理由でその配信が失敗した場合、そのメッセージをこのターゲットレベルのDLQに転送するように設定できる。例えば、EventBridgeのルールが複数のターゲットにメッセージを送信するよう設定されている場合でも、それぞれのターゲットごとに異なるDLQを指定したり、あるいは同じDLQを共有したりできる。ただし、同じDLQを使う場合でも、設定は各ターゲットに対して個別に行う必要がある。こうした設定作業は、Infrastructure as Code（IaC）ツール、例えばAWS CDKやAWS CloudFormationなどを使えば、コードとして設定を記述し、効率的に管理できる。

では、EventBridgeとターゲットレベルDLQ、そして通知システムがどのように連携して配信失敗を検知するのか、その仕組みを見ていこう。まず、EventBridgeバスに届いたイベント（メッセージ）は、設定されたルールに基づいて、特定のターゲット（例えば、別のシステムやサービス）へ配信されようとする。もし、ターゲットへの配信が、アクセス権限の不足、ターゲットサービスの一時的な停止、またはネットワークの問題などによって失敗した場合、EventBridgeはその失敗したメッセージを、事前にそのターゲット用に設定されていたデッドレターキュー（DLQ）へと自動的に格納する。

次に、AWSの監視サービスであるCloudWatchを使って、このDLQにメッセージが格納されたことを検知するアラームを設定する。DLQにメッセージが一つでも入ると、CloudWatchアラームがトリガーされる。このアラームが発動した際のアクションとして、AWSの通知サービスであるSimple Notification Service（SNS）トピックを設定しておく。すると、CloudWatchアラームはSNSトピックに通知メッセージを発行する。SNSトピックは、あらかじめ登録されている購読者（システム管理者や開発者のメールアドレスなど）に対して、配信失敗が発生したことを伝える通知を送信する。これにより、配信失敗を即座に把握し、原因を調査して対応を開始できる。この一連のプロセスを通じて、なぜメッセージが届かなかったのか、そしてどのメッセージが届かなかったのかといった詳細情報を、DLQに格納されたメッセージの属性から確認することも可能だ。

このようなシステムは、実際にAWSの環境で構築し、動作を検証できる。例えば、システム開発者は専用のテンプレートを使って環境をデプロイし、意図的にターゲットへの配信を失敗させることで、DLQへのメッセージ格納から通知までの流れを体験できる。通知の頻度やタイミングは、CloudWatchアラームのしきい値や監視期間を調整することで、システムの運用状況に合わせて細かく制御できる。

このデッドレターキューを用いたアプローチの大きなメリットは、EventBridgeがイベントをターゲットに届けられないという、通常は見過ごされがちな問題を確実に捕捉し、適切なタイミングで関係者に通知できる点にある。これにより、システム全体の信頼性と安定性が飛躍的に向上し、ユーザー体験の悪化を防ぐことにもつながる。個々のターゲットに対してDLQの設定は必要になるが、これはIaCツールを活用することで、効率的に管理・運用できる。この方法は、EventBridgeの配信失敗を検知し、安定したシステム運用を実現するための基本的ながら非常に効果的な手段である。