API Gateway でのレスポンスストリーミングに関する問題のトラブルシューティング - Amazon API Gateway
一般的なトラブルシューティングcURL エラーのトラブルシューティングアクセスログ記録を使用したトラブルシューティング

API Gateway でのレスポンスストリーミングに関する問題のトラブルシューティング

次のトラブルシューティングガイダンスは、レスポンスストリーミングを試用する API の問題を解決するのに役立ちます。

一般的なトラブルシューティング

TestInvokeMethod またはコンソールのテストタブを使用して、ストリームレスポンスをテストできます。以下の考慮事項は、レスポンスストリーミングでのテスト呼び出しの使用に影響する可能性があります。

  • メソッドをテストすると、API Gateway はストリーミングされたレスポンスペイロードをバッファリングします。次のいずれかの条件が満たされると、API Gateway はバッファリングされたペイロードを含む 1 回限りのレスポンスを返します。

    • リクエストが完了しました

    • 35 秒経過

    • 1 MB を超えるレスポンスペイロードがバッファされています

  • メソッドが HTTP レスポンスステータスとすべてのヘッダーを返すまでに 35 秒以上経過した場合、TestInvokeMethod で返されるレスポンスステータスは 0 になります。

  • API Gateway は実行ログを生成しません。

API をデプロイしたら、curl コマンドを使用してストリームレスポンスをテストできます。出力にプロトコルレスポンスヘッダーを含めるには、-i オプションを使用することをお勧めします。到着時にレスポンスデータを表示するには、curl オプション --no-buffer を使用します。

cURL エラーのトラブルシューティング

統合をテストしていて、curl: (18) transfer closed with outstanding read data remaining エラーが表示される場合は、統合のタイムアウトが十分に長いことを確認してください。Lambda 関数を使用している場合は、Lambda 関数のレスポンスタイムアウトを更新する必要があります。詳細については、「Lambda 関数のタイムアウトを設定する」を参照してください。

アクセスログ記録を使用したトラブルシューティング

REST API ステージのアクセスログを使用して、レスポンスストリームのログ記録とトラブルシューティングを行うことができます。既存の変数に加えて、次のアクセスログ変数を使用できます。

$context.integration.responseTransferMode

統合のレスポンス転送モード。BUFFERED または STREAMED のいずれかとなります。

$context.integration.timeToAllHeaders

API Gateway が統合接続を確立してから、クライアントからすべての統合レスポンスヘッダーを受信するまでの時間。

$context.integration.timeToFirstContent

API Gateway が統合接続を確立してから、最初のコンテンツバイトを受信するまでの時間。

$context.integration.latency-または-$context.integrationLatency

API Gateway が統合接続を確立してから統合レスポンスストリームが完了するまでの時間。

次の図は、これらのアクセスログ変数がレスポンスストリームのさまざまなコンポーネントをどのように表しているかを示しています。

API Gateway でのレスポンスストリーミングのアクセスログ変数

アクセスログの詳細については、「API Gateway で REST API の CloudWatch ログ記録を設定する」を参照してください。X-Ray を使用してレスポンスストリームをモニタリングすることもできます。詳細については、「API Gateway で X-Ray を使用して REST API へのユーザーリクエストをトレースする」を参照してください。