はじめに
昨年, Amazon API Gateway がレスポンスストリーミングに対応しました.
本記事では, API Gateway のレスポンスストリーミング利用時に遭遇したアイドルタイムアウトの問題と, その対応についてまとめます.
発生した問題
以下の構成でまれにエラーが発生することを確認しました.
API Gateway (REST API + EDGE)
└── Lambda (InvokeAgentCommand)
└── Agents for Amazon Bedrock (Claude 3.7 Sonnet)
└── Knowledge Base for Amazon Bedrock
API Gateway のアクセスログには 460 エラーが記録されていました.
調査の結果, エッジ最適化エンドポイントのアイドルタイムアウト(最大30秒)に抵触していることが判明しました.
- レスポンスは最大 15 分間ストリーミングできます。
- ストリームはアイドルタイムアウトの対象となります。リージョンエンドポイントまたはプライベートエンドポイントの場合、タイムアウトは 5 分です。エッジ最適化エンドポイントの場合、タイムアウトは 30 秒です。
原因は, Lambda 内の以下の処理において, 応答完了までに30秒以上かかるケースがあったためです.
const response: InvokeAgentCommandOutput = await client.send(command);
Bedrock(Agents + Knowledge Base)への問い合わせ処理に時間を要し,
その間ストリームがアイドル状態となっていました.
つまり, レスポンス自体は最大15分間ストリーミング可能ですが,
30秒間データ送信が行われない状態が続くとアイドルタイムアウトに抵触することが分かりました.
対応方法
考えられる対応は以下のいずれか, もしくは両方です.
1. Bedrock 側の応答時間を短縮する
まず, 現状把握のために Bedrock のトレースステップを確認します.
その上で,
- 適切なモデルの選定
- システムプロンプトの調整
- Knowledge Base の検索条件やチャンキング戦略の見直し
といった対応を行い, 応答時間そのものを短縮できれば根本的な解決になります.
2. API Gateway を REGIONAL に変更する
REGIONAL または Private エンドポイントの場合, アイドルタイムアウトは最大5分となります.
長時間の推論が前提となるユースケースでは, この選択が現実的な場合もあります.
まとめ
単純にタイムアウト値を引き延ばすだけでは本質的な改善にはなりません.
一方で, 長い推論時間が前提となる処理も存在します.
そのため,
- 応答時間を最小化したいのか
- 長時間推論を許容する設計にするのか
といった要件に応じて, アーキテクチャを選択することが重要だと考えます.