Nesta página, apresentamos uma visão geral dos recursos avançados de gerenciamento de tráfego disponíveis para balanceadores de carga de aplicativo externos regionais. Esta página é apenas sobre o balanceador de carga de aplicativo externo regional. Esses balanceadores de carga são sempre regionais e sempre estão no nível Standard. Se você usar um balanceador de carga em um modo diferente, consulte uma das seguintes páginas:
Visão geral do gerenciamento de tráfego para um balanceador de carga de aplicativo clássico
Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais
- 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
O direcionamento de tráfego permite direcionar o tráfego para instâncias de serviço com base em parâmetros HTTP, como cabeçalhos de 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 móvel. 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.
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 gerenciamento de tráfego, é possível definir divisões de tráfego com base em porcentagem 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.
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.
Extensibilidade com extensões de serviço
A integração com as extensões de serviço permite inserir lógica personalizada no caminho de dados de balanceamento de carga dos balanceadores de carga de aplicativo com suporte.
Para mais informações, consulte Visão geral das extensões de serviço.
Componentes do gerenciamento de tráfego
Em geral, os balanceadores de carga fornecem gerenciamento de tráfego por recursos de mapas de URL regionais e serviços de back-end regionais.Para balanceadores de carga de aplicativo internos entre regiões, o gerenciamento de tráfego usa os recursos de mapas de URLs globais e serviços de back-end globais.
Utilize os mapas de URL 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:
- Disjuntores
- Política do balanceador de carga de localidade
- Configurações do balanceador de carga de hash consistente
- Detecção de outlier
Veja no diagrama a seguir o que é usado para implementar cada recurso.
Como rotear solicitações para back-ends
Em balanceadores de carga de aplicativo externos regionais, o back-end do tráfego é determinado usando uma abordagem em duas fases:- 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
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.
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 lb-map
defaultService: regions/us-west1/backendServices/web-backend-service
hostRules:
- hosts:
- '*'
pathMatcher: pathmap
name: lb-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 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 lb-map
defaultService: regions/us-west1/backendServices/service-a
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: lb-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 nenhuma das hostRules forem definidas, a solicitação será roteada para
defaultService.
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 serviço de back-end corresponde.
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 que tenha base em regras simples de host e caminho,
como descrito anteriormente.
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.
Observação: as opções de correspondência e a semântica variam de acordo com a parte da solicitação que é correspondente. Para mais informações, consultematchRules[] na documentação da API de mapas de URL regionais.
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:
- Procura a primeira regra de correspondência aplicável à solicitação.
- Interrompe a procura por outras regras de correspondência.
- 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) |
Permite especificar 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. |
routeRules[]routeRules[].priorityrouteRules[].descriptionrouteRules[].servicerouteRules[].matchRules[]routeRules[].routeActionrouteRules[].urlRedirectrouteRules[].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çalhoHost, 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).
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. Observe as seguintes limitações ao usar o espelhamento de tráfego:
|
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 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 das solicitações definida pelo usuário antes de enviar a solicitação ao serviço de back-end selecionado. |
Injeção de aborto (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 entre origens (CORS) processam as configurações para aplicar solicitações CORS. |
É possível especificar uma das seguintes ações de rota:
- Encaminhar o tráfego para um serviço (
service). - Dividir o tráfego entre vários serviços (
weightedBackendServices weight:x, em que x precisa estar entre 0 e 1.000). - Redirecionar URLs (
urlRedirect).
Além disso, é possível combinar qualquer uma das ações de rota mencionadas anteriormente com uma ou mais das seguintes ações de rota:
- Espelhar tráfego (
requestMirrorPolicy). - Reescreva o host e o 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). - Manipular cabeçalhos de solicitação ou resposta (
headerAction).
urlRedirecturlRewriteheaderActionrequestMirrorPolicyweightedBackendServicesretryPolicytimeoutfaultInjectionPolicycorsPolicy
Redirecionamentos HTTP para HTTPS
Se você precisar redirecionar o tráfego HTTP para HTTPS, crie duas regras de encaminhamento com um endereço IP comum.
Para um exemplo completo, consulte Configurar o redirecionamento de HTTP para HTTPS para balanceadores de carga de aplicativo externos regionais.Políticas de tráfego
Ao usar recursos de serviço de back-end, é possível configurar políticas de tráfego para ajustar o balanceamento de carga em um grupo de instâncias ou de endpoints da rede (NEG, na sigla em inglês). Essas políticas só entram em vigor depois que um serviço de back-end for selecionado pelo mapa de URL, 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 upstream.
- Controlar a remoção de hosts não íntegros de um serviço de back-end.
Política de tráfego (API field name) |
Descrição |
|---|---|
Política de localidade do 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 localidade do balanceamento de carga. O modo de balanceamento determina a ponderação/fração de tráfego que precisa ser enviada para cada back-end
(grupo de instâncias ou NEG Para os modos de balanceamento suportados, consulte Modo de balanceamento. Para os algoritmos da política de balanceamento de carga suportados, consulte |
Afinidade da sessão (consistentHash) |
Inclui estes tipos de afinidade: baseada em cookie HTTP, baseada em cabeçalho HTTP, endereço IP do cliente, afinidade de sessão baseada em cookie com estado e afinidade de cookie gerada. 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 |
Detecção de outliers (outlierDetection) |
Um conjunto de políticas que especificam os critérios para remoção de VMs de back-ends não íntegros ou endpoints em NEGs, juntamente com 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 detecção de outliers, consulte
|
Disjuntores (circuitBreakers) |
Define limites máximos no volume de conexões e solicitações por conexão para um serviço de back-end. Para mais informações sobre a
quebra de circuito, consulte |
A seguir
- Para saber como configurar o gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais, consulte esta página.