このページでは、API に対するリクエストから返ってきたレスポンスで発生するエラーのトラブルシューティング方法について説明します。
BAD_GATEWAY
エラーコード 13
と「BAD_GATEWAY
」というメッセージが表示される場合は、Extensible Service Proxy(ESP)がサービスのバックエンドに到達できないことを示しています。
以下をご確認ください。
- バックエンド サービスが実行されていることを確認します。確認方法はバックエンドによって異なります。
-
App Engine フレキシブル環境では、
BAD_GATEWAY
メッセージのエラーコードは502
の可能性があります。詳細については、App Engine フレキシブル環境特有のエラーをご覧ください。 - Compute Engine の場合は、Compute Engine での Cloud Endpoints のトラブルシューティングで詳細をご覧ください。
-
GKE の場合、SSH を使用してポッドにアクセスし、
curl
を使用する必要があります。詳細については、Google Kubernetes Engine でのエンドポイントのトラブルシューティングをご覧ください。
-
App Engine フレキシブル環境では、
- バックエンド サービスの正しい IP アドレスポートが指定されていることを確認します。
- GKE の場合は、デプロイ マニフェスト ファイル(
deployment.yaml
とも呼ばれます)の中にある ESP--backend
フラグの値(短縮オプションは-a
)を確認します。 - Compute Engine の場合は、
docker run
コマンドで ESP--backend
フラグの値(短縮オプションは-a
)を確認します。
- GKE の場合は、デプロイ マニフェスト ファイル(
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
)が有効になっていないことを示しています。
Endpoints と ESP に必要なすべてのサービスがプロジェクトで有効になっていることを確認するには、必要なサービスの確認をご覧ください。
必要な権限を確認するを参照して、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 パスが一致しているか確認します。
Google Cloud コンソールで、プロジェクトの [エンドポイント] の [サービス] ページに移動します。
API が複数ある場合は、リクエストの送信先 API を選択します。
[デプロイの履歴] タブをクリックします。
最新のデプロイを選択して、サービス構成を確認します。
呼び出しているメソッドが 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
のトラブルシューティングを行うには:
Google Cloud コンソールで [Logging] ページに移動します。
ページ上部で該当する Google Cloud プロジェクトを選択します。
[Google App Engine Application] を選択して、
vm.syslog
を開きます。次のようなログエントリを探します。
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
エントリがある場合:app.yaml
ファイルに次を追加して、デフォルト VM のサイズを増やします。resources: memory_gb: 4
API を再デプロイします。
gcloud app deploy
app.yaml
ファイルの endpoints_api_service
セクションに rollout_strategy: managed
オプションが指定されている場合は、次のコマンドを使用して API を再デプロイします。
gcloud app deploy
詳細については、API と ESP のデプロイをご覧ください。
Cloud Logging のログを確認する
Cloud Logging のログを使用してレスポンス エラーのトラブルシューティングを行うには、
Google Cloud コンソールで [Logging] ページに移動します。
ページの上部で、Google Cloud プロジェクトを選択します。
左側のプルダウン メニューを使用して、[生成された API] > [YOUR_SERVICE_NAME] を選択します。
レスポンス エラーを示す行が表示されるまで、時間範囲を調整します。
JSON ペイロードを展開し、
error_cause
を探します。error_cause
がapplication
に設定されている場合は、コードに問題があることを示しています。error cause
がそれ以外であり、ご自身で問題を解決できない場合は、ログをエクスポートし、Google へのご連絡の際にご提供ください。
詳しくは以下をご覧ください。
ログ エクスプローラのログの構造について、Endpoints のログ リファレンスを確認する。
ログ エクスプローラの使用を開始する。
高度なログクエリを使用して詳細なフィルタリングを行う(たとえば、レイテンシが 300 ミリ秒を超えるリクエストをすべて取得する)。
サンプルの 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...
- App Engine フレキシブル環境:
- HTTP 動詞として
curl
をダウンロードしてインストールし、コマンド プロンプトで実行します。Windows では一重引用符内にネストされた二重引用符は処理されないため、サンプルの--data
オプションを次のように変更する必要があります。--data "{\"message\":\"hello world\"}"