Cloud Run のトラブルシューティング

このページでは、Cloud Run の使用中に発生するエラー メッセージのトラブルシューティングと問題解決の方法について説明します。

また、公開 Issue Tracker で既存の問題の確認や、新しい問題の報告を行うことができます。

このページに記載されていないその他のエラー メッセージについては、既知の問題ページをご覧ください。

デプロイエラー

このセクションでは、デプロイで発生する可能性がある問題と、その修正方法について説明します。

コンテナを起動できませんでした

デプロイしようとすると、次のエラーが発生します。

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

この問題を解決するには、次のように考えられる原因を排除します。

  1. コンテナ イメージをローカルで実行できることを確認します。コンテナ イメージをローカルで実行できない場合は、問題をローカルで診断して修正する必要があります。

  2. コンテナ ランタイムの契約に記載されているように、コンテナが想定されるポートでリクエストをリッスンしているかどうかを確認します。コンテナは、Cloud Run によって定義され、PORT 環境変数で指定されているポートで受信リクエストをリッスンする必要があります。ポートの指定方法については、コンテナの構成をご覧ください。

  3. コンテナが、すべてのネットワーク インターフェース（通常 0.0.0.0 で表記）でリッスンしているかどうかを確認します。

  4. コンテナ ランタイムの契約に従って、コンテナ イメージを 64 ビット Linux 用にコンパイルされていることを確認します。

  5. Cloud Logging を使用して、stdout ログまたは stderr ログでアプリケーション エラーを探します。また、キャプチャされたクラッシュを Stackdriver Error Reporting で確認することもできます。

    エラーや障害を修正するために、コードまたはリビジョン設定の更新が必要になる場合があります。また、サービスのトラブルシューティングをローカルで行うこともできます。

内部エラー、リソースの準備期限を過ぎています

デプロイまたは別の Google Cloud API の呼び出しを行うと、次のエラーが発生します。

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

この問題は、Cloud Run サービス エージェントが存在しない場合、または Cloud Run サービス エージェント（roles/run.serviceAgent）ロールがない場合に発生することがあります。

Google Cloud プロジェクトに Cloud Run サービス エージェントが存在し、必要なロールが付与されていることを確認するには、次の操作を行います。

  1. Google Cloud コンソールを開きます。

    [権限] ページに移動

  2. [権限] ページの右上にある [Google 提供のロール付与を含みます] チェックボックスをオンにします。

  3. [プリンシパル] リストで、次の ID を使用する Cloud Run サービス エージェントの ID を見つけます。
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com.

  4. サービス エージェントに Cloud Run サービス エージェント ロールが付与されていることを確認します。サービス エージェントにない場合は、このロールを付与します。

エラー: ユーザー root が /etc/passwd に見つかりません

デプロイしようとすると、次のエラーが発生します。

ERROR: "User \"root\""not found in /etc/passwd

この問題は、顧客管理の暗号鍵が --key パラメータを使用して指定された場合に発生します。

この問題を解決するには、Dockerfile で USER root の代わりに USER 0 を指定します。

デフォルトの Compute Engine サービス アカウントが削除されている

デプロイしようとすると、次のエラーが発生します。

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

この問題は、次のいずれかの状況で発生します。

この問題を解決するには:

  1. --service-account gcloud フラグを使用してサービス アカウントを指定します。
  2. 指定したサービス アカウントに、デプロイに必要な権限があることを確認します。

デフォルトの Compute Engine サービス エージェントが Google Cloud プロジェクトに存在するかどうかを確認するには、次の操作を行います。

  1. Google Cloud コンソールを開きます。

    [権限] ページに移動

  2. [権限] ページの右上にある [Google 提供のロール付与を含みます] チェックボックスをオンにします。

  3. [プリンシパル] リストで、次の ID を使用する Compute Engine サービス エージェントの ID を見つけます。
    PROJECT_NUMBER-compute@developer.gserviceaccount.com

Cloud Run サービス エージェントにイメージの読み取り権限がありません

PROJECT-ID-2 の Container Registry に保存されているイメージを使用して PROJECT-ID からデプロイしようとすると、次のエラーが発生します。

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

この問題を解決するには、次のトラブルシューティングの推奨事項を行います。

  • 他の Google Cloud プロジェクトからコンテナ イメージをデプロイする手順に沿って、プリンシパルに必要な権限があることを確認します。

  • この問題は、プロジェクトが VPC Service Controls 境界にあり、Cloud Run サービス エージェントからのリクエストを禁止する制限が Cloud Storage API にある場合にも発生することがあります。この問題を解決する方法は以下のとおりです。

    1. Google Cloud コンソールでログ エクスプローラを開きます（Cloud Run ページの [ログ] ページは使用しないでください）。

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

    2. クエリ フィールドに次のテキストを入力します。

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. このクエリを使用した後にログエントリが表示された場合は、そのログエントリを調べて、VPC Service Controls ポリシーを更新する必要があるかどうかを判断します。既存のアクセス ポリシーに service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com の追加が必要になることもあります。

コンテナのインポート エラー

デプロイしようとすると、次のエラーが発生します。

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

この問題を解決するには、次のように考えられる原因を排除します。

  1. コンテナのファイル システムに UTF-8 以外の文字が含まれていないことを確認してください。

  2. Windows ベースの Docker イメージでは、外部レイヤが使用されます。外部レイヤが存在する場合、Container Registry はエラーをスローしませんが、Cloud Run のコントロール プレーンはこれをサポートしていません。この問題を解決するには、Docker デーモンで --allow-nondistributable-artifacts フラグを設定してみてください。

配信エラー

このセクションでは、配信で発生する可能性がある問題と、その修正方法について説明します。

HTTP 401: クライアントが適切に認証されていない

配信中に次のエラーが発生します。

The request was not authorized to invoke this service

この問題を解決するには:

  • サービス アカウントによって呼び出された場合、Google によって署名された ID トークンのオーディエンス クレーム（aud）を次のように設定する必要があります。

    • 受信側のサービスの Cloud Run URL（形式は https://service-xyz.run.app）。
      • Cloud Run サービスは認証が必要です。
      • Cloud Run サービスは、Cloud Run URL またはロードバランサの URL 経由で呼び出すことができます。
    • ウェブ アプリケーション タイプの OAuth 2.0 クライアント ID のクライアント ID（形式は nnn-xyz.apps.googleusercontent.com）。
    • 指定された値を使用して構成されたカスタム オーディエンス。たとえば、カスタム オーディエンスが service.example.com の場合、オーディエンス クレーム（aud）の値も service.example.com にする必要があります。カスタム オーディエンスが https://service.example.com の場合、オーディエンス クレーム値も https://service.example.com にする必要があります。

  • jwt.io ツールは、JWT でクレームを確認するのに適しています。

  • 認証トークンの形式が無効な場合は、401 エラーが発生します。トークンが有効な形式で、トークンの生成に使用された IAM メンバーに run.routes.invoke 権限がない場合、403 エラーが発生します。

  • メタデータ サーバーから ID とアクセス トークンを取得して、Cloud Run サービスまたはジョブの ID でリクエストの認証を行い、HTTP プロキシによって下り（外向き）トラフィックをルーティングするときに、無効なトークンが取得された場合は、次のホストを HTTP プロキシ例外に追加します。

    • 169.254.* または 169.254.0.0/16
    • *.google.internal

    このエラーは通常、Cloud クライアント ライブラリがメタデータ サーバーからアプリケーションのデフォルト認証情報を取得し、REST または gRPC 呼び出しを認証するときに発生します。HTTP プロキシ例外を定義しない場合、次の動作が発生します。

    • Cloud Run サービスまたはジョブと HTTP プロキシが異なる Google Cloud ワークロードにホストされていると、Google Cloud クライアント ライブラリが認証情報を取得できる場合でも、HTTP プロキシ ワークロードに割り当てられたサービス アカウントのトークンが生成されます。このサービス アカウントには、目的の Google Cloud API オペレーションを実行するために必要な権限がない可能性があります。この場合、トークンは Cloud Run ではなく、HTTP プロキシ ワークロードのメタデータ サーバーのビューから取得されます。

    • HTTP プロキシが Google Cloud でホストされておらず、メタデータ サーバー リクエストがプロキシを使用してルーティングされる場合、トークン リクエストは失敗し、Google Cloud APIs オペレーションは認証されません。

HTTP 403: クライアントにサービスの起動権限または呼び出し権限がない

Cloud Logging に、resource.type = "cloud_run_revision" の次のエラーが存在する場合があります。

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

クライアントに返される HTTP レスポンスには次のエラーが含まれます。

403 Forbidden
Your client does not have permission to get URL from this server.

Cloud Logging に resource.type = "cloud_run_revision" のエラーが存在する場合、次の手順で問題を解決します。

Cloud Logging に resource.type = "cloud_run_revision" のエラーが存在しない場合は、次の手順で問題を解決します。

  • サービスの Ingress が All に構成されていても、VPC Service Controls が原因でブロックされている場合は、403 ステータス コードが返されることがあります。VPC Service Controls の拒否に関するトラブルシューティングの詳細については、次のセクションの 404 エラーをご覧ください。

HTTP 403: ウェブブラウザからサービスにアクセスするときにエラーが発生する

ウェブブラウザから Cloud Run サービスにアクセスすると、次の問題が発生します。

403 Forbidden
Your client does not have permission to get URL from this server.

ウェブブラウザから Cloud Run サービスを呼び出すと、ブラウザはサービスに GET リクエストを送信します。ただし、リクエストには呼び出し元のユーザーの認可トークンが含まれていません。この問題を解決するには、次のいずれかの解決策を選択します。

  • Cloud Run で Identity-Aware Proxy（IAP）を使用します。IAP を使用すると、HTTPS 経由でアクセスされるアプリケーションの一元的な認可レイヤを確立できます。IAP を使用すると、ネットワーク レベルのファイアウォールの代わりに、アプリケーション レベルのアクセス制御モデルを使用できます。IAP を使用して Cloud Run を構成する方法の詳細については、Cloud Run 用に Identity-Aware Proxy を有効にするをご覧ください。

  • 一時的な回避策として、Google Cloud CLI で Cloud Run プロキシを使用して、ウェブブラウザからサービスにアクセスします。次のコマンドを使用して、ローカルでサービスをプロキシできます。

    gcloud run services proxy SERVICE --project PROJECT-ID

    このコマンドを実行すると、Cloud Run は限定公開サービスを http://localhost:8080（または --port で指定したポート）にプロキシし、アクティブなアカウントのトークンまたは指定した別のトークンを提供します。これは、ブラウザでウェブサイトや API を非公開でテストする場合におすすめの方法です。詳細については、限定公開サービスのテストをご覧ください。

  • サービスに対する未認証の呼び出しを許可します。これは、テストを行う場合や、サービスが公開 API またはウェブサイトである場合に便利です。

HTTP 404: 未検出

配信中に次の問題が発生します。

HTTP 404 エラーが発生する。

この問題を解決するには:

  1. Google Cloud コンソールでサービスの詳細ページを確認するか、次のコマンドを実行して、正しい URL をリクエストしていることを確認します。

    gcloud run services describe SERVICE_NAME | grep URL

  2. アプリロジックが 404 エラーコードを返す可能性がある場所を調べます。アプリから 404 が返される場合は、Cloud Logging にそのアプリが表示されます。

  3. 構成したポートで、リクエストを受信する準備が整う前にアプリのリッスンを開始しないようにしてください。

  4. ローカルで実行するときに、アプリが 404 エラーコードを返さないことを確認します。

Cloud Run サービスの上り（内向き）設定が「内部」または「内部と Cloud Load Balancing」に設定されていて、指定したネットワークの制限をリクエストが満たしていない場合は、404 が返されます。これは、Cloud Run サービスのデフォルトの run.app の URL が無効になっていて、クライアントがその run.app の URL でサービスにアクセスしようとした場合にも発生する可能性があります。いずれの場合も、リクエストがコンテナに到達せず、次のフィルタを適用した Cloud Logging には 404 が存在しません。

resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

同じ上り（内向き）設定の場合、プロジェクトと IP アドレスを含む呼び出し元のコンテキストに基づいて、VPC Service Controls がリクエストをブロックする可能性があります。VPC Service Controls のポリシー違反を確認するには:

  1. Google Cloud コンソールでログ エクスプローラを開きます（Cloud Run の [ログ] ページではありません）。

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

  2. クエリ フィールドに次のテキストを入力します。

    resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

  3. このクエリを使用した後にログエントリが表示された場合は、そのログエントリを調べて、VPC Service Controls ポリシーを更新する必要があるかどうかを判断します。

Python ランタイムを使用するロードバランサでサービス エンドポイントにアクセスすると、404 エラーが表示されることもあります。この問題を解決するには、ロードバランサの URL マスクを確認し、ロードバランサに指定した URL パスが Python ソースコードのパスと一致していることを確認します。

HTTP 429: 使用可能なコンテナ インスタンスがない

配信中に次のエラーが発生します。

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

この問題を解決するには、サービスのコンテナ インスタンス数の指標を確認します。使用量が上限に近づいている場合は、この上限の引き上げを検討してください。「インスタンスの最大数」の設定をご覧ください。また、インスタンスが必要な場合は、割り当ての増加をリクエストします。

HTTP 500: Cloud Run がトラフィック レートを管理できない

処理中に次のエラーが発生することがあります。また、サービスがコンテナ インスタンスの上限に達していなくても発生することもあります。

HTTP 500
The request was aborted because there was no available instance

この問題は、次のいずれかが原因で発生する可能性があります。

  • トラフィックが急増している。
  • コールド スタート時間が長い。
  • リクエスト処理時間が長い、またはリクエスト処理時間が急増している。
  • サービスがコンテナ インスタンスの上限（HTTP 429）に達した。
  • Cloud Run サービスに起因する一時的な要因。

この問題を解決するには、上記の問題を解決してください。

これらの問題を解決するとともに、回避策として、指数バックオフを実装してリクエストを再試行し、リクエストがドロップされないようにすることができます。

10 秒の解像度にズームインすると、トラフィックまたはリクエストの処理時間の急激な増加が Cloud Monitoring にのみ表示される可能性があります。

この問題の根本原因が、Cloud Run のみに起因する一時的なエラーの増加にある場合は、サポートにお問い合わせください。

HTTP 501: オペレーションが実装されていない

配信中に次のエラーが発生します。

HTTP 501
Operation is not implemented, or supported, or enabled.

この問題は、Cloud Run ジョブを呼び出すときに間違った REGION を指定した場合に発生します。たとえば、リージョン asia-southeast1 にジョブをデプロイし、southeast1-asia または asia-southeast を使用してジョブを呼び出すと、このエラーが発生する可能性があります。サポートされているリージョンのリストについては、Cloud Run のロケーションをご覧ください。

HTTP 503: デフォルトの認証情報が見つからない

配信中に次のエラーが発生します。

HTTP 503
System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

この問題は、ファイルの欠落、無効な認証情報パス、環境変数の割り当ての誤りなどにより、アプリケーションが正しく認証されない場合に発生します。

この問題を解決するには:

  1. gcloud CLI をインストールして初期化します。

  2. Google アカウントに関連付けられている認証情報を使用して、アプリケーションのデフォルト認証情報（ADC）を設定します。次を使用して ADC を構成します。

      gcloud auth application-default login

    ログイン画面が表示されます。ログインすると、ADC で使用されるローカル認証情報ファイルに認証情報が保存されます。

  3. GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して、Google Cloud プロジェクトでの認証情報の JSON ファイルの保存先を指定します。

詳細については、アプリケーションのデフォルト認証情報を設定するをご覧ください。

HTTP 500 / HTTP 503: コンテナ インスタンスがメモリの上限を超えている

配信中に次のエラーが発生します。

Cloud Logging で:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

この問題を解決するには:

  1. コンテナ インスタンスが使用可能なメモリを超えているかどうかを判断します。varlog/system ログで、関連するエラーを探します。
  2. インスタンスがメモリ制限を超えている場合は、メモリの上限を引き上げることを検討してください。

Cloud Run では、ローカル ファイル システムに書き込まれるファイルは使用可能なメモリにカウントされます。これには、/var/log/* と /dev/log 以外の場所に書き込まれるログファイルも含まれます。

HTTP 503: 不正なレスポンスまたはコンテナ インスタンスの接続に問題がある

配信中に次のいずれかのエラーが発生します。

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

この問題を解決するには、次のトラブルシューティングの推奨事項を行います。

  • Cloud Logging を確認する。Cloud Logging を使用して、ログでメモリ不足エラーを探します。コンテナ インスタンスがメモリの上限を超えているというエラー メッセージが見つかった場合は、この問題を解決するための推奨事項をご覧ください。

  • アプリレベルのタイムアウト。リクエストが Cloud Run で設定されたリクエスト タイムアウトに達する前にエラーコード 503 で終了している場合は、言語フレームワークのリクエスト タイムアウトの設定の更新が必要になることがあります。

  • ダウンストリーム ネットワークのボトルネック。場合によっては、負荷テスト中などに、ダウンストリーム ネットワークのボトルネックの間接的な結果として 503 エラーコードが返されることもあります。たとえば、サービスがサーバーレス VPC アクセス コネクタ経由でトラフィックをルーティングする場合、次の手順を行い、コネクタがスループットのしきい値を超えていないことを確認します。

    1. Google Cloud コンソールでサーバーレス VPC アクセスを開きます。

      サーバーレス VPC アクセスに移動

    2. スループット グラフのヒストグラムで赤色の棒を確認します。赤色のバーが表示されている場合は、コネクタの最大インスタンス数またはインスタンス タイプを増やすことを検討してください。あるいは、サーバーレス VPC アクセス コネクタ経由で送信されたトラフィックを圧縮します。

  • 1 つのコンテナへのインバウンド リクエストの上限。コンテナあたりのリクエスト レートが高いことが 503 エラーの原因となる、既知の問題が存在します。コンテナ インスタンスが 1 秒あたり 800 件を超えるリクエストを受信すると、使用可能な TCP ソケットが枯渇する可能性があります。この問題を是正するには、次のいずれかを試してください。

    1. サービスで HTTP/2 を有効にして、HTTP/2 をサポートするようにサービスに必要な変更を加えます。

    2. 構成されている同時実行を抑制することで、1 つのコンテナ インスタンスに 1 秒あたり 800 件を超えるリクエストが送信されないようにします。コンテナ インスタンスあたりのリクエスト レートの見積もりを計算するには、次の式を使用します。requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

HTTP 503: 同時実行の設定が高いため、一部のリクエストを処理できない

配信中に次のエラーが発生します。

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

この問題は、コンテナ インスタンスがリクエストの処理で大量の CPU を使用し、その結果、コンテナ インスタンスがすべてのリクエストを処理できない場合に発生します。その場合、一部のリクエストで 503 エラーコードが返されます。

この問題を解決するには、次の対処方法をいくつか試してください。

HTTP 504: ゲートウェイ タイムアウト エラー

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

サービスが実行時間の長いリクエストを処理する場合は、リクエストのタイムアウトを長くすることができます。サービスが指定された時間内にレスポンスを返さない場合、コンテナ ランタイムの契約に記載されているように、リクエストは終了し、サービスが HTTP 504 エラーを返します。

この問題をトラブルシューティングするには、次の対処方法をいくつか試してください。

  • ロギングとトレースを計測し、構成したリクエスト タイムアウトの前にアプリで処理に時間がかかっている場所を把握します。

  • インフラストラクチャの更新に伴い、アウトバンド接続がリセットされる場合があります。アプリケーションで長期間の接続を再利用する場合は、切断された接続の再利用を避けるため、接続を再確立してアプリケーションを構成することをおすすめします。

    • アプリのロジックやエラー処理によっては、504 エラーは、アプリケーションが切断された接続を再利用しようとしている信号であり、構成したリクエスト タイムアウトに達するまでリクエストがブロックされる場合があります。
    • livenessProbe を使用すると、永続的なエラーを返すインスタンスを終了できます。

  • アプリのコード内で発生したメモリ不足エラー（java.lang.OutOfMemoryError など）により、コンテナ インスタンスが終了するとは限りません。メモリ使用量がコンテナのメモリ上限を超えていなければ、インスタンスは終了しません。アプリがアプリレベルのメモリ不足エラーを処理する方法によっては、構成したリクエスト タイムアウトになるまでリクエストがハングする可能性があります。

    • 上記のシナリオでコンテナ インスタンスを終了する場合は、アプリレベルのメモリ上限をコンテナメモリの上限よりも大きく構成します。
    • livenessProbe を使用すると、永続的なエラーを返すインスタンスを終了できます。

ピアによって接続がリセットされた

配信中に次のいずれかのエラーが発生します。

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

このエラーは、アプリケーションのネットワーク全体のピアと TCP 接続が確立されていて、そのピアが予期せず接続を閉じたときに発生します。

この問題を解決するには:

  • CPU スロットリングを使用してバックグラウンド処理を実行する場合は、CPU 割り当てを [CPU を常に割り当てる] に設定してみてください。

  • 送信リクエストのタイムアウト内であることを確認してください。アプリケーションの接続がこのしきい値を超えてアイドル状態を持続する場合、ゲートウェイで接続を終了する必要があります。

  • デフォルトでは、Cloud Run の TCP ソケット オプション keepalive は無効になっています。サービスレベルで Cloud Run の keepalive オプションを直接構成する方法はありませんが、新しい TCP ソケット接続を開いたときに、アプリケーションでこの接続に使用しているクライアント ライブラリに応じて適切なソケット オプションを指定することで、ソケット接続ごとに keepalive オプションを有効にできます。

  • インフラストラクチャの更新により、アウトバンド接続がリセットされる場合があります。アプリケーションで長期間の接続を再利用する場合は、切断された接続の再利用を避けるため、接続を再確立してアプリケーションを構成することをおすすめします。

  • HTTP プロキシを使用して Cloud Run サービスまたはジョブの下り（外向き）トラフィックをルーティングし、プロキシが接続の最大期間を適用している場合、接続プールを使用して確立された TCP 接続など、長時間実行される接続がプロキシによって自動的に切断されることがあります。これにより、すでに閉じられた接続を再利用するときに、HTTP クライアントでエラーが発生します。下り（外向き）トラフィックを HTTP プロキシ経由でルーティングする場合は、このシナリオを考慮し、接続の検証、再試行、指数バックオフを実装してください。接続プールの場合、接続の有効期間、アイドル状態の接続、接続のアイドル タイムアウトの最大値を構成します。

接続タイムアウト

リモートホストにリクエストを行うときに接続タイムアウトが発生すると、レイテンシ エラーまたは次のいずれかのエラーが発生します。

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

このようなエラーは、アプリケーションがリモートホストとの新しい TCP 接続の作成を試みて、接続の確立に時間がかかりすぎる場合に発生します。

  • VPC コネクタまたはダイレクト VPC 下り（外向き）を使用してすべての下り（外向き）トラフィックを VPC ネットワーク経由で転送する場合は、次のことを確認してください。

  • HTTP プロキシを使用して Cloud Run サービスまたはジョブからのすべての下り（外向き）トラフィックをルーティングする場合は、プロキシを使用してリモートホストに到達できることを確認してください。

    HTTP プロキシ経由で転送されるトラフィックは、プロキシのリソース使用状況に応じて遅延する可能性があります。プロキシを使用して HTTP 下り（外向き）トラフィックをルーティングする場合は、このシナリオを考慮して、再試行、指数バックオフ、またはサーキット ブレーカーを実装してください。

HTTP プロキシの例外を構成する

HTTP プロキシを使用して Cloud Run サービスまたはジョブの下り（外向き）トラフィックをルーティングする場合は、レイテンシ、接続タイムアウト、接続のリセット、認証エラーを防ぐため、Cloud APIs の例外と、プロキシされないホストとサブネットの例外を追加してください。

プロキシされないホストとサブネットには、少なくとも次のものが含まれている必要があります。

  • 127.0.0.1
  • 169.254.* または 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

プロキシされないホストには、必要に応じて次のものが含まれている場合があります。

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

下り（外向き）ネットワークで HTTP プロキシ例外を構成する一般的な方法は次のとおりです。

  • 環境変数: NO_PROXY または no_proxy。

  • Java 仮想マシンのフラグ: http.nonProxyHosts。

    • システム プロパティ https.nonProxyHosts が定義されていないため、http.nonProxyHosts は HTTP と HTTPS の両方に適用されます。
    • システム プロパティ http.nonProxyHosts は CIDR 表記をサポートしていないため、パターン マッチング式を使用する必要があります。

ID トークンの署名が Google によって編集された

配信中に次のエラーが発生します。

SIGNATURE_REMOVED_BY_GOOGLE

この問題は、次のような状況で開発とテストを行っている場合に発生することがあります。

  1. ユーザーが Google Cloud CLI または Cloud Shell を使用してログインする。
  2. ユーザーが gcloud コマンドを使用して ID トークンを生成する。
  3. ユーザーが、ID トークンを使用して非公開の Cloud Run サービスを呼び出そうとしている。

これは意図的なものです。Google では、このように生成された ID トークンが非公開の Cloud Run サービスを再生しないように、セキュリティの懸念からトークン署名を削除します。

この問題を解決するには、新しい ID トークンで限定公開サービスを呼び出します。詳細については、サービスでの認証のテストをご覧ください。

ログでの OpenBLAS 警告

NumPy などの OpenBLAS ベースのライブラリを第 1 世代の実行環境で使用している場合、次の警告がログに記録されることがあります。

OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k

これは警告であり、サービスへの影響はありません。第 1 世代の実行環境で使用されるコンテナ サンドボックスでは低レベルのハードウェア機能が公開されていないため、この警告が発生します。この警告をログに記録したくない場合は、第 2 世代の実行環境に切り替えることもできます。

バインドするマシンの IP アドレスを取得する際に Spark が失敗する

配信中に次のいずれかのエラーが発生します。

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

この問題を解決するには:

環境変数値を変更して問題を解決するには、Dockerfile で ENV SPARK_LOCAL_IP="127.0.0.1" を設定します。Cloud Run では、変数 SPARK_LOCAL_IP が設定されていない場合、デフォルトは localhost ではなく IPv6 になります。RUN export SPARK_LOCAL_IP="127.0.0.1" の設定は実行時には使用できず、Spark は未設定の場合と同様に動作します。

カスタム ドメインのマッピング

カスタム ドメインが証明書プロビジョニング中の状態で停止しています

カスタム ドメインをマッピングしようとすると、次のエラーのいずれかが発生します。

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

この問題を解決するには:

  • 24 時間以上経過するまで待ちます。SSL 証明書のプロビジョニングには通常 15 分ほどかかりますが、場合によっては最長で 24 時間ほどかかることがあります。

  • Google 管理者ツールボックスの Dig ツールを使用して、ドメイン登録事業者で DNS レコードが正しく更新されたことを確認します。

    ドメイン登録事業者の DNS レコードは、Google Cloud コンソールが追加を促すものと一致する必要があります。

  • 次のいずれかの方法を使用して、アカウントでドメインのルートが検証されていることを確認します。

  • ドメインの証明書の有効期限が切れていないことを確認します。有効期限の範囲を確認するには、次のコマンドを使用します。

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

管理 API

この機能は宣言されたリリース段階でサポートされていません

Cloud Run Admin API を呼び出すと、次のエラーが発生します。

The feature is not supported in the declared launch stage

このエラーは、Cloud Run Admin API を直接呼び出して、リリース ステージのアノテーションまたはフィールドを指定せずにベータ版機能を使用した場合に発生します。

この問題を解決するには、リクエストにリリース ステージ フィールドを追加します。以下に、v1 REST API と v2 REST API の例を示します。

次の例では、JSON と v1 REST API を使用して、リリース ステージのアノテーションをクライアント リクエストに追加しています。

    "annotations": {
      "run.googleapis.com/launch-stage": "BETA"
    }

次の例では、JSON と v2 REST API を使用して、LaunchStage の参照をクライアント リクエストに追加しています。

  "launchStage": "BETA"

次の例では、YAML と v1 REST API を使用して、リリース ステージのアノテーションをサービス リクエストに追加しています。

kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: BETA

クライアントの接続解除が Cloud Run に反映されない

Cloud Run で HTTP/1.1 を使用すると、クライアントの接続解除イベントが Cloud Run コンテナに反映されません。

解決策は、クライアントの接続解除が伝播する WebSocket または HTTP/2.0 を使用することです。

ネットワーク ファイル システムのトラブルシューティング

ネットワーク ファイル システムの使用に関する詳細はこちらをご覧ください。

NFS を使用してファイルにアクセスできない

エラー 推奨される対処方法
mount.nfs: Protocol not supported debian や adoptopenjdk/openjdk11 などの一部のベースイメージで、依存関係 nfs-kernel-server が欠落しています。
mount.nfs: Connection timed out 接続がタイムアウトした場合は、filestore インスタンスの正しい IP アドレスを指定していることを確認します。
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE アクセスがサーバーから拒否された場合は、ファイル共有名が正しいことを確認します。

Cloud Storage FUSE を使用してファイルにアクセスできない

Cloud Storage FUSE のトラブルシューティング ガイドをご覧ください。