本記事は BeeX Advent Calendar 2025 の11日目の記事です。
はじめに
とあるアプリでその日にあったメッセージの要約とメッセージからURL一覧を生成する処理を作っていたとき、
意図せず日時どころか数分おきに要約が生成され、！？となった話を書きます。
作ろうと思った仕組み
要約受付処理はAPIとして作成し、内部ではデータ収集→要約生成、URL抽出→成功レスポンス返却の順で処理を行うようにしました。
日次での定期実行にはEventBridgeのスケジュール機能を利用し、毎日決まった時間に要約受付APIを呼び出すようにしました。
この時にAPIを呼び出す方法としてEventBridge→LambdaでAPIコール実装ではなく、
EventBridgeのAPI Destination機能を利用し、Lambdaコードを実装することなく、EventBridgeから直接APIを呼び出すようにしました。
設定したときの僕の頭の中
流れとして、「EventBridge呼び出し → 要約受付処理API実行(EventBridgeはレスポンスは見てないだろう)」でシンプルだし、
Lambdaコードも不要で楽だな、EC2定時起動や停止も過去に何度もしているし大丈夫やろ、よしこれで行こう！
スケジュール設定を日本時間の午前3時にして、明日の朝に動作確認するか！おやすみ！
問題発生
翌朝、要約受付APIのログを確認すると、午前3時以降から数十件の要約生成リクエストが大量発生していることがわかりました。
スケジュール設定は午前3時の1回だけであることを確認し、APIのエラーかと思い、APIのログを詳細に確認しましたが、API自体は正常に動作、全て成功レスポンスを返していました。
ということはAPIがどこかから攻撃を受けていて、APIが大量に呼び出されているのか？と考え、
API側のエンドポイントパスを切り替え、EventBridgeの設定を変更すると攻撃?が止み、一安心ということでその日を終えました。
が、また翌日も同様に大量の要約生成リクエストが発生しました。
これはおかしい、EventBridgeが何かおかしいのでは？と考え、仕様を確認すると。。。
原因判明
API destinations as targets in Amazon EventBridgeにデカデカと以下の記述が。。。
そう、API DestinationはAPIのレスポンスを確認していたんですね。。。
(想定外の挙動の元凶部分 → 「EventBridge呼び出し → 要約受付処理API実行(EventBridgeはレスポンスは見てないだろう)」)
それも5秒以内に返ってこないと失敗を判定し、リトライを行う仕様でした。
要約生成は数十秒〜数分かかるため、EventBridgeから見ると全てタイムアウトエラーとなり、リトライが発生し続けていたのです。(デフォルトは約24時間or最大185回で打ち切り)
要約ログの出力時間も午前3時ちょうどに始まり、段々と間隔が広がっていったのも、EventBridgeリトライポリシーの指数関数的バックオフによるものでした。
対応
原因がわかったので、以下2つの対応を行いました。
- 要約受付APIのレスポンスを即時返却し、要約生成は非同期で行うように修正
- EventBridge API Destinationの仕様に合わせて対応するために、APIレスポンスは即時返却し、要約生成は非同期実行するように修正しました。
- EventBridgeのAPI Destinationで再試行回数を0回に設定
- (上記修正で理論上、失敗することは無くなったはずですが、)要約処理は失敗しても問題ないため、EventBridgeのAPI Destinationの再試行回数を0回に設定しました。
おわりに
ということで最近ちょっとやらかした話でした。(要約をBedrockのClaude Opus 4.5で生成しているのでコストが。。。)
ちゃんとサービス仕様を公式ドキュメントで確認しましょうという過去何度も語られている内容でした。