Visão geral do gerenciamento de tráfego para balanceadores de carga HTTP(S) internos

O balanceamento de carga interno HTTP(S) é compatível com o gerenciamento de tráfego avançado. Com essa funcionalidade, é possível usar os recursos a seguir:
  • Direcionamento de tráfego. Encaminhe o tráfego com inteligência usando como base parâmetros HTTP(S). Por exemplo, hosts, caminhos, cabeçalhos e outros parâmetros da solicitação.
  • Ações de tráfego. Execute ações baseadas nas solicitações e nas respostas. Por exemplo, transformações de cabeçalho e redirecionamentos.
  • Políticas de tráfego. Ajuste o funcionamento do balanceamento de carga. Por exemplo, os algoritmos avançados dele.

Para configurar esses recursos, use os mapas de URL e serviços de back-end. Para mais informações, consulte os tópicos a seguir:

Exemplos de casos de uso

O gerenciamento de tráfego é aplicável a muitos casos de uso. Nesta seção, veremos alguns exemplos gerais.

Direcionamento de tráfego: roteamento baseado no cabeçalho

Com o direcionamento de tráfego, você encaminha o tráfego a instâncias de serviço com base em parâmetros HTTPS, como os cabeçalhos da solicitação. Por exemplo, considere o dispositivo móvel de um usuário que tenha user-agent:Mobile no cabeçalho da solicitação. Com o direcionamento, é possível enviar esse tráfego a instâncias de serviço designadas para processar o tráfego de dispositivos móveis. Além disso, o tráfego que não tem user-agent:Mobile é enviado a instâncias designadas para processar o tráfego de outros dispositivos.

Direcionamento de tráfego do Cloud Load Balancing (clique para ampliar)
Direcionamento de tráfego do Cloud Load Balancing

Ações de tráfego: divisão com base no peso

Geralmente, implantar uma nova versão de um serviço de produção atual tem certos riscos. Mesmo que os testes sejam bem-sucedidos no preparo, não é recomendável fornecer imediatamente a nova versão a todos os usuários. Com o balanceamento de carga interno HTTP(S), você define divisões de tráfego baseadas em percentual em vários serviços de back-end.

Por exemplo, é possível enviar 95% do tráfego à versão anterior do serviço e 5% à nova versão dele. Depois de validar o funcionamento da nova versão de produção do seu serviço, mude gradativamente os percentuais até que 100% do tráfego chegue a ela. A divisão de tráfego normalmente é usada para implantar novas versões, testes A/B, migração de serviço e processos semelhantes.

Divisão de tráfego do Cloud Load Balancing
Divisão de tráfego do Cloud Load Balancing

Políticas de tráfego: espelhamento de solicitações

É provável que sua organização tenha requisitos de conformidade específicos que determinam o espelhamento de todo o tráfego para outro serviço. Por exemplo, um serviço que registra os detalhes da solicitação em um banco de dados para reprodução posterior.

Componentes do gerenciamento de tráfego

Em geral, os balanceadores de carga internos HTTP(S) fornecem o gerenciamento de tráfego usando os recursos regionais de mapas de URL e serviços de back-end.

Utilize os mapas de URL regionais para configurar o direcionamento e as ações de tráfego. Os recursos do Google Cloud associados a mapas de URL incluem os seguintes:

  • Regra de rota
  • Correspondência com a regra
  • Ação de regra

Utilize serviços de back-end regionais para configurar políticas de tráfego. Os recursos do Google Cloud associados a serviços de back-end incluem os seguintes:

  • Política do balanceador de carga de localidade
  • Configurações do balanceador de carga de hash consistente
  • Disjuntores
  • Detecção de outlier
Veja no diagrama a seguir o que é usado para implementar cada recurso.

Direcionamento de tráfego do Cloud Load Balancing (clique para ampliar)
Modelo de dados do Cloud Load Balancing (clique para ampliar)

Como rotear solicitações para back-ends

No balanceamento de carga interno HTTP(S), o back-end do tráfego é determinado pelo uso de uma abordagem de duas etapas:

  • O balanceador de carga seleciona um serviço de back-end que inclua back-ends. Eles podem ser instâncias de máquina virtual (VM) do Compute Engine em um grupo de instâncias não gerenciadas, VMs do Compute Engine em um grupo de instâncias gerenciadas (MIG, na sigla em inglês) ou contêineres por meio de um nó do Google Kubernetes Engine (GKE) em um grupo de endpoints de rede (NEG, na sigla em inglês). O balanceador de carga escolhe um serviço de back-end com base nas regras definidas em um mapa de URL regional.
  • O serviço de back-end seleciona uma instância de back-end com base nas políticas definidas em um serviço de back-end regional.

Ao configurar o roteamento, escolha um dos modos a seguir:

  • Regra simples de host e caminho
  • Regra avançada de host, caminho e rota

Em cada mapa de URLs, é possível usar as regras simples de host e caminho ou as avançadas de host, caminho e rota. Os dois modos são mutuamente exclusivos. Cada mapa de URL pode conter somente um desses modos.

Regra simples de host e caminho

Em uma regra simples de host e caminho, os mapas de URL funcionam conforme descrito na visão geral do mapa de URLs.

Veja no diagrama a seguir o fluxo lógico de uma regra simples de host e caminho.

Fluxo de mapa de URL simples
Fluxo de mapa de URLs simples

Regras de host são usadas para avaliar inicialmente uma solicitação. Um host é o domínio especificado pela solicitação. Se o host da solicitação corresponder a uma das entradas no campo hosts, a correspondência de caminho associada será usada.

Depois, essa correspondência será avaliada. As regras de caminho são avaliadas com base na semântica "primeiro as correspondências de caminho mais longas" e podem ser especificadas em qualquer ordem. Depois que a correspondência mais específica é encontrada, a solicitação é roteada para o respectivo serviço de back-end. Se a solicitação não for correspondente, o serviço de back-end padrão será usado.

Veja a seguir como é uma regra simples de host e caminho comum. Nela, o tráfego de vídeo vai para video-backend-service, e todo o restante para web-backend-service.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: regions/us-west1/backendServices/video-backend-service
region: regions/us-west1

Regra avançada de host, caminho e rota

Em comparação com as simples, as regras avançadas de host, caminho e rota fornecem mais opções de configuração. Com essas opções, é possível ativar padrões de gerenciamento de tráfego mais avançados e modificar algumas partes da semântica. Por exemplo, as regras de rota têm um valor de prioridade associado. Elas também são interpretadas em ordem de prioridade em vez de usar a semântica "primeiro as correspondências de caminho mais longas".

Como no exemplo anterior de regra simples de host e caminho, é possível usar um mapa de URL regional para configurar o gerenciamento de tráfego avançado. Por exemplo, com o mapa de URL a seguir, você configura o roteamento em que 95% do tráfego é encaminhado para um serviço de back-end e 5% para outro.

$ gcloud compute url-maps describe l7-ilb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: l7-ilb-map
pathMatchers:
- defaultService: regions/us-west1/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: regions/us-west1/backendServices/service-a
        weight: 95
      - backendService: regions/us-west1/backendServices/service-b
        weight: 5
region: regions/us-west1

Regras do host

Quando uma solicitação chega ao seu balanceador de carga, o campo host da solicitação é avaliado em relação às hostRules definidas no mapa de URLs. Cada regra de host consiste em uma lista de um ou mais hosts e uma correspondência de caminho (pathMatcher). Se não forem definidas hostRules, a solicitação será roteada para defaultService.

Para mais informações, consulte hostRules[] e defaultService na documentação da API de mapas de URL regionais.

Correspondências de caminho

Depois que uma solicitação corresponde a uma regra de host, o balanceador de carga avalia a correspondência de caminho aplicável ao host.

Uma correspondência de caminho é composta pelo seguinte:

  • Uma ou mais regras de caminho (pathRules) ou de rota (routeRules).
  • Um serviço padrão (defaultService), que é o serviço de back-end padrão usado quando nenhum outro corresponde.
Para mais informações, consulte pathMatchers[], pathMatchers[].pathRules[] e pathMatchers[].routeRules[] na documentação da API de mapas de URL regionais.

Regras para caminhos

As regras de caminho (pathRules) especificam um ou mais caminhos de URL, como / ou /video. Geralmente, elas são destinadas ao tipo de roteamento simples baseado em host e caminho descrito anteriormente.

Para mais informações, consulte pathRules[] na documentação da API de mapas de URL regionais.

Regras de rota

A regra de rota (routeRules) corresponde às informações em uma solicitação recebida e decide o roteamento com base na correspondência.

Ela pode conter várias regras de correspondência diferentes (matchRules) e muitas ações de rota distintas (routeAction).

Uma regra de correspondência avalia a solicitação recebida com base nos parâmetros de consulta, cabeçalhos e caminhos da solicitação HTTP(S). As regras de correspondência são compatíveis com vários tipos de correspondência, como as de prefixo, e de modificadores, como a não diferenciação de maiúsculas e minúsculas. Assim, por exemplo, é possível enviar solicitações HTTP(S) a um conjunto de back-ends com base na presença de um cabeçalho HTTP personalizado.

Se você tiver várias regras de rota, elas serão executadas pelo balanceador de carga em ordem de prioridade, com base no campo priority. Assim, é possível especificar uma lógica personalizada na correspondência, no roteamento e em outras ações.

Em uma determinada regra de rota, quando a primeira correspondência é feita, o balanceador de carga para de avaliar as regras de correspondência, e todas as restantes são ignoradas.

O Google Cloud realiza as ações a seguir:

  1. Procura a primeira regra de correspondência aplicável à solicitação.
  2. Interrompe a procura por outras regras de correspondência.
  3. Aplica as ações de rota correspondentes.

As regras de rota têm vários componentes, conforme descrito na tabela a seguir.

Componente da regra de rota (API field name) Descrição
Prioridade (priority) Um número de 0 a 2.147.483.647 (ou seja, 2³¹ - 1) atribuído a uma regra de rota em uma determinada correspondência de caminho.

A prioridade determina a ordem da avaliação da regra de rota. A prioridade de uma regra diminui à medida que o número dela aumenta. Assim, uma regra com prioridade 4 é avaliada antes de outra com prioridade 25. A primeira regra que corresponde à solicitação é aplicada.

Os números de prioridade podem ser diferentes. Não é possível criar mais de uma regra com a mesma prioridade.
Descrição (description) Uma descrição opcional de até 1.024 caracteres.
Serviço (service) O URL completo ou parcial do recurso do serviço de back-end a que o tráfego será direcionado se essa regra for correspondida.
Regras de correspondência (matchRules) Uma ou mais regras avaliadas em relação à solicitação. Essas matchRules podem corresponder a todos os atributos HTTP da solicitação ou a um subconjunto deles, como o caminho, os cabeçalhos HTTP e os parâmetros de consulta (GET).

Em uma matchRule, todos os critérios correspondentes precisam ser atendidos para que as routeActions da routeRule entrem em vigor. Se uma routeRule tiver várias matchRules, as routeActions da routeRule entrarão em vigor quando uma solicitação corresponder a uma das matchRules da routeRule.
Ação de rota (routeAction) Possibilita que você especifique quais ações serão realizadas quando os critérios da regra de correspondência forem atendidos. Elas incluem a divisão de tráfego, regravações de URL, repetição e espelhamento, injeção de falhas e políticas de CORS.
Ação de redirecionamento (urlRedirect) É possível configurar uma ação para responder com um redirecionamento HTTP quando os critérios da regra de correspondência forem atendidos. Não é possível usar esse campo com uma ação de rota.
Ação de cabeçalho (headerAction) É possível configurar regras de transformação de cabeçalhos de solicitação e resposta quando os critérios nas matchRules forem atendidos.

Para mais informações, consulte os campos a seguir na documentação da API de mapas de URL regionais:

  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

Corresponder às regras

As regras de correspondência (matchRules) se aplicam a um ou mais atributos de uma solicitação e realizam ações especificadas na regra de rota. Veja na lista a seguir alguns exemplos de atributos de solicitação que podem ser correspondidos por meio de regras de correspondência:

  • Host: um nome de host é a parte do nome de domínio de um URL. Por exemplo, a parte do nome do host do URL http://example.net/video/hd é example.net. Na solicitação, o nome de host vem do cabeçalho Host, conforme mostrado neste exemplo de comando curl. Nele, 10.1.2.9 é o endereço IP com a carga balanceada:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Os caminhos vêm depois do nome de host. Por exemplo, /images. A regra pode especificar se a correspondência deve ser feita com todo o caminho ou apenas com a parte inicial dele.

  • Outros parâmetros de solicitação HTTP, como cabeçalhos, que permitem a correspondência de cookies e baseada em parâmetros de consulta (variáveis GET).

Para uma lista completa de regras de correspondência compatíveis, consulte pathMatchers[].routeRules[].matchRules[] na documentação da API de mapas de URL regionais.

Ações de rota

As ações de rota são específicas e realizadas quando uma regra de rota corresponde aos atributos de uma solicitação.

Ação de rota (API field name) Descrição
Redirecionamentos (urlRedirect) Retorna um código de resposta 3xx configurável. Ele também define o cabeçalho de resposta Location com o URI apropriado. O host e o caminho são substituídos conforme especificado na ação de redirecionamento.
Regravações de URL (urlRewrite) Regrava a parte do nome do host e do caminho do URL ou ambas antes de enviar uma solicitação ao serviço de back-end selecionado.
Transformações de cabeçalho (headerAction) Adiciona e remove cabeçalhos antes de enviar uma solicitação ao serviço de back-end. Também é possível adicionar ou remover cabeçalhos depois de receber uma resposta do serviço de back-end.
Espelhamento de tráfego (requestMirrorPolicy) Além de encaminhar a solicitação ao serviço de back-end selecionado, envia outra idêntica ao serviço de back-end de espelhamento configurado de forma autônoma. O balanceador de carga não espera por uma resposta do back-end a que ele envia a solicitação espelhada.

O espelhamento é adequado para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não na versão de produção.
Divisão de tráfego ponderada (weightedBackendServices) Permite a distribuição do tráfego de uma regra correspondida a vários serviços de back-end de maneira proporcional a um peso definido pelo usuário e atribuído ao serviço de back-end individual.

Esse recurso é útil para configurar implantações em estágios ou testes A/B. Por exemplo, a ação de rota pode ser configurada para que 99% do tráfego seja enviado a um serviço que executa uma versão estável de um aplicativo. Já 1% do tráfego é enviado a um serviço separado que executa uma versão mais recente desse aplicativo.
Novas tentativas (retryPolicy) Configura as condições em que o balanceador de carga faz novas tentativas das solicitações com falha, quanto tempo o balanceador aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas.
Tempo limite (timeout) Especifica o tempo limite da rota selecionada. Ele é calculado com base no momento entre o processamento total da solicitação e da resposta. O tempo limite inclui todas as novas tentativas.
Injeção de falha (faultInjectionPolicy) Insere erros ao atender ao veicular solicitações para simular falhas, incluindo alta latência, sobrecarga, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas.
Injeção de atraso (faultInjectionPolicy) Insere atrasos em uma parte de solicitações definida pelo usuário antes de enviar a solicitação ao serviço de back-end selecionado.
Abortar injeção (faultInjectionPolicy) Responde diretamente a uma fração de solicitações com códigos de status HTTP definidos pelo usuário, em vez de encaminhar essas solicitações ao serviço de back-end.
Políticas de segurança (corsPolicy) As políticas de compartilhamento de recursos de origem cruzada (CORS, na sigla em inglês) processam as configurações do balanceamento de carga interno HTTP(S) para aplicar solicitações CORS.

É possível especificar uma das ações de rota a seguir, chamadas de ações primárias no Console do Google Cloud:

  • Encaminhar o tráfego para um serviço (service).
  • Dividir o tráfego entre vários serviços (weightedBackendServices weight:x, em que x é < 100).
  • URLs de redirecionamento (urlRedirect).

Além disso, é possível combinar qualquer uma das ações de rota mencionadas anteriormente a uma ou mais destas, chamadas de ações de complemento no Console do Cloud:

  • Espelhar tráfego (requestMirrorPolicy).
  • Regravar host/caminho do URL (urlRewrite).
  • Tentar novamente solicitações com falha (retryPolicy).
  • Definir tempo limite (timeout).
  • Inserir falhas em um percentual do tráfego (faultInjectionPolicy).
  • Adicionar política de CORS (corsPolicy).
  • Gerenciar cabeçalhos de solicitação/resposta (headerAction).

Para mais informações sobre a configuração e a semântica das ações de rotas, consulte o seguinte na documentação da API de mapas de URL regionais:

  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Políticas de tráfego

Use os recursos do serviço de back-end para configurar políticas de tráfego. Com elas, é possível ativar o balanceamento de carga ajustado em um grupo de instâncias ou de endpoints de rede (NEG). Essas políticas só entram em vigor depois que um serviço de back-end for selecionado por meio do mapa de URL regional, conforme descrito anteriormente.

Com as políticas de tráfego, é possível fazer o seguinte:

  • Controlar o algoritmo do balanceamento de carga entre as instâncias no serviço de back-end.
  • Controlar o volume de conexões com um serviço de upstream.
  • Controlar a remoção de hosts não íntegros de um serviço de back-end.

Os recursos da política de tráfego a seguir são configurados no serviço de back-end regional.

Política de tráfego (API field name) Descrição
Política de balanceamento de carga (LocalityLbPolicy) Em um serviço de back-end, a distribuição de tráfego é baseada em um modo e política de balanceamento de carga.

Primeiro, o serviço de back-end direciona o tráfego para um back-end (grupo de instâncias ou NEG) de acordo com o modo de balanceamento do back-end. Depois que um back-end é selecionado, o tráfego é distribuído entre as instâncias desse serviço de back-end de acordo com a política de balanceamento de carga.

Com o modo de balanceamento, o balanceador de carga seleciona primeiro uma localidade, como uma zona do Google Cloud. Depois, a política de balanceamento de carga determina um endpoint ou VM de back-end específica em um NEG.

Vários algoritmos de balanceamento de carga são compatíveis, como round-robin, solicitação mínima e outros. Para uma lista completa de algoritmos, consulte localityLbPolicy na documentação da API do serviço de back-end regional.
Afinidade da sessão (consistentHash) Inclui estes tipos de afinidade: baseada em cookie HTTP, baseada em cabeçalho HTTP, endereço IP do cliente e cookie gerado. A afinidade da sessão fornece uma tentativa de melhor esforço para enviar solicitações de um cliente específico ao mesmo back-end enquanto ele estiver íntegro e com capacidade.

Para mais informações sobre a afinidade da sessão, consulte consistentHash na documentação da API do serviço de back-end regional.
Detecção de outliers (outlierDetection) Conjunto de políticas que especifica os critérios da remoção de endpoints ou VMs de back-end não íntegros em NEGs. Inclui os critérios que definem quando um back-end ou endpoint é considerado íntegro o suficiente para receber tráfego novamente.

Para mais informações sobre a afinidade da sessão, consulte outlierDetection na documentação da API do serviço de back-end regional.
Disjuntores (circuitBreakers) Define limites máximos no volume de conexões e solicitações por conexão com um serviço de back-end.

Para mais informações sobre a afinidade da sessão, consulte circuitBreakers na documentação da API do serviço de back-end regional.

Limitações

  • RouteRule.service não funciona no momento. A solução é usar RouteRule.weightedBackendServices com um WeightedBackendService.
  • As expressões regulares de caminho pathMatchers.routeRules.matchRules.regexMatch não são compatíveis com o balanceamento de carga interno HTTP(S).
  • UrlMap.defaultRouteAction e UrlMap.defaultUrlRedirect não funcionam no momento. Você precisa especificar UrlMap.defaultService para processar o tráfego que não corresponde a nenhum dos hosts em UrlMap.hostRules[] nesse UrlMap.
  • UrlMap.pathMatchers[].defaultRouteAction e UrlMap.pathMatchers[].defaultUrlRedirect não funcionam no momento. Você precisa especificar UrlMap.pathMatchers[].defaultService para processar o tráfego que não corresponde a nenhuma das routeRules nessa pathMatcher.
  • Se o valor de BackendService.SessionAffinity não for "NONE", e BackendService.localityLbPolicy for definida como uma política de balanceamento de carga diferente de MAGLEV ou RING_HASH, as configurações de afinidade da sessão não terão efeito.
  • O comando gcloud compute backend-services import não exclui os campos de nível superior do recurso, como o serviço de back-end e o mapa de URL. Por exemplo, se você criar um serviço de back-end com configurações de circuitBreakers, será possível atualizá-las usando um comando gcloud compute backend-services import posterior. No entanto, não é possível excluir essas configurações do serviço de back-end. É possível excluir e recriar o recurso sem as configurações de circuitBreakers.

A seguir

  • Para configurar o gerenciamento de tráfego do balanceamento de carga interno HTTP(S), consulte esta página.