프록시리스 gRPC 서비스를 사용하는 Traffic Director 개요

이 가이드에서는 사용 사례 및 아키텍처 패턴을 포함한 프록시리스 gRPC 서비스를 사용하는 Traffic Director 아키텍처에 대한 개요를 제공합니다. 이 가이드에서는 이전 Traffic Director API를 다룹니다. 서비스 라우팅 API에 대한 자세한 내용은 개요를 참조하세요.

Traffic Director의 관리형 제어 영역을 사용하면 서비스 메시 및 부하 분산 사용 사례에 전역 라우팅, 부하 분산, 리전 장애 조치를 사용 설정할 수 있습니다. 여기에는 사이드카 프록시 및 게이트웨이 프록시가 사용되는 배포가 포함됩니다. 프록시리스 gRPC 애플리케이션을 위한 Traffic Director 지원 기능은 gRPC 애플리케이션이 사이드카 프록시를 필요로 하지 않는 서비스 메시에 참여할 수 있도록 하는 추가 배포 모델을 제공합니다.

일반적인 예시에서는 gRPC 클라이언트가 백엔드 로직을 호스팅하는 gRPC 서버와의 연결을 설정합니다. Traffic Director는 연결할 서버, 서버의 여러 인스턴스에 요청을 부하 분산하는 방법, 서버가 실행되고 있지 않을 경우 요청을 처리하는 방법에 대한 정보를 gRPC 클라이언트에 제공합니다.

Traffic Director의 작동 방식에 대한 전체 개요는 Traffic Director 개요를 참조하세요.

Traffic Director가 gRPC 애플리케이션에서 작동하는 방식

Traffic Director는 Envoy 등의 사이드카 프록시가 구성되는 방식과 비슷하게 지원되는 gRPC 버전으로 gRPC 클라이언트를 구성합니다. 그러나 Traffic Director에 직접 연결된 프록시리스 gRPC 애플리케이션에는 사이드카 프록시가 필요하지 않습니다. 대신 Traffic Director가 오픈소스 xDS API를 사용하여 gRPC 애플리케이션을 직접 구성합니다. 이러한 gRPC 애플리케이션은 xDS 클라이언트 역할을 하며 Traffic Director의 전역 제어 영역에 연결됩니다. gRPC 애플리케이션은 연결된 후 제어 영역에서 동적 구성을 수신하고 엔드포인트 검색, 부하 분산, 리전 장애 조치, 상태 확인을 사용 설정합니다. 이 접근 방식을 사용하면 Traffic Director 배포 패턴을 추가할 수 있습니다.

첫 번째 이미지에서는 사이드카 프록시를 사용하여 서비스 메시가 사용 설정됩니다.

사이드카 프록시를 사용하여 사용 설정된 서비스 메시입니다.
사이드카 프록시를 사용하여 사용 설정된 서비스 메시(확대하려면 클릭)

사이드카 프록시를 구성하기 위해 Traffic Director에는 xDS API가 사용됩니다. 클라이언트는 사이드카 프록시를 통해 서버와 통신합니다.

두 번째 이미지에서는 사이드카 프록시 없이 프록시리스 gRPC 클라이언트를 사용하여 서비스 메시가 사용 설정됩니다.

프록시리스 gRPC를 사용하여 사용 설정된 서비스 메시
프록시리스 gRPC를 사용하여 사용 설정된 서비스 메시(확대하려면 클릭)

Traffic Director가 구성하는 gRPC 서비스만 배포하는 경우 프록시를 전혀 배포하지 않고 서비스 메시를 만들 수 있습니다. 이렇게 하면 gRPC 애플리케이션에 서비스 메시 기능을 더 쉽게 가져올 수 있습니다.

이름 확인 스키마

프록시리스 배포에 대한 이름 확인 방법은 다음과 같습니다.

  1. 서비스에 연결할 때 xds를 gRPC 클라이언트 채널에서 이름 확인 스키마로 설정합니다. 대상 URI 형식은 xds:///hostname:port로 지정됩니다. 포트가 지정되지 않은 경우 기본값은 80입니다(예: 대상 URI xds:///example.hostname).
  2. gRPC 클라이언트는 Traffic Director에 리스너 검색 서비스(LDS) 요청을 전송하여 대상 URI의 hostname:port를 확인합니다.
  3. Traffic Director는 일치하는 포트가 있는 구성된 전달 규칙을 찾습니다. 그런 다음 hostname:port와 일치하는 호스트 규칙에 해당하는 URL 맵을 찾습니다. 연결된 라우팅 구성을 gRPC 클라이언트에 반환합니다.

Traffic Director에서 구성하는 호스트 규칙은 모든 URL 맵에서 고유해야 합니다. 예를 들어 example.hostname, example.hostname:80, example.hostname:8080는 모두 다른 규칙입니다.

다른 배포 유형으로 이름 확인

이름 확인 스키마는 프록시리스 배포와 Envoy 프록시를 사용하는 배포에서 서로 다릅니다.

gRPC 클라이언트는 xds 이름 확인 스키마를 사용하여 서비스에 연결하고 클라이언트가 Traffic Director의 서비스 구성을 수신할 수 있게 합니다. 그러면 gRPC 클라이언트가 gRPC 서버와 직접 통신합니다.

사이드카 프록시 및 프록시리스 배포 패턴을 결합하여 유연성을 높일 수 있습니다. 패턴 결합은 조직 및 네트워크가 기능 요구사항, 운영 요구사항, gRPC 버전이 서로 다른 여러 팀을 지원할 때 특히 유용합니다.

다음 이미지에서는 프록시리스 gRPC 클라이언트와 사이드카 프록시가 있는 gRPC 클라이언트가 모두 gRPC 서버와 통신합니다. 사이드카 프록시를 사용하는 gRPC 클라이언트는 dns 이름 확인 스키마를 사용합니다.

프록시리스 gRPC 클라이언트와 사이드카 프록시를 포함한 gRPC 클라이언트로 구성된 서비스 메시
프록시리스 gRPC 클라이언트와 사이드카 프록시를 포함한 gRPC 클라이언트로 구성된 서비스 메시(확대하려면 클릭)

사용 사례

다음 사용 사례는 프록시리스 gRPC 애플리케이션에 Traffic Director를 사용해야 하는 경우를 이해하는 데 도움이 됩니다. 배포에는 프록시리스 gRPC 애플리케이션, 사이드카 프록시가 있는 gRPC 애플리케이션, 또는 이 두 가지의 조합이 포함될 수 있습니다.

대규모 서비스 메시의 리소스 효율성

서비스 메시에 수백 또는 수천 개의 클라이언트와 백엔드가 포함된 경우 사이드카 프록시 실행으로 인한 총 리소스 소비가 증가하기 시작할 수 있습니다. 프록시리스 gRPC 애플리케이션을 사용하면 배포에 사이드카 프록시를 도입할 필요가 없습니다. 프록시리스 접근 방식을 사용하면 효율성이 향상될 수 있습니다.

고성능 gRPC 애플리케이션

일부 사용 사례의 경우 요청 및 응답 지연 시간에서 각각의 밀리초가 중요한 경우가 있습니다. 이러한 경우 모든 요청을 클라이언트 측 사이드카 프록시와 잠재적으로 서버 측 사이드카 프록시를 통해 보내는 대신 프록시리스 gRPC 애플리케이션을 사용하여 지연 시간을 줄일 수 있습니다.

사이드카 프록시를 배포할 수 없는 환경의 서비스 메시

일부 환경에서는 클라이언트 또는 서버 애플리케이션과 함께 사이드카 프록시를 추가 프로세스로 실행하지 못할 수 있습니다. 또는 예를 들어 iptables를 사용하여 요청 가로채기와 리디렉션용으로 머신의 네트워크 스택을 구성하지 못할 수 있습니다. 이 경우 Traffic Director를 프록시리스 gRPC 애플리케이션과 함께 사용하여 gRPC 애플리케이션에 서비스 메시 기능을 도입할 수 있습니다.

이기종 서비스 메시

프록시리스 gRPC 애플리케이션과 Envoy는 Traffic Director와 통신하기 때문에 서비스 메시에 두 배포 모델을 모두 포함할 수 있습니다. 두 모델을 모두 포함하면 다양한 애플리케이션과 여러 개발팀의 특정 운영, 성능, 기능 요구를 충족할 수 있습니다.

프록시가 있는 서비스 메시에서 프록시가 없는 메시로 마이그레이션

Traffic Director에서 구성된 사이드카 프록시가 있는 gRPC 애플리케이션이 이미 있는 경우 프록시리스 gRPC 애플리케이션으로 전환할 수 있습니다.

gRPC 클라이언트가 사이드카 프록시로 배포되면 DNS를 사용하여 연결하려는 호스트 이름을 확인합니다. 사이드카 프록시는 트래픽을 가로채서 서비스 메시 기능을 제공합니다.

gRPC 서버가 사용하는 이름 확인 스키마를 수정하여 gRPC 클라이언트가 gRPC 서버와 통신하는 데 프록시리스 경로를 사용할지, 사이드카 프록시 경로를 사용할지를 정의할 수 있습니다. 프록시리스 클라이언트는 xds 이름 확인 스키마를 사용하지만 사이드카 프록시는 dns 이름 확인 스키마를 사용합니다. 일부 gRPC 클라이언트는 한 gRPC 서버와 통신할 때 프록시리스 경로를 사용하지만 다른 gRPC 서버와 통신할 때 사이드카 프록시 경로를 사용할 수도 있습니다. 이렇게 하면 프록시리스 배포로 점진적으로 마이그레이션할 수 있습니다.

프록시가 있는 서비스 메시에서 프록시가 없는 메시로 마이그레이션하려면 프록시리스 gRPC 클라이언트에 사용되는 새 Traffic Director 서비스를 만듭니다. 동일한 API를 사용하여 기존 및 신규 버전에 대해 Traffic Director를 구성할 수 있습니다.

프록시리스와 프록시 기반 메커니즘을 사용하여 다른 서비스와 통신하는 gRPC 클라이언트가 포함된 서비스 메시
프록시리스와 프록시 기반 메커니즘을 사용하여 다른 서비스와 통신하는 gRPC 클라이언트가 포함된 서비스 메시(확대하려면 클릭)

아키텍처 및 리소스

프록시리스 gRPC 서비스의 구성 데이터 모델은 Traffic Director 구성 모델을 확장하며, 여기에는 이 가이드에 설명되어 있는 몇 가지 추가사항 및 제한사항이 있습니다. 프록시리스 gRPC가 Envoy의 기능을 모두 지원하지는 않기 때문에 이러한 제한 중 일부는 일시적이며 다른 일부는 RPC를 사용하는 데 적용됩니다. 예를 들어 gRPC를 사용하는 HTTP 리디렉션은 지원되지 않습니다. 이 가이드의 구성 모델을 이해하려면 Traffic Director 개념 및 구성을 숙지하는 것이 좋습니다.

다음 다이어그램은 프록시리스 gRPC 애플리케이션에 대해 구성해야 하는 리소스를 보여줍니다.

부하 분산을 위해 프록시리스 gRPC에서 지원되는 리소스
부하 분산을 위해 프록시리스 gRPC에서 지원되는 리소스(확대하려면 클릭)

라우팅 규칙 맵

라우팅 규칙 맵은 요청이 메시에서 라우팅되는 방법을 정의합니다. 전달 규칙, 대상 gRPC 프록시, URL 맵으로 구성됩니다. 라우팅 규칙 맵은 부하 분산 API를 사용하는 배포에만 적용됩니다. 서비스 라우팅 API 또는 Gateway API에는 적용되지 않습니다.

전달 규칙

일반적으로 구성 중인 서비스의 가상 IP 주소와 포트를 사용하여 전달 규칙을 만듭니다. xds 이름 확인 스키마를 사용하는 gRPC 클라이언트는 채널 URI의 호스트 이름을 확인하기 위해 DNS 조회를 수행하지 않습니다. 대신 이러한 클라이언트는 Traffic Director에 LDS 요청을 전송하여 대상 URI의 hostname[:port]을 확인합니다. DNS 조회는 포함되지 않으며 호스트 이름에 대한 DNS 항목이 필요하지 않습니다.

따라서 Traffic Director는 URI에 지정된 포트만 사용하여 IP 주소를 무시하고 전달 규칙을 찾습니다. 포트의 기본값은 80입니다. 그런 다음 Traffic Director는 전달 규칙에서 참조하는 대상 프록시와 연결된 URL 맵에서 일치하는 호스트 규칙을 찾습니다.

따라서 validateForProxyless 필드가 TRUE로 설정된 대상 gRPC 프록시를 참조하는 전달 규칙의 IP 주소는 0.0.0.0으로 설정되어야 합니다. validateForProxyless가 TRUE로 설정되면 0.0.0.0 이외의 IP 주소로 지정된 구성이 거부됩니다. 이 검사는 다른 라우팅 규칙 맵에서 포트가 동일한 중복 전달 규칙을 감지하지 않습니다.

다음에 유의하세요.

  • 전달 규칙의 부하 분산 스키마는 INTERNAL_SELF_MANAGED여야 합니다.
  • 여러 전달 규칙이 있을 수 있지만 각 전달 규칙의 IP:port는 고유해야 하며 포트는 호스트 규칙에 지정된 포트와 일치해야 합니다.
  • 2개 이상의 전달 규칙에 대상 URI의 포트와 일치하는 포트가 있는 경우 Traffic Director는 이러한 모든 전달 규칙에서 참조하는 URL 맵의 호스트 규칙에서 일치하는 hostname[:port]을 찾습니다. Traffic Director는 호스트 규칙의 hostname[:port]와 대상 URI에 지정된 hostname[:port] 간에 정확한 일치를 찾습니다. 와일드 카드 문자를 포함하는 호스트 규칙과 기본 규칙은 건너뜁니다.

또한 일치하는 항목이 두 개 이상 발견되면 동작이 정의되지 않고 예기치 않은 동작이 발생할 수 있습니다. 이는 일반적으로 다음 두 가지 조건이 모두 충족되는 경우에 발생합니다.

  • 여러 URL 맵에서 동일한 호스트 이름이 사용됩니다.
  • 부하 분산 스키마 INTERNAL_SELF_MANAGED를 사용하는 여러 전달 규칙이 동일한 포트를 지정합니다.

따라서 동일한 포트를 지정하는 전달 규칙이 참조하는 여러 URL 맵에서 동일한 호스트 이름을 다시 사용하지 않는 것이 좋습니다.

대상 gRPC 프록시

대상 프록시는 트래픽을 올바른 백엔드로 라우팅하는 데 사용되는 규칙을 포함하는 URL 맵을 지정합니다. gRPC 애플리케이션의 Traffic Director를 구성할 때는 프록시리스 gRPC 애플리케이션을 사용하는지 Envoy를 사용하는 gRPC 애플리케이션을 사용하는지와 관계없이 대상 HTTP 프록시가 아닌 대상 gRPC 프록시를 사용합니다.

대상 gRPC 프록시에는 REST API에 validateForProxyless라는 필드가 있습니다. 기본값은 FALSE입니다. 이 필드를 TRUE로 설정하면 구성 확인이 사용 설정되어 프록시리스 gRPC와 호환되지 않는 기능을 실수로 사용 설정하지 않을 수 있습니다.

Google Cloud CLI에서 --validate-for-proxyless 플래그는 validateForProxyless 필드와 같습니다.

프록시리스 gRPC 애플리케이션의 Traffic Director는 사이드카 프록시가 있는 gRPC 애플리케이션에 사용 가능한 모든 기능을 지원하지 않으므로 이 필드를 사용하여 URL 맵 또는 백엔드 서비스에 지정된 잘못된 구성을 거부할 수 있습니다. 구성 유효성 검사는 Traffic Director가 최신 버전의 gRPC로 지원하는 기능을 기반으로 수행됩니다.

URL 맵

URL 맵은 프록시리스 gRPC 클라이언트가 트래픽을 전송하는 데 사용하는 라우팅 규칙을 정의합니다. URL 맵은 hostname:port 형식의 호스트 규칙을 하나 이상 포함합니다. 이러한 호스트 규칙은 각각 서비스로 확인됩니다.

gRPC 클라이언트를 구성할 때 클라이언트가 연결해야 하는 서비스의 대상 URI를 지정합니다. 이 URI는 hostname:port 형식도 사용합니다. 이 URI는 URL 맵의 호스트 규칙 항목에 해당합니다.

예를 들어 gRPC 클라이언트에서 대상 URI xds:///myservice:8080을 구성하면 Traffic Director가 myservice:8080의 URL 맵 호스트 규칙에 해당하는 구성을 보냅니다. 이 구성은 다른 정보 중에서도 특정 gRPC 서버 인스턴스에 해당하는 각 IP 주소:포트 쌍인 엔드포인트 목록을 포함합니다.

대상 URI에 포트를 지정하지 않으면 80이 기본값으로 사용됩니다. 이는 다음을 의미합니다.

  • 대상 URI xds:///myservice가 URL 맵 호스트 규칙 myservice와 일치합니다.
  • 대상 URI xds:///myservice:80이 URL 맵 호스트 규칙 myservice:80과 일치합니다.
  • 대상 URI xds:///myservice가 URL 맵 호스트 규칙 myservice:80과 일치하지 않습니다.
  • 대상 URI xds:///myservice:80이 URL 맵 호스트 규칙 myservice와 일치하지 않습니다.

대상 URI의 문자열과 URL 맵 호스트 규칙의 문자열이 동일해야 합니다.

자세한 내용은 URL 맵 제한사항을 참조하세요.

상태 확인

gRPC 상태 확인은 백엔드 가상 머신(VM) 인스턴스 또는 네트워크 엔드포인트 그룹(NEG)에서 실행 중인 gRPC 서비스의 상태를 확인할 수 있습니다.

gRPC 서버가 gRPC 상태 확인 프로토콜을 구현하지 않아 gRPC 상태 확인을 사용할 수 없는 경우 대신 TCP 상태 확인을 사용하세요. HTTP, HTTPS 또는 HTTP/2 상태 확인을 사용하지 마세요.

자세한 내용은 gRPC 상태 확인 및 gRPC 상태 확인을 위한 추가 플래그를 참조하세요.

백엔드 서비스

백엔드 서비스는 gRPC 클라이언트가 gRPC 서버와 통신하는 방법을 정의합니다. gRPC의 백엔드 서비스를 만들 때 프로토콜 필드를 GRPC로 설정합니다.

  • 프로토콜이 GRPC로 설정된 백엔드 서비스는 사이드카 프록시를 통해 gRPC 애플리케이션에서도 액세스할 수도 있습니다. 이러한 경우 gRPC 클라이언트는 xds 이름 확인 스키마를 사용해서는 안 됩니다.

  • 모든 Traffic Director 배포에서 백엔드 서비스의 부하 분산 스키마는 INTERNAL_SELF_MANAGED여야 합니다.

백엔드

백엔드는 gRPC 서버 인스턴스를 호스팅합니다. Compute Engine의 관리형 인스턴스 그룹 또는 비관리형 인스턴스 그룹과 Google Kubernetes Engine의 영역 NEG를 백엔드로 사용하여 gRPC 서버 인스턴스를 호스트할 수 있습니다.

다음 단계