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

このページでは、Cloud Run の問題を解決する方法について説明します。

以下に記載されていない問題については、既知の問題かどうかを確認してください。

デプロイエラー

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

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

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

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 エラーが発生します。

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 404: 未検出

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

HTTP 404 エラーが発生する。

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

  1. 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 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 ポリシーを更新する必要があるかどうかを判断します。

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 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 オプションを有効にできます。

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

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 を直接呼び出して、リリース段階アノテーションを指定せずにベータ版機能を使用する場合に発生します。

ベータ版機能が使用されている場合は、リクエストの BETA の run.googleapis.com/launch-stage 値でリソースにアノテーションを設定して、この問題を解決します。

次の例では、サービス リクエストにリリース段階アノテーションを追加します。

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

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

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

解決策は、クライアントの接続解除が伝播される 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 のトラブルシューティング ガイドをご覧ください。