Container Apps の ingressタイムアウトの設定について

こんにちは、@PEIBAO LIU 様

Microsoft Q&A にお問い合わせいただきありがとうございます。

お客様が現在確認されている挙動は、Azure Container Apps が HTTP イングレスリクエストを処理する仕組みに起因する、想定通りの動作となります。HTTP イングレス経由でリクエストが行われる際、そのリクエストは Envoy ベースのイングレスプロキシを経由します。このプロキシには、約 240 秒（4 分）という固定のリクエストタイムアウトが設定されています。もし、お客様のストアドプロシージャの実行など、バックエンドでの処理にこの時間を超える時間を要する場合、イングレスレイヤーが接続を強制的に切断し、クライアントに対して「504 Gateway Timeout」または「stream timeout」のエラーを返します。たとえバックエンドのコンテナが稼働を続け、ストアドプロシージャの実行が進行中であったとしても、プラットフォーム側ですでにクライアントとの接続が閉じられてしまっている状態となります。この制限が存在するのは、Azure Container Apps が主に短時間で完了するステートレスな HTTP リクエスト向けに設計されており、イングレスレイヤー経由での長時間にわたる同期処理（同期オペレーション）はサポート対象外となっているためです。さらに、標準環境（従量課金ベースの環境）においては、このタイムアウト値を変更（構成）することができません。そのため、アプリケーションコードのレベルで処理の実行時間を延長するような設定を行っても、この問題が解決しないという結果になります。

この問題を解決するため、または回避策として、以下の点をご参照ください。

非同期処理パターンを採用する（推奨アプローチ）

単一の HTTP リクエスト内でストアドプロシージャの完了を待機するのではなく、リクエストを受け付けた時点で即座に応答を返すよう（例：HTTP 202 Accepted）、設計を変更します。そして、時間のかかるタスクについてはバックグラウンドで処理を行うようにします。

アプローチ例：

API がリクエストを受信 → メッセージキュー（Azure Service Bus / Storage Queue）にメッセージを送信

バックグラウンドワーカー（Container App または Job）がキューからメッセージを取得し、ストアドプロシージャを実行

クライアントは定期的にステータスをポーリングするか、処理完了時にコールバックを受け取る

長時間タスクには Azure Container Apps Jobs を利用する

Container Apps Jobs は、長時間実行されるタスクやバッチ処理ワークロード向けに特化して設計されており、HTTP イングレスのタイムアウト制限の影響を受けません。API から、あるいはイベントをトリガーとして Job を起動し、処理が完了するまで独立して実行させることができます。

キューベースのアーキテクチャを導入する

メッセージングシステムを活用し、各コンポーネントが疎結合されたアーキテクチャを導入します。

フロントエンド / API → タスクをキューに送信

ワーカーサービス → キューからタスクを取得し、ストアドプロシージャを実行

これにより、処理の信頼性が確保され、リクエストタイムアウトによる制限を回避することが可能になります。

長時間にわたる同期的な HTTP 呼び出しは避ける

Azure Container Apps のイングレス機能は、約 240 秒を超えるようなワークロードの処理には適していません。もし、どうしても同期的な実行が必須である場合は、Azure Kubernetes Service (AKS) のような代替サービスのご利用をご検討ください。AKS であれば、イングレスのタイムアウト設定をより詳細かつ柔軟に制御することが可能です。ストアドプロシージャの実行を最適化する（可能な場合）

実行可能であれば、ストアドプロシージャの実行処理を見直し、4分という制限時間内に完了するよう最適化してください。ただし、30分を要するようなワークロードの場合、これは現実的ではない可能性があります。