Azure OpenAI Service の 503 InternalServerException 発生原因について確認したい.

こんにちは。tomohiro_kato,

7月7日に発生した「503 InternalServerException」に関する詳細な情報をご提供いただき、ありがとうございます。

共有いただいた情報に基づくと、今回の調査では、問題の原因がAzure OpenAIサービス側の「一時的な状況」（バックエンド処理の一時的な失敗やリージョンごとのリソース容量制限など）にあるのか、それともリクエストのペイロードや実装といった「アプリケーション側」の要因にあるのかを特定する必要があります。

HTTP 503 (InternalServerException) について

503エラー（Service Unavailable / InternalServerException）は、一般的にサービスが一時的にリクエストを処理できなかったことを示します。Azure OpenAI Serviceにおいて、これは通常、サービス側の一時的な問題として扱われます。主な原因としては以下が挙げられます。

バックエンド処理の一時的な失敗。

リクエスト量の急増またはサービスの一時的な混雑。

リージョンごとの容量制限や、利用可能なコンピューティングリソースの不足。

現在、同じリクエストが正常に完了しているとのことですので、この問題はアプリケーション側の恒久的な不具合ではなく、一時的な事象であった可能性が高いと考えられます。

Azure OpenAIで問題が発生していたかを確認する方法

障害発生時にサービス側で一時的な問題が起きていたかどうかを判断するために、以下の点を確認することをお勧めします。

Azure Service Health

ご自身のサブスクリプションのAzure Service Healthを確認し、問題が発生した時間帯とAzure OpenAIのリージョンでフィルタリングを行ってください。

Azure OpenAIやCognitive Servicesに影響を及ぼすサービスインシデントやアドバイザリが報告されていないか確認します。

Azure Resource Health

Azure OpenAIリソースの正常性状態（ヘルスステータス）を確認してください。

公に報告されたサービスインシデントがない場合でも、Resource HealthやAzure Monitor上で、バックエンドサービスのパフォーマンス低下や、当該リソースに影響する5xxエラーの増加が確認されることがあります。

エンドポイントへの直接的な検証（該当する場合）

アプリケーションがAPI ManagementやAWSインフラストラクチャなどの仲介コンポーネントを介している場合、同じリクエストをAzure OpenAIのエンドポイントに対して直接送信してテストを行うことで、問題の切り分けに役立ちます。

Azure OpenAIへ直接送信しても同じリクエストでHTTP 503が返される場合、クライアントアプリケーションではなくAzure OpenAIサービス側に原因がある可能性が高まります。

これらの識別子を使用することで、お客様のリクエストとバックエンドサービスのログを照合することが可能になります。

画像が原因で問題が発生した可能性はありますか？ご提示いただいた情報に基づくと、以下の通りです。

画像解像度：約 3000 × 4000 ピクセル

画像サイズ：約 1.3 MB

現時点では、このサイズの画像単体が HTTP 503 レスポンスを引き起こすという兆候は見られません。もしリクエストがサポートされているサービス制限を超過した場合、通常は 503 ではなく、HTTP 400 や HTTP 413 といったクライアント側のエラーが発生すると考えられます。

ペイロード（送信データ）が問題に関与しているかどうかをさらに切り分けるため、以下の比較を行うことをお勧めします。

より小さな画像（解像度を下げたもの、または枚数を減らしたもの）を使用して、同じプロンプトで再試行する。

画像を含めず（テキストのみで）、同じリクエストを再試行する。

これらのシナリオ間での動作を比較する。

画像を含むリクエストのみが継続的に失敗する場合は、ペイロードがその動作に関与している可能性があります。画像を含むリクエストとテキストのみのリクエストの双方で断続的に 503 エラーが発生する場合は、一時的なサービス状況やリージョンのキャパシティ（容量）に関連する問題である可能性が高いと言えます。

再発を最小限に抑えるための推奨事項

一時的な HTTP 503 レスポンスに対しては、以下のベストプラクティスを推奨します。

「指数バックオフ」と「ジッター（ランダムな遅延）」を組み合わせた再試行を実装する（例：1秒、2秒、4秒、8秒）。

単一のデプロイメントへの急激なトラフィック集中（バースト）を避けるため、同時リクエスト数を制限する。

失敗したストリーミングリクエストにおいて、コネクションプールが枯渇しないよう、接続が適切に閉じられるようにする。

Azure Monitor のメトリックを使用して、リクエスト数、失敗数、およびレイテンシを監視する。

ワークロードで継続的に高いトラフィックが発生する場合は、キャパシティの調整、レート制限の適用、または複数デプロイメントへのトラフィック分散を検討してください。

リージョンのキャパシティ制限が疑われ、かつそのモデルが他の場所でも利用可能な場合は、サポートされている別のリージョンへのモデルのデプロイや、適切なリージョン間フェイルオーバーの実装を検討してください。

アプリケーション側でリクエストを3回再試行されていますが、一時的なリージョンの混雑やバックエンドのキャパシティ制限は、再試行の間隔よりも長く続く場合があります。その結果、サービスが復旧する前に HTTP 503 レスポンスが繰り返されることがあります。

参考になれば幸いです。ご不明な点がございましたら、お知らせください。

よろしくお願いいたします。