Visão geral do gerenciamento de tráfego para um balanceador de carga de aplicativo clássico

Nesta página, você encontra uma visão geral dos recursos de gerenciamento de tráfego disponíveis para o balanceador de carga de aplicativo clássico. Esta página é apenas sobre o balanceador de carga de aplicativo clássico. Se você estiver usando um balanceador de carga em um modo diferente com suporte ao conjunto expandido de recursos de gerenciamento de tráfego, consulte uma das seguintes páginas:

O balanceador de carga de aplicativo clássico é compatível com a funcionalidade de gerenciamento de tráfego que permite usar os seguintes recursos:

Para configurar esses recursos, use o mapa de URLs do balanceador de carga. Para mais informações, consulte os seguintes tópicos:

Componentes do gerenciamento de tráfego

De modo geral, os balanceadores de carga de aplicativo externos usam mapas de URL globais para fornecer gerenciamento de tráfego.

O balanceador de carga fornece as seguintes ações principais e mutuamente exclusivas:

  • Encaminhar solicitações para um serviço de back-end
  • Executar um redirecionamento

Ao configurar um balanceador de carga, é possível configurar uma ação de regravação de URL antes que o balanceador de carga envie solicitações ao serviço ou ao bucket de back-end.

As regravações ou os redirecionamentos podem ser aplicados em três níveis ao mapa de URLs:

  • No pathRule, em que a ação entra em vigor quando um caminho é correspondido
  • No pathMatcher, em que a ação entra em vigor quando não há caminhos correspondentes a este pathMatcher
  • No urlMap, em que a ação entra em vigor quando nenhum dos hosts especificados em qualquer uma das regras de host é correspondido

Usar routeRules em um pathMatcher é uma alternativa ao uso de pathRules. pathRules e routeRules não podem aparecer juntos no mesmo pathMatcher. Ao contrário de pathRules, em que a ordem não importa, as routeRules são examinadas em ordem. Um routeRule pode testar o caminho do URL, os cabeçalhos HTTP e os parâmetros de consulta de URL.

Exemplos de casos de uso

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

Substituições

As regravações de URL permitem que você apresente aos usuários externos URLs diferentes daqueles usados pelos seus serviços.

Uma regravação de URL separa um URL de um recurso. É possível converter com base em URLs legíveis, que são mais fáceis de lembrar e usar, transformando-os em URLs compatíveis com mecanismos de pesquisa, que são mais fáceis de encontrar pelos mecanismos de pesquisa, ou em URLs internos específicos da implementação.

O recurso de reescrita de URL faz o seguinte:

  1. Ler o URL recebido na solicitação.
  2. Substituir o host, o caminho ou ambos, transformando o URL antes de direcionar o tráfego para o serviço ou bucket de back-end.

No diagrama a seguir:

  1. Um usuário no Japão envia uma solicitação para o URL www.mydomain.com/static/images/someimage.jpg.
  2. Quando a solicitação chega ao balanceador de carga de aplicativo externo, ele usa as informações no mapa de URL para regravar o URL como www.myorigin.com/august_snapshot/images/someimage.jpg.
  3. (Opcional) Neste exemplo, o mapa de URLs envia a solicitação para um back-end externo.
Regravação de URL com o balanceador de carga de aplicativo clássico.
Figura 1. Regravação de URL com o balanceador de carga de aplicativo clássico.

Para ver um exemplo de configuração, consulte Regravações.

Redirecionamentos

Com redirecionamentos de URL, é possível redirecionar solicitações de clientes de um URL para outro.

Isso inclui a capacidade de:

  • redirecionar todas as solicitações HTTP para solicitações HTTPS;
  • redirecionar para um URL diferente formado ao modificar o host, o caminho ou a parte do host e do caminho do URL, ou mesmo ao remover ou manter parâmetros de consulta;
  • escolher os códigos de resposta de redirecionamento a serem emitidos.

Use os redirecionamentos de URL para os seguintes recursos:

  • fornecer o encurtamento de URL. Os URLs voltados para o cliente podem ser significativamente mais curtos. Esse serviço emite um redirecionamento para a página da Web com o URL longo;
  • evitar links corrompidos quando páginas da Web são movidas ou ficam desatualizadas;
  • permitir que vários nomes de domínio pertencentes ao mesmo proprietário façam referência a um único site;
  • evitar o trabalho e as ineficiências da configuração de soluções alternativas no servidor de back-end para aceitar o redirecionamento necessário;
  • reduzir a latência. Redirecionamentos criados na borda podem resultar em menor latência em comparação com redirecionamentos criados nos endpoints de back-end.

Os redirecionamentos de HTTP para HTTPS ajudam você a:

  • atender aos requisitos de conformidade (como HIPAA) para tráfego criptografado;
  • redirecionar solicitações por meio de HTTPS em vez de rejeitar solicitações enviadas com o protocolo HTTP;
  • melhorar o perfil de segurança do seu aplicativo redirecionando o tráfego no próprio balanceador de carga da camada 7, em vez de implementar o redirecionamento no servidor de back-end.

No diagrama a seguir:

  1. Um usuário no Japão envia uma solicitação GET http://example.com/img1.
  2. Com base no redirecionamento definido no mapa de URLs, o balanceador de carga retorna um redirecionamento HTTP/1.1 302 Found Location: https://example.com/img1, redirecionando a solicitação HTTP para uma solicitação HTTPS.
  3. O navegador do usuário envia uma solicitação GET https://example.com/img1.
Redirecionamento de URL com o balanceador de carga de aplicativo clássico.
Figura 2. Redirecionamento de URL com o balanceador de carga de aplicativo clássico.

Para ver um exemplo de configuração, consulte Redirecionamentos.

Códigos de resposta compatíveis

Os códigos de resposta de redirecionamento compatíveis estão listados na tabela.

Código de resposta Número Observações
MOVED_PERMANENTLY_DEFAULT 301
FOUND 302
PERMANENT_REDIRECT 308 Neste caso, o método de solicitação é mantido.
TEMPORARY_REDIRECT 307 Neste caso, o método de solicitação é mantido.
SEE_OTHER 303

Roteamento com base em cabeçalho e em parâmetros

O roteamento com base em cabeçalho e em parâmetros permite que um balanceador de carga tome decisões de roteamento baseadas em cabeçalhos HTTP e em parâmetros de consulta de URL.

Com esse recurso, é possível simplificar sua arquitetura de nuvem sem implantar níveis adicionais de proxies (NGINX, por exemplo) para fazer o roteamento.

É possível usar o balanceador de carga de aplicativo externo para realizar as seguintes ações:

  • Teste A/B
  • Atribuir clientes a diferentes conjuntos de serviços em execução em back-ends
  • Fornecer páginas e proporcionar experiências diferentes com base em diferentes categorias de dispositivos de origem das solicitações

Depois que um pathMatcher é selecionado com base na string do host, o routeRules no pathMatcher seleciona um caminho do URL. Para mais informações, consulte a visão geral dos mapas de URL.

Exemplo: configuração de testes A/B com roteamento baseado em parâmetros de consulta

O exemplo a seguir mostra como fazer testes A/B por meio da correspondência na string de consulta para especificar o experimento e a entrada.

Suponha que você queira garantir que as solicitações sejam tratadas da seguinte maneira:

  • Todas as solicitações com o valor de parâmetro de consulta A vão para o serviço de back-end chamado BackendServiceForProcessingOptionA.
  • Todas as solicitações com o valor de parâmetro de consulta B vão para o serviço de back-end chamado BackendServiceForProcessingOptionB.

Esses requisitos estão resumidos na tabela a seguir.

Solicitação Serviço de back-end
http://test.mydomain.com?ABTest=A BackendServiceForProcessingOptionA
http://test.mydomain.com?ABTest=B BackendServiceForProcessingOptionB

Para definir isso no seu mapa de URLs global, crie as seguintes configurações.

Correspondência Ação
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = A		 pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionA
pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].name = ABTest

pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].exactMatch = B		 pathMatchers[].routeRules[].service = BackendServiceForProcessingOptionB

Para ver um exemplo de configuração, consulte Roteamento com base em cabeçalho e em parâmetro.

Como rotear solicitações para back-ends

O back-end do tráfego é determinado usando uma abordagem de duas fases:

  • O balanceador de carga seleciona um serviço de back-end que inclua back-ends. Os back-ends podem ser os seguintes:

    • 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)
    • Contêineres por meio de um nó do Google Kubernetes Engine (GKE) em um grupo de endpoints de rede zonais (NEG, na sigla em inglês)
    • Back-ends externos fora do Google Cloud em um NEG da Internet
    • Cloud Storage em buckets de back-end
    • Serviços do App Engine, Cloud Functions ou Cloud Run em um NEG sem servidor

    O balanceador de carga escolhe um serviço de back-end com base em regras definidas em um mapa de URLs global.

  • O serviço de back-end seleciona uma instância de back-end com base em políticas definidas em um serviço de back-end global.

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

  • Teste simples de host e caminho por meio de pathRules
  • Teste avançado de solicitação por meio de routeRules

Em cada mapa de URL, é 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 com uma regra simples de host e caminho
Figura 3. Fluxo de mapa de URL com uma regra simples de host e caminho

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 ext-https-map

defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: ext-https-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Para ver um exemplo de configuração, consulte Host e caminho.

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, em vez de usar a semântica de caminho mais longo, as regras de rota são executadas em ordem.

Como no exemplo de regra simples de host e caminho, é possível configurar o gerenciamento avançado de tráfego por meio de um mapa de URLs global. No entanto, em vez de usar pathMatchers[].pathRules[], você usa pathMatchers[].routeRules[].

As seções a seguir explicam os componentes da regra avançada de host, caminho e rota.

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 nenhuma das hostRules forem definidas, a solicitação será roteada para defaultService.

Para mais informações, consulte hostRules[] e defaultService na documentação da API de mapa de URLs global.

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 pelos seguintes componentes:

  • Uma ou mais regras de caminho (pathRules) ou de rota (routeRules).

  • Uma regra padrão executada quando nenhum outro serviço de back-end corresponde. A regra tem as seguintes opções mutuamente exclusivas:

    • Um serviço padrão especifica o serviço de back-end padrão para roteamento quando nenhum outro serviço de back-end corresponde.
    • Um redirecionamento padrão especifica para qual URL redirecionar quando nenhum outro serviço de back-end corresponde.

Quando o balanceador de carga é configurado para um serviço padrão, ele também pode ser configurado para regravar o URL antes de enviar a solicitação ao serviço padrão.

Para mais informações, consulte pathMatchers[], pathMatchers[].pathRules[] e pathMatchers[].routeRules[] na documentação da API de mapa de URLs global.

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 que tenha base em regras simples de host e caminho, como descrito anteriormente.

Para mais informações, consulte pathRules[] na documentação da API de mapa de URLs global.

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.

Para ver uma lista detalhada de opções compatíveis com matchRules, consulte matchRules[] na documentação da API de mapa de URLs global.

Se você tiver várias regras de rota, o balanceador de carga as executará em ordem, o que permite especificar uma lógica personalizada para correspondência, roteamento e 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^31) -1) atribuído a uma regra de rota dentro de uma determinada correspondência de caminho para especificar a ordem da avaliação da regra de rota.

A prioridade mais alta é 0. A prioridade mais baixa é 2147483647. Por exemplo, uma regra com prioridade 4 é avaliada antes de uma regra com prioridade 25. A primeira regra que corresponde à solicitação é aplicada.

Os números de prioridade podem ter lacunas e não precisam ser contíguos. Não é possível criar várias regras 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) Permite que você especifique uma ação de regravação de URL a ser realizada quando os critérios da regra de correspondência forem atendidos.
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.

Para mais informações, consulte os campos a seguir na documentação da API de mapa de URLs global:

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

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 cookie e a baseada em parâmetros de consulta (variáveis GET). A correspondência de expressões regulares para valores de cabeçalho não é aceita.

Para ver uma lista completa de regras de correspondência compatíveis, consulte pathMatchers[].routeRules[].matchRules[] na documentação da API de mapa de URLs global.

Como configurar o gerenciamento de tráfego

Use o console do Google Cloud, a gcloud ou a API Cloud Load Balancing para configurar o gerenciamento de tráfego. No ambiente de configuração escolhido, defina o gerenciamento de tráfego por meio de configurações YAML.

Se precisar de ajuda para gravar esses arquivos YAML, use os recursos a seguir: