Visão geral do gerenciamento de tráfego avançado

O Traffic Director fornece recursos avançados de gerenciamento de tráfego que oferecem controle detalhado sobre como o tráfego é tratado. O Traffic Director é compatível com estes casos de uso:

  • Roteamento detalhado de solicitações para (um ou mais) serviços
  • Ações baseadas em solicitação e resposta, como redirecionamentos e transformações de cabeçalho
  • Distribuição de tráfego ajustada entre os back-ends de um serviço para melhor balanceamento de carga

Esses recursos avançados de gerenciamento de tráfego permitem que você atenda aos seus objetivos de disponibilidade e desempenho. Um dos benefícios de usar o Traffic Director para esses casos de uso é que você pode atualizar a forma como o tráfego é gerenciado sem precisar modificar o código do aplicativo.

Exemplos de casos de uso

O gerenciamento de tráfego avançado atende a muitos casos de uso. Nesta seção, você verá alguns exemplos detalhados.

Veja mais exemplos, incluindo código de amostra, nos guias Como configurar o gerenciamento de tráfego avançado e Como configurar serviços gRPC sem proxy com base em VM com gerenciamento de tráfego avançado .

Roteamento de tráfego detalhado para personalização

Você pode rotear o tráfego para um serviço com base nos parâmetros da solicitação. Por exemplo, você pode usá-lo para fornecer uma experiência mais personalizada para usuários do Android. No diagrama a seguir, o Traffic Director configura a malha de serviço para enviar solicitações com o cabeçalho user-agent:Android para o serviço Android em vez do serviço genérico.

Roteamento com base no cabeçalho do user agent definido como Android (clique para ampliar)
Roteamento baseado no cabeçalho user-agent definido como Android (clique para ampliar)

Divisão de tráfego baseada em peso para implantações mais seguras

A implantação de uma nova versão de um serviço de produção atual pode ser arriscada. Mesmo depois que os testes forem aprovados em um ambiente de teste, talvez você não queira encaminhar todos os usuários para a nova versão imediatamente.

O Traffic Director permite que você defina divisões de tráfego com base no peso para distribuir o tráfego entre vários serviços. Por exemplo, é possível enviar 1% do tráfego para a nova versão do seu serviço, monitorar se tudo funciona e aumentar gradualmente a proporção de tráfego para o novo serviço.

Divisão de tráfego com base no peso do Traffic Director (clique para ampliar)
Divisão de tráfego com base no peso do Traffic Director (clique para ampliar)

Espelhamento de tráfego para depuração

Ao depurar um problema, pode ser útil enviar cópias do tráfego de produção para um serviço de depuração. O Traffic Director permite configurar políticas de espelhamento de solicitações para que as solicitações sejam enviadas a um serviço e as cópias dessas solicitações sejam enviadas para outro serviço.

Espelhamento de tráfego do Traffic Director (clique para ampliar)
Espelhamento de tráfego do Traffic Director (clique para ampliar)

Balanceamento de carga ajustado para desempenho

Dependendo das características do seu aplicativo, você pode melhorar o desempenho e a disponibilidade ajustando o modo como o tráfego é distribuído entre os back-ends de um serviço. Com o Traffic Director, é possível aplicar algoritmos avançados de balanceamento de carga para que o tráfego seja distribuído de acordo com suas necessidades.

O diagrama a seguir, em contraste com os diagramas anteriores, mostra um serviço de back-end de destino (Serviço de produção) e os back-ends dele (Máquina virtual 1, Máquina virtual 2, Máquina virtual 3). Com o gerenciamento de tráfego avançado, você pode configurar como um serviço de back-end de destino é selecionado e como o tráfego é distribuído entre os back-ends desse serviço de destino.

Balanceamento de carga do Traffic Director (clique para ampliar)
Balanceamento de carga do Traffic Director (clique para ampliar)

Como funciona o gerenciamento de tráfego avançado

Para configurar o gerenciamento de tráfego avançado, use os recursos do serviço de regra de roteamento e dos serviços de back-end usados ao configurar o Traffic Director. O Traffic Director, por sua vez, configura seus proxies Envoy e aplicativos gRPC sem proxy para aplicar as políticas avançadas de gerenciamento de tráfego que você configurou.

Em geral, você faz o seguinte:

  1. Configure o mapa de regras de roteamento para fazer o seguinte, com base nas características da solicitação de saída:

    1. Selecione o serviço de back-end para que as solicitações são roteadas.

    2. Opcionalmente, realize ações adicionais

  2. Configure o serviço (back-end) para controlar como o tráfego é distribuído para back-ends e endpoints depois que um serviço de destino é selecionado.

Roteamento de tráfego e ações

No Traffic Director, o mapa de regras de roteamento refere-se à combinação dos recursos de mapa de URL, regra de encaminhamento e proxy de destino. Todos os recursos de gerenciamento de tráfego avançado relacionados ao roteamento e às ações são configurados usando o mapa de URL.

É possível configurar os recursos de gerenciamento de tráfego avançados a seguir no mapa de regras de roteamento.

Processamento de solicitações

Quando um cliente envia uma solicitação, ela é tratada da seguinte maneira:

  1. A solicitação corresponde a um mapa de regras de roteamento específico. Essa correspondência é feita da seguinte maneira:
    1. Se você estiver usando o Envoy:
      1. O endereço IP e a porta de destino da solicitação são comparados com o endereço IP e a porta das regras de encaminhamento em todos os mapas de regras de roteamento. Somente os mapas de regras de roteamento com regras de encaminhamento que têm o esquema de balanceamento de carga INTERNAL_SELF_MANAGED são considerados.
      2. A regra de encaminhamento que corresponde à solicitação se refere a um proxy HTTP ou gRPC de destino, que referencia um mapa de URL. Esse mapa de URL contém informações usadas para criar roteamento e ações.
    2. Se você estiver usando o gRPC sem proxy:
      1. O endereço IP da solicitação é ignorado porque só é possível usar o endereço IP 0.0.0.0 ao criar uma regra de encaminhamento que faça referência a um proxy gRPC de destino. Somente os mapas de regras de roteamento com regras de encaminhamento que têm o esquema de balanceamento de carga INTERNAL_SELF_MANAGED são considerados.
      2. A porta no URI de destino (por exemplo, xds:///foo.myservice:8080) é comparada à porta de regras de encaminhamento com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED. O endereço IP de uma regra de encaminhamento não é usado.
      3. A regra de encaminhamento que corresponde à solicitação se refere a um proxy gRPC de destino, que referencia um mapa de URL. Esse mapa de URL contém informações usadas para criar roteamento e ações.
  2. Quando o mapa de URL apropriado é determinado, o mapa de URL é avaliado para determinar o serviço de back-end de destino e, opcionalmente, aplicar ações.
  3. Depois que o serviço de back-end de destino é selecionado, o tráfego é distribuído entre os back-ends ou os endpoints desse serviço de back-end de acordo com a configuração do recurso do serviço de back-end.

A segunda etapa é descrita na seção a seguir, Roteamento simples com base no host e no caminho. A terceira etapa é discutida em Roteamento e ações avançados.

Roteamento simples com base no host e no caminho

O Traffic Director é compatível com os esquemas de roteamento simplificados e com um esquema mais avançado. Os esquemas de roteamento mais avançados, incluindo ações, estão descritos na próxima seção, Roteamento avançado e ações. No esquema simples, você especifica um host e, opcionalmente, um caminho. O host e o caminho da solicitação são avaliados para determinar o serviço a que uma solicitação será roteada.

  • O host da solicitação é a parte do nome de domínio de um URL. Por exemplo, a parte do host do URL http://example.com/video/ é example.com.
  • O caminho da solicitação faz parte do URL que segue o nome do host. Por exemplo, /video em http://example.com/video.
Como configurar um roteamento simples com base no host e no caminho

O roteamento simples com base no host e no caminho é configurado no mapa de regras de roteamento, que consiste em:

  • uma regra de encaminhamento global;
  • um proxy HTTP de destino ou proxy SSL de destino;
  • um mapa de URL.

A maior parte da configuração é feita no mapa de URLs e, depois de criar o mapa de regras de roteamento inicial, geralmente só é necessário modificar a parte do mapa de URL do mapa de regras de roteamento. Neste diagrama, as regras de caminho têm ações semelhantes às do próximo diagrama.

Roteamento com base em recursos de host e caminho (clique para ampliar)
Roteamento com base em recursos de host e caminho (clique para ampliar)

A regra mais simples é uma regra padrão, em que você especifica apenas uma regra de host curinga (*) e uma correspondência de caminho com um serviço padrão. Depois de criar a regra padrão, você pode adicionar outras regras, que especificam diferentes hosts e caminhos. As solicitações de saída são avaliadas de acordo com essas regras, da seguinte maneira:

Se o host de uma solicitação (por exemplo, example.com) corresponder a uma regra de host:

  1. A correspondência de caminho é avaliada a seguir.
  2. Cada correspondência de caminho contém uma ou mais regras de caminho que são avaliadas em relação ao caminho da solicitação.
  3. Se uma correspondência for encontrada, a solicitação será roteada para o serviço especificado na regra de caminho.
  4. Cada correspondência de caminho contém um serviço padrão para o qual as solicitações são roteadas se a regra de host corresponder, mas nenhuma regra de caminho corresponder.

Se a solicitação não corresponder a nenhuma das regras de host especificadas, ela será roteada para o serviço especificado na regra padrão.

Para mais informações sobre os campos do recurso do mapa de URL e como eles funcionam, consulte a página da API REST urlMaps.

Roteamento avançado e ações

Se você quiser fazer mais do que encaminhar uma solicitação com base no host e no caminho dela, poderá configurar regras avançadas para rotear solicitações e realizar ações.

Roteamento avançado (clique para ampliar)
Roteamento avançado (clique para ampliar)

De modo geral, o roteamento avançado e as ações funcionam da seguinte maneira:

  1. Assim como no roteamento simples, o host da solicitação é comparado às regras de host que você configura no mapa de URL. Se o host de uma solicitação corresponder a uma regra de host, a correspondência de caminho da regra de host será avaliada.
  2. A correspondência de caminho contém uma ou mais regras de rota que são avaliadas em relação à solicitação.
    1. Essas regras de rota são avaliadas em ordem de prioridade, combinando os atributos da solicitação (host, caminho, cabeçalho e parâmetros de consulta) de acordo com condições de correspondência específicas, por exemplo, correspondência de prefixo.
  3. Depois que uma regra de rota for selecionada, as ações poderão ser aplicadas. A ação padrão é encaminhar a solicitação para um único serviço de destino, mas também é possível configurar outras ações.
Roteamento avançado

O roteamento avançado é semelhante ao roteamento simples descrito acima, exceto que é possível especificar a prioridade da regra e outras condições de correspondência, conforme descrito abaixo.

Com o roteamento avançado, você precisa especificar uma prioridade exclusiva para cada regra. Essa prioridade determina a ordem em que as regras de rota são avaliadas. Os valores de prioridade mais baixa são priorizados em relação aos valores de prioridade mais alta. Quando uma solicitação corresponde a uma regra, a regra é aplicada e outras regras são ignoradas.

O roteamento avançado também é compatível com outras condições de correspondência. Por exemplo, é possível especificar que uma regra corresponderá ao cabeçalho de uma solicitação se o nome do cabeçalho corresponder exatamente ou apenas parcialmente, por exemplo, com base no prefixo ou no sufixo. A correspondência pode ser feita com base na avaliação do nome do cabeçalho com uma expressão regular ou em outros critérios, como a verificação da presença de um cabeçalho.

Ao combinar os parâmetros de host, caminho, cabeçalho e consulta com prioridades e condições de correspondência, é possível criar regras altamente expressivas que atendam aos seus requisitos exatos de gerenciamento de tráfego.

Hosts HTTP x hosts gRPC

Se você estiver escrevendo um aplicativo baseado em HTTP, o host é a parte do nome de domínio do URL que o aplicativo chama. Por exemplo, a parte do host do URL http://example.com/video/ é example.com.

Caso você esteja escrevendo um aplicativo baseado em gRPC, o host é o nome que um cliente usa no URI do canal para se conectar a um serviço específico. Por exemplo, a parte do host do URI do canal xds:///example.com é example.com.

Caminhos HTTP x caminhos gRPC

Se você estiver escrevendo um aplicativo baseado em HTTP, o caminho é a parte do URL que segue o nome do host, por exemplo, /video em http://example.com/video.

Se você estiver criando um aplicativo baseado em gRPC, o caminho estará no cabeçalho :path da solicitação HTTP/2 e será semelhante a /SERVICE_NAME/METHOD_NAME/. Por exemplo, se você chamar o método Download no serviço gRPC Example, o conteúdo do cabeçalho :path será semelhante a /Example/Download.

Outros cabeçalhos gRPC (metadados)

O gRPC é compatível com o envio de metadados entre o cliente gRPC e o servidor gRPC para fornecer informações adicionais sobre uma chamada RPC. Esses metadados estão na forma de pares de chave-valor transferidos como cabeçalhos na solicitação HTTP/2.

Ações

Com o Traffic Director, você especifica as ações que seus proxies Envoy ou aplicativos gRPC sem proxy realizam ao processar uma solicitação. As ações a seguir podem ser configuradas com o Traffic Director.

.
Ação (nome do campo da API) 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 envia a solicitação espelhada.

O espelhamento é útil 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 baseada em peso (weightedBackendServices) Permite que o tráfego de uma regra correspondente seja distribuído a vários serviços de back-end, de maneira proporcional a uma ponderação definida pelo usuário e atribuída 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.
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 para aplicar solicitações CORS.

Para mais informações sobre ações e como elas funcionam, consulte a referência da API de mapas de URL.

Em cada regra de rota, é 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).
  • Divida o tráfego entre vários serviços (weightedBackendServices).
  • URLs de redirecionamento (urlRedirect).

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

  • Gerenciar cabeçalhos de solicitação/resposta (headerAction).
  • 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).

Como as ações estão associadas a regras de rota específicas, o proxy Envoy ou o aplicativo gRPC sem proxy podem aplicar ações diferentes com base na solicitação em processamento.

Como distribuir tráfego entre os back-ends de um serviço

Conforme discutido em Processamento de solicitações, quando um cliente gerencia uma solicitação de saída, ele primeiro seleciona um serviço de destino. Depois de selecionar um serviço de destino, ele precisa descobrir qual back-end/endpoint deve receber a solicitação.

Como distribuir tráfego entre back-ends (clique para ampliar)
Como distribuir tráfego entre back-ends (clique para ampliar)

No diagrama acima, Regra foi simplificada. Normalmente, há uma regra de host, uma correspondência de caminho e uma ou mais regras de caminho ou rota. O serviço de destino é o serviço de back-end. Back-end 1, … e Back-end n realmente recebem e processam a solicitação. Esses back-ends podem ser máquinas virtuais do Compute Engine que hospedam o código do aplicativo do servidor, por exemplo.

Por padrão, o cliente que gerencia a solicitação enviará solicitações para o back-end íntegro mais próximo que tenha capacidade. Para evitar a sobrecarga de um back-end específico, ele balanceia as solicitações subsequentes em outros back-ends do serviço de destino usando o algoritmo de balanceamento de carga round-robin. Mas, em alguns casos, você pode querer um controle mais refinado sobre esse comportamento.

Balanceamento de carga, afinidade da sessão e proteção de back-ends

É possível definir as seguintes políticas de distribuição de tráfego em cada serviço.

Política (nome do campo da API) Descrição
Modo de balanceamento de carga (balancingMode) Controle como um grupo de endpoints de rede ou de instância gerenciada é selecionado depois que um serviço de destino é selecionado. É possível configurar o modo de balanceamento para distribuir a carga com base em conexões simultâneas, taxa de solicitação e muito mais.
Política de balanceamento de carga (localityLbPolicy) Define o algoritmo de balanceamento de carga usado para distribuir o tráfego entre back-ends em um grupo de endpoints de rede ou de grupo de instâncias gerenciadas. É possível escolher entre vários algoritmos diferentes, como round-robin, solicitação mínima e outros, para otimizar o desempenho.
Afinidade da sessão (sessionAffinity) A afinidade de 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. O Traffic Director é compatível com quatro opções diferentes de afinidade de sessão: endereço IP do cliente, baseado em cookie HTTP, base de cabeçalho HTTP e afinidade de cookie gerado e gerada pelo próprio Traffic Director.
Hash consistente (consistentHash) Pode ser usado para fornecer afinidade de sessão suave com base em cabeçalhos HTTP, cookies ou outras propriedades.
Disjuntores (circuitBreakers) Define limites máximos no volume de conexões e solicitações por conexão para um serviço de back-end.
Detecção de outliers (outlierDetection) Especifique os critérios para (1) remover back-ends não íntegros ou endpoints de grupos de instâncias gerenciadas ou de endpoints de rede e (2) adicionar um back-end ou endpoint de volta quando ele for considerado íntegro o suficiente para receber tráfego novamente. A verificação de integridade associada ao serviço determina se um back-end/endpoint é considerado íntegro.

Para mais informações sobre diferentes opções de distribuição de tráfego e como elas funcionam, consulte a referência da API de serviços de back-end.

Configuração de filtragem

Uma das principais responsabilidades do Traffic Director é gerar a configuração e enviá-la a vários clientes do Traffic Director, como proxies Envoy e/ou aplicativos gRPC. O Traffic Director controla a malha de serviço enviando a configuração aos clientes o que eles precisam fazer. O Traffic Director é o plano de controle.

Quando você cria ou atualiza uma configuração no Traffic Director, o Traffic Director traduz essa configuração em uma linguagem que os clientes possam entender. Por padrão, o Traffic Director compartilha essa configuração com todos os clientes. Em alguns casos, convém personalizar quais clientes do Traffic Director recebem configurações específicas. Em outras palavras, filtre a configuração por clientes específicos.

Embora seja uma funcionalidade avançada, os exemplos a seguir ilustram quando a configuração de filtragem pode ser útil:

  • Sua organização usa o modelo de rede VPC compartilhada e várias equipes estão usando o Traffic Director em diferentes projetos de serviço. Se você quiser isolar sua configuração de outros projetos de serviço, filtre a configuração para que clientes específicos do Traffic Director recebam apenas um subconjunto da configuração.
  • Você tem um grande número de regras de roteamento e serviços configurados no Traffic Director e quer evitar o envio de uma grande quantidade de configurações para cada cliente do Traffic Director. Lembre-se de que um cliente que precisa avaliar uma solicitação de saída usando uma configuração grande e complexa pode ter menos desempenho do que um cliente que só precisa avaliar uma solicitação usando uma configuração simplificada.

O filtro de configuração é baseado no conceito de filtros de metadados:

  1. Quando um cliente do Traffic Director se conecta, ele apresenta informações do arquivo de inicialização para o Traffic Director.
  2. Essas informações têm o conteúdo dos campos de metadados, na forma de pares de chave-valor, especificados no arquivo de bootstrap quando você implanta os proxies Envoy e/ou aplicativos gRPC.
  3. É possível adicionar filtros de metadados às regras de encaminhamento e/ou regras de rota configuradas no mapa de regras de roteamento.
  4. Quando você adiciona filtros de metadados a esses recursos, o Traffic Director só compartilha a configuração com clientes que apresentam metadados correspondentes às condições do filtro.

É possível aplicar filtros de metadados à regra de encaminhamento. Nesse caso, o mapa de regras de roteamento e os serviços associados são compartilhados apenas com clientes do Traffic Director que apresentam metadados correspondentes.

Também é possível aplicar filtros de metadados em regras de rota específicas. Nesse caso, o Traffic Director só compartilha a regra de roteamento específica e os serviços associados aos clientes do Traffic Director que apresentam os metadados correspondentes. Para informações sobre como configurar filtros de metadados, consulte Como configurar a filtragem de configuração com base na correspondência MetadataFilter.

Limitações

A seguir