レスポンス エラーのトラブルシューティング

このページでは、API に対するリクエストから返ってきたレスポンスで発生するエラーのトラブルシューティング方法について説明します。

BAD_GATEWAY

エラーコード 13 と「BAD_GATEWAY」というメッセージが表示される場合は、Extensible Service Proxy（ESP）がサービスのバックエンドに到達できないことを示しています。 以下をご確認ください。

  • バックエンド サービスが実行されていることを確認します。確認方法はバックエンドによって異なります。

  • バックエンド サービスの正しい IP アドレスポートが指定されていることを確認します。
    • GKE の場合は、デプロイ マニフェスト ファイル（deployment.yaml とも呼ばれます）の中にある ESP --backend フラグの値（短縮オプションは -a）を確認します。
    • Compute Engine の場合は、docker run コマンドで ESP --backend フラグの値（短縮オプションは -a）を確認します。

reset reason: connection failure

HTTP コード 503 または gRPC コード 14 が返され、「upstream connect error or disconnect/reset before headers. reset reason: connection failure」というメッセージが表示された場合、ESPv2 がサービスのバックエンドに到達できないことを示しています。

問題を解決するには、以下の項目を再確認してください。

バックエンド アドレス

ESPv2 に正しいバックエンド アドレスを構成する必要があります。一般的な問題としては、次のようなものがあります。

  • バックエンド アドレスのスキームは、バックエンド アプリケーション タイプと一致する必要があります。OpenAPI バックエンドは http://、gRPC バックエンドは grpc:// になります。
  • Cloud Run にデプロイされた ESPv2 の場合、バックエンド アドレスのスキームは https:// または grpcs:// になります。s は、バックエンドで TLS を設定するよう ESPv2 に指示します。

DNS ルックアップ

デフォルトでは、ESPv2 はドメイン名を IPv6 アドレスに解決します。IPv6 の解決に失敗した場合、ESPv2 は IPv4 アドレスにフォールバックします。

一部のネットワークでは、フォールバック メカニズムが意図したとおりに動作しないことがあります。代わりに、--backend_dns_lookup_family フラグを使用して、ESPv2 に IPv4 アドレスの使用を強制できます。

このエラーは、Cloud Run にデプロイされた ESPv2 のサーバーレス VPC コネクタを構成する場合によく発生します。VPC は IPv6 トラフィックをサポートしていません。

API is not enabled for the project

API キーをリクエストで送信したときに「API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project」のようなエラー メッセージが返された場合は、API キーが作成された Google Cloud プロジェクトと API の Google Cloud プロジェクトが異なることを示しています。この問題を解決するには、API が関連付けられているのと同じ Google Cloud プロジェクトで API キーを作成するか、API キーが作成された Google Cloud プロジェクトで API を有効にします。

Service control request failed with HTTP response code 403

エラーコード 14 が表示され、「Service control request failed with HTTP response code 403」というメッセージが表示された場合は、プロジェクトで Service Control API（servicecontrol.googleapis.com）が有効になっていないことを示しています。

  1. Endpoints と ESP に必要なすべてのサービスがプロジェクトで有効になっていることを確認するには、必要なサービスの確認をご覧ください。

  2. 必要な権限を確認するを参照して、ESP を実行しているインスタンスに関連付けられたサービス アカウントに必要なすべての権限を確認します。

Method doesn't allow unregistered callers

OpenAPI ドキュメントの security セクションで API キーが指定されている場合、ESP からエラー「Method doesn't allow unregistered callers」が返されますが、API へのリクエストで key という名前のクエリ パラメータに割り当てられた API キーがありません。

API を呼び出すために API キーを生成する必要がある場合は、API キーの作成をご覧ください。

Method does not exist

レスポンス「Method does not exist」は、指定された URL パス上で HTTP メソッド（GET や POST など）が見つからなかったことを示します。これをトラブルシューティングするには、デプロイしたサービス構成を比較して、リクエストで送信しているメソッド名と URL パスが一致しているか確認します。

  1. Google Cloud コンソールで、プロジェクトの [エンドポイント] の [サービス] ページに移動します。

    [Endpoints] の [サービス] ページに移動

  2. API が複数ある場合は、リクエストの送信先 API を選択します。

  3. [デプロイの履歴] タブをクリックします。

  4. 最新のデプロイを選択して、サービス構成を確認します。

呼び出しているメソッドが OpenAPI ドキュメントの paths セクションに指定されていない場合は、メソッドを追加するか、ファイルの最上位に x-google-allow フラグを追加します。

x-google-allow: all

このフラグを指定すると、OpenAPI ドキュメントのバックエンドでサポートされているすべてのメソッドがリストされるのを回避できます。all を使用すると、API キーまたはユーザー認証の有無にかかわらず、すべての呼び出しが ESP を介して API に渡されます。詳細については、x-google-allow をご覧ください。

App Engine フレキシブル環境固有のエラー

ここでは、App Engine フレキシブル環境にデプロイされた API からのエラー レスポンスについて説明します。

エラーコード 502 または 503

App Engine がリクエストにレスポンスするまで数分かかる場合があります。リクエストを送信して HTTP 502、503 または他のサーバーエラーが返された場合には、1 分ほど待ってからもう一度リクエストしてください。

エラー メッセージ BAD_GATEWAY

メッセージにエラーコード 502 と BAD_GATEWAY が含まれている場合は通常、メモリ不足が原因で App Engine によってアプリケーションが終了したことを示しています。デフォルト App Engine フレキシブル VM のメモリは 1 GB のみであり、そのうちアプリケーション コンテナに使用できるのは 600 MB のみです。

エラーコード 502 のトラブルシューティングを行うには:

  1. Google Cloud コンソールで [Logging] ページに移動します。

    [ログ エクスプローラ] ページに移動

  2. ページ上部で該当する Google Cloud プロジェクトを選択します。

  3. [Google App Engine Application] を選択して、vm.syslog を開きます。

  4. 次のようなログエントリを探します。

    kernel: [  133.706951] Out of memory: Kill process 4490 (java) score 878 or sacrifice child
kernel: [  133.714468] Killed process 4306 (java) total-vm:5332376kB, anon-rss:2712108kB, file-rss:0kB

    ログに Out of memory エントリがある場合:

    1. app.yaml ファイルに次を追加して、デフォルト VM のサイズを増やします。

      resources:
  memory_gb: 4

    2. API を再デプロイします。

      gcloud app deploy

app.yaml ファイルの endpoints_api_service セクションに rollout_strategy: managed オプションが指定されている場合は、次のコマンドを使用して API を再デプロイします。

  gcloud app deploy

詳細については、API と ESP のデプロイをご覧ください。

Cloud Logging のログを確認する

Cloud Logging のログを使用してレスポンス エラーのトラブルシューティングを行うには、

  1. Google Cloud コンソールで [Logging] ページに移動します。

    [ログ エクスプローラ] ページに移動

  2. ページの上部で、Google Cloud プロジェクトを選択します。

  3. 左側のプルダウン メニューを使用して、[生成された API] > [YOUR_SERVICE_NAME] を選択します。

  4. レスポンス エラーを示す行が表示されるまで、時間範囲を調整します。

  5. JSON ペイロードを展開し、error_cause を探します。

    • error_cause が application に設定されている場合は、コードに問題があることを示しています。

    • error cause がそれ以外であり、ご自身で問題を解決できない場合は、ログをエクスポートし、Google へのご連絡の際にご提供ください。

詳しくは以下をご覧ください。

サンプルの Invoke-WebRequest に関する問題

Windows PowerShell の一部のバージョンでは、チュートリアルのサンプル Invoke-WebRequest が失敗します。また、文字に変換しなければならない符号なしバイトのリストがレスポンスに含まれていたという報告もあります。サンプルの Invoke-WebRequest から返された結果が期待どおりでない場合は、別のアプリケーションを使用してリクエストを送信してみてください。いくつかの対処方法を以下に示します。

  • Cloud Shell を起動し、同じチュートリアルに示されている Linux の手順に従ってリクエストを送信します。

  • Chrome ブラウザの拡張機能である Postman（提供元: www.getpostman.com）などのサードパーティ製アプリケーションをインストールします。Postman でリクエストを送信するとき、以下の点に注意してください。

    • HTTP 動詞として POST を選択します。
    • ヘッダーで、キー content-type とその値 application/json を選択します。
    • 本文に {"message":"hello world"} を入力します。

    • URL で、環境変数ではなく実際の API キーを使用します。次に例を示します。

      • App Engine フレキシブル環境: https://example-project-12345.appspot.com/echo?key=AIza...
      • その他のバックエンド: http://192.0.2.0:80/echo?key=AIza...

  • curl をダウンロードしてインストールし、コマンド プロンプトで実行します。Windows では一重引用符内にネストされた二重引用符は処理されないため、サンプルの --data オプションを次のように変更する必要があります。

    --data "{\"message\":\"hello world\"}"