502 Bad Gateway - TooBigBody

ここに表示されているのは Apigee Edge のドキュメントです。
Go to the Apigee X のドキュメントに移動します。 info

症状

クライアント アプリケーションが、API 呼び出しに対するレスポンスとしてエラーコード protocol.http.TooBigBody の HTTP ステータス コード 502 Bad Gatewayを受け取ります。

エラー メッセージ

クライアント アプリケーションは、次のレスポンス コードを受け取ります。

HTTP/1.1 502 Bad Gateway

さらに、次のエラー メッセージも確認できます。

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

考えられる原因

このエラーは、HTTP レスポンスの一部としてターゲット/バックエンド サーバーから Apigee Edge に送信されたペイロード サイズが、Apigee Edge で許可されている上限 を超えている場合に発生します。

原因: レスポンス ペイロード サイズが許可されている上限を超えている

診断

1. シナリオ #1 の共通の診断手順で説明したように、API Monitoring、Trace ツール、NGINX アクセスログを使用して、確認されたエラーの障害コード、障害ソース、レスポンス ペイロード サイズを特定します。
2. 障害ソースの値が target の場合、ターゲット/バックエンド サーバーから Apigee に送信されたレスポンス ペイロード サイズが、Apigee Edge で許可されている上限を超えていることを示します。
3. レスポンス ペイロード サイズを、ステップ 1で特定したとおりに確認します。
   • ペイロード サイズが 10 MB の上限を超えている場合、それがエラーの原因です。
   • ペイロード サイズが 10 MB の上限に近い場合、レスポンス ペイロードが圧縮形式で渡されている可能性があります。 原因: レスポンス ペイロード サイズが解凍後に許可されている上限を超えているに移動します。
4. 次の手順で実際のレスポンスを確認して、レスポンス ペイロード サイズが 10 MB の上限を超えていることを確認します。
   1. ターゲット/バックエンド サーバーへの実際のリクエストにアクセスできない場合は、 解決策に移動します。
   2. ターゲット/バックエンド サーバーへの実際のリクエストにアクセスできる場合は、 次の手順を行います。
      1. Public Cloud/Private Cloud ユーザーの場合は、バックエンド サーバー自体から、またはバックエンド サーバーにリクエストを送信できる他のマシンから、バックエンド サーバーに直接リクエストを送信します。
      2. Private Cloud ユーザーの場合は、Message Processor のいずれかから バックエンド サーバーにリクエストを送信することもできます。
      3. ** Content-Length ヘッダー** を確認して、レスポンスで渡されたペイロードのサイズを確認します。
      4. ペイロードのサイズが Apigee Edge で許可されている上限を超えている場合、それが問題の原因です。

   バックエンド サーバーからのレスポンスの例:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   上記の例では、Content-Length: 11534336 (which is ~11 MB) が Apigee Edge で許可されている上限を超えているため、このエラーの原因となっています。

解決策

解決策をご覧ください。

原因: レスポンス ペイロード サイズが 解凍後に許可されている上限を超えている

レスポンス ペイロードが圧縮形式で送信され、レスポンス ヘッダー Content-Encodingがgzip, に設定されている場合、Apigee はレスポンス ペイロードを解凍します。解凍プロセス中に、ペイロードのサイズが Apigee Edge で許可されている 上限を超えている ことが判明すると、Apigee はそれ以上の 解凍を停止し、502 Bad Gateway とエラーコード protocol.http.TooBigBody をすぐに 返します。

診断

1. シナリオ #2 の 共通の診断手順で説明したように、API Monitoring、Trace ツール、NGINX アクセスログを使用して、確認されたエラーの障害コード、障害ソース、およびレスポンス ペイロード サイズを特定します。
2. 障害ソース の値が target の場合、ターゲット/バックエンド アプリケーションから Apigee に送信されたレスポンス ペイロード サイズが、Apigee Edge で許可されている 上限 を超えていることを示します。
3. レスポンス ペイロード サイズを、ステップ 1で特定したとおりに確認します。
   • ペイロード サイズが 10 MB の上限を超えている場合、それがエラーの原因です。
   • ペイロード サイズが 10 MB の上限に近い場合、レスポンス ペイロードが 圧縮形式で渡されている可能性があります。この場合は、圧縮された レスポンス ペイロードの非圧縮サイズを確認します。
4. 次のいずれかの方法で、ターゲット/バックエンドからのレスポンスが圧縮形式で送信され、 非圧縮サイズが許可されている上限を超えているかどうかを確認できます。

   トレース

   Trace ツールを使用する場合:

   1. 失敗したリクエストのトレースをキャプチャした場合は、 Trace で説明されている手順を参照してください。
      1. target.received.content.length の値を特定します。
      2. クライアントからのリクエストに Content-Encoding: gzip ヘッダーが含まれているかどうかを確認します。
   2. target.received.content.length の値が 10 MB の上限に近い場合、レスポンス ヘッダー Content-Encoding: gzip がこのエラーの原因です。

   実際のリクエスト

   実際のリクエストを使用する場合:

   1. ターゲット/バックエンド サーバーへの実際のリクエストにアクセスできない場合は、 解決策に移動します。
   2. ターゲット/バックエンド サーバーへの実際のリクエストにアクセスできる場合は、次の手順を行います。
      1. レスポンスで送信された Content-Encoding ヘッダーとともに、レスポンスで渡されたペイロードのサイズを確認します。
      2. レスポンス ヘッダー Content-Encoding が gzip に設定され、ペイロードの非圧縮サイズが Apigee Edge で許可されている上限を超えている場合、それが このエラーの原因です。

         バックエンド サーバーから受信したレスポンスの例:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         上記の場合、ヘッダー Content-Encoding: gzip が送信され、レスポンス内のファイル testzippedfile.gz のサイズは上限を下回っていますが、非圧縮ファイル testzippedfile のサイズは約 15 MB でした。

   Message Processor ログ

   Message Processor ログを使用する場合:

   1. Private Cloud ユーザーの場合は、Message Processor ログを使用して、HTTP 502 エラーに関する重要な情報を確認できます。

   2. Message Processor ログを確認します。

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. 特定の期間に 502 エラーが発生したかどうか（過去に問題が発生した場合）、または 502 で失敗しているリクエストがまだあるかどうかを検索します。次の検索文字列を使用できます。

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. 次のように、system.log から行が見つかります（TotalRead と chunkCount は異なる場合があります）。

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. 解凍プロセス中に、Message Processor が 読み取りバイト数の合計が 10 MB を超えていると判断すると、処理を停止して次の行を出力します。

      Message is too large. TotalRead 10489856 chunkCount 2571

      これは、レスポンス ペイロード サイズ が 10 MB を超えていることを意味します。サイズが 10 MB の上限を超え始めると、Apigee 障害コード protocol.http.TooBigBody でエラーをスローします。

解決策

上限

Apigee では、クライアント アプリケーションとバックエンド サーバーが、 Apigee Edge の上限の Request/response size で規定されている許可されている上限を超えるペイロード サイズを送信しないことを想定しています。

1. Public Cloud ユーザーの場合、リクエストとレスポンスの ペイロード サイズの上限は、Request/response sizeで Apigee Edge の上限に規定されているとおりです。
2. Private Cloud ユーザー の場合は、リクエストとレスポンスのペイロード サイズのデフォルトの上限を変更している可能性があります（推奨される方法ではありません）。 リクエスト ペイロード サイズの上限を確認する方法の手順に沿って、リクエスト ペイロード サイズの上限を確認できます。

現在の上限を確認するにはどうすればよいですか？

このセクションでは、Message Processor でプロパティ HTTPResponse.body.buffer.limit が新しい値で更新されていることを確認する方法について説明します。

1. Message Processor マシンで、 HTTPResponse.body.buffer.limit ディレクトリの /opt/apigee/edge-message- processor/conf プロパティを検索し、次のように設定されている値を確認します。

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. 上記のコマンドの出力例は次のとおりです。

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. 上記の出力例では、プロパティ HTTPResponse.body.buffer.limit が 10m で値 http.properties に設定されています。

   これは、Private Cloud 用に Apigee で構成されたリクエスト ペイロード サイズの上限が 10 MB であることを示します。

Apigee サポートのサポートが必要な場合は、 診断情報の収集が必要な場合に移動してください。

診断情報の収集が必要な場合

次の診断情報を収集して、Apigee Edge サポートにお問い合わせください。

Public Cloud ユーザーの場合は、次の情報を提供してください。

• 組織名
• 環境名
• API プロキシ名
• 502 エラーを再現するために使用した完全な curl コマンド
• API リクエストのトレース ファイル
• ターゲット/バックエンド サーバーからのレスポンスの完全な出力とペイロードのサイズ

Private Cloud ユーザーの場合は、次の情報を提供してください。

• 失敗したリクエストで確認されたエラー メッセージの全文
• 組織名
• 環境名
• API プロキシ バンドル
• 失敗した API リクエストのトレース ファイル
• 502 エラーを再現するために使用した完全な curl コマンド
• ターゲット/バックエンド サーバーからのレスポンスの完全な出力とペイロードのサイズ

• NGINX アクセスログ /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  場所: ORG、ENV、PORT# は実際の値に置き換えてください。

• Message Processor システムログ /opt/apigee/var/log/edge-message-processor/logs/system.log