🌟 はじめに
この記事は Microsoft Azure Tech Advent Calendar 2025 9 日目の記事です。
あくまでも現時点での公開情報と実際に動作させてみて分かったことベースでの記載となります。
将来的に動作が変わる可能性があることはご承知おきください。
⚡ TL;DR
- App Service のリクエストタイムアウト 4 分は正確にはアイドルタイムアウト。
- SSE なら 4分 超えることができる。
- LLM と連携するなら
stream=trueとして SSE を使うのがいいんじゃないでしょうか。
⏱️ Azure App Service におけるリクエストタイムアウト
App Service では アプリケーションが約 240 秒以内 (Windows アプリでは 230 秒、Linux アプリでは 240 秒) に応答が返されない場合 504 Gateway Timeout が発生します。
これは App Service と同じプラットフォームで提供される Azure Functions についても同様です。
また、この動作は良く知られた仕様で下記の FAQ にも記載があります。
アプリケーションのパフォーマンスに関する FAQ - Azure | Microsoft Learn
230 秒後に要求がタイムアウトになるのはなぜですか?
Azure Load Balancer には、4 分という既定のアイドル タイムアウト設定があります。 この設定は一般的にウェブ リクエストのための妥当な応答時間の制限です。 そのため、アプリケーションが約 240 秒以内 (Windows アプリでは 230 秒、Linux アプリでは 240 秒) に応答が返されない場合、App Service はクライアントにタイムアウトを返します。
🧱 4分の壁を超える方法
そもそも HTTP要求に対してで 4 分かかるのを是とするかどうかはおいといて、4 分を超える処理を実現する方法を考えます。
🔍 一般的なワークアラウンド
このような場合の対策としては一般的には HTTP 202 応答を用いた「非同期要求-応答パターン」を用いることができます。また、それを実現するフレームワークとして Durable Functions などが提供されています。
🕵️ タイムアウトはどこで発生するのか
前述の FAQ に記載のとおり、この 4 分という制限は Azure Loadbalancer の構成に起因するものとなります。
HTTP応答自体は返却されているので、この 4 分を下回るように、App Service 側のミドルウェアが返却しているものと推測されます。Windows 環境と Linux 環境で10秒のずれがあることから 下記のブログ記事を引用するとWorker 側のミドルウェア(Windows の場合は IIS、Linux の場合は Yarp + Kestrel)である可能性が考えられます。
App Service を構成する主要な要素とそれぞれの役割 - Japan PaaS Support Team Blog
次にロード バランサー側のドキュメントを見てます。以下のドキュメントに 4 分 というキーワードがあります。
ロード バランサーの TCP リセットおよびアイドル タイムアウトを構成する - Azure Load Balancer | Microsoft Learn
Azure Load Balancer の規則には、Load Balancer 規則、アウトバウンド規則、インバウンド NAT 規則に対して、4 分から 100 分の既定のタイムアウト範囲が設定されています。 既定の設定は 4 分です。
ロード バランサーの仕組みとしては変更可能のようですが、App Service プラットフォームを構成するロード バランサー自体をユーザーが変更することはできないため、4分を変更することはできません。
ここで気になるのはロード バランサー側のドキュメントには アイドル タイムアウト と記載されています。
アイドル タイムアウトってことはパケットが通り続ければ接続は維持されることが見込まれます。
検証
以下の2つのAPIを用意してみました。
- Server-sent events(SSE) を返す API
content-type は text/event-stream として指定回数だけイベントを返すやつ
- 単純に応答スループットが遅い API
content-type は text/plain; charset=UTF-8 だけど、応答が書き終わるまで指定秒スリープするやつ
検証結果
どちらの API も 250 秒かけて完了していることが確認できました。すなわち、4分 というのはあくまでもアイドル タイムアウトで、その間パケットが流れていれば切断されて 504 になることはありません。
Server Sent Event といえば
ここでようやく昨今の LLM 連携アプリケーションに話がつながります。
LLMの応答も stream=true とすることで SSE で応答を得ることができます。
Streaming API responses - OpenAI API
Azure OpenAI の Microsoft Foundry Models v1 REST API リファレンス - Azure OpenAI | Microsoft Learn
App Service 等にデプロイしたアプリケーションから LLM の APIを呼び出し、応答を加工してさらにクライアントにSSEで返却することで LLM からの応答が巨大になっても大丈夫ということですね。
参考
Azure OpenAIの返答をAzure Functionを中継してStream(SSE)したい
また、最近 サイドカーとしてで Phi-4 を SLM として動作させるチュートリアルがあります。
チュートリアル: SLM 拡張機能を使った Express.js チャットボット - Azure App Service | Microsoft Learn
ここでも SLM の API をストリームとして呼び出し、クライアントへも SSE で中継する実装となっています。
Phi-4 サイドカーちょっと試してみましたが SKU を渋ると応答がとてつもなく遅い1のでストリーム化は必須と思われます。
Azure Container Appsはどうなの
Azure Container Apps についても同様の制限があります。
Azure Container Apps でのイングレス | Microsoft Learn
要求のタイムアウトは 240 秒です
ただし、Premium イングレスを用いることで上限を緩和することが可能です。
Azure Container Apps 環境でイングレスを構成する | Microsoft Learn
これは Azure Containe Apps の場合 マネージドリソース として専用のロードバランサーが用意されるため変更可能なものと推測できます。
そんなことなかった。。。
Premium イングレスでアイドルタイムアウトを変更してもマネージドリソース LB の負荷分散規則のアイドルタイムアウトは変わらず。
なので別の仕組みっぽい。