Traffic Director load balancing

Traffic Director delivers global load balancing for your internal microservices with sidecar proxies. You can deploy internal microservices (sidecar proxy-based) with instances in multiple regions. Traffic Director provides health, routing, and backend information to the sidecar proxies, enabling them to perform optimal traffic routing to application instances in multiple cloud regions for a service.

In the following illustration, user traffic enters a Google Cloud deployment through an external global load balancer. The external load balancer distributes traffic to the Front End microservice in either us-central1 or asia-southeast1, depending on the location of the end user.

The internal deployment features three global microservices: Front End, Shopping Cart, and Payments. Each service runs on managed instance groups in two regions, us-central1 and asia-southeast1. Traffic Director uses a global load balancing algorithm that directs traffic from the user in California to the microservices deployed in us-central1, while requests from the user in Singapore are directed to the microservices in asia-southeast1.

An incoming user request is routed to the Front End microservice. The service proxy installed on the host with the Front End then directs traffic to the Shopping Cart. The sidecar proxy installed on the host with the Shopping Cart directs traffic to the Payments microservice.

Traffic Director in a global load balancing deployment (click to enlarge)
Traffic Director in a global load balancing deployment (click to enlarge)

In the following example, if Traffic Director receives health check results indicating that the VMs running the Shopping Cart microservice in us-central1 are unhealthy, Traffic Director instructs the sidecar proxy for the Frontend microservices to fail over traffic to the Shopping Cart microservice running in asia-southeast1. Because autoscaling is integrated with traffic management in Google Cloud, Traffic Director notifies the managed instance group in asia-southeast1 of the additional traffic, and the managed instance group increases in size.

Traffic Director detects that all backends of the Payments microservice are healthy, so Traffic Director instructs Envoy's proxy for the Shopping Cart to send a portion of the traffic, up to the customer's configured capacity, to asia-southeast1 and overflow the rest to us-central1.

Failover with Traffic Director in a global load balancing deployment (click to enlarge)
Failover with Traffic Director in a global load balancing deployment (click to enlarge)

Load balancing components in Traffic Director

During Traffic Director setup, you configure several load balancing components:

  • A global forwarding rule, which includes the VIP address; the target proxy; and the URL map. All of these are part of Traffic Director's traffic routing mechanism. The target proxy must be a target HTTP proxy.
  • The backend service, which contains configuration values.
  • A health check, which provides health checking for the VMs and pods in your deployment.

The following diagram shows an application running on Compute Engine VMs or Google Kubernetes Engine pods, the components, and the traffic flow in a Traffic Director deployment:

Traffic Director resources to be configured (click to enlarge)
Traffic Director resources to be configured (click to enlarge)

The diagram shows Traffic Director and the Google Cloud load balancing resources it uses to determine traffic routing. An xDS API-compatible sidecar proxy (such as Envoy, as shown) runs on a client VM instance or in a Kubernetes pod. Traffic Director serves as the control plane and communicates directly with each proxy using xDS APIs. In the data plane, the application sends traffic to the VIP address configured in the Google Cloud forwarding rule. The traffic is intercepted by the sidecar proxy and redirected to the appropriate backend. For more information about service discovery and traffic interception, see Traffic Director service discovery.