Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

프록시리스 gRPC 서비스를 사용하는 Cloud Service Mesh 개요

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

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

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

Cloud Service Mesh의 작동 방식에 관한 전체 개요는 Cloud Service Mesh 개요를 참조하세요.

Cloud Service Mesh가 gRPC 애플리케이션에서 작동하는 방식

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

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

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

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

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

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

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

이름 변환

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

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

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

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

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

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

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

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

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

사용 사례

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

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

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

고성능 gRPC 애플리케이션

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

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

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

이기종 서비스 메시

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

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

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

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

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

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

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

아키텍처 및 리소스

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

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

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

상태 확인

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

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

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

백엔드 서비스

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

프로토콜이 GRPC로 설정된 백엔드 서비스는 사이드카 프록시를 통해 gRPC 애플리케이션에서도 액세스할 수도 있습니다. 이러한 경우 gRPC 클라이언트는 xds 이름 변환 스키마를 사용해서는 안 됩니다.
모든 Cloud Service Mesh 배포에서 백엔드 서비스의 부하 분산 스키마는 INTERNAL_SELF_MANAGED여야 합니다.

백엔드

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

다음 단계

서비스 라우팅 API와 작동 방식에 대한 자세한 내용은 개요를 참조하세요.
프록시리스 gRPC 애플리케이션으로 Cloud Service Mesh 구성을 준비하려면 Envoy 및 프록시리스 워크로드 설정 준비를 참조하세요.
프록시리스 gRPC 배포에 적용되는 제한사항을 알아보려면 프록시리스 gRPC를 사용하는 한도 및 제한사항을 참조하세요.