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

이 가이드에서는 사용 사례 및 아키텍처 패턴을 포함한 프록시리스 gRPC 서비스를 사용하는 Traffic Director 아키텍처에 대한 개요를 제공합니다.

개요

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

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

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

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

이 접근 방식은 Traffic Director 배포 패턴을 추가로 지원합니다. 아래의 첫 번째 이미지에서는 사이드카 프록시를 사용하여 서비스 메시가 사용 설정됩니다.

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

Traffic Director는 xDS v2 API를 사용하여 사이드카 프록시를 구성합니다. gRPC 클라이언트는 사이드카 프록시를 통해 gRPC 서버와 통신합니다.

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

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

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

이름 확인 스키마

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

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

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

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

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

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

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

다음 이미지에서는 프록시리스 gRPC 클라이언트와 사이드카 프록시가 있는 gRPC 클라이언트가 모두 gRPC 서버와 통신합니다.

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

사이드카 프록시를 사용하는 gRPC 클라이언트는 dns 이름 확인 스키마를 사용합니다.

사용 사례

이 예시에서는 프록시리스 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 사용에 고유한 제한사항입니다. 예를 들어 HTTP 리디렉션은 gRPC를 사용 시 지원되지 않습니다. 이 가이드의 구성 모델을 이해하는 데 도움이 되는 Traffic Director 개념구성을 숙지하는 것이 좋습니다.

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

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

라우팅 규칙 맵

라우팅 규칙 맵은 요청이 메시에서 라우팅되는 방법을 정의합니다. 이는 전달 규칙, 대상 gRPC 프록시, URL 맵으로 구성됩니다.

전달 규칙

일반적으로 가상 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으로 설정되어야 합니다. validateForProxylessTRUE로 설정되면 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 맵의 기본 규칙은 건너뜁니다.

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

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

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

대상 gRPC 프록시

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

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

gcloud 명령줄 도구에서 --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 xds:///myservice가 URL 맵 호스트 규칙 myservice와 일치합니다.
  • 대상 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 서버 인스턴스를 호스팅할 수 있습니다.

제한사항

  • Google Cloud Console에서는 gRPC 프로토콜을 사용하여 백엔드 서비스 및 라우팅 규칙 맵을 구성할 수 없습니다. 이러한 리소스의 경우 Cloud Console은 읽기 전용입니다.

  • gRPC 1.30.0(최신 패치 적용) 이상은 현재 C++, 자바, Go, Python, PHP, Ruby, C# 언어로 프록시리스 gRPC 애플리케이션을 지원합니다.

  • 프록시리스 gRPC는 엔드포인트 검색, 라우팅, 부하 분산, 부하 보고를 지원합니다.

    • 고급 트래픽 관리와 같이 지원되지 않는 기능이 필요한 경우 서비스의 하위 집합에만 프록시리스 gRPC 서비스를 사용하도록 gRPC 클라이언트를 구성합니다. 사이드카 프록시를 사용하여 프록시리스 gRPC 서비스에서 아직 지원되지 않는 기능이 필요한 서버와 통신할 수 있습니다.
    • 와일드 카드 문자를 제외한 호스트 일치 규칙이 지원됩니다.
    • 경로 규칙 및 라우팅 규칙은 지원되지 않습니다. 호스트 규칙에 사용되는 경로 일치자는 기본 서비스를 하나만 구성할 수 있습니다.
  • gRPC 버전 1.30.0에서는 라운드 로빈 부하 분산만 지원됩니다. 다른 부하 분산 알고리즘은 지원되지 않습니다.

    • Traffic Director는 gRPC 클라이언트에 우선순위가 정해지고 가중치가 적용된 지역 목록(인스턴스 그룹 또는 NEG 1개)을 제공합니다. Traffic Director는 가장 가까운 영역, 용량, 백엔드 서비스의 분산 모드를 기준으로 이 값을 계산합니다. 특정 요청의 경우 gRPC 클라이언트는 우선순위와 가중치에 따라 하나 이상의 지역을 선택하고 이러한 지역 내에서 백엔드로 라운드 로빈 부하 분산을 수행합니다.
  • 장애 조치: 현재 영역 용량이 50% 미만이면 한 영역(지역)에서 다른 영역으로 장애 조치가 시작됩니다. 이 기준은 구성할 수 없습니다.

  • 대상 gRPC 프록시와 대상 gRPC 프록시를 참조하는 전달 규칙에 관련된 구성 명령어는 경우에 따라 최대 1분이 걸릴 수 있습니다.

  • 한 백엔드 서비스에서 다른 백엔드 서비스로 변경하기 위해 URL 맵 호스트 규칙을 업데이트하면 새 구성이 클라이언트로 푸시되는 동안 트래픽이 잠시 중단될 수 있습니다. 이러한 제한사항을 방지하려면 사이드카 프록시를 사용하여 배포하고 가중치가 적용된 백엔드 서비스로 트래픽 분할을 구현합니다. 이후에 트래픽을 이전 백엔드에서 새 백엔드 서비스로 천천히 이동합니다.

URL 맵 제한사항

이 출시 버전에는 다음 URL 맵 제한사항이 적용됩니다.

  • 호스트 규칙에 사용되는 경로 일치자는 기본 서비스를 하나만 구성할 수 있습니다.
  • 경로 규칙 및 라우팅 규칙은 지원되지 않습니다.
  • URL 맵 호스트 규칙에는 와일드 카드 문자가 지원되지 않습니다.
  • 고급 트래픽 관리 구성에 설명된 고급 트래픽 관리 기능은 지원되지 않습니다.

다음 단계