프록시리스 gRPC 배포 문제 해결

이 문서에서는 Cloud Service Mesh를 사용하여 프록시리스 gRPC 서비스를 배포할 때 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다. Client State Discovery Service(CSDS) API를 사용하여 Cloud Service Mesh 문제를 조사하는 방법은 Cloud Service Mesh 클라이언트 상태 이해를 참조하세요.

gRPC 애플리케이션의 RPC 실패 문제 해결

gRPC 애플리케이션에서 리모트 프로시져 콜(RPC) 실패 문제를 해결하는 두 가지 일반적인 방법이 있습니다.

  1. RPC가 실패하면 반환된 상태를 검토합니다. 보통, 상태에는 RPC 실패의 원인을 이해하는 데 도움이 되는 충분한 정보가 포함됩니다.

  2. gRPC 런타임에서 로깅을 사용 설정합니다. RPC 반환 상태로 다시 전파되지 않을 수 있는 실패를 이해하기 위해 gRPC 런타임 로그를 검토해야 할 때가 있습니다. 예를 들어 RPC가 기한을 초과했음을 나타내는 상태로 실패하면 로그를 통해 기한 초과가 발생한 근본적인 실패를 이해할 수 있습니다.

    gRPC의 다른 언어 구현에는 gRPC 런타임에서 로깅을 사용 설정하는 다양한 방법이 있습니다.

    • 자바에서의 gRPC: gRPC는 로깅에 java.util.logging을 사용합니다. gRPC 런타임에서 충분한 상세 로깅을 사용 설정하려면 io.grpc.level을 FINE 수준으로 설정합니다. 자바에서 로깅을 사용 설정하는 일반적인 방법은 파일에서 로깅 구성을 로드하고 명령줄 플래그를 사용하여 JVM에 파일 위치를 제공하는 것입니다. 예를 들면 다음과 같습니다.

      # Create a file called logging.properties with the following contents:
handlers=java.util.logging.ConsoleHandler
io.grpc.level=FINE
io.grpc.xds.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# Pass the location of the file to JVM by using this command-line flag:
-Djava.util.logging.config.file=logging.properties

      xDS 모듈에 특정한 로깅을 사용 설정하려면 io.grpc.xds.level을 FINE으로 설정합니다. 자세한 로깅을 보려면 수준을 FINER 또는 FINEST로 설정합니다.

    • Go에서의 gRPC: 환경 변수를 설정하여 로깅을 사용합니다.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • C++에서의 gRPC: C++에서 gRPC로 로깅을 사용 설정하려면 gRPC 문제 해결의 안내를 참조하세요. xDS 모듈별 로깅을 사용 설정하려면 xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb, lrs_lb의 GRPC_TRACE 환경 변수를 사용하여 다음 추적기를 사용 설정합니다.

    • Node.js의 gRPC: Node.js에서 gRPC를 사용한 로깅을 사용 설정하려면 gRPC-JS 문제 해결의 안내를 참조하세요. xDS 모듈별 로깅을 사용 설정하려면 xds_client, xds_resolver, cds_balancer, eds_balancer, priority, weighted_target의 GRPC_TRACE 환경 변수를 사용하여 다음 추적기를 사용 설정합니다.

RPC 상태 또는 런타임 로그의 오류에 따라 문제가 다음 카테고리 중 하나에 해당할 수 있습니다.

Cloud Service Mesh에 연결할 수 없음

연결 문제를 해결하려면 다음을 시도해 보세요.

  • 부트스트랩 파일의 server_uri 값이 trafficdirector.googleapis.com:443인지 확인합니다.
  • 환경 변수 GRPC_XDS_BOOTSTRAP이 정의되어 있고 부트스트랩 파일을 가리키는지 확인합니다.
  • gRPC 채널을 만들 때 URI에 xds 스키마를 사용하는지 확인합니다.
  • Compute 인스턴스를 만들고 프로젝트에서 네트워크를 수정하는 데 필요한 IAM 권한을 부여했는지 확인합니다.
  • 서비스 계정이 Traffic Director API에 액세스하도록 사용 설정되었는지 확인합니다. 프로젝트의 Google Cloud 콘솔 API 및 서비스에서 Traffic Director API의 오류를 확인합니다.
  • 서비스 계정에 올바른 권한이 있는지 확인합니다. VM 또는 pod에서 실행되는 gRPC 애플리케이션은 Compute Engine VM 호스트 또는 Google Kubernetes Engine(GKE) 노드 인스턴스의 서비스 계정을 사용합니다.

  • Compute Engine VM 또는 GKE 클러스터의 API 액세스 범위가 Compute Engine API에 대한 전체 액세스를 허용하도록 설정되어 있는지 확인합니다. VM 또는 클러스터를 만들 때 다음을 지정하여 이를 수행합니다.

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • VM에서 trafficdirector.googleapis.com:443에 액세스할 수 있는지 확인합니다. 액세스 문제가 있다면 TCP 포트 443을 통해 trafficdirector.googleapis.com에 대한 액세스를 차단하는 방화벽이나 trafficdirector.googleapis.com 호스트 이름의 DNS 확인 문제가 원인일 수 있습니다.

URI에 지정된 호스트 이름을 확인할 수 없음

로그에 다음과 같은 오류 메시지가 표시될 수 있습니다.

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

호스트 이름 확인 문제를 해결하려면 다음을 시도해 보세요.

  • 지원되는 gRPC 버전과 언어를 사용하고 있는지 확인합니다.
  • gRPC 채널을 만들기 위해 URI에 사용된 포트가 구성에서 사용되는 전달 규칙의 포트 값과 일치하는지 확인합니다. 포트가 URI에 지정되지 않은 경우 전달 규칙과 일치하는 데 80 값이 사용됩니다.
  • gRPC 채널을 만들기 위해 URI에 사용된 호스트 이름과 포트가 구성에서 사용된 URL맵의 호스트 규칙과 정확하게 일치하는지 확인합니다.
  • 두 개 이상의 URL 맵에서 동일한 호스트 규칙으로 구성되지 않았는지 확인합니다.
  • 와일드 카드가 사용 중인지 확인합니다. * 와일드 카드 문자를 포함하는 호스트 규칙은 무시됩니다.

서비스를 사용할 수 없어 RPC가 실패함

서비스를 사용할 수 없을 때 RPC 실패 문제를 해결하려면 다음을 시도해 보세요.

  • Google Cloud 콘솔에서 Cloud Service Mesh의 전반적인 상태와 백엔드 서비스 상태를 확인합니다.

    • 연결된 라우팅 규칙 맵 열에서 올바른 URL 맵이 백엔드 서비스를 참조하는지 확인합니다. 열을 클릭하여 호스트 일치 규칙에 지정된 백엔드 서비스가 올바른지 확인합니다.
    • 백엔드 열에서 백엔드 서비스와 연결된 백엔드가 정상인지 확인합니다.
    • 백엔드가 비정상인 경우 해당 백엔드 서비스를 클릭하고 올바른 상태 확인이 구성되었는지 확인합니다. 상태 확인은 일반적으로 방화벽 규칙이 잘못되었거나 누락된 경우 또는 VM과 방화벽 규칙에서 지정된 태그의 불일치로 인해 실패합니다. 자세한 내용은 상태 확인 만들기를 참조하세요.

  • gRPC 상태 확인이 제대로 작동하려면 gRPC 백엔드가 gRPC 상태 확인 프로토콜을 구현해야 합니다. 이 프로토콜이 구현되지 않았으면 대신 TCP 상태 확인을 사용합니다. HTTP, HTTPS 또는 HTTP/2 상태 점검을 gRPC 서비스와 함께 사용하지 마세요.

  • 인스턴스 그룹을 사용할 때 인스턴스 그룹에 지정된 이름이 지정된 포트가 상태 확인에 사용되는 포트와 일치하는지 확인합니다. 네트워크 엔드포인트 그룹(NEG)을 사용하는 경우 GKE 서비스 사양에 올바른 NEG 주석이 있고 상태 확인이 NEG 제공 포트를 사용하도록 구성되어 있는지 확인합니다.

  • 엔드포인트 프로토콜이 GRPC로 구성되었는지 확인합니다.

부하 분산 정책이 지원되지 않으므로 RPC가 실패함

로그에 다음 중 하나와 같은 오류 메시지가 표시될 수 있습니다.

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

RING_HASH가 사용 중인 클라이언트의 특정 언어 및 버전에서 지원되지 않기 때문입니다. 이 문제를 해결하려면 지원되는 부하 분산 정책만 사용하도록 백엔드 서비스 구성을 업데이트하거나 클라이언트를 지원되는 버전으로 업그레이드합니다. 지원되는 클라이언트 버전의 경우 gRPC의 xDS 기능을 참조하세요.

보안 구성이 예상대로 생성되지 않음

서비스 보안을 구성했지만 보안 구성이 예상대로 생성되지 않으면 배포의 엔드포인트 정책을 검사합니다.

Cloud Service Mesh는 엔드포인트와 일치하는 엔드포인트 정책 리소스가 2개 이상 있는 시나리오를 지원하지 않습니다(예: 같은 라벨과 포트가 있는 정책 2개 또는 엔드포인트 라벨과 일치하는 서로 다른 라벨이 있는 정책 2개 이상). 엔드포인트 정책을 엔드포인트 라벨과 일치시키는 방법에 대한 자세한 내용은 EndpointPolicy.EndpointMatcher.MetadataLabelMatcher의 API를 참조하세요. 이러한 경우 Cloud Service Mesh는 충돌하는 정책에서 보안 구성을 생성하지 않습니다.

서비스 메시 상태 문제 해결

이 가이드에서는 Cloud Service Mesh 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다.

대부분의 엔드포인트가 비정상인 경우의 Cloud Service Mesh 동작

엔드포인트의 99%가 비정상이면 신뢰성을 높이기 위해 Cloud Service Mesh에서 데이터 영역을 구성하여 엔드포인트의 정상 상태를 무시합니다. 대신 데이터 영역은 모든 엔드포인트 간에 트래픽을 분산하며 이는 서빙 포트가 계속 작동할 수 있기 때문입니다.

비정상 백엔드로 인해 트래픽 분산이 최적화되지 않음

Cloud Service Mesh는 백엔드 서비스에 연결된 HealthCheck 리소스의 정보를 사용하여 백엔드 상태를 평가합니다. Cloud Service Mesh는 이 정상 상태를 사용하여 트래픽을 가장 가까운 정상 백엔드로 라우팅합니다. 일부 백엔드가 비정상이면 트래픽이 계속 처리되더라도 분포가 최적이 아닐 수 있습니다. 예를 들어 트래픽이 정상 백엔드가 계속 있는 리전에 전달될 수 있지만 클라이언트에서 멀리 떨어져 있어 지연 시간이 발생할 수 있습니다. 백엔드 정상 상태를 식별하고 모니터링하려면 다음 단계를 수행합니다.

다음 단계