Cloud Service Mesh는 사이드카 프록시 또는 프록시리스 gRPC를 사용하여 내부 마이크로서비스에 전역 부하 분산을 제공합니다. 여러 리전의 인스턴스로 내부 마이크로서비스(사이드카 프록시 기반 또는 프록시리스 gRPC 기반)를 배포할 수 있습니다. Cloud Service Mesh는 사이드카 프록시 또는 프록시리스 gRPC에 상태, 라우팅, 백엔드 정보를 제공하므로 사이드카 프록시는 서비스의 여러 클라우드 리전에 있는 애플리케이션 인스턴스로 트래픽을 적절히 라우팅할 수 있습니다.
다음 다이어그램에서 사용자 트래픽은 외부 전역 부하 분산기를 통해 Google Cloud배포에 들어갑니다. 외부 부하 분산기는 최종 사용자의 위치에 따라 us-central1 또는 asia-southeast1의 프런트엔드 마이크로서비스에 트래픽을 분산합니다.
내부 배포에는 Front End, Shopping Cart, Payments라는 세 개의 전역 마이크로서비스가 있습니다. 각 서비스는 us-central1 및 asia-southeast1 등 두 리전에 있는 관리형 인스턴스 그룹(MIG)에서 실행됩니다. Cloud Service Mesh는 트래픽을 캘리포니아 사용자로부터 us-central1에 배포된 마이크로서비스로 전달하는 전역 부하 분산 알고리즘을 사용합니다. 싱가포르 사용자의 요청은 asia-southeast1의 마이크로서비스로 전달됩니다.
들어오는 사용자 요청은 Front End 마이크로서비스로 라우팅됩니다. Front End 호스트에 설치된 서비스 프록시는 트래픽을 Shopping Cart로 전달하고 Shopping Cart 호스트에 설치된 사이드카 프록시는 트래픽을 Payments 마이크로서비스로 전달합니다. 프록시리스 gRPC 환경에서 gRPC 애플리케이션은 트래픽 관리를 처리합니다.
전역 부하 분산 배포의 Cloud Service Mesh(확대하려면 클릭)
다음 예시에서 Cloud Service Mesh가 us-central1에서 Shopping Cart 마이크로서비스를 실행하는 가상 머신(VM)이 비정상임을 나타내는 상태 점검 결과를 수신할 경우 Cloud Service Mesh는 프런트엔드 마이크로서비스에 대해 사이드카 프록시에 asia-southeast1에서 실행되는 Shopping Cart 마이크로서비스로 트래픽을 장애 조치하도록 지시합니다. 자동 확장은 Google Cloud의 트래픽 관리와 통합되므로 Cloud Service Mesh는 asia-southeast1의 MIG에 추가 트래픽을 알리고 MIG의 크기를 늘립니다.
Cloud Service Mesh는 Payments 마이크로서비스의 모든 백엔드가 정상임을 감지합니다. 따라서 Cloud Service Mesh는 Shopping Cart의 Envoy 프록시가 트래픽의 일부를 고객이 설정한 용량까지 asia-southeast1으로 보내고 나머지는 us-central1로 오버플로하도록 지시합니다.
전역 부하 분산 배포의 Cloud Service Mesh 장애 조치(확대하려면 클릭)
Cloud Service Mesh의 부하 분산 구성요소
Cloud Service Mesh 설정 중에는 여러 부하 분산 구성요소를 구성합니다.
구성값이 포함된 백엔드 서비스
상태 확인(배포에서 VM 및 Google Kubernetes Engine(GKE) 포드에 대한 상태 확인 제공)
서비스 라우팅 API에서 Mesh 또는 Gateway 리소스 및 Route 리소스
부하 분산 API에서 VIP 주소, 대상 프록시, URL 맵이 포함된 전역 전달 규칙
Envoy와 같은 xDS API 호환 사이드카 프록시는 클라이언트 VM 인스턴스 또는 Kubernetes 포드에서 실행됩니다. Cloud Service Mesh는 컨트롤 플레인으로 작동하고 xDS API를 사용하여 각 프록시와 직접 통신합니다. 데이터 플레인에서 애플리케이션은 전달 규칙 또는 Mesh 리소스에 구성된 VIP 주소로 트래픽을 전송합니다. 사이드카 프록시 또는 gRPC 애플리케이션은 트래픽을 가로채서 이를 적절한 백엔드로 리디렉션합니다.
다음 다이어그램은 Compute Engine VM 또는 GKE 포드, 구성요소, Cloud Service Mesh 배포의 트래픽 흐름에서 실행되는 애플리케이션을 보여줍니다. 트래픽 라우팅을 확인하는 데 사용되는 Cloud Service Mesh 및 Cloud Load Balancing 리소스를 보여줍니다.
이 다이어그램은 이전 부하 분산 API를 보여줍니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Cloud Service Mesh load balancing\n=================================\n\nCloud Service Mesh uses sidecar proxies or proxyless gRPC to deliver global load\nbalancing for your internal microservices. You can deploy internal microservices\n(sidecar proxy-based or proxyless gRPC-based) with instances in multiple\nregions. Cloud Service Mesh provides health, routing, and backend information to\nthe sidecar proxies or proxyless gRPC, enabling them to perform optimal traffic\nrouting to application instances in multiple cloud regions for a service.\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/v1.24/docs/overview).\n\nIn the following diagram, user traffic enters a Google Cloud\ndeployment through an external global load balancer. The external load balancer\ndistributes traffic to the Front End microservice in either\n`us-central1` or `asia-southeast1`, depending on the location of the end user.\n\nThe internal deployment features three global microservices: Front End, Shopping\nCart, and Payments. Each service runs on managed instance groups (MIGs) in two\nregions, `us-central1` and `asia-southeast1`. Cloud Service Mesh uses a global\nload-balancing algorithm that directs traffic from the user in California to the\nmicroservices deployed in `us-central1`. Requests from the user in\nSingapore are directed to the microservices in `asia-southeast1`.\n\nAn incoming user request is routed to the Front End microservice. The service\nproxy installed on the host with the Front End then directs traffic to the\nShopping Cart. The sidecar proxy installed on the host with the Shopping Cart\ndirects traffic to the Payments microservice. In a proxyless gRPC environment,\nyour gRPC application would handle traffic management.\n[](/static/service-mesh/v1.24/docs/images/td-global-lb.svg) Cloud Service Mesh in a global load-balancing deployment (click to enlarge)\n\nIn the following example, if Cloud Service Mesh receives health check results\nthat indicate that the virtual machine (VM) instances running the Shopping Cart\nmicroservice in `us-central1` are unhealthy, Cloud Service Mesh instructs the\nsidecar proxy for the Front End microservices to fail over traffic to the Shopping\nCart microservice running in `asia-southeast1`. Because autoscaling is\nintegrated with traffic management in Google Cloud, Cloud Service Mesh\nnotifies the MIG in `asia-southeast1` of the additional traffic, and the MIG\nincreases in size.\n\nCloud Service Mesh detects that all backends of the Payments microservice are\nhealthy, so Cloud Service Mesh instructs Envoy's proxy for the Shopping Cart to\nsend a portion of the traffic---up to the customer's configured\ncapacity---to `asia-southeast1` and overflow the rest to `us-central1`.\n[](/static/service-mesh/v1.24/docs/images/td-global-lb-failover.svg) Failover with Cloud Service Mesh in a global load-balancing deployment (click to enlarge)\n\nLoad-balancing components in Cloud Service Mesh\n-----------------------------------------------\n\nDuring Cloud Service Mesh setup, you configure several load-balancing\ncomponents:\n\n- The backend service, which contains configuration values.\n- A health check, which provides health checking for the VMs and Google Kubernetes Engine (GKE) Pods in your deployment.\n- With the service routing APIs, a `Mesh` or `Gateway` resource and a `Route` resource.\n- With the load balancing APIs, a global forwarding rule, which includes the VIP address, a target proxy, and a URL map.\n\nAn xDS API-compatible sidecar proxy (such as Envoy) runs on a client\nVM instance or in a Kubernetes Pod. Cloud Service Mesh serves as the control\nplane and uses xDS APIs to communicate directly with each proxy. In the data\nplane, the application sends traffic to the VIP address configured in the\nforwarding rule or `Mesh` resource. The sidecar proxy or your gRPC application\nintercepts the traffic and redirects it to the appropriate backend.\n\nThe following diagram shows an application running on Compute Engine VMs or\nGKE Pods, the components, and the traffic flow in a\nCloud Service Mesh deployment. It shows Cloud Service Mesh and the\nCloud Load Balancing resources that are used to determine traffic routing.\nThe diagram shows the older load balancing APIs.\n[](/static/service-mesh/v1.24/docs/images/td-resources.svg) Cloud Service Mesh resources to be configured (click to enlarge)\n\nWhat's next\n-----------\n\n- To learn about configuring advance load balancing features, see [Advanced load balancing overview](/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview).\n- To learn more about service discovery and traffic interception, see [Cloud Service Mesh service discovery](/service-mesh/v1.24/docs/traffic-management/service-discovery).\n- To learn more about Cloud Service Mesh with the service routing APIs, see the [overview](/service-mesh/v1.24/docs/service-routing/overview)."]]
