Cloud Run 문제 해결

이 페이지에서는 Cloud Run을 사용하는 동안 발생할 수 있는 오류를 해결하는 방법을 설명합니다. Personalized Service Health는 프로젝트에 영향을 미치는 Google Cloud 서비스 중단을 식별하기 위해 기본 Google Cloud 인프라에서 발생한 모든 Cloud Run 이슈를 게시합니다. Personalized Service Health 이벤트에 알림을 설정하는 것도 고려해 보세요. 모든 Google Cloud 서비스에 영향을 미치는 이슈에 대한 자세한 내용은 Google Cloud Service Health 대시보드를 참고하세요.

공개 Issue Tracker에서 기존 문제를 확인하거나 새 문제를 개설합니다.

이 페이지에 나열되지 않은 다른 오류 메시지는 Cloud Run의 알려진 문제를 참고하세요. 이 가이드의 단계를 따르고도 오류가 계속 발생하면 지원팀에 문의하세요.

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으로 표시된 모든 네트워크 인터페이스에서 리슨하는지 확인합니다. 특히 컨테이너는 127.0.0.1에서 리슨하면 안 됩니다.

  4. 컨테이너 이미지가 컨테이너 런타임 계약에 따라 64비트 Linux용으로 컴파일되었는지 확인합니다.

  5. Cloud Logging을 사용하여 stdout 또는 stderr 로그에서 애플리케이션 오류를 찾습니다. Error Reporting에서 캡처된 장애를 찾을 수도 있습니다.

    오류나 장애를 수정하려면 코드 또는 버전 설정을 업데이트해야 합니다. 로컬에서 서비스 문제를 해결할 수도 있습니다.

컨테이너 가져오기 오류입니다.

배포를 시도할 때 다음 오류가 발생합니다.

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

이 문제를 해결하려면 다음 단계를 따르세요.

  1. 컨테이너의 파일 시스템에 utf8 이외의 문자가 포함되어 있지 않은지 확인합니다.

  2. 일부 Windows 기반 Docker 이미지는 외부 레이어를 사용합니다. Cloud Run의 컨트롤 플레인은 외부 레이어를 지원하지 않습니다. 이 문제를 해결하려면 Docker 데몬에서 --allow-nondistributable-artifacts 플래그를 설정해 볼 수 있습니다.

지원되지 않는 기능입니다.

Cloud Run Admin API를 호출할 때 다음 오류가 발생합니다.

The feature is not supported in the declared launch stage

이 오류는 Cloud Run Admin API를 직접 호출할 때 출시 단계 주석 또는 필드를 지정하지 않고 베타 기능을 사용하면 발생합니다.

이 문제를 해결하려면 요청에 출시 단계 필드를 추가합니다.

v1 또는 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

사용자 root를 찾을 수 없습니다.

--key 매개변수를 사용하여 고객 관리 암호화 키를 지정하면 다음 오류가 발생합니다.

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

이 문제를 해결하려면 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).

이 문제는 다음 시나리오 중 하나에서 발생합니다.

  • 배포 시 프로젝트에 기본 Compute Engine 서비스 계정이 존재하지 않으며 --service-account 플래그로 서비스 계정이 지정되지 않았습니다.

  • 서비스를 배포하는 개발자 또는 주 구성원이 배포할 기본 Compute Engine 서비스 계정에 대한 필요한 권한이 없습니다.

이 문제를 해결하려면 다음 안내를 따르세요.

  1. --service-account 플래그를 사용하여 서비스 계정을 지정합니다.

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT
    
  2. 지정한 서비스 계정에 배포에 필요한 권한이 있는지 확인합니다.

Google Cloud 프로젝트에 기본 Compute Engine 서비스 에이전트가 있는지 확인하려면 다음 단계를 따르세요.

  1. Google Cloud 콘솔에서 Identity and Access Management 권한 페이지로 이동합니다.

    권한으로 이동

  2. Google 제공 역할 부여 포함 체크박스를 선택합니다.

  3. 주 구성원 목록에서 PROJECT_NUMBER-compute@developer.gserviceaccount.com 형식을 따르는 Compute Engine 서비스 에이전트의 ID를 찾습니다.

Cloud Build 서비스 계정 문제

Cloud Build 서비스 계정에 필요한 권한이 없거나 사용 중지된 경우 소스 배포 중에 다음과 같은 오류가 발생합니다.

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build가 새 프로젝트에서 서비스 계정을 사용하는 방법에 대한 기본 동작이 변경되었습니다. Cloud Build 기본 서비스 계정 변경에 자세히 설명되어 있습니다. 이러한 변경사항으로 인해 처음으로 소스 코드에서 Cloud Run에 배포하는 새 프로젝트는 소스에서 배포할 수 있는 권한이 부족한 기본 Cloud Build 서비스 계정을 사용할 수 있습니다.

이 문제를 해결하려면 다음 단계를 따르세요.

  • 기본 서비스 계정 변경에 대한 Cloud Build 안내를 검토하고 변경사항을 선택 해제합니다.

  • 빌드 서비스 계정에 Cloud Run 빌더(roles/run.builder) 역할을 부여합니다.

Cloud Run 서비스 에이전트에 이미지를 읽을 권한이 없음

Artifact Registry에 저장된 이미지를 사용하여 다른 프로젝트의 gcr.io 도메인을 사용하여 프로젝트에서 배포하려고 하면 다음 오류가 발생합니다.

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.

다른 프로젝트의 Artifact Registry에 저장된 이미지를 사용하여 프로젝트에서 배포하려고 하면 다음 오류가 표시될 수도 있습니다.

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the 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 the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

이 문제를 해결하려면 다음 문제 해결 권장사항을 따르세요.

  • 다른 Google Cloud 프로젝트에서 컨테이너 이미지를 배포하는 안내에 따라 주 구성원에게 필요한 권한이 있는지 확인합니다.

  • 이 문제는 프로젝트가 Cloud Run 서비스 에이전트의 요청을 금지하는 Cloud Storage API의 제한이 있는 VPC 서비스 제어 경계 내에 있는 경우에도 발생할 수 있습니다. 이 문제를 해결하려면 다음 안내를 따르세요.

    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-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com을 추가해야 할 수도 있습니다.

소스 배포에 대한 권한 누락

소스에서 배포할 때 다음과 같은 오류가 발생할 수 있습니다.

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

모든 Cloud Run 서비스는 서비스가 다른 리소스에 액세스할 때 ID로 제공되는 서비스 계정과 연결됩니다. 이 서비스 계정은 기본 서비스 계정(PROJECT_NUMBER-compute@developer.gserviceaccount.com) 또는 사용자 관리 서비스 계정일 수 있습니다.

여러 서비스가 서로 다른 리소스에 액세스하는 환경에서는 기본 서비스 계정 대신 서로 다른 사용자 관리 서비스 계정으로 서비스별 ID를 사용할 수 있습니다.

이 문제를 해결하려면 서비스 ID로 사용되는 서비스 계정에서 배포 계정에 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여합니다. 이 사전 정의된 역할에는 서비스나 버전에서 서비스 계정을 연결하는 데 필요한 iam.serviceAccounts.actAs 권한이 포함되어 있습니다. 사용자 관리형 서비스 계정을 만드는 사용자에게는 iam.serviceAccounts.actAs 권한이 자동으로 부여되지만 다른 배포자의 경우 사용자 관리형 서비스 계정을 만드는 사용자로부터 이 권한을 부여 받아야 합니다.

새로 만드는 서비스 계정의 액세스 요구사항에 관한 자세한 내용은 전용 서비스 계정 만들기 권장사항 가져오기를 참조하세요.

소스 배포를 완료할 권한이 사용자에게 없습니다.

배포자 계정에 프로젝트에 필요한 권한이 없으면 다음과 같은 오류가 발생합니다.

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

이 오류를 해결하려면 관리자에게 다음 Identity and Access Management 역할을 부여해 달라고 요청하세요.

제공 오류

이 섹션에는 제공에서 발생할 수 있는 문제를 나열하고 각 문제를 해결하는 방법에 대한 제안을 제공합니다.

HTTP 404: 찾을 수 없음

제공 중에 다음 문제가 발생합니다.

`HTTP 404`:Not found

다음 시나리오에서 HTTP 404 오류가 발생할 수 있습니다.

  1. 잘못된 요청 URL 또는 애플리케이션 코드는 404 오류를 반환합니다. 이 문제를 해결하려면 다음 단계를 따르세요.

    1. 요청한 URL이 올바른지 확인합니다. Google Cloud 콘솔의 서비스 세부정보 페이지에서 또는 다음 명령어를 실행하여 URL을 확인할 수 있습니다.

      gcloud run services describe SERVICE_NAME | grep URL
      
    2. 앱에서 404 오류 코드를 반환하는 위치를 검사합니다. 앱이 404를 반환하면 Cloud Logging에서 확인할 수 있습니다. 또한 로컬에서 실행할 때 앱이 404 오류 코드를 반환하지 않는지 확인합니다.

    3. 앱에서 요청을 수신할 준비를 하기 전에 구성된 포트에서 수신을 시작하지 않는지 확인하세요.

  2. 요청이 컨테이너에 도달하지 않아 다음 시나리오에서 404 오류가 발생합니다.

    • 요청이 지정된 네트워크 제한을 충족하지 않습니다. 특히 Cloud Run 서비스의 인그레스 설정내부 또는 내부 및 Cloud Load Balancing으로 설정된 경우 더욱 그렇습니다.

    • 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
    
  3. 동일한 인그레스 설정을 사용할 경우 프로젝트 및 IP 주소를 포함한 호출자의 컨텍스트에 따라 VPC 서비스 제어가 요청을 차단할 수 있습니다. VPC 서비스 제어 정책 위반을 확인하려면 다음 안내를 따르세요.

    1. Google Cloud 콘솔에서 로그 탐색기를 엽니다.

      로그 탐색기로 이동

    2. 쿼리 필드에 다음 텍스트를 입력합니다.

      resource.type="audited_resource"
      log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
      resource.labels.method="run.googleapis.com/HttpIngress"
      
    3. 이 쿼리를 사용한 후 로그 항목이 표시되면 로그 항목을 검사하여 VPC 서비스 제어 정책을 업데이트해야 하는지 확인합니다.

  4. Python 런타임을 사용하여 부하 분산기로 서비스 엔드포인트에 액세스합니다. 이 문제를 해결하려면 부하 분산기의 URL 마스크를 확인하고 부하 분산기에 지정하는 URL 경로가 Python 소스 코드의 경로와 일치하는지 확인합니다.

사용 가능한 컨테이너 인스턴스 없음

제공 중에 다음 오류가 발생합니다.

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.

이 문제를 해결하려면 서비스의 컨테이너 인스턴스 수 측정항목을 확인하고 사용량이 최대값에 근접하면 이 제한을 늘릴 수 있습니다. 자세한 내용은 서비스의 최대 인스턴스 설정을 참고하고 추가 인스턴스가 필요한 경우 할당량 증가를 요청하세요.

Cloud Run이 트래픽 속도를 관리할 수 없음

다음 오류는 서비스를 제공하는 동안 발생하거나 서비스가 최대 컨테이너 인스턴스 한도에 도달하지 않은 경우 발생합니다.

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

이 문제를 해결하려면 다음 단계를 따르세요.

  1. 다음과 같은 가능한 근본 원인을 해결하세요.

    • 트래픽 급증
    • 콜드 스타트 시간
    • 긴 요청 처리 시간 또는 요청 처리 시간의 갑작스러운 증가
    • 서비스가 최대 컨테이너 인스턴스 한도(HTTP 429)에 도달한 경우
    • Cloud Run 서비스로 인한 일시적 요소
  2. 클라이언트가 삭제해서는 안 되는 요청에 대해 지수 백오프 및 재시도를 구현합니다. 트래픽 또는 요청 처리 시간이 짧고 갑작스럽게 증가하면 10초 해상도로 확대한 경우에만 Cloud Monitoring에 표시될 수 있습니다.

  3. 문제의 근본 원인이 Cloud Run만으로 인해 증가된 일시적인 오류 기간인 경우 지원팀에 문의할 수 있습니다.

작업이 구현되지 않음

Cloud Run 작업을 호출하는 동안 잘못된 REGION을 지정하면 다음 오류가 발생합니다(예: asia-southeast1 리전에 작업을 배포하고 southeast1-asia 또는 asia-southeast를 사용하여 작업을 호출하는 경우).

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

지원되는 리전 목록은 Cloud Run 위치를 참조하세요.

기본 사용자 인증 정보를 찾을 수 없음

누락된 파일, 유효하지 않은 사용자 인증 정보 경로, 잘못된 환경 변수 할당으로 인해 애플리케이션이 올바르게 인증되지 않으면 다음 오류가 발생합니다.

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 파일의 위치를 제공합니다.

    자세한 내용은 애플리케이션 기본 사용자 인증 정보 설정을 참조하세요.

컨테이너 인스턴스가 메모리 한도를 초과함

Cloud Logging에서 제공 중에 다음 HTTP 500 또는 HTTP 503 오류가 발생합니다.

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를 제외한 위치에 기록된 모든 로그 파일도 포함됩니다.

높은 동시 실행 설정으로 인해 일부 요청을 처리할 수 없음

컨테이너 인스턴스가 높은 CPU 부하를 사용하여 결과적으로 일부 요청을 처리할 수 없는 경우 다음 오류가 발생합니다.

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

이 문제를 해결하려면 다음 단계를 따르세요.

  1. 서비스의 최대 컨테이너 인스턴스 수를 늘립니다.

  2. 서비스의 동시 실행을 줄입니다. 자세한 내용은 인스턴스당 최대 동시 요청 수 설정을 참조하세요.

대기 중인 큐 요청 취소와 관련된 Cloud Logging 오류

Cloud Run이 트래픽을 관리할 수 있을 만큼 빠르게 확장되지 않으면 다음 오류 중 하나가 발생합니다.

  • The request was aborted because there was no available instance:
    severity=WARNING ( Response code: 429 ) Cloud Run cannot
    scale due to the max-instances limit you set
    during configuration.
    
  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
    cannot manage the rate of traffic.
    

이 문제를 해결하려면 다음 단계를 따르세요.

  1. 다음과 같이 확장 실패를 일으킬 수 있는 근본 원인을 해결합니다.

    • 트래픽 급증
    • 콜드 스타트 시간
    • 긴 요청 처리 시간
    • 높은 소스 코드 오류율
    • 최대 인스턴스 한도에 도달하여 시스템이 확장되지 않음
    • Cloud Run 서비스로 인한 일시적 요소

    확장 문제 해결 및 성능 최적화에 관한 자세한 내용은 일반적인 개발 팁을 참고하세요.

  2. HTTP 트리거 기반 서비스 또는 함수의 경우 클라이언트가 삭제해서는 안 되는 요청에 대해 지수 백오프 및 재시도를 구현하도록 합니다. Workflows에서 서비스를 트리거하는 경우 try/retry 문법을 사용하여 이를 수행할 수 있습니다.

  3. 백그라운드 또는 이벤트 기반 서비스 또는 함수의 경우 Cloud Run은 최소 1회 전송을 지원합니다. 재시도를 명시적으로 사용 설정하지 않아도 Cloud Run은 자동으로 이벤트를 다시 전송하고 실행을 재시도합니다. 자세한 내용은 이벤트 기반 함수 재시도를 참조하세요.

  4. 콜드 스타트와 관련된 문제의 경우 최소 인스턴스를 구성하여 청구에 더 큰 영향을 미치는 콜드 스타트 수를 줄입니다.

  5. 문제의 근본 원인이 Cloud Run만으로 인해 증가된 일시적인 오류 기간이거나 해당 문제에 대한 도움이 필요한 경우 지원팀에 문의하세요.

Google에서 수정한 ID 토큰 서명

개발 및 테스트 단계 중에 다음 오류가 발생합니다.

SIGNATURE_REMOVED_BY_GOOGLE

이 오류는 다음 시나리오에서 발생할 수 있습니다.

  • 사용자가 Google Cloud CLI 또는 Cloud Shell을 사용하여 로그인합니다.

  • 사용자가 gcloud 명령어를 사용하여 ID 토큰을 생성합니다.

  • 사용자가 ID 토큰을 사용하여 비공개 Cloud Run 서비스를 호출합니다.

이는 예상되는 기본 동작입니다. Google에서는 보안 문제로 인해 토큰 서명을 삭제하여 비공개 Cloud Run 서비스가 이러한 방식으로 생성된 ID 토큰을 재생하지 못하도록 합니다.

이 문제를 해결하려면 새 ID 토큰으로 비공개 서비스를 호출하세요. 자세한 내용은 비공개 서비스 테스트를 참고하세요.

로그의 OpenBLAS 경고

1세대 실행 환경에서 NumPy와 같은 OpenBLAS 기반 라이브러리를 사용하는 경우 로그에 다음과 같은 경고가 표시될 수 있습니다.

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

OpenBLAS 경고는 1세대 실행 환경에서 사용하는 컨테이너 샌드박스가 낮은 수준의 하드웨어 기능을 노출하지 않을 때 발생합니다. 이 경고는 서비스에 영향을 미치지 않습니다. OpenBLAS 경고 로그 항목을 방지하려면 2세대 실행 환경으로 전환하세요.

결합할 머신의 IP 주소를 가져올 때 Spark가 실패함

바인딩 머신의 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에서 SPARK_LOCAL_IP 환경 변수를 127.0.0.1(예: ENV SPARK_LOCAL_IP="127.0.0.1")로 설정합니다. SPARK_LOCAL_IP 환경 변수를 설정하지 않으면 기본값은 localhost 대신 이에 대응하는 IPv6 환경 변수로 설정됩니다. 또한 Spark는 RUN export SPARK_LOCAL_IP="127.0.0.1"로 설정된 환경 변수를 인식하지 않습니다.

NFS를 사용하여 파일에 액세스할 수 없음

오류 권장 해결 방법
mount.nfs: Protocol not supported 일부 기본 이미지(예: debianadoptopenjdk/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 문제 해결 가이드를 참조하세요.

연결 및 보안 오류

이 섹션에서는 Cloud Run의 일반적인 연결 및 보안 오류와 이를 해결하는 방법을 설명합니다.

클라이언트가 제대로 인증되지 않음

제공 중에 다음 오류가 발생합니다.

HTTP 401: The request was not authorized to invoke this service

이 문제를 해결하려면 다음 안내를 따르세요.

  1. 서비스 계정이 Cloud Run 서비스를 호출하는 경우 Google이 서명한 ID 토큰의 대상 클레임(aud)을 다음과 같이 설정합니다.

    • audhttps://SERVICE.run.app 또는 https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION 형식을 사용하여 수신 서비스의 URL로 설정하는 경우 서비스에 인증이 필요합니다. Cloud Run URL을 사용하거나 부하 분산기 URL을 통해 Cloud Run 서비스를 호출합니다. 인증된 요청을 전송하는 예는 HTTPS 요청으로 호출을 참조하세요.

    • nnn-xyz.apps.googleusercontent.com 형식을 사용하여 aud웹 애플리케이션 유형으로 OAuth 2.0 클라이언트 ID의 클라이언트 ID로 설정하면 IAP로 보호되는 HTTPS 부하 분산기를 통해 Cloud Run 서비스를 호출할 수 있습니다. 여러 리전의 Cloud Run 서비스로 지원되는 애플리케이션 부하 분산기에는 이 접근 방식을 사용하는 것이 좋습니다.

    • 구성된 커스텀 대상으로 aud를 설정하는 경우 제공된 정확한 값을 사용합니다. 예를 들어 커스텀 대상이 https://service.example.com이면 대상 클레임 값도 https://service.example.com이어야 합니다.

  2. 요청에 Authorization: Bearer ID_TOKEN 헤더 또는 커스텀 승인을 위한 X-Serverless-Authorization: Bearer ID_TOKEN 헤더가 포함되어 있고 토큰이 액세스 또는 갱신 토큰이 아닌 ID 토큰인지 확인합니다. 다음 시나리오에서는 잘못된 승인 형식으로 인해 401 오류가 발생할 수 있습니다.

    • 인증 토큰의 형식이 잘못되었습니다.

    • 승인 헤더가 유효한 서명이 있는 JSON 웹 토큰(JWT)이 아닙니다.

    • 승인 헤더에 여러 JWT가 포함되어 있습니다.

    • 요청에 여러 인증 헤더가 있습니다.

    JWT에 대한 클레임을 확인하려면 jwt.io 도구를 사용하세요.

  3. 메타데이터 서버를 사용하여 Cloud Run 서비스의 요청을 인증하기 위해 ID 및 액세스 토큰을 가져올 때 잘못된 토큰을 받거나 HTTP 프록시를 사용하여 이그레스 트래픽을 라우팅하는 작업 ID가 잘못된 경우, 다음 호스트를 HTTP 프록시 예외에 추가합니다.

    • 169.254.* 또는 169.254.0.0/16

    • *.google.internal

  4. 401 오류는 일반적으로 Cloud 클라이언트 라이브러리에서 REST 또는 gRPC 호출을 인증하기 위해 메타데이터 서버를 사용하여 애플리케이션 기본 사용자 인증 정보를 가져올 때 발생합니다. HTTP 프록시 예외를 정의하지 않으면 다음 동작이 발생합니다.

    • 서로 다른 Google Cloud 워크로드가 Cloud Run 서비스 또는 작업과 HTTP 프록시를 호스팅하는 경우 Cloud 클라이언트 라이브러리에서 사용자 인증 정보를 가져오더라도 HTTP 프록시 워크로드에 할당된 서비스 계정에서 토큰을 생성합니다. 토큰에 의도한 Google Cloud API 작업을 실행하는 데 필요한 권한이 없을 수 있습니다. 이는 서비스 계정이 Cloud Run 서비스 또는 작업이 아닌 HTTP 프록시 워크로드의 메타데이터 서버 뷰에서 토큰을 가져오기 때문입니다.

    • HTTP 프록시가 Google Cloud에서 호스팅되지 않고 프록시를 사용하여 메타데이터 서버 요청을 라우팅하는 경우 토큰 요청이 실패하고 Google Cloud API 작업이 인증되지 않습니다.

  5. 조직에서 지원하는 경우 인증되지 않은 호출을 허용하도록 서비스를 재배포합니다. 이는 테스트에 유용합니다.

클라이언트에 서비스 호출 권한이 없음

서비스를 호출하는 중에 다음 오류 중 하나가 발생합니다.

HTTP 403: 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.

인증 토큰을 생성하는 데 사용된 IAM 멤버에 run.routes.invoke 권한이 없으면 403 오류가 발생할 수 있습니다. 토큰을 생성하는 사용자에게 이 권한을 부여합니다.

또한 Cloud Logging에 resource.type = "cloud_run_revision" 형식의 오류 항목이 있는 경우 다음 단계에 따라 오류를 해결하세요.

  1. 누구나 서비스를 호출할 수 있도록 하려면 IAM 설정을 업데이트하고 서비스를 공개합니다.

  2. 특정 ID로만 서비스를 호출할 수 있도록 하려면 적절한 승인 토큰으로 서비스를 호출하세요.

    • 개발자 또는 최종 사용자가 서비스를 호출하는 경우 run.routes.invoke 권한을 부여합니다. Cloud Run 관리자(roles/run.admin) 및 Cloud Run 호출자(roles/run.invoker) 역할을 통해 이 권한을 제공할 수 있습니다.

    • 서비스 계정에서 서비스를 호출하는 경우 서비스 계정이 Cloud Run 서비스의 구성원인지 확인하고 Cloud Run 호출자(roles/run.invoker) 역할을 부여합니다.

    • 인증 토큰이 누락된 호출은 403 오류를 일으킬 수 있습니다. 유효한 인증 토큰을 사용하여 호출해도 여전히 403 오류가 발생하면 토큰을 생성하는 IAM 멤버에게 run.routes.invoke 권한을 부여합니다.

403 오류가 발생하고 로그 항목 resource.type = "cloud_run_revision"이 표시되지 않으면 VPC 서비스 제어에서 All로 구성된 인그레스 설정이 있는 Cloud Run 서비스를 차단했기 때문일 수 있습니다. VPC 서비스 제어 거부 문제 해결에 관한 자세한 내용은 404 오류를 참조하세요.

웹브라우저에서 서비스에 액세스할 때 오류 발생

웹브라우저에서 Cloud Run 서비스에 액세스할 때 다음 문제가 발생합니다.

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

웹브라우저에서 Cloud Run 서비스를 호출하면 브라우저가 서비스에 GET 요청을 전송합니다. 하지만 요청에 호출 사용자의 승인 토큰이 포함되지 않았습니다. 이 문제를 해결하려면 다음 단계를 따르세요.

  1. Cloud Run에서 IAP(Identity-Aware Proxy)를 사용합니다. IAP를 사용하면 HTTPS를 통해 액세스되는 애플리케이션에 대해 중앙 승인 레이어를 설정할 수 있습니다. IAP를 사용하면 네트워크 수준 방화벽 대신 애플리케이션 수준 액세스 제어 모델을 사용할 수 있습니다. IAP로 Cloud Run 구성에 대한 자세한 내용은 Cloud Run용 IAP(Identity-Aware Proxy) 사용 설정을 참조하세요.

  2. 임시 해결 방법으로 Google Cloud CLI에서 Cloud Run 프록시를 사용하여 웹브라우저를 통해 서비스에 액세스합니다. 로컬에서 서비스를 프록시하려면 다음 명령어를 실행합니다.

    gcloud run services proxy SERVICE --project PROJECT-ID
    

    Cloud Run은 비공개 서비스를 http://localhost:8080 (또는 --port로 지정한 포트)에 프록시하고 활성 계정의 토큰 또는 다른 지정 토큰을 제공합니다. 이는 브라우저에서 웹사이트 또는 API를 비공개로 테스트하는 데 권장되는 방법입니다. 자세한 내용은 비공개 서비스 테스트를 참조하세요.

  3. 서비스에 대해 인증되지 않은 호출을 허용합니다. 이 방법은 테스트를 수행하거나 서비스가 공개 API 또는 웹사이트인 경우에 유용합니다.

피어에서 연결 재설정

네트워크 상의 피어가 애플리케이션에서 설정한 TCP 연결을 예기치 않게 닫으면 다음 오류 중 하나가 발생합니다.

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

이 문제를 해결하려면 다음 단계를 따르세요.

  • CPU 제한을 통해 백그라운드 작업을 수행하려는 경우 인스턴스 기반 결제 설정을 사용하세요.

  • 아웃바운드 요청 제한 시간 내에 있는지 확인합니다. 애플리케이션이 이 기준을 넘어 유휴 상태로 연결을 유지하는 경우 게이트웨이가 연결을 수거해야 합니다.

  • 기본적으로 Cloud Run에는 TCP 소켓 옵션 keepalive가 사용 중지되어 있습니다. 서비스 수준에서 keepalive 옵션을 직접 구성할 수 있는 방법은 없습니다. 각 소켓 연결에 대해 keepalive 옵션을 사용 설정하려면 애플리케이션에서 이 연결에 사용 중인 클라이언트 라이브러리에 따라 새 TCP 소켓 연결을 열 때 필요한 소켓 옵션을 제공합니다.

  • 인프라 업데이트로 인해 가끔 아웃바운드 연결이 재설정됩니다. 애플리케이션이 장기간 연결을 재사용하는 경우 끊어진 연결이 재사용되지 않도록 애플리케이션을 구성하여 연결을 다시 설정하는 것이 좋습니다.

  • HTTP 프록시를 사용하여 Cloud Run 서비스 또는 작업 이그레스 트래픽을 라우팅하고 프록시에서 최대 연결 기간을 적용하는 경우 프록시에서 연결 풀링을 통해 설정된 TCP 연결과 같은 장기 실행 TCP 연결을 자동으로 삭제할 수 있습니다. 이로 인해 이미 종료된 연결을 재사용하면 HTTP 클라이언트가 실패합니다. HTTP 프록시를 통해 이그레스 트래픽을 라우팅하려면 연결 검증, 재시도, 지수 백오프를 구현해야 합니다. 연결 풀에 연결 수명, 유휴 상태 연결, 연결 유휴 상태 제한 시간의 최댓값을 구성합니다.

연결 제한 시간

애플리케이션에서 원격 호스트로 새 TCP 연결을 만들려고 하는데 연결 설정 시간이 너무 오래 걸리면 다음 오류가 발생합니다.

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

연결 시간 초과 문제를 해결하려면 다음 단계를 따르세요.

  1. VPC 커넥터 또는 직접 VPC 이그레스를 사용하여 VPC 네트워크를 통해 모든 이그레스 트래픽을 라우팅하는 경우 다음 단계를 따르세요.

    • VPC 커넥터의 인그레스 트래픽을 허용하는 데 필요한 모든 방화벽 규칙을 정의합니다.

    • VPC 방화벽 규칙은 VPC 커넥터나 직접 VPC 이그레스 서브넷의 인그레스 트래픽이 대상 호스트나 서브넷에 도달하도록 허용합니다.

    • 대상 호스트와 그 반대로 올바른 트래픽 라우팅을 허용하기 위한 모든 필수 경로가 있는지 확인합니다. 이는 패킷이 원격 호스트에 도달하기 전에 여러 네트워크를 통과하므로 VPC 네트워크 피어링 또는 하이브리드 클라우드 연결을 통해 이그레스 트래픽을 라우팅할 때 중요합니다.

  2. HTTP 프록시를 사용하여 Cloud Run 서비스나 작업의 모든 이그레스 트래픽을 라우팅하는 경우 프록시를 사용하여 원격 호스트에 연결할 수 있어야 합니다.

    HTTP 프록시를 통해 라우팅되는 트래픽은 프록시의 리소스 사용률에 따라 지연될 수 있습니다. 프록시를 사용하여 HTTP 이그레스 트래픽을 라우팅하는 경우 재시도, 지수 백오프 또는 회로 차단기를 구현합니다.

HTTP 프록시 예외 구성

HTTP 프록시를 사용하여 Cloud Run 서비스 또는 작업 이그레스 트래픽을 라우팅하는 경우 지연 시간, 연결 제한 시간, 연결 재설정, 인증 오류를 방지하기 위해 Cloud API와 기타 프록시되지 않은 호스트 및 서브넷의 예외를 추가합니다.

프록시되지 않은 호스트와 서브넷에는 최소한 다음이 포함되어야 합니다.

  • 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와 HTTPS 모두에 적용됩니다.

    • 시스템 속성 http.nonProxyHosts는 CIDR 표기법을 지원하지 않으므로 패턴 일치 표현식을 사용해야 합니다.

잘못된 응답 또는 컨테이너 인스턴스 연결 문제

컨테이너 인스턴스 연결 문제가 있으면 다음 오류가 발생합니다.

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

이 문제를 해결하려면 다음 단계를 따르세요.

  1. Cloud Logging에서 다음 오류를 확인합니다.

    • 메모리 부족 오류 로그에 메모리 한도를 초과하는 컨테이너 인스턴스 관련 오류 메시지가 포함된 경우 컨테이너 인스턴스가 메모리 한도를 초과함 섹션의 권장사항을 참고하세요.

    • 로그에 다음과 같은 오류와 함께 활성 프로브 실패:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.
      

      인스턴스가 제한 시간 내에 프로브에 응답하지 못하면 다음 단계를 따르세요.

  2. Cloud Run에 설정된 요청 제한 시간에 도달하기 전에 503 오류 코드와 함께 요청이 종료되면 언어 프레임워크의 요청 제한 시간 설정을 업데이트합니다.

  3. 경우에 따라 부하 테스트 중과 같은 다운스트림 네트워크 병목 현상으로 인해 503 오류 코드가 발생할 수 있습니다. 예를 들어 서비스가 서버리스 VPC 액세스 커넥터를 통해 트래픽을 라우팅하는 경우 다음 단계에 따라 커넥터가 처리량 기준점을 초과하지 않았는지 확인합니다.

    1. Google Cloud 콘솔에서 서버리스 VPC 액세스를 엽니다.

      서버리스 VPC 액세스로 이동

    2. 처리량 차트 히스토그램에 빨간색 막대가 있는지 확인합니다. 빨간색 막대가 있으면 커넥터가 사용하는 최대 인스턴스 또는 인스턴스 유형을 늘리는 것이 좋습니다. 또는 서버리스 VPC 액세스 커넥터를 통해 전송된 트래픽을 압축합니다.

  4. 컨테이너 인스턴스가 초당 800개를 초과하는 요청을 수신하면 사용 가능한 TCP 소켓이 소진될 수 있습니다. 이 문제를 해결하려면 서비스에 HTTP/2를 사용 설정하고 HTTP/2를 지원하도록 서비스를 변경합니다.

게이트웨이 제한 시간 오류

서비스가 지정된 시간 내에 응답을 반환하지 않고 요청이 종료되면 다음 오류가 발생합니다.

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

이 오류에 관한 자세한 내용은 컨테이너 런타임 계약을 참조하세요.

이 문제를 해결하려면 다음 단계를 따르세요.

  • 서비스에서 긴 요청을 처리하는 경우 요청 제한 시간을 늘리세요.

  • 구성된 요청 제한 시간을 초과하기 전에 앱이 시간을 소비하고 있는 위치를 파악하기 위해 로깅 및 추적을 계측합니다.

  • 인프라 업데이트로 인해 가끔 아웃바운드 연결이 재설정됩니다. 애플리케이션이 장기간 연결을 재사용하는 경우 끊어진 연결이 재사용되지 않도록 애플리케이션을 구성하여 연결을 다시 설정하는 것이 좋습니다.

    앱의 로직 또는 오류 처리에 따라 504 오류는 애플리케이션이 끊어진 연결을 재사용하려고 하는 신호일 수 있으며 구성된 요청 제한 시간까지 요청이 차단됩니다. 활성 프로브를 사용하여 지속적인 오류를 반환하는 인스턴스를 종료합니다.

  • 앱 코드 내에서 발생하는 메모리 부족 오류(예: java.lang.OutOfMemoryError)로 인해 컨테이너 인스턴스가 반드시 종료되는 것은 아닙니다. 메모리 사용량이 컨테이너 메모리 한도를 초과하지 않으면 Cloud Run에서 인스턴스를 종료하지 않습니다. 앱 수준 메모리 부족 오류를 처리하는 방법에 따라 구성된 요청 제한 시간을 초과할 때까지 요청이 처리되지 않을 수 있습니다.

    컨테이너 인스턴스를 종료하려면 다음 단계를 따르세요.

    • 앱 수준 메모리 한도를 컨테이너 메모리 한도보다 크게 구성합니다.

    • 지속적인 오류를 반환하는 인스턴스를 종료하기 위해 활성 프로브를 사용합니다.

인증서 프로비저닝 중에 커스텀 도메인이 멈춤

커스텀 도메인을 매핑할 때 다음 오류 중 하나가 발생합니다.

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.

이 문제를 해결하려면 다음 안내를 따르세요.

  1. 최소 24시간 동안 기다립니다. 일반적으로 SSL 인증서를 프로비저닝하는 데 약 15분 정도 걸리지만 최대 24시간까지 걸릴 수도 있습니다.

  2. Google 관리 콘솔 도구 상자 Dig 도구를 사용하여 도메인 등록기관에서 DNS 레코드를 올바르게 업데이트했는지 확인합니다. 도메인 등록기관의 DNS 레코드가 Google Cloud 콘솔에서 추가하라고 메시지에 표시하는 것과 일치해야 합니다.

  3. 다음 방법 중 하나를 사용하여 계정에서 도메인의 루트를 확인합니다.

  4. 도메인 인증서가 만료되지 않았는지 확인합니다. 만료 경계를 찾으려면 다음 명령어를 사용합니다.

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

클라이언트 연결 해제가 Cloud Run에 전파되지 않음

Cloud Run에서 HTTP/1.1을 사용하면 클라이언트 연결 해제 이벤트가 Cloud Run 컨테이너에 전파되지 않습니다.

이 문제를 해결하려면 클라이언트 연결 해제를 전파하는 Websockets 또는 HTTP/2.0을 사용하세요.

네트워크 파일 시스템 문제

NBD, 9P, CIFS/Samba, Ceph 네트워크 파일 시스템 사용에 관해 자세히 알아보세요.